Monday, 2019-12-02

*** kaspter <kaspter!~Instantbi@> has quit IRC00:26
*** goliath <goliath!> has quit IRC00:27
*** kaspter <kaspter!~Instantbi@> has joined #yocto00:27
*** kaspter <kaspter!~Instantbi@> has quit IRC01:16
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:16
*** DvorkinDmitry <DvorkinDmitry!> has quit IRC01:17
*** DvorkinDmitry <DvorkinDmitry!> has joined #yocto01:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC01:38
*** kaspter <kaspter!~Instantbi@> has quit IRC01:42
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:43
*** tgamblin <tgamblin!> has joined #yocto01:48
*** camus <camus!~Instantbi@> has joined #yocto01:58
*** kaspter <kaspter!~Instantbi@> has quit IRC01:59
*** camus is now known as kaspter01:59
*** kaspter <kaspter!~Instantbi@> has quit IRC02:28
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:31
*** camus <camus!~Instantbi@> has joined #yocto03:16
*** kaspter <kaspter!~Instantbi@> has quit IRC03:17
*** camus is now known as kaspter03:17
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto03:42
*** tgamblin <tgamblin!> has quit IRC03:47
*** armpit <armpit!~armpit@> has joined #yocto04:43
*** kaspter <kaspter!~Instantbi@> has quit IRC04:46
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:46
*** kaspter <kaspter!~Instantbi@> has quit IRC05:28
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:28
*** khem <khem!~khem@unaffiliated/khem> has quit IRC05:40
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto05:41
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto05:46
*** xtron <xtron!~xtron@> has joined #yocto06:16
*** ThomasD13 <ThomasD13!> has joined #yocto06:23
*** pohly <pohly!> has joined #yocto06:24
*** armpit <armpit!~armpit@> has quit IRC06:28
xtronincluded selinux in distro_features then removed it, now getting dbus, iproute do_package_qa error "iproute2-ss requires ..." seeing that kinda build chain issues in package-management and systemd/syvinit, using yocto zeus, anyone else?06:30
*** AndersD <AndersD!> has joined #yocto06:45
*** agust <agust!> has joined #yocto06:51
*** guerinoni <guerinoni!> has joined #yocto07:04
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:08
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC07:11
*** goliath <goliath!> has joined #yocto07:12
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto07:29
*** TobSnyder <TobSnyder!> has joined #yocto07:41
*** wertigon <wertigon!8addfa13@> has joined #yocto07:42
wertigonUgggh... Stuck between a rock and a hard place now -_-;; So meta-mingw[thud] works if I temporarily remove meta-clang and meta-browser from my build. Two problems arise however;07:43
wertigon1. meta-clang bumps gcc crosscompiler version to 8.207:44
wertigon(from 7.3)07:45
wertigon2. Requires some fugly hacks that I have mostly scripted up right now07:45
wertigonIf I can get meta-mingw to also bump up compiler version to 8.2 I should be home07:46
wertigonUgly solution that needs to be prettied up, but home07:47
wertigonHmm, correction, seems to perhaps be meta-browser that is the culprit here07:49
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:57
*** alessioigor <alessioigor!> has joined #yocto07:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:01
*** yann <yann!> has quit IRC08:23
*** jmiehe <jmiehe!> has joined #yocto08:24
*** rburton <rburton!> has joined #yocto08:31
*** goliath <goliath!> has quit IRC08:33
*** mckoan|away is now known as mckoan08:55
*** yann <yann!~yann@> has joined #yocto09:24
*** goliath <goliath!~goliath@> has joined #yocto09:26
*** farnerup <farnerup!> has joined #yocto09:26
wertigonIs there a way to force meta-mingw to use and build the same compiler poky use?09:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:34
rburtonwertigon: by default it does use the same one, so i presume the problem is that meta-clang is overriding the cross compiler but not the sdk compiler09:43
yoctiNew news from stackoverflow: Yocto, Meta-selinux does not work on raspberry pi 3 <>09:55
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto09:58
GeneralStupidHow does UBBOOT_CONFIG work? i created my own uboot config but iam not able to compile it in yocto (but it works in plain uboot). I always get Can't find default configuration "arch/../configs/......defconfig"!09:58
qschulzGeneralStupid: where is your defconfig in plain u-boot? what's its name? what's the exact error?10:04
*** diego_r <diego_r!> has joined #yocto10:16
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto10:23
yoctiNew news from stackoverflow: How I run qemu in yocto with movbe CPU feature? <>10:25
*** diego_r <diego_r!> has quit IRC10:28
*** diego_r <diego_r!> has joined #yocto10:28
*** hpsy <hpsy!~hpsy@> has joined #yocto10:30
*** lucaceresoli <lucaceresoli!> has joined #yocto10:34
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC10:46
*** JaMa <JaMa!~martin@> has joined #yocto10:46
wertigonrburton: if I remove meta-clang I get version 7.3 (which is my native version)10:53
wertigonif I add meta-browser and meta-clang I get 8.210:53
wertigonIn poky[thud]/meta/recipes-devtools/gcc/ I find gcc_7.3 and gcc_8.210:58
rburtonso blame meta-clang and its toolchain switching10:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:08
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto11:17
rburtonRP: hm one of the master selftest runs hung in drm/virtio stuff11:17
rburtonpaging kanavin_
kanavin_rburton, looking11:18
rburtona few fails in there11:18
RPrburton: just what we need, more intermittent failures. We should perhaps rerun it on that worker assuming kanavin_ doesn't need logs11:22
wertigonrburton: Ah, I finally see what happens here... meta-browser is the only package that bumps up the version to 8.2, so by removing it the version drops to 7.311:23
kanavin_rburton, RP that failure is probably specific to opensuse 15.011:23
wertigonSo, the default gcc is 7.3 and we do not change it11:23
kanavin_so I could add one more distro exception to the test11:23
wertigonOff to check which option I need to change to force version 8.2 in my image :)11:24
rburtoni'll refire it to see if it happens on demand11:39
kanavin_rburton, new python ptests need headers in /usr/include, but adding -dev to RDEPENDS of -ptests makes package_qa complain11:40
rburtonfired on suse 150 and 15111:40
RPrburton: thanks11:40
RPkanavin_: can't we disable that hint for that package?11:41
rburtonkanavin_: insane-skip for ptest package11:41
kanavin_ah! I didn't realize insane_skip can be package specific?11:41
kanavin_I thought it's for entire recipe :-/11:41
*** berton <berton!~berton@> has joined #yocto11:44
*** berton <berton!~berton@> has quit IRC11:45
*** berton <berton!~berton@> has joined #yocto11:47
*** jklare <jklare!~jklare@> has quit IRC11:59
*** jklare <jklare!~jklare@> has joined #yocto12:00
wertigonUgh, why isn't this cooperating...12:04
wertigonSo I try setting PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} to 8.212:04
wertigonAnd then I get12:05
wertigonERROR: gcc-runtime-7.3.0-r0 do_configure: Function failed: do_configure12:05
*** Crofton|work <Crofton|work!~Crofton@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC12:05
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC12:05
*** learningc <learningc!~pi@> has joined #yocto12:07
rburtonwertigon: i guess you need to set everything to the same version12:18
rburtonthere's a variable for that, GCCVERSION12:18
wertigonGCCVERSION does nothing if I set it in the command line12:18
wertigonBut I'll try local.conf12:19
rburtonyeah its not an envrionment var12:19
rburtonvery few environment variables pass into the bitbake context12:19
wertigonDoes SDKMACHINE pass into it?12:19
wertigonI know MACHINE works atleast12:20
wertigonSee, I know the solution is easy it12:20
wertigonit's just a matter of finding where to define it :P12:21
rburtondid you isolate the problem to just meta-clang12:25
wertigonHmm, to meta-browser, yes.12:25
rburtonwhat does meta-browser have to do with compiler version used12:25
wertigonmeta-clang included - sdkgcc = 7.312:25
wertigonmeta-browser (and meta-clang) - sdkgcc = 8.212:26
rburtonwell, drop meta-browser and verify its just meta-clang12:26
wertigonI did12:26
wertigonIt's meta-browser that changes stuff, not meta clang12:26
wertigonOr it might be meta-browser+meta-clang12:28
rburtonwell browser depends on clang12:28
rburtonbut clang is the one that pokes at the toolchain selection12:28
rburtonthus my suggestion that its not meta-browser at all12:29
rburtonwhat branches are you using?12:29
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:29
wertigonthud branches12:29
wertigonSince ti is not compatible with anything more recent... yet12:29
wertigonWe've just taken the decision to try and move away from arago though12:30
wertigonso we'll just have meta-processor-sdk and meta-ti in the future12:30
kanavin_rburton, 15.0 failed in the same way. Waiting for the verdict from 15.112:30
wertigonAha, here is something! :)12:30
wertigonIn conf/distro/include/toolchain.gcc I have SDKGCC version set to 7.3%12:31
wertigonThrough ?= ofc12:31
wertigonrburton: The biggest problem I have right now is that mingw and clang isn't compatible in thud12:32
wertigonHowever, I also do not need clang in my SDK files12:33
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto12:40
wertigonrburton: Out of interest, are clang and mingw compatible in zeus?12:41
rburton never tried12:42
rburtonon my todo list for a long time has been to merge the toolchain selection thing into core itself12:42
rburtonas meta-iss has a clone of the clang's toolchain switching class too12:42
wertigonOk, I'll try the default Yocto layers a little bit later then :)12:43
wertigonrburton: I have isolated the mingw/clang issues in thud btw in stock poky12:44
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC12:45
rburtonif you've an easy reproducer involving those layers and nothing else please do replicate with master and file a bug12:47
wertigonjust add meta-mingw, meta-clang and meta-openembedded to your bblayers.conf, change branches to thud and try to build the SDK with SDKMACHINE=x86_64-mingw32 bitbake <image>12:47
wertigonsorry, bitbake meta-toolchain12:47
wertigonAnd things should explode rather spectacularly :)12:47
wertigonrburton: Where to file the bug?12:48
rburtonwertigon: i'd say to start, if its all khem's fault we can let him keep it there or move somewhere else12:50
wertigonThanks ^^ b12:51
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto12:52
ThomasD13Hey, I would like to work on the actual kernel code of my linux image. This kernel contains already a set of patches and config fragments. Does Yocto provide a build step which applies all patches on the kernel source code and provide the final .config?12:56
ThomasD13I would like to have a folder which I can just run "make ..." to build the kernel and modules with the correct (patched) sourcecode and .config12:57
rburtonok who broke my branch12:58
rburton| ./boost/python/detail/wrap_python.hpp:57:11: fatal error: pyconfig.h: No such file or directory13:00
rburton|    57 | # include <pyconfig.h>13:00
rburton|       |           ^~~~~~~~~~~~13:00
ThomasD13According to the OpenEmbedded Build Sytem Workflow, "Patch Application" and "Config/Compile/Autoconf" sounds good. But how to "intercept and extract" the source files from yocto build process13:00
rburtonchecking whether to use python... /home/pokybuild/yocto-worker/edgerouter/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gdb-cross-canadian-mips64/8.3.1-r0/python13:00
rburtonchecking for python3.8... no13:00
rburtonconfigure: error: no usable python found at /home/pokybuild/yocto-worker/edgerouter/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gdb-cross-canadian-mips64/8.3.1-r0/python13:00
rburtoni wonder if thats the abi thing13:01
*** guerinoni <guerinoni!> has quit IRC13:03
ThomasD13wertigon, why do you move away from aragon?13:08
cengiz_iohello. will adding `dbg-pkgs` to EXTRA_IMAGE_FEATURES provide a glibc with debug symbols to my distro?13:31
cengiz_ioI need to cpuprofile an app and since there are no symbols in my glibc, gperftools blames strange functions like gnu_get_libc_version13:32
LetoThe2ndcengiz_io: should, yes.13:34
LetoThe2ndcengiz_io: but be aware that the size change can be dramatic13:34
cengiz_ioLetoThe2nd thanks. also the complete rebuild will be automatic right? (probably take x4 times long..)13:37
LetoThe2ndcengiz_io: yes, and no. :13:38
*** xtron <xtron!~xtron@> has quit IRC13:41
rburtonkanavin_: fwiw, has PYTHON_BINABI variable that isn't used13:44
*** Hauke <Hauke!> has quit IRC13:48
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC14:02
*** AndersD <AndersD!> has quit IRC14:04
rburtonRP: nativesdk recipe looking for linux/capability.h is failing.  native works as it looks on build host. why wouldn't nativesdk do the same?14:14
rburtonor why wouldn't it be pulling nativesdk-libc-headers into the build ?14:16
kergothi doubt it would be possible to build the crosssdk toolchain at all without linux-libc-headers, no? hmm14:18
rburtonoh idiot boy, i'm sitting in mingw14:18
rburtonshocking lack of linux headers in a mingw sdk ;)14:18
LetoThe2ndrburton: not it a pub?14:19
* LetoThe2nd confirms the "idiot boy", then.14:19
rburtonmaybe overloading a single build dir isnot sensible14:19
kanavin_rburton, I fixed the "m" thing, will drop the PYTHON_BINABI as well and confirm that boost is still ok14:22
rburtonkanavin_: i wonder if its worth adding a selftest to verify that python3native  is doing the right thing so we get a proper error like 'cannot find library, check PYTHON_ABI etc" instead of some recipes failing14:23
rburtonkhem: RRECOMMENDS_${PN} += "${@'libcxx-dev libcxx-staticdev compiler-rt-dev compiler-rt-staticdev' if '${CLANGSDK}' else ''}" doesn't do what you think14:24
rburtonbool("0") -> True14:24
rburtonwertigon: probably fixed your problem14:28
rburtonsolution is in fact in the readme14:29
RPrburton: I was scratching my head like kergoth until you mentioned mingw :)14:34
rburtonwertigon: first fix is on the house.  CLANGSDK="" in your local.conf.14:35
cengiz_ioLetoThe2nd adding dbg-pkg to extra features seems to build so quick that I'm not sure it did the right thing14:35
cengiz_iowill check now14:35
cengiz_ioperhaps I need to add DEBUG_BUILD = "1" as well?14:37
wertigonrburton: Thanks, I have also submitted a bug report in the clang github14:39
wertigonWill try it now :)14:39
wertigonrburton: I have managed to figure out exactly where we set the compiler options and everything now, as well14:41
wertigonSo, I might actually have this one bagged now :)14:42
wertigonThank you so much for the help!14:43
wertigonHmm, CLANGSDK="" did nothing for me :(14:46
wertigonBut no worries, I can run without CLANG until done14:46
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto14:49
*** AndersD <AndersD!> has joined #yocto14:51
*** diego_r <diego_r!> has quit IRC14:53
rburtonkanavin_: <-- libdnf failing (ross/next)14:54
rburton(centos 7, have fun)14:55
* rburton runs to get the kids14:55
wertigonGoing home too, thanks for the help!14:58
kanavin_rburton, that does look old gcc failure :(15:00
kanavin_are we planning to retire centos 7 in favor of centos 8?15:00
RPkanavin_: eventually, yes. We're not there yet15:01
kanavin_RP: then libdnf/dnf updates have to be deferred15:02
RPkanavin_: is this a C++ issue? (I've not looked at the failure)15:02
kanavin_RP: /home/pokybuild/yocto-worker/buildtools/build/build/tmp/hosttools/g++  -DLIBDNF_UNSTABLE_API -D_FILE_OFFSET_BITS=64 -Dlibdnf_EXPORTS -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/gio-unix-2.0 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../.15:03
kanavin_./usr/include -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/libmount -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/blkid -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-15:03
kanavin_sysroot-native/usr/lib/pkgconfig/../../../usr/include/glib-2.0 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/lib/glib-2.0/include -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/json-c -I/home/pokybuild/yocto-worker/buildtools/build/build15:03
kanavin_/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/libxml2 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/utils -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/transactio15:03
kanavin_n -isystem/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/include -O2 -pipe -std=c++11 -Wmissing-declarations -fPIC   -DPACKAGE_VERSION=\"0.38.1\" -DGETTEXT_DOMAIN=\"libdnf\" -DG_LOG_DOMAIN=\"libdnf\" -DTESTDATADIR=\"/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/data/tests\" -Wcast-align -Wno-uninitialized -Wredundant-decls15:03
kanavin_-Wwrite-strings -Wformat-nonliteral -Wmissing-format-attribute -Wsign-compare -Wtype-limits -Wuninitialized -Wall -Wl,--as-needed -MD -MT libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o -MF libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o.d -o libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o -c /home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/dnf-context.cpp15:03
kanavin_ static std::atomic_flag cfgMainLoaded = ATOMIC_FLAG_INIT;15:03
kanavin_        ^15:03
kanavin_oops sorry!15:03
kanavin_let's try again15:03
kanavin_ static std::atomic_flag cfgMainLoaded = ATOMIC_FLAG_INIT;15:04
kanavin_        ^15:04
kanavin_error: ‘atomic_flag’ in namespace ‘std’ does not name a type15:04
kanavin_seems like a C++ issue indeed, I don't get this on ubuntu 18.0415:04
*** hpsy <hpsy!~hpsy@> has quit IRC15:06
*** AndersD <AndersD!> has quit IRC15:07
RPkanavin_: That I think is C++11 which I guess centos7 isn't15:07
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC15:08
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto15:09
kanavin_RP, right, so I'll take out the libdnf upgrade from the set, and move them to a 'later' branch of mine15:09
tgamblinRP: Think I've figured out at least part of that selftest skip count bug15:11
RPkanavin_: would be good to know where debian8 stands too15:12
tgamblinattempting to import cairo in setUpClass and raising the exception if it can't be imported is causing it to count a single skip for the entire class15:12
RPtgamblin: ah, sounds good :)15:12
RPtgamblin: right, that isn't really correct though15:13
tgamblinRight. Just moving the try/except into each of the test functions makes it count correctly15:13
tgamblinIt's a little ugly, though15:14
RPtgamblin: can we fix the class handling?15:14
RPkanavin_: debian8 is gcc 4.9.2 FWIW (centos7 is 4.8.5)15:14
tgamblinPossibly. I found another project that saw a similar issue and fixed it, I'm looking at their patch to see what was done15:14
RPtgamblin: I agree we could just move it but that opens up the problem to happen again in future15:15
kanavin_RP, right, I can't easily test that though15:16
RPkanavin_: we could run ross/next specifically on that worker?15:17
tgamblinRP: Alright. I'll keep looking into the related UNKNOWN results issue and see if there's a way to do the skip fix more cleanly15:17
*** ericch <ericch!> has joined #yocto15:17
kanavin_RP: yes please15:17
RPkanavin_: trying, although I worry it will pull libdnf-native from sstate15:18
RPkanavin_: may need to add a PR bump to the brach I guess15:18
RPtgamblin: I suspect if you move the skip to the test, the UNKNOWN issue is fixed too. I would like to fix the underlying problem if possible though15:18
*** elGamal <elGamal!> has quit IRC15:19
*** elGamal <elGamal!> has joined #yocto15:19
RPkanavin_: we're in luck, its building it15:20
RPkanavin_: blew up :(15:21
kanavin_RP: right. I believe Debian 8 is supported until mid-202015:22
*** Bunio_FH <Bunio_FH!> has joined #yocto15:22
RPkanavin_: right :/. Just ensuring we know what gates libdnf I guess15:23
*** goliath <goliath!~goliath@> has quit IRC15:24
kanavin_RP: yep, sometimes I wish we would not rely on the host gcc :-/15:25
RPkanavin_: hard not to. We could go "selfhosted" if we mandated people use our own buildtools tarball...15:26
RPwe'd need a gcc-nativesdk recipe too15:27
*** Bunio_FH <Bunio_FH!> has quit IRC15:27
*** champagneg <champagneg!> has joined #yocto15:27
kanavin_RP: but would it be crazy to build gcc-native in addition to gcc-cross?15:27
kanavin_e.g. use the host gcc only for build gcc itself15:27
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:28
*** jwessel <jwessel!~jwessel@> has joined #yocto15:30
*** ThomasD13 <ThomasD13!> has quit IRC15:30
RPkanavin_: not crazy, just adds significantly to the build time15:32
kergothi'd rather just build in docker than use gcc-native, personally.. could even use a yocto-built docker image to self-host if we really wanted to..15:34
* kergoth shrugs15:34
kanavin_kergoth, this still doesn't solve the problem of having to hold back version updates because those updates don't work with 5 year old compilers15:36
kergothi don't see the issue with updating the host, particularly if that host is a controlled container, unless you're under tight constraints due to needing to deal with compliance requirements15:38
*** Bunio_FH <Bunio_FH!> has joined #yocto15:41
kanavin_kergoth, what I mean is that we now have to hold back version upgrades in oe-core master because of a continuing need to support older distributions.15:41
RPkergoth: having OE/Yocto "run anywhere" on distros is one of our valuable features, for better or worse15:41
*** stephano <stephano!> has joined #yocto15:41
RPyes, you can use containers or other solutions but it would make the project less attractive to people :/15:42
*** TobSnyder <TobSnyder!> has quit IRC15:43
RPits a balancing act and a tough one at times :(15:43
*** armpit <armpit!~armpit@> has joined #yocto15:45
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto15:45
mcfriskcontainers have been and are mandatory to assure reproducible builds. I can't imagine working without one, or rolling out the build setup for developers with full freedom to use random distros and versions of SW.15:49
mcfriskit was especially important when host contamination was a bigger problem, e.g. before recipe specific sysroots15:50
kergothfair enough. i do think if container use is sufficiently transparent it's almost a non-issue other than the additional requirement for podman or docker on the host. use of pyrex or equivalent means i almost never have to care that it's in a container, except i don't have to clutter up my host with unnecessary installed oe-core dependencies15:51
* kergoth shrugs15:51
Ad0what's the diff between warrior and warrior-next?15:51
kergoththe latter is where changes sit while being tested before merged to the former, generally..15:51
Ad0thanks !15:51
JPEWkergoth: Speaking of Pyrex, I have some changes I'm trying out... Since you're the only known user outside of my company, would you like to give some input?15:52
Ad0and is bitbake totally independent of, say, warrior? should I always be on latest or something :)15:52
kergothJPEW: ha, sure :)15:53
Ad0on openembedded-core15:53
kergothAd0: bitbake does need to match up with the layers, at least a certain release branch/tag is needed for a given yocto release, but the branch naming is different unfortunately. this was discussed recently by the TSC and will be improved15:53
Ad0ok! I just saw something related to "warrior" in tags for bitbake so I wound back to warrior-21.0.2 (3e61d700a05d2e0f68de3b37ab6d4005a5d07620)15:54
*** hpsy <hpsy!~hpsy@> has joined #yocto15:55
*** berton <berton!~berton@> has quit IRC15:58
*** berton <berton!~berton@> has joined #yocto15:59
*** berton <berton!~berton@> has quit IRC16:01
moto-timoANNOUNEMENT: meta-python2 is live
LetoThe2ndmoto-timo: is this like a "celebrate!" announcement, or a "quick, ran and find cover!" one? :-)16:02
frayit's a celebration that we all have to find cover16:02
tgamblinexciting news!16:03
*** goliath <goliath!> has joined #yocto16:03
LetoThe2ndfray: ah. thanks for explaining.16:04
rburtonmoto-timo: i admire your dedication to history preserving, i'd have totally just copied/pasted :)16:04
rburtonmoto-timo: <-- i see pipfiles16:05
rburtonmoto-timo: also believe it should dynamic-layers the meta-oe-needing bits out16:06
kergothmoto-timo: congrats! nicely done16:06
kergothagreed, dynamic-layers would be good16:07
LetoThe2ndmoto-timo: besides me being annoying, thanks for all the effort :)16:08
kergothi'm guessing the pipfiles were to ease use of kas to manually run the same tests as are configured in the gitlab ci configuration, but i doubt either will be used while it's on :)16:09
kergothstill, up to him how he wants to maintain the thing, workflow wise16:09
kanavin_moto-timo, \0/16:10
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC16:11
*** comptroller <comptroller!> has joined #yocto16:11
*** alessioigor <alessioigor!> has quit IRC16:11
*** alessioigor <alessioigor!> has joined #yocto16:12
RPmoto-timo: nice! :)16:17
*** berton <berton!~berton@> has joined #yocto16:17
*** goliath <goliath!> has quit IRC16:21
kergothJPEW: where should i look for the changes, have a branch?16:21
JPEWkergoth: I'm finishing them up now, but they'll be in the "next" branch16:22
*** berton <berton!~berton@> has quit IRC16:26
*** berton <berton!~berton@> has joined #yocto16:27
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC16:29
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto16:31
RP is an autobuilder failure where "oe-selftest -r signing.LockedSignatures.test_locked_signatures" fails16:34
RPCan anyone look at that test and tell me how this mode of failure is possible :/16:34
stephanomoto-timo: shiney :)16:34
RPIt adds a bbappens, reruns the build and the sig still matches16:34
RPstephano: nice to see you're still around :)16:34
rburtonhey stephano!16:40
stephanoRP: nice to be seen!16:40
rburtonaccidentally join did you?16:40
stephanorburton: howdy partner!16:40
stephanoI have to live up to all that "ping me on IRC" hype I preach at events. :-D16:41
fullstopWith systemd init how does one configure the network?  A lot of targets require network and the system hangs until I plug an ethernet cable in and obtain a dhcp lease.  I'd like to set it to a fixed address.16:43
rburtonfullstop: either use the traditional ifupdown configuration files (same as debian), or systemd-networkd16:43
fullstoprburton: thanks!16:45
fullstopso systemd will use ifupdown if they are there?16:45
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC16:46
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto16:47
JPEWRP: Huh, weird. It did reparse16:47
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC16:48
*** goliath <goliath!> has joined #yocto16:51
*** diego_r <diego_r!~diego@> has joined #yocto16:52
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto16:53
RPJPEW: yes. I don't understand :(16:59
RPJPEW: hashequiv was active16:59
*** farnerup <farnerup!> has quit IRC16:59
*** guerinoni <guerinoni!> has joined #yocto17:03
JPEWHmm, ya hashequiv could cause that if the target hash was in the database17:06
*** hpsy <hpsy!~hpsy@> has quit IRC17:06
rburtonfullstop: more systemd wont touch networking unless you configure networkd17:06
JPEWRP: It would have to be that the new hash was in the database and marked to report the unihash that was the taskhash of the original?17:07
*** hpsy <hpsy!~hpsy@> has joined #yocto17:07
*** jmiehe <jmiehe!> has quit IRC17:10
RPJPEW: right, and that shouldn't be able to happen? :/17:12
RPJPEW: its one reason I put the uuid in the variable it sets17:12
JPEWAh, right17:13
RPJPEW: I don't understand it at all :(17:13
RPJPEW: I also think I have the hashequiv change I made backwards :/17:13
RPJPEW: trying to understand from that build too17:14
RPJPEW: I think it renames the stamp and the hash without the hash being in the sstate cache :/17:14
*** yann <yann!~yann@> has quit IRC17:14
JPEWI was going to ask about that... I think I get what you are trying to do and why, but don't think I quite follow the mechaism17:14
RP6d55a78873fecf73b3a36b3b9326fae1a0ca3bd1c21f65ef9dfbfb2922ecae16 is, 6b59aec65be0166ea7bde7d7bc2004f822b13e842cb42142811487f867aac573 is not17:14
JPEWAh, ya if the stamp file was renamed that would make it think it didn't need to build17:15
RPJPEW: I thought that was correct since we'd told hashequiv to make a mapping. I now think that is wrong and we're creating the wrong mapping if that works :/17:15
*** vineela <vineela!~vtummala@> has joined #yocto17:15
JPEWOK, that would make sense.17:16
JPEWRP: So I *think* what you are trying to do is make a given taskhash report a specific unihash?17:18
JPEWe.g. when meta-toolchain gets a new taskhash because it's deps have changed, but we've already restored it from sstate, so that new taskhash should be mapped to the old unihash that the server previously reported17:19
RPJPEW: yes17:22
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC17:23
JPEWOk, then I *think* that in that case, the outhash is irrelevent. You should be able to add the new hash to the database with an "invalid" outhash (e.g. empty string) and eveything will sort out17:24
JPEWWe don't need the old outhash in the new entry because the old entry already has that outhash -> unihash mapping17:25
JPEWSo when the server looks up that outhash, it will get the same unihash (from the old entry) and the new one doesn't need it17:26
RPJPEW: right, I wasn't sure so I was trying to get the outhash17:27
RPJPEW: can you check if my logic is reversed in my patch?17:27
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto17:30
RPJPEW: I think I'd better rewrite this with less confusing variable names17:31
JPEWYa, I went through and tried to renamed them to unihash_old and unihash_new17:32
JPEWBut... I think the other problem is that you're capturing the old unihash and passing that as the new taskhash. You really want the old taskhash17:33
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC17:34
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:34
JPEWAnd, it does look backwards to me. You're passing the old unihash as the taskhash and the new unihash as the new one... instead pass the new taskhash as the taskhash and the old unihash as the unihash17:35
RPJPEW: I'm just confusing myself :(17:38
RPJPEW: One thing does worry me - what if an mapping for the hash already exists on the hashserver?17:38
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto17:38
JPEWWe always take the oldest hash, so the new one will be recorded but ignored17:39
RPJPEW: I think the client needs to error out though as the build wouldn't be reproducible17:39
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC17:40
RPI'm hoping this doesn't happen for anything we already have sstate artefacts for17:40
JPEWRP: Are you worried the existing DB on the AB is bad, or there is some other case that would trigger the logic?17:41
JPEWRP: I think I have a handle on this. If you want, I'll work up a patch for testing17:42
RPJPEW: actually, having stared at this, I think the code is right, the bitbake interpretation is wrong17:42
RPJPEW: I think that is wrong is that bitbake runqueue doesn't reset the task unihash to match the mapping it just created17:43
*** rburton <rburton!> has quit IRC17:43
RPand since it queried once, it would now cache the 'bad' value17:43
RPJPEW: there should be a "oh, my task unihash was reset again" event here17:44
RPJPEW: that stamp renaming is half the issue but explains why sstate broke17:45
JPEWreset to the value it had before the rehash?17:46
moto-timorburton: I haven't used dynamic-layers that much, but I like the idea... could that bring in cyrus-sasl from meta-networking as well (for python-ldap)?17:47
RPJPEW: yes17:49
RPJPEW: giving it a go with the tweak in -next17:57
RPJPEW: I have more renaming locally but didn't want to risk breaking things17:57
JPEWOK: Here's my (untested) take:
JPEWHmm, "old" and "new" in this case is confusing :)18:00
RPJPEW: yes, one reason I haven't gone further with those names18:01
RPsince we want the old value18:01
RPJPEW: I'll have a look later, thanks18:02
* RP -> food18:03
kergothmoto-timo: dynamic-layers is just a way to pull in bbappends only when the layer that has the main recipe exists, or recipes whose dependencies are only in that layer, potentially..18:04
*** mckoan is now known as mckoan|away18:06
*** armpit <armpit!~armpit@> has quit IRC18:08
*** rburton <rburton!> has joined #yocto18:15
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:25
*** guerinoni <guerinoni!> has quit IRC18:28
*** ericch <ericch!> has quit IRC18:32
*** dfrey <dfrey!~dfrey@> has joined #yocto18:32
*** ericch <ericch!> has joined #yocto18:33
dfreyI have defined a bluez5_5.52 recipe in one layer (BBFILE_PRIORITY=40) and there is a bluez5_5.50 recipe in another layer (BBFILE_PRIORITY=8).  It seems that while building bluez5_5.52, files from the bluez5_5.50 recipe's folder are being found. In the log.do_unpack file, I see this: "DEBUG: Searching for init in paths: <a bunch of paths>" and then:  "NOTE: Unpacking <path to bluez5_5.5018:41
kergoththat's odd, that shouldn't be possible.18:42
dfreyShould it even be searching in the recipe directory of the 5.50 version?18:43
kergothJPEW: ah, interesting, instead of re-sourcing the init you're capturing the vars it sets, that's cleaner. i like that we can specify the full buildcommand now. requiring PYREXCONFFILE will mean slightly different integration, but probably won't be problematic, and the user won't have to worry about the config in an old build dir being out of date with their preferences, presumably.19:10
kergoth(reading your personal next branch, cause i got bored)19:10
JPEWlol, ya.19:10
JPEWYes, I think it will be better, specifically because the oe-init-build-env now happens in the container19:11
JPEWMeaning, when I init 2.2 on my Fedora 31 machine, it won't complain about 'python' being python3 anymore :)19:12
*** roussinm <roussinm!> has joined #yocto19:14
khemthats how I wrap docker behind bitbake cmd19:15
JPEWkhem: Ya, we started with something very similar19:18
khemdevtool is painful with this env perhaps fixable but havent cared enough so far19:19
kergothyeah, i used something along those lines myself before too19:19
khemI will be happy to take in any improvements into yoe if you have suggestions19:20
JPEWkhem: I've been meaning to see what it would take to run yoe in pyrex; I don't think it would hard except new images would be needed b/c you don't build any hosttools19:21
JPEWerr, try to avoid building -native recipes19:21
kergothpyrex is basically a nicer version of what wrapper you have there, but configurable with a config file instead of hardcoding the paths to map19:21
kergoth integrates it into the mentor setup scripts, pretty painless19:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:27
*** rcw <rcw!~rcw@> has joined #yocto19:31
khemseems good can I use a different docker image ?19:31
khemor does pyrex expects things from image19:31
JPEWkhem: Yes19:31
JPEWThere is a minimal set of support the image requires19:32
JPEWIf you want to make your own, start from one of our "base" images19:32
JPEWor an "oe" image might be better for yoe if all you want is to add more pacakges so that you don't have to build -native recipes19:33
khemi am yet to see what it solves for me19:34
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC19:36
kergothi like that 1) more configurable, less hardcoded, 2) uses shims not shell functions, so less reliant on shell particulars, and wraps recipetool/devtool/etc by default too19:40
JPEWkhem: Perhaps you haven't run into this, but we had a lot of quirks we had to account for when running in a container19:41
*** yann <yann!> has joined #yocto19:42
*** mischief <mischief!> has joined #yocto19:44
*** pohly <pohly!> has quit IRC19:47
*** tgamblin_ <tgamblin_!~tgamblin@> has joined #yocto19:53
*** nrossi_ <nrossi_!uid193926@gateway/web/> has joined #yocto19:54
*** nayfe_ <nayfe_!uid259604@gateway/web/> has joined #yocto19:55
Ad0I am looking at rburton's which seems like a great starting point. however I get "ERROR: Nothing PROVIDES 'customimage' when running bitback customimage. there's a file called but I am not sure how this works with bitbake. is it suppose to make the file name into a a build name?19:56
*** u1106_ <u1106_!~quassel@> has joined #yocto19:56
*** elGamal <elGamal!> has quit IRC19:57
kergothdid you add the layer to BBLAYERS?19:58
Ad0hm I thought it was supposed to magically do that for me with the export TEMPLATECONF=../meta-custom/conf19:59
Ad0my mission is to make a "source control / git friendly" distro with clean structure instead of messing around with toaster20:00
Ad0it might be a shell issue if the paths are not set20:00
*** JPEW_ <JPEW_!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto20:00
*** elGamal <elGamal!~elg@> has joined #yocto20:01
*** diego_r <diego_r!~diego@> has quit IRC20:02
*** tgamblin <tgamblin!~tgamblin@> has quit IRC20:02
*** nayfe <nayfe!uid259604@gateway/web/> has quit IRC20:02
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC20:02
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC20:02
*** jij <jij!jonashg@nat/axis/x-mgbkucqkcclnrpjh> has quit IRC20:02
*** meow` <meow`!> has quit IRC20:02
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has quit IRC20:02
*** mdp <mdp!sid49840@gateway/web/> has quit IRC20:02
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC20:02
*** Azoff <Azoff!foobar@unaffiliated/azoff> has quit IRC20:02
*** u1106 <u1106!~quassel@> has quit IRC20:02
*** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC20:02
*** revsbech <revsbech!> has quit IRC20:02
*** nayfe_ is now known as nayfe20:02
*** nrossi_ is now known as nrossi20:02
*** diego_r <diego_r!~diego@> has joined #yocto20:02
*** meow` <meow`!> has joined #yocto20:03
*** mdp <mdp!sid49840@gateway/web/> has joined #yocto20:05
*** zbooth <zbooth!> has joined #yocto20:06
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has joined #yocto20:06
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto20:07
dfreyRegarding my message about my bluez recipe problems above... Does it make sense that my $FILESPATH contains directories from two different layers when I run "bitbake -c unpack bluez5"?20:13
JPEW_dfrey: depends: If they are added via bbappend then I think it would. If it's two .bb files, that wouldn't be what I would expect20:14
kergothonly if one of the layers is using a bbappend to add to FILESEXTRAPATHS20:14
Ad0kergoth, I made an idiot mistake, it works now. was environment / shell issue20:14
dfreyThere are bbappend files in play.  I'll look at that20:15
Ad0and I had to delete the build directory20:15
*** JPEW_ is now known as JPEW20:15
*** jij <jij!jonashg@nat/axis/x-xlzlevzpfxtviawf> has joined #yocto20:15
kergothah, good to hear you got it sorted20:15
Ad0thanks for  your help kergoth , I am trying to "port" the toaster configs over to this structure20:16
Ad0I executed it directly instead of source / .20:17
*** Hauke <Hauke!> has joined #yocto20:17
dfreyJPEW, kergoth: I think I'm headed in the right direction now.  Thanks for the hints20:17
frosteyesHi folks. Is it possible to use INCOMPATIBLE_LICENSE on image level?20:24
frosteyese.g. I have a file for all my images, where I want to prevent GPLv3 elements.20:25
frosteyesI though also have "-debug" versions of the images, only used locally, so GPLv3 is okay.20:26
*** tgamblin_ <tgamblin_!~tgamblin@> has quit IRC20:26
LetoThe2ndfrosteyes: no, you' probably have to switch it in/out through DISTROs20:26
LetoThe2ndfrosteyes: as per the documentation, INCOMPATIBLE_LICENSE works on the build- not the image creation stage:
LetoThe2ndhence it has to be set through a .conf file20:28
frosteyesLetoThe2nd: thanks.20:28
frosteyesI think it would have been a likely candidate for the image creation..20:29
*** JaMa <JaMa!~martin@> has quit IRC20:30
LetoThe2ndfrosteyes: only if your POV is limited to the GPLv3 topic20:30
roussinmHello y'all! We were wondering why $IMAGE_NAME from bitbake.conf is a hard assignment and not a default assignment? To modify the $IMAGE_NAME the only way is to patch the file, because bitbake.conf is somehow applied after our configurations.20:31
LetoThe2ndbecause "i do not want to go anything by this license into the image" is just something different than "this license is incompatible with my usecase". and the variable, as per documentation, is expressing the latter.20:31
LetoThe2ndroussinm: why do you want to modify IMAGE_NAME at all?20:32
frosteyesLetoThe2nd: understand the difference. Do you then reommned something for the first..20:32
roussinmLetoThe2nd: because the machine name inside is redundant because it's already in a directory which has the machine name.20:33
frosteyesAlternativ if some have created a python solution as a pre task for the image.20:33
frosteyesOr would I be looking into creating it my self..20:33
LetoThe2ndroussinm: thats a side effect, but what is it that you *actually* want to archieve?20:33
LetoThe2ndfrosteyes: switch DISTROs.20:33
LetoThe2ndfrosteyes: your debug distro can happily just he the normal one with gplv3 switched on.20:34
roussinmLetoThe2nd: What I would like to achieve is to remove the machine name from the image name, because for us it's redundant20:34
frosteyesLetoThe2nd: needing to switch distro for debug image, just create more overhead.. E.g. need to either provide it from cmd or need to edit local.conf, where 2 images, would just be switch image target.20:36
frosteyesBut it is properly easier to do it the yocto way, by having several distros, even though, I think it is a chumbersome way of doing it.20:37
LetoThe2ndroussinm: we do rather do this through just adding a symlink in the end that bears our desired name.20:37
LetoThe2ndfrosteyes: a) its the way it is b) it is for a reason: local data versus glabal data c) feel free to send patches for review.20:38
rburtonAd0: did you use . custom-init-env?20:42
roussinmLetoThe2nd: Are you referring to IMAGE_LINK_NAME, because this is too an hard assignment20:42
rburtonAd0: ah ok you sorted it20:42
LetoThe2ndroussinm: i'm not referring to anything specific at the moment, i don't have the code handy. i'm just pointing out that if all you need is a different, more convenient name for the end result, this might be a way less invasive way of archieving it.20:43
Ad0thanks rburton :) yeah I did in the end :)20:45
Ad0seems to build fine so far!20:47
roussinmLetoThe2nd: We did something like that in the past, but we though it was not a clean way to do it. If I want to change IMAGE_LINK_NAME or IMAGE_NAME, I think we could make it possible through bitbake.conf default assignment. Which is IMO simplier/friendly then having an 'addtask' something to create your image name.20:50
LetoThe2ndkergoth: can you maybe comment on the image name? ^^^^^^^^^^^^20:52
Ad0what happens if not all meta layers are warrior that I need? can I just get the thud one?20:52
LetoThe2ndAd0: try and find out. thats the only option you have20:53
Ad0ok so it's technically possible20:53
LetoThe2ndAd0: yes.20:53
*** Azoff <Azoff!foobar@unaffiliated/azoff> has joined #yocto21:02
*** berton <berton!~berton@> has quit IRC21:15
*** WillMiles <WillMiles!> has joined #yocto21:20
*** vmeson <vmeson!> has quit IRC21:24
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC21:26
*** cconlon <cconlon!~cconlon@> has joined #yocto21:30
*** rcw <rcw!~rcw@> has quit IRC21:30
RPJPEW: messed up the patch, retesting...21:33
*** armpit <armpit!~armpit@2601:202:4180:a5c0:51a5:502e:8fc:9836> has joined #yocto21:36
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:47
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC21:48
*** Bunio_FH <Bunio_FH!> has quit IRC22:00
*** WillMiles <WillMiles!> has quit IRC22:17
rburtonRP: should we announce that py2 will be removed from oe-core on e.g next monday?22:19
RPrburton: yes, good idea22:20
RPrburton: remind me to put in weekly status tomorrow. Do you want to send something out or should I?22:21
rburtoni can knock something up now22:21
*** nayfe <nayfe!uid259604@gateway/web/> has quit IRC22:23
rburtonRP: fired a new next, hopefully this time its actually green ;)22:28
rburtonmail sent22:28
rburtonshort and sweet22:28
RPrburton: thanks :)22:35
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC22:40
* RP ponders splitting sstate into a further set of subdirs22:43
RPwould take the autobuilder from 145,000 files in a directory to 570 which might not upset nfs so much22:44
RPits not currently scaling :/22:44
armpitrburton, thanks for the email22:44
armpitsorry, added a stable branch notice to yours22:51
armpitRP, I say go for it..22:52
*** cconlon <cconlon!~cconlon@> has quit IRC22:53
MarexRP: hey uh, is it possible to build an image which has both preempt-rt patched and non-preempt-rt-patched kernel images in it , from a single bitbake run ?22:57
MarexRP: I guess that's not what the multiconfig or whatever that multi- thingie name was is for22:58
*** jofr <jofr!~jofr@> has quit IRC23:04
*** jofr <jofr!~jofr@> has joined #yocto23:05
*** wooosaiiii <wooosaiiii!> has quit IRC23:07
*** wooosaiiii <wooosaiiii!> has joined #yocto23:10
RPMarex: multiconfig would let you do that23:11
RPMarex: it is possible to build two kernels in the same build too, if they namespace themselves the right way23:11
*** diego_r <diego_r!~diego@> has quit IRC23:17
*** vineela <vineela!~vtummala@> has quit IRC23:25
*** rburton <rburton!> has quit IRC23:31
MarexRP: is that the right tool for the job though ?23:45
*** agust <agust!> has quit IRC23:47
*** goliath <goliath!> has quit IRC23:56
RPMarex: it depends. You told me what you wanted to achieve and I said there are two ways you can do it. Whether they're "right" depends on information I don't have23:56
MarexRP: I want to ship both preempt-rt and non-preempt-rt patched kernel (and possibly xenomai-patched kernel) in the same image for one device23:58
MarexRP: I would very much like to stick with linux-yocto if possible23:58
RPMarex: in which case you need three kernel recipes (can just be copies of linux-yocto which change PN and inherit everything else)23:59
RPMarex: two of the kernel recipes need to set a different kernel module namespace23:59
MarexRP: that's all ? I recall it used to be awfully complicated when I last tried23:59
RP(package namespace)23:59

Generated by 2.11.0 by Marius Gedminas - find it at!