**** BEGIN LOGGING AT Fri Jun 24 02:59:57 2011 **** ENDING LOGGING AT Fri Jun 24 03:19:19 2011 **** BEGIN LOGGING AT Fri Jun 24 03:20:10 2011 Jun 24 03:50:21 Hi. newbie question, I have built cacao, jamvm and classpath and installed the ipks on the target, is there a way to test if it works? perhaps another package i can build and install? Jun 24 08:27:57 morning Jun 24 08:28:56 hi xora Jun 24 08:29:03 how is your wrist? Jun 24 08:30:34 woglinde: improving I think, but Ive not been doing grappling last two weeks Jun 24 08:35:57 morning all Jun 24 08:36:04 hi bluelightning Jun 24 08:36:11 hey woglinde Jun 24 08:37:12 hey Jun 24 08:37:37 hiya XorA hope you get better soon. Jun 24 08:38:03 ka6sox hush go to sleep Jun 24 08:38:13 heh.... Jun 24 08:38:33 okay till later Jun 24 08:38:38 ka6sox-away: being a little battered is a way of life for me :-D Jun 24 08:39:08 XorA, I know the feeling. Jun 24 08:39:41 slightly more battered today after training in a different style for last 2 days Jun 24 08:42:00 How to configure timezones under Linux? I have tzdata package, I set /etc/localtime and /etc/timezone Jun 24 08:42:08 But it looks like time is wrong Jun 24 08:42:41 ln -s /usr/share/timezones/Europe/London /etc/localtime Jun 24 08:42:49 if I remember rightly Jun 24 08:42:53 time() and localtime() returns UTC time, while SQlite3 strftime() returns it as it should be Jun 24 08:43:40 No, SQLite3 also returns wrong time but with the right timezone offset Jun 24 08:43:48 'date' shows time as it should be Jun 24 08:46:24 I messed up something Jun 24 09:08:09 Okay Jun 24 09:08:27 So date utility reports correct localtime and UTC time (date -u) Jun 24 09:08:50 UTC: 9 am, local: CEST, 11 am Jun 24 09:08:54 Code: Jun 24 09:08:56 GMT: Fri Jun 24 10:03:09 2011 Jun 24 09:09:04 Local: Fri Jun 24 10:03:09 2011 Jun 24 09:09:51 I used gmtime() and localtime() Jun 24 11:04:53 jo mickeyl Jun 24 11:25:38 03Mark Hatle  07master * ra5caaaaba8 10bitbake.git/lib/bb/ (build.py runqueue.py): (log message trimmed) Jun 24 11:25:38 runqueue.py: Add umask task control Jun 24 11:25:38 The umask for a task can now be set as: Jun 24 11:25:38 task[umask] = 022 Jun 24 11:25:38 task[umask] = '022' Jun 24 11:25:39 If specified as a text string, it must be octal. (This is due to Jun 24 11:25:39 recipe parsing where it's always set to a string.) Jun 24 11:33:31 hi wog Jun 24 11:33:32 linde Jun 24 11:49:44 hi mark hatle, windriver hiring near boston? Jun 24 11:50:03 looking for linux admin work Jun 24 11:50:16 * CcSsNET moves along to other channels. pm me if u like Jun 24 15:23:36 hmm Jun 24 15:33:01 umm this looks odd.. oe-core meta/recipes-kernel/linux-firmware/linux-firmware_git.bb the do_install installed 3 files at 0666 Jun 24 15:33:10 should htey REALLY be 0666 or 0644? Jun 24 15:33:25 * fray doesn't know what a "Libertas sd8686" is to be able to comment Jun 24 15:33:53 they should be 644 Jun 24 15:34:01 its only firmware Jun 24 15:34:08 I'll fix it and send up a bitch in a bit then Jun 24 15:35:05 PATCH yeesh Jun 24 15:35:14 * fray wonders what his fingers are thinking Jun 24 15:35:33 lol Jun 24 15:39:09 haha Jun 24 15:39:29 fray's a pimp on a side, it seems Jun 24 15:39:37 s/ a / the / Jun 24 15:39:46 no i was thinking about bitching about something on an internal mailing list.. ;) Jun 24 15:40:07 apparently my brain and fingers were coordinating about what I wasn't trying to type Jun 24 15:40:26 heh Jun 24 15:41:10 anyone know why kernel-headers does not include contents of STAGING_KERNEL_DIR required to build external modules? Jun 24 15:41:36 kernel-headers should -never- be used to build modules.. they only exist for userspace programs Jun 24 15:41:50 external modules should always use the kernel sources directly -- or the staging kernel dir Jun 24 15:42:16 (glibc and other things munge the userspace kernel headers for userspace usage, and the userspace headers do not have to match the running kernel -- while modules do) Jun 24 15:42:27 the staging kernel dir isn't packaged externally anywhere is it? Jun 24 15:42:40 I'm not sure.. Jun 24 15:42:42 and the kernel sources need to be 'prepared' somehow to build external modules (in a way I'm not clear of) Jun 24 15:43:03 hmmmm Jun 24 15:43:31 neither am I.... but I know how Fedora and others do it.. they export a development package that provides much of the kernel sources pre-configured for module usage Jun 24 15:43:38 is there any value to having kernel-headers package as well as linux-libc-headers? (I assume perhaps bc linux-libc-headers are typically dated) Jun 24 15:44:11 ya, I'm trying to understand how other distros do it - been digging through the src pkg for ubuntu, not that I can follow it easily Jun 24 15:44:19 AFAIK, kernel-headers is an input to what generates linux-libc-headers.. but I might be out of date on that Jun 24 15:44:53 Fedora exports the makefiles and specific referenced source and headers and places them into /lib/modules/kernel (I think thats it) Jun 24 15:45:08 then your modules can be set that the kernel sources are located there and they "magically" work.. Jun 24 15:45:37 In the past they did a lot of munging of files to save space..it's much easier to just provide the configured kernel source as a whole -- maybe remove the .o files Jun 24 15:48:07 I'm thinking the kernel-headers package should be replaced by one that includes all thats needed to build external modules - I'm not clear what value it adds otherwise compared to the linux-libc-headers-dev Jun 24 15:48:47 diff is that linux-libc-headers-dev has 'sanitized' headers (derived from make headers_install) and kernel-headers are 'un-sanitized' but still not clear why one would need both Jun 24 15:50:07 I think it's just so that the santized headers can be created... it's part of the sysroot bootstraping process Jun 24 15:50:55 if that were the case I wouldn't think they would be packaged Jun 24 15:51:12 (this all has to do with being able to build external modules via an SDK by the way) Jun 24 15:52:20 What I have see (elsewhere) is: kernel-headers (unsanitized by libc) are produced from a specific Linux kernel definition.. this doesn't track any board configuration.. this gets loaded as step one.. then the libc builds.. and these headers are munged and replaced by the sanitized version(s) Jun 24 15:52:52 for module support the configured kernel is split between the run-time binary and a copy of the entire configured source and placed in /lib/modules/kernel/- Jun 24 15:54:12 yes, thats true for the linux-libc-headers (LINUX_LIBC_HEADERS_VERSION) but for the machine's kernel recipe they are also packaged by OE as kernel-headers Jun 24 15:55:01 what you describe is what I see for typical distros yes, but not by OE built distros Jun 24 15:56:01 I'm up for creating a patch to address this, but I was thinking of 'replacing' kernel-headers package with one that could build external modules (for inclusion in a meta-toolchain) Jun 24 16:27:11 tharvey: if you need to do kernel development or kernel modules you need kernel (unsanitized headers) for user space you need sanitized headers i.e. linux-libc-headers in OE terms Jun 24 16:28:00 tharvey: so the SDKs we provide are more of Application Dev kits Jun 24 16:28:28 you need probably a Platform Dev Kit for writing device drivers or other kernel development Jun 24 16:30:57 khem: about this, it seems klibc can be built against linux-libc-headers(-dev) but I see little point changing the dependency on virtual/kernel in OE Jun 24 16:31:30 why not Jun 24 16:32:11 because I build an initramfs and I need a kernel where inject it Jun 24 16:32:41 "I" means typical klibc user I guess Jun 24 16:33:13 but yes, things are separated Jun 24 16:34:29 I dont think the dep belongs to klibc Jun 24 16:34:35 it belongs to image Jun 24 16:35:32 klibc-utils -> cpio (image) -> kernel Jun 24 16:36:04 that is ok but direct dep is not required I mean Jun 24 16:36:40 it seems so, reading debian posts Jun 24 16:37:45 ant_work: my attempt to install gentoo faired miserably Jun 24 16:37:58 kernel would boot but not find my ext4 rfs Jun 24 16:38:12 so I gave up after wasting 2 hrs Jun 24 16:38:35 ah, boot with another distro, chroot, reconfigure kernel,... Jun 24 16:39:28 ant_work: yeah but I am fine for now with xubuntu Jun 24 16:39:39 xubuntu is lighter than KDE or Gnome Jun 24 16:39:47 I needed something lighter Jun 24 16:40:38 awesome Jun 24 16:40:43 is light Jun 24 16:40:45 I can only say ubuntu could crash my PC, self-compiled Gentoo never... Jun 24 16:42:26 awesome is quite nice, stays the hell out of my way Jun 24 16:44:02 khem, would you have objection to me changing what kernel-headers package includes (currently these are simply unsanitized headers for the machine kernel and I'm not clear if anyone uses them) Jun 24 16:44:31 my change would be to include whats needed from machine kernel tree to make them appropriate for a platform sdk as you say Jun 24 16:45:03 actually, seems to make sense that I would not tweak 'kernel-headers_*.ipk' but to create a 'kernel-headers-$MACHINE_*.ipk' Jun 24 16:48:40 if I wanted to build opkg with curl/ssl support, what would be the best way to make a change to the EXTRA_OECONF that is in opkg.inc currently? (is there a nice way to do it with bbappend? ...without smashing the rest of what's in that var) Jun 24 16:49:04 bbl, bye Jun 24 16:52:39 hi effem Jun 24 16:52:51 hi woglinde, all Jun 24 16:52:56 only shortly here today Jun 24 17:08:06 I am having trouble with busybox compilation due lack of rpc.h Jun 24 17:08:28 anyone knows the way to fix it? Jun 24 17:08:46 otavio: yeah, update again, the glibc update was reverted Jun 24 17:09:00 Tartarus: I did Jun 24 17:09:15 Tartarus: my tree is current oe-core and it keeps failing Jun 24 17:09:17 Time for some heavy -c clean'ing perhaps then Jun 24 17:09:26 otavio check oe-core ml Jun 24 17:09:36 Tartarus: shouldn't I need to clean some? Jun 24 17:09:58 Tartarus: I'd say the fix and bumps ought to be commited Jun 24 17:10:28 otavio: Yeah, but I think you're in a bad state and need to either -c clean out some stuff or just start over from sstate cache Jun 24 17:11:16 Tartarus: removing tmp Jun 24 17:11:19 Tartarus: let's see Jun 24 17:52:51 Has someone got this? Jun 24 17:53:17 | make[2]: *** No rule to make target `/home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/lib/libosp.la', needed by `openjade'. Stop. Jun 24 17:53:38 openjade-native Jun 24 17:53:42 * fray hasn't seen that.. but I'm not building openjade Jun 24 17:54:28 fray: mind to try? Jun 24 17:55:36 where are you pulling it from? oe-dev, meta-oe, ? Jun 24 17:55:58 fray: oe-core Jun 24 17:57:01 actually I just checked I DID build it recently.. (late last night) Jun 24 17:57:15 * fray verifies it didn;t silently error Jun 24 17:57:38 ya it built to completion Jun 24 17:57:52 I'm on a Fedora 13 host (x86-64) Jun 24 17:58:24 fray: is it possible for you to cleansstate and built it again? Jun 24 17:58:30 fray: I fear gcc update has broken it Jun 24 17:58:44 I -do- have a libosp.la BTW Jun 24 17:59:00 when my current build is done I'll try rebuilding it.. Jun 24 17:59:07 (likely 10 minutes or so) Jun 24 18:05:38 (I REALLY hate rebuilding qt.. takes forever) Jun 24 18:15:14 speaking of hating rebuilding things, do we have a known-good external-toolchain-crosstool-ng floating around anywhere? Jun 24 18:15:19 seems like it'd be a common one to use Jun 24 18:15:21 ok.. trying to build openjade-native now Jun 24 18:16:02 otavio built -- no errors Jun 24 18:16:19 fray: confusing; are you using today's oe-core? Jun 24 18:16:35 ya.. plus a few (completely unrelated) patches not yet in oe-core Jun 24 18:16:50 (fixup_perms patch and a prelink uprev) Jun 24 18:17:06 I'm doing world builds tracking down bad permissions Jun 24 18:20:12 I am going to build from scratch (with clean sstate) to check Jun 24 18:26:53 I think I FINALLY have all of the modes right in the system.. only collisions remaining are package bugs AFAIK Jun 24 18:26:53 I'm trying to run the do_pack_write_ipk script in the temp directory, I see it is written in python and probably imported from somewhere. Is there a way for me to run this script from devshell? Jun 24 18:27:20 both sysvinit-sulogin and tinylogin profix "/sbin/sulogin".. one is a file and one is a symlink Jun 24 18:27:33 simialr issue w/ the matchbox-wm Jun 24 18:37:35 Yes; fully reproducable ... it fails to build here indeed Jun 24 18:37:43 openjade-native is not buildable Jun 24 18:44:01 hi, ncurses still fails to do_qa_configure telling it has hosts includes in oe-core Jun 24 18:45:19 | Rerun configure task after fixing this. The path was '/home/gnutoo/port4/embedded/oe-core/oetmps/shr/work/armv4t-oe-linux-gnueabi/ncurses-5.9-r0.1/ncurses-5.9/widec' Jun 24 18:45:29 * kergoth built angstrom from oe-core yesterday, testing distroless now Jun 24 18:45:47 if I cannot build even an image it's hard for me to switch Jun 24 18:45:49 kergoth: are you going to do a full build? Jun 24 18:45:58 I can wait tough Jun 24 18:45:59 where "full" means what? Jun 24 18:46:07 kergoth: please test today's tip and try openjade-native Jun 24 18:46:10 kergoth: it fails here Jun 24 18:46:21 kergoth: I cleaned up tmp and sstate cache Jun 24 18:46:28 k, kicking it off now Jun 24 18:46:54 this is ubuntu, not even sure what version, i think its 10.04 Jun 24 18:46:58 oe-core is quite unstable these days. Jun 24 18:47:24 well, the switch to gcc 4.6 caused some issues, not too surprising Jun 24 18:47:31 you can always opt into 4.5 or whatever and see if that helps Jun 24 18:47:39 otavio -- I'm finding it increasingly more stable (with a few hiccups) Jun 24 18:47:50 fray: not for me. Jun 24 18:48:03 the openjade-native failure though should have nothing to do with the gcc change.. Jun 24 18:48:12 since it uses the host system's tooling Jun 24 18:48:26 fray: the pulling process IMO is not being properly tested. And this is the opposite of what is suppose to happen Jun 24 18:48:41 fray: it is probably a missing depends somewhere Jun 24 18:48:44 fray: but dunno where Jun 24 18:48:58 are the other files in that directory there, just not the .la? Jun 24 18:49:08 i haven't had a failure in a while. a few weeks ago, now, i had failures pretty much every day :\ Jun 24 18:49:27 if only the .la is missing check that your libtool is functioning properly.. I had a failure building libtool.. but it went away and I haven't been able to reproduce it Jun 24 18:52:06 one of the quality issues is that the auto builders we've been relying on have had problems this week.... I believe things should be returning to normal though Jun 24 18:52:39 kergoth: same to me. Jun 24 18:52:51 do we run the things that will be pulled in the autobuilder before they get pulled, or is it only after-the-fact? Jun 24 18:53:06 kergoth typically they are run with the autobuilder (for the most part).. Jun 24 18:53:17 fray: we ought to have something as linux-next Jun 24 18:53:19 that hasn't really happened much this week due to the problem and other circumstances Jun 24 18:53:30 otavio that -is- master of oe-core Jun 24 18:53:42 fray: this way things gets tested before Jun 24 18:53:44 fray: no! Jun 24 18:53:45 we've not released an oe-core so there is no stable yet.. (but the intention is it's supposed to be more stable then not) Jun 24 18:53:52 fray: right, but *when* are they run with the autobuilder, before its pushed to master or after? :) Jun 24 18:54:01 kergoth both Jun 24 18:54:06 k Jun 24 18:54:21 fray: master is to have things tested. This is what people doing the consolated pull requests should test before sending those Jun 24 18:54:42 otavio yes.. and I know, for the most part, people have been testing extensively.. Jun 24 18:54:48 there have been lapses though Jun 24 18:55:06 (read the minutes of the TSC meeting when it comes out in a day or so.. we had a fairly extensive discussion on the topic) Jun 24 18:55:22 fray: so for example, the eglibc thing shouldn't have been merged with a missing rpc file and like Jun 24 18:55:30 yes.. we agree. Jun 24 18:55:32 even with the autobuilders its impossible to test everything due to differences in build machines, build ordering issues, etc.. only so much we can do Jun 24 18:55:34 fray: this broke all my build and I needed to start again :-( Jun 24 18:55:44 broke mine as well.. Jun 24 18:55:58 thank goodness for sstate Jun 24 18:55:59 heh Jun 24 18:56:07 kergoth: sure. But some mistakes that have happened lately are quite obvious due lacks of test Jun 24 18:56:08 even if it can be kind of brittle Jun 24 18:56:24 otavio: openjade-native built fine on my machine too Jun 24 18:56:29 kergoth: grr Jun 24 18:56:34 what I am missing? Jun 24 18:56:59 check if you have any of the other files in that dir.. if you do and only the .la is missing (there should be a coresponding libosp.a and libos.so) Jun 24 18:57:07 check libtool.. Jun 24 18:57:20 if the libosp.* are all missing then it's something deeper Jun 24 18:57:45 if I wanted to build opkg with curl/ssl support, what would be the best way to make a change to the EXTRA_OECONF that is in opkg.inc currently? (is there a nice way to do it with bbappend? ...without smashing the rest of what's in that var) Jun 24 18:57:56 03Simon Busch  07master * r121032a475 10openembedded.git/recipes/linux/linux-palmpre_git.bb: Jun 24 18:57:56 linux-palmpre: update to the latest version Jun 24 18:57:56 This will include a fix for the palmpre2 to get wireless network working. On the palmpre2 Jun 24 18:57:56 another gpio is used to reset the wifi chip as on the palmpre. Jun 24 18:57:56 Signed-off-by: Simon Busch Jun 24 18:58:15 do a .bbappend and do EXTRA_OECONF += ... Jun 24 18:58:29 later configure values should replace earlier ones (unless it's not gnu autoconf) Jun 24 18:58:53 ok so if I re-feed it --enable-curl that should work? great Jun 24 18:59:00 yes Jun 24 18:59:07 thanks Jun 24 18:59:12 wasn't sure if it was that easy Jun 24 18:59:13 heh Jun 24 19:00:10 (devel).% grep libosp.la * -R Jun 24 19:00:10 jade/Makefile.lt:LT_LIBS=../style/libostyle.la ../spgrove/libospgrove.la ../grove/libogrove.la /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/lib/libosp.la Jun 24 19:00:13 strange Jun 24 19:00:28 whats /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/l Jun 24 19:00:34 ib/libosp.* ? Jun 24 19:00:37 ugh bad paste Jun 24 19:00:42 I am able to reproduce it into devshell (thanks kergoth for the patches :P) Jun 24 19:00:44 point is.. are there oths? Jun 24 19:00:58 * fray 's typing is going away again.. must be Friday Jun 24 19:02:48 humm Jun 24 19:02:52 maybe I got a point here Jun 24 19:02:55 let me test Jun 24 19:08:08 HECK! got it Jun 24 19:08:23 pb_: are you there? Jun 24 19:09:35 fray: this was my fault. I have cooked a patch (that is waiting in my tree for testing) that removes the .la files after do_install hence it avoids a lot of .la files in -dev packages and like Jun 24 19:09:52 fray: however it seems openjade depends on .la file of other package Jun 24 19:10:01 fray: this seems wrong. Jun 24 19:10:09 pb_: ^ mind to comment on that? Jun 24 19:10:39 otavio thats the problem with libtool.. it get into everything and it's hard to remove Jun 24 19:10:46 some things actually require it to link due to other issues Jun 24 19:12:06 fray: IMO openjade ought to link against '-losp' without using the .la file Jun 24 19:16:58 otavio: .la files should DIAF on any machine with a decent linker, really.. Jun 24 19:17:12 well, there's one useful case, i guess, deps of static libs, but meh Jun 24 19:18:32 kergoth: yes; I got it partially done. Will try to hack openjade to see if I can drop this requirement later. Jun 24 20:10:15 hi, I can't login to patches.openembedded, it says my account is inactive. Any idea? Jun 24 20:48:43 khem: ping Jun 24 20:52:32 NOTE: package flex-native-2.5.35-r7.1: task do_configure: Failed Jun 24 20:52:36 anyone? Jun 24 20:52:42 http://paste.debian.net/120885/ Jun 24 20:53:37 you dont have the oe patch autoconf Jun 24 20:53:47 which has the option to exlucde autopoint Jun 24 20:54:33 ? I have fresh pull Jun 24 20:55:51 ant__: is that on oe-core Jun 24 20:56:03 no, still .dev Jun 24 20:57:13 you need gettext installed either on your build host Jun 24 20:57:18 or build gettext-native Jun 24 20:57:22 fwiw yesterday's build failed on NOTE: package gettext-native-0.18-r6: task do_configure: Failed Jun 24 20:57:31 if recipes exist in .dev for gettext-native Jun 24 20:58:00 ant__: thats precedent to this problem then Jun 24 20:58:19 pespin: recreate it Jun 24 20:58:30 now, gettext has not yet started do_configure Jun 24 20:58:32 pespin: whats your login Jun 24 20:58:42 ant__: gettext-native is what u need Jun 24 20:58:50 this one I mean Jun 24 20:59:24 its nicely fixed in oe-core Jun 24 20:59:37 its can of worms in .dev in inherit gettext Jun 24 20:59:52 khem, pespin Jun 24 21:00:04 it does not interact well with native class Jun 24 21:00:12 khem but now is totally broken Jun 24 21:05:12 pespin: retry Jun 24 21:05:33 ant__: yes not totally broken and not totally fixed somewhere in middle Jun 24 21:10:33 HEAD is now at e16a751 -> pretty sure here was ok Jun 24 21:10:39 testing Jun 24 21:11:10 eh.. need older bitbake Jun 24 21:13:11 khem, done thanks :) Jun 24 21:48:23 khem: fresh oe.dev doesn't cope with bitbake master. I went back to Jun 24 21:48:26 HEAD is now at ea0ca90 cooker.py: Drop duplicate parseCommandLine call Jun 24 21:49:05 gettext and flex are not yet configured but the build goes on Jun 24 21:49:16 (gettext-native and flex-native) Jun 24 21:50:08 trying to bisect (if it is worth...) **** ENDING LOGGING AT Sat Jun 25 02:59:57 2011