*** florian__ <florian__!~florian@dynamic-093-131-181-193.93.131.pool.telefonica.de> has joined #yocto | 00:14 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 00:17 | |
*** ardo <ardo!~ardo@host-79-30-198-16.retail.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds) | 00:31 | |
*** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 00:39 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 00:42 | |
*** florian__ <florian__!~florian@dynamic-093-131-181-193.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 00:42 | |
*** ardo <ardo!~ardo@host-80-183-58-45.business.telecomitalia.it> has joined #yocto | 00:47 | |
*** ardo <ardo!~ardo@host-80-183-58-45.business.telecomitalia.it> has quit IRC (Ping timeout: 264 seconds) | 01:11 | |
*** ardo <ardo!~ardo@host-80-183-58-117.pool80183.interbusiness.it> has joined #yocto | 01:14 | |
*** lexano <lexano!~lexano@174.119.69.134> has quit IRC (Ping timeout: 272 seconds) | 01:55 | |
*** davidinux <davidinux!~davidinux@194.34.233.45> has quit IRC (Ping timeout: 264 seconds) | 02:04 | |
*** davidinux <davidinux!~davidinux@194.34.233.37> has joined #yocto | 02:05 | |
*** benkard <benkard!~mulk@pd95149fd.dip0.t-ipconnect.de> has joined #yocto | 02:24 | |
*** mulk <mulk!~mulk@p5b2dce88.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 272 seconds) | 02:25 | |
*** benkard is now known as mulk | 02:25 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6536:300:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 255 seconds) | 02:55 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6518:6b00:2ce:39ff:fecf:efcd> has joined #yocto | 02:57 | |
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Read error: Connection reset by peer) | 03:32 | |
*** npcomp <npcomp!~user@user/npcomp> has quit IRC (Ping timeout: 268 seconds) | 03:36 | |
*** joeythesaint <joeythesaint!~jjmcdn@205.185.115.212> has quit IRC (Ping timeout: 268 seconds) | 03:36 | |
*** joeythesaint <joeythesaint!~jjmcdn@205.185.115.212> has joined #yocto | 03:37 | |
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 03:37 | |
*** npcomp <npcomp!~user@user/npcomp> has joined #yocto | 03:51 | |
*** sev99 <sev99!~sev@pool-108-32-48-117.pitbpa.fios.verizon.net> has quit IRC (Quit: Client closed) | 03:57 | |
*** amitk <amitk!~amit@58.84.61.226> has joined #yocto | 04:13 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 255 seconds) | 04:41 | |
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 264 seconds) | 04:43 | |
*** nerdboy <nerdboy!~nerdboy@47.143.129.198> has joined #yocto | 04:55 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 05:08 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Client Quit) | 05:11 | |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 05:52 | |
*** mulk <mulk!~mulk@pd95149fd.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds) | 06:02 | |
*** salahaldeen <salahaldeen!sid584754@id-584754.hampstead.irccloud.com> has joined #yocto | 06:03 | |
salahaldeen | Including Python3 modules in generated SDK do not work (python3-node-semver, kirkstone) | 06:03 |
---|---|---|
salahaldeen | Hello, | 06:04 |
salahaldeen | I am using one application which is using a python3 module (python3-node-semver), I was trying to provide the application developer with the yocto SDK but I cannot locate this module in the new generate SDK, I have tried to add this manually by adding these lines to machine config like this | 06:04 |
salahaldeen | IMAGE_INSTALL:append = " python3-node-semver" | 06:04 |
*** mulk <mulk!~mulk@p5b2dc13b.dip0.t-ipconnect.de> has joined #yocto | 06:04 | |
salahaldeen | TOOLCHAIN_HOST_TASK += " python3-node-semver " | 06:04 |
salahaldeen | https://layers.openembedded.org/layerindex/recipe/333689/ | 06:04 |
salahaldeen | but still not working, python3-node-semver is available on the target but not in the host SDK!! Any idea what this happening? | 06:04 |
salahaldeen | Regards, | 06:04 |
salahaldeen | Salahaldeen | 06:04 |
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 06:27 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Remote host closed the connection) | 06:28 | |
*** Chaser_ <Chaser_!~Chaser@user/chaser> has joined #yocto | 06:29 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 06:29 | |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Ping timeout: 264 seconds) | 06:30 | |
*** hnez <hnez!~quassel@flummi.grey.stw.pengutronix.de> has joined #yocto | 06:46 | |
*** linfax <linfax!~linfax@eumail.topcon.com> has joined #yocto | 07:13 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:30 | |
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:904d:2e61:c367:a752> has joined #yocto | 07:31 | |
*** Chaser_ <Chaser_!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…) | 07:32 | |
yocton | About the kernel CVEs, linux become a CNA : https://lwn.net/Articles/961978/ http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/ that might change things a bit... | 07:32 |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 07:33 | |
mcfrisk_ | oh, uptodate CVE data for all kernel branches and stable releases? can CVE database scale to that... | 07:37 |
*** frieder <frieder!~frieder@i577B9367.versanet.de> has joined #yocto | 07:37 | |
*** mckoan|away is now known as mckoan | 07:39 | |
yocton | If I read that correctly, the strategy will be to assign CVE to most of the bug fixes (i.e the cve number will dramatically increase) | 07:40 |
mcfrisk_ | that's what I think too. I hope the database and networks scale... gigabytes of CVE data | 07:42 |
yocton | WIP Doc is here https://lore.kernel.org/lkml/2024021430-blanching-spotter-c7c8@gregkh/ | 07:43 |
yocton | mcfrisk_: there may be more CVE but as long as they have better CPE data than now, it should be easier for us (cve_check will do most of the work) | 07:45 |
*** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has joined #yocto | 07:46 | |
yocton | No CVE for unmaintained kernel. This will make interesting dashboards... | 07:49 |
yocton | No published CVE without a merged fix first | 07:53 |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…) | 07:54 | |
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has joined #yocto | 07:56 | |
yocton | This will definitely push people towards stable branches (which is a good thing IMHO).... or bury their head in the sand with unmaintained/CVE-free kernels. | 07:56 |
mcfrisk_ | heads in sand already, and vendors claiming that's ok and good enough grr /rants | 07:58 |
yocton | "it is going to be interesting to watch; popcorn is recommended." -- the LWN article :) | 08:00 |
*** rfuentess <rfuentess!~rfuentess@adijon-159-1-11-151.w92-161.abo.wanadoo.fr> has joined #yocto | 08:10 | |
polprog | is there a way to avoid cleaning the whole project to rebuild the rootfs after I updated my distro conf? | 08:14 |
polprog | I've changed EXTRA_USERS_PARAMS and I want to rebuild the rootfs, but running 'bitbake foo-image' (this is the name of my image .bb) the .wic file is not updated | 08:15 |
polprog | alternative question, how do i find out which task uses that variable to invalidate it and re-run all steps that depend on it? | 08:16 |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 08:19 | |
mcfrisk_ | polprog: "bitbake -e foo-image" and check EXTRA_USERS_PARAMS variable. if the effective variable, e.g. contents, did not change, then image is not recreated | 08:21 |
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 08:23 | |
polprog | oh, my bad | 08:24 |
polprog | it actually works by changing the variable, i had a different problem :) | 08:24 |
polprog | (forgot that usermod -p takes a hash, not a password, thats why my assignment didnt work) | 08:25 |
*** Thorn_ <Thorn_!~Thorn@bl18-149-68.dsl.telepac.pt> has joined #yocto | 08:31 | |
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 268 seconds) | 08:33 | |
*** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (Ping timeout: 252 seconds) | 08:37 | |
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has joined #yocto | 08:38 | |
*** rob_w <rob_w!~rob@2001:a61:6137:6801:b516:cf26:a678:7eca> has joined #yocto | 08:39 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto | 08:46 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 08:46 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:48 | |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…) | 08:48 | |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 08:51 | |
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Remote host closed the connection) | 08:55 | |
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 08:55 | |
mckoan | polprog: bitbake -C image -> force image generation (-C is uppercase) | 09:16 |
RP | yocton: the implication is that if you are using a maintained stable tree, you have no CVEs | 09:23 |
polprog | mckoan: thanks! | 09:31 |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 09:33 | |
yocton | RP: yes! Or, if you're not up-to-date, only the CVEs that are fixable by an upgrade. | 09:36 |
RP | yocton: it is an interesting strategy :) | 09:37 |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…) | 09:37 | |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 09:39 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 260 seconds) | 09:45 | |
*** goliath <goliath!~goliath@user/goliath> has left #yocto (SIGILL) | 09:45 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 09:45 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 09:45 | |
polprog | apparently usermod in EXTRA_USERS_PARAMS does not support -6 type hashes? | 09:51 |
polprog | still something is wrong.. | 09:52 |
polprog | i've got EXTRA_USERS_PARAMS = "useradd user; usermod -p ${PW_HASH} user;" | 09:53 |
polprog | but escaping the PW_HASH=.. value doesnt work, the $-parts are susbtituted with empty strings | 09:54 |
polprog | so PW_HASH = "\$1\$IW9RRezN\$Y2koUDS0xs.P1bSn9fRU8." | 09:54 |
polprog | becomes .P1bSn9fRU8. in /etc/shadow | 09:54 |
polprog | (this hash is a test hash, dont worry) | 09:54 |
polprog | how should i do it? | 09:55 |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto | 09:57 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 09:57 | |
polprog | i forgot the ' in usermod invocation. it now works. rtfm | 10:05 |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 10:09 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 10:16 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 255 seconds) | 10:16 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:25 | |
*** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 10:25 | |
*** pvogelaar <pvogelaar!~pvogelaar@p200300efdf036100127b44fffe802df7.dip0.t-ipconnect.de> has joined #yocto | 10:34 | |
pvogelaar | Hi all, in the SRC_URI I specify a source in my_source.tar.zip. Unzip and untar works find and the source land in a directory named my_source.tar. Is there a way to tell the fetch to name the directory just my_source instead of my_source.tar? | 10:36 |
mckoan | pvogelaar: rename my_source.tar.zip in my_source.zip ? | 10:39 |
pvogelaar | oh, now I see. It is not even a tar it is just called *.tar. Thx for the hint and sorry for the stupid question | 10:42 |
*** pasherring <pasherring!~paulo@179.223.234.96> has joined #yocto | 11:15 | |
pasherring | Hello, all =) One question regarding sstate-cache. What are a few good reasons for sstate not being used to populate native packages for instance? | 11:17 |
pasherring | I work on a project that uses an outdated version (morty). We work on a handful of packages, and rarely need to change native packages. But, even though I configure sstate-cache to be shared among builds, it is always rebuilding native packages, such as glibc, gcc, cmake etc. | 11:19 |
rburton | pasherring: glibc isn't native | 11:20 |
rburton | pasherring: but are the host OSs all the same? | 11:20 |
rburton | native sstate is per-host unless you use uninative, and i'm not sure if that existed in morty | 11:20 |
pasherring | rburton, yes, the reference is my host machine only for now. | 11:21 |
rburton | should work then. | 11:21 |
pasherring | :\ Are there any "metadata smells" that could lead to that? I looked for things with ${AUTOREV}, but only found a target package that was using it. | 11:22 |
rburton | not for stuff like cmake-native. can you replicate with _just_ an unmodified poky and no other layers? | 11:31 |
pasherring | I can try to strip off the layers, but, wouldn't quite reproduce the issue as the image is our own. I'll try, anyway, to build with poky only and let you know. | 11:34 |
kanavin | pasherring, it's perhaps easiest to start with a blank cache, make a build, then make another build (which is supposed to use items from the first build but does not) | 11:35 |
kanavin | pasherring, then you can inspect the cache for two copies of each item where there should be just one | 11:35 |
kanavin | pasherring, once you find them, use bitbake-diffsigs and it will tell you what is the difference between them in the metadata that caused a rebuild | 11:36 |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds) | 11:36 | |
kanavin | it's probable there's something silly like inserting current date and time at the root of the metadata | 11:36 |
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 11:36 | |
kanavin | or other host-specific info such as build paths | 11:37 |
rburton | if you think you can replicate on demand then definitely try with just poky instead of trying to strip your setup down, that will tell you if poky itself is good. also, morty is ancient, please upgrade. | 11:37 |
kanavin | rburton, it's probably not that project, but current mercedes benz cars run it :D | 11:38 |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 11:38 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto | 11:38 | |
kanavin | upcoming will be on dunfell, just as it goes EOL | 11:38 |
pasherring | I wish we could do that, we are broadcom locked, and the effort to upgrade everything else, including outdated broadcom layers, are just too big :( | 11:40 |
kanavin | how are you ensuring security of the product? | 11:40 |
pasherring | I, myself, am not :| But the company try to shield itself by hiring some security assessment services. | 11:41 |
kanavin | even then, there will be at some point a business requirement that can't be fulfilled without updating to modern yocto. at that point the cost of that update will enormous. | 11:43 |
pasherring | It already is not viable, due to the use of broadcom stuff. | 11:44 |
pasherring | Broadcom delivers a bundled package with lots of dependencies and built-in packages that are formal recipes in the yocto world. | 11:45 |
rburton | this is when you threaten to switch hardware provider, or just write your own bsp using their patches as a start. | 11:48 |
kanavin | rburton, enter evil ancient vendor kernel with thousands of patches | 11:54 |
rburton | well, yeah | 12:01 |
* Crofton sighs the bottom up approach explaining best practices is failing | 12:01 | |
RP | "Don't build a Frankenstein OS" becomes "Don't use a Frankenstein Vendor" ? :) | 12:02 |
Crofton | LOL | 12:02 |
RP | LetoThe2nd: I'm not sure we can say that but... | 12:02 |
Crofton | Here is a video of rburton and kanavin explaining best practices to an engineer: https://youtube.com/watch?v=_Gsz7Gu6agA | 12:03 |
LetoThe2nd | RP: oh I can say that! | 12:05 |
LetoThe2nd | RP: https://www.linkedin.com/posts/josef-holzmayr_have-you-ever-wondered-why-i-chose-the-yocto-activity-7163817114087202817-6OxR | 12:06 |
LetoThe2nd | literally this morning. | 12:06 |
RP | :D | 12:06 |
rburton | ha | 12:07 |
kanavin | someone has to check the emperor is not naked | 12:08 |
kanavin | might as well be LetoThe2nd | 12:08 |
LetoThe2nd | kanavin: why should I care if the emperor is naked or not? | 12:09 |
kanavin | jester's job is telling uncomfortable truths that the courtiers will never say? | 12:09 |
LetoThe2nd | kanavin: well if said emperor despises clothes and his entourage consents, then why should it be an uncomfortable truth? | 12:11 |
RP | LetoThe2nd: https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes | 12:11 |
LetoThe2nd | translation to embedded linux: while in this group there often is consensus about best practises and such, reality and decision makers sometimes disagree and are happy with it. | 12:12 |
LetoThe2nd | RP: I know the tale :-) | 12:12 |
RP | LetoThe2nd: ok, it was just the the emperor in question didn't despise clothes :) | 12:13 |
LetoThe2nd | RP: indeed. | 12:13 |
kanavin | Linus (not the embedded one) does work in bathrobes, and he mentioned that proudly | 12:14 |
* RP thinks some information doesn't need to be shared | 12:15 | |
* LetoThe2nd hmmmmmmmssssss | 12:15 | |
LetoThe2nd | but again then, why should we care. | 12:16 |
Crofton | kanavin: should I post a selfie? | 12:16 |
RP | LetoThe2nd: the point was that in that case, the emperor was being scammed but nobody would tell him. Presumably people should care about that happening but who knows, perhaps nobody liked him. | 12:17 |
LetoThe2nd | Crofton: my CM for YP role requires me to demand this not taking place here. my social media role for OE asks you to go ahead, this will get clicks! | 12:17 |
Crofton | Why do we care? If vendors want to ship for bitcoin miners or botnet nodes, why shoudl we care as long as we get paid to help them? | 12:17 |
LetoThe2nd | RP: if we translate the story to real life YP, then actually its more like that the emperor knows that he's being treated badly, but he'll have to bear with it because finding a new tailor is going to cost him multiple times the scammed money. | 12:19 |
RP | YP doesn't have an emperor ;-) | 12:20 |
*** lexano <lexano!~lexano@174.119.69.134> has joined #yocto | 12:22 | |
Crofton | Reality is always messier than fiction. | 12:22 |
LetoThe2nd | RP: the emperor, at least in my understanding, is the PO/C-level/whatever in charge of a specific product being locked into a Frankenvendor. We can all be Jesters and tell them, but reality in their situation and life just is different. Been there way too long myself. | 12:22 |
kanavin | there's still a poetic justice in that situation | 12:25 |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Quit: Client closed) | 12:26 | |
kanavin | neglect product sustainability, and you'll pay for it, in the shape of product becoming increasingly unviable | 12:26 |
pasherring | Regarding that sstate stuff, I just moved stuff around, deleted the tmp folder and the sstate was not (re)used. I do see some setscene action going on, but then it starts basically from scratch, including native stuff :\ | 12:39 |
RP | pasherring: it could have been the hash equivalence database | 12:40 |
RP | in cache rather than tmp/cache iirc | 12:40 |
*** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-006-166.um10.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds) | 12:46 | |
kanavin | RP: it's on morty | 12:47 |
RP | kanavin: oh, who knows then. | 12:48 |
RP | we have fixed bugs | 12:48 |
pasherring | RP, after a quick search, I couldn't understand the concept :( | 12:49 |
kanavin | pasherring, hash equivalence was added long after morty, so you needn't worry about that. You should proceed as I suggested. | 12:50 |
*** prabhakar48 <prabhakar48!~prabhakar@217.163.141.2> has joined #yocto | 12:50 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 12:50 | |
pasherring | But, I just noticed that the issue (if it is morty, is it still an issue though?) is path sensitive. | 12:50 |
*** Guest95 <Guest95!~Guest95@62.159.41.246> has joined #yocto | 12:51 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 264 seconds) | 12:51 | |
pasherring | I.e., if the newly checked out build has the exact same path as the build that generated the sstate-cache, it will be reused. | 12:51 |
rburton | with pristine poky or your layers too? | 12:52 |
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has joined #yocto | 12:53 | |
pasherring | Mine as well. Still didn't managed to split things. | 12:53 |
rburton | well if you can say that sstate isn't used for eg cmake-native then do your reproducer with just poky and cmake-native, and then you'll know if its a poky thing or a your-layer thing | 12:54 |
*** prabhakar48 <prabhakar48!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 260 seconds) | 12:54 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 12:54 | |
*** sev99 <sev99!~sev99@pool-108-32-48-117.pitbpa.fios.verizon.net> has joined #yocto | 12:57 | |
kanavin | pasherring, this looks like the build path is included into a variable that affects even the most core native recipes. I suspect some oddity in one of the custom layers. To find out, you really need to find two sstate signatures in the cache for the same object coming from builds in different paths and compare them. | 12:57 |
pasherring | kanavin, these should all be relative path for this to be avoided, correct? | 13:01 |
rburton | build paths shouldn't be counted at all for sstate purposes | 13:01 |
kanavin | pasherring, not necessarily. Find what the issue is first. | 13:01 |
Guest95 | Hi, | 13:02 |
Guest95 | To create a smaller image size, I want to disable/remove the systemd service and include the sysvinit in IMX8. To do this I have added the following code in local.conf. | 13:02 |
Guest95 | DISTRO_FEATURES:remove = " systemd" | 13:02 |
Guest95 | INIT_MANAGER = "sysvinit" | 13:02 |
Guest95 | VIRTUAL-RUNTIME_init_manager = "sysvinit" | 13:02 |
Guest95 | VIRTUAL-RUNTIME_initscripts = "initscripts" | 13:02 |
Guest95 | VIRTUAL-RUNTIME_login_manager = "busybox" | 13:02 |
Guest95 | By adding this I get the error: | 13:02 |
Guest95 | ERROR: /work/new_yocto/varasicte/sources/meta-openembedded/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (sysvinit) matches the entries enabled in DISTRO_FEATURES | 13:02 |
Guest95 | ERROR: Parsing halted due to errors, see error messages above | 13:02 |
Guest95 | I don't understand this error. any help would be appreciated | 13:02 |
rburton | you can just set INIT_MANAGER=sysvinit | 13:02 |
rburton | note that sysvinit is the default, so that tells me your using a custom (imx8 provided?) distro. just make your own and set INIT_MANAGER directly instead of using local.conf. | 13:04 |
Guest95 | I already tried by setting INIT_MANAGER=sysvinit in local.conf. Even this gives the same error : | 13:05 |
Guest95 | ERROR: /data/work/sunil/new_yocto/varasicte/sources/poky/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (systemd) matches the entries enabled in DISTRO_FEATURES | 13:05 |
Guest95 | ERROR: Parsing halted due to errors, see error messages above | 13:05 |
rburton | most likely the distro you're using is poking at the features itself and you're fighting it. | 13:06 |
rburton | which is why you should make your own distro | 13:06 |
kanavin | Guest95, you can read the packagegroup.bbclass to see where the error comes from, and what variables are being checked there. Then use bitbake -e to find out what sets them and where. | 13:08 |
rburton | 99% sure its because DISTRO_FEATURES doesn't have sysvinit in | 13:08 |
kanavin | and what rburton said: local.conf is the wrong place to set those things. Adjust the original distro, or make your own. | 13:08 |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto | 13:10 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 13:10 | |
Guest95 | I'm using fslc-xwayland distro. May I know any bare minimal distro where I can use sysvinit. | 13:12 |
kanavin | Guest95, poky as a starting point is okay, although it enabled a lot of things you may not need | 13:13 |
kanavin | it uses sysvinit by default even, so you can just set DISTRO="poky" | 13:14 |
kanavin | you should have meta-poky in your layers somewhere | 13:14 |
kanavin | most likely | 13:14 |
Xogium | that is, if imx does the right thing | 13:14 |
kanavin | yeah, I suspect a lot of things have never been tested with anything except that vendor distro and may break | 13:16 |
Xogium | I tried to use poky to get started with yocto, but truth be told, it was very overwhelming to me. I understood better when I used the simplest-yocto-setup from bootlin | 13:16 |
Xogium | nothing against poky, but it just was doing WAY too much for my brain I guess ;) | 13:17 |
Guest95 | thanks for info. I will check it out | 13:23 |
mckoan | Guest95: i.MX8 doesn't like sysvinit and doesn't work with X11, you have to use (x)wayland | 13:34 |
mckoan | Guest95: you have a system alredy tailored to your system | 13:35 |
*** kanavin_ <kanavin_!~Alexander@2a02:2454:299:c100:b25:37c3:ea9f:574c> has joined #yocto | 13:53 | |
*** kanavin <kanavin!~Alexander@2a02:2454:299:c100:b25:37c3:ea9f:574c> has quit IRC (Read error: Connection reset by peer) | 13:54 | |
*** Tyaku_ <Tyaku_!~Tyaku@bub62-h03-89-84-109-199.dsl.sta.abo.bbox.fr> has joined #yocto | 14:00 | |
Tyaku_ | Hello is it possible to apply a patch for a specific distro AND specific machine ? for exemple: SRC_URI:append:mydistro:mymachine = " file://mypatch.patch " | 14:07 |
Saur | Tyaku_: Yes, it will work. Just be aware of the implications of machine specific changes in a recipe. | 14:15 |
Tyaku_ | @Saur, With my syntax the meaning is "Append the patch in SRC_URI if we build with DISTRO=mydistro AND MACHINE=mymachine right ? (I mean, it's not a OR ?) | 14:17 |
Saur | Correct. | 14:18 |
Tyaku_ | Also the documentations about these things is only "3.3 Conditional Syntax (Overrides)" ? | 14:18 |
Tyaku_ | Becasue there is no example with a "AND" like what I try to do | 14:18 |
*** luc4 <luc4!~luca@2a00:6d43:501:1201:2ae6:b51b:84f9:47a5> has joined #yocto | 14:19 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 255 seconds) | 14:20 | |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 14:20 | |
*** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 14:22 | |
luc4 | Hello! I recently ported my image recipe to nanbield and recompiled everything. Apparently the resulting image seems to have the entire rootfs with owner set to 1000 instead of 0. Any idea why? | 14:24 |
rburton | does that happen for eg core-image-minimal? | 14:24 |
luc4 | rburton: I did not try, but I can do it | 14:25 |
luc4 | rburton: 1000 is the id of a user I create with useradd however. I suspect it is somehow related. | 14:25 |
rburton | how are you looking at the ownership of the files in the rootfs? on the target? | 14:26 |
luc4 | rburton: I noticed it on the target, but I'm now mounting the image directly in my linux machine | 14:27 |
rburton | possibly your useradd is confusing things | 14:27 |
luc4 | I'll try to remove that | 14:27 |
luc4 | In testing something like this, should I simply rebuild the image or should I also somehow clean it up? | 14:29 |
rburton | just rebuild, that should be fine | 14:29 |
luc4 | thanks | 14:29 |
luc4 | rburton: I removed everything related to that user, but permissions did not change. Do you have any advice on how to debug this? | 14:36 |
rburton | luc4: fresh poky clone, bitbake core-image-minimal, verify that at least generates an image with correct perms. | 14:37 |
luc4 | rburton: thanks | 14:38 |
luc4 | actually, 1000 is also the id of my user on the host machine | 14:39 |
rburton | indeed | 14:40 |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.10> has joined #yocto | 14:40 | |
*** prabhakar <prabhakar!~prabhakar@217.163.141.10> has joined #yocto | 14:40 | |
*** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 14:41 | |
luc4 | the fact that I'm running on wsl2 inside a docker container may not help | 14:41 |
rburton | a custom container or a well tested one? | 14:45 |
rburton | (crops, kas) | 14:45 |
luc4 | rburton: it is the same I was using with kirkstone | 14:46 |
luc4 | however, I built a different image a couple of hours ago and permissions were just fine | 14:46 |
*** Xagen <Xagen!~Xagen@098-006-114-013.biz.spectrum.com> has joined #yocto | 15:14 | |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds) | 15:21 | |
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 15:22 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 15:31 | |
Ad0 | is there a built in way to modify sysctl.conf ? | 15:38 |
Ad0 | I want to disable ipv6 | 15:38 |
rburton | Ad0: ipv6 is the glorious future, but if you want to have to ipv6 then don't build it in your kernel | 15:47 |
rburton | (and remove the ipv6 DISTRO_FEATURE to remove the user-space code that supports it) | 15:47 |
rburton | "no ipv6", even | 15:47 |
Ad0 | there's like 10000 variables hehe | 15:47 |
Ad0 | I had a docker container connecting to localhost and it got ::1 | 15:47 |
Ad0 | that pissed me off | 15:47 |
rburton | that's the glorious future! | 15:48 |
Ad0 | I am fine with just doing it in sysctl.conf | 15:48 |
Ad0 | haha | 15:48 |
Ad0 | I guess making a bbappend for poky/meta/recipes-extended/procps/procps_3.3.17.bb ? | 15:49 |
Ad0 | put my file in /etc/sysctl.d | 15:51 |
*** joekale <joekale!~quassel@2620:a2:6000:13:60b1:3995:e320:ceb9> has joined #yocto | 15:52 | |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds) | 15:53 | |
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 15:54 | |
*** Tyaku_ <Tyaku_!~Tyaku@bub62-h03-89-84-109-199.dsl.sta.abo.bbox.fr> has quit IRC (Quit: Lost terminal) | 15:59 | |
pasherring | Are there tools to dump/compare siginfo files? Since I haven't really looked into this siginfo files, I really can't tell, but here is the dump of a do_compile for cmake, for instance https://pastebin.com/e1puAb2P | 16:11 |
Saur | pasherring: bitbake-dumpsig and bitbake-diffsigs are what you are looking for. | 16:12 |
*** luc4 <luc4!~luca@2a00:6d43:501:1201:2ae6:b51b:84f9:47a5> has quit IRC (Quit: Konversation terminated!) | 16:13 | |
pasherring | Saur, thanks! | 16:13 |
*** rfuentess <rfuentess!~rfuentess@adijon-159-1-11-151.w92-161.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 16:15 | |
*** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has quit IRC (Ping timeout: 268 seconds) | 16:17 | |
*** brrm <brrm!~brrm@2a02:8071:b700::1c89> has joined #yocto | 16:19 | |
pasherring | Is it too bad that siginfo of the same package for builds in different paths result in dictionaries ordered differently, but the same content? | 16:19 |
pasherring | Apparently, `bitbake-diffsigs` reports empty string. | 16:24 |
rburton | pasherring: in the last decade of work post-morty, lots of dictionaries and lists were sorted for that exact reason | 16:29 |
pasherring | Right :/ | 16:32 |
tlwoerner | qschulz: i know you're probably busy, but do you have any opinion on the 4 patches i submitted for meta-rockchip at the start of the week? i'm hoping to apply them soon-ish | 16:45 |
qschulz | tlwoerner: I actually have an opinion :D | 16:47 |
*** joekale <joekale!~quassel@2620:a2:6000:13:60b1:3995:e320:ceb9> has quit IRC (Ping timeout: 272 seconds) | 16:56 | |
*** joekale <joekale!~quassel@204.156.190.21> has joined #yocto | 16:56 | |
khem | RP: I see that you have mesa-24 upgrade staged, with that we wont need the mesa: Fix build with llvm 18 patch that I sent, its only needed with mesa-23 | 16:57 |
khem | RP: you have it staged in master-next so you can remove it if we have mesa-24 | 16:57 |
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has quit IRC (Quit: Leaving.) | 17:01 | |
tlwoerner | qschulz: i appreciate your opinions | 17:01 |
tlwoerner | (i might not agree, by i do appreciate) | 17:02 |
qschulz | tlwoerner: i'm sure you won't agree with the ones I'm going to give you :0 | 17:04 |
qschulz | :) | 17:04 |
*** joekale <joekale!~quassel@204.156.190.21> has quit IRC (Ping timeout: 272 seconds) | 17:08 | |
*** joekale <joekale!~quassel@204.156.190.21> has joined #yocto | 17:08 | |
*** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 264 seconds) | 17:11 | |
*** joekale <joekale!~quassel@204.156.190.21> has quit IRC (Ping timeout: 264 seconds) | 17:13 | |
*** joekale_ <joekale_!~quassel@2620:a2:6000:13:3b2a:e81a:6284:2070> has joined #yocto | 17:13 | |
*** rob_w <rob_w!~rob@2001:a61:6137:6801:b516:cf26:a678:7eca> has quit IRC (Quit: Leaving) | 17:13 | |
RP | khem: I was actually just checking that, thanks! | 17:16 |
*** mckoan is now known as mckoan|away | 17:18 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 17:27 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 17:31 | |
*** linfax <linfax!~linfax@eumail.topcon.com> has quit IRC (Ping timeout: 264 seconds) | 17:35 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #yocto | 17:37 | |
*** simonew <simonew!~ile@2a02:810d:a940:35fc:e6fb:248a:e411:d55> has joined #yocto | 17:44 | |
qschulz | tlwoerner: done | 17:48 |
nerdboy | moin | 17:51 |
*** bhstalel <bhstalel!~bhstalel@196.237.14.53> has joined #yocto | 17:58 | |
khem | RP: regarding RISCV failures, the hang in my runs is due to a local fix I am doing to touch the configure to avoid timestamp issue, configure keeps running in a loop mindlessly, so atleast I know the reason. | 18:02 |
khem | I think we need to get to root cause of system time issue that cpio builds are reporting | 18:03 |
khem | it could be a bug in lower layers of s/w | 18:03 |
*** Guest95 <Guest95!~Guest95@62.159.41.246> has quit IRC (Quit: Client closed) | 18:03 | |
khem | what I was trying was to bypass it and see if there are more failures left | 18:03 |
khem | in general RV64 is in a relatively good shape, where we can say its not tier1 but tier2 architecture in LTS ( worst case ) | 18:04 |
khem | which means we dont need whole sale backports but tests could be improved ( fixed ) | 18:05 |
*** florian__ <florian__!~florian@dynamic-093-131-148-062.93.131.pool.telefonica.de> has joined #yocto | 18:12 | |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds) | 18:35 | |
*** hus <hus!~hus@147.161.136.110> has joined #yocto | 18:44 | |
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has quit IRC (Read error: Connection reset by peer) | 18:45 | |
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has joined #yocto | 18:46 | |
hus | I have two build systems, an old one with debian 4.19.0-21-amd64 and a newer one with debian 6.1.0-13-amd64. Buildwith the old one private kernel modules get not signed. Using the newer one this works. Problem is the older one is the official server. Any ideas? | 18:48 |
khem | hus: how do you sign the kmods ? | 18:51 |
khem | IOW whats the dependency on build system kernel | 18:51 |
hus | Not explicitly. Just the config set: CONFIG_MODULE_SIG=y | 18:52 |
hus | CONFIG_MODULE_SIG_ALL=y | 18:52 |
hus | CONFIG_MODULE_SIG_FORCE=y | 18:52 |
hus | CONFIG_MODULE_SIG_SHA256=y | 18:52 |
hus | CONFIG_MODULE_SIG_SHA512=y | 18:52 |
hus | CONFIG_MODULE_SIG_HASH="sha512" | 18:52 |
hus | CONFIG_MODULE_COMPRESS=y | 18:52 |
hus | # CONFIG_MODULE_COMPRESS_GZIP is not set | 18:52 |
hus | CONFIG_MODULE_COMPRESS_XZ=y | 18:52 |
hus | CONFIG_CRYPTO_SHA1=y | 18:52 |
hus | CONFIG_CRYPTO_SHA256=y | 18:52 |
hus | CONFIG_CRYPTO_SHA512=y | 18:52 |
khem | does 4.19 have kmod signing support ? | 18:54 |
hus | I have to check. what is the flags name? | 18:55 |
khem | I guess it was added in 3.7 so you should be ok | 18:56 |
khem | firstly I am not clear on your setup, are you building yocto on top of this debian system ? | 18:57 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 18:57 | |
khem | and using yocto to create images which should have signed kernel mods ? | 18:57 |
*** hus <hus!~hus@147.161.136.110> has quit IRC (Quit: Client closed) | 18:58 | |
*** florian__ <florian__!~florian@dynamic-093-131-148-062.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 19:02 | |
*** amitk <amitk!~amit@58.84.61.226> has quit IRC (Remote host closed the connection) | 19:06 | |
*** hus <hus!~hus@147.161.136.110> has joined #yocto | 19:07 | |
*** amitk <amitk!~amit@58.84.61.226> has joined #yocto | 19:08 | |
*** joekale_ <joekale_!~quassel@2620:a2:6000:13:3b2a:e81a:6284:2070> has quit IRC (Ping timeout: 272 seconds) | 19:24 | |
*** joekale <joekale!~quassel@204.156.190.21> has joined #yocto | 19:24 | |
*** sev99 <sev99!~sev99@pool-108-32-48-117.pitbpa.fios.verizon.net> has quit IRC (Quit: Client closed) | 19:28 | |
*** florian__ <florian__!~florian@dynamic-093-131-148-062.93.131.pool.telefonica.de> has joined #yocto | 19:30 | |
*** frieder <frieder!~frieder@i577B9367.versanet.de> has quit IRC (Remote host closed the connection) | 19:52 | |
*** wmills_ <wmills_!~wmills@pool-72-83-14-124.washdc.fios.verizon.net> has joined #yocto | 20:03 | |
*** joekale <joekale!~quassel@204.156.190.21> has quit IRC (Ping timeout: 246 seconds) | 20:05 | |
*** joekale <joekale!~quassel@2620:a2:6000:13:4ea3:c464:d1a3:1627> has joined #yocto | 20:06 | |
*** Xagen <Xagen!~Xagen@098-006-114-013.biz.spectrum.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:10 | |
*** amitk <amitk!~amit@58.84.61.226> has quit IRC (Ping timeout: 264 seconds) | 20:23 | |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…) | 20:36 | |
*** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 20:48 | |
*** pasherring_ <pasherring_!~paulo@179.223.234.96> has joined #yocto | 20:56 | |
*** pasherring <pasherring!~paulo@179.223.234.96> has quit IRC (Read error: Connection reset by peer) | 20:57 | |
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 21:01 | |
*** Thorn_ <Thorn_!~Thorn@bl18-149-68.dsl.telepac.pt> has quit IRC (Ping timeout: 264 seconds) | 21:02 | |
*** pasherring_ <pasherring_!~paulo@179.223.234.96> has quit IRC (Ping timeout: 261 seconds) | 21:04 | |
*** pasherring <pasherring!~paulo@179.223.234.96> has joined #yocto | 21:08 | |
*** pasherring <pasherring!~paulo@179.223.234.96> has quit IRC (Ping timeout: 255 seconds) | 21:13 | |
*** bhstalel <bhstalel!~bhstalel@196.237.14.53> has quit IRC (Read error: Connection reset by peer) | 21:23 | |
RP | khem: I somehow need to get to the point of clean builds with riscv though | 21:27 |
RP | khem: even if we have to just disable some things | 21:27 |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Killed (NickServ (GHOST command used by florian__!~florian@dynamic-093-131-148-062.93.131.pool.telefonica.de))) | 21:28 | |
*** florian__ is now known as florian | 21:28 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 21:28 | |
*** hus <hus!~hus@147.161.136.110> has quit IRC (Quit: Client closed) | 21:38 | |
*** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-006-166.um10.pools.vodafone-ip.de> has joined #yocto | 21:45 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Ping timeout: 240 seconds) | 22:04 | |
khem | yeah. | 22:15 |
khem | btw. I see you dropped LLVM upgrade along with vulkan-samples | 22:15 |
khem | they are unrelated | 22:16 |
khem | so you can still keep llvm upgrade | 22:16 |
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:904d:2e61:c367:a752> has quit IRC (Remote host closed the connection) | 22:16 | |
khem | that will be good. I will meanwhile fix the issue with vulkan-samples for 32bit | 22:16 |
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.10> has quit IRC (Quit: Client closed) | 22:28 | |
RP | khem: I was confused as they seemed to be in an llvm series together | 22:33 |
RP | khem: the llvm version number also seems a little odd to me - 18.1.0 ? | 22:34 |
*** joekale <joekale!~quassel@2620:a2:6000:13:4ea3:c464:d1a3:1627> has quit IRC (Ping timeout: 268 seconds) | 22:46 | |
*** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 22:47 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 22:55 | |
*** simonew <simonew!~ile@2a02:810d:a940:35fc:e6fb:248a:e411:d55> has quit IRC (Ping timeout: 264 seconds) | 23:58 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!