Monday, 2021-01-18

marexlinums: prevented how ? pastebin the error message00:04
*** manuel1985 <manuel1985!> has quit IRC00:04
marexlinums: git grep ln..s in oe-core has plenty of examples00:05
linumsmarex: maybe it's specific to oath? They use the /usr/lib path, but I created a symlink under /lib to the proper so, so this became the end of it:00:07
linumsERROR: oath-2.6.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk- package contains symlink .so: oath path '/work/core2-64-poky-linux/oath/2.6.2-r0/packages-split/oath/lib/security/' [dev-so]00:07
*** dev1990 <dev1990!> has quit IRC00:07
*** manuel1985 <manuel1985!> has joined #yocto00:21
*** sakoman <sakoman!> has joined #yocto00:22
*** eduardas <eduardas!> has quit IRC00:26
*** sesom <sesom!> has joined #yocto00:29
*** sesom <sesom!> has quit IRC00:34
*** sakoman <sakoman!> has quit IRC00:35
*** v0n <v0n!> has quit IRC00:46
*** v0n <v0n!> has joined #yocto00:47
*** sakoman <sakoman!~steve@> has joined #yocto00:49
*** v0n <v0n!> has quit IRC00:53
*** v0n <v0n!> has joined #yocto00:54
*** linums <linums!~linums@> has quit IRC01:01
*** linums <linums!> has joined #yocto01:01
*** Anarky <Anarky!~Anarky@2a01:cb14:585:6700:baac:6fff:fea4:58b5> has quit IRC01:06
*** Kyubi <Kyubi!~Kyubi@> has quit IRC01:13
*** Anarky <Anarky!~Anarky@2a01:cb14:585:6700:baac:6fff:fea4:58b5> has joined #yocto01:24
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto01:29
*** manuel1985 <manuel1985!> has quit IRC01:29
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto01:34
*** Kyubi <Kyubi!~Kyubi@> has quit IRC01:41
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC01:43
*** linums <linums!> has quit IRC01:44
*** linums <linums!> has joined #yocto01:46
*** sakoman1 <sakoman1!~steve@> has joined #yocto01:56
*** sakoman <sakoman!~steve@> has quit IRC01:57
*** linums <linums!> has quit IRC02:02
*** linums <linums!~linums@> has joined #yocto02:03
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:05
*** JPEW_ <JPEW_!~JPEW@2605:a601:ac3d:c100:4f37:550:d1b1:6f01> has joined #yocto02:10
*** sakoman1 <sakoman1!~steve@> has quit IRC02:10
*** linums <linums!~linums@> has quit IRC02:14
*** linums <linums!~linums@> has joined #yocto02:14
*** sesom <sesom!> has joined #yocto02:18
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC02:18
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto02:19
*** gourve_l <gourve_l!> has quit IRC02:19
*** abelloni <abelloni!> has quit IRC02:19
*** abelloni <abelloni!> has joined #yocto02:19
*** gourve_l <gourve_l!> has joined #yocto02:19
*** JPEW_ <JPEW_!~JPEW@2605:a601:ac3d:c100:4f37:550:d1b1:6f01> has quit IRC02:20
*** gnac <gnac!> has quit IRC02:20
*** gnac <gnac!> has joined #yocto02:20
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC02:22
*** sesom <sesom!> has quit IRC02:23
*** v0n <v0n!> has quit IRC02:23
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto02:26
*** v0n <v0n!> has joined #yocto02:26
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC02:30
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto02:32
*** alicef_ <alicef_!~none@gentoo/developer/alicef> has joined #yocto02:36
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC02:36
*** B0ned1ger <B0ned1ger!> has quit IRC02:38
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto02:38
*** alicef_ <alicef_!~none@gentoo/developer/alicef> has quit IRC02:39
*** amerigo <amerigo!uid331857@gateway/web/> has quit IRC02:39
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto02:41
*** linums <linums!~linums@> has quit IRC02:51
*** linums <linums!> has joined #yocto02:52
*** linums <linums!~linums@> has joined #yocto02:55
*** denix0 <denix0!> has joined #yocto03:12
*** denix <denix!> has quit IRC03:13
*** denix0 is now known as denix03:13
*** B0ned1ger <B0ned1ger!> has joined #yocto03:19
*** B0ned1ger2 <B0ned1ger2!> has quit IRC03:22
*** gourve_l <gourve_l!> has quit IRC03:22
*** abelloni <abelloni!> has quit IRC03:22
*** abelloni <abelloni!> has joined #yocto03:22
*** gourve_l <gourve_l!> has joined #yocto03:22
*** gnac <gnac!> has quit IRC03:22
*** gnac <gnac!> has joined #yocto03:23
*** ahadi <ahadi!~ahadi@> has quit IRC03:24
*** ahadi <ahadi!> has joined #yocto03:25
*** camus <camus!~Instantbi@> has joined #yocto03:35
*** kaspter <kaspter!~Instantbi@> has quit IRC03:36
*** camus is now known as kaspter03:36
*** Kyubi <Kyubi!> has joined #yocto03:40
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC03:43
*** Kyubi <Kyubi!> has quit IRC03:48
*** B0ned1ger <B0ned1ger!> has quit IRC04:38
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto04:38
*** sesom <sesom!> has joined #yocto04:51
*** goliath <goliath!> has joined #yocto05:28
*** camus <camus!~Instantbi@> has joined #yocto05:32
*** kaspter <kaspter!~Instantbi@> has quit IRC05:33
*** camus is now known as kaspter05:33
*** sesom <sesom!> has quit IRC05:39
*** sesom <sesom!> has joined #yocto05:39
*** sesom <sesom!> has quit IRC05:43
*** sesom <sesom!> has joined #yocto05:44
*** sesom <sesom!> has quit IRC06:08
*** beneth <beneth!> has joined #yocto06:08
*** jobroe <jobroe!> has joined #yocto06:17
*** w00die <w00die!~w00die@> has quit IRC06:30
*** w00die <w00die!~w00die@> has joined #yocto06:32
*** AndersD <AndersD!> has joined #yocto06:37
*** AndersD_ <AndersD_!> has joined #yocto06:39
*** AndersD <AndersD!> has quit IRC06:42
*** sesom <sesom!> has joined #yocto06:45
*** sesom <sesom!> has quit IRC06:51
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:54
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:04
*** minimaxwell <minimaxwell!> has joined #yocto07:06
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC07:07
*** LocutusOfBorg <LocutusOfBorg!~locutusof@2001:b07:5d32:c012:74b4:6109:e60b:7241> has joined #yocto07:07
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto07:07
*** linums <linums!~linums@> has quit IRC07:09
*** linums <linums!> has joined #yocto07:18
*** pharaon2502 <pharaon2502!> has joined #yocto07:20
*** sesom <sesom!> has joined #yocto07:28
*** sesom <sesom!> has quit IRC07:29
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:29
*** sesom <sesom!> has joined #yocto07:29
*** sesom <sesom!> has quit IRC07:34
*** sesom <sesom!> has joined #yocto07:38
*** camus <camus!~Instantbi@> has joined #yocto07:43
*** frsc <frsc!> has joined #yocto07:43
*** kaspter <kaspter!~Instantbi@> has quit IRC07:44
*** camus is now known as kaspter07:44
*** rob_w_ <rob_w_!> has joined #yocto07:44
*** sesom_ <sesom_!> has joined #yocto07:44
*** sesom <sesom!> has quit IRC07:46
*** rob_w_ <rob_w_!> has quit IRC07:47
*** rob_w_ <rob_w_!> has joined #yocto07:47
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC07:48
*** rob_w_ <rob_w_!> has quit IRC07:49
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:50
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:51
*** alessioigor <alessioigor!> has joined #yocto07:55
*** sesom_ <sesom_!> has quit IRC07:58
*** sesom <sesom!> has joined #yocto07:58
*** fl0v0 <fl0v0!> has joined #yocto08:00
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto08:00
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto08:02
*** mckoan|away is now known as mckoan08:03
mckoangood morning08:03
LetoThe2ndyo dudX08:08
*** manuel1985 <manuel1985!> has joined #yocto08:24
*** Ad0 <Ad0!~Ad0@> has quit IRC08:26
*** Ad0 <Ad0!~Ad0@> has joined #yocto08:31
*** sesom <sesom!> has quit IRC08:31
*** dev1990 <dev1990!> has joined #yocto08:36
*** qschulz <qschulz!> has joined #yocto08:42
*** kaspter <kaspter!~Instantbi@> has quit IRC08:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:49
*** rnouse <rnouse!> has joined #yocto08:53
*** wooosaiiii <wooosaiiii!> has joined #yocto08:54
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has quit IRC09:00
*** sesom <sesom!> has joined #yocto09:05
*** sesom <sesom!> has quit IRC09:09
*** hch <hch!~x@unaffiliated/hch> has quit IRC09:12
*** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC09:12
*** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto09:14
*** hch <hch!~x@unaffiliated/hch> has joined #yocto09:14
*** rnouse <rnouse!> has quit IRC09:16
*** rnouse <rnouse!> has joined #yocto09:21
*** sesom <sesom!> has joined #yocto09:22
*** oberstet <oberstet!~oberstet@> has joined #yocto09:27
*** rnouse <rnouse!> has quit IRC09:31
*** Bunio_FH <Bunio_FH!> has joined #yocto09:50
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto09:52
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC09:53
paulbarkermanuel1985: Thanks!09:58
*** creich <creich!> has quit IRC10:08
paulbarkerRP: We know that creating files under pseudo and then deleting them outside pseudo can cause issues. How about the other way round?10:09
paulbarkerIs it safe to delete files under pseudo which were created outside of a pseudo context?10:09
*** creich <creich!> has joined #yocto10:11
manuel1985paulbarker: Well, thank you ;)10:12
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC10:22
*** dleppich <dleppich!> has joined #yocto10:26
RPpaulbarker: that is safe10:29
RPpaulbarker: the reason that external deletion causes problems is potential inode reuse. That doesn't happen the other way around10:29
paulbarkerRP: Ok, that makes sense. I'm trying to work out how the `tmp-wic` directory ends up in the pseudo db10:30
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto10:30
paulbarkerIt's created by bitbake as it's listed in `do_image_wic[cleandirs]`, then deleted by wic (still outside pseudo, I missed that the line which runs wic has `PSEUDO_UNLOAD=1`)10:31
RPpaulbarker: the creation by bitbake is probably under pseudo then?10:32
*** dleppich <dleppich!> has quit IRC10:32
paulbarkerRP: Doesn't look like it. It's created in `exec_func()` before FAKEROOT is even checked10:32
*** dleppich <dleppich!> has joined #yocto10:34
RPpaulbarker: the entire of bitbake-worker for peseudo tasks runs under pseudo10:34
paulbarkerRP: I missed that fact! Was just looking at `lib/bb/`10:34
*** manuel1985 <manuel1985!> has quit IRC10:35
RPpaulbarker: right, there is code in bitbake-worker for that10:35
paulbarkerThat could explain it. Bitbake creates the dir under pseudo, wic runs with `PSEUDO_UNLOAD=1` and deletes it10:35
RPthat would be bad, yes10:35
paulbarkerI'm not sure we even need that dir in `do_image_wic[cleandirs]` if wic creates and deletes the dir itself10:35
paulbarkerMy only concern is if wic dies part way through and leaves a junk dir behind10:36
paulbarkerRP: I'll modify it so that wic handles that directory internally, drop it from `do_image_wic[cleandirs]` and re-submit the patches10:38
paulbarkerThat should hopefully do the trick10:38
RPpaulbarker: sounds good10:38
qschulzpaulbarker: don't forget about people with a ctrl+c frenziness which stops builds unexpectedly. Making sure the dir is cleaned is not too bad?10:39
RPqschulz: I believe paulbarker will sort internally to wic10:39
paulbarkerqschulz: I think wic should bail if the workdir already exists. Then in do_image_wic we can check for an old workdir and delete it if present10:42
paulbarkerThat avoids the risk of someone shooting themselves in the foot, I don't want wic to unconditionally remove the workdir at startup or `wic -w ~` would become a foot-gun10:42
paulbarkerDeleting an old workdir in do_image_wic should be safe as it will have been created outside of a pseudo context10:43
*** emrius <emrius!> has joined #yocto10:46
emriusGood day! I would like to run a filesystem check on every boot. On a raspbian I could do that by adding `fsck=force` to `/proc/cmdline`. Is that the right thing to do? do I need to enable kernel modules for that or should that run out of the box?10:48
emriusI mean I would like to do that on my bitbaked image.10:48
*** tprrt <tprrt!> has quit IRC10:55
*** tprrt <tprrt!> has joined #yocto11:00
LetoThe2ndemrius: i would rather start thinking about a) why do you expect fs corruption? b) what will you do if the check fails?11:03
LetoThe2ndemrius: and, this suggests that you are using a systemd feature. so if the feature is waht you want and your image is using systemd, then it is probably the (most) right thing to do.11:06
*** camus <camus!~Instantbi@> has joined #yocto11:08
*** kaspter <kaspter!~Instantbi@> has quit IRC11:08
*** camus is now known as kaspter11:08
*** rnouse <rnouse!> has joined #yocto11:08
emriusLetoThe2nd: Thanks! We are currently running our system from an SD card. I thought that enforcing a filesystem repair e.g. after power failure might prevent corrupted root filesystems.11:13
*** rnouse <rnouse!> has quit IRC11:13
emriusWe are using systemd thus, that makes it much easier to apply! awesome11:13
LetoThe2ndemrius: depending on the rest of your system archicture that might or might not be a good idea.11:16
emriuswhat would be reasons not to do that?11:18
emriusdespite longer booting time of course11:19
LetoThe2ndprimarily the longer boot time. but also means of actually handling the problems.11:20
emriusBoot time is not critical for us. I mean, sure, it's kind of risky to leave it to the system to do that on its own but our devices are running headless very remote. Thus, if anything is fixable I think it might be best to just give it a shot...11:23
emriusLet's see how that turns out11:23
emriusOk, but coming back to `/proc/cmdline` :/ I actually have to set other parameters as well such as `isolcpu` to stabilize some acquisition thread running on one core.
emriusI could copy the current `/proc/cmdline` and (I think) override the `CONFIG_CMDLINE` kernel option. Or can I append to that kernel option somehow? Or maybe even the classic way: CONFIG_CMDLINE_append = "isolcpus=1" ?11:27
*** mort <mort!~mort96@snow/mort96> has quit IRC11:29
qschulzemrius: are you using u-boot?11:37
qschulzif yes, just add your stuff to the bootargs env variable, that's where the kernel parameters are defined before being passed to the kernel11:37
*** B0ned1ger2 <B0ned1ger2!> has quit IRC11:38
*** B0ned1ger <B0ned1ger!> has joined #yocto11:38
*** tgoodwin <tgoodwin!> has joined #yocto11:48
*** rnouse <rnouse!> has joined #yocto11:49
*** kpo_ <kpo_!> has quit IRC12:06
*** kpo_ <kpo_!> has joined #yocto12:07
*** sesom <sesom!> has quit IRC12:15
*** ad__ <ad__!~prefetch@unaffiliated/ad/x-0785363> has quit IRC12:18
*** __ad <__ad!~prefetch@2a01:4f8:c2c:5a84::1> has joined #yocto12:18
*** rob_w_ <rob_w_!> has joined #yocto12:21
*** linums <linums!> has quit IRC12:24
*** linums <linums!~linums@> has joined #yocto12:24
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC12:25
*** minimaxwell <minimaxwell!> has quit IRC12:32
*** minimaxwell <minimaxwell!> has joined #yocto12:33
*** __ad <__ad!~prefetch@2a01:4f8:c2c:5a84::1> has quit IRC12:41
*** __ad <__ad!~prefetch@unaffiliated/ad/x-0785363> has joined #yocto12:41
*** __ad is now known as ad__12:42
*** jft <jft!znc@> has quit IRC12:44
emriusqschulz: sorry for the late reply. Lunch break. Yes, I'm using u-boot. Thanks for the clarification!12:45
*** micka <micka!> has quit IRC12:46
*** frsc <frsc!> has quit IRC12:47
*** jft <jft!znc@> has joined #yocto12:47
*** sesom <sesom!> has joined #yocto12:47
*** micka <micka!> has joined #yocto12:47
*** Sponge5 <Sponge5!> has joined #yocto12:48
*** Chaser <Chaser!> has quit IRC12:48
Sponge5I added NetworkManager as a IMAGE_INSTALL_append and apparently it automagically added it to systemd services, can I expect that to happen to openssh too, or should I configure it?12:49
Sponge5I'll check anyway12:51
*** Sponge5 <Sponge5!> has quit IRC12:51
*** sesom <sesom!> has quit IRC12:54
*** Chaser <Chaser!> has joined #yocto12:54
*** kanavin_home <kanavin_home!~Srain@2a02:2450:1011:512:45a5:1b3d:84d2:e7fc> has quit IRC12:56
*** pbb <pbb!> has quit IRC12:56
*** xroumegue <xroumegue!~roumegue@2a01:cb1d:3f5:3900:2d77:9b3d:e4b1:719> has quit IRC12:56
*** agaikova <agaikova!> has quit IRC12:56
*** yangm <yangm!yanyetanot@gateway/shell/> has quit IRC12:56
*** nslu2-log <nslu2-log!> has quit IRC12:56
*** Fanfwe <Fanfwe!> has quit IRC12:56
*** ahadi <ahadi!> has quit IRC12:59
*** frsc <frsc!> has joined #yocto12:59
*** rcoote <rcoote!> has joined #yocto12:59
*** kanavin_home <kanavin_home!~Srain@2a02:2450:1011:512:45a5:1b3d:84d2:e7fc> has joined #yocto12:59
*** pbb <pbb!> has joined #yocto12:59
*** xroumegue <xroumegue!~roumegue@2a01:cb1d:3f5:3900:2d77:9b3d:e4b1:719> has joined #yocto12:59
*** agaikova <agaikova!> has joined #yocto12:59
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto12:59
*** nslu2-log <nslu2-log!> has joined #yocto12:59
*** Fanfwe <Fanfwe!> has joined #yocto12:59
*** RobertBerger <RobertBerger!> has joined #yocto12:59
*** Bernkastel-sama <Bernkastel-sama!~Rika-chan@unaffiliated/carlgel> has quit IRC12:59
RobertBergerIt looks like trace-cmd and perf install the same stuff to ${libdir}/traceevent/plugins13:00
RobertBergerDid someone else notice this?13:01
*** ahadi <ahadi!> has joined #yocto13:01
*** CarlGel <CarlGel!~Rika-chan@unaffiliated/carlgel> has joined #yocto13:01
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has quit IRC13:02
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC13:02
*** alephan <alephan!andreicubi@gateway/shell/> has quit IRC13:02
*** paulbarker_tmp <paulbarker_tmp!pbarkermat@gateway/shell/> has quit IRC13:02
*** guillaume <guillaume!gscigalama@gateway/shell/> has quit IRC13:02
*** jonesv[m] <jonesv[m]!jonesvmatr@gateway/shell/> has quit IRC13:03
*** olani[m] <olani[m]!olanimatri@gateway/shell/> has quit IRC13:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto13:03
*** yangm <yangm!yanyetanot@gateway/shell/> has quit IRC13:03
*** codetronaut[m] <codetronaut[m]!anmolkmatr@gateway/shell/> has quit IRC13:03
*** enick_764 <enick_764!khemmatrix@gateway/shell/> has quit IRC13:03
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC13:03
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/> has quit IRC13:03
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has quit IRC13:06
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC13:06
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has quit IRC13:07
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC13:07
*** guillaume <guillaume!gscigalama@gateway/shell/> has joined #yocto13:19
*** jonesv[m] <jonesv[m]!jonesvmatr@gateway/shell/> has joined #yocto13:19
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/> has joined #yocto13:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:21
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto13:21
*** olani[m] <olani[m]!olanimatri@gateway/shell/> has joined #yocto13:23
*** codetronaut[m] <codetronaut[m]!anmolkmatr@gateway/shell/> has joined #yocto13:25
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto13:26
*** enick_764 <enick_764!khemmatrix@gateway/shell/> has joined #yocto13:30
*** paulbarker_tmp <paulbarker_tmp!pbarkermat@gateway/shell/> has joined #yocto13:30
*** linums <linums!~linums@> has quit IRC13:30
*** linums <linums!> has joined #yocto13:31
*** guillaume <guillaume!gscigalama@gateway/shell/> has quit IRC13:34
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC13:34
*** codetronaut[m] <codetronaut[m]!anmolkmatr@gateway/shell/> has quit IRC13:34
*** paulbarker_tmp <paulbarker_tmp!pbarkermat@gateway/shell/> has quit IRC13:34
*** enick_764 <enick_764!khemmatrix@gateway/shell/> has quit IRC13:34
*** vmeson <vmeson!> has quit IRC13:34
*** jonesv[m] <jonesv[m]!jonesvmatr@gateway/shell/> has quit IRC13:35
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC13:35
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/> has quit IRC13:35
*** olani[m] <olani[m]!olanimatri@gateway/shell/> has quit IRC13:35
*** linums <linums!> has quit IRC13:36
*** linums <linums!~linums@> has joined #yocto13:36
*** linums <linums!~linums@> has quit IRC13:41
*** linums <linums!> has joined #yocto13:41
*** sakoman <sakoman!~steve@> has joined #yocto13:43
*** vmeson <vmeson!> has joined #yocto13:44
*** rnouse <rnouse!> has quit IRC13:48
*** linums <linums!> has quit IRC13:49
*** linums <linums!~linums@> has joined #yocto13:49
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has joined #yocto13:49
*** rnouse <rnouse!> has joined #yocto13:50
*** alephan <alephan!andreicubi@gateway/shell/> has joined #yocto13:51
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto13:55
*** tgoodwin <tgoodwin!> has quit IRC13:55
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto13:58
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto13:59
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto14:00
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has joined #yocto14:00
*** jonesv[m] <jonesv[m]!jonesvmatr@gateway/shell/> has joined #yocto14:03
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto14:04
*** sesom <sesom!> has joined #yocto14:04
*** enick_764 <enick_764!khemmatrix@gateway/shell/> has joined #yocto14:05
*** guillaume <guillaume!gscigalama@gateway/shell/> has joined #yocto14:06
*** paulbarker_tmp <paulbarker_tmp!pbarkermat@gateway/shell/> has joined #yocto14:06
*** olani[m] <olani[m]!olanimatri@gateway/shell/> has joined #yocto14:06
*** codetronaut[m] <codetronaut[m]!anmolkmatr@gateway/shell/> has joined #yocto14:06
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/> has joined #yocto14:06
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto14:06
*** ericch <ericch!> has joined #yocto14:12
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC14:13
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto14:14
*** ssajal <ssajal!> has joined #yocto14:18
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:22
*** kaspter <kaspter!~Instantbi@> has quit IRC14:28
*** linums <linums!~linums@> has quit IRC14:31
*** linums <linums!> has joined #yocto14:32
*** sgw <sgw!> has joined #yocto14:39
*** linums <linums!> has quit IRC14:43
*** linums <linums!> has joined #yocto14:44
*** tgoodwin <tgoodwin!> has joined #yocto14:50
*** ericch <ericch!> has quit IRC14:54
*** yifany <yifany!~yifan@> has joined #yocto15:07
*** linums <linums!> has quit IRC15:08
*** linums <linums!> has joined #yocto15:09
*** minimaxwell <minimaxwell!> has quit IRC15:13
*** linums <linums!> has quit IRC15:15
*** Bunio_FH <Bunio_FH!> has quit IRC15:16
*** linums <linums!> has joined #yocto15:16
*** alexm_ <alexm_!> has joined #yocto15:16
*** alexm_ <alexm_!> has quit IRC15:17
*** rcoote <rcoote!> has quit IRC15:18
*** minimaxwell <minimaxwell!> has joined #yocto15:19
*** ericch <ericch!> has joined #yocto15:20
v0nhi there15:21
qschulzv0n: o/15:23
v0nIf I'm building an initramfs for preinit things, like mounting squashfs overlays before switching root etc., should I define the image recipe as a depedence for core-image-minimal (or any custom ones) or should I somehow force it in the machine/distro conf?15:23
LetoThe2ndv0n: i would rather go multiconfig to create a build-in-bild15:26
LetoThe2nd*build-in-build, even15:26
v0nLetoThe2nd: I'm still not sure to understand the use case for multiconfig15:28
qschulzLetoThe2nd: does it bring something if the machines are identical?15:28
LetoThe2ndyou want to ship a root filesystem which carries a kernel, which in turn has an initramfs bundled, right?15:28
v0nhum no, I would have used a single kernel, an initramfs for preinit, which mounts stuffs and switch root to a persistent partition15:30
LetoThe2ndbut you have two rootfs involved.15:30
LetoThe2ndwhich will probably run different DISTROs15:30
v0nor it can be the same with some root detection logic, but you can imagine having different init systems (sysvinit vs. systemd for example), so yes 2 different rootfs.15:31
*** Bunio_FH <Bunio_FH!> has joined #yocto15:31
qschulzso yes, two different DISTROs even15:32
*** kpo_ <kpo_!> has quit IRC15:32
v0nLetoThe2nd: yeah that's something I'm still not confortable with. Is this case using two different distros, or two images of the same distro?15:32
LetoThe2ndonce different inits are involved you are runnind two DISTROs and therefore are in multiconfig land.15:32
LetoThe2ndqschulz: cue #1 please.15:32
*** rcoote <rcoote!> has joined #yocto15:32
*** kpo_ <kpo_!> has joined #yocto15:33
*** ericch <ericch!> has quit IRC15:33
v0nqschulz: LetoThe2nd: this is targetting the SD card. If I wanted to build a bootable image for the eMMC, would this be a third distro?15:35
LetoThe2ndv0n: probably more like a second machine.15:35
*** roussinm <roussinm!> has joined #yocto15:36
dleppichHi, I am struggling with bitbake chosing the wrong recipe version. I have a layer from a client providing a recipe for keyutils in version 1.5.10. In the dunfell version of meta-openembedded, there is a newer recipe for keyutils. 'bitbake-layers show-recipes keyutils' correctly lists both of them:15:36
dleppich=== Matching recipes: ===15:36
dleppich  meta-client        1.5.1015:36
dleppich  meta-oe              1.6.115:36
dleppichWhen I perform 'bitbake keyutils' it still starts to build version 1.5.10 and I don't know why. I was looking for a 'PREFERRED_VERSION_keyutils..' variable set somewhere but no match.15:36
qschulzv0n: well aren't emmc and sd card more or less the same thing?15:36
qschulzone is removable and not the other but it's pretty much the same thing15:37
qschulzso... not sure it matters?15:37
qschulz(except if you have some scripts/logics/recipes that are different when you are on sdcard vs emmc and you cannot detect this at runtime)15:37
qschulzin which case as LetoThe2nd said, two machines. Or if the differences are minimal, maybe two image recipes but two machines is cleaner15:38
qschulzdleppich: look for BBPRIORITY in conf/layer.conf15:38
*** B0ned1ger <B0ned1ger!> has quit IRC15:38
v0nI see15:38
qschulzthe higher the number the highest the priority of the recipes it contains15:38
*** B0ned1ger <B0ned1ger!> has joined #yocto15:38
v0nthe "flash" machine would have it's own .wic file for the flash layout but the distro image recipe would actually be the same. Maybe even a FitImage or raw squashfs partition on the flash.15:39
qschulzv0n: sd card and emmc are both flash, they can probably both have support for .wic if I'm not mistaken. Distro image recipe does not really exist so it's a bit confusing what you're saying15:40
dleppichqschulz: meta-client is a priority of 9, meta-oe has 6. So does the bitbake only chose higher versions when the layer priorities are equal?15:40
v0nLetoThe2nd: qschulz: the more I learn about yocto, the more I realize that "distro", "machine", and "image" don't have strong meanings, it's more like building blocks to define the granularity of your own use case15:41
LetoThe2ndv0n: au contraire. MACHINE, DISTRO and IMAGE are (almost) orthogonal.15:41
qschulzdleppich: yes15:41
LetoThe2ndv0n: you should be able to switch each one in and out at will.15:42
qschulzI cna understand the difference between distro and image is hard to grasp, it took me some time too. As LetoThe2nd said, see distro as lego vs mechano and image as boat vs car. The distro defines "how" you build something (init system, opengl support, etc...), the image what you build15:43
*** ericch <ericch!> has joined #yocto15:44
v0n( qschulz: about distro images, I mean that image recipes are distro specific and go into a distro layer usually, don't they? )15:44
qschulzand there is one important thing to remember, recipes cannot share information between themselves. Yes... image recipes too. So when you want to make two recipes have the same configuration, you need a configuration file (distro or "it depends")15:45
qschulzv0n: there is no such thing as distro images. There are distro configuration files which are nothing without any recipe to build (image and package recipes). Therea re image recipes which are nothing without a distro configuration file for configuring them15:45
qschulzdistro layer only has usually distro specific stuff. meaning the distro configuration file and distro specific bbappends or patches or classes etc.15:46
v0nqschulz: I talked about "distro images" because in my mind I was imagining that an "ubuntu" distro layer existed, it would provide "ubuntu" and "ubuntu-devel" image recipes for example, while core-image-minimal are the bare image recipes for a functional target15:50
v0nso in my case (standard distro vs. the preinit scripts), you guys would defined two distros (e.g. foo and foo-preinit) and build what, core-image-minimal for both of them?15:51
LetoThe2ndv0n: its not something "we would". its somethign that doesn't work in another way.15:51
* v0n is still struggling to figure out where to use image recipes vs. extending {IMAGE,PACKAGE}_INSTALL in the distro definition15:52
*** cdgarren <cdgarren!> has joined #yocto15:52
qschulzit's highly unlikely that you won't need to create two image recipes anyway, or make some part of the image recipe distro specific (which I don't recommend)15:52
qschulzcan your distro absolutely NOT work without a package in the image? if yes, then IMAGE_INSTALL is fine-ish. If it does not care, it's not where you should put it but in an image recipe15:53
cdgarrenI'm having an issue with using devtool for a kernel recipe. I have a local file that doesn't get unpacked into my devtool workspace. Anyone have any ideas?15:53
qschulze.g. systemd distro needs systemd15:53
qschulzcdgarren: did you add this file after having run devtool modify?15:53
cdgarrenqschulz No, it was in the recipe beforehand.15:54
qschulzcdgarren: is it not unpacked or not put into the devtool workspace?15:54
qschulz(i.e. are we talking about a tarball that is not extracted or a tarball/file that is not available in the workspace)?15:55
cdgarrenqschulz it's a plaintext .dts file, and it ends up being extracted into the work-shared/kernel-sources directory15:55
cdgarrenMy SRC_URI for the file looks something like this: file://project.dts;subdir=${S}/path/to/subdir/15:56
qschulzI don't use devtool for kernel so can't really help here :/ Especially since the kernel is such a special recipe (work-shared for example)15:57
v0nLetoThe2nd: qschulz: so in my case you would have "fooboard" and "fooboard-emmc" machines, "foodist" and "foodist-preinit" distros and also "foodist" and "foodist-preinit" image recipes, right?15:57
*** cdgarren <cdgarren!> has quit IRC15:57
qschulzv0n: I would triple check that you can't have the same machine for sd card and emmc15:58
qschulzand if it's only a filesystem issue, just build both from the image recipe for sd card and emmc15:58
qschulzotherwise, pretty much on point yes15:59
v0nqschulz: I think we can have the same machine yes, as you said it's both MMC anyway (the size is different for sure) but I would definitely not use the same layout for both storage16:12
qschulzv0n: you have to check if you can use two different wks out of the box16:13
*** cdgarren <cdgarren!> has joined #yocto16:13
qschulzotherwise, you can probably create a new image type instead16:13
qschulzit all depends16:13
*** cdgarren <cdgarren!> has quit IRC16:13
qschulzif there are really no differences apart from those, then two machiens might be overkill though cleaner16:13
roussinmHey folks, how do you handle yocto repository for multiple projects/machine ? Are you able to only use 1 yocto repository for all your machines/projects?16:14
rburtonYou might want to expand on what you mean by 'yocto repository'16:14
v0nroussinm: from what I've understood so far it really depends on what you want to provide. You can have one meta-<company> layer with everything, have one meta-<company> containing meta-<machine1>, meta-<machine2>, meta-<distro>, etc. or even split all these layers into separated git repositories. It all end up to what you need to publish or not (private vs. public layers, etc.)16:16
v0nqschulz: what do you mean by checking if I can use two different wks out of the box? I'd say yes, if let's say for the SD card I want to have a persistent partition for the rootfs while for the eMMC I want to have a raw squashfs partition or even a FitImage containing everthing.16:18
*** rcoote <rcoote!> has quit IRC16:18
paulgroussinm, maybe the answer is as simple as  ".  ./oe-init-build-env build-A "   and in another shell  ". ./oe-init-build-env build-B"16:18
roussinmv0n: thanks! I was wondering that if we take the meta-<company>/meta-<machine1,2> approach, we will probably have a meta-<company>/common recipes and that if you change those recipes you have to make sur that all machines are still properly built.16:19
roussinmpaulg: that's what we have been doing so far, just wanted to see what was the workflow somewhere else.16:20
roussinmpaulg: but both build-a and build-b are different git repositories.16:21
v0nno build-{a,b} are build directories here, not project repositories16:21
*** frsc <frsc!> has quit IRC16:23
qschulzv0n: you can only specify one file in WKS_FILE, so how do you pick which one to build if you have the same recipe and the same machine?16:23
rnouseJPEW, from our last week's discussion:
roussinmv0n: oh right, sorry i was refering to the oe-init-build-env source script.16:24
v0nqschulz: you cannot set WKS_FILE in the image recipe instead of globally in the distro conf?16:24
qschulzv0n: you want two different wks file because you have mmc and sd card -ready artifacts to create16:24
*** rcoote <rcoote!> has joined #yocto16:24
qschulzand they are different is what you said16:24
*** kpo_ <kpo_!> has quit IRC16:25
*** kpo_ <kpo_!> has joined #yocto16:26
v0nqschulz: I thought you can specify the WKS_FILE in the image recipe, so a different file for every image recipes if you'd like. I might have been wrong.16:26
*** AndersD_ <AndersD_!> has quit IRC16:27
qschulzyou would then have foodist-emmc foodist-sdcard foodist-preinit-emmc foodist-preinit-sdcard16:29
v0nthese are 4 image recipes for a single fooboard and two foodist and foodist-preinit distros, right?16:32
*** tgoodwin <tgoodwin!> has quit IRC16:33
*** sesom <sesom!> has quit IRC16:34
*** sesom_ <sesom_!> has joined #yocto16:34
roussinmv0n: when using meta-<company>/meta-<machine1,2> I think it makes sens to use COMPATIBLE_MACHINE in the layer.conf ?16:34
*** frsc <frsc!> has joined #yocto16:35
v0nroussinm: it might depends if the machine are compatible. For example I have a board based on beaglebone and its dev version, which require conf/machine/beaglebone.conf and does MACHINEOVERRIDES =. "beaglebone:". The "dev" variant simple require conf/machine/myboard.conf16:37
qschulzroussinm: no, layers shouldn't break anything if they are included but not used16:37
roussinmqschulz: how could it break anything?16:38
qschulzwhy do you need COMPATIBLE_MACHINE in the first place then?16:38
*** rob_w_ <rob_w_!> has quit IRC16:40
roussinmwell if I use the multi-machine directory approach, when I source the environment, I shouldn't be parsing/building recipes that are not compatible for that build environment.16:40
qschulzif you don't want to parse recipes, don't include the layer16:41
qschulzif you don't want to build a recipe, don't add it to your image recipe16:41
qschulzif some recipes are machine specific, define in those recipes COMPATIBLE_MACHINE16:41
*** sesom <sesom!> has joined #yocto16:42
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto16:42
*** wooosaiii <wooosaiii!> has joined #yocto16:42
qschulz(and make them have PACKAGE_ARCH = "${MACHINE_ARCH}")16:43
roussinmOh I see, so it's probably easier to use bblayers.conf in the build environment to configure that.16:43
qschulzyes, but honestly, except soime cases in which the layers have an enormous number of recipes, i don't think it's worth it to make bblayers.conf dynamic or configurable16:43
qschulzalso, I'm afraid anything in layer.conf actually applies to everything since it predates all recipe parsing (same for local.conf)16:44
*** ssajal <ssajal!> has quit IRC16:44
*** RobertBerger1 <RobertBerger1!> has joined #yocto16:44
*** RobertBerger <RobertBerger!> has quit IRC16:44
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC16:44
*** jobroe_ <jobroe_!> has joined #yocto16:44
*** rcoote <rcoote!> has quit IRC16:44
*** jobroe <jobroe!> has quit IRC16:44
*** rcoote <rcoote!> has joined #yocto16:45
*** sesom_ <sesom_!> has quit IRC16:45
*** ericch <ericch!> has quit IRC16:45
*** B0ned1ger <B0ned1ger!> has quit IRC16:45
*** yifany <yifany!~yifan@> has quit IRC16:45
*** jft <jft!znc@> has quit IRC16:45
*** wooosaiiii <wooosaiiii!> has quit IRC16:45
*** yifany <yifany!~yifan@> has joined #yocto16:46
*** minimaxwell <minimaxwell!> has quit IRC16:46
*** ericch <ericch!> has joined #yocto16:46
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto16:46
*** ssajal <ssajal!> has joined #yocto16:47
qschulzpredates = happens before16:47
roussinmit feels redundant to specify COMPATIBLE_MACHINE in each recipes in a layer named : meta-<machine>, no?16:47
*** jft <jft!znc@> has joined #yocto16:47
v0nroussinm: for what it's worth, this made my life easier in terms of code organization:
*** minimaxwell <minimaxwell!> has joined #yocto16:48
roussinmv0n: thanks, I'll take a look.16:49
*** sesom <sesom!> has quit IRC16:49
*** grma <grma!~gruberm@> has quit IRC17:02
*** fl0v0 <fl0v0!> has quit IRC17:12
*** mckoan is now known as mckoan|away17:12
*** minimaxwell <minimaxwell!> has quit IRC17:15
*** sesom <sesom!> has joined #yocto17:20
*** frsc <frsc!> has quit IRC17:22
*** Kyubi <Kyubi!> has joined #yocto17:26
*** sesom <sesom!> has quit IRC17:26
v0nLetoThe2nd: qschulz: last question, with the machine/distro/images distinction we were talking about, how can I organize my layers so that I end up with a boot partition containing my kernel + the preinit initramfs image, and a persistent partition with the "standard" rootfs? in order words, how do I organize my code to have a single .wic image for SD card containing these two rootfs?17:35
*** Kyubi <Kyubi!> has quit IRC17:35
*** linums <linums!> has quit IRC17:37
*** linums <linums!> has joined #yocto17:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto17:37
*** yifany <yifany!~yifan@> has quit IRC17:40
BCMMi'm having trouble running menuconfig inside the official Poky Docker image. is there a correct way to install libncurses-dev inside the image?17:45
*** Kyubi <Kyubi!> has joined #yocto17:51
rburtonthe crops ones?17:58
rburtontell rewitt to add ncurses-dev? :)17:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:59
*** sesom <sesom!> has joined #yocto17:59
*** Kyubi <Kyubi!> has quit IRC17:59
*** yifany <yifany!~yifan@> has joined #yocto18:03
*** tgoodwin <tgoodwin!> has joined #yocto18:05
*** sesom <sesom!> has quit IRC18:05
RobertBerger1@BCMM or add to the Dockerfile: RUN apt-get -y install libncursesw5-dev18:06
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC18:14
BCMMrburton: looks like somebody already tried that
BCMMRobertBerger1: i'm not really sure what to do with a Dockerfile. i've managed to get things working with `docker exec -u root raspi_dev apt-get install libncurses5-dev libtinfo-dev`, but that does involve downloading the packages again every time i start a container18:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:17
BCMM(also i'm kind of surprised that the image includes package index files; shouldn't i have to run apt update?)18:18
RobertBerger1@BCMM So you don't built the container, I guess.18:18
RobertBerger1@BCMM one option is what you do, but this is not going to stick, once you exit the container it's gone.18:19
*** micka <micka!> has quit IRC18:19
BCMMand yes, i'm pretty much just doing docker run at the moment as suggested, not building the image for myself18:20
RobertBerger1@BCMM another option would be to create your own container, which includes the existing (containers, they are 2 actually)18:21
RobertBerger1@BCMM a third option would be to git clone the crops stuff, extend the Dockerfile as you like and build it yourself18:21
RobertBerger1@BCMM I went for the third option:
RobertBerger1@BCMM for quick test you could try to pull my container: reliableembeddedsystems/poky-container:2020-07-26-master-local-gcc-9-gui-ub1818:25
*** rnouse <rnouse!> has quit IRC18:28
*** linums <linums!> has quit IRC18:32
*** linums <linums!> has joined #yocto18:32
*** linums <linums!> has quit IRC18:37
*** linums <linums!> has joined #yocto18:38
*** sesom <sesom!> has joined #yocto18:38
*** w00die <w00die!~w00die@> has quit IRC18:39
*** w00die <w00die!~w00die@> has joined #yocto18:40
*** sesom <sesom!> has quit IRC18:42
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:46
*** rcw <rcw!~rcwoolley@> has joined #yocto18:47
*** kpo_ <kpo_!> has quit IRC18:47
*** linums <linums!> has quit IRC18:48
*** linums <linums!> has joined #yocto18:48
*** kpo_ <kpo_!> has joined #yocto18:48
v0nHow can I get a single wic image with two rootfs (initramfs in a boot partition and a different persistent rootfs partition)?18:51
*** micka <micka!> has joined #yocto19:03
rburtonBCMM: if you have docker, easy enough to build your own image19:05
*** linums <linums!> has quit IRC19:06
*** linums <linums!> has joined #yocto19:08
*** jobroe <jobroe!> has joined #yocto19:09
*** jobroe_ <jobroe_!> has quit IRC19:10
*** linums <linums!> has quit IRC19:15
*** linums <linums!~linums@> has joined #yocto19:15
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:17
*** rnouse <rnouse!> has joined #yocto19:20
*** yifany <yifany!~yifan@> has quit IRC19:29
*** yifany <yifany!~yifan@> has joined #yocto19:30
*** yifany <yifany!~yifan@> has quit IRC19:35
*** linums <linums!~linums@> has quit IRC19:49
*** linums <linums!~linums@> has joined #yocto19:50
*** tgoodwin_ <tgoodwin_!> has joined #yocto19:53
*** goliath <goliath!> has quit IRC19:53
*** tgoodwin <tgoodwin!> has quit IRC19:54
LetoThe2ndv0n: its exactly what i described earlier. you have multiconfig,, where the outer build packages the inner (initramfs) into /boot.19:55
*** rcw <rcw!~rcwoolley@> has quit IRC19:55
*** rcw <rcw!~rcwoolley@> has joined #yocto19:55
*** dev1990 <dev1990!> has quit IRC20:04
*** emrius <emrius!> has quit IRC20:08
*** bsmerbeck <bsmerbeck!> has joined #yocto20:28
bsmerbeckLess of a yocto question, more of a design question. I'm looking to implement as an means of deploying upgrades, and I'm trying to figure a decent way to construct my image to support the upgrade operation. Specifically, I'm a bit locked up thinking about handling database schema changes. The database used by the system I'm developing20:32
bsmerbeckcontains user data, so obviously I want to persist. If the schema changes, how should I handle the schema change? Perhaps just including a database migration script in the upgrade, and use a one-time firing service to have it done on startup after the upgrade? Ideas feeling pretty messy20:32
*** bsmerbeck <bsmerbeck!> has quit IRC20:35
*** B0ned1ger2 <B0ned1ger2!> has quit IRC20:38
*** B0ned1ger <B0ned1ger!> has joined #yocto20:39
*** dev1990 <dev1990!> has joined #yocto20:39
*** rcoote <rcoote!> has quit IRC20:44
v0nLetoThe2nd: OK I'll try to learn more about multiconfig, I'm still not very used to it. As a first step, I guess I should work on a new distro definition for the initramfs image, correct?20:52
*** sesom <sesom!> has joined #yocto21:00
*** sesom <sesom!> has quit IRC21:09
*** jobroe <jobroe!> has quit IRC21:10
*** sakoman <sakoman!~steve@> has quit IRC21:24
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:27
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto21:27
*** ant__ <ant__!> has joined #yocto21:41
*** loblik <loblik!> has joined #yocto21:45
loblikI have this in my initramfs recipe to deploy dm-verity hash: do_image[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"  and basically it works21:50
loblikhowever I would like to do some char .replace() on the DM_VERITY_IMAGE_TYPE variable, but if I do \@d.getVar the variable seems not to be set. It is defined in machine configuariton file.21:51
loblikIs there something special about this? I thought the variables should be there during recipe parsing. Some variables like MACHINE are there but not this one.21:53
v0nHow do you choose the kernel modules to be built-in?21:55
*** yifany <yifany!~yifan@> has joined #yocto21:57
*** pikes <pikes!> has quit IRC22:17
*** sakoman <sakoman!~steve@> has joined #yocto22:24
*** bluelightning_ is now known as bluelightning22:24
v0nthere's no occurrences of builtin kernel modules in the doc. Is it expected to simply provide a custom kernel config and remove "kernel-modules" from the packages?22:26
*** adelcast <adelcast!> has quit IRC22:30
*** beneth <beneth!> has left #yocto22:37
*** gpanders <gpanders!> has quit IRC22:38
*** B0ned1ger <B0ned1ger!> has quit IRC22:39
*** B0ned1ger <B0ned1ger!> has joined #yocto22:39
*** adelcast <adelcast!> has joined #yocto22:41
*** ant__ <ant__!> has quit IRC22:44
*** sesom <sesom!> has joined #yocto22:49
*** sesom <sesom!> has quit IRC22:53
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC22:55
*** oberstet <oberstet!~oberstet@> has quit IRC22:57
*** rnouse <rnouse!> has quit IRC23:25
*** loblik <loblik!> has quit IRC23:26
*** rnouse <rnouse!> has joined #yocto23:38
*** micka_ <micka_!> has joined #yocto23:47
*** micka <micka!> has quit IRC23:47
*** kpo_ <kpo_!> has quit IRC23:47
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:47
*** v0n <v0n!> has quit IRC23:48
*** kpo_ <kpo_!> has joined #yocto23:48
*** yifany <yifany!~yifan@> has quit IRC23:48
*** yifany <yifany!~yifan@> has joined #yocto23:49
*** v0n <v0n!> has joined #yocto23:49

Generated by 2.17.2 by Marius Gedminas - find it at!