**** BEGIN LOGGING AT Mon Jun 23 02:59:58 2014 Jun 23 07:50:40 hi. I have a qestion. how can I solve this problem without reboot the pc? my error is: "ERROR: Only one copy of bitbake should be run against a build directory" Jun 23 07:57:15 sm_: make sure no bitbake processes are running and that the lock file is deleted I think. Jun 23 08:01:14 '/bin/sh -> bash' is not a build requirement, is it? Jun 23 08:14:41 tasslehoff: thanks for responding. I googled around and find "ps -ef|grep bitbake" command to find bitbake processes and kill them. I should try this command... but I didn't get your questin... Jun 23 08:15:31 sm_: that Q was for the channel, not for you specifically :) Jun 23 09:28:56 tasslehoff: not anymore, no Jun 23 09:29:56 RP: good. have an error I have not seen before, but got it when using bash as well. Jun 23 09:35:56 good morning Jun 23 09:39:45 Hi all.. i am doing TI Beaglebone project using yocto..in that i am using my customized recipes. if compile using that recipes i am getting error as mentioned in link..PLEASE CHECK ERROR AND .BB FILES IN WEB LINK Jun 23 09:40:03 PLEASE HELP ME HOW TO SOLVE THIS ERROR Jun 23 09:59:56 please..help me to resolve above pasted problem.. Jun 23 10:07:43 RP: hi Jun 23 10:09:01 RP: what the status wrt musl libc? Jun 23 10:09:29 ant_work: khem was working on that, not me Jun 23 10:09:50 do you think we eventually switch? Jun 23 10:12:45 ant_work: switch from what? It may become an option for some people and usecases, depends what people need/want really Jun 23 10:14:44 I mean, it looks like eglibc will disappear after 2.19 Jun 23 10:15:04 so glibc will be default once again Jun 23 10:15:52 on the paper musl will be much lighter Jun 23 10:17:00 see, I have now stumbled in the mtd-utils_1.5.1 which does only compile with (e)glibc and thanks to an hack uclibc Jun 23 10:17:49 (and requires headers 3.15 btw) Jun 23 10:18:45 I'm about rebuilding a test 3.15 toolchain and I'll give maybe a try to musl Jun 23 10:18:49 I'll let you know Jun 23 10:28:28 My impression has been that, at any given time, the default trend in libc usage is away from caring about footprint, because generally things are getting larger and faster. Jun 23 10:32:07 RP: a while ago you were fixing hanging bitbake processes when the main one is killed Jun 23 10:32:26 RP: I think there is still some issue as they are still hanging when aborted on Jenkins Jun 23 10:42:20 JaMa: I think there is some new problem, yes :/ Jun 23 10:42:39 JaMa: I've noticed local builds where I've had to kill things too :( Jun 23 10:42:51 I remember you said it's a bit can of worms when you was touching it last time Jun 23 10:43:15 JaMa: thanks for working through that patch btw, I was thinking I had that to do until this morning :) Jun 23 10:43:33 JaMa: its a nightmare unfortunately, you fix one place and something else hangs :( Jun 23 10:44:24 thanks for the patch (you from all people shouldn't be responsible for fixing it) Jun 23 10:44:53 I've combined it with my PNBLACKLIST changes (mostly to mark "unmaintained" recipes) so now world builds are a lot faster :) Jun 23 10:45:45 I'll send new reports today (hopefully), I'll start sending report about wrong PACKAGE_ARCH (mostly from allarch) as well Jun 23 10:45:47 JaMa: If I merge the other pending autotools change, I won't feel quite as bad about it now since a lot of the dependencies have been fixed (although not all) Jun 23 10:46:20 I'll also send some improvements to test-dependencies and sstate-diff-machines scripts, so they match more with what my jenkins jobs do Jun 23 10:47:05 JaMa: in parallel I'm trying to tweak diffsigs so it becomes more useful. If you do notice it saying strange things, I'd love test cases to improve it Jun 23 10:47:07 RP: please wait with that change a bit more, I'll try to blacklist/resolve few more issues so that it's easier to spot new ones when it's merged Jun 23 10:47:22 JaMa: RIght, its not going in yet Jun 23 10:47:42 JaMa: it just doesn't break "everything" now :) Jun 23 10:48:02 I'm still using -S none and then calling bitbake-diffsigs only for recipes where it differs Jun 23 10:48:18 JaMa: due to performance? Jun 23 10:48:20 because in my case I'm always comparing only 2 signatures (from 2 MACHINEs) Jun 23 10:48:37 JaMa: diffsigs makes sense when you know the two sigs Jun 23 10:48:58 yes and I want to include only signatures from the current metadata Jun 23 10:49:24 JaMa: right, that is a different use case for what printdiff is intended for Jun 23 10:50:16 and the performance of printdiff is better now when I've removed tousands of sigdata files (with updated sstate-cache-management) :) Jun 23 10:51:19 JaMa: I can imagine how that would help :D Jun 23 10:52:16 please..help me to resolve above pasted problem.. Jun 23 10:52:26 please..help me any one to resolve above pasted problem.. Jun 23 11:21:51 RP: sstate-diff-machines sample sent to ML: http://lists.openembedded.org/pipermail/openembedded-core/2014-June/093667.html Jun 23 12:00:38 JaMa: thanks, will see if I can spot any fixes in there if I get a chance Jun 23 12:16:13 Hi, is it a way to allow multiple users to use the same Yocto build/ folder ? Jun 23 12:16:24 no Jun 23 12:16:45 well, you can't have more than one bitbake process on a single build/ directory Jun 23 12:17:06 agreed, but regarding file permissions, can I allow different users to trig the build ? Jun 23 12:18:10 assuming they all have write access i can't see why not Jun 23 12:19:26 when I use my own user I have no problems, if I use a different user with the good write access I get : cp: preserving times for `/opt/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/pics': Operation not permitted Jun 23 12:20:14 $ ls -la /opt/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/pics total 68 drwxrwxrwx 17 romain admin 4096 Jun 13 17:42 . drwxrwxrwx 5 romain admin 4096 Jun 13 17:42 .. drwxrwxrwx 2 romain admin 4096 Jun 13 17:42 ACCESSORIES drwxrwxrwx 2 romain admin 4096 Jun 13 17:42 BONUS drwxrwxrwx 2 romain admin 4096 Jun 13 17:42 CHALLENGE Jun 23 12:22:00 the other user is also member of the admin group Jun 23 13:53:55 Note to all: Don't pause your bitbake that's running in a VM on Friday without forgetting to unpause the VM. Jun 23 14:14:41 * [Sno] waves Jun 23 14:59:04 hi Jun 23 14:59:23 I have a problem when creating my BSP, and I can't figure out what I did wrong Jun 23 15:00:07 I have a No bb files matched BBFILE_PATTERN Jun 23 15:00:18 and my u-boot is not considered in the providers Jun 23 15:01:37 I created a directory named meta-vodalys-bsp/recipes-bsp/u-boot/ Jun 23 15:01:57 and in meta-vodalys-bsp/conf/layer.conf Jun 23 15:02:38 I have those lines : http://pastebin.com/zspSDJR3 Jun 23 15:43:26 nobody there ? Jun 23 17:57:33 does anyone know about a document or blog post describing releases and updates? Updates more in the sense of identifying differences if not version based/how to deal with the revison number somewhat automatically in a build process? Jun 23 17:59:31 quick q: TI's arago has this in their layer conf: PREFERRED_VERSION_bash = "3.2.48" Jun 23 18:00:15 I want to override that in my layer to use the latest, how do I do that? I tried adding PREFERRED_VERSION_bash = "4.2" to my layer and it didn't install 4.2 Jun 23 18:00:38 ick. layers should not be specifying preferences in layer.conf at all, ever Jun 23 18:00:38 ripperD: create a file .bbappend Jun 23 18:00:50 ripperD: then add PREFERRED_VERSION_bash = "my.new.number" in it Jun 23 18:01:02 its specified in a conf, not in a bb recipe\ Jun 23 18:01:05 ripperD: and make sure that youre layer has a higher number Jun 23 18:01:09 kergoth: layer.conf??? Jun 23 18:01:24 specifying preferred version in a recipe would be pointless Jun 23 18:01:27 ripperD: use _forcevariable overrride Jun 23 18:01:33 denix: [10:59:31] quick q: TI's arago has this in their layer conf: PREFERRED_VERSION_bash = "3.2.48" Jun 23 18:01:49 layer configuration, not layer.conf :) Jun 23 18:02:11 it's a distro layer. so the config he refers to is a distro config Jun 23 18:02:28 yeah, distro config Jun 23 18:02:29 "layer configuration" is a meaningless term :) Jun 23 18:02:30 but fair enough Jun 23 18:03:04 kergoth: well, don't believe anything you see Jun 23 18:03:32 is pr_service compatible with "builds from scratch"? Jun 23 18:03:34 I don't, but if you can't assume the person you're supporting is making sense, there's really no hope in helping them :) Jun 23 18:04:29 hmm ok, I'll try the _cofcevariable override! Jun 23 18:04:49 force, not cofce :) Jun 23 18:05:15 : P nothing like typo's to send one on a wild goose chase Jun 23 18:12:36 Hello Jun 23 18:12:57 how is the proper way to blacklist the evbug module? Jun 23 18:13:04 it shouldn't be autoloaded Jun 23 18:28:14 does someone use the git hash/cvs/svn id or similar for their PR number? Jun 23 18:29:07 or does something speak against it? Jun 23 18:42:33 thanks denix,kergoth,volker- . For the archives, final solution was this in my layer conf Jun 23 18:42:36 # Overide the arago bash 3.2 preference Jun 23 18:42:38 PREFERRED_VERSION_bash_forcevariable = "4.2" Jun 23 18:42:49 err local.conf NOT layer conf Jun 23 19:04:39 volker-: that would be PV, not PR Jun 23 19:18:53 rburton: why not PR? Jun 23 19:19:21 rburton: version get bumped manual via PV and revision automatically via PR+SCM id/hash Jun 23 19:30:06 volker-: if your source comes from a vcs, then you can put the hash into the PV Jun 23 19:30:13 and PR gets bumped on rebuild Jun 23 19:30:41 there's numerous recipes in oe-core that follow that pattern Jun 23 19:41:43 rburton: but that mean my packagefile would be mypackage-r0.deb Jun 23 19:42:02 rburton: that works fine with own created packages. but as soon as you use .bbappend it is getting messy Jun 23 19:42:21 why would that impact bbappends? Jun 23 19:42:33 rburton: if I modify the bbappends? Jun 23 19:42:46 still don't see what the git revision has to do with bbappends Jun 23 19:43:07 (you modify bbappend, bitbake notices, does a rebuild and bumps PR) Jun 23 19:43:35 rburton: the idea behind the version+revision is to find the difference. So the original yocto package is v1.2.3r0, now I create a bbappend it and it will become v1.2.3r1; now I add a feature and push it up to v1.2.3r2 Jun 23 19:43:58 rburton: yes, but bitbake notice is some kind of problem when you want to make sure that it is always able to build from scratch Jun 23 19:44:15 rburton: official builds here are always build from scratch Jun 23 19:44:29 that's what a PR server is for - to track what input matches what PRs Jun 23 19:44:40 so you can wipe and rebuild, and you'll get the same PRs Jun 23 19:44:45 rburton: and the build system fails often enough for the development build which only build the changes. fails due of changes in yocto itself Jun 23 19:45:49 rburton: so the idea is to automatically update the PR value every time you modify the file in the SCM Jun 23 19:46:34 assuming you mean your recipes, isn't that effectively what happens anyway? Jun 23 19:47:00 you edit the recipes (bb, bbappend, classes, whatever) and when it builds, PR is increased if there were changes Jun 23 19:47:30 rburton: yes, the buildserver increasing the PR gives me headaches Jun 23 19:48:14 another server, another backup, another fail over. Jun 23 19:48:29 so share the PR database between the servers Jun 23 19:48:32 I have to copy the buildhistory already from the fileserver to jenkins and back afterwards. Jun 23 19:48:53 rburton: why do you try to talk it out? Jun 23 19:49:01 rburton: because it is not possible? Jun 23 19:49:12 not sure i understand that. surely the alternative is to put a PR into each recipe. Jun 23 19:49:24 which until about a year ago was exactly what we did, so feel free to do it again. Jun 23 19:50:05 i'm trying to understand what your actual problem is, as you started with "i want to put the version in the revision" Jun 23 19:50:34 no, bind the revison to the SCM. the version is PV, no need to touch this Jun 23 19:51:09 so you mean the revision of scm that contains the recipes Jun 23 19:51:16 yes Jun 23 19:51:21 what happens if something outside the scm changes, like a local.conf change Jun 23 19:51:33 that is all in scm Jun 23 19:52:03 if you have a local.conf in scm then you should move it to site.conf or your distro.conf :) Jun 23 19:52:10 changing the environment is always a problem. Jun 23 19:52:21 surely your proposal means rebuilding everything on every change? Jun 23 19:52:27 the local.conf gets automatically modified by the build script, most stuff is in distro.conf Jun 23 19:52:33 rburton: yes Jun 23 19:52:37 ouch Jun 23 19:52:39 rburton: rebuild everything, get the diff Jun 23 19:53:00 * rburton is also pan-frying tuna so has to go Jun 23 19:53:31 rburton: builds are for repeatability. And yocto failed a couple of time when not using this clean & rebuild approach Jun 23 19:54:40 How does yocto do releases? always the incremental changes only? Jun 23 19:54:51 s/releases/official releases/ Jun 23 19:57:23 anyone try to use multilib lately to get -m32 to work generating i386 binaries on-target? According to yocto bug 1369 this used to work.... Jun 23 19:57:24 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1369 enhancement, Medium+, 1.4 M3, constantinx.musca, VERIFIED FIXED, [Multilib] On-target gcc enhancement Jun 23 20:06:00 paulg: what error do you see? Jun 23 20:08:58 RP: it never looks in /lib/ or /usr/lib at link so I get this: http://pastebin.com/1NVGbcq3 Jun 23 20:12:25 paulg: I'm sure some of this did work at some point but that does indeed look rather broken :( Jun 23 20:13:42 RP: After getting sufficiently lost in the python of gcc-multilib.inc ; I tried to manually fix it with a gcc bbappend that did this... Jun 23 20:13:47 EXTRA_OECONF += "--enable-multiarch --with-arch-32=i586 --with-multilib-list=m32,m64" Jun 23 20:14:10 ...based on the gcc config I found in ubuntu, but I still got the same error. Jun 23 20:14:50 paulg: we have patches against gcc and dynamically force the configuration in that python code Jun 23 20:14:52 I _do_ have all the lib32 variants of the multilib libraries and dev pkgs happily living in /lib and /usr/lib - so it isn't that. Jun 23 20:15:03 paulg: so I'd guess that python is doing the wrong thing Jun 23 20:15:29 there have been changes to it and whilst things looked "ok", I can't 100% test everything :/ Jun 23 20:15:57 RP, yeah - what I took away from reading the python (and bug 1369) was that if I'd enabled multilib, then I'd get a sane multilib gcc Jun 23 20:15:59 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1369 enhancement, Medium+, 1.4 M3, constantinx.musca, VERIFIED FIXED, [Multilib] On-target gcc enhancement Jun 23 20:16:49 fwiw, the lib32-gcc that is independently generated can create and link 32 bit binaries fine, which confirms the target is properly populated, and the breakdown is in the 64 bit gcc. Jun 23 20:17:11 the multilib of it, that is ; it can generate 64 bit bins just fine. Jun 23 20:17:36 paulg: right, I guess we're just not configuring it correctly... Jun 23 20:18:21 I guess I can raise a bug and perhaps we can suck some of the meta-intel folks into helping ; I'm using their kit for defining my MACHINE as an i7 Jun 23 20:18:54 started a qemu-x86-64 on another machine just to get another data point... Jun 23 20:18:59 build, that is. Jun 23 20:20:55 oh, and I should qualify the lib32-gcc didn't originally work. I had to fix that 1st. :) Jun 23 20:21:00 http://article.gmane.org/gmane.comp.handhelds.openembedded.core/52491 Jun 23 20:24:39 paulg: I saw that, nicely found... Jun 23 20:27:36 paulg: its certainly work filing a bug so this is known about Jun 23 21:23:07 Question/problem: I have meta-oe layer, which is at ref "dylan-next". This is the branch necessary for the image I'm trying to produce from the Arago project. Anyway, in meta-oe/recipes-multimedia/x264/x264_git.bb, the ref that's in SRCREV (which is 1cffe9f406cc54f4759fc9eeb85598fb8cae66c7) is not a ref in the git repo pointed to by the .bb file. How can this be? I was able to get around it by simply grabbing the latest commit's ref from the repo Jun 23 21:23:07 and replacing the SRCREV, but ... if that was once a valid commit, should it be - forever? Jun 23 21:23:49 git repos shouldn't "lose" commits. Jun 23 21:24:58 zman97211: did you update bitbake recently? or are you using the new bitbake, not the one that was released with dylan? Jun 23 21:25:01 The error I would get is fatal: reference is not a tree Jun 23 21:25:25 I followed (what I think are your) instructions at ... one sec Jun 23 21:26:32 I'll look up the exact set of instructions I followed, but I didn't download bitbake seperately. I used the layer-setup script, which fetched everything for me, then set it up with the sdk 7.00.00.00 .txt file. Jun 23 21:27:29 I believe I followed http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment#Detailed_Setup Jun 23 21:28:15 And used amsdk/aamsdk-07.00.00.00-config.txt Jun 23 21:28:27 zman97211: right, so you are using the latest bitbake then (Daisy or Dora), but picked up the recipe from Dylan times... Jun 23 21:29:11 Shouldn't that have worked? I assume it did at one time. Jun 23 21:29:12 zman97211: recent bitbake now requires specifying exact branch for a commit ID (SRCREV), if it's not on master Jun 23 21:29:40 you'd need to update some of the old recipes you have to work with latest bitbake Jun 23 21:30:43 I assumed oe-layertool-setup.sh would have fetched a collection of sources that would have worked together. Jun 23 21:30:53 zman97211: it does Jun 23 21:30:59 Then why the mismatch? Jun 23 21:31:09 zman97211: didn't you say in the beginning that you need to use some old Dylan-era recipe? Jun 23 21:31:16 No... Jun 23 21:32:01 I used oe-layertool-setup, and it fetched meta-oe. Going a gitk in the meta-oe directory shows that I'm at a tag named "dylan-next". I didn't specify to use that, I assumed oe-layertool did Jun 23 21:32:04 I have meta-oe layer, which is at ref "dylan-next" Jun 23 21:32:25 yes, I did say that. Your script pulled it, not me, tough. Jun 23 21:32:30 *though Jun 23 21:33:37 Inside amsdk-07.00.00.00-config.txt is this: meta-openembedded,git://git.openembedded.org/meta-openembedded,dylan,cb182019c4f7485713cb50623240c01882448ffd,layers=toolchain-layer:meta-networking:meta-oe Jun 23 21:33:43 dylan. Jun 23 21:34:52 zman97211: yes, that release appears to be dylan based, indeed... Jun 23 21:35:28 have checked meta-oe history if x264 had any recent fixes updating SRCREV? Jun 23 21:36:19 Well, I looked on the OE website, and browsed through the tree... x264 isn't even in that layer any more. Jun 23 21:37:18 it's in oe-core now Jun 23 21:37:46 http://cgit.openembedded.org/openembedded-core/log/meta/recipes-multimedia/x264/x264_git.bb Jun 23 21:38:04 and here's the answer to your question - http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-multimedia/x264/x264_git.bb?id=b193c7f251542aa76cb5a4d6dcb71d15b27005eb Jun 23 21:39:46 they rewrote published history? yikes Jun 23 21:39:56 indeed Jun 23 21:40:12 Well, there we go. Thanks for being better with git than me! :) I suppose I could resolve that with a .bbappend in my own layer with a SRCREV = "the new one" right? Jun 23 21:41:22 zman97211: that would work, if you need to stick with that dylan-based release configuration, of course Jun 23 21:43:32 denix: Not necessarily. I'm kind of new to this and I'm a bit afraid to mess around outside your layertool script for fear of breaking something. Or should I use that to initialize my environment, but then swap out layers for newer versions? Jun 23 21:44:54 zman97211: what makes you comfortable. there are plenty of configs in layersetup, there's more recent one based on daisy... Jun 23 21:45:30 denix: Are those configs just a snapshot of what was used for TI's released stuff? Jun 23 21:46:24 denix: I just grepped the configs directory for daisy and didn't find anything. Jun 23 21:47:11 denix: Which would be the "best" starting configuration in your opinion? Jun 23 21:49:02 Oh, well, looks like there's a new one since I cloned oe-layersetup.git Jun 23 21:50:14 denix: LOL did you just now check that in? Jun 23 21:51:12 denix: thanks Jun 23 21:52:36 zman97211: yes, amsdk configs are usually snapshots used for TI official releases... Jun 23 21:53:08 zman97211: yes, daisy is a new config, just added recently Jun 24 02:00:30 howdy, I'm getting a whole lot of failures to fetch packages from downloads.yoctoproject.org with a "connection refused" message. is it possible that my IP has been blacklisted somehow? Jun 24 02:00:59 like.. trying to download pseudo-1.5.1 Jun 24 02:23:46 it also seems that the recipe for libpng in daisy refers to a source package that doesn't exist anymore Jun 24 02:24:03 at least not in the specified path on sourceforge Jun 24 02:28:19 mbroadst: I've also witnessed SRC_URI linkrot -- though that was with Yocto 1.2, which is quite ancient now. Hardly surprising. Jun 24 02:28:47 well how old is the daisy release? I thought that would be fine to target for a release here Jun 24 02:30:41 mbroadst: 2014-04-24 looks like Jun 24 02:31:10 how could that release be pointing to a libpng 1.6.8 that no longer exists at the given URI? just an oversight? Jun 24 02:31:23 I thought there were CI bots or some such Jun 24 02:34:14 mbroadst: that version of libpng could have disappeared recently--sf.net claims the libpng16 "directory" was last modified 2014-06-08 Jun 24 02:35:47 who knows Jun 24 02:43:53 yeah, great sadness :) Jun 24 02:44:25 so continues the manual scp's over vpn heh Jun 24 02:47:37 I strongly recommend setting up a local PREMIRROR populated from your CI system's download cache (and never deleted)...almost never makes a difference, but when it does it's a lifesaver Jun 24 02:47:52 hindsight blah blah Jun 24 02:48:51 yeah we very stupidly whacked that earlier, and nobody from it support is up right now to do the backup Jun 24 02:51:30 now how to fake a git checkout in the downloads dir.. **** ENDING LOGGING AT Tue Jun 24 02:59:59 2014