**** BEGIN LOGGING AT Wed Aug 12 02:59:59 2015 Aug 12 05:32:29 anyone here has issues using linux-yocto-dev as preffered provider? Aug 12 08:04:30 good morning Aug 12 08:28:10 morning all Aug 12 08:40:26 bluelightning: did u have issues using linux-yocto-dev ? Aug 12 08:40:38 Mine has issues with git revision.... Aug 12 08:41:48 but it did complain about WARNING: Failed to fetch URL git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=standard/base,meta;name=machine,meta, attempting MIRRORS if available Aug 12 08:41:54 parrot1: it's not something I've built myself, I have to be honest Aug 12 08:42:18 and I can attest that my network configuration should be good Aug 12 08:44:09 hmm....I found similar issues like in http://comments.gmane.org/gmane.linux.embedded.yocto.meta-intel/3323 , but I'm not sure if that will spread to yocto-dev since SRCREV is set to ${AUTOREV} Aug 12 08:57:19 parrot1: your best bet is to mail the mailing list and CC bruce ashfield Aug 12 09:10:04 bluelightning: ok. Does bruce hang out in IRC? Aug 12 09:10:28 wanna avoid emailing mailing list if I can help it lol Aug 12 09:11:34 yes, he's zeddii Aug 12 09:11:42 but he's not around atm Aug 12 09:17:19 bluelightning: ok...thanks :-) Will try my luck in IRC and if that doesnt work out, I guess mailing list is the better bet Aug 12 09:21:18 bruce is on holiday right now iirc Aug 12 09:23:38 rburton: u know who took over his task atm? Aug 12 09:26:54 morning Aug 12 09:39:41 Is anyone else using sstate cache in large scale build farms? Any writeups about their setup? We have quite a few problems with it lately, e.g. an uptodate state cache triggering builds of libgcc-initial for example which triggers other bugs and missing build dependencies or race conditions in sysroot. https://lists.yoctoproject.org/pipermail/yocto/2015-July/025856.html Aug 12 13:04:03 Shouldn't I see one variable with flags per task defined in the output of bitbake -e $recipe? Aug 12 13:04:41 E.g., I would expect a variable $do_deploy_archives if the recipe inherits archiver, but my bitbake -e output contains no such thing Aug 12 13:41:15 everyone:: my bitbake version is bitbake version 1.20.0 . I want to know if I have to change something in my own recipe to be able to use them in the last version of bitbake.??? Aug 12 13:44:35 khalebios: the migration section of the reference manual should serve as a guide for what might need changing: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration Aug 12 13:45:32 it's not just the bitbake version that counts, which yocto project version / branch you are using is the important bit of information to know Aug 12 13:46:20 How do I control the current work directory of a task? Aug 12 13:48:06 Is that always $WORKDIR? Aug 12 13:48:48 I'm trying to bitbake the ubi-utils-klibc package, but I'm getting an error, anyone has an Idea how I could fix it ? -- http://pastebin.com/Q2GUgiNe Aug 12 13:48:53 thanks in advance for your help :) Aug 12 13:49:27 neverpanic: it's the first directory specified in the dirs varflag value for the task, if no dirs varflag value is set then its ${B} Aug 12 13:49:46 bluelightning: thanks Aug 12 13:49:56 bluelightning: by branch you mean .. dora , fido? Aug 12 13:50:00 khalebios: yes Aug 12 13:50:17 khalebios: you may find https://wiki.yoctoproject.org/wiki/Releases a useful reference also Aug 12 13:54:03 thanks bluelightning Aug 12 13:58:38 OK, so do_deploy_archives from archiver.bbclass fails because it runs in ${B} (which defaults to ${S}) and can (in recipes that are exempt due to licensing) run before do_unpack, which creates ${S} in recipes that set S to a directory created by do_unpack Aug 12 14:17:48 anyone having problem with the ubi-utils-klibc recipe ? Aug 12 14:31:05 neverpanic: luckily thats easily fixed with a [dirs] assignment Aug 12 14:35:07 Or an "after do_unpack" Aug 12 14:35:50 guys, if I perform bitbake -c cleanall for the image and then execute bibacke image will be packages included to the image re-built? Aug 12 14:36:13 no, they'll be pulled from the sstate-cache (unless the checksum has changed) Aug 12 14:41:08 Ox4`: contrary to what fray said, since you used -c cleanall, the sstate packages would have been removed, so yes Aug 12 14:42:00 (unless you have set up SSTATE_MIRRORS yourself, that is) Aug 12 14:47:03 bluelightning: ok, so I can just use bitbake -c cleanall image in jenkins then :) Aug 12 14:47:11 it's very cool! Aug 12 14:47:14 oh, wait Aug 12 14:47:37 no, I've misread your comment, sorry... Aug 12 14:48:02 -c cleanall on the image will not result in any packages in the image being rebuilt Aug 12 14:48:53 Ox4`: why do you want to do that? Aug 12 14:51:27 bluelightning: because I am developing some package for the image and would like to rebuild the image with the package everytime when I push changes to the git. Aug 12 14:52:08 Ox4` when you rebuild the package the image will know to be rebuilt automatically Aug 12 14:52:17 the image has dependencies on all packages that are contained within Aug 12 14:53:07 if for whatever reason your changes do not automatically trigger the package to be rebuild, you can use: bitbake -C Aug 12 14:53:25 i.e. if you are modifying sources where bitbake can't detect the checksum change.. for the package foo Aug 12 14:53:43 bitbake -C configure foo Aug 12 14:54:15 that will cause configure and all later steps to be run-rune, and a new checksum to be generated (it'll be a false checksum, but different). THis will signal later recipes (dependent on 'foo' to also rebuild, including images) Aug 12 14:55:15 right, in this instance you shouldn't need to do anything, building the image should pick up any changes and re-execute tasks as needed Aug 12 14:56:47 (I should be clear, -if- use need to use -C the full comamnd would be something like bitbake -C configure foo ; bitbake image... since the -C stops at the end of 'foo' recipe tasks) Aug 12 14:57:11 but if you are not modifying files "out from under" bitbake, it will detect the changes and it will all just work.. Aug 12 14:57:24 (out from under, i.e. going into the extracted source directory and modifying things) Aug 12 15:00:11 fray: understood, thanks Aug 12 16:05:40 How would I filter out the -mfpmath=sse CFLAG being added by Yocto for a particular package? Aug 12 18:51:20 RP: any objections to my improving how our python code is compiled so it has correct filenames and line numbers without our having to manually adjust them when examining the traceback? Aug 12 18:51:32 code from the metadata, tha tis Aug 12 19:09:51 okay, with the fetch core modified to support ud.mirrortarballs, the git fetcher will now first try shallow tarball, then full tarball, then clone. now need a flag to separate *use of / fetch of* shallow tarballs from *creation of* shallow instead of full, which right now are the same variable Aug 12 19:18:42 I may be doing a non-trivial pseudo update in the next week or so. Performance hackery. Gonna go do some measurements and stuff first. Aug 12 19:18:47 then need at least one, possibly three options to control clone depth.. Aug 12 19:18:52 Actually, first I'm probably going to add a profiling feature to it. Aug 12 19:19:17 seebs: nice. best test the crap out of that :) Aug 12 19:20:02 yeah Aug 12 19:20:28 So the profiling thing, gonna try to make the client dump a hunk of timing info into a file on exit, if configured to do so. Aug 12 19:20:44 And then you can do a run and sum the info from that file and get total client/server times, in theory. Aug 12 19:21:06 Then do that without other changes to collect some current timing info, then make changes, then compare build results and collect more timing info. Wheeee. Aug 12 19:21:36 The basic change: Where applicable, instead of storing permissions info in the database, store them as extended file attributes. Aug 12 19:22:28 So the database would hold a lot less info. The big question is how to determine whether or not to check the database, because it's not obvious how to tell a file that we never tried to store info about from a file that we failed to store extended attributes on. So I'm still pondering that part. Aug 12 19:22:47 But the theory is, for a lot of the common cases where nothing ever sees a file but the client anyway, there'll be about 99% less IPC traffic and waiting for the server. Aug 12 19:23:35 huh, sounds promising Aug 12 19:25:38 It appears that xattrs work for files, but not for symlinks, so symlinks will still need db entries. Aug 12 19:26:52 Will also likely need some kind of db/fs sync operation. Aug 12 20:42:14 seebs: what metadata do symlinks need? Aug 12 20:42:56 Depends on filesystem, but they can in theory have permissions or owner distinct from that of the thing linked to. Sometimes. Aug 12 20:43:38 I suppose I'd wonder if it's ever the case that symlinks could have perms but not have xattrs. Aug 12 20:45:05 I believe so on ext3ish. Aug 12 20:45:10 At least, on my test system, it appears to be the case. Aug 12 20:45:42 I think. I am a little unsure. Aug 12 20:46:36 yeah. I have an ext4 fs on which I can chown links but not set attributes on them. Aug 12 20:47:03 ah, yes. ownership can be changed. Aug 12 20:47:29 Looks like the simple answer is I can store things as extended attributes for files and directories, but not for other things. Aug 12 21:35:35 ping Aug 12 21:37:34 who exactly are you pinging? if you have a question, ask it Aug 12 21:50:52 I want to add as alternative in oecore toybox instead of busybox. I'm trying adding a virtual dependency, but there is a particular recipe that is getting me an error Aug 12 21:58:07 this is happening when i try to modified meta/recipes-core/packagegroups/packagegroup-core-boot.bb the errros state that Nothing RPROVIDES 'virtual/anybox' Aug 12 22:02:49 this is happening when i try to modified meta/recipes-core/packagegroups/packagegroup-core-boot.bb the errros state that Nothing RPROVIDES 'virtual/anybox' Aug 12 22:04:47 i have tried adding PREFERRED_PROVIDER_virtual/anybox ?= "toybox" PREFERRED_RPROVIDER_virtual/anybox ?= "toybox" at local.conf but the error keeps comming Aug 12 22:12:35 you can't use a virtual/ in a runtime context. it's a build provide, not target Aug 12 22:12:42 e.g. you can't add virtual/anybox to IMAGE_INSTALL or an RDEPENDS Aug 12 22:12:47 only DEPENDS Aug 12 22:13:18 if you want to be able to choose a runtime provider, you'll need to define and use a VIRTUAL-RUNTIME variable. e.g. VIRTUAL-RUNTIME_anybox ?= "busybox", IMAGE_INSTALL += "${VIRTUAL-RUNTIME_anybox}" Aug 12 22:23:32 do you have any documentation or example I can used of a VIRTUAL-RUNTIME Aug 12 22:32:14 grep Aug 12 22:32:30 it's used for many packages already Aug 12 22:32:53 but there's nothing special about it, it's jsut a variable, a convention, and i just told you how to use it Aug 12 22:45:02 so I should add to VIRTUAL-RUNTIME_anybox = "toybox" at distro.conf and at the recipe with the RDEPNDS as ${VIRTUAL-RUNTIME_anybox} Aug 12 23:03:17 yep, though i'd recommend ?=, not =, so the local.conf can override it easily if you want to change it to something else Aug 12 23:32:55 ahoy! i was wondering if someone coudl point me towards the right command to see what file is causing a packagegroup to be included? I've grepped everywhere, and it's getting built in, hob even shows it as an added packagegroup! Aug 12 23:33:28 i could remove it with hob, but i don't use it - i was just trying to figure out what was pulling in the dependency Aug 12 23:34:02 bitbake -g -u depexp Aug 12 23:34:10 x11 dependency explorer, both forward and reverse Aug 12 23:34:11 does that work for packagegroups? Aug 12 23:34:32 the real question is does it work for runtime or just build time. packagegroups aren't special, they're just empty packages that depend on other packages Aug 12 23:34:42 i think it should work, yes, but try it and find out :) Aug 12 23:34:46 * kergoth hasn't used it in a while Aug 12 23:35:04 bitbake -g your-target and then examining the .dot files it produces may be of use as well Aug 12 23:35:24 hmmmh, so depexp says it reverse depends on itself! Aug 12 23:35:45 so actually, what I'm trying to figure out is why inetutils-syslogd is being installed instead of the busybox-syslogd Aug 12 23:35:55 that likely just indicates interdependencies between the packages the recipe produces Aug 12 23:35:58 which isn't unsurprising Aug 12 23:36:09 recipes often produce many packages which depend on one another Aug 12 23:36:11 interestingly enough that package group isn't included in any files anywhere Aug 12 23:36:30 and no other place is installing inetutils Aug 12 23:36:45 the packagegroup is from a vendor and isn't even included in my build which is what's stumping me Aug 12 23:36:48 btw, thanks for the help kergoth Aug 12 23:36:50 i appreciate it Aug 12 23:38:12 if you used hob in the past, it may well have added its own layer / image recipe / whatnot, so its changes could still be around, if the build directory was retained. check conf/bblayers.conf Aug 12 23:39:23 nope, i don't see a hob layer in there (build/conf/bblayers.conf) Aug 12 23:39:32 i was just trying to use it because it's dependency display is helpful occasionally Aug 12 23:46:52 heh, shallow git tarballs causes serious issues with linux-yocto, its branch validation process expects to be able to check the parent branches that fed into the current branch, so it's not enough to keep just the head of the current branch, need its dependent branches as well. will definitely have to make it an opt-in process, not default. was wondering if that might be the case due to the complexity of its branch and metadata management Aug 12 23:46:57 * kergoth ponders Aug 12 23:53:32 interesting things to ponder ;) Aug 12 23:54:36 that's actually quite messy when i think about it. where would you make that process opt in? Aug 12 23:54:39 * kergoth is trying to get git shallow clone support working, as git mirror tarballs for kernel repositories are freaking huge, and whether you download one of those or clone, it takes forever either way, and takes up a lot of space to distribute sources to customers Aug 13 00:00:38 i'm going to try to rebuild... is there any way to nuke only the cross compiled packages? or force a do_rootfs to actually do it from scratch? Aug 13 00:01:02 if your SSTATE_DIR is outside of tmp, you can just wipe tmp and it'll rebuild from that rather than from scratch. Aug 13 00:01:10 also do_rootfs is always re-run from scratch Aug 13 00:01:31 interesting, i had an issue where i hadn't incremented a PR number in a recipe and it wasn't copying in a new file. Aug 13 00:01:33 when the task is run, anyway. if it's not running, you can use -f on the bitbake line to force the matter. bitbake -f -c rootfs image Aug 13 00:01:35 i'm stuck on an old version of yocto Aug 13 00:01:39 1.3 Aug 13 00:01:40 ahh Aug 13 00:01:42 that's really old Aug 13 00:01:43 so... Aug 13 00:01:57 *sigh* i know. it's what my vendor gave me Aug 13 00:02:26 i had to layer in a ton of stuff to get it working, but i couldn't get a newer version working happily in time for my deadline. Aug 13 00:04:03 could i ask a little about the sstate_dir? i googled for a second - is it just the build for a machine that gets cached and none of the other artifacts? Aug 13 00:05:44 i don't even remember if we had sstate in 1.3, we had an equivalent, pstaging / packaged staging, though. instead of being metadata checksum based and task level, it was recipe level and version bound, hence the need to bump PR Aug 13 00:06:03 ooooh, that makes sense. Aug 13 00:06:11 okay, btw i think i found my problem Aug 13 00:07:12 there's a base_contains that is getting triggered, and a package i can't find any info for is causing inetutils to get included... Aug 13 00:08:12 and it's not showing up in inetutils reversedepends **** ENDING LOGGING AT Thu Aug 13 02:59:59 2015