<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]
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
<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
<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>
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>
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.