**** BEGIN LOGGING AT Mon Mar 03 10:59:56 2008 Mar 03 11:28:11 03slapin 07org.oe.dev * r6bfc098b... 10/ (1 packages/linux/linux-hackndev-2.6_git.bb): linux-hackndev: Changed repo location. Should fix kernel fetch bugs. Mar 03 11:28:22 03hrw 07org.oe.dev * r8466dbeb... 10/ (1 packages/vagalume packages/vagalume/vagalume_0.5.1.bb): vagalume: added 0.5.1-1 version of GTK+ based Last.fm client Mar 03 11:28:30 03hrw 07org.oe.dev * r4d1e9bbb... 10/ (1 conf/checksums.ini): checksums.ini: added some entries Mar 03 11:29:15 woglinde: hey Mar 03 11:29:23 he zecke Mar 03 12:00:33 re Mar 03 12:05:58 morning all Mar 03 12:09:09 hi rp Mar 03 12:09:28 time for lunch Mar 03 12:09:36 zecke: Does my reply help some of your fears or not? Mar 03 12:09:44 RP: let me reply Mar 03 12:09:54 zecke: ok :) Mar 03 12:13:15 RP: basicly go ahead Mar 03 12:13:33 zecke: You are right to ask those questions ;-) Mar 03 12:14:00 RP: I don't like the answer to the 2nd question... Mar 03 12:14:13 RP: did you test the symlink thing? is this an assumption or does this work? Mar 03 12:15:01 zecke: It does work, its actually how OE.dev is operating (albeit with a modern toolchain, not an old one) Mar 03 12:15:52 cool Mar 03 12:16:33 If we didn't change pkgconfig's mode of operation, an ABI change wouldn't have been needed Mar 03 12:25:41 so we have a go now? Mar 03 12:29:08 hi mickeyl btw. Mar 03 12:31:46 hi mickeyl Mar 03 12:32:10 hi guys Mar 03 12:33:26 hi! Mar 03 12:35:27 when im bitbaking gumstix-basic-image I get errors with the uisp package..anyone know what to do about this? Mar 03 12:35:29 * woglinde waits for ibot *g* Mar 03 12:41:15 hey Mar 03 12:41:28 does openembedded run on the treo650 with gsm support? Mar 03 12:42:01 and should i use the main development tree? Mar 03 12:42:39 fredmorcos: that is the wrong question. OE is a build environment, it allows to build software. sure you can use OpenEmbedded to build software on your treo650, it will be slow though Mar 03 12:43:17 fredmorcos: You want to pick a GUI (e.g. GPE, GPE phone edition, Qtopia, FooPhone) and then find out if it is working on your treo650 Mar 03 12:43:30 fredmorcos: and then pick a distribution offered for the treo Mar 03 12:43:56 i'm more interested in running the linux kernel than running a specific gui over palmos Mar 03 12:46:16 fredmorcos: then search for the kernel community, I think hackndev.com has support, and then come back :) Mar 03 12:46:52 alright, thanks Mar 03 12:52:44 hi zecke Mar 03 12:54:37 hi pb Mar 03 13:03:03 03koen 07org.oe.dev * r45bb832d... 10/ (1 packages/images/initramfs-bootmenu-image.bb): initramfs-bootmenu-image: add cpio.gz forcefully to IMAGE_FSTYPES Mar 03 13:03:22 hi woglinde Mar 03 13:16:48 hmm.. I get NOTE: preferred version csl-arm-2007q3 of gcc-cross not available (for item virtual/arm-angstrom-uclinuxeabi-gcc) but I do have a gcc-cross_csl-arm-2007q3.bb (actually trying to build it with -b now to see what happens) Mar 03 13:16:56 any ideas why it might "not be available"? Mar 03 13:25:04 * * OE Bug 3924 has been created by  Mar 03 13:25:06 * * linux-handhelds-2.6-2.6.21-hh20-r13-do_deploy Mar 03 13:25:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3924 Mar 03 13:29:26 hi all! Mar 03 13:36:04 * * OE Bug 3925 has been created by  Mar 03 13:36:06 * * linux-handhelds-2.6-2.6.21-hh20-r13-do_rm_work Mar 03 13:36:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3925 Mar 03 13:44:29 03pfalcon 07org.oe.dev * r388cd675... 10/ (4 files in 3 dirs): Mar 03 13:44:29 klibc-utils-fstype 1.1.1: Rename to klibc-utils-fstype-static. Mar 03 13:44:29 * Dirty rename games until we'll have klibc-utils buildable and working. Mar 03 13:44:36 03mickeyl 07org.oe.dev * r0be7e247... 10/ (1 packages/ode/files/install.patch packages/ode/ode_0.9.bb): ode 0.9 fix install.patch Mar 03 13:44:43 03mickeyl 07org.oe.dev * rfbe4ca19... 10/ (1 packages/gsm/files/gsmd): gsmd svn log to syslog Mar 03 13:44:50 03mickeyl 07org.oe.dev * rc052dd40... 10/ (3 files in 3 dirs): python-pyode 1.2.0 needs an install.patch Mar 03 14:03:25 03koen 07org.oe.dev * rd9d41f47... 10/ (3 files in 2 dirs): Mar 03 14:03:25 linux-handhelds: deploy tweaks: Mar 03 14:03:25 * copy zImage to zImage- to allow changing of INITRAMFS_PATH Mar 03 14:03:25 * make a modules.tgz tarball Mar 03 14:03:30 03pfalcon 07org.oe.angstrom-2007.12-stable * r494c6834... 10/ (1 conf/distro/include/angstrom.inc): Mar 03 14:03:30 applied changes from 6c2d621bdfd446c13552a5e4b126ef9c5dd20106 Mar 03 14:03:30 through 3859c4593b2a4ff696a5e81383ed8bc6dd957598 Mar 03 14:03:32 angstrom.inc: Make Angstrom bitbake caches to be per libc mode. Mar 03 14:03:34 03pfalcon 07org.oe.angstrom-2007.12-stable * rae3b8843... 10/ (1 BACKPORTS.txt): BACKPORTS.txt: Record bitbake cache path patch. Mar 03 14:16:15 re Mar 03 14:16:23 ~seen rschuster Mar 03 14:16:24 rschuster was last seen on IRC in channel #oe, 2d 17h 17m 1s ago, saying: 'Laibsch: ah ok. thanks!'. Mar 03 14:20:18 hrw: hi Mar 03 14:21:49 lumag: sorry for delay - I still did not found time to check custom papers Mar 03 14:23:41 Nah, That's ok. Didn't have time for tosa also Mar 03 14:25:30 BTW: is there any standard procedure to get commit access? Mar 03 14:26:06 lumag: you can commit to your local mtn db ;) Mar 03 14:26:48 lumag: show us your patches etc.. Mar 03 14:27:03 lumag: write to ML and we will reply with 'we want you' ;D Mar 03 14:27:12 hrw: :) Mar 03 14:30:30 zecke: I can compile everything as I would find useful. Mar 03 14:43:10 re Mar 03 14:43:39 re Mar 03 14:57:28 hi mr_nice Mar 03 15:00:48 hi woglinde Mar 03 15:11:03 anyone know what an XPA2X0 is? I found it mentioned in openzaurus register monitor module Mar 03 15:11:24 is it a pxa250 or 255? Mar 03 15:11:55 feel free to point me at a better place to ask :-) Mar 03 15:12:03 wookey: or pxa270? :) Mar 03 15:12:19 pxa270 has about 200 more registers than are in that module Mar 03 15:12:33 (I've just typed them all in!) Mar 03 15:12:51 wookey: There were zaurus models with 250, 255 and 270 processors in Mar 03 15:13:06 and with pxa210 Mar 03 15:13:14 sl-a300 has pxa210 Mar 03 15:13:36 hmm, mayabe it's a typo for pxa210/pxa250. Mar 03 15:13:37 wookey: ever heard about pxaregs util? Mar 03 15:14:06 you are going to tell me there is already a registers-reading util for pxa270? Mar 03 15:14:12 it is Mar 03 15:14:19 read/write Mar 03 15:14:19 wookey: I'm surprised you didn't use pxa-regs.h the kernel Mar 03 15:14:43 I did wonder, but only found sa1100 and this xpa thing online Mar 03 15:15:10 it did seem unlikely that some other sucker hadn't already typed all this tedious guff in... Mar 03 15:15:40 wookey: http://www.mn-logistik.de/unsupported/pxa250/ Mar 03 15:16:26 RP: that doesn't have register descriptions in it, but yeah, it mght have been msart Mar 03 15:18:36 bye Mar 03 15:18:48 it was marginally easier to copy it all out of the datasheet table Mar 03 15:22:50 hrw: thanx for that link - should have asked here first. Now - can I be bothered to update that for 270 as well... Mar 03 15:25:05 * * OE Bug 3926 has been created by  Mar 03 15:25:07 * * linux-handhelds-2.6-2.6.21-hh20-r14-do_compile Mar 03 15:25:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3926 Mar 03 15:26:50 wookey: OE has pxaregs in repository - check do we have patches for it or not Mar 03 15:26:53 Is it my internet connection, or is www.openembedded.org shaky at the moment Mar 03 15:47:04 * * OE Bug 3927 has been created by  Mar 03 15:47:06 * * simpad kernel update to 2.6.24 Mar 03 15:47:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3927 Mar 03 15:51:26 Puzzle with a prize: Mar 03 15:51:28 http://sourceforge.net/mailarchive/forum.php?thread_name=5e088bd90803030729o5bb6b406y28d411b17b02097e%40mail.gmail.com&forum_name=gumstix-users Mar 03 16:09:43 Crofton: ask, if the characters after 'l' always match with any chars in the udev text. Mar 03 16:10:08 Crofton: I suspect multithreaded concurrent output to the serial output. Mar 03 16:13:03 likewise: I suspect the same, but what is strange is that rather than the typical interleaving of all of the characters from the 2 competing messages, large numers of characters are just dropped on the floor and you never see them Mar 03 16:15:52 sakoman_: tail of dmesg looks good? Mar 03 16:16:07 sakoman: Does it happen on just gumstix or other devices too? Mar 03 16:18:20 RP: no idea! Mar 03 16:21:37 likewise: dmesg seems to be a subset of the console messages. No corruption there. But all of the messages contained in dmesg are also not corrupt on the console Mar 03 16:24:15 strange, I would expect dmesg to contain all kernel messages, let me look this up. Mar 03 16:25:05 * * OE Bug 3927 has been RESOLVED (FIXED) by Mar 03 16:25:07 * * simpad kernel update to 2.6.24 Mar 03 16:25:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3927 Mar 03 16:44:19 likewise: here's a comparison of the difference between console & dmesg test for a portion of the boot: http://pastebin.ca/926206 Mar 03 16:45:04 * * OE Bug 3928 has been created by  Mar 03 16:45:06 * * linux-2.6.24-r7-do_patch Mar 03 16:45:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3928 Mar 03 16:45:12 text, not test :-) Mar 03 16:45:52 03hrw 07org.oe.dev * raebabeb1... 10/ (1 packages/maemo4/hildon-control-panel_2.0.1.bb): hildon-control-panel: added 2.0.1 Mar 03 16:46:00 03hrw 07org.oe.dev * r242a466e... 10/ (1 packages/ukeyboard packages/ukeyboard/ukeyboard_1.2.bb): ukeyboard: added 1.2 version of alternative Maemo control panel for keyboards Mar 03 16:46:11 03Bernhard.Guillon 07org.oe.dev * r2cd7eb1d... 10/ (17 files in 4 dirs): simpad: add 2.6.24 and fix jffs2 params Mar 03 16:46:22 03koen 07org.oe.angstrom-2007.12-stable * r1453346f... 10/ (1 BACKPORTS.txt): BACKPORTS: add simpad kernel Mar 03 16:49:00 sakoman_: nice puzzle indeed Mar 03 16:49:59 03hrw 07org.oe.dev * ra5c19d4b... 10/ (1 packages/djvulibre/djvulibre_3.5.20.bb): djvulibre: fix SRC_URI Mar 03 16:49:59 ~curse sf.net for using very long urls which are hard to copy paste Mar 03 16:50:00 May the fleas of a thousand camels infest your most sensitive regions, sf.net for using very long urls which are hard to copy paste ! Mar 03 17:10:07 http://pokylinux.org/ - new Poky release, new website Mar 03 17:11:27 hrw: and manual ;-) Mar 03 17:11:41 yes Mar 03 17:12:10 The great Poky Handbook (soon available in print, hard leather cover limited edition) Mar 03 17:13:34 re zecke Mar 03 17:14:26 elo mickeyl Mar 03 17:15:28 hi Cliff Mar 03 17:16:51 RP: nice exposure (is that you?) :-) Mar 03 17:17:11 * likewise -> home Mar 03 17:17:20 how cute Mar 03 17:24:22 hi hrw Mar 03 17:25:03 * CosmicPenguin just got his annual urge to update his OE repository and maybe even submit some XO patches Mar 03 17:53:32 hrw: Hello Marcin Mar 03 17:53:43 hrw: getting any sleep these days? Mar 03 17:55:14 cbrake: not so bad so far Mar 03 18:22:13 hmm, if I want to make a UI in python what would be a good package to build (for an x11 image) Mar 03 18:22:31 python-pygtk? Mar 03 18:23:10 wasn't there also some gladexml or pyglade stuff in addition? Mar 03 18:23:40 thanks :) Mar 03 18:23:58 I couldn't find wkpython Mar 03 18:48:24 does anyone know what happens if I cross compile with --enable-largefile while the target system has no largefile support? Mar 03 18:48:48 not sure what defaults to use for a package Mar 03 18:56:32 Jin^eLD: try it out? ultimately you have this cached in your site-conf (for autotools) for your system Mar 03 18:57:13 zecke: well I do not think that I have a system to test.. just wonder what happens if I try to run a binary that was compiled with --enable-largefile on a system that does not have it Mar 03 18:59:23 Jin^eLD: it shouldn't link Mar 03 18:59:37 oh Mar 03 18:59:55 so.. I probably should avoid using --enable-largefile/--disable-largefile in my configure options and allow OE to choose? Mar 03 19:00:28 Jin^eLD: use it, breakage will be seen. I would be schocked to see systems without largefile support Mar 03 19:01:07 zecke: tweaking the mediatomb .bb for the new 0.11 release ;) Mar 03 19:01:08 Jin^eLD: AFAIK it is in the c library and a interface from the kernel, we set 2.4 as minimal kernel version in the glibc configure anyway... Mar 03 19:01:22 night! Mar 03 19:01:46 would it make sense to enable a trancoding option? can arm handle OGG->WAV using ogg123/usual apps? Mar 03 19:03:29 Jin^eLD: pxa and s3c2440 can easilly Mar 03 19:03:44 Jin^eLD: as can OMAP and mx31 Mar 03 19:03:58 Jin^eLD: and OMAP/mx31 might even manage video transcoding Mar 03 19:04:01 hm, I will leave it on then :> thanks for the hint Mar 03 19:04:29 our transcoding is implemented via external plugins (i.e. you can use whatever app you want, we launch a process, data is transferred via fifos) Mar 03 19:04:35 so no additional dependencies Mar 03 19:04:46 Jin^eLD: I know, Ive used mediatomb Mar 03 19:04:51 :) Mar 03 19:05:04 Jin^eLD: it upset my n810 though :-( Mar 03 19:05:26 the n8x0 is kind of picky about video Mar 03 19:05:35 and we were not able to make it play something that is transcoded Mar 03 19:06:00 had it working with ps3 until firmware 2.10 spoiled the game Mar 03 19:06:09 how that? Mar 03 19:06:16 what kind of problem are you actually having? Mar 03 19:06:43 mediatomb just seemed to lock solid Mar 03 19:06:47 Jin^eLD: the problem that you were discussing with others on mailing list Mar 03 19:06:59 Jin^eLD: so I canned using it until new version Mar 03 19:07:07 give me a hint Mar 03 19:07:21 the forum is full of problems :) which one exactly was it again? Mar 03 19:07:57 Jin^eLD: I cant remeber the exact post, but it was exactly the issue I had, and I think you had made changes to fix it in svn Mar 03 19:08:06 XorA: we released 0.11 yesterday Mar 03 19:08:19 or day before yesterday or something Mar 03 19:08:21 * XorA will retest Mar 03 19:08:35 thanks, let me know if it works please Mar 03 19:17:00 mhm, how to figure out this? preferred version csl-arm-2007q3 of gcc-cross-initial not available (for item gcc-cross-initial) Mar 03 19:17:14 it works for binutils for some reason, but for gcc it ignores my package Mar 03 19:19:46 its being parsed ok, so it is there Mar 03 19:21:31 !seen rp Mar 03 19:21:33 woglinde, rp is right here! Mar 03 19:22:01 hm are the sysroot changes now in .dev? Mar 03 19:22:42 woglinde: Not yet, the poky release has distracted me Mar 03 19:23:06 rp okay thanks Mar 03 19:24:37 doh.. time to go home I guess Mar 03 19:24:48 bye jinled Mar 03 19:24:52 nite Mar 03 19:25:06 no leds blinking yet ;) Mar 03 19:25:18 args sorry Mar 03 19:25:27 =)) Mar 03 19:25:28 never mind Mar 03 19:31:52 bye Mar 03 19:32:05 bye hrw Mar 03 19:41:35 hi ljp Mar 03 19:59:36 hi woglinde Mar 03 20:12:02 pb_, The BT online phone book provided useful information for me :) Mar 03 20:16:53 Does opkg need curl or curl-native for do_configure? Mar 03 20:26:04 curl Mar 03 20:26:16 opkg-native needs curl-native Mar 03 20:46:28 Crofton: ah, very good Mar 03 20:47:53 hi lrg Mar 03 20:48:37 hey pb_ Mar 03 21:03:09 so ich lass dann mal bauen Mar 03 21:03:16 und checke es nacher in .dev ein Mar 03 21:10:35 hi everybody Mar 03 21:12:12 hi thesing Mar 03 21:14:39 thesing: hi Mar 03 21:16:54 woglinde: ich verstehe einbischen duetsch :) Mar 03 21:18:06 * flo_lap nicht ;) Mar 03 21:24:25 args Mar 03 21:56:12 * flo_lap wonders about Koen's suggestion for a feature freeze Mar 03 21:58:41 flo_lap: You think it would be good or bad? Mar 03 22:00:25 RP: well... cleaning up is a good idea, but freezing for three months is far from reality Mar 03 22:00:32 yeah Mar 03 22:00:40 OE is many thing to many people Mar 03 22:00:48 this is a problem and a feature Mar 03 22:01:02 It won't work for .dev which is probably why koen suggested a branch Mar 03 22:01:22 RP: imho cleaning up in the active tree - maybe by marking packages - should be fine Mar 03 22:01:59 flo_lap: With current manpower, I don't think there is much else we can do Mar 03 22:02:15 we just need to figure out how to mark packages sanely Mar 03 22:02:27 it seems like we need several broken flags Mar 03 22:02:32 RP: then we would end up in a clean but badly outdated tree Mar 03 22:02:39 :) Mar 03 22:02:44 RP: with the manpower in mind :) Mar 03 22:03:59 I think having .dev to do major work is good Mar 03 22:04:02 We have a lot of packages that might be not the best but work for their purpose. Mar 03 22:04:13 too many branches and we will be out of sync sooner Mar 03 22:04:24 QACHECKDATE = "20080303" QABUILDTEST = "(arm|x86)" ? Mar 03 22:04:55 QACHECKDATE_arm = "" :) Mar 03 22:05:04 * * OE Bug 3929 has been created by  Mar 03 22:05:06 * * opkg-native fails to build from scratch Mar 03 22:05:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3929 Mar 03 22:22:07 RP: I thought that having a file like sane-srcrevs.inc might be better than having all that stuff in the bb files themselves Mar 03 22:22:30 RP: What is the semantics of QACHECKDATE_arm = ""? Mar 03 22:22:53 "builds without QA errors thrown at you from bitbake"? Mar 03 22:23:57 Laibsch: The date would be in "" Mar 03 22:24:07 so much is clear Mar 03 22:24:33 RP: One could have qacheck-arm.inc with lines like 'ffmpeg = "20080202"' Mar 03 22:25:11 Laibsch: QACHECKDATE_pn-ffmpeg = "20080202" surely? Mar 03 22:25:39 I think that is cleaner and it might even be possible to semi-automate the creation of this file, IOW, bitbake writes back information just like it does for the md5sum/shasums now Mar 03 22:25:53 RP: No Mar 03 22:26:20 My proposal is to have that qacheck information not in the bb file, but in a separate, per-arch file Mar 03 22:26:33 similar to the md5sum/shasum thing Mar 03 22:26:59 Laibsch: that makes no use of overrides and isn't easily accessed from our normal variable scope? Mar 03 22:27:27 You know the details better than I do Mar 03 22:27:41 I thought/think it would be a nicer way to collect the data Mar 03 22:27:46 Would it create problems? Mar 03 22:28:04 The file could be included just like we do with sane-srcrevs.inc, no? Mar 03 22:28:30 In that case, maybe it would need to be QACHECKDATE_pn-ffmpeg = "20080202", like you suggested Mar 03 22:28:44 But not in the bb file, but a separate file Mar 03 22:29:54 So, I guess I probably should have answered "yes", instead of "no" to your earlier question ;-) Mar 03 22:31:29 I don't really have a problem with this information being in the recipe itself Mar 03 22:31:51 We want to make it easy to see from inspection when a file was last looked at Mar 03 22:34:31 RP: do you think that everyone who looks at a bb file will update the date? It would be easier to maintain an automatic generated list from autobuilder or so. Mar 03 22:35:06 thesing: One problem is we want to know when someone last looked at and cleaned up the recipe Mar 03 22:35:23 thesing: Another is whether and when someone was able to build it Mar 03 22:35:28 RP: doesn't mtn give us this information? Mar 03 22:35:49 thesing: We get info that someone changed it but that doesn't mean much Mar 03 22:36:04 Someone might have done a search and replace over the tree Mar 03 22:36:29 We have a ton of recipes which people obviously haven't looked at or built in years Mar 03 22:37:31 RP: Let me get back to my original question Mar 03 22:37:41 RP: What is the semantics of QACHECKDATE_arm = ""? Mar 03 22:37:51 What does it mean? Mar 03 22:38:00 03Laibsch 07org.oe.dev * r6132afbc... 10/ (3 files in 3 dirs): gnutls: drop unused directory gnutls-1.4.4 with 1 patch Mar 03 22:38:01 What is the intended meaning? Mar 03 22:38:01 I think it should be the first step to have a list of what builds. If its build it doesn't need a cleanup so badly. Mar 03 22:38:23 thesing: That is also the first thing I look at Mar 03 22:38:29 but RP is right that is not the end Mar 03 22:39:07 Laibsch: I think we're thinking different things since I'm thinking of it as when a human last looked over and built the recipe and pronounced it "sane" Mar 03 22:39:18 and recipes that noone uses but build unusable, broken binaries "successfully" are a waste Mar 03 22:39:37 Several problems exist here such as "what is sane"? Mar 03 22:39:48 RP: I am trying to understand what meaning *you* want to attach to it Mar 03 22:40:05 But I think the "somebody declares it sane" is problematic Mar 03 22:40:26 Laibsch: The criteria koen mentioned on list looked like a good start Mar 03 22:40:54 When I declare something as OK (I cannot find anything left to improve) has a totally different weight than when somebody "in the know" declares it sane Mar 03 22:41:05 Laibsch: We can have a list if need be such as "no mention of /usr/include, ${includedir} used instead" Mar 03 22:42:11 Laibsch: This list will grow over time, hence the date stamps as to when the QA check applied Mar 03 22:42:23 s/grow/change/ Mar 03 22:43:19 Things which are good practice now once weren't even possible (.inc files for example) Mar 03 22:43:47 OK Mar 03 22:43:59 I am not sure if I could always make the call Mar 03 22:44:10 But having some kind of checklist would certainly help Mar 03 22:44:19 Most of the things that koen mentions would be doable for me Mar 03 22:44:32 many things in the b) paragraph might be tough Mar 03 22:44:45 Laibsch: The thing is your best effort would massively clean up the metadata Mar 03 22:44:56 I would not know if a custom do_stage routine can just be replaced with autotools_stage_all, for example Mar 03 22:45:34 RP: but basically, we are looking for build problems (which IMHO is OK as a first step) Mar 03 22:45:41 Laibsch: If it just uses oe_runmake with the standard arguments the answer is 95% yes. If not, the answer is usually not Mar 03 22:46:07 it would be something I should rather not touch most of the time Mar 03 22:46:50 Laibsch: Even if you flagged a list of possible improvements up, that would be useful as it would mean other devs who can tackle those kind of things know where to concentrate their effort Mar 03 22:47:02 Hehe Mar 03 22:47:08 !oebug 2194 Mar 03 22:47:09 * * Bug 2194, Status: NEW, Created: 2007-05-01 05:03 Mar 03 22:47:10 * * : meta-bug: bugs waiting to be committed and fixed Mar 03 22:47:11 * * http://bugs.openembedded.org/show_bug.cgi?id=2194 Mar 03 22:47:16 There you go ;-) Mar 03 22:47:23 Laibsch: gah ;-) Mar 03 22:47:24 That was my take on that so far Mar 03 22:47:56 thesing: ping Mar 03 22:48:00 RP: I certainly agree the initiave is very good Mar 03 22:48:13 The number of pressures on my time is a problem in my case Mar 03 22:48:14 ant|work: I'm here. Mar 03 22:48:18 I wish I could do more... Mar 03 22:48:48 And even if it seems daunting, there is a Japanese (?) proverb "a journey of a thousand miles begins with the first step" Mar 03 22:49:15 Kaizen is continuous improvement with small steps which ultimately lead to Toyota-quality Mar 03 22:49:28 thesing: I've built initramfs-kexec-image (103k) and initramfs-bootmenu-image (790k), now I'm shrinking the kernel (actually at 930 kb)... Mar 03 22:49:44 Laibsch: I have set lots of small things in motion and am watching them snowball ;-) Mar 03 22:49:53 RP: The good thing is that a todo-list would make this something not for a single person to do (which is impossible) Mar 03 22:49:58 thesing: as you said it is a tough task with 1,2 mb... Mar 03 22:50:00 RP: Great Mar 03 22:50:09 RP: That is the right approach IMHO Mar 03 22:50:35 thesing: don't you think the busybox could be made smaller? Mar 03 22:50:53 ant|work: I got the collie kernel down to ca. 500K but it didn't have display and input. Mar 03 22:51:20 RP: BTW, I care about the Sharp ROM support. I read your mail on list. But I don't really understand it and hope you'll help with keeping things supported there. Mar 03 22:51:36 thesing: ok, I'll start to config from scratch a "barebone" one Mar 03 22:51:43 ant|work: I don't know. I never looked at it. I think Paul will switch the bootmenu image to klibc eventually. Mar 03 22:51:51 Laibsch: If things break I will do my best to help fix them, don't worry Mar 03 22:52:28 thesing: yes, and actually after the last patches I think the image has growth :-( Mar 03 22:53:20 ant|work: Paul already committed a workaround. Mar 03 22:53:22 thesing: I'll go home soon (hopefully) and check why Mar 03 22:54:12 its because it uses klibc-utils-fstype which was compiled against glibc in the past. Mar 03 22:54:27 now it uses klibc and so klibc ends up in the image. Mar 03 22:54:48 thesing: last question: is the issue of continuous kexec fixed now, isn't? Mar 03 22:55:13 I don't know. I never booted a bootmenu image. Mar 03 22:55:19 thesing: I guess was missing a "noinitrd" or smthg Mar 03 22:55:29 They are to big for my machine. Mar 03 22:57:40 go ibot Mar 03 22:57:40 * thesing notices thats its easier to kexec a full kernel over nfs to test a driver than loading and unloading the module. Mar 03 22:57:53 thesing *g* Mar 03 22:57:59 thesing: I hope they'll fit in c7x0, it would be nice to go straight to the menu Mar 03 22:58:18 * ant|work completely disabled network in defconfig Mar 03 22:58:49 * ant|work but leaved too much cruft :-) Mar 03 22:58:56 ant|work: you could use initramfs-kexec-image to kexec a kernel with bootmenu image Mar 03 22:59:11 Laibsch: What would you say was a good package to make a test build with for sharp rom support? Mar 03 22:59:16 thesing: yea, that's second option Mar 03 22:59:38 RP: Well, there is no particular package Mar 03 22:59:39 ant|work: If you have a minimal defconfig please post it on the ml. Mar 03 22:59:52 RP: Actually, quite many basic packages already break Mar 03 23:00:08 thesing: the initramfs-kexec was approx 103 kb, we have space for a boot-logo! Mar 03 23:00:10 Laibsch: Can you give me two or three that work? Mar 03 23:00:39 RP: http://tinyurl.com/3xvv33 Mar 03 23:00:45 ant|work: Yes I have one at my collie ;) Mar 03 23:00:49 Those are the non-working ones ;-) Mar 03 23:00:54 Let me climb onto my soap box here a moment, and bitch about the bitbake changes... Mar 03 23:01:01 thesing: :=) Mar 03 23:01:05 RP: I believe perl used to be broken, but is now fixed Mar 03 23:01:07 * XorA|gone sets fire to soapboxes Mar 03 23:01:27 RP: I think that is also a more complicated ones and thus I think might be more easy to break Mar 03 23:01:32 It really is frustrating that an almost completely static project that should just continue to build is taking me as much effort to keep building as a new project. Mar 03 23:01:50 If it builds now (I am testing) it might be a good, very sensitive test case Mar 03 23:02:11 mwester: With old versions or cutting edge ones? Mar 03 23:02:27 There is much "lip service" given to compatability, and how a major change to a core recipe or tool should have no effect on old stuff, but in fact, they get broken constantly. Mar 03 23:02:27 mwester: Maybe angstrom-stable is more suited for your needs? Mar 03 23:02:37 03woglinde2 07org.oe.dev * rc3b1a39c... 10/ (29 files in 6 dirs): Mar 03 23:02:37 simpad-linux-2.6.24: Fix building of the linux-kernel for 2.6.24 Mar 03 23:02:37 *fix collie-kexec.patch contains the same patch threetimes Mar 03 23:02:37 *move patches to packages/linux/linux/simpad Mar 03 23:02:37 *add modified defconfig under packages/linux/linux-2.6.24/simpad Mar 03 23:02:37 Unslung - 2.4 kernel, Mar 03 23:02:42 old, old, old. Mar 03 23:03:02 No need for anything new, in fact we go through effort to AVOID having new stuff bleed into it. Mar 03 23:03:03 :( Mar 03 23:03:12 * mwester gets off his soap box. Mar 03 23:03:13 mwester: Is there any common factor to the breakage? Mar 03 23:03:36 RP: the most frustrating ones are the ones I know little about -- toolchain stuff, and libc stuff. Mar 03 23:04:31 Many of the others I find and pin down to another dependency that needs tweaking, etc. I don't doubt that the dependencies are wrong, I just don't see why they should change the way they do for no apparent reason. Or at least reasons that I do not fathom. Mar 03 23:05:10 mwester: If any of the current changes I'm making break it, I do promise to try and fix it if I can reprodue it Mar 03 23:05:26 Anyway, I've just spend three hours fixing Unslung and regression-testing it to make sure that it still builds... time I was not able to spend on other things in OE. :( Mar 03 23:05:30 mwester: Can you give an example as I don't quite follow what you mean about dependencies Mar 03 23:06:19 mwester: I have seen your mail btw and I'm not ignoring it, I just want to push the rest of the changes, then worry about fixing it if its still broken Mar 03 23:06:50 libgcc_s.so.1 vanished from the rootfs after I blew away the entire tmp directory (which was what enabled the gcc-cross stuff to build again). Mar 03 23:07:45 ah, so a build from scratch was needed for the gcc-cross change? :/ Mar 03 23:07:46 I have no idea what pulled it in previously, so I don't know where the real dependency needs to be added -- I just made the rootfs depend on libgcc_s.so.1 !! Mar 03 23:08:13 Yeah, a build from scratch appears to have fixed it, but the notes on that commit seem to imply it shouldn't have been necessary. Mar 03 23:08:24 it shouldn't :( Mar 03 23:09:05 But I'm not pushing for a fix for my immediate problem right now; that's something I should continue to work on. Mar 03 23:09:40 FWIW, gcc packaging is a total shambles Mar 03 23:09:56 I think I just about understand it enough to rewrite it now Mar 03 23:09:56 I'm just trying to raise the level of awareness with the core OE team that there is such a thing as history, and like in an auto race, being aware of what's behind you is sometimes important if you wish to finish the race... Mar 03 23:10:08 * ant|work keeps some old buildtrees from the last weeks and the rootfs was populated differently on every build... Mar 03 23:10:35 So here's a thought. Mar 03 23:11:10 Can we have bitbake toss out an absolute record of what it did and what the dependencies were, in a machine-parsable form? Mar 03 23:11:33 mwester: At what level? Mar 03 23:11:40 mwester: bitbake -g isn't enough? Mar 03 23:12:30 Parsing that requires perl. Mar 03 23:13:01 mwester: Show me the data format you'd like it in then ;-) Mar 03 23:13:14 dotgraphs are a standard machine parsable format Mar 03 23:13:28 Depends on your purpose. Mar 03 23:13:28 bitbake can easily output it any way you want though Mar 03 23:13:41 This would not be for human consumption Mar 03 23:14:02 so -g should be ok? Mar 03 23:15:21 The idea is that I should be able to make a reference build, log all manner of information, and then at some later date or on another system, or both, I should be able to build the same item, and have it tell me where/how it differs -- what versions differ, what dependencies have changed, and I'd like even for it to tell me (if I wish to invest the CPU time) how staging differed as the build progressed and was compared to the reference. Mar 03 23:16:05 -g will tell you about versions and dependencies as far as bitbake knows them Mar 03 23:16:15 This would allow us to validate that a given environment can create the same build -- reproducability. That's something that we cannot do today -- which is odd, since the whole point of building your own toolchain and all is to guarantee that. Mar 03 23:16:21 the missing information would have to be gained from comparing the packages themselves Mar 03 23:16:36 staging will be possible once we have packaged staging Mar 03 23:17:21 mwester: We do have reproducability in that if you go to OE revision X and bitbake revision Y, you stand a good chance of getting the same output Mar 03 23:17:40 mwester: What we don't have is a good way to compare output from two builds Mar 03 23:17:55 RP: "stand a good chance" is the operative term. Mar 03 23:18:12 mwester: We've tried to cover all the variables like sources with the md5sum Mar 03 23:18:14 That is inadequate for non-hobbyist sort of use, IMO. Mar 03 23:18:24 md5sum is the least of our issues. Mar 03 23:18:40 mwester: where does that approach fail then? Mar 03 23:19:03 Making sure the sources are constant is trivial; the problem is the "butterfly effect" Mar 03 23:19:20 Consider Unslung -- nobody has changed it, or any of it's sources for months. Mar 03 23:19:25 It broke this weekend. Mar 03 23:19:33 yes, but OE changed Mar 03 23:19:39 Yes. Mar 03 23:19:48 That isn't about reproducibility then Mar 03 23:19:59 go back to an old revision of OE and it would probably work Mar 03 23:20:08 Let's not mince about with words. Mar 03 23:20:30 This is not about a static copy of OE on a machine in a lab with no updates; yes, anyone can do that. Mar 03 23:21:15 This is about you, for example, being able to change gcc, making the statement that it should affect no builds, and having a technique that we can use to verify that claim. Mar 03 23:21:33 mwester: Right, but this doesn't mean OE builds are not reprodubile. I understand your problem but its not about reproducability Mar 03 23:21:47 I guess that I do not speak your english then.\ Mar 03 23:21:57 I apologize for useing the work reproducability. Mar 03 23:22:01 I shall invent a new onel Mar 03 23:22:04 ! Mar 03 23:22:25 I think you know what I'm referring to. Mar 03 23:23:00 A quick check of my dictionary seems to say that my usage of the term is correct, but I shall defer and call it something else. Mar 03 23:23:38 So, we need a means to ensure that changes can be made and someone can confirm that indeed that change did not have impact where it was not supposed to, and if it did, help determine why. Mar 03 23:23:42 mwester: reproducible to me means "feed same input, get same output" Mar 03 23:24:04 I'm not argueing definitions, I'm arguing a solution to a problem. Mar 03 23:24:05 If OE changes, the input has clearly changed Mar 03 23:24:21 Anyhow, back to the problem Mar 03 23:24:23 the problem is that OE *does* change Mar 03 23:24:50 Yes Mar 03 23:25:05 mwester: How do you define what should and shouldn't change though? Ensure built objects don't change? Ensure dependencies are identical? Mar 03 23:25:24 These are exaclty the quesitons that need to be asked and figured out. Mar 03 23:25:41 I think the answer differs, so the tests applied may need to be different. Mar 03 23:26:04 For example, a packaging change for the toolchain should result in identical binaries. Mar 03 23:26:37 On the other hand, a patch to the compiler may result in different binaries, presumably for the better. Mar 03 23:27:11 The issue is how you compare two OE builds Mar 03 23:27:36 You can compare fileds in the output packages, bitbake dependency graphs and all kinds of other things Mar 03 23:27:45 but someone needs to write the infrastructure to do that Mar 03 23:27:55 And comparing the output from the -g option does not address the issue, and is inadequate in the end, but perhaps that's a start. Mar 03 23:28:12 At least it might be useful for diagnostic purposes... Mar 03 23:28:21 It doesn't give you the holy grail, it does give you something Mar 03 23:28:35 As Laibsch said earlier, small steps, one at a time Mar 03 23:29:35 We're going through similar teething problems at work, and that's difficult enough for a handful of projects with various toolchains... although I think it's a disparate issue... comparing dependency trees and output objects doesn't really tell you how/why something fails.. it might point the finger at something, but it seems to me like it's missing the point - you don't necessarily want no behavioural change from bitbake and the metadata changing, but you do want a w Mar 03 23:29:52 mwester: Nobody is going to land a solution on your lap which does what you need, all we can do it pool resources and ideas and move forward one step at a time. Adding a new class which logged a build might be a start. Part of that might be dumping dependency data... Mar 03 23:30:21 mwester: That would compliment insane, sanity and the various other QA ssystems we're putting into place Mar 03 23:30:44 I'm not asking for anyone to write me a solution. I'm really just poking at a painful (for me) problem to see if anyone else thought this was a problem, and if anyone else agrees that it might be worthwhile addressing it. Mar 03 23:31:28 mwester: I understand the problem and I do feel bad that "we" cause you these issues :( Mar 03 23:32:26 mwester: That isn't the intent FWIW. I'm more than aware that people use OE for a ton of different things and I do try to keep them in mind when things change Mar 03 23:33:39 * cyrilRomain understand mwester frustrations, especially when a change can break or make a bug appear at many different 'stage' (toolchain, pkgconfig, libtool, ...), which require a good knowledge on many part, and this is especially painfull to see a weird issue dissappearing when we give up rebuilding from scratch Mar 03 23:34:01 * ant|work thinks 'rm -rf /tmp' should be a new bitbake task... Mar 03 23:34:15 On the other hand, OE.dev is a living, breathing, evolving entity and we don't want to stop that happening since I think there are areas we need to make progress in... Mar 03 23:34:26 mwester: but QA and autobuilds are there to help up Mar 03 23:34:38 You mentioned staging earlier and that is one of our biggest QA nightmares :/ Mar 03 23:34:49 I'm honestly not trying to lay blame on anyone or on any specific project or process. I am of the strong opinion that the current culture itself around OE is very "leading edge" and forward-looking, and that this is why things are the way they are. Mar 03 23:34:53 hence packaged staging but that means change Mar 03 23:36:29 nite Mar 03 23:37:18 mwester: OE.dev was meant to be leading edge by definition in a way or at least that is the way I see it Mar 03 23:37:24 woglinde: night Mar 03 23:37:35 night all Mar 03 23:37:38 'night woglinde Mar 03 23:38:15 night Mar 03 23:38:57 RP: Agreed. But perhaps there's just too much stuff in OE.dev. I keep trying to understand why it is that we cannot separate three things: native packages used only because we don't trust what might be installed (or not) on the host, toolchain pacakges, and the actual sources the typical user is working with. Mar 03 23:39:42 mwester: What benefit does that give? Mar 03 23:40:07 It allows controlled acceptance of sweeping changes. Mar 03 23:40:53 mwester: I think the problem is that OE.dev is being torn in too many directions. It does an incredible job of managing to mostly satifsy everyone too Mar 03 23:42:05 Agreed. Those words are a text-book example of the signal that it is time for a project to branch. Mar 03 23:42:27 I understand that there is a culture against branching, though. Mar 03 23:42:53 I don't think anyone is against it, we just need people to stand up and volunteer to maintain them Mar 03 23:43:18 and maintaining an OE branch is not a light undertaking Mar 03 23:43:26 * RP looks at poky Mar 03 23:43:51 As with all branching activities, the problem really is who pays the price. Mar 03 23:44:09 As it is right now, those wishing stability pay the price Mar 03 23:44:44 If branching is done in the common fashion, the price is paid in terms of features being duplicated, or not being merged back at all. Mar 03 23:45:37 Well, fwiw after this round of changes to OE.dev, I don't see anymore fundamental changes looming so its likely a stable period will exist after the instability the current round of changes will no doubt introduce Mar 03 23:46:07 ;) Can I quote you on that? Mar 03 23:46:44 mwester: I didn't specify time units ;-) Mar 03 23:47:16 Ok, I shall take away from this discussion that it might be worth the effort to attempt to create some form of audit mechanism. Mar 03 23:47:29 but seriously, from where I sit, I can't see any other fundamental changes coming Mar 03 23:48:31 These current ones have been known about for probably 6 months and the changes have been carefully tested and planned, ok only on a subset of OE metadata but that is better than changing OE.dev directly Mar 03 23:49:19 mwester: Keep in mind I took the gamble of removing the major problems in poky which was quite a personal gamble ;-) Mar 03 23:49:46 Well, I've still synced up and built a reference build for all the OE things I work with, in anticipation of the change announced in the email from last week... I expect you too did some sort of comparison with poky to make sure it was all working. Mar 03 23:49:54 mwester: Would certainly help for debugging, I'd imagine Mar 03 23:51:16 mwester: Yes, comparisions were made in various ways but things could be improved and made easier Mar 03 23:51:32 03mpanczyk 07org.oe.dev * raaab4fbc... 10/ (3 files in 3 dirs): at76c503: add firmware Mar 03 23:51:37 03koen 07org.oe.dev * r7712d917... 10/ (1 classes/testlab.bbclass): Mar 03 23:51:37 testlab bbclass: add class that dumps a bunch of statistical data from your images, usefull for people doing regression testing Mar 03 23:51:37 details at: Mar 03 23:51:37 * http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again Mar 03 23:51:37 * http://dominion.thruhere.net/koen/cms/package-relations-inside-images Mar 03 23:52:03 NAbyss: I expect so - I know that ClearCase is widely depised by many developers, but if you've ever had the luxury of having the complete set of "configuration records" from two builds to compare, well, it's a fabulous way to answer the questions about what changed, and why it's different... Mar 03 23:52:15 mwester: That commit looks interesting :) Mar 03 23:52:34 mwester: It's what we use at work.. we keep everything from toolchain to build output in it.. works rather well, especially MVFS Mar 03 23:53:13 RP: perl builds for Sharp ROM currently Mar 03 23:53:58 Laibsch: ok, I will endeavor to setup a 2.9.5.3 toolchain and test that with the sysroot changes applied and make sure it works before I commit it Mar 03 23:54:00 RP: it looks very interesting. Mar 03 23:56:59 RP: http://blog.leggewie.org/?p=11 Mar 04 00:06:12 Laibsch: thanks, I should really boot up my old desktop since it has the sharp toolchain on it Mar 04 00:29:00 night all Mar 04 00:30:55 night all Mar 04 00:51:10 Laibsch: I'm surprised sharprom-compat works at all. It seems full of circular dependencies? Mar 04 01:30:05 * * OE Bug has been RESOLVED by ynezz(AT)true.cz Mar 04 01:30:07 * * chinook-compat - GCC/libc version mismatch Mar 04 01:30:09 * * http://bugs.openembedded.org/show_bug.cgi?id= Mar 04 02:02:45 ljp: hey Mar 04 02:06:20 ljp: http://pokylinux.org/screencasts/poky-anjuta-screencast.html seen this? Mar 04 02:43:27 zecke: no i havent/ looks cool Mar 04 02:47:07 will send this to qtopia-interest :) Mar 04 02:47:56 ljp: qtopia-interest is kind of disappointing if I send the same things to qt4-feedback thiago or simon would apply them right away :) Mar 04 02:48:39 they are not under the same pressure/schedule as we are Mar 04 02:53:03 plus, we produce differnet types of products Mar 04 02:55:05 ljp: not accepting patches will turn down any contributor :) Mar 04 02:55:07 bbl Mar 04 03:01:26 no one has turned down patches. Mar 04 03:52:49 ljp: sorry, I'm in the office now Mar 04 03:53:54 ljp: Qt has 4000-5000 thousand customers, delivering a good major and minor release is pure pressure. It is the question how to handle it and how to handle resources Mar 04 03:54:18 ljp: not taking any input means you inbreed, which is known to cause issues :) Mar 04 04:03:46 wow, software inbreeding... thats an impressive concept Mar 04 04:04:16 i guess microsoft is the best example Mar 04 04:07:55 Apple is another. Mar 04 04:19:46 who says we dont take input? Mar 04 04:20:10 ljp: hehe Mar 04 04:21:23 ljp: see the analog clock patch, sent on the 20th of february, four lines, no reply, obvious fix... Mar 04 04:21:28 => no input Mar 04 04:21:35 so Mar 04 04:24:14 does it break binary compatibility? Mar 04 04:27:15 ljp: reimplementing a virtual? can it break existing apps? no, if some one reimplements resizeEvent and calls QFrame::resizeEvent he will continue to get the broken behaviour... anyway Mar 04 04:27:31 ljp: http://labs.trolltech.com/blogs/2008/03/03/many-new-qt-releases/ this is input<->output :) Mar 04 04:29:10 03mwester 07org.oe.dev * rb5b172da... 10/ (1 packages/images/unslung-image.bb): Mar 04 04:29:10 unslung-image.bb: add libgcc to the dependency list, as it's no longer being Mar 04 04:29:10 pulled in automagically. Mar 04 04:43:09 I am looking for advice on how to conditionally fetch code from svn at a certain revision if a variable is defined, or from HEAD otherwise Mar 04 08:18:32 morning Mar 04 08:38:44 re Mar 04 08:38:48 it's too damn early :P Mar 04 08:42:31 bonjour Mar 04 08:43:48 ...what is the best way to find out why a preferred version of some package is marked as not available, allthough the .bb file is there and look ok? Mar 04 08:44:05 some dependency missing? but which one? Mar 04 08:55:15 shouldn't openttd_0.4.0.1 be removed if the source for that version is no longer available ? Mar 04 08:56:54 which graphviz viewer do you use ? Mar 04 08:59:26 Genesis: vim Mar 04 08:59:42 some extention ? Mar 04 09:00:32 zecke help me out here :) what's the best way to find out why a preferred version of a package is not taken? :) I tried several things yesterday but did not get any further Mar 04 09:01:25 Jin^eLD: bbread (now bitbake -e) on the bb file and check the depends Mar 04 09:01:49 thanks! Mar 04 09:01:50 Jin^eLD: is it buildable when you use the right name? mostly missing dependency or wrong preferred_version Mar 04 09:02:10 Jin^eLD: also bitbake shell, if it works, can be nice to peek into your provider :) Mar 04 09:02:11 you mean when I use "bitbake -b package.bb" or just "bitbake packagename" ? Mar 04 09:02:21 Jin^eLD: bitbake packagename Mar 04 09:02:35 thats interesting Mar 04 09:02:36 ERROR: Nothing PROVIDES 'gcc-cross-initial_csl-arm-2007q3.bb' (but '[]' DEPENDS on or otherwise requires it) Mar 04 09:04:09 without .bb :) Mar 04 09:04:21 oh Mar 04 09:04:26 pn-pv should work Mar 04 09:04:29 pn as well Mar 04 09:04:54 same message Mar 04 09:05:14 pn will probably pick a different version Mar 04 09:06:26 yeah, pn spits out a lot of info but I guess it is taking the other versions, not the one that I am looking for Mar 04 09:06:32 pn-pv gives the same error Mar 04 09:06:40 I must be missing something Mar 04 09:06:57 Check the dep tree? Mar 04 09:07:58 Jin^eLD: what is the name of the .bb? Mar 04 09:08:23 gcc-cross-initial_csl-arm-2007q3.bb Mar 04 09:08:45 basically I took the exiting csl recipes from 2005 and updated them to 2007 versions which now use gcc 4.2.1 Mar 04 09:09:27 NAbyss: bitbake -g gcc-cross-initial_csl-arm-2007q3 tells me that nothing is actually providing my stuff which confuses me... so not sure how to go ahead with the deptree thing Mar 04 09:09:47 Jin^eLD: bitbake gcc-cross-initial will not built it, okay, is -vvv saying something about excluding it? Mar 04 09:09:58 Jin^eLD: is the file in your BBFILES? Mar 04 09:10:23 Jin^eLD: use the shell, parse, type help, check all providers of gcc-cross-initiaƶ Mar 04 09:10:24 zecke: the file as such is being parsed and cached Mar 04 09:10:56 Jin^eLD: bitbake gcc-cross-initial-csl-arm2007q3 brings up the error with .bb? Mar 04 09:10:57 ok let me try that... -vvv? I tried -DDD and could not find any exclusions, it was just saying that preferred provider is not available and picking a different one Mar 04 09:11:26 ok one sec, too many steps queued in my pipeline :) Mar 04 09:11:45 morning all Mar 04 09:11:56 bitbake gcc-cross-initial-csl-arm2007q3 tells me: ERROR: Nothing PROVIDES 'gcc-cross-initial-csl-arm2007q3' (but '[]' DEPENDS on or otherwise requires it) Mar 04 09:11:59 hey RP Mar 04 09:12:10 I will try the shell now Mar 04 09:12:27 morning Mar 04 09:12:36 Jin^eLD: bitbake -e -b your.bb what is the PN, PV? Mar 04 09:13:13 you mean -e and -b at the same time? Mar 04 09:13:50 I think there is a clue now Mar 04 09:13:52 NOTE: package gcc-cross-initial-4.2.1+csl-arm-2007q3: started Mar 04 09:14:11 probably one of the gcc .bb's that is included is resetting PV Mar 04 09:14:20 so it does not match my preferred provider requirement Mar 04 09:14:22 doh! Mar 04 09:14:37 that must be it.. zecke - thanks a lot! I must have been blind the whole time :) Mar 04 09:14:44 welcome to the mess that are the gcc .bb files :( Mar 04 09:15:11 * zecke continues having fun with Qtopia... Mar 04 09:15:25 * RP plays with gcc 2.95.3 :/ Mar 04 09:16:01 yo richard :) Mar 04 09:17:35 * Genesis plays with kboot & grubimage.bbclass Mar 04 09:17:59 RP: yeah.. lots of includes and requires etc ,etc. :) Mar 04 09:18:17 2.95?? antique stuff :> Mar 04 09:21:18 http://www.moblin.org/projects/projects_image-creator.php Mar 04 09:21:52 that's a bit what i wanted to do Mar 04 09:22:53 Jin^eLD: antique? proven! stable not that crap of... just kidding :) Mar 04 09:23:01 :))) Mar 04 09:23:09 I assume same goes for kernel 2.4 ;) Mar 04 09:23:59 I recently got some toolchain from a vendor, they are using arm9 stuff without any fancy stuff or whatever - still on some older 3.x Mar 04 09:24:17 and I think even oabi Mar 04 09:24:25 they "fear" to change Mar 04 09:26:34 Jin^eLD: It is actually quite a scary move to make, particularly without something like OE to rebuild everything Mar 04 09:27:52 RP: well.. yes.. but if you know OE it's one day of work or so, ARM9 is very well supported Mar 04 09:28:17 well, maybe their problem is the "not knowing OE" part :> Mar 04 09:28:22 Jin^eLD: Does the vendor know OE? Mar 04 09:28:25 right :) Mar 04 09:28:27 :) Mar 04 09:28:58 so far I managed to move 2 companies to OE :> if I succeed with the uclinux thing there will probably be a 3rd one Mar 04 09:29:31 Jin^eLD: uclinux is pretty exciting, you are the first :) Mar 04 09:29:48 zecke: I don't know if it is, actually I do not really like this extremely minimalistic stuff Mar 04 09:30:21 especially the target platform that I will be using is arm9, and they still want uclinux because they say the performance is much better Mar 04 09:30:41 if they'd be happy with the "regular" thing I'd make them a uclibc based rootfs in one day :P Mar 04 09:30:48 but on the other hand - it would be good to have uclinux in OE Mar 04 09:30:49 it is even faster if you don't have a os in the way :) Mar 04 09:31:17 because I would really like to just select a distro/machine and start a build Mar 04 09:31:48 actually that's where you learn to appreciate OE - when you try to use something that's not supported and spend a shitload of time looking for useful info Mar 04 09:31:55 find pages that are like 6-7 years old Mar 04 09:32:02 broken links, antique toolchains Mar 04 09:32:04 doh.. Mar 04 09:32:29 uclinux sureley did not make me happy :) Mar 04 09:33:06 but it's not looking too bad, Koen gave me some pointers in regard to the bfin work that he started Mar 04 09:33:21 and with the help of you guys things are slowly progressing :> Mar 04 09:43:04 morning Mar 04 09:44:07 Jin^eLD: gcc 295 supported arm9? Mar 04 09:49:22 hi, all! Mar 04 09:50:16 how should I propose angstrom 2007.12 change? (backport from oe-dev is needed)? Mar 04 09:50:42 look into angstrom-devel archives Mar 04 09:56:41 good morning all Mar 04 10:12:45 morning Mar 04 10:13:22 If You need help, i'm interested in uclunux too (for oteher arch) i can help u Mar 04 10:16:37 methril: cool, thanks Mar 04 10:16:46 hrw: no idea? Mar 04 10:17:24 methril: what arch are you working with? Mar 04 10:17:48 in work arm920t, in my spare time mips Mar 04 10:18:31 so I guess you're interested in uclinux for those two? Mar 04 10:18:51 no, only for the mips Mar 04 10:19:33 you are using an arm9 with ucLinux, as i read Mar 04 10:19:45 yes, my task is to get arm9 running with uclinux Mar 04 10:20:09 but including ucLinux into a bbfile it's a start point for both :) Mar 04 10:20:16 :) Mar 04 10:20:27 so far I was adding another TARGET_OS Mar 04 10:20:41 nice :) Mar 04 10:20:43 that required some additional tweaks here and there Mar 04 10:20:55 yes, some patches Mar 04 10:21:19 and those tokens need to be figured out, I am using uclinuxeabi but for bfin and probably for mips you will probably need just uclinux Mar 04 10:21:52 I figured that it mostly depends on the toolchain that is being used Mar 04 10:23:04 it's my "first" attempt with OE, then i'd like to see your bbfiles as soon as you have them Mar 04 10:23:35 once I get something that actually works and looks usable I will add patches to the bugtracker Mar 04 10:23:45 k Mar 04 10:23:53 I also posted some questions on the ML Mar 04 10:23:57 thanks Mar 04 10:24:11 ops!! i forgot to susbscribe to the mailing list :) Mar 04 10:24:16 i'm going to do it now Mar 04 10:25:03 :) Mar 04 10:32:52 hmm.... cannot be right. Mar 04 10:33:24 when building gcc-cross-sdk-4.1.2-r11, it has -isystem /usr/local/angstrom/..... as argument to gcc. Mar 04 10:33:32 esben: read the ml :) Mar 04 10:33:46 but /usr/local is interesting Mar 04 10:33:46 zecke: could you be more precise? Mar 04 10:34:07 ml = mailinglist Mar 04 10:34:24 I know, but what mail on the list? Mar 04 10:34:37 esben: having gcc in its content? sysroot? Mar 04 10:34:46 Yes, I am aware of sysroot. Mar 04 10:35:13 but, gcc-cross-sdk is supposed to be built for installing into /usr/local/angstrom/... Mar 04 10:35:27 esben: and? Mar 04 10:35:32 so there is a chicken-and-egg problem in requiring toolchain to be in /usr/local Mar 04 10:35:53 esben: does it fail? is that pedantic that it might pick up the wrong header? Mar 04 10:35:57 yes, it fails Mar 04 10:36:13 esben: and it fails because of the -isystem? what makes you think that? Mar 04 10:36:16 it fails to find standard includes. Mar 04 10:36:32 esben: where does it search for them (strace) Mar 04 10:36:39 it fails because it does not have an include search path where it can find stdio.h, stdlib.h and so on. Mar 04 10:37:16 the -isystem does not break anything (as my /usr/local/angstrom/ is empty), but it is wrong to have it there for building gcc-cross-sdk AFAICS Mar 04 10:37:49 esben: why? from what I assume stdio.o is coming from the C library you build your gcc against Mar 04 10:38:00 esben: it might as well be in /usr/local/angstrom... Mar 04 10:38:40 zecke: /usr/local/angstrom/... is the target for external-toolchain, which is gcc-cross-sdk + libs. Mar 04 10:39:09 when building gcc-cross-sdk it would therefore seem wrong to assume that anything is there. Mar 04 10:40:44 it must be possible to build gcc-cross-sdk without having an oe built external-toolchain. Mar 04 10:41:41 and therefore, it would make sense to have it not use it, even if it is there, as it could make the resulting toolchain differ depending on the precense of a previous oe built toolchain on the build system. Mar 04 10:41:50 esben: I didn't build gcc-cross-sdk recently Mar 04 10:41:58 I guess not ;-) Mar 04 10:42:30 esben: but there is a C library, otherwise newlib would be used by gcc... Mar 04 10:42:45 I would like to refactor the gcc recipes to not have the gcc-cross-sdk recipe derive from the other gcc recipes. Mar 04 10:43:25 * zecke starts a meta-toolchain build Mar 04 10:43:41 esben: I think your error is not with the -isystem, but something else :) Mar 04 10:44:02 zecke: I think so as well, but -isystem still should not be there. Mar 04 10:44:13 gcc-cross-sdk should not depend on itself. Mar 04 10:44:31 esben: stdlib.h is a C library header, gcc is a compiler... Mar 04 10:44:51 esben: it is not bootstrapping itself, in case it is bootstrapping itself, it is using newlib (another lib c) Mar 04 10:45:12 yes, but /usr/local/angstrom is coming from meta-toolchain which is gcc-cross-sdk and glibc Mar 04 10:45:59 esben: yes it is the --prefix, I don't doubt that. it adds it to the include path, cool, but that is not the issue Mar 04 10:46:02 or the root cause Mar 04 10:48:33 I guess the problem is that glibc headers are put in staging, and gcc-cross-sdk is looking in /usr/local/angstrom instead of staging. Mar 04 10:53:11 hrw: ping Mar 04 10:53:16 pong Mar 04 10:53:32 hrw: do you happen to have a barebone defconfig-c7x0? Mar 04 10:53:53 moment Mar 04 10:53:55 acyually I',m around 930 kb :-( Mar 04 10:54:31 hi Mar 04 10:54:39 ant|work: http://blog.haerwu.biz/download/ - look at config-* files Mar 04 10:54:41 hi rschuster Mar 04 10:54:50 hrw: thx Mar 04 10:55:04 if I want a *-native package use the same patches as its corresponding non-native recipe I override FILESDIR, right? Mar 04 10:55:14 ant|work: or waut a oment - I have few patches too Mar 04 10:55:50 hrw: the initrd-bootmenu-image is actually >780kb (uclibc)... Mar 04 10:56:06 ant|work: look in download/zaurus/ Mar 04 10:57:18 hrw: I think it was 330 kb before ?? busybox got somehow inflated fear... Mar 04 10:57:46 ant|work: no idea - never built it Mar 04 10:58:02 esben: you miss the 'only' in your conclusion :) Mar 04 10:58:06 lrg: do you have among your product offerings a DAC with internal tone control that will run from a single +3.3V supply? Mar 04 10:58:07 whereby the initramfs-kexec-image is around 100kb Mar 04 10:58:36 hrw: s/initrd/initramfs/ Mar 04 10:59:49 zecke: no, I don't think so ;-) **** ENDING LOGGING AT Tue Mar 04 10:59:57 2008