| === blahdeblah is now known as WeRateOps | ||
| === WeRateOps is now known as blahdeblah | ||
| === pitti is now known as pitti` | ||
| === pitti` is now known as pitti | ||
| === doko_ is now known as doko | ||
| === ricab is now known as ricab|bbl | ||
| 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:13 |
|---|---|---|
| cjwatson | kstenerud: Can you pastebin the whole debian/control? | 10:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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 |
| ubottu | Launchpad bug 1717998 in tomcat8.0 (Ubuntu) "Please remove tomcat8.0 before 18.04 releases" [High,Fix released] | 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:19 |
| kstenerud | ok | 10:20 |
| 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) | 10:24 |
| === ricab|bbl is now known as ricab_ | ||
| 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:40 |
| 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:41 |
| === sgclark is now known as sgmoore | ||
| cjwatson | rbasak: The de-facto standard is whatever backportpackage(1) does | 11:45 |
| 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:46 |
| * 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 | 11:47 | |
| === ricab_ is now known as ricab | ||
| === ricab__ is now known as ricab|laptop | ||
| === Saviq is now known as ricab|test | ||
| === ricab|test is now known as Saviq | ||
| === ricab is now known as ricab|lunch | ||
| === mitya57_ is now known as mitya57 | ||
| seb128 | jbicha, just curious but why libnotify did a "no change upload for autopkgtest"? | 14:35 |
| 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:36 |
| 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:39 |
| 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:44 |
| Laney | but why do that in the archive? | 14:45 |
| 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:46 |
| Laney | silo? | 14:47 |
| === ricab|lunch is now known as ricab | ||
| 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 | 14:48 |
| talx | is it possible to get here | 15:17 |
| talx | for preseed installation | 15:17 |
| teward | talx: support in #ubuntu or #ubuntu-server but it looks like you already were helped about 3 hours ago in #ubuntu-server? | 15:18 |
| 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:19 |
| teward | no problem :) | 15:20 |
| === JanC_ is now known as JanC | ||
| === sam_w_ is now known as sam_w | ||
| === blackboxsw_ is now known as blackboxsw | ||
| === bashfulrobot_ is now known as bashfulrobot | ||
| === mnepton is now known as mneptok | ||
| vorlon | stgraber, kees: TB meeting? | 20:04 |
| === gurmble is now known as grumble | ||
| 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:23 |
| 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:24 |
| sarnold | what crashes, where? | 22:40 |
| Eickmeyer | sarnold: plymouth during boot. | 22:47 |
| JackFrost | ...Ugh, libotr5-dev is in universe.. | 23:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!