| *** sakoman <sakoman!~steve@dhcp-72-253-5-74.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 00:55 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-132-199.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 01:00 | |
| *** brrm <brrm!~brrm@ip-085-216-021-034.um25.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds) | 01:03 | |
| *** brrm <brrm!~brrm@ip-085-216-021-034.um25.pools.vodafone-ip.de> has joined #oe | 01:04 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 01:52 | |
| *** yocti <yocti!~limnoria@mail.yoctoproject.org> has joined #oe | 04:39 | |
| *** dustinm` <dustinm`!~dustinm@static.38.6.217.95.clients.your-server.de> has quit IRC (Quit: Leaving) | 06:45 | |
| *** dustinm` <dustinm`!~dustinm@static.38.6.217.95.clients.your-server.de> has joined #oe | 06:50 | |
| *** mckoan|away is now known as mckoan | 07:54 | |
| mckoan | good morning | 07:54 |
|---|---|---|
| *** frieder <frieder!~frieder@200116b824bf6f810000000000001cba.dip.versatel-1u1.de> has joined #oe | 08:00 | |
| kanavin | 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. | 08:17 |
| kanavin | 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) | 08:19 |
| kanavin | Ch^W, no. RP wrote feedback yesterday, and dropped the patch from master-next. | 08:19 |
| AlexanderKrimm[m | 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. | 08:25 |
| AlexanderKrimm[m | 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 | 08:29 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 10:01 | |
| frieder | 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? | 10:06 |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 10:11 | |
| JaMa | frieder: see what I did in jansa/warrior-overrides branch, do all the recipes in the branch you use need nobranch? | 10:13 |
| JaMa | 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 | 10:15 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe | 10:19 | |
| frieder | 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. | 10:19 |
| frieder | JaMa: I will definitely complain on the Qt tracker thread and I will try to get others to do so. | 10:20 |
| *** florian_kc is now known as florian | 10:22 | |
| frieder | 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? | 10:22 |
| frieder | Or maybe I'm misinterpreting this. | 10:23 |
| JaMa | 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) | 10:33 |
| frieder | JaMa: Ah, ok. | 10:35 |
| JaMa | 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 | 10:36 |
| frieder | 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. | 10:44 |
| frieder | JaMa: Does the issue also exist for versions used in meta-qt5 master? Because I think of switching some BSPs to master anyway. | 10:48 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d> has joined #oe | 10:52 | |
| JaMa | 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 | 10:54 |
| frieder | JaMa: Ok, thanks for confirming. | 10:56 |
| JaMa | 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 | 10:56 |
| frieder | JaMa: Ok, I see. | 10:56 |
| JaMa | frieder: some more context https://github.com/meta-qt5/meta-qt5/issues/349#issuecomment-691077189 | 10:58 |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds) | 13:04 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 13:17 | |
| *** otavio <otavio!~otavio@191-221-68-67.user3p.brasiltelecom.net.br> has quit IRC (Quit: leaving) | 13:20 | |
| *** otavio <otavio!~otavio@191-221-68-67.user3p.brasiltelecom.net.br> has joined #oe | 13:21 | |
| JaMa | frieder: thanks for trying :) | 13:50 |
| frieder | JaMa: :) | 13:50 |
| *** sakoman <sakoman!~steve@dhcp-72-253-5-74.hawaiiantel.net> has joined #oe | 13:55 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has quit IRC (Quit: Ping timeout (120 seconds)) | 14:01 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has joined #oe | 14:01 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds) | 14:01 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 14:02 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has joined #oe | 14:30 | |
| *** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** mckoan is now known as mckoan|away | 17:21 | |
| Ch^W | 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. | 17:29 |
| *** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has joined #oe | 17:30 | |
| Ch^W | 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. | 17:30 |
| *** frieder <frieder!~frieder@200116b824bf6f810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 17:40 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 18:11 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 18:15 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has quit IRC (Read error: Connection reset by peer) | 19:27 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has joined #oe | 19:30 | |
| *** florian__ <florian__!~florian@dynamic-078-049-018-005.78.49.pool.telefonica.de> has joined #oe | 19:34 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has quit IRC (Read error: Connection reset by peer) | 19:49 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has joined #oe | 19:50 | |
| kanavin | Ch^W, on holiday now. would rather not get drawn into long discussions on a subject where five different people have eight different opinions :) | 19:55 |
| kanavin | but patches welcome, as always :) | 19:55 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:08 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Ping timeout: 252 seconds) | 21:20 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-5-74.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 21:27 | |
| *** sgw <sgw!~swold_loc@user/sgw> has joined #oe | 21:34 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-5-74.hawaiiantel.net> has joined #oe | 21:35 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has quit IRC (Quit: byebye.) | 21:38 | |
| Ch^W | kanavin: I feel that. Enjoy your holiday! | 21:53 |
| RP | Ch^W: Just to ensure you have the context, this area is probably one of the most difficult areas of development we have | 21:57 |
| RP | 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! | 21:58 |
| RP | 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 | 21:59 |
| Ch^W | RP: Agreed. I see tons of Yocto workflow tools out there that focus way too much on policy, and too little on mechanism. | 21:59 |
| Ch^W | This is why I started attacking it from the mechanism side, rather than the policy side. | 21:59 |
| Ch^W | Making mechanisms (like setup-layers) more useful, so it is easier to use local policy. | 22:00 |
| kanavin | 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 | 22:02 |
| Crofton | git submodules :) | 22:03 |
| Ch^W | 🤮 | 22:03 |
| Crofton | I spent the afternoon doing work and I know what my state is across several layers :) | 22:04 |
| kanavin | Crofton, and how would someone set them up, pray tell? | 22:04 |
| Crofton | I am goign to work on a talk about that | 22:04 |
| Crofton | also, I might use your work to setup read only builds | 22:04 |
| kanavin | 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 | 22:05 |
| kanavin | I give you permission to insert a disclaimer to your talk that I cannot stand submodules and want to never use them | 22:05 |
| RP | 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 | 22:06 |
| RP | 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? | 22:07 |
| * RP is ignoring Crofton | 22:08 | |
| kanavin | RP: I'd say forking layer repos via piling commits on top is in itself a bad idea. | 22:09 |
| kanavin | done via custom patches, 2x bad | 22:10 |
| kanavin | (e.g. custom patching mechanism) | 22:10 |
| RP | kanavin: right, both have pros/cons and people do sometimes need to do it | 22:10 |
| RP | 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 | 22:10 |
| Ch^W | RP: Good question, I cannot say for sure. But I probably owe an explanation as to what drove us to take that approach. | 22:11 |
| Ch^W | 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. | 22:13 |
| RP | 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... | 22:13 |
| kanavin | Ch^W, I don't mean to be pushy, but you could probe your company joining YP as a member | 22:14 |
| RP | Ch^W: just keep in mind this is probably the hardest topic we have :) | 22:14 |
| Ch^W | kanavin: No need to be pushy, I push very hard internally. | 22:14 |
| Ch^W | RP: I can tell, as it was something I had to solve on my own internally. | 22:15 |
| Ch^W | 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. | 22:15 |
| RP | Ch^W: right, that is at least something we try and design to do (reproduce) :) | 22:17 |
| kanavin | 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 | 22:18 |
| RP | kanavin: I'd love to see buildtools working to the point that is enough! | 22:18 |
| Ch^W | Virtual machines. | 22:18 |
| Crofton | what kanavin said. We all want to be able to rebuild in the future | 22:19 |
| RP | I originally started work on OE as I couldn't rebuild the images for my Sharp Zaurus :) | 22:19 |
| Crofton | 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 | 22:20 |
| Ch^W | kanavin: I should also add that our host distro is one of our build images. | 22:21 |
| Ch^W | Way-back-when we bootstrapped with Ubuntu, but now we just build VMs OVA appliances directly. | 22:21 |
| Crofton | All this because a handful of people were annoyed they couldn't build Linux images for Sharp Zaurus' | 22:23 |
| Ch^W | LOL | 22:23 |
| Ch^W | Crazier things have happend for lesser reasons... | 22:23 |
| Crofton | it was a motley crew https://flic.kr/p/BNUF7 | 22:26 |
| *** azcraft <azcraft!~AzCraft@195.214.250.162> has joined #oe | 22:40 | |
| *** florian__ <florian__!~florian@dynamic-078-049-018-005.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds) | 23:33 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 23:38 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Quit: Leaving.) | 23:40 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!