**** BEGIN LOGGING AT Fri Mar 27 02:59:57 2009 Mar 27 05:00:47 03mwester * r1089 10kernel/trunk/ (4 files in 2 dirs): Mar 27 05:00:47 kernel 2.6.29: Update for 2.6.29 official release -- Mar 27 05:00:47 updated defconfig, dropped PHY patch temporarily. Mar 27 05:01:17 mwester: have they broken upstream? Mar 27 05:19:18 Minor problem with the network driver was introduced; I think it will not manifest if booting from flash in the normal fashion (because redboot will reset the PHY for us). And apparently the ATAGS patch got dropped on the floor somewhere, because we need that still. Mar 27 05:20:14 Velocity patch is also needed, but there's something else wrong with the velocity (perf issues) that I need to track down so I've not worred about getting that patch upstream. Mar 27 05:30:20 03bzhou * r9814 10optware/trunk/ (3 files in 2 dirs): packages-cs08q1armel: added native gcc Mar 27 05:40:10 03bzhou * r9815 10optware/trunk/make/py-sqlalchemy.mk: py-sqlalchemy: 0.5.2 -> 0.5.3 Mar 27 05:50:06 03bzhou * r9816 10optware/trunk/make/mpg123.mk: mpg123: 1.6.4 -> 1.7.0 Mar 27 13:20:34 mwester-laptop: FYI, glib-2.0 is the one that pulls in python-native. Mar 27 13:26:40 Shame. Mar 27 13:27:41 Bitbake is written in python; you can't get to the point where it tries to build glib-2.0 without, obviously, having a reasonably-functional python on the host... so I don't know why it would have a dependency on python-native. Mar 27 13:27:59 It should work, as the root cause of the earlier problem is fixed. Mar 27 13:28:52 But still... one would think "ASSUME_PROVIDED += "python-native"" would avoid building that in the first place, and would probably work, and save a few minutes of build time. Oh well. Mar 27 14:04:04 I'm rebuilding the image. I'll try doing a clean to see if it works. Mar 27 14:16:43 Why are you doing a clean? I'm really confused now... Mar 27 14:16:47 What isnt' working? Mar 27 14:21:11 originally i was trying to see if the toolchain target was smart enough to pickup all libs available at build time. Mar 27 14:21:41 I discovered that It worked on a fresh tmp but not after cleaning. Isn't that the problem you observed or? Mar 27 14:22:21 But don't worry about it. I'm still building. It might be fine. Mar 27 14:23:27 slugosbe-image worked ok. I'm now trying my roboslut-image.bb which pulls in the extra stuff I need (gpsd,glib-2.0,libusb1,uvcvideo)... Mar 27 14:24:22 I'll then try the toolchain to see if it pulls in some of this stuff. If not I'll try the opkg-target method which showed some progress yesterday... Mar 27 14:24:59 If it works I'll make sure to document it. Mar 27 14:32:39 damn. My roboslug-image fails near the end with: Ran out of flash space in - 0x160000 bytes too large. Mar 27 14:33:04 It's obvious I'll have to install those manually after turnup to memstick. oh well. Mar 27 15:34:30 VoodooZ: if you're creating a totally custom image, you can try to edit the slugos image recipe and remove things you don't need: for instance I doubt you need the kernel modules for netconsole, the velocity, or even the raid driver. Mar 27 15:34:55 Although getting back 0x160000 will be tough... Mar 27 15:40:13 true. but that's ok as I need to use a memstick regardless. I want to stay as stock as possible as I wasted too much time trying to track oe changes in the past. Mar 27 15:41:00 the roboslug-image.bb was using the recommended OE trick of extending an existing image, in this case slugos-image.bb.. It just adds a list of extra packages to add. Mar 27 15:42:26 It's a shame there's no variable syntax that allows one to remove something; that would allow roboslug-image.bb to remove the stuff it doesn't need. :( Mar 27 16:19:03 yep. I thought about that. oh well. at least I finally got my robot build compiling after 1 year of not touching it. libusb1 will need some adapting but it's a step forward. Mar 27 16:19:20 btw, I did get the opkg-target trick to work! Mar 27 16:30:26 Ok, that's cool -- if opkg-target works, then I think it might actually be usable as a real SDK, not just a kernel-building toolchain! Mar 27 16:33:09 yep. and first the first time I was able to do it in a non-kludgy way using pkgconfig calls in my Makefile! Hurray! Mar 27 16:33:49 one just as to add the cross feed to the opkg.conf file of the SDK and add lib and -dev packages away. Mar 27 16:38:01 What is that entry to the opkg.conf file (i.e. can I add it during the toolchain build?) Mar 27 16:38:03 and this toolchain should produce EABI compliant bins right? when I do a file it only says: srx2: ELF 32-bit MSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped Mar 27 16:38:31 Yes, it is EABI. I think you need to dump the elf format to tell the difference. Mar 27 16:38:37 ah ok. Mar 27 16:39:10 I'm surprised my code works without change. even the colour thresholds were spot on. :) Mar 27 16:39:10 Oh, it's also linked with the GNU HASH option -- should make the dynamic linking much faster. Mar 27 16:39:14 :) Mar 27 16:39:17 good. Mar 27 16:39:31 now I have to figure out what's changed with libusb1... Mar 27 16:39:49 libusb became libusb1 with libusb-compat Mar 27 16:39:59 euh? Mar 27 16:40:04 not the opposite? Mar 27 16:40:22 Unless something was mucking about with private data structs in libusb, linking with libusb-compat should "just work" Mar 27 16:40:31 ah ok. Mar 27 16:40:55 There are some known failures, such as gnuradio Mar 27 16:40:58 I had to link to libusb-0.4_0.1.12 like 1 year ago to have it compile. Mar 27 16:41:06 the API has changed. Mar 27 16:41:20 but I'll try the compat way. sounds better. Mar 27 16:41:26 then I'll adapt my code. Mar 27 16:41:33 It's minimal anyways. Mar 27 16:42:33 unfortunately I don't see it in the feeds but that's ok. I'll build it. Mar 27 16:42:48 I shouldn't be relying on those feeds anyways. Mar 27 17:00:46 mwester: is it possible libusbpp doesn't get build for the feeds? (it's the package name for libusb-compat) Not a big deal as I'll hopefully migrate my code to pure libusb1. Mar 27 17:02:49 libusbpp is probably not built. Mar 27 17:02:58 let me check on that. Mar 27 17:03:46 er, s/not built/not packaged/ Mar 27 17:06:13 that's the weird thing though. the README in libuspp's work folder says libusb-0.1 and libuspp should never be installed at the same time.... Installing libusbpp on my slug pulls in libusb-0.1-4... not a big deal though. Mar 27 17:10:36 Ok, that's the conflict then. Mar 27 17:12:16 libusb-0.1 and libusb1-with-libusb-compat both will install different usb libraries in /lib, with the same name. Hence the warning. libusbpp does not get packaged because I explicitly suppress lubusb0.1 during the build. Mar 27 17:12:58 There is no way to link some libs against the old libusb0.1 and others against libusb1 on the same system; one of the two will fail. Mar 27 17:13:10 We chose to go with the newer libusb1. Mar 27 17:13:33 SlugOS 4.8-beta actually has an issue; the last one you install is the one you get, so it's rather non-deterministic. Mar 27 17:16:47 ok. going with libusb1 is the right choice, especially if it has a compat option. Mar 27 17:17:35 I initially installed the old one in both slug and toolchain 'cause I didn't know about the compat stuff so it should be ok next iteration. which I'll do soon. Mar 27 17:24:14 I appreciate the time and effort testing this stuff (and tripping over the rough edges); you're the first person who's tried the toolchain/SDK for other than a kernel compile. :) Mar 27 17:42:22 cool. I'm good at breaking stuff. Thanks for the help. Mar 27 17:43:19 do i need a password to update the wiki? Mar 27 18:03:16 password should be listed on the wiki home page; it's just to prevent wikispam Mar 27 18:03:20 try "nslu2" Mar 27 18:06:33 ah ok. I'll to find a good place for it... Mar 27 18:07:38 I guess i should put it under SlugOS.. Mar 27 18:18:07 Here it is: http://www.nslu2-linux.org/wiki/SlugOS/SettingUpToolchain Mar 27 18:18:46 mwester: I linked to it directly from the SlugOS page. Feel free to change anything.. **** ENDING LOGGING AT Sat Mar 28 02:59:57 2009