**** BEGIN LOGGING AT Tue May 01 02:59:57 2007 May 01 04:52:02 morn :) May 01 06:56:40 morning all May 01 07:03:15 rwhitby : The angstrom-minimal-image needs to be trimmed down a bit to fit in a 4MB flash May 01 07:04:17 The rootfs comes out at 3538944 bytes for me. So yes, a bit big for 4MiB total. May 01 07:04:40 rwhitby : which is constant with what you found on the nslu2 that has 8MB May 01 07:05:12 nslu2 can take up to about 6MB rootfs. May 01 07:06:38 the only image that was ok was the squashfs-lzma but my kernel could not load it May 01 07:07:23 cpio , which is even smaller failed with a "bad magic numbers" errors May 01 07:09:14 this is what i get with 2 different types of minimal-image i tried -> http://rafb.net/p/gITsW196.html May 01 07:17:54 is there a way to apply a patch only when building for uclibc and not glibc ? May 01 07:33:03 03koen 07org.oe.dev * rf9c3925d... 10/ (3 files in 3 dirs): May 01 07:33:03 linux-gta01: update to moko10 May 01 07:33:03 * should fix sound and bluetooth May 01 07:36:37 good morning all May 01 07:36:45 rwhitby: that's good to hear (minimal image) May 01 07:37:36 koen: should task-base.bb have a PROVIDES = "${PACKAGES}" in it? I couldn't set MACHINE_TASK_PROVIDE to "task-boot" without making task-base.bb PROVIDE task-boot ... May 01 07:37:58 s/MACHINE_TASK_PROVIDE/MACHINE_TASK_PROVIDER/ of course .. May 01 07:38:06 I don't think MACHINE_TASK_PROVIDER is suppossed to work like that May 01 07:38:24 (and PACKAGES should be in PROVIDES automagically iirc) May 01 07:39:07 Hmm. What's the recommended way to use bootstrap-image to get something smaller than task-base then? May 01 07:39:46 (I'm assuming bootstrap-image.bb is still the canonical "default" image creation recipe?) May 01 07:40:06 I stopped using bootstrap-image eons ago May 01 07:40:22 there seems to be an explosion of images ... May 01 07:40:36 all doing roughly the same thing May 01 07:40:42 yep May 01 07:41:24 should it be possible for all distros to use a common image creation .bb, with distro variables and tasks determining what actually goes into the image? May 01 07:41:29 "I have this new machine , with new distro open and open-image" was the guilty part in the past May 01 07:41:53 rwhitby: it should be possible, but might now be sensible May 01 07:41:57 koen: agreed, that's why I'm trying to do it correctly this time around instead of using angstrom-minimal-image ... May 01 07:42:18 s/now/not/ May 01 07:42:40 surely there's nothing "angstrom-ish" about angstrom-minimal-image.bb, right? May 01 07:42:59 there was till I removed ANGSTROM_EXTRA_INSTALL May 01 07:43:20 right, which can be done by a DISTRO_EXTRA_RDEPENDS, right? May 01 07:44:01 it could, but with that it wouldn't be minimal, right? :) May 01 07:44:03 So I'm now confused - what should MACHINE_TASK_PROVIDER be used for, if not to select which task forms the basis of your image? May 01 07:44:28 (since everyone currently sets MACHINE_TASK_PROVIDER to task-base) May 01 07:45:34 right now it should be hardcoded to task-base May 01 07:45:48 till someone documents valid (read working) options for it May 01 07:46:03 and what are some examples of what those options would be? May 01 07:46:14 (I thought an option was task-boot, for instance) May 01 07:46:18 atm only task-base and task-boot May 01 07:46:38 since a lot of embedded systems have 4MB what about having an image that fits that May 01 07:46:41 but you said before "I don't think MACHINE_TASK_PROVIDER is suppossed to work like that" May 01 07:47:04 I can see the "I set MACHINE_TASK_PROVIDER to task-wifi and it doesn't boot" problems coming May 01 07:47:10 I assumed you were saying that I shouldn't be using MACHINE_TASK_PROVIDER to swap from task-base to task-boot May 01 07:47:14 rwhitby: yes, sorry, I wasn't fully awake yet May 01 07:47:20 ok, no problem. May 01 07:48:32 so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size. Then I add other stuff to it using other tasks (like task-wifi). May 01 07:49:03 Good morning May 01 07:49:28 and if I do that, then I can use bootstrap-image.bb unchanged. May 01 07:49:53 Is there a different, preferred way to achieve the same result? May 01 07:51:13 I'm not sure if we should allow multiple entries in MACHINE_TASK_PROVIDER May 01 07:51:30 yeah, that's what I was concerned about. May 01 07:51:40 *lightbulb* May 01 07:51:45 that's what I meant before :) May 01 07:52:33 So I still need a "generic" image.bb, in which I can use MACHINE_TASK_PROVIDER to switch between task-boot and task-base only, and which has some other variable that I can use to then add stuff to the image on a distro-policy basis. May 01 07:52:43 I think DISTRO_EXTRA_R* is for things like that May 01 07:53:38 Hi! May 01 07:53:43 I do fear that the contents of -image can now vary wildly depending on what you set for MACHINE_TASK_PROVIDER May 01 07:53:45 hey keesj May 01 07:54:08 but DISTRO_EXTRA_R* is only added to task-base. There is (currently) no way I can use DISTRO_EXTRA_R* and angstrom-minimal-image.bb to add stuff to task-boot. May 01 07:54:24 ah, right May 01 07:54:39 what is MACHINE_TASK_PROVIDER really meant to be used for? May 01 07:54:57 to distinguish between task-bootstrap and task-base May 01 07:55:22 does task-bootstrap still exist? May 01 07:56:00 it is easy to assume gcc and glibc proviced? May 01 07:56:05 rwhitby: I hope not May 01 07:56:25 koen: so MACHINE_TASK_PROVIDER has no current reason for existence then? May 01 07:56:39 keesj: like http://www.openembedded.org/user-manual&dpage=commonuse_prebuilt_toolchain ? May 01 07:56:54 (and no definition of what it should be used for if it did have a current reason for existence) May 01 07:56:58 rwhitby: not that I know off, but your task-boot suggestion would make sense May 01 07:57:05 yes! May 01 07:58:21 <__blue119__> Hi Dear all May 01 07:58:22 koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something? May 01 07:58:44 (since it doesn't have anything to do with MACHINEs) May 01 07:59:06 nor with BOOTSTRAP May 01 07:59:24 ok, so IMAGE_FOUNDATION_TASK then? May 01 07:59:26 something like DEFAULT_TASK_PROVIDER? May 01 07:59:47 yep, DEFAULT_TASK_PROVIDER floats my boat. May 01 08:00:18 <__blue119__> could anyone help me <(_ _)>? May 01 08:00:20 do you want to write an RFC for that? May 01 08:00:25 koen: is there a reason why angstrom-minimal-image has a DEPENDS on task-base but RDEPENDS on task-boot? May 01 08:00:42 (and does it work for you if you change task-base to task-boot in the DEPENDS?) May 01 08:01:35 I ran into the provides problem you mentioned and was too lazy to debug that May 01 08:02:12 ok, so you worked around it there, and I worked around it by setting PROVIDES to ${PACKAGES} in task-base.bb May 01 08:02:46 yes May 01 08:04:44 koen: here's a reason for MACHINE_TASK_PROVIDER/DEFAULT_TASK_PROVIDER to accept multiple packages - for mokoslug, I want to set DEFAULT_TASK_PROVIDER to task-boot, but for the nslu2 machine only, I want task-boot *and* sysconf. May 01 08:05:16 (so that the network comes up out of first boot correctly, since the nslu2 has no console you can use to set the network info) May 01 08:06:37 <__blue119__> when i build gpe-image, it occur error whcih libxdamage_X11R7.1-1.0.3.bb be compiled May 01 08:10:28 <__blue119__> i look over error log as if con't find X11.h, but I do not find libx11 in org.openembedded.dev May 01 08:11:16 rwhitby: it's a reason, but a very bad one May 01 08:15:08 mroning May 01 08:15:59 <__blue119__> i don't know how to result the problem that someone can tell me how to do. May 01 08:16:22 Hey XorA May 01 08:17:21 hey sirfred May 01 08:18:11 If someone is interested, I've created recipes for o-hand sato gtk-engine, theme and matchbox theme, as bug 2182 May 01 08:18:48 koen: RFC sent. May 01 08:19:15 koen: I specified in the proposal that DEFAULT_TASK_PROVIDER take a singular task value. May 01 08:20:10 rwhitby: yes, otherwise we end up with another task-bootstrap like variable that includes everything + the kitchensink May 01 08:20:35 So now I need to write a "generic-image.bb" which uses DEFAULT_TASK_PROVIDER, MACHINE_EXTRA_TASKS, and DISTRO_EXTRA_TASKS. May 01 08:21:12 sounds like a plan May 01 08:21:32 koen: you've always said that the distro.conf sets policy. should there be any policy in an image.bb file? May 01 08:21:54 rwhitby: that's a very good question :) May 01 08:22:09 (i.e. what characteristic should differentiate one image.bb file from another?) May 01 08:23:05 currently, most of the existing image.bb files seem to be "-image.bb = task-base + task-" May 01 08:23:44 Is that basically how it is supposed to be? May 01 08:25:45 03koen 07org.oe.dev * r6f521003... 10/ (3 files in 3 dirs): xtscal: Sharp seems to use Dogname instead of DOGNAME for newer models May 01 08:27:04 rwhitby: I'm not aware of anyone putting any thought into that May 01 08:27:45 So there is no definition of how distro, task and image should be differentiated to achieve an intended result/ May 01 08:27:56 s|/|?| May 01 08:28:06 koen: does awk have a toupper/tolower command, it might make more sense to normalise all names :-) May 01 08:29:03 rwhitby: we have a pretty good picture what goes into distro and machine, but beyond that..... May 01 08:29:09 XorA: right May 01 08:30:00 i.e. whether it is better to have a mokoslug.conf which includes angstrom.conf and then sets DEFAULT_TASK_PROVIDER differently, from which you can build a generic-image.bb to get what you need; or whether one should just use angstrom.conf directly, and put the differences in task-mokogateway and mokogateway-image.bb ? May 01 08:30:51 ok, I gotta run to catch a bus home, but my dircproxy will keep logging this for me to read (and respond to) in about an hour. May 01 08:31:01 I'm allergic to 'distros' that just include another distro May 01 08:31:04 but that's just me May 01 08:33:01 well, in this case I include angstrom, and then change some policy that I don't agree with. May 01 08:34:00 (and no, that's not an attempt to start an argument. there may or may not be good reasons to disagree on policy in this case, but there will always be reasons to have different policy in the general case) May 01 08:41:07 I had a srange problem. I was trying to compile some stuff, but it failed. I saw there where some updates to GLIBC for couple of days ago, and it seems like wireless.h is missing to defienes. Like #include and #include . After i dadded it to the wireless.h it compiled. May 01 08:45:54 goxboxlive: I had the same problem, and even opened a bug. May 01 08:46:12 sifred: Great, then it is beeing taken care of. May 01 08:46:28 goxboxlive: But someone said that it worked for him, so I was confused. I thing I didn't have that problem on angstrom May 01 08:47:28 goxboxlive: bug 2095 May 01 08:47:46 goxboxlive: It happened to me for openzaurus distro May 01 08:47:47 sirfred: Strange, i talked to another person and he had the problme he self when i tried to build a opie image (distro Angstrom). I was trying to compile Opie2 (using crosscompiler in OE) May 01 08:48:33 goxboxlive: Perhaps the patch could be any useful to you May 01 08:48:43 sirfred: But he also told me that a console image wherent afected of it, just the Opie image. He didnt tried out x11 though May 01 08:49:08 sirfred: I just added the two defines and it compiles for me now. May 01 08:49:34 And now, the compilation is finished. Have to try it out. May 01 08:50:06 +#include May 01 08:50:06 +#include May 01 08:50:06 #include May 01 08:50:11 goxboxlive: That was my patch. May 01 08:50:28 The same you did, I see. May 01 08:51:13 yes May 01 08:56:16 Hmm, recent gpe-mini-browser svn versions doesn't seem to work. May 01 08:56:45 I write an url, hit enter and it just sits in front of me, eating all my cpu May 01 08:59:37 Was someone able to build recent mozilla minimo on oe? Impressions? May 01 09:01:12 not me :) May 01 09:01:14 sirfred: if you copy the crap I did for firefox minimo should build May 01 09:01:21 maybe minimo .2 stands a chance of compiling May 01 09:01:37 sirfred: I managed to get it to build a while ago, but then I got disgusted at the really crappy code quality of mozilla May 01 09:03:22 I tried bitbake minimo and failed in what seemed to be a confusion between host and target libraries May 01 09:03:40 But curiously, their web page recommends oe to build it. May 01 09:03:58 They say to run just "bitbake minimo" May 01 09:04:37 sirfred: dougt@meer.net for all minimo problems :) May 01 09:05:38 Well, it was that I would like to have a web browser in the zaurus. But I think I'm going back to gstreamer land, more interesting. May 01 09:06:05 NOTE: package firefox-2.0.0.3-r1: task do_compile: started May 01 09:06:39 Perhaps the switch to angstrom (and so, NPTL) was good for gstreamer performance May 01 09:07:15 sirfred: mozilla code is allergic to EABI :-( May 01 09:07:37 probably beacuse they hardcode *fpa assumptions May 01 09:07:38 XorA: Uff, enough for me of this, so. May 01 09:07:56 koen: I managed to fix that thanks to pb_ patch, but it still segfaults somewhere else May 01 09:08:48 XorA: I wonder when the debian dudes are going to fix it for armel May 01 09:09:12 koen: firefox.. but what is the minimum amount of memory needed to run that? May 01 09:09:20 koen: 1Gb? May 01 09:09:28 2Gb May 01 09:09:44 koen: Well, I meant only visiting about:mozilla May 01 09:10:05 If you go for real pages, 2Gb could be short May 01 09:11:23 koen: no idea, bet I noticed there is no .deb last time I checked May 01 09:11:37 * XorA ran firefox on OpenZaurus May 01 09:11:59 * sirfred wonders on what is XorA running OpenZaurus May 01 09:12:06 sirfred: C860 May 01 09:12:15 XorA: 64Mb RAM? May 01 09:12:18 sirfred: with you accellerated driver firefox runs nicely May 01 09:12:25 XorA: Swap enabled? May 01 09:12:29 sirfred: nope May 01 09:12:32 XorA: Nice to hear that May 01 09:13:33 XorA: I've found an interesting thing about the overlay surface. If you place only in 8 pixel multiple places, it's more stable. May 01 09:14:28 sirfred: do you mean only on 0,8,16,24,32.... May 01 09:14:40 XorA: Yes. Sorry for my english. :-( May 01 09:15:04 XorA: I have a WIP xserver with that restriction. May 01 09:15:09 sirfred: no its fine, I was just checking I was reading it right May 01 09:15:20 sirfred: that is a very common restriction in overlays May 01 09:15:34 sirfred: so I would say upload the new patch when you are happy with it May 01 09:15:51 XorA: I will update the recipe. yes. May 01 09:16:06 Well, the patch, actually. :) May 01 09:16:34 XorA: I was experimenting with a mplayer gpe frontend, using the mplayer slave mode. May 01 09:16:40 * XorA wishes the 3200 had a W100 May 01 09:17:43 XorA: You mean the w3220 ? May 01 09:17:57 XorA: What's a 3200 ? May 01 09:19:24 sirfred: zaurus slc-3200 May 01 09:19:31 that has pxa270fb instead of w100 May 01 09:19:36 koen: And what chip is it wearing? May 01 09:19:39 Ah, ok. May 01 09:20:02 But there's some overlay support for that, true? May 01 09:20:10 yes May 01 09:20:20 So, what's the problem? May 01 09:20:30 Perhaps there's not an xv port? May 01 09:21:29 no, only a mplayer vo plugin May 01 09:21:31 Sure there's no less documentation than for the w100 May 01 09:21:44 I'm thinking about assalting ati headquarters and stole the docs. May 01 09:22:16 It's probably less dangerous that the amount of time I've passed looking at disassembled arm code. May 01 09:22:16 XorA: I had a talk with Justin Treon at ELC, and he said he doesn't have the time to work on pxa270 overlay May 01 09:22:29 (and we was jumping up and down on hwo great bvdd is) May 01 09:22:53 koen: we have working overlay May 01 09:23:07 XorA: but only in mplayer, right? May 01 09:23:29 koen: yes, but all I need is probably a day to merge that with sirfreds excellent work May 01 09:24:00 XorA: Humm, it seems you didn't take a look at it yet. :) May 01 09:24:07 koen: what I hadnt managed to figure out on my own was the magic sequence to get it turned on right, my overlay was a black square May 01 09:24:24 XorA: I'm thinking about rewriting some of the xv code. May 01 09:24:36 koen: now I have an example of how it is turned on right it should be easier May 01 09:24:54 who is Justin Treon? May 01 09:27:11 XorA: I was thinking that perhaps a mplayer recipe with just the xv vo driver could be nice, just to save some flash. May 01 09:27:38 Because now, it need some dependencies that are not actually used (libaticore, libw100,...) May 01 09:27:56 Well, at least if you want to use it on X, perhaps a new mplayer-xv package. May 01 09:28:10 sirfred: I was thinking of just removing aticore stuff from mplayer May 01 09:29:05 XorA: And leave libw100 ? May 01 09:29:19 sirfred: well the opie guys might want some video output May 01 09:29:28 XorA: And what about two packages? May 01 09:29:38 XorA: The opie guys are not interested in xv driver, I suppose. May 01 09:31:17 sirfred: pity mplayer doesnt have a plugin interfacve May 01 09:31:33 XorA: Yes, and who dares to add something to it... May 01 09:33:14 two packages would be fine by me May 01 09:33:17 XorA: But what's the problem in having two different packages? May 01 09:33:26 XorA: ok May 01 09:33:43 sirfred: just need to abstact stuff into mplayer.inc May 01 09:34:32 sometimes I think it would be nice to be able to loop a build in a .bb with different args/packages produced each time May 01 09:35:15 XorA: meta-bb !! May 01 09:35:53 XorA: like collie-kernels did? May 01 09:36:08 koen: did they? May 01 09:36:24 XorA: sort of May 01 09:36:38 it depended on all the permutation recipes May 01 09:37:30 foreach ARG in $ARGS; do_tasks(); done May 01 09:37:35 Since some time ago, /etc/init.d/gpe-dm seems to not store the right PID to perform correctly the 'stop' command May 01 09:38:12 It seems that someone is forking before expected, because the stored PID uses to be one less than the real one. May 01 09:40:46 Humm, looking at the source code, I see a if (! nodaemon) daemon(0, 0); after create_pidfile(). May 01 09:41:16 And that daemon call, I will bet it needs to fork. May 01 09:42:35 Looking at the manual page, yes, it forks. So, I think the create_pidfile should be moved after daemon. May 01 09:47:28 * rwhitby returns May 01 09:47:38 koen: so to change policy, but remain binary compatible with Angstrom, how else should I do it instead of including angstrom.conf in mokoslug.conf and then overriding what needs to change (especially when there is no -= operator in bitbake yet) ? May 01 09:48:11 rwhitby: I didn't say it was wrong, just that I'm allergic to it May 01 09:48:49 ok, it's good to understand that difference, cause you react the same way in both cases :-) May 01 09:50:12 I've learnt not to copy and global replace on conf files, and I've learnt not to add lots of new DISTRO_FOO variables to conf files. the only option left is include and override standard variables. May 01 09:50:37 (assuming it can't be done in the "parent" distro, like the -= case) May 01 09:50:47 rwhitby: http://rafb.net/p/nnypQR86.html May 01 09:50:52 (read around the dutch) May 01 09:51:05 * koen expects a working EABI/EB tomorrow May 01 09:52:04 ok, I will re-check arm-kernel-shim at that point, cause I truly think I remember seeing the truncation problem on armel too for arm-kernel-shim cmdline processing. May 01 09:58:58 Hmm, that seemed to be the reason, I've delayed the create_pidfile after daemon() and it works fine now. May 01 09:59:14 I've opened a bug in the gpe bugtracker. May 01 09:59:53 sirfred: thanks May 01 10:00:01 florian_: np May 01 10:00:35 sirfred: the fix in svn already for a while i need to make a new release May 01 10:01:03 florian_: I've also seen that the higher available version in the bugtracker is 0.48 May 01 10:01:18 florian_: And I'm using 0.50 May 01 10:01:49 sirfred: right, i need to run the script that creates the versions again May 01 10:01:51 florian_: I was tempted to check the svn code, but was too lazy. May 01 10:03:09 sirfred: right, the problem was quite obvious and trivial to fix... May 01 10:03:32 florian_: Yes, even easier than browsing the svn. :) May 01 10:07:01 sirfred: indeed May 01 10:09:03 03hrw 07org.oe.dev * r57d2b2fc... 10/ (1 packages/xorg-lib/libice_1.0.3.bb): libice: added 1.0.3 May 01 10:09:07 03hrw 07org.oe.dev * r1e0fdf5f... 10/ (1 packages/xorg-lib/libxaw_1.0.3.bb): libxaw: added 1.0.3 May 01 10:09:11 03hrw 07org.oe.dev * r0a8ed31e... 10/ (1 packages/xorg-lib/libxfont_1.2.8.bb): libxfont: added 1.2.8 May 01 10:09:15 03hrw 07org.oe.dev * r0bacc074... 10/ (1 packages/xorg-lib/libxi_1.1.0.bb): libxi: added 1.1.0 May 01 10:09:19 03hrw 07org.oe.dev * r0ebfce61... 10/ (1 packages/xorg-lib/libxinerama_1.0.2.bb): libxinerama: added 1.0.2 May 01 10:09:24 03hrw 07org.oe.dev * rc8eec3ec... 10/ (1 packages/xorg-lib/libxrandr_1.2.1.bb): libxrandr: added 1.2.1 May 01 10:09:32 03hrw 07org.oe.dev * ra3f21934... 10/ (1 packages/xorg-lib/libxt_1.0.5.bb): libxt: added 1.0.5 May 01 10:09:43 03hrw 07org.oe.dev * r0a229750... 10/ (1 packages/xorg-lib/libxv_1.0.3.bb): libxv: added 1.0.3 May 01 10:09:56 03hrw 07org.oe.dev * r02fe531a... 10/ (3 files in 2 dirs): mkfontdir: added 1.0.3 May 01 10:10:04 03hrw 07org.oe.dev * r84d6d7cf... 10/ (1 packages/xorg-app/xdm_1.1.4.bb): xdm: added 1.1.4 May 01 10:10:09 all should build. did not tested on device. some need versioned dependencies to build (xrandr for example) May 01 10:10:14 bye all - have a nice day May 01 10:10:17 03hrw 07org.oe.dev * rb034fcc5... 10/ (1 packages/xorg-app/xrandr_1.2.0.bb): xrandr: added 1.2.0 May 01 10:10:25 03hrw 07org.oe.dev * r44641351... 10/ (1 packages/xorg-app/xrdb_1.0.3.bb): xrdb: added 1.0.3 May 01 10:10:32 03hrw 07org.oe.dev * r59404f96... 10/ (1 packages/xorg-driver/xf86-input-evdev_1.1.5.bb): xf86-input-evdev: added 1.1.5 May 01 10:10:37 03hrw 07org.oe.dev * rf1e95d09... 10/ (1 packages/xorg-driver/xf86-input-keyboard_1.2.0.bb): xf86-input-keyboard: added 1.2.0 May 01 10:10:45 03hrw 07org.oe.dev * r1f5dfd28... 10/ (1 packages/xorg-driver/xf86-input-mouse_1.2.1.bb): xf86-input-mouse: added 1.2.1 May 01 10:10:51 03hrw 07org.oe.dev * r81b96598... 10/ (1 packages/xorg-driver/xf86-video-siliconmotion_1.5.1.bb): xf86-video-siliconmotion: added 1.5.1 May 01 10:49:55 hey zecke May 01 10:50:32 ho May 01 11:32:07 morning all May 01 11:33:15 03bero 07org.oe.dev * r33db0448... 10/ (4 files in 3 dirs): May 01 11:33:15 perl-native: Patch perl's makedepend.SH to work with gcc 4.2. Shouldn't be May 01 11:33:15 needed for perl since it doesn't run makedepend.SH. Closes #2168 May 01 11:37:27 morning May 01 11:55:47 03lenehan 07org.oe.dev * r147dd5eb... 10/ (3 files in 3 dirs): (log message trimmed) May 01 11:55:47 perl 5.8.8: Allow perl to build when using an external toolchain. May 01 11:55:47 This is done by allowing gcc to search for errno.h by itself instead May 01 11:55:47 of manually searching for. The manual search was looking in May 01 11:55:47 STAGING_INCDIR and that's not where the external toolchains headers May 01 11:55:47 are. This whole test is really for handle other compilers and May 01 11:55:51 operating systems, so the simple make gcc do itself should be fine May 01 12:13:19 ~lart htc universal people May 01 12:13:19 * ibot send killer squirrels to attack htc universal people May 01 12:14:10 03koen 07org.oe.dev * r53e01bb2... 10/ (3 files in 3 dirs): May 01 12:14:10 xtscal: reinstate tr toupper filter so everything works again. May 01 12:14:10 NOTE: it would be nice if machine maintainers run the script on their device May 01 12:14:10 instead of pasting a line from /proc/cpuinfo. If the htc universal people had May 01 12:14:10 done so, they would have noticed everything comes up in *uppercase*. So xtscal May 01 12:14:10 wasn't broken May 01 12:18:53 Hmm.. bitbake's 1.8.2's parsing of all RDEPENDS in task-base, including those that aren't being used, is annoying. I now need to pull in several hundred more packages (which are not going to be used) just to parse that file ;( May 01 12:22:17 v8jlene: that's the side-effect of needing to now how to rename libraries when using debian.bbclass May 01 12:23:36 and indeed very annoying May 01 12:24:31 koen: Ok. I guess I don't re-parse all that often. I've gone from have 800 recipes to 4500 so parse - definitely a bit slower! (I just added them all since figuring out what I needed isn't a job for now). May 01 12:24:51 anyone know much about rpath? May 01 12:24:59 I am looking at gcc-cross May 01 12:25:48 Crofton|home: rule of thumb, all rpath's on linking are bad May 01 12:25:57 CoreDump|afk: only -rpath-link makes sense and is fine May 01 12:28:53 hmm May 01 12:29:04 I am trying to figure out where it comes from and how we can remove May 01 12:29:30 for example, this is from run.do_configure.22111 May 01 12:29:34 for gcc-cross May 01 12:29:46 export LDFLAGS="-L/home/balister/oe/tmp/staging/i686-linux/lib -Wl,-rpath-link,/ May 01 12:29:46 home/balister/oe/tmp/staging/i686-linux/lib -Wl,-rpath,/home/balister/oe/tmp/sta May 01 12:29:46 ging/i686-linux/lib -Wl,-O1" May 01 12:30:03 so rpath-link does not impact runtime? May 01 12:31:31 right May 01 12:32:12 is gcc-cross packaged and installed? if it is a sort of -native tool I would the rpath is okay for now as well May 01 12:32:27 well, the rpath should be okay for now, for packaged staging this would need fixing May 01 12:32:51 toolchain production is black magic to me May 01 12:33:37 Crofton|home: well, I assume the lib will be installed into that dir /home/balister/oe/tmp/staging/i686-lib. May 01 12:34:00 well, then insane shouldn't care about the RPATH May 01 12:34:48 Crofton|home: well, you might be right May 01 12:34:59 Crofton|home: I though only to be packaged files will be checked May 01 12:35:26 http://bugs.openembedded.org/show_bug.cgi?id=2152 May 01 12:35:31 Here is the bug report May 01 12:36:04 who are the toolchain gurus? May 01 12:36:27 The problem with rpath is we all know it is bad, but we aren't real good at fixing the problem :) May 01 12:37:15 bbl May 01 13:21:48 oe look very promissing. what feature will I first miss? what part of OE is ugly? May 01 13:22:41 you will miss the feature you need which isn't implemented, I guess. And the uglies part of OE is the one you dislike the most. May 01 13:24:15 how do I make a list of packages get built when I run "bitbake my-image", but not be dependencies of the resulting root file system? May 01 13:24:50 right now I have "export PACKAGE_INSTALL" setting a list of packages in my image .bb file May 01 13:25:27 but if I run "bitbake my-image" it's not building that list of packages first, so it can't find them when it tries to install them in the image May 01 13:26:16 I used to set DISTRO_EXTRA_RDEPENDS to my package list, but that made the packages dependencies of the root file system, so if I tried to remove them from the target I had to use "ipkg remove -force-depends" May 01 13:26:48 xuumbi, I'd guess you need RDEPEND in my-image.bb May 01 13:26:51 there must be an easy way to have a list of packages built during the image creation process May 01 13:27:03 hm. May 01 13:27:12 well, I haven't tried it yet :) May 01 13:28:02 polyonymous: yeah that would make sense... let me try May 01 13:30:25 hello all May 01 13:32:10 what I don't like is that I can't perform some actions because I am behind a firewall May 01 13:32:34 git and mtn just won't work :( May 01 13:32:59 for mtn I use a ssh tunnel , for git I carry my hd home May 01 13:48:40 was image_ipk renamed to image? May 01 13:49:32 gm May 01 13:50:25 likewise, for bug 2152, does it matter that RPATH exists May 01 13:50:35 doesn't gcc-cross run only on the build amchine? May 01 13:50:40 Is there a general guide to bitbake and the org.openembedded repository structure? May 01 13:51:09 I think I've exhausted the documentation but I feel as if there is a large gap between the docs and the implementation. May 01 13:52:43 Crofton|home: yes, it's no problem there, might even be desirable. However, I'm wondering what a target gcc and its lib looks like. May 01 13:53:11 can we fix insane.bbclass so it doesn't report the gcc-cross as an error? May 01 13:53:20 vervain: If that's true, complain here, or on the mailing list. May 01 13:53:40 Crofton|home: yes, about to do so (if I have my mtn key here... lemme check) May 01 13:53:53 ok May 01 13:54:01 that fixes one bug at leat :) May 01 13:54:26 I disabled insane.bbclass in my school machine so I can do OSK builds May 01 13:54:45 but at home I will leave it enabled and try to sovle problems as I can May 01 13:54:52 Crofton|home: "if bad_dir in txt May 01 13:54:55 'whoops May 01 13:56:49 Crofton|home: A bit of a workaround, but replacing "if bad_dir_test in txt:" by "if bad_dir in txt:" will only check against RPATHs that have "work/" in them, which skips the cross/ items AFAIK. May 01 13:57:04 vervain: feel free to ask questions. OE makes a lot of sense once you get your mind around it. But, in my experience this usually takes developers several weeks of working with it before this happens. May 01 13:57:54 cbrake: yes, but any comments vervain has now helps us to smoothen the learning curve, which is steep and too bumpy. May 01 13:58:37 likewise: if these newcomers would contribute to the documentation :) May 01 13:59:20 zecke|food: being unsure about how things work (which is common for all beginners here) often does not make on commit documentation fixes. May 01 14:00:36 unsure -> ask -> answer -> update documentation -> review -> unsure :) May 01 14:00:37 zecke|food: but I feel guilty about not having committed doc fixes myself. May 01 14:00:51 exactly :-) May 01 14:01:15 but most people do unsure -> ask -> answer -> unsure without giving back :) May 01 14:02:21 reading through the documentation, we do seem to be lacking in tutorial type documentation. Something that starts with simple concepts and gradually exposes the user to more advanced concepts. May 01 14:03:04 will Mickey's book accomplish this? May 01 14:03:23 I don't know May 01 14:03:33 it could May 01 14:05:05 * cbrake needs to get moving on his "intro to OE" articles" May 01 14:05:24 * zecke|food needs to do assignments May 01 14:06:49 Can I have a wiki account? May 01 14:09:00 keesj: Sure. http://www.openembedded.org/user/login May 01 14:09:11 Should have an option so sign up May 01 14:09:38 since when does one need an account for the wiki? May 01 14:09:41 you can edit the wiki without an acocunt May 01 14:10:55 I am willing to help with documentation but I'm trying to avoid re-inventing wheels. May 01 14:11:41 Laibsch can't find it May 01 14:12:22 I find myself often not knowing if my answer should lie inside OE, BitBake or on of the other projects GPE/Familiar/Etc. May 01 14:13:08 vervain: familiar is dead May 01 14:13:27 koen: The point, though, is still valid May 01 14:13:32 Is bb used on any other significant projects other than OE... perhaps that would give me mroe insight into bb. May 01 14:13:45 vervain: probably not, but it could be May 01 14:15:16 vervain: bitbake is general purpose and mainly handles things parsing bb files, managing variables, dependencies, tasks, and executing tasks. May 01 14:15:25 koen: Really - So no more development for H5500 etc... I still have one ;-) May 01 14:15:56 vervain: why so? May 01 14:16:05 vervain: h5xxx is supported by angstrom May 01 14:16:22 koen: Aha.. I didn't know that. May 01 14:17:01 hmm , I can edit the wiki , I just did not try before I ran "edit" , just pressed login and did not get an account. Ooops May 01 14:17:32 cbrake: I think I'll 'walk through' the bb process for say bootstrap-image from local.conf through and write down what I find... understanding what all get's pulled in and why is the part I'm missing. May 01 14:20:05 vervain: in a nut shell, the various *.conf files are combined to create a bunch of env variables (see /conf/bitbake.conf), and then bitbake parses *.bb & *.class files to come up with a bunch of packages to build and tasks to run. Dependencies determine what gest build and can be viewed by running running bitbake with the -g option and looking at the resulting *.dot files. May 01 14:22:49 cbrake: ya - I think it's the -g option that I need to start playing with more... May 01 14:22:59 This link http://www.openembedded.org/wiki/HowToCheckForExistingPackagesn seems broken. May 01 14:23:02 I guess OpenEmbeded is ready for a book! May 01 14:23:13 From: http://www.openembedded.org/wiki/DirectoryStructure May 01 14:36:15 where do want documentation contributions for the manual? May 01 14:36:24 (not the wiki but the manual) May 01 14:36:34 polyonymous: no luck, setting RDEPENDS in my image bitbake file doesn't work :( May 01 14:38:08 if anyone else can help... I'm trying to setup a custom image bitbake file that builds a list of packages, but doesn't make them dependencies of the resulting image May 01 14:43:45 keesj: check out the org.openembedded.documentation branch from mtn May 01 14:44:22 make your changes and attach the output of "mtn diff org.openembedded.documentation" to the bug tracker May 01 14:44:29 Let me know if you need help with that. May 01 14:45:45 Laibsch, are you bugs.*@rolf.*? ;-) May 01 14:46:08 thanks I will May 01 15:05:03 polyonymous: yes, thought you knew May 01 15:05:17 Laibsch, Yes, I guessed, but wanted to make sure. May 01 15:05:27 /whois May 01 15:05:32 For no apparent reason, just to complete the picture May 01 15:05:35 removes any doubt May 01 15:05:54 no, it doesn't. May 01 15:06:13 Indeed, it does not May 01 15:06:16 ;-) May 01 15:06:25 and better so. I never liked it May 01 15:06:36 Must have fixed that in the meantime May 01 15:06:53 Anyway, let me apologize for all my future submissions as well :) I mean, I'll try to be more specific, but I can't promise I will succeed :) May 01 15:06:54 * Laibsch values some privacyy May 01 15:07:36 notwithstanding, I think it's better that I continue submissions instead of just shutting up :) May 01 15:07:46 bugzilla usually has these steps lined out "What were you doing?", "what do you think should have happened", "what happened", etc. May 01 15:07:58 polyonymous: that is for certain May 01 15:08:29 Yes, I'll try. It's just that I think that patches are really self-descriptive, but you're right - you first read summary, not a patch. May 01 15:08:53 Laibsch, do you think I should also submit fixes for unsupported opie part of angstrom as well? May 01 15:08:59 But it would be nice if you sometimes stepped back and asked yourself "If I read this would I be able to understand what the other person was doing and what they were trying to achieve and failed"? May 01 15:09:14 Yes, I agree. May 01 15:09:20 opie is only unsupported in one person's mind May 01 15:09:33 Okay, then it won't hurt if I submit patches. May 01 15:09:35 It really is supported May 01 15:09:44 OK, it would be very nice if you did. May 01 15:09:54 No, it would be very nice if you did. May 01 15:10:18 My tree is dirty like hell, I even think maybe I should branch locally (guess mtn supports that, otherwise what's distributed about it:)) May 01 15:10:37 Okay, I'll go for yet another submission now :) May 01 15:11:04 polyonymous: "mtn ls changed" "mtn ls unknown" are of great help May 01 15:11:12 It keeps me sane May 01 15:11:17 Laibsch, yes, as well as mtn status May 01 15:11:44 I think mtn status makes more sense that mtn ls changed even. May 01 15:12:05 You can also use quilt to keep your OE tree "clean" when you need it clean May 01 15:12:25 * Laibsch checks "mtn status" May 01 15:13:05 Yes, but that you can do with any vcs, it doesn't take a distributed one. I think mtn should support local branches. I'm not familiar with mtn, but I guess it shares concepts with git which I use a lot. May 01 15:13:59 psokolovsky__: What were you trying to say with "consequently" in your last bug comment? May 01 15:14:39 Laibsch: consequently it's not really a libopie2 problem ;-). at least, not only it could break. May 01 15:14:49 polyonymous: Yes, it works. But I prefer KISS whenever possible. A branch was too complicated for me until now. May 01 15:15:04 Laibsch, one step at a time :) May 01 15:15:10 psokolovsky__: So what package is the problem in? May 01 15:15:17 Can you reassign? May 01 15:15:32 I mean update the summary? May 01 15:15:40 what is not libopie2 problem? Did I submit a patch for it yet? :) May 01 15:15:57 polyonymous: no May 01 15:16:09 !oebug 2193 May 01 15:16:10 * * Bug 2193, Status: NEW, Created: 2007-05-01 04:43 May 01 15:16:11 * * bugs.openembedded.org(AT)rolf.leggewie.biz: libopie2 fails do_compile for MACHINE="qemuarm" and angstrom May 01 15:16:12 * * http://bugs.openembedded.org/show_bug.cgi?id=2193 May 01 15:16:12 Laibsch, maybe I should. I have a patch for a wireless problem. May 01 15:16:20 Laibsch: no, I don't think reassign is need, the problem with linux-headers, or how it is called, apparently. I'm investigating. In the end, we'd of course patch libopie, not linux ;-) May 01 15:16:55 aha May 01 15:17:00 I have a patch for this problem. May 01 15:17:06 Not that I LIKE the patch... May 01 15:17:07 OK, as long as it works (which is my main concern (I am glad most devs around here are not like that)) May 01 15:17:24 * Laibsch makes polyonymous the "patch master" May 01 15:17:40 polyonymous: You are welcome to attach the patch to the BTS May 01 15:17:42 http://rafb.net/p/9XxJsw68.html May 01 15:18:06 Yes, that's a option. For the time being feel free to look at it. May 01 15:18:17 ah, no, this patch is ok. May 01 15:18:26 I've had the other patch which I don't like... May 01 15:18:28 polyonymous: I think you miss file://include.pro May 01 15:18:47 what do you mean I miss? It's there, isn't it? May 01 15:18:55 Is it? May 01 15:19:03 you mean in my patch? May 01 15:19:09 lines 34/35 May 01 15:19:11 I assumed it was added by you since it was not in the recipe May 01 15:19:19 OK, don't worry May 01 15:19:29 no, it was May 01 15:19:34 psokolovsky__: What do you think? May 01 15:19:37 the line is changed to add a \ at the end. May 01 15:19:47 Oh, right May 01 15:19:59 * Laibsch needs glasses in the end May 01 15:20:02 The uglier patch was to qte-mt, I think... May 01 15:20:18 Laibsch: I'm out of context, sorry May 01 15:20:31 polyonymous: Would you care to be "official opie maintainer" in angstrom? May 01 15:20:48 psokolovsky__: Just forget anything but the last line from me. May 01 15:21:25 Laibsch, I'm not sure if I will have time for it, but as long as I have time I'll do my best to contribute. May 01 15:21:27 psokolovsky__: What do you think about http://rafb.net/p/9XxJsw68.html, a patch to 2193 from polyonymous May 01 15:21:33 Laibsch: there's big urge to have second maintainer, that's presupposition for opie to actually be in angstrom May 01 15:21:59 psokolovsky__: You know there already *are* two maintainers May 01 15:22:05 You and me May 01 15:22:20 Some stuff is less actively being worked on. May 01 15:22:29 Laibsch, polyonymous: looks good, but needs to be submitted upstream ;-) May 01 15:22:46 psokolovsky__, I can submit it to both trackers. May 01 15:22:48 psokolovsky__: Commit locally until committed upstream? May 01 15:22:58 Laibsch: I'm glad you out it like that. let's let Koen know about that ;-) May 01 15:23:02 should I attach it to bugzilla? May 01 15:23:09 Laibsch: sure May 01 15:23:20 polyonymous: please do, for any patch ;-) May 01 15:23:28 will do. May 01 15:23:39 psokolovsky__: I (and others) have told him numerous times. But you know he only hears what he wants to May 01 15:23:42 and submit to mantis as well? May 01 15:24:47 polyonymous: yes, exactly, I'm sorry about that duplication, but that's what we have now. May 01 15:24:58 no problem. May 01 15:25:02 I attached it to bugzilla. May 01 15:25:29 polyonymous: and please-please submit all patche sto tracker - they will never be lost. because at any given time someone may be not around, or busy with sth else. May 01 15:26:02 psokolovsky__, I do, most of the time (poor Laibsch:)). May 01 15:26:33 ok ;-) May 01 15:27:02 polyonymous: you know about PR (the variable)? May 01 15:27:07 psokolovsky__, Is libopie2 considered 'core' ? May 01 15:27:11 Laibsch, yes :) May 01 15:27:19 OK May 01 15:27:28 I will commit your patch tonight May 01 15:27:29 But I think it only needs to be bumped when you add functionality fix. May 01 15:27:33 polyonymous: core of opie, yep, apparently May 01 15:27:45 I mean, if you already have it built, you don't need to upgrade. May 01 15:27:58 psokolovsky__, Ok. Just to make sure I submit it properly. May 01 15:27:58 polyonymous: when package would change May 01 15:28:30 psokolovsky__, yes, package. As in, e.g., ipk. But if you add a build fix, then what's the use of bumping PR? You can't possibly have older revision. May 01 15:29:35 polyonymous: is package contents or metadata change, bump PR. otherwise, ipkg won't notice new package, or at least, that it's in fact new package May 01 15:29:40 in fact, I think the patch should be submitted upstream to kernel, wouldn't it make sense for wireless to include type definitions? May 01 15:30:15 psokolovsky__, Exactly. And you don't need ipkg to notice the package if all you've done is fixed compile issues. May 01 15:31:12 polyonymous: Makes a lot of sense what you're saying May 01 15:31:22 I just increase it by default ;-) May 01 15:31:46 that shouldn't hurt much either. May 01 15:31:48 Which I think has merit - thinking of it May 01 15:31:50 polyonymous: well, maybe. but quoting Koen, "PRs are cheap - bump them!" May 01 15:32:23 polyonymous: Consider the person with an incomplete compilation? Unless they do -c rebuild or -c clean they might run into trouble May 01 15:32:41 psokolovsky__, That is also valid point. Doesn't invalidate mine, though. I think we can coexist with different opinions. At least as long as I'm not committing directly to tree :) May 01 15:32:46 so yes, they are cheap. And it does not hurt May 01 15:33:08 Laibsch, what you're talking about is something that bitbake should take care of, I think. May 01 15:33:17 polyonymous: well, you asked, that was just a suggestion ;-) May 01 15:33:44 psokolovsky__, Yes, it's nice to share opinions and broaden our views :) May 01 15:33:49 polyonymous: It probably does. But better safe than sorry May 01 15:34:16 There's nothing wrong with being sorry and being always safe is boring :))) May 01 15:34:26 :-D May 01 15:34:57 * Laibsch "bitbake libopie" r8 May 01 15:35:05 * Laibsch "bitbake libopie2" r8 May 01 15:35:23 I don't like mantis, in fact. :) May 01 15:35:50 here we are, failing opie-networksettings with the same wireless problem. May 01 15:37:33 polyonymous: no more changes to the patch you attached from the rafb.net stuff, right? May 01 15:37:57 Laibsch, no, that's the complete patch against .dev tree. May 01 15:38:42 and the patch for opie-networksettings follows shortly :) May 01 15:40:06 I have been seeing arm alignment problems on Angstrom builds. Anyone else seen that? I think it may be peculiar to Bluetooth? May 01 15:40:38 tnb: Marcel Holtmann said bluez really needs those unaligned accesses :( May 01 15:41:12 he noticed them as well on his neo1973 May 01 15:41:22 koen: hmm, I see. so we just ignore the messages? May 01 15:41:45 tnb: for the time being, yes May 01 15:42:44 koen: ok, thanks. May 01 15:44:36 v8jlene: where did perl-module-strict go? May 01 15:45:22 v8jlene: I moved 5.8.4 and 5.8.7 out of the way, and bitbake now complains nothing provides perl-module-strict (needed for automake) May 01 15:48:45 koen: deploy/ipk/i486/perl-module-strict_5.8.8-r9_i486.ipk, tmp/deploy/ipk/sh4/perl-module-strict_5.8.8-r9_sh4.ipk - so the module exists here May 01 15:48:49 v8jlene: ah, it looks like a dependency deadlock May 01 15:48:58 perl-module-strict_5.8.8-r9_armv5teb.ipk May 01 16:04:40 v8jlene: it seems like bitbake 1.8 needs some more info from the perl recipe May 01 16:05:07 v8jlene: I added PACKAGES_DYNAMIC="perl-module*", but I suspect that's the wrong way to fix it May 01 16:05:26 is BOOTSTRAP_IMAGE_RDEPENDS depreciated? May 01 16:05:39 xuumbi: yes May 01 16:06:09 koen: ok, looks like FirstProject needs to be updated... May 01 16:06:18 feel free May 01 16:06:19 how should "specifying package lists" be handled then? May 01 16:06:40 I'm happy to update it but I don't know the right procedure :) May 01 16:08:41 koen: "bitbake automake" works fine here with just the DEFAULT_PREFERENCE lines deleted. Bitbake 1.8.2. May 01 16:09:02 v8jlene: even when you remove the old perl recipes? May 01 16:10:54 koen: "No providers of runtime build target perl-module-data-dumper". What has the old perl got to do with the new one ;( May 01 16:11:01 google finds very little on BOOTSTRAP_IMAGE_RDEPENDS, I was hoping to find a mailing list entry or something explaining why it is depreciated, and what to use in its place... May 01 16:11:30 v8jlene: it probably specifies that it will build perl-module- May 01 16:12:02 e.g by having it in PACKAGES May 01 16:12:23 koen: Oh, old one has: PACKAGES_DYNAMIC = "perl-module-*" - which I don't have in the new one. Seems that applies to all modules called that regardless of what version is selected... May 01 16:14:35 koen: I presume PACKAGES_DYNAMIC is to tell it that those packages are dynamically generated. Adding that line into perl_5.8.8.bb fixes things. May 01 16:14:59 yes, that's correct May 01 16:15:10 although I'm known for abusing PACKAGES_DYNAMIC :) May 01 16:15:25 there's worse things you could be know for ;) May 01 16:23:07 03lenehan 07org.oe.dev * rc18c0af8... 10/ (1 packages/perl/perl_5.8.8.bb): (log message trimmed) May 01 16:23:07 perl 5.8.8: Fix to tell bitbake about the perl module packages. I'd left out May 01 16:23:07 the PACKAGES_DYNAMIC declaration for the perl modules. This declaration May 01 16:23:07 appears to be global though - so if either of the older perl versions exist May 01 16:23:07 it actually works - bitbake picks up the definition from the older recipes May 01 16:23:07 even though it isn't building them. This shows up as "No providers of May 01 16:23:11 runtime build target " errors where x is a perl module. Thanks to Koen May 01 16:27:42 v8jlene: I don't think it's global, OE desperately tried to build 5.8.7, which is why I removed those May 01 16:29:04 koen: With just the DEFAULT_PREFERENCE commented out here it just build 5.8.8... maybe it'd built 5.8.7 before is stopped it and deleted the DEFAULT_PREFERENCE lines.. ah, yes it had.. May 01 16:29:24 koen: Ok, all makes sense now. May 01 16:39:47 koen: what is the status of angstrom sdk builds? I tried to build meta-sdk and got QA errors. May 01 16:40:25 I managed to get an sdk 2 weeks ago, didn't look at it after that May 01 16:42:17 * cbrake finds display blanking is a constant source of annoyance for embedded systems ... May 01 16:42:50 cbrake: amen to that May 01 16:47:38 I got a feeling that bb 1.8 builds way more packages that 1.6 did... May 01 16:49:08 polyonymous: angstrom-console-image? May 01 16:50:05 cbrake, that too, I think. Right now building opie-image which pulls in way more stuff than it did a couple of days earlier with 1.6 May 01 16:50:41 03koen 07org.oe.dev * rbc8cfed5... 10/ (3 files in 3 dirs): May 01 16:50:41 glibc 2.5: fix the strlen() issues on big endian EABI, thanks to Lennert for tracking down the culprit May 01 16:50:41 * This is not a proper fix, we still need to find out wht __ARMEB__ isn't defined May 01 16:51:11 polyonymous: avahi has a gtk dependency, which tends to pull in a lot if it is included. May 01 16:51:46 had a gtk dependency :) May 01 16:51:59 cbrake, no, that's the other issue. That was consistent across bitbake versions. May 01 16:52:18 polyonymous: ohh, ok. May 01 16:52:48 * cbrake checks out latest avahi package :-) May 01 16:52:56 I've built opie-image a couple of days ago and now I'm building it again with 1.8. May 01 16:53:13 And I have to fix a lot of packages that aren't built in my old 'tmp'. May 01 16:53:39 Right now I'm looking at lirc-modules which I don't need, anyway :) May 01 16:54:04 when building with uclibc/gcc 4.1.1 on ppc i get a strange error during the end -> http://rafb.net/p/xwrDJJ10.html May 01 16:54:18 and it ipkg-cl is not at staging May 01 16:54:33 Ifaistos, bitbake ipkg May 01 16:54:34 oops May 01 16:54:37 bitbake ipkg-native May 01 16:54:47 its all ready build May 01 16:54:53 bitbake 1.6? May 01 16:54:56 yes May 01 16:54:59 ipkg-native? are you sure? May 01 16:55:09 I think it's not. May 01 16:55:26 zecke has a patch already, guess it didn't go upstream yet. May 01 16:55:59 meanwhile try bitake ipkg-native, should help. May 01 16:56:07 hmmm my rep is not synced with OE May 01 16:56:17 i'll check May 01 16:56:37 it is bitbake issue, not tree, I believe. May 01 16:56:42 you are right. i was looking at the libc build May 01 16:56:54 and there it exists May 01 16:57:02 base class checks for rootfs_ipk inheritance which isn't cached if class is inherited indirectly. May 01 16:57:09 polyonymous: could you send me a bitbake -DDD without that patch? May 01 16:57:23 polyonymous: I'm busy but I still want to understand which cycle we have May 01 16:58:29 zecke_, angstrom-*-image inherits a class that inherits rootfs_${package type - don't remember the variable}. May 01 16:58:53 base bbclass checks if package inherits rootfs_ipk before making it depend on some -native stuff. May 01 16:59:21 and inherit function in parser only collects top-level inheritance. May 01 16:59:52 because it overwrites whatever happens in nested classes. May 01 17:00:18 It's not easy to send bitbake -DDD now, because I've --switch-ed to -1.8 :) May 01 17:01:19 03polyonymous 07org.oe.dev * r46287715... 10/ (3 files in 3 dirs): libopie2: add missing include. Patch from polyonymous. Thanks. closes 2193. May 01 17:17:07 polyonymous: please go back to 1.6 to generate the log May 01 17:18:16 zecke_, will do, but not in the middle of my builds. May 01 17:39:30 polyonymous: are you going to send your libopie patch upstream as well? May 01 17:39:45 hvontres|poodle, I did. May 01 17:39:50 polyonymous: cool :) May 01 17:39:58 :) May 01 17:40:59 I'm trying to check for iwmmxt support with an AC_TRY_COMPILE statement May 01 17:41:09 It's strange, but the code: May 01 17:41:27 int main() { __asm__ __volatile__ ("wunpckelub wr6, wr4"); return 0; } May 01 17:41:52 Is failing when I try to compile it manually, however, the AC_TRY_COMPILE section passes May 01 17:42:20 The compiler flags are the same -march=armv5te -mtune=xscale May 01 17:43:01 Any hint? May 01 17:44:44 hi May 01 17:44:53 koen: hi, saw the 'almost' patch May 01 17:47:20 hi likewise, hi koen. May 01 17:47:24 HopsNBarley: hi May 01 17:49:38 Does anybody here know how the kernel build system generates /inclued/linux/autoconf.h ? May 01 17:49:56 any idea why the default parameters for squashfs are these ? EXTRA_IMAGECMD_squashfs = "-le -b 16384" May 01 17:50:20 * hvontres|poodle is still a bloody noob when it comes to autotools and other magic sturr May 01 17:51:02 Ifaistos: No, and they should be made endianess-aware at least May 01 17:51:32 likewise : jffs2 settings are the same May 01 17:51:37 le May 01 17:51:43 Ifaistos: same issue then :-) May 01 17:53:01 hvontres|poodle, I don't think kernel really use autotools at all. May 01 17:53:28 it had better not May 01 17:53:46 well, I can even reword it as "I'm pretty sure it doesn't" :) May 01 17:56:04 polyonymous: bug 2196 dupe of 2160? May 01 17:56:06 hvontres|poodle: afaik, the kernel makefile system generates it after 'make prepare' or 'make oldconfig': After configuration. May 01 17:56:18 !oebug 2196 May 01 17:56:19 * * Bug 2196, Status: NEW, Created: 2007-05-01 08:20 May 01 17:56:20 * * polyonymous(AT)klever.net: sword (opie) build fails for angstrom fails because of symbols invisibility May 01 17:56:21 * * http://bugs.openembedded.org/show_bug.cgi?id=2196 May 01 17:56:24 !oebug 2160 May 01 17:56:25 * * Bug 2160, Status: NEW, Created: 2007-04-29 06:31 May 01 17:56:26 * * bugs.openembedded.org(AT)rolf.leggewie.biz: RPATH issue in sword May 01 17:56:27 * * http://bugs.openembedded.org/show_bug.cgi?id=2160 May 01 17:56:51 no, I don't think so. Except for both are related to sword May 01 17:57:10 OK May 01 17:57:18 I didn't have this rpath issue, btw. May 01 17:58:00 zecke_: did django send you love note as well? May 01 17:58:40 sirfred: yes, I just stumbled across that... now I need to figure out why make oldconfig pulls in the uname -r output from my build host for CONFIG_UNAME_RELAEASE... May 01 17:59:25 hvontres|poodle: Good luck. May 01 17:59:52 sirfred: thanks... at least now I know where to start looking... May 01 18:01:42 lirc-modules is a hell and I think it's not supposed to cross-build the way it is.... May 01 18:04:28 likewise: http://rafb.net/p/z2enSS69.html May 01 18:04:32 polyonymous: Are you reading oe-devel? May 01 18:04:44 Laibsch, reading yes, I'm not subscribed though May 01 18:05:32 hey HopsNBarley May 01 18:05:40 (that is I'm reading via gmane nttp) May 01 18:06:24 polyonymous: I am not subscribed either (which is exactly why I asked if you read it ;-)) I use gmane for MLs whenever possible May 01 18:07:07 heh ;-) May 01 18:07:16 koen: your patch seems to break glibc 2.4 builds: NOTE: Task failed: Error: /home/leon/sandbox/openembedded/org.openembedded.dev/packages/glibc/glibc-2.4/armeb-strlen.patch not found. May 01 18:09:00 koen: which is strange, since you didn't touch glibc 2.4... ??! May 01 18:09:23 FILES_PATH May 01 18:09:30 later May 01 18:11:08 03koen 07org.oe.dev * r61e6e424... 10/ (1 packages/glibc/glibc-2.4/armeb-strlen.patch): glibc: also add strlen patch to glibc-2.4 dir May 01 18:12:45 polyonymous: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/15303 May 01 18:13:07 RFC for RW access for polyonymous May 01 18:13:14 yup. I see. May 01 18:13:34 wow. I didn't know I had so many bugs. May 01 18:14:04 I sort of did ;-) May 01 18:14:16 I wouldn't call the whole list "my bugs", though :) May 01 18:14:18 koen: ok, wow, this is intertangled. No wonder I am too dumb too follow all this stuff :-) May 01 18:14:30 polyonymous: You don't own them May 01 18:14:39 But they are a part of what you contributed May 01 18:14:40 yeah, I'm somehow involved. May 01 18:14:41 s/replace second occurence of too to to/ May 01 18:15:18 likewise, s/oo f/o f/ ;-) May 01 18:15:39 likewise: next try is http://rafb.net/p/NFyNvC42.html May 01 18:15:43 likewise, no, better s/o f/ f/ :) May 01 18:16:09 koen: OK, I'm now tracking down why __ARMBE__ isn't set. May 01 18:17:22 koen: http://rafb.net/p/OfZQ6R27.html and now working on some builds that have #errors to see what is (not) defined May 01 18:39:26 hi timtimred May 01 18:39:59 oh hello May 01 18:40:11 it wasnt me, whatever it was May 01 18:40:23 JustinP, you having rpath issues? May 01 18:40:24 :) May 01 18:41:22 if I have export PACKAGE_INSTALL = "xinetd", then RDEPENDS = "${PACKAGE_INSTALL}" in my-image.bb, if I then bitbake my-image -c rebuild, and an xinetd ipk doesn't already exist under tmp/deploy/ipk/etc., shouldn't bitbake then realize it needs to run bitbake xinetd? May 01 18:47:23 I'm looking at this mailing list post which seems to suggest that, but it's not working: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-February/001507.html May 01 18:50:01 clear May 01 18:50:16 * pgfeller ... ups, that was not the terminal May 01 18:50:56 hi all, - is there a commandline tool in OE to apply xml stylesheets to xml files (like Xalan)? May 01 18:51:14 xsltproc? May 01 18:51:32 polyonymous: thanks May 01 18:51:38 you're welcome. May 01 18:51:59 polyonymous: I'll try this (I've made a xsl to transfor iTunes podcas/rss to m3u playlists) May 01 18:52:33 It worked for me like half a year ago or so. May 01 19:13:50 koen: for lennert: http://rafb.net/p/4Wf6vD42.html (Not sure if it helps, I'm noob here) May 01 19:31:48 unbelievable. bitbake opie-image completed :) May 01 19:32:29 polyonymous: wohoooo :) May 01 19:32:44 I'm going for opie-kdepim-image now :)) May 01 19:32:48 like|movies: http://rafb.net/p/hgPgSo97.html May 01 19:33:27 polyonymous: what device are you building for ? May 01 19:33:35 hvontres|poodle, spitz May 01 19:35:17 polyonymous: ahh.. :) I guess I'll give poodle another shot as soon as I can figure out my kernel build problems.... May 01 19:35:50 hvontres|poodle, luckily I haven't had any kernel build problems... ;-) May 01 19:36:21 btw, someone asked me for my kdepimpi patch here and I just noticed it's in bugzilla for ages now. May 01 19:36:35 (in case "someone" is around:)) May 01 19:36:52 polyonymous: I think I might have a clue where to look now... I am suspecting CONFIG_LOCALVERSION_AUTO is somehow goofing things up May 01 19:37:07 polyonymous: well, maybe soon you can fix that :) May 01 19:37:25 hvontres|poodle, ;-))) I didn't mean complaining, actually. May 01 19:38:58 and as for your kernel issue, I don't think I can comment on that. Luckily I haven't had a chance to fight kernels in oe, yet :) May 01 19:40:49 polyonymous: hehe...lucky you :) I just want to be able to re-compile to change the cmdline to use /dev/mmcblk0p1 as / (makes testing images a LOT easier :) ) May 01 19:41:14 xuumbi: I'm guessing bitbake looks at stamps to determine if packages need built, not tmp/deploy/ipk/... May 01 19:41:30 polyonymous: well, I should probably get back to work...:) May 01 19:41:33 hvontres|poodle, I see. Wish kexec supported passing cmdline. May 01 19:41:38 have fun :) May 01 19:41:47 cbrake: what do you mean by "stamps"? May 01 19:41:53 xuumbi: I've run into this issue before -- digging through dusty archives of my mind ... May 01 19:42:15 xuumbi: tmp/stamps/ May 01 19:42:31 polyonymous: yeah...but I grok that even less than the kernel build system... but it looks doable. May 01 19:42:39 cbrake: oh right May 01 19:42:57 xuumbi: technicality, but the problem remains. May 01 19:43:29 I'm not bold enough to look at it unless I have to. I'm testing images by kexecing kernel and then altbooting into chroot. Works fine for me. May 01 19:43:50 hello all May 01 19:43:51 cbrake: basically my goal is to not use DISTRO/MACHINE_EXTRA_RDEPENDS to specify packages to be built and therefor included, because that makes those packages dependencies of the distro and require ipkg remove -force-depends to remove them May 01 19:43:58 who's the best person to ask about tslib? kergoth? May 01 19:46:18 cbrake: my current solution, which probably isn't the best, is to create a "dummy" task file with all the packages that I need compiled, so I build that first, then when I build my custom image file that includes the same packages in PACKAGE_INSTALL May 01 19:48:27 there must be something wrong. bitbake opie-kdepimpi-image complete :)) May 01 19:56:51 Is bitbake 1.8 slightly crazy? May 01 19:57:14 Why does it leave jobs half-unfinished? May 01 19:57:22 Only to continue them later? May 01 19:57:44 B_Lizzard: multithreading + intertask dependencies May 01 19:57:51 huh? Maybe they're half-finished? :) May 01 19:58:18 I'll consider it sane, then May 01 19:58:22 :) May 01 20:10:37 Crofton: well, like the recent e-mail by someone else, my build failed and I retried and it continued. The problem is that the bas gcc libs are now not packaged and not installed in my image. I've switched that fatal to warn in my local tree as it sucks that it's allowing broken builds to continue. I want to be able to test things.... May 01 20:11:30 JustinP, I think everyone comments out #return False in insane :) May 01 20:12:07 polyonymous: ok, commenting that out too May 01 20:12:18 heh May 01 20:13:09 it really should have been tested that this doesn't break things....if a build which fails with RPATH issues fails on a subsequent build then I'd be fine with it....but allowing bad builds means that we have to restart building from scratch as who knows which packages may have failed... May 01 20:13:31 Very true. May 01 20:16:53 you can also mkdir classes in BBPATH May 01 20:16:57 like in build May 01 20:16:59 and touch classes insane.bbclass May 01 20:17:07 that is how I think I did it, need to go see if the build finished May 01 20:23:16 *** No rule to make target `../protocol/jar/src/libnkjar_s.a', needed by `libnecko.a'. Stop. May 01 20:23:21 Hi, May 01 20:26:28 JustinP, I am going to try to figure out how to start fixing some of the RPATH stuff May 01 20:36:04 Is tslib still being maintained? May 01 20:36:15 I see a lot of patches which are apparently not being applied May 01 20:43:43 it's even hosted on LTG May 01 20:44:26 psokolovsky__: you mean berlios, right? May 01 20:44:39 ah, yep, apparently... May 01 20:46:51 who's the best person to ask about tslib patches? I found what might be a minor bug May 01 20:47:02 03polyonymous 07org.oe.dev * r1f0046e3... 10/ (4 files in 3 dirs): May 01 20:47:02 opie-networksettings cvs: Fix compilation with latest linux-headers. May 01 20:47:02 * Closes #2197. May 01 20:47:41 See, why would I need a mtn access? I'm already committing :) May 01 20:50:57 Is there a list of bb variable definitions somewhere? May 01 20:51:58 vervain: bitbake.conf May 01 20:53:52 or documentation.conf May 01 20:54:11 not the OE bitbake configuration but generic bb variables. May 01 20:54:52 in teh bb docs there are some examples in the 4. Commands->bitbake->Metadata section but it's thin. May 01 20:55:14 "read the source"? May 01 20:56:33 Hi, how to solve "../protocol/jar/src/libnkjar_s.a', needed by `libnecko.a'"? May 01 20:56:43 minimo on mipsel May 01 20:58:39 time to boot into angstrom's opie image :) May 01 21:01:00 I wonder is it a problem to make OE splash screen landscape or is it that just nobody took care of it? May 01 21:08:38 polyonymous: Any luck booting? May 01 21:08:47 hvontres|poodle, Yup, I'm in it now. May 01 21:08:52 setting up stuff. May 01 21:09:05 03koen 07org.oe.dev * rbc5aec33... 10/ (14 files in 3 dirs): linux-ezx 2.6.21: update patches to r1995, gives you working ts, keys and some powermanagement May 01 21:09:10 'booting' is kexecing and chrooting, though. May 01 21:09:28 polyonymous: works for me :) May 01 21:09:38 :) May 01 21:10:09 * hvontres|poodle 's method is almost the same May 01 21:10:32 koen: sounds like i should build new images :-) May 01 21:10:34 Quite natural methos. May 01 21:11:02 florian: or just ipkg upgrade if you're using angstrom May 01 21:11:34 polyonymous: yup. right now I have one "daily driver" SD with OZ 3.5.4.2 and one "experimental" with the image du jour May 01 21:12:12 hvontres|poodle, you don't have microdrive, I take it? :) May 01 21:12:28 koen: Angstrom-gpephone images? May 01 21:13:59 florian: afaik gpephone is still broken May 01 21:14:10 polyonymous: actually, i used too. I had a 5GB ST1 that I used for mp3's. but sadly it died. May 01 21:14:19 koen: ? May 01 21:14:41 florian: it doesn't compile against a recent gtk May 01 21:14:55 RIP. May 01 21:14:57 koen: i guess the world is just bigger than you would like to have it for Angstrom May 01 21:15:23 so it compiles now? May 01 21:18:07 koen: here it compiles most of the time, but i never used anything else than the recommended gtk and glib May 01 21:19:03 I think I'm about ready to switch to angstrom's opie-kdepim-image ;-) May 01 21:19:18 Crofton: I thought that people had already proposed patches for it on the list... May 01 21:20:14 I think there are two problems, fixing insasen.bbclass and fixing the bb files so we do not end up with with bad rpaths May 01 21:24:08 Crofton: the problem is not in insane.bbclass, but in PACKAGE_FUNCS May 01 21:24:22 'morning' all May 01 21:24:37 koen, remind me to keep my mouth shut when I do not really know what I am talking about :) May 01 21:24:44 if you fiddle with PACKAGE_FUNCS errors don't get propagated May 01 21:25:15 or rather, it doesn't invalidate the previous task (do_install) May 01 21:25:35 koen: This is why do_install was part of do_package May 01 21:26:00 RP: indeed May 01 21:26:52 koen: Why don't we make it a PACKAGE_FUNCS too? May 01 21:27:10 RP: I have no idea May 01 21:27:25 I'll have to wait for zecke to whisper some wise reply into my ear ;) May 01 21:29:27 Let me make a patch someone can test... May 01 21:29:46 exit May 01 21:33:11 koen: http://www.rpsys.net/openzaurus/temp/oe-install-change.patch May 01 21:33:20 untested but might just work May 01 21:34:54 03koen 07org.oe.dev * rf342c01c... 10/ (1 conf/machine/ixp4xxbe.conf): ixp4xxbe: add -D__ARMEB__ to target cc arch May 01 22:06:06 Good night May 01 22:06:14 night sirfred|zzz May 01 22:15:46 03ifaistos 07org.oe.dev * raa47c0e9... 10/ (3 files in 3 dirs): packages/linux/linux-magicbox_2.6.18.6.bb : Add squashfs-lzma support to the kernel May 01 22:15:50 03ifaistos 07org.oe.dev * rda7866de... 10/ (1 conf/machine/magicbox.conf): May 01 22:15:50 conf/machine/magicbox.conf : make sure jffs2 and squashfs images generated are for big endian machines May 01 22:15:50 Set minimun kernel to 2.6.18. May 01 22:16:22 Ifaistos: squashfs-lzma. cool. May 01 22:17:26 4MB flash don't leave you with much choice... :) May 01 22:18:40 now that I'm all built and running it's about time to see what in my mtn diff isn't in bugzilla yet :) May 01 22:19:26 polyonymous : was the bitbake 1.6 fix for ipkg-native pushed upstream ? May 01 22:19:46 Ifaistos, what do you mean pushed? I passed the patch to zecke. May 01 22:19:57 Ifaistos, want a patch? May 01 22:20:10 did he put it to the svn ? May 01 22:20:16 yeah sure May 01 22:20:20 I think not yet. hang on. May 01 22:20:59 http://rafb.net/p/qrOvDZ14.html May 01 22:21:16 zecke wanted bitbake -DDD output from me which I didn't have to provide him with, yet. May 01 22:21:43 Ifaistos: Do you happen to know about how to compress for squashfs-lzma on ubuntu? May 01 22:22:33 Ifaistos: mksquashfs? May 01 22:23:09 Laibsch : yes May 01 22:23:20 likewise: I think that is going to be normal squashfs, no? May 01 22:23:38 you need to patch it May 01 22:23:47 Laibsch, Ifaistos: squashfs-tools-native_3.1r2.bb holds mksquash-lzma too (I wrote this .bb) May 01 22:24:07 this one --> squashfs-lzma-tools-native_3.1r2.bb May 01 22:24:42 OK, so I bitbake it and execute it from within the staging dir? Got the idea right? May 01 22:24:47 likewise : this is the one i use. i though Laibsch wanted to compress something outside OE May 01 22:25:05 Laibsch: yes May 01 22:25:06 yep. works fine May 01 22:25:10 anyone know which ASoC git tree is the best to pull from? May 01 22:25:12 yes, 800 tar.bz2 recompressed on the collie is going to take like ... May 01 22:25:22 Ifaistos: OK, I don't know if Ubuntu has it a package, guess not. May 01 22:25:27 800MB May 01 22:25:41 likewise: google thinks not, too May 01 22:26:55 plus I don't have the space on the collie to recompress 800 MB already compressed data May 01 22:28:17 Laibsch: 800MB on collie???????? May 01 22:28:54 yes May 01 22:28:58 Japanese wikipedai May 01 22:29:01 wikipedia May 01 22:30:28 English would be bigger ;-) May 01 22:31:51 night everyone May 01 22:36:52 I'm totally lost. I'm afraid I'll have to read mtn docs :( May 01 22:39:53 polyonymous: That is not so bad May 01 22:40:09 But you could ask in #monotone on irc.oftc.org May 01 22:40:16 Laibsch, I used to read docs when everything else fails, therefore I have to admit everything else failed :) May 01 22:40:30 I think I should start off with docs. I'm missing some concept. May 01 22:40:51 The guys in #monotone are VERY helpful May 01 22:41:00 very nice people May 01 22:41:13 Laibsch, but I shouldn't be pestering. I should first try myself. May 01 22:41:16 Laibsch: so koen dosn't hang out over there ? :) May 01 22:41:20 polyonymous: and the monotone documentation is very well written. May 01 22:41:56 likewise, good to know. I hope I'm able to figure out things. After all I don't have troubles with git. May 01 22:42:14 polyonymous: anything specific you would like to know? May 01 22:42:57 likewise, well, I just don't fully understand what is selected as an update target and why I seem not to have the most recent commits after pulling and updating. May 01 22:43:10 And I do get updates. May 01 22:43:27 And how many heads the .dev branch has, etc. May 01 22:43:41 polyonymous: last question first: how do you know that you do not have the lastest commits? May 01 22:43:52 hvontres|poodle: You are NOT being nice now, are you ;-) May 01 22:44:28 polyonymous: mtn automate get_base_revision_id tells the id's of the head(s), multiple if not merged yet. There must be a simpler way, I always use this though. May 01 22:44:37 polyonymous: That happens when you have made local changes May 01 22:44:41 likewise, well, I've seen commit by koen to this xtscal problem and I don't see it in my tree, although koen said that if I've seen commit then I should be having it.. May 01 22:44:46 I think mtn will not overwrite them. May 01 22:44:49 Laibsch, thought that's related. May 01 22:45:01 Yes, but it should've reported conflict, I'd think. May 01 22:45:13 Laibsch: yes, it merges and/or reports a conflict May 01 22:45:40 mtn get_base_revision_id is 9709188a53609e84bb72b7a7f9ee79ee1c0419f2 May 01 22:45:46 polyonymous: but take some time to read the docs, I have to catch up on GIT myself so I cannot help you on the differences. May 01 22:46:07 yes, I think I should. May 01 22:46:28 * Laibsch points Ifaistos to !oebug 2200 May 01 22:46:33 polyonymous: you'll be an expert soon. May 01 22:46:36 !oebug 2200 May 01 22:46:37 * * Bug 2200, Status: NEW, Created: 2007-05-01 15:43 May 01 22:46:38 * * bugs.openembedded.org(AT)rolf.leggewie.biz: QA issues in squashfs-lzma-tools-native May 01 22:46:39 * * http://bugs.openembedded.org/show_bug.cgi?id=2200 May 01 22:46:55 likewise, quite possible :) May 01 22:48:24 what is base revision id? and what is heads... Well, I'm off to docs, I'm afraid :) May 01 22:51:04 Laibsch, regarding your answer to koen about mixed-case - `tr` is exactly that makes everything uppercase and therefore you don't need mixed-case. But this is the commit I don't see in my tree yet :) May 01 22:52:21 polyonymous: Well, maybe you can post a reply. Would be nice May 01 22:52:33 Laibsch, is List open for non-subscribers? May 01 22:53:05 hmm.. May 01 22:53:16 mtn: selected update target da7866de083247553abfdcab2457e49e772484f7 May 01 22:53:16 mtn: warning: rename target conflict: nodes 2147483655, 21478, both want parent 959, name wireless.patch May 01 22:53:16 mtn: warning: resolve non-content conflicts and then try again. May 01 22:53:22 I need to find out what it means ;0 May 01 22:56:52 polyonymous: you can post via gmane.org. Or maybe I am subscribed and have to receive no mails May 01 22:56:55 * Laibsch forgot May 01 22:57:14 Ifaistos: mksqashfs-lzma is doing a nice job here. Thank you. May 01 22:57:18 Laibsch, I'll see... May 01 23:04:20 Laibsch, I'm not registered at gmane either :) May 01 23:05:17 well, I'd rather sort out my mtn... May 01 23:05:22 good nite May 01 23:05:26 polyonymous: good luck May 01 23:05:34 night, likewise May 01 23:05:46 polyonymous: there is also "mtn revert", but be sure to copy your local changes first! May 01 23:06:12 I was thinking about reverting it... May 01 23:09:27 it's very nice of mtn to ay the problem is with 'wireless.patch' without even mentioning the directory :) May 01 23:09:53 polyonymous: I meant registering for the ML but set it to sent out no mail since you (and I) read from gmane May 01 23:10:19 Laibsch, Ah... That may make sense, indeed. May 01 23:21:20 Laibsch, I sorted out monotone, finally, by reverting packages in question (and those are basically the ones that went upstream) May 01 23:21:38 and by what I read in xtscal-cxk.patch - the problem is solved. May 01 23:49:41 Laibsch: Well, ok... but koen does seem to lack some of the skills needed for customer support :) May 01 23:54:19 muwhaha May 01 23:58:14 CoreDump|home: ok, so I was TRYING to be nice this time.....:) May 01 23:58:26 you were May 02 00:00:30 CoreDump|home: any chance of setting up bb on hentges.net? May 02 00:00:42 ? May 02 00:01:22 ah, no way. May 02 00:01:30 CoreDump|home: I was just wondering if I could "borrow" your server to do builds :) May 02 00:01:46 my server is a dog-slow celeron May 02 00:02:17 CoreDump|home: ahhh.. so my dual P-II's might actually beat it then :) May 02 00:02:30 probably =) May 02 00:05:35 okay, all patches it took me to build images on angstrom are in bugzilla now :) May 02 00:21:48 polyonymous: wohooo...:) May 02 00:22:04 * polyonymous agrees :) May 02 00:46:00 night everyone. May 02 00:52:23 gn May 02 02:20:16 03lenehan 07org.oe.dev * r493ecbe0... 10/ (1 classes/cpan.bbclass): May 02 02:20:16 cpan.bbclass: Building cpan modules needs to depend on both perl and May 02 02:20:16 perl-native. They are built with perl-native but use the May 02 02:20:16 configuration information from perl. This issue wasn't showing up May 02 02:20:16 with bitbake 1.6 but is with 1.8.2 where perl is configured and May 02 02:20:17 compiled perl but not staged prior to moving on. May 02 02:20:20 03lenehan 07org.oe.dev * r253548a9... 10/ (1 classes/cpan.bbclass): May 02 02:20:23 cpan.bbclass: Stop the cpan modules which ask you to confirm the May 02 02:20:25 configuration from hanging bitbake. They expect you to press y to indicate May 02 02:20:27 that you are ok with the configuration. For some reason there was no problem May 02 02:20:29 in bitbake 1.6 but this caused hangs in do_configure with bitbake 1.8. May 02 02:20:31 03lenehan 07org.oe.dev * r3ea77972... 10/ (38 files in 2 dirs): May 02 02:20:33 perl modules: Bump PR on cpan modules effected by the recent May 02 02:20:35 cpan.bbclass changes. **** ENDING LOGGING AT Wed May 02 02:59:56 2007