camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<thomasd13>
The package zfs requires >python3.4. I assume it uses somehow autotools to determine which python version is available. Up to autoconf version 1.16.2, there was a bug that autoconf could not detect any python version > 3.10. For example 3.11 would have been detected as 3.1
<thomasd13>
Can I somehow control which autoconf version that zfs package is using during configure-stage? I would like to give it >1.16.2 that it can detect my "host-python version of 3.11"
<thomasd13>
I think thats the root reason why the configure stage of zfs is failing for me, due to detect wrong python3.1 version
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
<thomasd13>
Or to ask more specific: Who is providing "./recipe-sysroot-native/usr/share/aclocal-1.16/python.m4" in the package work directory, and how can I control/patch it?
<thomasd13>
neverpanic, thank you so much. I was searching for autoconf and aclocal. No wonder I didnt find the correct package
<thomasd13>
Where can I read about the relation of "automake" and the autoconf relation? Just asking for reference if I have similar issues in the future
xmn has quit [Ping timeout: 248 seconds]
olani has quit [Ping timeout: 246 seconds]
<neverpanic>
thomasd13: I did dnf provides /usr/share/aclocal-1.16 on my fedora development system, and it told me that folder was provided by automake, then looked for automake in the poky tree.
<neverpanic>
Not sure there's a simpler way for -native recipes, since those IIRC don't use a package manager. If you were on target you could use opkg (or whatever package manager you have enabled) to do the same thing.
<thomasd13>
Ah okay, so you searched on your host system, who is providing that particular file and then transfered that to yocto-project
mvlad has joined #yocto
Thorn has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
leon-anavi has joined #yocto
<neverpanic>
yes
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
amelius has joined #yocto
<amelius>
vmlinux is created during kernel build
<amelius>
Hey I'm trying to create an fitimage with help of kernel-fitimage class and keep getting: aarch64-poky-linux-objcopy: 'vmlinux': No such file
argonautx[m] has quit [Quit: You have been kicked for being idle]
olani has joined #yocto
gegir has joined #yocto
Thorn has joined #yocto
<LetoThe2nd>
yo dudX
<qschulz>
LetoThe2nd: o/
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
gegir has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<JaMa>
"I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" when building xmlto-native is known issue? Just got it in langdale after last update from yesterday and IIRC there were some fixes around this in master recently
<RP>
khem: I agree we should switch, someone just needs to debug the taskhash problem. I'm trying to get there but I can only fix so many things at once :(
<RP>
JaMa: I've worried about the network accesses from some of this stuff for a while :/ I'm not sure the recent changes explictly fixed anything like that
<JaMa>
RP: ok, I'll check if it does (and why it started to appear after yesterday)
gegir has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
Guest1 has joined #yocto
florian has joined #yocto
d-s-e has joined #yocto
Obj87 has joined #yocto
<thomasd13>
Is it possible with bitbake to delete everything in the sstate-cache which a specific image does NOT depend on?
<RP>
thomasd13: easiest would be to set it up as a mirror and run a new build, then see what gets copied to SSTATE_DIR ?
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<thomasd13>
RP, but a mirror only includes the downloaded sources, no? So a new build will build everything again, but without fetching the sources - when I am right here?
<RP>
thomasd13: I mean using SSTATE_MIRRORS
<thomasd13>
ahhh
<neverpanic>
thomasd13: No, an sstate mirror, that will contain the sstate items that were used.
<neverpanic>
If you do this locally, you'll get links (sym- or hard-, don't remember), which are basically free
<neverpanic>
You can then write a script to use that to keep your cache small and only cover those items you're actually using regularly.
kanavin_ has joined #yocto
kanavin has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<JaMa>
the disadvantage might be that after the build only the "final" sstate archives will be fetched from SSTAT_MIRRORS and next time you change something you might rebuild more (even when the sstate on old SSTATE_MIRRORS which you deleted would still be useful and applicable)
<JaMa>
the sstate-cache-management.sh has some support for filtering based on stamps directory, that might give you better and more complete results
<JaMa>
but I haven't used that feature for long time and it's possible that bit rot started to grow there long time ago
ptsneves has joined #yocto
gegir has quit [Ping timeout: 265 seconds]
Guest1 has quit [Quit: Ping timeout (120 seconds)]
<thomasd13>
Thank you very much guys for suggestions: I just setup a SSTATE_MIRROR and compare now my new SSTATE_DIR with the mirror
Guest1 has joined #yocto
<Guest1>
Does anyone know of an example online of enabling multilib or 32-bit application support for a 64-bit raspberry pi distro?
camus has quit [Remote host closed the connection]
camus has joined #yocto
<LetoThe2nd>
guest1: where do you have that?
<LetoThe2nd>
guest1: and the last line is probably the problem. which release are you on?
<LetoThe2nd>
guest1: hint - look at the documentation that i linked.
Guest1 has quit [Quit: Client closed]
Guest1 has joined #yocto
azcraft has joined #yocto
alex88_ has quit [Read error: Connection reset by peer]
alex88 has joined #yocto
beneth has quit [Quit: Gateway shutdown]
beneth has joined #yocto
Guest1 has quit [Quit: Client closed]
seninha has joined #yocto
d-s-e has quit [Ping timeout: 265 seconds]
aduda has joined #yocto
amelius has quit [Read error: Connection reset by peer]
amelius has joined #yocto
aduda has quit [Read error: Connection reset by peer]
fuzzybear396513 has joined #yocto
<fuzzybear396513>
I've got a very reproducible error that doesn't make any sense.
<fuzzybear396513>
I have a recipe that's failing on the ` do_package.qa` step.
<fuzzybear396513>
The error is that a file exceeds the "maximum shebang size"
<fuzzybear396513>
But, I've looked at the file and the shebang is literally #!/bin/bash
<fuzzybear396513>
The claimed maximum size is 128. So, I'm not sure why this error keeps popping up or how to fix it.
<fuzzybear396513>
Unfortunately, the build source and context is proprietary. But, since I'm asking for support in a public forum I can probably meet halfway.
<rburton>
the check reads a line from the file, so i'd check line endings
<fuzzybear396513>
What sorts of issues could result in this error besides a long hashbang?
<RP>
fuzzybear396513: are you sure you're looking at the right file? If so you might need to look more closely at the test, maybe make it print the line it thinks is wrong
<RP>
rburton: could be right about the line encodings
<rburton>
the logic is package_qa_check_shebang_size in insane.bbclass
<fuzzybear396513>
I'll double-check the line endings.
<mcfrisk>
fuzzybear396513: if files embed paths from the recipe sysroot, then paths to bash etc can become really long, and some file systems have limits with long file names
<fuzzybear396513>
I guess you're saying to make sure they're \cr\lf instead of just \cr or similar.
<rburton>
fuzzybear396513: well, \n would be expected, and i believe that's what readline() will look for on a binary file
<fuzzybear396513>
Okay, This gives me some food for debugging.
<fuzzybear396513>
rburton \n being system-dependent, I guess, you mean.
<rburton>
not really, \n is \n
<fuzzybear396513>
What's the hex representation of \n?
<rburton>
'The line terminator is always b'\n' for binary files' so assuming the check you're running is the same as the one i'm looking at, that's the ending it uses
<rburton>
$ echo |od -x
<rburton>
0000000 000a
<rburton>
0x0a
<RP>
fuzzybear396513: \n is 0xa. a \r might be there instead 0xd
<rburton>
or man ascii will tell you
<RP>
but comparing the file with a known ok one with a hex editor would be a bad place to start
<RP>
er, wouldn't be
<fuzzybear396513>
Right.
<fuzzybear396513>
Okay. Deal.
<rburton>
"head myfile | od -c" would be a good starting place
Max[m] has joined #yocto
<fuzzybear396513>
I'll check for weird line endings. It _might_ be a path length issue, too, since the paths in the error output is pretty long.
<fuzzybear396513>
rburton I've always used hexdump. od is new to me. I'll man it.
* RP
likes mc and it's view function
<rburton>
hexdump works too :)
<fuzzybear396513>
Wow. Thanks you guys!
<fuzzybear396513>
I didn't see it but there are ~100 trailing spaces after the first line in the problematic file.
<fuzzybear396513>
So, there _is_ a newline. But, it's >128 characters deep into the first line.
<fuzzybear396513>
Really appreciate it.
<rburton>
glad that was easy :)
<rburton>
maybe the test should print the line...
<fuzzybear396513>
I'm not sure. Honestly, this feels like it should have been on me.
jclsn has quit [Quit: WeeChat 3.8]
aduda has joined #yocto
amelius has quit [Read error: Connection reset by peer]
amelius has joined #yocto
aduda has quit [Read error: Connection reset by peer]
<RP>
rburton: I was also wondering if we should print it and whether if we did, it had quotes
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Schlumpf has joined #yocto
Xagen has quit [Ping timeout: 248 seconds]
<ArgaKhan>
rburton: are you there?
<rburton>
aye
<rburton>
for a bit anyway
amitk has quit [Ping timeout: 246 seconds]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<ArgaKhan>
rburton: We were talking the other day. I still couldn't solve it. I couldn't see that this irc also says "no notification" and missed it. I am using the kirk stone branch.
<ArgaKhan>
rburton: *We were talking the other day. I still haven't been able to solve it. This irc doesn't have a notification feature, I couldn't see it and missed it. I am using the Kirk stone branch.
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
sakoman has joined #yocto
Schlumpf has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
kscherer has joined #yocto
goliath has joined #yocto
rob_w has quit [Remote host closed the connection]
Xagen has joined #yocto
mckoan is now known as mckoan|away
Thorn has quit [Ping timeout: 248 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
<Spinola>
[RP] I'm back again with next problem, now using the SDK that was build from kirkstone. During the 'make modules' i get the following error: "1>cc1 : error : cannot load plugin ./scripts/gcc-plugins/arm_ssp_per_task_plugin.so: ./scripts/gcc-plugins/arm_ssp_per_task_plugin.so: undefined symbol: _ZN8opt_pass14set_pass_paramEjb". This seams to be a known problem, can you give me some hints?
<RP>
Spinola: I have no idea what that means
gegir has joined #yocto
louis_ has quit [Read error: Connection reset by peer]
<RP>
Spinola: I don't know if you specifically need that. The bug is still open
thomasd13 has quit [Ping timeout: 255 seconds]
<Spinola>
[RP] I will have to see what GCC_PLUGINS brings to the table (it was always on by default and didn't gave any problems so I never looked into it)
<Spinola>
[RP] But why doesn't bitbake complain about this when building an out of three module, while using the SDK gives this error?
<RP>
Spinola: gcc plugin support is working in the cross compiler used in the build but not in the sdk compiler? I'm just guessing
<zeddii>
no progress. but I just fixed a peripheral problem to it this morning, so I'll see if I can update the bug with the latest while I'm setup to test it. I'm mainly looking at it from the point of view of tweaking the .config to not cause the issue, versus the plugins themselves.
<RP>
zeddii: right, there are just posts pointing there about the compiler issue too :/
<Spinola>
[RP] But the SDK is build from this same systesm
<RP>
Spinola: gcc-cross and gcc-cross-canadian are two different builds of the compiler
<RP>
Spinola: looking at a more recent compiler I can see "checking for -rdynamic... yes" so I think this was at least improved on master
<Spinola>
[RP] I saw a remark from [rburton] that generating the SDK on master also worked without a problem, right? Are these problems related?
<zeddii>
RP: yah, it wasn't clear if the plugin issues were due to them being incorrectly detected and the kernel-build artifacts .config being wrong. That's what I'm currently looking at.
* RP
gets depressed every time I wade into this. I have a local patch starting to rip apart some of the silly naming of some of the virtual/ deps but we're probably too far into M4 for this kind of work
<fray>
late to the discussion, but which plugins? I thought LTO was a plugin and that is working for us in the Langdale SDK.. and last time (a few weeks or so back) I built master it appeared to work
<RP>
fray: it is the gcc plugin api itself, being able to compile plugins against the compiler
<fray>
Ahh ok.. so different then
GNUmoon2 has quit [Remote host closed the connection]
ecdhe_ has quit [Read error: Connection reset by peer]
<rburton>
zeddii: have you been told that the -dev kernel's perf fails with buildpath errors? WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/src/debug/perf/1.0-r9/arch/arm64/include/generated/asm/syscalls.c in package perf-src contains reference to TMPDIR [buildpaths]
ecdhe has joined #yocto
seninha has quit [Ping timeout: 248 seconds]
<RP>
rburton: of course it does, it is perf :/
<RP>
we should get poky-bleeding going using -dec
seninha has joined #yocto
<rburton>
yeah
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
florian has quit [Quit: Ex-Chat]
d-s-e has quit [Quit: Konversation terminated!]
* RP
wonders if he'd be crazy to look at doing that
leon-anavi has quit [Quit: Leaving]
<rburton>
starting with just the dev kernel would be a good starting point
* RP
suspects external toolchain people will be hit
gegir has quit [Ping timeout: 252 seconds]
<zeddii>
rburton: haven't seen that yet, but my perf was just building fine for x86-64 and the -dev kernel.
<zeddii>
was working on 6.3 this morning, so maybe it'll pop out when I get further into that.
mvlad has quit [Remote host closed the connection]
<RP>
zeddii: enabling the dev kernel is a preferred provider? was there a perf bit as well?
<zeddii>
core-image-kernel-dev testing, yep.
<zeddii>
with linux-yocto-dev
<zeddii>
root@qemux86-64:~# uname -a
<zeddii>
Linux qemux86-64 6.2.0-yoctodev-standard #1 SMP PREEMPT_DYNAMIC Mon Dec 12 16:03:35 UTC 2022 x86_64 GNU/Linux
<zeddii>
root@qemux86-64:~# rpm -qa |grep perf
<zeddii>
perf-tests-6.2.0-r9.qemux86_64
<zeddii>
perf-python-6.2.0-r9.qemux86_64
<zeddii>
perf-6.2.0-r9.qemux86_64
<rburton>
zeddii: might be an arm thing, try with qemuarm64
<zeddii>
yah. x86 doesn't tend to generate syscalls
<rburton>
jonmason was a fool and added -dev to meta-arm CI, so it just blew up
<zeddii>
we look forward to his perf patch!
<RP>
rburton: if it means you get to tell zeddii instead of me... :)
<zeddii>
I have to sort out 6.3 and this gcc plugin thing before I can switch machines.
<jonmason>
Someone thought testing the next kernel would help us find problems before they hit us
<rburton>
need to have words with that idiot
rfuentess has quit [Remote host closed the connection]
<jonmason>
probably the same idiot that thought doing big endian iamges would be a good idea
<rburton>
what a fool
<rburton>
you can't help some people
<jonmason>
of course, there is probably some idiot that implemented kas and gitlab ci on poky and runs it nightly
<mcfrisk>
"pity the fool"
<rburton>
RP: can you remember what recipe broke with meson and its rpath stripping? (disable-rpath-handling.patch). Looking at the referenced bugs upstream, since a long time ago its only stripped the rpaths it added to the build tree, so we should be able to drop that.
<rburton>
aha the commit says, how useful!
<rburton>
" (e.g. libmodulemd-native used by libdnf can't find libyaml)"
<rburton>
so guessing if an image builds with dnf, it doesn't need to be applied anymore
<RP>
rburton: I was just about to say, the commit message hints!
<tlwoerner>
when packaging, could someone point me to an example of the trick used to change the order of packages?
<tlwoerner>
how do i capture files that would be included in an earlier package into a later package?
amitk has quit [Ping timeout: 248 seconds]
Guest67 has joined #yocto
<yocton_>
PACKAGES:prepend = "... " or PACKAGES =+ "..." ?
<yocton_>
note: "=+" and not "+="
yocton_ is now known as yocton
amitk has joined #yocto
ArgaKhan has quit [Ping timeout: 255 seconds]
<tlwoerner>
that works if i'm creating a new package, but what if i want to re-arrange the exisitng set?
<tlwoerner>
${PN}-doc is consuming files that should be in ${PN}
<yocton>
Do you have custom $FILES:... ? (I don't see any overlap between $PN and $PN-doc
<yocton>
IIRC I did once PACKAGES:remove = "${PN}" and PACKAGES:prepend = "${PN} " but it was a workaround... Can you edit FILES:${PN}-doc to remove the paths you want in ${PN} ?
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
gsalazar has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
amitk has joined #yocto
Guest67 has quit [Quit: Client closed]
gsalazar has joined #yocto
risca has quit [Ping timeout: 260 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
amitk has quit [Remote host closed the connection]
<rburton>
tlwoerner: -doc only grabs the documentation directories, so i'm curious what the problem is
amitk has joined #yocto
<rburton>
khem: RP so it looks like the buildpaths issues are resolved in meta-clang
<rburton>
doing another layer check now to see what the fallout is
<tlwoerner>
rburton: cups
<tlwoerner>
rburton: most people expect to log into http://localhost:631 and see the cups printer info
<tlwoerner>
these files are installed under /usr/share/doc/...
<tlwoerner>
the cups recipe *thinks* it's packaging up these files as part of ${PN}, but it isn't
<rburton>
lol
amitk has quit [Ping timeout: 255 seconds]
<rburton>
that's a silly place to put the web gui
gsalazar has quit [Ping timeout: 268 seconds]
<rburton>
tlwoerner: you could just set FILES:PN-doc to just ${mandir} so it grabs the manpages but not the docs. or make PN recommend PN-doc, after all you _might_ want the server without the web ui
<tlwoerner>
rburton: right. or simply remove the comment and those FILES:${PN} lines from cups
<tlwoerner>
if the user wants the webui they are free to install cups-doc
<tlwoerner>
but there's a divergence between the code and comments in the recipe, and what actually happens
<tlwoerner>
just not sure which way to go on this one
florian_kc has joined #yocto
gsalazar has joined #yocto
<rburton>
tlwoerner: i'd be tempted to split up the webgui into a separate package properly and have that as a recommends
gsalazar has quit [Ping timeout: 268 seconds]
<tlwoerner>
rburton: if you're skipping over the fact that cups contains its own web server then no, this is not silly :-P
<rburton>
yeah that's true
<tlwoerner>
rburton: yes, that's sort of the direction i'm taking
<rburton>
FILES:${PN}-doc = "${mandir}" would be the easy fix
<tlwoerner>
a separate PACKAGECONFIG
<tlwoerner>
and a separate package
<tlwoerner>
"let the user decide"
<tlwoerner>
and remove the comments/FILES lines
<tlwoerner>
rburton: what's the advantage of having it as a recommends?
<rburton>
people get it by default, can remove it
<tlwoerner>
can it be removed on a package-by-package basis, or globally?
<tlwoerner>
how about adding it as a recommends if the packageconfig is enabled?
<paulg>
anyone used EXTRA_IMAGE_FEATURES = "read-only-rootfs" recently? Doesn't even build on the beaglebone reference platform on master...
<paulg>
ERROR: core-image-minimal-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['100-sysvinit-inittab']
<paulg>
guessing it doesn't get autobuilder coverage.
<tlwoerner>
paulg: i was using it over the holidays
<tlwoerner>
it doesn't interact well with the "expand the rootfs on first boot" trick, but otherwise it was okay then
<paulg>
tlwoerner, thanks - I'll look for something relatively recent when I investigate then.
<tlwoerner>
paulg: coincidentally i did use it with a beaglebone black, although i used meta-ti and no-distro oe-core
<paulg>
good to know that I'm not completely off in the weeds in cobweb infested cruft nobody has touched for years.
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
* tlwoerner
's farm provides him with lots of after-hours fun
<paulg>
I'm not falling into that trap again -- buying hardware and then it sits in the box for five years.
<paulg>
Only reason my beaglebone black saw its 1st electron was 'cause I was asked to look into dm-verity and that is the only platform we (yocto/oe) have traces of being used.
<paulg>
I've also got an r-pi3 that has never been out-of-box. "Oh look, it is on sale - might be handy for a project."
<paulg>
I'm sure I'm not the only one who does that.
<paulg>
might be a sensible path forward from the decade old beagleboard black as a reference platform though?
gsalazar has joined #yocto
goliath has quit [Quit: SIGSEGV]
<rburton>
paulg: that’s almost definitely because the machine uses SERIAL_CONSOLES. That isn’t read only friendly with sysv. Systemd works though :)
<paulg>
systemd - my favourite piece of software...
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
tlwoerner: denix was telling me about the https://beagleboard.org/ai-64 earlier in the week. bit more grunt than the play.
<denix>
paulg: I have a zoo of boards I don't have time to play with. though I've been able to find dedicated tasks around the house for several of my BBBs and RPis.
<RP>
paulg: you're not but I try to power them at least once :)
<RP>
rburton: where are we going with this, enable on the AB?
<denix>
rburton: BeaglePlay is not as powerful but cheaper - AM62x/Cortex-A53 vs. J721e/Cortex-A72+C7x DSP/MMA in AI-64
<JaMa>
I try to power my toys at least once a year, but my interest sometimes fades before their batteries got enough juice to actually boot
<rburton>
rburton: ideally, remove the use of CONSOLES from the bsp. real hardware shouldn't really need it.
<denix>
SERIAL_CONSOLES_CHECK[doc] = "Similar to SERIAL_CONSOLES except the device is checked for existence before attempting to enable it. Supported only by SysVinit."
<rburton>
systemd does the right thing and brings up consoles on devices it discovers