Monday, 2020-09-28

*** sakoman <sakoman!> has quit IRC00:14
*** kiwi_29 <kiwi_29!> has quit IRC01:25
*** matthewzmd <matthewzmd!~user@> has quit IRC01:27
*** kiwi_29 <kiwi_29!> has joined #yocto01:29
*** kiwi_29_ <kiwi_29_!> has joined #yocto01:31
*** kiwi_29 <kiwi_29!> has quit IRC01:31
*** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has quit IRC01:36
*** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has joined #yocto01:37
*** kiwi_29_ <kiwi_29_!> has quit IRC02:15
*** kiwi_29 <kiwi_29!> has joined #yocto02:18
*** kiwi_29 <kiwi_29!> has quit IRC02:33
*** kiwi_29 <kiwi_29!> has joined #yocto02:34
*** manuel1985 <manuel1985!> has quit IRC02:40
*** manuel1985 <manuel1985!> has joined #yocto02:54
kiwi_29Hello.. my custom distro is based on deb pacakges. One of my custom recipes "custrecipe1" installs a file in /usr/lib/SHAREDLIB.SO this shared lib is also provided by another package - "anotherpkg1" .02:56
kiwi_29Therefore while generating rootfs, when custrecipe1.deb is being installed there is an error02:56
kiwi_29dpkg: error processing archive custrecipe1.deb (--unpack):02:56
kiwi_29trying to overwrite '/usr/lib/ which is also in package anotherpkg102:57
kiwi_29How do I deal with this situation02:57
*** kiwi_29 <kiwi_29!> has quit IRC02:57
*** pev <pev!> has quit IRC03:14
*** sakoman <sakoman!> has joined #yocto03:21
*** georgem <georgem!~georgem@> has quit IRC03:29
*** georgem <georgem!~georgem@> has joined #yocto03:29
*** sakoman <sakoman!> has quit IRC03:36
*** sakoman <sakoman!> has joined #yocto03:36
*** stacktrust <stacktrust!> has quit IRC04:00
*** Bunio_FH <Bunio_FH!> has joined #yocto04:00
*** wooosaiii <wooosaiii!> has quit IRC04:01
*** stacktrust <stacktrust!> has joined #yocto04:01
*** wooosaiii <wooosaiii!> has joined #yocto04:02
*** Bunio_FH <Bunio_FH!> has quit IRC04:02
*** jobroe <jobroe!> has joined #yocto04:28
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC04:32
*** gonkulator <gonkulator!~brandon@> has joined #yocto04:32
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto04:40
*** feddischson <feddischson!> has joined #yocto04:44
*** zkrx <zkrx!> has quit IRC04:48
*** kiwi_29 <kiwi_29!> has joined #yocto04:58
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto05:00
*** kiwi_2962 <kiwi_2962!> has joined #yocto05:02
*** ibinderwolf <ibinderwolf!> has joined #yocto05:09
*** w00die <w00die!~w00die@> has quit IRC05:11
*** davidinux <davidinux!~davidinux@> has quit IRC05:11
*** w00die <w00die!~w00die@> has joined #yocto05:13
*** davidinux <davidinux!> has joined #yocto05:13
*** NiksDev <NiksDev!~NiksDev@> has quit IRC05:15
*** beneth <beneth!> has joined #yocto05:16
*** ThomasD13 <ThomasD13!> has joined #yocto05:19
*** kiwi_29 <kiwi_29!> has quit IRC05:19
*** AndersD <AndersD!> has joined #yocto05:39
*** kiwi_29 <kiwi_29!> has joined #yocto05:43
*** kaspter <kaspter!~Instantbi@> has quit IRC05:43
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:43
*** CoLa|work <CoLa|work!> has joined #yocto05:45
*** CoLa|work <CoLa|work!> has quit IRC05:50
*** manuel1985 <manuel1985!> has quit IRC06:04
*** pohly <pohly!> has joined #yocto06:07
*** camus1 <camus1!~Instantbi@> has joined #yocto06:08
*** kaspter <kaspter!~Instantbi@> has quit IRC06:09
*** camus1 is now known as kaspter06:09
*** goliath <goliath!> has quit IRC06:10
*** agust <agust!> has joined #yocto06:24
*** AndersD <AndersD!> has quit IRC06:35
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has joined #yocto06:38
*** kiwi_29 <kiwi_29!> has quit IRC06:38
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:42
*** mihai- is now known as mihai06:50
*** kamel_b is now known as kamel06:55
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:55
*** davidinux <davidinux!> has quit IRC07:07
*** mbulut <mbulut!> has joined #yocto07:12
*** jmiehe <jmiehe!> has joined #yocto07:22
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:24
*** manuel1985 <manuel1985!> has joined #yocto07:27
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto07:31
*** mckoan|away is now known as mckoan07:31
mckoangood morning07:31
erbogood morning07:37
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto07:40
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:45
*** jkimblad <jkimblad!> has quit IRC07:51
*** sno <sno!> has quit IRC08:00
leon-anavihi :)08:01
*** fbre <fbre!91fdde45@> has joined #yocto08:01
fbreHi! I'm in the menuconfig of an ARM64 5.4.61 kernel configuration and want to select the i.MX8. What should I choose in "Platform selection"? Can I unselect one of the preselected settings? I can see "ARMv8 based Freescale Layerscape SoC family", "ARMv8 based NXP i.MX SoC family", "i.MX8M busfreq" and "NXP S32 SoC Family" are on.08:06
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:10
*** eduardas <eduardas!~eduardas@> has joined #yocto08:11
eduardashello, is it now possible to specify the kernel in-tree defconfig file to use for kernel build?08:15
eduardasit seems to me this is not possible with standard poky's kernel.bbclass08:16
eduardasPhytec for example make their own kconfig.bbclass where they have an INTREE_DEFCONFIG variable for this purpose08:17
eduardasI think something like this would be very useful to have in standard kernel.bbclass08:18
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto08:18
eduardashonestly, it surprises me something like this is not already there08:18
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:20
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC08:21
qschulzif there's a "defconfig" in ${WORKDIR} (passed with the file fetcher in SRC_URI), it's used08:22
*** sno <sno!> has joined #yocto08:23
qschulzeduardas: otherwise, if you inherit kernel-yocto, you can use KBUILD_DEFCONFIG and install your defconfig in arch/<arch>/configs/ to use it08:24
*** zkrx <zkrx!> has joined #yocto08:36
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:c990:8de1:5141:d0ec> has joined #yocto08:37
eduardasqschulz: is it ok to use kernel-yocto.bbclass on regular mainline linux source tree?08:48
eduardasqschulz: or does the kernel source need some kind of yocto-specific modifications?08:48
eduardasqschulz: because it sounds like linux-yocto is special in some way08:48
qschulzeduardas: who does not try does not know :D08:50
eduardasqschulz: what is "linux-yocto style kernel source" anyway?08:50
qschulz(and I don't use kernel-yocto soooo... I don't know :) )08:50
qschulzbut it brings config fragment support for example08:50
eduardasqschulz: ok, will try it... thank you for the advice since I was not aware of this class08:51
qschulzeduardas: remember, to use KBUILD_)DEFCONFIG, you need to install your defconfig in the sources in arch/<ARCH>/configs ;)08:52
*** fbre <fbre!91fdde45@> has quit IRC08:58
*** goliath <goliath!> has joined #yocto08:59
eduardasqschulz: seems it at least needs KERNEL_VERSION_SANITY_SKIP="1" to be set in my kernel recipe to work09:00
*** davidinux <davidinux!~davidinux@> has joined #yocto09:01
rburtoneduardas: linux-yocto has mainline tags in, so you can just use linux-yocto and set the branch/revision yourself09:03
rburton <-- that is mainline 5.8.1109:04
qschulzrburton: they are using phytec's bsp so probably not mainline?09:05
rburtonin that case, the fact that linux-yocto builds mainline kernels implies that the classes don't need magic09:06
*** florian_kc is now known as florian09:36
eduardasqschulz: I am using mainline 5.8.5 actually... a Phytec SoM, but not Phytec's BSP... I usually put together my own BSP based on latest stable Yocto branch09:36
* qschulz applauds loudly09:37
* qschulz screams: "More people like eduardas please!"09:37
eduardasPhytec's docs are relatively ok for a SoM vendor... I've seen much worse... but it is still not up-to-date with latest Yocto/OE09:38
eduardasqschulz: thanks... I don't deserve so much praise :D09:39
eduardasthough this approach that most people more familiar with Yocto think of as normal is really difficult to explain to managers09:40
qschulzeduardas: it's refreshing to see, many people do not want/"cannot" upgrade from BSP's Yocto versions (we've seen people asking for help for jethro still...)09:41
eduardasmiddle management still thinks that "vendor BSP is best BSP, vendor bootloader is best bootloader, vendor kernel is best kernel"09:41
qschulzeduardas: it can be, but you bear the costs of maintaining it when vendor don't want to take care of it anymore09:41
qschulzeduardas: it's all short-term vs long-term and it's hard to force people on doing long term things (because it also usually costs more short-term)09:42
*** pev <pev!> has joined #yocto09:43
eduardasalso, if anyone from Phytec is hearing this, please add u-boot as a bootloader option since barebox is really niche and has some incompatibility with mainline dtb parsing09:43
*** kaspter <kaspter!~Instantbi@> has quit IRC09:48
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:48
*** ak77 <ak77!c12e4b03@> has joined #yocto10:03
*** mbulut <mbulut!> has quit IRC10:30
*** kpo_ <kpo_!> has joined #yocto11:07
eduardasqschulz: using linux-yocto does not work after all11:11
eduardasqschulz: even though the in-tree defconfig gets copied over to WORKDIR, it does not get applied at the end11:12
qschulzeduardas: how is your defconfig named? what's its entry in SRC_URI?11:12
eduardasqschulz: it's not in SRC_URI since the whole point is to use the in-tree one11:14
eduardasqschulz: it's arch/<arch>/configs/product_defconfig11:15
eduardasqschulz: and i set KBUILD_DEFCONFIG_imx6ul-product-mainline = "product_defconfig"11:16
RPIt is lovely when you can watch a build rolling straight to the key part reusing sstate all the way :)11:20
qschulzeduardas: are you requiring linux-yocto or inheriting kernel-yocto?11:22
eduardasqschulz: inheriting kernel-yocto11:24
qschulzwhat tasks have youd efined in your recipe? is it possible you bypass some task or override one?11:25
eduardasqschulz: except for the KERNEL_VERSION_SANITY_SKIP="1" there is hardly anything worthy of suspicion, no direct task customization11:26
qschulzeduardas: and you inherit kernel also right?11:27
qschulzeduardas: I;m out of ideas, I'd check tha tall/most tasks are run and try to understand what should happen and what actually happens before the recipe's do_compile :/11:28
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC11:29
eduardasqschulz: something like this:
qschulzeduardas: I think you can use KBRANCH directly?11:30
qschulzinstead of SRC_BRANCH11:30
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto11:30
eduardasqschulz: because of time limitations I am probably going to drop the idea of using in-kernel defconfig for now11:30
eduardaswill implement the "classic" defconfig in metadata11:31
eduardasI really feel "normal" kernel.bbclass should have an in-kernel defconfig option11:31
eduardascan I make yocto release feature requests here?11:31
qschulzeduardas: you can send patches :D11:32
eduardasthough sadly I do not belong to an organization that is a member of Yocto11:32
eduardasqschulz: I know, but I probably won't get paid to do them11:32
eduardasit is really difficult to convince management we should work upstream11:33
qschulzeduardas: what we do is that we cp the intree defconfig to ${WORKDIR}/defconfig in kernel_do_configure_prepend() and this seems to work11:33
eduardaswould be very nice doing open-source as a dayjob11:33
qschulzyou can override this per machine11:33
*** rsalveti <rsalveti!uid117878@gateway/web/> has joined #yocto11:33
qschulzeduardas: some people here contribtue on their free time too :)11:34
qschulzbut I get what you mean :)11:34
qschulzeduardas: I'd probably send a mail to the mailing list giving your recipe, what you're trying to achieve, what's happening and ask for help?11:35
qschulzmaybe you forgot a few variables? maybe it's a bug :)11:35
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:36
rburtoneduardas: feature requests in bugzilla please.  patches very much welcome, obviously you don't have to be a member to send a patch.  if management are making it difficult to contribute then really they should be paying for a support contract as open source != free support.  there's plenty of discussion to remind management of that fact.11:39
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto11:40
ThomasD13Hi, is there a easy way to list all packagegroups, which are really going to be added to the linux image with bitbake?11:45
*** Konsgnx <Konsgnx!> has joined #yocto11:46
*** berton <berton!~berton@> has joined #yocto11:46
qschulzThomasD13: I think that's something you can have from the buildhistory11:48
ThomasD13qschulz, I can see which packages are installed, and which files belongs to it. But packagegroups..?11:51
ThomasD13I'll have a look. Maybe I have overseen something11:51
ThomasD13Argh!! Thanks qschulz !! image-info.txt is it :)11:53
RPkhem: the minifi-cpp issue is the fact the recipe uses ${B}/minifi-install. Change that to ${WORKDIR}/minifi-install and it should work11:54
RPkhem: I sent a patch12:02
*** micka_ is now known as micka12:05
*** xantoz <xantoz!> has quit IRC12:16
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:25
OutBackDingodumb question can say distro = "test" inherit all from another distru "test2" ??12:29
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto12:35
*** mihai is now known as Guest2549612:36
*** mihai- is now known as mihai12:36
*** Guest25496 <Guest25496!~mihai@unaffiliated/mihai> has quit IRC12:39
*** kpo_ <kpo_!> has quit IRC12:46
*** kpo_ <kpo_!> has joined #yocto12:46
*** Bunio_FH <Bunio_FH!> has joined #yocto12:46
RPOutBackDingo: definitely, poky-altcfg and poky-tiny do that12:53
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto12:59
*** paulg <paulg!> has joined #yocto13:04
*** d32 <d32!2ef3c527@> has joined #yocto13:07
*** rcw <rcw!~rcw@> has joined #yocto13:09
*** Bunio_FH <Bunio_FH!> has quit IRC13:11
*** paulg <paulg!> has quit IRC13:13
*** paulg <paulg!> has joined #yocto13:15
*** d32 <d32!2ef3c527@> has quit IRC13:16
eduardasrburton: do suggestions to improve standard poky bitbake classes fit within the meta-yocto category here?
eduardasrburton: then what category in bugzilla do I use?13:30
rburtonfor anything in oe-core, build system -> oe-core13:30
rburtonmeta-yocto is
eduardasrburton: thank you. It was confusing for me.13:32
*** ssajal <ssajal!> has quit IRC13:40
*** kaspter <kaspter!~Instantbi@> has quit IRC13:47
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:47
*** ssajal <ssajal!> has joined #yocto13:49
eduardasrburton: registered enhancement request here
eduardasrburton: if I have messed this up, please let me know13:51
rburtontriage will deal with that on thursday13:51
eduardasrburton: ok, was not aware13:52
*** AndersD <AndersD!> has joined #yocto13:56
eduardastried building lapack nad got "libgfortran was skipped: libgfortran needs fortran support to be enabled in the compiler"13:59
eduardashow am I supposed to properly enable fortran support in yocto?13:59
*** ericch <ericch!> has joined #yocto14:00
*** ThomasD13 <ThomasD13!> has quit IRC14:01
rburtoneduardas: google?  FORTRAN_forcevariable = ",fortran" in local.conf14:04
*** cp- <cp-!> has quit IRC14:06
*** cp- <cp-!> has joined #yocto14:07
*** cp- <cp-!> has joined #yocto14:09
*** stephano <stephano!> has joined #yocto14:12
*** armpit <armpit!~armpit@2601:202:4180:a5c0:1ce8:b073:6e6a:c331> has quit IRC14:15
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto14:20
ptsnevesHey guys, i just rebased on the latest master and having issues building.14:21
ptsnevesRROR: gnu-config-native-20200831+gitAUTOINC+0b5188819b-r0 do_unpack: Unpack failure for URL: 'git://'. No up to date source found: clone directory not available or not up to date: /var/fpwork/desousan/home/emergency-fix1/builds/yoctobuild/downloads/git2/; shallow clone not enabled14:21
*** armpit <armpit!~armpit@2601:202:4180:a5c0:9d97:e0e:5802:c8f4> has joined #yocto14:28
pevIm playing with a qemuarm target and making various changes - it seems that it's not that easy to extend qemuarm or the runqemu script... Is it the 'right' thing to do to create a new machine cloning qemuarm and a new run script?14:28
ptsnevespev yes. It is trivial to create new machines in yocto. I think you can even include the other conf14:30
*** OnkelUll1 is now known as OnkelUlla14:31
qschulzptsneves: indeed, you just need to do `require path/to/machine/qemu.conf` with path/to/machine/qemu.conf being the path relative to the root of the layer in which it is stored14:32
ptsnevesqschulz thanks for the extra detailed info :)14:33
pevptsneves, Yeah, I can see that for the machine, but with the 'runqemu' script should one just create a new bsp specific version?14:33
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC14:34
ptsneves@pev can i ask what exactly are you trying to extend in runqemu? There are some extra variables that allows some configurability of runqemu14:35
pevfor example I need to setup additional flash images. I can use QB_OPT_APPEND, but then Im forced to use (potentially incorrect) full paths into tmp/deploy... as reqemu isn't that clever...14:36
pevIm adding u-boot build for qemuarm, persistant image backing for the two flash images to allow saveenv to work. Im also trying to work out why u-boots virtio networking is failing with qemu ... and currently failing!14:37
*** eduardas <eduardas!~eduardas@> has quit IRC14:38
ptsneveshmm are you able to use runqemu through yocto to run qemu? Would you not need completely different flags? If your problem is only with the deploy dir there is the
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto14:40
*** RobertBerger <RobertBerger!~rber@2a02:587:3b0d:ecec:6db1:3adf:bfd6:e7ed> has joined #yocto14:41
pevptsneves, I can use runqemu to do it but only if I hardcode paths given to QB_OPT_APPEND e.g. QB_OPT_APPEND += "-drive if=pflash,format=raw,index=0,file=tmp/deploy/images/qemuarm-swu/flash0.img"14:42
pevin my bsps conf/machine/qarmemu-flash.conf14:43
pevthat keeps letting me use "runqemu" which is convenient, but Im aware it's a bodge14:43
ptsnevespev what about the QB_OPT_APPEND += "-drive if=pflash,format=raw,index=0,file=${DEPLOY_DIR_IMAGE}/flash0.img"14:43
pevHm, I hope it's really not that embarassingly simple... :-D14:44
*** Bunio_FH <Bunio_FH!> has joined #yocto14:44
ptsneveswell i hope it is :D14:45
pevOh man, it was. Total brain fart last night at 1am...!14:46
ptsnevesno problem, you are into deep stuff and the manual is big. Glad to be of help14:47
*** w00die <w00die!~w00die@> has quit IRC14:48
pevOn the topic of bodges, Im creating flash images in the u-boot's recipe using do_deploy_append() but I have a sneaking suspicion it's probably not the 'right' place...?14:49
*** ak77 <ak77!c12e4b03@> has quit IRC14:49
*** w00die <w00die!~w00die@> has joined #yocto14:50
ptsnevespev do not know. The issue with bootloaders is that often uboot is just one of the blobs. I honestly just use the do_deploy also :D14:52
ptsnevesqschulz do you now how to properly generate the uboot binary blobs?14:52
ptsnevesi would read the default uboot recipes as well as the inc files14:53
qschulzptsneves: the question is not really complete14:53
qschulzbut basically, compilation or logic to do to create something? do_compile14:53
ptsnevesi guess to make the binary blob available in the DEPLOY_DIR_IMAGE14:54
qschulzthen you install them where they need to be in the target FS in do_install and if you need something in the deploydir (think and rethink again if you REALLY need to dot hat and why) available as an artifact: do_deploy14:54
pevptsneves : Yeah, it's more complicated soon too as what Im ultimately needing todo is to create an initial set of qemu images with various emulated partitions created. I suspect all of them, including the pflash images should be created in the same recipe / rule, but not sure which14:54
*** Bunio_FH <Bunio_FH!> has quit IRC14:55
qschulztake do_deploy as do_install but to make files available as a build artifact available on the host (but compiled for the target ofc)14:55
pev*** qemu virtual *disk* images, that is'14:55
ptsnevesqschulz thanks. That was our idea also :)14:55
qschulzpev: new to this, but probably you are looking for a new IMAGE_FSTYPES (using IMAGE_CMD IIRC, read image_types.bbclass) or some ROOTFS_POSTPROCESS_COMMAND or IMAGE_POSTPROCESS_COMMAND or something along those lines14:56
*** xtron <xtron!~xtron@> has joined #yocto14:57
qschulz ?14:57
pevqschulz: Ah thanks... I was starting to think along those lines as "virtual flash images" don't quite fit into the box of rootfs or recipe install rule... Just can't quite get my head around what's "right" or "yocto-ish" yet!14:57
qschulzpev: distro, machine, image recipe, package recipe are all the things you can change/add and safely share in a layer15:04
qschulzpev: with what you're telling us, it really looks like something to handle in an image recipe :)15:04
*** roussinm <roussinm!> has joined #yocto15:05
*** Bunio_FH <Bunio_FH!> has joined #yocto15:08
*** kaspter <kaspter!~Instantbi@> has quit IRC15:09
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:10
ptsnevespev the way i normally did the image recipe also "produce" the bootloaders, was to add a do_image_<your fstype>[depends] = "<your boot loader recipe> <your extra blobs>"15:10
ptsnevesnormally i chose IMAGE_FSTYPES += "wic" and so do_image_wic[depends] += "boot-image:do_deploy"15:11
ptsnevesof course i had a recipe which was called boot-image that deployed all my boot blobs15:12
qschulzptsneves: not really, it's EXTRA_IMAGEDEPENDS set in the machine conf file :)15:12
ptsnevesqschulz thanks for the tip :D15:12
ptsnevesqschulz did not know :)15:13
*** jmiehe <jmiehe!> has quit IRC15:13
qschulzptsneves: :)15:13
qschulzptsneves: which probably does exactly what you wrote :)15:13
*** kaspter <kaspter!~Instantbi@> has quit IRC15:14
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:14
ptsnevescontinuing: Then i would create a wks file which would generate the whole binary image containing not only the fs image but also the binary blobs. The wks for something like i am talking looked like this
ptsnevesqschulz that is slightly different. It is a depends on a recipe and i wanted dependency on tasks, specifically the do_deploy15:15
ptsnevesqschulz  for that to be useful the recipe of the bootloader would need to install something in a linux like path which does not make sense for a boot loader blob15:16
*** Bunio_FH <Bunio_FH!> has quit IRC15:17
*** Bunio_FH <Bunio_FH!> has joined #yocto15:20
qschulzptsneves: mmmm.... I learned something today. So EXTRA_IMAGEDEPENDS is just an "alias" for do_image_complete[depends] += "recipe:do_populate_sysroot"15:21
qschulzi'd have expected it to depends on do_depend actually15:21
qschulzstill, it is indeed not enough if you need it before do_image_complete (which is probably the case if you want to use it in a wks)15:22
ptsnevesqschulz that is my understanding let me look at image.bbclass...15:22
ptsnevesqschulz d.appendVarFlag('do_image_complete', 'depends', extraimage_getdepends('do_populate_sysroot'))@image.bbclass15:24
ptsnevesso yep what you described a normal DEPENDS15:24
*** Bunio_FH <Bunio_FH!> has quit IRC15:24
qschulzptsneves: not really, because DEPENDS also populates the recipe-sysroot* of the recipe (yes, even for an image recipe) :) but yeah, same hooks are used15:26
ptsnevesqschulz ohhhh. i am an old timer on krogoth :(   so this subtelties were lost in me. Very good info to keep in mind on my upcoming update15:27
qschulzptsneves: oh jeez, poor you15:28
qschulzptsneves: had the chance to never work on it (though parts of our projects still use this version, I could until now not debug it :) )15:29
*** AndersD <AndersD!> has quit IRC15:30
qschulzptsneves: so I tend to forgot per recipe sysroot is still not used by some people :/15:32
*** dev1990 <dev1990!> has quit IRC15:32
*** dev1990 <dev1990!> has joined #yocto15:32
ptsnevesactually the per sysroot feature is the biggest reason we want to update. The races on a shared sysroot are mind buzzing :(15:33
ptsnevesauto detection build systems detecting something sometimes and others not15:33
kergothi dont miss those issues, builds were never reproducible and sstate reuse was problematic as a result15:36
kergoththank goodness rp and the rest made it happen. i think that was on our todo list for like 8 years or something :)15:36
kergothcan i just take a moment (not for the first time) to note that oe has existed for 17-18 years now? holy hell15:38
ptsnevescongrats and big thanks to the people who make it happen15:38
*** Nooks <Nooks!> has joined #yocto15:41
*** Bunio_FH <Bunio_FH!> has joined #yocto15:41
*** ptsneves <ptsneves!b0dd7824@> has quit IRC15:43
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto15:46
*** leon-anavi <leon-anavi!~Leon@> has quit IRC15:47
moto-timokergoth: time flies15:47
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto15:47
*** kiwi_29 <kiwi_29!> has joined #yocto15:58
kiwi_29Hello.. my custom distro is based on deb pacakges. One of my custom recipes "custrecipe1" installs a file in /usr/lib/SHAREDLIB.SO this shared lib is also provided by another package - "anotherpkg1" .15:59
kiwi_29Therefore while generating rootfs, when custrecipe1.deb is being installed there is an error15:59
qschulzkiwi_29: why do you need this lib twice?16:00
kiwi_29dpkg: error processing archive custrecipe1.deb (--unpack):16:00
kiwi_29Don't need it twice16:00
qschulzkiwi_29: then don't install it :)16:00
kiwi_29anotherpkg1 is installed as package directly as dependeny of other packages16:01
kiwi_29Custerecipe1 compiles some software and also generated the shared lib which is same as name as anotherpkg116:02
zeddiiso change the recipe for Custerecipe1 and don't package that library.16:03
ptsnevesare these sharedd libs based on the exact same code?16:03
*** kiwi_29 <kiwi_29!> has quit IRC16:04
RPkergoth: makes us feel old! :)16:05
zeddiiI'm a young one in the mix. and I've been at it for 10 years :D16:06
kergothyeah.. i just dug into the meta-metnor history to figure out when i changed something. it was 8 years ago. still at mentor. :)16:06
*** leonanavi <leonanavi!~Leon@> has joined #yocto16:06
RPkergoth: its when it gets back to the bitkeeper cvs it gets scary :)16:07
moto-timobitkeeper **shudder**16:07
kergothyeah i still have the bkbits tarballs on my nas somewhere from the exports from that. i don't think i have the cvs archives that preceded it though16:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC16:09
kergothit bothers me some days how much history of software gets lost over the years. versions of major projects that nobody has anymore unless its on some cd in someone's closet16:09
kergothprior to scm, anyway16:09
*** kpo_ <kpo_!> has quit IRC16:09
*** kiwi_29 <kiwi_29!> has joined #yocto16:09
kiwi_29the code in custrecipe1 for shared lib is a lil different than anotherpkg116:10
*** kpo_ <kpo_!> has joined #yocto16:10
*** pev <pev!> has quit IRC16:11
RPkergoth: I think we did an ok job of at least pulling in the majority of the history. It is useful, the bigger problem was our lack of comments back then! :)16:11
RP(and I'm as guilty as anyone)16:11
ptsneveskiwi_29 then if it is different you should either name the library differently or version it differently. Of course if it is getting there by mistake you should rework the recipe16:12
kergothagreed. i used to have a habit of not including enough *why* in my commit messages. lets just list what i'm doing, which is already in the damn diff. *eyeroll*16:12
ptsneveskergoth you would be surprised how in 2020 almost 2021 this is still not done :(16:13
RPkergoth: right, I've made assumptions about things I'd remember too, which misses another key point16:13
*** pev <pev!> has joined #yocto16:13
kiwi_29There was something related to assume_shlibs ..will that help ?16:13
sgwRP: Morning, So my dumper changes failed badly or uncovered different issues?16:13
RPsgw: they cause backtraces on the autobuilder16:14
RPsgw: I didn't look into why16:14
kergothkiwi_29: like ptsneves implied, the answer is "don't do that". either don't install both, or rename one, or otherwise avoidt he conflict16:15
sgwRP: that's strange, I did not see that, but I did local testing with a couple of different qemu images, I will have to try to force different errors.16:18
RPsgw: I'm assuming the autobuilder tested some path you didn't. You can see a few failures so I'm hoping it will reproduce ok16:18
*** roussinm <roussinm!> has quit IRC16:20
sgwRP: yeah, I saw those, I will give them a try later today.16:20
*** kiwi_29 <kiwi_29!> has quit IRC16:21
NooksI'm having trouble building a /usr/bin/php that has fnmatch() support, and I'm not really sure how to fix it.  The version of PHP I'm building is 7.2.10 from meta-openembedded.16:22
*** chris_ber <chris_ber!~quassel@> has quit IRC16:22
JaMamy first change was in monotone and OE was the only reason for me to ever use monotone :)16:22
Nooks(it's 7.2.10 becuase the project is based on Thud for other reasons)16:22
NooksI'm not totally sure about what's gone wrong, but it looks like PHP checks for fnmatch.h using AC_FUNC_FNMATCH, which looks like it might be checking for cross-compilation.16:23
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto16:24
RPJaMa: its the only time I ever used monotone either16:24
*** mckoan is now known as mckoan|away16:24
RPsgw: I'm keen to get the changes in, I just had bigger issues with pseudo over the weekend16:25
*** camus1 <camus1!~Instantbi@> has joined #yocto16:28
*** kaspter <kaspter!~Instantbi@> has quit IRC16:30
*** camus1 is now known as kaspter16:30
RPA green master-next with the pseudo changes in too: :)16:37
JaManice :)16:41
moto-timopseudo makes my head hurt16:46
*** Bunio_FH <Bunio_FH!> has quit IRC16:46
*** leonanavi <leonanavi!~Leon@> has quit IRC16:51
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto16:51
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:55
rburtonmoto-timo: if it doesn't, then worry16:57
*** feddischson <feddischson!> has quit IRC17:00
RPI'm still kind of in awe of the way the wrapper generation works17:01
ptsneveswhere does the need for changes in pseudo come from? Is its functionality changing over time?17:06
*** meow` <meow`!~sbourdeli@> has quit IRC17:09
RPptsneves: realisation that its corrupting file modes quietly17:09
ptsnevesuhhh, how come quietly? In our system we have a file list checker that also checks for permission changes and no issues. Is it a recent issue?17:10
ptsnevesi mean root file system file list checker17:10
ptsnevesdoes it happen for packaged files or generally17:11
armpitmoto-timo, I have a patch for that17:11
RPptsneves: its a rare race problem related to inode number reuse17:12
RPptsneves: it would happen for packaged files, its certainly rare but I don't like rare issues like this17:12
*** davidinux <davidinux!~davidinux@> has quit IRC17:13
*** xtron <xtron!~xtron@> has quit IRC17:16
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC17:27
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto17:29
sgwRP: got it to reproduce with the qemuarm-oecore build local.  trying to understand why now.17:33
*** kiwi_29 <kiwi_29!> has joined #yocto17:35
*** kiwi_29 <kiwi_29!> has quit IRC17:39
*** kiwi_29 <kiwi_29!> has joined #yocto17:40
*** davidinux <davidinux!~davidinux@> has joined #yocto17:43
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:46
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto17:47
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC17:47
zeddiiRP: I recently introduced a busybox recipe/config that is tailored for initrds in meta-virt. Martin followed up to say that due to it having a static configuration, some distros can blow up when they include meta/conf/distro/include/ .. What's the policy in adding exceptions to that file ? I can't think of a way to work around this in the meta-virt layer without breaking yocto policy (we17:47
zeddiill, I suppose I can make a new distro feature).17:47
*** jobroe <jobroe!> has quit IRC17:49
*** kiwi_29 <kiwi_29!> has quit IRC17:53
*** kiwi_29 <kiwi_29!> has joined #yocto17:54
*** Tofe <Tofe!> has joined #yocto17:54
*** Bunio_FH <Bunio_FH!> has joined #yocto17:55
*** kiwi_29 <kiwi_29!> has quit IRC18:06
*** kiwi_29 <kiwi_29!> has joined #yocto18:08
RPzeddii: we can make exceptions to the no-static-libs18:08
RPzeddii: we used to do it for pseudo-native. The point of the file is to stop building stuff we don't need/use/care about18:09
zeddiiok. so if I sent a patch to add libxcrypt, it won't be denied as 100% incorrect. (It may be denied for other reasons, but that's a different story).18:11
RPrburton: master-next is throwing a ton of warnings about not being able to reset nice levels. Is that related to anything you changed?18:11
*** kiwi_29 <kiwi_29!> has quit IRC18:11
*** kiwi_29 <kiwi_29!> has joined #yocto18:11
RPzeddii: as long as you can state why and probably document that in comments in the file, not automatic18:13
zeddiiwill do. otherwise, I'm doing some kind of funky distro feature dance. I can fall back to that as appropriate.18:14
RPzeddii: would you video the funky dancing? :)18:14
zeddiino video of me dancing shall ever be made :P18:14
*** kiwi_29 <kiwi_29!> has quit IRC18:14
*** kiwi_29 <kiwi_29!> has joined #yocto18:20
rburtonRP: huh, shouldn't be18:27
RPrburton: its happening in rpm postinsts, other than that the logs are unhelpful18:29
rburtonvery surprised if its something i broke18:30
RPrburton: looking at the patches in -next, its hard to know which others :/18:30
RPrburton: I'm not saying it is yours but I am puzzled as to what else has touched rpm18:32
RPrburton: the pseudo ones are unchanged since the previous run18:32
rburton'i'm not saying its yours, but it's yours' ;)18:34
RPrburton: I just can't prove it yet18:34
rburtonon boot or at rootfs?18:35
RPrburton: do_rootfs  with rpm18:36
rburtonkicking a build now18:36
rburtonmaybe its the plugin stuff18:37
rburtonah i have a hunch18:37
rburtonyeah fine its my fault18:37
*** Bunio_FH <Bunio_FH!> has quit IRC18:38
RPrburton: :)18:38
*** kiwi_29 <kiwi_29!> has quit IRC18:39
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:39
*** kiwi_29 <kiwi_29!> has joined #yocto18:39
*** Bunio_FH <Bunio_FH!> has joined #yocto18:41
rburtonRP: v2 sent18:43
RPrburton: thanks :)18:44
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:10b2:ae0f:a8cb:5231> has joined #yocto18:47
sgwRP: found 1 of the issues and recent v2, it might still run more frequently, need to fix the status check in still18:48
havok101Hey, I've written a simple recipe for an app I'm building. But each time I build it I see fatal error: unistd.h: No such file or directory. If I used the sdk to build it, it builds fine.18:49
Nooksok, editing main/php_config.h in do_configure_append() makes a php binary with fnmatch() (according to php --rf fnmatch)18:50
havok101Only thing I feel I'm doing unconventional is OECMAKE_SOURCEPATH = "${S}/Apps-c++". Because the root cmake list is located under a sub directory18:50
Nooksif I had to guess I would say that the cross-compile check in AC_FUNC_FNMATCH is to blame, but I am still curious as to how other autoconf-using software built by Yocto gets a working fnmatch()18:51
*** Bunio_FH <Bunio_FH!> has quit IRC18:51
*** kiwi_29 <kiwi_29!> has quit IRC18:53
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC18:55
*** kiwi_29 <kiwi_29!> has joined #yocto18:55
havok101yeah I can build a whole image. Just this one is having a problem.18:55
RPsgw: ok, I'll give it another try on the autobuilder, thanks18:56
sgwRP: sorry about that, I think I tested it one way.18:59
RPsgw: its ok, we have a lot of codepaths in this case19:01
*** paulg_ <paulg_!> has joined #yocto19:03
* RP suspects cancelling his build succeeded in giving sakoman all the workers :)19:03
*** paulg_ <paulg_!> has quit IRC19:03
*** kiwi_29 <kiwi_29!> has quit IRC19:04
sgwRP: on a different topic, what's your thoughts on debugging a sstate issues?19:05
RPsgw: that its a good thing to do? ;-)19:08
RPsgw: (you may need to be more specific)19:08
sgwyeah, I see bitbake do the setscenes but then starts fetching, unpacking, ...19:09
RPsgw: when you weren't looking we changed the way this works a bit19:09
sgwThis is not a poky related issue, so there are other things I need to deal with.19:09
RPsgw: as part of the hash equivalence work, we removed the contraints around setscene, then build19:10
RPsgw: bitbake now dynamically adapts as it goes19:10
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto19:12
sgwThoughts on where   to go looking then or enabling debug on?19:12
RPsgw: you've given me no idea what kind of issue you're looking at so I have no idea19:13
moto-timonot the first time sgw has been slightly random ;)19:13
sgwWhat we are seeing is the kernel rebuilding and not using sstate from fresh build directories with no configuration changes.19:13
RPsgw: ah, now there is a better clue19:14
sakomanRP: yes, it did!  Thanks :-)19:14
RPsgw: I'm going to guess its module which needs a full kernel build directory19:14
RPguess its some kernel module which19:14
RPsgw: that is expected unfortunately19:15
sgwInterestingly, if I just rm TMPDIR and run bitbake in the same builddir it does use sstate correctly19:15
RPwas there an external module in the second build that wasn't in the first?19:15
sgwbut if have a different BBPATH (ie different builddir) it rebuilds.19:16
sgwNope everything is identical19:16
sgwOnly the actual build directory changes19:16
RPhmm, that is stranger then. It shouldn't depend on BBPATH or TOPDIR19:16
RPsgw: save the stamps directories from both builds and compare?19:16
RPsgw: oh, is hashequiv enabled?19:17
sgwI saves the siginfo from one build and then tried diffsig from the second and they are the same19:17
RPa non-common hash equiv and shared sstate dir would do this19:17
*** kiwi_29 <kiwi_29!> has joined #yocto19:17
RPsakoman: I need to write the prioritisation function a little differently :)19:19
*** kiwi_29 <kiwi_29!> has quit IRC19:20
*** kiwi_29 <kiwi_29!> has joined #yocto19:21
*** kiwi_29 <kiwi_29!> has quit IRC19:26
*** kiwi_29 <kiwi_29!> has joined #yocto19:27
*** roussinm <roussinm!> has joined #yocto19:32
*** WillMiles <WillMiles!~Will@> has joined #yocto19:35
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has quit IRC19:41
*** ssajal <ssajal!> has quit IRC19:42
*** ssajal <ssajal!> has joined #yocto19:44
*** kpo_ <kpo_!> has quit IRC19:56
*** kpo_ <kpo_!> has joined #yocto19:56
*** feddischson <feddischson!> has joined #yocto20:02
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC20:03
*** ecdhe_ <ecdhe_!> has joined #yocto20:03
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:03
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC20:11
*** ericch <ericch!> has quit IRC20:15
*** ericch_ <ericch_!> has joined #yocto20:16
*** goliath <goliath!> has quit IRC20:20
*** pev <pev!> has quit IRC20:21
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:45
*** ecdhe_ <ecdhe_!> has quit IRC20:48
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC20:48
*** leonanavi <leonanavi!~Leon@> has joined #yocto20:48
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:48
*** kamensky <kamensky!806bf1bc@> has joined #yocto20:51
*** leon-anavi <leon-anavi!~Leon@> has quit IRC20:51
*** feddischson <feddischson!> has quit IRC20:53
*** beneth <beneth!> has left #yocto20:56
*** pev <pev!> has joined #yocto20:57
*** Konsgnx <Konsgnx!> has quit IRC21:03
*** pohly <pohly!> has quit IRC21:07
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC21:09
*** berton <berton!~berton@> has quit IRC21:16
sgwRP: so much for getting it right the first time, looks like v3 should do the correct trick.  Got the status and string checks fixed the right way around!21:23
RPsgw: ah. So I abort this one and retry?21:24
sgwThat looks like it still has to original code, so abort and use v3 please.21:25
RPsgw: done, restarted21:26
RPsgw: hanks21:26
RPthanks :)21:26
sgwsorry about the re-tries.21:27
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto21:27
*** leonanavi <leonanavi!~Leon@> has quit IRC21:27
sgwhalstead: It was great to have a real happy hour with you friday!21:29
RPsgw: I had a few with pseudo and its not the only patchset which has been fun recently21:31
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC21:31
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto21:38
*** kiwi_29 <kiwi_29!> has quit IRC21:39
*** dusry <dusry!> has joined #yocto21:53
dusryHi, everyone. Has anyone ever seen 'devtool modify' fail on do_unpack for the u-boot recipe. I get a ModuleNotFoundException for _sysconfigdata. Devtool has only failed on this one recipe.21:57
khemseems like a python related error21:58
khemis it on master branch21:59
dusryYeah, that's what I noticed. I get a stack trace from Python. Currently it is. I have tried both dunfell and master.21:59
dusryThis same issue also occurs for u-boot-ti-staging in meta-ti, but the TI guys haven't responded.22:00
RPdusry: there have been reports on the mailing list but we've never had a patch to fix this properly (and we don't fully understand the error)22:03
kergothhmm, seems -fuse-ld doesn't work with our gcc-cross-canadian in an sdk, it just always uses what we built with using LDGOLD, even  though we enabled gold whether it was default or not..22:04
kergothguessing its probably something to do with our various symlinks in the gcc-cross-canadian build process22:05
dusryRP I recently posted on the mailing list about it. I'd be happy to help look into it, but I'm not really sure where to start looking. Still learning the whole system.22:06
dusryYou can also find the stack trace in what I sent to the mailing list, or I can send it again.22:06
*** camus1 <camus1!~Instantbi@> has joined #yocto22:07
kergothrunning into ""ARM external linker must be gold"" in the go-runtime build using an external oe sdk as an external toolchain, since it fails to use -fuse-ld=gold to switch22:08
RPdusry: was one "fix" and there were others, this has been going on for a while. I stopped taking these patches as there is clearly a bugger issue we need to get to grips with22:08
kergothdusry: you sh ould chekc the mailing list archives, there've been at least 3 threads that i know of22:08
*** kaspter <kaspter!~Instantbi@> has quit IRC22:08
*** camus1 is now known as kaspter22:09
RPdusry: I suspect the real fix will be to patch our python to look for an OE specific variant of this environment variable name, then we can set one for our python which the OS python won't see/use22:11
RPbut I am guessing at it22:12
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC22:13
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto22:13
dusryRP thank you for the info. Might be the push I need to go explore the inner workings of OE.22:14
RPdusry: I think in some ways it may be a similar issue to this one
RPdifferent variable name, possibly similar issue though?22:18
*** dreyna <dreyna!> has joined #yocto22:19
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:10b2:ae0f:a8cb:5231> has quit IRC22:19
*** kiwi_29 <kiwi_29!> has joined #yocto22:24
*** The_Pacifist <The_Pacifist!> has joined #yocto22:25
The_PacifistIs there a way to share a custom/vendor_specific kernel object between multiple meta-bsp layers?22:30
*** kamensky <kamensky!806bf1bc@> has quit IRC22:31
The_PacifistFor clarity, I have a driver I pull down from a vendor's website as part of a .bbappend file inside a recipe-bsp dir, inside a a meta-bsp dir22:31
*** itseris <itseris!> has quit IRC22:31
The_PacifistMy question is, can I share that driver with multiple meta-bsp's22:32
*** rcw <rcw!~rcw@> has quit IRC22:32
*** kiwi_29 <kiwi_29!> has quit IRC22:32
The_PacifistIs it a bad idea to put it in a non-hardware meta layer?22:32
*** kiwi_29 <kiwi_29!> has joined #yocto22:33
*** itseris <itseris!> has joined #yocto22:33
*** camus1 <camus1!~Instantbi@> has joined #yocto22:33
*** kaspter <kaspter!~Instantbi@> has quit IRC22:34
*** camus1 is now known as kaspter22:34
*** pev <pev!> has quit IRC22:41
*** dev1990 <dev1990!> has quit IRC22:54
*** kiwi_29 <kiwi_29!> has quit IRC22:55
dusryThe_Pacifist I feel like that's the only way outside of maintaining two copies. Doesn't seem like there is anything wrong with it. Just make sure you prioritize your layer correctly.22:56
*** kiwi_29 <kiwi_29!> has joined #yocto22:57
*** dusry <dusry!> has quit IRC23:02
*** agust <agust!> has quit IRC23:03
*** kiwi_29 <kiwi_29!> has quit IRC23:05
halsteadsgw, Just caught your message. Thank you. It was nice to have an in person conversation about Yocto Project. And the porter was darn good too.23:08
*** kiwi_29 <kiwi_29!> has joined #yocto23:08
RPhalstead: wish I could join you for some porter! :)23:27
halsteadI wish you could too RP23:27
zeddiisakoman: I built the one arch that still builds with 5.4.61+ and lttng-modules. which is why mine didn't blow up :D23:27
sakomanzeddii: what are the odds . . .  ;-)23:28
zeddiiwhen I looked at your links, it was obvious :D23:28
*** kiwi_29 <kiwi_29!> has quit IRC23:29
*** kiwi_29 <kiwi_29!> has joined #yocto23:29
*** kiwi_29 <kiwi_29!> has quit IRC23:40
*** kiwi_29 <kiwi_29!> has joined #yocto23:43

Generated by 2.17.2 by Marius Gedminas - find it at!