**** BEGIN LOGGING AT Thu Apr 22 02:59:57 2010 Apr 22 03:03:12 I ran the "bitbake virtual/kernel" and waited for it to finish, I think it succeeded. Where exactly were the files installed to? Apr 22 03:05:29 BitWraith: look in tmp/deploy/ Apr 22 03:06:08 ah... There appears to be a finished kernel image here Apr 22 03:08:23 and, the modules archive already has an asix module, I didn't have to change the config :-) Apr 22 04:01:55 How would I go about adding squashfs patches to the linux/2.6.26 recipe? Would simply typing them into the recipe itself and recompiling be enough? Apr 22 04:05:18 Come to think of it, that's probably overkill. As much as that would solve my problems with portage, there are other ways that involve less abuse of the patch system Apr 22 04:08:37 look at the recipes. there are plenty of examples of how you add patches to a build Apr 22 04:55:20 how do I force bitbake to rerun a task that was already completed? Apr 22 04:56:10 Sine I already have one working kernel, there is no harm in trying the patches. I have them in the .bb file, but I'm getting "20 tasks did not need to be rerun" Apr 22 05:02:34 actually, it may have completed after all Apr 22 05:02:42 I think I misread the output Apr 22 05:03:34 BitWraith: you probably didn't bump PR. either bump the revision or bitbake -c clean virtual/kernel to get it to rebuild. Apr 22 05:08:12 YES! It appears to have patched successfully. :-) Apr 22 06:09:53 I build directfb-1.0.4 and qt-4.6.0 with open embedded , but can't display from fb, get error:"directfb: driver not found" Apr 22 06:10:15 how I can solve it, tks Apr 22 06:15:39 I need to make some changes to my kernel config and have completely forgotten what the tool/package to generate a new defconfig is called. Anyone? Apr 22 06:28:21 ah. bitbake virtual/kernel -c menuconfig, so nevermind :) Apr 22 06:45:22 wow, this is wierd... my /dev/ is mostly empty. I have no loop devices, and no block devices. lol Apr 22 06:57:49 morning Apr 22 08:21:07 03Koen Kooi  07org.openembedded.dev * rf48823a3a5 10openembedded.git/recipes/tinylogin/tinylogin_1.4.bb: tinylogin: bump PR for LICENSE change Apr 22 08:57:48 good morning Apr 22 09:18:46 hey all, this may be a fairly general make/bitbake question: Apr 22 09:19:04 if I want the auto-generated .config file in the kernel source directory to contain certain additional entries, where do I have to define them? Apr 22 09:19:16 (the .config itself gets overwritten on each bitbake compilation) Apr 22 09:19:45 a quick pointer would be appreciated :-) Apr 22 09:34:51 tsaaps: the defconfig for your machine is copied to .config on every bitbake run. So change recipes/linux/your_machine/defconfig to contain those entries Apr 22 09:46:24 ah, thanks a lot! :-) Apr 22 09:57:13 the default fstab says "uncomment line if you have sdcard", is there a default way to specify my own fstab file somewhere, or would I have to take the whole base-files package into my collection? Apr 22 10:45:27 03Sergey Lapin  07org.openembedded.dev * rda6df4bb33 10openembedded.git/recipes/busybox/busybox.inc: (log message trimmed) Apr 22 10:45:27 busybox: prevent postinst script from failing Apr 22 10:45:27 recent addition in rootfs_ipk.bbclass which runs postinst scripts with Apr 22 10:45:27 -e option, while very useful, prevents busybox from configuring at image Apr 22 10:45:27 build time. It will be configured at first image boot if your file Apr 22 10:45:28 system is writable, but in case of e.g. squashfs, that will be fatal Apr 22 10:45:29 error. This commit prevents postinst to fail, so busybox will create Apr 22 11:22:42 03Roger Monk  07org.openembedded.dev * rc8f2cde950 10openembedded.git/recipes/ti/ti-dsplink.inc: Apr 22 11:22:42 ti-dsplink: remove unnecessary 'clean' step Apr 22 11:22:42 * dsplink installations (when used directly, and not from cetools) Apr 22 11:22:42 are clean and therefore don't need a clean step Apr 22 11:22:42 Signed-off-by: Roger Monk Apr 22 11:22:43 Signed-off-by: Koen Kooi Apr 22 11:22:47 03Roger Monk  07org.openembedded.dev * r791c15ebf5 10openembedded.git/recipes/ti/ (ti-dsplink.inc ti-dsplink_1.64.bb): Apr 22 11:22:47 ti-dsplink: Move dsplink_1.64 fix-ups into version specific recipe Apr 22 11:22:47 * Fix-ups for kernel headers and CROSS_COMPILE are specific to 1.64 Apr 22 11:22:47 Signed-off-by: Roger Monk Apr 22 11:22:47 Signed-off-by: Koen Kooi Apr 22 11:22:47 03Roger Monk  07org.openembedded.dev * rdaf115dfc1 10openembedded.git/recipes/ti/ (ti-dsplink.inc ti-dsplink_1.64.bb ti-dsplink_1.65.00.02.bb): Apr 22 11:22:47 ti-dsplink: Use new URL and add dsplink v1.65.00.02 (early adopter) Apr 22 11:22:48 * Add new version (1.65.00.02) - eary adopter release Apr 22 11:22:48 * Start using new URI base location Apr 22 11:22:49 * Introduce variables to keep SRC_URI common and PV variants Apr 22 11:23:05 ti-local-power-manager: Remove OPT from LPM sources using #define Apr 22 11:23:05 * OPT Argument Decorator is no longer used/supported in latest dsplink versions Apr 22 11:23:05 * LPM implements some callback functions from DSPLINK which used this decorator Apr 22 11:23:05 * 'Void _TAL_translateCallback (IN Uint32, IN OPT Pvoid, IN OPT Pvoid);' Apr 22 11:23:06 * Remove by passing -DOPT="" to LPM build Apr 22 11:23:06 * Safe to remove for building against older DSPLINK versions as well Apr 22 12:04:51 03Koen Kooi  07org.openembedded.dev * r4914d6f9f4 10openembedded.git/recipes/glib-2.0/ (5 files in 2 dirs): glib-2.0 2.24.0: apply two patches from release branch and one from ubuntu Apr 22 13:12:32 03Martin Jansa  07org.openembedded.dev * r630b9cff97 10openembedded.git/recipes/libconfig/ (2 files in 2 dirs): Apr 22 13:12:32 libconfig_1.3.2: add patch for build with automake-1.11 Apr 22 13:12:32 * libconfig.h is installed twice from $(libinc) and then again from $(libinc_cpp) Apr 22 13:12:32 * newer automake checks that and fails Apr 22 13:12:32 Signed-off-by: Martin Jansa Apr 22 13:41:35 03Martin Jansa  07org.openembedded.dev * r4cd4219072 10openembedded.git/recipes/qwo/ (qwo-0.5/qwo.automake-1.11.patch qwo_0.5.bb): Apr 22 13:41:35 qwo: add patch for build with automake-1.11 Apr 22 13:41:35 * qwo.1 is created in created in DESTDIR already with help2man, no need Apr 22 13:41:35 to add it to DEST files Apr 22 13:41:35 * automake-1.11 checks for files instaled more than once and fails Apr 22 13:41:36 Signed-off-by: Martin Jansa Apr 22 13:53:28 03Koen Kooi  07org.openembedded.dev * r770632552a 10openembedded.git/recipes/netbook-launcher/ (2 files in 2 dirs): liblauncher: add 0.3.8, disabled by default since it breaks API Apr 22 14:41:22 ao2: python _ctypes problem: do you have http://paste.pocoo.org/show/204928/ because of http://paste.pocoo.org/show/204929/ in Modules/_ctypes/libffi/configure.ac? Apr 22 14:50:43 JaMa, I've fixed the configure Apr 22 14:50:53 let me paste the patch Apr 22 14:51:00 morning Apr 22 14:51:05 morning Apr 22 14:51:22 hi Apr 22 14:51:49 ao2: or push it please if it works Apr 22 14:53:22 yo , i m working on beagleboard video system but when i try to play simple 720p video on beagleboard , i got so slow fps ? whats wrong ? beagleboard documentation says it plays 720p at 60fps but i got maybe 5 fps very slow video on console ? whats wrong ? Apr 22 14:53:29 JaMa, the configure now passes but I still have some "wrong ELFCLASS" messages on build, but the module seems to be compiled anyway. Sending to oe-devel then, as I don't have commit rights Apr 22 14:54:23 someone please help ? :( Apr 22 14:57:27 #beagle beagle32 Apr 22 14:58:27 ao2: ok, thanks I'll try, BTW: you should probably apply for R/W, those patches you sent before were good and IIRC were applied in most cases Apr 22 14:59:37 JaMa, I'll consider that, thanks. Apr 22 15:01:49 JaMa, sent Apr 22 15:11:14 ao2: missing PR bump.. but looks good Apr 22 15:15:05 JaMa, will you fix it up before pushing? Plus, let me know if you get the "wrong ELFCLASS" messages in the do_compile logs, please. Apr 22 15:15:24 ao2: yes.. Apr 22 15:15:39 ao2: wrong ELFCLASS was there even before IIRC Apr 22 15:16:25 I see, as I said _ctypes seems to work fine regardless, I was just curios. Apr 22 15:20:03 03Antonio Ospite  07org.openembedded.dev * r539d5a80be 10openembedded.git/recipes/python/ (3 files in 2 dirs): (log message trimmed) Apr 22 15:20:03 python-2.6.4: make Modules/_ctypes/libffi configure Apr 22 15:20:03 This fixes configure issues with recent autoconf, e.g: Apr 22 15:20:03 autoreconf: Entering directory `Modules/_ctypes/libffi' Apr 22 15:20:03 autoreconf: configure.ac: not using Gettext Apr 22 15:20:03 autoreconf: running: aclocal --force Apr 22 15:20:04 configure.ac:26: error: m4_copy: won't overwrite defined macro: \ Apr 22 15:28:41 hmmmm Apr 22 16:04:29 kergoth: indeed Apr 22 16:05:02 Can anyone recall if RP got anywhere looking at threading the initial parsing process? Apr 22 16:21:13 kergoth, not sure but I do know that RP should be traveling today, and hopefully will make it all the way home from the US without too many hitches Apr 22 16:21:19 ah Apr 22 16:21:21 cool Apr 22 16:21:22 thanks Apr 22 17:12:37 where in US was RP ? Apr 22 17:12:55 zenlinuxPDX: Folsom ? Apr 22 17:15:09 He was in SFO for a conference and then up in Portland Apr 22 17:15:46 zenlinuxPDX: oh cool. If I was in country I could have met him in SFO Apr 22 17:16:34 where are you these days? Apr 22 17:16:51 I was in india until tuesday Apr 22 17:16:57 cool Apr 22 17:17:02 I am back here in bay area now Apr 22 17:51:01 window 12 Apr 22 17:51:08 heh sorry. Apr 22 18:05:03 03Roman I Khimov  07org.openembedded.dev * re235bf7138 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Apr 22 18:05:03 util-linux-ng: handle setsid through alternatives too Apr 22 18:05:03 It can be provided by busybox. Apr 22 18:05:03 Signed-off-by: Roman I Khimov Apr 22 18:06:09 I'm porting a design from an old version of OE (early 2008) to the latest version of OE everything has good smooth so far but when I compile the kernel it is 4 times the size of the kernel when it is compiled on the older version of OE. I diff'd the config files and they are identical other than time stamp. KERNEL_IMAGETYPE = "uImage" is set in both OE systems. What else would cause the kernel to compile so large. Apr 22 18:06:39 svolpe: are you comparing uImage size ? Apr 22 18:06:46 khem: yes. Apr 22 18:07:22 svolpe: ok I would suggest to look into the vmlinux files and compare the section sizes Apr 22 18:07:52 svolpe: what version binutils are you using in bad case Apr 22 18:08:50 svolpe: and what version of kernel is it ? Apr 22 18:11:47 khem: the kernel is 2.6.23, I will check on the binutils Apr 22 18:15:42 khem: binutils 2.20 Apr 22 18:16:09 svolpe: ok, can you run size command on both new and old vmlinux Apr 22 18:16:26 and check which sections are bloated Apr 22 18:20:45 khem: the text is bloated. Apr 22 18:21:18 svolpe: hmmmm Apr 22 18:21:42 khem: data and bss are identical text is 3M verses 1M Apr 22 18:21:53 svolpe: ok Apr 22 18:22:16 svolpe: which gcc versions are used in both cases Apr 22 18:23:12 khem: 4.4.2 for the boated, 4.1.1 for the not bloated. Apr 22 18:23:43 svolpe: ok. Apr 22 18:25:19 svolpe: If you have the build trees for both you may compare some individual files Apr 22 18:25:28 like built-in.o for size Apr 22 18:25:35 khem: I do have the build trees for both. Apr 22 18:25:42 ok good Apr 22 18:27:39 khem: which built-in.o file, there are quite a few? /arch/arm/kernel? Apr 22 18:28:59 svolpe: yes Apr 22 18:29:16 svolpe: if you could generate a linker map file that would be awsome Apr 22 18:30:18 khem, should not be a problem. I have 2 virtual systems running, one with the old OE, one with the new OE :-) Apr 22 18:30:34 cool Apr 22 18:30:53 my guess is that something bad is happening in link step Apr 22 18:31:02 khem: its been a while since I have done a linker map so I might be a couple of minutes. Apr 22 18:31:30 yeah ok. Add -Map option to linker options Apr 22 18:32:39 khem: I already have the System.map but I'm assuming that is not enough information. Apr 22 18:33:22 yeah in there you can check if the addresses are same in both Apr 22 18:33:25 or similar Apr 22 18:33:45 another thing you could do is disassemble the vmlinux files Apr 22 18:33:57 and check if there are like 0s appended Apr 22 18:35:36 svolpe: keep trying I will be back in a bit out to get lunch Apr 22 18:35:52 khem: ok, thanks. Apr 22 18:39:25 khem: you have to love OE. I just edited -Map to LDFLAGS in run.do_compile.xxx ran the script and my linker script was made :-) Apr 22 18:56:06 03Klaus Kurzmann  07org.openembedded.dev * r4927ae4069 10openembedded.git/recipes/freesmartphone/libframeworkd-glib_git.bb: Apr 22 18:56:06 libframeworkd-glib_git.bb: bump rev to get fsogsmd compatability fix Apr 22 18:56:06 Signed-off-by: Klaus Kurzmann Apr 22 19:24:30 03Martin Jansa  07org.openembedded.dev * r2676fd398e 10openembedded.git/recipes/shr/frameworkd-config-shr_git.bb: Apr 22 19:24:31 frameworkd-config-shr: drop fso-abyss from RDEPENDS (not needed with fsogsmd) Apr 22 19:24:31 Signed-off-by: Martin Jansa Apr 22 19:24:41 03Martin Jansa  07org.openembedded.dev * r558333e8c8 10openembedded.git/recipes/tasks/task-shr-minimal.bb: Apr 22 19:24:41 task-shr-minimal: drop fso-abyss from RDEPENDS (not needed with fsogsmd) Apr 22 19:24:41 Signed-off-by: Martin Jansa Apr 22 19:24:42 03Martin Jansa  07org.openembedded.dev * r1d659b8468 10openembedded.git/recipes/tasks/task-shr-feed.bb: Apr 22 19:24:43 task-shr-feed: drop fso-abyss and mokoko Apr 22 19:24:43 * fso-abyss is not needed with fsogsmd Apr 22 19:24:43 * mokoko is broken after last EFL bump and pretty much dead Apr 22 19:24:43 Signed-off-by: Martin Jansa Apr 22 19:47:03 svolpe: ok. do you see any differences between two mapfiles Apr 22 20:08:17 03Roman I Khimov  07org.openembedded.dev * reab5346d00 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Apr 22 20:08:17 util-linux-ng: handle chrt through alternatives too Apr 22 20:08:17 Can be provided by busybox. Apr 22 20:08:17 Signed-off-by: Roman I Khimov Apr 22 20:08:18 khem: there are some minor differences as the new map file has a couple more entries but other than that I do not see anything sizewise. I imported both into a spreadsheet and did subtraction from earch sections address to the previous sections address then sorted by that field, largest first and the two map files looked similar for section sizes. Apr 22 20:09:51 svolpe: hmmm Apr 22 20:10:06 svolpe: how does addresses in System.map look Apr 22 20:10:35 is there any default / preferred way to overrule the stock fstab file, except having to pull the whole .bb package into an own collection and modifying it? Apr 22 20:11:12 I'd suggest leveraging FILESPATH Apr 22 20:11:21 FILESPATHBASE =. "${TOPDIR}/files:" Apr 22 20:11:42 cp -a some/path/fstab /path/to/builddir/files/therecipethatownsfstab/ Apr 22 20:11:48 (probably base-files) Apr 22 20:11:48 khem: One thing I noticed is that vmlinux in the root Linux directory is about the same size (4.4M) for both builds but the vmlinux in arch/arm/boot/compressed in what is different as the good system is about 1.5M and the bad system is about 4.6M Apr 22 20:12:39 kergoth: hmm... thanks... still "half nice" somehow, but better than nothing Apr 22 20:12:47 "half nice"? Apr 22 20:12:52 khem: I have to head off for a bit, I will probably be back on in a couple of hours, if not maybe I can talk to you some more tomorrow. Thanks for all the help already. Apr 22 20:13:01 i'd be interested to hear what's wrong with that method, or what could possibly improve upon it Apr 22 20:13:04 svolpe: compressed uses its own linkers script IIRC Apr 22 20:13:21 svolpe: ok Apr 22 20:13:26 khem: so I guess that probably is were the problem is then. Apr 22 20:13:34 if you want to avoid dealing with an individual recipe at all, use ROOTFS_POSTPROCESS_COMMAND to do whatever mangling you want to on the filesystem of the image Apr 22 20:13:40 but that's more hackish yet Apr 22 20:14:30 kergoth: amends.inc could be used too I guess isnt it Apr 22 20:14:52 kergoth: well, I think it's not really nice to copy stuff to the builddir, btw where would you do that at all if you do not touch the original recipe? I'd rather prefer a variable on machine or local.conf level to specify the fstab (especially since the comment inside the fstab says that "you may want to modify it") Apr 22 20:15:43 Jin^eLD: that makes no sense Apr 22 20:15:55 you want a variable, which don't support inline newlines, to specify a multi-line file? Apr 22 20:16:22 kergoth: I think you misunderstood me, I do not want to have the files contents in the variable Apr 22 20:16:23 03Khem Raj  07org.openembedded.dev * raa56c494db 10openembedded.git/recipes/gcc/gcc-svn.inc: Apr 22 20:16:23 gcc-svn.inc: Change version to 4.6.0 Apr 22 20:16:23 Signed-off-by: Khem Raj Apr 22 20:16:33 03Khem Raj  07org.openembedded.dev * re1babd21c9 10openembedded.git/recipes/gcc/ (14 files in 2 dirs): Apr 22 20:16:33 gcc: Add recipes for version 4.5.0 Apr 22 20:16:33 Signed-off-by: Khem Raj Apr 22 20:16:34 rather an easy way to specify where the customized fstab should come from Apr 22 20:16:46 recipes find all local files in the same, consistent way Apr 22 20:16:55 they all use FILESPATH to find any file:// file Apr 22 20:16:57 fstab is no different Apr 22 20:17:03 what was the way again to specify custom dev nodes? Apr 22 20:17:19 I think there was a different approach Apr 22 20:17:23 and i told you how to point FILESPATHBASE to an alternative location Apr 22 20:17:25 not rocket science Apr 22 20:17:58 I do understand the idea and that it would work :) it just sounds like a "brute force" approach Apr 22 20:18:46 we're not going to subvert the entire way that local files are handled to make you happy Apr 22 20:19:08 if you have a better way that still allows versoin specific files, machine specific files, and distro specific files all to be included in the OE repository, i'd certainly like to hear it Apr 22 20:19:21 kergoth: I was thinking of something similar to how the device_table is handled Apr 22 20:19:30 device_table is a special case. Apr 22 20:19:40 it's not found via the mechanism that every other recipe in the repo uses Apr 22 20:19:55 and that method doesn't allow the conditional versions i just described Apr 22 20:20:39 do a find openembedded/recipes/base-files -name fstab. Apr 22 20:21:08 those are automatically used when appropriate, with a single entry in SRC_URI Apr 22 20:21:13 mhm mhm.. well I'll give this all a thought... I'd find it nice to be able to customize "global system files" in a consistent manner Apr 22 20:21:29 they aren't "global system files" Apr 22 20:21:37 they're a file installed by a binary package, generated by a recipe Apr 22 20:21:43 you aren't just dropping the file in the rootfs Apr 22 20:21:47 so sorry, it's not going to be that easy Apr 22 20:22:04 but yes, please do, we're always open to improvements Apr 22 20:22:32 I see your point, on the other hand it's more "rootfs customization", but then again someone would have to define what exactly falls into that category Apr 22 20:22:52 as i already told you, you can add hacks to the rootfs with a variable Apr 22 20:23:07 ROOTFS_POSTPROCESS_COMMAND += "cp /path/to/fstab ${D}/etc/fstab;" Apr 22 20:23:41 I know the postprocess thing, I was using from time to time for things like that but my thought was to make some packages aware of such customizations Apr 22 20:24:19 well, good luck with that. Apr 22 20:24:21 :) Apr 22 20:24:52 and good luck coming up with a clean syntax for it Apr 22 20:25:01 at a minimum for each file you'd have to specify the local path and the destination path Apr 22 20:25:11 and bitbake variables, as i said, are single line, unless you define them as functions Apr 22 20:25:46 CUSTOMIZED_FILES += "/local/path:/etc/fstab" would be about the best you could do, most likely Apr 22 20:26:38 hmmm Apr 22 20:26:43 I'll give that all a deeper thought, just brought this up becuase I kind of stumbled across this a couple of times on different occasiouns Apr 22 20:27:28 * kergoth_ still doesn't really see what's unclean about putting the files in a per-recipe location using filespathbase. the files have to go somewhere, why not there? Apr 22 20:28:25 I actually think we need to completely re-do image/rootfs construction Apr 22 20:28:36 a recipe for it with a list of binary packages is really limited Apr 22 20:28:54 ideally there'd be a separate tool for it, with a UI Apr 22 20:29:04 I do not know why I am so "scared" regading the filespathbase, maybe because I want to be more explicit in configuring "I wans this to happen" Apr 22 20:29:19 omg, UI Apr 22 20:29:26 that's scarier :) Apr 22 20:29:27 copying or creating a file in a directory isn't explicit? Apr 22 20:29:56 you may easily forget a file there and you'll never notice or get an error message Apr 22 20:30:42 vs. I told it so and if it's not there it'll complain Apr 22 20:31:03 sure, that'd be user error Apr 22 20:32:19 if you were to write http://kergoth.pastey.net/135585 to classes/customized_files.bbclass and add INHERIT += "customized_files", you could specify them the way i did above with the CUSTOMIZED_FILES definition Apr 22 20:32:34 well, not quite, you'd have to add to a recipe specific definition Apr 22 20:32:52 CUSTOMIZED_FILES_append_pn-base-files = " /path/to/some/fstab:/etc/fstab" Apr 22 20:33:26 * kergoth_ doesn't think thats much cleaner, but maybe you'd prefer that Apr 22 20:33:39 erm, the to needs -f2, of course Apr 22 20:33:44 but you get the idea Apr 22 20:33:50 yes, thanks for the sample Apr 22 20:33:54 np Apr 22 20:34:20 I'll play around with it, maybe I'll come up with something Apr 22 20:34:22 i still think we need a standalone tool, similar to the montavista image designer thingy Apr 22 20:35:05 as long as it does not limit existing functionality and is a standalone addon... Apr 22 20:35:37 or in other words - as long as its not enforced upon us, fine :) Apr 22 20:35:46 that's what i'd like to see, not part of bitbake or oe (though it could be included with it), just a separate python script as an alternative to the recipes Apr 22 20:36:04 course, you'd then need a way to share common image configs for that script, the way we do with the recipes Apr 22 20:36:12 which adds to the complexity a bit, so maybe thats not ideal Apr 22 20:36:13 * kergoth_ shrugs Apr 22 20:37:39 I think such a tool would have a huge complexity... especially if it wants to offer more tuning options Apr 22 20:37:53 well, that complexity has to be somewhere Apr 22 20:38:02 the question is where, and the usability of the interface Apr 22 20:42:02 * kergoth_ grumbles Apr 22 21:05:43 anybody coming to ESC in San Jose ? Apr 22 21:11:36 khem: I'm starting to think it would be easier to port my board files to a newer version of the kernel :-) Apr 22 21:12:29 svolpe: yes Apr 22 21:12:54 svolpe: can you compare the Map files for compressed kernels Apr 22 21:12:57 khem: even once I find the bloated section, then what? it will be some sluething to fix it. I suspect I could port everything to the latest kernel in 3 days which will probably be quicker. I'll have to give it some thought. Apr 22 21:13:14 khem: I will do that next. Apr 22 21:14:06 khem: compare the compressed kernels that is. Apr 22 21:14:11 yeah Apr 22 21:29:06 svolpe: compare arch/arm/boot/compressed/vmlinux.lds.in from say 2.6.31 and your kernel which is 2.6.23 Apr 22 21:29:15 and see the differences Apr 22 21:29:42 svolpe: I have 2.6.25 kernel here compiling wth 4.5.0 producing 1.8M image Apr 22 21:31:27 khem: thats a good idea. Apr 22 21:31:40 khem: I could probably port to 2.6.25 pretty easy. Apr 22 21:32:15 khem: the only reason I'm hesident to port the kernel is our system is rock solid stable and has a good track record :-) Apr 22 21:40:56 anyone around feel like testing https://gist.github.com/79060efd21592099dc02 for me? Apr 22 21:41:01 just want to confirm sanity before i push it Apr 22 21:56:12 hi BlindMan Apr 22 21:56:20 hi bluelightning Apr 22 21:56:22 ^^ Apr 22 21:57:25 khem: ping Apr 22 22:14:29 ant__: whats up Apr 22 22:15:18 hey..survived to vulcanos? Apr 22 22:16:02 I tried to compile minimal with MACHINE = "collie" and build errors out with: bb.fatal("DISTRO requested EABI but selected machine does not support EABI") Apr 22 22:16:11 ant__: yes :) Apr 22 22:16:16 Being that default compiler is gcc 4.4.2 I added armv4 in sane-toolchain.inc Apr 22 22:16:24 flew over half the continents Apr 22 22:16:32 he Apr 22 22:16:40 so..my hack was: Apr 22 22:16:44 -<------>armv5te iwmmxt armv7a armv7 armv5teb armv4t" Apr 22 22:16:56 +<------>armv5te iwmmxt armv7a armv7 armv5teb armv4 armv4t" Apr 22 22:17:12 is it the right way? Apr 22 22:17:18 ant__: with gcc 4.4 its ok Apr 22 22:17:28 woglinde says there could be more fixes required Apr 22 22:17:32 but is not recommended with older gcc revs Apr 22 22:17:47 ant__: I dont think so Apr 22 22:17:50 yep, Ang* is still in 4.3 sleep Apr 22 22:18:20 K* says 4.4 is producing horrible/slower binaries Apr 22 22:18:47 no probs with minimal if someone fixes sane-toolchain.inc Apr 22 22:18:48 ant__: the results I have are contrary Apr 22 22:18:54 4.4 does a better job for me Apr 22 22:18:58 :D Apr 22 22:19:27 btw I see you pushed 4.5 ! Apr 22 22:19:32 yes I did Apr 22 22:19:37 feel free to test it Apr 22 22:19:48 I have tested it on arm x86 and mips Apr 22 22:19:49 will do Apr 22 22:20:06 thumb or arm ? Apr 22 22:20:14 ant__: thumb Apr 22 22:20:16 ok Apr 22 22:20:32 thx Apr 22 22:21:09 with minimal PREFERRED_GCC_VERSION_local = "4.5.0" in your local.conf should select it for you Apr 22 22:22:19 I think adding armv4 to EABI supported arches in sane-toolchain.inc should be proposed to ml but it will mean that older gcc revs are ignored Apr 22 22:22:49 fwiw the collie kernel I built doesn't boot :/ Apr 22 22:23:03 surely bad config / my bad Apr 22 22:23:24 (I blindly build w/out having that machine) Apr 22 22:23:42 ant__: I know few folks got armv4 arch working on OE with EABI/gcc4.4.2 Apr 22 22:23:47 because I fixed gcc for them Apr 22 22:23:55 yea, woglinde has simpad on eabi Apr 22 22:24:06 ah Apr 22 22:24:09 there you go Apr 22 22:24:19 actually his kid has... Apr 22 22:24:24 heh Apr 22 22:35:18 khem, ant__: either of you guys mind applying https://gist.github.com/79060efd21592099dc02 and just running a do_fetch of something, to check sanity? :) Apr 22 22:37:02 I've seen it in the ML Apr 22 22:37:10 kergoth: let me try it Apr 22 22:37:14 honestly not bothered to read it... Apr 22 22:37:35 khem: thanks Apr 22 22:37:46 the original commit got applied, and then had to be reverted due to shit blowing up :) Apr 22 22:37:51 so figured i'd be a bit more cautious this time around Apr 22 22:38:02 kergoth: wise thing to do :) Apr 22 22:38:19 kergoth: do you have a user branch I can cherry pick from Apr 22 22:38:40 I can try plain old diff Apr 22 22:39:37 khem: checksum branch of http://github.com/kergoth/OpenEmbedded.git Apr 22 22:39:47 * kergoth avoids putting topic branches on the main git server due to the limitations about deleting them Apr 22 22:41:24 * ant__ notes psplash has still the old OE logo... Apr 22 22:41:44 (minimal distro) Apr 22 22:41:51 ant__: hmmm Apr 22 22:42:29 striding with our kernel bootlogo...the last one ;) Apr 22 22:42:33 ant__: which pslash does it chose Apr 22 22:42:47 the OE one Apr 22 22:43:02 there are like three recipes which provide psplash Apr 22 22:43:16 he Apr 22 22:43:27 kergoth: can bitbake handle .xz archives Apr 22 22:43:40 it isn't bitbake that handles it, its base.bbclass Apr 22 22:43:42 ant__: how about angstrom one ? Apr 22 22:43:43 and someone added it there, yeah Apr 22 22:44:01 khem: angstrom has a separate dir -> overrides Apr 22 22:44:54 we have the new logo in linux-kexecboot Apr 22 22:45:25 qvga and vga Apr 22 22:46:07 ant__: then update the pslash with same too Apr 22 22:46:33 yea...right now I'm timing boot from mtd/jffs2 ;) Apr 22 22:46:47 kergoth: fetch was successful Apr 22 22:46:48 that's how I noticed it Apr 22 22:47:01 khem: k, thanks Apr 22 22:47:16 anything else I should check Apr 22 22:47:26 btw the recipe has checksums in it Apr 22 22:47:35 it does not use the common checksums.ini Apr 22 22:47:52 k Apr 22 22:48:06 if it managed to generate teh sums at all and they don't mismatch, i think we're okay Apr 22 22:48:09 thanks for testing it Apr 22 22:48:17 kergoth: may be I should disable checksums and then see if the fetch fails Apr 22 22:48:29 could try it Apr 22 22:50:25 kergoth: http://pastebin.com/vtia6pni Apr 22 22:50:32 seems good to me Apr 22 22:50:47 you have my Tested-by and Acked-By :) Apr 22 22:52:31 kergoth: hmmm now when I reintroduce the checksums in recipes it errors out again wierd Apr 22 22:53:31 I thought now it should succeed the fetch Apr 22 22:55:32 03Chris Larson  07org.openembedded.dev * r28a068820b 10openembedded.git/classes/ (base.bbclass utils.bbclass): Apr 22 22:55:32 Use the python modules for checksum generation where we can Apr 22 22:55:32 Based on df32920678d15c86897b50b752b937210a01edea. Apr 22 22:55:32 Signed-off-by: Chris Larson Apr 22 22:55:32 Tested-by: Khem Raj Apr 22 22:55:33 Acked-by: Khem Raj Apr 22 22:55:59 kergoth: you were too quick I guess Apr 22 22:56:22 heh, oops. does that behavior also occur without this applied? Apr 22 22:57:09 I am trying Apr 22 22:58:09 problem is that changes to these classed forces a complete parse Apr 22 23:01:18 kergoth: fails in same way Apr 22 23:01:19 weird Apr 22 23:02:38 bitbake -f -c fetch is what I am trying Apr 22 23:03:13 The localpath does not exist Apr 22 23:03:34 why it doesnt note that the tar file is not there so he has to download it first Apr 22 23:04:16 kergoth: seems like another bitbake or base.bbclass bug to me Apr 22 23:04:52 seems so.. what did you do to make it happen again? Apr 22 23:05:23 I rm'ed the tar file Apr 22 23:05:34 then I did this Apr 22 23:05:42 bitbake -f -c fetch gcc-cross Apr 22 23:05:56 where gcc-cross for me is gcc-cross_4.5.0.bb Apr 22 23:06:30 oh I disabled the checksums in gcc-4.5.0.inc first Apr 22 23:06:56 then it downloaded the tar file and barfed about the checksums rightly Apr 22 23:07:17 next step I deleted the tar file and reintroduced the checksums back in gcc-4.5.0.inc Apr 22 23:07:25 then did bitbake -f -c fetch gcc-cross Apr 22 23:07:54 then it did not download the file but went ahead to checksums and which will fail because the tar file is not there Apr 22 23:08:54 same result if I use the recipe directly like this bitbake -f -c fetch -b gcc-cross_4.5.0.bb Apr 22 23:08:54 hmm Apr 22 23:09:34 NOTE: package gcc-cross-4.5.0-r0: task do_fetch: Started Apr 22 23:09:34 NOTE: The localpath does not exist 'src/gcc-4.5.0.tar.bz2' Apr 22 23:09:34 NOTE: Task failed: Checksum of 'ftp://ftp.gnu.org/gnu/gcc/gcc-4.5.0/gcc-4.5.0.tar.bz2' failed Apr 22 23:09:37 NOTE: package gcc-cross-4.5.0-r0: task do_fetch: Failed Apr 22 23:11:21 'src' is your DL_DIR, i assuming? Apr 22 23:11:24 assume Apr 22 23:11:53 yep Apr 22 23:12:28 # OEDIR = "${HOME}/work/oe" Apr 22 23:12:29 DL_DIR = "${OEDIR}/src" Apr 22 23:12:59 odd, wonder why its even getting that far without the file existing Apr 22 23:13:08 yeah Apr 22 23:13:43 and despite noting that file does not exist it should try to download it Apr 22 23:13:56 The localpath does not exist 'src/gcc-4.5.0.tar.bz2' Apr 22 23:14:05 should ask it to go back and fetch it Apr 22 23:17:39 kergoth: can you reproduce it ? **** ENDING LOGGING AT Fri Apr 23 02:59:56 2010