Soopaman has quit [Remote host closed the connection]
Perflosopher has quit [Quit: Ping timeout (120 seconds)]
Perflosopher has joined #yocto
davidinux has joined #yocto
xmn has quit [Ping timeout: 276 seconds]
paulg has quit [Ping timeout: 250 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
Scorpi has joined #yocto
<Scorpi>
Hi, I want to have nodejs included in my SDK (for npm). How do achieve this?
<Scorpi>
The package I want to build depends on nodejs-native. When I include this in TOOLCHAIN_HOST_TASK, I get an error: "rdepends upon non-existent task do_package_write_ipk in virtual:native:/opt/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_14.17.1.bb"
<brabander>
bitbake does not seems to fail when files are missing with FILES:${PN} = "nonexisiting"
<brabander>
is that normal?
tnovotny has joined #yocto
tnovotny has quit [Client Quit]
tnovotny has joined #yocto
zpfvo has joined #yocto
<LetoThe2nd>
brabander: yup
rfuentess has joined #yocto
leon-anavi has joined #yocto
<rburton>
brabander: FILES is a list of globs of files which may possibly match, unlike some other packaging systems its not fatal if there's a mistake. this is how the defaults are useful (see bitbake.conf)
old_guy has quit [Quit: Client closed]
pope has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
<RP>
rburton: seems I've overloaded 2004-arm-1 :/
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
kroon has joined #yocto
ptsneves has joined #yocto
prabhakarlad has quit [Quit: Client closed]
amitk_ has quit [Ping timeout: 255 seconds]
diego_r has joined #yocto
vladest has quit [Ping timeout: 265 seconds]
florian__ has joined #yocto
florian has joined #yocto
murych has joined #yocto
vladest has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
alessioigor has joined #yocto
prabhakarlad has joined #yocto
olani_ has quit [Ping timeout: 265 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
tnovotny has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
glembo[m] has joined #yocto
nemik has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tnovotny has joined #yocto
diego_r has quit [Read error: Connection reset by peer]
diego_r has joined #yocto
tnovotny_ has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
seninha has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
* RP
can't decide what to do about the crate problem. Scrap rc1 or not?
<RP>
I think I miss having people to discuss some of this stuff with :(
<mcfrisk>
RP: is the crate change for the better? if yes, then go forward with it.
manuel1985 has joined #yocto
Net147 has quit [Quit: Quit]
<RP>
mcfrisk: I don't know, I'm not a rust/crate/cargo expert. I suspect it is but if I merge the patch, other things will break, I'll then be on the hook for fixing those and blocked on release until we do
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<RP>
I probably shouldn't have taken the change at all in the first place but then I'd be obstructing development and not encouraging it :(
<RP>
I worry if we don't fix this now, it will cause further problems down the road. Saur is already not happy about not being able to share things across releases and this will make it much worse
alessioigor has quit [Quit: alessioigor]
<RP>
The relief at being able to hand rc1 over to QA was immense, if I start messing around with this, I'm back to square one with stress levels :(
alessioigor has joined #yocto
<JaMa>
RP: I don't have many recipes with crates, but as you wanted other people to discuss this I think it can be merged later and I wouldn't worry too much about 4.2.0 tag not having it yet (as people will still take time to adapt and upgrade their layers, so newer mickledore revision would be enough)
<JaMa>
RP: and for that backport request from Saur I have to say that I agree with him, I understand your fear that someone will quote you on backwards compatibility later, but then I'm willing to quote your reply as well where you clearly said that backwards compatibility is not a rule
<JaMa>
e.g. overrides syntax compatibility to dunfell was huge benefit for layers I maintain, for people with many crates this might be important as well (e.g. if devs are constantly changing crates in kirkstone based build, while someone like Saur is making sure their layer is as much as possible compatible with newer Yocto releases - which in this case would require him to regenerate the crate .inc file in
<RP>
JaMa: we can't really release 4.2, then change crates in an incompatible way
<JaMa>
mickledore everytime someone changes it in kirkstone, while with backwards compatibility he can just teach the rust devs to generate forward compatible .inc files in first place
<JaMa>
then I might be missing something, because the change I've seen doesn't affect the crates generated with officially supported and documented -c update_crates task
<mcfrisk>
I'm waiting for parsec-service to be fixed in meta-security so that I would compile again... meta-clang, tpm-tss2 updates and now poky crate changes all breaking things. just go forward and we can fix and aling.
<RP>
JaMa: the change in question means you may need one set of url/checksums for mickledore and another for master so I think the situation could get much worse
olani_ has joined #yocto
<mcfrisk>
the release specific branches in various layers are really not maintained at all, using master and being compatible with lts is better
<JaMa>
mcfrisk: "go forward" with release or merging the change?
<mcfrisk>
merging
<RP>
I suspect I don't know enough about this topic either and I'll have to dive deeper. Do I tell QA to stop in the meantime? :/
<JaMa>
which is good improvement, but unless I'm missing something it's not breaking the compatilibity of correctly generated SRC_URIs
<RP>
JaMa: sadly not. python3-bcrypt-crates.inc has no ;name parameters in the url
<mcfrisk>
merge it, it feels like the right thing to do. I guess no-one is a rust/crate expert who knows better. it's about feeling and intuition in the end. no-one can know for sure
<RP>
JaMa: so I merge the change, the recipes will break
<RP>
Its a public holiday tomorrow, key people are on vacation next week (and probably today) and I really don't want to rebuild the release but it is probably the correct thing to do from a technical perspective
<JaMa>
"the recipes will break" ok, then I have to be missing something
<RP>
JaMa: the urls don't have name parameters so if we change the default, the checksums won't match up
<RP>
Rather than working on sorting any of this I've an afternoon of meetings too :(
<Saur[m]>
RP: But isn't that just a question of doing as Enrico suggest, regenerate the recipes, then apply the patch?
<RP>
Saur[m]: sure, "just" that
<RP>
tell QA not to process rc1 any further, merge the bitbake change, write the other patches, post them, put them through the autobuilder for testing, handle the emails about the other layers breaking, and run through the release process again to build rc2 making sure the QA emails get sent (the rc1 didn't) and handling any new intermittent build failures
<JaMa>
my LA is over 100 from 3 other builds running already, but I've triggered python3-bcrypt build with the fetcher change included to see what's going on and in worse case will at least "just" regenerate the .inc file
<Saur[m]>
Well, in my world, recipe breakage that causes build failures, which can easily be sorted by modifying the recipe, should not be seen as a blocker. I.e., to me this can just as well be done in 4.2.1. Anyone can be prepared for the change in advance since it just means that the crates.inc files have to be updated. Since there is no syntax changes or anything like that, which would prevent doing it in advance, waiting for 2.4.1 should be fine.
<Saur[m]>
4.2.1*
<RP>
Ok, I've told QA to stop so rc2 it is. it is the right thing to do technically and for the project
* RP
quietly curses as the repo sync falls apart
<JaMa>
repo sync as combo-layer-tool?
<Saur[m]>
RP: On the other hand (I will contradict myself here a bit), if you *do* take the change for Mickledore, it means there will no longer be a requirement to use the name= parameter for the crate:// URIs, which would mean I can use the same crates.inc files for Langdale and Mickledore and thus solve my wish for compatibility...
<RP>
JaMa: consequences of it. Nothing I can't fix
<RP>
Saur[m]: I don't think there is a requirement to use the name parameter as we have recipes that don't have that now
<RP>
JaMa: confirmed that things do fail to build FWIW
<Saur[m]>
RP: There is if you have a recipe that depend on two different versions of the same crate.
<JaMa>
I'm still quite far from that due to other load: 5 running tasks (1407 of 3556)
<Saur[m]>
That is what the "fetch:crate: create versioned 'name' entries" patch solves, without having to explicitly specify different names for them using the name= parameter.
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
<RP>
Saur[m]: ok, so this does help your other issue
<JaMa>
"sadly not. python3-bcrypt-crates.inc has no ;name parameters in the url", Ah I get it now (after seeing the failure locally)
<RP>
anyway, why aren't these checksums just in the crate url if we're autogenerating these things anyway
<Saur[m]>
RP: As far as I can tell, this should solve my problem, but backporting to Kirkstone/Langdale would have solved it as well, and would be less invasive.
<RP>
Saur[m]: going forward having two different naming setups for this would be problematic though
<Saur[m]>
RP: I have been asking myself that too. The only reason I can see is that if the checksums do not match, bitbake will output suggested updates using the SRC_URI[name.sha25sum] syntax, rather than updated URIs with sha256sum=.
<prabhakarlad>
Hi all, is there a way we could add require to bb/bbappend depending on the MACHINE?
<Saur[m]>
prabhakarlad: You mean like `require foo-${MACHINE}.inc`? It should work.
Ad0 has quit [Ping timeout: 255 seconds]
<prabhakarlad>
Saur[m]: thanks, thats a good trick, I actually wanted to skip "require" for specific machine
vmeson has joined #yocto
<Saur[m]>
prabhakarlad: You can do that if you use a variable, e.g., `FOOBAR = "foobar.inc"`, `FOOBAR:some-machine = ""`, `require ${FOOBAR}`
<JaMa>
RP: I've sent the updates for .inc files
<JaMa>
still running the build, but "what could go wrong" right?
<JaMa>
hmm but you didn't set the name in SRC_URI entries
<JaMa>
how did you regen these? with bitbake output?
<JaMa>
I think mine are better, because I've used the bbclass to do the update, so next time someone updates one of these 2 recipes will get fewer changes in the .inc file
<JaMa>
and I've also documented in commit message how to efficiently regenerate them, because what Frederic said is unnecessary complicated
goliath has joined #yocto
<JaMa>
and I'm past do_fetch as well
<Saur[m]>
RP, JaMa : If the patch to automatically set the versioned names is applied (which I believe RP is going for now), we might want to update the cargo-update-recipe-crates.bbclass too to no longer generate the name= parameters. It is not needed, but it would result in patches corresponding to RP's version rather than JaMa's.
<JaMa>
right
<JaMa>
I don't think RP was asking for even more work, but you're right
<RP>
If we're going to do that, why not just put the sha256 into the url? :)
<JaMa>
I've just tried to be helpful, will go back to work where people are complaining that I gave them negative review for changes which don't even build
waltminer has joined #yocto
<RP>
JaMa: I appreciate the help and the second set of eyes
Ad0 has joined #yocto
<JaMa>
RP: you're welcome :)
<RP>
JaMa: I got build failures when I tried update_crate so I copy and pasted. Your echo is easier :)
<Saur[m]>
RP: I do agree with you as I believe it would simplify the crates.inc files. The only thing that speaks against it is that the error output when a checksum is wrong uses the SRC_URI[name.sha256sum] syntax.
<RP>
Saur[m]: that could be improved as needed
<JaMa>
RP: yes I got the same failure when trying to update solana recipes few days ago
<Saur[m]>
RP: Also, FYI, we are seeing a steady increase in Rust (and Go) recipes in our layers, so while I still have very little experience with either, I believe exposure to them will lead to more contributions from our side to improve the experience with working with either.
<JaMa>
on unrelated note, I assume this isn't triggered on AB as buildpaths are fatal error in poky, right?
<JaMa>
WARNING: python3-bcrypt-4.0.1-r0 do_package_qa: QA Issue: File /usr/lib/python3.11/site-packages/bcrypt/_bcrypt.abi3.so in package python3-bcrypt contains reference to TMPDIR [buildpaths]
diego_r has quit [Read error: Connection reset by peer]
azcraft has joined #yocto
diego_r has joined #yocto
prabhakarlad has quit [Quit: Client closed]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
prabhakarlad has joined #yocto
<RP>
JaMa: they are and we haven't seen that
tunahan has quit [Quit: tunahan]
<JaMa>
cryptography has the same so might be something rusty
<JaMa>
WARNING: python3-cryptography-39.0.2-r0 do_package_qa: QA Issue: File /usr/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so in package python3-cryptography contains reference to TMPDIR [buildpaths]
tunahan has joined #yocto
<brabander>
how can i force the pkg_postinst of a recipe? I've updated it, but even a "-c clean" doesn't seem to work
xmn has joined #yocto
manuel_ has joined #yocto
<Saur[m]>
RP: I just sent a patch to make cargo-update-recipe-crates.bbclass without the name= parameters. It is not required to take it, but it does go along with Enrico's patch, so I leave it up to you which you do. I then think we should revise this in 4.2.1 to use sha256sum= parameters instead, possibly with an update to the error output when the checksums do not match.
<JaMa>
where do you expect it to be forced? pkg_postinst is executed by package manager
<brabander>
when i build the image, the updated pkg_postinst doens't seem to be used
<Guest6985>
So if I understand correctly "poky" is a reference distro. Should we always start from this reference or is it recommended to start with "other" reference distribution and if so which alternatives exists?
<Guest6985>
e.g. OpenEmbedded Core?
rob_w has joined #yocto
<Saur[m]>
Guest6985: OE-Core is part of Poky. Poky is basically Bitbake, OE-Core and meta-poky combined into one repository.
<Guest6985>
My second question is, if I am in the branch "dunfell" and I have a build directory "build" and I want to change to "langdale", then my "build" directory needs to be removed and I need to source the oe-env script again... because I get: ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<Guest6985>
ERROR: Shell environment variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<Guest6985>
ERROR: Exiting to allow enviroment variables to be corrected
<Guest6985>
ERROR: Shell environment variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
<Guest6985>
ERROR: Exiting to allow enviroment variables to be corrected
<Guest6985>
Is there a better way of doing it (probably yes so then what way is recommended instead of deleting my build directory)?
<Guest6985>
It seems the error is related to something else
<Saur[m]>
Guest6985: Actually, in that case the problem is due to the `BB_ENV_EXTRAWHITE`variable having been set in your shell's environment when you sourced `oe-init-build-env` with the Dunfell version. If you unset that variable, or start a new terminal, it should be possible to source the updated version.
<mcfrisk>
Guest6985: remove build/tmp but you can modify build/conf/* to pass the build, just follow the instructions in errors/warnings
<Guest6985>
Saur[m] starting a new terminal worked
<Guest6985>
thanks
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<Guest6985>
there is a meta-flutter available which doesn't work on most devices because the Flutter engine is so difficult to compile for a specific device. Will it be much easier with the upcoming Impeller engine which will replace the current Skia engine or does this has nothing to do with it in the first place to have Flutter running on embedded devices?
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<rob_w>
if impeller makes it general easier to compile for different platforms , then it should help i say
<Guest6985>
But was the bottleneck until now that Skia engine made it difficult to compile Flutter engine for embedded devices?
<mckoan>
Guest6985: AFAIK Impeller is under active development, and isn't yet ready
<Guest6985>
mckoan That is alright, my point is to not switch to Qt if the new Flutter Impeller will (or at least should be able to) make it easier to compile Flutter engine for embedded devices. The other point that remains is that I don't know if the C bindings that interface with Flutters' Dart will slow down the back-end (e.g. interfacing with sensors)?
gsalazar has joined #yocto
<smurray>
mckoan: I believe Impeller is in Flutter 3.7.x
<RP>
Saur[m]: we can't really revise that in a point release. I've taken your patch though, thanks (and tweaked JaMa's to match after it)
<Guest6985>
Impeller and Skia seems to be libraries part of the Flutter engine, meaning it will help slightly in compiling Flutter for devices but the difficulty still remains.
<smurray>
Guest6985: we're building flutter-auto from meta-flutter for several different platforms in AGL, I'm curious what it is that you're having a problem with?
thomas__ has quit [Ping timeout: 252 seconds]
<Saur[m]>
RP: Well, since both the syntax using `SRC_URI[name.sha256sum]` and `sha256sum=` are equally valid and will remain so, changing the output from `bitbake -c update_crates` to use `sha256sum=` instead of `SRC_URI[name.sha256sum]` shouldn't be a problem. The task is manually run so nothing happens without the developer being aware of it.
<Saur[m]>
Though I guess changing the error output from using one form to the other might be a bit more invasive.
<Guest6985>
smurray having flutter for jetson, rpi, imx etc. flutter for AGL seems to be in full development
<RP>
Saur[m]: you're right from a technical perspective on both. The issue is in a stable release we're not supposed to change behaviours like that
<Guest6985>
The one you mention is under development by toyota and thus well supported
<Guest6985>
smurray
<Saur[m]>
RP: Fair enough.
<smurray>
Guest6985: yes
<Saur[m]>
RP: FWIW, I have built our six Rust recipes after applying Enricos patch without problems. And also after applying the changes that my patch results in.
sakoman has joined #yocto
<Scorpi>
How can I include nodejs into the SDK so I can use npm?
<Scorpi>
adding nodejs-native to TOOLCHAIN_HOST_TASK causes an error: rdepends upon non-existent task do_package_write_ipk in virtual:native:/opt/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_14.17.1.bb
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
<Saur[m]>
Scorpi: You are not expected to add native recipes to TOOLCHAIN_HOST_TASK, it takes nativesdk recipes, i.e., you would need a `nativesdk-nodejs`. However, the `nodejs` recipe currently does not add `nativesdk` to `BBCLASSEXTEND`. It might be as simple as adding that, but I have no experience with nodejs, so I wouldn't know.
kscherer has quit [Quit: Konversation terminated!]
<Saur[m]>
RP: Btw, I sent a PATCHv2 for my patch to fix a typo in the commit message.
<RP>
Saur[m]: I'd already merged v1, sorry
<Saur[m]>
RP: No worries.
<JaMa>
RP: FYI that [buildpaths] QA issue is caused by ld-is-gold in DISTRO_FEATURES, gold generates the library path in .gnu.version_d section which seems to be missing completely when default bfd is used
tnovotny_ has quit [Quit: Leaving]
<RP>
JaMa: ah, at least we know why the autobuilder didn't see it then!
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Guest6985 has quit [Quit: Client closed]
xmn has quit [Ping timeout: 250 seconds]
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
diego_r has quit [Ping timeout: 265 seconds]
xmn has joined #yocto
diego_r has joined #yocto
<smurray>
just checking, is it the case that I can't take the SRC_URI generated with cargo-update-recipe-crates on e.g. oe-core master, and use it with kirkstone?
<smurray>
based on the error I'm seeing, I'm guessing there was a crate fetcher change at some point that precludes it...
<RP>
smurray: I think things on master/mickledore as of an hour or so ago should be ok
<smurray>
RP: ah, okay, so pull, then regen the crates .inc?
<smurray>
RP: looking at the commit message, that definitely will fix my issue, thanks!
<RP>
smurray: this is partly why I scrapped rc1
<Saur[m]>
smurray: You're welcome. ;)
leon-anavi has quit [Remote host closed the connection]
<smurray>
Saur[m]: heh, I'm torn on whether I was lucky or unlucky to hit it ;)
<Saur[m]>
smurray: Well, I only stumbled on this yesterday...
<smurray>
Saur[m]: crates.io seemed pretty slow today, I'm wondering if that's new or if I just wasn't paying enough attention before