**** BEGIN LOGGING AT Mon Sep 14 02:59:57 2020 **** BEGIN LOGGING AT Mon Sep 14 03:10:47 2020 **** BEGIN LOGGING AT Mon Sep 14 05:36:57 2020 **** BEGIN LOGGING AT Mon Sep 14 05:39:47 2020 Sep 14 06:42:20 good morning **** BEGIN LOGGING AT Mon Sep 14 09:55:13 2020 **** BEGIN LOGGING AT Mon Sep 14 09:59:59 2020 Sep 14 10:11:45 guys, any hints on how I can overload scripts/wic in my layer? I tried adding it and prepending the corresponding PATH/PYTHONPATH, but it still prefers the wic version from poky somehow Sep 14 10:12:13 I am trying to get JPEWs --offset wic feature to work on dunfell, but I would prefer not to touch/branch the poky submodule Sep 14 11:53:32 Jin^eLD: why would you need to overload? You can make an image recipe use a wic file with a specific custom name. Sep 14 11:54:07 Jin^eLD: I personally could not think of a usecase for that Sep 14 11:54:46 eduardas: I need a wic feature that is on master but not on dunfell Sep 14 11:55:05 the feature is in wic itself, its a parameter that JPEW added recently Sep 14 11:55:53 Jin^eLD: if I really needed that, I'd just rebase my BSP onto master and do my next release images with whatever the next release is going to be Sep 14 11:56:42 eduardas: tried it but master unleashed hell on me Sep 14 11:56:57 varous things did not compile or were broken Sep 14 11:59:50 Jin^eLD: yeah, that happens, but I do practice periodically rebasing on master even though I have my releases based on stable Yocto releases Sep 14 12:00:26 rebasing often means you don't need to fix much in your layers in one go Sep 14 12:00:58 in one conference video a Dell EMC person said they do that every two weeks or so Sep 14 12:01:10 if I remember correctly Sep 14 12:01:49 well, the problem I had was not due to me having so many changes - basic packages not modified by me were not compiling on master **** BEGIN LOGGING AT Mon Sep 14 12:51:40 2020 **** BEGIN LOGGING AT Mon Sep 14 13:05:47 2020 **** BEGIN LOGGING AT Mon Sep 14 16:56:54 2020 **** BEGIN LOGGING AT Mon Sep 14 17:45:37 2020 **** BEGIN LOGGING AT Mon Sep 14 20:30:32 2020 **** BEGIN LOGGING AT Mon Sep 14 20:57:21 2020 Sep 14 21:22:11 I'm hearing there are fetch fails with pyqt5, sounds like we need to add some stuff to a mirror Sep 14 21:54:12 Crofton|cloud: or hope that there will be an actual release soon instead of those snapshots Sep 14 21:54:33 Crofton|cloud: not sure what happened with the world builds populating the mirror on source.oe.org :/ Sep 14 21:54:47 urg Are we using snapshots? Sep 14 21:55:04 Ok sounds like we have some detective work to do Sep 14 22:00:17 JaMa: this should work? http://source.openembedded.org/ Sep 14 22:01:06 http://sources.openembedded.org/ Sep 14 22:01:09 is alive **** BEGIN LOGGING AT Mon Sep 14 23:12:46 2020 Sep 15 00:06:05 Crofton|cloud: yes http://sources.openembedded.org/ was alive and updated from world build when I used to run them Sep 15 00:06:39 Crofton|cloud: and yes, pyqt5 are snapshots, last updated today with https://github.com/meta-qt5/meta-qt5/pull/357 Sep 15 00:08:33 we're on various 5.15.1 snapshots since https://github.com/meta-qt5/meta-qt5/commit/1650757f4182435a63985f73e477ed80927f0eac Sep 15 00:09:12 but we should be able to upgrade to 5.15.1 from 12th https://www.riverbankcomputing.com/news/PyQt_v5.15.1_Released Sep 15 00:42:43 source mirror is out of date but regardless this wont help I do not build meta-qt5 in world builds anymore for timing reasons Sep 15 00:42:51 perhaps I will re-introduce slowly Sep 15 00:43:37 maybe just blacklist qtwebengine/qtwebkit and that wont hurt build times **** BEGIN LOGGING AT Tue Sep 15 01:43:13 2020 **** BEGIN LOGGING AT Tue Sep 15 02:01:11 2020 **** ENDING LOGGING AT Tue Sep 15 02:59:57 2020