**** BEGIN LOGGING AT Wed Feb 17 02:59:58 2010 Feb 17 03:52:19 Hello Feb 17 03:52:25 I am new to OE Feb 17 03:52:34 Can anyone guide me Feb 17 07:48:35 good morning Feb 17 08:22:07 re Feb 17 08:52:30 good morning Feb 17 08:54:08 http://www.linuxfordevices.com/c/a/News/Intel-and-Nokia-MeeGo/ Feb 17 08:59:41 03Koen Kooi 07org.openembedded.dev * recd916f4f4 10openembedded.git/recipes/policykit/policykit_0.96.bb: policykit: add 0.96 Feb 17 08:59:44 03Koen Kooi 07org.openembedded.dev * r498e017700 10openembedded.git/recipes/pam/ (libpam-base-files.bb libpam-base-files/pam.d/polkit-1): Feb 17 08:59:44 libpam-base-files: remove polkit-1 that is already in policykit package: Feb 17 08:59:44 Collected errors: Feb 17 08:59:44 * Package libpam-base-files wants to install file /etc/pam.d/polkit-1 Feb 17 08:59:44 But that file is already provided by package * policykit Feb 17 08:59:44 03Koen Kooi 07org.openembedded.dev * r9373490e2b 10openembedded.git/recipes/networkmanager/ (networkmanager-0.7.inc networkmanager_0.7.999.bb): network-manager: fix 0.7.9999 Feb 17 08:59:45 03Koen Kooi 07org.openembedded.dev * r2c2ebfa4ad 10openembedded.git/recipes/gnome/gnome-power-manager_2.28.3.bb: gnome-power-manager: add 2.28.3 Feb 17 08:59:46 03Koen Kooi 07org.openembedded.dev * rd70bbcefa0 10openembedded.git/recipes/networkmanager/network-manager-applet_git.bb: network-manager-applet git: update to 0.7.999 Feb 17 08:59:46 03Koen Kooi 07org.openembedded.dev * r03bf612853 10openembedded.git/conf/checksums.ini: checksums: add some old-style checksums Feb 17 08:59:47 03Koen Kooi 07org.openembedded.dev * r9483ed2c50 10openembedded.git/recipes/devicekit/devicekit-power_014.bb: devicekit-power: add 014 Feb 17 08:59:50 03Koen Kooi 07org.openembedded.dev * r74501117c2 10openembedded.git/conf/distro/include/sane-srcrevs.inc: opkg-native: bump to r522 to get a fix to remove duplicate messages from do_rootfs logs Feb 17 08:59:50 03Koen Kooi 07org.openembedded.dev * r1eb889c7e0 10openembedded.git/recipes/devicekit/ (devicekit-power_009.bb devicekit_003.bb): devicekit, -power: convert to new style staging Feb 17 08:59:51 03Koen Kooi 07org.openembedded.dev * rd1d1bf9254 10openembedded.git/recipes/policykit/policykit-gnome_0.96.bb: policykit-gnome: update to 0.96 Feb 17 08:59:52 03David-John Willis 07org.openembedded.dev * ra9904949e3 10openembedded.git/ (5 files in 3 dirs): Feb 17 08:59:53 system-tools-backends: Add 2.8.3 and checksum and remove DEFAULT_PREFERENCE = "-1" from 2.8.1 as I can find no good reason for it to be set. Feb 17 08:59:53 * Update Angstrom distro patch for 2.8.3 and make it only apply if Angstrom distro is set. Feb 17 08:59:56 03Koen Kooi 07org.openembedded.dev * rfba63ed00f 10openembedded.git/ (22 files in 5 dirs): Feb 17 08:59:56 qt4: add 4.6.2 Feb 17 08:59:56 * fix 4.6.1 references in 4.6.0 files as well Feb 17 08:59:56 * make qt-config.patch work with QT_NO_CAST_{TO,FROM},ASCII strict checking Feb 17 08:59:56 03Koen Kooi 07org.openembedded.dev * r2a18af8d4d 10openembedded.git/recipes/eggdbus/eggdbus_0.6.bb: eggdbus: fix depencies and add checksums Feb 17 08:59:56 03Koen Kooi 07org.openembedded.dev * r7194635729 10openembedded.git/recipes/hal/consolekit_0.4.1.bb: consolekit: add 0.4.1 Feb 17 09:20:50 blindvt: We don't have CIA for bitbake in here Feb 17 09:34:32 Hi, I have compiling errors (http://paste.pocoo.org/show/179196/), please anyone can help me ? Feb 17 09:34:43 should I switch to shr/testing2010 ? Feb 17 09:37:34 vadmeste: I have no idea what distribution are you using (cannot say from that log, but clearly not any SHR version) and shr/testing2010 is branch mainly for SHR distribution (even when it's only oe.dev + SRCPV patches) Feb 17 09:41:04 ah okey I understand now.. Feb 17 09:41:30 my problem that the stable/2009 doesn't support my nhk-15 machine.. Feb 17 09:54:00 Hey, about my error, it's just a bug or an error that comes from me ? Feb 17 09:56:35 most important part from your log is " See `config.log' for more details." Feb 17 10:18:13 okey, but i have many config.log now, is it in build/tmp directory ? Feb 17 10:22:32 good morning Feb 17 10:30:01 hi florian Feb 17 10:33:15 vadmeste: tmp/work/arch/glibc*/ Feb 17 10:33:50 I deleted all the build file, i am now building the micro distribution Feb 17 11:18:19 pb_: okay. I did check the return value, I did not read it from the console... the socket was set non blocking... :) Feb 17 11:18:40 pb_: now, next question. I have a GNU makefile, it is removing "intermediate targets". I would like it to not do it. Feb 17 11:18:40 zecke: doh Feb 17 11:18:54 03Koen Kooi 07org.openembedded.dev * ra93ded8dbe 10openembedded.git/recipes/hal/consolekit_0.4.1.bb: consolekit 0.4.1: fix PAM and make it a distro feature Feb 17 11:19:00 zecke: I think you need to set them as .PRECIOUS or some such Feb 17 11:19:03 let me check the fine manual Feb 17 11:19:22 ah yes Feb 17 11:19:22 http://www.gnu.org/software/automake/manual/make/Special-Targets.html Feb 17 11:20:10 actually, looks like .SECONDARY might be better for your purposes, but you can choose Feb 17 11:24:31 pb_: awesome, I had it open too... but I would not have guessed that. Feb 17 11:24:58 yeah, the "Special Targets" naming is a bit obscure Feb 17 11:26:54 hmm... my static dependencies are "wrong".. Do you know anything better than --debug=FLAGS to see what is up with GNU make? Feb 17 11:35:56 hi all Feb 17 12:24:28 03Koen Kooi 07org.openembedded.dev * r6ff50549c0 10openembedded.git/recipes/policykit/policykit-gnome_0.96.bb: policykit-gnome: fix SRC_URI Feb 17 13:43:01 hey I am still newbie and I think that there are no documentation about this subject, but why bitbake base-image fails when I set "minimal" as a distro ? Feb 17 13:43:23 vadmeste: What does the error message say? Feb 17 13:43:31 hello there, I got a problem bitbaking gconf (within beagleboard-demo-image) there is a missing dependency during do_configure. polkit-dbus seems to be needed, but nothing seems to provide this Feb 17 13:44:53 broonie, NOTE: Resolving any missing task queue dependencies Feb 17 13:44:53 ERROR: Required build target 'base-image' has no buildable providers. Feb 17 13:44:53 Missing or unbuildable dependency chain was: ['base-image', '${ANGSTROM_FEED_CONFIGS}'] Feb 17 13:48:05 I guess because minimal doesnt define ANGSTROM_FEED_CONFIGS Feb 17 13:59:07 emm okey, there are a lot to learn about OE Feb 17 14:00:37 vadmeste: easy fix, use Angstrom Feb 17 14:00:48 Koen Kooi org.openembedded.dev * rd1d1bf9254 openembedded.git/recipes/policykit/policykit-gnome_0.96.bb: policykit-gnome: update to 0.96 << Hmm, pretty sure that's wrong, that's polkit-gnome not policykit-gnome :-o Feb 17 14:01:07 okey Feb 17 14:01:13 thanks Feb 17 14:01:44 I have a question about the setup: it is better a 32bit or a 64bit host machine? 32bit can use JIT, but I need very powerful setup, so I'm moving to 64 bit and I have a compilation error in stable/2009 for nano package the is not present, in the same commit, on 32 bit host machine. Feb 17 14:02:21 recalcati: 32/64 bit doesnt really make any speed difference for OE in my experience, nor does psycho Feb 17 14:02:45 recalcati: I use a Debian 64bit ad OE build machine Feb 17 14:02:51 s/ad/as Feb 17 14:03:51 actually the spped is mostly determined by the HD thoughput (see VelociRaptor) Feb 17 14:04:07 the speed of a build process Feb 17 14:04:43 now when they make a gcc can can offload to my GPU :-) Feb 17 14:06:18 XorA: mckoan: ok. I'll buy one. for the bug I'll try to check, but if I'm not able to fix the bug on nano on a646269c2ada7691d8a7f7455ba4528c7cca3483 , I put it on bugzilla, right? Feb 17 14:07:01 recalcati: I didnt see a bug using stable, but its been a while since I did a compile Feb 17 14:07:43 check the commit Feb 17 14:07:51 please... Feb 17 14:09:19 that commit is pretty self explanatory Feb 17 14:43:20 hi Feb 17 14:43:40 moin woglinde Feb 17 14:43:41 whats the nearly best way for c programm to parse command options Feb 17 14:43:46 getopt lib? Feb 17 14:44:35 anybody knows if exist a floating point (sin/cos) function set optimized for ARM9? Feb 17 14:45:56 ah zecke Feb 17 14:46:10 03Koen Kooi 07org.openembedded.dev * r9db8aacd6e 10openembedded.git/recipes/gnome/gconf_2.28.0.bb: gconf: add 2.28.0 Feb 17 14:47:58 eFfeM-work: you lost momentum on http://threads.gmane.org/gmane.comp.handhelds.openembedded/29679 ? Feb 17 14:48:35 make that http://thread.gmane.org/gmane.comp.handhelds.openembedded/29679 Feb 17 14:53:02 Laibsch: from the discussion i felt there were some mixed opinions and didn't think it was such a big deal Feb 17 14:53:30 OK Feb 17 14:53:40 03Martin Jansa 07org.openembedded.dev * r999ce2c086 10openembedded.git/recipes/gtk+/gtk+_2.18.6.bb: Feb 17 14:53:40 gtk+-2.18.6: add libxrender-native to virtclass-native dependencies (fails to find libx11 without) Feb 17 14:53:40 Signed-off-by: Martin Jansa Feb 17 14:53:40 unfortunately, it continually does confuse users Feb 17 14:55:37 yeah, feel free to escalate if you want to, koen's reaction was a little bit irritated, and no-one really stepped up saying "great plan" Feb 17 14:56:01 mickey and pb did Feb 17 14:56:02 IIRC Feb 17 14:56:11 and me Feb 17 14:58:56 i'll write a followup email, see how that lands Feb 17 15:00:06 eFfeM-work: +1 from me Feb 17 15:00:42 eFfeM-work: BTW why don't you create something like agnostic-console-image.bb ? Feb 17 15:01:04 mckoan: because console-image.bb should really be agnostic Feb 17 15:01:11 agnostic is too difficult a word for me :-) Feb 17 15:01:11 and agnostic for what? Feb 17 15:01:19 might as well rename it back to angstrom-console-image Feb 17 15:01:20 location of the user? Feb 17 15:01:20 Laibsch: I see Feb 17 15:01:22 and then create a new one Feb 17 15:01:24 agree with Laibsch Feb 17 15:01:25 *shrug* Feb 17 15:01:30 mickey|cafe: yep Feb 17 15:01:38 mickey|cafe: has a point too Feb 17 15:01:41 mickey|cafe: maybe that is indeed the best Feb 17 15:01:49 anything that can keep us out of a lengthy hatred debate is good ;) Feb 17 15:01:55 yep Feb 17 15:02:06 and why piss off someone when you can do without? Feb 17 15:02:14 yo Feb 17 15:02:17 no matter if you agree with that position or not Feb 17 15:02:17 koen may actually like that Feb 17 15:02:27 since it's good for the angstrom "brand" Feb 17 15:02:47 eFfeM-work: you want to do that or shall I go ahead? Feb 17 15:07:44 XorA: I copied from 32bit to 64bit system $OE_HOME. now it's better I do rm -rf tmp/* and re-compile all. I had strange messages. maybe the toolchain was the 32bit old one. .... Feb 17 15:07:46 Laibsch: go ahead. Feb 17 15:07:47 03Marco Cavallini 07org.openembedded.dev * ra720b18919 10openembedded.git/conf/distro/kaeilos.conf: kaeilos.conf: Added credits to Angstrom Feb 17 15:07:54 btw it is in console-base-image not console-image Feb 17 15:07:55 OK Feb 17 15:08:02 Just ask :-D Feb 17 15:08:02 as i accently wrote in the email Feb 17 15:08:08 I'll find it Feb 17 15:08:20 * eFfeM-work now is gone to become eFfeM-home later :-) Feb 17 15:08:31 recalcati: definitely rm tmp Feb 17 15:15:07 mckoan: good move, but on the other hand I think it's rather silly that these demands are being made. Angstrom is by far not the only contributor to OE. Do we now need to explicitly mention everyone everytime, including Mommie and Daddie for raising us and letting us hack early in our lives? Mom-and-Dad McKoan had a greater impact on Kaeilos than Angstrom, why aren't they mentioned? Feb 17 15:15:37 And why not Grandma and the kid round the block who beat us when we were little (and weak) so we wouldn't dare going out the house and had nothing to do but hack? Feb 17 15:15:50 * Laibsch hopes it's clear I'm only partially being serious Feb 17 15:15:56 mckoan: right Feb 17 15:16:16 In my infinite setups I was getting a little bit confused Feb 17 15:16:51 * Laibsch has seen Koen first vehemently oppose his patches, only to apply them without credit a few months later Feb 17 15:17:37 let them bitch, I don't care Feb 17 16:18:41 03Rolf Leggewie 07org.openembedded.dev * r80db39feb7 10openembedded.git/recipes/images/ (angstrom-console-base-image.bb console-base-image.bb): Feb 17 16:18:41 recipes/images/console-base-image.bb: factor out Angstrom-specific bits Feb 17 16:18:41 * factor out Angstrom-specific bits into a separate recipe Feb 17 16:18:41 * I hope this should keep all participants in the ML-discussion happy Feb 17 16:18:41 http://thread.gmane.org/gmane.comp.handhelds.openembedded/29679 Feb 17 16:18:41 * the generic recipe now uses the IMAGE_EXTRA_INSTALL variable in favor Feb 17 16:18:42 of ANGSTROM_EXTRA_INSTALL to include additional packages in the image. Feb 17 16:18:51 03Rolf Leggewie 07org.openembedded.dev * re6472c1df7 10openembedded.git/recipes/ (9 files in 3 dirs): Feb 17 16:18:51 altboot: drop altboot in favor of kexecboot to avoid confusion Feb 17 16:18:51 * altboot is no longer supported Feb 17 16:18:51 * Thanks Coredump for your work, it certainly filled a niche at its time Feb 17 16:18:51 * drop related images as well Feb 17 16:31:33 hrw|gone: the freetype recipe you added does not build for me (tinderbox unfortunately does seem to be getting a log, though): http://paste.debian.net/60272/ Feb 17 16:33:20 thats libpng error Feb 17 16:33:22 hm Feb 17 16:33:37 maybee the .pc file is wrong Feb 17 17:27:34 morning Feb 17 17:30:17 he kergoth slept well= Feb 17 17:30:19 ? Feb 17 17:41:11 Anyone heard of this? http://www.aavamobile.com/ Feb 17 17:42:53 crofton nope Feb 17 17:44:45 they should say it is the second open device :) Feb 17 17:45:26 is the method for adding a search path for local files still FILESPATHBASE =. "mycollection/files:" ? - seems to break libpam-base-files as bitbake for some reason assumes file://pam.d/* is in your override Feb 17 17:45:35 in germany they would get suied Feb 17 18:07:41 hrw|gone: restarting with a clean tmp resolved the problem. sorry for the noise Feb 17 18:09:35 tharvey: the /* thing is a pretty ugly way to go anyway, should probably make it just do file://pam.d, and let it copy the whole dir over when it finds it.. but it sounds like it could be a bug in do_unpack in base.bbclass. Feb 17 18:10:35 kergoth, ya, was just looking at some prints I added to bitbake and came to the same conclusion - it doesn't handle wildcards correctly Feb 17 18:11:20 was wondering how many recipes used /* notation Feb 17 18:11:57 i doubt there's more than a couple Feb 17 18:12:01 heh Feb 17 18:12:53 bitbake/lib/bb/fetch/local.py:localpath does a if filespath newpath = bb.which(filespath, path) which won't handle wildcards Feb 17 18:16:22 03Koen Kooi 07org.openembedded.dev * r8679a85748 10openembedded.git/recipes/images/ (angstrom-console-base-image.bb console-base-image.bb): Feb 17 18:16:22 Revert "recipes/images/console-base-image.bb: factor out Angstrom-specific bits" Feb 17 18:16:22 This violates the principal of least surprise and invalidates documentation. If you're touching a recipe at least make sure the creator/maintainer agrees with your changes. Which I don't, as I've already stated Feb 17 18:16:22 This reverts commit 80db39feb76a6afaf1eb2c4dd8311fc21e4c2d6f. Feb 17 18:16:38 well, the thing is, what exactly does file://pam.d/* *mean*? Feb 17 18:16:45 all the files in the *first* pam.d found in filespath? Feb 17 18:16:50 or all the fiels in all pam.d's in filespath? Feb 17 18:16:53 its not clear Feb 17 18:17:21 good point... but at least changing it to file://pam.d/ doesn't break Feb 17 18:18:00 yeah, that i know works Feb 17 18:18:01 and does end up meaning first pam.d found in filespath, which is probably fine Feb 17 18:18:14 at least its explicit in its meaning Feb 17 18:19:59 do you mind making the patch for me? http://www.pastebin.org/93166 Feb 17 18:20:28 i would if my macbook wasn't out of commission at the moment.. and so is my NAS.. so the only devices with my ssh keys are down :) Feb 17 18:21:27 anyone with commit access mind making pam-base-files more explicit for me? http://www.pastebin.org/93166 Feb 17 18:22:37 trying to release a collection that builds on top of OE to some end users - wonder if I can bandaid around this temporarily? ie can I define FILESPATHBASE per package? Feb 17 18:43:18 tharvey: any variable can be defined per package using the pn-${PN} override. Feb 17 18:48:55 kergoth, thanks - that was the syntax I was looking for Feb 17 19:44:19 re Feb 17 19:47:54 Laibsch: someone really got p*ssed off by your change Feb 17 19:47:54 wv Feb 17 19:47:57 wb Feb 17 19:48:45 eFfeM: frankly, I don't care Feb 17 19:49:32 I do care about the failure to work together, though Feb 17 19:49:50 'morning' all Feb 17 19:50:13 pb_: how did your cross changes work out? Feb 17 19:50:48 kergoth: Any more thoughts on the bblayers thing? Feb 17 19:54:18 RP: good evening. haven't had time to do any more with them since last week unfortunately, been distracted by other things. I might get back to them tomorrow. Feb 17 19:54:50 I'm still fairly optimistic that the general strategy is a sound one. It does seem to remove all kinds of weird special-casing that we had before, which is nice. Feb 17 19:55:03 haven't had a chance to give it more thought Feb 17 19:55:17 pb___: The long path lengths of relative rpaths in the cross directory is causing relocation problems in poky Feb 17 19:55:42 pb___: Which made me wondering about removing the cross directory ;-) Feb 17 19:56:13 pb___: Removing special casing is nice, totally agreed Feb 17 19:56:23 right, indeed, getting rid of cross is an additional benefit Feb 17 19:56:48 out of interest, what is the problem with long rpaths? are they just ugly, or is there some functional issue? Feb 17 19:57:39 pb___: chrpath can only change to a path which is shorter or equal to the original string length Feb 17 19:57:46 xHmm Feb 17 19:57:56 RP: doh, that is a bit sucky. Feb 17 19:57:59 Why do we have 3 different revs of opkg for opkg, opkg-native and opkg-sdk? Feb 17 19:58:12 I guess it is hard to expand the string table without relinking the whole binary. Feb 17 19:58:19 pb___: right Feb 17 19:58:50 Tartarus: I'd say thats nuts Feb 17 19:59:12 * Tartarus makes a note to try and RFC a change.. Feb 17 19:59:31 RP: btw, I still think you'll have better luck, esp for SDK relocation with $ORIGIN over chrpath Feb 17 19:59:47 esp if we fix the mpfr/gmp thing Feb 17 20:00:02 Tartarus: I'm using chrpath to inject a $ORIGIN ;-) Feb 17 20:00:02 wasn't the idea to use chrpath to insert $ORIGIN in there? Feb 17 20:00:05 heh Feb 17 20:00:38 Why aren't you linking $ORIGIN initially? Feb 17 20:00:41 I guess I'm missing that Feb 17 20:00:49 Tartarus: because it's hard to statically determine the correct relative path Feb 17 20:00:51 at link time Feb 17 20:01:10 Tartarus: Too much like hard work when you can write one function which works for everything Feb 17 20:01:10 Because of people playing layout games? Feb 17 20:01:12 since you don't necessarily know where either the binary, or the libraries it uses, are going to land in the sysroot Feb 17 20:01:36 Note I'm playing with -native and -cross staging packages, not the SDK Feb 17 20:02:26 but, anyway, for my part I think you would be better off providing a wrapper binary that invokes ld.so with an appropriate --library-path option, since I don't think there is any other way to solve your "custom ld.so" issue. Feb 17 20:02:27 Some funky layout? Feb 17 20:02:30 Or perl unfun? Feb 17 20:02:37 and, that also avoids the issue with over-long rpaths as it happens Feb 17 20:02:45 I didn't find doing all of -cross and -native with $ORIGIN that hard, except perl Feb 17 20:03:28 Tartarus: how did you deal with the path lengths of things in cross linking against native packages? Feb 17 20:03:36 (of course the hard part of relocating isn't the linked stuff, it's hardcoded paths in all of the little stupid files) Feb 17 20:03:42 pb___: I'm ignoring the ld.so problem for now :/ Feb 17 20:03:55 Tartarus: You have all the relocation working? Feb 17 20:04:15 RP: Yes, it's just ugly and unchanged from 2 or 3 years ago Feb 17 20:04:48 RP: In some packages we have $ORIGIN/../../../staging/$hostarch/... Feb 17 20:04:53 RP: yeah, it seems to me like you would be better off tackling that now rather than saving it up for later. I don't think solving it that way is really any harder than what you are doing with chrpath. Feb 17 20:04:56 which is ugly, i admit Feb 17 20:05:16 possibly a fraction more fiddly, but then you don't have the path length limitation to worry about. Feb 17 20:05:42 Tartarus: I'd imagine if you built in a short path directory, it would break ;-) Feb 17 20:06:01 RP: Yes, I am able to ignore DISTRO=minimal Feb 17 20:06:05 But it wouldn't be hard to unbreak Feb 17 20:06:09 Just further ugly Feb 17 20:06:24 And you do have to say at some point, we don't care for your /crazy/and/arbitray/layout Feb 17 20:06:29 Tartarus: No, I mean if you ran a build in /foo on a system instead of /home/lng/path Feb 17 20:06:34 RP: if I understand correctly, tartarus is passing the -rpath-link statically at build time, not using chrpath. So I don't think the path length of his build dir matters. Feb 17 20:06:59 RP: Er, no? It's all within a give hierarchy, for -cross/-native Feb 17 20:07:08 pb__: Correct Feb 17 20:07:16 -rpath-link with $ORIGIN escapes Feb 17 20:07:17 Tartarus: ok, you do it statically, right Feb 17 20:07:29 Tartarus: Are these changes public anywhere? Feb 17 20:07:46 I pastebin'd 'em at some point last week Feb 17 20:07:53 but, that means he needs to hard-wire a bunch of layout assumptions into (presumably) his makefiles, hence his distaste for micro. heh. Feb 17 20:08:01 And a goal of mine is to get kergoth to post 'em, if he agrees it's not too ugly Feb 17 20:08:06 But it's only a minor win Feb 17 20:08:14 The hard part isn't getting link stuff working Feb 17 20:08:25 Tartarus: I'm curious about the other bits ;-) Feb 17 20:08:27 The hard part is all of the stupid places in conf files and .m4 files and so on with hard coded paths Feb 17 20:09:09 kergoth said he'll look over what I did today, and if he's not voilently ill after, we'll pastebin Feb 17 20:09:19 But if you've looked at the problem, I bet you can guess what we did Feb 17 20:09:34 Tartarus: sed? Feb 17 20:09:51 Tartarus: There are a few different options I'm wondering about Feb 17 20:10:56 Yeap, sed Feb 17 20:12:09 Tartarus: SO you added some kind of postprocessing? Feb 17 20:12:16 pre and post, yes Feb 17 20:12:23 Tartarus: by file extension, explicit list or ...? Feb 17 20:12:38 Anything non-binary is checked Feb 17 20:12:45 Anything we change, we log Feb 17 20:12:58 So we have a list at least for unpacking Feb 17 20:13:12 We also had to add a blacklist Feb 17 20:13:14 bison sucks. Feb 17 20:13:39 (And would be a candidate to fix for real to have some env way to override) Feb 17 20:21:03 Tartarus: Makes sense. I can see a need for this stuff in OE itself... Feb 17 20:30:22 morning Feb 17 20:30:33 RP: Yeah Feb 17 20:30:42 I'm just torn on if it's too ugly to make it in, or not Feb 17 20:31:03 I've also got some changes to how we layout pstaging that would be good to RFC either way Feb 17 20:31:36 (And only a small part of it depends on adding a variable that contains lsb_release -r -i and uname -m Feb 17 20:32:22 Tartarus: I'd be interested to see the patches certainly Feb 17 20:36:22 k Feb 17 20:40:53 http://pastebin.com/m6eabe079 Feb 17 20:41:22 HOSTVENDOR is `lsb_release -i`_`lsb_releasr -r`_`uname -m` Feb 17 20:41:40 * kergoth waits on a pile of git clones / svn checkouts / etc Feb 17 20:41:49 So the end result is that we can easily share target pstaging between hosts Feb 17 20:42:21 And also, between different machines Feb 17 20:42:23 Tartarus, RP: speaking of packaged staging. do you see conflicts with multiple simultaneous do_package_stage? i.e. http://pastebin.org/93227 Any pointers? Feb 17 20:42:31 out of curiosity, why PSTAGE_BLACKLIST rather than using the pn-${PN} override + PSTAGING_ALLOWED? Feb 17 20:42:52 kergoth: Probably because I missed how to use PSTAGING_ALLOWED like that Feb 17 20:43:34 well, you can override the value of any variable per recipe with that override Feb 17 20:44:50 * kergoth grumbles about the slow net connection, neighbors must be sucking it up Feb 17 20:45:29 denix: Only seen crazy stuff like that when building on NFS Feb 17 20:45:42 denix: But you have something sane like ext3 underlying, i assume Feb 17 20:45:55 hm xz seems crawling fast Feb 17 20:45:56 ext4, yes Feb 17 20:46:14 woglinde: heh Feb 17 20:46:31 never heard of it until a week ago Feb 17 20:46:34 It can be faster than bz2, or not depending on how aggressive it was at compress time Feb 17 20:46:37 Tartarus: it's not just kernel/tar. I've seen other conflicts, like - | mkdir: cannot create directory `/OE/arago-deploy/pstage/angstromglibc/IPKG_BUILD.13587': File exists Feb 17 20:46:52 denix: I've never seen that. Strange Feb 17 20:46:59 Tartarus: but always when more than 2 recipes go into do_package_stage task! Feb 17 20:47:06 Odd Feb 17 20:47:08 just not seen that Feb 17 20:47:20 Tartarus, RP: I have to either disable PSTAGE, or set BB_NUMBER_THREADS=1 Feb 17 20:47:25 woglinde: Neither had I, until I learned it was also the stuff in p7zip, which we use internally Feb 17 20:47:57 hm yes p7 I know Feb 17 20:48:00 and it's also 'lzma' Feb 17 20:48:10 but a specific compressor of it Feb 17 20:48:17 yeah I read the blog entry on kernel yesterday Feb 17 20:48:26 denix: Are those tasks running opkg_make_index somehow? Feb 17 20:49:32 RP: in the second error with mkdir conflict one of the recipes was running do_package_update_index_ipk task Feb 17 20:50:04 denix: That is the problem, I don't see why it would be doing that Feb 17 20:50:46 RP: because it was an image recipe? Feb 17 20:51:04 denix: The package_write function shouldn't be updating the index though Feb 17 20:51:23 denix: In poky, the index updates also have locking around them Feb 17 20:51:42 RP: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-February/017257.html Feb 17 20:52:50 RP: in OE index updates are locked also - ${DEPLOY_DIR_IPK}.lock Feb 17 20:54:52 denix: hmm, there goes that theory :/ Feb 17 20:55:39 Tartarus: Removing the code that changes PSTAGE_PKGPATH then adding it back in multiple places looks rather wrong :/ Feb 17 20:56:11 RP, i think i have an issue related to the one from denix, if I restore the kernel from packaged staging sometimes it does do a kernel_do_deploy, guess in that case the timestamp of deploy is wrong (but didn't have a chance to verify it) so after restoring it thinks it still needs to do kernel_do_deploy Feb 17 20:56:30 btw if i am correct timestamps are second accurate to that might also be involved Feb 17 20:56:50 eFfeM: :/ That will probably be a pain to debug but it could be that... Feb 17 20:57:19 well, next time it happens I'll examine the package in the pstage dir (and the timestamps) Feb 17 20:58:08 but the deploy timestamp is written very near the end and I guess it could well happen the packaged-staging stamp is written in the same second if you hvae a fast machine. not sure what will happen then. Feb 17 20:59:03 RP: It could be done a bit more efficiently I think Feb 17 20:59:07 i would guess if timestamps are equal it is played safe and tasks which are unsure if they have been performed are being re-executed (but that is just a guess) Feb 17 20:59:09 Or at least a helper func Feb 17 20:59:29 <94SAAHDA4> Tartarus: I just wonder why the original approach failed or wasn't adaptable Feb 17 20:59:57 RP: towards splitting up the package names so? Feb 17 21:00:36 Tartarus: Why line 20-26 of the patch was removing that code and then duplicating it Feb 17 21:00:51 Obviously you used a different path too Feb 17 21:01:08 Ah Feb 17 21:01:19 So, I see what you're saying Feb 17 21:01:30 Probably because I haven't reviewed the changes as a diff realy :) Feb 17 21:01:44 step one, remove the "don't let us reuse -cross/-native pstaging if TMPDIR changes" Feb 17 21:01:48 step two, make it work again Feb 17 21:01:56 Tartarus: right ;-) Feb 17 21:02:12 See, this is why i didn't want to post it until after kergoth saw :) Feb 17 21:02:19 * kergoth chuckles Feb 17 21:02:22 This works, but indeed could be better Feb 17 21:02:32 * kergoth thinks his svn checkout might complete sometime today.. Feb 17 21:03:00 Tartarus: I understand how these things happen, don't worry - it just needs some cleanup :) Feb 17 21:03:56 heh Feb 17 21:04:26 denix: Are you still seeing the IPKG error or not? Feb 17 21:04:48 denix: I'm finding it hard to get a fix on which errors you're still seeing and which you're not Feb 17 21:04:57 That said, the last 3 hunks are the big deal about relocation Feb 17 21:04:58 RP__: that one I've seen one, but the one with tar happens more often Feb 17 21:05:11 I had forgotten about the stupid binconfig stuff until i saw it again Feb 17 21:05:21 Since it's cross/ stuff that ends up in a target pstaging Feb 17 21:05:22 * kergoth binconfig bits need to die in a fire Feb 17 21:05:37 RP__: I was treating them as one problem, due to happening in do_package_stage task... Feb 17 21:05:55 erm, there should have been a 'thinks' in that /me Feb 17 21:06:12 denix: This isn't on a virtual machine is it? Feb 17 21:06:23 * RP__ agrees with kergoth Feb 17 21:06:39 RP__: nope, real quad core with local storage on ext4 Feb 17 21:06:59 * RP__ has seen crazy virtualisation failures Feb 17 21:06:59 heh, there's another grunt work task.. go through and kill the last remaining binconfig scripts Feb 17 21:07:14 RP__: works well in a single thread though... Feb 17 21:07:17 kergoth: and clean up all the pkgconfig use Feb 17 21:07:31 OE still has horrible regexps in there for .pc files :( Feb 17 21:07:35 Poky does not Feb 17 21:08:44 Tartarus: Yes, the reclocation bits are interesting and I'd probably take them for OE Feb 17 21:08:59 OK, good to know Feb 17 21:09:04 Tartarus: I think I added something slightly similar to Poky now I think about it although I think just against .la files Feb 17 21:10:00 kergoth: accept my twitter request Feb 17 21:10:52 i thought i already did.. hmm, okay Feb 17 21:11:27 kergoth: btw, what's with the privacy? :) Feb 17 21:11:28 RP__: OK, I've locally changed things up Feb 17 21:14:54 ah, right Feb 17 21:18:32 kergoth: did not noticed before that you are no longer @mvista Feb 17 21:28:50 bye Feb 17 21:32:11 jo ant Feb 17 21:43:14 woglinde: hey Feb 17 21:48:54 calling it a day, cya all tomorrow & stay well! Feb 17 22:14:41 03Andrea Adami 07org.openembedded.dev * r54c1945111 10openembedded.git/recipes/kexecboot/linux-kexecboot-2.6.32/ (akita/defconfig c7x0/defconfig spitz/defconfig): linux-kexecboot_2.6.32: minor defconfig update for Zaurus clamshells Feb 17 22:15:31 l8r eFfeM-work Feb 17 22:35:49 03Koen Kooi 07org.openembedded.dev * re34626307d 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom: move to qt 4.6.2 and nm 7.999 Feb 17 22:35:50 03Koen Kooi 07org.openembedded.dev * r1e013ab819 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Feb 17 22:35:51 03Koen Kooi 07org.openembedded.dev * r36b0f7ab4a 10openembedded.git/recipes/pam/libpam-base-files.bb: libpam-base-files: bump PR Feb 17 22:35:52 03Koen Kooi 07org.openembedded.dev * rebc9df5d84 10openembedded.git/recipes/policykit/policykit_0.96.bb: policykit: bump PR Feb 17 22:35:53 03Koen Kooi 07org.openembedded.dev * r3199040088 10openembedded.git/recipes/qt4/ (qt4-embedded-gles_4.6.2.bb qt4-x11-free-gles_4.6.2.bb): qt4-*-gles 4.6.2: only enable opengl es2 but not openvg Feb 18 00:07:11