 @mitya57 good morning
 how's qt going in debian experimental?
 btw we had a pending talk, so whenever you have some time, please ping me here ;)
 FTR I altered my initial plan, so now it's going to be:
 1. I'm going to tell you a story about cantaloupes (yes, I'm serious) (no, I'm not crazy)
 2. I'm going to do some R&D
 3. I'm going to explain you some technical things
 We could do 1. this weekend if you can (I have the story in a *.txt) but I would like to comment it with you
 The story is just 2 A4 pages so don't worry
 @Santa [how's qt going in debian experimental?], Hi Santa! Qt is mostly ready, I'm fighting with Qt WebEngine build failures, otherwise it's fine.
 that's tough
 @Santa [btw we had a pending talk, so whenever you have some time, please ping me here ; …], I have time now. Maybe you can PM me to avoid spamming this chat? Or you want it to be public?
 I think it's cool to have it publicly available for anyone interested in Qt packaging
 OK
 @mitya57 ↑ here you have it, once you read it I could explain a few things
 So, I guess you want to talk about automation.
 Something more generic actually.
 https://perezmeyer.blogspot.com/2020/08/stepping-down-as-qt-6-maintainers.html
 ↑ what you are saying here - without saying it - is: "we love cantaloupes, but the cost of maintenance in person-hours is so high that we can't handle it"
 Kind of that, right
 Correct, so Martin Luther King said "I have a dream". Well, I don't have a dream I have a guess.
 My guess is that some things you are doing could be changed a little bit, optimizing the cost in person-hours of the things you are doing.
 And I'm also guessing I can help you with that.
 That being said, the first thing I would like to help you with, is the way you handle the qt uploads to ubuntu once the packages are available in Debian.
 If that works, we could try to optimize more things, how does that sound?
 Yes, currently every transition in Ubuntu requires bootstrapping the docs first. If you know how to optimize that, that would be nice!
 That's absolutely fantastic. I'm very glad to hear that.
 Now, indeed, let's talk about automation XD
 Note that automation could be one solution to optimize some things, but for sure it's not something which is going to solve all the problems in the world.
 But I think it's going to work really well for the bootstraping, and I will try to explain why I think that.
 I agree with that, it can be automated with a script that gets packages from Debian, applies necessary modifications, and dput's to given PPA.
 Or do you mean something more smart?
 Something like that, yes.
 Some time ago I linked a video here, and I would like you to watch it again and make some comments about it. Let me find the link...
 https://www.youtube.com/watch?v=jUwlzLZaZ5A
 I remember that video, yes :)
 ok, so let me focus on the first 2 parts
 git-clone-all -r plasma
 and...
 do-all gbp-tritemio
 do you know what they do these commands?
 That's easy to guess 😜
 ok, so gbp-tritemio: what it does?
 Runs git-buildpackage?
 and something else
 before running git-buildpackage it modifies the package version; it adds a "+tritemioX" suffix to the version
 Ok, makes sense
 and it does that ONLY in the package built, it doesn't touch the git local clone repo at all
 Ack
 Let me say some general thing: I'm all for automation, but most difficult (and time consuming) things in Qt packaging (and maybe any packaging) are things that cannot be automated: figuring out why the build failed on some architectures, updating copyright for 3rd party sources where it's not properly documented, rebasing patches and
 of course, not all the problems are the same and therefore the solutions for each one could be different
 so ... going back to the bootstraping thing in ubuntu
 as you can see with the automation we have seen above we have:
 - do-all: to run commands in all git repos
 - gbp-tritemio: to build a modified source package without touching the git repo
 so what would be the solution for the ubuntu bootstraping thing? The way I see it, writing "gbp-qtstage1"
 and this program would alter the package on the fly the same way you are currently doing manually
 Ok. It's just about modifying 3 source packages actually.
 yeah, but you would be able to upload all the stage 1 packages in a row
 It's qtbase, qtdeclarative (with -doc* binaries removed) and qttools (with webkit support removed). Then I wait until it builds and copy packages from Debian. … So yes, it is possible to automate that, but it won't save a lot of time.
 yeah but the whole list of packages of the stage1 is a bit bigger, isn't it?
 qtbase … qtxmlpatterns … qtdeclarative … qtlocation … qtsensors … qtwebsockets … qtwebchannel … qtwebkit
 ↑ is this list correct?
 That's an alternative variant that doesn't involve disabling qtwebkit support in qttools, but I prefer the variant I mentioned because it's just 3 packages.
 that method is not in the qtbase README.source?
 README.source is mostly for people bootstrapping Debian for new architectures, and it allows them to do so without *any* modifications. … Ubuntu is a different thing: unlike Debian, we have all binaries built by amd64 build, that's why we need a different path.
 Right
 Santa that said, your tooling will probably be much more useful when we have to upload Qt to Ubuntu when the packages are not in Debian (like it was with 5.9.8 for Focal). … Because I usually upload all packages with ~ppa1 suffix first.
 ack, I don't understand very well the 3-packages variant bootstraping
 "That's an alternative variant that doesn't involve disabling qtwebkit support in qttools"
 so how do you do that exactly?
 https://launchpadlibrarian.net/365659969/qttools-opensource-src_5.9.5-0ubuntu1~2_5.9.5-0ubuntu1.diff.gz … This is the diff I found on LP. If you reverse it, you will get a package that doesn't depend on qtwebkit.
 aha
 that's interesting. may I suggest you to document this somewhere?
 (if it's not already)
 Ok, will do
 Thanks. You also mentioned the tooling could be interesting to upload new versions of qt when they are not available in debian (like what happened in focal)
 ... so I will think a bit about that
 this way whenever you are done with the qt packages in debian, maybe we could pretend we are going to upload 5.15 to groovy wihout having it available in debian
 This thing happens rarely, but sometimes we want versions older than in Debian. But given that Qt has no more opensource LTS branches, I don't know if that will happen at all.
 ack, we could try anyway
 Ok, so I think I already had enough of qt packagin for this weekend XD
 @mitya57 thank you very much for your time :)
 No problem, thanks to you too!
 Actually I was trying myself to automate some aspects of packaging, e.g. the copyright generator for qtwebengine is the most recent example.
 Yeah, I would like to research a bit more that kind of things too