**** BEGIN LOGGING AT Tue May 19 02:59:57 2009 May 19 03:00:25 Found it May 19 04:23:23 hi May 19 04:23:37 it's seems i'm having problems cross-compiling boost May 19 04:23:55 while other tools & libs are building fine for my arm May 19 04:24:33 when I do "bitbake boost", the libs resulting from that building are actually for x86 (as seen with the file cmd) May 19 06:49:00 good morninig May 19 07:56:00 pb_: hey, ping? May 19 08:01:46 03Previdi Roberto  07org.openembedded.dev * r04e583d2be 10openembedded.git/ (4 files in 2 dirs): (log message trimmed) May 19 08:01:46 zenity package May 19 08:01:46 Please ignore my previous zenity patches. I collected all in one May 19 08:01:46 single patch this time so it should be more handy to use. May 19 08:01:46 The package zenity allows to use powerful graphic dialogs from the May 19 08:01:48 shell or scripts without effort. I added some patches to build fine May 19 08:01:50 (makefile.patch and no-gnome-doc.patch) and one patch to add a little May 19 08:01:52 03Koen Kooi  07org.openembedded.dev * r58483e2d58 10openembedded.git/ (conf/checksums.ini recipes/gnome/zenity_2.26.0.bb): zenity: add 2.26.0 May 19 08:01:57 03Koen Kooi  07org.openembedded.dev * r26b65117eb 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: remove opkg-native from clean list May 19 08:02:00 03Koen Kooi  07org.openembedded.dev * r6788438bed 10openembedded.git/contrib/angstrom/upload-packages.sh: angstrom feed uploader: use partial mode in rsync May 19 08:05:29 03Koen Kooi  07org.openembedded.dev * rc0121b6327 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom-feed-builder: add zenity May 19 08:25:54 zecke: yo May 19 08:26:21 pb___: do you remember why you decided to use feeder in package.bbclass? May 19 08:28:00 for the run_hooks() stuff, you mean? May 19 08:28:20 probably just because it was a convenient way of deserializing the function data from disk and getting it into a runnable form May 19 08:28:30 pb___: yes, feeder vs. bb.parse.include? May 19 08:29:45 hm, not sure. either bb.parse.include() didn't exist at the time, or it didn't do what I needed, or I just overlooked its existence. I don't remember which, I'm afraid. May 19 08:30:27 pb___: I have changed the signature of feeder :) May 19 08:30:44 ah, heh May 19 08:30:57 well, feel free to adapt the package.bbclass bits to use include() if you think that will work May 19 08:31:09 morning all May 19 08:31:39 pb___: hehe, yeah, will have to do it. do you know an easy way to do it? May 19 08:32:24 zecke: not offhand. if I did, I would have done it that way to start with :-} May 19 08:35:29 pb___: oh sorry, I meant do you have an easy way to test parsing of the hooks? May 19 08:35:37 pb___: or do you remember one? could think of one? May 19 08:38:00 zecke: you can easily enough make a testcase, just create a package that defines a python function and saves it with package_stash_hook() May 19 08:38:24 then you should find that your function is run during packaging for all subsequent builds May 19 08:38:25 pb___: the stuff we write out is a simple python method with the bitbake syntax for it? right? May 19 08:38:29 right May 19 08:38:50 what is the filename of these files? May 19 08:39:09 ${PKGDATA_DIR}/hooks/${PN} May 19 08:39:25 see package_stash_hook() again :-} May 19 08:40:05 hehe, I see why include bb.parse.handle failed for you :) May 19 08:40:09 no known file extension May 19 08:40:19 ah, maybe that was it May 19 08:41:44 I think there might have been some other stuff that handle() does and I didn't want May 19 08:42:39 oh, actually, the filename is ${PKGDATA_DIR}/hooks/HOOK_NAME/${PN} May 19 08:43:11 where HOOK_NAME is the second argument to package_stash_hook(), or the first one to package_run_hooks() May 19 08:43:33 practically speaking it's the name of one of the functions listed in PACKAGEFUNCS, though it doesn't strictly need to be May 19 08:46:21 bbiab, heading to my office now May 19 08:46:22 * pb___ -> May 19 08:46:49 <- ___bp * May 19 08:53:26 good morning May 19 08:55:47 do you think that changing BBPATH from within *.conf files is something we want? May 19 08:58:15 morning May 19 08:58:22 hrw|gone: ping? May 19 09:00:26 zecke: yes May 19 09:01:33 zecke: I do it within local.conf and I suspect kergoth is doing that too May 19 09:01:40 RP: where do we do this? May 19 09:01:53 RP: ah okay, but to find the local.conf we need to have a BBPATH? May 19 09:03:31 zecke: yes, but that doesn't mean you don't want to change it May 19 09:03:53 RP: what is your usecase? May 19 09:04:10 RP: why change in conf/local.conf and not have it right at the start? May 19 09:04:44 the issue I'm facing is, that after starting to parse a lookup of relative paths will be different :) May 19 09:05:04 which means during evaluation of a file, I have to parse again... which kinda sucks :) May 19 09:07:28 RP: Does bitbake generally build the latest version as well when I build "bitbake $recipe-$olderversion"? May 19 09:07:47 It does at least for me in minimal distro and I think I saw this with angstrom, too May 19 09:09:22 anyway... so I can't take the easy route... :( May 19 09:10:08 zecke: I think its a feature we do use :/ May 19 09:10:35 Laibsch: bitbake recipe-oldversion is a bit of a hack which doesn't really work anymore May 19 09:11:29 RP: pong May 19 09:11:30 morning May 19 09:12:23 RP: that's rather sad. when did it get broken? May 19 09:12:50 RP: it makes optimizing the parse tree rather hard :( May 19 09:14:26 RP: what's up? May 19 09:15:07 RP: Anything else to replace it? May 19 09:15:21 there's always -b May 19 09:15:27 if you build the deps manually May 19 09:15:29 morning folks, btw. May 19 09:15:54 morning mickeyl ! May 19 09:16:50 pb_: I suspect it would be with the change from reicpe to task granularity May 19 09:17:04 mickeyl: good morning May 19 09:17:04 It would probably be possible to fix it May 19 09:17:52 hrw: You mentioned ldconfig-native didn't work for you a while back - was that building on 64 bit for a 32 bit platform? May 19 09:18:41 RP: yes May 19 09:18:51 RP: 64bit host and 32bit arm/x86 May 19 09:18:55 hrw: Did 32 for 32 bit work? May 19 09:19:07 RP: did not tried May 19 09:19:11 RP: okay, thanks, I'll bear that in mind May 19 09:19:56 pb_: Thinking about it, it probably is fixable May 19 09:20:18 but I don't know exactly why it builds both the most recent and the version specified May 19 09:20:25 FYI: Amethyst has a high load and the website is very slow to respond May 19 09:20:34 Looks like some runaway postgres processes May 19 09:21:45 hrw: ok, that confirms a problem, thanks May 19 09:23:32 bb in ~1h May 19 09:29:40 Do you guys get "fatal: The remote end hung up unexpectedly" as frequently on git pull as I do? May 19 09:30:24 How can I make BitBake give me a .tar.gz of a package instead of a .ipkg? I'm doing 'bitbake helloworld' and the target sys does not support .ipkg. Do .bb files have a target package format variable for this? May 19 09:31:01 Laibsch: yes I get that msg quite often. May 19 09:31:43 xanalogica__: don't know but you could do "rgrep tar classes/" May 19 09:32:04 I know you can have an image in tar.gz format May 19 09:32:32 xanalogica__: Use INHERIT "package_tar" instead of "package_ipk" May 19 09:34:27 Can somebody help me understand why "bitbake opie-image" builds fso-gsm0710muxd? "bitbake -g opie-image;grep gso *depends.dot" does not clarify this except it lists it among the tasks to build. May 19 09:34:57 Laibsch: Have a look at the tdepends.dot file May 19 09:35:07 ah, that one is new May 19 09:35:12 to me May 19 09:35:13 thanks May 19 09:35:39 oh, you mean task-depends.dot? May 19 09:36:05 I can't gather from there as to why it wants to build it May 19 09:36:16 Laibsch: sorry, yes May 19 09:36:28 It would look to me like opie-image depends on this fso package directly May 19 09:36:43 but inspecting the opie-image.bb file confirms this is not the case May 19 09:36:49 Laibsch: can you pastebin that file greped for fso-gsm... May 19 09:37:08 RP: thanks very much, I've been reading the wiki/FAQ for some time for that tip. May 19 09:37:22 Laibsch: All that dependency means is that the image can't build until that package is ready which makes sense May 19 09:37:36 Laibsch: Why its being pulled in will be somewhere else May 19 09:38:44 RP: grep fso task-depends.dot: http://rafb.net/p/Io3o2h68.html May 19 09:39:11 could be the mickeyterm May 19 09:41:13 03Rolf Leggewie  07org.openembedded.dev * r6f40c70d22 10openembedded.git/conf/checksums.ini: checksums.ini: add entry for gnome-mplayer 0.5.3. May 19 09:41:13 03Rolf Leggewie  07org.openembedded.dev * re3a1ba3b28 10openembedded.git/recipes/minilite/ (8 files): minilite: unify May 19 09:41:15 Laibsch: I'd guess mickeyterm RDEPENDS on it May 19 09:42:20 yes, looks like it May 19 09:42:30 now I wonder where the dependency on mickeyterm is coming from May 19 09:42:37 Let me see if I can find that May 19 09:42:52 This being minimal it seems kind of natural May 19 09:43:02 and assumptuous at the same time ;-) May 19 09:44:56 mickeyl: How does mickeyterm end up being built for images in minimal? May 19 09:45:15 Building for qemuarm or spitz I don't really need it, I think May 19 09:46:20 Laibsch: what image are you trying to build? May 19 09:46:25 via task-cli-tools May 19 09:46:30 i guess May 19 09:46:31 I doubt anything in minimal.conf itself is pulling in mickeyterm May 19 09:47:03 yeah, the grep of truth reveals that task-cli-tools and illume-image both have dependencies on mickeyterm May 19 09:47:08 re May 19 09:47:31 then again May 19 09:47:38 minimal.conf does not pull in task-cli-tools May 19 09:47:42 but rather task-cli-tools-debug May 19 09:48:00 which is ok May 19 09:48:25 so i guess it comes in via an image rather than the distro May 19 09:48:29 yah, it's actually task-cli-tools-python which depends on mickeyterm May 19 09:48:34 *nod* May 19 09:48:36 that's ok so far May 19 09:48:56 If possible, I'd like to build an image without that FSO stuff, of course May 19 09:49:02 hehe May 19 09:49:07 not that I don't like FSO, of course ;-) May 19 09:49:10 Laibsch: is mickeyterm actually getting shipped in your image, or is it just the fact that it gets built that's upsetting you? May 19 09:49:22 I'm not sure it's being shipped May 19 09:49:26 and I'm not upset May 19 09:49:39 It's just that I'm very strapped for CPU cycles May 19 09:50:07 And when I see something being built that I don't think is really necessary, I start to look into the matter ;-) May 19 09:50:23 if you wanted to stop it getting built at all, without ditching the whole of task-cli-tools-debug, you'd probably need to explode that .bb file into three separate ones. May 19 09:50:56 as things stand right now, bitbake will have to build task-cli-tools.bb in order to satisfy task-cli-tools-debug, and that in turn will cause all the rdepends for the other PACKAGES in that .bb file to get built even though they aren't going to be shipped. May 19 09:51:58 the thing is that minimal distro force you to have task-cli-tools-debug unless DISTRO_TYPE = "release" May 19 09:52:09 thats insane for me May 19 09:52:12 but, if you don't want to debug, you might find that just eliminating task-cli-tools-debug from your distro configuration is the easiest way to work around it. May 19 09:54:17 hmm.. I see lot of missing u-a in my angstrom system ;( May 19 09:54:33 hrw: it doesn't seem completely unreasonable to install debugging tools under DISTRO_TYPE=debug. isn't this exactly what DISTRO_TYPE is for? May 19 09:55:45 pb_: our build times are being longer and longer and longer May 19 09:55:59 possibly the conditional should actually be DISTRO_TYPE==debug, rather than DISTRO_TYPE != release, so that you don't get them in alpha images, but that seems like a minor technicality. May 19 09:56:23 before bluez4 simple 'bitbake console-image' was under 2K. now it is over 2K because we build gstreamer, x11 for bluez. May 19 09:56:36 hrw: well, sure, but in this particular case you are only getting debug tools if you ask for them. May 19 09:56:37 using minimal distro adds python to that May 19 09:56:54 hrw: what effect would you expect DISTRO_TYPE=debug to have, if not to turn on debugging? May 19 09:57:04 pb_: minimal distro adds them always May 19 09:57:35 really? May 19 09:57:38 yes May 19 09:57:38 DISTRO_EXTRA_APPS += '${@base_conditional("DISTRO_TYPE", "release", "", "task-cli-tools-debug",d)}' May 19 09:57:44 that looks like it won't add them for release builds May 19 09:57:50 at least, it looks like that's the intended effect May 19 09:57:51 and DISTRO_TYPE="debug" few lines up May 19 09:57:54 if it isn't working, I guess that'd just be a bug. May 19 09:58:08 and DISTRO_TYPE="debug" few lines up *hardcoded* May 19 09:58:46 sure, but it's trivial to change that. there's even a commented-out example on the adjacent line to show you what to do. May 19 09:59:09 it's not as if this is deeply embedded into some immutable thing. May 19 09:59:13 sure, but I need to change distro config for that so I can remove DISTRO_EXTRA_APPS too (and will rather remove that) May 19 10:00:03 I hope that we will not get to moment when "bitbake console-image" will take day on 8core systems because 10K tasks needs to be done May 19 10:00:19 do you know that building tcpdump require gstreamer? May 19 10:01:18 no, why's that? May 19 10:01:34 bluez? May 19 10:01:45 The sane thing would be DISTRO_TYPE ?= "debug" May 19 10:02:18 yeah, that seems like it should be uncontroversial enough May 19 10:02:43 oh ha May 19 10:03:53 some one wants to test my refactoring? May 19 10:04:22 (will do some refactoring myself against a "gold" set) May 19 10:04:45 florian: good morning May 19 10:05:31 pb_: bluez May 19 10:05:58 hi May 19 10:06:00 mickeyl: do you know if a good map/reduce implementation for python exists? I want to distribute some stuff to the different cores I have here... May 19 10:06:11 pb_: tcpdump -> libpcap -> bluez-libs (which is bluez4 is most distros) May 19 10:06:20 hrw: that seems like it's simply a bug in the bluez packaging. May 19 10:06:22 zecke: not offhand May 19 10:06:36 it's bluez-utils that needs gstreamer, not bluez-libs. May 19 10:07:22 those packages do seem to have become conflated in bluez4 but I think they simply need to be separated out again. May 19 10:07:38 What does OE currently do with ld.so.cache? Rebuild at every boot? May 19 10:08:14 RP: it varies. some machines ship a static copy, some build it in tmpfs at boot time, some store it in flash, and some don't use it at all. May 19 10:08:33 personally I favour not using it at all, but it depends on your target environment May 19 10:09:14 pb_: bluez4 is libs+utils in one May 19 10:09:26 pb_: Is not using it not a performance hit? May 19 10:09:36 * zecke thinks dynamic linking is for sissies... May 19 10:10:29 RP: not necessarily; it depends on your filesystem layout. If you can arrange for most/all libraries to be in the first place that ld.so would look anyway (i.e. not scattered around in /opt/qtopia and the like) then there's no performance hit from not having the cache. May 19 10:10:54 indeed, it's probably faster for ld.so to just stat() the libraries in place than to read the cache, if it would have ended up looking in the same place anyway. May 19 10:11:11 pb_: true May 19 10:11:12 zecke: google for "python map reduce"; there are several solutions (octo.py among others). May 19 10:11:20 having the cache is faster if either you have lots of search paths in ld.so.conf, or if you are making lots of use of hwcaps May 19 10:11:35 Sadly, I have some insanely located libs :( May 19 10:11:44 * RP stabs xulrunner May 19 10:11:50 (or if you have lots of spurious rpaths in your binaries, but hopefully that isn't happening much these days) May 19 10:12:11 xanalogica__: didn't find that one... I have found various other bullshit :) May 19 10:12:21 Yes, hopefully the rpath issues are resolved May 19 10:12:21 hrw: indeed, as I said: they appear to have become conflated and needs to be re-separated. May 19 10:12:35 I don't think there's any fundamental reason why you can't build the libraries from bluez4 without building everything. May 19 10:12:47 xanalogica__: thanks, octo.py seems a good match1 May 19 10:13:10 indeed, there might even be a reasonable argument for splitting the apps part up further, so that people who don't want to use the audio bits (most folks, I suspect) don't end up needing gstreamer May 19 10:14:27 RP: yah, if you have libraries in crazy places and you can't move them, you probably are stuck with needing ld.so.cache. for mythfront, I actually managed to dispense with /usr/lib as well and just installed all the libraries directly in /lib, which seemed to work well. May 19 10:14:38 xanalogica__: hmm... it distributes across different systems... I want it to be python threads :} May 19 10:14:55 RP: ... though, that said, if these are libraries that you don't need very often, you might find that the performance hit from having to search for them in two places is not all that bad. May 19 10:15:02 pb_: I could probably try and move things around but not now, I jsut need to make this work as is May 19 10:15:22 fair enough. well, it'll work fine without ld.so.cache, just not quite as fast as with the cache. May 19 10:15:29 pb_: OE's standard bootmisc.sh runs ldconfig on anything other than openmoko May 19 10:15:59 yeah, that's probably a misfeature May 19 10:17:12 zecke: try http://blog.doughellmann.com/2009/04/implementing-mapreduce-with.html for spreading across processes; Python's GIL prevents many thread-based approaches to multicores. May 19 10:17:25 and then we patch glibc to put the cache into /var/run/volatile May 19 10:17:36 Well, /var/run which is a volatile May 19 10:17:38 anyway today I plan rather fix task-proper-tools then fight with too long build times May 19 10:18:15 some parser patches... not yet for speed... http://page.mi.fu-berlin.de/freyther/bitbake/parser/ May 19 10:19:12 xanalogica__: I thought the global lock is not that bad :) May 19 10:20:43 RP: yeah, that's a bit odd. some glibc versions do that and some don't. I think we used to just install a symlink from /etc/ld.so.cache -> /var/run/ld.so.cache but I guess someone didn't like that. May 19 10:20:57 heh.. we waste 3x280KB with e2fsprogs-fsck* May 19 10:21:55 zecke: global lock is not bad for threads blocking on I/O but not for compute-bound multicore problems. Jython and IronPython don't have this issue, nor will Unladen Swallow when Google finishes with it. May 19 10:22:19 xanalogica__: I want to move the parsing to different threads :) May 19 10:22:33 xanalogica__: so it is both io and cpu bound May 19 10:43:23 git can switch all too easily between branches and I don't want that to mess up my TMPDIR. I have therefor added a post-checkout hook to git which writes out a file ".git/openembedded/branch.conf:GIT_BRANCH="org.openembedded.dev"' May 19 10:44:08 I then source .git/openembedded/branch.conf and include $GIT_BRANCH in my definition of TMPDIR. Working nicely, except May 19 10:45:44 "git checkout $file" messes this up, the contents of .git/openembedded/branch.conf don't change, but bitbake assumes $GIT_BRANCH is "" afterwards :-( Why is that? May 19 10:51:24 03Koen Kooi  07xora/angstrom-srcpv * r4fb5e283e6 10openembedded.git/recipes/xserver-common/ (files/89xdgautostart.sh xserver-common_1.24.bb): xserver-common: add xdg-autostart support (from poky) May 19 10:51:29 03Koen Kooi  07xora/angstrom-srcpv * rcc4e74ff5f 10openembedded.git/ (2 files in 2 dirs): util-linux-ng: update to 2.15 May 19 10:51:37 03Koen Kooi  07xora/angstrom-srcpv * rc7747266be 10openembedded.git/ (6 files in 3 dirs): May 19 10:51:37 e2fsprogs(-native): update to 1.41.5 May 19 10:51:37 * add staging tweak from poky to get stuff into /bin instead of /sbin May 19 10:51:50 03Koen Kooi  07xora/angstrom-srcpv * r563519c636 10openembedded.git/recipes/udev/ (7 files in 6 dirs): udev 141: add /dev cache, install binaries to the correct locations May 19 10:51:59 03Koen Kooi  07xora/angstrom-srcpv * r5c194b6adf 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 19 10:52:12 03Koen Kooi  07xora/angstrom-srcpv * r7790e2eda3 10openembedded.git/recipes/udev/ (udev-141/local.rules udev_141.bb): May 19 10:52:12 udev 141: add fb0 -> fb symlink to make X happy May 19 10:52:12 * X starts, but hal doesn't see devices anymore May 19 10:52:12 03Koen Kooi  07xora/angstrom-srcpv * r3d1136959a 10openembedded.git/recipes/util-linux-ng/ (4 files in 2 dirs): util-linux-ng 2.15: stage libblkid (yes, this used to be in e2fsprogs(-libs)) May 19 10:52:19 03Koen Kooi  07xora/angstrom-srcpv * r4e3165e4bb 10openembedded.git/ (3 files in 2 dirs): hal: add (disabled) hal 0.5.12 May 19 10:52:24 03Koen Kooi  07xora/angstrom-srcpv * r38cea1ff24 10openembedded.git/ (4 files in 3 dirs): e2fsprogs-libs: update to 1.41.5, split out libs May 19 10:52:37 03Koen Kooi  07xora/angstrom-srcpv * r76ca0113de 10openembedded.git/ (conf/checksums.ini recipes/hal/hal-info_20090414.bb): hal-info: update to 20090414 May 19 10:52:42 03Koen Kooi  07xora/angstrom-srcpv * r61f0ac5601 10openembedded.git/recipes/util-linux-ng/ (util-linux-ng.inc util-linux-ng_2.15.bb): util-linux-ng: split out libs to avoid collision with e2fsprog-libs May 19 10:52:48 03Florian Boor  07xora/angstrom-srcpv * rb6242ec579 10openembedded.git/recipes/pointercal/ (files/topas910/pointercal pointercal_0.0.bb): pointercal: Add support for the Topas 910. May 19 10:52:53 03Florian Boor  07xora/angstrom-srcpv * r1a38b91d59 10openembedded.git/recipes/xserver-kdrive-common/ (2 files in 2 dirs): xserver-kdrive-common: Run calibration script before window manager and change names in bb accordingly. May 19 10:52:53 03Florian Boor  07xora/angstrom-srcpv * r1fc28fb048 10openembedded.git/recipes/python/ (python-2.6.1/07-export-grammer.patch python_2.6.1.bb): python: Add patch to fix linking May 19 10:52:55 03Koen Kooi  07xora/angstrom-srcpv * r856f9cecac 10openembedded.git/conf/distro/angstrom-2008.1.conf: angstrom 2009.X: weakly assign OLDEST_KERNEL May 19 10:52:57 03Koen Kooi  07xora/angstrom-srcpv * rb04cc935db 10openembedded.git/conf/bitbake.conf: bitbake.conf: weakly assign OLDEST_KERNEL ?= "2.4.0" *after* machine and distro configs are included May 19 10:53:00 03Florian Boor  07xora/angstrom-srcpv * r798c780a3a 10openembedded.git/recipes/icu/ (files/rematch-gcc-bug.patch icu_3.6.bb): icu: Apply patch working around a gcc bug. May 19 10:53:05 03Marcin Juszkiewicz  07xora/angstrom-srcpv * rea51d805b9 10openembedded.git/recipes/psplash/ (files/bug/psplash-default psplash.inc psplash_svn.bb): May 19 10:53:08 psplash: added BUG support May 19 10:53:10 BUG has 3 framebuffers: May 19 10:53:12 fb0 is BUGbase 160x105 monochrome LCD used for fbprogress and BUG menu May 19 10:53:14 fb1, fb2 are used by LCD modules (QVGA resolution) May 19 10:53:16 03Koen Kooi  07xora/angstrom-srcpv * rd71e3cdf4d 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: util-linux-ng: fix dep loop May 19 10:53:31 03Florian Boor  07xora/angstrom-srcpv * r0bddb9342c 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs: Add gpe-mini-browser 2 May 19 10:53:37 03Rolf Leggewie  07xora/angstrom-srcpv * r2f5a647c16 10openembedded.git/recipes/flac/flac.inc: flac: add HOMEPAGE and simplify do_stage May 19 10:53:47 03Rolf Leggewie  07xora/angstrom-srcpv * r6d1b0baf0c 10openembedded.git/ (5 files in 2 dirs): May 19 10:53:47 flac: add 1.2.1. (Closes: #4386) May 19 10:53:47 * move disable-xmms-plugin.patch from SRC_URI in .inc to May 19 10:53:47 1.1.0 and 1.1.2 bb file. Does not apply cleanly to 1.2.1. May 19 10:53:48 Unsure if it would still be needed at runtime or not, but May 19 10:53:50 1.2.1 otherwise compiles fine. May 19 10:53:52 03Paul Eggleton  07xora/angstrom-srcpv * r15f147680d 10openembedded.git/recipes/opie-packagemanager/ (3 files in 2 dirs): opie-packagemanager: support opkg and split feed files in 1.2.4 version May 19 10:53:58 03Rolf Leggewie  07xora/angstrom-srcpv * r3719c19256 10openembedded.git/ (conf/checksums.ini recipes/granule/libassa_3.4.2.bb): libassa: update to 3.5.0. 3.4.2 was incompatible with the libtool we use now. May 19 10:54:02 03Koen Kooi  07xora/angstrom-srcpv * r6788438bed 10openembedded.git/contrib/angstrom/upload-packages.sh: angstrom feed uploader: use partial mode in rsync May 19 10:54:07 03Koen Kooi  07xora/angstrom-srcpv * r26b65117eb 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: remove opkg-native from clean list May 19 10:54:10 03Previdi Roberto  07xora/angstrom-srcpv * r04e583d2be 10openembedded.git/ (4 files in 2 dirs): (log message trimmed) May 19 10:54:13 zenity package May 19 10:54:15 Please ignore my previous zenity patches. I collected all in one May 19 10:54:17 single patch this time so it should be more handy to use. May 19 10:54:19 The package zenity allows to use powerful graphic dialogs from the May 19 10:54:21 shell or scripts without effort. I added some patches to build fine May 19 10:54:23 (makefile.patch and no-gnome-doc.patch) and one patch to add a little May 19 10:54:29 03Koen Kooi  07xora/angstrom-srcpv * r58483e2d58 10openembedded.git/ (conf/checksums.ini recipes/gnome/zenity_2.26.0.bb): zenity: add 2.26.0 May 19 10:54:32 03Koen Kooi  07xora/angstrom-srcpv * rc0121b6327 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom-feed-builder: add zenity May 19 10:54:35 03Rolf Leggewie  07xora/angstrom-srcpv * r6f40c70d22 10openembedded.git/conf/checksums.ini: checksums.ini: add entry for gnome-mplayer 0.5.3. May 19 10:54:40 03Rolf Leggewie  07xora/angstrom-srcpv * re3a1ba3b28 10openembedded.git/recipes/minilite/ (8 files): minilite: unify May 19 10:54:43 03Graeme Gregory  07xora/angstrom-srcpv * r5854557425 10openembedded.git/: May 19 10:54:45 Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 19 10:54:47 Conflicts: May 19 10:54:49 recipes/psplash/psplash.inc May 19 10:57:18 -rw-rw-rw- 1 hrw hrw 460180 05-18 15:13 e2fsprogs-e2fsck_1.41.5-r0.2_armv5te.ipk May 19 10:57:18 -rw-rw-rw- 1 hrw hrw 154058 05-19 12:56 e2fsprogs-e2fsck_1.41.5-r1.2_armv5te.ipk May 19 10:57:34 nice difference May 19 10:58:00 would it be possible to omit the xora/angstrom-srcpv branch from CIA? May 19 10:58:01 mke2fs package is 97K instead of 289K May 19 10:58:18 tune2fs is 86K instead of 256K May 19 10:58:23 and same functionality... May 19 10:58:39 hrw: i just files a patch for e2fsprogs-libs the do_package failed on my machine: pr 5101 May 19 10:59:15 !oebug 5101 May 19 10:59:17 * * Bug 5101, Status: HTTP transfer failed :( May 19 10:59:25 xranby: send patch to OE ML May 19 10:59:30 hrw: very good. is this static vs dynamic linking, or something else? May 19 11:00:12 pb_: not shipping few copies but using links instead May 19 11:00:32 hrw: ok http://bugs.openembedded.net/show_bug.cgi?id=5101 - e2fsprogs-libs : unexpected keyword argument 'allow_links' May 19 11:00:37 pb_: before we had mke2fs mkfs.ext[2344dev]. now we have one May 19 11:00:47 hrw: heh, it's a bit sad that nobody noticed that before. May 19 11:00:58 xranby: allow_links is proper argument May 19 11:01:06 xranby: which bitbake you use? May 19 11:01:13 xranby: and how old OE? May 19 11:01:35 pb_: e2fsprogs recipes are ugly May 19 11:01:41 hrw: im using bitbake from svn trunk rev 1179 May 19 11:01:45 maybe we should ask zecke to create a bbclass that detects multiple copies of the same file in an output package and prints some suitable warning May 19 11:02:05 xranby: and oe? May 19 11:02:17 03Koen Kooi  07org.openembedded.dev * rd962d391fa 10openembedded.git/ (70 files in 3 dirs): linux-omap 2.6.29: refresh dss2 patchset May 19 11:02:48 hrw: and org.openembedded.dev from just munutes ago May 19 11:02:59 hrw: the git tree May 19 11:04:47 strange May 19 11:04:50 checking May 19 11:04:59 hrw: is there a dependency on python version? May 19 11:05:28 hrw: i use python 2.5.2 for the record May 19 11:05:56 2.x is ok as long as it is 2.4+ May 19 11:08:06 * * OE Bug 5101 has been created by xerxes(AT)zafena.se May 19 11:08:08 * * e2fsprogs-libs : unexpected keyword argument 'allow_links' May 19 11:08:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5101 May 19 11:14:38 03Marcin Juszkiewicz  07org.openembedded.dev * r8acc5061cc 10openembedded.git/recipes/e2fsprogs/e2fsprogs_1.41.5.bb: May 19 11:14:38 e2fsprogs: improve packaging for 1.41.5 to not waste rootfs space May 19 11:14:38 There is no need to ship mke2fs + mkfs.ext[2344dev] as separate May 19 11:14:38 binaries. Same goes to e2fsck and fsck.ext[2344dev]. May 19 11:19:24 03Lynn Lin  07org.openembedded.dev * ra5f902c677 10openembedded.git/classes/package_rpm.bbclass: package_rpm: fix move wrong generated rpm name - closes #5078 May 19 11:21:04 /bin/chattr or /usr/bin/chattr? May 19 11:21:11 we have both now May 19 11:23:44 I think /usr/bin/chattr is more conventional. May 19 11:24:30 thats how debian do that May 19 11:25:04 I think that I will generate a list May 19 11:25:51 hrw: do e2fsprogs-libs build on your machine? on my machine e2fsprogs built fine yet e2fsprogs-libs dont build May 19 11:26:01 xranby: 1.41.2 builds May 19 11:29:27 mickey|sun: is there a MRU/LRU in python? May 19 11:34:59 how do I find out who committed 04e583d2be81fd42f36bb79eb7b3d64ab8deaf99? I think that revision maybe should be disapproved before being applied again after rework. May 19 11:35:33 <_cpo_> Laibsch: http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=04e583d2be81fd42f36bb79eb7b3d64ab8deaf99 May 19 11:35:33 !oebug 5078 May 19 11:35:34 * * Bug 5078, Status: RESOLVED (FIXED), Created: 2009-04-08 14:07 May 19 11:35:35 * * lynn.lin(AT)avocent.com: \[patch\] fix move wrong generated rpm name in package_rpm .bbclass May 19 11:35:36 * * http://bugs.openembedded.net/show_bug.cgi?id=5078 May 19 11:35:48 <_cpo_> Previdi Roberto May 19 11:36:02 no May 19 11:36:10 _cpo_: no, that is the author May 19 11:36:15 not the one doing the commit May 19 11:36:22 Laibsch: er? May 19 11:36:28 <_cpo_> cgit will tell you commiter May 19 11:36:35 <_cpo_> it was Koen Kooi May 19 11:36:44 I don't think Roberto has commit rights May 19 11:36:53 author Previdi Roberto 2009-04-28 10:51:39 May 19 11:36:53 committer Koen Kooi 2009-05-19 07:54:07 May 19 11:36:57 <_cpo_> Laibsch check header of http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=04e583d2be81fd42f36bb79eb7b3d64ab8deaf99 May 19 11:37:07 * * OE Bug 5078 has been RESOLVED (FIXED) by openembedded(AT)haerwu.biz May 19 11:37:08 Laibsch: look at the second line :-} May 19 11:37:09 * * fix move wrong generated rpm name in package_rpm .bbclass May 19 11:37:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5078 May 19 11:37:13 <_cpo_> :) May 19 11:37:14 Indeed May 19 11:37:29 I wonder how to do that one the command line May 19 11:37:40 But I can live with cgit May 19 11:38:03 xranby: sorry if I am interrupting - but I just built it, and for that I had to manually fetch it :P , something wrong with the SRC_URL. May 19 11:38:30 <_cpo_> maybe because it's SRC_URI instead of SRC_URL? May 19 11:38:34 Laibsch: git-show --pretty=full, maybe May 19 11:38:39 That commit doesn't look like it makes a lot of sense, shouldn't those patches be in recipes/zenity/files or recipes/zenity/zenity? May 19 11:38:53 pb_: cool, thanks. will take a look May 19 11:38:54 or fuller, or fullest, or something May 19 11:40:57 as for whether it should be in recipes/gnome or recipes/zenity, dunno, I don't think it makes a great deal of difference. May 19 11:41:08 full works May 19 11:41:17 I don't think zenity is strictly a gnome package but I would find it hard to get too worked up about. May 19 11:41:27 yeah, I guess it's not the best of commits, but it does not really affect me May 19 11:41:40 actually, it does do "inherit gnome", so I guess it qualifies as being gnome for our purposes May 19 11:41:49 It just kind of stuck out of qgit because the commit message looks so meaningless May 19 11:41:57 that must mean that its sources are on ftp.gnome.org, which is about the only criterion we have for gnomishness May 19 11:42:07 yeah, that is fine May 19 11:42:26 yeah, agreed, the commit message is pretty much gibberish May 19 11:42:41 I stumbled across it because of the commit message. And then when I looked at it, I thought "wow, those files are put into a weird place" May 19 11:42:57 * Laibsch shrugs May 19 11:43:07 but I was curious May 19 11:43:11 and now I know ;-) May 19 11:43:21 yeah, oh well, crazy koen. May 19 11:44:12 I suppose one could revert that checkin on the grounds that he hasn't conformed to his own unilaterally-imposed checkin message policy, but I think life is probably too short. May 19 11:44:15 heh we should start checking for large noses and ears May 19 11:44:45 heh May 19 11:45:45 I assume it must have been a glitch. Something about the tools he uses with git. May 19 11:47:19 can I get anyone to test bitbake parser patches? May 19 11:47:52 zecke: I can try them, but not this minute May 19 11:48:07 lunchtime first :-} May 19 11:48:21 looks like a git-am applied patch May 19 11:48:52 pb_: cool, will search some food too... I traded ram for speed... once again May 19 11:49:10 zecke: right, ram is expendable May 19 11:49:52 I have been programming in java recently, I am quite sanguine about needing at least 8GB in order to do anything May 19 11:52:21 * pb_ -> May 19 11:54:02 pb_: you joined the dark side :-) May 19 11:55:47 after all these years I still haven't found a good cache in python... May 19 11:58:43 03Marcin Juszkiewicz  07org.openembedded.dev * r999d3b511e 10openembedded.git/recipes/util-linux-ng/ (util-linux-ng_2.14.bb util-linux-ng_2.15.bb): util-linux-ng: dropped use of FILESPATH May 19 11:58:47 03Marcin Juszkiewicz  07org.openembedded.dev * re04a5a65d9 10openembedded.git/recipes/tasks/task-proper-tools.bb: task-proper-tools: sort alphabetically May 19 11:58:50 03Marcin Juszkiewicz  07org.openembedded.dev * r89489b1cea 10openembedded.git/recipes/tasks/task-proper-tools.bb: task-proper-tools: added few extra packages May 19 12:06:18 pb_: http://page.mi.fu-berlin.de/~freyther/bitbake/parser... apply all of them, the later should be a performance win (at cost of some ram, no proper caching yet) May 19 12:06:41 pb_: I go from 3.38 to 2.40 with these on my bitbake -p minimal-image benchmark May 19 12:07:02 pb_: the only victim is package.bbclass :) May 19 12:16:28 ERROR: Build of /home/dp/openembedded/org.openembedded.dev/recipes/util-linux-ng/util-linux-ng_2.15.bb do_configure failed May 19 12:16:53 hm. builds here May 19 12:17:49 /home/dp/openembedded/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -luuid May 19 12:17:59 missed a DEPEND it seems May 19 12:24:07 03Koen Kooi  07org.openembedded.dev * r72060aa173 10openembedded.git/recipes/gnome/zenity/ (fingerscroll.patch makefile.patch no-gnome-doc.patch): zenity cruft: remove files that a failed attemp at using git-am put there May 19 12:40:36 RP: Is it intentional that "bitbake -c rm_work" goes through all the steps again including configure (and compile, I assume)? May 19 12:43:37 * pb_ returns! May 19 12:43:42 zecke: okay, I'll try them out presently May 19 12:44:26 pb_: cool, your classes/package.bbclass will see some runtime errors due the feeder May 19 12:45:37 righto, I'll just comment that out for now May 19 12:46:07 actually, I'm a bit surprised that code is ever being invoked at run time since I don't think anything is currently using the hook mechanism. May 19 12:46:32 pb_: hehe, oh, okay, well.. i just grepped for internal symbols :) May 19 12:46:43 but maybe python does the signature checking earlier than I thought it did May 19 12:46:53 zecke: ah, heh May 19 12:47:22 pb_: actually I had an error with feeder and blamed package.bbclass for my own stupidity :) May 19 12:47:39 :-} May 19 12:54:25 okay, brb for benchmarking May 19 13:23:10 03Marcin Juszkiewicz  07org.openembedded.dev * r8379f149a2 10openembedded.git/recipes/netcat/netcat_0.7.1.bb: netcat: use update-alternatives as we have netcat in busybox too May 19 13:33:30 Any way to use packaged-staging for the whole build but to be able to disable it for a particular recipe ? (I rewrote some parts of one recipe and want to test it but it keeps unpacking the prev. stuff) May 19 13:50:17 rkirti|away: bump PR May 19 13:56:18 03Martin Dietze  07org.openembedded.dev * r9f026f95ef 10openembedded.git/recipes/linux/ (8 files in 3 dirs): linux-mtx 2.6.27: updates May 19 13:56:19 03Koen Kooi  07org.openembedded.dev * rce170fea65 10openembedded.git/recipes/u-boot/ (u-boot-git/leopardboard-support.patch u-boot_git.bb): u-boot git: add support for dm355-leopardboard May 19 13:56:29 03Martin Dietze  07org.openembedded.dev * r7ef692efa3 10openembedded.git/classes/ (nylon-image.bbclass nylon-mirrors.bbclass): nylon classes: update image type and mirror locations May 19 13:56:30 03Martin Dietze  07org.openembedded.dev * rceefd8ff95 10openembedded.git/recipes/busybox/ (4 files in 3 dirs): busybox: add more patches, update nylon defconfig May 19 14:04:49 03Rolf Leggewie  07org.openembedded.dev * r0965086647 10openembedded.git/ (conf/checksums.ini recipes/granule/granule_1.4.0.bb): granule: add 1.4.0 May 19 14:04:50 03Rolf Leggewie  07org.openembedded.dev * rf2ba78c87b 10openembedded.git/recipes/granule/ (granule.inc granule_1.2.4.bb): granule: move SRC_URI definition into .inc file May 19 14:04:51 03Rolf Leggewie  07org.openembedded.dev * rac5d9b4400 10openembedded.git/conf/distro/minimal.conf: conf/distro/minimal.conf: assign DISTRO_TYPE only weakly May 19 14:04:58 03Rolf Leggewie  07org.openembedded.dev * rfe80a43e57 10openembedded.git/recipes/granule/granule_1.2.4.bb: May 19 14:04:58 granule: drop 1.2.4 May 19 14:04:58 * do_configure does not find the new libassa it seems. May 19 14:04:58 1.4.0 works -> drop rather than spend time debugging May 19 14:13:17 hrw: Wow. :) worked. thanks May 19 14:22:38 03Koen Kooi  07org.openembedded.dev * rea19b9d74d 10openembedded.git/recipes/linux/ (linux-davinci/update-mach-types.patch linux-davinci_git.bb): linux-davinci git: fix dm355-leopard machtype since we can use a proper uboot now May 19 14:22:40 03Koen Kooi  07org.openembedded.dev * reb376e5b84 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 19 14:29:59 zecke: a silly question, are your patches for the trunk or the 1.8 branch? May 19 14:30:55 back in a few, gotta go buy some timber now May 19 14:31:35 pb_: 1.8 May 19 14:35:46 guys: ^dnl in autoconf files is comment - right? May 19 14:39:44 hrw: yeah, but you should not use it May 19 14:39:53 hrw: "dnl" is original m4 syntax May 19 14:40:34 hrw: m4 is so flexible that it allows redefining its comments syntax as well and this is what the autoconf people did May 19 14:42:05 hrw: or have you read this in autoconf's own files? (there it is allowed) May 19 14:49:29 I am trying to build tftp-hpa and it has broken configure.in May 19 14:52:34 hm May 19 14:52:38 as always May 19 14:52:44 with such older software May 19 14:53:25 tftp-hda 5.0 is 2009 but yes. it is old May 19 14:53:30 but I like that tftpd May 19 14:53:40 ;) May 19 14:54:51 jepp May 19 14:55:12 maybee they should run autoscan May 19 14:55:23 and write a new configure.ac May 19 15:06:20 zecke: okay, thanks May 19 15:08:29 woglinde: ho May 19 15:10:03 hi pb May 19 15:15:31 bye all May 19 15:21:17 hi woglinde May 19 15:42:06 * * OE Bug 4996 has been RESOLVED (FIXED) by comte_fabien(AT)yahoo.fr May 19 15:42:08 * * Incorrect Rootfs May 19 15:42:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4996 May 19 15:47:07 * * OE Bug 4575 has been RESOLVED (FIXED) by May 19 15:47:09 * * Incorrect SRC_URI in gnome_mplayer_0.5.3.bb May 19 15:47:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4575 May 19 15:47:28 how do i overwrite the name of the directory that a source archive is being extracted to? May 19 15:47:42 look at the S variable May 19 15:47:52 "rgrep S recipes" May 19 15:47:59 for examples May 19 15:48:04 "rgrep S recipes/" May 19 15:49:02 rgrep? May 19 15:49:27 same as grep -r I assume May 19 15:49:28 03Rolf Leggewie  07org.openembedded.dev * r02cc40c6ed 10openembedded.git/recipes/gnome-mplayer/ (3 files): May 19 15:49:28 gnome-mplayer: unify May 19 15:49:28 * add AUTHOR and SECTION (partly closes #4575) May 19 15:49:28 * fix HOMEPAGE May 19 15:49:28 * both recipes were unbuildable before this commit and are still unbuildable May 19 15:49:30 Unbreaking the recipes will be done in separate commits. May 19 15:49:32 03Rolf Leggewie  07org.openembedded.dev * r8722f3a634 10openembedded.git/recipes/gnome-mplayer/gnome-mplayer_cvs.bb: gnome-mplayer: point svn to googlecode.com. builds fine. May 19 15:49:37 03Rolf Leggewie  07org.openembedded.dev * raa29e81331 10openembedded.git/recipes/gnome-mplayer/ (3 files): May 19 15:49:40 gnome-mplayer: unbreak 0.5.3 May 19 15:49:42 * rearrange the SRC_URI situation and point to googlecode.com May 19 15:49:44 * the patches don't apply to the released versions, but only to SVN May 19 15:49:46 03Rolf Leggewie  07org.openembedded.dev * r57f3352b98 10openembedded.git/ (2 files in 2 dirs): gnome-mplayer: add 0.9.5. (Closes: #4575) May 19 15:49:51 i'll use kdevelop :) May 19 15:50:10 whatever gets the job done, I guess May 19 15:50:31 but i'm not sure whether that's what i need May 19 15:51:00 the thing is, the archive contains a - in my needs - wrong directory name May 19 15:51:22 i want it to be extracted to a different name rather than change the ${S} to what the archive spits out May 19 15:51:44 do_unpack_prepend() { mv blah new_blah } May 19 15:51:53 or would i have to mv the directory in do_fetch_append May 19 15:52:07 oh okay ^^ so pretty much that same idea May 19 15:52:08 aye May 19 15:52:12 will do it that way, thx May 19 15:58:11 eeeh? May 19 15:59:12 XorA|gone / Laibsch: http://pastebin.com/m60b65cc2 May 19 15:59:56 what's wrong? May 19 16:00:35 (other than the fact that what i am doing there to begin with is greatly ugly... but it's just a workaround until they release or until we switch to a newer bitbake) May 19 16:05:04 meep? May 19 16:07:17 morning May 19 16:08:10 hiho May 19 16:09:10 ooh May 19 16:09:16 g'day kergoth May 19 16:09:16 * kergoth looks through zecke's parser patches May 19 16:09:31 zecke: I get a KeyError at cache.py:112 May 19 16:09:35 ah, hm, he quit May 19 16:09:41 zecke: come back! May 19 16:10:52 03Rolf Leggewie  07org.openembedded.dev * r199f38cafe 10openembedded.git/ (conf/checksums.ini recipes/cellwriter/cellwriter_1.3.3.bb): cellwriter: update to 1.3.4 May 19 16:13:18 this reminds me, our anonymous python function handling sucks. appending the bodies? honestly. leads to a ton of problems. indentation, early return resulting in not evaluating the others, etc May 19 16:16:52 yeah, that's just awful May 19 16:17:19 kergoth / pb_: can you help me with something really cheesy please? http://pastebin.com/m60b65cc2 what does that fail? May 19 16:17:42 I dunno why it's done that way, even: they're stored separately, it's just that finalise() seems to glom them all together rather than executing them separately. May 19 16:17:43 weird May 19 16:18:06 pb_: yeah, its silly, it should just iterate over them and eval them one by one May 19 16:18:23 right May 19 16:18:32 fraxinas: it looks like you're trying to prepend shell onto a python function, that's doomed. May 19 16:18:56 (talking of stupid things in the way bitbake handles functions...) May 19 16:19:03 * kergoth chuckles May 19 16:19:33 humm? but i've always done it that way, and it doesn't have the _python in the name May 19 16:19:34 fraxinas: you'll need to create some kind of do_crazy_munging() function and arrange for it to be executed prior to unpack May 19 16:19:53 a task should probably not just blindly be a function. it should be some intermediate format or something, so it can act as a wrapper on any bits that get prepended/appended/defined May 19 16:19:54 * kergoth shrugs May 19 16:20:50 crazy o.o May 19 16:21:03 can't i just change the directory name the extract command is using? May 19 16:21:15 kergoth, pb_ We used to execute them one by one but zecke changed it to append for speed May 19 16:21:21 fraxinas: what exactly are you trying to achieve? May 19 16:21:39 fraxinas: if the source is just being unpacked into a directory with a different name to what oe is expecting, you probably just need to adjust the value of ${S} May 19 16:21:44 Better would be to wrap each in a generated funciton name, compile all at once and call each function May 19 16:21:53 RP: ah. May 19 16:21:56 I think that would keep the speed and remove the problems May 19 16:21:58 ~fishslap zecke May 19 16:22:00 * ibot slaps zecke up side the head with a wet fish. May 19 16:22:09 the thing is, the archive contains a - in my needs - wrong directory name May 19 16:22:09 <-> XorA is now known as XorA|gone May 19 16:22:09 i want it to be extracted to a different name rather than change the ${S} to what the archive spits out May 19 16:22:11 that's a measurable performance difference? you wouldn't think itd be enough to notice May 19 16:22:19 huh May 19 16:22:34 kergoth: It was significant May 19 16:22:40 yeah, strange, I didn't think the python compiler had that much startup overhead. May 19 16:22:51 well, if finalise wasn't called as often as it is, that might help matters :) May 19 16:23:05 considering its called, what, 25,000 times in a task-base? May 19 16:23:08 heh, true May 19 16:23:18 once per task + once per non-full recipe parse May 19 16:23:21 fraxinas: in that case it seems like you have another problem as well; you need to append, not prepend, to do_unpack. May 19 16:23:31 otherwise you'll be trying to rename something that doesn't exist yet May 19 16:23:45 Is there someone looking at zecke patches for bitbake? May 19 16:23:49 anyway, see my earlier comments about creating a separate task, I think that's probably the right way to fix this. May 19 16:23:54 otavio: everyone May 19 16:23:59 hehe May 19 16:24:05 http://moblin.org/community/blogs/imad/2009/moblin-v20-beta-netbooks-and-nettops-its-here May 19 16:24:06 hah May 19 16:24:17 aye !! that's probably my problem ^^ of course May 19 16:24:19 at a first glance i dont see anything terribly insane, pulling them down to test and look over more closely May 19 16:24:58 kergoth: Where is this problemtaic finalise call? May 19 16:25:29 RP: :-) May 19 16:25:41 RP: it's called when include=0 in handle(), every time May 19 16:26:01 it's not that problematic for current code, i had some i had recently written and made a silly assumption May 19 16:26:21 pb_: what is the plans for them? To include in trunk or stable? May 19 16:26:25 still syntax error -_- crappy May 19 16:26:38 otavio: they're against 1.8 at the moment, I think trunk has bigger issues May 19 16:26:56 okay i'll go with the "wrong" ${S} instead May 19 16:27:00 I don't know whether zecke plans to actually land them in the stable branch or not May 19 16:27:45 pb_: since by asking it but I'm not following it up May 19 16:27:47 kergoth: right. It seems to be called when its needed though :/ May 19 16:27:49 pb_: right May 19 16:28:22 RP: yep, unfortunately, it can be doing anything, including modifying the metadata we just parsed in. no way to get around it May 19 16:29:04 kergoth: its one of out features... May 19 16:29:36 :) May 19 16:29:45 otavio: I'm not quite sure what the plan is with the current bitbake trunk, I guess it depends on whether anybody has time to work on it. of course, there's no reason that we couldn't punt on the trunk for the time being and cut a new release branch off the current tip of 1.8, call it 1.9 or something. May 19 16:30:01 * kergoth chuckles at the removal of "obtain" from the parser, remembers hacking that in, was never anything but a hack May 19 16:30:16 Where did zecke post the patches? May 19 16:30:29 RP: OE ml May 19 16:30:32 pb_: that's a good point, perhaps trunk should just become a 2.0 branch, and make 1.8 trunk, since the latter has been getting more than bugfixes anyway :P May 19 16:30:39 RP: http://page.mi.fu-berlin.de/freyther/bitbake/parser/ May 19 16:30:40 RP: http://page.mi.fu-berlin.de/freyther/bitbake/parser/ May 19 16:30:58 kergoth: Hmm, no mail here yet, May 19 16:31:02 kergoth, otavio thanks May 19 16:31:06 cmon caffeine, help me out.. May 19 16:31:30 kergoth: is current trunk 'usable' ? May 19 16:31:31 RP: that's odd, it was four or five hours ago that holger sent the mail May 19 16:31:45 kergoth: I never felt safe to use it May 19 16:31:50 last time i tried to run trunk, a week or two ago, it didn't even run without errors on my machine. May 19 16:31:53 RP: http://thread.gmane.org/gmane.comp.handhelds.openembedded/23843 May 19 16:31:53 kergoth: I use stable branch instead May 19 16:32:12 kergoth: Removing obtain is a cause for celbration. The fetchers can probably be massively cleaned up too May 19 16:32:15 pb_: agreed May 19 16:32:27 bb.fetch needs to be revamped completely May 19 16:32:32 lots of things that bug me about it May 19 16:32:37 can't pass in a destination, have to use DL_DIR, .. May 19 16:32:42 * kergoth shakes head May 19 16:32:46 * kergoth doesn't know what he was thinking May 19 16:32:51 heh May 19 16:33:01 i had to do some fetching outside of do_fetch for work May 19 16:33:06 yeah, it's funny how many things turn out to suck when you look at them closely May 19 16:33:18 honestly, it's amazing this all works as well as it does, considering May 19 16:33:22 * RP has slowly been trying to help the fetchers... May 19 16:33:26 hack gone wild :) May 19 16:34:01 anyway, gotta go build a new hen-house now. chicks due to hatch tomorrow I think. May 19 16:34:03 later all. May 19 16:34:05 i was toying around with using urllib2 to fetch, but it hits some problems on Mac OS X machines due to Mac OS X not liking certain syscalls running after a fork but before an exec, and thats how our tasks are run May 19 16:34:09 later pb_ May 19 16:34:31 pb_: have fun May 19 16:34:40 kergoth: that sounds like you're accidentally using vfork() rather than real fork May 19 16:34:53 * pb_ -> May 19 16:37:03 not sure what os.fork uses under the hood, but I'd be surprised if it was vfork May 19 16:37:13 RP: Is it intentional that "bitbake -c rm_work" goes through all the steps again including configure (and compile, I assume)? May 19 16:37:24 okay works now May 19 16:38:17 Laibsch: no May 19 16:39:00 OK, not a really big problem May 19 16:39:08 But it struck me as odd May 19 16:40:28 hi, perhaps offtopic, but is anyone aware of the linksys dma2100. Is it hackable ? May 19 16:40:35 http://mail.python.org/pipermail/pythonmac-sig/2009-March/021105.html summarizes the issue i ran into with urllib on Mac OS X May 19 16:40:46 can it run openembedded ? (that makes it on-topic :-) ) May 19 16:40:52 "Additionally, per POSIX, only async-cancel-safe functions are safe to May 19 16:40:52 use on the child side of fork(), so even use of lower-level May 19 16:40:53 libSystem/BSD/UNIX APIs should be kept to a minimum, and ideally to May 19 16:40:53 only async-cancel-safe functions." May 19 16:41:05 * kergoth tries to find a copy of the posix info on async-cancel-safe, never messed with that stuff May 19 16:44:57 kergoth: hmm :/ May 19 16:45:26 guess we're just stuck using wget or curl :) just seems silly to not leverage functionality that python provides out of the box May 19 16:45:49 though, guess urllib2 could work on other operating systems, Mac OS X has a whole mess of OpenEmbedded issues :) May 19 16:46:07 * kergoth tries to wake up May 19 16:46:09 kergoth: indeed... May 19 16:46:27 * RP hides when OS X and OE are mentioned together May 19 16:56:43 kergoth: what about using urllib2 in all but macosx? May 19 16:56:56 otavio: would probably be a step in the right direction May 19 16:57:23 * kergoth thinks we need to change the api, or at least add a better one, though, at some point May 19 16:59:22 RP: OE X :-) May 19 17:00:36 * kergoth tries a build with zecke's patchset applied May 19 17:22:51 kergoth: that's a bit odd. POSIX does have some stuff about requiring async cancel but that's only really for the benefit of multi-threaded programs calling fork(). May 19 17:23:09 ah. wonder why Mac OS X is being such a bitch about it then :) May 19 17:23:13 * kergoth shrugs May 19 17:23:22 (in which case, yes, the behaviour is basically that fork() becomes like vfork(); you can't do anything legitimately except exec() if there are other threads involved) May 19 17:23:50 dunno, maybe your os x system is multithreaded under the covers, or maybe OS X itself just takes these things more seriously. May 19 17:24:02 bah, missed mickey again May 19 17:24:11 ah, i see May 19 17:44:12 03Angus Ainslie  07fso/milestone5.5 * rda236b7906 10openembedded.git/ (2 files in 2 dirs): paroli-elementary : extra python bindings for elementary May 19 17:44:12 03Angus Ainslie  07fso/milestone5.5 * r8684b21831 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image: use paroli-elementary bindings May 19 17:44:23 03Angus Ainslie  07fso/milestone5.5 * ra746adbe29 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli : use new python bindings May 19 18:27:48 hm.. do somebody tries to use qemu-10.0.3 to buld angstrom? May 19 18:28:22 ant__: ping? May 19 18:42:37 re May 19 18:42:42 * kergoth ponders May 19 18:42:46 hey woglinde May 19 18:43:21 * kergoth thinks we can't ditch the re-eval of the world when .conf changes without variable ref tracking, separate objects per var, and an association between ast statements and var objects.. ugh May 19 18:43:59 jo kergoth May 19 19:02:37 kergoth: yeah, that's probably right. on the other hand, zecke's ast stuff should allow the world to be re-evaluated without re-parsing fully, which would still be something of a win. May 19 19:03:12 yeah. I'd be curious to see what time is taking up by parsing vs evaluation May 19 19:03:16 and, actually, once you build an ast for the parse tree, keeping track of dependencies for each var isn't actually gong to be that much harder. May 19 19:04:02 kergoth: of course, the other half of zecke's stuff is to write a proper grammar and a "real" parser for .bb files rather than all this regexp badness May 19 19:04:06 aye, the ast methods wouldn't have a terribly difficult time of storing the info it already has for +=, =+, append, prepend, etc. then you'd just need to keep track of actual refs, foo=${bar}, and the expansion code could do that May 19 19:04:13 so, that ought to make parsing itself faster as well. double win! May 19 19:04:17 yeah, he has that C parser or whatever, i hope he'll pull that in too May 19 19:04:28 right May 19 19:04:39 Jay7: pong May 19 19:05:26 ant__: I'm trying to build kexec-tools-static 2.0.0 May 19 19:05:38 check the headers... May 19 19:05:42 have some time May 19 19:06:28 * pb___ heads off to cook dinner May 19 19:06:29 bbiab May 19 19:06:40 oh, I'm not sure if itd be useful to anyone, but i made a .inc for populating one collection from another. for each recipe that gets this task run, it copies all the files the recipe needs into a destination collection, including the filespath files, .incs, etc May 19 19:06:51 for work, but I'm sure they'd let me push it up May 19 19:07:02 Jay7: akmost surely you need to add -nostdinc May 19 19:07:12 to purgatory/Makefile May 19 19:08:01 hello. I got myself a beagleboard and i'm trying to setup the dev environment. I am following the getting started guide and i'm currently at the Start building -phase, only it won't build. I get an error: "Error, lockfile path does not exist!: OE/sources", when it's trying to build coreutils-native_7.2.bb. Any ideas? May 19 19:08:50 Deep_Blue: I've just restarted bitbake and this error has gone May 19 19:09:04 Jay7: bbl - 20-30 mins May 19 19:10:54 I have the latest released version, what do you mean? May 19 19:12:04 meaning the 1.8.12, not some dev version May 19 19:12:15 Deep_Blue: just try to run bitbake again May 19 19:13:59 same thing. just to clarify, i'm just doing the bitbake nano-thing May 19 19:15:18 has anyone ever seen ts_calibrate, ts_test and ts_print work fine, but not work with a Qt app? May 19 19:16:02 as far as I can tell I have all the right environment variables set, but I get "Couldnt load module input" when starting my Qt app May 19 19:26:06 NOTE: package tftp-hpa-5.0-r0: task do_build: Succeeded May 19 19:26:10 03Angus Ainslie  07fso/milestone5.5 * rce26e66985 10openembedded.git/recipes/netbase/netbase/ (om-gta01/interfaces om-gta02/interfaces): netbase : add metric for usb0 in interfaces file May 19 19:26:11 03Angus Ainslie  07fso/milestone5.5 * ra315d0c201 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image : add rootfs postprocessing for locale May 19 19:26:12 03Angus Ainslie  07fso/milestone5.5 * r99251bb40b 10openembedded.git/recipes/busybox/busybox-1.11.3/defconfig: busybox: add readehead to defconfig May 19 19:26:32 re May 19 19:29:43 hey hrw May 19 19:34:23 after few hours I finally have what I wanted from recipe May 19 19:35:36 hrw: check out zecke's parser stuff? :D May 19 19:35:46 did not checked May 19 19:36:09 my daughter does not allows me to concentrate May 19 19:36:30 hehe May 19 19:36:32 how old? May 19 19:37:00 2 years May 19 19:37:12 3 months :) May 19 19:37:24 she was born right around FOSDEM 2 years ago May 19 19:37:28 ah :) May 19 19:37:33 kergoth: 15 months May 19 19:37:39 hmm May 19 19:37:41 she has eye problem May 19 19:37:42 right May 19 19:37:56 hrw missed FOSDEM a year ago May 19 19:38:04 Crofton|work: and chichi's May 19 19:38:09 hrw serious May 19 19:38:19 hrw, right need to write that email May 19 19:38:26 is the ye problem serious? May 19 19:38:50 Jay7: Any other ideas? May 19 19:39:07 Deep_Blue: no, have no idea then May 19 19:39:12 Crofton|work: two medicines to apply directly to eye 4 times per day May 19 19:39:18 Crofton|work: it require 3 persons... May 19 19:39:19 urg May 19 19:39:21 ok. thanks May 19 19:39:23 jeeze May 19 19:39:39 I have some bitbake restarts and it will started build May 19 19:40:09 pplz, we have some problem when building from empty tmp and sources dirs May 19 19:40:46 not sure that it is angstrom-specific May 19 19:41:18 i tried searhing, but only thing i found was some log from here saying no idea. May 19 19:41:40 Deep_Blue: is it shasum-native.bb? May 19 19:42:04 no, coreutils-native_7.2.bb May 19 19:42:19 hm.. I have it on shasum-native May 19 19:42:29 well, something strange May 19 19:42:41 is OE/sources exists and writeable? May 19 19:43:09 yeap May 19 19:44:25 re May 19 19:45:06 bye May 19 19:48:07 03Marcin Juszkiewicz  07org.openembedded.dev * r1e0d96b7d4 10openembedded.git/recipes/netcat/netcat_0.7.1.bb: netcat: use update-alternatives class (thx Koen) May 19 19:48:12 03Marcin Juszkiewicz  07org.openembedded.dev * r9fb58d79a6 10openembedded.git/recipes/tftp-hpa/ (files/default files/init tftp-hpa_5.0.bb): tftp-hpa: added 5.0 version of HPA tftp client/daemon May 19 19:48:58 is there anybody had tried unix-network-programming books' sources on oe? May 19 19:49:24 unp? May 19 19:51:41 can someone explain the state of xserver-xorg/xserver-kdrive? May 19 19:51:58 is kdrive still used, is it just a xorg build with --enable-kdrive? May 19 19:56:58 kergoth: kdrive is slowly being phased out May 19 19:57:12 kergoth: but xorg is still a lot heavier May 19 19:57:16 ah May 19 19:57:56 * RP has a soft spot for kdrive May 19 19:58:09 xserver-kdrive in OpenEmbedded is using the xorg-xserver sources from upstream.. so its the same source tree, just a different actual x server coming out of it, right? May 19 19:58:19 kergoth: right May 19 19:58:37 okay. so the xserver-xorg recipe builds kdrive plus a bunch of others, but xserver-kdrive is just the kdrive bits? May 19 19:58:40 makes sense May 19 19:58:42 thanks May 19 19:58:57 kergoth: xserver-xorg probably doesn't build kdrive May 19 19:59:21 xserver-xorg-common.inc has --enable-kdrive May 19 19:59:25 ehh... seems kexec-tools-static should be partially rewritten to build against klibc.. May 19 19:59:32 and my xserver-xorg build just failed in kdrive/vesa/vm86.c May 19 20:00:07 * kergoth shrugs May 19 20:00:23 kergoth: The versions in poky don't ;-) May 19 20:00:48 oddly, it doesn't seem to package the thing.. weird May 19 20:00:55 okay, maybe i need to swipe poky's X then :) May 19 20:01:07 RP, do you have a macro for that May 19 20:02:03 Crofton|work: Poky's kdrive recipes are separate from the bigX ones... May 19 20:02:47 it does seem pretty weird for the xorg recipes to be doing --enable-kdrive. I wonder what that's about. May 19 20:02:50 I mean for the phrase "The versions in poky don't ;-): May 19 20:03:03 Crofton|work: ah :) May 19 20:03:22 Crofton|work: I thought I was managing not to say that a lot ;-) May 19 20:03:24 I'm trying ti figure out how spi really works May 19 20:03:28 * kergoth chuckles May 19 20:03:46 * kergoth really needs to sort through what he has yet to push upstream to OpenEmbedded May 19 20:03:48 heh, spi as in the organisation, or spi as in the bus? May 19 20:03:54 I'm assuming the spi_board_info struct tells the spi driver to config itself? May 19 20:04:00 both of them are fairly inscrutable I suspect May 19 20:04:06 spi the bus May 19 20:04:16 ah, that's probably the easier of the two May 19 20:04:21 RP: what's xserver-xf86-lite? May 19 20:04:26 and the modalias says what drivers can use the board driver? May 19 20:04:54 kergoth: No DRI or GLX May 19 20:05:13 Jay7: NFS? May 19 20:05:25 ah May 19 20:05:28 * RP should trhow away the dri2 recipe looking at the list May 19 20:06:27 Crofton|work: yeah, the board_info is the hardware specific configuration bits, pins to use or addresses or whatever. May 19 20:06:54 Laibsch: no, local fs May 19 20:07:06 the modalias is used so higher level drivers can claim interfaces/ May 19 20:07:12 ? May 19 20:07:27 kergoth: have you seen my email with versions issues? any ideas? May 19 20:07:34 Laibsch: just try to move tmp and sources, create empty tmp and sources and start bitbake something May 19 20:07:39 * RP does get rid of the dri2 version May 19 20:07:46 I'm not exactly sure what modalias is for. judging from the name it's some hotplug thing but I don't quite know what happens to it. May 19 20:07:54 heh May 19 20:08:12 I think higher level drivers use it to find spi buses connected to specifc hw May 19 20:08:16 denix0: I've never seen anything like that. i don't see how version prefs would affect its preferences wrt *PR* May 19 20:08:20 ah, could be May 19 20:08:26 which is a nuisance on the beagle since people will connect different stuff May 19 20:08:27 denix0: maybe ask RP? May 19 20:08:59 kergoth: ok May 19 20:09:04 RP: ping :) May 19 20:09:07 :) May 19 20:09:13 denix0: hi May 19 20:09:31 apparently otavio is the guilty party for --enable-kdrive in the xorg recipe May 19 20:09:39 denix0: Hmm, this in on the mailing list? May 19 20:09:46 RP: ah, it's so unusual to see you araound... :) May 19 20:10:01 RP: yep May 19 20:10:59 RP: http://thread.gmane.org/gmane.comp.handhelds.openembedded/23680/focus=23816 May 19 20:13:29 denix0: It sounds like a bitbake bug that it ignores the PR when PREFERRED_VERSION is set May 19 20:13:43 (and there are two recipes with the same PV) May 19 20:14:07 RP: is it known or something new? May 19 20:14:11 denix0: All I can suggest is deving into the providers.py code May 19 20:14:16 denix0: I was unware of it... May 19 20:14:20 unaware May 19 20:14:45 RP: Ok, thanks May 19 20:16:03 RP, http://twitter.com/abraxas3d May 19 20:17:09 Crofton|work: heh :) May 19 20:17:12 It is a beta May 19 20:18:34 hi rp May 19 20:21:03 hi woglinde May 19 20:23:40 rp *g* seems ubtuntu did a little update to the poulsbo stuff May 19 20:26:02 woglinde: Hopefully there should be some moblin stuff around soon too May 19 20:27:51 rp :) May 19 20:28:31 is there some way to add more than 1 ROOTFS_POSTPROCESS_COMMAND May 19 20:28:48 any that get appended with += don't seem to get called May 19 20:29:03 it's a string. May 19 20:29:05 a single string May 19 20:29:13 so remember to end your lines of shell with ";" May 19 20:29:14 nytowl: should be. make sure you use "; " inbetween May 19 20:29:18 it's not a list May 19 20:29:19 likewise: :) May 19 20:29:22 :-) May 19 20:29:34 likewise, thx thats the insight I was looking for May 19 20:29:50 nytowl: thank kergoth, he was more verbose May 19 20:30:01 * kergoth chuckles May 19 20:30:15 I was just about to thank kergoth for the reason behind the insight :) May 19 20:30:22 cool :-) May 19 20:30:43 You're talking with both the .us and .eu support teams I guess. May 19 20:32:02 hehe May 19 20:32:13 got both timezones awake righ now May 19 20:32:46 yeah this is the most productive part of my day (after work hours) :-) May 19 20:33:03 especially if I bring neat hardware to the home May 19 20:37:20 hey guys i got gcc-cross package with bitbake now i see some folder but not executable a gcc compiler binary do i need some extra set up or installation? May 19 20:38:33 are there extra parameters for gcc installation ? it looks like a standard gcc package May 19 20:43:33 orges what is your goal? May 19 20:44:32 i want to install arm-angstrom-linux-gnueabi-gcc to eo May 19 20:44:36 to oe May 19 20:45:13 i got the packages but havent installed properly yet May 19 20:46:17 ???? May 19 20:46:44 you want a compiler? May 19 20:46:49 or pakages? May 19 20:46:53 or sdk? May 19 20:47:00 i want a compiler May 19 20:47:11 i have binutils-cross-2.18-r1 gcc-cross-initial-4.1.2-r10 May 19 20:47:11 cross-linkage-1.0-r0 glibc-intermediate-2.5-r7 May 19 20:47:11 gcc-cross-4.1.2-r10 linux-libc-headers-2.6.20-r7 May 19 20:47:11 May 19 20:47:21 bitbake gcc-cross yes May 19 20:47:27 yeah i did it May 19 20:47:36 then just make is enough? May 19 20:47:46 then it will apper under oetmp/cross May 19 20:47:54 is there anyone that can fix my patchwork access ? May 19 20:48:23 wow thank you May 19 20:48:27 nytowl crofton May 19 20:48:32 :) thanks woglinde May 19 20:48:39 thx woglinde May 19 20:48:41 orges all other stuff ist under oetmp/staging May 19 20:48:51 ok i got it i'm so newbie May 19 20:49:04 sorry for msg mass May 19 20:49:23 Crofton, Crofton|work can you fix my patchwork access ? May 19 20:49:36 ok hang on ' May 19 20:49:38 there is also a cross toolchain sdk package, right? meta-sdk- something. May 19 20:49:46 sure May 19 20:50:43 03Angus Ainslie  07fso/milestone5.5 * rc764254f5c 10openembedded.git/recipes/images/fso-image.inc: fso-image.inc : allow other packages to append ROOTFS_POSTPROCESS rules May 19 20:50:53 03Angus Ainslie  07fso/milestone5.5 * r64edc5e659 10openembedded.git/recipes/images/fso-paroli-image.bb: fos-paroli-image : allow other packages to append ROOTFS_POSTPROCESS rules May 19 20:51:04 nytowl, you should be able to change patch states May 19 20:51:17 noone can comment via patchwork May 19 20:51:27 Crofton|work,, I can't login May 19 20:51:46 hmm May 19 20:51:55 you need your password reset May 19 20:52:01 never got a confirmation email May 19 20:52:17 that might help May 19 20:53:07 I do not think it is a very compex registration sysrtem May 19 20:53:15 the user management stuff is not great :) May 19 20:53:40 yeah I could find any way to resend the registration email or reset a password May 19 20:53:51 s/could/couldn't/ May 19 20:54:09 03Fraxinas  07org.openembedded.dreambox * rc5d698c9b7 10openembedded.git/packages/enigma2/enigma2.bb: enigma2: add gst-plugin-apetag (otherwise some monkeyish mp3s don't preroll) and move icydemux into common RDEPENDS too May 19 20:54:09 03Fraxinas  07org.openembedded.dreambox * r910439c7a0 10openembedded.git/: Merge branch 'org.openembedded.dreambox' of git://git.openembedded.net/openembedded into org.openembedded.dreambox May 19 20:54:10 03Fraxinas  07org.openembedded.dreambox * r63d1c4212c 10openembedded.git/packages/gstreamer/ (3 files in 2 dirs): May 19 20:54:11 gstreamer: add gstreamer (core) 0.10.23 recipe, add gst-plugins-base 0.10.23 recipe including an ugly patch which brings it to current git head May 19 20:54:14 (fixes various issues like dvbmediasink playback with multiple audio streams, CD audio playback) May 19 20:55:41 I mmight have to delete you and then you can re-add yourself May 19 20:55:47 lets try that route May 19 20:56:02 no May 19 20:56:06 lets not do that May 19 21:07:40 is mickey the only person who manages git ssh keys? May 19 21:10:01 I suspect more people can May 19 21:10:30 we are moving git server Wednesday, so we should have a bigger list then :) May 19 21:12:41 Crofton|work: ok May 19 21:13:03 do you have a specifc question? May 19 21:14:27 Crofton|work: http://thread.gmane.org/gmane.comp.handhelds.openembedded/23520/focus=23857 May 19 21:15:12 I'll try and remember to ask him in the am May 19 21:15:15 cbrake, ping May 19 21:15:42 although I think we are going to move the server tomorrow May 19 21:15:42 Crofton|work: howdy May 19 21:15:54 we moving git tomorrow May 19 21:15:57 ? May 19 21:16:15 Crofton|work: what was the final agreement on org/net? May 19 21:16:18 denix0: I can also manage git keys May 19 21:16:20 we should warn people it will be flaky while dns updates May 19 21:16:35 well, the official urls are .org May 19 21:16:44 Crofton|work: yes, I'll send out an email later tonight May 19 21:16:52 need to talk to mickey|sports about the .net addresses May 19 21:17:01 what time? May 19 21:17:02 Crofton|work: what time suits you to do the switch? May 19 21:17:05 :-) May 19 21:17:12 whenever May 19 21:17:18 not around my lunch time May 19 21:17:25 later would be better May 19 21:17:30 things slow in the afternoon May 19 21:17:31 ok, how about 3PM EDT? May 19 21:17:33 cbrake: should Theodore re-send you his key then? May 19 21:17:34 ok May 19 21:17:59 denix0: sure, if he already has access, I can change keys, etc May 19 21:18:42 denix0, I think we need another ack from an active dev May 19 21:18:43 cbrake: he was granted the access and sent his key to mickey, but haven't heard back yet... May 19 21:19:30 Crofton|work: I can ack - he's patches are sane and he did good job on docs. cbrake can vote for him too :) May 19 21:19:44 ok :) May 19 21:19:46 he's = his May 19 21:20:27 denix0: sure, just send key to cbrake@bec-systems.com or cliff.brake@gmail.com May 19 21:21:29 cbrake: thanks May 19 21:21:44 denix0: I'll process later today -- need to head out for a few hours May 19 21:21:56 cbrake: no problem May 19 21:23:36 Crofton|work: how is the eV member stuff coming along? Have not heard much May 19 21:23:46 heh May 19 21:23:46 Crofton|work: I hear rumors that there is a maillist going May 19 21:23:52 I'll collect a list May 19 21:24:05 then get someone else to jion me in proposing them for membership May 19 21:24:12 then the current members vote May 19 21:24:20 I put you on the list alread May 19 21:24:28 Crofton|work: sounds good -- may as well batch process them for efficiency May 19 21:25:08 yep May 19 21:28:52 anyone got the url for the linux sound chaos diagram May 19 21:29:38 hmmm May 19 21:32:47 argh May 19 21:32:50 * kergoth grumbles May 19 21:33:34 wait.. hmm May 19 21:33:43 * kergoth .. yes, he's talking to himself May 19 21:33:50 kergoth goes in circles May 19 21:33:57 :) May 19 21:34:04 good nite May 19 21:34:09 gn woglinde May 19 21:34:17 trying to figure out how you'd add to zecke's stuff to avoid the full re-eval when a .conf changes May 19 21:34:20 heh May 19 21:34:23 lots of pieces May 19 21:38:54 the annoying parts are the immediate vs lazy things May 19 21:43:31 03Andrea Adami  07org.openembedded.dev * r5d7b852d1b 10openembedded.git/recipes/kexec/files/kexec2-klibc.patch: kexec-tools-static_2.0.0: add --nostdinc to purgatory Makefile makefile May 19 22:03:18 kergoth: if you could arrange for your AST to be some kind of SSA representation then I think the immediate vs lazy stuff would pretty much fall out in the wash, it'd just become a question of using different vars as the assignment source. May 19 22:05:09 (or, of course, have an ssa intermediate generated from the ast parse tree, if that's easier) May 19 22:05:59 not familiar with ssa representation. i was just mulling over the idea of it storing a "variable" as a tuple of the Statements from the ast that feed into it, in the parse order. then when something gets a := or += or whatever, it becomes a new tuple whose statements are those of the other var at that point in time, or something. May 19 22:06:28 but I'm just throwing ideas around, i dunno May 19 22:06:37 * kergoth needs more caffeine, also May 19 22:07:25 kergoth: see http://en.wikipedia.org/wiki/Static_single_assignment_form for example May 19 22:07:34 ah, thanks May 19 22:07:53 ahhh, right May 19 22:08:16 my prototype implementation of a bb.data that tracked var refs basically did that. itd keep around refs to old versions of vars May 19 22:09:17 * kergoth will have to read some more of these links on this wikipedia entry May 19 22:10:30 _append/_prepend are basically just refs to the var's own previous version May 19 22:10:51 right, exactly May 19 22:10:53 foo(2) = "${foo(1)} bar" May 19 22:11:25 and the same goes for foo := "${foo} bar" May 19 22:11:57 (which, obviously, generalises to assignments where the lhs and rhs are different variables) May 19 22:16:27 i wonder if += and =+ being different from _append and _prepend could be avoided with a smarter var eval/expansion happening. I mean, i wonder if there are any bits in the metadata that actually rely on +=/=+/.=/=. being immediate May 19 22:16:30 guess we'll find out, eventually May 19 22:20:01 03Rolf Leggewie  07org.openembedded.dev * re6a8ba0d16 10openembedded.git/ (conf/checksums.ini recipes/kanatest/kanatest_0.4.8.bb): kanatest: add 0.4.8 May 19 22:20:11 03Rolf Leggewie  07org.openembedded.dev * re373e7e4f0 10openembedded.git/ (3 files in 2 dirs): kanatest: fight some bitrot (SRC_URI, HOMEPAGE, etc.) May 19 22:20:33 i guess our ssa-like thing would use something analogous to Φ function for normal var refs, since those we can't resolve until we're done parsing everything May 19 22:20:38 * kergoth ponders May 19 22:31:40 * pb___ zzz May 19 22:31:41 night all May 19 22:31:49 'nite May 19 22:33:17 gn May 19 22:33:29 good morning May 19 22:34:45 this is probably a simple question, but how would i go about splitting a single long data type into two different char bytes? May 19 22:34:51 in c May 19 22:37:13 this is pretty off-topic for here May 19 22:37:33 also assuming a long is 4 bytes, that would be 4 chars May 19 22:40:58 well yeah thats obvious May 19 22:41:18 nm May 19 22:41:40 wrong channel tab anyways May 19 22:41:43 heh May 19 22:43:42 03Koen Kooi  07org.openembedded.dev * rd5de998081 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom 2009.X: switch to udev 141 and hal 0.5.12 per RFC May 19 22:43:43 03Koen Kooi  07org.openembedded.dev * rdda33cd8b2 10openembedded.git/conf/machine/dm355-leopard.conf: dm355-leopard: use upstream UBOOT_MACHINE May 19 22:43:43 03Koen Kooi  07org.openembedded.dev * r68ce5c8144 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 19 22:43:44 03Koen Kooi  07org.openembedded.dev * rf08698737b 10openembedded.git/conf/checksums.ini: checksums: add more checksums May 19 22:43:47 03Matthieu Poullet  07org.openembedded.dev * r1f4ac66042 10openembedded.git/recipes/dsplink/ti-paths.inc: May 19 22:43:50 dsplink: change path to the XDC tools directory May 19 22:43:52 This way the naming convention is more coherent: May 19 22:43:54 TIBIOSDIR -> BIOS_INSTALL_DIR May 19 22:43:56 TIXDCTOOLSDIR -> XDC_INSTALL_DIR May 19 22:43:58 Signed-off-by: Matthieu Poullet May 19 22:44:00 Signed-off-by: Koen Kooi May 19 23:08:06 * * OE Bug 5062 has been RESOLVED (WONTFIX) by May 19 23:08:08 * * fso-console-image rootfs for a780 is not usable May 19 23:08:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5062 May 19 23:23:06 * * OE Bug 3833 has been RESOLVED (FIXED) by May 19 23:23:08 * * getting OE ready for opkg and throw out ipkg May 19 23:23:10 * * http://bugs.openembedded.net/show_bug.cgi?id=3833 May 19 23:31:23 03Paul Eggleton  07org.openembedded.dev * r00113e8b95 10openembedded.git/ (7 files in 3 dirs): zaurusd: update to latest svn (as of 20090501) May 19 23:49:35 * Laibsch remind kergoth about bug 518 May 19 23:49:39 !oebug 518 May 19 23:49:40 * * Bug 518, Status: ASSIGNED, Created: 2005-12-10 05:39 May 19 23:49:42 * * mardy(AT)users.sourceforge.net: \[PATCH\] tslib: work with different screen resolution May 19 23:49:43 * * http://bugs.openembedded.net/show_bug.cgi?id=518 May 19 23:49:54 ah, right, thanks, needed the reminder :) May 19 23:54:44 Can you commit it right away? May 20 00:04:07 * * OE Bug 5104 has been created by  May 20 00:04:09 * * creation of dependency-complete feed May 20 00:04:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5104 May 20 00:13:06 * * OE Bug 1200 has been RESOLVED (INVALID) by May 20 00:13:09 * * RFC: hciattach patch to turn BT radio on May 20 00:13:10 * * http://bugs.openembedded.net/show_bug.cgi?id=1200 May 20 00:14:59 kergoth: Can you commit bug 518 it right away? May 20 00:23:17 03Angus Ainslie  07fso/milestone5.5 * r424d0f96c5 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image : fix variable assignment May 20 00:23:19 03Angus Ainslie  07fso/milestone5.5 * r11eb31d33c 10openembedded.git/recipes/openmoko-projects/paroli-elementary_git.bb: paroli-elementary : set SRCPV May 20 00:24:06 * * OE Bug 1892 has been RESOLVED (FIXED) by May 20 00:24:08 * * Bitbake decides to not package stuff May 20 00:24:10 * * http://bugs.openembedded.net/show_bug.cgi?id=1892 May 20 00:51:50 ping cbrake about May 20 00:51:59 !oebug 2858 May 20 00:52:00 * * Bug 2858, Status: NEW, Created: 2007-08-24 07:17 May 20 00:52:01 * * cliff.brake(AT)gmail.com: mono: ARM_FPU_NONE is hardcoded in configure.in May 20 00:52:03 * * http://bugs.openembedded.net/show_bug.cgi?id=2858 May 20 00:52:16 !oebug 2859 May 20 00:52:17 * * Bug 2859, Status: NEW, Created: 2007-08-24 07:19 May 20 00:52:18 * * cliff.brake(AT)gmail.com: mono: is --without-tls the correct TLS option May 20 00:52:19 * * http://bugs.openembedded.net/show_bug.cgi?id=2859 May 20 00:52:42 !oebug 2863 May 20 00:52:44 * * Bug 2863, Status: NEW, Created: 2007-08-24 07:32 May 20 00:52:45 * * cliff.brake(AT)gmail.com: mono: test on other architectures May 20 00:52:46 * * http://bugs.openembedded.net/show_bug.cgi?id=2863 May 20 00:53:45 !oebug 2857 May 20 00:53:48 * * Bug 2857, Status: NEW, Created: 2007-08-24 07:15 May 20 00:53:49 * * cliff.brake(AT)gmail.com: \[META\] mono issues May 20 00:53:50 * * http://bugs.openembedded.net/show_bug.cgi?id=2857 May 20 01:08:07 * * OE Bug 5104 has been marked as DUPLICATE of bug 2970 by May 20 01:08:09 * * creation of dependency-complete feed May 20 01:08:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5104 May 20 01:08:57 Chi-Chi's? heh May 20 01:09:04 Living close to mexico FTW! May 20 01:09:15 hepatitis, eh? May 20 01:14:51 note, they are still open in .eu May 20 01:15:02 we were in the one in Brussel's May 20 01:16:40 yeah May 20 01:16:51 Is this correct? - FILESPATHPKG := "${@bb.data.getVar('FILESPATHPKG', d, 1).replace(':files:', ':linux-davinci:files:', 1)}" May 20 01:23:16 ah, adding in between files and the more specific entries? thats probably the best way to do it, yeah May 20 01:23:24 unless you want to just override the thing entirely May 20 01:41:05 kergoth: thanks May 20 01:42:13 kergoth: I thought about overwriting it entirely too... not sure which is better though May 20 01:43:07 * * OE Bug 5014 has been RESOLVED (FIXED) by May 20 01:43:09 * * pidgin uses inexisting preferred version. May 20 01:43:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5014 May 20 02:05:06 * * OE Bug 5008 has been RESOLVED (INVALID) by May 20 02:05:08 * * checksums doesn't contain valid sums for addressbook-0.1: do_fetch failed May 20 02:05:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5008 May 20 02:22:28 Laibsch: hey, thanks for #4986! :) **** ENDING LOGGING AT Wed May 20 02:59:57 2009