**** BEGIN LOGGING AT Sun Apr 02 03:00:01 2017 Apr 02 04:00:01 kanavin: libdnf isn't version 0.2.3, it's on 0.8.1 right now Apr 02 06:49:00 RP, 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) works Apr 02 06:49:28 anyway, I can keep maintaining my downstream patch Apr 02 06:51:37 I 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) Apr 02 07:12:23 gtristan: I do remember that several of us have tried and failed to reproduce it :( Apr 02 07:50:31 morning guys Apr 02 07:51:14 could somebody help me with compilation error: http://ix.io/pw4 ? Apr 02 08:23:38 Ox4: looks like you're using 64 bit compiler flags with a 32 bit toolchain Apr 02 08:38:29 RP: file arm-linux-gnueabihf-gcc Apr 02 08:38:31 arm-linux-gnueabihf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=27933f002c76b6bb88e5a4c5ec3afdacd3392e0e, not stripped Apr 02 08:55:47 Ox4: the compiler is a 64 bit binary but that doesn't mean it can generate 64 bit binaries though Apr 02 11:30:21 Anyone else having problems with autoconf-native today on master? It's complaining that it can't find help2man during do_compile Apr 02 11:41:13 paulbarker: I'm not aware of issues fwiw Apr 02 11:42:10 RP: 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 where Apr 02 11:42:45 paulbarker: sounds like the story of my life recently :/ Apr 02 11:43:20 RP: 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 anything Apr 02 11:47:50 paulbarker: a build here seems ok fwiw Apr 02 11:51:33 Fixed it, but this looks like a recipe-specific sysroot issue Apr 02 11:51:47 I set up a new build with everything checked out on one drive Apr 02 11:52:10 sstate-cache, downloads and tmp symlinked to another bigger but slower drive Apr 02 11:52:55 Removing the 'tmp' symlink fixed it Apr 02 11:56:47 Setting TMPDIR to point at the other drive works, using a symlink in the build directory doesn't Apr 02 11:58:00 I think it's confusing PATH during certain tasks Apr 02 12:14:53 RP: 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 yet Apr 02 12:20:09 Linking tmp -> tmp2 is fine, linking tmp -> ../tmp causes failures Apr 02 12:20:20 I can open a bug if this is something we care about Apr 02 12:31:27 paulbarker: I think we'd just add a sanity check for this and error if someone does it Apr 02 13:38:46 RP: I have a build from scratch. I see the postinst warning. What did you do to know? Should I revert it and rebuild? Apr 02 13:39:32 the update_gio_module_cache saga I mean Apr 02 13:47:34 RP: after revert, anything about postponed packages in do_rotfs log Apr 02 15:39:02 I 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? Apr 02 16:02:41 ant_home: yes, please revert and then see if the postinst is still deferred Apr 02 16:03:17 zecke: that is basically recipe specific sysroots so a fairly big change Apr 02 16:06:21 RP: http://git.sysmocom.de/poky/meta-sysmocom-bsp/tree/recipes-core/images/image-rauc-ubi.bb?id=1b77777791ff2d19b6c53a81bd4b332fab72c339 is my recipe. it builds an ubi but is not an image Apr 02 16:06:57 RP: 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) Apr 02 16:07:24 RP: without mtd-utils-native:do_populate_sysroot mkfs.ubifs is failing... Apr 02 16:08:53 I 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 :) Apr 02 16:09:38 but the change is nice, it helps to reveal hidden dependencies nicely.. Apr 02 16:12:04 zecke: I think it sounds like its trying to pull in glibc-initial and gcc-cross-initial which have file overlap with gcc-cross and glibc Apr 02 16:12:47 zecke: 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 working Apr 02 16:13:31 http://paste.lisp.org/display/343262 Apr 02 16:14:19 zecke: right, libgcc-initial is the same issue Apr 02 16:16:04 zecke: FWIW the DEPENDS in that recipe doesn't do much since DEPENDS are applied to do_configure and you don't really depend on that Apr 02 16:16:13 (fetch is before configure) Apr 02 16:16:30 Direct dependencies are [... I seem to have glibc-initial and glibc-locale in it Apr 02 16:16:47 and most likely glibc-locale depends on glibc.. so I end up with both.. Apr 02 16:17:57 zecke: I don't understand now glibc-initial would become a direct dependency :/ Apr 02 16:18:46 zecke: you could try being more specific, e.g. virtual/kernel:do_build -> virtual/kernel:do_deploy Apr 02 16:18:59 image-rauc-rescue-initramfs:do_build -> image-rauc-rescue-initramfs:do_image_complete Apr 02 16:19:31 that might just be enough to stop it getting so confused Apr 02 16:19:33 http://paste.lisp.org/display/343262#1 for the copy of the first lines. if you want to have the rest I can copy it too Apr 02 16:20:20 zecke: try change the deps to what I've suggested above, I think understand why it thinks these are direct deps now Apr 02 16:21:18 RP: yes, direct dep is fixed.. but now mkfs.ubifs is not there. :( Apr 02 16:21:56 zecke: you kept mtd-utils-native:do_populate_sysroot in do_fetch[depends] ? Apr 02 16:22:10 yupp Apr 02 16:23:01 maybe I add for do_deploy as this is where I call mtd-utils-native/mkfs.ubifs Apr 02 16:23:30 zecke: just about to suggest that Apr 02 16:25:20 okay 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? Apr 02 16:25:59 Thank you. It is building now. And I will clean it up. Apr 02 16:26:05 zecke: Its either that, or that deploy is assumed to be an sstate task and is a semi-reserved name in that sense Apr 02 16:26:19 (usually enabled with deploy.bbclass) Apr 02 16:26:53 anyhow, glad you're somewhere close. I think we need to do something about do_build dependencies and -initial... Apr 02 16:27:09 happy to have found a corner case :) Apr 02 16:27:37 Yeah, 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 myself Apr 02 18:03:20 I 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: https://bpaste.net/show/8c1e7ff3bfc3 . Any comments to this recipe header? Apr 02 18:35:14 Looks 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? Apr 02 18:35:53 If I send a patch, will the downloads.yoctoproject.org mirror get updated when it's merged? Apr 02 19:04:51 I 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 exist Apr 02 19:07:38 The libray file exists in the recipe-sysroot Apr 02 19:09:53 Is there some extra config for cmake exported targets to work with yocto? Apr 02 19:51:44 paulbarker: tempted to change the url to our mirror Apr 02 19:51:57 paulbarker: I wish upstreams wouldn;t do this Apr 02 19:53:21 RP: I've locally changed SRC_URI to point at downloads.yoctoproject.org, I can send that patch Apr 02 20:04:57 hey guys, is this the right place to ask questions about matchbox-keyboard? Apr 02 20:12:34 paulbarker: sounds good, thanks! Apr 02 20:12:51 d3xter: yes, although the matchbox people are more likely to be around tomorrow Apr 02 20:20:02 RP: why is that? ^^ Apr 02 20:25:16 d3xter: I just know who the matchbox knowledgeable people and when they're usually online, you want jku or rburton Apr 02 20:28:31 RP: ok, will ask tomorrow then. thanks :) **** ENDING LOGGING AT Mon Apr 03 03:00:01 2017