**** BEGIN LOGGING AT Thu Jan 19 03:00:02 2017 Jan 19 04:00:53 is it safe to share the shared state cache amongst multiple build runners? eg for a CI system that may be doing multiple yocto builds at the same time Jan 19 04:03:22 yep. the one question mark is portability of native sstates if the build host is different. uninative helps, but isn't full proof in my experience. if the host is the asme, and you're just changing distro/machine/etc, it's fine Jan 19 04:17:49 @kergoth great, thanks. Jan 19 08:13:06 good morning Jan 19 09:39:41 maybe relevant to our interests: a release monitoring service https://lwn.net/SubscriberLink/711906/0bb77c05cf9d2b8f/ Jan 19 10:14:57 hi ed2 Jan 19 10:15:15 ed2: There were a couple of small glitches with wic but I have patches for them in my wip branch Jan 19 10:15:49 joshuagl, ed2: https://autobuilder.yocto.io/builders/nightly-wic/builds/144 is the remaining wic problem we're going to have Jan 19 10:16:20 joshuagl: I think we'll need a version bump and to replace that list of things with "wic-tools" beyond that version increment Jan 19 10:16:32 (the list in step 12) Jan 19 10:16:55 RP: hi, thank you for fixing it! Jan 19 10:17:07 RP: can do Jan 19 10:17:26 RP: why do you think we'll have problems with those builds? Jan 19 10:18:27 RP: I made do_image_wic to depend on wic-tools:build, so theoretically it should be ok. Jan 19 10:18:43 RP: I don't expect anything major at least. Jan 19 10:21:37 ed2: that autobuilder test runs "bitbake XXX" then expects wic XXX to work Jan 19 10:21:48 ed2: clearly that no longer happens Jan 19 10:22:04 joshuagl: open to other ideas but don't have any :/ Jan 19 10:24:28 ed2: build isn't enough, is it? i think you'd need it to depend on a different task which ensures the sysroot is populated? Jan 19 10:24:44 RP: it's a fairly common pattern in the AB codebase, I'm afraid I don't have a smarter idea Jan 19 10:28:18 joshuagl: what ed mentions works fine for images during a normal build, it isn't going to help this "external wic" usage case as written though Jan 19 10:29:46 RP: right. I have a snippet ready to test once a version bump is in Jan 19 10:30:41 joshuagl: I should queue a version bump in my wip branch... Jan 19 10:36:02 jku: interesting, we could replace bits of our RRS with this I guess Jan 19 10:36:30 git diff Jan 19 10:36:36 ohman, I s Jan 19 10:36:42 suck :-/ Jan 19 11:10:54 kanavin_home: might make a useful extra data source Jan 19 11:23:13 i missed what jku linked to Jan 19 11:30:24 rburton https://lwn.net/SubscriberLink/711906/0bb77c05cf9d2b8f/ (lwn on release-monitoring.org) Jan 19 11:32:32 ah Jan 19 11:40:46 RP: I can't reproduce that issue locally in my rss branch. Jan 19 11:41:11 ed2: which one? Jan 19 11:41:17 ed2: clean wic-tools first? Jan 19 11:41:45 RP: nope, this one: https://autobuilder.yocto.io/builders/nightly-wic/builds/144  Jan 19 11:42:08 RP: I think I fixed it yesterday. Jan 19 11:42:28 ed2: have I missed a patch in my branch? Jan 19 11:43:03 RP: I'll check it out. Jan 19 11:53:43 I'm testing "rpurdie/wip-rss". Where do I look to see the "native sysroot"? As in, where are the native tools that e.g. the target build of "shadow" uses? Jan 19 12:03:32 RP: I think I know what's the reason of that issue. We can solve it if we add this dependency: do_image[depends] += "wic-tools:do_build" Jan 19 12:04:34 ah it's $WORKDIR/recipe-sysroot-native Jan 19 12:05:50 RP: or modify wic code to run 'bitbake wic-tools' if wic-tools sysroots doesn't exist. Jan 19 12:06:43 erm Jan 19 12:06:56 Fetcher failure: Unable to resolve 'bf2942f7559d114e96f7c7f1287bf7e5120632a' in upstream git repository in git ls-remote output for git.yoctoproject.org/yocto-kernel-tools.git Jan 19 12:09:20 ed2: I don't believe that dependency will help Jan 19 12:09:32 ed2: I think we'll just have to tweak the autobuilder as mentioned Jan 19 12:09:49 rburton: zeddii forgot to push? Jan 19 12:09:58 i think so Jan 19 12:10:50 ah no, he's missing a letter from the sha ;) Jan 19 12:11:31 i'm sure this patch set was tested :) Jan 19 12:13:45 I am trying to create a recipe for libusbgx (which is an autotools project) but get a wierd error when autoreconf is running: http://pastebin.com/0FWYG6iz Jan 19 12:14:20 It appears that AC_DEFINE is not recognized as a valid command, which is rather odd, because it is one of the most basic of the autoconf commands... Jan 19 12:15:13 RP: why do you think it won't help? it should help to build wic-tools and wic should work after that in my opinion. Jan 19 12:16:07 The configure.ac is this one: https://github.com/libusbgx/libusbgx/blob/master/configure.ac Jan 19 12:21:13 deva: do you inherit pkgconfig? I vaguely remember that pkg-config macros can be invalid in shell if pkg-config is not available... and then you can get weird errors like that Jan 19 12:21:22 deva: have you inherited pkgconfig? Jan 19 12:21:34 heh, snap Jan 19 12:21:50 yeah if pkgconfig macros are not availabile the error message is literally the worst Jan 19 12:23:05 jku, rburton, inheriting pkgconfig worked Jan 19 12:23:18 Thanks - I could never have guessed that on my own :-D Jan 19 12:24:09 what you're getting here is the experience of spending a day to understand why configure fails like that ;) Jan 19 12:25:53 rburton, Did you find out /why/? Jan 19 12:26:30 because autoconf is a kludge of shellish wrapped in m4 Jan 19 12:26:32 I mean why the missing pkgconfig inherit could end up rendering that error messages? Jan 19 12:27:16 not sure, AC_DEFINE *is* a macro so there must be some m4 quoting going on that confuses it when it thinks PKG_CONFIG is a shell function and doesn't get expanded Jan 19 12:27:28 i valued my sanity at that point Jan 19 12:28:17 (the inherit adds a depends on pkgconfig-native so then the pkg.m4 file is present and PKG_CONFIG expands correctly) Jan 19 12:29:14 Content-Type: text/plain; charset="y" Jan 19 12:29:20 that really is the most annoying bug in git's ui Jan 19 12:29:34 I found a topic much resemling it, but the guy was creating a FreeBSD "recipe" Jan 19 12:30:02 He came to the conclusion that it was because of ACLOCAL_ARGS Jan 19 12:30:05 hi all, my image iherits extrausers and adds users/groups with EXTRA_USERS_PARAMS, but how can i chown within a recipe to a user in EXTRA_USERS_PARAMS ? Jan 19 12:30:05 https://lists.freebsd.org/pipermail/freebsd-ports/2008-August/050269.html Jan 19 12:36:39 RP: worked just fine for me: https://gist.github.com/bartosh/3ffe10879b58c1ef402d2c1e1c7829d7 Jan 19 12:37:30 RP: however, may be it's not the best idea to always build wic-tools as it will impact performance for no reason. Jan 19 12:37:42 RP: making wic to build wic-tools looks better to me. Jan 19 12:39:21 deva: the confusing part is IIRC that the autoconf error references the first use of AC_DEFINE not the place where things actually went wrong Jan 19 12:39:44 jku, That sounds like a reasonable explanation Jan 19 12:40:21 So basically it all boils down to the autoconf guys needing to work a bit on their error reporting mechanisms ;) Jan 19 12:45:01 ed2: or we just change the test case, I think that is fine Jan 19 12:46:36 rburton: does anything actually log the postinsts we run during rootfs creation? Jan 19 12:47:16 I can see the intercepts in log,do_rootfs, but what about all other postinsts? Jan 19 13:10:59 RP: I like building wic-tools better. It's a bit implicit, but it's convenient for users: https://gist.github.com/bartosh/6f72369b5e6cac16e58197f0250e00d5 Jan 19 13:12:19 RP: i mean users don't have to care about building it manually. wic will do it for them. Jan 19 13:15:32 ed2: I really don't want to run bitbake within bitbake Jan 19 13:15:47 ed2: well, put more simply, we can't Jan 19 13:16:06 RP: it's not about it. it's about wic running bitbake. Jan 19 13:16:26 RP: if wic is run from bitbake it would mean that wic-tools are already built. Jan 19 13:16:35 ed2: your patch removes a code line which will force this to bitbake wic-tools during image generation Jan 19 13:16:52 ed2: there was a reason I added native_sysroot = get_bitbake_var("RECIPE_SYSROOT_NATIVE", options.image_name) Jan 19 13:17:33 RP: yes, I did it for a reason too. that line introduces unneeded guessing. Jan 19 13:18:02 ed2: it fixed broken builds Jan 19 13:18:09 ed2: without it we saw breakage Jan 19 13:18:42 RP: if wic image is built by bitbake then wic-tools will be always build due to this dependency: do_image_wic[depends] += "wic-tools:do_build" Jan 19 13:19:08 ed2: was that added by some patch not in my branch? Jan 19 13:19:19 RP: if they're not built then there is bug that should be fixed. Jan 19 13:19:39 ed2: the tools get built but the wic-tools env file was not present Jan 19 13:19:50 Mornin Gents, what is the default make target Yocto calls in a Makefile. Trying to build a kernel module but compile step is just skipping everything. Jan 19 13:19:51 https://gist.github.com/strike5150/ea47fad28a188fd8b5116ad4b528bd43 Jan 19 13:20:17 ed2: a clean tmp, bitbake core-image-minimal would fail with None being returned by get_bitbake_var("RECIPE_SYSROOT_NATIVE", "wic-tools") Jan 19 13:20:35 ed2: there is a core-image-minimal.env file but not a wic-tools one Jan 19 13:21:38 https://gist.github.com/strike5150/c09fad30407124afc236ca28602b0736 Jan 19 13:22:39 Strike5150: See base_do_compile in base.bbclass Jan 19 13:23:02 Strike5150: its basically running "make" Jan 19 13:23:32 RP: Ok thanks Jan 19 13:25:27 RP: hm, now i see what happens. that can be fixed this or similar way: https://gist.github.com/bartosh/cb20e293fdcbe733ef3c1cf66b99d3f3 Jan 19 13:26:35 ed2: that is horrible, you're writing stuff to random locations and completely breaking the task/sstate structure :( Jan 19 13:27:16 RP: that's similar to how .env files are written, no? Jan 19 13:28:00 ed2: well, in that case the image recipe is writing a file to be picked up in a later task, The location its using should really be in WORKDIR Jan 19 13:28:20 RP: I've got a bunch of PACKAGE_WRITE_DEPS changes I'm testing (on top of rpurdie/wip-rss).... Jan 19 13:28:34 So I'm expecting matchbox-keyboard to fail rootfs time postinst (because it doesn't have "qemu-native:do_populate_sysroot" in PACKAGE_WRITE_DEPS) Jan 19 13:28:39 ed2: This is one recipe writing out something outside of the sstate tasks for another piece of the system to pick up, its quite a bit different in concept :/ Jan 19 13:28:51 but it just works Jan 19 13:29:00 jku: I think qemu-native is pulled in by other things :/ Jan 19 13:29:12 RP: it's just an idea. Can it be implemented better way? Jan 19 13:29:40 ed2: why can't we just do what I did and use the image env file if its present? Jan 19 13:30:14 RP: should I not see the qemu binaries in recipe-sysroot-native in that case ? Jan 19 13:31:12 jku: ah, you should. You don't? Jan 19 13:31:32 no Jan 19 13:32:17 jku: and it still works? Perhaps it finds a qemu binary from your host? Jan 19 13:33:16 yeah it works. I'm pretty sure I don't have qemu on build host... I'll add a bit of logging to see what it really calls Jan 19 13:33:26 RP: That approach assumes that all wic deps are in image recipe sysroot. This is true for default configurations, but creates additional work for users if they want to use other wks files. Jan 19 13:33:58 ed2: presumably those users would just build wic-tools? Jan 19 13:34:11 RP: this practically means that users will have to either built wic-tools or modify image deps. Jan 19 13:34:40 ed2: which is pretty much what they do today without the "wic-tools" shortcut? Jan 19 13:35:27 RP: yes, but it's not nice. as we anyway build wic-tools do to do_image_wic dependency on it we should use it too :) Jan 19 13:35:49 RP: the only reason we can't use it is that .env file is not generated. Jan 19 13:37:08 RP: btw, even if they build wic-tools and run bitbake it will not help. Jan 19 13:37:23 ed2: I just realised that, you're right :/ Jan 19 13:38:35 ed2: I guess we have to change wic-tools as you propose Jan 19 13:38:48 ed2: this is going to race though :( Jan 19 13:38:59 RP, so the qemu is on the _image_ recipe recipe-sysroot-native. I guess that makes sense? Jan 19 13:39:06 RP: then we should do it better way. Can you suggest which? Jan 19 13:39:34 RP: Can we do it in image_types.bbclass somehow? Jan 19 13:39:59 RP: the same way as it's done for images? Jan 19 13:40:06 ed2: you should probably combine the two tasks in wic-tools too, they're both python Jan 19 13:40:28 ed2: we can easily add this to the other env file generation but that is even worse for races Jan 19 13:40:57 jku: yes, that is the intent Jan 19 13:42:37 ed2: I'm not sure I have better ideas Jan 19 13:43:04 ed2: what I really don't need is another round of testing of these changes but I guess we can't avoid that Jan 19 13:53:17 RP: rburton: can you think of ~recent (since Morty) changes that might cause the environment during testsdkext to have been cleaned of several more variables? Jan 19 13:53:52 joshuagl: offhand, no Jan 19 13:56:13 dumping the environment during host_gcc_version() the env in master is much, much more. I don't see any evidence of the OE_/OECORE_ namespaced environment variables Jan 19 13:57:08 "much, much more *spartan*" that should've been Jan 19 14:43:56 weirder and weirder, reverted rburton's patch "utils: Always use datastore's PATH for host_gcc_version" on my master branch and tests are running fine Jan 19 14:51:39 *sigh* desktop wedged Jan 19 14:53:05 think I need to bisect master and find what made the env change happen, back in a few days :-) Jan 19 14:53:59 presumably if you're after a specific file you can shortcircuit it as much as possible Jan 19 14:54:23 I haven't narrowed it down to a specific file, unfortunately Jan 19 14:54:32 the environment scripts are the same in each Jan 19 14:55:15 joy Jan 19 15:03:44 or its opposite Jan 19 15:52:25 Is it possible to have a floating SRCREV in a recipe? By that I mean, that it will fetch the tip of a given branch, and set its SRCREV accordingly? Jan 19 15:52:42 you want AUTOREV Jan 19 15:53:02 SRCREV = "${AUTOREV}", specifically Jan 19 15:53:09 http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-AUTOREV Jan 19 15:53:16 yeah, that. thanks kergoth Jan 19 15:53:23 :) Jan 19 15:55:06 Yes, and we already do use AUTOREV. I think my question is a little different and a little longer, so bear with me: Jan 19 15:56:13 perhaps you want buildhistory-collect-srcrevs, which writes a config file with SRCREV_pn- lines, to lock down the autorevs as of now Jan 19 15:56:35 that's what mentor uses to deal with autorev for our releases, since we want to support BB_NO_NETWORK Jan 19 15:58:12 Hello - I've made a variation on my recipe, called my-recipe-dbg_0.1.bb. It applies a patch that changes CFLAGS and the output filename of the build. Jan 19 15:58:12 Our top-level CM system sets the version of a git repo that a recipe should use, by setting in local.conf: SRCREV_pn-myrecipe = "8787837733..." and BRANCH_pn-myrecipe = "master" Jan 19 15:58:58 When I try to put both builds on the same system, despite the different output filename, I get conflicts in sysroots/genericx86-64/pkgdata/runtime-reverse/my-recipe Jan 19 15:59:10 The recipe does set SRCREV = "${AUTOREV}" to ensure sstate cache is sane, and this works Jan 19 15:59:38 Circuitsoft: is it a library? the package names get renamed to the library name inthat case Jan 19 15:59:59 No. Jan 19 16:00:13 Each package has one file: /usr/bin/myapp, and /usr/bin/myapp-dbg. Jan 19 16:00:15 This works fine for checking out pinned, specific versions, but how can I make the recipe check out the lastest version and update AUTOREV/SRCREV accordingly? Jan 19 16:00:22 that doesn't really make sense Jan 19 16:00:38 sveinse: what do you mean "update AUTOREV/SRCREV accordingly"? Jan 19 16:00:44 a recipe isn't going to modify itself. Jan 19 16:00:50 layers are not output of the build Jan 19 16:01:11 or did you forget to add SRCPV to PV, so it doesnt' know to rebuild when the upstream branch is updated? Jan 19 16:01:16 No, but the artefacts its generates needs to have AUTOREV in it. But let it pick the latest version from git Jan 19 16:01:33 no idea what you're talking about Jan 19 16:01:47 if you set SRCREV = "${AUTOREV}, it will pick the latest version from git, that's the entire point Jan 19 16:02:07 ok Jan 19 16:02:51 what happens if I from local.conf set : SRCREV_pn-myrecipe = "123456..." ? Jan 19 16:03:01 then it checks out that version, right? Jan 19 16:03:03 that will override SRCREV in the recipe, so it isn't using AUTOREV anymore. Jan 19 16:03:09 if you want the latest, don't do that Jan 19 16:03:30 right, that was my question Jan 19 16:03:41 again, if you want to track a branch head, use autorev Jan 19 16:03:45 you weren't using autorev Jan 19 16:05:08 right. I assumed the recipe construct SRCREV = "${AUTOREV}" was to ensure that the *output* from the receipe, e.g. what goes into sstate cache got a version that corresponds to the repo version, but it's not. Jan 19 16:05:18 SRCREV has one meaning, not two Jan 19 16:05:32 SRCREV is what version is fetched. if you set it with an override, that replaces the previous value Jan 19 16:05:41 bitbake doesn't magically use every value a variable has ever been set to Jan 19 16:05:46 understood Jan 19 16:05:48 SRCREV_pn- *replaces* the value of SRCREV Jan 19 16:05:53 that's how overrides work Jan 19 16:07:28 * kergoth ponders Jan 19 16:07:50 top-level configuration managment is not always easy Jan 19 16:17:54 rburton: I've queued the patches I just posted in -next Jan 19 16:18:12 rburton: mostly things that fell out of rss but can be isolated Jan 19 16:18:59 jku: do you have a branch with your changes? Jan 19 16:19:20 ed2: did we decide how to proceed with wic? I could probaby use a patch against my branch if possible please? Jan 19 16:20:39 RP: sure. I have around 4 in my branch. I'll push them in 10 minutes as soon as tests pass. Jan 19 16:21:01 rp: just writing an email, but the branch is jku/wip-rss in poky-contrib, based on rpurdie/wip-rss Jan 19 16:21:11 ed2: I've just rebased my branch against master and the patches I've posted Jan 19 16:21:26 jku: thanks. Just to warn, I just did rebase and repush mine Jan 19 16:21:54 RP: do you want me to rebase my branch against yours and test again? Jan 19 16:22:31 jku: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jku/wip-rss&id=95ba4334f94dad2d2c002a375356405690d41582 - should be virtual/update-alternatives-native Jan 19 16:22:54 oh yes Jan 19 16:26:04 jku: series looks good though, exactly what we need. Probably need to split my changes up to match and rebase all this against master Jan 19 16:26:21 rburton: did you find that function we talked about? Jan 19 16:27:26 RP: i think i remember almost adding something to lib/oe/ repeatedly but it not actually surviving Jan 19 16:27:42 its just a join and lambda Jan 19 16:28:01 rburton: I think we should still do it Jan 19 16:28:03 " ".join(s + ":" + task for s in input.split()]) should work Jan 19 16:28:25 must be plenty of places where we can remove the same logic Jan 19 16:28:46 rburton: right Jan 19 16:30:09 sounds handy for depends flag construction Jan 19 16:31:45 RP: I pushed my branch ed/wic/rss to contrib for your review. Jan 19 16:32:03 RP: will rebase it against your branch and run tests again. Jan 19 16:33:17 ed2: thanks Jan 19 16:35:32 RP, fixed the missing "-native", rebased, force pushed Jan 19 16:38:32 jku: cool, thanks. You're going to send email? Jan 19 16:39:46 kergoth: yeah exactly that Jan 19 16:42:18 RP, I'll respond to your -architecture mail, just to note that I've tested it and have some patches Jan 19 16:42:52 jku: sounds good thanks Jan 19 16:43:16 jku: I think I'll work on taking your patches, reformating mine and adding this function rburton and I are talking about Jan 19 16:44:16 ed2: I don't need http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=99100b0b5f92dd972dfb36035e8cbc7beceb2469 anymore right? Jan 19 16:44:58 no, you don't Jan 19 16:45:16 and it should conflict with my patch I think Jan 19 16:46:47 RP: with this one https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ed/wic/rss&id=e4a4a5140694ae1fd4ebd67f09b43ef610d78629 Jan 19 16:47:23 RP: how does buildhistory interfere with selftest? i have it enabled (can't recall when i last did a full selftest though) Jan 19 16:47:38 would it be better for selftest startup to INHERIT_remove buildhistory instead? Jan 19 16:49:55 rburton: if you get "warning, package version went backwards" due to sstate, it fails tests Jan 19 16:50:15 ah Jan 19 16:50:17 yeah fair enough Jan 19 16:50:28 i think i wipe that from WARN_QA here too :) Jan 19 16:50:30 ed2: right, yes, that should conflict Jan 19 16:51:52 rburton: I'll tweak the commit message Jan 19 16:54:24 * kergoth disables that warning in pretty much all of his builds, too often make a change to test something out and then revert, gets old fast Jan 19 16:58:09 kergoth: yeah, exactly Jan 19 17:35:32 Is there a proper cmake toolchain file that can be generated along with the populate_sdk step for an image. Basically I want to generate a toolchain against my image so I can run it on other machines to build packages Jan 19 17:50:18 So, I'm using Yocto to run an X11-based appliance at a customer site. If I need to SSH in to do some work, and want it left alone, is there a recommended way to lock the screen with a "leave me alone" message? Jan 19 17:50:55 a locked screensaver? Jan 19 17:51:15 I was thinking something like xloadimage, or i3lock. Jan 19 17:51:28 xloadimage would work, but I can't find it, or anything like it, in any standard repositories. Jan 19 17:52:58 probably trivial to write a recipe Jan 19 17:56:08 fray: thanks for comments - I'm currently getting to the point where image creation works for 'complex' images like sato Jan 19 17:56:37 fray: once that is done, I'll look at fixing the issues you raised Jan 19 17:57:23 sstate-cache, relocated SDK and non-intel arches are likely the biggest concerns for testing Jan 19 17:57:24 RP: tested my commits on top of your rss branch - all tests pass. I pushed it to my ed/wic/rss branch, so you can either cherry-pick from it or reset your branch to it. Jan 19 17:57:29 * darknighte hates when IRC silently disconnects Jan 19 17:57:48 fray: core-image-minimal builds for aarch64, fwiw Jan 19 17:58:17 ed2: thanks, I just merged that into my branch and updated Jan 19 17:58:34 fray: and I guess we can teach rpm to look for platform configuration in rootfs, or even have it configured dynamically from dnf Jan 19 17:58:36 ed2: I squashed the wic-tools.bb changes Jan 19 17:58:54 mips, powerpc (the non qemu ones) and some of the more essoteric arm ones will likely break the arch handling Jan 19 17:59:09 (my guess is they don't have the mips tri-lib implemented either, last time I looked it was missing) Jan 19 17:59:35 and yes -- rpm should be reason the platform config from the rootfs.. if it's not, I'd call that a bug in their stuff.. Jan 19 17:59:59 sometimes i wish we had some sort of postponed search/replace feature. can always use anonymous python or an event handler, which is what i usually do, but still Jan 19 18:00:15 _remove/_append won't do, since then you append whether what you wanted to remove was there or not Jan 19 18:02:41 kergoth: a _replace operator? that would be fun for function name clashes! :) Jan 19 18:03:11 indeed. i can't imagine it'd be worthwhile, and syntactically would be an issue, just a slightly common pattern Jan 19 18:03:17 oh well Jan 19 18:05:49 fray: so you're not against getting rid of rpm5 in principle? if we can add all the missing stuff to rpm4 Jan 19 18:07:09 RP: this last time change is still missing in your branch: https://gist.github.com/bartosh/cd84d3901650eb24fcffa57a043282a2 Jan 19 18:08:53 RP: I squashed it into this commit: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ed/wic/rss&id=b1820cb0b1bc78e3dfb1dcde1ddd01e88acbd954 Jan 19 18:28:13 pohly: i need to go, can you check that origin/master-next in poky has the fixed rmwork patches in? i just got conflicts when rebasing and i think it has the broken patches too. (cc RP) Jan 19 18:30:17 rburton: RP: FYI the eSDK patches I just sent are fairly important, if there's any chance of them making it into M2 it would be great if they could go in Jan 19 19:07:08 This may be a silly question, but wouldn't going from rpm5 to rpm4 be sort of downgrade-like? Jan 19 19:11:26 seebs: rpm5 was like a fork/rewrite and rpm4 kept progressing Jan 19 19:11:30 rburton: f0479968cf7d8 = origin/master-next doesn't have any of my rm_work related patches, which is as it should be, as one of them is the WIP bitbake event patch. Jan 19 19:11:47 What's the correct way to use a custom bsp .scc file located in my custom bsp layer? If I specifically include it in SRC_URI it appears to get processed twice by scc according to the meta-series output file. It then tries to apply patches to standard/preempt-rt/base that don't apply. When building on another platform using intel-core2-32-preempt-rt.scc it only gets processed once and no incorrect patches are applied. Jan 19 19:12:03 ahh, i see. Jan 19 19:12:31 If I don't include it in SRC_URI it's never applied at all. I'm wondering if this a new problem with the last big push to morty since I didn't notice this before. Jan 19 19:12:58 rburton: the insane.bbclass patch in OE-core master-next and poky master-next is the one without my commit message fix - not terribly important, so better don't worry about that. Jan 19 19:20:05 ed2: thanks, I've merged that in Jan 19 19:21:36 pohly: the bitbake event patch did hit the list and is in bitbake master-next now Jan 19 19:22:49 RP: so should I send a revised patch series or can you or Ross just pick everything except that patch from what I posted? Jan 19 19:23:28 Can someone help with this error https://gist.github.com/strike5150/41c327a91520102446c46726bb91182a, I have cleaned and rebuilt but I keep getting this QA issue. I Jan 19 19:23:46 Its building against 4.4.11 but mentions 4.4.3 in vmlinux/boot Jan 19 19:27:26 pohly: we should be able to pick it up Jan 19 19:28:09 RP: there's also this one-line fix which needs to be added. Never mind, I'll just send a new revision. Jan 19 19:28:33 I've started to use "git series" and so far like it. Jan 19 19:29:34 I still need to ask, though, whether not using create/send-pull-request poses a problem for you guys. Jan 19 19:48:47 pohly: As long as they're patches it works for me, not sure about ross. Sometimes with a complicated series I do use the git branches Jan 19 19:50:49 RP: the branch could be created also when using "git series", it just needs some additional tooling, also for the boiler plate text in the cover letter. Jan 19 19:50:57 pohly: i'm happy with bare patches, for a long series a pointer to a branch is good Jan 19 19:51:01 * rburton looks up git series Jan 19 19:51:15 its purple in google so presumably i've seen this before Jan 19 19:51:16 georgem: if zeddii doesn't see your question I'd suggest posting a message to the mailing list and CCing him (Bruce Ashfield) Jan 19 19:52:29 rburton: v3 of the bitbake rmwork series sent. The OE part is unchanged. Jan 19 19:55:23 Hmm, random idea: new flag that lets you add an expansion / getvar hook to a variable. when it's used, the hooks are called and can optionally alter the value. could be used to implement search/replace, and could even theoretically subsume handling of _append/_prepend/_remove/overrides Jan 19 19:57:50 kergoth: sounds expensive on execution cost... Jan 19 20:09:48 that would be a concern, yeah. obviously the logic owuldn't be much more, but there'd be extra function calls, and worse, expansion and splitting of the flag itself, unless that's done at setvarflag time Jan 19 20:09:51 just a random thought Jan 19 20:17:34 bluelightning: will do, thanks Jan 19 20:26:23 damnut! Jan 19 20:26:37 ed2: can you have a look at ^^^ if you're around? Jan 19 20:26:43 * rburton -> dinner Jan 19 20:30:28 is anyone fixing create-pull-request for the OE cgit URL change? Jan 19 20:31:24 rburton: yep, will look Jan 19 20:38:18 rburton: wic failures are caused by this failure: https://autobuilder.yoctoproject.org/main/builders/nightly-wic/builds/592/steps/BuildImages Jan 19 20:39:18 rburton: gptdisk-native failed to build: ERROR: Nothing RPROVIDES 'gptfdisk-native-sgdisk-native' (but virtual:native:/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-wic/build/meta/recipes-devtools/fdisk/gptfdisk_1.0.1.bb RDEPENDS on or otherwise requires it) Jan 19 20:40:00 rburton: this thing looks quite strange: gptfdisk-native-sgdisk-native Jan 19 20:47:20 ed2: the patch that implemented that looks reasonable... just trying it on top of master now Jan 19 20:48:11 ed2: hmm, it does indeed fail on master Jan 19 20:48:15 not sure why... Jan 19 20:48:47 RP: can you explain what could be wrong with this patch? surely in the native case we should be ignoring the RRECOMMENDS? http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/meta/recipes-devtools/fdisk/gptfdisk_1.0.1.bb?h=ross/mut2&id=9e99c35e0e5bbaca1eab696a40493e20fbe00721 Jan 19 20:51:44 bluelightning: which failure did this cause? Jan 19 20:52:01 ah, 592 above? Jan 19 20:52:05 RP: yep Jan 19 20:52:12 reproduced locally too Jan 19 20:52:32 it's bizarre, surely we do this kind of thing all over the place Jan 19 20:54:04 bluelightning: I can explain what happened Jan 19 20:54:13 bluelightning: not sure you'll like it Jan 19 20:54:27 ok ... ? Jan 19 20:55:04 bluelightning: a long time ago there was a thread where I complained about how hard it was to make native BBCLASSEXTEND work. In the end I forced a switch from XXXX-nativesdk to nativesdk-XXX - do you remember it? Jan 19 20:55:14 yep Jan 19 20:55:22 I wasn't able to convince people that native-XXX was better though Jan 19 20:55:54 This is basically that problem rearing its head, the native BBCLASSEXTEND code is getting confused about how to remap the variables Jan 19 20:56:13 It sets PN = ORIGPN + -native Jan 19 20:56:33 then it extends the "${PN}-sgdisk" to become "${PN}-sgdisk-native" Jan 19 20:56:35 right, I had assumed that Jan 19 20:56:51 what I don't quite understand is why it cares about these values for -native Jan 19 20:57:17 and why we haven't seen this elsewhere (am searching for other examples now) Jan 19 20:57:19 bluelightning: we have a lot of implied knowledge in the RDEPENDS. If native doesn't look at the RDEPENDS, the system doesn't work Jan 19 20:57:31 hmm, maybe we have been over that before Jan 19 20:57:35 bluelightning: we do see this elsewhere but we have overrides Jan 19 20:58:29 presumably RRECOMMENDS_${BPN} would work? Jan 19 20:58:41 oh wait, that would break for nativesdk Jan 19 20:59:14 bluelightning: no, the preferred way to handle is RRECOMENDS_${PN}_class-native = xxx Jan 19 20:59:40 we do seem to do that in a lot of places, I'll grant you Jan 19 20:59:42 ok Jan 19 21:00:11 bluelightning: I do have a bug to go back and try and untangle this mess, probably due for M2 Jan 19 21:01:16 bluelightning: it is something we need to think about fixing :/ Jan 19 21:01:22 how, I don't know Jan 19 21:02:34 bluelightning: from what I remember, in the native case, we do rely on these depends having made it into the sysroot as well as the main recipe Jan 19 21:03:02 RP: I think you're right, we do Jan 19 21:03:06 so somehow we need to collect up a recipe's runtime dependencies in the native case since we're not just building thing but running it Jan 19 21:31:57 I think rss is going to break me :/ Jan 19 21:32:17 I have a bug the autobuilder doesn't find and I can't easily debug, somewhere in sstate afaict Jan 19 21:33:51 RP: what's the bug? Jan 19 21:34:45 bluelightning: the contents of the sysroot components directory disappears under certain rebuild circumstances like a large rebuild of an existing tree Jan 19 21:35:29 hmm, nasty Jan 19 21:36:08 are you able to trigger it reliably? Jan 19 21:36:18 bluelightning: not as yet Jan 19 21:36:19 or have you just hit it for the first time now? Jan 19 21:36:21 ok Jan 19 21:56:49 bluelightning: I can't replicate it :( Jan 19 22:07:23 ed2: damnit, that's a patch i re-merged because i couldn't remember why it broke. now i remember Jan 19 22:07:26 thanks ed2 Jan 19 22:56:21 bluelightning: are you aware of https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/152/steps/Running%20oe-selftest/logs/stdio - test_devtool_modify ? Jan 19 22:57:32 (centos7) Jan 19 22:57:36 RP: no.. :/ Jan 19 22:58:07 I'm a bit surprised we didn't see this earlier Jan 19 22:58:14 that change went in a while ago Jan 19 22:58:44 I'll see if I can see what's causing it after I get back from lunch Jan 19 23:22:39 bluelightning: its possible it was finding something like git-native from the sysroot previously Jan 20 00:45:50 hmm, I was wrong, it's a recent change to the test... testing a fix right now **** ENDING LOGGING AT Fri Jan 20 03:00:02 2017