**** BEGIN LOGGING AT Mon Aug 16 02:59:56 2010 Aug 16 04:19:20 hello Aug 16 04:21:13 I have problem with mini2440 with 3.5''tft screen.I am using Angstrom. Aug 16 04:22:08 screen become white and blank .Butt serial console is working properly. Aug 16 04:23:13 i am passing mini2440=0tb also to kernel Aug 16 07:05:36 gm Aug 16 07:06:38 'morning eFfeM_work Aug 16 07:07:04 thx for the time-consuming work Aug 16 07:07:31 (cleaning and disinfection ) Aug 16 07:07:38 :p Aug 16 07:09:05 are we nowt below 8000 items to parse? Aug 16 07:09:14 couldm't check it yet Aug 16 07:11:59 yes Aug 16 07:12:08 but there seems to be an issue with docbook Aug 16 07:12:21 khem posted a workaround Aug 16 07:12:34 apparently a recipe decided to depend on a specific version of docbook Aug 16 07:12:47 didn't even know that a DEPENDS on a specific version was possible Aug 16 07:12:55 well, that's a minor regression compared to the cleaning Aug 16 07:13:03 advantages Aug 16 07:13:04 but we are a lot below 8000 Aug 16 07:13:18 great Aug 16 07:13:21 ty :-) Aug 16 07:13:38 not everyone was happy (as I was aware when I started this) Aug 16 07:13:39 I'll have some linux-kexecboot cleanings to do Aug 16 07:13:54 before merging in linux Aug 16 07:14:13 eFfeM_work: dress your asbest suit :) Aug 16 07:14:20 :-) Aug 16 07:14:50 the nice words of people like you help to bring the snide remarks into perspective Aug 16 08:08:16 hi Noor Aug 16 08:08:25 hello eFfeM_work Aug 16 08:08:29 How r u doing? Aug 16 08:08:49 i'm fine thank you Aug 16 08:08:59 pushed your changes Aug 16 08:09:13 thanks Aug 16 08:09:18 I have some more recipes Aug 16 08:09:23 i'll upstream them today Aug 16 08:09:43 feel free to post them, I can probably peek at them tonight Aug 16 08:09:49 OK Aug 16 08:09:54 just want to confirm one thing Aug 16 08:10:36 ask Aug 16 08:11:15 in sdcc bison and flex is required in configuration Aug 16 08:11:25 i have added those in its dependencies Aug 16 08:11:54 just want to conform that it is right or it assumes that bison and lfex will be installed on the host system Aug 16 08:11:55 I assume you need bison-native and flex-native Aug 16 08:12:00 yeah Aug 16 08:12:14 i am talking about sdcc-native recipe Aug 16 08:13:31 i think you should add them, there are other recipes that do so too (and it definitely does not harm) Aug 16 08:14:21 OK Aug 16 08:14:24 Thanks Aug 16 08:14:45 yw Aug 16 08:14:51 it upstream that change as well in a seperate patch Aug 16 08:15:10 ok Aug 16 08:15:36 just tell me when I upstream removing Legacy Pathc should I add this thing in recipe or not Aug 16 08:15:48 if i will not add this thing recipe will not work Aug 16 08:16:06 although it will be upstreamed in other patch Aug 16 08:16:16 morning Aug 16 08:16:25 afk for a moment Aug 16 08:19:32 Noor: if the patch is also sent upstream it should still be added to the recipe (unless upstream applies the patch quickly and you come up with a new recipe with the fixed upstream Aug 16 08:20:05 normally our recipes build towards a specific version, even when building from git or svn Aug 16 08:20:32 so if upstream accepts it this could lead to a new recipe or a new version of a recipe (or a modified recipe) Aug 16 08:24:00 OK Aug 16 08:49:42 03Jason Kridner  07org.openembedded.dev * r66848a81f7 10openembedded.git/recipes/ (5 files in 5 dirs): Aug 16 08:49:42 u-boot/angstrom-uboot-scripts/beagleboard-test-image: increase ramdisk Aug 16 08:49:42 * add initramfs image Aug 16 08:49:42 * move to 128MB ramdisk until I can get initramfs working Aug 16 08:49:42 Signed-off-by: Jason Kridner Aug 16 08:49:42 Signed-off-by: Koen Kooi Aug 16 08:50:07 03Jason Kridner  07org.openembedded.dev * rd74d5d8715 10openembedded.git/recipes/images/beagleboard-test-image.bb: Aug 16 08:50:07 beagleboard-test-image: add dsplink Aug 16 08:50:07 Signed-off-by: Jason Kridner Aug 16 08:50:07 Signed-off-by: Koen Kooi Aug 16 08:55:56 03Koen Kooi  07org.openembedded.dev * r59d950ada0 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: xorg-xserver: bump PR Aug 16 08:57:41 eFfeM_work: should I give the configure error that is popped up when bison-native and flex-native is missing for sdcc-native in patch Aug 16 08:58:07 or just mention that confidure failes on flex and bison Aug 16 08:58:41 Noor: it is ok just to mention that bison and flex are needed to run configure and that therefore they are added as dependencies Aug 16 08:58:59 OK Aug 16 09:00:39 in this case do i have to bump PR number as well? Aug 16 09:01:38 good morning Aug 16 09:02:20 Noor: yes if you change something that may affect the build process bump PR Aug 16 09:02:31 better safe than sorry and you have added a dependency Aug 16 09:02:35 hi florian Aug 16 09:28:36 03Frans Meulenbroeks  07org.openembedded.dev * rf4483f87cc 10openembedded.git/recipes/openssl/ (11 files in 3 dirs): Aug 16 09:28:37 Revert "openssl: removed old 0.9.8 versions; these have security vulnerabilities" Aug 16 09:28:37 This reverts commit a0a7a2710d0ea14ac41015e9b8f99fc8b4c687b3. Aug 16 09:28:37 Missed the DEFAULT_PREFERENCE = "-1" on the 1.0 recipe. Aug 16 09:29:40 mickey|office: hi Aug 16 09:31:20 good morning eFfeM_work Aug 16 09:32:18 mickey|office: seems I made some friends over the weekend ;-) Aug 16 09:34:42 eFfeM_work: oh well, some collateral damage is always to be expected. i think all has been pretty non-intrusive, esp. compared to other transition phases master has gone through. stuff can be fixed. Aug 16 09:34:59 03Frans Meulenbroeks  07org.openembedded.dev * r4b38463f53 10openembedded.git/recipes/docbook-sgml-dtd/ (2 files): Aug 16 09:34:59 Revert "docbook-sgml-dtd*native: remove old versions" Aug 16 09:34:59 This reverts commit 5329088185d8f55f721cba92deab06dc859e9df1. Aug 16 09:34:59 some recipes pin specifically to the 3.1 version, so reinstating that one Aug 16 09:36:00 mickey|office: I've unrolled the openssl and docbook commits, there are a few others I want to peek at but that'll have to wait until tonight Aug 16 09:36:14 eFfeM_work: good. Aug 16 09:37:18 btw we still have 261 native recipes left and 540 ones which do a do_stage Aug 16 09:37:36 but at least we seem to be getting towards manageable numbers Aug 16 09:38:00 oh yes. considering where we started from that sounds pretty good Aug 16 09:46:33 eFfeM_work: the black hole seems to be recipes/linux: I suppose the archeo-2.4 kernels would not build anymore and even if they would, there will be so many issues with userspace Aug 16 09:47:12 ant_work: I explicitly skipped linux/u-boot/gcc/binutils and a few others Aug 16 09:47:22 yea ;) Aug 16 09:47:35 but especially linux and u-boot are quite disorganized Aug 16 09:48:20 unfortunately there is not enough feedback about old boards/machines Aug 16 09:48:40 old or seldom used Aug 16 09:48:45 e.g. there seem to be about 5 gits for omap3 Aug 16 09:48:57 iirc there is pending sakoman work Aug 16 09:49:16 old machines is indeed an issue, since there is no owner identified it is hard to say something about status Aug 16 09:49:23 heh Aug 16 09:49:57 back to linux: personally I'd say things like gcc3 or linux 2.4 do not belong in dev head any more Aug 16 09:50:20 imagine we still have gcc295 deps for some kernels Aug 16 09:51:25 actually I have seen a recipe from 2008 (not kernel related) that was probably never build as the deps were wrong Aug 16 09:51:41 and recipes that refer to patches that do not exist Aug 16 09:51:48 probably moving to nonworking is sane Aug 16 09:52:04 is noworking parsed or skipped btw? Aug 16 09:52:18 i've posted the list, if no action it taken i'll move it there Aug 16 09:52:40 typically it is skipped, the dir level is one deeper, depends on how you define BBFILES or BBPATH Aug 16 09:54:23 ant_work: feel free to write an RFC to remove 2.4 kernels Aug 16 09:55:48 are there machines with 2.4 only? Aug 16 09:56:04 I suppose all comes from OpenZaurus Aug 16 09:56:11 sharprom-toolchain Aug 16 09:56:48 years ago Aug 16 09:57:24 only these Aug 16 09:57:24 frans@frans-desktop:~/workspace/openembedded.git/conf/machine$ grep "2\.4" * Aug 16 09:57:25 mtx-1.conf:KERNEL_VERSION_mtx-1 = "2.4.27" Aug 16 09:57:25 mtx-2.conf:KERNEL_VERSION_mtx-2 = "2.4.27" Aug 16 09:57:44 actually i should also check include Aug 16 09:58:13 some machiens mention 2.4 in comment but that's it Aug 16 09:59:01 pheww Aug 16 09:59:08 I'll have to check Martin Jansa : shr: blacklist all 2.4 kernels, because of multiple ERRORs it shows in every build Aug 16 09:59:39 yeah saw that as well Aug 16 10:00:09 iirc we solved just by setting compatible_machine inthat old recipes Aug 16 10:00:37 so it does not taint other machines as preferred provider for kernel :) Aug 16 10:01:32 heh Aug 16 10:01:34 ANGSTROM_BLACKLIST_pn-linux-davinci = "strange kernel, spank maintainer" Aug 16 10:01:36 fun Aug 16 10:02:28 :P Aug 16 10:03:44 btw there are still quite some 2.4 recipes which would be used based upon machine suffix or preference Aug 16 10:04:27 I'd let those to stable Aug 16 10:05:47 I suppose if one in 2010 uses 2.4 kernels he has not many choices (custom modules) Aug 16 10:05:58 guess so Aug 16 10:06:16 so should stick with vendor kernel Aug 16 10:07:37 probably are reminescences of old router work Aug 16 10:08:04 with custom DSL modules (รจ la Broadcom) Aug 16 10:08:39 yup Aug 16 10:13:47 03Koen Kooi  07org.openembedded.dev * r57f89c7392 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: Aug 16 10:13:47 angstrom: pin openssl to 1.0.0 Aug 16 10:13:47 * This needs a PR bump of affected recipes, but a DISTRO_PR bump is imminent Aug 16 10:59:03 eFfeM_work: that last patch that Frans added, he ran oe_stylize script and added the output of oe_stylize Aug 16 11:00:18 should i do it as well, I mean submit the patch that oe_stylize outputs. Although it will change the whole recipe. Aug 16 11:01:33 the output of oe_stylize is quite different than the recipe that is present in reposetory Aug 16 11:03:34 check with care the include/require and try to rebuil. if all it's ok can be committed Aug 16 11:03:45 btw eFfeM_work = Frans Aug 16 11:04:08 :D Aug 16 11:04:10 OK Aug 16 11:12:10 Aug 16 11:12:21 back from lunch Aug 16 11:12:52 I'd say run through stylize but indeed take care with include/require and always do a test build after stylize Aug 16 11:13:05 OK Aug 16 11:13:13 yeah thats what I am doing Aug 16 11:14:14 i'll always try to do a verification build too before committing patches from the list Aug 16 11:14:55 i was just confirming that should i submit oe_stylize output as it changes the recipe alot Aug 16 11:15:37 Noor: btw FM are my initials, my name was too long for irc, Frans was taken, FM was taken or too short (forgot) so thats why I came to eFfeM wth the weird capitalisation (sounds like FM) Aug 16 11:16:06 but XorA has found a completely different explanation ;-) Aug 16 11:16:34 and what was that Aug 16 11:16:38 Noor: wrt stylize: also some new fields are not in oe-stylize Aug 16 11:16:42 F*** em Aug 16 12:30:48 Noor: saw your sdcc recipe, it would be nice if you also could change do_stage into do_install and add a NATIVE_INSTALL_WORKS Aug 16 12:31:41 Noor: actually even better, convert the recipe to BBCLASSEXTEND="native" Aug 16 12:32:12 (and I would expect the non-native recipe also to depend on bison-native and flex-native) Aug 16 12:34:04 hhmmm actually non-native recipe depends of native. sdcc-native is written in its DEPENDS list Aug 16 12:36:01 Noor: ah ok that will drag in bison and flex Aug 16 12:36:11 yeah Aug 16 12:37:23 my second patch is related to removal of legacy staging, coming in few min Aug 16 12:37:57 ah ok Aug 16 12:40:56 i created a new bb file and while compiling i got this error: ".. ld: skipping incompatible ..." Aug 16 12:44:10 ?? Aug 16 12:50:54 eFfeM_work: should I follow the steps that Paul has recommended for next recipes that I have in queue? Aug 16 12:51:03 is this the formal procedure Aug 16 12:51:49 well the procedure is not that formal, using stylize is not too common, but if you are fixing things it is a good plan to improve the layout too Aug 16 12:52:22 and there is a point in having it in separate commits Aug 16 12:52:30 ahan Aug 16 12:52:36 typically one commit is one change Aug 16 12:52:44 OK Aug 16 12:53:05 or a number of related changes, but these are quite independent so are probably better separate patches Aug 16 12:53:21 (which means a little bit more work for me to apply them though :-( ) Aug 16 12:54:26 rules are not cast in stone though Aug 16 12:57:12 and bit of more work for me as well :) Aug 16 12:59:01 no answer to me? Aug 16 12:59:03 git commit -s xx.bb -m "xx: oe-stylized" Aug 16 12:59:49 ndemir: your error message is too terse to say anything about it (but I must say I hadn't seen it) Aug 16 13:00:15 eFfeM_work: can you give me a good tutorial to create a bb file. Aug 16 13:00:41 i am trying to create a bb file for lshw tool. Aug 16 13:01:19 eFfeM_work: lshw is a simple tool which can be compiled with only make command. Aug 16 13:08:30 ndemir: was afk Aug 16 13:10:05 ndemir: openembedded manul is at http://docs.openembedded.org/usermanual/html/ Aug 16 13:10:14 you might also peek at some other simple recipes Aug 16 13:11:34 there are plenty simpleones around Aug 16 13:57:20 03Simon Busch  07org.openembedded.dev * rdc54877a1e 10openembedded.git/recipes/lvm2/lvm2.inc: Aug 16 13:57:20 lvm2.inc: remove unnecessary EXTRA_OECONF_arm line from recipe Aug 16 13:57:20 Signed-off-by: Simon Busch Aug 16 13:57:20 Acked-by: Stefan Schmidt Aug 16 13:57:37 03Simon Busch  07org.openembedded.dev * raefe7a444c 10openembedded.git/recipes/lvm2/ (4 files in 2 dirs): Aug 16 13:57:37 lvm2: rebase all recipes on a global lvm2.inc recipe Aug 16 13:57:37 This rebases all specific versions of lvm2 on a global recipe lvm2.inc which defines the Aug 16 13:57:37 common parameters for building lvm2. Staging is overwritten as we don't need any of the Aug 16 13:57:38 executables or manpages the build of lvm2 produces for any related builds. Aug 16 13:57:38 Signed-off-by: Simon Busch Aug 16 13:57:39 03Simon Busch  07org.openembedded.dev * r91109cc11b 10openembedded.git/recipes/lvm2/ (files/lvm.conf lvm2.inc): Aug 16 13:57:47 lvm2.inc: add machine specific configuration file Aug 16 13:57:48 For some machines we need a specific lvm configuration to detect the captable devices Aug 16 13:57:48 which can contain a lvm volume. Aug 16 13:57:48 Signed-off-by: Simon Busch Aug 16 13:57:48 Acked-by: Stefan Schmidt Aug 16 13:57:48 03Simon Busch  07org.openembedded.dev * rc17c517bc1 10openembedded.git/recipes/lvm2/ (files/include-limits.patch lvm2.inc): Aug 16 13:57:49 lvm2.inc: add patch to fix building Aug 16 13:57:49 lvm2 fails to build cause there is a include of limits.h missing. The patch adds the Aug 16 13:57:50 include to the relevant file of the lvm2 source. Aug 16 13:57:50 Signed-off-by: Simon Busch Aug 16 13:57:51 Acked-by: Stefan Schmidt Aug 16 13:57:51 03Simon Busch  07org.openembedded.dev * r47b3089c43 10openembedded.git/recipes/lvm2/files/palmpre/lvm.conf: Aug 16 13:57:52 lvm2: add configuration file for palmpre machine Aug 16 13:57:53 Signed-off-by: Simon Busch Aug 16 13:57:53 Acked-by: Stefan Schmidt Aug 16 14:43:54 I want to compile lshw with bitbake. It depends on libc6, libgcc1 and libstdc++6. What should i write to bb file for DEPENDS? Aug 16 14:43:59 ? Aug 16 15:03:23 03Martin Jansa  07org.openembedded.dev * r1ac5a19b93 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Aug 16 15:03:23 shr: prefer openssl 1.0.0 Aug 16 15:03:23 Signed-off-by: Martin Jansa Aug 16 15:03:31 03Martin Jansa  07org.openembedded.dev * r8dd59bdb18 10openembedded.git/recipes/ (15 files in 12 dirs): Aug 16 15:03:32 recipes: bump PR in recipes depending on openssl after SHR and Angstrom moved to openssl-1.0.0 Aug 16 15:03:32 Signed-off-by: Martin Jansa Aug 16 15:05:37 03Martin Jansa  07org.openembedded.dev * r637002603d 10openembedded.git/ (20 files in 10 dirs): Aug 16 15:05:37 xorg: add latest packages for 2010-08-16 Aug 16 15:05:37 Signed-off-by: Martin Jansa Aug 16 15:25:10 morning Aug 16 15:25:58 hi kergoth_ Aug 16 15:26:03 hey florian Aug 16 15:26:05 how's it going? Aug 16 15:31:35 mmh... it would be better when openssl has been updated to 1.0.0a before pinning the 1.0.0 version Aug 16 15:37:10 hi kergoth Aug 16 15:40:07 eFfeM_work: I guess you'll like my 9 patches just sent to oe-devel :) Aug 16 15:44:21 03Martin Jansa  07org.openembedded.dev * r46a6b6eed0 10openembedded.git/recipes/python/python-native_2.6.4.bb: python-native: bump PR after openssl upgrade Aug 16 16:15:48 eFfeM_work: I just submitted and ugly, but hopefully harmless, patch to fix building libgcrypt on my machine. no good idea of root cause. Aug 16 16:16:11 anyway, moving to latest OE didn't work, but the submitted patch did. Aug 16 16:19:55 hmmm, now I'm having problems with shared-mime-info-native. it seems to be missing freedesktop.org.xml.in and update-mime-database.c Aug 16 16:23:12 hmmm... the files are there. Aug 16 16:23:33 right in the location that po/missing says they should be. Aug 16 16:38:00 ugh, this problem has existed over a year without a patch: http://groups.google.com/group/beagleboard/browse_thread/thread/0ca02e78e21709f1?fwc=1 ! Aug 16 16:39:29 khem, looks like I was not testing http://pastebin.com/iGFrxYkP properly last week - it doesn't work, nor does using a do_unpack_prepend to modify SRC_URI. The issue is that do_patch's bb.data.getVar('SRC_URI', d) does not contain my changes - any idea why a bb.data.setVar('SRC_URI', d) from do_unpack would not show up in a bb.data.getVar from do_patch? Aug 16 16:39:49 I must not be understanding bb's use of 'd' or something, I assume thats a global dataset var Aug 16 16:40:20 every task gets its own *copy* of the datastore Aug 16 16:40:28 changes done in a task never leak into other tasks Aug 16 16:40:41 that would be my issue then... is that what update_data is for? Aug 16 16:41:00 no Aug 16 16:41:04 update_data applies overrides Aug 16 16:41:18 you never need to touch it unless you're changing OVERRIDES Aug 16 16:41:29 and even then its likely not the best course of action Aug 16 16:43:31 so what is the right way for a task to alter the datastore? Aug 16 16:44:11 ? Aug 16 16:44:19 again, any changes a task makes to the datastore are local to that task Aug 16 16:44:20 period. Aug 16 16:45:49 as an example of a case where vars need to be set in one function and used in another, the packaging process adjusts PACKAGES and the rdepends and the like dynamically. if you look at package.bbclass, you'll see that it's one task which runs multiple functions, so the changes persist across the functions, just within a single task Aug 16 16:45:57 so that works around the issue in that particular case Aug 16 16:46:21 I see, so if I'm trying to add a file to be patched (in a way that needs some python processing to see if it needs to be added) I don't want to mess with do_unpack, I want to simply mess with do_patch (or perhaps both if I need do_unpack to copy the file where do_patch can get to it) Aug 16 16:46:24 there are cases where files are written to in tmpdir and read from in subsequent tasks to share information Aug 16 16:46:28 but a task cannot touch the global datastore, period Aug 16 16:47:04 kergoth_, this is what I'm trying to do: http://pastebin.com/iGFrxYkP - in the case of a specific kernel provider I need an additional patch for a recipe Aug 16 16:47:15 yeah, that would be an option. i assume this logic requires that it looks at the source tree, so you can't do it in an anonymous python function? Aug 16 16:47:33 in that pastebin example, du_unpack does copy the file to the workdir but do_fetch doesn't apply the patch, now I understand why Aug 16 16:47:34 you can do that just fine in an anonymous python function Aug 16 16:47:42 or a def'd function called from an anonymous python snippet Aug 16 16:47:55 SRC_URI += "${@my_function(d)}" Aug 16 16:48:07 then def my_function(d): which returns the extra patch if the condition is true, or the empty string otherwise Aug 16 16:48:11 ah... that sounds like a nice option Aug 16 16:48:25 in this way you're changing the recipe wide metadata, not messing with task specific Aug 16 16:49:19 see, the problem with tasks changing the metadata is its non-deterministic Aug 16 16:49:28 if tasks run in a slightly different order due to unexpressed deps, you're fucked Aug 16 16:50:20 that makes sense Aug 16 17:16:42 kergoth_, khem thx - the following worked great to add a patch to a kernel based recipe just for a specific provider: http://pastebin.com/uniZpa72 Aug 16 17:19:24 tharvey, you can kill the leading space both in the function and in the SRC_URi append Aug 16 17:19:27 += adds a space already Aug 16 17:20:43 ah true, thx - also adding _${KERNEL_VERSION} as patch is dependent on that as well Aug 16 17:21:55 03Andrea Adami  07org.openembedded.dev * ra55666696b 10openembedded.git/recipes/klibc/ (klibc-1.5.19/klibc-x86-KLIBCARCHINCFLAGS.patch klibc.inc): Aug 16 17:21:56 klibc: remove superfluous KLIBCARCHINCFLAGS patch Aug 16 17:21:56 * OE patch went upstream with 1.5.19 (28da73a8add68f4abf68c417ac9559acc5d06861) Aug 16 17:21:56 * OpenEmbedded patch c/o Khem Raj. Thx. Aug 16 18:09:24 argh, stupid remarks on http://groups.google.com/group/beagleboard/browse_thread/thread/0ca02e78e21709f1 sent me on a wild goose chase. The paths are getting truncated. Aug 16 18:09:46 * jkridner1 looks for a patch that will avoid the truncation issue. Aug 16 18:24:29 eFfeM_work: latest issue is shared-mime-info(-native) not building due to paths being truncated. any idea how to fix that besides mounting everything in a shorter path? Aug 16 18:25:59 _chase_, denix: any thoughts on building shared-mime-info when the paths get truncated? it thinks files are missing that aren't because the file names are too long. Aug 16 18:28:31 <_chase_> jkridner1: not off the top of my head. Let me look at it. Aug 16 18:29:15 03Koen Kooi  07org.openembedded.dev * ra28f286e2e 10openembedded.git/recipes/guile/ (guile-1.8.7/18.diff guile_1.8.7.bb): guile 1.8.7: sync up with the 1.8 release branch Aug 16 18:33:33 I really should fire off a clean build ... Aug 16 18:33:42 but I am stuck in fpga debug land :) Aug 16 19:04:47 03Frans Meulenbroeks  07org.openembedded.dev * r53428e7357 10openembedded.git/recipes/coreutils/ (24 files in 4 dirs): Aug 16 19:04:48 Revert "coreutils: removed old versions" Aug 16 19:04:48 This reverts commit 82dcd385984ba059b346a0e37fd3e14d536074ad. Aug 16 19:04:48 reverted coreutils removal as 7.0 and up is GPLv3, so there is Aug 16 19:04:48 a desire to keep 6.0. Aug 16 19:16:32 03Frans Meulenbroeks  07org.openembedded.dev * rd4b0e80b84 10openembedded.git/recipes/coreutils/ (11 files in 2 dirs): Aug 16 19:16:32 coreutils: removed 7.1 and 7.2 Aug 16 19:16:32 Signed-off-by: Frans Meulenbroeks Aug 16 19:16:43 03Noor Ahsan  07org.openembedded.dev * rae47dc5c99 10openembedded.git/recipes/sdcc/sdcc-native_2.8.0.bb: Aug 16 19:16:43 sdcc-native: Run oe-stylize.py Aug 16 19:16:43 * Run 'oe-stylize.py' on the recipe and make changes accordingly Aug 16 19:16:43 Signed-off-by: Noor Ahsan Aug 16 19:16:44 Acked-by: Frans Meulenbroeks Aug 16 19:17:24 Noor: just pushed your patch, expected a 2nd patch, it is ok to send two patches at the same time (e.g. you can use git format-patch -2 to generate patches for the last two commits) Aug 16 19:21:24 Noor and if you submit a new version please set the old version in patchwork to superseded Aug 16 19:22:06 JaMa: wanted to try your patches but 2 is not in patchowrk and 1 has a strange subject line Aug 16 19:25:51 eFfeM: you should send your cleanup patches to ml before you commit them Aug 16 19:26:04 eFfeM: that way you can avoid lot of aftermath Aug 16 19:27:33 khem, I understand your point Aug 16 19:27:46 then again on lots of patches I send to the ML I just get no reaction Aug 16 19:27:50 eFfeM: strange, I'll check Aug 16 19:28:07 or we would have gotten a yes/no battle upfront (and we've been already there a few times) Aug 16 19:30:38 eFfeM: this is what git send-email said to me when I was sending it first and now again :/ "The following files are 8bit, but do not declare a Content-Transfer-Encoding." Aug 16 19:34:58 jama guess there are some old files in it Aug 16 19:35:15 btw any particular reason to move to obsolete (see also my email) ? Aug 16 19:37:38 eFfeM: it forewarns Aug 16 19:37:58 I build from scratch often Aug 16 19:39:48 khem yeah a forewarning would have been better Aug 16 19:40:53 actually to some extend it was given, I started on a smaller scale about a weeka go, actually expecting neg feedback, didn't get any feedback, this weekend I was inspired/bored (choose your pick) and gave it a big stab Aug 16 19:41:09 but yeah, it could have been done better Aug 16 19:41:39 eFfeM: there is a variety of requirements in OE Aug 16 19:42:03 and you can not meet all but it can be discussed beforehand and expectations set accordingly Aug 16 19:42:20 embedded world is fragmented and it always will be Aug 16 19:42:38 true Aug 16 19:42:47 I'll try to take more care next time Aug 16 19:42:51 one reason of OE success is that it supports soo many packages and so many versions of them Aug 16 19:43:04 you call it feature or bug Aug 16 19:43:07 but thats true Aug 16 19:43:21 there still are embedded people who want to use gcc 4.1 Aug 16 19:43:25 as of today Aug 16 19:44:08 i have no problems with many packages, Aug 16 19:44:29 and actually I need gcc 4.1; it is the only version that supports nios2 Aug 16 19:45:10 then you know it. now suppose I go and remove gcc 4.1 think its old Aug 16 19:45:17 how would you react Aug 16 19:45:35 :) Aug 16 19:45:42 so IMO Aug 16 19:45:45 first try to fix Aug 16 19:45:46 eFfeM: it's because "Copyright" symbol in recipes/obsolete/xorg/xorg-app/xmodmap/autofoo.patch Aug 16 19:45:53 actually the gcc recipes are well maintained, but lots of old recipes are really orphaned and I saw no one taking action to remove legacy staging and convert to BBCLASSEXTEND = "native" Aug 16 19:45:57 if its not fixable then send a notice of removal Aug 16 19:46:21 eFfeM: you wont know unless you break something Aug 16 19:47:08 khem, yeah the notice would have been better, actually I tried quite carefully not to remove anything that was pinned or had a PREFERENCE on it, but yes I introduced a few issues Aug 16 19:47:10 at work I moved a file which was untouched for 8 years and 3 hours later I had an email that something broke Aug 16 19:47:27 so never say never :) Aug 16 19:47:51 btw and if it is decided to remove gcc 4.1, I would not be too upset, I would just put in in my local overlay Aug 16 19:48:24 actually we do most of our work on a frozen tree, backporting things that are really needed Aug 16 19:48:34 and we move forward only every once in a while Aug 16 19:48:56 but I understand that others work differently Aug 16 19:48:59 and have different needs Aug 16 19:49:15 like with the license issue Aug 16 19:49:27 JaMa: no idea on how to resolve the copyright symbol Aug 16 19:50:10 eFfeM: we should always try to address comminity needs as prio 1 Aug 16 19:50:25 otherwise community stops to care for the project Aug 16 19:50:44 IMO, the work you are doing is great Aug 16 19:51:29 JaMa: will this do the trick? --8bit-encoding= Aug 16 19:51:32 if we keep a keen eye on requirements and also not make someone suffer too badly then its very good Aug 16 19:51:49 Jay7: I had to convert the patch to utf8 first Aug 16 19:52:01 JaMa: what is the problem ? Aug 16 19:52:19 Jay7: --8bit-encoding=UTF-8 is what was used after confirming that interactive option I guess Aug 16 19:53:09 khem: git format-patch or git send-email, dumps some file (patch in xorg-lib and xorg-app) in cp1250 and then for sending I used default option UTF-8 as content-encoding Aug 16 19:53:37 khem, I agree with you, community is indeed #1 prio Aug 16 19:55:07 JaMa: us-ascii or utf should be better Aug 16 19:55:57 eFfeM: growing community always helps and we should be promoting new and existing users and listening to what one says Aug 16 19:56:17 sometimes good ideas come around which can improve the project Aug 16 19:56:18 khem: that's why I dumped it first with format-patch, then converted to utf-8 with iconv and then resend as PATCHv2 again with UTF-8 as content-encoding Aug 16 19:56:43 why is it cp1250 first I dont understand Aug 16 19:58:56 khem: probably the source was cp1250, so the patch for that file had to be also cp1250 to apply cleanly Aug 16 19:59:15 khem: I mean the paatch for xmodmap, not patch for OE Aug 16 19:59:37 * JaMa is going to push python-2.6.5 from poky Aug 16 20:01:04 03Fahad Usman  07org.openembedded.dev * readb7a0e36 10openembedded.git/recipes/dcop/dcopidl-native_3.5.8.bb: Aug 16 20:01:04 dcopidl-native_3.5.8.bb: Removed legacy style staging Aug 16 20:01:04 * converted do_stage to do_install and replaced ${STAGING_BINDIR} with ${D}${bindir} Aug 16 20:01:04 * and treated the source with oe-stylize.py script Aug 16 20:01:05 Signed-off-by: Fahad Usman Aug 16 20:01:11 03Frans Meulenbroeks  07org.openembedded.dev * r089e125197 10openembedded.git/recipes/openssl/ (5 files in 2 dirs): Aug 16 20:01:11 openssl 0.9.8g; removed (0.9.8m stays) Aug 16 20:01:11 Signed-off-by: Frans Meulenbroeks Aug 16 20:05:48 JaMa: 1/9 again shows up with the weird subject line, 2/9 is not on patchwork yet Aug 16 20:06:18 eFfeM: weird subject is imho right that's how utf-8 subject should be sent Aug 16 20:11:23 2/9 is also there Aug 16 20:14:12 mickeyl: why there is python-devel instead of python-dev? can I rename it to python-dev (otherwise there is QA Issue: "ERROR: QA Issue with libpython2: non -dev package contains symlink .so: libpython2 path '/work/armv4t-oe-linux-gnueabi/python-2.6.4-ml10.1/packages-split/libpython2/usr/lib/libpython2.6.so' Aug 16 20:15:14 jama, 1/9 and 2/9 are on patchwork with weird subject lines, but git am gives an error saying that some patches do not apply Aug 16 20:16:24 eFfeM: try to download those from : http://gitorious.org/~jama/angstrom/jama-shr-experimental/ Aug 16 20:23:28 will try Aug 16 20:25:23 might be tomorrow before I can apply/test Aug 16 20:25:33 still working on something else Aug 16 20:40:49 03Frans Meulenbroeks  07org.openembedded.dev * rd6dd78e7f7 10openembedded.git/recipes/python/python-pygtk_2.8.6.bb: Aug 16 20:40:50 python-pygtk_2.8.6.bb removed Aug 16 20:40:50 underlying gtk+ version is not there any more Aug 16 20:40:50 newer version exists Aug 16 20:40:50 Signed-off-by: Frans Meulenbroeks Aug 16 21:06:33 hmmm... bison was building for me until my last update. Aug 16 21:06:47 * jkridner wonders if it is pstage or if someone made a patch that broke it. Aug 16 21:06:53 jkridner: bison native ? Aug 16 21:07:00 yup Aug 16 21:07:05 whats the error Aug 16 21:07:22 it was complaining about not finding flex output. Aug 16 21:07:46 configure: error: cannot find output from flex; giving up Aug 16 21:07:56 ah Aug 16 21:08:02 is flex built ok Aug 16 21:08:14 I was looking at that... it seems to have built first. Aug 16 21:08:35 it got to setscene on flex fine. Aug 16 21:09:44 * jkridner is doing -c clean bison; bitbake flex-native; bitbake bison to see. Aug 16 21:10:56 jkridner, I guess bison recipe is not ok, there is no dependency on flex Aug 16 21:11:48 bedtime, cya tomorrow Aug 16 21:26:23 khem, eFfeM: that wasn't it. bitbake -c clean bison-native; bitbake flex-native; bitbake bison-native; still failed. Aug 16 21:27:00 I was in the process of sending a patch, but I think that can be NAK'd. Aug 16 21:35:47 why doesn't someone disable packaged staging for quilt-native? Aug 16 21:38:39 ah, it was the flex package staging that was the problem. 'bitbake -c clean flex-bison' worked. Aug 16 21:38:47 er, flex-native Aug 16 21:48:33 Odd. During binary locale generation, qemu has a nonzero chance of segfaulting or having relocation errors. Has anyone else seen that on Ubuntu? Aug 16 21:49:09 I'm running the same command repeatedly under qemu-arm locale-tree, and it segfaults or has a relocation error about 1 in 8 times. Aug 16 21:52:40 xobs: what specific error you see Aug 16 21:52:51 jkridner: I will try to reproduce Aug 16 21:53:05 Sometimes it's "qemu-arm: relocation error: qemu-arm: symbol fcntl, version GLIBC_2.0 not defined in file libpthread.so.0 with link time reference". Sometimes it's "Segmentation fault". Sometimes it's "qemu-arm: relocation error: qemu-arm: symbol unlink, version GLIBC_2.0 not defined in file libc.so.6 with link time reference". Aug 16 21:53:48 xobs: and you are using same machine to build and run qemu Aug 16 21:53:53 khem: Most of the time (>80%) it works just fine, but since it has to generate many locales when building glibc, it never succeeds during all of them. Aug 16 21:54:19 khem: Yes, this has all been built in this one virtualbox instance. I started a new tmp directory yesterday. Aug 16 21:56:02 xobs: ok. I do not build locales here so probably I never get bitten by this problem Aug 16 21:57:36 xobs: which version of ubuntu are you usin Aug 16 21:59:58 khem: 10.04. I need to build locales this way as the device they're going to only has 64 MB of RAM. Aug 16 22:03:28 xobs: I understand. I have plans to add cross localedef to eglibc Aug 16 22:03:34 then we wont need qemy Aug 16 22:03:40 qemu atleast for eglibc Aug 16 22:07:26 khem: Is there any way I can limit the locals generated for testing to, say, en_US? I'd like to get this test image at least booting all the way. Aug 16 22:17:17 in an effort to find out what all the fuss is about Aug 16 22:17:24 I am doing a build of OE Aug 16 22:17:26 ok Aug 16 22:17:38 well I needed to get it going on my new machine Aug 16 22:39:10 Crofton: which fuss ? Aug 16 22:39:32 :) Aug 16 22:39:49 there was some chatter on the lits Aug 16 22:40:10 Crofton: yes I think it should be settled now Aug 16 22:40:22 and I have a new quad core at home I needed to get going Aug 16 22:48:28 http://pastebin.com/EUZD5ApJ Aug 16 22:48:34 any thougts Aug 16 22:48:54 fails in module-init-tools-cross Aug 16 22:49:12 I ran out of disk space during a build. I've now added INHERIT += "rm_work" to local.conf, but what can I do to clean out the old stuff? Aug 16 22:50:10 rm -rf tmp? Aug 16 22:50:23 that is the easiest way ... Aug 16 22:50:44 Crofton: I've broken harddrive's that way Aug 16 22:51:16 th eoe tmp drive ... Aug 16 22:51:26 er oe tmp directory Aug 16 22:51:35 I think the drive was already somewhat old Aug 16 22:51:37 it was just funny Aug 16 22:51:45 somewhere in the middle, the drive just gave up Aug 16 22:51:48 shitton of errors Aug 16 22:51:50 explosion Aug 16 22:52:14 Crofton: hmm, but that includes all the packages too Aug 16 22:52:23 yeah Aug 16 22:52:28 less than optimal Aug 16 22:52:30 Crofton: I'd like to keep the packages and throw out the intermediate objects Aug 16 22:53:01 ahh Aug 16 22:53:02 hollisb, if you look at the tmp folder, things are fairly neatly arranged Aug 16 22:53:12 need to install static libc on build machine! Aug 16 22:53:16 the deploy folder has all your packages and stuff Aug 16 22:53:17 I rremember now Aug 16 22:53:36 aditya_1010: so I just need to rm tmp/work? Aug 16 22:54:18 hollisb: INHERIT += rm_work will nuke things out Aug 16 22:54:38 Tartarus: yes, but I didn't have that before, and filled my disk Aug 16 22:54:51 yeah, you can add it now Aug 16 22:54:55 and it'll go Aug 16 22:55:02 if you run the same command again, it'll just skip all the stuff that's already done Aug 16 22:55:39 I did add it, then ran bitbake meta-toolchain again, and it's still out of disk space Aug 16 22:56:34 he needs to get rid of the work for stuff already done Aug 16 22:57:10 tmp/work is 37G -- I can safely blow this away? Aug 16 22:59:29 Tartarus? Aug 16 23:00:07 you can only safely remove it if you know that you have no recipes which are only partially built right now Aug 16 23:00:19 otherwise you'd have to clean and rebuild those manually Aug 16 23:00:26 still not a big deal Aug 16 23:01:47 kergoth_: I think I was mid-recipe when I ran out of space Aug 16 23:02:02 kergoth_: is there no "bitbake clean old stuff" command for me? :) Aug 16 23:05:58 hi Aug 16 23:06:47 hollisb: That's what rm_work is Aug 16 23:06:51 Try bitbake -k meta-toolchain Aug 16 23:07:02 That should let things go far enough that rm_work's are kicked off Aug 16 23:07:07 http://bugs.openembedded.org/show_bug.cgi?id=5451 anybody got some pointers ? I can't figure how to pass different kernel source to that driver Aug 16 23:07:37 Tartarus: alright, trying now Aug 16 23:12:36 xf86-video-msm_git.bb pulls some headers from a kernel souce. I would like to find out where that kernel source is defined. any pointers ? Aug 16 23:14:47 khem: maybe you can give me a hint. you always my last #oe hope :> Aug 16 23:14:48 dcordes: the kernel-module class is the right way to build external kernel modules Aug 16 23:15:01 er Aug 16 23:15:05 Tartarus: .. Aug 16 23:15:12 just module.bbclass Aug 16 23:15:26 That shows where the right kernel sources are too Aug 16 23:15:38 if you have something ... odd ... to build Aug 16 23:15:48 Tartarus: xorg module != kernel module Aug 16 23:15:58 Tartarus: how is an xorg module odd ? Aug 16 23:16:26 dcordes: Anything that needs the actual kernel sources over just general linux-libc-headers exposed stuff is odd. Aug 16 23:17:16 Tartarus: ok xf86-video-msm is bleeding edge and relies on an fb kernel driver that is not mainlained yet Aug 16 23:17:18 dcordes: Now, if you have something that just needs a newer linux-libc-headers that used before, that's just a normal thing Aug 16 23:20:03 How can I use Ubuntu's qemu-arm rather than one built by OE? OE's continues to segfault sometimes. I have 'ASSUME_PROVIDED += "qemu qemu-native"' in my local.conf, but it keeps trying to build qemu. Aug 16 23:23:31 Tartarus: ok then it's odd. 'module.bbclass' can you elaborate ? Aug 16 23:31:28 03Paul Eggleton  07org.openembedded.dev * r065d098d9c 10openembedded.git/recipes/ (178 files in 173 dirs): Aug 16 23:31:28 opie: remove version 1.2.2 recipes Aug 16 23:31:28 These have probably been unbuildable for some time now, and there is no reason Aug 16 23:31:28 not to use a newer version. Aug 16 23:31:28 Signed-off-by: Paul Eggleton Aug 16 23:32:31 ...okay, weird. I interrupted bitbake during qemu's do_configure stage, but glibc's do_package stage was running in parallel (I have it set for two parallel tasks). So even though qemu wasn't built, it's still happily generating locales. Aug 16 23:35:53 Tartarus: in case of the above mentioned recipe, how can I tell bitbake to use specific kernel source for the headers ? Aug 16 23:36:16 Tartarus: I know an external (not in an oe recipe) git repository that has the headers I'm missing Aug 16 23:36:36 Tartarus: I know an external (not in an oe recipe) git repository that has the headers xf86-video-msm_git.bb is missing Aug 16 23:42:51 dcordes: external git repo of kernel sources ? Aug 17 00:10:37 | /home/balister/oe/tmp/sysroots/x86_64-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -ltinfo Aug 17 00:10:41 in alsa something Aug 17 00:10:44 ring a bell? Aug 17 00:19:24 hmm, someone is/was having a similar issue on a gumstix overo build Aug 17 00:30:55 khem, i'm seeing relocation errors building eglibc-2.11. Has anything changed in the last few days? log.do_compile: http://pastebin.com/k4D9etWP Aug 17 00:36:24 grg: hmmm not that I know of any Aug 17 00:39:02 khem, http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=0dee8eb3458f655ff7e21a898178051c521e5891 Aug 17 00:39:04 ? Aug 17 00:39:21 gdb3 makes everything bigger... Aug 17 00:40:04 grg: yeah Aug 17 00:40:05 thats it Aug 17 00:40:15 thats the source of your problem too Aug 17 00:41:43 its having issues generating .macinfo for PIC objects Aug 17 00:42:07 i wish i knew what that meant Aug 17 00:42:32 khem: yes Aug 17 00:43:48 grg: can you find out which mcount.o gets linked in into libc_pic.a Aug 17 00:44:07 grg: I see there are two compiles one with -fPIC and another without Aug 17 00:44:21 the one with -fPIC should be included in libc_pic.a Aug 17 00:44:37 there's only one in the build dir: build-mipsel-oe-linux/gmon/mcount.o Aug 17 00:44:37 thats a bug in libc if its not including the right one Aug 17 00:44:53 look for mcount.o* Aug 17 00:45:12 there should be mcount.os Aug 17 00:45:21 and thats the one which should be picked into PIC version Aug 17 00:45:30 if its picking that one then its ok Aug 17 00:45:33 yep, there's mcount.{o,os,os.d,o.d} Aug 17 00:46:11 dcordes: then you should use that as your kernel I guess Aug 17 00:46:31 dcordes: I dont think it will work with other versions of kernel at runtime othereise Aug 17 00:46:35 khem: so I can assume currently the recipe is grabbing the headers from my virtual/kernel ? Aug 17 00:46:49 dcordes: yes Aug 17 00:46:57 unless its some kernel module Aug 17 00:47:05 which has view of kernel sources too Aug 17 00:47:07 nono xorg module Aug 17 00:47:11 yes Aug 17 00:47:23 that is picking linux-libc-headers Aug 17 00:47:40 not good Aug 17 00:47:52 it must pick at least the kernel for my device Aug 17 00:48:11 dcordes: you can also write a recipe for linux=libc-headers that picks the kernel sources you want Aug 17 00:48:30 khem: where can I find an example ? Aug 17 00:48:36 dcordes: usually it kernel interfaces to userspace are solid Aug 17 00:48:39 so they work Aug 17 00:48:45 with older kernel headers Aug 17 00:48:59 but sometimes you need to compile apps which need bleeding edge kernel headers Aug 17 00:49:02 khem: check the above bug I linked to Aug 17 00:49:13 khem: it is the requirements to msm_fb framebuffer kernel driver that are critical Aug 17 00:49:24 brb Aug 17 00:49:35 http://bugs.openembedded.org/show_bug.cgi?id=5451 Aug 17 00:50:11 MSMFB_RESUME_SW_REFRESHER MDP_FB_PAGE_PROTECTION_WRITETHROUGHCACHE Aug 17 00:55:27 khem, libc_pic.a contains mcount.os Aug 17 01:02:08 damnit. bitbake removes the _append/_prepend variable flags when the override is collapsed Aug 17 01:02:11 * kergoth grumbles Aug 17 01:02:49 that's going to completely screw this up **** ENDING LOGGING AT Tue Aug 17 02:59:57 2010