**** BEGIN LOGGING AT Fri Jul 28 03:00:00 2017 Jul 28 06:56:14 has there been a change with regards to sysroots in pyro? Jul 28 06:56:40 my build/tmp/sysroots/ is empty now Jul 28 07:18:53 I see there's a new directory called sysroots-components Jul 28 07:19:04 but not sure to what extent that needs to be used Jul 28 07:20:26 so because the sysroot is empty, I now get this kind of errors: Jul 28 07:20:31 usb_modeswitch.h:26:20: fatal error: libusb.h: No such file or directory Jul 28 07:20:42 this used to work fine with morty Jul 28 07:29:34 gartin: have a look at section 6.11.1 in the ref-manual Jul 28 07:45:45 hnje, thanks Jul 28 08:12:20 I actually have the DEPENDS already but something is wrong Jul 28 08:14:58 the required headers and files are not found in recipe-sysroot-native Jul 28 08:15:53 It looks like tar-doc and cpio-doc both want to install "/usr/share/man/man8/rmt.8" on current master when building a full-cmdline image. Do we have a usual way to handle this? Jul 28 08:16:02 I've not seen update-alternatives used for man pages Jul 28 08:16:50 This is with EXTRA_IMAGE_FEATURES += "doc-pkgs" Jul 28 08:17:16 docs are bad, mkay? Jul 28 08:45:29 From a distro point-of-view I can just drop rmt.8 from cpio-docs in a do_install_append but I don't think that's ok to force on everyone Jul 28 08:54:21 Hi all, what is the easiest way to deploy openCL/GL on a custom target inside Yocto ? Jul 28 09:08:57 What m4 recipe in OE-core provides AC_MSG_ERROR? Jul 28 09:10:01 It's in autoconf-archive, but that is in meta-oe. Jul 28 09:25:23 Hmm, isn't AC_MSG_ERROR part of the normal autotonf? So why the heck does autoreconf not find it? Jul 28 09:41:51 What is the correct way to override the prefix for an autotools package? I have one specific package I want installed in /opt instead of the usual /usr Jul 28 09:53:41 Is "possibly undefined macro: AC_MSG_ERROR" perhaps caused by AX_PTHREAD not being defined in "AX_PTHREAD([], [AC_MSG_ERROR([requires pthread])])"? Jul 28 09:54:05 autotools, thanks a lot - that error message was super helpful. Not. Jul 28 09:54:05 Hi! it appears perl-using packages are broken with recent perl versions on the build machine :-/ Jul 28 09:54:35 https://www.irccloud.com/pastebin/r3HDk22K/broken%20perl%20dependencies Jul 28 09:54:50 is that a known issue? Jul 28 10:11:10 e.g. intltool is broken :-/ Jul 28 10:11:34 intltool-native, to be more specific. Using Arch to build. Jul 28 11:09:40 kergoth: Thanks, I've been finding it has been hit-or-miss as a reference. And you're correct about the kernel; I can consistently see the expected value if prior to compile of virtual/kernel I check its 'include/generated/compile.h' file for UTS_MACHINE. Jul 28 11:10:14 Now I'm off trying to figure a way to ferret that value out from other recipes. Jul 28 11:19:48 And it looks like STAGING_KERNEL_BUILDDIR is the ticket. Jul 28 12:01:59 rburton: there ? Jul 28 12:02:06 khem: aye Jul 28 12:02:14 rburton: I have pushed llvm changes to a branch Jul 28 12:02:18 yeah saw! Jul 28 12:02:28 3 patches Jul 28 12:02:38 pushed one just now Jul 28 12:02:47 should complete the set Jul 28 12:02:52 give it a shot on AB Jul 28 12:03:07 it worked in my limited testing Jul 28 12:04:20 http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/llvm Jul 28 12:06:08 khem: if you can fiddle mesa to use it then we can actually exercise it on the AB Jul 28 12:12:51 hi, what is the normal path to install binary's and data files Jul 28 12:20:11 I'm trying to go from morty to pyro. All of the groupadds are failing. groupadd is not in the packages' recipe-sysroot-native and I guess the Ubuntu groupadd is somehow incompatible. Is this a known problem? Jul 28 12:24:04 rburton: first thing is to build it for all arches Jul 28 12:32:28 khem: world doens't happen on all arches Jul 28 12:32:43 i can add it to the sato for a test build though Jul 28 12:41:19 rburton: I tried to enable it on mesa Jul 28 12:41:35 found that I need to provide llvm${PV} Jul 28 12:42:20 really, or can we fiddle the mesa recipe if we're adopting llvm into core? :) Jul 28 12:44:18 rburton: should "inherit autotools pkgconfig" be enough such that PKG_CHECK_MODULES is found during autoreconf? Jul 28 12:44:26 yes Jul 28 12:44:45 Hmm, tpm2.0-tools also needs DEPENDS = "pkgconfig". Jul 28 12:45:42 But it runs its own "bootstrap" script, so perhaps that's screwing up something. Jul 28 12:47:42 yes Jul 28 12:57:25 rburton: the tpm tools needs things like AX_CHECK_COMPILE_FLAG and AX_PTHREAD from autotools-archive, which is in meta-oe. Is there anything corresponding to that in OE-core? Jul 28 12:57:43 jku was working on moving that to oe-core Jul 28 12:57:58 the first step was getting rid of gnome-common, so in theory you can just copy it over now Jul 28 12:58:21 rburton: that would be the right solution for this problem. Jul 28 12:58:54 (jku is on leave so you're welcome to move it to core) Jul 28 12:59:31 okay Jul 28 13:52:00 Is there no longer a combined, staged sysroot in pyro? I'm trying to use STAGING_DIR_HOST as in the past, but the path it's providing contains nothing that was staged prior to the recipe running into configure. Jul 28 13:52:13 it actually contains nothing... it's up in the recipe. Jul 28 13:54:49 Hi, the meta-openembedded layer provides a recipe mpv_0.24.0.bb that I wanted to use but the version was too old. So in my own layer I added a recipe with the name mpv_0.25.0.bb but for some reason bitbake does not detect this new version. If I rename it to asdf_0.25.0.bb it is detected but I want to use the mpv_0.25.0 name, how can I do that? Jul 28 13:56:41 wouterstreamit: make a branch in meta-oe, update the recipe, and send the patch to oe-devel list :) Jul 28 13:56:57 wouterstreamit: making own layers for that kind of thing is discouraged Jul 28 13:58:38 Hello all, I'm trying out pyro (after using morty and krogoth a while) and getting a bit lost on how to migrate my STAGING_DIR_* requirements. I have a file that gets created by one recipe that I need to source from a different recipe, however the various _HOST and _TARGET paths are defaulting to the dependent recipe's "recipe-sysroot", and there seems to be no common staging path anymore. Jul 28 14:00:08 tgoodwin: if the file gets installed by the recipe into the sysroot, and the dependent recipe has that recipe in its dependencies, then the file should appear in the recipe-specific sysroot for that dependent recipe Jul 28 14:00:42 tgoodwin: that's a new feature of pyro, so that recipes get deterministic sysroots when they are built Jul 28 14:05:52 tgoodwin: basically if a recipe depends on something put in the sysroot by another recipe, then that other recipe should be in DEPENDS Jul 28 14:09:53 rburton: Yep, I've ensured the dependent recipe has a DEPENDS for this other recipe that puts the file in sysroot and verified that the recipe is deploying that file into sysroot-components (I assume this is the "affirmative" that my recipe works correctly) Jul 28 14:10:43 kanavin: this dependent recipe has nothing at all in its recipe-sysroot despite having loads of depends that were working prior to pyro. Jul 28 14:16:14 Ah... I think I see the issue. I don't think it's actually made it to 'configure' for the dependent package just yet (it hung up on a task I inserted between patch and configure). Jul 28 14:37:08 rburton: on llvm recipe I have to do some more work it seems it doesnt provide cross llvm-config Jul 28 14:37:35 rburton: meanwhile you can take the ninja and re2c patches they are independent of llvm Jul 28 14:37:45 ok, cool Jul 28 14:37:59 they're literal copies of what is in meta-oe? Jul 28 14:38:01 I guess I also need to get llvm-common into oe-cor Jul 28 14:38:23 rburton: they are copies then bettered by Khem Jul 28 14:40:29 :) Jul 28 14:57:43 Trying to understand why shadow-native dependencies are being filters out by setscene_depvalid. https://github.com/openembedded/openembedded-core/blame/pyro/meta/classes/sstate.bbclass#L949 Jul 28 16:58:21 kergoth: I just updated https://bugzilla.yoctoproject.org/show_bug.cgi?id=11698 - any chance you could see if we can fix that now we have a solid reproducer/details? Jul 28 16:58:22 Bug 11698: normal, Medium+, 2.4 M2, kergoth, NEW , Git shallow fetcher sometimes fails selftest Jul 28 16:59:17 ab.yocto.io is ready for work. Jul 28 16:59:50 halstead: was just about to ask about that, thanks! Jul 28 17:00:01 :) Jul 28 17:00:39 * RP fires a new test build Jul 28 17:01:37 RP: thanks, yeah, that should make it much easier, i'll take a look later this afternoon Jul 28 17:02:00 RP, I'm going to add more workers today and will probably mess up a few builds getting them tested. Do you have anything specific I should build? Jul 28 17:02:13 kergoth fyi - https://pastebin.com/hTKSSgUV Jul 28 17:02:28 that is the failure on my CentoS 7 machine.. doubt it adds anything above and beyond that existing bug Jul 28 17:02:31 it's a weird one Jul 28 17:02:34 * kergoth nods Jul 28 17:03:52 bitbake sure gets unhappy when you use ${} syntax on an undefined var from inside inline python Jul 28 17:05:29 my guess is that something changed in the display of a parameter between 1.8 and 2.x Jul 28 17:10:17 halstead: master-next and master are both things which I could use results on Jul 28 17:10:32 halstead: rburton may also have a mut, not sure Jul 28 17:10:43 kergoth: so many bugs and so little time :/ Jul 28 17:10:49 no doubt Jul 28 17:11:00 kergoth: I'm hopeful the server startup is at least a bit more robust now Jul 28 17:11:04 halstead: i do. feel free to fire a ross/mut, it needs a test Jul 28 17:25:15 Does anyboy know how to to enable autologin with the busybox getty in Poky? Jul 28 17:26:34 I have tried a sysvinit-inittab bbapend that has a do_install() that builds an innittab with all the flags I could think of, but I have not yet gotten autologin working Jul 28 17:27:20 Thanks rburton will do. Jul 28 17:40:00 rburton: (kanavin, or anyone) Did the packaging change as well in pyro? I have a -dev package that has pretty typical links set from its .so's to the related libwhatever.so.x.y.z. After package split though the links are all broken since the .x.y.z is part of the main package. So because of that QA fails because the link is broken (giving me 'file not found'). Jul 28 17:51:53 Is there a way to skip package_qa for specific packages like -dev in Pyro? Jul 28 17:55:16 * armpit more AB builds mean more beer Jul 28 17:57:05 tgoodwin: what do you mean? .so has always been in -dev, and the library has always been in the main package, which is why -dev depends on the main package Jul 28 17:57:30 cross-package symlinks dont' break qa checks unless the packages are missing deps on those packages Jul 28 17:58:50 kergoth: I agree with you (that .so have always been -dev, etc.) which is why this QA failure is surprising me. Jul 28 17:59:36 don't know what to tell you, nothing should ahve changed in this area, and the qa check shouldn't and wont' fail as long as the deps are correct Jul 28 17:59:42 you'd need to give us more info to help diagnose Jul 28 18:00:13 It's causing an exception in the python script, FileNotFoundError, because the link is broken. I imagine this probably has something to do with the developer preferring the library not be installed in /usr/lib (however the link that is broken is relative to its own directory (a.so -> a.so.x.y.z)) Jul 28 18:00:51 the links are always relative to its own directory. and the packaging qa checks shouldn't be following the link anyway. Jul 28 18:01:08 again, you'll need to give more info to diagnose further. the exact error, for example Jul 28 18:06:32 Would you like me to paste it in a private window? It's rather lnog. Jul 28 18:06:33 long* Jul 28 18:07:18 You're right, the QA check, specific line, is trying to read the file in the package. Jul 28 18:07:23 google for 'pastebin' Jul 28 18:17:31 tgoodwin: Yesterday I had posted a question about installing source packages (so I could build them on the target) in an image recipe. I saw you responded, then lost power. Do you know how to do this? Jul 28 18:19:16 hi. i'm having trouble with removing packages from an RDEPENDS variable inside of a recipe. I'm currently "require"ing the original recipe, which is just a package group with lots of RDEPENDS additions, and I'm trying to _remove from this variable and it isn't working Jul 28 18:19:54 additionally, I tried adding to PACKAGE_EXCLUDE in this recipe and that doesn't work either. What else should I try? Jul 28 18:48:24 mawillia: yes, sorry about that. Yes, I need to find my notes on the packages we added to do this on a project since you're basically wanting to install development tools/libraries onto the target as well as your source code. The recipe for your source code is really easy. You just have to make sure do_install installs it from your ${S} to ${D} and that FILES is setup to pick those files up in your package. Jul 28 18:53:41 tgoodwin: if you have an example recipe you could share I would be greatful. Otherwise, I am thinking I would need to write some sort of find script to do the recursive copy, correct? Jul 28 18:55:33 mawillia: I guess I'm not sure what you mean by that (recursive copy). Jul 28 18:59:57 The source has a couple of subdirs. The install command doesn't support recursive (or wildcards, right?) installation, and you need to use the install command vs. copy in the do_install() in order for the files to get picked up correctly, true? Jul 28 19:00:17 no, not true, just install corrects permissions for us Jul 28 19:00:31 if you use cp -a, yoiu'll also want to chown -R root:root, or use the cp arg to not retain ownership Jul 28 19:00:58 * kergoth doesn't recall the exact cp args to do that offhand, but other recipes do it Jul 28 19:02:35 Ah. OK. Thanks, that makes it a bit simpler and I can look around the meta layers for that. Jul 28 19:03:26 use of cp while retaining ownership would end up wih files owned byt he user you're using to do the build, hence the need to not retain that Jul 28 19:03:27 np Jul 28 19:13:52 mawillia: I sent you a message with a recipe example, etc. Jul 28 19:18:56 do i need to register to be heard in this channel or are my questions too stupid? Jul 28 19:20:39 "isn't working" is not helpful Jul 28 19:20:43 we'd need more information Jul 28 19:20:47 exactly what _remove lines are you using? Jul 28 19:20:59 are you using the unexpanded or expanded variable name? Jul 28 19:21:11 i.e. RDPEENDS_${PN}_remove or RDEPENDS_foo_remove Jul 28 19:23:15 kergoth: I have tried both RDEPENDS_${PN}_remove and RDEPENDS_foo_remove to no effect. I can see how _${PN} might not work since it (likely) wouldn't reflect the name of the recipe that the working recipe required Jul 28 19:23:53 you're using bitbake -e to verify the value is what you expect? Jul 28 19:24:00 don't just go by what gets packaged, check bitbake -e Jul 28 19:24:08 particularly since bitbake -e will show the history of the changes to the variable Jul 28 19:24:13 you should see the _remove entry there Jul 28 19:24:25 bitbake -e foo | less and scroll down to ^RDEPENDS_foo Jul 28 19:28:49 kergoth: I tried this earlier and I'm now seeing the same result: no _remove when using the expanded variable name Jul 28 19:31:21 I'm guessing this is something related to requiring a recipe that has unexpanded RDEPENDS_${PN} Jul 28 19:31:53 is there a better way to do what I'd like to do: create a new packagegroup recipe that takes another packagegroup recipe and strips out a few things? Jul 28 19:51:45 kergoth I see you figured out that it was just a test problem Jul 28 19:52:30 yeah, git version inconsistencies in the fetch command when you combine —tags with —mirror. no point explicitly specifying to fetch tags when our refspec includes them anyway, so can just drop it Jul 28 19:53:23 glad it turned out to be simple.. I stared at it blankly.. :) Jul 28 19:55:30 yeah, not exactly a helpful error, and the tests themselves can be a bit messy due to all the different git repos involved. fetch from upstream to a source repo, then let shallow fetch from that source repo to a destination, and in some cases they test the resulting tarball producing the git repo under workdir.. Jul 28 19:55:32 :) Jul 28 20:49:37 binary Jul 28 22:39:54 kergoth: thanks for the patch! Jul 28 22:40:02 np, sorry for the delay **** ENDING LOGGING AT Sat Jul 29 03:00:00 2017