**** BEGIN LOGGING AT Thu Mar 27 02:59:57 2008 Mar 27 05:47:45 03rwhitby 07org.oe.dev * re561ab79... 10/ (1 packages/meta/slugos-packages.bb): slugos-packages: Added dropbear and demoted motion (fails to build) Mar 27 07:38:04 * * OE Bug 4126 has been created by  Mar 27 07:38:06 * * openmoko-image-1.0-autobuild Mar 27 07:38:08 * * http://bugs.openembedded.net/show_bug.cgi?id=4126 Mar 27 07:39:12 morning Mar 27 08:09:22 morning Mar 27 08:11:12 hi HRH_H_Crab Mar 27 08:11:17 hi hrw Mar 27 08:12:22 RP, i use the latest oe.dev rpeo, but i also get the ttf-liberation error with the poky image... (try to build it for my collie) Mar 27 08:12:34 law: which error? Mar 27 08:13:20 hrw, http://pastebin.com/m1280425c Mar 27 08:13:39 i already build ttf-libaration manually Mar 27 08:14:41 ah... Mar 27 08:16:17 law: s/poky image/x11-sato-image/ please Mar 27 08:16:47 law: that x11-sato-image recipe is wrong Mar 27 08:17:01 ttf-liberation recipe does not generate ttf-liberation package Mar 27 08:17:14 03rwhitby 07org.oe.dev * rab9b6229... 10/ (4 files in 4 dirs): linux-ixp4xx: Added the dmabounce debug patch from OpenWrt Mar 27 08:17:54 hrw, is there also a poky image in OE ? Mar 27 08:18:02 no Mar 27 08:18:41 x11-sato-image was someone's attempt to create poky-image-sato in OE Mar 27 08:20:11 hrw, a ok so i should use poky from openedhand ? Mar 27 08:22:00 it depends what you want to get Mar 27 08:22:18 hrw, poky for collie Mar 27 08:24:26 sato does not support qvga screens Mar 27 08:25:19 hrw, hmm ok Mar 27 08:28:10 hrw, poky works really nice on my c7x0, but some apps are missing (webbrowser, mailapp) Mar 27 08:28:38 hrw, webkit is very slow on my c7x0 (installed on sd) Mar 27 08:41:03 hi greentux Mar 27 08:41:40 law: Poky is not user targetted so we live without mailapp Mar 27 08:41:56 03xora 07org.oe.dev * rcaecf914... 10/ (2 files in 2 dirs): angstrom-2007-for-openmoko-versions.inc : update gtkhtml version Mar 27 08:44:06 hi all Mar 27 08:45:09 hrw, but it works better than others on my c7x0 (out of the box) Mar 27 08:45:44 hrw, so i think about building a application feed (pasted on pinky 3.1) Mar 27 08:50:06 law: Poky does have claws mail in it iirc, just not in the standard images Mar 27 08:53:15 RP: it does, I stole some stuff from it once Mar 27 09:05:31 RP: see something slightly odd about this path? ~/openmoko/build-neo/tmp/work/armv4t-angstrom-linux-gnueabi/gcc-cross-4.1.2-r14/image/home/graeme/openmoko/build-neo/tmp/cross/lib Mar 27 09:12:51 XorA: yes, it looks wrong Mar 27 09:13:20 RP: johncylee noticed it, he thinks thats where the recursive install zecke put in is going wrong, its finding libs in there Mar 27 09:13:25 johncylee: over to you Mar 27 09:14:34 Where is this path coming from? Mar 27 09:14:37 RP: there shouldn't be abs path name inside the image directory, right ? Mar 27 09:14:42 hi Mar 27 09:15:06 RP: under TMPDIR/work/armxxx/gcc-cross/image Mar 27 09:16:14 RP: log.do_install shows it installed to that dir Mar 27 09:17:09 i'm trying to create an openembedded package for libebml and libmatroska Mar 27 09:17:20 ah, that path does make sense Mar 27 09:17:24 RP: the DESTIR issued by OE is correct Mar 27 09:17:33 but i haven't gotten the ebml libs to install so that i can link them correctly Mar 27 09:17:56 RP: so it was used to actually install stuffs to staging and cross dirs, right ? Mar 27 09:18:57 johncylee: The image directory and do_install are just used to generate the gcc-cross packages Mar 27 09:19:08 specifically libgcc_*.ipk Mar 27 09:19:21 this is my first bb-file... would anybody mind giving me some clues? Mar 27 09:19:25 XorA: How in sync is OM with the gcc changes I made? Mar 27 09:19:38 RP: 100% Mar 27 09:19:52 RP: I did mtn propogate only this morning Mar 27 09:19:53 Fraxinas: libebml and libmatroska already exist in OE? Mar 27 09:19:56 RP: libtool will look for .la files under cross/armxxx/lib/*.la, and the libspp.la files there includes the x86_64 dependency_libs Mar 27 09:20:05 do they? Mar 27 09:20:06 XorA: ok, I just wanted to confirm that thanks :) Mar 27 09:20:47 johncylee: ah, I think I start to understand Mar 27 09:21:09 cross packages are rather nasty beasts Mar 27 09:21:39 johncylee: the staging is not done from the image directory but from a staging-tmp one Mar 27 09:21:48 but it will be very similar to the image one Mar 27 09:22:08 RP: i couldn't find them in the filebrowser Mar 27 09:22:27 Fraxinas: so you've written recipes for them all? Mar 27 09:22:34 RP: so, libtool will add something like "-L.../staging/x86_64-linux/usr/lib" when building target packages Mar 27 09:22:39 yes i have but they don't work ;) Mar 27 09:22:56 Fraxinas: pastebin them and maybe someone will give you some pointers Mar 27 09:23:03 cool okay Mar 27 09:24:11 http://pastebin.ca/959270 Mar 27 09:24:40 RP: under my TMPDIR/cross/arm.../lib directory, there are some .la files with dependency_libs = "...../staging/x86_64-linux/usr/lib". that's why packages like avahi always fail Mar 27 09:24:40 the makefile doesn't have an "install" option though, i think i should mention that Mar 27 09:25:01 Fraxinas: There is no do_stage function Mar 27 09:25:31 i had the do_install section named do_stage before Mar 27 09:25:38 was experimenting a lot with it Mar 27 09:26:13 i had been using the libogg bb as a hint :) Mar 27 09:27:04 autotools gives a good default do_install, you'll need a custom do_stage Mar 27 09:27:16 and the do_install function should not be touching staging Mar 27 09:27:47 aye i'll try that again Mar 27 09:28:07 johncylee: Where are those files coming from? Is this with OE.dev from scratch? Mar 27 09:28:21 Well, OE.OM:) Mar 27 09:28:44 I have no such thing here :/ Mar 27 09:29:13 RP: we don't have such things on i686. it only happens on x86_64. Mar 27 09:29:29 johncylee: My main machine is x86_64 Mar 27 09:30:05 RP: okay, I will pull from OE.dev and check if there's anything different in classes and package/gcc Mar 27 09:30:37 johncylee: I looked at my gcc-cross and it doesn't build libssp either... Mar 27 09:31:22 RP: yeah it shouldn't. is for x86 not arm Mar 27 09:31:32 s/is/it's/ Mar 27 09:31:49 but your arm gcc-cross has it? Mar 27 09:33:01 There is something odd going on... Mar 27 09:33:56 RP: yes arm gcc-cross has it Mar 27 09:34:11 which version of gcc? Mar 27 09:34:24 RP: gcc-cross_4.1.2.bb Mar 27 09:35:13 ok, mine is 4.2.2 which may or may not have something to do with it Mar 27 09:35:16 * RP bakes 4.1.2 Mar 27 09:37:51 * RP notes gcc-4.1.2.inc has --disable-libssp Mar 27 09:45:56 RP: it's not in my run.do_configure Mar 27 09:47:21 johncylee: Yes, 4.1.2 does have libssp here too Mar 27 09:47:43 hi rp Mar 27 09:47:53 hi woglinde Mar 27 09:48:31 rp is there a timeline for gcc-4.3 yet? Mar 27 09:48:42 woglinde: its in OE isn't it? Mar 27 09:48:57 RP: it's overwritten somewhere Mar 27 09:49:47 johncylee: yes, confirmed here too, its not making it to the configure options Mar 27 09:50:02 it does for 4.2.2 Mar 27 09:51:23 gcc-configure-common.inc comes after gcc-4.1.2,inc and overwrites it Mar 27 09:51:30 RP: yeah Mar 27 09:51:37 RP: just grepped it Mar 27 09:51:47 johncylee: This is from when some idiot rearranged the gcc recipes ;-) Mar 27 09:51:56 * XorA chuckles at RP Mar 27 09:52:03 *g* Mar 27 09:53:39 RP: so, move gcc-configure-cross.inc in front of gcc-${PV}.inc ? Mar 27 09:53:40 johncylee: I'll fix it but I'm not going to rush into it, I'd like to get it right ;-) Mar 27 09:53:47 johncylee: eek, no ;-) Mar 27 09:54:44 johncylee: If you want the quick workaround, add --disable-ssp to the flags in gcc-cross_4.1.2.bb Mar 27 09:54:52 then its like 4.2.2 Mar 27 09:55:07 but I will come up with something neater Mar 27 09:55:53 RP: thanks. by the way, I noticed that autotool_do_install will sed the path of all .la files Mar 27 09:56:08 RP: but we don't use it for gcc-cross Mar 27 09:56:43 johncylee: cross packages need special handling Mar 27 09:57:05 autotools_do_install would most likely explode for gcc-cross Mar 27 09:57:50 RP: I know. but, if stuffs under cross/arm.../lib/*.la has dependency_libs = "...x86_64..." like this libssp Mar 27 09:58:02 johncylee: Its just libssp though? Mar 27 09:58:06 RP: we will still be in trouble if libtool found it and use it Mar 27 09:58:44 RP: no. grep -nH -e x86_64 *.la Mar 27 09:58:44 libmudflap.la:17:dependency_libs=' -L/home/john/oe/tmp/openmoko/staging/x86_64-linux/usr/lib -ldl' Mar 27 09:58:44 libmudflapth.la:17:dependency_libs=' -L/home/john/oe/tmp/openmoko/staging/x86_64-linux/usr/lib -ldl' Mar 27 09:58:44 libssp.la:17:dependency_libs=' -L/home/john/oe/tmp/openmoko/staging/x86_64-linux/usr/lib' Mar 27 09:58:44 libssp_nonshared.la:17:dependency_libs=' -L/home/john/oe/tmp/openmoko/staging/x86_64-linux/usr/lib' Mar 27 09:58:55 mudflap shouldn't be there either Mar 27 09:59:37 * johncylee kills mudflap, burn it and bury it Mar 27 09:59:52 johncylee: Its the same issue, missing flags Mar 27 10:00:59 RP: if i take out the do_install {} section then i get an error message make: *** No rule to make target `install'. Stop. Mar 27 10:01:26 Fraxinas: Your app can't cope with "make install"? Mar 27 10:01:33 because the makefile of libebml doesn't have an install option Mar 27 10:02:04 and i must really assert that it's not my app ;) Mar 27 10:02:35 Fraxinas: does the app use autotools? Mar 27 10:02:46 no Mar 27 10:02:56 it's really badly done actually Mar 27 10:03:03 so why does it say inherit autotools in your .bb file? Mar 27 10:03:11 it doesn't have any configure.ac or makefile.am or anything either Mar 27 10:03:36 Fraxinas: ok, remove that inherit, autotools.bbclass only helps if the app actually uses autotools Mar 27 10:03:46 RP: but I didn't see anything disable mudflap for 4.1.2 Mar 27 10:03:47 you need to write a custom do_install and a custom do_stage Mar 27 10:03:57 ah okay good to know, i shall do that Mar 27 10:04:29 johncylee: It should have --disable-libmudflap Mar 27 10:04:50 however that means that i'll have to copy everything into the install directory by system commands in the do_install {} section right? Mar 27 10:05:37 Fraxinas: You'll have to use "install" to install the files manually, yes Mar 27 10:05:46 Fraxinas: there are examples in OE that do it Mar 27 10:05:47 RP: true for 4.2.2 but not 4.1.2 Mar 27 10:05:55 okay i'll check Mar 27 10:06:14 johncylee: You mean the configure option doesn't exist? Mar 27 10:06:26 it's something kind of like "install -m 0644 ebml/*.h ${STAGING_INCDIR}" Mar 27 10:06:34 RP: I mean it's not in bb :) Mar 27 10:06:42 johncylee: I know, thats a bug Mar 27 10:09:42 RP: do_compile fails when i take out the autotools of inherit Mar 27 10:11:18 am i going to explicitely have to add a do_compile { oe_runmake.... } to the recipie then? Mar 27 10:12:55 oh wait i already do that manually anyways, so something before the compile step in the toolchain must have already been missing Mar 27 10:14:34 technically could only be do_configure but the app doesn't even have a configure Mar 27 10:15:04 how many .h and .c files the app has? Mar 27 10:16:03 26 headers Mar 27 10:16:26 so maybee consider to write a Makefile.am and configure.ac Mar 27 10:16:42 21 cpps Mar 27 10:17:16 hmm it does compile all right though Mar 27 10:17:38 with the autotools inherited Mar 27 10:18:39 so it has a configue.ac and Makefile.am already Mar 27 10:19:20 fails because of http://pastebin.org/25618 without autotools Mar 27 10:19:51 no it doesn't come with them. it just has a collection of ready-made makefiles for Linux, Win32 Mar 27 10:20:42 yes than consider to read the autotools doku and write a configure.ac and Makfefile.am Mar 27 10:22:58 isn't it possible to do the tasks with a bitbake recipie too? Mar 27 10:30:58 my intention is also to understand oe a little better ^^ Mar 27 10:31:20 for example: why does the ar command fail in the compile task? Mar 27 10:34:38 mipsel-linux-ar: illegal option -- e Mar 27 10:35:05 so the Makefiles using an option that the mips-archiver dont have Mar 27 10:43:24 * XorA suddenly sees the light Mar 27 10:52:22 * ScaredyCat turns it off Mar 27 10:58:03 Fraxinas: You can do it in a .bb file, see what autotools was doing for do_compile and maybe copy it Mar 27 10:59:24 sounds like a good idea :) Mar 27 11:06:44 Is LEAD_SONAME documented anywhere? I don't know what it does or what it should be set to? Mar 27 11:29:08 RP i've found out that the version with autotools inherited uses the command ar while the one without actually uses mipsel-linux-ar Mar 27 11:29:35 however it complains about a parameter -e when that ons isn't supplied at all Mar 27 11:30:04 Fraxinas: Its probably to do with variables that are exported Mar 27 11:30:26 when you find something wrong like extra invalid options you have to start patching things :( Mar 27 11:30:48 aww ._. Mar 27 11:35:13 good monring Mar 27 11:42:20 RP: i think i fixed it by doing this: oe_runmake CC="${CC}" CXX="${CXX}" AR="${AR} rcvu" Mar 27 11:44:14 yes actually Mar 27 11:44:44 made and installed the libs Mar 27 11:45:38 but still i have the prob /media/Devel/7025/build/tmp/cross/lib/gcc/mipsel-linux/4.1.1/../../../../mipsel-linux/bin/ld: cannot find -lebml Mar 27 11:45:41 am I the only one having problems doing an "mtn pull"? Mar 27 11:48:31 wb linde Mar 27 11:50:26 hmm, why can't I mtn pull :( Mar 27 11:50:39 ~curse usb Mar 27 11:50:40 May you be reincarnated as a Windows XP administrator, usb ! Mar 27 11:50:57 Fraxinas: is the library in staging? If not, why not? Mar 27 11:51:22 andy@foxtux /media/Devel/7025/build/tmp/staging $ find |grep ebml./mipsel-linux/lib/libebml.so.0./mipsel-linux/lib/libebml.so./mipsel-linux/lib/libebml.a Mar 27 11:51:45 it's there. installed it with oe_libinstall -a -so -C make/linux libebml ${STAGING_LIBDIR} Mar 27 11:51:51 thats a static lib Mar 27 11:52:07 static lib is not good? Mar 27 11:52:40 not when you're trying to do dynamic linking Mar 27 11:52:56 hmm that makes sense Mar 27 11:53:15 i pretty much tried porting the gentoo ebuilds over to oe Mar 27 11:55:15 they do it that way too on the i686 build for libmatroska with -lebml Mar 27 11:56:46 woglinde_: hi Mar 27 11:58:21 Fraxinas: gentoo and OE are a little different Mar 27 11:58:27 does anyone have experience with Thecus N2100? Mar 27 12:00:17 hmm of course ^^ Mar 27 12:00:50 RP: Thank God (and the OE devs) for that :) Mar 27 12:02:01 oxo: rwhitby has one iirc Mar 27 12:02:26 * oxo was looking for a `review' of such a box from a hacker's point of view Mar 27 12:03:18 RP what do i need to change so that i can use the statically linked ebml lib? Mar 27 12:04:01 Fraxinas: The better question might be how to build a dynamic ebml library Mar 27 12:05:04 oxo: nslu2-linux.org try Mar 27 12:05:20 k, thanks Mar 27 12:05:25 :) Mar 27 12:07:08 it confuses me though that it doesn't work with the static lib in oe, too Mar 27 12:07:17 when it works just like that on my host architecture Mar 27 12:08:03 Fraxinas: OE is probably overriding the LDFLAGS Mar 27 12:09:14 humm that might be Mar 27 12:20:50 hmm. I just tried pushing to the nslu2 mirror and I don't like the look of the output... Mar 27 12:21:10 401 revisions and 2.9M data transmitted... Mar 27 12:21:16 and its now hung Mar 27 12:23:26 so they stopped syncing? Mar 27 12:24:07 I don't think they carry the stable branch and my push may have upset something. I used to be able to pull from there, I can't now Mar 27 12:24:26 Something really odd is going on :( Mar 27 12:25:06 I have 221 revisions locally which the wolfson mirror doesn't have either :/ Mar 27 12:25:24 did you pull from openmoko.org? Mar 27 12:25:30 no Mar 27 12:25:48 I think the openmoko branching has upset something :/ Mar 27 12:25:50 because there are approx 200 duff revisions attributed to om.org Mar 27 12:26:21 I'm never touched OM, just the main server and now nslu2 and wolfson Mar 27 12:26:43 Somewhere in this mess are 15 revisions from me Mar 27 12:26:56 odd Mar 27 12:27:06 I never pushed OM branch to OE.org at all Mar 27 12:28:11 koen did? Mar 27 12:28:22 viewmtn handle OM branch Mar 27 12:28:27 someone push 200 duff revisions to om.org this morning though Mar 27 12:28:41 I do not remember when pulled last time Mar 27 12:29:04 I push one-two revs from time to time and try to pull daily Mar 27 12:30:21 but I suspect that our monotone machine require 8GHz cpu to be able to handle mtn server Mar 27 12:31:45 The wolfson box reported 'error: timed out waiting for I/O with peer monotone.linuxtogo.org, disconnecting' when it tried to sync yesterday and it's looking like it's in the process of doing the same just now. Mar 27 12:32:03 s/yesterday/this morning/ Mar 27 12:32:13 mtn.oe.org is down as far as I can see from .tw Mar 27 12:33:27 I can mtr to it. Mar 27 12:33:43 Or to 'linuxtogo.org', at any rate. Mar 27 12:33:57 anyone can Mar 27 12:34:13 but mtn is on amethyst.openembedded.net not on ltg (which do redirect) Mar 27 12:34:20 monotone is using 2GB ram and 100% processor Mar 27 12:34:26 on amethyst Mar 27 12:34:42 which is a reason why I 'love' mtn recently Mar 27 12:35:15 Yeah, that'd be consistent with what I'm seeing here. Mar 27 12:35:34 we need petition to Intel and AMD to get 8GHz single core cpus for our monotone servers Mar 27 12:37:09 huhu Mar 27 12:43:36 morning all. Mar 27 12:44:06 thesing: hi Mar 27 12:44:06 hi thesing Mar 27 12:44:12 hi jineld Mar 27 12:44:15 woglinde: hi Mar 27 12:44:50 yo Crofton Mar 27 12:44:54 hi mr_nice Mar 27 12:44:55 hey guys Mar 27 12:44:57 morning crofton Mar 27 12:46:25 there have been some mails/rfcs regarding initramfs generation, does anyone know if this has been sorted out? Mar 27 12:46:32 so far I used an ugly hack for it Mar 27 12:46:53 gm Mar 27 12:47:03 woglinde: do you read angstrom-dev ml? Mar 27 12:47:36 mr_nice nope Mar 27 12:48:02 woglinde: ok Mar 27 12:48:49 mr_nice I have to go Mar 27 12:49:02 my son is watiing in the kindergarten Mar 27 12:49:38 woglinde: hurry up Mar 27 12:49:40 *g Mar 27 12:50:00 Jin^eLD: I have something laying around for initramfs generation I will rfc it asap. Mar 27 12:50:38 thesing: anything I could test right away? Mar 27 12:50:57 in my "hack" I was simply unpacking the rootfs image somewhere and then pointing the kernel config to that directory Mar 27 12:51:23 if you have something that I could test locally - would be nice Mar 27 12:52:21 bonjour Mar 27 12:53:32 Jin^eLD: the problem is thats its mixed with something other I was working on. I have to commit that first. I was away from OE for two weeks so I have to check for bitrot first. Mar 27 12:54:20 oh, ok Mar 27 13:05:58 good morning Mar 27 13:06:42 thesing: hi Mar 27 13:06:45 good morning Mar 27 13:07:00 hi Mar 27 13:07:07 thesing: we are getting impatient for the initramfs/klibc commits ...he he Mar 27 13:07:24 pls check with RP the kernel do_deploy change Mar 27 13:07:36 he said was almost ok Mar 27 13:07:47 only "minor changes" Mar 27 13:08:06 too bad that to push changes you need to connect to mtn server first ;( Mar 27 13:08:20 :-/ Mar 27 13:08:31 thesing: Do you have commit access? Mar 27 13:08:39 RP: yes Mar 27 13:09:05 RP: What are the minor issues with the do_deploy stuff? Mar 27 13:09:09 I'm very much in favour of the do_deploy change and poky has had something similar for a while Mar 27 13:09:25 thesing: I'd just like to see uImage handled in the generic do_deploy as well Mar 27 13:09:34 Poky's does so you could look at that Mar 27 13:10:22 I will. Poky servers work I guess ? ;) Mar 27 13:10:40 thesing: yes :) Mar 27 13:11:31 thesing: http://svn.o-hand.com/view/poky/trunk/meta/classes/kernel.bbclass?rev=4116&view=markup Mar 27 13:11:56 RP: would it be hard to override PR and PV for package generation? Mar 27 13:12:00 thesing: I'm particularly after the package_stagefile call in OE soon Mar 27 13:12:12 thesing: I really don't want to do it Mar 27 13:12:21 It will break things Mar 27 13:13:53 RP: I want PV and PR of initramfs-kernel sync with kernel package. Otherwise upgrading doesn't work. Mar 27 13:14:45 thesing: Just add a RDEPENDS_initramfs = "kernel (= PV-PR)" Mar 27 13:14:46 I wonder when 'mtn pull' will end.. Mar 27 13:16:08 hrw: me too. Mar 27 13:16:24 hrw: while you wait: there is no SRC_URI_append_c7x0 in http://svn.o-hand.com/view/poky/trunk/meta/packages/linux/linux-rp_2.6.24.bb?rev=3677&view=markup Mar 27 13:16:41 ant|work: There doesn't have to be Mar 27 13:17:14 mumble mumble Mar 27 13:17:58 ok, I'm testing the sharp-rc patch(s) so I added it Mar 27 13:18:36 RP: how will this help? initramfs-kernel is a zImage with initramfs included. why should it rdepend on kernel? I can imaging something like RPROVIDES=kernel (= KERNELPV-KERNELPR) in the initramfs recipe. Mar 27 13:19:16 RP: file://mtd-module.patch;patch=1;status=external also unneeded? Mar 27 13:20:12 thesing: ah, I see what you mean Mar 27 13:20:40 thesing: Changing PV and PR at package creation time will break things badly :( Mar 27 13:21:19 * ant|work got lost testing patches during all that defconfig changes Mar 27 13:21:34 ~curse sharp for the 1,2 mb limit Mar 27 13:21:35 May the fleas of a thousand camels infest your most sensitive regions, sharp for the 1,2 mb limit ! Mar 27 13:23:04 * * OE Bug 4127 has been created by  Mar 27 13:23:06 * * cacao-initial-0.98-autobuild Mar 27 13:23:08 * * http://bugs.openembedded.net/show_bug.cgi?id=4127 Mar 27 13:23:39 46 minutes ago started 'mtn pull' - still not finished (hang) Mar 27 13:24:29 RP: would the RPOVIDES solution work? Mar 27 13:25:19 thesing: RPROVIDES are not versioned Mar 27 13:27:11 thesing: If you set PV_packagename = "" and PR_packaename = "" where packagename is the name of the output package you can probably do what you want Mar 27 13:27:29 Where the "" is something which will pull the right version in Mar 27 13:45:02 one hour of pulling.... Mar 27 13:45:35 hrw: so perhaps you have 1 min for checking this: http://www.pastebin.org/25654 Mar 27 13:49:01 ant|work: it is in Richard queue already Mar 27 13:50:34 hrw so I'm not too wrong putting it in SRC_URI_APPEND_c7x0 Mar 27 13:53:31 add it to SRC_URI for all Mar 27 14:16:44 re Mar 27 14:17:05 wb Mar 27 14:48:19 afer 2 hours I ctrl-c "mtn pull" operation... Mar 27 14:48:56 hrw: you're much more patient than me. Mar 27 14:49:08 thesing: I have other things to do Mar 27 14:49:34 restarted it Mar 27 14:50:47 who has control over the mtn servers an can look whats going on? Mar 27 14:52:17 27 13:39 < RP> monotone is using 2GB ram and 100% processor Mar 27 14:52:58 mickey: it's a painful agony for mtn, could you pull the plug? Mar 27 14:53:04 how about killing mtn and restarting it on the server? Mar 27 14:59:37 o.. progress - it is pulling now Mar 27 15:00:49 very slowly but pulling Mar 27 15:02:05 I guess the issue is getting worse by people starting and stopping pulls several times like us. Mar 27 15:41:44 Jin^eLD, RP: http://www.pastebin.ca/959600 is my current version of the initramfs stuff its mixed with the do_deploy stuff. It works on a 2 week old OE tree. Mar 27 15:42:36 thanks, I'll have a look! Mar 27 15:43:05 after 53 minutes it died on i/o error Mar 27 15:43:25 thesing: looks good. I'm not sure about all the bits in kernel.bbclass but its definetly heading the right way Mar 27 15:47:54 RP: you mean the task dependencies? They build an initramfs-kernel + package if virtual/kernel is build and clean them it virtual/kernel is cleaned. An rm-work dependency is missing but I'm not sure what happens if its added and rm-work is disabled. Mar 27 15:49:19 thesing: Don't do that please :( Mar 27 15:49:29 03rpurdie 07org.oe.dev * r1e3a5371... 10/ (1 packages/vte/vte.inc): vte.inc: Disable python, add intltool-native to DEPENDS Mar 27 15:49:34 03rpurdie 07org.oe.dev * r017e6ef4... 10/ (4 files in 3 dirs): lvm2: Add patch to remove -Llibdir from LDFLAGS Mar 27 15:49:39 03rpurdie 07org.oe.dev * r05788b53... 10/ (1 packages/esmtp/esmtp_0.5.1.bb): esmtp: Add --with-libesmtp option to configure else it adds -L/lib to LDFLAGS Mar 27 15:49:41 thesing: If I clean glib-2.0 it doesn't clean everything linking to glib-2.0 Mar 27 15:49:44 03rpurdie 07org.oe.dev * rc3810124... 10/ (5 files in 4 dirs): elfutils: Add 0.131, fix warnings patch for 0.127 Mar 27 15:49:49 03rpurdie 07org.oe.dev * rec772733... 10/ (3 files in 3 dirs): device-mapper: Patch insanity out of Makefiles Mar 27 15:49:53 03rpurdie 07org.oe.dev * r34c03310... 10/ (1 packages/gcc/gcc-cross-kernel-3.4.4_csl-arm-2005q3.bb): gcc-cross-kernel-3.4.4-csl-2005q3: Merge fixes from Poky Mar 27 15:49:58 thesing: There are better ways to handle this (BB_STAMP_POLICY) Mar 27 15:49:58 03rpurdie 07org.oe.dev * rd6a36458... 10/ (3 files in 3 dirs): gcc-3.4.4: Add patch to fix jar location from poky Mar 27 15:50:03 03rpurdie 07org.oe.dev * r88ea87d0... 10/ (6 files in 3 dirs): gcc: Add csl 2006q1 compiler versions from Poky Mar 27 15:50:08 03rpurdie 07org.oe.dev * r53735966... 10/ (4 files in 2 dirs): gcc-4.*: Set ARM_INSTRUCTION_SET to arm so vfp instructions can be avoided within libgcc itself (from poky) Mar 27 15:50:13 03rpurdie 07org.oe.dev * rfc44b8f5... 10/ (14 files in 2 dirs): gcc-4.x: Cleanup and standardise the compiler configuration flags, fixing various bugs in the 4.1.x and 4.0.x versions. Broken libssp and libmudflap libraries should no longer be staged into cross. Mar 27 15:50:17 03rpurdie 07org.oe.dev * r285ba195... 10/ (1 packages/gcc/gcc-package-target.inc): gcc-package-target.inc: Package libgfortran-dev if present, don't package libgcc, libstdc++ or libg2c, these packages from from gcc-cross Mar 27 15:50:22 03rpurdie 07org.oe.dev * rd9f628bb... 10/ (1 packages/gcc/gcc-package-cross.inc): gcc-package-cross.inc: Only provide the packaged libraries, not the corresponding -dev packages which are broken and are provided by gcc Mar 27 15:50:29 RP: is this documented somewhere? Mar 27 15:50:53 thesing: Its a really recent thing but long planned Mar 27 15:51:16 thesing: basically in "full" mode, touching glib will resulting in anything dependning on glib rebuilding Mar 27 15:51:33 its not perfect yet but is the proper generic way to do what you're doing Mar 27 15:51:57 amethyst is idle :) Mar 27 15:56:44 and it took only 3 hours and 4 minutes to pull ;) Mar 27 16:34:31 *internet* how nice :) Mar 27 16:35:11 zecke: been offline? Mar 27 16:35:29 zecke: libssp mystery solved, it wasn't disabled in gcc 4.1.2, it was in 4,2,2. I've synced the recipes up now Mar 27 16:36:08 All the more reason for the gcc cleanup to get some kind of standardisation Mar 27 16:42:31 03rpurdie 07org.oe.dev * re9687e34... 10/ (5 files in 3 dirs): binutils: Add 2.16.1 Mar 27 16:42:36 03rpurdie 07org.oe.dev * rd1dfc5df... 10/ (9 files in 3 dirs): glibc: Add 2.3.6 Mar 27 16:49:52 RP: you once said it took about 4 mins to rebuild from scratch using packaged-staging. What do one need (not) to delete in /tmp for a vacuum-clean build? Mar 27 16:51:19 ant|work: Just tmp/deploy/pstage Mar 27 16:51:27 RP: so my change was innocent :) Mar 27 16:51:39 ich_: I suspect so :) Mar 27 16:52:07 XorA|gone: I want a hand written apology post card (just kidding) Mar 27 16:53:11 RP: well, that /pstage dir was not populated creating images, only by 2 separate builds (zaurus-updater and virtual/kernel) Mar 27 16:53:59 ant|work: run bitbake xyz -c buildall and it will be Mar 27 16:54:19 where xyz covered the things you want to build Mar 27 16:56:15 tcooksey: my reply should arrive shortly Mar 27 16:56:48 zecke: cheers. :-) Mar 27 16:56:54 Good afternoon all Mar 27 16:57:08 trying to track down the maintainer for libtool-native Mar 27 16:58:16 tcooksey: basicly it is due debian renaming. a package "foo" that only contains libfoo.so.1.0.0 gets renamed to libfoo1. Distributions/whatever can INHERIT += "debian" to get this renaming (a policy decision) Mar 27 16:58:40 tcooksey: in your case you have more than one library installed, so it is not obvious what is the leading so and if the package should be renamed Mar 27 16:58:53 tcooksey: you can ignore it, say which one is the leading so, split the packaging Mar 27 16:59:43 Who should I CC for Ticket http://bugs.openembedded.net/show_bug.cgi?id=4112 to get the patch checked in? Mar 27 17:00:34 hillct: attach diff's :) Mar 27 17:00:54 of course Mar 27 17:01:03 er, didn't I? Mar 27 17:02:51 oh, I just attached the full file Mar 27 17:02:55 easy enough Mar 27 17:03:17 hillct: I'm lazy I want to view the diff in my browser :) Mar 27 17:03:24 heh Mar 27 17:03:26 one sec Mar 27 17:03:34 the diff is the staging Mar 27 17:03:37 that's it Mar 27 17:07:34 bye Mar 27 17:09:59 zecke: there ya go Mar 27 17:15:54 hillct: who requires that lib? :) Mar 27 17:16:17 hillct: unified diffs... the result of mtn diff, sorry I assumed that was known to you Mar 27 17:17:07 it probably was, at one point, long ano when I first checked in my stuff Mar 27 17:17:29 the dependency is for ticket 4113 Mar 27 17:21:05 zecke: there ya go Mar 27 17:23:31 thanks Mar 27 17:23:44 zecke: for previous builds of CallWeaver (ticket 4113) we jut fixed the libtool-native staging locally for the slugos 3.10 release but it seems worthwhile to fix it upstream Mar 27 17:24:21 since the upstream recipe seems to have made it's way back into slugos 4.8 Mar 27 17:46:44 RP: for do_deploy I want to commit http://www.pastebin.ca/959764 is this ok with you? it's as in poky with tabs and "addtask deploy before do_build after do_install" instead of "addtask deploy before do_package after do_install" Mar 27 17:47:47 thesing: Can you make it do_package please? That has implications for packaged-staging Mar 27 17:48:40 RP: packaged-staging handles deploy_dir? Mar 27 17:49:00 thesing: it handles output from do_deploy, yes Mar 27 17:49:24 thesing: otherwise feel free to commit and drop any customdo_deploy functions which are uneeded Mar 27 17:49:41 RP: ok. Mar 27 17:56:11 would console-image pull webkit-gtk ? Mar 27 17:56:15 if yes why Mar 27 18:39:05 * * OE Bug 4128 has been created by  Mar 27 18:39:06 * * djvulibre-3.5.19-autobuild Mar 27 18:39:08 * * http://bugs.openembedded.net/show_bug.cgi?id=4128 Mar 27 18:47:22 03thesing 07org.oe.dev * r6b053bb8... 10/ (1 classes/kernel.bbclass): kernel.bbclass: add generic do_deploy task Mar 27 18:47:27 03thesing 07org.oe.dev * r5042c988... 10/ (66 files in 3 dirs): update kernel recipies to use new generic do_deploy from kernel.bbclass Mar 27 19:09:13 03osas 07org.oe.dev * rc6d6222e... 10/ (1 packages/meta/slugos-packages.bb): spandsp promoted for slugos Mar 27 19:10:52 03rodrigo.vivi 07org.oe.dev * r487f86d7... 10/ (1 conf/distro/mamona.conf): Mamona.conf: cleaning and reorganizing it. Mar 27 19:13:41 good evening ! Mar 27 19:14:08 hmm, if I tell angstrom to create an ext2 image - does this image have any partitions Mar 27 19:14:21 I'm trying it with qemu Mar 27 19:14:27 no partition Mar 27 19:14:32 but could not figure out the root parameter so far Mar 27 19:14:55 hmm, root=/dev/hda also does not work (specified the image as -hda) Mar 27 19:14:59 Jin^eLD : or you add root=hda ad kernel parapeter Mar 27 19:15:28 thats what I did Mar 27 19:15:29 hda: unknown partition table Mar 27 19:15:37 it seems it can't figure it out Mar 27 19:15:44 how do the angstrom arm qemu images work? Mar 27 19:15:54 Jin^eLD or you use a script on poky repository to create an image with partition from a ext2.image Mar 27 19:16:25 Jin^eLD don't know i did similar test with x86 arch ... Mar 27 19:16:38 script in poky, thanks for the hint, I will try it Mar 27 19:20:11 I think I found it Mar 27 19:20:12 poky-addptable2image Mar 27 19:22:31 03koen 07org.oe.dev * r62d075b4... 10/ (1 classes/kernel.bbclass): kernel.bbclass: unbreak uImage generation. Mar 27 19:22:56 Jin^eLD: what image did u try with uclibc Mar 27 19:23:33 Khem: self built for mipsel Mar 27 19:23:39 Khem: actually I am still strugling with the uclibc - mips thing Mar 27 19:23:43 :) Mar 27 19:24:02 my static binaries refused to run on the platform, so I wanted to try if the "normal" image, like minimal image Mar 27 19:24:04 would work Mar 27 19:24:54 ping koen Mar 27 19:25:14 I know what to change in OE to compile for mips/uclibc but I wanted to confirm that the produced binaries actually work Mar 27 19:25:23 before submitting a patch Mar 27 19:25:40 gremlin[it]: I guess I will Mar 27 19:25:52 but was seeing that as last resort, so still trying a few things out Mar 27 19:26:06 good Jin^eLD Mar 27 19:26:53 qemu says: No filesystem could mount root, tried: iso9660 Mar 27 19:26:56 why isnt it trying ext2? Mar 27 19:27:01 I compiled ext2 into the kernel Mar 27 19:27:04 and I can loopback mount the image Mar 27 19:28:02 gremlin[it]: Send koen an e-mail, he's currently on a self-imporsed IRC sabattical Mar 27 19:28:54 ahhhh ok ... maybe i send a sms so ... isn't important anyway :) Mar 27 19:29:23 gremlin[it]: I think he's actually trying to finish school this time :) Mar 27 19:29:45 heheheh i thought :) Mar 27 19:30:04 * * OE Bug 4129 has been created by  Mar 27 19:30:06 * * gnuplot-4.2.0-autobuild Mar 27 19:30:08 * * http://bugs.openembedded.net/show_bug.cgi?id=4129 Mar 27 19:36:45 l8r everyone Mar 27 19:38:35 Jin|away: use -hda option of qemu Mar 27 19:39:01 Jin|away: and in -append specify root=/dev/sda Mar 27 21:12:30 hiya! Mar 27 21:13:16 any ideas why I might suddenly end up build linux-bd-neon-2.6-2.6.22-r2? Mar 27 21:14:23 jeremy_laine: is it a kernel recipe? Mar 27 21:15:14 thesing: it is, but I should be picking up linux-2.6.24 (I'm using mpc8313e-rdb) Mar 27 21:15:46 thesing: that was still the case yesterday, but today's mtn pull must have busted it Mar 27 21:16:26 maybe its because of the do_deploy changes. Mar 27 21:17:24 I updated some kernel recipes but it shouldn't affect which kernel is selected. Mar 27 21:17:44 thesing: to boot linux-bd-neon-2.6-2.6.22-r2 doesn't even build! Mar 27 21:18:57 thesing: I have PREFERRED_PROVIDER_virtual/kernel ?= "linux" in the machine config file, what more can I do? Mar 27 21:20:20 jeremy_laine: why "?=" ? Mar 27 21:22:16 jeremy_laine: you know about "bitbake -e" ? Mar 27 21:23:48 changing ?= to = made no difference Mar 27 21:24:31 sure have to set to "linux" and not "linux-bd-neon" ? Mar 27 21:25:47 bitbake -e gives no references to "neon" Mar 27 21:26:07 I see my virtual/kernel definition come up correctly Mar 27 21:27:12 jeremy_laine: hrm... I remember that was caused by a bug in linux-bd-neon, but that should have been fixed Mar 27 21:27:22 if you build it explicitly 'bitbake virtual/kernel' it work ? Mar 27 21:27:27 * flo_lap thinks we shoudl get rid of this anyway Mar 27 21:28:15 bitbake virtual/kernel build the neon kernel, odd.. Mar 27 21:28:51 ok ... so maybe is just distro / image that don't include the right kernel Mar 27 21:30:25 gremlin[it]: I don't agree, there is something messed with virtual/kernel, if it points to "linux", why am I building "linux-bd-neon"? Mar 27 21:30:55 hmm strange indeed Mar 27 21:30:59 maybe I reverted the neon fix somehow. Mar 27 21:31:14 and why does it fail to build? Mar 27 21:31:59 probably the defconfig makes no sense with my cross-compiler Mar 27 21:32:11 (I am building for mpc8313e-rdb) Mar 27 21:32:30 mhh hbut if you build directly it work ... Mar 27 21:34:21 the really weird things is that a grep of "bd-neon" on org.oe.dev gives very few results Mar 27 21:34:39 so I'm stumped as to how it is getting selected Mar 27 21:38:46 "bitbake linux" doesn't work, nor does "bitbake linux-2.6.24" Mar 27 21:43:17 everything is fine if I revert to revision ee54b47d88c9b12e16112560ea26459766cbb606 Mar 27 21:44:07 thesing: this the last revision before the do_deploy changes Mar 27 21:47:32 thesing: FWIW I started a fresh rebuild one hour ago for c7x0 and it was building the (outdated but) right kernel linux-rp_2.6.23 for the machine Mar 27 21:47:43 thesing: commit 6b053bb87e29cff98f94c410ec8687851b734b73 seems to introduce the breakage for me Mar 27 21:48:51 jeremy_laine: it builds the right kernel for me. you use the linux recipe? Mar 27 21:50:22 thesing: yup, I want "linux_2.6.24" to be selected Mar 27 21:50:56 thesing: it seems to be 100% reproducible for me: apply the patch to kernel.bbclass and it breaks, revert the patch and it works Mar 27 21:51:34 jeremy_laine: obviously you changed DEFAULT_PREFERENCE = "-1" Mar 27 21:52:17 jeremy_laine: sorry: DEFAULT_PREFERENCE_mpc8313e-rdb = "1" Mar 27 21:52:34 ant|work: you had me checking :) Mar 27 21:52:41 =) Mar 27 21:52:55 same for c7x0, will be pushed one day Mar 27 21:53:37 ~lart koen Mar 27 21:53:38 * ibot takes large quantities of Krispy Kream donuts and stuffs them one after another down koen's throat until koen puts on 150lbs Mar 27 21:55:01 RP: Do you want to answer to this stable branch crap announced on the Angstrom list? Mar 27 21:55:55 thesing: I seem to have narrowed it down some, it's the "python __anonymous ()" bit in kernel.bbclass that seems to mess the build for me Mar 27 21:57:54 RP: I found a QA problem with libgnomecups. it calls for global level fix, which is above my bitbake knowledges: If package contains bindir/*-config, then it most probably should be part of devel package, and copied to staging. Exception may be possible via bb file (or grep for --cflags inside *-config to be sure thet it is devel file). Mar 27 21:58:36 thesing: confirmed, I have updated to HEAD and if I remove the "python __anonymous ()" definition, all is well Mar 27 21:59:11 jeremy_laine: packages/linux/linux.inc seems to have the save python __anonymous function Mar 27 22:01:22 jeremy_laine: can you try s/u-boot-mkimage-openmoko-native/u-boot-mkimage-native/ in kernel.bbclass and remove the anonymous pyhton function from linux.inc? Mar 27 22:02:47 thesing: uhm, it's already u-boot-mkimage-native in kernel.bbclass, do you mean the other way around? Mar 27 22:04:47 jeremy_laine: no its fine then. Just try to remove the anon pyhton func in linux.inc Mar 27 22:05:50 nope, that doesn't work Mar 27 22:10:48 jeremy_laine: strange. So it works if you remove the anon python func from classes/kernel.bbclass but not if you remove it from packages/linux/linux.inc ? Mar 27 22:11:09 thesing: that's right Mar 27 22:11:26 hi there I have a command inside a task that needs root permission... I'd like to use sudo command but I the input and output to get the password are redirected ... Does any one have an idea to do it? Mar 27 22:11:56 vivijim: don't do it. Use fakeroot Mar 27 22:12:45 thesing: I forgot to say... the fakeroot doesn't work in my case... I'm trying to run debootstrap command Mar 27 22:12:57 thesing: it boils down to a single line: bb.data.setVar("DEPENDS", depends, d) Mar 27 22:13:15 if I comment this line out, it works, if it's present it breaks Mar 27 22:14:22 jeremy_laine: I think its because the uboot*opemoko and uboot* conflict and so bitbake thinks that linux_* packages can't be build. Mar 27 22:15:30 jeremy_laine: does it work if you remove the anonymous func from linux.inc and replace the mkimage command with openmoko-mkimage? Mar 27 22:18:00 thesing: have removed the anon func from linux.inc, not sure where you want me to replace mkimage Mar 27 22:18:21 (so far I still end up with linux-bd-neon) Mar 27 22:19:21 jeremy_laine: in anonymous func in kernel.bbclass. So the anon function is moved from linux.inc to kernel.bbclass. Mar 27 22:20:41 thesing: yup, that works Mar 27 22:21:43 thesing: I'll commit that if it's OK with you Mar 27 22:23:04 jeremy_laine: I think it would be better to write an email to oe-devel and comment out the anon python func from kernel.bbclass Mar 27 22:24:47 jeremy_laine: I don't know what the difference between uboot-* and uboot-*-openmoko is and probably some other kernel needs uboot-* and doesn't work with uboot-*-openmoko Mar 27 22:25:10 thesing: I'll just commit the change to kernel.bbclass in that case, it is enough to fix the problem Mar 27 22:25:52 (it restores the previous behaviour) Mar 27 22:26:30 wait a moment. Mar 27 22:26:39 thesing: my understanding is that uboot-*-openmoko is a superset of uboot Mar 27 22:26:49 there seems to be no mkimage without openmoko in oe. Mar 27 22:27:05 ok, so the change should be totally painless Mar 27 22:28:18 thesing: mkimage is in the u-boot sources (I got it built during my u-boot-zaurus experiments) Mar 27 22:28:22 yes. now its clear why you couldn't build your kernel: bitbake couldn't find the dependency. Mar 27 22:28:47 ant|work: mkimage-native too? Mar 27 22:30:05 ant|work: you're right u-boot-utils-native has it. Mar 27 22:30:37 * ant|work yet browsing with viewMTN... Mar 27 22:31:10 jeremy_laine: could you try if it works too with u-boot-utils-native? Mar 27 22:31:12 thesing: in u-boot.inc Mar 27 22:31:53 thesing: if we change to u-boot-utils-native we will break something for sure Mar 27 22:32:32 to restore the previous situation, there is only one way: use u-boot-openmoko-native Mar 27 22:32:55 hi ant|work :) Mar 27 22:32:57 next we can discuss on oe-devel why this is needed, but at least we fix the breakage Mar 27 22:34:23 u-boot-*-opemoko seems to be the same as u-boot-utils-native with lots of patches added. Mar 27 22:34:44 thesing: correct, that's what I meant by "superset" Mar 27 22:35:09 Tartarus: hey...this time I did not test samba because of current apparent WPA breakage..no network Mar 27 22:35:21 ant|work, heh Mar 27 22:35:24 k Mar 27 22:35:31 OE or unrelated? Mar 27 22:35:38 i've got that wpa supplicant patch too :) Mar 27 22:35:49 .dev Mar 27 22:36:11 I'll have to check both then ;-) Mar 27 22:36:16 ant|work, k Mar 27 22:36:29 4006 :) Mar 27 22:36:37 strange is WPA was working not long ago Mar 27 22:37:07 Jin|away: so you are commiting s/mkimage*/mkimage-openmoko/ and remove python anonymous from linux.inc and write an e-mail about it to oe-devel? Mar 27 22:41:43 jeremy_laine: last line was for you. Mar 27 22:41:52 thesing: correct Mar 27 22:42:22 great. Mar 27 23:03:30 hrw|gone: BTW, I don't have any thecus boxes Mar 28 00:13:43 03thesing 07org.oe.dev * r42f9a5d8... 10/ (1 packages/linux/linux-rp_2.6.24.bb): linux-rp_2.6.24.bb: reenable accidently diabled hctuni.patch Mar 28 00:13:47 03jeremy_laine 07org.oe.dev * r860b69bf... 10/ (1 classes/kernel.bbclass packages/linux/linux.inc): kernel.bbclass,linux.inc: move dependency on u-boot-openmoko-native to kernel.bbclass Mar 28 00:13:52 03utx 07org.oe.dev * rda3f9793... 10/ (4 files in 3 dirs): Mar 28 00:13:52 Sharp CE-RHx support update Mar 28 00:13:52 * added CE-RH2 support for Akita Mar 28 00:13:52 * added CE-RH1 support for c7x0 Mar 28 00:13:53 * patch comments Mar 28 00:43:46 hi all Mar 28 00:47:50 gnite **** ENDING LOGGING AT Fri Mar 28 02:59:57 2008