the package, but no further changes. I can track debian updates in the
merges report. The bug approach with a tag seems a bit fragile.
On Mon, Dec 2, 2019 at 8:33 PM Steve Langasek <firstname.lastname@example.org> wrote:
> On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote:
> > On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek <email@example.com> wrote:
> > > On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote:
> > > > haproxy is currently a sync in ubuntu, at version 2.0.10-1. The 2.0.x
> > > > line is upstream's stable LTS line, and I would like to stay there.
> > > > Debian experimental already has 2.1.0-2, which is also an upstream
> > > > stable line, but not an LTS.
> > > > I would prefer that we don't move to 2.1.0 for the next ubuntu LTS
> > > > version, so how would I go about preventing that from being synced
> > > > into Ubuntu should debian move 2.1.0 from experimental to unstable? I
> > > > would like to continue to receive updates from unstable as long as
> > > > it's tracking the 2.0.x upstream line.
> > > > Some options I heard about:
> > > > a) sync blacklist
> > > > (https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt)
> > > > b) add an ubuntu version to the package, even though it's identical to
> > > > the debian one
> > > > Any other options?
> > > I wouldn't recommend using the sync blacklist, since it's not self-service
> > > (~ubuntu-archive) and it also blocks you from doing manual syncs using the
> > > standard tools (syncpackage).
> > > Setting a fake Ubuntu version seems doable, and managing the flow of new
> > > versions as merges, if a bit ugly.
> > I can work with that.
> > > What about using a block-proposed bug on the package instead?
> > Hm, let's see how that would work.
> > I file a bug saying this package shouldn't be synced automatically
> > (for example), and add that tag. Then each time there is a debian
> > update, it will not migrate, and I will check if that update is one I
> > want to have.
> > If yes, I remove the tag, let it migrate, and add the tag back again.
> > If not, I leave it as is, or perhaps ask someone from the release team
> > to remove it from proposed? Won't it just be synced again then?
> Yes, you can either add/remove the tag, or open/close the bug.
> If at some point before DebianImportFreeze, Debian moves to 2.1.0 in
> unstable, then obviously any further syncs this cycle are also going to be
> of versions you don't want. So you would want to leave the bug open, and
> leave the synced version in -proposed /unless/ you needed to do an
> Ubuntu-specific upload of haproxy, in which case you could ask an archive
> admin to temporarily remove the synced version from -proposed, do your
> upload, let it migrate to the release pocket, and then have the synced
> version copied back (so that it's ready for inclusion in 20.10).
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer https://www.debian.org/
> firstname.lastname@example.org email@example.com
> ubuntu-devel mailing list
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel