 qt6 migrated
[15:16] <lubot_> [matrix] <tsimonq2> arraybolt3: piuparts failure
[15:16] <lubot_> [matrix] <tsimonq2> Unpacking libfm-qt-common (1.2.1-2+salsaci+20230115+29) ...
[15:16] <lubot_> [matrix] <tsimonq2>   dpkg: error processing archive /var/lib/local-apt-repository/../../..//srv/local-apt-repository/libfm-qt-common_1.2.1-2+salsaci+20230115+29_all.deb (--unpack):
[15:17] <lubot_> [matrix] <tsimonq2>    trying to overwrite '/usr/share/libfm-qt/archivers.list', which is also in package libfm-qt12:amd64 1.2.1-1+b1
[15:17] <lubot_> [matrix] <tsimonq2> 100% something we missed imo :)
[15:17] <lubot_> [matrix] <tsimonq2> @RikMills: now for Qt 5 :P
[17:36] <lubot_> [matrix] <arraybolt3> Not possible. I looked at the actual built archives, the file it's griping about *does not exist* in libfm-qt11, *in the newly built version*. The version that's in the archive, on the other hand, almost certainly *does* include that file.
[17:37] <lubot_> [matrix] <arraybolt3> And look closely at the number. Error processing archive ...libfm-qt-common_**1.2.1-2**+salsaci+20230115+29_all.deb... because of a file that is in package libfm-qt12:amd64 **1.2.1-1**+b1.
[17:37] <lubot_> [matrix] <arraybolt3> And look closely at the version numbers. Error processing archive ...libfm-qt-common\_**1.2.1-2**+salsaci+20230115+29\_all.deb... because of a file that is in package libfm-qt12:amd64 **1.2.1-1**+b1.
[17:47] <tsimonq2> This is simply upgrade testing
[17:48] <tsimonq2> It is testing an existing installation with those packages, and when upgrading to the new version, there are conflicting files
[17:48] <lubot_> [matrix] <arraybolt3> Yes, I know. What I'm saying is that piuparts is grabbing mismatched packages.
[17:48] <tsimonq2> I believe you need a conflict/replaces
[17:48] <lubot_> [matrix] <arraybolt3> ...hmm... ok you might be right there.
[17:48] <lubot_> [matrix] <arraybolt3> I get it. Alright, that makes sense.
[17:49] <lubot_> [matrix] <arraybolt3> lol, the whole point of this was to be able to *remove* conflicts/replaces.
[17:49] <lubot_> [matrix] <arraybolt3> tsimonq2: Does that mean I need a soname bump too?
[17:50] <lubot_> [matrix] <arraybolt3> If so, we might have to drop this in Debian for now, since I think we're past the transition freeze.
[17:51] <lubot_> [matrix] <arraybolt3> Or can I do conflicts/replaces against a version number? I think I can do that, but Lintian yells any time it sees that.
[17:51] <tsimonq2> Here's the thing… if you add a conflict/replaces, you cannot usually drop it until after a stable release of Debian and Ubuntu LTS
[17:52] <tsimonq2> This is because of the upgradability case, the one that is making the test fail
[17:53] <tsimonq2> Also, your MP has Ubuntu suffixes on the versions
[17:53] <tsimonq2> Those versions should be bumped to 0.12
[17:53] <tsimonq2> Honestly, I think that will do the trick
[17:54] <arraybolt3> :faceaplm: ok lemme look
[17:54] <RikMills> looks like muon will be removed soon in debian
[17:55] <arraybolt3> Argh, ok I found the. Thanks for checking that.
[17:57] <tsimonq2> No worries
[17:57] <tsimonq2> Have you ever used piuparts before?
[17:58] <lubot_> [matrix] <arraybolt3> Not hardly :P
[17:58] <lubot_> [matrix] <arraybolt3> I know what it does ish (but evidenly not enough!), I just know that it seems buggy when used with sbuild and so I disabled it.
[17:59] <lubot_> [matrix] <arraybolt3> (It will barf if you're building a package for a distro other than the one you're actively running, it will die on font files for no particular reason when that's probably a bug in some other package, etc. Barely ever works.)
[17:59] <tsimonq2> Yeah, once it works properly it is basically "what will *upgrading* to this package do?"
[18:00] <lubot_> [matrix] <arraybolt3> I thought it was "if I install and then uninstall this, are all the files gone?".
[18:00] <lubot_> [matrix] <arraybolt3> I guess that's part of it but not the whole thing.
[18:01] <tsimonq2> Nope :)
[18:01] <tsimonq2> It does a couple of things but mainly upgrading is what I look for
[18:02] <lubot_> [matrix] <arraybolt3> Hmm. My sbuild was doing the install-purge test I think.
[18:02] <lubot_> [matrix] <arraybolt3> So I should have set it to the install-upgrade-purge test?
[18:03] <tsimonq2> Probably, yeah :)
[18:04] <tsimonq2> See what flags the CI uses maybe 
 pretty sure Debian is past the transition freeze heh (re @lubuntu_bot: (matrix) <arraybolt3> If so, we might have to drop this in Debian for now, since I think we're past the transition freeze.)
[20:01] <arraybolt3> I don't think I'll need to cause a transition after all :)
[21:26] <lubot_> [matrix] <arraybolt3> Building the libfm-qt package and testing with piuparts locally.
[21:28] <lubot_> [matrix] <arraybolt3> HAHAHA my mirrors are going to mess me up now
[21:29] <lubot_> [matrix] <arraybolt3> Y'know what, Salsa CI can manage this. /me pushes to Git
[21:30] <tsimonq2> Niceeee heh
[21:31] <lubot_> [matrix] <arraybolt3> I think I may migrate away from sbuild, though, problems like this are commonplace for me sometimes.
[21:32] <lubot_> [matrix] <arraybolt3> Maybe I just need to know how to use it right, but I know alkisg uses VMs that he uses plain debuild inside, and that kind of sounds easier.
[21:32] <tsimonq2> It may sound easier, but sbuild is what the archive uses, so might as well be consistent, heh
[21:32] <lubot_> [matrix] <arraybolt3> Then I can use piuparts, lintian, and autopkgtest manually and script them just the way I want.
[21:33] <lubot_> [matrix] <arraybolt3> tsimonq2: Maybe my config file is just bad?
[21:33] <tsimonq2> All depends on the exact issues you're facing :)
[21:34] <lubot_> [matrix] <arraybolt3> The last one was when piuparts tried to fetch sid files from an Ubuntu mirror :-/
[21:34] <lubot_> [matrix] <arraybolt3> I guess there's probably a mirror option in piuparts though.
[21:34] <lubot_> [matrix] <arraybolt3> I'll figure it out. I most likely am just using my tool wrong.
[21:35] <tsimonq2> You're close heh
[21:38] <Eickmeyer> There's a quote for the ages with no context.
[21:38] <lubot_> [matrix] <arraybolt3> ?
[21:38] <tsimonq2> facepalm XD
[21:38] <tsimonq2> bad Eickmeyer
[21:39] <Eickmeyer> Indeed Bad Eickmeyer XD
[21:39] <arraybolt3> I'm missing *everything* here :P
[21:40] <Eickmeyer> nvm, you aren't in the gutter.
[21:40] <tsimonq2> +1 stay out of it :P
[21:40]  * arraybolt3 goes back to typing
[22:06] <lubot_> [matrix] <arraybolt3> Simon Quigley: I don't know if I'm misunderstanding something, but with an SRU, isn't the package supposed to migrate 7 days after being in -proposed, regardless of when in those 7 days the fix was marked verification-done?
[22:07] <lubot_> [matrix] <arraybolt3> Or does it wait until 7 days after all verification is finished?
[22:07] <lubot_> [matrix] <arraybolt3> I ask because lubuntu-update-notifier is still in -proposed.
[22:16] <lubot_> [matrix] <arraybolt3> I'm guessing the latter is true.
[22:24] <lubot_> [matrix] <kc2bez> I don't know that the 7day mark is a hard time line.
[22:24] <lubot_> [matrix] <kc2bez> I have seen things slide a little if the appropriate folks are busy.
[22:25] <lubot_> [matrix] <arraybolt3> I could ask the current vanguard, I guess.
[22:26] <lubot_> [matrix] <arraybolt3> I should check update-excuses first though to make sure it's not already moving :P
[22:55] <lubot_> [matrix] <arraybolt3> Simon Quigley: Yes, I did just assign you to that config-file-conflict bug for Focal, and yes, I am taking care of it myself. (Technically it was your code, and your name is on the fix, so I figured that was the right thing to do.)
[23:07] <lubot_> [matrix] <arraybolt3> Eickmeyer: Woohoo, lubuntu-update-notifier is all finished! Let the floodgates open on SDDM!
[23:07] <lubot_> [matrix] <arraybolt3> Thanks for your patience.
[23:08] <lubot_> [matrix] <kc2bez> Thanks for sticking with it @arraybolt3
[23:09] <Eickmeyer> arraybolt3: Thanks!