**** BEGIN LOGGING AT Tue Dec 18 02:59:58 2012 Dec 18 08:39:10 good morning Dec 18 08:47:42 good morning Dec 18 09:05:03 morning all Dec 18 09:05:15 JaMa: thanks for your recent cleanup work :) Dec 18 09:06:56 bluelightning: you're welcome Dec 18 09:07:22 bluelightning: what do you think about archiving patchwork entries after they are assigned to some bundle? Dec 18 09:07:35 bluelightning: and can you assign some patches to those bundles I've shared? Dec 18 09:07:41 JaMa: I think that's a great idea Dec 18 09:07:47 JaMa: sure thing Dec 18 09:08:08 I mean, do you have permission to add patches there (when I've marked them as public) Dec 18 09:09:29 JaMa: hopefully Dec 18 09:09:44 bluelightning: now with only one page of failures from world build it makes more sense to add bitbake world to jenkins :) Dec 18 09:10:28 JaMa: I think you're right re not being a place where public bundles are listed Dec 18 09:17:37 morning Dec 18 09:17:55 JaMa: congratulations on new role Dec 18 09:18:34 hehe, thanks Dec 18 09:21:51 JaMa: speaking of patchwork... I can not find my patch "florence: move to meta-gnome" neither in meta-oe git tree or patchwork Dec 18 09:22:27 hrw: patchwork does not pick moves with -M correctly, maybe I've missed it too Dec 18 09:22:35 ah, ok Dec 18 09:22:55 yup not on pw Dec 18 09:23:53 can you merge it? Dec 18 09:25:23 I don't have it in my maildir anymore, do you know about ML archive with usable UI? or can you resend it to me? Dec 18 09:25:44 I can Dec 18 09:25:50 well pipermail will probably work for -M patch :) Dec 18 09:26:05 mmt trying Dec 18 09:26:44 sent Dec 18 09:26:52 ah please send it to me or ML, thanks Dec 18 09:26:56 :) Dec 18 09:27:20 brb Dec 18 09:27:44 now only 4 entries left to be merged in oe-core Dec 18 09:49:20 possible race condition in sanity check (after tmp-eglibc/* was removed) http://paste.debian.net/216953/ Dec 18 10:38:35 levonmaa: maybe we need the same fix for qt5-native, qtjsbackend-native fails the same Dec 18 12:51:25 levonmaa: also you're touching ${STAGING_DATADIR}/${QT_DIR_NAME}/mkspecs/features/qt_module.prf from do_configure, that's bad for sstate Dec 18 13:55:44 bluelightning: what about the PR server? Dec 18 13:56:32 ant_work: I haven't been directly involved... Koen says Angstrom is using it already Dec 18 13:56:57 does it mean we can remove all trace of PR in our layers? Dec 18 13:57:08 no Dec 18 13:57:43 it's a bit early to be doing anything differently yet Dec 18 13:57:49 then where is the improvement? Dec 18 13:57:55 but in a short time we should be able to stop touching PR Dec 18 13:58:12 ant_work: read "[OE-core] Switch to PR server model for PR bumps - 1 week" Dec 18 14:03:25 JaMa: I somehow interpret RP intentions are to remove PR from recipes as rule Dec 18 14:03:42 I'll read all thread later Dec 18 14:03:47 thx for the link Dec 18 15:34:52 often when I change a rather involved recipe, I end up with a situation where I can build all my packages but the build fails during the do_rootfs with the following message: "satisfy_dependencies_for: Cannot satisfy the following dependencies for ." Is there a standard practice for solving this issue? I tried to look at the dependency graph and increase the PR for everything that seemed to relate to the packages it prints out after this message, to no a Dec 18 15:35:49 just recipes which are rdepending on renamed package Dec 18 15:35:58 you can grep Packages files in deploy/ipk Dec 18 15:38:45 hm when I grep Packages for this particular package its not there Dec 18 15:38:58 oh whoops sorry wrong folder Dec 18 15:42:16 JaMa: the problem is that we added a few drivers to the mesa-dri package, and it creates these sort of "meta" packages for each driver. The one I am having trouble with is the "mesa-dri-driver-radeon" saying that my top task can't satisfy dependencies for that package, but in the Packages file nothing actually shows up as depending on that package Dec 18 15:42:43 things DO depend on mesa-dri (the recipe that creates this package) and I increased the PR on that, and rebuilt it, but still have the same result Dec 18 15:44:05 I see that it shows up in the Packages "Depends" but there is not entry for it Dec 18 15:44:19 as well as the Recommends Dec 18 15:49:29 mbroadst: the Depends/Recommends for which other package? Dec 18 15:50:44 mbroadst: this sort of thing will occur if recipe A depends on something satisfied by recipe B's PACKAGES_DYNAMIC (which is often the case for dynamically packaged modules) but then when recipe B is built, it doesn't create that package (or it is empty, which amounts to the same thing) Dec 18 15:51:52 well that's the rub Dec 18 15:51:57 the packages are being created Dec 18 15:52:09 well the ipks are Dec 18 15:52:20 but its the Packages file that seems to not be updated Dec 18 15:53:07 build package-index Dec 18 15:53:22 but it should be updated during do_rootfs (before that failure) Dec 18 15:53:29 I've tried a number of things, including increasing the PR on all seemingly related packages (determined by printing the dot dependency graph, as well as just by hand), and subsequently just doing -c cleanall on each of them Dec 18 15:55:43 mbroadst: you need to find where it is in the metadata where this dependency is added and clear that, I don't think anything else is going to help Dec 18 15:56:16 for most of you is one thing obsolete and irrelevant but I can not find one that will fill a kernel 2.6.x which then take my inspiration to create a BSP Dec 18 15:56:39 I tried meta-handhels Dec 18 15:56:44 akita -> ok Dec 18 15:56:51 hx4700 -> ok Dec 18 15:56:58 h3600 -> fails Dec 18 15:57:17 h3600 is 2.6.29 Dec 18 15:58:08 I wonder if it could be a gcc (4.7.2) issue with older kernels Dec 18 15:59:28 any clue? Dec 18 15:59:31 bluelightning: hmm I see, okay. Is there a way to run just that last step. Currently this thing happens after about 45min of building and then just fails at the last second Dec 18 15:59:51 oh I guess I can just do the do_rootfs huh Dec 18 16:00:14 mbroadst: that's all it'll run the second time anyway Dec 18 16:00:42 not in the case that PRs were changed, that was causing lots of rebuilds Dec 18 16:01:06 yes, that would Dec 18 16:01:21 mckoan: afair, kernels < 2.3.35 have problems with gcc 4.6+ due to a changed __packed handling Dec 18 16:02:32 isn't -mno-unaligned-access enough to fix it? Dec 18 16:02:44 ensc|w: you probably mean < 3.3.35, don't you? Dec 18 16:03:02 the thing ending with .35 ;) Dec 18 16:03:03 and it was only in 4.6+ with some extra patches (from toolchain-layer) Dec 18 16:03:45 JaMa: no; afair some usb register structures were declared __packed and gcc accessed the registers bytewise then Dec 18 16:04:01 -maligned-access would have fixed it ;) Dec 18 16:04:24 so I argue that oe-core won't support kernel 2.6.x based BSP Dec 18 16:05:49 bluelightning: ah I see what the problem was, there is a mesa-dri.inc file in openembedded-core/meta/recipes-graphics/mesa/mesa-dri.inc that has: DEFAULT_PREFERENCE = "-1". So we created one in our layer and set the preference to "1". that previous include file specifies some drivers that we no longer indicate should be built Dec 18 16:05:51 we should probably consider that a bug if that's the case Dec 18 16:05:57 (re 2.6 kernel support) Dec 18 16:06:12 mbroadst: ah, right Dec 18 16:06:24 I guess I thought setting our preference to 1 would fully override the previous file? Dec 18 16:07:14 mbroadst: DEFAULT_PREFERENCE only affects which recipe is selected Dec 18 16:07:28 mbroadst: inc files are found only by looking through BBPATH Dec 18 16:07:43 I see Dec 18 16:07:50 ensc|w: https://github.com/shr-distribution/linux/commit/3ee21899d953f8a3f0736eba3a01aedce3641e8a is what we're using since that patch was introduced in toolchain-layer Dec 18 16:09:23 or this saying which gcc patch needs that https://github.com/shr-distribution/linux/commit/0333777365bef05b336d4f4a06bb3b37f4ada838 Dec 18 16:09:33 __packed fixes are 139540170d9d9b7ead3caaf540f161756b356d56 Dec 18 16:10:16 JaMa: I know that bootloaders/early booting does not support unaligned access because mmu is not enabled yet or code is executed in sram which is mapped as ordered memory Dec 18 16:11:25 and he is trying to boot it only, isn't he? Dec 18 16:12:14 but true, he needs both patches later :) Dec 18 16:12:20 JaMa: which arch is crespo? Dec 18 16:17:31 armv7a Dec 18 16:23:53 mckoan: I'm also using 2.6.39 with latest gcc on armv4t (om-gta02) Dec 18 16:26:17 JaMa: great, which meta is? Dec 18 16:31:36 JaMa: I do not know why unaligned access makes problem on crespo (I highly suspect that video memory is mapped as ordered memory there). But generally, unaligned access works perfectly fine in "normal" kernel (no early bootstage) on ARMv6+ Dec 18 16:33:14 mckoan: can you track down your problems (e.g. toggle gpios when no console output is possible yet)? Dec 18 16:34:29 ensc|w: I have no runtime problems (yet) I can't bitbake virtual/kernel Dec 18 16:35:24 ensc|w: I can't trace kernel build using devshell because devshell doesnt set the build environment as it did with oe-classic Dec 18 16:35:34 ensc|w: I'm stuck Dec 18 16:37:13 ah, kernel buils fails... that's probably easier to solve than lockups in the early booting... ;) Dec 18 16:37:37 what exactly fails? the make .82 thing with pattern and non-pattern on the same line? Dec 18 16:37:58 ensc|w: what? Dec 18 16:40:27 your bitbake build gives out some error message; which message is it? Dec 18 16:42:33 ensc|w: with h3600 is http://pastebin.com/zYWnj23h Dec 18 16:42:41 ensc|w: we're using this on 3 armv7a machines to boot (crespo, n900, om-gta04) Dec 18 16:52:59 mckoan: difficultly to say what's wrong there. You could try building with KERNEL_LDSUFFIX=.bfd, or add V=1 to see gcc cmdlines Dec 18 16:53:59 JaMa: I am wokring with omap3 + 4 and they do not have problems with unaligned access; it would be really interesting to know where the reported memory is belonging to Dec 18 17:45:37 moin Dec 18 18:28:23 moin senor Dec 18 19:08:04 is there an easy way to print out the contents of EXTRA_OECONF in a inc file after its been created? I tried using bb.note in a do_configure_prepend and running with -c configure, but it seems a bit overkill Dec 18 19:08:43 or, ideally, just the configure string that will be used at compile time Dec 18 19:09:27 mbroadst: enable BB_VERBOSE_LOGS and look into the create logfiles Dec 18 19:10:32 ah thank you Dec 18 19:10:57 those reside in the work dir? Dec 18 19:11:11 yes; below ${WORKDIR} Dec 18 19:14:12 ok, I guess I'm a bit confused, I was working with JaMa earlier to resolve a dependency issue during my final do_rootfs and he said if I rebuilt the package-index package I could avoid having to increase PRs to see if dependencies were correct. But that doesn't seem to be updating that file.. do I have to do a clean first? Dec 18 19:20:09 instead of asking you could have done it already Dec 18 19:33:13 mbroadst: no, as long as you have a at stuff in the feeds "bitbake package-index" should do the right thing Dec 18 19:33:28 s/a at// Dec 18 19:33:49 talk about random typos... Dec 18 19:39:16 I see.. seems like I've got a bit more to learn about dynamic packages then. Thanks mr_science Dec 18 19:53:00 mbroadst: tbh, i'm not sure if that depends on an existing image or not Dec 18 19:53:45 yeah I'm not either, I would guess not though Dec 18 19:54:01 but once i have an image built, i can bump package revs and rebuild the index then pull new packages from the feed Dec 18 20:03:38 hi Dec 18 22:43:26 JaMa: what kinds of problems are you seeing with the qtjsbackend-native? Dec 18 23:44:28 22:46 < levonmaa> JaMa: what kinds of problems are you seeing with the qtjsbackend-native? Dec 18 23:45:32 still trying to use /usr/lib and failing Dec 18 23:47:43 hmmm... I dont see that with my master Dec 18 23:48:16 Also I changed the patches a bit, needed to get rif of the printf's Dec 18 23:48:47 that I added for qmake and QT_CONF_PATH... Dec 18 23:48:56 they were confisung cmake ;) Dec 19 00:05:14 levonmaa: and what about that touching sysroot? Dec 19 00:05:22 is that line really needed twice? Dec 19 00:12:58 JaMa: could you explain a bit more on the implications to sstate Dec 19 00:19:31 everything what you want to do in sysroots needs to go through $D so that if someone builds from sstate-cache he gets the same content of sysroots directories as if he build it himself Dec 19 00:20:12 so if you call that sed "${STAGING_DATADIR}/${QT_DIR_NAME}/mkspecs/features/qt_module.prf" it's called only when you're really building it Dec 19 00:20:24 not when you just download sstate archive and unpack it Dec 19 00:53:27 JaMa: right... Dec 19 00:54:00 gotta think about that **** ENDING LOGGING AT Wed Dec 19 02:59:59 2012