Thursday, 2024-02-15

*** florian__ <florian__!~florian@dynamic-093-131-181-193.93.131.pool.telefonica.de> has joined #yocto00:14
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto00: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 #yocto00: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 #yocto01: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 #yocto02:05
*** benkard <benkard!~mulk@pd95149fd.dip0.t-ipconnect.de> has joined #yocto02:24
*** mulk <mulk!~mulk@p5b2dce88.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 272 seconds)02:25
*** benkard is now known as mulk02: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 #yocto02: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 #yocto03:37
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto03:37
*** npcomp <npcomp!~user@user/npcomp> has joined #yocto03: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 #yocto04: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 #yocto04:55
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto05: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 #yocto05: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 #yocto06:03
salahaldeenIncluding Python3 modules in generated SDK do not work (python3-node-semver, kirkstone)06:03
salahaldeenHello,06:04
salahaldeenI 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 this06:04
salahaldeenIMAGE_INSTALL:append = " python3-node-semver"06:04
*** mulk <mulk!~mulk@p5b2dc13b.dip0.t-ipconnect.de> has joined #yocto06:04
salahaldeenTOOLCHAIN_HOST_TASK += " python3-node-semver "06:04
salahaldeenhttps://layers.openembedded.org/layerindex/recipe/333689/06:04
salahaldeenbut still not working, python3-node-semver is available on the target but not in the host SDK!! Any idea what this happening?06:04
salahaldeenRegards,06:04
salahaldeenSalahaldeen06:04
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto06: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 #yocto06:29
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto06: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 #yocto06:46
*** linfax <linfax!~linfax@eumail.topcon.com> has joined #yocto07:13
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:30
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:904d:2e61:c367:a752> has joined #yocto07:31
*** Chaser_ <Chaser_!~Chaser@user/chaser> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)07:32
yoctonAbout 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 #yocto07: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 #yocto07:37
*** mckoan|away is now known as mckoan07:39
yoctonIf 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 data07:42
yoctonWIP Doc is here https://lore.kernel.org/lkml/2024021430-blanching-spotter-c7c8@gregkh/07:43
yoctonmcfrisk_: 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 #yocto07:46
yoctonNo CVE for unmaintained kernel. This will make interesting dashboards...07:49
yoctonNo published CVE without a merged fix first07: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 #yocto07:56
yoctonThis 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 /rants07: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 #yocto08:10
polprogis there a way to avoid cleaning the whole project to rebuild the rootfs after I updated my distro conf?08:14
polprogI'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 updated08:15
polprogalternative 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 #yocto08: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 recreated08:21
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has quit IRC (Ping timeout: 255 seconds)08:23
polprogoh, my bad08:24
polprogit 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 #yocto08: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 #yocto08:38
*** rob_w <rob_w!~rob@2001:a61:6137:6801:b516:cf26:a678:7eca> has joined #yocto08:39
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto08:46
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto08:46
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto08: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 #yocto08: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 #yocto08:55
mckoanpolprog: bitbake -C image -> force image generation (-C is uppercase)09:16
RPyocton: the implication is that if you are using a maintained stable tree, you have no CVEs09:23
polprogmckoan: thanks!09:31
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto09:33
yoctonRP: yes! Or, if you're not up-to-date, only the CVEs that are fixable by an upgrade.09:36
RPyocton: 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 #yocto09: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 #yocto09:45
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds)09:45
polprogapparently usermod in EXTRA_USERS_PARAMS does not support -6 type hashes?09:51
polprogstill something is wrong..09:52
polprogi've got EXTRA_USERS_PARAMS = "useradd user; usermod -p ${PW_HASH} user;"09:53
polprogbut escaping the PW_HASH=.. value doesnt work, the $-parts are susbtituted with empty strings09:54
polprogso PW_HASH = "\$1\$IW9RRezN\$Y2koUDS0xs.P1bSn9fRU8."09:54
polprogbecomes .P1bSn9fRU8. in /etc/shadow09:54
polprog(this hash is a test hash, dont worry)09:54
polproghow should i do it?09:55
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto09:57
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto09:57
polprogi forgot the  ' in usermod invocation. it now works. rtfm10: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 #yocto10:25
*** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto10:25
*** pvogelaar <pvogelaar!~pvogelaar@p200300efdf036100127b44fffe802df7.dip0.t-ipconnect.de> has joined #yocto10:34
pvogelaarHi 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
mckoanpvogelaar: rename my_source.tar.zip in my_source.zip ?10:39
pvogelaaroh, now I see. It is not even a tar it is just called *.tar.  Thx for the hint and sorry for the stupid question10:42
*** pasherring <pasherring!~paulo@179.223.234.96> has joined #yocto11:15
pasherringHello, 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
pasherringI 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
rburtonpasherring: glibc isn't native11:20
rburtonpasherring: but are the host OSs all the same?11:20
rburtonnative sstate is per-host unless you use uninative, and i'm not sure if that existed in morty11:20
pasherringrburton, yes, the reference is my host machine only for now.11:21
rburtonshould 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
rburtonnot for stuff like cmake-native.  can you replicate with _just_ an unmodified poky and no other layers?11:31
pasherringI 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
kanavinpasherring, 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
kanavinpasherring, then you can inspect the cache for two copies of each item where there should be just one11:35
kanavinpasherring, once you find them, use bitbake-diffsigs and it will tell you what is the difference between them in the metadata that caused a rebuild11:36
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds)11:36
kanavinit's probable there's something silly like inserting current date and time at the root of the metadata11:36
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto11:36
kanavinor other host-specific info such as build paths11:37
rburtonif 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
kanavinrburton, it's probably not that project, but current mercedes benz cars run it :D11:38
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto11:38
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has joined #yocto11:38
kanavinupcoming will be on dunfell, just as it goes EOL11:38
pasherringI 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
kanavinhow are you ensuring security of the product?11:40
pasherringI, myself, am not :| But the company try to shield itself by hiring some security assessment services.11:41
kanavineven 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
pasherringIt already is not viable, due to the use of broadcom stuff.11:44
pasherringBroadcom delivers a bundled package with lots of dependencies and built-in packages that are formal recipes in the yocto world.11:45
rburtonthis is when you threaten to switch hardware provider, or just write your own bsp using their patches as a start.11:48
kanavinrburton, enter evil ancient vendor kernel with thousands of patches11:54
rburtonwell, yeah12:01
* Crofton sighs the bottom up approach explaining best practices is failing12:01
RP"Don't build a Frankenstein OS" becomes "Don't use a Frankenstein Vendor" ? :)12:02
CroftonLOL12:02
RPLetoThe2nd: I'm not sure we can say that but...12:02
CroftonHere is a video of rburton and kanavin explaining best practices to an engineer: https://youtube.com/watch?v=_Gsz7Gu6agA12:03
LetoThe2ndRP: oh I can say that!12:05
LetoThe2ndRP: https://www.linkedin.com/posts/josef-holzmayr_have-you-ever-wondered-why-i-chose-the-yocto-activity-7163817114087202817-6OxR12:06
LetoThe2ndliterally this morning.12:06
RP:D12:06
rburtonha12:07
kanavinsomeone has to check the emperor is not naked12:08
kanavinmight as well be LetoThe2nd12:08
LetoThe2ndkanavin: why should I care if the emperor is naked or not?12:09
kanavinjester's job is telling uncomfortable truths that the courtiers will never say?12:09
LetoThe2ndkanavin: well if said emperor despises clothes and his entourage consents, then why should it be an uncomfortable truth?12:11
RPLetoThe2nd: https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes12:11
LetoThe2ndtranslation 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
LetoThe2ndRP: I know the tale :-)12:12
RPLetoThe2nd: ok, it was just the the emperor in question didn't despise clothes :)12:13
LetoThe2ndRP: indeed.12:13
kanavinLinus (not the embedded one) does work in bathrobes, and he mentioned that proudly12:14
* RP thinks some information doesn't need to be shared12:15
* LetoThe2nd hmmmmmmmssssss12:15
LetoThe2ndbut again then, why should we care.12:16
Croftonkanavin: should I post a selfie?12:16
RPLetoThe2nd: 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
LetoThe2ndCrofton: 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
CroftonWhy 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
LetoThe2ndRP: 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
RPYP doesn't have an emperor ;-)12:20
*** lexano <lexano!~lexano@174.119.69.134> has joined #yocto12:22
CroftonReality is always messier than fiction.12:22
LetoThe2ndRP: 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
kanavinthere's still a poetic justice in that situation12:25
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Quit: Client closed)12:26
kanavinneglect product sustainability, and you'll pay for it, in the shape of product becoming increasingly unviable12:26
pasherringRegarding 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
RPpasherring: it could have been the hash equivalence database12:40
RPin cache rather than tmp/cache iirc12:40
*** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-006-166.um10.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds)12:46
kanavinRP: it's on morty12:47
RPkanavin: oh, who knows then.12:48
RPwe have fixed bugs12:48
pasherringRP, after a quick search, I couldn't understand the concept :(12:49
kanavinpasherring, 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 #yocto12:50
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto12:50
pasherringBut, 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 #yocto12:51
*** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 264 seconds)12:51
pasherringI.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
rburtonwith pristine poky or your layers too?12:52
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has joined #yocto12:53
pasherringMine as well. Still didn't managed to split things.12:53
rburtonwell 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 thing12: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 #yocto12:57
kanavinpasherring, 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
pasherringkanavin, these should all be relative path for this to be avoided, correct?13:01
rburtonbuild paths shouldn't be counted at all for sstate purposes13:01
kanavinpasherring, not necessarily. Find what the issue is first.13:01
Guest95Hi,13:02
Guest95To 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
Guest95DISTRO_FEATURES:remove = " systemd"13:02
Guest95INIT_MANAGER = "sysvinit"13:02
Guest95VIRTUAL-RUNTIME_init_manager = "sysvinit"13:02
Guest95VIRTUAL-RUNTIME_initscripts = "initscripts"13:02
Guest95VIRTUAL-RUNTIME_login_manager = "busybox"13:02
Guest95By adding this I get the error:13:02
Guest95ERROR: /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_FEATURES13:02
Guest95ERROR: Parsing halted due to errors, see error messages above13:02
Guest95I don't understand this error. any help would be appreciated13:02
rburtonyou can just set INIT_MANAGER=sysvinit13:02
rburtonnote 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
Guest95I already tried by setting INIT_MANAGER=sysvinit in local.conf. Even this gives the same error :13:05
Guest95ERROR: /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_FEATURES13:05
Guest95 ERROR: Parsing halted due to errors, see error messages above13:05
rburtonmost likely the distro you're using is poking at the features itself and you're fighting it.13:06
rburtonwhich is why you should make your own distro13:06
kanavinGuest95, 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
rburton99% sure its because DISTRO_FEATURES doesn't have sysvinit in13:08
kanavinand 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 #yocto13:10
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto13:10
Guest95I'm using fslc-xwayland distro. May I know any bare minimal distro where I can use sysvinit.13:12
kanavinGuest95, poky as a starting point is okay, although it enabled a lot of things you may not need13:13
kanavinit uses sysvinit by default even, so you can just set DISTRO="poky"13:14
kanavinyou should have meta-poky in your layers somewhere13:14
kanavinmost likely13:14
Xogiumthat is, if imx does the right thing13:14
kanavinyeah, I suspect a lot of things have never been tested with anything except that vendor distro and may break13:16
XogiumI 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 bootlin13:16
Xogiumnothing against poky, but it just was doing WAY too much for my brain I guess ;)13:17
Guest95thanks for info. I will check it out13:23
mckoanGuest95: i.MX8 doesn't like sysvinit and doesn't work with X11, you have to use (x)wayland13:34
mckoanGuest95: you have a system alredy tailored to your system13:35
*** kanavin_ <kanavin_!~Alexander@2a02:2454:299:c100:b25:37c3:ea9f:574c> has joined #yocto13: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 #yocto14: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
SaurTyaku_: 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
SaurCorrect.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 do14:18
*** luc4 <luc4!~luca@2a00:6d43:501:1201:2ae6:b51b:84f9:47a5> has joined #yocto14: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 #yocto14:22
luc4Hello! 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
rburtondoes that happen for eg core-image-minimal?14:24
luc4rburton: I did not try, but I can do it14:25
luc4rburton: 1000 is the id of a user I create with useradd however. I suspect it is somehow related.14:25
rburtonhow are you looking at the ownership of the files in the rootfs? on the target?14:26
luc4rburton: I noticed it on the target, but I'm now mounting the image directly in my linux machine14:27
rburtonpossibly your useradd is confusing things14:27
luc4I'll try to remove that14:27
luc4In testing something like this, should I simply rebuild the image or should I also somehow clean it up?14:29
rburtonjust rebuild, that should be fine14:29
luc4thanks14:29
luc4rburton: I removed everything related to that user, but permissions did not change. Do you have any advice on how to debug this?14:36
rburtonluc4: fresh poky clone, bitbake core-image-minimal, verify that at least generates an image with correct perms.14:37
luc4rburton: thanks14:38
luc4actually, 1000 is also the id of my user on the host machine14:39
rburtonindeed14:40
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.10> has joined #yocto14:40
*** prabhakar <prabhakar!~prabhakar@217.163.141.10> has joined #yocto14:40
*** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto14:41
luc4the fact that I'm running on wsl2 inside a docker container may not help14:41
rburtona custom container or a well tested one?14:45
rburton(crops, kas)14:45
luc4rburton: it is the same I was using with kirkstone14:46
luc4however, I built a different image a couple of hours ago and permissions were just fine14:46
*** Xagen <Xagen!~Xagen@098-006-114-013.biz.spectrum.com> has joined #yocto15:14
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds)15:21
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto15:22
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)15:31
Ad0is there a built in way to modify sysctl.conf ?15:38
Ad0I want to disable ipv615:38
rburtonAd0: ipv6 is the glorious future, but if you want to have to ipv6 then don't build it in your kernel15:47
rburton(and remove the ipv6 DISTRO_FEATURE to remove the user-space code that supports it)15:47
rburton"no ipv6", even15:47
Ad0there's like 10000 variables hehe15:47
Ad0I had a docker container connecting to localhost and it got ::115:47
Ad0that pissed me off15:47
rburtonthat's the glorious future!15:48
Ad0I am fine with just doing it in sysctl.conf15:48
Ad0haha15:48
Ad0I guess making a bbappend for poky/meta/recipes-extended/procps/procps_3.3.17.bb ?15:49
Ad0put my file in /etc/sysctl.d15:51
*** joekale <joekale!~quassel@2620:a2:6000:13:60b1:3995:e320:ceb9> has joined #yocto15:52
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)15:53
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto15:54
*** Tyaku_ <Tyaku_!~Tyaku@bub62-h03-89-84-109-199.dsl.sta.abo.bbox.fr> has quit IRC (Quit: Lost terminal)15:59
pasherringAre 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/e1puAb2P16:11
Saurpasherring: 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
pasherringSaur, 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 #yocto16:19
pasherringIs 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
pasherringApparently, `bitbake-diffsigs` reports empty string.16:24
rburtonpasherring: in the last decade of work post-morty, lots of dictionaries and lists were sorted for that exact reason16:29
pasherringRight :/16:32
tlwoernerqschulz: 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-ish16:45
qschulztlwoerner: I actually have an opinion :D16: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 #yocto16:56
khemRP: 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-2316:57
khemRP: you have it staged in master-next so you can remove it if we have mesa-2416:57
*** zpfvo <zpfvo!~fvo@i59F5CEF2.versanet.de> has quit IRC (Quit: Leaving.)17:01
tlwoernerqschulz: i appreciate your opinions17:01
tlwoerner(i might not agree, by i do appreciate)17:02
qschulztlwoerner: i'm sure you won't agree with the ones I'm going to give you :017: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 #yocto17: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 #yocto17:13
*** rob_w <rob_w!~rob@2001:a61:6137:6801:b516:cf26:a678:7eca> has quit IRC (Quit: Leaving)17:13
RPkhem: I was actually just checking that, thanks!17:16
*** mckoan is now known as mckoan|away17:18
*** goliath <goliath!~goliath@user/goliath> has joined #yocto17: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 #yocto17:37
*** simonew <simonew!~ile@2a02:810d:a940:35fc:e6fb:248a:e411:d55> has joined #yocto17:44
qschulztlwoerner: done17:48
nerdboymoin17:51
*** bhstalel <bhstalel!~bhstalel@196.237.14.53> has joined #yocto17:58
khemRP: 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
khemI think we need to get to root cause of system time issue that cpio builds are reporting18:03
khemit could be a bug in lower layers of s/w18:03
*** Guest95 <Guest95!~Guest95@62.159.41.246> has quit IRC (Quit: Client closed)18:03
khemwhat I was trying was to bypass it and see if there are more failures left18:03
khemin general RV64 is in a relatively good shape, where we can say its not tier1 but tier2 architecture in LTS ( worst case )18:04
khemwhich 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 #yocto18:12
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds)18:35
*** hus <hus!~hus@147.161.136.110> has joined #yocto18: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 #yocto18:46
husI 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
khemhus: how do you sign the kmods ?18:51
khemIOW whats the dependency on build system kernel18:51
husNot explicitly. Just the config set: CONFIG_MODULE_SIG=y18:52
husCONFIG_MODULE_SIG_ALL=y18:52
husCONFIG_MODULE_SIG_FORCE=y18:52
husCONFIG_MODULE_SIG_SHA256=y18:52
husCONFIG_MODULE_SIG_SHA512=y18:52
husCONFIG_MODULE_SIG_HASH="sha512"18:52
husCONFIG_MODULE_COMPRESS=y18:52
hus# CONFIG_MODULE_COMPRESS_GZIP is not set18:52
husCONFIG_MODULE_COMPRESS_XZ=y18:52
husCONFIG_CRYPTO_SHA1=y18:52
husCONFIG_CRYPTO_SHA256=y18:52
husCONFIG_CRYPTO_SHA512=y18:52
khemdoes 4.19 have kmod signing support ?18:54
husI have to check. what is the flags name?18:55
khemI guess it was added in 3.7 so you should be ok18:56
khemfirstly 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
khemand 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 #yocto19:07
*** amitk <amitk!~amit@58.84.61.226> has joined #yocto19: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 #yocto19: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 #yocto19: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 #yocto20: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 #yocto20: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 #yocto20: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 #yocto21: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 #yocto21: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
RPkhem: I somehow need to get to the point of clean builds with riscv though21:27
RPkhem: even if we have to just disable some things21: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 florian21:28
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto21: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 #yocto21:45
*** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Ping timeout: 240 seconds)22:04
khemyeah.22:15
khembtw. I see you dropped LLVM upgrade along with vulkan-samples22:15
khemthey are unrelated22:16
khemso you can still keep llvm upgrade22:16
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:904d:2e61:c367:a752> has quit IRC (Remote host closed the connection)22:16
khemthat will be good. I will meanwhile fix the issue with vulkan-samples for 32bit22:16
*** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.10> has quit IRC (Quit: Client closed)22:28
RPkhem: I was confused as they seemed to be in an llvm series together22:33
RPkhem: 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 #yocto22: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 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!