**** BEGIN LOGGING AT Sun Jan 29 02:59:57 2006 Jan 29 03:00:11 jnc@baker:/tmp/goof$ diff -burN johnX/objdump-p-nano.log shadows/objdump-p-nano.log Jan 29 03:00:13 ... Jan 29 03:00:18 -nano: file format elf32-little Jan 29 03:00:18 +nano: file format elf32-littlearm Jan 29 03:00:26 maybe that's just objdump being different Jan 29 03:00:39 but that's rather odd Jan 29 03:00:47 i updated the wiki with instruction on how to set up OE on AMD64/ubuntu 5.10 -> http://oe.handhelds.org/cgi-bin/moin.cgi/RequiredSoftware#head-00c2efbe210c97ab0de10b6a54f4415cd260dca5 Jan 29 03:01:14 johnX: could you please make a post to the bug http://bugs.treke.net/show_bug.cgi?id=637 Jan 29 03:01:34 i am bad at explaining things sometimes Jan 29 03:01:59 i think you have a valuable viewpoint to add Jan 29 03:02:36 -nano is on amd ? Jan 29 03:03:00 the diff was from ia32 going to amd64 Jan 29 03:03:05 so the + lines are amd64 Jan 29 03:03:09 - lines are ia32 Jan 29 03:03:30 I think the elf32-little thing is caused by using an objdump that doesn't properly understand arm binaries. Jan 29 03:03:36 oh okay Jan 29 03:03:39 no big deal there Jan 29 03:04:31 yeah Jan 29 03:04:45 ok, that's the objdump from binutils on Debian unstable, I did those again with the objdump from binutils-cross that bitbake made Jan 29 03:04:49 probably need to diff the actual disassemblies to find out what's making the binaries different. Jan 29 03:05:02 jnc@baker:/tmp/goof$ objdump --version Jan 29 03:05:02 GNU objdump 2.16.91-multiarch 20051214 Debian GNU/Linux Jan 29 03:05:10 for debian etch amd64 (testing) Jan 29 03:05:35 grabbing binutils-multiarch Jan 29 03:05:41 that'd be her Jan 29 03:06:17 emte: looks like they removed the Caps in include named in evas.....and moved them.... Jan 29 03:06:21 pb__: could it be due to some non-explicit opt flags dragged in automagically by amd64? Jan 29 03:06:36 shadows: it shouldn't be, but anything is possible Jan 29 03:06:44 i read that things like -funroll-loops was default on amd64 Jan 29 03:06:52 I'll run those three commands again and put up new log files Jan 29 03:06:54 okay Jan 29 03:06:57 yeah, that should only be the case for amd64 targets Jan 29 03:07:06 oh! Jan 29 03:07:09 good point Jan 29 03:07:38 if you actually have the two machines side by side, try running some source file through arm-linux-gcc -O2 -S on both and diff the resulting .s files. Jan 29 03:08:09 pb__: err, could you suggest a good test case? Jan 29 03:08:12 i havent build any arm binaries yet but the x86 i build at least work ;/ Jan 29 03:08:25 like nano Jan 29 03:08:29 or something Jan 29 03:08:35 dunno. if nano is what you're looking at, just pick a source file from there. Jan 29 03:08:36 i'll try to build them on an intel machine and see if there are any differences Jan 29 03:08:39 i do not have ia32 to play with really Jan 29 03:08:42 okay Jan 29 03:09:04 you could use "size *.o" as a first step to see which files give different results on the two architectures Jan 29 03:09:15 nice Jan 29 03:09:38 shadows: I reran with binutils-multiarch objdump and put it in ftp://bloom.jads.com/pub/ Jan 29 03:09:44 johnX: size *.o output please for oetmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9/src Jan 29 03:10:44 ok Jan 29 03:10:47 it's in pub too Jan 29 03:11:48 ohhh Jan 29 03:11:53 one file is different sized Jan 29 03:11:59 winio.o Jan 29 03:12:44 - 20180 4 52 20236 4f0c winio.o Jan 29 03:12:44 + 20176 4 52 20232 4f08 winio.o Jan 29 03:13:02 that was from.. Jan 29 03:13:03 jnc@baker:/tmp/goof$ diff -burN johnX/size-nano-src.log shadows/size-nano-src.log Jan 29 03:13:12 fuck... cvs@sourceforge broken :( Jan 29 03:13:54 ah, but only by four bytes. What's the size difference you see in the final nano executable? Jan 29 03:13:57 ("size nano") Jan 29 03:14:11 jnc@baker:~/opensource/openzaurus/build/oetmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9/src$ size nano Jan 29 03:14:15 text data bss dec hex filename Jan 29 03:14:17 101931 808 844 103583 1949f nano Jan 29 03:14:18 johnX: your turn :) Jan 29 03:14:26 bitbake@Schala:~/tmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9/src$ size nano Jan 29 03:14:28 text data bss dec hex filename Jan 29 03:14:32 101935 808 844 103587 194a3 nano Jan 29 03:15:36 no byte unaccounted for Jan 29 03:15:50 okay, four bytes there as well. Jan 29 03:16:05 that's not a huge amount, obviously, but there shouldn't really be any difference at all. Jan 29 03:16:09 so, maybe not the linker Jan 29 03:16:22 I guess you need to diff the result of objdump -D winio.o now. Jan 29 03:16:36 * shadows pokes gnome-terminal Jan 29 03:17:16 it's there Jan 29 03:17:41 * shadows grabs Jan 29 03:18:37 wow Jan 29 03:18:50 hey could you post the C source for that real quick also Jan 29 03:19:00 i want to be 300% sure we're doing the same code Jan 29 03:19:10 winio.c? Jan 29 03:19:14 yes Jan 29 03:19:32 it's there Jan 29 03:20:05 okay Jan 29 03:20:10 same source 300% sure Jan 29 03:20:15 totally different output Jan 29 03:20:21 * shadows :/ Jan 29 03:20:36 I did objdump -D Jan 29 03:20:39 you did too right? Jan 29 03:20:41 yes Jan 29 03:20:45 i mean, the assembly Jan 29 03:20:51 it's wildly different Jan 29 03:21:00 i'll post, one second Jan 29 03:21:53 some of it is addresses and things Jan 29 03:23:03 http://jnc.pimpcat.org/files/oz/od32to64-D-nano_winio.diff Jan 29 03:24:04 I would have to agree: The output is different Jan 29 03:25:15 things like Jan 29 03:25:16 - 44e8: e59da004 ldr sl, [sp, #4] Jan 29 03:25:16 - 44ec: e59f12ec ldr r1, [pc, #748] ; 47e0 <.text+0x47e0> Jan 29 03:25:17 + 44e8: e59f12ec ldr r1, [pc, #748] ; 47dc <.text+0x47dc> Jan 29 03:25:56 yeah, that is interesting Jan 29 03:26:05 it looks like the register allocator is behaving a bit differently. Jan 29 03:26:22 small for an app like nano, but huge for a kernel? Jan 29 03:26:27 could be Jan 29 03:26:54 it's a big enough difference in object code that the kernel fails the sizecheck for cxxx0 models Jan 29 03:27:10 it's unsafe to flash a kernel that is over xyz number of bytes Jan 29 03:27:21 try "arm-linux-gcc -S -da winio.c" (using whatever other flags nano usually builds with) and diff the resulting files. That might give a clue as to where in the compiler things are diverging. Jan 29 03:27:40 okay Jan 29 03:27:54 a little help from you guys though, on what command to actually run. Jan 29 03:28:02 * shadows reviews logs Jan 29 03:28:25 * pb__ breakfast time now Jan 29 03:28:25 * johnX coudln't really program his way out of a wet paper bag Jan 29 03:28:33 back in a bit Jan 29 03:28:34 *laugh* Jan 29 03:29:09 okay what is the path to the cross compiler hmm Jan 29 03:30:10 ./build/oetmp/work/armv5te-linux/gcc-cross-initial-3.4.4-r3/image/home/jnc/opensource/openzaurus/build/oetmp/cross/bin/arm-linux-gcc Jan 29 03:30:30 is it initial Jan 29 03:30:39 or not the initial? Jan 29 03:30:42 tmp/cross/bin/arm-linux-gcc maybe? Jan 29 03:31:00 ah okay Jan 29 03:31:00 yes Jan 29 03:31:06 or for you oetmp/cross/bin/arm-linux-gcc Jan 29 03:31:30 NOTE: Update cvs://anonymous@cvs.sourceforge.net/cvsroot/gaim;module=gaim Jan 29 03:31:30 can't create temporary directory /tmp/cvs-serv28992 Jan 29 03:31:30 Too many links Jan 29 03:31:43 parse errors hrm. o_O need to poke flags Jan 29 03:31:44 it's sourceforge or me ? Jan 29 03:31:50 it's sf Jan 29 03:31:57 it was doing that to me the other night Jan 29 03:32:00 johnX: what google told me also Jan 29 03:32:19 pfff... Jan 29 03:32:40 obergix[home]:If you had a process making that many links in /tmp you'd probably notice it :) Jan 29 03:32:43 any way in bitbake to tell it to continue with the rest if one target fails ? Jan 29 03:32:56 johnX: df -hi would tell for sure Jan 29 03:33:13 sf == single point of failure Jan 29 03:33:54 obergix[home]: But it's a *free* single point of failure Jan 29 03:34:59 good morning Jan 29 03:35:10 mornin' Jan 29 03:36:37 shadows: any progress? Jan 29 03:37:10 johnX: no, though i've come up with another name for the problem Jan 29 03:37:33 poking the do_compile log Jan 29 03:38:14 shadows: Just to be sure, what are the CFLAGS in tmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9/src/Makefile Jan 29 03:38:43 I have: Jan 29 03:38:44 CFLAGS = -I/home/bitbake/tmp/staging/arm-linux/include -fexpensive-optimizations Jan 29 03:38:45 -fomit-frame-pointer -frename-registers -O2 Jan 29 03:38:46 johnX: a gratis one, but definitely not a libre one ;) Jan 29 03:38:52 export TARGET_CFLAGS="-I/home/jnc/opensource/openzaurus/build/oetmp/staging/arm-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2" Jan 29 03:39:31 export CFLAGS="-I/home/jnc/opensource/openzaurus/build/oetmp/staging/arm-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2" Jan 29 03:41:04 03jbowler 07org.oe.dev * r9ac526de... 10/packages/udev/ (7 files in 2 dirs): Jan 29 03:41:04 udev: make work with util-linux mount in all Jan 29 03:41:04 - busybox requires -o move, util-linux requires --move Jan 29 03:41:08 03jbowler 07org.oe.dev * r02736531... 10/ (3 files in 2 dirs): slugos-packages: add zip and devlabel in conf Jan 29 03:41:12 03jbowler 07org.oe.dev * rddf91516... 10/packages/linux/ (3 files in 2 dirs): Jan 29 03:41:13 ixp4xx-kernel: add rw back to nslu2 and nas100d command lines in 2.6.15.1 Jan 29 03:41:13 - on these two platforms the JFFS2 boots ro without the rw option Jan 29 03:41:17 03jbowler 07org.oe.dev * r49eb1e1a... 10/packages/busybox/ (busybox-1.01/slugos/defconfig busybox_1.01.bb): Jan 29 03:41:18 busybox: change slugos defconfig not to include mount/umount/swaponoff in 1.01 Jan 29 03:41:18 - the util-linux versions of the standard mount utilities are now used Jan 29 03:41:21 in the slugos images. Jan 29 03:41:23 03jbowler 07org.oe.dev * rf66aa4fb... 10/packages/initscripts/ (initscripts-slugos_1.0.bb initscripts_1.0.bb): initscripts: update comments with correct udev stop point in 1.0 Jan 29 03:41:27 03jbowler 07org.oe.dev * rf1f7cb96... 10/packages/slugos-init/ (20 files in 4 dirs): (log message trimmed) Jan 29 03:41:28 slugos-init: update for new LEDs, turnup save/restore suppport in 0.10 Jan 29 03:41:33 - /sbin/leds is now a script which uses /sys/class/leds Jan 29 03:41:35 All scripts are not in /sbin Jan 29 03:41:36 /sbin/sysconf does SysConf reading and now implements save/restore Jan 29 03:41:39 of the system configuration. Jan 29 03:41:40 turnup, reflash and sysconfsetup use /sbin/sysconf as appropriate Jan 29 03:41:43 03jbowler 07org.oe.dev * r7171148c... 10/.mt-attrs: slugos-init: remove unnecessary execute attributes in 0.10 Jan 29 03:42:35 salut alan|home Jan 29 03:43:10 lut obergix[home] Jan 29 03:49:05 hail zecke Jan 29 03:49:06 hi ph5 Jan 29 03:49:09 guh Jan 29 03:49:17 pb__: this is so heavily autotooled Jan 29 03:49:25 doing anything without "make" is failing Jan 29 03:49:26 heh Jan 29 03:49:37 shadows: doh Jan 29 03:49:42 i'm up to this... and failing... Jan 29 03:49:44 jnc@baker:~/opensource/openzaurus/build/oetmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9/src$ arm-linux-gcc -DPACKAGE_VERSION=1.3.9 -DVERSION=1.3.9 -DHAVE_VSNPRINTF -I/home/jnc/opensource/openzaurus/build/oetmp/staging/arm-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -S -da winio.c Jan 29 03:49:55 hi pb__ Jan 29 03:50:00 what's the error you get? Jan 29 03:50:06 winio.c:2751:30: too many decimal points in number Jan 29 03:50:11 related to some macro crap Jan 29 03:50:24 size_t verlen = strlenpt(VERMSG) + 1; Jan 29 03:50:40 nano.h:136:#define VERMSG "GNU nano " VERSION Jan 29 03:50:54 ah, probably need more quotes around VERSION Jan 29 03:51:00 -DVERSION=\"1.3.9\" or something Jan 29 03:51:03 ohhh Jan 29 03:51:06 will try Jan 29 03:51:39 for good or for awesome! Jan 29 03:51:42 it compiled. Jan 29 03:51:53 okay, so here's the deal johnX ... you're going to love this one Jan 29 03:51:58 ahaha Jan 29 03:52:02 I can tell Jan 29 03:52:57 nearest i can tell, the best thing you could do is grab the do_compile log output from your build of nano in the oe environment temp thing Jan 29 03:53:00 copy it Jan 29 03:53:15 cut out all the crap in the copy that is a function, about halfway down the file up to the end Jan 29 03:53:29 then save, and in your shell, source it (if using bash) Jan 29 03:53:39 that way you have all the env vars set up Jan 29 03:53:47 then from the src dir of nano sources... Jan 29 03:54:50 I think it ought to work without the environment stuff. johnX should be able to just take your command, replace the path to the staging directory with the one on his system, and run the resulting command with no other preparation. Jan 29 03:55:12 pb__: nano relies on headers from ncurses and junk Jan 29 03:55:23 yeah, but it will find them in the staging area Jan 29 03:55:34 yep Jan 29 03:55:41 that's what the -I/home/jnc/opensource/openzaurus/build/oetmp/staging is for Jan 29 03:56:00 just changing that one path should be sufficient Jan 29 03:56:25 i don't know. i've found bugs in gcc before, and i'm just good at running into things that are broken. how they work or what to do about fixing them, is magic smoke Jan 29 03:56:41 heh, fair enough Jan 29 03:57:03 your wisdom is awesomely appreciated, pb Jan 29 03:57:35 so I should run what? Jan 29 03:57:39 err Jan 29 03:58:11 nevermind Jan 29 03:59:48 pb__: okay so that command you suggested, it outputs a number of files Jan 29 04:00:06 what's the next step, once we have that output for mine and johnX's systems Jan 29 04:00:31 you need to diff the corresponding files on the two systems and find the first (lowest numbered) one that's different. Jan 29 04:00:41 oh wow, okay Jan 29 04:00:50 that should, hopefully, indicate the place in the compiler where the two are diverging Jan 29 04:02:44 johnX: how's it going, buddy Jan 29 04:03:15 you want me to run that command from up above, right except with the quotes that pb__ added, right? Jan 29 04:03:32 or do I actually need to source all those env vars? Jan 29 04:03:43 i would source the env vars, pb says it is unnecessary Jan 29 04:03:52 i sourced the env vars, and it worked Jan 29 04:04:07 to avoid making things overly complicated, that seems like the easy way to do this Jan 29 04:05:24 ok, ran that, didn't export the env vars Jan 29 04:05:32 what should be the result? Jan 29 04:05:54 after sourcing those vars, arm-linux-gcc -DPACKAGE_VERSION=\"1.3.9\" -DVERSION=\"1.3.9\" -DHAVE_VSNPRINTF -I${your oe temp}/staging/arm-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -S -da winio.c Jan 29 04:06:02 err Jan 29 04:06:07 if you just run it, nothing will happen Jan 29 04:06:14 ah Jan 29 04:06:17 if you do "source filename" Jan 29 04:06:26 bash sucks it into the existing environment as if you just typed it Jan 29 04:07:31 i ran the command line you have above Jan 29 04:08:19 if it results in a bunch of files winio.c.* then it worked Jan 29 04:08:58 then it worked Jan 29 04:09:02 hot diggity Jan 29 04:09:04 that's what I was asking earlier :) Jan 29 04:09:21 make a dir winio-dissection, copy winio.* into there Jan 29 04:09:24 and tbz2 it up Jan 29 04:09:39 re Jan 29 04:11:33 bzip2'ing Jan 29 04:11:58 okay. 3.7M bzip2'd, not too bad Jan 29 04:13:08 ftp://bloom.jads.com/pub/winio-dissection.tar.bz2 Jan 29 04:13:15 share and enjoy Jan 29 04:14:23 are you sirius? ;) Jan 29 04:14:50 heh Jan 29 04:17:12 things like um Jan 29 04:17:13 - (symbol_ref:SI ("edit") )) -1 (nil) Jan 29 04:17:13 + (symbol_ref:SI ("edit") )) -1 (nil) Jan 29 04:17:16 what the hell Jan 29 04:17:34 why would there be 32-bit addresses in one Jan 29 04:17:37 and 64-bit in another Jan 29 04:18:11 oh, right, drat Jan 29 04:18:18 those are host machine addresses Jan 29 04:20:07 koen|tv: http://lists.gnu.org/archive/html/monotone-devel/2006-01/msg00291.html Jan 29 04:20:10 pb__: naturally the 01.rtl is different Jan 29 04:21:05 pb__: is there something i should be trying differently? the trouble is that compiler output is differing from when it is run on ia32 versus being run on amd64 host Jan 29 04:21:51 shadows: can you send me your copies of those files to look at? Jan 29 04:21:56 yes sir Jan 29 04:21:59 I guess I can grab johnX's from the url he mentioned Jan 29 04:23:47 i'll tar up the whole mess and compress it Jan 29 04:24:09 okay, cool Jan 29 04:24:53 about 8MiB Jan 29 04:25:06 http://jnc.pimpcat.org/files/oz/oe-gcc-32to64derivation.tar.bz2 Jan 29 04:28:52 zecke: http://lists.gnu.org/archive/html/monotone-devel/2006-01/msg00286.html Jan 29 04:29:11 'a fresh pull is almost 7 times faster with rosters' <- with an OE tree Jan 29 04:30:33 zecke: what do you think about importing the bk history with the monotone history on top for the new scm? Jan 29 04:34:11 ping luke-jr_ Jan 29 04:34:26 !seen luke-jr_ Jan 29 04:34:27 Laibsch: luke-jr_ was last seen in # 6 hours, 51 minutes, and 35 seconds ago saying: ... Jan 29 04:37:00 hi koen, Laibsch, woglinde Jan 29 04:37:07 hey pH5 Jan 29 04:37:29 hi ph5 Jan 29 04:37:31 hi pH5, good to see you. How are you doing Jan 29 04:37:32 ? Jan 29 04:37:34 zecke wake up Jan 29 04:38:03 I let anthy devs know about the fabulous progress you made. Jan 29 04:38:15 woglinde: ja Jan 29 04:38:27 koen: from 8 hours to 1 hour Jan 29 04:38:50 zecke: faster as svn :) Jan 29 04:39:07 Laibsch: desperately trying to build udev-081+udevsynthesize patch, but otherwise fine, thanks Jan 29 04:39:11 koen: well that was localhost vs. machine Jan 29 04:39:19 remote machine on 10mbit Jan 29 04:39:58 pH5: Well, keep at it. I guess I won't really need it. Jan 29 04:40:01 ;-) Jan 29 04:40:55 zecke: but with the db snapshots initial pull for monotone isn't really a problem anymore Jan 29 04:41:13 okay bye Jan 29 04:41:26 pH5: Have you ever been in contact with luke-jr_about Japanese input method? He showed great interest, too. But i cannot reach him for the last couple of days. Jan 29 04:41:34 koen : I am working an a "build a minimal x86 with oe" wiki page. where should i added ? Jan 29 04:42:08 Ifaistos: no idea, create the wiki page and link it from the frontpage Jan 29 04:43:56 Laibsch: no... Jan 29 04:44:09 ok Jan 29 04:44:52 koen: well you can get behind with pulling and exchanging the db is not always what you want Jan 29 04:45:09 koen: and to some degree it defeats security (not that someone cares) Jan 29 04:48:41 zecke: monotone-dumb or monotone-cvssync would solve most problems Jan 29 04:52:55 pb__: please do let me know how it goes, and what your thoughts are on the compiler output differentiation. i'm to sleep now. my email: lucent@gmail.com Jan 29 04:53:18 shadows: okay, will do. good night. Jan 29 04:53:33 "monotone-dumb"? heh. Jan 29 04:53:38 koen: well it depends on the acceptance ;) Jan 29 04:54:13 shadows: 'night Jan 29 05:05:41 good morning Jan 29 05:05:56 mickeyl: hey Jan 29 05:06:39 zecke: http://oe.handhelds.org/cgi-bin/moin.cgi/ScmOverview Jan 29 05:06:40 good morning mickey Jan 29 05:06:45 hey mickeyl Jan 29 05:07:05 * koen heads of to see some penguins marching Jan 29 05:07:43 have fun, koen. this is a womens film, you know? Jan 29 05:07:49 :D Jan 29 05:13:56 France ping Jan 29 05:14:45 gerwinin: france is probably asleep, it's a bit early for him yet. Jan 29 05:16:17 oh sorry :) Jan 29 05:16:25 I thought he was in Europe as well Jan 29 05:16:37 morning twiun# Jan 29 05:16:38 no, he's on the US east coast Jan 29 05:16:57 hey mickeyl :) Jan 29 05:17:54 Wow. I swear Scott Adams has a spy in my office. Jan 29 05:17:56 http://dilbert.com Jan 29 05:18:55 heheh didn't know that I will shoot him a mail Jan 29 05:19:30 bummer, in the branch a lot of packages try to find their libs in $STAGING_LIBDIR/.libs - where does that behaviour come from? A world build looks pretty poor atm. Jan 29 05:19:38 example: /local/pkg/oe/collie/tmp/staging/arm-linux/lib/.libs/libasound.so: file not found Jan 29 05:19:51 who is to blame here? pkgconfig, libtool, ? Jan 29 05:19:54 autofoo? Jan 29 05:23:59 Mickeyl I had a similar problem with alsa with my epia distribution Jan 29 05:24:16 mickeyl: libtool, probably. do you have a libasound.la in your staging area? Jan 29 05:24:23 if so, try inspecting that file for suspicious contents Jan 29 05:25:09 pb: argh, here we are: Jan 29 05:25:16 dependency_libs=' -L/local/pkg/oe/collie/tmp/staging/arm-linux/lib -lm -ldl -lpthread' Jan 29 05:25:46 how can I fix this behaviour? IIRC this worked when I did the last world build some months ago Jan 29 05:26:16 oh wait, i don't see a full path there Jan 29 05:26:24 just -L, which should be ok Jan 29 05:26:30 yeah, that looks okay Jan 29 05:31:02 ah, I see koen has rolled the image-building dice again. Jan 29 05:31:11 * pb__ flashes the latest gpe-image Jan 29 05:37:13 which bitbake revision is to be used for branch again? Jan 29 05:37:33 * pb__ no idea Jan 29 05:38:02 I guess zecke or koen or hrw would know. Jan 29 05:38:10 yeah Jan 29 05:38:18 * mickeyl patiently waits until one of those are back Jan 29 05:38:27 mickeyl: dunno ;) Jan 29 05:47:48 I made a bb for the via padlock security tools shall I submit it to bugs.openembedded.org ? Jan 29 05:49:05 yeah, go ahead Jan 29 05:55:02 If I want to contribute a new patched kernel (because I need some extra drivers ) how can I do that ? Jan 29 05:56:02 morning Jan 29 06:06:18 mickey|newspaper: Any bitbake revision should work ok with the branch as they're backwards compatible Jan 29 06:07:03 hmm, i got a traceback when using the latest Jan 29 06:07:17 mickey|newspaper: oh Jan 29 06:07:22 RP: are you sure the CVSDATE->SRCDATE stuff is backwards compatible? Jan 29 06:07:22 len(eglibigle) couldn't be evaluated Jan 29 06:07:36 eglibigle apparantly wasn't a sequence Jan 29 06:07:41 this was while doing a world build Jan 29 06:08:06 reenoo: did people start to use SRCDATE in the branch? Jan 29 06:08:35 besides, i'm a bit worried about some changes done in .branch Jan 29 06:08:39 zecke: no, but wasn't bitbake patched to rename CVSDATE to SRCDATE? Jan 29 06:08:57 koen recently commited a change to modules.bbclass that breaks all our gcc 2.95.3 builds Jan 29 06:09:11 hi Jan 29 06:09:25 reenoo: it tries SRCDATE first, CVSDATE and then DATE Jan 29 06:09:47 zecke: ok, sorry, that sounds ok indeed Jan 29 06:10:46 mickey|newspaper: sounds like we need to zap HOST_CC_ARCH for 2.95.3 builds or something Jan 29 06:11:17 yeah. may i ask why it has been added anyway? i don't quite understand the commit message Jan 29 06:11:55 to... err.. prevent modules from being miscompiled? Jan 29 06:11:56 mickey|newspaper: :} Jan 29 06:12:30 aha, so we have been using miscompiled modules for three years now and we didn't see it. can't be that bad, can it? heh Jan 29 06:12:58 well. without the -march=... access to GPIOs on at least pxa machines will be incorrect Jan 29 06:13:32 ah right. this only refers to modules which do that low level stuff Jan 29 06:13:40 which are rare - external ones, that is Jan 29 06:13:43 mickey|newspaper: yah, you probably didn't fall victim to any of the troublesome cases. It only affects out-of-tree modules which do particular bit-flipping things. Jan 29 06:14:05 i see Jan 29 06:14:11 on the ipaq, it was breaking the alsa modules. Jan 29 06:14:45 does gcc-2.95.3 just not understand -march=? Jan 29 06:14:59 it doesn't understand the xscale switch Jan 29 06:15:03 tune, even Jan 29 06:15:10 oh, right Jan 29 06:15:48 well, that switch isn't actually required for correct operation, so a reasonable workaround for the branch might be to break the variable in half and leave that bit out for the modules. Jan 29 06:16:00 mickey|newspaper: Do you have a traceback from the latest bitbake? That sounds a bit like a bug? Jan 29 06:16:45 RP: i can reproduce it.# Jan 29 06:17:34 * mickey|newspaper launches bitbake -k world again Jan 29 06:22:05 grrr making a bitbake file for misdn_user is a drag Jan 29 06:22:48 can I use wildcards in overrides as in PREFERRED_VERSION_evas-* ?= "${EDATE}? Jan 29 06:24:14 RP: ok, here we are : Jan 29 06:24:18 http://pastebin.com/528667 Jan 29 06:25:45 CoreDump|home: no Jan 29 06:26:00 ah, would have been to easy I guess. Thanks Jan 29 06:26:01 mickey|newspaper: Are you sure that was the same error as last time? Jan 29 06:26:09 yes Jan 29 06:26:50 mickey|newspaper: Its just telling you it can't find any eligible providers to build. You don't need a traceback there but bb.error gives one by default Jan 29 06:27:08 * CoreDump|home writes PREFERRED_VERSION's for e-image in dev, since 0.0.10.xx is preserred over _${CVSATE}.bb Jan 29 06:27:15 no, that's not bb.error() giving a traceback Jan 29 06:27:23 bitbake is trying to evaluate len(None), by the looks of it Jan 29 06:27:35 it's probably just forgetting to stop after the error Jan 29 06:28:07 Ah, my browser cut out the last two lines :) Jan 29 06:28:19 03mickeyl 07org.oe.oz354fam083 * rdae12b3d... 10/packages/python/python_2.4.1.bb: python: fix SRC_URI (2.4.1) Jan 29 06:28:25 Speaking of the latest bitbake, it changed oe_libinstall and broke xerces-s Jan 29 06:28:29 http://bugs.treke.net/show_bug.cgi?id=635 Jan 29 06:28:47 can the changes in oe_libinstall be responsible for all the breakage in .branch ? Jan 29 06:28:55 (see my mail to oe) Jan 29 06:29:09 oe_libinstall is not from bitbake? Jan 29 06:29:13 The calls to filterProviders don't check for an error and should do Jan 29 06:29:14 Crofton: eh? oe_libinstall isn't part of bitbake. Jan 29 06:29:25 ups, of course not Jan 29 06:29:30 base class is oe Jan 29 06:29:34 right Jan 29 06:29:41 pb_, argh, you are correct Jan 29 06:29:48 but he change is still there :) Jan 29 06:30:14 what was the change? Jan 29 06:30:15 there is in script built by bb Jan 29 06:31:24 arg checking, I think the new way is 'better" Jan 29 06:34:45 do you guys have cbrpager in the package directory of .dev ? Jan 29 06:36:01 mickey|newspaper: http://www.rpsys.net/openzaurus/temp/bitbake_filtprov_fix-r0.patch should fix that error - its a bug in bitbake (introduced by me :-/) Jan 29 06:36:19 and unoticed by me Jan 29 06:37:48 zecke: We can only conclude that sadly neither of us is perfect :) Jan 29 06:40:20 we suck Jan 29 06:40:25 let us face it Jan 29 06:40:43 RP: can other lists be None as well? Jan 29 06:40:44 zecke: don't be so hard with yourself :) Jan 29 06:41:13 alan|xchat: well the quality of bitbake could be greatly improved Jan 29 06:41:57 zecke: Which others lists are you thinking about? Jan 29 06:42:16 morning Jan 29 06:43:13 morning chouimat Jan 29 06:44:41 zecke: To be honest I'd rather bitbake moved forward with the odd tiny bug rather than sat set in stone, undeveloped and unloved... Jan 29 06:45:01 mmm... i've got a newb question. "monotone: already up to date at 30c43de0d10703530b40f3820110767c65fc2a3b"... Is there an "officially lattest checksum" i could compare mine to ? Jan 29 06:54:43 alan|xchat: monotone.vanille.de? Jan 29 06:55:02 RP: well I don't like thet feeling that bitbake works due pure luck ;) Jan 29 06:55:14 RP: my University can be blamed for that though Jan 29 06:57:22 RP: ok, that fixed it. thanks Jan 29 07:03:57 mickey|newspaper: do you know which bb file provoked that? Jan 29 07:04:25 microwindows Jan 29 07:04:35 when its dependencies couldn't be built Jan 29 07:21:01 ~lart SF CVS Jan 29 07:21:02 * ibot puts SF CVS into a headlock and administers a mighty noogie, rubbing half of SF CVS's hair of Jan 29 07:24:45 JustinP: I had to set PREFERRED_VERSION for the e stuff for e to compile. Now I'm seeing your problem w/ entrance / edje_cc Jan 29 07:26:19 mickey|newspaper: koen@bitbake:~/OE/build$ bitbake --version Jan 29 07:26:19 BitBake Build Tool Core version 1.3.2.1, bitbake version 1.3.2 Jan 29 07:26:29 and r154 if I use svn correctly Jan 29 07:27:04 svn is currently on revision 337... Jan 29 07:27:22 ok, so I don't use it correctly Jan 29 07:27:37 Last Changed Author: zecke123 Jan 29 07:27:37 Last Changed Rev: 322 Jan 29 07:27:41 ah, that looks better Jan 29 07:27:56 and r332 in lib/ Jan 29 07:30:09 pb__: did you test the patch in #1488 with a build/boot? If so, I'll apply it ASAP Jan 29 07:30:59 I haven't tried a full image build yet, no. Jan 29 07:31:20 a build wouldn't be interesting, would it? Jan 29 07:32:12 not in itself, but booting from a freshly-installed system would be a good test. I guess I can simulate that by hacking my ipkg status file. Jan 29 07:32:35 or poking at a fresh jffs2/tar.bz2 file Jan 29 07:33:51 okay, here we go Jan 29 07:39:14 mm, not quite right. let me tweak the patch a bit. Jan 29 07:39:55 pb__: could you also make a patch relative to the ipkg/ dir? that would save me some regenerating to get it into OE Jan 29 07:41:42 okay Jan 29 07:41:50 zecke: did you get a reply yet to your monotone mail? Jan 29 07:41:56 mhh i got this -->>ERROR: Nothing provides runtime dependency ipkg-linkudev <<-- probably after last ipkg upgrade ... Jan 29 07:42:06 heh Jan 29 07:42:15 looks like someone forgot to add a space somewhere Jan 29 07:48:10 koen yes but i'm not able to find where ... `grep -r ipkg-linkudev *` find nothing :( Jan 29 07:49:57 gremlin[it]: it's probably the result of FOO_append = " ipkg-link" FOO_append = "udev" Jan 29 07:50:11 the second one is missing a leading space Jan 29 07:50:36 so FOO will be " ipkg-linkudev" Jan 29 07:50:56 pb__: heh. I like that patch :) Jan 29 07:51:56 pb__: it's funny nobody had that idea before... Jan 29 07:54:40 maybe classes/package_ipk.bbclass Jan 29 07:59:06 crap Jan 29 07:59:30 pb__: I turns out the patch needs to be made in the dist/ directory Jan 29 08:00:05 ah Jan 29 08:00:16 can you just fix it by hand? the patch only touches about half a dozen files. Jan 29 08:00:55 I can Jan 29 08:01:04 reenoo: heh. I remember discussing the idea with jamey a couple of years ago. Jan 29 08:02:12 koen yes 99% the missing space is in classes/package_ipk.bbclass Jan 29 08:03:22 koen: okay, thanks Jan 29 08:03:51 at least now buildinf is going forward ... Jan 29 08:05:19 hrrm Jan 29 08:05:30 gpe on a h3800 is missing some themes Jan 29 08:05:55 koen i have installed it ... Jan 29 08:07:26 I erased opie from the h3870 I have for work Jan 29 08:08:02 very good Jan 29 08:08:32 hihihiih :) Jan 29 08:11:31 do any of the opie and gpe targets work on x86/epia ? Jan 29 08:12:24 I think florian has used gpe on x86 at some point, though not epia specifically. Jan 29 08:13:17 looks like the x86 needs some love and attention :) Jan 29 08:14:53 yeah, most of the familiar and gpe folk are focussed on arm platforms Jan 29 08:27:46 JustinP: Well, it's choking on the variables IND etc. define IND doesn't seem to work in the theme file for whatever reason Jan 29 08:58:20 03koen 07org.oe.oz354fam083 * r3db3c816... 10/packages/gpe-login/gpe-login_0.85.bb: gpe-login: update to 0.85, fixing auto-login problems Jan 29 08:58:24 03koen 07org.oe.oz354fam083 * r76e3fb4d... 10/packages/ipkg/ipkg_0.99.157.bb: ipkg: update to 0.99.157, fixing problems with Replaces:, arch selection and string handling Jan 29 09:07:06 pb__: i poked a few GCC devs Jan 29 09:07:42 and i quote "< pinskia> shadows: most likely someone meesed up the differe Jan 29 09:07:50 err Jan 29 09:07:57 * shadows kicks paste error Jan 29 09:08:26 let's try that again... " < pinskia> shadows: most likely someone meesed up the different HOST_WIDE_INT sizes between the crosses" Jan 29 09:17:47 pb__: the gcc devs told me that there are many fixes in csl-arm-gcc branch Jan 29 09:18:36 shadows: Using the CSL branch in OE is a long term aim Jan 29 09:20:28 shadows: yeah, that sounds about right Jan 29 09:21:05 looking at what's different in the code, my guess is that something in the vicinity of arm_rtx_costs() is giving different results on the two systems. Jan 29 09:21:37 it might indeed be worth trying the csl-arm-branch or the gcc-4.1 branch to see if the problem persists there. Jan 29 09:22:49 pb__: okay Jan 29 09:23:01 is there a straightforward manner in which i could do that? Jan 29 09:23:08 pb__: You don't by chance know anyone who'd fancy adding the csl-arm-branch and/or gcc 4.1 to OE do you? Jan 29 09:23:31 heh Jan 29 09:23:54 i think there should be a check put in to stop AMD64 users from compiling anything with gcc 3.3.4, given that bug Jan 29 09:24:17 maybe a bit drastic, but important to make sure that messed up binaries don't become bug reports themselves Jan 29 09:24:52 shadows: The binaries might actually work but are just oversized... Jan 29 09:24:53 RP: isn't the csl-arm-branch in OE already? Jan 29 09:24:58 I thought it had been there for months. Jan 29 09:25:19 pb__: There is code there but its never produced working binaries Jan 29 09:25:36 What's wrong with the binaries it produces? Jan 29 09:25:44 pb__: koen and others have tried to update it but have never quite managed to make it all work Jan 29 09:26:41 pb__: I can't remember now but there were masses of bug reports for many strange issues which were all being caused by the csl branch, hence familiar and openzauius switched back to the normal toolchain Jan 29 09:29:23 RP: the binaries are different from ia32 gcc 3.3.4 output, which may be a problem for bugtesting Jan 29 09:29:29 whether or not they work Jan 29 09:30:31 http://bugs.treke.net/show_bug.cgi?id=204 Jan 29 09:31:23 shadows: I agree its an issue which needs to be monitored and a warning might be good. If the binaries are equivalent and just produce different code, it would be less of an issue than if the binaries were not equivalent though Jan 29 09:31:41 yes Jan 29 09:31:49 the big difference is the linux kernel Jan 29 09:32:12 it is a big enough difference that a kernel built on amd64 host _will not_ fit on the zaurus, without a functional change Jan 29 09:32:27 for cxxx0 zaurii Jan 29 09:32:49 pb__: Have a look at the link posted by shadows above for one example of csl problems (I remember seeing a lot more) Jan 29 09:33:13 shadows: Which zaurus do you have? Jan 29 09:33:23 RP: i own an C3000 (spitz) Jan 29 09:33:52 shadows: You could try compiling all of the MTD options and jffs2 as modules then Jan 29 09:34:40 zecke, should I add rwhitby to r/w for the svn repo? Jan 29 09:36:44 which bootloader can to run a kernel into a jffs filesystem? Jan 29 09:37:35 RP: how about compiling with -Os instead of -O2 for the kernel, with gcc 3.3.4 Jan 29 09:37:41 good/bad idea? Jan 29 09:38:18 shadows: Possibly worth a try. I remember seeing some comments that the kernel broken when compiled with that but who knows which version of gcc that was with... Jan 29 09:38:58 okay Jan 29 09:39:18 RP, in the last kernel 2.15 there is an option for compiling it with -Os (make menuconfig) Jan 29 09:39:25 if i have attempted 'bitbake virtual/kernel' and it fails at the size check, what to do such that it will rebuild the .config Jan 29 09:39:43 BleSS: I know its an option. That doesn't mean it will always work ;-) Jan 29 09:40:12 or must i scrap my oetmp and rebuild everything Jan 29 09:40:14 shadows: bitbake virtual/kernel -c configure -f might work Jan 29 09:40:44 okay Jan 29 09:40:51 RP, i say because that option was not in configuration menu (before of 2.6.15) Jan 29 09:41:30 which bootloader can boot kernel from JFFS? Jan 29 09:41:52 BleSS: not sure Jan 29 09:42:55 i think that bootldr is the only one - http://www.handhelds.org/handhelds-faq/bootldr.html Jan 29 09:43:11 BleSS: I think hh.org's LAB project can Jan 29 09:44:35 so can redboot, I think. Jan 29 09:45:06 RP: eh, i just nuked the stamps and the info in the work dir, seems to be doing what i wanted. thanks though Jan 29 09:45:08 yes, redboot can too Jan 29 09:52:27 gentlemen, i don't know how often you have a look at what pdaxrom team does, but i suggest you should have a look at this : http://www.oesf.org/forums/index.php?showtopic=17052&st=105 Jan 29 09:52:45 if it is not a fake, then i'm really impressed Jan 29 09:53:30 any idea why gpe-image requires iptables ? Jan 29 09:54:10 Ifaistos: My guess would be the networking config stuff Jan 29 09:57:18 Ifaistos: for gpe-shield, which is a firewall configuration tool Jan 29 09:58:38 ok. thanks ! For some reason it can not access netfilter.org Jan 29 09:59:04 ah Jan 29 09:59:44 o-kay. Jan 29 10:00:15 RP: making the JFFS2 and MTD stuff as modules, kernel builds and zImage is within the size constraint Jan 29 10:01:45 shadows: I guess the next test is to see if it boots :) Jan 29 10:01:49 aye Jan 29 10:02:19 safe enough to throw that on there with the rootfs from 2.4.20 embeddix kernel of oz 3.5.4fam083 branch? Jan 29 10:04:03 shadows: Yes and no. The 2.6 kernel boots driect from the microdrive so it won't get very far. It won't break anything either though Jan 29 10:04:17 oh okay. that's good enough to test Jan 29 10:04:34 i do not keep much important on my Z, it is a test platform for sacrifice to the OE gods Jan 29 10:06:53 heh Jan 29 10:07:18 does pxa270 have a fpu? Jan 29 10:09:09 Nope Jan 29 10:20:38 alan|: reading more into it, ZarPSX is the name ... hmm Jan 29 10:36:14 03rw 07org.oe.dev * re35f3ae6... 10/conf/distro/preferred-gpe-versions-2.7.inc: preferred-gpe-versions-2.7.inc: revert bogus changes introduced in e28d190b53d034845e4ae2fce2648104676a571b. Jan 29 10:36:41 RP: the 2.6.15-r1 image is booting (in what appears to be a success) on my hardware Jan 29 10:37:02 it's even working with the rootfs i had on there Jan 29 10:37:21 shadows: great :) Jan 29 10:37:29 in a stroke of irony though, the touch screen does not react Jan 29 10:37:32 when GPE starts Jan 29 10:37:33 heh Jan 29 10:37:39 actually this is OPIE, not GPE Jan 29 10:37:48 shadows: With a proper 2.6 image it will work Jan 29 10:37:52 nice Jan 29 10:38:26 so, how to make this well known in the OE codebase? Jan 29 10:38:57 how about a defconfig for cxxx0 that changes jffs2 and MTD to be modular? Jan 29 10:39:06 that doesn't make it clear why Jan 29 10:39:19 it would let amd64 users build though Jan 29 10:39:44 You'd break c1000 then Jan 29 10:40:02 oh hmm Jan 29 10:40:22 so what is the plan for 2.6 kernel and c1000 Jan 29 10:40:33 boot directly to... something Jan 29 10:40:49 shadows: It works just as well as it does for c3000 but the c1000 has nand flash, not a microdrive Jan 29 10:40:55 no HDD on akita, so flash it is Jan 29 10:41:01 I don't think this is something we neccessarily solve in OE atm - you have a workaround and in the long run a decent compiler should fix it Jan 29 10:41:27 okay Jan 29 10:41:35 leave the bug report open? Jan 29 10:41:49 http://bugs.treke.net/show_bug.cgi?id=637 Jan 29 10:43:09 Add a comment with the summary of what we've found - c3x00 users can work around by making jffs2 and mtd modular, c1000 users can make ext3 modular Jan 29 10:43:56 oh i guess it works both ways Jan 29 10:44:34 i would want to have an amd64 host c1000 user test that Jan 29 10:44:46 shadows: You can test it ;-) Jan 29 10:44:47 it's kind of a low priority thing though Jan 29 10:44:54 oh that's right Jan 29 10:44:56 hey, i will do that Jan 29 10:50:21 shadows: excuse me... off line for a few minutes... you were saying ? Jan 29 10:50:55 alan|home: i was making a comment on the zaurus port of psx emu Jan 29 10:51:07 it looks like an actively developed project Jan 29 10:52:03 yep. but too me, the most impressive is that 3D acceleration works... Jan 29 11:03:08 ~lart locale-def Jan 29 11:03:08 * ibot stabs locale-def Jan 29 11:14:29 kergoth: what about openembedded.org DNS ? Jan 29 11:46:22 what about it? Jan 29 11:51:49 koen|away, mickey|newspaper: would be good if you guys could merge the two heads of the release branch btw Jan 29 11:51:54 * reenoo|afk afk for real now Jan 29 11:53:55 jbowler-zzz: did you check in r36 of base-files_3.0.14.bb? Jan 29 11:54:01 kergoth: what's the matter with openembedded.org being down, more specificzally bugs.oe.org ? Jan 29 11:54:16 jbowler-zzz: (it looks to me like you did, but I'm not sure I am reading the logs right) Jan 29 12:00:01 opie-image builds for epia (with a little help) :) Jan 29 12:01:39 it boots too. but with a lot of dbus related errors :( Jan 29 12:17:02 kergoth: is my question embarassing ? Jan 29 12:18:10 Ifaistos: that's odd, I don't think you should have any dbus stuff at all in an opie image Jan 29 12:21:34 pb_: not sure, let me check the diff Jan 29 12:22:21 pb__: Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory Jan 29 12:22:36 pb__: This is what i get after reboot Jan 29 12:23:30 pb__: Login for the console does not work either. I get a :Cannot set group: Operation not permitted" message Jan 29 12:24:19 pb__; ssh works ok Jan 29 12:26:04 pb__: Bootsplash does not have an entry for epia Jan 29 12:26:42 that login problem sounds like the login program is not running as root for some reason Jan 29 12:26:51 pb__: is this change back in the BitKeeper logs? Jan 29 12:26:56 jbowler: no, in monotone Jan 29 12:27:16 Curious, monotone log is giving me absolutely no output for that file. Jan 29 12:27:26 that is odd Jan 29 12:27:50 I was actually looking at zecke's tailorized git repository, but (afaik) the data in there is derived from monotone Jan 29 12:28:39 It's in there, it's just that 'log' can sometimes do weird selections. Jan 29 12:28:46 zecke: fyi, a black mark against darcs: "darcs annotate" on a single file takes 15 minutes to run on my sempron 3100+ and consumes just under 2GB of RAM. Jan 29 12:29:30 also, "darcs trackdown" crashes with some complaint about not being able to apply a patch to gnu-config.bb (which, in a manner reminiscent of monotone, it claims is "user error"). I couldn't work out how to fix that. Jan 29 12:29:55 pb__: r36 was ccsmart@smartpal.de's change to implement the populate-volatile.sh stuff, revision 42c8721fc380bf1630edd879420ff3c586f4752d Jan 29 12:30:25 What's the problem? Jan 29 12:30:25 okay Jan 29 12:30:48 it seems to have broken familiar on the ipaq; we don't get any /etc/resolv.conf -> /var/run/resolv.conf symlink anymore Jan 29 12:31:06 which, on the face of it, is unsurprising because that revision deleted the whole block of code that was responsible for making those links Jan 29 12:31:32 pb__: okay Jan 29 12:31:36 I'm guessing that the bits in question were moved to some other file, which we either don't have or aren't using right. Jan 29 12:31:40 He changed the _nylon and _openslug rules which create an empty resolve.conf, but the change, while wacky, should be harmless Jan 29 12:31:42 pb__: logread output -> http://pastebin.com/529122 Jan 29 12:32:20 I believe there should probably be a 'do_install_append' (no suffix) which creates the link for everything else. Jan 29 12:32:34 jbowler: yeah, the nylon and openslug changes do look a bit weird (but, as you say, harmless enough). I was more worried about the big deletion starting at: Jan 29 12:32:43 - if (grep -q "^\(tmpfs\|ramfs\)\W\+/var" ${D}${sysconfdir}/fstab); then Jan 29 12:32:43 - # /var is in a ramdisk Jan 29 12:33:18 it seems that a whole pile of stuff has just been removed there, with no obvious replacement. Jan 29 12:33:35 Right, that's the populate-volatile.sh change - that should be in populate-volatile.sh Jan 29 12:33:58 Where is populate-volatile.sh? Jan 29 12:33:59 CoreDump|home: I'm not setting any PREFERRED_VERION for e stuff....this is strange....have you updated your bitbake? Jan 29 12:34:02 obergix[home]: the dns is down because i was unemployed and couldnt pay the bill. its that simple. Jan 29 12:34:26 JustinP: yes, everything is up to date. Dunno why that is Jan 29 12:34:48 CoreDump|home: very veyr strange..... Jan 29 12:35:04 kergoth: i'd be glad to offer some payment, depending on the amount Jan 29 12:35:06 pb__: in an image /etc/init.d/populate-volatile.sh and /etc/default/volatiles - I've noticed that 00_core has nothing for resolv.conf though. Jan 29 12:35:21 I can live with having to set versions, but the edje thing is a bitch Jan 29 12:35:44 ah right, yeah, I do have populate-volatile.sh in my image Jan 29 12:36:02 Source is packages/initscripts Jan 29 12:36:52 okay, thanks. I guess I'll assign the bug to ccsmart and let him take care of it. Jan 29 12:37:12 yes, it is Jan 29 12:37:26 I've even tried updating everything to very very recent and it doesn't help Jan 29 12:37:51 (also evas seems to have undergone a structure change which breaks everything...themost recent everything else required an evas from the 13th) Jan 29 12:38:45 JustinP: tried that, too to no avail. The #define Blahh doesn't work in the theme file Jan 29 12:43:09 * CoreDump|home plays with altboot under kernel 2.6 Jan 29 12:43:24 add support for kexec Jan 29 12:43:26 heh heh Jan 29 12:43:37 heh that would be neat Jan 29 12:43:51 then you could dual boot the SharpROM Jan 29 12:44:05 and once kexec is in the kernel, I'll do that Jan 29 12:46:37 CoreDump|home: as of 2.6.15, it is Jan 29 12:46:44 :) Jan 29 12:46:44 I have the kexec patch here and am working on zaurus kernels - haven't got up to that yet though :) Jan 29 12:46:55 shadows: no kexec on arm yet Jan 29 12:47:03 heh Jan 29 12:47:03 oh! didn't know that Jan 29 12:47:54 but lets get basic functions to work first Jan 29 12:48:34 what is _with_ bugs.openembedded.org not resolving Jan 29 12:48:57 !lart DNS Jan 29 12:48:57 shadows: the openembedded.org dns is broken. do like it says in the topic and use bugs.treke.net instead. Jan 29 12:48:58 * cdbot chops DNS in half with a free Solaris 7 CD Jan 29 12:49:15 pb__: links on the bugtracker point to oe.org though Jan 29 12:49:41 so, i am manually restructuring links and stuff Jan 29 12:49:48 it's something of an irritant :/ Jan 29 12:50:33 yeah, that is a bit sucky Jan 29 12:52:25 http://bugs.treke.net/show_bug.cgi?id=637 updated Jan 29 12:52:41 could someone please poke the build to emit a warning and quote that bug? Jan 29 12:54:08 ack Jan 29 12:54:16 akita is C1000 Jan 29 12:54:19 updated . Jan 29 12:54:25 i'm so done with this bug. Jan 29 12:56:16 Ifaistos: oh! that seems to be gpe, not opie. Jan 29 12:58:53 pb__: yes you are right. stupid me :( Jan 29 12:59:47 for the dbus thing, try starting the d-bus daemon by hand (/etc/init.d/dbus start) and see what happens Jan 29 13:02:48 pb__: root@epia:/etc/init.d# ./dbus-1 start Jan 29 13:02:49 Starting system message bus: start-stop-daemon: unknown user name: messagebus Jan 29 13:02:49 root@epia:/etc/init.d# Jan 29 13:02:56 oh Jan 29 13:03:05 what happens when you create a user messagebus ;) Jan 29 13:03:06 Is it possible to chroot to the staging arm dir via qemu, but use native cross-compilers? Jan 29 13:03:30 Ifaistos: hm, seems that your postinst scripts didn't run properly Jan 29 13:03:40 RP: did ryoohki talk to you? Jan 29 13:03:42 try "ipkg configure", in case some packages are unconfigured Jan 29 13:04:14 luke-jr_: no? Jan 29 13:04:29 RP: is the SD driver compiled into the kernel? Jan 29 13:04:37 CoreDump|home: yes Jan 29 13:04:42 ah thx Jan 29 13:04:53 RP: he's the guy who said he's successfully used a builtin C760 mic w/ 2.4 Jan 29 13:04:55 CoreDump|home: In theory you can boot from it Jan 29 13:04:55 pb__: Nothing to be done Jan 29 13:05:49 but I'd have to recompile my kernel /w new parameters right? Jan 29 13:06:35 hmm Jan 29 13:06:40 luke-jr_: I have a c760 and I'd swear it doesn't have an inbuilt mic... Jan 29 13:06:49 there should be a way to change the kernel boot args on an image Jan 29 13:06:54 we need to come up with such a tool Jan 29 13:07:08 pb__: The kernel looks like its missing fb support and i can imagine other things also Jan 29 13:07:16 shadows: Feel free to hack the sharp boot loader ;-) Jan 29 13:07:25 i mean, for host machine Jan 29 13:07:27 RP: he told me he's actually used it successfully Jan 29 13:07:34 heh Jan 29 13:07:39 Ifaistos: that would be a problem Jan 29 13:07:45 kdrive won't run without fb support Jan 29 13:07:57 but kexec _will_ let me set the parameters right? Jan 29 13:07:57 You can use the xorg xserver though, that's what I do on the epia Jan 29 13:07:59 to not have to recompile a zImage / image for cxx00 Jan 29 13:08:12 just run a command on it and modify the kargs Jan 29 13:08:29 CoreDump|home: Yes, although you'll need a kernel which hasn't had its commandline fixed (which is easy to make in OE) Jan 29 13:08:47 pb__: There is no xorg on the image build Jan 29 13:08:57 RP: hmm that could complicated things tho Jan 29 13:09:22 Ifaistos: indeed, you'd need to select it at image building time Jan 29 13:09:39 or install it from .ipks at runtime Jan 29 13:09:55 omg! the pwr button actually suspends the machine, nice! Jan 29 13:10:05 pb__: I'll try and fix the kernel first and then see which way to go Jan 29 13:10:14 ok Jan 29 13:10:37 pb__: At least it compile and it boots.... It's a start :) Jan 29 13:10:45 CoreDump|home: With the Sharp bootloader, we have no choice but to fix the commandline Jan 29 13:10:51 Ifaistos: heh :-) Jan 29 13:11:19 so we flash a fixed barebone kernel and kexec the real one. Jan 29 13:11:41 CoreDump|home: um... pwr button always suspends... Jan 29 13:11:52 luke-jr_: not on 2.4 / akita Jan 29 13:11:58 o Jan 29 13:12:06 (akita / borzoi / spitz) Jan 29 13:19:31 koen|away, mickey|newspaper: oz354fam083 is a hydra Jan 29 13:25:20 * CoreDump|home preps an SD card Jan 29 13:36:17 CoreDump|home: that's the idea Jan 29 13:36:40 ? Jan 29 13:36:52 sorry, i'm a bit late reading all this Jan 29 13:37:08 heh Jan 29 13:37:09 talking to simcop about a bug Jan 29 13:49:21 mmh Jan 29 13:49:24 | arm-linux-gcc: /local/pkg/oe/collie/tmp/staging/arm-linux/lib/.libs/libXau.so: No such file or directory Jan 29 13:49:29 this bug is starting to anny me Jan 29 13:49:31 annoy, even Jan 29 13:50:36 oh dear, sounds like the contagion is spreading Jan 29 13:51:07 can't build diet-x11 anymore Jan 29 13:52:02 doh Jan 29 13:56:37 <[cc]smart> pb_: in ? Jan 29 13:56:41 mickeyl: you have a bogus pkgconfig Jan 29 13:56:42 <[cc]smart> pb__: in ? Jan 29 13:56:47 [cc]smart: hello Jan 29 13:56:50 koen|away: where? Jan 29 13:56:51 <[cc]smart> hi Jan 29 13:56:55 <[cc]smart> just read about that bug Jan 29 13:57:02 ah right, the resolv.conf thing? Jan 29 13:57:07 mickeyl: or stuff built with said bogus pkgconfig Jan 29 13:57:14 <[cc]smart> yes, jbowler gave me some details but i'm not sure Jan 29 13:57:25 hmm. the problem occurs both in .dev and .branch for me Jan 29 13:57:45 and always from a fresh built Jan 29 13:57:46 <[cc]smart> if i get it right there is one crated durign boot in /var/tmp for some OS and not for others Jan 29 13:57:56 so are our latest versions broken or what? Jan 29 13:58:18 the ones with a custom .m4 in SRC_URI are likely to be brtoken Jan 29 13:58:23 <[cc]smart> for those others, there's a zapping in pace therefore as it was always created before Jan 29 13:58:31 [cc]smart: I'm not exactly sure either. All I know is that, with older versions (before r35) of base-files, a symlink to /var/run/resolv.conf was created in /etc, and this isn't happening (on Familiar) with newer versions. Jan 29 13:58:41 koen: well, we have only one pkg version in Jan 29 13:58:44 01.5.0 Jan 29 13:58:46 0.15.0 even Jan 29 13:58:52 -native has the pkg.m4 in Jan 29 13:59:01 if that's known to be bogus, why it's still in? Jan 29 13:59:15 mickeyl: :( Jan 29 13:59:58 zecke, I assume I should add rwhitby to the rw list for svn? Jan 29 13:59:59 weird Jan 29 14:00:06 <[cc]smart> thre are 2 possibilities a) we create this symlink for all OS during boot and therefore add it to base. that is, add an entry to /etc/default/volatiles/00_core b) we create a new /etc/default/volatiles/01_resolv.conf which would only be added by OS that want this link Jan 29 14:00:07 at least the branch builds for me without problems Jan 29 14:00:22 Crofton: yes. I think you can add anyone Jan 29 14:00:30 ok Jan 29 14:00:37 I'll let you know as they appear Jan 29 14:00:42 everyone even.. Jan 29 14:00:43 thanks Jan 29 14:00:57 [cc]smart: okay. I can't think of any reason why any OSs would not want that link, but I guess just doing it for Familiar would be the safe option. Jan 29 14:01:14 ok, let' Jan 29 14:01:20 s see what happens without the m4 Jan 29 14:01:43 [cc]smart: something also needs to be done about the upgrade path from older versions of familiar; base-files's postinst will need to create that link somehow, since the upgrade will have removed it. Jan 29 14:01:58 <[cc]smart> pb__: my problem is, currently i can't apply it myself, cause my server is bust. the line to use would be as follows: l root root 644 /var/tmp/resolv.conf /etc/resolv.conf Jan 29 14:02:14 <[cc]smart> there is an explanation for that in /etc/default/volatiles/00_core Jan 29 14:02:24 <[cc]smart> could you add that for me and check that it does ? Jan 29 14:02:38 okay, let me try that on my ipaq now Jan 29 14:02:56 <[cc]smart> the first caracter is lowercase L Jan 29 14:03:01 <[cc]smart> for lik Jan 29 14:03:05 right Jan 29 14:03:05 <[cc]smart> er, link Jan 29 14:03:08 * pb__ cut and paste Jan 29 14:03:22 so, I just put that in /etc/default/volatiles/01resolv.conf? Jan 29 14:03:25 <[cc]smart> er /var/run i think oyu said Jan 29 14:03:39 <[cc]smart> add an underscore in thre Jan 29 14:03:53 ah right Jan 29 14:04:07 <[cc]smart> jbowler wasn't sure about the actual target file so we concluded /var/tmp Jan 29 14:04:10 okay, rebooting, let's see what happens Jan 29 14:04:13 <[cc]smart> probably you have to adjust Jan 29 14:04:24 yeah, I'll check the old .bb file to be sure of the location Jan 29 14:05:25 hm, didn't work Jan 29 14:05:40 is there anything else I need to do to make it use 01_resolv.conf? Jan 29 14:05:56 <[cc]smart> no, just placing it in the right directory Jan 29 14:06:02 <[cc]smart> give me a sec Jan 29 14:06:27 root@h3900:/etc/default/volatiles# ls -l Jan 29 14:06:27 -rw-r--r-- 1 root root 1527 Jan 1 1970 00_core Jan 29 14:06:27 -rw-r--r-- 1 root root 55 Jan 29 2006 01_resolv.conf Jan 29 14:06:32 that's what I have now Jan 29 14:07:35 hrm Jan 29 14:07:42 if I run populate-volatile.sh by hand, it says: Jan 29 14:07:47 root@h3900:~# /etc/init.d/populate-volatile.sh Jan 29 14:07:47 Undefined users: Jan 29 14:07:47 /etc/init.d/populate-volatile.sh: 137: diff: not found Jan 29 14:07:47 Skipping /etc/default/volatiles/01_resolv.conf Jan 29 14:07:47 root@h3900:~# Jan 29 14:07:56 that doesn't sound entirely good Jan 29 14:11:41 <[cc]smart> seems populate-volatile go some enhancents... in any case looks like the two paths need to be esxchanged for each other Jan 29 14:12:03 okay, I try that Jan 29 14:12:21 <[cc]smart> is there a web possibility where i can see the actual current version of the script ? Jan 29 14:12:57 <[cc]smart> monotone is down for me until i have some real installation again (you see me typing from a bootable Knoppix CD) Jan 29 14:12:59 that did't make any difference, still "Skipping /etc/default/01_resolv.conf" Jan 29 14:13:03 (and no symlink) Jan 29 14:13:16 I think there is a viewmtn thing, but I don't know the url. Jan 29 14:13:22 mickeyl or koen or zecke might be able to help you out Jan 29 14:13:48 the viewmtn on vanille.de appears to be defunct and I forget the url to that on ewi Jan 29 14:13:55 ~ewi Jan 29 14:13:57 extra, extra, read all about it, ewi is ewi546.ewi.utwente.nl - main backup server for OE monotone. Hosts database snapshot: http://ewi546.ewi.utwente.nl/OE/OE.db.bz2 Jan 29 14:14:13 or I guess I can just copy /etc from an image into my public_html dir if you want Jan 29 14:14:26 that might be the easiest thing if you just want to see the script Jan 29 14:14:47 <[cc]smart> yes, copy the populate-volatile.sh please Jan 29 14:16:08 okay. might take a minute, handhelds.org is pretty slow right now. Jan 29 14:17:05 handhelds.org/~pb/populate-volatile.sh Jan 29 14:18:46 http://monotone.vanille.de/viewmtn/ looks as it works Jan 29 14:18:56 albeit slow due to the load on that machine Jan 29 14:19:17 * mickeyl kicks it a bit Jan 29 14:19:57 ah, heh, you have problems with excessive load as well? Jan 29 14:20:09 h7 seems to be sitting at a pretty constant load of about 25 these days. Jan 29 14:20:21 yeah, viewmtn is crazy because it starts a lot of monotone processes which slow my machine down to a crep Jan 29 14:20:23 creep even Jan 29 14:20:30 ah, nasty Jan 29 14:21:34 <[cc]smart> pb__: make sure you didn't add an empty line to 01_resolv.conf Jan 29 14:22:11 ah Jan 29 14:22:14 I did add an empty line Jan 29 14:22:16 * pb__ deletes it Jan 29 14:22:22 Crofton: thanks for thinking to add me to rw list for svn. I tried the mirror command with svk, but it took soooo long and timed out at revision 69. Jan 29 14:22:36 The plain svn checkout, of course, was fine. Jan 29 14:22:36 [cc]smart: rock, now it works. thanks. Jan 29 14:22:55 [cc]smart: so, that just leaves the issue of ipkg upgrades from older versions. any idea how to deal with that? Jan 29 14:22:58 <[cc]smart> np. just add the file to the distro then Jan 29 14:23:02 <[cc]smart> thx Jan 29 14:23:15 <[cc]smart> er Jan 29 14:24:05 rwhitby-away: svk sync again, Crofton's server is behind a 10 mbit link Jan 29 14:24:09 <[cc]smart> what would be the catch ? don't see it currently. you'd add the file and populate-volatile.sh needs to be in place with 00_core Jan 29 14:24:37 people who are currently running familiar 0.8.2 have the /etc/resolv.conf symlink provided in base-files. Jan 29 14:24:57 <[cc]smart> rerun populate-volatile. it should not be problem. Jan 29 14:25:02 if they upgrade base-files to the new version, the symlink is deleted (because it's no longer in the package) and their system is broken because dns lookups stop working. Jan 29 14:25:10 zecke: is the multi-hour initial sync for svk vs some minutes for svn justified? What's it doing extra? Jan 29 14:25:15 so, yeah, I guess base-files needs to rerun populate-volatile from its postinst or something. Jan 29 14:26:01 rwhitby-away: it is downloading every revision Jan 29 14:26:09 <[cc]smart> don't remember where populate-volatile is in... ah. ic Jan 29 14:26:26 <[cc]smart> populate is automatically done every boot Jan 29 14:26:26 it's in initscripts, I think Jan 29 14:26:39 <[cc]smart> it's original intent is populating ram disks Jan 29 14:26:43 right, but it would suck if people had to reboot midway through upgrading Jan 29 14:26:49 koen: I'm pulling monotone root-dir-rename branch Jan 29 14:27:07 <[cc]smart> then yes. ia lso doe rerun populate during postinstall of postfix or cyrus stuff Jan 29 14:27:09 koen: it has 3.338 revs as well and it looks fast Jan 29 14:27:37 <[cc]smart> actually, i move postinstall taks out into /etc/default/volatiles files and leave the installation to that scipt Jan 29 14:27:51 <[cc]smart> this way i catch all cases. static and ram filesystems Jan 29 14:28:07 rwhitby-away: svk sync should do nothing more than fetching revisions Jan 29 14:28:16 also, if someone didn't realise immediately that they needed to reboot, there is a risk that dhcpcd would create /etc/resolv.conf as a regular file and then a subsequent run of populate-volatile would refuse to overwrite it. Jan 29 14:28:32 that way, they'd be left with resolv.conf sitting in flash, which would be a big lose. Jan 29 14:28:40 <[cc]smart> correct. you can run populate as part of postinstall Jan 29 14:28:45 okay Jan 29 14:29:38 <[cc]smart> if you see the chance of other familiar specific entries, you might also want to name the file 01_familiar instead or such Jan 29 14:30:31 zecke: ah, ok - I get it, you're retrieving the whole history, not just the HEAD. Jan 29 14:30:39 unfortunately 0.8.2 didn't have populate-volatile, so I guess base-files is also going to have to depend on the newer initscripts. That should still be ok though. Jan 29 14:31:35 [cc]smart: thanks for all that Jan 29 14:31:46 <[cc]smart> np. glad if i can give sth. back. Jan 29 14:33:47 RP: could you give me the url to the patch again? Jan 29 14:33:54 (bitbake el*) Jan 29 14:35:13 rwhitby-away: what svk does is, use 'svn' locally (in a depot) Jan 29 14:41:04 rwhitby-away, I added you to the rw list Jan 29 15:05:41 rwhitby-away: e.g I use svk to merge between my svn repo on ewi to crofton's server Jan 29 15:06:00 oh hey there's an idea Jan 29 15:06:27 change our hosts files on desktop machines to reflect bugs.openembedded.org Jan 29 15:06:40 shadows: /topic Jan 29 15:07:09 err Jan 29 15:07:19 well i hadn't considred modifying my hosts file to compensate Jan 29 15:07:31 shadows: use bugs.treke.net ;) Jan 29 15:14:19 sounds for my c750 works on 3.5.4RC gpe... Jan 29 15:14:23 but... Jan 29 15:14:34 only if i log into GPE as root Jan 29 15:15:22 i compiled my own mplayer-atty to try to watch a movie. Jan 29 15:15:46 sound won't work if logged as user Jan 29 15:16:03 even when mplayer is launched from root terminal Jan 29 15:16:24 you _must_ be root to have it work Jan 29 15:17:06 that's weird Jan 29 15:17:11 is there a sound daemon? Jan 29 15:17:12 i hope this information is helpfull a way or another. I'll get back here tomorrow, and will see if it worth openning a bug Jan 29 15:17:33 shadows: i don't know and i'm too tired to keep on trying Jan 29 15:17:36 bye Jan 29 15:17:39 thanks Jan 29 15:17:42 have a good night Jan 29 15:17:45 ^^ Jan 29 15:17:51 you too Jan 29 15:21:05 Is anybody inclined to take a look at http://prdownloads.sourceforge.jp/zaurus-ja/9316/imkit-0.4.5.tar.gz ? It is probably the missing link before we have the first Japanese input method on OpenEmbedded (YEAH!). I do not see anything called configure or MAKEFILE or some such. How does this thing compile. I also looked into the Japanese README and INSTALL file but from I can tell there aren't really any instructions on how to compile this either. Jan 29 15:21:40 I guess, this might be trivial for somebody who knows about compiling (which I don't really), I'm just poking around. Jan 29 15:22:02 I do see some .cpp and .h files which I think are related to compilation. Jan 29 15:22:02 03rw 07org.oe.dev * r73f0bcea... 10/conf/distro/preferred-gpe-versions-2.7.inc: preferred-gpe-versions-2.7.inc: sync with oz354fam083 branch. Jan 29 15:22:07 03rw 07org.oe.dev * r11a3bd09... 10/packages/figment/ (files/dotdesktop-name-comment.patch figment_0.3.5.bb): figment: adjust name and comment in .desktop file to match naming scheme of other GPE apps. Fixes hh.org Bug #1463. Jan 29 15:22:11 03jbowler 07org.oe.dev * r34633137... 10/packages/beep/beep-1.2.2/linux-input.patch: beep: release with Debian event/dwery patches in 1.2.2 Jan 29 15:22:15 03xora 07org.oe.dev * rdde70ffa... 10/packages/evince/ (evince-0.5.0/more-no-doc.patch evince_0.5.0.bb): evince_0.5.0.bb : add new version Jan 29 15:22:51 good nite Jan 29 15:23:44 good night zecke Jan 29 15:25:50 zecke: sweet dreams Jan 29 15:26:54 Laibsch: that imkit thing seems to contain some .pro files, which I think are the requisite magic tokens that you need to build opie programs. Jan 29 15:30:20 pb__: Thank you for the hint. Seems to make a lot of sense since the containing folders seem to correspond to the three packages that can be build from this source. Jan 29 15:30:52 How would I build .pro in OE? What do I need to inherit and how do I call oe_runmake? Jan 29 15:31:39 I'm not sure. That might be a question for mickey|tv, or for the h4x0rs in #opie. Jan 29 15:32:11 OK, maybe mickey|tv will react. I'll also ask in #opie Jan 29 16:42:59 03rw 07org.oe.dev * re4d8da41... 10/classes/package.bbclass: package.bbclass: don't silently ignore errors when running STRIP. Set IGNORE_STRIP_ERRORS to get the old behaviour back. Part of a fix for hh.org Bug #1469 Jan 29 16:44:02 doesnt strip return a non-zero exit code when run against a shell script? Jan 29 16:44:17 and doesnt package.bbclass run it against all executables, or does it check the actual file type? Jan 29 16:44:20 heh Jan 29 16:44:33 it (used to) run it against everything executable and ignore errors. Jan 29 16:44:44 which, as Rene discovered, sucks because it also ignores errors caused by write-protected executables Jan 29 16:45:39 that new patch changes it to only run against things that are actually unstripped binaries, and no longer ignore errors. Jan 29 16:47:58 pb__: right. thanks for explaining. I've been busy updating the bug in hh.org bugzilla ;) Jan 29 16:48:05 heh :-) Jan 29 16:48:45 it seems hh.org is having a hard time again (cpu load) Jan 29 16:49:19 yeah Jan 29 16:49:31 it's actually more of a problem with disk speed than cpu load, by the looks of things. Jan 29 16:49:46 oh, ok Jan 29 16:50:16 h7 is running a pretty constant load average of around 25 to 30, but most of that is due to processes in disk wait; the cpu itself is actually almost 50% idle. Jan 29 17:01:58 ah, cool Jan 29 17:03:34 sweet - svk will go through a corporate proxy Jan 29 17:23:32 03jbowler 07org.oe.dev * r4917a4fd... 10/ (2 files in 2 dirs): slugos-packages: add beep in conf Jan 29 17:23:36 03jbowler 07org.oe.dev * r8ec105da... 10/packages/beep/beep_1.2.2.bb: beep: release 1.2.2 Jan 29 17:23:40 03jbowler 07org.oe.dev * rb95403eb... 10/packages/busybox/ (busybox-1.01/slugos/defconfig busybox_1.01.bb): Jan 29 17:23:41 busybox: put fdisk back in to slugos defconfig in 1.01 Jan 29 17:23:41 - util-linux fdisk does not work on ARM (alignment problems) so use Jan 29 17:23:41 the busybox one in preference Jan 29 17:23:45 03jbowler 07org.oe.dev * r73da0cbc... 10/packages/meta/slugos-image.bb: slugos-image: add beep remove the util-linux fdisk in meta Jan 29 17:23:49 03jbowler 07org.oe.dev * rf9e43ab7... 10/ (4 files in 3 dirs): Jan 29 17:23:49 initscripts: slugos only change to device_table in 1.0 Jan 29 17:23:49 - slugos now installs the correct device table in the image build, Jan 29 17:23:51 ensuring that the device table matches /dev and, maybe, removing Jan 29 17:23:55 confusion Jan 29 17:23:57 03jbowler 07org.oe.dev * r45de09da... 10/packages/slugos-init/ (8 files in 3 dirs): Jan 29 17:23:59 slugos-init: update to use 'beep' in 0.10 Jan 29 17:24:01 - boot scripts now use the new beep arguments Jan 29 17:26:46 hello all Jan 29 17:56:36 I think something may have just broken all module builds... Jan 29 17:58:56 <-- hasn't been able to build glibc for ages Jan 29 18:03:40 is this channel always so ... empty? Jan 29 18:04:02 it's most lively weekdays Jan 29 18:04:07 Borealid: not really. There are a lot of people asleep atm though Jan 29 18:04:18 nice to know Jan 29 18:04:28 people are on UK time? Jan 29 18:04:48 Quite a few people are European Jan 29 18:04:56 I should be asleep... Jan 29 18:04:59 heh Jan 29 18:05:34 I don't suppose you happen to know the right way to get a working native compiler on OZ, do you? Jan 29 18:05:41 jbowler-away: I have a set of led updates coming in shortly. It will probably require minor changes to your led patches but only cosmetic ones Jan 29 18:05:53 k Jan 29 18:06:06 Did you see the cpu-idle/cpu-activity patch? Jan 29 18:06:23 I.e. packages/linux/ixp4xx-kernel/2.6.15/951-* Jan 29 18:08:12 jbowler-away: I hadn't looked at the patch. I have added my own version of duty cycle to the timer though :) Jan 29 18:08:36 Aargghhh, someone has added ${HOST_CC_ARCH} to KERNEL_CC Jan 29 18:11:00 should a 2.6 kernel machine be compiling glibc-2.3.2-r6 with the option '--enable-kernel=2.4.0'? Jan 29 18:11:50 RP: another problem I've found is that the it doesn't seem to be possible to get two LEDs to flash in sync Jan 29 18:12:12 which means that getting the NSLU2 ready/status to flash 'amber' (it's a red led + a green led) isn't really working at present... Jan 29 18:13:21 if you can turn the LEDs on or off at will, can't you just turn them both on until a specified time, then off until another specified time a second later, then repeat? Jan 29 18:13:25 jbowler-away: The only way that springs to mind is to create a common timer trigger that doesn't apply per led Jan 29 18:14:49 Right, which would also save kernel resources... Jan 29 18:15:00 jbowler-away: I also have my doubts about combining the cpu trigger with the timer. Whilst I see the idea, the result it hard to read... Jan 29 18:15:05 And would suggest 'phase' in addition to 'duty_cycle' Jan 29 18:16:06 The reason for doing it that way is because otherwise the code got duplicated, but all the #ifdefs could be removed - the cost is a few extra bytes in the LED device, but it's not much and it does make the code more clear. Jan 29 18:16:08 yes. The idea was people are free to invent weird and wonderful triggers to meet their needs. Which ones make mainline is debatable but they're easy to create and hook in Jan 29 18:17:07 cpu activity is probably important because the existing ARM LED code already apparently has an idle trigger Jan 29 18:17:33 Yes, I know. It also has timer functionality as well... Jan 29 18:17:59 I certainly plan to put a cpu activity trigger into mainline Jan 29 18:18:10 I've just not written it yet :) Jan 29 18:18:32 The patch series should be ready for another run on LKML though and perhaps might make -mm this time Jan 29 18:19:25 | patching file sysdeps/generic/ldsodefs.hrn| Hunk #1 succeeded at 211 (offset 8 lines).rn| Hunk #2 FAILED at 294.rn| Hunk #3 FAILED at 366.rn| 2 out of 3 hunks FAILED -- rejects in file sysdeps/generic/ldsodefs.h Jan 29 18:19:34 any ideas? Jan 29 18:19:57 package is glibc-2.3.5+cvs20050627-r1 Jan 29 18:20:22 is this the fault of the OE metadata? Jan 29 18:20:26 RP: well, 951-*.patch works and is tested, it can be made a separate trigger if you don't mind the code duplication (duty_cycle is required for the cpu-idle to work ok on NSLU2). Jan 29 18:21:19 Anyone know who "rw" is in this (IRC) context? Jan 29 18:21:38 jbowler-away: http://www.rpsys.net/openzaurus/patches/led_trig_timer-r4.patch is what I've just changed the timer code to Jan 29 18:21:59 jbowler-away: You want reenoo Jan 29 18:22:33 aka Rene Wagner Jan 29 18:22:54 * kergoth fires off his first oe build in months Jan 29 18:23:17 jbowler-away: I think the cpu-idle code needs to be separate. I probably won't be 100% certain until I see it though... Jan 29 18:23:27 Ah, he signed off an hour or so ago. Jan 29 18:23:29 jbowler-away: You have proved its simple enough to write though :) Jan 29 18:23:47 He's UK based and will be asleep (where I should be) Jan 29 18:23:58 Yes, cpu-activity is trivial - switch the LED off in idle, on at the end. Jan 29 18:24:34 cpu-idle is less trivial because an 'off' LED is not very obvious - not obvious enough to be visible on NSLU2 and the cpu-activity on NSLU2 isn't bright enough. Jan 29 18:26:44 So the on/off values are reversed? Jan 29 18:27:43 cpu-activity: on=active, cpu-idle: on=idle Jan 29 18:28:00 So the trigger needs an invert option? Jan 29 18:28:08 which you require depends on the sematic of the LED, which is defined by the labelling and other affordances Jan 29 18:28:50 RP: I did two triggers, they set a flag in the trigger data Jan 29 18:29:16 Its either two triggers or a trigger parameter Jan 29 18:29:52 RP: are you the one who built the gpe-image with the 2.6 kernel for borzoi a while back? Jan 29 18:30:11 Well, it's two triggers, but they share code... Jan 29 18:30:37 Borealid: yes Jan 29 18:32:01 jbowler-away: It could be argued it could be implemented either way :) I accept the two triggers approach means you can select either on a per led basis though :) Jan 29 18:34:13 RP: oh, ok - I thought 'trigger parameter' meant /sys/class/leds//invert or something like that, as opposed to something to trigger creation in the code? Jan 29 18:34:58 I guess the complete generalisation is frequency for active and idle plus brightness for active and idle Jan 29 18:35:46 That might be easier to understand (set brightness for the 'active' brightness and idle_brightness for the inactive level). Jan 29 18:36:13 That would also require different code - at present 'timer' unconditionally toggles brightness Jan 29 18:37:05 I was wondering of three parameters "invert", "brightness" and "frequency" Jan 29 18:37:39 but then you can't automatically set invert on a per led basis without userspace help Jan 29 18:37:51 Four - duty_cycle is needed too, the short duty cycle makes the LED appropriately frenetic (suggesting 'activity') Jan 29 18:38:24 ... I just wonder if there are i18n issues - whether my interpretation is cultural Jan 29 18:38:30 Is there not some defaults for some of these which will just work well? Jan 29 18:39:41 RP: no, on Loft cpu-activity (no flash) works fine, on NSLU2 it doesn't work at all well, and the labels on different machines are different anyway. Jan 29 18:40:12 It could be done at the board level, but passing in the parameters is really difficult (just the number of LEDs and the GPIO pins was difficult!) Jan 29 18:40:33 Anyway, it requires a lot of tweaking and is a user preference thing in some ways. Jan 29 18:40:55 I know. I'll have to experiment but I can see the problem Jan 29 18:41:24 Do you have an ixp4xx board of any description? Jan 29 18:41:40 no, just pxa and omap devices Jan 29 18:42:25 k - would you like me to separate out 951 from the timer stuff? (I.e. with the potential code duplication?) Jan 29 18:43:12 I'd like to see how bad it looks and I'll be trying it if nobody else does IYSWIM :) Jan 29 18:43:48 I've just committed the zaurus kernel changes (including updated led patches) so I think I'd best get some sleep! Jan 29 18:44:02 'night! Jan 29 18:45:43 night RP Jan 29 18:45:52 'nite RP Jan 29 18:47:03 jbowler-away: btw, if you do have any issues with the led core let me know ASAP - I'll probably present it to LKML soon to see if I can get a decision on its future out of them... Jan 29 18:48:44 The common timer issue is the only problem. Jan 29 19:09:08 pb__ unionfs-utils now fails in RUNSTRIP: Jan 29 19:09:12 file /home/work-tmp/jbowler/nslu2/ucslugc/work/unionfs-utils-1.0.13-r0/install/unionfs-utils/./usr/sbin/unionctl | grep -q 'not stripped' && armeb-linux-uclibc-strip /home/work-tmp/jbowler/nslu2/ucslugc/work/unionfs-utils-1.0.13-r0/install/unionfs-utils/./usr/sbin/unionctl || return 1; Jan 29 19:09:56 lt-file: could not find any magic files! Jan 29 19:14:21 I don't understand the command because it has the general form a && b || return 1, which seems wrong (the command fails if !a, so it fails if the file is already stripped) Jan 29 19:14:47 Indeed the whole RUNSTRIP can be shorted to "a && b", and probably just "b" in this case. Jan 29 19:18:36 The problem here is that the 'file' in staging/i686*/bin, the result of building file-native, is apparently non-functional Jan 29 21:08:14 is 2.6 working on the 5500? my oe just started compiling it and that has never happened before. Jan 29 21:08:19 (kernel) Jan 29 23:10:44 moo Jan 29 23:10:48 yo Jan 29 23:11:30 moo Jan 29 23:11:37 hmm Jan 29 23:11:40 looks like I can commit working e finally for dev... Jan 29 23:11:48 i guess i need to think of a good flag Jan 29 23:12:02 once these compiles finish Jan 29 23:12:14 JustinP: Just what I was trying to build! Jan 29 23:12:17 maybe NONSYSV Jan 29 23:12:26 of course it relies on the system's cpp instead of the cross one.... Jan 29 23:12:34 johnX: oh really? ;-) in .dev? Jan 29 23:12:45 half heartedly Jan 29 23:12:48 lol Jan 29 23:12:52 every couple weeks I poke at e Jan 29 23:13:00 johnX: theme stuff is broken currently in dev Jan 29 23:13:08 you should write some code instead o poke LO Jan 29 23:13:10 :P* Jan 29 23:13:14 due to some strangeness introduced in cpp... Jan 29 23:13:38 emte: That's a little bit out of my depth Jan 29 23:13:45 nah Jan 29 23:13:52 you want the link to the examples? Jan 29 23:14:12 a nice start would be to take the text editor example and resize it to pda ... Jan 29 23:14:27 LO? Jan 29 23:14:38 was off a couple keys :P Jan 29 23:15:36 where is my python book Jan 29 23:16:35 * emte releases a few mine into the room to draw out the book Jan 29 23:16:39 mice* Jan 29 23:17:05 "now as soon as the book moves it will set off one of these land mines and we'll know where it is..." Jan 29 23:17:14 lol Jan 29 23:17:28 lt-file: could not find any magic files! Jan 29 23:17:36 Does that mean anything to anyone? Jan 29 23:18:14 I get that during the packaging phase of diet-x11-6.2.1+cvs20060130-r6 Jan 29 23:21:29 yay, entrance *compiled* :-) Jan 29 23:21:43 well...the themes Jan 29 23:21:48 entrance itself has always been fine Jan 29 23:22:06 hmm Jan 29 23:22:16 python defaults flase does it not? Jan 29 23:22:20 false* Jan 29 23:23:44 ::shrug:: Jan 29 23:23:51 I've had very little python experience Jan 29 23:23:59 only a few small changes to BB Jan 29 23:24:05 yeah i've forgot 98% of mine Jan 29 23:24:21 i am trying to place a SYSV override Jan 29 23:27:02 Hrm. Convertin the OE database to rosters makes doing a fresh OE pull about 7 times faster. Jan 29 23:27:31 so it takes 6 hours? Jan 29 23:33:37 in tmp/staging/./i686-linux/bin/ I have "file" which is a shell script that calls tmp/staging/./i686-linux/bin/.libs/lt-file Jan 29 23:34:16 which is fine except that calling either "file" or "lt-file" with results in "lt-file: could not find any magic files!" Jan 29 23:50:07 johnX: file or libmagic maybe have hardcoded path(s) to the default magic file(s) Jan 29 23:50:40 I'll check Jan 29 23:53:13 saturn: thanks, copied my magic from /usr/share/file to where strings said the hardcoded path was, all should be good now Jan 30 00:02:14 emte: ~75 miuntes Jan 30 00:46:31 thar she blows! Jan 30 00:47:30 meanwhile, diet-x11 still hates me Jan 30 00:48:23 fun Jan 30 00:49:40 I have a version that compiled for me yesterday, I just need bitbake to be satisfied that it is built so that it can go on to build packages that depend on it Jan 30 00:50:05 you need to make sure all its files are in staging and then you need stamps Jan 30 00:50:07 johnX: Hm, there is a way to build sans deps Jan 30 00:50:41 ah yes Jan 30 00:50:46 NAbyss: I kinda figured there was a way to do something like that, but I'd rather fix whatever is causing it to die Jan 30 00:50:55 johnX: try bitbake -b /path/to/package.bb Jan 30 00:51:21 see, it's not a problem with diet-x11 so much as it is that the function RUNSTRIP is dying for reasons I can't understand Jan 30 00:51:53 what machine/distro? Jan 30 00:52:01 akita/openzaurus-unstable Jan 30 00:52:10 hmmm Jan 30 00:52:18 I've been working ok with spitz Jan 30 00:52:26 how up to date are you? Jan 30 00:52:31 this all worked for me yesterday Jan 30 00:52:38 I'm 100% up to date Jan 30 00:52:45 hmm, me too Jan 30 00:52:49 but I haven't started from scratch for a bit Jan 30 00:52:59 amd64 host perhaps? Jan 30 00:53:04 nope Jan 30 00:53:08 plain vanilla athlon Jan 30 00:53:25 hmmm Jan 30 00:53:48 I'll poke at some things Jan 30 00:57:24 perhaps starting from scratch again? Jan 30 00:57:34 maybe Jan 30 00:59:49 trying to build a couple other packages to see if they bug out as well Jan 30 01:00:34 hmmm...diet-x11 compiling for me right now Jan 30 01:00:45 mine compiles Jan 30 01:00:50 and dies in do_package Jan 30 01:01:08 well, we'll see Jan 30 01:01:13 I *just* updated Jan 30 01:05:33 johnX, its not diet-x11 Jan 30 01:05:43 there is a problem in OE Jan 30 01:05:48 ah Jan 30 01:06:02 i am now getting that error with glibc Jan 30 01:06:20 the error about file? Jan 30 01:06:27 NOTE: package glibc-2.3.5+cvs20050627-r1: task do_package: started Jan 30 01:06:27 ERROR: function RUNSTRIP failed Jan 30 01:06:36 and the log is empty? Jan 30 01:06:41 wow, fun Jan 30 01:07:11 i havent looked yet i just gave it a second kick at the cat Jan 30 01:07:51 at first something was wrong with file from file-native Jan 30 01:08:14 * emte is checking mailing list now to see who mangled it Jan 30 01:08:37 btw, the way I said I "fixed" file from up above is actually wrong Jan 30 01:08:48 it just breaks it in a different place Jan 30 01:12:06 <_law_> ERROR: function RUNSTRIP failed Jan 30 01:12:09 packaging.... Jan 30 01:12:17 <_law_> i think there is an oe problem :-( Jan 30 01:12:21 yes Jan 30 01:12:21 hehe Jan 30 01:13:06 yeah Jan 30 01:13:08 odd Jan 30 01:13:18 why are all the logfiles now different names? Jan 30 01:14:00 http://www.handhelds.org/hypermail/oe/current/5949.html Jan 30 01:14:19 well i found the log files Jan 30 01:14:31 they are called run.RUNSTRIP.xxx Jan 30 01:14:41 not log.RUNSTRIP.xx Jan 30 01:14:58 I have both Jan 30 01:15:19 yeah so do i Jan 30 01:15:34 and about 10 other logfiles too Jan 30 01:15:49 well RUNSTRIP is the interesting one in this case Jan 30 01:16:26 i cant say this looks right Jan 30 01:16:29 base_do_package() { Jan 30 01:16:29 : Jan 30 01:16:29 } Jan 30 01:16:51 damnit.....diet-x11 failed for me too Jan 30 01:16:58 sorry to jinx it Jan 30 01:17:09 hmm Jan 30 01:17:19 johnX, is your run file looping? Jan 30 01:17:44 oh wait its not a loop Jan 30 01:18:21 the problem seems to be in RUNSTRIP(), which is also what john bowler was saying in the message to the OE mailing list that I linked above Jan 30 01:19:15 IGNORE_STRIP_ERRORS perhaps? Jan 30 01:19:27 see commit for rev e4d8da41e5409080382f7a87c16b20bcc29516e3 Jan 30 01:40:55 hey, that works Jan 30 01:41:11 looks like someone broke it by not ignoring warnings....who knows why Jan 30 01:41:21 so how long has RUNSTRIP been faiiling silently? Jan 30 01:43:33 9 hours ago Jan 30 01:43:43 excuse me if this is possibly a stupid question, but where am I supposed to set IGNORE_STRIP_ERRORS? Jan 30 01:43:50 local.conf Jan 30 01:43:58 not stupid ;-) Jan 30 01:44:07 looks like rw broke packaging.... Jan 30 01:58:34 hi Jan 30 01:59:08 how can i install a 2.6 kernel on my poodle to have usbnet working please ? Jan 30 02:00:36 Dazgard: Do you have a working OE setup as yet? Jan 30 02:03:37 i have openzaurus oinstalled on my poodle Jan 30 02:04:11 i tried last day to compile OE, i take the whole day verifying revisions :s Jan 30 02:04:25 and next, i got errors Jan 30 02:07:52 Which branch? Jan 30 02:08:57 morning all Jan 30 02:13:47 morning Jan 30 02:15:31 morning all Jan 30 02:19:26 morning Jan 30 02:23:31 grr @ sf.net Jan 30 02:23:55 is their cvs server still down? Jan 30 02:24:15 yup Jan 30 02:28:12 Greetings ! Jan 30 02:28:22 NAbyss: im using 3. Jan 30 02:28:28 3.4.5 Jan 30 02:28:54 but tell me is there a good howto about howto to compile the whole thing ? please ? Jan 30 02:29:54 I am trying to build an initrd for the epia-2.6.12 kernel using OE but i am kind of confused... Jan 30 02:30:13 ~gettingstarted Jan 30 02:30:15 i guess gettingstarted is http://oe.handhelds.org/cgi-bin/moin.cgi/GettingStarted Jan 30 02:30:18 Dazgard: See that link Jan 30 02:31:02 should i make an additional IMAGE_CMD_ to handle it or do a postprocessing script ? Jan 30 02:31:58 NAbyss: thanks Jan 30 02:33:13 hi Jan 30 02:47:19 ~lart perl for not understanding multilib Jan 30 02:47:19 * ibot rm -rf's perl for not understanding multilib **** ENDING LOGGING AT Mon Jan 30 02:59:57 2006