**** BEGIN LOGGING AT Wed Jun 26 02:59:57 2019 Jun 26 06:42:01 good morning Jun 26 09:04:53 hi everyone, quick question, what's the meaning of solid vs dashed lines in `bitbake -g` Jun 26 09:05:05 (i assume build time vs runtime dependency, but which one is which?) Jun 26 10:04:55 milloni: that must be a really old version of bitbake Jun 26 10:05:18 RP: oh? Jun 26 10:05:20 it is Jun 26 10:06:15 milloni: modern code doesn't do that Jun 26 10:06:31 doesnt do what? Jun 26 10:06:41 milloni: show different kinds of lines Jun 26 10:06:41 doesnt create dependency graphs? Jun 26 10:06:44 okay Jun 26 10:06:58 do you happen to know which one was which in the old one? Jun 26 10:07:38 milloni: one is runtime, one is build time but I don't remember which is which. I should be fairly obvious Jun 26 10:07:52 milloni: we removed that and changed the code as that dependency view had bugs Jun 26 10:08:02 oh? Jun 26 10:08:37 i'm investigating a problem where something that i think should be a build dependency is installed into the image Jun 26 10:08:50 i.e flex is a build dependency of nfs but not runtime Jun 26 10:08:56 the graph confirms so Jun 26 10:09:21 you'd be better off looking for a package which depends on flex being installed in the image Jun 26 10:09:33 that is a package manager level problem Jun 26 10:10:20 yeah - we've confirmed that removing nfs removes flex as well Jun 26 10:10:39 there's just no runtime dependency on flex in the graph Jun 26 10:10:47 according to the graph nothing runtime depends on it Jun 26 10:11:08 unless it's a bug in the graph Jun 26 10:13:24 milloni: that graph only lists some dependencies, there may be others created at build time once for example shlibs dependencies are known Jun 26 10:13:32 milloni: as I said, you really want to look at the packages Jun 26 10:13:38 okay thanks Jun 26 10:28:32 RP: according to /opkg/info/unfs3.control this package Depends: flex (>= 2.6.0) Jun 26 10:28:41 the recipe comes from poky Jun 26 10:29:11 is this a bug in poky? surely it doesn't need flex as a runtime dependency? also, interestingly i ran bitbake -e unfs3 Jun 26 10:29:31 RDEPENDS seems to be empty (these are the runtime dependencies i suppose?) Jun 26 10:41:42 milloni: runtime deps suggest that unfs3 uses libfl, so yes, it needs flex Jun 26 10:41:48 patches welcome to split flex into a library and a binary Jun 26 10:41:52 (packaging) Jun 26 10:42:13 DEBUG: unfs3: Dependency libfl.so.2 requires package flex-libfl (used by files: /data/poky-tmp/master/work/corei7-64-poky-linux/unfs3/0.9.22.r497-r0/packages-split/unfs3/usr/sbin/unfsd) Jun 26 10:42:39 its split already, so that's sorted then :) Jun 26 10:42:55 rburton: out of interest how did you find that info? (so that next time i can do it myself) Jun 26 10:43:02 do_package log for unfs3 Jun 26 10:43:08 oh Jun 26 11:07:05 Hi, I was compiling chromium via yocto (took some time and patches :)), the last part of the do_compile i did in the devshell. Now I'd like to run do_install, however it restarts the compilation instead. How do I tell yocto that I actually already finished do_compile manually? Jun 26 11:12:59 raem: creating the appropriate stamp file? Jun 26 11:40:11 raem: obviously that's not a sustainable way to build chromium either Jun 26 11:40:53 raem: did https://layers.openembedded.org/layerindex/branch/master/layer/meta-browser/ not work Jun 26 12:23:56 Hi, question about 2.8 release process: when is it planned to create a new branch and freeze major SW versions? Jun 26 12:28:07 Hmm, is https://layers.openembedded.org/rrs/recipes/OE-Core/2.8/M2/ containing the current M2 state of upstream version checks? Jun 26 12:41:29 I'm using yocto + poky (branch thud) and I'd like to update the cmake to another version without switching to the warrior branch. I've copied the cmake version (3.14) recipe that I need and I'm adding it to my repo. How can I tell to yocto uses my cmake instead of the poky one? Jun 26 12:42:04 ricardocrudo: In your conf file, you can use PREFERRED_VERSION, I believe. Jun 26 12:42:22 https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-PREFERRED_VERSION Jun 26 12:43:24 ("in your conf file" I'm meaning local.conf, for example. Jun 26 12:45:46 RP: I filed a bug for the adding users to groups created elsewhere issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 Jun 26 12:45:47 Bug 13419: normal, Undecided, ---, richard.purdie, NEW , recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens) Jun 26 12:46:00 RP: hope I captured it well, please add if needed Jun 26 12:46:33 tgoodwin that sounds great. I'll give it a try. thanks Jun 26 12:47:10 rburton: Hi, I just sent 2 patches for cve-update-db in oe-core. One concerns the proxy and I just saw (too late) the ' build on CVE is failing' discussion on yocto mailing list. I hope it won't interfere with Vignesh patch. Jun 26 12:47:21 woot Jun 26 12:47:38 you're welcome. :) Jun 26 12:47:52 lemagoup: patchtest says you need to rebase to master Jun 26 12:50:28 rburton: Sorry I was on master-next, I'll send a v2 Jun 26 12:50:42 lemagoup: in that case thats probably fine Jun 26 12:54:21 rburton: ok Jun 26 13:40:06 RP: creating a stampfile would probably do the trick, how does that exactly work (or where do i find infos for this). I basically just want to tell bitbake that do_compile is done already Jun 26 13:41:11 raem: look in STAMPS and create something similar to the other files. This isn't documented as its not something we recommend at all. You'd usually fix the do_compile to work Jun 26 13:41:44 raem: the stamp files in STAMPS are what bitbake looks at to decide if something has executed Jun 26 13:41:46 rburton: chromium-ozone-wayland on armv7 is a bit of a nightmare if you want a recent chromium version. i'll open some issues there once it is working, but no it did not work out of the box Jun 26 13:42:45 RP: i'll have a look. obviously i will redo it properly once i have another 5h to compile :) but until then i'd like to try to install it first Jun 26 13:50:00 New news from stackoverflow: Is there a restriction on recipe/package names in Yocto? Jun 26 13:56:30 RP: I just ranted at someone here who asked when the useradd issue is expected to be fixed upstream. Basically said that you are badly overloaded, and we need to work on our reputation first by contributing to Yocto. Jun 26 14:01:26 kanavin: indeed, we don't just magically fix all bugs :/ Jun 26 14:02:36 RP: Magically fixed bugs sounds nice... Let's work on that! Jun 26 14:03:28 darknighte: put it on the list along with making bitbake psychic ;-) Jun 26 14:04:22 oooooh, that sounds great. Add that one too. don't forget to walk on water while you're at it... ;) Jun 26 14:10:04 darknighte: you mean bug 13210 ? Jun 26 14:10:05 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13210 major, Medium, Future, ross.burton, RESOLVED WONTFIX, Bitbake is not psychic Jun 26 14:22:00 rburton: the last debian selftest needs filing as a bug, its a race in file copying with python cache files :( Jun 26 15:13:00 RP: on it Jun 26 15:33:12 rburton: thanks Jun 26 18:40:45 has anyone ever seen someone license a bbappend? can it be different than the base recipe? Jun 26 18:53:27 radsquirrel: what do you mean? If you're referring to LICENSE, that isn't the license of the recipe file or the append, but the licesen of the sources involved Jun 26 18:54:31 if you're referring to a copyright/license header comment or repo wide license of the metadata itself, it'd likely depend on the licenses involved, as the bbappend would be a derived work. that said, recipe content is generally too trivial for a copyright to have much meaning, most repositories just pick MIT just to make it explicit Jun 26 18:55:17 kergoth: sorry - I'm referring to the license of the metadata itself Jun 26 18:55:28 not the code pointed to by the metadata Jun 26 18:56:24 if the metadata license of the recipe was GPL, you couldn't very well declare the license of hte bbappend as something gpl-incompatible, i'd imagine. otherwise it's probably fine.. comes down to license compatibility wrt derived works, but IANAL Jun 26 18:58:47 its MIT (base) -> bsd3 (append) Jun 26 18:58:56 kergoth awesome, thanks! Jun 26 18:59:38 it's probably no different than trying to include a bsd3 component in an MIT codebase. not sure as to the implications there about the license of the metadata as a whole, but probably doesn't matter, really Jun 26 18:59:59 i can't imagine anyone will fight you over a couple of shell commands in a do_compile or something :) Jun 26 19:00:03 not much IP there Jun 26 19:01:32 right. it isn't even that...its just the setting of FILESEXTRAPATH :-) Jun 26 19:48:36 RP: regarding the last failing tests for lttng-tools, it is indeed a space problem, we produce a ~501M trace in /tmp (volatile and on base ptest image -> ~495M). Seems to work when using a TMPDIR set to use the actual image disk (Size:2.8G Used: 2.6G). Jun 26 19:49:18 does creating a dit in the ptest directory of the recipe and setting TMPDIR in run-ptest would be okai? Jun 26 19:50:16 psrcode: that sounds fine to me if it works Jun 26 19:50:40 will send you a patch shortly Jun 26 19:50:56 psrcode: great. We're getting there with the ptest results :) **** BEGIN LOGGING AT Wed Jun 26 20:04:53 2019 **** ENDING LOGGING AT Thu Jun 27 02:59:57 2019