**** BEGIN LOGGING AT Tue Jan 31 02:59:56 2006 Jan 31 03:00:03 device is suspended. i will sleep, and in the morning time, try to resume Jan 31 03:00:15 'nite and thanks for all the advices Jan 31 03:01:32 shadows: np. 'night Jan 31 03:03:04 RP: feel like reviewing a change for the package.bbclass problem? http://pastebin.ca/39222 Jan 31 03:12:23 jbowler: Did you see my comments about file permissions on oe@ ? Jan 31 03:13:08 Yes, that's easy to add now there is a script... one moment. Jan 31 03:16:17 strip returns 0 even if it failed to strip a Jan 31 03:16:17 binary Jan 31 03:16:28 That was a comment made by rene? Jan 31 03:26:32 The only thing I can reproduce is that it returns 0 if the executable is already stripped, but then some executables come that way (busybox is stripped in the build directory). Jan 31 03:26:46 On a shell script I get 1 (as expected). Jan 31 03:27:26 ok Jan 31 03:31:09 jbowler: That change looks good to me Jan 31 03:31:38 I'll give it some testing if you like but its proabably just as well to check it in Jan 31 03:31:39 His attempt to detect errors would also fail unpredictably if a .bb file set (for example) STRIP=echo Jan 31 03:32:39 I need to check in the file-native change first - I'm testing with both, but a broken file would cause it to spew lots of complaints to /dev/tty Jan 31 03:33:50 Did you track down why your file was the libtool file? Jan 31 03:34:47 I've got a modified version for the 'write' problem - http://pastebin.ca/39225 Jan 31 03:35:13 RP: everyone's file is the libtool one - that's what the file-native .bb file stages! Jan 31 03:35:41 It does a straight copy of src/file from the build directory, and that is always the libtool script Jan 31 03:36:38 My intention is to check both in tomorrow my time (well, later today, about 8 hours time) if there aren't any problems. Jan 31 03:37:44 jbowler: I guess most people just don't have file-native built then... Jan 31 03:38:13 checking in tomorrow sounds good. Thanks for sorting this out :) Jan 31 03:38:15 That's quite likely Jan 31 03:38:30 np Jan 31 03:39:21 file-native only gets built because it is a dependency of 'file' (!) Jan 31 03:39:36 slugos builds file for the native development environment Jan 31 03:40:18 Hi Liam Jan 31 03:40:31 morning Dirk, all Jan 31 03:40:38 hi liam Jan 31 03:40:42 lrg|home: Did you find time to play with tosa? Jan 31 03:41:11 does the Ir port on c7x0 not act as a serial port on 2,6? Jan 31 03:41:24 XorA: It should do Jan 31 03:41:39 do13: not yet, I've managed to break ssp audio on the pxa and I need this working for my trip to China :( Jan 31 03:41:51 RP: hrmmm, trying to get pocketop to work Jan 31 03:42:22 lrg|home: np Jan 31 03:42:46 do13: I'm ready to release 0.10 later tomorrow. I'l send you and RP an email with my plans Jan 31 03:42:51 cat /dev/ttyS1 Jan 31 03:43:12 jbowler-zzz: Just read you email about file-native - your proposed fix sounds good Jan 31 03:43:34 lrg|home: Which version of the kernel is that against? Jan 31 03:44:06 lrg|home: to make 2.6.16-rc1-git4 work, I needed http://www.rpsys.net/openzaurus/patches/alsasoc_fixups-r0.patch Jan 31 03:44:34 RP: it will be against 2.6.16(still todo). Thanks for the patch Jan 31 03:44:54 lrg|home: The other codecs will need similar changes Jan 31 03:45:33 RP: np, thanks. Jan 31 03:46:35 * XorA must be missing something obvious Jan 31 03:48:41 XorA: Do you not need to turn on the irport with irattach or something? Jan 31 03:48:48 * RP knows nothing about the IR port :) Jan 31 03:49:15 RP: well pocketop isnt irda Jan 31 03:49:28 RP: so Ive no idea Jan 31 03:52:28 XorA: The port won't work as a serial port if the tranciever is turned off... Jan 31 03:56:00 RP: hmmm, wonder how to get that turned on then, irattach doesnt Jan 31 04:00:51 XorA: use irda control applet Jan 31 04:01:13 hrw|work: that appears to go walkies on my system, whats it called? Jan 31 04:01:32 XorA: dont know Jan 31 04:02:39 XorA: it use few ioctl() calss Jan 31 04:02:43 calls Jan 31 04:08:52 doesnt help, I can get phone to talk to Irda, but dont seem to be able to get /dev/ttyS1 to produce bytes Jan 31 04:11:01 * Geo_KM is back Jan 31 04:33:34 * Geo_KM is away: Away at the moment Jan 31 05:18:49 hey Jan 31 05:18:54 * zecke suck Jan 31 05:18:57 s Jan 31 05:19:32 hi zecke Jan 31 05:20:00 hi zecke Jan 31 05:21:08 pb_: localegen: as long as the endianess matches you can run localegen on the host? Jan 31 05:21:28 pb_: or does it insist to use /usr/* for storing the locales? Jan 31 05:22:49 zecke: yeah, you can run it on the host as long as the endianness (and word size) match Jan 31 05:23:05 I wish qemu sucked a bit less, then we would have no problem Jan 31 05:23:21 pb_: maybe qemu goes oom? Jan 31 05:23:29 doesn't seem so Jan 31 05:36:58 pb_: any reason to not store BT link keys in /etc/ instead of /var/? Jan 31 05:38:40 morning Jan 31 05:44:19 hrw|work: I guess /etc would be okay Jan 31 05:44:20 hi reenoo Jan 31 05:46:53 hi reenoo Jan 31 05:47:17 reenoo: jbowler is proposing something like http://pastebin.ca/39222 as the solution for the strip issues Jan 31 05:47:28 but probably with file mode handling added Jan 31 05:47:29 ~curse nokia dtl* Jan 31 05:47:31 May you be reincarnated as a Windows XP administrator, nokia dtl* ! Jan 31 05:55:27 hey pb_ Jan 31 05:55:30 hi RP Jan 31 05:55:36 RP: looks a bit bogus Jan 31 05:57:32 zecke: if you wanted to try debugging qemu I could send you a copy of the glibc-package.bbclass bits I was working on. Jan 31 05:57:41 "bitbake qemu-native" will construct an appropriate qemu Jan 31 05:58:09 morning Jan 31 05:58:11 pb_: I fear I do not have enought time Jan 31 05:59:10 zecke: drat Jan 31 06:01:23 <_law_> hrw|work, whats the problem with nokia card? Jan 31 06:02:04 _law_: http://www.hrw.one.pl/2006/01/31/another-nokia-product-which-i-do-not-like/ Jan 31 06:02:10 RP: in particular it ignores strip errors Jan 31 06:02:24 RP: strip returns 0 even on errors Jan 31 06:03:45 _law_: basically: in my Zaurus it behave like plastic placeholder rather then working card Jan 31 06:03:59 <_law_> hrw|work, :-) Jan 31 06:04:14 hrw|work: do you want to try my dtl1 card? Jan 31 06:04:44 zecke: its same driver, same shit Jan 31 06:05:31 I will put it in collie and use instead of plastic placeholder Jan 31 06:13:52 reenoo: I mentioned that earlier and jbowler thought not :-/ Jan 31 06:20:13 RP: as far as the permissions changing is concerned, I don't think I want to silently do that. Jan 31 06:22:49 reenoo: A program has the right to install its binaries in whatever permissions mode it likes Jan 31 06:23:04 reenoo: Whether or not that's correct for a particular package is a different question Jan 31 06:23:27 but sanity checking file permissions with the strip function is a totally broken idea Jan 31 06:24:29 RP: we don't want unstripped binaries in the packages for obvious reasons. Jan 31 06:24:40 reenoo: I agree with that Jan 31 06:24:53 RP: if a .bb really wants readonly binaries it can set IGNORE_STRIP_ERRORS Jan 31 06:25:27 reenoo: That is totally insane. File mode for binaries has nothing to do with stripping Jan 31 06:26:47 Think about it - your idea means no package can have readonly stripped binaries Jan 31 06:29:44 RP: well, how do you want to address that then? Jan 31 06:31:06 changing permissions before/after we run strip will leave the binary writeable for a short time which the user may not want Jan 31 06:31:43 reenoo: Eh? This is on the build system where I really don't think thats an issue Jan 31 06:34:37 <[lala]> hi all Jan 31 06:34:51 <[lala]> is there a nylon specific support channel or is that handled here as well? Jan 31 06:38:59 hi [lala] Jan 31 06:39:06 <[lala]> hi rp Jan 31 06:41:12 <[lala]> RP: i have installed the latest kernel this morning ... can't say much about the white screen yet though :) Jan 31 06:42:23 [lala]: ok :) Jan 31 06:45:40 hi RP, mathew online? Jan 31 06:48:03 greentux_alt: He is around, yes Jan 31 06:48:12 perhaps not on irc Jan 31 06:49:46 RP: ok, email him Jan 31 06:53:20 can anyone help me with building minimo? Jan 31 06:53:53 xumbi: it doesnt build Jan 31 06:53:59 basically I need to be able to build the minimo package from familiar Jan 31 06:54:11 XorA: it doesn't? Jan 31 06:54:23 xumbi: on rare occasions someone gets it to build it doesnt work Jan 31 06:54:24 XorA: well that sucks Jan 31 06:54:44 XorA: well at least I know it's not just me! :) Jan 31 06:56:08 I work for a company that wants to use minimo in one of its products, so I've been tasked with building it Jan 31 06:56:46 I've been trying for about 2 months now with no luck Jan 31 06:57:06 xumbi: chat to the guys on #gpe, they are more familiar than I Jan 31 06:57:58 XorA: ok cool, I'll head over there Jan 31 06:58:13 XorA: thanks for the info Jan 31 07:34:49 hmm. it would be nice to get possibility to force rebuild of out-of-kernel modules when kernel was bumped.. Jan 31 07:39:47 <[lala]> CosmicPenguin: ping Jan 31 07:40:02 RP: with c3000 ac power and battery, 2.6.15-r2 kernel built with size optimize on amd64 build host, Z does not survive a long suspend Jan 31 07:40:46 shadows: My c3000 sat overnight with 2.6.15-rc2 on it :-/ Jan 31 07:43:18 RP: and it works fine, yes? Jan 31 07:43:24 shadows: yes Jan 31 07:43:40 is your build host ia32 or amd64 Jan 31 07:43:46 ia32 Jan 31 07:43:49 :( Jan 31 07:43:54 mine is amd64 Jan 31 07:44:17 i think we may conclude prematurely that amd64 build host and gcc-3.3.4 are not equivilent Jan 31 07:44:29 ...to ia32 build host and same compiler Jan 31 07:44:53 shadows: 3.3.4 is quite old, why did you pick that version? Jan 31 07:44:57 i didn't Jan 31 07:45:08 it was the default that building was going to use Jan 31 07:45:28 am happy to test a different one Jan 31 07:45:31 shadows: try setting PREFERRED_VERSION_gcc = "3.4.4" Jan 31 07:45:31 PREFERRED_VERSION_gcc-cross = "3.4.4" Jan 31 07:45:31 PREFERRED_VERSION_gcc-cross-initial = "3.4.4" Jan 31 07:45:44 okay Jan 31 07:46:02 shadows: I suspect youll have to build from scratch though Jan 31 07:46:09 that is fine Jan 31 07:46:25 shadows: advantage of amd64 :-) Jan 31 07:46:30 shadows: Ah. 3.3.x has nasty bugs for the kernel from my experience Jan 31 07:46:40 I thought you were using 3.4.x Jan 31 07:46:47 well, it is the default i am pretty sure Jan 31 07:46:58 shadows: sorry, Im sure you put 3.3.4 before, my brain just never parsed it Jan 31 07:47:33 shadows: Personally I use 3.4.3 Jan 31 07:47:42 I share mickeyl's distrust of 3.4.4 Jan 31 07:47:54 ah Jan 31 07:47:57 RP: what is the problem with 3.4.4? Jan 31 07:47:59 then i too will try 3.4.3 Jan 31 07:48:22 XorA: Nothing I can put my finger on exactly, just didn't seem right when I tried it Jan 31 07:48:54 RP: not had a problem with it here, but I dont do wierd opie C++ stuff :-) Jan 31 07:54:02 good, i now go to work. this will build while i am making money Jan 31 07:59:05 hi all Jan 31 08:00:42 hey florian_kc Jan 31 08:07:32 hi Jan 31 08:10:11 RP: I did that led class you posted Jan 31 08:10:15 s/did/dig/ Jan 31 08:10:16 CosmicPenguin meant: RP: I dig that led class you posted Jan 31 08:39:07 CosmicPenguin: I've already had complaints from the MTD and IDE people :) Jan 31 08:39:37 RP: Bart complains about everything Jan 31 08:40:26 Seriously, I think its smart to make that general Jan 31 08:40:48 Yes, but should it be at the block level instead? Jan 31 08:40:59 I mean, right now, I twiddle the led on the DB1200 when you access the SD port, but thats in my driver, and its completely bogus Jan 31 08:41:20 Its just so much cleaner to have an existing trigger you tie into Jan 31 08:41:44 CosmicPenguin: Feel free to respond and state that case - I'm probably going to need backup :) Jan 31 08:41:53 I'm not entirely convinced it belongs at the block level - the point of the LED is to turn on when you access the hardware Jan 31 08:42:01 so it follows that it should be closer to the hardware access Jan 31 08:42:41 In the MTD case we have flash block erasing which the block later wouldn't see Jan 31 08:43:26 We'd also have the problem of trigger naming. Setting an LED to hook a specific hardware device would be trick as you wouldn't know its block number in advance Jan 31 09:01:16 hi Crofton Jan 31 09:02:31 hi Jan 31 09:29:58 i am having trouble getting libcurl into my os image Jan 31 09:30:25 i have included the .bb file, and i can install the package 'curl' Jan 31 09:30:42 which includes libcurl and the curl command line tool Jan 31 09:31:12 but when i try to just include libcurl, bb tells me it cant find it Jan 31 09:31:32 but 'libcurl' is defined as one of the packages in the .bb file for curl Jan 31 09:31:39 am i missing how that works? Jan 31 09:32:16 kitno455: its probably libcurlXX due to debian naming Jan 31 09:33:07 literally 'libcurlXX' or are the X's to be replaced. i am not familiar with debian Jan 31 09:33:14 kitno455: easy way: add curl, harder way: look how exactly libcurl package is named and add into image Jan 31 09:33:27 libcurl.so.2.0.3 could give libcurl2.ipk etc Jan 31 09:33:42 oh, right, the SONAME Jan 31 09:34:16 what does the 'packages' line in the .bb file do- just give the starting point? Jan 31 09:34:27 and bb adds the number later? Jan 31 09:35:19 if you use one of distros which inherit 'debian' class then names are changed during packaging Jan 31 09:36:10 i believe openslug does this. Jan 31 09:36:38 most of Oe distros do it Jan 31 09:36:47 try it now... Jan 31 09:38:27 cu Jan 31 09:44:01 ERROR: Nothing provides runtime dependency libcurl3 Jan 31 09:44:06 hmmm Jan 31 09:50:30 ok, still no go. Jan 31 09:51:35 i can add 'curl' to my image, and it makes the ipk's for libcurl3_7.14.0-r2... in the tmp/deploy/ipk dir Jan 31 09:51:52 and it puts the ipk in the image. this is fine Jan 31 09:52:16 but when i JUST want to put libcurl3 in the image, i cant seem to do that. Jan 31 09:52:43 am i doing something wrong? Jan 31 09:54:04 kitno455: I suspect this is a bug with the current metadata/bitbake. There was a dicussion on #oe about this. Jan 31 09:54:15 kitno455: The problem is debian.bbclass Jan 31 09:54:57 (when combined with BUILD_ALL_DEPS = "1" which is the default for images now) Jan 31 09:57:19 sounds like something i cant fix Jan 31 09:57:40 i guess i could write a postinstall script that removes the files from the image :) Jan 31 09:58:36 be aware, that i am building openslug, so i am using the nslu2 trees for this. i suppose it could differ Jan 31 09:59:48 RP: are there any magic tricks to get around mmc0: unrecognised SCR structure version 1 ? Jan 31 10:00:39 ade|desk: Disable that check in the kernel? Jan 31 10:01:26 RP: Did you see Pierre Ossman's message about MMC? Jan 31 10:01:37 ade|desk: I'd be interested in knowing if that works... Jan 31 10:01:47 CosmicPenguin: I replied. Should be about 5 lines ;-) Jan 31 10:02:04 Let me add a "me too" to that... :) Jan 31 10:03:02 ade|desk: Find me a document detailing the SCR structure version 1 and I'll fix the kernel properly Jan 31 10:03:31 hmm Jan 31 10:06:39 Good luck with all of that Jan 31 10:21:16 RP: does greentux have that info ? Jan 31 10:23:43 ade|desk: I believe that SCR version 1 is defined in something greater then SD versuion 1.01, so any documents on it are probably NDAed Jan 31 10:23:47 or under NDA even Jan 31 10:27:29 ade|desk: I don't know. If he did, its probably NDA'd :-/ Jan 31 10:27:40 SD version 1.01 = version 0 to linux Jan 31 10:28:08 Contact your local SD association representative and bitch loudly Jan 31 10:29:30 The stupid thing is its probably very similar to version 0 :-/ Jan 31 10:30:42 * ade|desk jumps up and down smaking head against a wall screaming about kingston sd cards Jan 31 10:33:11 jbowler- have you seen anything weird with terminal on a recent ucslugc? Jan 31 10:34:10 Its a shame the details of the SCR 1 structure couldn't find their way to me anonymously :-/ Jan 31 10:38:38 That would be bad Jan 31 10:39:04 The HP guys did a real good job of convincing the SD association to let go of 1.01 Jan 31 10:39:13 we just need to continue the battle for 1.1 Jan 31 10:39:44 "just" Jan 31 10:40:17 By the time it comes out, 1.2 will be current and SCR version 2 :-/ Jan 31 10:40:23 and so it will go on Jan 31 10:40:39 well, better behind the curve then not at all, Jan 31 10:42:18 Especially when you have an association that doesn't understand that restricting the protocol hurts sales Jan 31 10:42:51 hurrah, tax return completed Jan 31 10:42:56 * pb_ congratulates self on a job well done Jan 31 10:43:36 pb_: _return_ sounds good :-) Jan 31 10:44:41 pb_: over 6 hours before the deadline as well :) Jan 31 10:45:04 It would appear there is some SCR info out there Jan 31 10:45:24 florian_kc: heh. the "return" is just the paperwork I need to file, not at all the same as a refund. It turns out that I do actually owe the government some money after all. Jan 31 10:45:28 RP: yah, exactly Jan 31 10:45:35 Which says only the 8MSB bits of the version register will be used to reflect deviations from the 1.01 spec Jan 31 11:04:04 hi all Jan 31 11:04:36 hi Mardy Jan 31 11:19:38 re Jan 31 11:22:19 hi renoo: can you double check you staging//bin/file for me? I.e. is it a shell script or an executable, and if it is a shell script is it a libtool one? Jan 31 11:23:21 03hrw 07org.oe.oz354fam083 * rbb9c038e... 10/packages/quilt/ (quilt-native_0.39.bb quilt_0.39.bb): quilt 0.39: fixed SRC_URI - close #636 Jan 31 11:23:26 03florian 07org.oe.dev * r379077a1... 10/packages/busybox/ (busybox-1.01/familiar/defconfig busybox_1.01.bb): busybox: Add slimmed configuration for Familiar. Jan 31 11:23:30 03florian 07org.oe.dev * r4719567c... 10/packages/libgtkstylus/libgtkstylus_0.3.bb: libgtkstylus: Remove development files from package. Jan 31 11:23:34 03pH5 07org.oe.dev * rc0e8f2d1... 10/conf/bitbake.conf: bitbake.conf: add XORG_MIRROR Jan 31 11:23:35 Mispelt, that was meant to be 'hi reenoo: ...' Jan 31 11:23:38 03pH5 07org.oe.dev * rc359736a... 10/packages/xserver/ (3 files in 2 dirs): xserver-kdrive: add evdev support to cvs version Jan 31 11:23:43 03pH5 07org.oe.dev * rb67d2e16... 10/packages/apmd/apmd_3.2.2.bb: apmd: set /usr/bin/apm permissions to 0755 instead of 4577 Jan 31 11:23:47 03jbowler 07org.oe.dev * rf7dddcc3... 10/packages/file/ (file-native_4.13.bb file_4.13.bb): Jan 31 11:23:47 file-native: fix do_stage in 4.13 Jan 31 11:23:47 - the hand crafted do_stage installed a broken file in staging, the Jan 31 11:23:47 fix is to use the standard native do_stage which does a proper install Jan 31 11:23:47 using the makefile Jan 31 11:23:51 03jbowler 07org.oe.dev * r1d38adb3... 10/classes/ (native.bbclass package.bbclass): (log message trimmed) Jan 31 11:23:52 package.bbclass: implement a failsafe strip in classes Jan 31 11:23:54 - package.bbclass now uses file-native and cross strip to reliably strip Jan 31 11:23:56 unstripped executables and check the return code. For the moment a Jan 31 11:23:58 failure here doesn't cause the build to fail but does output a failure Jan 31 11:24:00 message direct to the controlling terminal (this is temporary). This Jan 31 11:24:02 behaviour can be changed by forcing IGNORE_STRIP_ERRORS = "" Jan 31 11:24:06 03jbowler 07org.oe.dev * r62b1a8d4... 10/conf/distro/slugos.conf: slugos: force strip errors to halt build in conf Jan 31 11:26:48 hi jbowler Jan 31 11:27:08 jbowler: dunno. it was picking up stuff from my host version of file though Jan 31 11:27:11 good evening Jan 31 11:27:16 reenoo: hi Jan 31 11:27:27 yo hardwire Jan 31 11:27:39 evening pH5 Jan 31 11:27:59 jbowler: arguably, file-native is a broken idea anyway Jan 31 11:28:32 jbowler: it doesn't build unless you have a working (and fairly current) build of file in your host environment Jan 31 11:29:14 That's going to be a problem with the patch I just checked in then Jan 31 11:29:49 So the DEPENDS="file-native" in file fixes that for file itself? Jan 31 11:30:20 it's intended to do so, yeah Jan 31 11:30:33 Do you build a big endian build? Jan 31 11:30:47 no Jan 31 11:31:21 The problem with the host utilities (like host strip) is that on an LE build system (which is typical - ix86) they can't handle BE format files. Jan 31 11:32:14 I don't know how reliable file is in that scenario (i.e. whether a 'fairly current' build of file is required anyway) Jan 31 11:32:18 speaking of strip. it returns 0 on errors. so, that part of your patch won't work Jan 31 11:32:36 No it doesn't Jan 31 11:32:45 I.e. strip returns '1' on errors Jan 31 11:32:54 .. give me an example where it doesn't Jan 31 11:35:10 heh. sure it does. I lost two hours to that yesterday Jan 31 11:35:49 .. and the version string (slugos builds binutils-2.16) Jan 31 11:36:21 ("GNU strip 2.16") Jan 31 11:37:07 GNU strip 2.15.96 20050323 Jan 31 11:37:33 So it's a bug in strip, which is fixed... Jan 31 11:38:02 that may be. but we can't upgrade binutils just to get that fix Jan 31 11:38:03 What is your strip anyway - binutils-2.16 builds a binary, is the 2.15.96* one a shell script? Jan 31 11:38:38 no, it's a binary Jan 31 11:39:07 So what's an example of the failure? Jan 31 11:39:33 any binary you want Jan 31 11:39:59 Eh? Why do you expect it to fail on a binary? Jan 31 11:40:29 any readonly elf executable or shared object file Jan 31 11:40:49 Why's that a problem, they aren't read only? Jan 31 11:41:21 I'm sorry I don't understand the question Jan 31 11:42:03 Why is it a problem if strip fails on a read-only ELF binary which is unstripped and returns a 0 error code as though it succeeded? Jan 31 11:42:51 because unstripped binaries will end up in packages that way without anyone noticing? Jan 31 11:43:02 ohhh - that postinst script command batching is cool Jan 31 11:43:05 ... look at the patch ... Jan 31 11:43:29 in particular the chmod +w line Jan 31 11:43:30 err. right. you're messing with permissions Jan 31 11:43:41 I'm not sure I like that either Jan 31 11:44:48 Well, I could do u-w u+w Jan 31 11:45:50 Eh, no, that's what -w and +w do. Jan 31 11:47:59 Anyway, binutils-2.16 strip has that specific bug too, it must be a bug... Jan 31 11:49:30 Eh... it's explicitly non_fatal, I wonder what happens. Jan 31 11:52:15 I guess the current code is as good as it can get. but it still makes a file wrtieable (for a short time) someone thought should be read-only. Jan 31 11:53:23 It makes it writeable by the person who just wrote it... Jan 31 11:53:56 There's no security implication in that. Jan 31 11:54:10 hmm Jan 31 11:54:30 If I have the capability to create a readonly file in a given directory I have the capability to unlink that file and recreate it. Jan 31 11:55:22 yah, it seems I mixed something up there Jan 31 11:55:38 I can't see any significant security difference between being about to do unlink, create(0555), write and just do a direct write. Jan 31 11:55:50 s/create/creat/ Jan 31 11:55:50 jbowler meant: I can't see any significant security difference between being about to do unlink, creat(0555), write and just do a direct write. Jan 31 11:58:17 It's nothing compared to installing apm 4577 ;-) Jan 31 11:58:39 indeed. Jan 31 11:59:09 Hum... I can't find 'strip' in binutils-cross, but it is there in binutils. Jan 31 12:01:36 Ok, strip is objcopy and the bug is in binutils/objcopy.c where it ignores the failure code from smart_rename Jan 31 12:05:29 2003-11-27 Nick Clifton Jan 31 12:05:29 * rename.c (smart_rename): Make sure that we have write Jan 31 12:05:30 permission on the destination file before renaming. Jan 31 12:08:35 Then he didn't update all the call sites which were failing to check the return code I think. Jan 31 12:29:28 03pH5 07org.oe.dev * rce67b1ab... 10/packages/apmd/apmd_3.2.2.bb: apmd: set suid bit for /usr/bin/apm Jan 31 12:35:13 reenoo|afk: see binutils-2.16-objcopy-rename-errorcode.patch in packages/binutils/binutils-2.16, I'm pretty sure this will apply to the 2.15 version too Jan 31 12:35:31 I didn't realise that writing to a setuid file didn't clear the setuid bit. Jan 31 12:35:56 At least on reiser4 Jan 31 13:06:10 is native packaging possible? Jan 31 13:08:05 HopsNBarley: Not yet Jan 31 13:08:37 thanks! you've just saved me countless days of effort! Jan 31 13:10:12 is there a generic strategy for packaging things that don't yet cross compile? Jan 31 13:10:17 by hand? Jan 31 13:11:57 If a package doesn't cross compile, it would be native? Jan 31 13:17:20 RP: I mean that there is no .bb file for it yet. Jan 31 13:23:36 HopsNBarley: I don't understand the question I'm afraid Jan 31 13:25:14 RP: lets take apache - no cross compile, yet it builds fine. i'd like to make a package of that. Or mod_php - seems alot of work to get all the pieces right for cross compile, so i was hoping to build/package it natively. Jan 31 13:26:05 i'm using NSLU2's and soon some PPC gear, so native compilation is an option. Jan 31 13:28:50 HopsNBarley: When you say "it builds fine" do you mean in or outside of OE? Jan 31 13:29:11 Hello Everyone! I have a few 'business practice' questions with OE. I can build packages, and program on it fine, and getting ready to use my images for a small box we have. Jan 31 13:29:33 what are the best ways of 'upgrading' the OE image at a later date? Jan 31 13:29:44 ipkg? or just un-tar in the /root Jan 31 13:30:14 probably ipkg Jan 31 13:31:49 yeah, that was along the lines I was thinking too, but before installing & releasing was just wanting get some 'real-world' feedback as well :) Jan 31 13:34:17 RP: in the case of apache, both in and out of OE. there is a native only bb file. Jan 31 13:35:14 RP: to ask the question a different way, is OE's design goal strickly one of cross-compile? I'm a noob - I don't know. Jan 31 13:35:53 is ipkg used anywhere else? Jan 31 13:36:22 dwildes: Ive been ipkg upgrading my zaurus for about 6 months now with no problems, its certainly easier than reflashing Jan 31 13:41:15 Thanks XorA! I think ipkg is the way to go as well, as least for patches and small updates, then maybe a full reflash for each major release Jan 31 13:45:15 RP: I've build my kernel 2.6 and a bootstrap image... and... "kernel panic - not syncing: no init found. try passing init= option to kernel" Jan 31 13:46:10 03rw 07org.oe.dev * rbf2bfa89... 10/conf/machine/h3900.conf: h3900.conf: don't include tune-xscale.conf so as to retain backwards compatibility. the extra bit of performance isn't worth the hassle of building, storing/mirrorin, and maintaining duplicate packages. Jan 31 13:46:14 03rw 07org.oe.dev * r304f7977... 10/classes/package.bbclass: package.bbclass: interpret 0 as false (as well as "") when evaluating IGNORE_STRIP_ERRORS Jan 31 13:46:18 03rw 07org.oe.dev * r1b63b991... 10/packages/ppp/ppp_2.4.3.bb: ppp: bump PR to force rebuild after package.bbclass changes. only add postinst for ppp (main) package. Fixes hh.org Bug #1469. Jan 31 13:46:22 03rw 07org.oe.dev * raf1f2872... 10/classes/package.bbclass: disapproval of revision '304f797758aebb96591a27d547338e2c77c68ada' Jan 31 13:46:26 03rw 07org.oe.dev * rc1c3a45f... 10/packages/ppp/ppp_2.4.3.bb: disapproval of revision '1b63b991554424859234171d74c5abc6b9ba6759' Jan 31 13:46:30 03rw 07org.oe.dev * r652c2196... 10/classes/package.bbclass: disapproval of revision 'af1f287266f2f111baa6945c52966396c108642b' Jan 31 13:46:34 03rw 07org.oe.dev * rd2c8ff83... 10/packages/ppp/ppp_2.4.3.bb: Jan 31 13:46:35 ppp: bump PR to force rebuild after package.bbclass changes. only add postinst for ppp (main) package. Fixes hh.org Bug #1469. Jan 31 13:46:35 - no misc changes this time. Jan 31 13:52:31 re Jan 31 14:09:18 RP --> http://pastebin.com/532755 Jan 31 14:10:25 Greetings to all ! Jan 31 14:11:01 Is there any Familiar distro theme i can add to bootsplash ? Jan 31 14:21:25 RP: there's your vote from me.. :) Jan 31 14:23:26 cedric__: Can you check which root= device it was using? Jan 31 14:24:06 cedric__: I think it'll be using mtdblock2 when it should be using mtdblock1 Jan 31 14:24:43 RP: yep it's using mtdblock2 Jan 31 14:27:22 RP: what's the best way to hack/change the kernel setting in OE? which directory should I work on? sorry it's been a long time... :-) I need to get my head around it again! Jan 31 14:27:45 cedric__: packages/linux/linux-openzaurus.inc is the file you want Jan 31 14:30:37 I though we change that last year... Jan 31 14:32:14 cedric__: I think I thought I'd fixed the rom driver and removed that fix, sorry :-( Jan 31 14:32:52 (In theory, mtdblock0 should be the rom chip on the device) Jan 31 14:59:19 03koen 07org.oe.dev * rc6bbd701... 10/conf/machine/h3900.conf: Jan 31 14:59:20 h3900: stop people thwarting my attempt to get thumb-interwork running Jan 31 14:59:20 people without a h3900 machine should also stop messing with this file, damnit!s Jan 31 15:06:31 CosmicPenguin: I've responsed along similar lines, thanks :) Jan 31 15:06:54 Just thought I would toss my .02 in Jan 31 15:07:03 re Jan 31 15:07:08 since I think this would be really useful for Alchemy, and at least moderately useful for Geode Jan 31 15:07:13 CosmicPenguin: I'm going to push for the LED Core, LED Trigger Core and LED Drivers. If we loose the triggers themselves and have to patch them in ourselves, so be it Jan 31 15:07:24 RP: nod Jan 31 15:08:44 renoo|afk: didn't you just invert the sense of the IGNORE_STRIP_ERRORS test? Jan 31 15:08:58 if x1 != x1 then ignore the error Jan 31 15:09:12 So if IGNORE_STRIP_ERRORS=1 the error isn;t ignored... Jan 31 15:17:17 It was "test value != "" ', it's now 'test value != 1' Jan 31 15:18:11 So value==1 was true before and is now false, value == "" was false before and is now true, value == 0 was false before and is still false. Jan 31 15:18:15 jbowler-away: yah, sorry about that. would be fixed if monotone.vanille.de didn't have issues again. Jan 31 15:18:24 reenoo: it has issues? Jan 31 15:18:24 push it into ewi Jan 31 15:18:35 * zecke restarts vanille Jan 31 15:18:40 or push it into monotone.nslu2-linux.org (though I don't pull that) Jan 31 15:18:54 or push it into dominion (I do pull that) Jan 31 15:18:55 zecke: it's timing out to be precise Jan 31 15:19:20 reenoo: about to start Jan 31 15:19:23 reenoo: started Jan 31 15:19:27 zecke: thanks Jan 31 15:19:33 ewi546.ewi.utwente.nl is fine Jan 31 15:19:53 pushed Jan 31 15:20:46 03rw 07org.oe.dev * r428392cf... 10/classes/package.bbclass: package.bbclass: fix interpretation of IGNORE_STRIP_ERRORS one more time. Jan 31 15:21:30 Eh, you just put it back to the way it was before Jan 31 15:22:00 (Well, it breaks if someone says IGNORE_STRIP_ERRORS = "yes ignore them please") Jan 31 15:22:34 heh, don't do that then Jan 31 15:22:45 you can't set MACHINE="nslu2 if you don't mind" either Jan 31 15:23:01 I think what you want is 'test 0"${IGNORE_STRIP_ERRORS}" -gt 0' Jan 31 15:23:34 RP: I finally ci'ed your patch to bitbake Jan 31 15:24:14 pb__: can't I? I mean, I would create "conf/machine/nslu2 if you don't mind.conf" Jan 31 15:24:59 I can see that the ' might cause problems somewhere though... Jan 31 15:26:27 jbowler-away: if you created the .conf file, sure. the point I was trying to make was that the precedent with those boolean variables is that you set them to "1" to turn them on; setting them to some random string that happens to vaguely resemble that is not, in general, good enough. Jan 31 15:26:57 Yes, I was being slightly argumentative for the sake of it... Jan 31 15:27:13 urgh Jan 31 15:27:20 pity there is no way in test to say "yes in any language" Jan 31 15:27:22 current 2.4 kernel seems to be fubared in spitz Jan 31 15:27:36 I am testing the bootstrap-image on epia and realized that it does not contain any dhcp support for network setup Jan 31 15:27:37 I suspect that having spaces and apostrophes in MACHINE probably would cause oe at least a bit of heartburn though. Jan 31 15:27:52 Ifaistos: really? udhcpcd is part of busybox Jan 31 15:28:11 in dev at least Jan 31 15:28:32 pb__: It does not run during initial boot Jan 31 15:28:37 Ifaistos: that's very sad Jan 31 15:29:08 There is probably no 'auto eth0' in /etc/network/interfaces... Jan 31 15:29:30 ah yeah, good point Jan 31 15:29:34 jbowler-away: no, it's meant the way it is now and was before your changes Jan 31 15:30:11 mhh i got lot of such error at end of building an image --> *** glibc detected *** arm-linux-depmod: double free or corruption (!prev): 0x00000000006071e0 *** Jan 31 15:30:13 It seems that there is not /etc/udhcpd.conf Jan 31 15:30:34 ferora core 4 (64bit) on x86_64 Jan 31 15:30:40 gremlin[it]: I've gotten those as well, but they never caused any problems Jan 31 15:30:41 renoo: it says 'x${IGNORE_STRIP_ERRORS} != x' and after my changes it said 'test -n "${IGNORE_STRIP_ERRORS}" and these are identical. Jan 31 15:30:54 gremlin[it]: yep, happened to me on a 64bit system too Jan 31 15:31:01 jbowler-away: no. Jan 31 15:31:02 JustinP i know happen also in past .. but was long time i didn't see ... Jan 31 15:31:11 jbowler-away: "0" is a non-empty string Jan 31 15:31:55 reenoo (sorry, I still can't type): 0x != x, x != x unless == "", -n value means value != "" Jan 31 15:32:59 * reenoo bangs head against table Jan 31 15:33:07 and IIRC before my changes the test was !(defined IGNORE_STRIP_ERRORS) Jan 31 15:33:23 let me check... Jan 31 15:34:31 No, I'm wrong too: bb.data.getVar('IGNORE_STRIP_ERRORS', d, 1) != '1' Jan 31 15:34:47 jbowler-away: right Jan 31 15:34:48 So what you want is test "${IGNORE_STRIP_ERRORS}" = 1 Jan 31 15:34:59 I just need more sleep ;) Jan 31 15:35:22 03rw 07org.oe.dev * r86c872a0... 10/classes/package.bbclass: package.bbclass: now really fix interpretation of IGNORE_STRIP_ERRORS. Jan 31 15:35:35 'test' is the worlds most evil command Jan 31 15:36:20 Or '[' Jan 31 15:37:05 Once rebooted udhcpd works.... Is this how things are supposed to happen or is there something missing from the configs ? Jan 31 15:37:11 jbowler-away: I hope I finally got it right now Jan 31 15:37:35 yes - it's correct now Jan 31 15:46:32 lookw like the modules bbclass problems are in the oz354fam083 tree as well Jan 31 15:47:28 goodnight Jan 31 16:00:03 hey Jan 31 16:04:39 * CoreDump|home wonders if there is a reason opie-qss was excluded from 2.6 images Jan 31 16:17:10 zecke: ah good, thanks Jan 31 16:17:38 just with some hours delay Jan 31 16:20:12 zecke: an hour time lag sums up my life at the moment :-/ Jan 31 16:33:32 RP: what happened? Jan 31 16:33:40 * zecke gets used to svk now Jan 31 16:33:51 zecke: Just too busy... Jan 31 16:34:11 hehe, I know how that feels Jan 31 16:34:25 stay strong, don't ruin your health Jan 31 16:35:02 I'll try not to :) Jan 31 16:35:09 Probably too late for my sanity :-/ Jan 31 16:35:52 well that can always be reflashed Jan 31 16:37:42 zecke: you have an image handy? :) Jan 31 16:38:22 RP: I poses one but... (actually two) but none could be used to take a picture Jan 31 16:38:40 one is missing a v4l linux driver and the other has a broken battery Jan 31 16:56:23 okay cya guys Jan 31 16:57:20 03coredump 07org.oe.dev * rb8d67726... 10/packages/altboot/ (6 files in 4 dirs): Jan 31 16:57:20 altboot: Jan 31 16:57:21 - More kernel 2.6 changes Jan 31 16:57:23 - Booting off SD seems to work as expected now Jan 31 16:57:25 - Turn off printk before showing the menu, kernel messages make a mess of it Jan 31 16:57:27 - Load keympas before showing the menu. init=/bin/sh is useless with a b0rked keymapping. Jan 31 17:00:39 hello all Jan 31 17:01:06 good night Jan 31 17:01:30 hello Jan 31 17:02:38 does anyone here know how to build modules natively on the device if your metadata is borked? Jan 31 17:03:23 I tried building against the stock 2.6.15-rc7 kernel sources (which is the version I'm using), but the resultant modules only work halfway Jan 31 17:15:43 Is this about the opentomtom project? Jan 31 17:16:58 #oe == Openembedded Jan 31 17:17:12 read the topic of channels you join Jan 31 17:17:42 yeah but im not entirely sure what it means to be honest Jan 31 17:17:54 oe.handhelds.org Jan 31 17:18:00 or, here's an idea Jan 31 17:18:03 when you dont know what something is Jan 31 17:18:04 google it. Jan 31 17:18:35 (or risk abuse) Jan 31 17:18:46 hehe Jan 31 17:19:21 the one thing i will say is, although you're doing very well with your 'google it' and 'rtfm' responses, you could have saved yourself more time by just answering my question Jan 31 17:21:59 yes, but this way maybe you'll inflict less annoyance on others in the future Jan 31 17:45:02 yay, runstrip errors Jan 31 18:05:28 * shadows goes to town with bug reporting Jan 31 18:26:20 http://bugs.openembedded.org/show_bug.cgi?id=640 Jan 31 18:26:34 which part of the OE system controls the creation of /dev/console node? Jan 31 18:40:03 could be /etc/init.d/devices from "initscrpts" Jan 31 18:40:20 hmm Jan 31 18:40:38 the trouble is, that i'm not using the normal spitz installation routine Jan 31 18:40:57 i'm using the recovery linux system to boot, then create an ext3 fs, and upack the tarball to it Jan 31 18:41:01 there's no /dev/console Jan 31 18:41:06 thus when init runs, init freaks out Jan 31 18:41:09 and nothing happens Jan 31 18:41:22 heh, dunno why that would be Jan 31 18:41:39 oh Jan 31 18:41:43 well wait Jan 31 18:41:53 i think my point is that init does not run Jan 31 18:41:57 i mean, it starts Jan 31 18:42:01 /dev should be included in your tarbal Jan 31 18:42:02 and then there's a lack of a console Jan 31 18:42:08 oh /dev is included Jan 31 18:42:16 there's only 4-5 devices, none of them is console Jan 31 18:42:19 and contain "console" Jan 31 18:42:22 hmm Jan 31 18:42:23 no console. Jan 31 18:42:27 yaaah. Jan 31 18:43:23 i'll be doing another build soon, and i can file a formal bug report with more info. i had thought this was a typo someone would recognize when i mentioned it in IRC Jan 31 18:43:31 and save me the trouble Jan 31 18:43:32 ;) Jan 31 18:43:34 dunno how they generate the tarball for borzoi / spitz but in a normal gpe or opie-image, console is there Jan 31 18:43:41 okay Jan 31 18:43:48 device creation is two phase. first is the devices included in the actual image/tarball, then is the creation of hte devices in the /dev ramdisk. makedevs populates the latter, at least on 2.4 Jan 31 18:44:04 oh okay Jan 31 18:44:07 2.6 kernel here Jan 31 18:44:11 udev fanciness Jan 31 18:44:28 console is in the real dev un flash Jan 31 18:44:40 so hmm Jan 31 18:44:52 it's also possible that gcc poofed something Jan 31 18:44:54 udev isn't running at INIT =) Jan 31 18:45:06 i've switched to gcc 3.4.3 now Jan 31 18:45:09 * CoreDump|afk doubts it Jan 31 18:45:17 hoping this solves kernel issues Jan 31 18:47:13 I should make NFS booting work in 2.6 grr Jan 31 18:47:43 tired of flashing all the darn time? Jan 31 18:48:17 indeed Jan 31 18:48:36 and my SD is to small for anything useful Jan 31 18:50:51 what um, network device would you use exactly Jan 31 18:51:40 WLAN Jan 31 18:51:41 CF wired ethernet? Jan 31 18:51:42 oh Jan 31 18:51:53 WLAN for NFS root? Jan 31 18:51:56 o_O Jan 31 18:52:13 works surprisingly well Jan 31 18:52:49 fsck of loop files on nfs sucks tho heh Jan 31 18:54:30 CoreDump|afk: Could be tricking get WLAN working before trying to mount root I'd imagine! (I use NFS root for all development in 2.6 kernels via wired ethernet with no issues) Jan 31 18:55:11 v8jlene: use altboot =) Jan 31 18:55:27 NOTE: package gpe-image-ext2loop-1.0-r19: task do_rootfs: started Jan 31 18:56:34 http://hentges.net/tmp/screenshots/Zaurus/Akita/Altboot/altboot-2.jpg Jan 31 18:59:53 CoreDump|afk: CoreDump|afk: Ah, looks nice ;) Probably not suitable as is on my platform (I'm working on an sh4 based embedded router platform) and I'm ok nfs bootin gover wires for development ;) Jan 31 19:00:37 v8jlene: NFS is perfect for this kind of work i imagine Jan 31 19:02:53 CoreDump|afk: Yeah, I make all changes on the server (be that new kernels or new/modified root filesystem) and then reboot to test things. Quick and no messing around with the hardware itself. Jan 31 19:03:10 nice =) Jan 31 19:03:17 ~praise linux Jan 31 19:03:19 All hail linux! Jan 31 19:03:36 um lol Jan 31 19:04:11 w00t, NFS script works out of the box for kernel 2.6 Jan 31 19:04:36 a lot of things work "out of the box" for kernel 2.6 that never did on kernel 2.4 Jan 31 19:04:44 well, or not Jan 31 19:04:52 no? Jan 31 19:05:10 something during init trashes WLAN Jan 31 19:05:16 oh Jan 31 19:05:27 could be hotplug Jan 31 19:05:37 or the damn udev Jan 31 19:07:12 well, it's too late for today, n8 all Jan 31 19:07:58 03jbowler 07org.oe.dev * r94dcd1ea... 10/packages/linux/ (ixp4xx-kernel_2.6.15.1.bb ixp4xx-kernel_2.6.15.2.bb): ixp4xx-kernel: bug fix release 2.6.15.2 Jan 31 19:08:02 03jbowler 07org.oe.dev * ra0299ec4... 10/packages/binutils/ (2 files in 2 dirs): Jan 31 19:08:03 binutils: make strip and objcopy return 0 if asked to write ro files in 2.16 Jan 31 19:08:03 - the same bug exists in earlier versions and is probably fixed by the Jan 31 19:08:03 same patch, objcopy (==strip) would identify an ro file and abort the Jan 31 19:08:03 overwrite (smart_rename), but the caller in objcopy fails to check the Jan 31 19:08:05 error code and so the error is not reported Jan 31 19:09:22 yay for jbowler Jan 31 19:27:24 hey everyone. Jan 31 19:29:46 suppose one were looking to get e17 working on a sl-5500... what target would provide the best image to start with? Jan 31 19:30:30 e-image-core should work Jan 31 19:30:41 but may be too big, I'm not sure Jan 31 19:31:00 and in dev entrance isn't starting on boot....so it's not usable Jan 31 19:31:16 the versions in oz354fam083 should work, but I haven't tested them in a while Jan 31 19:31:17 thanks. Jan 31 19:31:20 suppose I should do that.... Jan 31 19:31:41 if you're looking to play you can always start with a gpe-image and install the e stuff on top of it Jan 31 19:31:49 i really appreciate it. i've been kinda stuck for a while. Jan 31 19:31:52 which is what I originally did Jan 31 19:31:52 yeah Jan 31 19:31:57 ah Jan 31 19:32:10 well I just fixed some more issues with compiling the other day Jan 31 19:32:14 what have you been trying? Jan 31 19:32:19 well i wasted a bunch of time trying to get everything on top of a bootstrap image Jan 31 19:32:26 (I'm the person who's supposed to be responsible for e in OE :-| ) Jan 31 19:32:32 ah Jan 31 19:32:42 well, e-image-core may work Jan 31 19:32:46 but it also may be too big Jan 31 19:32:55 i was about to gpe or opie, but was trying to conserve space. Jan 31 19:32:59 I would suggest using altboot and making a boot image on an SD card for tetsing it Jan 31 19:33:18 e17 is far larger than gpe or opie Jan 31 19:33:34 I haven't tried to go in and shrink the image sizes in the themes as yet Jan 31 19:34:02 I'm assuming i cant flash this thing the standard way then. Jan 31 19:34:09 i'll look into alt boot. Jan 31 19:34:20 i got a 256mb sd card and a 64mb cf Jan 31 19:35:24 you can try flashing it but I think the core image is still too large for the sl5500 Jan 31 19:35:30 I'm not sure, but it's very likely Jan 31 19:35:43 ok. Jan 31 19:35:47 using an image on your SD card for tetsing would be better for now Jan 31 19:35:48 i'll give it a shot. Jan 31 19:35:53 :-) Jan 31 19:35:56 let me know how it goes Jan 31 19:35:59 i will Jan 31 19:36:05 AFAIK no-one has tried it on an sl5500 yet Jan 31 19:36:12 really? Jan 31 19:36:24 yep Jan 31 19:36:37 * gremlin484 might be breaking the proverbial "new ground" Jan 31 19:36:41 I have a zpitz Jan 31 19:36:47 spitz Jan 31 19:37:38 i've had this 5500 for a few years now, and it's just been collecting dust, but i'm pretty heavy into e17 now, ( not coding, but theming ) so I decided to give it a shot. Jan 31 19:37:42 * JustinP will build an e-image-core in oz354fam083 and see if it still works Jan 31 19:37:49 ah, cool Jan 31 19:38:11 if you could make OZ themes that woul dbe very nice :-) Jan 31 19:38:11 I'd be happy to include them, esp if they're smaller size-wise than th Jan 31 19:38:11 e de Jan 31 19:38:23 fault Jan 31 19:38:31 hmmm...how did that happen...darn lag Jan 31 19:39:10 the largest part of e is he themes Jan 31 19:40:11 i can see that. Jan 31 19:40:56 athough the binary edj is smaller than the uncompressed source files. Jan 31 19:41:04 of course Jan 31 19:41:14 the edj are very high quality, though.... Jan 31 19:41:18 yeah Jan 31 19:42:29 and edje_cc is having issues with the cpp that OE builds....not sure what's up there Jan 31 19:50:54 ok, my e-image-core compiled in oz354fam083 Jan 31 19:50:59 I'll test it as soon as I get home Jan 31 19:51:15 (on cell network right now and it's the slow one...) Jan 31 19:51:32 cool. Jan 31 19:53:15 you'll have to excuse my retardedness... what do you mean by oz354fam083 ? Jan 31 19:54:02 the branch Jan 31 19:54:09 ehat branch are you trying in? Jan 31 19:54:12 what Jan 31 19:54:41 the org.openembedded.dev branch should compile e-image-core right now, but entrance isn't starting for me (haven't had time to figure out why yet) Jan 31 19:54:55 I recently updated the versions tin .dev Jan 31 19:55:27 ok yeah .dev Jan 31 19:55:42 the org.openembedded.oz354fam083 branch has the old versions which definately worked back when I put those in. I'm still running them on my Z right now, actually ;_) Jan 31 19:55:45 I get it. I didn't look at the other development ones. Jan 31 19:56:00 i'll switch. Jan 31 19:56:22 you should use a new directory for building as well Jan 31 19:56:30 new conf and new tmpdir Jan 31 19:56:32 sorry, I just started figuring out oz about an hour ago... Jan 31 19:56:37 not oz oe Jan 31 19:56:39 Oh I see Jan 31 19:56:51 have you gotten the monotone database yet? Jan 31 19:57:00 bitbake, monotone and all... Jan 31 19:57:01 yeah Jan 31 19:57:09 ok Jan 31 19:57:18 then you probably haven't lost any time, hopefully Jan 31 19:57:22 had you started building yet? Jan 31 19:57:22 i was compiling e-image0core from .dev Jan 31 19:57:28 it was failing... miserably Jan 31 19:57:41 oz354fam083 is the "stable" branch for the upcoming releases Jan 31 19:57:51 e-image-core *should* compile in .dev.... Jan 31 19:57:56 what was failing? Jan 31 19:58:08 ok. i'm on the same page now... or at least in the same library... Jan 31 19:58:38 heh Jan 31 19:59:08 I'm not sure it was a while back... my scrollback is only 200 lines I think. Jan 31 19:59:27 ok Jan 31 19:59:43 well, switch to the stable branch and start your compiles form scratch Jan 31 19:59:58 make sure you have your environment all set up Jan 31 20:01:13 and that you have the newest bitbake Jan 31 20:01:50 i have bitbake 0.25 i think Jan 31 20:01:55 without double checking Jan 31 20:02:04 i'm pulling oz354fam083 now Jan 31 20:02:13 did you pull bitbake from svn? Jan 31 20:02:31 no portage ( gentoo ) Jan 31 20:02:39 well... Jan 31 20:02:54 portage may have used svn Jan 31 20:03:49 I believe it does Jan 31 20:03:56 :-) Jan 31 20:03:59 yay for gentoo Jan 31 20:04:26 i usually dont watch emerge that close :) Jan 31 20:04:41 emerge ..... go away for a while... all done. Jan 31 20:04:47 sounds good to me Jan 31 20:05:29 :-) Jan 31 20:05:54 should i have gotten rid of my org.openembedded.dev folder? Jan 31 20:06:09 no, that's fine Jan 31 20:06:18 just get rid of the tmp folder in your build dir Jan 31 20:06:29 and change your local.conf to point to the new checkout Jan 31 20:06:48 and also change your BBPATH ENV var Jan 31 20:07:03 it seems to have written 3 revs... Jan 31 20:07:14 ? Jan 31 20:08:34 hold on.... Jan 31 20:11:21 BBPATH is set correctly in bot local.conf and within the environment Jan 31 20:11:39 monotone --db=/stuff/oe.db pull ewi546.ewi.utwente.nl "org.openembedded.oz354fam083" Jan 31 20:11:50 monotone --db=/stuff/oe.db checkout --branch=org.openembedded.oz354fam083 Jan 31 20:12:04 and monotone --db=/stuff/oe.db pull ewi546.ewi.utwente.nl org.openembedded.oz354fam083 Jan 31 20:12:16 are all done almost instantly... Jan 31 20:12:25 does that sound right? Jan 31 20:12:38 pulls should be quick when you have no revs to pull Jan 31 20:12:45 ok Jan 31 20:12:47 checkout should check a bunch of files out Jan 31 20:12:47 did it? Jan 31 20:13:27 checkout did not echo back anything Jan 31 20:13:33 it shouldn't Jan 31 20:13:43 you don't have to use /stuff, BTW Jan 31 20:13:48 and don't run bitbake as root Jan 31 20:14:01 you could kill your host system Jan 31 20:14:06 right. i'm user Jan 31 20:14:29 just making sure Jan 31 20:14:43 and i just used /stuff to make it as simple as possible, while i still try to figure out exactly what is going on.... Jan 31 20:15:31 ok Jan 31 20:15:38 did the files get checked out? Jan 31 20:16:13 ' /stuff/org.openembedded.oz354fam083 exists, and is populated ? Jan 31 20:16:28 yes Jan 31 20:17:08 heh, again I apologize for my n00b'ness... I'm really not a stupid as I look. Jan 31 20:18:05 I understand Jan 31 20:18:19 now do you have your build dir set up? Jan 31 20:18:26 and your ENV? Jan 31 20:18:35 i believe so. Jan 31 20:18:54 ok Jan 31 20:19:02 (you et your BBPATH correctly?) Jan 31 20:19:04 set Jan 31 20:19:06 yeah Jan 31 20:20:06 ok Jan 31 20:20:10 fire away Jan 31 20:20:16 BTW, bitbake -i is nice :-) Jan 31 20:21:01 heh Jan 31 20:21:54 i'm still wrapping my head around getting to the point that I can build stuff... it's all making sense though Jan 31 20:22:21 I use a shell script swhich sets up my env Jan 31 20:22:33 have to go, about to get off the bug Jan 31 20:22:35 bus Jan 31 20:22:40 will be back in a little while Jan 31 20:22:43 thanks for the help Jan 31 20:22:46 appreciate it Jan 31 20:57:59 back Jan 31 20:58:04 but need to eat Jan 31 20:58:21 still compiling Jan 31 20:58:30 '/building Jan 31 21:04:08 oh you will be compiling for a long time Jan 31 21:04:43 starting from scratch means you have to build gcc and glibc, those take a long time Jan 31 21:04:46 yeah i know dev took a few hours Jan 31 21:04:56 'glibc is going now Jan 31 21:05:38 were you getting those "corruption" errors? Jan 31 21:06:29 dosent look like it Jan 31 21:06:37 although i'm not using verbose Jan 31 21:06:46 I meant before Jan 31 21:06:54 you must be a different person Jan 31 21:07:01 yeah sounds familiar Jan 31 21:07:12 hmmm Jan 31 21:07:22 amd64 host? Jan 31 21:07:25 nah Jan 31 21:07:45 nm, then Jan 31 21:31:09 hm, much simpler to compile in a mixed chroot than to make a working BB, I think ;) Jan 31 21:33:29 yay qemu Jan 31 21:37:04 build of e-image-core from oz354fam083 during gcc-cross-4.0.0-r1: Jan 31 21:37:17 checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Jan 31 21:37:20 any thoughts? Jan 31 21:37:59 gremlin484: for gcc-cross? Jan 31 21:38:02 no idea Jan 31 21:38:26 luke-jr_: works fine in a "normal" environment for me Jan 31 21:38:31 i'm google'n with no luck so far Jan 31 21:39:04 strange Jan 31 21:39:16 you sure you have all the right versions of the req's installed? Jan 31 21:39:21 (with Gentoo you should) Jan 31 21:39:49 JustinP: non-OE compile... Jan 31 21:39:55 i can't say i'm sure, but.... Jan 31 21:39:58 JustinP: ./configure && make && make install Jan 31 21:40:20 but in a chroot w/ mixed native & non-native apps Jan 31 21:40:31 using qemu under binfmt_misc for the non-natives Jan 31 21:45:28 gremlin484: check RequiredSoftware and make sure it's all installed Jan 31 21:51:45 well, the doc says just emerge bitbake, which is done, but i tried the listed ones manually, and it looks like i'm missing the following: Jan 31 21:51:56 ccache, quilt, sgmltools-lite, docbook-xml-dtd, and xmlto Jan 31 21:52:04 i'm emergeing them now Jan 31 21:53:34 also, should I be using the GCC 2.95.3 toolchain as described here: http://oe.handhelds.org/cgi-bin/moin.cgi/ZaurusKernels Jan 31 22:01:15 if you're using the 2.4 kernel, yes Jan 31 22:01:18 I suggets installing it Jan 31 22:01:37 e-image-core works fine for me from stable Jan 31 22:02:33 ok, i'm on 2.6.15 Jan 31 22:02:44 no, not on Jan 31 22:02:49 if you're going to *compile* 2.4 Jan 31 22:02:58 ahhhh Jan 31 22:03:10 oz354fam083 defaults to kernel 2.4 for the zaurii I think....not sure about 5500 Jan 31 22:03:52 see i think thats where most of why confusion came from when reading the documentation.... i wasn't sure when it was referring to the zaurus, and when it was referring to the machine from which i was building.... Jan 31 22:03:58 maybe I just cant read Jan 31 22:04:31 i was using gcc 2.95.3 but maybe it got messed up? Jan 31 22:04:54 ? Jan 31 22:04:55 i wouldnt think that would be possible running as a user Jan 31 22:05:02 yeah dumb question Jan 31 22:05:05 well, you should have a recent gcc installe don your host Jan 31 22:05:15 and IE will compile a recent cross-compiler for the Z Jan 31 22:05:23 but the embeddix 2.4 kernels need the old compiler Jan 31 22:05:28 OE, not IE Jan 31 22:05:45 * luke-jr_ watches IE compile GCC Jan 31 22:05:55 my gentoo box uses gcc-3.4.5 Jan 31 22:05:58 good Jan 31 22:06:02 lol Jan 31 22:06:20 gremlin484: OE won't work right if it's run as root, I think Jan 31 22:06:35 right, i'm running as user. Jan 31 22:07:02 what error you getting? Jan 31 22:07:48 well, now i've emerge those packages from above, so i'm running bitbake again.... Jan 31 22:07:58 erm Jan 31 22:08:05 don't use portage Jan 31 22:08:26 not the GCC 2.95.3 toolchain Jan 31 22:08:29 unless it has Svn/MT ebuilds... Jan 31 22:08:37 GCC 2.95 can die Jan 31 22:08:44 bury it already Jan 31 22:08:45 yeah, well, we believe it does Jan 31 22:09:16 ok i'm confused.... Jan 31 22:09:36 i'm talking about putting the GCC 2.95.3 toolchain in /usr/local/arm/ Jan 31 22:10:03 GCC 2.95 is good for rm only Jan 31 22:10:08 then ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95" Jan 31 22:10:12 in local.conf Jan 31 22:10:19 rm? Jan 31 22:10:24 deletion Jan 31 22:10:39 gremlin484: stop listening to luke Jan 31 22:10:42 lol Jan 31 22:11:00 gremlin484: he's right, it should be thrown away, but you need it if you're compiling a 2.4 kernel Jan 31 22:11:10 gremlin484: and use portage Jan 31 22:11:13 ... which you shouldn't be doing =p Jan 31 22:11:14 gremlin484: it works perfect Jan 31 22:11:22 haha Jan 31 22:11:28 luke-jr_: is the 2.6 kernel ready for every machine? I don't think so Jan 31 22:11:40 luke-jr_: not sure if it's ready for the sl5500 yet.... Jan 31 22:11:42 JustinP: still doesn't mean he should build 2.4 Jan 31 22:11:56 who cares if it's ready? ;0 Jan 31 22:12:00 luke-jr_: if 2.6 isn't done, yes, he should Jan 31 22:12:19 I frigging care Jan 31 22:12:26 pfft, I use 2.6 and it isn't done for my Z Jan 31 22:12:28 my zaurus isn't useful if I can't connect to it Jan 31 22:12:37 don Jan 31 22:12:43 don't they all support networking? Jan 31 22:12:53 connect meaning usbnetworking? Jan 31 22:13:03 i have a CF wireless card, for what it's worth Jan 31 22:13:04 yes, but my Z won't connect to my computer via USB yet Jan 31 22:13:05 I thought it was only some display/kb/sound/etc stuff that was lacking Jan 31 22:13:12 and my CF wireless card wasn't working either Jan 31 22:13:16 no Jan 31 22:13:21 USB stuff doesn't work 100% Jan 31 22:13:26 (C3000, here) Jan 31 22:13:32 well, USB doesn't work w/ 2.4 either... Jan 31 22:13:34 inline remote doesn't work Jan 31 22:13:36 C760 here Jan 31 22:13:37 i had the stock openzaurus rom working over usb network, but the routing was a pain Jan 31 22:13:42 sure it does, you just have to reload it Jan 31 22:14:39 nah, neither side sees the other at all Jan 31 22:14:42 not even a dmesg log Jan 31 22:15:03 but that's fairly irrelevant with as useless as USB networking is Jan 31 22:15:25 the only reason I use it is to copy stuff off CF cards once in a while Jan 31 22:15:55 most people have CF readers other than the Z, so they wouldn't even need it for that Jan 31 22:16:07 but if wireless works, then i dont care about the cradle... Jan 31 22:16:14 luke-jr_: it works just fine Jan 31 22:16:38 anyway, just go on with your compiling Jan 31 22:16:43 lol Jan 31 22:16:45 i am Jan 31 22:17:08 IIRC. There isn't any support for SD cards on the 5500 in the 2.6 kernel Jan 31 22:17:24 I think there's support for MMC Jan 31 22:17:28 which can read SD just fine Jan 31 22:18:06 meh...same error with those packages.... Jan 31 22:18:15 checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Jan 31 22:18:41 gcc-cross-4.0.0-r1 Jan 31 22:19:30 4? Jan 31 22:19:42 it shouldn't be compiling gcc-4.... Jan 31 22:20:34 bah, i was missing /usr/local/arm/2.95.3/bin from my path variable Jan 31 22:20:43 shouldn't make a difference yet Jan 31 22:22:24 yeah you're right same error Jan 31 22:23:39 I think i'm missing something here... something I should be picking up on.... Jan 31 22:24:15 it wouldn't have anything to do with not doing monotone update -rjan2006prebreakage Jan 31 22:25:25 no, that should be fine Jan 31 22:25:36 the stable branch shouldn't be affected by that Jan 31 22:26:03 * gremlin484 hits head against wall several times Jan 31 22:26:38 did you set your DISTRO right? Jan 31 22:26:42 and MACHINE? Jan 31 22:27:10 yeah... MACHINE = "collie" Jan 31 22:27:18 DISTRO = "openzaurus" Jan 31 22:27:22 hah Jan 31 22:27:23 that's it Jan 31 22:27:27 damn it Jan 31 22:27:27 openzaurus-3.5.4 Jan 31 22:27:45 I should have mentioned that earlier Jan 31 22:28:39 eh, so now do i just continue, or should i blow away /stuff/build/tmp ? Jan 31 22:28:45 and OE/BB really ought to say that you've used an invalid conf.... Jan 31 22:29:07 you shoul dbe able to "continue" but you may want to blow it away to be safe Jan 31 22:30:05 just cause i'm intrigued, i'm gonna leave tmp for now, but if I get any other issues, i'll get rid of it and start from scratch Jan 31 22:30:12 hehe Jan 31 22:31:28 it's sooo hard to blow away tmp... It took poor computy so long to compile it! Jan 31 22:31:44 lol Jan 31 22:31:52 heh Jan 31 22:31:56 I do it regularly Jan 31 22:32:03 to make sure things compile right form scratch Jan 31 22:32:07 from Jan 31 22:33:47 it wouldn't be so bad if not for the "Handling BitBake Files:" part Jan 31 22:34:05 what does the term BitBake come from by the way Jan 31 22:34:19 not sure Jan 31 22:34:31 it was called oe when I first started Jan 31 22:34:41 hmm Jan 31 22:34:46 then the metadata got oe and the tool was changed to bb Jan 31 22:34:57 I like it Jan 31 22:35:15 coo Jan 31 22:35:17 i love the defunct design in the 5500 cradle in that i had to, on a bootstrap openzaurus image, do a "sleep 5; ifconfig ..." to get my usb network functioning because I cant use the touch screen. Jan 31 22:35:23 actually, you can blow away all of tmp but cache and the "handling bb files" should be much faster Jan 31 22:35:35 hehe Jan 31 22:35:42 I bought a SerialIO cable for mine Jan 31 22:35:48 in fact, I still have it Jan 31 22:35:54 and my 5500 is dead Jan 31 22:36:04 heh Jan 31 22:36:28 i bought one of those rubber roll up keyboards Jan 31 22:36:30 I'd be willing to give it to you, actually....if I could get it to you somehow Jan 31 22:36:32 i lost it a while back Jan 31 22:36:44 I don't have any use for it anymore Jan 31 22:36:56 heh i dont know if i'd use it Jan 31 22:37:04 ::shrug:: Jan 31 22:37:20 as long as i can get the wireless working, i prefer to ssh anyways Jan 31 22:37:37 I always ssh over USB... Jan 31 22:38:02 I use wireless too, but haven't for a while....my Z has been very minimal (music player only) for quite a while Jan 31 22:39:03 ok, I have to head to bed Jan 31 22:39:11 good luck with your compiling Jan 31 22:39:43 thanks for all your help man Jan 31 22:39:49 i'll let you know how it goes Feb 01 01:25:10 03jbowler 07org.oe.dev * rd69b634c... 10/conf/distro/slugos.conf: slugos: select ixp4xx-kernel 2.6.15.2 in conf Feb 01 01:29:49 03jbowler 07org.oe.dev * rf136d974... 10/packages/slugos-init/ (4 files in 3 dirs): Feb 01 01:29:49 slugos-init: add init script to handle USB device moving in 0.10 Feb 01 01:29:49 - the init.d script fixfstab uses blkid to build a partition/uuid Feb 01 01:29:49 mapping table and compares this to the version from the previous Feb 01 01:29:49 boot, if anything changes /etc/fstab is updated Feb 01 01:36:00 03jbowler 07org.oe.dev * r6287535c... 10/conf/distro/ (9 files): slugos: bump all version numbers to 3.2 for alpha testing in conf Feb 01 01:50:22 morning Feb 01 02:00:23 morning all Feb 01 02:06:32 shadows: I have a theory about the suspend/resume issues - it could be the fatalBatterycheck function playing up Feb 01 02:06:45 shadows: My machine failed to resume last night... Feb 01 02:07:15 RP: I mucked about with my Akita all day in 2.6.15-r2 with no issues Feb 01 02:09:42 morning Feb 01 02:10:20 morning XorA Feb 01 02:11:58 johnX: Its only done it once... Feb 01 02:12:12 ah Feb 01 02:19:11 morning Feb 01 02:20:51 moin Feb 01 02:22:41 <_guillermo> has anyone tried the pl2303 usb-serial converter modules succesfully? Feb 01 02:30:05 morning Feb 01 02:30:56 hey hrw|work Feb 01 02:32:25 morning hrw|work. d013_, zecke Feb 01 02:34:46 morning RP, hrw|work, zecke Feb 01 02:38:22 'hrw test2 images' releases Feb 01 02:38:28 s/es/ed Feb 01 02:43:36 good morning Feb 01 02:43:44 hi florian_kc Feb 01 02:43:48 florian_kc: good morning! Feb 01 02:43:50 zecke: good morning! Feb 01 02:44:15 _guillermo: on what platform? I use the pl2303 all the time on my laptop. Feb 01 02:44:49 my gps receiver and several of my usb-serial dongles are pl2303 based. Feb 01 02:45:05 <_guillermo> pb_ me too, and no problem, but in my akita a get info from my gps in 'blocks' Feb 01 02:45:14 <_guillermo> a lot of lines every 30 seconds or so Feb 01 02:45:49 <_guillermo> I found some bugs were corrected in 2.6.15git in that module, but I don't know if it could be that Feb 01 02:46:08 mm, dunno. are you just seeing a buffering issue, or is data actually missing? Feb 01 02:46:15 is there anything suspicious in the output from dmesg? Feb 01 02:47:21 might be worth trying with a powered hub, in case the akita's bus power is too puny to run your gps. I'm pretty sure my gps receiver needs more than the 500mW you can draw from a single bus load. Feb 01 02:48:50 _guillermo: Actually there are 2 types of pl2303 chipset. on pl2303 and one pl2303-C which identifies as a pl2303 but needs a patch to work Feb 01 02:49:04 <_guillermo> aps, really? Feb 01 02:49:24 <_guillermo> but in my desktop it's working! Feb 01 02:49:37 _guillermo: Yes i have been biten by this one recently :/ Feb 01 02:49:41 _guillermo: the akita might be supplying less power than the desktop Feb 01 02:50:53 _guillermo: Same kernel version on both machines ? 2.4 drivers for the pl2303 have this problem Feb 01 02:51:20 _guillermo: It's fixed on 2/6 Feb 01 02:54:03 <_guillermo> 2.6.15 in my desktop Feb 01 02:54:13 <_guillermo> 2.6.15git in my akita Feb 01 02:54:52 <_guillermo> about the power, I thought about that, but the product maker says in needs, at maximum, 80mA, and the akita should provide up to 100 Feb 01 02:55:24 _guillermo: do a diff on the pl driver to see if there are any differences Feb 01 02:56:51 <_guillermo> I will but, what about this patches http://seclists.org/lists/linux-kernel/2006/Jan/1197.html , are they already in our sources? Feb 01 02:58:13 I really get used to svk Feb 01 02:58:51 <_guillermo> pb_ the power hub trick could help, btw, I think I'm not missing anything, that the problem, and that's why I think could be buffering **** ENDING LOGGING AT Wed Feb 01 02:59:59 2006