**** BEGIN LOGGING AT Wed Aug 25 02:59:57 2010 Aug 25 05:13:58 03Roman I Khimov 07org.openembedded.dev * r95a18d758e 10openembedded.git/recipes/ethtool/ (ethtool_3.bb ethtool_4.bb ethtool_5.bb ethtool_6.bb): (log message trimmed) Aug 25 05:13:58 ethtool: remove versions prior to 2.6.35 Aug 25 05:13:58 since 2.6.33 ethtool have changed version numbering and old versions Aug 25 05:13:58 override new one. 2.6.35 is considered as safe upgrade for three years Aug 25 05:13:58 old version 6, so there is no point in keeping it or any previous one Aug 25 05:13:58 around. Aug 25 05:13:59 Signed-off-by: Roman I Khimov Aug 25 05:13:59 03Roman I Khimov 07org.openembedded.dev * reb8c967ca8 10openembedded.git/recipes/ethtool/ethtool_2.6.35.bb: Aug 25 05:14:00 ethtool: add version 2.6.35 Aug 25 05:14:00 Signed-off-by: Roman I Khimov Aug 25 05:14:01 Acked-by: Frans Meulenbroeks Aug 25 05:43:39 gm everyone Aug 25 05:58:57 eFfeM_work: gm Aug 25 05:59:12 eFfeM_work: I just sent an email about autoconf cleanup Aug 25 05:59:34 too much got cleaned up Aug 25 06:01:05 hi khem, just curious, were you able to reproduce the 4.4.4 problem? if you need to I can get you more info if you tell me what. I still kept a copy of the tree. I myself am fine at the moment as 4.3.3 does not give me the issue Aug 25 06:01:15 wrt autoconf: ouch, will read the email Aug 25 06:04:57 hi eFfeM_work, gm Aug 25 06:06:00 if a recipe is not inheriting from autotools, is there a way to remove the do_install function from it, like you did with gawk_3.1.4.bb? Aug 25 06:09:34 fahad_usman: will get back to you in 15 mins Aug 25 06:09:48 eFfeM_work: okay, sure Aug 25 06:12:16 eFfeM_work: no time to look into the gcc 4.4 issue yet Aug 25 06:12:29 eFfeM_work: I have fairly good idea what it is Aug 25 06:12:50 eFfeM_work: btw. is your build machine 32bit or 64bit Aug 25 06:13:33 khem: np, just wanted to let you know that I have more info if neeeded Aug 25 06:13:43 my build machine is ubuntu 10.04 64bit Aug 25 06:14:25 ok perfect Aug 25 06:14:34 I will try it on similar box Aug 25 06:23:32 fahad_usman: do_install is needed in general to be defined its just that autotools class defines it Aug 25 06:23:41 so you dont need your own for a given recipe Aug 25 06:23:59 but you will need one otherwise it will end up as no op Aug 25 06:24:40 khem, saw your email, if you want a revert let me know (and you have my ack if you want to revert yourself) Aug 25 06:25:04 actaully was worried that you were referring to the autotools_stage_all removal Aug 25 06:26:17 I will readd autoconf213 tomorrow Aug 25 06:26:46 first I will try to avoid it if I can Aug 25 06:26:59 khem, wrt autoconf213: where/how is it decided to use autoconf213? I see no depends on it in recipes/* and no pinning in conf/* Aug 25 06:27:52 that is why I did feel it was safe to remove Aug 25 06:28:05 grep -r "autconf213" recipes/* Aug 25 06:28:35 grep -r "autoconf213" Aug 25 06:28:41 typo Aug 25 06:29:07 its only fennec and dev version of firefox which use it Aug 25 06:29:47 fahad_usman: peeked into the gawk recipe: that one *does* inherit from autotools, that is why the do_install could go (and let autotools take care of it); for the rest see khem's answer Aug 25 06:29:57 khem: Aug 25 06:29:57 frans@frans-desktop:~/workspace/openembedded.git/recipes$ grep automake123 */* -r Aug 25 06:29:58 frans@frans-desktop:~/workspace/openembedded.git/recipes$ Aug 25 06:30:12 frans@frans-desktop:~/workspace/openembedded.git/recipes$ grep -r automake123 ../conf Aug 25 06:30:12 frans@frans-desktop:~/workspace/openembedded.git/recipes$ Aug 25 06:30:45 eFfeM_work: I asked for autoconf213 not automake Aug 25 06:30:58 aaargh; still too early Aug 25 06:31:02 hi all Aug 25 06:32:17 khem but still same result: Aug 25 06:32:18 frans@frans-desktop:~/workspace/openembedded.git/recipes$ grep -r autoconf123 */* ../conf Aug 25 06:32:18 frans@frans-desktop:~/workspace/openembedded.git/recipes$ Aug 25 06:32:58 is this a deleted firefox recipe ? Aug 25 06:34:00 oops 213 it really isn't my day Aug 25 06:34:13 khem: in the patch is just sumbitted, kakasi-native does not inherit from autotools, so, the do_install function has to be there, right? Aug 25 06:34:15 got it Aug 25 06:34:31 fahad_usman: yes Aug 25 06:34:38 eFfeM_work: :) Aug 25 06:34:47 get that beer cart right Aug 25 06:34:52 hmm Aug 25 06:35:51 khem: okay, thanks (no need to revert then) Aug 25 06:36:07 I want to build a very small distro for my at91rm9200ek board Aug 25 06:36:10 123, 213, 132: dyslectics of the world: untie Aug 25 06:36:45 fahad_usman: well talking about kakasi it inherits autotools Aug 25 06:36:48 I was using buildroot, but it has given problems to u-boot Aug 25 06:37:00 so you can get rid of do_stage and it should just work Aug 25 06:37:12 but there isn't any "make menuconfig" ? Aug 25 06:37:31 khem btw noticed that ncurses 5.7 also has a reference to autoconf213 Aug 25 06:37:42 thats commented out :) Aug 25 06:37:43 khem: right Aug 25 06:37:52 khem, yes Aug 25 06:38:23 fahad_usman: kakasi-native_2.3.4.bb can be removed and BBCLASSEXTEND used to have native recipe in there Aug 25 06:38:31 its simple replacement Aug 25 06:39:06 its hot here today Aug 25 06:39:21 11:30p and temp is still around 93F Aug 25 06:39:26 fahad_usman: while you are at removing legacy staging please also look into merging native and nonnative recipes Aug 25 06:39:42 14C here and 8.37 am Aug 25 06:40:22 khem you're in CA? Near SFO or LA ? Aug 25 06:41:41 is OE == new buildroot Aug 25 06:42:04 khem, eFfeM_work: okay, sure, i will try Aug 25 06:44:08 eFfeM_work: can you tell me how to revert the changes i just sent? Aug 25 06:45:34 eFfeM_work: I am in San Jose which is 30miles from SFO and 450miles from LA :) Aug 25 06:46:57 khem, I know roughly where it is, my previous job brought me to silicon valley several times (and to some strange company in Redmond, WA) Aug 25 06:47:03 guess LA would even be hotter Aug 25 06:47:24 yeah anytime Aug 25 06:47:34 this week is predicted to me hot Aug 25 06:47:38 s/me/be Aug 25 06:48:04 oh heh the evil empire Aug 25 06:50:35 alright I will try to sleep Aug 25 06:50:42 gm Aug 25 06:50:45 gn Aug 25 06:50:48 I meant Aug 25 06:50:57 nite! Aug 25 06:52:07 fahad_usman: revert in your tree ? Aug 25 06:52:24 if it is the last commit in your tree you can do git reset HEAD^ Aug 25 06:53:16 if you mean remove from the list, just write a small msg in a reply that you want to withdraw the patch and update its status in patchwork Aug 25 07:32:46 eFfeM_work: i am getting ERROR: Dependency loop #1 found: .... when I added BBCLASSEXTEND = "native" to the target kakasi_2.3.4.bb Aug 25 07:33:09 fahad_usman: have you removed the old kakasi-native recipe ? Aug 25 07:33:14 yes Aug 25 07:33:51 you probably also need to remve this line DEPENDS = "kakasi-native" Aug 25 07:34:00 otherwise native depends on native which gieves a cycle Aug 25 07:35:24 and test if kakasi builds even if kakasi-native is not build Aug 25 07:35:47 eFfeM_work: oh, okay Aug 25 07:36:00 eFfeM_work: ya, i am trying that Aug 25 07:36:05 I'm not sure if BBCLASSEXTEND = "native" will automatically add the dependency, guess someone here can tell that. Aug 25 07:36:25 if you really need a dep on native in the recipe the solution is to say Aug 25 07:36:28 something like Aug 25 07:36:39 DEPENDS_virtclass-native = "" Aug 25 07:36:50 DEPENDS = "kakasi-native" Aug 25 07:37:08 acdtually the order should be the other way round Aug 25 07:37:19 but the virtclass-native will override the regular one Aug 25 07:37:55 eFfeM_work: right Aug 25 08:19:24 hi Aug 25 08:19:38 hi hrw Aug 25 08:22:10 03Frans Meulenbroeks 07org.openembedded.dev * r9600cc400c 10openembedded.git/recipes/lmbench/ (3 files in 2 dirs): Aug 25 08:22:10 lmbench-2.0.4: removed Aug 25 08:22:10 removed this version. it is from 2003, not pinned Aug 25 08:22:10 Signed-off-by: Frans Meulenbroeks Aug 25 08:22:20 03Frans Meulenbroeks 07org.openembedded.dev * r3c886c4816 10openembedded.git/recipes/lmbench/lmbench_3.0-a9.bb: Aug 25 08:22:20 lmbench: added 3.0-a9 version Aug 25 08:22:20 kept 2.5 so people who want to compare results still can build Aug 25 08:22:20 that version if desired Aug 25 08:22:20 Signed-off-by: Frans Meulenbroeks Aug 25 08:57:42 hi eFfeM_work, there's one more thing Aug 25 08:58:07 if there's a patch in the target file that apply only to target recipe, and not the native one Aug 25 08:58:24 eFfeM_work: what should i do in that case Aug 25 09:10:21 03Martin Jansa 07org.openembedded.dev * r962aacf151 10openembedded.git/recipes/linux/linux-openmoko-2.6.32/ (0003-usbhost.patch.patch 0004-ar6000_delay.patch.patch): Aug 25 09:10:21 linux-openmoko-2.6.32: fix usbhost patch Aug 25 09:10:21 * no change in resulting source -> no PR change Aug 25 09:10:21 Signed-off-by: Martin Jansa Aug 25 09:15:25 eFfeM_work: you there? Aug 25 09:15:32 yup Aug 25 09:15:38 didn't see your msg Aug 25 09:15:52 okay Aug 25 09:16:11 pff, first verify if the target patch is still needed Aug 25 09:16:45 okay, let me check Aug 25 09:16:50 Q to all: do we have a way to add a target specific SRC_URI in a recipe with BBCLASSEXTEND = "native" ? Aug 25 09:18:23 what recipe ? Aug 25 09:18:43 i think SRC_URI_append_virtclass-native can be used when only the native recipe need the patch, but can't figure how to do it for target only Aug 25 09:19:01 same, kakasi_2.3.4 Aug 25 09:19:23 there is no equivalent like _target Aug 25 09:19:39 this has been discussed before, forgot why not Aug 25 09:21:10 peeked at recipe,I can imagine that the patch also applies for native, and does not harm Aug 25 09:21:50 the native recipe fails when the patch is applied Aug 25 09:21:53 i suggest doing the patch in both cases and test by building kakasi (whcih is the only recipe that depends on kakasi-native Aug 25 09:22:06 and the target fails without it, just varified Aug 25 09:22:44 yes, keep the patch and try to build native with it Aug 25 09:23:36 then rebuild kasaki and if il really want to be sure build zten and anki which are the only recipes that depen on kakasi Aug 25 09:25:54 !logs Aug 25 09:25:56 Channel logs for #oe are archived at: Aug 25 09:25:57 http://hentges.net/tmp/logs/irc/%23oe Aug 25 09:25:57 Live-logs are available at Aug 25 09:25:59 http://hentges.net/tmp/logs/irc/livelogs/%23oe.livelog Aug 25 09:26:01 See ?? help-logs for usage instructions Aug 25 09:26:58 kakasi-native builds with the patch, (but earlier it was failing for some reason) Aug 25 09:27:37 btw, what's the easiest way to find the recipes depending on a particular recipe? Aug 25 09:28:11 fahad_usman: there is not really an easy way, what I typically do (eg. for kakasi) is: Aug 25 09:28:25 cd recipes; grep kakasi */* Aug 25 09:28:50 that will show all occurrences of the word kakasi in all recipes Aug 25 09:28:58 right Aug 25 09:29:00 most of these if not all are fromDEPENDS Aug 25 09:29:39 don't you use the -g option in bitbake? Aug 25 09:31:28 getting some compilation errors for angstrom Aug 25 09:31:37 the logs can be found at http://pastebin.com/ET20P2Wr Aug 25 09:33:56 strange, what cmd did you give? Aug 25 09:34:04 log seems to say automake is not installed Aug 25 09:34:41 bitbake console-image x11-image Aug 25 09:35:08 before that I gave bitbake base-image and it built the image successfully Aug 25 09:35:09 from scratch Aug 25 09:35:25 yes Aug 25 09:35:32 very strange Aug 25 09:35:36 not really an idea Aug 25 09:35:57 fahad_usman: bitbake -g gives the recipes that are needed for your recipe, not who calls your recipe Aug 25 09:36:03 thre is no bitbake option for that Aug 25 09:36:19 bitbake -g world would give all deps, but i seem to recall there were some issues with it Aug 25 09:41:55 eFfeM_work: btw, zten is also failing, saying *configure:3313: error: C++ compiler cannot create executables* Aug 25 09:42:06 should I try from scratch again? Aug 25 09:42:16 aniruddh: you can try Aug 25 09:42:56 fahad_usman: maybe revert your kakasi patches and try to build zten from scratch (do a -cclean first) Aug 25 09:43:11 if that does not work you hit a package that has a problem Aug 25 09:43:12 okay Aug 25 09:52:05 afk for 2 hrs or so Aug 25 09:52:43 eFfeM_work: zten is still failing with the same error Aug 25 11:02:08 hi all, Aug 25 11:02:25 if update a native recipe that uses PR from its target recipe, how should i bump the PR, should i update it in the target .bb file or should i add PR in the native recipe? Aug 25 11:14:27 hello Aug 25 11:23:15 Is there a way to boot u-boot from u-boot self? Aug 25 11:55:41 fahad_usman: bump the PR from the target recipe (but please first look if you can merge the recipes Aug 25 11:59:27 they don't inherit from autotools Aug 25 12:01:44 eFfeM_work and i haven't made any change to the target recipe at all Aug 25 12:02:42 fahad_usman: one sec Aug 25 12:04:28 most native recipes seem to have their own PR, not sure if that is wise, but feel free to add one to the native recipe Aug 25 12:04:32 i'll rais it on the mailing list Aug 25 12:07:15 * fahad_usman is afk for 20 minutes Aug 25 12:35:30 thanks eFfeM_work for posting the querry for me Aug 25 12:35:38 yw Aug 25 12:35:57 i am facing another problem Aug 25 12:36:06 I guess the PR += ".0" is the desirable solution, but this is not in use Aug 25 12:36:37 when i try to build the recipes that depend upon the recipes i intend to change, those recipes fail, even before i have modified any recipes Aug 25 12:37:32 for example, in case of libfribidi, abiword depends on libfribidi Aug 25 12:39:39 and when i try to build libfribidi, ncurses fails saying ncurses_5.7's do_compile failed Aug 25 12:42:27 so you have an issue building libcurses 5.7 Aug 25 12:42:39 yes Aug 25 12:42:47 hm' i recall there were some issues, but I seem to recall I've build it yesterday or so Aug 25 12:43:09 i think i updated the code today Aug 25 12:43:13 what is the libcurses compile error? can you pastebin the log (or at least the last part of it) Aug 25 12:43:26 sure Aug 25 12:46:05 eFfeM_work: here it is http://pastebin.com/3P4AkxeE Aug 25 12:48:12 have you rebuild from scratch ? Aug 25 12:48:35 * eFfeM_work would like to be eFfeM_patio :-( Aug 25 12:49:22 fahad_usman: and in your ncruses dir you you have obj_s/cursesf.o Aug 25 12:50:00 i rebuilt it from scratch yesterday, haven't made any significant changes since then Aug 25 12:53:06 fahad_usman: check if the cursesf.o file is there ; it shoudl be as it is built in line 68 of your log Aug 25 12:53:16 is it possible to generate a minimal boot image with just busybox,dbus,udev without having OE compiling gstreamer and a full x11 stack ? Aug 25 12:53:42 dj-death: yes Aug 25 12:57:44 eFfeM_work: ok, great Aug 25 12:58:11 eFfeM_work: and is there normal that OE builds gstreamer/x11 when I ask for task-boot ? Aug 25 12:58:11 you might want to roll your own image recipe thoug Aug 25 12:58:33 no idea what is in task-boot; Aug 25 12:58:47 eFfeM_work: no, i don't have cursusf.0 in the /home/fahad/systemBuilder/oe-git/build/tmp/work/armv7a-angstrom-linux-gnueabi/ncurses-5.7-r11/ncurses-5.7/narrowc/obj_s Aug 25 12:59:19 wel the issue is if you drag in bluetooth you drag in bt audio which in turn drags in lots of gst stuff Aug 25 12:59:44 eFfeM_work: it seems to be an image with dbus busybox udev and a few other basic tools Aug 25 12:59:54 eFfeM_work: the generated rootfs is about 9Mb Aug 25 13:00:20 but still... to generate that OE build the whole gnome stack Aug 25 13:00:26 minimal-image might compile gst stuff, but it is not sure if it ends up in the image Aug 25 13:00:32 s/build/builds/ Aug 25 13:01:10 hm, that seems odd Aug 25 13:01:18 i know insane drags in some stuff Aug 25 13:01:30 but ofc it is very easy to make your own image recipe Aug 25 13:01:30 insane ? Aug 25 13:01:40 insane.bbclass Aug 25 13:01:56 is in some angstrom conf. Aug 25 13:02:08 something like INHERIT += "insane.bbclass" Aug 25 13:02:12 ah Aug 25 13:02:23 so my problem might not be related to the image Aug 25 13:02:28 but rather the distro Aug 25 13:02:40 and bitbake -g task-boot might give you a list of dependencies on task-boot Aug 25 13:02:52 yes, check the generated img Aug 25 13:03:29 yeah... I've been watch dependencies graphs for hours, but there too much connections Aug 25 13:04:13 s/watch/watching/ Aug 25 13:11:47 s/cursesf.0/cursesf.o/ Aug 25 13:17:05 dj-death: i can try to kick off a build tonight at home Aug 25 13:18:11 fahad_usman: strange, can you try a bitbake -cclean ncurses; bitbake ncurses Aug 25 13:18:22 to see if the problem persists Aug 25 13:18:32 i can also peek in my system at home tonight Aug 25 13:18:51 eFfeM_work okay, sure, Aug 25 13:19:41 dj-death: you can definitely make your own image Aug 25 13:20:14 e.g. take minimal-image remvoe everything in IMAGE_INSTALL and replace it by whatever pacakges you want to have Aug 25 13:22:27 eFfeM_work in the meanwhile, i am sending patch for makedevs-native_1.0.0.bb, it did not inherit from autotools, so i am not merging it with the non-native recipe Aug 25 13:22:49 even if you do not inherit you can still merge Aug 25 13:24:00 but in that case both the do_install functions have to be same, right? Aug 25 13:24:17 yes or you need a do_install and a do_install_virtclass_native Aug 25 13:25:06 i think here you need the latter as there is the sbindir and the makedevs.makedefs in the target recipe Aug 25 13:25:51 yes, do_install_virtclass_native should work here Aug 25 13:27:09 do that, that way we also get rid of FILESDIR Aug 25 13:27:41 after posting the patch mail a followup msg if this is the correct way Aug 25 13:29:23 okay, thanks Aug 25 13:30:04 i'll do that tomorrow now, as i have to leave in 5 mins now Aug 25 13:30:11 ok Aug 25 13:33:29 * fahad_usman has left Aug 25 13:33:40 have a nice evening Aug 25 14:35:54 03Chris Larson 07org.openembedded.dev * r013d632d46 10openembedded.git/classes/utils.bbclass: Aug 25 14:35:54 oe.utils: add oe_run convenience function Aug 25 14:35:54 This one is intended to be used from python snippets in variables. It returns Aug 25 14:35:54 the stdout of the subprocess and raises an exception if the exit code isn't 0. Aug 25 14:35:54 Signed-off-by: Chris Larson Aug 25 16:10:55 Hello Aug 25 16:11:48 Did anybody succeded in compiling qte 2.x on openembedded ! Aug 25 17:00:03 03Roman I Khimov 07org.openembedded.dev * rb0f0b3ab87 10openembedded.git/recipes/squid/ (3 files in 2 dirs): Aug 25 17:00:03 squid: update 3.1.6 to 3.1.7 Aug 25 17:00:03 * fixes DoS vulnerability Aug 25 17:00:03 * fixes lots of bugs, most notable is HTTP/1.1 compliance bugs Aug 25 17:00:03 * considered as safe upgrade Aug 25 17:00:04 Signed-off-by: Roman I Khimov Aug 25 17:00:09 03Roman I Khimov 07org.openembedded.dev * ra9090f72a9 10openembedded.git/recipes/iptables/iptables_1.4.9.1.bb: Aug 25 17:00:09 iptables 1.4.9.1: DEPENDS on libnfnetlink Aug 25 17:00:09 Actually, it can be built with and without libnfnetlink support. Aug 25 17:00:10 libnfnetlink-enabled build enables nfnl_osf utility for passive OS Aug 25 17:00:10 fingerprinting and pf.os is its 'database', so it shouldn't be moved to Aug 25 17:00:10 documents. Just build with it and package separately. Aug 25 17:00:11 Signed-off-by: Roman I Khimov Aug 25 17:10:30 eFfeM? Aug 25 17:10:49 eFfeM_work? Aug 25 17:11:05 Can you put lmbench 2.0.4 back please? 2.0.4, 2.5 and 3.0 are all kinda different beasts Aug 25 17:13:18 ah ok, is it still of any use ?? Aug 25 17:13:27 Well, I use it here :) Aug 25 17:13:56 ok I will revert, thought it was so outdated that no one is using it Aug 25 17:14:11 * Tartarus is one of those out of tree distro people Aug 25 17:14:17 so when adding 3.0 I thought it was better remvoed Aug 25 17:14:28 whenever there's major changes like a major version change its a good idea to keep the latest of each around, sounds like 2.0 is different enough from 2.5 that that's the case here Aug 25 17:14:30 * kergoth_ grumbles Aug 25 17:16:13 kergoth, yeah, well the latest (2007) version is 3.0, 2.0.4 is from 2003, so when introducing 3.0 I thought it would be appropriate to remove this very old version Aug 25 17:16:53 * kergoth_ nods Aug 25 17:17:08 * Crofton wishes people would quit equating a better OE with deleting everything they can find without understanding it Aug 25 17:17:23 03Frans Meulenbroeks 07org.openembedded.dev * rf41e81fc9d 10openembedded.git/recipes/lmbench/ (3 files in 2 dirs): Aug 25 17:17:24 Revert "lmbench-2.0.4: removed" Aug 25 17:17:24 This reverts commit 9600cc400c1aff9f7fc7068e3a02d1b64aeb6107. Aug 25 17:17:24 As requested by Tom Rini on irc. Aug 25 17:17:24 Apparently this was still used despite being from 2003. Aug 25 17:17:24 apologies for any inconvenience Aug 25 17:17:24 Signed-off-by: Frans Meulenbroeks Aug 25 17:17:31 there you go Aug 25 17:17:38 Thanks Aug 25 17:17:47 btw and I do have a good inderstanding what lmbench does Aug 25 17:17:59 Tartarus: yw Aug 25 17:18:43 * eFfeM wished people who knew the recipe cleaned up after them instead of leaving a trail of unused, unmaintained versions Aug 25 17:20:52 then this all would not be needed Aug 25 17:25:32 heh, that's why i think we need more individual responsibility over recipes, someone to give it the tlc Aug 25 17:26:29 kergoth_ well I proposed a few weeks ago to re-introduce recipe owners, then it is at least clear who to contact Aug 25 17:26:43 but didn't get too much feedback on the idea Aug 25 17:27:01 i quite like the idea, though i don't think we want to use MAINTAINER in the recipe for it Aug 25 17:27:06 i liek the idea, just not sure how to make it happen Aug 25 17:28:01 how can i add an extra include path to a recipe? Aug 25 17:28:14 could not even get a complete list of distro owners: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/022698.html Aug 25 17:28:22 and distro's are our first class citizen. Aug 25 17:28:35 etrunko, CFLAGS += "-I${S}/foo" or whatever Aug 25 17:28:48 effeM: that's worrisome Aug 25 17:29:15 maybe the best way to start adding recipe ownership is to just start grabbing some ourselves Aug 25 17:29:17 yeah, was searching for the word, I came up with disturbing Aug 25 17:29:20 kergoth_: thanks, will try Aug 25 17:30:03 kergoth_ it would help if the TSC would come with a proposal Aug 25 17:30:15 good idea Aug 25 17:30:24 you could email the tsc list :) Aug 25 17:30:39 and perhaps eventually we can split the recipes in a maintained and other dir Aug 25 17:30:50 kergoth_ will do Aug 25 17:31:27 actualy i feel quality and stability should be a topic at OEDEM Aug 25 17:31:53 i think everyone would agree with that Aug 25 17:32:04 we all know its a problem, just no one is clear on the best solution Aug 25 17:33:20 nope, and maybe the things I do are not always the best and definitely not always politically the best, but at least it brings something and it makes the discussion explicit Aug 25 17:33:42 well, what frustrates me is the drama that comes up whenever anyone does *anything* to improve matters Aug 25 17:33:48 i'm sorry, but stagnating is *not* the answer to this problem Aug 25 17:34:16 i mean not just changes to improve this, but anything at all invasive too Aug 25 17:34:51 i fully agree (and if some of the drama is at my side, my apologies; but sometimes a rough wakeu- call is needed) Aug 25 17:35:56 often people don't respond to the threads until you do something that breaks their stuff -- thats their own fault :) but i expect continuing to post removals to the lsit rather than juts doing them wil lmake it easier to blame them, and get lessp eople annoyed ;) Aug 25 17:36:29 what annoys me is people gravitate to deleting stuff, rather than doing anything actually make things better Aug 25 17:36:47 yeah, learned from it, but guess we would not made it if it was done through the list Aug 25 17:37:35 Crofton|work: if you look at the deletes you'll see that it also took care that the number of recipes that needed to be tackled for legacy staging and target/native integration is a lot less Aug 25 17:37:49 and if you peek into the commit log you'll see that I also fix problems Aug 25 17:37:55 kergoth_: yeah, that worked... kind of Aug 25 17:38:30 etrunko, of course, if the buildsystem of what you're building isn't obeying our CFLAGS, for whatever, reason, that won't help :) only really a danger with non-autotools recipes, standard makefile stuff Aug 25 17:38:37 aside from coaching Noor and Fasad who are working on removing legacy staging (and testing their changes) Aug 25 17:38:37 btw kergoth srctree does not work for kernel builds :( Aug 25 17:38:40 but STAGING_KERNEL_DIR is resulting in sysroots/armv7a-angstrom-linux-gnueabi, instead of my sysroots/babbage-angstrom-linux-gnueabi Aug 25 17:38:41 which is annoying Aug 25 17:38:47 hmm, that is annoying. what's the issue? Aug 25 17:38:49 linux.inc likes to mess with the defconfig Aug 25 17:39:08 oh, right. Hmm. Aug 25 17:39:15 so it need the defconfig in ${WORK} Aug 25 17:39:27 kergoth: ;) Aug 25 17:39:32 I could make it work bby hacking, but would rather not Aug 25 17:39:32 i'm using CFLAGS += "-I${STAGING_KERNEL_DIR}/include" Aug 25 17:39:34 one option would be to redirect workdir into the source tree Aug 25 17:39:40 we're overriding S, we could override WORKDIR too Aug 25 17:39:47 and then put your defconfig in work/ or something Aug 25 17:39:52 I have a cmake based and autotools based package to test next Aug 25 17:39:56 but itd be nice to have a variable to override the defconfig path being used Aug 25 17:39:59 that would be best i think Aug 25 17:40:01 yeah\ Aug 25 17:40:07 I could try that Aug 25 17:40:16 it should be "sysroots/babbage-angstrom-linux-gnueabi/kernel" instead of "sysroots/babbage-angstrom-linux-gnueabi" Aug 25 17:40:21 ooops Aug 25 17:40:25 for now, I copy in the kernel into the root fs Aug 25 17:40:25 the other way round Aug 25 17:40:30 any idea? Aug 25 17:41:45 Crofton|work, hmmm. need to give some thought to generally how to handle file:// files that aren't patches, not just for defconfig. they all end up in workdir during the unpack, adn we skip the unpack, so no file:// files will be where they're expected to be Aug 25 17:42:21 no hurry Aug 25 17:42:24 one possibility would be to do wihat we used to do ages ago, and have a script which you can run to copy a file:// file from its original location yourself Aug 25 17:42:33 I'll let you know how it goes for my other cases Aug 25 17:42:35 rather than "unpacking" them into workdir, the recipe could pull them itself from the original location Aug 25 17:43:00 it is a bit annoying the old file behavior changed though Aug 25 17:43:34 in tree stuff won't do that, but people's out of tree stuff might have broke Aug 25 17:44:04 Crofton btw it is not my intention to give anyone a hard time, but I (and from the reaction quite a few other people) feel that we've aggregated too much legacy junk). Cleaning ofc is not a very rewarding or inspiring activity but it is somethng that should happen. Some apparently have disinterest in cleaning their recipes, so I decided to pick up this non-rewarding boring task. Aug 25 17:44:10 I'm thinking of a threefold solution. 1) add var to override defconfig, 2) have srctree set WORKDIR=${S}, 3) potentially consider a shell function in utils.bbclass to find the file in filespath Aug 25 17:44:30 * eFfeM still does not understand why at some point we had about 12 versions of the abiword recipe Aug 25 17:45:27 I rather like the BBVERSIONS concept, lets you reduce the duplication of metadata by building the multiple versions we support from a single recipe with an extra override - then the cruft at least isn't piling up in the oe dir having to be parsed Aug 25 17:46:19 yeah Aug 25 17:46:30 that would work well for sane packages Aug 25 17:46:46 crap like boost with api changes and builds system changes is harder Aug 25 17:46:49 what i really want in our next file format is the notion of 'override blocks' Aug 25 17:46:52 so you could do like Aug 25 17:46:59 pv-1.0.1 [ Aug 25 17:46:59 that would help, but still we should ascertain one way or another that these version actually work Aug 25 17:47:00 a=b Aug 25 17:47:02 c=d Aug 25 17:47:05 a+=e Aug 25 17:47:06 ] Aug 25 17:47:55 effeM: agreed. which comes back to the notion of recipe ownership -- its owner should make sure they all continue to build. it's not that hard to do a loop build to build them all Aug 25 17:48:59 not for the 20 or so I have, for the complete system it is tough though Aug 25 17:49:54 well, if all the important stuff was owned, the work for each individual wouldn't be terrible -- the only real difficulty are libs, but if upstream is sane they won't break it in a minor version, so you don't have to test everything that links against it Aug 25 17:51:02