dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
dgriego1 has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
Tokamak has quit [Ping timeout: 260 seconds]
Tokamak has joined #yocto
jmiehe has quit [Quit: jmiehe]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #yocto
otavio_ has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
arlen_ has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
otavio has joined #yocto
sakoman has joined #yocto
amitk has joined #yocto
Tokamak has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
sakoman has quit [Quit: Leaving.]
roussinm has quit [Quit: WeeChat 3.3-dev]
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
warthog9 has quit [Ping timeout: 268 seconds]
ant__ has joined #yocto
warthog9 has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
lucaceresoli has joined #yocto
<RP> jonmason: I was worried about losing that runner fix so I sent it out
<RP> rburton: I also sent out those sorting fixes. I suspect there is a bigger underlying issue though
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Ping timeout: 252 seconds]
<dagmcr> Hi guys, yocto-3.1.11 was supposed to be released yesterday but it didn’t. However I can see in dunfell branch 3.1.11 was already bumped earlier this month. Have the plans changed? Or testing went wrong? Thanks!
davidinux has joined #yocto
amitk has joined #yocto
goliath has joined #yocto
<RP> dagmcr: it is actually in QA atm and due to be released
<dagmcr> RP: Great! Thanks for the info
<abelloni> kanavin: it is really weird the test passed
<jonmason> RP: no problem. I was waiting for CI to finish yesterday, which took forever. https://gitlab.com/jonmason00/poky/-/pipelines/377038995
<jonmason> I mostly care about it getting into meta-zephyr. So, I'll push that patch out this morning https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/376922543
<jonmason> I'm debating sending patches with a 0/X with a link to the gitlab CI output. Is that worthwhile?
<RP> jonmason: it always helps to know the testing something has had
<jonmason> that boost issue on qemuarmv5 is nice to know about :/
<RP> jonmason: I think mozjs has an issue on v5 too
<jonmason> double :/
<jonmason> probably best to open bugs for these, and I'll see about fixing them in the next couple of months
<jonmason> unless there is more urgency
<RP> jonmason: no real urgency. I've filed two bugs
<RP> jonmason: I also filed the poky-tiny arm one
<RP> again just so we have something to track
<RP> abelloni: ^^^
Vonter has quit [Ping timeout: 265 seconds]
<jonmason> yes, I saw the poky tiny email this morning (which is why you don't read work email in bed on a weekend)
<RP> jonmason: sorry!
* RP really shouldn't be working
<jonmason> No, don't get me wrong. I was going to work on it today. I'm just saying that I should be reading work email :)
<jonmason> I'm a clean plate kind of person, and wanted to get this stuff off my plate
<RP> jonmason: I just worry at things slipping through cracks. I have echos of the os._exit discussion for qemurunner before :/
<jonmason> Also, I promised someone I was going to do a blog post for arm on setting up gitlab ci. So, I need to do a rough draft of that as well
<RP> jonmason: I know what you mean about resolving things, I wanted the pseudo issue I was chasing yesterday sorted out
<RP> my fixes keep not working :/
<jonmason> RP: no worries. it seems like I'm chasing bugs shaked out by gitlab ci for weeks now
<jonmason> oh, and I made the fun mistake of accidentally hosing my sstate hdisk mbr and had to rebuild that from scratch this week
<RP> jonmason: how do you think I feel with the autobuilder!
<RP> jonmason: wait until people tell you it would be so much nicer if... :)
<RP> at least sstate is disposable I guess
* RP needs to clear his sstate disk
<jonmason> RP: watching that video from LPC has me wanting to add stuff. Maybe with enough poking rburton will do it ;-)
<jonmason> sstate is disposable, and I was able to steal from the YP sstate for a little speed-up, but it's become obvious how much I depend on it being there for fast builds
<RP> jonmason: I invalidate mine so often it isn't funny :(
<jonmason> my nightlys take about an hour to build lots of machines and run testimage on the qemus. These are taking over 12 without an sstate being there
<RP> It is just the nature of the stuff I work on
<jonmason> yes, but you have a massive backend to help you. I have a single desktop PC
<jonmason> and I need to work on getting more of my local systems in a build setup
<RP> jonmason: I just have single local server I do my dev work on
<jonmason> oh jeez, then you must be waiting forever
<RP> jonmason: it does have 80something cores
<RP> I only ever really get to mix my changes in with other changes on the main AB
<jonmason> I would be fun to automate the RPC system I have to power-up some systems, then find some way to monitor the job, then shut them down
<RP> jonmason: trivial to write a plugin to bitbake to do something when the build completes
<RP> in fact a metadata eventhandler on BuildComplete would be enough
<abelloni> RP: I had a look back at what was done for mozjs
<abelloni> they used EXTRA_OECONF_append = " --disable-ion "
<abelloni> which made it work on armv5
<abelloni> it was 2 years ago so it may have been fixed since then
<RP> abelloni: handy to know. We should probably have at least some v5 testing to try and stop regressions going unnoticed
<RP> abelloni: its lovely to see the swatbot queue clear. Not sure our AB-INT bug count will agree but...
<jonmason> RP: lol, that was the exact reason why I added it to our CI. Too many unnoticed regressions in qemuarmv5. If you add it, please let me know so I can remove it from ours.
<ant__> jonmason, I don't have any armv5 toy anymore but I have experienced many boot issues on real hw beautifully ignored by qemu :)
<jonmason> ant__: that is fair, but difficult to test in CI :)
<ant__> offhand I remember gcc6>7 transition with align issues :)
<jonmason> armv5 is so old, I'm not sure I could add any systems to the internal LAVA test framework
<jonmason> edit, ask for armv5 systems to be added...
<ant__> ping hrw
<ant__> ^
<jonmason> is the RaspPi version 1 armv5?
<ant__> no, is a developer who now has my armv4/5 zaurus
<ant__> he promised he'll play again with it
<ant__> bbl, must reboot, bye
ant__ has quit [Remote host closed the connection]
<RP> jonmason: do your tests cover polkit?
<jonmason> RP: currently the minimal testimage, trying to expand to everything that is quick (and currently works)
<RP> jonmason: quick cheat would just be to add boost and mozjs to the list of targets I guess
<jonmason> RP: are you referring to my CI, or are you going to add qemuarmv5 to AB?
<jonmason> also, is systemtap broken in riscv or did I just find a bug (its missing from COMPATIBLE_HOST)? I thought it was working earlier in the week
<RP> jonmason: I don't know any more :)
<RP> jonmason: we just upgraded the kernel so that probably broke it
perdmann has joined #yocto
<jonmason> RP: no problem, I'll take a look and see if it's trivial to fix. If so, patch will be sent. If not, I'll open a bug. work for you? :)
<RP> jonmason: riscv? we don't officially support riscv :(
<jonmason> both of qemuriscv64 and 32 see it
<jonmason> if its a machine in poky, I'm building it. if its qemu, then I'm running testimage
<jonmason> though, no fixes for riscv will come from ym work email ;-)
<perdmann> Hi, i cant run bitbake core-image-sato . iam on debian 11 and i get this error: https://dpaste.org/ZiQT
lucaceresoli has quit [Ping timeout: 252 seconds]
<RP> jonmason: well, the recipe says it doesn't support it
<jonmason> maybe it was always breaking....
<RP> It doesn't look bad to fix...
<jonmason> I'm not trying to make you do more work
<jonmason> shouldn't you be riding a bike in a park somewhere? ;-)
<RP> jonmason: IMAGE_INSTALL:append = " connman systemtap"
<RP> jonmason: you're breaking it ;-)
<RP> jonmason: I wish I was out on the bike. Not up to it :(
<jonmason> I already have that line. So, that is how I know it's missing
<RP> jonmason: right, but the recipe specifically says it doesn't build on riscv
<jonmason> ah
<RP> so that isn't going to work
<jonmason> I'm seriously down the rabbit hole of trying to cover my butt for graphics issues with qemuarm ;-)
<jonmason> "Just add a test in CI to make sure it doesn't break"
<RP> every time I look at some of this code I regret it
<jonmason> its always a race to get something done so that you can work on something else
<jonmason> no regrets
<RP> jonmason: rburton would have a fit if he was looking at this bit of oeqa :/
<jonmason> RP: so, we show it to him on monday then?
<RP> jonmason: tempting :)
wwilly has joined #yocto
<RP> bug 14575 and 14574 are probably nice easy ones if someone fancies helping
gioyik has joined #yocto
manuel_ has quit [Remote host closed the connection]
manuel_ has joined #yocto
<tlwoerner> jonmason: i think rpi v1 is armv6
* tlwoerner has several armv5 things being worked on
<tlwoerner> yes, the original rpi had an ARM1176JZF-S, ARM11 is armv6 architecture
angolini has quit [Quit: Connection closed for inactivity]
xmn has quit [Ping timeout: 252 seconds]
lucaceresoli has joined #yocto
vd has quit [Quit: Client closed]
Vonter has joined #yocto
lucaceresoli has quit [Ping timeout: 265 seconds]
<jonmason> I'll have to dig through my pile of old arm boards and see if I have anything older than that
gioyik has quit [Ping timeout: 276 seconds]
* RP has an arvm4 zaurus somewhere
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
florian has joined #yocto
prabhakarlad has joined #yocto
florian has quit [Ping timeout: 260 seconds]
camus has quit [Quit: camus]
gioyik has joined #yocto
vd has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
florian has joined #yocto
florian has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #yocto
gioyik has quit [Ping timeout: 276 seconds]
<abelloni> jonmason: I can probably get some recent armv5 board shipped to you if you plan to add that in a farm
<abelloni> sam9x60 was released end of 2019
gioyik has joined #yocto
<jonmason> abelloni: thanks for the offer. I don't think work would allow outside boards to the LAVA farm. If I can get something like LAVA setup here at home, then I might take you up on it.
ant__ has joined #yocto
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
sakoman has quit [Quit: Leaving.]
florian has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
kd123 has joined #yocto
Gaffel has quit [Quit: What's that?]
kd123 has quit [Quit: Client closed]
jwillikers has joined #yocto
Tokamak has joined #yocto
Jawsy has joined #yocto
<Jawsy> In a yocto build I have pulled in the meta-virtualization layer to get docker running. But with the change in the kernel config, pthread_setschedparam() has started to fail inside a thread. Any ideas? or am I in the wrong place? The meta-virtualization layer has enabled a bunch of cgroup related configs.
locutusofborg has quit [Ping timeout: 265 seconds]
locutusofborg has joined #yocto
Gaffel has joined #yocto
florian has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
dtometzki has joined #yocto
goliath has quit [Quit: SIGSEGV]