**** BEGIN LOGGING AT Thu Oct 21 02:59:58 2010 Oct 21 03:34:18 Is www.angstrom-distribution.org on dialup these days? Oct 21 03:36:36 grg, I wouldn't know about that one...not one I help with... Oct 21 03:37:37 i'm beginning to think INHERIT += angstrom-mirrors is a bad thing Oct 21 03:42:16 grg, it sounds like there was a non-angstrom file that drove the server past its transfer limit Oct 21 03:42:38 angstrom stuff is on linuxtogo Oct 21 03:42:54 we, the angstrom guys, need to work out a better solution .... Oct 21 04:46:45 yarrr Oct 21 04:50:55 new ubuntu font = ftw Oct 21 04:52:33 hmm, how do you grab that? Haven't had a chance to check it out yet Oct 21 04:57:32 * kergoth mutters Oct 21 06:16:31 morning! Oct 21 06:17:47 morning eFfeM_work Oct 21 06:27:39 eFfeM_work, you remember the MasterMakefile we used over on nslu2-linux? Oct 21 06:27:49 yes ofc Oct 21 06:28:25 working on one for here. Oct 21 06:29:28 here we also have a small makefile to kick off our projects (get bitbake and oe if they are not there, check out our overlays from the local scm etc) Oct 21 06:29:47 makes it nice for the autobuilder as only a few things have to be done Oct 21 06:31:38 oh I should look @ those. Oct 21 06:33:55 they are not in OE as they are reasonably specific; but mostly it has a rule for app which depends on openembedded which in turn checks out openembedded if it does not exist; same for bitbake; additional rules for clean and update Oct 21 06:34:56 I just remmber we could call a couple of targets and make an entire image. Oct 21 06:35:12 including fetching the toolchains. Oct 21 06:35:24 yes Oct 21 06:35:52 that would be helpful for regression testing Oct 21 06:35:58 yup Oct 21 06:36:55 okay time for sleep, will play with that tommorrow. Oct 21 06:38:07 whoops Oct 21 06:42:27 Good morning! Oct 21 06:42:35 hi mfhk Oct 21 06:43:06 Hi effem, the kernel building page is here: http://wiki.openembedded.org/index.php/Kernel_Building Oct 21 06:43:25 Hope it's what you want. Oct 21 07:17:09 mfhk: saw your page; good start! I've added it to the faq Oct 21 07:17:25 Thanks :) Oct 21 07:17:39 you might want to merge your menuconfig chagnes things to it Oct 21 07:17:58 ok Oct 21 07:18:00 btw adding to the faq is just adding a category tag to the end of the page (like user) Oct 21 07:18:16 I see. Oct 21 07:18:42 and wrt The default .config file used is placed in ???/defconfig Oct 21 07:19:28 ??? Oct 21 07:19:30 actually it is normally somewhere under recipes/linux, fetching it follows the std rules for fetching files (using FILESPATHPKG or whatever the name is) Oct 21 07:19:46 and you can put them in an overlay Oct 21 07:20:32 the -c menuconfig task will just start menuconfig and change the .config in the work dir (so changes are lost if you rm tmpdir or -c clean virtual/kernel Oct 21 07:21:12 I know that. I will update on these. Oct 21 07:21:26 nice, thanks Oct 21 07:23:26 good morning Oct 21 07:44:29 after todays fetch I get checksum mismatch on libsamplerate0_0.1.7.bb. anyone else seeing this? Oct 21 07:44:36 (good morning) Oct 21 07:46:09 tasslehoff: did you remove it from your downloads dir? Oct 21 07:46:22 tasslehoff: checksum was changed few days ago.. so you have to redownload it Oct 21 07:49:01 JaMa|W: thanks. Oct 21 08:00:10 03Martin Jansa  07master * rf86164e73e 10openembedded.git/recipes/linux/ (4 files in 3 dirs): Oct 21 08:00:10 linux(-kexecboot): add recipe for 2.6.36 version + spitz defconfig Oct 21 08:00:10 Signed-off-by: Martin Jansa Oct 21 08:23:18 03Koen Kooi  07org.openembedded.dev * rec39356527 10openembedded.git/conf/machine/ (mtx-3.conf mtx-3a.conf): conf/machine: first batch of preferred_version removal: gcc/glibc/binutils Oct 21 08:29:29 03Koen Kooi  07org.openembedded.dev * rffd7fe5dfa 10openembedded.git/conf/machine/ (13 files): omap machines: remove preferred versions from machine files, the recipes already pin those correctly Oct 21 08:36:17 someone has patch for busybox-1.16.2 with make-3.82? similar patch is applied in busybox-1.13.2 Oct 21 09:46:23 hi all,im trying to make a inherit module...this is how im doing it....im getting error in do_compile stage....any suggestion http://pastebin.com/PH0z62ue Oct 21 09:54:14 what's the content of $D in pkg_postinst? Oct 21 09:54:44 Heinervdm: empty on target, rootfs dir on host Oct 21 09:55:04 eFfeM_work: ok, thx Oct 21 10:00:38 this is the error im getting...http://pastebin.com/Y76yzBLn Oct 21 10:02:02 hitlin37_: make: *** No targets specified and no makefile found. Stop. <- are you sure $S is correct? Oct 21 10:28:46 how do i check....i made a angstrom image first ....then i put my recipe in oe recipe directory... Oct 21 10:30:33 is this the directory where i ahve to place my make file Oct 21 10:30:36 build/tmp-angstrom_2008_1/work/beagleboard-angstrom-linux-gnueabi/usb-dongle-r90 Oct 21 10:58:55 now im getting make: *** No rule to make target `modules_install'......im making it for target system,so why its installing on host,im doing this MACHINE=beagleboard bitbake -b usb_dongle.bb Oct 21 10:59:57 hitlin37_: and you know what "-b" argument to bitbake mean? Oct 21 11:01:41 build....i guess Oct 21 11:02:44 what command i need so that..it makes a .ipk for target Oct 21 11:07:20 hitlin37_: -b == --break-build-for-me-cause-I-do-not-know-what-I-am-doing Oct 21 11:07:39 hmmmm Oct 21 11:09:59 could u suggest me some place i can start with...to make a inherit module Oct 21 11:10:34 hitlin37_: the module.bbclass expects a proper Makefile Oct 21 11:12:13 i have makefile for linux system...it works fine on linux....now im trying for target system Oct 21 11:13:52 so that i can use modprobe..and run my driver on target Oct 21 11:15:32 khem: with latest version of target binutils patch it pulls /usr/lib/libz.so from host http://tinderbox.openembedded.org/public/logs/task/8983798.txt Oct 21 11:52:09 JaMa|W, I am pretty sure I see that on oprofile also Oct 21 11:55:11 hi Oct 21 12:57:57 hi Oct 21 12:58:08 pb_: RP: I might have issues following the meeting today Oct 21 12:58:26 is there someone with error to compile gcc-cross-initial-4.3.3-r18.1 ? Oct 21 13:11:19 zecke: ok Oct 21 13:11:49 fidencio_, that should have been fixed last night Oct 21 13:12:06 Crofton|work: hmmm. Ok. I'll update and try again. Oct 21 13:19:29 what does FILES_${PN} in a recipe do? Oct 21 13:39:18 tasslehoff: it is the var that specifies which files go in the package with name ${PN} Oct 21 13:39:29 you could also say FILES_xyz Oct 21 13:39:37 xyz must be in PACKAGES Oct 21 13:42:16 eFfeM_work: ok. thanks :) Oct 21 13:42:27 * tasslehoff works at connecting the dots Oct 21 13:42:36 yw Oct 21 13:43:16 a good way to learn is to peek at existing recipes (and perhaps play with it0 Oct 21 13:43:21 and ofc read the manual Oct 21 13:44:23 see e.g http://docs.openembedded.org/usermanual/usermanual.html#chapter_metadata Oct 21 14:02:31 Crofton|work: tks :-) Oct 21 14:13:42 Crofton|work: my master is up to date, but still broken, now in binutils-cross :-\ Oct 21 14:14:35 err. not in bin-utils, this is in gcc-cross-initial yet Oct 21 14:32:37 @all: guys, I'm having a problem to build gcc-cross-initial using HEAD's master. This is the log: http://pastebin.com/q5g76TDQ Oct 21 14:32:58 Is there someone with the same problem? Oct 21 15:29:20 hrm Oct 21 15:37:16 fidencio_: update to latest head and build from scratch Oct 21 15:37:20 gm all Oct 21 15:42:09 khem: I update here and the only change is in oe/darwin Oct 21 15:43:52 * kergoth grumbles, darwin is progressing much more slowly than he'd hoped. getting there, but it'll be a long time Oct 21 15:46:30 kergoth: building darwin with oe? Oct 21 15:46:41 working on it, clearly i'm a glutton for punishment Oct 21 15:46:53 pretty cool Oct 21 15:47:22 * florian always wondered how much effort it would be to build some BSD with oe Oct 21 15:49:13 someone was trying to build it with freebsd, not sure who or how far they got, though Oct 21 15:50:06 fidencio_: how about rebuilding from scratch Oct 21 15:50:34 khem: sorry, rebuild from scratch? how? Oct 21 15:50:37 kergoth: you mean freebsd a target Oct 21 15:51:05 fidencio_: rm -rf ; bitbake Oct 21 15:51:53 khem: gimme some hours to test Oct 21 16:00:30 kergoth: would be interesting as well... it seems to be not entirely uncommon in the embedded world Oct 21 16:02:46 libx11-1_1.3.2-r9.2 is failing in do_compile: Oct 21 16:02:53 i486-oe-linux-libtool: link: warning: library `/home/michael/git/newstix/tmp/sysroots/i486-oe-linux/lib/libxcb.la' was moved. Oct 21 16:02:57 grep: /lib/libpthread-stubs.la: No such file or directory Oct 21 16:03:05 /usr/bin/sed: can't read /lib/libpthread-stubs.la: No such file or directory Oct 21 16:03:13 this is with libtool 2.4 Oct 21 16:12:52 does anyone else think itd be nice if all the shit we say we require in the insane/sanity check was as -natives? :| Oct 21 16:12:56 we need to fix this at some point Oct 21 16:23:58 oh jesus Oct 21 16:24:08 default gcc in osx builds 64 bit binaries, but uname says i386 Oct 21 16:24:14 * kergoth twitches Oct 21 16:24:23 * kergoth adds -m32 to BUILD_CC_ARCH Oct 21 16:25:04 hrm Oct 21 16:25:17 | m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DPIC add_n.asm >tmp-add_n.s Oct 21 16:25:17 | m4:../config.m4:30: cannot open `-n .././mpn/asm-defs.m4 Oct 21 16:25:17 | ': No such file or directory Oct 21 16:25:20 thats a new one.. Oct 21 16:25:31 its trying to open a commandline argument with a newline in it? Oct 21 16:25:35 what the hell is going on Oct 21 16:43:35 what the hell Oct 21 16:43:39 this gmp failure is so weird. Oct 21 16:45:55 er Oct 21 16:45:58 weird. Oct 21 16:46:07 it runs echo -n, an somehow the -n isn't interpreted by echo Oct 21 16:46:10 yet an echo at the commandline does Oct 21 16:46:16 * kergoth scratches head Oct 21 16:46:53 gm Oct 21 16:47:11 kergoth: builtin echo vs /bin/echo ? Oct 21 16:47:24 hmm good idea Oct 21 16:47:26 * kergoth checks Oct 21 16:47:34 although I thought every variant I know supports -n Oct 21 16:47:37 nope, both work Oct 21 16:47:41 grr Oct 21 16:47:44 yeah, me too Oct 21 16:47:45 very werid Oct 21 16:47:55 only happens when building gmp-native on darwin, though Oct 21 16:48:05 hrm Oct 21 16:48:19 and yet, gmp's homebrew recipe doesnt' have anything fancy.. Oct 21 16:48:31 course, they don't re-generate the config stuff Oct 21 16:48:39 but still Oct 21 16:58:14 anyone working with omap3 and qt or gles? finding that qt4-embedded-gles is not building and not clear if people are using it or not Oct 21 16:58:47 I'm assuming that qt4-embedded-gles uses virtual/egl (libgles-oma3 in my case) for rendering? Oct 21 16:59:12 shell scripting note, for those who aren't aware, use getopts instead of getopt if you want portable argument handling with support for spaces in args Oct 21 17:00:36 hey all, anyone in here familiar with Gumstix? Oct 21 17:02:01 some Oct 21 17:03:51 a bit Oct 21 17:07:03 Has anyone used their stagecoach (multi COM expansion board)? Oct 21 17:07:27 In particular, has anyone tried using openMPI on the gumstix? Oct 21 17:16:29 could someone look in tmp/sysroots//lib/libxcb.la and tell me what dependency_libs should be set to? Oct 21 17:16:40 mine is dependency_libs=' -L/home/michael/git/newstix/tmp/sysroots/i486-oe-linux/lib /lib/libpthread-stubs.la /lib/libXau.la /lib/libXdmcp.la' Oct 21 17:16:58 i.e. no sysroot prefix on /lib/libpthread-stubs.la :( Oct 21 17:17:21 dpackard, I have sort of poked at it Oct 21 17:17:30 at least getting it built Oct 21 17:18:30 Sorry, I shouldn't have asked two questions at once. So you were able to build openMPI? Oct 21 17:18:50 dpackard, I do not think so Oct 21 17:18:57 I forget what the issue was Oct 21 17:19:02 are you in a hurry? Oct 21 17:19:28 Crofton|work, not a big hurry Oct 21 17:19:48 Crofton|work, just trying to figure out the best way to take advantage of the stagecoach Oct 21 17:20:18 Crofton|work, I think MPI would be a great way to take advantage of those networked processors Oct 21 17:21:16 Crofton|work, I haven't attempted building openMPI yet. I wanted to see if anyone has had success, or would recommend against it Oct 21 17:21:36 I just read the build instructions Oct 21 17:21:41 and it seems sane Oct 21 17:21:54 I think it would be an awesome thing to do with a coach Oct 21 17:22:01 ah ha! Oct 21 17:22:05 we have used one with distcc Oct 21 17:22:10 if you build coreutils-native on darwin, its echo doesn't support -n Oct 21 17:22:14 wtf? Oct 21 17:22:59 Crofton|work: great :) I will give it a shot then Oct 21 17:23:15 I'll be traveling next week and have some deadlines Oct 21 17:23:21 Crofton|work: has it been effective using the distcc?? Oct 21 17:23:26 otherwise I would try to remember how far I got Oct 21 17:23:28 yeah Oct 21 17:24:34 Crofton|work: good to hear! don't spend too much time on it. I will have the chance to investigate Oct 21 17:24:44 cool Oct 21 17:24:51 ping me if you have questions Oct 21 17:24:53 Crofton|work: I'll let you know if I get stuck, or make progress Oct 21 17:25:05 Crofton|work: thanks! Oct 21 17:27:47 coreutils-native built outside of oe produces a working echo Oct 21 17:27:49 weird. Oct 21 17:50:54 with libtool 2.4 and sysroot support turned on, if i look in tmp/sysroots/blah/blah/bin/blah-libtool, should i see lt_sysroot=? Oct 21 17:50:55 stefan_schmidt: hi Oct 21 17:50:57 mine is blank Oct 21 17:51:13 hi zecke Oct 21 17:51:16 zecke: how are you? Oct 21 17:54:29 I'm back. If I have bitbake file http://pastebin.com/xadxL5am and in my SVN is a test.png which I want to install where my program can then access it when it runs. What's the normal method for doing that. It puts the executable in /usr/bin. I need a hint. Oct 21 17:55:59 maybe install it to ${sharedir}/${PN}/test.png? Oct 21 17:56:25 The libtool built by libtool-native has a non-empty lt_sysroot, but the libtool built by libtool-cross has an empty lt_sysroot. Oct 21 17:56:29 does that make sense? Oct 21 17:58:26 mzs: I think I know those libxcb.la errors are you using libtool 2.5 Oct 21 17:58:32 err 2.4 Imean Oct 21 17:58:40 Yeah. Oct 21 17:59:04 it has dependency_libs="... /lib/libpthread.la", which i think is normal, since libtool is supposed to prepend the sysroot, right? Oct 21 17:59:15 but lt_sysroot='' in the libtool script Oct 21 17:59:25 does it have =/lib/libpthread.la Oct 21 17:59:31 no. no '=' Oct 21 17:59:35 ok Oct 21 17:59:43 then it wont do it Oct 21 17:59:56 won't prepend sysroot? Oct 21 18:00:00 yep Oct 21 18:00:21 Probably libxcb was built by the libtool script that has lt_sysroot='', so it didn't put the '=' in? Oct 21 18:00:22 mzs: are libtool macros for this package regenerated Oct 21 18:00:27 if not you might want to do that Oct 21 18:00:44 for libx11 (the package using libxcb)? or for libxcb? Oct 21 18:00:47 or for libtool itself? Oct 21 18:00:59 yes libxcb should regenerate its configure with new macros from libtool 2.4 Oct 21 18:01:22 here I gave you the gem :) now go figure out how to do it for libxcb Oct 21 18:01:43 should my libtool-cross script have an empty lt_sysroot though? Oct 21 18:14:47 khem: looks like libxcb is already getting its macros regenerated Oct 21 18:16:04 mzs, but how would my C++ program know where ${sharedir}/${PN} is? I don't want to hardcode it probably. Right now when I'm testing on my host I have "test.png" since it's in the same directory as my executable, but that's not the case when it's installed. I wonder if there's a way to still use "test.png" but have it look in like /etc/${PN}/ Oct 21 18:17:45 foobaz: you could pass a precompiler flag when you build your executable Oct 21 18:18:01 -DDATADIR=${datadir}/${PN} Oct 21 18:18:13 or ${sysconfdir} if you want /etc Oct 21 18:20:37 mzs: look at the generated ${TARGET_ARCH}libtool script does it have lt_sysroot Oct 21 18:20:46 it has lt_sysroot='' Oct 21 18:20:52 thats wrong Oct 21 18:20:53 looking in the config log for libtool-cross it has: Oct 21 18:21:01 configure:6775: checking for sysroot Oct 21 18:21:01 configure:6805: result: no Oct 21 18:21:11 huuh Oct 21 18:21:14 but --with-sysroot is being passed to its configure Oct 21 18:21:42 ok are there more sysroot strings Oct 21 18:21:46 it should autodetect it Oct 21 18:21:53 meanwhile libtool-native: Oct 21 18:21:53 configure:6775: checking for sysroot Oct 21 18:21:53 configure:6805: result: /home/michael/git/newstix/tmp/sysroots/x86_64-linux Oct 21 18:22:05 libtool-cross configure is called with --with-sysroot by itself Oct 21 18:22:19 libtool-native configure is called with --with-sysroot and --with-sysroot=/ Oct 21 18:22:29 mzs: ok Oct 21 18:23:01 hi jeremy_laine_ Oct 21 18:23:10 long time away from OE Oct 21 18:23:25 I pissed him off Oct 21 18:23:30 ha Oct 21 18:23:45 mzs: and its 2.4 for libtool-cross Oct 21 18:23:53 yep 2.4-r26.1 Oct 21 18:23:59 khem: think about the karma.. Oct 21 18:24:03 kharma... hmm Oct 21 18:25:09 zecke: I grew up 7 km from where Dalai Lama lives :) Oct 21 18:25:20 so it was tought to me in school every freaking day Oct 21 18:25:52 mzs: for me checking for sysroot... /scratch/oe/sysroots/armv7a-oe-linux-gnueabi Oct 21 18:26:14 mzs: pastebin your log.do_configure and run.do_configure Oct 21 18:26:17 khem: wow Oct 21 18:26:48 khem: http://pastebin.ca/1969240 line 501 is the call to configure for my libtool-cross Oct 21 18:27:02 in your libtool-cross, is it called with --with-sysroot= or just --with-sysroot? Oct 21 18:27:40 Ah. what version of gcc added sysroot support? Oct 21 18:27:54 would it be, say, something after 4.3.3? :) Oct 21 18:29:31 mzs: its possible but your libtool is at 2.4-r26.1 and mine is 2.4-r26.2 Oct 21 18:29:34 i486-oe-linux-gcc: not configured with sysroot headers suffix Oct 21 18:29:37 you might want to update Oct 21 18:30:29 khem: have you pushed that yet? Oct 21 18:31:08 hmmm not yet ups Oct 21 18:31:57 mine has no --with-sysroot= Oct 21 18:32:02 only --with-sysroot Oct 21 18:32:27 the problem seems to be with how my gcc was built, it says "not configured with sysroot headers suffix" when i call it with --print-sysroot Oct 21 18:32:34 mzs: difference is I never did x86 build Oct 21 18:32:50 mzs: which gcc ? Oct 21 18:32:55 cross ? Oct 21 18:33:10 I think so.. Oct 21 18:33:42 ok where is your log.do_configure Oct 21 18:33:58 for gcc-cross? pulling it up Oct 21 18:34:53 no for libtoo-cross Oct 21 18:36:01 khem: http://pastebin.ca/1969245 Oct 21 18:38:54 weird. my gcc-cross config.log definitely shows --with-build-sysroot=... but the i486-oe-linux-gcc it produced says "not configured with sysroot headers suffix" Oct 21 18:42:52 mzs: strange in your case it does not detect sysroot Oct 21 18:47:25 khem: could you please run: --help | grep print-sysroot Oct 21 18:47:43 for gcc 4.3.3 it only turns up -print-sysroot-headers-suffix, which i guess might not be quite the feature we need Oct 21 18:48:04 but all this gcc sysroot support looks fairly old, so i'm not positive 4.3.3 doesn't have the right stuff Oct 21 18:50:32 Yeah, OK. -print-sysroot was added in gcc 4.4.x Oct 21 18:52:04 the old way was to call gcc -print-file-name=libc.a and strip off ${prefix}/libc.a Oct 21 18:52:06 ugh Oct 21 18:52:47 back to libtool 2.2.6b :/ Oct 21 18:53:43 or 2.4 without sysroot support, i suppose Oct 21 18:53:53 wait Oct 21 18:57:17 i suppose i could backport -print-sysroot to 4.3.3 Oct 21 19:27:16 mzs: it could be something specific to x86 Oct 21 19:27:23 * khem was on a call Oct 21 19:29:27 khem: any hint on failing target binutils build? Oct 21 19:30:57 JaMa: I have not encountered that yet, are you on 2.20.1 Oct 21 19:31:16 yes Oct 21 19:31:38 and libtool 2.4 Oct 21 19:31:51 yes Oct 21 19:32:05 Does it work ok with old libtool Oct 21 19:32:42 it worked even with new libtool before http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=f1148d26740e57cba4fe29fd78c234359868a50e Oct 21 19:32:47 mzs: whats your machine ? Oct 21 19:33:03 mzs: I can try to build for qemux86 and see if I can get same problem as you Oct 21 19:33:07 re Oct 21 19:34:43 JaMa: ah I see the problem Oct 21 19:34:58 JaMa: now libtool does not get sysroot from configure so it barfs Oct 21 19:35:00 man Oct 21 19:35:17 I have open pandora of worms Oct 21 19:35:36 heh Oct 21 19:35:45 khem: I think my problem is caused by using old gcc 4.3.3 Oct 21 19:36:01 it doesn't have -print-sysroot so libtool-cross's autodetection fails Oct 21 19:36:05 so I guess for target binutils we still need with-sysroot Oct 21 19:36:11 mzs: ah I see Oct 21 19:36:20 this echo problem is the weirdest fucking thing Oct 21 19:36:20 hrm Oct 21 19:36:40 khem: so that patch was usefull only for old libtool? Oct 21 19:36:42 mzs: I can force the sysroot for libtool-cross so it does not have to detect it Oct 21 19:36:44 'echo -n foo' works from outside of oe, even running the *same echo binary* Oct 21 19:36:56 but if i do it from do_compile() in this recipe, it prints '-n foo' Oct 21 19:37:21 mzs: that might help, although i think other packages might also use -print-sysroot sometimes Oct 21 19:37:24 e.g. binutils Oct 21 19:37:53 kergoth: echo $SHELL in a terminal and echo $SHELL in do_compile(), make sure they're the same Oct 21 19:38:14 they are, both are /bin/bash Oct 21 19:38:18 fucking weird Oct 21 19:38:51 hrm Oct 21 19:39:01 JaMa: the problem is if I use with-sysroot then it will encode that into the linker so it has to be / becasue thats what it should be Oct 21 19:39:05 to get it to work on target Oct 21 19:39:24 * kergoth really doesn't envy khem the toolchain and libtool madness Oct 21 19:39:35 but it would fail for libtool Oct 21 19:39:51 because it wont point to target sysroot Oct 21 19:40:07 i see :/ Oct 21 19:40:11 now I see the value of workarounds Oct 21 19:40:21 lets cook up one for this case Oct 21 19:42:21 when checking poky repo it was nice to see that it has only 2 versions of gcc and one binutils, I guess much better test coverage then our plenty of options.. Oct 21 19:43:49 one fine day I will nuke all Oct 21 19:43:59 below 2.18 Oct 21 19:44:08 and gcc below 4.3 Oct 21 19:44:22 *g* Oct 21 19:44:26 ifact may be nuke even 4.3 Oct 21 19:44:35 just leave 4.5 4.4 and 4.2.1 Oct 21 19:44:43 poky has 4.5 and 4.3.3 iirc Oct 21 19:44:45 4.2.1 for people who still want GPLv2 Oct 21 19:44:59 and samewar gdb 6.8 and binutils 2.18 Oct 21 19:45:22 JaMa: clearly they dont care about gplv2 which is good Oct 21 19:46:22 btw folks please look into patchwork and update the patch status Oct 21 19:46:32 if its applied then mark it so Oct 21 19:46:52 I should send an appeal to ml Oct 21 19:47:16 JaMa: we have a libtool 2.4 patch for binutils right Oct 21 19:48:45 ? Oct 21 19:51:06 * khem 's stomach is growling Oct 21 19:51:11 oh SIGFOOD Oct 21 19:51:21 * mario-goulart 's too Oct 21 19:51:59 * JaMa eating cookies Oct 21 19:52:07 infact libtool's with-sysroot option should be called -with-build-sysroot right now it conflicts with toolchains options Oct 21 19:52:57 let me ask it on libtool ml Oct 21 19:53:02 or suggest Oct 21 19:53:11 but first thing first Oct 21 19:53:13 food... Oct 21 19:54:07 mzs: I think specifying hardcoding -with-sysroot= in libtool will solve your problem Oct 21 19:54:12 so let me do that Oct 21 19:54:13 okay, this darwin failure is fucking weird. Oct 21 19:54:31 apparently on osx, running bash in posix mode results in the 'echo' builtin not supporting -n Oct 21 19:54:52 but that's not the case in linux Oct 21 19:54:55 breaks the gmp-native build Oct 21 20:01:55 kergoth: crazy, there doesn't seem to be anything in the manpage about that even Oct 21 20:02:30 new info: it doesn't do it at an interactive shell, or in a /bin/sh interactive shell, or a separate shel script using #!/bin/sh Oct 21 20:02:31 only in OE Oct 21 20:02:37 yet, if i disable posix mode from inside of oe Oct 21 20:02:39 it works. Oct 21 20:02:48 so it something with the shell, posix mode + ... something Oct 21 20:03:17 * kergoth can't seem to make it break.. wtf Oct 21 20:03:36 its definitely bash, if i force it to use the coreutils echo it works flawlessly regardless Oct 21 20:07:39 okay! Oct 21 20:07:54 ericben: ping Oct 21 20:08:01 for some reason, the shell spawned by OE has xpg_echo turned on, which expands echo by default, and appears to make -n not change its behavior Oct 21 20:08:15 now.. why.. Oct 21 20:09:05 shopt -s xpg_echo Oct 21 20:09:14 is here Sean Cross? Oct 21 20:10:01 kergoth: Oct 21 20:10:16 khem: i know how to turn it on.. i'm saying *its already on* in do_compile in gmp Oct 21 20:10:16 --enable-xpg-echo-default Oct 21 20:10:49 not talking about the target, i'm talking about inside a shell script emitted and run by oe Oct 21 20:10:50 kergoth: I meant to hint to see if its turned on/off somehow in oe Oct 21 20:10:56 ah, yes Oct 21 20:11:13 bash might be compiled differently Oct 21 20:11:30 now we need bash-native Oct 21 20:11:38 git grep in oe doesn't show it Oct 21 20:11:49 khem: but get this -- a test script with #!/bin/sh -e, just like th eoe one, doesn't show it on Oct 21 20:11:53 run outside of oe Oct 21 20:12:09 okay, more than that Oct 21 20:12:23 if i run the *emitted run. script* outside of oe, it doesn't have xpg_echo on Oct 21 20:12:28 its only when run from oe Oct 21 20:12:31 * kergoth boggles Oct 21 20:12:44 maybe its an environment variable Oct 21 20:12:45 hmm something in /etc/profile Oct 21 20:12:48 oe strips it Oct 21 20:13:29 ah ha! Oct 21 20:13:31 that was it Oct 21 20:13:39 if i run my test script with env -i, it has xpg_echo on Oct 21 20:13:50 so its something in the environment of the login shell, an env var, which makes it stay off Oct 21 20:13:54 yet it defaults to on otherwise Oct 21 20:13:57 * kergoth stabs osx Oct 21 20:15:07 :D Oct 21 20:17:14 found it! Oct 21 20:17:25 if you set COMMAND_MODE=legacy in the environment, the shell disables xpg_echo Oct 21 20:17:38 yikes. Oct 21 20:25:03 unbelieveable. Oct 21 20:25:06 bite me, apple Oct 21 20:25:43 heh... Oct 21 20:25:46 jo Oct 21 20:25:47 hi Oct 21 20:25:54 morning Oct 21 20:26:02 hm its dark here Oct 21 20:26:06 with full moon Oct 21 20:26:13 seeker:openembedded kergoth$ env -i /bin/bash -c "shopt|grep xpg_echo" Oct 21 20:26:14 xpg_echo off Oct 21 20:26:14 seeker:openembedded kergoth$ env -i /bin/sh -c "shopt|grep xpg_echo" Oct 21 20:26:14 xpg_echo on Oct 21 20:26:21 heh Oct 21 20:26:29 lame Oct 21 20:26:32 shopt? Oct 21 20:26:34 * kergoth exports COMMAND_MODE in the i386-darwin config file in oe Oct 21 20:26:35 hm Oct 21 20:26:48 kergoth: can we just make oe always call /bin/bash? Oct 21 20:26:53 what threw me was that the behavior was retained as long as the env was, because its controlled by environment variable. Oct 21 20:26:56 "bash is the only supported shell" :) Oct 21 20:26:59 Crofton|work: another error :-\. now trying to build glib Oct 21 20:27:10 and because i wasn't doign an env -i in my test script, it was retaining my interactive mode shell's behavior in that regard Oct 21 20:27:36 fidencio_, pastebin Oct 21 20:28:24 * kergoth tries building gmp-native again Oct 21 20:31:16 Crofton|work: http://pastebin.com/9EWSVAs0 Oct 21 20:31:55 khem: autotools.bbclass is only passing --with-sysroot, so i think that means all configure scripts are going to use sysroot autodetectio Oct 21 20:32:15 so i should still backport -print-sysroot to gcc 4.3.3/4.3.4 Oct 21 20:32:30 or we should pass sysroot explicitly everywhere Oct 21 20:33:06 where is LD_LIBRARY_PATH coming from? Oct 21 20:34:00 mzs: yes Oct 21 20:34:49 mzs: the reason was sysroot might differ for native and target recipe Oct 21 20:35:00 so let detection take care of it Oct 21 20:35:07 but that could be changed as well Oct 21 20:35:14 Crofton|work: I'll confirm. 1 minute Oct 21 20:36:51 Crofton|work: LD_LIBRARY_PATH isn't set by myself Oct 21 20:38:17 hm Oct 21 20:39:50 Crofton|work: and the LD_LIBRARI_PATH of my system not include anything Oct 21 20:41:19 weird Oct 21 20:41:39 khem, you might want to look at that pastebin Oct 21 20:44:36 Crofton: I did Oct 21 20:44:42 doesnt ring any bells Oct 21 20:44:54 fidencio_: whats your distro Oct 21 20:45:04 and machine Oct 21 20:45:19 werder Oct 21 20:47:46 tinderbox shows that 2.9 builds ok for people Oct 21 20:47:51 khem: ubuntu, babbage Oct 21 20:47:58 fidencio_: I mean OE Oct 21 20:48:10 i.e. target distro and machine Oct 21 20:48:21 angstrom-2008-1 Oct 21 20:48:33 2008.1 Oct 21 20:48:34 fidencio_: ok, is it some regression ? Oct 21 20:48:43 or you are building for fisrt time Oct 21 20:48:51 question about runlevels/shutdown/reboot with angstrom... let's say I want to toggle some fields in sysfs just about exactly when rhe halt/reboot/shutdown commands are called... Oct 21 20:48:52 Yeap. 3 days ago I was buinding Oct 21 20:49:07 khem: I need go. But I'm back in 20 minutes Oct 21 20:49:14 I have some scripts in /etc/rc6.d/S01myscript, but it takes like 10s before it gets to it Oct 21 20:49:28 jconnolly: raise there priority Oct 21 20:49:45 khem: S01=>S99 ? Oct 21 20:50:09 i always think of init/rc scripts as boot, but forget about shutdown Oct 21 20:52:54 jconnolly: no S01 will execute before S02 Oct 21 20:53:31 so you have it right Oct 21 20:53:55 hmm thought so. not sure if K is executed before S scripts on shutdown though. I'll experiment a bit Oct 21 20:54:24 huh do u want these scripts to run at shutdown time ? Oct 21 20:54:34 then name them starting K no Oct 21 20:54:39 *sigh* Oct 21 20:54:43 systemd!!!!!!!!!!! Oct 21 20:55:40 jconnolly: K will be executed first Oct 21 20:55:53 ah indeed Oct 21 20:55:57 slightly more responsive Oct 21 20:55:59 thanks khem Oct 21 20:56:09 np Oct 21 21:01:30 calling it a day ... Oct 21 21:01:54 nite effem Oct 21 21:02:13 khem do you find some spare time to update chromuim? Oct 21 21:02:29 woglinde: hmmm the 25th hour Oct 21 21:02:59 *sigh* Oct 21 21:03:10 woglinde: will look into it on weekend if I can Oct 21 21:03:26 right now dealing with libtool 2.4 a bit Oct 21 21:03:27 cool Oct 21 21:03:46 ugh! Oct 21 21:04:01 bitbake really needs to set env vars in the actual environment, rather than via emission into the shell script Oct 21 21:04:15 COMMAND_MODE is set *after* the shell is spawned, which is too late to govern its shell options Oct 21 21:04:24 :| Oct 21 21:04:31 oh no Oct 21 21:04:37 the even forked libxml Oct 21 21:04:38 One nice thing about having the env vars in the script is i can just comment out the bottom line, source it, and then run make or whatever Oct 21 21:04:40 *sigh* Oct 21 21:04:46 kergoth: hmmm I think it will make the shell scripts more subtle Oct 21 21:04:48 * kergoth hacks it by prepending an shopt to configure/compile Oct 21 21:05:08 I like the fact that complete env is in the script Oct 21 21:05:09 kergoth: what if you just hardcode oe to call /bin/bash instead of /bin/sh? Oct 21 21:05:11 mzs: true, but there's always devshell Oct 21 21:05:13 03Martin Jansa  07master * rd6fcdc05b0 10openembedded.git/recipes/diffstat/diffstat_1.47.bb: diffstat: fix PR Oct 21 21:05:17 mzs: that isn't in OE. Oct 21 21:05:26 its bitbake, which means all the compatibility issues that come along with that Oct 21 21:05:32 OE doesn't even require 1.10.x yet Oct 21 21:05:51 maybe OE on Mac could :) Oct 21 21:06:06 kergoth: whats stopping us retiring 1.8 Oct 21 21:06:24 yeah 1.10 is like 3X faster! Oct 21 21:06:26 i'd like there to be a way to inject shell that's outside of a function, run before the task is, for this Oct 21 21:06:31 there's no "anonymous shell" Oct 21 21:06:32 hehe Oct 21 21:06:34 I would even retire 1.10 and just use master Oct 21 21:06:51 khem: nothing as far as i know, i think we should do it, but probably a TSC or even OEDEM decision Oct 21 21:07:02 i'd vote for tsc, i don't think there's that much to debate about it, personally Oct 21 21:07:03 too much to decide Oct 21 21:07:06 if 1.10 has bugs, we'll fix them Oct 21 21:07:09 btw with 1.10 I get list of failed recipes in the end, this doesn't work in master or shouldn't work there? Oct 21 21:07:35 why not in master ? Oct 21 21:07:40 with 1.10 I get it repeated 3 times actually, but still better than nothing.. Oct 21 21:07:41 thats a bug in master I would say Oct 21 21:07:47 JaMa: likely a bug, i've noticed the Tasks Summary display also doesn't show when a failure occurs, i think in 1.10 and master actually Oct 21 21:07:55 richard's runqueue changes changed that Oct 21 21:07:58 the summary, i mean Oct 21 21:08:15 the other bit could have been the excpetion handling changes, or the logging change Oct 21 21:08:19 will look into it Oct 21 21:08:58 hmm, the list of failed recipes might have been inadvertantly removed as a part of my attempts to reduce the amount of crap the user sees Oct 21 21:09:05 i got sick of seeing that this task failed like 12 times Oct 21 21:09:09 i saw the first one, shut up already Oct 21 21:09:31 yup that worked also in master after 1.10.. Oct 21 21:10:36 whew, hacking the shopt into configure/compile fixed the build of gmp-native ... next Oct 21 21:14:36 JaMa: found it. Oct 21 21:15:25 JaMa: if you have a git copy of bitbake, do git show 06b742aae2b8013cbb269cc30554cff89e3a5667 -- lib/bb/cooker.py Oct 21 21:15:33 that's the change that dropped what you want to see, i think Oct 21 21:15:49 my fault, we can resurrect it Oct 21 21:16:26 kergoth: I also liked the list of failed recipes Oct 21 21:17:15 ERROR: Fetch failed: Unable to fetch URL git://git.chromium.org/cros.git;protocol=git;rev=07f1fc0ce7a4bbd57f6b057435ad86f0a98e073d from any source. Oct 21 21:17:42 kergoth: well I've downgraded to 1.10 just because of this issue, so would be great if you can resurrect it Oct 21 21:18:48 hm Oct 21 21:18:50 urgs Oct 21 21:18:52 git.chromium.org[0: 74.125.248.73]: errno=Connection refused Oct 21 21:19:08 03Chris Larson  07master * r850d6158ea 10bitbake.git/lib/bb/cooker.py: Oct 21 21:19:08 Resurrect display of failed files Oct 21 21:19:08 This was inadvertantly removed when trying to reduce the amount of duplicated Oct 21 21:19:08 information the user sees when a failure occurs. Oct 21 21:19:08 Signed-off-by: Chris Larson Oct 21 21:19:17 JaMa: try that, if you would Oct 21 21:19:41 ah bitbake commits are also caught bu CIA now Oct 21 21:19:42 cool Oct 21 21:21:03 khem the webinterface works for cros Oct 21 21:21:09 why the git protocol not Oct 21 21:21:24 kergoth: will try as soon as some recipe fails for me, thanks Oct 21 21:26:27 woglinde: hmm try http Oct 21 21:26:42 03Eric BENARD  07master * r75ea005ac8 10bitbake.git/lib/bb/fetch/hg.py: (log message trimmed) Oct 21 21:26:43 bitbake: lib/bb/fetch/hg: fix fetching from a mercurial repository Oct 21 21:26:43 * without this fix, we get : Oct 21 21:26:43 updating working directory Oct 21 21:26:43 74 files updated, 0 files merged, 0 files removed, 0 files unresolved Oct 21 21:26:43 abort: There is no Mercurial repository here (.hg not found)! Oct 21 21:26:43 Signed-off-by: Eric Bénard Oct 21 21:27:13 cool Oct 21 21:27:22 this bug fixed Oct 21 21:28:26 nite jama Oct 21 21:31:01 woglinde: git clone http://git.chromium.org/git/cros.git Oct 21 21:32:28 I wonder why git protocol is blocked Oct 21 21:32:37 hm Oct 21 21:32:41 tryoing src. now Oct 21 21:32:57 the command I gave you should owrk Oct 21 21:32:59 hm same Oct 21 21:34:05 khem: so sorry. if I can't get a ride I was fucked losing 1 or 2 hours in a bus Oct 21 21:34:37 woglinde: http://pastebin.com/n3hkSe4J Oct 21 21:35:07 fidencio_: so are you fucked now ? Oct 21 21:35:27 khem: Nops. I get the ride. Oct 21 21:35:52 args Oct 21 21:36:14 bitbake tried rsync Oct 21 21:36:28 khem: so, I'll compare the glibc recipe with the last version that compile ... Oct 21 21:36:40 Just to be sure that it's a regression Oct 21 21:37:30 fidencio_: yeah I wonder why it wont compile Oct 21 21:37:32 now Oct 21 21:37:42 those errors dont make sense to me Oct 21 21:38:38 hm one checksum changed Oct 21 21:38:45 but that I can fix myself Oct 21 21:40:34 good Oct 21 21:40:37 khem: the latest buildable version was the version with INC_PR="r36" Oct 21 21:40:53 fidencio_: ok Oct 21 21:42:39 * kergoth mulls over possible shared unpack caching with git Oct 21 21:44:28 fidencio_: do u have the source snapshot where it built Oct 21 21:44:53 hmmmm Oct 21 21:44:54 khem: I think so Oct 21 21:45:06 fidencio_: ok then cd into recipes/glibc Oct 21 21:45:11 and git log Oct 21 21:45:16 this would be cool if i got it to work Oct 21 21:45:23 give me the rev of the commit on top Oct 21 21:45:36 let linux-libc-headers andt he real kernel share the same core of unpacked sources, by cloning the right position in the patch stack in the git repository for the tarball Oct 21 21:45:38 or something Oct 21 21:45:51 khem: 5b485324c Oct 21 21:46:10 Hi Oct 21 21:46:44 i'm building fluxbox to angstrom distro in a a1200 machine Oct 21 21:46:50 kergoth: yeah I have talked so many times about generating linux-libc-headers to share but if you change that then all recipes become machine specific Oct 21 21:46:52 but i get a error on do_install step Oct 21 21:46:55 http://pastebin.com/adUsJGQt Oct 21 21:47:00 what do you mean? Oct 21 21:47:02 any help? Oct 21 21:47:17 i'm just talking about the SRC_URI tarballs and patches Oct 21 21:47:53 name the repo by the tarball, apply the patches as commits in the repo, hash the tarball+patches as a tag indicating the ref to use to clone into workdir Oct 21 21:48:33 then the actual original unpacking and patching is a one time operation per tarball and patch set, and everyone clones Oct 21 21:48:36 i wonder how that would perform Oct 21 21:48:38 * kergoth ponders Oct 21 21:49:27 is a strange problem here Oct 21 21:50:25 khem: and the rev of the latest buildable in my pc 58f686523f Oct 21 21:50:58 * kergoth 'll have to try a proof of concept to see if its worth doing Oct 21 21:53:49 hmm, i could reuse the SRC_URI -> git repo code from that sort of proof of concept for other things Oct 21 21:53:53 * kergoth ponders some more Oct 21 21:54:49 hah, it worked Oct 21 21:54:54 the environment thing for darwin Oct 21 21:55:18 if isinstance(e, bb.event.ConfigParsed): Oct 21 21:55:18 os.environ["COMMAND_MODE"] = "unix2003" Oct 21 21:55:34 event handler, sets it in the env in the main server process which flows down into the workers Oct 21 21:55:37 fidencio_: git bisect it Oct 21 21:55:40 so the shells they run have it set in time Oct 21 21:55:45 such a hack Oct 21 21:55:48 fidencio_: now that you know good and bad versions Oct 21 21:59:02 fidencio_: echo $LD_LIBRARY_PATH Oct 21 21:59:10 what does that say Oct 21 22:01:32 any help here? Oct 21 22:02:21 :/home/fidencio/local/lvm/lib Oct 21 22:02:26 khem: ^ Oct 21 22:02:50 fidencio_: why why why Oct 21 22:03:01 hmmm Oct 21 22:03:12 that : could mean look in current dir Oct 21 22:03:21 can you fix that Oct 21 22:03:33 khem: why this machine isn't used only for me :-\ Oct 21 22:03:52 well. OK message is clear what glibc wants Oct 21 22:04:00 and : will force it to look into CWD Oct 21 22:04:33 fidencio_: just for experiment override that and see if that helps Oct 21 22:04:43 if it does then I would suggest to fix your system Oct 21 22:05:08 khem: ok. I'll try. many thanks Oct 21 22:05:43 fidencio_: ok let me know how it goes Oct 21 22:06:13 angelox_123: let me see Oct 21 22:06:38 ok Oct 21 22:07:50 angelox_123: go into your workdir for fluxbox Oct 21 22:08:39 angelox_123: in the sourcdir grep for fbrun.1 Oct 21 22:09:18 source dir Oct 21 22:09:33 where have ./configure blablabla? Oct 21 22:09:58 yes Oct 21 22:10:09 i do: Oct 21 22:10:14 find . | grep fbrun.1 ? Oct 21 22:10:29 yeah or grep -r "fbrun.1" Oct 21 22:10:37 dont need find Oct 21 22:10:57 have a file: Oct 21 22:10:59 ./doc/fbrun.1 Oct 21 22:11:23 remove it? Oct 21 22:11:31 no Oct 21 22:11:41 what i do? Oct 21 22:11:43 I said grep for string fbrun.1 not file Oct 21 22:11:58 some Makefile.am should contain this string Oct 21 22:12:08 ah sorry Oct 21 22:12:15 khem: same error. ok. I'll bisect ... Oct 21 22:12:19 grep'ing :D Oct 21 22:13:37 fidencio_: you need to clean the build Oct 21 22:13:55 fidencio_: after clearing LD_LIBRARY_PATH do Oct 21 22:14:25 bitbake -c clean glibc glibc-initial gcc-cross gcc-cross-intermediate gcc-cross Oct 21 22:14:33 then bitbake glibc Oct 21 22:14:50 and make sure that LD_LIBRARY_PATH is unset Oct 21 22:16:20 kergoth: I am thinking of renaming libtool's with-sysroot to something else Oct 21 22:16:43 kergoth: may be with-libtool-sysroot or with-build-sysroot something like that Oct 21 22:16:57 kergoth: I have mailed to libtool ml Oct 21 22:17:02 also explaining the issue Oct 21 22:17:07 that would be a very good idea, avoid namespace collisions Oct 21 22:17:09 I think they did not think about it Oct 21 22:17:15 * kergoth nods Oct 21 22:17:26 but I also doubt they will change it Oct 21 22:17:31 they might smear another one on top Oct 21 22:17:37 can patch it that way locally for now, no big deal Oct 21 22:17:40 but let me change what the hack Oct 21 22:17:47 * kergoth nods Oct 21 22:17:53 too slow to grep Oct 21 22:18:15 I will make it with-libtool-sysroot Oct 21 22:18:20 to make it explicit Oct 21 22:18:49 then we dont need those oe_filter_outs Oct 21 22:18:59 nice Oct 21 22:19:04 and denix0 will be happy Oct 21 22:19:39 hmm but I have to regenerate those libtool 2.4 patches Oct 21 22:19:46 I guess there are only couple of recipes Oct 21 22:19:49 not big deal Oct 21 22:20:34 angelox_123: it should not be that slow unless you are doing it on HP calculator or PDP-1 Oct 21 22:20:40 i'd really like to experiment with our recipe sources maintained in a git repository, no local extra files in the oe tree at all Oct 21 22:20:47 just a recipe pointing at a git repo on oe.org Oct 21 22:21:14 kergoth: you mean all patches etc are stored elsewhere ? Oct 21 22:21:19 potentially, if we use git-submodule in the future, could have it pulled down into the oe tree ahead of time Oct 21 22:21:27 i mean a git repo with our patchsets maintained as branches Oct 21 22:21:35 no separate stuff at all Oct 21 22:21:40 hm Oct 21 22:21:45 nice idea Oct 21 22:21:53 other distros have played with it for that Oct 21 22:21:56 e.g. git.debian.org Oct 21 22:22:03 the vcs-pkg effort is in that direction Oct 21 22:22:35 except for us we'd likely want to keep the recipe itself out of the tree, just to avoid pain dealing with recipe changes for multiple versions Oct 21 22:22:48 *g* Oct 21 22:22:53 otherwise you'd have to cherry pick a common change to all the version branches or something, unless we used a separate repo for each version Oct 21 22:22:56 kergoth: hmm you mean no tars Oct 21 22:22:57 but that sounds like more trouble than its worth Oct 21 22:23:00 khem: yep Oct 21 22:23:10 he I wouldnt see the shitty recipes anymore Oct 21 22:23:16 kergoth: huge space requirements Oct 21 22:23:19 like an srctree build of sorts Oct 21 22:23:21 khem: how so? Oct 21 22:23:30 kergoth: right now we suck in from web Oct 21 22:23:32 we have to fetch it down anyway, a git repo isn't likely to be *that* much bigger Oct 21 22:23:41 chromium recipe is shitty too Oct 21 22:23:43 *g* Oct 21 22:23:45 kergoth I mean from scm pov Oct 21 22:23:54 not seeing what you mean Oct 21 22:24:07 kergoth: right now we dont store tars in our SCM Oct 21 22:24:13 and we wouldn't Oct 21 22:24:21 i'm not talking about storing SRC_URI files directly in git Oct 21 22:24:24 i'm talking about unpacking the tarball Oct 21 22:24:27 storing those in git Oct 21 22:24:31 and applying hte patches as commits Oct 21 22:24:42 as a separate git repo per recipe's sources Oct 21 22:24:50 e.g. git://git.openembedded.org/nano.git Oct 21 22:25:02 you could clone it down and ./configure; make; make install to test native build without oe Oct 21 22:25:17 good nite Oct 21 22:25:39 kergoth: so we are storing the nano sources isnt it Oct 21 22:25:47 yep Oct 21 22:25:47 oh I see Oct 21 22:25:53 when upstream uses git Oct 21 22:25:56 we could base ours directly on that Oct 21 22:26:08 kergoth: but then my point is valid Oct 21 22:26:10 which would make our lives easier in general, easier to track what they're up to Oct 21 22:26:28 we have to have space to store all that Oct 21 22:26:31 dood Oct 21 22:26:35 we mirror that shit *anyway* Oct 21 22:26:38 on our mirrors Oct 21 22:26:43 we'd just take that space on our git server instead Oct 21 22:26:54 hmm valid Oct 21 22:27:15 so when one git clones he clones both ? Oct 21 22:27:24 metadata and srcdata Oct 21 22:27:27 either we use submodules or someting to pre-fetch its sources into the oe tree Oct 21 22:27:34 or we just put the git url to our git tree in the recipe Oct 21 22:27:38 either way would get the job done Oct 21 22:27:57 then who updates srcdata Oct 21 22:28:11 the recipe maintainer, preferably, its not different than now Oct 21 22:28:12 right now we just fiddle with recipe change the SRC_URI Oct 21 22:28:15 and it works Oct 21 22:28:15 just branches instead of patches Oct 21 22:28:44 would be useful to have helper scripts to assist in rebasing our patchsets on new versions, what have you Oct 21 22:28:48 khem,i did: root@pynell-desktop:/home/angelo/angstrom-setup-scripts/build/tmp-angstrom-2008.1/work/armv5te-angstrom-linux-gnueabi/fluxbox-1_1.1.1-r0/fluxbox-1.1.1# grep -r "fbrun.1" but nothing shows Oct 21 22:28:50 hmm so he operates on srcdata Oct 21 22:28:56 the command is correct? Oct 21 22:29:15 i see it as easier than now in certain way, the recipe would be almost exactly the same for srctree as not Oct 21 22:29:18 s/way/ways/ Oct 21 22:29:27 kergoth: yes I am getting it Oct 21 22:29:31 not that bad actually Oct 21 22:29:36 would make it easier to just jump in and start hacking on the code Oct 21 22:29:43 or just poke around and see whats what Oct 21 22:29:46 it would get rid of checksums Oct 21 22:29:47 too Oct 21 22:29:53 potentially Oct 21 22:30:02 if we can make sure that source we keep are sane Oct 21 22:30:15 possibly -- we could think about using the srctree work + submodules to avoid sources being in tmpdir at all, too Oct 21 22:30:25 shared source trees right under oe/source/foo/ Oct 21 22:30:27 or whatever Oct 21 22:30:33 no digging 40 dirs deep Oct 21 22:30:35 yeah scm recipes dont use checksums Oct 21 22:30:38 khem? Oct 21 22:30:54 angelox_123: grep -r "fbrun\.1" Oct 21 22:31:02 angelox_123: grep -r "fbrun\.1" * Oct 21 22:31:11 that * is important Oct 21 22:31:13 ah Oct 21 22:31:16 i forget that Oct 21 22:31:17 :D Oct 21 22:31:20 oh man, if we used srctree with submodules, we could use gitver, you could just cd in, change branches, and you've changed what version you're using, no preferences to twiddle Oct 21 22:31:23 man grep Oct 21 22:31:24 the submodule could control the version Oct 21 22:31:25 * kergoth ponders Oct 21 22:31:28 I'll pastebin Oct 21 22:31:42 kergoth: I think it will be good thing Oct 21 22:31:49 Here khem: Oct 21 22:31:50 http://pastebin.com/tLa9SMBp Oct 21 22:32:18 i've been mulling over this kind of thing for a few years now, but wasnt sure about 1) the reaction to it, 2) implementation details, and 3) transition from now, and 4) tools based on it (e.g. git-submodule viability) Oct 21 22:32:21 angelox_123: can you pastebin doc/Makefile.am Oct 21 22:32:40 khem: of course,give me a second Oct 21 22:32:51 kergoth: yeah one thing I am not clear is how do we maintain non git recipes Oct 21 22:32:59 I mean srcdata Oct 21 22:33:06 do we untar it and commit it Oct 21 22:33:13 khem: it's here: http://pastebin.com/AgPDmieh Oct 21 22:33:20 one thing i was thinking about as a similar tool would be a script which parses the recipe tree and unpacks/patches them, converts to git, and pulls that into a project area, importing it there, along with its dependencies, then builds only parse what you imported, only updating upstream and importing changes from it to the project would have to parse everything Oct 21 22:33:38 khem: yeah, exactly. we could even automate it, i've bene thinkinga bout a scirpt to convert SRC_URI into a git tree Oct 21 22:33:49 kergoth: yeah that would be nice Oct 21 22:33:52 khem: or, if upstream uses a different scm, you could use git-svn or git-cvsimport as the base Oct 21 22:34:07 and prolly a script which could grok new releases Oct 21 22:34:20 yeah, for the tarball ones, that would be lovely Oct 21 22:34:35 and inform us hey you got a new release Oct 21 22:34:45 man, i was talking about release monitoring in the original brainstorming wiki page for oe Oct 21 22:34:49 we never did it :\ Oct 21 22:35:02 angelox_123: ok now you need to create a patch do you know how to do that with OE/quilt Oct 21 22:35:10 freshmeat has an API, you know, that could be fun to play with :) Oct 21 22:35:45 interesting Oct 21 22:35:46 khem: i don't understand Oct 21 22:35:53 angelox_123: well you said it Oct 21 22:36:08 anyway, i think i'll try writing a script to populate a git repo from SRC_URI, and maybe try converting autoconf/automake to git repositories with a local OE with recipes pointing at them, and see how it goes Oct 21 22:36:16 khem: i'll create a patch to remove fbrun.1 from Makefile.am ? Oct 21 22:36:50 angelox_123: yes Oct 21 22:36:59 but let me see if I have the src local Oct 21 22:37:24 khem: ok,only doc/Makefile.am or doc/Makefile too? Oct 21 22:38:05 angelox_123: I have sources local let me do it here Oct 21 22:38:09 its easy that way Oct 21 22:38:13 ok Oct 21 22:42:23 angelox_123: apply this patch to oe metadata Oct 21 22:42:25 http://pastebin.com/AUxUYhn4 Oct 21 22:42:33 then rebuild fluxbox Oct 21 22:42:44 i apply on oe tree? Oct 21 22:42:50 i don't know what is oe metadata Oct 21 22:43:02 cd openembedded/; patch -p1 < this.patch Oct 21 22:43:17 yeah oe tree Oct 21 22:44:02 ok Oct 21 22:44:03 thanks Oct 21 22:44:07 :) Very Oct 21 22:45:11 my original attempt to convert SRC_URI to git was ... ambitious Oct 21 22:45:41 i was trying to automatically create a branch for each patch, and that branch got commits for each change to that patch, and i tried to track copies/moves of the patches, and also commit history of the recipe itself Oct 21 22:45:49 my brain just about melted there Oct 21 22:45:49 kergoth: hmm Oct 21 22:45:51 hehe Oct 21 22:45:52 to rebuild i just do bitbake -c clean fluxbox && bitbake fluxbox Oct 21 22:45:52 ? Oct 21 22:46:25 angelox_123: yes Oct 21 22:46:31 what really got confusing was the changes to the recipe which changed what patches existed Oct 21 22:46:31 ok Oct 21 22:46:34 thanks Oct 21 22:46:35 SRC_URI changing over time Oct 21 22:46:48 coupled with branches per patch + inter-branch/patch dependency Oct 21 22:46:52 now i say.. fuck that Oct 21 22:46:53 * angelox_123 says thanks to khem again Oct 21 22:46:55 hehe Oct 21 22:47:05 kergoth: the recipes we have is unmanagable too Oct 21 22:47:32 kergoth: OE needs to shed some more Oct 21 22:48:02 oh, another thing i was thinking over -- BBVERSIONS used per-version or per-version-block overrides -- those might be useful for .incs even without use of BBVERSIONS, to start merging includes Oct 21 22:48:05 might not, too, not sure Oct 21 22:48:10 something to mull over Oct 21 22:48:18 e.g. FOO_1.0, FOO_1.2 Oct 21 22:48:42 we should never have allowed incs Oct 21 22:49:04 heh, in theory its nice to avoid duplication, but in reality it just makes it more confusing Oct 21 22:49:09 since now you have to chase things down Oct 21 22:49:18 well if done right Oct 21 22:49:26 and its very constrained Oct 21 22:49:42 over the period you will see that fixing such cases become a lot more complex Oct 21 22:49:46 and errorprone Oct 21 22:49:51 khem: Oct 21 22:49:53 NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance. Oct 21 22:49:53 NOTE: Handling BitBake files: - (3263/7082) [46 %]ERROR: /home/angelo/angstrom-setup-scripts/sources/openembedded/recipes/fluxbox/fluxbox_1.1.1.bb:12: unparsed line: ' "' while parsing /home/angelo/angstrom-setup-scripts/sources/openembedded/recipes/fluxbox/fluxbox_1.1.1.bb Oct 21 22:49:53 ERROR: /home/angelo/angstrom-setup-scripts/sources/openembedded/recipes/fluxbox/fluxbox_1.1.1.bb:12: unparsed line: ' "' while parsing /home/angelo/angstrom-setup-scripts/sources/openembedded/recipes/fluxbox/fluxbox_1.1.1.bb Oct 21 22:49:54 NOTE: Handling BitBake files: \ (6123/7082) [86 %] Oct 21 22:49:57 with the kind of testing we have in OE its impossible Oct 21 22:50:50 angelox_123: edit recipes/fluxbox/fluxbox_1.1.1.bb Oct 21 22:51:02 and add \ at the end of line where I added the new patch Oct 21 22:51:27 ok Oct 21 22:51:46 Which module has "string" for python in it. I can't seem to find it. Oct 21 22:52:06 i assume you mean package, not module Oct 21 22:52:09 string is a module Oct 21 22:52:16 angelox_123: like http://pastebin.com/Q5c58Acx Oct 21 22:52:19 Package, yes. Oct 21 22:52:31 check the manifest Oct 21 22:52:38 recipes/python/*manifest*.inc Oct 21 22:55:25 * RobotGuy sighs Oct 21 22:56:16 I see stringold, but I presume for now I shouldn't use that. Correct? Oct 21 22:56:19 from a quick oneline grep: FILES_python-stringold="${libdir}/python2.6/lib-dynload/strop.so ${libdir}/python2.6/string.* " Oct 21 22:56:27 not sure why you'd presume that Oct 21 22:56:47 its preferred to use the methods on strings rather than the string module, but there are still cases where the module is necessary Oct 21 22:57:03 DJango seems to be one of those cases. Oct 21 23:03:47 hmmm Oct 21 23:06:31 I'm building a dev software image for BeagleBoard Oct 21 23:18:12 angelox_123: so did it build ? Oct 21 23:18:27 compiling Oct 21 23:18:39 (slow....) \o/ Oct 21 23:19:52 khem: I think hat theglibc is compiling. I'll pay a beer for you! Oct 21 23:19:57 kergoth, the -c patch does seem to have problems on occasion. I see the same behaviour as you with regards -c clean,build but not all the time. Oct 21 23:20:07 Does bitbake do any task reordering that would cause this? Oct 21 23:20:37 fidencio_: ok Oct 21 23:21:10 hey khem Oct 21 23:21:12 worked Oct 21 23:21:13 thanks Oct 21 23:21:15 :) Oct 21 23:21:19 * angelox_123 says thanks to khem Oct 21 23:21:26 khem: many thanks! Oct 21 23:22:07 angelox_123: ok cool Oct 21 23:22:17 okay, this is weird Oct 21 23:22:23 this patch applies to mpfr-native in linux, but not in osx Oct 21 23:22:25 how willthe sdk recipes work with libtool 2.4? Oct 21 23:22:28 line endings, perhaps? Oct 21 23:22:29 hmm Oct 21 23:22:33 03Khem Raj  07master * r357d6443e3 10openembedded.git/recipes/fluxbox/ (fluxbox/remove-duplicate-fbrun.1.patch fluxbox_1.1.1.bb): Oct 21 23:22:33 fluxbox_1.1.1.bb: Delete duplicate fbrun.1 occurance from man_MANS Oct 21 23:22:33 Signed-off-by: Khem Raj Oct 21 23:23:29 the patches themselves always have unix line endings.. i don't see how the tarball could possibly do anything to them.. weird Oct 21 23:24:12 hrm Oct 21 23:40:04 kergoth: whats the error Oct 21 23:40:19 just rejects, not helpful Oct 21 23:40:36 oh Oct 21 23:41:07 * kergoth has hit the weirdest errors working on this Oct 21 23:41:27 kergoth: can you patch it manually Oct 21 23:41:29 without quilt Oct 21 23:41:38 i tried PATCHTOOL = "patch", still fails Oct 21 23:41:42 haven't tried outside of oe yet Oct 21 23:45:12 kergoth, I had problems with the patch from macports before. Oct 22 00:29:07 ka6sox-work: not using patch from macports, using the one which was already installed in /usr/bin/ Oct 22 00:29:30 oh...thats the one I usually use too. Oct 22 00:39:23 i'm wondering if POSIXLY_CORRECT is affecting it Oct 22 00:39:28 (being set, or not) Oct 22 01:08:57 oh, crap, haha Oct 22 01:09:09 this is just a patch that quilt manages to apply, but pure patch fails Oct 22 01:09:10 wonder why Oct 22 01:13:36 hi i'm trying to build opie-image for poodle/angstrom, keeps failing on opie-notes_cvs.bb Oct 22 01:13:45 any suggestion for how to fix this? Oct 22 01:15:27 git read-tree 1 failed with signal 128, output: Oct 22 01:15:27 fatal: Not a valid object name 1 Oct 22 01:16:15 i'm able to manually git clone git://gitorious.org/opie/opie, so not sure what the deal is Oct 22 01:45:12 CrazyFoam: missing SRCREV int he recipe Oct 22 01:46:42 oh damn! Oct 22 01:46:48 this patch says it wont apply with -R Oct 22 01:46:54 er, with --dry-run Oct 22 01:46:55 but *does* apply Oct 22 01:46:58 hah Oct 22 01:51:41 kergoth, thanks, guess i could try the most recent commit: SRCREV="12722637addc74dc6df1ef1913058a71987b9f7d" Oct 22 01:52:07 but doesn't make sense because a ton of other opie packages were built and didn't use git Oct 22 01:53:30 well, something is using git and doesn't have SRCREV set. Oct 22 01:54:50 hmmm, how can i coerce it to use opie.core.pim.notes_anoncvs.handhelds.org_v1_2_4_.tar.gz? Oct 22 01:59:32 hmmm maybe adding a line like PREFERRED_VERSION_opie-notes = "${OPIE_VERSION}" to conf/distro/include/preferred-opie-versions-1.2.4.inc Oct 22 02:04:31 ha! that worked Oct 22 02:06:42 so it seems there is a bug/missing line in conf/distro/include/preferred-opie-versions-1.2.4.inc Oct 22 02:25:49 damnit damnit damnit Oct 22 02:26:03 i swear to god i had this fixed, and i haven't removed the fix, and now its broken again Oct 22 02:26:29 i thought i was past this and on to other bugs Oct 22 02:26:30 * kergoth grumbles Oct 22 02:28:55 * kergoth sighs **** ENDING LOGGING AT Fri Oct 22 02:59:58 2010