**** BEGIN LOGGING AT Wed Nov 13 02:59:58 2013 Nov 13 03:12:33 Hello everyone, is anyone experiencing libmpd-11.8.17 Not Found error? Nov 13 03:13:03 nope Nov 13 03:13:21 k Nov 13 03:13:22 what branches are you on? Nov 13 03:13:28 Dylan I believe Nov 13 03:13:32 haven't updated to Dora yet Nov 13 03:14:41 i'm on master, but lemme pull and rebuild Nov 13 03:14:59 alright thanks nerdboy Nov 13 03:15:20 * nerdboy has been flogging gnat-gcc for a while Nov 13 03:16:09 okay, i'm gonna nuke tmp and pull/rebuild Nov 13 03:16:53 oh yeah, i did take a detour to fix erlang but i haven't built my full image for a few weeks Nov 13 03:17:03 kk thanks I awaits your answer Nov 13 03:17:29 be back in 10 min - gotta get some udon. So hungry Nov 13 03:17:39 k Nov 13 03:17:55 hope nobody's using the feed right now... Nov 13 03:36:24 a couple merge conflicts later and rebuild in progress... Nov 13 03:38:04 nerdboy: kk cool Nov 13 03:38:25 as soon as i bump my ssh bbappend... Nov 13 03:42:43 deps look good, it's cranking on all 6 cores... Nov 13 03:44:08 nerdboy: sounds good, have you gone past libmpd? Nov 13 03:44:29 not yet => 174 of 7213 Nov 13 03:46:00 i think i have -j6 with 6 threads Nov 13 03:46:44 i see all cores working hard! Nov 13 03:53:11 I'm having some trouble with dependency resolution, trying to build gstreamer 1.0 git with poky master Nov 13 03:53:18 it complains when building the rootfs Nov 13 03:57:53 thaytan: that sounds odd, since i'm also on master and have gstreamer pulled into my image Nov 13 03:58:04 nothing weird yet... Nov 13 03:58:15 nerdboy, which gstreamer though? Nov 13 04:00:05 i'll let you know when it's done building... Nov 13 04:00:43 looks like it's all 1.0.9 Nov 13 04:00:52 yeah, 1.0.9 built fine Nov 13 04:01:03 you're using the git recipes? Nov 13 04:01:07 I'll clean stuff and rebuild Nov 13 04:01:13 nerdboy: thanks for your help, i will check back soon Nov 13 04:01:28 nerdboy, yes Nov 13 04:03:08 b1gtuna: it should take a couple of hours for a fresh build Nov 13 04:03:24 usually lots of dep updates after a pull... Nov 13 04:10:43 thaytan: can you paste-bin the terminal contents? Nov 13 04:15:00 nerdboy, I'll see if it fails again after this build Nov 13 04:15:17 maybe it's got stale cached data from having built 1.0.9 Nov 13 04:15:28 could be Nov 13 04:15:53 if things get into a wonky state, usually nuking tmp is all i need Nov 13 04:18:32 yeah, I just hate the long rebuild from a full nuke Nov 13 04:25:16 nerdboy: sure couple hours is ok Nov 13 04:26:43 thaytan: i do it every few weeks Nov 13 04:27:14 should make a bumper sticker of that one... Nov 13 05:14:08 i guess there were more updates than i thought... Nov 13 05:14:38 only half done so far, so it must've invalidated most/all of my cache Nov 13 06:59:35 b1gtuna: almost baked Nov 13 06:59:58 currently churning on webkit-gtk... Nov 13 07:21:28 nerdboy: kk Nov 13 07:22:37 it's on do_rootfs so we'll know pretty quick if any deps are jacked up Nov 13 07:26:00 hmm if it has reached rootfs, doesn't it mean the package has been fetched? ie, no 404? Nov 13 07:26:25 yup Nov 13 07:27:03 i think the last of the deps get resolved when things get installed into the image Nov 13 07:27:36 b1gtuna: either fetched or it was already in downloads Nov 13 07:29:21 okay, it's done Nov 13 07:29:34 just a few license and relocation warnings Nov 13 07:31:45 hmm Nov 13 07:31:54 can u do a clean on that particular package, and try again? =P Nov 13 07:34:17 what version was not found? Nov 13 07:35:25 yup, i just a 404 trying to fetch it Nov 13 07:36:15 libmpd-11.8.17 Nov 13 07:36:17 hmm ok Nov 13 07:36:21 thanks for confirmation Nov 13 07:36:41 do these kind of breakges get fixed by upstream devs? Nov 13 07:37:06 looks like sourceforge is obsolete Nov 13 07:37:30 the SRC_URI needs to point to http://www.musicpd.org/download/mpd/ Nov 13 07:39:32 ya i do have the patch for it. Was wondering if anyone else cares Nov 13 07:39:52 i can only fix it in my bbappend Nov 13 07:39:59 i would file a bug Nov 13 07:40:17 you found it man, own it Nov 13 07:40:23 ;) Nov 13 07:43:16 i'm still trying to figure out how meta-openembedded libmpd went from 0.17.1 to 11.8.17 Nov 13 07:43:32 what? Nov 13 07:44:08 hmm Nov 13 07:44:25 latest stable is 0.18.3, so i have no idea what 11.8.17 is Nov 13 07:44:37 what the heck that's odd Nov 13 07:44:41 anyone care to fess up? Nov 13 07:44:47 i already asked in the mailing list Nov 13 07:44:51 so far no response Nov 13 07:45:27 and now you can't fetch from sourceforge Nov 13 07:45:35 fail Nov 13 07:45:44 file a bug, please Nov 13 07:45:55 kki will thanks nerdboy Nov 13 08:56:11 What is PRIVATE_LIBS variable and what it does Nov 13 09:50:52 morning all Nov 13 10:25:52 What is PRIVATE_LIBS variable and what it does?? Nov 13 10:38:22 RP: seems I can run screen as root inside the nspawn environment. Nov 13 10:38:32 RP: but that does not work with Yocto. Nov 13 10:38:43 sudo screen does not work either because: sudo: effective uid is not 0, is sudo installed setuid root? Nov 13 10:39:54 lpapp: is it BB's sudo? Nov 13 10:41:21 BCMM: no, just 'su' Nov 13 10:41:39 or you mean sudo screen? Nov 13 10:41:43 that is just sudo as usual. Nov 13 10:41:47 without any Yocto involved. Nov 13 10:41:51 wait, are you using sudo or su? Nov 13 10:42:41 both, that is what I am explaining.... Nov 13 10:42:44 sudo does not work as written. Nov 13 10:43:17 I wonder if it related to some permission problems. Nov 13 10:43:25 ls -ld /dev/console Nov 13 10:43:26 crw------- 1 root root 136, 5 Nov 13 10:39 /dev/console Nov 13 10:43:28 lemme change that... Nov 13 10:43:46 ls -l /bin/su /bin/sudo Nov 13 10:44:09 still the same issue... Nov 13 10:44:15 on busybox systems, BB's implementation of su is often used in place of the normal one Nov 13 10:44:18 that will not help, really. Nov 13 10:44:26 it's diagnostic, not a fix... Nov 13 10:44:27 it is /not/ busybox. Nov 13 10:44:31 ah, ok Nov 13 10:44:37 it is the host system Nov 13 10:44:45 the permission problem has to be fixed Nov 13 10:44:51 but chmod 660 /dev/console did not help. Nov 13 10:45:24 what was the error from screen? sometimes it fails due to permissions on /run or /var/run, not on the console Nov 13 10:47:57 the one I showed above. Nov 13 10:51:55 BCMM: /run and /var/run are 755 Nov 13 11:00:22 Hey. Nov 13 11:00:47 Anyone know how to refer to other packages from a recipe? Trying to create a recipe for Squid, and I DEPEND on "db", the Berkeley DB. Nov 13 11:01:22 Anyone know how I can get the path to that DB as a variable? Then I can say EXTRA_OECONF = " --with-db=${var_to_path} " Nov 13 11:03:48 Stygia: the path you specify there needs to point into the sysroot though, not into where db is built Nov 13 11:04:15 bluelightning, Ah, so something sort of like ${D}${bindir}? Nov 13 11:04:27 Even if the tool isn't yet a part of the image? Nov 13 11:05:39 Stygia: it'll be somewhere under ${STAGING_DIR_HOST} Nov 13 11:06:00 the image doesn't come into it, that's much later... the sysroot exists for this precise purpose Nov 13 11:06:25 as long as you have DEPENDS set appropriately to ensure db gets built first, that is sufficient Nov 13 11:06:26 Ah, right, thought it was weird, I have the terms made up. Hmm, any way to expand STAGING_DIR_HOST outside a recipe, so I can find the appropriate subdir? Nov 13 11:06:51 bitbake -e your-recipe | grep ^STAGING_DIR_HOST= Nov 13 11:07:01 Ah, fantastic! Cheers mate. Nov 13 11:10:02 got screen working with some chmod o+rw /dev/console and then /run/screen hack. :D Nov 13 11:17:50 how is it guaranteed that bitbake virtual/kernel -c menuconfig configured the kernel in my layer? Nov 13 11:17:57 i.e. not just append, but a full replacement for core? Nov 13 11:29:30 Hmm. If you're still around bluelightning, I'm unfortunately stuck on making a recipe for squidGuard. Nov 13 11:29:34 This is the recipe and output: http://pastebin.com/jURujuye Nov 13 11:30:03 What bothers me is that it says, "checking for db.h ... yes", seeming to indicate that it finds the database as it sould. Nov 13 11:30:07 Stygia: s/DEPEND_${PN}/DEPENDS/ Nov 13 11:30:49 and if this is an autotooled piece of software you should inherit autotools instead of running configure yourself Nov 13 11:31:08 I tried to inherit autotools, but I had no luck with it. Nov 13 11:31:18 Maybe it was because of the depends block, hang on... Nov 13 11:31:24 when you say you had no luck, what do you mean? Nov 13 11:31:26 Without _${PN}? Nov 13 11:31:39 Well, this exact same error occurred, it couldn't find Berkeley DB. Nov 13 11:31:40 yes, DEPENDS is for the recipe, not an output package -> no package suffix needed Nov 13 11:32:01 Hmm, right. Nov 13 11:32:06 right, but that doesn't mean you should rip out the inherit ;) Nov 13 11:32:09 That makes sense, actually, RDEPENDS makes sense in package context. Nov 13 11:32:24 Nope, fair enough! Just wanted to try it manually. Nov 13 11:32:59 if you want to see what arguments are being sent to configure with "inherit autotools" you can see those in log.do_configure Nov 13 11:33:04 FWIW Nov 13 11:34:03 Yes, cheers mate, I was doing that! I get this: http://pastebin.com/kmMB3PN0 Nov 13 11:34:30 And, unfortunately, there's no difference in the results if I say EXTRA_OECONF = " --prefix=${STAGING_DIR_HOST} " Nov 13 11:35:06 that wouldn't be correct anyway Nov 13 11:35:35 AFAICT you need to add what the error message complains about to EXTRA_OECONF Nov 13 11:35:42 It wouldn't? As a prefix for libs and such? Nov 13 11:35:58 Yes, as --with-db=${STAGING_DIR}, etc? Nov 13 11:36:13 STAGING_DIR_HOST, but yea. Nov 13 11:36:15 you want the software to work at runtime - so telling it the prefix is within the sysroot won't work, because at runtime on the target that path will not exist Nov 13 11:36:34 Stygia: yes Nov 13 11:39:00 Well, I did already try that, with no change w.r.t results, though. Trying it again... No luck with our without prefixing ${libdir} to STAGING_DIR_HOST for --with-db-lib, ${incdir} for --with-db-inc, etc. Nov 13 11:43:26 Stygia: right, I'd expect that Nov 13 11:49:11 bluelightning, Expect that to work, or expect it to fail? Nov 13 11:49:26 Stygia: expect that ${libdir} and ${incdir} would be needed there Nov 13 11:49:39 bluelightning, Ah right, well unfortunately either way I had no luck. Nov 13 11:49:55 it's asking you to point to the actual library and include directories, so you'd need to actually do that Nov 13 11:50:47 so, if it still doesn't work, you need to have a look at what check the configure script is doing and why that's failing Nov 13 11:51:07 Yup, I am. Nov 13 12:41:48 :-) Nov 13 13:12:39 why does i2c-tools depend on Yocto? Nov 13 13:12:43 why does i2c-tools depend on perl?* Nov 13 13:14:42 maybe one of them is a perl script? Nov 13 13:16:13 yikes, there are some perl scripts, too, not just the "main" binaries. Nov 13 13:48:54 hi, this is in my conf/local.conf: IMAGE_FEATURES += "package-management ssh-server-openssh i2c-tools" Nov 13 13:49:09 yet, I cannot find the i2c-tools binaries in my core-image-minimal after building and flashing it. Nov 13 13:49:12 what is wrong? Nov 13 13:49:22 i2c-tools is coming from our distro layer. Nov 13 13:49:30 we do not integrate meta-oe just for this. What can go wrong here? Nov 13 13:51:32 lpapp, I don't i2c-tools is an image feature. you probably want IMAGE_INSTALL += " i2c-tools" Nov 13 13:53:39 blitz00: you mean IMAGE_INSTALL_append? Nov 13 13:53:46 right Nov 13 13:54:11 what is the difference between += and _append? Nov 13 13:54:14 just syntax? Nov 13 13:56:58 lpapp: _append will be added at the end of the parsing, so it is guaranteed to be there. += is an immediate assignment. so if AA += "BB" is followed later by AA = "CC", then it would be lost Nov 13 13:57:20 not quite. If you used _append you need to add a space between the quote and the package name. But that's only syntax. Append uncondtionally append to the variable, whereas with += you can have ordering issues as it's right away assign, and something else can override it Nov 13 13:57:28 also += will add 'spaces', while _append does not. Nov 13 14:00:40 ndec: blitz00 thanks for the explanation. Nov 13 14:00:46 np Nov 13 14:03:20 you're welcome Nov 13 14:11:48 IMAGE_FEATURES takes features, not package names Nov 13 14:12:17 current versions fully validate items added to IMAGE_FEATURES so this kind of think can no longer pass without error Nov 13 14:12:25 s/think/thing/ Nov 13 14:31:06 hi, is there a 'nice' method to handle upstream packages which requires ./configure && make && make install? in different folders, such as root/configure.ac, root/foobar/configure.ac? Nov 13 14:31:26 i know it's bad... but i can't really fix that, and i need to be able to build with a recipe.. Nov 13 14:41:28 ndec: could you separate them into several recipes? Nov 13 14:41:48 if yes you could set the S variable in each recipe accordingly Nov 13 14:42:29 well, that brings another problem ;-) the upstream are in SVN, so i end up with fetching svn://xxxxx/root and svn://xxxx/root/foobar in 2 different recipes Nov 13 14:42:35 and that messes up the download folder.. Nov 13 14:43:17 ndec: you can fetch svn://xxxxx/root in both, then the download cache hits Nov 13 14:44:02 what is the 2 fetch happens in //, in different bitbake threads? Nov 13 14:44:37 ndec: I think there is a locking mechanism used Nov 13 14:44:45 ok. i can try that. Nov 13 14:51:13 tobiash: so, it seems there is no such lock mechanism. it is trying to fetch the repo twice simultaneously. Nov 13 14:51:16 and fails. Nov 13 14:54:22 hmm.. ok, this very ugly workaround works: do_fetch[depends] =+ "foobar:do_fetch"... at least it's no longer fetching in // now... Nov 13 14:59:58 ndec: sounds like a bug in the fetcher Nov 13 15:52:04 hey, if I modify a patch file manually (inserting + lines), will yocto repeatch the source? Nov 13 15:52:09 for bitbake core-image-minimal? Nov 13 15:52:18 trying to modify a kernel patch like that... Nov 13 15:55:08 oh, it will. Nov 13 15:55:30 hmm... i would have thought it wouldn't ... Nov 13 16:16:46 the system takes a checksum of all local files in SRC_URI and adds it into the signature for do_fetch Nov 13 16:17:34 thus if you modify a local file such as a patch referred to by a recipe, that causes the recipe's do_fetch and all tasks that depend upon it to re-execute Nov 13 16:19:15 blitz00: thanks Nov 13 16:19:21 bluelightning: thanks, even. :) Nov 13 16:19:44 bluelightning: that's neat. i didn't know about that! Nov 13 16:19:58 a hidden gem :) Nov 13 16:20:49 there are just so many of them... Nov 13 16:22:57 it's not currently documented; I'm not quite sure where the appropriate place to insert it would be though Nov 13 16:23:42 it *might* fit into the new section Scott is writing on the workflow for writing new recipes Nov 13 16:26:54 I've entered a doc enhancement bug for now Nov 13 16:27:04 bug 5521 Nov 13 16:27:05 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5521 enhancement, Undecided, ---, scott.m.rifenbark, NEW , Document file checksums Nov 13 16:56:35 gah, this random, intermittent missing variable dependency bug is getting really old. sometimes, seemingly only in our automated builds, a task will fail due to a shell function it tried to call not having been emitted, because the dep scanning code somehow missed it Nov 13 16:56:48 re-running the build on the same machine seems to get past it Nov 13 17:27:21 kergoth: master or with old code? Nov 13 17:28:07 yocto-1.5.final Nov 13 17:29:22 kergoth: wouldn't be what I was thinking about (methodpool) Nov 13 17:29:50 kergoth: although I guess something similar to do with parsing and contexts might still be the case Nov 13 17:30:04 what's particularly irritating is it's not reprodicible, makes it hard to add any useful debugging. Nov 13 17:30:21 kergoth: the methodpool bug was like that Nov 13 17:30:26 very annoying Nov 13 17:38:37 hi guys Nov 13 17:38:52 is it somehow possible to tell Bitbake that we're offline, without having _git.bb packages fail? Nov 13 17:39:19 basically, AUTOREV fails without network connection Nov 13 17:40:35 and I'd just like it to use the existing git checkout without bailing out. Nov 13 17:40:51 Sput: AUTOREV requires a network connection, if you want to do offline builds, you need to have fix git hash references in SRCREV instead. This is why oe-core does not use AUTOREV Nov 13 17:41:24 sgw_: so there's no way to build completely unrelated packages while being offline, without trying to get various upstreams to change their packages? Nov 13 17:42:24 (the problem being that bitbake tries to expand AUTOREV while building the dep cache, and even though the package I want to build is unrelated to the package in question, it bails out) Nov 13 17:42:30 Sput: not if you use AUTOREV Nov 13 17:42:43 meh. that is rather unfortunate. Nov 13 17:43:19 Sput: right, the work around if you know the git ref you have on your system, you can override the SRCREV with that git ref Nov 13 17:43:37 but then I have to go around and patch packages in unrelated upstream layers :/ Nov 13 17:43:39 the other is to have a locla mirror of all of the autorev SCMs.. Nov 13 17:43:46 point the system those those instead.. Nov 13 17:43:52 you just have to remember to update them yourself Nov 13 17:44:21 Sput: you don't have to patch the package directly you can set the SRCREV overrides in your local.conf Nov 13 17:44:42 Sput: and yes you might consider that patching vs overriding Nov 13 17:44:53 sgw_: oh, that works per-package? SRCREV_packagename? Nov 13 17:45:03 Sput: yes it does Nov 13 17:45:04 SRCREV_pn-recipename Nov 13 17:45:05 well, I'll have to talk to the meta-ivi and the meta-ros guys then Nov 13 17:45:29 Sput: poky-bleeding.conf is an example of how you can apply this Nov 13 17:46:24 Sput: in reverse, since poky-bleeding sets everything to AUTOREV! Nov 13 17:46:36 aaah, thx Nov 13 17:46:49 Sput: you can also extract these values after a build if you have buildhistory enabled by using the "buildhistory-collect-srcrevs" tool Nov 13 17:47:48 that sounds good Nov 13 17:49:20 thx for the help so far, will play around with that Nov 13 17:50:28 well, 7289 tasks to build, I guess I'll go home then :) Nov 13 19:13:55 * kergoth plays around with ptest Nov 13 19:18:24 Does anyone know how to use the Git submodule fetcher (gitsm) in Yocto. I can't figure out the syntax? Nov 13 19:18:50 RP: ^ Nov 13 19:20:44 It's not clear on the syntax in the recipe. Nov 13 19:21:45 Will gitsm fetch the base Git repo and then any submodules? Do you have to specify the submodule names somewhere? Nov 13 19:22:30 GlennS_: according to my reading of the commit message for the commit that added it, it should work exactly like the standard git fetcher except it will fetch submodules Nov 13 19:22:41 so you shouldn't need to add anything special for submodules Nov 13 19:23:30 So just replace git:// with gitsm:// then Nov 13 19:24:55 right, that's the idea Nov 13 19:25:40 sounds nice in principle, but it doesn't appear to work for me. Here's a URL to try: SRC_URI = "gitsm://github.com/fluendo/gstreamer.git;protocol=git" Nov 13 19:25:56 Fails to fetch the "common" submodule in that repo. Nov 13 19:26:28 fails how? Nov 13 19:27:46 Specifically, in the unpack() function of gitsm.py it fails on the "git submodule update". Nov 13 19:28:51 I believe (for some reason) the overriden "download()" method is not being called and subsequently the "update_submodules" isn't being called which creates a "*.tmp" directory. Nov 13 19:41:40 GlennS_: ok... i never used gitsm.. just trying it now to see if it fails too.. Nov 13 19:42:42 I checked again. It is calling download() in gitsm.py and does all the update_submodule() steps successfully. It's just the unpack() that fails at the last line (git submodule update). Nov 13 19:45:41 It fails because it cannot switch to a "temp" directory that is removes in the last step of "update_submodules()" in gitsm.py. Nov 13 19:45:44 GlennS_: just tried it here, seems to work Nov 13 19:45:50 Hello, I want to add few default user to my default image. I think the easier way to do is is to use ROOTFS_POSTPROCESS_COMMAND in my image recipe. But I don't understand how to do this a clean way. Nov 13 19:46:06 GlennS_: you didn't perchance try git:// first and then switch over to gitsm:// ? Nov 13 19:46:18 I wish I could figure this out. I'll try a dummy a recipe again. Nov 13 19:46:39 GlennS_: hmm.. it fails for me too. Nov 13 19:46:46 weebette: which version of the build system are you using? Nov 13 19:46:47 i think i am on dylan, atm. Nov 13 19:47:34 weebette: check the useradd class Nov 13 19:48:08 and this, even, openembedded-core/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb Nov 13 19:48:25 bluelightning : I am unsure of my build system version. The one that comes with danny ? Nov 13 19:48:33 thanks ndec Nov 13 19:48:36 weebette: ah right, danny is what I was after Nov 13 19:49:08 so you can create a "dummy" recipe to do it using useradd.bbclass, or do it by hand as you were thinking Nov 13 19:49:22 in dora (1.5) there is also extrausers.bbclass for this express purpose Nov 13 19:50:07 * bluelightning heads out Nov 13 19:50:27 I don't have extrausers.bbclass in my install Nov 13 19:51:10 thanx ndec for the hint for the example Nov 13 19:51:35 ndec > so it fails for you too? Nov 13 19:52:42 GlennS_: yes. i think i found why... Nov 13 19:53:46 argh.. no.. Nov 13 19:54:34 Fails for me any with a dummy recipe. Nov 13 19:56:24 I think I'm on dylan at the moment. Nov 13 20:00:12 GlennS_: hmm. i have the feeling that it fails in update_submodules() but there is a not error/exception there, and it tries to continue... Nov 13 20:02:31 I commented out the last line in "update_submodules" . . . the one that removes the temp GIT repository that is updates with the modules. The unpack step works now but all is still not right. Nov 13 20:18:20 I think I know what the problem is. They can't just "copy" the "modules" directory from the clonedir to your work "git" directory. It has a hard-coded path in the config directory that references a "tmp" directory that is created and deleted at the end of "update_submodules". Nov 13 20:18:42 That's why the update fails. Nov 13 20:22:28 i think it's something that changed in git recently, so it might work with newer git. Nov 13 20:22:39 i am looking at git log Nov 13 20:25:33 GlennS_: i think we need git 1.7.10+ to get that to work, see Nov 13 20:25:36 $ git describe --contains d75219b Nov 13 20:25:36 v1.7.10-rc1~14^2~2 Nov 13 20:25:47 d75219b submodules: always use a relative path from gitdir to work tree Nov 13 20:26:07 i am running on 12.04 which has 1.7.9 Nov 13 20:26:12 how about you? Nov 13 20:28:08 GlennS_: and the actual commit is here: https://github.com/git/git/commit/d75219b Nov 13 20:34:48 I'm running 12.04 as well. Nov 13 20:35:11 With git 1.7.9.5 Nov 13 20:36:22 GlennS_: so, i think this needs to be reported on the OE list. Nov 13 20:36:44 I totally agree. I'm sure a lot of people stick to the LTS release. Nov 13 20:37:04 at least this fetcher would need to make sure that git version is right, or update core.worktree accordingly. Nov 13 20:37:16 GlennS_: yep. Nov 13 20:37:49 I guess for now I may need to update my git. Nov 13 20:38:48 I'm a little new to this . . . but where should this bug be reported - OE or Yocto? Nov 13 20:41:10 GlennS_: OE, in this case. Nov 13 20:41:33 openembedded-core@lists.openembedded.org Nov 13 20:41:45 feel free to copy/paste our conversation, too. Nov 13 20:41:53 i will monitor the list if needed. Nov 13 21:11:50 * mranostay waves Nov 13 21:12:25 Ended up logging a ticket in Yocto Bugzilla. OE says to log tickets there for these foundational components. Nov 13 21:12:43 FYI: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5525 Nov 13 21:12:44 Bug 5525: normal, Undecided, ---, richard.purdie, NEW , gitsm.py fetcher requires git version > version 1.8.5 Nov 13 21:15:08 GlennS_: ok, thanks Nov 13 22:50:01 seebs: fray: I was wondering if I could get some help with bitbake recipe that I am trying to write for clang. Nov 13 22:50:21 Possibly! Although I have to run out for an errand at the moment. Nov 13 22:50:22 I am stuck at some "QA" issue when trying to bitbake my clang recipe. Nov 13 22:50:35 NP. I am not in a hurry at the moment. Nov 13 22:51:15 mtahmed: did you set up and github site? I'm wondering if you should clone poky or add a layer. Nov 13 22:51:31 could you pastebin your QA problem? Nov 13 22:51:33 vmeson: Also for "staging my work" what should I fork? poky? Nov 13 22:51:52 Oh, yes, that's what I wanted to ask. Nov 13 22:51:55 mtahmed: I'm not 100% certain but poky would be my starting point. Nov 13 22:51:58 And I will do that. Nov 13 22:52:55 is that the repo that you started with? Nov 13 22:53:07 Yes. Nov 13 22:55:44 mtahmed: http://pastebin.com/ the logs? Nov 13 22:55:56 The log for the issue I am having: http://sprunge.us/ZNZh Nov 13 22:56:35 sprunge! Much cleaner :D Nov 13 22:58:26 I don't see any up-to-date mirrors for poky on github. Nov 13 22:58:42 I will push my own. Nov 13 23:00:07 The problem I am having is not properly understanding this "package splitting" concept. Nov 13 23:00:35 It says I have static-dev files in non-static-dev package or something along those lines. Nov 13 23:01:10 Why can't I have one package with everything? Incuding the static-dev files, the other header files, libraries, and binaries? Nov 13 23:01:22 That is the question I have. Nov 13 23:04:56 howdy Jefro Nov 13 23:10:47 mtahmed: looking... Nov 13 23:11:50 mtahmed: you can, if you want to disable the QA checks, but highly granular packaging gives you much more control over the contents of your images, which is always appropriate when dealing with embedded systems Nov 13 23:11:51 so the 2nd group of errors: ERROR: QA Issue: non -staticdev package contains static .a library: clang3.3-dev path '/work/i586-poky-linux/clang3.3/3.3-r0/packages-split/clang3.3-dev/usr/lib/llvm3.3/libLLVMARMAsmPrinter.a' Nov 13 23:14:21 Yes. Nov 13 23:14:25 for package splitting, check other distros for a starting point. Ubuntu: http://sprunge.us/SeAI Nov 13 23:15:47 Okay ... like that. Makes sense. Nov 13 23:16:13 and the default list of packages seems to be: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} Nov 13 23:16:21 from http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html Nov 13 23:17:15 so your goals is to make the clang recipe put the .a files in a subdir or somethign so they can be separately packaged. Nov 13 23:17:22 *goal Nov 13 23:18:07 Makes sense. I was looking at an older version of docs :( Nov 13 23:18:07 * vmeson looks for an example... Nov 13 23:18:10 http://docs.openembedded.org/usermanual/usermanual.html#id325388 Nov 13 23:18:32 No I understand. I was splitting them but not into staticdev as well. I will do that. Nov 13 23:18:34 FILES_${PN}-staticdev += "${libdir}/llvm3.3/*.a" Nov 13 23:18:36 problem solved Nov 13 23:18:39 :) Nov 13 23:18:50 :D Thanks. Nov 13 23:19:06 np **** ENDING LOGGING AT Thu Nov 14 02:59:59 2013