<RP>
moto-timo: issues like that are a pain. I've been having brakes issues :(
<moto-timo>
RP: indeed... didn't help that the repair shop was closed which I didn't know until after the tow
<moto-timo>
RP: meanwhile attempting to get python packaging into state that can be sent to ML :/
<RP>
moto-timo: I had a hot binding brake caliper. After the garage serviced it, I had a smoking hot brake caliper, they added grease to generate smoke :)
<moto-timo>
RP: "helpful"
<RP>
moto-timo: I thought so. Ended up fixing it myself :/
<RP>
moto-timo: are the python changes near ready?
<moto-timo>
RP: close... but setuptools-scm is being wonky
<moto-timo>
RP: I am just about ready to finish the commit (for now) and push and send a email
<RP>
moto-timo: ok, cool
sakoman has quit [Quit: Leaving.]
tangofoxtrot has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 256 seconds]
tangofoxtrot has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
jclsn7 has quit [Ping timeout: 256 seconds]
<moto-timo>
RP: sent such as it is... I wish I hadn't lost yesterday
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
camus has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
<moto-timo>
RP: at least 20 tasks failed when building anything that inherited setuptools3, so more work to be done
sakoman has joined #yocto
jclsn7 has joined #yocto
xmn has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
Vonter has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
<kergoth>
zyga[m]: presumably someone could write type stubs for it and maintain them separately ala typeshed, yeah?
jclsn7 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 has joined #yocto
camus1 is now known as camus
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn73 has joined #yocto
amitk has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakoman has quit [Quit: Leaving.]
<moto-timo>
RP: more fixes on top of the series pushed to the branch. The rest will have to wait for sleep.
wooosaii has joined #yocto
wooosaiii has quit [Ping timeout: 240 seconds]
wooosaiiii has quit [Ping timeout: 250 seconds]
toastloop has joined #yocto
wooosaiiii has joined #yocto
huseyinkozan has joined #yocto
mrybczyn has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
michalkotyla has quit [Ping timeout: 256 seconds]
michalkotyla has joined #yocto
rob_w has joined #yocto
michalkotyla has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
m4ho has quit [Quit: WeeChat 3.3]
goliath has quit [Quit: SIGSEGV]
GNUmoon has joined #yocto
thierryE[m] has joined #yocto
mvlad has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
thierryE has left #yocto [#yocto]
lowfi has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
lucaceresoli has joined #yocto
leon-anavi has joined #yocto
frieder has joined #yocto
rfuentess has joined #yocto
goliath has joined #yocto
ziga_ has quit [Remote host closed the connection]
ederibaucourt has joined #yocto
gsalazar has joined #yocto
ederibaucourt has left #yocto [#yocto]
ederibaucourt has joined #yocto
ederibaucourt has quit [Client Quit]
AKN has joined #yocto
<AKN>
Hi Everyone
<AKN>
How to load brcmfmac driver & firmware in yocto
xmn has quit [Quit: ZZZzzz…]
<zyga[m]>
kergoth: good morning, I don't know, I only ever added type information directly
rob_w has quit [Remote host closed the connection]
<jclsn[m]>
Morning, my bitbake suddenly hangs at 0% when parsing recipes. I think this happened after I force-quit a bitbake session by closing the terminal. Is there maybe a lockfilepresent or something?
<jclsn[m]>
* Morning, my bitbake suddenly hangs at 0% when parsing recipes. I think this happened after I force-quit a bitbake session by closing the terminal. Is there maybe a lockfile present or something?
frieder has quit [Read error: Connection reset by peer]
<jmlemetayer[m]>
Hi folks, I noticed that the access to the server http://downloads.yoctoproject.org/ was very slow this morning. Is this normal?
<jmlemetayer[m]>
More than 1 min from 2 places (my work and my ovh server).
raghavgururajan has quit [Ping timeout: 240 seconds]
raghavgururajan has joined #yocto
florian has joined #yocto
jclsn73 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #yocto
vladest has quit [Quit: vladest]
frieder has quit [Ping timeout: 272 seconds]
frieder has joined #yocto
toastloop has left #yocto [Leaving]
oobitots has joined #yocto
vladest has joined #yocto
olani has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
lowfi has quit [Quit: Leaving]
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
AKN_R has joined #yocto
AKN has quit [Ping timeout: 250 seconds]
olani has quit [Ping timeout: 240 seconds]
manuel1985 has quit [Ping timeout: 240 seconds]
<Saur[m]>
RP: Now that you have changed OE-Core to only uses SPDX-licenses, should we consider dropping SPDXLICENSEMAP as well, or is that too soon? Since this is a simple one-to-one conversion and there now is a script to do the job, it seems reasonable to ask layer maintainers to do likewise (and it should be a lot simpler than the variable renames). Otherwise we will have to fight a never ending battle to prevent non-SPDX-license names to creep back in.
<rburton>
agreed
<rburton>
slash and burn!
manuel1985 has joined #yocto
<kanavin>
Saur[m], it's easier just to send a patch ;)
<kanavin>
no need to ask RP's permission for everything on your mind ;)
<Saur[m]>
kanavin: Well, our network is currently down at work, so right now all I can to is chat... ;)
<kanavin>
Saur[m], if you can chat your network is not down ;)
<Saur[m]>
I'm at home... ;)
<kanavin>
you don't need a corporate network to make oe-core patches :)
<kanavin>
in fact, I would see it as a blessing and would want it to stay down for the rest of the week or something
<Saur[m]>
But I don't have any OE environments or build machines at home.
pgowda_ has joined #yocto
Schlumpf has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
Qorin has joined #yocto
xmn has joined #yocto
mrybczyn has quit [Quit: Client closed]
huseyinkozan has quit [Quit: Konversation terminated!]
Qorin has quit [Ping timeout: 272 seconds]
<RP>
Saur[m]: I think it will probably have to stay for the LTS but in master in the next cycle we should be able to remove it
<RP>
Saur[m]: I'm worried about how many layers will convert given the timescales. There is also the issue no warning is given to encourage anyone to migrate
<Saur[m]>
Hmm, ok. I would think it would be easier to convert the license names than, e.g., rename variables. As all the needed licenses are in Honister there is an upgrade path already. Anyway, I will prepare the patch and you can consider it and then either take it, or put it in the pile for post-kirkstone changes (AKA ask me to resend the patch once kirkstone is out).
mrybczyn has joined #yocto
alessioigor has joined #yocto
<RP>
Saur[m]: the issue is that people expect a certain amount of time and to see warnings about changes :/
<RP>
If we don't do that, it creates a different kind of usability issue :/
<Saur[m]>
RP: Fair enough.
<RP>
Saur[m]: I've wanted to do this for ages, I've talked about it regularly in the calls. Nobody did it, I found time myself as I really wanted to see it happen for core
alessioigor has quit [Quit: alessioigor]
<RP>
Saur[m]: I think we're just too late to go too much further though :(
<Saur[m]>
I understand. I'll prepare it, and postpone it for post-kirkstone.
oobitots has quit [Quit: Client closed]
sakoman has joined #yocto
<RP>
Saur[m]: we can see what people think, I just worry about late changes
Thorn has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
Schlumpf has joined #yocto
jmiehe has joined #yocto
frieder has quit [Ping timeout: 256 seconds]
mrybczyn has quit [Quit: Client closed]
mrybczyn has joined #yocto
AKN_R has quit [Read error: Connection reset by peer]
Schlumpf has quit [Quit: Client closed]
oobitots has joined #yocto
<moto-timo>
RP: I think most of the failures are from ‘meson’… wheels seem to only be installing into ${PYTHON_SITEPACKAGES_DIR}/bin but that isn’t in PATH
<RP>
moto-timo: I doubt we know to look there in general code :/
<moto-timo>
RP: plus the errors I already mentioned about [shebang-size], which I don’t understand
<RP>
moto-timo: maybe we just postprocess the install step with symlinks from bindir for our tools?
<moto-timo>
RP: that or symlinks is what I was thinking?
<moto-timo>
RP: I don’t think I have a swatbot account so I can’t read the link
<moto-timo>
RP: but I was able to see things under “Failed Builds”
<RP>
moto-timo: right, I was thinking some of the links there should work in swatbot but wasn't sure which
gsalazar has quit [Ping timeout: 240 seconds]
<moto-timo>
RP: do you have any ideas about [shebang-size]? That seems just wrong…
<RP>
moto-timo: I haven't looked at it at all, sorry
gsalazar__ has joined #yocto
gsalazar_ has quit [Ping timeout: 272 seconds]
Schlumpf has joined #yocto
gsalazar_ has joined #yocto
<RP>
Saur[m]: I think I have a lead on your logging issue. I think the difference in behaviour is the event.logfile parameter printed by knotty.py. When the function calls are wrapped, that is missing
<manuel1985>
If several recipes RPROVIDE the same virtual package, what happens if I don't set a PREFERRED_RPROVIDER?
gsalazar__ has quit [Ping timeout: 256 seconds]
<rburton>
PROVIDE, you mean
<rburton>
?
<RP>
manuel1985: if you're in the runtime space, you shouldn't be using virtuals so as rburton says, do you mean PROVIDE or RPROVIDE ?
<manuel1985>
rburton, RP: I actually mean RPROVIDE. Just reviewing a collegues PR. What's bad about using RPROVIDES?
<smurray>
manuel1985: from my experience using RPROVIDES for e.g. conf file packages, it boils down to dnf picking one from the feed semi-randomly if you are not explicit
<manuel1985>
We'd use it to select either the development or the production config for another package on the image.
<manuel1985>
smurray: Thanks.
<RP>
manuel1985: it is as smurray says, a really bad idea
<manuel1985>
but if I set a PREFERRED_PRPROVIDER I'm okay I guess?
<moto-timo>
RP: stoopid oversight... didn't pass --prefix to pip install
<manuel1985>
smurray: Or are you saying PREFERRED_RPROVIDER doesn't work?
<RP>
manuel1985: I've posted about this before on the mailing lists. It works but it can't influence the package managers
<qschulz>
manuel1985: are those config packages installed in the image "manualy" or part of the RDEPENDS of some other package?
<smurray>
manuel1985: I've still not figured out what the mentions of it in bitbake are actually for. It definitely does not work the way you might think it would
<RP>
so they can do something random
<manuel1985>
qschulz: They are installed due to the other packages RDEPENDing on them
<RP>
My advice is stay away from virtual RPROVIDES. If you want more details try and find the mailing list posts I've made before
<manuel1985>
RP: Okay, will go look for it. Thx.
<smurray>
RP: I think the thing that threw me off when I first poked around was seeing it used in lib/bb/providers.py, and it not being hugely obvious to me how that logic intersects (or not) with the package manager
<RP>
smurray: I never really wanted it at all but there was some use case which forced it a while back :/
<smurray>
manuel1985: another approach to consider might be alternatives, if you can wrangle priorities for the different versions so update-alternatives does what you want
<RP>
Saur[m]: I have a fix for the logging issue. It is nice and simple
olani has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
mrybczyn has quit [Quit: Client closed]
<manuel1985>
RP: Are you Richard Purdie?
goliath has quit [Quit: SIGSEGV]
<RP>
manuel1985: I am
osama has joined #yocto
<rburton>
i wonder why, six years ago, we decided that poky-tiny had to write cpio.gz images
Tokamak has joined #yocto
gpanders has left #yocto [#yocto]
<RP>
rburton: hmm. Who did it?
<RP>
Saur[m]: patch on the list, hopefully solves your problem
osama1 has joined #yocto
osama has quit [Ping timeout: 256 seconds]
<rburton>
RP: can I ask for "kernel: make kernel-base recommend kernel-image, not depend" to be merged?
<RP>
Saur[m]: I've posted patches so let me know if it works for you
<RP>
rburton: I meant to, not sure what happened
<rburton>
i'll let you off :)
<RP>
rburton: queued so it will be in the next round of testing
<rburton>
thanks
fleg has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
raghavgururajan has joined #yocto
fleg has joined #yocto
<rburton>
RP: re poky-tiny, you, sortof, but the initial commit set IMAGE_FSTYPES explicitly to ext2 cpio.gz
<RP>
rburton: I think the thought was that ext2 wasn't useful
<rburton>
when you removed it, the kernel didn't build the ext2 module
<rburton>
do we testimage poky-tiny at all?
<RP>
sure, but is an ext2 image actually useful for tiny?
<RP>
rburton: I worry that we don't
<rburton>
ext2 is as useful as cpio.gz
<rburton>
its a file system
<RP>
but cpio works with standard tools and is small
<RP>
ext2 doesn't and isn't
<RP>
rburton: if you have a use for ext2...
<rburton>
our use of poky-tiny is a wic image which contains a ext4
<rburton>
but we're trying to testimage it and poky-tiny is breaking that too
<RP>
why would a tiny system want a journal?
<rburton>
tinyish
<rburton>
and i suspect the fs is created without a journal
<qschulz>
poky-small
<RP>
I suspect tiny should generate a tarball and let wic do whatever with it
<rburton>
i lie, its a wic with a raw copy of a initramfs
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #yocto
olani has quit [Ping timeout: 272 seconds]
rfuentess has quit [Remote host closed the connection]
ecdhe_ has joined #yocto
<RP>
moto-timo: I probably need to try another build run. What should I do with the python patches?
<RP>
drop all, drop some, wait a bit longer?
<moto-timo>
RP: I only have 13 errors left... trying to get it done ASAP
<moto-timo>
RP: but you might want to drop all for now and we can try v2 later?
osama2 has joined #yocto
ecdhe has quit [Ping timeout: 256 seconds]
<RP>
moto-timo: ok
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
osama1 has quit [Ping timeout: 256 seconds]
pasherring has joined #yocto
mrybczyn has joined #yocto
<Saur[m]>
RP: I looked at the patch and I am very happy you looked at the problem, because I am pretty sure I would never have figured out such a simple solution. I will try it out as soon as I can, but I am currently a bit handicapped by not being able to access my computers at work.
florian_kc has joined #yocto
fleg has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
osama2 has quit [Ping timeout: 256 seconds]
fleg has joined #yocto
raghavgururajan has joined #yocto
mrybczyn32 has joined #yocto
mrybczyn32 has quit [Client Quit]
Schlumpf has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 256 seconds]
<moto-timo>
python3-nose still has python2 syntax code in it an fails to compile... ARGH
goliath has joined #yocto
mckoan is now known as mckoan|away
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<RP>
rburton: you had to send patches which clash with -next didn't you?! :)
<rburton>
ha sorry
<rburton>
i can rebase
<moto-timo>
I don't see anything in oe-core depending on python3-nose...?
<RP>
rburton: I've sorted since it wasn't hard. Just annoying!
<RP>
We have a fix for (c) on the inclusive language list so I think we're down to one issue "blocking" merge. I'm tempted to merge the -next branches...
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
olani has joined #yocto
<moto-timo>
RP: series v2 sent... I saw no errors in building everything in meta that inherits setuptools3-base
<moto-timo>
RP: for qemux86_64 that is
* moto-timo
crossing fingers for better outcome
<RP>
moto-timo: thanks, I'll give it a go
camus has quit [Remote host closed the connection]
camus has joined #yocto
<RP>
khem: there is an OE TSC meeting in 30 mins. We need to talk about github so not sure if you're around/available?
Vonter has quit [Ping timeout: 240 seconds]
<RP>
moto-timo: build away...
leon-anavi has quit [Quit: Leaving]
<moto-timo>
RP: I'm watching it. Thank you.
florian_kc has joined #yocto
<Saur[m]>
RP: I tried the logging change. It seems to work. It is so much better to see the log of what caused the failure. :)
<RP>
Saur[m]: good. That is why I wanted to get it fixed
<moto-timo>
RP: hmmm, buildtools failed because of dnf
<moto-timo>
might still be some gremlins in nativesdk
<Saur[m]>
RP: I assume it is too late to get it into 3.4.2?
<RP>
Saur[m]: since it is in QA, yes
<Saur[m]>
Thought so. Oh well, as long as it's fixed, I'm happy. :)
otavio has quit [Remote host closed the connection]
<moto-timo>
RP: yeah, some issues with python3-setuptools, pip in nativesdk :/
<sakoman>
moto-timo: yes, that does look lie the same issue :-( And sadly still not fixed
<moto-timo>
sakoman: k. I've been slammed with the PEP-517 wheels work but I will try
<sakoman>
moto-timo: should I take the CVE only patch and wait till a later date for the version bump (when it is fixed)?
<moto-timo>
sakoman: entirely up to you... depends on when you wanted to do the next bump
<RP>
moto-timo: still, it looks better than last time!
<moto-timo>
RP: some builds actually passed :)
<RP>
moto-timo: I wasn't going to put it quite that way, but yes :)
<sakoman>
moto-timo: well, the CVE fix is probably the highest priority and the version bump can wait till the ptest regression is figured out
<moto-timo>
sakoman: I agree, given the time contraints
<sakoman>
moto-timo: I will make it so
florian_kc has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
<sakoman>
moto-timo: I have a huge patch backlog to get tested and reviewed so I won't have time to work on it for a few days either
<RP>
sakoman: would you like to swap with mine? :)
<sakoman>
RP: not a chance ;-)
<RP>
sakoman: shame :)
otavio has joined #yocto
GNUmoon has joined #yocto
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
pasherring has quit [Client Quit]
pasherring has joined #yocto
<moto-timo>
RP: edgerouter also failed because of dnf... hmmm
<moto-timo>
ok so it's the python3-pkg-resources split that isn't working properly
Vonter has quit [Ping timeout: 256 seconds]
Thorn has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
Thorn has joined #yocto
<moto-timo>
RP: my car is ready at the shop so afk for a bit... I'll hammer on this more later but you might be zzzz by then
<RP>
moto-timo: np, thanks. I'll probably drop the set and then we can retest when ready
<moto-timo>
RP: yes, that is prudent
jmiehe has quit [Quit: jmiehe]
florian_kc has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
<RP>
disruptive changes pushed
Vonter has joined #yocto
<zeddii>
RP: dumb question. is there a way to see where a particular offending variable is set ? I can't do my normal bitbake -e on one that is popping up here.
<zeddii>
I'm grepping of course, and will find it eventually
<RP>
zeddii: it should be printing where it was set
<RP>
zeddii: if it isn't, it is obscure and I'm curious where