**** BEGIN LOGGING AT Tue Jun 27 03:00:08 2017 Jun 27 06:38:49 Hello! I just built a firmware using the pyro branch. After I boot the system I get https://pastebin.com/5hDa5kf9 and I can’t log into ssh. Any idea why this happens in pyro and not in morty? Jun 27 07:07:55 zero_note: Do you have something like gcc_multilib installed? Jun 27 07:34:45 morning Jun 27 07:35:35 I have an issue when upgrading from fido to pyro regarding the shadow package, complaining that it can't be configured offline and rootfs is read-only Jun 27 07:36:05 the log file says: "pwconv: cannot lock /etc/passwd; try again later." Jun 27 07:40:04 it seems shadow is a required package by qt5, yet I need to have read-only file system. Has this happened to someone else? Jun 27 07:42:35 Hi! Quick Q on Yocto/OE 2.1. I'm trying to figure out whether it's possible to prepare kernel's shared_workdir without compiling the kernel itself. The case I'm currently fighting with is that the kernel is rebuilt from scratch every single time I use a new build/tmp directory although I assume everything should be taken out from sstate cache... Any hints? Jun 27 08:51:01 is it possible to use host toolchain for x86_64 target? I've added ASSUME_PROVIDED for binutils & gcc but the build fails with "Runtime target 'diffstat-native' is unbuildable" Jun 27 08:58:07 nvm. I overwrote ASSUME_PROVIDED from poky Jun 27 09:43:24 sobczyk: Possible maybe but I think you're going to run into a few issues Jun 27 09:48:58 RP: yeah, I just realized that a few files would need to be copied from host filesystem to rootfs Jun 27 09:50:55 because I've made praviously similar thing with crosstoolng toolchain Jun 27 10:38:03 pohly: is https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1191/steps/Running%20Sanity%20Tests/logs/stdio your fault? Jun 27 10:43:42 rburton: yes, could be. Apparently kill qemu did not work, so self.process.poll() return None. Jun 27 10:44:52 Hmm, I'm not sure whether it worked before either. Jun 27 10:45:08 I noticed that killing processes did not work when using a shell. Jun 27 10:45:14 it didn't error like that before Jun 27 10:45:30 rburton: let me check... Jun 27 10:45:47 rburton: in this case, isn't the real problem that the machine doesn't boot? Jun 27 10:46:01 "Target didn't reached login boot in 1500 seconds" Jun 27 10:46:09 yes but i think the traceback is new Jun 27 10:46:24 rburton: yes, that might be true. I'll have a look. Jun 27 10:46:29 like https://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/1127/steps/Running%20Sanity%20Tests/logs/stdio without your patch Jun 27 10:51:34 rburton: got it. communicate() is guaranteed to wait for command completion, whereas my revised code merely waited for the pipes to be closed. So I introduced a race condition. Jun 27 10:51:39 Fix coming... Jun 27 10:51:42 thanks Jun 27 11:02:52 rburton: how sad that even writing unit tests didn't catch this race condition ;-/ Jun 27 11:03:18 no test suite survives reality :) Jun 27 11:04:21 Speaking of the tests, is it necessary to enable them in the AB setup? Jun 27 11:04:27 The new ones, I mean. Jun 27 11:04:59 implemented right they'll just work Jun 27 12:23:30 Hi there, I have a recipe which build one application and some so libs, which indeed I'm trying to install into final filesystem. On single package bitbaking all seems ok and in WORKDIR/package I can found every files correctly installed, but during the do_rootfs task I'm stuck with an error related to this recipe Jun 27 12:24:34 the package cannot be installed because nothing provides...one of the libraries built by the package (== recipe) itself Jun 27 12:25:24 no matter how many PROVIDES and RPROVIDES combinations I try Jun 27 12:26:04 any ideas? thanks in advance Jun 27 12:29:45 (additional info: this happen with yocto 2.2.1, the same recipe used in yocto 1.8 gave no problems) Jun 27 12:42:21 zero_note: can you share the recipe somewhere? Jun 27 12:46:59 jku: sure, in 5 minutes Jun 27 12:49:18 jku: here it is https://pastebin.com/AuYfvvVv Jun 27 12:52:28 zero_note: and what's the error? Jun 27 12:53:32 jku: during do_rootfs task: Computing transaction...error: Can't install mDNSResponder-625.41.2-r1@cortexa9hf_neon: no package provides libdns_sd.so Jun 27 12:58:19 talking about differences between different yocto versions (1.8 and 2.2.1), I've found that in WORKDIR/pkgdata/runtime/PN of morty config I have more dependencies listed than in fido config Jun 27 12:58:29 hmm, I guess this happens because the library is in the same package as a binary that uses it? Did you try this already http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/commit/recipes-connectivity/mdns/mdns_544.bb?id=2aedd7ac63872595f71cf4a963e4c55a945c4bc4 Jun 27 12:59:16 jku: I think you're right, but I guess that should be lots of similar recipes around... Jun 27 13:00:15 jku: unfortunately I've already tried it Jun 27 13:00:29 zero_note: not really, most split to "libabc" and "libabc-bin" or similar packages Jun 27 13:01:57 jku: uhmm ok, maybe could be a good idea a complete recipe rewrite from scratch Jun 27 13:03:29 jku: right now the only way I've found its a bit tricky, consist of a sed 's/libdns_sd.so //g' -i ${WORKDIR}/pkgdata/runtime/${PN} executed in do_packagedata_append() Jun 27 13:04:34 ( s/its/is/g ) Jun 27 13:05:02 kanavin: ^ do you have better knowledge on this "no package provides libdns_sd.so" issue Jun 27 13:09:56 (note that it's 2.2 so not dnf) Jun 27 13:12:58 jku: I do not as it is a smartpm issue :-/ Jun 27 13:13:16 ah ok Jun 27 13:50:32 kanavin: is smartpm related to do_rootfs stuff? Jun 27 13:58:19 (also related to my "porting" of recipes from fido to morty): none of my systemd services is enabled in the final rootfs (sadly even here recipes worked perfectly in fido), there is some kind of log that I could read to understand whats going on with systemd.bbclass ? Jun 27 14:11:49 nevermind, I'll use bb.debug in systemd.bbclass Jun 27 15:55:38 rburton: you around? Jun 27 15:57:33 lamego: aye Jun 27 15:59:20 Hi Ross. I'd appreciate your input on this: in order to update python-git recipe to latest version, two RDEPENDS must be added, "git" and "python-git". I'm not sure if the recipe is the best place to add "git" Jun 27 15:59:58 python-git should be depending on git already becasuse it needs to invoke the git binary Jun 27 16:00:06 rburton: "git"needs to be added due to a current issue in python-git upstream: https://github.com/gitpython-developers/GitPython/issues/637 Jun 27 16:00:57 rburton: without explicitly adding it at the recipe, the build fails Jun 27 16:01:11 oh you mean DEPENDS, not RDEPENDS? Jun 27 16:02:03 rburton: I added as RDEPENDS, should it be DEPENDS? Jun 27 16:02:24 DEPENDS = build dependency, RDEPENDS = runtime dependency Jun 27 16:03:05 rburton: correct, the error happens at runtime, while trying to import git module Jun 27 16:03:15 right, RDEPENDS Jun 27 16:04:25 rburton: so the recipe is the appropriate place for that. correct? Jun 27 16:05:19 rburton: and most likely we'll have to revert it when the issue gets solved at upstream. Jun 27 16:05:53 lamego: the recipe is the right place for a dependency that the package needs. if this actually what the problem is though? Jun 27 16:07:51 rburton: the problem is that git module cannot be imported to python2 because git command is not found at the target system (runtime) Jun 27 16:08:22 so yes rdepends is exactly what is required Jun 27 16:09:10 rburton: cool, I wanted to be sure. Thanks for the help. Jun 27 16:09:43 rburton: Sorry for the ping on the archiver patch, I didn't see it was in your contrib tree Jun 27 16:23:27 okay, i need to finally submit this little patch to image.bbclass to make it use appendvarflag instead of setvarflag on prefuncs/postfuncs for the do_Image_ functions, this is the second time i've been bitten by it Jun 27 16:23:30 hmm Jun 27 16:33:29 huzzah, reworked swupdate compound image generation to work as an image type, no need to create separate recipes for every image anymore Jun 27 17:48:29 grr, the fact that conversion commands are just dropped in rather than being their own tasks is causing me some real headaches Jun 27 19:49:58 RP: what is holding mesa merge? Jun 27 19:54:46 otavio: we can't get clean builds, too many bad patches :( Jun 27 20:23:13 RP: but is it causing failures? Jun 27 20:23:28 RP: or it is just on the pile? Jun 27 20:25:59 otavio: the pile Jun 27 20:30:56 RP: is there something berton or me can take a look? we might help Jun 27 21:15:55 otavio: roughly speaking, morty-next has issues with arm64 and mips that I think we need armin's input on as I don't know where they're at. Ross is running new mut/mut2 builds and we'd need him to know where those are at too Jun 27 21:16:12 otavio: I was at least able to get krogoth to build Jun 27 21:16:29 otavio: pyro status is also unknown, I can't help feel we're missing patches Jun 27 21:20:47 Dear All, Jun 27 21:21:11 Does it often happen that yocto is working on one distro (e.g. Fedora), but not on e.g. Debian? Jun 27 21:21:27 Both distros are "recommended" one for YP 2.3 Jun 27 21:55:12 Does it document somewhere what the staging branches are for each release? **** ENDING LOGGING AT Wed Jun 28 03:00:04 2017