Sunday, 2017-04-02

*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC00:07
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto00:13
*** ant_home <ant_home!~ant__@> has quit IRC00:19
*** Snert <Snert!> has quit IRC00:47
*** Snert <Snert!> has joined #yocto00:56
-YoctoAutoBuilder- build #1079 of nightly-mips-lsb is complete: Failure [failed Running Sanity Tests BuildImages_1] Build details are at
-YoctoAutoBuilder- build #1102 of nightly-x86-lsb is complete: Failure [failed BuildImages_1] Build details are at
*** rcw <rcw!> has quit IRC01:44
*** p0kerface|work <p0kerface|work!~bg14ina@kde/bgupta> has joined #yocto01:45
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC01:48
*** p0kerface|work <p0kerface|work!~bg14ina@kde/bgupta> has quit IRC02:14
*** catch22 <catch22!~aboseley@> has quit IRC02:23
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC03:00
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto03:06
*** catch22 <catch22!~aboseley@> has joined #yocto03:08
*** sbach <sbach!~sbach@> has quit IRC03:22
*** madgoat <madgoat!> has joined #yocto03:36
*** madgoat <madgoat!> has left #yocto03:38
*** catch22_ <catch22_!~aboseley@> has joined #yocto03:44
Son_Gokukanavin: libdnf isn't version 0.2.3, it's on 0.8.1 right now04:00
-YoctoAutoBuilder- build #1122 of nightly-x86 is complete: Failure [failed BuildImages_1] Build details are at
-YoctoAutoBuilder- build #1128 of nightly-arm is complete: Failure [failed BuildImages_1 BuildImages_2] Build details are at
-YoctoAutoBuilder- build #1067 of nightly-arm-lsb is complete: Failure [failed BuildImages_1] Build details are at
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC04:24
*** linulin <linulin!> has quit IRC04:24
*** linulin <linulin!> has joined #yocto04:24
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto04:27
*** hanthings_ <hanthings_!~nandor@> has joined #yocto04:29
*** nandi_ge___ <nandi_ge___!~nandor@> has quit IRC04:32
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto04:39
*** themikenicholson <themikenicholson!~nic47222@> has quit IRC04:46
*** themikenicholson <themikenicholson!~nic47222@> has joined #yocto04:50
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto05:03
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC05:13
*** abelal <abelal!~quassel@> has quit IRC05:24
*** Noor <Noor!~quassel@> has quit IRC05:25
*** abelal <abelal!~quassel@> has joined #yocto05:26
*** Noor <Noor!~quassel@> has joined #yocto05:26
-YoctoAutoBuilder- build #864 of nightly-oe-selftest is complete: Failure [failed Running oe-selftest] Build details are at
*** gtristan <gtristan!~tristanva@> has quit IRC06:37
*** gtristan <gtristan!~tristanva@> has joined #yocto06:41
gtristanRP, in this case, its clearly not worth my time trying to force gcc build scripts to parallelize better, I could lose a whole week or two hunting down this special case; when the fact is, just building gcc/xgcc with make all-gcc *before* ever trying to configure libgcc (which, actually makes sense) works06:49
gtristananyway, I can keep maintaining my downstream patch06:49
gtristanI would also wonder though, where do gcc configure/build scripts make a guarantee that invoking internal targets like this is really going to work ? (I have to at least be suspicious that this is not really a bug, and that users are not really intended to invoke make configure-libgcc at all anyway, and its just some user who really wants to invoke that internal target)06:51
RPgtristan: I do remember that several of us have tried and failed to reproduce it :(07:12
-YoctoAutoBuilder- build #729 of nightly-arm64 is complete: Failure [failed Running Sanity Tests] Build details are at
*** Ox4 <Ox4!~int@unaffiliated/zloy> has joined #yocto07:50
Ox4morning guys07:50
Ox4could somebody help me with compilation error: ?07:51
*** p0kerface|work <p0kerface|work!~bg14ina@kde/bgupta> has joined #yocto08:03
*** ant_home <ant_home!~ant__@> has joined #yocto08:09
RPOx4: looks like you're using 64 bit compiler flags with a 32 bit toolchain08:23
*** grma <grma!~gruberm@> has joined #yocto08:28
*** peacememories <peacememories!> has joined #yocto08:30
Ox4RP: file arm-linux-gnueabihf-gcc08:38
Ox4arm-linux-gnueabihf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.24, BuildID[sha1]=27933f002c76b6bb88e5a4c5ec3afdacd3392e0e, not stripped08:38
RPOx4: the compiler is a 64 bit binary but that doesn't mean it can generate 64 bit binaries though08:55
*** gnana <gnana!~gnanachan@> has joined #yocto09:16
*** catch22 <catch22!~aboseley@> has quit IRC09:32
*** catch22_ <catch22_!~aboseley@> has quit IRC09:32
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC09:37
*** peacememories <peacememories!> has quit IRC09:49
*** sjolley1 <sjolley1!sjolley@nat/intel/x-gavokkahjwdlbsob> has quit IRC09:53
*** sjolley <sjolley!~sjolley@> has joined #yocto09:54
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto10:13
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC10:33
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:34
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto10:38
*** zzeroo <zzeroo!> has quit IRC10:49
*** Biliogadafr <Biliogadafr!> has joined #yocto11:05
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:26
paulbarkerAnyone else having problems with autoconf-native today on master? It's complaining that it can't find help2man during do_compile11:30
*** gtristan <gtristan!~tristanva@> has quit IRC11:34
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:38
RPpaulbarker: I'm not aware of issues fwiw11:41
*** peacememories <peacememories!> has joined #yocto11:41
paulbarkerRP: It's strange as I have a successful build only last night. This is a new clone of everything and it's failing. Probably my mistake somewhere, I've just got to work out where11:42
*** gtristan <gtristan!~tristanva@> has joined #yocto11:42
RPpaulbarker: sounds like the story of my life recently :/11:42
paulbarkerRP: rolling back oe-core to a commit from a few days ago doesn't fix it so I doubt it's a change there that's broken anything11:43
*** peacememories <peacememories!> has quit IRC11:44
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:45
*** peacememories <peacememories!> has joined #yocto11:45
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:46
RPpaulbarker: a build here seems ok fwiw11:47
paulbarkerFixed it, but this looks like a recipe-specific sysroot issue11:51
paulbarkerI set up a new build with everything checked out on one drive11:51
paulbarkersstate-cache, downloads and tmp symlinked to another bigger but slower drive11:52
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:52
paulbarkerRemoving the 'tmp' symlink fixed it11:52
*** Ox4 <Ox4!~int@unaffiliated/zloy> has quit IRC11:56
paulbarkerSetting TMPDIR to point at the other drive works, using a symlink in the build directory doesn't11:56
paulbarkerI think it's confusing PATH during certain tasks11:58
*** peacememories <peacememories!> has quit IRC11:58
paulbarkerRP: I've reproduced on another build server now. If TMPDIR points at a symlink it seems to lead to bad a PATH value in autoconf-native. Not sure about other recipes yet12:14
*** Ox4 <Ox4!~int@> has joined #yocto12:16
paulbarkerLinking tmp -> tmp2 is fine, linking tmp -> ../tmp causes failures12:20
paulbarkerI can open a bug if this is something we care about12:20
RPpaulbarker: I think we'd just add a sanity check for this and error if someone does it12:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto12:32
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC12:41
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto13:08
ant_homeRP: I have a build from scratch. I see the postinst warning. What did you do to know? Should I revert it and rebuild?13:38
ant_homethe update_gio_module_cache saga I mean13:39
*** jairglez <jairglez!jairdeje@nat/intel/x-hfdkwznhsvnqiysi> has joined #yocto13:45
ant_homeRP: after revert, anything about postponed packages in do_rotfs log13:47
*** jairglez <jairglez!jairdeje@nat/intel/x-hfdkwznhsvnqiysi> has left #yocto13:58
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:06
*** zecke <zecke!> has joined #yocto14:51
*** esfaer <esfaer!> has joined #yocto14:57
*** esfaer <esfaer!> has left #yocto14:57
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC15:12
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:13
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC15:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:18
*** gnana <gnana!~gnanachan@> has quit IRC15:23
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC15:25
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto15:26
zeckeI have some issue porting a custom recipe to build an ubi from dora to master. Anyone aware of how task:do_populate_sysroot and do_prepare_recipe_sysroot interact?15:39
*** grma <grma!~gruberm@> has quit IRC15:54
RPant_home: yes, please revert and then see if the postinst is still deferred16:02
RPzecke: that is basically recipe specific sysroots so a fairly big change16:03
zeckeRP: is my recipe. it builds an ubi but is not an image16:06
zeckeRP: with mtd-utils-native:do_populate_sysroot inside the task depends... I end up with a FileExistsError on the do_fetch task (e.g. gcc or glibc-.. being linked twice)16:06
zeckeRP: without mtd-utils-native:do_populate_sysroot mkfs.ubifs is failing...16:07
zeckeI don't mind rewriting it.. I tried with inherit image and then having do_rootfs/do_image in shell.. but mkfs.ubifs was still missing :)16:08
zeckebut the change is nice, it helps to reveal hidden dependencies nicely..16:09
RPzecke: I think it sounds like its trying to pull in glibc-initial and gcc-cross-initial which have file overlap with gcc-cross and glibc16:12
RPzecke: Usually there is code in sstate.bbclass (setscene_depvalid()) which avoids this. I think something about your more unusual task structure is meaning that isn't working16:12
RPzecke: right, libgcc-initial is the same issue16:14
RPzecke: FWIW the DEPENDS in that recipe doesn't do much since DEPENDS are applied to do_configure and you don't really depend on that16:16
RP(fetch is before configure)16:16
zecke Direct dependencies are [... I seem to have glibc-initial and glibc-locale in it16:16
zeckeand most likely glibc-locale depends on glibc.. so I end up with both..16:16
RPzecke: I don't understand now glibc-initial would become a direct dependency :/16:17
RPzecke: you could try being more specific, e.g. virtual/kernel:do_build -> virtual/kernel:do_deploy16:18
RPimage-rauc-rescue-initramfs:do_build -> image-rauc-rescue-initramfs:do_image_complete16:18
RPthat might just be enough to stop it getting so confused16:19
zecke for the copy of the first lines. if you want to have the rest I can copy it too16:19
RPzecke: try change the deps to what I've suggested above, I think understand why it thinks these are direct deps now16:20
zeckeRP: yes, direct dep is fixed.. but now mkfs.ubifs is not there. :(16:21
RPzecke: you kept mtd-utils-native:do_populate_sysroot in do_fetch[depends] ?16:21
zeckemaybe I add for do_deploy as this is where I call mtd-utils-native/mkfs.ubifs16:23
RPzecke: just about to suggest that16:23
zeckeokay that does the trick. So the sysroot can change per task. Just from looking at the behavior it seems that successful tasks end up in the sstate so the result of do_fetch was kept.. and do_deploy started off differently?16:25
zeckeThank you. It is building now. And I will clean it up.16:25
RPzecke: Its either that, or that deploy is assumed to be an sstate task and is a semi-reserved name in that sense16:26
RP(usually enabled with deploy.bbclass)16:26
RPanyhow, glad you're somewhere close. I think we need to do something about do_build dependencies and -initial...16:26
zeckehappy to have found a corner case :)16:27
zeckeYeah, my next issue comes from trying to support dora and master as much as possible from the same branch.. but that is something I caused myself16:27
*** _william_ <_william_!> has quit IRC16:36
*** _william_ <_william_!> has joined #yocto16:36
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:36
*** p0kerface|work <p0kerface|work!~bg14ina@kde/bgupta> has quit IRC16:41
*** _william_ <_william_!> has joined #yocto16:42
*** p0kerface|work <p0kerface|work!~bg14ina@kde/bgupta> has joined #yocto17:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto17:56
sveinseI set out to combine a larger Qt application and its recipe for building it into one repository. I think I was able to, by ditching the use of SRC_URI: . Any comments to this recipe header?18:03
*** pohly <pohly!> has joined #yocto18:29
paulbarkerLooks like ethtool-4.8.tar.gz got re-uploaded upstream with a different md5sum/sha256sum. It's the same .tar file, just re-compressed with a new date. What's our policy on things like that?18:35
paulbarkerIf I send a patch, will the mirror get updated when it's merged?18:35
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC18:40
*** pohly <pohly!> has quit IRC18:45
mrpelotazoI have an exported library target which I import to other projects with find_package. It works fine under my host machine but fails when built with yocto with following error message: The imported target xyz references the file "/usr/lib/libxyz.a" but this file does not exist19:04
mrpelotazoThe libray file exists in the recipe-sysroot19:07
mrpelotazoIs there some extra config for cmake exported targets to work with yocto?19:09
RPpaulbarker: tempted to change the url to our mirror19:51
RPpaulbarker: I wish upstreams wouldn;t do this19:51
paulbarkerRP: I've locally changed SRC_URI to point at, I can send that patch19:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:57
*** d3xter <d3xter!c0a49d61@gateway/web/freenode/ip.> has joined #yocto20:04
d3xterhey guys, is this the right place to ask questions about matchbox-keyboard?20:04
*** nighty- <nighty-!> has quit IRC20:09
RPpaulbarker: sounds good, thanks!20:12
RPd3xter: yes, although the matchbox people are more likely to be around tomorrow20:12
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto20:14
d3xterRP: why is that? ^^20:20
*** ant_home <ant_home!~ant__@> has quit IRC20:25
RPd3xter: I just know who the matchbox knowledgeable people and when they're usually online, you want jku or rburton20:25
d3xterRP: ok, will ask tomorrow then. thanks :)20:28
*** ant_home <ant_home!~ant__@> has joined #yocto20:28
*** d3xter <d3xter!c0a49d61@gateway/web/freenode/ip.> has quit IRC20:37
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC20:50
*** Saur1 <Saur1!> has joined #yocto21:01
*** Saur1 <Saur1!> has quit IRC21:03
*** warthog9 <warthog9!> has quit IRC21:04
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC21:04
*** gtristan <gtristan!~tristanva@> has quit IRC21:07
*** warthog9 <warthog9!> has joined #yocto21:12
*** jwest__ <jwest__!> has quit IRC21:37
*** zecke <zecke!> has quit IRC22:14
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:18
*** jwest__ <jwest__!~jwest@2601:148:200:6f80:2548:f100:4eb0:4142> has joined #yocto22:30
*** sameo <sameo!~samuel@> has joined #yocto22:52
*** MWelchUK <MWelchUK!> has quit IRC23:03
*** Biliogadafr <Biliogadafr!> has quit IRC23:22
*** sameo <sameo!~samuel@> has quit IRC23:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC23:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:31
*** ant_home <ant_home!~ant__@> has quit IRC23:33
*** p0kerface|work is now known as BaloneyGeek23:35
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC23:38
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto23:41
*** dreyna <dreyna!> has joined #yocto23:55

Generated by 2.11.0 by Marius Gedminas - find it at!