**** BEGIN LOGGING AT Fri Nov 05 02:59:58 2010 Nov 05 03:01:12 a mystery: Nov 05 03:01:51 i'm building chromium, and it specifies a bunch of slices of the svn repo to download. you checkout those slices from SVN, tar them up individually and put them in sources/downloads, then untar them into your work directory Nov 05 03:02:16 one of them consistently fails (bunzip2 bails out, pipe gets broken, etc.) on the untar into my work directory Nov 05 03:02:27 yet it works perfectly fine when i do it from the command line Nov 05 03:02:30 what could that be? Nov 05 03:25:31 is anyone else getting build errors on angstrom-version with current head of oe.dev? Nov 05 03:25:59 someone else was yesterday, i dont think we solved their problem though Nov 05 03:26:29 http://build.sakoman.com/public/logs/task/186111.txt Nov 05 03:27:16 you lucky dog (panda) :P Nov 05 03:27:24 fails on 2 of my build machines, one 32 bit ubuntu, the other 64 bit ubuntu Nov 05 03:27:39 do_install is calling do_install ? Nov 05 03:27:42 but not others? or are those your only 2 machines? Nov 05 03:28:03 i think it creates the logfile outside of the task Nov 05 03:28:18 those are the two machines I've tried Nov 05 03:28:29 idk though. what version of bitbake and python are you using? Nov 05 03:28:49 max recursion depth sounds scary, like mutual recursion or something like that Nov 05 03:28:51 wow, -c clean of angstrom-version fails even more spectacularly! Nov 05 03:29:53 http://pastebin.com/JzGqjhqw Nov 05 03:30:20 BitBake Build Tool Core version 1.10.0, bitbake version 1.10.0 Nov 05 03:30:46 Python 2.6.5 Nov 05 03:31:20 It is likely a commit from sometime in the past 24 hours that broke things Nov 05 03:31:55 A pre-pull buils passed, post pull failed Nov 05 03:33:39 hmm Nov 05 03:34:07 sakoman: try a bisect? Nov 05 03:34:43 kergoth_: I'm reading through the log for the past day to see if there are any likely culprits Nov 05 03:39:12 kergoth_, mrj10: here's the culprit: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=openembedded.git;a=commitdiff;h=a3d8c448c2bb3ea2c9a92bdb442fb4b39144bae0 Nov 05 03:39:30 weird. Nov 05 03:39:30 reverting that seems to fix the issue Nov 05 03:39:41 haven't heard of any problems with that until now Nov 05 03:40:08 only seems to fail on angstrom-version -- many other recipes build just fine Nov 05 03:40:29 makes no sense, that runs against the oe dir, not the recipe Nov 05 03:40:30 hmm Nov 05 03:40:38 * kergoth_ looks further Nov 05 03:41:07 * sakoman has no clue what that does, he's just happy to get back to work :-) Nov 05 03:41:36 kergoth: that recipe prints out info about the OE branch and revision to a file in the device rootfs Nov 05 03:42:09 using the METADATA_* variables Nov 05 03:42:58 why it's failing for sakoman i don't know Nov 05 03:43:20 do you have an old version of git or something that doesn't support "git rev-parse --verify --short HEAD"? Nov 05 03:43:50 git version 1.7.0.4 Nov 05 03:44:20 hmm.. does that command yield something meaningful when in your openembedded directory? Nov 05 03:44:29 for me i get a 7-character (short) hash Nov 05 03:44:38 with git 1.6.3.3 Nov 05 03:44:55 I get the same Nov 05 03:45:38 what about "git symbolic-ref HEAD" Nov 05 03:46:11 I get refs/heads/sakoman Nov 05 03:46:37 strange Nov 05 03:46:42 that sounds kosher Nov 05 03:46:53 what about clearing your BB cache, have you done that since you pulled? Nov 05 03:47:00 (run 'touch' on your local.conf) Nov 05 03:47:15 (then re-run bitbake angstrom-install) Nov 05 03:47:54 I tried it with a couple of different machines, so that is essentially the same thing, right? Nov 05 03:48:12 i.e. a conf file was touched Nov 05 03:48:51 btw the recipe that breaks is angstrom-version, not angstrom-install Nov 05 03:48:56 yeah Nov 05 03:48:59 sorry about that Nov 05 03:49:25 maybe i'm dense, but i don't see why the recipe exports METADATA_REVISION, METADATA_BRANCH, and TARGET_SYS Nov 05 03:49:33 shouldn't it be importing them? :P Nov 05 03:49:46 no clue! Nov 05 03:50:09 reverting the above mentioned commit fixes the build on both of the machines Nov 05 03:51:48 oh, no, it should export them so that the install and echo commands can see those values Nov 05 03:52:40 just for grins, can you try reapplying the commit and running "touch /path/to/local.conf && bitbake angstrom-install -c clean && bitbake angstrom-install"? Nov 05 03:55:46 no, it doesn't need to export them Nov 05 03:55:54 ${} variables are expanded by bitbake before emission Nov 05 03:55:56 not by the shell Nov 05 03:56:35 ah Nov 05 03:57:14 mrj10: OK will run that test Nov 05 03:58:05 that commit changes so few things :P Nov 05 03:59:10 its odd, it 1) switches to using the oe.process bits to spawn the process, and 2) makes it use rev-parse instead of show-ref .. i can't see how either of those would cause this Nov 05 03:59:12 very strange Nov 05 04:00:13 yeah Nov 05 04:00:15 hmm Nov 05 04:00:19 oh, shit, i see it Nov 05 04:00:25 does oe.process.run() return the same thing as os.popen()? Nov 05 04:00:31 it does Nov 05 04:00:38 the issue is the use of oe_run rather than oe.process.run Nov 05 04:00:47 oe_run emits all exported vars into the subprocess environment Nov 05 04:00:56 including METADATA_REVISION :) Nov 05 04:02:00 ah! good call. i did look at oe_run, but didnt go far enough to figure out that the environment passed to oe.process.run included all the OE internal stuff Nov 05 04:02:07 so, that recipe shouldn't be exporting those variables, but we could always make it use oe.process.run directly with only PATH in the env Nov 05 04:02:18 either one would solve this particular case Nov 05 04:03:49 yeah, or just pass through the environment passed to bitbake instead of that + everything generated within bitbake+OE Nov 05 04:04:02 probably both, no? Nov 05 04:05:16 http://pastebin.com/ajA2pRwU Nov 05 04:05:20 hmm, perhaps. i'm not sure thats ideal either though. Nov 05 04:06:07 fails again with that commit re-instated Nov 05 04:06:24 ok, yeah, that's expected now that i know the problem Nov 05 04:06:42 before kergoth_ found that, i thought it might just be a random cache corruption problem, i've had a few of those and it's easy to test that Nov 05 04:06:59 i'd say kill the exports from angstrom-version for now, its definitely unnecessary, confusing, and will take care of it until we determine the best general fix Nov 05 04:07:05 * kergoth_ isn't likely to mess with it tonight Nov 05 04:07:11 (unless someone else wants to :) Nov 05 04:07:18 now that the commit is reapplied, go into openembedded/recipes/angstrom/angstrom-version.bb and remove the 3 lines that begin with "export " Nov 05 04:07:21 and try again Nov 05 04:07:25 see if that fixes it (it should) Nov 05 04:08:04 OK, will do Nov 05 04:09:49 OK, build completes successfully now Nov 05 04:09:59 03Chris Larson  07master * rfe0b4102c3 10openembedded.git/recipes/angstrom/angstrom-version.bb: Nov 05 04:09:59 angstrom-version: drop unnecessary exports Nov 05 04:09:59 Signed-off-by: Chris Larson Nov 05 04:10:14 that was creepy.. Nov 05 04:10:23 indeed :-) Nov 05 04:11:05 angstrom-version has been a troublesome recipe for some time now Nov 05 04:11:22 hey, someone should forward-port all the TI modules to the ti-omap 2.6.36 kernel Nov 05 04:11:41 Nov 05 04:12:42 :-) Nov 05 06:29:17 gm Nov 05 06:30:30 ls Nov 05 06:31:19 mrj10 Nov 05 06:31:29 (gm) Nov 05 06:37:28 :-) Nov 05 06:39:07 morning eFfeM_work Nov 05 06:39:37 hi ka6sox, good proposal (but didn't read the reactions yet ;-) ) Nov 05 06:40:22 thanks, I haven't seen any yet! Nov 05 06:59:45 ka6sox do you have any idea where this is gone to: http://www.openembedded.org/snapshots/ Nov 05 07:00:11 it does not exist any more, it used to have our mtn snapshots Nov 05 07:01:09 they are probably still on Amethyst Nov 05 07:01:29 I'll look for them tommorrow. Nov 05 07:02:01 ok, np Nov 05 07:02:05 let me add that to redmine so they can be found. Nov 05 07:02:18 ok, tnx Nov 05 07:12:41 03Martin Jansa  07master * r75adfed2b9 10openembedded.git/ (5 files in 3 dirs): Nov 05 07:12:41 xorg: upgrade libxi 1.3.2->1.4.0, xproto 7.0.18->7.0.19 Nov 05 07:12:41 Signed-off-by: Martin Jansa Nov 05 07:16:50 khem: I applied patch to eglibc-2.11 aswell, but forgot to change comment Nov 05 07:24:59 donation link is fixed. Nov 05 07:26:36 03Khem Raj  07master * r426fec50b3 10openembedded.git/classes/meta.bbclass: Nov 05 07:26:36 meta.bbclass: Exclude meta recipes from world builds Nov 05 07:26:36 Signed-off-by: Khem Raj Nov 05 07:26:36 Acked-by: Chris Larson Nov 05 07:26:47 03Khem Raj  07master * r10e1e4d039 10openembedded.git/recipes/tasks/ (3 files): Nov 05 07:26:47 task-arago-toolchain: Exclude from World build Nov 05 07:26:47 Signed-off-by: Khem Raj Nov 05 07:26:47 Signed-off-by: Denys Dmytriyenko Nov 05 07:43:46 * stefan_schmidt wonders if everybody has kicked his weekend appointsments to help with the patchwork weekend :) Nov 05 07:43:47 hi all Nov 05 07:44:44 hi stefan_schmidt which weekend are you planning on doing this? Nov 05 07:45:01 ka6sox: this :) Nov 05 07:45:24 oh, then I won't start trying to move patchwork this weekend then. Nov 05 07:45:28 ka6sox: but we are working on making it a monthly social event :) Nov 05 07:45:38 ka6sox: ah, yes, that would be good Nov 05 07:45:48 ka6sox: did not know it was on the admin agenda Nov 05 07:46:02 would be great if you could leave it alone until monday Nov 05 07:46:04 stefan_schmidt, ya, it got added to my list this morning Nov 05 07:46:15 np, I can wait. Nov 05 07:46:20 thanks Nov 05 07:47:41 do you need the old monotone repos? Nov 05 07:48:38 ka6sox: not for the patchwork stuff. I don't know if we still need them at all. Nov 05 07:48:39 hmm Nov 05 07:49:03 maybe having they around as kind of OE history would not be a good idea Nov 05 07:49:10 no hard feelings on this thought Nov 05 07:49:18 ka6sox: maybe ask on the ml Nov 05 07:49:23 kk Nov 05 07:52:05 I remember when we transitioned from mtn to git...I didn't see how we could get any of the old history. Nov 05 07:53:55 ka6sox: hmm, maybe a language problem as I'm not a native english speaker. I meant the history of the project as a whole not the history of the SCM Nov 05 07:54:12 ah.... Nov 05 07:54:15 got it. Nov 05 07:55:43 03Martin Jansa  07master * rb6d7a41d8a 10openembedded.git/recipes/shr/shr-version.bb: Nov 05 07:55:43 shr-version don't export METADATA_BRANCH and METADATA_REVISION Nov 05 07:55:43 * otherwise you'll get Nov 05 07:55:43 NOTE: :maximum recursion depth exceeded Nov 05 07:55:43 while calling a Python object while evaluating: ${@base_get_scm_branch(d)} Nov 05 07:55:43 Signed-off-by: Martin Jansa Nov 05 08:59:40 mornin Nov 05 09:28:44 good morning Nov 05 09:36:52 03Frans Meulenbroeks  07master * rd35078be3c 10openembedded.git/contrib/testing/testscript.sh: Nov 05 09:36:52 contrib/testing/testscript.sh: created Nov 05 09:36:52 This is an example script to run tests for the testing branch. Nov 05 09:36:52 See also http://wiki.openembedded.net/index.php/TestingScript Nov 05 09:36:52 Feel free to improve! Nov 05 09:36:53 Signed-off-by: Frans Meulenbroeks Nov 05 09:37:55 as requested :-) Nov 05 09:41:16 hi eFfeM_work Nov 05 09:42:09 hi ant_work (and ericben and Jin^eLD and all who came in in the last 3 hrs :-) ) Nov 05 09:43:30 JaMa: ping Nov 05 09:43:55 need some small advise on a libx11 patch Nov 05 09:47:33 03Alex Ferguson  07org.openembedded.dev * r7026fff476 10openembedded.git/recipes/gtk+/ (gtk+-1.2-1.2.10/small-filesel.patch gtk+-1.2_1.2.10.bb): (log message trimmed) Nov 05 09:47:33 gtk+-1.2: Patch gtkfilesel for smaller screens. Nov 05 09:47:33 * Added small-filesel.patch, which is only for jlime, but is Nov 05 09:47:33 possibly useful for other devices as well, and which modifies Nov 05 09:47:33 gtkfilesel to fit in screens of 320x240 and larger resolutions. Nov 05 09:47:33 * Modified gtk+-1.2-1.2.10 recipe for above patch. Nov 05 09:47:34 Signed-off-by: Alex Ferguson Nov 05 09:47:35 03Alex Ferguson  07org.openembedded.dev * r4ec3e12938 10openembedded.git/recipes/matchbox-desktop/matchbox-desktop-0.9.1/layout.patch: Nov 05 09:47:35 matchbox-desktop: Modify layout.patch for highlight colors. Nov 05 09:47:35 Modified layout.patch with a modified highlight color, which Nov 05 09:47:36 is by default white. White highlight does not go well with Nov 05 09:47:36 white text, so the highlight is now (nearly) black. Nov 05 09:47:37 Signed-off-by: Alex Ferguson Nov 05 09:47:37 Signed-off-by: Kristoffer Ericson Nov 05 09:47:38 03Alex Ferguson  07org.openembedded.dev * r3097f4afc1 10openembedded.git/recipes/matchbox-common/ (2 files in 2 dirs): (log message trimmed) Nov 05 09:47:39 matchbox-common: Add jlime-specific modifications. Nov 05 09:47:50 always be preferred over git versions where available. Nov 05 09:47:50 Signed-off-by: Alex Ferguson Nov 05 09:47:54 Signed-off-by: Kristoffer Ericson Nov 05 09:47:54 03Alex Ferguson  07org.openembedded.dev * r469fa13d39 10openembedded.git/conf/machine/include/tune-mips32.inc: (log message trimmed) Nov 05 09:47:54 tune-mips32.inc: Add missing definitions. Nov 05 09:47:54 I added the FEED_ARCH and BASE_PACKAGE_ARCH definitions which Nov 05 09:47:54 are assigned the value of TARGET_ARCH (which is defined in Nov 05 09:47:54 the individual machine files). I used the TARGET_ARCH variable Nov 05 09:47:55 and not a static value since the value can be either "mipsel" Nov 05 09:47:55 (as in ben-nanonote) or "mips" (as in qemumips). Nov 05 09:47:57 zecke: hi, do you have examples on how to run qttracereply ? Nov 05 09:54:56 eFfeM_work: pong Nov 05 09:57:15 JaMa: as you are the libx11 wiz/maintainer: i have a small (one-line) patch for libx11 which I am testing now for 1.3.2, not too sure if I should add the patch to libx11-1.3.2.bb or to the inc Nov 05 09:57:45 actually configure thinks nios2-linux is an os2 system, as it matches *os2* so added an extra case Nov 05 09:59:24 eFfeM_work: if you can prepare patch for all versions and put it with same name to libx11-${PV} then feel free to add it to .inc Nov 05 10:00:49 JaMa: I see the other versions duplicate the patches Nov 05 10:00:54 eFfeM_work: and please report it upstream, if they apply it to git, then you should put it to .bb Nov 05 10:00:56 actually i see that they are probalby not used Nov 05 10:01:24 eFfeM_work: as it won't be needed in next snapshot and I would have to move it from .inc to .bb then Nov 05 10:01:28 let me check Nov 05 10:01:45 eFfeM_work: which patch is not used? Nov 05 10:02:13 no, it is ok, mistyped myself Nov 05 10:02:54 i'll add to the recipe and try to get it upstream, although I don't think they will accept it as it is Nov 05 10:03:41 this is the patch: http://www.pastebin.ca/1982622 Nov 05 10:04:05 guess the real fix is to change the *os2* pattern, but no idea how to do that reliably Nov 05 10:04:22 btw where is upstream for this? Nov 05 10:04:41 http://xorg.freedesktop.org Nov 05 10:29:35 zecke: forget it, using qttracereplay instead of reply seems to be the right thing to do :-D Nov 05 10:32:55 good morning Nov 05 10:42:03 eFfeM_work: hmm why didn't you fill it as bug with patch in xorg bugtracker? Nov 05 10:42:25 JaMa: they make things too hard, you need to sign up, create a login etc Nov 05 10:43:02 too much work Nov 05 10:43:48 actually not sure whether the email will get thru, it is sent to the moderator, but I do not feel like sigining up for yet another ML just to file a report Nov 05 10:44:05 but if you have a bugzilla account with them, feel free to enter it there Nov 05 10:46:27 I am trying to get a minimal image to boot in qemu. What is the easiest to do? DISTRO=angstrom minimal-image ?? Nov 05 10:55:49 hej, any u-boot'er here can tell me if CONFIG_AUTOBOOT_STOP_STR is patched by oe (or already has some default value), since I can't find anything by grepping ;) Nov 05 12:26:37 03Koen Kooi  07org.openembedded.dev * r1d5c108b01 10openembedded.git/recipes/glibc/ (glibc-2.9/neon-memcpy.patch glibc_2.9.bb): Nov 05 12:26:37 glibc 2.9: add experimental, angstrom only memcpy patch Nov 05 12:26:37 * Angstrom only till it receives further testing Nov 05 12:26:37 * Apart from the PR bump, this has no impact at all on non-angstrom distros Nov 05 12:26:37 Signed-off-by: Koen Kooi Nov 05 12:26:38 Acked-by: Philip Balister Nov 05 12:48:39 'j #fpc Nov 05 14:14:36 is there an easy way to generate the sdk with the non stripped libs inside ? Nov 05 14:15:09 PACKAGE_STRIP = "no" ? Nov 05 14:21:34 mmm installing -dbg packages should do the trick and then playing with solib-search-path in gdb should do the trick Nov 05 14:36:25 morning Nov 05 14:38:40 khem, you there? Nov 05 14:40:37 any known issues with gcc4.5 and u-boot ? Nov 05 14:42:06 don't build u-boot with gcc-4.5 .... Nov 05 14:43:07 "ok", i did build u-boot with 4.5 armv7 and have a strange issue where u-boot seems to work fine, but just doesn't start the kernel after loading it Nov 05 14:43:38 ppl at #beagle can't help me either, so I was wondering that this was maybe a gcc issue Nov 05 14:43:47 check the memory detection Nov 05 14:43:52 see if reports the right numbers Nov 05 14:43:56 how ? Nov 05 14:44:02 apparentyl there is some discussion on the u-boot list Nov 05 14:44:17 see what u-boot prints Nov 05 14:44:23 i do, sec Nov 05 14:44:42 I downloaded a gcc 4.3 toolchain from narcissus Nov 05 14:45:05 http://pastebin.com/VxsQkvPs Nov 05 14:45:20 this is how far i get Nov 05 14:47:46 mlip: Dram: 0 Bytes :) Nov 05 14:48:42 ericben: yeah, ... was missing that, maybe i should really get some other gcc Nov 05 14:49:26 mlip: try codesourcery's one Nov 05 14:50:49 where do I get it ... I would get one from narcissus right now Nov 05 14:53:44 nvm, narcissus is finished :) Nov 05 15:02:25 ericben, Crofton : thx, next time I do not consult uboot and beagle but just throw _all_ my question at oe :) would've saved me 3h Nov 05 15:11:28 well, check in #beagle first Nov 05 15:11:39 some of us are there also, I just missed the question there Nov 05 15:19:53 ericben: sorry Nov 05 15:20:29 zecke: hi Nov 05 15:20:43 do you know if trace works on qt4 embedded ? Nov 05 15:21:31 I tried and it accepts the option but doesn't create a log file Nov 05 15:21:42 03Chris Larson  07master * re58fe232ef 10openembedded.git/recipes/termcap/ (15 files in 2 dirs): Nov 05 15:21:42 termcap: add 2.0.8 with gentoo patchset Nov 05 15:21:42 No one should really be using this, but what the heck. Nov 05 15:21:42 Signed-off-by: Chris Larson Nov 05 15:22:29 ericben: were you able to use qttracereplay? sorry for my mixup Nov 05 15:23:02 zecke: not yet as I don't have X11 on the board. Do you know it -g Nov 05 15:23:08 raphicssystem trace works on qt4embedded ? Nov 05 15:24:07 zecke: I quickly tried on qt4e and it accepts the option but doesn't create a log file Nov 05 15:29:12 ericben: you need Qt/X11 to record it, e.g. on the desktop with Qt 4.7 Nov 05 15:32:58 zecke: ok so I need to configure Xorg + Qt/X11 for my target Nov 05 15:33:16 zecke: this will take some time as I have several other things in the pipe but I'll do it Nov 05 15:36:39 ericben: do you use linux on your desktop? Nov 05 15:42:04 khem: testing builddir. dropped the usage of ${B} from base.bbclass, added it to the dirs flags in autotools.bbclass instead, since we know its supported by those specifically, and set B in local.conf, testing a build now Nov 05 15:42:07 * kergoth crosses fingers Nov 05 15:43:19 khem, .... Nov 05 15:48:36 kergoth: cool Nov 05 15:48:51 that was quick Nov 05 15:48:52 died in quilt-native Nov 05 15:48:53 hehe Nov 05 15:48:57 ah Nov 05 15:49:05 quilt-native is a beasr Nov 05 15:49:05 * kergoth disables and continues Nov 05 15:49:26 Crofton: I've seen you acked a memcpy patch today. That reminded me to that (still unapplied) kernel patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2009-November/003860.html Nov 05 15:49:41 I see that code didn't change in 2.6.36 Nov 05 15:50:07 once I experimented on Zaurus, but the nand-scanning did not show any benefit Nov 05 15:50:08 well that memcpy patch needs testing I would say Nov 05 15:50:23 yeah Nov 05 15:50:23 I can retry Nov 05 15:50:55 we figured the NEON one is OK, but we'll see if it blows anything up before making it apply to all distros Nov 05 15:51:12 hmm. If B is relative to S *and* using srctree, it needs to be a different value than use of B relative to WORKDIR, since placing it in workdir already captures host_sys, etc Nov 05 15:51:24 yes I would suugest to test it on armv4t or armv5te Nov 05 15:51:30 B relative to S with srctree really should capture package_arch, host_os, distro, etc Nov 05 15:51:49 course, B could stay relative to WORKDIR even when using srctree, just couldn't use git clean to -c clean :) Nov 05 15:51:52 kergoth: relative to S you mean inside S ? Nov 05 15:52:08 yeah, e.g. obj.${HOST_SYS} or whatever Nov 05 15:52:22 easy to inspect if its right within S for srctree, not buried in tmpdir Nov 05 15:52:23 hmm we should move B parallel to S Nov 05 15:52:26 I think Nov 05 15:52:38 without srctree, sure Nov 05 15:53:26 why not with srctree too Nov 05 15:54:05 because with srctree, S is outside of workdir, outside of oe's control. i sure wouldn't want it throwing files in ${S}/../, cluttering up my drive Nov 05 15:54:35 if i have ~/nano/.git, i don't want ~/obj.foo to be nano's build files :) Nov 05 15:54:50 zecke: yes I have linux on the desktop Nov 05 16:00:27 khem, I did a fresh build for armv4 machine with eglibc 2.12 and the resulting binaries doesnt run. So I suspect that it got "thumbed". looking at a objdump of busybox looks like thumb (although my arm assembler is abit rusty( Nov 05 16:02:31 kristoffer: check for 'bx' instruction - its armv4t Nov 05 16:03:46 hrw, alright, then its thumbed, alot of mov bx,lr Nov 05 16:03:52 doh Nov 05 16:03:57 bx I mean Nov 05 16:03:59 not move Nov 05 16:04:25 kristoffer: try eglibc 2.11 Nov 05 16:05:55 hrw, roger will do Nov 05 16:19:56 hi does someone knows a bit ekiga, I've the following compilation error and no answer in #ekiga: sysroots/armv6-novfp-oe-linux-gnueabi/usr/include/opal/opal/connection.h:1772:5: error: 'virtual ptlib_virtual_function_changed_or_removed****** OpalConnection::IsConnectionOnHold()' is private (http://git.gnome.org/browse/ekiga/commit/?id=e446d985c10103f38be08fb133885a992abcd0fe doesn't fix the error) Nov 05 16:20:37 maybe I should use linphonec but it has some audio issues on htcdream, maybe because of the bad alsa driver Nov 05 16:21:30 else there is sflphone that seem good but no recipes and it doesn't compile under the devshell Nov 05 16:22:37 I really need to find a better way to manage my various OE and bitbake topic branches Nov 05 16:23:00 many aren't ready and won't be to go upstream anytime soon, at the very least have to wait for the release, so i keep having to merge them all together to do integration testing Nov 05 16:23:05 maybe topgit would help Nov 05 16:23:58 hmm Nov 05 16:24:14 kristoffer: AFAIK 2.12 worked ok on armv4t Nov 05 16:24:28 kristoffer: which distro/machine combo are you using ? Nov 05 16:24:36 I mean target Nov 05 16:25:48 Hmm, it would be kind of nice to have a pu/next branch for doing integration testing of upcoming developments, before they hit master, the way git and the kernel do -- or even a "next" layer with the yocto model Nov 05 16:29:15 kergoth: whats pu ? Nov 05 16:29:38 * kergoth tries to find a link Nov 05 16:29:42 next layer hmmm Nov 05 16:30:01 http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html Nov 05 16:30:32 next is intended as a testing branch for topics being tested for stability for master. Nov 05 16:30:32 There is a fourth official branch that is used slightly differently: Nov 05 16:30:32 pu (proposed updates) is an integration branch for things that are not quite ready for inclusion yet (see "Integration Branches" below). Nov 05 16:30:32 next is intended as a testing branch for topics being tested for stability for master. Nov 05 16:30:32 There is a fourth official branch that is used slightly differently: Nov 05 16:30:32 pu (proposed updates) is an integration branch for things that are not quite ready for inclusion yet (see "Integration Branches" below). Nov 05 16:30:33 next is intended as a testing branch for topics being tested for stability for master. Nov 05 16:30:33 There is a fourth official branch that is used slightly differently: Nov 05 16:30:34 pu (proposed updates) is an integration branch for things that are not quite ready for inclusion yet (see "Integration Branches" below). Nov 05 16:30:34 'next' is for stability testing, "pu" is proposed updates, for integration testing of things that aren't quite ready yet Nov 05 16:30:35 erk Nov 05 16:30:38 stupid irc client Nov 05 16:30:40 sorry about that Nov 05 16:31:47 khem: which memcpy patch did you say is worth to try? glibc or kernel one? Nov 05 16:32:39 nm, glibc seems neno only Nov 05 16:33:18 I'll repatch the armv5te kernel Nov 05 16:43:48 khem, I know it works on armv4t since it got thumb support Nov 05 16:43:50 armv4 doesnt Nov 05 16:44:08 khem, using jlime-2010.1 Nov 05 16:47:11 khem, the fix for armv4 thumb-workaround patch is available on 2.12 but Im assuming something is missing to make it completely thumb-free Nov 05 16:47:16 he I've re-read RP email but am still full of doubts... Nov 05 16:50:40 ant_work: i don't see it being any worse than poky/oe was, its just an umbrella over poky Nov 05 16:50:46 Poky is the buildsystem of Yocto Project, so now what to do with OE? Nov 05 16:50:57 that's underlying story Nov 05 16:51:31 either we continue as is, but sync with poky more often, or we change to a more layered model and continue to sync with poky, or we go to a layered model based on poky and maintain the extra layers. those are the 3 options i see Nov 05 16:53:09 well, nothing more than an overlay then Nov 05 16:53:41 (I have nothing against) Nov 05 16:53:53 the contents of poky are very limited Nov 05 16:53:59 its not much different than it is now, just the bits poky already has would be the very minimal core Nov 05 16:54:17 assuming the 3rd of the above options, anyway Nov 05 16:55:17 and poky's commit policy is even more strict then OE one so core will get less breakups Nov 05 16:55:31 right Nov 05 16:55:38 I see, we can forget about core then Nov 05 16:55:48 e.g. toolchain Nov 05 16:55:52 no Nov 05 16:55:54 well, not necessarily Nov 05 16:55:59 you can override it in overlay Nov 05 16:56:04 sure Nov 05 16:56:06 or we could just be poky developers for that. Nov 05 16:56:12 I meant that ;) Nov 05 16:56:16 poky is still open source, just with a tighter policy Nov 05 16:56:18 we can not depend blindly on poky Nov 05 16:56:29 I don't see that it would be blind Nov 05 16:56:32 if it is not a two way street, it will not work Nov 05 16:56:37 er Nov 05 16:56:46 Imeant blindly depend on the yocto project Nov 05 16:57:01 I don't either Nov 05 16:57:09 Crofton|work: sorry, but who has to earn finally? Nov 05 16:57:24 I think it could work, those of us who hack on the core would do the same, just RP would pull those into poky Nov 05 16:57:26 but, we need to make sure the Yocto project knows we need input Nov 05 16:57:30 or a maintainer would Nov 05 16:57:48 gotta run some errnds Nov 05 16:57:54 I see several steps Nov 05 16:57:59 is not easy thema Nov 05 16:58:13 and the first one is we need a voting proposal for the eV members to vote on Nov 05 16:58:26 saying we would like to work with the yocto project Nov 05 16:58:45 people need to be on board Nov 05 16:58:56 and have a sense this is a community decision Nov 05 16:58:58 * ant_work hugs khem for the outstanding toolchain work Nov 05 16:59:11 and, I need to run siome errnads Nov 05 16:59:53 * ant_work did not forget Tartarus and co. too ;) Nov 05 16:59:58 yeah, we need to vote on such a major change, absolutely. we don't necessarily have to base upon them, but it seems like a good approach to retain the best of both worlds, as long as we become active poky developers as well Nov 05 17:00:50 I guess they'll have nothing against picking some of our patches Nov 05 17:01:35 I think OE has more devs/testers than them...well, they are payed ;) Nov 05 17:01:50 in the email, it sounded like there'd be no opposition to some OE people being people he pulls from, or even becoming maintainers Nov 05 17:01:58 * kergoth shrugs Nov 05 17:02:22 I maintained Poky, then maintained contrib branches Nov 05 17:02:33 Richard is open for pulling changes Nov 05 17:03:15 I'm not too worried, whichever approach we take will be okay, but if we choose to replace the core with them, it would reduce the syncing effort drastically on both their and our part Nov 05 17:04:22 one thing that bugs me about poky is the repository layout. i think the layers should be different git repositories with git-submodule or something rather than one giant repo Nov 05 17:04:25 heh Nov 05 17:05:28 I'm not too convinced too about the specific metadata reordering Nov 05 17:06:03 but hey, you get used after a while Nov 05 17:06:11 i don't see how basing on them would be any different than breaking it up ourselves. either way there'll be core of the most important things in a core layer Nov 05 17:06:21 right Nov 05 17:06:52 I'm dubious about the classes Nov 05 17:06:58 OE has many Nov 05 17:07:36 true, if we base on them the core ones would be there, and our others would be in a main oe layer, rather than all classes in one Nov 05 17:07:36 are those sync'ed nowadas? Nov 05 17:07:57 ah, I see Nov 05 17:07:59 dealing with class issues with many layers where there isn't a common core is a nightmare Nov 05 17:08:18 I bet Nov 05 17:08:18 you can't pick and choose overlays from different projects and actually expect to be able to combine them in a single build :( Nov 05 17:08:27 would be lovely to be able to do so Nov 05 17:09:51 huh, surprisingly few breakages in a task-boot using separate objdir for all autotools recipes (with some individually opting out) Nov 05 17:10:52 iirc in Gentoo overlays are only for packages, not for classes Nov 05 17:11:19 so for them its a nonissue, they have a core that's common to all Nov 05 17:11:49 yes, that's the profile Nov 05 17:30:55 bbl Nov 05 17:31:00 nn Nov 05 17:38:25 hi ka6sox Nov 05 17:38:37 effem,likewise: do you guys lack present continuous tense in dutch? Nov 05 17:39:42 hiya woglinde_ bbiab..heading into work. Nov 05 17:54:59 he zecke Nov 05 17:55:33 03Chris Larson  07master * rd4c084b2e5 10openembedded.git/bin/sed: Nov 05 17:55:33 bin/sed: Fix arg saving thinko Nov 05 17:55:33 Signed-off-by: Chris Larson Nov 05 18:10:20 I'm trying to understand debug symbols and file sizes Nov 05 18:10:34 if I build an application with -g, the unstripped size is 28MB Nov 05 18:10:44 Right Nov 05 18:10:57 however, when I do a build with PACKAGE_STRIP = "no", the binary size is only 5MB Nov 05 18:11:02 the stripped binary size is ~4MB Nov 05 18:11:21 the 5MB binary appears to have all the symbols (at least they show up in oprofile) Nov 05 18:11:48 so I'm wondering how I manually get 5MB version Nov 05 18:12:19 btw, with the gdb3 option, gcc produces a 128MB binary! Nov 05 18:12:51 yes, -ggdb3 is huge Nov 05 18:13:37 hm Nov 05 18:14:24 So, when P_S = "no", how big are the files in ${S} ? Nov 05 18:14:33 Are they 28mb or 5mb? Nov 05 18:15:10 28MB Nov 05 18:15:24 Tartarus: I'm thinking object copy is still run (package.bbclass) Nov 05 18:15:50 Yeah Nov 05 18:16:27 Er, wait Nov 05 18:16:44 I wonder if the makefile's install rule is biting you Nov 05 18:17:13 iirc we pass in something to keep install -s from stripping Nov 05 18:17:35 But if the makefiles try to be too smart, we might not be getting all of the right magic in Nov 05 18:19:19 Tartarus: OE seems to be doing the right thing, I'm just trying to figure out how do manually for iterative development Nov 05 18:19:35 Tartarus: so I can handle a 5MB binary vs a 28MB Nov 05 18:20:47 Well, that's what I mean. If you're getting 28 when built Nov 05 18:20:49 But 5 into the package Nov 05 18:20:55 IC Nov 05 18:20:56 Something in the makefiles is outsmarting us Nov 05 18:21:03 And stripping some stuff anyhow Nov 05 18:21:06 Not everything, of course Nov 05 18:21:09 But some stuff Nov 05 18:21:13 nod Nov 05 18:40:51 cbrake: make rules dont strip binaries Nov 05 18:40:58 its OE rules that will do it Nov 05 18:41:15 so thats why it gets stripped when you deploy/package it but not when you build it manually Nov 05 18:41:23 in the workdir Nov 05 18:41:28 that could be whats happening Nov 05 18:48:30 khem: that fits Nov 05 18:48:59 ok Nov 05 18:49:03 * cbrake is still walking trough the OE magic in package.bbclass (I assume) Nov 05 18:49:15 OE has many magic tricks Nov 05 18:49:25 I wish my son understood it Nov 05 18:49:33 he would be so impressed Nov 05 18:52:16 khem hehe later Nov 05 18:52:29 give him some time Nov 05 18:52:57 I was wrong, the binary in ${S} is 5MB Nov 05 18:55:16 there is no -g in TARGET_CFLAGS Nov 05 18:57:10 khem, got any good pointers of finding where the thumb code gets implemented. Ive looked through 2.12 and cant see anything weird (it adjusts if arch isnt suppose to support thumb) Nov 05 18:59:17 yep, that's it, remove -g, and now I get 5MB binaries in my other workspace. So apparently, a default gcc compile puts symbols in the binary, even with -g? Nov 05 19:03:10 * without -g Nov 05 19:07:24 kristoffer: whats the error you get Nov 05 19:07:27 and whats your machien Nov 05 19:09:04 khem, jornada7xx(armv4), eglibc 2.12, kernel panic at startup, when running through busybox binary I see thumb code (bx). Nov 05 19:09:28 khem, I think it might have todo with gcc, since I know filip used 4.2.2, and i now pulled 4.5 Nov 05 19:09:34 kristoffer: hmmm and whats your compiler Nov 05 19:09:47 ok you should use 4.4+ in OE Nov 05 19:09:59 otherwise EABI for armv4 wont work Nov 05 19:10:25 4.2.2 is certainly a problem Nov 05 19:10:26 khem, Im currently testing to fix jornada7xx to preferred 4.2.2, just to test it. If it works then its GCC (4.5) otherwise its something else Nov 05 19:10:37 use gcc 4.5 Nov 05 19:10:42 you will be happier Nov 05 19:11:17 alright, even though 4.2.2 seems to have worked for filip? What else could it be then?.. eglibc 2.12 worked fine for him Nov 05 19:11:43 kristoffer: well there is a bx avoid path then gcc should know Nov 05 19:11:50 and tame linker to behave Nov 05 19:11:58 I did that for gcc 4.4 and 4.5 Nov 05 19:12:01 not for 4.2 Nov 05 19:12:19 so I have no answer why it worked for filip using 4.2 Nov 05 19:12:45 khem, hmm oki. I did a quick find | xargs grep bx inside the arm/ folder and looking through those it seems like youve have ifdefd all the places Nov 05 19:13:09 just at a loss where to start looking really. Nov 05 19:13:41 khem, doh, filip used 4.4.2 not 4.2.2 Nov 05 19:13:53 so Ill take a try at 4.4.2 and see what falls down Nov 05 19:13:56 well there you go Nov 05 19:14:09 * khem stop easting the sanity pill Nov 05 19:14:26 kristoffer: as I said use 4.5 first Nov 05 19:14:38 you will be much better supported if you use 4.5 Nov 05 19:15:57 khem, alright, but then I need an plan of approach :) assuming eglibc is alright (atleast worked for other people), gcc 4.5 you said is patched and fixed.. what next? binutils? Nov 05 19:16:51 kristoffer: just use DISTRO=minimal Nov 05 19:17:03 and it will all be taken care of Nov 05 19:17:14 or if you have your own distro Nov 05 19:17:23 then include sane-toolchain.inc Nov 05 19:17:26 in it Nov 05 19:17:43 khem, already doing that. jlime-2010.1.conf with sane-toolchain.inc included Nov 05 19:18:44 it pulls gcc 4.5 + eglibc 2.12 and the resulting binaries include thumb code. which makes my kernel go snappy Nov 05 19:20:49 khem, do you want a copy of the dump file (arm-objdump busybox binary)? Nov 05 19:22:48 kristoffer: again so it fails with 4.5 is that what you are saying ? Nov 05 19:25:19 khem, in short yes. It worked for filip with gcc 4.4.2 + eglibc 2.12, for me with gcc 4.5 + eglibc 2.12 it doesnt. Nov 05 19:25:26 did u rebuild everything with 4.5 ? Nov 05 19:25:36 hmm thats a problem we need to fix then Nov 05 19:25:58 I have only tried with armv4t Nov 05 19:26:10 as I dont have any armv4 devices Nov 05 19:26:26 qemu? Nov 05 19:26:37 woglinde_: its armv4t Nov 05 19:26:43 hm= Nov 05 19:26:46 hm Nov 05 19:26:53 sa1100 too? Nov 05 19:26:58 I mean from OE pov Nov 05 19:27:13 I dont know if we can configure it to emulate a armv4 box Nov 05 19:27:14 kergoth you around? Nov 05 19:27:16 I am sure we can Nov 05 19:27:34 khem, I did a full build with 4.5 starting from scratch yes. Ive now deleted the entire tmp/ and going to redo with gcc 4.4.2 just to make sure it works Nov 05 19:27:35 kristoffer: ok dont delete you 4.5 root file system Nov 05 19:27:46 rofl Nov 05 19:27:47 and in parallel build with 4.4.x Nov 05 19:28:06 its a fast devserver, so takes about an hour to build bootstrap-image Nov 05 19:28:08 khem are we going to do whole builds or incrementals? Nov 05 19:28:27 ka6sox-work: I would say both Nov 05 19:28:27 khem, roger Nov 05 19:28:37 kk Nov 05 19:28:39 khem, Ill let you know once I have built both Nov 05 19:28:44 kristoffer: ok Nov 05 19:29:07 I want to see why bx are leaking in Nov 05 19:30:36 kristoffer: dont bother Nov 05 19:30:40 I think I know the problem Nov 05 19:30:47 khem, same here. in busybox binary Im seeing bx used as "bx lr" and "bx ip" if that helps Nov 05 19:30:51 khem, sweet Nov 05 19:31:24 * khem halts building the world Nov 05 19:40:08 re Nov 05 19:40:39 jo florian Nov 05 19:43:23 khem, let me know when you have pushed something to test. Nov 05 19:48:40 kristoffer: I am testing a patch Nov 05 19:48:55 roger Nov 05 19:54:14 hello, what is the difference of using devshell and setup-env ? Nov 05 20:00:44 I have a question regarding where I can define the CORTEXA8FIXUP variable checked in linux.inc Nov 05 20:01:24 if I define it in my linux recipe it works as expected. However I would prefer to have a recipe that works with both cortex a8 and a9 Nov 05 20:01:55 so I figured it would make sense to add CORTEXA8FIXUP to machine.conf files as appropriate Nov 05 20:02:15 define as yes for a8 machines, and no for a9 machines Nov 05 20:02:25 however this doesn't work Nov 05 20:02:58 can anyone explain why recipe definition is good, machine.conf definition is bad? Nov 05 20:06:09 recipes get all configuration metadata, but they're free to override it. do a bitbake -e virtual/kernel | grep \^CORTEXA8FIXUP Nov 05 20:06:19 03Khem Raj  07master * r960846ba91 10openembedded.git/recipes/gcc/ (gcc-4.5.inc gcc-4.5/gcc-armv4-pass-fix-v4bx-to-ld.patch): Nov 05 20:06:19 gcc-4.5.inc: Fix code generation for armv4 with EABI Nov 05 20:06:19 Also bump to latest SVN REV Nov 05 20:06:19 Signed-off-by: Khem Raj Nov 05 20:06:42 kristoffer: ok I pushed the patch to gcc now you should rebuild with this version and ideally should work ok with 4.5 as well Nov 05 20:07:52 sakoman: yeah the variable looks machine.conf material Nov 05 20:08:23 khem: any idea why it doesn't work when I put it there? Nov 05 20:08:44 because I think linux.inc refefines it Nov 05 20:09:14 but with a ?= Nov 05 20:09:20 hmm Nov 05 20:09:31 let me see after the meeting is over Nov 05 20:09:32 so I imagine that the machine.conf would override that Nov 05 20:09:55 OK, thanks. I'll keep looking too Nov 05 20:12:09 like i said, use -e to see what its really set to Nov 05 20:13:58 kergoth: ah, I missed your comment! will do Nov 05 20:15:05 khem the bx patch was missed in gcc-4.5? Nov 05 20:22:10 03Chris Larson  07org.openembedded.dev * rc5b9544d95 10openembedded.git/bin/wrapper.sh: Nov 05 20:22:10 bin/wrapper.sh: fix sed self exec Nov 05 20:22:10 Signed-off-by: Chris Larson Nov 05 20:23:51 hi khem, I have a question concerning gcc configuration in oe. Before when compiling toolchain manualy, we passed things like : --with-float=softfp --with-fpu=vfp --with-cpu=arm1136jf-s now I see there is no such option to configure . Is this expected ? Nov 05 20:32:43 khem, right, Ill start building. Nov 05 20:36:27 did anyone try tslib stuff with 2.6.37-rc1 kernel? Nov 05 20:36:53 ts_calibrate does not work for some reason (it complains that selected device is not touchscreen) Nov 05 20:36:55 but it is Nov 05 20:37:35 evtest $TSLIB_TSDEVICE shows correct data Nov 05 20:50:46 oh, that's because EV_VERSION is changed in 2.6.37, and tslib does strict check Nov 05 20:57:39 Anybody know why various libraries get put into staging as /usr/include/libname-version/libname/files.h, rather than /usr/include/libname/file.h ? Nov 05 20:58:34 ex: in an app, you'd refer to , but in staging it's in gtk-2.0/gtk/gtk.h, so I'm running into issues. Nov 05 21:10:33 foerster: I think you need to use pkg-config so that the correct include paths are added to your build. For example: #CAIRO_CFLAGS = $(shell pkg-config --cflags pangocairo) Nov 05 21:16:31 03Alex Ferguson  07org.openembedded.dev * r55ed0698de 10openembedded.git/recipes/mupdf/mupdf_0.6.bb: Nov 05 21:16:31 mupdf-0.6: Fix SRC_URI for source url change. Nov 05 21:16:31 Older mupdf releases are moved from mupdf.com/download/ to Nov 05 21:16:31 mupdf.com/download/archive/. mupdf 0.6 is an older release Nov 05 21:16:31 and its SRC_URI is no longer valid. Nov 05 21:16:32 Signed-off-by: Alex Ferguson Nov 05 21:16:32 Signed-off-by: Kristoffer Ericson Nov 05 21:31:43 yikes, anyone ever seen this one? : Nov 05 21:32:08 http://pastebin.com/AdZQTY1G Nov 05 21:45:34 likewise: thanks. Now I need to figure how how/where to do this with autotools. Nov 05 21:57:56 foerster: if you found out let me know :/ Nov 05 21:58:04 just got it Nov 05 21:58:11 trying now, will let you know in a minute Nov 05 21:58:20 foerster: so far, I have used Makefile's only for that. I'm planning to go autotools Nov 05 22:00:28 likewise: yay, figured it out. Nov 05 22:01:06 without going through all of the autotools stuff (b/c I'm still learning those)... Nov 05 22:01:09 PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= 2.20.1]) Nov 05 22:01:16 that goes in configure.ac Nov 05 22:01:54 if found, two variables will automatically be created: GTK_CFLAGS and GTK_LDFLAGS Nov 05 22:02:25 Then in my Makefile.am in my source dir, I have an AM_CFLAGS = $(GTK_CFLAGS), which passes that info into me. Nov 05 22:03:13 foerster: thanks for sharing! Nov 05 22:03:45 np. The stuff in brackets [GTK] can be whatever you like. Nov 05 22:04:27 PKG_CHECK_MODULES([THING_I_NEED], [gtk+-2.0 >= 2.20.1]) is just as good and would give me $(THING_I_NEED_CFLAGS) in the Makefile.am Nov 05 22:04:40 bbiab Nov 05 22:10:53 khem, not quite finished yet with bootstrap-image, but a quick objdump of busybox binary doesnt show any bx thumb instructions. So so far so good Nov 05 22:23:03 Hi Nov 05 22:23:13 i did the tutorial to send patches, Nov 05 22:23:36 but my patch doesn't appear on patchwork... Nov 05 22:25:44 are you subscribed to the mailing list? Nov 05 22:25:48 i never got any emails from you Nov 05 22:26:26 yes Nov 05 22:26:31 i forget the email Nov 05 22:26:48 i was subscribed on openembedded-commits Nov 05 22:26:50 correct? Nov 05 22:27:01 you need to subscribe to openembedded-devel Nov 05 22:27:08 and send to it? Nov 05 22:27:16 yes, that's the email to send proposed patches Nov 05 22:27:20 ah ok Nov 05 22:27:21 thanks Nov 05 22:27:22 :) Nov 05 22:27:30 others will vet/ack/test it, then commit it on your behalf, if you're not a commiter Nov 05 22:27:32 no problem Nov 05 22:31:37 ok i send to openembedded-devel Nov 05 22:31:40 that appears here Nov 05 22:32:14 at there appears? Nov 05 22:33:18 khem: hi, I've just resent eglibc-make-3.82 patch Nov 05 22:33:32 khem: now it patches eglibc-2.11 and eglibc-2.12 Nov 05 22:33:42 can't test it on earlier versions, sorry Nov 05 22:55:23 bah, gnome-power-manager is busted, can't find libtool Nov 05 22:55:34 khem, sound like an easy fix? Nov 05 23:02:53 tartarus autotools? Nov 05 23:04:30 hm Nov 05 23:05:01 lol Nov 05 23:05:02 it used to build i assume Nov 05 23:05:09 gnome.bbclass has EXTRA_OECONF += "--enable-introspection=no" Nov 05 23:05:19 koen saying it takes 8hrs for angstrom-gnome-image sounded crazy for a 16 core box Nov 05 23:05:26 so trying locally and hit that Nov 05 23:05:52 hrm Nov 05 23:06:08 woglinde_: that's pretty silly Nov 05 23:06:20 kergoth I thought that Nov 05 23:06:45 apparently they've never heard of disable :) Nov 05 23:07:07 hm Nov 05 23:07:16 * kergoth experiments with using topgit to manage integration branches Nov 05 23:07:19 * woglinde_ scratches head Nov 05 23:11:13 hey kergoth - just looking for a quick answer - why does the perforce fetcher work the way it does (file at a time)? Nov 05 23:11:20 no idea, didn't write it Nov 05 23:11:32 oh, thought i saw your C on it, my apologies. Nov 05 23:12:07 RP made some modifications to it, but it was originally written by Jordan Crouse, aka CosmicPenguin on freenode Nov 05 23:12:19 thanks! Nov 05 23:12:23 the only commits i've done to it have been repo wide adustments to prepare for python 3.0, etc Nov 05 23:12:31 np Nov 05 23:13:39 my group is working on a new one with p4 "views", srcrev support. Nov 05 23:13:55 ah, nice Nov 05 23:14:10 we're looking to replace bb.fetch entirely with something that sucks less one of these days Nov 05 23:14:14 needs to be revamped badly Nov 05 23:15:34 https://github.com/kergoth/openembedded/compare/master...autotools seem sane to people (ignore the Branch Setup commit) Nov 05 23:15:37 ? Nov 05 23:15:39 stinking kernel patch won't apply :( maybe i need more context lines? Nov 05 23:16:25 i add two hunks to one file, one 3-liner at the top and one of roughly 30 lines further down; the second hunk always fails, and i can't get diff to tell me any more specifically what the problem is, the patch looks fine to me Nov 05 23:19:02 anyone make a straight-up read-only filesystem with OE? I need one w/o S98configure, if possible. Nov 05 23:29:20 okay, i think topgit is going to make my life a hell of a lot easier wrt integration testing of my topic branches Nov 05 23:30:17 i wonder if its able to remove a dependency from a branch though Nov 05 23:30:32 hmm, doesn't look like it, yet at leats Nov 05 23:30:36 khem, hmm getting exact same error when booting up the new bootstrap-image, however none of the binaries now contain 'bx' Nov 05 23:30:39 minor annoyance Nov 05 23:31:07 maybe you could do a revert of the merge, then manually adjust .topdeps and rebase to sanitize the history Nov 05 23:31:19 khem, the kernel panic is essentially the vague "Kernel panic - not syncing: attempted to kill init!" with the usual backtrace. Nov 05 23:32:44 for those interested, my patch issue was a tabs vs. spaces thing, needed to >> the diff to a file rather than copy-and-paste from terminal :P Nov 05 23:55:43 hmm, yes, this is a definite improvement. there are downsides, given how dependent it is upon the merge based workflow rather than rebase, but i can see its usefulness, can always rebase the branch when the time comes to push it up Nov 06 00:05:09 03Andrea Adami  07org.openembedded.dev * rfda42d99d3 10openembedded.git/recipes/libqtaux/libqtaux2.inc: Nov 06 00:05:09 libqtaux2: fix staging of opie headers. Nov 06 00:05:09 * staging code in do_compile has been converted and moved in do_install Nov 06 00:05:09 * fix breakage introduced with febcae3b7b0b58c2668892ad1798eb1368bd4bc4 Nov 06 00:05:09 * (liquidset.cpp:38:32: error: opie2/ocolorbutton.h: No such file or dir...) Nov 06 00:05:10 * tested rebuilding opie-image armv5te from scratch Nov 06 00:05:11 * bump PR Nov 06 00:09:37 Hi Nov 06 00:10:14 a Celeron M compiling a minimal image,it's a good idea? Nov 06 00:12:06 it is if you're patient Nov 06 00:12:35 depends on how minimal, if you don't want X or a desktop manager, a basic command-line image shouldn't take terribly long Nov 06 00:13:00 kergoth: I did not know we are already here: Build Configuration: \BB_VERSION = "1.11.0" Nov 06 00:13:18 I'm using master, flawless fwiw Nov 06 00:13:44 mrj10: i'll give the notebook at night..... what do you think? it can compile on a night only command-line ? Nov 06 00:13:46 heh, master's version should likely be adjusted to git + git rev or something :) Nov 06 00:16:20 i couldn't tell you, i've only used relatively beefy machines, but do be sure to let us know how it goes :) Nov 06 00:18:09 question: does minimal / console-image warn about 'NOTE: multiple providers are available for runtime module-init-tools-depmod (module-init-tools, module-init-tools-cross)' ? Nov 06 00:18:19 angstrom/console-image does Nov 06 00:18:25 here... Nov 06 00:18:39 when i was using it Nov 06 00:18:40 yes Nov 06 00:20:21 heh, x11-image has now several cases like above :/ Nov 06 00:20:32 tartarus hm gnome-power-panel worked here Nov 06 00:20:51 ant_,this warning is important? Nov 06 00:20:53 his sounds nasty: NOTE: multiple providers are available for runtime hotplug (udev, hotplug-ng, linux-hotplug) Nov 06 00:21:01 but uclibc has nox execinfo.h Nov 06 00:21:13 ant_,these warning is important? Nov 06 00:21:17 warnings* Nov 06 00:21:26 angelox not really Nov 06 00:21:27 usually not, because those are just built Nov 06 00:21:36 hum... i understand Nov 06 00:21:42 goodbye peoples Nov 06 00:21:46 i'll test fedora Nov 06 00:21:49 later! Nov 06 00:22:20 woglinde: still...I hate those notes Nov 06 00:22:50 heh.. NOTE: consider defining a PREFERRED_PROVIDER entry to match xcursor-transparent-theme Nov 06 00:23:00 who did break the providers? :p Nov 06 00:27:24 Hi all Nov 06 00:27:37 someone know where i change the version of gcc? Nov 06 00:27:52 local.conf Nov 06 00:29:50 thx Nov 06 00:30:53 hmmm Nov 06 00:31:04 in this file nothing about gcc version Nov 06 00:31:12 now i use gcc-4.4.3 Nov 06 00:31:24 but i want try gcc-4.4.2 or 4.4.1 Nov 06 00:32:05 use 4.5 Nov 06 00:33:23 how to update it? Nov 06 00:33:31 i am noob on that Nov 06 00:34:27 if you are using angstroem ANGSTROM_GCC_VERSION = "4.5" Nov 06 00:34:47 i think i don't use angstroem Nov 06 00:36:31 here my local.conf -> http://pastebin.com/HU9t6nMq Nov 06 00:36:47 sorry have to go Nov 06 00:36:58 look at the angstroem conf Nov 06 00:45:52 someone can help me? Nov 06 00:50:53 Popeye_: i was gone for a bit. you're trying to change your "gcc version" right? Nov 06 00:51:14 what MACHINE are you compiling for? Nov 06 00:51:45 and do you want a new version of the cross-compiler or a native compiler for the device to compile things for itself **** ENDING LOGGING AT Sat Nov 06 02:59:57 2010