Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
On Thu, Aug 18, 2022 at 08:28:29AM -0700, Steve Langasek wrote: > I'm concerned that this requires subscription to the package in Debian for > this to not fall off the radar. We have merges.ubuntu.com which tracks > which packages need to be updated, and the standing assumption is that the > person who last uploaded the package to Ubuntu is responsible for following > through on the merges. Is this not the current practice of the Ubuntu > Server team? I think Andreas' mention of using a subscription was just about being more responsive, rather than as a substitute for grep-merges. But to answer your question of what our team does: We found that our packages weren't getting merged when last touched by people outside the team, or people who had left. So instead we monitor the status of all packages that we're subscribed to, and schedule such outstanding merges and track their progress, as our primary means of ensuring that merges happen. This doesn't work so well when we touch packages outside the normal scope of our team, such as during +1 maintenance, or sponsoring something unrelated to the server team. We do try to use grep-merges too though, and as it happens I reminded everyone in our standup today that they need to do this. However this is an individual thing, not a team thing. I think the cracks identified above suggest that we should find a better way. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi On Thu, Aug 18, 2022 at 12:28 PM Steve Langasek wrote: > > Hi Andreas, > > On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote: > > > I thought of: > > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, > > subscribe to the tiff package in debian, and sync it manually the next > > time there is a debian upload > > I'm concerned that this requires subscription to the package in Debian for > this to not fall off the radar. We have merges.ubuntu.com which tracks > which packages need to be updated, and the standing assumption is that the > person who last uploaded the package to Ubuntu is responsible for following > through on the merges. Is this not the current practice of the Ubuntu > Server team? It is, and we have a weekly report[1] about it. I just go through this extra step of subscribing to the package in the tracker so I don't have to wait for that weekly report. > There's a commandline tool, 'grep-merges', which lets you grep for packages > you touched last by email. 'grep-merges hasenack' currently returns empty > so you're currently good :) Thanks ;) 1. https://lists.ubuntu.com/archives/ubuntu-server/2022-August/009372.html (grep-merges is the last section in that email) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi Andreas, On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote: > I thought of: > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, > subscribe to the tiff package in debian, and sync it manually the next > time there is a debian upload I'm concerned that this requires subscription to the package in Debian for this to not fall off the radar. We have merges.ubuntu.com which tracks which packages need to be updated, and the standing assumption is that the person who last uploaded the package to Ubuntu is responsible for following through on the merges. Is this not the current practice of the Ubuntu Server team? There's a commandline tool, 'grep-merges', which lets you grep for packages you touched last by email. 'grep-merges hasenack' currently returns empty so you're currently good :) -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Oh, this is a rabbit hole... I'll just bite the bullet and drop the delta in 4ubuntu2, and watch for new debian uploads. On Thu, Aug 18, 2022 at 10:36 AM Marc Deslauriers wrote: > > On 2022-08-18 09:24, Andreas Hasenack wrote: > > Hi, > > > > On Wed, May 25, 2022 at 9:52 AM Lukas Märdian wrote: > >> > >> Am 25.05.22 um 13:22 schrieb Marc Deslauriers: > >>> [...] > We needed a version that does not contain the word "ubuntu", so it can be > auto-synced, once the committed patch is uploaded into Debian. But at > the same > time we needed it to be bigger than the current version (1.0.1-3build2) > and > wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" > version. We > came up with the following: > > > > I found myself in a similar situation today, but not quite. > > > > I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component > > mismatch. Eventually the MIR[2] was approved, and I can now remove the > > delta, but debian hasn't uploaded a new version yet. How to version > > the ubuntu package and allow for auto-sync to sync it in the future? > > > > 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new > > kinetic upload without ubuntu in the version) > > > > I thought of: > > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, > > subscribe to the tiff package in debian, and sync it manually the next > > time there is a debian upload > > b) use 4.4.0-5~build1 > > c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if > > we need another ubuntu upload *with* delta again, it gets messy > > d) 4.4.0-4maysync1 is lower than the current one in kinetic > > > > I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye > > on the package on the debian side of things, but what do you think of > > (b)? > > > > Of course, as soon as you use 4.4.0-5~build1, debian will release 4.4.0-4.1 :) > > Marc. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
On 2022-08-18 09:24, Andreas Hasenack wrote: > Hi, > > On Wed, May 25, 2022 at 9:52 AM Lukas Märdian wrote: >> >> Am 25.05.22 um 13:22 schrieb Marc Deslauriers: >>> [...] We needed a version that does not contain the word "ubuntu", so it can be auto-synced, once the committed patch is uploaded into Debian. But at the same time we needed it to be bigger than the current version (1.0.1-3build2) and wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We came up with the following: > > I found myself in a similar situation today, but not quite. > > I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component > mismatch. Eventually the MIR[2] was approved, and I can now remove the > delta, but debian hasn't uploaded a new version yet. How to version > the ubuntu package and allow for auto-sync to sync it in the future? > > 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new > kinetic upload without ubuntu in the version) > > I thought of: > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, > subscribe to the tiff package in debian, and sync it manually the next > time there is a debian upload > b) use 4.4.0-5~build1 > c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if > we need another ubuntu upload *with* delta again, it gets messy > d) 4.4.0-4maysync1 is lower than the current one in kinetic > > I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye > on the package on the debian side of things, but what do you think of > (b)? > Of course, as soon as you use 4.4.0-5~build1, debian will release 4.4.0-4.1 :) Marc. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
And I forgot the links: 1. https://launchpad.net/ubuntu/+source/tiff/4.4.0-4ubuntu1 2. https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551 On Thu, Aug 18, 2022 at 10:24 AM Andreas Hasenack wrote: > > Hi, > > On Wed, May 25, 2022 at 9:52 AM Lukas Märdian wrote: > > > > Am 25.05.22 um 13:22 schrieb Marc Deslauriers: > > > [...] > > >> We needed a version that does not contain the word "ubuntu", so it can be > > >> auto-synced, once the committed patch is uploaded into Debian. But at > > >> the same > > >> time we needed it to be bigger than the current version (1.0.1-3build2) > > >> and > > >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" > > >> version. We > > >> came up with the following: > > I found myself in a similar situation today, but not quite. > > I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component > mismatch. Eventually the MIR[2] was approved, and I can now remove the > delta, but debian hasn't uploaded a new version yet. How to version > the ubuntu package and allow for auto-sync to sync it in the future? > > 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new > kinetic upload without ubuntu in the version) > > I thought of: > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, > subscribe to the tiff package in debian, and sync it manually the next > time there is a debian upload > b) use 4.4.0-5~build1 > c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if > we need another ubuntu upload *with* delta again, it gets messy > d) 4.4.0-4maysync1 is lower than the current one in kinetic > > I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye > on the package on the debian side of things, but what do you think of > (b)? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi, On Wed, May 25, 2022 at 9:52 AM Lukas Märdian wrote: > > Am 25.05.22 um 13:22 schrieb Marc Deslauriers: > > [...] > >> We needed a version that does not contain the word "ubuntu", so it can be > >> auto-synced, once the committed patch is uploaded into Debian. But at the > >> same > >> time we needed it to be bigger than the current version (1.0.1-3build2) and > >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. > >> We > >> came up with the following: I found myself in a similar situation today, but not quite. I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component mismatch. Eventually the MIR[2] was approved, and I can now remove the delta, but debian hasn't uploaded a new version yet. How to version the ubuntu package and allow for auto-sync to sync it in the future? 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new kinetic upload without ubuntu in the version) I thought of: a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta, subscribe to the tiff package in debian, and sync it manually the next time there is a debian upload b) use 4.4.0-5~build1 c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if we need another ubuntu upload *with* delta again, it gets messy d) 4.4.0-4maysync1 is lower than the current one in kinetic I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye on the package on the debian side of things, but what do you think of (b)? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
[...]
We needed a version that does not contain the word "ubuntu", so it can be
auto-synced, once the committed patch is uploaded into Debian. But at the same
time we needed it to be bigger than the current version (1.0.1-3build2) and
wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
came up with the following:
1.0.1-3build2 < 1.0.1-3maysync1 < 1.0.1-3ubuntu1 => 1.0.1-3maysync1
I kind of think "maysync" and "willsync" could be confusing for users as they
may think it has something to do with the software they are installing...how
about something simple, like 3u1, or 3distro1?
I'm not sure how much end users look at or are influenced by the (end of
the) version string of the packages that they're installing. But I get
your point there. OTOH the "maysync"/"willsync" suffix makes things more
transparent for developers/packagers.
I very much like the "3u1" suffix, too ("3distro1" works as well), as it
is small and simple. But might be a bit opaque for developers/packagers.
Like, it's not obvious what's the difference between a "3ubuntu1" and
"3u1" Ubuntu package. If this would be documented, so everybody could
find the meaning behind it easily, this could be the best solution IMO.
The "+3b1" suffix suggested by xnox would not have worked in the case
described above, due to the special (not-so-special) "-3build2" version
string.
1.0.1-3build2 > 1.0.1-3b1 => not OK
1.0.1-3build2 < 1.0.1-3+b1 => OK, but:
1.0.1-3ubuntu1 < 1.0.1-3+b1 => not OK
The confusion wrt. Debian's binNMU version strings is another reason why
we should probably avoid the "+bN" notation, although I like the fact of
it never being able to show up in a Debian source upload for the same
reason.
-- Lukas
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi, On 2022-05-25 05:44, Lukas Märdian wrote: > Hi all! > > We had an interesting discussion with @enr0n and @brian-murray recently, about > which version string to choose if we want an Ubuntu package (+delta) to be > auto-synced, without the need for a manual merge. The results might be of > interest for the broader Ubuntu developer community! > > The context was a sponsoring request for "gnudatalanguage" [0] but the outcome > applies to and can be useful all over the archive. > > Initially a version of "1.0.1-3willsync1" was suggested, as the fix was > already > committed in Debian (Salsa) but not yet uploaded and we had some precedence > about the "willsyncX" version in the archive [1]. We wanted it to sync > automatically, as soon as the upload happens in Debian and therefore avoided > an > "ubuntuX" version string, as this would block an auto-sync [2]. BUT: > "-3willsync1" > "-3ubuntu1" or another potential, future "ubuntuX" version, so > if we'd need to add another patch, which might not necessarily auto-sync, we > cannot override the "willsync1" version with an "ubuntuX" version. That's a > problem and could lead to ugly version strings. > > > > We needed a version that does not contain the word "ubuntu", so it can be > auto-synced, once the committed patch is uploaded into Debian. But at the same > time we needed it to be bigger than the current version (1.0.1-3build2) and > wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We > came up with the following: > > > 1.0.1-3build2 < 1.0.1-3maysync1 < 1.0.1-3ubuntu1 => 1.0.1-3maysync1 I kind of think "maysync" and "willsync" could be confusing for users as they may think it has something to do with the software they are installing...how about something simple, like 3u1, or 3distro1? Marc. > > > So I'd like to suggest that anybody in a similar situation should be using a > "maysync1" revision, in favor of "willsync1". > > Cheers, > Lukas > > > PS: "1.0.1-3~willsync1" might have been another option, but that's in conflict > (i.e. smaller than) the current "-3build2" version string. > > > [0] https://pad.lv/1973377 > [1] $ apt search . | grep "sync[0-9]" > [2] https://git.launchpad.net/ubuntu-archive-tools/tree/auto-sync#n566 > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
In the past, when we did uploads into Ubuntu that we want to autosync, we simply used `+bN` as those are bigger than last debian source version, and get autosynced. It is a slight misnomer, as it is Debian's binNMU version number, but that also means none of debian's source versions may ever use that version, and the next debian upload is guaranteed to get autosynced. I.e. we have often uploaded snapshots of debian's packaging VCS into ubuntu as `+bN` given strong expectations that next debian upload will include all of those changes. -- okurrr, Dimitri On Wed, 25 May 2022 at 10:44, Lukas Märdian wrote: > > Hi all! > > We had an interesting discussion with @enr0n and @brian-murray recently, > about which version string to choose if we want an Ubuntu package > (+delta) to be auto-synced, without the need for a manual merge. The > results might be of interest for the broader Ubuntu developer community! > > The context was a sponsoring request for "gnudatalanguage" [0] but the > outcome applies to and can be useful all over the archive. > > Initially a version of "1.0.1-3willsync1" was suggested, as the fix was > already committed in Debian (Salsa) but not yet uploaded and we had some > precedence about the "willsyncX" version in the archive [1]. We wanted > it to sync automatically, as soon as the upload happens in Debian and > therefore avoided an "ubuntuX" version string, as this would block an > auto-sync [2]. BUT: "-3willsync1" > "-3ubuntu1" or another potential, > future "ubuntuX" version, so if we'd need to add another patch, which > might not necessarily auto-sync, we cannot override the "willsync1" > version with an "ubuntuX" version. That's a problem and could lead to > ugly version strings. > > > > We needed a version that does not contain the word "ubuntu", so it can > be auto-synced, once the committed patch is uploaded into Debian. But at > the same time we needed it to be bigger than the current version > (1.0.1-3build2) and wanted it to be smaller than a potential, future > "1.0.1-3ubuntu1" version. We came up with the following: > > > 1.0.1-3build2 < 1.0.1-3maysync1 < 1.0.1-3ubuntu1 => 1.0.1-3maysync1 > > > So I'd like to suggest that anybody in a similar situation should be > using a "maysync1" revision, in favor of "willsync1". > > Cheers, > Lukas > > > PS: "1.0.1-3~willsync1" might have been another option, but that's in > conflict (i.e. smaller than) the current "-3build2" version string. > > > [0] https://pad.lv/1973377 > [1] $ apt search . | grep "sync[0-9]" > [2] https://git.launchpad.net/ubuntu-archive-tools/tree/auto-sync#n566 > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
