**** BEGIN LOGGING AT Thu Sep 27 02:59:57 2012 Sep 27 06:59:53 good morning... :) Sep 27 07:01:33 So, am I the only one having "ncurses" errors when building core-image-minimal? on the newest rev of oe-core? **** ENDING LOGGING AT Thu Sep 27 08:14:33 2012 **** BEGIN LOGGING AT Thu Sep 27 08:16:20 2012 Sep 27 08:26:36 Qw_freak: I have been seeing QA issues when building ncurses Sep 27 08:27:01 Qw_freak: I also had to -c cleansstate to get it to build the other day when it was complaining about a needing to be reconfigured Sep 27 09:00:19 morning all Sep 27 09:00:38 yeah, that ncurses thing just happened to me now, and someone mentioned it on the mailing list last night Sep 27 09:00:45 as you say, -c cleansstate seems to sort it out Sep 27 09:20:25 pb_: hi Sep 27 09:23:44 pb_: about modules and related files installed in rootfs, there is not only kernel.bbclass to check, I think the code in image.bbclass at #216 does run depmod after a lazy check Sep 27 09:25:01 pb_: and btw about update-modules it seems nowaday kmod can actually cope with systemd and udev. Sep 27 09:28:18 hi ant_work Sep 27 09:28:36 yeah, I think that's probably all true Sep 27 09:30:59 hi pb_, ant_work, all Sep 27 09:31:57 hi bluelightning Sep 27 09:32:55 * pb_ nearly finished epic oe-core update, phew Sep 27 09:35:37 does anybody know why the clutter recipe is named "clutter-1.8" rather than just "clutter"? Sep 27 09:37:53 pb_: the idea was that we could support multiple versions of clutter since the API is apparently not compatible between releases Sep 27 09:39:36 ah, fair enough. it seems that clutter-1.8 does actually provide "clutter-1.6" so I assume those two were compatible, but maybe 1.10 isn't. Sep 27 09:39:43 does the same thing go for cogl as well or does that one have a stable api? Sep 27 09:44:47 I think that might be in a similar situation, the two projects are closely linked Sep 27 09:45:20 yeah, that's sort of what I suspected. the cogl recipe isn't namespaced in the same way that clutter is, but maybe this is an oversight. Sep 27 09:46:07 possible; I can confer with some of the cogl developers if you like, they're in the same office as me Sep 27 09:49:50 might be worth finding out if you happen to be talking to them, yeah Sep 27 09:50:37 ok will do Sep 27 09:50:42 but I guess it's not a pressing issue right now; I assume there's no point in me sending patches to update the cogl/clutter versions since they have presumably zero chance of getting merged at the moment Sep 27 09:51:00 and, as long as the versions stay the same, the cogl namespacing doesn't really matter Sep 27 09:51:21 yeah I think we'd probably want to hold off on any package updates at the moment unless absolutely necessary Sep 27 09:52:32 that said, JaMa has just sent some Qt updates, I'm not sure what to do with them to be honest... Sep 27 09:52:52 yeah, that's fine. I need a newer clutter locally, but I don't need to support multiple versions in parallel so again the namespacing doesn't bother me particularly. Sep 27 09:53:32 hello Sep 27 09:54:57 though, I just noticed that clutter-1.8 doesn't actually build successfully so I guess nobody is using it :-} Sep 27 09:55:16 we do definitely build it regularly on the autobuilder... Sep 27 09:55:34 it's included in core-image-sato I think and that's one of the images we build as a matter of course Sep 27 09:55:50 oh, that's strange. I wonder why you don't see the error. Sep 27 09:55:59 I get: Sep 27 09:56:00 ERROR: clutter-examples is listed in PACKAGES multiple times, this leads to packaging errors. Sep 27 09:56:27 and, sure enough, it is. clutter-1.8_1.8.4.bb adds it to PACKAGES, and also includes clutter-package.inc which does the same thing Sep 27 09:56:40 in fact, this is _all_ clutter-package.inc does, heh Sep 27 09:58:53 hi hrw Sep 27 10:03:51 hm, we should try to find a way to make the clutter/cogl recipes a bit less x11-centric as well Sep 27 10:04:07 the weird thing is it just built successfully here Sep 27 10:04:55 that is weird Sep 27 10:05:21 I'm pretty sure the duplicate entry in PACKAGES is not because of any local change I did Sep 27 10:05:23 oh, I see what's happened Sep 27 10:05:32 PACKAGES="clutter-1.8-examples clutter-examples clutter-1.8-dbg clutter-1.8-staticdev clutter-1.8-dev clutter-1.8-doc clutter-1.8-locale clutter-1.8" Sep 27 10:05:37 fail... Sep 27 10:05:53 oh, heh Sep 27 10:06:37 yes, you're right, clutter-package.inc uses "clutter-examples" verbatim, whereas clutter-1.8_1.8.4.bb uses "${PN}-examples" Sep 27 10:06:50 did you override PN somehow? Sep 27 10:07:17 yeah, I did, that was what led to my original question about why it had the -1.8 in there. Sep 27 10:07:26 aha, the loop is closed :) Sep 27 10:07:30 I hadn't noticed that the two files were using slightly different things for PACKAGES Sep 27 10:07:37 yeah, right, local error on my part after all Sep 27 10:07:50 well sort of, it's exposed brokenness in the recipes as well Sep 27 10:09:24 how to make SRC_URI entry to be cloned into other dir then 'git'? Sep 27 10:18:05 hrw: add ;destsuffix=somedirname Sep 27 10:18:19 thanks Sep 27 10:24:34 grr, build failure in cally-atktext-example.c again Sep 27 10:25:02 I'm sure I must have patched that file about 15 times in the past few weeks but I seem to keep losing the change. Sep 27 10:26:03 * pb_ fixes it again Sep 27 10:37:32 hm, this is rather weird, my nfsroot recipe has suddenly started depending on a load of nativesdk stuff. Sep 27 10:37:35 I wonder how that happened. Sep 27 10:43:22 ah Sep 27 10:43:29 NOTE: multiple providers are available for runtime libclutter-1.0-examples (eglibc, nativesdk-eglibc, clutter) Sep 27 10:43:37 I think that's what's known as an epic eglibc fail Sep 27 10:43:40 ???!!! Sep 27 10:43:58 bluelightning: eglibc has PACKAGES_DYNAMIC = "libc6*" Sep 27 10:44:12 which, apparently, was written by someone who doesn't understand how regexps work Sep 27 10:44:32 (though, even leaving that aside, it's fairly hard to imagine how that particular regexp can have seemed like a good idea) Sep 27 10:44:48 I'm not sure it's meant to be a regex Sep 27 10:45:00 I'm pretty sure bitbake matches it as one Sep 27 10:45:17 at least git grep shows that most examples we have treat it as a glob and not a regex Sep 27 10:45:33 in fact it's not most, it's all Sep 27 10:45:46 ah, that's interesting. let me do a little experiment with bitbake then. Sep 27 10:48:16 yeah, bitbake definitely seems to treat it as a regex and not a glob Sep 27 10:49:28 if I set PACKAGES_DYNAMIC = "abc*d" then bitbake will match it for RDEPENDS = "abccccccccccd" or "abd", but not for "abced". Sep 27 10:58:49 So, Everytime I try to bake "meta-toolchain-qte, " Perl ruins my build by doubleing the @DESTDIR@ path sequence like: /home/qw/OE/build/tmp-eglibc/work/i686-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/image/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/perl..... anybody know anything about that? Sep 27 11:02:10 in fact, you can tell even more easily that it's a regex: if you set PACKAGES_DYNAMIC = "a**" then you get a python stack trace and a diagnostic about an invalid regular expression :-) Sep 27 11:02:29 pb_: how can the current usage be valid then? Sep 27 11:02:57 well, it so happens that if you write a glob and treat it as a regex it will usually do more or less what you wanted. Sep 27 11:03:40 so, PACKAGES_DYNAMIC = "perl-module-*" will match anything which starts with "perl-module" followed by zero or more dashes Sep 27 11:04:12 pb_: ah, right, so partial matches are obscuring the issue then? Sep 27 11:04:23 and the desired outcome is presumably that it matches things like "perl-module-obfuscator" which do happen to conform to that pattern Sep 27 11:05:02 right, none of the regexp matches are anchored at the end so it will always match on a prefix Sep 27 11:05:10 I don't think this is right, we ought to be using a glob here and not a regex IMO - that's what is expected Sep 27 11:05:21 presumably this has been this way for a long time Sep 27 11:06:50 presumably. afaik, bitbake has always been like this, and I think it's probably true as well that the erroneous PACKAGES_DYNAMICses have been there for ages too Sep 27 11:08:12 right, I guess nobody noticed... Sep 27 11:08:44 http://osdir.com/ml/sysutils.bitbake.devel/2006-01/msg00004.html does sort of suggest that PACKAGES_DYNAMIC was conceived originally as a regex Sep 27 11:09:28 though, even in this case, RP seems a bit confused since he does also give "kernel-module-*" as an example of what one might set it to Sep 27 11:10:56 hmm Sep 27 11:14:14 anyway, the PACKAGES_DYNAMIC in eglibc seems bogus by any measure since I don't think it actually builds any packages whose names start with "libc6" apart from PN/-dbg/-dev. Sep 27 11:15:23 right, an old relic perhaps? Sep 27 11:15:39 yeah, I traced it back as far as eglibc_2.12 before I lost the will to live Sep 27 11:17:02 heh Sep 27 11:17:47 bit of a sad state of affairs, well done for catching an analysing it Sep 27 11:17:55 s/an/and/ Sep 27 11:21:53 yeah, a bit sad indeed Sep 27 11:31:43 so, it turns out you can't just delete the PACKAGES_DYNAMIC from eglibc.bb because then you lose in another way. setting it to "" appears to be the right thing. Sep 27 11:44:47 well, patch sent, let's see what the appropriate authorities have to say about that Sep 27 11:46:17 *g* Sep 27 11:47:12 "missing PR bump" probably :-} Sep 27 11:47:51 yeah Sep 27 11:47:54 classic Sep 27 11:56:18 pb_: so the whole bunch of P_D is working by pure luck :) Sep 27 11:56:48 more or less, yeah Sep 27 12:01:58 oh, well, now I remember I have to adapt P_S to add extra deps for the klibc-shared utils...there was some issue with that as well... Sep 27 12:04:48 ah, yes, a corner case :] Sep 27 12:05:11 -- extra runtime dependencies (RDEPENDS) to be set for Sep 27 12:05:11 all packages. The default value of None causes a Sep 27 12:05:11 dependency on the main package (${PN} Sep 27 12:05:39 so if you try to set it none thinking none==none you get $PN ;) Sep 27 12:06:49 - if you do Sep 27 12:06:49 not want this, pass '' for this parameter. Sep 27 12:07:04 ah yes Sep 27 12:07:15 possibly not a very well designed API that one Sep 27 12:07:44 package.bbclass #97 for the casual (?) reader Sep 27 12:07:57 that do_split_packages() thing might well be one of the oldest pieces of unmodified code that we still have in current oe :-} Sep 27 12:09:52 I note in passing that some of the eglibc packages have apparently been "singed off" Sep 27 12:10:04 ^_^ Sep 27 12:10:04 s/packages/patches/ Sep 27 12:10:56 oe devs singing in shower... Sep 27 12:12:47 ah, I was thinking more of oe devs being careless with fire Sep 27 12:13:00 but yes, that is also a plausible interpretation Sep 27 12:13:04 ok, new question - how to say where to apply patch from SRC_URI? I have two git trees and need to patch second one Sep 27 12:28:14 ok, gave up - will apply patch by hand in recipe or use sed Sep 27 12:30:10 last attempt did that. but patch has "../" as start of path... Sep 27 12:38:39 drat, need newer libsoup Sep 27 12:38:39 hrw: does patchdir + striplevel not help? Sep 27 12:39:38 used striplevel=0 and "../dirname/Makefile" in patch Sep 27 12:40:56 hmm, patchdir should be able to apply it anywhere AFAICT Sep 27 12:42:01 maybe, but this version works and I do not like to wait when bitbake decides to unpack whole kernel git tarball just because I changed recipe a bit (which is nice on other occassions) Sep 27 13:05:04 pb_: so apparently the namespacing for clutter was useful back in the 0.8 days, but now it's probably not necessary Sep 27 13:05:47 pb_: I suspect rburton may be updating clutter in the next cycle Sep 27 13:06:13 well, i suspect i'll be merging patches from collabora to do that :) Sep 27 13:06:50 rburton: ah right :) Sep 27 13:22:07 hrw: how come the kernel arch isn't aarch64, do you know? Sep 27 13:23:05 bluelightning: long discussion on lkml Sep 27 13:23:16 hrw: basically they didn't like the name? Sep 27 13:23:21 sort of Sep 27 13:23:29 ok Sep 27 13:23:45 kind of 'its just arm right? so its like was with x86?' etc Sep 27 14:01:05 So, I found a very bad error in the native-perl_5.14.2.bb script.. Where do I go with this? Sep 27 14:01:13 So, I found a very bad error in the native-perl_5.14.2.bb script.. Where do I go with this? Sep 27 14:02:19 --- perl-native_5.14.2.bb Sep 27 14:02:27 not native-perl_5.14.2.bb Sep 27 14:07:48 morning Sep 27 14:15:04 Qw_freak: the mailing list, I suppose Sep 27 14:16:39 i have a kernel module Makefile that install some Makefile on the system /usr/include, is it ok to install those files in the sysroot /usr/include and sysroot /kernel ? Sep 27 14:16:52 that install some headers*, sorry Sep 27 14:17:16 pb_ : Okay, I will try that... Sep 27 14:21:50 heh, a rare example of the kernel people demonstrating good taste :-) Sep 27 14:22:06 bluelightning: okay, very good, thanks Sep 27 15:00:22 new arch port shows nice bugs in recipes ;) Sep 27 15:01:59 i think this whole sdk business is going to drive me insane Sep 27 15:02:36 after fixing many dependency failures, i'm now stuck at rpm who wants to biuld rpm-python but refuses to use the python provided in the sdk but instead uses some other python that i have no clue where it comes from Sep 27 15:03:19 from your system ? :p Sep 27 15:03:41 it could comes from a python2.6-config's output Sep 27 15:03:43 no something from build/blablablabla/somewhere/random/other/bla Sep 27 15:03:49 ah Sep 27 15:04:07 lol Sep 27 15:04:11 nice PATH anyway Sep 27 15:04:31 build/tmp-eglibc-eglibc/sysroots/x86_64-linux/ Sep 27 15:04:34 to be more precise :) Sep 27 15:05:12 i mean.. when i set OECORE_NATIVE_SYSROOT from the sdk environment-setup script, isn't it supposed to use that? Sep 27 15:12:45 gmc: if this is a result of you still you going down the route of using an external toolchain to not rebuild native tools, you can expect those kinds of issues... Sep 27 15:13:22 well i've given up on including automake and all Sep 27 15:13:28 but apparently including python is bad too? Sep 27 15:14:05 perhaps i'm misunderstanding the concept of sdk in oe-core ? Sep 27 15:14:57 gmc: we provide the SDK so that people can use it external to the build system to build applications Sep 27 15:15:21 gmc: we don't support using the SDK as an external toolchain to bypass building native tools Sep 27 15:15:42 ah.. well, that part i didn't get yet... wish i had known earlier :) Sep 27 15:15:45 sorry I don't mean to sound rude... Sep 27 15:16:10 same here.. just kinda frustrated about it all :) Sep 27 15:16:16 the thing is we do provide a solution to rebuilding all of the native tools every time as I mentioned yesterday Sep 27 15:16:18 really appreciate all the help i've gotten here Sep 27 15:16:23 yep sstate Sep 27 15:16:55 although i thought that was mostly for the autotools stuff, didn't think that it would apply to everything Sep 27 15:17:11 yes, it does - it even helps with avoiding rebuilding things for the target if they haven't changed, so it's a much better solution overall Sep 27 15:17:43 it's just a tad bit more complicated to the average casual devver than installing a .deb and go :) Sep 27 15:18:03 from a user perspective it should be pretty easy Sep 27 15:18:36 you don't have to understand the mechanics most of the time, it will just activate when it can Sep 27 15:19:08 ok, that's true.. it'll just download the sstate entries i guess Sep 27 15:19:37 gmc: well, you don't have to do that either - just run the build once, then you already have them in your sstate-cache Sep 27 15:20:02 gmc: either preserve that, or you can move that to another (possibly remote) location and point to it with SSTATE_MIRRORS Sep 27 15:20:15 that's all you should need to do Sep 27 15:21:14 yes ok, but if I built them once, i have them.. not my peers, so they would need to either copy mine manually or get them from the mirror Sep 27 15:23:41 gmc: right, your peers would also set their SSTATE_MIRRORS in the same way, and the system will download the sstate packages as needed Sep 27 15:25:22 the thing that worries me then, is that when they change something (perhaps by accident), their build environment will go out of sync with the 'golden' build env Sep 27 15:27:39 what kind of change do you mean? Sep 27 15:28:08 any.. that would lead to the hash of the input to change and thus require for eg the cross-compiler to be rebuilt Sep 27 15:29:06 gmc: if the system did not behave like that then it would become "out-of-sync" with the metadata... Sep 27 15:29:36 bluelightning: what about adding 4.8.3 with negative D_P? Sep 27 15:29:38 yes, i understand that.. from the oe-core point of view that's fine Sep 27 15:29:57 bluelightning: or at least merging only the 4.8.1 cleanup at least? Sep 27 15:30:02 but if you look at it from a software development view, where you want to provide a build environment that doesn't change, it's less logical Sep 27 15:31:11 gmc: the question is what inputs do you think people will legitimately change that will trigger this? Sep 27 15:31:32 JaMa: why does it have to be now and not later? Sep 27 15:32:06 JaMa: by all means, make a case and we can consider it Sep 27 15:32:08 well, that's the thing.. it doesn't matter whether it is legitimate or not, the point is that they can (either on purpose or without realizing it) change things that change the build environment Sep 27 15:34:19 gmc: so I'm finding it a bit hard to understand without specifics Sep 27 15:36:03 bluelightning: the cleanup is formal only, so with low risk and I have some layer with .bbappends to it which needs 4.8.3 (or 4.8.2) so recipe even with negative D_P would help me to be able to use next release Sep 27 15:37:29 gmc: if you go down the route you're going down not only is it difficult to get working, but I think you're also potentially setting yourself up for subtle and hard-to-debug issues Sep 27 15:37:33 gmc: e.g. a bug has been fixed in one of the things you're hard-building and that fix is not reflected in your environment as it should be Sep 27 15:39:52 JaMa: so please make a case in your reply, ultimately it's not up to me; but I feel uncomfortable about the limited time we have left for testing such changes Sep 27 15:50:51 bluelightning: it'll be reflected in the golden build env eventually Sep 27 15:51:12 i'm still trying to wrap my head around it myself.. but say someone accidently changes the abi or the libc or some nitty gritty arm tuning setting somewhere Sep 27 15:51:30 his/her toolchain gets rebuilt and along with that everything else Sep 27 15:52:40 and then things start to break somehow.. but it still works for everyone else Sep 27 15:53:11 so by allowing them to change their build environment, you introduce extra variables into the debugging process Sep 27 15:55:20 btw, for my understanding.. when working in oe-core, should i disregard the entire openembedded.org site and docco and consider the yoctoproject manuals as leading? Sep 27 15:56:42 gmc, probably a good idea Sep 27 15:56:55 you could also edit the website :) Sep 27 15:57:13 i would if i felt confident enough i understood all the complexity :) Sep 27 15:58:06 gmc: well, the upload to the mirror location is a manual step, so the accidental change would be limited to that one developer's machine Sep 27 16:00:20 yes, of course.. that's a good thing indeed Sep 27 17:26:21 Hello. Sep 27 17:31:59 grrrr... Sep 27 17:34:31 Right. Sep 27 17:34:38 Stupid liborc :( Sep 27 17:34:43 Does not want to compile. Sep 27 17:39:10 JaMa: Hi Sep 27 17:39:25 Your fix to xserver-xorg did not work Sep 27 17:39:35 http://dpaste.com/806909/ Sep 27 17:39:46 Does anyone have idea how to fix it? Sep 27 17:55:35 otavio: RP didn't apply 1/2 so it was missing PR bump Sep 27 17:55:43 otavio: have you tried to rebuild that manually? Sep 27 17:57:48 otavio: also see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030167.html Sep 27 17:59:11 JaMa: mine is build fine and conflicts looks fine ... but they do not install file Sep 27 17:59:18 JaMa: it raises a rootfs error Sep 27 18:03:14 JaMa: Sep 27 18:03:15 Package: xserver-xorg-module-exa Sep 27 18:03:15 Version: 2:1.11.2-r8 Sep 27 18:03:15 Conflicts: xserver-xorg (< 2:1.11.2-r8) Sep 27 18:03:24 So it looks alright Sep 27 18:03:27 BUT Sep 27 18:03:36 it fails to install Sep 27 18:04:08 Wouldn't be better to put it as a RDEPENDS (= EPV)? Sep 27 18:04:19 otavio: is this output from opkg status? Sep 27 18:04:32 dpkg -I Sep 27 18:04:36 in the package Sep 27 18:05:26 reading opkg source it seems it needs 2 spaces after < Sep 27 18:05:37 as it parses constraint as 3 characters Sep 27 18:05:41 ahahah Sep 27 18:05:47 OMG! Sep 27 18:05:57 but as you can see in my e-mail I've both installed and my do_rootfs does not fail Sep 27 18:05:58 It is better to fix opkg ;) Sep 27 18:07:03 JaMa: yes but it is strange. Sep 27 18:07:11 JaMa: are you testing in oe-core? Sep 27 18:07:30 where else? Sep 27 18:09:00 dunno if you have a patches opkg or something Sep 27 18:09:12 I am using poky Sep 27 18:09:21 but shouldn't matter Sep 27 18:10:41 yes my patches to opkg were already applied Sep 27 18:10:59 I'm testing with extra space if it fixes opkg status output I'll send it with PR bump Sep 27 18:11:08 Guys, no ideas? Sep 27 18:12:37 otavio: try http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/test&id=ee7cb6d8e07e1e6e8fc2327b11a6f3363eefa40c if you have time Sep 27 18:14:14 JaMa: testing Sep 27 18:16:57 JaMa: finishing the build Sep 27 18:18:06 JaMa: did not work Sep 27 18:18:22 JaMa: opkg has removed the extra space when building the package Sep 27 18:19:07 otavio: opkg or bb.utils.explode_dep_versions ? Sep 27 18:19:21 JaMa: no idea Sep 27 18:19:34 JaMa: but the built package did have a single space Sep 27 18:19:44 JaMa: I do think the right place to fix it is in opkg Sep 27 18:20:10 >>> bb.utils.explode_dep_versions('xserver-xorg (< 1.11.2)') Sep 27 18:20:10 {'xserver-xorg': '< 1.11.2'} Sep 27 18:20:10 >>> bb.utils.explode_dep_versions('xserver-xorg (< 1.11.2)') Sep 27 18:20:10 {'xserver-xorg': '< 1.11.2'} Sep 27 18:20:13 * otavio has no opkg background to look at it Sep 27 18:20:51 Package: xserver-xorg-module-exa Sep 27 18:20:52 Version: 2:1.11.2-r9 Sep 27 18:20:52 Conflicts: xserver-xorg (< 2:1.11.2-r9) Sep 27 18:23:31 can you use opkg status? Sep 27 18:26:30 you can see I have them both installed in the same image: https://github.com/shr-distribution/buildhistory/blob/jama/images/om_gta02/eglibc/shr-image/installed-packages.txt Sep 27 18:28:01 JaMa: I understand but how you want me to run opkg status if it is not built? Sep 27 18:28:07 JaMa: the rootfs fails Sep 27 18:29:13 you don't have feed? just opkg update and run opkg status on target Sep 27 18:29:36 JaMa: no; I am using it on yocto only... no feed Sep 27 18:30:15 did you try to build an image? update might work and rootfs generatil fail Sep 27 18:31:17 FFS! Sep 27 18:31:28 how do you think I got that buildhistory entry? Sep 27 18:32:23 you can check how many do_rootfs I've finished in last few days with this Sep 27 18:32:58 JaMa: OK; I am testing another way ... Sep 27 18:33:07 will post the patch soon if it works. Sep 27 18:33:14 try RCONFLICTS_${PN}-module-exa = "${PN} (<< ${EXTENDPKGV})" Sep 27 18:33:41 JaMa: I am testing RDEPENDS = Sep 27 18:34:05 and how should RDEPENDS help? Sep 27 18:34:22 it will make thinks works if anything Sep 27 18:34:48 http://paste.debian.net/193700/ Sep 27 18:34:52 s/works/worse/ Sep 27 18:34:52 This? Sep 27 18:36:19 JaMa: works like a charm Sep 27 18:36:21 :) Sep 27 18:37:33 Testing << now Sep 27 18:37:57 What the problem of using RDEPENDS the way above? Sep 27 18:40:30 Using << fails Sep 27 18:40:43 hey I'm having problems w/ perl since the patch wentin this morning (perl, not perl-native or nativesdk) Sep 27 18:40:50 anyone else having any issues? Sep 27 18:40:56 no Sep 27 18:41:05 fray: can you comment on my tune- RFC? Sep 27 18:41:26 the arm w/ optimization stuff? Sep 27 18:41:59 yes Sep 27 18:42:18 found it.. it's multilib.. if your lib dir is called 'lib64' it fails.. ugh Sep 27 18:42:27 ok.. give me about 10 minutes and I'll comment.. (I did read it over( Sep 27 18:42:43 ok thanks Sep 27 18:43:15 otavio: RDEPENDS with = VER could work, but have you tried upgrade path or just do_rootfs? Sep 27 18:43:33 JaMa: just rootfs Sep 27 18:44:11 I've tested upgrade path with opkg only when it was with RREPLACES.. all my targets are upgraded past that "dangerous" point since then.. Sep 27 18:48:02 JaMa: I sent the patch Sep 27 18:48:09 JaMa: give it a test please Sep 27 18:58:45 JaMa: ok sent.. let me know if you want something else Sep 27 19:01:56 fray: I didn't get the last part about OPTDEFAULTTUNE, but thanks anyway Sep 27 19:05:17 more or less, I don't really care.. it's easy to do in the distro file.. thats what I was trying to say.. Sep 27 19:05:30 sorry it's been a -really- long day and I've only been at work for 4 hours so far. :( Sep 27 19:12:54 fray: I don't think it's so easy in distro config (see reply when you have time) Sep 27 19:13:15 ok Sep 27 19:46:39 can you do bitbake -c do_fetch do_compile foo.bb or something along those lines? Sep 27 19:47:45 can oe uses ssh keys ? Sep 27 19:47:51 oe or bitbake Sep 27 19:48:02 for fetching? Sep 27 19:48:33 i was wondering if i could git clone on a gitosis from a recipe Sep 27 19:48:37 so yes for fetching Sep 27 19:48:56 I think you need a key without a passphrase Sep 27 19:49:08 of course Sep 27 19:51:55 and in front it has to be read only Sep 27 21:18:03 evening all Sep 27 21:21:45 hi pb_ **** ENDING LOGGING AT Fri Sep 28 02:59:56 2012