**** BEGIN LOGGING AT Wed Jan 13 02:59:57 2010 Jan 13 07:54:33 hello. i build an image for a x86 target. the image works fine but i experienced a strange problem. sometimes when i reboot the machine the network is not initialized (ifconfig shows no output at all) a reboot will fix this issue but when the system starts with no ip address i can only reboot it locally. anyone got an idea? Jan 13 09:22:34 morning Jan 13 09:25:28 hrw: gm Jan 13 09:48:27 morning all ! Jan 13 09:49:39 gremlin[it]: hi Jan 13 09:50:23 hi mckoan|away, i booked all for FOSDEM ! ... Jan 13 09:51:17 gremlin[it]: great! I'm looking forward to meeting you there :-) Jan 13 09:51:34 mckoan|away, same for me Jan 13 09:58:42 my old distro is getting a little bit better with the help of oe Jan 13 09:59:13 I can't forget the old one by now ... Jan 13 10:09:04 the fantastique question is : hw to add udev to my old distro? or, maybe, is better to use the mdev in busybox ? Jan 13 10:09:22 depends on what you want recalcati Jan 13 10:09:41 usb and mmc hotplug most of all Jan 13 10:10:03 hotplug or automount? Jan 13 10:10:17 automount Jan 13 10:10:27 both will work Jan 13 10:10:31 03Khem Raj  07org.openembedded.dev * rcc57844de3 10openembedded.git/recipes/gcc/gcc-4.4.2/ (138 files in 4 dirs): Jan 13 10:10:31 gcc-4.4.2: Delete unused patches. Jan 13 10:10:31 Signed-off-by: Khem Raj Jan 13 10:10:41 03Khem Raj  07org.openembedded.dev * r892ca3199b 10openembedded.git/recipes/gcc/ (gcc-svn.inc gcc-svn/gcc-flags-for-build.patch): Jan 13 10:10:41 gcc-svn: Port gcc-flags-for-build patch for getting cross native build going. Jan 13 10:10:41 Signed-off-by: Khem Raj Jan 13 10:10:45 hrw: work on busybox? 1.10.1 ? Jan 13 10:11:08 I used mdev with 1.13 iirc Jan 13 10:14:23 hrw: ok, thx, I'll try. Jan 13 10:21:55 If PACKAGE_ARCH=something when this recipe do a autotools_stage_all things should be moved to staging/${PACKAGE_ARCH}-${MACHINE_ARCH} no ? Jan 13 10:23:36 read ${PACKAGE_ARCH}-${HOST_OS} instead of ${PACKAGE_ARCH}-${MACHINE_ARCH} Jan 13 10:41:23 someone familiar with perl? Jan 13 10:46:14 flo_lap: good morning Jan 13 10:46:34 03Koen Kooi  07org.openembedded.dev * r80db15f2b5 10openembedded.git/ (2 files in 2 dirs): gst-fluendo-mpegdemux: add 0.10.23 Jan 13 10:46:35 03Koen Kooi  07org.openembedded.dev * r76fb223eef 10openembedded.git/ (conf/checksums.ini recipes/bluez/obexd_0.21.bb): obexd: add 0.21 Jan 13 10:46:35 03Koen Kooi  07org.openembedded.dev * r2153070fc5 10openembedded.git/recipes/bzip2/bzip2_1.0.5.bb: bzip2: add missing symlink Jan 13 10:46:44 03Koen Kooi  07org.openembedded.dev * r9c4e6be040 10openembedded.git/recipes/totem/totem_2.28.5.bb: Jan 13 10:46:44 totem 2.28.5: add missing dep on gnome-doc-utils Jan 13 10:46:44 - also drag in some more buildtime deps to build more (optional) plugins Jan 13 10:48:10 filip.zyzniewski@tefnet ~/pda/oe/build_dir $ file tmp/work/i686-linux/nspr-native-4.8.2-r0/image/usr/include/nspr tmp/staging/i686-linux/usr/include/nspr Jan 13 10:48:13 how can this be? Jan 13 10:48:16 tmp/work/i686-linux/nspr-native-4.8.2-r0/image/usr/include/nspr: directory Jan 13 10:48:18 tmp/staging/i686-linux/usr/include/nspr: cannot open `tmp/staging/i686-linux/usr/include/nspr' (No such file or directory) Jan 13 10:48:22 why didn't stuff from image go into staging? Jan 13 10:48:32 (my own bb file) Jan 13 10:50:46 pb_: I'm the real one ;) Jan 13 10:50:54 good morning Jan 13 10:51:14 heh Jan 13 10:52:20 NOTE: Running task 258 of 262 (ID: 8, /home/filip.zyzniewski/pda/oe/openembedded/recipes/nspr/nspr-native_4.8.2.bb, do_populate_staging) Jan 13 10:52:25 this should copy it, right? Jan 13 10:55:33 help :)? Jan 13 10:55:50 filip: it's rather hard to help without knowing what is in your .bb file Jan 13 10:55:58 if you pasted that somewhere, maybe someone can give you some advice Jan 13 10:56:29 ah sure Jan 13 10:58:07 pb_: the file is here: http://filip.eu.org/jornada/oe/nspr/ (native one) Jan 13 11:00:40 mm, there's nothing very obvious in there that would be causing it to go wrong. Jan 13 11:00:51 that's why I am utterly lost here Jan 13 11:01:10 you ought to be using ${libdir} and ${includedir} in your configure line, rather than hard-coding some random path, but in practice I suspect those variables probably do match what you have written there in your configuration. Jan 13 11:01:38 I will polish it once chromium builds properly Jan 13 11:01:45 I guess you will have to poke at the sysroot staging code to see why it isn't doing the right thing for you. that'd be sysroot_stage_dirs() and similar functions in base.bbclass. Jan 13 11:01:54 thanks Jan 13 11:02:00 (presumably you don't get the "legacy staging mode" diagnostic, right?) Jan 13 11:02:40 I do Jan 13 11:02:46 ah Jan 13 11:02:48 does it matter? Jan 13 11:02:59 yes, that indicates that the whole auto-staging system is disabled. Jan 13 11:03:12 in that case, you need to figure out why that is happening. Jan 13 11:03:34 does that particular bb file cause this or something else? Jan 13 11:03:40 generally the particular bb file Jan 13 11:03:55 ok, I'll debug this Jan 13 11:04:02 if it had a do_stage() method then that would cause this, but yours doesn't appear to Jan 13 11:04:35 fwiw, the function that determines whether to use legacy mode is "is_legacy_staging()" in base.bbclass Jan 13 11:05:34 so, you need to arrange for that function to return false. Jan 13 11:37:49 03Martin Jansa  07org.openembedded.dev * r6533f07110 10openembedded.git/recipes/ (8 files in 8 dirs): Jan 13 11:37:49 linux-2.6.32-2.6.33-rc4: add rc4 instead of rc3 drop patch already Jan 13 11:37:49 applied upstream Jan 13 11:37:49 Signed-off-by: Martin Jansa Jan 13 11:37:50 03Martin Jansa  07org.openembedded.dev * r0328134214 10openembedded.git/recipes/tasks/task-boot.bb: Jan 13 11:37:55 task-boot: use DISTRO_UPDATE_ALTERNATIVES instead of update-alternatives directly Jan 13 11:37:57 * Images built after 2009-12-08 9b641bbfed07c075ae5cbe84082a85f1ba703447 Jan 13 11:37:59 probably use opkg-native, but also ship with u-a-cworth Jan 13 11:38:01 Signed-off-by: Martin Jansa Jan 13 11:38:03 03Martin Jansa  07org.openembedded.dev * rbd5d3afd23 10openembedded.git/recipes/busybox/busybox.inc: Jan 13 11:38:06 busybox: bump INC_PR to force postinst script run on targets after u-a fixup Jan 13 11:38:08 Signed-off-by: Martin Jansa Jan 13 11:38:12 03Martin Jansa  07org.openembedded.dev * rd6eb534006 10openembedded.git/recipes/ (6 files in 3 dirs): (log message trimmed) Jan 13 11:38:15 opkg, update-alternatives-cworth: use /usr/lib/opkg/alternatives directory instead of /usr/lib/ipkg/alternatives Jan 13 11:38:17 * It's usefull to make it compatible with u-a script in opkg package Jan 13 11:38:19 * Old entries are merged to new directory in quite verbose postinst Jan 13 11:38:21 script Jan 13 11:38:25 * If entry exists only in old it's moved Jan 13 11:38:27 * If entry exists in both the one with more lines is used Jan 13 11:47:59 re Jan 13 11:48:34 jo mickey Jan 13 11:48:44 morsche Jan 13 11:49:01 hi mickey|sofa Jan 13 11:49:05 hi florian Jan 13 11:49:07 morning florian Jan 13 11:49:21 hi woglinde Jan 13 11:49:32 mickey|sofa: good morning Jan 13 11:49:40 hm, snowing here again Jan 13 11:49:52 pb uha Jan 13 11:50:14 pb seems GB will die Jan 13 11:50:17 hi pb_, here it stopped now. But everything is white Jan 13 11:50:28 woglinde: yeah, it seems Jan 13 11:50:45 with the amount of salt that they seem to be pouring onto the roads, I guess all plant life will be extinguished. Jan 13 11:50:52 and all rivers will become undrinkable Jan 13 11:50:54 as to interpret an old german saying Jan 13 11:51:35 heh Jan 13 11:51:40 yesterday I read something funny Jan 13 11:51:41 so many good vibrations before breakfast Jan 13 11:51:54 * mickey|sofa brews a decaf to lighten his mood up ;) Jan 13 11:52:03 I GB no one cleans the way, so they cant be sued if some one falls Jan 13 11:52:40 mickey|sofa: heh Jan 13 11:52:52 args in GB Jan 13 12:38:50 morning all Jan 13 12:40:41 my do_install() seems to be overriden by bitbake with make DESTDIR=/home/filip.zyzniewski/pda/oe/build_dir/tmp/work/armv4-linux/nss-native-3.12.5-r0/image install Jan 13 12:40:45 can I prevent that? Jan 13 12:42:30 hi rp Jan 13 12:43:54 ah maybe it's me Jan 13 13:10:48 hi rp Jan 13 13:58:16 ah maybe it's me/ Jan 13 13:58:20 can I make do_stage just copy the image/* into staging? Jan 13 14:21:27 that's approximately what sysroot_stage_all() ought to be doing for you automatically. Jan 13 14:21:49 did you manage to figure out why your recipe was ending up with legacy mode selected? Jan 13 14:32:15 03Koen Kooi  07org.openembedded.dev * r4a10cd2be0 10openembedded.git/recipes/mplayer/ (mplayer-common.bb mplayer-common/angstrom/mplayer.conf): mplayer-common: switch to ao=alsa for angstrom, oss emulation is broken in >2.6.31 Jan 13 14:32:25 03Koen Kooi  07org.openembedded.dev * r507d23ac85 10openembedded.git/recipes/mplayer/ (files/fix-exp.diff mplayer_svn.bb): mplayer: fix build error with EXPR_2F Jan 13 14:44:39 is it possible to get the templates used on tinderbox.openembedded.net ? Jan 13 15:01:28 EsbenH: what do you mean? CSS? Jan 13 15:02:15 khem: ping. Are you there? Jan 13 15:02:31 Laibsch: yes, it seems like the CSS files are doing something strange Jan 13 15:02:41 like what? Jan 13 15:03:56 I am testing with the django "runserver" thingy Jan 13 15:04:14 the dashboard.css being served to my browser is not the same as the one on disk Jan 13 15:04:51 it has added whitespace all around Jan 13 15:04:58 and cut out the @import line Jan 13 15:05:15 basically ripping out all the layout :-( Jan 13 15:06:32 you're talking about tinderbox.oe.net, right? Are you applying any custom CSS? Can you paste me a screenshot somewhere? Jan 13 15:07:47 http://foss.doredevelopment.dk:8000/ Jan 13 15:08:15 I fetched the css from tinderbox.oe.net Jan 13 15:08:20 (using wget -np -r) Jan 13 15:14:47 I wonder if django caches these files somewhere.... Jan 13 15:14:56 If I change something in fx. dashboard.css Jan 13 15:15:12 and fetch the file (again) with wget, I still get the old version. Jan 13 15:25:41 I just updated openembedded from git and now I get this whenever I run bitbake: http://pastebin.com/m7fa58a40 Jan 13 15:27:32 what version of bitbake do you have? Jan 13 15:33:15 pb_, 1.8 Jan 13 15:33:44 1.8.18, or actually 1.8? Jan 13 15:44:38 have a nice rest of the day Jan 13 15:44:49 ah, that helped Jan 13 15:45:07 django were serving from it's own media files, even if I gave it the specific path Jan 13 15:45:13 works much better with Apache as fronted :-) Jan 13 15:57:07 pb_, git tag 1.8 Jan 13 15:57:19 sorry was afk Jan 13 16:14:06 Hi, I wrote a simple bb file to compile opencpn an autmake project. But now i want to debug it with eclipse. I can compile and run code on beagle with eclipse. Is there any easy method to convert it to an eclipse project? Jan 13 16:14:07 03Koen Kooi  07org.openembedded.dev * rbb44fcc7fc 10openembedded.git/recipes/xorg-driver/xf86-input-tslib_0.0.6.bb: xf86-input-tslib: bump PR to something newer than it was due to the xorg .inc Jan 13 16:14:08 03Koen Kooi  07org.openembedded.dev * r75268ccf88 10openembedded.git/recipes/pam/libpam-base-files.bb: libpam-base-files: RRECOMMEND libpam-meta Jan 13 16:14:10 03Koen Kooi  07org.openembedded.dev * ra267182e12 10openembedded.git/ (9 files in 3 dirs): gdm: move to 2.28.2, fix conflict with libpam-base-files Jan 13 16:16:49 Hi, I wrote a simple bb file to compile opencpn an autmake project. But now i want to debug it with eclipse. I can compile and run code on beagle with eclipse. Is there any easy method to convert it to an eclipse project? Jan 13 16:17:35 zuencap2: there is something about eclipse in the wiki Jan 13 16:17:46 not sure if that can help, I'm not using eclipse Jan 13 16:18:36 Which parameters I should use to invoke ./configure? Jan 13 16:19:03 I can do the rest my self. Jan 13 16:22:06 zuencap2: search for OTE in oe wiki Jan 13 16:32:16 anything special that one need s to do to get /packages/ to work with django-oestats ? Jan 13 16:36:36 I found OTE but there is nothing about debugging. I don't want to run bb file and generate ipkgs. Jan 13 16:37:15 Is there any way to prevent bitbake from deleting code files after compiling? Jan 13 16:39:08 sure - do not inherit rm_work Jan 13 16:40:13 my bb file inherits autotools Jan 13 16:40:39 how can I remove rm_work Jan 13 16:41:05 in local.conf you have it Jan 13 16:42:48 Thanks a lot Jan 13 17:01:30 re Jan 13 17:04:35 someone with wiki account awake? Jan 13 17:04:53 fosdem event should have an entry on the frontside Jan 13 17:05:23 ok I have an account but I don't know what rights are associated with this account Jan 13 17:05:31 ie if I can modify the front page Jan 13 17:05:34 likewise, mckoan|away, Crofton, khem, otavio, denix: can you take a look at patchwork 1449/1450/1451/1462/1463 and ack them? Jan 13 17:06:01 hrw robert and I will come to fosddem Jan 13 17:06:04 args fosdem Jan 13 17:06:12 company sponsors Jan 13 17:06:21 wow Jan 13 17:06:23 woglinde: I know Jan 13 17:06:25 I'll try to come Jan 13 17:06:34 woglinde: ask Robert to fix wiki page - he is PR guy Jan 13 17:06:35 ;D Jan 13 17:06:45 hrw hihi is already gone Jan 13 17:06:50 I am alone now at work Jan 13 17:07:07 hrw wasnt clear until today if company sponsors the trip Jan 13 17:07:43 maybee I will raise it to mailinglist Jan 13 17:07:56 and we need a page for atendees Jan 13 17:08:05 woglinde: create one Jan 13 17:08:18 hm Jan 13 17:08:29 I have to write documentation Jan 13 17:08:34 so I will now off again Jan 13 17:08:36 *g* Jan 13 17:09:55 bye till later Jan 13 17:12:13 hrw: acked. I'm not an expert in Java, but changes look fine Jan 13 17:12:51 denix: ack all 5? Jan 13 17:13:14 yep Jan 13 17:13:31 should see the emails shortly Jan 13 17:14:05 thx Jan 13 17:27:48 morning Jan 13 17:28:18 hi kergoth Jan 13 17:29:31 hey pb_ Jan 13 17:29:36 * kergoth ponders career path Jan 13 17:30:10 ah, that old problem Jan 13 17:30:44 heh, been kind of floundering about for a while, no clear direction Jan 13 17:31:24 is there much room for progression inside mvista? Jan 13 17:31:30 I don't really know what they're like as an organisation. Jan 13 17:32:00 there aren't really senior roles that I've seen, nor are there architects, so the only route is management Jan 13 17:32:06 ah Jan 13 17:32:21 I guess you don't especially want to go into management. Jan 13 17:33:30 should give it more thought. in the past i never really liked the idea, but being a technical lead or in a project/product management position might not be too terrible Jan 13 17:33:48 bye Jan 13 17:33:54 but i think architect -> cto or something might be a better approach.. either that, or stick to pure engineering and stick to a senior position Jan 13 17:33:55 * kergoth shrugs Jan 13 17:35:54 was looking at indeed.com the other day, there's a position at logitech that wants OE experience. i didn't realize anyone over there made use of it Jan 13 17:36:11 oh, heh. no, I never heard of them using it either. Jan 13 17:37:09 I guess there's also the alternate career path of not being an employee at all and focussing more on freelance consulting/contracting kind of work. Jan 13 17:37:20 that's a good point Jan 13 17:37:25 that would provide some nice schedule flexibility Jan 13 17:37:53 but you should be aware that discipline is very important in that case Jan 13 17:38:02 * Laibsch speaks from experience Jan 13 17:38:04 :-( Jan 13 17:38:38 yeah. of course, the flexibility goes both ways: you lose the benefit of a dependable paycheck each month. Jan 13 17:39:20 but it's nice to be able to decide for yourself what to work on and when. Jan 13 17:48:22 pb_, any idea for my problem earlier? Jan 13 17:51:54 th1: no, not really. I'm not seeing that problem; I am using bitbake 1.8.18 rather than a git checkout, though I don't know if that is actually related to your issue. Jan 13 17:52:32 ok Jan 13 17:52:40 I'll try with bitbake head and see if that makes any difference Jan 13 17:52:48 just need to build python2.6 packages for my debian first Jan 13 18:06:13 * kergoth sighs Jan 13 18:06:27 not a good day? Jan 13 18:07:17 just odd issues. this time libidl-native is failing to find glib.h, because the -I its picking up from the .pc somehow has the staging path twice. /home/foo/.../tmp/staging.../home/foo/.../tmp/staging Jan 13 18:07:23 hrmph Jan 13 18:07:35 must have missed something when syncing with OE Jan 13 18:10:59 yet a diff of the classes & config files doesn't show anything of the sort.. what the heck Jan 13 18:11:25 does anyone know why qt4-embedded doesn't build certain libraries out of the box? QtUiTools for example? Jan 13 18:12:16 I can't figure out how to include it... Jan 13 18:28:31 thats odd.. this .pc has one path in the cflags, but a pkg-config --cflags on it from devshell prefixes the include paths with staging, even though the pkg config sysroot env var isn't set.. Jan 13 18:28:34 hrm Jan 13 18:29:10 it's not set in devshell? Jan 13 18:29:34 aha, found it.. local patch i forgot about :) Jan 13 18:29:44 * kergoth wonders why this didn't break anything before the sync with oe Jan 13 18:30:22 heh Jan 13 18:30:31 I bet now that you found it, you could make it break :) Jan 13 18:31:18 help Jan 13 18:31:31 for whatever reason we patched pkg-config to automatically set sysroot / pkg_config_path based on its current location.. which is well and good if you're running it outside of OE, but OE sets those for the builds anyway, setting them when unset breaks native recipes which rely on an unset sysroot... Jan 13 18:31:32 bhgv: are you drowning? on fire? Jan 13 18:31:34 * kergoth grumbles Jan 13 18:32:19 typo ssorry Jan 13 18:34:25 hm Jan 13 18:34:36 there seems to be a problem with non-legacy stage populating Jan 13 18:35:00 what is the problem? Jan 13 18:36:25 command in base.bbclass:1155 os.system(bb.data.expand('cp -pPR ${SYSROOT_DESTDIR}${TMPDIR}/* ${TMPDIR}/', d)) Jan 13 18:36:43 is resolved to: cp -pPR /home/filip.zyzniewski/pda/oe/build_dir/tmp/work/i686-linux/nspr-native-4.8.2-r0/sysroot-destdir//home/filip.zyzniewski/pda/oe/build_dir/tmp/* /home/filip.zyzniewski/pda/oe/build_dir/tmp/ Jan 13 18:37:08 pwd when launching bitbake is /home/filip.zyzniewski/pda/oe/build_dir Jan 13 18:37:17 now the cp arguments don't make any sense Jan 13 18:37:32 /home/filip.zyzniewski/pda/oe/build_dir/tmp/work/i686-linux/nspr-native-4.8.2-r0/sysroot-destdir//home/filip.zyzniewski/pda/oe/build_dir/tmp doesn't exist Jan 13 18:38:47 what is this cp execution for? Jan 13 18:39:21 I don't alter neither SYSROOT_DESTDIR nor TMPDIR Jan 13 18:39:59 downside to screwing with the classes: now i get to wipe tmp and do another world build from scratch.. maybe i should start using ccache again after all Jan 13 18:40:20 re Jan 13 18:40:40 how to specify empty SRC_URI and get ipk built? source is fetched in custom task Jan 13 18:40:40 kergoth, ccache will bite you and you knwo it :) Jan 13 18:40:44 hrw: czesc :) Jan 13 18:40:45 or you won't have abig enough cache Jan 13 18:41:05 yeah.. true. end up chasing your own tail for ages before you think to consider a corrupt object in the cache Jan 13 18:41:06 filip: cześć Jan 13 18:41:07 hrw, aside from faking it with SRC_URI = 'file:///dev/null', not sure :( Jan 13 18:41:41 pb__: do you have any idea about a possible cause of this? Jan 13 18:42:17 Tartarus: SRC_URI = "file://${FILE}" works Jan 13 18:42:32 Tartarus: FILE=recipe_filename ;D Jan 13 18:43:23 i think we patched our package_ipk to handle empty src_uri.. or had it fall back to the recipe or something Jan 13 18:43:25 * kergoth looks Jan 13 18:43:41 kergoth: you as MVL? Jan 13 18:44:27 src_uri = bb.data.getVar("SRC_URI", localdata, 1) or \ Jan 13 18:44:27 bb.data.expand("file://${FILE}", localdata) Jan 13 18:44:29 heh Jan 13 18:45:02 ;) Jan 13 18:45:09 kergoth: merge it Jan 13 18:47:11 hrw: the OE one falls back to ${FILE} directly, right now, so i don't think there's a problem, afaict Jan 13 18:47:36 ok, stable branch does not Jan 13 18:48:16 ah Jan 13 18:50:07 bye Jan 13 18:51:33 hi,I've some toolchain problem: http://pastebin.com/m4e977222 Jan 13 18:51:41 so...should I paste config.log? Jan 13 18:51:57 is the build order wrong? should I clean something and rebuild? Jan 13 18:52:23 I'm at revision 75268ccf888a07612411491ee0ad3d2ca3366eb8 Jan 13 18:56:18 filip: hm, yeah, that cp does look a bit weird, but I guess it works for everyone else. I guess you should take this up with RP. Jan 13 18:57:50 pb__: RP? Jan 13 18:59:43 filip: yes Jan 13 19:02:27 kergoth: regarding your libidl-native problem. bluelightning saw something similar one of these days for mtd-utils-native. I also had trouble with the package which I pinned down to $BUILDDIR being taken from my build environment (most vars are cleared as you know). Maybe that is something you want to check. Jan 13 19:03:01 oh, I see you already found the problem Jan 13 19:03:05 Laibsch: already worked it out, it was something mvl6 specific hosing it :) thanks for the tip, though, will keep an eye out Jan 13 19:08:08 hmm, any guides floating around for the sheevaplug that anyone has handy? I'm sick of mine collecting dust Jan 13 19:24:25 grr, I'm getting really fed up with jffs2. gotta find something better. Jan 13 19:24:56 UBIFS seems to be the crack de jour Jan 13 19:25:55 GNUtoo|oeee: does it happen when you are doing build from scratch ? Jan 13 19:26:21 no not from scratch Jan 13 19:26:30 some glibc had a problem updating Jan 13 19:26:31 yeah, I should try ubifs. Jan 13 19:26:37 so I cleaned all glibc+gcc Jan 13 19:26:52 GNUtoo|oeee: I see thats the catch 22 situation probably Jan 13 19:27:06 ubi is nice on NAND Jan 13 19:27:10 what's that? Jan 13 19:27:12 GNUtoo|oeee: if you have to rebuild glibc Jan 13 19:27:24 ah Jan 13 19:27:36 what should I do beside rebuilding from scratch? Jan 13 19:27:56 then you should do something like unstage gcc-cross Jan 13 19:28:08 and then clean glibc Jan 13 19:28:10 ok Jan 13 19:28:19 stage gcc-cross-intermediate Jan 13 19:28:21 I cleaned it too Jan 13 19:28:24 ok Jan 13 19:28:32 does oe have the ability to generate ubi filesystems? Jan 13 19:28:37 and glibc-initial needs to be staged too Jan 13 19:28:54 ok Jan 13 19:28:55 actually glibc an glibc-initial provide same files (headers) Jan 13 19:29:06 which gcc-cross needs to function properly Jan 13 19:29:14 ok Jan 13 19:29:22 once you clean glibc it also stabs glibc-initial Jan 13 19:29:31 which means now gcc-cross wont work well Jan 13 19:29:49 when I said I cleaned every glibc it means the cross the initial etc... Jan 13 19:29:59 try to bitbake clean glibc and then bitbake stage glibc-initial Jan 13 19:30:21 did you also clean cross-gcc ? Jan 13 19:31:32 ok thanks Jan 13 19:33:36 yes Jan 13 19:33:37 pb__: sure it does.. Jan 13 19:33:43 everything gcc or glibc Jan 13 19:34:26 pb__: if you want both ubifs and ubinized .ubi just put ubi IMAGE_FSTYPES Jan 13 19:34:39 GNUtoo|oeee: hmmm, then it should work better Jan 13 19:34:44 ok Jan 13 19:35:02 pb__: you can put there just ubifs if you don't care about ubinize (you have ubi partition already prepared) Jan 13 19:36:19 khem, re: prev discussion on-list: i guess that the majority of that 600MiB (!!) of a checkout comes from such superfluous patches. I wouldn't be surprised if about 20% of the whole tree consists of such orphaned patches that were blindly copied to a new version but were never ever intended to applied to that particular version. This suspicion cries for some sanity check in bitbake if a patch-dir contains unapplied patches, IMHO Jan 13 19:39:46 blindvt: I am cleaning up one by one Jan 13 19:39:59 I think gcc is one big chunk Jan 13 19:40:29 has many revisions and if a patch involves configure scr\ipts the patch size can grow quite a bit Jan 13 19:40:42 plus its confusing to know which patches are applied and which not Jan 13 19:40:58 because the patches get appended in different .inc and .bb files Jan 13 19:41:04 which makes it even worse Jan 13 19:41:12 so its better to delete the unused ones Jan 13 19:41:22 hi khem Jan 13 19:41:25 and if really needed they can be recovered Jan 13 19:41:34 Laibsch: hello Jan 13 19:41:35 did you find anything with regard to the glib-2.0 failure? Jan 13 19:41:44 Laibsch: didnt really look Jan 13 19:41:55 NOO Jan 13 19:42:03 I had to pick my friends family yesterday Jan 13 19:42:15 well Jan 13 19:42:20 not too late I guess Jan 13 19:42:27 The failure is still there of course Jan 13 19:42:35 their flight was delayed by 2 hrs Jan 13 19:42:53 Laibsch: how about the task bar issue Jan 13 19:43:16 woglinde committed a fix/hack Jan 13 19:43:25 ugh Jan 13 19:43:28 * khem looks Jan 13 19:43:29 He just leaves out the problematic bits Jan 13 19:43:50 Although we all seem to be unclear as to what functionality now is missing Jan 13 19:44:30 anyone ever run into this one with postfix-native? Jan 13 19:44:34 ./postfix-install: Error: no /home/clarson/oe/projects/sync/tmp/staging/i686-linux/usr/bin/postconf file. Did you forget to run "make"? Jan 13 19:44:34 mmm ERROR: Task do_stage does not exist for target glibc-initial Jan 13 19:44:36 khem, that binutils-2.20 ones were just the cause tripping /me into yelling and i'm sorry for doing this since i by no means ment to sound as rude as i did when reading what you quoted in your reply, bit still.. I think i got an excuse since the symptom trips fairly often, AFAI can see Jan 13 19:44:49 Laibsch: thats a real hack :) Jan 13 19:45:31 blindvt: happens Jan 13 19:45:39 khem: We're relying on you for a proper fix :-b (given that bluelightning is not around) Jan 13 19:45:48 btw someone is reporting me that we can't fetch boost 1.41 because its website is down Jan 13 19:46:01 JaMa: okay, very good Jan 13 19:46:12 khem, does but of course shouldn't. please accept my (retroactive) apologies Jan 13 19:46:14 GNUtoo|oeee: should the OE sources mirror pick that up? Jan 13 19:46:22 * Laibsch has a look Jan 13 19:46:27 maybe Jan 13 19:47:47 [Wed Jan 13 19:34:17 2010] [error] [client 69.15.127.225] File does not exist: /var/www/sourcemirror/boost-1.41.0.cmake0.tar.gz Jan 13 19:48:09 If anybody has that file, holler! Jan 13 19:48:10 in how much time can it be done? the website is at : http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0/boost-1.41.0.cmake0.tar.gz Jan 13 19:48:26 I have it\ Jan 13 19:48:35 that URL is 404, too Jan 13 19:48:46 I'll put it on my router Jan 13 19:48:50 GNUtoo|oeee: If you let me have it, I can put it on the mirror Jan 13 19:48:57 ok thanks a lot Jan 13 19:49:10 must have been 404 for a while, I guess Jan 13 19:53:20 http://gnutoo.homelinux.org/sources/boost-1.41.0.cmake0.tar.gz Jan 13 19:53:54 kergoth, quick question regarding bb"improve printing dependent tasks" (http://patchwork.openembedded.org/patch/1135/): Do i need to resend this to the bitbake-dev@berlios list or may i ask you to kindly accept my ping, just this time? I promise to send bb stuff to the proper list, next time if need be Jan 13 19:54:08 GNUtoo|oeee: Oh, big file Jan 13 19:54:28 37M Jan 13 19:54:28 blindvt: i'll see if i have time today to look at it, pretty busy with work at the moment Jan 13 19:55:03 kergoth, cool. It's a rather trivial UI improvement, just let me know. TIA Jan 13 19:55:13 do you want me to lzma it? Jan 13 19:56:45 http://paste.debian.net/56580/ is the list of fetch failures the last time I updated the sources mirror. Jan 13 19:56:53 GNUtoo|oeee: no. I'm almost there Jan 13 19:57:04 ok Jan 13 19:57:33 my router is slow...since it is a adsl connection and in adsl there is the word asymetric Jan 13 19:58:36 don't worry Jan 13 19:58:44 I'm glad it's there at all Jan 13 19:58:51 ok Jan 13 19:59:00 also check the checksums Jan 13 19:59:01 making the OE fetcher more robust Jan 13 19:59:07 in the case the file is corrupt Jan 13 19:59:10 That will be done automatically by the clients Jan 13 19:59:25 I had issue with the hdd of the laptop which holds the file Jan 13 19:59:30 I'll check it now Jan 13 20:00:25 should be fine Jan 13 20:00:45 it's 351747d991e3e391fea5623d4b5c038a on the tarball and in the recipe Jan 13 20:01:46 Laibsch: How can I use the source mirror in my local.conf Jan 13 20:01:59 Laibsch: or does it fall back to source mirror automatically Jan 13 20:02:04 khem: You should have it already. It's been made the default Jan 13 20:02:11 Laibsch: ok Jan 13 20:02:13 Why would anyone not want it Jan 13 20:02:14 ? Jan 13 20:02:26 yeah natural pick Jan 13 20:02:51 Laibsch: remind me of the include errors you were getting Jan 13 20:02:55 with that one native recipe Jan 13 20:03:01 when? Jan 13 20:03:08 yesterday Jan 13 20:03:08 when do you want to be reminded? Jan 13 20:03:33 now :) Jan 13 20:03:39 I wanted the logs Jan 13 20:03:54 * khem looks in ff history Jan 13 20:05:35 ff history? Jan 13 20:05:39 You chat with ff? Jan 13 20:05:55 You downloaded the stuff, didn't you? Jan 13 20:06:11 firefox Jan 13 20:06:13 I guess he means his ff download history. Jan 13 20:06:21 Laibsch: I downloaded the task-bar problem Jan 13 20:08:43 Laibsch, do you also want boost-1.40.0.cmake2.tar.gz ? Jan 13 20:09:10 khem: http://oss.leggewie.org/wip/khem/ should have what you want, I think Jan 13 20:09:13 I should find a way to put theses 17G of sources in my router Jan 13 20:09:19 GNUtoo|oeee: sure, why not Jan 13 20:09:23 ok Jan 13 20:09:33 are you on a fixed IP? Jan 13 20:11:48 Laibsch: this is the one I was looking for http://paste.debian.net/56518/ Jan 13 20:12:12 Oh, I see Jan 13 20:12:14 Sorry Jan 13 20:12:24 Let me know if you want anything else Jan 13 20:13:37 Does http://paste.debian.net/56580/ look proper to you guys? I'm particularly concerned about Jan 13 20:13:37 export includedir="/usr/include" Jan 13 20:13:37 ok done : http://gnutoo.homelinux.org/sources/boost-1.40.0.cmake2.tar.gz Jan 13 20:14:09 hrm.. pulling the oe iscsi-target broke my build, since locally we were only building the utils, not the module.. i wonder how best to manage that.. separate module/userland into two recipes.. config var.. Jan 13 20:16:27 two recipes sounds easier to do Jan 13 20:17:07 Laibsch: /usr/include is not there in the paste you posted Jan 13 20:17:15 Laibsch, no dynamic ip Jan 13 20:17:17 it lists failed fetch list Jan 13 20:17:19 Laibsch: http://paste.debian.net/56579, you mean? Jan 13 20:17:21 thats what i was thinking. thanks, i'll do that Jan 13 20:17:26 * kergoth adds to todo Jan 13 20:17:30 that looks basically ok to me, though I don't quite know what the context is. Jan 13 20:18:05 pb_: oops, sorry, yes. clipboard contained the wrong URL Jan 13 20:18:34 bitbake -e could change with what target you provide Jan 13 20:18:55 like bitbake -e or bitbake -e Jan 13 20:18:56 pb_: the reason I'm asking is that a recipe I'm about to create sets includedir to /usr/include (host include) and thus fails Jan 13 20:19:04 I was wondering if that was the reason Jan 13 20:19:07 kergoth: yeah, definitely two recipes Jan 13 20:19:11 wrong setup on my end Jan 13 20:19:22 just like with the BUILDDIR issue I had the other day. Jan 13 20:19:23 iscsi-target & kernel-module-iscsi-target, perhaps? Jan 13 20:19:48 or iscsi-target-utils & iscsi-target? Jan 13 20:19:48 Laibsch: includedir is relative to the ${D}, so "/usr/include" would be correct assuming you have prefix=/usr Jan 13 20:19:51 i think i like the former better Jan 13 20:19:56 kergoth: yeah, the former Jan 13 20:20:10 OK I'll need to look into it further, then Jan 13 20:20:10 okay, thanks Jan 13 20:20:41 i think all i have left to pull from OE is bluez4 changes into the libs/apps recipes.. then, need to look at newer versions of things.. been only pulling fixes.. Jan 13 20:20:43 whew.. Jan 13 20:20:46 Laibsch: though, obviously, it depends on what your recipe is actually using ${includedir} for. if it has some conflicting use for it then there is certainly the potential for problems. Jan 13 20:20:47 * kergoth needs a better workflow Jan 13 20:21:06 kergoth: yah, I don't think anybody has ever figured out a very good workflow for that. Jan 13 20:21:21 pb_: http://paste.debian.net/56578 bb file name is given in the comment Jan 13 20:21:48 this workflow *works*, but .. still way too complicated Jan 13 20:22:03 makes me wonder if there's something we can do fundamentally in how OE works to make it easier to maintain subsets of the metadata Jan 13 20:23:23 kergoth: I suspect that boils down to the separation of different responsibilities (i.e. declaration of input source versus build method versus what to do with the output) that we've talked about in the past. Jan 13 20:23:32 * kergoth nods Jan 13 20:23:45 probably needs someone to actually make that happen :-) Jan 13 20:24:11 I guess you could see if you can get the TSC interested in it. Jan 13 20:24:50 yeah, would be good to see what they think about the possibility.. if they agree with that direction, then we can sit down and try to hash out a way to make it happen with incremental changes Jan 13 20:24:59 yeah Jan 13 20:25:44 as with many things, we are limited by people available to do the work Jan 13 20:25:58 too many users, not enough develoeprs Jan 13 20:26:08 although, this is not really a bad problem :) Jan 13 20:31:48 well, often its just a matter of sitting down and doing it Jan 13 20:32:05 I've implemented things that were in the back of my mind for years in about two days of work, just never got around to it.. Jan 13 20:32:09 :) Jan 13 20:32:38 erk, MACHINE_KERNEL_PR is .. ick Jan 13 20:32:44 * kergoth wonders why it was implemented that way Jan 13 20:33:14 * kergoth would have thought PR .= ".${MACHINE_KERNEL_PR}" woudl be better than PR = "${MACHINE_KERNEL_PR}" Jan 13 20:34:28 03Koen Kooi  07org.openembedded.dev * r0d85e0aac0 10openembedded.git/recipes/powervr-drivers/ (3 files): Jan 13 20:34:28 omap3-sgx-modules: make 1.4.14.2514 the default and make it build against 2.6.32 Jan 13 20:34:28 libgles-omap3: make 3.01.00.02 the default and attempt to fix file permissions Jan 13 20:34:55 Too late now, unless we use EPOCH :) Jan 13 20:35:04 re Jan 13 20:36:22 * kergoth pulled the latest classes, and noticed: "iscsi-target-0.4.17-" Jan 13 20:36:28 (unset MACHINE_KERNEL_PR :P) Jan 13 20:40:17 GNUtoo|oeee: BTW, tell eveybody to use tinderbox for reporting. That way, I shall catch missing files more easily. We should have everything that right now is at their original location. But I can of course hunt down files individually as well if I know they are missing. Jan 13 20:40:39 ok Jan 13 20:40:41 hi laibsch Jan 13 20:41:04 the person in question was the gnash lead developer Jan 13 20:42:25 kergoth: yeah, MACHINE_KERNEL_PR is teh suck. Jan 13 20:42:33 * chouimat wanders in Jan 13 20:42:41 hi chouimat Jan 13 20:42:47 hi Jan 13 20:43:09 would be nice if PR was left with its original meaning.. changes to the recipe and files from SRC_URI Jan 13 20:43:11 we were thinking that there are bugs in the gnash autotools script triggered by oe in the 0.8.6 version Jan 13 20:43:11 getting a tad overloaded Jan 13 20:43:37 yeah, indeed Jan 13 20:43:51 there's also DISTRO_PR but that isn't quite so offensive Jan 13 20:44:18 that doesn't actually mess with PR though right, just gets used in the packaging? Jan 13 20:44:27 right Jan 13 20:44:37 hoi pb Jan 13 20:44:59 DISTRO_PR is factored into ${PKGR}, which I think is a much more wholesome way of doing things Jan 13 20:45:51 anybody know where opensuse store their patches in an accessible location? Jan 13 20:46:04 something like patch-tracker.debian.org Jan 13 20:46:31 apropos MACHINE_KERNEL_PR, there was a long thread about this on the mailing list at the time. you can google for something like "recipes with broken PRs now" and it should turn up. Jan 13 20:46:55 * Laibsch just added information for all those patch-stealers out there to http://wiki.openembedded.net/index.php/Push_patches_upstream Jan 13 20:47:05 just so that I can find them again ;-) Jan 13 20:48:06 My angstrom rootfs is complaining when I boot that it's readonly, so it has a few problems in /var/run, any way to mount root rw without a console? Jan 13 20:49:21 re mickeyl Jan 13 20:50:06 hi woglinde Jan 13 20:50:26 pb I ask my wife to come to brussel too Jan 13 20:50:32 but she didnt decide yet Jan 13 20:50:39 is cmake mirrored now? Jan 13 20:51:35 woglinde: very good Jan 13 20:52:36 pb are you going the whole week or just the weekend? Jan 13 20:52:37 kergoth: ah, here we go. my previous diatribe about M_K_PR is at http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-May/011378.html :-} Jan 13 20:52:46 woglinde: just the weekend: arriving friday evening, leaving sunday evening Jan 13 20:56:16 GNUtoo|oeee: yes Jan 13 20:56:18 try it Jan 13 20:56:29 temok Jan 13 20:56:30 ok Jan 13 20:56:36 s/temok/ Jan 13 20:59:15 pb_: regarding the earlier include question, http://tinderbox.openembedded.org/public/logs/task/4399722.txt is incorrect, though, isn't it? That problem is because the build system is looking at host includes, right? Jan 13 20:59:27 Just so that I'm not marching off into the wrong direction Jan 13 20:59:31 thanks a lot Jan 13 20:59:47 pb__: ah. right. i think that would have been a good situation to have had the TSC to resolve that, since clearly there was opposition when it still went in.. Jan 13 21:02:15 khem, or it fails with the same error when I bitbake glibc-initial or it say that there is no do_stage when I do -c stage Jan 13 21:02:54 I'll check how populate staging is called Jan 13 21:03:31 indeed it was do_stage Jan 13 21:03:37 mmm Jan 13 21:04:25 Is there a more efficent way to do tar -C a -c . | tar -C b -x Jan 13 21:04:26 ? Jan 13 21:04:50 cpio? Jan 13 21:04:52 (ie you want to copy the contents of a/ into b/ and there's overlapping dirs) Jan 13 21:07:09 still piping from one cpio to another? Jan 13 21:07:48 ah, hm Jan 13 21:11:50 I should check if it deletes the staging dirs Jan 13 21:15:33 hi djwillis Jan 13 21:16:20 kergoth: right, indeed Jan 13 21:17:00 Laibsch: yes, that -I/usr/include does look wrong. Jan 13 21:17:26 Laibsch: traditionally, ${includedir} is just the directory that the app will install its own headers into; it doesn't (in general) form part of the CFLAGS. Jan 13 21:17:36 but, perhaps that isn't the case here. Jan 13 21:19:19 Tartarus: cp -u ? Jan 13 21:19:33 vimdif amuses me Jan 13 21:22:05 khem, new to me, thanks Jan 13 21:25:22 Tartarus: this is GNU cp option though it wont be available on macosx or bsd Jan 13 21:25:34 but we build coreutils-native there too Jan 13 21:31:00 that wud be ok then Jan 13 21:31:39 I was wondering how much build time saving can we get if we used dash instead of bash Jan 13 21:32:00 I heard that kernel build is much faster on dash Jan 13 21:32:45 I guess the packages which have makefiles doing shell expansions will be happy Jan 13 21:33:08 there was a patch in bugzilla someone posted to use dash for building OE Jan 13 21:33:45 khem: really? Jan 13 21:33:51 I can't find that Jan 13 21:34:02 only a couple of reports that builds fail if sh is dash Jan 13 21:34:35 03Rolf Leggewie  07org.openembedded.dev * rd9dab81515 10openembedded.git/recipes/giac/giac_0.5.0.bb: giac: move to nonworking and close #98 as LATER Jan 13 21:34:41 someone should sit down and compare the build output of a pair of tmp dirs, one with /bin/sh as dash, one with /bin/sh as bash Jan 13 21:34:48 @all: are you guys getting frequent "fatal: The remote end hung up unexpectedly" errors when doing git pull as well? Jan 13 21:34:53 "someone" Jan 13 21:34:56 I wonder if there is some issue serverside Jan 13 21:37:36 Laibsch: sometimes, yes Jan 13 21:38:14 I HATE WORLD BUILDS Jan 13 21:40:02 kergoth: can you actually do them? Jan 13 21:41:03 Last time I tried, bitbake still hadn't even started the runqueue after two days of going full blast on a fast computer. Jan 13 21:41:17 haha Jan 13 21:41:18 wow Jan 13 21:41:20 Laibsch: yes.. quite frequent Jan 13 21:41:25 i haven't tried one on a full OE repository in a while Jan 13 21:41:29 the last one i tried did start Jan 13 21:41:34 it got about half way through after 72 hours Jan 13 21:41:51 JaMa: but that is not against .dev, or is ti? Jan 13 21:41:52 it Jan 13 21:42:20 i did a dev one months ago, but it was a -k with a bunch of hokey recipes masked out Jan 13 21:42:34 well, as i say, broke out after 50% or so Jan 13 21:42:36 ran out of disk :P Jan 13 21:43:31 Laibsch: I was referring to "hung up" Jan 13 21:43:49 Laibsch: http://bugs.openembedded.org/show_bug.cgi?id=4387 Jan 13 21:44:12 JaMa: OK. What did you do with the build, then? Jan 13 21:45:05 khem: that's just one the tickets removing bashisms Jan 13 21:45:19 Laibsch: with build? .. I just repeat git pulls until successful one.. Jan 13 21:45:45 khem: I guess I misunderstood you. I'm aware there are bashisms in OE and patches in the tracker to fix individual recipes. Jan 13 21:46:06 khem, so I'll have t rebuiild from scratch again? Jan 13 21:46:15 Laibsch: yeah I did not mean a single patch Jan 13 21:46:16 JaMa: so, basically what you want to do is "bitbake -c fetchall world", right? Jan 13 21:47:10 khem: My misunderstanding was that I thought you meant there was a patch in the tracker that would make OE use dash internally (assuming it would be provided by something like dash-native) Jan 13 21:47:14 so many of us here use ubuntu/debian we could put a bit of effort to use the default shell :) Jan 13 21:47:27 khem: bash is my default shell ;-) Jan 13 21:47:45 MVL6 customers keep opening bugs about the /bin/sh as dash error, even though the error tells them exactly what the problem is and how to fix it Jan 13 21:47:45 after dash bit me very bad when it was introduced VERY prematurely Jan 13 21:47:46 I mean the one you get with pristine installation Jan 13 21:47:47 it makes me sad Jan 13 21:48:14 kergoth: looks like bashisms are here to stay for a while Jan 13 21:48:27 Laibsch: sorry I probably misunderstood you.. I'm getting those mostly when pulling from OE git server (ie before push/rebase) Jan 13 21:48:37 aye, sadly Jan 13 21:48:45 someone profiled linux kernel and about 40% of time it was doing was shell stuff Jan 13 21:48:49 OT: goddamnit, chrome needs to stop sucking up cpu and bloating the way firefox does Jan 13 21:48:52 rest 60% was compiling Jan 13 21:49:36 JaMa: now I see. I thought you were talking about "bitbake world" when you were just referring to the git pull errors. I asked in #git but so far nobody had anything to say about it. Jan 13 21:50:18 as I understand it, the dash problem is not oe, but stuff we get from others Jan 13 21:50:25 jsut to flog a dead horse Jan 13 21:50:42 poor horse Jan 13 21:50:51 heh Jan 13 21:51:36 Crofton|work: understood may be we could switch shells dynamically Jan 13 21:52:00 so we can then separate the recipes that need bashism out Jan 13 21:52:29 but is that really worth it? Jan 13 21:52:38 just another layer of stuff to go wrong? Jan 13 21:53:09 read the thread on the gumstix list where someone was complaining about build time Jan 13 21:53:35 some guy replied with the details on build ing a machine for $750 that could build console-image in a few hours Jan 13 21:54:02 I'm sure there are a lot more areas of the build we could focus on that would gain more than bash/dash Jan 13 21:54:06 at the end of the day, you can through a little money at the build time issue Jan 13 21:54:11 yeah Jan 13 21:54:18 profile first, optmize second ;) Jan 13 21:54:50 this analysis was from someone getting paid by the hour, so reducing the time meant he could have lower quotes for work Jan 13 21:55:12 bahaaha poor alix board Jan 13 21:55:25 but now it is booting via pxe Jan 13 21:57:33 premature optimization is the root of all evil Jan 13 21:57:58 even bad teeth? Jan 13 21:58:00 ;-) Jan 13 22:00:02 03Stanislav Brabec  07org.openembedded.dev * r667b7cb389 10openembedded.git/recipes/gtk+/pixops-test.bb: pixops-test: GNU_HASH QA error fix. Jan 13 22:09:07 profling part is probably done enough by others that can be scaled here too but I agree its not a low hanging fruit Jan 13 22:10:47 kergoth: Was the TSC summary ok? Jan 13 22:10:50 Crofton|work: someone reported 10% speedup in boottime with sysvinit Jan 13 22:11:14 and there are many other examples available on web Jan 13 22:11:31 so no help for compiler...I'll try another machine then Jan 13 22:11:35 upstart upstart Jan 13 22:11:39 sreadahead Jan 13 22:12:05 Build time is not optimised - there is massive low hanging fruit Jan 13 22:12:23 * RP keeps trying to fix them Jan 13 22:12:43 hi RP Jan 13 22:12:52 * khem finds support Jan 13 22:13:31 * RP wouldn't expect bash/dash to be a problem, more the shear amount of forks we make Jan 13 22:13:49 use dash as non interactive shell and bash as interactive seems a good balance :) Jan 13 22:13:58 I'd like to find a better way to manage our autoreconf executions, only do so when we really need to Jan 13 22:14:12 RP: autoconf spins shell for every little test Jan 13 22:14:21 kergoth: I like it that we actually do it Jan 13 22:14:23 also would be nice to somehow leverage autoconf caching more, ./configure re-runs the same shit build after build Jan 13 22:14:36 khem: right, that is a good example of something that'd be nice to fix Jan 13 22:14:45 kergoth: yes, that'd be nice Jan 13 22:16:12 kergoth: caching autoconf results and updating them if something changes how would be do it ? or do you suggest to cache something and then make updates manually Jan 13 22:16:17 RP: another possibility would be to avoid generation of libtool scripts in builds in general, and point to a staging libtool Jan 13 22:16:34 khem: you can't cache everything across all builds,I've tried, the shit hits the fan, there's stuff you don't want to cache :) Jan 13 22:16:58 kergoth: Even if the cache is recipe specific? Jan 13 22:17:05 khem: but thats the kind of thing i was thinking.. though in general a way to store/access prior build information in subsequent builds, even with a fresh tmp, would be nice Jan 13 22:17:14 true, that would probably work Jan 13 22:17:20 incremental builds Jan 13 22:17:20 kergoth: libtool is an interesting one. Now about that LIBTOOL renaming patch :) Jan 13 22:17:31 * RP agrees using one in staging would be a nice twist Jan 13 22:17:56 RP: speaking of which, did you know that firmware Linux resets the PATH to point to a dir of symlinks to only the binaries on the build machine it knows it can rely on? Jan 13 22:18:09 we should think about something like that Jan 13 22:18:13 would make things a bit more deterministic Jan 13 22:18:30 yes true Jan 13 22:18:44 kergoth: Yes. I actually have some plans on that which are even nicer but we'll see... Jan 13 22:18:56 heh Jan 13 22:19:09 We should always refer to staging area and create symlinks for things we pull from build machine Jan 13 22:19:11 kergoth: Was the TSC summary ok? Jan 13 22:19:13 * kergoth watches the list of random oe "would be nice" things grow Jan 13 22:19:20 seemed okay to me Jan 13 22:19:22 configure generates a lot of variables that would be useful to go into a site like file Jan 13 22:19:28 kergoth: ok, I was waiting on you ack ;-) Jan 13 22:19:35 * RP will publish Jan 13 22:19:44 ah, right Jan 13 22:19:45 ones that don't change unless you move to a different host Jan 13 22:19:48 or target Jan 13 22:19:48 sadly I'm a bit behind on email Jan 13 22:19:53 so much for inbox zero Jan 13 22:20:03 grg: indeed Jan 13 22:20:08 * RP never catches up these days :( Jan 13 22:22:33 grg: Thats what we're thinking basically Jan 13 22:23:07 ah. cool Jan 13 22:23:46 RP: the architectural issue that's been brought up a few times, about areas of responsibility for recipe and distro and what should go where.. do you think that should come up directly in the tsc as a question of project architectural direction, or mailing list discussion of the possibilities first? Jan 13 22:23:55 it's rather fuzzy at the moment Jan 13 22:25:51 kergoth: I'd like to see the mailing list discuss the options Jan 13 22:26:17 kergoth: So we play out a couple of scenarios and if there is no clear winner the tsc rules Jan 13 22:26:28 s/couple/several/ Jan 13 22:26:46 kergoth: If there are threads like that I could use some way to spot them mind... Jan 13 22:27:28 i don't think this one has hit the list yet, just random musings on irc Jan 13 22:27:42 i'll throw something out if nobody else does, maybe this weekend Jan 13 22:28:00 kergoth: sounds good Jan 13 22:30:19 jo ant Jan 13 22:30:35 hey woglinde Jan 13 23:02:14 Laibsch: opie-image compiled for minimal (thx woglinde) Jan 13 23:02:36 yes, but it really only masked out the problem Jan 13 23:02:51 mickeyl: Interesting time to wake up LOL Jan 13 23:02:59 hehe Jan 13 23:03:02 ant__: we still should talk to bluelightning about it Jan 13 23:03:42 Laibsch: ask mickey about SPLASH in minimal Jan 13 23:03:50 mickeyl: ^^ Jan 13 23:04:06 well, this is not a question specific to minimal Jan 13 23:04:16 not all distro setting SPLASH (just 3) Jan 13 23:04:25 and minimal tries to be as generic (kind of its old name) as possible Jan 13 23:04:39 ok, then we should add it to the images Jan 13 23:05:25 ant__: I have come to the conclusion that the best approach is to set SPLASH = "" globally (not sure where, though) and have distros responsible for deviating if they want Jan 13 23:05:29 btw, most images seems originated from Angstrom work, reading first line Jan 13 23:05:33 no, not the images Jan 13 23:05:50 boah 5 hours Jan 13 23:05:56 the images are not the right place to define this Jan 13 23:05:56 to get this alix board work Jan 13 23:06:29 Laibsch: som eimages are using it in IMAGE_INSTALL, these need the setting. Other images absolutely ignore the thing Jan 13 23:06:43 ant__: I know the situation is currently broken Jan 13 23:06:50 breakage is nothing new to OE ;-) Jan 13 23:07:14 though lately things are not too bad ;) Jan 13 23:07:40 woglinde: the workaround for opie-taskbar do you have the build lying around Jan 13 23:08:20 khem: if you need I have somewhere the glibc-version workdir Jan 13 23:09:10 ant__: build for opie-taskbar ? Jan 13 23:09:16 yes Jan 13 23:09:23 failing one ? Jan 13 23:09:24 cool Jan 13 23:09:26 no Jan 13 23:09:41 never failed before Jan 13 23:09:41 the one whihc builds fine ? Jan 13 23:09:51 interesting Jan 13 23:10:00 its pushed Jan 13 23:10:02 what binutils version are toy using Jan 13 23:10:04 yesterday Jan 13 23:10:08 woglinde: saw that Jan 13 23:10:15 I think it's eglibc specific issue Jan 13 23:10:22 but I wanted to understand the underlying problem Jan 13 23:10:31 how is it wrt uclibc? errors out? Jan 13 23:10:40 ant__: havent tried yet Jan 13 23:10:56 opie-image could be a big ask for uclibc dont know Jan 13 23:11:09 long ago I built opie / uclibc for armv5te, no errors :) Jan 13 23:11:34 I am building native-sdk-image and its going well for me Jan 13 23:11:39 but it takes half a day Jan 13 23:13:41 * khem runs to meeting Jan 13 23:14:30 khem gogo Jan 13 23:14:41 nope Jan 13 23:14:53 I have opie running with eabi armv4 and uclibc Jan 13 23:14:58 its no bit tasj Jan 13 23:14:58 woglinde: did you build opie-taskbar against uclibc too? Jan 13 23:15:02 args big task Jan 13 23:15:04 sure Jan 13 23:15:09 simpad Jan 13 23:15:13 ok, them is eglibc issue Jan 13 23:15:17 *then Jan 13 23:15:36 hm? Jan 13 23:16:04 glibc built fine, uclibc too. opie-taskbar was only failing in minimal/eglibc Jan 13 23:16:16 if I'm not wrong... Jan 13 23:16:22 some logs? Jan 13 23:16:37 yes, tinderbox for my builds Jan 13 23:17:16 I'll rebuild opie angstrom/uclibc tonight Jan 13 23:18:30 woglinde: [23:31] < woglinde> hm did I say that I have run my simpad running with 2.6.32 uclibc-eabi-linxuthreads and opie? Jan 13 23:19:16 woglinde: can you show me your config files? Jan 13 23:19:29 woglinde: local.conf and oe modifications if any Jan 13 23:20:46 woglinde: I'd like to try this for a jornada7xx with elibc Jan 13 23:22:36 s/elibc/eglibc/ Jan 13 23:25:40 Laibsch: http://fr.pastebin.ca/1750339 suggests just x11-image and x11-jvm-image need to set SPLASH atm Jan 13 23:28:47 I would add it here temporarly, awaiting a deep rework (see the psplash-angstrom) Jan 13 23:29:47 woglinde: I get this: Jan 13 23:29:49 /home/filip.zyzniewski/pda/oe/build_dir/tmp/work/armv4-linux/eglibc-2.11-r8.1/build-arm-linux/libc_pic.os: In function `scalb Jan 13 23:29:53 n': Jan 13 23:29:55 unwind-pe.c:(.text+0x12c24): undefined reference to `__muldf3' Jan 13 23:29:58 unwind-pe.c:(.text+0x12d0c): undefined reference to `__muldf3' Jan 13 23:30:04 and much more of the same kind Jan 13 23:32:16 ant__: rfc sent to list Jan 13 23:32:24 although it's still a bit half-baked Jan 13 23:32:52 I'd remove all the psplash-angstrom you see Jan 13 23:33:23 it's defined in Angstrom-2008.1.conf Jan 13 23:37:03 Laibsch: remember we have PREFERRED_PROVIDER_virtual/psplash Jan 13 23:37:33 if we fix things fix them properly Jan 13 23:38:00 Laibsch: I replied Jan 13 23:38:11 RP: thanks Jan 13 23:38:15 * Laibsch goes to read Jan 13 23:38:20 as I told you, a router doesn't care for splash :) Jan 13 23:38:55 Laibsch: Specifically I asked where its used Jan 13 23:39:25 ant__: I know which is why I think "" may be the sane thing Jan 13 23:39:34 deviating from my initial POV Jan 13 23:39:43 RP: two greps: conf and images Jan 13 23:39:45 RP: the mail hasn't arrived yet Jan 13 23:41:04 Laibsch: I asked where it was used (not doing the grep myself as I think its useful to discuss on the list and make people think a bit - not just you either) Jan 13 23:41:50 the place it is really used is in images, obviously Jan 13 23:41:57 some images hardcode values Jan 13 23:42:04 some distros set a preference Jan 13 23:42:19 overall, the outcome can be unsatisfactory IMHO Jan 13 23:43:20 and it could be improved setting a default and having distros change that to their liking (thinking mainly distros here as they may want to display their logo, but could be changed on an individual basis, too) Jan 13 23:43:32 the main point that currently there is no default Jan 13 23:43:41 main point is ... Jan 13 23:43:53 RP: does that answer the question? Jan 13 23:44:46 RP: some distros = angstrom, kaeilos, jlime Jan 13 23:44:55 yes Jan 13 23:45:01 thanks for adding that ant__ Jan 13 23:45:33 np, the lure worked..you fished RP :D Jan 13 23:45:45 no shit, I was dumbfounded ;-) Jan 13 23:46:12 Having seen rather little RP activity lately out in the open Jan 13 23:46:33 Sometimes one is lucky Jan 13 23:47:07 My POV is that it would be preferable to actually have a default rather than assuming the distro deals with it (which is currently not the case for the minimal distro) Jan 13 23:48:19 turn that around and have things work even for distros that have forgotten or otherwise not bothered with splash. Jan 13 23:50:47 actual state is that some images would use psplash-angstrom if distro doesn't define Jan 13 23:51:05 yes, good point Jan 13 23:51:09 thanks for adding Jan 13 23:51:45 I think it's just an oversight. Now the setting is in the distro.conf and image can be purged Jan 13 23:51:51 I like PB's reply. ant__, what happens when ${SPLASH} is part of an image recipe definition and the variable is empty? Things blow up, right? Jan 13 23:52:54 Laibsch: If its used my mutliple images, perhaps a default in image,bbclass would work? Jan 13 23:53:09 RP: yes, good point Jan 13 23:53:13 I'll try that out Jan 13 23:53:23 sure Jan 13 23:53:25 I was wondering where to define a default (if we decided to do that) Jan 13 23:53:36 and indeed, I was uneasy about bitbake.conf as well Jan 13 23:53:43 RP: but the preference in DISTRO? Jan 13 23:53:45 but that was the only place I could come up with so far Jan 13 23:54:37 ant__: default with ?= in image.bbclass (to be overridable) Jan 13 23:54:46 that sounds like a good idea to me Jan 13 23:55:27 I'm unsure distro prefs are kept. I have to think more about it Jan 13 23:55:45 images include image.bbclass Jan 13 23:55:45 yes Jan 13 23:56:14 ant__: the distro can override in its config file Jan 13 23:56:40 As for little activity from me recently, there is plenty around, perhaps just not high profile :/ Jan 13 23:56:42 I guess ant was worried that image.bbclass may have higher priority Jan 13 23:56:49 ok, no need for a loca in-recipe override Jan 13 23:57:00 If image.bbclass has ?= it would be suitably weak Jan 13 23:57:21 RP: yes, that is what I figured. Most of the mass of an iceberg is below water line, right? ;-) Jan 13 23:57:24 yes, at that point we have already parsed distro.conf, sure Jan 13 23:57:41 I had a momentary black-out ;) Jan 13 23:57:54 If both image.bbclass and distro.conf set SPLASH with ?= who wins? Jan 13 23:58:10 ant__: not at all, these are important points to consider Jan 13 23:58:19 Laibsch: config files are parsed before the classes, so the latter Jan 13 23:58:56 nice Jan 13 23:59:03 Laibsch: distro Jan 13 23:59:10 OK Jan 13 23:59:32 The point I wanted to make in the email is to think about contexts for this stuff Jan 13 23:59:35 I shall cook up a patch for discussion, then Jan 13 23:59:46 I can actually do that now with some confidence Jan 13 23:59:52 Laibsch: patches are worth 1000 words or something :) Jan 13 23:59:59 RP: all is born when OM guys had a nifty-eye-candy illume splash Jan 14 00:00:05 months ago Jan 14 00:00:12 Before this fruitful discussion I would have patched bitbake.conf and something told me that wasn't right Jan 14 00:00:17 iirc a provider was created for the purpose Jan 14 00:00:26 Usually the idea is to reduce boot time so you don't need a spash screen Jan 14 00:00:38 RP: OK, rather than answer, I'll just send the patch ;-) Jan 14 00:00:59 thanks guys Jan 14 00:01:04 Laibsch: I replied to pb_ to keep the discussion in sync with here Jan 14 00:01:18 good Jan 14 00:04:39 * Laibsch wonders about recipes/images/beagleboard-demo-image.bb Jan 14 00:05:01 ant__: do you think that recipe is distro-specific enough that it should keep it's hard-code value? Jan 14 00:05:25 Maybe change it to SPLASH_angstrom Jan 14 00:05:30 yes, is koen work Jan 14 00:05:55 same for recipes/images/illume-image.bb Jan 14 00:06:01 well, that is not a reason Jan 14 00:06:26 the question is "should other distros be able to use the recipe or is it really an angstrom-specific recipe?" Jan 14 00:06:45 ah, sorry, now I get the question Jan 14 00:07:15 I can only guess it's very tied to angstrom Jan 14 00:07:25 what is psplash-zap? Jan 14 00:07:39 is to kill psplash in console-images Jan 14 00:07:51 otherwise closes at VT change Jan 14 00:07:56 would we even need that package going forward? Jan 14 00:08:03 OK Jan 14 00:08:07 something to consider later on Jan 14 00:08:09 yes, otherwise tyou don't reach console Jan 14 00:08:32 well, probably could be done with initscripts Jan 14 00:34:07 good nite **** ENDING LOGGING AT Thu Jan 14 02:59:57 2010