Friday, 2021-04-23

*** B0ned1ger <B0ned1ger!> has quit IRC00:03
*** sakoman <sakoman!> has joined #yocto00:19
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto00:21
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC00:26
*** kpo_ <kpo_!> has quit IRC00:47
*** kpo_ <kpo_!> has joined #yocto00:48
vdlI'm on dunfell and I need python3-protobuf 3.14. What do you guys suggest?00:49
fraymove to something newer then dunfell... or port your own version of protobuf and any associated depednencies.. (starting with the existing version)00:56
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto00:58
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC01:03
vdlfray: I backported the 3 necessary patches to bump protobuf to 3.14 but it's more complicated than that. Do you think it'll be safe to move to Gatesgarth or am I shooting myself in the foot?01:13
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:1028:68cd:20a0:1995> has joined #yocto01:27
*** kaspter <kaspter!~Instantbi@> has quit IRC01:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:34
* paulg smells a PI trap01:36
vdlI'm not using a Raspberry3.14 btw.01:39
*** [Sno] <[Sno]!> has quit IRC01:40
*** [Sno] <[Sno]!> has joined #yocto01:41
*** [Sno] <[Sno]!> has quit IRC01:46
*** [Sno] <[Sno]!> has joined #yocto01:47
*** ctlnwr_ <ctlnwr_!~catalin@> has quit IRC01:50
*** kaspter <kaspter!~Instantbi@> has quit IRC02:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:07
*** kaspter <kaspter!~Instantbi@> has quit IRC02:21
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:27
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:28
*** sakoman <sakoman!> has quit IRC02:29
*** kaspter <kaspter!~Instantbi@> has quit IRC02:32
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:36
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC02:49
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:1028:68cd:20a0:1995> has quit IRC02:49
*** ahadi <ahadi!> has quit IRC02:51
*** ahadi <ahadi!~ahadi@> has joined #yocto02:52
*** sakoman <sakoman!> has joined #yocto02:53
*** kaspter <kaspter!~Instantbi@> has quit IRC02:56
*** sakoman <sakoman!> has quit IRC02:56
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:57
*** camus <camus!~Instantbi@> has joined #yocto02:57
*** camus1 <camus1!~Instantbi@> has joined #yocto03:00
*** kaspter <kaspter!~Instantbi@> has quit IRC03:01
*** camus1 is now known as kaspter03:01
*** camus <camus!~Instantbi@> has quit IRC03:02
*** kpo_ <kpo_!> has quit IRC03:03
*** kaspter <kaspter!~Instantbi@> has quit IRC03:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:05
*** kaspter <kaspter!~Instantbi@> has quit IRC03:09
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:19
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto03:23
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC03:27
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c1d8:438a:5ba5:da50> has quit IRC03:57
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto04:00
*** armpit <armpit!~armpit@2601:202:4180:a5c0:e183:e120:a0a1:83e4> has joined #yocto04:10
*** [Sno] <[Sno]!> has quit IRC04:42
*** [Sno] <[Sno]!> has joined #yocto04:48
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC05:04
*** B0ned1ger <B0ned1ger!> has joined #yocto05:14
*** [Sno] <[Sno]!> has quit IRC05:19
*** [Sno] <[Sno]!> has joined #yocto05:21
*** AndersD <AndersD!> has joined #yocto05:36
*** prabhakarlad <prabhakarlad!> has quit IRC05:37
*** AndersD_ <AndersD_!> has joined #yocto05:39
*** AndersD <AndersD!> has quit IRC05:42
*** B0ned1ger <B0ned1ger!> has quit IRC05:56
*** B0ned1ger <B0ned1ger!> has joined #yocto05:56
*** dreyna_ <dreyna_!> has quit IRC06:15
*** oberstet <oberstet!~oberstet@> has joined #yocto06:20
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:23
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto06:28
*** agust <agust!> has joined #yocto06:30
*** B0ned1ger <B0ned1ger!> has quit IRC06:43
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:43
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto06:45
*** mckoan|away is now known as mckoan06:45
*** pharaon2502 <pharaon2502!> has joined #yocto06:48
*** yannholo <yannholo!> has joined #yocto06:50
*** Bunio_FH <Bunio_FH!> has quit IRC07:01
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:06
LetoThe2ndyo dudX07:06
LetoThe2ndqschulz: so how many beers did you accumulate? ;)07:07
*** vermaete <vermaete!> has joined #yocto07:10
*** rcoote <rcoote!> has joined #yocto07:13
*** prabhakarlad <prabhakarlad!> has joined #yocto07:15
*** Bunio_FH <Bunio_FH!> has joined #yocto07:16
*** Piraty_ is now known as Piraty07:30
*** RobertBerger <RobertBerger!> has joined #yocto07:31
*** goliath <goliath!> has joined #yocto07:39
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC07:41
*** tnovotny <tnovotny!> has joined #yocto07:48
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC07:51
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto07:56
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:58
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto08:00
*** hch_ is now known as hch08:05
*** zandrey <zandrey!~zandrey@> has joined #yocto08:11
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC08:11
*** [Sno] <[Sno]!> has quit IRC08:22
*** [Sno] <[Sno]!> has joined #yocto08:23
*** camus <camus!~Instantbi@> has joined #yocto08:30
*** jsandman97254 <jsandman97254!> has joined #yocto08:30
*** kaspter <kaspter!~Instantbi@> has quit IRC08:31
*** camus is now known as kaspter08:31
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto08:33
*** qschulz <qschulz!> has quit IRC08:36
*** qschulz <qschulz!> has joined #yocto08:36
qschulzLetoThe2nd: too many08:37
JaMaRP: meta-multimedia with yocto-check-layer breaking on this one?
JaMaRP: I came across it recently as well as reported in only to be notified by Denys that this issue is known for much longer08:38
RPJaMa: yes.
RPJaMa: I think Khem is saying he has some patches to workaround it08:40
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC08:42
*** AndersD_ <AndersD_!> has quit IRC08:46
*** |Sno| <|Sno|!> has joined #yocto08:47
*** [Sno] <[Sno]!> has quit IRC08:50
*** fenrig <fenrig!> has joined #yocto08:59
*** Spectrejan[m] <Spectrejan[m]!spectrejan@gateway/shell/> has quit IRC09:00
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto09:01
JaMaRP: thanks, haven't seen the context in the back log, now I'm "pleased" :)09:05
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC09:06
RPJaMa: basically we're trying to get more CI of the layer compatibility running regularly09:07
fenrigI converted a couple of recipes to have a native counterpart as well with BBCLASSEXTEND += "native" , and I've added DEPEND_class-native deps to them as they depend on each other. Now it seems yocto doesnt include the header files of a root native recipe (one that is converted) in the recipes sysroot native when it's compiled itself on the native09:09
fenrigcounterpart. Can anybody point me out what I'm missing here?09:09
RPfenrig: if it is listed in DEPENDS and installs the headers, it should include them. Note that the install paths for natives is a bit different to target since it has to install them at the location they'll "run" at and the paths look like they include duplication but are in fact correct. Try comparing the layout of the files to a recipe known to work with native09:15
*** thekappe <thekappe!c65a42b1@> has joined #yocto09:16
RPi.e. you'll see files file /my/build/path/tmp/work/xxx/yyy/image//my/build/path/tmp/work/xxx/yyy/recipe-sysroot-native from memory09:16
fenrigso I have libamxc-native09:17
fenrigand i have libamxp-native09:17
fenrigand in work/xxx/yyy/libamxc-native in the image folder of the work dir it has both the header files and the so libraries09:18
fenrigbut when i look in09:18
fenrigwork/xxx/yyy/libamxp-native in the recipe's recipe-sysroot-native I dont have these header files, so I'm doing something wrong there09:19
fenrigin the amxp recipe bb i have this: DEPENDS_class-native = "libamxc-native"09:20
fenrigshould i add libamxc-dev as well in those depends?09:20
fenrignope doesnt seem to be able to resolve it it renames libamxc-dev to libamxc-dev-native which doesnt exist09:22
thekappeHello dudX !09:28
thekappeDo you think I can run bitbake from a makefile ?09:28
thekappeI've tried something like09:29
RPfenrig: what are the paths to the files in image folder?09:29
RPfenrig: can you see your host build path in there or just "/usr/include" or similar09:29
thekappe@source ${LAYERS_PATH}/poky/oe-init-build-env ./build09:30
thekappe@cd ./build && bitbake multiconfig:<mymachine>:<myimage>09:30
fenrigso for libamxc-native where the header files are installed in image its: libamx-native/<version>/image/usr/include/amx/*.h09:34
fenrigI dont understand the host build path question exactly, should i check the libamxp-native temp logs?09:35
fenrigBTW <yocto root>/build/tmp-glibc/work/x86_64-linux/ is my path09:36
fenrigamxp-native --> log.do_compile --> -isystem/workspace/yocto/sah/netci/build/tmp-glibc/work/x86_64-linux/libamxp-native/v0.6.9-r0/recipe-sysroot-native/usr/include09:39
fenrigbut this path /workspace/yocto/sah/netci/build/tmp-glibc/work/x86_64-linux/libamxp-native/v0.6.9-r0/recipe-sysroot-native/usr/include/ does not have the amxp-native header files09:41
fenrigit does have others like lxma and libltdl09:41
qschulzthekappe: I remember a company received a Yocto BSP that had only a Makefile and the whole magic hidden. But.... Why do you want to such a thing?09:42
qschulzfenrig: mmmm why do you need header files of a native recipe in a target recipe?09:44
thekappe@qschulz, for some lazy user09:44
fenrigwell its a set of libraries in seperate components that the eventual native tool uses09:45
fenrigso it needs to resolve that chain in the native counterparts09:45
fenrigwe have a very modular approach to the framework, its not one big component blob09:45
dev1990hi, mixing ?= and ??= operators with conditional assigment i.e. FOO_override ?= "bar" FOO_overrride ??="bar2" is correct or this will end up undefined behavior ?09:57
fenrigthe native classextend doesnt support carrying header files?10:04
fenrigis there some philosophy behind it10:04
fenrigi mean native tools probably still need dependencies right?10:04
*** vermaete <vermaete!> has quit IRC10:04
*** nohit <nohit!sid334887@gateway/web/> has quit IRC10:05
*** nohit <nohit!sid334887@gateway/web/> has joined #yocto10:07
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto10:10
qschulzdev1990: not sure to understand the question? what are you trying to do?10:15
dev1990qschulz: not sure about my comment10:16
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:17
*** kpo_ <kpo_!> has joined #yocto10:18
*** kpo <kpo!> has quit IRC10:18
qschulzfenrig: they should be here... but are they installed by the recipe in ${D}?10:18
RPfenrig: I'm now confused, you want the libxamxp-native recipe to have its own header files in recipe-sysroot-native?10:21
fenrigwell y10:22
RPfenrig: amxc-native DEPENDS on amxp-native, right?10:23
fenriglibamxp-native is depending on libamxc-native10:23
fenrigy y10:23
fenrigand libamxc-native has header files that are necessary for libamxp-native10:23
fenrigand i dont have them in the sysroot-native10:23
RPfenrig: which is expected. Have a look at the work directory for xz-native10:24
RPfenrig: If I do /media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0$ find -name lzma.h10:25
RPfenrig: I see mentions of ./sysroot-destdir/media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/include/lzma.h ./xz-5.2.5/src/liblzma/api/lzma.h and ./image/media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/include/lzma.h10:25
RPfenrig: now do the same for amxp-native and see if it looks similar for one of the headers there10:25
qschulzdev1990: never asked myself this question, I'd have expected it to work as other recipes? It's just that basicxally FOO_overrride = "baz" would override FOO_overrride ?= "bar" ?10:26
qschulzas other "normal" operators*10:26
fenrigxz native has the host path repeated in sysroot-destdir?10:26
fenrigthats what you are saying?10:26
RPfenrig: this is what I was getting at earlier, yes10:26
RPand that is the correct things to see, odd as it may look10:27
fenrigand i should have this for the header files as well?10:27
RPfenrig: correct10:27
RPfenrig: I'm saying to look at xz-native as an example of where it is working correctly10:27
fenrigand making correct use of ${D} allows for the behaviour on both native and target?10:27
RPfenrig: yes10:28
RPfenrig: the reason is that exec_prefix will be set to /media/build1/poky/build/tmp/work/x86_64-linux/xz-native/5.2.5-r0/recipe-sysroot-native/usr/10:28
RPand includedir will be $exec_prefix/include10:28
RPso files are installed to ${D}${prefix}/includedir10:29
RP(it may be prefix, not exec_prefix but my point is the same)10:29
fenrigbut all this stuff is in autotools10:31
fenrigso the xz-native recipe is a bad candidate to understand10:31
fenrigis there some documentation on this that you are aware off. It seems I cant find anything usefull on google10:32
RPfenrig: it doesn't matter whether you're using autotools or something else for libxamxc, my point is the file layout would be similar10:33
RPfenrig: we probably need to better document this :/10:33
fenrigyes but i need to look at the recipe what is the correc tthing to do10:33
RPfenrig: your question was why weren't the files appearing. I'm asking if the files are in the right locations. That is the first thing to check here and I don't know if they are or not. I'm trying to give you something you can compare the layout with10:34
RPIf the layout matches, it will be something else. If they don't match, that hints where the problem may be10:34
RPfenrig: there is a section, see Q: Why do ${bindir} and ${libdir} have strange values for -native recipes?10:40
*** JaMa <JaMa!> has quit IRC10:49
*** JaMa <JaMa!> has joined #yocto10:52
dev1990qschulz: I made update with test case, it is working as expeceted with ?= and ??=, so this is probably my imagination.10:52
*** Jonek <Jonek!> has joined #yocto10:54
RPdev1990: we do have a few selftests in bitbake so that we try to at least be consistent with how everything operates10:54
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto11:02
fenrigso i need to pass ${prefix} additionally to ${D} ?11:02
fenrigso this: EXTRA_OEMAKE = "DEST=${D} LIBDIR=${libdir} VERSION_PREFIX=master_"11:02
fenrigmight need to become: EXTRA_OEMAKE = "DEST=${D}${prefix} LIBDIR=${libdir} VERSION_PREFIX=master_" ?11:03
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC11:06
dev1990RP: glad to hear it :-)11:07
RPfenrig: depends on the makefile11:08
fenrigyeah logically11:12
fenrigbtw why does ${prefix} include usr/ at the end?11:13
fenrignow its installing to usr/usr/...11:13
*** |Sno| <|Sno|!> has quit IRC11:14
RPfenrig: is the makefile hardcoding prefix=/usr ?11:14
fenrigin a way yes11:14
RPfenrig: usually you're pass in the prefix as a variable11:14
fenrigyeah the DEST11:15
RPfenrig: no, not as DEST. normally something like DEST=${D} PREFIX=${prefix} LIBDIR=${libdir}11:15
fenrigah yes11:16
fenrigi can override prefix11:16
fenriggood catch11:16
RPfenrig: and/or INCLUDEDIR by the looks of it11:16
RPfenrig: set BINDIR as well just to make it all portable11:17
fenrigand remove DEST it seems11:19
RPfenrig: no, keep that11:19
*** |Sno| <|Sno|!> has joined #yocto11:19
fenrigno cant11:19
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto11:19
fenrigcause DEST is appended again to BINDIR11:20
fenrigah wait11:20
fenriglibdir does not contain the ${D} part?11:20
RPfenrig: this is the odd double path thing I mentioned, it should work even if it looks odd at first11:20
RPfenrig: DEST=${D} and bindir/libdir/prefix/includedir don't have ${D} in them11:21
fenrigso it should be this: EXTRA_OEMAKE = "DEST=${D} PREFIX=${prefix} LIBDIR=${libdir} BINDIR=${bindir} VERSION_PREFIX=master_"11:21
RPyes, probably INCLUDEDIR=${includedir} as well11:21
fenrigyeah i saw11:21
fenriglets try this11:21
fenrigfinally it should be fixed then11:22
RPfenrig: closer, certainly :)11:22
fenrigand those libdir/includedir/prefix/bindir are set respectively for target and native right?11:22
fenrigI shouldnt care about only passing them to native or smth like that11:22
fenrigsilly question I know, but just checking11:22
RPfenrig: yes, the core of the build will set them correctly for the different cases11:22
fenriggreat <311:23
fenrigthis yocto stuff is really put well together, i just couldnt find a description of this part11:23
fenriglibamxp-native compiles now11:23
fenriglets check libamxp11:23
fenrigand if thats working I change them all to incorporate this behaviour11:23
RPfenrig: those paths do look really wrong the first time you see them but they do make sense :)11:24
fenrigTY RP, I needed some time to understand11:24
fenrigmind boggling paths11:24
fenrigim sure there is a logic to it though11:24
RPndec, michaelo: I've wondered if we should put something in the docs about this. Not entirely sure where though11:25
fenrigamxp for target is compiling11:25
*** |Sno| <|Sno|!> has quit IRC11:26
*** |Sno| <|Sno|!> has joined #yocto11:26
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC11:26
*** |Sno| <|Sno|!> has quit IRC11:36
*** |Sno| <|Sno|!> has joined #yocto11:37
*** |Sno| <|Sno|!> has quit IRC11:43
*** |Sno| <|Sno|!> has joined #yocto11:44
*** ayaka <ayaka!~ayaka@> has joined #yocto11:50
ayakaI try to use TOOLCHAIN_HOST_TASK_append in a file would be used by the other file11:50
ayakabut I found it would be override by the inherited file11:50
*** |Sno| <|Sno|!> has quit IRC11:51
*** |Sno| <|Sno|!> has joined #yocto11:52
*** thekappe <thekappe!c65a42b1@> has quit IRC12:02
*** Bunio_FH <Bunio_FH!> has quit IRC12:14
*** Bunio_FH <Bunio_FH!> has joined #yocto12:31
*** ahalaney <ahalaney!> has joined #yocto12:40
zeddiiRP: quick question. I cut and pasted the check layer command from your email last night, and it errored on: ERROR: Nothing PROVIDES 'util-linux-uuid'12:40
zeddiiI just wanted to confirm .. should I be running that from a completely clean clone ? That's my normal integration build, so it has some custom configs12:41
tgamblinzeddii: util-linux-uuid got renamed to util-linux-libuuid last month. Wondering if your configs still reference the old name?12:48
zeddiiyah. I was in on that, I remember it. This is everything up to date. it wouldn't be building otherwise.12:49
tgamblinAh, okay12:49
zeddiiI'm just rm -rf'ing everything and starting over. too much work to use my existing build dir anyway.12:50
zeddiiprobably some dumb distro config I was messing with12:51
* zeddii goes for coffee while it rm's12:51
*** tnovotny <tnovotny!> has quit IRC13:02
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto13:04
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC13:09
zeddiiRP: my second run got further, but my list of issues is different than the AB one.13:12
*** mckoan is now known as mckoan|away13:18
*** camus <camus!~Instantbi@> has joined #yocto13:40
*** kaspter <kaspter!~Instantbi@> has quit IRC13:41
*** camus is now known as kaspter13:41
*** sakoman <sakoman!> has joined #yocto13:49
*** zandrey <zandrey!~zandrey@> has quit IRC13:52
RPzeddii: I'd do this in a clean directory/build/checkout. The layers added at the start of the test need to be minimal14:00
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC14:05
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto14:06
*** |Sno| <|Sno|!> has quit IRC14:24
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:24
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:24
*** sno <sno!> has joined #yocto14:26
*** stephano <stephano!~stephano@> has joined #yocto14:27
RPzeddii: I'm seeing errors about seccomp being missing for meta-virt. We may need to speed up the migration of that to core? armpit?14:28
zeddiiRP: I did a commit to just add the depedency. until it migrates.14:31
zeddiiI can undo it later.14:31
armpitRP, would you take it if ptests are wonked ?14:32
RParmpit: ptests don't currently work today right?14:32
RParmpit: I guess it depends what "wonked" means exactly. As long as they don't break the build or anything and don't regress with the move we're probably ok14:33
RPwe can fix them in due course14:33
*** psnsilva_ <psnsilva_!~psnsilva@> has joined #yocto14:35
*** psnsilva <psnsilva!~psnsilva@> has quit IRC14:38
RPzeddii: great, the autobuilder doesn't have meta-security in its config :(14:38
zeddiiahah. is meta-virt the only one that would need it ? so I guess that isn't the best solution. but i'm testing with it locally for now.14:39
zeddiiI could copy libseccomp in as well ;)14:39
RPzeddii: nothing has yet needed it, no, so I hadn't added it. We may end up adding anyway but as yet...14:40
RPzeddii: adding totally new layers is a pain as the controller has to be restarted which can interrupt builds14:40
armpitRP, ptests run, its their results that need cleaning up14:41
RPzeddii: lets see if we can convince armpit to send a patch14:41
* armpit notarmpit14:41
RParmpit: the builds won't run new ptests until they're added to the list of ptests to run14:41
armpitill put together a patch14:42
*** Jonek <Jonek!> has quit IRC14:51
*** kaspter <kaspter!~Instantbi@> has quit IRC14:53
vdlis it safe to keep the state sstate-cache dir between 2 yocto releases (dunfell -> gatesgarth)?14:56
*** Bunio_FH <Bunio_FH!> has quit IRC14:57
JPEWvdl: should be14:58
*** lin0xc0der <lin0xc0der!2923a264@> has joined #yocto15:02
*** sno <sno!> has quit IRC15:03
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto15:04
*** sno <sno!> has joined #yocto15:06
*** rcoote <rcoote!> has quit IRC15:06
*** pharaon2502 <pharaon2502!> has quit IRC15:07
*** lin0xc0der <lin0xc0der!2923a264@> has quit IRC15:08
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC15:09
*** Bunio_FH <Bunio_FH!> has joined #yocto15:17
*** sbach <sbach!~sbachmatr@> has quit IRC15:20
*** sbach <sbach!~sbachmatr@> has joined #yocto15:21
armpitRP, so which recipe- dir would you want this recipe to live in?15:23
armpitvdl, I keep mine in separate directories so its easier to nuke sstate for a particular release15:25
RParmpit: recipe-support? open to suggestions15:33
RPvdl: it is safe15:33
RPvdl: can be useful to have separate for management reasons but the tools don't care15:34
RPkhem: do you still see those busybox issues with current master-next?15:35
zeddiiINFO: Summary of results:15:36
zeddiiINFO: meta-virtualization ... PASS15:36
RPzeddii: nice :)15:37
zeddiias I mentioned, my list of initial errors was slightly different. but I fixed what I saw.15:37
RPzeddii: we can rerun the autobuilder tests quite easily against -next branches and so on15:37
zeddiiI didn't have the libdevmapper or lvm2, but maybe those were the inherited ones you mentioned, and I picked up meta-oe fixes for them.15:37
zeddiiI can push everything to master next. and drop the libseccomp one.15:38
zeddiiwe can know it is a to be fixed soon error.15:38
vdlarmpit: RP: so having like a separate sstate-dunfell and sstate-gatesgarth is not really needed15:39
RPvdl: correct15:42
vdlok let's keep my separate sstate dir as is and bump dunfell -> gatesgarth and see what happens, yay \o/15:43
* vdl has in a tab15:43
zeddiiRP: I just pushed all my meta-virt fixes to it's master-next. so if you do another test run, and use that branch .. it should do better (modulo the libseccomp).15:46
RPzeddii: lets see - has master-next for meta-oe and meta-virt15:48
* zeddii nods15:48
* RP moved meta-aws and meta-intel to being enabled on master and "live"15:48
*** Bunio_FH <Bunio_FH!> has quit IRC15:49
*** yannholo <yannholo!> has quit IRC15:57
vdlI'm not sure to understand the purpose of the stateless-rootfs DISTRO_FEATURES. What's the reason for doing systemctl --preset-mode=enable-only preset-all?16:07
*** sstabellini_ is now known as sstabellini16:25
*** matthewcroughan <matthewcroughan!> has quit IRC16:25
*** matthewcroughan <matthewcroughan!> has joined #yocto16:25
vdlmeta-ti has no gatesgarth branch? :/16:28
JaMazeddii: CVE-2021-3121.patch in meta-virtualization/hardknott is now causing ERROR: containerd-opencontainers-v1.4.3+gitAUTOINC+33d90b72d1-r0 do_patch: Fuzz detected: should I send a fix or do you already have something?16:28
*** psnsilva_ <psnsilva_!~psnsilva@> has quit IRC16:29
vdldenix: which meta-ti branch am I supposed to use for gatesgarth?16:31
zeddiiJaMa: I don't have a fix for it. Considering that was just submitted, that is surprising. I'll happily take the refresh if you've fired it up.16:33
vdlkhem: ^^16:33
*** sno <sno!> has quit IRC16:33
*** sno <sno!> has joined #yocto16:34
*** sno <sno!> has quit IRC16:42
*** sno <sno!> has joined #yocto16:45
*** sno <sno!> has quit IRC16:54
*** vmesons <vmesons!> has joined #yocto16:57
*** vmeson <vmeson!> has quit IRC16:58
RPzeddii: - seems that something appends unconditionally to sysvinit-inittab and python3-paramiko fetches ?16:59
zeddiino. I fixed that.17:01
zeddiiif you are using my master-next python3-paramiko isn't even in the layer anymore17:01
RPzeddii: sorry, wrong output17:01
RPzeddii: - it is fixed17:01
zeddiithere's probably something new. bit it shouldn't be ther :D17:01
RPzeddii: yes, sorry, I was just looking at the wrong build. I should finish for the day!17:03
zeddiiit's friday. I approve of that message.17:03
*** kpo_ <kpo_!> has quit IRC17:04
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto17:05
*** kpo_ <kpo_!> has joined #yocto17:08
*** dreyna_ <dreyna_!> has joined #yocto17:08
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC17:10
*** dreyna__ <dreyna__!> has joined #yocto17:10
*** dreyna_ <dreyna_!> has quit IRC17:14
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC17:24
*** moto-tim1 <moto-tim1!> has quit IRC17:28
*** moto-tim1 <moto-tim1!> has joined #yocto17:29
vdlDoes a container image require packagegroup-core-boot or packagegroup-base to start?17:39
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has quit IRC17:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:43
zeddiinope. what's in the container has nothing to do with how it starts.17:45
zeddiioutside of the entry point binary that is.17:46
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has joined #yocto17:47
vdlzeddii: for systemd-based containers, it's recommended to have systemd and systemd-container installed in the container. What pulls these packages in?17:51
zeddiinothing. that's completely up to you17:51
vdlIn other words, will I have systemd installed in the container if I don't add packagegroup-core-boot and packagegroup-base to IMAGE_INSTALL?17:52
zeddiiyou'll have absolutely nothing installed if you don't specifiy it.17:52
zeddiiup to you if you use those package groups or not.17:52
vdlho so at the minimum I'll have to do IMAGE_INSTALL = "systemd systemd-container"17:53
zeddii99% of the containers people want, want systemd no where near them.17:53
zeddiiso yah, you'll come up with your own content. there's nothing canned for it.17:53
*** fenrig <fenrig!> has quit IRC17:53
vdlzeddii: what package(group) is responsible to install "systemd" when DISTRO_FEATURES includes "systemd"?17:54
zeddiiI can't say that I've looked in a while. I can grep for a bit and see :D17:59
vdlzeddii: for systemd(-container) within the container, the reason is that systemd makes it smoother if systemd is available inside the guest, like systemd-networkd automatically configures dhcp and IP masquerade on the guest side of the virtual ethernet link. Guest system journal is another nice addition.18:00
zeddiiI'm just saying that most people have no interest in 'system containers'18:01
vdlho ok18:01
zeddiiand want no init system anywhere near their container contents.18:01
*** lemon56 <lemon56!> has joined #yocto18:02
lemon56hi quick question... sometimes i see stuff like "@oe.utils.conditional()" .. is this a bash thing?18:03
zeddiiit's inline python18:04
lemon56ah thanks haha. ill do a search on that18:04
vdlso yeah in the case where systemd is used in your DISTRO_FEATURES, I expect to pull in systemd and systemd-container inside the container, but no {MACHINE,DISTRO}_EXTRA_* things and no (kernel, dts) boot images. So I want to remove packagegroup-core-boot and packagegroup-base from the container image, but I fail to understand what pulls-in the base files and systemd to have a "bootable" container.18:05
zeddiivdl: to answer the other thing, it is VIRTUAL-RUNTIME_init_manager that really gets systemd installed, not the distro feature.18:05
vdlzeddii: ho!18:05
zeddiiyou'll see the packagegroups referencing that.18:05
vdlzeddii: so for this scenario I'm describing, is there a clean way to define systemd-container as a dependency or recommendation for VIRTUAL_RUNTIME_init_manager in my distro config?18:09
zeddiiI'd just create a packagegroup that installs what you need, and then have your image recipe include it.  that's what I do in meta-virt for all the base container definitions that are being built up there.18:11
zeddiiI wouldn't bring the distro config into it at all.18:11
tgamblinJaMa: did you already try the fix for the CVE patch? When I run devtool modify containerd-opencontainers, the thing throws an error instead of letting me do the work18:13
*** stm-at-esd <stm-at-esd!> has joined #yocto18:13
zeddiitgamblin: yah. there's something brain damaged going on with go and devtool. I just refresh the patches manually.18:14
zeddiior maybe it's meta-virt and devtool. who knows. I didn't check :D18:14
tgamblinzeddii: yeah, tried that, but when I do it manually I don't see any of the fuzz issues :P18:15
zeddiiodd. my builder is chewing away on other things, so I haven't tried myself to see if hardknott throws the warning on the build myself.18:16
tgamblinAlmost certainly does, I'm able to reproduce it readily. Just didn't notice it last time18:16
vdlzeddii: a packagegroup-container can pull in systemd systemd-container if DISTRO_FEATURES include systemd.18:17
zeddiivdl: I'll take your word for it. I don't go anywhere near those packagegroups.18:17
zeddiitgamblin: you could just on faith head into the build directory and refresh with quilt, and see what git says about the delta.18:18
vdlany idea why doesn't have VIRTUAL-RUNTIME_dev_manager ??= "systemd"18:18
tgamblinzeddii: might give that a shot18:18
vdlzeddii: packagegroup-core-boot is the one pulling in systemd... I guess packagegroup-core-boot is in fact necessary to "boot" the container (e.g. with systemd-nspawn -b).18:23
zeddiiit's just a packagegroup ... you could create your own. so I'm not following what you mean by that satement.18:23
vdlUnfortunately I don't see any mechanism in the build system to have a bootable container without the boot images.18:24
zeddiithere's no package group that is required by anything to do anything18:24
zeddiiI've booted plenty of images when playing with nspawn using my own packagegroups. but tossed it all in the bin several years ago.18:24
vdlzeddii: to put it in another way: I'd assume that yocto had a way to distinguish the packages needed for booting a system (host or guest) and the package needed to boot the actual hardware (not needed in a container).18:26
stm-at-esdHi, I have a packaging problem here. I try to package two variants of the same library one built with a plugin interface and another without a plugin interface. So I created two recipes libntcan-plugin and libntcan-noplugin that build the same library with and without the plugin interface active. I have set18:27
stm-at-esdRCONFLICTS_libntcan-plugin="libntcan-noplugin" and RCONFLICTS_libntcan-noplugin="libntcan-plugin" in the recipes to show that each packed variant conflicts with the other one. But in the end I get a QA error "ERROR: libntcan-plugin-4.1.4-r0 do_package_write_ipk: The recipe libntcan-plugin is trying to install files into a shared area when those18:27
stm-at-esdfiles already exist." Now my questions: a) Is it possible to build two packages that install basically the same files but make sure that only one of them can be installed? b) How is that done correctly? Setting RCONFLICTS_* seems not to be enough?18:27
zeddiino, not really. that's like it doesn't have images for every possible task. There's some very base plumbing in oe-core, and then other things we are doing in meta-virtualiation18:27
vdlzeddii: Like packagegroup-base has packagegroup-distro-base and packagegroup-machine-base, I think we must have packagegroup-core-machine-boot and packagegroup-core-distro-boot split in packagegroup-core-boot.18:29
zeddiimaybe ? but that spit is arbitrary and only useful in some situations. the line has to be drawn somewhere.18:30
zeddiilike I said, I spend nearly all day every day doing container stuff, and I don't use them and wouldn't18:31
vdlzeddii: true, similar to packagegroup-base, which allows one to remove packagegroup-machine-base if one doesn't want the packages listed in MACHINE_EXTRA_RDEPENDS (same for distro).18:32
vdlzeddii: maybe that's because you have a strong understanding of the build system and thus are confortable to add your own packages and tweaks. But IMHO, yocto is all about being smart and pulling in what's necessary, when necessary, once the machine/distro/image configuration is properly written. Thus saying "you can write your own packagegroup" isn't really a solution to have a proper way to18:35
vdlexclude the boot images (in the context of a container).18:35
vdlOtherwise, all these MACHINE/DISTRO_ESSENTIAL/EXTRA_RDEPENDS/RRECOMMENDS and stuffs don't make sense at all.18:36
zeddiivdl. there's thousands of images for thousands of tasks.18:37
zeddiithis is one specific example.18:37
zeddiiyou can't drive a super flexible set of do-anything package groups into core and actually test them.18:38
*** Bunio_FH <Bunio_FH!> has joined #yocto18:43
vdlzeddii: well I disagree. That's the whole purpose of bitbake, its flexibility and the sh*itload of variables...18:47
* zeddii shrugs18:47
zeddiiand that same flexibility is what gets us torn apart in all the comparisons. so that's the counterpoint18:48
stm-at-esdWell after examining the names of the created packages I see that the packages have the same base name (in both cases libntcan*) and not libntcan-plugin* and libntcan-noplugin*. This seems to be the culprit. I'll investigate this further. Bye.18:49
*** mr_science <mr_science!~sarnold@> has joined #yocto18:49
*** mr_science <mr_science!~sarnold@> has quit IRC18:51
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC18:51
JaMatgamblin: no, after seeing your e-mail I didn't even start building it locally18:51
vdlzeddii: I'm just talking about having a proper definition of the boot images from the machine conf, included (by default) in the image conf. Nothing fancy :)18:54
*** dakhouya <dakhouya!d82e07b2@> has joined #yocto18:56
zeddiithere's always room for improvement. but I wouldn't call what's available now improper.18:56
vdlzeddii: another example is how bad meta-ti is, they hack IMAGE_INSTALL directly to force the (optional) inclusion of kernel-image-zimage and kernel-devicetree, rather than using the (confusing I'd agree) MACHINE_ESSENTIAL_EXTRA things. You imagine removing packagegroup-core-boot to exclude the kernel? nope, not with meta-ti.18:56
*** dakhouya <dakhouya!d82e07b2@> has quit IRC18:57
vdlIf we don't really on all this, let's simply get rid of these variables, packagegroups and machine/distro/image features. We all define IMAGE_INSTALL and we are fine ^^18:57
* zeddii exits the conversation18:58
*** nerdboy <nerdboy!~sarnold@> has joined #yocto18:59
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto18:59
vdlzeddii: because there's room for improvements, one needs to define how to do it. Sorry if I pushed you out of the conversation.19:01
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto19:06
denixvdl: nobody like talking to someone who complains excessively and does nothing to fix the situation. as usual, patches are welcome. this is the only place where IMAGE_INSTALL snuck in to meta-ti -
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC19:11
*** lemon56 <lemon56!> has quit IRC19:43
khemRP:  I have some patches for oe-core to fix meta-python with ptest check-layer fixes, pytest is in oe-core now so it can be fixed amicably by removing the bbappends from meta-python19:43
khemRP:  I am doing a final run and will send the oe-core ones shortly19:43
khemRP:  btw. I ran the script on some other layers in my distro conf, and in meta-clang we introduced a variable called CLANG_SDK to add clang toolchain to SDK even when using gcc if user wished to, default it is set to 0 but it does changed signature of one task on packagegroups, whats the best way to fix it ? we could add CLANG_SDK to bitbake.conf and that will fix it19:45
tgamblinkhem: RP: I saw the email on that but I'm just getting to it now. This is for checking sstate for recipes?19:50
*** sno <sno!> has joined #yocto19:54
armpitHappy Germany Beer day20:04
khemtgamblin: I have sent fixes for meta-python as well20:07
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC20:11
vdldenix: so you assume that I mention all this and "do nothing to fix the situation". Nice judgment :)20:13
vdldenix: any reason not to have a gatesgarth branch in meta-ti?20:13
tgamblinkhem: alright, thanks20:16
*** vmesons is now known as vmeson20:16
vdlAnd it wasn't complaining btw, I was discussing how to split non-hardware boot packages from hardware boot images :)20:17
*** kpo_ <kpo_!> has quit IRC20:18
kergothso you submitted a patch? or a bug? or did anything but complain on irc?20:20
kergothdidn't look like it from here either20:20
*** kpo_ <kpo_!> has joined #yocto20:22
vdlkergoth: what do you want me to submit if I didn't discuss how to fix a thing? I've already come to the point that splitting a packagegroup-core-machine-boot from packagegroup-core-boot seems like a solution20:22
*** oberstet <oberstet!~oberstet@> has quit IRC20:23
kergoththe bug is the IMAGE_INSTALL_append, which would be easy to submit a patch for20:23
vdlyup, this I'm submitting a patch to use MACHINE_ESSENTIALS_EXTRA_RDEPENDS soon20:23
kergothand any real discussion about design needs to be on the list, not in a transitory form on irc, or it won't involve the necessary parties20:24
kergothlists, rather20:24
vdlso it binds to packagegroup-core-boot20:24
tgamblinkhem: new build is breaking on those patches, looking at why20:24
vdlkergoth: I disagree, I might be missing a design point that one can simply tell me here via IRC20:24
kergothonly a small subset of developers are on the channel, and of those, an even smaller subset overlap your time zone20:25
vdlI'll continue this one on the mailing list though for sure20:25
vdlkergoth: I know. Still IRC is a good place to ask why meta-ti has no gatesgarth branch, don't you agree? :)20:26
*** sno <sno!> has quit IRC20:26
kergothyes, but not so much the discussion of splitting a core packagegroup used by countless companies and projects.20:27
*** sno <sno!> has joined #yocto20:32
khemtgamblin: you need corresponding oe-core patches too20:34
khemthat I have send for python related recipes20:34
denixvdl: I suggest you ask TI people on meta-ti list about gatesgarth plans. my understanding - there are no resources. and there are no TI people on this IRC channel20:35
*** sno <sno!> has quit IRC20:40
*** sno <sno!> has joined #yocto20:41
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto20:43
tgamblinkhem: that'll do it20:49
*** sno <sno!> has quit IRC20:51
*** sno <sno!> has joined #yocto20:59
RPvdl: I will say that the packagegroup stuff in oe-core has been around for a long time and predates containers. I helped design some of it, warts and all. At the time I'd imagined it evolving over time. Instead people have tended to use it or replace it with their own stuff. Replacing it was a design feature and is fine.21:03
RPvdl: I do think it needs updating. How I'm less sure about. A lot of us, me included worry about changes now as they tend to break things for existing users who aren't used to them changing21:04
RPvdl: I think we can change them but don't be surprised if there is inertia around not doing so as the potential risk is higher here21:04
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has joined #yocto21:07
*** vineela <vineela!~vtummala@> has joined #yocto21:08
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:6589:dd40:ac04:92ab> has quit IRC21:12
*** dmoseley <dmoseley!~dmoseley@> has quit IRC21:17
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto21:19
*** stm-at-esd <stm-at-esd!> has left #yocto21:52
*** ahalaney <ahalaney!> has quit IRC21:57
*** sno <sno!> has quit IRC22:02
*** sno <sno!> has joined #yocto22:03
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto22:06
*** stephano <stephano!~stephano@> has quit IRC22:06
*** c4t3l <c4t3l!~rcallicot@> has quit IRC22:07
*** sno <sno!> has quit IRC22:08
*** c4t3l <c4t3l!> has joined #yocto22:08
*** sno <sno!> has joined #yocto22:09
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:12
*** vineela <vineela!~vtummala@> has quit IRC22:13
*** c4t3l <c4t3l!> has quit IRC22:23
*** rohfle <rohfle!> has joined #yocto22:27
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC22:32
*** angolini <angolini!uid62003@gateway/web/> has quit IRC22:33
vdlRP: I was thinking about adding packagegroup-core-machine-boot as a dependency for packagegroup-core-boot, like packagegroup-base has internal dependency for packagegroup-machine-base and packagegroup-distro-base (the goal is that it won't make a difference for people using packagegroup-core-boot, but one can remove packagegroup-core-machine-boot if necessary, like for containers)22:35
*** dev1990 <dev1990!> has quit IRC22:56
*** felix_inst <felix_inst!> has quit IRC22:57
*** agust <agust!> has quit IRC23:03
*** goliath <goliath!> has quit IRC23:07
*** vineela <vineela!~vtummala@> has joined #yocto23:21
*** vineela <vineela!~vtummala@> has quit IRC23:23
*** thaytan <thaytan!> has quit IRC23:25
*** JaMa <JaMa!> has quit IRC23:33
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has quit IRC23:33
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has joined #yocto23:38
*** Bunio_FH <Bunio_FH!> has quit IRC23:55

Generated by 2.17.2 by Marius Gedminas - find it at!