**** BEGIN LOGGING AT Wed May 09 03:00:05 2018 May 09 06:39:49 i did kick off a qemuarm core image minimal build on ec2 micro for the fun of it. 36hrs and counting. May 09 07:26:15 New news from stackoverflow: Yocto 2.4.2 failed to do_package_qa task || How to check for not equal to values in bb.utils.contains() || Yocto build broken when setting a remote rpm repository with https Where I can I find info about the relationship between PV, SRCPV and PKPV ? May 09 08:12:45 (lost connection for a sec there if someone replied) May 09 10:16:20 hi all, i am on a debian sid, and getting this error May 09 10:16:21 ERROR: Task (virtual:native:/home/angelo/git/bounty/lm-toolchain-yocto/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb:do_compile) failed with exit code '1' May 09 10:17:14 my collegues uses same yocto from our internal git, but they are on stable ubutnu distros and all works May 09 10:18:06 is there a way to fix this without impacting other guys that are on ubuntu stable and properly building ? May 09 10:26:35 When bitbake starts running it prints out the main build config vars as well as layer versions. Can I get this information in a script-friendly manner? May 09 10:42:59 Is there a way to override the branch field only from local.conf for a recipe's SRC_URI="...;branch=..." ? May 09 10:44:09 I tried setting BRANCH_pn-recipename="", but for some reason in a task being run after do_unpack before do_patch it is still master May 09 10:46:05 I thought BRANCH_pn-* would work, I'm sure it did once. So either that has been removed from Rocko or the taskpoint after do_unpack before do_patch is too early for the repo to be checked out correctly May 09 10:49:06 angelo_ts: I ran into e2fsprogs issues with ubuntu 18.04 host toolchain - solved by upgrading e2fsprogs to latest version available. May 09 10:49:32 malu1, ok thanks May 09 10:49:43 likely i will have other issues about libc later May 09 10:50:13 angelo_ts: yes, you might run into glibc 2.27 issues as I did May 09 10:51:34 malu1, yep, thats' it May 09 10:51:42 what you did then ? May 09 10:52:17 angelo_ts: if so you might considering using 'INHERIT_remove = "uninative"' which will make sure everything is built from scratch which solves glibc 2.27 not being detected. May 09 10:53:49 as far as I understand the uninative stuff makes u use a prebuilt toolchain etc. which is not compatible with the latest glibc 2.27 changes. May 09 11:27:03 New news from stackoverflow: If the same code is built at different folders using arm-poky-linux-gnueabi-gcc, the resulting binary will have different contents May 09 11:40:06 RP: did you already pick anuj's gst updates into next? (the v4 and v2 sent at 5am) May 09 11:42:33 rburton: yes May 09 11:42:49 cool May 09 11:52:50 argh looked at the wget fetcher again and now i want to rewrite it all in Requests May 09 12:18:08 rburton: the wget fetcher used to be so simple too :( May 09 12:18:13 malu, many thanks May 09 12:18:40 so what you suggest as best way of working: INHERIT_remove = "uninative" or yocto in a container ? May 09 12:19:37 angelo_ts: certainly the container way. building a moving target on a moving host is very prone to break things, and not using uninative is a bandaid for this particular breakage only. May 09 12:21:06 LetoThe2nd, thanks. There was around a guide for yocto into container =? May 09 12:22:03 angelo_ts: I'm not the right guy to answer that as I'm not sure what the full consequence is of not using uninative. May 09 12:22:24 angelo_ts: depends on your usage in the end. but a rather simple usecase is to just have fixed ubuntu version with all needed stuff installed, a user account, mount the work directory inside. May 09 12:23:55 rburton: hmm, failure in clutter-gst now :( May 09 12:24:09 RP: yeah just testing an upgrade for that now May 09 12:26:19 RP: the qemu failure is most annoying, i wonder what caused that May 09 12:34:37 rburton: qemu upgrade? May 09 12:34:47 oh yeah that would be it ;) May 09 12:37:07 oh right i turned on llvmpipe, that explains why mesa is taking an age to build May 09 13:04:59 RP: clutter upgrade on the list May 09 13:07:24 rburton: that fixes that failure? May 09 13:08:10 yeah May 09 13:10:40 rburton: safe to pull that, drop the qemu upgrade and merge or needs another run? May 09 13:12:07 i'd be happier with another run tbh May 09 13:12:15 i'll have a quick look at what changed in qemu May 09 13:20:00 what is the "qemu failure"? May 09 13:20:34 I've noticed that you reverted the earlier CVE patch before doing the upgrade, I have v2 which removed the patch together with the upgrade, but that should end-up the same May 09 13:20:47 JaMa: yeah that was meant to be squashed in before merge May 09 13:21:12 i think we need to explicitly disable sdl in the no-x builds as that is now depending on x keysyms May 09 13:22:02 so qemu fails to build for you? May 09 13:22:11 if you remove x11 distro feature, yes May 09 13:22:21 here I'm building it with spice/virgl/gtk3 enabled, so I might see different issue May 09 13:23:27 target qemu or nativesdk or native? May 09 13:23:35 JaMa: target May 09 13:23:48 target, https://autobuilder.yocto.io/builders/nightly-no-x11/builds/993/steps/BuildImages/logs/stdio May 09 13:24:44 I'll trigger the build to see if I can reproduce here with no-x11 distro May 09 13:25:55 heh qemu was skipped: Recipe is blacklisted: depends on blacklisted libsdl May 09 13:26:43 conf/distro/include/webos-recipe-blacklist-world.inc:PNBLACKLIST[libglu] ?= "broken: we don't build libGL with mesa: cannot find -lGL" May 09 13:26:46 conf/distro/include/webos-recipe-blacklist-world.inc:PNBLACKLIST[libsdl] ?= "depends on broken libglu" May 09 13:28:00 heh May 09 13:29:22 libglu should build against mesa-gl just fine May 09 13:32:18 I've added these long time ago (definitely before dylan was released) and they wasn't revisited since then (except very few cases when someone actually needed something blacklisted) May 09 13:33:26 but libsdl2 is better anyway, because it supports accelerated gl May 09 14:44:22 I reorganized my local SRC_MIRROR and now 1 do_fetch task fails. The src file in question looks good to me in the reorganized mirror. The do_fetch log does not really tell from where it tried to get the file. Can the logging level of the fetcher class be increased? May 09 15:04:27 u1106_: you could try running the task as bitbake -c fetch -DDDv May 09 15:34:59 JaMa: looks like the qemu upgrade makes the assumption that sdl == x11, so we need to guard the sdl packageconfig with x11 DISTRO_FEATURE checks. also change to libsdl2 at the same time? May 09 15:36:36 rburton: there are more changes needed to make libsdl2 really usable, see: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu May 09 15:36:59 ok fine by me May 09 15:37:10 libsdl 1.x is dead isn't it? May 09 15:38:23 JaMa: replied on list May 09 15:39:38 ok, will send v2 after reproducing this May 09 15:40:23 i can replicate just by removing x11 from distro features May 09 15:40:33 so should be easy enough May 09 15:41:22 RP: I don't see that that gives me any more information. There is a lots of additional information concerning all the steps before it does the do_fetch. But I don't think that is relevant to my problem. The information inside tmp/work/foo/bar/temp/log.do_fetch.12345 does not get any more detailed :( May 09 15:43:38 do_fetch's log should show every mirror url being checked, as well as info about the url processing done by PREMIRRORS May 09 15:44:21 u1106_: I agree with kergoth, the fetch logs usually are pretty verbose :/ May 09 15:45:13 i usually find the 'returning ..' messages that show what substitutions were applied in mirror processing to be helpful when diagnosing mirror issues May 09 15:45:17 make sur ethe pathsss are correct May 09 15:45:34 hmm, I don't see that. Will compare with a sucessful do_fetch May 09 15:50:11 rburton: ping? May 09 15:50:17 tlwoerner: wot May 09 15:50:24 wrt the github.com/${PN}/archive issue May 09 15:50:41 switching to github.com/${PN}/releases is considered okay? May 09 15:50:53 generally not as thats the same url May 09 15:51:08 the acceptable fixes are 1) git fetch 2) maintainer-uploaded tarball May 09 15:51:57 note that the actual tarball links in /releases/ are typically actually /archive/ May 09 15:52:06 unless its a maintainer uploaded tarball, which is fine May 09 15:52:07 http://git.openembedded.org/openembedded-core/commit/?id=9c668f9ff989a34e615e2ecc051dadbfe24a5bb4 May 09 15:52:31 yes, see https://github.com/logrotate/logrotate/releases May 09 15:52:48 logrotate-3.14.0.tar.gz is a maintainer-uploaded tarball May 09 15:52:56 "Source code" is a /archive/ tarball May 09 15:53:25 compare with https://github.com/madler/pigz/releases which doesn't have maintainer-uploaded tarballs May 09 15:53:53 ah, okay May 09 15:55:18 the tarball URL for the uploaded tarballs is eg https://github.com/logrotate/logrotate/releases/download/3.14.0/logrotate-3.14.0.tar.gz May 09 15:55:21 note the lack of /archive/ May 09 15:57:57 New news from stackoverflow: In devtool command line tool is finish subcommand removed or replaced? May 09 15:59:53 rburton: i was hoping to find an example in oe-core of switching from github archive to git, it looks like all the cleanups that were done, were all able to switch to developer-generated tarballs May 09 16:00:22 tlwoerner: switching to git is trivial, just change the src_uri and set S=WORKDIR/git May 09 16:00:50 rburton: and i'll need a SRCREV? May 09 16:01:36 do i need to change the name of the recipe from ${PN}_${PV}.bb to ${PN}_git.bb ? May 09 16:01:44 yeah, set it to the sha of the tag May 09 16:01:54 no need to rename if it continues to be based on releases May 09 16:02:03 ok, thanks :-) May 09 16:02:12 imho, _git recipes should be reserved for recipes which track arbitrary commits, not releases May 09 16:02:36 the version is still valid, even if it does fetch over git instead of tarball May 09 16:05:29 FWIW: I prefer _git.bb and PV set inside, that way setting SRCREV_pn-foo somewhere won't produce so confusing results May 09 16:05:43 FIGHT! May 09 16:07:23 we have recipes-connectivity/connman/connman_1.33.bbappend which sets PV to 1.12+git which annoys me every time May 09 16:08:17 it's only slightly better than duplicating whole recipe in our layer with _git.bb name or using require recipes-connectivity/connman/connman_1.33.bb inside of connman_git.bb which sets 1.12+git May 09 16:09:02 but I realize that in this case the connman_1.33.bb isn't even fetching from git.. :0 May 09 16:09:11 wouldn't that be a bug (i.e. the recipe name is 1.33 but inside it sets PV to 1.12)? May 09 16:09:56 recipe name matches with what the recipe fetches, but our bbappend changes it to fetch something else from our forked connman May 09 16:12:46 obviously connman is the exception, not the rule, but in any case i think changing the name to _git.bb makes more sense since with future version bumps only the SRCREV inside the recipe needs changing, not the SRCREV plus recipe name May 09 16:25:54 RP: kergoth: Right. For a recipe with a working do_fetch I get a lot of information in log.do_fetch May 09 16:25:55 E.g the "returning" line mentioned by kergoth May 09 16:25:55 > DEBUG: For url http://downloads.yoctoproject.org/mirror/sources/git2_github.com.file.file.git.tar.gz returning file:///usr/local/share/src_mirror/git2_github.com.file.file.git.tar.gz May 09 16:25:55 But for the failing one I get really no info where it tries to search https://pastebin.com/X6D83t15 May 09 16:28:01 New news from stackoverflow: Yocto build succeeds, but warning about missing RDEPENDS May 09 16:30:07 I have also straced both task. For the suceeding one it does a couple of lstat() calls on my local src mirror and then 2 stat() calls on /usr/local/share/src_mirror/git2_github.com.file.file.git.tar.gz and the the symlink to downloads May 09 16:33:14 u1106_: that looks very like the recipe in question has a "floating" SRCREV, it therefore has to look at the repo to see what the current revision is May 09 16:33:17 in the failing case it does only the lstat() calls on the source mirror, but never tries to stat() /usr/local/share/src_mirror/git2_github.com.IntelRealSense.librealsense.git.tar.gz , which I guess should should be the file it needs. Nor on anything else May 09 16:33:20 u1106_: when it can't do that, it fails May 09 16:34:10 RP: that could be. I guess this package has never been built offline before here May 09 16:34:44 u1106_: we try and educate people not to have floating revisions but in the connected world we live in, its hard for people to understand why :/ May 09 16:35:09 u1106_: it could also be a "name" it has to resolve and that has to be done against the canonical upstream since it can change May 09 16:35:12 lmbench is failing to build because it can't find rpc/rpc.h any ideas what changed in the last 24 hours that would break that? May 09 16:35:31 moto-tim1: the glibc changes from khem? May 09 16:35:42 so I guess I do a bbappend and force it to known good version? May 09 16:35:47 RP: that was my first guess May 09 16:35:49 moto-tim1: we dropped large chunks of the rpc stack from glibc May 09 16:36:02 (in keeping with what upstream are doing) May 09 16:36:15 u1106_: you can probably even do it from a config, but ye May 09 16:36:16 yes May 09 16:36:22 RP: ok. well, lmbench is probably in need of an update then :) May 09 16:37:11 moto-tim1: a depends on one of the new recipes may be enough (or may not) May 09 16:40:59 RP: right. just got that from the commit log :) May 09 16:41:26 * moto-tim1 thanks khem for breadcrumbs May 09 16:48:04 rburton: it seems to be a convention that when switching a recipe from a tarball to git that one updates the PV to include git? e.g. PV = "8.40-1+git${SRCPV}" May 09 16:48:15 or is that more often the convention when the sha is between releases? May 09 16:48:26 convention is a strong word :) May 09 16:48:40 if the sha is the tag then i prefer just eg PV=8.40 May 09 16:48:50 i.e. the default May 09 16:48:52 the fact that it comes via a git clone is a detail that doesn't matter May 09 16:49:04 intel is backing out from iot, wind-river,... so many things in embedded(which is not a surprise), will that eventually impact yocto somehow May 09 16:49:32 ausjke: if you know what the future holds for wind river then i think you know more than wind river does... May 09 16:50:18 ausjke: the fact is things will change, the question is whether those changes will be good or bad May 09 16:50:40 ausjke: but even if things might be bad initially, good things often have a way of righting themselves :-) May 09 16:50:52 hope for the best, i guess May 09 16:51:45 * ausjke is trying to hard to figure out intel's success in embedded field for the last 2 decades...sad May 09 16:52:18 ausjke: in the beginning, there weren't a lot of people using OE, so it was good having someone with money driving it May 09 16:53:07 i'm hoping (and somewhat optimistic) that the project has reached and passed the tipping point where there is enough involvement that it can continue without that strong backing May 09 16:59:13 tlwoerner, it reached the tipping point before Intel showed up :) May 09 17:00:14 RP: when specifying a SRCREV I end up with: ERROR: librealsense2-2.10.0-r0 do_fetch: Fetcher failure: Conflicting revisions (bc56b2dcfcf844e39ae2a9c953eaeb35b0706ae4 from SRCREV and v2.10.0 from the url) found, please specify one valid value May 09 17:00:15 The URI is git://github.com/IntelRealSense/librealsense.git;tag=v${PV} May 09 17:00:26 considering we started OE in 2002, I think that's a safe statement to make, yes :) May 09 17:00:57 Crofton: but they pay many of the gurus who really drive the project today, if those gurus go out and get jobs that have nothing to do with OE, it might be hard for the community to find those sorts of contributors May 09 17:01:14 for a little while, anyway :-) May 09 17:01:24 can a tag not working in offline build??? I do have the tag on my mirror, but that should be irrelevant. From strace I know that it does not even access the mirror May 09 17:01:41 I doubt most of the oe experts are going to drop oe work unless there's no other choice, as deep expertise in anything is valuable May 09 17:01:44 for an SCM, you can use a tag, but you need a local (on your disk) mirror for that repository.. May 09 17:01:49 it's a known limitation May 09 17:01:54 i know i wouldn't, at least for the day job, unless i had to May 09 17:02:47 kergoth, finding an employer has it's ups and downs, even for 'experts'.. it's amazing how many people want me to move to work for them.. (And these are only tangentally related to OE) May 09 17:03:11 in the end everyone is replacable.. the catch is -how- long and -how- expensive May 09 17:03:13 that's true, i do shovel a lot of recruiter mails into a label in gmail on a fairly regular basis May 09 17:03:34 tlwoerner: 'many' is a bit of a stretch. 'some' May 09 17:03:36 but still, i expect most tend to stay where their years of expertise have led them, unless they're particularly bored May 09 17:03:46 kergoth, ++ May 09 17:04:17 course there's that old quote saying if you're the expert in your team, you should find a new team, so you don't stagnate.. May 09 17:04:20 but *shrug* :) May 09 17:04:34 I find that a bit of a BS statement myself.. May 09 17:04:38 u1106_: you cannot use a tag, no May 09 17:04:39 agreed May 09 17:04:40 lol true :) May 09 17:04:47 just because you are an expert doesn't mean you stagnate.. but it's up to YOU to figure out where to keep looking May 09 17:04:59 u1106_: it has to be "resolved" to a commit and you need the upstream repo for that May 09 17:05:23 and you can gain deeper and wider knowledge even just mentoring and teaching once your'e in a ssenior role May 09 17:05:23 RP/u1106_ which is why a local copy of the upstream repo can 'solve' the issue.. but may not really be what you want May 09 17:05:36 plus can branch off into other internal projects and lead other teams to expand May 09 17:05:41 my personal goal is to work myself out of the job I'm currently doing.. May 09 17:05:55 that doesn't stop me from being an 'expert' in what I'm currently doing.. but it does continue to make me useful.. May 09 17:06:02 my personal goal is to retire ;) May 09 17:06:05 Tell your bosses people got to eat May 09 17:06:05 fray: the chimney thing? May 09 17:06:18 (note, I don't really consider myself an expert in a lot of things others might -- but someone who is smart enough to figure out what is needed when it's needed..) May 09 17:06:21 tlwoerner :) May 09 17:06:23 I need to start doing some side work, cause i'm definitely not learning as much as i used to May 09 17:06:28 getting rusty in some areas May 09 17:06:39 (for those w/o the chimney reference: http://kernel.crashing.org/fray/chimney/) May 09 17:06:53 what I spent part of my last two weekends on.. May 09 17:07:03 so I can not only 'build' software, but I can remove brick.. May 09 17:07:10 see I DO do hardware! May 09 17:07:30 kergoth: switching OE from python to rust? (i.e. getting rusty...) May 09 17:07:33 ha May 09 17:07:54 (lol and the 0333 picture, the wall is straight -- welcome to picture stitching -- makes it look fish-eye) May 09 17:07:59 fray. what's the terrible upstream latency on that server. May 09 17:08:04 tsk. tsk. May 09 17:08:09 3rd world country or something. May 09 17:08:19 sorry, my DSL only has a 2-5MB/s upload.. :P May 09 17:08:28 the pictures are 'kinda big' May 09 17:08:36 zeddii: says the guy from the country with the worst internet of all developed countries... May 09 17:08:45 shhhh. May 09 17:08:48 i don't want to retire, i'd rather just gradually reduce the # of hours per work of work, do a ssemi-retirement thing May 09 17:09:00 occasionally they add additional string across the border.... May 09 17:09:44 kergoth, my goal (which I won't meet) is to retire in my early 50's.. then in 203x, come back and fix the UNIX time problem for 4x my normal rates.. ;) May 09 17:10:24 fray. stop all the gambling and drugs. you'll retire faster. May 09 17:10:49 lol, I thought gambling (stock market) was how you retired faster May 09 17:11:40 * tlwoerner wants to be a lumberjack May 09 17:11:52 i'm a lumberjack and i'm okay, i sleep all night and i work all day.. May 09 17:11:57 and ya, my 'drug' (caffine and alcohol) habit can get expensive.. don't drink much -- but I like expensive Scotch.. :| May 09 17:12:03 ha, haven't heard the lumberjack song in ages May 09 17:12:28 tlwoerner I've given up on lumberjack -- but may have to restart.. I can't get anyone to call me back about the trees on my property.. May 09 17:12:35 RP: fray: Sorry, don't understand why relsoving a tag would need network connection. I can do it locally in my git2/... directory May 09 17:12:35 $ git rev-parse refs/tags/v2.10 May 09 17:12:35 bc56b2dcfcf844e39ae2a9c953eaeb35b0706ae4 May 09 17:12:40 damnit I'll PAY you to take them down safely.. but NO... you wouldn't want ot call me back May 09 17:12:45 tlwoerner. funny. I have a friend that is actually a lumberjack. that dude has some serious heavy equipment! May 09 17:12:48 netflix canada just added a bunch of monty python May 09 17:13:02 just stick with trailer park boys ;) :D May 09 17:13:14 u1106_ bitbake fetcher -always- goes out and resolves tags from a remote location.. tags can 'change', so it needs to make sure the upstream has not changed May 09 17:13:40 if you create a local mirror of the upstream, it will still go out to the mirror (which happens to be on your disk) ... but then you are responsible for updating your mirror async of the build system May 09 17:14:01 changing from a tag to a commit ID, means that it's not non-changing -- and if the commit is on the local system there is no reason to go look at the upstream May 09 17:14:05 you are right, they *could* change. Although I would call that very bad practice May 09 17:14:08 https://plus.google.com/+TrevorWoerner/posts/2Kb9nDizNue May 09 17:14:21 u1106_ tags change all the time, for better or worse.. May 09 17:15:15 zeddii: have you tried any of their drinks? May 09 17:15:17 when I have restrictions for internet access, I use a local mirror of the remote git repositories -- and tell bitbake to use my mirror.. May 09 17:15:17 ok, I see the point and I will find a workaround. Thanks for your help everybody May 09 17:15:32 workaround is 'easy', but it does mean you have to manage it May 09 17:16:10 (linux-yocto is one that I do this with..) May 09 17:16:26 I create a layer that has a git directory and local mirrors of the contents..) May 09 17:16:29 tlwoerner. not yet, but that's my retirement plan on the east coast! :D May 09 17:16:29 PREMIRRORS_prepend = " \ May 09 17:16:30 git://git.yoctoproject.org/linux-yocto-4.12.git git://${LAYERDIR}/git/linux-yocto-4.12.git;protocol=file \n \ May 09 17:16:30 git://git.yoctoproject.org/yocto-kernel-cache git://${LAYERDIR}/git/yocto-kernel-cache.git;protocol=file \n \ May 09 17:16:30 " May 09 17:17:09 zeddii: http://www.lcbo.com/lcbo/product/liquormen-s-dirty-ol-cad-whisky-trailer-park-boys/480442 is surprisingly good! May 09 17:17:23 tlwoerner I had no idea anyone would 'train a novice' in this.. May 09 17:17:34 I'm just used to 'grab the chain saw.. don't be an idiot' May 09 17:18:13 looks good! May 09 17:18:26 Joe MacDonald is the one who finally found me a Scotch I liked.. I still don't like Bourbon or 'Tennesse Wiskey' May 09 17:18:37 fray: nah, that's old skool, turns out there's a whole bunch of interesting, new, techniques May 09 17:18:37 problem with the one jjm found me was it's $150 a bottle.. :P May 09 17:19:00 tlwoerner my issue isn't the cutting down.. it's all of the work of taking care of it once it's down.. May 09 17:19:06 so the point is that the mirror needs to contain a true git repo. Not such tar tarball that I once copied from downloads? (Even if that tarball contains a git repo). Or what exactly makes the fetcher happy to *not* trying the network? May 09 17:19:32 (but the one tree near my house is hollow inside, and I'd be more likely to hit the house without appropriate machinery.. which is why I need a professional -- if they're around, there there are other trees I'd like them to remove.. May 09 17:19:40 u1106_ yes May 09 17:19:55 just close the original repository with git clone .... --bare --mirror May 09 17:19:58 u1106_: set SRCREV to a commit id, don't usse ;tag=, and it won't need to contact the remote May 09 17:20:08 but like I said, you are on your own for keeping it in sync with the upstream though May 09 17:20:24 but what RP/kergoth said.. move to commit id's and you don't have this issue any longer May 09 17:20:44 (I have things I need to track tags and branches on.. thus the mirroring strategy) May 09 17:21:59 fray: just like with tree falling, the branches are a pain ;-) May 09 17:22:08 exactly May 09 17:23:27 fray: the course was basically a two-day, hands-on expansion of https://www.youtube.com/watch?v=7FRKU4RmeD0 May 09 17:24:16 one thing (for tree falling) I don't have but should buy are the kevlar chaps.. I'm always worried the saw will skip and I'll severe a leg.. ;P May 09 17:24:48 yep, i've seen that happen, and i've got myself a pair May 09 17:24:49 I've got my MontaVista Hard Hat Linux - Hard Hat (yes it's actually a real hardhat w/ a log on it)... face shield, gloves, etc... May 09 17:25:38 kergoth: fray: so I ended up with setting the SRC_URI in a bbappend, to get rid of the tag set by the upstream recipe. Ugly maintenance issue, but do_fetch is happy now May 09 17:26:09 yes.. that works.. in a few cases, I've had to write some anonymous python to rewrite the existing SRC_URI... but it's all doable May 09 17:26:43 Ok, thanks everbody May 09 17:26:51 (if you know others will be doing bbappens on the SRC_URI -- just replacing it with your own value can cause problems.. thus the anon python chunk to do it 'inline').. May 09 17:26:59 I'd consider that an 'advanced' usecase though May 09 17:27:00 yeah that's what i was going to suggest, d.setVar('SRC_URI', d.getVar('SRC_URI', expand=False).replace(';tag=foo')) or whatever in anonymous python May 09 17:27:11 kergoth, exactly.. annoying but owrks May 09 17:28:56 (actually going back and checking, I wasn't able to do it in an anon sectionf or some reason -- in this case -- but had to do it via a handler in RecipePreFinalise.. :P something to do with processing order if I remember right... May 09 17:29:57 huh, wonder whyt hat is. woudln't expect PV/SRCPV to process before anonfuncs run May 09 17:30:45 thats what it was! May 09 17:30:46 so is the replace('tag'...) any safer the just setting a complete new SRC_URI. I mean if the upstream recipe / tag / sha1 changes I need to make a manual update anyway, don't I? May 09 17:31:05 because it used a tag.. the PV/SRCPV was processed BEFORE the anon python.. so it was still contacting the remote.. :P May 09 17:31:12 so I had to move it to a prefinalize handler.. ;P May 09 17:31:16 ah, interesting May 09 17:31:39 I seem to also recall it had something to do with the hash values changing after the anon python as well.. (due to the PV/SRCPV) May 09 17:32:27 i kind of wish we had the ability to run arbitrary little blocks of code as pre/post expansion hooks on particular variables. sort of doable by using inline python that returns the empty string, but.. May 09 17:35:06 could I make a "selftest" into my bbappend so that the build fails if the checksum of the upstream recipe changes or if the PV changes? Because then I should never miss my manual maintenance in the bbappend May 09 17:37:01 well actually for the changed PV I don't need to test, Whenever it changes my append will no longer be appended and do_fetch will fail again if they still use the tag in the SRC_URI May 09 17:53:32 you can do whatever you want in anonymous python. so yeah, you could easily extract the tag from the uri and if it changes error out indicating you need to adjust SRCREV to match May 09 17:53:35 i've actually done that before May 09 17:58:25 http://blogs.msdn.microsoft.com/commandline/?p=2995 May 09 18:23:27 whats with the yocvto rpi 3 builds latly May 09 18:53:39 moto-timo: you might want to look into https://github.com/kraj/meta-openembedded/commits/kraj/master if you are trying latest glibc rework May 09 18:53:58 https://github.com/kraj/meta-openembedded/commit/25cba67d6f8338df06d43d94c3882892b8c9ef65 May 09 18:54:02 is what you are looking for May 09 18:55:12 khem: RP was right that lmbench needs DEPENDS on rpcsvc-proto. does that only apply for glibc (not libc-musl)?? May 09 18:56:14 khem: so it should be DEPENDS_append_glibc = " rpcsvc-proto" ? May 09 18:58:34 New news from stackoverflow: Can't connect to free wifi network with iwconfig in Linux embedded [closed] May 09 19:00:06 khem: nevermind, I just looked at your commit. thank you May 09 19:00:14 khem: btw the mdadm gcc8 fix breaks with gcc<8 May 09 19:00:57 moto-timo: I planned to submit a pull to oe-devel after these changes were merged which I sent just now May 09 19:01:18 rburton: I can guess May 09 19:01:29 that warning is sort of new in gcc8 May 09 19:02:03 khem: thank you. I really appreciate the hard work. May 09 19:02:23 yw May 09 19:02:58 moto-timo: now you can see glibc becoming more like musl May 09 19:03:26 get rid of cruft even if it is painful... some competition is always good I guess May 09 19:05:32 once gcc8 lands I plan to review and drop more patches from gcc/glibc which we are carrying out of tree May 09 19:06:08 \o/ May 09 19:06:10 and drop crypt once the patch on discussions on ml ends and it lands in upstream glibc May 09 19:06:54 rburton: I think we probably can use pragmas May 09 19:18:04 fun also got a race in mesa May 09 19:22:13 rburton: runtime race ? May 09 19:36:47 yeah May 09 19:36:49 rburton: we should enable llvmpipe backend for x86 I have been using it for sometime May 09 19:37:04 yeah i've turned it on here May 09 19:37:16 wanted to see how much of a difference it made to qemux86-64 actually May 09 19:37:37 https://github.com/kraj/openembedded-core/commit/bd5b222a07e66809c7f113cdab9311d363626962 May 09 19:49:52 rburton: I see you're the recipe maintainer for cve-check-tool. Was going to email a patch to the oecore list for cve-check.bbclass. Are you the maintainer for that as well? May 09 19:50:12 jynik: i guess. fwiw i consider it broken beyond help May 09 19:50:32 rburton: Oh! Why's that? May 09 19:50:58 because the entire concept of actually trusting the mitre database is doomed May 09 19:51:10 feel free to mail the list though May 09 19:51:14 ideally with a patch ;) May 09 19:51:52 I see. Yeah, I'm trying to put together some guidelines for folks to better utilize some Yocto/OE features and was going to include a recommendation that they use cve-check. May 09 19:52:24 So would you say that presenting that with the caveat that it should be only used to supplement one's monitoring of advisories, and not be the sole source of information, is reasonable? May 09 19:53:06 yes thats fine May 09 19:53:32 i have A Plan for the future that doesn't involve cve-check May 09 19:53:52 "A" plan May 09 19:54:02 Fantastic... will keep an eye out and update my paper accordingly. :) May 09 19:56:12 jynik: its better than nothing but in suing it, we learnt what we really should be doing... May 09 19:56:18 er, using :) May 09 19:57:33 jynik: specifically the database has sufficient gaps and mismatches that you can't rely on it, but you can use it to double-check your own expectations May 09 19:59:18 RP, let me know when you want me to start taking on stable/sumo-next May 09 19:59:38 armpit: go for it! May 09 19:59:56 armpit: just bare in mind its not released yet May 09 20:00:37 rburton: interesting... sometimes a github.com//archive is a developer-released tarball (which kinda sucks) May 09 20:00:55 RP, yep. is the AB setup to do sumo builds ie autofill in parts? May 09 20:01:39 rburton: the tarball links from /releases/ point to /archive/ URIs: https://github.com/cisco/libsrtp/releases May 09 20:08:17 armpit: not sure May 09 20:09:44 * armpit good time for me to learn ; ) May 09 20:11:58 armpit: basically, no, that is missing May 09 20:12:18 armpit: adding autofill to the new buildbot codebase might be a better use of time May 09 20:25:22 rburton: sent a v2 along with some more fixes May 09 20:31:49 khem, a v8 has more power May 09 20:32:19 armpit: but more money for repairing May 09 20:37:30 armpit: some good v6s around now... May 09 20:40:41 RP: yeah I think v6 is right mix of money/power May 09 20:43:46 not if you need to run from the police May 09 20:47:41 tlwoerner: yes, those are autogenerated tarballs-from-tags May 09 20:47:57 tlwoerner: when it says "Source Code", that's github giving you a git-archive May 09 20:48:33 khem: was the only changed patch mdadm? May 09 20:50:34 rburton: so how does one differentiate between developer release tarballs on github (i.e. the "okay" ones) and the auto-generated github tarballs (i.e. the ones that should be fixed)? May 09 20:50:49 tlwoerner: anything with /archive/ is autogenerated May 09 20:51:28 rburton: even though it comes from /releases/ ? e.g. https://github.com/cisco/libsrtp/releases and https://github.com/cisco/openh264/releases May 09 20:52:40 the open264 page, release 1.7.0 has a lot of *maintainer provided* tarballs (the libopenh264-1.7.0.* files) and then the github-generated /archive/ links (Source code) May 09 20:52:55 the maintainer provided ones are good May 09 20:53:12 rburton: okay, excellent. thanks for the clarification :-) May 09 20:54:16 tlwoerner: https://github.com/rossburton/meta-ross/blob/master/classes/insanitier.bbclass#L93 :) May 09 20:54:30 should get around to putting that in core... May 09 20:55:23 rburton: yes :-) if i'm not mistaken, devtool will complain, but not bitbake itself May 09 21:04:08 right May 09 21:04:13 at least devtool does May 09 21:04:56 and as my own builds have that class in, oe-core itself is clean May 09 21:46:01 rburton: My apologies if I inadvertantly spammed you a patch twice. Forgot to click the link to activate my list subscription. May 09 22:12:24 jynik: you did, no worries May 09 22:13:15 afternoon Jefro May 09 22:27:14 can the git fetcher check out a tag? May 09 22:28:53 this is odd... if i clone https://github.com/cisco/openh264.git manually and checkout a180c9d4d6f1a4830ca9eed9d159d54996bd63cb it works, that's tag v1.7.0 May 09 22:30:05 but if i ask bitbake to clone and checkout that sha, it can't find it May 09 22:30:47 See the tag parameter in https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#git-fetcher May 09 22:31:12 It is common to just set branch=master and SRCREV to the sha1 of the tag, though May 09 22:34:38 tlwoerner: i'd suggest comparing the tag hash to the commit hash the tag points to, in the case where the tag is annotated May 09 22:34:40 neverpanic: ah, thanks May 09 22:34:43 i.e. git show —pretty=fuller sometag May 09 22:34:47 but yes, definitely avoid ;tag= May 09 22:35:35 the sha of the tag doesn't appear from master, if i'm on master, do a "git log", and search for the sha, it isn't found May 09 22:35:49 maybe the tag wasn't made on master? May 09 22:36:00 That would explain why the fetch fails for you with branch=master May 09 22:36:13 Try with nobranch=1; if that works, the branch is the problem May 09 22:36:57 nobranch=1 worked May 09 22:37:56 the tag doesn't appear on any branch May 09 22:37:59 $ git branch --contains a180c9d4d6f1a4830ca9eed9d159d54996bd63cb May 09 22:38:00 * (HEAD detached at a180c9d4) May 09 22:38:23 check it out: https://github.com/cisco/openh264.git May 09 22:38:38 https://github.com/cisco/openh264/releases May 09 22:38:48 GitHub's web interfaces says the tag is on the openh264v1.7 branch May 09 22:38:48 neverpanic: if the tag is on a branch, github will tell you that May 09 22:39:13 oh well, thankfully nobranch=1 works :-) May 09 22:39:14 https://github.com/cisco/openh264/commit/a180c9d4d6f1a4830ca9eed9d159d54996bd63cb has the branch annotation set to openh264v1.7 May 09 22:42:55 neverpanic: weird, now that i've checked out that branch, then returned to master, then tried the --contains command again, it now gives me the right answer ... :-S May 09 22:43:14 oh well, thanks :-D **** ENDING LOGGING AT Thu May 10 03:00:01 2018