**** BEGIN LOGGING AT Tue Mar 30 02:59:57 2010 Mar 30 03:01:16 Crofton_|work: could be a stdc++ include? Mar 30 03:13:59 zecke, use to work, last week Mar 30 03:14:03 I am poking around Mar 30 03:14:09 bed tmie though Mar 30 03:15:14 sleep well Mar 30 05:25:54 The `enna_hg.bb` recipe I posted to the list needs `libvalhalla_hg.bb` but `libvalhalla_1.0.1.bb` is chosen. How do I specify this dependency? `PREFERRED_VERSION_libvalhalla = "hg"` in the recipe? Mar 30 05:26:36 Enna 0.4.0 for example depends on libvalhalla 1.0.1. Mar 30 05:27:08 PaulePanter: "hg" is unlikely the version... Mar 30 05:27:35 zecke: Ok, PV = "0.4.0+hg" then? Mar 30 05:28:11 But that will change if a new release happens. Mar 30 05:28:16 PaulePanter: this wouldn't follow the naming/version convention either. Mar 30 05:28:52 zecke: Could you give me a pointer to the naming convention, please. Mar 30 05:29:51 PaulePanter: http://wiki.openembedded.net/index.php/Versioning_Policy, and it is outdaed for SRCREV :( Mar 30 05:30:58 zecke: Sorry, `PV = "1.0.1+hg" it should be. (I pasted the version for Enna and not libvalhalla.) Mar 30 05:31:18 PaulePanter: but as you use a fixed SRCREV the +hg is probably fine, so yes PREFERRED_VERSION_libvalhalla = "1.0.0+hg" should work Mar 30 05:33:04 zecke: How would you have done it? If it is not fixed append `r${SRCREV}`? Mar 30 05:33:35 zecke: `PREFERRED_VERSION_libvalhalla = "hg"` seems to work though. ;-) Mar 30 05:34:38 If a Mercurial/hg repository is used in the `SRC_REV` BitBake is always failing for me the first time and then works afterwards. Is that a known bug of BitBake? Mar 30 05:35:15 I am using BitBake 1.8.19. Mar 30 05:41:18 PaulePanter: no idea, I have never used the hg fetcher Mar 30 05:41:22 zecke: Sorry, I was wrong. `PREFERRED_VERSION_libvalhalla = "hg"` does *not* work. Mar 30 05:41:36 zecke: I will send a message to the list. Mar 30 05:41:50 PaulePanter: did you try libvalhalla = "1.0.0+hg"? Mar 30 05:44:40 zecke: Not yet. I had to wait for another task to finish. I am trying now. Mar 30 05:45:40 PaulePanter: also with bitbake -e on the libvahalla_hg.bb you should see the content of PV, sticking that into PREFERRED_VERSION should work Mar 30 05:46:26 zecke: Thanks, I will try it in the next run. Mar 30 05:55:58 It looks like I cannot use `PREFERRED_VERSION_libvalhalla = "1.0.0+hg" in a recipe. I will use it in `local.conf`. But that does not work generally. So can I specify it in a recipe? Mar 30 05:56:17 PaulePanter: no you can not. Mar 30 05:57:04 zecke: That is bad. :( Mar 30 05:57:04 PaulePanter: for your hg update problem, a log file would be extremely helpful, e.g. with bitbake -DDD -vvv Mar 30 05:57:33 zecke: I will only be able to provide it in some hours. Sorry. Mar 30 05:58:06 zecke: Can you reproduce this? Mar 30 05:58:08 PaulePanter: well, what you want and we don't have right now is DEPENDS = "foo (>= 1.0.0+hg)". We only ever got as far as parsing this information, but not to evaluate it Mar 30 05:58:21 PaulePanter: not right now Mar 30 05:59:14 zecke: Thanks! Mar 30 06:03:47 I will report back later. Thanks for your help so far. Mar 30 07:02:39 03Martin Jansa  07org.openembedded.dev * r760b513491 10openembedded.git/recipes/openmoko-3rdparty/emtooth_svn.bb: Mar 30 07:02:39 emtooth: bump SRCREV, add new deps Mar 30 07:02:39 Signed-off-by: Martin Jansa Mar 30 07:02:50 03Martin Jansa  07org.openembedded.dev * rc7736ca03a 10openembedded.git/recipes/efl1/ecore_svn.bb: Mar 30 07:02:50 ecore: enable XIM for dead keys support from illume keyboards Mar 30 07:02:50 Signed-off-by: Martin Jansa Mar 30 07:09:19 good morning Mar 30 07:13:04 good morning Mar 30 07:17:37 03Thomas Zimmermann  07org.openembedded.dev * r7271551808 10openembedded.git/recipes/bluez/ (files/obexd-add-fso-support.patch obexd_0.22.bb): Mar 30 07:17:37 obexd: add 0.22 Mar 30 07:17:38 * Add experimental FSO PBAP for SHR only Mar 30 07:17:38 Signed-off-by: Thomas Zimmermann Mar 30 07:39:55 gm Mar 30 08:07:55 ping eFfeM Mar 30 08:10:02 MWelchUK_work: pong Mar 30 08:10:08 & gm Mar 30 08:11:03 morning all Mar 30 08:11:12 yo RP Mar 30 08:11:16 Did you manageto get m4 1.4.14 to build? Mar 30 08:11:55 MWelchUK_work: not sure any more, i seem to recall someone else took a peek too Mar 30 08:12:30 Ah! Not on org.openembedded.dev Mar 30 08:13:10 MWelchUK_work: yes: http://cgit.openembedded.org/cgit.cgi/openembedded/log/recipes/m4/m4_1.4.14.bb Mar 30 08:13:16 chris did Mar 30 08:14:07 i recall having tried to get rid of the native recipe, but w/o too much success Mar 30 08:14:41 eFfeM, I looks like I'm using an older version of automake... Mar 30 08:14:57 ah ok Mar 30 08:15:29 let me give it a quick try Mar 30 08:15:48 while waiting for some real work to complete Mar 30 08:16:46 will take a short while Mar 30 08:17:18 I thought I might get away with using m4 1.4.12, but oddly now autoconf is moaning it needs m4 version 1.4 or later?! Mar 30 08:18:39 autoconf moved to a new version too Mar 30 08:19:21 The native packages appear to work fine. Mar 30 08:20:20 i'll let you know how i proceed, cache is out of date, now at 67%, system is also quite busy with other things Mar 30 08:49:44 MWelchUK_work: m4 1.4.12 needs autoconf 2.65 and that has default preference -1 Mar 30 08:50:17 actually it needs autoconf >= 2.64 but we have no recipe for 2.64 Mar 30 08:51:24 Isn't it the other way around - m4 1.4.12 seems to have compiled, then it tries to build autconf. Mar 30 08:51:49 for me it does not compile, configure tails Mar 30 08:51:50 fails Mar 30 08:52:14 configure.ac:20: error: Autoconf version 2.62 or higher is required Mar 30 08:52:22 actually this is ofc for 1.4.14 not .12 Mar 30 08:52:31 good morning florian, all Mar 30 08:52:42 Yes - 1.4.14 fails for me too Mar 30 08:53:08 It needs a newer version of automake as far as I can see. Mar 30 08:53:23 probably best thing is to try to use .14 but enable the autoconf 2.63 recipe locally Mar 30 08:53:29 maybe XorA|gone has more info Mar 30 08:54:27 * MWelchUK_work thinks he's going to have to get his head around the whole automake/m4/autoconf thing. Mar 30 08:54:37 It's really not a natural fit! Mar 30 08:55:15 good morning Mar 30 08:55:20 gm Mar 30 08:56:49 eFfeM: I have to catch XorA|gone too... I had to revert to autoconf-2.63 in order to build kexec-tools. It was the only one failing Mar 30 08:57:46 btw, see his tree: http://www.xora.org.uk/cgi-bin/cgit.cgi/openembedded/log/?h=xora/autoconf-2.65 Mar 30 08:59:54 it seems some recipes could need some m4 hacking Mar 30 09:07:20 eFfeM, Think I'm going to try automake 1.10.3, m4 1.4.12 and autoconf 2.63 and see if I get anywhere with that. Mar 30 09:08:57 * MWelchUK_work assumes that automake, m4 and autoconf are quite fundamental and so probably needs to do a clean build. Mar 30 09:09:06 morning Mar 30 09:09:11 morning Mar 30 09:13:05 hm.. could anyon pls check whether xextproto does fetch? My build was broken... Mar 30 09:13:30 I did dare to empty my src dir :/ Mar 30 09:55:31 I want to just try if the `SRC_URI` with a Mercurial/hg repository works. So I have to clean my `${OE_TREE}/downloads` folder of the already downloaded files. When I then run `$ bitbake -c fetch -b /srv/filme/oe/openembedded/recipes/libvalhalla/libvalhalla_hg.bb` it does not try to clone the repository though. Could you give me the right option for `-c` please. Mar 30 09:56:46 PaulePanter: well, I assume you have a "stamp" for do fetch Mar 30 09:56:53 PaulePanter: attempt to put -f in your command line Mar 30 09:58:38 zecke: Thanks, but adding `-f` did not help. It just says `NOTE: Running task 2 of 2 (ID: 0, /oe/openembedded/recipes/libvalhalla/libvalhalla_hg.bb, do_fetch)` but nothing happens. Mar 30 10:02:02 kergoth: you any idea on the m4 problem above ? Mar 30 10:03:09 PaulePanter: no idea then, just try -c clean and retry?, also remove the tarball and the tarball.md5 from the source dir? Mar 30 10:03:48 zecke: Yes, I did this now. I just wanted to be clever and save the rebuilding stuff. ;-) Thanks. Mar 30 10:03:50 eFfeM, kergoth, I get what seems to be the same problem building autoconf 2.65 and 2.63 Mar 30 10:04:53 PaulePanter: i think the clean will also not have the effect you want... IIRC the do_fetch looks for .md5 files and then figures out that everything is fine and it does not need to do anything. Mar 30 10:05:33 eFfeM, kergoth: http://pastebin.com/1QTmRW33 Mar 30 10:06:05 no idea here Mar 30 10:06:21 eFfeM, kergoth, at least autoconf 2.61 builds :-) Mar 30 10:10:20 Which has some patches to it, not applied for 2.63 and 2.65 Mar 30 10:10:40 patches... Mar 30 10:19:30 zecke: Ok, finally it worked. After `-c clean` I also had to run the normal `bitbake -b …` with `-f` added. Mar 30 10:24:25 MWelchUK_work: I could build autoconf-2.63 after agit pull ~12 hours ago Mar 30 10:24:42 Angstrom Distro Mar 30 10:25:14 ant_work, isn't angstom defaulting to 2.65 Mar 30 10:25:19 yes :/ Mar 30 10:25:57 ant_work, Hmm, sure I pulled this morning, tried 2.63 and it didn't work for me. Mar 30 10:26:40 I've also stuck in a preferred verison for m4 (1.4.12) so that might have affected it. Mar 30 10:26:43 note that I had the 2.65 already built and decided to downgrade seeing kexec-tools failing Mar 30 10:27:01 I had two autoconf (2.63 and 2.65) in mt configure logs :/ Mar 30 10:27:03 brrr Mar 30 10:27:39 I'll check tonight..but as I said my build of last night failed because fetch error Mar 30 10:28:28 I'll fix this and rebuild from scratch, then Mar 30 10:29:09 ant_work, I think I'm going to have to do a build from scratch as well. Might try and get something to work and do that over night! Mar 30 10:29:27 he :) I launch my build overnight Mar 30 10:29:51 lesson #1: never empty SRCDIR while doing unsurveiled builds ... Mar 30 10:30:24 ant_work, I have a box with a number of builds set off by a cron job every night - only problem is I screwed up the script a bit recently :-s Mar 30 10:30:57 ant_work, moving the directory probably would have been a better idea... Mar 30 10:31:16 yes, but this was a 'debug' build :) Mar 30 10:31:43 btw do we have something like 'eclean distfiles' to prune srcdir? Mar 30 11:06:52 03Koen Kooi  07org.openembedded.dev * r39e783decf 10openembedded.git/classes/scons.bbclass: scons bbclass: convert to new style staging Mar 30 11:06:53 03Koen Kooi  07org.openembedded.dev * r01d75b1a85 10openembedded.git/classes/scons.bbclass: scons bbclass: add SCONS_FIX_ENV option that allows you to fix the toolchain from env Mar 30 11:06:54 03Koen Kooi  07org.openembedded.dev * r584b124b6b 10openembedded.git/recipes/python/ (2 files in 2 dirs): Mar 30 11:06:54 python-scons: update to 1.3.0 Mar 30 11:06:54 * stage sconscript file that gets the toolchain options from the environment Mar 30 11:15:04 03Koen Kooi  07org.openembedded.dev * r076a2ad86e 10openembedded.git/recipes/opencv/artoolkitplus_2.2.0.bb: artoolkitplus: add 2.2.0 Mar 30 11:21:49 Does anyone remember who nslu2-linux.adm@bkbits.net is and how to contact him. Mar 30 11:22:10 PaulePanter: rwhitby ?? Mar 30 11:22:27 PaulePanter: that would be me probably Mar 30 11:22:57 rwhitby: Great! I have a question regarding `autotools.bbclass`. Mar 30 11:23:32 rwhitby: Why did you put `EXTRA_AUTORECONF = "--exclude=autopoint"` in it? Mar 30 11:23:54 PaulePanter: note that particular email address means that it was imported from a bitkeeper database over 5 years ago by someone related to the nslu2-linux project which had over 100 developers Mar 30 11:24:11 rwhitby: I tried a rebuild with this line disabled and it worked for me. Mar 30 11:24:34 PaulePanter: I personally have no knowledge of any changes to autotools.bbclass Mar 30 11:24:59 PaulePanter: where does that email address occur? Mar 30 11:25:08 rwhitby: probably in git log Mar 30 11:25:25 rwhitby: merge from old bitkeeper time probably Mar 30 11:25:30 rwhitby: Commit 0f235b0f42575bfb50dd891cf44aa08c2e404a67. Mar 30 11:26:12 03Martin Jansa  07org.openembedded.dev * r248e00f306 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 30 11:26:12 EFL: bump SRCREV Mar 30 11:26:12 Signed-off-by: Martin Jansa Mar 30 11:26:39 PaulePanter: ok, that email address means that the original authorship of that change has been lost, and a default group email has been used instead. Mar 30 11:27:13 rwhitby, funny who things come back to haunt you after years :0 Mar 30 11:27:16 rwhitby: Thank you for the clarification. Mar 30 11:27:16 er :) Mar 30 11:27:35 more coffee Mar 30 11:27:40 I hope that no one will ask me about ko/pi and kdepim/pi ;D Mar 30 11:27:51 PaulePanter: no worries, mate. Mar 30 11:28:09 03Martin Jansa  07org.openembedded.dev * r78c29173da 10openembedded.git/conf/distro/include/sane-srcrevs.inc: EFL: bump SRCREV even more for last few efreet fixes Mar 30 11:31:13 XorA: hi,may I ask you where did you get the patches for autoconf-2.65 from? Mar 30 11:31:43 ant_work: what patches? Mar 30 11:31:56 those in your (merged) tre Mar 30 11:32:03 *tree Mar 30 11:32:53 unfortunately Gentoo is still on 2.63 so I could'n steal anything yet... wrt kexec-tools Mar 30 11:34:16 ant_work: do you mean patches applied to autoconf or other patches? Mar 30 11:34:33 m4 patches for recipes failing with autoconf-2.65 Mar 30 11:34:55 ant_work: google for xxxxx autoconf 2.64 Mar 30 11:35:21 hm..any big change between 2.64 and 2.65? Mar 30 11:36:08 ant_work: no, thats why you search for 2.64, thats when the breakages happened Mar 30 11:36:21 great, thx Mar 30 11:36:33 found some debian links already.. Mar 30 11:36:36 * XorA discovered that by luck Mar 30 11:36:56 he.. The Mar 30 11:36:57 fix is simply to add a ";" before fi Mar 30 11:37:17 ant_work: that sounds wrong Mar 30 11:37:24 http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg189733.html Mar 30 11:38:23 ant_work: ah that could be right in that particular case Mar 30 11:38:45 ant_work: there are also some changes to expansion order, which caused fun Mar 30 11:43:32 MWelchUK_work: just moved to the latest autoconf and automake (by commenting out the default pref lines) and then m4 1.4.14 builds Mar 30 11:43:49 bah..I was seeking for the irclogs but both server are behaving badly.. Mar 30 11:43:58 hentges one is 'kaputt' Mar 30 11:43:59 * eFfeM thinks that either we should mvoe to the latest auto* or have the latest m4 with default pref -1 Mar 30 11:44:23 eFfeM: we are on latest auto* Mar 30 11:44:58 Somehow was overlooked by Patchwork. Could some please commit this. Mar 30 11:45:51 XorA: we're not, angstrom is, but oe in general is not: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/autoconf/autoconf_2.65.bb Mar 30 11:46:01 DEFAULT_PREFERENCE = "-1" Mar 30 11:46:33 patchwork seems to miss patches regularly Mar 30 11:47:07 XorA: so if you want to build for minimal things break Mar 30 11:47:33 eFfeM: well moan at minimal distro guys :-D Mar 30 11:47:34 * eFfeM learned to avoid to touch autoconf again, so he's not going to remove that default pref .... Mar 30 11:47:48 i think the recipe should have the default pref removed Mar 30 11:48:08 do it then :-D Mar 30 11:48:08 * eFfeM thinks we have too many things with DEFAULT_PREFERENCE = "-1" Mar 30 11:48:15 eFfeM: well...root/conf/distro/include/angstrom-2008-preferred-versions.inc wins Mar 30 11:48:23 ant_work: i know Mar 30 11:48:36 butthere is more...one could have some PREFERRED_.. Mar 30 11:48:38 eFfeM: in truth, I never meant to commit it with that Mar 30 11:48:45 eFfeM: that was an accident Mar 30 11:48:48 3 levels are a bit confusing Mar 30 11:49:07 XorA: i'm still hiding below the pile of dirt pushed upon me the previous time I touched autohelll Mar 30 11:49:09 eFfeM: Im in france with no access so cant fix it, please do with my blessing Mar 30 11:49:29 XorA: autoconf and automake Mar 30 11:49:31 ? Mar 30 11:49:39 eFfeM: automake isnt my recipe Mar 30 11:49:51 eFfeM: but I can Ack the fix for autoconf Mar 30 11:50:38 03Koen Kooi  07org.openembedded.dev * r1c4a1dcef5 10openembedded.git/recipes/u-boot/ (8 files in 2 dirs): uboot git: update beagleboard Mar 30 11:51:19 automake has been added by dirk opfer Mar 30 11:51:29 eFfeM: angstrom isnt on ltest automake Mar 30 11:51:59 is it on latest m4 ? taht one gave me a msg saying it needed a later automake Mar 30 11:52:49 erm, I had thought it was, but I might have fucked up Mar 30 11:53:09 * XorA doesnt have a build tree here Mar 30 11:54:20 eFfeM, Ah, Ok. Mar 30 11:54:27 cheers. Mar 30 11:54:32 eFfeM: my plan is to take a weekend to test/bump angstrom to latest Mar 30 11:54:52 So I guess it's th old version of automake that's causing all the problems? Mar 30 11:56:44 I had only one package failing because of autoconf-2.65, and I was using automake-1.10.3 Mar 30 11:56:50 ping hrw Mar 30 11:57:20 pong MWelchUK_work Mar 30 11:57:24 :-) Mar 30 11:57:35 ant_work: try to clean m4 then build it Mar 30 11:57:44 Can I completely remove e2fsprogs from task-proper-tools.bb? Mar 30 11:58:01 prefer to not do that Mar 30 11:58:25 eFfeM: one rebuild from scratch can't be escaped today... Mar 30 11:58:30 03Frans Meulenbroeks  07org.openembedded.dev * r8b6dbef9a6 10openembedded.git/recipes/autoconf/autoconf_2.65.bb: Mar 30 11:58:30 autoconf: removed DEFAULT_PREFERENCE = -1 Mar 30 11:58:30 as discussed on #oe Mar 30 11:58:30 Signed-off-by: Frans Meulenbroeks Mar 30 11:58:30 Acked-by: Graeme Gregory Mar 30 11:58:31 03Frans Meulenbroeks  07org.openembedded.dev * r48f59b9a05 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Mar 30 11:58:34 03Frans Meulenbroeks  07org.openembedded.dev * r0682e2a57d 10openembedded.git/recipes/tgt/tgt_1.0.2.bb: Mar 30 11:58:34 tgt: moved to 1.0.3 Mar 30 11:58:34 Signed-off-by: Frans Meulenbroeks Mar 30 11:58:35 there you are, apologies for the merge Mar 30 11:58:39 hrw, Ok, so I just need e2fsprogs, none of the sub packages? Mar 30 11:58:46 but rebase didn't do it Mar 30 11:58:55 eFfeM: "autoconf 2.65: removed DEFAULT_PREFERENCE = -1" for future please Mar 30 11:59:23 oh, right Mar 30 11:59:36 hrw: ok is indeed better Mar 30 11:59:37 MWelchUK_work: iirc we depend on them in other places Mar 30 11:59:53 hrw, Ok. Mar 30 12:00:07 MWelchUK_work: I am enabling reset now in u-l-ng Mar 30 12:00:32 I think that we need to recheck what goes to basic rootfs and into extended ones... Mar 30 12:00:47 some things in u-l-ng are listed as deprecated Mar 30 12:01:14 hrw, should have named it somewhere, actually didn't because by heart I adhere to this: Mar 30 12:01:14 http://wiki.openembedded.org/index.php/Commit_log_example Mar 30 12:01:23 The first words of a commit should be recipe name, normally without the version number. Mar 30 12:01:44 but could have mentioned 2.65 after the : Mar 30 12:01:45 eFfeM: I aggree with commit policy, but your commit touched ONE version Mar 30 12:01:50 true Mar 30 12:02:05 eFfeM: it is not that you removed DEFAULT_PREFERENCE = -1 for autoconf Mar 30 12:02:10 you did it for 2.65 only Mar 30 12:02:26 ideally would have been: autoconf: removed DEFAULT_PREFERENCE = -1 for 2.65 Mar 30 12:02:40 sounds nice Mar 30 12:02:55 fully agree with your remark, will take care next time Mar 30 12:04:56 still dubious about touching kernel recipes... Mar 30 12:05:08 in that case I'd keep the ver Mar 30 12:08:03 hrw, I really need to move this to busybox-alt: http://patchwork.openembedded.org/patch/1794/ Mar 30 12:08:51 ok, do that then Mar 30 12:09:10 The file is already there for busybox... Mar 30 12:09:43 03Marcin Juszkiewicz  07org.openembedded.dev * rfd43073321 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Mar 30 12:09:43 util-linux-ng: swapoff is symlink to swapon Mar 30 12:09:43 Signed-off-by: Marcin Juszkiewicz Mar 30 12:09:44 03Marcin Juszkiewicz  07org.openembedded.dev * r02f7331e4f 10openembedded.git/recipes/alsa/ (alsa-state.bb alsa-state/bug20/asound.state): Mar 30 12:09:44 alsa-state: BUG 2.0 support Mar 30 12:09:44 Signed-off-by: Marcin Juszkiewicz Mar 30 12:09:54 03Marcin Juszkiewicz  07org.openembedded.dev * rb185cddd04 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Mar 30 12:09:54 util-linux-ng: enable reset command Mar 30 12:09:55 Signed-off-by: Marcin Juszkiewicz Mar 30 12:11:09 03Martyn Welch  07org.openembedded.dev * r7d7f2596ec 10openembedded.git/recipes/ifupdown/ (ifupdown-ubuntu-0.6.8/init ifupdown-ubuntu_0.6.8.bb): Mar 30 12:11:10 Add ubuntu verison of ifupdown Mar 30 12:11:10 We need some of the features in the ubuntu version of ifupdown, rather than Mar 30 12:11:10 the version found in Debian. Mar 30 12:11:10 Signed-off-by: Marcin Juszkiewicz Mar 30 12:11:38 ops, last one had to be edited in commit first Mar 30 12:11:42 nevermind Mar 30 12:12:16 MWelchUK_work: I will merge few of your components into dev and push - ok/ Mar 30 12:12:17 ? Mar 30 12:12:40 hrw, sure. Mar 30 12:12:45 np Mar 30 12:16:53 hi, all! Mar 30 12:17:43 MWelchUK_work: In commit 7d7f2596ec0aea7684d2c05fa852f093b622b530 would have `PR = "r0"` been better? Mar 30 12:18:18 I want to add a package at image build time. A package RCONFLICTS with some of default packages (busybox-syslog). Is it possible? Mar 30 12:20:58 PaulePanter, is that one of the commits hrw just made? Mar 30 12:21:03 03Martyn Welch  07org.openembedded.dev * rba9d4c2181 10openembedded.git/recipes/start-stop-daemon/ (files/start-stop-daemon.c start-stop-daemon_1.9.18.bb): Mar 30 12:21:03 start-stop-daemon: added standalone C version Mar 30 12:21:03 This is not needed if you are building with busybox, however it is Mar 30 12:21:03 required if attempting a busybox-less build and do not want to have DPKG Mar 30 12:21:03 installed. Mar 30 12:21:04 Signed-off-by: Marcin Juszkiewicz Mar 30 12:21:05 03Martyn Welch  07org.openembedded.dev * r3352b508e2 10openembedded.git/recipes/traceroute/traceroute_2.0.12.bb: Mar 30 12:21:05 traceroute: added 2.0.12 version Mar 30 12:21:06 Signed-off-by: Marcin Juszkiewicz Mar 30 12:21:06 03Martyn Welch  07org.openembedded.dev * rc5014e1b9f 10openembedded.git/recipes/realpath/ (files/makefile.patch realpath_1.10.bb): (log message trimmed) Mar 30 12:21:07 realpath: added 1.10 Mar 30 12:21:07 The package contains a small utility realpath, which converts each Mar 30 12:21:08 pathname argument to an absolute pathname, which has no components Mar 30 12:21:08 that are symbolic links or the special . or .. directory entries. Mar 30 12:21:09 This utility provides mostly the same functionality as `/bin/readlink -f' Mar 30 12:21:09 in the coreutils package. Mar 30 12:21:35 PaulePanter: probably would be better but it cannot be reversed now Mar 30 12:21:54 PaulePanter: sometimes I forgot to clean such small things before initial push Mar 30 12:22:05 PaulePanter: especially when I use recipe for longer time Mar 30 12:22:28 MWelchUK_work: commits rewritten this time Mar 30 12:23:36 MWelchUK_work: task-proper-tools is what I want to push as next Mar 30 12:23:57 Ok, I'm just working on a cleaned up version... Mar 30 12:24:32 hrw: Probably one downside if there are no review rounds. Mar 30 12:24:51 hrw, Just want to see which patches I can remove from my queue after the above activity! Mar 30 12:25:08 PaulePanter: Martyn sent that version quite long time - no one looked nearly Mar 30 12:25:12 hrw, PaulePanter, I did push them to the ML as RFC! Mar 30 12:25:33 Though I hadn't expected hrw to be so eager Mar 30 12:26:23 MWelchUK_work: your work made my work easier as we both work to get same result - rootfs without busybox Mar 30 12:28:53 MWelchUK_work: I am sorry. I missed those. Mar 30 12:30:30 03Koen Kooi  07org.openembedded.dev * rdca5bfe78f 10openembedded.git/conf/machine/include/tune-cortexa8.inc: angstrom: start adding infrastructure to support 'hardfp' on new arm cores Mar 30 12:35:47 hrw, I haven't had a chance to build it yet, but something like this: http://pastebin.com/kevNYP4L Mar 30 12:37:34 MWelchUK_work: hwclock.sh is for util-linux-ng - rigth? Mar 30 12:38:02 MWelchUK_work: maybe add it into u-l-ng as u-l-ng-hwclock which will be in RDEPENDS of busybox-alt? Mar 30 12:39:35 hrw, No, hwclock.sh is a part of busybox. It got dumped on u-l-ng during some early dev work. Mar 30 12:39:41 ok Mar 30 12:39:52 Actually it's in recipes/busybox/files/ Mar 30 12:40:22 Hence why it really should be a part of busybox-alt... Mar 30 12:40:43 ok Mar 30 12:44:26 MWelchUK_work: I will look more into ifupdown-ubuntu Mar 30 12:45:11 hrw, I had a look to see if my understanding of the situation was correct, however the differences were so cryptic to me that I gave up fast :-) Mar 30 14:22:26 hrw, Hmm, seems to be trying to pull busybox-mountall into task-base. Tried cleaning task-base, didn't work, so I'm going to do a complete rebuild :-s Mar 30 14:23:39 hrw, If you want to push the task-proper-tools.bb part, feel free. Mar 30 14:23:49 ok Mar 30 14:29:12 03Koen Kooi  07org.openembedded.dev * r24d8719345 10openembedded.git/recipes/libcroco/ (libcroco_0.6.1.bb libcroco_0.6.2.bb): libcroco: add 0.6.2 and convert to new style staging Mar 30 14:52:23 03Martin Jansa  07org.openembedded.dev * rcd0282a8d8 10openembedded.git/recipes/xorg-xserver/ (6 files in 2 dirs): Mar 30 14:52:23 xserver-xorg: bump SRCREV Mar 30 14:52:23 Signed-off-by: Martin Jansa Mar 30 14:52:33 03Martin Jansa  07org.openembedded.dev * r4000c3d0d6 10openembedded.git/recipes/mesa/ (mesa-dri-glsl-native.bb mesa-dri-glsl-native_7.8.bb): Mar 30 14:52:33 mesa-dri-glsl-native: move to 7.8 release Mar 30 14:52:33 Signed-off-by: Martin Jansa Mar 30 14:52:34 03Martin Jansa  07org.openembedded.dev * rbc81e417ed 10openembedded.git/ (2 files in 2 dirs): Mar 30 14:52:34 illume-keyboards-shr: install directly to illume/keyboards (do not use subdir for each keyboard) Mar 30 14:52:34 * Newer illume isn't looking for keyboards in subdirectories of Mar 30 14:52:35 /usr/lib/enlightenment/modules/illume/keyboards/ Mar 30 14:52:35 Signed-off-by: Martin Jansa Mar 30 14:52:36 03Martin Jansa  07org.openembedded.dev * r0b47d18bd9 10openembedded.git/recipes/mesa/ (mesa-dri-7.8/fix-progs-makefile.patch mesa-dri_7.8.bb): Mar 30 14:52:36 mesa-dri: add version 7.8 Mar 30 14:52:37 Signed-off-by: Martin Jansa Mar 30 15:05:55 * MWelchUK_work slaps himself. Mar 30 15:06:58 In new versions of uboot, the shortcut "set" (for "setenv") no longer works and explains why his NFS root wasn't working... Mar 30 15:30:29 ha Mar 30 15:30:36 That's almost as fun as when 'mmcinit' became 'mmc init' Mar 30 15:30:54 03Koen Kooi  07org.openembedded.dev * rcdff13c73d 10openembedded.git/recipes/gcc/ (gcc-configure-cross.inc gcc-package-cross.inc): Mar 30 15:30:55 gcc-cross: fix gfortran -> g77 linking logic Mar 30 15:30:55 Acked-by: Tom Rini Mar 30 15:30:55 Signed-off-by: Koen Kooi Mar 30 15:32:17 It's amazing how easy it is to miss the error as well (as it whizzes out of the top of the serial console buffer) Mar 30 15:38:41 03Koen Kooi  07org.openembedded.dev * rbc13fe86a5 10openembedded.git/recipes/m4/ (m4.inc m4_1.4.14.bb): m4 1.4.14: work around automake 1.11 req Mar 30 15:43:47 Tartarus, that caused me grief until my fingers learned the new way Mar 30 15:47:38 03Steve Sakoman  07org.openembedded.dev * r7509e6b7cb 10openembedded.git/recipes/debianutils/debianutils_2.30.bb: debianutils: remove duplicate installation of tempfile.1 in preparation for automake 1.11.1 Mar 30 15:47:39 03Steve Sakoman  07org.openembedded.dev * rc90bdc8faf 10openembedded.git/recipes/gnome/gnome-bluetooth_git.bb: gnome-bluetooth: remove trailing / in lib/plugins/Makefile.am to eliminate install error Mar 30 15:47:40 03Steve Sakoman  07org.openembedded.dev * rab62901b36 10openembedded.git/recipes/telepathy/ (2 files in 2 dirs): libtelepathy: remove duplicate header installation in preparation for automake 1.11.1 Mar 30 15:47:41 03Steve Sakoman  07org.openembedded.dev * r4ce7c3c06b 10openembedded.git/recipes/ntp/ntp_4.2.4p7.bb: ntp: remove duplicate installation of sntp.1 in preparation for automake 1.11.1 Mar 30 15:47:42 03Steve Sakoman  07org.openembedded.dev * re8052e4cb7 10openembedded.git/recipes/libnet/libnet_1.1.2.1.bb: libnet: convert to new staging Mar 30 15:47:42 03Steve Sakoman  07org.openembedded.dev * r35cfb1383e 10openembedded.git/recipes/sylpheed/ (claws-mail_3.6.1.bb files/duplicate-header.patch): claws-mail: remove duplicate header installation in preparation for automake 1.11.1 Mar 30 16:14:09 automake 1.11! Mar 30 16:46:21 mickeyl: ? Mar 30 17:07:58 am 1.11 would simplify all Vala programs Mar 30 17:08:06 as it has native Vala support Mar 30 17:08:14 so I'm looking forward to it Mar 30 17:08:25 I know that it has Mar 30 17:08:43 XorA told before that he has a plans to migrate angstrom to it soon Mar 30 17:08:49 cooo Mar 30 17:08:50 l Mar 30 17:09:40 how can i regenerate package-index automatically after each call to bitbake? Mar 30 17:09:43 i remember we had a solution for that Mar 30 17:09:48 but not how Mar 30 17:09:52 bitbake package-index? Mar 30 17:09:58 well, yes Mar 30 17:10:01 but automatically Mar 30 17:10:17 first heard Mar 30 17:10:28 hmm, k, perhaps i imagined that Mar 30 17:11:20 how things go mickeyl? Mar 30 17:12:35 can't complain, FSO progressing nicely with the first actual contract in sight Mar 30 17:12:44 other than that, mainly iphone/ipad development here Mar 30 17:12:45 nice Mar 30 17:13:00 how's ania and the little one? Mar 30 17:13:08 we are fine Mar 30 17:13:21 Mira catched some kind of flue Mar 30 17:13:26 but doing fine Mar 30 17:13:39 is she old enough to search easter eggs in the garden? :) Mar 30 17:14:28 we do not have that tradition but she is at proper age - can autonomically move in agarden Mar 30 17:16:40 how is Sabine? Mar 30 17:23:10 a bit nervous atm. Mar 30 17:23:17 she quit her job Mar 30 17:23:22 and will start being freelancer next month Mar 30 17:23:33 so now we have two freelancers in the family Mar 30 17:23:39 which means finances are a bit more unstable Mar 30 17:23:48 o yes Mar 30 17:24:07 doable anyway Mar 30 17:24:20 but i'm looking forward that she has quite some contracts, as she's known by some important CROs Mar 30 17:24:25 (clinical research organization) Mar 30 17:24:55 ;) Mar 30 17:25:15 ok, time to check will few checksums.ini work properly at same time Mar 30 17:27:32 good Mar 30 17:28:06 I still use stable/2009 Mar 30 17:40:28 I've got a recipe that includes some local files - I change the content of the local files and bump the PR then bitbake the recipe - it rebuilds according to the new PR, but it packages the old version of the local files - some sort of caching issue? Mar 30 17:43:53 nvr mind - I see the package didn't get installed - sorry for the noise Mar 30 17:55:42 03Roman I Khimov  07org.openembedded.dev * r1f71e0d0b6 10openembedded.git/recipes/clamav/clamav_0.94.2.bb: Mar 30 17:55:42 clamav-0.94.2: remove deprecated options from config file Mar 30 17:55:42 Signed-off-by: Roman I Khimov Mar 30 17:55:45 03Roman I Khimov  07org.openembedded.dev * rc5ffbab676 10openembedded.git/recipes/clamav/ (3 files in 2 dirs): Mar 30 17:55:45 clamav: add version 0.95.3 Mar 30 17:55:45 Signed-off-by: Roman I Khimov Mar 30 17:55:46 03Roman I Khimov  07org.openembedded.dev * r654351c29d 10openembedded.git/recipes/clamav/ (clamav.inc files/clamav-daemon.init): Mar 30 17:55:46 clamav: wait on stop in init Mar 30 17:55:46 Takes some time for clamav to shut down and it's better to return from Mar 30 17:55:47 init script only when it actually is stopped. Mar 30 17:55:47 Signed-off-by: Roman I Khimov Mar 30 17:55:49 03Roman I Khimov  07org.openembedded.dev * re5f884a71e 10openembedded.git/recipes/clamav/ (5 files): Mar 30 17:55:50 clamav: switch to INC_PR Mar 30 17:55:50 Signed-off-by: Roman I Khimov Mar 30 18:10:30 have a nice rest of day Mar 30 18:19:14 03Roman I Khimov  07org.openembedded.dev * r1ff531e946 10openembedded.git/recipes/poptop/poptop_1.3.4.bb: Mar 30 18:19:15 poptop: disable logwtmp in config Mar 30 18:19:15 Poptop tries to use that and we have it removed since it's broken, no good. Mar 30 18:19:15 Signed-off-by: Roman I Khimov Mar 30 18:19:18 03Roman I Khimov  07org.openembedded.dev * r1ca92813d6 10openembedded.git/recipes/poptop/poptop_1.3.4.bb: Mar 30 18:19:18 poptop: change "require-mppe-128" option to plain "mppe" Mar 30 18:19:18 OE has ppp-2.4.3-mppe-mppc-1.1.patch for pppd and it disables Mar 30 18:19:18 'require-mppe-128' option, so poptop complains: Mar 30 18:19:19 In file /etc/ppp/options.pptpd: unrecognized option 'require-mppe-128' Mar 30 18:19:19 on start. Fix that by using 'mppe' option. Mar 30 18:19:20 Signed-off-by: Roman I Khimov Mar 30 18:19:20 03Roman I Khimov  07org.openembedded.dev * r46ce809681 10openembedded.git/recipes/poptop/poptop_1.3.4.bb: Mar 30 18:19:21 poptop: don't expose open port by default, listen on 127.0.0.1 Mar 30 18:19:21 Signed-off-by: Roman I Khimov Mar 30 18:21:54 ok, this is really getting far from "normal" Mar 30 18:22:13 the tmp build dir is taking more than 100gb for angstrom-x-image Mar 30 18:22:59 does setting BBDEBUG to yes have something to do with that? Mar 30 18:28:16 anyone building angstrom from scratch with latest HEAD? Mar 30 18:28:19 hmm Mar 30 18:28:46 Did you set other variables? Mar 30 18:28:58 Like DEBUG_BUILD or INHIBIT_PACKAGE_STRIP ? Mar 30 18:29:04 Tartarus: nope Mar 30 18:29:23 those are commented as in local.conf.sample Mar 30 18:29:30 Yeah, but so is BBDEBUG :) Mar 30 18:29:33 k Mar 30 18:30:06 i set BBDEBUG because the .sample file told me i would get some more output Mar 30 18:30:23 Can you pastebin your local.conf ? Mar 30 18:30:26 ~pastebin Mar 30 18:30:28 [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. Mar 30 18:30:28 ok Mar 30 18:30:40 ibot: thanks Mar 30 18:30:40 pas de quoi, etrunko Mar 30 18:30:44 lol Mar 30 18:30:51 kind bot Mar 30 18:31:09 * Tartarus finds it funny that the explanation is 5 lines long here Mar 30 18:33:03 Tartarus: here is my environment http://pastebin.com/jT2krNVc Mar 30 18:34:39 looks sane Mar 30 18:36:56 and local.conf http://pastebin.com/052BNetJ Mar 30 18:37:03 there is KEEPROOTFS set Mar 30 18:37:12 could be? Mar 30 18:37:45 Not that large, no Mar 30 18:37:55 How long have you had this tmpdir? Mar 30 18:38:11 And start du'ing the subdirs, see what's taking up the most space Mar 30 18:38:25 Tartarus: samba by faqr Mar 30 18:38:28 13GB Mar 30 18:38:34 OK, that sounds like a bug :) Mar 30 18:38:52 Just one 'samba' build dir is 13gb? Mar 30 18:38:56 Look and see what's so big in there Mar 30 18:39:01 something in temp/ I hope Mar 30 18:39:01 samba binaries taking > 100MB Mar 30 18:39:49 Not immediately horrible, we strip debug info out in packaging... Mar 30 18:41:01 etrunko, if build space is an issue use rm_work Mar 30 18:41:28 Tartarus: i noticed those binaries are replicated into source, package and packages-split Mar 30 18:42:37 Crofton: is it a recipe/task/class? Mar 30 18:42:52 class I think Mar 30 18:43:02 without checking INHERIT += "rm_work" Mar 30 18:43:07 in local.conf Mar 30 18:43:11 ok Mar 30 18:43:33 as noted redeuces disk space at the expense of information to figure out why builds are not quite right Mar 30 18:44:20 Crofton_|work: true, but he's saying 100GB for angstrom-x-image, that seems oddly high Mar 30 18:44:46 I think angstrom has the debug flag that makes stuff really big Mar 30 18:44:50 until stripped Mar 30 18:45:03 ah Mar 30 18:45:05 I do not build that image Mar 30 18:45:11 :S Mar 30 18:45:20 Yeah, I forgot they do -ggdb3 Mar 30 18:45:25 oh debug Mar 30 18:45:33 so makes some sense Mar 30 18:45:37 And is why angstrom doesn't use the normal libc inc files Mar 30 18:46:15 Tartarus, Crofton: is there any other (smaller) image that ships e17? Mar 30 18:47:01 not sure Mar 30 18:47:24 ok, will take a look then Mar 30 18:47:27 thanks for the tips Mar 30 18:47:45 I'm checking my tmp dir size Mar 30 18:47:55 use rm_work, I bet it helps Mar 30 18:48:13 already in my local.conf Mar 30 18:53:36 morning Mar 30 18:53:49 morn kergoth_ Mar 30 19:32:08 03Roman I Khimov  07org.openembedded.dev * rf95a95435c 10openembedded.git/recipes/openssl/openssl.inc: (log message trimmed) Mar 30 19:32:08 openssl: deal with unpackaged /usr/lib/ssl files Mar 30 19:32:08 Config file is accessed directly from libcrypto, so belongs to Mar 30 19:32:08 libcrypto package. Mar 30 19:32:08 openssl-misc is a new package that contains CA management scripts. Mar 30 19:32:08 Signed-off-by: Roman I Khimov Mar 30 19:32:09 Acked-by: Holger Hans Peter Freyther Mar 30 19:42:30 http://blogs.arm.com/software-enablement/locks-swps-and-two-smoking-barriers/?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+BeagleBoard+%28BeagleBoard.org%29 Mar 30 20:14:37 Crofton_|work: rm_work did the job, already free almost 60 GB Mar 30 21:12:30 bitbake question: for SRC_URI="file://local_dir_symlink" I get a dir with the name of the link target, not "local_dir_symlink" when the temp directory structure is created. Where is the copy done for a file:// URI? Mar 30 21:13:12 hoj: the same place all the rest of the unpacking happens. do_unpack task in base.bbclass Mar 30 21:13:50 I suspect its doing if os.path.isdir, which uses stat, not lstat. should probably make it check for a link specifically Mar 30 21:16:53 I'm using 1.8.13 bitbake and don't see a do_unpack.. Mar 30 21:19:51 ? Mar 30 21:19:56 do_unpack is in OE, not bitbake. Mar 30 21:20:47 it may be using the copyfile method in bb.utils, but you'd want to read the task to see that. Mar 30 21:21:54 ok. Thanks for the pointer Mar 30 21:21:58 np Mar 30 21:22:28 all the tasks are defined in the classes and recipes, bitbake parses that and runs them Mar 30 21:24:22 ok. Slightly confused since there was also a base.bbclass in my cwd/bitbake Mar 30 21:24:47 that's just an example. bare minimum Mar 30 22:06:20 RP, another bitbake patch http://patchwork.openembedded.org/patch/1334/ Mar 30 22:08:40 kergoth_: were you able to reproduce the issue with FILESDIR that I was seeinhg Mar 30 22:15:36 kergoth: looks like os.path.realpath() killed my SRC_URI symlink in base_do_unpack(). Removing the realpath call just results in the symlink getting copied in oe_unpack_file Mar 30 22:15:55 khem: I think I have a new oneù Mar 30 22:18:21 ant__: hmm Mar 30 22:18:23 http://paste.lisp.org/+22XE Mar 30 22:19:11 I see a custom FILESPATH Mar 30 22:19:23 and the recipe was building not long ago Mar 30 22:20:52 ant__: it seems this is not able to fetch stuff Mar 30 22:20:58 do you have internet connection Mar 30 22:21:06 yea, but I suppose such tarball never existed Mar 30 22:21:17 I fear name is mangled Mar 30 22:23:45 khem: apart this the good news is I could fix kexec-tools vs. autoconf-2.65 Mar 30 22:23:52 cool Mar 30 22:23:59 I'll commit in a while Mar 30 22:24:00 ant__: I think the problem is default name here Mar 30 22:24:41 but how could it work previously? Is a 2010 commit Mar 30 22:25:56 SRC_URI = "${XORG_MIRROR}/individual/proto/${BPN}-${PV}.tar.bz2;name=archive" Mar 30 22:26:19 BPN in recipes/xorg-proto/xextproto-70-includes_7.0.5.bb, Mar 30 22:26:25 is xextproto-70-includes Mar 30 22:26:43 and PN is 7.0.5 Mar 30 22:28:11 ah Mar 30 22:28:46 Add BPN = "xextproto" before including xextproto_7.0.5.bb in xextproto-70-includes_7.0.5.bb Mar 30 22:29:01 03Andrea Adami  07org.openembedded.dev * r9ac5e400b1 10openembedded.git/recipes/kexec-tools/ (2 files in 2 dirs): Mar 30 22:29:01 kexec-tools_2.01: fix configure.ac for autoconf > 2.63 Mar 30 22:29:01 * see debian bug #543081 Mar 30 22:31:02 khem: bingo ! Mar 30 22:31:54 /oe/sources/xextproto-7.0.5.tar.bz2' saved [80831/80831] Mar 30 22:33:07 but that might have other problems Mar 30 22:33:20 build it fully and see if the names etc are correct Mar 30 22:36:06 yea Mar 30 22:38:45 seems ok Mar 30 22:44:21 khem: yeah, reproduced the _[1] error, haven't had a chance to look into it though, doing so now Mar 30 22:48:27 03Andrea Adami  07org.openembedded.dev * r3400d0649c 10openembedded.git/recipes/xorg-proto/xextproto-70-includes_7.0.5.bb: Mar 30 22:48:27 xextproto-70-includes: fix BPN (Base Package Name) to fetch the sources Mar 30 22:48:27 * BPN was xextproto-70-includes, PN 7.0.5 Mar 30 22:55:02 khem: oddly, pulling that snippet out of the metadata, eval'ing it in a standalone script with the same limited globals & locals works fine, so its something specific to bitbake Mar 30 22:55:04 * kergoth mutters Mar 30 22:58:43 oh no..again..NOTE: Task failed: Fetch failed: ftp://elsie.nci.nih.gov/pub/tzdata2010f.tar.gz;name=tzdata-2010f Mar 30 23:04:36 sigh Mar 30 23:04:42 We should really mirror these on the oe mirror Mar 30 23:04:51 yea..mirrorselect :) Mar 30 23:05:10 * Tartarus means preemptively and maybe stop bothering with upstream URI Mar 30 23:05:13 it seems the server is just damn slow.. Mar 30 23:05:59 yea, why isn't it in angstrom mirror? Mar 30 23:10:05 I think the mirror needs updating from time to time Mar 30 23:19:16 good nite Mar 30 23:20:03 khem: interesting. if i change that .join() in your filespathbase bits to not pass a list, so it passes a generator expression instead (just remove the [ and ]), the _[1] error goes away. must have something to do with the list comprehension Mar 30 23:23:26 khem: pushed a change that resolves the other error that can show up (undefined global "d"), but still not sure how best to resolve the _[1] thing Mar 30 23:23:42 you can work around it as i mention above, for now Mar 30 23:27:06 why the hell does this not happen outside of bitbake Mar 30 23:59:55 khem: should be fixed Mar 31 00:03:39 heh thanks kergoth Mar 31 00:05:29 ugh, the way we do our event handlers is .. ick Mar 31 00:17:35 kergoth: where do we use the event handlers atm Mar 31 00:17:48 do we use it for error handling Mar 31 00:19:09 khem: event handlers are used in a number of places in the metadata. events are fired when tasks start, complete, etc Mar 31 00:22:13 kergoth: ah I see. Mar 31 00:38:09 * kergoth grumbles Mar 31 00:39:56 this is odd. Mar 31 00:39:57 h Mar 31 00:39:57 m Mar 31 00:40:00 m Mar 31 02:15:44 er. Mar 31 02:16:21 * kergoth holds off a moment to do more testing Mar 31 02:16:40 I think I *may* have just cut the initial parse time to 1/5th of what it is today Mar 31 02:45:47 Anyone ever have problems building rpm-native? Specifically magic file problems, specifically "file: could not find any magic files! Mar 31 02:45:47 make: *** [magic.mgc] Error 1" under build/tmp/work/x86_64-linux/rpm-native-4.4.2.3-r15/rpm-4.4.2.3/file/magic Mar 31 02:48:22 The file command without the "-C -m magic" option (eg file magic) shows that "magic" is indeed a magic text file. ;) **** ENDING LOGGING AT Wed Mar 31 02:59:56 2010