selective sync from debian: haproxy case

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

selective sync from debian: haproxy case

Andreas Hasenack-5
Hi all,

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?

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: selective sync from debian: haproxy case

Steve Langasek-6
Hi Andreas,

On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote:

> Hi all,
>
> 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.

What about using a block-proposed bug on the package instead?

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: selective sync from debian: haproxy case

Andreas Hasenack-5
Hi Steve,

On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek <[hidden email]> wrote:

>
> Hi Andreas,
>
> On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote:
> > Hi all,
> >
> > 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?

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: selective sync from debian: haproxy case

Colin Watson
I have no real opinion on the main question, but on a question of fact:

On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote:

> On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek <[hidden email]> wrote:
> > 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?

You'd likely want it removed from -proposed in that case so that it's
possible to upload new versions.  It wouldn't be auto-synced unless a
newer version is then uploaded to Debian unstable.

It might be worth somebody investigating beefing up auto-sync to support
"block-auto-sync" bugs on packages for this sort of situation.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: selective sync from debian: haproxy case

Steve Langasek-6
In reply to this post by Andreas Hasenack-5
On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote:
> On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek <[hidden email]> 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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: selective sync from debian: haproxy case

Andreas Hasenack-5
Thanks for all the answers. I think I will add an ubuntu version to
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 <[hidden email]> 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 <[hidden email]> 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/
> [hidden email]                                     [hidden email]
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel