**** BEGIN LOGGING AT Fri Mar 19 02:59:56 2010 Mar 19 06:15:59 Hi All Mar 19 06:16:24 I am trying to enable mouse support for the console in Angstrom Mar 19 06:16:44 and Created one receipe and IPK for gpm Mar 19 06:16:55 gpm -general Purpose mouse Mar 19 06:17:04 But still it's not working Mar 19 06:17:12 so any idea where am wrong ? Mar 19 06:54:20 anyone know why the python package for angstrom might be missiing termios? Mar 19 06:54:23 among other modules Mar 19 07:04:19 * sigh * Mar 19 07:34:54 morning Mar 19 07:36:02 good morning Mar 19 07:38:47 I asked about this yesterday but still havn't solved it so I'll try again.. I got two "identical" (manufactor say they are and lspci/lshw looks pretty identical) machines. The problem is that the network is only working in one of them using the same image. I'm moving the CF-card between the machines. On one of the machines it seems like it can't identify the nics at all. I need some suggestions on where to start troubleshooting this Mar 19 07:40:20 jovox: if network is only working in one of them using the same image, looks like the problem is the hardware Mar 19 07:43:53 yeah.. but I tried with a another "rescue" distro and that one work on both machines Mar 19 07:44:31 and it's 4 out of 5 machine that doesnt work Mar 19 07:44:49 and manufactor says all five should be identical Mar 19 07:45:23 but lspci tells me I have the same nics on all five Mar 19 07:47:40 you're not trying them at the same time are you ? Mar 19 07:48:01 same time? Mar 19 07:48:49 I got them on my desk and just move the cf card between them.. do yeah, pretty much the same time Mar 19 07:51:04 But it's clear something is different between them Mar 19 07:57:50 help me pls Mar 19 08:02:37 jovox: i think the issue is with your hw and your setup Mar 19 08:03:05 jovox: if the machines one way or another get the same mac address this could well be a problem Mar 19 08:03:25 your cf card contains u-boot which often sets the mac address Mar 19 08:03:55 I don't have any network cable connected so thats now the issue Mar 19 08:04:46 I just booted the rescue image on two machines. It's loading the same driver on both of them (one of them is the one that does not work with my image). Mar 19 08:05:00 ah ok, thought from your message that you had (as you ssaid the network was only working iwth one machine) Mar 19 08:05:46 ok, to be more clear it's the nics there are not being identified Mar 19 08:05:48 jovox, guess you need to check if there is debugging code in your nic driver that you can enable to pinpoint the problem Mar 19 08:06:20 they are there, lspci sees them, but somehow they are not accepted or some other error shows up Mar 19 08:06:45 yes Mar 19 08:10:54 The rescue image image is using an older version of the r8169 module.. Mar 19 08:11:28 it's using 2.2 while mine is 2.3 Mar 19 08:11:55 it looks like onw can set the debuglevel for it Mar 19 08:12:02 will see if that gives anything Mar 19 08:12:04 maybe then try the old one Mar 19 08:12:10 yes Mar 19 08:12:14 indedd typically you can set some debug level Mar 19 08:29:37 If I need the python "urlparse" module. Where is that provided? Mar 19 08:29:56 It doesn't seem to be installed by default and there is no python-urlparse recipe Mar 19 08:30:49 /usr/lib64/python2.6/urlparse.py is part of python-2.6.2-4.fc12.x86_64 on my fedora 12 system Mar 19 08:31:13 or do you mean not for building but for the target? Mar 19 08:31:21 right, it is part of the standard library, but we don't install the full standard library by default. Right for the target Mar 19 08:31:22 s/building/host/ Mar 19 08:31:35 ah, sorry Mar 19 08:31:36 :) Mar 19 08:31:54 np :) Mar 19 09:31:46 godd morning Mar 19 09:32:33 recalcati: dog morning Mar 19 09:32:58 the compilation was succesful. Mar 19 09:33:09 right morning Mar 19 09:35:14 recalcati: good to know :-D Mar 19 09:38:46 03Michael Lippautz  07org.openembedded.dev * reb2093fa76 10openembedded.git/recipes/lighttpd/lighttpd.inc: Mar 19 09:38:46 lighttpd: Add configuration to CONFFILES. Mar 19 09:38:46 Signed-off-by: Michael Lippautz Mar 19 09:41:00 03Koen Kooi  07org.openembedded.dev * rb34c4a2a27 10openembedded.git/recipes/xorg-lib/ (6 files in 2 dirs): pixman git: update to 0.17.13, update NEON patches Mar 19 09:46:21 03Koen Kooi  07org.openembedded.dev * r96b8c73a38 10openembedded.git/recipes/xorg-lib/ (2 files in 2 dirs): pixman git: revert a commit that breaks thumb, reported by Martin Jansa Mar 19 09:48:37 Hi, I have mailed my patches to dev list, I like to know status through pwclient. Help me, how to use pwclient, and conf files required? Mar 19 10:31:14 mickeyl, if you have a min can you look at http://bugs.openembedded.org/show_bug.cgi?id=5385 please? Thanks. And, should I give fso2-* a try? I plan to put my hands on openezx again this weekend. Mar 19 10:33:19 03Martin Jansa  07org.openembedded.dev * r527c307f33 10openembedded.git/recipes/mplayer/mplayer_git.bb: Mar 19 10:33:19 mplayer_git: use same SRC_URI for all, additional patch in glamo repo won't hurt as it's enabled only in EXTRA_OECONF Mar 19 10:33:19 Signed-off-by: Martin Jansa Mar 19 10:35:53 03Martin Jansa  07org.openembedded.dev * r1b95116648 10openembedded.git/recipes/libxml/libxml2_2.7.7.bb: Mar 19 10:35:54 libxml2: add version 2.7.7 Mar 19 10:35:54 Signed-off-by: Martin Jansa Mar 19 10:35:55 03Martin Jansa  07org.openembedded.dev * r4cf9229119 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: frameworkd: bump SRCREV Mar 19 10:51:59 hey all, Still am looking for a solution for mouse with in console Mar 19 10:54:49 attach a mouse! Mar 19 10:57:42 :) Mar 19 10:58:12 it's already attached :( Mar 19 10:58:14 ao2: i will take a look. we're currently in transition phase, that means some of the services in fso2 are read for primetime (usage, device, data, tdld), but some others are not yet finished (gsm,gps). Unfortunately fso2 has not seen any integration work for EZX, since I did not know whether it would be in a state that justifies this work (as you know). It should not be complicated to bring fso2 to openezx, in fact due to it being C, it should run much better Mar 19 10:58:14 than FSO1 ever did. If you are serious about "finishing" the kernel, then I volunteer to spend some time on the integration when i'm back from austria (1th of April). Mar 19 11:03:28 morning Mar 19 11:03:36 gm Mar 19 11:07:21 mickeyl, I'll let you know then, for now I keep testing with fso1 which should be faster for prototyping, I mean to edit .py files directly on target rootfs, this should work, shouldn't it? Mar 19 11:07:50 correct Mar 19 11:08:21 that's the beauty of fso1, with fso2 we're again in develop-compile-test mode Mar 19 11:08:30 what image do you suggest me to use? fso-zhone-image? or -paroli? Mar 19 11:08:32 can't get both the cake and eat it though ;) Mar 19 11:08:39 paroli is dead Mar 19 11:08:51 for integration work I'd use zhone Mar 19 11:08:56 it's simpler than full SHR Mar 19 11:09:00 thanks again Mar 19 11:09:03 np Mar 19 11:09:12 paroli is dead? Mar 19 11:09:18 mickeyl, I'll get back to you when I have something Mar 19 11:09:19 I thought it wasn't Mar 19 11:12:23 ao2: awesome, thanks Mar 19 11:12:42 Ainulindale: i don't see anyone working on it except the pyneo guys Mar 19 11:13:00 that counts for me as dead ;) Mar 19 11:13:15 by now they probably ripped out fso support ;) Mar 19 11:15:07 mickeyl: heh Mar 19 11:19:56 hmm Mar 19 11:20:01 guadec this year in netherlands Mar 19 11:20:28 i should've proposed a paper for when it was on the canarian islands rather than for this year :D Mar 19 11:20:31 oh well... Mar 19 11:21:41 rofl Mar 19 11:21:46 siji, console as text console, or do you mean x windows Mar 19 11:21:54 mickeyl, it shows you spent time in grad school Mar 19 11:22:19 mickeyl: don't complain about having the opportunity to go to the netherlands ;-) Mar 19 11:22:22 I want to enable it with out X Mar 19 11:22:33 eFfeM-work, I was thinking that also :) Mar 19 11:22:56 am having one clutterr apps , which is running on eglnative Mar 19 11:23:14 actually lots of Germans enjoy to come to the netherlands, look at our coasts in summer or Venlo on saturday Mar 19 11:23:42 siji: if you run clutter you run some form of windowing sw (guess X, don't know about egl) Mar 19 11:23:43 well Mar 19 11:24:05 there's this urban legend about dutch and germans not really having the right chemistry ;) Mar 19 11:24:25 mickey actually i think dutch beaches are more pop with germans than the canarian isles Mar 19 11:24:32 mickeyl: only if it comes to soccer Mar 19 11:24:34 hehe Mar 19 11:25:05 not exactly , Eglnative means it's running on FB Mar 19 11:25:09 frame buffer Mar 19 11:25:33 And I read some where that gpm will solve my prblm Mar 19 11:25:37 siji but i have problems with mouse and kbd sometimes too with beagle, no idea what causes it, guess it is a usb thingie (beagle has some more usb flakes that my nslu2 did not have) Mar 19 11:25:42 no idea on gpm Mar 19 11:25:51 ok Mar 19 11:26:24 but here my keyboard and mouse is working fine with beagle , i mean X is detecting those Mar 19 11:26:31 by using usb hub Mar 19 11:26:53 ok , what i did that i created one reciepe for gpm Mar 19 11:27:14 ah ok, well don't know gpm so can't really help you with that (and 35 km away from my beagle) Mar 19 11:27:32 ok Mar 19 11:37:39 eFFew-work,as i told u while creating ipk Mar 19 11:37:56 OE generated only gpm*-dev and gpm*-dbg Mar 19 11:38:03 is it fine Mar 19 11:39:43 i mean , i think normaly it will generate three ipk files right? Mar 19 11:43:32 03Tom 'TAsn' Hacohen  07org.openembedded.dev * rbdeef9865b 10openembedded.git/recipes/shr/e-wm-config-illume2-shr_git.bb: Mar 19 11:43:32 e-wm-config-illume2-shr: Added shr-e-gadgets to RDEPENDS Mar 19 11:43:32 Signed-off-by: Martin Jansa Mar 19 11:43:52 03Tom 'TAsn' Hacohen  07org.openembedded.dev * r06fc7fa5e1 10openembedded.git/recipes/shr/shr-e-gadgets_git.bb: Mar 19 11:43:52 shr-e-gadgets: new recipe for e17 gadgets Mar 19 11:43:52 Signed-off-by: Martin Jansa Mar 19 11:48:14 eFFew-work, u there Mar 19 11:48:22 I have enabled it in ubuntu Mar 19 11:48:25 working fine Mar 19 11:48:34 but now need to enable it with Angstrom Mar 19 11:48:51 can pls have a look on my receipe Mar 19 11:52:10 siji, I think you're spelling eFFeM-work nick wrong, maybe it's not jumping out at him. Mar 19 12:05:47 siji, actually was afk for lunch Mar 19 12:06:24 if you post it somewhere i can have a peek at your recipe (but really the log has the interesting stuff Mar 19 12:06:48 siji: beware of messages like NOTE; file /a/b/xyz is not in any package Mar 19 12:06:59 and yes, I would expect also a non-dev pkg Mar 19 12:12:43 ya Mar 19 12:12:45 wil do Mar 19 12:20:12 , u there Mar 19 12:26:08 hi Mar 19 12:26:15 who can I bug about http://bugs.openembedded.org/show_bug.cgi?id=5413 ? Mar 19 12:27:34 siji: what's up Mar 19 12:27:55 hey i was talking in Clutter IRC Mar 19 12:28:32 and clutter eglnative is only enabled for tslib Mar 19 12:28:39 means only for touch screen Mar 19 12:29:09 evdev is not supported my eglnative clutter Mar 19 12:31:51 ah ok, that explains things Mar 19 12:32:54 so now let me try to add a patch on clutter ;) Mar 19 12:33:01 anyway thanks alot Mar 19 12:38:35 morning Mar 19 12:46:37 siji: gl & have fun :-) Mar 19 12:46:47 :) Mar 19 13:00:41 03Martin Jansa  07org.openembedded.dev * rb2df355282 10openembedded.git/recipes/xorg-lib/ (13 files): Mar 19 13:00:41 pixman: add pixman.inc, unify recipes, remove do_stage from few old versions, add 0.17.12 with positive D_P Mar 19 13:00:41 Signed-off-by: Martin Jansa Mar 19 13:29:52 Anyone up for an oe build question today? Google is being most unhelpful :-( Mar 19 13:31:23 On two different machines, when building OE, running task 441, that's recipes/udev/attr_2.4.44.bb, in the do_install() function, something goes crazy and spawns multiple 'make' processes that choke the machine. Ideas? Mar 19 13:45:33 morning all Mar 19 13:45:41 hi tp Mar 19 13:45:43 ups rp Mar 19 13:50:32 hi rp Mar 19 13:50:36 hi pb Mar 19 13:50:40 hi woglinde Mar 19 14:06:08 03Martin Jansa  07org.openembedded.dev * r1405e1aabe 10openembedded.git/recipes/tasks/task-shr-feed.bb: Mar 19 14:06:08 task-shr-feed: add shr-theme-02 Mar 19 14:06:08 Signed-off-by: Martin Jansa Mar 19 14:06:18 03Jesus McCloud  07org.openembedded.dev * r2ed9ffad20 10openembedded.git/recipes/shr/ (3 files): Mar 19 14:06:18 shr-theme-o2: new recipes for o2 theme Mar 19 14:06:18 Signed-off-by: Martin Jansa Mar 19 14:18:32 hmm Mar 19 14:18:36 was that pixman update tested? Mar 19 14:18:42 | arm-oe-linux-gnueabi-libtool: link: cannot find the library `/data/pkg/oe/dream/tmp/staging/armv6-novfp-oe-linux-gnueabi/usr/lib/libpixman-1.la' or unhandled argument `/data/pkg/oe/dream/tmp/staging/armv6-novfp-oe-linux-gnueabi/usr/lib/libpixman-1.la' Mar 19 14:23:01 BBCLASSEXTENDS seems to have broken -b Mar 19 14:23:13 mickey@amethyst:/local/pkg/oe/dream$ bitbake -b ../openembedded/recipes/xorg-lib/pixman_0.17.12.bb Mar 19 14:23:14 ERROR: Parsing error data_fn virtual:native:/data/pkg/oe/openembedded/recipes/xorg-lib/pixman_0.17.12.bb and fn /data/pkg/oe/openembedded/recipes/xorg-lib/pixman_0.17.12.bb don't match Mar 19 14:25:12 mickeyl: I think that is fixed on master at least Mar 19 14:26:05 hmm, kj Mar 19 14:30:24 s/master/HEAD/ Mar 19 14:35:25 Hi, I am working on the integration of the i.MX25 card from Freescale in OpenEmbedded. I am not sure on the right way of handling the kernel patches for this board Mar 19 14:37:22 They are distributed by Freescale as part of a LTIB release, and are packaged in a 2M tar.bz2 file Mar 19 14:38:26 Should I integrate the file in recipes/linux/linux-2.6.28/mx25_3stack/ , or decompress it first? Mar 19 14:38:49 do not use '_' in machine name Mar 19 14:38:50 mikc: Can you not just use a URL to it or the patches? Mar 19 14:38:59 mikc, It might be worth checking they haven't pushed the support back already. Mar 19 14:39:02 sorry, I meant - Mar 19 14:40:02 mikc, They seem to push patches back, but not always exactly as they appear in LTIB Mar 19 14:44:05 MX25 is not in mainline kernel Mar 19 14:44:19 Really? Mar 19 14:44:30 mikc, http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=8c25c36f33157a2e2a1fcd60b6dc00feace80631 Mar 19 14:48:59 what does "psp" mean in 'linux-omap-psp-2.6.32'? Mar 19 14:52:39 JaMa: pixman 0.16.2 no longer builds for me after the update Mar 19 14:53:57 Hmm... There is no mx25_3stack_defconfig in official, but commits referring to i.mx25. Do you know if this sfr/linux-next tree will be pulled ? Mar 19 14:55:53 RP: any plans to backport the fix? Mar 19 14:56:00 RP: or do we require master now? Mar 19 14:56:03 or HEAD Mar 19 14:56:05 or whatever Mar 19 14:56:38 tomorrow will be 6 years since my first OE contribution Mar 19 14:56:42 time flies Mar 19 14:56:45 indeed Mar 19 14:58:45 03Steffen Sledz  07org.openembedded.dev * rf583e41692 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig: Mar 19 14:58:45 linux-2.6.24: enable ftdi_sio module for hipox machine Mar 19 14:58:46 Signed-off-by: Steffen Sledz Mar 19 15:01:17 RP: I don't have a mirror at hand to host these easily Mar 19 15:05:02 mikeul: Platform Support Package Mar 19 15:08:50 hrw: seriously? damn.. what's the project's age as a whole now, a bit more than that? Mar 19 15:08:58 * kergoth wonders where the time goes Mar 19 15:09:15 Is such a big pack of patches likely to be accepted in OE? Mar 19 15:10:12 Or should I definitely find a way to mirror them somewhere? Mar 19 15:10:14 mikc, I picked the wrong tree- they are in torvalds tree as well. Mar 19 15:10:32 really? ow I missed that Mar 19 15:12:21 it recent :/ I just pulled and it appeared Mar 19 15:12:39 (I pulled yesterday from stable....) Mar 19 15:12:58 mikc, it might not have gone back with that name, or if it's like the ppc stuff, there may be a common defconfig for multiple boards. Mar 19 15:13:50 let's give it a try... Mar 19 15:14:12 OK, so it is not the same way as in LTIB Mar 19 15:14:22 I'll look at that Mar 19 15:15:33 mikc, probably not. I think they have an internal team that hack things together for the LTIB, then a team that cleans it up for mainline Mar 19 15:16:08 mikc, clearly the community may also object to how things have been done and thus changes must be made. Mar 19 15:16:52 mickeyl: I didn't release 1.8 was broken. I would like people to start using master tbh Mar 19 15:16:53 MWelchUK_work: For i.MX? Freescale have no involvmenet with mainline. Mar 19 15:17:05 There is no good reason not to anymore Mar 19 15:17:30 it looks like it is pengutronix.de who pushes that. i.MX25 3DS appears in menuconfig Mar 19 15:17:44 broonie, ok, it's someone else then Mar 19 15:17:45 Yes, pengutronix are upstream as far as the kernel is concerned. Mar 19 15:18:01 Hence why the patches are probably very different. Mar 19 15:18:31 Well, they do frequently base their work on the FSL stuff but sometimes that's not so good. Mar 19 15:18:48 The FSL i.MX2x stuff is basically abandoned at this point, their newer stuff is much more mainlinable. Mar 19 15:22:47 hum..error: linux/fec.h: No such file or directory Mar 19 15:23:09 I should have missed something... Mar 19 15:23:26 RP: ok, same error in HEAD Mar 19 15:24:10 mickeyl: That is odd as I regularly use -b Mar 19 15:26:16 mickeyl: I wonder if there is something odd about that recipe? :/ Mar 19 15:26:25 mhm.. I added curl to my RDEPENDS but no matter what I do it does not end up on the rootfs... am I missing something? Mar 19 15:26:41 Jin^eLD: check the package and see if its a dependency? Mar 19 15:26:45 MWelchUK_work: thanks for the help Mar 19 15:26:51 Jin^eLD: RDEPENDS variable being overwritten somewhere? Mar 19 15:26:55 mikc, np Mar 19 15:27:12 RP: nope, not for this package, for instance, I had "file" in RDEPENDS and it got installed correctly Mar 19 15:27:20 so puzzled about why it is ignoring curl Mar 19 15:28:22 although now I see that for some reason nothing from RDEPENDS from this package is being taken.. grml Mar 19 15:29:31 curl was even built, the ipk is available Mar 19 15:29:48 check the package that is meant to depend on it Mar 19 15:30:12 Also, bitbake -b X -e | grep ^RDEPENDS Mar 19 15:30:28 Jin^eLD: There isn't an RDEPENDS and an RDEPENDS_$packagename set are there? Mar 19 15:30:51 RP: no, only RDEPENDS = "blah" Mar 19 15:32:14 lets see what grep spits out... Mar 19 15:32:44 kergoth: 2003-06-02 21:19:02 was "Initial repository create" by you Mar 19 15:33:00 ah. Mar 19 15:33:04 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bda361cba6cf49d92d21f44c87a9d2f13511d551 Mar 19 15:33:16 so nearly 7 years.. boggles the mind Mar 19 15:33:36 RP: there are indeed several RDEPENDS and RDEPENDS_packagename when I do the grip thing Mar 19 15:33:37 http://pastebin.mozilla.org/709123 Mar 19 15:33:42 total of 3 Mar 19 15:34:02 is it because of inheriting update-rc.d? Mar 19 15:34:15 Jin^eLD: most likely, I've seen that before Mar 19 15:34:35 hm, so what do you suggest? RDEPENDS_${PN} += "curl"? Mar 19 15:34:42 Jin^eLD: yes Mar 19 15:34:57 Jin^eLD: Looking at the log that is exactly your problem Mar 19 15:35:09 thanks Mar 19 15:35:15 kergoth_: Scary timescales :) Mar 19 15:36:43 kergoth_: It was May that year I got a Zaurus iirc Mar 19 15:37:05 I got Zaurus in Feb 2004 Mar 19 15:37:10 September I cracked the 2.6 kernel boot problem Mar 19 15:37:22 and the rest is history Mar 19 15:38:12 I don't remember exactly when I got mine, it was a ways before oe started though, during the developer program Mar 19 15:38:44 kergoth: you started OpenZaurus and then migrated it to be OpenEmbedded Mar 19 15:38:52 yeah Mar 19 15:38:57 s/migrated it/migrated it's build system/ Mar 19 15:39:26 OZ existed for a while before this, originally just a modified rom, then everything building in a buildroot.. pretty sure it was the first buildroot with kconfig :) Mar 19 15:39:33 * kergoth_ gets all nostalgic Mar 19 15:39:46 I got OE booting on sl5500 Mar 19 15:40:10 kergoth_: I jumped straight into the c760 zaurus ;-) Mar 19 15:40:13 you guys gave me r/w due to that Mar 19 15:40:20 I remember my sl5500 and C700 :) Mar 19 15:40:55 I remember day when people on #oe congratulated me getting c760 and I did not had idea what they are talking about Mar 19 15:41:16 hehe Mar 19 15:41:19 until I read oesf forums to notice that one guy from Australia gave me c760+wifi Mar 19 15:41:20 gm all Mar 19 15:41:35 RP: that did work, thanks again Mar 19 15:41:47 I think I still have an sl5600 with stickers on it saying its not supposed to hit the public, EVER Mar 19 15:42:00 Jin^eLD: np, been there before. We should make that easier to catch (e.g. by banning RDEPENDS on its own) Mar 19 15:42:01 kergoth: ;D Mar 19 15:43:19 RP: but RDEPENDS on its on in a recipe is valid? in this case it was just not processed correctly? Mar 19 15:43:35 Jin^eLD: its valid but conflicts with what that class does Mar 19 15:43:38 i.e. I should not switch to always using RDEPENDS_${PN}... Mar 19 15:43:43 I see... Mar 19 15:43:43 Jin^eLD: and its also not recommened Mar 19 15:43:54 you should be using RDEPENDS_${PN}, always Mar 19 15:44:13 oh ok, will fix my recipes then Mar 19 15:44:53 kergoth_: I remember in 2003 when you announced it would take about a year to get OE going. That seemed like an eternity to me Mar 19 15:45:21 Jin^eLD: INHERIT += "recipe_sanity"; bitbake -c recipe_sanity somerecipe may be of use, checks for certain common issues / potential cleanups Mar 19 15:45:48 RP: no, breaks for me for every recipe with classextends Mar 19 15:45:56 RP: recipe_sanity already checks for plain RDEPENDS Mar 19 15:46:00 are you sure you don't have some noncommitted diffs? Mar 19 15:46:01 kergoth: ah, cool, thanks Mar 19 15:46:34 mickeyl: when you said HEAD, was this the 1.8 branch or master? Mar 19 15:46:58 master Mar 19 15:47:12 mickeyl: Something odd is going on :( Mar 19 15:47:18 There shouldn't be any differences like that Mar 19 15:48:26 pb_: great, that sounds like a good start Mar 19 15:48:28 RP: I wonder if in the future we should merge version branches back into master on a regular basis to keep things from deviating in both directions. its pretty common, i think thats how the git folks do their maint branch Mar 19 15:52:25 kergoth_: or we stop having long lived branches. 1.8 has been around way too long Mar 19 15:52:34 well, that too ;) Mar 19 15:52:55 kergoth_: I see 1.10 being a lot less painful in that regard Mar 19 15:53:10 Just need to get on and do it... Mar 19 15:53:30 I'd just want to merge the layers patch really Mar 19 15:53:34 * RP has been thinking a lot about stamps issues Mar 19 15:53:49 I can see a case for dropping stamps and replacing them with checksums Mar 19 15:54:14 I like the idea of per task output tracking and such that you proposed, but I expect it will be awfully invasive. what I suggested could be done entirely in the metadata in a weekend of work Mar 19 15:54:25 * kergoth_ ponders Mar 19 15:54:58 kergoth_: I just don't want to start on a solution which fixed 25% of the problem, then leaves us facing a wall :/ Mar 19 15:55:20 kergoth_: I'm kind of resigned to the fact we'll need to change bitbake in some way to make it work better Mar 19 15:55:33 and that isn't a bad thing as long as we do it properly Mar 19 15:55:38 basically, I want what e2factory has, damnit Mar 19 15:55:44 but with the stuff we have that it doesn't Mar 19 15:55:45 :) Mar 19 15:55:54 kergoth_: this is what I want too Mar 19 15:56:12 hence my desire to thrown away stamps entirely and replace with checksums Mar 19 15:56:22 The stamp code is so so broken :/ Mar 19 15:56:26 I could see using e2factory for bringup or something, but it just doesn't have what we have Mar 19 15:56:31 agreed Mar 19 15:56:38 then the hacks on top of it for pstage just made it messier Mar 19 15:56:42 necessary, but messy Mar 19 15:56:58 right Mar 19 15:57:13 I tried to push the model we had, the cracks appeared Mar 19 15:57:30 can I draw attention to a specific buzilla entry somehow? Mar 19 15:57:32 the worry I have with checksums is that more than just the output of dependent tasks feeds into the task Mar 19 15:57:42 metadata does as well, and we don't track what variables are used by what tasks Mar 19 15:58:14 kergoth_: I have an idea about this - why not checksum the actual functions we run for a given task? Mar 19 15:58:47 that's not enough. Mar 19 15:58:56 that covers changing the function, not changing the variables that it uses Mar 19 15:59:29 kergoth_: if you cover the expanded version? Mar 19 15:59:45 ignoring the fact that we'd have to avoid the different paths changing things Mar 19 15:59:49 and what about d.getVar()? Mar 19 16:00:25 Hmm, I'm primarily thinking of shell functions Mar 19 16:00:45 python tasks are tasks too, you need a way to handle both, if you plan to replace stamps Mar 19 16:00:48 kergoth_: I think we're going to end up with this and a list of variables Mar 19 16:01:14 kergoth_: Well, encapsulating any data into the checksum is better than the current stamps approach ;-) Mar 19 16:01:23 that's a pain to maintain, but does work Mar 19 16:01:33 kergoth_: right Mar 19 16:02:03 kergoth_: I'd love a better idea but thats what I'm currently thinking Mar 19 16:02:09 the problem i see is, if you use a whitelist, the failure mode is use of bad content, particularly for pstage Mar 19 16:02:17 blacklist, the failure mode is just re-executing the task Mar 19 16:02:24 if you see what i mean Mar 19 16:02:33 I do and I agree Mar 19 16:02:48 There are only 400 ish variables so how hard can it be :) Mar 19 16:03:30 I'd say more if I wasn't restrained by NDA Mar 19 16:03:37 but it is viable Mar 19 16:06:25 anyone who knows how to activate CONFIG_FB_CFB_SYS_COPYAREA (and friends) in the kernel config? i'm using devshell and i modify .config before the build, that normaly works fine, but somehow this options get overwritten, i don't know why... Mar 19 16:08:10 marekp: I do not remember exactly anymore, either I had to copy .config to the appropriate defconfig place, and/or also one directory up (I think ther is a copy of it there that comes from the recipe) Mar 19 16:08:26 it's been too long.. but something like that Mar 19 16:12:13 yea i know what file (../defconfig) you mean, so i have to overwrite it maybe Mar 19 16:12:37 ok i try that, thanks Mar 19 16:12:51 I have a doubt about the recipe recipes/linux/linux_2.6.28.bb Mar 19 16:13:02 SRC_URI = "${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2 \ ${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/patch-${PV}.10.bz2;patch=1 \ file://defconfig" Mar 19 16:13:13 marekp: yes, thats what I meant, you copy your newly generated .config over the ../defconfig file Mar 19 16:13:26 what is the value of ${PV} here? Mar 19 16:13:43 2.6.28 of course Mar 19 16:14:18 yes sorry Mar 19 16:14:24 recipe name is PN-PV.bb and linux_2.6.28.bb does not change PV in recipe Mar 19 16:14:45 http://marcin.juszkiewicz.com.pl/2010/03/19/how-time-flies/ btw Mar 19 16:14:58 I don't know why I saw patch-${PV}.10.bz2 but I read patch-2.6.28-${PV}.10.bz2 Mar 19 16:15:10 happens Mar 19 16:15:48 hrw: happy anniversary Mar 19 16:15:55 thx Mar 19 16:16:24 will spend most of time on visiting furniture shops probably Mar 19 16:17:37 btw. i had to modify the .config because normal recipe is not creating a working kernel for my at91sam9260... the architecture is not set to AT91 and some other options are missing... what i dont understand is, that the defconfig in the image directory (output) seems to look perfect, but i did not trace down on that. Mar 19 16:17:51 hrw: I also thought to celebrate 30th anniversary of the bought of my first computer :-D Mar 19 16:17:55 http://en.wikipedia.org/wiki/ZX80 Mar 19 16:18:51 RP: thoughts on http://github.com/kergoth/OpenEmbedded/commits ? Mar 19 16:20:57 stupid question I have Mar 19 16:21:13 kergoth_: The siteinfo one is interesting - I think CONFIG_SITE should be moved into autotools but we should still inherit it in base Mar 19 16:21:14 why there are adduser and useradd commands? Mar 19 16:21:23 cannot one of them be symlink to other? Mar 19 16:21:34 kergoth_: I remember trying this a while back and did see a lot of subtle breakage without it :/ Mar 19 16:21:35 RP: it's only used by a handful of recipes other than autotools, though Mar 19 16:21:43 hrw: they do different things. iirc, adduser is a frontend to useradd. Mar 19 16:21:51 I grepped and added the inherit to anyone using its variables or functions, in that commit Mar 19 16:21:53 kergoth_: I guess you searched and caught them all? Mar 19 16:22:00 kergoth_: fair enough Mar 19 16:22:09 hrw: debian does not prefer useradd but RH does Mar 19 16:22:23 hrw: I asked the same question many times Mar 19 16:22:46 RP: how does that split look as a starting point? we can always move things from there, but it makes it a bit easier to get your head around, I think Mar 19 16:22:48 or better I should say I wondered the sme many times Mar 19 16:22:57 in OE land we have useradd from shadow but adduser in tinylogin Mar 19 16:23:18 hrw: and I NEVER rmember which one is my favourite Mar 19 16:23:32 kergoth_: the webbrowser on this machine is braindead and choked on the larage patch, one second :) Mar 19 16:23:37 haha, oops Mar 19 16:25:15 hrw: yes useradd comes fro shadow Mar 19 16:25:32 useradd/adduser always confuses me, i know one is a frontend to the other, but i can never, ever remember which to use Mar 19 16:25:36 that naming was idiotic Mar 19 16:25:38 kergoth_: I totally agree with those patches Mar 19 16:25:50 kergoth_: One thing though - can we time them with the same changes in Poky, please :) Mar 19 16:25:57 sure, that's fine with me Mar 19 16:26:15 kergoth_: You can add my Acked-by and push if you like ;-) Mar 19 16:26:59 kergoth_: mine too Mar 19 16:27:11 okay, thanks Mar 19 16:27:15 hrw: useradd implements SUS behaviour so its same on all distros but adduser is a convinience script which can vary on distros Mar 19 16:27:32 kergoth_: I'd like to see most of utils.bbclass moving into a bitbake based python library like bb.utils Mar 19 16:27:33 RP: should I go ahead and push today then? will you pull it into poky today, or do you want to hold off? Mar 19 16:27:36 agreed Mar 19 16:27:46 kergoth_: go for it, I'll do Poky to match Mar 19 16:28:11 okay, let me do a couple final sanity checks, then i'll push it Mar 19 16:28:12 kergoth_: if you are afraid of breakage then commit on Monday Mar 19 16:28:29 this will give you (and us) trouble free weekend ;) Mar 19 16:28:34 hehe Mar 19 16:28:43 I should be around this weekend, though, I don't mind babysitting Mar 19 16:30:23 "Use of this historical codebase is strongly discouraged" - tinylogin d: Mar 19 16:32:03 someone here has non-Debian based distro running? Mar 19 16:32:18 hrw: Fedora 12 here Mar 19 16:32:51 Jin^eLD: which language is 'adduser' written in? Mar 19 16:32:56 * kergoth_ just fired up a centos 5.4 VM, but is still getting the necessary packages installed Mar 19 16:33:18 hrw: let me see Mar 19 16:33:26 after ending cooperation with OpenedHand I dropped all Fedora VM images Mar 19 16:34:20 hrw: I'll fetch the sources of the rpm, /usr/sbin/adduser is a binary file but I would assume c or c++, or were you thinking of it as in "what script language"? Mar 19 16:34:32 hrw *g* Mar 19 16:34:58 woglinde: those crazy people which wanted to run Poky on FedoraCore4... Mar 19 16:35:07 hrw: so.. is the info "it's an ELF" enough for you or do you want me to check what sources they are using? Mar 19 16:35:35 would be nice to grab source Mar 19 16:36:12 it's from the shadow-utils package, let me see... Mar 19 16:36:38 Jin^eLD: 0.10 or newer? Mar 19 16:36:54 shadow-utils-4.1.4.2-2.fc12.x86_64 Mar 19 16:37:04 I'm fetching the source rpm now Mar 19 16:37:23 thx Mar 19 16:37:28 np Mar 19 16:38:08 URL: http://pkg-shadow.alioth.debian.org/ Mar 19 16:38:08 Source0: ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-%{version}.tar.bz2 Mar 19 16:38:17 and version is Version: 4.1.4.2 Mar 19 16:38:24 so we go back to base ;D Mar 19 16:38:33 and there are 4 patches used Mar 19 16:38:57 I can put the spec file online if you want to see what they are using/doing Mar 19 16:39:13 would be great Mar 19 16:39:26 officially I do not know anything about rpm packages Mar 19 16:39:26 try http://www.deadlock.dhs.org/jin/shadow-utils.spec Mar 19 16:39:35 got it Mar 19 16:39:40 I could say the same about .deb packages :> Mar 19 16:40:15 if you want those patches too I could extract the source rpm and tar it up for you Mar 19 16:40:39 would be nice Mar 19 16:40:43 you know my email Mar 19 16:40:53 I'll just put it onlone, will be faster Mar 19 16:40:57 if you dont mind Mar 19 16:41:01 sure, fine Mar 19 16:42:29 ha! shadow has contrib/ dir with adduser stuff Mar 19 16:42:33 try http://www.deadlock.dhs.org/jin/shadow-utils-fc12.tar its everything extracted from the source rpm, including the original sources Mar 19 16:43:21 got it Mar 19 16:43:48 k Mar 19 16:45:28 does Koen hang around here? Mar 19 16:45:37 s/hang/hang out/ Mar 19 16:46:03 ~seen koen Mar 19 16:46:07 koen was last seen on IRC in channel #oe, 827d 6h 39m 43s ago, saying: 'I forgot to commit that portion yesterday'. Mar 19 16:46:11 aww Mar 19 16:46:16 it's been a while Mar 19 16:46:30 ~seen _koen_ Mar 19 16:46:32 hrw: i haven't seen '_koen_' Mar 19 16:46:36 I need him to look at one bug Mar 19 16:46:41 filip: /join #beagle Mar 19 16:46:45 in gtk+ Mar 19 16:47:11 hrw: thanks for the hint :) Mar 19 16:47:57 filip: nie ma za co Mar 19 16:48:16 ;) Mar 19 16:53:31 mickeyl: do you have log? Mar 19 16:55:35 JaMa: : http://vala.pastebin.com/PmXNGtx5 Mar 19 16:57:48 mickeyl: EXTRA_OECONF = "--disable-gtk" as in 0.17 should be enough, but I'm curious why this issue is shown only now Mar 19 16:59:52 thanks Mar 19 17:00:27 I'll push it now Mar 19 17:00:36 ln -s useradd $RPM_BUILD_ROOT%{_sbindir}/adduser - nice way Fedora ;D Mar 19 17:07:17 03Martin Jansa  07org.openembedded.dev * r68710643f0 10openembedded.git/recipes/xorg-lib/pixman_0.16.2.bb: Mar 19 17:07:17 pixman_0.16.2: disable gtk (as done in 0.17.*, to break circular dependency gtk+->cairo->pixman->gtk+ and also libtool issue Mar 19 17:07:17 Signed-off-by: Martin Jansa Mar 19 17:08:23 hrw lol Mar 19 17:13:21 have a nice weekend everybody Mar 19 17:30:10 hi anyone that as experience with gpe-dm ? in my case, it is starting a lot of xserver instances until my memory is used up. Mar 19 17:31:46 kergoth_: Are you still planning to land those patches today? Mar 19 17:43:06 03Chris Larson  07org.openembedded.dev * re0503768af 10openembedded.git/classes/base.bbclass: Mar 19 17:43:07 base.bbclass: Add note about base_path_relative Mar 19 17:43:07 Signed-off-by: Chris Larson Mar 19 17:43:08 03Chris Larson  07org.openembedded.dev * r89b7e43371 10openembedded.git/ (7 files in 2 dirs): Mar 19 17:43:08 Initial split of base.bbclass Mar 19 17:43:08 Acked-by: Richard Purdie Mar 19 17:43:08 Acked-by: Marcin Juszkiewicz Mar 19 17:43:08 Signed-off-by: Chris Larson Mar 19 17:43:09 03Chris Larson  07org.openembedded.dev * ra215c2f283 10openembedded.git/ (13 files in 10 dirs): Mar 19 17:43:09 Don't inherit siteinfo in base.bbclass Mar 19 17:43:10 Acked-by: Richard Purdie Mar 19 17:43:10 Acked-by: Marcin Juszkiewicz Mar 19 17:43:11 Signed-off-by: Chris Larson Mar 19 17:43:40 RP: k, done Mar 19 17:47:04 kergoth: cool :) Mar 19 17:47:20 hi Mar 19 17:47:48 hi chouimat Mar 19 17:48:15 grrr not allowed to irc from new job's office :( Mar 19 17:49:00 chouimat: sounds like a challenge? ;-) Mar 19 17:49:37 RP: let's just I'm working from home today and I'm not sure I will renew the contract in June Mar 19 17:50:11 chouimat: fair enough Mar 19 17:51:01 it's more application development than system development ... and the team who designed the platform I have to work with should be killed Mar 19 17:52:34 RP: the best computer on my desk is wasted by running XP and outlook ... the linux box I got is a nice 400Mhz P2 or P3 ... Mar 19 17:54:49 pb_: ping Mar 19 17:54:54 kergoth: yo Mar 19 17:55:39 pb__: for multi-version in one recipe, I'm thinking a "BBVERSIONS" which lists them *all*, rather than a BBVERSIONEXTEND which adds to the original, since the former would allow 'nano.bb', ignoring the default 1.0 variant. thoughts? Mar 19 17:56:08 kergoth: yeah, that would work. I had been thinking in terms of a wildcard expression of some kind. Mar 19 17:56:10 ok to see why when I use gtk the window show on this crappy device but xlib directly doesn't work Mar 19 17:56:35 hmm, that could work too, alternatively we could generate the list of versions with a snippet Mar 19 17:56:44 kergoth: I guess you could make it a regex, which would allow you to either enumerate specific versions as alternatives, or have a more general match. Mar 19 17:57:00 the nice thing about a wildcard is that you don't necessarily have to update the .bb every time a new version gets released. Mar 19 17:57:35 bbiab, gotta go collect my daughter from town Mar 19 17:57:54 true, but wouldn't it have to contact the remote server at parse time to get the list, unless you want it to match 1., and let the version preference control whether it'll be used.. but it could create extranious datastore instances for versions that don't really exist if you do that Mar 19 17:58:00 The question is where the data this regexp works against is generated? Mar 19 17:58:05 right Mar 19 17:58:18 parser fetching over networks causes problems Mar 19 17:58:24 been there, done that :/ Mar 19 17:58:32 if its just a space separated list, it leaves it up to the metadata to determine how to generate that list Mar 19 17:58:32 How many people like SRCREV? :) Mar 19 17:58:37 guh :) Mar 19 17:58:43 kergoth_: agreed Mar 19 17:59:12 so, is it agreed that its more useful to do a BBVERSIONS and drop the base datastore from the variants if set, as opposed to a BBVERSIONEXTEND? Mar 19 17:59:18 what do you think? Mar 19 17:59:36 kergoth: well, in my particular use-case, the versions would all be nailed down externally in a .conf file of some kind. but yeah, I guess you do have a bit of an issue around what to do if the user doesn't specify a version. Mar 19 17:59:47 * pb__ -> Mar 19 17:59:56 pb_: skip the file? Mar 19 18:00:09 hmm Mar 19 18:00:21 kergoth_: I can see a list being a more sane implementation in this case Mar 19 18:00:23 well, it could pull bbversions from the finalised store, so you could use a _pn-whatever override Mar 19 18:00:41 kergoth_: What have we created? :) Mar 19 18:00:54 hehe Mar 19 18:01:12 FOO_pn-bar_virtclass-native_pv-1.0 = "X" Mar 19 18:01:19 haha Mar 19 18:01:48 i'd still like to see a new file format, or a variatn of this one, which allows override blocks Mar 19 18:01:51 1.0 ( Mar 19 18:01:52 a = b Mar 19 18:01:53 c = d Mar 19 18:01:54 ) Mar 19 18:02:01 2.0 ( native ( a = 42 ) ) Mar 19 18:02:03 or something Mar 19 18:02:33 hmm, .bb2 ? Mar 19 18:02:40 yeah, perhaps Mar 19 18:02:54 Change the override character to % as well? Mar 19 18:03:04 while we're at it, change how +=/=+/.=/=./_prepend/_append work too Mar 19 18:03:48 add a -= operator Mar 19 18:03:57 kergoth_: How would you change them? Mar 19 18:04:19 oh, i really want values to be able to be python objects, with typing, too Mar 19 18:04:20 add something to allow variable to be deleted as well... Mar 19 18:04:21 Mar 19 18:04:56 just imagine for a in d.getVar("SOMELIST", True) with no .split() crap ;) Mar 19 18:05:07 Can we also add version deps like x-1.2 DEPENDS y-3.4 Mar 19 18:05:11 but when exported, gets str()d into something useful for shell Mar 19 18:05:26 khem: We could do that now, its a bitbake internals issue Mar 19 18:05:39 khem: I made the parser accept the syntax years ago Mar 19 18:05:51 ok cool Mar 19 18:05:58 I will try it out Mar 19 18:06:06 khem: It doesn't do anything ;-) Mar 19 18:06:11 heh Mar 19 18:06:18 khem: but it won't break the parser which is great for backwards compatibility Mar 19 18:06:31 oh can we add OBSOLETES Mar 19 18:06:51 kergoth_: nice idea :) Mar 19 18:07:07 kergoth_: Seriously though, how would you change the += .+ _prepend ? Mar 19 18:08:10 I'm not sure, but the some things being lazy and others being immediate causes confusion in general Mar 19 18:08:16 include/require/inherit also Mar 19 18:08:18 e.g. if recipe b obsoletes a it then bitbake should not build a if b is already built Mar 19 18:08:19 needs further thought Mar 19 18:08:57 I've often thought that we could make all classes inherited between the config metadata and the class, always before. if the class wants to do something based on a varaible the recipe sets, it can just do so more lazily Mar 19 18:09:28 kergoth_: right, hmm Mar 19 18:09:30 Hi guys, gypsy_svn is failing to download. Mar 19 18:09:33 kergoth: may be we should add a preprocess step Mar 19 18:09:50 MWelchUK: Use the git repo from freedesktop.org Mar 19 18:10:17 OH svn services are slowly being killed off Mar 19 18:10:20 to evaluate variable assignments Mar 19 18:10:45 RP, OK, cheers. Mar 19 18:14:52 git push poky Mar 19 18:15:00 gah :) Mar 19 18:23:32 hmm Mar 19 18:23:42 RP: I can't recall, does it work to do SOMEVAR_oneoverride_anotheroverride? Mar 19 18:49:36 how is FILESPATHBASE searched? libpam-base-files.bb is failing with 256. SRC_URI = "file://pam.d/*" but the files that it wants are in libpam-base-files Mar 19 18:50:23 03Martin Jansa  07org.openembedded.dev * rbad798fb3b 10openembedded.git/conf/distro/include/sane-srcrevs.inc: (log message trimmed) Mar 19 18:50:23 EFL: bump SRCREV Mar 19 18:50:23 * Ecore_data/Ecore_txt was removed so few OLD apps/libs are not Mar 19 18:50:23 buildable anymore Mar 19 18:50:23 * etk/epsilon will be moved to obsolete Mar 19 18:50:24 * other recipes only updated DEPENDS where possible Mar 19 18:50:24 * more info: Mar 19 18:50:25 03Martin Jansa  07org.openembedded.dev * r049e78d95f 10openembedded.git/recipes/efl1/epdf_svn.bb: Mar 19 18:50:26 epdf: disable deprecated etk Mar 19 18:50:26 Signed-off-by: Martin Jansa Mar 19 18:50:27 03Martin Jansa  07org.openembedded.dev * r4ed7c11430 10openembedded.git/conf/distro/shr.conf: Mar 19 18:50:27 shr: use binutils 2.20.1 Mar 19 18:50:28 Signed-off-by: Martin Jansa Mar 19 18:50:28 03Martin Jansa  07org.openembedded.dev * rcfd545deb8 10openembedded.git/recipes/efl1/esmart_svn.bb: Mar 19 18:50:29 esmart: drop epsilon dependency, then we won't get thumb Mar 19 18:50:29 Signed-off-by: Martin Jansa Mar 19 18:51:16 03Martin Jansa  07org.openembedded.dev * r7b52a85404 10openembedded.git/recipes/tasks/ (5 files): Mar 19 18:51:16 tasks: remove etk/epsilon from task recipes Mar 19 18:51:16 Signed-off-by: Martin Jansa Mar 19 18:51:44 re Mar 19 18:52:21 kergoth: actually, thinking about that multi-version thing more, I guess you would/could still have a default version specified in the .bb if the user doesn't pick another, just to make "bitbake foo" work. Mar 19 18:54:19 bitbake foo would work either way, the question is just whether or not we keep the default version / variant Mar 19 18:54:25 what I'm thinking is, if y> Mar 19 18:54:26 > Mar 19 18:54:41 I'm thinking if you want that, you could list it in the variable Mar 19 18:55:13 hmmm Mar 19 18:57:35 RP: thoughts on the add of PV to overrides for bbversions? base.bbclass or bitbake? with bitbake, it could combine the variants, add 1.0-virtclass-native to overrides for each combination Mar 19 18:57:48 * kergoth_ ponders Mar 19 18:58:29 pb__: I figured the default version would be used for the case where the variable isn't set, but what i was wondering was whether to retain the default version + default datastore when the user *does* set it, and I think its agreed that the answer is "no" Mar 19 18:59:43 kergoth: it is fairly important to me that you be able to build multiple versions of the same package in a single bitbake run. Mar 19 19:00:33 i don't see a problem with that, its no different than the extendclass stuff Mar 19 19:00:39 kergoth: but, there is no need to retain the default version if it isn't going to be built. Mar 19 19:01:16 the question was one of usability, not ram usage. does the variable list versions in addition to default, or list all versions you want generated Mar 19 19:01:58 ah, I see. well, I still feel that the variable should be a regex, not a simple list :-} Mar 19 19:02:21 well, as i said earlier probably after you left, the problem is what to apply the regex against Mar 19 19:02:26 poking at upstream at parse time is .. iffy Mar 19 19:02:59 right, but I don't think it should be necessary to poke at upstream; you just need to match it against the version that has been requested by the user. Mar 19 19:03:46 but as you already said, its critical to be able to build multiple versions in one run, so how do you make the determination of which versions the user requested? Mar 19 19:03:53 and where? at parse time, that information isn't yet available Mar 19 19:04:20 the user needs to supply it via either dependencies or the command line. "bitbake foo-1.2 foo-1.3" for example. Mar 19 19:05:22 yes, but again, the question is how to mak ethat determination. you'd have to examine the runqueue Mar 19 19:05:27 which isn't generated until after the parse Mar 19 19:05:32 yet parse time is where variants are generated Mar 19 19:05:41 you'd have to make more fundamental changes Mar 19 19:06:35 hmm Mar 19 19:07:29 yes, it would require some changes to how bitbake thinks about versions. Mar 19 19:09:41 well, to support BBVERSIONS = "1.0.0 2.0.7 2.0.9 git" or something can work today, using the same mechanisms as bbclassextend. we can always enhance the bbversions varaible to support wildcards/regexes Mar 19 19:15:26 * kergoth_ ponders Mar 19 19:18:47 yeah, true Mar 19 19:24:36 ok libpam-base-files does not build possibly because I have prepended my overlay files path to FILESPATHBASE. I fixed it by setting SRC_URI = "file://libpam-base-files" instead of the pam.d/* glob Mar 19 19:26:38 is anyone else seeing bizzare behaviour after today's base.bbclass checkin? Mar 19 19:26:57 what sort of behavior? Mar 19 19:27:08 seems fine here, so far anyway :) Mar 19 19:27:50 for example: openssl-native is rebuilt with every bitbake command Mar 19 19:28:17 i.e. if I bitbake tslib, openssl-native is rebuilt from scratch Mar 19 19:28:27 as far as i know it didn't actually change anything, only moved things around Mar 19 19:28:59 if I do a bitbake openssl-native it completes successfully, but then is rebuilt again on the next bitbake command! Mar 19 19:29:22 hmm Mar 19 19:29:51 odd Mar 19 19:29:54 looking into it Mar 19 19:30:09 anyone have an example of using 'test' in a u-boot script? Mar 19 19:33:33 sakoman: going to bitbake -e openssl-native before and after the change, see what differs Mar 19 19:36:06 03Martin Jansa  07org.openembedded.dev * r185e4f64ec 10openembedded.git/recipes/images/shr-image.inc: Mar 19 19:36:06 shr-image: use install_linguas Mar 19 19:36:06 Signed-off-by: Martin Jansa Mar 19 19:36:06 03Martin Jansa  07org.openembedded.dev * r02d4ca6802 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Mar 19 19:36:06 preferred-shr-version: update automake to 1.11.1 Mar 19 19:36:06 Signed-off-by: Martin Jansa Mar 19 19:36:07 03Martin Jansa  07org.openembedded.dev * rd6f29aecf1 10openembedded.git/recipes/efl1/ (ecore-native_svn.bb ecore.inc ecore_svn.bb): Mar 19 19:36:07 ecore: convert BBCLASSEXTEND Mar 19 19:36:08 * different EXTRA_OECONF weren't used for -native as the diff seems Mar 19 19:36:08 rather unintentional when OECONF was updated only in non-native Mar 19 19:36:09 version, feel free to add it if really needed Mar 19 19:36:09 Signed-off-by: Martin Jansa Mar 19 19:48:13 pb__: master? Mar 19 20:02:43 Anyone have any thoughts on possibly moving the add of the override to OVERRIDES in bitbake rather than the classes, for bbclassextend / bbversions? Mar 19 20:02:52 * kergoth_ isnt sure how he feels about it Mar 19 20:04:20 kergoth_: do you see the same openssl issue? Mar 19 20:05:04 working on something for work at the moment, hold Mar 19 20:05:14 OK Mar 19 20:13:58 mickeyl: good evening Mar 19 20:15:20 hi pb__ Mar 19 20:15:24 i have something very strange going on Mar 19 20:15:31 i will show you a small exceprt of source code Mar 19 20:15:41 which runs fine on i686 Mar 19 20:15:46 but crashes with a null pointer on arm Mar 19 20:16:01 perhaps you spot something obvious that would be dangerous on arm Mar 19 20:16:26 pb__: please have a brief look at https://bugzilla.gnome.org/show_bug.cgi?id=613343 Mar 19 20:22:34 mickeyl: Looks like the sim entry copy is doing something unfortunate? Mar 19 20:24:09 broonie: no, it is null beforehand Mar 19 20:24:39 it is null right after Mar 19 20:24:46 fso_gsm_abstract_at_command_to_int () Mar 19 20:24:54 err, wrong Mar 19 20:24:57 entry = (...) Mar 19 20:25:15 and i can't really see what could go wrong there :/ Mar 19 20:25:27 Eh, 683 is the first one where a nil is reported? Mar 19 20:26:04 Oh, hang on. The code doesn't tie in with the log message. Mar 19 20:26:31 yeah, sorry, it was one debugging run earlier :/ Mar 19 20:26:37 didn't change the behaviour though Mar 19 20:26:39 mickeyl: ok, I'll have a look Mar 19 20:26:44 pb__: thanks Mar 19 20:26:52 It does mean that it's harder to tie the error report in with teh code :/ Mar 19 20:26:54 every g_message ("atcommands.vala:678: number = %p", Mar 19 20:26:55 number) was ok Mar 19 20:27:11 every g_message ("atcommands.vala:681: number = %p, Mar 19 20:27:11 name = %p", entry.number, entry.name); showed nil for number Mar 19 20:27:39 right, so it gets number wrong when you read it out of entry? Mar 19 20:27:40 i have since then change the arguments, but it's always the 2nd argument in the newly born struct that stays null Mar 19 20:27:47 yeah Mar 19 20:27:58 if i manually set it after the init Mar 19 20:27:59 like Mar 19 20:28:07 entry.number = "foo"; Mar 19 20:28:09 then it stays ok Mar 19 20:28:10 what does free_smartphone_gsm_sim_entry_copy() look like? Mar 19 20:28:46 er, sorry, _init() not _copy() Mar 19 20:30:30 one second, it's in another library... Mar 19 20:31:39 http://vala.pastebin.com/FWwR1hZc Mar 19 20:32:30 uuuuuuuh Mar 19 20:32:50 hmm Mar 19 20:32:57 hm, that doesn't look very good Mar 19 20:33:02 that's somewhat strange Mar 19 20:33:07 (*self).number = (_tmp1_ = g_strdup ((*self).number), _g_free0 ((*self).number), _tmp1_); Mar 19 20:33:16 surely the argument to strdup() should be "numbe", not the old value Mar 19 20:33:37 wah Mar 19 20:34:46 ok, so the init func is completely bogus Mar 19 20:35:07 yeah, it is hard to see how that code could work correctly on any arch Mar 19 20:35:24 hmm Mar 19 20:35:36 let me diff that with the code that gets generated on my desktop Mar 19 20:35:46 it is fairly clear from inspection that the "numbe" argument doesn't go anywhere: it's only used in that one g_return_if_fail(). Mar 19 20:36:07 right, good plan Mar 19 20:36:22 ah! Mar 19 20:36:24 void free_smartphone_gsm_sim_entry_init (FreeSmartphoneGSMSIMEntry *self, gint index, const char* name, const char* number) { Mar 19 20:40:55 ok, while that's a good find, i wonder how that can happen Mar 19 20:41:02 it's the same vala version Mar 19 20:41:09 just one is compiled by OE Mar 19 20:41:15 and the other one compiled manually Mar 19 20:41:24 (vala-native, actually) Mar 19 20:42:46 that is rather weird. might be worth diffing the config.status files to see if the oe version is picking up any bogosity from the site files. Mar 19 20:42:57 oh yeah Mar 19 20:45:44 i'm afraid it's quite cluttered :/ Mar 19 20:45:45 http://pastebin.ca/1846041 Mar 19 20:46:31 hrm. different autoconf versions, I guess Mar 19 20:46:40 or different versions of some .m4 file or other Mar 19 20:46:42 yeah Mar 19 20:46:52 hmm, the variables part might be interesting Mar 19 20:47:00 -max_cmd_len='1572864' Mar 19 20:47:00 +max_cmd_len='98304' Mar 19 20:47:06 should not hurt though Mar 19 20:47:55 yeah. that is weird, but seems like it ought to be harmless. Mar 19 20:48:12 rest of the vars look ok to me Mar 19 20:48:21 hmm, k Mar 19 20:48:33 so... dunno. very strange. Mar 19 20:48:57 let me check whether it swallows every last character of struct inits Mar 19 20:49:05 i guess it should blow up in that case Mar 19 21:02:14 heh, I wonder why our landlord thought it was a good idea to install a 130dB siren in our computer room. Mar 19 21:05:08 wah, that's a tad bit on the loud side Mar 19 21:06:45 pb__, broonie: thanks for helping. playya_ and me just found it. the problem is actually in our code, the code we had seen was generated from a Vala source that is generated itself from specs... and as a matter of fact the spec-generator in the preferred version (0.1.3) that is in OE had the bug cutting the last char from the signature :)) Mar 19 21:09:45 03Roman I Khimov  07org.openembedded.dev * re399e99d25 10openembedded.git/recipes/dnsmasq/ (dnsmasq-dbus_2.52.bb dnsmasq.inc dnsmasq_2.52.bb): Mar 19 21:09:45 dnsmasq: add version 2.52 Mar 19 21:09:46 Fixes CVE-2009-2957 and CVE-2009-2958 among other things. Mar 19 21:09:46 Signed-off-by: Roman I Khimov Mar 19 21:09:51 mickeyl, the strange thing is that it strdups the self.number Mar 19 21:09:56 03Roman I Khimov  07org.openembedded.dev * r6476a15dfc 10openembedded.git/recipes/dnsmasq/ (dnsmasq.inc files/init): Mar 19 21:09:56 dnsmasq: add status check to init file Mar 19 21:09:56 Signed-off-by: Roman I Khimov Mar 19 21:11:10 it seems to be a follow up Mar 19 21:11:23 it tries to replace itself Mar 19 21:11:42 maybe we should file a bug for this case Mar 19 21:19:33 yeah Mar 19 21:19:43 Vala should really warn us Mar 19 21:19:51 a self assignment does not make sense usually Mar 19 21:27:19 03Michael 'Mickey' Lauer  07org.openembedded.dev * redfd4c4dd6 10openembedded.git/recipes/vala-dbus-binding-tool/ (2 files): vala-dbus-binding-tool: 0.1.3 -> 0.1.4 Mar 19 21:33:57 hm by the way, can someone please delete my gettext-branch it isnt needed anymore Mar 19 21:38:49 oestats seems to be failing for me, but I'm not sure why. Mar 19 21:39:53 I thought it was because I was trying to use "tinderbox.openembedded.org" instead of "http://tinderbox.openembedded.net", but that doesn't seem to work for me either :-s Mar 19 21:44:20 Ah! I'm using bitbake master - think this is a known issue. Mar 19 21:44:47 bitbake has nothing to do with that Mar 19 21:44:59 its a class in oe Mar 19 21:46:27 kergoth_, http://www.mail-archive.com/bitbake-dev@lists.berlios.de/msg00723.html Mar 19 21:48:47 ahh right, i stand corrected :) Mar 19 21:50:52 kergoth_, I think I'll start using 1.8 branch for now :-) Mar 19 21:52:22 kergoth_: hehe :P Mar 19 21:53:38 argh.. Mar 19 21:53:46 * kergoth_ kicks bitbake/lib/bb/cache.py Mar 19 22:03:25 sakoman: if i bitbake openssl-native, then bitbake openssl-native again, it does nothing. i'll try building tslib Mar 19 22:03:33 hmmm Mar 19 22:03:40 wait, nevermind, bad test Mar 19 22:03:44 * kergoth_ grumbles Mar 19 22:22:07 mickeyl: aha, very good Mar 19 22:22:58 hey pb__ Mar 19 22:23:53 hi ant__ Mar 19 22:24:05 * mickeyl waves goodbye -- see you in a week after our small vacation Mar 19 22:24:47 sakoman: k, looking into it Mar 19 22:26:02 mickey|vacation: enjoy Mar 19 22:26:08 thanks Mar 19 22:29:37 pb__: I'm amazed by the hot thread running on linux-arm-kernel about armv6 vs. highmem. Very interesting bug-chase... Mar 19 22:30:41 ...and this time Russel got bitten by Nicolas and Catalin ;) Mar 19 22:31:24 that's indeed a 'hierarchical' mailing list Mar 19 22:37:10 heh. I haven't read the linux-arm-kernel list for about five years. Mar 19 22:39:29 pb__: Be thankful ;-) Mar 19 22:39:46 kergoth_: Yes, we have expand multiple overrides as long as they're in the right order Mar 19 22:40:05 kergoth_: Whether it should be added to OVERRIDES in bitbake or by the class, good question Mar 19 22:40:19 kergoth_: In the class case there wasn't much complexity by doing it in the class Mar 19 22:40:21 pb__: I had to approach it, was waiting for the LZMA patches Mar 19 22:40:21 I think i'll go with the classes for now, to keep the code in bitbake a bit simpler Mar 19 22:40:25 * kergoth_ nods Mar 19 22:40:47 kergoth_: For versions I suspect it adds a lot of complexity? Mar 19 22:40:58 kergoth_: or are you writing a class for this? Mar 19 22:41:23 pb__: now that we talk, I remember we lack support for cpio.lz and co. Mar 19 22:41:31 not *that* much complexity, i had a version where each set of variants built on top of the previous one for constructing combined overrides and combined values for the returned dictionary Mar 19 22:41:42 but it definitely added some code Mar 19 22:41:43 I mean, LZO will be soon replacing gz Mar 19 22:43:18 iirc this is the suggested compressor for initramfs and kernel, for arm Mar 19 22:43:34 kergoth_: right, I can imagine that Mar 19 22:44:56 * kergoth_ got bit when he had a version that didn't return a "" entry, and various other little quirks he didn't account for at first :) Mar 19 22:45:37 ant__: yeah, I don't think that'd be very hard to do. Mar 19 22:45:39 kergoth_: heh, that class extend code wasn't big but it certainly was scary :) Mar 19 22:45:54 * pb__ bedtime now Mar 19 22:45:56 night all Mar 19 22:46:38 :) Mar 19 22:46:42 night pb__ Mar 19 22:46:51 'night pb__ Mar 19 22:46:54 'nite Mar 19 22:47:41 kergoth_: I'm going to apply this base.bbclass split to poky, then get some sleep ;-) Mar 19 22:48:21 sakoman ran into an issue, its rebuilding things it doesn't have to, very weird, consdiering it just moves bits, shouldn't change anything Mar 19 22:48:24 * kergoth_ is looking into it Mar 19 22:49:22 hi. I'm a user of OE. Mar 19 22:49:32 kergoth_: Have you seen it too? Mar 19 22:49:52 a recent patch came through for the cmake.bbclass from Roman Mar 19 22:49:54 just did, yeah. bitbake openssl-native; bitbake openssl-native -- it builds it both times Mar 19 22:50:05 * kergoth_ scans the classes in the hopes that its obvious :) Mar 19 22:50:46 found it Mar 19 22:50:58 kergoth_: I'm curious... Mar 19 22:51:07 I have tried applying the patch on machine as it was suggested I 'ack' it Mar 19 22:51:34 the patch seems to do what it is supposed to...what is involved in Ack-ing it? Mar 19 22:52:04 ash_: just reply to the list and put Acked-by: You Name Mar 19 22:52:10 ash_: Reply to the patch on the mailing list with an Acked-by line as per the linux kernel development model. Please ensure you understand what that means Mar 19 22:53:06 okay - thanks for the explanation. I had looked on the OE site for guidance but I didn't think to look at Linux Mar 19 22:54:30 03Chris Larson  07org.openembedded.dev * r1369fef494 10openembedded.git/classes/base.bbclass: Mar 19 22:54:31 base: erk, don't remove do_setscene from EXPORT_FUNCTIONS, silly Mar 19 22:54:31 Signed-off-by: Chris Larson Mar 19 22:54:36 RP: had to adjust EXPORT_FUNCTIONS when things moved, but apparently got overzealous :P Mar 19 22:54:51 kergoth: ah Mar 19 22:55:01 kergoth: makes sense Mar 19 22:55:22 RP: an easy question for you: in bitbake.conf we have IMAGE_DEPENDS_cpio.lzma = "lzma-native". In initramfs-kexecboot-image.bb we set IMAGE_FSTYPES = "cpio.gz cpio.lzma" and EXTRA_IMAGEDEPENDS = "". Mar 19 22:55:36 RP: it was noted that if buildhost had no lzma installed, the creation would fail. Mar 19 22:55:52 so DEPENDS = "lzma-native" was added in the image.bb Mar 19 22:56:28 I would think this DEPENDS is superfluous Mar 19 22:57:51 sakoman: should be fine now. Mar 19 22:59:48 ant__: It shouldn't need that, correct Mar 19 22:59:54 RP: so if we add LZO support in bitbake.conf, should we still explicit the dependecy from lzo-native? Mar 19 22:59:56 ant__: sounds like something else is wrong Mar 19 23:00:02 ahrg Mar 19 23:04:55 whew, think this is finally working as hoped Mar 19 23:05:23 maybe Mar 19 23:09:19 damnit Mar 19 23:10:18 kergoth: still problems? Mar 19 23:10:24 * kergoth_ just realized this is completely hosed with the in recipe checksums.. no override specific flags ;) Mar 19 23:10:30 other than that, works great Mar 19 23:10:47 hmm, at least, i don't think flags get merged when overrides are applied Mar 19 23:10:53 * kergoth_ looks Mar 19 23:10:59 kergoth: ah, the BBVERSIONS stuff Mar 19 23:11:05 yeah Mar 19 23:11:15 the other bits seem fine Mar 19 23:12:02 bb.data.update_data is one really lame function name Mar 19 23:12:25 kergoth: but a very clever function :) Mar 19 23:13:16 kergoth: base change pushed into poky too Mar 19 23:13:22 pretty much anyway Mar 19 23:13:34 I'll try and properly sync things up better at some point :/ Mar 19 23:13:48 data_smart says its __setitem__ is deprecated Mar 19 23:13:50 but update_data uses it Mar 19 23:13:52 haha Mar 19 23:14:11 kergoth: you expect consistency? ;-) Mar 19 23:14:22 i know, crazy talk.. Mar 19 23:14:58 * kergoth_ thinks about making update_data merge override var flags into the main var's flags Mar 19 23:16:45 kergoth: Doesn't it do something like that already? Mar 19 23:17:03 I thought renameVar did it? Mar 19 23:17:16 it doesn't use renameVar :P Mar 19 23:17:20 maybe thats the answer then Mar 19 23:17:38 oh, wait, maybe i'm blind Mar 19 23:17:40 :) Mar 19 23:17:46 hmm Mar 19 23:18:00 nope, it doesn't. the only place in that file that uses it is expandKeys Mar 19 23:18:03 * kergoth_ tests Mar 19 23:18:30 ah, I must have fixed the expandKeys failure Mar 19 23:23:02 RP: renamevar only manipulates the prepend/append flags for that, doesn't merge the flags of the old var into the new Mar 19 23:25:54 * kergoth_ mutters Mar 19 23:27:35 kergoth_: if you rename first update_data should handle it Mar 19 23:28:31 I don't see any code in either update_data or renamevar to merge flags Mar 19 23:28:58 hrm Mar 19 23:30:34 also only renames vars which have content, so you can't just SRC_URI_2.0.7[md5sum] without also giving SRC_URI_2.0.7 a value. /me hacks around it for now Mar 19 23:30:40 kergoth_: I'm pretty sure it does Mar 19 23:31:24 03Geetha T  07org.openembedded.dev * r3dbea75bd6 10openembedded.git/conf/machine/omapzoom36x.conf: omapzoom36x.conf: Machine config for OMAP Zoom36x Mar 19 23:31:24 03Geetha T  07org.openembedded.dev * r01b04b9a77 10openembedded.git/recipes/u-boot/u-boot_git.bb: u-boot_git: Added support for OMAPZoom36x Mar 19 23:31:25 03Graeme Gregory  07org.openembedded.dev * raa4f6eb2b5 10openembedded.git/recipes/linux/linux-omap-zoomsync/omapzoom2/logo_linux_clut224.ppm: linux-omap-zoomsync : make logo more generic now recipe has 2 machines Mar 19 23:31:26 03Geetha T  07org.openembedded.dev * rc31ca1edca 10openembedded.git/recipes/linux/ (2 files in 2 dirs): linux-omap-zoomsync_2.6.32: Added support for OMAPZoom36x Mar 19 23:31:27 03Graeme Gregory  07org.openembedded.dev * rccb23a493e 10openembedded.git/contrib/angstrom/sort.sh: Mar 19 23:31:27 contrib/angstrom/sort.sh : add the new omapzoom36x machine Mar 19 23:31:27 Signed-off-by: Graeme Gregory Mar 19 23:31:28 03Graeme Gregory  07org.openembedded.dev * r85561b7406 10openembedded.git/recipes/x-load/x-load_git.bb: Mar 19 23:31:28 x-load_git.bb : fix minor mistake in omapzoom36x version Mar 19 23:31:28 This also needs the u-boot snapshot to exist. Mar 19 23:31:28 Signed-off-by: Graeme Gregory Mar 19 23:31:29 03Geetha T  07org.openembedded.dev * rfe529294f9 10openembedded.git/recipes/x-load/x-load_git.bb: x-load_git: Added support for OMAPZoom36x Mar 19 23:39:10 gm Laibsch Mar 19 23:42:09 'night all Mar 19 23:42:17 night Mar 19 23:45:37 thanks kergoth_ ! I'll pull & give it a try Mar 19 23:48:30 * kergoth goes to unbork do_clean... :P Mar 19 23:48:33 * kergoth shakes head at self Mar 19 23:53:23 03Chris Larson  07org.openembedded.dev * rbcf8d1320f 10openembedded.git/classes/utility-tasks.bbclass: Mar 19 23:53:23 utility-tasks: unbork do_{clean,rebuild,mrproper,distclean} Mar 19 23:53:23 Signed-off-by: Chris Larson Mar 19 23:53:45 * kergoth considers some cleanups Mar 19 23:57:04 argh Mar 19 23:57:21 i thought i had this fixed, but i guess not, now its not obeying my preferred version for the native variant Mar 19 23:57:21 g Mar 19 23:57:22 rr Mar 19 23:59:06 Hey all Mar 20 00:01:49 aha, there we go Mar 20 00:02:43 Does anyone have any idea why I can successfully run "bitbake robostix", but if I add "robostix" to IMAGE_INSTALL I receive the message: Mar 20 00:03:33 "...requires the runtime entity 'robostix' but it wasn't found in any PACKAGE or RPROVIDES variables" Mar 20 00:06:36 toborguru: because the bitbake command takes a build time provider, not a package name Mar 20 00:06:38 binary vs runtime. Mar 20 00:06:45 IMAGE_INSTALL takes binary packages Mar 20 00:06:53 see PACKAGES in the robostix recipe Mar 20 00:07:01 OK, thanks Mar 20 00:07:18 np Mar 20 00:51:09 * kergoth_ grumbles Mar 20 01:05:14 hi folks my libtool task seems to be caught in a constant reconfigure loop Mar 20 01:06:24 odd, never seen that :\ Mar 20 01:06:36 woo, this works now: http://gist.github.com/338382 Mar 20 01:08:18 gah, not quite.. so close Mar 20 01:08:59 oh, right.. putting PV into overrides makes the shit hit the fan in SRCREV recipes Mar 20 01:09:02 grrr Mar 20 01:09:08 srcrev needs to die in a fire Mar 20 01:09:12 actually i have this -> | configure: error: source directory already configured; run "make distclean" there first Mar 20 01:09:19 hrm, maybe not Mar 20 01:09:27 hi there kergoth Mar 20 01:09:31 whatnick: oh, thats almost certainly caused by you trying to build in a dir that has a symlink in it Mar 20 01:09:43 go to the real path, wipe tmp,a nd try again Mar 20 01:09:46 its an autoconf bug Mar 20 01:10:25 hmm i have dirs exported in my profile Mar 20 01:10:33 i have building for gumstix Mar 20 01:10:46 okay then I will remount and NOT symlink :) Mar 20 01:11:11 * whatnick goes off to wipe tmp Mar 20 01:17:16 * whatnick hates autotools Mar 20 01:17:27 when will the world become saner :P Mar 20 01:18:28 its autotools that has made so many architectures support so many common packages Mar 20 01:18:49 I know its grown too smart but dont ignore what it can do Mar 20 01:19:46 and to be fair, its better than homegrown solutions, and doesn't have many dependencies Mar 20 01:20:13 woot! Mar 20 01:20:16 http://gist.github.com/338382 works Mar 20 01:20:22 kergoth++ Mar 20 01:20:30 completely, even the DEFAULT_PREFERENCE_2.2.3 = "-1" causing it to default to 2.2.2 Mar 20 01:20:43 one recipe for multiple versions = win, methinks Mar 20 01:20:52 well i like Cmake Mar 20 01:21:02 because I am a wimpy Mar 20 01:21:10 has anyone made oe work on mingw ? Mar 20 01:21:23 doubtful Mar 20 01:21:32 i remember playing with it at one point, but itd' have a long ways to go Mar 20 01:21:34 same with cygwin Mar 20 01:21:38 and darwin.. Mar 20 01:21:40 :) Mar 20 01:22:13 the git on my vm is behaving strangely with gitorious Mar 20 01:22:14 khem: check out nano.bb on http://gist.github.com/338382 :) Mar 20 01:22:21 * kergoth 'll probably push this to bitbake master soon Mar 20 01:22:27 had to checkout in windows and copy stuff over Mar 20 01:26:27 what are the main blocker on mingw ? Mar 20 01:26:57 been too long, you'd have to try and see Mar 20 01:29:14 well then I make making a gumstix verdex build I will take it through the paces Mar 20 01:31:55 * kergoth tries to fix PV in OVERRIDES Mar 20 01:32:21 hmm Mar 20 01:50:27 well Mar 20 01:50:36 it seems I have f'ed over my debian install Mar 20 01:51:19 doh :( Mar 20 01:55:46 yeah Mar 20 01:56:14 if I trying to upgrade my kernel, it complains something is wrong with udev and I should reinstall it and if I do that it says I should upgrade my kernel first Mar 20 01:57:13 is there any way to report bugs with ? Mar 20 01:57:51 cause the xf86-video-omapfb recipe fails wonderfully at fetch Mar 20 01:58:28 uh, maybe the bug tracker link that's in the topic of the channel? :P Mar 20 01:58:51 shush Mar 20 01:58:54 I knew that Mar 20 02:22:24 well entered a bug Mar 20 02:26:54 kergoth, looks ok Mar 20 02:28:01 kergoth: so now we can have one recipe for all verisons ? Mar 20 02:28:07 thats the idea, yeah Mar 20 02:28:31 hi Mar 20 02:28:36 hey zecke Mar 20 02:28:48 kergoth: isnt that gonna complicate the recipes Mar 20 02:28:51 * kergoth has a few kinks to work out yet Mar 20 02:28:59 or is it optional Mar 20 02:29:00 no more than they already are Mar 20 02:29:04 and yes, its optional Mar 20 02:29:11 there'll be a version override Mar 20 02:30:41 kergoth: I think only difference would be that right now differences are spread across multiple recipes for different versions Mar 20 02:31:03 if we put that all into one .bb file people may get afraid of the recipe :) Mar 20 02:31:05 yes, this would consolidate them, and reduce the boilerplate .bb's that just require the .inc Mar 20 02:31:19 plus, it doesn't have to be just one recipe, either Mar 20 02:31:19 but for some recipes which just bump the version and build identical this is a good idea Mar 20 02:31:21 you could have two recipes Mar 20 02:31:26 one for 2.2.x, one for 2.0.x Mar 20 02:31:27 for example Mar 20 02:31:33 for where the upstream changes happened Mar 20 02:31:36 say, a conversion to autotools Mar 20 02:32:05 oh well. I think having recipe per version conveys more Mar 20 02:32:11 atleast to me Mar 20 02:35:08 * kergoth thinks this is a possible way to alleviate the concerns of those arguing for keeping around old versions in the tree, since it'd let you still build them if you want, and the default behavior of the metadata will be the common bits.. so old versions automatically get the fixes Mar 20 02:38:06 anyone else having trouble with xf86-video-omapfb.git in oe.dev? Mar 20 02:38:20 in building oe.dev for beagleboard to be specific Mar 20 02:41:19 kergoth, sometimes patches are specific to versions etc. IMO they will rot as they do now even in a single recipe Mar 20 02:41:49 if you add a new patch, either you generate it for all the versions and add to the recipe, or not, and let them rot Mar 20 02:41:49 b Mar 20 02:41:50 ut Mar 20 02:41:50 Mar 20 02:41:58 but at least the rot wont' clutter up the repository ;) Mar 20 02:42:04 it will make it so difficult to make changes to recipes as well Mar 20 02:42:16 what do you mean? Mar 20 02:42:54 as i said, its optional, so recipes that have massive differences between versions don't have to use it, but its more likely those changes are bound to a range of versions than just one Mar 20 02:42:59 because if I care about 2.2.4 and recipe build 2.2.0 - 2.2.5 then I have to make sure that my change does not impact other versions Mar 20 02:43:03 its error prone Mar 20 02:43:14 no Mar 20 02:43:23 you're free to make your change version specific, if you're too lazy to make it work for the others Mar 20 02:43:31 do_configure_append_2.2.4 Mar 20 02:44:05 I dont know may be I am stuck with current naming conventions technically I dont see many merits Mar 20 02:44:07 SRC_URI_append_2.2.4 .. Mar 20 02:44:25 i don't see how speeding up repository parse time and uncluttering the repository isn't a merit Mar 20 02:44:38 same for reducing useless duplication of metadata Mar 20 02:45:12 I guess its better to present both cases to a newbie and ask him what he thinks is better Mar 20 02:46:06 speeding up parsing how much ? Mar 20 02:46:16 parsing one recipe is quite a bit faster than multiple Mar 20 02:46:23 which is one of the advantages of BBCLASSEXTEND Mar 20 02:46:44 is there a way to only parse the bb's which are to be built ? Mar 20 02:46:45 hard to say a hard number without converting more recipes to it Mar 20 02:46:52 uh Mar 20 02:46:57 you don't know what you're building until the recipes are parsed. Mar 20 02:47:05 you have to parse them to get the deps and generate teh runqueue Mar 20 02:47:36 we could read the version info from the recipe names Mar 20 02:48:01 and PREFERRED_VERSIONS to chose the recipes isnt it Mar 20 02:48:34 generate the dependencies as we go parsing Mar 20 02:48:40 preferred_versions + preferred_version_foo + default_preference in every recipe Mar 20 02:48:43 so no, afraid not Mar 20 02:48:45 would that be possible ? Mar 20 02:49:27 hmm yeah DEFAULT_PREFERENCE Mar 20 02:50:03 nevertheless some recipes can be converted Mar 20 02:50:05 may be Mar 20 02:50:07 there are possibilities, but difficult to cover every case Mar 20 02:50:25 frankly it takes 6 hours to build my image Mar 20 02:50:32 phil was talking about doing something like this bbversions, but a regex, and matching it against the user requested versions somehow, so it only generates variants for the versions you want Mar 20 02:50:35 and I can spare 5 mins for parsing if you ask me Mar 20 02:51:17 well, not everyone feels that way Mar 20 02:51:33 it's not statistically significant, but from a user experience standpoint its an annoyance Mar 20 02:51:52 I was talking about bitbake to new users or some users who wants to use it Mar 20 02:52:12 and one of the biggest hurdle for them is learn bb syntax Mar 20 02:52:33 and someone said rpm spec files are cleaner Mar 20 02:52:36 agreed, there are many things we could do to improve the file format Mar 20 02:52:44 RP and I were talking about going for a .bb2 format at some point Mar 20 02:53:43 so I feel this will create more confusion for a writer of bb file Mar 20 02:54:04 maybe not for people who know bbfiles well Mar 20 02:54:06 what part of "optional" is failing to sink in? Mar 20 02:54:23 optional means it will be used Mar 20 02:54:30 where appropriate, yes Mar 20 02:54:33 and if its for one or for all it doesnt matter Mar 20 02:54:51 it has to be tought/learnt that with bitbake it can happen this way too Mar 20 02:54:54 that's ridiculous, of course it does Mar 20 02:54:59 learn what? Mar 20 02:55:02 its one new variable Mar 20 02:55:04 @#$@# Mar 20 02:55:09 forgot there is an online builder Mar 20 02:55:10 the rest is overrides, as used everywhere else in oe Mar 20 02:55:17 I Could just build my x11-image thre Mar 20 02:56:14 kergoth: oh well. Its fine. Mar 20 02:56:57 this will I guess make upgrade also interesting for people Mar 20 02:57:16 of course not, nothing will use it until it makes it into a release which becomes the minimum bitbake version requirement Mar 20 02:57:21 which isn't happening to master anytime soon Mar 20 02:57:23 it's not going into 1.8 Mar 20 02:58:56 kergoth: may be finding ways to select 'recipes to be built' for a given profile can help in reducing parse time too Mar 20 02:59:24 may be have a pass in bitbake where it does just that and then does the real parsing Mar 20 02:59:24 doubtful. **** ENDING LOGGING AT Sat Mar 20 02:59:58 2010