**** BEGIN LOGGING AT Mon Aug 19 02:59:59 2013 Aug 19 08:00:01 morning all Aug 19 10:19:41 Hi all, I am working to achieve that no artifacts of UNIX System V init should be present on target i.e /etc/init.d and /etc/rc[0-6|S].d Aug 19 10:20:05 I seem to handle other things but it is opkg postinstaller script which is of some concern Aug 19 10:20:26 opkg is using /etc/rcS,d dir to place its postinstaller script Aug 19 10:20:37 which is removed on first boot Aug 19 10:21:02 Is it a good idea to replace it with a systemd service file? Aug 19 10:21:24 mshakeel: if it works the same way, I don't see why not... Aug 19 10:22:01 I mean if sysvinit is in distro features than keep things as it is otherwise use service file instead of script Aug 19 10:22:40 there is one more problem that there is 'systemd-compat-units.bb' which uses this script Aug 19 10:23:02 bluelightning: we need to modify that as well, is it acceptable? Aug 19 10:23:21 systemd-compat-units.bb is there to run sysvinit scripts in systemd env Aug 19 10:23:41 what are you changing there? Aug 19 10:24:19 just not to call that script if it is only systemd env Aug 19 10:25:02 although it is already first checking for this script existence. Aug 19 10:25:48 but functionality wise there shouldn't be any problem because what this script is doing (configuring pkgs) will be done through service file Aug 19 10:27:27 /etc/rcS.d/S98run-postinsts is opkg post-install script Aug 19 10:54:38 bluelightning, Hey. Aug 19 10:54:53 bluelightning, I pulled oe-core and tried to find meta-perl, but it's not there anywhere. Is it still in your staging/test area? Aug 19 10:56:38 Stygia: it's in the meta-openembedded repository Aug 19 10:57:24 Stygia, Alright, I'll go look for it. Aug 19 10:59:06 bluelightning, Is it on github too? Aug 19 10:59:59 bluelightning, Alright, got it. Aug 19 11:00:21 I'll be adding recipes gradually as I adjust their naming to your convention and add proper dependencies, etc. Aug 19 11:00:34 Stygia: ok, np Aug 19 11:01:07 bluelightning, Does a 'team member' need to sign off all my pushes? Do I need to write to the mailing list and describe what I've done? I mean I know I'm supposed to be subscribed and I am. Aug 19 11:02:04 Stygia: you'll need to send the new recipes as patches to the openembedded-devel mailing list Aug 19 11:02:28 Stygia: if you're sending a few you can use the pull request scripts, that makes things a bit easier Aug 19 11:02:33 bluelightning, Alright I'll just use the procedure on the wiki. Aug 19 11:11:09 bluelightning, Well... okay, I think that was it. I committed two recipes. Aug 19 11:12:31 bluelightning, So if this works/gets accepted I'll be pushing about... 30 I'd say this week. Aug 19 11:13:04 bluelightning, Hah... more like 104. :P Aug 19 11:14:00 Stygia: so you've committed them but not sent the patches yet, is that right? Aug 19 11:14:59 bluelightning, I think I send them? I used the git send-email command from the wiki. Aug 19 11:15:33 bluelightning, git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1 Aug 19 11:15:59 Stygia: ah, it should have been sent to openembedded-devel@ Aug 19 11:16:42 Aah right, pardon. I'll try again. I hope openembedde-core@ doesn't hate me now. Aug 19 11:17:14 doesn't seem to have shown up there yet, FWIW Aug 19 11:18:06 bluelightning, Hmm no... I may not have a proper sendmail binary, git didn't notify me about that, though. I'll keep trying. Aug 19 11:22:00 bluelightning, ... seems like the debian installer for sendmail is broken. I'll do it later, then. Aug 19 11:25:06 stygia: postfix may be simpler to set up from my experience, and also provides a sendmail binary Aug 19 11:27:36 zibri, Hmm alright, I could try that, thanks. :) Aug 19 11:50:12 Alright, so. Seems like postfix works just fine, and I tried to send an email. But I got a mail back from the openembedded-devel@ list saying I'm not allowed to email it? Aug 19 11:50:30 'You are not allowed to post to this mailing list' Aug 19 11:53:09 Stygia: are you subscribed? valid From: set? Aug 19 11:54:31 I did just subscribe, I think, and my From: erp@movis.dk Aug 19 11:54:41 Waait... maybe I subscribed to the openembedded-core one... let me check. Aug 19 11:55:05 Ah, yes. Sorry, I subbed to the wrong one. Aug 19 11:58:42 Hmm, alright. Now it should be posted, I think. Aug 19 12:02:54 Stygia: ok, I see it now Aug 19 12:03:02 Stygia: you've put signed-off-by in the subject line Aug 19 12:03:41 Stygia: also the shortlog should be "recipename: add" or similar Aug 19 12:03:49 Hmm? I guess? I more or less copy pasted the lines from the wiki. Aug 19 12:03:50 shortlog? Aug 19 12:04:15 Stygia: shortlog = first line of the commit message Aug 19 12:04:30 I did git commit -s then wrote a commit message, then just used the git send-email Aug 19 12:04:50 Ah, okay, so the first line should be short. How did I put the signed-off-by in there? I didn't do that manually, I just used git commit -s like suggested by the wiki Aug 19 12:05:02 I'm not exactly super familiar with git... Aug 19 12:05:13 I'm not sure how that all ended up on one line to be honest Aug 19 12:05:42 Hmm alright, well. Pardon either way. Aug 19 12:06:32 also, when sending to the openembedded-devel list you need to include a prefix that specifies which layer the patch is for, i.e. --subject-prefix="meta-perl][PATCH" Aug 19 12:06:54 (since the openembedded-devel list is used for many different layers) Aug 19 12:08:30 btw, if you also use --confirm=always on the git send-email command line you get a preview of the headers before sending Aug 19 12:08:37 Hmm alright. I will try again for another package, see if I can get it right. Aug 19 12:12:05 Okay, I hope this did it. Aug 19 12:12:43 I did git commit -s, added a line to briefly describe it, another line with a more full description, then pushed. But it seems like the whole description goes in the subject.. Aug 19 12:13:37 Ah, I got an email telling me I need a blank line before it. Right. Aug 19 12:13:59 Sorry to spam your mailing list. I still haven't contributed anything to an OS project before. Heh, hopefully the number of recipes I'm about to push will make up for it. Aug 19 12:17:04 no worries, we all went through this at some point :) Aug 19 12:17:24 Okay... okay, now I think it's right. :) Third commit, and this time the subject and everything looks correct. Aug 19 12:21:18 This last one I send looks right, yea? Aug 19 12:21:50 pretty much, although typically when adding recipes I usually do one commit per recipe (not sure if that's a rule or not though) Aug 19 12:22:41 Ah, hmm. Aug 19 12:22:49 Well I've done one recipe + its dependencies. Aug 19 12:22:56 It wouldn't build it work just with the one recipe. Aug 19 12:23:19 indeed, if you did want to do one per recipe it would be in order such that the dependencies were added first Aug 19 12:23:41 this is somewhat of a triviality though Aug 19 12:23:50 Hmm. Yea, alright, fair enough. I'll try to keep that in mind. Aug 19 12:24:00 the recipes themselves are very clean, well done :) Aug 19 12:25:56 Stygia: a couple of other things though Aug 19 12:26:09 perl-module-* may not fit our typical naming scheme (at least as far as I've seen) Aug 19 12:26:31 usually it's lib*-perl Aug 19 12:27:01 also, we usually characterise the perl license as "Artistic-1.0 | GPL-1.0+" Aug 19 12:27:19 (assuming those recipes were meant to be licensed a la perl itself) Aug 19 12:27:35 Oh? Didn't you tell me to change from cpan-X to perl-module-X? Aug 19 12:27:42 Also, they were. Aug 19 12:27:51 did I? hmm... Aug 19 12:28:02 I distinctly remember someone saying it. Immediately I'd say you. Aug 19 12:28:07 Fuck me if I know, though. Aug 19 12:28:35 this is a lot of pedantry to put up with, I know... sorry about that Aug 19 12:29:52 Hmm, well, no worries. Aug 19 12:30:06 I just sort of need a way to know for sure. Is it perl-module-X or libX-perl? Aug 19 12:30:24 Because I've been spending some time renaming my cpan-X things to perl-module-X already... Aug 19 12:30:58 looking over all of our recipes and the older ones in OE-Classic, it's libX-perl Aug 19 12:31:22 I wonder if there's an easy way to rename them quickly rather than you having to go through and do it by hand Aug 19 12:31:48 I think I have a mass renamer somewhere here... Aug 19 12:32:11 I guess if you haven't committed them yet it'll already be easier Aug 19 12:32:36 bluelightning, https://www.youtube.com/watch?v=PxANht7yBV4 Aug 19 12:32:46 bluelightning, Sorry about the quality. Just thought the joke fit. Aug 19 12:32:56 heh Aug 19 12:36:26 bluelightning, Are you sure about the libX-perl convention, though? Aug 19 12:37:25 Stygia: looking at this, fairly sure yes: http://layers.openembedded.org/layerindex/recipes/?q=perl Aug 19 12:43:18 bluelightning, Alright, well. Okay then. Aug 19 12:43:32 bluelightning, Just FYI this is the last time I'm renaming anything. ;) So now you're stuck with that convention. Aug 19 12:43:45 ok :) Aug 19 12:44:29 bluelightning, No worries though, my mass renamer can do regular expressions. Aug 19 12:44:51 So it's a pretty simple matter of s/perl-module-(.*)/lib\1-perl/gi Aug 19 12:44:54 I can do that. :P Aug 19 12:46:53 I'll fix that expression if it's borken somewhere, don't worry. :) Aug 19 12:51:12 howdy! jsut a short one: whats the best practise when working with multiple projects, which could have architecture or bits n pices in common? using a vendor layer for the software is obvious, but what about the directory structure, and what gets built when/where? Aug 19 12:56:28 LetoThe2nd: keep separate build directories; you may also wish to use separate branches in your "vendor" layer so that changes don't necessarily have to apply to both Aug 19 12:57:20 bluelightning: so basically start from poky base for each project? Aug 19 12:58:12 LetoThe2nd: yes Aug 19 12:59:08 bluelightning: so sharing the toolchain or such is not recommended? e.g. when ever i start or take over some project, the first build is used to get everything setup up, right? Aug 19 12:59:33 sharing the downloads is possible, already found that Aug 19 13:00:08 LetoThe2nd: you can share the sstate directories between the two to save build time Aug 19 13:01:02 otavio, http://cgit.openembedded.org/openembedded-core/commit/?id=72980d5bb465f0640ed451d1ebb9c5d2a210ad0c Aug 19 13:01:03 Stygia: er, so your patch is on top of the other patch you sent, it should be against master Aug 19 13:01:07 broke meta-xilinx Aug 19 13:01:22 Stygia: you can squash it into the previous patch by using "git rebase -i master" Aug 19 13:01:35 Crofton|work: ?!? Aug 19 13:01:37 bluelightning: is that ok also for example if one is x86 and the other is arm? or just not worth the effort because only the initial build is affected? Aug 19 13:02:09 LetoThe2nd: well, it'll still be able to save time on the native part Aug 19 13:02:13 LetoThe2nd: as a general rule, i am using 1 download and 1 sstate-cache, which are symlink'd in all my build folders. Aug 19 13:02:23 http://pastebin.com/F6U7Ckw8 Aug 19 13:02:53 ndec: ok, something like /opt/pokystuff/{downloads,sstate} manually lilnked into every project? Aug 19 13:03:11 yep. Aug 19 13:03:32 ndec: ok, i think i get it. Aug 19 13:03:45 sstate make 'build folder' cheap ;-) Aug 19 13:04:26 there are tools/scripts to cleanup sstate when it starts getting too big. Aug 19 13:04:46 otavio, zedd_ http://pastebin.com/F6U7Ckw8 Aug 19 13:05:17 ndec: well that thing getting big is not an issue to my, just thinking of how things are actually used in everyday work (as opposite to "first steps") Aug 19 13:05:26 Crofton|work: yes; I sent a fix for this to the ml Aug 19 13:05:32 ah cool Aug 19 13:05:38 thanks Aug 19 13:05:44 LetoThe2nd: everyday work, as you are 'alone', or with a team? Aug 19 13:05:48 sgw_: Did you see the patch for linux-dtb? It is critical ^ Aug 19 13:05:59 sgw_: it fixes a regression Aug 19 13:06:04 ndec: both cases exist Aug 19 13:06:40 bluelightning, Alright? I'm not exactly sure what you mean by that and why I would do that. Aug 19 13:06:46 i haven't implemented the 'team' use case yet... but i suspect sharing the 'team build server' sstate over the network should be what to do. Aug 19 13:06:49 I actually don't understand what you mean by a patch being on top of the other patch? Aug 19 13:07:34 otavio, thanks, always good to find Monday's problem is already queued for a fix Aug 19 13:07:37 Stygia: the test-more patch you have sent isn't a change on top of master, it's a change on top of one of the other patches you sent Aug 19 13:07:46 ndec: ok Aug 19 13:07:56 Stygia: test-simple I mean Aug 19 13:07:57 Ah hmm alright. So if I run the rebase command, what then, I can change my previous commit? Aug 19 13:08:04 Stygia: yes Aug 19 13:08:10 test-simple RPROVIDES test-more so not completely off. :P Aug 19 13:08:50 So if I rebase it... do I have to mail it again, or just push, or what? Aug 19 13:10:31 Stygia: it'll have to be re-sent yes Aug 19 13:10:38 ndec: when after some bitbking i changed my pwd into another project and source th oe init nothing clashes, right? Aug 19 13:11:05 bluelightning, Alright. I'll rename one at a time, then do one commit per rename, then, once I"ve done all that, send the email? Aug 19 13:11:16 LetoThe2nd: not sure i see what you mean. Aug 19 13:11:17 Crofton|work: eheh; sorry by not catch this error before :( Aug 19 13:11:30 Stygia: it's not one commit per rename it's one commit to add the recipe on top of what's in the meta-openembedded repository Aug 19 13:11:58 Hmm alright. Aug 19 13:12:03 ndec: well sourcing oe-init-env-script or howsitcalled prepares my shells environment when i'm inside a specific project Aug 19 13:13:08 ndec: so after being done with things there, if i use the *same* shell to continue working maybe in another project, will leftovers in the env clash? Aug 19 13:15:14 \o/ vacatioooooon! :) Aug 19 13:16:32 bluelightning, Okay... I've no idea if that was right, but anyhow, there it goes. Aug 19 13:16:40 bluelightning, At least now I can add new recipes without doing it wrong. ^_^ Aug 19 13:18:24 LetoThe2nd: hmm... that's weird.. Aug 19 13:18:52 my nick has changed, and I can't change it back... i am definitely not in vacations... Aug 19 13:19:45 Stygia: I'm afraid this is the same thing Aug 19 13:20:00 bluelightning, Oh, well uh. Hmm. Aug 19 13:20:19 bluelightning, I'm not quite sure what to do. I did the restage thing, and it opened a file that said 'noop', so... I saved that and mailed it in. Aug 19 13:20:42 Stygia: ah of course.. sorry... try git rebase -i origin/master Aug 19 13:21:00 After commiting, yea? I did already commit these chagnes Aug 19 13:21:01 changes Aug 19 13:21:05 yes Aug 19 13:21:42 bluelightning, Isn't it too late now though? Aug 19 13:22:04 Stygia: not really, none of these patches can be applied Aug 19 13:22:32 Stygia: if you like you can send the next one to me first if that helps Aug 19 13:24:17 The file? Or the commit? Aug 19 13:24:36 Okay, I"m trying to restage the commit... If I'm reading this right, then what I'm doing here makes sense: Aug 19 13:24:36 s 51bdf53 Added recipes for Test::More and its dependency Test::Harness Signed-off-by: Emil Petersen Aug 19 13:24:37 s 9288d2e perl-module-test-more: deleted, perl-module-test-simple: add Test::Simple contains Test::More and a number of other packages.$ Aug 19 13:24:37 s f52c98d perl-module-common-sense: added, perl-module-json-xs: added Aug 19 13:24:37 s a99702c perl-module-scalar-list-utils: added Aug 19 13:24:39 s 4455d1f perl-module-test-simple: renamed Aug 19 13:24:41 s a80ca11 perl-module-json-xs: renamed Aug 19 13:24:43 s 5bf8d69 perl-module-common-sense: renamed Aug 19 13:24:45 p 1cf1455 libjson-xs-perl,libscalar-list-utils-perl,libtest-harness-perl,libtest-simple-perl, perl-module-test-harness: rename Aug 19 13:24:50 Picking the last commit and squashing the others? Aug 19 13:25:37 Stygia: no, you need to move things around such that you can squash the renames into the adds Aug 19 13:25:37 bluelightning, That make sense? Aug 19 13:25:55 Stygia: you can cut and paste lines to reorder the commits Aug 19 13:26:00 bluelightning, I'm sorry, but I don't know what you mean by that or how to begin to accomplish it. Aug 19 13:26:15 bluelightning, Ah, so.... the adds need to be the last ones? Aug 19 13:26:53 Stygia: well not really, they need to be interleaved since the squash just squashes it into the commit above Aug 19 13:27:19 bluelightning, ... I'm sorry but you've completely lost me. Aug 19 13:27:33 bluelightning, Can I somehow delete all my commits so far and just do a "normal" commit with the right name to start with? Aug 19 13:28:28 Stygia: sure... you can soft reset back to master Aug 19 13:29:19 i.e.: git reset origin/master Aug 19 13:30:45 bluelightning, Alright... I'm just gonna kill this repo and clone it again... then go read the git documentation before I bring irrevokable shame to my family name. Aug 19 13:44:32 Stygia: no need to clone again, if you reset to origin/master you're back where you started with your changes uncommitted on top Aug 19 13:57:54 i think i accidentally terminated a bitbake run badly. now i'm getting "An uncaught exception occured in runqueue" followed by a traceback and "OSError: [Errno 2] No such file or directory" Aug 19 13:58:06 how should i go about finding out what's causing this and fixing it? Aug 19 14:00:31 BCMM, I've no idea, but have you tried -c cleanall'ing the recipe you terminated? Aug 19 14:01:00 now you mention it, probably not all of them Aug 19 14:01:01 i'll try that Aug 19 14:02:05 Stygia: nope, same again Aug 19 14:02:08 thanks though Aug 19 14:02:43 "NOTE: Executing RunQueue Tasks" is the last line before it falls over Aug 19 14:03:37 if i "git pull" the latest versions of everything, what do i need to do to ensure stuff gets rebuilt Aug 19 14:03:38 / Aug 19 14:03:56 (i was trying to type a question mark...) Aug 19 14:08:00 it looks like it's breaking because tmp/sysroots/x86_64-linux/usr/bin/pseudo doesn't exist Aug 19 14:08:31 which is presumably because i just ran wipe-sysroot... Aug 19 14:08:42 i guess there are some other commands i need to run when i do wipe-sysroot? Aug 19 14:10:10 Hi iam new here maybe someone can help me, i Build with hob an Image "atom" + "Core Image Minimal initramfs" and boot it over pxe with pxelinux and it holds on "Waiting for removable media ..." does this mean that rootfs cannot be found ? Aug 19 14:11:14 Only can find something about a boot bug with udev but this should be fixed in dylan Aug 19 14:20:55 BCMM: You could try bitbake -c pseudo-native Aug 19 14:21:10 BCMM: -c clean pseudo-native Aug 19 14:22:18 RP: thanks, that's fixed. new error now: "rpmbuild: command not found" Aug 19 14:22:39 RP: it seems like wipe-sysroot destroyed a bunch of native utilities without prompting anything to rebuild them? Aug 19 14:23:07 have i misunderstood the circumstances under which it is ok to wipe-sysroot? Aug 19 14:23:50 BCMM: I'm not familiar with it :/ Aug 19 14:24:08 BCMM: that error means rpm-native is missing and needs cleaning Aug 19 14:24:25 yeah, doing that now, but i imagine it's going to do that for every native package Aug 19 14:25:11 BCMM: for some reason its not wiped out the native do_populate_sysroot stamps in tmp/stamps Aug 19 14:25:58 RP: what exactly are stamps? they indicate that something has already been installed and doesn't need building just cause something depends on it? Aug 19 14:26:16 BCMM: they tell bitbake is something has been built or not Aug 19 14:26:21 s/is/if/ Aug 19 14:27:33 for the actual ARM packages i've built, there are already work dirs with completed builds right? so it should basically "make install" or equivalents without having to rebuild those? Aug 19 14:31:05 RP: looking at the source, it wipes out do_populate_sysroot stamps only Aug 19 14:33:33 BCMM: but it should do that in the native directory as well as the target ones Aug 19 14:33:57 RP: yeah, they seem to be gone. that doesn't seem to have persuaded bitbake to reinstall them Aug 19 14:34:40 BCMM: Something odd is going on :/ Aug 19 14:34:52 BCMM: hard to tell from afar though :( Aug 19 14:35:02 RP: shall i just do bitbake -c clean $(bitbake -s | grep native | awk ' { printf $1 " " } ') Aug 19 14:35:41 is that likely to cause further breakage, beyond having to rebuild the native packages? Aug 19 14:35:55 BCMM: At this point I'd probably start with a clean tmp Aug 19 14:36:12 that means rebuilding all the target packages... Aug 19 14:36:25 BCMM: presumably you have sstate still? Aug 19 14:36:47 RP: what's sstate? (i'm pretty much a yocto newbie) Aug 19 14:37:09 BCMM: the sstate-cache directory - it will use objects from there *if* they match your current configuration Aug 19 14:37:41 RP: yeah, i have that - what is it though? Aug 19 14:38:21 BCMM: saved output from the build to reuse in other builds if the configuration matches. Aug 19 14:38:38 ah, basically tarballs of finished "packages"? Aug 19 14:38:57 BCMM: tarballs of the output of specific tasks Aug 19 14:39:04 so yes, ish Aug 19 14:39:30 so if i just wipe out tmp/ and re-run my recipes, i won't be doing everything from scratch? sounds like the way to go, thanks Aug 19 14:42:58 BCMM: correct, assuming the configuration still matches Aug 19 14:43:28 RP: meaning relevant configuration, or any modification of local.conf? Aug 19 14:43:40 BCMM: relevant configuration Aug 19 14:43:49 thanks, i'll do that Aug 19 14:46:21 RP: have you seen ^C problems early on in bitbake's startup? it seems worse than it was before bitbake learned to restart itself. e.g. an interrupt and clean shutdown of the pseudo-native build and it continues merrily along to the real build Aug 19 14:46:31 RP: i'm quite often having to ^Z and pkill -f bitbake Aug 19 14:47:11 another behavior is just a hang if you interrupt prior to the initial build Aug 19 14:50:10 Hi iam new here maybe someone can help me, i Build with hob an Image "atom" + "Core Image Minimal initramfs" and boot it over pxe with pxelinux and it holds on "Waiting for removable media ..." does this mean that rootfs cannot be found ? Sry for remsg :-) Aug 19 14:52:00 RP, those are the most ridiculous off road tires I ahve ever seen Aug 19 14:55:10 daBONDi_work: ensure you have not removed support for the device upon which you are booting from in your kernel config Aug 19 14:55:28 kergoth: I've seen the same thing :( Aug 19 14:55:54 kergoth: I think the process changes have made an existing problem much worse and more visible :( Aug 19 14:56:22 Crofton|work: They're all terrain, I don't do much proper offroad Aug 19 14:57:12 * kergoth nods Aug 19 14:57:50 Crofton|work: http://www.rpsys.net/wp/rp/disco2.jpg shows it can happily go interesting places on those tyres ;-) Aug 19 15:37:30 daBONDi_work: I suspect it does mean the rootfs can't be found, have a look at meta/recipes-core/initrdscripts/files/init-live.sh where that message is shown Aug 19 15:45:24 yeah bluelightning i found that already in source still no clue to fix it, but iam trying :-) Aug 19 16:06:48 Someone Now if i need the modules.xxx.tgz file to boot with syslinux ? Aug 19 16:06:59 Someone know if i need the modules.xxx.tgz file to boot with syslinux ? :-) Aug 19 16:54:21 Hi guys, I have a uclibc based rootfs, lzma compressed takes ~2.2MB. Now if I just change libc to eglibc it becomes ~3.4. Is there any way I can trim down standard eglibc to achieve something similar to uclibc? Aug 19 16:55:54 Krz: you can play around with the eglibc configuration options (see Darren's work on poky-tiny), but to be honest I thought you had already done that Aug 19 16:58:43 bluelightning: looking at poky-tiny config (which I'm using) there is nothing else to strip :/ Aug 19 16:59:30 Krz: right, in that case unless you want to cut out some really fundamental stuff that is probably the lower limit of size for eglibc Aug 19 17:04:22 i guess if i really wanted openembedded on my new phone i'd a freerunner... Aug 19 17:04:30 *need Aug 19 17:05:10 unless there are any other machine targets for openmoko? Aug 19 17:08:57 the meta-smartphone repository has a bunch of phone hw targets IIRC Aug 19 17:09:32 bluelightning: thx; ~3.4MB is pretty low anyway Aug 19 17:09:55 bluelightning: we just have so low size restrictions Aug 19 17:47:40 Hi iam again << Yocto N00b :-) i Installed the Yocto Plugins in my Eclipse Juno SR2 and Create a Bitbakecommander Project and under the Project Properties > Builders i got an error, "Missing Builder (org.yocto.bc.ui.builder.BitbakeBuilder", i install it with Help > Install Software > Pass URL from 1.4.1 Version Aug 19 18:45:32 hi guys, anyone know how to use bitbake commander in eclipse Aug 19 18:50:13 i am using eclipse kepler and the plugin Aug 19 19:07:09 any eclipse bitbake commander experts out there? Aug 19 22:36:15 any thoughts on https://gist.github.com/kergoth/6274970 ? the lack of consistency amongst non-linux-yocto kernels wrt .config bugs me Aug 19 23:11:19 kergoth: That seems like a good idea to me, intuitively. Consistency is nice. Aug 19 23:11:40 Unrelated, but since I happened to be here looking for you: Any thoughts on how well meta-sourcery works with multilib builds, normally? Aug 19 23:12:40 I ask because my fork is sorta badly broken for a BSP that enables multilibs, with the root problem being that ${TARGET_PREFIX} is the same for both multilibs, I think. It didn't affect my previous implementation because that one always set up wrappers, thus, had different TARGET_PREFIX for each multilib. Aug 19 23:19:17 seebs: heh, I doubt anyone has ever tested it with them. I'm guessing some missing ${MLPREFIX}s Aug 19 23:20:09 I'm not sure. The distinction seems to be that with our wrappers, we were setting values with names like PREFERRED_PROVIDER_virtual/tuning1-wrapper-linux-gnu-gcc-initial Aug 19 23:20:52 But without the wrappers, it's just the generic and identical-between-multilibs "mips-sourcery-linux-gnu-gcc-initial" or whatever. Aug 19 23:21:38 So, what's biting us is, there is a hidden assumption in the way the virtual/PREFIX-gcc-initial stuff is set up, which is that TARGET_PREFIX varies. Aug 19 23:21:40 yeah, i expect the quickest solution would be to add mlprefix to the non-PN-based-package-names and to the provides. longer term would be nice to only provide a given multilib if we really provide that multilib Aug 19 23:22:17 I think it's not the package names biting us, but the predefined (external to this layer) virtual/* names. Aug 19 23:22:34 Something somewhere is assuming that gcc-initial can have a different PREFERRED_PROVIDER for each multilib, which it sort of has to. Aug 19 23:22:35 i know, i just mentioned it as it'd bite us later :) Aug 19 23:22:39 Ahh, that too. Aug 19 23:23:04 And I *think* I have the mlprefixes in most of the places I need them, maybe. Aug 19 23:23:26 In my fork, there's suitable magic such that you really can build the external-sourcery-toolchain-cross for two multilibs, in principle. Aug 19 23:23:58 I am sort of leaning towards some kind of fancy thing wherein we have base symlinks using the CSL_TARGET_SYS names, and then tuning-specific links to them which use something else, and make TARGET_PREFIX be that something else. Aug 19 23:24:08 Even if the tuning-specific links don't *actually* do anything different. Aug 19 23:25:21 doesn't sound unreasonable to me Aug 19 23:26:40 I am gonna stop talking now. I was feeling mostly okay, then I thought "huh, my throat feels dry and itchy", and suddenly I feel awful. Aug 19 23:26:54 And I learned, quite a while back, that I get *really stupid* when I am even a little sick sometimes. Aug 19 23:27:12 I try very, very, hard not to write code when I have mild sniffles. Unless it is for future entertainment value during code reviews. Aug 19 23:27:54 heh, definitely a good policy, I have that one also. particularly for fevers, almost never thinking straight with those Aug 19 23:28:26 I sort of default to a fever whenever anything happens to my immune system. Aug 19 23:28:39 Although this did lead to one of the most fascinating experiences I ever had. Aug 19 23:29:06 I had a fever, and I grabbed a book. It turned out to be _Foucault's Pendulum_. Aug 19 23:29:29 So basically, there's what the calendar tells me is about a 3-day period during which I frankly have no idea which things I dreamed and which I read. Aug 19 23:29:42 And I am sort of afraid to ever go read the book again now, for fear it won't be as awesome as it seemed then. Aug 19 23:35:34 Foucalt's Pendulum is pretty awesome. So is Name of the Rose. Aug 19 23:36:36 I did eventually confirm that I did not invent "mechanical avunculogratulation", although I may well have spelled it wrong. Aug 19 23:53:26 seebs: we need to get your enhanced set -e error output bits merged into bitbake Aug 19 23:53:56 We do. But I am not sure what would be the next step, since I don't think there were any problems reported with the ones I submitted last time. :) Aug 19 23:55:01 could be it just got missed, or fell o the floor with richard on vacation, who knows. maybe a re-submit would be sufficient Aug 19 23:55:12 * kergoth shrugs Aug 20 00:30:17 sometimes i wish i could append to a variable default value without modifying the flag directly Aug 20 00:30:24 foo ??+= or something equally twisted Aug 20 00:30:35 would be really handy for PACKAGECONFIG defaults Aug 20 00:31:07 we should think about having a packageconfig backfill mechanism **** ENDING LOGGING AT Tue Aug 20 02:59:59 2013