**** BEGIN LOGGING AT Mon May 24 02:59:57 2010 May 24 03:37:47 03Chris Larson  07org.openembedded.dev * r9e028bae96 10openembedded.git/classes/amend.bbclass: (log message trimmed) May 24 03:37:47 amend.bbclass: load *all* available amend.inc files in FILESPATH, not the first May 24 03:37:47 While this deviates from ordinary BBPATH/FILESPATH behavior by bitbake and May 24 03:37:47 OpenEmbedded, amend.inc is a special case. It's highly unintuitive for May 24 03:37:47 someone to create, say, files/busybox/amend.inc relative to TOPDIR, with May 24 03:37:47 ${TOPDIR}/files in FILESPATHBASE, and suddenly things break, because that May 24 03:37:48 amend.inc overrides one in an overlay. May 24 03:50:53 03Chris Larson  07org.openembedded.dev * r541b7473f5 10openembedded.git/conf/bitbake.conf: May 24 03:50:53 bitbake.conf: add ${datadir}/gdb/autoload to the default paths included in ${PN}-dbg May 24 03:50:53 Some libraries provide gdb autoload script as a debugging aid. May 24 03:50:53 Signed-off-by: Chris Larson May 24 03:50:55 03Chris Larson  07org.openembedded.dev * r1a2a620b19 10openembedded.git/lib/oe/patch.py: May 24 03:50:55 oe.patch: kill long standing annoying messages from the non-quilt patch application May 24 03:50:55 Signed-off-by: Chris Larson May 24 03:50:55 03Chris Larson  07org.openembedded.dev * r4c508c916a 10openembedded.git/classes/autotools.bbclass: May 24 03:50:55 autotools.bbclass: drop 'cfgcmd' and 'Running ..' output May 24 03:50:55 Per discussion with Enrico Scholz, there are better ways to debug problems May 24 03:50:56 than this, so drop it, making it more consistent with oe_runmake and ensuring May 24 03:50:56 we don't see problems with spaces in arguments. May 24 03:50:57 Signed-off-by: Chris Larson May 24 07:00:45 mwester: I can take a look in the morning May 24 07:41:50 03Koen Kooi  07org.openembedded.dev * r7432971c5b 10openembedded.git/recipes/u-boot/u-boot-mkimage_1.3.2.bb: u-boot-mkimage: fix target build May 24 07:45:56 morning May 24 07:46:43 hrw, moin May 24 07:55:39 there's no telnetd in oe ? May 24 08:08:24 is there any alternative to dropbear? May 24 08:13:21 dcordes: openssh? May 24 08:13:32 dcordes: and you can enable telnetd in busybox but what for? May 24 08:13:52 !oebug 5435 May 24 08:13:54 * * Bug 5435, Status: UNCONFIRMED, Created: 2010-05-19 14:26 May 24 08:13:55 * * lukas(AT)htc-linux.org: machine htcleo: gcc version etc. May 24 08:13:56 * * http://bugs.openembedded.org/show_bug.cgi?id=5435 May 24 08:17:12 khem: I updated the bug about binutils/nm wrong installation path, thank u 4 looking into this May 24 08:36:14 good morning May 24 09:33:52 I set May 24 09:33:53 DISTRO_SSH_DAEMON ?= "openssh" May 24 09:34:01 in task-base.bb May 24 09:34:20 console-image will still install dropbear. how can I install openssh instead? May 24 09:37:09 rebuild task-base? May 24 09:54:36 hrw, that worked. thanks May 24 10:11:01 ~praise kergoth for 1a2a620b19398a80b6f3286c7dc8dd3161f8f01f May 24 10:11:02 All hail kergoth for 1a2a620b19398a80b6f3286c7dc8dd3161f8f01f! May 24 13:09:44 I'm seeing a lot of issues like: opkg_conf.c:230: warning: implicit declaration of function 'regexec' May 24 13:10:19 with beagleboard builds. armv5te builds seem fine May 24 16:27:57 hi at all, i have a little question, is there a detailed guide on how to compile a distro, which is not written for oe? May 24 16:52:08 03Koen Kooi  07org.openembedded.dev * r69e374d447 10openembedded.git/contrib/angstrom/personal-feed.sh: angstrom personal feed script: s/staging/sysroots/ May 24 17:23:30 good morning all May 24 17:23:59 cbrake: hmmm interesting May 24 17:25:47 khem: yeah, seems to be something with regex in libc, but have not tracked it down yet May 24 17:25:56 khem: also ran into issues building eject May 24 17:29:11 cbrake: is it for target opkg package ? May 24 17:29:23 eject what issues did you run into May 24 17:35:42 khem: http://pastebin.com/yZ7Jz7Va May 24 17:37:09 isn't this issue related to tcl? seen that in last few tcl commits May 24 17:38:03 http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=6a3e08e32d190eaea554d27023a02a78acbb1656 and later there is Koen's commit (possible fix) May 24 17:41:26 okay, think i have this working.. need to throw together unit test recipes though May 24 17:41:35 changing do_patch to fix something that's bugged me for years May 24 17:41:39 JaMa: cbrake seems likely May 24 17:41:43 deprecating pnum in favor of letting you set the -p value with patch= May 24 17:41:46 kergoth: whats that May 24 17:41:48 so patch=0 is pnum=0;patch=1 May 24 17:42:11 also, if you don't set patch=, it'll assume patch based on extension, .diff/.patch May 24 17:42:14 unless you set nopatch= May 24 17:42:19 kergoth: hmmm May 24 17:42:22 so the common case, pnum=1, .patch/.diff, is automatmic May 24 17:42:25 no need to set any params May 24 17:42:34 heh May 24 17:42:34 thoughts? May 24 17:42:46 i'll fix all the recipes in the repo, of course May 24 17:42:48 file:// what else can it be ? May 24 17:43:02 it can be a patch or it can be a normal file May 24 17:43:03 patches can be fetched, then applied, just fine May 24 17:43:15 not sure what you mean. May 24 17:43:24 again, if the extension is .patch/.diff, whether its local or not, it'll assume patch May 24 17:43:32 hi everyone May 24 17:43:54 hey May 24 17:44:03 :) May 24 17:44:25 kergoth: personally I like it being explicit like where patch states the type and then pnum states the striplevel May 24 17:44:36 but thats may be because I am used to it May 24 17:45:30 kergoth: why I was asking for other types in SRC_URI was to find if we have common syntax May 24 17:45:46 we do. uri type has no effect on do_patch May 24 17:45:52 it uses bb.fetch's localpath May 24 17:46:17 well, we could always ditch the automatic based on extension part May 24 17:46:29 but i do think consolidating pnum/patch and adding nopatch is cleaner May 24 17:46:34 we've had people ask in here many times May 24 17:46:41 hmm ok I agree it will clean the recipes May 24 17:46:42 "i set patch=0, but it wont apply!" May 24 17:47:00 "okay, set pnum=0;patch=1" May 24 17:47:02 heh May 24 17:47:07 SRC_URI += "file://a.patch" May 24 17:48:02 explicit is better than implicit, i agree, but on the flip side, making the most common cases easier improves useability, so where to draw the line :) May 24 17:48:19 yeah its hard call May 24 17:48:49 well, i'll obviously mail it to the list to get more comments, and can split up the two pieces of it, the param changes vs the automatic by extension bit May 24 17:49:05 just one of those things thats bugged me for *years* and i just never did it for some reason May 24 17:49:10 I spent half and hour on a patch generation because it wouldnt apply no matter what I did and then I figured out the patch must be relative to a subdir inside src of the package May 24 17:49:11 even though it took all of 10 minutes to do May 24 17:49:18 ugh, i hate those May 24 17:49:45 I would love bitbake/quilt to detect this :) May 24 17:49:52 i wonder how common that is, maybe do_patch should have a subdir param May 24 17:50:17 and oh god, i need to rewrite lib/oe/patch.py.. i dunno what the fuck i was thinking May 24 17:50:28 i was even more of an OOP noob than i am now, i think :) May 24 17:50:33 I was trying my first bitbake recipe following http://www.xora.org.uk/2010/01/22/openembeddedangstom-new-package-workflow-eggdbus/ and in the first step where the package would be downloaded there the fetch tried http://build.shr-project.org/sources/ before trying the location I mentioned. Is this a standard behavior? May 24 17:50:50 JaMa: yes, that looks correct -- trying to rebuild tcl/glibc ... May 24 17:50:58 shazkhan: see MIRRORS and PREMIRRORS variables May 24 17:51:08 shazkhan: PREMIRRORS are attempted before the recipe uri, MIRRORS after May 24 17:51:19 shazkhan: likely your distro is setting it May 24 17:52:03 kergoth: Got it ... yes I am using shr so there must be some setting in its .conf May 24 17:52:20 Is OE capable to build Android? May 24 17:53:06 oh no I've seen this coming May 24 17:53:20 android>oe May 24 17:53:29 ? May 24 17:54:17 dcordes: u mean some parts of Android can be built with oe but not all? May 24 17:55:33 shazkhan, not at all and I suspect this is not going to happen May 24 17:56:08 dcordes: I would like to ask why although I don't like Android! May 24 17:58:26 JaMa and kergoth: the utils and libs I am dealing with are interdependent so can I make one directory in recipe and then put them into sub-directories or should I just put them in separate directories under recipes? Is there any concept of meta package or something? May 24 18:03:29 shazkhan: yes, there was a mailing list thread about someone starting an OE overlay to build android stuff. I don't know the status, but see the openembedded-devel mailing list archives May 24 18:03:37 i still have the mail in my inbox because I wanted to check it out May 24 18:03:57 dcordes: OE is a build tool. there's no reason it has to build a regular linux kernel, or even a regular linux distribution, necessarily May 24 18:05:43 Is the OE recipe directory structure flat? May 24 18:06:06 dcordes: though, it could certainly be more of a non-oe, bitbake based thing.. it really depends on how much of the oe metadata they'd be able to reuse, classes, etc May 24 18:06:31 shazkhan: recipes/*/*.bb are normally the recipes used. there have been, in the past, recipes in subdirs, but those were things we didn't want built -- recipes/obsolete, recipes/nonworking May 24 18:06:33 shazkhan: see usually used BBFILES := "/OE/dev/recipes/*/*.bb" May 24 18:07:27 shazkhan: naturally, your own overlays wouldn't have to be that way, it's just convention, not requirement May 24 18:07:54 kergoth, he asked if parts of android could be built by oe. I was taking that he means the official metadata May 24 18:08:05 kergoth: I will also look for the thread because some of my friends deal with Android and I think OE is more universal to use and get used to. May 24 18:08:47 dcordes: well, just because it's being developed independently doesn't mean it won't eventually be merged. May 24 18:09:02 i assumed he'd want to keep an eye on such develpoments May 24 18:09:05 developments, even May 24 18:09:43 anyway.. May 24 18:09:48 dcordes: That was based on android>oe! My first question was can we build android with oe. Not sure what you mean by the meta data being official or not ... May 24 18:10:16 shazkhan: many people have their own repositories of recipes outside of the main OE repo, for their own work, or stuff that's not ready for primetime, or any nujmber of things May 24 18:10:41 these may be clones of the oe repository, or independent chunks to add to oe, which are known as overlays or layers or collections, depending on who you talk to May 24 18:11:07 kergoth, sorry... it's all good. May 24 18:11:21 kergoth: I guess I'll get this after some practice ;p May 24 18:12:43 On directory structure I tried recipe/abc/xyz/xyz.bb but bb didn't pick it ... May 24 18:13:03 see your BBFILES, likely in your local.conf May 24 18:13:17 it controls how bitbake finds recipes, unless you're using bitbake master with the bblayers support May 24 18:13:22 personally I think it would be nearly as crazy as posting some fork of org.oe.dev that builds wince. but that's my opinion. May 24 18:13:34 I don't see anything wrong with that. May 24 18:13:40 I've built avr toolchains out of OE in the past May 24 18:13:55 when we started the project, we intended there to be no limitations about target os or architecture, it was one of the design goals May 24 18:14:23 speaking of which.. makes me have a less destructive thought. we should add haret in oe May 24 18:14:27 you'd pretty much ignore 90% of the metadata for something like that, but.. May 24 18:15:29 and by crazy I didn't mean impossible ;) May 24 18:16:54 I know, I got that, I just don't think it's crazy :) May 24 18:17:32 kergoth: layout.conf has BBFILES += "${LAYERDIR}/recipes/*/*.bb" so how to change it so that both behaviors work? May 24 18:17:35 there really isn't that much separating, conceptually, tools like bitbake and more typical enterprise level build tools. they both build lots of components, generally obeying dependencies, and do something with the output May 24 18:17:41 shazkhan: eh May 24 18:17:48 shazkhan: thats only used if you're using bblayers with bitbake master May 24 18:18:00 shazkhan: otherwise, again, its BBFILES likely in your *local.conf*, not layer.conf May 24 18:18:14 shazkhan: local.conf is not usually in the oe dir, but your build dir May 24 18:18:24 did not find it there so should I put it there? May 24 18:18:35 oe does not work if you dont set BBFILES May 24 18:18:50 so either its coming from local.conf or your shell script you sourced May 24 18:20:08 has anyone compared an OE build benchmarks on a conventional hard disk vs an SSD? May 24 18:20:52 tharvey: Dramatic improvement. May 24 18:21:36 kergoth: BBFILES := "${PKGDIR}/recipes/*/*.bb" is also in site.conf but niether in setup-env or local.conf as I am dealing with SHR-openmoko May 24 18:22:31 broonie, do you have any stats? ie 10% decrease in buildtime? Any recommendations on drive/interface? May 24 18:23:36 tharvey: No, sorry. My understanding is that you really want to use hte Intel drives. May 24 18:26:03 shazkhan: okay, so whatever setup script you used or instructions youf ollowed placed it there, thats fine, and thats likely the one you want to modify if you want the other path to work, then. May 24 18:26:48 shazkhan: bitbake is quite flexible, as you can probably tell. bitbake.conf includes a variety of files, not just local.conf, and it finds the first of that file in BBPATH, and doesn't -care- which file a variable is defined in, as long as its set May 24 18:27:02 unfortunately, we can't currently say.. okay, this is set to this, but *which file* set it that way? May 24 18:27:13 we'll get that feature sometime in the near future, though May 24 18:28:30 shazkhan: it may help you grasp the big picture to think of the metadata as layered. bitbake.conf is the least specific, and anything more specific than that can override it.. site, being your machine generally, your distro, your target architecture, your machine, etc, always with the more specific information overriding the less specific information. local.conf, ideally, is the most specific of all, letting your build override the rest May 24 18:28:44 sadly, it isn't quite that way, since DISTRO and MACHINE are set in local.conf, those two config files are loaded after local.conf May 24 18:28:48 technical limitation May 24 18:28:59 but you probably get the idea :) May 24 18:29:16 s/your machine, etc/your MACHINE, etc/ May 24 18:29:52 better than before ... thanx May 24 18:30:07 np May 24 18:30:28 I don't know of any good documents that help you grasp the big picture, overall concepts. most of the documentation is rather specific May 24 18:30:38 * kergoth is thinking about trying to throw something like that together though May 24 18:30:48 :) May 24 18:30:56 many people aren't comfortable diving into using something without that understanding May 24 18:31:07 so many of those will end up backing off and using something else, its a barrier to entry May 24 18:31:26 * kergoth seems to be unusually talkative today May 24 18:31:42 * khem lol May 24 18:31:52 thats true ... unless one has a good grasp at the big picture it does'nt work to make it you defacto tool! May 24 18:33:02 anyone know if we still have the original wiki pages from the old, old wiki? May 24 18:33:10 the stuff where we brainstormed the original OE/BitBake design May 24 18:33:20 OE impresses me but it used to scare me 2 yrs back. Now I find myself capable to swallow it gradually :) May 24 18:33:20 i'd like to write something up on the history of the project May 24 18:33:30 shazkhan: hehe, well, welcome back, then May 24 18:33:54 :) May 24 18:34:01 shazkhan: OE has bit of headwind to start with May 24 18:34:08 but then all do May 24 18:34:35 it depends how sophesticated they are to put it in better way May 24 18:34:45 ya ... I started with toolchains and environment variables and now find OE very interesting May 24 18:35:17 thanx to ssome cool lot from #openmoko-cdevel May 24 18:35:18 broonie, thx May 24 18:35:48 that I got to build a decent distro ;p for a start. May 24 18:37:14 kergoth: I'd be excited about some history but also something useful like the big picture and how to headwind ... May 24 18:37:29 shazkhan: there is a lot on wiki May 24 18:37:36 one should read about bitbake and oe manula May 24 18:37:40 manual May 24 18:38:34 khem: urghhh right but they are too lengthy .... I prefer quick starts but I know I am wrong :( May 24 18:39:00 shazkhan: there must be a quick start too May 24 18:39:05 manual is more like a reference manual, which is useful, but not all you need for documentation May 24 18:39:42 I know someone who's written an embedded linux book and gotten it published that's thinking about writing one on OE May 24 18:39:46 will see if that pans out May 24 18:39:48 http://wiki.openembedded.net/index.php/Getting_Started should help May 24 18:40:06 hmmmmm May 24 18:40:22 kergoth: Chris H :) May 24 18:40:23 kergoth: I was also thinking about a book on OE! May 24 18:40:35 this patch vs pnum thing.. i dunno whats more usable. it seems silly to have to set two parameters, for sure, but 'patch=0' doesn't immediately jump out at me as, hey, use -p 0 May 24 18:40:39 khem: yep :) May 24 18:41:10 maybe i should consolidate into pnum. pnum=1, pnum=0, then the -p value is always explicit, and the presence of one implies it being a patch May 24 18:41:13 khem: ya I saw some examples on the wiki that are more quick start kinda .... me becomes nerd now and less talkative. May 24 18:41:25 kergoth: chris is a cool guy May 24 18:41:25 hmm. May 24 18:42:02 khem: yeah he is. he used to be at MV, but he's one of those who came over to mentor :) May 24 18:42:45 really ? May 24 18:42:49 heh May 24 18:42:57 yep, "technical marketing manager" here May 24 18:43:03 so mentor is ex-mv + few mentor folks now :) May 24 18:43:12 * khem should join the band wagon too May 24 18:45:25 gah, i'm tempted to give up on thsi patch stuff now, but its one of those things that bugs me May 24 18:45:28 hmm May 24 18:51:04 kergoth: one bug that I ran into was when I set my TMPDIR with trailing / May 24 18:51:11 TMPDIR=/scratch/oe/ May 24 18:51:12 interesting May 24 18:51:16 all hell broke May 24 18:51:23 TMPDIR=/scratch/oe May 24 18:51:28 its hunky dory May 24 18:51:34 the reason is lamangler May 24 18:51:38 has a sed script May 24 18:51:52 which compares the dirnames and substitutes them May 24 18:52:01 ah May 24 18:52:03 now that my tmpdir has / at end May 24 18:52:15 my workdir has $tmpdir//blah/vla May 24 18:52:26 and it does not match the sed expr May 24 18:52:42 and lamangler does not strip out staging paths May 24 18:52:48 from target packages May 24 18:53:38 classes/autotools.bbclass: autotools_prepackage_lamangler () May 24 18:53:49 -e 's:-I${WORKDIR}\S*: :g;' May 24 18:53:57 ideally, i think we'd do a better job of handling our paths May 24 18:54:08 to support ming, we'd want to support both styles of paths May 24 18:54:16 most likely May 24 18:54:17 yeah May 24 18:54:19 what a nightmare May 24 18:54:39 maybe best to flag vars that are paths, and always use /, and have it convert them internally, and normalize the paths (kill //) May 24 18:54:44 I tried to do var = ${tmpdir%/} May 24 18:54:46 then move all paths into variables, like that one May 24 18:54:53 to strip the trailing / May 24 18:54:56 but it did not work May 24 18:54:59 hmm May 24 18:55:05 my bash-fu is rusty May 24 18:55:06 I think because its not read by shell but by bitbake May 24 18:55:12 ah, yes May 24 18:55:13 indeed May 24 18:55:23 we were stupid to not use something different May 24 18:55:32 wanted something familiar, but now its unclear who's expanding what May 24 18:55:39 we shouldve used the spec % or something :) May 24 18:55:59 var = ${tmpdir%/} works in dash too :) May 24 18:59:14 khem: after talking with workers, for the patch stuff: apply .patch/.diff by default, set -p value by strip=, which is a lot more clear than 'pnum', and if its a patch you have to manually apply, and dont want it applied for you, set noapply=1 May 24 18:59:23 which would be less confusing than nopatch=1 May 24 18:59:27 because it likely *is* a patch May 24 18:59:31 just not one you want do_patch to apply May 24 18:59:35 thoughts? May 24 18:59:38 s/workers/coworkers/ May 24 19:00:05 think thats a more intuitive way than current May 24 19:00:23 striplevel would be more clear May 24 19:00:41 that'd work May 24 19:00:45 apply={no|yes} May 24 19:00:49 is that doable ? May 24 19:00:51 ooh, good one May 24 19:00:52 yeah May 24 19:00:53 easily May 24 19:01:01 the number is vague May 24 19:01:05 yes/no more clearly boolean May 24 19:01:09 or true/value, but yes/no is clearer May 24 19:01:11 and its negative :) May 24 19:01:12 s/value/false/ May 24 19:01:43 okay, i'll do two patches, one ditches patch=/pnum= for apply/striplevel, to make it less odd May 24 19:01:47 seems cool May 24 19:01:50 and a second to do the automatic apply=yes May 24 19:01:52 and get comments May 24 19:01:55 thanks for the input :) May 24 19:02:30 there are like 8 recipes in oe that set patch=0, yet it is a patch, and is applied with pnum=1 May 24 19:02:34 weird. May 24 19:02:58 hmm May 24 19:03:07 yeah go ahead May 24 19:30:29 telnetd: ptsname error (is /dev/pts mounted?): No such file or directory May 24 19:30:35 telnetd: can't create pty May 24 19:32:07 sorry wrong window May 24 19:35:28 03Adrian Alonso  07org.openembedded.dev * rca1efa862f 10openembedded.git/conf/machine/xilinx-ml507.conf: May 24 19:35:28 xilinx-ml507: Add screen option and don't disable tty1 May 24 19:35:28 Signed-off-by: Adrian Alonso May 24 19:35:28 Signed-off-by: Stefan Schmidt May 24 19:35:29 03Stefan Schmidt  07org.openembedded.dev * r7f0b18ea5d 10openembedded.git/: Merge branch 'adrian' into org.openembedded.dev May 24 19:35:31 03Adrian Alonso  07org.openembedded.dev * rb8b73ed5d5 10openembedded.git/recipes/linux/ (linux-xilinx-ml507/xilinxfb.patch linux-xilinx-ml507_git.bb): May 24 19:35:31 linux-xilinx-ml507: Update kernel version and add fb fix May 24 19:35:31 * kernel version 2.6.33 May 24 19:35:31 * frame buffer fix patch add support for new xps_tft May 24 19:35:32 display modules May 24 19:35:32 Signed-off-by: Adrian Alonso May 24 19:35:33 Signed-off-by: Stefan Schmidt May 24 19:35:33 03Adrian Alonso  07org.openembedded.dev * r3eefdbe219 10openembedded.git/recipes/linux/linux-xilinx-ml507/defconfig: May 24 19:35:34 linux-xilinx-ml507: Enable video framebuffer in defconfig May 24 19:35:34 Signed-off-by: Adrian Alonso May 24 19:35:35 Signed-off-by: Stefan Schmidt May 24 19:35:35 03Adrian Alonso  07org.openembedded.dev * r05f7fb1f63 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): May 24 19:36:05 xserver-xorg-conf: Add xilinx-ml507 config May 24 19:36:05 * xorg config file for xilinx-ml507 target platform May 24 19:36:05 Signed-off-by: Adrian Alonso May 24 19:36:05 Signed-off-by: Stefan Schmidt May 24 20:05:20 03Khem Raj  07org.openembedded.dev * r163a66fac4 10openembedded.git/conf/distro/minimal.conf: (log message trimmed) May 24 20:05:20 distro/minimal.conf: Dont keep CACHE as weak assignment. May 24 20:05:20 * As this is a weak assignment and bitbake.conf has a proper May 24 20:05:20 assignment and bitbake.conf is included before distro conf May 24 20:05:20 file it leaves this weak assignment as no-op. The problem happens May 24 20:05:21 when using minimal but changing libc from eglibc to uclibc then May 24 20:05:22 it will use same cache directory and then its infact wrong. May 24 20:05:22 03Khem Raj  07org.openembedded.dev * r8a78d6a20a 10openembedded.git/recipes/uclibc/uclibc_git.bb: May 24 20:05:23 uclibc_git.bb: Bump SRCREV May 24 20:05:23 Signed-off-by: Khem Raj May 24 20:28:25 khem, I have an interactive shell on the htcleo device now. I suspect something is wrong with the userspace compilation. there are many programs segfaulting and giving illegal instruction errors May 24 20:28:42 dcordes: cool May 24 20:28:46 good job May 24 20:28:49 we can fix those May 24 20:29:11 khem, the problem is that even telnetd which I'm using to connect seems buggy. May 24 20:29:22 hmm May 24 20:29:32 do you have gdb on the target May 24 20:29:41 it will pause occasionally and then pass the data in one big chunk May 24 20:29:41 if not then put it on May 24 20:29:46 it is installed. May 24 20:29:49 ok May 24 20:30:12 then you can install the dbg ipks May 24 20:31:05 I think I'd better do this on the host machine May 24 20:31:16 thats fine too May 24 20:31:25 launch gdbserver there May 24 20:41:51 khem, should I just add the dbg packages via extra install? May 24 20:42:12 khem, or is there some mechanism to add dbg packages automatically? May 24 20:42:36 I guess the mechanism patch is not committed yet May 24 20:44:15 * kergoth takes that as a reminder to go back over his pending patches May 24 20:47:22 khem, think I should remove the 'no udevd init' patch ? May 24 20:52:20 dcordes: ok May 24 20:52:51 greetings! is anyone using an angstrom toolchain? May 24 20:53:21 I'm using the 4.5.2 qte from http://www.angstrom-distribution.org/toolchains/ May 24 20:54:43 I always get this error http://pastebin.com/P9pntg6q May 24 20:55:10 I've tried other toolchains in that same folder and get the same thing when trying to compile other apps May 24 20:55:22 I assume it must be my build environment (ubunty hardy) May 24 20:59:51 oneshel: yeah the problem is that its expecting libmpfr to be on your host machine May 24 21:00:54 khem: a-ha, I knew it must be something like that May 24 21:01:11 awesome, thanks so much, it's working May 24 21:01:23 I just blindly assumed anything I'd need would be in the toolchain May 24 21:01:54 yeah we pondered over this to package version of tools which have this statically linked in May 24 21:02:01 but thus far you need to have it on the box May 24 21:02:12 if you are using gcc 4.2+ May 24 21:03:57 cool, thanks again May 24 21:15:24 khem, looks like the telnetd seems too buggy to do anything useful May 24 21:16:16 khem, I will append a new dmesg with lots of output May 24 21:23:13 khem, there are known working builds of busybox. maybe I should use that in some initrd and chroot to the sd with oe image May 24 21:23:32 yeah that would help May 24 21:23:39 if you are able to chroot May 24 21:23:48 yes that worked before May 24 21:23:57 into the same image May 24 21:28:57 yeah try to debug telnetd May 24 21:29:07 or any other application with illegal instr May 24 21:29:35 khem, if it's only that.. maybe it's easier to run the debug commandline from init May 24 21:30:09 but I don't know what's the correct way to do that. didn't find much on using gdb via script May 24 21:30:17 I tried to add something like May 24 21:30:22 gdb /sbin/init 1 May 24 21:30:54 that may not work May 24 21:31:06 you have to debug one process at a time May 24 21:31:18 init is a process in itself and it dicy May 24 21:36:11 khem, downloading known working initrd. hope it contains telnetd May 24 21:45:42 khem: perhaps you could hack the two patches c/o Enrico which Kergoth already ack'ed May 24 21:46:20 (autotools and packaged-staging) May 24 21:50:26 ant_home: I will look May 24 21:50:30 I wanted to test them here May 24 21:51:26 I've tested the second one (packaged-staging) May 24 21:52:10 I still see some strange issues (race?)...l May 24 21:56:24 ok May 24 21:56:41 khem, I will update the bug soon as I have a _truely_ working connection. thanks again for the assistance May 24 21:56:43 later May 24 21:59:19 kergoth: is the ouput of bitbake -c listtasks ordered? May 24 22:00:45 doubtful, think it just operates based on keys() from the metadata, which is a dict under the hood May 24 22:00:53 hm..no, definitely not May 24 22:01:25 I imagine I encounter an issue with tasks order and 4 bb_threads May 24 22:02:01 and I see the *_all tasks sneaks everywhere without apparent logic... May 24 22:02:14 in the a.m. output May 24 22:03:01 those are a pain to diagnose. unfortunately, no way to go back and see what tasks were run in what order on what threads May 24 22:03:15 would be nice to be able to determine more things about the build looking at a tmpdir after the fact May 24 22:06:06 Well, zaurus-updater is the most deprecated piece of software ever written...always failing for som ereasons (package_stagefile_shell) May 24 22:07:40 now, RP's comment May 24 22:07:43 # package_stagefile_shell need to run before populate_sysroot for packaged-staging May 24 22:08:00 I'd suppose is still valid May 24 22:08:39 hmm qemu does not let me login at all May 24 22:08:42 the whole package_stagefile_shell thing remains an hack May 24 22:08:44 username root May 24 22:08:54 password should be nothing but it doesnt let mein May 24 22:09:28 where should I look at May 24 22:12:39 khem: may need to add zap_root_password; to ROOTFS_POSTPROCESS_COMMAND May 24 22:16:53 ROOTFS_POSTPROCESS_COMMAND =+ "zap_root_password" May 24 22:16:58 in machine.conf May 24 22:17:01 will that be ok ? May 24 22:20:49 no May 24 22:20:53 its a shell command May 24 22:21:00 if its not empty, it'll error May 24 22:21:02 don't forget the ; May 24 22:21:21 zap_root_password; if you're doing =+ May 24 22:45:46 gm May 24 22:45:55 hi likewise May 24 22:46:06 kergoth_: I discovered what's happening...here is another issue: a recipe bug! May 24 22:47:00 hehe May 24 22:47:02 we try to have an armv5te recipe which does strange machine-specific things with package_stagefile_shell :/ May 24 22:47:02 there are lots of those! May 24 22:47:16 No! No such thing as bugs in recipes! :p May 24 22:47:42 * kergoth_ thinks of oe recipes as similar to linux kernel device drivers, from a quality perspective :P May 24 22:48:01 kergoth: it happens on multimachine builds, otherwise one doesn't see this May 24 22:48:37 i.e. updater.sh is hidden in a machine specific dir in the staging.. ipk May 24 22:48:53 package_stagefile_shell is rather a hack to begin with, hacking on top of that is worrisome :) May 24 22:48:53 so second machine can't find it staged May 24 22:49:05 he he May 24 22:49:35 now I see why koen insisted 'leave it machine-specific' May 24 22:50:00 heh, if it has machine specific files in there, it should stay that way May 24 22:50:19 hm..actually is 'universal updater' May 24 22:50:21 what recipe is that? May 24 22:50:34 the (in)famous zaurus-updater May 24 22:50:42 kergoth: I feel I can write better device drivers than recipes :-) May 24 22:50:51 likewise: that's worrisome :) May 24 22:50:53 it is not machine specific by nature May 24 22:51:20 kergoth_: haha :-) May 24 22:51:40 * mwester thinks device drivers are FAR easier than attempting to debug toolchain build issues. :( May 24 22:52:04 hm...this bit May 24 22:52:06 package_stagefile_shell ${DEPLOY_DIR_IMAGE}/updater.sh May 24 22:52:51 now, for A. DEPLOY_DIR_IMAGE contains machine name May 24 22:57:09 well, not only Angstrom, minimal too: May 24 22:57:17 ./distro/minimal.conf:DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}" May 24 22:57:42 default is not multimachine-friendly, probably: May 24 22:57:48 ./bitbake.conf:DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images" May 24 23:13:35 03Andrea Adami  07org.openembedded.dev * ra9102cac0e 10openembedded.git/recipes/zaurus-utils/zaurus-updater.bb: May 24 23:13:35 zaurus-updater: force back PACKAGE_ARCH = "${MACHINE_ARCH}" May 24 23:13:35 * though not machine specific, the recipe uses package_stagefile_shell May 24 23:13:35 * and being DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}" May 24 23:13:35 * in case of multimachine builds only the first one has a valid staging ipk. May 24 23:32:58 | AttributeError: 'module' object has no attribute 'pydebug' May 24 23:32:58 | FATAL: python setup.py build_ext execution failed. May 24 23:32:58 NOTE: package python-m2crypto-0.18.2-ml1: task do_compile: Failed May 24 23:41:45 don't everyone talk at once... May 24 23:52:52 mwester: sorry I was not able to look at your issue May 24 23:55:39 awozniak: seems like cyclic dependency of modules May 25 00:07:14 khem: yeah, I'm just not sure how to fix. I'm trying a bitbake -k, waiting for that to finish, then try it again. May 25 00:26:16 s'ok, khem - but I want a refund of the down payment I made on repairs. :p :D May 25 00:52:34 nite all **** ENDING LOGGING AT Tue May 25 02:59:57 2010