mrlemke has quit [Read error: Connection reset by peer]
mrlemke has joined #yocto
seninha has quit [Remote host closed the connection]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
amahnui1 has joined #yocto
Tokamak_ has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
seninha has joined #yocto
kevinrowland has quit [Quit: Client closed]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
BobPungartnik has joined #yocto
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #yocto
bps3 has joined #yocto
bps2 has quit [Ping timeout: 258 seconds]
seninha has quit [Remote host closed the connection]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
sakoman has joined #yocto
<moto-timo>
New setuptools will continue to cause pain. Python modules are just not paying attention.
<moto-timo>
Cull the recipes that fail to pay attention?
The_Pacifist has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
amahnui1 has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kroon has joined #yocto
sakoman has quit [Quit: Leaving.]
dtometzki has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
astlep has joined #yocto
pgowda_ has joined #yocto
kroon_ has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
kroon has quit [Ping timeout: 246 seconds]
kroon__ has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
kroon_ has quit [Ping timeout: 240 seconds]
mvlad has joined #yocto
goliath has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<mckoan>
good morning
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
locutusofborg_ has joined #yocto
Tokamak_ has joined #yocto
xmn_ has joined #yocto
Wouter0100 has quit [*.net *.split]
Tokamak has quit [*.net *.split]
xmn has quit [*.net *.split]
jpuhlman has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
ldericher has quit [*.net *.split]
LocutusOfBorg has quit [*.net *.split]
alex88 has quit [*.net *.split]
Shaun has quit [*.net *.split]
xantoz has quit [*.net *.split]
rob_w has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
tlwoerner_ has joined #yocto
alex88 has joined #yocto
jpuhlman has joined #yocto
Shaun has joined #yocto
xantoz has joined #yocto
ldericher has joined #yocto
Wouter0100 has joined #yocto
dev1990 has joined #yocto
<LetoThe2nd>
yo dudX
ptsneves has joined #yocto
gsalazar has joined #yocto
Schlumpf has joined #yocto
GNUmoon has quit [Remote host closed the connection]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
xmn_ has quit [Quit: ZZZzzz…]
manuel1985 has joined #yocto
GNUmoon has joined #yocto
bps3 has quit [Remote host closed the connection]
bps3 has joined #yocto
ardo has quit [Ping timeout: 255 seconds]
ardo has joined #yocto
Schiller has joined #yocto
DaGoEsd has joined #yocto
florian_kc has joined #yocto
<DaGoEsd>
Good morning! I have a problem with a poky distribution created by Yocto, on which depmod -a no longer works. It always creates an empty modules.dep. (The kernel modules are not compressed). Is this problem known and is there a solution for it?
<DaGoEsd>
Depmod comes from busybox and once worked in previous builds (earlier zeus, now kirkstone).
kroon_ has joined #yocto
kroon__ has quit [Ping timeout: 240 seconds]
locutusofborg_ is now known as locutusofborg
locutusofborg has quit [Changing host]
locutusofborg has joined #yocto
<ernstp>
mrybczyn[m]: I sent out my cve-check patches to the list now anyway, so they can be discussed
leon-anavi has joined #yocto
dvorkindmitry has joined #yocto
Juanosorio94 has joined #yocto
<Juanosorio94>
How can I patch my external kernel without using devtool?
<DaGoEsd>
Juanosorio94: locate the recipe from which your kernel is made, create an own layer, integrate this layer via your bblayers.conf and create a recipes-kernel/linux/<your_kernel_recipe>.bbappend file. Within this file you specify patches, using SRC_URI:append:<your_machine> = "file://yourpatch_1.patch file://yourpatch_2.patch"
<ptsneves>
DaGoEsd interesting i understood the question as external src kernel
<DaGoEsd>
ptsneves: Also for an external kernel there must be a recipe which can be extended with a .bbappend file.
<ptsneves>
DaGoEsd i was thinking not. If the externalsrc kernel is a git repository just patch the repository directly :) No bitbake necessary
<DaGoEsd>
ptsneves: If you have the necessary rights, this will also work.
BobPungartnik has quit [Quit: Leaving]
lexano has quit [Ping timeout: 244 seconds]
prabhakarlad has joined #yocto
<Juanosorio94>
ill try just patching it then
lexano has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
lexano has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
<Schiller>
RP: I still don't get the SingleBranch or AnyBranchScheduler to work. Can i post the Scheduler for more intel?
nemik has joined #yocto
lexano has joined #yocto
kroon_ has quit [Ping timeout: 240 seconds]
jpuhlman has quit [Ping timeout: 246 seconds]
jpuhlman has joined #yocto
GNUmoon has quit [Remote host closed the connection]
seninha has quit [Ping timeout: 260 seconds]
<rburton>
RP: nice!
pgowda_ has quit [Quit: Connection closed for inactivity]
GNUmoon has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
starblue has quit [Ping timeout: 240 seconds]
<RP>
Schiller: have you setup the code to monitor the repo to detect changes?
tre has joined #yocto
<ptsneves>
I am trying to write a self test for fit images due to request here https://bugzilla.yoctoproject.org/show_bug.cgi?id=12283. I see that the only self test we have is ./meta/lib/oeqa/selftest/cases/kerneldevelopment.py. Should I create a new case or extend kerneldevelopment.py?
starblue has joined #yocto
<RP>
rburton: I tweaked the css to thicken the line and remove the points
<rburton>
looks much better without the points
<RP>
ptsneves: depends how many tests and whether they fit in with the kerneldevelopemts tests or not
seninha has joined #yocto
<LetoThe2nd>
quick poll! what do think about a jester-style presentation about what actually happens during booting (target: ELC-E)
<ptsneves>
for now i just want to generate a fitImage and verify it's contents. They are not really related to kerneldevelopment, but just kernel plain and simple. Do we not have any tests for kernel function?
<LetoThe2nd>
(as opposed to the inevitable boot time optimization talks)
<rburton>
LetoThe2nd: could be interesting. starting with firmware?
<LetoThe2nd>
rburton: rom code to actual payload kernel. i'm imagining the theme to be "getting up in the morning"
<rburton>
what board?
florian_kc has quit [Read error: Connection reset by peer]
<LetoThe2nd>
no specific one, but probably showing a few variations from simple sama5d over imx or such to tegra.
florian_kc has joined #yocto
<Schiller>
RP: I only edited the yocto-docs-changed scheduler [codebases, builderNames, branch etc.]. Can you guide me to where the setup code for the yocto-docs-changes Scheduler is stated?
<RP>
rburton: still wondering about zoom and tootips, they can be useful I guess
<rburton>
yeah they're useful for poking in detail
<rburton>
would be nice if the short sha was visible in the tooltip, if there was spike you could know where to look
<LetoThe2nd>
rburton: pokyng in detail? (badum-tsh!)
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
<Schiller>
RP: Thanks a lot. That should solve the issue. I was reading about the GitPoller but couldn't find it. Now it makes sense.
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
kroon_ has joined #yocto
<qschulz>
LetoThe2nd: FYI, Bootlin has a slide or two in their cc-by-sa training material about different booting mechanisms (IIRC, Atmel boards, probably BBB and Marvell boards too?)
kroon__ has joined #yocto
bps3 has quit [Remote host closed the connection]
kroon_ has quit [Ping timeout: 258 seconds]
bps3 has joined #yocto
DaGoEsd has quit [Quit: Client closed]
kroon has joined #yocto
kroon__ has quit [Ping timeout: 246 seconds]
<Schiller>
RP: It still seems to not be working. Can you confirm my approach: in master.cfg i got Gitpoller(repourl='ssh://me@server:<path>' etc.) and in the schedulers.py i got the SingleScheduler and AnyScheduler setup. Then i just do a commit on given repo which should trigger a build correct or am I missing smth.
bps3 has quit [Remote host closed the connection]
bps3 has joined #yocto
<RP>
Schiller: it should work. Does the buildbot log on the controller show it poll the repo and see the change?
<JaMa>
FWIW: I think meta-handheld isn't compatible with any recent release (other than meta-handheld incorrectly claiming the compatiblity till honister) http://cgit.openembedded.org/meta-handheld/log/
<rburton>
yeah, there's also that :)
<RP>
JaMa: fair enough. I was just using it as a marker of where things had updated or hadn't :)
<Schiller>
RP: I think i was to impatient before. I checked the logs but didnt wait for the polling. Yeah there seems to be smth wrong. Ill try fix it then it should work thx.
<RP>
Schiller: since it polls it isn't instant
<RP>
Schiller: you can push updates with it but you need git server side config for that
rob_w has quit [Remote host closed the connection]
vladest has quit [Quit: vladest]
xmn has joined #yocto
<LetoThe2nd>
qschulz: thx
lexano has quit [Quit: Leaving]
lexano has joined #yocto
Tokamak_ has quit [Ping timeout: 244 seconds]
ramacassis[m] has joined #yocto
<sotaoverride>
how do i make sure a recipe is run before another, whats the RDEPENDS syntax or the best way of doing this?
Tokamak has joined #yocto
paulg has joined #yocto
<sotaoverride>
one recipe creates a directroy structure, other adds a systemd mount service to mount partions on the directory structure. I want to make sure the directory structure recipe is run before the systemd mount service recipe.
<LetoThe2nd>
yo go people! we're (supposedly) seeing the do_unpack stage cleaning out an EXTERNALSRC directory in a go based recipe. any pointers on what to look for? the externalsrc bbclass is beyond me, unfortunately.
<Juanosorio94>
I built an image using bitbake-core-image minimal, I found what appears to be an image for me inside the poky/build/tmp/deploy/images/machine but as I was flashing my sd card it said that it has no partition table and that it wont probably be able to boot from it, and surprise, it didnt :D am I looking at the wrong place, did the wrong bitbake
<Juanosorio94>
target, or is my process just misconfig"d?
<LetoThe2nd>
Juanosorio94: it depends on the type of image that you built/chose. ext4: no partitions, just a filesystem. tar.gz: only filesystem contents. wic: usually a kind of binary for direct usage on the sd card.
<Juanosorio94>
how do I find that out o.o
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<zeddii>
RP: I am now seeing that python3-six build failure repeating. I'll try and figure out what is different here than everywhere else.
Tokamak_ has joined #yocto
<zeddii>
urk. maybe this is slightly different ... I see python3-six-native, now that I'm drinking my coffee and after I typed that in.
nemik has quit [Ping timeout: 240 seconds]
<LetoThe2nd>
Juanosorio94: by looking at a) the deploy/machine/images directory, and b) the IMAGE_FSTYPES variable of your build
<ramacassis[m]>
(don't take my word for it, kinda new to Yocto)
<ramacassis[m]>
I guess you could do it with RDEPENDS, but otherwise the proposed syntax "do_compile[depends] = "my_first_recipe:do_deploy" looks good to me
Tokamak has joined #yocto
<LetoThe2nd>
zeddii: do you have any wisdom on go+externalsrc?
Tokamak_ has quit [Ping timeout: 244 seconds]
<zeddii>
that ... I have never tried. I imagine it will be tricky, you'd need -mod=vendor, or there will be fetching, and the placing of the bits in possibly some host directories.
<LetoThe2nd>
zeddii: go.bbclass coming in my way, i presume? or the go mechanisms per se?
<RP>
zeddii: hmm, not good but we haven't see that elsewhere :/
<zeddii>
some of both. if the go environment isn't fully set (but it should be), then go won't look for the source, or the dependencies in the right place.
<LetoThe2nd>
zeddii: hmhm.
<zeddii>
and other than that, if some tasks are inhibited for externalsrc, then go will happily go out and fetch things, and again, if the variables aren't set properly, could put them in the local go paths, (i.e. ~/.go, etc)
<ramacassis[m]>
Hello all, the project I am working on uses plenty of "volatiles" files. They are later put in /etc/default/volatiles so that the OE script "populate-volatile.sh" can process the rules.
<ramacassis[m]>
The script verifies/creates a directory, a file or a symlink. But I don't see documentation about it in the manual.
<ramacassis[m]>
Is that the preferred way to handle the creation of symlinks on the target ?
<zeddii>
RP: it is likely just the same root cause of my old sysroot, I should have noticed the -native (although, i did do a cleanall on it yesterday .. so that should have take care of it)
<RP>
rburton, mrybczyn[m]: Do you think we should add the json cve pieces to honister so it can generate CVE numbers on the AB?
<RP>
zeddii: ah, right
<zeddii>
after the destruction in Ottawa over the weekend, I'm not thinking straight yet
<zeddii>
but electricity is nice!
<RP>
zeddii: hope everything is ok. We had a dose of that at the end of last year
<RP>
house next door still isn't fixed
<zeddii>
tornado level winds, but almost as wide as the city. Was quite 'impressive'
<zeddii>
I think I read 1300 snapped power poles (everything is buried where I live though)
<RP>
zeddii: not good. Sounds quite familiar, damage was a bit wider spread here
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<zeddii>
only 24 hours without power here, but there are parts of the city they hope will be restored by friday and some a bit longer, so all in all ... ok for me, but not for others.
<RP>
zeddii: I didn't lose power thankfully but there were a lot of places like that here, some for a few weeks.
<RP>
zeddii: in one case they put new poles up along a road, only for the next storm to come in and knock them all over again
<RP>
we had three nasty ones in a short period
<zeddii>
ouch. just something to look forward to as the storms intensify. these didn't really happen here when I arrived 20 years ago.
<zeddii>
now we are tornado alley north
<Guest87>
how should i go about troubleshooting a bitbake crash when using toaster? here is a paste of the error I am seeing https://pastebin.com/6y7q4cWm
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<RP>
Guest87: when it has a "handledexception" like that it means that bitbake thinks it printed an error message for the user. Clearly there wasn't one :(
<RP>
Guest87: anything under the files in tmp/log/ ?
<RP>
zeddii: I remember a storm like that one when I was about 7. Plenty of time for trees to get old/weaker since then ready for that storm though (and bits of my house to rust ready to fail under pressure)
<Guest87>
RP: nothing recent enough to be relevant (everything is 5+ days old)
Tokamak has quit [Ping timeout: 250 seconds]
Tokamak_ has joined #yocto
<Schiller>
RP: Can you give me some more insides about what i am doing wrong? In logs I find after a commit <change contains codebase that is not processed by scheduler AnyBranch-...> even tho in codebasis i did set the repo. And what is the codebases ['',] for? When i include i don't get the log error, but then it seems to try to set the
<Schiller>
yocto-auto-helper repo branch of the commit.
<RP>
Schiller: did you give the project a name in the change_source and refer to it with that name in the scheduler?
<JaMa>
sakoman: thanks, I'm still bisecting gcc to find out what else I need to fix some strange build failures in gtest templating
<Schiller>
RP: Yes i did fill out the <porject> variable.
bps3 has quit [Ping timeout: 240 seconds]
<Schiller>
RP: I only get the log error when i miss the <''> in codebases. Idk why it is necessary. But then still it throws an error when Fetching the auto-helper.
<Guest87>
anybody have success/tried running toaster in wsl2?
<Schiller>
RP: Also the "yocto-docs-changed" Scheduler doesn't use <properties>. I customized the whole scripts heavily. Where does he get his build-infos from?
zwelch has quit [Quit: Leaving]
zwelch has joined #yocto
florian has quit [Quit: Ex-Chat]
<qschulz>
RP: mrybczyn[m]: rburton: nice graphs for the CVEs!
<qschulz>
i'm missing some info though... what's the actual setup used? basically which layers are reported in those graphs?
<qschulz>
RP: thank you very much. I could have sent a patch indeed sorry.
<rburton>
qschulz: the underlying tools work on all layers, i run the patch review scripts on meta-arm occasionally
<rburton>
running it on meta-oe would be... interesting
<RP>
rburton: we have options now...
<RP>
landgraf: I like the look of that fetcher patch, thanks! Do we need any extra tests?
Tokamak has quit [Ping timeout: 244 seconds]
mrlemke has left #yocto [Leaving]
Tokamak has joined #yocto
<yudjinn[m]>
whats the best process to upgrading a project from zeus to dunfell?
<zwelch>
yudjinn[m]: switch all of your repos over to the dunfell branches and fix what breaks? :) Some migration issues will be documented in the release notes, but i have found most of my pain comes from my own layers' deficiencies.
<JaMa>
and in ideal world I would recommend preparing for this incrementally, e.g. now we don't have any plans to upgrade after kirkstone, but building our layers with oe-core/master shortly after gcc-12 was merged allows to quite easily fix the issues caused by gcc-12 itself, while next time bunch of other recipes were broken by boost upgrade and so on
<zwelch>
I am currently migrating a target from dunfell to kirkstone, and i wrote that generates the required patch series for me. That way, I have been able to continue working on dunfell, deferring the creation of a forking branch. As I started my migration well before the official release, that saved me a lot of effort of maintaining parallel branches that would have lots of merge conflicts (caused by the new override syntax).
<JaMa>
LTS releases are great, but trying to figure out what broke your components during the 2 years in between is much more work than doing small incremental steps every few weeks
<zwelch>
s/wrote/wrote a script/
ptsneves has quit [Ping timeout: 252 seconds]
<zwelch>
and i agree with JaMa, jumps between LTS are painful... I'm hoping to move our targets onto each successive release as they come out.
<JaMa>
I'm just rebasing my branches on top of dunfell (until the product switches from dunfell to kirkstone)
<zwelch>
(also because i hope to start contributing upstream more, which effectively requires tracking the master branches anyway)
<JaMa>
that way I can continually push backwards compatible changes to product (including overrides syntax changes)
<zwelch>
(when i started my script, i hadn't realized that the new override syntax was supported in dunfell)
<JaMa>
unfortunately too many people still haven't realized that even today
<RP>
zeddii: are you crazy busy? I have a thorny topic I'm not sure I dare mention
<zeddii>
I'm heading to the airport (assuming I can get there) later today, so now is as good a time as any, since i'll be offline for a few days after this.
<LetoThe2nd>
RP: i dare!
<LetoThe2nd>
zeddii: where can i get free beer?
<qschulz>
LetoThe2nd: by sending a patch :D ?
<LetoThe2nd>
qschulz: that is ethically unacceptable!
<RP>
zeddii: I accidentally enabled CVE checking for linux-yocto and was having a panic attack at the number of CVEs in master. I'm basically wondering what we do with them
<JaMa>
zeddii is giving beer for meta-virt patches? I hope I'll be drunk soon :)
<RP>
zeddii: I'm seriously wondering about adding them to the default exclusions list so we have a clean slate and then worry about the new ones?
<RP>
zeddii: I was wondering if you have any plans/thoughts
<zeddii>
that's as good a plan as any. for the kernel, we really don't want to get into doing anything much more than comes via -stable. so knowing about them is good, but doing too much about them is hard.
<RP>
zeddii: I'm asking now while I'm looking at the hardcoded "ignore" in a script
<zeddii>
since there are teams at the OSVs that handle them, it can take a long time to deal with them.
<RP>
zeddii: agreed. I'll see if I can come up with a patch and see what people make of it
<RP>
rburton, mrybczyn[m]: ok with you?
<zeddii>
RP: and of course, I'll do what I can with them. just no SLA implied :)
<rburton>
the kernel cves are "interesting"
<rburton>
so yeah
<RP>
zeddii: the same as the rest of OE-Core! ;-)
<RP>
zeddii: I just don't think we can continue this blanket "ignore it", much as I'd like to
<zeddii>
as long as it won't be something that blocks a release, because you'll never get a CVE free kernel :)
<RP>
zeddii: nothing in the release process gates on this, it is just a guide
<zeddii>
and -stable quite honestly, doesn't get them all nominated, and if the backport is even slightly non-obvious, it doesn't happen either.
<zeddii>
ack'd
<RP>
zeddii: quick other question - how much of a pain is the edgerouter bsp code?
<zeddii>
it's mainline, we don't have any patches, just config.
<RP>
zeddii: ok, cool. That is good to know
* RP
is wondering about cleanup of older stuff and where to concentrate effort
<rburton>
the recipe clearly inherits python_flit_core which clearly DEPENDS python3-flit-core-native which provides that class
<rburton>
so, weird.
<rburton>
try deleting tmp/ and trying again?
<sielicki>
probably something on my end, yeah.
<sielicki>
that's what I was thinking too -- that recipe isn't doing anything complicated, something deeply wrong.
<rburton>
if it happens with a clean poky i'm very curious so maybe the sysroots got messed up
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<RP>
zeddii, rburton: cve patch of doom sent
<RP>
gah, with the wrong syntax :(
<RP>
my local config is messed up :(
gsalazar has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<zeddii>
hah.
* RP
has sent a v2
gsalazar has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
mckoan is now known as mckoan|away
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
<mrybczyn[m]>
RP: i don't use the exclusion file, doing own analysis. So the patch is neutral in my case
<landgraf>
RP: Only tests from previous version. I've not resent them because nothing changed
<landgraf>
FetchPremirroronlyLocalTest - this
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
gsalazar has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
kevinrowland has joined #yocto
<RP>
landgraf: ok, that wasn't clear but makes sense! :)
<RP>
JaMa: you're working around the bug for makedevs now? :)
<JaMa>
and devmem2 as well, but then still plan to figure out how to fix it properly (or at least why it happens only recenly)
<JaMa>
tlwoerner_: your patch just changed the error message, because the file COPYING was already created during previous do_patch, so to properly cleanup you would really need to wipe whole WORKDIR
<JaMa>
tlwoerner_: removing the files listed in SRC_URI would be easy, but removing also files created by .patch files might be too fragile to even support this
<yudjinn[m]>
so I'm trying to move a project from zeus to dunfell, and it uses tegra. I
<yudjinn[m]>
I'm getting an error of `MACHINE=jetson-xavier is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.`
kevinrowland has quit [Quit: Client closed]
tlwoerner_ has quit [Quit: Leaving]
<zwelch>
yudjinn[m]: machine names change from time to time.... check meta-tegra/conf/machines/
tlwoerner has joined #yocto
<tlwoerner>
JaMa: oh right, that "patch" :-)
<yudjinn[m]>
thanks! that should get me further down the road
seninha has quit [Ping timeout: 244 seconds]
prabhakarlad has quit [Quit: Client closed]
<JaMa>
JPEW: can you recommend a tool/script which would allow to easily query GENERATED_FROM in tmp-glibc/deploy/spdx/qemux86-64/packages/*.spdx.json to map licenses from the non-SPDX header in source file to all packages which were generated from that specific source file? https://lists.openembedded.org/g/openembedded-core/message/166008 is the context for this question
<JaMa>
JPEW: or should I just use e.g. jq and some adhoc shell script
<JaMa>
JPEW: also if I'm reading create-spdx.bbclass correctly then GENERATED_FROM is really just from debugsrc, so if there is e.g. shell script with some license header included in one of the packages I need to separately check in which package it ends (as it won't be listed anywhere in GENERATED_FROM relation)
<JPEW>
JaMa: I'm unaware of anything to do it
<JPEW>
I'd probably ad-hoc, but I'd also use python instead :)
<JaMa>
yes, python would make more sense :) .. but still more work then quick grep I was hoping to use :)
<yudjinn[m]>
bb.data_smart.ExpansionError: Failure expanding variable EXTRA_OEMAKE, expression was EXCLUDE_BUILD_FLAGS=1 PLATFORM=aarch64 JETSON=TRUE WITH_LIBELF=yes ${@build_date(d)} WITH_SECCOMP=no which triggered exception TypeError: 'timespec' is an invalid keyword argument for this function
goliath has quit [Quit: SIGSEGV]
<JaMa>
yudjinn[m]: bitbake is using python3 for few years now
manuel1985 has joined #yocto
<yudjinn[m]>
this is on dunfell
<JaMa>
python3 is used since 1.31.1
<yudjinn[m]>
gotcha, then I'm unsure why it's having an issue with timespec
seninha has quit [Ping timeout: 258 seconds]
<yudjinn[m]>
this is in meta-tegra>dunfell, by the way.
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<zwelch>
yudjinn[m]: i seem to recall running into that myself. I can't remember the exact problem, but i believe that i had to change something in my project layer(s) to fix it.
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<yudjinn[m]>
hm, any other pointers?
seninha has joined #yocto
<zwelch>
yudjinn[m]: not presently.
<yudjinn[m]>
gotcha, thanks!
<moto-timo>
tlwoerner: the YPS email arrived
Tokamak has quit [Ping timeout: 255 seconds]
camus has quit [Ping timeout: 240 seconds]
camus1 has joined #yocto
Tokamak has joined #yocto
<tlwoerner>
moto-timo: yea i had to poke. apparently it was supposed to go out on friday, but <issues> and it didn't run
<tlwoerner>
thanks!
camus1 is now known as camus
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 244 seconds]
leon-anavi has quit [Quit: Leaving]
manuel1985 has joined #yocto
<Saur[m]>
moto-timo: I'm getting a number of this after updating my layers: https://pastebin.com/YmD8EetZ I assume it happens to all python packages that need to rebuild for one reason or another. :(
<Saur[m]>
A `bitbake -c clean ...` fixes it, but it is not a long term solution...
pietrushnic has left #yocto [#yocto]
<moto-timo>
Saur[m]: can you try changing 'inherit setuptools3' to 'inherit setuptools_legacy' ? that package has scripts installed and probably does not behave well with new setuptools
<moto-timo>
Saur[m]: otherwise, not sure what to say... rburton might have some other insights
goliath has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
jmiehe has joined #yocto
mvlad has quit [Remote host closed the connection]
<Saur[m]>
moto-timo: Well, there were a couple more affected recipes in that build: python3-docutils-native python3-mako-native python3-inflection-native python3-setuptools-scm-native python3-packaging-native python3-cython-native python3-pygments-native python3-scons-native python3-pytest-native python3-lark-native python3-sdbus++-native python3-numpy-native python3-six-native
<moto-timo>
Saur[m]: can you file a bug in bugzilla so we talk about it in bug triage in the morning?