**** BEGIN LOGGING AT Fri Jan 22 02:59:57 2010 Jan 22 03:16:04 03Khem Raj 07org.openembedded.dev * re140696df4 10openembedded.git/recipes/eglibc/eglibc_svn.bb: Jan 22 03:16:04 eglibc-svn: Bump SRCREV to tip of trunk. Jan 22 03:16:04 Signed-off-by: Khem Raj Jan 22 04:41:57 I'm trying to cross compile in OE a project which uses scons. I get this: CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/gtk-2.0 Jan 22 04:42:15 how do I insert my ${STAGING_DIR}/${BASE_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/ in the -I Jan 22 04:42:19 ? Jan 22 07:15:30 hello i was wondering if anyone could help me with a bitbake recipe, real basic stuff Jan 22 07:17:00 is anyone here? Jan 22 07:21:40 hello Jan 22 07:24:38 hello? Jan 22 07:25:02 can anyone help me Jan 22 07:38:52 03Khem Raj 07org.openembedded.dev * r9b7a3d25ba 10openembedded.git/recipes/wxsqlite3/ (3 files in 2 dirs): Jan 22 07:38:52 wxsqlite3: Add version 1.9.7 recipe. Jan 22 07:38:52 * Fix linker failure due to gcc inline issue (gcc-inline.patch). Jan 22 07:38:52 * Fix broken unicode builds (wxtranslate.patch). Jan 22 07:38:52 Signed-off-by: Johan Hovold Jan 22 07:38:54 Signed-off-by: Khem Raj Jan 22 07:42:59 good morning Jan 22 07:45:32 03Bernhard Kaindl 07org.openembedded.dev * r9c2a58e499 10openembedded.git/recipes/binutils/binutils_2.17.bb: (log message trimmed) Jan 22 07:45:32 binutils_2.17.bb: Fix setscene of binutils-cross-sdk_2.17, switch binutils_2.17.bb to INC_PR Jan 22 07:45:32 * All of the binutils-cross-sdk_*.bb recipes rely on their binutils_*.bb Jan 22 07:45:32 recipe to define INC_PR, but binutils_2.17.bb does not define it, so Jan 22 07:45:34 setscene of binutils-cross-sdk_2.17 fails because it does a mkdir of Jan 22 07:45:36 work/.../binutils-cross-sdk-2.17-\$\{INC_PR\}.1/ which causes an abort Jan 22 07:45:38 when trying to find the setscene scripts later. Jan 22 07:49:05 03Bernhard Kaindl 07org.openembedded.dev * r0ed1a21a00 10openembedded.git/recipes/htop/htop_0.7.bb: (log message trimmed) Jan 22 07:49:05 htop_0.7.bb: Fix htop do_configure: Ensure that ncurses is staged. Jan 22 07:49:05 * htop's do_configure needs ncurses, but htop did only have an RDEPENDS Jan 22 07:49:05 on ncurses which only triggers a build of of ncurses after or in parallel Jan 22 07:49:05 to htop's do_configure, which is too late. Fix this: Jan 22 07:49:09 Since htop is dynamically linked against ncurces, OE detects the REDEPENDS Jan 22 07:49:11 to ncurses automatically and we can simply change the RDEPENDS to DEPENDS. Jan 22 08:04:16 Hi! Jan 22 08:04:36 Have anyone here cross-compiled anyting using bjam (Boost Jam) ? Jan 22 08:24:15 03Marc Olzheim 07org.openembedded.dev * r658cf78bc2 10openembedded.git/recipes/iproute2/ (4 files in 2 dirs): Jan 22 08:24:15 iproute2: Remove unneeded bash dependency Jan 22 08:24:15 * Even though the recipes did not list it in REDEPENDS, two scripts in Jan 22 08:24:15 this package depended on bash. Since this was unneeded, I removed that Jan 22 08:24:15 dependency. (Upstream notified) Jan 22 08:24:17 Signed-off-by: Khem Raj Jan 22 09:05:50 03Robert Schuster 07org.openembedded.dev * rfc301f1583 10openembedded.git/conf/machine/nokia900.conf: Jan 22 09:05:50 nokia900: initial version of machine config for Nokia N900 tablet/phone Jan 22 09:05:50 Written by Robert, tweaked a bit by me. Jan 22 09:05:50 Acked-by: Marcin Juszkiewicz Jan 22 09:05:51 03Guo Hongruan 07org.openembedded.dev * ra72f0d33dd 10openembedded.git/recipes/linux/ (linux-sun4cdm_2.4.26.bb linux-sun4cdm_2.6.8.1.bb): Jan 22 09:05:55 Fix a bug of COMPATIBLE_HOST defination in linux-sun4cdm_*.bb Jan 22 09:05:57 * Correct the defination of COMPATIBLE_HOST in linux-sun4cdm_2.4.26.bb and linux-sun4cdm_2.6.8.1.bb, the previous defination causes linux-sun4cdm never been selected. Jan 22 09:06:00 Signed-off-by: Marcin Juszkiewicz Jan 22 09:06:02 03Marcin Juszkiewicz 07org.openembedded.dev * r9b2387f596 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 22 09:10:53 just wondering, is the official rule now to have checksums in the recipe? And if so, do we plan a conversion and outdate checksums.ini ? Jan 22 09:13:22 * XorA watches the tumble weed Jan 22 09:14:00 * JaMa would like to use in-recipe checksums more.. but it would be nice to have some policy for SRC_URI naming like SRC_URI[archive.md5sum] named the same in every recipe with just one archive? Jan 22 09:16:20 eFfeM: there was a thread about it on ML, but if I remember outcome of it correctly, both ways are correct :P Jan 22 09:16:51 JaMa: anyone is free to write some docs Jan 22 09:17:09 JaMa: if your the first the chances your way wins :-) Jan 22 09:17:31 one issue is there is an infrastucture for the old way and none for the new Jan 22 09:18:14 ynezz: i remember the thread but was not sure about the outcome Jan 22 09:18:49 reason for asking is that I still use the old-style checksums.ini but yesterday committed a recipe on behalf of mlip2 which had inline checksums Jan 22 09:19:03 and got curious what the preferred solution is Jan 22 09:20:21 i've no problem converting the recipes I feel attached to, but I'm not exactly seeking additional work, so if the old way is ok, I won't Jan 22 09:20:38 and happy to use whatever is the preferred way for future recipes Jan 22 09:20:45 i read that on the ML, and this is why I created the recipes using the in-recipe approach Jan 22 09:31:11 hmm, newstyle checksums dont work with gnome software Jan 22 09:36:52 eFfeM: I think, that both ways as correct, looking into git log... Jan 22 09:38:46 good morning Jan 22 09:39:15 i see koen still using the old style Jan 22 09:41:23 florian: 'morning Jan 22 09:41:48 eFfeM: it's not only him, git log -p and look for checksums.ini Jan 22 09:42:52 different topic: packaged staging: would it be ok to move pstage out of tmp/deploy set DEPLOY_DIR_PSTAGE then nuke tmp, or do I need to fully rebuild Jan 22 09:43:26 ynezz: I know, just mentioned koen as he is one of the opinion leaders (if that is the right phrase) Jan 22 09:43:44 eFfeM: there were some bugs when it was moved outside, I dont know if they ever got fixed, it was either mckoan or ant_work that was having issues Jan 22 09:44:02 XorA: guess I'll take the safe route then Jan 22 09:44:53 eFfeM: ask them, it would be good to keep it outside tmp/ Jan 22 09:45:01 eFfeM: I only warned in case you saw issues Jan 22 09:45:24 one more staging q: I see now that pstage is in deploy/*libc, but build for machines that use glibc and for machines that use eglibc. can I mix these or do I need to have some LIBC related var in my DEPLOY_DIR_PSTAGE Jan 22 09:46:03 XorA: do you mean on the IRC ? Jan 22 09:46:03 XorA: Thanks, mckoan, ant_work: any comments ? Jan 22 09:47:23 mckoan: vageu memories you had some issue with packaged staging Jan 22 09:47:37 well, if your image contains a package using 'package_stagefile_shell' you get problems moving pstage out of tmpdir Jan 22 09:47:55 but biggest problem I/we see is the arch-mismatch Jan 22 09:48:13 I mean, staging-ipk are defaulting to host arch... Jan 22 09:48:53 and this is with 'regular' layout Jan 22 09:49:37 eFfeM: why you want to move pstage out of tmp/deploy ? Jan 22 09:50:32 mckoan: a few days ago someone pointed me to this page from hrw: http://marcin.juszkiewicz.com.pl/2008/07/01/packaged-staging-and-what-it-gives/ Jan 22 09:50:58 and I also once had issues that mythtv failed because there was an old version in staging Jan 22 09:51:06 and then someone mentioend: use packaged staging Jan 22 09:51:27 btw, host arch is just fine for the -cross and -native, absolutely wrong for the others... Jan 22 09:52:19 actually even seem to recall koen mentioned that with packaged staging this problem (linking against an old lib in staging instead of loally) would go away with packaged staging, but not fully sure any more Jan 22 09:52:40 mckoan: if it is out of tmp/deploy it is easier to remove the rest Jan 22 09:53:14 eFfeM: the point was to have per-package staging Jan 22 09:53:53 ~curse python for infecting gnome Jan 22 09:53:54 May the fleas of a thousand camels infest your most sensitive regions, python for infecting gnome ! Jan 22 09:54:38 yeah but staging currently still contains old versions, they are not removed or so, so guess a good practice could be to have pstage outside of tmp and remove tmp very regularly Jan 22 09:55:09 eFfeM: I'm not sure about real benefits of it, I should try Jan 22 09:55:43 I faced to weird problems two days ago Jan 22 09:56:59 I wasn't able to build the version I wanted of a package, the only way after houts playing with bitbake -cclean and so on has been to delete tmp and rebuild Jan 22 09:57:44 I'm afraid with pstage out of tmp/deploy will raise more problems than benefits Jan 22 09:58:08 from a QA perspective (to get proper dependencies) it would make sense to rm tmp after every package build and repopulate staging with only what is in depends; afai understand things now even with pstage if you build console-image still everything will end up in staging and missing dependencies might go unnoticed because some other pacakge installed things Jan 22 10:00:39 eFfeM: I'd rather consider a selective package cleaning that AFAIK is not available now Jan 22 10:04:17 a good point for packaged-staging would be if it allow development environment/tree moveable Jan 22 10:05:49 not sure if that is possible Jan 22 10:08:27 actually thinking of it the tree could perhaps be moved to a different system, but not to a different location, because there are files in staging (and hence in the staging recipes) that contain paths. E.g. *-config stuff Jan 22 10:22:29 pb_: what a dense e-mail (opcode 0xed5b0b23)! Heat-off! Jan 22 10:48:00 morning all Jan 22 10:48:06 hi gremlin Jan 22 10:48:12 hi woglinde ! Jan 22 10:49:34 hi gremlin[it] Jan 22 10:56:30 hmm, how does the pkgconfig SYSROOT support work? Jan 22 10:56:44 hi mckoan Jan 22 11:03:20 XorA: man pkgconfig? Jan 22 11:04:09 zecke_: it looks like OE does it right, this cursed Makefile doesnt pick up the env vars for some reason Jan 22 11:04:51 XorA: PKG_CONFIG_SYSROOT_DIR Jan 22 11:05:07 zecke_: yes which we export from bitbake.conf Jan 22 11:06:05 XorA: is it using the wrong pkg-config? Jan 22 11:06:19 zecke_: that is possible, I am debugging it now Jan 22 11:06:37 hi xora Jan 22 11:29:43 hi pb Jan 22 12:53:13 re Jan 22 13:03:20 hi hrw Jan 22 13:09:17 gm Jan 22 13:11:35 Crofton_|work: hi Jan 22 13:17:19 anyone look over the libxml recipe? Jan 22 13:26:14 I remember I saw something strange during build...I have a log somewhere, can't check offhand Jan 22 13:26:33 the patch for libxml2 :) Jan 22 13:26:37 it applies :) Jan 22 13:27:17 I am mainly worried if changing the configure options adds depends Jan 22 13:27:46 hej (i am the one who wrote this patch) Jan 22 13:27:53 hi Jan 22 13:28:02 iirc there was some packaging flaw.. Jan 22 13:28:10 well, actually it compiles fine, and the if it compiles it doesnt add any extra deps Jan 22 13:28:19 do you know if there are additional packages that must be built due to the configure changes Jan 22 13:28:30 well, they may have alrady been built Jan 22 13:28:36 i needed the configure options for the new recipe on xml::libxml Jan 22 13:28:41 but a different order of build might cause a problem Jan 22 13:28:43 yeah Jan 22 13:29:01 so, a clean of tmp and rebuild would show ? Jan 22 13:29:10 ./contrib/patchwork/pw-am.sh 1505 Jan 22 13:29:14 somethign like that Jan 22 13:29:31 can't i just output the dependencies with bitbake -g ... ? Jan 22 13:29:33 any patch that works with that and has a good log message is much more likely to get in :) Jan 22 13:29:51 those are read from the recipe :) Jan 22 13:30:22 but then i would have to do a bitbake world ? Jan 22 13:30:40 since only then we have the guarantee that everything builds ? Jan 22 13:33:43 actuall rm tmp Jan 22 13:33:49 and bitbake libxml2 Jan 22 13:33:56 k, doing that Jan 22 13:34:02 thanks Jan 22 13:34:19 painful I know Jan 22 13:34:33 well, if thats the requirements, then it has to be done ;) Jan 22 13:34:46 well Jan 22 13:34:57 some people are more strict than others Jan 22 13:35:12 if you are real fmailiar, you know what can change Jan 22 13:35:32 also, there will need to be a pr bump Jan 22 13:35:42 I'll do that in another commit Jan 22 13:36:13 i'll do the rebuild without it, and report on whether it builds Jan 22 13:36:17 mlip if you want to i can build overnight Jan 22 13:36:30 already got rid of tmp ;) Jan 22 13:37:08 grep -l says that some 200 recipes use libxml2, ofc there are some dups (different versions of a recipe) so it is a fairly important recipe Jan 22 13:37:37 do i have to build those too ? Jan 22 13:38:13 eh, well there are things in it that I cannot test and I guess you cannot either Jan 22 13:38:21 because buidling is one and testing is two Jan 22 13:38:43 then again the configure options should extend functionality so i feel they are fairly safe Jan 22 13:39:10 that i thought too; libxml2 gets more features, so it should be fairly safe Jan 22 13:40:20 intriguing observation: dbus-native depends on libxml2-native but dbus itself does not depend on libxml2 Jan 22 13:41:06 btw the fact that libxml2 is fairly core was the argument not to add those new flags in libxml2-native (if it ain't broken don't fix it) Jan 22 13:45:01 worst case it gets reverted, I am not sensitive about that sort of thing Jan 22 13:46:26 200/448 - i think in 30mins i can tell if libxml2 builds from scratch Jan 22 13:48:45 re Jan 22 13:50:56 hm oh firefox 3.6 is out Jan 22 13:51:22 woglinde: and my nomaroka says still 3.6pre even with today's version ;D Jan 22 13:51:28 * hrw -> coffee Jan 22 13:51:44 ~lart phoronix Jan 22 13:51:45 * ibot slaps phoronix upside the head with a wet fish Jan 22 14:09:08 what this time? Jan 22 14:09:40 firefox 3.6 Jan 22 14:17:03 Crofton_|work eFfeM_work: NOTE: Tasks Summary: Attempted 448 tasks of which 0 didn't need to be rerun and 0 failed. Jan 22 14:17:10 bitbake libxml2 from scratch Jan 22 14:17:20 thanks Jan 22 14:17:25 I'll push in a fwe minutes Jan 22 14:17:58 dunno what about the recipes that require libxml2, but since the patch adds features (without any more deps) this should be no problem Jan 22 14:20:25 mlip: cool, good work Jan 22 14:21:19 Crofton_|work: will you also push the libxml-libxml-perl recipe ? That was the reason the libxml2 recipe needed to be changed Jan 22 14:22:26 yeah Jan 22 14:22:32 I wanted to work on this one first Jan 22 14:23:13 sure Jan 22 14:24:01 03Philip Balister 07org.openembedded.dev * r71edf0fca9 10openembedded.git/recipes/libxml/ (libxml2.inc libxml2_2.7.3.bb): libxml2 : Convert to INC_PR. Bump PR for earlier commit. Jan 22 14:24:11 03Michael Lippautz 07org.openembedded.dev * r8477bc642e 10openembedded.git/recipes/libxml/libxml2.inc: Jan 22 14:24:11 libxml2: Add catalog and docbook support Jan 22 14:24:11 * Adds catalog and docbook support, which is needed for Jan 22 14:24:11 libxml-libxml-perl recipe. Jan 22 14:24:13 Signed-off-by: Philip Balister Jan 22 14:24:28 * eFfeM_work just didn't want that it got dropped, as the xmltv recipe could also benefit from the perl recipe (will dig into that later this weekend) Jan 22 14:25:07 btw is it mandatory or recommended to add a signed-off line if you push on behalf of someone else ? Didn't do that yesterday with the other files from Michael that I pushed for him Jan 22 14:27:40 I think the pw script does that Jan 22 14:27:56 ~curse intel badly for "Intel released version 2.10.0 of the X.org xf86-video-intel driver, which is usually just called "intel". This is the first version to require a kernel with KMS support." Jan 22 14:27:57 May the fleas of a thousand camels infest your most sensitive regions, intel badly for "Intel released version 2.10.0 of the X.org xf86-video-intel driver, which is usually just called "intel". This is the first version to require a kernel with KMS support." ! Jan 22 14:28:19 hrw? Jan 22 14:29:00 woglinde: my laptop can not use intelfb Jan 22 14:29:50 Crofton, ah, so you didn't add it yourself Jan 22 14:30:05 hrw dell crap Jan 22 14:30:06 eFfeM_work, right Jan 22 14:30:07 *g* Jan 22 14:30:25 woglinde: intel crap Jan 22 14:31:33 * kergoth always uses ci -s out of habit.. should just move the -s into the ci alias, really.. Jan 22 14:31:48 Crofton_|work: odd, I pushed this for him http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=6cd92d1545ccf5d4f1459f70faa81be68adb0794 Jan 22 14:32:01 http://0pointer.de/blog/projects/udev-browse.html Jan 22 14:32:04 nice stuff Jan 22 14:32:05 that did not add a signed_off msg, so it must be some local config I assume Jan 22 14:32:25 using the contrib/patchwork script? Jan 22 14:32:42 this stupid PR = "r0" stuff is annoying Jan 22 14:33:06 guess so, I committed with git commit --author Jan 22 14:33:19 * eFfeM_work does not really have knowledge on patchwork Jan 22 14:35:49 hrw: do you happen to remember the history of updater.sh? The origins I mean? Jan 22 14:39:25 ant_work: mickeyl know more but I can tell some too Jan 22 14:39:41 hrw: it seems there were headers appended to the kernel and prepended to the initrd originally Jan 22 14:39:54 ant_work: first ver was with poodle, then c7x0, tosa, spitz, akita, borzoi/terrier Jan 22 14:40:11 yea, these share same 7168k mtd stuff Jan 22 14:40:24 ant_work: someone decoded it, Sash and pdax people wrote own ver, other people too Jan 22 14:40:34 ant_work: we used original sharp ones iirc Jan 22 14:40:57 ant_work: one day I started to merge poodle/c7x0/tosa/akita/spitz versions into one which we use now. Jan 22 14:41:16 ant_work: when and why image header got added? no idea - looks like it was there from start Jan 22 14:41:37 I see...anyway the flashing process is still not perfect, it seems. Stanislav said updater.sh doesn't do proper checksum Jan 22 14:41:37 ant_work: for me it looks like sharp planned to store version of rootfs there Jan 22 14:41:59 exactly, and read it from the diagnostic Jan 22 14:42:23 these checksums/mver have any value for us Jan 22 14:42:30 using 2.6 Jan 22 14:42:36 or am I wrong? Jan 22 14:42:55 never checked that stuff Jan 22 14:43:16 I mostly assumed that updater.sh is what it is and does what it does. Jan 22 14:43:42 planned to drop that 16B header but at that time I also dropped Z support Jan 22 14:43:59 hi booxter Jan 22 14:44:00 ;) Jan 22 14:44:05 great work, btw Jan 22 14:44:37 ant_work: good thing was that I had most of Z models at desk at that time so testing was easier Jan 22 14:44:58 hrw: we come now to the point where an user could even ignore that cumbersome Keypress on boot... Jan 22 14:46:03 ant_work: I like 2.4 rescue mode Jan 22 14:46:25 he..you need old,small SD/CF Jan 22 14:46:35 with that kernel Jan 22 14:48:10 hrw: do you think it makes sense spending time on ubifs on Z? Jan 22 14:48:46 latest kernels have support compiled-in Jan 22 14:48:57 ant_work: ubifs is faster then jffs2 Jan 22 14:49:16 ubifs has sense on any device Jan 22 14:49:22 I see Jan 22 14:49:26 which uses root on flash Jan 22 14:49:46 even on small 121MB flash? Jan 22 14:50:47 it is not small Jan 22 14:51:10 I have here devices with smaller flash chips Jan 22 14:51:18 what do routers use? squashfs-lzma? Jan 22 14:52:40 mostly Jan 22 14:55:18 Crofton_|work: http://patchwork.openembedded.org/patch/1502/ is for stable - can you? Jan 22 15:00:14 In the oe docs it says that ROOTFS_POSTPROCESS_COMMAND could be used to change the root password. Thats pretty much all I find about setting the password. I have seen examples where they use zap_root_password but nothing that actually explains how it should be done Jan 22 15:00:34 check zap_root_password function then? Jan 22 15:04:26 hrw, does that take into account khem's commnet? Jan 22 15:04:36 yes Jan 22 15:04:37 I thought you might have messed up the subject line :) Jan 22 15:04:45 I did Jan 22 15:06:03 done Jan 22 15:06:17 Laibsch, thanks for responding to the svga patch Jan 22 15:06:21 jovox you can just issue a command in ROOTFS_POSTPROCESS_COMMAND e.g. a command to hack a different root password in the root fs (ofc there are also other ways to achieve it like copying a passwd file or even make a recipe that gives a passwd fiel) Jan 22 15:06:47 mlip, I have been stuck on this for quite some time Jan 22 15:06:51 thx, now need patchwork to catch it Jan 22 15:06:52 NOTE: Running task 549 of 578 (ID: 425, virtual:native:/home/balister/oe/openembedded/recipes/perl/libxml-namespacesupport-perl_1.10.bb, do_configure) Jan 22 15:07:15 NOTE: Running task 4333 of 7280 (ID: 3215, /home/hrw/devel/buglabs/trunk/meta-bug/packages/bug-apps/com.buglabs.app.timelapse.bb, do_build) Jan 22 15:07:22 yeah Jan 22 15:07:27 BBCLASSEXTEND Jan 22 15:07:38 hm next will be zlib I will switch Jan 22 15:08:55 Crofton_|work: mhm ? Jan 22 15:09:39 Crofton_|work: I've build it yesterday before checking in without any problem Jan 22 15:10:05 it is not an earlier task that is in progress? (due to parallel make etc). Jan 22 15:10:09 Crofton_|work: maybe Jan 22 15:10:13 stop it Jan 22 15:10:18 because i think Jan 22 15:10:21 you'Ve created a huge logfile by now Jan 22 15:10:25 heh Jan 22 15:10:32 because there is some unitiliazed log file Jan 22 15:10:41 s/log/config Jan 22 15:11:28 i've seen this before, but since it disappeared after i did a clean build i thought it would have been cause by my corrupted tmp Jan 22 15:11:53 looks like it is looping on a continent selection Jan 22 15:11:55 there's something going on with perl/cpan/initialization that asks the user for some parameters (which country, etc) Jan 22 15:12:33 so this has not been caused by my corrupted tmp, but is a general problem :/ Jan 22 15:12:39 pb__: can you please look with your expirienced eye, if there is something obviously wrong (possible another thumb issue?) http://pastebin.ca/1761592 Jan 22 15:13:33 I'm assuming that nothing "normal" will trgger this? Jan 22 15:14:14 basically, I need to do some CPAN action to set the var it is looping? Jan 22 15:14:18 eFfeM_work, ok, I'll write a recipe for that then. Thanks a lot Jan 22 15:14:32 JaMa: yeah, that looks like you have a thumb interworking problem in libxml Jan 22 15:14:35 jovox, just mentioning options Jan 22 15:14:54 what does the call site at 0x409b2538 look like? Jan 22 15:15:20 Crofton_|work: I dont have that cpan(.bbclass) knowlegde, but setting the var only helps if Makefile.PL uses it Jan 22 15:15:40 jovox: i've seen that flag been used to rm some files from the rootfs Jan 22 15:15:51 Crofton: ? SVGA patch? Jan 22 15:16:06 I can't recall replying to that Jan 22 15:16:12 eFfeM_work, yeah, thats how I have used it as well Jan 22 15:16:17 svgalib Jan 22 15:16:29 you asked for something from git format patch Jan 22 15:17:12 pb_: updated http://pastebin.ca/1761602 Jan 22 15:17:16 I going to push the patch and depend on no one building perl :) Jan 22 15:17:17 And maybe it would be the right place to put it btw otherwise the password file might be overwritten by some other package.. Jan 22 15:18:19 03Michael Lippautz 07org.openembedded.dev * rca64b38e43 10openembedded.git/recipes/perl/ (2 files in 2 dirs): Jan 22 15:18:19 libxml-libxml-perl: Adds perl module XML::LibXML Jan 22 15:18:19 Signed-off-by: Philip Balister Jan 22 15:18:31 hi likewise Jan 22 15:18:46 hmm, maybe the email I saw was from eFfeM_work Jan 22 15:18:51 no Jan 22 15:18:54 urg Jan 22 15:18:58 back to work Jan 22 15:19:06 jovox, i think it is ok if your recipe is the last one in the image Jan 22 15:19:20 Crofton_|work: have you found a solution to the looping problem ? Jan 22 15:19:26 ok, I will try that Jan 22 15:19:31 Crofton: I think you mistake me for Paul Menzel, no? Jan 22 15:19:40 no Jan 22 15:19:44 OK Jan 22 15:19:47 Anyways Jan 22 15:19:49 I am guessing if you do something from the command line Jan 22 15:19:58 with CPAN the problem goes away Jan 22 15:20:21 :/ Jan 22 15:20:24 not ideal Jan 22 15:20:31 no Jan 22 15:20:51 but i can't trigger it a second time Jan 22 15:20:54 ;) Jan 22 15:22:29 Crofton_|work: could you paste the log, or something from the dialog? Jan 22 15:22:45 can't do a search which function/module causes this whithout any hint Jan 22 15:23:21 not easily Jan 22 15:24:13 i just remember that it asked for the country Jan 22 15:24:48 http://sscnet.ch/node/20 Jan 22 15:24:52 i think it was this dialog Jan 22 15:26:38 JaMa: hm, strange, that doesn't make a lot of sense. Jan 22 15:27:14 RP: Is the successor you were talking about any of InDefero, Redmine or Girocco? Jan 22 15:27:47 fourth option would be Gitorious that runs gitorious.org Jan 22 15:27:57 any of those four? Jan 22 15:29:11 pb_: :/ I'll try with rebuilded libxml (this problem is older than last changes to libxml) Jan 22 15:30:02 okay, good idea Jan 22 15:30:22 your problem seems to be that something is jumping into thumb code in the wrong state, anyway Jan 22 15:36:56 RP: I guess you mean gitolite, don't you? Jan 22 15:41:21 mlit is looping on the continent question Jan 22 16:01:30 Laibsch: yes Jan 22 16:19:11 pb_: strange indeed http://pastebin.com/m1e941d48 Jan 22 16:28:17 JaMa: caused by my libxml2 patch ? :/ Jan 22 16:29:14 mlip: probably not.. there was problem even before.. but it changed now Jan 22 16:29:48 oke; triplechecked the libxml homepage now and it says: Jan 22 16:30:03 Libxml2 does not require any other library, the normal C ANSI API should be sufficient (please report any violation to this rule you may find).# Jan 22 16:32:29 re Jan 22 16:47:56 03Chris Larson 07org.openembedded.dev * r53c1e82f65 10openembedded.git/recipes/shadow/shadow_4.1.4.2.bb: Jan 22 16:47:56 shadow: unbork the dependencies.. its DEPENDS, not DEPEND. Jan 22 16:47:56 Signed-off-by: Chris Larson Jan 22 16:47:57 03Chris Larson 07org.openembedded.dev * rac39d0bcd2 10openembedded.git/recipes/man/man_1.5p.bb: Jan 22 16:47:59 man: fix ldflags typo Jan 22 16:48:01 Signed-off-by: Chris Larson Jan 22 16:48:03 03Chris Larson 07org.openembedded.dev * r0174458a62 10openembedded.git/recipes/shadow/ (4 files): Jan 22 16:48:06 shadow: reorg into .inc, pull some mvl6 changes over, use a 'pam' distro feature. Jan 22 16:48:08 Signed-off-by: Chris Larson Jan 22 16:48:10 03Chris Larson 07org.openembedded.dev * r8cb2e3b5d3 10openembedded.git/recipes/postfix/postfix.inc: Jan 22 16:48:13 postfix: kill funky FILESDIR usage in SRC_URI Jan 22 16:48:15 Signed-off-by: Chris Larson Jan 22 16:48:17 03Chris Larson 07org.openembedded.dev * r81cd71f8a5 10openembedded.git/recipes/libcap/libcap2_2.16.bb: Jan 22 16:48:24 libcap: BUILD_CFLAGS can need the libcap/include too Jan 22 16:48:26 Signed-off-by: Chris Larson Jan 22 16:51:00 03Chris Larson 07org.openembedded.dev * rc6088e9906 10openembedded.git/recipes/iptables/ (7 files in 2 dirs): Jan 22 16:51:00 iptables: unbork the 1.3.8 build, merge iptables-utils into iptables. Jan 22 16:51:00 In recent iptables versions, the -save and -restore files are just symlinks Jan 22 16:51:00 pointing to the main, merged binary, so the separate package is a bit Jan 22 16:51:02 unnecessary. Jan 22 16:51:04 Signed-off-by: Chris Larson Jan 22 16:52:14 gogogo kergoth Jan 22 16:52:22 hehe Jan 22 16:52:28 trying to get through some of the backlog Jan 22 16:52:40 think i've got all the recipe changes that we couldn't easily do in amend.inc files upstream now Jan 22 16:52:51 now to push any class/.inc/.conf changes.. Jan 22 16:52:58 and amend.inc? :) Jan 22 16:53:15 its pushed Jan 22 16:53:34 yay Jan 22 16:53:44 pushed amend.inc and package_dbg.bbclass both on tuesday Jan 22 16:53:51 (the latter does per-subpackage dbg packages) Jan 22 16:54:05 think i'll push newcollection.inc today Jan 22 16:55:42 g'day kergoth Jan 22 16:55:45 hey pb_ Jan 22 16:56:28 hmm, never did get around to killing the explicit path list in package_dbg.. ah well, one of these days Jan 22 17:02:20