Friday, 2019-12-06

*** goliath <goliath!> has quit IRC00:00
*** ericch <ericch!> has quit IRC00:16
*** MiskaX <MiskaX!> has joined #yocto00:17
*** dreyna_ <dreyna_!> has quit IRC00:24
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC00:33
*** cp- <cp-!> has quit IRC00:38
*** cp- <cp-!> has joined #yocto00:40
*** creich <creich!> has joined #yocto00:58
*** comptroller <comptroller!> has quit IRC01:32
*** creich <creich!> has quit IRC01:40
*** Willy-- <Willy--!> has quit IRC01:55
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto02:39
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC02:42
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d00:b1:225:90ff:feda:2428> has joined #yocto02:43
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d00:b1:225:90ff:feda:2428> has quit IRC03:01
*** fatalhalt <fatalhalt!> has joined #yocto03:04
*** Domin1k <Domin1k!c1669b04@> has quit IRC03:04
*** gtristan__ <gtristan__!6e0be3b1@> has joined #yocto04:08
gtristan__Hi, I'm trying to preserve the sstate cache directory between builds in a project which was previously not doing this, in order to increase build time... and in doing so I've encountered an error which appears to be quite exactly like this one: , basically I get a "value foo.service04:11
gtristan__does not exist" from do_package04:11
gtristan__This only happens the second time, after checking out the whole fresh source tree a second time but rigging it up so that it's sstate-cache directory is a symlink to an out of tree directory where I preserved the cache from a previous (successful) build04:12
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC04:14
gtristan__Now, I've followed the advice of Matt Madison from the mentioned post and used systemd_system_unitdir instead of the previous "${systemd_unitdir}/system", and still get the same error... so my question (...drumroll...) is do I need to delete the sstate cache and start over in order to properly test my change ?04:14
gtristan__Also, at the same time I'll start reading into in this project but, if there are any recommendations on how I should be debugging this that would be very helpful04:16
gtristan__Extra verbose mode possible ?04:16
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto04:19
yoctiNew news from stackoverflow: Bitbake not installing files from recipe to rootfs <>04:40
gtristan__Ok simpler question: Once I've sourced the set_bb_env for the given project and am ready to build things... how can I find out what the value of a given variable would be for a given recipe ?04:59
gtristan__Like say, DISTRO_FEATURES for example, how can I print what bitbake thinks it is ?05:00
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto05:23
*** opello <opello!~opello@about/csharp/regular/opello> has joined #yocto05:24
opellohi, it seems as of openembedded-core 6661718158f8fdcdf63b0d48e8fe72d3ac4778f2 the ultimate package architecture (TUNE_PKGARCH) has changed under some circumstances (including mine; from cortexa9hf-vfp-neon to cortexa9hf-neon) which makes generated rpms incompatible; the commit suggests there's a way to preserve an upgrade path, but i don't quite understand what "don't forget to migrate PR service database to new TUNE_PKGARCH" is suggesting05:29
*** jaganteki <jaganteki!31cecb5c@> has joined #yocto05:44
*** gtristan__ <gtristan__!6e0be3b1@> has quit IRC05:45
*** ThomasD13 <ThomasD13!> has joined #yocto06:00
*** AndersD <AndersD!> has joined #yocto06:21
*** pohly <pohly!> has joined #yocto06:49
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:59
*** agust <agust!> has joined #yocto07:02
bojonesIf a recipe is depending on another package being installed, will IMAGE_INSTALL_append = " <package>" give the same result as RDEPENDS += "<package>" ?07:03
bojonesThe right way to specify the dependency, is using RDEPENDS, right?07:04
bojonesWell, never mind my question before. After thinking about it for a while, the difference is obvious.07:08
*** guerinoni <guerinoni!> has joined #yocto07:08
yoctiNew news from stackoverflow: Yocto - Files/directories were installed but not shipped in any package <>07:11
*** fatalhalt <fatalhalt!> has quit IRC07:16
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:41
*** mckoan|away is now known as mckoan07:42
*** TobSnyder <TobSnyder!> has joined #yocto07:46
*** frsc <frsc!> has joined #yocto07:49
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:58
*** diego_r <diego_r!~diego@> has joined #yocto08:21
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC08:39
Ad0I can't seem to find a .gitignore template for yocto projects, maybe it's too variable. only thing I can think of is to ignore build directory08:53
LetoThe2ndjust ignore the buld directory, done.08:54
* alessioigor waves all09:04
alessioigorI'm trying to find what package add a file into the image. To do this I use find into all "image" directory of all packages. Unfortunately after first build bitbake doesn't make the image directory. How force it to do it?09:04
alessioigorThanks in advance!09:05
LetoThe2ndalessioigor: oe-pkgdata-uril09:06
LetoThe2ndutil, even09:06
angelo__hi, is there a simple way to know all packages of an image recipe that involves postinst scripts ^09:18
angelo__ops .. ?09:18
Ad0LetoThe2nd, hehe.09:24
Ad0if I add a bb with a higher version in my custom layer, overriding another layer's recipe, can I refer to the other layer's files in a nice way? or do I have to do something like ../../other-layer or something09:25
Ad0it has a bunch of .patch files that I don't touch09:26
LetoThe2ndi think it should work just like they were in the directory next to each other.09:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:28
Ad0it says missing files :/09:28
LetoThe2ndthen i'm probably wrong. happends, that.09:28
Ad0hehe the structure is a bit different to in that layer09:29
qschulzAd0: FILEEXTRAPATHS_prepend := to the other layer recipe09:29
Ad0it's meta-security/meta-tpm - so it's a layer in it's subdir. but I include that layer in the bblayers.conf like meta-security and meta-security/meta-tpm (and under that /recipes-tpm.  in my layer it's meta-mylayer/recipes-tpm09:30
qschulzbut it's still relative to something. you have THISDIR or COREBASE available but that's still not great great09:30
LetoThe2ndqschulz: i would have expected the file lookup to happen after the virtual layer flattening, but hey, i'm often mistaken there.09:30
LetoThe2ndand of course, if the structure is different, then it doesn't work09:31
qschulzLetoThe2nd: "the virtual layer flattening" what's that?09:32
Ad0but a meta layer subdir will be flat when included in the bblayers09:32
LetoThe2ndAd0: to my understanding, all layers basically flattened into one state, which is what bitbake actually uses to run its tasks then. but like i said, i might be wrong09:33
LetoThe2ndthat was for qschulz. :) but better ask kergoth or RP about it :)09:34
*** khem <khem!~khem@unaffiliated/khem> has quit IRC09:36
qschulzLetoThe2nd: anything that isn't set with := is done after flattening is my gut feeling.09:36
LetoThe2ndqschulz: no idea, honestly.09:36
qschulz(hence FILEEXTRAPATHS_prepend := "${THISDIR}/files" in bbappends09:36
qschulzotherwise if it's resolved after flattening, THISDIR is the dir of the original bb (?)09:37
*** sashko <sashko!~sashko@> has quit IRC09:39
qschulzkanavin__: FYI, error at compilation time for gobject-introspection happens only with icecc enabled also on plain poky. I tested on Warrior 2.7.2 and master (109ef2e5c4161a2c0ac58bede3daa48c7b4881ec). Going to send a mail09:48
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto09:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:53
RPqschulz: correct, that is why := is needed with THISDIR09:55
wertigonWhat is a symlink to /etc/ doing in the mingw folder?09:57
RPwertigon: a bug?10:00
wertigonRP: Possibly10:00
wertigonOr simply a mingw artifact10:01
RPwertigon: there is image/sdk post processing and I suspect it assumes linux and needs turning off for mingw10:01
wertigonIt does seem weird to me that the x86_64-mingw32 toolchain folder contains that link in particular10:02
wertigonRP: Yeah, I think most of these bugs I'm finding have already been fixed since I'm on thud ;)10:02
RPwertigon: its hardcoded in Needs to be fixed by abstracting to a function and disabling on mingw, Worth opening a bug10:03
jagantekipaulbarker: I found the same issue with fstype=ext410:03
wertigonOk, I'll see if I can get a bugzilla account going :)10:03
RP(it in meta/lib/oe/ and not fixed in master)10:03
wertigonI doubt it breaks anything10:04
wertigonBut still...10:04
RPwertigon: right, its not going to harm anything but is pointless10:04
wertigonYeah, I'll open a bug in the eSDK component10:07
RPwertigon: sdk, not eSDK10:09
wertigonRP: Bugzilla only allows eSDK or eclipse plugin :P10:12
*** jaganteki <jaganteki!31cecb5c@> has quit IRC10:15
wertigonRP: Bug filed under yoctoproject as bug #1368610:16
yoctiBug minor, Undecided, ---, paul.eggleton, NEW , meta-mingw produces a symlink to host /etc/  in the x86-64_mingw32 folder10:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:16
wertigonAnd there we got it :D10:16
*** jaganteki <jaganteki!31cecb5c@> has joined #yocto10:19
wertigonAlso related: empty /var/ directory10:19
wertigon(it does contain two other empty directories)10:19
jagantekipart --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boota --active --align 4096 --size 20M --extra-space 0part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label bootb --active --align 8192 --size 20M --extra-space 010:25
jagantekiHi any work around for this partition layout. to create bootable flag.10:26
jagantekihere bootb is creating bootable but boota won't10:26
jagantekiI have tried with ext4, same behavior.10:26
*** jaganteki <jaganteki!31cecb5c@> has quit IRC10:31
*** jaganteki <jaganteki!31cecb5c@> has joined #yocto10:32
*** Bunio_FH <Bunio_FH!> has joined #yocto10:36
RPkanavin__: around? My patch from yesterday doesn't work but I have another in mind, wondering if you have a setup which can easily test?11:06
*** goliath <goliath!> has joined #yocto11:14
*** Chrusel <Chrusel!5b15581c@> has joined #yocto11:28
*** ThomasD13 <ThomasD13!> has quit IRC11:31
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:31
*** alessioigor <alessioigor!> has quit IRC11:38
kanavin__RP, yes please11:44
*** berton <berton!~berton@> has joined #yocto11:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:45
*** goliath <goliath!> has quit IRC11:47
mcfriskwhy doesn't PACKAGEGROUP_x86-64 += "bla" work, but PACKAGEGROUP_append_x86-64 += "bla" does? The first one seems to overwrite the whole PACKAGECONFIG.11:47
*** berton <berton!~berton@> has quit IRC11:47
*** berton <berton!~berton@> has joined #yocto11:48
mcfriskthe same strongswan recipe bbappend was setting a generic PACKAGEGROUP and I was moving aesni to be x86-6411:51
RPkanavin__: patch is on top of master-next and on the list11:56
kanavin__RP: testing now11:56
RPkanavin__: thanks!11:57
kanavin__RP: yes, it seems to work :)11:58
RPkanavin__: cool, thanks!12:02
RPkanavin__: your logs from yesterday put me on the track of the problem thanks!12:04
kanavin__RP, right, glad we got it contained and sorted quickly :)12:04
RPkanavin__: me too as that one is ugly on the autobuilder and causes lots of noise12:04
wertigonOk, here is a fugly workaround to the mingw x86_64 symlinks12:11
wertigonfor link in $(find x86_64-spark-mingw32-tmp/usr/ -type l); do FILE=$(readlink -f $link); rm $link; cp $FILE $link; done12:11
wertigonSorry, the path is supposed to be sysroots/x86_64-spark-ming32/usr/12:12
wertigonThen everything just works nativelty12:12
*** Chrusel <Chrusel!5b15581c@> has quit IRC12:13
*** wertigon <wertigon!8addfa13@> has quit IRC12:14
*** jaganteki <jaganteki!31cecb5c@> has quit IRC12:16
*** wertigon <wertigon!8addfa13@> has joined #yocto12:19
yoctiNew news from stackoverflow: Meson version in Yocto <>12:42
wertigonAny concrete plans about FOSDEM for the Yocto team yet?12:48
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:51
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC13:05
rburtonmcfrisk: because that's how overrides work.13:05
*** rburton <rburton!> has quit IRC13:33
*** rburton_ <rburton_!> has joined #yocto13:33
*** rburton_ <rburton_!> has quit IRC13:36
*** rburton <rburton!> has joined #yocto13:39
*** rchard2scout <rchard2scout!59cad575@wikipedia/rchard2scout> has joined #yocto13:42
GeneralStupidHi, where do i put mtd partitions in the dts file?13:53
qschulzGeneralStupid: I think U-boot can patch the device tree for you, like transparently, depending on what's in the mtdparts env variable13:54
qschulzso if anyway you need to load something from the NAND in U-Boot, use mtdparts maybe13:55
qschulzGeneralStupid: but I think that's a question you can ask on #mtd ;)13:57
GeneralStupidqschulz: i talked to LetoThe2nd yesterday and he told me that mtdparts is 2005 :)13:59
GeneralStupidi need to modify the dts anyway13:59
qschulzGeneralStupid: what's suggested in lieu of mtdparts?14:00
GeneralStupidqschulz: writing the partition table in the dts14:01
GeneralStupidbut then i need to do it twice. ... I dont know :D14:01
qschulzwhat i'm saying is that u-boot should be able to fixup your dts from what you put in mtdparts14:03
qschulzthat might be a kconfig options though14:03
qschulzso if you need it in u-boot already, use that option (if it exists)14:03
roussinmkanavin__: I have a question regarding cmake OEToolchain.cmake... This patch 7da988887c. It will not look into the native sdk sysroot, but when we invoke cmake, it find certains tools that it need, like `ar` inside the target sdk sysroot(aarch64 for us), which can't be used on native(x64_64 for us). So I'm wondering if both CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH points to the target sysroot, how cmake is14:03
roussinmsuppose to find the x86_64 version of `ar`14:04
qschulzGeneralStupid: also.. be careful because mtdparts changed last year in u-boot and `mtd` cmd is used instead so I don't know exactly how everything's handled14:04
GeneralStupidqschulz: iam using 2017.0314:04
*** rchard2scout <rchard2scout!59cad575@wikipedia/rchard2scout> has quit IRC14:06
GeneralStupidqschulz: i will call it a day. Have a nice weekend :)14:09
qschulzGeneralStupid: you too14:09
yoctiNew news from stackoverflow: How to make yocto recipe ( zeus branch ) for postgresql 9.6? <> || Building python3-psycopg2-native recipe error [ yocto ] <>14:12
JPEWRP: Ack :/ sorry about the MinGW failure14:15
RPJPEW: I nearly asked you whether I needed to stage and test that :)14:23
RPJPEW: just let me know if its an easy fix or I should revert14:24
*** ruru4143 <ruru4143!> has quit IRC14:25
kanavin__roussinm, I am not sure which patch you mean?14:32
*** AndersD <AndersD!> has quit IRC14:35
*** champagneg <champagneg!> has joined #yocto14:38
roussinmI think I figured it out, in theory cmake will use the prefix from the compiler to find the other tools like ar,nm,ranlib... but I think my IDE is changing that path somehow...14:40
kanavin__roussinm, I am not a cmake expert really, I only know as much as the commit msg says14:41
*** goliath <goliath!> has joined #yocto14:44
angelo__I am getting a "Transaction failed" error at end of the build. Some packages "Failed", but not finding much more info. How can i debug this ?14:44
angelo__ok, sry, scrolling up the log i found something useful14:45
angelo__it is "cpio: open failed - Inappropriate ioctl for device"14:46
*** khem <khem!~khem@unaffiliated/khem> has quit IRC14:52
*** hpsy <hpsy!~hpsy@> has joined #yocto14:54
*** jklare <jklare!~jklare@> has quit IRC14:56
*** jklare <jklare!~jklare@> has joined #yocto14:59
*** ericch <ericch!> has joined #yocto15:02
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto15:19
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC15:27
Ad0rust-native is brutal on RAM15:32
*** TobSnyder <TobSnyder!> has quit IRC15:33
*** fl0v0 <fl0v0!~fvo@> has joined #yocto15:35
*** goliath <goliath!> has quit IRC15:36
*** cadsys <cadsys!~cadsys@> has joined #yocto15:45
cadsysI have question in my mind15:45
cadsysIf we are making a project on linux in c++ / C , Is it beneficial if we create its yocto layer stack15:46
cadsysIs it necessary to create a yocto layered project for long run15:47
cadsysPlease anyone ans15:48
roussinmFrom us side we create a layer with our compagny name(meta-....) . Use that layer with our projects.15:50
cadsysroussinm : I mean , Is there really need of create yocto layer15:51
cadsysWhat are the benefits of yocto over a simple standard application or makefile project15:52
*** diego_r <diego_r!~diego@> has quit IRC15:55
bojonesHello. I have a package which is basically just a kernel module and a shared library. Another package (the main application) is depending on the package (well, actually just the header files). My problem is, if the kernel is rebuilt, the kernel module is rebuilt and hence my main application is rebuilt. Can this be fixed? I'm probably doing something wrong..15:55
*** lexano <lexano!> has joined #yocto15:56
*** frsc <frsc!> has quit IRC15:56
qschulzcadsys: Yocto is a build system. It uses cmake, meson, ninja, make, autootls, whatever to compile the application. So do that first and try to not ignore variables coming by parameters so that people can easily cross-compile without patching your stuff15:57
qschulzbojones: separate the kernel-module recipe from the other stuff so that you depend only on the other stuff recipe15:59
bojonesqschulz: But the problem is, the main application depends on the shared library, which depends on the kernel module16:00
bojonesBut since the interface to the kernel module and the shared library doesn't change, it shouldn't be necessary to rebuild the application16:01
qschulzbojones: how is Yocto supposed to know that?16:02
*** lfa <lfa!~lfa@> has quit IRC16:02
bojonesqschulz: It's not supposed to know that - but maybe I could help it.. thats my question. My thought was something like, the main application was only depending on the header files for the shared library. The shared library was only depending on the header files of the kernel module.16:07
rburtonJPEW: got a do_install postfunc to hopefully clean up the pod2man versions16:07
bojonesBut I don't know if this is something that your can do in Yocto..16:07
*** hpsy <hpsy!~hpsy@> has quit IRC16:08
JPEWrburton: Ah, excellent. I got sidetracked from asking about getting that finished up16:08
rburtonJPEW: all new implementation, literally just look in every man page for the bad string and rip it out16:08
JPEWrburton: Ya, I think that makes sense and is probably a lot simpler to maintain16:09
rburtonbojones: the library doesn't depend on the kernel module at build time though right16:09
rburtonif you've really got new kernel headers then just split up the recipes a bit so you build the kernel module entirely separately16:10
bojonesrburton: no. But it depends on the header files from the kernel module.16:10
rburtonJPEW: ross/pod2 if you want to heckle16:11
rburtonbuild of sato running now to check nothing else breaks16:11
cadsysqschulz : Hi thank you but my question is , Is that good to make yocto project rather than a cmake project ?16:11
cadsysRight now I create a cmake project16:11
JPEWRP: Odd, nativesdk-wayland isn't detecting libxml2 on the AB. Of course, I can't reproduce that locally :(16:12
cadsysbut someone told me yocto is a build tool which are used by multiple companies16:12
cadsysYou also need to use it16:12
rburtoncadsys: different scopes: cmake can't build an entire system, and a yocto recipe on its own doesn't build source code16:12
armpitWas systemd intended to be used in e/SDK ? there is no natvivesdk package16:13
cadsysrburton : can I explain everything which I want ?16:13
rburtonarmpit: why would you need nativedk-systemd?16:13
cadsysI have a lakhs lines of project which is developed in c/c++ but it was running only on windows and it is simple standard application16:14
cadsysBut recently we compiled it for linux by help of cmake tool16:14
cadsysWe also want to make it standalone application of linux , So we need to configure our linux os as per application requirement16:15
cadsysSo in that scenario how yocto is perfect ?16:16
cadsysI mean we need to use yocto or not ?16:16
cadsysanyone suggest me please16:20
JPEWcadsys: If you want to build a complete Linux system that includes your application, you can use Yocto16:20
qschulzbojones: I think the point of rburton was to have a recipe only with this header. Then another one for the kernel-module which depends on the header recipe. Then another one for your application which dpeend on the header recipe.16:21
cadsysJPEW : I mean is it seriously beneficial because it will required great effort to import whole project on yocto thats why I want to confirm first16:22
qschulzcadsys: "We also want to make it standalone application of linux , So we need to configure our linux os as per application requirement" this isn't explicit enough for context. I didn't understand exactly what you wanted16:23
armpitrburton, I need libsystemd for a package I want to add to the sdk16:24
JPEWcadsys: What do you run on today? An embedded device? What OS (e.g. Ubuntu, Fedora)?16:24
cadsysqschulz : I mean we will remove extra drivers or application which we not required for application16:25
*** WillMiles <WillMiles!> has joined #yocto16:25
armpitWillMiles, nice domain.. so you brought us all the rain : )16:26
bojonesqschulz: Ahh ok, that makes sense. But can you have it in a single .bb file?16:27
rburtonarmpit: a nativesdk tool in the sdk?16:28
*** roussinm <roussinm!> has quit IRC16:28
WillMilesarmpit: Yup, they're a small local ISP.  If you've got rain I'm envious - it's all snow up here today16:29
armpitrburton, I want to add python-systmed to the sdk16:29
armpitrburton, once I get the python-systemd sorted to support nativesdk, and add it to TOOLCHAIN_HOST_TASK_append =  it failes with missing libsystemd16:32
*** champagneg <champagneg!> has quit IRC16:32
rburtonarmpit: still curious how that is useful in the nativesdk context :)16:32
rburtonbut if thats what you really want then you'll most likely want a minimal packageconfig_class-nativesdk override16:33
bojones.. the headers and the library I mean16:36
*** Bunio_FH <Bunio_FH!> has quit IRC16:38
armpitrburton, if I want a 3rd party  to develop systemd  apps or tweek systemd configs , isn't that a usecase for an e/SDK ?16:41
qschulzbojones: if your lib does not depend on anything else but the header (wrt kernel module), should be doable indeed16:42
bojonesqschulz: neither the kernel module or the shared library "ever" changes.. So the header files are "static"..16:44
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:45
*** FailDev <FailDev!18d83107@> has joined #yocto16:48
qschulzbut the header is the same file for both, and I don't like duplicates personally :)16:57
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:02
rburtonarmpit: no, they'd use the target systemd in the sysroot17:02
rburtonarmpit: nativesdk is stuff the user can *run* in the sdk17:03
RPkanavin__: those gettext changes really don't like existing build directories do they? :/17:04
kanavin__RP, probably not, I've had them in my tree for such a long time that I don't remember how it was when transitioning from previous version17:05
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:05
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:05
RPkanavin__: I just cleared stuff out but we need to keep it in mind when they merge I guess17:06
*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-vrxobbleezmitueb> has joined #yocto17:09
*** guerinoni <guerinoni!> has quit IRC17:17
*** vineela <vineela!~vtummala@> has joined #yocto17:21
armpitrburton, I thought I could use the esdk to build a systemd service then send it to the target to run and debug17:22
*** mckoan is now known as mckoan|away17:23
armpitan esdk contains all the headers and libs needed to support such an task17:23
* armpit is what is my understanding17:23
rburtonarmpit: right, but they're all class-target17:25
rburtonnativesdk is the pieces that you can run in the sdk itself17:25
* armpit breaks out his Yocto pre-school set to do some more learning17:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:39
*** lucaceresoli <lucaceresoli!> has quit IRC18:00
*** leon-anavi <leon-anavi!~Leon@> has quit IRC18:15
*** Bunio_FH <Bunio_FH!> has joined #yocto18:20
*** palate <palate!~palate@unaffiliated/palate> has quit IRC18:31
*** hpsy <hpsy!~hpsy@> has joined #yocto18:36
*** hpsy <hpsy!~hpsy@> has quit IRC18:41
*** hpsy <hpsy!~hpsy@> has joined #yocto18:42
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto18:50
moosnatHi, I just upgraded a Yocto-based build from rocko to thud, and I'm experiencing a huge performance loss in the parsing stage: on rocko it parsed recipes in a matter of seconds, now it takes 15 minutes. Is there a way I can profile this?18:51
Ad0there are different layers for different boards, only one of them can be used at a time, I already have separate image build files but maybe I have to sort this out on a distro level?18:59
Ad0make a distro per board, and use BBMASK to exclude other board's layers?19:06
*** Bunio_FH <Bunio_FH!> has quit IRC19:07
*** pohly <pohly!> has quit IRC19:55
*** FailDev <FailDev!18d83107@> has quit IRC20:41
moto-timozeddii: has anybody sent a patch for meta-virtualization/recipes-extended/images/ Could not inherit file classes/features_check.bbclass20:44
moto-timozeddii: oh wait, maybe my poky is out of sync ... now that I read it again20:45
JPEWRP: + master-next of meta-mingw should fix the build errors20:45
*** wertigon <wertigon!8addfa13@> has quit IRC20:45
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC21:01
*** ericch <ericch!> has quit IRC21:01
*** goliath <goliath!> has joined #yocto21:03
*** ericch <ericch!> has joined #yocto21:03
*** berton <berton!~berton@> has quit IRC21:04
moto-timoJPEW: have you ever used buildah? wondering if it is faster than podman build21:05
JPEWpodman build uses buildah for the backedn21:05
JPEWI don't recommend invoking them independently, it's easy to get things very confused :)21:06
moto-timonoted :)21:06
moto-timoseems like avoiding docker-engine on CI is a good thing though :)21:06
JPEWYa. The problem we ran into is that podman build is *so* slow with the vfs driver our TravisCI job would timeout21:07
JPEWThe best compromise I've found is to build images in docker + buildkit, then import to podman using 'podman pull docker-daemon:IMAGE'21:08
JPEWmoto-timo: This script will do that for you:
moto-timoJPEW: what do you do about registry? do you run a local podman registry? or is that not even a thing...21:10
JPEWmoto-timo: Sorry, here's a better one:
moto-timoand thanks for the script21:10
*** tgamblin <tgamblin!~tgamblin@> has quit IRC21:10
JPEWpodman's registry is just a bunch of files in ~/.local/share/containers21:11
moto-timoJPEW: oh right, I read that somewhere already.21:11
JPEWmoto-timo: FWIW, the podman build time is more bearable with the fuse-overlay driver; I just haven't found a new enough version that works to build on Ubuntu 18.0421:15
moto-timoJPEW: probably better support on Fedora, given the RedHat origins?21:16
JPEWmoto-timo: Yep. I've been pretty happy with it.21:17
moto-timoJPEW: other than the brain shift from Docker, seems very promising21:17
JPEWmoto-timo: Ya, I hope it sticks around. They've put a lot of effort into make it work the same way as docker21:18
*** rcw <rcw!~rcw@> has joined #yocto21:19
JPEWMost of the bugs I've found have been in regard to differences in how it deals with our convoluted Dockerfiles, which is to be expected given its a clean implementation21:19
moto-timoWe've done some nasty things in Dockerfiles too21:20
JPEWWell, FWIW, podman can run the C-preprocess on Dockerfiles before it builds them... which seems like a double edged sword :)21:20
JPEWC preprocessor21:20
*** roussinm <roussinm!> has joined #yocto21:20
JPEWWe don't use that feature b/c we want to also be able to build them in Docker21:21
*** guerinoni <guerinoni!~guerinoni@> has joined #yocto21:26
*** WillMiles <WillMiles!> has quit IRC21:31
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC21:45
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto21:45
*** rburton <rburton!> has quit IRC21:58
*** rcw <rcw!~rcw@> has quit IRC21:59
*** guerinoni <guerinoni!~guerinoni@> has quit IRC22:19
roussinmI would like to remove gcc from the target sysroot in the sdk, because we don't need a aarch64 gcc, we only want the one that is inside the x86 that generates aarch64 binaries.22:27
roussinmWe tried removing packagegroup-cross-canadian-${MACHINE} from the TOOLCHAIN_HOST_TASK, but then we only get the gcc aarch64.22:28
*** agust <agust!> has quit IRC22:39
RProussinm: cross-canadian *is* the x86 gcc that generates aarch64 binaries. "gcc" is the target gcc22:45
roussinmOh, right we just figured that, we were looking at the wrong variable. But still remain, how to remove gcc binairy from the aarch64 sysroot.22:47
roussinmOr it shouldn't be installed by default and we are doing something funky that does that.22:48
RProussinm: I'm slightly surprised its there22:54
roussinmOk that's why I thought too, it's probably because of the meta-clang layer actually...22:54
roussinmI'm trying a build without the meta-clang layer right now and see if gcc reside inside the aarch64 sysroot.22:55
roussinmkhem: maybe you know something about this?22:56
*** roussinm <roussinm!> has quit IRC22:56
*** hpsy <hpsy!~hpsy@> has quit IRC22:57
*** vineela <vineela!~vtummala@> has quit IRC23:03
*** vineela <vineela!~vtummala@> has joined #yocto23:04
*** vineela <vineela!~vtummala@> has quit IRC23:08
*** ericch <ericch!> has quit IRC23:10
*** roussinm <roussinm!> has joined #yocto23:43
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC23:45

Generated by 2.11.0 by Marius Gedminas - find it at!