Wednesday, 2020-04-29

alejandrohsRP: sgw did anyone say beer?00:05
sgwalejandrohs: homebrew!  It's almost that time of day!  Actually working on steaming some rice for a batch of sake!00:05
alejandrohsdenix: I dont remember the exact details but yeah I think at some point just realized having separate TMPDIRs per TCLIBCs was just sane, and didnt get to the point where I had the ca-certs issue because of that00:09
alejandrohssgw: Still have to try the homebrew one!, now I remember you mentioning it before00:09
alejandrohsfirst time i hear about homebrew sake tbh00:10
denixalejandrohs: quite strange you don't see ca-certs issue with separate TMPDIRs...00:10
sgwyour welcome here anytime after the world opens up again phyically distanced for a time00:10
denixsgw: where are you now?00:10
sgw (actually an ex-Intel person manages the site!)00:11
sgwdenix: Still at Intel but working on a different distro project that is currently CentOS based, but we are looking at an OE/Bitbake alternative.00:12
denixsgw: clear?00:12
sgwSo I dropped back in to wave and cause trouble00:12
sgwno not clear, StarlingX (
sgwEdge Cloud stuff00:14
denixsgw: nice to see you again! :)00:14
sgwYeah, I miss hanging out with this crowd, much more active than our chat, I do pop in every so often!00:14
denixyeah, we definitely need another distro! care to convert your crowd to oe/yocto? :)00:15
khemMoh3N: IMAGE_INSTALL_append = " valgrind"  in local.conf00:17
sgwIt's being worked on!  Initial work is up already, but long way to go and needs some layer restructuring and an actual distro layer!  Currently using poky as the base, but really should not.00:17
khemdenix: whats the ca-certs issues00:17
denixkhem: multiconfig related00:18
sgwSort of classic new distro move (base it on poky)00:18
khemdenix: ok, so its newlib/glibc combo I believ ?00:18
denixsgw: nice!00:18
khemsgw: meta-centos00:18
khemok meta-centos700:19
denixkhem: yeah, kind of. separate TMPDIRs, but there's clash of ca-certs packages, which are noarch/all00:19
khemdenix: yeah noarch bites quite a bit when you build multiple libcs00:20
khemI use to see this on OE builder quite often ( woth glibc/musl ) but it seems to be doing better lately00:20
khembut there are issues there I know00:20
denixkhem: any ideas to get it sorted out?00:21
*** Moh3N <Moh3N!057efd82@> has quit IRC00:22
khemwhat error do you see, I usually see that its rebuilt due to a dependency being arch specific and used as RDEP instead of RRECOMMEND00:22
khemmy fixes sometimes also included SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS see
denixkhem: I'm trying to re-use the same deploy from multiconfig with separate TMPDIR due to TCLIBC and both of them build own ca-certs and they clash in do_write_ipk00:24
khemyeah in this case they are not allarch I am afraid00:25
denixwhat makes them not allarch?00:26
khemallarch should be common across multiconfigs too like multiarch00:26
khemusually a dependency perhaps00:26
khemI would check bitbake-diffsigs00:27
alejandrohssgw: definitely up for that00:27
alejandrohskhem: hahaha meta-centos00:27
alejandrohsdenix: I think once youre able to figure out why its happening we should file a bug to keep track of it, worst case scenario to state the scope that multiconfig supports00:29
alejandrohsdenix: I run daily builds of glibc/newlib but dont share neither TMP nor DEPLOY00:32
khemone way to narrow it further is to build it for glibc and then build for musl and see if it ends up rebuilding, then the problem is generic otherwise, its multiconfig speicific00:32
*** dreyna <dreyna!> has joined #yocto00:33
denixalejandrohs: yeah, not sharing DEPLOY_DIR would work, but what if you need to re-use artifact binaries between them?00:33
khemusing separate DEPLOY_DIR is hiding the problem.00:33
kheme..g if you were doing feeds it would show up00:34
denixkhem: exactly00:34
alejandrohsdenix: I do share them, but I have a sort of shared directory only with the artifacts, not ipks,rpms, etc00:35
khemI think if you share sstate it would be evident too, as the version will keep toggling00:36
alejandrohsdenix: these are declared on the shared machine so the variable is on both datastores00:36
alejandrohsdenix: not saying, your way shouldnt be possible thats just how I did it00:37
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto00:38
*** yann|work <yann|work!> has quit IRC00:40
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:b94c:baeb:34ca:6eb6> has quit IRC00:50
*** alejandrohs <alejandrohs!~alejandro@> has quit IRC01:01
*** dev1990 <dev1990!> has quit IRC01:04
*** robert_yang <robert_yang!~robert@> has quit IRC01:15
*** robert_yang <robert_yang!~robert@> has joined #yocto01:15
*** vmeson <vmeson!> has quit IRC01:17
*** dreyna <dreyna!> has quit IRC01:19
*** ssajal <ssajal!> has quit IRC01:28
*** vmeson <vmeson!> has joined #yocto01:35
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9dd6:f56f:6cc7:33cf> has joined #yocto01:41
*** ericch <ericch!> has quit IRC01:42
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC01:43
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9dd6:f56f:6cc7:33cf> has quit IRC01:50
*** edgar444 <edgar444!uid214381@gateway/web/> has joined #yocto02:10
*** dreyna <dreyna!> has joined #yocto03:03
*** dv_ <dv_!> has quit IRC03:04
*** dreyna <dreyna!> has quit IRC03:14
*** dv_ <dv_!> has joined #yocto03:18
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC03:26
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto03:28
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC03:54
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto03:54
*** sakoman <sakoman!> has quit IRC04:37
*** AndersD <AndersD!> has joined #yocto04:39
denixheh, besides above issues with ca-certs noarch, there are also issues using mc:<cfg>:pkg in different do_task[depends], as it checks there should be a single ":" in there...04:40
denixTask 'depends' should be specified in the form 'packagename:task'04:45
*** Chrusel <Chrusel!c1669b04@> has joined #yocto04:56
*** attieg <attieg!> has joined #yocto04:57
*** attieg_ <attieg_!> has quit IRC04:59
*** dreyna <dreyna!> has joined #yocto05:03
*** ibinderwolf <ibinderwolf!> has joined #yocto05:05
ChruselGood morning everybody! Can anybody confirm that is down?05:06
*** sgw <sgw!sgw@nat/intel/x-ffdupnvrnwmptnfs> has quit IRC05:07
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC05:08
*** dmoseley <dmoseley!~dmoseley@> has quit IRC05:15
*** feddischson <feddischson!> has joined #yocto05:31
armpitChrusel, yes it is. the certs are being updated05:32
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC05:32
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto05:34
*** gtristan <gtristan!~tristanva@> has quit IRC05:51
*** justinsg_ <justinsg_!uid296040@gateway/web/> has joined #yocto05:59
*** gtristan <gtristan!~tristanva@> has joined #yocto06:03
*** justinsg_ is now known as justinsg06:06
*** justinsg <justinsg!uid296040@gateway/web/> has joined #yocto06:07
*** pohly <pohly!> has joined #yocto06:14
Chruselarmpit: thanks for confirmation!06:15
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:23
*** frsc <frsc!> has joined #yocto06:26
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:34
*** Bunio_FH <Bunio_FH!> has joined #yocto06:34
*** thecomet <thecomet!~thecomet@> has quit IRC06:37
*** thecomet <thecomet!~thecomet@> has joined #yocto06:37
*** feddischson <feddischson!> has quit IRC06:40
*** feddischson <feddischson!> has joined #yocto06:43
*** dreyna <dreyna!> has quit IRC06:45
*** locutus_ <locutus_!> has joined #yocto06:45
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC06:46
*** agust <agust!> has joined #yocto06:55
*** phippu <phippu!> has joined #yocto06:58
*** fl0v0 <fl0v0!> has joined #yocto07:01
*** Bunio_FH <Bunio_FH!> has quit IRC07:08
*** Bunio_FH <Bunio_FH!> has joined #yocto07:08
*** rawr is now known as grumble07:22
*** phippu <phippu!> has quit IRC07:27
*** lfa_ <lfa_!> has joined #yocto07:51
*** lfa <lfa!> has quit IRC07:55
*** Bunio_FH <Bunio_FH!> has quit IRC07:55
*** locutus_ <locutus_!> has quit IRC07:59
*** locutus_ <locutus_!~LocutusOf@> has joined #yocto08:01
*** Bunio_FH <Bunio_FH!> has joined #yocto08:09
*** Bunio_FH <Bunio_FH!> has joined #yocto08:13
*** Bunio_FH <Bunio_FH!> has joined #yocto08:14
*** mckoan|away is now known as mckoan08:15
*** blarz <blarz!> has left #yocto08:16
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC08:18
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto08:18
*** justinsg <justinsg!uid296040@gateway/web/> has quit IRC08:18
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto08:19
*** locutus_ <locutus_!~LocutusOf@> has quit IRC08:21
*** Chrusel <Chrusel!c1669b04@> has quit IRC08:22
*** yann|work <yann|work!> has joined #yocto08:26
*** ant__ <ant__!> has quit IRC08:26
*** nameclash <nameclash!> has joined #yocto08:34
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC08:41
*** invalidopcode_ <invalidopcode_!> has joined #yocto08:44
*** invalidopcode <invalidopcode!> has quit IRC08:47
*** invalidopcode_ <invalidopcode_!> has quit IRC08:49
*** hpsy <hpsy!~hpsy@> has quit IRC08:55
*** goliath <goliath!> has joined #yocto08:56
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:10
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:3079:5c25:b6e7:5cb8> has joined #yocto09:12
*** jkroon_ <jkroon_!~jkroon@> has joined #yocto09:17
*** kroon <kroon!~kroon@> has joined #yocto09:18
*** locutus_ <locutus_!~LocutusOf@> has joined #yocto09:26
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC09:29
*** jobroe <jobroe!> has joined #yocto09:34
*** thaytan <thaytan!> has quit IRC09:41
*** thaytan <thaytan!> has joined #yocto09:42
*** florian_kc is now known as florian09:42
qschulzhalstead: hello there! Hope you're doing fine. I don't know if you're in charge of as well but there is a huge time difference between cloning with https and git protocol for meta-openembedded from
qschulzhalstead: 1min30+ for https, <10sec for git09:47
halsteadqschulz: yes I'm the person who can fix that. Https should be comparable or faster. I'll look into it.09:49
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:b94c:baeb:34ca:6eb6> has joined #yocto09:50
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:3079:5c25:b6e7:5cb8> has quit IRC09:51
*** ant__ <ant__!> has joined #yocto10:01
*** kroon <kroon!~kroon@> has quit IRC10:04
*** rburton <rburton!rburton@nat/intel/x-jlbddwfvtjxwisoq> has joined #yocto10:10
*** mamadeus <mamadeus!~mamadeus@> has joined #yocto10:19
*** mamadeus <mamadeus!~mamadeus@> has quit IRC10:22
RPdenix: you need mcdepends for that10:28
*** mattsm <mattsm!> has quit IRC10:33
nameclashmorning fellas, is there a way to run cleansstate "recursively"?, i.e. remove everything from the sstate-cache that would normally be populated during the build task for the given recipe?10:40
rburtonits very rare to need to cleansstate, what are you actually trying to do10:45
rburtonif you want to force rebuilds there are better ways10:48
nameclashthe "Exection of event handler 'sstate_eventhandler2' in sstate.bbclass failed with a python traceback saying "ValueError: not enough values to unpack (expected 3, got 1)"10:49
nameclashindicates something might be wrong with the sstate-cache and was looking for a solution other than wiping the entire sstate-cache directory10:50
*** iceaway <iceaway!~pelle@> has joined #yocto10:52
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto10:57
iceawayI'm having a weird issue when building one of my images. I have a base image which contains all the basic system sw, and then another image which requires the base image and adds just one recipe, our custom piece of software. But when I try to build the base image, it says that some recipes cannot be build because they depend or our custom software. Any idea how standard packages could have a dependency of10:57
iceawayour custom software?10:57
qschulziceaway: make sure you're actually building the image you think you're building. Is there any underscore, uppercase letter or weird character in the image recipe filename? do both image have a completely different filename?11:01
rburtoniceaway: pastebin of the error message would be helpful11:01
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@> has joined #yocto11:02
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto11:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:03
*** kroon <kroon!~kroon@> has joined #yocto11:03
*** locutus_ <locutus_!~LocutusOf@> has quit IRC11:03
iceawayqschulz: I'm sure its the correct image. I can build the image that requires the base image, but not the base image itself. Pastebin coming up..11:04
qschulziceaway: bitbake -e kodkod-image-base | grep anpr-sw11:09
qschulzif nothing there, then bitbake -g kodkod-image-base and inspect the .dot file manually to find who pull the anpr-sw11:10
rburtonyeah the key is11:10
rburton  - nothing provides anpr-sw >= 9.1.2b3 needed by gstreamer1.0-plugins-good-jpeg-1.14.4.imx-r0.1.aarch64_mx811:10
rburtondid you patch gstreamer-plugins-good?11:10
rburtonand presuambly anpr-sw is your special sauce11:11
qschulzor libgdiplus0-4.2-r0.0.aarch64_mx8 (first problem listed)11:13
rburtonthat sounds like part of meta-mono?11:14
iceawayqschulz: The first command gave me a PREFERRED_VERSION statement, which I use in my distro configuration to select the correct version of anpr-sw. Could that be the issue?11:22
iceawayEven if that recipe/package is not included it the image?11:23
iceawayrburton: Not touching gstreamer just including it in my base image. anpr-sw is our custom stuff, correct.11:25
qschulziceaway: no11:29
qschulzbitbake -e libgdiplus0 | grep anpr-sw11:30
qschulzor bitbake -e kodkod-image-base | grep libgdiplus0 I don't know, but use -g for the image and look which package is pulling your anpr-sw11:31
qschulzyou want to find who has anpr-sw on the right side of the arrow11:31
iceawayWill try to fire up something to view the dot-files.11:32
iceawayNever looked at .dot-files before, any good tool to recommend?11:32
qschulziceaway: vim or emacs11:35
*** berton <berton!~berton@> has joined #yocto11:35
iceawayqschulz: ah, cool, I thought you needed some special viewer.11:36
qschulziceaway: you could use `dot` but it takes ages to create a png from a .dot file11:36
qschulzand it's often barely usable (especially for an image)11:36
iceawayqschulz: vim worked fine. I cannot see anpr-sw anywhere in the file though.11:39
iceawayThis feels like one of those things that will feel SO obvious once I find it...11:40
qschulziceaway: you did -g on the image recipe right?11:44
*** kroon <kroon!~kroon@> has quit IRC11:45
iceawayqschulz: yes, I copied your command: bitbake -g kodkod-image-base11:45
*** hpsy <hpsy!~hpsy@> has joined #yocto11:46
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC11:49
*** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto11:54
*** dev1990 <dev1990!> has joined #yocto11:58
rburtoniceaway: let me guess: old version of yocto?11:59
*** gtristan <gtristan!~tristanva@> has quit IRC11:59
rburtonand i'm guessing anpr-sw contains a custom libjpeg implementation?12:01
*** rcoote <rcoote!> has joined #yocto12:01
rburtonso gstreamer found that in the sysroot instead of libjpeg, and happily built against it12:01
iceawayrburton: yeah :( stuck with Sumo for the time being unfortunately.12:02
qschulzah the auto-rdepends, good guess!12:02
rburtoniceaway: can you confirm that anpr-sw contains at least a libjpeg implementation?12:03
iceawayrburton: It may, I am not 100% sure what goes in that package it detail, it is provided to me by other developers in the company.12:03
iceawayLet me have a look"12:04
rburtonsumo has recipe specific sysroots so the prime cause of random build dependencies is gone12:05
rburtonso *somehow* this anpr is being selected as a provider when building gstreamer12:05
rburtonbut as its a black box and you can't say more, that's all we can tell12:05
iceawayrburton: is present in the anpr-sw package.12:05
iceawayAnyway to tell gstreamer to NOT use the anpr-sw one?12:06
rburtonfwiw, this is why black box recipes containing a pile of replacements is a bad idea12:06
*** larsjep <larsjep!c1b6a603@> has quit IRC12:06
rburtonpresumably you have a anpr-sw PROVIDES libjpeg somewhere12:07
iceawayrburton: yeah, it's not by my choosing :)12:07
iceawayrburton: not in the recipe, it provides some other libs but not libjpeg.12:07
*** dev1990 <dev1990!> has quit IRC12:09
rburtonwell i'd recommend that you 1) split anpr-sw up eg libjpeg-anpr and others, then each of those can PROVIDE=libjpeg, and your distro can do PREFERRED_PROVIDER to pick12:10
rburtonyou can't do that at an image level but you can at the distro level12:10
rburtonas switching provider will rebuild gstreamer etc12:10
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/> has joined #yocto12:11
iceawayrburton: thanks a lot! I will look into that.12:11
rburtoneg meta-intel has a custom zlib which has more tuning for IA hardware
rburtonand the BSP picks that for target zlib use
iceawayrburton: excellent, I will check those examples!12:17
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto12:18
*** gourve_l <gourve_l!> has joined #yocto12:32
gourve_lHi! I'm moving from thud to zeus. Unfortunately, it broke my custom class which inherit from core-image. This class mainly add a ROOTFS_POSTPROCESS_COMMAND which, during builds for production, use "systemd disable" to "disable" a tty (serial-getty@ttyS0.service).12:39
gourve_lHow should I prevent systemd-serialgetty to open the serial port? I believe that I should not touch to SERIAL_CONSOLES because SERIAL_CONSOLES is machine specific.12:39
*** sgw <sgw!~sgw@> has joined #yocto12:45
millonigourve_l: i believe that systemd doesnt create that service by default anymore12:46
millonibut you might want to check for yourself12:46
millonialso, you might want to consider moving to dunfell, which came out some days ago :)12:47
*** thecomet <thecomet!~thecomet@> has quit IRC12:47
gourve_lI missed the dunfell release. dunfell is still in dev according to but I'll move to it12:50
gourve_lhmm, maybe I will wait for a "Moving to the Yocto Project 3.1 Release" section12:52
gourve_lin the yocto's manual12:52
*** tgamblin_ <tgamblin_!> has joined #yocto12:54
gourve_lmilloni: the recipe (poky/meta/recipes-core/systemd/) seems to create the service for every tty defined in SERIAL_CONSOLES12:55
*** hpsy <hpsy!~hpsy@> has quit IRC12:55
*** tgamblin <tgamblin!> has quit IRC12:57
rburtongourve_l: wiki updated13:06
rburtongourve_l: also do you mean
*** rcoote <rcoote!> has quit IRC13:09
*** rcoote <rcoote!> has joined #yocto13:09
*** tgamblin_ is now known as tgamblin13:11
gourve_lAh, I look at the "current" manual that's why I missed it. (
gourve_lthanks for the link13:12
millonirburton: you might want to update "current" ^13:12
yoctiNew news from stackoverflow: dependency of one recipe over other recipe <>13:13
rburtonhalstead: can you fix the /current/ documentation link to point at 3.1 instead of 3.0?13:13
*** rcoote <rcoote!> has quit IRC13:14
*** rcoote <rcoote!> has joined #yocto13:14
halstead Yes I can rburton.13:14
millonigourve_l: ah apologies - i might have got it mixed up with another service13:15
*** AndersD <AndersD!> has quit IRC13:15
milloniwhy can you not change SERIAL_CONSOLES?13:15
gourve_lbecause, if I'm right, I would have  only 1 .ipk for systemd-getty but 2 different builds (my-image-dev.rootfs.ext3 with serialgetty@ttyS0.service enabled and my-image-build.rootfs.ext3 with serialgetty@ttyS0.service disabled). The content of the .ipk would be the content created during the last build13:16
millonii dont think that's necessarily a problem13:18
millonias far as i can tell, if you have two MACHINEs (-dev and regular), you will end up with 2 ipk's for systemd-serialgetty13:19
milloniwhich should be fine unless you're insistent on having a single ipk13:20
halsteadrburton, Done.13:20
millonibut that will limit the range of things you can do severely13:20
gourve_lthey are not 2 different machines13:20
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC13:20
gourve_lotherwise, yes I would have done that13:20
milloniah, i see, so it's a single MACHINE and DISTRO but 2 different images?13:21
gourve_lyes, with small tricks during the rootfs post process13:22
*** ericch <ericch!> has joined #yocto13:22
millonii would recommend using a separate distro or machine for dev builds13:22
milloniotherwise you're severely limiting yourself in the range of things you can13:23
millonithat seems to be the standard practice13:23
*** g0hl1n <g0hl1n!> has quit IRC13:24
gourve_lok, so with standard practice you have something like build/tmp/deploy/my-machine-dev and build/tmp/deploy/my-machine-prod ?13:25
milloniwhen i say it seems standard practice i just mean that this solution has been recommended to me by at least one person from the yocto team :)13:25
millonibut yeah, that's what i would do13:26
millonianother option that i have more experience with is having a separate layer that you switch on and off depending on whether you need a dev or prod build, but i found this solution very cumbersome and i dont recommend it13:27
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto13:28
millonii *think* (might be wrong about this) that yocto zeus/dunfell has a feature where it run a build for multiple machines at the same time which is very cool :)13:28
millonis/it run/it can run/13:28
gourve_lnice feature, I have to take a look at it13:29
gourve_lbut, with 1 machine for dev and 1 for prod, do you build the linux kernel 2 times, even if you have the same defconfig?13:30
millonii'm not sure13:32
millonimy guess would be no, it will reuse sstate cache because the inputs are the same13:32
millonimaybe it will re-run do_deploy etc but that should be negligible13:33
millonifull disclosure: i dont know anything about sstate caching though13:33
*** rcoote <rcoote!> has quit IRC13:34
*** rcoote <rcoote!> has joined #yocto13:34
*** g0hl1n <g0hl1n!> has joined #yocto13:36
*** ssajal <ssajal!> has joined #yocto13:38
*** rcoote <rcoote!> has quit IRC13:39
*** rcoote <rcoote!> has joined #yocto13:39
gourve_lthanks, I will do some tests. If the kernel is only built 1 time that would be wonderful because I already have 7 different machines and 4 "flavors" (dev, prod, test, demo).13:42
millonioh wow, yeah, that might get messy13:45
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC13:46
*** stephano <stephano!> has joined #yocto13:50
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has quit IRC13:53
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has joined #yocto13:53
*** vmeson <vmeson!> has quit IRC13:54
*** rcoote <rcoote!> has quit IRC13:54
*** rcoote <rcoote!> has joined #yocto13:54
*** rcoote <rcoote!> has quit IRC13:58
*** rcoote <rcoote!> has joined #yocto13:59
RPkanavin_home: -next looks better apart from the ubuntu1604 segfault :(13:59
*** GeneralStupid <GeneralStupid!> has joined #yocto14:00
GeneralStupidHi, is there a (simple) way to get an openssl binary into yocto?14:02
*** sakoman <sakoman!> has joined #yocto14:02
milloniGeneralStupid: IMAGE_INSTALL += "openssl" in your image recipe14:04
*** nameclash <nameclash!> has quit IRC14:04
GeneralStupidmilloni: it does not create a binary afaik14:06
milloniin only deploys the shared library?14:07
qschulzGeneralStupid: wild guess, openssl-bin?14:09
GeneralStupidqschulz: no -.-14:09
milloniGeneralStupid: which version of yocto?14:10
gourve_lopenssl-bin works for me14:10
*** hpsy <hpsy!~hpsy@> has joined #yocto14:15
kanavin_homeRP: I guess ubuntu 16.04 has to join the tarball gang14:16
kanavin_homeand minimum gcc bumped to 6.x14:16
GeneralStupidgourve_l: 2.6 i guess14:16
RPkanavin_home: but why? :/14:17
*** jobroe <jobroe!> has quit IRC14:18
GeneralStupidIts actually not true. I dont have any binary -.-14:20
qschulzGeneralStupid: openssl-bin is a package not a recipe. bitbake is for building recipes14:20
GeneralStupidqschulz: this is really confusing me all the time14:21
khemrecipe = a set of rules to build packages14:23
khempackage = contains binary outputs14:23
khema recipe can generate 1 or more packages one of these output packages can be same name as recipe14:24
khemhope that helps14:24
GeneralStupidWhere would a good place to add that package?14:25
qschulzGeneralStupid: in your image, with IMAGE_INSTALL14:25
*** berton <berton!~berton@> has quit IRC14:25
*** berton <berton!~berton@> has joined #yocto14:26
qschulzGeneralStupid: also, DEPENDS is on recipes, RDEPENDS is on packages14:26
GeneralStupidOk :)14:27
*** hpsy <hpsy!~hpsy@> has quit IRC14:32
GeneralStupidThanks this is working14:34
*** ibinderwolf <ibinderwolf!> has quit IRC14:34
*** mattsm <mattsm!> has joined #yocto14:37
*** gtristan <gtristan!~tristanva@> has joined #yocto14:44
*** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC14:54
*** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto14:55
*** weltling_ is now known as weltling14:57
*** pharaon2502 <pharaon2502!> has quit IRC14:59
*** jd89 <jd89!> has joined #yocto15:07
*** frsc <frsc!> has quit IRC15:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto15:10
RPkanavin_home: since you like 'fun' problems, have you any ideas on the cmake/expat dependency problem?15:17
RPkanavin_home: I really don't like the patch proposed15:17
JPEWkanavin_home: I've push the SDL change to master-next in meta-mingw15:17
*** jd89 <jd89!> has quit IRC15:18
kanavin_homeRP: regarding ubuntu 16.04, my best guess is that openmp parallel code in rpm is incorrectly compiled by gcc 5.x, and segfaults. Upstream has changed how it works quite a bit from my original patches.15:18
kanavin_homeJPEW: thanks - that means the virgl enablement can proceed now.15:19
RPkanavin_home: that would explain it. I guess forcing the min version is easiest :/15:20
kanavin_homeRP: can I see where the cmake/expat problem is?15:20
kanavin_homeah, patch proposed15:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:21
RPkanavin_home: the patch explains it at least :)15:21
*** jd89 <jd89!> has joined #yocto15:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto15:24
rburtonbootstrap is fun15:29
rburtoncould just delay it by not switching to cmake for expat15:30
*** maudat <maudat!> has joined #yocto15:31
*** rcoote <rcoote!> has quit IRC15:34
yoctiNew news from stackoverflow: dependency of one recipe over other recipe [closed] <>15:43
RPrburton: that is what the patch does but it will mean two different versions of expat eventually15:44
RPkanavin_home: should I go ahead and sent the patches for the gcc min version and adjust the autobuilder config?15:49
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:51
kanavin_homeRP: I would first want to confirm that that would indeed solve the issue though, somehow. There is a chance it would still segfault even after gcc bump due to some other ubuntu-specific thing.15:52
kergothsome days i feel like we should give up and just require that an official container be used for the build, host support issues suck :)15:53
RPkanavin_home: how about we rerun this branch on the performance test worker with build tools temporarily applied there?15:53
RPkergoth: it is one of the values of the project, which makes this a tough one15:53
rburtonkergoth: there's definitely value in a known host setup15:54
kergothyep, all the way back to the beginning it was a key feature, many other projects had more host requirements, specific distros, sudo, etc15:54
kanavin_homeRP: yes, that should work15:54
kergothstill a pain in the ass though15:54
kanavin_homekergoth: it would be less of a pain, if old distros would be dropped more aggressively15:55
kergothi do think there's more value in *not muckingw ith the user's host setup* than actually having to build on the same. using a wrapper with docker like pyrex makes the use of the container largely transparent15:55
kanavin_homekergoth: supporting multiple distros is not such a big problem in itself, if they're all reasonably recent15:55
kanavin_homekergoth: but some members want centos 7 or whatnot15:55
kergothyeah, that's a pain. i used to have to carry like 12 extra bbappends in meta-mentor just for centos5 crap15:56
RPkanavin_home: we will be able to better do this now we have buildtools-extended15:56
kanavin_homeRP: yeah, I tried that on centos 7, and it's pretty neat15:57
RPkanavin_home: test build running15:59
RPkanavin_home: gives us the best of both worlds, we can "support" old hosts but move forward more easily15:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto16:05
mcfriskfyi openembedded developer happy hour:
neverpanicmcfrisk: you do no corporate doesn't allow zoom? *scnr*16:09
mcfriskneverpanic: I do, not using corporate things16:20
mcfriskneverpanic: good to know our IT dept has little eyes and ears here too ;)16:21
*** itaysp <itaysp!~itaysp@> has joined #yocto16:21
neverpanicmcfrisk: is comparing me to IT a deliberate or accidental insult? ;-)16:23
mcfriskneverpanic: both16:23
neverpanicI won't rat you out =)16:23
mcfriskthen join in the zoom thingy16:24
neverpanicnope, busy doing GDP++16:24
mcfriskI had to unblock video from bios, fall back to distro kernel and install the scary .deb, but zoom works now16:24
*** orzen <orzen!> has quit IRC16:28
*** jae1 <jae1!> has joined #yocto16:29
opellois there a nice way to handle a postinst that depends on a service (my use case is docker and loading images into it) ... meta-openstack seems to just start postgres and wait for python-heat, but i'm concerned about if at some point there's a postinst for the dependent service and the start up mess that would ensue16:32
kanavin_homeRP: good news, cmake has a copy of expat in its source tree, and an option to use it :)16:34
Crofton|roadmcfrisk:  thanks for postig here too!16:34
RPkanavin_home: that is horrible but would solve the problem I guess16:34
*** jae1 <jae1!> has quit IRC16:35
kanavin_homeRP: only needs to be enabled for cmake-native, which is fine I think?16:36
*** fl0v0 <fl0v0!> has quit IRC16:39
RPkanavin_home: yes, good point. that helps16:45
*** mckoan is now known as mckoan|away16:54
*** vineela <vineela!~vtummala@> has joined #yocto17:02
*** robert_yang <robert_yang!~robert@> has quit IRC17:19
*** robert_yang <robert_yang!~robert@> has joined #yocto17:19
*** Bunio_FH <Bunio_FH!> has quit IRC17:34
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:37
*** invalidopcode <invalidopcode!> has joined #yocto17:38
jd89Is there a way to control how the partitions are created with wks / wic? In creating an image with 5 partitions an extended partition is created as the 4th partition and two others are created within it. Is it possible to specify where the extended partition is created or switch to using GPT?17:45
*** Bunio_FH <Bunio_FH!> has joined #yocto17:47
*** g0hl1n <g0hl1n!> has quit IRC17:52
*** g0hl1n <g0hl1n!> has joined #yocto17:53
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:116a:e4c5:723c:5ca8> has joined #yocto17:56
*** rburton <rburton!rburton@nat/intel/x-jlbddwfvtjxwisoq> has quit IRC17:59
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3c5d:7c09:562a:defe> has quit IRC18:02
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3cb1:4458:b980:2533> has joined #yocto18:06
*** pharaon2502 <pharaon2502!> has joined #yocto18:07
kergothupdated bitbake and oe-core today and now i'm getting shitloads of 'server version is too old for client' messages18:11
kergothand now i'm getting tons of attempted reconnects to the bitbake server, but this is non-persistent, so the auto-stated server must have crashed without giving any useful output?18:51
kergothdid something change in how bitbake clients and servers interact or are started recently?18:52
armpitthat sound new. if you can, could you open a defect?19:01
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/> has quit IRC19:04
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/> has joined #yocto19:05
*** leon-anavi <leon-anavi!~Leon@> has quit IRC19:06
*** vineela <vineela!~vtummala@> has quit IRC19:17
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto19:20
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC19:23
*** aidanh_ is now known as aidanh19:23
*** vineela <vineela!~vtummala@> has joined #yocto19:24
*** jobroe <jobroe!> has joined #yocto20:01
*** jd89 <jd89!> has quit IRC20:03
*** jd89 <jd89!> has joined #yocto20:21
*** alejandrohs <alejandrohs!~alejandro@> has joined #yocto20:30
RPkergoth: check the cooker deamon log file as that should say what happened20:31
*** frsc <frsc!> has joined #yocto20:33
*** jd89 <jd89!> has quit IRC20:48
*** frsc <frsc!> has quit IRC20:53
*** feddischson <feddischson!> has quit IRC20:57
*** edgar444 <edgar444!uid214381@gateway/web/> has quit IRC21:00
psrcodeHi, really basic question that I can't seem to find an answer for: how do I enforce a "tune" for a machine? let's say I "require conf/machine/include/" the defaulttune is ppc64p9le but I would like to force the new machine to use the ppc64p9 instead. Do I simply declare DEFAULTTUNE_mymachine = "ppc64p9"?21:03
*** Bunio_FH <Bunio_FH!> has quit IRC21:03
*** Bunio_FH <Bunio_FH!> has joined #yocto21:04
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC21:08
psrcodeanswering myself: "DEFAULTTUNE = " in the machine conf does the job.21:14
*** pohly <pohly!> has quit IRC21:15
psrcodeat least seems to. tbh I find the name DEFAULTTUNE to be a bit misleading but ¯\_(ツ)_/¯21:16
*** berton <berton!~berton@> has quit IRC21:18
*** meow` <meow`!> has quit IRC21:22
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC21:25
*** meow` <meow`!~sbourdeli@> has joined #yocto21:31
*** camus1 <camus1!~Instantbi@> has joined #yocto21:39
*** kaspter <kaspter!~Instantbi@> has quit IRC21:41
*** camus1 is now known as kaspter21:41
*** agust <agust!> has quit IRC21:44
*** yann|work <yann|work!> has quit IRC21:48
*** camus1 <camus1!~Instantbi@> has joined #yocto21:52
*** kaspter <kaspter!~Instantbi@> has quit IRC21:52
*** camus1 is now known as kaspter21:52
*** pharaon2502 <pharaon2502!> has quit IRC21:56
*** pharaon2502 <pharaon2502!> has joined #yocto21:58
*** pharaon2502 <pharaon2502!> has quit IRC21:59
*** pharaon2502 <pharaon2502!> has joined #yocto22:01
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:b94c:baeb:34ca:6eb6> has quit IRC22:01
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:5d17:dfd5:86c9:227> has joined #yocto22:02
*** stbenz8 <stbenz8!> has joined #yocto22:05
*** pharaon2502 <pharaon2502!> has quit IRC22:05
*** stbenz <stbenz!> has quit IRC22:07
*** stbenz8 is now known as stbenz22:07
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:10
alejandrohspsrcode: that allows us to override the value correctly and keep a hierarchical structure for similar architectures and their features22:11
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto22:13
psrcodeI was simply complexed with de "DEFAULT" part, i was expecting a "TUNE" parameter to set.22:13
RPpsrcode: it all depends how you perceive it :/22:18
psrcodeas long as it works at the end of the day, I don't care much :)22:19
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:24
khempsrcode: yes you did it right way22:26
*** jobroe <jobroe!> has quit IRC22:30
denixRP: thanks, I was able to use mcdepends successfully22:36
*** kergoth <kergoth!~kergoth@> has left #yocto22:39
denixRP: btw, is there a way to use MC overrides w/o mcextend.bbclass? I see it adds a useful MCNAME variable as well. but it is via BBCLASSEXTEND. I wonder if w/o that class there's a way for recipe to determine it's being built w/ mc:<name> prefix...22:43
RPdenix: BB_CURRENT_MC iirc22:45
RPdenix: but be careful since that would make the recipe MC specific22:46
denixRP: ok, BB_CURRENT_MC=default otherwise22:48
RPdenix: right22:49
denixRP: this could work... thanks!22:50
*** goliath <goliath!> has quit IRC22:52
*** alejandrohs <alejandrohs!~alejandro@> has quit IRC22:57
*** vineela1 <vineela1!vtummala@nat/intel/x-yztujwyzybxuagoz> has joined #yocto22:57
*** vineela <vineela!~vtummala@> has quit IRC22:59
*** ant__ <ant__!> has quit IRC23:05
*** alejandrohs <alejandrohs!~alejandro@> has joined #yocto23:11
*** alejandrohs <alejandrohs!~alejandro@> has quit IRC23:13
*** maudat <maudat!> has quit IRC23:15
*** robert_yang <robert_yang!~robert@> has quit IRC23:22
*** robert_yang <robert_yang!~robert@> has joined #yocto23:23
*** ericch <ericch!> has quit IRC23:24
*** robert_yang <robert_yang!~robert@> has quit IRC23:32
*** robert_yang <robert_yang!~robert@> has joined #yocto23:33
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:5d17:dfd5:86c9:227> has quit IRC23:36
*** robert_yang <robert_yang!~robert@> has quit IRC23:52
*** robert_yang <robert_yang!~robert@> has joined #yocto23:53

Generated by 2.17.2 by Marius Gedminas - find it at!