**** BEGIN LOGGING AT Wed Feb 13 02:59:57 2008 Feb 13 05:31:23 * wick900c is away: afk Feb 13 09:14:47 morning Feb 13 09:22:50 good morning Feb 13 09:28:57 good morning Feb 13 09:29:03 How do I make a patch for a non-kernel recipe apply only for 2.6 kernels? SRC_URI_$whatoverride ? Feb 13 09:29:15 SRC_URI += '${@base_version_less_or_equal("KERNEL_VERSION", "2.6.8", "file://tslib-input_raw-grab_events.patch;patch=1", "", d)}' Feb 13 09:29:16 no such override Feb 13 09:29:34 Laibsch: how many 2.4 targets we have? Feb 13 09:29:36 I had figured the above SRC_URI line should do it, but in fact, it errors out Feb 13 09:29:44 hrw: Don't know Feb 13 09:29:52 I only know about Sharp-ROM Feb 13 09:30:15 And I have found a solution for checking DISTRO for sharprom-compatible Feb 13 09:30:28 But I am unsure other distros don't use 2.4, either Feb 13 09:31:02 hrw: +SRC_URI += '${@base_conditional("DISTRO", "sharprom-compatible", "", "file://tslib-input_raw-grab_events.patch;patch=1", d)}' Feb 13 09:31:10 you think that is the better solution? Feb 13 09:31:14 That one works Feb 13 09:32:11 and it ugly Feb 13 09:32:25 hrw: I am open to better suggestions Feb 13 09:32:29 why is it ugly? Feb 13 09:32:40 it is distroizm Feb 13 09:32:45 You think SRC_URI_sharprom-compatible is better? Feb 13 09:33:22 maybe time for DISTRO_KERNEL_MAJOR_VERSION = 2.4/2.6? Feb 13 09:33:28 Well, take a look at Feb 13 09:33:31 !oebug 2199 Feb 13 09:33:32 * * Bug 2199, Status: NEW, Created: 2007-05-01 13:48 Feb 13 09:33:33 * * : tslib fails do_compile for Sharp ROM Feb 13 09:33:34 * * http://bugs.openembedded.org/show_bug.cgi?id=2199 Feb 13 09:33:42 and feel free to suggest a better solution Feb 13 09:34:26 comment 2 seems to correctly suggest the patch should only be applied to 2.6 kernels Feb 13 09:34:37 Which is why I wanted to do that Feb 13 09:34:42 It is more correct Feb 13 09:35:28 hrw: maybe you can comment on my "push'em"-RFC Feb 13 09:36:56 Laibsch: sharprom-compatible use which linux-libc-headers? Feb 13 09:37:04 EVIOCGRAB is defined in 2.6 ones Feb 13 09:37:23 and for 2.4 userspace 2.6 headers can be used Feb 13 09:39:14 we did it in OZ Feb 13 09:39:59 hrw: all the better Feb 13 09:40:08 I need to check on the libc-headers Feb 13 09:40:32 PREFERRED_PROVIDER_virtual/linux-libc-headers = "sharprom-toolchain-native" Feb 13 09:41:08 then check Feb 13 09:41:18 I guess it is taken from http://handhelds.org/download/projects/toolchain/archive/cross-2.95.3.tar.bz2 Feb 13 09:41:23 yes Feb 13 09:41:56 Does that answer the question? Feb 13 09:42:04 * Laibsch is unsure how to deal with this, then Feb 13 09:43:33 use that toolchain but use linux-libc-headers 2.6 Feb 13 09:44:53 hrw: remove "virtual/linux-libc-headers " from PROVIDES in packages/sharprom-toolchain/sharprom-toolchain-native_1.0.bb ? Feb 13 09:45:12 Or include the header files in the tslib bb file? Feb 13 09:45:18 Or something else entirely Feb 13 09:45:28 Sorry, I am not so proficient here Feb 13 09:47:03 remove line Feb 13 09:47:15 w8 Feb 13 09:47:29 change PREFERRED_PROVIDER_virtual/linux-libc-headers in sharprom-compatible.conf Feb 13 09:47:54 you mean, add such a line? Feb 13 09:48:08 hi ssvb Feb 13 09:48:24 Laibsch: change that one to linux-libc-headers Feb 13 09:48:34 hello Feb 13 09:48:56 hrw, OK, I'll give it a try. Thanks Feb 13 09:49:08 hi hrw Feb 13 09:56:58 hrw: I guess we need to change something else. Just changing the preferred provider did not yet fix the compilation failure for tslib Feb 13 09:57:04 It remained the same Feb 13 09:57:45 Maybe tslib needs to DEPENDS on linux-libc-headers? Feb 13 09:58:45 Yes, that results in a successful compilation Feb 13 10:05:06 03pfalcon 07org.oe.dev * r1e069dfa... 10/ (26 files in 26 dirs): Feb 13 10:05:06 linux-handhelds-2.6 2.6.21-hh20: Use noop iosched by default, make other modular. Feb 13 10:05:06 * Per discussion on ML. Feb 13 10:05:06 * defconfigman r440. Feb 13 10:05:26 03pfalcon 07org.oe.dev * r16ce3628... 10/ (5 files in 3 dirs): gpe-login, keylaunch: Annotate patches submitted upstream as RFCed on the list. Feb 13 10:20:05 * * OE Bug 3768 has been created by Feb 13 10:20:07 * * SharpROM-compilation emits long (but harmless?) errors when compiling Feb 13 10:20:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3768 Feb 13 10:38:28 good morning Feb 13 10:46:32 good morning Feb 13 10:47:17 hrw: with PREFERRED_PROVIDER_virtual/linux-libc-headers = "linux-libc-headers" instead of sharprom-toolchain-native, should sharprom-toolchain-native now DEPENDS on linux-libc-headers? Feb 13 10:47:44 a built from scratch of tslib does not build linux-libc-headers and thus still fails Feb 13 10:48:07 but for other DISTROs, linux-libc-headers is built automatically as a dependency of glibc Feb 13 10:49:34 no it should not Feb 13 10:49:54 what do you suggest instead? Feb 13 10:50:01 hm.. then it should depend on virtual/linux-libc-headers (sharprom-toolchain-native I mean) Feb 13 10:51:23 OK, fair enough Feb 13 10:51:54 hrw: But that is a bit strange since sharprom-toolchain-native also PROVIDES virtual/linux-libc-headers Feb 13 10:52:46 I know Feb 13 11:26:05 03mickeyl 07org.oe.dev * rdb9d94dd... 10/ (6 files in 3 dirs): udev: update to 118, remove noasmlinkage patch in favour of 'sed' Feb 13 11:26:12 03mickeyl 07org.oe.dev * rbb7fd700... 10/ (5 files in 3 dirs): Feb 13 11:26:12 gconf-dbus: update svn version to rev 641, remove cvs version Feb 13 11:26:12 * this makes it work with dbus 1.1.x Feb 13 11:26:22 03mickeyl 07org.oe.dev * r054216fc... 10/ (4 files in 2 dirs): gconf-dbus svn remove obsolete patches Feb 13 11:26:31 03mickeyl 07org.oe.dev * r90c9a3c5... 10/ (1 conf/distro/include/preferred-om-2008-versions.inc): preferred-om-2008-versions: switch to bb 1.7.2, udev 118, dbus 1.1.4 Feb 13 11:26:37 03Laibsch 07org.oe.dev * rf3ae86a7... 10/ (9 files in 3 dirs): tslib: consolidate, taking extra care 0038f02055e33a3dad0ba914de112ce9450c45d4 is dealt with properly Feb 13 11:48:05 * * OE Bug 3769 has been created by christian.glindkamp(AT)taskit.de Feb 13 11:48:06 * * vsftpd.postinst fails while building root filesystem image Feb 13 11:48:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3769 Feb 13 12:04:51 03mickeyl 07org.oe.dev * r8e9b95fb... 10/ (4 files in 3 dirs): Feb 13 12:04:51 gst-plugin-pulse 0.9.7 add patch reducing 20% of the load due to some busylooping Feb 13 12:04:51 NOTE: need to play more with that to find out whether we can get even more Feb 13 12:04:54 03mickeyl 07org.oe.dev * reac7ec53... 10/ (1 conf/distro/include/preferred-om-2008-versions.inc): preferred-om-2008-versions: update more software, pulseaudio 0.9.9 / gst-pulse 0.9.7 now works Feb 13 12:21:05 * * OE Bug 2199 has been RESOLVED (FIXED) by Feb 13 12:21:07 * * tslib fails do_compile for Sharp ROM Feb 13 12:21:09 * * http://bugs.openembedded.org/show_bug.cgi?id=2199 Feb 13 12:29:07 RP: ant just pointed out to me that gentoo apparently patched 2.6.23 for the exploit Feb 13 12:29:11 http://www.gentoo-portage.com/sys-kernel/gentoo-sources/ChangeLog#ptabs Feb 13 12:29:32 I don't see this with the same priority for embedded systems as it is for desktop and servers Feb 13 12:42:24 03Laibsch 07org.oe.dev * r91ff2149... 10/ (3 files in 3 dirs): Sharp ROM stuff: include latest linux-libc-headers by default. Closes 2199. Feb 13 12:59:59 mickey|flu: is busybox setuid ? Feb 13 13:01:56 hrw: SharpROM has a circular dependency now Feb 13 13:02:03 So, this won't work Feb 13 13:03:36 ade|desk: newer busybox can have file with list of setuids Feb 13 13:03:39 Laibsch: ;( Feb 13 13:05:40 ah things have improved :) Feb 13 13:10:42 did nto tested Feb 13 13:14:41 hrw: what can we do to solve the circle? Feb 13 13:19:04 Laibsch: I would remove PROVIDE from sharprom toolchain recipe Feb 13 13:21:58 hrw: Then it tries to build external toolchain which fails Feb 13 13:22:17 Maybe this can be solved with some more pinning Feb 13 13:25:33 hrw: I assume linux-libc-header bb files should include a "PROVIDES = 'virtual/linux-libc-headers'" line Feb 13 13:25:43 probably Feb 13 13:26:17 I guess this is pretty basic stuff Feb 13 13:26:23 Does that need an RFC? Feb 13 13:26:40 I would add Feb 13 13:27:33 OK Feb 13 13:33:41 hrw: The downside is that SharpROM is now compiling the whole glibc Feb 13 13:34:05 Just for excluding a patch that is unneeded for 2.4 kernels Feb 13 13:37:28 then soemthing is wrong Feb 13 13:37:40 it should take sharpromtoolchain as glibc Feb 13 13:38:07 guys, does anyone know if uclinux requires a specific toolchain, or if it is just a matter of kernel configuration? Feb 13 13:38:10 let me inspect -g Feb 13 13:38:34 can the toolchain that is produced by OE generate flat format stuff or do I need to create my own? Feb 13 13:46:32 monotone.openembedded.org will be unreachable for a short while due to kernel update Feb 13 13:46:38 use one of the mirrors Feb 13 13:48:26 hrw: I cannot understand from http://rafb.net/p/1kXPfj84.html why glibc is being pulled in Feb 13 13:48:37 mickey|flu, zecke: Could oen of you bring up the tunnel again? Feb 13 13:49:01 I'm on the run :} Feb 13 13:49:11 zecke: ok - many thanks! Feb 13 13:49:19 There are some messages initially about "ERROR: Multiple .bb files are due to be built which each provide virtual/arm-linux-libc-for-gcc (/home/laibsch/work/org.openembedded.dev/packages/sharprom-toolchain/sharprom-toolchain-native_1.0.bb /home/laibsch/work/org.openembedded.dev/packages/glibc/glibc_2.2.5.bb)." Feb 13 13:49:20 *sorry* Feb 13 13:49:26 bbl Feb 13 13:50:03 it was worth a try ;-) Feb 13 13:50:13 hrw: But I don't know which feature is provided by glibc that is not provided by sharprom-toolchain Feb 13 14:39:04 morning Feb 13 14:52:54 hi to all Feb 13 14:54:01 can anyone help out on a problem i have with adding a package ? Feb 13 14:54:07 (to OE) Feb 13 14:57:18 hi Feb 13 14:57:28 hi woglinde Feb 13 14:59:51 Laibsch: does sharprom-toolchain-native provide virtual/arm-linux-libc-for-gcc? Feb 13 15:00:22 Laibsch: "bitbake -g strace" is better check - less deps Feb 13 15:01:01 hrw: no, it does not Feb 13 15:01:07 I guess you suggest it should ;-) Feb 13 15:01:12 I'll give it a shot Feb 13 15:01:13 Thanks Feb 13 15:05:40 hrw: I'd say it looks good now http://rafb.net/p/CWu0OE59.html Feb 13 15:05:44 for strace at least Feb 13 15:07:14 hrw: dependency chart for python-pyqt is still the same, though Feb 13 15:09:13 ;( Feb 13 15:34:02 hi flo Feb 13 15:34:53 re Feb 13 15:37:05 * * OE Bug 3770 has been created by Feb 13 15:37:07 * * trim down anki packages Feb 13 15:37:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3770 Feb 13 15:51:57 hey all, is it possible to have bitbake -c devshell drop to a bash prompt, not spawn a terminal? Feb 13 15:59:18 Tartarus: ask RP Feb 13 16:04:23 Tartarus: it is not iirc Feb 13 16:06:51 damn :( Feb 13 16:07:06 Got a bunch of remote guys and I wanted them to use that if possible Feb 13 16:17:36 nokias free software policy is really just #$§!* Feb 13 16:17:52 rschuster: their what? :D Feb 13 16:18:37 their "release sources in 3.2 but make it proprietary in 4.0" policy ;) Feb 13 16:19:09 thats pretty troublesome for OE where everything is and wants to be built from source Feb 13 16:20:10 rschuster: were has Nokia stated that 4.0 is proprietary? Feb 13 16:20:28 hi rschuster Feb 13 16:20:32 as lots of the suff is GPL they cannot keep the sources for themselves anyway. Feb 13 16:20:53 philippe: its rather XY was open in 3.2 and is closed now Feb 13 16:21:07 yeah Feb 13 16:21:24 rschuster: ah ok. Which XY are you talking about? Feb 13 16:21:26 this happened to gpsbt and gpsmgr which we have in OE and which I wanted to upgrade ... Feb 13 16:21:40 as well as osso-ic Feb 13 16:22:30 * hrw would like to get sources of everything i18n related... Feb 13 16:22:47 * philippe wonders if osso-ic was replaced by something else... Feb 13 16:24:17 anyway time to annoy some people about that Feb 13 16:28:12 philippe: the source package was called osso-ic-oss in 3.2, their differences table said its gone Feb 13 16:28:13 (http://repository.maemo.org/stable/chinook/3.2_vs_4.0_content_comparison.html) Feb 13 16:28:23 philippe: however dpkg --status cannot be fooled. ;) Feb 13 16:29:02 ii osso-ic 1.2.31 Internet Connectivity Daemon Feb 13 16:29:10 n810/2007.50.2 Feb 13 16:29:44 hrw: right, same on n800 Feb 13 16:29:54 same image for both Feb 13 16:30:22 I wonder what is so special about this library. I mean they have a separate osso-ic-wlan whose source is free :$ Feb 13 16:30:42 maybe it is a mistake... Feb 13 16:31:25 philippe: good point. I wrote a mail to the osso-ic maintainer already :) Feb 13 16:32:39 rschuster: I would say 'report bug' but it does not warrant response Feb 13 16:36:26 * philippe should keep an eye on the stuff that Nokia releases and does not release Feb 13 16:36:35 so I could bug everybody internally Feb 13 16:37:52 philippe: curse i18n team from me Feb 13 16:38:18 and n810 hardware keyboard designer too (for two lshift keys instead of lshift and rshift) Feb 13 16:38:38 hrw: you should know how often we curse those people already internally Feb 13 16:39:24 philippe: you can know that at OH I do not do any nokia related things Feb 13 16:39:51 hrw: I know. Feb 13 16:40:33 I hope that it will stay that way Feb 13 16:40:50 hrw: what I said had to be understood as : we curse those hw designers a lot already Feb 13 16:40:53 as I do not have luck when it comes to nokia products Feb 13 16:40:57 philippe: I know ;D Feb 13 16:41:02 but the ipr and legal departements are the worst Feb 13 16:42:05 philippe: how goes testing of fix for maemo #2763 (power on drama)? Feb 13 16:42:11 my n810 waits for fix... Feb 13 16:49:28 hi ph5 Feb 13 16:49:50 hi Feb 13 16:53:10 * hrw -> afk Feb 13 16:53:16 gotta go. Feb 13 16:54:05 * * OE Bug 3771 has been created by Feb 13 16:54:07 * * tk fails do_configure for SharpROM Feb 13 16:54:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3771 Feb 13 16:57:50 re robert Feb 13 17:08:03 * * OE Bug 3772 has been created by Feb 13 17:08:05 * * SharpROM sometimes compiles glibc which it shouldn' t really do Feb 13 17:08:07 * * http://bugs.openembedded.net/show_bug.cgi?id=3772 Feb 13 17:13:34 hrw: the glibc problem was not introduced by our recent work Feb 13 17:13:42 It has been there before Feb 13 17:28:12 bye Feb 13 19:14:17 bonne soirée / happy halloween Feb 13 19:39:46 hi zecke, Laibsch, hrw, everyone Feb 13 19:40:04 hi likewise Feb 13 19:49:25 ant_: When you boot lnux-rp 2.6.24 do you get a warning from clock_disable() ? Feb 13 20:38:36 hvontres|work: re Feb 13 20:39:01 hvontres|work: recompiling now (standard defconfig) Feb 13 20:40:59 hvontres|work: mtn log packages/linux/linux-rp-2.6.23/defconfig-c7x0 --diffs |less Feb 13 20:41:12 hvontres|work: shows only minor changes... Feb 13 20:42:28 hvontres|work: BTW latest 2.6.23 working seems to be Revision: e544e6520a227daffc4fabe13941ec879c7adf7b Feb 13 20:43:21 Author: pfalcon@openembedded.org Feb 13 20:43:41 Date: 2007-12-26T16:10:21 Feb 13 20:47:33 hi everybody Feb 13 20:47:41 hi thesing Feb 13 20:49:53 hi guys Feb 13 20:55:41 cbrake: Did you ever find a fix for the uclibc eabi alignment trap problems you saw? Feb 13 20:55:53 RP: good news with stock linux-rp-2.6.24-r3! Suspend/resume reboot issues have disappeared ! Feb 13 20:56:02 RP: no, I never did track that down. Feb 13 20:56:05 ant_: great Feb 13 20:56:11 hrw|gone: ping Feb 13 20:56:13 RP: or it looks like...testing right now Feb 13 20:56:42 RP: I'm only using the eabi in a minimal updater rootfs, so performance was not real critical, and I've been consumed with other project issues :-\ Feb 13 20:56:59 *uclibc that is ... Feb 13 20:57:01 cbrake: I'm trying to fix up the cm-x270 support in poky and your blog has been very helpful, thanks ;-) Feb 13 20:57:09 RP: great! Feb 13 21:01:47 ..NOTE: preferred version 115 of udev not available...thath's fresh from today...! Feb 13 21:02:28 hmm Feb 13 21:02:40 I wonder if mickey|flu forget to cehck in something Feb 13 21:02:57 I saw him bump the prefered version in the openmoko file Feb 13 21:07:09 relocation error: /usr/lib/libsigproc.so.0: symbol __floatsisf, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference Feb 13 21:07:15 any thoughts? Feb 13 21:08:15 Crofton|work: about udev: http://lists.linuxtogo.org/pipermail/openembedded-commits/2008-February/012382.html Feb 13 21:09:13 urh Feb 13 21:09:29 mickey|flu, deleted 115 and replaced it with 118 Feb 13 21:09:39 angstrom sane srcrevs is likely 115 Feb 13 21:10:05 bad flu! Feb 13 21:10:11 hi crofton Feb 13 21:10:46 hi Feb 13 21:10:53 ant_: 2.6.23 works for me on poodle, but 2.6.24 does not resond to power button :( Feb 13 21:11:40 hvontres|work: eek...stuck at gpe-login stupid loop..let me retry with console-image Feb 13 21:12:17 hvontres|work: damn, power button shut off but now won't resume Feb 13 21:14:05 hvontres|work: did you try my patch? Feb 13 21:15:13 thesing: not yet. i want to get 2.6.24 working normaly first. Feb 13 21:15:37 thesing: plus, I have a bunch of projects around the house to keep me busy :) Feb 13 21:16:07 Hi, I'm having trouble compiling Angstrom with uclibc for x86, is this the right place to seek help? Feb 13 21:17:10 pardsbane: yes. But not many people compile for x86. Feb 13 21:17:21 pardsbane: Whats your problem? Feb 13 21:18:35 hum. Ok, well, in short, I'm building on an x86_64 Ubuntu box, and when I run 'bitbake nano', I get: "/bin/sh: i486-angstrom-linux-uclibc-gcc: not found" when trying to do_configure uclibc. Feb 13 21:19:28 pardsbane: do you have bash as /bin/sh ? Feb 13 21:20:14 I'm using angstrom-2007.12-stable if it matters, and I have ANGSTROM_MODE = "uclibc" / TARGET_OS = "linux-uclibc" / MACHINE = "x86" Feb 13 21:20:24 thesing: I'll check. Feb 13 21:20:37 hvontres|work: the latest 2.6.23 with no evident issues for c7x0 is the one I listed above, the last without ATAGS Feb 13 21:20:56 Ok, on ubuntu, /bin/sh is a link to /bin/dash Feb 13 21:21:05 Is that a problem? Feb 13 21:21:13 pardsbane: yes Feb 13 21:21:47 pardsbane: run "dpkg-reconfigure dash" Feb 13 21:22:14 pardsbane: and you shouldn't set TARGET_OS. Feb 13 21:22:27 yepp Feb 13 21:22:34 only angstroemmode Feb 13 21:22:53 ANGSTROM_MODE= "uclibc" Feb 13 21:23:00 ok Feb 13 21:23:18 what is the role of TARGET_OS? Feb 13 21:23:42 hm Feb 13 21:23:47 some relict Feb 13 21:24:20 ant_: is that linux-rp-2.6.23 r27? Feb 13 21:24:57 hvontres|work: no, I think was r16 (angstrom-2007.12-stable) Feb 13 21:25:24 hvontres|work:RP I've collected the bootlogs of vanilla linux-rp-2.6.24-r3 on c7x0 Feb 13 21:25:36 hvontres|work:RP: posting now Feb 13 21:25:38 What do I need to do to create my own custom 'profile' (list of packages to install, etc)? What I'm trying to do is move my embedded linux build from a custom build system I wrote around the Gentoo Embedded project to Open Embedded, I'm hoping it will be more stable. Feb 13 21:26:43 pardsbane: write a new image. Feb 13 21:27:46 thesing: is that a distro? Feb 13 21:28:07 no Feb 13 21:28:18 image is image distro is distro Feb 13 21:28:18 a distro defines what versions to use and some other policies. Feb 13 21:28:36 a image decides what packages end up in an image. Feb 13 21:28:40 ah ok. Feb 13 21:29:04 so you mean a replacement for "bootstrap-image", like "my-image" Feb 13 21:29:20 yes. Feb 13 21:29:20 right Feb 13 21:30:40 cool. in the OE checkout, those files go in org.openembedded.../packages/images... can I put mine in .../build/packages/images since my build directory is on BBPATH? Feb 13 21:32:23 hvontres|work: http://rafb.net/p/eZmnJF37.html Feb 13 21:32:35 hvontres|work: yes, warnings Feb 13 21:32:58 pardsbane: I think you need to add it to BBFILES in local.conf to. But I'm not sure. Feb 13 21:33:16 there is a section about overlays in the oe manual. (I think) Feb 13 21:33:57 RP: typo Using static partision definition Feb 13 21:34:29 ant_: Yes, that is the Warning I was seeing too. I wonder if that has anything to to with the resume failure Feb 13 21:34:33 thesing: Ok, thats what I was looking for, like gentoo's portage overlays. Feb 13 21:34:43 I'll look in the manual. Feb 13 21:35:09 hvontres|work: at least it reboots ;-) Feb 13 21:35:56 hvontres|work: there were changes to sharpsl_pm (c/h) Feb 13 21:37:01 pardsbane: http://www.openembedded.org/user-manual&dpage=special_bitbake_collections Feb 13 21:37:21 not much description but you should get the idea. Feb 13 21:37:47 ant_: hmmm.. http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.24-rc1-git12.log claims that was fixed in 2.6.24-rc1 Feb 13 21:37:53 thesing: Thats enough to get started, thanks Feb 13 21:37:59 hvontres|work: confirmed: 2.6.24 does suspend but doesn't resume Feb 13 21:38:50 hvontres|work: I start doubting about apmd scripts... Feb 13 21:39:24 so I fixed the bash/dash issue, but I still see "make: i486-angstrom-linux-uclibc-gcc: Command not found" (same problem) Feb 13 21:39:27 hvontres|work: power man was working beautifully till end of december (angstrom stable) Feb 13 21:39:55 hvontres|work: and defconfigs only had minor changes (modularized) Feb 13 21:40:22 pardsbane: did you remove the TARGET_OS stuff? Feb 13 21:40:42 hvontres|work: perhaps RP 's kernel is just victim of bad scripts.... Feb 13 21:41:02 ant_: so far 2.6.23 has worked pretty well for me. 2.6.24 hasn't yet. And I have no clue how to possibly debug this Feb 13 21:41:46 hvontres|work: you mean on collie 2.6.23-r27 is ok? Feb 13 21:41:52 thesing: Yes. Do I need to clean or rm tmp? I just re-ran 'bitbake nano' after changing local and fixing bash. Feb 13 21:42:09 pradsbane bitbake nano is enough Feb 13 21:42:57 ok, well I'll re-run it just to be sure, but I think something else is still wrong. Feb 13 21:44:19 pardsbane: does it build gcc-initial and friends? Feb 13 21:46:10 ant_: poodle Feb 13 21:46:24 hvontres|work: ok, but not c7x0... Feb 13 21:47:59 thesing: I'm not sure how to tell Feb 13 21:49:01 there is a /tmp/cross/i486-angstrom-linux-uclibc and one in staging as well, but they seem to be empty Feb 13 21:49:15 those are the only things in cross and staging though, no other packages Feb 13 21:50:05 oh, I take that back, there is a /tmp/x86_64-linux/ which appears to have a real GCC built in it. Feb 13 21:51:16 oh, no, it has the autoconf tools and gettext, flex, and bison, but no gcc. Feb 13 21:51:59 do you have the PREFERRED_PROVIDER lines in local.conf? Feb 13 21:52:13 yeah, the defaults Feb 13 21:52:28 PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial" Feb 13 21:52:28 PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross" Feb 13 21:52:48 (and the g++ one) Feb 13 21:53:13 can you execute the gcc in cross/bin ? Feb 13 21:54:56 one sec Feb 13 21:54:59 morning all Feb 13 21:55:05 hi fique Feb 13 21:55:16 hello woglinde Feb 13 21:55:32 I rm tmp, so could rerun and tee the complete output to a file incase I missed anything. I'll rerun it and let you know Feb 13 21:58:03 is there something wrong with bugzilla? Feb 13 21:58:52 dcordes: try bugs.openembedded.net Feb 13 21:59:30 thesing: I do. get redirected to http://72.233.35.82/ and can't login Feb 13 22:00:51 dcordes: I get redirected too, but I can login. Feb 13 22:01:14 thesing: ah just noticed it works when I go to Log In in the top menu Feb 13 22:01:19 guess it is my browser Feb 13 22:07:43 #/nick likewise Feb 13 22:09:33 thesing: you asked if I could run the gcc in cross, but there isn't one there. Feb 13 22:09:52 no i486-*-gcc? Feb 13 22:10:29 if not did bitbake build gcc-initial? Feb 13 22:11:11 there is a cross/i486-angstrom-linux-uclibc, but it only has include and lib symlinks to tmp/staging Feb 13 22:12:40 I'll try gcc-initial, the only thing of 'meat' in tmp is staging/x86_64-linux, and there are all the build tools in there up to but not including gcc Feb 13 22:12:53 IE, automake, autoconf, bison, flex are all in there, but no gcc code Feb 13 22:13:43 thesing: Did you want me to run 'bitbake build gcc-initial' or 'bitbake gcc-initial'? Feb 13 22:14:06 oh, I missread what you said, nm Feb 13 22:15:09 I see this in the logs:NOTE: multiple providers are available for virtual/i486-angstrom-linux-uclibc-li Feb 13 22:15:09 bc-for-gcc (uclibc, external-toolchain); Feb 13 22:15:09 NOTE: consider defining PREFERRED_PROVIDER_virtual/i486-angstrom-linux-uclibc-li Feb 13 22:15:09 bc-for-gcc Feb 13 22:16:23 pardsbane dont worry Feb 13 22:16:26 only warning Feb 13 22:19:48 woglinde: thats what I thought, but its not building uclibc because it can't find the right gcc. Feb 13 22:20:58 I wonder if it is a bootstrapping issue, like it needs uclibc to build gcc, but it needs gcc to build uclibc. But I don't understand why its looking for the i486-uclibc gcc yet, when it hasn't even build the uclibc. Feb 13 22:21:25 pardsbane: try "bitbake gcc-initial" Feb 13 22:22:01 ERROR: Nothing PROVIDES 'gcc-initial' (but '[]' DEPENDS on or otherwise requires it) Feb 13 22:23:15 pardsbane: we build gcc-initial first then glibc-intermediate then gcc-cross and then glibc. I don't know how it's with uclibc. But it will be similar. Feb 13 22:23:38 thesing gcc-cross on x86? Feb 13 22:23:44 when you have x86 Feb 13 22:24:00 woglinde: I think for oe it's all the same. Feb 13 22:24:46 pardsbane: do you get the same error if you use glibc? Feb 13 22:25:59 hum, let me try Feb 13 22:27:25 btw, here are some settings displayed when I tried to bitbake gcc-initial: TARGET_ARCH = "i486" Feb 13 22:27:25 TARGET_OS = "linux-uclibc" Feb 13 22:27:25 MACHINE = "x86" Feb 13 22:27:25 DISTRO = "angstrom" Feb 13 22:27:25 DISTRO_VERSION = "2007.12-r3" Feb 13 22:27:47 * ant_ stumbled in two new bug candidates: /dev/.udev/rules.d No such file or directory... adduser: unrecognized option "--disabled-password" this one could explain the gpe-login loop Feb 13 22:28:01 ant urgs Feb 13 22:28:06 I'm not setting TARGET_OS, so that must come from Angstrom. I commented out ANGSTROM_MODE=uclibc and I'll try again. Feb 13 22:28:07 maybee the udev update? Feb 13 22:28:18 yes, I fear Feb 13 22:30:54 hi khem Feb 13 22:31:12 woglinde: hello Feb 13 22:34:45 thesing: I get the same error when I comment out the ANGSTROM_MODE line Feb 13 22:34:58 (ie, I'm using glibc, as far as I can tell) Feb 13 22:35:21 if you have TARGET_OS = linux you use glibc Feb 13 22:35:26 oh yeah, TARGET_OS is now 'linux' instead of 'linux-uclibc' Feb 13 22:36:50 pardsbane: try "bitbake gcc-cross-initial" Feb 13 22:37:04 hvontres|work: it is not only the power button: 'apm --suspend' put the Zaurus in unrecoverable state Feb 13 22:37:13 ok Feb 13 22:37:27 nick cbrake_away Feb 13 22:38:52 ant_: actually, right now the power button dosn't suspend the poodle in 2.6.23 either... as a matter of fact, the 2.6 kernels never did.. Feb 13 22:39:27 ant_: the main difference i see with 2.6.23 vs 2.6.24 is that the poser button can wake up in 2.6.23 and not 2.6.24 Feb 13 22:39:31 hvontres uh Feb 13 22:40:07 hvontres|work: and the boot warnings Feb 13 22:42:32 hvontres|work: was working two days ago with CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS is not set Feb 13 22:42:49 hvontres|work: and the same warnings Feb 13 23:18:16 thesing: are you still online? Feb 13 23:18:27 yes Feb 13 23:18:58 so, I tried gcc-cross-initial and it works with glibc but not with uclibc Feb 13 23:19:22