**** BEGIN LOGGING AT Mon Aug 05 03:02:02 2019 Aug 05 06:49:29 New news from stackoverflow: Embedded Linux distro for Android hardware [closed] Aug 05 09:38:50 Should it not be ok to list symlinks in SRC_URI ? Aug 05 09:39:40 Cause I'm not seeing the dependency change being picked up by bitbake if I change which file the symlink points to Aug 05 09:43:58 kroon: I suspect its a corner case we have no tests for and has never been made to work Aug 05 09:45:10 RP, ok, should Bitbake support it you think ? Aug 05 09:45:32 kroon: It should probably work Aug 05 09:45:57 yeah. I'll see if I can do something about it Aug 05 09:46:15 kroon: it will no doubt result in more complex code which is something I do worry about :( Aug 05 12:17:01 rburton, I made a couple of tweaks to maintainers.inc, do you have any other ideas for better re-assigning? Aug 05 12:17:08 particularly, who else is inactive Aug 05 12:40:58 rburton, remember my issue with backporting epiphany 3.31.4 into poky rocko? I followed your advice to replace the webkit and epiphany recipes with those from master. As a secondary dependency I had to copy recipes-gnome/libdazzle and patch it to request and older version of meson (0.44.1) which seemed to work. Then however, I had to add yet anothe Aug 05 12:40:59 r dependency (recipes-core/glib-2.0) that fails in do_configure due to an unrecognized field in meson_options -- most probably due to the outdated meson version in rocko. That was the point where I resigned. As a plan B I'm now trying to build ephy "offline" using the gnome project's build engine -- which doesn't seem to be trivial either (includin Aug 05 12:40:59 g most of its dependencies), however I don't see another reasonable way to backport epiphany into rocko. Having said that, I'd love to hear any other pointers for solving this admittedly non-standard problem... Aug 05 12:41:35 backport meson? Aug 05 12:43:13 (ephy 3.31.x is a development release so not sure why you'd want that) Aug 05 12:43:37 ok, did not even think of it (as I supposed this, as a devtool being handled differently than "normal" package recipes) Aug 05 12:43:54 if you want to backport a huge component to an older release then you'll just need to backport all of the deps Aug 05 12:44:06 or, don't backport a huge component, and just backport specific fixes Aug 05 12:44:08 or, upgrade Aug 05 12:44:25 yeah, upgrade is not an option Aug 05 12:45:16 backport fixes either as our webUI team is not looking for that specific fix Aug 05 12:46:17 it's just more of a "we need a more recent version" + we need support for automated UI testing (which comes with 3.31.4) Aug 05 12:46:49 are you sure you need a new *ephy* and not just a new webkit? Aug 05 12:47:12 That I don't know.. Aug 05 12:47:34 considering ephy is just the menus and buttons and stuff, its webkit that does the actual rendering. Aug 05 12:48:47 RP, I take back what I said earlier about symlinks in SRC_URI... seems to work fine already, my bad Aug 05 12:50:25 kroon: ok, cool! :) Aug 05 12:51:38 ok, thank you for the background rburton. That might come in handy if I continue to fail backporting everything. I'll check back later... Aug 05 13:42:18 RP: I tried `bitbake -c populate_sdk_ext core-image-minimal` on master-next with hash equivalence enabled and it built successfully.... is there something else I should try? Aug 05 13:44:15 JPEW: oh, sorry, I think I found the problem. It was actually the hashserv code having threading problems Aug 05 13:44:47 RP: Ah good. Out of curosity, does multiprocessing in the hash sever play nicely with `journal_mode = MEMORY`? Aug 05 13:45:13 JPEW: For some reason with threading, the log messages locked things up. Once i moved to multiprocessing it removed the lockup Aug 05 13:45:53 Strange Aug 05 13:46:18 JPEW: seems fine with the journal mode Aug 05 13:46:40 JPEW: There are upstream python issues file with mixing threading, multiprocessing and logging :/ Aug 05 13:48:02 RP: Ya.... as we've discovered the hard way, mixing threads and fork() in general is really problematic Aug 05 13:48:26 In python or any other language Aug 05 13:48:59 I'm trying to "bitbake -k world" but it keeps complaining about multiple versions of swupdate being available. I tried putting "PREFERRED_VERSION_swupdate" in the distro config file, then in the machine config file, still the same issue. Looks like it only works in local.conf, is that expected? Aug 05 13:49:07 JPEW: its down to the way logging has locks which don't play well with fork even from multiprocessing Aug 05 14:24:30 nameclash, this is actually fairly typical that people start development with a fixed yocto version without a version upgrade strategy in place Aug 05 14:26:05 nameclash, then comes along a requirement that can only be satisfied via a yocto upgrade, and it's not possible to do because the organization is totally unprepared Aug 05 14:26:46 yeah this really starts to get painful in the ass... Aug 05 14:27:26 generally I would not even try backporting recipes, because it almost always unravels into a dependency hell Aug 05 14:27:43 that's where I am right now... Aug 05 14:28:06 so why is upgrading yocto not an option? Aug 05 14:28:12 I'm at that a point where the glibc recipes would be next Aug 05 14:29:05 because we're not using vanilla yocto but a commercially maintained spin-off that's based on rocko Aug 05 14:29:52 then ask your commercial maintainer to do it! if you are paying them real money this is exactly the work they should be doing. Aug 05 14:29:55 https://wiki.yoctoproject.org/wiki/Releases <-- ask when they're moving to warrior Aug 05 14:30:26 rocko came out in october 2017 so i hope they're providing security updates Aug 05 14:30:47 my first naive approach was to build yocto from master and then just export ephy+dependencies but that didnt work out because it depends on glibc 2.28 but rocko ships 2.26 ... Aug 05 14:31:39 kanavin: that's complicated.. Aug 05 14:32:43 nameclash: so is backporting glibc/glib/webkit/ephy to a two year old release Aug 05 14:34:00 rburton, how are poky patches handled these days? I sent one recently, and wonder if it has been dropped somehow. Aug 05 14:34:16 (the nativesdk qemu one) Aug 05 14:34:41 I guess you're both right but my gut says that building webkit/ephy from source (separately from yocto) might even be "easier" ... Aug 05 14:35:16 but heck, I'll give it a try and escalate the situation :) Aug 05 14:35:22 let's see what happens Aug 05 14:35:35 kanavin: local.conf.sample: do not add sdl to nativesdk qemu config? Aug 05 14:35:41 rburton, yes Aug 05 14:35:46 ping RP ^ Aug 05 14:36:01 its in mut but i haven't actually fired mut for a while now Aug 05 14:36:22 i should prune it and fire a build, there's a few bits in there that fell through the cracks Aug 05 14:42:14 * jwessel wants to get the wic changes for OSTree merged, but the original version was pretty bad... It created individual partitions of fixed sizes and used the rawcopy method, which is problematic for easily adding extra space. Aug 05 14:43:13 I didn't write the first version... I extended the rootfs wic code to allow you to use a different rootfs for each partition. Aug 05 14:43:46 I am just not sure if that was the right way to do it either, but it is a heck of a lot faster and more flexible. Aug 05 15:10:57 * kergoth yawns Aug 05 15:21:00 New news from stackoverflow: Running Chromium with yocto Aug 05 15:42:22 swupdate_git.bb provides the swupdate-lua package, but swupdate_2018.11.bb (the last release in my version of Yocto) doesn't. This makes it impossible to select PREFERRED_PROVIDER_swupdate = "2018.11" to let "bitbake work" run. Is there a way to exclude a package (not the recipe) from world? Aug 05 15:43:49 that shouldn't be impossible. what exactly is the behavior? Aug 05 15:46:16 I run bitbake -k world, it complains about two versions of swupdate to be built and advise me to select one through PREFERRED_PROVIDER. If I select "git", it works fine, if I select "2018.11" I get the same error Aug 05 15:47:11 No recipes have dependencies on explicit version of swupdate, so I started suspecting a difference between the two versions that could cause that issue Aug 05 15:48:10 so I tweaked the git one to have the same list of packages as the 2018.11 one, and now I can have PREFERRED_PROVIDER_swupdate = "2018.11" Aug 05 15:55:38 sounds like something is depending on swupdate-lua, if that's the only difference Aug 05 15:55:57 one package providing something the other doesn't is only a problem if something is explicitly pulling in the other package, so both recipes end upb eing built Aug 05 15:57:34 okay let me check that Aug 05 15:58:05 rescuegui_git.bb:RDEPENDS_${PN} += "swupdate-tools swupdate-lua" Aug 05 15:58:09 here it is, good catch Aug 05 19:10:23 ELCE announcements came in Aug 05 19:10:52 acceptances? Aug 05 19:11:26 Crofton|work: I got one of each haha Aug 05 19:12:26 congrats! Aug 05 19:12:33 (not sure for which though) Aug 05 19:12:47 Crofton|work: thanks! Aug 05 19:13:06 Crofton|work: lets just say I wont be explaining how the sstate cache works haha Aug 05 19:14:14 but I'd better start researching about those beer places Aug 05 19:14:19 lolz Aug 05 19:15:09 http://www.lafinemousse.fr/ Aug 05 19:15:39 https://www.brewdog.com/bars/global/brewdog-lemarais/ Aug 05 19:16:17 http://www.kerbeer.bzh/ Aug 05 19:16:55 Brewdog is sort of a joke, but they had a good pizza and nice if you need a break from trying to be and good tourist Aug 05 19:20:34 I see youve done your work haha Aug 05 19:26:02 brewdog isn't a joke! Aug 05 19:26:44 * Crofton|work grins Aug 05 19:26:48 i mean stuff like thermo nuclear penguin is 99% PR stunt Aug 05 19:26:54 it is a chain, but I ahve a soft spot for it Aug 06 00:50:56 newbie question, currently the yocto build creates a file /etc/version which has the timestamp of the build image. I want to know where that file gets created? Aug 06 02:23:09 rostam: it's part of the rootfs creation code in meta/lib/oe/rootfs.py (search in that file for BUILDNAME) Aug 06 02:23:41 rostam: is there something you want to change? **** ENDING LOGGING AT Tue Aug 06 02:59:57 2019