**** BEGIN LOGGING AT Fri Jul 15 02:59:57 2011 Jul 15 06:41:54 hi guys, i made a recipe which is supposed to create seperate packages for the project's lib and bins (and i don't want to do it with inherit lib_package because of the naming) but the files end up in the wrong ipks... what am i doing wrong @ http://pastebin.com/8yRbdKDQ ? Jul 15 07:20:59 hi everybody Jul 15 07:21:00 I accidentally came to need some sources from it. In particular, I need kernel-2.4 patches for h3900. (CVS, I guess). Anybody to point me where I can get it? Jul 15 07:42:41 hm, is http://www.openembedded.org/snapshots/ gone? need to rebuild an old product but the fetch fails Jul 15 07:44:25 ildar: you should try to find people with h3600 Jul 15 07:44:42 afaik, there is no cvs mirrors from hh.org Jul 15 07:44:46 only tarballs Jul 15 07:45:13 Source tarballs would be ok too Jul 15 07:45:24 if you have a link Jul 15 07:46:44 hm.. may be on oe mirrors site Jul 15 07:46:52 but can't remember link Jul 15 07:47:01 mirrors.openembedded.org seems down Jul 15 07:47:01 I don't know familiar mailing list :( Jul 15 07:52:34 ant_work: hello Jul 15 07:52:59 morning Jay7 Jul 15 07:56:53 hi ant Jul 15 07:56:58 hi jay7 Jul 15 07:56:59 hi effem Jul 15 07:57:17 morning woglinde Jul 15 07:57:21 Jay7: thanx Jul 15 07:58:33 ildar: I'll try to ask some people about h3900 2.4 kernel but not sure about results Jul 15 07:58:58 ok, thanx Jul 15 08:00:21 hi woglinde, all Jul 15 08:00:25 Jay7 2.4 support is dropped in oe-core Jul 15 08:00:40 woglinde: I know Jul 15 08:00:50 ildar is looking for some old patches from hh.org Jul 15 08:00:57 yep. Jul 15 08:01:43 ah okay Jul 15 08:05:01 woglinde i stumbled upon a problem last night which i asked about before you got here, so may the channel please forgive me repeating myself... Jul 15 08:05:10 hi guys, i made a recipe which is supposed to create seperate packages for the project's lib and bins (and i don't want to do it with inherit lib_package because of the naming) but the files end up in the wrong ipks... what am i doing wrong @ http://pastebin.com/8yRbdKDQ ? Jul 15 08:05:45 fraxinath look at other recipes how FILES_ stuff is handled Jul 15 08:05:56 look in bitbake.conf too in config di Jul 15 08:05:57 r Jul 15 08:06:11 woglinde i pretty much copied the stuff from the lib52a recipe Jul 15 08:06:45 it's very confusing that it packs a file into another ipk when i've explicitely put it into a different one Jul 15 08:06:50 ues bitbake -e and look into what FILES_ really envolved Jul 15 08:07:07 but from the look the globbing seems wrong in some cases Jul 15 08:07:16 okay will try Jul 15 08:07:43 FILES_librtmp = " ${libdir}/librtmp.* is wrong for sure Jul 15 08:07:58 .so should go to dev Jul 15 08:08:34 nad image is the wrong place to look Jul 15 08:08:46 where the files ended up Jul 15 08:09:17 hey guies ,i have been working on mini6410 development board ,i have downloaded the kernel from mini6410dedian site ,but i suspect it has internal bugs , anyone who has been working on kernel ,plz suggest Jul 15 08:09:29 my main problem is that ./usr/lib/librtmp.so.0 ends up in rtmpdump when it should be in librtmp Jul 15 08:09:40 yes wrong globbing Jul 15 08:09:59 fraxinath are you using old oe master? maintaince 2011.3? Jul 15 08:10:14 using the opendreambox branch Jul 15 08:10:18 it's oldish Jul 15 08:11:11 morning all Jul 15 08:12:24 fraxinath by the way you should fix the library stuff for rmtp Jul 15 08:12:30 it has no .so lib Jul 15 08:12:39 linkinig against .so.0 is bad manner Jul 15 08:12:57 it comes with a crappy static makefile :/ Jul 15 08:13:02 wish they used autotools Jul 15 08:13:21 autotools it yourself Jul 15 08:13:24 isnt that hard Jul 15 08:13:59 could do that Jul 15 08:14:20 but first i wanna understand how to put files into arbitrary ipks correctly :) Jul 15 08:15:49 fraxinath: :) I can even trigger some strange python error doing bad things with packaging Jul 15 08:16:14 oh, seem i've hit a wound spot Jul 15 08:17:52 bluelightning: hi, don't you have 2.4 kernel tree for h3900? Jul 15 08:18:00 it was on hh.org Jul 15 08:18:28 Jay7: probably somewhere back in NZ I guess Jul 15 08:18:39 see, I had similar ".so not in -dev" QA, even if for a libc this is maybe ok Jul 15 08:18:48 fraxinath: we did http://paste.debian.net/122951/ Jul 15 08:19:11 bluelightning: ildar is looking for 2.4 kernel tree for h3900 Jul 15 08:19:22 hmm Jul 15 08:19:35 ildar: bother bluelightning ;) Jul 15 08:19:49 Jay7: I really wish I had grabbed more than just the opie sources before it went :( Jul 15 08:20:15 ildar: I will see if I can get my old machine in NZ up over the weekend and have a look Jul 15 08:21:36 woglinde... bitbake -e shows me, the FILES_ variables are being set correctly, but they seem to be used nowhere after that Jul 15 08:22:13 gm mickeyl Jul 15 08:53:18 bluelightning: whoa! thanks a lot1 Jul 15 08:53:20 ! Jul 15 08:53:41 ildar: well, maybe wait to thank me until I actually find it :) Jul 15 08:54:27 your efforts worth thanking anyway Jul 15 09:00:46 morning woglinde Jul 15 09:01:44 mickeyl got some slepp? Jul 15 09:01:49 ups sleep Jul 15 09:01:51 *g* Jul 15 09:04:47 no slepp -> depp Jul 15 09:16:38 ildar: are you hoping to use it as a reference for improving the 2.6 support for h3900? Jul 15 09:16:59 yep Jul 15 09:17:17 any chance I would succeed? Jul 15 09:29:33 bluelightning: about oe-core. Are you cleaning meta-oe? Please kill the classes in there Jul 15 09:30:31 if you add meta-oe on the top of oe-core things are going weird Jul 15 09:32:01 ildar: well, you may want to look at some of the work done by "rui kou" a few years ago, he said he got everything working for h3900 Jul 15 09:32:25 ant_work: really? which classes are causing problems? Jul 15 09:32:48 using angstrom-setup-scripts you get e.g. kernel.bbclass Jul 15 09:33:23 ildar: http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg03251.html Jul 15 09:33:28 which is different from both oe-dev and oe-core Jul 15 09:34:00 I understand koen did add it at the beginning to prototype the layer Jul 15 09:34:11 s Jul 15 09:34:17 ant_work: the question is always "why is it different" ? Jul 15 09:34:36 see my MSG on oe-dev Jul 15 09:35:06 took some time before removing it Jul 15 09:35:49 I discovered I was using this class when parsing the log I did not find reference to cpio.xz Jul 15 09:37:18 Anyone know how I get the debug from lib/bb/fetch2 ? I have a strange fetcher problem. Jul 15 09:37:20 bluelightning: we need some sort of documentation for the oe-devs Jul 15 09:37:31 about the minimalistic layer structure Jul 15 09:37:35 ant_work: you mean on migrating to oe-core? Jul 15 09:37:43 finally yes Jul 15 09:37:52 ant_work: yes, this is definitely lacking Jul 15 09:37:54 Logger is "BitBake.Fetcher" Jul 15 09:38:38 ant_work: I was hoping that someone else would take the initiative and do it, but maybe that "someone else" is going to be me... Jul 15 09:38:41 bluelightning: I still can't understand the initial note http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/conf/layer.conf Jul 15 09:38:54 about priority Jul 15 09:39:56 ant_work: hmm, well it may be right in that the priority numbers only apply to recipes (and recently bbappend files as well) Jul 15 09:40:08 if so that may be a bug# Jul 15 09:40:19 s/#// Jul 15 09:40:21 I can tell you meta-oe is 6 and overwrites oe-core Jul 15 09:40:30 yes, and that's correct Jul 15 09:40:33 Ah, found it. "bitbake -l Fetcher" Jul 15 09:40:44 I would expect meta-oe to override oe-core Jul 15 09:41:16 then "It really depends on order of the layers appearing " doesn't apply anymore? Jul 15 09:41:33 however I would also expect only a limited number of overlayed recipes and bbclasses Jul 15 09:42:08 ant_work: well the wording may not be optimal but it's only referring to .inc and .conf files Jul 15 09:42:25 omg Jul 15 09:42:41 ? Jul 15 09:43:22 I am used to include my changes as last item so I would prefer that ordering Jul 15 09:43:36 the priority thing adds complexity Jul 15 09:43:49 and why not the .inc? Jul 15 09:44:02 ant_work: well, ideally it would be last is higher priority if ordering was important Jul 15 09:44:06 so yes Jul 15 09:44:07 I confess I never dug in that code Jul 15 09:44:30 seems a bit awkward Jul 15 09:44:55 anyway, once cleaned it works :) Jul 15 09:45:00 hi ant Jul 15 09:45:03 .inc files should not be "overridden"... in fact AFAIK you can't overlay them in the same way as recipes or bbclass files Jul 15 09:45:09 hello pb_ Jul 15 09:45:46 heh, funnily enough I just patched my setup yesterday to make meta-oe lower priority than oe-core Jul 15 09:45:52 ildar: I would certainly love to see h3900 fully working with a modern kernel; I have several of them Jul 15 09:45:53 lol Jul 15 09:46:08 pb_: why especially? is there something in meta-oe you don't want? Jul 15 09:46:12 or didn't want? Jul 15 09:46:35 bluelightning: I was just a bit fed up with "unexpectedly" getting a version of a recipe from meta-oe rather than the one from oe-core Jul 15 09:46:47 imagine a class :/ Jul 15 09:46:50 I can't remember offhand which one it was that tipped me over the edge Jul 15 09:47:27 it is a bit infuriating that meta-oe duplicates so many recipes from oe-core, often without (as far as I can tell) any good reason Jul 15 09:48:09 well now that bitbake-layers provides an easy way to show overlayed recipes I hope it can be used to find those that need tidying up Jul 15 09:48:42 it doesn't show overlayed classes though, and frankly those ought to be kept to a bare minimum Jul 15 09:49:15 as a general rule, I only want to use something from meta-oe if the recipe doesn't exist (or isn't usable for some reason) in oe-core Jul 15 09:49:28 what is missing in oe-core's kernel.bbclass? some uboot magic? Jul 15 09:49:55 ant_work: the differences are pretty minor last I checked Jul 15 09:49:59 let me compare again Jul 15 09:51:26 pb_: I think meta-oe was an initial proof-of-concept promoted to real layer Jul 15 09:52:00 yeah, possibly Jul 15 09:52:04 afaik koen was working around gnome Jul 15 09:52:15 a bit of find | cut | sed | sort | uniq suggests that there are currently 70 recipes in both meta-oe and oe-core Jul 15 09:52:40 including binutils, gcc-cross, glib-2.0 and a bunch of x11 stuff Jul 15 09:53:10 and, bizarrely, abiword Jul 15 09:53:28 hmm. gnome-image? Jul 15 09:53:28 oh, no, that's not in oe-core proper, it's only in demoapps Jul 15 09:54:10 gnome-image is not one of them Jul 15 09:54:14 gnome-desktop is, though Jul 15 09:54:20 if I filter out meta-demoapps then it's down to 49 duplicates Jul 15 09:55:42 oh, I think openssl was the one that annoyed me enough to demote meta-oe Jul 15 09:56:33 the one in meta-oe is older and more broken than the one in oe-core, afaict Jul 15 09:57:20 Main layer maintainer: Koen Kooi Jul 15 09:57:34 Send pull requests to openembedded-devel@lists.openembedded.org with '[meta-oe]' in the subject' Jul 15 09:57:40 ok, lets' flood Jul 15 09:58:59 good news are it is actively maintained :) Jul 15 09:59:00 let's focus on kernel.bbclass for a moment Jul 15 09:59:52 http://pastebin.com/R1Wuhut2 Jul 15 10:00:20 bluelightning: I can say I deleted the one in meta-oe and could build just fine my kernel + console-image last night Jul 15 10:00:30 now, there are some bits that are obviously out of date in the meta-oe version wrt recent patches in oe-core Jul 15 10:00:59 right Jul 15 10:01:03 plus the hated M_K_PR Jul 15 10:01:11 s/hated/hated (by me)/ Jul 15 10:01:37 what is the purpose of that? for the uninitiated Jul 15 10:01:46 what about the uboot_mkimage() stuff, do you know what that's for? Jul 15 10:02:10 bluelightning: basically a way to get versioning synchronisation for out-of-tree modules when the kernel changes Jul 15 10:02:25 which is, admittedly, a problem. I just happen to think that M_K_PR is a poor solution for it. Jul 15 10:02:37 pb_: is there an alternative solution? Jul 15 10:02:46 in particular, M_K_PR assumes a 1:1 correspondence between MACHINEs and kernels Jul 15 10:03:30 bluelightning: there was a fairly lengthy thread on the mailing list at the time this was first landed in oe.dev Jul 15 10:03:50 if you search for a large thread with a subject along the lines of "all kernel modules broken now" then I think you will probably find it Jul 15 10:03:54 let me see if I can track it down Jul 15 10:04:06 I vaguely remember that Jul 15 10:04:29 http://comments.gmane.org/gmane.comp.handhelds.openembedded/24048 Jul 15 10:04:30 I think Jul 15 10:05:56 pb_: this uboot_mkimage() was in linux.inc Jul 15 10:06:15 I must say that the whole kernel class thing in oe-core is pretty confusing too Jul 15 10:07:03 we seem to have linux-kernel-base.bbclass, kernel.bbclass, kernel-arch.bbclass, kernel-yocto.bbclass, and possibly a few more as well Jul 15 10:07:23 then of course in recipes/ there is linux-yocto.inc and, finally, linux-yocto_2.6.37.bb Jul 15 10:07:37 pb__ fwiw uboot_mkimage had to be overwritten for mipsel target :p Jul 15 10:07:39 it isn't entirely clear to me how much of that stuff is genuinely yocto specific and how much is/could be generic Jul 15 10:09:26 back in a moment, restarting gnome Jul 15 10:09:27 (again) Jul 15 10:11:13 re Jul 15 10:11:17 that's better Jul 15 10:11:22 * pb_ in "fallback mode" now Jul 15 10:11:40 and emacs works again, hurrah Jul 15 10:13:33 bluelightning: h3900 work with agstrom Jul 15 10:13:51 ildar: how well though? Jul 15 10:13:53 and, as he wrote: everything like touchscreen ,SD card ,LCD is OK. Jul 15 10:14:03 bluelightning: pls keep addtask menuconfig after do_configure Jul 15 10:14:04 ildar: what about battery management? Jul 15 10:14:11 well enough for testing Jul 15 10:14:16 yeah Jul 15 10:14:34 that's why I want those 2.4 patches Jul 15 10:14:46 crumbs, is h3900 still using 2.4? Jul 15 10:14:49 ildar: right, ok Jul 15 10:14:59 batt and mtd Jul 15 10:15:05 pb_: not really, but 2.6 never made it to full support :( Jul 15 10:15:07 in my focus Jul 15 10:15:15 bluelightning: doh Jul 15 10:15:44 I thought it was basically all done, but maybe I am remembering wrong Jul 15 10:15:50 pb_: IIRC you did quite a lot of the original kernel work for h3900, right? :) Jul 15 10:15:59 I had GPE2 with k-2.6 booted 2 years ago Jul 15 10:16:08 yeah, I did the h3900 and h5400 ports back in the day Jul 15 10:16:50 whoa! pb_! Jul 15 10:16:53 for 2.4 originally, but I remember jamey and I spent quite a long time rewriting most of that stuff for 2.6 Jul 15 10:17:09 can you help with porting drivers? Jul 15 10:17:33 pb_: thinking about it, I wouldn't be here now if it weren't for that work, so thanks very much :) Jul 15 10:17:33 but then I think we had this problem with the soc bus not being politically acceptable upstream, and I think that was around the time that the wheels started to fall off the handhelds.org wagon, and I guess it all went to pieces a bit Jul 15 10:17:34 oouh :( Jul 15 10:18:05 oh, and I guess hp closed crl, that didn't help either. heh. Jul 15 10:18:14 yeah, a lot of stuff happened Jul 15 10:18:45 ildar: I don't really have time to do any heavy driver porting at the moment, but if you have a particular problem then I might be able to help you with it Jul 15 10:18:53 pb_: do you have those drivers? Jul 15 10:18:56 great Jul 15 10:19:05 that makes the deal Jul 15 10:19:07 :) Jul 15 10:19:26 what, the old 2.4 ones? I probably have them lying around on an old tree somewhere, though not anywhere I can lay muy hands on this minute Jul 15 10:19:32 still I'm complete noob in kernel source :( Jul 15 10:19:46 that's ok Jul 15 10:19:50 I'll wait Jul 15 10:19:52 ildar oha Jul 15 10:20:03 I plan my vacations in 1 week Jul 15 10:20:21 so I could do some porting work Jul 15 10:20:40 okay, very good Jul 15 10:20:45 :) Jul 15 10:20:45 what is missing in 2.6 at the moment, then? Jul 15 10:20:57 mtd and battery Jul 15 10:21:03 and sound Jul 15 10:21:14 ah Jul 15 10:21:24 ildar: sound ought to be easy... the chips are supported AFAIK, probably just need the glue Jul 15 10:21:28 well, mtd is fairly trivial, nothing very h3900 specific there except the write protect Jul 15 10:21:36 yeah, I guess so Jul 15 10:21:42 right Jul 15 10:21:48 battery is basically just the 1-wire bus, you need the asic2 w1 master and then you should be all set Jul 15 10:21:49 has anyone seen an errors with console-image and /etc/init.d/rc like this: http://pastebin.com/3J6xwLm5 , I pulled top of oe git, b59743b9136df1f427b1bd1ae260c8f30ab6e880 , and built console-image rootfs, it doesn't seem to boot correctly for me Jul 15 10:22:11 sound, dunno, all crazy alsa stuff. lrg would be your resource for that. Jul 15 10:22:18 so I plan to have a well-supported device by the end of my vacations :) Jul 15 10:22:33 ildar: awesome :) Jul 15 10:22:51 still I can't promise Jul 15 10:23:06 I said, I'm a newbie Jul 15 10:23:10 no, but at least having someone looking into it is a good thing Jul 15 10:23:20 and fun Jul 15 10:23:22 :) Jul 15 10:23:38 yeah, it would be neat to have the h3900 supported again. I was actually quite fond of that device. Jul 15 10:24:09 being able to plug in not one but two PCMCIA cards was what sold me on it originally Jul 15 10:24:18 one difference between my old oe which worked and my current oe is that the old oe used glibc , new oe uses eglibc , but no idea why that would break since whole rootfs comes from new oe Jul 15 10:24:32 of course the CF sleeve didn't support cardbus, but it was still cool Jul 15 10:24:39 yeah Jul 15 10:24:41 er, the PC card sleeve Jul 15 10:24:55 right, no cardbus on pxa obviously Jul 15 10:25:22 yes Jul 15 10:25:22 yeah, Cardbus is completely different thing. 32 bit Jul 15 10:25:26 only pcmcia Jul 15 10:26:11 htns: looks like something is corrupted :( Jul 15 10:27:08 ok, then. my email is ildar.mulyukov@gmail.com in case you have something for me Jul 15 10:27:16 thanks a lot Jul 15 10:27:32 ildar: ok, will let you know Jul 15 10:27:55 bluelightning, i thought that too. so i did mv tmp/downloads downloads.bk ; rm -rf tmp ; mkdir tmp ; mv downloads.bk tmp/downloads ; bitbake console-image Jul 15 10:27:59 * ildar nodes Jul 15 10:28:00 and got the same result Jul 15 10:28:08 pb_: you remember that KLIBCSTRIP, ok, I fixed that. Now the recipe spits out QA about unpackaged .dbg packages :p Jul 15 10:30:00 htns: what does /etc/init.d/rc contain in the rootfs you have built? any clues there? Jul 15 10:33:23 bluelightning, yup, i thought that too, i unpacked my rootfs tarball and also did the same check on the SD card with my rootfs, in both /etc/init.d/rc is fine. line 1 is #!/bin/sh so i suspect some linker issue based on the libnss_compat issue. i saw from the log it is looking for nss compat -2.9 . rootfs tarball only has -2.12 Jul 15 10:34:32 bluelightning: and pb_: well, it looks battery is already there: http://mink365.googlecode.com/files/h3900-28-all.diff Jul 15 10:35:29 ildar: there's code in there, question is does it work? Jul 15 10:36:13 htns: this is not something I'm familiar with I'm afraid, I'd suggest a post to the mailing list if noone else is able to help here Jul 15 10:38:15 oh yeah, asic3 has onewire as well Jul 15 10:38:35 I don't quite remember which one is used on h3900. I have a vague recollection that h3800 used asic2 onewire (and asc1 didn't have it) but h3900 used asic3 onewire. Jul 15 10:38:42 bluelightning, thanks, i will retry my build on older ubuntu, was using 11.04, maybe will retry on 9.10 to see if that changes anything Jul 15 10:38:57 some experimentation maybe needed, or check old 2.4 sources to see what happened there Jul 15 10:39:13 htns: shouldn't make a difference, lots of people are using 11.04 (I am here although not for regular builds) Jul 15 10:39:17 I did have battery working on one of the pxas under 2.6 but I think it might have been h5400 not h3900 Jul 15 10:39:47 bluelightning, ok, thx, are you on x86-64 or 32-bit? Jul 15 10:39:56 htns: 32-bit for the ubuntu machine Jul 15 10:40:04 h5400 onewire is in samcop, so different again. I don't remember if it's compatible with asic2/asic3 or not. Jul 15 10:40:19 bluelightning, maybe i should try 32-bit , i am on ubuntu 64 bit Jul 15 10:40:34 htns: shouldn't make a difference especially at boot stage on the target Jul 15 10:40:47 yeah, I use ubuntu 11.04 on 64-bit, doesn't seem to be a problem Jul 15 10:40:49 there are others using 64-bit ubuntu 11.04 without issues Jul 15 10:40:55 right, there you go :) Jul 15 10:41:09 bluelightning, you are right, i'm stuck though, no other ideas :) Jul 15 10:41:29 distro-specific issues almost always crop up quite early during the build Jul 15 10:41:38 (if they are present) Jul 15 10:42:11 what target is this, qemusomething? Jul 15 10:44:16 htns: ^ ? Jul 15 10:44:45 pb_, i'm using a sheevaplug like target, so machine = kirkwood Jul 15 10:45:07 can you reproduce it with qemu and a known-working kernel? Jul 15 10:45:51 if I had to guess I'd say this was a kernel bug of some kind, particularly if your rootfs is on flash or something Jul 15 10:46:30 if I didn't have to guess then I suppose I would boot with init=/bin/sh and inspect the situation manually Jul 15 10:46:37 pb_, yup, i can. i initially started with 2.6.34 with working rootfs using OE top of tree as of 0997ea806990cf918c08326032281db8fbdedd77 . on that rootfs works fine Jul 15 10:47:22 using same 2.6.34 kernel and switching only rootfs to OE top of tree as of b59743b9136df1f427b1bd1ae260c8f30ab6e880 then rootfs fails Jul 15 10:48:01 the other difference is that the old OE tree was built on ubuntu 9.10 32-bit , whereas my new tree is built on ubuntu 11.04 64-bit Jul 15 10:48:38 well, if you have two rootfs images, one of which works and one of which fails under identical conditions, can you just diff them and see what has changed? Jul 15 10:49:21 but I would still recommend that you try to reproduce it in qemu to rule out broken hardware or broken kernels Jul 15 10:49:36 the fact that your hardware happened to work with the old rootfs doesn't necessarily guarantee that it is operating correctly Jul 15 10:49:49 pb_, good point, i didn't try that. i assumed there would be massive differences. the old OE is from June 4, 2010, new OE is from July 13 Jul 15 10:50:01 admittedly, there is no guarantee that the qemu kernel is operating correctly either, but at least it is worth a try Jul 15 10:50:39 pb_, i've been using this hardware with 2.6.34 and old rootfs for about 6 months :) i'm suspecting software issues on my side rather than hardware Jul 15 10:51:35 evidently :-} Jul 15 10:51:54 sorry, that's a bit imprecise on my part, i was using 2.6.28 and old rootfs for about 6 months, then switched to 2.6.34 about 2 weeks ago, then found that 2.6.34 had problems with wpa supplicant from old OE, so decided to try new OE to get new wpa supplicant :) Jul 15 10:52:39 okay Jul 15 10:52:50 then encountered my current boot issues, http://pastebin.com/3J6xwLm5 , ok, that's my life story done :-) Jul 15 10:53:01 well, this is all just speculation really. it still sounds to me as though the most likely cause is a kernel bug, but I think you are going to have to try some things to narrow it down a bit further. Jul 15 10:53:07 htns whats your device? Jul 15 10:53:16 woglinde, it is a sheevaplug based device Jul 15 10:53:21 hm Jul 15 10:53:31 so you need a special kernel Jul 15 10:53:33 if it's straightforward to boot your rootfs under qemu then do that and see what happens. Jul 15 10:53:56 htns you could try narcissus too Jul 15 10:53:59 pb_, i thought that it might be the kernel too, but then i realized, hey, old rootfs works fine with that kern Jul 15 10:53:59 to build an image Jul 15 10:54:10 if it's not straightforward to do that, then you will have to make a value judgement about whether it's worth spendign the time or not. if not, then as I said before I would boot with a shell and inspect the running system by hand Jul 15 10:54:10 http://narcissus.angstrom-distribution.org/ Jul 15 10:54:33 woglinde, good point, i should try a prebuilt rootfs, then i will know if it is my build environment that is at fault Jul 15 10:54:59 htns you maybee have to exchange the kernel Jul 15 11:06:43 pb_, thanks, i like the idea of init=/bin/sh so i am now booted and have a shell. i see /dev/ has what looks like reasonable entries. http://pastebin.com/fkYTJkB8 not sure if /dev/initctl should exist Jul 15 11:15:09 hmm, oh wow, i used woglinde's idea of the narcissus sheevaplug rootfs, and it boots perfectly fine, http://pastebin.com/6zN9sUvE , i have my console now Jul 15 11:16:26 oh, very good Jul 15 11:17:12 argh, :-) , console image doesn't have wpa_supplicant . hehe, ok, time for beer , will try to test wpa on weekend Jul 15 11:29:37 htns lol include wpa Jul 15 11:30:03 pb_: do you think PACKAGES_DYNAMIC could help me to avoid to list of binaries here? What about FILES_ ? http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/klibc/klibc-utils.inc Jul 15 11:30:52 (the RDEPENDS cruft is already under attack) Jul 15 11:31:06 ant_work: try do_split_packages() Jul 15 11:32:20 I'll have to add globs for -dbg Jul 15 11:32:32 I can't think of relisting those Jul 15 11:33:49 ah, I see, regexp Jul 15 12:47:21 hmm, I'm not sure how to merge this do_uboot_mkimage() change Jul 15 12:48:13 it doesn't look like it's going to result in the same thing as the code in oe-core in kernel_do_deploy(), plus we've made our own changes to that Jul 15 12:48:53 someone who understands this better will have to do it I think (along with describing the change better, the commit message in oe-dev is not very useful) Jul 15 13:23:18 bluelightning: fwiw here a custom version for mipsel http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-kexecboot.inc?h=org.openembedded.dev Jul 15 13:24:15 iirc there was too much bloat in linux.inc so the task was moved to kernel.bbclass. Jul 15 13:24:57 now we face the same with kernel.bbclass Jul 15 13:27:11 ant_work: this is an area that is fairly new to me, so I'm not necessarily in the best position to suggest major layout changes that might address that Jul 15 13:27:33 it all depends on your KERNEL_IMAGETYPE Jul 15 13:27:46 if uImage then it triggers that code Jul 15 13:28:11 but yes, it's easy to break :) Jul 15 13:29:28 ant_work: looks like pb_ has posted something to the mailing list, let's see what comes out of that Jul 15 13:29:48 I'm trying to fish koen with that lure Jul 15 13:30:06 meybe he's on biz trip Jul 15 13:56:57 how people use nfs in sdks nowadays Jul 15 13:58:22 ? Jul 15 13:58:40 mwester-laptop: thanks Jul 15 13:58:50 For what? Jul 15 13:59:18 mwester-laptop: adding that missing question mark Jul 15 13:59:27 :D Jul 15 13:59:51 Actually, I was not addign the missing puncuation, I was wondering if Otavio could clarify the question.... Jul 15 14:07:12 I am looking to where it "exports" the rootfs and like so I can look how it does it Jul 15 14:13:17 otavio: Well, oe-core has some slick user-space nfs server magic Jul 15 14:13:32 Which has been a wishlist item for some of us for like 10 years+, heh Jul 15 14:14:27 http://dilbert.com/strips/comic/2011-07-15/ Jul 15 14:25:56 Tartarus: slick user-space? hum, knows where it can be found there? Jul 15 14:26:07 scripts/ Jul 15 14:26:12 the qemu scripts use it Jul 15 15:07:23 bluelightning: koen is alive, just he'd move the cruft from oe-core in meta-oe Jul 15 15:07:39 I hope I misunderstood Jul 15 15:17:41 ant_work: I'm not sure I understand either Jul 15 16:15:53 bbl Jul 15 16:27:15 03Howard D. Gray  07org.openembedded.dev * r348bd8209b 10openembedded.git/recipes/usb-gadget-mode/ (files/usb-gadget usb-gadget-mode.bb): Jul 15 16:27:16 usb-gadget-mode: add support for multi gadget Jul 15 16:27:16 This adds support for using the multi gadget ("g_multi" kernel module) Jul 15 16:27:16 as the default USB gadget mode. Jul 15 16:27:16 Signed-off-by: Howard D. Gray Jul 15 16:27:16 Signed-off-by: Koen Kooi Jul 15 16:27:23 03Joel A Fernandes  07org.openembedded.dev * r93e91091c7 10openembedded.git/recipes/linux/ (2 files in 2 dirs): (log message trimmed) Jul 15 16:27:23 linux-omap-psp: Added patch to fix MMC timeout errors Jul 15 16:27:23 This fixes MMC errors due to timeouts, and is borrowed from Steve Sakoman's patch for the Jul 15 16:27:23 linux-omap-2.6.39 recipe (as noticed by Jason Kridner) Jul 15 16:27:24 Details of the issue: Jul 15 16:27:24 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42214.html Jul 15 16:27:25 Signed-off-by: Joel A Fernandes Jul 15 16:27:25 03Koen Kooi  07org.openembedded.dev * ra4e41b90ec 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jul 15 17:04:21 kergoth: have you worked much/more with GitPython? Jul 15 17:04:51 it seems pretty rough at best... Jul 15 17:05:02 how so? Jul 15 17:05:31 I have had quite some trouble making it work, and cannot find any commits since january Jul 15 17:05:50 is it an abandoned tool? Jul 15 17:06:27 they fixed bugs i reported a week and a half ago. Jul 15 17:06:31 so.. not that i can tell Jul 15 17:06:46 https://github.com/gitpython-developers/GitPython/issues/25 Jul 15 17:07:03 k Jul 15 17:07:47 https://github.com/gitpython-developers/GitPython/commits/master Jul 15 17:08:15 argh, I seem to have switched GitPython for python-git Jul 15 17:08:40 yep, those are two completely different projects Jul 15 17:09:21 having difficulty figuring out what package is providing /var/run on my image - grep /var/run from /usr/lib/opkg/info/* tells me its base-files, yet base-files ipk clearly has run symlinked to volatile/run and thats not whats on my filesystem - any ideas? Jul 15 17:09:32 esbenh: https://gist.github.com/44477bb3c0d9caa0c030 - i admit the way the commands are done is rather messy, but that's functional code using gitpython Jul 15 17:10:13 its obviously coming from another packages file contents or postinst script but not clear why a 'grep run /usr/lib/opkg/info/*' doesn't show that Jul 15 17:10:56 kergoth: I'll give it one more look Jul 15 17:11:04 have to take care of the cooking right now though... Jul 15 17:11:08 hehe Jul 15 17:11:11 I sense smoke.... Jul 15 17:11:20 * kergoth is eating eggs at the moment, decided to do a proper breakfast for once Jul 15 17:12:45 wouldn't take much to refactor this to separate out the UI/command stuff, get a core that just has basic add to/update cache, and clone with/without cache operations Jul 15 17:12:55 think that'd be all we'd need to have a functional git fetcher Jul 15 17:14:30 interesting, in the gitpython commits there's branches for pygit2 / dulwich Jul 15 17:14:41 so maybe you can plug in alternative implementations behind its api Jul 15 17:14:45 that'd be cool Jul 15 17:22:35 hey guys, I have some trouble setting up my touchscreen: ts_calibrate segfaults or complains the devices I pass are no touchscreen devices oO Jul 15 17:23:14 what version of tslib? Jul 15 17:23:46 uhm ts-lib segfaults Jul 15 17:24:04 * kergoth__ 's never seen or heard of a tslib segfault Jul 15 17:24:20 the not a touchscreen device thing depends on the kernel you're running vs the kernel you built tslib against, but using master may help Jul 15 17:24:25 args yes calibrate program Jul 15 17:34:23 kergoth: libts-0.0-0 1.0-7em1 Jul 15 17:34:37 no clue what that is Jul 15 17:34:41 but try the current version in git Jul 15 17:41:14 when it says "selected device is not a touchscreen I understand" does that mean it's lacking the settings or is the raw input unreadable? Jul 15 17:44:08 no, it means the input layer event interface version doesn't match what we expect, most likely Jul 15 17:44:48 kergoth: mh... as i expected... the touchscreen-device isn't mapped to /dev/input* either, it shows up as /dev/touchscreen-1wire Jul 15 17:48:42 kergoth: dulwich is currently git and hg AFAIK Jul 15 17:49:04 would be nice to have a similar solution to hg fetching Jul 15 17:49:15 dFence: hm, don't know offhand then Jul 15 17:49:26 esbenh: yeah, hg and git are *so* similar. I don't know hg all that well personally though Jul 15 17:52:10 i have only used hg very little, but believe that it is very similar to git Jul 15 18:06:59 kergoth: OK, I got it to work now - ts_calibrate responds (a bit too jumpy for my taste, but later..) -- but when I start X the ts doesn't respond Jul 15 18:07:25 how you have your X getting ts stuff is something I have no clue about Jul 15 18:11:26 CRAP Jul 15 18:11:32 just rm -rf'd a good 45 minutes of work Jul 15 18:11:34 i hate that :| Jul 15 18:12:04 thank goodness for vim backup files Jul 15 18:17:35 kergoth: time for a break ;-) Jul 15 18:25:12 kergoth: http://pastebin.com/aUFHkqkL Jul 15 18:25:43 esbenh: usually indicates manual use of a config reader/writer along with internal use, so there's a locking conflict Jul 15 18:25:57 working on that code right now Jul 15 18:26:00 give me a few Jul 15 18:26:17 note the use of the config writer object, but Remote.create() wants to write to the config file too Jul 15 18:26:20 hence the problem there Jul 15 18:26:35 you can change the cfg.set()'s to remote.config_writer.set(), and drop the first argument in those calls Jul 15 18:26:45 (tehre was a bug in remote.config_writer when I wrote that code) Jul 15 18:32:50 bah, they didn't fix all of the bugs I reported Jul 15 18:33:27 AttributeError: 'CmdFetchInfo' object has no attribute 'old_commit' Jul 15 18:34:01 i know Jul 15 18:34:06 they changed that part of the api Jul 15 18:34:13 when I wrote that, it was against the last release.. Jul 15 18:34:27 I'm about to commit a refactored version that works with master Jul 15 18:34:53 ok, I will not try to duplicate your effort then :-) Jul 15 18:36:45 esbenh: pull Jul 15 18:39:16 I'm sure there's room for improvement, but that Fetcher class probably does what you want Jul 15 18:39:39 setup_cache() and download() being the useful methods Jul 15 18:42:31 the one gripe I have with GitPython right now is its handling of the git config files Jul 15 18:42:53 it uses ConfigParser, which has problems in multiple ways with git's config file format Jul 15 18:43:06 - git allows multiple entries with the same key, ConfigParser does not Jul 15 18:43:15 - ConfigParser doesn't appear able to handle line continuation with \ Jul 15 18:43:45 been bit by both of those with this.. my ~/.gitconfig gets parsed if I use Repo.clone_from() to implement the direct clone, and it explodes Jul 15 18:43:52 thats' why the direct clone sets it up manually instead Jul 15 18:48:54 kergoth: add is broken, calls fetcher.update_cache() which has been dropped Jul 15 18:52:57 ah, just a rename. just needs to run setup_cache() Jul 15 18:53:31 fixed Jul 15 18:55:30 I think it would be useful to be able to give the cache argument to Fetcher.__init__ as the full path to the cachedir Jul 15 18:55:39 ie. not having urlbase+".git" added Jul 15 18:55:39 the other thing to think about is how to go about populating mirrors. my thought is, have a separate method for that on the fetcher to take the bits for that url from the cache and ensure tehy're in the necessary format for use as a mirror Jul 15 18:56:12 in this case, we can create a bare repo thats a mirror of upstream Jul 15 18:58:06 what exactly do you mean with mirror there? we have upstream repos, cachedir repos, and download repos Jul 15 18:58:19 i mean like sources.openembedded.org. Jul 15 18:58:29 the repo in the cache dir isn't suitable as is, since it holds multiple remotes per repo Jul 15 18:58:44 thats assuming you want to be able to mirror git repositories without using an intermediate tarball the way oe does Jul 15 18:59:10 why not just use some of the existing git mirror setups? Jul 15 18:59:19 ? Jul 15 18:59:24 no clue what you're talking about Jul 15 18:59:41 we already have the objects in the cache, why would you re-clone from upstream to get a mirror repo? Jul 15 18:59:46 fx. repo.or.cz Jul 15 19:00:04 so no one will ever want to create their own mirrors? Jul 15 19:00:12 nearly every company wants their own source mirror Jul 15 19:00:16 I doubt that'll be changing anytime soon Jul 15 19:00:26 yes, but not from directly within their build environment Jul 15 19:00:50 I don't see how it would be done otherwise. magic? squid? Jul 15 19:01:30 and you'd rather re-download everything from upstream than use the existing cache to populate it? Jul 15 19:01:33 I'm not seeing the logic Jul 15 19:01:34 we must not be talking about the same problem here... Jul 15 19:01:47 I'm talking about setting up a directory that you can point the fetchers at instead of upstream Jul 15 19:01:50 I do builds on my laptop mostly Jul 15 19:01:55 yes, and? Jul 15 19:02:07 I have a server which holds a number og git mirrors Jul 15 19:02:23 I'm talking about taking the metadata and using it to populate a mirror of everything that can be fetched Jul 15 19:02:39 it just pulls the remote mirrors once in a while witn cron Jul 15 19:03:03 I don't see how manually maintaining mirrors is an improvement over using the knowledge in the metadata Jul 15 19:03:09 there's a reason most people use -c fetchall to set up mirrors with oe Jul 15 19:03:35 Ah, now I follow. Jul 15 19:03:36 I dont use it Jul 15 19:03:43 I'm talking about fetching of sources for recipes, not the up front fetch of your layers Jul 15 19:03:51 yes, it would be nice to have the git repos supported in same way Jul 15 19:04:18 since the caching mechanism is implemented per fetcher, I think it makes sense to implement mirror population as a part of that Jul 15 19:05:21 woglinde_: well, nearly everyone still uses the metadata to fetch, was the point. fetchall is a bad example since it doesn't hit every recipe, only the current preferred providers Jul 15 19:05:55 perhaps make a seperate bitbake task for it, mirroring from upstream and the cache to a specified mirror location in the proper format, which i know see is what you were getting at from the beginning Jul 15 19:07:01 in the case of something like git, there has to be a difference between download and mirror, since the mirror needs to be a bare repo and stores the refs locally rather than in a remote Jul 15 19:07:17 so yeah, that was the point, that we should separate logically download from mirror, as operations Jul 15 19:07:44 something like git clone --mirror --reference cache.git git://host.com/upstream.git /path/to/our/mirror.git Jul 15 19:08:16 well, the reference is no good of-course... Jul 15 19:08:20 yeah, exactly. though we could add an option to use hard links rather than reference, to make it fully standalone, now that I think about it :) Jul 15 19:08:22 * kergoth nods Jul 15 19:08:42 rm -rf'ing the cache would destroy the mirror, wouldn't it? Jul 15 19:08:53 if we used reference, yeah Jul 15 19:10:57 will we be able to store tags properly in a shared cache repo? Jul 15 19:11:03 it does Jul 15 19:11:12 all refs go into the per-url remote, including tags Jul 15 19:11:24 then it pulls them into the correct locations when cloning from it (refs/tags, refs/heads) Jul 15 19:11:50 remote.config_writer.set('fetch', '+refs/*:refs/remotes/%s/*' % name) Jul 15 19:11:50 remote.config_writer.set('tagopt', '--no-tags') Jul 15 19:12:05 it's doing --no-tags here to make sure itd oens't fetch any to refs/tags/, since we don't want any there in the cache repo Jul 15 19:12:32 I thought the --no-tags made the remote not fetch tags Jul 15 19:12:54 it does, but its fetching them anyway. Jul 15 19:12:55 ah, that was my point Jul 15 19:12:57 note: refs/* Jul 15 19:12:59 not refs/heads/* Jul 15 19:13:12 tags are just refs stored in refs/tags/ rather than refs/heads/ Jul 15 19:13:23 annotated tags are refs stored there pointing at tag objects rather than commit objects Jul 15 19:13:36 ok, so we have refs/remotes/foobar/heads/* and refs/remotes/foobar/tags/* Jul 15 19:13:40 exactly Jul 15 19:13:45 great Jul 15 19:15:14 won't it be possible to make a bitbake task which populates/updates a mirror using the cache repo, calling it after do_fetch, but not before do_build, as we don't want to update mirrors on every build Jul 15 19:16:02 yeah, that seems sane to me Jul 15 19:16:38 oh, suppose we need to make sure download() doesn't update the cache, since we want the unpack operation to stay offline Jul 15 19:16:51 so it should error out if it's not already in cache, rather than init/updating it there Jul 15 19:17:32 at least for your use case :) Jul 15 19:17:35 yes, no reason for download() to use network access Jul 15 19:18:49 that's a couple line change, just drop the setup_cache() call from download() in favor of a check / error if it doesn't exist, or just punt and let it fail if it doesn't exist in the clone code Jul 15 19:19:27 for my cache script, I do a lot more url sanitization Jul 15 19:19:43 e.g. making sure i always use git:// or http:// or whatever for specific servers, to avoid accessing the same repo via multiple mechanisms Jul 15 19:19:49 but i doubt thats needed for your usage Jul 15 19:20:16 (I cron job a git cache update daily, so my actual clones go quicker during the day) Jul 15 19:20:32 nice Jul 15 19:20:56 its useful for things like clones of oe/bitbake/oe-core/etc.. i do a lot of those when setting up seperate project areas Jul 15 19:21:06 oh, thats another thing that I need to add to this -- submodule / recursive clone Jul 15 19:21:14 want to make sure submodules are set up using the cache too Jul 15 19:28:10 esbenh: a more simplistic approach (e.g. for hg) might be to just turn the url into a path, replacing invalid chars, clone to that in the cache dir, then for unpack, clone from that, potentially changing the url back to upstream after the clone. thats what I did for my first implementation of the git cache. don't need to poke at so many internal things Jul 15 19:30:55 esbenh: where's the current fetcher code for oe-lite at? you guys have so many repositories, I never remember which I need :) Jul 15 20:00:42 reported another gitpython bug Jul 15 20:00:44 heh Jul 15 20:00:54 he really needs to rework all that ref handling code Jul 15 20:01:24 a ref is a ref is a ref, they aren't special. tags don't need special handling unless its a ref pointing to an annotated tag object -- that is, the ref doesn't change, what it points to might not be a commit Jul 15 21:16:22 fray: could your adduser stuff have broken zap_root_password? Jul 15 21:55:55 htns: your problems could be udev related Jul 15 21:56:14 * khem was skimming through channel log Jul 15 21:58:30 a year of changes between working and not working revs Jul 15 21:58:32 heh Jul 15 21:58:42 go figure Jul 15 21:58:56 heh Jul 15 21:59:22 and tree is not bisectable Jul 15 21:59:36 and oe.dev it does not matter if its bisectable or not Jul 15 21:59:54 unless one is ready to build from scratch everytime Jul 15 22:04:42 great, got OE-lite building with a slightly modified version of git_cache.py Jul 15 22:04:54 thanks :-) Jul 15 22:10:36 esbenh: nice Jul 15 22:10:56 yep, now I just need to sort out signature handling Jul 15 22:12:09 and.... I need to give both a tag, commit-id, or branch name to download() Jul 15 22:12:27 for commit-id, I can just use commit-id as signature Jul 15 22:13:11 for tag, I need to lookup the tag, and use the commit-id it refers to as signature, but this needs to be stored away, as I need the signature already when constructing the runqueue Jul 15 22:13:31 rev-parse will take a ref or id and give you an id, can do the same thing regardless of what it is Jul 15 22:14:43 for branch src_uri's, I think I will not even bother, it is just plain dirty, and only to be used when debugging the component represented by the recipe Jul 15 22:15:13 kergoth: yes, I know, I just need to find a good way to handle recipe persistent state. Jul 15 22:15:17 ah, yes Jul 15 22:15:34 but first, need to get some sleep, and then family stuff all day tomorrow. Jul 15 22:15:42 good plan. night Jul 15 22:15:47 me too Jul 15 22:15:52 but no family stuff Jul 15 22:15:56 good night Jul 15 22:15:57 night Jul 15 22:50:48 anyone know where the source to /lib/ld-linux.so.2 is? i gather it's part of (e)glibc, but i'm not seeing exactly where ld-linux.so is built there Jul 15 22:52:36 i'm trying to understand more precisely what happens when linux sees the path to the loader in .interp in an ELF binary Jul 15 22:52:58 *to the linker Jul 15 22:54:14 btw, any bitbake guru online? Jul 15 22:54:49 I insist to cause "OSError: [Errno 1] Operation not permitted: " Jul 15 22:55:09 ERROR: Function 'fixup_perms' failed Jul 15 23:03:34 the error is caused by a dangling symlink Jul 15 23:03:47 I have a fix for fixup_perm -- but that just masks dangling symlinks in packages Jul 15 23:03:57 hm.. let me check Jul 15 23:04:11 http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=mhatle/ml&id=5cdb49fa75f53cb1dc43ab5517c87d29bd918e9a Jul 15 23:04:24 I havn't sent it for review yet.. if it works for you, feel free to pass it along.. Jul 15 23:04:25 ah, one ln -sf ${STAGING_KERNEL_DIR} linux Jul 15 23:04:52 I'll test it right now Jul 15 23:10:05 it seems I have a different package.bbclass in oe-core Jul 15 23:12:37 patch applies @637 Jul 15 23:14:05 fray: did not help in my case :/ Jul 15 23:14:49 http://paste.debian.net/123053/ Jul 15 23:18:03 it broke earlier in then the patch I posted.. Jul 15 23:18:15 add the if line above that fix_perms Jul 15 23:19:44 unfortunately not, retried twice Jul 15 23:20:11 maybe the path is too long.... Jul 15 23:20:57 if you look at "def fix_perms(path, mode, uid, gid, dir): Jul 15 23:21:08 you'll see a commented out "bb.note".. uncomment that and we'll know what it was tyring to do Jul 15 23:21:36 sure Jul 15 23:25:04 I don't see the note, looking in the logs Jul 15 23:25:18 it'll be in the log.do_package for that package Jul 15 23:26:07 NOTE: Fixup Perms: chown 0:0 /oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/poodle-angstrom-linux-gnueabi Jul 15 23:26:24 show me an "ls -Fld" on that file Jul 15 23:26:52 fray: any idea if the adduser/etc stuff could have broken zap_root_password? Jul 15 23:27:19 I don't think it would have.. but it's possible the default passwd file somehow got a "*" in the password field or something Jul 15 23:28:01 drwxr-xr-x 2 andrea users 4096 Jul 16 01:18 /oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/poodle-angstrom-linux-gnueabi// Jul 15 23:28:16 fray, k, thanks Jul 15 23:28:57 fray, too busy / friday'd to peek at it, i guess? :) Jul 15 23:29:00 ant__ it looks to me that whatver is runnign the do_package operation isn't running in pseudo mode.. Jul 15 23:29:13 Tartarus I've got to get the tuning re-do done so RP can look at it.. or would Jul 15 23:29:17 k Jul 15 23:29:23 ant__ are you running bitbake via the wrapper script or directly? Jul 15 23:29:24 I owe RP a pile of v2s now myself, heh Jul 15 23:29:34 fray, direct Jul 15 23:29:44 * fray states he REALLY hates how complex the arm architecture tunings are Jul 15 23:30:04 ant__ thats hte problem then.. it's trying to play with permissions.. but if you don't have pseudo loaded (LD_PRELOAD prior to running bitbake) then it can't do that Jul 15 23:30:22 either manually run w/ pseudo -- or use the wrapper in the "scripts" directory Jul 15 23:30:36 (one in the scripts directory also makes sure that pseudo is built before any target packages) Jul 15 23:30:51 ..or install it in $base_bindir .... Jul 15 23:31:20 problem seems to be installing in sysroot Jul 15 23:31:49 the problem is that the system needs root permissions.. and hopefully you won't give it those level perms.. :) Jul 15 23:31:58 so you need pseudo loaded in memory to emulate root permissions (safely) Jul 15 23:32:08 sure, but the rest of the binaries do package flawlessy Jul 15 23:32:16 of same klibc sources Jul 15 23:32:29 then they just happen to have been ignored.. Jul 15 23:33:06 the fixup_perms deals with a huge problem, the system as a whole had conflicting permissions for various files.. that chunk of do_package make sure they are sane, within the scope of the distribution, before the actual packaging happens.. Jul 15 23:33:12 you need pseudo loaded in order to do that.. Jul 15 23:33:25 other things might appear to work w/o pseudo.. but you'll have very broken permissions, owners and groups as a result Jul 15 23:33:50 I see Jul 15 23:34:10 (pseudo serves the same purpose as fakeroot, only it's "better".. and we need to preload it so it can capture python code as well as shell..) Jul 15 23:43:48 fray: maybe the script is in Poky? Jul 15 23:44:44 btw I found a pseudodone, pointing to a higher level Jul 15 23:45:02 in oe-core, it's scripts/bitbake Jul 15 23:45:15 hm.. /oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin Jul 15 23:45:22 maybe I should install there Jul 15 23:45:26 no.. Jul 15 23:45:30 do a which bitbake Jul 15 23:45:43 you should have the scripts directory in your path.. Jul 15 23:46:12 the "oe-init-build-env" does that for you if you use it.. otherwise you need to manually add it to your path.. Jul 15 23:46:18 it doesn't belong in the sysroot Jul 15 23:46:54 oki, I was looking for pseudo* Jul 15 23:47:02 (note if you have a pseudodone file.. it means at one point you where running the bitbake wrapper) Jul 15 23:47:38 well, maybe is in the path before, yes Jul 15 23:48:02 which says so Jul 15 23:48:42 eek.. I was running through the wrapper w/out figuring it :p Jul 15 23:48:57 if you are using the scripts/bitbake wrapper, then the issue could be something wrong with the klibc recipe (running target operations w/o fakeroot settings enabled -- pseudo is disabled by default).. or somehow you broken pseudo.. Jul 15 23:49:00 I start to see the differences with oe-dev Jul 15 23:49:39 if you've updated your glibc recently, it's possible a new syscall was introduced.. pseudo needs to be rebuilt (in that case) to discover the new syscalls so it can properly intercept them.. (it's rare that is needed, unless you have done a host distro upgrade) Jul 15 23:49:56 well, I use Gentoo Jul 15 23:50:07 should not be the case Jul 15 23:50:16 if glibc is updated.. rebuilding pseudo is a good idea.. otherwise it shouldn't be necessary Jul 15 23:50:17 fray: had you seen reports of pseudo being broken on CentOS/RHEL5.5 ? Jul 15 23:50:41 incandescant yes, but that was a long time ago.. AFAIK current pseudo works fine.. if thats not the case then I need a reproducer Jul 15 23:50:53 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4b66ce472871618cfe4761861392b7f9c3c265b0 Jul 15 23:50:58 (if someone is using Yocto 0.9 or 1.0 on a newer machine it might be an issue) Jul 15 23:51:04 apparently that patch causes issues Jul 15 23:51:13 this was someone using poky master on CentOS 5.5 Jul 15 23:51:39 fray: two people, in fact, reported it yesterday and today Jul 15 23:52:01 that may mean that CentOS's glibc is broken Jul 15 23:52:21 \o/ Jul 15 23:52:23 that patch was due to a user (Ubuntu?) reporting pseudo didn't seem to be working properly qith Qt.. Jul 15 23:52:26 that's an easy fix then :-/ Jul 15 23:53:01 http://bugzilla.pokylinux.org/show_bug.cgi?id=1150 Jul 15 23:53:05 thats an explanation of the problem Jul 15 23:53:07 I don't know specifics but but a user on #poky reverted that patch and all was fine, eflanagan was having a similar problem yesterday Jul 15 23:54:25 fray: gnarly Jul 15 23:54:39 the interception code pulls the RTLD info for realpath in an attempt to generate a forwarding function.. somewhere along the line glibc changed the definition of realpath... On the system that sparked this bug report, the realpath being returned by the dynamic linker was the wrong version.. Jul 15 23:54:50 this corrects the issue by requesting the next version until it gets one that "works" Jul 15 23:55:01 fray: pseudo is not installed on my buildhost Jul 15 23:55:14 oe builds pseudo-native Jul 15 23:55:17 specifically one with the versioned symbol "GLIBC_2.3" Jul 15 23:56:31 ant__ pseudo is built and installed as part of oe-core.. it lives in build/tmp/sysroots/x86_64-linux/./usr/lib/pseudo/lib64/libpseudo.so Jul 15 23:57:06 the other possibility is if you have a 64-bit host and some 32-bit executables on it.. by default pseudo is only built for one executable type.. if you have a system with both types installed.. you need to flip a bit in the local.conf Jul 15 23:57:15 no, here 32bits Jul 15 23:57:40 if you have a 32-bit host that shouldn't be the issue then Jul 15 23:58:20 incandescant if you can check the glibc on the centos machine and find the symbol and versions for all of the realpath functions that might help figure out whats going wrong Jul 15 23:58:47 (should be able to use objdump ... don't remember the right parameters off-hand.. but starting w/ -x is likely good enough) Jul 15 23:58:50 fray: ok, I'll see what I can do Jul 15 23:59:20 this patch is specifically looking for GLIBC_2.3 as the version.. it's possible CENTOS has a different versioned symbol.. or??? Jul 15 23:59:40 yeah, perhaps Jul 15 23:59:49 CentOS 5.5 is pretty retro Jul 16 00:00:10 it definitely has a new enough glibc though, so perhaps the symbol versioning is whack Jul 16 00:00:39 thats my guess.. Jul 16 00:00:44 5 ain't retro :) Jul 16 00:00:58 no.. it's "quant" ;) Jul 16 00:01:04 quaint even Jul 16 00:01:17 hehe Jul 16 00:01:35 CentOS is retro when you're used to running Fedora Jul 16 00:18:56 fray: I've rebuilt pseudo-native Jul 16 00:19:10 and as bonus tried to build pseudo Jul 16 00:19:14 cc1: error: unrecognized command line option "-m32" Jul 16 00:19:34 -o pseudo_tables.o pseudo_tables.c Jul 16 00:20:18 target pseudo may or may not build.. if it tried -m32 then it tried to build a 32-bit version for the target and I'm not surprised there are issues with that.. Jul 16 00:20:51 well, same fixup_perms error :/ Jul 16 00:21:24 the error you are getting is simply there aren't enough permissions to chown that file/directory to 0:0 Jul 16 00:21:33 but why? Jul 16 00:21:41 there are the gcc-cross and co. Jul 16 00:21:46 all is 755 Jul 16 00:22:07 why do_package wanna be root? Jul 16 00:22:10 you need to figure out why you are getting that error.. there are only two causes that I know of.. pseudo is not running -- or your filesystem (selinux?) has locked out rights to be able to change that directory Jul 16 00:22:32 when you are building packages for the target, the you don't want the files owned by -you-.. you want them owned by root:root.. Jul 16 00:22:43 all the tree is 755 Jul 16 00:22:47 on your host system pseudo emulates the ability to do that.. so when the packager comes in, it sees them as root:root Jul 16 00:22:56 no user/group is the failure.. not mode Jul 16 00:23:02 ok, I see Jul 16 00:23:21 I'll try to grasp the magic from gcc-cross Jul 16 00:23:35 fixup_perms should not be running in a -cross package.. Jul 16 00:23:39 if it is, something is very broken Jul 16 00:23:49 fixup_perms is specific to target package Jul 16 00:23:55 klcc is a perl script around gcc Jul 16 00:24:08 (cross) Jul 16 00:24:40 it seems reasonable to me to install it where gcc-cross is Jul 16 00:25:04 but it could even be in the path elsewhere Jul 16 00:25:10 if the recipe is klcc-cross, then fix_perms should not have run -- unless the recipe didn't tell the system it's cross Jul 16 00:25:29 inherit cross Jul 16 00:26:01 the error triggers if I try to customize PACKAGES and FILES Jul 16 00:26:16 let them unset, no error (but empty pkg) Jul 16 00:26:45 the nomral build process.. fetc, patch, configure, compile, install, package, package_write_xxxx Jul 16 00:27:02 in package, this package is running a step that should only be run for target packages.. the fixup_perms step Jul 16 00:27:31 recipe peeks in STAGING_DIR_TARGET Jul 16 00:28:57 doesn't matter.. why is this running.. figure that out and you'll be able to figure out how to disable it Jul 16 00:29:19 native.bblcass has a do_package[noexec] = "1" I would assume cross would as well Jul 16 00:30:21 I don't see anything in cross.bbclass that prevents do_package from running.. maybe thats the bug? Jul 16 00:31:50 a simple workaround would be to put the following at the top of the fixup_perms function in packages.bbclass Jul 16 00:31:54 if bb.data.inherits_class("native", d) or \ Jul 16 00:31:54 bb.data.inherits_class("cross", d): Jul 16 00:31:54 return Jul 16 00:32:11 there is no reason we ever want to run that code on a native or cross package Jul 16 00:45:43 ok, I'll see tomorrow Jul 16 00:45:47 good night Jul 16 00:45:49 thx Jul 16 01:03:08 aside: don't know if oe-core has it, but oe has a utility function in the oe python package for checking inherits of multiple classes in a single function call **** ENDING LOGGING AT Sat Jul 16 02:59:57 2011