<khem>
RP: I have sent a better fix for zip issue, its on ml
xmn has quit [Ping timeout: 268 seconds]
amitk has joined #yocto
jmd has joined #yocto
_whitelogger has joined #yocto
Abp has joined #yocto
jmd has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
alperak has joined #yocto
_whitelogger has joined #yocto
jmd has joined #yocto
sfo has joined #yocto
_sfo has quit [Killed (NickServ (GHOST command used by sfo!d6f77adfe3@user/sfo/x-3716460))]
_sfo has joined #yocto
mvlad has joined #yocto
leon-anavi has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.2.2]
enok has joined #yocto
Daanct12 has joined #yocto
enok has quit [Ping timeout: 256 seconds]
<kanavin>
Jookia, for what it's worth I think we can remove looking at the host pkg-config entries, as it is not actually used for anything nowadays - theoretically it can be used with host libsdl, but that's been long obsolete by libsdl-native configured with opengl acceleration
<kanavin>
I think RP also wanted to keep it as an example of how to link with host libraries if/when needed, but if it's causing trouble like yours I'd rather drop that.
sakoman has quit [Ping timeout: 268 seconds]
alessioigor has joined #yocto
sakoman has joined #yocto
florian has joined #yocto
<RP>
kanavin: we still shouldn't have floating pkg-config detection though :/
mckoan|away is now known as mckoan
Abp has quit [Ping timeout: 246 seconds]
Abp has joined #yocto
chep has quit [Ping timeout: 256 seconds]
jmd has quit [Remote host closed the connection]
Abp has quit [Read error: Connection reset by peer]
Abp has joined #yocto
Guest9734 has joined #yocto
Abp has quit [Read error: Connection reset by peer]
Abp has joined #yocto
jmd has joined #yocto
<kanavin>
RP: yes, of course. I'll try to find time and bring the set of recipe options in perfect match with upstrema.
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<RP>
kanavin: I couldn't work out how to pass an option to meson to disable gvnc-1.0 detection (it is buried in one of the tests)
Daanct12 has quit [Quit: WeeChat 4.2.2]
chep has joined #yocto
florian has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
sotaoverride is now known as Guest7222
Guest7222 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
<landgraf>
If "module" class is inherited then kernel-module-${PN}-${KERNEL_VERSION} dependendency is added to the package while documentation (and example "hello" module) suggests adding RPROVIDES:${PN} += "kernel-module-hello") resulting in broken dependencies :(
<RP>
landgraf: the documentation is probably out of date :(
<landgraf>
RP: this it NXP documentation not YP (I just googled it). But hello_mod example is ours
<RP>
we should perhaps fix hello-mod then? Sounds like we might be missing a test too? :/
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
pbiel has joined #yocto
<pbiel>
Hi, I have a following entry in wks file part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --offset 128M --fixed-size 1G --sourceparams="loader=u-boot" --use-uuid
<pbiel>
however when I boot my linux the -mmcblk0p1 is mounted under /run/media/boot-mmcblk0p1
<pbiel>
why is that?
<pbiel>
any ideas?
<Xogium>
maybe it is mounted in both places ?
<mckoan>
pbiel: see fdisk
<mckoan>
pbiel: I mean, see /etc/fstab
<pbiel>
nope in /boot I have a different content
<pbiel>
in /etc/fstab there is nothing about mmcblk0p1
<pbiel>
I was sure that the entry will base added base on wks file
<pbiel>
will be added based on wks file*
<Xogium>
sounds like er, how's that called again, udisks is automounting stuff ?
<Xogium>
if you got a desktop env on there, they also like to automount partitions in /run
<Xogium>
random ideas
<pbiel>
Hmm I think I've got something, there is an udev rule that calls a script that is responsible for mounting, so that's the reason. However I'm still curious, isn't that wic is supposed to update fstab accordingly to wks file? It's even mentioned in the doc here: https://docs.yoctoproject.org/ref-manual/kickstart.html
ablu has quit [Ping timeout: 255 seconds]
ablu has joined #yocto
guestkati has joined #yocto
alessioigor has quit [Quit: Client closed]
michal has quit [Ping timeout: 264 seconds]
<guestkati>
Hi, I at openssh9.7_p1.bb there is an UNPACKDIR variable and can't find it in the manuals. The commit msg says about not unpacking to WORKDIR. In my build the UNPACKDIR variable is not set and ultimately searches for a file in root (install -m 0644 ${UNPACKDIR}/ssh_config ${B}/). Is this something introduced in new versions of yocto?
<Jookia>
kanavin: removing it would be great. should i send a patch?
jwessel has joined #yocto
Guest9734 is now known as MrCryo
florian has joined #yocto
<Jookia>
is there any scriptable/line-based alternative to thinks like taskexp and depexp? ie to find a tasks's dependencies
<smurray>
guestkati: the change to UNPACKDIR is a recent thing on master branch, there was some discussion on the mailing list wrt rationale
Xagen has joined #yocto
florian has quit [Ping timeout: 255 seconds]
<RP>
Jookia: bitbake -g generates task-depends.dot files which you can process
<Jookia>
yeah i might make a few scripts for this
<RP>
Jookia: any patch removing that needs a clear explanation of why it isn't needed. I'm still not 100% convinced we can remove it
<Jookia>
RP: i think removing it because it's broken and leaky is a good reason, but also i don't think it's needed for anything?
<Jookia>
the documentation is unclear why this is actually needed
<RP>
Jookia: I have enough other major problems without merging something I strongly suspect will break several use cases. I'm sorry if I haven't had the time to research and document those use cases in full :(
<RP>
I appreciate it is frustrating not to know exactly what I'm referring to but it is a suspicion I have and it would take work to prove/disprove it :(
<RP>
basic summary I'm overloaded and need a break, not more work
<Jookia>
couldn't you just merge the patch and see if it gets complaints for breaking things?
<RP>
Jookia: who is going to deal with the complaints? Do we have the bandwidth in automated testing to take a potential set of build failures from such a change?
<Jookia>
you can revert if it it's broken. isn't there some kind of -next branch?
<Jookia>
the complaints would show up on the mailing list wouldn't they?
<RP>
Jookia: it sounds so simple when you put it like that :/
<RP>
Jookia: I have a little experience at this (a couple of decades) and it really isn't that simple :(
<RP>
If I ignore the issue you get upset/disillusioned, if I explain the problem you also get upset/disillusioned and also don't believe me :/
<RP>
feel free to send the patch. We can try and test it but no promises
<Jookia>
i'm absolutely fine with my patches not being merged or sitting in patch purgatory
<Jookia>
that's generally where patches go in high profile projects
<RP>
Jookia: I'd hope the majority of ours don't :/
<Jookia>
it's more disillusioning to get in discussions that have no resolution
* RP
notes not to get into them in future then and just stay silent
<RP>
I did say a better more immediate solution that would get merged would be to find out how to configure qemu not to enable that package
<Jookia>
i don't you said that would get merged?
<Jookia>
or was that implied
<RP>
I would take a patch which added an explicit disable of gvnc-1.0. I just couldn't find the right configure option
<Jookia>
there's no configure option, it would require a patch
<RP>
I'd take a patch, particularly if it was sent upstream too
<Jookia>
maybe there's a disable-tests flag?
<Jookia>
qemu are doing the same thing openembedded is: checking the host for available libraries and linking to them
<RP>
openembedded is supposed to be explicit, only linking to specific things
<RP>
qemu-native is one of the very few places we let influence in from the host. It is supposed to be safe since we have explict configure options to qemu
<Jookia>
i think removing the host influence would be a better idea, if you can give a list of things you think it would break i'd test them
<Jookia>
the only thing i can think would break is host opengl but things have changed a lot since 2014 with that
<kanavin>
Jookia, I thought RP told you there is no such list? Seriously, why don't you go to your manager, tell them we are struggling, and ask if you can help with the core things instead of micro-focusing on your little issue
<kanavin>
otherwise, dig into qemu source, find how to add an option that disables the thing that leaks from the host, send that to qemu upstream, get it merged, and then send us a backport
<kanavin>
while you're at it, get qemu updated to 9.0 too
<kanavin>
or is it all someone else's problem?
<Jookia>
???
<Jookia>
i'm trying to do free work here to fix a bug
<Jookia>
i'm happy to do all the testing and deal with feedback or have my patches in purgatory
<Jookia>
i'm just ASKING if they COULD give me that list
<kanavin>
how are you using the yocto project?
<Jookia>
i'm using it on arch linux
<kanavin>
are you putting it into a product, and selling that product on the market?
<Jookia>
no?
<Jookia>
if you only want contributions from companies and paid workers and not hobbyists, fine
<RP>
Jookia: sadly I don't have the list, I'd have to do some work myself to try and work it out
<Jookia>
there is no commercial incentive to work on the things i care about
* RP
feels particularly bad about this :(
<Jookia>
if you're asking me to throw money at fixing the bugs i hit, that's impossible. sorry
<Jookia>
i'm happy to throw work at actually fixing things
<RP>
contributions are welcome, I'm just warning that a patch removing this code entirely, whilst seemingly attractive, is very hard to review/merge safely
<Jookia>
yeah that's fine, i'd just like some concrete objections at some point (next year?) to move things forward with it
<Jookia>
or a general idea of why it could be broken so i can test it
<Jookia>
kanavin: if you're asking me to fix specific things, no
<Jookia>
if you don't care about other fixes, that's fine
<Jookia>
i've barely even used yocto/openembedded, i figured trying to fix the first bug i saw that affects all image builds on arch might be a good idea?
<kanavin>
Jookia, sure, but it's a qemu bug
<Jookia>
you're not going to get random hobbyists who don't know the project internals to just jump in and fix large issues like that
<kanavin>
and so you need to fix it in qemu
berton has joined #yocto
<Jookia>
it's only a qemu bug if qemu says it's their bug
<kanavin>
you need to find out.
<Jookia>
it's not really useful to argue over who owns a bug if nobody wants it fixed
<kanavin>
typically upstream projects are willing to take patches that eliminate floating dependencies
<RP>
we agree it needs fixing, the question is how
<Jookia>
the bug i have is only triggered by a floating dependency, it isn't BECAUSE of floating dependencies
<Jookia>
yocto intends to link to an unknown amount of host libraries and mix them with the toolchain
<RP>
Jookia: most projects do understand that floating dependencies are tricky for determinism and are prepared to take patches to at least add configure options for them
<Jookia>
it's unclear what libraries they are
<RP>
Jookia: the specific ones we're looking for are the ones related to SDL/GL/vnc support but we're not meant to be using gvnc
<RP>
and none of the SDL/GL/vnc options should be working without explicit config regardless of whether they're on the host
<Jookia>
i guess the thing to do is to test if you need host packages for SDL/GL/vnc
<kanavin>
Jookia, no. You need to add an explicit option in qemu tree for what is now implicit, and send it upstream.
xmn has joined #yocto
<Jookia>
alrighty
alessioigor has joined #yocto
LocutusOfBorg has quit [Read error: Connection reset by peer]
<RP>
I say close rust is breaking and takes ages to retest
ptsneves has joined #yocto
MrCryo has quit [Ping timeout: 256 seconds]
MrCryo_ has joined #yocto
MrCryo_ has quit [Remote host closed the connection]
MrCryo has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
<Xagen>
good day everyone
<Xagen>
i have an issue with my sdk toolchain that i'm trying to solve
sakoman has joined #yocto
<tgamblin>
rburton: I can submit those
<Xagen>
i have nativesdk/host tools and the side of the sdk for the target system
<Xagen>
the make files for the kernel that get packaged for the target system use the host systems gcc when i run the build instead of the gcc from the toolchain
<Xagen>
is there an easy way to fix this without patching the make files?
<rburton>
pass CC to the makefile, its in the environment
<Jookia>
vmeson: is there a branch for testing gcc 14?