**** BEGIN LOGGING AT Fri Feb 05 02:59:59 2016 Feb 05 03:16:02 kergoth the multiple sdkmachine worked in YP 2.0 Feb 05 03:16:17 (I don't think we've got any special patches for that).. Feb 05 03:16:45 did you test with linux and non-linux, but the same arch? i just tested 10 minutes ago with mingw32 and linux and it choked due to both binutils recipes being 'binutils-cross-i686' Feb 05 03:16:48 that is part of our normal toolchain build process.. simply adjust the SDKMACHINE and build.. the system wipes out the old binutils-crosssdk and generates a new (right one) for the switch Feb 05 03:16:57 ya.. typical test is 4 ways.. Feb 05 03:16:59 it didn't do that here Feb 05 03:17:11 SDKMACHINE={i686,x86_64,i686-mingw,x86_64-mingw) Feb 05 03:18:11 hmm, will try again Feb 05 03:21:00 ya.. typical build is for mach in ; do for sdk in ; MACHINE=$mach SDKMACHINE=$sdk bitbake -c populate_sdk ; done ; done Feb 05 08:40:11 kergoth: good idea. Usually how will we do it Feb 05 08:40:24 we do have TOOLCHAIN = "gcc" setting in bbappend Feb 05 08:48:29 khem: looking for advice on systemd, since you've upgraded it in OE a couple of times, I figured you might be the right person to ask Feb 05 08:49:07 I'm trying to make it more configurable, there's a number of switches that one can pass to cnfigure to enable stuff like machined, logind and so on Feb 05 08:49:44 i'm waging between enabling all of that and spliting it up into separate packages or just adding a bunch of PACKAGECONFIG flags with features Feb 05 08:51:17 not sure what is the preferred approach, from what I've seen Ross added systemd-binfmt as package rather than PACKAGECONFIG flag Feb 05 08:53:01 but then, stuff like coredup is enabled via PACKAGECONFIG flag (unset by default) and just packaged into systemd Feb 05 09:21:49 I Feb 05 09:22:00 I'm having an issue with yocto 2.0 Feb 05 09:22:19 hi alexlarsson Feb 05 09:22:43 I just built a core-image-miminal having just added Feb 05 09:22:45 CORE_IMAGE_EXTRA_INSTALL="bash glibc-binary-localedata-en-us" Feb 05 09:22:51 to the default generated config Feb 05 09:22:54 and i get: Feb 05 09:23:03 root@qemux86:~# export LC_ALL=en_US Feb 05 09:23:03 -sh: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. Feb 05 09:23:13 yeah i was hoping [Sno] would have posted his fix for that by now :) Feb 05 09:23:24 Oh, there is a fix? Feb 05 09:23:25 alexlarsson: https://github.com/rehsack/poky/commit/46ac36953e2e76ba716c7ba42ddfe41c9a19a11d Feb 05 09:23:27 * alexlarsson & desperate... Feb 05 09:23:39 <[Sno]> rburton: thanks for having it cached ;) Feb 05 09:23:52 [Sno]: left the tab open to remind me to pester you :) Feb 05 09:24:01 <[Sno]> still no tuit to send the mail :( Feb 05 09:24:07 alexlarsson: i've not tested that, but its certainly worth a try Feb 05 09:24:22 alexlarsson: if you can verify it now then i'll just take that and send it myself :) Feb 05 09:24:26 <[Sno]> we built a new field test release with that yesterday Feb 05 09:24:39 <[Sno]> after labor tests satisfied project lead ^^ Feb 05 09:25:40 i think there's a global scarcity of tuits right now :( Feb 05 09:26:02 [Sno]: am i missing something, or is the patch it references not in the commit? Feb 05 09:26:25 alexlarsson: the patch is already in the tree Feb 05 09:26:49 ah, i see Feb 05 09:26:59 <[Sno]> alexlarsson: that's the patch introducing the ABI breakage Feb 05 09:27:21 i see Feb 05 09:27:35 would be awesome if we didn't need the cross-localedef nasty Feb 05 09:27:38 it was added to glibc, so it needs to be added to the cross locale build too? Feb 05 09:27:47 yes Feb 05 09:28:34 * alexlarsson & rebuilding Feb 05 09:28:46 <[Sno]> but cross-building the locale-binaries with qemu isn't much better from resources point of view Feb 05 09:29:18 <[Sno]> less nasty for sure ... Feb 05 09:30:10 well it would be awesome if we didn't need to fork bits of glibc to do cross locale building Feb 05 09:32:09 did you ever try to get the locale cross build utils upstreamed? Feb 05 09:32:29 glibc upstream is said to be nice these days Feb 05 09:33:02 yeah that's something to be tried again Feb 05 09:33:16 khem would be the person to speak to, although he's all about musl these days :) Feb 05 09:33:52 I don't get why everyone is so excited about musl Feb 05 09:34:16 It doesn't seem to have enough support for things for e.g. desktop apps Feb 05 09:34:23 anyway, that patch fixed my issue Feb 05 09:34:39 and imho looks safe enought to merge Feb 05 09:34:55 but, then i'm just flailing around wrt yocto :) Feb 05 09:34:56 alexlarsson: khem has been running xfce on it Feb 05 09:34:59 hopeing something sticks Feb 05 09:35:11 alexlarsson: upgrading the ostree bootstrap? Feb 05 09:35:21 the xdg-app runtime Feb 05 09:35:25 to 2.0 Feb 05 09:35:49 which is nice Feb 05 09:35:52 cool Feb 05 09:35:54 dropped a bunch of custom stuff Feb 05 09:35:57 \o/ Feb 05 09:36:43 I'll add that patch to the meta-freedesktop layer for now Feb 05 09:37:24 Maybe i should try to upstream my overlay things at some point Feb 05 09:37:51 http://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/tree/meta-freedesktop/recipes-core/glibc/glibc Feb 05 09:37:54 like that one Feb 05 09:37:58 http://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/tree/meta-freedesktop/recipes-core/glibc/glibc/glibc-static-tls.patch Feb 05 09:37:59 i mean that Feb 05 09:38:40 looks like that shoud go upstream yeah Feb 05 09:39:11 its from the fedora kernel Feb 05 09:39:25 without it gl + python breaks with some mesa drivers Feb 05 09:40:30 http://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/tree/meta-freedesktop/recipes-devtools/make/make/make-handle-ttyname-fail.patch Feb 05 09:40:36 this one is a bit weirder Feb 05 09:41:16 it mainly fixes things for container use (where the real tty of a process is outside the container) Feb 05 09:41:43 SRC_URI_remove = "file://04-default-is-optimized.patch" Feb 05 09:41:53 I also had to do that in the python builds Feb 05 09:42:06 because it makes asserts a no-op... Feb 05 09:42:11 huh, i never knew we had that Feb 05 09:42:14 that sounds wrong Feb 05 09:42:22 yeah Feb 05 09:42:46 I also have to do this in bash: Feb 05 09:42:47 erm yeah that's just being deleted Feb 05 09:42:47 EXTRA_OECONF += "bash_cv_getcwd_malloc=yes " Feb 05 09:43:14 because it picks some alternative getcwd impl that doesn't work in a container otherwise Feb 05 09:43:30 alexlarsson: clearly mickey wasn't aware that python optimisation isn't optimisation Feb 05 09:43:30 libpcre: Feb 05 09:43:32 EXTRA_OECONF = "--enable-unicode-properties" Feb 05 09:43:44 needed for glib 2.46.2 Feb 05 09:43:56 why isn't that on by default? Feb 05 09:44:02 fuck knows... Feb 05 09:44:14 you should ask a glib maintainer Feb 05 09:44:18 … Feb 05 09:44:31 No no Feb 05 09:44:41 its needed in libpcre for glib to use the system copy Feb 05 09:44:46 so we dropped the optimise patch for python2 at some point, but it came back for py3 Feb 05 09:44:50 oh right, sorry Feb 05 09:45:01 you should send patches :) Feb 05 09:45:13 I guess Feb 05 09:45:15 bugzilla? Feb 05 09:45:40 I just don't know how important this stuff is to you. I'm not really doing "embedded" stuff Feb 05 09:45:57 well the py3 one is just a broken patch, that's stupid Feb 05 09:45:58 fixing now Feb 05 09:46:26 the bash one tingles my spidey sense as we were hitting malloc failures inside bash in QA Feb 05 09:46:43 pcre should be a packageconfig at least, and if the overhead isn't too much just enable by default Feb 05 09:47:20 Also, i have an EXTRA_OEMCONF to get python support in libxml2 Feb 05 09:47:32 There should be a nicer option for that Feb 05 09:50:33 hey guyz, short question Feb 05 09:51:13 alexlarsson: python should be enabled by default, or at least is in mater Feb 05 09:51:16 why would a do_fetch not get pass the CLOSE_WAIT state of the connection Feb 05 09:51:46 rburton: oh, maybe it changed since 1.8 which i updated from Feb 05 09:51:48 * alexlarsson & looks Feb 05 09:53:33 yeah, seems to be there Feb 05 09:53:38 * alexlarsson & deletes more Feb 05 09:54:24 alexlarsson: so without that pcre option glib is using its internal copy of pcre? Feb 05 09:54:34 rburton: yeah Feb 05 09:54:44 at least with 2.46.2 or later Feb 05 09:54:45 fiddle fiddle fiddle Feb 05 09:55:50 https://git.gnome.org/browse/glib/tree/configure.ac#n2332 Feb 05 09:57:22 actually, since forever Feb 05 09:57:38 it just auto-enables the use of a system copy with 2.46.2 Feb 05 09:58:57 --with-pcre=[internal/system] Feb 05 09:58:57 whether to use system PCRE [default=internal] Feb 05 09:59:00 the docs are wrong then :) Feb 05 09:59:30 oh, post 2.46.2, surely Feb 05 09:59:32 yeah, maybe its in 2.47 only Feb 05 09:59:56 i can get the groundwork in quickly though Feb 05 10:00:10 https://git.gnome.org/browse/glib/commit/?id=82c2461e3d719dfe11361c07502d1cf8a998c121 Feb 05 10:00:20 you should probably use --with-pcre=system anyway Feb 05 10:00:30 makes more sense for distro use Feb 05 10:01:12 yeah Feb 05 10:04:05 So, for libxml2-python i have to add PACKAGECONFIG=python in my layer? Feb 05 10:05:20 oh, no, its on by default Feb 05 10:07:34 Hmm, my bbappend has --with-zlib which is not in the default, so maybe i need a layer anyway Feb 05 10:08:43 Why is that not on the regular OEMCONF, but it is for the native one? Feb 05 10:19:55 rburton: want me to file bugs for these things? Feb 05 10:20:36 Hi all. I'm trying to get 'bitbake meta-toolchain-qt5' working for raspberrypi/2. I have tried a number of different patches currently flowing around, without success. It works when building without x11 and wayland, but I want to be able to run the qt applications from X.. Anyone that knows of any currently working tree to achive this (or any other good 'hacks' to get it working)? Feb 05 10:22:11 In my current tree it fails on: fatal error: interface/vmcs_host/wayland-dispmanx-server-protocol.h: No such file or directory Feb 05 10:25:39 alexlarsson: please Feb 05 10:42:20 enabling unicode properties in pcre makes a surprising difference to the binary size Feb 05 10:42:27 packages/corei7-64-poky-linux/libpcre/libpcre: PKGSIZE changed from 157544 to 272312 (+72%) Feb 05 10:49:21 rburton: yeah, but then you get to not have a copy of it in glib... Feb 05 10:49:30 oh yeah, sure Feb 05 10:49:35 just surprised it made such a difference Feb 05 10:49:45 so, how much smaller is glib with --with-pcre=system Feb 05 10:49:53 building now to find out Feb 05 10:50:01 touching pcre of course means perl wants to rebuild :) Feb 05 10:50:56 so, do i file against OE-Core product? Feb 05 10:51:06 when I use bash in a yocto-built rootfs, the left/right arrow keys don't work as usual. I have to do something like http://superuser.com/questions/488157/how-do-i-make-ctrl-arrow-keys-move-forward-backward-a-word-at-a-time-in-cygwin-b Feb 05 10:51:09 twisty maze of bugzillas, none alike Feb 05 10:51:20 is there a better way to do that other than to manually put in a config file? Feb 05 10:51:33 perhaps some packageconfig I missed? Feb 05 10:52:04 alexlarsson: build system and metadata -> oe-core Feb 05 11:03:00 rburton: no bug needed for the python optimize thing? Feb 05 11:12:01 I guess you're on the pcre thing too Feb 05 11:12:41 So, its pcre, locale crash, https://bugzilla.yoctoproject.org/show_bug.cgi?id=9066 and https://bugzilla.yoctoproject.org/show_bug.cgi?id=9067 Feb 05 11:12:42 Bug 9066: normal, Undecided, ---, ross.burton, NEW , Increase nr of static TLS slots Feb 05 11:12:43 Bug 9067: normal, Undecided, ---, paul.eggleton, NEW , make: don't crash if ttyname fails Feb 05 11:38:43 alexlarsson: that's right, thanks! Feb 05 11:41:21 alexlarsson: 176k down in glib library size Feb 05 11:41:45 net win! Feb 05 11:42:08 yeah Feb 05 12:58:33 I have a question about, the current toolchain of master branch, I see it uses musl instead of glib ? What is it the plan for the libc ? Feb 05 13:05:22 (I speak about the poky-tiny toolchain) Feb 05 13:15:32 yes, it moved to musl Feb 05 13:15:40 that's the plan Feb 05 13:18:56 rburton: ok, and poky (no tiny) will continue to use glibc ? Feb 05 13:19:57 yes Feb 05 13:20:05 by default, obviously Feb 05 13:20:08 you can do what you want Feb 05 13:20:43 a.k.a. "its only software" ;) Feb 05 13:21:41 rburton: fine, thank you for the quick answer. Feb 05 13:44:08 Hey all, what is the correct way to specify a branch to the git fetcher in a recipe? Feb 05 13:44:39 Ideally I'd like to check out a branch, but have it act like SRC_REV="${AUTOREV}" Feb 05 13:44:51 (just give me the latest of the specified branch) Feb 05 13:47:34 SRC_URI = " \ Feb 05 13:47:34 git://website/project.git;branch=development \ Feb 05 13:47:34 " Feb 05 13:59:07 Well sure it's obvious if you put it like that :) Feb 05 13:59:09 Thanks! Feb 05 14:01:43 One other question. I've got a recipe that depends on GNU readline - and I've added readline to my DEPENDS for the recipe, and readline is getting built fine, but my recipe still won't compile - it doesn't seem to see the header for readline. (ie passing -lreadline to gcc doesn't seem to turn up the library) Feb 05 14:01:50 what's the best way to go about diagnosing this? Feb 05 14:08:02 <_gpg_> hello everybody Feb 05 14:08:37 <_gpg_> anyone knows how to enable bootchart please ? i've already added bootchart but there's nothing in my /var/log (i'm also using system-d) Feb 05 14:12:54 It looks like bootchart is part of systemd now, you shouldn't need to enable anything Feb 05 14:13:07 do you have the bootchart-render binary on your target? Feb 05 14:14:22 Can you run systemd-analyze plot on your system and get output? Feb 05 14:15:31 It looks like the bootchart "classic" that's built into systemd can be enabled by passing it to the kernel command line, so it's going to depend on what bootloader you use Feb 05 14:16:28 you need to pass init=/usr/lib/systemd/systemd-bootchart on the kernel command line to enable boot charting, if you don't want to use systemd-analyze (which should just work with no configuration) Feb 05 15:15:27 khem: the fortify-strong patch disappeared from your branch, was that intentional? Feb 05 15:48:56 * kergoth yawns Feb 05 16:10:35 It looks like bitbake is trying to install a bunch of debug information in /usr/bin/.debug and my source code in /usr/src/debug Feb 05 16:10:46 have I told it to make a debug version of my package somehow? HOw do I prevent that? Feb 05 16:12:27 I have a custom do_install that only copies one file into ${bindir} Feb 05 16:12:41 I don't know why it would be installing all of these source files as well Feb 05 16:14:02 kergoth I know you know the answer and I know you're here cause you like, just yawned ;) Feb 05 16:21:14 ryansturmer: why would you want to prevent it? debug info is split out into separate binary packages, so is only installed if you want to do debugging. It's the best of both worlds, we get small binaries by default, but can install debug info to debug. inclusion of sources is done so you can examine sources in your debugger and view code at the line numbers it knows about. There's a variable you can use to disable inclusion of source Feb 05 16:24:04 I probaby wasn't clear, I'm getting 2 failures Feb 05 16:24:42 I'm getting an installed-but-not-shipped for stuff installed in the source directory Feb 05 16:24:49 /usr/src/debug/mypackagename Feb 05 16:25:05 then you have a package that is either missing the default ${PN}-dbg in the PACkAGES Feb 05 16:25:08 and I'm getting a non-debug-package contains debug directory Feb 05 16:25:19 or for some reason the stuff is being placed in the wrong location Feb 05 16:25:28 for the second item, you have a wild card/glob that is too broad.. Feb 05 16:25:33 easiest fix is usually Feb 05 16:25:52 ${PN}-dbg += "/.debug" Feb 05 16:26:08 I had that, but I didn't have the debug listed in packages Feb 05 16:26:12 since we're on that topic Feb 05 16:26:23 if I say FILES = "suchandsuch" Feb 05 16:26:29 that sets for all packages Feb 05 16:26:39 but FILES_${PN} just the package currently being built? Feb 05 16:26:47 FILES = should be ignored AFAIK Feb 05 16:27:09 FILES_ are processed in the order fromt he PACKAGES variable Feb 05 16:27:20 Well, any variable, not just files Feb 05 16:27:27 say, DEPENDS Feb 05 16:27:45 DEPENDS = "readline" means any package requires readline Feb 05 16:27:46 well, DEPENDS is build time so DEPENDS_${PN} doesn't make sense Feb 05 16:27:50 you have two classes of variables.. you have recipe level.. these follow the regular rules of overides.. Feb 05 16:28:03 and you have package variables.. they're -always- of the format _ Feb 05 16:28:22 there are a few cases where by itself will affect all packages, but don't count on that behavior.. Feb 05 16:28:53 rburton, yup.. which is why there is the RDEPENDS_${PN} because it's distinctly different then the recipe (source) dependencies.. Feb 05 16:29:02 ah ok Feb 05 16:29:22 indeed Feb 05 16:29:23 DEPENDS means one recipe depends on another recipe at build time, RDEPENDS_ is runtime, dependency from one binary package on another binary package Feb 05 16:29:23 everything you do in a recipe you need to ask.. does this affect the 'recipe (source)', or does this affect the output (packages) Feb 05 16:29:29 the docs do cover this ;) Feb 05 16:29:32 that will guide you to the vairable usage and for the formatting Feb 05 16:30:30 The docs are enormous, believe me when I say I don't come here until I'm exhausted combing through the docs Feb 05 16:31:00 can't win with docs can you :) Feb 05 16:31:20 you assked about depends, search for depends :P Feb 05 16:31:51 My question isn't about DEPENDS, it's about appending the package name to variables and when that's appropriate/why is it done? Feb 05 16:32:04 Oh well, also about DEPENDS Feb 05 16:32:13 that is the recipe vs package behavior.. Feb 05 16:32:17 it's appropriate when the variable is for the binary packages Feb 05 16:32:23 DEPENDS by definition is about the recipe Feb 05 16:32:26 RDEPENDS is about teh package Feb 05 16:32:28 I did sort that earlier question out from the docs. Feb 05 16:32:34 recipes don't get package names (they're irrelevant).. and package variables need to know which package is affected (so it's required) Feb 05 16:32:52 hmm pigz-native-2.3.3-r0 is failing to find native libz, it will be very short world build.. Feb 05 16:32:53 Right. Feb 05 16:32:57 I also think everyone should read http://www.aosabook.org/en/yocto.html at least once for the background Feb 05 16:33:01 one of the confusing issue to the variable syntax in OE is that "_" is used for more then one thing.. Feb 05 16:33:19 it's used as a seperator in a -single- variable.. it's also used as a seperator for an "override" Feb 05 16:33:35 yeah, true, worse yet when it's been both Feb 05 16:33:36 in the case of package related variables, it's simple a seperator, not an override Feb 05 16:33:47 like this case, we used to get recursions due to using the package name as a temporary override Feb 05 16:33:56 i htink it still doe sthat, actually.. but it shouldnt' :) Feb 05 16:33:58 I will read that book, thank you. Feb 05 16:34:02 I've certainly done things like: RDEPENDS_${PN}_append_class-nativesdk Feb 05 16:34:06 That page, rather. Feb 05 16:34:11 So, with FILES_ Feb 05 16:34:12 in that case, you have a sepertor, an operator and an override Feb 05 16:34:42 Oh oh Feb 05 16:34:46 but the 'variable' is 'RDEPENDS_${PN}', operator 'append' and override 'class-nativesdk' Feb 05 16:34:47 you're saying FILES = doesn't mean anything Feb 05 16:34:54 FILES does not do anything Feb 05 16:34:59 (because it specifies package files, per package) Feb 05 16:35:02 FILES_ does stuff Feb 05 16:35:17 but FILES_${PN} says "Ship these files for ${PN} package" Feb 05 16:35:21 got it. Feb 05 16:35:45 yes.. Feb 05 16:38:33 so I added ${PN}-dbg to my PACKAGES variable Feb 05 16:38:56 so PACKAGES="${PN} ${PN}-dbg" Feb 05 16:39:09 rburton: there is a bug in gcc patch I posted Feb 05 16:39:35 rburton: thats causing g++ use a tonne of memory when compiling cmake and webkit Feb 05 16:39:39 you should really just avoid overriding PACKAGES when you dont' need to Feb 05 16:39:43 I am posting a v3 soon Feb 05 16:39:43 khem: what one? Feb 05 16:39:45 the default is probably just fine Feb 05 16:39:51 0051 Feb 05 16:40:34 ok, retracted Feb 05 16:40:45 Well that fixed it. Feb 05 16:40:49 rburton: I have ported a new pu Feb 05 16:41:03 rburton: may be you should drop my v2 Feb 05 16:41:07 and use v3 series Feb 05 16:41:27 I have flip flopped on fstack-protector-strong Feb 05 16:41:38 since earlier I suspected that change to be the root cause of this Feb 05 16:41:38 ok Feb 05 16:41:57 so in v3 I change it back to strong Feb 05 16:42:21 doing world builds for glibc/musl and 6 architectures takes a hell lot of time Feb 05 16:42:27 :) Feb 05 16:42:43 I wish I did not hack so deep components Feb 05 16:43:07 yeah it does Feb 05 16:43:17 its more annoying when you touch a library that causes gcc to rebuild Feb 05 16:43:39 today i was rebuilding libpcre a few times, and that causes perl/python/rpm to rebuild which was quite boring Feb 05 16:43:57 rburton: http://errors.yoctoproject.org/Errors/Details/32754/ Feb 05 16:43:57 is new Feb 05 16:44:10 did we add something to QA checks Feb 05 16:44:35 rburton: and all I have is one box Feb 05 16:44:47 well another one is a VM on my mbp Feb 05 16:44:52 which counts for nothing Feb 05 16:44:59 khem`: we added a new test but none of those are it Feb 05 16:45:17 the arch test needs to decode numbers to names Feb 05 16:45:46 hm that libgcc thing, i've seen before Feb 05 16:46:03 stupid brain forgetting things Feb 05 16:46:19 ERROR: QA Issue: Architecture did not match (183 to 40) Feb 05 16:46:29 libgcc_s.so is sometimes dlopened Feb 05 16:46:38 and shlibs wont catch it Feb 05 16:46:49 especially the unwinder stuff Feb 05 16:47:02 oh there was a bug in the pkgdata expansion Feb 05 16:47:06 is that based on master? Feb 05 16:47:29 (oe-core 654f0eec426e882e50f688f6d097d992e34e5b40) Feb 05 16:47:29 where I've seen it is a multilib gcc, it produces both a 32-bit and 64-bit libgcc_s.so during compilation Feb 05 16:47:47 khem`: if it were dlopened you wouldn't get that warning Feb 05 16:47:51 both get packages, and thats when the QA runs through and sees a binary for the "not what I targets".. Feb 05 16:48:02 it's not a dlopen issue, it's that it really did build a binary for the wrong architecture Feb 05 16:48:27 rburton: yes latest master Feb 05 16:48:41 rburton: I was thinking of the thread on ml Feb 05 16:48:44 about libgcc Feb 05 16:48:53 my issue is related to arch mismatch Feb 05 16:49:34 #define EM_AARCH64 183 /* ARM AARCH64 */ Feb 05 16:49:41 #define EM_ARM 40 /* ARM */ Feb 05 16:50:05 ya.. it's exactly what I thought.. you built a (target) gcc that supports both -m32 and -m64.. so it built two internal versions of libgcc_s.so one of which is not for the same architecture.. Feb 05 16:50:15 I thought we have a QA SKIP for that error in the gcc sources already Feb 05 16:50:20 (for this exact reason) Feb 05 16:51:18 khem`: if you don't mind i'm going to split up that security flags patch as its grown a bit. when the commit message needs a table of contents you know its too long ;) Feb 05 16:51:21 Thanks guys for your help. Got everything working. Feb 05 16:51:28 khem`: i noticed that meta-clang *adds* clang, but doesn't remove the dependency on gcc for TOOLCHAIN=clang recipes, testing a change to do that locally Feb 05 16:51:41 s/clang/the clang-cross dependency/ Feb 05 16:51:58 kergoth: yes certain Feb 05 16:52:15 aspects are not ironed out Feb 05 16:52:25 np, just wanted to make sure it was on the radar :) Feb 05 16:52:28 since we dont have a minimal image where I can avoid gcc Feb 05 16:52:32 kernel needs it Feb 05 16:52:38 * kergoth nods Feb 05 16:52:40 so there was no point to attack it Feb 05 16:52:43 as of now Feb 05 16:52:58 but patches are welcome Feb 05 16:53:02 i was just trying to see what in my build was built with gcc, so i figured i'd check -g, and it didn't show anything useful :) Feb 05 16:53:03 more hands are better Feb 05 16:53:06 * kergoth nods Feb 05 16:54:49 fray: its happening in boost Feb 05 16:55:05 rburton: are you going to pick the kraj/pu Feb 05 16:55:19 or should I send it to list Feb 05 16:55:28 khem`: picking now Feb 05 16:55:35 ok thx Feb 05 16:55:56 khem, if boost is doing it, sounds like it's trying to play the multilib game as well Feb 05 16:56:13 fray: yeah but it did not do it before Feb 05 16:56:18 so i think its some Feb 05 16:56:27 race that makes it so Feb 05 16:56:48 could be.. I know very early int he YP development we had a lot of problems with boost on IA trying to build both 32-bit and 64-bit.. but those got squashed.. Feb 05 17:13:07 fray: for arm do you do ILP32 Feb 05 17:17:38 khem: can you check the security_flags patches in poky-contrib:ross/mut, it bothered me that the commit was getting so varied so i split it up :) Feb 05 17:19:06 rburton: ok Feb 05 17:20:34 rburton: thats how I wanted it :) Feb 05 17:20:38 +1 Feb 05 17:20:50 thanks Feb 05 17:21:04 if you change that branch again please rebase on that :) Feb 05 17:21:07 g++ is running OOM on webkit Feb 05 17:21:10 again Feb 05 17:21:15 I wonder whats going on Feb 05 17:21:22 I guess I need to try it on a different machine Feb 05 17:21:36 I switched the machine to use 4.2 kernel Feb 05 17:21:42 and that might have done it Feb 05 17:34:43 If I have a package that contains a script that has a shebang line that refers to something that I don't install (for instance /usr/bin/perl) Feb 05 17:35:03 I get a message indicating that I should add it to the RDEPENDS Feb 05 17:35:09 yes Feb 05 17:35:22 you have a script that uses perl and you don't depend on perl, so your script won't work :) Feb 05 17:35:41 It's just a warning, but if this is a script that's not used by my package, short of removing it, is there a way to avoid the warning Feb 05 17:35:43 you can either ignore the warning (INSANE_SKIP) or put that script in a separate package you don't install Feb 05 17:35:52 ok Feb 05 17:35:59 I will go read about INSANE_SKIP Feb 05 17:35:59 (which can then depend on perl without pulling it in to your image) Feb 05 17:36:05 It sounds crazy. Feb 05 17:36:18 you're install a perl script, so it's kind of useful that perl is present for it to run :) Feb 05 17:36:43 Right right - this is a utility script inside a package I depend on, thats essentially never going to get used on the target system Feb 05 17:36:59 splitting it into another package you don't install is fairly common Feb 05 17:37:00 there are several such scripts, and it's a tremendous amount of trouble to go remove them all Feb 05 17:37:38 roger. Thanks, that answers my question! Feb 05 17:44:27 khem`: https://gist.github.com/kergoth/d588dae2f34e042ee346 seems to work for me, built core-image-base and minimal, but still has limited testing, so not submitting it yet Feb 05 17:44:39 just as an fyi Feb 05 17:45:59 seems ok Feb 05 17:46:10 dont see any downsides Feb 05 17:52:57 i was thinking we should fix basedepends, instead of doing the check for INHIBIT_DEFAULT_DEPS in the function, we should just make it so anything in basedepends is appended if inhibit default deps isn't set, so it'd be easier to add default base deps Feb 05 17:53:02 i.e https://gist.github.com/kergoth/638a47f50aa781c60cc6 Feb 05 18:28:51 hi guys Feb 05 18:31:08 when using an fsl-community-bsp stack of layers (and not usually in other cases) I get error messages like "Computing transaction...error: Can't install XXXX@cortexa9hf_vfp_neon: no package provides YYYY" when trying to build core-image-{sato,minimal}. Feb 05 18:31:39 The XXXX and YYYY vary a bit; most recently its been python3-xml and python3-elementtree, resp. Feb 05 18:44:25 Hey, kergoth, thanks for the help yesterday. That was precisely where my problem was. Feb 05 18:48:18 wyrm: np Feb 05 19:21:38 ... the issue is usually resolved with bitbake XXXX -c cleansstate. This situation sound familiar to anyone? Feb 05 19:25:28 is there any way to fail the build early when package signatures change due to "unnatural" causes? Feb 05 19:25:47 you can lock them down entirely, but what exactly is 'unnatural'? Feb 05 19:29:01 kergoth: basically, when a generic package gets rebuilt/repackaged for different machines, but it's not machine-specific itself. Feb 05 19:29:29 If you're doing a multi-machine build, that will trigger errors due to the conflict in the sysroot Feb 05 19:29:40 I suspect until we have a 'parallel' machine build implemented -- we won't have an easy way to detect that Feb 05 19:29:52 kergoth: more pointers for locking them down? Feb 05 19:30:24 fray, kergoth: well, in some cases it gets back later on with "PR went backwards" error... Feb 05 19:30:41 pr can go backwards for all sorts of reasons Feb 05 19:30:46 that indicates that the checksum changed in a way that the PR server says you've reverted to an earlier build.. Feb 05 19:30:46 it doesn'mt mean this sort of problem necessarily Feb 05 19:30:52 ya.. Feb 05 19:31:09 if you really want to look fo rthe problem.. lock down the checksums.. and then look for the erorrs? when they change.. Feb 05 19:31:09 build one builds one way, another builds another, pr got bumped going from former to the latter, then you go back, for wahtever reason, and it uses that version from ssttate instead of bumping pr again Feb 05 19:31:32 that of course requires you to do one build, lock it down (common components), then do subsequent "other machine" builds. Feb 05 19:31:45 kergoth, fray: yeah, I know. that's why I'm looking for a way to spot signature changes early on Feb 05 19:32:21 if you want to spot every signature change, then lock it down. Feb 05 19:32:39 i don't see that bitbake has a magic way to know which signature changes are okay and which arent' Feb 05 19:33:04 ya, it can just compare lock down vs what it wants and bitch Feb 05 19:33:34 kergoth: well, unless the recipe itself got changed, right? Feb 05 19:33:50 or a class, or a config file, or any of its dependencies, or.. Feb 05 19:33:52 any of those are valid Feb 05 19:34:40 one thing I'm used to seeing a culpret.. someone has made a mistake in the machine config file and made some 'distribution' setting changes.. Feb 05 19:34:48 that effectively invalidates large bits of the system.. Feb 05 19:34:56 there is nothing to stop them, other then detection.. Feb 05 19:35:15 if we eventually get parallel (single project) multi-machine.. we can then identify when the checksums for common components change and report it.. Feb 05 19:35:22 until then the lock-down approach is the best I can think of Feb 05 19:36:36 fray, kergoth: ok, makes sense - I'll move in that direction for now then. thanks Feb 05 19:57:03 bah, recipetool newappend doesn't work in cases where the recipe isnt' currnetly seen as an eligible provider. that's irritating. in thise case i want to append it to make it eligible :) Feb 05 19:57:09 might need a better way to map from name to recipe Feb 05 20:24:32 ... and then other times -c cleanstate (even of both XXXX and YYYY) is not enough. Feb 05 20:25:29 is there some other relevant information I could dig up? bitbake 1.22.0 ? are there any keywords someone could recommend I search through commits for? Feb 05 20:52:54 (right now is one of the times where the cleansstate is not working) Feb 05 21:45:38 sjolley: maybe you know the answer to this? Feb 05 21:46:13 is it worthwhile to upload in-progress slides or just wait until they're finished? Feb 05 21:50:15 probably not... Feb 05 21:50:26 *i'll just wait Feb 05 21:56:39 khem: https://gist.github.com/kergoth/14715e1f0e08e07e1fec may be of interest, WIP, still doing test builds Feb 05 21:56:46 * kergoth ponders Feb 05 21:57:47 interesting yes Feb 05 21:58:43 oddly nativesdk.bbclass has NATIVESDKLIBC seemingly with an eye toward making libc switching for the sdk possible, but everything else hardcodes glibc Feb 05 22:02:03 hmm, i must have messed something up, linux/types.h isn't in the sysroot after building gcc-crosssdk-i686. meh, will revisit later Feb 05 22:15:48 who needs types with today's "modern" languages anyway? Feb 05 22:16:04 wait and see if anyone misses them... Feb 05 22:17:43 i hate when my compute rmakes a noise, and i have no idea what app did it or why Feb 05 22:17:45 what dinged? Feb 05 22:22:02 ah, musl doesn't pull in linux-libc-headers, that explains it Feb 05 22:27:45 hmm, that's odd Feb 05 22:35:09 hmm, recipetool-newappend needs a -e arg to just spawn $EDITOR for me Feb 05 22:53:20 Hmm, WARNING: ../tmp/sstate-control/manifest-i686_linux-musl-nativesdk-libgcc-initial.populate_sysroot not found Feb 05 22:53:23 wonder what that's about **** ENDING LOGGING AT Sat Feb 06 02:59:58 2016