**** BEGIN LOGGING AT Wed Nov 17 02:59:57 2010 Nov 17 03:16:46 meh Nov 17 03:22:55 hrm, for some reason the recipeinfo changes result in not reparsing some recipes when a cache is in place that were reparsed without the changes.. Nov 17 03:22:59 * kergoth tries to track down why Nov 17 03:23:51 kergoth: I am bewildered Nov 17 03:23:57 there is this git repo Nov 17 03:24:06 if I clone it manually works all ok Nov 17 03:24:13 but bitbake fetcher is failing Nov 17 03:24:20 what's the failure? Nov 17 03:25:04 "git://gitorious.org/efikamx/linux-kernel.git;protocol=git" Nov 17 03:26:28 http://pastebin.com/4gNUc1Xi Nov 17 03:26:52 weird Nov 17 03:26:58 that same command works at a commandline? Nov 17 03:28:30 git clone -n git://gitorious.org/efikamx/linux-kernel.git /home/kraj/work/oe/downloads/git/gitorious.org.efikamx.linux-kernel.git Nov 17 03:28:33 works Nov 17 03:29:16 weird. Nov 17 03:29:18 hmm Nov 17 03:29:35 I have two gits Nov 17 03:29:38 and both work Nov 17 03:29:49 one is from native staging Nov 17 03:30:09 no idea, that's a strange one Nov 17 03:30:22 it happens all the time Nov 17 03:34:01 I am going to buy an Android phone, which model would work with OE in the near future? Nov 17 03:44:24 mfhk: well HTC seems to working with oe Nov 17 03:55:16 * kergoth hacks on bb.cache some more Nov 17 04:08:52 damnit, with this patch applied: 6816 cached, 387 parsed. without: 6791 cached, 412 parsed. Nov 17 04:08:57 * kergoth mutters Nov 17 04:13:50 does https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep seem sane, looking over the diff? Nov 17 07:02:58 gm Nov 17 07:05:09 khem you still here ? Nov 17 07:45:12 good morning Nov 17 08:20:03 gm Nov 17 09:35:06 03Chase Maupin  07org.openembedded.dev * r64db5346f3 10openembedded.git/recipes/u-boot/u-boot_git.bb: Nov 17 09:35:06 u-boot_git: use SOC_FAMILY for omapl devices Nov 17 09:35:06 * Use the SOC_FAMILY override for omapl137 and omapl138 based Nov 17 09:35:06 devices. Nov 17 09:35:06 Signed-off-by: Chase Maupin Nov 17 09:35:06 Signed-off-by: Koen Kooi Nov 17 09:35:08 03Koen Kooi  07org.openembedded.dev * rabcc9c2948 10openembedded.git/recipes/linux/linux-davinci_git.bb: Nov 17 09:35:08 linux-davinci git: update hawkboard Nov 17 09:35:08 Signed-off-by: Koen Kooi Nov 17 09:35:09 03Chase Maupin  07org.openembedded.dev * rb64297415c 10openembedded.git/conf/machine/am180x-evm.conf: Nov 17 09:35:09 am180x-evm: Add am180x-evm machine type Nov 17 09:35:09 * Add new machine type for the AM180x family of devices. These Nov 17 09:35:10 devices are part of the omapl138 SOC_FAMILY. Nov 17 09:35:10 Signed-off-by: Chase Maupin Nov 17 09:36:52 hm.. it thought that bb of image for efikamx is hang but seems it was fetching kernel image from git.. Nov 17 09:37:16 well, x11-image should redo the task Nov 17 10:16:43 hm, anyone ever got this while building: Nov 17 10:16:47 sh: /home/frans/workspace/SYHL1_1/C/Linux/openembedded/tmp/staging/x86_64-linux/bin/quilt: /bin/bash: bad interpreter: Text file busy Nov 17 10:17:05 this is ubuntu 10.04, /bin/bash exists Nov 17 10:17:24 * eFfeM_work is puzzled but thinks kicking the build again might allow it to proceed Nov 17 10:17:37 eFfeM_work, yes, and I don't remember what fixed it...too late here. Nov 17 10:18:00 i'll see if it is repeatable Nov 17 10:18:24 apparently not; a new build does not give the error Nov 17 10:19:18 khem, uclibc++ patch posted, would especially like to see your feedback on the cstring patch (which might not be good, but at least it got things compiling :-) ) Nov 17 10:23:57 good morning Nov 17 10:24:06 eFfeM_work: there are still some race issues, it seems Nov 17 10:24:38 guess so, but text file busy is probably an OS or bash issue Nov 17 10:24:42 hi ericben Nov 17 10:24:48 at least I solved a repeatable one: lzma-native Nov 17 10:25:00 ah, cool Nov 17 10:25:07 imagine removing an unneeded dependency cured the thing... Nov 17 10:25:11 strange Nov 17 10:25:15 also would like to understand the preferred provider thing, see my reply on your mail Nov 17 10:25:20 yep Nov 17 10:25:37 and documentation about PREFERRED_VERSION_pn Nov 17 10:25:49 when adding PACKAGE_ARCH = ${MACHINE}, should'nt the workdir be tmp/work/${MACHINE}-angstrom-linux-gnueabi ? Nov 17 10:27:02 ericben: probably (depends on the triplet, and ofc only if you are building for angstrom) Nov 17 10:27:23 eFfeM_work: see Re: [oe] [PATCH (v2)] Reverse the order of OVERRIDES Nov 17 10:27:26 I also have this: ppce500v2-oe-linux-gnuspe Nov 17 10:27:29 outstanding issue imho Nov 17 10:28:01 ant_work: that's why I added the _local Nov 17 10:28:49 actually I seem to recall a reply from RP that this introduces an incompatibility between oe and yocto/poky so not too sure that patch is a good plan Nov 17 10:28:58 would love to see the _target override though Nov 17 10:29:10 I have a strange behaviour here (on qt4 embedded recipe, amended in an overlay for a machine) : the workdir is armv6-angstrom... , but the package is machine specific in the end which is correct. The problem is when building meta-toolchain-qte, I get this error : cp: cannot stat `/scratch/tests/101116/cpuimx35/tmp_angstrom-2010.x_eukrea-cpuimx35/pkgdata/eukrea-cpuimx35-angstrom-linux-gnueabi/qt4-embedded': No such file or directory Nov 17 10:29:44 so meta-toolchain-qte search for qt4-embedded in the machine dirs when it's built in the arch dir Nov 17 10:30:12 do you have an idea of where I should search for this problem ? Nov 17 10:33:14 strange Nov 17 10:33:29 yes I agree with you :-D Nov 17 10:33:33 not really an idea, not something I have too much knowledge about Nov 17 10:33:55 this was working fine before, so I'm searching for the comit which broke this Nov 17 10:38:53 is the problem repeatable ? (have you tried to rm tmp and does it resurface) ? Nov 17 10:39:17 i expect this to be something in the class stuff Nov 17 10:39:36 in fact I found this when doing a clean build from scratch Nov 17 10:40:21 I have overlay + amend.inc + FILESPATHBASE change to pick files from overlays Nov 17 10:41:21 I'm goiing to try some testing tags to find when that broke Nov 17 10:50:49 seems ok with me, but I'm not too good with amend.inc somehow it didn't work for me the way I wanted it (and neither did .bbclass) but didn't dive into it yet, guess that was something at my side) Nov 17 10:58:54 kergoth_, is there a subtile reason why there are soooo many 'p' in Fetch::suppports_srcrev() ? If not i'll rename it in master, fwiw Nov 17 11:00:09 (osc has this wrong -- since it's using just 2 'p' ;) Nov 17 11:09:26 eFfeM_work: that seems to be a problem in amend.inc. setting PACKAGE_ARCH = "${MACHINE}" in oe's recipe works fine Nov 17 11:12:07 kergoth_, can we use bz2 or no compression at all (instead of .gz) for packing checkouts or do you think that doesn't make sense or won't be used? Just an idea.. Nov 17 11:14:24 does it happen only to me? http://pastebin.com/6RE7417z Nov 17 11:15:37 ynezz: this happens also to me ... when I have a mistake somewhere in a recipe Nov 17 11:15:55 the hardest thing is to find where is the mistake as bitbake doesn't provide any log for this Nov 17 11:15:56 but it's testing-next from 12th November and bitbake master Nov 17 11:16:17 that's why I'm asking :) Nov 17 11:16:20 ynezz: ah interesting :) Nov 17 11:31:20 Hello, someone has an idea how to fix this build error with OE: http://pastebin.com/xhZmvqQs ? Nov 17 11:41:54 I have a 1024x600 resolution on my lcd . Any pointers where can i specify for OE to be built for that screensize Nov 17 11:55:23 hm, the parsing error is in openssl recipe and fails also with bitbake 1.10.1 Nov 17 11:55:34 but I can't clearly see why Nov 17 11:56:09 http://pastebin.com/55kJwULL Nov 17 11:56:39 ParsingErrorsFound is really sparse error message :) Nov 17 12:14:34 eFfeM_work: I found the problem ! changing PACKAGe_ARCH in amend.inc doesn't work because MULTIMACH_ARCH is already set and is the variable used for the workdir path for example Nov 17 12:14:39 e Nov 17 12:15:30 eFfeM_work: setting PACKAGE_ARCH *and* MULTIMACH_ARCH to ${MACHINE} in amend.inc seems to do the trick Nov 17 12:17:15 03Martin Jansa  07master * r9be2cf18ce 10openembedded.git/recipes/ (5 files in 3 dirs): (log message trimmed) Nov 17 12:17:15 jlime,dzen2,puzzles: use RDEPENDS_${PN} Nov 17 12:17:15 * it was fixed in whole tree about half year ago Nov 17 12:17:15 http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-June/020384.html Nov 17 12:17:15 http://comments.gmane.org/gmane.comp.handhelds.openembedded/33440 Nov 17 12:17:15 * then again about month ago Nov 17 12:17:16 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg11356.html Nov 17 12:17:35 someone building micro+eglibc? Nov 17 12:18:02 for some reason stdio.h isn't in sysroot after building from scratch for me (and eglibc-initial fails to configure) Nov 17 12:41:33 ericben: ah ok, good find, guess we should document it somewhere Nov 17 12:42:37 ynezz: try running bitbake -v -v -v -D -D -D recipename Nov 17 12:46:14 eFfeM_work: yes I'll send a mail to the list explaining the thing Nov 17 13:03:00 JaMa: suggest writing an email to list with cc to alex and kristoffer on the RDEPENDS thingie Nov 17 13:16:05 eFfeM_work: well I replied to oe-devel an oe-commits when I noticed in their recipes without any reaction... so I just pushed it Nov 17 13:19:06 yeah, now recall the reply (was probably between the 600 messages or so that where in my box after being away for a week) Nov 17 13:20:32 eFfeM_work: btw did you notice that your libx11 change is already applied upstream? Nov 17 13:20:42 so next libx11-1.4 snapshot will have it Nov 17 13:20:52 cool, will get to it later Nov 17 13:20:56 now busy Nov 17 13:21:10 ok :) Nov 17 13:32:08 what's the correct way of moving a file from one package to another without breaking upgrades? Nov 17 13:33:26 obi: RREPLACES_old = new Nov 17 13:34:50 i think this will only work if the old package should be removed Nov 17 13:35:07 but i already have both packages installed and want to keep both packages after the upgrade Nov 17 13:35:31 that's RCONFLICTS_ Nov 17 13:35:55 JaMa: the other way around, surely. "RREPLACES_new = old". Nov 17 13:35:56 but better to test first I'm not 100% sure Nov 17 13:36:07 seems a bit unreasonable to expect the old packages to predict which new ones will be invented to replace them :-} Nov 17 13:36:12 pb_: ah right Nov 17 13:38:35 JaMa: you mean something like RCONFLICTS_new = "old (<$version)"? can version include the PR? the only similar occurence in git looks like this: RCONFLICTS_${PN}-tshark = "tshark wireshark (<1.0.5)" Nov 17 13:40:58 obi: but that's if you need to remove whole old package before installing new one Nov 17 13:41:34 RREPLACES can be used if new package only partially replaces old one (that's our case isn't it?) Nov 17 13:42:08 and I'm not sure that RCONFLICTS are automatically resolved during opkg upgrade Nov 17 13:42:19 user maybe have to remove it manually first Nov 17 13:42:34 ah, yes, i see. my guess was that RREPLACES indicates a replacement for an obsolete package Nov 17 13:45:01 but my question regarding the PR remains the same, since RREPLACES_${PN} = "tshark wireshark (<1.0.5)" is again the only package with specifies a version Nov 17 13:46:15 obi: do you actually need to specify a version? Nov 17 13:46:20 I don't think you have to wrote version there Nov 17 13:47:50 i think so, because i want to upgrade the old package instead of removing it Nov 17 13:47:55 the documentation says: Nov 17 13:48:01 RREPLACES Nov 17 13:48:01 Used to specify that the current package replaces an older package with a different name. During package installation the package that is being replaced will be removed since it is no longer needed when this package is installed. Nov 17 13:48:21 I think that documentation is wrong. Nov 17 13:49:18 ok Nov 17 13:50:32 i think i should specify a version, because the new package should not replace the upgraded old package ;) Nov 17 13:51:03 but in the specific case i'm probably able to bump the version of the old package, making the PR irrelevant Nov 17 13:51:18 JaMa: wrt the x11 patch,did they apply it just as we gave it? seem to recall there was a change proposal Nov 17 13:51:48 but in any case: can we create a similar patch for the current version and apply that one ? Nov 17 13:51:50 eFfeM_work: no changed Nov 17 13:51:57 ah so we can just push Nov 17 13:52:02 and then changed host<->target var Nov 17 13:52:26 eFfeM_work: I meant: no, changed :) Nov 17 13:52:33 ah ok Nov 17 13:52:40 yeah that was discussed Nov 17 13:52:52 http://cgit.freedesktop.org/xorg/lib/libX11/log/ Nov 17 13:53:33 fml. PHP forcefully disables libdl when cross compiling, meaning I can't (easily) get any extensions to work. hmm. Any autoconf gurus around with some hints? Nov 17 13:53:35 can you add that patch to the current libx121 ? Nov 17 13:53:42 JaMa: ^ Nov 17 13:53:52 been involved in other problems over my ears atm Nov 17 13:54:40 * JaMa too and leaving in few minutes, sorry Nov 17 13:54:47 also no nios to test it :) Nov 17 13:54:48 ah ok, np Nov 17 13:57:48 forester, does it just not test for it being supported? Nov 17 13:57:52 That's just another site variable Nov 17 13:59:19 Tartarus: it checks if it can find dlopen directly, then tries by linking with -ldl . Since cross compiling, the default is set to no automatically. Nov 17 13:59:42 I tried setting a site variable, but they do unset ac_cv_* before running tests. Nov 17 14:00:37 OK, wow, that sounds pretty broken Nov 17 14:00:50 I'd go and patch the configure scripts too Nov 17 14:00:58 Tartarus: early for you? Nov 17 14:00:59 ok, stealing some time ... Nov 17 14:01:40 Crofton|road, not since my son decided 0600-0630 is his getting up time Nov 17 14:02:02 and he's still too young to read a clock :( Nov 17 14:02:25 Tartarus: This problem sounds familiar :-) Nov 17 14:02:30 * Crofton|road is cursing noisy hotles Nov 17 14:02:34 hotels Nov 17 14:06:14 JaMa: patch created, retested that it patches ok for all versions, don't have a nios tree handy to build it Nov 17 14:06:20 if ok, please ack and I'll push it Nov 17 14:06:31 patch is already send to ML Nov 17 14:14:19 RP: are we due to have a TSC meeting today? Nov 17 14:14:27 * pb_ loses track of which day is which Nov 17 14:31:06 gm Nov 17 14:31:31 it seems commit b35109935bdb9e18671456a8c2e404a0c5556c0e breaks all images that include task-native-sdk Nov 17 14:32:43 was it intentional to change the name of the package generated? Nov 17 14:33:05 kergoth? Nov 17 14:54:39 a Debian based Host PC is no longer valid choice to build OE ? Nov 17 14:55:13 due git without curl? Nov 17 14:55:14 mckoan: works fine here Nov 17 14:55:28 JaMa: yes Nov 17 14:55:33 just remove ASSUME_PROVIDED git-native from your config I guess Nov 17 14:56:26 and then build git-native first with -b (because otherwise it will fail to build due to git) Nov 17 14:56:56 JaMa: and in this case bitbake create git and use it instead of the host provided? Nov 17 14:57:28 y Nov 17 15:01:24 funny http://tinderbox.openembedded.net/packages/985559/ Nov 17 15:01:37 sakoman_: hmm, i built one with that in fine, and compared the testlab results before and after to make sure the images were the same, maybe i messed up the test somehow Nov 17 15:01:43 sakoman_: what's the behavior? Nov 17 15:03:00 kergoth_: the commit removes: RPROVIDES_${PN} = "task-native-sdk" Nov 17 15:03:23 so any image that includes task-native-sdk fails due to no provider Nov 17 15:04:07 not seeing what you mean. the images that want it don't include task-native-sdk.inc, they add task-native-sdk to RDEPENDS, and task-native-sdk.bb produces a task-native-sdk package.. Nov 17 15:04:25 * kergoth_ shrugs, can easily add it back Nov 17 15:04:38 ericben: works on you ride with Lenny 64bit? Nov 17 15:04:45 nothing in the current oe tree seems to behave the way you describe, as far as i can see Nov 17 15:04:54 ericben: s/ride/side Nov 17 15:05:27 kergoth_: note the subtle difference between task-sdk-native and task-native-sdk -- theold recipe was named the former, but produced the latter Nov 17 15:05:27 oh, i'm blind Nov 17 15:05:29 * kergoth_ nods Nov 17 15:05:39 why the hell are we doing that, again? Nov 17 15:05:55 * kergoth_ mutters Nov 17 15:06:00 I have no freakin' clue -- I've always found it bizzare and confusing Nov 17 15:06:08 but I just lived with it Nov 17 15:06:46 well, i'll bring back the rprovides for now Nov 17 15:06:50 we can fix the thing after the release Nov 17 15:07:02 well, the rprovides is probably good either way Nov 17 15:07:07 but the recipes should get a rename :) Nov 17 15:07:13 yup, I agree Nov 17 15:07:38 the -native at the end is confusing at best, and liekly wrong since it isn't a native package Nov 17 15:07:50 clearly you aren't the only one confused by this, since i got screwed up by it too :) Nov 17 15:08:11 I've had a gazillion gumstix customers ask me about it too Nov 17 15:08:22 it is definitely a faq Nov 17 15:09:39 k, fixed, thanks for spotting it Nov 17 15:10:26 mckoan: I'm on a debian sid 64bits Nov 17 15:10:36 03Chris Larson  07master * rc4912d6abf 10openembedded.git/recipes/tasks/task-sdk-native.inc: Nov 17 15:10:36 task-sdk-native: resurrect RPROVIDES_${PN} Nov 17 15:10:36 Signed-off-by: Chris Larson Nov 17 15:10:49 ericben: I suppose that sid has a newer git :-( Nov 17 15:10:59 mckoan: Version: 1:1.7.2.3-2 Nov 17 15:11:09 03Frans Meulenbroeks  07master * ra2820f8fd2 10openembedded.git/recipes/xorg-lib/ (8 files in 5 dirs): (log message trimmed) Nov 17 15:11:09 libX11: patch configure.ac so a nios2 system is not seen as an os2 system. Nov 17 15:11:09 The OS/2 platform requires some utility functions as well as having a non-32 bit wchar_t. Fix the configure check so that it doesn't also affect the nios2 cpu, which wouldn't influence these operating system issues. Nov 17 15:11:09 This is already accepted upstream and will be in 1.4 Nov 17 15:11:10 http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=affc2488a7f2660a74dc8354fc3e0bff2c4f879c Nov 17 15:11:10 Signed-off-by: Frans Meulenbroeks Nov 17 15:11:11 Acked-by: Martin Jansa Nov 17 15:11:20 03Chris Larson  07master * rc59070a06b 10openembedded.git/recipes/tasks/task-sdk-native.inc: Nov 17 15:11:20 task-sdk-native: forgot to bump INC_PR Nov 17 15:11:20 Signed-off-by: Chris Larson Nov 17 15:11:20 JaMa: thanks for the ack Nov 17 15:11:25 yw Nov 17 15:12:02 figured as it was identical to the upstream patch an ack from you alone is ok Nov 17 15:12:05 kergoth_: hi, what do you think about the patch I send concerning amend.bbclass ? Nov 17 15:12:08 would like to get this in the weekly build Nov 17 15:12:37 When are testing tags made again? Nov 17 15:12:59 * Tartarus would like to see sane-toolchain + powerpc work again :) Nov 17 15:13:04 Tartarus: friday I think Nov 17 15:13:20 ericben: on Lenny is git version 1.6.3.3 Nov 17 15:13:27 Tartarus: thursday, i think 5pm but not sure which TZ (probably EST or PST) Nov 17 15:13:44 ok, a little time then, thanks Nov 17 15:13:57 ericben: and bitbake -b git-native fails Nov 17 15:14:17 ~curse git-native Nov 17 15:14:18 May the fleas of a thousand camels infest your most sensitive regions, git-native ! Nov 17 15:14:20 ericben: the concept is good, but I think the logic of how MULTIMACH_ARCH is set is slightly more complex than that. Your patch won't catch the case where PACKAGE_ARCH_ is set to MACHINE_ARCH. See lines 58 through 89 in base.bbclass. We should likely shift that either out of an anonymous python function, or move that logic into lib/oe/ or a def'd python function, so we can call it from amend.bbclass as well Nov 17 15:15:33 hi kergoth Nov 17 15:15:41 hey pb_, how's it going? Nov 17 15:15:43 kergoth_: OK I took inspiration from base.bbclass but didn't see all that. I'll try to update the patch. Nov 17 15:16:09 kergoth_: yeah, good. cold and wet here nowadays, and starts getting dark at about 3pm, but fine apart from that :-) Nov 17 15:16:10 ericben: don't duplicate the code, please, make it common instead, or change it to not use anonymous python (e.g. MULTIMACH_ARCH = "${@get_multimach_arch(d)}" Nov 17 15:16:15 pb_: hehe Nov 17 15:16:16 hi Nov 17 15:16:32 its lovely here, finally in the 70s(F) during the day, best part of being in arizona Nov 17 15:16:34 kergoth_: are you expecting us to have a tsc meeting this morning? I can't quite remember what we agreed. Nov 17 15:16:58 i can't either -- i don't think i updated the meeting invite to match, so i get no reminders now Nov 17 15:17:01 heh Nov 17 15:17:14 *g* Nov 17 15:17:22 mckoan: Is there perhaps a new git subpackage yuoi need to install from debian? Nov 17 15:17:29 s/yuoi/you/ Nov 17 15:20:53 i think we agreed to meet, but if there's nothing to discuss, we can make it end shortly Nov 17 15:21:09 mickey|office: ok, very good Nov 17 15:22:52 Tartarus: seems not Nov 17 15:25:34 mckoan: perhaps it's a debian bug then? It looks like git ls-remote isn't functional Nov 17 15:29:15 Tartarus: everything worked smoothly unilt 2nd November, must be something new and untested in OE Nov 17 15:30:21 mckoan: Are you sure debian didn't update their git package since? Nov 17 15:30:22 RP: ping? Nov 17 15:30:24 That comes from bitbake Nov 17 15:30:34 mickey|office: does https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep seem sane to you? I'm trying to do some refactoring to make it easier to parallelize the parsing, so i can hand off a filename and get back the recipe info to be added to the cache and dep info, rather than having all this shared state Nov 17 15:30:57 Tartarus: and because seems that I'm the only one building OE on Lenny 64 I argue that who introduced the problem use a different distro Nov 17 15:31:20 mckoan: Well, try this Nov 17 15:31:23 do a ... Nov 17 15:31:34 kergoth_: I'll take a look when I have a chance. Nov 17 15:31:50 git ls-remote http://git.senfdax.de/git/literki master Nov 17 15:32:00 mickey|office: k, no rush, there's a shortage of python-fu in OE and Mentor, hard to get comments :) Nov 17 15:32:10 *nod* i can imagine Nov 17 15:32:20 i finally got around to writing some python again Nov 17 15:32:28 after being buried in Vala and Objective-C for years Nov 17 15:32:30 hehe Nov 17 15:32:33 ncie Nov 17 15:32:35 mckoan: THat's the command that's making that error and the man page for ls-remote says that's valid syntax, i think :) Nov 17 15:32:57 i still have to learn python3 though, can't motivate myself, since there's too few libraries supporting it yet Nov 17 15:33:15 Tartarus: that command in oe tree? Nov 17 15:33:32 yeah, i haven't messed with it much either, though i really want to, particularly the io changes Nov 17 15:33:42 yep Nov 17 15:33:46 i did start a branch in bitbake and ran some 2to3 fixers against it, thats about it :) Nov 17 15:33:48 mckoan: That's the command OE is having bitbake execute Nov 17 15:33:54 mckoan: And it's a normal git command Nov 17 15:33:55 i guess by mid 2011 it should get better Nov 17 15:33:59 people are slowly adopting it Nov 17 15:34:03 So have debian's git try and do it Nov 17 15:34:14 or any other command in the git ls-remote man page Nov 17 15:34:32 OE doesn't even technically require 2.[56] yet :| Nov 17 15:34:39 Tartarus: 16:35 koan@quad:openembedded$ git ls-remote http://git.senfdax.de/git/literki master Nov 17 15:34:43 error: git was compiled without libcurl support. Nov 17 15:34:45 Segmentation fault Nov 17 15:34:47 ouch Nov 17 15:34:52 mckoan: There you have it, debian bug Nov 17 15:35:24 I bet git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc also does that :) Nov 17 15:35:25 damn! Nov 17 15:35:26 taken from the man page Nov 17 15:36:25 wonder if i could talk bitbake into running a 2to3 against our python in the metadata automatically ;) not that it covers everything, but.. Nov 17 15:36:33 hey cminyard Nov 17 15:36:42 morning kergoth_ Nov 17 15:37:13 Tartarus: thx anyway, I'll upgrade to sid Nov 17 15:37:43 mckoan: i'm new to the conversation, but what's the issue with git-native? Nov 17 15:38:10 mckoan: Just file a bug w/ debian Nov 17 15:38:19 That's pretty clearly something that got broken :) Nov 17 15:39:01 kergoth_: hi, see ML topic "16:24 < mickey|office> kergoth_: I'll take a look when I have a chance. Nov 17 15:39:19 kergoth_: hi, see ML topic "Error: git was compiled without libcurl support" Nov 17 15:39:44 ah Nov 17 15:40:58 * mckoan goes back to mainstone build Nov 17 15:43:56 the debian policy manual recommends using "Breaks" in addition to "Replaces" when moving a file to another package. how closely do we want to follow the debian policy? how about introducing an RBREAKS variable? Nov 17 15:44:10 see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces Nov 17 15:44:21 heh, does opkg support that? :) Nov 17 15:44:36 that would become part of the introduction of the new variable, i guess Nov 17 15:46:10 well, worst case the var wouldn't be used by the package managers that don't support it, which is how we've been doing it, as far as i know Nov 17 15:46:21 we have rpm as well, and there's no way everything is going to be supported by them all Nov 17 15:48:42 i guess i'll prepare a patch to get some feedback from the mailing list, then Nov 17 15:48:52 And yocto has a lot of rpm work that would be good to get Nov 17 15:49:03 If possible since it requires pseudo and all that Nov 17 15:52:41 Hello, someone has an idea how to fix this build error with OE: http://pastebin.com/xhZmvqQs ? Nov 17 15:53:32 obi: good plan Nov 17 15:55:01 what are the semantics of Breaks? I'm not familiar with that field. Nov 17 15:55:20 I'm fairly sure that opkg doesn't support it today but, of course, it could be made to. Nov 17 15:57:32 it indicates that the replaced package must be upgraded to continue to work, e.g. after the replacing package gets removed Nov 17 15:57:39 http://www.debian.org/doc/debian-policy/footnotes.html#f46 Nov 17 16:04:47 RP: ping Nov 17 16:41:49 damnit, __BB_DONT_PARSE seems to be biting me in the ass Nov 17 16:41:50 hrm Nov 17 16:42:58 oh hell, i think i see it Nov 17 16:42:59 hmm Nov 17 17:06:15 anyone know where people talk about the features/improvements to gcc that come from linaro? Nov 17 17:07:20 on the linaro ml? Nov 17 17:13:01 have a nice rest of the day Nov 17 17:17:41 hi woglinde! could you please comment on this patch: http://patchwork.openembedded.org/patch/3427/ - git says that you've changed this file (pkgconfig.bbclass) before. ;-) Nov 17 17:22:44 gm Nov 17 17:23:58 obi: that patch looks sensible to me Nov 17 17:26:53 I'd need some one or two acks on the mailing list and a decision when to apply it (before or after the release) ... and finally someone to apply it for me, because my git write access still is non-functional Nov 17 17:29:04 hm Nov 17 17:29:23 I am going home now Nov 17 17:29:26 till later Nov 17 17:49:43 hi Nov 17 17:57:32 eFfeM_work, khem, which ones of those patches for uClibc++ are not in master ATM? Given the fact that uClibc++ is not very volatile a target, i'd recommend to use the master and not some old tarball Nov 17 18:01:53 ISON Nov 17 18:41:20 Crofton: gcc improvements are mainly on linaro mailing lists and the WG meeting minutes Nov 17 18:41:36 are they online? Nov 17 18:41:40 Crofton: any specific question ? I can answer too Nov 17 18:41:51 Crofton: yes. See linaro.org Nov 17 18:42:01 I just want some stuff to look over Nov 17 18:46:20 Crofton: ok Nov 17 18:46:45 actually you wont find vigourous discussions compared to the number of patches but you can get some idea Nov 17 18:46:53 I personally look at the patches what they do Nov 17 18:49:08 I have an application that has some events I would like to use to do page up/down Nov 17 18:49:22 k Nov 17 18:49:29 any thoughts on how I can have user space simulate those key presses ? Nov 17 18:49:56 anyone can answer :) Nov 17 18:50:25 Crofton: libfakekey? Nov 17 18:50:27 Crofton: if you are using some GUI framework it should have such events Nov 17 18:50:41 Crofton: its used for virtual keyboards Nov 17 18:51:19 stefan_schmidt, sounds good Nov 17 18:51:30 this is on gnome built in OE Nov 17 18:52:01 Crofton: used from the matchbox keyboard and maybe also the E17 keyboard Nov 17 18:52:10 should not depend on to much gnome things. Nov 17 18:52:19 But its years since I looked into it Nov 17 18:52:30 thanks, I'll look into this Nov 17 18:53:27 ouoch, does svn.0-hand.com exist anymore Nov 17 18:54:02 Crofton: hmm, check git.o-hand Nov 17 18:55:40 the source mirror has it :) Nov 17 19:05:35 hi Nov 17 19:05:55 i have problem compiling openssl-1.0.0a Nov 17 19:06:04 it always fails in the app directory Nov 17 19:06:10 is this a know problem? Nov 17 19:06:17 is ther a solution? Nov 17 19:15:46 michaelw Nov 17 19:16:53 i am having issues build the meta-toolchain-qte Nov 17 19:17:37 why is it trying to access my host machine native libraries? Nov 17 19:23:34 Crofton, just send a key press and key release event yourself, no? think: http://paste.debian.net/100067/ Nov 17 19:24:03 Crofton, (modulo typos and eventually missing bits) Nov 17 19:24:25 :) Nov 17 19:24:40 thanks, forwarding all these to the guy that needs to make it work Nov 17 19:24:45 he's messing in python atm Nov 17 19:25:49 Crofton, well, i bet there's a python wrapper for Xlib too. Same thing there: If you need an event, heck, just send one ;) Nov 17 19:29:31 Crofton, oops, i forgot to send the release with a KeyReleaseMask. But he'll get the idea.. Nov 17 19:29:40 whatever Nov 17 19:30:50 Packaged contents of kernel into /storage/oe/testbuilder/build/minimal/armv7/deploy/ipk/efikamx/kernel_2.6.31-r0_efikamx.ipk Nov 17 19:30:51 kernel-2.6.31.12-ER1 Nov 17 19:30:52 *** Error: Package name contains illegal characters, (other than [a-z0-9.+-]) Nov 17 19:30:57 yeah Nov 17 19:31:00 khem: no good :( Nov 17 19:31:02 Didn't someone else hit that yesterday? Nov 17 19:31:09 yep Nov 17 19:31:15 Can't do ER in your version Nov 17 19:31:16 khem was talking about it Nov 17 19:32:33 NOTE: oestats: error sending task, disabling stats Nov 17 19:32:35 I guess upstream patches or the defconfig adds -ER1 to LOCALVERSION Nov 17 19:32:38 eh.. Nov 17 19:34:47 blindvt, sounds like he has it going in python Nov 17 19:40:30 khem: regarding the release, the TSC covered that today, might want to wait for pb_'s mail Nov 17 19:42:11 Jay7: yeah I will fix it Nov 17 19:42:21 Jay7: I have to patch the kernel version string Nov 17 19:42:32 kergoth_: so whats the direction? Nov 17 19:42:49 kergoth_: do we intend to branch a release ? Nov 17 19:42:58 khem: if possible do it before next testing branch update :) Nov 17 19:43:07 Jay7: yes I will Nov 17 19:44:17 khem: yes, branch off for the release, then tag that branch after a period of time wherein cherry picking will occur for any fixes that need to go in the release Nov 17 19:44:27 khem: wait for the official word, though. Nov 17 19:44:50 hmmm. who will maintain the branch Nov 17 19:44:56 do we have volunteers Nov 17 19:45:01 or is it one of thing Nov 17 19:45:04 maintenance should be a distro issue, not an official OE task Nov 17 19:45:18 ok so we branch out Nov 17 19:45:26 otherwise we run into the problem khem describes Nov 17 19:45:33 and release from there and distro's can then backport Nov 17 19:45:40 so essentially like stable/2009 Nov 17 19:45:44 yeah Nov 17 19:45:55 but what OE publishes is the starting point Nov 17 19:46:39 we're not talking about a long lived branch here. Nov 17 19:46:46 I dont know how many folks will deliver for stabilizing release branch Nov 17 19:46:46 the branch is for any stabilization *before* the release Nov 17 19:46:52 the release itself is a tag from that branch Nov 17 19:46:57 not a release branch after that Nov 17 19:47:09 kergoth_: you release from a tag or not Nov 17 19:47:15 what is purpose of testing branch then? Nov 17 19:47:15 once you branched thats it Nov 17 19:47:21 ? Nov 17 19:47:37 kergoth_: I mean that becomes the maintainance thing Nov 17 19:47:42 no Nov 17 19:47:50 but I think we dont have that much man power seriously Nov 17 19:47:53 there will not be a maintainance branch for the release, no fixes go in after the release Nov 17 19:48:04 basically, we need to try things and see what works well Nov 17 19:48:08 seems we going to use freebsd release logic :) Nov 17 19:48:41 kergoth_, but there is no objection to a distro copying from the tag and maintianing it for their puroposeds Nov 17 19:48:45 the only reason for a branch at all is to give a bit of extra time to pull in any fixes between now and the release. if there aren't any, so be it, but master isn't going to be limited the way you described in the email Nov 17 19:48:47 kergoth_: OK sounds fine Nov 17 19:48:49 Crofton: right, exactly Nov 17 19:49:15 I see that the guy who is doing the release is the only one stabilizing Nov 17 19:49:15 kergoth_, i have a few pythonic hunks for bb fetchers that i'd like to push if it's ok for you. May i send them to you directly, the list or point'n click url? Nov 17 19:49:20 if the release person wants to go based on testing, they're free to do so Nov 17 19:49:28 khem: right, thats how i see it Nov 17 19:49:44 some people REALLY like the current stable branch :) Nov 17 19:50:03 at ELCE we talked with a couple of atmel guys who find it really useful Nov 17 19:50:06 blindvt: direct email is less convenient due to having to get the patches out of my gmail account, there's no pw-am.sh for gmail ;) Nov 17 19:50:16 largely becuase it is very slow to change :) Nov 17 19:50:39 kergoth_: I think we wont muster enough people and time for release. Nov 17 19:50:41 the problem with a long lived stable branch is its nearly impossible to keep up with and review all the commits that do go into master Nov 17 19:50:53 unless master gets merged to it periodically or something, e.g. git's maint branch Nov 17 19:50:59 kergoth_: my idea is a tag on master Nov 17 19:51:06 every six months Nov 17 19:51:40 like i said, that's fine with me, the only decision that was made was that master will not be frozen, if shit breaks there and you can't release from it, that's on you Nov 17 19:51:41 but branch is fine too. Nov 17 19:51:48 beyond that, whatever :) Nov 17 19:52:18 i think we need to sit down and establish a documented process/workflow for our branches and tags and releases Nov 17 19:52:26 yes Nov 17 19:52:26 right now things are a bit too haphazard Nov 17 19:52:29 +1 Nov 17 19:52:44 I think branch is fine. As long as devs help out on release Nov 17 19:52:53 there are many great workflows out there that other projects use, we may want to do something based on one of those -- and most of those are based on general configuration management patterns Nov 17 19:53:03 my only motivation to carve it out of master is the amount of developer base using it Nov 17 19:53:18 kergoth_, http://uclibc.org/~aldot/bitbake/20101117-1606/ Nov 17 19:53:41 if devs come onboard with testing and helping out a to be released branch no problems infact its even better Nov 17 19:53:47 I'd personally rather like to see something like what git does for their project, with 'next' and potentially 'pu' and all Nov 17 19:54:10 well our master = next Nov 17 19:54:51 but I think the release branch will come into being sooner or later even if we tag master Nov 17 19:55:05 which is the problem, really. features dont get integrated together and tested as a whole other than in master itself right now Nov 17 19:55:06 because I expect some heavy use of the release which might need bug fixes Nov 17 19:55:09 which is just asking for problems Nov 17 19:55:10 Crofton: I do think stable is useful and we depend on it here at O.S. Systems Nov 17 19:55:18 and some distro maintainers backport stuff Nov 17 19:55:26 otavio, thanks Nov 17 19:55:36 Crofton: the only problem we have is a "merge point" to "dev" Nov 17 19:55:45 we get little feedback, bu that is good :) Nov 17 19:55:45 blindvt: oh good, suppports always got on my nerves :) Nov 17 19:56:07 Crofton: we would need a way to merge to "next stable" Nov 17 19:56:26 blindvt: regarding strip leading slashes, OE works around that exact same issue -- this makes me think we need to move lib/oe/path.py:join into bb.utils. Nov 17 19:56:47 so I guess what we will do is create the release-2010.12 branch Nov 17 19:57:05 and call out for devs to pound on it Nov 17 19:57:13 blindvt it is probably a good idea to go for the latest version Nov 17 19:57:17 of uclibc++ Nov 17 19:57:21 didn't really consider that Nov 17 19:57:23 may be using the testing matrix Nov 17 19:57:24 kergoth_, bummer, i totally forgot about oe.path. Yea, perhaps that's a good idea Nov 17 19:57:35 blindvt: second, ud.parm.get('md5sum', None) -> None is the default for the second argument, you can just ud.parm.get('md5sum') Nov 17 19:57:45 guess the patches are not in htat version either, there are really only a few commits since the 0.2.2. release Nov 17 19:57:53 (5-10 iirc) Nov 17 19:58:06 khem: if there's any "new" release (stable or whatever) please merge it back into dev from time to time Nov 17 19:58:15 khem: so we have "merge points" at it Nov 17 19:58:18 otavio: it wont be merged Nov 17 19:58:28 otavio: patched should be always backported Nov 17 19:58:35 to it via master imo Nov 17 19:58:35 khem: so it will always be a nightmare Nov 17 19:58:51 freebsd or pkgsrc release process is alike Nov 17 19:58:57 otavio: and 6 months down the line we will have next release Nov 17 19:59:04 blindvt: also you have a remnant commented out line in fetch/svn.py, first hunk in the last patch Nov 17 19:59:04 otavio, that is hard problem due to core changes in dev Nov 17 19:59:06 and then this release is decommissioned Nov 17 19:59:06 pkgsrc does release quarterly Nov 17 19:59:11 blindvt: other than that, they look sane to me Nov 17 19:59:37 freebsd have stable and current branches (like our) Nov 17 19:59:54 eFfeM, garrett didn't do any release in a long time, so i'd really go for master. I admit that i didn't recently try to use it instead of libstdc++-v3 so i'm not current of possibly missing features. That said, we will only fix trunk and journal stuff there so that's what folks should be using for now Nov 17 20:00:31 I like pkgsrc scheme Nov 17 20:00:47 kergoth_, yes: '#logger.warn("You should switch to SRCREV")' Nov 17 20:00:49 blindvt: its also possible we should consider breaking up bb.utils. oe's module is nicely arranged, and move some other things into bitbake, in the long term, but don't bother with that now, i'd suggest just adding oe's join to bb.utils Nov 17 20:00:51 split branch quarterly, stabilize it and announce release Nov 17 20:00:56 s/module/package/ Nov 17 20:01:00 then return to work on master Nov 17 20:01:17 release branches are subject to security updates only Nov 17 20:01:23 kergoth_, i wasn't sure if the comment above that now added comment was still true so i ment to suggest the requested warning. Nov 17 20:01:30 ah Nov 17 20:01:53 Crofton: no related stuff Nov 17 20:01:54 probably not a bad idea Nov 17 20:02:02 kergoth_, i didn't runtime test anything of that and i didn't want to spit out odd/outdated/misplaced warnings Nov 17 20:02:03 Crofton: if backports are done into release Nov 17 20:02:07 * kergoth_ nods Nov 17 20:02:15 Crofton: release ought to "merge" fine into dev Nov 17 20:02:29 blindvt: mind looking over a bit of python for me? finding folks with python-fu to review my bitbake changes is like pulling teeth Nov 17 20:02:32 Crofton: and merging it into dev provides an upgrade path for next stable Nov 17 20:02:35 heh Nov 17 20:02:36 this is why I see people developing their own concpet of "stable" Nov 17 20:03:22 Crofton: for us, for example, move to next OE is a nightmare since we have too many conflicts to deal with Nov 17 20:03:25 kergoth_, didn't runtime-test anything as in all of those whole series (but i'm rather confident that it should work just fine, i think) Nov 17 20:03:26 otavio: This release we will should try to always commit to master and then backport to release branch thats upto disto maintainers Nov 17 20:03:29 khem, please see my reply on the uclibc++ mail, the error messages are in the original mail and in the reply Nov 17 20:03:41 if there is a patch thats only needed on release and not on master then thats fine Nov 17 20:03:51 because the patch is dead anyway Nov 17 20:03:55 khem: right but only doing this doesn't make it work Nov 17 20:04:02 khem: we need to merge release back into master Nov 17 20:04:14 otavio: I dont get it Nov 17 20:04:23 khem: since master will contain all changes of release it will just work Nov 17 20:04:25 we can just release more frequently Nov 17 20:04:27 neither do I Nov 17 20:04:32 fire and forget :) Nov 17 20:04:32 if you branch out and all commits to this branch come via master what do u need to merge back ? Nov 17 20:04:39 kergoth_, ok, thanks. So i'll push those and see if turning on that warning makes sense the next time i build oe and then commit that warning on top Nov 17 20:04:56 khem: OK... let me try to explain Nov 17 20:04:58 otavio: but master will have other shitload Nov 17 20:05:03 that can bite you in the ass Nov 17 20:05:03 I see this is only way for OE at this time because nobody cares about stable Nov 17 20:05:10 blindvt: push after making the changes i proposed? :) Nov 17 20:05:17 Jay7, that is not true Nov 17 20:05:40 blindvt: take a look at https://github.com/kergoth/bitbake/compare/master...parallel-parsing-prep, thoughts? Nov 17 20:05:45 Jay7: only way to enlarge userbase is to have releases Nov 17 20:06:00 Let me try to make it clear. Nov 17 20:06:06 khem: yes, sure Nov 17 20:06:10 OE releases 2010.12 Nov 17 20:06:23 - we branch from it to our internal development Nov 17 20:06:34 - fixes are done into master Nov 17 20:06:37 Crofton: yes thats true Nov 17 20:06:46 - those are cherry-picked into release when OK Nov 17 20:06:57 I have received very positive feedback from suers Nov 17 20:07:08 - release is merged back into master to make sure it provide a merge path good Nov 17 20:07:27 otavio: how to deal with core changes? Nov 17 20:07:28 where users is defined as people doing work with the output of OE Nov 17 20:07:35 kergoth_, which proposed changes? 1) enable the warning -- scheduled for the next oe build. 2) what? Nov 17 20:07:48 e.g. changing required bitbake (and python) versions Nov 17 20:08:04 or changing metadata behaviour like new staging Nov 17 20:08:09 blindvt: add oe.path.join to bb.utils and use that, drop the unnecessary ", None" in that ud.parm.get for md5sum Nov 17 20:08:23 otavio: why should release is merged back into master Nov 17 20:08:26 otavio: so every commit which was cherry-picked to release will be twice on master? Nov 17 20:08:30 release is point, not branch :) Nov 17 20:08:43 kergoth_, k Nov 17 20:09:11 otavio: with 2 different hashes and whoever merged release to master will resolve possible conflict for you? instead resolving all together much later when there is new release? Nov 17 20:09:42 JaMa: yes. Or we commit into release and merge it into master Nov 17 20:09:44 we should define 'release' and 'branch from release was made' Nov 17 20:09:49 *from which Nov 17 20:10:08 thats are different things.. Nov 17 20:10:13 otavio: probably first to master to provide some testing before cherry-picking to release Nov 17 20:10:25 kergoth_, i kept the md5sum None for better readability. In fact i had it out and put it back in in an odd attempt to help other people to understand the code ;) Nov 17 20:10:34 usually maintainence branches receive fixes that are merged into development one when done Nov 17 20:10:49 JaMa: but then there's no path to upgrade to master again Nov 17 20:10:56 I think dict's "get" is pretty well known, if anything itd be the existance of the second argument that's less well known Nov 17 20:11:05 otavio: no merge into release it gets the patches from master that way we make sure that all fixes go into master Nov 17 20:11:12 and are there in next release Nov 17 20:11:18 JaMa: if you try: git merge stable/2009 into master you'll see the nightmare it is Nov 17 20:11:22 * kergoth_ uses it all the time to avoid having to catch a KeyError or check for existence first Nov 17 20:11:31 kergoth_, indeed Nov 17 20:11:34 then they are cherry picked into release even though the fix is only for release Nov 17 20:12:29 otavio: there has to be some time length of maintainance we can not keep a separate brach for that long syncing happily with master Nov 17 20:12:34 OE changes frequently Nov 17 20:13:02 and sometimes changes are fundamental Nov 17 20:13:08 khem: how do you suggest to a company to "fork" from main OE and have an upgrade path for next release then? Nov 17 20:13:18 otavio: why not cherry-pick commits from your branch to new "release" and resolve only those (with needed changes due different core)? Nov 17 20:13:29 I'd suggest a week or two at absolute most for the existence of the release branch, then tag, possibly merge to master, and delete the branch Nov 17 20:13:35 kergoth_, quick style question about import. Do you prefer CSV imports (os, re) or one per line. What about potentially redundant imports -- if bb pulls in module_foo, and mod1 imports bb, should mod1 also import module_foo if it uses stuff from it, just to be sure? Nov 17 20:13:37 * khem gives up and thinks just make the release happen and stop thinking beyond that Nov 17 20:13:58 blindvt: iirc PEP8 advises one import per line Nov 17 20:14:04 otavio: i think the "nightmare" comes from changing files for your fork and not submitting the changes for inclusion into master Nov 17 20:14:05 otavio: w.r.t. internal changes ? Nov 17 20:14:08 i'd say be explicit about what you're using, don't rely on indirect imports Nov 17 20:14:15 otavio: maybe using abb layer would help Nov 17 20:14:18 otavio: the next release will be another branch Nov 17 20:14:33 and it will have all fixes that were done to previous release Nov 17 20:14:41 kergoth_, k. Just asking since alot of spots rely on indirect imports of os.path (IIRC) Nov 17 20:14:45 so your next product can base of this branch Nov 17 20:15:21 blindvt: oh, i see what you mean Nov 17 20:15:29 obi: partially yes. But not really. Nov 17 20:15:31 for that particular case, where the package imports one of its own modules, you can rely on that Nov 17 20:15:41 an import of just os will get you os.path Nov 17 20:15:51 now, if you only use os.path, nothing else in os, i'd say just import os.path Nov 17 20:15:59 imo anyway Nov 17 20:16:02 otavio: I guess you have to stabilize on a release Nov 17 20:16:10 and next release Nov 17 20:16:10 kergoth_, ok Nov 17 20:16:50 i think we need to avoid the 'from' imports as well, it causes problems with module reloading, which is something we may want to support in the future when we support a long lived bitbake server process Nov 17 20:17:00 khem: but not using a git tree. Using a layer? Nov 17 20:17:10 otavio: its then upto you how long you wanna maintain a release branch, the fact that you make the patch work on master makes sure that the problem is fixed for next release Nov 17 20:17:14 kergoth_, one last thing: this one's still open (from earlier today): Nov 17 20:17:18 kergoth_, can we use bz2 or no compression at all (instead of .gz) for packing checkouts or do you think that doesn't make sense or won't be used? Just an idea.. Nov 17 20:17:28 otavio: yes layer is better Nov 17 20:17:40 blindvt: i think that should likely wait until the fetch revamp Nov 17 20:17:43 khem: we use a git tree currently Nov 17 20:17:49 otavio: unfortunately there is no OE standard like ISO C standard that we comply to Nov 17 20:17:54 since we're looking to move unpack/fetch all into bitbake's new fetch module, so things like git can have a more intelligent unpack Nov 17 20:17:54 * otavio needs to learn how to work with layers Nov 17 20:17:56 so things change Nov 17 20:18:05 kergoth_, i see Nov 17 20:18:14 the whole archival of scms may change entirely, or become optional just for mirroring purposes Nov 17 20:18:37 otavio: yeah layers can give you better view of minimizing the changes to OE metadata Nov 17 20:18:56 khem: after the meeting can we talk about this ? Nov 17 20:18:57 and then when you upgrade to newer release you have to port forward your layers only in ideal case Nov 17 20:18:58 kergoth_, i'll have a look at your parallel-parsing-prep if i find the time Nov 17 20:19:06 blindvt: np, no rush Nov 17 20:19:12 just need a sanity check :) Nov 17 20:19:26 e.g. am i completely out of left field, or is this a real improvement to the code Nov 17 20:19:28 figured :) Nov 17 20:20:05 otavio: which meeting ? Nov 17 20:20:27 khem: well, I don't want to disturb asking questions now Nov 17 20:20:49 otavio: sure. Nov 17 20:22:00 kergoth_, did you, by chance, had time to poke at one of those 3 oe patchlets we talked about yesterday? (the redundant deps and, auto-depend native unpackers and the third one)? Nov 17 20:22:42 s/poke/look/ Nov 17 20:22:44 blindvt: i dropped the class changes and was able to build xz and xz-native fine on my machine and configuration, anyway Nov 17 20:22:50 i didn't dive any further than that, though Nov 17 20:23:05 * kergoth_ has so many bitbake and oe trees/branches he's in real danger of forgetting where he was doing things Nov 17 20:23:21 https://gist.github.com/700677 Nov 17 20:23:22 heh Nov 17 20:24:28 meh Nov 17 20:24:30 i'm interrested in feature/typing! perhaps that one can fix my keyboard -- or myself for that matter :P Nov 17 20:24:35 hehe Nov 17 20:24:37 if only it meant that Nov 17 20:29:07 kergoth_, is it ok to handle that 'add oe.path.join to bb.utils' later and push the rest now? I'm accumulating too much noops in bitbake and way too many against oe Nov 17 20:29:38 feel free to push it with the strip slash bits now and revisit later if you want Nov 17 20:29:48 k. thanks Nov 17 20:29:48 i know how you feel Nov 17 20:29:49 np Nov 17 20:30:17 i've resorted to using topgit to manage integration branches, so i can do most of my builds on an integration branch that pulls in all the branches i have pending, and can update it all easily Nov 17 20:30:46 kergoth_, at least i can get rid of local stuff i accumulate in bb. That's a good start :) Nov 17 20:30:49 * kergoth_ nods Nov 17 20:32:11 given the rate that i can trick khem into applying stuff to oe there's a long way to go, but hey Nov 17 20:32:44 blindvt: you just have to make less controversial patches :) Nov 17 20:33:13 i hate it when you put a ton of work into something, then send-email, and get no replies because nobody wants to touch whatever you're changing with a 10 foot pole :) Nov 17 20:33:50 khem, they're useful or make stuff work Nov 17 20:33:53 autobuilder can solve this :) Nov 17 20:34:10 at least check that your changes doesn't break building Nov 17 20:34:16 yeah Nov 17 20:34:39 let's ask Amazon to donate cloud for OE :) Nov 17 20:34:44 can somebody help me build openssl-1.0.0a? Nov 17 20:34:56 i get errors in the app dir Nov 17 20:34:59 then build some kind of autobuilder/tinderbox there :) Nov 17 20:35:29 khem, your master has fucked up ppc support because of bugs in gcc. I sent (i really hope i did when i'm bitching around like that now ;) a workaround to reinstate ppc and nothing happened. *shrug* Nov 17 20:35:39 or even let's ask Intel/AMD directly for build farm :) Nov 17 20:36:18 with Ubuntu 10.10, make -j8 no longer pegs a i7 CPU. Does anyone know if anything has changed with recent versions of make? Nov 17 20:36:24 blindvt: ppc works fine in OE Nov 17 20:38:21 I can add build request interface for my home machine Nov 17 20:38:29 Has someone an idea what's wrong here with mtd-utils_1.3.1.bb - http://pastebin.com/xhZmvqQs ? Nov 17 20:38:29 cbrake: hmm interesting never heard that kind of issue Nov 17 20:38:43 to allow build request queueing Nov 17 20:38:54 cazze: paste your issue somewhere Nov 17 20:40:29 cbrake: here with PARALLEL=16 and BBTHREAD=4 the i7 gets quite loaded ;-) Nov 17 20:41:20 Jordinar: your objdir looks suspicious Nov 17 20:41:42 khem, qemuppc didn't build for me last time i tried. How did you build libstdc++-v3 without support for long-double-128? Nov 17 20:41:43 Jordinar: the issue is that the files are compiled for some other arch and are being linked into some other Nov 17 20:42:03 blindvt: well it build now Nov 17 20:42:20 blindvt: thre is ofcourse one patch from Tartarus that should go in Nov 17 20:42:31 which should happen once he fixes the comment Nov 17 20:43:26 khem: Why is that so? I just picked a preconfigured machine without changing it and issued 'bitbake minimal-image' - or where could I fix that? Nov 17 20:43:58 Jordinar: what does your local.conf look like Nov 17 20:44:25 khem, micro-uclibc with current binutils and current gcc? Can you show me your conf? It didn't for me: http://paste.debian.net/100073/ Nov 17 20:44:29 hmm, would be nice if github let you add a description to a branch, or knew how to show .topmsg when using topgit Nov 17 20:45:07 hmm, even with -j16, top is showing only 50% on a kernel build. That is very odd. In the past -j8 pretty much used all CPU on a kernel build. Nov 17 20:45:21 khem: that's all: http://pastebin.com/eCMnrzVg Nov 17 20:45:51 blindvt: except I use gcc 4.5 Nov 17 20:45:55 and minimal-uclibc Nov 17 20:46:33 cbrake: 1) may be you building something that just have no load for 16 threads; 2) may be some changes in kernel scheduler Nov 17 20:46:36 for me micro+eglibc didn't somehow stage stdio.h and eglibc-initial failed to do_configure bacause of it :/ Nov 17 20:46:53 Jordinar: you dont need to set TARGET_OS Nov 17 20:47:18 JaMa: since when ? Nov 17 20:47:34 JaMa: I think some folks do use micro Nov 17 20:47:43 and dont see this Nov 17 20:47:52 no idea this was actually my first micro build (just to test that binconfig change I've sent to ML) Nov 17 20:48:21 blindvt: anyway take latest OE apply http://patchwork.openembedded.org/patch/3565/ and qemuppc should work Nov 17 20:48:42 btw Nov 17 20:49:02 khem: ack changes for sh3/4 or push it :) Nov 17 20:49:07 Jay7: you have my ack for that Nov 17 20:49:11 khem, yuck Nov 17 20:49:13 khem: I suspected my patch and then 6f5c792dd75746009e7a5994170cec05a92f0fdd, but even after reverting those 2 It still failed Nov 17 20:49:19 ok, I'll push it then Nov 17 20:49:25 khem: "you dont need to" -- meaning it's a problem if I do? I'm trying without that. Is a clean compile necessary then, so I have to remove the whole tmp dir? Nov 17 20:50:38 Jordinar: I think OE is overriding that for you Nov 17 20:50:43 so not an issue here Nov 17 20:51:19 khem: http://pastebin.com/EJy08CmH Nov 17 20:51:36 Jordinar: but this path is fishy /home/radi/oe/build/minimal/mkfs.ubifs/crc16.o Nov 17 20:51:39 khem: alright, mtd-utils still fails... bad, but thanks for your help Nov 17 20:52:04 Jordinar: how does it come to pick that object I wonder Nov 17 20:53:43 khem: the only thing I can tell you is that this file exists ... there are several others in build/minimal --- all related to mtd-utils obviously Nov 17 20:53:47 cazze: it seems its needing crypto Nov 17 20:54:08 tools for writing to flash, etc. Nov 17 20:54:33 Jordinar: how does it end there is a question I would have expected it to be under some sort of target or cross or native build trees Nov 17 20:55:00 khem: so bitbake crypto will do the job? Nov 17 20:55:02 Jordinar: are they cross tools Nov 17 20:55:09 cazze: no Nov 17 20:55:20 cazze: its expecting it be on your host Nov 17 20:55:28 its openssl-native not openssl Nov 17 20:55:41 khem: they definitely end there using 'bitbake minimal-image' ... without changing the scripts etc.... only local.conf is modified. Nov 17 20:56:16 khem: i will thest, thx already for the help Nov 17 20:56:20 *test Nov 17 20:56:28 khem: no, the binaries there run fine on the buildhost (x86) Nov 17 20:57:24 could be an error in the mtd-utils*.bb ? Nov 17 20:57:31 Jordinar: hmmm I see. so those are for host but why are they being linked into target packages I wonder Nov 17 20:57:40 Jordinar: its possible Nov 17 20:57:52 see what link paths its searching stuff in Nov 17 21:00:19 don't see anything suspicious there... Nov 17 21:01:09 hehe Nov 17 21:01:13 khem: basically the target is that board: http://www.ic-board.de/product_info.php?language=en&info=p105_ICnova-SAM9G45-OEM.html (click 'Features' there) .... maybe another machine / distro is known to fit better? Nov 17 21:01:15 * Jay7 have look on vmstat data Nov 17 21:01:26 it's an ARM9 SAM9G45 Nov 17 21:01:29 machine is going to use swap when building Nov 17 21:01:49 I'll graph it Nov 17 21:16:02 khem: even if i do bitbake openssl it takes openssl-native. how can i change that? Nov 17 21:19:55 khem, do you mind if I push the patch I posted on the list yesterday? Nov 17 21:20:13 and I will have a smal updat eto the gnuradio native sdk that needs to go Nov 17 21:25:38 if I REDEPEND on pkgconfig-dev, do I need to DEPEND on pkgconfig? Nov 17 21:27:06 Crofton: sure go ahead Nov 17 21:27:15 k Nov 17 21:27:16 only if you need pkgconfig to build. if you only require it to run, you don't need it in DEPENDS, it'll know to build it Nov 17 21:27:29 Crofton: actually, I am waiting for pb_ email on todays TSC meeting minutes Nov 17 21:27:39 then we might be able to cut a release branch soon Nov 17 21:27:51 I posted the one, both should not have broad impact Nov 17 21:28:11 Jordinar: I will see if I can get around to reproducing it Nov 17 21:28:33 Jordinar: but problem is basically the same what Iexplained somehow linker is searching wrong libs/objects Nov 17 21:29:17 khem: yeah, I agree .... but I really don't know where to tamper in the oe files to fix that Nov 17 21:29:19 cazze: well you can use ASSUME_PROVIDED = "openssl-native" that way it will use the native version from your build host so make sure you have it there Nov 17 21:29:30 Jordinar: ok np Nov 17 21:29:44 I guess that nothing should write its stuff to build/minimal ..... that's what it does here Nov 17 21:29:45 Jordinar: you can summarize the issue on mailing list Nov 17 21:29:56 that will serve as reference for offline work Nov 17 21:30:15 I dont know if I can but if I do come around with some time I will try to fix it Nov 17 21:30:41 didn't work much with lists ..... just writing an email with the info to ..... ? Nov 17 21:31:05 look at openembedded.org Nov 17 21:31:30 ic. Nov 17 21:39:05 kergoth_: I have a patch but I have do_patch overridden Nov 17 21:39:28 kergoth_: so I want to copy this patch into workdir but as a normal file and then apply myself Nov 17 21:39:41 ;apply=no Nov 17 21:39:45 kergoth_: apply=no and what other attribute Nov 17 21:39:47 ok Nov 17 21:39:52 hmm Nov 17 21:39:59 it *should* unpack a patch that's set to apply=no Nov 17 21:40:02 but verify that :) Nov 17 21:40:16 another problem is that I have patches/ folder being overwritten so its better to keep it on topdir Nov 17 21:40:39 hmmm I think I have hijacked unpack too Nov 17 21:40:51 so basically I have to manually symlink it Nov 17 21:44:03 heh Nov 17 21:50:15 03Frans Meulenbroeks  07org.openembedded.dev * rc149a3e6f7 10openembedded.git/recipes/tasks/task-mythtv.bb: Nov 17 21:50:15 task-mythtv: new task to aggregate mythtv related packages Nov 17 21:50:15 Signed-off-by: Frans Meulenbroeks Nov 17 21:50:17 03Frans Meulenbroeks  07org.openembedded.dev * r1ff4b0a7bf 10openembedded.git/recipes/mythtv/mythplugins_0.23+fixes.bb: Nov 17 21:50:17 mythplugins_0.23+fixes.bb: improved installation, commented out apache stuff Nov 17 21:50:17 commented out apache stuff; apache has too many issues building Nov 17 21:50:17 use lighttpd! Nov 17 21:50:17 improved the postinst, make sure the needed modules are enabled Nov 17 21:50:17 in the web server configuration file Nov 17 21:50:18 Signed-off-by: Frans Meulenbroeks Nov 17 21:50:18 03Frans Meulenbroeks  07org.openembedded.dev * r537f94646e 10openembedded.git/recipes/images/james-image.bb: Nov 17 21:50:19 james-image: image for the james, a home entertainment solution Nov 17 21:50:19 see http://www.elinux.org/BeagleBoard/James for outdated doc Nov 17 21:50:20 will be updated (and maybe relocated) in the future Nov 17 21:50:31 Signed-off-by: Frans Meulenbroeks Nov 17 21:50:32 03Frans Meulenbroeks  07org.openembedded.dev * r669a9b9c0a 10openembedded.git/recipes/tasks/task-internetserver.bb: Nov 17 21:50:34 task-internetserver: task to aggregate internet server functionality Nov 17 21:50:34 apache/php/mysql/perl/ftp Nov 17 21:50:35 other servers might be added in due time Nov 17 21:50:35 Signed-off-by: Frans Meulenbroeks Nov 17 21:50:35 03Frans Meulenbroeks  07org.openembedded.dev * r12d3b6eaf3 10openembedded.git/recipes/gtkmm/ (5 files): Nov 17 21:50:35 gtkmm: added gtkmm-demo package Nov 17 21:50:36 There were some unpacked files in /usr/share/gtkmm-2.4/demo/ Nov 17 21:50:36 This patch addes a new package gtkmm-demo and stuffs the files from Nov 17 21:50:37 that demo dir in it Nov 17 21:50:37 Also added INC_PR Nov 17 21:50:38 Signed-off-by: Frans Meulenbroeks Nov 17 21:51:51 03Frans Meulenbroeks  07org.openembedded.dev * rde524aeeec 10openembedded.git/MAINTAINERS: Nov 17 21:51:51 MAINTAINERS: added james-image + tasks to my entry Nov 17 21:51:51 Signed-off-by: Frans Meulenbroeks Nov 17 21:57:47 Hmm Nov 17 21:57:57 Is there a SlugOS combo that's supposed to build atm? Nov 17 22:07:14 Tartarus: the testing page has some Nov 17 22:07:26 nslu2le/be slugos slugimage iirc Nov 17 22:07:34 ah right Nov 17 22:07:35 calling it a day, cya all tomorrow & have fun! Nov 17 22:07:38 later Nov 17 22:18:56 khem, please: sed -i -e 's/diretory/directory/g' conf/local.conf.sample && git commit -s -m 'local.conf.sample: commentary typo fixc' && git push -v --thin Nov 17 22:19:01 khem, TIA Nov 17 22:19:28 drats Nov 17 22:19:35 khem, please: sed -i -e 's/diretory/directory/g' conf/local.conf.sample && git commit -s -m 'local.conf.sample: commentary typo fix' && git push -v --thin Nov 17 22:19:57 (fixes typo in commit message of commentary typo fix of sample conf ;) Nov 17 22:20:07 https://spreadsheets.google.com/ccc?key=0AhY8lmfkCabTdFlPQ1ozR2ZNM0Z4ckpLZ3VOLVE2dnc&authkey=CKy8lbkH#gid=0 Nov 17 22:20:12 vmstat graph Nov 17 22:20:24 ka6sox-work: ^^ Nov 17 22:23:04 blindvt: thx will do Nov 17 22:23:50 khem, i'm starting from a pristine clone now. Let's see how far i get.. Nov 17 22:25:21 blindvt: fantastic. Nov 17 22:25:29 blindvt: how is life ? Nov 17 22:25:47 blindvt: geared enugh for a uclibc release yet? Nov 17 22:26:05 khem, pfff. This one was a pretty bad year in RL for me Nov 17 22:26:41 blindvt: I understand Nov 17 22:28:50 khem, as to a release: a 1.0 would only warrant a full SUSv4 audit and while i've started to add an automated API checker to the testsuite, i have a much improved version of that checker lying around here. Note, however, that i didn't really start to _check_ nor improve our POV wrt SUSv4, so a 1.0 is not really realistic soonish. We could talk about the 0.9.32 though (or any backports that would warrant a 0.9.31.x) Nov 17 22:29:49 hmm Nov 17 22:30:01 Isn't gobject-introspection stuff supposed to be disabled? Nov 17 22:30:15 SUSv4? hmm Nov 17 22:37:18 blindvt: ok .32 is fine too Nov 17 22:37:26 blindvt: I want nptl out of door Nov 17 22:37:48 and it will be first version with nptl so .32 is fine as it crystalizes Nov 17 22:37:56 we can have 1.0 release Nov 17 22:38:33 khem, thing is that we (as in NPTL) currently break horrible with gcc trunk since somebody had the bright idea to DCE some of our strong aliases Nov 17 22:39:15 khem, 4.6 is not yet released but we will have to sort that out rather soon, given the schedule of 4.6.0 Nov 17 22:40:56 khem, there are a couple of minor outstanding hunks that beg for consideration, like the ldd tracer strip patchlet that was sent to the ML and maybe a few other bits that i don't remember offhand Nov 17 22:47:28 ok. i'll send the ext4 image stuff tomorrow. Nov 17 22:47:38 g'night, all! Nov 17 22:51:12 03Yuri Bushmelev  07master * r1a9d655a29 10openembedded.git/recipes/ (ltrace/ltrace_0.5.3.bb tasks/task-cli-tools.bb): ltrace: exclude from build for SH3/SH4 targets Nov 17 22:52:55 hm.. Nov 17 23:00:25 blindvt: 4.6.0 should happen next year Nov 17 23:00:34 blindvt: we worry about it then Nov 17 23:01:35 blindvt: honestly uclibc has been neglected on my part for past few months Nov 17 23:02:21 should I check Archived checkbox in patchwork? Nov 17 23:02:24 what this mean? Nov 17 23:06:41 Jay7: yes its stored Nov 17 23:07:04 hey khem Nov 17 23:08:08 applied then Nov 17 23:09:13 ant__: hi Nov 17 23:09:56 angstrom-eglibc for armv5te has just built fine Nov 17 23:10:12 we should really move to eglibc per default Nov 17 23:10:36 I'll compare the sizes Nov 17 23:10:42 03Khem Raj  07master * reb6a1aa091 10openembedded.git/recipes/linux/ (3 files in 2 dirs): Nov 17 23:10:42 linux-efikamx: Fix the existing 2.6.31 recipe to use lower case letter in package name Nov 17 23:10:42 * Use upstream Amit's branch for git recipe Nov 17 23:10:42 Signed-off-by: Khem Raj Nov 17 23:10:48 * Tartarus curses, quite loudly, scripts that do @python@, @perl@ and so forth Nov 17 23:10:49 ant__: angstrom-2010 uses eglibc by default already Nov 17 23:10:53 03Khem Raj  07master * ra6e303aed1 10openembedded.git/recipes/eglibc/ (eglibc_2.11.bb eglibc_2.12.bb eglibc_svn.bb): Nov 17 23:10:53 eglibc_2.11/eglibc_2.12/eglibc_svn: Upgrade to latest SVN tip Nov 17 23:10:53 Signed-off-by: Khem Raj Nov 17 23:10:55 03Bernhard Reutner-Fischer  07master * rd53f2eaae3 10openembedded.git/conf/local.conf.sample: Nov 17 23:10:55 local.conf.sample: commentary typo fix Nov 17 23:10:55 Signed-off-by: Bernhard Reutner-Fischer Nov 17 23:10:55 Signed-off-by: Khem Raj Nov 17 23:10:57 03Khem Raj  07master * rf5c7beb6f5 10openembedded.git/conf/distro/minimal.conf: Nov 17 23:10:57 minimal.conf: Pin QT version to 4.7.0 Nov 17 23:10:57 Signed-off-by: Khem Raj Nov 17 23:10:59 03Tim Harvey  07master * r2c2013c90f 10openembedded.git/recipes/nuttcp/ (nuttcp/nuttcpd.init nuttcp_7.1.3.bb): Nov 17 23:10:59 nuttcp: new recipe Nov 17 23:10:59 Signed-off-by: Tim Harvey Nov 17 23:10:59 Signed-off-by: Khem Raj Nov 17 23:11:01 03Graham Gower  07master * rec8e3903c1 10openembedded.git/conf/distro/include/sane-toolchain.inc: Nov 17 23:11:01 sane-toolchain.inc: remove duplicate line. Nov 17 23:11:01 Signed-off-by: Graham Gower Nov 17 23:11:01 he..I'm working on 'stable' ;) Nov 17 23:11:08 khem: Are you sure gcc 4.4.4 + powerpc breaks? Nov 17 23:11:13 Tartarus: yes Nov 17 23:11:14 I didn't get that same fatal error Nov 17 23:11:21 At least no quite so quick, but k Nov 17 23:11:26 Want me to re-sub? Nov 17 23:11:29 Tartarus: err Nov 17 23:11:30 Or just update Nov 17 23:11:49 Tartarus: update add my sign-off and push Nov 17 23:12:11 Tartarus: better you push today tomorrow we will have another test branch Nov 17 23:12:19 yeah Nov 17 23:12:29 Jay7: now efikamx kernel should build fine Nov 17 23:12:34 Jay7: try that out Nov 17 23:12:42 Need to, ahem, bitchslap gobject-introspection real quick too Nov 17 23:13:12 khem: still I'm tempted by uclibc..how is the NPTL status? Nov 17 23:13:22 two more bike rides to work and then I have 20 dollars gift card Nov 17 23:13:27 have you unified the recipes? Nov 17 23:13:39 khem: thanks, I'll restart efika builds this night Nov 17 23:13:42 ant__: it is or was good last time I did stuff Nov 17 23:14:17 ant__: arm/ppc/mips/sh/x86/x86_64 support nptl and seem to work to some extent Nov 17 23:14:23 iirc uclibc-git was needed for nptl Nov 17 23:14:44 ant__: yes the reason for that is because there is no uclibc release yet with nptl Nov 17 23:14:56 oh, I see... Nov 17 23:14:57 soon we may have .32 Nov 17 23:15:07 then that will be first official nptl release Nov 17 23:18:47 03Camille Moncelier  07master * rcf67dc1bb1 10openembedded.git/recipes/dropbear/ (dropbear.inc dropbear/default): Nov 17 23:18:47 dropbear: Removed openmoko references. Added /etc/default/dropbear Nov 17 23:18:47 Signed-off-by: Camille Moncelier Nov 17 23:18:47 Signed-off-by: Khem Raj Nov 17 23:22:11 03Maksym Parkachov  07master * r04531031ee 10openembedded.git/recipes/mcpp/ (mcpp.inc mcpp_2.7.2.bb): Nov 17 23:22:11 mcpp: added new recipe for version 2.7.2 Nov 17 23:22:11 * created .inc file for both target and native version Nov 17 23:22:11 * added version 2.7.2 Nov 17 23:22:11 Signed-off-by: Maksym Parkachov Nov 17 23:22:11 Signed-off-by: Khem Raj Nov 17 23:23:29 khem: can you please take a look at my patch to pkgconfig.bbclass and ack or nak it? http://patchwork.openembedded.org/patch/3427/ Nov 17 23:24:33 it's a build fix, but not many people seem to care Nov 17 23:24:39 obi: patch looks sane to me Nov 17 23:25:03 let me pull it into my tree where I will launch a clean build now Nov 17 23:25:07 The .pc one? Nov 17 23:25:10 thanks Nov 17 23:25:12 What is broken today? Nov 17 23:25:13 obi: do u have patches pending on this patch Nov 17 23:25:15 Tartarus: yes Nov 17 23:25:31 03Tom Rini  07org.openembedded.dev * r4e5f9e1010 10openembedded.git/conf/distro/include/ (sane-toolchain-eglibc.inc sane-toolchain-glibc.inc): Nov 17 23:25:31 sane-toolchain-*glibc.inc: Use -O2 on PowerPC Nov 17 23:25:31 In FULL_OPTIMIZATION use -O2 on powerpc due to some problems Nov 17 23:25:31 with libgcc.a and -Os when using gcc 4.5.x. Nov 17 23:25:31 Signed-off-by: Tom Rini Nov 17 23:25:32 Acked-by: Khem Raj Nov 17 23:25:54 khem: no, but i will create a new overlay which depends on this patch Nov 17 23:26:18 khem: Bah Nov 17 23:26:24 didn't update commit msg, did update comment Nov 17 23:26:35 Tartarus: thats ok :) Nov 17 23:26:45 Tartarus: well, it's described in the commit: Nov 17 23:26:48 comment is more important Nov 17 23:26:49 "* .pc files must be installed explicitly to avoid causing Nov 17 23:26:50 build problems. E.g. libsoup-2.4-gnome.pc must not be Nov 17 23:26:50 installed if libsoup-2.4 is built without gnome support, Nov 17 23:26:50 because gstreamer would try to link against libsoup-2.4-gnome." Nov 17 23:27:12 obi: That makes more sense with your overlay msg above Nov 17 23:27:13 today, pkgconfig.bbclass does a recursive search for *.pc and installs every file it can find Nov 17 23:27:14 Which isn't :) Nov 17 23:28:47 actually, it depends on the packages you want to use Nov 17 23:29:07 hehe.. opie-notes fails to build by gcc-4.5 Nov 17 23:29:16 as I understand at least Nov 17 23:29:41 it builds ok for angstrom but fails for minimal Nov 17 23:29:48 Jay7: lot of opie recipes dont build with gcc 4.5 Nov 17 23:30:09 there was a new release coming I guess which is more modern C++ Nov 17 23:30:14 Tartarus: there are many .pc files, which don't get installed, due to configure not finding some library or another. if another configure script then checks for that package, it will fail to build or link Nov 17 23:30:16 chances of that working is better Nov 17 23:30:30 so, opie-image cant be built for minimal distro Nov 17 23:30:40 I think using standard install for .pc files is sufficient Nov 17 23:31:16 * Jay7 is thinking how to describe this better on testing page.. Nov 17 23:31:48 well, angstrom isn't gcc 4.5 is it? :) Nov 17 23:33:38 Tartarus: angstrom-2010 is Nov 17 23:34:18 but i think angstrom is more and more geared to ARM these days Nov 17 23:35:40 Jay7: whats the error Nov 17 23:35:50 http://tinderbox.openembedded.net/public/logs/task/10238054.txt Nov 17 23:36:18 khem: angstrom have similar messages but as warnings and for other files Nov 17 23:37:10 an, ant__ pointed me to warnings for mainwindow.cpp too Nov 17 23:37:53 yep, only warningswith old gcc Nov 17 23:38:23 btw, other problem of oestats - you can't return from log view to build view Nov 17 23:38:52 I should collect this somewhere in preparation for oestats-next :) Nov 17 23:39:30 khem: http://pastebin.ca/1995077 Nov 17 23:40:10 he..O2 vs. Os too Nov 17 23:40:34 we need runtime testers :p Nov 17 23:41:16 Jay7: yeah I have seen that error. Its a warning from newer compilers Nov 17 23:41:30 Jay7: I have fixed few things in OE to shush this warning Nov 17 23:41:37 but was not interested in opie Nov 17 23:42:51 ant__: that code needs to be fixed Nov 17 23:43:31 yes, starts to bitrot Nov 17 23:45:48 opie does not have any momentum Nov 17 23:46:40 angstrom is "geared" to what people ask for and work on Nov 17 23:46:59 03Tom Rini  07org.openembedded.dev * r8d906dfca2 10openembedded.git/recipes/gobject-introspection/ (2 files in 2 dirs): Nov 17 23:46:59 gobject-introspection: Use /usr/bin/env for python Nov 17 23:47:00 Scripts that do #!@PERL@ or #!@PYTHON@ and replace that with Nov 17 23:47:00 a full path are in danger of breaking in certain environments Nov 17 23:47:00 (such as some autobuilders) and should instead use /usr/bin/env. Nov 17 23:47:00 While in here, use GNOME_MIRROR for the sources. Nov 17 23:47:01 Signed-off-by: Tom Rini Nov 17 23:49:38 well.. Nov 17 23:49:46 * Jay7 have updated Testing page.. Nov 17 23:49:49 Crofton: Opie happens to produce small working images, though severely outdated Nov 17 23:50:05 it attracts more users to #oe Nov 17 23:50:09 ;) Nov 17 23:50:13 * usable images :) Nov 17 23:50:34 sure Nov 17 23:51:00 but is outdated Nov 17 23:51:06 and hard to keep up in dev Nov 17 23:51:18 well, yes and not Nov 17 23:51:26 bluelightning is doing miracles Nov 17 23:51:33 very useful to use on outdated hardware :) Nov 17 23:52:16 still, two core recipes with legacy staging need love... Nov 17 23:53:05 it would be great to remove legacy staging before release.. Nov 17 23:53:10 but seems too late now Nov 17 23:53:30 * ant__ thought about giving 'sugar' distro to his 3yrs old kid... Nov 17 23:53:42 while I thought he stole my iphone Nov 17 23:53:46 :/ Nov 17 23:54:02 that's about ease of use Nov 17 23:54:23 Testing page source is about ease of use :\ Nov 17 23:54:36 even for me already.. Nov 17 23:55:01 I'm thinking about splitting table by distro Nov 17 23:55:14 or by machines Nov 17 23:55:26 he..we come back to the damned matrix Nov 17 23:55:36 google form :) Nov 17 23:55:42 yeah.. Nov 17 23:55:47 And that was essentially the point I was trying to make Nov 17 23:55:55 Did my first builds and report the other week Nov 17 23:56:06 And yeah, I wanted to improve the wiki part Nov 17 23:56:09 since it was kinda painful Nov 17 23:56:25 dokuwiki tables syntax is more elegant... Nov 17 23:56:39 but with such big table it will suxx anyway Nov 17 23:57:01 anything without actually 90% working graphical editing is a pain Nov 17 23:57:15 And then it's just a slightly different pain :) Nov 17 23:57:45 can mediawiki use FCKeditor or TinyMCE? Nov 17 23:57:54 both have tables support iirc Nov 17 23:58:08 my drupal and typo3 installations have it at least Nov 18 00:04:41 btw, any idea about this recuyrrent notes? Nov 18 00:04:43 cp: cannot stat `/oe/build/tmp/work/i686-linux/stagemanager-native-0.0.1-r15/sysroot-destdir//oe/build/tmp/*': No such file or directory Nov 18 00:05:09 this is first occurrence Nov 18 00:05:10 it's still vaugely on my list to work out Nov 18 00:05:24 long standing issue Nov 18 00:05:42 other is the 'inherit gettext' Nov 18 00:05:51 khem: I've started minimal/efikamx/console-image build Nov 18 00:06:09 well, Missing inherit gettext? Nov 18 00:07:00 Tartarus: note the double slash Nov 18 00:07:41 and all those 'cp:cannot...' msgs refers to a glob Nov 18 00:09:05 ok, time to sleep Nov 18 00:09:11 Tartarus: you know what? this (stagemanager-native) is the only 'cp: cannot' left in my eglibc build Nov 18 00:09:22 log Nov 18 00:10:27 'nite Jay7 Nov 18 00:14:42 Jay7: cool ok Nov 18 00:34:10 Strange. bitbake has taken to freezing when building anything on "NOTE: Resolving any missing task queue dependencies", unless I blow away TMPDIR every time. Has anyone else seen that sort of thing before? Nov 18 00:37:29 xobs: what are you trying to build ? Nov 18 00:38:36 khem: Currently I'm trying to get perl to build, but it keeps failing. So I thought I'd clean perl-native by running "bitbake perl-native -c clean" Nov 18 00:38:47 Oh son-of-a... Nov 18 00:39:07 Can we push recipes to just build help2man and A_P it out in the local.conf.sample? Nov 18 00:40:19 xobs: do u have anything in ASSUME_PROVIDED ? Nov 18 00:40:20 khem: Oh, okay. This is why you shouldn't leave a problem halfway through fixing it. perl-native was added to ASSUME_NATIVE in an attempt to fix the problem. Nov 18 00:40:29 khem: Good call :) Nov 18 00:40:59 xobs: yes thats a known behavior. Nov 18 00:42:09 Tartarus: help2man ? you mean help2man-native or target package Nov 18 00:42:18 -native Nov 18 00:42:46 Got one handy but it's not quite up to current standards of virtclass-native and BBCLASSEXTEND Nov 18 00:42:49 it's just -native Nov 18 00:43:08 * Tartarus will kick this harder tomorrow and just miss the tag probably Nov 18 00:54:54 Or tonight, heh Nov 18 01:10:22 So.. acks? ;) **** ENDING LOGGING AT Thu Nov 18 02:59:58 2010