**** BEGIN LOGGING AT Mon Mar 22 03:00:02 2010 Mar 22 04:47:01 zecke, ping Mar 22 04:49:56 yes Mar 22 04:50:38 was wondering if you had any more feedback on my grip upgrade recipe Mar 22 04:51:13 and if not, when you might be thinking of committing it (not intending to nag, but it would be a big morale booster for me) Mar 22 04:54:34 The latest one is this: http://patchwork.openembedded.org/patch/1766/ Mar 22 04:55:04 zenlinuxPDX: it looks fine, I will try to apply it today. sorry about the delay Mar 22 04:55:23 no problem at all - I really appreciate it Mar 22 04:55:49 been trying to contribute something for a week or so now, just hoping something actually makes it in :) Mar 22 06:06:45 zenlinuxPDX: I try to build pulseaudio but my m4 is in a infinite loop :( Mar 22 06:07:22 yikes, that's no good Mar 22 06:08:13 yesterday on this channel there was some discussion of a bug which caused some package to keep getting rebuilt - it might have been openssl Mar 22 06:08:29 not sure if there was any resolution to that - kergoth_ would probably know Mar 22 06:11:08 * zenlinuxPDX is off to bed Mar 22 06:18:51 kergoth_: ping? Mar 22 06:18:59 zenlinuxPDX: was this about recursion on finding the endianes? Mar 22 06:19:28 zecke, I'm not certain. I thought it had something to do with changes to base.bbclass Mar 22 06:19:45 I would have thought by now they had been resolved. Have you done a pull recently? Mar 22 06:20:36 zenlinuxPDX: hehe, good point Mar 22 06:30:58 Hi, How to use pwclient Mar 22 06:35:03 bala_holmes: what did you try so far? Mar 22 06:36:41 I need to check my patches status Mar 22 06:37:56 My patches are not present in "http://patchwork.openembedded.org/project/openembedded/list/" Mar 22 06:38:02 ?? Mar 22 06:47:02 bala_holmes: no need to msg me Mar 22 06:47:16 ok Mar 22 06:47:51 bala_holmes: which address did you use for sending your patch? Mar 22 06:49:11 zecke : openembedded-devel@lists.openembedded.org Mar 22 06:49:37 zecke : for review and commit... Mar 22 06:50:00 bala_holmes: and where did you send it from? Mar 22 06:52:06 from '"balakrishnan@e-consystems.com" mail id Mar 22 06:53:46 zecke : I am not getting ur question... Mar 22 06:59:27 03Holger Hans Peter Freyther  07org.openembedded.dev * r888edecd1b 10openembedded.git/contrib/qa/oe_audit.py: Mar 22 06:59:27 oe_audit.py: Properly handle used version.. Mar 22 06:59:27 There might be a third column for -s and we want to Mar 22 06:59:27 use that one. It seems bitbake is a bit confused about Mar 22 06:59:27 latest vs. current... and it is helping. Mar 22 06:59:27 03Holger Hans Peter Freyther  07org.openembedded.dev * rfc461bbba2 10openembedded.git/contrib/oeaudit/oe_audit.py: oeaudit: Use optparse to specify the parameters Mar 22 06:59:28 03Holger Hans Peter Freyther  07org.openembedded.dev * r654f95c329 10openembedded.git/contrib/ (4 files in 2 dirs): Mar 22 06:59:29 oeaudit: Move the oeaudit into a new subdirectory and split it up Mar 22 06:59:29 * OE should contain OE related handling Mar 22 06:59:29 * FreeBSD should contain the handling of FreeBSD specific things Mar 22 06:59:30 like the auditfile format, mapping BSD names to OE.. Mar 22 06:59:30 03Holger Hans Peter Freyther  07org.openembedded.dev * r054df308d4 10openembedded.git/contrib/oeaudit/ (freebsd.py oe_audit.py): oeaudit: Do the PR thin inside the freebsd config. Mar 22 06:59:31 03Holger Hans Peter Freyther  07org.openembedded.dev * rd0263eb39f 10openembedded.git/contrib/oeaudit/oe_audit.py: oeaudit: Print a friendly message when the bitbake module can not be found Mar 22 06:59:40 03Holger Hans Peter Freyther  07org.openembedded.dev * r950e9fd872 10openembedded.git/contrib/oeaudit/freebsd.py: oeaudit: Add the FreeBSD revision to the package version. Mar 22 07:32:08 03Steffen Sledz  07org.openembedded.dev * r30e7b3d1a0 10openembedded.git/recipes/libunwind/libunwind.inc: Mar 22 07:32:08 libunwind: unneeded empty DEPENDS var removed Mar 22 07:32:08 Signed-off-by: Steffen Sledz Mar 22 08:21:03 good morning Mar 22 08:48:56 03Koen Kooi  07org.openembedded.dev * rb3536b21d5 10openembedded.git/recipes/sysvinit/sysvinit_2.86.bb: sysvinit: bump PR for license change Mar 22 09:20:21 hi, I have a problem with xextproto-70-includes_7.0.5.bb: the fetch fails and I can't find the xextproto-70-includes-7.0.5.tar.bz2 source package. I noticed the package is searched at this urls: http://sources.openembedded.org//xextproto-70-includes-7.0.5.tar.bz2 and http://xorg.freedesktop.org/releases/individual/proto/xextproto-70-includes-7.0.5.tar.bz2;name=archive but each other are broken. Mar 22 09:20:32 how can i fix this problem? Mar 22 09:21:24 hi Mar 22 09:27:48 how can i add and build my kernel to OE. Mar 22 09:28:40 manz: which version? Mar 22 09:29:06 my own modified version 2.6.22 Mar 22 09:29:29 manz: learn from recipes/linux/linux_2.6.22.bb Mar 22 09:29:44 ok thanks Mar 22 09:29:58 manz: it's quite easy Mar 22 09:30:10 ok Mar 22 09:30:16 manz: of course you must have your machine patches Mar 22 09:31:00 manz: I am going to submit a new machine in a few minutes, so you can learn exactly how I added it into linux_2.6.28.bb for example Mar 22 09:31:10 no need for that, you can also store the complete source locally Mar 22 09:31:14 which is dirty :P Mar 22 09:31:14 cool Mar 22 09:31:43 yeah, I still have to submit my SBC6020 patches :+ Mar 22 09:32:18 mckoan: ping me once u are done. Mar 22 09:34:43 manz: now Mar 22 09:34:56 ok Mar 22 09:35:09 zenlinuxPDX: ping? Mar 22 09:36:39 03Marco Cavallini  07org.openembedded.dev * r0ea061a77f 10openembedded.git/recipes/linux/linux-2.6.28/mh355/ (defconfig linux-2.6.28.10-at91-mh.patch): Mar 22 09:36:39 linux-2.6.28/mh355/linux-2.6.28.10-at91-mh.patch: added patches for machine Microhard mh355 Mar 22 09:36:39 * added recipes/linux/linux-2.6.28/mh355/defconfig Mar 22 09:36:41 03Marco Cavallini  07org.openembedded.dev * rb80f71438a 10openembedded.git/recipes/linux/linux_2.6.28.bb: linux_2.6.28.bb: added patches for machine Microhard mh355 Mar 22 09:36:42 03Marco Cavallini  07org.openembedded.dev * rf2ef5d637d 10openembedded.git/MAINTAINERS: MAINTAINERS: added myself as mantainer of machine Microhard mh355 Mar 22 09:36:43 03Marco Cavallini  07org.openembedded.dev * r1b30f674da 10openembedded.git/conf/machine/mh355.conf: machine/mh355.conf : Added new Microhard MH355 machine based on AT91SAM9263 Mar 22 09:36:43 03Marco Cavallini  07org.openembedded.dev * rea5966cee6 10openembedded.git/conf/machine/mh355.conf: mh355.conf: Added producer website to machine conf Mar 22 09:39:49 someone posted yesterday the problem..: http://pastebin.com/kNQh9hzU Mar 22 09:41:52 03Marco Cavallini  07org.openembedded.dev * r7284b51dfd 10openembedded.git/recipes/linux/linux-2.6.28/mh355/linux-2.6.28.10-at91-mh.patch: linux-2.6.28.10-at91-mh.patch: removed trailing whitespaces, please apologize Mar 22 09:45:10 claudiuM: looks like you can't get sources of xextproto-70-includes-7.0.5.tar.bz2 Mar 22 09:46:16 the xextproto-7.0.5.tar.bz2 instead are available, but i guess it needs the headers Mar 22 09:49:45 morning Mar 22 09:50:21 morning all Mar 22 09:52:53 so how can i do if the sources of xextproto-70-includes-7.0.5.tar.bz2 are not available? Mar 22 09:53:01 how/what Mar 22 09:54:08 I'm compiling Angstrom for the BeagleBoard, and want to get started with SDKs. Which Meta-package could/should I use? Mar 22 09:56:57 claudiuM: 1.retry maybe today are ok 2.find a different source Mar 22 09:59:38 hi, anyone has an idea of what recently changed in regard to endian handling? Mar 22 09:59:51 I see libsamplerate0 failing, ettercap-ng is failing in a nice way too Mar 22 10:00:18 I have a build that Mar 22 10:01:03 Oops. I have a build of a working rootFs. Can I create an SDK based on that one? Mar 22 10:06:19 tasslehoff: on a rootfs? do you plan to compile under qemu? Mar 22 10:06:35 tasslehoff: the way that works better is to use meta-toolchain and give that to people Mar 22 10:10:45 zecke: I'm fumbling in the dark, but I think the latter is what I want :) I don't need qemu Mar 22 10:14:01 zecke: what I want, is to let other devs here compile their applications without compiling toolchain and the entire rootfs every time. Doing "bitbake meta-toolchain" now, to see how far that will take me :) Mar 22 10:19:34 MWelchUK_work: hi Mar 22 10:19:50 hrw, hi Mar 22 10:20:10 hrw, Just looking into task-proper-tools Mar 22 10:21:41 hrw, I assume at the moment there isn't anyway to switch between a busybox and a task-proper-tools build whilst using the same image recipes? Mar 22 10:24:11 good morning Mar 22 10:25:20 MWelchUK_work: yep, your one is nice because it replace busybox package itself. task-proper-tools is extension for busybox based system Mar 22 10:25:35 MWelchUK_work: in my rootfs I have task-boot without busybox dependency Mar 22 10:25:48 03Martyn Welch  07org.openembedded.dev * rc548cd3617 10openembedded.git/recipes/ettercap/ettercap-ng_0.7.3.bb: Mar 22 10:25:49 ettercap-ng: Pass location of ncurses Mar 22 10:25:49 Ensure that ettercap uses the ncurses libs from the staging include Mar 22 10:25:49 directory during configuration Mar 22 10:25:49 Signed-off-by: Martyn Welch Mar 22 10:25:49 Signed-off-by: Holger Hans Peter Freyther Mar 22 10:25:50 03Enrico Scholz  07org.openembedded.dev * r3510d2ed15 10openembedded.git/classes/rm_work.bbclass: Mar 22 10:25:50 rm_work.bbclass: reordered 'rm $dir -rf' arguments Mar 22 10:25:51 Using an 'rm -rf $dir' ordering is more portable. Mar 22 10:25:51 Signed-off-by: Enrico Scholz Mar 22 10:25:52 Acked-by: Roman I Khimov Mar 22 10:25:52 Signed-off-by: Holger Hans Peter Freyther Mar 22 10:25:53 03Scott Garman  07org.openembedded.dev * r7b6ea7669e 10openembedded.git/recipes/grip/ (grip-3.3.1/no-host-includes.patch grip_3.3.1.bb): Mar 22 10:25:53 grip: Upgrade to 3.3.1 Mar 22 10:25:54 * Latest development version (should be stable, same version is in Mar 22 10:25:54 Debian Stable) Mar 22 10:26:14 MWelchUK_work: oh, sorry for your extra work on sending an updated patch. Mar 22 10:26:18 hrw, yes - my plan was to move to something like a virtual_provider for the "base_tools" ala busybox. Mar 22 10:26:29 zecke, np Mar 22 10:27:07 zecke, I use stgit to manage patches on top of git, so editing them is rather trivial. Mar 22 10:27:20 MWelchUK_work: what about extending task-proper-tools with your busybox-alt contents and create busybox-empty just for replacement of busybox with task-proper-tools? Mar 22 10:29:22 hrw, what I'll probably do for now is just have busybox-alt require task-proper-tools. Mar 22 10:29:24 MWelchUK_work: could you check if ettercap-ng is still building for you? I think there might have been something in OE that broke stuff Mar 22 10:30:47 zecke, will do. Mar 22 10:31:47 hrw, as I said in the cover mail, we did it that way as a fast prototype. Really I think task-base needs to be modified to make it more transparent about that is going on, Mar 22 10:32:35 hrw, I think having the option to build with or without busybox should be an option to build with glibc or ulibc. Mar 22 10:33:06 hrw, hmm, there should have been a "like" in there somewhere :-s Mar 22 10:34:08 ;) Mar 22 10:34:53 MWelchUK_work: for today I plan to prepare some backports from .dev to stable/2009 for my work - will check your changes later Mar 22 10:35:59 hrw, ok - we use stable/2009 as well, infact I've just been moving a whole load of stuff from an overlay we used to use to patches on stable/2009 and dev so that we can push most of it back! Mar 22 10:37:45 hrw, I've kinda realised that overlays don't work well for modifications when you are developing over extended periods of time - things get stale fast. Mar 22 10:38:34 Additions, fine. Modifcations, better to use patches directly to OE tree. Mar 22 10:39:19 I am using meta-oe/ directory for things which needs to be pushed back to OE - so far I have ~10 dirs there Mar 22 10:40:52 The problem I have found is that, especially with dev, the packages in the main tree change, then it becomes more and more difficult to work out which changes are improvements in the OE tree and which are changes you have made. Mar 22 10:42:18 yep Mar 22 10:43:09 After having a lot of success using stgit (bit like quilt) on top of git when doing kernel work - I have started using that for OE as well. Mar 22 10:43:24 I use branches Mar 22 10:46:34 * MWelchUK_work really needs to learn more about git. Mar 22 10:47:27 claudiuM, about xextproto-70-includes-7.0.5.tar.bz2 I can't find another source either. And not even a message about its removal from http://xorg.freedesktop.org/releases/individual/proto/ Mar 22 10:47:41 asking on #xorg Mar 22 10:48:49 yes..i searched it too but can't find any source Mar 22 10:49:19 ok, I asked there, let's what they tell us Mar 22 10:49:31 ok, thanks Mar 22 10:52:14 zecke, builds "running". I just cleaned ettercap-ng, it appears to be building new versions of autoconf and automake - which makes me nervous :-) Mar 22 10:54:16 MWelchUK_work: hehe, I agree... :} Mar 22 10:59:22 claudiuM: you may also ask to Stanislav Brabec who created xextproto-70-includes_7.0.5.bb Mar 22 11:02:11 ok, I ask it here too, maybe someone have it: Mar 22 11:02:11 hi, if someone has the source package xextproto-70-includes-7.0.5.tar.bz2, can upload it on the angstrom mirror? thank you very much Mar 22 11:02:47 I lack it Mar 22 11:05:05 MWelchUK_work: I will send stable request for shadow and procps Mar 22 11:08:21 hrw, sorry I don't follow. Mar 22 11:08:36 moment Mar 22 11:12:02 hrw, Ah, ok :-) Mar 22 11:18:00 The build of meta-toolchain worked. but I'm unsure where to go next. What's a common way to work with this? I want the devs to be able to use my SDK, and develop applications that they can link with the correct versions of e.g. linux includes. I (think I) want to be able to compile and release a rootfs, that the other devs can develop and put applications into. Does that make sense? Mar 22 11:20:12 tasslehoff: with the result of the SDK people can write software against the libs of your distro/rootfs Mar 22 11:20:36 tasslehoff: you will still need a way to package the sw of your colleagues Mar 22 11:32:29 zecke, yup - failing for me now as well. Mar 22 11:36:34 MWelchUK_work: *sigh*, I would asume that the AC_DEFINE now needs a third parameter Mar 22 11:40:07 zecke, Is this what you are getting: http://pastebin.ca/1849125 Mar 22 11:40:21 zecke: So if I compile meta-toolchain and basic-rootfs, the devs can unpack basic-rootfs and link against libs. I could then pack a non-basic-rootfs containing packages or binaries to be installed by a script at first boot with the new rootfs? Mar 22 11:40:33 if so, yippi :) Mar 22 11:42:15 tasslehoff: a rootfs is a for a device Mar 22 11:42:37 tasslehoff: it doesn't ship with -dev packages. there is no point to give it to a dev, unless you want him to run it Mar 22 11:44:00 zecke: true. how can I provide the libs and include that the devs need? Mar 22 11:44:10 zecke: thanks for bearing with me :) Mar 22 11:45:57 tasslehoff: it is in the meta-toolchain. If you want to install additional libs you can look at meta-toolchain-qte, or just change meta-toolchain (or the related task) Mar 22 11:46:15 tasslehoff: if you properly configure your devs can even do opkg-target install libssl-dev to install additional libs Mar 22 11:47:09 tasslehoff: we do have some words for the meta-toolchain(-qte) in the wiki Mar 22 11:47:16 tasslehoff: make that documentation Mar 22 11:52:26 morning Mar 22 12:09:06 zecke: yeah, I read that one. Mar 22 13:03:28 we need to describe patches Mar 22 13:03:43 I am considering dropping old patches on update of recipes Mar 22 13:04:35 khem: ping Mar 22 13:04:59 khem: recipes/util-linux-ng/util-linux-ng-2.14/util-linux-ng-replace-siginterrupt.patch Mar 22 13:05:22 khem: recipes/util-linux-ng/util-linux-ng-2.14/util-linux-ng-replace-siginterrupt.patch is your patch added in March 2009. Was it ever sent upstream? Mar 22 13:33:25 I thought if I did 'bitbake virtual/kernel -c menuconfig; ; bitbake console-image' that my new image would reflect my kernel config changes. It doesn't. What am I missing? Mar 22 13:39:02 mikeul after doing the menuconfig force a recompile of the kernel before baking console-image Mar 22 13:39:17 mikeul: this is done by bitbake -c compile -f virtual/kernel Mar 22 13:39:41 actually I tried that, too. I'll do it again... Mar 22 13:41:34 after a menuconfig i normally do the -c compile-f then bitbake virtual/kernel Mar 22 13:41:57 you might also choose to overwrite the std defconfig file in the recipes dir with menuconfig Mar 22 13:52:01 gm Mar 22 13:52:23 gm sakoman Mar 22 13:52:43 anyone else getting a build failure on tslib? I get: Mar 22 13:52:45 | arm-angstrom-linux-gnueabi-libtool: install: error: cannot install `linear.la' to a directory not ending in /usr/lib/ts/ Mar 22 14:01:43 eFfeM: I must be doing something dumb. I'm looking at /proc/config.gz on the board to determine if my config changes have been made, and they have not. Mar 22 14:02:09 eFfeM: but here's a clue, regarding the naming of the images... Mar 22 14:03:44 eFfeM: wait, I think I see my error Mar 22 14:07:58 eFfeM: OK, I had compounded my problems with a silly mistake. But why is it necessary to force the compile after menuconfig? Changing the config isn't enough for bitbake to recompile? Mar 22 14:10:24 I guess bitbake is based on a dependence between tasks, and not on mod times of files, like make is. And compiling isn't dependent on makeconfig ? Mar 22 14:19:05 mikeul, I believe that's the case. Mar 22 14:50:18 morning Mar 22 14:50:47 hi kergoth Mar 22 14:51:44 hey hrw Mar 22 14:51:51 how's it going? Mar 22 14:51:58 * kergoth_ yawns Mar 22 14:54:42 bb in few Mar 22 14:58:37 hi kergoth Mar 22 14:58:57 hey Mar 22 15:00:47 hi, all! Mar 22 15:01:09 do anybody use normal syslogd/klogd with any OE distro? Mar 22 15:04:09 it installs binaries in weird places (/usr/bin instead of /sbin) and doesn't handle conflicts with busybox-syslog. Is there some proper recipe somewhere or I need to craft my own from scratch? Mar 22 15:05:56 how to generally get rid of busybox syslogd in OE without patching appropriate recipe? (I want to live properly with overlays without touching original recipes while unnecessary) Mar 22 15:10:06 kergoth, gm Mar 22 15:10:49 Hm, just noticed that my window was scrolled up - doh! Mar 22 15:10:57 :) Mar 22 15:14:03 slapin: Sounds like that need update-alternatives Mar 22 15:14:20 kergoth: No more problems with those file moves? Mar 22 15:14:35 nope, seems solid now Mar 22 15:14:41 haven't heard any complaints since Mar 22 15:14:56 kergoth: cool :) Mar 22 15:15:20 RP, which files? Mar 22 15:15:27 that multi-version crap ended up being a giant pain in the ass Mar 22 15:15:43 * kergoth started trying to make every release version of nano that exists build :) Mar 22 15:16:09 I think some autoconf/autotool changes has killed ettercap-ng. Mar 22 15:16:41 kergoth: I can imagine it creating a lot of problems Mar 22 15:16:57 kergoth: Did you get it working? Mar 22 15:16:58 it got me thinking though. Mar 22 15:17:01 Un-less my patch somehow works fine as a local patch and not when applied to dev :-s Mar 22 15:17:23 Every upstream change isn't ever intended to be for just one version. no changes are temporary, or intended that way.. more likely, a change lasts until another change occurs that makes the previous bits no longer applicable Mar 22 15:17:37 so if you created a set of recipes, one for each range, you could make every version buildable Mar 22 15:17:46 its like the minrev/maxrev stuff Mar 22 15:17:49 only for versions Mar 22 15:18:29 kergoth: right. But is that useful? Mar 22 15:19:30 that's a good question, and that's where I stand now, wondering if this whole thing is *really* useful or not Mar 22 15:19:36 it was a fun exercises, but now i wonder.. Mar 22 15:19:56 it might make it easier for branched off repositories to stay in sync if we kept old versions Mar 22 15:20:09 and with this it doesn't create nearly as much clutter in the repository, though it does produce extra datastores Mar 22 15:21:19 kergoth: I don't know if it will encourage people to keep old versions "working" though Mar 22 15:21:26 I'm still not convinced there is any problem keeping old versions around :) Mar 22 15:21:45 Crofton|work: there are advantages and disadvantages Mar 22 15:21:46 MWelchUK_work: yeah, I see breakage in libsamplerate0 too Mar 22 15:21:51 MWelchUK_work: and with endianess too Mar 22 15:21:55 rp yep Mar 22 15:21:55 RP: well, I think it would make it easier, since changes to a given recipe automatically affect the other versions in the range Mar 22 15:21:57 Crofton|work: I know with Poky I like having it lean+mean ;-) Mar 22 15:22:12 but you have a much more constrained audience Mar 22 15:22:13 kergoth: but will people actually consider that Mar 22 15:22:14 I also have a script that can run a given task for every variant version of a recipe that exists, which makes it easier to test Mar 22 15:22:36 quite frankly, I am to the point of suggesting anyone how thinks old version must go Mar 22 15:22:40 RP: the thing is, this issue exists now, people change things for one recipe, and they all end up bitrotted Mar 22 15:22:42 should switch to Poky Mar 22 15:22:51 honestly, i'd rather they made teh change and broke the builds for the other versions than the other ones got bitrotted Mar 22 15:22:57 you can always fix the builds of the other versions Mar 22 15:23:00 bbiab Mar 22 15:23:02 but keeping things sane is much more difficult Mar 22 15:23:07 heh Mar 22 15:23:26 kergoth: Right, its a difficult one Mar 22 15:23:36 Crofton|work: heh :) Mar 22 15:23:53 also, not every recipe would need to leverage this, or add old versions to it, of course Mar 22 15:23:57 i dunno Mar 22 15:24:10 maybe i should send out a mail on the list, get thoughts Mar 22 15:24:25 kergoth: could do. How ugly was the code in bitbake in the end? Mar 22 15:24:42 its on github, hold Mar 22 15:25:03 http://github.com/kergoth/BitBake/commits/bbversions should work Mar 22 15:25:18 there's also a gist where i was playing with nano Mar 22 15:25:39 http://gist.github.com/338382 Mar 22 15:25:58 this is before i started making them all build and split it up into one recipe per range and the like, it was just to show the syntax Mar 22 15:26:07 that checksum checking works Mar 22 15:27:40 kergoth: could be worse code wise although those loops are looking a like scary :) Mar 22 15:27:55 I wanted to make it easy to add new sets of variants if we ever wanted to Mar 22 15:28:06 each create_variants call is based on the variants before it :) Mar 22 15:28:23 that way the natives are created for each version, and the like Mar 22 15:28:41 I'm sure the code can be improved, I messed with it a lot to get it working at all :) Mar 22 15:30:58 you don't want to know how long it took me to realize that for the pv not in BBVERSIONS case I had to re-finalize a new datastore for it, since the 'd' was already finalized with the old version.. Mar 22 15:30:58 * kergoth shakes head Mar 22 15:31:27 erm, am i back? stupid wifi Mar 22 15:31:38 kergoth, yup Mar 22 15:31:51 k, thanks Mar 22 15:32:10 * kergoth wonders if his 5 messages after rp said it could be worse got through Mar 22 15:33:44 yeah, they did Mar 22 15:33:57 okay, good Mar 22 15:34:09 * kergoth should really go complain to IT Mar 22 15:34:15 ah well Mar 22 15:34:16 kergoth, infact it didn't look lie you went anywhere. Mar 22 15:34:35 ah, guess I didn't disconnect long enough to time out. cool Mar 22 15:35:05 * MWelchUK_work chastises fingers for failing to hit the "k" key. Mar 22 15:35:15 kergoth: you only call finalise once on any given d, right? Mar 22 15:35:20 yep Mar 22 15:35:25 made sure of that Mar 22 15:35:35 kergoth: good, as if you don't is a world of fun ;-) Mar 22 15:35:54 yeah, i know, things get .. really interesting Mar 22 15:36:09 * kergoth double checks though :) Mar 22 15:36:21 had so many incarnations of this trying to get the kinks worked out Mar 22 15:37:45 anybody knows a way to get bitbake-1.8.18 directly from git with one single command? Mar 22 15:38:27 mckoan: after git clone or instead? Mar 22 15:38:45 "git clone git://git.openembedded.net/bitbake origin/1/8/18"? Mar 22 15:39:03 um origin/1.8.18 even Mar 22 15:39:23 RP: yeah, it waits and doesn't finalize any of them until it's about to return. Mar 22 15:39:34 other than the original one it used to get the variable values, of course Mar 22 15:39:35 kergoth: cool, thats the safe way to do it :) Mar 22 15:39:42 hrw: git clone of bitbake-1.8.18 Mar 22 15:40:02 git clone git://git.openembedded.net/bitbake bitbake-1.8/v1.8.18 Mar 22 15:40:08 mckoan, See above, I think :-) Mar 22 15:40:21 the second argument to clone is the destination, not the branch, no? Mar 22 15:40:35 ah.. right Mar 22 15:40:36 fsck Mar 22 15:40:50 * kergoth isn't sure if clone has an option for the branch Mar 22 15:40:51 fine, it works Mar 22 15:41:31 thank you Mar 22 15:41:52 it has Mar 22 15:41:55 "-b" Mar 22 15:42:06 but it gives bitbake-1.8/HEAD Mar 22 15:43:10 oh fuck you thunderbird 3.0 Mar 22 15:43:19 you better have saved that draft before hanging on me Mar 22 15:44:18 kergoth, my favourite is web forms and accidentally hitting "go back one page" on the wrong tab :-s Mar 22 15:45:04 RP: there's one change I made that I didn't push yet.. I save the original PV in a __BB_ORIG_PV variable, and then use that in FILESPATHPKG, so any versions in the range defined by the current recipe will also look in the version for the current recipe.. so you can have nano_3.0.x.bb, and put patches in nano-3.0.x/, or hte individual dirs for each version Mar 22 15:45:09 heh Mar 22 15:45:18 (didn't push to github, that is) Mar 22 15:45:27 * RP curses ubuntu. I want the close button on the top right. I do not want to undo 18 years of reflex action learning... Mar 22 15:46:15 kergoth: I'm not sure I like that. The "nano" directory would make more sense surely? Mar 22 15:46:17 RP: 10.04? Mar 22 15:46:22 hrw: yes Mar 22 15:46:31 hrw: Thankfully it can be fixed Mar 22 15:46:36 RP: yep Mar 22 15:46:37 RP: but isn't sufficient. Mar 22 15:47:06 if you have nano_1.0.0 and nano_2.0.0 that each covers all (or most) of the versions that come after that version, they can't share all their files in a common nano/ dir Mar 22 15:47:12 if you see what I mean Mar 22 15:47:35 kergoth: So the recipe should manually state that nano-1.x is a valid directory to search? Mar 22 15:48:01 kergoth: I think its a case where the recipe clearly has knowledge bitbake doesn't Mar 22 15:48:01 in every recipe? i suppose so, seems like something you'll *have* to set in every recipe that uses this feature, though. Mar 22 15:48:26 kergoth: The naming will only make sense on a per recipe basis Mar 22 15:48:32 what good is a recipe for a range of versions if it doesn't also have the patches for that range? Mar 22 15:49:09 kergoth: Patches in a range are likely to change at certain points anyway Mar 22 15:49:16 ? Mar 22 15:49:41 I have a nano_1.0.0.bb that builds nano 1.0.0 through 1.0.5, and nano_1.0.6.bb that builds versions 1.0.6 through 1.0.9 Mar 22 15:49:48 because the change that broke things occurred at 1.0.6 Mar 22 15:50:02 the patches to one range won't apply to the other, but the patches are common within the range. Mar 22 15:50:40 kergoth: Surely the 1.0.6 changes can be listed in the same recipe and just use overrides though? Mar 22 15:50:57 if you want to list 7 _ for every variable you want to change, sure Mar 22 15:51:02 with most of the patches coming from a 1.0.x directory and the 1.0.6 patch in a directory of its own? Mar 22 15:51:03 we don't have overrides for a range, either. Mar 22 15:51:26 Well, I think here gcc is a better and real example Mar 22 15:51:27 it isn't 1.0.6 alone. Mar 22 15:51:32 kergoth: hmm, thats a bit of a drawback :/ Mar 22 15:51:32 its 1.0.6 through 1.0.9 Mar 22 15:51:35 We've got a few things that can somehow live in files Mar 22 15:51:54 But there really is a lot of gcc-4.Y.x stuff that's the same every time Mar 22 15:52:05 by providing the original recipe version in a variable, you can add that to the default FILESPATHPKG in the .inc Mar 22 15:52:17 kergoth: In some ways it would be nice to list an identifer with the version range :/ Mar 22 15:52:45 ideally, metadata, conditional metadata, and files should all be able to apply to a range of versions Mar 22 15:53:01 not just because of this feature, but because *they really do* apply to a range of versions. no change lives alone Mar 22 15:53:03 ~hail kergoth for BBVERSIONS Mar 22 15:53:04 * ibot bows down to kergoth for BBVERSIONS and chants, "I'M NOT WORTHY!!" Mar 22 15:53:17 if you think of upstream like an scm, and releases like tags in that scm, we need minrev/maxrev for *everything* Mar 22 15:53:20 :) Mar 22 15:53:42 i dunno what's best, but doing this got me thinking about it in this way Mar 22 15:53:50 do you think that mode of thought about this makes sense? Mar 22 15:53:52 kergoth: will it handle different SRC_URI (think patches) or rather prefer to use recipes for such? Mar 22 15:54:04 hrw: the pv ends up in overrides Mar 22 15:54:11 kergoth: I've alway seen svm recipes like this... Mar 22 15:54:11 so for one ver or a couple you can do it that way Mar 22 15:54:16 er, scm Mar 22 15:54:17 but if its for a range, that gets pretty ugly Mar 22 15:54:25 ok Mar 22 15:54:31 RP: yes, but our scm recipes will almost always fail to build every version Mar 22 15:54:37 because there's no minrev/maxrev for metadata Mar 22 15:54:42 just nobody tries to go back and build them all Mar 22 15:54:57 so that alone isn't enough, imo Mar 22 15:55:09 kergoth: This goes back to your original point - there are only certain ranges that are interesting Mar 22 15:55:47 hrw: for nano, I used a per-version override or filesdir, but if it applied to more than one, you can create a new recipe for that range, or shift which filesdir is the base patches and which are version specific Mar 22 15:56:11 for example, if you start at 1.3.1, then do 1.3.2 and notice the patch doesn't apply, you fix it, and then build 1.3.3, but of course 1.3.3 is more likely to have the 1.3.2 patch apply than the 1.3.1 patch.. Mar 22 15:56:13 03Denys Dmytriyenko  07org.openembedded.dev * rce7314b977 10openembedded.git/recipes/u-boot/ (u-boot-mkimage-native_1.3.2.bb u-boot.inc): Mar 22 15:56:13 u-boot: update LICENSE to more specific GPLv2 Mar 22 15:56:13 There are parts of U-Boot that are GPLv2 and GPLv2+ (version 2 or later) Mar 22 15:56:13 Also, U-Boot's author Wolfgang Denk is planning to switch to GPLv3+ Mar 22 15:56:13 Signed-off-by: Denys Dmytriyenko Mar 22 15:56:22 so the 1.3.2 patch should become the base for that range, and 1.3.1 the deviation Mar 22 15:56:59 * kergoth had 1.0.x, 1.2.x, 2.x.x of nano building last night, but 1.1.x and 1.3.x proved to have a lot of per-version bits, lots of changes that broke the patches Mar 22 15:57:13 RP: I think it needs more thought and discussion Mar 22 15:57:21 kergoth: yes Mar 22 15:57:46 this could be useful as is, but in making nano work with it, its clear that it would be nice to better support ranges of versions intrinsically Mar 22 15:58:02 somehow. Mar 22 15:58:35 to this, someone can say.. do we really care about building all versions.. to that i say perhaps not, but it would be nice to keep all versions from now on, if it doesn't increase the workload terribly Mar 22 15:58:50 nano was just a proof of concept, to see how difficult it would be to get things building for every version that exists Mar 22 15:59:09 hrw: actually it didn't work Mar 22 15:59:10 bitbake-1.8/v1.8.18/bin/bitbake --version Mar 22 15:59:11 kergoth: I'm wondering about BBVERSIONS = "1.0.[1-5]:1.0.x 1.0.[6-9]:-1.0.x2" type syntax Mar 22 15:59:11 BitBake Build Tool Core version 1.9.0, bitbake version 1.9.0 Mar 22 15:59:37 RP: I think its cleaner to use the base version of the range where possible, as that's where the change occurred Mar 22 15:59:37 mckoan, the tag is 1.8.18, not v.1.8.18 I think Mar 22 15:59:47 i think 1.0.0 and 1.0.6 is cleaner than 1.0.x and 1.0.x2 Mar 22 15:59:49 mckoan: you need two steps Mar 22 15:59:49 or even v1.8.18 Mar 22 15:59:56 x2, x3, x4, it doesn't *tell you anything* Mar 22 16:00:00 there's no information in that Mar 22 16:00:17 kergoth: You'd most likely have to look at the recipe regardless Mar 22 16:00:25 kergoth: I think 1.0.0 would confuse people Mar 22 16:00:31 yes, but I'd rather have something with meaning than something without Mar 22 16:00:51 hrw: ok, 2 steps as I supposed :-( Mar 22 16:00:52 maybe 1.0.0+ and 1.0.6+ Mar 22 16:00:58 that could do, yeah Mar 22 16:01:32 I think its cleaner to use the base recipe version than encoding it into BBVERSIONS, then the recipe filename reflects what it is Mar 22 16:01:37 i guess you could duplicate that Mar 22 16:02:03 kergoth: My point is that you'd probably want a way to specify more than one Mar 22 16:02:26 but again, there's no way to do that for the metadata, so you'd often have to split off recipes anyway Mar 22 16:03:06 kergoth: Think about that string making it into overrides as well as the final PV Mar 22 16:03:15 i see what you want, since you want to avoid duplication of the metadata between the ranges, but I think the recipes will get cluttered if you try to cram too many into a single recipe Mar 22 16:03:21 03Tom Rini  07org.openembedded.dev * r73d7d78abb 10openembedded.git/recipes/gdb/ (5 files): gdb*: Add flex-native (and make sure we have relevant zlib) in DEPENDS. Mar 22 16:03:43 kergoth: I'm just pushing it to a corner to see how it scales ;-) Mar 22 16:04:33 I'm worried that we could confuse people if we have too much conditional metadata in one recipe.. I like that we can do it, but I dunno Mar 22 16:04:49 I'd almost rather just have a recipe per range Mar 22 16:04:51 hmmm Mar 22 16:05:13 kergoth: which starts to defeat what you started out to do :) Mar 22 16:05:18 I don't think so Mar 22 16:05:30 It just means one recipe per range of versions, rather than one recipe per version Mar 22 16:05:50 not one recipe for all versions, which was what i played with at first, but from actually making things build, i don't know how bad that could get Mar 22 16:05:54 kergoth: You set out to have more than one version per file. This would allow a single range per file but doesn't scale to all versions per file in theory Mar 22 16:06:20 kergoth: A cornerstone of OE is its power and capability Mar 22 16:06:40 it is, but we also have recipes that everyone is afraid to touch, because there's just so much crap in there for so many versions and architectures and .. Mar 22 16:06:54 kergoth: This isn't going to change that Mar 22 16:07:18 right, but what you want to be able to do is make it worse. Mar 22 16:07:18 The reason people don't touch them is they can't build them all. That isn't going to change Mar 22 16:07:37 Its not different to what you want to do, that doesn't change much either Mar 22 16:08:09 it'll already clean up some of the existing recipes, cases where patches are copied verbatim into 12 different versions because we lacked the ability to describe what they really are for Mar 22 16:09:00 well, fine, we can do it your way, can still do a recipe per range if someone wants to, just adds yet more boilerplate to the recipe.. seems like your proposals do that pretty regularly Mar 22 16:10:14 kergoth: absolutely, I'm not saying not to do a recipe per range where it makes sense Mar 22 16:10:32 kergoth: just that if we're going to add syntax to bitbake, may as well cover all the options in case we need them Mar 22 16:11:15 hmm, and of course, I could always use the original pv without bitbake saving it for me Mar 22 16:11:21 by directly calling the util that splits the filename Mar 22 16:11:29 We give people the full loaded gun, what they do with it... Mar 22 16:12:14 I thought about doing the pattern matching in the metadata, use an anonymous python function to expand out BBVERSIONS before bitbake saw it Mar 22 16:12:23 which would let you enhance the wildcards without touching bitbake Mar 22 16:12:32 but thats *yet more* shit in anonymous python functions, which makes me sad Mar 22 16:12:38 thoughts on that? Mar 22 16:13:18 kergoth: a bridge too far? Mar 22 16:13:41 flexibility is one thing, but when it makes our lives more difficult rather than easier, I think a line should be drawn Mar 22 16:13:44 kergoth: Yes we can do it, I'm not sure its useful except in strange cases like pb__ seems to have Mar 22 16:13:52 so i think i'd rather let bitbake expand them Mar 22 16:13:53 * kergoth nods Mar 22 16:13:54 kergoth: right Mar 22 16:14:06 you can always expand it further with anonymous python if you want, on top of what bitbake does.. Mar 22 16:14:09 for his case Mar 22 16:14:13 yes Mar 22 16:14:43 i think [a-b] covers the majority of cases anyway.. i could see {a,b,c,d} perhaps, but you can just as easily list them individually Mar 22 16:14:47 heh Mar 22 16:14:54 kergoth: I think pb__ would be quite happy with an anonymous python snippet sorting his crazy usecase Mar 22 16:15:18 what I haven't yet done, by the way, is profiled to determine the impact of returning a crapload of datastores that never end up built Mar 22 16:15:32 i'm hoping they'd get collected and not have much impact if they arne't used, but i'm not certain Mar 22 16:15:40 do you recall? Mar 22 16:15:42 you did that code Mar 22 16:16:15 kergoth: The overhead is the extra finalise calls Mar 22 16:16:17 of course, since it reparses at each task, it'd be returning a pile of versions even when it only wanted one, then dropping the rest on the floor each time,r ight? Mar 22 16:16:27 hmm, true Mar 22 16:16:49 kergoth: The reparse at task run time issue could be fixed if it turns out to be a problem Mar 22 16:17:01 yeah, i figured that Mar 22 16:17:07 kergoth: I see it as effectively being an overhead of twice the original parse time Mar 22 16:17:14 assuming you built everything Mar 22 16:17:35 well, maybe 10 times that assuming you run 10 tasks per recipe Mar 22 16:17:47 So if the initial parse time is ok, we're fine Mar 22 16:18:04 we need to trim down the amount of crap we do in anonymous python anyway :) Mar 22 16:18:12 kergoth: totally agreed Mar 22 16:18:18 * kergoth 'll do some overall build time tests before and after Mar 22 16:18:18 kergoth: Its the finalise calls that kill us Mar 22 16:18:54 kergoth: Improving the parser is fine but all the junk in anonymous methods makes it kind of pointless Mar 22 16:19:02 so, anyone else want to jump in on this feature? worthwhile? Mar 22 16:19:07 agreed Mar 22 16:19:48 datastore is more of an issue than the parser too Mar 22 16:20:15 But there the trick is to access the data less Mar 22 16:20:36 15 million lookups when parsing or something :/ Mar 22 16:21:04 re Mar 22 16:21:05 RP: I was thinking about taking the datastore and producing an intermediate semantic representation of things. this is a recipe, you can ask it to build, ask it for variables, *maybe* ask it for flags.. I think we should stop treating it so much like a dictionary directly, from our code Mar 22 16:21:07 I think with one patch I managed to third that in the past :) Mar 22 16:21:16 yikes Mar 22 16:21:42 * kergoth ponders Mar 22 16:21:45 hey hrw Mar 22 16:21:49 anybody read [RFC] Openembedded and Open Invention Network ? Mar 22 16:21:56 kergoth: I think I'd need more details to comment Mar 22 16:22:11 mckoan: I read part of it and plan to go back and read properly ;-) Mar 22 16:22:43 well, if you could say hey recipe, do this thing.. but leave how it does it up to it, I think it could make it easier to cache important bits of information. make it more OO, it retains all that knowledge and when and where it needs it Mar 22 16:22:47 i dunno, something else to ponder Mar 22 16:22:49 RP: thx, just to know if any of you found it interesting Mar 22 16:23:14 mckoan: interesting enough to need to find time to read it properly Mar 22 16:23:36 same here, its in my inbox, unread, amongst a total of 10 mails, awaiting action Mar 22 16:23:45 * kergoth tends to try to stick to inbox zero, anything there requires action Mar 22 16:24:20 * Tartarus assumes kergoth has commit emails filtered :) Mar 22 16:24:51 I try to stick to inbox zero, but I fail Mar 22 16:24:56 I'm 4756 in the hole Mar 22 16:25:10 actually, my main gmail has no commit mails.. when it does, though, yeah, immediately archived Mar 22 16:27:52 CosmicPenguin: heh, its tough.. i've lost out and had to painstakingly work back repeatedly.. a few times i admit i just said fuck it, archive all, go away... :P Mar 22 16:28:19 CosmicPenguin: I know the feeling. I'm down to a few hundred from more than I care to remember though :) Mar 22 16:30:22 Its the kernel patches that swamp me :/ Mar 22 16:30:50 Those are much easier if you keep on top of them. Mar 22 16:31:07 broonie: I know, believe me I know... Mar 22 16:31:29 and aren't afraid to go back and query stuff if it takes more than a few secodns to understand (putting the ball ack into the submitters court) Mar 22 16:32:21 RP: thoughts on a name for this :1.0.x thing? what variable should we shove 1.0.x into? variables set by bitbake should probably be namespaced as such, or __, to avoid stepping on someone's toes.. needs to be a variable, since bitbake has no knowledge of FILESPATHPKG. Mar 22 16:32:36 BPV or something is tempting, but could step on someone Mar 22 16:32:39 hmm Mar 22 16:36:22 I have to admit, I'm really excited for the xorg.conf.d/ stuff coming in 1.8 Mar 22 16:36:32 that idea is only about 4 years past its time Mar 22 16:40:01 * kergoth thinks about using BPV, setting a default BPV ?= "${PV}" in bitbake.conf, and using that in BP.. though, might want PN-BPV, BPN-PV, and BPN-BPV all 3.. hmm Mar 22 16:47:55 busybox-syslog is RRECOMMEND'ed, how could I get rid of it in rootfs properly? so I could set RCONFLICTS in sysklogd Mar 22 16:49:55 there's a variable to remove rrecommended packages, check rootfs_ipk.bbclass Mar 22 16:49:59 * kergoth can't recall the name Mar 22 16:50:29 03Martin Jansa  07org.openembedded.dev * r9259b4c343 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Mar 22 16:50:29 fso: bump SRCREVs to latest Mar 22 16:50:29 Signed-off-by: Martin Jansa Mar 22 16:50:30 03Martin Jansa  07org.openembedded.dev * r0e4d145692 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 22 16:50:30 frameworkd-config-shr: bump SRCREV Mar 22 16:50:30 Signed-off-by: Martin Jansa Mar 22 16:50:30 03Martin Jansa  07org.openembedded.dev * re9bfb11a95 10openembedded.git/recipes/vim/vim.inc: vim: add diffutils to RSUGGESTS, as vimdiff doesn't like busybox version of diff Mar 22 16:53:39 hmm.. which dynamic dns service gives longest refresh time? Mar 22 16:53:54 no-ip.com gives 2 months Mar 22 16:56:20 kergoth: BAD_RECOMMENDATIONS? Mar 22 16:56:26 that's the one :) Mar 22 16:56:33 kergoth: thanks! Mar 22 16:56:35 np Mar 22 16:58:32 anyone else getting a build failure on tslib? I get: Mar 22 16:58:48 | arm-angstrom-linux-gnueabi-libtool: install: error: cannot install `linear.la' to a directory not ending in /usr/lib/ts/ Mar 22 16:59:06 hmm, that's odd Mar 22 16:59:11 working from close to top of tree Mar 22 16:59:17 what version of tslib? Mar 22 16:59:46 tslib-1.0-r23.4 Mar 22 16:59:49 k Mar 22 17:00:00 * kergoth hasn't seen it, but fires off a build Mar 22 17:01:05 last commit on my tree was: src_distribute: simplify do_distribute_sources Mar 22 17:03:25 sakoman: that's due to recent automake/autoconf/libtool; they expect 'AM_LDFLAGS = -rpath ...' but package uses LIBADD. See https://www.cvg.de/people/ensc/plugin-link.patch for a patch Mar 22 17:03:42 (1st hunk) Mar 22 17:03:48 ah Mar 22 17:04:05 ensc|w: is the AM_LDFLAGS version compatible with old autotools too? Mar 22 17:04:11 if so i'll apply it upstream Mar 22 17:05:11 yes Mar 22 17:05:57 k Mar 22 17:05:59 thanks Mar 22 17:06:13 LDFLAGS was always the way to add linker flags Mar 22 17:07:10 * kergoth nods, pretty sure he just left that Makefile.am alone for the most part, haven't made changes to tslib other than bugfixes really Mar 22 17:09:13 have a nice rest of the day :-) Mar 22 17:09:55 i think bitbake may have gone off the deep end on me Mar 22 17:10:00 hmm Mar 22 17:14:19 * kergoth grumbles, adding the bpv stuff to bitbake is proving slightly annoying Mar 22 17:47:01 03Graeme Gregory  07org.openembedded.dev * r901777bacb 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): xserver-xorg-conf_0.1.bb : add omapzoom36x config files. Mar 22 17:52:11 hmm Mar 22 18:05:01 bitbake -e nano-1.0.0|grep -E '^(PV|PN|BPV|BPN|OVERRIDES)=' Mar 22 18:05:02 BPN="nano" Mar 22 18:05:02 BPV="1.0.0+" Mar 22 18:05:02 OVERRIDES="local:qemux86:${MACHINE_CLASS}:micro:linux:i686:build-linux:fail-fast:pn-nano:1.0.0:1.0.0+" Mar 22 18:05:05 PV="1.0.0" Mar 22 18:05:07 finally Mar 22 18:05:18 hmm Mar 22 18:05:47 * kergoth tries to make the implementation less ugly Mar 22 18:08:18 ensc|w: thanks! I'll give that patch a try Mar 22 18:11:07 03Adrian Alonso  07org.openembedded.dev * r5e90184edf 10openembedded.git/recipes/u-boot/u-boot_git.bb: (log message trimmed) Mar 22 18:11:07 u-boot_git.bb: add xilinx ml507 support Mar 22 18:11:07 * Based on xilinx official repos Mar 22 18:11:07 * If a hardware project dir is set in local.conf XILINX_BSP_PATH Mar 22 18:11:07 * it will over write xparameters header and append some canonical Mar 22 18:11:07 * definitions. It also install u-boot elf executable for bare metal Mar 22 18:11:08 * execution, early development stages. Mar 22 18:11:17 03Stefan Schmidt  07org.openembedded.dev * re027a196b8 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Mar 22 18:23:45 hmmm Mar 22 18:24:54 * kergoth thinks about keeping RP's : syntax, but defaulting it to the original pv :) Mar 22 18:33:44 kergoth: Thatd work Mar 22 18:35:01 got your syntax working, using BPV for it. could do something ugly and __'d or something, but BPV actually makes a certain amount of sense for it, and fits into the existing stuff Mar 22 18:35:32 kergoth: yes, that does fit Mar 22 18:36:02 * kergoth goes back to getting every version of nano to build :) Mar 22 18:38:51 03Martin Jansa  07org.openembedded.dev * rd84617efee 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 22 18:38:51 EFL: bump SRCREV, for bluetooth module fix Mar 22 18:38:51 Signed-off-by: Martin Jansa Mar 22 19:24:42 03Roman I Khimov  07org.openembedded.dev * r4e5a21d49f 10openembedded.git/recipes/libnfnetlink/ (3 files): Mar 22 19:24:42 libnfnetlink: unify versions with .inc file Mar 22 19:24:42 Signed-off-by: Roman I Khimov Mar 22 19:24:43 03Roman I Khimov  07org.openembedded.dev * r58b5bec1b6 10openembedded.git/recipes/conntrack-tools/ (3 files in 2 dirs): Mar 22 19:24:44 conntrack-tools: add new recipe Mar 22 19:24:44 Includes failover script for pacemaker. Mar 22 19:24:44 Signed-off-by: Roman I Khimov Mar 22 19:24:45 03Roman I Khimov  07org.openembedded.dev * rd47d5ded5d 10openembedded.git/recipes/libnfnetlink/ (libnfnetlink.inc libnfnetlink_1.0.0.bb): Mar 22 19:24:45 libnfnetlink: add version 1.0.0 Mar 22 19:24:45 Signed-off-by: Roman I Khimov Mar 22 19:24:47 03Roman I Khimov  07org.openembedded.dev * r1cd8c1baf7 10openembedded.git/recipes/libnetfilter-queue/ (3 files): Mar 22 19:24:47 libnetfilter-queue: rename recipe dir to libnetfiler Mar 22 19:24:47 libnetfilter-conntrack is to be pushed after this and there is also Mar 22 19:24:47 libnetfilter-log that could be added to OE. Don't see any reason to Mar 22 19:24:48 create separate directory for each of those. Mar 22 19:24:48 Signed-off-by: Roman I Khimov Mar 22 19:25:05 03Roman I Khimov  07org.openembedded.dev * r9e35f0c735 10openembedded.git/recipes/bridge-utils/ (bridge-utils.inc files/ifupdown.sh): Mar 22 19:25:06 bridge-utils: add ifupdown script from Debian Mar 22 19:25:06 Signed-off-by: Roman I Khimov Mar 22 19:25:33 03Sergey Lapin  07org.openembedded.dev * r323edc5ef4 10openembedded.git/recipes/musicpd/mpd_0.14.2.bb: mpd: Proper dependencies. Mar 22 19:25:34 03Sergey Lapin  07org.openembedded.dev * rc91a54aef8 10openembedded.git/: Mar 22 19:25:34 Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:34 Conflicts: Mar 22 19:25:34 recipes/musicpd/mpd_0.14.2.bb Mar 22 19:25:35 03Sergey Lapin  07org.openembedded.dev * r43653cf44f 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:36 03Sergey Lapin  07org.openembedded.dev * r8e099432e6 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:37 03Sergey Lapin  07org.openembedded.dev * rdf2ace6d59 10openembedded.git/contrib/angstrom/sort.sh: sort.sh: added mini2440 to machine list Mar 22 19:25:38 03Sergey Lapin  07org.openembedded.dev * r9dbc3d7164 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:40 03Sergey Lapin  07org.openembedded.dev * r029e21c811 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:40 03Sergey Lapin  07org.openembedded.dev * r3937c88166 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:40 03Sergey Lapin  07org.openembedded.dev * rc9d89f888e 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:40 03Sergey Lapin  07org.openembedded.dev * rb7ca90501a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:45 03Sergey Lapin  07org.openembedded.dev * r12784ca2ec 10openembedded.git/recipes/sysklogd/ (sysklogd.inc sysklogd_1.4.1.bb sysklogd_1.5.bb): sysklogd: using proper binary locations and update-alternatives Mar 22 19:25:47 03Sergey Lapin  07org.openembedded.dev * r5d87cec7a3 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:25:57 03Sergey Lapin  07org.openembedded.dev * r2a04d3897d 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Mar 22 19:26:20 slapin_nb: in the future, please consider rebasing before you push, i doubt we need to see all those merges Mar 22 19:59:15 and Same words for Stefan :) Mar 22 20:01:47 kergoth: I'm seeing a similar issue (to tslib) with pulse: Mar 22 20:01:52 | arm-angstrom-linux-gnueabi-libtool: install: error: cannot install `libcli.la' to a directory not ending in /usr/lib/pulse-0.9.15/modules/ Mar 22 20:05:43 sakoman: hmmm where it is trying to install ? Mar 22 20:05:56 good question, that's quite odd Mar 22 20:06:47 sakoman: yeah.. i see the same issue with pulse now Mar 22 20:07:34 whats DESTDIR ? Mar 22 20:07:59 or --prefix may be there is a bug in libtool Mar 22 20:08:06 did you upgrade autotools Mar 22 20:08:10 one moment -- on phone call now Mar 22 20:08:45 whats --with-libdir specified to during configure ? Mar 22 20:09:58 khem: I have --libdir=/usr/lib, but maybe I have slightly different issue then sakoman (and I updated autoconf/automake to latest) Mar 22 20:11:17 khem: log.do_install http://paste.pocoo.org/show/192650/ Mar 22 20:12:13 and log.do_configure http://paste.pocoo.org/show/192651/ Mar 22 20:16:12 my do_install is similar: http://pastebin.com/rfxKx3Q0 Mar 22 20:16:28 JaMa: did you change coreutils-native as well ? Mar 22 20:16:49 03Martin Jansa  07org.openembedded.dev * raf867082a7 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Mar 22 20:16:49 frameworkd: bump SRCREV for vibration Mar 22 20:16:49 Signed-off-by: Martin Jansa Mar 22 20:17:20 hello, can anybody help me with compilating angstrom for HTC hero (i have writen device config) but build on ubuntu server 9.10 says error... Mar 22 20:17:43 khem: version of coreutils-native? no still 7.2-r1 since builddir start Mar 22 20:20:05 JaMa: sakoman: look at the failing install invocation and at the end where it specifies the output dir Mar 22 20:21:06 try to run it manuallt Mar 22 20:21:56 may be use -inst-prefix-dir Mar 22 20:22:00 and see if that helps Mar 22 20:26:19 tomeff: well you have to give details about your error inorder to get help Mar 22 20:26:40 ok wait, i post it (to pastebin :D ) :) Mar 22 20:27:46 http://effik.pastebin.com/egLMBKBz Mar 22 20:30:40 tomeff: you could disable locales if you dont need them Mar 22 20:30:49 how ? :D Mar 22 20:31:14 * hrw -> off Mar 22 20:31:24 khem: --help --mode=install says it's -inst-prefix and when I use it, it says "unrecognized option `-inst-prefix'", checking why Mar 22 20:31:35 tomeff: ENABLE_BINARY_LOCALE_GENERATION = "0" Mar 22 20:31:41 in local conf Mar 22 20:31:45 ok Mar 22 20:32:22 JaMa: use -inst-prefix-dir it may be a buggy install manpage Mar 22 20:32:30 btw it build only rootfs or both (kernel and rootfs)? :D Mar 22 20:32:59 hm. I have a weird issue here - why does the same file, on the jffs2 and on the ext3 filesystem, differ? Mar 22 20:34:14 hmm Mar 22 20:34:47 tomeff: usually both Mar 22 20:35:00 khem: unrecognized option `-inst-prefix-dir' Mar 22 20:35:52 interesting is it the install from staging ? Mar 22 20:36:51 * khem is out for errands Mar 22 20:36:53 yes Mar 22 20:37:17 JaMa: laters gotta go now Mar 22 20:39:17 * JaMa trying to rebuild coreutils just in case Mar 22 20:44:56 btw kernel for HTC hero is in .img , how to convert kernel from .bin to img (in img it has information which is rootfs,...) Mar 22 20:48:42 whats the difference between RRECOMMENDS and RSUGGESTS? Mar 22 20:52:25 RRECOMMENDS are installed by default and can be removed later Mar 22 20:52:40 03Roman I Khimov  07org.openembedded.dev * r8479d9d3eb 10openembedded.git/recipes/iptstate/ (3 files in 2 dirs): Mar 22 20:52:40 iptstate: add version 2.2.2 Mar 22 20:52:40 Signed-off-by: Roman I Khimov Mar 22 20:52:46 03Roman I Khimov  07org.openembedded.dev * rf7f706bc05 10openembedded.git/recipes/iptstate/ (iptstate.inc iptstate_2.2.1.bb): Mar 22 20:52:46 iptstate: move to .inc to ease newer versions addition Mar 22 20:52:46 Signed-off-by: Roman I Khimov Mar 22 20:52:47 03Roman I Khimov  07org.openembedded.dev * rc211977dea 10openembedded.git/recipes/iptstate/iptstate.inc: Mar 22 20:52:47 iptstate: build with libnetfilter-conntrack Mar 22 20:52:47 As was intended originally. Also, newer versions always require Mar 22 20:52:48 libnetfilter-conntrack. Mar 22 20:52:48 Signed-off-by: Roman I Khimov Mar 22 20:52:57 RSUGGESTS are only shown as possible additional stuff Mar 22 20:53:50 JaMa: did rebuilding coreutils help? Mar 22 20:54:05 still on conference call here :-( Mar 22 20:54:18 JaMa: thanks Mar 22 20:59:03 sakoman: no :/ Mar 22 21:15:54 what is 'w' in "movwls r9, #58127 ; 0xe30f"? cannot find it in asm manual now :/ Mar 22 21:17:09 ah sorry wrong manual Mar 22 21:17:18 lo Mar 22 21:22:41 Could some one apply this patch for me (I don't have commit privileges): http://patchwork.openembedded.org/patch/1781/ Mar 22 21:26:37 JaMa, kergoth: Adding this patch to pulsaudio.inc patch list fixed the issue for me: Mar 22 21:26:41 http://pastebin.com/AQdAbKE2 Mar 22 21:31:21 JaMa, kergoth: to be even more specific: http://pastebin.com/WksLV0qz Mar 22 21:46:52 khem: new error http://effik.pastebin.com/a1q4YwTP Mar 22 21:55:53 sakoman: interesting. Mar 22 22:03:38 03Martyn Welch  07org.openembedded.dev * r78d6a328b2 10openembedded.git/recipes/gypsy/ (gypsy_0.7.bb gypsy_svn.bb): Mar 22 22:03:38 gypsy: Add version 0.7, remove broken svn recipe Mar 22 22:03:38 Svn package no longer provided at o-hand. Remove it and replace with Mar 22 22:03:38 version 0.7 from the projects website. Mar 22 22:03:38 Signed-off-by: Martyn Welch Mar 22 22:03:39 Acked-by: Koen Kooi Mar 22 22:03:40 Signed-off-by: Philip Balister Mar 22 22:22:39 did anyone try the aufs2 git? Mar 22 22:23:19 the recipe in oe.dev is quite outdated.. Mar 22 22:28:18 hmm, did anyone have an opinion on http://github.com/kergoth/OpenEmbedded/commit/3def3ba3d4860983f2d8f082eb528c4b84f83b50 ? Mar 22 22:29:26 too complicated for me :/ Mar 22 22:30:30 heh, k Mar 22 22:31:41 hmm are you redoing how some tasks happen? Mar 22 22:31:58 cleaning up do_unpack and oe_unpack_file Mar 22 22:32:00 cause that looks like a lot of stuff being replaced by what looks like functionality from the os module Mar 22 22:32:28 a few bits are replaced with shutil usage, some responsibility was shifted, do_unpack determines the dir to unpack to instead of oe_unpack_file doing it Mar 22 22:32:49 making oe_unpack_file just have source file, destination directory, and options, rather than it knowing about the urls and variables Mar 22 22:32:55 makes it more generally useful Mar 22 22:33:10 But, faster or slowe? Mar 22 22:33:11 r Mar 22 22:33:40 unlike the conversion completely to python unpacking, it doesn't seem to affect performance much at all Mar 22 22:33:45 I'll verify though Mar 22 22:34:16 conversion to python's archival modules nearly doubles unpack times, sadly Mar 22 22:35:36 so its picking out the URL itself from the file now? Mar 22 22:36:16 jo Mar 22 22:37:16 not sure what you mean. it always started iwth the url, it has to, because params in the url can affect the unpack process. it's just that its do_unpack that deals with that now, and does so by leveraging the existing urldata mechanism rather than grabbing it manually Mar 22 22:39:05 yeah Mar 22 22:39:31 I guess before someone else was doing some redundant stuff outside and passing in the url directly Mar 22 22:39:42 * kergoth doesn't really like the way he's handling the 'env' for subprocess, but isn't sure what a better method would be Mar 22 22:40:20 there is oe_popen / oe_system now, but would have to pass in the datastore Mar 22 22:40:22 hmm Mar 22 22:40:46 * kergoth has an idea that might be cleaner Mar 22 22:41:44 pass in the function it will call.. default to os.system, and do_unpack could pass in one that uses oe_system instead Mar 22 22:42:17 go for it **** ENDING LOGGING AT Mon Mar 22 22:48:09 2010 **** BEGIN LOGGING AT Mon Mar 22 22:54:14 2010 Mar 22 22:58:13 hm poor scott isnt aware off that richard has all stuff in poky converted to BBCLASSEXTEND native Mar 22 22:59:59 woglinde: Someone has to merge that into OE one way or other Mar 22 23:00:37 sure but he could do it lot more easier Mar 22 23:00:59 and I am to lazy to write it Mar 22 23:01:16 yeah may be you or I should reply to his email directing him to look into poky Mar 22 23:21:58 03Martyn Welch  07org.openembedded.dev * r74b47226f8 10openembedded.git/recipes/udhcp/udhcp_0.9.8.bb: Mar 22 23:21:58 udhcp_0.9.8.bb: Update SRC_URI Mar 22 23:21:58 * The udhcp SRC_URI is broken, change to download from mirror that is still Mar 22 23:21:58 carrying this package. Mar 22 23:21:58 * Add checksum entries. Mar 22 23:21:59 Signed-off-by: Martyn Welch Mar 22 23:21:59 Signed-off-by: Khem Raj **** ENDING LOGGING AT Mon Mar 22 23:25:21 2010 **** BEGIN LOGGING AT Mon Mar 22 23:44:15 2010 Mar 22 23:52:34 03Jesse Gilles  07org.openembedded.dev * r7202fbf2fc 10openembedded.git/recipes/ruby/ (files/extmk.patch ruby_1.8.7-p248.bb): Mar 22 23:52:34 ruby_1.8.7-p248.bb: fix ext/dl compile Mar 22 23:52:34 * Update ruby library path so extensions needing mkmf can build and Mar 22 23:52:34 find the right ruby headers. Fixes building of ext/dl. Mar 22 23:52:34 Signed-off-by: Jesse Gilles Mar 22 23:52:34 Signed-off-by: Khem Raj Mar 22 23:52:35 03Khem Raj  07org.openembedded.dev * r814ad5d596 10openembedded.git/recipes/ruby/ (4 files): Mar 22 23:52:35 ruby: Move to using INC_PR and BBCLASSEXTEND Mar 22 23:52:36 Signed-off-by: Khem Raj Mar 23 00:11:45 would now be a good time to do a quick kernel upgrade to melo..the git server? Mar 23 00:12:06 gn all Mar 23 00:12:16 ka6sox seems so Mar 23 00:12:21 ka6sox: for me, yes :-) Mar 23 00:12:22 good nite Mar 23 00:12:23 only khem is doing some stuff Mar 23 00:12:39 khem, that okay wiht you? about 10 minutes Mar 23 00:14:27 always seems to be pretty dead about this time. late for folks in europe, and in the US most are off of work and probalby have better things to be doing :) Mar 23 00:14:55 kergoth, thanks...shouldn't be too long...copy some modules and reboot. Mar 23 00:15:49 let khem know if he asks...won't be long Mar 23 00:24:37 can anybody check to see tha ttinderbox and git came back up? Mar 23 00:25:24 hood nite Mar 23 00:25:34 mom Mar 23 00:26:08 cgit is running Mar 23 00:26:19 thanks. Mar 23 00:26:48 tinderbox too Mar 23 00:26:49 okay Mar 23 00:26:52 good nite now really **** ENDING LOGGING AT Tue Mar 23 02:59:57 2010