**** BEGIN LOGGING AT Sun Sep 16 02:59:57 2007 Sep 16 04:28:19 mwester: ping Sep 16 08:21:04 03koen 07org.oe.dev * r1673ab63... 10/ (18 files in 3 dirs): gtk: add 2.12.0 from poky Sep 16 08:21:10 03koen 07org.oe.dev * r600682b5... 10/ (8 files in 5 dirs): glib 2.0: add 2.12.13 and 2.14.0 from poky Sep 16 08:21:17 03koen 07org.oe.dev * r97e2b25c... 10/ (1 conf/distro/angstrom-2008.1.conf): angstrom 2008: use gtk+ 2.12.0 Sep 16 08:56:38 03koen 07org.oe.dev * r87cab650... 10/ (1 conf/distro/angstrom-2008.1.conf): angstrom 2008: use glib-2.0 2.14.0 Sep 16 10:00:06 03pH5 07org.oe.dev * r0d48495a... 10/ (3 files in 3 dirs): Sep 16 10:00:06 openmoko-icon-theme-standard2-qvga: icon theme for qvga devices Sep 16 10:00:06 * this recipe is a hack that rescales (from svgs or pngs) the stock Sep 16 10:00:06 icons in openmoko-icon-theme-standard2 to 22x22 and removes the Sep 16 10:00:06 bigger stock icons as well as the 128x128 icons. Sep 16 10:00:07 * needs convert and rsvg, their native recipes are still missing Sep 16 10:00:11 03pH5 07org.oe.dev * r28199245... 10/ (1 conf/machine/fic-gta01.conf conf/machine/fic-gta02.conf): fic-gta0[12]: add gps MACHINE_FEATURE Sep 16 10:00:15 03pH5 07org.oe.dev * rd22e4517... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko: only include the gps panel applet for devices that have gps Sep 16 10:00:19 03pH5 07org.oe.dev * r3f1b3c1c... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko: let magician use the qvga icon theme Sep 16 10:11:29 hi pH5 Sep 16 10:11:36 hi RP Sep 16 10:12:05 koen: do you have a pango >= 1.17.3 recipe already? Sep 16 10:12:27 not that I know off Sep 16 10:12:37 * koen is looking at NOTE: package gcc-cross-4.2.1-r4: task do_compile: started Sep 16 10:13:09 pH5: In answer to yesterday's questions, I don't know why it searched for the files 12 times. Changing build.py would have negative effects with the stamps problem and its the issue I was hinting at when I replied about the problem on the mailing list Sep 16 10:13:43 pH5: Poky has a 1.18.1 Sep 16 10:16:17 RP: cool, thanks. Sep 16 10:17:59 RP: I understand the stamp issue as it is now. I don't quite understand why stamp_is_current returns False if a dependency stamp is missing. Is that intentional, and if yes, why? Sep 16 10:22:39 pH5: If you bitbake foo which depends on tasks a, b and c and the stamp for a is missing, you want a to build? Sep 16 10:23:17 anyone know of the lowest power ARM embedded board capable of running X, wireless, and having an ethernet port and maybe 2 USB ports? Sep 16 10:23:20 RP: yes, but only if foo is not yet existing. Sep 16 10:23:40 if the foo stamp is there already, I don't need to rebuild a,b and c even if their stamps are missing? Sep 16 10:24:32 only if there are a,b,c stamps there that are newer than foo, I need to rebuild foo. Sep 16 10:24:56 pH5: Its the way its defined to work. if a was missing, it should rebuild a, then build foo again since a > foo Sep 16 10:26:14 pH5: Its designed such that if I delete a stamp, all tasks dependning on that task should rerun. This was how we got people to recover after the do_install changes for example Sep 16 10:26:21 essentially, as a hobbist project, I'm looking at building a small portable shell computer (although X and mpd capable), with a run-time of about 30 hours or so at 2w average off of batteries. Sep 16 10:27:13 I see. if that behaviour is by definition, there isn't much that can be done about this. Sep 16 10:27:16 xipietotec: wireless is not really compatible with "lowest power" Sep 16 10:27:39 pH5: Its a really tricky problem :/ Sep 16 10:27:40 Now I don't understand anymore how rm_work can possibly fit into this :) Sep 16 10:27:49 yes Sep 16 10:27:52 RP, if it can run wireless off a USB port thats fine. I'd lock the usb wireless at 1/2/5mb/s. Sep 16 10:28:54 pH5: rm_work started out as a quick hack for people low on disk space. It wasn't really designed to 100% fit the way OE/bitbake works :/ Sep 16 10:29:39 it would not be running wireless constantly or even the majority of the time anyways. It's just an option I'd want for it. The idea is to have a portable admin swiss army knife of sorts. Sep 16 10:31:07 xipietotec: There are a ton of arm boards out there, most of them can probably do what you want... Sep 16 10:33:48 pH5: It might be better to think about the idea differently. Perhaps rm_work should have an "incompatibility" flag with a value of "do_unpack do_patch do_configure" etc. If a task bitbake is running is in the list of "incompatibilites", it has to rerun the task? Sep 16 10:34:26 pH5: Obviously that is pretty nasty logic to add though :-( Sep 16 10:37:00 I'm a bit concerned about a future packaged staging where do_stage might depend on do_package_write when building from sources. But when fetching to be staged packages from a repo, all the source stamps will never be created. Sep 16 10:38:42 pH5: Yes, that is a tricky one. I think in the past it was thought that a successful fetch of the staging package would "fill in" the needed stamps Sep 16 10:39:02 far from ideal I admit Sep 16 10:39:10 RP: but that will break if somebody does -ccompile afterwards Sep 16 10:39:21 pH5: Yes Sep 16 10:39:37 pH5: Its the same problem as rm_work Sep 16 10:41:48 03koen 07org.oe.dev * r4068182b... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko: use qvga icon theme for qvga machines and make the ui task machine specific Sep 16 10:43:03 pH5: Are you still using bitbake trunk? Sep 16 10:43:10 RP: always Sep 16 10:43:23 pH5: Apart from the exit code issues, how are you finding it? Sep 16 10:46:12 RP: it seems to work very well, except in some cases where it leaves zombie threads around when bailing out. Sep 16 10:46:23 but I didn't have time to find out how to reproduce that. Sep 16 10:46:57 pH5: I've seen that too but have never managed to reproduce when I've had time to look at it :/ Sep 16 10:47:30 In case anyone is interested, I'm thinking about ways to make pkgconfig work better in OE btw. I have local patches to add a "sysroot" config option to it which might remove the need to hack the pkgconfig files in staging Sep 16 10:47:49 The drawback is we have to modify staging to look like the rootfs Sep 16 10:48:10 isn't that a good thing? Sep 16 10:48:37 pH5: Yes and no. Having a different layout is a good test of a build system Sep 16 10:49:11 I see. always that ambivalence. Sep 16 10:50:01 pH5: :) Sep 16 10:50:43 pH5: If this removes the need for the pkgconfig hacking, I would be tempted to propose changing the layout Sep 16 10:51:12 It would open the door to someone writing something similar for libtool too Sep 16 10:51:20 but that won't be me ;-) Sep 16 10:51:42 if we change the layout we can change the stamp logic as well :) Sep 16 10:51:58 koen: Totally separate issues Sep 16 10:52:03 I know :) Sep 16 10:52:23 it seems my jedi poweres don't work on RP :( Sep 16 10:53:12 koen: ;-) Sep 16 10:53:55 * koen heads out for a bike ride Sep 16 10:53:56 Seriously, I don't rule out adjusting the stamp logic, it just needs a lot of careful thought and careful consideration of the consequences Sep 16 10:53:57 later all Sep 16 10:54:10 koen: have fun Sep 16 11:00:24 03pH5 07org.oe.dev * r814e3aa9... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): libgsmd: remove -w parameter for universal Sep 16 11:00:28 03pH5 07org.oe.dev * r076fedc8... 10/ (4 files in 3 dirs): pango: add 1.18.1 from Poky Sep 16 11:04:33 good idea. Sep 16 11:04:44 * pH5 heads out, too Sep 16 11:04:54 RP: will you send a mail about the pkgconfig magic to the list? Sep 16 11:05:26 pH5: Once I've got a bit further with it and have something to show for it :) Sep 16 11:05:33 :) sure Sep 16 11:17:03 any ixp4xx hackers ? Sep 16 11:17:27 yes Sep 16 11:17:34 hi Sep 16 11:17:45 thx for your notes /email Sep 16 11:18:02 it seems a trial to make a few changes ! Sep 16 11:18:38 well now only the network needs to be corrected Sep 16 11:19:55 you mentioned that one npe bb file ver 2.3.2 Sep 16 11:20:24 that will take care of the ethernet driver ? and npe driver ? Sep 16 11:21:02 ixp4xx-npe is the package which contains the microcode which gets loaded into the Intel Network Processing Elements (NPEs) Sep 16 11:21:36 everything else (i.e. the mac and qmgr drivers) is built as kernel modules during the kernel build. Sep 16 11:21:40 yes i know the basics but keep fumbling the code Sep 16 11:22:43 do you have a kernel running with the mii, ixp4xx_qmgr and ixp4xx_mac kernel modules loaded? Sep 16 11:22:49 yes Sep 16 11:23:08 and what board code is being selected when the kernel boots? Sep 16 11:23:28 604 Sep 16 11:23:38 actually, the more basic question is: how do you intend to load the microcode into the NPEs? Sep 16 11:23:40 ixdpg425 is code 604 Sep 16 11:24:04 which kernel are you building? ixp4xx-kernel_2.6.21.6.bb ? Sep 16 11:24:07 well redboot already did it, however it seems that it gets loaded again by following the oot Sep 16 11:24:09 boot Sep 16 11:24:12 yes Sep 16 11:24:34 forget what redboot does, none of that is relevant for the kernel. Sep 16 11:24:40 i see the microcode.h file in several locatoins Sep 16 11:24:59 how are you going to load the microcode after the bootloader hands off to the kernel? Sep 16 11:25:35 what microcode.h file? the microcode is in an NPE-B or NPE-C file after the ixp4xx-npe-native and ixp4xx-npe packages are built. Sep 16 11:25:38 i saw some notes on several ways, as it is there is a scan which finds the microcode Sep 16 11:25:53 please be more specific Sep 16 11:26:45 i have traced the boot , the microcode is found in "RedBoot" and loaded Sep 16 11:27:18 i see , so i should used on of the METHODS to reload the microcode, such as putting it intdo a device file Sep 16 11:27:40 please pastebin the full boot log of the kernel so I can see it. Sep 16 11:27:42 i can paste the boot message to pastebin Sep 16 11:27:44 ~pastebin Sep 16 11:27:44 rumour has it, pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/, or http://pastebin.com is usually painfully too slow and unresponsive to use, use one of the other pastebin sites, or dpaste.com is a very nice pastebin as well Sep 16 11:27:50 snap Sep 16 11:27:51 right Sep 16 11:27:54 1 sec Sep 16 11:29:42 I'm interested to know how it found the microcode, cause there is no code in ixdp425-setup.c to search for microcode ... Sep 16 11:30:26 unless you have some other patches applied that you have forgotten to mention Sep 16 11:32:17 http://www.pastebin.ca/699443 Sep 16 11:32:52 i will also paste the coyote-setup.c Sep 16 11:37:02 pastebin.ca/699449 Sep 16 11:40:00 so the ixp425-eth bb files are depricated ? old not used , history ? Sep 16 11:40:48 i see now how bitbake stages a bb file in the staging dir Sep 16 11:40:51 they predate the open source driver Sep 16 11:41:26 so your bootlog shows the microcode being loaded from RedBoot as directed from coyote-setup.c - so what's the problem? Sep 16 11:41:42 ok so here is what happens Sep 16 11:42:19 i will paste it, 1 sec Sep 16 11:42:27 ga Sep 16 11:46:45 http://www.pastebin.ca/699459 Sep 16 11:47:16 so no change is needed to ixp4xx-npe-native_2.3.2.bb ? Sep 16 11:47:44 what you're seeing there has nothing to do with building. Sep 16 11:47:48 the zip files and md5 files are in the download.. yet it errors out when i run it as a single b Sep 16 11:48:04 well what now ? Sep 16 11:48:05 you've got some serious problems with your PHYs Sep 16 11:48:18 well, there are two possibilities (at least) Sep 16 11:48:23 oh well redboot had now problem Sep 16 11:48:38 1) the redboot microcode is not compatible with the open source drivers Sep 16 11:48:54 (in this case, try loading NPE-B and NPE-C from a different MTD partition. Sep 16 11:49:03 interfaith: check the PHY id's on your PHY's, this might be you got them switched in hardware. Sep 16 11:49:11 2) Your board is wired differently from what is set up in coyote-setup.c Sep 16 11:49:26 3) there's a hardware problem Sep 16 11:49:31 yes perhaps there is marvell chip on board Sep 16 11:49:40 for (2) and (3), I have no ability to help you Sep 16 11:49:52 interfaith: I have seen this error on our board when the PHY's both where at the same ID. Also, I can reproduce it on the Intel IXDP425 dev board when I swapped the ID's (using jumpers) Sep 16 11:49:55 (at least not with a board in front of me) Sep 16 11:50:06 s/with/without/ Sep 16 11:50:08 interfaith: I have seen this error on our board when the PHY's both where at the same ID. Also, I can reproduce it on the Intel IXDP425 dev board when I swapped the ID's (using jumpers) Sep 16 11:50:12 interfaith: check the PHY id's on your PHY's, this might be you got them switched in hardware. Sep 16 11:50:31 hmm so simply swap PHY id's Sep 16 11:50:49 yes sometimes redboot finds NPE-C Sep 16 11:51:16 interfaith: At least *check* them carefully. Might be you got them wired identically (and all kind of h/w race condition and weird states occur) Sep 16 11:52:15 interfaith: which board is that? custom? Sep 16 11:52:23 03mickeyl 07org.oe.dev * r2b94d08f... 10/ (8 files in 4 dirs): add openmoko-sound-system2 Sep 16 11:52:28 03mickeyl 07org.oe.dev * r023be36f... 10/ (1 conf/distro/include/sane-srcrevs.inc): sane-srcrevs.inc: bump openmoko-dialer2 and openmoko-sound-theme-standard2 Sep 16 11:52:29 yes it is based on the ixdpg425 Sep 16 11:52:38 then a marvel switch chip was added Sep 16 11:52:51 no pci Sep 16 11:52:55 no usb Sep 16 11:53:03 just the marvel switch chip Sep 16 11:53:25 you can see coyote-setup.c i pasted above Sep 16 11:55:01 ok, so let me understand the ixp4xx-npe_2.3.3.bb file takes care of the open source ethenet driver ? Sep 16 11:59:52 no, that file takes care of packaging the intel microcode Sep 16 12:00:30 fine, so when i have the zip and md5 files in the download dir then the bb file should work with no changes ? Sep 16 12:00:34 the open source ethernet driver is built as part of the ixp4xx kernel patches from svn.nslu2-linux.org, included automatically in the ixp4xx-linux_2.6.21.6.bb i OE Sep 16 12:01:20 i see, and it results in a ixp4xx_mac.ko module ? Sep 16 12:01:21 yep, and it does so at least for the slugos distro - last tested this morning in fact. Sep 16 12:01:51 the kernel build results in ixp4xx_qmgr and ixp4xx_mac kernel modules. Sep 16 12:02:19 and that code will fetch packets to/from the npe to the os ? Sep 16 12:02:34 yes Sep 16 12:02:49 after the microcode has been loaded into the NPEs Sep 16 12:03:19 buy an NSLU2, build slugosbe and try it for yourself ;-) Sep 16 12:03:32 theres an idea ! Sep 16 12:03:47 a linksys wifi device ? Sep 16 12:03:49 The same ethernet driver is part of Debian Etch Sep 16 12:04:17 (for the ixp4xx kernel flavour of the Debian Etch arm release) Sep 16 12:05:14 will newer microcode support appear anytime ? Sep 16 12:05:24 ver 3.0 or 2.4 ? Sep 16 12:07:50 the same driver works with 2.4 microcode, cause openwrt uses that driver and 2.4 microcode. Sep 16 12:08:05 I didn't know there was 3.0 microcode until today Sep 16 12:08:31 what's new in 3.0 which would cause us to change? Sep 16 12:08:39 and will openwrt build on oe now ? it seems easy to change openwrt Sep 16 12:08:57 openwrt has it's own build system, it does not use OE Sep 16 12:09:01 hmm 3.0 for the ixp435 i guess Sep 16 12:09:22 but openwrt is in the master makefile ? for your nslu2 system Sep 16 12:09:44 yes Sep 16 12:09:46 amazing so many open source build platforms emerging Sep 16 12:10:48 should most bb files build as a single bitbake ? Sep 16 12:11:13 all should Sep 16 12:11:38 which one doesn't? Sep 16 12:12:03 well the npe 2.3.2 fails for me Sep 16 12:12:15 i have the zip and md5 files in place Sep 16 12:12:17 well pastebin the full log of it then Sep 16 12:12:25 ok 1 sec Sep 16 12:12:35 help us to help you Sep 16 12:12:45 ha ha :) heaven Sep 16 12:17:51 http://pastebin.ca/699491 Sep 16 12:19:33 rwhitby will also paste my zip/md5 download listing Sep 16 12:20:06 where's the build of ixp4xx-npe-native ? Sep 16 12:20:25 since that is the package which creates staging/i686-linux/bin/IxNpeMicrocode-2.3.2 Sep 16 12:20:31 shall i bitbake it now ? Sep 16 12:21:10 i just did bitbake of ixp4xx-npe_2.3.2.bb Sep 16 12:21:42 bitbake ixp4xx-npe-2.3.2 Sep 16 12:21:57 not bitbake -b ixp4xx-npe_2.3.2.bb Sep 16 12:22:09 the oh ho..ug Sep 16 12:22:10 the first one builds dependencies, the second one does not Sep 16 12:22:18 hit me Sep 16 12:22:38 * like|away is not yet away :-) Sep 16 12:23:53 i get error no providers ? Sep 16 12:25:31 http://pastebin.ca/699497 Sep 16 12:25:31 bitbake ixp4xx-npe-native Sep 16 12:25:38 then bitbake ixp4xx-npe Sep 16 12:25:44 i see :) Sep 16 12:25:58 like|away: what are you smoking ;-) Sep 16 12:26:07 what's the difference between -native and void packages ? Sep 16 12:26:11 (in short) Sep 16 12:26:40 the story for ixp4xx-npe is that you need to build a binary first, and then you need to run that binary to create the output microcode file. Sep 16 12:27:03 so the one which builds a binary which runs on the build host is a -native, and the other one isn't (cause it's building stuff for the target system) Sep 16 12:27:10 03mickeyl 07org.oe.dev * r3372303f... 10/ (3 files in 2 dirs): task-openmoko[-feed]: add some packages, move some others around Sep 16 12:27:22 -native runs on x86 while void runs on the target machine Sep 16 12:27:23 03mickeyl 07org.oe.dev * r2240acf8... 10/ (3 files in 3 dirs): openmoko-session: remove libgtkstylus. We will handle right clicks differently Sep 16 12:27:23 ? Sep 16 12:27:43 if x86 is your build host architecture, yes. OE is not limited to x86 build hosts. Sep 16 12:27:53 still get "no providers" Sep 16 12:29:08 * rwhitby waits for the pastebin Sep 16 12:29:31 1 sec Sep 16 12:30:02 here's a tip: when I'm remotely debugging something with something, I believe *nothing* that they say - I only believe what I see with my own eyes in a pastebin. Sep 16 12:30:18 http://pastebin.ca/699504 Sep 16 12:30:30 ha ha right Sep 16 12:30:45 "bitbake ixp4xx-npe-native" is what I said. Sep 16 12:30:53 ok 1 sec Sep 16 12:30:59 but that's not the command you ran. why? Sep 16 12:32:36 http://pastebin.ca/699506 Sep 16 12:32:53 i will run the command, as you suggest Sep 16 12:33:05 seriously, do you think I have so much spare time to help you with this that you can't even be bothered running the commands that I say? Sep 16 12:33:14 ouch Sep 16 12:33:29 "bitbake ixp4xx-npe-native" is what I said. Sep 16 12:33:37 run that command (without the quotes) Sep 16 12:33:43 ok here goes Sep 16 12:35:33 i see so adding the full path made the trouble ? Sep 16 12:36:07 ok, here's the point where I point you to the OE and bitbake manuals, cause now you're really wasting my time. Sep 16 12:36:31 sorry,, it worked as you suggested Sep 16 12:36:43 * rwhitby goes back to debugging why dund doesn't work on the new dbus bluez-utils on gta01 Sep 16 12:37:06 now you should be able to "bitbake ixp4xx-npe" Sep 16 12:37:16 yes here goes Sep 16 12:37:21 then you will get a package emitted which includes the files NPE-B and NPE-C. Sep 16 12:37:43 concatenate them, put them in a spare MTD partition, put the name of that partition in coyote-setup.c instead of RedBoot, test. Sep 16 12:37:57 thx ! Sep 16 12:38:45 some light has appeared ! Sep 16 12:44:23 shall i add the NPE-B + NPE-C together ? Sep 16 12:46:37 concatenate them. cat NPE-B NPE-C > /dev/mtdblock Sep 16 12:46:47 got it Sep 16 12:47:29 can i upgrade to 2.4 now as well ? Sep 16 12:47:42 :) Sep 16 12:48:38 i hear a BEAR not a LION is the king Sep 16 12:51:11 RP: Hi, happen to be around? Sep 16 12:59:05 so the correct way to rebuild the kernel after a hack is "bitbake ixp4xx-kernel -c compile -f " ? Sep 16 13:03:13 thx rwhitby .. your the best 2 Sep 16 13:06:14 interfaith: thank me by sending me a board for free ;-) Sep 16 13:06:37 ok i will ask for one Sep 16 13:07:06 they do something called "HPNA" Sep 16 13:07:26 ip over cable tv cable Sep 16 13:07:31 03ospite 07org.oe.dev * r97c84a68... 10/ (1 files/device_table-ezx.txt): device-table-ezx: add uinput node (ezxd starts before udev and needs it for the power button) Sep 16 13:07:36 03koen 07org.oe.dev * rb67cb2f7... 10/ (7 files in 7 dirs): linux-ezx: enable uinput feature Sep 16 13:07:43 03koen 07org.oe.dev * r17b65e69... 10/ (1 packages/ezx/ezxd/ezxd.init): ezxd: remove --reverse from run-parts Sep 16 13:07:47 03koen 07org.oe.dev * ree7b95f6... 10/ (1 conf/distro/include/sane-srcrevs.inc): sane-srcrevs: bump ezxd to get the powerbutton working Sep 16 13:09:20 koen as rwhitby spelled out the exact path is not needed to rebuild a hacked kernel or any bb file Sep 16 13:10:05 interfaith: I would listen to koen's OE advice over mine any day of the week. Sep 16 13:10:21 ha ..he told me to type in the full path Sep 16 13:10:32 he has probably forgotten more about OE than I've learnt. Sep 16 13:10:38 ha ha ok Sep 16 13:11:55 i will try the build with all this new 'inteligence' Sep 16 13:20:25 http://www.pastebin.ca/699528 Sep 16 13:20:46 rwhitby: perhaps i need to rebuild the image now as well ? Sep 16 13:21:15 some unknowns come out when the modules are loaded Sep 16 13:21:27 did you change coyote-setup.c to look in the 'Npe' partition? (we call the partition 'microcode' in the other ixp4xx machines which do that) Sep 16 13:23:31 * rwhitby is concerned about upgrading bluez-utils from 3.9 to 3.15 on his BlueSlug, as dund for the Treo650 might not work afterwards ... Sep 16 13:24:42 yes, i will check the changes more clearly now Sep 16 13:25:41 mickeyl: I'm concerned about 2240acf86047820a29307f8c7417de1943260355 since it breaks tap-n-hold with no alternative Sep 16 13:27:59 koen: Hi, is it all ok with amv4t vs armv5te in-pace builds in OE? binutils/gcc for both overwrite each other in staging. Sep 16 13:28:39 psokolovsky_: it should be, since it's just a change in the gcc spec file and OE specifies all options explicitly Sep 16 13:29:08 I've seen no problems so far with my armv4/armv5/armv6 staging+cross Sep 16 13:29:52 koen: but it appears that it build the same(?)-config binutils/gcc and overwrites the old one. Is this just unavoidable evil or bug after all? Sep 16 13:30:22 it's a misfeature of the current OE Sep 16 13:30:38 * koen mentions 'packaged staging' Sep 16 13:30:54 ok Sep 16 13:31:22 koen: anyway, I found yet another case when setting MACHINE on env screws binutils build %) Sep 16 13:31:47 that's not 'another case; Sep 16 13:32:04 setting MACHINE in env *always* screws up binutils Sep 16 13:32:36 koen: ??? didn't we fix that multiple times? Sep 16 13:32:43 no Sep 16 13:32:58 yes, we did Sep 16 13:33:04 people *tried* to fix it multiple times Sep 16 13:33:46 after each fix my test cases still failed, so .... Sep 16 13:34:10 koen: some hero should come and fix this obscene trivial bug after all... Sep 16 13:34:16 morning Sep 16 13:43:02 03rwhitby 07org.oe.dev * r1a392ab8... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: added bootchart Sep 16 13:43:07 03koen 07org.oe.dev * r641f6b99... 10/ (1 conf/distro/angstrom-2008.1.conf): angstrom 2008: prefer pango 1.18.x Sep 16 13:44:03 mtn update has changed Sep 16 13:45:28 -r is needed now..? =? that long code of chars ? Sep 16 13:46:33 wait 10 minutes that the multiple heads will be resolved by the OE server Sep 16 13:46:45 yes Sep 16 13:47:19 angstrom-minimal has no modules ... bootstrap-image ..does have modules ? Sep 16 13:48:32 now angstrom-minimal builds .. but bootstrap-image fails one gconf-dbus_svn.bb Sep 16 13:49:24 good morning Sep 16 13:50:07 I've been comparing sizes of my OE build with my previous buildroot image Sep 16 13:50:56 I noticed that OE gnuplot pulls in libstdc++ whereas the buildroot gnuplot does not Sep 16 13:51:37 It's not immediately obvious (to me anyway:-) from the bb file why this might be Sep 16 13:52:22 Almost identical config options on both Sep 16 13:52:53 Any ideas or pointers? Sep 16 13:56:15 rhwitby: what minimal image should be used ? that will have the ixp4xx modules ? Sep 16 13:56:31 some changed needed to angstrom-minimal to pull in ixp4xx modules ? Sep 16 14:01:35 interfaith: I build slugos for ixp4xx only Sep 16 14:01:56 bitbake slugos-image ? Sep 16 14:02:08 --> no providers Sep 16 14:03:27 now bitbake bootstrap-image fails Sep 16 14:18:26 anyone know how the /etc/modules file is created when an image is built? Sep 16 14:21:56 sakoman: I fear you need a cross ldd and objdump to inspect gnuplot Sep 16 14:22:11 Crofton|home: postinst of kernel-module packages AFAIK Sep 16 14:22:36 and the happens in linux kernel build? Sep 16 14:22:49 no Sep 16 14:23:00 postints get run on package install time Sep 16 14:23:04 e.g. do_rootfs Sep 16 14:23:08 bitbake -c rebuild kernel-module? Sep 16 14:23:45 but the kernel-module package nees including in the image Sep 16 14:23:53 grrrr bbiab Sep 16 14:24:13 every kernel-module-foo package has a postints Sep 16 14:24:24 postinst* Sep 16 14:24:28 hmmm Sep 16 14:24:33 *lightbulb* Sep 16 14:24:42 module-init-tools could also provide it Sep 16 14:25:53 running update-modules on teh machine after flashing fixes the problem Sep 16 14:26:07 console image is ok, by minimal image does not create teh file Sep 16 14:26:41 http://www.toptechnews.com/story.xhtml?story_id=100009U0AQYG Sep 16 14:26:48 google re-invents the wheel Sep 16 14:27:38 I am trying to finsd the magic line from angstrom-console-image to get this to happen Sep 16 14:27:52 it should happen for minimal images imho Sep 16 14:28:02 as in make it happen in task-boot Sep 16 14:32:57 does the minimal image have any modules? Sep 16 14:33:19 yes, I can get the ethernet one installed on the image Sep 16 14:33:31 and modprobing it brings up the netwrok fine Sep 16 14:34:19 * koen ponders about -Wl,as-needed in OE Sep 16 14:38:29 * Crofton|home notes we only a few months to finish angstrom-2007 Sep 16 14:41:53 hmm, minimal may not install modules??? Sep 16 14:42:08 * Crofton|home goes insane Sep 16 14:42:45 if you don't have modules in MACHINE_ESSENTION_EXTRA_RRECOMMENDS minimal image won't have any modules Sep 16 14:42:59 ah, I have the autoload though Sep 16 14:43:00 ok Sep 16 14:43:32 I haven't used usb on the OSK in quite some time, so I did not notice it disappeared Sep 16 14:48:54 sakoman, maybe check the debian arm stuff to see if they know of any problems with gnuplot on arm? Sep 16 15:01:31 Crofton: thanks for the suggestion, I'll check Sep 16 15:02:26 gnuplot functions just fine, it's just 1.7x too big :-) Sep 16 15:03:45 ah Sep 16 15:03:57 surely there is a scale option Sep 16 15:04:52 I think steve means in size Sep 16 15:05:02 ah, is in bytes :) Sep 16 15:05:28 sakoman: you could try to link to libsupc++ till we figure out why c++ gets dragged in Sep 16 15:05:57 Yes, in bytes! Sep 16 15:06:46 koen: good suggestion, I'll give it a try Sep 16 15:07:52 * chouimat realised that he's 3 weeks late on his project estimates Sep 16 15:08:35 chouimat: the earlier you fail, the more time you have to repair it Sep 16 15:08:48 koen true ... Sep 16 15:09:12 man Sep 16 15:09:21 nfs is going a few kB/s.... Sep 16 15:09:25 koen: also -- I'm not sure why pango, cairo, and virtual/libx11 are DEPENDS. gnuplot will build just fine without them Sep 16 15:09:31 koen I lost about 2.5 weeks with some weird kernel crashes and freezes now it seems to be fixed Sep 16 15:09:46 sakoman: for the x11 and cairo terminal Sep 16 15:10:01 sakoman: should get packaged seperately Sep 16 15:10:06 sakoman, sometimes another package will build the dependencies for you Sep 16 15:10:10 they do Sep 16 15:11:01 * koen remember a php script he wrote to plot data with gnuplot because the ADI and 20-sim tools were not being helpfull Sep 16 15:11:20 ~lart visualdsp++ Sep 16 15:11:21 * ibot does a little 'dpkg -P visualdsp++' action Sep 16 15:11:28 Looking at the status file libstdc++ seems to be a direct dependency of gnuplot Sep 16 15:11:29 ~lart 20-sim Sep 16 15:11:29 * ibot tries to shut 20-sim up Sep 16 15:11:38 koen look like it's a nice tool :) Sep 16 15:11:47 Doesn't show up as a dependency anywhere else Sep 16 15:17:50 hi all Sep 16 15:25:45 03koen 07org.oe.dev * rb1874794... 10/ (1 packages/iso-codes packages/iso-codes/iso-codes_1.4.bb): iso-codes: add 1.4 Sep 16 15:25:49 03koen 07org.oe.dev * r0652add7... 10/ (1 packages/gnome/epiphany_2.19.6.bb): Sep 16 15:25:49 epiphany: add 2.19.6 with webkit as default backend Sep 16 15:25:49 * needs recent gtk and glib-2.0, so use DISTRO=angstrom-2008.1 Sep 16 15:27:13 hi koen - do you know anybody working with the freescale i.MX27? Sep 16 15:27:42 HopsNBarley: not that I know off Sep 16 15:27:46 also on a platform not - i got a set of 2.6.13 kernel patches for that marvel chip, so i'm taking a look at that port also. Sep 16 15:27:54 s/not/point Sep 16 15:27:55 HopsNBarley: lrg have mx21 and mx31 afak Sep 16 15:28:11 mx21 is very close to 27. thanks. Sep 16 15:28:51 several of these marvel based products showing up from iomega, hammer, qnap... Sep 16 15:29:05 seems nice: 400MHZ, gigE, sata... Sep 16 15:29:24 another question: OE libgd builds without freetype support (--without-freetype in the list of EXTRA_OECONF) Sep 16 15:29:35 is there an OE approved way to override this? Sep 16 15:30:14 koen - lrg is a person here? Sep 16 15:34:24 sakoman, not that I can think of Sep 16 15:34:53 Crofton: thanks Sep 16 15:35:15 do you know what impact that would have (addition of freetype support)? Sep 16 15:39:52 ~seen lrg Sep 16 15:39:54 lrg was last seen on IRC in channel #oe, 9d 5h 54m 21s ago, saying: 'hey koen'. Sep 16 15:49:23 Crofton: I'll check sizes Sep 16 15:50:09 HopsNBarley: hi, which marvell chip is that? 400 MHz, GigE,SATA ? Sep 16 15:51:11 hi likewise - i haven't opened the case yet - hold on - but that sounds like orion family Sep 16 15:51:17 steliosk: I see you are experiencing gcc 4.1.x problem with recent Linux kernels for powerpc? Sep 16 15:51:19 Crofton: hmm . . . very interesting. buildroot libgd is 219.1K, OE libgd is 1.1MB!!! Sep 16 15:51:34 HopsNBarley: which case are you opening? :-) Sep 16 15:51:54 likewise, latest iomega storcenter. Sep 16 15:52:11 how do you measure that? Sep 16 15:52:18 different options? Sep 16 15:52:20 HopsNBarley: with wireless? Sep 16 15:52:30 nope Sep 16 15:52:37 sakoman: -size ? Sep 16 15:53:21 Crofton: just looked at the size of libgd in /usr/lib for the 2 images (which is what I care about) Sep 16 15:53:33 ok Sep 16 15:54:32 Crofton, likewise: both are libgd.so.2.0.0 Sep 16 15:55:17 Crofton: have to leave for a couple of hours. I'll look at gd build options when I return Sep 16 15:55:48 Some days I think OE is too big :) Sep 16 15:55:51 Cannot find any gnuplot at http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/package/ Sep 16 15:56:05 probably in the gumstix svn ... Sep 16 16:10:49 sakoman, Crofton|home: hmmn, nothing strange. http://websvn.gumstix.com/filedetails.php?repname=Buildroot&path=%2Ftrunk%2Fpackage%2Fgd%2Fgd.mk Sep 16 16:15:00 likewise : yes Sep 16 16:15:21 steliosk: did that occur with earlier kernels? Sep 16 16:15:35 likewise : kernels up to 2.6.20 build without problem Sep 16 16:15:58 I've been seeing strange userland problems as well a while back. Looked more like binutils though... Sep 16 16:16:12 steliosk: so you stick with gcc 3.4.x for now? Sep 16 16:16:44 likewise : for the kernel yes. for userland apps gcc 4.1.1 seems to work without problems Sep 16 16:17:10 likewise : what we see is that the memory gets reported wrong Sep 16 16:17:24 likewise : that's why the kernel fails Sep 16 16:18:04 likewise : and since 2.6.20 and prior kernels worked fine with the same toolchain, i believe this to be a kernel issue Sep 16 16:19:07 I haven't seen kernel problems on efika yet. Sep 16 16:19:14 Crofton|home : Which days Mon-Fri ? :) Sep 16 16:19:24 steliosk, ? Sep 16 16:19:36 ah Sep 16 16:19:38 heh Sep 16 16:19:54 on days when we have questions about specifix packages Sep 16 16:20:06 on other days I think buildroot is too fragmented :) Sep 16 16:21:07 likewise : efika is on powerpc tree,xilinx is on the (soon to be depreciated) ppc tree and probably that's where the problem is Sep 16 16:21:44 likewise : but we did not have time to check the xilinx kernel in detail Sep 16 16:34:21 hm.. which distro is the one to be used with avr32? not armstrong 2007.1? Sep 16 16:34:44 eh ..angstrom-2007.1 Sep 16 16:35:12 roh : Yes but it will not build Sep 16 16:35:55 steliosk ? Sep 16 16:36:24 roh: both 2007.1 and 2008.1 work Sep 16 16:37:00 koen: oh.. 2007.1 failed here.. but i can just clobber and retry Sep 16 16:38:14 did you pull in the past few days? Sep 16 16:38:20 some updates went in Sep 16 16:38:27 nope.. doing now Sep 16 16:38:36 i'm on a atnwgw100 Sep 16 16:38:46 03koen 07org.oe.dev * r9a2acbd7... 10/ (1 packages/gnome/epiphany_2.19.6.bb): epiphany: needs gnome-vfs-plugin-http Sep 16 16:38:49 same here till the stk1002 arrives Sep 16 16:38:56 nice. Sep 16 16:39:38 somehow i need to find a spec to this 15" tft ive got from a dead notebook.. the avr32 seems to have a fitting controller onchip Sep 16 16:39:38 908K Angstrom-minimalist-image-uclibc-ipk-2008.1-test-20070914-atngw100.rootfs.tar.gz Sep 16 16:39:44 below 1MB :) Sep 16 16:40:10 see if it can autoload modules :) Sep 16 16:40:22 koen which target would you recommend? Sep 16 16:40:35 whow.. 271 new rev Sep 16 16:40:47 MACHINE=atngw100 Sep 16 16:41:11 those 271 include propagates from .dev Sep 16 16:41:35 i see... DISTRO on angstrom-2007.1 ? or better 2008.1? Sep 16 16:42:11 for avr32 they only differ in gtk+ versions Sep 16 16:42:44 ok.. is there some basic bitbake reciepe which pulls together a small rootfs and kernel? Sep 16 16:43:22 angstrom-minimal-image Sep 16 16:43:45 anything else drags in alsa, which doesn't compile for avr32 due to lack of atomics ops implementation Sep 16 16:44:51 i see.. will try Sep 16 16:46:04 koen: is there any progress about gpe-mini-browser? Sep 16 16:47:00 what progress do you mean? Sep 16 16:47:06 it renders google.com for me Sep 16 16:48:13 day or two ago bitbake gpe-mini-browser always failed with pkg-config being unable to find package gtk-webcore-nrcit Sep 16 16:48:39 works fine over here Sep 16 16:50:16 hm Sep 16 16:51:02 and it's in the feeds anyway Sep 16 16:51:09 http://pastebin.ca/698497 that`s what i get when trying to build it Sep 16 16:51:30 i`m using self-made images Sep 16 17:08:18 koen is bb 1.8.8 ok for avr32? i get qa-errors on packaging here Sep 16 17:18:05 File "", line 19, in package_qa_check_arch Sep 16 17:18:05 KeyError: 'avr32' Sep 16 17:18:05 ERROR: Task 173 (/home/roh/svn/oe-avr32/openembedded/packages/linux-libc-headers/linux-libc-headers_2.6.20.bb, do_package) failed Sep 16 17:36:47 koen: woowoo on the epithany Sep 16 17:44:50 roh: that sounds like you have an old copy of insane.bbclass Sep 16 17:45:09 my current thinking is task-base takes care of autoloading modules Sep 16 17:45:14 XorA|gone: it runs, but I haven't been able to visit a webpage yet, maybe we should upgrade Sep 16 17:45:19 I think task-boot needs update-moduules Sep 16 17:45:42 Crofton|home: as I said, every kernel module should run update-modules in its postinst Sep 16 17:46:30 pkg_postinst_modules () { Sep 16 17:46:31 if [ -n "$D" ]; then Sep 16 17:46:31 ${HOST_PREFIX}depmod-${KERNEL_MAJOR_VERSION} -A -b $D -F ${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION} Sep 16 17:46:31 else Sep 16 17:46:32 depmod -a Sep 16 17:46:33 update-modules || true Sep 16 17:46:33 fi Sep 16 17:46:35 when you are building images, does the postinst run then, or does that happen after first boot? Sep 16 17:46:35 } Sep 16 17:51:07 Crofton|home: as you can see from that postinst, it runs only depmod during do_rootfs and skips update modules Sep 16 17:51:25 koen hm.. it says no changes against 56e7ad184e2407b765afc6cd46fac74bd31b0447 Sep 16 17:51:28 Crofton|home: but update-modules will run itself on first boot Sep 16 17:52:04 ah.. it only has avr32 for ulibc Sep 16 17:52:11 I'm thinking task-boot needs update-modules Sep 16 17:52:21 Crofton|home: it doesn't Sep 16 17:52:32 Crofton|home: each kernel modules already RDEPENDS on update-modules Sep 16 17:52:42 see kernel.bbclass Sep 16 17:52:46 where is defined it it builds ulibc or libc? Sep 16 17:52:57 hmmm Sep 16 17:53:07 roh: using ANGSTROM_MODE Sep 16 17:53:14 ah, I forgot to say Sep 16 17:53:21 minimal image doesn't have update-modules Sep 16 17:53:30 you want ANGSTROM_MODE = "uclibc" in local.conf :) Sep 16 17:53:37 * Crofton|home needs to stop screwing around and write some crap Sep 16 17:53:38 ah.. thanks Sep 16 17:53:41 Crofton|home: so you have no modules in that image Sep 16 17:53:56 for OSK I have some modules Sep 16 17:54:01 and I autoload the usb one Sep 16 17:54:13 this works for console image, not for minimal Sep 16 17:54:23 also works for ossie-imafe, after I add task-base Sep 16 17:54:25 *restart* Sep 16 17:54:51 Crofton|home: do_split_packages(d, root='/lib/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='update-modules kernel-%s' % bb.data.getVar("KERNEL_VERSION", d, 1)) Sep 16 17:54:52 I can't gaurantee this is a completely accurate statement, since I am timesharing writing after a couple of days Sep 16 17:56:39 roh: uclibc compiles in 3 minutes vs the 3 hours for glibc :) Sep 16 17:57:22 Crofton|home: either you have no modules in the minimal image or kernel.bbclass is broken Sep 16 17:57:41 I'll have to come back to this Sep 16 17:58:30 Crofton|home: omap5912osk.conf doesn't have any *ESSENTIAL*, so it won't have any modules in task-boot Sep 16 17:58:41 ah Sep 16 17:58:54 crap, I keep forgetting the difference Sep 16 17:59:20 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS is for task-boot, MACHINE_EXTRA_RRECOMMENDS for task-base Sep 16 17:59:28 recommends flow in via task-base Sep 16 17:59:29 yeah Sep 16 17:59:33 I only learned that a few weeks ago :) Sep 16 17:59:39 beat this into my head with a stick Sep 16 17:59:43 so did I Sep 16 17:59:51 my problem is I forgot it Sep 16 18:00:18 I forget it to, and relearn it every few days when another minimal-image craps out Sep 16 18:00:23 too* Sep 16 18:00:27 essential rrecommends still won't fail of the module does not exist? Sep 16 18:00:42 no, it's still RRECOMMENDS Sep 16 18:00:45 good Sep 16 18:00:47 but in a different task Sep 16 18:00:54 I think I should upgrade some modules ..... Sep 16 18:01:35 alright Sep 16 18:01:38 back to writing Sep 16 18:02:01 good idea Sep 16 18:02:17 * koen gets back to the bachelor thesis thingy that should have been finished 2 years ago Sep 16 18:02:26 hehe Sep 16 18:02:39 only 2 more paragraphs Sep 16 18:03:16 FIXME- add verbal description of LMV and nullspace error minimization Sep 16 18:03:34 I can't copy the textbook for the description since my supervisor wrote it :( Sep 16 18:05:08 urg Sep 16 18:05:29 psokolovsky_: hi Sep 16 18:07:01 koen: google translate it around a few times :-) Sep 16 18:37:54 in IMAGE_INSTALL, do you need to list packages or sources ? because when specifying a package from a custom receipt, ipkg tells me he doesn't know it Sep 16 18:52:04 nud: you list packages Sep 16 18:52:16 nud: If ipkg didn't find it, was the package built? Sep 16 18:52:27 RP: it was Sep 16 18:52:39 it is in /deploy/ipkg Sep 16 18:53:30 I proceeded the way cbrake describes in his blog post, requiring angstrom-console-image and adding stuff to IMAGE_INSTALL Sep 16 18:55:54 any bitbake trickster ? hack kernel then bitbake virtual/kernel -f ? Sep 16 18:55:57 I have a misbehaving package (rt-test) that sets an absolute include path in it's configure.ac (/usr/include/nptl). However, STAGING_DIR is not yet set during configure. What's the neatest solution? Sep 16 18:56:14 just rebuild do not pull new kernel bz2 Sep 16 19:00:31 sakoman: I strongly suspect GD is using its builtin versions of libjpeg and friends Sep 16 19:02:04 sakoman:, koen: yes, "# JPEG has link problems -- tries to link against local /usr/lib/libjpeg instead of the STAGING_DIR one" from the makefile Sep 16 19:03:14 likewise: so this is a known bug? Sep 16 19:03:39 sakoman: oops, I was looking at the gumstix makefile, not the OE one Sep 16 19:04:00 the gd recipe specifies the staging version Sep 16 19:04:03 it's one of those "5 minutes to solve it, but no one takes the time" kind of things Sep 16 19:04:22 so to fix angstrom-minimal to take modules ? use ESSENTIAL RECOMMENDS trick ? Sep 16 19:07:00 why "No Providers" slugos-image when slugos distro is used ? Sep 16 19:08:11 sakoman: -rwxr-xr-x 1 leon leon 209164 2007-09-16 20:59 libgd.so.2.0.0 Sep 16 19:09:11 sakoman: so my libgd from OE is also ~200 kB, not 1.1 MB, where did you look? Sep 16 19:10:12 interfaith, yes, this is my understanding Sep 16 19:10:41 thx Sep 16 19:10:55 interfaith, the problem is deciding what is really essential Sep 16 19:11:07 and that task-base has too much crap :) Sep 16 19:11:20 well yes i do need the network modules Sep 16 19:11:48 interfaith, I am having a philosophical discussion with myself :) Sep 16 19:12:01 chirp Sep 16 19:12:32 basically, we need mission statements for each of the basica tasks Sep 16 19:12:50 * Crofton|work pukes after using the phrase "mission statement" Sep 16 19:13:20 not the LION the BEAR is the king Sep 16 19:15:33 the provider for an 'image' is contained with the 'distro' ? Sep 16 19:17:42 bootstrap-image build fails now some gnome package fails to download Sep 16 19:18:03 which package? Sep 16 19:18:19 1 sec Sep 16 19:20:38 gconf-dbus.svn.bb Sep 16 19:21:02 trunk_develope...........dbus_1_.tar.gz Sep 16 19:21:35 i dont need it.. but bootstrap-image has the network modules for an easy test Sep 16 19:24:53 RP: http://rafb.net/p/SyaLBA97.html <-- the files; http://rafb.net/p/DVUmtd74.html <-- the log; http://rafb.net/p/eYOjuP65.html <-- the files in /install (or, why I don't understand why some packages are missing) Sep 16 19:26:57 bitbakers.. so if changes are made to kernel code.. we rebuild via bitbake virtual/kernel -f ? Sep 16 19:27:21 i do so Sep 16 19:27:34 nice..going Sep 16 19:27:44 or you can just do compile step Sep 16 19:28:01 -c compile -f ? Sep 16 19:28:09 yes Sep 16 19:28:52 the point is when changing kernel source code to simply rebuild and not download and overwrite the kernel code again Sep 16 19:29:12 such tricks are VITAL Sep 16 19:30:55 interfaith: just in case, such tricks are just dirty and not scalable (though pragmatic oftentimes) Sep 16 19:31:24 WELL then howto kernel hacking ? Sep 16 19:32:03 likewise: -rwxr-xr-x 1 root root 1115328 Jan 1 1970 /usr/lib/libgd.so.2.0.0 Sep 16 19:32:08 for building a new board solution on oe Sep 16 19:32:51 it have nothing to do with oe Sep 16 19:32:55 likewise: I checked both in /usr/lib on my gumstix and in rootfs/usr/lib Sep 16 19:33:05 just compiler Sep 16 19:33:19 interfaith: the right way is to produce patch with the changes, apply it to .bb, and bump PR so it was rebuilt. Of course, such sequence makes sense mostly for hacking-for-maintenance (in the sense that .bb maintainer will need to do that eventually) Sep 16 19:33:43 likewise: angstrom-2007 distro? Sep 16 19:33:45 sakoman: did you try the "size" command (preferably the cross one) on this file? Sep 16 19:33:53 sakoman: yes, 2007.9 here Sep 16 19:34:09 .9? Sep 16 19:34:17 ok..eventually a solid patch will emerge, then Sep 16 19:34:36 right now i am just groping for a working network Sep 16 19:34:49 for what board? Sep 16 19:35:14 if it's not secret :) Sep 16 19:35:21 it is like the ixpdpg425.. has marvel chip on board .. almost works Sep 16 19:35:35 the board does an HPNA service Sep 16 19:35:49 reboot works fine..NPE-B on phy 5 Sep 16 19:36:05 however i get linkup link down over and over in the os Sep 16 19:36:30 likewise: size indicates text is 985721, datais 126996, bss is 67084 Sep 16 19:36:30 ifconfig -a sees eth0 and eth1.. but no ping YET :( Sep 16 19:37:09 so rwhitby counselled me on getting ucode NPE-B AND C into a flash partition Sep 16 19:38:23 my next try is to use nslu2be /slugos distro slugos-image with kernel setup hacks Sep 16 19:38:39 sakoman: uclibc, likewise: glibc? Sep 16 19:39:06 koen: yes uclibc for me on both buildroot and OE Sep 16 19:39:27 koen: glibc :-) Sep 16 19:40:02 there you go :) Sep 16 19:40:12 so far the trick was to get the ixp..ko modules to show up in the image via ESSENTIAL Sep 16 19:40:27 koen: what creeps in the uclibc build? math? Sep 16 19:40:46 likewise: I still suspect internal libs Sep 16 19:42:58 likewise: strange that the buildroot uclibc version of gd and the OE libc version are roughly the same size, but the OE uclibc is vastly larger! Sep 16 19:43:26 sakoman: see koen's remark above Sep 16 19:45:27 likewise: yes I saw it Sep 16 19:49:02 log for gd do_configure indicates that configure finds both jpeg and png support Sep 16 19:55:12 sakoman, looks like you do not need the auto eth0 bit Sep 16 19:56:09 Crofton: I found that it wasn't necessary on first boot, but was for subsequent boots Sep 16 19:56:23 rebooting Sep 16 19:57:38 hm, you re correct Sep 16 19:57:45 :-) Sep 16 20:13:48 koen: doesn't seem to be jpeg lib. Running gdlib-config on buildroot version gives "-lfreetype -lpng12 -lz -lm " on OE gives "-ljpeg -lpng12 -lz -lm /home/sakoman/perforce/s100/build/tmp/staging/arm-angstrom-linux-uclibcgnueabi/lib/libiconv.a" Sep 16 20:14:06 If it is statically linking libiconv that would explain the 900K difference Sep 16 20:14:40 BTW, I didn't build in jpeg support on my buildroot version Sep 16 20:14:50 but did build in freetype Sep 16 20:16:15 Crofton: btw, the auto eth0 is required on the buildroot version of gumstix too Sep 16 20:34:23 koen: libiconv is the culprit. It isn't present in the buildroot version, but is present twice in the OE build. Once in /usr/lib pulled in by gdb and another time statically linked into libgd Sep 16 20:35:31 That explains 1.8MB of the difference in size, and the inclusion of libstdc++ by gnuplot explains most of the rest of the increase between OE and buildroot images Sep 16 20:37:05 sakoman, you should put that in bugzilla Sep 16 20:38:20 Crofton: what is strange is that likewise isn't getting the libiconv bloat Sep 16 20:38:42 Gonna try to understand this a little better before filing a bug Sep 16 20:39:14 ok Sep 16 20:40:25 i'm on glibc, mind you Sep 16 20:40:44 yes, there is that :-) Sep 16 20:41:56 Crofton: all this work just to get back to where I was a month ago with buildroot! :-) Sep 16 20:43:04 I suppose if I was smarter it wouldn't have taken so long ;-) Sep 16 20:45:37 I don't mind spending tie learning things in great depth, what I mind is forgetting what I learned and having to learn it again ..... Sep 16 20:45:42 likewise: could you look in work/.../gd-2.0.33/config.h and see if HAVE_ICONV is defined for you? Sep 16 20:46:05 Crofton: yeah, seems like that happens more often as the years pass! Sep 16 20:46:13 yep Sep 16 20:46:29 hopefully we can get a fix in place and solve the problem Sep 16 20:46:54 Crofton: yeah, as they say, "size matters" Sep 16 20:47:13 how days of data is that? Sep 16 20:48:41 why does bitbake generate libfoobar (ie: the name of the .so file) instead of using $(PN) ? Sep 16 20:50:13 Crofton: uncompressed a year of data is about 10MB Sep 16 20:51:49 so a meg of flash gets you 6 weeks or so Sep 16 20:51:52 I have a .so file named libpt-linux-arm.so and I'd like to have packages like libpt$version.ipkg instead Sep 16 20:52:00 Crofton: yup Sep 16 20:57:43 neo has no camera? Sep 16 20:57:52 * Crofton thinks this would be a good thing Sep 16 21:08:03 hi, what does an ?= mean in a bitbake conf file (context TARGET_ARCH ?= "armeb"). Set variable if unset? Sep 16 21:09:18 yeah Sep 16 21:09:27 Crofton: thanks Sep 16 21:23:34 nud: The packages look to be there but ipkg isn't seeing them for some reason Sep 16 21:26:40 RP: should I put pwlib-plugins or libpt-linux-arm-r-plugins in IMAGE_INSTALL ? Sep 16 21:27:16 nud: pwlib-plugins Sep 16 21:27:36 ah Sep 16 21:27:48 so it is neither the ipkg name nor the build source package Sep 16 21:28:24 nud: Its the name as used in PACKAGES Sep 16 21:28:30 ok Sep 16 21:29:28 what I've ended to do is to put pwlib-plugins and opal-plugins in cet-vphone's RDEPENDS Sep 16 21:29:45 is it a good approach ? Sep 16 21:29:50 nud: If that works, adding to IMAGE_INSTALL should work too Sep 16 21:30:05 I've not rebuilt the image yet ;-) Sep 16 21:33:49 RP: thanks, seems to work Sep 16 21:34:33 it seems I was just not catching the package names to use Sep 16 21:34:49 imho the .ipk files should have the same filename as the PACKAGES name Sep 16 21:36:45 mmh actually the -plugins packages didn't end up in the image Sep 16 21:37:00 ah yeah they did Sep 16 21:37:07 * nud was looking in the wrong image Sep 16 21:45:30 nud: If you want the names to match, disable debian.bbclass Sep 16 21:46:38 it's sorta more logical in that context Sep 16 21:56:01 sakoman: #define HAVE_ICONV 1 Sep 16 22:47:09 03mickeyl 07org.oe.dev * rba4c754e... 10/ (4 files in 2 dirs): linux.inc: make convenient selection of root-over-nfs actually work Sep 16 22:52:16 slugos root password ?? Sep 16 22:52:28 try hitting return? Sep 16 22:52:33 no luck Sep 16 22:52:40 using slugos-image Sep 16 22:52:55 bootstrap-image no password ok Sep 16 22:53:01 rwhitby trix ? Sep 16 23:03:21 koen, what distro are you using with your nokia800? What is the nokia bootloader like to work with? Sep 16 23:04:55 koen, lol, I just realized I'm logged in as my wife.. I'm on her computer. This is svope (Gerrath). Sep 16 23:06:26 * Crofton hopes koen is in bed .... Sep 16 23:07:31 Crofton, Thanks, I always foget he's on a very different timezone from me :-) Sep 16 23:07:38 yeah Sep 16 23:07:49 sometimes those guys are up pretty late Sep 16 23:18:45 anyone seen a compile fail in xserver-xorg_1.3.0.0.bb? Sep 16 23:34:15 anyway to build an image like bootstrap-image if one package fails to download.. can it be cut out ? Sep 16 23:35:03 gconf-dbus_svn.bb fails to download.. can i cut it out via some bitbake trick ? Sep 16 23:35:43 this bb is not needed not used.. i just need the image Sep 16 23:37:13 or how to get the angstrom-minimimal image to include the ixp4xx modules ? some ESSENTIAL trick ? Sep 16 23:47:53 interfaith: SlugOS root password is "opeNSLUg" (note odd uppercase) Sep 16 23:48:31 ok thx ! any idea to cut OUT a bb from task-base.. one that will not download eg Sep 16 23:48:53 You have to find everything that depends on it, and remove it. Sep 16 23:49:24 ouch.. for some reason one bb cannot download in bootstrap-image..hanging me as i dont need that anyway Sep 16 23:49:48 Well, something thinks you need it -- bitbake is attempting to download it. Sep 16 23:51:47 or the other way around the ixp4xx network module ARE in bootstrap-image but NOT in angstrom-minimal Sep 16 23:51:50 how to add ? Sep 16 23:53:53 bootstrap-image has many extras this one is gnome .. it is in task-base perhaps Sep 16 23:54:25 Same way - understand and compare the dependencies, so that you can add a dependency on the ixp4xx modules into the correct image. Off the top of my head, I don't know where the correct place for this dependency might be for angstrom. Sep 16 23:55:24 the EXTRA commands are in the MACHINE AND DISTRO conf files..which are the same for both images Sep 16 23:56:15 i will check the bb file of angstrom-minimal..to see if EXTRA is used Sep 17 00:01:03 anyway to force a build of "roofs" if some files are added..hacking time ! Sep 17 00:13:11 i suppose there is some rootfs bb to build a hacked rootfs ? Sep 17 00:21:09 ANGSTROM_EXTRA_INSTALL ? anyone guess ? to add kernel modules perhaps ? **** ENDING LOGGING AT Mon Sep 17 02:59:57 2007