**** BEGIN LOGGING AT Tue Jan 17 02:59:56 2023 Jan 17 07:54:55 good morning Jan 17 08:17:31 AlexanderKrimm[m, no, we do not consider hostarch == targetarch a special case for running target binaries. If you need to execute a target binary, it always goes through qemu usermode. Jan 17 08:19:07 AlexanderKrimm[m, so your best option is to build for standard x86, and adjust cflags for specific packages, as long as the code they generate will not be executed during the build (so glibc or other core libs are not eligible) Jan 17 08:19:47 Ch^W, no. RP wrote feedback yesterday, and dropped the patch from master-next. Jan 17 08:25:41 kanavin: yeah probably makes a lot of thing simpler not to have that special case especially for openembedded. i'll try to go with the specific package route for now. Jan 17 08:29:09 thanks for the advice and the warm welcome, still a bit overwhelmed by how everything fits together with openembedded, yocto and all the different layers and knobs, but documentation and the community seem to be very nice Jan 17 10:06:04 JaMa: Our customers are struggling with https://bugreports.qt.io/browse/QTQAINFRA-3091. Would you accept a PR in meta-qt5 dunfell to add nobranch=1? Jan 17 10:13:55 frieder: see what I did in jansa/warrior-overrides branch, do all the recipes in the branch you use need nobranch? Jan 17 10:15:01 frieder: maybe your customers could complain in https://bugreports.qt.io/browse/QTQAINFRA-3091? it's still cheaper to restore the branches than fixing all builds Jan 17 10:19:22 JaMa: I haven't tried what recipes need changes. I just get the reports from customers piling up here as they notice that fetching is broken. Jan 17 10:20:01 JaMa: I will definitely complain on the Qt tracker thread and I will try to get others to do so. Jan 17 10:22:37 JaMa: So in jansa/warrior-overrides you tried to avoid setting nobranch=1 globally and do so only for the recipes where it is needed? For other recipes the 5.12 branch is still pointing to 5.12.12? Jan 17 10:23:11 Or maybe I'm misinterpreting this. Jan 17 10:33:22 frieder: 5.12.12 tag was downmerged to 5.12 in most of qt repos, but not in qtbase where 5.12.12 tag isn't in any branch now (used to be in 5.12.12 branch) Jan 17 10:35:08 JaMa: Ah, ok. Jan 17 10:36:37 the issue is that we have a build which still used 5.12.11 (because of "reasons"), so "fixing" it in warrior branch HEAD by global nobranch still won't help, because that build would need to upgrade qt first Jan 17 10:44:51 JaMa: Ok, understood. If there are "reasons" not to upgrade then there's no easy/nice way to fix this except to restore the missing branches upstream. Jan 17 10:48:37 JaMa: Does the issue also exist for versions used in meta-qt5 master? Because I think of switching some BSPs to master anyway. Jan 17 10:54:06 frieder: shouldn't be, because the tags are from 5.15 branch, e.g. qtbase $ git branch -a --contains v5.15.8-lts-lgpl remotes/origin/5.15 Jan 17 10:56:11 JaMa: Ok, thanks for confirming. Jan 17 10:56:16 frieder: but I don't test this very often as @lge we use only 5.12 in some projects and qt6 in others and I don't regularly use meta-qt5 anywhere else nowadays and during the build tests to test new PRs I'm keeping my downloads directory (which still has all the pruned branches) so I wouldn't notice Jan 17 10:56:47 JaMa: Ok, I see. Jan 17 10:58:11 frieder: some more context https://github.com/meta-qt5/meta-qt5/issues/349#issuecomment-691077189 Jan 17 13:50:07 frieder: thanks for trying :) Jan 17 13:50:58 JaMa: :) Jan 17 17:29:54 kanavin: I was thinking a future update to setup-layers could include some robustness checking, like return with a non-zero return code if it cannot leave the layers in the desired state. Jan 17 17:30:32 kanavin: But I did not want to get carried away this time around, plus I know it is still in work so figured it was worth seeing if you had any ideas on how that should happen. Jan 17 19:55:04 Ch^W, on holiday now. would rather not get drawn into long discussions on a subject where five different people have eight different opinions :) Jan 17 19:55:15 but patches welcome, as always :) Jan 17 21:53:18 kanavin: I feel that. Enjoy your holiday! Jan 17 21:57:44 Ch^W: Just to ensure you have the context, this area is probably one of the most difficult areas of development we have Jan 17 21:58:25 Ch^W: there are a lot of different workflows people need to support and for each person, their specific workflow is obviously the correct one and the others often aren't! Jan 17 21:59:01 Ch^W: I have put off working on this for a long time as every time I've tried, it has been a world of pain and I've not been sure it has been the worth the risk of fragmenting the community Jan 17 21:59:25 RP: Agreed. I see tons of Yocto workflow tools out there that focus way too much on policy, and too little on mechanism. Jan 17 21:59:40 This is why I started attacking it from the mechanism side, rather than the policy side. Jan 17 22:00:08 Making mechanisms (like setup-layers) more useful, so it is easier to use local policy. Jan 17 22:02:45 Ch^W, for me it's not so much about convincing existing users to change their workflows, but more about what do we teach and recommend to the newcomers, e.g. via official docs Jan 17 22:03:12 git submodules :) Jan 17 22:03:26 🤮 Jan 17 22:04:01 I spent the afternoon doing work and I know what my state is across several layers :) Jan 17 22:04:10 Crofton, and how would someone set them up, pray tell? Jan 17 22:04:40 I am goign to work on a talk about that Jan 17 22:04:57 also, I might use your work to setup read only builds Jan 17 22:05:02 they just about work when you can clone them from somewhere magical, but there's no way to make a new setup without lots of annoying manual steps Jan 17 22:05:43 I give you permission to insert a disclaimer to your talk that I cannot stand submodules and want to never use them Jan 17 22:06:34 Ch^W: Right, but keep in mind the right thing to do isn't to add every possible mechanism we can to the tools. The patch functionality you talked about for oe-setup-layers is worrying me a bit for example Jan 17 22:07:45 Ch^W: I totally understand why some people want it (and KAS has it for example) but there are other ways people handle it (like a fork/push of the repo somewhere instead of patching). Should we as a project be encouraging local patching of repos? Jan 17 22:08:27 * RP is ignoring Crofton Jan 17 22:09:53 RP: I'd say forking layer repos via piling commits on top is in itself a bad idea. Jan 17 22:10:08 done via custom patches, 2x bad Jan 17 22:10:23 (e.g. custom patching mechanism) Jan 17 22:10:25 kanavin: right, both have pros/cons and people do sometimes need to do it Jan 17 22:10:56 kanavin: I'm mainly trying to give Ch^W an idea of the kinds of things we're going to run into here, there isn't a 100% right or wrong answer Jan 17 22:11:17 RP: Good question, I cannot say for sure. But I probably owe an explanation as to what drove us to take that approach. Jan 17 22:13:02 I have approval to start talking about some of this stuff, so I will see about posting something on OE-core to troll the conversation along. Jan 17 22:13:28 Ch^W: OE does give users lots of choices but every time we do, we potentially double our test matrix and have to document two different workflows and explain to users why they need to chose and how... Jan 17 22:14:16 Ch^W, I don't mean to be pushy, but you could probe your company joining YP as a member Jan 17 22:14:22 Ch^W: just keep in mind this is probably the hardest topic we have :) Jan 17 22:14:44 kanavin: No need to be pushy, I push very hard internally. Jan 17 22:15:01 RP: I can tell, as it was something I had to solve on my own internally. Jan 17 22:15:45 RP: One of the crux issues is that aero has a regulatory burden to rebuild anytime a regulator asks. And this could be 30 years from now. Jan 17 22:17:10 Ch^W: right, that is at least something we try and design to do (reproduce) :) Jan 17 22:18:03 Ch^W, as long as 30 years from now there will be a container technology capable of running the host distro you are building in right now, this should be doable Jan 17 22:18:24 kanavin: I'd love to see buildtools working to the point that is enough! Jan 17 22:18:31 Virtual machines. Jan 17 22:19:03 what kanavin said. We all want to be able to rebuild in the future Jan 17 22:19:32 I originally started work on OE as I couldn't rebuild the images for my Sharp Zaurus :) Jan 17 22:20:16 Even if the container is a pC under a table somewhere :) An early project. I ahd to explain that the PC had to stay for N years incase of a GPL complaince exercise Jan 17 22:21:15 kanavin: I should also add that our host distro is one of our build images. Jan 17 22:21:49 Way-back-when we bootstrapped with Ubuntu, but now we just build VMs OVA appliances directly. Jan 17 22:23:13 All this because a handful of people were annoyed they couldn't build Linux images for Sharp Zaurus' Jan 17 22:23:22 LOL Jan 17 22:23:32 Crazier things have happend for lesser reasons... Jan 17 22:26:15 it was a motley crew https://flic.kr/p/BNUF7 **** ENDING LOGGING AT Wed Jan 18 02:59:56 2023