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)
BCMM has quit [Quit: Konversation terminated!]
goliath has quit [Quit: SIGSEGV]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
amitk has joined #yocto
yannd has quit [Ping timeout: 252 seconds]
<zeddii> hmmm. just did an update to master, and now, all of my -native packages are failing to fetch/unpack.
paulg has quit [Ping timeout: 265 seconds]
erbo has quit [Quit: Lost terminal]
davidinux has joined #yocto
amitk has quit [Quit: leaving]
amitk has joined #yocto
pidge has quit [Remote host closed the connection]
pidge has joined #yocto
gsalazar has joined #yocto
Puru has joined #yocto
pidge has quit [Remote host closed the connection]
pidge has joined #yocto
amitk has quit [Quit: leaving]
amitk has joined #yocto
amitk has quit [Client Quit]
amitk has joined #yocto
mckoan has joined #yocto
<mckoan> good morning
amitk is now known as idlethread
idlethread is now known as amitk
dtometzki has quit [Read error: Connection reset by peer]
dti has joined #yocto
leon-anavi has joined #yocto
Puru has quit [Quit: Client closed]
xantoz has joined #yocto
pbergin has joined #yocto
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
ilunev has joined #yocto
goliath has joined #yocto
tnovotny has joined #yocto
Dorinda has joined #yocto
BCMM has joined #yocto
JaMa has quit [Quit: off]
mccc has quit [Ping timeout: 264 seconds]
pidge has quit [Ping timeout: 264 seconds]
Tazura2 has joined #yocto
Tazura3 has joined #yocto
Tazura has quit [Ping timeout: 264 seconds]
Tazura2 has quit [Ping timeout: 272 seconds]
goliath has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
Dorinda has quit [Quit: Ping timeout (120 seconds)]
MrKaKe has joined #yocto
MrKaKe is now known as bjobjo
pbergin has quit [Quit: Leaving]
dti has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
bjobjo has quit [Quit: Reconnecting]
bjobjo has joined #yocto
bjobjo has quit [Client Quit]
bjobjo has joined #yocto
bjobjo has quit [Changing host]
bjobjo has joined #yocto
bluelightning has quit [Quit: Konversation terminated!!!111]
kpo has joined #yocto
pbaptista has joined #yocto
chrfle has joined #yocto
hpsy has joined #yocto
pbaptista has quit [Quit: Client closed]
Dorinda has joined #yocto
paulg has joined #yocto
rpcme has joined #yocto
barath has joined #yocto
<barath> hi, would anyone know if there's any documentation on how package specific variants of global variables like for instance INCOMPATIBLE_LICENSE and INCOMPATIBLE_LICENSE_pn-<packagename> are handled?
Tazura3 is now known as Tazura
Dorinda has quit [Ping timeout: 250 seconds]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
marc1 has joined #yocto
ecdhe has quit [Ping timeout: 272 seconds]
pbaptista has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
chrfle has quit [Ping timeout: 245 seconds]
sakoman has joined #yocto
tnovotny has quit [Quit: Leaving]
ilunev has quit [Quit: Textual IRC Client: www.textualapp.com]
troth has quit [Quit: Leaving]
roussinm has joined #yocto
roussinm has quit [Client Quit]
roussinm has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
vmeson has joined #yocto
pbaptista has quit [Ping timeout: 250 seconds]
chrfle has joined #yocto
ecdhe has joined #yocto
davidinux has joined #yocto
shoragan[m] has quit [Quit: node-irc says goodbye]
barath has quit [Quit: node-irc says goodbye]
jordemort has quit [Quit: node-irc says goodbye]
Emantor[m] has quit [Quit: node-irc says goodbye]
Andrei[m] has quit [Quit: node-irc says goodbye]
khem has quit [Quit: node-irc says goodbye]
kayterina[m] has quit [Quit: node-irc says goodbye]
ejoerns[m] has quit [Quit: node-irc says goodbye]
Jari[m] has quit [Quit: node-irc says goodbye]
shoragan|m has quit [Quit: node-irc says goodbye]
AlessandroTaglia has quit [Quit: node-irc says goodbye]
alex88[m] has quit [Quit: node-irc says goodbye]
ndec[m] has quit [Quit: node-irc says goodbye]
cody has quit [Quit: node-irc says goodbye]
Saur[m] has quit [Quit: node-irc says goodbye]
kayterina[m] has joined #yocto
Andrei[m] has joined #yocto
jordemort has joined #yocto
khem has joined #yocto
Emantor[m] has joined #yocto
Jari[m] has joined #yocto
Saur[m] has joined #yocto
ndec[m] has joined #yocto
shoragan[m] has joined #yocto
shoragan|m has joined #yocto
ejoerns[m] has joined #yocto
barath has joined #yocto
alex88[m] has joined #yocto
AlessandroTaglia has joined #yocto
cody has joined #yocto
pidge has joined #yocto
chrfle has quit [Ping timeout: 245 seconds]
pidge has quit [Quit: Leaving]
pidge has joined #yocto
pidge_ has joined #yocto
pidge_ has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
<smurray> RP: someone pointed out to me that the kernel's SPDX isn't pure "GPLv2", but has the syscall exception. Their concern is the latter isn't reflected in LICENSE...thoughts?
Guest28 has joined #yocto
<Guest28> Hey everyone. Trying to setup a docker container for yocto and cnat get bitbake to work. Would anyone help me out a little? Happy to share my Dockerfile
yates has quit [Ping timeout: 245 seconds]
<khem> smurray: yeah I think we should update the license field
<smurray> khem: it doesn't seem entirely obvious to me how to proceed, in the kernel tree COPYING points at other files (LICENSES/prefered/{GPL-2.0,Linux-syscall-note}), what would we want to use as a e.g. GPL-2.0-with-Linux-syscall-note or the like?
<smurray> khem: just the kernel COPYING file, maybe, and LIC_FILES_CHKSUM points at all 3 files?
<khem> smurray: I think SPDX identifier is Linux-syscall-note
<khem> so "GPL-2.0 && Linux-syscall-note"
<smurray> and a copy of Linux-syscall-note needs to end up COMMON_LICENSE_DIR?
vmeson has quit [Quit: Konversation terminated!]
<khem> right
vmeson has joined #yocto
<smurray> khem: one wrinkle is && does not map to SPDX's "WITH", which indicates an exception
janvermaete[m] has joined #yocto
Guest3846 has joined #yocto
<RP> smurray: shouldn't it be GPL-2.0 && GPL-2.0-with-syscall-exception ?
<smurray> RP: heh, I've no idea, that's why I asked
<RP> smurray: I think it should be the above. We may have to add a license file for the syscall-exception as we don't have one currently that I an spot
Guest28 has quit [Quit: Connection closed]
<smurray> RP: what goes in GPL-2.0-with-syscall-exception, exactly? The combined file does not exist in the kernel tree anymore, they're split out under LICENSES/*
<RP> smurray: a copy of that license
<smurray> RP: the issue is that doesn't exist in combined form in the current kernel tree, though, the exception lives on its own in LICENSES/exceptions/Linux-syscall-note, it's literally just the 1 paragraph from Linus
<RP> smurray: looks like https://spdx.org/licenses/Linux-syscall-note.html maybe which gives the correct SPDX name
<smurray> RP: okay, so that bit on its own w/o the rest of the GPL is okay to call GPL-2.0-with-syscall-exception?
<RP> smurray: we should say "GPLv2 && Linux-syscall-note"
<RP> and then add a Linux-syscall-note file to the licenses directory
kpo has quit [Read error: Connection reset by peer]
<smurray> RP: as I mentioned above, && means "and", not "with", so if you generate SPDX from LICENSE you're not going to get something that matches what's in the kernel...
kpo has joined #yocto
<RP> smurray: as I see it, that means that some code is under GPLv2 and some under the syscall exception which I think is ok?
<JPEW> You lose the SPDX WITH and there is no way to recover it
<smurray> RP: the top-level COPYNG file says: SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
<smurray> i.e. all of the code is GPL-2.0 plus that exception bit
<RP> smurray: The only mapping we have for that into our license field is with &&, meaning some of the code (the headers) are usable under the syscall note
<RP> I'm not claiming it is ideal, I'm claiming it is as close as we can currently get
<RP> and it is logically correct from the way the code works. WIll it generate perfect SPDX docs? No.
<smurray> RP: okay. I'm only bringing this up as someone at a customer asked wrt their internal reviews and LICENSE
<JPEW> We could add GPL-with-syscall and add a line to SPDXLICENSEMAP to make it map correctly
<RP> JPEW: that won't help for this problem as that isn't how SPDXLICENSEMAP works
<smurray> my concern this suggests a lot of pain to be able to do anything like useful SPDX from LICENSE fields
<smurray> err, concern is
<JPEW> RP: what is it for then?
<RP> JPEW: that mapping is to be able to translate OE specific license names into SPDX ones, e.g. GPLv2 -> GPL-2.0
<RP> "GPL-2.0 WITH Linux-syscall-note" is *not* an SPDX license, its an SPDX license with a modifier
<RP> and in OE's usage of LICENSE, modifiers end up as separate && entries
<JPEW> Hmm, ok.
<RP> JPEW: it is confusing as some licenses with modifiers are licenses in their own right
<RP> I'd assumed this one was but it isn't
<JPEW> Right, and OE doesn't have A WITH equivalent
<JPEW> Or even the concept of a modifier?
<RP> JPEW: we just treat a modified license as a different license. You can see even the SPDX people are torn on that
<RP> smurray: I think the issue can be handled ok if it is && in the LICENSE field. We may need to list which licences are considered exceptions but that should let us handle most cases?
<kergoth> Sounds like it'd be an effective stopgap measure until we add support for a WITH operator
<smurray> RP: I'm okay with adding it for now, sure
<smurray> RP: next question, it'd apply to linux-libc-headers as well, I'm guessing?
<RP> smurray: yes, I actually checked that LICENSE that was setting
<RP> what license
<smurray> RP: should I try working up a patch, then?
<RP> smurray: please, we need to do something
<smurray> RP: okay, will do
<RP> smurray: it may generate some discussion but it is discussion we need to ave
<smurray> RP: I need to actually look at meta-doubleopen, I'm curious if there's some mapping being done for things like this
<RP> smurray: I suspect they just ignore our license info
<smurray> RP: yeah, I wasn't sure. I thought it was different from e.g. meta-codescanner in that it didn't run fossology, but I've not gone and looked at what it does yet
<RP> zeddii: Interestingly we did see qemuarm ptest timeouts for lttng-tools and also https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2199/steps/14/logs/stdio which is an rcu/udev issue on qemux86-64. It does look "better" than the other issues we've see though (prior to the change to base )
moto_timo[m] has joined #yocto
moto_timo[m] has left #yocto [#yocto]
<paulg> RP where is the "reail" error for that last link? As opposed to just a summary that says something failed.
<paulg> (i.e. rcu stall etc etc.)
<RP> paulg: scroll up from the bottom, its above the sumary
* paulg didn't know smurray was in the log. ;-)
<paulg> are those udev worker stalls always there, or only when thie rcu stall happens?
<RP> paulg: we've seen the udev issue without the rcu stall. It is rare
<smurray> paulg: lol, I disavow everything! ;)
<RP> paulg: the above are three bugs referencing it, one mentions rcu and udev in the title
* paulg clicks and reads
<RP> paulg: this could be a genuine load issue, looks like two tests failed at the same time with an rcu stall
<abelloni> my guess is that 14275 is a dup of 14184 ;)
<RP> abelloni: I was thinking that
<paulg> I'm assuming all these are under qemu....
<abelloni> (that was on my list for Thursday)
<RP> paulg: yes
<paulg> I reacall a ways back we had issues with udev -- because something it did was pathological and basically akin to a fork bomb.
<RP> paulg: what I don't understand is why these VMs totally crash, they should get CPU time and not completely die :(
<paulg> I would have to try and search that up, but this kinda brings back memories of that.
<paulg> yah 14273 ends in a sched while atomic which is not ideal, to say the least.
<RP> paulg: that could be rather like the suspected aufs/yaffs2 issue we've seen
<paulg> although at that point "rcu: rcu_preempt kthread starved for 21093 jiffies!" so basically you are foobar long b4 the SWA.
<RP> paulg: right, in our older bugs I think the rcu issue is a symptom and there is a deeper kernel issue. It usually never manages to print active tasks for example
<RP> this new one, I'm less sure, could really be a load problem but it still shouldn't crash :/
* RP heads to bed
<abelloni> I would'nt rule out that the SWA is due to dumpstack dumping the stack
<paulg> agreed
<paulg> ideally it shouldn't eat itself doing that, but one is definitely off the beaten path when barfing out a splat; and printk just keeps getting more complicated and complicated. :-(
<paulg> ^ <-------------- been saving that in my "might need that someday" toolkit for a while now.
<abelloni> I wouldn't worry about the SWA, it is definitively the RCU thread not being scheduled for 21s that is an issue
<paulg> https://www.suse.com/support/kb/doc/?id=000019156 <----- limits the udev forkbomb factor
<paulg> if one continues down that thread of thought, then it is as if udev is getting carpet-bombed with events and thinking it needs a zillion workers?
<paulg> changing the udev log level from info to debug might be interesting, if it doesn't completely flood itself and get overwhelmed worse.
<paulg> still looking for the concrete case info for which it went ape-shit some 8-12y ago(?) Kinda makes for a largish search window. :-/
<smurray> udev is quite the forkbomb on startup iirc from my go at debugging the weird intermittent serial console failures a couple of years back
Guest28 has joined #yocto
<paulg> ISTR that it was the slow turds that were dying back 10 odd yrs ago - like ARM versatile or MIPS malta type cruft that got run circles around by a 2010 vintage smartphone.
<paulg> zeddii, that ring a bell for you?
<paulg> so a qemu starved for cycles might be a similar emulation of a gutless turd with the power of a 1995 pocket calculator.
<paulg> I'm thinking there was no real sane backoff algo either, so once you got to the edge, over you went like a flock of lemmings.
<paulg> anyway --- all based on cobweb infested faint memories of a time long ago.
Guest3846 has quit [Quit: Client closed]
mccc has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
gsalazar has quit [Ping timeout: 264 seconds]
Pierre-jeanTexie has joined #yocto
Guest7133 has joined #yocto
Guest7133 has quit [Client Quit]
Guest52 has joined #yocto
Guest52 has quit [Client Quit]
Guest28 has quit [Quit: Connection closed]