**** BEGIN LOGGING AT Thu Aug 20 02:59:57 2009 Aug 20 04:00:26 03Jeremy Puhlman  07org.openembedded.dev * r27765f8a1d 10openembedded.git/recipes/gettext/ (5 files in 2 dirs): (log message trimmed) Aug 20 04:00:26 gettext: Correct autoconf-lib-link code to defer to the compiler's library search paths. Aug 20 04:00:26 Ultimately we should have --with- and --without- for everything, Aug 20 04:00:26 however if a recipie does not the suspect code wanders through the host system Aug 20 04:00:28 searching for a working library. OE takes great pains to set that all up, lets Aug 20 04:00:30 let it decide the right library. Aug 20 04:00:32 Signed-off-by: Jeremy Puhlman Aug 20 04:00:37 03Jeremy Puhlman  07org.openembedded.dev * rf171a1e3eb 10openembedded.git/recipes/wireless-tools/wireless-tools.inc: (log message trimmed) Aug 20 04:00:37 wireless-tools.inc: Change first use of SRC_URI from += to = Aug 20 04:00:39 Since wireless-tools.inc is included at the top of the recipe it should clear Aug 20 04:00:43 SRC_URI. Aug 20 04:00:45 Without this, SRC_URI contains the recipe file, which in turn gets Aug 20 04:00:47 installed in to the work area. When using BBPATH to set BBFILES, Aug 20 04:00:49 this causes an error on subsequent parsing due to wireless-tools.inc Aug 20 04:36:05 hmm, anyone have an sh3/sh4 box? Aug 20 06:32:52 03Khem Raj  07org.openembedded.dev * r4cffb4ce4d 10openembedded.git/recipes/opkg/opkg.inc: Aug 20 06:32:52 opkg: Add opkg to FILESPATHPKG. Aug 20 06:32:52 Otherwise it does not find patches stored under opkg directory Aug 20 06:32:52 Signed-off-by: Khem Raj Aug 20 06:57:07 ping msmith_ Aug 20 09:00:17 03Steve Sakoman  07org.openembedded.dev * r31b3535468 10openembedded.git/ (conf/checksums.ini recipes/gnome/liboobs_2.22.0.bb): liboobs: add 2.22.0 Aug 20 09:00:17 03Steve Sakoman  07org.openembedded.dev * rae0a397d76 10openembedded.git/ (conf/checksums.ini recipes/gthumb/gthumb_2.10.11.bb): gthumb: add 2.10.11 Aug 20 09:00:18 03Steve Sakoman  07org.openembedded.dev * r32612d6d61 10openembedded.git/recipes/gnome/gnome-keyring_2.26.0.bb: gnome-keyring: add missing dependency on libpam Aug 20 09:00:19 03Steve Sakoman  07org.openembedded.dev * r4fd667016a 10openembedded.git/conf/checksums.ini: checksums.ini: add missing entry for libcanberra 0.14 Aug 20 09:00:22 03Steve Sakoman  07org.openembedded.dev * r6d77f938e9 10openembedded.git/ (4 files in 3 dirs): system-tools-backends: add 2.6.1 Aug 20 09:14:24 denix: I think you might be interesting in looking at xora/angstrom-srcpv branch :-) Aug 20 09:15:11 XorA: hey, how did you fill SRCPV? Aug 20 09:15:36 XorA: thanks, haven't seen it before, until Koen rubbed it into my face... ;) Aug 20 09:16:15 zecke: I stole your openmoko patch Aug 20 09:17:13 XorA: do you build with BB_GIT_CLONE_FOR_SRCREV = "1"? Aug 20 09:17:38 zecke: I havent tried that, I wanted to seperate the two things in peoples minds Aug 20 09:17:56 XorA: which is great :) Aug 20 09:18:06 SRCPV = "${@bb.fetch.get_srcrev(d)}" Aug 20 09:18:06 AUTOREV = "${SRCPV}" Aug 20 09:18:32 XorA: how do you plan to go ahead? did you also take the changes that fixed the various PV formating bugs? Aug 20 09:19:00 zecke: yes I have tried to make sure the PV formatting was fixed as well Aug 20 09:19:04 what BB_GIT_CLONE_FOR_SRCREV is for? Aug 20 09:19:35 denix0: for git the abovr SRCPV will emit a "1" "2" "3"... as there is no real monotonic increasning number Aug 20 09:19:38 zecke: I had to manually merge your patch because of the amount of diversion between trees, so may have screwed up here and there Aug 20 09:20:03 denix0: for Openmoko we wanted to have everyone be able to build and provide packages, so you need a global scheme Aug 20 09:20:25 denix0: this is how BB_GIT_CLONE_FOR_SRCREV was born, it will git clone and use git rev-list to generate a revision number Aug 20 09:20:31 zecke: but I think the way ahead would be to merge the bitbake.conf changes, then work ${PN} by ${PN} to gradually convert Aug 20 09:20:42 I note FSO tree is already converting anyway Aug 20 09:20:50 denix0: NumberOfCommits-HASH Aug 20 09:20:51 s/tree/branch/ Aug 20 09:21:00 XorA: we need to look at RPs concerncs again Aug 20 09:21:17 zecke: I spoke to RP, he was happy with SRCPV changes entering OE Aug 20 09:21:22 zecke: ah, so SRCPV is the number of commits in the repo? Aug 20 09:22:06 denix0: with BB_GIT_CLONE_FOR_SRCREV, yes number of commits + some digits of the hash Aug 20 09:22:09 zecke: its more a case to educate DISTRO that the must keep their persistant cache dir if they are not using BB_GIT_CLONE_FOR_SRCREV Aug 20 09:24:36 XorA: he was happy with SRCPV? I think he wasn't happy with the bb.fetch_get_srcrev usage Aug 20 09:25:00 XorA: it is a bit of a hack and works because of the implementation Aug 20 09:26:16 zecke: from what he said to me I think he thought of it as a step in the right direction, if we switched then the underlying implementation could be fixed. Probably best talk to him direct, I think he was unhappy with the original implementation of AUTOREV and was looking to fix it sometime Aug 20 09:26:58 zecke: I can see how decoupling SRCREV from PV would make under the hood changes easier later Aug 20 09:28:39 personally I havnet actually looked under the hood for a while as it scares me. I just wanted nice PV incements for personal use Aug 20 09:35:08 Hello. I'm going to use external toolchain to build OE for lpc3250 board and now I'm confused with one thing -- in bitbake.conf CC is host compiler (for x86 pc e.g.) and BUILD_CC is cross-compiler (for arm9 board e.g.), right? Aug 20 09:38:08 raydan: the other way around Aug 20 09:42:24 Hm, thanks. It's all right then Aug 20 10:42:52 I see that a lot of recipies use ${PYTHON_DIR}, how does this get populated? I've tried using it in my own recipe and it has no value Aug 20 11:18:06 zecke: can you easily get something like this in TW: http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&KeyWords=10-00003-ND Aug 20 11:18:31 zecke: pins 4-5 need to be shorted on the mini-A end Aug 20 11:20:01 zecke: I plan to order a few anyway, so could wait and ship you one with BB, otherwise I'll get BB shipped today Aug 20 11:23:05 cbrake: I think I should be able to find that stuff easily Aug 20 11:23:51 denix: Would you be so kind to take a look at the u-boot git recipe? I don't think it fetches successfully. Aug 20 12:14:50 03Steffen Sledz  07org.openembedded.dev * rde8bab6aed 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux-2.6.24: use kernel module for SATA disks at hipox machine Aug 20 12:36:52 Could anybody tell me, please, in what way 'bitbake -vvv PACKAGE' show package names, marked as ASSUME_PROVIDED, as it said in manual? I've added prebuilt toolchain and libc, but number of target haven't decreased and in the 'bitbake -vvv helloworld-image' log I see gcc-cross-initial, binutils-cross and even qemu-native. Aug 20 12:37:49 raydan hm you could use -DDD too Aug 20 12:41:40 woglinde: yes, I know it, but there is really big heap of messages. I need some string to grep and check, did my prebuilt toolchain and libc tied fine with OE or not. gcc-cross-initial, binutils-cross in bitbake log make me think that my OE doesn't see my toolchain and going to build it's own Aug 20 12:42:13 raydan hm Aug 20 12:42:22 didnt use external-toolchain yet Aug 20 12:55:35 Laibsch: which machine? Aug 20 12:56:03 I think it's irrespective of machine Aug 20 12:56:12 I believe the denx.de git server is down Aug 20 12:56:34 I see many hits for the tarball on sources.openembedded.org Aug 20 12:57:05 I haven't tried myself, but I assume the git server in the source URI is no longer working Aug 20 12:58:42 hmm, git.denx.de seems to work fine Aug 20 13:10:39 It says www.denx.de in SRC_URI IIRC Aug 20 13:10:43 Maybe that is the reason? Aug 20 13:13:13 www.denx.de is also up Aug 20 13:14:00 some machines fetch u-boot from different trees, are you sure it fails for denx.de? Aug 20 13:15:28 I'm running a test right now Aug 20 13:25:22 jo gnutoo Aug 20 13:25:42 hi Aug 20 13:30:42 denix0: fetch fails for me, too: http://tinderbox.openembedded.net/packages/218649/ Aug 20 13:30:52 looks like the revision isn't specified correctly Aug 20 13:31:25 could be a distro problem Aug 20 13:32:19 do you have the error message? I can't seem to find logs in tinderbox... Aug 20 13:57:57 http://tinderbox.openembedded.net/packages/217239/ Aug 20 13:58:06 you must have seen it yourself, yesterday Aug 20 13:58:25 * Laibsch wonders where the logs went Aug 20 14:00:20 no, that's different. that specific machine is not yet in u-boot Aug 20 14:04:33 ic Aug 20 14:05:03 It looks like the tinderbox currently does not provide the links to the logs Aug 20 14:05:09 I'll have to look into that Aug 20 14:05:29 denix0, the error was "fatal: Not a valid object name 1" indicating to me it was trying to fetch r1 Aug 20 14:05:38 which does not mean anything to git Aug 20 14:05:58 usually one gets such an error when the revision isn't specified Aug 20 14:06:06 I was compiling for qemuarm Aug 20 14:06:10 looks like SRCREV=1 Aug 20 14:06:49 u-boot_git has not SRCREVs for qemuarm Aug 20 14:08:00 is there even u-boot for qemuarm? it's not a real platform... Aug 20 14:10:47 how does pkg-config work within OE? It appears to be returning paths to the host system, not the staging area Aug 20 14:11:16 is there some magic I need to be doing to make it give the correct paths? Aug 20 14:22:41 Elleo: pkg-config in oOpenEmbedded points to staging. see conf/bitbake.conf, which sets the env vars for pkg-config's search paths. Aug 20 14:25:13 kergoth: well that's not what's happening when farsight2 calls pkg-config when looking for the python defs Aug 20 14:25:36 it returns a path to the host system and only works if I have the python-gst and python-gtk defs installed system wide Aug 20 14:26:08 it calls pkg-config directly, rather than through any autotools macro or anything Aug 20 14:29:33 Elleo: I guess OE sets PKG_* env. variables, which make pkg-config look in appropriate place Aug 20 14:31:35 well pkg-config is finding the .pc files fine Aug 20 14:31:49 it's the paths that it returns that aren't correct Aug 20 14:32:02 and the paths in the .pc files are system wide ones, so that's understandable Aug 20 14:32:23 I'd guess that OE only overrides pkg-config in autoconf scripts or something Aug 20 14:32:43 not when it's executed directly Aug 20 14:32:58 Elleo: definitely no. I'm just developing a recipe with simple Makefile using pkg-config to get gtk+ libs and it works Aug 20 14:33:45 maybe it's doesn't handle pkg-config --variables then Aug 20 14:34:07 maybe... Aug 20 14:34:09 the build process calls `pkg-config --variable=defsdir gst-python-0.10` to find the defs Aug 20 14:34:28 did you try '-c devshell' and calling pkg-config from there? Aug 20 14:34:31 and it's getting /usr/share/gst-python/0.10/defs returned Aug 20 14:34:50 no, I'll give that a try now Aug 20 14:35:59 this is a problem we have w/ pkgconfig files Aug 20 14:36:07 we change well-known paths Aug 20 14:36:15 but OE obviously has no idea what the contents fo a 'variable' is Aug 20 14:36:30 hence special treatment is necessary for that Aug 20 14:36:36 in the respective file Aug 20 14:36:40 (recipe) Aug 20 14:36:51 aah okay Aug 20 14:37:09 I'll just patch farsight2's build process to give the correct paths then Aug 20 14:37:18 *nod* Aug 20 14:37:37 it's often best to patch by looking at bindir or libdir and creating a relative path based on that Aug 20 14:37:45 okay Aug 20 14:51:34 mickeyl: what's the easiest way to set a bitbake variable in a recipe from an external process output during parsing? Something like PV = "`echo 1.2.3`" Aug 20 14:53:54 mickeyl: don't bindir and libdir give the wrong type of path though? I thought they gave the form /usr/bin /usr/lib, etc. rather than /path/to/staging/usr/bin Aug 20 14:54:20 is there a variable I'm unaware of that gives /path/to/staging/? Aug 20 14:55:39 denix0: i don't know offhand. you could do it with a python function PV = @${...} Aug 20 14:55:46 then calling os.popen or so Aug 20 14:56:08 Elleo: OE mangles the bindir and libdir paths to point into staging Aug 20 14:56:15 Elleo: have a look at pkgconfig.bbclass Aug 20 14:56:32 mickeyl: does it not do that with datadir as well? Aug 20 14:56:41 IIRC yes Aug 20 14:57:04 as at the moment I've replaced the pkg-config line with a ${datadir}/path/to/defs/ and it's returning /usr/share/path/to/defs when compiling Aug 20 14:57:18 mickeyl: thanks. os.popen is being deprecated unfortunately... Aug 20 14:57:31 denix0: subprocess.call Aug 20 14:58:02 Elleo: you can always use vars like STAGING_BINDIR, etc. Aug 20 14:58:14 ah okay, thanks Aug 20 14:58:17 Elleo: have a look at bitbake.conf or call bitbake -e to see which vars we declare Aug 20 14:58:28 ah handy Aug 20 14:59:39 hmm, anyone messed with ncurses lately? Aug 20 14:59:41 | ./config.status: line 512: ]([ABCDGIRSTW][ABCDGIRSTW]*)[: command not found Aug 20 14:59:41 | ./config.status: line 513: syntax error near unexpected token `(' Aug 20 14:59:41 | ./config.status: line 513: `lt_cv_sys_global_symbol_to_cdecl='sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^[ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p''' Aug 20 14:59:41 | FATAL: oe_runconf failed Aug 20 14:59:57 ncurses-native no longer builds Aug 20 15:04:39 mickeyl: how recent? Aug 20 15:07:28 florian: kannst du mir die liste der mitglieder schicken? Aug 20 15:08:01 zecke: klar... is aber auch im git Aug 20 15:11:02 florian: ah okay, let me find that then Aug 20 15:11:12 zecke: check mail :) Aug 20 15:20:50 jo kergoth Aug 20 15:21:56 zecke: HEAD Aug 20 15:21:58 zecke: booting from scratch Aug 20 15:22:02 err Aug 20 15:22:04 building Aug 20 15:22:06 kergoth: any idea w/ ncurses-native: Aug 20 15:22:08 | ./config.status: line 512: ]([ABCDGIRSTW][ABCDGIRSTW]*)[: command not found Aug 20 15:22:10 | ./config.status: line 513: syntax error near unexpected token `(' Aug 20 15:22:12 | ./config.status: line 513: `lt_cv_sys_global_symbol_to_cdecl='sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^[ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p''' Aug 20 15:22:15 | FATAL: oe_runconf failed Aug 20 15:22:17 ? Aug 20 15:22:20 hm Aug 20 15:22:27 seems some sed error Aug 20 15:22:30 yikes Aug 20 15:22:40 looks like a quoting problem, the sed command uses ' in a '' Aug 20 15:22:46 never seen that one Aug 20 15:22:49 hmm Aug 20 15:22:57 * kergoth gets mountain dew Aug 20 15:35:14 mickeyl: fails here too Aug 20 15:35:32 thanks for confirming Aug 20 15:35:39 lets see recent changes to ncurses Aug 20 15:36:07 hmm, only kergoth's Aug 20 15:36:21 that looks very unrelated thoug Aug 20 15:36:56 hmm, feel free to revert for now. very odd, i don't see how it would cause that, and it doesn't happen here Aug 20 15:37:02 can always revisit later Aug 20 15:37:54 * kergoth doesn't want to break anything, just working through his backlog of mvl6 changes that never went upstream Aug 20 15:38:21 surething Aug 20 15:39:27 hm didnt get it why ncurses libtool support was disabled? Aug 20 15:40:34 i don't recall the exact failure, but i hit build problems with it using it. besides, libtool sucks Aug 20 15:40:37 ;) Aug 20 15:40:45 bah Aug 20 15:41:08 mickeyl: want me to back it out, or are you going to? Aug 20 15:41:30 let me try first whether it makes any change, i still doubt it Aug 20 15:41:32 kergoth whats the altenative to libtool? Aug 20 15:41:38 hmm Aug 20 15:41:39 d'oh Aug 20 15:41:44 builds Aug 20 15:42:01 kergoth: completely strange, but yes, please revert for now until we find what's really wrong Aug 20 15:42:05 woglinde: with a sane linker, you don't really need it. Aug 20 15:42:14 will do, i'll see if i can repro the failure to investigate Aug 20 15:42:18 thanks Aug 20 15:42:47 we really need to find a way to avoid so many non-deterministic build issues Aug 20 15:42:50 somehow. Aug 20 15:44:01 yeah Aug 20 15:44:03 03Chris Larson  07org.openembedded.dev * rba43e91802 10openembedded.git/recipes/ncurses/ncurses.inc: Aug 20 15:44:03 Revert "ncurses: don't use libtool." Aug 20 15:44:03 This reverts commit f9b6fb8272850ebb1a001f6f055df8a3c74733fd. Aug 20 15:44:03 Apparently the change to not use libtool causes failures on some machines, but Aug 20 15:44:03 not others. Will investigate further. Aug 20 15:52:11 03Michael 'Mickey' Lauer  07org.openembedded.dev * rdf0c1f671b 10openembedded.git/recipes/freesmartphone/ (4 files): fso-abyss | libgsm0710 | libgsm0710mux: catch up PV with upstream Aug 20 15:53:11 moving to private staging areas would help determinism with regard to build order, but still wouldn't help us with regard to the build machine. maybe we really do need to start providing a chroot OpenEmbedded dev env, livecd, whatever Aug 20 15:55:38 take any bootable CD, include apt-getable OE and you're set Aug 20 15:56:05 hehe, yeah, pretty much... the key would be to get everyone building in the same environment.. what that env is doesn't matter so much Aug 20 15:58:52 Well, isn't auto* the big problem? Aug 20 15:59:46 I'd be more inclined to blame the developers who make the configure.{in,ac} scripts, myself. those stupid ass macros scanning /usr/lib and /usr/include to find things directly Aug 20 16:00:15 jeremy's patch to make the lib-link.m4 ignore the results of its scans of that sort is a start, but the devs can still do stupid shit, and short of a chroot, we can't stop them Aug 20 16:01:57 Yeah, if that stuff was sysrooted it shouldn't/wouldn't matter, but same deal Aug 20 16:02:36 if we could trust them to use existing macros for it, we can easily modify the macros to fix it Aug 20 16:03:53 here's an example of something we can't automatically work around. libpcap, as it stands today, toggles its bluetooth support based on the existence of bluetooth/bluetooth.h. thankfully, it uses AC_CHECK_HEADER for that check, but its still a problem for deterministic builds Aug 20 16:03:53 That too Aug 20 16:04:03 even worse, it toggles usb sniffing based on an execution of udevinfo Aug 20 16:04:18 While we're daydreaming, can we get use flags yet? :) Aug 20 16:04:28 hehe Aug 20 16:04:34 That would of course fix the libpcap problem :) Aug 20 16:04:56 not alone it wouldnt, because in this case there's no --enable/--disable/--with/--without for those optional bits at all Aug 20 16:05:07 but thats typical, case by case fixups Aug 20 16:05:09 sadly Aug 20 16:05:16 sure it would, you make sure you build bt early Aug 20 16:05:25 :) Aug 20 16:05:53 you can do that without use, just add bluez-libs to DEPENDS, which is how we worked around it for the mvl6 release Aug 20 16:06:10 but there's no way to disable it, since you can't guarantee that bluez-libs *wasn't* built before it Aug 20 16:06:17 (unless you do something like private staging) Aug 20 16:06:20 yeah Aug 20 16:06:25 I'm just daydreaming a bit Aug 20 16:06:54 but while we're adding stuff, make it say that if we have a use flag, we make sure we do X/Y/Z after we have libc/compiler Aug 20 16:06:57 and before we do normal stuff Aug 20 16:07:19 yeah.. just only so much we can do automatically, eventually it comes down to the recipe maintainer actually *reading* the buildsystem of what it builds, and too few of us do that Aug 20 16:07:26 yeah Aug 20 16:08:07 maybe we should do an audit in that regard at some point. add a flag somewhere indicating its been done for a given recipe, and just go through them. it'll be painful, but.. Aug 20 16:18:28 any opinion on a commit to completely strip out all .la files from both staging and packages? Aug 20 16:18:57 We determined that yes, really, we can kill those stupid things? Aug 20 16:19:11 I've done a number of builds with them ripped out of staging, no problems Aug 20 16:19:16 seem completely unnecessary Aug 20 16:19:31 i'll do some more testing of compiles in the target fs to make sure that part doesn't break anything Aug 20 16:25:35 kergoth: that's a good idea. i remember a time we did this for the toolchains Aug 20 16:55:16 03Michael  07shr/import * r1c5b857f18 10openembedded.git/recipes/images/shr-image.inc: shr-image.inc: protect "$DISPLAY" for evaluating. Aug 20 16:55:17 03Sebastian Krzyszkowiak  07shr/import * r03b5e3a1ed 10openembedded.git/recipes/freesmartphone/frameworkd_git.bb: frameworkd: add python-phoneutils to RDEPENDS Aug 20 16:57:18 03Sebastian Krzyszkowiak  07shr/import * r8eed238472 10openembedded.git/recipes/freesmartphone/opimd-utils_git.bb: Aug 20 16:57:18 opimd-utils: split opimd-cli into different package Aug 20 16:57:18 Signed-off-by: Julien 'Ainulindale' Cassignol Aug 20 18:13:43 re Aug 20 18:25:34 morning Aug 20 18:26:25 hi hrw Aug 20 18:28:33 I returned from long trip just to discover that kde4.3 just lost most of settings on my desktop... Aug 20 18:28:41 F..K Aug 20 18:30:48 hello openembedded internet pals, just came by to say hi and thanks, got my OMAP-L138 build distro working and wanted to come by and say thanks Aug 20 18:32:14 nar: thx Aug 20 18:38:57 nar what are you using for kernel? Aug 20 18:39:39 linux-davinci git Aug 20 18:40:06 We originally got it from TI, but I believe all their changes have been merged into linux-davinci trunk at this point Aug 20 18:44:55 Although I haven't built a recipe for that yet. Aug 20 18:45:25 Still haven't figured out a way better than make MYMODULE=m ... for putting my custom stuff on the board Aug 20 19:27:19 03Chris Larson  07org.openembedded.dev * rf2442f18ec 10openembedded.git/recipes/tar/ (5 files): Aug 20 19:27:19 tar: inherit gettext & use a .inc to avoid duplicated metadata. Aug 20 19:27:19 Signed-off-by: Chris Larson Aug 20 19:34:31 ♥ git merge -s ours Aug 20 19:36:10 hm 19.19 Aug 20 19:48:27 by all Aug 20 19:49:07 nite hrw Aug 20 21:05:41 I'm looking at converting the opie-cvs recipes over to git since opie has switched SCM systems Aug 20 21:06:22 fun :) Aug 20 21:06:23 unfortunately the opie-cvs recipes all rely on subdirectory CVS checkouts, and such checkouts are not supported with git... any suggestions (that don't involve me restructuring the git repo) Aug 20 21:06:43 Tartarus: indeed... Aug 20 21:06:53 Well, you could just modify S Aug 20 21:06:57 and have them all checkout the full thing Aug 20 21:07:02 Or is that too big a dl? Aug 20 21:07:22 (otoh it'll just be dl'd once and all the recipes will use the same source tarball) Aug 20 21:07:56 but if the user has rm_work disabled then that will eat a lot of space... Aug 20 21:08:31 it would also be spending a lot of time copying data around thats ultimately not used in the compilation Aug 20 21:08:32 You could force some of that space back with a do_unpack_2 or whatever Aug 20 21:08:44 see the gcc-csl stuff for an example of a post unpack job Aug 20 21:08:58 * bluelightning looks Aug 20 21:09:02 Yeah, it's downsides all-aronud Aug 20 21:09:04 *around Aug 20 21:09:14 But if you aren't going to restructure opie, I'm not sure what else you can do Aug 20 21:09:26 aside from some sort of specific exports made from the git tree for OE to use here Aug 20 21:09:34 Tartarus: I'm looking at where the package-staging fails to rewrite the path for /cross Aug 20 21:09:45 ok Aug 20 21:09:50 well it kind of doesn't need restructuring apart from this problem... it's only me working on the project right now Aug 20 21:10:03 /pstage/stamp-cache-cross is sane Aug 20 21:10:11 bluelightning: who installed the git server at hh.org? ;) Aug 20 21:10:29 florian: nobody, I migrated the CVS repo to gitorious :) Aug 20 21:10:52 the opie part of it anyway Aug 20 21:11:34 Tartarus: the problem is in the ipk... Aug 20 21:11:40 e.g. I have staging-gcc-cross-armv5te-angstrom-linux-gnueabi_4.3.3-r5.1_i686-linux.ipk Aug 20 21:11:51 bluelightning: .. and you still have a working account? ;) Aug 20 21:12:26 florian: yes, there has been no comment on the matter in fact, neither before nor after the move Aug 20 21:12:30 Tartarus: but in data.tar.gz the 'prefix' armv5te is missing... Aug 20 21:12:43 so the package is just rebuilt in /cross Aug 20 21:12:55 florian: I'm loving it though, git is awesome :D Aug 20 21:13:23 instead of unpacking in /cross/armv5te/... Aug 20 21:13:24 bluelightning: heh Aug 20 21:14:04 Hmm, interesting Aug 20 21:14:06 bluelightning: yes right... i still wait for moe time to try to get some more out of git... more than i do right now. Aug 20 21:14:26 asked kergoth if he's got a fix for that yet? ;) Aug 20 21:15:01 hm..there is apile of commits in queue, it seems Aug 20 21:15:21 florian: I'm not using anywhere near it's full featureset, but for opie, just not having to put up with the annoying limitations and issues that CVS has anymore is brilliant Aug 20 21:15:31 but definitely in stamp-cache-cross there is /oe/build/tmp/cross/armv5te/bin/arm-angstrom-linux-gnueabi-gcc|1250326990|452051 Aug 20 21:15:47 bluelightning: :-) Aug 20 21:18:05 bluelightning: about Opie/qte, there are a lot of recipes (mostly games) in the tree. Wouldn't it be good to unify in a subdir? Aug 20 21:18:46 ant__: the recipes you mean? Aug 20 21:18:56 e.g. zshopi, ztappy, zuc, zudoku.. Aug 20 21:19:29 lot of them starting with Z Aug 20 21:19:36 I had wondered about that.. in fact we already have that for a few games I believe, I forget now which ones Aug 20 21:19:51 Tartarus: Yeah we have a fix in the stream, not sure if its percolated up yet. Aug 20 21:19:52 (I was reordering zaurus-utils, that's why :) Aug 20 21:20:25 ant__: ah, qpe-games Aug 20 21:20:58 I'd put all under ../games Aug 20 21:21:40 actually if the number of recipes increase, it will be necessary to classify/group Aug 20 21:21:50 hmm, yes Aug 20 21:21:59 well, I'm not opposed to the idea Aug 20 21:22:34 of course we do have this whole SDL mess yet to sort out, but that's only tangentially related Aug 20 21:44:07 kergoth: hi Aug 20 21:44:33 I got some hints, it looks like I need these two patches for pstage: http://fr.pastebin.ca/1536938 Aug 20 22:06:07 03ghost  07org.openembedded.dreambox * radfd736808 10openembedded.git/packages/dreambox/dreambox-secondstage.bb: dreambox-secondstage.bb: update dm800 and dm8000 secondstage... needed for 20090820 drivers! Aug 20 22:06:19 03ghost  07org.openembedded.dreambox * r5956a28a24 10openembedded.git/packages/dreambox/dreambox-dvb-modules.bb: Aug 20 22:06:19 dreambox-dvb-modules.bb: update dm800 and dm8000 drivers Aug 20 22:06:19 - better H264 compatibility ... (higher bitrates, more reference frames) Aug 20 22:06:19 - dm800 fix for playback of MPEG2 HD 1080p (converted H264 file with mkv2vob was not working.. green screen) Aug 20 22:06:20 - add VTUNER_SET_FRONTEND_INFO ioctl (ioctl id 6) to set a struct dvb_frontend_info* to set frontend capibilities and frontend type Aug 20 22:06:23 THIS DRIVERS NEEDS AT LEAST SECONDSTAGE 74 !!!!!!!!!!!! Aug 20 22:06:25 03ghost  07org.openembedded.dreambox * r85e9bb36d3 10openembedded.git/packages/dreambox/dreambox-dvb-modules.bb: dreambox-dvb-modules.bb: dm800/dm8000 drivers needs at least secondstage 74 Aug 20 22:06:28 03ghost  07org.openembedded.dreambox.release_25 * r6fd09371cf 10openembedded.git/packages/images/dreambox-image.bb: dreambox-image.bb: add dreambox-tpmd and genuine-dreambox plugins Aug 20 22:06:31 03ghost  07org.openembedded.dreambox.release_25 * rac0ce2756b 10openembedded.git/: Merge branch 'org.openembedded.dreambox.release_25' of git://git.openembedded.net/openembedded into org.openembedded.dreambox.release_25 Aug 20 22:06:37 03ghost  07org.openembedded.dreambox.release_25 * r56b742fade 10openembedded.git/packages/enigma2/enigma2.bb: enigma2: workaround buggy extra_depends on split_packages Aug 20 22:06:40 03ghost  07org.openembedded.dreambox.release_25 * r747cdcf8f2 10openembedded.git/packages/dreambox/dreambox-secondstage.bb: dreambox-secondstage.bb: update dm800 and dm8000 secondstage... needed for 20090820 drivers! Aug 20 22:06:46 03ghost  07org.openembedded.dreambox.release_25 * r4a75dd97f3 10openembedded.git/packages/dreambox/dreambox-dvb-modules.bb: Aug 20 22:06:49 dreambox-dvb-modules.bb: update dm800 and dm8000 drivers Aug 20 22:06:51 - better H264 compatibility ... (higher bitrates, more reference frames) Aug 20 22:06:53 - dm800 fix for playback of MPEG2 HD 1080p (converted H264 file with mkv2vob was not working.. green screen) Aug 20 22:06:55 - add VTUNER_SET_FRONTEND_INFO ioctl (ioctl id 6) to set a struct dvb_frontend_info* to set frontend capibilities and frontend type Aug 20 22:07:00 THIS DRIVERS NEEDS AT LEAST SECONDSTAGE 74 !!!!!!!!!!!! Aug 20 22:27:35 eh..debian guys decided "The ipk archives files are tar files." Aug 20 22:27:41 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382772 Aug 20 22:39:18 03Felix Domke  07org.openembedded.dreambox.release_25 * r27532940e1 10openembedded.git/packages/dreambox/dreambox-tpmd.bb: dreambox-{dccamd,tpmd}: also RDEPEND on wdog Aug 20 22:39:30 03Andreas Oberritter  07org.openembedded.dreambox * r639cbc8ce1 10openembedded.git/packages/twisted/ (3 files): twisted: update to version 8.2.0 Aug 20 22:39:30 03Felix Domke  07org.openembedded.dreambox * rf621acba2f 10openembedded.git/: Merge branch 'org.openembedded.dreambox' of git://git.opendreambox.org/git/obi/opendreambox-1.5 into org.openembedded.dreambox Aug 20 22:39:31 03Felix Domke  07org.openembedded.dreambox * r149e52a5f4 10openembedded.git/packages/dreambox/dreambox-tpmd.bb: dreambox-{dccamd,tpmd}: also RDEPEND on wdog Aug 21 01:30:14 03Michael Smith  07org.openembedded.dev * rfb61d971d4 10openembedded.git/recipes/hicolor-icon-theme/hicolor-icon-theme_0.10.bb: Aug 21 01:30:14 hicolor-icon-theme: don't inherit gnome Aug 21 01:30:14 inherit autotools and gtk-icon-cache instead, so the theme doesn't Aug 21 01:30:14 depend on gconf. Aug 21 01:30:14 Signed-off-by: Michael Smith Aug 21 01:37:01 msmith_: are you sure you don't play ping pong? Aug 21 01:38:00 nevermind :) Aug 21 01:51:07 03Michael Smith  07org.openembedded.dev * r08825f5f10 10openembedded.git/recipes/glibc/ (glibc-package.bbclass glibc.inc): Aug 21 01:51:07 glibc: fix hardcoded /sbin/ldconfig path Aug 21 01:51:07 Put it in ${base_sbindir} instead of /sbin. Bump INC_PR to r34. Aug 21 01:51:07 Signed-off-by: Michael Smith Aug 21 01:51:07 Acked-by: Khem Raj Aug 21 01:53:29 03Michael Smith  07org.openembedded.dev * r3c7bcc004e 10openembedded.git/recipes/gcc/ (7 files): Aug 21 01:53:29 gcc: fix libstdc/libgcc packaging on x86_64 Aug 21 01:53:29 do_install was looking under ${D}/some long cross path/*/lib; Aug 21 01:53:29 needs to be lib64 on x86_64. On x86_64 base_libdir would be set to Aug 21 01:53:29 /lib64, so we can go by that. Aug 21 01:53:31 Bump INC_PR for recent gccs: 4.1.2, 4.2.[34], 4.3.[34], 4.4.1. Aug 21 01:53:33 Signed-off-by: Michael Smith **** ENDING LOGGING AT Fri Aug 21 02:59:56 2009