[00:20] ^ [13:41] hi #security, when a package in a stable release is, say, 1.0-1, and you need to issue a security update, but that security update is just a rebuild [13:41] do you call the rebuild 1.0-1build1, or something else? [13:41] there is no added patch, so in principle it shouldn't warrant an ubuntu suffix [14:08] ahasenack: we could, but we usually don't [14:08] usually don't what? [14:08] ahasenack: our automated tooling just uses our usual security update "ubuntu" version string [14:08] oh, so you would call it 1.0-1ubuntu0.1? [14:09] yes, even if we could use "build" [14:09] ok, but you wouldn't mind if we used 1.0-1build1? [14:09] nope, wouldn't mind at all, though you probably want 1build0.1 just to be sure [14:09] (bar other upgrade issues that might arise, but let's assume I checked) [14:10] is there precedence for using 1build0.1? [14:10] isn't using "build" risking to conflict with a fresher import from debian? [14:10] we do that so we don't collide with later releases that may have gotten a build1 during the dev cycle [14:11] but it's a stable release, not devel [14:11] and later stable releases have a new upstream version [14:11] so, in what I'm describing is for stable releases, not the dev release [14:11] (in this particular case) [14:11] ok, let me layout the actual package [14:11] ahasenack: if you look at the publishing history, and there was never a build1, sure, you can use build1 [14:12] https://pastebin.ubuntu.com/p/69vJC7Bvdy/ [14:12] would you still prefer 1build0.1? [14:12] ok, looks like there was never a 1.0.5-1build1 https://launchpad.net/ubuntu/+source/go-md2man/+publishinghistory [14:13] you can use build1 if you like [14:13] using 0.1 vs 1 is just to minimize the chance of colliding with the package history [14:13] k [14:14] it's even gone from devel [14:14] jammy even [14:14] k [17:49] sdeziel: imports from Debian are always rebuilds, so theoretically... shouldn't all buildN suffixes from Debian be dropped? :)