**** BEGIN LOGGING AT Thu Mar 13 02:59:58 2014 Mar 13 07:12:12 hello, can anyone help me on this error, please ? Mar 13 07:13:14 LD vmlinux.o Mar 13 07:13:15 powerpc-wrs-linux-gnuspe-ld.bfd: cannot find libgcc.a: No such file or directory Mar 13 07:13:56 when building the kernel Mar 13 07:16:02 robertyang: bitbake -c cleansstate gcc-cross ; bitbake virtual/kernel Mar 13 07:16:15 if that fixes it, you have the same problem as I'm having :) Mar 13 07:16:29 koen, thanks Mar 13 07:16:39 * robertyang trying koen's command Mar 13 07:39:21 my host is a little slow, it only runs to do_kernel_configcheck Mar 13 07:41:49 koen, thanks, it works Mar 13 07:42:34 koen, do you have a patch for it, please ? Mar 13 08:00:27 robertyang: no patch :( Mar 13 08:00:49 robertyang: something is broken with gcc-cross and sstate, which is out of my league to fix Mar 13 08:01:49 koen, got it, thank for the info Mar 13 08:08:20 koen, I've two bsps have this problem, one works well by bitbake -c cleansstate gcc-cross ; bitbake virtual/kernel, but the other one doesn't Mar 13 08:08:38 hmmm Mar 13 08:08:45 that workaround works for me Mar 13 08:08:50 both for linux and u-boot Mar 13 08:37:12 hi all, how do I get all my custom image package included in the sdk (meta-toolchain) ? Mar 13 08:37:49 I mean all dev packages (library) Mar 13 08:40:33 kbouhara, how about bitbake -C populate_sdk Mar 13 08:40:53 kbouhara, sorry, bitbake -cpopulate_sdk Mar 13 08:42:06 good morning Mar 13 08:42:16 robertyang, thanks ! Mar 13 08:42:30 robertyang, will try it Mar 13 08:42:38 I love popualte_sdk :) Mar 13 08:43:06 Crofton: Eu timezone? Mar 13 08:43:28 kbouhara, you are welcome Mar 13 08:43:46 mckoan, yep Mar 13 08:43:56 WSR 14 in Karlsruhe Mar 13 10:20:04 Is there a tip to avoid shared area file to be overwritten when changing kernel version in the machine.conf ? Mar 13 10:26:42 kbouhara: out of the box, OE only supports one kernel built per machine I'm afraid Mar 13 10:37:28 bluelightning, ok so i should let it overwrite files without fear to have an unstable bsp ? Mar 13 10:37:55 kbouhara: it's probably fine yes Mar 13 10:39:44 bluelightning, ok thanks for you answers Mar 13 12:46:43 bluelightning: ping Mar 13 13:07:50 hi. are the git mirror on github officially maintained/supported? e.g. is it safe to rely on them in a 'production' environment instead of git.openembedded.org? Mar 13 13:08:01 how often are they updated? Mar 13 13:13:57 there's either a git hook or a cron job every 10 minutes Mar 13 13:14:00 I forget which Mar 13 13:15:24 koen: ok. Mar 13 13:15:52 so, i can use them fine on 'production' , right? Mar 13 13:16:06 we get much better b/w with them in fact. Mar 13 13:27:06 anyone ever experience the kernel build process on oe sometimes fail in the install step because the staging of the kernel source causes random Makefiles to end up as directories Mar 13 13:28:15 hi mickeyl Mar 13 13:28:29 bluelightning: hey paul, i've been wandering through some ohloh projects to update my profile. Would you be so kind and add an alias for my contributions on the Opie project? All my contributions are listed under 'Michael Lauer', but I'd like them linked to my actual ohloh account "Dr. Michael 'Mickey' Lauer" [mickeyl] – See https://www.ohloh.net/p/opie/contributors?query=lauer&sort=commits_12_mo Mar 13 13:28:54 to add an alias, you need to be project manager though, that's why I'm asking you Mar 13 13:29:03 mickeyl: sure, let me see what I can do Mar 13 13:29:09 bluelightning: excellent, thanks Mar 13 13:35:29 mickeyl: ok, do you think it should be prompting me already? I tried adding an alias but it only allows aliasing between actual committers in the repo, so there's no other end to alias with that part of ohloh at least Mar 13 13:36:56 bluelightning: hmm, for what https://www.ohloh.net/p/opie/contributors?query=lauer&sort=commits_12_mo is telling me is that the actual account is at least listed as contributor, although it has 0 commits. so i thought it should allow linkin that Mar 13 13:39:09 bluelightning: I can create an entry in the technical issue help forum Mar 13 13:41:13 mickeyl: unfortunately it doesn't list your contributor account in the drop-down, only the committer Mar 13 13:41:39 bluelightning: ok, thanks anyways. i'll ask on the foru Mar 13 13:41:40 m Mar 13 13:41:47 will keep you posted Mar 13 13:41:52 mickeyl: thanks... let me know if you want me to do anything Mar 13 14:07:39 I follow the secondary toolchain explanations from http://www.openembedded.org/wiki/Adding_a_secondary_toolchain , yet OE builds gcc by itself Mar 13 14:08:29 also, it tries to use my toolchain for building native apps Mar 13 14:09:45 do I have to blacklist every single native recipe in OE? Mar 13 14:12:12 Anyone has any input on how I would track down the source of an error such as http://pastie.org/8914498 Mar 13 14:15:34 morning all Mar 13 14:17:17 hi pb_ Mar 13 14:17:19 how can I make OE use my toolchain only for cross compilation, and not for native recipes? Mar 13 14:17:32 hi bluelightning Mar 13 14:17:36 * pb_ stabs busybox Mar 13 14:17:41 because it really is using the prebuilt cross compilation toolchain for things like m4-native Mar 13 14:17:53 only those crazy dudes would have come up with the idea of making "zcat" not decompress its input Mar 13 14:18:22 dv_: it certainly shouldn't. how did you install the toolchain? Mar 13 14:18:41 it is on an absolute path. I followed the instructions from http://www.openembedded.org/wiki/Adding_a_secondary_toolchain Mar 13 14:19:58 dv_: maybe talk to fray about that, since that's his work Mar 13 14:22:18 hm. that page tells you to override ${CC}, which seems fairly bogus Mar 13 14:22:32 http://pastie.org/private/2piafhhfvspypescqlx13a here is the result of what I did according to these instructions Mar 13 14:22:52 surely you should only be overriding TARGET_CC or something, since it seems vanishingly unlikely that the same CC will be appropriate for both target and build. Mar 13 14:23:00 hmm Mar 13 14:23:09 so override TARGET_* instead of * Mar 13 14:23:51 that seems like a less crack-addled plan to me, yeah. though perhaps the idea is that the "_toolchain-example" override would only apply for target, I dunno. Mar 13 14:29:01 okay this seems to solve Mar 13 14:29:09 now I need to ensure OE doesnt build gcc and eglibc Mar 13 14:29:15 I am adding them to ASSUME_PROVIDED Mar 13 14:29:34 but, if I run ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}g++ " , things break down. I suspect the "+" characters are viewed as some kind of regex Mar 13 15:31:35 well, the fun starts. the toolchain does not have termcap anywhere Mar 13 15:55:40 Can anyone tell me how I include the package.manifest from a build in the image built from it? Mar 13 15:58:51 Out of curiosity, why not just include the package-management feature, and ask your package manager what's installed on the target, no? Mar 13 15:58:55 s/, no// Mar 13 15:59:40 I have no good reason, other than an ignorance of how to do that as well. ;) Mar 13 16:00:00 well, if we already produce a complete manifest (and in master, we do), it should be trivial to copy that into the image as a postprocessing command Mar 13 16:00:30 just depends on whether you want the overhead of runtime package management or not Mar 13 16:01:44 it'd be nice to have runtime package management, but easier to just copy the manifest. :) Mar 13 16:07:29 I guess I'm just looking specifically for the name of the variable to include, or if I have to do some string parsing Mar 13 16:07:48 trying to take the lazy route Mar 13 16:41:59 so PRINCs are no longer necessary? but when I add a .bbappend, the PR stays the same Mar 13 16:43:00 its recommended to use the PR server Mar 13 16:43:10 which autoincrements PR for packaging based on the metadata changing Mar 13 16:43:15 so you never have to worry about bumping it manually Mar 13 16:43:40 try setting PRSERV_HOST ?= "localhost:0" Mar 13 16:44:30 oh so I set this in local.conf now Mar 13 16:44:35 with the pr server, a distro like angstrom can have an official persistent PR server to keep package revs monotonically increasing Mar 13 16:44:46 so you can point to an external pr server, or let bitbake autostart/shutdown its own Mar 13 16:45:16 taht var is in local.conf.sample.extended Mar 13 16:45:22 course i can't remember the last time i looked at the .extended Mar 13 16:46:17 hmm PR is still the same Mar 13 16:46:56 it'll be the same, until the metadata changes. e.g. do a parse without the bbappend available, then add it and run bitbake again, and it'll increase PR Mar 13 16:47:12 it doesn't operate based on the number of appends, but based on actual changes to the metadata Mar 13 16:47:42 ah, okay Mar 13 17:29:43 I'm trying to compile some u-boot sources outside of oe using the toolchain built inside of my oe tree. I keep getting an error about -lgcc which is from (I think) a missing --sysroot option. I thought if I ran "bitbake -c devshell u-boot" and then changed to my external source directory, I'd be good, but u-boot doesn't use the CC env var set by bitbake. Mar 13 17:36:10 nm, I found the command via bitbake -e u-boot -c compile and looking for oe_runmake Mar 13 17:41:45 i'm pretty sure u-boot should build cross without needing a full sysroot Mar 13 17:42:09 just the toolchain part should do it... Mar 13 17:53:56 on another note, what broke the lxde config stuff on master? Mar 13 17:54:18 everything built fine a few a days ago, but not now... Mar 13 17:55:02 git-blame? :) Mar 13 17:56:29 kergoth: i still haven't traced it down, atleast not as of last night late... Mar 13 17:56:51 no relevant/recent changes in the lxde recipes Mar 13 17:57:08 ah Mar 13 17:57:12 although they are no missing a required dependency on lxde-dev-tools Mar 13 17:57:12 lovely Mar 13 17:57:17 *now Mar 13 17:57:39 plus, the other recipes seem to ignore that's even installed, so... Mar 13 17:58:06 big fubar in my brand new image that uses lxdm as the login manager Mar 13 17:59:19 it will take some time for me to dig into it and see how to make the config stuff work properly Mar 13 18:50:08 mr_science: I needed all of this: make CROSS_COMPILE=arm-poky-linux-gnueabi- CC="arm-poky-linux-gnueabi-gcc --sysroot=/oe/tmp/sysroots/wbq" HOSTCC="gcc -isystem/oe/tmp/sysroots/x86_64-linux/usr/include" HOSTLDFLAGS="-L/oe/tmp/sysroots/x86_64-linux/lib -L/oe/tmp/sysroots/x86_64-linux/usr/lib" HOSTSTRIP=true Mar 13 20:13:50 I'm on an Ubuntu 13.04 VPS and checked out the repos via what http://www.openembedded.org/wiki/OE-Core_Standalone_Setup said Mar 13 20:14:12 I just tried 'bitbake core-image-minimal' and it seems to keep stalling at some step without giving any reason why Mar 13 20:16:33 Hodapp: what does your local.conf and bblayers look like? Can you paste them? Mar 13 20:16:41 brb Mar 13 20:16:50 hold on, was getting a log from verbose output Mar 13 20:17:02 http://hodapple.com/files/bitbake.log.gz is the log Mar 13 20:18:54 * mr_science waits for git Mar 13 20:18:58 http://hodapple.com/files/openembedded/bblayers.conf Mar 13 20:19:02 http://hodapple.com/files/openembedded/local.conf Mar 13 20:19:42 okay, i was just in a two hour+ meeting and need a bathroom break Mar 13 20:19:57 and maybe some whiskey Mar 13 20:20:05 two hour+ meetings tend to make me want that Mar 13 20:27:58 yeah, tese can't be helped i suppose Mar 13 20:28:03 *these even Mar 13 20:28:35 they're all for me to brain-dump since i'm gone after next week Mar 13 20:28:58 greener pastures? Mar 13 20:32:31 yup Mar 13 20:32:58 not "greener" captures it, but more-or-less... Mar 13 20:33:01 *sure Mar 13 20:33:54 I just started a new job last week, hence me looking at OpenEmbedded for the first time Mar 13 20:36:32 you more layers than that, at least a bsp layer Mar 13 20:37:06 what? Mar 13 20:38:58 something like "poky, meta-openembedded, meta-rpi" Mar 13 20:39:18 or meta-oe and meta-rpi Mar 13 20:40:04 I'm just trying to do what http://www.openembedded.org/wiki/OE-Core_Standalone_Setup said as a sanity check Mar 13 20:41:27 it was building fine this way on my other VM, until disk space became an issue and I migrated to another VM and wiped out the configuration Mar 13 20:41:33 i haven't tried building any qemu targets, but my guess is that qemumips would need some kind of mips bsp layer Mar 13 20:42:04 otherwise how could it create a bootable mips image? Mar 13 20:42:23 unless that's inherent in the "qemumips" target Mar 13 20:42:40 is it normal for this operation to stall indefinitely with no error in the event of a problem like this? Mar 13 20:42:48 also, I would configure the build paths to something sane Mar 13 20:43:12 it might be because it doesn't know where to put the output Mar 13 20:43:29 i only have oe-classic here, so i can't test anything right now Mar 13 20:44:08 if you can't figure it out, i can help more after i get home tonight Mar 13 20:44:17 I'll try with qemux86 Mar 13 20:44:23 where do I set the build path? Mar 13 20:44:43 the DL_DIR is one example Mar 13 20:45:06 just set them to whatever makes sense in your local build env Mar 13 20:45:58 alright... I set DL_DIR and I'm building again Mar 13 20:49:48 gah. stalling again, almost immediately. Mar 13 20:49:52 no clue as to what it's waiting on Mar 13 20:55:17 you can try adding -D to get some dbug output Mar 13 20:55:23 *debug even Mar 13 20:55:41 if you need more, keep adding D's Mar 13 20:56:39 yeah, I think I put 6 or 7 on there for this run Mar 13 20:56:43 log I pasted was 3 Mar 13 20:58:21 still seems weird... Mar 13 21:01:42 I see one Python instance in 'ps aux' that is marked yet is using 15-25% of the CPU... but my one-minute load average is still near zero Mar 13 21:05:27 * Hodapp blinks Mar 13 21:05:34 this is looking like absolutely nothing to do with OE or Bitbake. Mar 13 21:06:08 I'm seeing crap in dmesg about killing processes. It looks like the OOM killer is killing processes, only I'm not out of memory nor do I see any out-of-memory errors in dmesg. Mar 13 21:09:40 clear that zombie and maybe that'll fix it Mar 13 21:09:59 * mr_science is not a zombie fan Mar 13 21:10:17 except when woody getas out the garden tools Mar 13 21:10:30 that one was pretty funny... Mar 13 21:10:39 mr_science: no, I've been *having* to kill the Python processes because ^C is doing nothing on its own Mar 13 21:11:04 but what happens when you start fresh Mar 13 21:11:11 the same damn thing Mar 13 21:11:29 I just rebooted; I'll see if I get those oddball lines in dmesg when I start again Mar 13 21:11:35 they shouldn't zombie either, bitbake is pretty good at respecting ctrl-c and what not Mar 13 21:11:49 I've a feeling here that bitbake isn't at fault Mar 13 21:11:51 somethign else is weird Mar 13 21:13:29 http://hodapple.com/files/openembedded/dmesg_wtf.txt I cannot make heads or tails of this Mar 13 21:14:16 it's inside of KVM but I can't see that mattering, unless it's overprovisioned memory like mad or something Mar 13 21:22:38 so you're building with bitbake in a linux kvm install? Mar 13 21:23:09 yeah, it's a VPS Mar 13 21:23:15 i have several at home, but i haven't tried building anything with bitbake in a VM with only 2G ram Mar 13 21:23:39 builds gentoo fine, builds native/cross toolchains fine Mar 13 21:24:01 well, it was building just fine on a Joyent VPS which had only 256 MB (I think); the issue there was disk space Mar 13 21:24:21 but i pretty much only do bitbake either native or chroot where i have the full system RAM available Mar 13 21:24:26 bitbake won't build worth a damn, if at all, with less than a gig of ram Mar 13 21:24:38 last i checked, anyway Mar 13 21:24:47 huh Mar 13 21:24:52 I can build on my desktop instead I guess Mar 13 21:25:00 *i* wouldn't try with less than 2 GB Mar 13 21:25:09 4 GB is fine Mar 13 21:25:16 yeah, the system gets pushed pretty hard with 1 :) Mar 13 21:25:23 and it takes forever Mar 13 21:25:48 * mr_science usually does 6 threads/5 parallel make on a 4 GB machine Mar 13 21:25:57 6 cores Mar 13 21:26:15 similar here Mar 13 21:26:31 taking forever don't much bother me when this is a low-priority task and it's on a VPS Mar 13 21:26:41 but, I'd have expected some other behavior if memory is the issue Mar 13 21:27:20 i'd probably use 1 GB as a real world minimum Mar 13 21:27:37 maybe 2 Mar 13 21:27:42 yeah, i wouldn't even try with less than 1. it used to not even be possible with 1, but that got fixed Mar 13 21:27:47 heh Mar 13 21:30:18 this sort of thing might be good to add to the Wiki Mar 13 21:30:29 I'm still curious though why the VPS is behaving the way it is Mar 13 21:33:35 hummm, guess I could start this build overnight on the work laptop when nobody's using the bandwidth Mar 13 21:33:49 it may burn a hole in the table Mar 13 21:51:33 Hodapp: bring a nice aluminum baking sheet and put it under the laptop Mar 13 21:51:45 big-ass heat sink Mar 14 02:25:59 for bug purposes, is meta-openembedded part of oe-core, or just layers? Mar 14 02:31:46 meta-oe isn't even part of yocto at all, so i'd say layers if anywhere in that bugzilla, assuming you're talking about bugzilla.yoctoproject.org Mar 14 02:32:09 so, a different bugzilla then? Mar 14 02:32:51 there is no bugzilla for meta-oe, best you can do is the mailing list Mar 14 02:33:05 the reason why is that there isn't anyone to maintain the bugzilla Mar 14 02:33:24 no oe infra people? Mar 14 02:33:39 nerdboy: I mean to triage bugs, fix bugs etc Mar 14 02:33:55 no bug wranglers then Mar 14 02:34:02 right Mar 14 02:34:35 if they were wrangled, there's really nobody to assign them to either? Mar 14 02:34:47 right Mar 14 02:35:02 We struggle enough with the OE-Core bugs :/ Mar 14 02:35:28 so, not the responsibility of he/she-whom-committed-the-recipe either? Mar 14 02:35:59 they might be interested in helping, they may have moved on to other things Mar 14 02:36:35 tbh, i've been having so much fun building my rpi os i haven't really been paying attention to much of that stuff Mar 14 02:36:59 okay, way too many work hours too Mar 14 02:37:13 been really light on my gentoo commits too Mar 14 02:37:35 had to stop and think for a minute just to mark some arm stuff stable... Mar 14 02:39:28 with github/gitlab like tools need for separate bugtrackers go away Mar 14 02:39:34 so i finally decided the key people in my group are untrainable (at least by me) and after next week they get to learn on their own Mar 14 02:39:45 may be we should think of deploying gitlab Mar 14 02:39:54 for oe git Mar 14 02:40:19 then layers hosted on git.oe.org can have issue trackers if they want to use it Mar 14 02:40:22 khem: not a bad idea Mar 14 02:40:38 I have deployed gitlab for my own stuff and its very nice Mar 14 02:40:55 its free github for private use Mar 14 02:41:18 your projects still look professional Mar 14 02:41:55 still sounds like recruiting some bug wranglers/package maintainers is a good idea too... Mar 14 02:42:17 maybe i can help with that Mar 14 02:42:18 more devs are always welcome Mar 14 02:42:33 we can get rid of gitolite as well Mar 14 02:42:36 besides recruiting myself i mean... Mar 14 02:42:49 nerdboy: its rather hard to do that.. Mar 14 02:44:31 people dont have a tendency to opt themselves out when they stop maintaining a recipe, or just sto ppaying attention to it, they tend to just wander off, and then your maintainer info is wrong Mar 14 02:44:35 i've recruited and mentored several gentoo devs over the years Mar 14 02:44:47 RP: what do you think of gitlab for git.oe Mar 14 02:44:48 i'm finally not talking out of my ass this time Mar 14 02:44:53 i swear Mar 14 02:46:11 yeah, if a maintainer really disappears and we can't get anyone to adopt it, we put in "maintainer-wanted" as the maintainer ;) Mar 14 02:46:26 in the package metadata i mean Mar 14 02:46:34 if you're volunteering to maintain the maintainer metadata, sure ;) Mar 14 02:46:55 that's kind of an adhoc thing Mar 14 02:48:09 when that's adhoc, it tends to not happen, imo Mar 14 02:48:26 we've tried ahving package maintainers many times over the years in oe, without much success Mar 14 02:48:35 i'd love to see it happen, but hte track record is not a good one Mar 14 02:49:09 it seems to work here, more or less Mar 14 02:50:28 but there are also several teams of devs/admins/infra/docs/xxx that are *supposed* to handle things Mar 14 02:51:06 sometimes a "team" might be one person for a while, but it mostly works Mar 14 02:51:59 one-dev herds are not uncommon, but the other stuff is mostly staffed okay Mar 14 02:52:12 with ups/downs and lots of changes over the years... Mar 14 02:53:26 maybe oe/yocto users tend to fix things on their own and just have nowhere to submit a patch/recipe/other? Mar 14 02:54:16 i mean no bug to submit the fix... Mar 14 02:56:03 khem: I know litle about gitlab so I don't have an opinion at this point Mar 14 02:58:00 nerdboy: as kergoth said, we've tried a few things and it hasn't worked well. We're open to trying new things but what we really need is more people with time to help out Mar 14 02:58:12 and sadly that last part is in short supply **** ENDING LOGGING AT Fri Mar 14 02:59:59 2014