**** BEGIN LOGGING AT Fri Nov 10 02:59:59 2017 Nov 10 07:13:42 RP: is "newbuilable" in runqueue.py a typo for "newbuildable"? Or does it have a special meaning? Nov 10 07:26:51 mario-goulart: probably it means "reboilable" and is a typo... Nov 10 07:26:56 Nov 10 07:28:53 :-) Nov 10 08:50:17 mario-goulart: newbuildable I suspect Nov 10 09:11:51 RP: ok. Thanks. Nov 10 13:46:28 Hi, I'm trying to build a custom image and this image should include python3 but I'm getting lot's of errors like "consider defining a PREFERRED_PROVIDER entry to match python-distribute-native". Can't find much information and I'm quite stuck. Anybody with some clues/ideas? Nov 10 14:17:44 Hi, I'm trying to use gitver.bbclass from meta-oe in my poky pyro based distro, like this: PV = "${GITVER}+gitr${SRCPV}" Nov 10 14:18:29 but I get following bitbake error when building that recipe: https://pastebin.com/g5AutNgF Nov 10 14:18:48 "RuntimeError: maximum recursion depth exceeded while calling a Python object" Nov 10 14:19:00 any ideas? am I doing something wrong? Nov 10 15:33:15 pespin: i think gitver contains SRCPV already Nov 10 15:34:16 rburton, yes I saw that, but anyway it doesn't work if I set it to ="${GITVER}" Nov 10 15:34:27 I think it's because I'm using S = "${WORKDIR}/git" in the recipe Nov 10 15:36:06 I saw it fails in the following line in get_git_pv of gitver.bbclass: srcdir = d.getVar("S") Nov 10 15:36:17 if I return "foo" before that, then there's no recursion issue Nov 10 15:37:02 and from the information brom the bt, I seems the recipe tries to expand S, which in turn expands WORKDIR, which in turn expands to ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} Nov 10 15:37:25 then PV expands to GITVER. And GITVER tries to expand S again Nov 10 15:37:27 set S before PV? Nov 10 15:39:07 rburton, I'm already doing that. First S = "${WORKDIR}/git", then PV = "${GITVER}" Nov 10 15:45:28 any idea on how to break the circular dependency is welcome. I'm not sure how this has ever worked for other people. Nov 10 15:47:47 If I understand correctly, I should change WORKDIR to not include PV then Nov 10 15:48:51 maybe you're meant to use it in pkgv? Nov 10 15:48:55 * rburton has no idea Nov 10 15:53:06 rburton, gitver.bbclass header description says: "gitver.bbclass provides a GITVER variable which is a (fairly) sane version, for use in ${PV}, extracted from the ${S} git checkout, assuming it is one. This is most useful in concert with srctree.bbclass" Nov 10 15:53:22 but probably srctree bbclass plays a role here changing something required. Nov 10 16:00:44 there's code in bitbake/oe-core to do what gitver.bbclass did nowadays, how old is your poky? Nov 10 16:01:41 or *some* of what gitver did, maybe Nov 10 16:08:28 joshuagl, I'm using pyro Nov 10 16:09:01 joshuagl, can you give me a pointer to the bits in bitbake/oe-core? Nov 10 16:09:41 I basically need PV to be updated automatically to latest tag in repo SRCREV is AUTOINC being built in a nightly jenkins build). Nov 10 16:09:51 AUTOREV, not AUTOINC sorry Nov 10 16:12:12 bitbake has gitkpkgv_revision() in lib/bb/fetch2/git.py which is "based on gitpkgv" Nov 10 16:14:37 joshuagl, I already looked at gitpkv, but it provides other information. Not the version, but the hash + count in commits from there afair Nov 10 16:14:42 exists in pyro Nov 10 16:15:56 isn't that basically what gitver provides? Nov 10 16:16:39 joshuagl, no, it provides the latest tag from the branch you checked out. For instance, "0.2.0". And after it, yes, it provides what you mention. Nov 10 16:17:14 ah, sorry didn't see that you were looking for latest tag Nov 10 16:17:49 joshuagl, that's why ther eused to be gitver and gitpkgv, they povide similar but different functionalities. Nov 10 16:18:00 sure, makes sense now Nov 10 16:18:59 so it seems git.py doesn't provide that functionality, but it makes more sense to have it there than in a separate .bblcass such as gitver afaict Nov 10 16:20:12 because all the info could be gathered from the downloads/ directory before creating the WORKDIR directory, which requires PV->GITVER to be set Nov 10 18:05:29 khem, ping Nov 10 18:05:49 pong ( cross court ) Nov 10 18:06:44 khem, are you working on upgrading binutils to 2.29.1 in master ? Nov 10 18:07:43 havent yet got on it. Nov 10 18:07:52 but I do Nov 10 18:08:29 * armpit do what? seems mid though Nov 10 18:09:19 * armpit are we married now ? Nov 10 18:10:10 but I do have it on my backlog Nov 10 18:10:19 * khem chops Nov 10 18:11:24 there are 41 security issues against 2.29 and I am hoping to update Rocko to 2.29.1 instead of backport all 41 + commits Nov 10 18:12:33 I was working this today and upgrading seems more fruitful Nov 10 18:16:28 do you see any issues in have 2.29.1 in Rocko ? Nov 10 18:19:51 * armpit did I scare him off?? Nov 10 19:05:49 for anybody intersted about the previous topic, it seems populating GITVER from downloads/ is not a good idea neither, because the WORKDIR is created before running the fetch task (and thus still not having the repo in there). As it is done already for SRCPV, information is gathered directly from the remote by means of git ls-remote in fetcher2. Something similar is required to get GITVER, ie. some "git describe" which can get Nov 10 19:05:50 the latest tag directly from the remote (which doesn't exist as a built-in from git afaik). Nov 10 22:38:15 Should I bother sending up CVE patches for morty OE core? Nov 10 22:51:49 yes **** ENDING LOGGING AT Sat Nov 11 03:00:02 2017