**** BEGIN LOGGING AT Tue Feb 09 02:59:59 2016 Feb 09 08:17:02 Hi everyone! Feb 09 08:19:29 I'm running ubuntu 16.04 since a few days, I'm using yocto 1.7 (not the last one...) I'm facing issues with some packages because of gcc-5 Feb 09 08:20:11 I installed gcc-4.9, but I would like to know if it is possible to tell bitbake to use gcc 4.9 instead of gcc-5 Feb 09 09:18:44 aurele: you need to set the GCCVERSION variable in your confs Feb 09 09:18:57 something like GCCVERSION = "4.9.3" Feb 09 09:26:35 good morning Feb 09 09:31:32 aratiu I will try this thanks Feb 09 10:56:04 hi, what would be the cleanest way to modify the CFLAGS for a set of recipes? Feb 09 10:56:06 I need to create a "debug" image where certain packages are build with debugging symbols Feb 09 12:06:16 rburton: does the rpm backend support ascii armored signatures? Feb 09 12:06:37 from what I see there are generated only binary signatures inside the rpm files Feb 09 12:07:06 I'm adding a feature to the gpg signer to support signature types and I'm wondering if this feature can be supported by rpm also Feb 09 12:07:24 aragua: no idea Feb 09 12:07:30 erm, aratiu: no idea Feb 09 12:08:23 ipk files and package feeds can support easily both types of signatures because they are in outside files, separate from the pkg Feb 09 12:09:05 anyway I'll not touch the way the rpm backend functions, I was just curious Feb 09 13:37:07 rburton: I'm getting those annoying pexpect errors with the rpm backend, is it ok to create a commit to convert the gpg_sign to use Popen + pipes instead of pexpect? Feb 09 13:37:25 I'm running python 2 in a virtual environment and installing pexpect is a real pain Feb 09 13:38:43 i'd love that, pexpect is a pain Feb 09 13:39:06 it's calling rpm isn't it? Feb 09 13:39:13 * rburton hasn't looked at that properly Feb 09 13:39:19 yes Feb 09 13:39:28 good old gpg lets you pass secrets on fds and things, much nicer Feb 09 13:39:40 I can pass "--passphrase-fd", str(keypipe[0]) to gpg Feb 09 13:39:48 cand I do something similar with rpm? Feb 09 13:47:11 no idea, sorry Feb 09 14:30:16 rburton: I also updated the last two patches with Upstream-Status: Submitted [] , so I will repost the whole thing Feb 09 14:30:46 ok, cool Feb 09 14:44:19 rburton: both patches are needed, so let me rebuild just to be sure and repost Feb 09 14:47:47 armpit: why didn't you remove ./meta/recipes-extended/tzdata/tzdata_2015d.bb in fido's upgrade to 2016a? Feb 09 14:58:26 I've just ran show-appends from bitbake-layers, and it's correctly showing the appends I would expect for the mesa recipe, but then also states 'WARNING: mesa_git.bb: missing append for preferred version' Feb 09 14:58:44 I'm not expecting any appends for mesa_git, so I'm not sore why it's producing that Feb 09 14:59:53 If there's a recipe in another layer that installs a file, and it turns out that I don't want that file in the installation - the accepted way to deal with that in my layer is write a bbappend file in my layer with a do_install_append that removes it, right? Feb 09 15:00:25 anyone know of the reason this warning is showing? Feb 09 15:26:56 Hello guys, did anyone of you try to get recipes data using bitbake libraries? Feb 09 15:27:00 I did import everything what needed (python) Feb 09 15:27:06 d = bb.data.init() Feb 09 15:27:10 d.setVar("BBPATH", BBPATH) Feb 09 15:27:14 bb.parse.init_parser(d) Feb 09 15:27:33 bb.parse.parse_py.BBHandler.handle(recipe_path, d, None) Feb 09 15:27:41 I can handle most recipes this way, but I have problems when parsing recipes inheriting specific package groups Feb 09 15:27:48 e.g. : bb.data_smart.ExpansionError: Failure expanding expression ${@oe.utils.ifelse(d.getVar('PACKAGE_ARCH_EXPANDED', True) == 'all', 'allarch', '')} which triggered exception NameError: name 'oe' is not defined Feb 09 15:27:53 is it the correct way to parse it? Feb 09 15:30:25 janek: best to use something like tinfoil which handles this for you Feb 09 15:30:38 see many of the scripts in oe-core/scripts (like devtool) Feb 09 15:52:38 what's the best way to clean up old cruft in the tmp/work dir? Feb 09 15:54:29 rm? :) Feb 09 15:55:27 i think that's what scripts/cleanup-workdir was for, but i've never used it Feb 09 15:59:18 i just rm tmp/ occasionally Feb 09 15:59:34 same Feb 09 16:07:45 +1 Feb 09 16:23:27 well, as a developer I do the same once in a while Feb 09 16:25:16 but what about autobuilders? or distro builders? Feb 09 16:26:01 we carry around sstate-cache, but typically builds start with a fresh tmp in our autobuilders.. Feb 09 16:26:05 i'd never want to keep around tmp for an autobuilder, too risky to not go from scratch. for continuous integration, we use sstate, for release and periodic, we build from scratch Feb 09 16:26:15 that is just an artifact of space savings.. not designed that way Feb 09 16:26:35 the public AB has a clean tmp every build too Feb 09 16:26:36 fray: exactly, but do you clean old sstate files? Feb 09 16:26:37 and as kergoth said for his case, we also have regular "build everything from scratch" autobuilders.. (at least once a week) Feb 09 16:26:43 we time them out using atime Feb 09 16:26:49 yeah, we use atime too Feb 09 16:27:15 since even if it's not obsolete.. a simple rebuild will "bring it back" Feb 09 16:27:17 not perfect, but gets the job done. the i ntermediate artifacts can hang around, someone brought that up on the list recently Feb 09 16:27:36 we've got the atime set to between 3 and 7 days.. with a once a week (or more) from scratch build Feb 09 16:28:07 i think ours is similar. i use 7 days for my personal builds, but i think the official ones are shorter than that due to the # of builds and space limitations Feb 09 16:28:11 I know our build guy has some additional heuristics other then atime, but that is the primary Feb 09 16:28:50 there's sstate-cache-management.sh, but that's only useful if you have every combination of configuration you might want to build handy Feb 09 16:28:53 (last time I checked, we do something like 1000 builds a day for our base core product.. most of those are different configurations and platforms) Feb 09 16:28:58 but we build multipel product versions and branches and whatnot, so that's just out Feb 09 16:30:57 the frequency of our autobuilds goes down as a product gets older.. fewer changes means we need fewer builds to verify changes.. Feb 09 16:31:29 if you don't need the intermediate artifacts, (though IMO you should keep them for bitbake -S printdiff, becuase it's just a matter of time till someone wants to know why something is building from scratch), you can clear them out by builidng from sstate and then using those stamps to clean, i.e.: bitbake foo; rm -rf tmp; bitbake foo; sstate-cache-management.sh --yes --cache-dir=sstate-cache --stamps-dir=tmp/stamps Feb 09 16:31:33 (ohh and all of those are internal builds.. we have a seperate system for production/release builds) Feb 09 16:32:16 kergoth which intermediate artifacts are you referring to? the do_install (vs do_package)? Feb 09 16:32:29 yeah, the tasks that don't run when later tasks are cached Feb 09 16:32:41 ok, so I guess I'm not doing anything weird here... :) clean build once a week, cron-based clean up of old files... was wondering if there was a more generic script Feb 09 16:32:42 gotcha.. Feb 09 16:32:54 wihtout those siginfos, you won't be able to use printdiff, but there's value ini wiping do_package if you're short on space or have distribution size requirements Feb 09 16:32:57 * kergoth shrugs Feb 09 16:33:04 denix the script kergoth mentioned is about the closest you'll see to a more generic script Feb 09 16:33:34 though i suppose one could disable sstate emission for do_package somehow.. hmm Feb 09 16:33:46 we don't often use the siginfo from the autobuilders.. so it's not much of an issue for us Feb 09 16:33:47 fray: yep, thanks Feb 09 16:34:08 (or system was built before that script existed.. and continues to work, so we've not attempted to move to using it) Feb 09 16:34:37 trying to remember but we've got a build holding area (failed builds, sstate-cache that kind of thing) thats something like 20 TB of storage.. Feb 09 16:34:46 if you're distributing sstate, i.e. to accelerate out of box experience, then it's critical to be able tof igure out why the cache isn't working as expected if it isn't working as expected :) Feb 09 16:34:48 so we've not really had a problem (so far) as long as we use the atime Feb 09 16:35:15 kergoth, so far we've only distributed sstate in specific cases.. and in those cases it comes from the production servers, which don't timeout the sstate Feb 09 16:35:31 does the yocto project autobuilder and testing infrastructure do any sstate reuse testing? i.e. between different build dirs, build hosts, etc to check for unexpected rebuilds? Feb 09 16:35:32 (specific cases are almost always '-native' components..) Feb 09 16:35:36 i used to do a lot of that manually Feb 09 16:35:51 i.e. natives should rebuild when changing build hosts, but target should have 100% reuse still Feb 09 16:35:58 kergoth, it does some.. I don't know if it's all improved since the old days.. but I filed some defects on specific tests I wanted to see.. Feb 09 16:36:05 builds with different usernames, host types, etc.. Feb 09 16:36:07 we generate around 4TB of new sstate per month (even when we aren't changing upstream layers) .. :/ Feb 09 16:36:08 * kergoth nods Feb 09 16:36:14 JaMa: wow Feb 09 16:36:25 JaMa do you time anything out? Feb 09 16:36:36 kergoth: some Feb 09 16:36:46 I know our problem w/o the weekly (or more often) atime removal was we could easily fill 8TB in that time Feb 09 16:36:58 chromium is quite big and almost any change is invlidating sstate signature of one of its dependencies Feb 09 16:37:02 since the storage server was designed for failed builds and sstate.. that was too much Feb 09 16:37:06 ahh ok Feb 09 16:37:39 kergoth: we discoveved that we need to add PARALLEL_MAKE to the tests, as some recipes (cough java) rebuild when that changed Feb 09 16:37:45 so we prune the sstate periodically (keeping only the latest) Feb 09 16:38:11 kergoth: if you have thoughts or ideas, i can point you at the tests we have and bugzilla :) Feb 09 16:38:25 I should really try to integrate some changes to the signature generation. one thing that bugs me is we don't just change it when the metadata results change, but also how we got there. Feb 09 16:38:36 i.e. FOO = "bar" and FOO = "${BAR}"; BAR = "bar"; generate entirely different checksums Feb 09 16:38:43 when the used var is FOO, that is Feb 09 16:38:46 which just seems wrong Feb 09 16:40:58 that reminds me, i should add a new subcommand to 'bb', i want to be able to, on demand, ask bitbake for the metadata signature of a given variable. if it's a task, give me both the current base hash and task hash, otherwise just the variable checksum Feb 09 16:41:06 possibly optionally dumping signature data Feb 09 16:41:09 * kergoth ponders Feb 09 16:51:08 JaMa, by mistake Feb 09 16:52:08 armpit: ok, fix sent Feb 09 16:53:38 JaMa, thanks Feb 09 16:55:00 kergoth: but the counter-example is FOO="${WORKDIR}/foo" when the value is different, but the signature doesn't change because top directory change can be easily excluded from signatures Feb 09 16:55:50 last time it was discussed on ML RP claimed that the cases where it works better with vardepvalue flag aren't that often and I agree Feb 09 16:55:58 WORKDIR isn't excluded from signatures, TOPDIR is Feb 09 16:56:15 yes, but WORKDIR uses TOPDIR Feb 09 16:56:19 and? Feb 09 16:57:07 in my original implementation, expanded values were checksummed, but vars were re-expanded with a blacklist, so blacklisted / excluded vars were left as is Feb 09 16:57:29 so it used the final value, but i.e. ${WORKDIR} would be left like that if it was left out of signatures Feb 09 16:57:57 imo that was a good compromise solution, but there are performance implications with that, so i can see why richard didn't take that approach Feb 09 17:02:14 huh, odd, i have these commits on top of a tag in the git repo, export, then bitbake applies that series to the tarball of that same version, and the patches fail to apply.. guess either the tag doesn't actually match the release, or patch is applying differently than git Feb 09 17:08:46 how do you run the do_configure() step from a devshell? do you need to have run it previously so there's a run.do_configure.1234 in temp/ that you can run? Feb 09 17:08:57 yep Feb 09 17:09:07 ok Feb 09 17:09:12 functions & tasks aren't available in devshell at the moment Feb 09 17:09:16 not directly, anyway Feb 09 17:09:41 next q: how do you run cmake? doesn't seem to be available in the path, even though the recipe inherits cmake.bbclass. Feb 09 17:10:55 guess i could check what run.do_configure.1234 does... Feb 09 17:11:17 kergoth: we could probably quite easily make the checksum computation pluggable and experiment with that Feb 09 17:11:35 Ulfalizer: it just runs cmake as it's on the path Feb 09 17:12:23 is it expected that i wouldn't get it on the path in the devshell? Feb 09 17:12:43 oh... maybe those run scripts set up the environment too Feb 09 17:12:53 at the beginning, iirc, including the path, prolly Feb 09 17:14:19 nm... i do get cmake in the path now. not sure what changed. Feb 09 17:14:41 maybe because i did a full build of the recipe before running devshell Feb 09 17:14:58 Ulfalizer: works for me Feb 09 17:15:10 even if you e.g. remove tmp/ and then run devshell? Feb 09 17:15:20 well that won't work Feb 09 17:15:24 heh Feb 09 17:15:26 as devshell just opens a shell in the work Feb 09 17:15:32 doesn't actually do much else Feb 09 17:15:44 would work/ get created prior though? Feb 09 17:15:47 yes Feb 09 17:15:57 "addtask devshell after do_patch" Feb 09 17:19:56 so is it expected that rm tmp/ bitbake foo -c devshell wouldn't work? for some reason i don't get cmake on the path when i do that. Feb 09 17:20:14 does do_configure() pull in cmake-native or something? Feb 09 17:20:50 yeah pretty much Feb 09 17:21:00 DEPENDS is actually do_configure[depends] Feb 09 17:21:12 ah, yeah, right Feb 09 17:21:16 i remember that now Feb 09 17:21:26 this lets fetch/unpack/patch happen whilst build deps are still being built Feb 09 17:21:45 so if you've a clean tmp do a bitbake foo first to populate the sysroots Feb 09 17:21:57 kk Feb 09 17:25:37 odd... after successfully 'bitbake foo' and then running 'bitbake foo -c devshell', i still don't get a run.do_configure.* in temp/ Feb 09 17:25:42 +running Feb 09 17:26:05 Ulfalizer: it built from sstate Feb 09 17:26:10 so it had no need to run configirue Feb 09 17:26:20 bitbake foo:do_configure; bitbake foo:do_devshell Feb 09 17:26:22 or -c, whichever Feb 09 17:26:57 is that syntax documented? looks handy. Feb 09 17:27:27 Usage: bitbake [options] [recipename/target recipe:do_task ...] Feb 09 17:27:36 neato Feb 09 17:27:41 first line of bitbake —help :) Feb 09 17:27:47 my favourite option is -C Feb 09 17:28:08 * Ulfalizer rtfms Feb 09 17:29:07 so -C compile would run compile and everything that follows it? Feb 09 17:29:24 if earlier stuff was up-to-date Feb 09 17:30:02 it would mark compile as needing to happen even if the system thinks it doesn't need to, and then build as usual Feb 09 17:30:30 yep, -C is awesome Feb 09 17:30:34 -C unpack is useful as a force-rebuild without having to do cleansstate Feb 09 17:30:49 remember that it just re-runs the task, though, it won't always clean out first, so if you have old remannts floating around, a manual clean is still handy Feb 09 17:31:06 ok, thanks for the tip Feb 09 18:13:18 halstead_: do you know which testopia version we have in bugzilla.YP.org? Feb 09 18:31:37 <[Sno]> khem: I've seen your question to submit a PR for cross-localedef wrt. the ABI-breaking patch (file://strcoll-Remove-incorrect-STRDIFF-based-optimization-.patch) Feb 09 18:32:07 <[Sno]> khem: doesn't cross-localedef has an external relationship to glibc? Feb 09 18:32:41 cross-localedef was based on localedef inside of glibc -- then "modified".. Feb 09 18:33:07 I'd assume they could (and should) be kept in sync.. but I don't know if anyone is actively doing that.. (or maybe cross-localedef was merged into glibc when eglibc went away?) Feb 09 18:34:35 <[Sno]> in poky/jethro, meta/recipes-core/glibc/cross-localedef-native_2.22.bb fetches ${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc "manually" Feb 09 18:35:30 <[Sno]> so I dunno what kind of PR I should send (I hope it should be against https://github.com/kraj/localedef) Feb 09 18:36:04 <[Sno]> otherwise I'm totally confused :D Feb 09 19:18:03 oh yeah i meant to talk to khem about that Feb 09 19:31:54 rburton: o/ Feb 09 20:08:56 <[Sno]> rburton: the "fix memory corruption" commit - patch comment like that (https://github.com/rehsack/poky/commit/1b1b9b25acfa70e70db1b429c0443be6671e3e8a) ok? Feb 09 20:53:03 https://github.com/jedisct1/libsodium/issues/259 Feb 09 20:53:25 someone had an issue building something on an Edison Feb 09 20:53:41 I feel like busybox tar can't unpack long filenames Feb 09 21:48:54 so Feb 09 21:49:03 just how long ago was bin/build/oebuild.sh removed? **** ENDING LOGGING AT Wed Feb 10 02:59:59 2016