**** BEGIN LOGGING AT Mon Oct 11 02:59:57 2010 Oct 11 06:19:12 I have a question about the initramfs-image recipe, anyone willing to help? Oct 11 06:19:24 gm Oct 11 06:21:12 I have a question about the initramfs-image recipe, anyone willing to help? Oct 11 06:22:41 After build, the $BOOT_ROOT is not set, am I missing something? Oct 11 06:23:13 mfkh, no idea what BOOT_ROOT does or why you'd need it Oct 11 06:23:50 and generally speaking this is the quiet time here, US people are gone to sleep, EU people will start to to appear Oct 11 06:24:25 The /init script is called when booting into the initramfs Oct 11 06:25:12 The boot_root function uses the $BOOT_ROOT variable. Oct 11 06:26:54 maybe it is missing and need to be added; i don't normally build initramfs images Oct 11 06:27:50 I see. Thanks effeM. Oct 11 06:29:52 BTW, effeM, could you tell me what board are you working on or have worked on. I am planning to buy one. Oct 11 06:30:54 I want to use it to study Qtopia or GTK+. Oct 11 06:32:29 beagleboard/hawkboard/sheevaplug/openrd-client/calamari/neek (and in the ancient past NSLU2) Oct 11 06:33:40 Is beagleboard VERY well supported by OE? Oct 11 06:33:45 yes Oct 11 06:34:03 it is probably the most widely used board atm Oct 11 06:34:13 you might want to get a beagleboard XM Oct 11 06:34:17 or wait for pandaboard Oct 11 06:34:58 koen didn't get his PB yet, so not much support there I guess ;) Oct 11 06:35:06 Yes, I have check that model, but it is not available in my region by Digikey. :( Oct 11 06:35:19 mfhk: it's not available at all Oct 11 06:35:26 it will be soonâ„¢ Oct 11 06:35:46 that is why I said 'wait for" Oct 11 06:36:05 first five are supposed to be shipped to early adopters this week Oct 11 06:36:27 * dm8tbr has slight hopes that his proposal might have been interesting enough Oct 11 06:36:39 but probably if then only for the second 10 or so Oct 11 06:37:01 You mean pandaboard compatible with beagleboard? Oct 11 06:37:14 no panda is omap4, full HD etc Oct 11 06:37:16 www.pandaboard.org Oct 11 06:37:32 thanks, let me see... Oct 11 06:37:56 dm8tbr: there are many entries, but lots of them are in my opinion not realistic or not exciting and not panda specific Oct 11 06:38:24 eFfeM_work: yes, things like 'port android 2.2' are underwhelming, TI is doing that already Oct 11 06:39:04 but I think top100fps made an XBMC entry and I think he'd totally deserve one. Oct 11 06:39:34 what about doing mythtv? It is in OE (and a myth version that requires no customisation is unachievable if only because you need local channels and depend on local receiver boards) Oct 11 06:40:26 dm8tbr: what is your proposal ? Oct 11 06:40:36 actually there are - even if not many - USB DVB receivers Oct 11 06:40:37 Then, is OE going to support the panda? Oct 11 06:41:00 mfhk: I'd expect so, though probably more specifically Angstrom Oct 11 06:41:16 eFfeM_work: the amateur radio experimentation platform Oct 11 06:41:30 #73 Oct 11 06:42:40 we had even further ideas, but there is currently no easily available technology to realize them Oct 11 06:44:08 Amateur Radio HDTV transmissions would require DVB-S2 modulators or something with simmilar bandwith, not easily achievable. with 802.11g/n maaaaybe, but we didn't feel like going that way Oct 11 06:44:11 looks interesting, guess instead of going to a more capable dsp, i'd go to an FPGA Oct 11 06:45:30 well the proposal has to sound good for omap4, so we tried to outline possible uses, but yess you could preprocess ADC output in e.g. a FPGA Oct 11 06:46:14 then you could go for even faster ADC Oct 11 06:46:32 currently we are considering 0,5-4 MSPS Oct 11 07:03:32 btw is it possible to force OE into using static linking only (and not put shared libraries in my image) Oct 11 07:03:46 * eFfeM_work is wondering what that would mean for the size of his (small) image Oct 11 07:03:53 guess that could be useful for initramfs too Oct 11 07:25:36 Anyone used ubifs instead of jff2 in his/her project? Oct 11 07:27:46 Anyone used ubifs instead of jffs2 in his/her project? Oct 11 07:28:01 we're providing both images for SHR Oct 11 07:29:21 JaMa, then how are you going to burn the ubi image into the flash chip? Oct 11 07:29:30 I would like to switch to ubifs on ts72xx, but didn't found time yet to study the ubifs :) Oct 11 07:29:41 Must you boot into an initramfs first? Oct 11 07:29:48 why? Oct 11 07:30:25 you can put image on usb flash disk or on nfs share for example Oct 11 07:31:06 I cannot only use ubiformat to burn the image, if not boot into shell, I cannot use ubiformat, see? Oct 11 07:31:37 how did you flashed jffs2 image in such case? Oct 11 07:31:42 sorry , typing mistake, I mean I can only use ubiformat... Oct 11 07:32:09 well, than ubiformat is not enough Oct 11 07:32:28 ynezz, use nand write.jffs Oct 11 07:32:48 moin Oct 11 07:33:29 mfhk: there are two ways Oct 11 07:34:01 hrw: please let me know Oct 11 07:34:16 http://tuomas.kulve.fi/blog/2008/04/18/ubifs-and-gumstix/ is on device Oct 11 07:34:31 http://tuomas.kulve.fi/blog/2008/04/18/ubifs-and-gumstix/ is on host (sorry) Oct 11 07:34:36 http://dominion.thruhere.net/koen/cms/creating-and-mounting-a-ubifs-volume is on device Oct 11 07:35:55 mfhk: grab ubi.img from OE deploy dir, flash into rootfs mtd parttion Oct 11 07:36:52 hm, it's possible directly using ubiformat Oct 11 07:36:54 mfhk: then add to kernel: "root=ubi0:rootfs rootfstype=ubifs ubi.mtd=X" where X is number of mtd partition with ubi.img, ubi0:rootfs is name of ubi partition with rootfs Oct 11 07:36:56 but didn't tried it Oct 11 07:37:14 mfhk: in worst case you will have to do few attempts Oct 11 07:37:15 ubiformat /dev/mtd0 -f ubi.img Oct 11 07:38:16 That's what I am saying. You have to boot into a temp initramfs to have the ubiformat tool. Oct 11 07:38:55 mfhk: or to nfsroot or to root-on-sd or... Oct 11 07:39:06 if you want to make ubi on device Oct 11 07:39:08 if you've some system on the board already, just install mtd-utils package Oct 11 07:39:22 ynezz: not if system is in jffs2 in flash Oct 11 07:39:50 I asked because I want to know if there is any short cut, so it seems there is none :-) Oct 11 07:40:10 mfhk: there is Oct 11 07:40:13 09:35 < hrw> mfhk: grab ubi.img from OE deploy dir, flash into rootfs mtd parttion Oct 11 07:40:17 09:36 < hrw> mfhk: then add to kernel: "root=ubi0:rootfs rootfstype=ubifs ubi.mtd=X" where X is number of mtd partition with ubi.img, ubi0:rootfs is name of ubi partition with rootfs Oct 11 07:41:02 hrw: no, it will fail with ECC error. I tried that. Oct 11 07:41:17 mfhk: pastebin dmesg? Oct 11 07:42:01 hrw: you can look at the ... let me see ... Oct 11 07:42:53 hrw: here: http://www.linux-mtd.infradead.org/faq/ubi.html#L_ecc_error Oct 11 07:43:13 hrw: you must use ubiformat to flash it. Oct 11 07:43:39 ok Oct 11 07:44:02 hrw: it took me 2 days to find out :( Oct 11 07:44:22 happens Oct 11 07:44:39 so far I played with ubifs on sheevaplug, beagleboard, at91sam9263ek Oct 11 07:45:23 hrw: is it smooth you feel? Oct 11 07:45:33 compared to jffs2? Oct 11 07:45:38 yes Oct 11 07:45:53 try ubifs and you will be surprised how fast you will forget that jffs2 exists Oct 11 07:46:18 mfhk: nandwrite ubinized image.. http://wiki.openmoko.org/wiki/Ubifs Oct 11 07:46:49 ok, I am eager to try after I fixed up my smdk6410. Oct 11 07:48:59 JaMa: I tried nand write ubinized image. it won't work, wasted me 2 days. Oct 11 07:50:43 was it really ubinized? not just ubifs image? Oct 11 07:51:22 JaMa: really ubinized correctly with regard to the NAND chip spec. Oct 11 07:51:42 ok, strange, works here ok Oct 11 07:52:38 JaMa: anyway, made me learn something in the end, good :) Oct 11 08:04:33 03Koen Kooi  07org.openembedded.dev * rcfcd107b9e 10openembedded.git/recipes/webm/ (2 files in 2 dirs): libvpx: update to 0.9.2 Oct 11 08:20:09 good morning Oct 11 08:45:14 eFfeM_work: I'm under the impression we can remove a lot of gpe recipes. Talking with florian yesterday about this, it looks like a couple of gpe-versions could be removed (if not all) Oct 11 08:45:43 I mean preferred-gpe-versions Oct 11 08:47:39 ant_work: I'm all in favour of removing the .6 and .7 includes Oct 11 08:48:02 only 2 distros make use of pref-gpe-vers Oct 11 08:48:13 amsdelta-oe and sharprom compatible Oct 11 08:49:02 actually wrt amsdelta i've not even an idea who the maintainer is Oct 11 08:49:32 about sharprom, is surely not able to build images nowaday (is kept just to build single packages). I'd obsolete it, being it needs external toolchain Oct 11 08:49:45 gcc-2.95 Oct 11 08:50:16 sharprom is even older than amsdelta Oct 11 08:50:18 found this Oct 11 08:50:19 sharprom-compatible.conf Oct 11 08:50:20  Not listed in MAINTAINERS Oct 11 08:50:20  probbly also created by nslu2-linux.adm@bkbits.net, but file has been touched by several people Oct 11 08:50:54 hrw: opinions? We already discarded the embedix-kernels Oct 11 08:51:09 eFfeM_work: this sharprom comes from old OpenZaurus iirc Oct 11 08:51:41 * eFfeM_work is strongly in favour to explicitly mention the MAINTAINERS in every distro and machine conf so you know who to contact Oct 11 08:51:47 eFfeM_work: generally speaking, I'd remove the distro stuck to 2.4 kernel Oct 11 08:52:11 ant_work: you have my blessing (and my ack fwiw) Oct 11 08:52:23 ok, thx Oct 11 08:53:41 eFfeM_work: ah, about your initrams size-conceirns, if you have a low-populated rootfs building klibc-static is awesome Oct 11 08:53:58 low-pop = 2 or 3 binaries Oct 11 08:54:15 otherwise klibc-shared becomes interesting Oct 11 08:54:22 good morning Oct 11 08:54:51 if you have a bit more space, try uclibc initramfs Oct 11 08:55:17 finally, if you feel brave, dietlibc is another alternative (broken atm :/) Oct 11 08:55:49 sharprom-compatible... let it die with openzaurus*2.4* kernels Oct 11 08:56:00 :) Oct 11 08:56:03 final hack Oct 11 08:56:34 I really wonder how many people still use their zauruses (especially sl5500 ones) Oct 11 08:57:19 ant_work: ah, sounds very interesting; what I have is flashcp, a few busybox applets, urjtag and probably i2c-toos and module-init-tools Oct 11 08:57:39 probably sl-cxx00 ones are still in small use but with 2.6 kernels and ubuntu/debian/fedora rather then sharprom Oct 11 08:58:03 florian: good morning Oct 11 08:58:12 eFfeM_work: /me checks that zsafe recipe Oct 11 08:59:03 ant_work: actually space is not really the issue, it is also the loading time Oct 11 08:59:11 will peek at klibc Oct 11 09:00:23 hrw, nice, i don't really know what it is, i think the recipe-sanity test drew my attention to it, and noticed it was odd Oct 11 09:01:40 eFfeM_work: will mail as it may make few more people interested Oct 11 09:02:08 as this is really strange Oct 11 09:02:41 weird suggestion: what about an option that says that non-packaged files in the image dir constitute an error (instead of a note like it is now); together with it probably have something like an -unused package that is normally empty, but that can be used to explicitly tell that files do not go into any package (no auto populating of -unused) Oct 11 09:03:29 hrw, actually recall why I got here, recipe_sanity complained that FILES_zsafe overwrote FILES_${PN} Oct 11 09:04:36 eFfeM_work: about non-packaged files, what is the 'right' way to eliminate the note in case of -cross packages? Oct 11 09:04:46 there are some more recipes that have things like this, no idea if it is sound Oct 11 09:05:03 ant_work: no idea, i doubt there is a right way defined Oct 11 09:05:52 eFfeM_work: see e.g. klcc-cross if you peek at klibc Oct 11 09:06:13 will do Oct 11 09:06:30 thx Oct 11 09:40:08 good morning Oct 11 10:01:48 morning Oct 11 10:02:41 hi mickey|office Oct 11 10:03:00 florian: got mail from Berlin. Apparantly everything is ok now with the new address in Berlin and I received the e.V.'s Gemeinnützigkeitsbescheinigung for another year Oct 11 10:03:09 pb_: heya! how are things? Oct 11 10:03:39 mickey|office: good, thanks. building project not going quite to schedule but everything is basically fine :-) Oct 11 10:04:00 mickey|office: that's good news! Oct 11 10:04:19 pb_: hehe, all projects have the tendency to get late Oct 11 10:04:37 heh, indeed Oct 11 10:04:53 uh! please don't mention this ;) Oct 11 10:51:45 I am not able to to clone the git for gumstix overo branch Oct 11 10:52:17 #gumstix? Oct 11 11:22:06 hmm Oct 11 11:22:32 im trying to build u-boot with bitbake, but im getting "fatal: not a valid object name 1" Oct 11 11:23:31 maybe it's wrong SRC_REV or no SRC_REV at all Oct 11 11:23:34 attila_: no SRCREV defined for you machine Oct 11 11:23:42 s/you/your/ Oct 11 11:24:25 where do i define that Oct 11 11:24:51 in the machine conf? Oct 11 11:26:14 attila_: see the u-boot recipe Oct 11 11:28:57 cool, thanks JaMa, ynezz :) Oct 11 11:57:05 eFfeM_work: about the unpackaged files, I suppose most if not all the files landing in sysroot and not in the target image will trigger the note Oct 11 11:58:15 afaik the resulting empty package is skipped (not generated) Oct 11 12:01:41 anyone knows which config should i use for u-boot if i have a custom board with a pxa270? Oct 11 12:03:18 http://lists.denx.de/pipermail/u-boot/2007-May/021485.html Oct 11 12:03:24 attila: ^ Oct 11 12:04:08 thx Oct 11 12:04:11 we used a customized version for zaurus spitz (pxa270) Oct 11 12:24:39 03Koen Kooi  07org.openembedded.dev * r8da20f5b7d 10openembedded.git/recipes/linux/multi-kernel.inc: Oct 11 12:24:39 multi-kernel: use PARALLEL_MAKE if set by user Oct 11 12:24:39 Signed-off-by: Koen Kooi Oct 11 12:31:16 hi, what package do I need to cross debug on an x86 machine an executable on an ARM targt with gdb+gdbremote? Oct 11 12:31:29 gdb-cross or gdb-cross-sdk? Oct 11 12:35:33 hello, when porting linux to arm, I add printascii("bara bara\n"); in start_kernel. It print other string, and then trap into abort. What's wrong? Oct 11 12:36:44 cjjnjust: this is not a linux port channel, BTW pastebin the boot messages Oct 11 12:36:53 `pastebin Oct 11 12:37:00 ~pastebin Oct 11 12:37:00 [~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. Oct 11 13:09:11 03Koen Kooi  07org.openembedded.dev * r3f4b585e47 10openembedded.git/recipes/libtool/libtool-sdk_2.4.bb: Oct 11 13:09:11 libtool-sdk: add recipe for 2.4 Oct 11 13:09:11 Without this pkgconfig-sdk fails to build as part of meta-toolchain when using libtool 2.4 Oct 11 13:13:09 jo Oct 11 13:19:43 good evening Oct 11 13:21:47 When I tried to build the kernel using the vendor supplied kernel source tree, with ""bitbake -c compile virtual/kernel" , I got error : /bin/sh: /usr/local/arm/4.2.2-eabi/usr/bin/arm-linux-ar: No such file. Any ideas? Oct 11 13:24:47 When I tried to build the kernel using the vendor supplied kernel source tree, with ""bitbake -c compile virtual/kernel" , I got error : /bin/sh: /usr/local/arm/4.2.2-eabi/usr/bin/arm-linux-ar: No such file. Any ideas? Oct 11 13:26:04 I cannot find any file that mention this binary "arm-linux-ar" in the tree. Oct 11 13:27:00 mfhk: which distro:machine:image ? Oct 11 13:27:09 external toolchain Oct 11 13:27:10 hm Oct 11 13:27:39 or misconfigured kernel-tree# Oct 11 13:30:34 woglinde: distro is x11-gpe-image, no external toolchain installed Oct 11 13:31:48 than misconfigured kernel-tree Oct 11 13:31:49 and, machine is mini6410 Oct 11 13:32:33 any hints where to look for the related problem config please? Oct 11 13:34:52 look into the top Makfefile inside the kernel src Oct 11 13:35:23 where I think the hardcoded AR is defined Oct 11 13:35:28 ars there Oct 11 13:36:22 mfhk: x11-gpe-image is image name not distro Oct 11 13:37:50 mckoan: sorry, distro is angstrom-2008.1 Oct 11 13:38:36 mfhk: you'd better start with te simplest image or with x11-image Oct 11 13:40:00 mckoan: so, the image have something to do with this "ar" thing? Oct 11 13:41:33 mckoan: I have built without problem for x11-gpe-image using the OE fetched kernel. This error only occur with board vendor supplied kernel tree. Oct 11 13:43:25 woglinde: thanks, I found AR = $(CROSS_COMPILE)ar in the Makefile Oct 11 13:46:51 mfhk hm that should be okay Oct 11 13:47:08 the question is where is CROSS_COMPILE set to /usr/local/arm/4.2.2-eabi/usr/bin/arm-linux-ar Oct 11 13:47:15 or better Oct 11 13:47:18 /usr/local/arm/4.2.2-eabi/usr/bin/arm-linux- Oct 11 13:48:41 I am using diff to find out difference from OE fetched kernel, many thanks to all of you! Oct 11 14:13:55 Hi all, is there a easy way to read env. variables from within a recipe, env. vars. which were exported before starting bitbake -c build ? Oct 11 14:15:12 joft06 explain your needs Oct 11 14:16:55 joft06: -e? Oct 11 14:17:54 I like to set a special path to such a env variable. This recipe should check if a certain file is located in that path ......... IF the path is not given it should just ignore it and take a default file instead Oct 11 14:18:58 ? Oct 11 14:19:20 ok, more details ;-) : Oct 11 14:19:52 the path is a pointer to a directory which MAY contain a DTS file Oct 11 14:20:32 if the user specifies such a path by doing export EXHWDESCDIR=/path/to/dts/file Oct 11 14:21:07 then the bb reipe should check that path for the DTS file ---- otherwise it should just take a default DTS Oct 11 14:21:21 no wrong Oct 11 14:21:27 use local.conf for it Oct 11 14:21:41 yes, thats what I'm doing so far Oct 11 14:21:55 but that's very "slow" Oct 11 14:22:08 what is slow? Oct 11 14:22:28 user should only set it once Oct 11 14:22:28 if I have to change that path from call-to-call (call of bitbake) it has to rebuild the bb-cache everytime Oct 11 14:22:33 and go off with it Oct 11 14:22:48 set it =? Oct 11 14:22:54 args ?= Oct 11 14:23:09 and provide it with DFFdxdfdf=moo bitbake Oct 11 14:56:29 anyone knows if paul menzel is in here? Oct 11 14:58:28 playya sometimes Oct 11 14:58:32 but only rare Oct 11 14:58:52 hmm. ok Oct 11 14:59:13 woglinde, do you know his nick? then i can setup a highlight Oct 11 15:12:55 paulepanther or so Oct 11 15:34:23 ok. thx Oct 11 16:52:42 Hi to all, Oct 11 16:53:34 how can I compile with bitbake standalone C file? Oct 11 16:53:48 people, I have troubles building CDRA Oct 11 16:54:09 bitbake -b ~/workspace/oe_sam_dv/oe_at91sam/recipes/crda/crda_1.1.1.bb Oct 11 16:54:33 ... sys.stderr.write('ERROR: Failed to import the "M2Crypto" module: %s\n' Oct 11 16:55:02 libnl and python-m2crypto already built by bitbake Oct 11 16:55:17 (I just found that my question is answered in the docs) Oct 11 16:55:46 TheNoise dont doit better use buildsystem Oct 11 17:02:54 woglinde, do you mean using autotools? Oct 11 17:03:25 your own Makefile Oct 11 17:03:40 if its only one file Oct 11 17:03:52 a small Makfile is enough Oct 11 17:04:00 ok, then how can I cross compile it? Oct 11 17:04:01 but personal I use a autotools Oct 11 17:04:17 cc is set from outside Oct 11 17:04:27 and oe does set it right Oct 11 17:04:34 have to go now Oct 11 17:04:35 bye Oct 11 17:04:39 till later Oct 11 17:08:11 hi, i have my compiler located under /OE/build/tmp_angstrom_2008_1/sysroots/i686-linux/usr/armv4t/bin, now i was wondering which dirs i need to move to another computer to get that woriking Oct 11 17:24:21 is there any howto about setting up OE on Mac OSX? Oct 11 17:38:07 http://bec-systems.com/site/711/openembedded-srctree-and-gitver Oct 11 17:41:50 re Oct 11 17:45:52 cbrake, how is it setting S automagically Oct 11 17:46:38 gm Oct 11 17:46:58 Crofton|work: S = "${FILE_DIRNAME}" Oct 11 17:47:04 is located in srctree.bbclass Oct 11 17:47:10 ah Oct 11 17:47:28 but I keep my source in something like /home/me/src/git Oct 11 17:47:44 Actually, I override S in local.conf Oct 11 17:47:59 Crofton: I imagine you could simple set S then, but have not tried it Oct 11 17:48:07 so other people can use the recipe and keep the source in their preferred location Oct 11 17:48:33 S_pn-gnuradio-srctree = "/home/balister/src/git/gnuradio" Oct 11 17:48:47 I would add a comment showing how to do that to your example Oct 11 17:49:06 Crofton: yes, its tradeoffs -- I like to keep the source and recipe together for my work Oct 11 17:49:27 I don't want the source in the some tree as the recipe Oct 11 17:49:37 messes up version control Oct 11 17:50:01 would you mind adding this discussion to your article? Oct 11 17:50:07 Crofton|work: I've been trying to use git submodules for that scenario Oct 11 17:50:16 Crofton|work: comments are open, so feel free Oct 11 17:50:49 ok Oct 11 17:51:10 I try to keep things simple :) Oct 11 17:51:56 03Chris Larson  07master * r372d8e0833 10openembedded.git/recipes/cups/cups14.inc: Oct 11 17:51:56 cups14: add missing deps on libpng, jpeg Oct 11 17:51:56 Signed-off-by: Chris Larson Oct 11 17:52:14 03Chris Larson  07master * r65ba692b90 10openembedded.git/recipes/gnome/gnome-bluetooth_2.30.0.bb: Oct 11 17:52:14 gnome-bluetooth-2.30.0: add missing x11, xi deps Oct 11 17:52:14 Signed-off-by: Chris Larson Oct 11 17:52:15 03Chris Larson  07master * re7f3fb184f 10openembedded.git/recipes/u-boot/u-boot.inc: Oct 11 17:52:16 u-boot: ensure deploy runs before package_stage Oct 11 17:52:16 Without this, whether the u-boot binaries make it into the staging package can Oct 11 17:52:17 vary, causing failures when building u-boot from pstage. Oct 11 17:52:17 Signed-off-by: Chris Larson Oct 11 18:12:08 is there anybody coming early to ELC/OEDEM on Monday 25th? Oct 11 18:13:10 Crofton: have you decided to come to OEDEM already? :) Oct 11 18:19:21 I will arrive Monday am Oct 11 18:49:41 hi all Oct 11 18:50:21 hi khem Oct 11 18:53:39 re Oct 11 18:56:35 i have a tuesday early evening flight (18.30 or so iirc) Oct 11 18:58:27 have fun Oct 11 19:13:21 hey JaMa Oct 11 19:17:39 hehe khem Oct 11 19:18:59 woglinde: wts up man Oct 11 19:19:35 nothing Oct 11 19:19:59 Crofton: I will also arrive Monday morning to LHR - how do you plan to get to Cambridge? by train? I'm still deciding and looking for a company... :) Oct 11 19:20:25 khem: ping Oct 11 19:21:49 dfoley: hello Oct 11 19:23:18 denix, I suspect I will rent a car Oct 11 19:23:28 I need to talk with my family in England Oct 11 19:23:41 khem: I'm not 100% sure but it seems that gcc is causing problems with host paths in it's .la files Oct 11 19:23:49 also some friends of mine are arriving around noon and plan to take a train Oct 11 19:23:59 dfoley: ok explain Oct 11 19:24:08 Crofton: I see. don't drive on the right side then :) Oct 11 19:24:25 dfoley: btw. I am out to lunch brb in 1 hr then we can continue Oct 11 19:24:26 it is genetic. I can drive on both sides Oct 11 19:24:35 khem: ok Oct 11 19:24:36 Crofton: stick shift :) Oct 11 19:24:41 of course Oct 11 19:24:50 Crofton: yeah, I remember your story from last year... :) Oct 11 19:25:26 * khem has German, Indian and US drivers licenses Oct 11 19:25:39 Crofton: anyone you know who's going to Cambridge/ELC on Monday? Oct 11 19:25:54 yes Oct 11 19:26:02 two guys arrinving in LHR at noon Oct 11 19:26:15 I do not know my exact schedule Oct 11 19:26:21 need to write that email :) Oct 11 19:27:32 khem cool Oct 11 19:29:46 denix, what time do you get in? Oct 11 19:30:34 Crofton: around 10am, I think... Oct 11 19:30:56 or maybe 11, don't remember Oct 11 19:31:08 heh Oct 11 19:31:09 check Oct 11 19:31:28 I'll let me friends know also Oct 11 19:31:41 they are planning on the train Oct 11 19:37:16 Crofton: thanks! Oct 11 19:42:12 playya: did you try if python-pygobject from git builds? Oct 11 19:43:31 no Oct 11 19:44:09 iirc there's a disable-introspection switch in a newer version Oct 11 19:45:43 2.21.4 has this switch: http://blog.tomeuvizoso.net/2010/06/new-pygobject-release-2214.html Oct 11 19:46:38 btw. i sent a mail to oe-dev with my current diff Oct 11 19:53:15 Anyone around w/ freetype built? Oct 11 19:53:23 Is freetype 2.3.x libfreetype6? Oct 11 19:58:40 playya: 2.21.4? Oct 11 19:59:07 playya: I tried 2.26.0 Oct 11 20:25:18 * Jay7 is not going to ELC-E this year.. no visa - no game Oct 11 20:32:15 Jay7: where are you from ? Oct 11 20:32:24 dj-death: russia Oct 11 20:32:46 ok Oct 11 20:33:08 at least coming to the UK must be easier than the US :) Oct 11 20:35:02 denix, looks like I am confused about the days Oct 11 20:35:19 Crofton: why is that? Oct 11 20:35:24 I get in Monday AM, but will likely go see my family south of London Oct 11 20:35:31 Tom arrives Tuesady Oct 11 20:36:35 khem, http://pastebin.com/ZvwM9xUX Oct 11 20:36:41 this is post libtool updates Oct 11 20:36:53 Crofton: I was thinking to catch gstreamer conf on Tue as well... Oct 11 20:37:03 yeah Oct 11 20:37:24 I need to finalize my plans :) Oct 11 20:43:52 Crofton|work: is that angstrom-2010 Oct 11 20:44:25 of course :) Oct 11 20:44:32 the recipe is not commited though Oct 11 20:44:35 Crofton|work: ok noted. Oct 11 20:44:44 bitbake gnu-radion Oct 11 20:44:48 will reproduce it Oct 11 20:44:50 it is a srctree version of the gnuradio ercipe Oct 11 20:44:54 ah Oct 11 20:44:55 ok Oct 11 20:44:59 mrmoku, i have a 2.26 recipe, too. but not yet tested Oct 11 20:45:03 so you see it elsewhere? Oct 11 20:45:07 ok, last batch of obsolete file removal coming up ... Oct 11 20:45:12 03Frans Meulenbroeks  07org.openembedded.dev * r7eb0765f6c 10openembedded.git/recipes/gdb/ (files/libiberty-cross.patch gdb-6.3/thumb-breakpoint.patch): Oct 11 20:45:13 gdb : moved unused files to obsolete dir Oct 11 20:45:13 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:17 Crofton|work: no that was a question :) Oct 11 20:45:19 03Frans Meulenbroeks  07org.openembedded.dev * ra7a24b59a9 10openembedded.git/recipes/glib-2.0/ (10 files in 6 dirs): Oct 11 20:45:19 glib-2.0 : moved unused files to obsolete dir Oct 11 20:45:19 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:19 03Frans Meulenbroeks  07org.openembedded.dev * r14d5920cc3 10openembedded.git/recipes/openjade/openjade-1.3.2/oj-native-libosp-fix.patch: Oct 11 20:45:19 openjade : moved unused files to obsolete dir Oct 11 20:45:19 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:22 03Frans Meulenbroeks  07org.openembedded.dev * rad50a18730 10openembedded.git/recipes/gputty/gputty/conf.patch: Oct 11 20:45:22 gputty : moved unused files to obsolete dir Oct 11 20:45:22 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:22 03Frans Meulenbroeks  07org.openembedded.dev * r8f4ef9cd82 10openembedded.git/recipes/libxine/libxine-1.1.16/ (libavcodec.patch libpostproc.patch): Oct 11 20:45:25 libxine : moved unused files to obsolete dir Oct 11 20:45:25 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:25 03Frans Meulenbroeks  07org.openembedded.dev * rbd49bbc106 10openembedded.git/recipes/gnuradio/gnuradio/ (gnuradio-libusb.patch no-trellis-doc.patch): Oct 11 20:45:25 gnuradio : moved unused files to obsolete dir Oct 11 20:45:25 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:29 03Frans Meulenbroeks  07org.openembedded.dev * rc81b8f70ce 10openembedded.git/recipes/gkdial/ (3 files in 2 dirs): Oct 11 20:45:29 gkdial : moved unused files to obsolete dir Oct 11 20:45:29 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:31 03Frans Meulenbroeks  07org.openembedded.dev * r27653bb9e3 10openembedded.git/recipes/gcc/ (64 files in 18 dirs): Oct 11 20:45:31 gcc : moved unused files to obsolete dir Oct 11 20:45:31 Signed-off-by: Frans Meulenbroeks Oct 11 20:45:31 let my try that Oct 11 20:45:32 03Frans Meulenbroeks  07org.openembedded.dev * ra1f2673a44 10openembedded.git/recipes/git/files/git-gui-install-mode-arg-spaces.patch: Oct 11 20:45:32 git : moved unused files to obsolete dir Oct 11 20:45:40 you had a dash in there :) Oct 11 20:46:16 ah ok typo Oct 11 20:46:51 hopefully the in tree recpe does the same thing ..... Oct 11 20:46:56 checking now Oct 11 20:48:50 bitbake gnuradio Oct 11 20:49:01 should do the same or similar libtool messages Oct 11 20:50:48 hmm, I want to see the orc talk Oct 11 20:51:00 SRC_URI_virtclass-native_append does not seem to do what it should Oct 11 20:51:12 it overrides complete SRC_URI Oct 11 20:52:18 khem there was a patch about a week ago because SRC_URI_ would not override SRC_URI, maybe this is a side effect of that patch Oct 11 20:52:41 yeah SRC_URI_append_virtclass-native is what I need Oct 11 20:54:41 khem: of course it does. i've explained that and why multiple times in herea nd at least once on the mailing list Oct 11 20:54:47 (override complete SRC_URI) Oct 11 20:55:04 yeah some people like me learn hardway Oct 11 20:55:30 I looked into sources and figured Oct 11 20:56:56 kergoth: even SRC_URI_virtclass-native += "" did not work Oct 11 20:57:23 anyone got freetype built handy? Oct 11 20:57:37 tartarus? Oct 11 20:57:53 woglinde, is it libfreetype5 or 6, for 2.3.x ? Oct 11 20:58:34 mom Oct 11 20:58:58 hm 2.4 has 6 Oct 11 20:59:06 yeah Oct 11 20:59:08 I'm packaging that now Oct 11 20:59:15 but if it's not 6 i need to D_P it or something Oct 11 20:59:20 so feeds don't go wonky Oct 11 20:59:33 hm 2.3 should have the same Oct 11 20:59:39 yes, it should Oct 11 20:59:40 but look into source Oct 11 21:00:17 bah, someone has to just have it built and handy :) Oct 11 21:00:27 arm-angstrom-linux-uclibceabi-libtool: link: (cd "/devel/arm/oetmp-ang/work/armv5te-angstrom-linux-uclibceabi/freetype-2.3.12-r2/freetype-2.3.12/objs/.libs" && rm -f "libfreetype.so.6" && ln -s "libfreetype.so.6.4.0" "libfreetype.so.6") Oct 11 21:00:31 arm-angstrom-linux-uclibceabi-libtool: link: (cd "/devel/arm/oetmp-ang/work/armv5te-angstrom-linux-uclibceabi/freetype-2.3.12-r2/freetype-2.3.12/objs/.libs" && rm -f "libfreetype.so" && ln -s "libfreetype.so.6.4.0" "libfreetype.so") Oct 11 21:00:44 thanks Oct 11 21:00:59 * Tartarus just waits for a few more things to finish building Oct 11 21:01:07 03Khem Raj  07master * r56827335b8 10openembedded.git/recipes/openjade/openjade_1.3.2.bb: Oct 11 21:01:07 openjade_1.3.2.bb: Add missing patch to native build. Oct 11 21:01:07 * While merging native recipe one patch got lost which Oct 11 21:01:07 should have been applied to native build only. Otherwise Oct 11 21:01:07 a clean rebuild wont work. Oct 11 21:01:07 Signed-off-by: Khem Raj Oct 11 21:04:20 hm, nuked that one half an hour ago, will revert Oct 11 21:05:08 it's back.... Oct 11 21:05:19 apologies for any inconvenience Oct 11 21:05:20 03Frans Meulenbroeks  07org.openembedded.dev * r9ddb7032fd 10openembedded.git/recipes/obsolete/openjade/openjade-1.3.2/oj-native-libosp-fix.patch: Oct 11 21:05:20 Revert "openjade : moved unused files to obsolete dir" Oct 11 21:05:20 This reverts commit 14d5920cc37dac7c118cb019a90fde9c56f4b99d. Oct 11 21:05:20 apparently this patch was accidently not included in the recipe Oct 11 21:05:20 it has been added since, so reverting this commit Oct 11 21:05:20 Signed-off-by: Frans Meulenbroeks Oct 11 21:06:18 ok, calling it a day, cya tomorrow Oct 11 21:07:46 o.O Oct 11 21:08:00 lol Oct 11 21:08:04 openjade Oct 11 21:12:28 khem, you caught m y message bitbake gnuradio should reproduce my libtool issue? Oct 11 21:18:30 woglinde: yeah its jaded Oct 11 21:19:03 Frans is sniffing down my neck I should be careful to leave orphan patches :) Oct 11 21:19:14 *g* Oct 11 21:23:40 03Andrea Adami  07org.openembedded.dev * rd39eee29fb 10openembedded.git/conf/distro/include/ (2 files): Oct 11 21:23:40 preferred-gpe-versions: remove unused/unpinned versions Oct 11 21:23:40 * only two distros are currently using this files: Oct 11 21:23:40 * sharprom-compatible.conf -> preferred-gpe-versions.inc Oct 11 21:23:40 * amsdelta-oe.conf -> preferred-gpe-versions-2.8.inc Oct 11 21:23:40 * both could probably live with latest versions...who knows... Oct 11 21:23:41 03Andrea Adami  07org.openembedded.dev * r4af226e94d 10openembedded.git/recipes/libqtaux/libqtaux2.inc: libqtaux: remove superfluous do_stage() Oct 11 21:23:42 03Andrea Adami  07org.openembedded.dev * r27be3e925f 10openembedded.git/recipes/libxsettings/ (libxsettings_0.11.bb libxsettings_svn.bb): libxsettings: convert to new-style staging. Bump PR. Oct 11 21:23:42 03Andrea Adami  07org.openembedded.dev * r3abb865117 10openembedded.git/recipes/libxsettings-client/ (9 files in 3 dirs): Oct 11 21:23:43 libxsettings-client: convert to new-style staging Oct 11 21:23:44 * remove unused/unpinned versions Oct 11 21:23:44 * bump PR Oct 11 21:23:45 03Andrea Adami  07org.openembedded.dev * r86c2087138 10openembedded.git/recipes/opie-taskbar/ (4 files): opie-taskbar: move to new style staging. Bump PR. Oct 11 21:23:45 03Andrea Adami  07org.openembedded.dev * rcc66d8a96f 10openembedded.git/recipes/libopietooth/ (4 files): libopietooth: convert to new-style staging. Bump PR. Oct 11 21:23:46 03Andrea Adami  07org.openembedded.dev * r7ac14aa20b 10openembedded.git/recipes/opie-libqrsync/opie-libqrsync.inc: opie-libqresync: convert to new style staging. Oct 11 21:23:46 03Andrea Adami  07org.openembedded.dev * r4f05db37d7 10openembedded.git/recipes/libgpepimc/ (9 files): Oct 11 21:24:26 03Khem Raj  07master * rbf2f44fc9b 10openembedded.git/recipes/curl/curl_7.21.1.bb: Oct 11 21:24:26 curl_7.21.1.bb: DEPENDS for native and sdk recipes needs to be tuned Oct 11 21:24:26 * Using BBCLASSEXTEND for native nativesdk and sdk needs Oct 11 21:24:26 adjusting the DEPENDS and EXTRA_OECONF Oct 11 21:24:26 Signed-off-by: Khem Raj Oct 11 21:26:32 jo ant Oct 11 21:26:50 hi woglinde Oct 11 21:28:06 kergoth: native has PACKAGES="" and also cross class but sdk and nativesdk dont, this casues wrong libtool to be picked to provide libltdl, it picks libtool-sdk or libtool-nativesdk instead of libtool shoulnt the PACKAGES be adjusted to have correct suffix in these cases ? Oct 11 21:28:31 kergoth: like libltdl-sdk-dev and libltdl-nativesdk-dev and so no ? Oct 11 21:31:43 dfoley: there ? Oct 11 21:32:29 khem: ya. I decided to rebuild first for sanity Oct 11 21:32:38 ok Oct 11 21:33:00 dfoley: you are not using libtool 2.4 yet are you ? Oct 11 21:33:16 dfoley: which machine and distro are you using Oct 11 21:33:54 khem: I guess so. angstrom-2010.x and my machine which is armv4t Oct 11 21:36:36 khem: the sdk recipes can't have an empty packages, because they're supposed to emit packages to be installed into the sdk... Oct 11 21:36:41 as far as i know, anyway.. Oct 11 21:36:56 dfoley: got it Oct 11 21:37:21 kergoth: hmm should they have same names like original target recipe Oct 11 21:38:32 I mean package names Oct 11 21:38:59 so in case of libtool it does not pick sdk recipe to provide libtool for target root file system Oct 11 21:39:04 that I am building Oct 11 21:39:17 I guess the packages should be called differently Oct 11 21:39:28 may be they should have the sdk suffix in them Oct 11 21:40:20 good nite Oct 11 21:40:45 er Oct 11 21:40:54 we should just be able to do BBCLASSEXTEND = "sdk" Oct 11 21:40:56 or add sdk to the list Oct 11 21:41:42 Tartarus: in some cases BBXLASSEXTEND might not be possible like libtool Oct 11 21:42:04 anyway inherit sdk should behave similarily isnt it Oct 11 21:42:31 Er Oct 11 21:42:33 Say again? Oct 11 21:42:37 We have some stuff doing that already Oct 11 21:43:08 Tartarus: ok right now my problem is that some PACKAGES emitted by libtool and libtool-sdk are named same Oct 11 21:43:24 so bitbake chooses libtool-sdk to provide them even for target Oct 11 21:43:25 As in they're being placed in the wrong spot/ Oct 11 21:43:31 So, something is up with the recipe Oct 11 21:43:35 not BBCLASSEXTEND Oct 11 21:43:38 that works fine elsewhere Oct 11 21:43:57 Tartarus: I see the problem Oct 11 21:44:21 Tartarus: the problem is that sdk recipe includes the target recipe and hence gets the package names Oct 11 21:44:27 Yes Oct 11 21:44:28 but it also inherits sdk Oct 11 21:44:36 So we should have just used BBCLASSEXTEND Oct 11 21:44:40 not added a new bbfile Oct 11 21:44:52 should sdk.bbclass munge the package names Oct 11 21:45:14 if manually inheriting hte class behaves differently than inheriting with bbclassextend, something is broken Oct 11 21:45:27 kergoth: you got my point Oct 11 21:46:19 handling of PACKAGES/RDEPENDS for native/cross needs to be rethought in general. Oct 11 21:46:27 the classes need to mangle all the available RDEPENDS as well Oct 11 21:46:55 but the thing is, the package names are based on PN, and libtool-sdk is the PN, so i don't see how it could be emitting hte same packages Oct 11 21:46:59 unless its a bug in the recipe Oct 11 21:48:02 kergoth: what if I added something to PACKAGES Oct 11 21:48:07 PACKAGES =+ "libltdl libltdl-dev libltdl-dbg" Oct 11 21:48:25 in the target recipe which is then included in sdk recipe Oct 11 21:48:36 yeah, that would be a problem Oct 11 21:48:44 imo class should munge PACKAGES Oct 11 21:49:03 that would break RDEPENDS behavior, unless they're mangled also Oct 11 21:49:07 but probably a good idea, yes Oct 11 21:51:19 Why doesn't this happen already? Oct 11 21:51:49 i expect because no one thought about it Oct 11 21:52:03 no one noticed that RDEPENDS_${PN} affects natives either Oct 11 21:52:13 these issues only really showed up after the conversions to bbclassextend Oct 11 21:52:18 because such things used to only be set in the target recipes Oct 11 21:52:27 and I think we should substitute sdk with nativesdk may be ? Oct 11 21:52:34 moving forward Oct 11 21:52:37 sdk needs to go away, its unclear and old Oct 11 21:52:38 imo Oct 11 21:52:51 We need to make nativesdk do something, yes Oct 11 21:52:56 That's the problem with that statement Oct 11 21:52:58 so target native and nativesdk Oct 11 21:53:09 and cross Oct 11 21:53:14 afaics the "make a standalone sdk" part of the conversion is untried Oct 11 21:53:26 or at least poky hadn't changed that recipe yet when I looked last Oct 11 21:53:32 (meta-toolchain, that is) Oct 11 21:53:49 yeah I am working on meta-toolchain Oct 11 21:53:51 right now Oct 11 21:53:57 actually trying to build it Oct 11 21:54:05 poky or OE? Oct 11 21:54:05 * khem never paid attention to sdk Oct 11 21:54:08 OE Oct 11 21:54:09 it should be fine in OE Oct 11 21:54:21 aside from new libtool stuff ;) Oct 11 21:54:29 is crosssdk still useful Oct 11 21:54:36 That's part of the "new" way Oct 11 21:54:44 * kergoth was thinking about adding TOOLCHAIN_FEATURES or so, using oe.packagegroup Oct 11 21:55:05 khem: nativesdk is native -> into an sdk. crosssdk is cross -> into an sdk. there is no "still useful", they're two different classes Oct 11 21:55:06 Tartarus: hmm ok Oct 11 21:55:12 afaik, anyway Oct 11 21:56:13 kergoth: so say I want to ship a target curl into sdk then it would include the target package for that into sdk right Oct 11 21:56:29 but if I want to ship the cross compiler that would be crosssdk Oct 11 21:56:41 right, target doesn't need a sspecial class, the same packages work for both Oct 11 21:56:54 but thats not hte case for native and cross due to relocatability concerns, etc Oct 11 21:56:56 and if I wannt to ship a version of libmpfr that this compiler needs to run that would be nativesdk ? Oct 11 21:56:58 the sdk is a special type of image Oct 11 21:57:05 It contains target stuff in one subdir Oct 11 21:57:08 and host stuff in another Oct 11 21:57:10 basically Oct 11 21:58:27 i rather like the idea of just letting native/cross make packages and killing the sdk classes Oct 11 21:58:39 kergoth: exactly Oct 11 21:58:48 and fix relocation issues that crop up due to installing in paths relative to SDK_DIR or whatever instead of sysroots Oct 11 21:59:01 we could have INSTALL_ROOT Oct 11 21:59:18 something like that into opk Oct 11 21:59:20 g Oct 11 21:59:29 also, i'd like to kill the prefix mangling in native/cross which makes them live in sysroots, let them use the standard prefix with DESTDIR, and *fix* relocation issues Oct 11 21:59:39 heh Oct 11 21:59:42 kergoth: so my understanding of nativesdk and crosssdk is right ? Oct 11 21:59:43 Oct 11 21:59:50 i think so, yes Oct 11 22:00:09 anyone know where the proper upstream scm repo is for wget? Oct 11 22:00:27 they have a deprecated svn, a deprecated mercurial.. can't tell if the bzr repo is current, i'm a bzr noob Oct 11 22:00:29 kergoth: should be on savannah Oct 11 22:00:30 hrmph Oct 11 22:00:44 savannah links to a page which links to deprecated repositories :) Oct 11 22:01:43 http://wget.addictivecode.org/RepositoryAccess Oct 11 22:02:11 use bzr Oct 11 22:02:32 its like git or svn Oct 11 22:02:51 https://savannah.gnu.org/bzr/?group=wget Oct 11 22:05:03 kergoth: so the old sdk means both crosssdk and nativesdk depending upon what you are talking about right Oct 11 22:05:49 i know what bzr *is*, its just the bzr branch command they give errors, so figured that repo wasn't right Oct 11 22:05:53 * kergoth tries again Oct 11 22:06:27 khem: if you look at sdk.bbclass, at what it does, you'll see that it doesnt' change TARGET_* Oct 11 22:06:40 which means its not native, target remains the smae, just host becomes the same as build == cross Oct 11 22:06:43 kergoth: right Oct 11 22:07:16 i think at first no one considered the usefulness / need of native tools in an sdk Oct 11 22:07:22 but i don't really know :) Oct 11 22:08:01 * kergoth rsyncs the wget bzr repo Oct 11 22:08:16 kergoth: yeah its to make same toolchain work on different distros Oct 11 22:08:23 and still use shared libs Oct 11 22:08:41 kind of captive env I can understand the use of it Oct 11 22:08:52 yeah, its great if you can't rely on the build machines you run on Oct 11 22:10:17 e.g. gcc uses libmpfr.so and if some machine provides a faulty one, gcc from that SDK on that machine will generate bogus code Oct 11 22:10:32 Hence the use it statically part :) Oct 11 22:10:34 But yes Oct 11 22:10:51 I am always for static toolchains Oct 11 22:10:54 SDK isn't always going to work on other hosts Oct 11 22:11:25 Tartarus: sometimes its like you want to base on ubuntu 8.04 Oct 11 22:11:32 and want the same to work on ubuntu 10.10 Oct 11 22:11:41 and releases in between Oct 11 22:11:53 yes Oct 11 22:11:54 host arch may be same Oct 11 22:11:56 ideally we'd build everything native/cross in a way that's portable with lsb tools or autopackage tools or something Oct 11 22:11:59 Believe me, I know :) Oct 11 22:12:06 * Tartarus wishes LSB didn't suck Oct 11 22:12:15 * kergoth too Oct 11 22:14:03 pkg-config removes /usr/lib from -L flags. Oct 11 22:14:19 playya__: yep. there' an env var that controls that behavior, iirc Oct 11 22:14:27 whats the best solution to avoid it? write a patch or set the env var Oct 11 22:14:59 why would you want to avoid it? Oct 11 22:15:02 for native/cross? Oct 11 22:15:27 maybe it helps with gobject-introspection Oct 11 22:15:41 target recipes should never touch /usr Oct 11 22:15:45 and trying things at random isn't going to magically fix it Oct 11 22:16:12 btw. should the .gir files go into -dev or gir1.0- packages? Oct 11 22:18:29 I'm just rebuilding to check if it helps Oct 11 22:25:15 03Andrea Adami  07org.openembedded.dev * r0cb515879a 10openembedded.git/recipes/libqpe/ (libqpe-opie.inc libqpe-opie_1.2.3.bb libqpe-opie_1.2.4.bb): libqpe-opie: remove superfluous do_stage (). Bump PR. Oct 11 22:55:33 ERROR: QA Issue with staging: libospgrove.la failed sanity test (workdir) in path /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib Oct 11 22:55:34 ERROR: QA Issue with staging: libospgrove.la failed sanity test (workdir) in path /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib Oct 11 22:55:35 hmm Oct 11 23:01:30 lots of crap in the metadata at the moment Oct 11 23:03:16 Yeah :( Oct 11 23:03:49 if I were to graph my perceptiion of quality over the past month, it would be awful Oct 11 23:04:02 Missing or unbuildable dependency chain was: ['libfontconfig1'] Oct 11 23:05:08 The wiki is transitioning at this time (I think I saw that in the ML) but its offline/read only at this point. Oct 11 23:05:09 I don't mind the occasional problem, but the past couple of weeks have been dreadful Oct 11 23:05:15 urg Oct 11 23:05:22 did we send an email Oct 11 23:05:30 Steffen said he would Oct 11 23:05:33 I am hoping everyone is asleep :) Oct 11 23:05:36 me too! Oct 11 23:05:44 except khem and me Oct 11 23:06:00 i just got to work Oct 11 23:06:01 heh Oct 11 23:06:02 :) Oct 11 23:06:08 I'll send something Oct 11 23:06:20 I only moved the A record for the wiki Oct 11 23:06:34 I think www redirects and we can fix that after dns updates Oct 11 23:06:43 I'll send an email Oct 11 23:06:52 * kergoth thinks about ditching the old use of pkgdata to persist the info across do_package -> do_package_ipk, instead just running the packaging tasks via PACKAGEFUNCS, or a new PACKAGEWRITEFUNCS run from do_package_write Oct 11 23:07:01 hrm Oct 11 23:09:17 ERROR: QA Issue with staging: libostyle.la failed sanity test (workdir) in path /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib Oct 11 23:09:47 do we have any examples of how to solve such issues? Oct 11 23:09:53 * kergoth hopes the discussion at oedem about starting to do actual releases goes somewhere, would be really nice Oct 11 23:09:57 I am assuming they are libtool upgrade related? Oct 11 23:10:18 kergoth, the problem is releases are a DISTRO concept Oct 11 23:10:21 heh, personally, i don't see the point in keeping .la files in sysroots at all. we don't need them on 95% of the build machines Oct 11 23:10:42 what about the other 5%? Oct 11 23:10:54 Crofton|work: I disagree. release of images, binaries, etc, sure, but we could at least use a proper release cycle to stabilize the tree Oct 11 23:10:59 all I know is .la seems to be some form of swear word Oct 11 23:11:01 the other 5% is likely broken already for other reasons Oct 11 23:11:28 Oh .la!! Oct 11 23:11:29 the only reason you need .la is for machines where one shared lib can't automatically pull in another it depends on at link time, as far as i know Oct 11 23:11:34 maybe khem would know better though Oct 11 23:11:42 Nah, doesn't have the right ring to it, Crofton. :) Oct 11 23:13:09 I have a week at home, and was hoping to see about beating SlugOS into a bit better shape -- did I pick a bad time for that, with the libtool change? Oct 11 23:14:11 using libtool 2.4 is giving *lots* of failures in qa_staging, but is otherwise ok Oct 11 23:14:12 Oh probably :) Oct 11 23:14:20 you can opt out of 2.4 Oct 11 23:14:40 2.4 is opt in, no? Oct 11 23:14:48 kergoth, yes Oct 11 23:15:00 er, yes Oct 11 23:15:11 I meant you could opt out of that bit of extra trouble when dusting things off Oct 11 23:15:21 Well, if I have the time, I suppose it would be best to make it work with 2.4 -- have to sooner or later anyhow. Oct 11 23:15:35 yeah we need to make it work Oct 11 23:15:51 and it sounds like the libtool guys will be helpful Oct 11 23:15:55 I guess I should I probably make sure it boots still before I tackle 2.4, though. Oct 11 23:17:41 can we try shooting all the la files? Oct 11 23:17:51 I know they are nothing but trouble :) Oct 11 23:18:28 I'd like to get some guidelines in place for fixing these problems Oct 12 01:30:43 03Khem Raj  07master * ra92ca415ac 10openembedded.git/recipes/libtool/ (10 files): (log message trimmed) Oct 12 01:30:43 libtool: Abstact more common things to libtool.inc Oct 12 01:30:43 * inherit autotools is now in libtool.inc and so is EXTRA_AUTORECONF = Oct 12 01:30:43 "--exclude=libtoolize" Oct 12 01:30:43 * Include libtool.inc separately into -cross -native -sdk and -nativesdk Oct 12 01:30:44 recipes for 2.4 this avoids the problem where libltdl etc are also Oct 12 01:30:45 provided by -sdk and -nativesdk recipes which is incorrect Oct 12 01:30:47 03Khem Raj  07master * r49c5170a52 10openembedded.git/recipes/binutils/binutils-cross-sdk.inc: Oct 12 01:30:47 binutils-cross-sdk.inc: Do not install ${D}${infodir}/dir Oct 12 01:30:47 * This file should be generates when the package is actually installed Oct 12 01:30:47 not when we install it during build. Oct 12 01:30:47 Signed-off-by: Khem Raj Oct 12 01:38:16 * kergoth_ ponders the native/cross packaging situation Oct 12 01:42:22 kergoth_: I think we need to clear our sdk approach Oct 12 01:44:32 * kergoth_ thinks about removing the prefix= overrides in native.bbclass and seeing what explodes Oct 12 01:44:51 * ka6sox-work stands back Oct 12 01:45:16 hehe Oct 12 01:47:28 kergoth_: you mean base_prefix Oct 12 01:47:35 i mean all of them Oct 12 01:48:06 oh Oct 12 01:48:32 kergoth_: then sysroot should take of it u mean ? Oct 12 01:48:37 it'd be a really, really fast way to find relocation problems -- every native would be relocated from the standard prefix into the sysroot location Oct 12 01:51:56 * khem scratches head Oct 12 02:10:32 khem did you see me whining about libtool hassles Oct 12 02:22:53 Ah **** ENDING LOGGING AT Tue Oct 12 02:59:57 2010