**** BEGIN LOGGING AT Wed Jan 11 02:59:58 2006 Jan 11 03:00:32 RP: I've probably made some changes, do you have a line number ? Jan 11 03:01:11 lrg|home: 156 in the last version of SoC I have Jan 11 03:01:33 lrg|home: Search for spitzscoop2 and you'll see it Jan 11 03:02:37 heh.. I forgot to set SRCDATE.. Jan 11 03:03:37 RP: okay Jan 11 03:05:13 will be back after lord o war Jan 11 03:05:33 RP: ah, my file is different. I had made some changes to the mic bias already. I'll check against the old revision and make sure the new rev deals with this correcdtly Jan 11 03:06:08 lrg|home: The only reference to spitzscoop2 should be within the set_bias function. Anything else would be wrong Jan 11 03:07:35 libgaim0.ipk (from qpe-libgaim) has weird Depends: libgaim-plugins, qpe-libgaim-locale*, libc6 (>= 2.3.5+cvs20050627), libgcc1 (>= 3.4.4) Jan 11 03:08:26 RP: ok, thanks. Its only in set_bias now. :) Jan 11 03:10:56 hrw|tv: It could be debian.bbclass doing weird renaming... Jan 11 03:12:41 RP, lrg: I'm about to rebuild 2.6.15-rc7 for my Akita. I was going to just pull the line that RP mentioned. Should I do that? Or is their anything else that should be changed? Jan 11 03:13:15 johnX: That's all you should need to change Jan 11 03:13:43 johnX: it's probably best to remove the line RP mentioned atm until a I release a new audio patch. Jan 11 03:13:54 lrg|home: johnx is the person who reported the oops on akita Jan 11 03:14:10 alright, then I'll hack this up and see how it comes out. :D Jan 11 03:14:16 johnX: thanks for the report Jan 11 03:14:22 no problem Jan 11 03:14:42 after all I have an enlightened self interest in 2.6 for Akita being stable Jan 11 03:15:44 RP: ok but why at all it has that dependency.. I cannot find any occurence of it Jan 11 03:17:37 I know they can be created automatically if something is in /usr/share/locale/ but why it got that dependency is beyond me.. Jan 11 03:20:14 testers for final 3.5.4 are (very slowly) increasing.. Jan 11 03:20:47 bbl Jan 11 03:21:11 hrw|tv: I don't really have time to look into that depends at the moment. It looks odd though... Jan 11 03:21:47 I'm also seeing build failures on libxine. Its trying to use -mcpu=i686 to an arm compiler... Jan 11 03:22:40 RP: good move Jan 11 03:23:52 it's possible to flash just the kernel on an Akita, right? Jan 11 03:24:14 would I just put updater.sh and zImage.bin on a card, and leave out initrd.bin? Jan 11 03:24:49 johnX: correct Jan 11 03:26:28 great, I'm rebuilding 2.6.15 right now, and I'm starting to get tired of restoring my settings every week or so Jan 11 03:26:50 johnX: Keep in mind everything on /home is saved over a rootfs reflash Jan 11 03:27:07 mostly /etc is what I'm thinking about Jan 11 03:27:33 johnX: Just make sure you install the new kernel modules Jan 11 03:27:50 snd_soc_spitz is the one you've changed Jan 11 03:28:25 RP: would I be able to just copy over that kernel module? Jan 11 03:28:43 RP: I haven't updated my OE tree since I build the kernel I'm using now Jan 11 03:30:20 johnX: yes, no need to reflash the kernel in theory Jan 11 03:30:55 OE will produce a new kernel moudle ipk file for that module - just install that, or copy the file over Jan 11 03:31:28 Gah. libxine runs "Wand-config" and finds the config of my build system Jan 11 03:31:45 RP: how helpful of it Jan 11 03:38:01 morning Jan 11 03:39:27 morning Jan 11 03:40:44 are thr Jan 11 03:41:10 are there nown compile problems with SDL in the 3.5.4 branch? Jan 11 03:41:15 known ven Jan 11 03:43:56 morning CoreDump|home Jan 11 03:44:09 hi RP Jan 11 03:46:44 ping do13 Jan 11 04:11:59 and behold there was music! Jan 11 04:13:42 johnX: excellent. Thanks for testing. The next kernel revision should include a fix for that :) Jan 11 04:14:00 glad to be helpful Jan 11 04:20:52 wow...mixer is pretty loud by default Jan 11 04:21:51 johnX: find a level that is good and use alsactl store to save it and alsactl restore to restore Jan 11 04:22:08 good plan Jan 11 04:22:27 ah the memories of screwing around with alsa back in the bad old days are coming back Jan 11 04:22:43 johnX: we have some plans to simplify the mixer and provide some default settings Jan 11 04:24:13 I'm actually kind of enjoying digging around in this stuff :D Jan 11 04:25:56 desktop linux is too easy these days Jan 11 04:26:12 :) Jan 11 04:26:27 um is there a check-in policy for the3.5.4 branch? If so, what is it? Jan 11 04:26:32 lrg|home: pong Jan 11 04:27:21 do13: I've got the mainstone hooked upto the wm9712 and don't have a problem with aux and touch at the same time Jan 11 04:27:31 I just take it bug/compilefixes are fine right? Jan 11 04:27:54 lrg|home: strange. Do you use polling mode? Jan 11 04:27:57 do13: I open the touch and then cat /sys/bus/ac97/aux1 without touch breaking Jan 11 04:28:04 do13: yes Jan 11 04:28:48 * CoreDump|home takes that for a yes Jan 11 04:28:57 do13: I'll get to the bottom of this when i get my tosa :) Jan 11 04:29:52 do13: it's quite strange the pen down events. the only other diff between mainstone and tosa would be I've nothing connected to the aux adc's. so I'm reading NC pins Jan 11 04:30:25 lrg|home: reading nc pins should have no effect. Jan 11 04:31:21 lrg|home: can you insert a loop into wm97xx_read_aux_adc to do 5 or 10 samples? Jan 11 04:31:36 CoreDump|home: The changes have to be added to some bug in the bugzilla. koen or mickeyl then apply. We're not allowed to touch it Jan 11 04:31:45 ahh Jan 11 04:31:46 do13: ok Jan 11 04:31:54 RP: thanks, will do Jan 11 04:32:11 do13: i'm only reading aux by cat atm, so its manual and not very fast Jan 11 04:32:28 CoreDump|home: I think hrw might also be allowed certain access. I'm also allowed to touch the kernels in there (I think) Jan 11 04:32:40 CoreDump|home: but I have been told off before... Jan 11 04:33:15 Well, I can live with these restrictions as long as bugs get fixed =) Jan 11 04:33:50 But I'll be damned if I hve to wait weeks for a simple compilfix to go live=) Jan 11 04:33:55 CoreDump|home: koen was pretty good about applying patches to it Jan 11 04:34:07 although I think he's away atm Jan 11 04:37:56 you don't have a bug no. for the "request to commit" bug by chance? Jan 11 04:40:11 CoreDump|home: #350 I think Jan 11 04:40:40 thank you Jan 11 04:47:10 I just tried to bitbake lsof and got a 404 trying to download http://www.oesources.org/source/lsof_4.75.tar.bz2 Jan 11 04:47:34 johnX: That just means the mirror doesn't have it Jan 11 04:47:58 RP: ok, glad I didn't file a bug report then Jan 11 04:53:43 lrg|home: can you reproduce this? Jan 11 04:57:19 do13: not yet, I've tried a loop of 100 and got a pxa2xx ac97 read error, still investigating...... Jan 11 05:03:46 re Jan 11 05:03:51 lrg|home: i have never seen an pxa2xx ac97 read error :) Jan 11 05:03:54 'Lord of war' is nice movie Jan 11 05:09:38 night all, thanks for the quick fix RP Jan 11 05:09:48 johnX: cu Jan 11 05:09:56 'night johnX Jan 11 05:56:18 RP: dtl1_cs looks like got suspend/resume... Jan 11 06:04:43 hrw|tv: That's good to know. Someday we'll have some fully featured kernels :) Jan 11 06:06:05 anyway updating to 2.6.15-git7 is not for me - I identified few patches already applied but failed on other Jan 11 06:06:58 nevermind. time to go to make some cleaning in house Jan 11 06:08:31 hi Jan 11 06:22:22 hrw|tv: I have git5 compiling here... Jan 11 06:24:05 hrw|tv: http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.15+2.6.16-git5.bb Jan 11 06:24:25 not tested on device though Jan 11 06:25:41 not now Jan 11 06:38:34 RP: Did you checked my corgi-bl changes? Jan 11 06:43:13 cu Jan 11 06:57:51 do13_: With all the OE/bitbake issues, I haven't had much time for anything else, sorry :-/ Jan 11 06:59:20 RP: np. If this works for you we can push this. Jan 11 07:00:49 do13_: I'll aim to get that tested soon then as pushing that straight into mainline would be good Jan 11 07:01:21 I haven't had time to touch the LED code recently either which I was hope to at least push a little more... Jan 11 07:02:05 RP: Any new comments about this from rmk? Jan 11 07:03:23 do13_: I sent him an email which he never replied to. He only recieves 50% of the emails I send him and claims never to have seen the others Jan 11 07:04:19 RP: his spam filter is obviously only 50% effecient :-) Jan 11 07:10:08 RP: send the mails twice so he should get the relevant info :) Jan 11 07:14:21 * RP resends the quesiton Jan 11 07:18:37 NOTE: package opie-image-1.0: completed Jan 11 07:18:52 no extra patches to the metadata, just the new bitbake patch Jan 11 07:19:09 (apart from a libxine compile fix) Jan 11 07:37:16 <_law_> hrw|gone, dtl1_cs supend/resume? where did you read this? Jan 11 08:05:16 Is a german speaking user interested in test reading my german User Manual? Jan 11 08:05:25 It's not finished yet Jan 11 08:06:29 Cobelius: User Manual for what? Jan 11 08:06:41 OpenEmbedded and BitBake Jan 11 08:06:55 how to install, how to create packages, machine description etc. Jan 11 08:08:09 Cobelius: Do you have a link? Jan 11 08:16:37 http://stuff.intion.de/oe.pdf Jan 11 08:18:44 Cobelius: thx. I'll look at this later Jan 11 08:18:49 ok Jan 11 08:53:16 ugh, monotone so slow. how do people actually get work done with it? Jan 11 08:58:55 NOTE: package gpe-image-1.0: completed Jan 11 08:59:10 Not looking too bad for the new bitbake patch... Jan 11 08:59:48 anyone know what date that prebreakage tag is so i can just download the snapshot before it? Jan 11 09:00:35 RP: sounds good Jan 11 09:00:48 gb2: Download a snapshot atferwards and just use the tag? Jan 11 09:01:28 RP: i was hoping to avoid having to go through monotone, I was downloading tree snapshots, not the monotone db snapshot. Jan 11 09:01:51 ah, you didn't say what kind of snapshot :) Jan 11 09:01:57 Friday should be safe Jan 11 09:01:59 oh dear my FD has just seen the akita, he's now wondering off with another accountant wanting to get a load of them for all the top brass Jan 11 09:02:08 someone makes a session about OpenEmbedded at the "embedded World 2006" in Nürmberg Jan 11 09:02:09 Thats bad news Jan 11 09:02:11 ok, thanks. Jan 11 09:02:37 schurig: somebody needs to do one for OLS too Jan 11 09:02:44 And CELF, for that matter Jan 11 09:04:12 ade|desk: thats good news, the more people buy them, the better for us Jan 11 09:27:40 XorA: not so sure about him though Jan 11 09:35:40 CVS moved to cvs.savannah.[non]gnu.org Jan 11 09:35:40 Check http://savannah.gnu.org/forum/forum.php?forum_id=4168 for details. Jan 11 09:35:40 Anonymous access over SSH is replaced by the (more efficient) pserver. Jan 11 09:35:42 how annoying Jan 11 09:35:47 * gb2 fiddles Jan 11 09:39:40 heh, I haven't updated these .bb files in a while Jan 11 09:43:02 I wonder why the quilt bb pulls from a cvs tag rather than downloading a release tarball Jan 11 09:44:17 gb2: If you haven't built for a while, you need to remove the savannah tarballs from your download directory Jan 11 09:50:23 RP: i have a cut down private snapshot of a bunch of .bb files for a small project and I just did a new rebuild with an empty download dir. Jan 11 09:50:33 so i'm just noticing these now Jan 11 09:50:53 the quilt one is kinda weird though Jan 11 09:51:34 it probably ought to be using the release tarball Jan 11 09:52:25 Hi, my OE and monotone are up to date. When I try to build, bitbake eventually aborts because some file apparently cannot be downloaded. -> http://rafb.net/paste/results/kzNI2w77.html Any comments? Jan 11 10:10:50 Hi, my OE and monotone are up to date. When I try to build, bitbake eventually aborts because some file apparently cannot be downloaded. -> http://rafb.net/paste/results/kzNI2w77.html Any comments? I have had this problem for the last couple of days. Not just today. Jan 11 10:14:58 Laibsch: Your bitbake probably isn't uptodate. See topic Jan 11 10:16:38 hi my trying now to compile my PHP nativly on the slug and i always get this error : Jan 11 10:16:42 libtool: link: warning: library `/usr/lib/gcc/armeb-linux/3.4.4/../../..//libmysqlclient.la' was moved. Jan 11 10:16:42 grep: /home/kami/slug/openslug/tmp/staging/armeb-linux/lib/libiconv.la: No such file or directory Jan 11 10:16:45 /bin/sed: can't read /home/kami/slug/openslug/tmp/staging/armeb-linux/lib/libiconv.la: No such file or directory Jan 11 10:16:45 libtool: link: `/home/kami/slug/openslug/tmp/staging/armeb-linux/lib/libiconv.la' is not a valid libtool archive Jan 11 10:16:45 ake: *** [libphp5.la] Error 1 Jan 11 10:16:51 RP: Hm, I don't think so. I updte it via cron. What is the most current version? Jan 11 10:16:52 can anyone help me? Jan 11 10:19:07 kami22: It looks like something is wrong with the -dev package you're using as the staging path names are leaking onto the device somehow Jan 11 10:19:42 RP: My version is BitBake Build Tool Core version 1.3.2.1, bitbake version 1.3.2. Jan 11 10:19:42 Laibsch: I don't know the revision offhand - you need the latest svn and even then, we have some things broken at the moment. Jan 11 10:19:55 Laibsch: from latest svn? Jan 11 10:22:02 sorry have to restart my system Jan 11 10:22:46 RP: As I said, I do the updates via cron. I double checked and did a "svn up", version stayed at 332 Jan 11 10:22:57 My bitbake is current. Jan 11 10:23:20 This is nothing major, just some 404 so it should be easy to fix. Jan 11 10:23:29 I just don't know where. Jan 11 10:24:44 Laibsch: Ok. The only reason I mention it is that the first error people see when they haven't updated their bitbake is the CVSDATEs and SRCDATES get confused and it uses the wrong glibc Jan 11 10:26:25 Is there a way to determine why the autotools bbclass isn't being included in a bb? Jan 11 10:29:25 RP: That is OK. I also got burned by rapidly outdated setup. That is why I now have cron to take care of things. Jan 11 10:33:55 * Philippe is back (gone 19:20:26) Jan 11 10:37:10 http://pastebin.com/501092 Jan 11 10:43:11 hrm. glibc built for powerpc really seems to want to do altivec stuff. I wonder why, especially since I want to use it on a non-altivec capable cpu. foo. Jan 11 10:48:50 gb2: -march=g3? Jan 11 10:49:41 Luke-Jr: apparently glibc just wants binutils capable of ".machine ..." Jan 11 10:49:54 I'm guessing I misbuilt binutils Jan 11 10:50:12 I wish the toolchain building stuff was a little better maintained Jan 11 11:04:45 gb2, ppc is an altivec device Jan 11 11:05:18 i didnt think anyone really still use them tho Jan 11 11:05:35 the g2 upgrade boar was pretty cheap for them Jan 11 11:05:41 board* Jan 11 11:05:51 but the ram was stupidly expensive Jan 11 11:10:33 emte: eh? Not all PPC CPUs support Altivec Jan 11 11:11:04 I should really go through and modernize these toolchain setups Jan 11 11:11:16 I know my G3 laptop doesn't Jan 11 11:11:41 the G series isnt really classified as a ppc Jan 11 11:11:58 the "G*" stuff is marketing goo Jan 11 11:12:08 the ppc was the hybrid system Jan 11 11:12:09 the MPC74xx generally supports altivec instructions Jan 11 11:12:24 as do several other lines Jan 11 11:12:33 it nativly supported both Apple's file systems and IMBs Jan 11 11:12:41 IBM's* Jan 11 11:12:58 it had a very short lifespan Jan 11 11:13:09 huh? Jan 11 11:13:25 are you refering to some specific meaning of "ppc" Jan 11 11:13:27 it lasted 6-8 month on the market i belive Jan 11 11:13:50 i am refering to the specific ppc hardware, yes Jan 11 11:14:21 oh how stupid. Jan 11 11:14:32 configure:15: ccache gcc -c ... conftest.s Jan 11 11:14:35 conftest.s:1: Error: unknown pseudo-op: `.machine' Jan 11 11:14:37 conftest.s:2: Error: no such instruction: `blr' Jan 11 11:14:42 duh! stupid glibc. Jan 11 11:14:47 use the damn cross compiler when running that test! Jan 11 11:15:15 the G in the ones after stand for Generation from what i remember Jan 11 11:15:26 Good evening all Jan 11 11:15:32 "the specific ppc hardware" ? Jan 11 11:15:54 I'm refering to ppc the architecture Jan 11 11:16:47 Can anyone tell me, how a _cvs.bb file finds out the currently checked out Version (and how the ${PV} is generated out of that info) ? Jan 11 11:18:17 RP: ping Jan 11 11:20:46 then gb2 you want this? http://www-128.ibm.com/developerworks/eserver/articles/archguide.html Jan 11 11:20:56 no Jan 11 11:21:00 i don't need anything. Jan 11 11:21:55 but i'll curse at glibc with you Jan 11 11:22:19 I think I'm actualy running into a dependency hole that i need to work around Jan 11 11:22:36 with the new system or old? Jan 11 11:22:40 old Jan 11 11:22:46 is the new system working yet? Jan 11 11:23:07 has issues i think ... Jan 11 11:23:10 the old system toolchain stuff I actually wrote long ago :) Jan 11 11:23:24 most of those things still list me as maintainer Jan 11 11:23:50 well if you did the depends stuff right the new stuff should work no? Jan 11 11:24:19 unless there are other major changes Jan 11 11:24:27 http://pastebin.com/501092 Jan 11 11:24:34 yeah. the problem I'm running into is glibc-initial Jan 11 11:24:38 which I think I don't even really want Jan 11 11:25:10 the glibc stuff in OE feels horribly out of date Jan 11 11:26:46 glibc-initial runs its configure, which attempts to ensure ${target_prefix}-gcc is usable, it decides it isn't (it hasn't been built yet) and it goes with "gcc" instead, which isn't appropriate Jan 11 11:27:38 it happens to work on arm and x86 though Jan 11 11:27:46 zecke, will have all the awnswers for you :) Jan 11 11:28:11 Drugs are not an answer Jan 11 11:28:20 are you building on a ppc host or x86? Jan 11 11:28:54 ppc Jan 11 11:28:59 for arm on ppc Jan 11 11:29:03 it fails in glibc here Jan 11 11:29:05 oh Jan 11 11:29:12 heh Jan 11 11:29:25 see zecke has the majic :P Jan 11 11:29:28 yeah :) Jan 11 11:29:49 zecke: i'm currently building for ppc host on an x86 build machine and am running into failures at glibc :) Jan 11 11:33:15 gb2: which kind of error? Jan 11 11:33:18 use pastebin Jan 11 11:33:35 but I'm on OS X/Darwin/PPC so my errors will be different Jan 11 11:33:58 zecke: glibc-initial runs configure and the configure tries to use CC=powerpc-linux-gcc, but powerpc-linux-gcc hasn't been built yet, so it uses gcc instead. Jan 11 11:34:20 gb2: that is wrong ;) Jan 11 11:34:22 zecke: which then fails to pass required tests in the sysdeps/powerpc configure.in Jan 11 11:34:27 gb2: no gcc-cross-initial is build? Jan 11 11:34:37 gcc-cross-initial depends on glibc-initial Jan 11 11:34:39 :) Jan 11 11:35:25 gb2: yeah, glibc-initial sucks. Jan 11 11:35:48 gb2: now the master takes over Jan 11 11:36:01 I solved this long ago Jan 11 11:36:37 back when I first added all this cross toolchain building machinery to OE Jan 11 11:37:02 it'll come back to me eventually Jan 11 11:37:22 it's been about 18 months since I had my head deep into this stuff Jan 11 11:40:42 iirc, things got hairy when nptl support was added Jan 11 11:40:54 brb, I need to reboot Jan 11 11:45:43 aha, crosstool actually does their version of glibc-initial not as cross but as native Jan 11 11:46:32 hm, so do we Jan 11 11:47:40 http://pastebin.com/501092 <-- why is the bbclass not being included? Jan 11 11:48:05 # Override libc_cv_ppc_machine so glibc-cvs doesn't complain Jan 11 11:48:06 # 'a version of binutils that supports .machine "altivec" is needed'. Jan 11 11:48:07 hah Jan 11 11:48:13 Do we have something like "bitbake opie-image -f -c cleanstage", which cleans the opie-image package and all DEPENDS from work / and staging to provoke a comlete rebuild without removing tmp (and thus glibc, gcc, ...) Jan 11 11:48:15 how annoying :) Jan 11 11:49:38 heh Jan 11 11:52:45 there are some powerpc specific fixes&hacks, in the .dreambox branch, so you might want to check there. Jan 11 11:53:22 config/dm7020.conf should show a known-good glibc/gcc combination Jan 11 11:53:32 including NPTL if i'm not mistaken Jan 11 11:55:46 tmbinc: it looked like that was configured to use an external toolchain Jan 11 12:00:54 gb2: no, definitely not. Jan 11 12:01:04 i don't like external toolchains Jan 11 12:01:20 oh, branch Jan 11 12:01:37 yes Jan 11 12:01:45 hrm. is there any way to sanely browse the branch without pulling it from monotone? Jan 11 12:02:00 and why is there a need for a separate branch? Jan 11 12:03:44 I believe monotone compresses the data, so it isn't human readable (though I'm not sure), it's a also a database, so the data may be fragmented - someone has to pull from the db to see it. Jan 11 12:04:55 I don't think there is a web-based source browser yet, if that's what you are looking for. Jan 11 12:05:05 that's more of what I was looking for Jan 11 12:07:13 It shouldn't be hard to write, could probably even be done with simple scripts. Jan 11 12:07:51 there is supposedly one on monotone.vanille.de, it's just rediculously slow and often spits out "sorry, db was locked" after you wait 10 minutes Jan 11 12:08:09 viewmtn - yes, there seem to be some perf problems Jan 11 12:08:14 gb2: what do you want? Jan 11 12:08:25 you can get the org.openembedded.dev Jan 11 12:08:34 http://pastebin.com/501092 <-- why is the bbclass not being included? Jan 11 12:08:42 with git Jan 11 12:09:12 zecke: what I'd really like now I think is "what's different between dev and dreambox" Jan 11 12:09:29 gb2: the reason for the seperate branch is that it's something like a "stable" branch, as it's used for a commercial product. the other reason is that there are some hacks which should be done in a nicer way. and the final reason is lazyness from my side (sorry for that). Jan 11 12:09:41 ah okay never mind Jan 11 12:09:48 tmbinc: ah, ok. Jan 11 12:09:54 gb2: i've an rsync source for that branch, if you need that. Jan 11 12:10:21 I'm pulling the OE.db.bz2 snap and I ought to be able to spit out the tree from that. Jan 11 12:10:36 OE.db.bz2 doesn't include the .dreambox branch, iirc Jan 11 12:10:42 oh :( Jan 11 12:10:57 the wiki seemed to imply it did Jan 11 12:11:05 hm maybe that changed Jan 11 12:11:21 rsync://dreamboxupdate.com/openembedded/oe.db should be a semi-current version including both branches if you want Jan 11 12:11:59 I got past my problem with glibc-initial btw. It will be nice to find what differences there are though, and I may want to apply that to my setup here. Jan 11 12:12:38 tmbinc: how large is the db file? Jan 11 12:14:04 ~67MB or something? Jan 11 12:15:01 the one i just grabbed is 73M Jan 11 12:15:05 ok, here goes monotone Jan 11 12:15:06 we're using glibc 2.3.5+cvs20050627, which one do you use? gcc 3.4.4, binutils 2.15.91.0.2, but this is probably a very bad choice Jan 11 12:15:35 oh, my monotone is old :( Jan 11 12:16:20 tmbinc: right now I'm just wanting something glibc 2.3.2+ gcc 3.2-3.4 Jan 11 12:16:30 hehe Jan 11 12:16:39 what device are you building for, just out of interest? Jan 11 12:17:23 Luke-Jr: I suspect the bbclass is being included but doesn't do what you want. We already have functions called do_unpack... Jan 11 12:17:24 at the moment, i'm running stuff on a mpc7410 based powermac running ubuntu of some sort, but my eventual target is a freescale processor. Jan 11 12:17:45 ah ok Jan 11 12:19:45 pb_: git is current, darcs is 52 revs behind Jan 11 12:21:14 tmbinc: it looks like the db snapshot does have the branch in it Jan 11 12:22:42 RP: and I want to override it Jan 11 12:22:54 gb2: ok fine Jan 11 12:36:43 RP: I put 'echo kde_split' in the root section of the bbclass and nothing happens, still Jan 11 12:37:44 Luke-Jr: well change bitbake to be more verbose about which files it includes Jan 11 12:37:51 Luke-Jr: maybe -DDD is already enough Jan 11 12:37:56 zecke: bitbake -DDD? Jan 11 12:38:04 is it possible to change w/o restarting bitbake? Jan 11 12:39:01 from within the shell? Jan 11 12:39:13 Luke-Jr: should be if you drop into the expert mode. but don't ask how Jan 11 12:39:52 zecke: I should be able to override do_unpack, though, right? Jan 11 12:40:23 I think you should be able to Jan 11 12:51:54 what the difference between tmp/cross and tmp/staging ? Jan 11 12:52:10 gremlin[it]: cross is the cross compiler itself (nothing more) Jan 11 12:52:21 gremlin[it]: staging is all the extra gimmicks you might finde useful Jan 11 12:53:31 zecke: very good Jan 11 12:58:07 mhh ok ... so if a package (pppd) need an include file (crypt.h) which is better to use ? in cross or staging ? (it's present in both) Jan 11 13:00:48 gremlin[it]: it shouldn't be in cross (if we are talking about OpenSSL) Jan 11 13:01:52 no pppd just need the 'standard' crypt.h present in libc :) Jan 11 13:03:47 but pppd for some reason look for in in /usr/include and /usr/lib .. usually that work so no one matter about ... but for me libcrypt.so is in /usr/lib64 so i fai all time to build pppd :( ... Jan 11 13:04:53 that sounds like a bug in ppp.bb Jan 11 13:05:15 it definitely shouldn't be looking in /usr/include or /usr/lib for those files Jan 11 13:05:59 pb_ sincerelly i report this bug all time i do a tmp wipeout .. :) Jan 11 13:06:15 heh Jan 11 13:08:30 pb_ can u suggest me a machine that can be build with 2.4 or 2.6 kernel so i can do the same for h3600 ? Jan 11 13:09:52 gremlin[it]: which version of pppd? Jan 11 13:10:32 ppp-2.4.3-r0 Jan 11 13:10:36 * zecke will start with the subversion tailor... Jan 11 13:10:47 gremlin[it]: did you ever look at the Makefile? Jan 11 13:11:04 yes ... i correct it by hand all time ;) Jan 11 13:12:12 the bad thing of ppp is that it doesent use auto-tools ... so for me wasn't so easy to create a real patch for oe ... just a trick ... Jan 11 13:13:19 NOTE: Fetch cvs://anoncvs@sources.redhat.com/cvs/glibc;module=libc Jan 11 13:13:19 cvs [checkout aborted]: reading from server: Connection reset by peer Jan 11 13:13:22 foo :( Jan 11 13:13:27 * gb2 taps his foot Jan 11 13:14:20 gremlin[it]: h3900? Jan 11 13:14:26 I haven't tried that for a while though Jan 11 13:16:08 Luke-Jr: If the echo doesn't print, you're not overriding do_unpack properly. How you do that properly, I don't know. Jan 11 13:19:50 pb_ ok .. just to have an idea on what things should be done :) Jan 11 13:20:09 mhhh s/on what things/on how things/ Jan 11 13:26:45 shouldn't be much. really, it's just a case of building the right kernel and installing the appropriate modules. Jan 11 13:32:18 * zecke is a tailor hackor... Jan 11 13:37:02 zecke: eleet Jan 11 13:38:48 * CosmicPenguin patiently waits for tailor P4 support Jan 11 13:39:02 CosmicPenguin: I think tailor is the wrong approach Jan 11 13:56:35 lrg|home: ping Jan 11 13:57:50 do13: pong Jan 11 13:58:20 lrg|home: wm97xx_config_gpio settings are lost after resume? Jan 11 13:58:44 do13: ah, thanks. will fix Jan 11 13:59:00 do13: does the tosa use the gpios ? Jan 11 13:59:47 lrg|home: np. thx for the patch. I'll send you details Jan 11 14:00:03 do13: cool, thanks Jan 11 14:04:02 lrg|home: mail send! Jan 11 14:04:53 lrg|home: the external mic detection wasn't working after resume:) Jan 11 14:05:46 do13: ok thanks. Jan 11 14:15:14 * Philippe is away: sleeping, working or partying in Helsinki Jan 11 14:31:53 night all Jan 11 14:32:00 night Jan 11 14:32:01 night Jan 11 14:52:55 to compile a package for the sharp rom, I set DISTRO=sharprom-compatible. do I also need to use the org.openembedded.oz354fam083 branch, or will the org.openembedded.dev branch work? Jan 11 15:29:36 In what directory do I need to say "monotone update -rjan2006prebreakage "? In the one containing oe.db? Jan 11 15:40:30 zecke: http://www.rpsys.net/openzaurus/temp/bitbake-rprovides-r5.patch is the tidied up version Jan 11 15:40:54 RP: okay Jan 11 15:41:37 RP: a small hint. If you would have +5 lines of comments on the first hunk I see I would not look too carefully at the rest Jan 11 15:44:57 zecke: I don't understand Jan 11 15:45:13 RP: My first sight is explode_deps Jan 11 15:45:30 zecke: Ah, which isn't commented, right. Jan 11 15:45:33 RP: and the lack of specification. This leads to me looking more carefully at the patch, and ++nitpicking Jan 11 15:47:02 zecke: I did comment the other functions although evidently I missed one :-/ Jan 11 15:48:12 RP: anyway the patch already looks a lot cleaner Jan 11 15:48:42 RP: I need to understand why patch removed getProviders Jan 11 15:50:18 zecke: It adds GetProvidersRun further down Jan 11 15:51:13 right, I need to figure out the meaning ;) Jan 11 15:51:51 zecke: I split the handling of runtime depends and build depends. That function combined both in one function so it had to be changed. Jan 11 15:52:56 RP: hehe, well I need to run the 'automatic' zecke-brain proof machine on the patch Jan 11 15:53:40 http://www.rpsys.net/openzaurus/temp/bitbake-rproviders-r6.patch has a comment for explode_deps :) Jan 11 15:54:52 I've built images using the previous patch. This one reversed the order of build and runtime dependency resolution (its now correct) so I need to rerun some test builds but I'm fairly confident it will work correctly Jan 11 15:55:55 fucking stupid svk... Jan 11 15:59:13 night all Jan 11 15:59:45 'night dirk Jan 11 16:03:05 back in about 30 mins Jan 11 16:08:33 *cry* fucking svk... Jan 11 16:08:55 heh Jan 11 16:09:01 what's svk doing? Jan 11 16:09:14 svk sync claims that a path does not exist.. and stops syncing... Jan 11 16:12:00 that does sound... undesirable Jan 11 16:12:15 zecke: I don't know the actual error message but I guess you could create it or tell svk to create it if neccessary Jan 11 16:12:49 reenoo_: well it should sync that? Jan 11 16:12:55 Name bezeichnet kein Verzeichnis des Dateisystems: Pfad '/projects/gmit/expway/mitv/comp_src' Jan 11 16:13:14 after a fresh svk mirror Jan 11 16:13:33 and I'm mirroring a branch Jan 11 16:14:23 so, you're doing an 'svk cp'? Jan 11 16:14:41 svk sync //projects/... Jan 11 16:17:23 hmm. odd Jan 11 16:17:57 maybe it doesn't like branches... Jan 11 16:18:03 I'm mirroring a branch Jan 11 16:19:12 no, it doesn't like either the remote or (more likely) the local repo/depot structure Jan 11 16:24:32 actually, that may not be true Jan 11 16:24:48 zecke: did you mirror the entire repo? or just the branch? Jan 11 16:26:23 reenoo_: just the branch Jan 11 16:32:41 I just created a branch here and mirrored synced it Jan 11 16:33:06 s: sync:/sync:/ Jan 11 16:33:12 err Jan 11 16:33:16 s: sync:/sync: Jan 11 16:35:55 http://pastebin.com/501699 Jan 11 16:38:01 we have project/(t,branches,trunk) so we can have the same branch name twice Jan 11 16:38:05 that might upset svk... Jan 11 16:38:15 svk doesnt care what layout you or upstream use. Jan 11 16:41:15 kergoth: it is picky how I name the mirrored path Jan 11 16:41:40 if a is in b's name it will not work. Maybe that same limitation persists in remote branches... Jan 11 16:41:45 anyway sleep well! Jan 11 17:06:41 either debug mode doesn't mention bbclasses or it's not being included Jan 11 17:07:46 to compile a package for the sharp rom do I need to use the org.openembedded.oz354fam083 branch, or will the org.openembedded.dev branch work? Jan 11 17:08:39 neither will work, last I checked Jan 11 17:08:45 unless you get really lucky Jan 11 17:08:51 ah Jan 11 17:09:05 somewhere the wiki said it would work if i set distro to sharprom-compatible, but thats no longer true? Jan 11 17:09:16 shrug Jan 11 17:09:19 maybe it is, try Jan 11 17:09:35 im pulling the oz354 source, takes a while Jan 11 17:12:36 no reason to think an OZ branch would work w/ Sharp Jan 11 17:13:17 yeah, im going to need that for oz anyways though Jan 11 17:13:33 why? Jan 11 17:13:40 use openzaurus-unstable :) Jan 11 17:13:49 isn't it needed for the 3.5.4 oz? Jan 11 17:13:50 what's that? Jan 11 17:14:07 i just found out about OE today, so im kind of clueless Jan 11 17:15:13 org.openembedded.dev is the absolute latest stuff Jan 11 17:15:37 oz354fam083 is a (I think) bugfix-only in-progress release for OZ & Familiar Jan 11 17:16:32 oh.. so if I compile an ipk with oe.dev, i will be able to install it in OZ fine? Jan 11 17:16:56 I expect so Jan 11 17:17:11 I don't use OZ releases, tho Jan 11 17:17:16 I just build my own OZ-based OS for my Z Jan 11 17:17:42 the only differences is which packages you include, right? Jan 11 17:18:30 and that I always use openzaurus-unstable Jan 11 17:21:51 is that another branch? Jan 11 17:22:03 no Jan 11 17:22:07 its simply latest in .dev Jan 11 17:22:11 oh right Jan 11 19:59:10 i've started a qt gnokii application if anyone's interested http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/ Jan 11 21:20:58 http://pastebin.com/501092 <-- why is the bbclass not being included? Jan 12 00:06:10 RP: with bitbake -r4 everything seems broken (the whole RDEPENDS of slugos-image simply disappear for some builds), with -r1 things were working, but the PREFERRED_PROVIDER_virtual/kernel definately doesn't work. Here's the bitbake output (PREFERRED_PROVIDER_virtual/kernel is set to ixp4xx-kernel): Jan 12 00:06:13 NOTE: multiple providers are available (nslu2-kernel, linux-jlime-sh3, handhelds-sa, linux-openzaurus, gumstix, collie-kernel-24-8, poodle255-kernel-2.4-embedix, collie-kernel-48-16, mnci-ramses, opensimpad, nslu2-linksys-kernel, openzaurus-sa, linux-omap1, openzaurus-pxa27x, linux-mtx-1, linux-geodegx, collie-kernel-58-6, poodle-kernel-2.4-embedix, xanadux-ba-2.6, openzaurus-pxa, linux-h1940, ipod, collie-kernel-32-0, linux-omap-2.6, linux-h6300-om Jan 12 00:06:15 NOTE: consider defining PREFERRED_PROVIDER_kernel Jan 12 00:06:31 slugos-image RDEPENDS start with "kernel" Jan 12 01:47:02 jbowler: This is a bit of a concern as -r4 (which is basically the same as -r6) should work just as well :-/ Jan 12 01:47:32 morning all Jan 12 01:47:33 morning Jan 12 01:48:06 jbowler: I've just had an opie-image build sucessfully... Jan 12 01:48:49 jbowler: Perhaps its some issue specific to slugos image as I fixed a number of corner cases in the code, one of it which it might have been relying on Jan 12 01:53:45 RP: http://sam.rpsys.net/bitbake-rprovides-r5.patch the current patch? Jan 12 01:54:51 I find that if I add DEPENDS = "virtual/kernel virtual/ixp-eth" to slugos-image.bb it works fine, if I don't have it the required kernel is not used. Jan 12 01:55:04 XorA: http://www.rpsys.net/openzaurus/temp/bitbake-rproviders-r6.patch Jan 12 01:55:27 I haven't tried that patch yet though... Jan 12 01:55:56 RP: do you see any problem if I incorporate your LEDs patches into the NSLU2 (etc) kernel? Jan 12 01:55:57 jbowler: Ah, I think I understand. Try -r6 as I did change something which will have a big effect on slugos Jan 12 01:56:54 jbowler: No problem at all. I did talk to Alessandro about the NSLU using them Jan 12 01:57:26 jbowler: In -r4, RDEPENDS were built, then DEPENDS. This is obviously wrong and I changed that for -r5/r6 Jan 12 01:57:30 Presumably I have to set up the GPIO definitions correctly (number and polarity) in NSLU2 specific code? Jan 12 01:58:11 jbowler: You need a specific LED driver for the NSLU2. I think Alessandro might have some code already Jan 12 01:59:02 Yes, he said he had looked at it. Jan 12 02:00:42 -r6 has an error in the 'nothing provides' message, it was in r4 too: Jan 12 02:00:56 File "/home/nslu2/bitbake/bin/bitbake", line 489, in buildProvider Jan 12 02:00:56 bb.error("Nothing provides %s dependency %s" % (itemtype, item)) Jan 12 02:00:57 NameError: global name 'itemtype' is not defined Jan 12 02:01:21 (That's from "bitbake kernel", kernel is RPROVIDED I believe). Jan 12 02:02:45 jbowler: That's a typo, fixing, thanks Jan 12 02:04:23 Do I need to remove the cache going from r1 to r6? At present with r6 bitbake slugos-image gives me: Jan 12 02:04:35 ERROR: Nothing provides runtime dependency python-native Jan 12 02:04:35 NOTE: no buildable providers for ipkg-utils-native Jan 12 02:05:03 Ah. This is a bug in the metadata - add an RDEPENDS="" to ipkg-utils-native for now Jan 12 02:05:23 Basically, inherit native sets PACKAGES to "" which breaks things like this Jan 12 02:05:35 This isn't bitbake but OE being incorrect Jan 12 02:05:49 http://www.rpsys.net/openzaurus/temp/bitbake-rproviders-r7.patch has the typo fixed Jan 12 02:06:22 and that error shouldn't have been "kernel" but something else as its a build time dependency Jan 12 02:07:16 RP: ipkg-utils-native explicitly sets both RDEPENDS and PACKAGES: Jan 12 02:07:24 RDEPENDS = "python-native" Jan 12 02:07:25 # Avoid circular dependencies from package_ipk.bbclass Jan 12 02:07:25 PACKAGES = "" Jan 12 02:07:28 * XorA boggles that the GP2X is linux 2.4 Jan 12 02:08:27 jbowler: That PACKAGES isn't needed as native.bbclass also does this if I remember rightly which is why python-native can't be found Jan 12 02:09:32 I don't know what the DEPENDS and RDEPENDS of a native packahe should be exactly really. I guess the above is correct, native.bbclass shouldn't be setting PACKAGES and should set BUILD_ALL_DEPS = 1 Jan 12 02:10:53 In general it should be that foo-native includes foo and foo has a list of RDEPENDS "a b c", then foo-native should RDEPEND on "a-native b-native c-native". Jan 12 02:11:08 Getting that to work might be difficult though ;-) Jan 12 02:11:50 jbowler: I think my comments above have that covered, Changing PACKAGES="" in native.bbclass is going to break things though :) Jan 12 02:12:25 For now, until we fix other things, setting RDEPENDS="" in that one .bb file is a tempting work around :) Jan 12 02:13:02 seeing as the plan is that STAGING becomes package controlled, shouldn't native become a build of a package for ARCH=${BUILD_ARCH} or something similar? Jan 12 02:13:13 and then -native disappears Jan 12 02:13:43 Yes, it should - the -native package and inherit native already do that, but they also stop the packaging. Jan 12 02:14:27 There are a lot of issues here which we can hit once we have "normal" packaging for staging working. One step at a time... :) Jan 12 02:14:46 RP: fair enough, Im still too scared to look at bitbake code Jan 12 02:16:01 It is scary, especially if you don't know python verry well :) Jan 12 02:16:40 But I'm really happy with -r6 as its feels like its doing everything properly Jan 12 02:17:04 jbowler: I'll be very interested to see if slugos-image builds... Jan 12 02:17:16 RP: I dont, I think Im too old for these new fangled languages :-) nearest I got is a patch for binconfig.bbclass many years ago Jan 12 02:17:49 It looks like it does, but it's just starting slugos-lag, that will show if there are any problems now (I have the slugos-image.bb DEPENDS commented out again) Jan 12 02:18:56 jbowler: Other changes from -r4 include ignoring circular runtime dependencies and only building the rdepends of subpackages that are actually rdepended on themselves Jan 12 02:19:25 The latter point is important for meta-opie as it declares lots of tasks but opie-image only uses a small number of them Jan 12 02:20:07 (a task being a subpackage of RDEPENDS for a particular function like task-bootstrap) Jan 12 02:22:19 Is this a side effect of an r1->r7 change? Jan 12 02:22:21 ERROR: Cannot satisfy the following dependencies for kernel: Jan 12 02:22:21 kernel-image-2.6.15 Jan 12 02:23:37 jbowler: Have you pulled the change to kernel.bbclass which adds PACKAGES_DYNAMIC = "kernel-image-*" to kernel.bblcass? Jan 12 02:23:51 It was a while ago so I'd suspect you should have... Jan 12 02:23:59 morning all Jan 12 02:24:03 hi dirk Jan 12 02:24:14 RP: I believe I have that change Jan 12 02:24:18 hi Richard Jan 12 02:25:08 I actually changed bitbake code while bitbake was running though... Jan 12 02:26:16 jbowler: I can't find that error in my bitbake code... Jan 12 02:27:09 It's something to do with deleting the slugos-image DEPENDS = "virtual/kernel virtual/ixp-eth", because when I rebuild now I get the multiple providers message for the kernel. Jan 12 02:28:27 It should no longer suggest PREFERRED_PROVIDER_kernel as a solution though? Jan 12 02:28:48 No, it says: Jan 12 02:28:52 NOTE: consider defining a PREFERRED_PROVIDER to match runtime kernel-image- Jan 12 02:29:42 Ah, kernel-image-. Not kernel.That's interesting Jan 12 02:32:35 jbowler: Does it continue past that or error out with the cannot satisfy kernel-image error? Jan 12 02:33:08 Its interesting is says kernel-image and not kernel-image-2.6.15 as well... Jan 12 02:35:05 The build complains about multiple providers, but the image rootfs step cannot find kernel-image-2.6.15 even though it downloaded kernel_2.6.15-r3.0_ixp4xxl.ipk Jan 12 02:35:18 morning ! Jan 12 02:35:51 Still, the problem may be that I changed the bitbake - it only built that kernel with the old (-r1) bitbake. Jan 12 02:36:04 jbowler: Ah, that's an ipkg error. Jan 12 02:36:13 Yes Jan 12 02:36:40 jbowler: Check if kernel-image-2.6.15_2.6.15-r3.0_ixp4xxl.ipk exists Jan 12 02:37:07 I suspect bitbake will have created kernel-image-_2.6.15-r3.0_ixp4xxl.ipk instead Jan 12 02:37:31 Your question becomes why has ${KERNEL-VERSION} disappeared? Jan 12 02:37:53 I'm not sure - I deleted deploy/ipk/kernel* Jan 12 02:38:11 Ah, ok, it still happens... Jan 12 02:38:49 And I have kernel-image-2.6.15_2.6.15-r3.0_nslu2l.ipk Jan 12 02:39:06 (That's the correct name - because it now picks up the correct kernel .bb) Jan 12 02:39:58 ipkg isn't attempting to install the kernel-image- ipk Jan 12 02:40:32 It downloads kernel_2.6.15-r3.0_ixp4xxl.ipk Jan 12 02:40:50 If ipkg was asked to install kernel-image- instead of kernel-image-2.6.15, that would break it Jan 12 02:41:18 I think you probably need to clean tmp and work out exactly where the build is breaking down... Jan 12 02:42:32 slugos-lag is already half way through, and that started clean with -r7 Jan 12 02:45:19 ok. I've noticed my last opie builds were slighly more correct in the build choices - it build libxine-fb instead of libxine for example Jan 12 02:46:02 I think it's my mistake - my ipkgarchs is not up-to-date Jan 12 02:49:19 ah, ok. That would explain why ipkg was upset **** ENDING LOGGING AT Thu Jan 12 03:00:21 2006