**** BEGIN LOGGING AT Fri Mar 28 02:59:57 2008 Mar 28 04:16:51 03rwhitby 07org.oe.dev * rdd15f7f4... 10/ (4 files in 3 dirs): ftpd-topfield: Updated to 0.7.5 and added the syslog patch Mar 28 06:06:10 03mwester 07org.oe.dev * r3f7c924d... 10/ (4 files in 4 dirs): Mar 28 06:06:10 defconfigs: Update ixp4xxx 2.6.24.4 defconfigs to disable PREEMPT, and switch from "cubic" to "reno" Mar 28 06:06:10 as the default TCP congestion control algorithm (avoids a kernel crash) Mar 28 07:03:41 moin Mar 28 08:31:44 morning Mar 28 08:31:49 hoi Mar 28 09:02:36 g'morning Mar 28 09:07:51 good morning Mar 28 09:13:42 Tartarus: I think Koen was right and the WPA problems come from modules-renaming https://dev.openwrt.org/browser/trunk/package/kernel/modules/crypto.mk Mar 28 11:35:06 morning all. Mar 28 11:36:34 hi thesing Mar 28 12:05:05 * * OE Bug 2437 has been RESOLVED (INVALID) by heinold(AT)inf.fu-berlin.de Mar 28 12:05:07 * * libqte-opie wont compile with uclibc Mar 28 12:05:09 * * http://bugs.openembedded.org/show_bug.cgi?id=2437 Mar 28 12:05:22 morning folks Mar 28 12:05:37 please remind me... what do we need to build packages for RDEPENDS nowadays? Mar 28 12:05:57 bitbake task-foo does only emit the ipk for task-foo. while it builds the RDEPENDS, it does not package them Mar 28 12:06:00 was that BB_SCHEDULE? Mar 28 12:06:23 mickeyl: bitbake task-foo -c buildall ? Mar 28 12:06:36 aaah Mar 28 12:06:37 or BB_DEFAULT_TASK = "buildall" Mar 28 12:06:39 thanks Mar 28 12:06:48 that was it Mar 28 12:06:52 my memory is a sieve Mar 28 12:12:04 morning Mar 28 12:17:06 mickeyl: does monotone server on amethyst runs in normal system or xen? Mar 28 12:21:43 hrw: normal system Mar 28 12:22:07 normal system. i want full 4core power :) Mar 28 12:23:48 mickeyl: monotone is 1core Mar 28 12:24:13 mickeyl: and for git or mercurial I would suggest xen instance which will do only this Mar 28 12:24:27 hrw: why? Mar 28 12:24:27 less breakage possible if someone will get into system somehow Mar 28 12:26:34 this way you can have normal system which runs some services and allow only few people to login and xen instance(s) for stuff which require giving access for external people Mar 28 12:26:35 i don't know whether i want to do that effort Mar 28 12:27:19 Lets see how things work out. We have the option of doing that if needed Mar 28 12:27:59 I would like to get rwhitby opinion how nslu2 people use xen Mar 28 12:28:04 on server(s) Mar 28 12:28:17 Is there a date when we move to a new scm or is even decided wich one it will be? Mar 28 12:28:44 thesing: its under discussion. We've basically agreed we need some trials to check some things Mar 28 12:28:50 hrw: we have many xen servers Mar 28 12:29:39 rwhitby: what do you think about my idea? Mar 28 12:29:56 we have about 11 xen instances, on two physical machines at OSUOSK Mar 28 12:29:58 OSUOSL Mar 28 12:30:19 hrw: I'll msg you a private link to our stats system so you can see Mar 28 12:30:28 ok Mar 28 12:31:05 for instance, we have our monotone server in a xen instance by itself, so that it can't resource hog and kill anything else Mar 28 12:31:32 and we have the autobuilder in a xen instance, and then we host multiple projects (nslu2-linux, nas-central, foonas) all in xen instances on the same physical machine Mar 28 12:32:02 we also have a developer-access xen instance, to which we can give developers shell access without worrying about security too much Mar 28 12:32:15 (and that would be the idea for the git server) Mar 28 12:32:30 git or mercurial Mar 28 12:32:51 yep, either. we already do it in nslu2-linux for monotone Mar 28 12:33:13 ka6sox and dyoung can set up xen instances in their sleep now :-) Mar 28 12:33:45 ;) Mar 28 12:33:50 The OE server is just getting started and I'm not sure many of its admins know xen very well but lets see how it goes Mar 28 12:34:10 RP: I'm sure ka6sox would be happy to help Mar 28 12:34:15 iirc xen require cpu with virtualization support? Mar 28 12:34:27 It partly depends how we setup the git repository and I'm leaning towards single user atm Mar 28 12:34:58 hrw: the two machines we have a Xeon's I believe. Mar 28 12:35:27 rwhitby: I ask because my amd64 lack virt :( Mar 28 12:35:59 hrw: i thought (and please check this yourself) that you can run xen linux on linux without virt support. Mar 28 12:37:02 will do Mar 28 12:40:19 RP, mickeyl: nslu2-linux has been blessed by the admins at OSUOSL being slug fans, so we have two slots there. we'd be happy to set up a git server xen instance. Mar 28 12:41:44 rwhitby: ok, thanks. We'll see how these trial setups work out and take it from there Mar 28 12:42:31 the other thing about having separate xen instances for each service is that you can measure what they need. e.g. we know that monotone for nslu2-linux requires 20% of a CPU and 600MB of memory steady state. Mar 28 12:42:53 and keeps that xen instance at a load average of around 0.5 max Mar 28 12:43:40 rwhitby: I am cautiously in favour of xen but one step at a time :) Mar 28 12:43:46 and can push traffic when syncing at 3.5MB/sec Mar 28 12:44:34 hrw: if you want to run linux in xen you don't need virt support in cpu. Only if you want to run unmodified OS as guest. Mar 28 12:45:21 thesing: yeah, that's what I remembered. Mar 28 12:45:34 based on the nslu2-linux experience, I run Xen on the servers at work now too. Mar 28 12:46:30 thesing: thx Mar 28 12:46:43 it's in nslu2-linux's interest for OE to have stable, well managed servers, so our offers of help are not all altruistic :-) Mar 28 12:49:30 today uclibc 0.9.29 fails to compile for angstrom/hx4700 with "error: conflicting types for 'build_wcs_upper_buffer'" (http://en.pastebin.ca/960736) anybody seen this before? Mar 28 12:52:37 has anyone tried bluetooth on any arm board using oe? Mar 28 12:53:08 works fine on om-gta01 Mar 28 12:54:17 profiles like headset, sync...? Mar 28 12:54:27 treo650 connects via dund to an nslu2 running OE Mar 28 13:04:49 rwhibty: did you care to modify the bluetooth class in nslu2 hcid.conf (oebug 363)? Mar 28 13:05:25 ~seen Laibsch Mar 28 13:05:29 laibsch was last seen on IRC in channel #oe, 6d 11h 29m 39s ago, saying: 'polyonymous_: Please sent an email to XorA'. Mar 28 13:05:38 just to know whether the phone found easily the dund profile Mar 28 13:06:49 * steliosk sends an email to ml about scm and ducks for cover Mar 28 13:08:32 !oebug 363 Mar 28 13:08:33 * * Bug 363, Status: NEW, Created: 2005-10-01 08:39 Mar 28 13:08:34 * * S.G.Pickering(AT)bath.ac.uk: bluez: hcid.conf has hard-coded BT class and the class is malformed Mar 28 13:08:35 * * http://bugs.openembedded.org/show_bug.cgi?id=363 Mar 28 13:09:25 rwhitby: it seems there are python applets for modifying it on the fly (Suse - Yast) Mar 28 13:10:02 ant|work: nslu2 uses class 0x820100 Mar 28 13:10:26 k Mar 28 13:10:31 bluez hcid.conf is a good example of the historical PDA-ness of OE Mar 28 13:13:57 03tmbinc 07org.oe.dreambox * r02ef2324... 10/ (1 packages/dreambox/dreambox-dvb-tools-v3.bb): dreambox-dvb-tools: use 1.3 for new showiframe Mar 28 13:20:57 are there any issues w/ setting up oe on amd64? Mar 28 13:21:12 summatusmentis: none Mar 28 13:21:17 alright, thanks HRH_H_Crab Mar 28 13:21:27 crap, I always do that. thanks hrw! Mar 28 13:21:28 or maybe something is on pure-64bit system Mar 28 13:21:32 no longer nowadays Mar 28 13:21:38 * hrw use amd64 with ia32 libs installed Mar 28 13:21:41 we had all sorts of problems 1 year ago Mar 28 13:21:47 oh, I see Mar 28 13:21:48 now it seems sorted out. Mar 28 13:21:53 wonderful Mar 28 13:21:53 03utx 07org.oe.dev * r2af4eb2f... 10/ (1 packages/linux/linux-rp-2.6.24/sharpsl-rc-r2.patch): Sharp Remote sharpsl-rc-r2.patch fix. Mar 28 13:21:53 i have a pure 64 bit system here Mar 28 13:22:05 * summatusmentis goes to setup debian amd64 in vmware fusion Mar 28 13:22:29 I remember that my first paid OE related work was 'fix python on amd64' Mar 28 13:24:59 http://thedailywtf.com/Articles/Out-of-Balance.aspx Mar 28 13:30:54 hi mickeyl hrw ! Mar 28 13:31:05 kalimera steliosk Mar 28 13:31:53 As for the amd64 don't be 100% sure. Have you ever checked the sizes of the resulting binaries ? Mar 28 13:32:09 hrw: were you setting up debian with encrypted lvm a while back? Mar 28 13:32:20 steliosk: all my OE powered devices runs binaries built on amd64 Mar 28 13:32:31 summatusmentis: yes - Debian installer supports it out-of-box Mar 28 13:32:45 right, and it doesn't cause any slow downs? Mar 28 13:33:02 a couple of months ago i noticed that some of binaries produced on 64bit machines had different md5 sums and where actually a bit bigger in size Mar 28 13:33:19 summatusmentis: did not noticed it on my pentium M 1.6GHz laptop Mar 28 13:33:25 ok, thanks Mar 28 13:33:28 but never looked into it with details Mar 28 13:33:31 it used to be the case that nslu2 images built on 64bit were too big to fit. dunno if it's still true, cause since then we've told people to only build nslu2 stuff on 32 bit. Mar 28 13:34:08 * florian still remembers when he tried OE on a PPC 64bit machine the first time Mar 28 13:34:10 we even set up a 32bit xen instance for out autobuilder, cause we couldn't trust 64bit Mar 28 13:35:03 rwhitby : well probably that's similar to what i have notice Mar 28 13:36:06 florian : I got a Pegasus G4 1Ghz with debian, and i am planning on trying OE on it, but no time at the moment Mar 28 13:36:51 steliosk: We had an IBM OpenPower 720 around for testing some years ago Mar 28 13:37:58 * ant|work is waiting for standard adopting of gcc-4.3 (-march=core2 and -mtune=core2 are present and functional) by bye prescott/nocona Mar 28 13:38:11 heh OE on cell is the next step ;) Mar 28 13:38:23 :-) Mar 28 13:39:26 ant|work: and -march=geodelx Mar 28 13:40:00 hrw: for AMD, of course Mar 28 13:40:23 anyone read my email on ml ? Mar 28 13:40:34 steliosk: oe-private one? Mar 28 13:41:01 yes Mar 28 13:41:58 I have to think about reply Mar 28 13:42:23 hrw : Is this a good think or bad think ? :) Mar 28 13:43:17 steliosk: idea is nice Mar 28 13:43:35 dev->testing->stable Mar 28 13:43:45 1. push XYZ to .dev Mar 28 13:43:50 morning Mar 28 13:44:03 2. build it for arm/x86/ppc angstrom/generic Mar 28 13:44:27 3. if builds (and works?) then request adding to testing Mar 28 13:47:37 hrw : yes something in that context Mar 28 13:51:57 steliosk: how can a md5sum of different builds (even on the same machine) be the same? You'ld have to skip summing all the metadata the compiler throws in. Mar 28 13:52:27 steliosk: if it's possible let me know. maybe md5summing the correct linker sections makes sense. Mar 28 13:58:08 I keep hearing about this size issue but I thought modern binutils fixed it Mar 28 13:58:49 so size IS important. Mar 28 13:59:06 RP: we have kernel-module-sir-dev package.bbclass thinks it is a -dev package and adds update-modules-dev to its RRECOMMENDS. Any Idea how do change this? Mar 28 14:00:18 thesing: Its an RRECOMMENDS so in theory its harmless but we do need to make the code in package.bbclass more intelligent Mar 28 14:00:49 RP: well atm it pulls update-modules-dev into images Mar 28 14:01:10 thesing: ah, the package exists, right :/ Mar 28 14:01:32 thesing: Probably for now, add a blacklist and add kernel-module-* to it Mar 28 14:02:07 ok. Mar 28 14:11:03 re Mar 28 14:11:06 Good Morning Mar 28 14:11:30 hi mwester-laptop Mar 28 14:11:36 mwester even! Mar 28 14:12:38 I've cloned myself :) Mar 28 14:12:47 (scarey, huh?) Mar 28 14:13:07 mwester: Can you teach the rest of us the secret? Mar 28 14:13:43 Er, nope. There can be only one evil genious to take over the world. Mar 28 14:14:34 But for now, I'll settle for a quiet day at work, so I don't have to do any real work :D Mar 28 14:15:38 Hmm... now there's multiple RP's too. Mar 28 14:16:06 * RP__ couldn't resist Mar 28 14:16:13 hehe! Mar 28 14:16:43 RP*: how do I do packaged staging for SlugOS -- any pointers for where to start? Mar 28 14:17:14 mwester: Basically add INHERIT += "packaged-staging" and it will become active Mar 28 14:17:26 That simple... Mar 28 14:17:39 Its even documented at the top of the .bbclass file :) Mar 28 14:18:18 I can do that. I understand, then that this will cause each package to package up what it normally stages, and enable bitbake to unpackage it into the staging area instead of rebuilding? Mar 28 14:18:26 I don't claim it works perfectly yet, I do claim it works better than nothing, shouldn't break anything and if people start using it development will move forward faster Mar 28 14:18:43 mwester: Ah, you do need bitbake 1.8 svn branch head Mar 28 14:19:22 I see it as a fundamental stepping stone to my ideal, so I'd like to see if I can get it working with SlugOS. Mar 28 14:19:33 mwester: Yes, it will put files into tmp/deploy/pstage. If you then wipe out tmp except that directory and rebuild, it should replicate staging Mar 28 14:20:07 Does this interact in any way with the external toolchain? Mar 28 14:20:08 mwester: I detailed a test on the oe list where I made to builds, then compared the tmp directory contents Mar 28 14:20:17 two builds Mar 28 14:20:43 in theory they should be identical, in practise they weren't but they were really close :) Mar 28 14:21:01 hm can some look gst-plugins, I think the esound dependency can be removed Mar 28 14:21:02 mwester: external toolchains are a different question Mar 28 14:21:35 ;) Ah, but I'd like them to not be so different. If you have a moment, I'd like to toss out an idea. Mar 28 14:22:18 mwester: native and cross staging packages have the constraint of needing to be played in the path they were built for. You can replace native packages with ASSUME_PROVIDED and meta-toolchain can replace cross packages Mar 28 14:22:25 mwester: go on... Mar 28 14:24:34 Consider the use case where I have need to make a change to a user-space component on a specific variant of my product. I can use the external toolchain to avoid building that, but I'd like to also have the base libraries for that product pre-populated. So Mar 28 14:25:41 mwester: Is this the person I'd call the "application developer" ? Mar 28 14:25:58 if we abstract the idea of the external toolchain into the concept of "assemblies", where an assembly is a collection of packages that are essentially packaged staging, I can easilly pre-populate my work environment with anything -- not just a toolchain. Mar 28 14:26:09 No, not limited to application developer. Mar 28 14:26:43 ok. I'll be quiet for a minute :) Mar 28 14:27:48 packaged staging doesn't just cover the toolchain, it covers everything Mar 28 14:28:14 One can then build on that idea to add "PREFERRED_VERSION" or equiv to assemblies -- so that I can setup a local.conf file that causes the correct toolchain to appear, the correct "base assembly" (whatever that might be, but perhaps kernel, core libraries, init scripts, etc), any other "assemlies" I need Mar 28 14:28:54 That's why I'm intruiged by packaged staging -- it seems to be the magic we need to implement something like this. Mar 28 14:29:16 mwester: Its the same thing to what you describe Mar 28 14:29:51 mwester: If you take an empty tmp directory with just the pstage package files in and then bitbake "something", it will 'build' all of "something"'s dependencies using the staging packages Mar 28 14:30:08 if the staging packages are valid a build is just an untar Mar 28 14:30:26 Yes, that's the implementation of that low-level bit. Mar 28 14:30:57 mwester: Apart from getting the packages, what is left? Mar 28 14:30:57 What we/I need to figure out is how to create the concept of an assembly, version it, and ensure that bitbake dependency checking stops at the assembly level. Mar 28 14:31:28 mwester: Why do you need all that? Mar 28 14:32:03 Lets assume for a moment that bitbake can check some urls for these packages and download them if present Mar 28 14:32:23 Ok. Mar 28 14:32:41 You put up a feed of several packages Mar 28 14:33:10 a user them runs bitbake foo on a distro setup to search that source for prebuild packages Mar 28 14:33:30 Your assembly would just be the list of packages you put in the "feed" ? Mar 28 14:34:20 bitbake's version checking is actually more clever than that as if the distro setup says it needs bar 3.4.5-r6 and only 3.4.5-r5 is available it will build instead of downloading Mar 28 14:34:59 likewise : what do you mean by "different builds' ? What i did was to checkout the same mtn revision on a 32bit machine and on a 64bit machine and build from scratch both of them Mar 28 14:35:07 Ideally, yes. What I wish to avoid is for bitbake foo to do any dependency checking into that assembly. The assumption is that I have gone through the trouble to ensure the assembly is "good", and regardless of what/how other things have changed the assembly cannot. Mar 28 14:35:41 So I do not want bitbake to build anything provided by the assembly -- although warnings might be helpful. Mar 28 14:35:44 steliosk: I mean, did you ever find two executables have the same md5sum, even with two builds at the same machine? Mar 28 14:36:12 likewise : shouldn't they ? Mar 28 14:36:39 mwester: In simple terms you'd then modify the do_prepopulate_staging task to error if it couldn't find a package then Mar 28 14:36:52 mwester: Effectively trivial Mar 28 14:37:07 I hadn't thought of implementation, but it's good if it is trivial :) Mar 28 14:37:14 steliosk: they "should" but I suspect the compiler throws in metadata such as build time, comments, etc. that make their contents differ. never tested this though. Mar 28 14:37:26 steliosk: I'm quite sure the metadata changes when you change build host. Mar 28 14:37:33 mwester: bitbake would do checking but you'd error if the configurations didn't match Mar 28 14:38:14 likewise : also size was different but it looked like the .o files and they seemed to have the same. This was not extensively tested though Mar 28 14:38:27 is there any reason to not run OE on debian unstable? Mar 28 14:38:43 mwester: Presenting packaged-staging to the user needs some thought but I think the foundations are there for it Mar 28 14:38:52 summatusmentis: other than running in yet-unknown problems, no Mar 28 14:39:23 likewise : i am not sure that metadata creeps in, especially in striped files Mar 28 14:39:30 likewise: ok, thanks Mar 28 14:39:40 steliosk: I'll test this right now :-) Mar 28 14:40:00 Well, clearly the right place to start is in getting packaged staging working for SlugOS - I'll start with that. I'm also interested in an external toolchain for same; any simple magic to create that? Mar 28 14:40:36 mwester: In theory "bitbake meta-toolchain" Mar 28 14:40:47 mwester: Make sure you have the needed -sdk versions available Mar 28 14:40:53 RP: i would commit http://www.pastebin.ca/960850 if this is ok with you. Mar 28 14:40:56 (gcc/binutils) Mar 28 14:41:27 thesing: yes, ok Mar 28 14:41:56 RP: thanks for your help. I'll work on this, and see what I can do with the assembly mechanism later. :) Mar 28 14:42:36 RP: do you think the evas-native issue is self healing? I doubt that :) Mar 28 14:42:49 mwester: Its a case of starting somewhere and working out what else we need. I don't claim packaged-staging is 100% right, I do claim its ready for people to explore and enhance Mar 28 14:44:36 steliosk: the stripped tmp/rootfs/bin/busybox has a different md5sum on each rebuild. Mar 28 14:44:40 zecke: No, I don't think so Mar 28 14:45:03 zecke: I'd like to add your check for oe_libinstall multiple matches and see how many problem areas we have Mar 28 14:46:18 likewise : hmmm can you diff them and see what's different ? Mar 28 14:47:15 RP: yes, I would like to see this patch in .dev and see what is breaking Mar 28 14:47:32 RP: I will propably readd the disapproved patch as well (as it was not causing the error) Mar 28 14:48:33 hmm, lets see how many other packages have this problem Mar 28 14:49:00 03thesing 07org.oe.dev * r36467803... 10/ (1 classes/package.bbclass): Mar 28 14:49:00 package.bbclass: fix handling of kernel-modules which end with '-dev' Mar 28 14:49:00 Kernel-modules which end with -dev get update-modules-dev Mar 28 14:49:00 as RRECOMMENDS so update-modules-dev gets pulled in images. Mar 28 14:49:00 So we blacklist kernel-module packages for now. Mar 28 14:49:08 steliosk: i'ld need to diff the objdump sections ad see. No time for that now, though. Mar 28 14:49:17 s/ad/and Mar 28 14:58:58 likewise: It would make a nice QA test program :) Mar 28 15:00:57 steliosk: so I diffed them, there is a timestamp left in our executables. Mar 28 15:01:07 steliosk: looking in which section... Mar 28 15:03:15 03mickeyl 07org.oe.dev * r13170805... 10/ (1 packages/python/python-dbus_0.82.4.bb): python-dbus 0.82.4 this is using pkgconfig, so inherit pkgconfig Mar 28 15:03:28 steliosk: It's probably inserted by the busybox make/build system. Most packages have this, that's why you cannot do a md5sum on the result... Mar 28 15:04:26 ~blame florian Mar 28 15:04:27 * ibot blames florian (and Canada) for all the evil in the world Mar 28 15:04:54 hmm... didn't work that time Mar 28 15:07:40 we want libgcc in images, don't we? Mar 28 15:08:08 yes Mar 28 15:08:51 its not pulled in atm. Mar 28 15:09:34 which package should rdep on libgcc? Mar 28 15:11:33 maybe task-base? Mar 28 15:11:50 thesing: anything linking against it should be picked up by shlibs code Mar 28 15:15:30 RP: well its not working. I'll add it to task-base locally. Mar 28 15:15:44 * mwester did that too. Mar 28 15:15:59 someone needs to work out what broke and fix it properly :/ Mar 28 15:16:19 I do have it on my list of things to look at... Mar 28 15:16:35 RP: where is the shlib code? package.bbclass ? Mar 28 15:16:43 thesing: yes Mar 28 15:20:04 RP: it seems that libgcc is not in NEEDED but you get a runtime warning if something tries do call pthread_cancel for example. (I checked busybox) Mar 28 15:20:49 glibc configure - mipsel-angstrom-linux-gcc -E complains about not finding include/limits.h - is it missing something like -isystem ${CROSS_DIR}/${TARGET_SYS}/include-fixed in the CFLAGS or something? I tried _append'ing but it did not help Mar 28 15:20:59 thesing: we cannot be sure, libgcc most always come with a system. Mar 28 15:21:21 thesing: something changed in gcc which means its no longer in NEEDED? Did that used to be the case? Mar 28 15:21:56 Jin^eLD: do you have a limits.h? somewhere? Mar 28 15:22:42 zecke: it is in include-fixed Mar 28 15:22:51 for uclibc adding CFLAGS_append fixed the problem Mar 28 15:22:54 but glibc seems to be more complicated Mar 28 15:23:05 I think there was some gcc related change done that introduces this include-fixed directory Mar 28 15:23:42 sounds like a run of fixinclude on some header files (hopefully not your host) Mar 28 15:23:48 but then again, I have no idea Mar 28 15:24:02 well I just noticed that some includes are staged in include and some in fixed-include Mar 28 15:24:18 all I know is when you compile glibc, your limits.h comes from either glibc-initial or gcc/newlib Mar 28 15:24:20 which seems to be OK from gcc's standpoint, at least I googled and found out that it's a common practice Mar 28 15:24:25 I just think it has not been used in OE Mar 28 15:24:36 hm Mar 28 15:25:04 * * OE Bug 3345 has been RESOLVED (FIXED) by Mar 28 15:25:06 * * ecore-native stages unusable libraries Mar 28 15:25:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3345 Mar 28 15:25:21 I even think the problem doe snot appear when building for arm Mar 28 15:25:22 not sure why Mar 28 15:25:41 but I get it for mipsel Mar 28 15:25:53 still struggling with the mips thing heh Mar 28 15:26:04 * * OE Bug 3141 has been RESOLVED (FIXED) by Mar 28 15:26:06 * * EFL modifcations Mar 28 15:26:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3141 Mar 28 15:26:20 after my qemu image refused to boot (could not run init for some reason) I thought I'd build a glibc based image instead of uclibc and see how that goes Mar 28 15:26:37 RP: yes. I checked some earlier image. Mar 28 15:27:48 thesing: Any idea what changed? gcc version? Mar 28 15:28:21 The fact its gone missing is a bit worrying Mar 28 15:28:51 RP: the image where it works is from 200802121030 Mar 28 15:30:08 thesing: same gcc version? Mar 28 15:30:31 thesing: I bet this is because libgcc isn't in staging but in cross :/ Mar 28 15:30:43 RP: I don't know how do I check in the image? Mar 28 15:31:23 testlab ? Mar 28 15:31:35 thesing: not sure :/ Mar 28 15:31:52 ant|work: I only have the binary image. Mar 28 15:32:42 If someone has some build time going spare, try a build but after gcc-cross builds, copy the target libs in cross over to staging (libgcc, ligstdc++ etc.) Mar 28 15:33:22 RP: objdump of libgcc shows GCC_4.2.0 in "Version definition" (among older versions) Mar 28 15:33:22 If that works, we need to rethink gcc's staging a little Mar 28 15:33:46 thesing: That gives a minmum at least :) Mar 28 15:40:05 * * OE Bug 4025 has been RESOLVED (INVALID) by Mar 28 15:40:07 * * pulseaudio-0.9.6-autobuild Mar 28 15:40:09 * * http://bugs.openembedded.org/show_bug.cgi?id=4025 Mar 28 15:41:04 * * OE Bug 4106 has been RESOLVED (FIXED) by Mar 28 15:41:06 * * pulseaudio 0.9.9 does not build with uclibc (with patch proposal ) Mar 28 15:41:08 * * http://bugs.openembedded.org/show_bug.cgi?id=4106 Mar 28 15:41:12 RP: yeah libgcc is installed in cross we have to move it by hand to staging Mar 28 15:48:25 03mickeyl 07org.oe.dev * r9fdf6133... 10/ (3 files in 3 dirs): pulseaudio 0.9.9 fix building against uClibc. closes #4106 Mar 28 15:53:16 florian: is monotone.oe having problems? Mar 28 15:54:22 ScaredyCat: no - it just does not work usually Mar 28 16:00:25 RP: console images doesn't boot without libgcc (at least on collie) Mar 28 16:05:15 thesing: yes, we need it in the images and need to work out why its gone missing from NEEDED :/ Mar 28 16:06:12 :( Mar 28 16:13:07 hmmm.. yet another new Flash file system : http://kerneltrap.org/Linux/UBI_File_System Mar 28 16:15:35 RP: would you object if I add libgcc to task-boot and commit it as a workaround? Mar 28 16:16:58 thesing: yes, we need to fix properly Mar 28 16:18:06 RP: true but until then we can only build broken images. Mar 28 16:19:12 RP: and I have no clue about this toolchain/libc stuff. Mar 28 16:29:04 thesing: let me run some tests... Mar 28 16:31:27 hmm, binaries here have NEEDED libgcc_s.so.1 Mar 28 16:33:01 thesing: When did you last make a build from scratch? Mar 28 16:33:34 RP: last night. Mar 28 16:34:25 RP: maybe its oabi related? Mar 28 16:34:55 possibly Mar 28 16:38:13 * RP tries an oabi build Mar 28 16:40:42 RP: maybe related: ipkgs are put at deploy/glibc/ipk in addition to deploy/glibc/ipk/$PACKAGE_ARCH Mar 28 16:44:02 thesing: thats packaged staging doing something wrong :/ Mar 28 16:46:28 bye Mar 28 17:06:14 03thesing 07org.oe.dev * r76c36c8a... 10/ (1 conf/machine/include/zaurus-2.6.inc): zaurus-2.6.inc: add mmc-spi to collie RRECOMMEND Mar 28 17:06:18 03thesing 07org.oe.dev * r289640b6... 10/ (1 packages/linux/linux-rp_2.6.24.bb): linux-rp_2.6.24.bb: add new patches for collie Mar 28 17:06:23 03thesing 07org.oe.dev * ra54b1060... 10/ (1 packages/linux/linux-rp.inc): linux-rp.inc: autoload mmc-modules for collie Mar 28 17:06:28 03thesing 07org.oe.dev * rfc4b712c... 10/ (1 packages/linux/linux-rp-2.6.24/defconfig-collie): defconfig-collie: enable mmc-modules Mar 28 17:14:17 03rpurdie 07org.oe.dev * r5b6dcfdf... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: Put ipk/deb files in the correct directories Mar 28 17:14:36 thesing: I've fixed that... Mar 28 17:15:10 RP: but it was not related to the libgcc issue? Mar 28 17:15:26 thesing: No, it fixes the ipk issue Mar 28 17:16:25 I have an oabi build running... Mar 28 17:19:04 03rpurdie * r1044 10/ (2 files in 2 dirs): cache.py: Fix a bug where changed files weren't getting spotted and an invalid cache was being used Mar 28 17:22:58 hehe Mar 28 17:26:26 thesing: looks like a problem with oabi Mar 28 17:27:10 hiya! Mar 28 17:27:26 seems uImage generation is busted for powerpc Mar 28 17:27:26 jeremy_laine: hi Mar 28 17:27:51 jeremy_laine: what broke? Mar 28 17:28:08 I am getting a "Invalid CPU Type" error message, most probably becausing we're passing "-A powerpc" instead of "-A ppc" Mar 28 17:28:27 I seem to remember there was some code somewhere that fixed ARCH to address this but can't find it Mar 28 17:29:48 jeremy_laine: kernel-arch.bbclass? Mar 28 17:29:54 jeremy_laine: which kernel recipe was this? Mar 28 17:29:59 ah bugger Mar 28 17:30:19 I am trying to build "linux-2.6.24" for mpc8313e-rdb Mar 28 17:30:52 if I look at run.do_deploy.xx, I see that in "do_compile" we use the correct mkimage invocation Mar 28 17:31:18 but for "do_deploy" the UBOOT_ARCH magic is missing Mar 28 17:32:39 jeremy_laine: The logic from do_compile needs moving todo_deploy Mar 28 17:32:48 well, to kernel.bbclass Mar 28 17:32:55 RP: yup, am doing that as we speak Mar 28 17:33:07 should we drop the do_compile_append() from linux.inc in that case? Mar 28 17:33:13 jeremy_laine: I'd add it to kernel-arch.bbclass Mar 28 17:33:47 jeremy_laine: if all the logic is in do_deploy, yes Mar 28 17:33:47 ehmm.. Mar 28 17:37:41 re Mar 28 17:37:49 jeremy_laine: http://www.pastebin.ca/961078 Mar 28 17:42:04 * * OE Bug 758 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 17:42:06 * * Every reboot resets time to build time or in other cases to 1970 Mar 28 17:42:08 * * http://bugs.openembedded.org/show_bug.cgi?id=758 Mar 28 17:42:28 RP: pastebin.ca's not responding.. Mar 28 17:45:40 jeremy_laine: http://rafb.net/p/R1ib3X57.html Mar 28 17:46:13 RP: do we really want to be setting UBOOT_ARCH globally? Mar 28 17:46:28 RP: we don't really need to export the variable, do we? Mar 28 17:47:52 do_deploy is shell so it needs shell variables. You can do it in the function if you like... Mar 28 17:48:22 I guess it depends whether we think we'll ever want this elsewhere and if anything is ever going to want to override it Mar 28 17:48:56 one thing to consider - does this binary get packaged? If so, do_deploy might be the wrong place to be making these conversions Mar 28 17:49:04 or do_install needs to do them too Mar 28 17:52:34 RP: here is what I plan to commit: http://rafb.net/p/EvXtY210.html Mar 28 17:52:51 (am testing it at the moment) Mar 28 17:53:53 RP: can you do something about the libgcc issue? Mar 28 17:55:04 * * OE Bug 2158 has been RESOLVED (WONTFIX) by thommycheck(AT)gmx.de Mar 28 17:55:06 * * angstrom collie fails to shut down Mar 28 17:55:08 * * http://bugs.openembedded.org/show_bug.cgi?id=2158 Mar 28 17:57:00 thesing: I'll try and have a look later I need to go out now. At least I can reproduce it... Mar 28 17:57:19 RP: ok. thanks. Mar 28 17:57:47 jeremy_laine: looks ok to me, I just worry there may be a packaging issue too Mar 28 17:57:54 * RP -> back later Mar 28 17:58:05 03jeremy_laine 07org.oe.dev * r8ee010af... 10/ (1 classes/kernel-arch.bbclass classes/kernel.bbclass): Mar 28 17:58:05 kernel.bbclass: fix generation of uImage on powerpc platforms Mar 28 17:58:05 * add a map_uboot_arch function to kernel.bbclass which changes Mar 28 17:58:05 "powerpc" to "ppc" and export UBOOT_ARCH Mar 28 17:58:05 * pass -A ${UBOOT_ARCH} instead of -A ${ARCH} to mkimage in kernel.bbclass Mar 28 18:04:13 lrg: ping. Do you still use the imx21 platform under OE? Mar 28 18:06:04 * * OE Bug 2516 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:06:06 * * Collie 2.6: bulk writing to SD gets stuck Mar 28 18:06:08 * * http://bugs.openembedded.org/show_bug.cgi?id=2516 Mar 28 18:06:17 * * OE Bug 2161 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:06:19 * * unrecognized cards with new collie SD card driver Mar 28 18:06:21 * * http://bugs.openembedded.org/show_bug.cgi?id=2161 Mar 28 18:09:24 RP: for now I'll leave the do_compile_append() in linux.inc although I think it's not needed anymore (will discuss on oe-devel) Mar 28 18:10:02 RP: but I am pulling the UBOOT_* definitions (including UBOOT_ARCH) from linux.inc, they are already defined in kernel.bbclass Mar 28 18:16:04 03jeremy_laine 07org.oe.dev * r84875aef... 10/ (1 packages/linux/linux.inc): linux.inc: remove UBOOT_* definitions, they are already defined in kernel.bbclass Mar 28 18:20:08 03koen 07org.oe.stable * rf49b1792... 10/ (1 BACKPORTS.txt): org.openembedded.stable: welcome to the stable branch Mar 28 18:21:04 * * OE Bug 2235 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:21:06 * * angstrom collie: some keys do not work Mar 28 18:21:08 * * http://bugs.openembedded.org/show_bug.cgi?id=2235 Mar 28 18:22:04 * * OE Bug 2503 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:22:07 * * angstrom collie: no mmc modules autoloading Mar 28 18:22:09 * * http://bugs.openembedded.org/show_bug.cgi?id=2503 Mar 28 18:23:05 * * OE Bug 2513 has been RESOLVED (INVALID) by thommycheck(AT)gmx.de Mar 28 18:23:07 * * angstrom collie: can not start GPE Mar 28 18:23:09 * * http://bugs.openembedded.org/show_bug.cgi?id=2513 Mar 28 18:25:05 * * OE Bug 2547 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:25:06 * * Collie froze when setting clock Mar 28 18:25:08 * * http://bugs.openembedded.org/show_bug.cgi?id=2547 Mar 28 18:38:04 * * OE Bug 3883 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:38:06 * * MMC/Cards doesn't work for 2.6.24 Mar 28 18:38:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3883 Mar 28 18:40:04 * * OE Bug 3693 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:40:06 * * Keyboard not working for collie on 2.6.23-git9 Mar 28 18:40:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3693 Mar 28 18:51:05 * * OE Bug 3845 has been RESOLVED (FIXED) by thommycheck(AT)gmx.de Mar 28 18:51:07 * * Angstrom on Collie : No output on serial line (tty OUT_TTY) ( Sharp I/O port) Mar 28 18:51:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3845 Mar 28 20:28:27 re Mar 28 20:35:30 03thesing 07org.oe.dev * r62bd8cc0... 10/ (3 files in 3 dirs): keymaps_1.0.bb, collie/keymap-2.6.map: use OK button as return Mar 28 20:35:34 03thesing 07org.oe.dev * r5457d911... 10/ (1 packages/linux/linux-rp-2.6.24/defconfig-collie): defconfig-collie: enable touchscreen Mar 28 20:35:39 03thesing 07org.oe.dev * ra6539db9... 10/ (1 packages/linux/linux-rp.inc): linux-rp.inc: autoload input-power support Mar 28 20:35:44 03thesing 07org.oe.dev * rcfb7d5eb... 10/ (1 conf/machine/include/zaurus-2.6.inc): zaurus-2.6.inc: add kernel-module-power to collie MACHINE_RRECOMMENDS Mar 28 20:40:47 jeremy_laine: thanks for the map_uboot_arch, I was needing UBOOT_MACHINE_c7x0 = "corgi_config" before Mar 28 20:48:41 zecke: was you asking yourself why the runtime entity 'gtk+-directfb' should ever be in a console-image? Mar 28 20:49:14 zecke: I wonder too ... Mar 28 20:53:45 * mwester wonders why builds complain that gtk+-directfb depends on itself, and cannot find itself. It seems to have some form of existential crisis... :D Mar 28 20:54:33 a couple packages had that problem for a bit Mar 28 20:54:45 mwester: I thought I've found it: ./packages/gtk+/gtk+-directfb_2.10.14.bb:DEPENDS = "glib-2.0 pango-directfb atk... Mar 28 20:54:54 Missing or unbuildable dependency chain was: ['gtk+-directfb', 'pango-directfb'] Mar 28 20:55:00 pango-directfb had been removed from OE for now due to the report of it breakin Mar 28 20:55:03 ?? Mar 28 20:58:47 andrea@mizar /oe/org.openembedded.dev/packages $ grep -R pango-directfb . Mar 28 20:58:54 ./gtk+/gtk+-directfb_2.10.14.bb:DEPENDS = "glib-2.0 pango-directfb atk jpeg libpng gtk-doc libgcrypt cairo-directfb cups" Mar 28 20:59:27 Oh - good catch. That might do it. Mar 28 20:59:47 mwester: but why in console image ? Mar 28 20:59:57 I'll start another build tonight; I'll edit that file and see if that fixes it. Mar 28 21:00:07 I can't imagine why you need it in a console image. Mar 28 21:00:27 (remote X?) Mar 28 21:00:37 or mc Mar 28 21:00:42 ? Mar 28 21:00:53 mc uses gtk? Mar 28 21:01:00 * mwester is not an mc user... Mar 28 21:01:05 it can use X Mar 28 21:01:12 Ah, ok. Mar 28 21:01:21 use in Gentoo meaning ;-) Mar 28 21:02:37 * mwester is distracted; his new toy just entered his office and is vacuuming the floor. Mar 28 21:03:02 * mwester bought a roomba Mar 28 21:03:23 * ant just scared: a robot pump? Mar 28 21:04:29 http://www.irobot.com/sp.cfm?pageid=122 Mar 28 21:04:36 Apparently they are hackable, too. Mar 28 21:04:52 mwester: you insane, are you planning some linux-rt reflash? Mar 28 21:05:25 :D I have no idea yet. But it's pretty cool to watch. And fun to play with. Mar 28 21:05:48 mwester: if they are realy hackable please tell me later. Mar 28 21:06:14 And the best part of it all is that I don't have to sweep and vacuum the floor anymore, and it was paid for from the household budget instead of my hobby money! :D Mar 28 21:06:33 thesing: Euro - prices here http://www.roomba.it/shop_robot.aspx (mit MWSt) Mar 28 21:07:04 ant: I wonedered myself but didn't say that *scary* Mar 28 21:07:20 =) Mar 28 21:08:28 mwester: but does it work? Mar 28 21:09:05 So far it's doing pretty well. I imagine it will be unhappy in the kitchen, with all the table and chair legs to negotiate around. Mar 28 21:09:28 mwester: I wonder if my cats like it Mar 28 21:09:34 he he, big dogs at home? Mar 28 21:09:35 It just finished a cycle, found it's charging station, and has parked itself. Mar 28 21:09:56 morning Mar 28 21:09:58 I have a very little dog (8 lbs). It's a little frightened. Mar 28 21:10:05 or _childrens_? Mar 28 21:10:07 morning rod Mar 28 21:10:09 mwester: +1 on the packaged staging for slugos Mar 28 21:10:56 I finished the reference build; I'm building the packaged staging now. Will compare and test... Mar 28 21:11:01 mwester: are some of the slugos machines arm-oabi? Asking because of the libgcc issue. Mar 28 21:11:14 Yes - SlugOS is OABI. Mar 28 21:11:27 Angstrom runs on the NSLU2 as well; that's EABI Mar 28 21:11:46 We're targetting EABI SlugOS for the next major release. Mar 28 21:12:12 thesing: is OABI a suspect in that gcc issue, then? Mar 28 21:12:34 yes. Mar 28 21:12:47 thesing: libgcc not being in the rootfs/image, you mean? Mar 28 21:13:10 correct. Mar 28 21:13:31 ant: The prices in Europe for the robot are ruinous! Mar 28 21:13:49 mwester how much it cost in US ? Mar 28 21:13:54 The model 530 is only USD 299 Mar 28 21:14:08 (the .it website lists it for 299 Euros Mar 28 21:14:10 ) Mar 28 21:14:25 mwester: the prices in EURO are ruinos :-( Mar 28 21:15:13 even if you live in EU Mar 28 21:15:27 + taxes Mar 28 21:15:29 mwester: Error: "taxes" is not a valid command. Mar 28 21:16:02 * mwester wonders how many bots we need :) Mar 28 21:16:18 mwester: VAT 20% included Mar 28 21:16:34 "for your convenience" Mar 28 21:16:37 I certainly wish that "taxes" was not a valid command, but it certainly is a command issued by the government here. Mar 28 21:27:29 03osas 07org.oe.dev * rec382304... 10/ (4 files in 2 dirs): asterisk 1.6 and asterisk-addons 1.6 with DEFAULT_PREFERENCE = "-1" Mar 28 21:40:03 bye Mar 29 00:13:24 03osas 07org.oe.dev * rd898916e... 10/ (6 files in 2 dirs): adding missing files for astersk 1.6 Mar 29 00:16:50 re Mar 29 00:17:22 RP: the fresh build was ok, but subsequent angstrom builds crashes out... Mar 29 00:17:38 NOTE: package angstrom-version-1_2008.1-test-20080329-r1: task do_package_write_ipk: started Mar 29 00:17:38 ERROR: Error in executing: Mar 29 00:17:38 ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/oe/build/tmp/angstrom/work/c7x0-angstrom-linux-gnueabi/angstrom-version-1_2008.1-test-20080329-r1/install/angstrom-version.lock' Mar 29 00:18:05 i built before midnight...20080328 Mar 29 00:27:52 RP: mkdir: kann Verzeichnis „/media/Linux/openmoko/build/tmp/deploy/glibc/ipk/armv4t/IPKG_BUILD.27187“ nicht anlegen: File exists Mar 29 00:27:55 NOTE: Task failed: ipkg-build execution failed Mar 29 00:28:00 this is on mesa, ever seen this= Mar 29 00:31:23 RP: this is my /pstage: http://www.pastebin.org/25976 Mar 29 00:37:41 RP: zecke: this is the full errorlog http://www.pastebin.org/25978 Mar 29 00:38:41 zecke: btw gtk+-directfb DEPENDS should be changed (pango instead of pango-directfb) Mar 29 00:39:03 it was discussed in September 2007 in the ml Mar 29 00:39:34 ^ the deletion of pango-directfb Mar 29 00:40:48 as you see in the above log the ERROR about gtk+-dirctfb disappears Mar 29 00:41:14 sorry, i'm not here :) Mar 29 00:41:44 he, for the posterity then :-) Mar 29 00:42:02 ant: ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/oe/build/tmp/angstrom/work/c7x0-angstrom-linux-gnueabi/angstrom-version-1_2008.1-test-20080329-r1/install/angstrom-version.lock' Mar 29 00:42:26 this is your error, not gtk+ directfb disappearing (which is another error but luckily not fatal) Mar 29 00:42:48 2 separate things Mar 29 00:42:55 in the same log Mar 29 00:43:35 the angstrom-version issue persists Mar 29 00:44:00 the minor one goes away Mar 29 00:44:40 hi CoreDump Mar 29 00:44:53 ant: no idea what is up with your fs? disk is full? clean the angstrom version package, let it build again... Mar 29 00:45:25 ant: this package is probably only putting a version info in the package, there is hardly anything that can fail :) Mar 29 00:45:58 hi Mar 29 00:46:19 I just did a bitbake -c buildall from vacuum and finished without errors Mar 29 00:46:41 then I did the same and it errors out... Mar 29 00:47:07 the second time Mar 29 00:54:19 hm, monotone still does not support SMP? Mar 29 01:18:32 03tmbinc 07org.oe.dreambox * r04c318be... 10/ (1 packages/dreambox/dreambox-bootlogo.bb): dreambox-bootlogo: better dm800 bootlogo support Mar 29 01:18:35 03tmbinc 07org.oe.dreambox * r1cc18ae1... 10/ (3 files in 3 dirs): initscripts-opendreambox: custom 'halt' to show shutdown picture Mar 29 01:18:39 03tmbinc 07org.oe.dreambox * r907c0c59... 10/ (1 packages/dreambox/dreambox-dvb-modules.bb): dreambox-dvb-modules: use newer drivers Mar 29 01:25:28 03tmbinc 07org.oe.dreambox * r1ef9ff28... 10/ (1 packages/tuxbox/tuxbox-common.bb): tuxbox-common: update srcdate Mar 29 01:34:41 can someone help me to get a oe build env for openmoko? i get the error "Please set a valid MACHINE in your local.conf" while i setted MACHINE = "om-gta01" - what's wrong? Mar 29 01:43:00 03mickeyl 07org.oe.dev * r7a4fc7be... 10/ (4 files in 4 dirs): gtk+-directfb 2.10.14 move to nonworking until someone adds pango-directfb Mar 29 01:44:38 emdete: Did you delete your tmp directory entirely, and follow the instructions on the mailing list to migrate to the new openmoko OE branch? Mar 29 01:44:57 mwester: yes. no. Mar 29 01:45:12 mwester: i followed the wiki. Mar 29 01:45:59 I don't know what's in the wiki. You should check the recent emails to the distro-devel list (among others). Mar 29 01:46:19 mwester: i'm not subscribed. where can i find those? Mar 29 01:46:42 Top right corner of the www.openmoko.org page is the link Mar 29 01:48:06 mwester: what does 'new' mean? some days/weeks or older? Mar 29 01:48:13 Past few days Mar 29 01:49:11 3/24/08 - titled "Openmoko Monotone Changes" Mar 29 01:52:59 okay, that's what broke my env. Mar 29 01:54:04 ended in a message that there are two heads or something after removing the patch dir. **** ENDING LOGGING AT Sat Mar 29 02:59:56 2008