**** BEGIN LOGGING AT Wed Aug 27 02:59:58 2014 Aug 27 03:10:28 hello channel Aug 27 03:10:47 does anyone here ever used the de2i-150 board with yocto? Aug 27 06:07:59 hi, I run bitbake on gentoo, I have Error on "do_compile" & "do_package" for "qt4-x11-free" package. I googled but wasn't successful... How can I fix this problem? Aug 27 06:26:20 someOne_: what is the problem ? Aug 27 06:33:13 khem: the problem is : QA ISSUE in do_package_qa task and the compile log indicates that host include and/or library paths were used. please check the log '${workdir}/temp/log.do_compile' for more information.(but in this file, there isn't extra information) Aug 27 07:44:01 someOne_: that means cross compile env is not clean for this package Aug 27 07:44:13 qt4-x11-free Aug 27 07:48:08 khem: gm, we got split yesterday Aug 27 07:52:13 khem: so what should I do to set the enironment? I deleted the build directory & run again... but again this error happend!! Aug 27 07:53:18 enironment --> environment Aug 27 07:55:35 khem: --with-gxx-include-dir, --with-sysroot and --with-build-sysroot are absolutely wrong here Aug 27 07:57:18 it mixes armv4 and armv5...how can that happen? Before last changes we had issues with multimachine-builds of the same arch but even in my worst nightmares I'd never expect two archs to mix up Aug 27 09:43:31 <_valle_> Anyone gotten mongodb to work on daisy? Aug 27 14:28:22 hi guys, I want to use the qt4 meta toolchain for crosscompile a qt4 application. Do I need to have all the yocto built rootfs or the toolchain tar is enought? Aug 27 14:28:48 I'd like to use qtcreator Aug 27 14:39:35 rspock: the toolchain tarball should be enough Aug 27 14:39:54 rspock: depends what else your app links against I guess Aug 27 14:41:41 I have a couple of external library such as qserialport and libqxt but I can compile them by hand Aug 27 14:42:09 and linking by hand Aug 27 14:42:41 the main question is, does the qt library get linked by the toolchain? Aug 27 14:43:42 * Crofton|work is getting ready to go all postal over work Aug 27 15:12:54 which fossology version does the spdx.bbclass support? it is not the latest, that's for sure. Aug 27 15:24:04 I just noticed a problem in master. I set two packages to use autorev while I try to fix some bugs only appearing on hardware. Those packages do rebuild once the changes are committed, but the images don't regenerate. I've seen twice where I rerun the image and see it rebuild the two packages but when I then check in the device image, it has the old version of the programs. anyone have ideas what I may be doing wrong? Aug 27 15:46:13 never mind, found the issue I had Aug 27 16:06:54 blloyd: does clearing the cache help? Aug 27 16:07:30 blloyd: if so, that would point at a caching issue with dependencies on autorev recipes Aug 27 16:14:37 blloyd: are those 2 recipes pulled into image through packagegroup? Aug 27 16:59:29 anyone seen their build shut down out of nowhere with '[Errno 4] Interrupted system call' ? Aug 27 18:13:46 RP: clearing cache does help. So does a bitbake -c cleansstate IMAGENAMES. Aug 27 18:15:05 JaMa: they are included via IMAGE_INSTALL += "..." in the given images. Aug 27 18:36:44 does the git fetcher in bitbake 1.22 (yocto 1.6) only work with annotated tags now? from what i've read online and in practice, it certainly seems to be the case Aug 27 18:39:00 jgilles: no it should work fine with lightweight ones Aug 27 18:39:18 hm Aug 27 18:39:40 but it's always safer to use annotated ones for your own repos Aug 27 18:39:54 i have numerous recipes i've been using with yocto 1.5 that no longer fetch with either "tag=" in SRC_URI or SRCREV="tag" Aug 27 18:40:18 what does "no longer fetch" mean? Aug 27 18:40:21 and it is only recipes that have lightweight tags Aug 27 18:40:23 isn't it because of incorrect branch? Aug 27 18:40:24 actual errors are much more useful than summary Aug 27 18:40:30 yeah, one sec Aug 27 18:40:38 e.g. the tagged commit not included in any branch? Aug 27 18:41:51 that happens quite often, not all tags reference commits that are on a branch. if the fetcher is assuming that, it's a bug Aug 27 18:42:00 ERROR: Function failed: Fetcher failure for URL: 'git://github.com/hparra/ruby-serialport.git;tag=v1.1.0;protocol=git'. The command git ls-remote git://github.com/hparra/ruby-serialport.git refs/heads/v1.1.0 refs/tags/v1.1.0^{} gave empty output unexpectedly Aug 27 18:43:12 v1.1.0 in that repo is a lightweight tag Aug 27 18:43:33 i get that same exact git ls-remote error with other recipes referencing lightweight tags Aug 27 18:43:53 I'd open a bug in bugzilla and email the list about it, personally Aug 27 18:44:01 if i change SRCREV to the SHA hash of the commit, it's fine, and other recipes that use annotated tags work Aug 27 18:44:43 ok, just checking to see if there was something i was missing Aug 27 18:45:18 same issue as this one i think: http://stackoverflow.com/questions/24574954/bitbake-git-fetcher-failure Aug 27 19:21:55 kergoth: fetcher supports nobranch parameter Aug 27 19:22:09 kergoth: so you can explicitly say that for tags like this Aug 27 19:22:40 the whole thing is just terrible usability. having to force the user to set branch= to match SRCREV, all of it is just a giant pain in the ass Aug 27 19:23:15 jgilles: you shouldn't be setting SRCREV=tag Aug 27 19:23:46 SRCREV should be just srcrev and latest code IIRC checks that if you provide SRCREV and a tag in SRC_URI that they should match Aug 27 19:24:28 kergoth: well it's useful at least when you set SRCREV = AUTOREV it won't leave the branch you've started from Aug 27 19:25:27 jgilles: and even better is not to use tags in SRC_URI.. because that causes git ls-remote every time you're parsing metadata Aug 27 19:25:51 to map tag name to actual SHA Aug 27 19:26:05 so all the nice build-ability without network just from local premirror is gone Aug 27 19:26:25 unless you trust your cache Aug 27 19:26:52 but then you can have 2 builders which are both building tag v1.0, but both with different source Aug 27 19:28:20 so what we're doing in webOS world is to enforce annotated tags and then WEBOS_VERSION sets not only the name of the tag, but also it's SRCREV and webos_enhanced_submissions.bbclass checks that they match Aug 27 19:28:32 I think we jump through way too many hoops to support autorev. it adds *massive* complexity. i think the better choice would have been to support an srctree/externalsrc + automatic srcrev approach only, personally Aug 27 19:29:21 s/it's/its Aug 27 19:29:54 iirc there was another corner case when fetcher didn't do the right thing without knowing the branch Aug 27 19:29:55 with an external local tree, things get simpler, not limited to ls-remote Aug 27 19:30:04 RP mentioned it in commit message I guess Aug 27 19:30:38 yes, but you cannot (easily) share local tree with other developers Aug 27 19:31:53 i don't really see that as much of a problem, just wrap your bitbake execution in a git pull in your local copy first. handle it at a level above/before bitbake Aug 27 19:31:58 * kergoth shrugs Aug 27 19:38:35 the tag is on a branch, btw Aug 27 19:39:08 it's just a lightweight tag versus an annotated one, that is the only pattern I see with recipes that fail to fetch Aug 27 19:41:53 jgilles: have you tried removing SRCREV or setting it to actuall SHA? Aug 27 19:42:07 yeah, setting SRCREV to SHA works Aug 27 19:42:15 then the tag is not refrerenced at all though Aug 27 19:42:19 so it is useless Aug 27 19:51:23 removing SRCREV and using tag= in SRC_URI doesn't work Aug 27 19:54:01 setting SRCREV=SHA and tag= in SRC_URI both results in an error Aug 27 19:54:08 ERROR: Function failed: Fetcher failure: Conflicting revisions (709e385f6d20aaadc7f3252af59250336d27e607 from SRCREV and v1.1.0 from the url) found, please spcify one valid value Aug 27 19:54:40 so, anyway, workaround is to just use SRCREV=SHA and put a comment in about what tag it really is Aug 27 20:05:08 * mranostay spots a rogue dvhart Aug 27 20:09:07 guys is there a way to move all the meta-toolchain path to another machine? Aug 27 20:09:38 I tried to tar the folder and the untar but the qmake dosn't work Aug 27 20:10:12 I get Yocto/build/sdk/poky/1.5.3/sysroots/x86_64-pokysdk-linux/usr/bin/qmake': No such file or directory when trying to add to Qtcreator Aug 27 20:43:46 21:51:33 < jgilles> removing SRCREV and using tag= in SRC_URI doesn't work Aug 27 20:43:53 this show work, what's the error? Aug 27 20:45:18 JaMa; ERROR: Function failed: Fetcher failure for URL: 'git://github.com/hparra/ruby-serialport.git;tag=v1.1.0;protocol=git'. The command git ls-remote git://github.com/hparra/ruby-serialport.git refs/heads/v1.1.0 refs/tags/v1.1.0^{} gave empty output unexpectedly Aug 27 20:46:43 again, it works fine if the tag is an annotated tag Aug 27 20:46:47 just fails if it's a lightweight tag Aug 27 20:47:11 same recipe referencing a lightweight tag in SRC_URI worked fine with bitbake 1.20 (dora) Aug 27 22:56:16 we should make the fetcher fall back to trying a lightweight tag, I thought someone was going to send a patch, or its got lost in the system Aug 27 22:59:48 what is a light weight tag? Aug 27 23:00:19 tag created without -a in "git tag" Aug 27 23:00:52 doesn't have own message, date and SHA - only adds "name" to existing commit Aug 27 23:01:11 yeah, a light weight tag is a ref just like a branch is, doesn't use the tag object type Aug 27 23:01:17 refs/tags/ instead of refs/heads/ Aug 27 23:03:34 I have different problem with fetcher now.. I've recipe with many git repos in SRC_URI (instead of git submodules) Aug 27 23:03:47 so I have a lot of SRCREV_foo = "something" variables Aug 27 23:04:30 but they are not included in PV Aug 27 23:04:55 and changing one of them doesn't triger do_fetch + do_unpack re-execution :/ Aug 27 23:05:17 see SRCREV_FORMAT Aug 27 23:05:40 SRCREV_FORMAT = "foo_bar" will separate the foo srcpv and bar srcpv with _ Aug 27 23:05:44 iirc anyway Aug 27 23:05:50 see the user manual Aug 27 23:06:12 yes, but I don't want 15 SRCREVs in PV Aug 27 23:06:30 you can't have it both ways. either it's part of pv, or it isn't :) Aug 27 23:07:01 that said, ideally changing srcrev would affect fetch checksums whether you're usig srcpv or not Aug 27 23:07:07 I don't want them in PV, I just want do_fetch + do_unpack to fetch right SRCREVs Aug 27 23:07:18 yes, that's what I wanted :) Aug 27 23:07:47 you'd have to grab the names out of SRC_URI at parse time and check for SRCREV_ for each ,i think, and add those to vardeps. do_fetch[vardeps] += "${@get_srcrev_vars(d)}" Aug 27 23:07:55 * kergoth shrugs Aug 27 23:08:14 might want to open a bug on that one Aug 27 23:08:19 I've tried this with do_fetch[vardeps] += "SRCREV_foo SRCREV_bar" .. Aug 27 23:08:30 but it still doesn't change the signature Aug 27 23:09:53 they both set to AUTOREV? probably isn't translated at that point Aug 27 23:10:15 no, all are set to some locked revisions Aug 27 23:10:39 and I should say that right now I'm testing it with dylan, will try to reproduce it in master as well Aug 27 23:15:04 FFS.. wait a bit I'm retesting everything.. Aug 27 23:15:48 I've included them all in do_fetch[vardeps], but the one I'm testing the change, was copied with one character missing (RCREV_foo), sigh Aug 27 23:15:51 sorry Aug 27 23:24:00 seems to be working now Aug 27 23:24:05 * JaMa goes to bed to sleep in shame Aug 28 02:04:20 halstead: you there ? Aug 28 02:04:43 halstead: eglibc.org is down, do you have handle on it ? **** ENDING LOGGING AT Thu Aug 28 02:59:58 2014