[10:13] <kstenerud> Can someone help me out with questions about debian/control? I have a package that breaks itself and replaces itself, but I can't find info in https://www.debian.org/doc/debian-policy/ch-relationships.html that explains what this is for (every mention of it says "see below", but never actually explains)
[10:14] <cjwatson> kstenerud: Can you pastebin the whole debian/control?
[10:15] <Faux> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages ?
[10:15] <cjwatson> kstenerud: I believe that the "see below" is simply a reference to the definition of Provides
[10:15] <kstenerud> http://paste.ubuntu.com/p/DR7g5HsyRx/
[10:16] <cjwatson> kstenerud: I don't see any self-Breaks/Replaces there
[10:16] <cjwatson> kstenerud: Two packages have Breaks/Replaces on similar but distinct package names (extra ".0")
[10:17] <kstenerud> OK, I'm not sure I follow. Why would there be all these different package names?
[10:17] <cjwatson> kstenerud: It looks like just a package rename
[10:18] <kstenerud> Basically: If I can remove the Breaks delta, that removes the remaining delta on the tomcat8 package, so I want to know if I can safely remove the delta and turn this into a sync
[10:18] <cjwatson> kstenerud: That is, at some point the maintainer felt it best to rename libtomcat8.0-java to libtomcat8-java and tomcat8.0-user to tomcat8-user, and the Breaks/Replaces would be to make the upgrade proceed smoothly
[10:18] <rbasak> kstenerud: remember I said it was likely to need to remain until after the next LTS?
[10:19] <rbasak> kstenerud: if you can figure out when the rename took place, that'll tell us when it can be removed.
[10:19] <cjwatson> The history is in https://bugs.launchpad.net/ubuntu/+source/tomcat8.0/+bug/1717998
[10:19] <cjwatson> So you can see there that those binaries were in cosmic, so removing that delta has to wait until after 20.04
[10:20] <kstenerud> ok
[10:24] <cjwatson> (because otherwise, somebody who's upgrading through a supported upgrade path may find that they have the old package name installed, apt schedules the replacement package for installation, and then dpkg would throw an error when trying to unpack the replacement package because it ships files from another package without an appropriate Replaces)
[11:40] <rbasak> If backporting 0.23.0-1 from Bionic to Xenial, what would be the best version number string to use? I don't see a standard documented anywhere; what's the de-facto standard? 0.23.0-1~16.04.1 perhaps? Or an "ubuntu" in there somewhere?
[11:41] <rbasak> For 0.22.2-1ubuntu0.1 I was going to use 0.22.2-1ubuntu0.1~16.04.1 - is that sensible?
[11:41] <rbasak> (this is the certbot backport that will be SRU'd)
[11:45] <cjwatson> rbasak: The de-facto standard is whatever backportpackage(1) does
[11:46] <cjwatson> which I think would be ~ubuntu16.04.1
[11:46] <cjwatson> (yes, this does result in duplicate "ubuntu" sometimes)
[11:46] <rbasak> Ah, I didn't think to look there. Thanks!
[11:47]  * rbasak likes standards
[11:47] <Skuggen> Good thing there are so many of them, then :)
[11:47] <rbasak> :)
[11:47]  * rbasak will try to avoid creating another one
[14:35] <seb128> jbicha, just curious but why libnotify did a "no change upload for autopkgtest"?
[14:36] <jbicha> seb128: Locutus thought that maybe virtualbox/i386 wouldn't be triggered (see #ubuntu-release ) but it didn't work
[14:36] <seb128> k
[14:36] <jbicha> sorry but the explanation felt too wordy for debian/changelog
[14:39] <seb128> it's just the first time I see a no change upload for autopkgtests, usually those can be retried/hinted without needing uploads
[14:44] <LocutusOfBorg> seb128, I thought a new upload wouldn't trigger that i386 autopkgtest, and looks like I was wrong
[14:44] <LocutusOfBorg> probably kernel didn't trigger it because it is built only on amd64...
[14:45] <Laney> but why do that in the archive?
[14:46] <LocutusOfBorg> Laney, how could we do it otherwise?
[14:46] <LocutusOfBorg> looks like qtbase is not triggering vbox/i386 autopkgtest for virtualbox/6.0.4-dfsg-5: amd64: Pass
[14:47] <Laney> silo?
[14:48] <LocutusOfBorg> that usually means autopkgtests runs twice (but your point is valid, I didn't trigger the no-change rebuild, even if I proposed it)
[14:48] <LocutusOfBorg> anyway, [12:01:50] <LocutusOfBorg>  ./sil2100:force-badtest virtualbox-ext-pack/all/i386
[14:48] <LocutusOfBorg> [12:02:02] <LocutusOfBorg> can we please add virtualbox/all/i386? same reason for it...
[14:48] <Laney> Doesn't seem to me to be an appropriate use of the archive
[15:17] <talx> is it possible to get here
[15:17] <talx> for preseed installation
[15:18] <teward> talx: support in #ubuntu or #ubuntu-server but it looks like you already were helped about 3 hours ago in #ubuntu-server?
[15:19] <talx> nope
[15:19] <talx> the issue isn't solved for me
[15:19] <teward> talx: well, support is still in #ubuntu or #ubuntu-server, not here.
[15:19] <talx> oh
[15:19] <teward> this channel is specific for ubuntu development, not support.
[15:19] <talx> I was directred to here
[15:19] <talx> no intention to disrespect
[15:20] <teward> no problem :)
[20:04] <vorlon> stgraber, kees: TB meeting?
[22:23] <Eickmeyer> Odd question: I'm trying to fork the Lubuntu plymouth theme (obvious fork of the Ubuntu plymouth theme) for Ubuntu Studio by merely replacing the Lubuntu logo with the Ubuntu Studio logo and changing the background to a dark gray (RGB 0.17 0.17 0.17), but it keeps crashing. Trying to figure out what I'm doing wrong.
[22:24] <Eickmeyer> I've tried changing the size of the logo (a png file) but I'm getting nowhere.
[22:24] <Eickmeyer> Reason for the change: our existing plymouth theme is long-in-the-tooth and doesn't scale well.
[22:40] <sarnold> what crashes, where?
[22:47] <Eickmeyer> sarnold: plymouth during boot.
[23:00] <JackFrost> ...Ugh, libotr5-dev is in universe..