**** BEGIN LOGGING AT Fri Sep 18 02:59:58 2015 Sep 18 04:54:31 Crofton: You there? Sep 18 08:31:27 good morning Sep 18 08:31:31 mornin Sep 18 10:07:06 hmm, how is it possible that some packages that did build fine with thumb configuration for arm5 on yocto 1.7 fail to build on yocto master/2.0, but do work if I disable thumb for them? Sep 18 10:07:57 for example the unmodified "icu" recipe from poky does not build with enabled thumb ARM_INSTRUCTION_SET for armv5 but does build if I switch the instruction set o "arm" Sep 18 10:08:09 and I have the same with one of my own custom packages Sep 18 10:27:42 Jin^eLD: Sep 18 10:28:35 sorry... wrong combination of keys.. Sep 18 10:28:44 damn! :) Sep 18 10:28:55 and I was already hoping for a hint ;) Sep 18 10:30:05 hehe Sep 18 10:34:03 I seem to recall JaMa's been dealing with this a bit, but he's not around Sep 18 10:34:16 don't know the details myself Sep 18 10:35:14 I'll ping him then when he arrives, thanks Sep 18 11:21:48 gstreamer1.0-plugins-bad has gdk-pixbuf in its default packageconfig list. also, the x11 elements from gstreamer1.0-plugins-bad are added to the default list only if x11 is amongst the distro features. so far so good. Sep 18 11:22:02 but, the gdk-pixbuf recipe has this line: DEPENDS_append_linuxstdbase = " virtual/libx11" Sep 18 11:22:33 so, if gdk-pixbuf is in the gstreamer1.0-plugins-bad packageconfig list, but x11 is _not_ in the distro features, this will lead to build errors Sep 18 11:22:50 now what would the proper solution be? can gdk-pixbuf work without x11? Sep 18 11:38:57 dv_: linuxstdbase is an active override in your configuration? Sep 18 11:40:11 i don't know. it didn't happen to me. I got a mail with this error, and that is when I noticed this in the gdk-pixbuf recipe. Sep 18 11:41:46 I would have thought it unusual... that line is only going to do anything if linuxstdbase is in OVERRIDES Sep 18 11:42:26 (linuxstdbase is for LSB, in case it's not clear - it's what we use to set various things in recipes in order to satisfy LSB spec requirements) Sep 18 11:44:12 okay, but shouldnt it be more like: DEPENDS_append_linuxstdbase = " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11', '', d)} " ? Sep 18 11:44:46 in case I want "LSB minus x11" Sep 18 11:45:11 actually I think at least with what we have in the master version of the recipe, that line is redundant - PACKAGECONFIG already adds virtual/libx11 to DEPENDS when x11 is in PACKAGECONFIG Sep 18 11:45:29 I haven't read the spec recently, but is there really any such thing as "LSB minus x11" Sep 18 11:45:31 ? Sep 18 11:46:04 oh! true. Sep 18 11:46:12 PACKAGECONFIG_linuxstdbase = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} ${GDK_PIXBUF_LOADERS}" Sep 18 11:57:50 JaMa: ping Sep 18 11:58:10 JaMa: I heard you had some compile problems with some packages for arm in regard to thumb/non thumb instruction set Sep 18 11:58:37 I'm currently puzzled by a similar issue and was wondering if you could give me a few hints Sep 18 12:11:33 Jin^eLD: yes, there are many issues in oe-core recipes Sep 18 12:11:50 JaMa: how did you solve them? the interesting thing is that I did not have these problems with yocto 1.7 Sep 18 12:11:58 now I am switching to 2.0/master and suddenly it does not work anymore Sep 18 12:12:07 you can see fixes in jansa/master branch or https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717 Sep 18 12:12:26 Jin^eLD: because you didn't have thumb really enabled in 1.7? Sep 18 12:12:38 Jin^eLD: and are you using thumb1 or thumb2? Sep 18 12:12:45 arm5 so thumb1 I guess Sep 18 12:12:53 the ipk dirs were called armv5te though? Sep 18 12:13:56 but wait, so the only real fix is to change the instruction set (thats what I did considering it a hack) Sep 18 12:13:59 ? Sep 18 12:14:43 and can you please confirm that although the build summare showed thumb in TUNE_FEATURES and although on 1.5 as well as on 1.7 the ipk's were put into armv5te and not in armv5e - it was not building thumb? Sep 18 12:14:51 s/summare/summary/g Sep 18 12:15:55 yes, I can confirm that Sep 18 12:16:15 you can check your CC variable and it didn't have -mthumb for sure if you didn't set ARM_INSTRUCTION_SET in your distro Sep 18 12:16:54 no I did not... but why were the packages marked as armv5te then, was this a bug? Sep 18 12:17:31 sort of bug and sort of limitation of how old toolchain worked Sep 18 12:17:38 I see... Sep 18 12:17:50 ok, these are some findings :) Sep 18 12:17:51 thanks Sep 18 12:18:08 before using the same toolchain path for multiple DEFAULTTUNEs you would need to mangle the paths to TC or build separate TC for building arm and thumb :) Sep 18 12:18:32 more details are in commits where I've changed this Sep 18 12:18:43 and even more on ML if you're interested in details Sep 18 12:18:54 ok I might read up the archives Sep 18 12:18:59 thank you for the explanation! Sep 18 12:19:09 this indeed clears up the confusion I had Sep 18 12:57:32 WARNING: QA Issue: perf: Files/directories were installed but not shipped in any package: Sep 18 12:57:44 perf packaging is missing some python related files Sep 18 13:19:11 hmm, maybe even already fixed :) Sep 18 13:48:41 Hmm Sep 18 13:48:50 There's not some flag I'm missing that would split -dbg and -src packages out, yes? Sep 18 13:52:17 rather than -dbg which has both .debug dirs and srcs Sep 18 13:52:25 (I see you can toggle having one or the other) Sep 18 13:53:37 the -dbg package sources aren't complete sources though Sep 18 13:54:20 there is no flag to have the debug sources split into a different package; you can turn off putting those sources into the packages altogether though Sep 18 13:54:53 PACKAGE_DEBUG_SPLIT_STYLE is the variable that does the latter Sep 18 13:56:24 Yeah Sep 18 13:56:44 ok, if we have a longer term need for .debug and not sources I'll make something useful then Sep 18 18:11:37 this is a little bit off topic, but debugging an initramfs, and STDOUT goes to LCD, but not serial console. Is there any way to get it to go to both? Sep 18 18:13:05 cbrake: i *think* you can specify multiple console= lines in the kernel cmdline Sep 18 18:13:16 worth trying, anywya. e.g. console=tty0 console=ttyS0,115200 or whatever the syntax is Sep 18 18:13:43 kergoth: yeah, that is what I have, and from kernel space that works great Sep 18 18:13:58 however, once /init starts in my initramfs, stdout only goes to tty0 Sep 18 18:14:30 (as well as stderr) Sep 18 18:14:39 ah, interesting Sep 18 18:15:00 kergoth: yeah, its been this way on the last 3 projects, but I've gotten by with 2>/dev/kmsg tricks Sep 18 18:15:05 kergoth: but its getting old Sep 18 18:15:09 no idea beyond that, let me know if you figure it out, though, that'd be handy :) Sep 18 18:15:27 kergoth: it used to work, so not sure if something changed in the kernel, or what is going on Sep 18 18:41:40 kergoth: this seems to work: exec 3>&1 4>&2 >/dev/kmsg 2>&1 Sep 18 18:42:13 kergoth: but would still like to understand how to do it outside my /init script Sep 18 18:47:46 hmm, what compiles the dtc file into a dtb file? Sep 18 18:48:25 Crofton: dtc(1) from device-tree-compiler Sep 18 18:48:32 that I know :) Sep 18 18:48:44 but bitbake what runs dtc :) Sep 18 18:49:16 linux-dtb.inc Sep 18 18:49:20 Crofton in a kernel build, the kernel runs dtc Sep 18 18:49:27 * kernel build Sep 18 18:49:28 weird Sep 18 18:49:34 scripts/dtc Sep 18 18:49:37 bitbake linux-xlnx didn't do that Sep 18 18:49:53 you have to include the inc for it to have an effect Sep 18 18:50:44 hmm, need to do some more thinking, nuke tmp, and email customer with issue Sep 18 18:50:49 Crofton you could look in arch/arm/dts/Makefile, to make sure there are DTS bits specified for your CONFIG Sep 18 18:50:52 and then ride bicycle Sep 18 18:51:15 I'm having trouble duping an issue a customer sees Sep 18 18:51:27 and I suspect he hasn't given me all the facts Sep 18 19:11:24 Crofton: define KERNEL_DEVICETREE in the machine and include linux-dtb.inc in the recipe Sep 18 19:11:51 that reminds me, i need to make it so mel's kernel_add_dts recipetool command adds the .inc.. the scriptutils function we're calling doesn't support it Sep 18 19:11:59 hmm Sep 18 21:01:44 Any meta-browser people in here? Chromium appears to be broken on master due to gcc >= 5. I suppose it probably makes more sense to upgrade it to the newest stable version rather than trying to fix the current version? Debian is on 45.0.2454.85 maybe I'll try upgrading it to that? Sep 18 21:14:32 georgem: heh, gcc 5.2 has broken a lot of stuff, lots of fixes being done Sep 18 21:14:46 yeah Sep 18 21:15:19 Just planning on trying (at least to make an effort) to fix anything I stumble across Sep 18 21:19:48 * kergoth nods **** ENDING LOGGING AT Sat Sep 19 02:59:59 2015