**** BEGIN LOGGING AT Thu May 03 02:59:56 2007 May 03 03:00:17 never mind, I found the answer May 03 03:07:17 Note that this will build packages with version "1.2.2+cvs2007xxxx", which uses the old qtopia or QT/embedded-2.3.10 Note that this is not the OPIE II project (which unfortunately labeled itself opie-1.2.3 after svn checkout): http://www.linuxtogo.org/gowiki/OpieProject., which uses the new qtopia-4.2.1. May 03 03:07:26 updated wiki here: http://www.linuxtogo.org/gowiki/OpieWithAngstrom May 03 03:39:08 xjqian: your update reverted, please read the page, or at least intro, before making random changes. thanks. May 03 03:46:41 psokolovsky: that's fine and yes i've read the intro May 03 03:47:32 psokolovsky: could you link the opie II page to the intro, so people know which one is which. May 03 03:47:57 xjqian: then it must have been clear taht it's not opie2, as intro makes that pretty unambiguous May 03 03:48:32 xjqian: I will some next time, or you're welcome to do that May 03 03:48:33 psokolovsky: what seems confusing to me is http://www.linuxtogo.org/gowiki/OpieProject?highlight=%28opie%29 has the title OpieProject May 03 03:50:07 xjqian: this issue was already raised to opie2 organizer. he's response was along the lines that creating confusion among the users would be one of his aims. so, enjoy your flight. May 03 03:50:39 xjqian: there's extensive discussion on opie-devel list if you're interested May 03 03:51:38 ugh. i see. another confusion is after svn checkout svn://projects.linuxtogo.org/svn/opie/trunk opie II creates a directory opie-1.2.3 by default May 03 03:52:01 thanks for the pointer May 03 04:16:46 i dont think opieII labeled itself as opie 1.2.3 May 03 04:21:26 ljp: your're right. sorry my mistake May 03 04:23:21 ljp: indeed, interesting reading in the opie mailing list. ljp, I see your point. But I'm on psokolovsky's side for the confusion in naming. May 03 04:24:21 whats the confusion? May 03 04:24:45 t would have been confusing if opieII was just opie May 03 04:26:53 then why not register opie as opieII May 03 04:27:00 i never said one of my aims was creating confusion among users, thats just bs May 03 04:27:24 the name IS opieII May 03 04:27:28 and in serveral wiki pages, http://www.linuxtogo.org/gowiki/GettingOpieSources, this for example May 03 04:27:37 morn :) May 03 04:27:47 i was linked to this page from the mailing list May 03 04:27:56 quite less confusiong than the whole GPE hubbub May 03 04:28:15 and there's no indication at all this is to fetch opieII May 03 04:28:41 not a single sign until I got the source and read the README in the trunk May 03 04:29:15 i know it's not your intension to confuse people, but how the wiki pages are written is really confusing May 03 04:31:49 esp to people new to opie May 03 04:32:23 ok, well. i will clean tham up when i get the chance May 03 04:33:28 thanks May 03 04:34:36 ljp: of course you didn't say that. you said that you don't care, and did it confusing way. so don't be surprised that people start to think that you want the confusion. May 03 04:35:23 well, someone telling them that wont help May 03 04:36:15 ljp: and as for gpe then again, it seems like there's funky inclination to follow that way. and that strange - while working on opie2, wouldn't it be good idea to keep opie1 users warm and not dissatisified with confusion? May 03 04:37:52 i still dont see where any confusion is. May 03 04:38:21 i could have committed the code to handhelds.org, but i didnt May 03 04:53:25 ljp: you decide where to host. but if you consistently used opieII/opie2 name everywhere (including project/repo internal names), that would be helpful for people May 03 06:20:41 good morning all May 03 06:23:36 moin May 03 06:25:40 * koen got his tax return :) May 03 06:30:43 koen: you pay taxes? May 03 06:31:02 yes, but since I'm a student, I get it all back May 03 06:31:19 my employers pay taxes for me automagically May 03 06:36:22 * CM gets to pay extra taxes... As if 33% wasn't enough May 03 06:36:52 psokolovsky__: qemu-native compilation with the patch finished fine. May 03 06:37:25 Good morning May 03 06:37:31 morning! May 03 06:37:50 Laibsch: cool, now just tell us that it aslo able to generate working locales ;-D May 03 06:43:00 psokolovsky__: That is all the testing I was going to do on that one. May 03 06:43:24 I already reversed the patch and cleaned out that qemu-native May 03 06:43:39 The working locale part is left up to you ;-) May 03 06:44:21 psokolovsky__: I interrupted the bitbake clean May 03 06:44:32 How do I find out if it generates working locales? May 03 06:44:35 lol. as if somebody doubted it does compile ;-) May 03 06:44:46 psokolovsky__: I thought you did May 03 06:44:55 I at least was not sure. May 03 06:45:09 If that does not help, then fine May 03 06:45:17 Not my problem May 03 06:45:24 Laibsch: first step is apparently try to build locale(s) at all. if it won't segfault, good sign May 03 06:45:30 I got a solution I deem superior for me May 03 06:45:54 psokolovsky__: "bitbake glibc" ? May 03 06:46:01 Laibsch: then, you can just save generated packages and compare with gcc3-compiled-qemu later (or uplaod so someone else did that) May 03 06:46:11 I am sorry but I don't have the time for that May 03 06:46:14 Laibsch: yep May 03 06:46:29 Nah, you will have to do that. May 03 06:46:33 Laibsch: but you'd need to do anyway, right? May 03 06:46:41 ok May 03 06:47:17 psokolovsky__: I do *not* want anything compiled that I will use later on while this untested patch is applied May 03 06:47:17 my whole idea of asking you was that you do a clean rebuild on a new machine, and could follow thru all that May 03 06:47:25 ok May 03 06:47:34 psokolovsky__: That takes me several days as you know May 03 06:47:42 an image might even take a week May 03 06:47:52 I am not cleaning out tmp to test a single bug May 03 06:48:37 * Laibsch is back to bitbake -c rebuild qemu-native May 03 06:49:03 Laibsch: with GLIBC_GENERATE_LOCALES locale generation alone takes 10mins max, add ~1-2hr compiling glibc May 03 06:49:17 not my machine May 03 06:49:23 not on my bb machine May 03 06:49:35 ok, sorry to bother you then ;-) May 03 06:49:40 And I don't even want to spend ~1-2 hours May 03 06:49:46 np May 03 06:49:50 later May 03 06:50:07 zecke: Still up? Later May 03 06:50:21 Seems like everybody skipped sleeping last night May 03 06:52:37 03koen 07org.oe.dev * rf93b1c50... 10/ (1 packages/cairo/cairo_git.bb): cairo-git: update PV May 03 07:15:24 * Laibsch suggests to remove the "not supported"-part from http://www.linuxtogo.org/gowiki/OpieWithAngstrom May 03 07:18:41 hello all May 03 07:19:08 hey likewise May 03 07:19:19 hey koen May 03 07:19:36 likewise: http://ewi546.ewi.utwente.nl/tmp/eabi-eb.diff May 03 07:20:38 koen: yup, something like that should do it (finger crossed still) May 03 07:21:07 koen: haven't been able to test yet, my nightly build was broken May 03 07:22:02 I have a toolchain now May 03 07:22:19 * koen builds an image May 03 07:23:16 I'm still having problems that every package and then some gets pulled in my images... at least in the build May 03 07:28:05 you can avoid that by giving each task-* in task-base.bb its own recipe May 03 07:29:52 03polyonymous 07org.oe.dev * rb896e366... 10/ (6 files in 3 dirs): May 03 07:29:52 qte, qte-mt 2.3.10: Fix build with recent kernel headers. May 03 07:29:52 * Closes #2201. May 03 07:29:56 03pfalcon 07org.oe.dev * ra2852adc... 10/ (4 files in 3 dirs): May 03 07:29:56 opie-todo cvs: Unbreak system-wide logging. May 03 07:29:56 * A specific app may not override system-wide parameter on a whim - it's May 03 07:29:56 under user control. May 03 07:30:02 03pfalcon 07org.oe.dev * r388abcdc... 10/ (3 files in 3 dirs): (log message trimmed) May 03 07:30:02 opie-taskbar cvs: Don't bother to start qss from C++ code. May 03 07:30:03 * Because it's useless - to have a separate process for sound server, May 03 07:30:05 and then have mishacks to start/keep alive it hardcoded in C++. That doesn't May 03 07:30:07 work somehow (h4000, hx4700, etc. machines have issues), and then it May 03 07:30:09 completely non-debuggable. May 03 07:30:11 * So instead, qss should be started separately, of course from a shell script. May 03 07:30:13 03pfalcon 07org.oe.dev * r686b8a7b... 10/ (1 packages/tasks/task-opie.bb): May 03 07:30:15 task-opie: Add opie-qss, an OPIE sound server, essential component. May 03 07:30:17 * Fixed #2211. May 03 07:30:21 03pfalcon 07org.oe.dev * rc3d8d21c... 10/ (3 files in 3 dirs): May 03 07:30:23 opie-init: Start qss daemon. May 03 07:30:25 * Fixes #2211. May 03 07:30:27 03pfalcon 07org.oe.dev * rdb859e25... 10/ (1 packages/opie-init/opie-init/opie): opie-init: Actually daemonize qss. May 03 07:30:32 03koen 07org.oe.dev * r4bc8cc04... 10/ (4 files in 3 dirs): gcc 4.1.2: fix 800-arm-bigendian.patch May 03 07:40:28 likewise: updated patch is in May 03 07:45:27 koen: starting a fresh build then for ixp4xxbe/angstrom May 03 07:49:42 zecke: good morning May 03 07:50:26 moin May 03 07:50:30 Laibsch: now I'm here May 03 07:52:44 you're not here, you're in berlin May 03 07:57:42 koen: what makes you believe that? May 03 07:57:56 your sith powers May 03 08:05:02 ;) May 03 08:05:07 ~snack for koen May 03 08:05:16 * ibot throws for koen a doggy treat May 03 08:16:29 03koen 07org.oe.dev * r2b2a9e8b... 10/ (3 files in 3 dirs): linux-ezx 2.6.21: update to r1996, fixes some oopses May 03 09:43:48 monring May 03 09:54:49 hi ade May 03 10:06:00 mood gorning. May 03 10:06:22 hi polyonymous May 03 10:06:32 hi. May 03 10:07:53 Laibsch, I wouldn't say that 'opie in angstrom' metabug depends on the dual gpe/opie image bug ;-) May 03 10:10:36 My interpretation as creator of the meta-bug is "all bugs related straight to opie" which is true. May 03 10:12:52 to rephrase it, koen should be able to safely ignore any bug that is blocking it ;-) May 03 10:14:16 Could this be a dash/bash issue? | make[3]: Leaving directory `/home/leon/sandbox/ixp4xxbe-eabi/openembedded/build/tmp/work/x86_64-linux/perl-native-5.8.7-r5/perl-5.8.7/x2p' May 03 10:14:18 | ../makedepend: 1: Syntax error: Unterminated quoted string May 03 10:14:40 likewise: probably May 03 10:14:44 likewise: yes, makedepend of perl is broken :) May 03 10:14:49 I built 5.8.8, which is dash-safe May 03 10:15:08 Laibsch, I just stated my opinion, I'm not feeling like fighting for it :) May 03 10:15:10 ok, tnx. May 03 10:15:17 morning all May 03 10:15:29 morning Ifaistos May 03 10:15:42 ***good*** morning Ifaistos May 03 10:16:02 * Ifaistos is happy as his baby is now 55 mm long May 03 10:16:15 likewise: http://www.openembedded.org/~koen/ARM-eb-EABI-rootfs.tgz May 03 10:21:03 koen: got it. need to prep some h/w setup here. May 03 10:21:52 * likewise checking if the ixp4xx kernels have EABI enabled May 03 10:22:36 hmm. no. need to build an EABI kernel first May 03 10:22:43 Laibsch, tried to hack around your collie psplash (bug 2149), yet? May 03 10:33:27 opie-todo doesn't build, hmm... May 03 10:38:58 likewise: Lennert: Yep, werkt perfect. Dus toch __ARMEB__-issues.. May 03 10:46:17 Hi! May 03 10:46:34 hey May 03 10:46:42 koen: So, can you link http://linuxtogo.org/gowiki/AngstromFaq for word "FAQ" on angstrom site? May 03 10:47:16 koen: or do you leave that as an exercize to a reader - read wiki and discover faq? May 03 10:47:32 koen: please don't, *many* people will fail it ;-) May 03 10:47:38 if ti was hard to write it should be hard to understand :) May 03 10:48:06 koen: and thanks and congrats on the facelift of the site ;-) May 03 10:56:32 koen: what works perfectly? your rootfs? May 03 10:56:43 likewise: yes May 03 10:57:02 koen: ok, so the missing patch hunk was the root of all evil? May 03 10:57:11 likewise: it seems that way May 03 11:12:22 morning May 03 11:12:28 hey chouimat May 03 11:33:20 psokolovsky__: bitbake -c clean only cleans up stuff in tmp/work. Are there any other bitbake -c command that cleans up stuff in tmp/staging (or I have to clean those manually). (I've read the bb manual and can't find any enlightenment, btw) May 03 11:45:53 xjqian: no. finish "packaged staging" thing if you want it ;-) May 03 11:46:50 psokolovsky__: got it. thanks May 03 11:46:59 psokolovsky__: expect some updates to packaged-staging during GUADEC :) May 03 11:47:11 koen: cool! May 03 11:49:01 psokolovsky__, just FYI - on my Z sound in opie works on initial start as well. May 03 11:49:28 polyonymous: since when? May 03 11:50:33 psokolovsky__, don't know, I've just tested with a fresh image. May 03 11:50:33 the one that doesn't build (2224:)). May 03 12:06:42 RP: the install patch works fine, the only exception being do_deploy May 03 12:07:38 psokolovsky__, regarding 2224 - I think the patch was older than your recent cvs bump? May 03 12:08:49 polyonymous: no. please describe the exact issue you have, not ideas what it might be May 03 12:09:11 psokolovsky__, what is there to describe? The patch doesn't apply, because it's already there after checkout. May 03 12:09:24 NOTE: :argument of type 'NoneType' is not iterable while evaluating: May 03 12:09:26 ${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']} May 03 12:09:54 polyonymous: link to upstream please May 03 12:12:36 psokolovsky__, heck, it's two years old, but it DOES contain the patch: http://handhelds.org/cgi-bin/cvsweb.cgi/opie/core/pim/todo/main.cpp?rev=1.11&content-type=text/x-cvsweb-markup May 03 12:13:27 hmm.. May 03 12:13:29 koen: Now this can be reversed I guess? http://www.openembedded.org/viewmtn/revision.psp?id=f342c01c457224ae016d92fea9fbf40b24d88f32 May 03 12:13:29 polyonymous: ok, let's start from the start. which patch? May 03 12:13:44 likewise: yes May 03 12:13:49 psokolovsky__, hang o. May 03 12:13:50 n May 03 12:14:47 psokolovsky__, forget it. May 03 12:14:59 03pfalcon 07org.oe.dev * re51f8fd8... 10/ (3 files in 3 dirs): May 03 12:14:59 libqpe-opie cvs: Unbreak logging. May 03 12:14:59 * Again, it's bad idea to randomly disable some logging sources based on May 03 12:14:59 obscure compile-time defines (QT_DEBUG is not mentioned in qte-2.3.10, so May 03 12:14:59 how could it get such name at all?). OE OPIE is going to have logging facility May 03 12:15:00 helping to resolve issues, not obfuscate them. May 03 12:15:57 03koen 07org.oe.dev * ra8e33b18... 10/ (1 conf/machine/ixp4xxbe.conf): ixp4xxbe: the gcc patch is in, so no need for this workaround anymore May 03 12:17:14 likewise: there you go May 03 12:17:36 psokolovsky__, not exactly forget it - the patch doesn't apply. I don't know what I was looking at, when I said it doesn't apply, because it's already there. May 03 12:18:10 koen: and http://www.openembedded.org/viewmtn/revision.psp?id=bc8cfed5e37f251070c62f9cef49b1db7aa86264 May 03 12:18:27 polyonymous: yes, that's true. reasons not true. first rule of system enginering - don't trust anything, verify ;-) May 03 12:18:53 psokolovsky__, Yes, I do not have much to say in my defense :) May 03 12:19:16 and now I wonder who on earth was such smart as to stuff some gnome crap for patch conflict resolution?! May 03 12:19:20 likewise: right May 03 12:19:22 psokolovsky__, it's todo/ path, have you fixed it yet? May 03 12:19:36 shame, shame! people forgot what unix is! they use some May 03 12:19:58 "leenooks" crap with dwarfs and stuff, instead of commandline! May 03 12:20:00 shame! May 03 12:21:09 # Set a default May 03 12:21:10 TERMCMD ?= "${GNOME_TERMCMD}" May 03 12:21:12 b/s May 03 12:21:22 psokolovsky__, I'm running away now. I don't know if you fixed that patch, just in case: http://rafb.net/p/khF9fi12.html May 03 12:21:25 * polyonymous is gone May 03 12:22:15 koen: thanks. May 03 12:22:32 likewise: could you revert the patch, I'm about to run off May 03 12:22:39 I am hitting a bitbake problem here or something else? http://www.pastebin.ca/468837 May 03 12:22:51 koen: yes, will do May 03 12:22:57 koen: cu May 03 12:23:08 likewise: no TARGET_OS? May 03 12:23:25 (armeb-INVALID vs armeb-linux) May 03 12:23:40 koen: using MACHINE=ixp4xxbe with DISTRO=angstrom-2007.1 May 03 12:23:52 koen: lemme check eb vs be May 03 12:25:00 koen: ixp4xxbe May 03 12:48:18 * polyonymous is back May 03 12:48:23 03lenehan 07org.oe.documentation * ref06b87a... 10/ (1 usermanual/reference/image_types.xml): (log message trimmed) May 03 12:48:23 usermanual: Update image types to match recent changes: May 03 12:48:23 - ext3 and ext3.gz have been added May 03 12:48:23 - cpio and cpio.gz have been added May 03 12:48:23 - default options for jffs2, squashfs and squashfs-lzma have been changed May 03 12:48:24 - ext2.gz now deletes tmp files so leftovers don't break next run May 03 12:48:26 - tar has been changed to make tars instead of tar.bz2's May 03 13:08:02 psokolovsky__: What is your problem? May 03 13:10:30 RP: Well, mail should describe it well enough - no rc check for "terminal" command, out-of-hand default for such command. I leave interpretation of the rest to you ;-) May 03 13:11:07 psokolovsky__: You just succeeded in massively pissing me off... May 03 13:12:03 RP: I'm sorry, but I tried to make it both funny and "cognitive" May 03 13:12:33 RP: it's also pissing off for me to understand that I could been building broken images for a month now %) May 03 13:13:32 psokolovsky__: I can understand that being frustrating. We are all trying to develop various things and with the best will in the world, things do break though May 03 13:14:28 hmm OT: can you break broken glass ? May 03 13:15:49 RP: yeah, but I clear added humoresque shade to that "report", no? maybe just too "vivid", because I'm not sure I could argue to success that such a tool like bitbake should *not* depend on nay GUI stuff ;-I May 03 13:16:35 RP: otherwise, I of course didn't intend to make you frown in a day ;-) May 03 13:17:04 It's my fault, I made psokolovsky__ mad today :) May 03 13:17:14 probably, he passed the piss :) May 03 13:17:55 polyonymous: well nope, but I wonder if you had the same issue. I initially thought you did May 03 13:18:15 psokolovsky__, the same like what? May 03 13:18:44 psokolovsky__, I indeed goofed twice today. May 03 13:18:57 polyonymous: like silent failure to patch, though I now guess it wasn't your case May 03 13:19:26 psokolovsky__, maybe it's just my setup, but it wasn't quite failure. It was quite audible. May 03 13:19:45 psokolovsky__, but.. May 03 13:19:49 psokolovsky__: I've replied to the mail with some hints May 03 13:19:57 ahhh now I know what this GUI stuff you're talking about. May 03 13:20:06 psokolovsky__, yes, I've had terminal popup. May 03 13:20:08 psokolovsky__: automated builds are why we shouldn't depends on GUI functionality May 03 13:20:22 psokolovsky__: but that doesn't mean we shouldn't have optional GUI functionality May 03 13:21:13 RP, If I get it right, the problem is that it's not optional enough. The rest is emotional miscommunication :) May 03 13:22:04 polyonymous: See the reply, it is optional, you just need to know how to configure it. There sounds to be some kind of error propagation bug somewhere too May 03 13:22:06 RP: optional, sure! (especially if you need it). but the change goes towards requiring GUI by default, and I couldn't appreciate that, and I'm sure there're few people around who would agree. May 03 13:22:34 I haven't even read original mail :) May 03 13:22:47 psokolovsky__: Its just a bad default for PATCH_RESOLVER. FWIW, I didn't set that default May 03 13:23:10 psokolovsky__: If we want to change it to noop, I'm fine with that May 03 13:23:30 But without looking at it (I will in half a minute) I think the solution is comething along the lines `${TERM} || ${BASH}`. May 03 13:23:31 I do want to find the underlying bug though as command failures should abort the build May 03 13:24:13 polyonymous: No, that breaks under multithreading. I've given this a lot of thought and there have been several mails to the mailing list about it May 03 13:24:16 RP: apparently, that's what should be done, right. thanks for proposing that. May 03 13:24:50 RP, yes, that makes sense, indeed.... then, maybe `|| ${FAIL}`. May 03 13:24:52 psokolovsky__: I want to find that underlying bug though - don't just take the simple solution ;-) May 03 13:25:36 RP: yeah, I guess May 03 13:25:47 well, anyway. I think you can do without my intervening :) May 03 13:25:55 RP: I will try to do that too a bit later, if you won't beat me on that May 03 13:26:27 psokolovsky__: I have other things to do atm. It'll probably be the weekend before I can think about it May 03 13:26:53 hi all May 03 13:27:12 psokolovsky__, do I reopen todo bug, or is it not necessary? May 03 13:27:34 RP: ok. again, sorry, if I pulled you from important thing and added unneeded headache. wasn't intended. May 03 13:27:43 hi mr_nice May 03 13:27:46 * woglinde heads home May 03 13:27:51 hi woglinde May 03 13:27:57 polyonymous: I committed it, feel free to try buidl again May 03 13:28:17 psokolovsky__, ok. on last pull I've had multihead hydra :) May 03 13:29:23 psokolovsky__, And I've just tested the getpagesize() fix - seems to work fine. May 03 13:30:28 polyonymous: nice. I'll commit as soon as I'll do next code session ;-) May 03 13:30:53 good. just letting you know, not hurrying you up :) May 03 14:14:27 Aarrgh. qemu: uncaught target signal 11 (Segmentation fault) - exiting (this is natively installed qemu on Feisty 7.04) May 03 16:10:44 polyonymous: morinng :) May 03 16:20:57 hvontres|poodle, yes :) May 03 16:22:59 hvontres|poodle, got /msg? May 03 16:28:22 polyonymous: got it, thanks :) I'll grab it when I get home tonight May 03 16:28:57 Good. It will be there waiting for you :) May 03 17:43:33 hi likewise! May 03 17:52:22 Can anyone suggest the best method of creating a single file image with kernel+jffs2 as rootfs with u-boot ? May 03 17:52:47 paste the files together with dd or use mkimag -T multi option ? May 03 18:03:53 HopsNBarley: hi! May 03 18:03:55 hi all May 03 18:04:02 hi likewise May 03 18:04:17 koen: did not commit the revert yet, I didn't have my key with me... May 03 18:04:36 and I'm playing with a new toy :) May 03 18:04:41 * koen likes tax returns May 03 18:05:19 koen: the cam you saw on ebay or something else? May 03 18:05:38 koen: but will commit in a moment. May 03 18:05:41 koen: what toy? May 03 18:06:03 new image stabilised lens May 03 18:06:13 ah May 03 18:06:18 not my kind of toy then ;) May 03 18:06:25 doens't run linux :) May 03 18:06:38 nope May 03 18:06:41 shame ;) May 03 18:08:13 koen: what's the best way to commit? disapprove or just a reverse patch? May 03 18:08:42 remove the patch from SRC_URI and mtn rm -e it May 03 18:09:14 DaggyFixes would involve disapproving it and merging, but that makes my brain hurt May 03 18:10:13 http://www.venge.net/mtn-wiki/DaggyFixes May 03 18:12:02 i have a question about building packages that are subsets of other packages May 03 18:12:35 for example, if i tried creating a diffutils-minimal that only included diff and cmp (omitting sdiff and diff3) May 03 18:13:23 however, when i build my final image, diffutils is added to it to 'satisfy runtime diffutils-minimal' May 03 18:13:49 any thoughts on what i need to do to break this dependence? May 03 18:18:51 03likewise 07org.oe.dev * rd8cede68... 10/ (4 files in 4 dirs): glibc: Remove armeb strlen workaround. We now have the GCC PR16350 patch, take 3 in GCC. May 03 18:32:40 psokolovsky__, ping? May 03 18:32:51 polyonymous: pong May 03 18:33:04 psokolovsky__, why no-builtin-qss-startup.patch ? May 03 18:33:48 polyonymous: read commit message May 03 18:33:54 psokolovsky__, good point :)) May 03 18:33:56 sorry May 03 18:34:31 polyonymous: btw, possible, it in fact will be reverted, but instead shell wrapper will be called May 03 18:35:06 polyonymous: of course, unless you have better ideas: a) why pocketpc/palms don't work; b) how to make it all more debuggable May 03 18:35:42 psokolovsky__, hmm... when it started autmatically there's no way to kill it and restart elsewhere? May 03 18:36:20 psokolovsky__, I'd be glad to find out why pocketpc/palms don't work, but I do not have it :) May 03 18:36:38 polyonymous: no. it stupidly keeps restarting its own instance. that's exactly why that patch - better control by externalizing May 03 18:37:00 rwhitby: EABI/BE is working now May 03 18:37:06 psokolovsky__, I see... The thing is that this 'sleep 1' isn't always enough. May 03 18:38:15 polyonymous: yep, I guess ;-). how much? May 03 18:38:42 psokolovsky__, I haven't tried to find out, it depends on device. _sometimes_ sleep 1 _is_enough.. May 03 18:39:32 psokolovsky__, as for debugging you can rename file for debugging. May 03 18:39:46 polyonymous: again, why I think that maybe calling it from qpe would be better after all - it *knows* when to start it ;-) May 03 18:40:10 polyonymous: no, there're should decend diagnostics means w/o any hacks May 03 18:40:15 should be May 03 18:40:20 that's basically the only reason why I raised the issue :) May 03 18:40:35 well, debugging _is_ hacking, anyway :) May 03 18:41:18 I'd that that externalizing for debugging isn't the reason, because debugging is not the primary purpose of running software :) May 03 18:42:11 So, I'd rather run it from qpe... But naturally, the issues should be solved... May 03 18:42:25 polyonymous: that's why I call it "diagnostics" after all. Diagnostic support *is* important feature of any complex system. May 03 18:42:52 psokolovsky__, "diagnostics" as in "logging" should work from qpe, no? May 03 18:43:03 polyonymous: try it ;-) May 03 18:43:15 psokolovsky__, If you say no, I'd believe you :) May 03 18:43:26 and compare with decent solution, like log4j ;-) May 03 18:44:06 polyonymous: it's adhoc, inconsistent, and fragmented. was scarse at all w/o my recent patches May 03 18:45:00 psokolovsky__, well, I'm not going to defend this thing, it's just that I doubt the solution is good. May 03 18:45:24 polyonymous: which one? external startup of qss? May 03 18:45:42 yes, I'm only talking about his. I do not propose redoing the whole opie :) May 03 18:47:44 psokolovsky__, what about a little compromise: do not restart qss? :) May 03 18:48:23 polyonymous: yep, that's the problem - opie indeed could use cleanup not only in intergration, but in design. external qss startup is of course rigth thing, but given funky deps on other semi-services, it doesn't work good ;-\ May 03 18:49:06 polyonymous: dunno. as I say, plan is to run script, and script can bother with such stuff. May 03 18:49:23 What would be in the script? May 03 18:49:35 I don't understand how would that help. May 03 18:49:52 polyonymous: "qss >log &" ? May 03 18:49:56 ah May 03 18:50:22 psokolovsky__, well, I think that's not needed in "production". May 03 18:50:49 I think this kind of debugging stuff can be better achieved by renaming qss and running it externally for debugging purpose. May 03 18:51:50 psokolovsky__, and, anyway, I'd propose no-builtin-qss-restart.patch. It will be shorter too :) May 03 18:52:04 polyonymous: see above - "no, there're should decend diagnostics means w/o any hacks" May 03 18:52:24 There will be no decent diagnostics means, anyway :) May 03 18:53:01 and, again, see above - debugging IS hacking and debugging is not the primary goal of development. For us it may be, but not for user :) May 03 18:53:55 polyonymous: didn't I "infect" you with idea and you'd go to move qte adhoc logging from libqpe-opie to libopie2 (where "opie" logging lives)? ;-) May 03 18:54:33 polyonymous: yeah. diagnostics is. so, debugging with renames is out. diagnostics with script is in ;-) May 03 18:55:39 well, I do not really see how is it better in production and that is the primary criterion... But it sure is better than what we have now. May 03 18:55:54 polyonymous: and that attitude is mistake of many commercial vendors (withink one well-known OS vendor). But we don't build terminators here. We'd known there's something wrong long before they will decide to conquere the Earth ;-) May 03 18:56:20 what attitude? May 03 18:56:56 "not part of production" May 03 18:57:40 psokolovsky__, wait, what about autostarting qss with -nodaemon? May 03 18:58:25 Well, I somewhat agree with you on this one. May 03 18:58:30 polyonymous: autostarting where? and I answered - qss.sh May 03 18:58:43 psokolovsky__, nah, in opie-taskbar. May 03 18:58:47 qpe that is. May 03 18:59:23 polyonymous: yes, current idea is to make opie-taskbar run qss.sh. sounds good? May 03 18:59:54 psokolovsky__, sounds acceptable. But I was thinking about adding it to qpe, instead of wrapper script. May 03 19:00:56 polyonymous: bit it was in qpe, undiagnostable. I offered you - tell me what's wrong with it on pocketpcs/palms. have answer? May 03 19:01:58 psokolovsky__, you know already I have no pocketpcs/palms. Well... why is undiagnostable? Where does the output go when run in qpe? May 03 19:03:40 polyonymous: /dev/null? and important thing from which legs of thsi stuff grow - we must make it such, that we - and not only we - could be able to diagnoze it w/o access to devices. May 03 19:04:29 psokolovsky__, who redirects it to /dev/null? You mean it goes there even if qpe is run with -nodaemon? May 03 19:05:26 polyonymous: it goes "somewhere", where you can't find it. didn't I mentioned "adhoc, inconsistent, and fragmented; was scarse" logging? May 03 19:05:48 What about solving exactly this problem? May 03 19:06:26 polyonymous: and at this I already joked and hinted ;-) May 03 19:06:47 Okay, I'll play around with it. May 03 19:07:14 polyonymous: it == consistent and centralized means of logging, I hope ;-) May 03 19:07:40 it == making sure that if you run qpe -nodaemon you get qss messages along with other crap. May 03 19:08:15 I doubt it produces any output, though... :) May 03 19:08:30 For me it's just silent unless it can't connect top qpe :) May 03 19:08:35 s/top/to May 03 19:09:41 polyonymous: well, you miss the fact that *that* already was done for me. we need general logging support now, not waste time patchinh here and there. ymmv May 03 19:11:11 psokolovsky__, I have nothing against logging as long as it doesn't prevent qss from starting up as a side effect :) Or what are you talking about? If you suggest that I just further develop opie, I don't think I'm ready to go for it :) May 03 19:11:57 Not unless I see where the whole opie thing goes. So far having my trivial patches sitting there for ages doesn't really encourage further enhancements :) May 03 19:12:27 polyonymous: rejigger logging and clean up machine support are two things which would be required to get OPIE to the decent state. note, I even don't mention unit tests ;-) May 03 19:13:19 psokolovsky__, well, you're talking from opie's POV. And from that perspective you're absolutely right. But we're on #oe now :) May 03 19:13:40 polyonymous: I fully agree. But for me - I subscribed to maintain opie in OE, and I want to being able to do that, not waste days of my time on each semi-trivial issue. May 03 19:14:06 polyonymous: nope, I speak exactly from OE perspective ;-) May 03 19:14:49 from OE perspective we want to get opie running on as many devices as possible. Well, the usual thing - world domination :) May 03 19:15:05 aim of OPIE in OE - provide well-ingrated system and easy support for new machines. w/o those 2 thinsg above, it's firefighting, not maintenance May 03 19:15:11 hi, all! May 03 19:15:26 slapin_nb: hello, lazyboy! May 03 19:15:29 about that commit access, again... May 03 19:15:41 psokolovsky__, yes, but that's in fact opie issue, not oe. May 03 19:15:53 psokolovsky__, btw, I think I finish that thing tomorrow. May 03 19:15:56 I do not mind enhancing opie if I see where it's headed, of course. May 03 19:16:15 slapin_nb: *What* thing? Let me dream!! ;-D May 03 19:16:45 psokolovsky__, m-k applet, do you still remember it? :) May 03 19:17:02 psokolovsky__, or that's irrelevant yet? May 03 19:17:30 speaking of commit access... :) May 03 19:17:31 * slapin_nb got some time for some huge development task, btw May 03 19:17:40 polyonymous, yes? May 03 19:17:55 slapin_nb, nah, that remark wasn't exactly for you :) May 03 19:18:09 What's with m-k applet, btw? May 03 19:18:14 polyonymous, :( May 03 19:18:34 slapin_nb, I didn't mean to offend you. May 03 19:18:36 polyonymous, that's psokolovsky__ to discuss whole idea May 03 19:18:45 ah ok May 03 19:18:52 psokolovsky__, May 03 19:19:08 wb May 03 19:19:33 psokolovsky, May 03 19:19:36 these mips routers do hang sometimes, you know... May 03 19:19:40 slapin_nb: yep, I just didn't even try to ping you about it, to not be put down! well, you're cool! May 03 19:20:26 psokolovsky, I got time now, so I'm going to flush my TODO, and this one is near top of it. May 03 19:21:11 psokolovsky, so I ask if it's still needed May 03 19:21:22 slapin_nb: cool, thanks. on my side, I only cleaned up my older patches for mb-kbd, and put stuff in hg. what's left is exactly to use results of your applet's work ;-) May 03 19:21:37 slapin_nb: absolutely and desperately!! May 03 19:22:10 psokolovsky, ok May 03 19:23:03 any commit access possibilities for me, btw? (I mean OE.dev) May 03 19:23:59 slapin_nb: well, collect your bug submissions and send list to koen/hrw ;-). I'd be glad to vote for you ;-) May 03 19:24:42 psokolovsky, what was the outcome of my voting, if this what you'd call voting, btw? :) May 03 19:25:14 polyonymous: I'm not core developer, so have no idea of such questions May 03 19:25:23 psokolovsky, ok, thanks! May 03 19:25:52 polyonymous: in your place, I'd waite few days more, and send mail to those folks asking for commit, referncing that oe-devel topic May 03 19:26:07 psokolovsky, okay, just wondering. I'm quite content with submitting bugs, but now that I have quite a few some of which are definitely safe to commit, it would make sense. May 03 19:27:03 polyonymous: I may only agree. the number of submissions increases, and we need more committers to keep up May 03 19:27:17 psokolovsky, They're well aware, as hrw said, "speaking of giving commit access to polyonymous" before proposing the other dev for commit access :) Well, I'm not in a hurry anyway - I'd have to learn mtn better. Now I can live with my knowledge :)) May 03 19:28:14 how does bitbake become aware of new package versions, and recompile when a newer version of a package is available for an image/task? May 03 19:28:15 polyonymous: well, just keep in mind, that you should be proactive ;-) May 03 19:28:43 psokolovsky, or active at the very least, I know. That's always my problem :) May 03 19:28:56 xuumbi: latest available version is used, unless masked/pinned. how? by scanning all versions ;-) May 03 19:29:46 polyonymous: well, you're active regarding bugs submissions, now be ready to calmly nag OE maintainers ;-) May 03 19:30:24 psokolovsky: as an experiment I tried changing "r0" to "r1" in my .bb file, but when rebuilding my image it doesn't see the change and rebuild the package May 03 19:30:47 psokolovsky: so then I changed the version number of the .bb itself, and that didn't get picked up either :( May 03 19:30:52 psokolovsky, I prefer patching to nagging :) before I go for two weeks to Moscow, I don't think I'll be pushing it myself. It would be silly - to get access and immediately get off :) May 03 19:31:07 xuumbi: it should - PR's are almost never pinned. May 03 19:31:34 psokolovsky: ok I'll dig deeper, thanks May 03 19:32:08 xuumbi: try to build exactly that recipe as initial measure, not the whole image May 03 19:33:55 psokolovsky: ah, ok, when bitbak'ing the package itself the new version does get picked up May 03 19:34:23 psokolovsky, http://rafb.net/p/P99pJD32.html - what about this then? :) May 03 19:34:58 psokolovsky: I was looking for an easy way of checking to see if a package had a newer version, then automatically rebuilding it when generating a new image, I guess I'll have to write a script for that... May 03 19:35:04 polyonymous: that's kinda cool, real unix way ;-) May 03 19:35:13 psokolovsky, worksforme :) May 03 19:35:26 Maybe it should be limited to some finite amount of iterations May 03 19:35:50 like for attempt in 0 1 2 3 4 5 6 7 8 9 a b c d e f ; May 03 19:36:12 xuumbi: well, it should work with image too, of course, it's just recipes for images should be done right. use existing gpe-image, opie-image as templates May 03 19:36:32 polyonymous: works as in tested? May 03 19:36:45 psokolovsky, this is a copy'paste from ssh to Z :) May 03 19:37:06 nice! please submit patch ;-) May 03 19:37:16 yup. Will attach it to the sound bug. May 03 19:40:50 Why isent libgcc.so installed in the imegaes anymore? I have to add it manually. May 03 19:41:53 goxboxlive, have you had rpath failure on gcc-cross? May 03 19:42:14 no May 03 19:42:33 should i? How do i do that? May 03 19:42:44 goxboxlive, ah, are you talking about binary images? May 03 19:42:53 or do you bitbake yourself? May 03 19:43:05 Yes May 03 19:43:24 if 'yes' was about binaries, then I have no idea :) May 03 19:43:26 I am talking about ansgtrom-images May 03 19:43:55 it isent installed in console-image or openmoko-image. Haventtried opie yet . May 03 19:44:03 I have started with a fresh image today May 03 19:44:26 dunno about images. I know what could make me end up without half of gcc in my own build. But I doubt it's in "official" binaries. May 03 19:44:40 ok May 03 19:44:56 hmm... haven't tried opie? But there's no opie image available? May 03 19:47:19 yes there is May 03 19:47:34 bitbake opie-image (voila) May 03 19:47:51 ah, so you DO bake it yourself, not talking about binary images for download. May 03 19:48:13 goxboxlive, well, are you absolutely sure you didn't have failure on gcc-cross which you had to restart? May 03 19:48:29 hmm that might be yes May 03 19:48:38 goxboxlive, then, that's it. May 03 19:48:38 should i rebuild it? May 03 19:48:48 it will fail again :) May 03 19:49:01 so, wath to do then? May 03 19:49:11 goxboxlive, I had to comment one 'return False' in insane.bbclass to make it non-fatal. May 03 19:49:36 ok May 03 19:49:37 thx May 03 19:57:14 psokolovsky, I attached the patch, but forgot to checke the 'patch' box. Hope, you won't have me resubmit :) May 03 19:57:42 polyonymous: you can edit attachment properties after submit ;-) May 03 19:57:47 nevermind, it's changable May 03 19:57:51 yeah, I know. May 03 19:58:03 I believe at some point it wasn't possible, though :) May 03 19:58:19 Okay, it's in 2211 now. May 03 20:00:27 thanks! May 03 20:00:36 you're welcome :) May 03 20:01:12 I'm afraid 16 seconds aren't enough, though... May 03 20:02:05 goxboxlive, polyonymous: if insane failed, make sure you rebuild the package from start (first -c clean, then build) May 03 20:02:06 psokolovsky, or there's another problem... maybe the socket is left after reboot - don't commit yet. May 03 20:02:23 likewise, it won't help, it will fail again :) May 03 20:02:42 likewise, unless you torture insane itself, that is. May 03 20:02:42 Yes, but not with the return commented out. May 03 20:02:51 yeah. May 03 20:03:08 and yes, in this case you'd better -c rebuild it. May 03 20:03:18 Ah ok, it will fail again now every time? good. May 03 20:03:33 likewise, no, no, only after clean. May 03 20:03:43 Wish it would fail consistently. May 03 20:04:00 Me too, the current approach is not deterministic. May 03 20:04:13 quite deterministic, but I don't like the determination :) May 03 20:04:54 if it now fails on a package, and you issue the same bitbake again, will it fail again? May 03 20:05:33 likewise, no. That's the determination I don't like. May 03 20:06:13 I would expect something less predictable from nondeterministic approach that is. May 03 20:07:30 polyonymous: yes, that's the issue I'ld like to fix first. Either never fail (warn only), or fail every time. May 03 20:07:47 likewise, I don't think we're in any disagreement here :) May 03 20:08:01 polyonymous: which one would you prefer? May 03 20:08:23 likewise, I'd prefer gcc-cross fixed :) May 03 20:08:47 likewise, if I knew how to do it I'd prefer fail consistently. Since I don't - I prefer warn-only :) May 03 20:08:53 gcc-cross is of our least concent, it does not arrive on the target. May 03 20:10:02 likewise, partially, it does. And failure to build it prevents the whole thing, anyway. May 03 20:10:50 koen: I desperately need a working config for a buildable ARM EABI BE image :-/ Now perl won't build for me. I wonder if I have some host-deps or something. May 03 20:11:05 polyonymous: Replace if bad_dir_test in line: by if bad_dir in line: will at least pass gcc-cross for the moment. May 03 20:12:01 likewise, well, I'm content with warn behaviour I have now, so I'd rather not mess with it and move on to something more productive :) May 03 20:12:07 koen: could you please show me the config that built the uploaded EABI BE image for you? May 03 20:12:15 polyonymous: ok May 03 20:14:45 likewise: remove 'gdb' for debug apps, bitbake angstrom-console-image May 03 20:14:49 s/for/from/ May 03 20:15:08 likewise: and I removed all !5.8.8 perl versions May 03 20:15:54 (mkdir packages/obsolete/perl ; mtn add packages/obsolete/perl ; mtn mv -e *5.8.4* *5.8.7* ../obsolete/perl) May 03 20:23:04 koen: ah, that explains a bit. But shouldn't we just be simply able to remove the dependency on perl? Or is that the task-* split-up in several *.bb you mentioned? May 03 20:23:09 whoops, too late May 03 21:13:25 polyonymous: I think you can consider yourself approved. I recollect thumbs up from psokolovsky, hentges, koen and me (maybe more). No objections. You need to create your keys and send them to both mickey and koen. May 03 21:13:48 If you are indeed not approved, they will let you know ;-) May 03 21:15:21 Laibsch, okay, will do. @openembedded.org from the phrasebook doesn't really imply @openembedded.org? May 03 21:15:31 yes it does :) May 03 21:16:08 Crofton, but I don't have @oe.org address May 03 21:16:15 We know May 03 21:16:46 Umm... would you elaborate a bit on it so that it makes sense to me? :) May 03 21:16:48 I am not sure why it is that way, but I am pretty sure that is how it is May 03 21:17:00 Hmm.. May 03 21:17:23 It's not that I object it, but I don't quite understand it either. May 03 21:17:42 me niether May 03 21:18:09 that makes me feel better, of course :) May 03 21:18:25 I am crofton@openembedded.org keywise May 03 21:18:54 But you have no corresponding email address? May 03 21:18:58 yes, this is just the key May 03 21:19:08 There sometimes no adresses behind it May 03 21:19:13 Me, for example May 03 21:19:27 Yeah, I understand. I thought the purpose of using email is to ensure no collisions. May 03 21:19:40 I think that is suboptimal since of course everybody assumes this is a mail address and might try to contact the committer there. May 03 21:19:55 Especially is this has worked with others in the past May 03 21:19:57 that too. May 03 21:20:15 But no, this is not always an email address May 03 21:20:16 Laibsch: same here... maybe email forwarding is possible? May 03 21:20:32 I don't know May 03 21:20:35 I am sure there is a cunning plan May 03 21:20:39 :) May 03 21:20:41 and I don't really care *too* much May 03 21:20:51 the plan is world domination May 03 21:20:55 right May 03 21:21:00 I think it just ruins uniqueness constraint. May 03 21:21:11 working email is of no real concern here. May 03 21:21:28 contact info is in maintainers May 03 21:21:33 mtn list keys will list one non-oe.org address May 03 21:21:34 but I think if I go for polyonymous I won't collide with anyone :) May 03 21:21:54 nslu2-linux.org that is May 03 21:22:05 I think there is another one May 03 21:22:07 no, way more May 03 21:22:23 8 keys May 03 21:22:29 * Laibsch has not checked lately May 03 21:22:42 mtn list keys|grep -v openembedded.org :) May 03 21:22:56 http://rafb.net/p/9Et0Kr79.html May 03 21:26:41 Well, if it's a custom here, I don't mind it. Just wanted to make sure, because it didn't make enough sense to me at the first glance. May 03 21:28:07 morning May 03 21:28:15 good one, I hope. May 03 21:28:29 Can we add somebody to the MAINTAINERS file who has no RW access to .dev but who is actively reporting and fixing bugs? May 03 21:28:59 being in maintainers implies some responsibility, doesn't it? May 03 21:29:17 It is not 100% clear what it implies May 03 21:29:40 The only thing certain to me is that you volunteered to take care of XY May 03 21:29:40 that's true :) May 03 21:29:49 polyonymous: yes, you at least fix what you break :-) May 03 21:29:59 There is also no screening really where you would have to pass some kind of test May 03 21:30:01 likewise, and vice versa :)) May 03 21:30:09 sssssh... May 03 21:30:31 Laibsch, there is a stress-test of actually doing some work. May 03 21:30:37 Laibsch: then why did I have to buy two rounds of beer? :-) May 03 21:30:38 likewise: Well, that would lead to the question of somebody "external" as MAINTAINER May 03 21:30:53 likewise: Where? May 03 21:30:59 I did not get any! May 03 21:31:00 just kidding May 03 21:31:17 likewise: Whatever it is you were proposing: DENIED May 03 21:31:19 ;-) May 03 21:31:45 Actually, we (undetermined group of OE ppl) did have a few beers in FOSDEM. May 03 21:33:07 I don't like beer. May 03 21:35:22 psokolovsky, I submitted the right patch. May 03 21:35:29 Now I can generate some keys :) May 03 21:37:39 I don't need to do anything with OE.mtn, do I? Just wonder why right before generating keys it states how to mtn db init OE.mtn... May 03 21:38:18 polyonymous: keys are saved in .monotone/ May 03 21:38:54 zecke, that's good. I was just thinking how do I preserve my private key if it goes to db :) May 03 21:39:06 polyonymous: it used to be in the db :) May 03 21:39:15 polyonymous: I think mtn 0.23 changed that May 03 21:39:20 Oh ... Exportable at least? :) May 03 21:39:27 Or just keep a backup of the whole thing? :) May 03 21:39:36 polyonymous: exportable :) May 03 21:40:00 that's better :) Well, not that it matters now that it goes to ~/.monotone. May 03 21:40:13 umm... it's ~/.monotone, not .monotone, I suppose? May 03 21:40:27 probably May 03 21:40:58 hmm.. why specify database for genkey ? May 03 21:41:41 dunno May 03 21:41:48 ok. just wondering May 03 21:42:35 zecke, I think it's outdated info. May 03 21:42:53 probably May 03 21:43:08 just looking at monotone's doc. May 03 21:43:21 I'm sorry for asking questions, just like knowing things I'm doing :) May 03 21:46:44 and email addresses in the phrasebook are correct, I take it? May 03 21:56:06 03pfalcon 07org.oe.dev * rc3da8ddf... 10/ (3 files in 3 dirs): opie-todo cvs: Fix unbreak-logging.patch May 03 21:56:10 03polyonymous 07org.oe.dev * r63574aab... 10/ (6 files in 3 dirs): May 03 21:56:10 qte 2.3.10: Fix lack of PAGE_* in latest linux-headers properly: use getpagesize() May 03 21:56:10 * Closes #2201. May 03 22:16:32 sent it. May 03 22:47:16 !oebug 717 May 03 22:47:17 * * Bug 717, Status: NEW, Created: 2006-02-23 01:16 May 03 22:47:18 * * Robert.Demski(AT)wp.pl: Include amule package bb files May 03 22:47:22 * * http://bugs.openembedded.org/show_bug.cgi?id=717 May 03 22:47:37 koen, we need to add SlugOS to VERSION field May 03 22:48:26 Crazy, 72 bugs fixed in the last week. May 03 22:48:35 Well done! May 03 23:06:50 Laibsch, how're your qemu experiments? May 03 23:33:38 polyonymous: how to make sure an old version of, e.g. glibc_intermediate, gets cleaned in tmp/staging May 03 23:34:16 xjqian, why me? :) I don't know. I think staging doesn't keep track of files staged. May 03 23:34:28 polyonymous: you mean the qem-native stuff? May 03 23:34:31 so, maybe rm -rf tmp/ is the way to go :) May 03 23:34:34 Laibsch, yes. May 03 23:34:42 Laibsch, I know it compiled, but did glibc build? May 03 23:35:08 polyonymous: I did not try. May 03 23:35:19 Laibsch, ah ok. I did and it failed (with that patch). May 03 23:35:20 I don't have the CPU cycles to spare at the moment May 03 23:35:31 polyonymous: OK, good to know May 03 23:35:33 qemu segfaulted on glibc. May 03 23:35:43 Please make a comment to that effect in the bug report May 03 23:35:46 polyonymous: you seems awake:) May 03 23:35:46 It would be better if it didn't fail, though :) May 03 23:35:59 (S) May 03 23:36:02 Later May 03 23:36:12 xjqian: just address the channel for general questions May 03 23:36:13 xjqian, awake and knowledgeable are different things :) May 03 23:36:27 Okay, Laibsch, I'll comment. May 03 23:36:37 xjqian: packaged-staging *might* do it but I don't know. I've never gotten the damn thing to work. May 03 23:48:49 JustinP: ok. thanks. My question is I'm not sure what's the best practice if a lib in the tool chain gets updated. How to make sure the old version is cleaned and not used anymore? May 03 23:51:02 xjqian: the right way would be for packaged-staging to work correctly and "upgrade" the packages in the stage environment May 03 23:51:07 xjqian: packaged-staging uses package management to install files to the staging folder(s) May 03 23:51:29 xjqian: like I said, though, it has never worked correctly for me. The author, koen, also doesn't seem interested in debugging the problem... May 03 23:53:53 JustinP: so the current practice for the devs are: cleaning up tmp, starting from a clean slate everytime anything important, e.g. glibc, gets an update? and for not so critical stuff, find a way (e.g. manually) to get by? Is my understanding correct? May 03 23:54:05 yep May 03 23:54:47 Crofton: thanks. I am all clear now8-) May 03 23:55:20 basically, when you have time rm -rf tmp May 03 23:55:23 and rebuild May 03 23:55:31 we would love someone else to work on packaged-staging...after koen's SoC project he seems to have abandoned it May 03 23:55:42 hopefully he has time this summer May 03 23:55:52 as far as I'm concerned it has never worked May 03 23:59:50 rm -rf is a good thing - you can test if the fresh build works :) May 04 00:00:12 do you guys think this should be in the wiki or documentation, etc May 04 00:01:04 what good open source project does nt have arcane lore passed on through irc channels May 04 00:01:06 ? May 04 00:01:51 ;-))) May 04 00:01:55 Night, everybody May 04 02:13:22 03lenehan 07org.oe.dev * rea56f69f... 10/ (4 files in 2 dirs): May 04 02:13:22 perl: Extract common functionality from cpan and cpan_build classes into a May 04 02:13:22 cpan-base class and update cpan_build to work with the new perl layout that May 04 02:13:22 was added with perl 5.8.8. May 04 02:13:27 03lenehan 07org.oe.dev * r72a2a6f0... 10/ (3 files in 2 dirs): May 04 02:13:27 perl/perl-native 5.8.8: Move the creation of the hostperl link in staging May 04 02:13:27 from the configure task in perl to the stage task in perl-native where it May 04 02:13:29 belongs - perl shouldn't be messing with the staged perl-native. May 04 02:13:33 03lenehan 07org.oe.dev * r3c345b9f... 10/ (3 files in 3 dirs): May 04 02:13:33 perl-native 5.8.8: Apply the patch from perl to stop the .packlist files May 04 02:13:35 from being installed. Since we use perl-native to do the cpan module May 04 02:13:37 installs we need to changed perl-native as well to stop cpan modules from May 04 02:13:41 getting .packlist files. This is a new patch since just the .packlist May 04 02:13:43 related part has been extracted from the larger patch. May 04 02:13:45 03lenehan 07org.oe.dev * r24286eb4... 10/ (10 files in 3 dirs): May 04 02:13:47 perl: Add the .debug directories that to FILES_${PN}-dbg in the May 04 02:13:49 cpan-base.bbclass, and then update the cpan modules to no longer manually May 04 02:13:51 specify this. Also remove references to the new removed .packlist files. **** ENDING LOGGING AT Fri May 04 02:59:56 2007