**** BEGIN LOGGING AT Wed Nov 16 02:59:57 2011 Nov 16 06:15:33 can i trade back for mine again? :P Nov 16 06:15:46 sorry wrong window :/ Nov 16 06:54:24 can the same serial console port opened by 2 processes Nov 16 07:37:13 hmm, at which time i can expect laibsch here? Nov 16 07:42:38 mmisc: about once per year or rarely Nov 16 08:35:14 good morning Nov 16 08:51:43 mornin Nov 16 10:21:02 hi, fellows! Nov 16 10:22:57 Have a little problem: bitbake trying to fetch patch-2.6.37, but can't find it. Me too... Is it ok to change the kernel version for higher one? I compile system for beagleboard. Nov 16 10:23:49 oops, not beagle, just qemuarm. Nov 16 10:33:40 reisei: well, it is due the kernel.org downtime from the last two months. it is best to try to find the patches somewhere and download them manually Nov 16 10:35:11 zecke, ok I searched but find nothing, ofcourse will search again a bit, but... Nov 16 10:46:34 Where can I find kernel mirrors list? I saw the ${KERNELORG_MIRROR} so I searching for it... Nov 16 10:47:38 reisei: really google... kernel.org got hacked... a lot of data vanished and is slowly restored Nov 16 10:48:37 zecke: I found working mirror with all needed patchs, so I just want to add it to the mirror list. Nov 16 10:49:13 reisei: yeah, you can set KERNELORG_MIRROR in conf/local.conf, I don't know how much of the URL needs to be put there Nov 16 10:49:42 ok, thanks, zecke! Nov 16 12:54:38 Today's guile problem Nov 16 12:54:40 Dude, GNU Radio looks really cool. Particularly GNU Radio Companionā€¦ Is this the only decent block-based open source signal processing tool there is? Nov 16 12:54:47 this is nguiel, not guile-native Nov 16 12:54:57 and it already has the inherit gettext Nov 16 13:26:18 urg Nov 16 13:26:26 stupid paste buffer Nov 16 13:26:33 http://pastebin.com/xycRPh2T Nov 16 13:26:37 guile #fail Nov 16 14:45:27 mhm, I have the feeling that do_install_avahi-autoipd() { Nov 16 14:45:31 is not being called at all Nov 16 14:45:39 it should be in the run.do_install script, right? should be visible there? Nov 16 14:47:08 and it should be visible when running bitbake -e avahi as well? Nov 16 14:47:11 I do not see it though Nov 16 15:04:01 Jin^eLD: why would it be called? Nov 16 15:04:11 unless that recipe adds avahi-autoipd to overrides, that won't do anything Nov 16 15:04:27 kergoth: I don't know :) but I assume the one who wrote the avahi.inc recipe knew the reason :) Nov 16 15:04:51 let me grep for overrides Nov 16 15:05:14 don't see anything there Nov 16 15:05:23 does that mean that the avahi recipe is partially broken? Nov 16 15:05:45 it has some other intersting things in there like pkg_postinst_avahi-daemon Nov 16 15:05:56 would that also be discared? Nov 16 15:06:01 postinsts are per package, do_install is not Nov 16 15:06:09 ok I see Nov 16 15:07:32 so /openembedded-core/meta/recipes-connectivity/avahi/avahi.inc is broken then :( Nov 16 15:07:50 it does seem like it, though I couldn't say for sure without reading all of it and the corresponding recipe Nov 16 15:49:55 kergoth: btw I still did not find the solution to my "it keeps rebuilding u-boot" problem, update to bitbake 1.14 today, still the same Nov 16 15:54:29 Jin^eLD: don't you have 2 recipes in some layers and LOCALCOUNT in SRCPV keeps incrementing with every build? Nov 16 15:54:49 Jin^eLD: 2 recipes forcing different SRCREVs to be precies Nov 16 15:55:40 JaMa|Wrk: that was kergoth's thought too, but I build my u-boot from a tarball Nov 16 15:57:03 and I do not see another u-boot with the same version as mine in the other layers Nov 16 15:58:00 so, no SRCPV or SRCREV is being used.. I have no clue what to look for; bitbake -e did not show anything suspicious Nov 16 15:58:05 I would check sqlite db for LOCALCOUNT if it's changing Nov 16 15:58:38 where is the database located? Nov 16 15:58:44 cache dir Nov 16 15:59:07 bb_cache.dat? Nov 16 15:59:18 ąõ ķī Nov 16 15:59:21 ah no Nov 16 15:59:22 found it Nov 16 15:59:37 bb_persist_data.sqlite3 Nov 16 16:06:05 I do not find any u-boot related entries in the sqlite db in the BB_URI_LOCALCOUNT table Nov 16 16:06:36 so that's not it then... Nov 16 16:06:44 ? Nov 16 16:16:29 Jin^eLD: weird.. I have a few http://paste.pocoo.org/show/508740/ Nov 16 16:17:11 JaMa|Wrk: my bad ;) I forgot the % around the string :P Nov 16 16:17:24 I seem to have two Nov 16 16:18:09 let me rebuild and see if it changes... Nov 16 16:33:19 JaMa|Wrk: I do not see a difference when comparing the select before and after the build Nov 16 16:33:40 http://pastebin.mozilla.org/1384239 Nov 16 16:55:08 hi all Nov 16 16:55:35 hi pb Nov 16 16:57:33 hi pb_ Nov 16 17:00:12  Nov 16 17:11:50 Jin^eLD: then it's probably realy something else.. does it produce different sstate archives? Nov 16 17:13:35 JaMa|Wrk: how exactly do I find out, what should I be searching for? Nov 16 17:13:55 something in sstate-cache or sstate-control? Nov 16 17:14:01 http://pastebin.com/xycRPh2T Nov 16 17:14:04 guile failure Nov 16 17:14:11 recipe inherits gettext Nov 16 17:15:00 Jin^eLD: sstate-cache look for sstate-u-boot.*populate-sysroot.tgz Nov 16 17:15:24 Jin^eLD: if there is one from each build you can use bitbake-diffsigs on .tgz.sigdata to see what's changing for you on everybuild Nov 16 17:16:02 Jin^eLD: but still it should not rebuild it with every build unless you're using BB_SIGNATURE_HANDLER = "basichash" Nov 16 17:16:03 JaMa|Wrk: populate_lic seems to be done each time new Nov 16 17:17:17 I do not think that I am using the basichash thing, I'll recheck Nov 16 17:22:10 JaMa|Wrk: I do not have as many duplicate siginfos as I do builds, only two or three, which I guess are from my changes in the recipe Nov 16 17:22:34 * Jin^eLD feels lost Nov 16 17:35:07 Jin^eLD: so the build does not create new archives except from populate-lic? Nov 16 17:35:41 JaMa|Wrk: does not seem so, otherwise I'd had 30+ archives there Nov 16 17:36:22 it does rebuild u-boot each time I build my image, and I did that very often in the last days (in progress of tuning) Nov 16 17:36:40 maybe you're looking with wrong pattern? :) Nov 16 17:37:12 find . | grep u-boot-at91sam9g20ek :) Nov 16 17:37:34 doing that in sstate-cache dir Nov 16 17:37:42 http://paste.pocoo.org/show/508797/ Nov 16 17:39:34 mhm, I did that with wc -l and now let me do another image build and see if I get more Nov 16 17:39:38 maybe you are right.. Nov 16 17:46:00 JaMa|Wrk: ls -l sstate-u-boot* | sort | wc -l count stayed the same Nov 16 17:46:16 did it before building the image, and then after image finished (which triggered a rebuild of uboot) Nov 16 17:46:27 heh Nov 16 17:46:34 gm all Nov 16 17:46:40 hi khem Nov 16 17:50:17 khem: hi khem Nov 16 17:51:11 Jin^eLD: then check the stamps directory if it's changing there (something removing u-boot stamps after building it or image) Nov 16 17:51:19 Jin^eLD: then I'm out of ideas Nov 16 17:51:45 using oe-core ? Nov 16 17:51:53 yes, bitbake 1.14 Nov 16 17:54:46 Jin^eLD: u-boot gets rebuild everytime ? Nov 16 17:55:16 Do u know if its bitbake related only Nov 16 17:55:28 khem: it gets rebuilt every time I build myimage Nov 16 17:55:40 I don't, we checked a number of possiblities Nov 16 17:56:21 does -DDD shows some reason why it rebuilds Nov 16 17:56:29 may be you need to compare signatures Nov 16 17:56:45 I could not find anything with -e or -DDD but maybe I did not know what to look for, at least I could not see anything obvious Nov 16 17:58:50 try --dump-signatures Nov 16 17:59:37 how exactly? bitbake myimage --dump-signatures? Nov 16 17:59:49 u-boot Nov 16 18:00:00 its a bitbake option Nov 16 18:00:39 I got the option part, was not sure if I should run it on uboot or on my image recipe... started Nov 16 18:02:54 uhm, that may sound stupid but... where exactly is it dumping to? I do not see anything in the terminal where I run it, no extra files are left afterwards Nov 16 18:14:38 OK.. I compared the stuff in the stamps directory before and after the build Nov 16 18:15:04 the stamp file contents for configure, install and patch have changed Nov 16 18:15:10 the stamp file names have not Nov 16 18:15:25 does that tell me anything? Nov 16 18:15:30 anything meanigful that is? Nov 16 18:16:46 is there a way to get the equivalent of git log --abrev-commit into a SRC_ Nov 16 18:16:49 REV Nov 16 18:18:23 thinking here of MACHINE_KERNEL_PR_append = "+gitr${SRCREV}" Nov 16 18:30:21 Jin^eLD: comprare the content with bitbake-diffsigs Nov 16 18:32:29 for the do_configure sigs it says dependency on task gcc-cross_4.5.bb.do_populate_sysroot was removed Nov 16 18:33:14 for do_install it says that dependency on task pseudo_1.2.bb.do_populate_sysroot was removed Nov 16 18:33:33 this happens between last 2 image builds? Nov 16 18:34:01 and for do_patch it said that dependency on task quilt-native_0.48.bb.do_populate_sysroot was removed Nov 16 18:34:02 yes Nov 16 18:34:10 I copied away the stamps from "before" the build Nov 16 18:34:17 and then compare the u-boot stamps from before/after the image build Nov 16 18:34:31 and when you say "19:13:41 < Jin^eLD> the stamp file names have not" you mean that those files have same hash in filename? Nov 16 18:34:40 yes, the file names are the same Nov 16 18:34:43 but different content? Nov 16 18:34:54 right Nov 16 18:35:25 for instance I was now diffsiging bitbake-diffsigs /tmp/sigbefore/u-boot-2009.06-r2.do_patch.sigdata.e136ca74f7f9cb9c768804446be14a76 /tmp/sigafter/u-boot-2009.06-r2.do_patch.sigdata.e136ca74f7f9cb9c768804446be14a76 Nov 16 18:35:39 does it happen again if you build it now again? Nov 16 18:36:09 let me start another image build and see what changes there Nov 16 18:36:26 maybe it could be caused by http://git.openembedded.org/bitbake/commit/?id=e492eb4dc9016cd0bed194377c6f2b85cf0ad113 somehow Nov 16 18:36:48 but if it happens over and over again then it's probably bug Nov 16 18:37:27 it does build u-boot each time I bitbake myimage Nov 16 18:37:32 consistently Nov 16 18:39:37 Jin^eLD: do you have bitbake master or something older? Nov 16 18:40:32 JaMa|Off: I checked out the 1.14 tag today, but it was the same with 1.13 git from hmm, about 2 weeks ago Nov 16 18:45:08 JaMa|Off: ok that is weird now Nov 16 18:45:29 the build finished (once again rebuilding u-boot), but the u-boot the stuff in stamps stayed the same Nov 16 18:45:39 no change between the previous one and this one Nov 16 18:46:33 Jin^eLD: then it's not caused by that commit, because this one is from master not yet in 1.14 Nov 16 18:50:23 I wonder how I can finally figure out what is going wrong there Nov 16 18:50:55 I was not especially confused where new attempt did trigger a rebuild, as always, but the sig stuff in stamps stayed the same, including contents Nov 16 18:53:09 aem, not "not" but rather "now" :) Nov 16 18:53:53 hmm, wonder whats involved in coercing llvm-gcc/clang to build arm stuff Nov 16 19:14:16 khem: good to see you back and sorting some e-mails without response.. when you find some time for gcc issues I've sent one on oe-devel "libvpx causing gcc ICE when building for qemux86-64" Nov 16 19:14:48 khem: seems to be also when mplayer2 and libav is built with optimizations Nov 16 19:19:55 JaMa|Off: sure I have a lot of emails to sort Nov 16 19:20:04 will take a few days Nov 16 19:51:49 i always miss woglinde Nov 16 19:52:12 khem, rehi, hope your trip was fine Nov 16 19:56:02 khem, i've fleshed out the scheduler fns as suggested by woglinde. Perhaps you can sort a bump of the _git out with him. Nov 16 19:59:19 khem, oh, and i have severe trouble using TCLIBC=uClibc (or however it's spelled) with meta-oe and current bitbake. I will try to explain what i'm doing and how i'm failing miserably in the new transmeta-world when i can get at the build-machine again.. Will be fun ;) Nov 16 20:05:25 can anyone comment why task hashes change again when they are saved to sstate? Nov 16 20:05:36 that is the sstate file name has a different hash than the task itself? Nov 16 20:25:51 hmmm Nov 16 20:25:58 I've an mplayer2 build failure: http://www.pastie.org/private/fp9xlnalcdi01tdf4ia Nov 16 20:26:08 the error is rather strange Nov 16 20:26:18 I'll try nm Nov 16 20:28:46 000080e8 T XShmQueryExtension Nov 16 20:28:47 seem there Nov 16 20:33:56 hmm is there a good "ramdisk" distro i can use as a base to create a ramdisk with "alsa++" on it ? Nov 16 20:34:08 alsa++ meaning alsa + something more Nov 16 20:34:25 what do you mean by "ramdisk" distro? Nov 16 20:34:42 any of the distros are likely to work for you, if you pick the right image to build Nov 16 20:34:47 well i mean busybox + uclibc and well maybe some init.. Nov 16 20:35:54 and ofc a kernel to go with that.. Nov 16 20:36:44 guess most "minimal" distros are at that level.. Nov 16 20:37:00 bitbake minimal of a given distro i mean Nov 16 20:39:14 the image recipe is what chooses what gets built and put in your root filesystem. the distro picks higher level policy, hardware features you want to support (e.g. bluetooth), other features (e.g. ipv6), and the packaging to be used. that said, you might want to look at the micro distro Nov 16 20:54:00 there are initramfs images but they might need some tweaking Nov 16 20:58:57 hrrm... could someone try to build tcpdump from meta-oe after installing libpcap-dev on the host? Nov 16 20:59:10 i think it tries to link agains the host one Nov 16 20:59:30 and am totally stumped on how to fix this :/ Nov 16 21:01:10 generally there's a configure argument to tell it where to find its dependent library Nov 16 21:01:13 thats how most things work Nov 16 21:01:19 you pass that in EXTRA_OECONF Nov 16 21:02:20 hmm, the current tcpdump bb file tries to fixup the Makefile afterwards Nov 16 21:06:55 kergoth, does it make sense to supply LDFLAGS with the correct search path to configure? Nov 16 21:07:48 the LDFLAGS in the metadata already has the right paths, but that doesn't mean the macros in the configure script obey it. Nov 16 21:07:58 some go out and test for existance of certain files in certain paths directly Nov 16 21:08:06 depends, i'd take a look at hte configure.{ac,in} Nov 16 21:09:06 thanks Nov 16 21:10:03 heh, makes one wonder about constructing and using a minimal chroot for builds. the host contamination stuff is a pain in the ass Nov 16 21:12:34 yep Nov 16 21:13:00 shouldn't it be possible to use the native staging for a changeroot? Nov 16 21:15:28 it isn't complete, nor would the permissions be correct Nov 16 21:16:09 i've just returned to oe after a year, so much has changed... Nov 16 21:17:04 shoragan: welcome to the club ;) same here Nov 16 21:17:55 and i'm not sure splitting it into all these layers has made it clearer Nov 16 21:18:47 for me it did not, I still prefer the oe-classic setup Nov 16 21:19:04 but had to switch because it becomes deprecated :( Nov 16 21:20:52 yep Nov 16 21:21:07 and so many thing which worked fine are now broken Nov 16 21:21:26 unfortunately... Nov 16 21:21:49 any transition is going to have hiccups, sadly Nov 16 21:39:34 kergoth: thanks Nov 16 21:54:35 kergoth, i think i fixed it, libpcap should install a pcap-config script Nov 16 21:54:45 and it was not visible in the sysroot Nov 16 23:28:58 khem ping Nov 16 23:38:31 woglinde: hello Nov 16 23:38:39 woglinde: whats up Nov 16 23:38:49 khem ist it possible to get full fenv support for arm in uclibc Nov 16 23:38:58 there are some bits missing Nov 16 23:39:09 yes there are. Nov 16 23:39:10 and its not so easy to copy it over from glibc Nov 16 23:39:26 cook up patches Nov 16 23:39:38 I meant its to hard for me Nov 16 23:39:45 oh Nov 16 23:40:07 dont think I can get to it in short while Nov 16 23:40:13 since I have a big back log Nov 16 23:40:17 okay Nov 16 23:40:27 and next few weeks will be loaded as well Nov 16 23:40:32 what are your tasks for the next time? Nov 16 23:40:56 its mainly paid work Nov 16 23:41:09 and I have to deliver some trainings Nov 16 23:43:41 without full fenv support we dont get llvm compiled Nov 16 23:44:42 hmm Nov 16 23:46:13 if you can figure out what it needs minimally Nov 16 23:46:19 I can see what I can do Nov 16 23:48:47 fegetexcept und fetestexcept Nov 16 23:48:52 if I remember correctly Nov 16 23:49:16 in glibc peeking in /proc is used Nov 16 23:49:26 original written bei pb_ Nov 16 23:49:31 *g* Nov 16 23:49:48 * woglinde wonders where pb didnt had wrote something **** ENDING LOGGING AT Thu Nov 17 02:59:57 2011