<khem>
alimon: I see, I think some packaging files are different perhaps. We could move it to meta-oe dynamic layers perhaps would you mind creating a patch ?
tp43_ has joined #yocto
xmn has quit [Quit: ZZZzzz…]
vd has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jwillikers has quit [Remote host closed the connection]
sakoman has quit [Read error: Connection reset by peer]
hpsy has joined #yocto
sakoman has joined #yocto
angolini has quit [Quit: Connection closed for inactivity]
sakoman has quit [Quit: Leaving.]
zpfvo1 has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
sakoman has joined #yocto
tp43_ has quit [Ping timeout: 245 seconds]
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
cocoJoe has joined #yocto
Xagen_ has joined #yocto
Xagen has quit [Ping timeout: 245 seconds]
amitk has joined #yocto
tp43_ has joined #yocto
paulg has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
tp43_ has quit [Ping timeout: 245 seconds]
hpsy has quit [Remote host closed the connection]
roussinm has quit [Quit: WeeChat 3.3-dev]
goliath has joined #yocto
davidinux has joined #yocto
frieder has joined #yocto
rob_w has joined #yocto
ant__ has quit [Quit: Leaving]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
<mihai>
yo
leon-anavi has joined #yocto
<cocoJoe>
good morning
zpfvo1 has quit [Quit: Leaving.]
zpfvo has joined #yocto
tre has joined #yocto
bps has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
kanavin has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
kanavin has joined #yocto
jmiehe has joined #yocto
prabhakarlad has joined #yocto
florian has joined #yocto
tre has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
tre has joined #yocto
<lukma>
Dear Community, I do have a strange question :-)
<lukma>
Normally I can use FOO:remove = "bar"
<lukma>
but what if I do have the _bbappend file which inherites FOO with _many_ set values
<lukma>
I need to remove the all and then set a few new ones
<lukma>
I can do it with bitbake -e recipe | grep ^FOO
<lukma>
and then manually call FOO:remove = on the result
<lukma>
but I wondering if there is any better (i.e. more elegant way) to do it ?
<RP>
lukma: anonymous python and using setVar will reset the variable
<lukma>
RP: Thanks :-)
frieder has quit [Quit: Leaving]
frieder has joined #yocto
<lukma>
RP: I've found on the Internet that _anonymous is called after the recipe is parsed
<lukma>
is it called before or after the bbappend is appended?
<qschulz>
lukma: or just FOO = "new values" ?
<qschulz>
provided your bbappend is the last one to be parsed (in the layer with highest priority IIRC?)
<RP>
lukma: after
<lukma>
qschulz: FOO = "new values" is not working as I do play with already set PROVIDES and RPROVIDES
<qschulz>
not following sorry :/
hpsy has joined #yocto
<RP>
qschulz: the issue is the setting FOO = will not change the previous appends
<qschulz>
RP: there was no mention of _append or _prepend in the question :)
jmiehe has quit [Quit: jmiehe]
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
jmiehe has joined #yocto
<RP>
qschulz: fair enough, I guess I assumed since it was the only way the question made sense to me
<qschulz>
RP: yup, I just didn't guess it but that is indeed the only way the question made sense :)
hpsy has quit [Read error: Connection reset by peer]
frieder has quit [Ping timeout: 240 seconds]
frieder has joined #yocto
BCMM has joined #yocto
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
jwillikers has joined #yocto
vmeson has quit [Read error: Connection reset by peer]
vmeson has joined #yocto
angolini has joined #yocto
jwillikers has quit [Remote host closed the connection]
<lukma>
Is Yocto/OE supporting '**' in FILES:${PN} ?
<lukma>
I would need to extract files with a suffix scattered accross many different directories (Already copied to S{D})
<smurray>
I believe you can do e.g. /usr/*/*.foo, but if you have different depths of directory you'll need multiple file globs
<lukma>
Files with suffix are placed in many different directories
<lukma>
the depth indeed is different
<smurray>
the perl and go recipes do what I mentioned to handle modules, so I suspect there's not something simple to handle it
<smurray>
there are dynamically split packages for some things which use anonymous python in the recipe to build the variables, so that might be an approach
<qschulz>
you could use the do_s[plit_packages python function indeed
<qschulz>
since by default you pass it a regexp for the filename only
paulg has joined #yocto
<qschulz>
with do_split_packages but then it splits each file in a different package..so might not be ideal
<qschulz>
lukma: reading the code of the handling of FILES, it seems like ** could be supported
vmeson has quit [Quit: Konversation terminated!]
<qschulz>
see files_from_filevars in oe-core/classes/package.bbclass
<qschulz>
it uses glob.glob() which supports ** since python 3.5
<smurray>
heh, I don't see any use of it in oe-core with grep, though
<RP>
smurray: I'd never seen it before! :)
<smurray>
RP: me either ;)
<wCPO>
Is there more to enabling a kernel config option than described here: https://docs.yoctoproject.org/kernel-dev/common.html#adding-recipe-space-kernel-features ? I did everything as described and "test.scc" is copied to build/tmp/work/genericx86_64-poky-linux/linux-yocto/5.10.43+gitAUTOINC+3f38ad49cf_ab49d2db98-r0 but it isn't enabling the option.
cocoJoe has quit [Quit: Client closed]
cocoJoe has joined #yocto
prabhakarlad has quit [Quit: Client closed]
jmiehe has quit [Read error: Connection reset by peer]
cocoJoe has quit [Quit: Client closed]
cocoJoe has joined #yocto
prabhakarlad has joined #yocto
sakoman has joined #yocto
roussinm has joined #yocto
<wCPO>
oh, some smart filtering is done, so if the dependencies aren't added it is silently removed
<JPEW>
RP, sakoman What layers are scanned for CVEs
Krisso has joined #yocto
cocoJoe has quit [Quit: Client closed]
<sakoman>
JPEW: I only scan oe-core
<RP>
JPEW: core right now but we could extend that if there was interest/support for handling the issues
cocoJoe has joined #yocto
<qschulz>
wCPO: there's a tool to create config fragments in the kernel IIRC, use that one instead of writing config fragments by hand
<tlwoerner>
is it possible for a recipe to interrogate the kernel config?
<tlwoerner>
in other words, i want to optionally include the "kmod" package in my packageconfig, but only if zram is configured as a module
<tlwoerner>
if zram is a built-in then i don't need kmod
<wCPO>
qschulz: I would do that next time, but I kinda expected it to complain and not just silently remove kernel config options
goliath has quit [Quit: SIGSEGV]
<qschulz>
wCPO: the kernel does not complain IIRC, so Yocto can't do anything about it
<qschulz>
if it does complain (check log.do_compile to know), then maybe there's something we can do?
<qschulz>
tlwoerner: you would need to read the .config of the kernel recipe to know that. Except if there's some special handling somewhere... recipe data is local, so you can't access it from another recipe.
<qschulz>
Though what you could do is deploy this .config from your kernel recipe
<qschulz>
mmmmmm
<qschulz>
thinking about that, PACKAGECONFIG probably needs to be set during parsing so what I was about to suggest won't work
Guest81 has joined #yocto
<zeddii>
it's generally a bad idea to attempt to link packaging decisions to the .config like that. The names of the values, etc, change over time. It just needs to be explicit, with some potentially installed packages that aren't always required.
<wCPO>
qschulz: I will check tomorrow. I have powered off my server for today
<tlwoerner>
or i could just include kmod unconditionally and if it's needed it's needed, if it not it's not
<qschulz>
yup
<qschulz>
don't know exactly what are the consequences of including it, but maybe you could split the outcome of that in a different package
<qschulz>
and you could have an RDEPENDS_kernel-module-zram += "your-kmod-package" in a bbappend of the kernel?
<tlwoerner>
i have a feeling module vs built-in is going to get messy
<barath>
does anyone here know off-hand whether sharing the a sstate-cache directory directly is safe wrt race conditions?
<barath>
ie. if I share a sstate-cache directory directly, can I end up in a situation where someone downloads a sstate-cache file while it's being written, causing the downloader to attempt to use an incomplete sstate-cache file?
<barath>
sry to butt in like that
prabhakarlad has quit [Quit: Client closed]
<qschulz>
barath: IIRC some servers run by YP (autobuilder?) has the sstate-cache over NFS, so I'd say yes
<JPEW>
barath: It is safe. sstate is designed to be shared that way
<qschulz>
and in any case, I've had multiple builds on my local desktop reuse the same sstate-cache without any issue :)
<JPEW>
You need proper file locking IIRC, so either a local file syetem or NFS
<barath>
that is very nice to hear. I couldn't find anything explicit about whether that was safe or not in the docs
<barath>
currently we copy the sstate-cache from several builder nodes to a central server to be served from, but it sounds like that's not even really necessary except to avoid having to query multiple sstate mirrors
dlan has quit [Remote host closed the connection]
<JPEW>
barath: Ya, I would recommend directly sharing it over NFS for CI-type jobs
<JPEW>
It's much more efficient
<JPEW>
We then export the cache via HTTP, which our developers point there local builds at as a mirror, so if CI has built something before, the developers will just download it instead of building it themselves
<barath>
yeah, we currently try to build everything during the night on those nodes and then we aggregate it by rsyncing it to a single http server. we've had weird issues sometimes where sstate-cache are seemingly corrupted, and it would be nice to exclude any unecessary steps and just point people directly to the sstate-cache directories...
<barath>
I assume there arent really any docs on how yocto writes the sstate-cache files wrt locking/atomicity other than the code itself?
<JPEW>
barath: Probably not
<tlwoerner>
code makes good documentation ;-)
<barath>
agreed :D
<barath>
just more work to present to people who dont want to read it
<JPEW>
barath: Ya, we really need "A quick guide to setting up sstate"
<barath>
well it seems an easy enough concept in itself, apparently whoever first set up our yocto workflow didn't get the message of aggressively sstate-caching and premirroring everything
<JPEW>
barath: I suspect that is common, it just doesn't scale well :)
cocoJoe has quit [Quit: Client closed]
<barath>
:D yes
<vd>
Is `if d.getVar('FOO') == '1':` valid?
prabhakarlad has joined #yocto
<barath>
and writing recipes without regard for how the sstate cache hashes will be calculating, leading to hash invalidation when really nothing important has changed... oh well
<barath>
thanks for the quick help! :)
vmeson has joined #yocto
dlan has joined #yocto
<qschulz>
vd: what's wrong with it?
<vd>
just asking if it's valid bitbake/python
cocoJoe has joined #yocto
Krisso has quit [Quit: Client closed]
<RP>
vd: probably, depending on where that is used
frieder has quit [Remote host closed the connection]
<vd>
Like BB_CURRENT_MC, is there a variable describe the bitbake target(s) being built?
Guest81 has quit [Quit: Client closed]
<vd>
s/describe/describing/
vd has quit [Quit: Client closed]
vd has joined #yocto
<tlwoerner>
if i do a d.setVar() with a variable that doesn't exist, will it be created?
goliath has joined #yocto
<qschulz>
tlwoerner: add it to an anonymous python function and then bitbake -e recipe to check if it does :)
<RP>
tlwoerner: yes
<tlwoerner>
yes, it's working now. i was trying a bunch of stuff and it didn't seem to be working
<tlwoerner>
but i think bitbake didn't think my changes required a respin so the output file wasn't getting updated, but after a -c cleansstate it's working
<tlwoerner>
i was trying little incremental changes in a python __anonymous function and the output wasn't changing, but after i did a cleansstate i got the correct output
rob_w has quit [Quit: Leaving]
<RP>
tlwoerner: the hashes that represent hashes can't look into anon python so it would depend whether the variables the code is changing are already in the hash or not
<RP>
represent tasks
<tlwoerner>
RP: i see. originally the variable was outside the anoymous function and could be fiddled with by the user. but then i realized that it would make more sense for the variable to be set inside the anonymous function depending on a set of criteria instead
<tlwoerner>
so as i moved the variable inside the anonymous and fiddles with the correct python syntax (originally i was just trying to create/set the variable directly and not using d.setVar()) it wasn't getting updated
<tlwoerner>
which prompted the question :-)
<tlwoerner>
but i got it sorted out now, thanks! :-)
<vd>
how can I call bb.note() from a multiconfig file?
<tlwoerner>
so an IMAGE_FEATURE can't include a kernel module? only a MACHINE_FEATURE could do that?
<tlwoerner>
zeddii: that's how enabling nfs includes the nfs kernel module?
<RP>
tlwoerner: I don't see why an IMAGE_FEATURE couldn't do that
<RP>
tlwoerner: or do you mean enable rather than include?
<zeddii>
tlwoerner: there's a bugzilla that explains all the nuances to this.
<vd>
how can I print a variable from a config file?
<RP>
vd: XX := "${@bb.warn(d.getVar('Y'))}" maybe ?
<tlwoerner>
in yesterday's call i asked about having an IMAGE_FEATURE include/rrecommend a kernel config and zeddii said this is what nfs is doing, so i was trying to track down how nfs is doing this
<RP>
tlwoerner: you only build the kernel once so IMAGE_FEATURE is too late to change kernel config
<zeddii>
tlwoerner: due to kernel versions, machine capabilities, etc, there's no universally generic way to do it. If you use kernel fragments, the closest thing is to have KERNEL_FEATURES, which error or can be checked if they aren't set. otherwise, you are binding yourself to kernel recipes, versions and mucking around.
<vd>
RP: I see, the trick is the use a dummy variable, thanks ;)
<tlwoerner>
there's no point enabling zram-tmpfs in IMAGE_FEATURES if the kernel isn't configured with zram enabled
<zeddii>
tlwoerner: we use KERNEL_FEATURES for that, as teh decoupling mechanism.
<tlwoerner>
zeddii: ah! of course
<zeddii>
nfs isn't based on an image feature (I thought it was), sec.
<zeddii>
we do plenty on distro features, but there's no reason why the same for image_features isn't valid.
<RP>
zeddii: there is a reason - you can't change kernel config per image
<RP>
just which modules are installed in the image
<zeddii>
true. I was just thinking of it as a variable, that someone can set to change things. but that's distro changes in this case.
argonautx has quit [Quit: Leaving]
<tlwoerner>
so maybe this suggests i should be making this a DISTRO_FEATURE instead?
<zeddii>
that's what I ended up doing in meta-virt for kubernetes, etc.
<tlwoerner>
zeddii: using a KERNEL_FEATURE means i'd have to start by submitting a .scc/.cfg option for zram to yocto-kernel-cache?
<vd>
RP: I get ERROR: Unable to parse Var <XX[:=]> with the := operator and with = I don't see the message
<zeddii>
unless the feature is in it's own layer, yes.
<FO3>
Question about multilib: We enabled, both lib get created, but bin seem to be randomly a mixt of 32 and 64bits executables. For recipes that have both libraries and bin in them (like systemd). Any idea on how to fix that ? (We tryed both IPK and RPM)
<RP>
FO3: it should be deterministic based upon policy :/
<FO3>
policy ?
<FO3>
poky, poky-tiny, poky-bleeding stuff like ? I will look into that.
<RP>
F03: if you add lib32-openssh, you should have a 32 bit openssh binary in the image
<FO3>
yes but because we add lib32-systemd to have the lib; we get 32bit system executables
<FO3>
because we need both 32 and 64 systemd lib. but iwould prefer to control which executable we get by default
<FO3>
there seem to be something for recipes with ALTERNATE stuff in multilib.bbclass; but not for recipes w/o
ant__ has joined #yocto
<RP>
FO3: you should be able to control that by explicitly installing the one you want
<FO3>
RP: Thnaks we will do more tests, but both systemd get installed, and the 32bit one seem to win in /bin
<RP>
FO3: I think it is configurable but I don't remember how/where
d0ku has joined #yocto
<FO3>
RP: ok; i will keep looking to find how
ant__ has quit [Ping timeout: 252 seconds]
d0ku has quit [Client Quit]
d0ku has joined #yocto
<khem>
FO3: you perhaps would need to package libs into its own package and rest of systemd binaries into separate one
<khem>
32bit bins should then not be picked up if there is library-only dependency
<khem>
only 32 bit libs will be pulled in
<FO3>
ok; but i want to add lib32-systemd in my toolchain; so my old 32bit only app can link with it.
<FO3>
so while building image; it doesnt knw about my app that required 32bit systemd.so so we added lib32-systemd in IMAGE_INSTALL that bring both exe; but 32bits seem to win. I saw in the doc; that for RPM; the normal one get installed firs then the multilib ones
<FO3>
we were using IPK; then tryed RPM in hope of better results; but did not change anything
ant__ has joined #yocto
vd has quit [Ping timeout: 246 seconds]
<RP>
RobR: docs are fixed
<RobR>
RP thanks
<FO3>
Thank you both; i will try to find where the rpm choose the order
<smurray>
RP: I think I've brute forced a solution to the asyncio loop hangs
<RP>
smurray: ah cool, that sounds good :)
LetoThe2nd has joined #yocto
<smurray>
RP: I can sort of imagine something clever with a custom event loop policy (which in theory could transparently ensure a different loop per process/thread), but that seems like another can of worms wrt Python version
<JPEW>
smurray: Whats the solution?
<LetoThe2nd>
JPEW: how did the townhall go?
<JPEW>
LetoThe2nd: I though it went really well
leon-anavi has quit [Remote host closed the connection]
<smurray>
JPEW: both client and server need to always call new_event_loop and then giving that loop in a call to set_event_loop
<smurray>
JPEW: that makes both 3.7 and 3.9 happy
<LetoThe2nd>
JPEW: nice to hear! satisfactory attendee count?
<JPEW>
LetoThe2nd: It was between 70-100 + presenters
<LetoThe2nd>
JPEW: hey i think thats pretty good!
<smurray>
JPEW: the wrinkle that was biting with 3.7 was repeated use of new_event_loop in the client w/o set_event_loop seems to blow up eventually in the bitbake-server processes
<JPEW>
LetoThe2nd: Ya. I think a lot of the attendees did have much familiarity with Yocto or OE, so it was good outreach :)
<smurray>
JPEW: and get_event_loop isn't an answer as there's a usecase in the hashserv unit tests that will blow up
<JPEW>
LetoThe2nd: Sorry, they did *not* have familiarity
<LetoThe2nd>
JPEW: ya guessed that.
<JPEW>
LetoThe2nd: I sometimes type non-linerarly and it gets me into trouble :)
<LetoThe2nd>
JPEW: so do we all
<LetoThe2nd>
JPEW: i'm super curious how the count for the mentorship session will turn out.
<JPEW>
smurray: Ya, that test cases makes some things a little more difficult, but I think it's important to have
<smurray>
JPEW: with my changes it'll be impossible to write code that runs the server and client or even the 2 different clients in the same process w/o some potential issues, but it no longer hangs in selftests anymore...
<JPEW>
smurray: because each client has it's own loop?
<smurray>
JPEW: right
<JPEW>
hmm
<smurray>
JPEW: but the seemingly required calls to set_event_loop to make 3.7 not explode will break trying to do that
<JPEW>
smurray: That probably means you can't have more than one asyncio loop user, not just the client/server
<smurray>
JPEW: atm there's no other users in bitbake, I think
<JPEW>
Is the code for setting the loop in the Client or ASyncClient class?
<smurray>
JPEW: Client
<JPEW>
smurray: K, I don't think that one would work with multiple other asyncio users anyway... if your doing that you need to use ASyncClient (and provide your own loop) anyway
<smurray>
JPEW: if we could force everyone to use Python 3.9 I suspect we could avoid some issues, but that's not happening anytime soon
<JPEW>
smurray: Sure. Perhaps make sure thats documented for posterity?
<smurray>
JPEW: the need to call set_event_loop seems very 3.7 specific, 3.9 worked w/o it in the client code AFAICT
<JPEW>
Ya, are you making it version conditional?
<smurray>
after spending the last 3 weeks testing I can't say I feel like doing another round of tests around that, tbh
<smurray>
it works on both 3.7 + 3.9 atm w/o it being conditional
<smurray>
what would be the benefit of that, exactly?
<JPEW>
It would work with multiple clients
<smurray>
all these task processes are short-lived effectively
<smurray>
on the client side I actually don't quite understand how asyncio is particularly useful
<JPEW>
smurray: Ya, fair. As long as we know what the limitations are (e.g. with a comment), we should be OK
<smurray>
JPEW: I'll add some comments, if you want to grind on debugging it for several weeks more, you can ;)
<smurray>
JPEW: at this point if these changes don't pass autobuilder my next step will be just dropping asyncio for PR server for now to get the read-only support in
vd has joined #yocto
<vd>
Why are BUILDNAME and BBTARGETS empty?
leon-anavi has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
vd has quit [Quit: Client closed]
amitk has quit [Ping timeout: 268 seconds]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
vd has joined #yocto
cocoJoe has quit [Quit: Client closed]
RobR has quit [Quit: Client closed]
zyga-mbp has quit [Ping timeout: 240 seconds]
zyga-mbp has joined #yocto
<vd>
I get a weird error with my .mount unit: "must be superuser to use mount", but there's only root on the system...
d0ku has quit [Ping timeout: 268 seconds]
tp43_ has joined #yocto
prabhakarlad has quit [Quit: Client closed]
leon-anavi has quit [Remote host closed the connection]
prabhakarlad has joined #yocto
<tp43_>
I got a pl2303 cable only $1
goliath has quit [Quit: SIGSEGV]
jwillikers has quit [Remote host closed the connection]
florian has quit [Ping timeout: 240 seconds]
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #yocto
<vmeson>
vd: Do you have more context about: Why are BUILDNAME and BBTARGETS empty?