**** BEGIN LOGGING AT Wed Sep 16 02:59:57 2009 Sep 16 04:56:35 could someone please inform me as to how/where samba pulls in dbus/libavahi as a dependency? two things i don't want on my system. i've tried grepping etc. to no avail Sep 16 04:57:12 run bitbake -g. Sep 16 04:57:47 thanks Sep 16 04:58:38 also in trying to up ncurses to 5.7, i noticed a visibility.patch. searching git commits lead me to one of yours. could you explain what 'visibility' means in this context? or can it vary? Sep 16 04:58:55 i believe it was a gcc patch Sep 16 05:00:04 visibility bits? Sep 16 05:02:39 symbol visibility. ensures that only external api functions are available to users of the library. been years since i've looked at that stuff though, google for gcc symbol visibility Sep 16 05:03:08 yea i did, thanks for the response though Sep 16 05:03:11 np Sep 16 05:36:58 hrm strange i dont see dbus or avahi in either of the .dot Sep 16 05:38:27 but i see Sep 16 05:38:27 Depends: update-rc.d, uclibc (>= 0.9.30.1), libiconv (>= 1.12), libgcc1 (>= 4.4.1), libpopt0 (>= 1.14), libreadline5 (>= 5.2), ncurses (>= 5.4), libavahi-client3 (>= 0.6.24), libavahi-common3 (>= 0.6.24) Sep 16 05:38:39 in the .ipk/control Sep 16 05:39:25 some runtime dependencies are generated based on what libs were linked against. it's possible that you had avahi/dbus built already, and the samba buildsystem had an optional dependency on them, using them only if they're available.. in which case build order would affect whether or not it ends up with those runtime deps Sep 16 05:39:45 those sorts of things are best resolved by explicitly passing --with/--without/--enable/--disable to force it one way or hte other Sep 16 05:40:26 kergoth okay, so it will check what autoconf finds in staging and throw those in as depends as well? Sep 16 05:40:37 yep, lots of autoconf scripts do things like that Sep 16 05:41:40 their autoconf script will enable support for a thing if it's available, and because of the build order, its available.. and then the shlibs code in package.bbclass adds that to the ipk deps, since the app links against it Sep 16 05:42:19 --enable-avahi Enable Avahi support (default=auto) Sep 16 05:42:34 cool, thanks Sep 16 05:42:57 lets see if i can --disable-avahi Sep 16 05:43:28 yep, that would be best Sep 16 05:45:58 m4t: the other day i wrote a class to check for those missing deps (or needs to explicitly disable things). it compares the generated runtime deps against what the recipe actually pulls in. not perfect, but it may be of use to help us catch things like this in the future. need to see about getting it upstream to oe Sep 16 05:48:10 cool, if you've got a drop-in for bitbake that you need tested let me know, i could do that Sep 16 05:48:18 more from an end-user standpoint than a developer's one Sep 16 05:48:34 * kergoth nods Sep 16 05:48:55 we need to fix these kinds of issues badly, as they make our builds less deterministic Sep 16 05:49:00 build order shouldn't affect things like that Sep 16 05:51:44 03Dr. Fred  07shr/import * r9fcb76f392 10openembedded.git/recipes/libmms/ (libmms.inc libmms_0.4.bb): Sep 16 05:51:44 add libmms Sep 16 05:51:44 Signed-off-by: Frederik 'playya' Sdun Sep 16 06:00:33 m4t: if you want to experiment, http://gist.github.com/187895 . set MISSINGDEPS_ERROR = "1" and MISSINGDEPS_ENABLE = "1", then build dbus & avahi and build samba without the explicit --disable, and it should error out, telling you about it Sep 16 06:00:49 m4t: oh, and of course, INHERIT += "missingdeps" after putting hte bbclass into classes Sep 16 06:03:19 goodmorning Sep 16 06:03:26 thanks i grabbed it Sep 16 06:05:32 MISSINGDEPS_ERROR = "1" and MISSINGDEPS_ENABLE = "1" on a per .bb basis or in local.conf as well? Sep 16 06:06:30 you'll want to enable it globally, currently, because it emits metadata from all recipes that it uses to map the rdeps back to deps Sep 16 06:06:46 k Sep 16 06:06:58 will see about making enable only affect the reporting/checking, not the metadata emission, to make per recipe more viable Sep 16 06:07:53 i'll test it out now on samba, after this current packaging finishes Sep 16 06:28:08 Depends: update-rc.d, uclibc (>= 0.9.30.1), libiconv (>= 1.12), libgcc1 (>= 4.4.1), libpopt0 (>= 1.14), libreadline5 (>= 5.2), ncurses (>= 5.4), libattr1 (>= 2.4.43 Sep 16 06:28:24 let me try that new bbclass now Sep 16 06:32:37 I'm trying to compile Angstrom for Beagleboard and get an error in [..]/m4-native-1.4.12-r0/m4-1.4.12/GNUmakefile about to many levels of symbolic links, and I see that the GNUmake in question is symlinked to itself. Sep 16 06:35:18 tasslehoff: I'm following this howto - http://www.angstrom-distribution.org/building-angstrom Sep 16 06:36:38 talking to myself is a good start of solving the problem.. Sep 16 06:38:20 good morning Sep 16 06:42:00 I deleted the GNUmakefile, and now it seems to build Sep 16 07:00:59 Is analog video out and audio in not supported on beagleboard? ref: http://wiki.openembedded.net/index.php/BeagleBoard Sep 16 07:02:29 gotta wait for this 800mb debug pkg again Sep 16 07:02:46 and tasslehoff , not to ignore you, but im not sure, ive never worked with one Sep 16 07:06:13 m4t: hehe. ok :) Sep 16 07:07:05 hey kergoth : Sep 16 07:07:06 NOTE: Multiple libraries (libnetapi.so.0, libtdb.so.1, libsmbsharemodes.so.0, libtalloc.so.1) found and LEAD_SONAME not defined Sep 16 07:07:06 NOTE: Task failed: samba-3.3.7-r0: missing dependencies for the following binary packages: ncurses, libavahi-common, libattr, libavahi-client, popt Sep 16 07:07:06 ERROR: TaskFailed event exception, aborting Sep 16 07:07:37 thanks. Sep 16 07:30:56 kergoth : also it does not error when i add deps += "aforementioned libraries that are pulled in" Sep 16 07:59:10 khem: prismstumbler is florian's thing, not mine really Sep 16 07:59:39 if wireless.patch is harmless on newer kernels then I would leave it in, some people might well still be using older kernels. Sep 16 08:03:34 good morning Sep 16 08:03:44 oh Sep 16 08:04:25 good morning Sep 16 08:04:39 hi dth Sep 16 08:42:42 unfortunately, this web interface is very flakey Sep 16 08:42:55 no, I can't get to a console on the second VT Sep 16 08:43:13 sorry, wrong channel Sep 16 09:27:44 florian: good morning Sep 16 09:58:45 what's the best way to submit a trivial patch? Sep 16 09:58:57 (doesn't fix any bugs by itself) Sep 16 10:03:15 send it to the mailing list, probably Sep 16 10:04:27 * czr_ nods Sep 16 10:04:44 what's the preferred format for it? git diff > foo.patch ? Sep 16 10:05:44 morning Sep 16 10:06:56 czr_: git format-patch or git send-emil Sep 16 10:07:07 (just about to write the same) Sep 16 10:07:29 yo ant_work get fixing :p-D Sep 16 10:07:54 XorA: hello there Sep 16 10:10:04 pb___: there is a chase for missing deps lately :) Sep 16 10:10:10 czr_: if it's that trivial, the format doesn't really matter; "git diff" output would be fine, and so would "git format-patch". for more complicated changesets "git format-patch" makes it a bit easier to apply. Sep 16 10:10:14 ant_work: yeah, it seems. go kergoth! Sep 16 10:10:32 just wondering how your autotools patch would integrate in the pic Sep 16 10:10:48 pb__, right. I'm just starting to use git and git format-patch seems somewhat intimidating. I'll just send a git diff. Sep 16 10:11:04 git diff does mean you dont get credited :-) Sep 16 10:11:21 git format-patch HEAD -1 Sep 16 10:11:26 let me see Sep 16 10:11:29 will give you last commit Sep 16 10:11:44 yeah, but I haven't committed yet. so I guess after a change I'll have to commit first :-) Sep 16 10:11:49 * ant_work warns about whitespaces in the patches...smthg strange Sep 16 10:12:45 ant_work: I worry about black space in patches personally Sep 16 10:12:51 * ant_work locally doeas always a git am -3 --whitespace=fix Sep 16 10:12:57 right. here goes. be gentle :-) Sep 16 10:13:01 ant_work: the autotools thing is more or less orthogonal to the other stuff. I don't think there'd be any conflicts. Sep 16 10:13:24 pb___: yea, it was my same impression Sep 16 10:13:41 you could try it out, and if it works you could even check it in. überhacker zecke did ack the patch at one point so I think it is approved. Sep 16 10:14:09 oe-devel, right? Sep 16 10:15:41 XorA: the git guys are working hard on whitespaces / blank eof http://thread.gmane.org/gmane.comp.version-control.git/127711/focus=127714 Sep 16 10:15:49 hmm. do I need to do anything special to sign off? format-patch generates a file 0001-foo. Sep 16 10:16:01 or just a short mail with the 0001-foo attached? Sep 16 10:17:05 hello Sep 16 10:17:13 i want to ask how to change the kernel version Sep 16 10:17:20 i'm using Sep 16 10:17:29 czr_: doesn't matter, you can either attach the file or insert it into the body of your mail. Sep 16 10:17:42 pb__, cool. thanks. and sorry for the noob-questions. Sep 16 10:19:42 ant_work: what happened to kexecboot? Sep 16 10:19:43 how to change the kernel version i'm using Sep 16 10:19:48 ant_work: seems to have gone dead Sep 16 10:19:50 and where all i need to do the change Sep 16 10:39:47 I'm attempting my first OE-build of angstrom for beagleboard and get this error, http://pastebin.com/d7f2f2608. Sep 16 10:39:50 morning all Sep 16 10:41:29 morning Sep 16 10:44:29 is 1.8.10 of bitbake ok? or should I get a newer one? Sep 16 10:45:11 ah. seems that versions past that have a lot of issues fixed. Sep 16 10:47:11 I think 1.8.10 is basically ok for most things, though the sanity checker doesn't like it. You would probably be better off with a later 1.8.x version. Sep 16 10:48:38 yeah, I found 1.8.12 for hardy by rold leggewie, and will go with that. Sep 16 10:48:42 rolf even. Sep 16 10:49:17 czr_: you do know you dont need to install bitbake? Sep 16 10:49:37 should I use the git-version then? Sep 16 10:50:16 (I don't mind installing it as long as it comes in a nice package :-) Sep 16 10:51:29 anyone got a clue about the error I'm getting? Sep 16 10:58:32 tasslehoff, what image are you trying to build? Sep 16 11:02:30 XorA: about kexecboot, I bothered all (not-yet-retired) Z kernel hackers about kernel patches for readingthe mtdpart. I have a patch for kexecboot todo the same but obviously the 'optimal' would be a kernel patch Sep 16 11:03:14 Crofton|work: base-image Sep 16 11:03:33 stable or dev? Sep 16 11:03:57 Probably I'll have to comit the patch in OE so that it gathers visibility and I can say: see...it works in userland, are you not able to do it in kernelspace :D ? Sep 16 11:03:58 did you follow instructions from angstrom website, or OE getting started? Sep 16 11:04:59 Crofton|work: the ones on the angstrom site (http://www.angstrom-distribution.org/building-angstrom) Sep 16 11:05:09 ok, that is .stable Sep 16 11:07:02 I'm running a build here, in the meantime try console-image Sep 16 11:07:05 Crofton|work: yes. found a post about the issue here http://groups.google.com/group/beagleboard/browse_thread/thread/0ca02e78e21709f1?fwc=1, but I'm a bit to fresh to understand all of it :) Sep 16 11:07:45 * ant_work hopes oneday the schizophrenia OE/angstrom will end Sep 16 11:08:23 what schizophrenia? Sep 16 11:08:39 starting from build-instructions, set env, etc Sep 16 11:08:54 not talking about the paranoid attitude of some devs agains A. Sep 16 11:09:38 well Sep 16 11:09:59 IMHO we have micro, minimal, and large=angstrom Sep 16 11:10:10 the default Angstrom build uses stable so users do not fall over random .dev breakage and large scale changes Sep 16 11:11:00 heh Sep 16 11:11:03 Ångstom Sep 16 11:11:07 hrmmm Sep 16 11:11:12 irssi isnt unicode :-) Sep 16 11:11:22 Angstrom can build pretty small images Sep 16 11:12:03 a distro is much more than a conf file in the distro directory Sep 16 11:12:26 you need a support organization that exists outside this channel :) Sep 16 11:12:33 Crofton|work: the proliferation of images is another 'bad thing' imho. Some works only with some distros. Sep 16 11:12:51 ant_work, that is a bug that needs fixing :) Sep 16 11:13:01 :) Sep 16 11:13:05 but custom imahes are a good thing Sep 16 11:13:21 I'm not set on being shizophrenic. I want to build a custom image for my BB, and hope that starting with a small angstrom and adding what I need is a good idea :) Sep 16 11:13:40 tasslehoff, you are fine Sep 16 11:13:44 tasslehoff: sorry, not taking about you :) Sep 16 11:13:45 I started a clean build Sep 16 11:13:57 what distro is on the build machine? Sep 16 11:14:05 ant_work: I didn't think so :) Sep 16 11:14:11 Crofton|work: Ubuntu 9.04 Sep 16 11:14:27 I have F11 Sep 16 11:14:59 an incremental build of base-image worked for me Sep 16 11:15:11 now I am trying a clean build, so it will be a while Sep 16 11:17:10 Crofton|work: ok. I had another problem as well, with a GNUmake file symlinked to itself (like in http://groups.google.com/group/beagleboard/browse_thread/thread/4b8d6ec343ad20ed). This I "solved" by deleting the GNUmakefile Sep 16 11:19:05 that is way back Sep 16 11:19:15 packages should no longer exist anywhere Sep 16 11:21:17 ot, would missing thumb support from the kernel be reflected in missing 'thumb' in /proc/cpuinfo? Sep 16 11:21:36 I'm pretty certain the core is ARM926TEJ-S which should support thumb, but /proc/cpuinfo doesn't list it in flags. Sep 16 11:21:57 oops, ARM926EJ-S even,. Sep 16 11:23:04 I didn't think the kernel filtered the flags like that, but maybe it does. ARM926EJ-S certainly does support thumb, anyway. Sep 16 11:23:13 * czr_ nods Sep 16 11:23:39 czr_: I've seen your armv5te patch. Can't comment on this because I build using angstrom, not including sane-toolchain Sep 16 11:24:03 Crofton|work: I know, but the second to last poster has the same problem as me Sep 16 11:24:19 ant_work, np. I tried to check that the variable doesn't depend on it being defined twice, but didn't see any obvious reason for it being so. Sep 16 11:24:29 neither me Sep 16 11:24:30 czr_: ah yes, it does. see setup.c: Sep 16 11:24:36 #ifndef CONFIG_ARM_THUMB Sep 16 11:24:36 elf_hwcap &= ~HWCAP_THUMB; Sep 16 11:24:36 #endif Sep 16 11:24:47 pb__, ah. silly kernel. :-) Sep 16 11:24:58 explains it then. the vendor kernel doesn't enable thumb. Sep 16 11:25:06 heh. well, to be fair to the kernel, thumb binaries won't have any useful effect if the kernel is built without thumb support. Sep 16 11:25:35 it would be still nice to know that the cpu is capable of thumb, even if the kernel isn't :-) Sep 16 11:25:54 is the "micro" distro tested? Sep 16 11:26:27 yeah, I guess. that's what the cpu reference manuals are for :-) Sep 16 11:26:35 I don't think there are any non-thumb arm9 or higher cpus. Sep 16 11:26:56 * czr_ nods Sep 16 11:27:04 micro is tested, yes, though not on such a wide range of targets or packages as some other distros. Sep 16 11:27:16 right. so I would expect it to build then. good. Sep 16 11:27:31 I'm testing using machine=i686-generic for now. will try arm next if all goes well. Sep 16 11:27:40 yes, it should do. you might do better with micro-uclibc though if you want small images. Sep 16 11:27:46 tasslehoff, did you ever make a soft link involving packages Sep 16 11:27:55 hmm. I'll try that one as well. Sep 16 11:28:07 how does bitbake behave if I change DISTRO in the local.conf? Sep 16 11:28:10 "micro" itself is a little bit of an oxymoron, the inclusion of (e)glibc means that the images are inescapably quite large Sep 16 11:28:39 in an existing tmpdir, you mean? not well, you would probably need to build from scratch in a fresh tree. Sep 16 11:28:49 heh, it seems like every attempt at making a distro starts to converge back to Angstrom :) Sep 16 11:28:55 hmm. would switching TMPDIR help then? Sep 16 11:29:07 although khem will say you can configure eglibc to be small :) Sep 16 11:29:14 Crofton|work: no. I have a symlink for /home/oe over to /data/oe where I have more disk space, but that's the only thing I have touched. Sep 16 11:29:16 that's what I thought :-) Sep 16 11:29:27 hmm Sep 16 11:29:34 symlinks in that path are bad Sep 16 11:29:54 I would remove that symlink Sep 16 11:29:57 how would I go about customizing eglibc? Sep 16 11:30:07 (to make it "small") Sep 16 11:30:12 there are tools in the build process that trip up on symlinks like that Sep 16 11:30:21 czr_: yeah, or just use a completely separate build directory. Sep 16 11:30:21 not sure, ask khem :) Sep 16 11:30:55 I will. If I first get the default micro to build. Sep 16 11:31:03 eww, eglibc uses svn. Sep 16 11:31:09 czr_: http://bugs.openembedded.org/show_bug.cgi?id=5313 Sep 16 11:31:39 czr_: I plan to give eglibc a try Sep 16 11:32:29 Crofton|work: I'll try that and build again. Do I have to clean something before I retry? Sep 16 11:32:51 try without rm'ing the tmp dir Sep 16 11:32:57 hmm. micro uses sane-toolchain though, so I guess I'm safe. although I'm just building for i686, so probably things will just "work" (I'm using x86-64 though). Sep 16 11:33:01 if that fails rm the tmp dir Sep 16 11:34:11 anyhow, I'll leave it building, and will get back after that. thanks pb__, ant_work and others. Sep 16 11:34:12 yeah, I think it should be ok. I did a micro build for qemuarm a couple of days back (with eglibc) and it seemed to work fine Sep 16 11:34:37 if you do have trouble with i686 for any reason, post here (or the list) and I'll have a look at it Sep 16 11:35:16 * czr_ nods Sep 16 11:35:41 * czr_ took three days off work to at least attempt to get to know oe better Sep 16 11:36:01 I've been using it for over a year with our pxa270 target. but sometimes it still feels like I don't have a clue what I'm doing :-) Sep 16 11:36:07 heh Sep 16 11:36:14 (plus we're using angstrom 2007 something, which is slightly dated) Sep 16 11:36:40 pb__: it would be good if all distro's would inherit a common set of includes Sep 16 11:36:52 I have a small target here which is perfect for testing ( http://koltsoff.com/pub/pikkune.jpg , 75 MHz ARM9E ) Sep 16 11:37:09 and I'll be probably switching to pxa270 later on, depending on how things go. Sep 16 11:37:21 ant_work: well, I dunno. if there is anything sufficiently generic that it is guaranteed to be correct for all distros, it probably ought to be in the base config anyway. Sep 16 11:37:49 split at toolchain level is nonsense Sep 16 11:37:57 imho Sep 16 11:38:06 I'm not quite sure what you mean. Sep 16 11:38:34 are you saying you want all DISTROs to use the same toolchain? I don't think that would be achievable. Sep 16 11:38:35 straight: koen is busy and angstrom lost the train with latest toolchain updates/breakages :) Sep 16 11:38:38 recipes/gcc/gcc-4.4.1/gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch ? gcc-4.3 patch against 4.4? Sep 16 11:39:23 czr_: it isn't very uncommon for patches to be named like that; it happens if the patch was written for 4.3 but still required for 4.4 and nobody bothered to rename it. Sep 16 11:39:29 pb__: there have been so many toolchain-related commits in the last weeks :) Sep 16 11:39:31 ah ok. Sep 16 11:39:43 I'm waiting to see RP's sdk and cross fixes Sep 16 11:39:48 I tend to rename patches even if the patches still apply cleanly. just to avoid confusion :-) Sep 16 11:39:50 I don't know whether that specific patch is actually still appropriate for 4.4, but nobody has complained about it causing a problem. Sep 16 11:40:28 czr_: I think the general approach here is to only rename the patch if it needed editing to apply to the new version. if the old one applies verbatim then it is sometimes handy to have the filename reflect that it really is the same patch. Sep 16 11:40:30 ah, it's a very simple one Sep 16 11:40:47 yeah, I see the merit in that as well Sep 16 11:41:03 ant_work: I think the sdk and cross stuff is mostly or entirely cross-distro. Sep 16 11:42:08 I wouldn't have thought any of the recent checkins around sane-toolchain.inc should have upset angstrom since it doesn't use that file. if angstrom really did get broken as a side effect of some other changes then that is certainly unfortunate; you should probably take it up with whoever checked in the patch in question. Sep 16 11:42:30 pb__: is a minor case, eglibc Sep 16 11:44:57 okay. I guess khem would be your man for that. Sep 16 11:44:59 pb__: khem outlined the problem in bug 5313 Sep 16 11:45:04 eh Sep 16 11:46:07 ah, I see. yes, that angstrom-eglibc.inc is fairly obviously just broken. Sep 16 11:46:26 the first assignment to TARGET_OS is always going to be ineffectual since the latter will overwrite it. Sep 16 11:46:49 so, I guess you should find out who added the second line and get them to fix it. Sep 16 11:47:01 what are the advantages to using eglibc? Sep 16 11:47:10 compared to glibc, you mean? Sep 16 11:47:14 yeah Sep 16 11:47:24 Crofton|work: me eagerly curios Sep 16 11:47:26 it's supposed to be a bit more modular, you can turn off features that you don't want. Sep 16 11:47:46 also allegedly better support for cross-testing and cross-building although I have never found plain glibc to be particularly deficient in that respect. Sep 16 11:48:22 I'm not certain that distros should be bale to use all libc's anyway Sep 16 11:48:24 I'll fire a build and do a size-comparison Sep 16 11:48:35 see http://www.eglibc.org/features Sep 16 11:48:39 uclibc was disappointing Sep 16 11:48:47 no real size savings months ago Sep 16 11:48:59 indeed, I don't think there is any point in trying to support every libc on every distro. Sep 16 11:49:25 it's not entirely obvious that the (e)glibc based micro is actually very useful and we have talked about throwing it away on a few occasions. Sep 16 11:49:36 pb___: still in my benches arm/glibc was the fastest Sep 16 11:49:52 however, it also doesn't cost much to maintain it, and it does have the advantage of better compatibility with other mainstream distros. Sep 16 11:50:09 if there's a for-dummies guide how to select features in eglibc with oe, I'd be interested Sep 16 11:50:09 Leon broke the file :-) Sep 16 11:50:10 I would expect most DISTROs, though, to pick a single libc and stick with it. Sep 16 11:50:38 I tried looking for info when eglibc was the hype (some months back), but couldn't find stuff beyond "your distro maintainers will know what to do, go away shoo". Sep 16 11:50:52 heh Sep 16 11:51:08 czr_: yeah, dunno. the webpage talks about some "options.def" file but I have never actually looked at it myself. Sep 16 11:51:12 I thought the main motivation for eglibc was Dreppers anti arm ranting Sep 16 11:52:20 ant_work: I think I posted some size comparisons of micro vs micro-uclibc to the list a while back. Sep 16 11:52:26 I don't recall exactly when though. Sep 16 11:52:34 pb__: real usercase can be a bit different: initramfs images and friends hate the bloat of glibc Sep 16 11:52:54 my current target has 4 MiB of NOR. Sep 16 11:52:59 :-) Sep 16 11:53:09 I guess eglibc size would be at least big as uclibc, not smaller Sep 16 11:53:11 yes, initramfs images are kind of a special case. you don't necessarily need them to be binary compatible with your full rootfs so they can be largely self contained. Sep 16 11:53:18 ant_work: yes, eglibc is bigger than uclibc Sep 16 11:53:20 ant_work, eglibc will be somewhere between the two Sep 16 11:53:36 he..we ended using klibc :) Sep 16 11:53:49 btw: help! Sep 16 11:53:54 why not uclibc? Sep 16 11:54:09 too big (1,2 MB size) Sep 16 11:54:31 uclibc? Sep 16 11:54:45 kernel+initramfs <= 1,2 MB Sep 16 11:54:48 ah. Sep 16 11:55:02 you could always go 2.2 :-) Sep 16 11:55:13 or even 2.4. Sep 16 11:55:15 but then no kexec... Sep 16 11:55:24 klibc is dead though, so you probably have to rethink Sep 16 11:55:25 you could port kexec to 2.2. what.. no? :-) Sep 16 11:55:28 * czr_ hides & runs Sep 16 11:55:30 czr_: 4MB of NOR should be okay. I think micro-base-image for micro-uclibc comes out at about 800kB on my arm target. Sep 16 11:55:48 XorA: last things to do (help btw) is kexec-tools-klibc-static_2.0.0 Sep 16 11:55:58 the recipe needs some fixes Sep 16 11:56:10 pb__: heh, once upon a time we used to get the whole OS + games in 800K Sep 16 11:56:11 thesing disappeared.. don't know who bother Sep 16 11:56:17 pb__, yeah, I have 8 MiB of SRAM, so it's a win-win. but I'm going to try the eglibc first. just because I can. I guess the reason I shy away from uclibc still is it's lack of proper nptl. Sep 16 11:56:23 ah no, a bit less than that. 550k as a tar.gz, or 650k as a jffs2 Sep 16 11:56:45 czr_: right, uclibc does suck in that respect. should really fix that, it wouldn't be very hard. Sep 16 11:57:08 I did look at the issue, it was mainly the lack of interest of someone to implement futexes properly I guess Sep 16 11:57:20 since there are a zillion arm versions, and each having slightly different barriers and such. Sep 16 11:57:35 and since uclibc won't be used on real SMP systems, no one bothered I guess. Sep 16 11:57:44 * Crofton|work is hoping tasslehoff's build issue is due to the symlink .... Sep 16 11:58:05 it is a bit tiresome, though there are only really two arm versions that matter: armv6 and upwards, where you use strex/ldrex; and pre-armv6, which is always UP and can use straightforward SWP. Sep 16 11:58:05 task 225/245. althoug they seem to get slower towards the higher number. Sep 16 11:58:43 pb__, I have no idea. that's what I read from the mailing lists when I looked into it ages back before we chose oe/angstrom/glibc as our build environment. Sep 16 11:59:01 right, fair enough Sep 16 11:59:17 maybe one day I will get fed up enough with it to try to write those bits for uclibc. Sep 16 11:59:19 not that we actually ended up using threads for anything. Sep 16 11:59:54 hmm. eglibc build complains about /lib/libfoo.map files not being included in any package. this is ok I guess? Sep 16 12:00:21 it's nearly five years since I did the arm nptl bits for glibc so I guess I am about ready to face it again :-} Sep 16 12:00:23 (the following files were installed but not shipped in any package: /lib/libresolv_pic.map, /lib/libutil_pic.map, ... about 15 of them) Sep 16 12:00:32 * tasslehoff hopes Crofton|work is right Sep 16 12:00:38 czr_: I guess. I don't think those files are needed for anything, though you could stick them in the -dev package if you wanted. Sep 16 12:00:42 heh. you tried to escape. but escape is impossible. i know the feeling :-) Sep 16 12:01:08 hmm. there are also two object files in the list. Sep 16 12:01:39 that's a bit odd. what are they? Sep 16 12:01:40 ah, I'll just pastebin the whole thing. http://www.pastebin.org/18305 Sep 16 12:02:06 03Koen Kooi  07org.openembedded.dev * r14a286d359 10openembedded.git/recipes/linux/linux-omap-2.6.29/omap3-touchbook/aufs-squashfs-mount-to-avoid-initramfs.patch: linux-omap 2.6.29: only use touchbook aufs stuff when passsing "special" as root device name Sep 16 12:02:11 hm, looks like some eglibc craziness. I guess they should go in the -dev package too. Sep 16 12:02:13 this with distro=micro and machine=i686-generic Sep 16 12:02:39 probably not worth worrying about for now though, I guess you don't plan to do any compiling on the target platform itself :-) Sep 16 12:02:44 pb__, what about line 22? Sep 16 12:03:04 neh, I'll be happy to run the helloworld package on the target :-) Sep 16 12:03:07 czr_: similar logs for glibc too Sep 16 12:03:11 well. maybe ls and cat too if I get crazy enough. Sep 16 12:03:22 czr_: I think that's harmless in this case Sep 16 12:03:27 right. good. Sep 16 12:03:47 czr_: the *libc recipes hare hard beasts to package Sep 16 12:03:57 iirc, those libraries are being shipped in some kind of "libc-unwanted-detritus" package. the warning is just the library autonamer saying that it doesn't know what to do, but this is okay since you don't want that package to be autonamed anyway Sep 16 12:03:59 I can just imagine Sep 16 12:04:18 ah, ok Sep 16 12:04:37 that whole LEAD_SONAME thing was a bad idea, it should just go away. Sep 16 12:04:47 * czr_ agrees. Sep 16 12:04:53 although I have no idea what it means, but.. Sep 16 12:05:36 i guess I can pretty much ignore NOTEs as long as the package builds. Sep 16 12:05:37 the idea was that, if you had a package with multiple shlibs in it, you could give the autonamer a hint as to which one should be used to name the package. Sep 16 12:06:02 why I thought this was a clever thing to do is now lost in the mists of time, but I am now fairly sure that I was wrong about it whatever the reason was. Sep 16 12:06:03 oh well. Sep 16 12:06:48 uh. building cross gcc-4.4.1 Sep 16 12:07:08 I guess this is a good time as any to take a break :-). Thanks all for help, I'll be back later hopefully. Sep 16 12:07:20 righto, later Sep 16 12:07:26 * pb__ bbiab too, heading to the hardware lab now Sep 16 12:13:12 cool. coreutils built. yay. Sep 16 12:21:18 hi! Sep 16 12:21:39 Hi Im not sure how OE works in relation to compiling modules, I want to write a simple helloworld device driver for gumstix earth Sep 16 12:22:51 I was running Concierge 1.0.0 on Cacao 0.99.4 with classpath 098 on an arm, and I got an alignment trap Sep 16 12:23:08 who I should I send the error log to ? Sep 16 12:23:45 saiimons: to the cacao dudes, I suppose Sep 16 12:25:04 any module developers here that can explain? I was thinking of somehow modifing the bitbake build for the image to incorerate my device driver Sep 16 12:25:51 incorporate* Sep 16 12:26:25 yes, you should be able to add it to your image.bb just like any other package.# Sep 16 12:30:10 would this be the easiest solution? i am guessing i should be using bitbake to build everything instead of the old make command. i am not sure were the image "recipes" are held Sep 16 12:30:36 you mean a patch adding a module to the kernel? just add the patch (e.g. http://pastebin.com/m7c9e7958) to your kernel SRC_URI Sep 16 12:30:42 03Koen Kooi  07org.openembedded.dev * ra7144f8e73 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): xserver-xorg-conf: add omap3-touchbook support Sep 16 12:31:32 SilentJonathan: see http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-gumstix_2.6.15.bb Sep 16 12:33:20 i mean a new module from scratch such as a helloworld module http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C1 Sep 16 12:33:38 thanks ant_work ill have a look at it Sep 16 12:53:16 Crofton|work: I think it was the symlink that caused the problems :) Sep 16 12:58:23 tasslehoff: good to hear angstrom/stable still builds :-} Jkes apart, eagle is the most supported noard atm Sep 16 12:59:59 Can OE be used in any celular with ARM arch ? Sep 16 13:01:47 julemore: some palms, openoko Sep 16 13:02:20 How do I know if my device can handle OE? Sep 16 13:02:46 does it have an open kernel available Sep 16 13:03:06 what? Sep 16 13:03:27 if its good a 2.6 kernel available, you can easilly add support in OE Sep 16 13:04:13 no, listen my celular is a Toshiba TG01 1GHZ ARM and 256 MB with windows mobile... I want to use OE in it... Sep 16 13:04:31 possible? Sep 16 13:06:19 julemore: the answer is the same, does it have a linux kernel available for it? Sep 16 13:06:19 I guess anything is possible, it's just a question of how much work is required. Sep 16 13:06:37 khem: i get the same error with DISTRO="minimal" Sep 16 13:06:40 afaik there is no existing port for tg01 so it would be fairly difficult (though presumably possible) to make OE run on it. Sep 16 13:06:47 khem: install: cannot stat `/home/kimrhh/OE/tmp/work/armv7a-oe-linux-gnueabi/eglibc-2.10-r6.1/eglibc-2_10/libc/sunrpc/rpcsvc/bootparam_prot.h': No such file or directory Sep 16 13:06:53 XorA how can I know it? Sep 16 13:07:07 OE is just a build environment isn't it? Sep 16 13:07:10 julemore: www.google.com is pretty good these days Sep 16 13:07:11 khem: from "bitbake console-image" Sep 16 13:09:09 XorA, I thought that the only thing necessary for using OE in a celular is 1. minimum hardware 2. AARM archictecture Sep 16 13:09:33 I mean of course there is not a dsitro for my celular.. thats why I want to use OE Sep 16 13:10:12 well, you need a kernel etc Sep 16 13:10:20 there is customization needed Sep 16 13:10:20 julemore: well you can of course write all the support for it yourself Sep 16 13:10:38 julemore: so technically you can, but I dont think that is what you really mean Sep 16 13:11:17 When u say support... u mean drivers for integrated resources as wigi, gps, LCD etc? Sep 16 13:11:27 wifi Sep 16 13:11:51 julemore: more basic than that, you need a kernel first Sep 16 13:11:57 julemore: then you can think about drivers Sep 16 13:12:12 but OE its a kernel itself isnt? Sep 16 13:12:22 julemore: no, its a build system Sep 16 13:12:23 khem: trying with stable now Sep 16 13:13:27 And isnt there any generic ARM BUILDING? Sep 16 13:13:36 julemore: no Sep 16 13:13:54 julemore: even windows mobile has different kernels for different devices Sep 16 13:16:56 XorA 3 years ago I got an ARM DEVICE called M501 Artila with 280 MHZ... I did create a boot and rootfs from a generic 2.6.X linnux version... The only thing I needed was a patch for the CPU AT91RM2000... and it worked, The problem was that I cannont access any resource like USB etc Sep 16 13:17:44 thats why I was thinking I can Sep 16 13:17:49 could Sep 16 13:18:59 morning Sep 16 13:21:16 julemore: "patch for the CPU AT91RM2000..." that doesnt sound very generic Sep 16 13:22:16 patch for a concrete CPU is more generic than toshiba tg01 Sep 16 13:22:47 julemore: so does the cpu in toshiba have a kernel? Sep 16 13:23:06 and the cpu is something like Snapdragon Sep 16 13:23:16 julemore: if you spent as much time looking it up as discussing here, you would be 99% of the way to the answer Sep 16 13:23:36 lol k Sep 16 13:23:50 lets search for Snapdragon linux support Sep 16 13:23:52 it seems there are solutions (millos/ThunderSoft) Sep 16 13:25:14 oooh coool Sep 16 13:25:18 snapdragon Sep 16 13:25:20 :) Sep 16 13:25:52 you should be able to get OE to compile any generic kernel, then work from there Sep 16 13:26:11 k Sep 16 13:51:47 hmm 141M /tmp/ang/work/armv4t-angstrom-linux-gnueabi/openssl-0.9.8j-r10.0/staging-pkg/staging/armv4t-angstrom-linux-gnueabi/usr/lib/libcrypto.a Sep 16 13:51:51 quite big Sep 16 13:57:01 khem: stable fails for gcc instead :( Sep 16 13:57:04 khem: /home/kimrhh/OE/tmp/work/armv7a-oe-linux-gnueabi/gcc-cross-initial-4.2.4-r5/gcc-4.2.4/gcc/crtstuff.c:1: error: bad value (cortex-a8) for -mtune= switch Sep 16 13:57:19 would it be better to report this on a mailing list or something? Sep 16 13:57:44 kimrhh, what MACHINE and DISTRO? Sep 16 13:59:19 Crofton|work: DISTRO = "minimal", MACHINE = "beagleboard" Sep 16 13:59:47 i do not think gcc-4.2.4 supports armv7 Sep 16 13:59:58 all the beagle devs are using Angstrom Sep 16 14:00:30 Crofton|work: it was a suggestion in here to try minimal distro, since angstrom failed Sep 16 14:00:31 is minimal even supported in stable Sep 16 14:01:06 well, talk to the minimal support team then :) Sep 16 14:01:28 Crofton|work: for angstrom as distro i get: cannot stat `/home/kimrhh/OE/tmp/work/armv7a-angstrom-linux-gnueabi/glibc-2.9-r35.2/glibc-2.9/sunrpc/rpcsvc/bootparam_prot.h': No such file or directory Sep 16 14:02:01 odd I successfully built that only a couple of days ago Sep 16 14:02:05 kimrhh, are you building stable or dev? Sep 16 14:02:28 hmm, but that is the .dev version pf glibc Sep 16 14:02:52 Crofton|work: tried both with angstrom, same result Sep 16 14:02:59 pulling and building dev to see what happens Sep 16 14:03:05 does someone have any hints how to limit the needed system performance of yaffs2 operations when removing big files from a nand flash? Sep 16 14:03:23 Crofton|work: bitbake console-image, that is Sep 16 14:03:25 Crofton|work: I built that in .dev only 12 hours ago Sep 16 14:03:42 the file operation blocks all other processes in system when erasing files Sep 16 14:03:50 yeah, I rebuilt for me yesterday Sep 16 14:04:05 armv4 is b0rk3d which I have a patch for Sep 16 14:04:11 but beagle worked fine Sep 16 14:04:52 gm Sep 16 14:05:18 gm Sep 16 14:05:39 XorA: can it at all be parallel-make related? Sep 16 14:05:49 I bumped the kernel rev on my x86 build from 2.6.25 to 2.6.29 and madwifi-ng now won't build: Sep 16 14:05:51 XorA: or something else with my configuration Sep 16 14:05:53 http://pastebin.com/m7952c2f4 Sep 16 14:06:06 kimrhh: I use 6 threads so I doubt it Sep 16 14:06:30 sakoman: isnt madwifi in staging drivers now? Sep 16 14:06:48 this in stable/2009 Sep 16 14:06:57 XorA: this is my local.conf: http://dpaste.com/94366/ Sep 16 14:07:38 I bumped the revision on madwifi to the most recent, but it fails in the same way Sep 16 14:11:01 kimrhh: I am clueless as to what is going wrong Sep 16 14:12:51 hmmm . . . this doesn't seem to show up in other machines because task-base only builds madwifi if the machine has pci Sep 16 14:13:16 morning Sep 16 14:13:48 gm kergoth Sep 16 14:14:15 sakoman: I have noticed it before, and just removed madwifi from the build as my machines didnt have one Sep 16 14:14:50 XorA: what method did you use to remove it? Sep 16 14:15:12 sakoman: butcher task-base Sep 16 14:15:24 XorA: ok :) Sep 16 14:15:36 XorA: yeah, that's my inclination too Sep 16 14:15:41 sakoman, XorA: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=aea9acb329d715db851c1bed8506c3d0f9b42ae1 Sep 16 14:15:50 XorA: but you succesfully built what for beagle some time ago? Sep 16 14:15:59 there must be a builable version, the EEE machines have ath5k devices in them Sep 16 14:16:07 meh, sleepy Sep 16 14:16:10 kimrhh: successfully last night Sep 16 14:16:26 XorA: console-image ? Sep 16 14:17:23 kergoth: looks like a good candidate for stable/2009 too :-) Sep 16 14:17:50 kimrhh: all the way to x11-image Sep 16 14:18:26 XorA: hmm ok Sep 16 14:19:59 anybody using the latest classpath out of Angstrom? Sep 16 14:21:35 XorA: stable or dev? Sep 16 14:22:54 kimrhh: .dev Sep 16 14:23:16 khem: any news about my --fix-v4bx problem? Sep 16 14:28:47 i can't even find the source of this flag Sep 16 14:30:32 mickeyl: what's the actual problem you are having? Sep 16 14:30:53 w/ gcc 4.4.1 i can't compile a kernel Sep 16 14:31:26 what's the error? Sep 16 14:31:32 | /local/pkg/oe/om-gta02/tmp/cross/armv4t/lib/gcc/arm-oe-linux-gnueabi/4.4.1/../../../../arm-oe-linux-gnueabi/bin/as: unrecognized option '--fix-v4bx' Sep 16 14:31:58 what binutils do you have? Sep 16 14:32:25 sounds like it's too old. Sep 16 14:32:28 2.18 Sep 16 14:32:33 ah, that's definitely too old Sep 16 14:32:37 ah, ok Sep 16 14:32:40 you need to get a newer binutils or an older gcc Sep 16 14:32:42 which one can you recommend? Sep 16 14:32:51 I'm using 2.19.51 at the moment and it seems to be working ok Sep 16 14:32:59 I think any 2.19.x should suffice for your needs though Sep 16 14:33:05 ok, thanks Sep 16 14:33:12 we should fix sane-toolchain.inc then Sep 16 14:33:20 it recommends this very combination Sep 16 14:33:24 doh Sep 16 14:33:31 # Base line versions, good for most things Sep 16 14:33:31 PREFERRED_GCC_VERSION ?= "4.4.1" Sep 16 14:33:31 PREFERRED_BINUTILS ?= "2.18" Sep 16 14:33:31 that certainly doesn't sound very sane Sep 16 14:33:47 pb__: does that flag mean armv4 can do eabi now? Sep 16 14:33:49 eww Sep 16 14:34:11 pb__: as the only thing stopping it was the bx instruction Sep 16 14:34:13 XorA: well, sort of. Sep 16 14:34:38 obviously v4 will never be able to fully support the eabi, since eabi mandates thumb interworking and there is no thumb at all on v4. Sep 16 14:35:10 but, yes, --fix-v4bx will generally allow you to link together a bunch of eabi (interworking enabled) object files to get a non-interworking binary which will run on v4 Sep 16 14:35:17 pb__: yeah, but instead of compiling oabi for one class of cpu, we should be able to just use it like a v4t without thumb? Sep 16 14:35:28 right, that is the idea Sep 16 14:35:33 pb__: awesome Sep 16 14:35:41 * XorA will try that tonight Sep 16 14:44:51 * czr_ starts working on a new machine config. Sep 16 14:45:07 I guess the at91sams are pretty close to "stock" arm926ej-s configs. Sep 16 14:48:06 czr_: I used them as a basis for our 926ej-s based SoC and it worked fine Sep 16 14:48:25 * czr_ nods Sep 16 14:48:59 I think for the first run I'll build the kernel manually. any ideas on which gcc should be used for this? is 4.4.1 ok? (cross arm5vte) Sep 16 14:52:30 we building the kernel manually using codesourcery 4.2.1, but it also works with an OE-built 4.3.3 Sep 16 14:52:33 not tried anything later Sep 16 14:52:48 we *were*... Sep 16 14:53:43 hmm. correct me if I'm wrong, but assuming that linux-libc-headers is at 2.6.23-r4, then any new kernel features past that version won't be exposed to the built (e)glibc? right? Sep 16 14:53:52 (stuff like timerfd and such) Sep 16 14:54:51 not sure. something i've never paid much attention to but probably should! Sep 16 14:55:05 czr_: yes Sep 16 14:55:14 czr_: I added 2.6.31 yesterday Sep 16 14:55:22 * czr_ nods Sep 16 14:55:36 the micro distro isn't using it by default though. it's still on .23. where can I change this? Sep 16 14:56:07 czr_: I tested building, but havent actually run the code Sep 16 14:56:09 mike_cw, I'm trying to learn oe as I go, so I'm kind of shooting in the dark. still. after a year + using oe :-) Sep 16 14:56:18 hmm. ok. maybe I'll try later then. Sep 16 14:56:29 once I manage to get the current version to run first Sep 16 14:57:05 same here. i think we will switch to it for the officially build system for the chip. i'm in the process of evaluating it. Sep 16 14:58:27 mike_cw, which chip are you working with? Sep 16 14:58:44 Chipwrights CW5631 Sep 16 14:59:11 arm926ej-s + a dsp Sep 16 14:59:24 * czr_ looking at the product brief. interesting Sep 16 15:12:46 * czr_ needs food. laters -> Sep 16 15:25:33 Can we make bitbake pick any file from an overlay... so that we can override a single config file used by some bb using an overlay e.g.? Sep 16 15:26:11 florian: you can use FILESPATH to do that Sep 16 15:27:16 kergoth: ah sounds like i just need to read the manual :-) Sep 16 15:27:20 FILESPATHBASE =. "${TOPDIR}/files:" will let you override that single config file based on TOPDIR Sep 16 15:27:26 mkdir files/busybox Sep 16 15:27:31 echo foo > files/busybox/defconfig Sep 16 15:27:34 bitbake busybox Sep 16 15:28:05 you could manipulate FILESPATHBASE to go based on COLLECTIONS or BBPATH to add the relative path to the recipe from each element or so Sep 16 15:28:54 kergoth: ah that's nice indeed - many thanks! Sep 16 15:29:03 someone posted an example to the list to do exactly what you want, but i can't remember the thread :\ Sep 16 15:29:14 i have a snippet that does it here, but it depends on changes to collections.inc that i don't think i've pushed yet Sep 16 15:29:31 I'll tell the imap server to find the one :-) Sep 16 15:29:34 the one on the list hardcodes it, it adds like 'recipes/${PN}' relative to each entry in bbpath Sep 16 15:30:10 i use the topdir based stuff all the time, particularly coupled with amend-recipes.inc Sep 16 15:31:04 mkdir -p files/busybox; cp /some.patch files/busybox; echo "SRC_URI += 'file://some.patch;patch=1' >> files/busybox/amend.inc; echo 'PR .= ".1"' >> files/busybox/amend.inc; bitbake busybox Sep 16 15:32:28 hmm right... never used that but that combination is nice Sep 16 15:37:18 kergoth, are you aware of problems with staging in srctree? Sep 16 15:37:55 tardyp: the indentation issue? cbrake pointed it out yesterday, haven't had a chance to look at it. i'm sure its just a matter of switching it to spaces instead of tabs... we really need to make _prepend/_append smarter when it comes to python functions Sep 16 15:38:57 i'll try to repro today Sep 16 15:39:16 kergoth, I dont know what you are talking about Sep 16 15:39:26 okay, well thats the only issue i know of Sep 16 15:39:38 it is just that srctree breaks the staging if I use it for clutter Sep 16 15:39:41 03Michael 'Mickey' Lauer  07org.openembedded.dev * r2a3d5c2197 10openembedded.git/recipes/python/python-dbus_0.83.0.bb: python-dbus: add some more dependencies Sep 16 15:39:44 "breaks the staging"? Sep 16 15:39:54 03Michael 'Mickey' Lauer  07org.openembedded.dev * r306ae77b3b 10openembedded.git/conf/distro/include/sane-toolchain.inc: sane-toolchain.inc: bump default binutils to a version that works with the default gcc Sep 16 15:40:01 the .pc file is not in staging dir Sep 16 15:40:15 maybe it is a difference with poky Sep 16 15:40:39 hmm, it uses the existing do_stage, it shouldn't behave any differently Sep 16 15:40:47 i'll try pulling down clutter and see if i can reproduce Sep 16 15:41:48 You know, I'm using the EXTRA_INHERIT_pn-clutter-1.0 = "srctree gitver" trick Sep 16 15:42:03 ah, right, okay Sep 16 15:42:31 i went and upgraded some packages on my ubuntu karmic box at work, and now it no longer boots Sep 16 15:42:37 * kergoth is reconstructing his build environment.. Sep 16 15:43:04 * * OE Bug has been RESOLVED by xerxes(AT)zafena.se Sep 16 15:43:06 * * e2fsprogs-libs : unexpected keyword argument 'allow_links' Sep 16 15:43:08 * * http://bugs.openembedded.net/show_bug.cgi?id= Sep 16 15:48:03 silly question, but is there a tool to extract ipk packages without running ipkg on the target? Sep 16 15:48:15 it's an ar archive Sep 16 15:48:23 in the ar archive are two tarballs Sep 16 15:48:29 one with the metadata, one with the files that will be installed Sep 16 15:48:33 it's the same file format as .deb Sep 16 15:48:45 i'm sure googling would tell you more details Sep 16 15:48:47 ah. explains the "Debian binary package (format 2.0)" what file says. Sep 16 15:48:51 indeed Sep 16 15:48:53 that's enough, thanks :-) Sep 16 15:48:55 np Sep 16 16:02:25 * czr_ is sneaky and uses dpkg-deb -x package.ipk . Sep 16 16:04:05 * * OE Bug has been RESOLVED by xerxes(AT)zafena.se Sep 16 16:04:07 * * Cant override thumb default for armv5 and v4 in local.conf using Angstrom Sep 16 16:04:09 * * http://bugs.openembedded.net/show_bug.cgi?id= Sep 16 16:05:37 kergoth: would you check if in MV too the staging-ipk's have broken arch? Pls check something target specific e.g. udev. Acyually OE and Poky exhibit the issue. Sep 16 16:07:29 kergoth: yeah karmic broke for me too. It does not recognise the networking devices anymore so wlan0 and eth0 are missing Sep 16 16:07:53 * khem` installed opensuse 11.2 Sep 16 16:07:57 morning khem` Sep 16 16:08:05 hello ant_work Sep 16 16:23:52 he...atm Gentoo is the only distro without victims in the upgrade-path (friends say..I confirm) Sep 16 16:25:20 XorA|gone: console-image still fails for me Sep 16 17:06:00 bbl Sep 16 17:11:40 * kergoth lets ideas bounce around his head for how you'd want to configure a standalone image creation tool Sep 16 17:14:04 standalone image creation tool - as in something to dd straight to media? Sep 16 17:14:48 i'm thinking of a script rather than a recipe. Sep 16 17:15:04 take packages as inputs, or files, or dirs, or whatever Sep 16 17:15:09 the recipe method is rather limited Sep 16 17:15:35 kind of like a debootstrap meets mk thing? Sep 16 17:15:45 yeah, exactly Sep 16 17:16:09 hi , iam back at oe with a new platform .. its a ppc 440 :-) lets see how for i get Sep 16 17:22:42 * czr_ used to have a ibm netstation with ppc440 something. Sep 16 17:23:07 ran some variant of bsd based x server Sep 16 17:23:43 * kergoth ponders configuration file formats for an image builder tool.. what all do we need to express.. Sep 16 17:23:55 human editable text file? Sep 16 17:24:08 well yeah, but beyond that. the oe configuraiton file format is too limited Sep 16 17:24:14 kergoth: netbsd/freebsd have makefs utility :) Sep 16 17:24:16 ah. Sep 16 17:24:22 thinking maybe a configobj based nested ini file Sep 16 17:24:22 but this is only for ufs :) Sep 16 17:24:28 how does it work? Sep 16 17:24:41 kergoth: its funny that you and I so often worry about the same problems Sep 16 17:24:41 moment Sep 16 17:24:45 hehe Sep 16 17:25:07 kergoth: http://www.freebsd.org/cgi/man.cgi?query=makefs&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html Sep 16 17:25:08 well, i was thinking that a big part of the complaints of folks like prpplague, the bringup type folk, isn't so much the build infrastructure as it is the lack of control over the filesystem/image creation process Sep 16 17:25:23 is it possible to do separate busybox binaries that link to libbb? Sep 16 17:25:25 ding! Sep 16 17:25:31 with the current bb setup? Sep 16 17:28:35 You really have to emulate the buildroot behavior Sep 16 17:28:50 people want to pick from a menu and pull a crank Sep 16 17:30:04 hmm, itd be cool if the image creation UI could spawn / interact with a bitbake server process to automatically build only whats needed to include those bits in the image Sep 16 17:30:14 kergoth: oh... I'm just looking for a solution for the same. Sep 16 17:31:02 Especially in a distributed environment like a company Sep 16 17:31:11 the debootstrap behavior is really attractive Sep 16 17:31:17 one buildmeister, many users Sep 16 17:31:55 kergoth: I was thinking about an ini-file like format. That's easy to read/write in software and everyone understands it. Sep 16 17:32:02 yeah Sep 16 17:32:31 long term i could see going to that for the *config* side of OE, leaving the rest as the flexible metadata Sep 16 17:50:05 curious why linux-libc-headers version isn't tied directly to kernel version? Is it because its meant to be machine neutral and just arch specific? I notice angstrom uses linux-libc-headers-2.6.23 which seems like it may be dated as far as userspace ioctl's go compared to say 2.6.30/31 kernels? Sep 16 18:00:06 tharvey_, I actually asked almost the same question today :-) Sep 16 18:00:29 not quite the same though. (and I don't know the answer to yours really, as to the why). Sep 16 18:01:19 I have a custom kernel recipe which adds a userspace ioctl for a driver - looks like in order to get the header file into the sdk properly I need to patch both the kernel recipe and the linux-libc-headers Sep 16 18:02:28 I've also found that sdk's really need to be machine specific and not arch specific as they contain kernel headers which are machine specific - so again not quite sure why linux-libc-headers can't simply come from virtual/kernel Sep 16 18:02:42 * czr_ nods Sep 16 18:02:58 you might want to wait for the answer here or just drop the question to the ml Sep 16 18:03:27 tharvey_: they can these days Sep 16 18:04:00 tharvey_: if you have an idea how to implement it go ahead Sep 16 18:04:07 khem, has that been done in recent patches? I'm probably a month or so behind Sep 16 18:04:15 I have thought of doing it so many times but never got there Sep 16 18:04:31 tharvey_: no it has not been done Sep 16 18:04:37 but we can certainly extend it Sep 16 18:04:52 khem, someone told me today that you would know how to customize eglibc? or rather, how to select which features to drop? Sep 16 18:05:05 khem, I did implement kernel-headers (for out-of-tree modules) a while back (with your help) by inserting it into kernel.bbclass but I don't believe it ever got committed Sep 16 18:05:07 czr_: yes Sep 16 18:05:24 tharvey_: no it did not Sep 16 18:05:44 khem, I'm using the micro distro with couple of targets (just playing around still). how to do it? or is there an example somewhere? Sep 16 18:06:01 tharvey_: for kernels after 2.6.18 sanitized headers can be built using kernel makefiles now Sep 16 18:06:27 czr_: so far we have not done the config part in eglibc in OE Sep 16 18:06:36 ah Sep 16 18:06:44 czr_: but its needed Sep 16 18:06:48 khem, thats by using include/linux/Kbuild right? Sep 16 18:06:51 itd be like uclibc Sep 16 18:07:10 hmm. where do I look for uclibc customization stuff? Sep 16 18:07:16 tharvey_: actually linux makefile has a target to generate sanitized headers Sep 16 18:07:52 make headers iirc Sep 16 18:07:55 khem, right, I believe it utilizes list of headers in include/linux/Kbuild though Sep 16 18:08:41 yes and unifdef Sep 16 18:13:11 czr_: http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/option-groups.def?rev=8712&view=markup Sep 16 18:13:20 these are options available for configuring Sep 16 18:13:57 czr_: and you can en/disable them in libc/option-groups.defaults Sep 16 18:14:15 ah. so I could do it manually at least. cool & thanks Sep 16 18:14:29 czr_: or you can have option-groups.config Sep 16 18:15:05 in top of tree Sep 16 18:15:05 what's the difference between them? Sep 16 18:15:23 well option-groups.config is supposed to be user defined Sep 16 18:16:03 option-groups.config will override settings in option-groups.defaults Sep 16 18:16:12 so essentially you should look at option-groups.defaults Sep 16 18:16:17 and see what you do not need Sep 16 18:16:20 right. thanks Sep 16 18:16:35 I'll try to play with that tomorrow (I have to get a vendor kernel to work first) Sep 16 18:16:36 and then create a option-groups.config and disable those features in there Sep 16 18:17:22 by default every option is included Sep 16 18:17:42 so basically the default eglibc is just as large as glibc, right? Sep 16 18:18:11 czr_: yes it glibc with embedded focus Sep 16 18:18:29 CosmicPenguin: i wonder if something like http://dl.getdropbox.com/u/112715/Documents/foo.ini.txt would be a reasonable way to control the behavior.. course that doesn't have the way to specify which bits from which inputs go in.. just playing around Sep 16 18:18:35 http://www.eglibc.org/features Sep 16 18:18:40 well yes, that much I know beforehand but still :-). it's kind of difficult to find noob-oriented docs on the real differences and such. Sep 16 18:18:44 http://www.eglibc.org/mission Sep 16 18:19:10 yes, I've read all of that stuff, but have yet to actually see how to customize it. your info helps a lot, thanks. Sep 16 18:19:24 no problems Sep 16 18:19:57 I wonder how many recipes will break with a very very minimal eglibc Sep 16 18:20:08 if you dont worry about backward compatibility --disable-versioning will reduce the size Sep 16 18:20:09 most of the stuff that I see seems to be quite obscure (at least to me) Sep 16 18:20:24 hmm. where do I put that? Sep 16 18:20:46 yes if you have a set of apps then you can start tailoring Sep 16 18:21:10 its a configure option that can be added to EXTRA_OECONF Sep 16 18:21:41 ah. what does it do? leaves out versioning info from the symbols? Sep 16 18:23:02 yes Sep 16 18:23:27 cool. I never quite got glibc versioning to work anyway Sep 16 18:23:38 somehow even the most simple programs fail to run across different glibc-versions. Sep 16 18:23:38 then disable it :) Sep 16 18:23:46 cool. thanks Sep 16 18:23:52 it's a one off build anyway. Sep 16 18:23:56 at least for now. Sep 16 18:37:04 03shr build user  07shr/import * raf26800f5c 10openembedded.git/recipes/pulseaudio/ (2 files in 2 dirs): libcanberra: increase buffer size in alsa backend Sep 16 18:59:37 http://tinderbox.openembedded.net/public/logs/task/2882429.txt Sep 16 18:59:46 configure: error: compiler support for __thread is required Sep 16 18:59:57 what can it be? Sep 16 19:06:34 03shr build user  07shr/import * r0d8df78666 10openembedded.git/recipes/pulseaudio/ (2 files in 2 dirs): libcanberra: increase buffer size a bit more Sep 16 19:18:18 03Aleksandr Koltsoff  07org.openembedded.dev * r4c4c18764b 10openembedded.git/conf/distro/include/sane-toolchain.inc: Sep 16 19:18:18 sane-toolchain.inc: armv5te mentioned twice on eabi-capable list Sep 16 19:18:18 * armv5te is mentioned twice in the arm_eabi_supporting_arches list of Sep 16 19:18:18 sane-toolchain.inc. Remove the latter occurance. Sep 16 19:18:18 Signed-off-by: Khem Raj Sep 16 19:18:20 Acked-by: Cliff Brake Sep 16 19:29:42 03Martin Jansa  07shr/import * r82764d7012 10openembedded.git/recipes/python/python-docutils-native_0.5.bb: Sep 16 19:29:42 Add python-docutils-native_0.5.bb from oe.dev.org (needed for midori and libtheora docs) Sep 16 19:29:42 Signed-off-by: Klaus Kurzmann Sep 16 19:29:43 03Thomas Zimmermann  07shr/import * r4dca81d597 10openembedded.git/recipes/gtk-webcore/ (midori/config midori_0.1.10.bb): Sep 16 19:29:45 Midori: add fullscreentoggle to toolbar Sep 16 19:29:47 Signed-off-by: Klaus Kurzmann Sep 16 19:29:49 03Thomas Zimmermann  07shr/import * r38dd42000a 10openembedded.git/recipes/gtk-webcore/midori_0.1.10.bb: Sep 16 19:29:52 Midori: Fix depencies for buildings docs Sep 16 19:29:54 Signed-off-by: Klaus Kurzmann Sep 16 19:29:56 03Thomas Zimmermann  07shr/import * rca2977b42a 10openembedded.git/recipes/vagalume/vagalume_0.7.1.bb: Sep 16 19:29:59 Vagalume: fix RDEPENDS Sep 16 19:30:01 Signed-off-by: Klaus Kurzmann Sep 16 19:31:06 Hi Sep 16 19:31:25 I'm building console-image. How do I disable task-wiki when doing that? Sep 16 19:34:11 03Stanislav Brabec  07org.openembedded.dev * r1cf1e7ed14 10openembedded.git/recipes/ (2 files in 2 dirs): libxcalibrate, calibrateproto: Increment PE to upgrade packages in feeds. Sep 16 19:37:15 03Stanislav Brabec  07org.openembedded.dev * r7081e345e4 10openembedded.git/recipes/intltool/ (9 files): intltool: Increase INC_PR to replace pre-INC_PR packages in feeds. Sep 16 19:38:51 03Stanislav Brabec  07org.openembedded.dev * r70bd2a139a 10openembedded.git/recipes/wget/ (wget.inc wget_1.11.4.bb wget_1.9.1.bb): wget: Increase INC_PR to replace pre-INC_PR packages in feeds. Sep 16 19:42:27 03Stanislav Brabec  07org.openembedded.dev * r9298697cbf 10openembedded.git/recipes/bluez/ (3 files in 2 dirs): bluez-gnome: Fix crash on pairing configured rfcomm device. Typo fix. Sep 16 19:53:28 03Stanislav Brabec  07org.openembedded.dev * r952eef23cc 10openembedded.git/recipes/gtk+/ (8 files): gtk+: Implemented INC_PR, require hicolor-icon-theme. Sep 16 20:03:42 fsck when is OEDEM? Sep 16 20:03:51 what is the alternative to classpath for Java in Angstrom? Sep 16 20:12:26 re Sep 16 20:13:08 I am writing an do_patch_append() but it does not parse. (If I place the same in do_configure_prepend() it works. Sep 16 20:13:23 Do we have do_patch_append support? Sep 16 20:14:18 interesting I thought _append and _prepend worked for all tasks Sep 16 20:16:27 khem: nice work on testing gcc4.4.1 Sep 16 20:16:57 zecke: thx Sep 16 20:17:13 zecke: it will pair well with binutils 2.20 which is due this month Sep 16 20:18:27 likewise: _append/_prepend are generic, they dont' care what variable they're operating against. perhaps you're trying to append shell to a python task? Sep 16 20:19:34 kergoth: How can I tell if do_patch is a python task? Should my .inc file or .bb know what the base class implementation is? Sep 16 20:20:22 kergoth: The snippet I tried to add to the linux.inc is in this ml thread; it fetches the latest ARM machine types list: "[oe] [PATCH] linux-igep2: Add 2.6.28.10 for IGEP v2 machine" Sep 16 20:21:27 oh and Hi All! Sep 16 20:27:42 likewise: _prepend/_append aren't smart enough. ideally, for functions at least, they'd construct a list of things to be built, shell or python, but right now its just a concatenation, which causes problems if you try to append shell to python or vice versa, or if you try to append a tab indented python script to a space indented python function Sep 16 20:27:58 likewise: it's something we should definitely see about fixing for future versions of bitbake Sep 16 20:28:04 but for now i can tell you, do_patch is python. Sep 16 20:28:08 03Stanislav Brabec  07org.openembedded.dev * re6b1829aea 10openembedded.git/recipes/prismstumbler/prismstumbler_0.7.3+0.7.4pre1.bb: prismstumbler: Don't apply wireless.patch for linux-libc-headers >= 2.6.30. Sep 16 20:28:19 you can always add a new task between unpack and patch, or between ptach and configure, to do what you want done Sep 16 20:28:19 r Sep 16 20:28:19 ath Sep 16 20:28:19 er Sep 16 20:28:19 th Sep 16 20:28:20 an Sep 16 20:28:21 Sep 16 20:28:24 er, rather than appending Sep 16 20:30:59 kergoth: have you checked by chance the arch in a staging-ipk ? Sep 16 20:31:01 kergoth: thanks, this I didn't know. (and I already tried the space vs. tabs approach because suspected something in that area). Sep 16 20:32:00 likewise: np Sep 16 20:32:08 ant__: fraid not, been quite busy with other tasks for work Sep 16 20:33:13 np Sep 16 20:33:20 pls don't forget Sep 16 20:33:38 hopefully MV is sane in that regard Sep 16 20:35:15 i doubt it is. its functional, but i have a task somewhere in my list to go back over the package arch situation for packaged staging Sep 16 20:35:30 :/ Sep 16 20:35:33 have to deal with the fact that cross recipes need both build/target archs captured in the packages Sep 16 20:35:45 since their binaries are dependent upon boht Sep 16 20:36:22 yeah, i have a task on my list: "Fix arch handling for pstage packages." Sep 16 20:37:07 so if you want to fix it yourself, have at it :) doubt i'll have time anytime soon Sep 16 20:50:51 morning kergoth Sep 16 20:52:09 hi pb Sep 16 20:52:13 hi kergoth Sep 16 20:52:44 hi woglinde Sep 16 20:53:24 hey Sep 16 20:57:39 kergoth: I see in staging_helper () ipkgarchs="${BUILD_SYS}" which is evaluated as ipkgarchs="i686-linux" Sep 16 20:58:36 but at this point things should have been 'crossed' Sep 16 20:59:21 BUILD_SYS is always the build machine, it isn't affected by cross. Sep 16 20:59:46 am I mixing SYS<->HOST? Sep 16 20:59:49 HOST_SYS is the one that changes for crosses Sep 16 20:59:54 k Sep 16 21:00:14 (normal packages have HOST_SYS==TARGET_SYS, cross packages typically have HOST_SYS==BUILD_SYS) Sep 16 21:14:00 pb___: perhaps all started here: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=614d84bf383ec75aa55a5d2aece99f7ce43b7e41 Sep 16 21:14:22 and in cross.bbclass there is any sort of trick :) Sep 16 22:18:41 ant__: did you figure out the usr dir in TMPDIR Sep 16 22:21:22 I think Sep 16 22:22:54 should it exist Sep 16 22:23:07 it comes from ${TMPDIR}${layout_libdir} Sep 16 22:23:45 in packaged-staging.bbclass Sep 16 22:23:59 can it be put in ${TMPDIR}/${HOST_SYS}/ Sep 16 22:24:31 I'm trying to correlate this and the wrong arch in the staging-packages... Sep 16 22:28:41 export USB_LIBS="-L${WORKDIR}/libusb-0.1.12/.libs/ -l:libusb-gnur.a" Sep 16 22:29:11 in a recipe, how can I get it to keep " s around the env var Sep 16 22:30:20 'USB_LIBS=-L/home/balister/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.2.1-r7.1+gitra08c659c122f24947421adf38e7260642a67381a-r7.1/libusb-0.1.12/.libs/ -l:libusb-gnur.a' Sep 16 22:30:26 causes trouble later Sep 16 22:30:48 basically, I need some help quoting stuff in recpies :) Sep 16 22:31:57 EXTRA_OEMAKE += "'USB_LIBS=-Lthis -Lthat'"? Sep 16 22:32:15 (note, the quotes are around the entire argument passed to make) Sep 16 22:33:38 this ends up fed to a sub confugure some how Sep 16 22:33:44 http://tinderbox.openembedded.net/public/logs/task/2883928.txt Sep 16 22:33:48 lat line Sep 16 22:33:51 last line Sep 16 22:35:23 basically, the vars are used to make configure find the local copy of libusb Sep 16 23:04:09 khem: looking again at packaged-staging, PSTAGE_PKGARCH = "${BUILD_SYS}" Sep 16 23:04:49 and echo "Architecture: ${PSTAGE_PKGARCH}" >> ${PSTAGE_TMPDIR_STAGE}/CONTROL/control Sep 16 23:05:42 so I suppose the former is valid only if bb.data.inherits_class('native', d) or bb.data.inherits_class('cross', d) or bb.data.inherits_class('sdk', d): Sep 16 23:11:26 good night Sep 17 02:54:45 so i ran into a known bug with newer versions of findutils Sep 17 02:54:56 and the recommended fix was to add 'gl_cv_func_wcwidth_works=yes' to config.site Sep 17 02:55:01 is there another way to do this? Sep 17 02:57:09 eg. a configure.ac patch? Sep 17 02:58:22 oh gnulib/m4/wcwidth.m4 has it **** ENDING LOGGING AT Thu Sep 17 02:59:57 2009