**** BEGIN LOGGING AT Tue Feb 24 02:59:57 2009 Feb 24 03:30:36 Is there a solution to building tinylogin? The download location doesn't appear to exist anymore Feb 24 03:31:02 I'm attempting a build based on the angstrom distribution, for reference Feb 24 06:36:07 Grr Feb 24 06:36:13 ERROR: libdaemon-0.13: http://0pointer.de/lennart/projects/libdaemon/libdaemon-0.13.tar.gz has no entry in conf/checksums.ini, not checking URI Feb 24 06:41:32 And gstreamer Feb 24 06:42:40 Hi, does oe have gtkglext bb file? Feb 24 06:44:10 03Koen Kooi  07org.openembedded.dev * rd4ed85c549 10openembedded.git/packages/dsplink/gstreamer-ti_svn.bb: gstreamer-ti: bump SRCREV Feb 24 06:58:34 malfet, bah, might not have an image for you, had a thinko in the install line Feb 24 06:58:37 bah x 2 Feb 24 07:23:37 morning Feb 24 08:56:32 Why won't this work?? I'm trying to make a package that installs a mp3 file: http://pastebin.com/d5d13e72f Feb 24 08:57:18 Someone, please tell me about the dark magic that surrounds the rootfs, so I can understand, why I can't control how and where to install my own files. Feb 24 08:57:55 And btw, I've tried installing to /tmp/, /music/, /var/, and now /root/ without success -- the file simply isn't there upon bootup. Feb 24 09:02:41 Oh shit, I was wrong. The file IS in fact in /root. I just checked the wrong place; I thought root user's home dir was /root and tested with "ls". Feb 24 09:14:05 * * OE Bug 5039 has been created by di(AT)fh-wedel.de Feb 24 09:14:08 * * netbase 4.21 no longer downloadable Feb 24 09:14:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5039 Feb 24 09:21:06 * * OE Bug 5040 has been created by di(AT)fh-wedel.de Feb 24 09:21:08 * * base-passwd 3.5.19 no longer downloadable Feb 24 09:21:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5040 Feb 24 09:37:55 morning Feb 24 09:40:20 good morning Feb 24 09:52:48 good morning hrw, florian Feb 24 09:56:08 good morning all Feb 24 10:09:34 Anyone who can point to instruction on how to install files in home? Specifically /home/root ? Feb 24 10:12:32 what you mean by 'install files'? Feb 24 10:18:49 if i want to make a patch or take an action after autotools and before configure, what is the oe_ that i've to use? Feb 24 10:23:49 autotools calls configure Feb 24 10:26:26 well, if it gives you a fail in configure? Feb 24 10:26:34 i've to overrride the configure? Feb 24 10:27:13 hrw, um, if that word is ambiguous then I'm not sure. I what have a package pre-installed when I build an image, and I want that package to "put" files in /home/root. Feb 24 10:28:43 Btw, I've made a bb recipe for xmms2. Perhaps the OE project would like it. Feb 24 10:29:10 ~bug 4436 Feb 24 10:29:13 ~bugs 4436 Feb 24 10:32:25 Zta: packages CANNOT touch user homes Feb 24 10:33:06 hrw, why? Feb 24 10:33:21 is /home a mount point? Feb 24 10:33:24 because this is policy Feb 24 10:33:29 oh Feb 24 10:33:37 Zta: /home on many devices is separated from rootfs Feb 24 10:33:38 how you show a bug here? Feb 24 10:33:44 !oebug 4436 Feb 24 10:33:45 * * Bug 4436, Status: UNCONFIRMED, Created: 2008-07-16 16:57 Feb 24 10:33:46 * * drwyrm(AT)gmail.com: configure script of mpfr-native fails on debian-etch + some backports Feb 24 10:33:47 * * http://bugs.openembedded.net/show_bug.cgi?id=4436 Feb 24 10:33:57 hrw, so? Feb 24 10:34:04 Zta: and what about using xmms2 from 'hrw' user? Feb 24 10:34:07 hrw, Oh, you mean when the fs is built? Feb 24 10:34:23 Zta: I have device here which has /home/ on separate flash partition Feb 24 10:34:45 so rootfs with files in /home/somewhere will get them lost Feb 24 10:34:45 I still don't see why that should make it a problem to install files on that partition Feb 24 10:34:55 ah yes, exactly. Feb 24 10:35:11 so /home is a mount point Feb 24 10:35:18 can be Feb 24 10:35:49 Can I create /music/ or /var/music from a package and put files in here? Feb 24 10:36:44 why not /usr/share/xmms2/music? Feb 24 10:37:07 Zta: read FHS - we do not follow it exactly but try to Feb 24 10:37:49 well, it music didn't have to be xmms2-specific, I suppose. Feb 24 10:38:03 hi folks Feb 24 10:38:31 Same reason it's called /var/www and not /usr/share/apache/www/ I suppose =) Feb 24 10:39:30 hi blindman Feb 24 10:40:14 Zta: if the files are static, rather than editable, they would be best in /usr/share/music or some such place. Feb 24 10:40:26 /var is sometimes a ramdisk or a small writeable partition or the like Feb 24 10:40:49 or /srv/music, or even /music, would probably be ok too Feb 24 10:41:05 depends how important you feel the music is :-) Feb 24 10:48:44 it's for a music player, so it's very important =) Feb 24 10:58:17 pb_, but thanks, the wriable issue is good to have in mind. Feb 24 11:11:35 good afternoon, mr pb :) Feb 24 12:37:06 * * OE Bug 5041 has been created by di(AT)fh-wedel.de Feb 24 12:37:08 * * SVN fetch of opkg_svn fails Feb 24 12:37:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5041 Feb 24 13:46:15 http://www.ibm.com/developerworks/edu/l-dw-linux-embedded-distro-i.html Feb 24 13:46:48 hehe.. "how to reinvent your own wheel" :) Feb 24 14:01:33 http://aws-asset.soup.io/asset/0249/3943_f98f_800.png Feb 24 14:01:37 re Feb 24 14:02:40 :-) Feb 24 14:02:43 hrw: wb Feb 24 14:07:23 hello, it strange: emacs has been built recently on settings that are very similars to mine: http://downloads.freesmartphone.org/fso-unstable/feeds/armv4t/emacs_22.3-r0_armv4t.ipk but I still have a segfault on | qemu-arm -s 1048576 -L /home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi ./test-distrib /home/embedded/oetmp_openmoko/work/armv4t-angstrom-linux-gnueabi/emacs-22.3-r0/emacs-22.3/lib-src/testfile c Feb 24 14:07:23 ould it be the arch of my machine(non x86-64)? Feb 24 14:07:56 I've tried to increase the stack size to 10485760 and it didn't change anything Feb 24 15:26:00 03Theodore A. Roth  07org.openembedded.documentation * ra81237f552 10openembedded.git/usermanual/chapters/introduction.xml: Feb 24 15:26:00 introduction.xml: Fix spelling of Angstrom. Feb 24 15:26:00 * Use character entities. Feb 24 15:26:26 question: Feb 24 15:26:48 I renamed the dir under which my OpenEmbedded trees house Feb 24 15:27:09 I also adjusted the variables (environment) etc Feb 24 15:27:20 still bitbake complains about the old path Feb 24 15:27:23 how to fix? Feb 24 15:27:50 Crofton|work: ok, I am starting to apply patches from mail list Feb 24 15:28:08 Crofton|work: I have registered with patchwork. How do I change the patch state in patchwork? Feb 24 15:28:22 I need to make you a maintainer Feb 24 15:28:32 udovdh: you moved TMPDIR? Feb 24 15:28:36 I think the best thing to do is make everyone that registers a maintiner Feb 24 15:28:39 hang on Feb 24 15:29:02 hrw /bla/bla/org.openembedded.dev became Feb 24 15:29:14 hrw /bla/OE/org.openembedded Feb 24 15:29:22 bitbake as a dir under /bla/OE Feb 24 15:29:30 I see I need to remove .pyc files Feb 24 15:30:18 udovdh: tried that in the past as well but at some places the path is hardcoded Feb 24 15:30:25 udovdh: if you did not moved TMPDIR (dir where build takes place) it will work Feb 24 15:30:30 cbrake, try now Feb 24 15:30:30 you get get by that by having a symlink to the old name Feb 24 15:30:40 otherwise you need to rebuild Feb 24 15:31:02 there are places that know the old path; i think gcc is one of them Feb 24 15:31:13 hrw so it wont work here Feb 24 15:31:18 can't fix it manually? Feb 24 15:31:36 udovdh: not that i am aware of Feb 24 15:31:44 just keep your old temp dir or rebuild Feb 24 15:31:50 hmmm. ok Feb 24 15:31:51 thanks Feb 24 15:31:59 or keep a symlink Feb 24 15:35:24 eFfeM, would like to clean it up... Feb 24 15:35:28 tidy etc Feb 24 15:36:59 udovdh: tonight before going to bed; rm the tmp dir and start building console_image or so, that will make sure all the cross paths etc are rebuild when you get up in the morning (assuming you have a reasonably modern PC) Feb 24 15:37:34 eFfeM, I can do a bitbake navit Feb 24 15:37:40 so tmpdir is the culprit Feb 24 15:37:42 thanks Feb 24 15:37:59 http://wiki.navit-project.org/index.php/Navit_on_OpenEmbedded_for_n810 Feb 24 15:38:12 http://wiki.navit-project.org/index.php/Navit_on_Ångström Feb 24 15:39:20 wouldl love to see navit on my beagle board, but i had some issues with gpsd and never had time to look into it Feb 24 15:39:25 * eFfeM has a bluetooth gps Feb 24 15:40:27 eFfeM, beagleboard is omap? Feb 24 15:40:39 gpsd should work ok maemo with navit etc Feb 24 15:40:41 udovdh: yes, omap3 (3530) Feb 24 15:40:45 autostart etc Feb 24 15:40:47 udovdh, beagle board is omap3 Feb 24 15:40:56 so see the links in my nokia wiki Feb 24 15:41:07 then look here http://wiki.navit-project.org/index.php/Navit_on_n770/n800/n810#Configuration_options Feb 24 15:41:10 and read down Feb 24 15:41:25 near the bottom Feb 24 15:42:07 udovdh: i know it should but got sidetracked while installing gpsd, i think i did not get the daemon or something like that Feb 24 15:42:08 Crofton|work: thanks! is Accepted the state for "I pushed the patch" Feb 24 15:42:29 I think we should review the states :) Feb 24 15:42:34 I find them vague Feb 24 15:42:36 eFfeM, gpsd builds fine for chinook-compat Feb 24 15:42:41 but, that would be a good start Feb 24 15:42:43 Crofton|work: how about "Pushed" Feb 24 15:42:46 udovdh: just checked for you with strings gcc and definitely it has paths in it with the tmp dir Feb 24 15:43:00 Crofton|work: ok, and should I also click the Archived box? Feb 24 15:43:09 try it Feb 24 15:43:10 eFfeM, oh... aha Feb 24 15:43:12 weird Feb 24 15:43:19 I think it will take us a little while to figure out :) Feb 24 15:43:25 I'll look after lunch Feb 24 15:43:39 Crofton|work: looks good, its off the main list which is what I want Feb 24 15:43:42 if you have any ideas, lets talk about them on the list Feb 24 15:43:48 cbrake, exactly Feb 24 15:44:06 there are some people with more patchwork experince also Feb 24 15:44:32 udovdh: not weird, gcc needs to know where to find cc1 and cpp and include files etc so these paths are part of the executable Feb 24 15:45:53 eFfeM, ah, hmm. no config file or variables etc? Feb 24 15:46:52 sigh, untangling another dpkg/apt dep isue Feb 24 15:46:54 issue Feb 24 15:50:52 udovdh: you can override it in the cmd line Feb 24 15:51:54 but even with a config file you cannot really have a hard-coded path as you would want to distinguish between a native and a cross compileer (unless you do something like /etc/gcc/ Feb 24 15:52:03 but anyway, it is not the way it is made Feb 24 16:04:18 does anybody know whether www.linux4sam.org is down ? Feb 24 16:09:55 03Frans Meulenbroeks  07org.openembedded.dev * r052e421ce5 10openembedded.git/contrib/angstrom/build-feeds.sh: anstrom/build-feeds.sh: added cron Feb 24 16:23:43 Yay, really fixed dpkg/apt-native this time Feb 24 16:35:07 Odd question - has anyone here working with OE/bitbake ever run out of file descriptors when doing a build, as an error? Feb 24 16:37:47 robtow: could you explain clearly? Feb 24 16:39:40 hello, it strange: emacs has been built recently on settings that are very similars to mine: http://downloads.freesmartphone.org/fso-unstable/feeds/armv4t/emacs_22.3-r0_armv4t.ipk but I still have a segfault on | qemu-arm -s 1048576 -L /home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi ./test-distrib /home/embedded/oetmp_openmoko/work/armv4t-angstrom-linux-gnueabi/emacs-22.3-r0/emacs-22.3/lib-src/testfile c Feb 24 16:39:40 ould it be the arch of my machine(non x86-64)? Feb 24 16:39:43 I tried: Feb 24 16:39:51 Omckoan - one of my team members tried doing an initial run of OE, and got an error that he had rhit a limit on open file descriptors. I'm nonplussed, as it has niot happened to me; I've done numerous beagleboard and x86 builds of the Angstrom distro. Feb 24 16:39:56 *increasing the stack size to 10485760 Feb 24 16:40:21 *using an external qemu: http://qemu-arm-eabi.wiki.sourceforge.net/ Feb 24 16:40:33 I don't have his build log in front of me, just his comment that this is what happened to him. I'm looking at his enviro, and trying to duplicate it. Feb 24 16:40:34 mabe it's qemu? Feb 24 16:40:35 robtow: there is an issue building x86 Feb 24 16:41:01 ~curse linux4sam.org Feb 24 16:41:02 May the fleas of a thousand camels infest your most sensitive regions, linux4sam.org ! Feb 24 16:41:03 mckoan - I built x86 console image last week, and booted it under VMware. Feb 24 16:41:27 robtow: lucky guy :-) Feb 24 16:41:34 What issue do you refer to? In any case, my colleague was doing a beagleboard "minimal" image build. Feb 24 16:41:59 robtow: beagleboard != x86 Feb 24 16:42:14 I know, that, mckoan. Feb 24 16:43:15 I take it that this error of too many open file descriptors doesn't ring a bell. That's ok; just thought I'd ask. Obscure erros are part of the game. Feb 24 16:47:18 robtow: such error rang a bell (for me) but I don't know how (and when) to solve it :-( Feb 24 16:47:27 mmm it's not using my external qemu-arm desite of the asume provided and the exported PATH Feb 24 16:49:06 mckoan, ah, so it's been seen in the wild before. That's something, at least :-) Feb 24 16:50:11 robtow: that is what I was trying to say, but before I needed to know if you was facing to the same problem ;-) Feb 24 16:50:38 wow the new qemu seems to be better at compiling emacs... Feb 24 16:53:56 mckoan - I and a couple of other team members have NOT had this problem; a new engineer came in, set up his environment - and promptly did. SO I'm trying to figure out why - is that he uses the zsh instead of bash? Did he have a weird set of parameters in build.local.conf? Etc. Feb 24 16:53:57 also we need to uppdate emacs recipes for security reason(tm) Feb 24 16:54:29 about FEED_ARCH_nokia800, does it influence the code generation like gcc -m486 ? (or what was the flag?) Feb 24 16:57:44 03Tom Rini  07org.openembedded.dev * re28f5e5be8 10openembedded.git/packages/dpkg/dpkg-native.inc: Feb 24 16:57:44 dpkg-native: Last change broke thing (oops), we need to set PERL to ... and RDEPENDS="". Feb 24 16:57:44 The first part really does get us using the right perl to find out PERL_LIBDIR. Feb 24 16:57:46 The second part means that we don't depend on target perl being built too. Feb 24 16:57:48 03Tom Rini  07org.openembedded.dev * redcfd4eb90 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Feb 24 17:05:48 03Frans Meulenbroeks  07org.openembedded.dev * r94e89b7346 10openembedded.git/packages/cdrtools/cdrtools-native_2.01.bb: cdrtools-native: changed SRC_URI from ftp: to http: as ftp: did not work any more Feb 24 17:13:37 hello, the trunk of qemu-arm-eabi that is here: http://qemu-arm-eabi.wiki.sourceforge.net/ compiles(do_compile) emacs but neither the normal qemu-native or the qemu-native-cvs work...but the qemu-arm-eabi has...not less than 32 patches... Feb 24 17:14:12 Gnutoo: qemu-native_svn.bb fails too? Feb 24 17:14:32 hrw, no emacs fails with qemu-native and qemu-native_svn Feb 24 17:15:25 maybe I could make an automatic patch and test but it would take a lot of time...to test the automatic testing script Feb 24 17:15:29 03Frans Meulenbroeks  07org.openembedded.dev * r7ce1c0c356 10openembedded.git/packages/cdrtools/cdrtools-native_2.01.bb: cdrtools-native: bumped PR, fixed HOMEPAGE Feb 24 17:15:40 s/maybe I could make an automatic patch and test but it would take a lot of time...to test the automatic testing script// Feb 24 17:16:27 maybe I could automatize the patching,compiling,testing of qemu-arm-eabi to see which patch is responsible of the problem...but it would also take a lot of time...testing the script Feb 24 17:19:57 hrw, sorry I wasn't clear enough and it was related to my post that are ^^^ Feb 24 17:46:40 Hi, I send the patch from http://article.gmane.org/gmane.comp.handhelds.openembedded/21238 can anybody please verify the package and add it? thx Feb 24 18:06:24 Omegamoon: I just wanted to thank you for your Zubuntu work. I really appreciate it. Feb 24 18:07:20 i'm trying to make a recipe for cdrtools, but apparently it does not install; is there something in the recipe i need to do for that (there is nothing in image, so I get an empty package); exe's are in the src dir Feb 24 18:07:31 any idea what is wrong? Feb 24 18:36:57 ClashTheBunny: Glad you like Zubuntu Feb 24 18:42:32 Can someone experienced at bitbake look at http://patchwork.openembedded.org/patch/18/ ? Feb 24 18:44:54 meep .. http://pastie.org/398857 .. anyone got a clue? :) Feb 24 18:48:24 ah, doh. nevermind, stupid me copypasted some wiki comment into my local.conf Feb 24 18:48:32 blasty check your BB_NUMBER_THREADS variable Feb 24 19:49:18 noticed there was only cdrtools-native and no cdrtools, tried to make one, but i did not succeed; if anyone wants to give it a try: http://filebin.ca/wsvkke/cdrtools_2.01.bb contains what I got, i still get x86 targets and man pages do not get installed. Feb 24 20:35:03 guys, I build a kernel, and the modules at the same time, using the same toolchain etc... but insmod fails to load the module with "invalid module format" Feb 24 20:42:54 I'm starting to suspect that the host, ubuntu 8.10 is messing the cross toolchain in general. Feb 24 20:47:19 eFfeM, at what point are you with cdrtools? Feb 24 20:49:07 eFfeM, could you give more details? Feb 24 20:49:38 gnutoo see the link above for the bb file Feb 24 20:49:45 it does not package man Feb 24 20:49:54 which is not that dramatic Feb 24 20:50:14 but for some reason whatever I do, it generates x86 executables Feb 24 20:50:29 back in a bit, need a reboot Feb 24 20:53:38 re Feb 24 20:58:02 eFfeM,for the man remove the FILES_${PN}-doc += "/usr/man" because according to http://bec-systems.com/oe/html/recipes_packages.html it already does it automatically with ${mandir} Feb 24 20:59:30 eFfeM, for the x86 executables: does the rest of the bitbaken packages are also x86 executables? Feb 24 20:59:32 I bet no Feb 24 21:00:08 first: what is that: export CCOM = "gcc" Feb 24 21:00:09 ? Feb 24 21:00:17 because for me gcc is: Feb 24 21:01:04 seems my problem comes from "V4BX" -- the kernel doesn't like it ? wrong binutils ? someone uses an armv4t with a clue ? Feb 24 21:01:59 I use armv4t on the openmoko Feb 24 21:03:35 eFfeM, my gcc is arm-angstrom-linux-gnueabi-gcc Feb 24 21:03:37 I get "unknown relocation : 40" when trying to insmod. seems that the binaries generated are "V4BX" and the kernel doesn't grock them Feb 24 21:03:52 BusError, what is V4BX? Feb 24 21:04:46 new form on interworking, from what I can gather Feb 24 21:04:54 BusError, ah ok thumb Feb 24 21:05:31 BusError, so the kenrel and the modules weren't compiled together? Feb 24 21:05:52 they are ! same time, source, toolchain Feb 24 21:06:13 mmm Feb 24 21:06:51 I recompiled /everything/ went from eglibc to glibc, from angstrom to kaeilos same thing Feb 24 21:08:02 BusError: that's a kernel bug. probably easiest to patch the kernel to ignore those relocs. Feb 24 21:08:02 BusError, what machine and what kernel are you using? Feb 24 21:08:43 or you might be able to persuade ld to stop emitting them, though I don't know offhand whether there is a flag for that. Feb 24 21:09:08 pb_, patch as, add a compile option ? I'm using a 2.6.29-rc6, I understood it was all sorted out Feb 24 21:09:41 I'm not even sure if I need, or need not these bx things on arm920t (s3c2440) Feb 24 21:09:47 BusError: you probably need to modify the code. Feb 24 21:09:52 no, you don't need them. Feb 24 21:10:36 Gnutoo: was sidetracked, the man thing probably should go Feb 24 21:10:37 actually, they might go away if you add -mno-thumb-interwork to the cflags. that'd be worth a try. Feb 24 21:10:56 but, really, the kernel's reloc handler should cope with them. Feb 24 21:10:57 ah ok openmoko... Feb 24 21:11:05 the CCOM rule is added because the makefile they use has that macro to specify the c compiler Feb 24 21:11:14 and other packages are building fine Feb 24 21:11:17 or another board that has a s3c2440 Feb 24 21:12:19 Gnutoo: for other recipes I see sometimes too CC=gcc or so, and if the path is right it should work i'd say, but I'll try with arm-angstrom-linux-gnueabi-gcc tomorrow Feb 24 21:12:44 eFfeM, yes but does CCOM means kind of compiler like gcc, or the compiler such as arm-angstrom-linux-gnueabi-gcc Feb 24 21:12:51 ok Feb 24 21:14:14 pb_, would these bx problems have an impact on qemu ? I managed to boot my kernel on there, but all userland fails Feb 24 21:15:54 BusError: shouldn't do. what exactly goes wrong with your userland? Feb 24 21:16:19 (assuming qemu is emulating an arm920t cpu, that is) Feb 24 21:16:21 Gnutoo: maibye it indeed need the arm...gcc Feb 24 21:16:54 Init fails to launch on qemu somehow- kernel runs fine. haven't investigated much, I'm more worried about the code generated on the target Feb 24 21:17:51 my 'machine.conf' includes tune-arm920t.inc -- I tought it would sort things out ? Feb 24 21:18:15 conf/machine/include/tune-arm920t.inc Feb 24 21:18:47 yeah, probably. I'm not quite sure how qemu's configuration is handled. Feb 24 21:19:15 anyway, init failing to launch could be caused by almost anything, no reason to suspect it's v4bx related without further evidence to that effect. Feb 24 21:19:27 afaik, the glibc dynamic linker can handle those relocs just fine, it's only the kernel that's broken. Feb 24 21:20:18 is there a git-branch I could pull that patch from ? It must exist, most googling refers to eabi works as 1+ years old at least Feb 24 21:21:15 dunno, offhand. it's a pretty trivial patch though. Feb 24 21:21:39 in arch/arm/kernel/module.c, function apply_reloc, you just need to add "case R_ARM_V4BX: break;" to the big switch statement. Feb 24 21:22:18 might need to define R_ARM_V4BX in elf.h as well, I guess Feb 24 21:29:01 NOTE: Creating the CheckSum parser failed Feb 24 21:29:06 hmm, what am i missing... Feb 24 21:34:59 03Michael 'Mickey' Lauer  07org.openembedded.dev * raf8b170066 10openembedded.git/conf/distro/include/ (fso-autorev.inc sane-srcrevs.inc): sane-srcrevs.inc: add libgsm0710mux; also to fso-autorev Feb 24 21:34:59 03Michael 'Mickey' Lauer  07org.openembedded.dev * rfcdc1a355c 10openembedded.git/packages/ezx/ (4 files in 3 dirs): Feb 24 21:34:59 ezx-gen-blob: add svn version which finally compiles Feb 24 21:34:59 remove outdated binary-only old version Feb 24 21:35:01 03Michael 'Mickey' Lauer  07org.openembedded.dev * r392689e080 10openembedded.git/packages/popt/ (popt-native_1.14.bb popt.inc popt_1.14.bb): popt[-native]: add 1.14 Feb 24 21:35:04 03Michael 'Mickey' Lauer  07org.openembedded.dev * r87191b9432 10openembedded.git/packages/cups/ (cups_1.2.10.bb cups_1.2.12.bb): cups: 1.2.12 is now the default; 1.2.10 is no longer available Feb 24 21:35:19 03Michael 'Mickey' Lauer  07org.openembedded.dev * r26820377cb 10openembedded.git/packages/fakeroot/ (7 files in 2 dirs): Feb 24 21:35:20 fakeroot: 1.9.6 -> 1.12.1 Feb 24 21:35:25 remove 1.7 Feb 24 21:35:27 03Michael 'Mickey' Lauer  07org.openembedded.dev * rb3c44fafa0 10openembedded.git/packages/resolvconf/ (resolvconf_1.28.bb resolvconf_1.41.bb): resolvconf: 1.41 -> 1.43; remove 1.28 Feb 24 21:35:30 03Michael 'Mickey' Lauer  07org.openembedded.dev * rad86e72827 10openembedded.git/packages/glib-2.0/ (glib-2.0_2.18.0.bb glib-2.0_2.18.1.bb glib-2.0_2.18.3.bb): gilb-2.18.x: make it default Feb 24 21:35:33 03Michael 'Mickey' Lauer  07org.openembedded.dev * r74353393fb 10openembedded.git/packages/tzcode/tzcode-native_2007k.bb: tzcode-native: switch SRC_URI Feb 24 21:36:28 03Michael 'Mickey' Lauer  07org.openembedded.dev * r9260ed268c 10openembedded.git/packages/libsidplay/libsidplay_1.36.59.bb: libsidplay: use mirror for SRC_URI Feb 24 21:36:28 03Michael 'Mickey' Lauer  07org.openembedded.dev * rceb7e56980 10openembedded.git/packages/efl1/elementary_svn.bb: elementary: fix QA in packaging and submit necessary path to edje compiler Feb 24 21:36:31 03Michael 'Mickey' Lauer  07org.openembedded.dev * r1c9e5ab71e 10openembedded.git/packages/freesmartphone/fso-abyss_git.bb: fso-abyss: needs libgsm0710mux now Feb 24 21:36:34 03Michael 'Mickey' Lauer  07org.openembedded.dev * r33d49cc344 10openembedded.git/packages/base-passwd/ (13 files in 5 dirs): Feb 24 21:37:13 base-passwd: 3.5.19 -> 3.5.20 Feb 24 21:37:13 remove 3.5.9 Feb 24 21:37:14 03Michael 'Mickey' Lauer  07org.openembedded.dev * rce6d7638da 10openembedded.git/packages/netbase/netbase_4.21.bb: netbase 4.21: bring PR back as spotted during the review by Crofton Feb 24 21:37:20 03Michael 'Mickey' Lauer  07org.openembedded.dev * red1d18ed62 10openembedded.git/packages/netbase/netbase_4.21.bb: netbase: debian mirrors no longer carry this, change SRC_URI Feb 24 21:37:50 03Michael 'Mickey' Lauer  07org.openembedded.dev * r216ea0ff69 10openembedded.git/packages/udev/udev_124.bb: udev_124: make default version Feb 24 21:37:50 03Michael 'Mickey' Lauer  07org.openembedded.dev * rcf51a4d845 10openembedded.git/packages/automake/ (automake-native_1.10.bb automake_1.10.bb): automake[native] 1.10: make default Feb 24 21:37:58 03Michael 'Mickey' Lauer  07org.openembedded.dev * r97f2395bce 10openembedded.git/packages/screen/ (4 files in 3 dirs): Feb 24 21:38:25 screen 4.0.2: add debian patch to OE; has vanished from most mirrors Feb 24 21:38:25 screen 4.0.3: add with DEFAULT_PREFERENCE=-1; patch needs to be slightly adjusted Feb 24 21:38:31 03Michael 'Mickey' Lauer  07org.openembedded.dev * rf76fd5a763 10openembedded.git/: Merge branch 'mickey/sane-defaults-and-updates' into org.openembedded.dev Feb 24 21:38:34 03Michael 'Mickey' Lauer  07org.openembedded.dev * r0b4fa0c4c2 10openembedded.git/packages/freesmartphone/ (5 files in 5 dirs): libgsm0710muxd: new recipe; gsm 07.10 multiplexer engine Feb 24 21:38:45 (3 lines omitted) Feb 24 21:39:55 03Koen Kooi  07org.openembedded.dev * r0fdea8a59d 10openembedded.git/packages/dsplink/gstreamer-ti_svn.bb: gstreamer-ti: bump to r126 to make gstreamer autoplug and playbin work Feb 24 21:42:35 pb I'm trying to compile the kernel with -mtune=arm920t instead of arm9tdmi. it already compiles with the no-interworks so I don't know why these are generated Feb 24 22:11:06 BusError: it might be that you just can't disable interworking completely at -march=armv5 nowadays. Feb 24 22:11:33 interworking comes basically for free on those processors so there is no benefit to turning it off Feb 24 22:11:52 except, as you discovered, for avoiding v4bx relocs in object files :-} Feb 24 22:14:30 pb__ well it won't work unless I change the toolchain too even with ld-s --fix-v4bx they are inserted via the libc somehow, it appears Feb 24 22:14:58 BusError: really? kernel modules don't link with libc. Feb 24 22:15:51 well I tough so, but I traced the build, and even with --no-interworks (default on kernel) and --fix-v4bx there are still in the .ko Feb 24 22:16:06 I suspect "ld -s" just doesn't do anything with --fix-v4bx Feb 24 22:16:09 I suspect inlines from libgcc Feb 24 22:16:37 that option is really for generating executables, I wouldn't be surprised if it is a no-op for relocatable output Feb 24 22:17:06 libgcc doesn't get linked into kernel modules either Feb 24 22:17:15 I haven't found how NOT to get them generated by gcc all the same Feb 24 22:17:30 right, I suspect there just isn't any way to not get them generated at armv5 and higher Feb 24 22:17:46 as I said earlier, I think your best option is just to fix the kernel Feb 24 22:17:48 it's a rather complete mess ! and I tought arm9 was a simple upgrade from arm7 :D Feb 24 22:18:12 yeah, it should be a simple upgrade. the kernel's reloc processing is just broken. Feb 24 22:18:45 well I would rather not have a crash course on elf, kernel module internals, and all that stuff to load a silly module :/ Feb 24 22:18:55 if you compile with -march=armv4 -mno-thumb-interwork then I expect those relocs will go away, but you might have other problems in that case. Feb 24 22:19:11 you don't really need a crash course in elf. just make the one-line change I mentioned earlier. Feb 24 22:19:32 or two-line change if you want pretty formatting :-} Feb 24 22:19:49 * BusError goes have a look back at the log :D Feb 24 22:23:47 * BusError blesses make -j12 :D Feb 24 22:26:27 pb_ worked, now to wonder why that patch is not in the kernel ? Feb 24 22:27:06 thanks thats a problem that had been nagging me for some time! Feb 24 22:30:28 well, that patch isn't really suitable for upstream. a "real" fix would be to actually apply the v4bx for cpus that need it. Feb 24 22:30:47 however, that's more complicated to do, and your cpu doesn't need it, so the simple fix is good enough for your situation Feb 24 22:32:28 I guess a reasonable compromise would be to add a check for the cpu architecture in there. something roughly along the lines of: case R_ARM_V4BX: if (cpu_arch <= armv4) return -ENOEXEC; else break; Feb 24 22:33:27 that'd allow it to work in your case. on older cpus the module would be unloadable, but that's no worse than not having the patch at all. Feb 24 22:34:02 you'd need to figure out what the right thing to put inside the if-expression is, though. I imagine there must be some variable inside the kernel that holds the cpu architecture but I don't know what it is offhan. Feb 24 22:34:05 d Feb 24 22:34:49 I'll just #ifdef it for the arm920T for now :D Feb 24 22:35:06 heh, fair enough Feb 24 22:36:01 now for the next wierd problem: Feb 24 22:36:04 Alignment trap: qcop (1123) PC=0x40295060 Instr=0x2800f9ad Address=0xffffffff FSR 0x813 Feb 24 22:36:33 heh, qcop? i think you are on your own with that one :-} Feb 24 22:36:50 thats opie. works with eglibc somehow, but I rebuilt with glibc and it fails to launch Feb 24 22:37:03 probly some c++ horror case Feb 24 22:38:06 yeah Feb 24 22:38:26 apparently that instruction is "stmcsda r0, {r0, r2, r3, r5, r7, r8, fp, ip, sp, lr, pc}" which is pretty weird Feb 24 22:38:41 but, well, opie. Feb 24 22:39:08 thats the only UI desktop that builds, here. Feb 24 22:39:10 if you wanted to attack this, the first order of business would be to find out what library the offending pc address is in. Feb 24 22:39:32 then pin it down to the individual function, and then try to figure out what's gone wrong with it. Feb 24 22:40:14 the "alignment trap" is a bit misleading; this code is trying to write to address -1, which is bound to fail even if alignment traps were not enabled. Feb 24 22:40:50 it just happens that alignment has higher priority than protection faults and so that's what gets reported. Feb 24 22:41:46 überhacker mickey|zzZZzz used to be one of the opie dudes. he might be able to help you with that if he wasn't asleep. Feb 24 22:42:34 yeah I realize that, the instruction is probably just fine, but has a dangling pointer, and it could be for a bazillion reason. most probably distro related too (it works in angstrom) Feb 24 22:43:29 kaeilos is nice tho, no udev bloat, it almost boot fast :D Feb 24 22:45:20 yeah, could be. with an instruction like that it's pretty much even money whether the instruction is bogus or it's a good instruction with bad arguments. Feb 24 22:45:55 stm..da is a fairly unconventional variant (traditional stacks are stm..db) and the register selection looks a bit arbitrary Feb 24 22:46:26 and the 'cs' condition code is also slightly funky Feb 24 22:46:34 could also be a piece of stack Feb 24 22:46:57 but, none of that is conclusive; it's a perfectly valid instruction in its own right and it's certainly not inconceivable that this is really what's wanted. Feb 25 00:04:34 03Stefan Schmidt  07fso/milestone5 * r0d5a98248b 10openembedded.git/ (conf/checksums.ini packages/cellhunter/cellhunter_0.4.0.bb): cellhunter: Move to the 0.4.1 bugfix release Feb 25 00:48:20 03Michael 'Mickey' Lauer  07org.openembedded.dev * r6d76191b20 10openembedded.git/classes/efl.bbclass: efl.bbclass: touch config.rpath which is necessary for newer automake Feb 25 00:48:22 03Michael 'Mickey' Lauer  07org.openembedded.dev * r25b51d32c9 10openembedded.git/docs/usermanual/ (31 files in 3 dirs): Feb 25 00:48:22 docs: import usermanual from org.openembedded.documentation. Feb 25 00:48:22 org.openembedded.documentation is deprecated now; please do all updates here! Feb 25 00:52:40 03Michael 'Mickey' Lauer  07org.openembedded.documentation * r51d1c67b2c 10openembedded.git/THIS_BRANCH_IS_DEPRECATED: Add deprecation notice. Feb 25 01:50:55 anyone thought about moving the 'doc' flag sets next to the variables they document, at least for the cases where that's viable? **** ENDING LOGGING AT Wed Feb 25 02:59:57 2009