<RP>
paulg: I didn't offer to explain it, I just knew how to find that one. I have no idea why it is working at all tbh
<paulg>
:-)
<RP>
paulg: the strip() is a python string manipulation function that removes whitespace so the combination of variable names, functions and programs there is ironic
<usvi>
Saur_Home: I am terribly sorry, I need to go to sleep. I realized it is 2 hours past midnight
<usvi>
I will read replies in the morning tho
<RP>
paulg: it is only run if if (extra_sections and kernel_image.find(d.getVar('KERNEL_IMAGEDEST') + '/vmlinux') != -1)
<paulg>
of course! my mind was 100% focused on the *task* strip, and not the Python ('cause I suck at python)
<RP>
paulg: so I guess only mips does that
<paulg>
namespace overlap completely led me down the garden path. :-/
<paulg>
as for why qemu mips doesn't trigger the extra_sections check ... would require further investigation.
florian_kc has quit [Ping timeout: 268 seconds]
<paulg>
probably doesn't plonk down a vmlinux would be my initial guess.
<RP>
paulg: I remember mips doing something weird with striping so we lost our test case and it regressed
<RP>
makes me wonder if we could remove some code
<paulg>
removing code is good.
<RP>
paulg: makes you loads of friends, they start emailing you :)
<paulg>
oh yeah, I know it well. :) It is nearly always a good way to kick the hornet's nest and get the vocal minority all wound up.
<RP>
paulg: nobody noticed the && true in the makefile :)
<Saur_Home>
RP: Just upgraded our platform to 4.3.2. Prefer to do it late on Fridays so that the builders can populate the sstate-cache for all products during the weekend.
<RP>
Saur_Home: I'm depressed that despite my efforts I'm no where near close to sorting the patch queue and I really don;t like that patch so a great way to end the day :(
<Saur_Home>
RP: Sorry
<Saur_Home>
RP: If you do not want to take it, then I will not trouble you with it again. Since this is in a bbclass, I can handle it on our side by copying it to one of our layers and modifying it there.
<paulg>
Linux version 6.6.15-yocto-standard (oe-user@oe-host) (mips64-poky-linux-gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.42.0.20240202) #1 SMP PREEMPT Sun 4
<Saur_Home>
RP: Regarding the virtual/ warning: Wouldn't it be better to recommend that the virtual/foo is replaced by defining a VIRTUAL-RUNTIME_foo variable and using that instead?
<simonew>
RP: we use virtual- instead in meta as well e.g. in grub-bootconf for RPROVIDES. We should change that then as well right? I can send another patch.
<RP>
simonew: I'm less worried about that since it isn't as common a problem so torn on whether it is worth changing. It technically isn't right though
mulk has quit [Ping timeout: 276 seconds]
benkard has joined #yocto
benkard is now known as mulk
xmn has quit [Quit: ZZZzzz…]
<simonew>
Ok, It seems only 6 recipes are affected. Should be therefore limited
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
alessioigor has joined #yocto
Chaser has joined #yocto
Chaser has quit [Client Quit]
mulk has quit [Ping timeout: 256 seconds]
mulk has joined #yocto
xmn has joined #yocto
Kubu_work has joined #yocto
Marmottus11 has quit [Ping timeout: 264 seconds]
mulk has quit [Ping timeout: 268 seconds]
mulk has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Marmottus11 has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
<simonew>
Just checked now out of interest: the switch virtual/ to virtual- seemed not to cause big issues back then. I've sent a patch now for it, but if not considered worth it, also fine.
<mischief>
RP: so far no such issue in my ubuntu container on the same machine, so it's probably just an untested version of something in the host tools of gentoo
<mischief>
.. like when having a very new make broke a bunch of old makefiles
<RP>
mischief: let me know if you work out what it is caused by, I'm curious now...
amitk has quit [Ping timeout: 246 seconds]
amitk has joined #yocto
<Saur_Home>
RP: I saw your message to rburton earlier regarding glib and some memory error. I do not know if it is the same error, but we are affected by https://gitlab.gnome.org/GNOME/glib/-/issues/3064, which is the reason we have opted to stay at glib 2.74. With 2.76 and 2.78 we get random memory corruptions.
<RP>
Saur_Home: this is a glib test suite failure in the low memory signalling from dbus
<RP>
causes intermittent failures in ptests
<Saur_Home>
Ok, probably something else then.
amitk has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
<mischief>
RP: i have no idea what is wrong, because running opkg-build by hand works :-D
<Saur_Home>
Interesting. I just realized that glib issue 3064 has been closed. Seems we will finally have a solution in 2.80. :)