nginx package signature guarantees with Xenial?

Thomas Ward teward at
Fri Jul 1 13:12:21 UTC 2016


Sorry for not replying sooner. Along with the rest of the Server Team, I
help to maintain the nginx packaging in Ubuntu.

Robie's points have all been points he and I discussed on IRC or are
points I would make myself.  I'm not changing those points, as they are
spot-on accurate.

That said, if you're unsure of whether there is an nginx update in the
pipeline for Ubuntu or not, chances are I'm in the loop for any pending
updates, and you can drop me a message, or email the Server list where
I'll see it anyways, and I'll let you know generally if there's any
updates in the works.  (I can tell you there's one in the works now that
I intend to land in Yakkety (16.10) "soon" and am happy to share some
specifics off-list, though there'll be a message landing soon on the
lists for a call for testing of this, detailing the changes, anyways.)


On 07/01/2016 07:10 AM, Robie Basak wrote:
> Hi Jeff,
> Sorry, I just remembered this thread and that I hadn't replied.
> On Fri, Jun 24, 2016 at 03:06:13PM -0400, Jeff Kaufman wrote:
>>> Have you considered adding your module to Ubuntu's repositories? Is
>>> there any reason you couldn't maintain them in xenial-backports for the
>>> benefit of Xenial users, for example?
> Note that the usual route to adding packages to Ubuntu is via Debian.
> Though then you'd have to deal with the rebuilds in collaboration with
> the Debian nginx maintainers too, as well as the rebuilds in stable
> Ubuntu releases and backports[2] which would have to be done
> independently.
>> That's possible.  I don't have a great sense of what that would
>> entail.  For example, if the nginx package maintainer updated nginx,
>> the package for ngx_pagespeed would need to be rebuilt.  Is there a
>> good way to handle this?
> If there's a particular reason you don't want to do that then Ubuntu
> does accept Ubuntu-specific (not from Debian) packages too.
> Unfortunately, we don't really have a good way right now. However, in
> Ubuntu, we work in teams rather than owning specific maintainerships
> like Debian. If we know that ngx_pagespeed needs to be rebuilt, I expect
> that we'll JFDI. For example, we already do this with pinba-engine-mysql
> as needed.
> In the development release, an update can't land in the release pocket
> if it causes other packages to become uninstallable[1], so we should
> also notice. This assumes that the dependencies are set up correctly.
> In a stable release, I don't think we currently track this because it is
> quite an unusual case (I only know of pinba-engine-mysql and now this).
> But I'm sure the SRU team[3] would be open to some additional CI to
> prevent accidents if you're interested in driving this.
> We do expect that those interested in the package (in this case, you)
> are available to fix any issues though, for example if it fails to
> build, or otherwise blocks a new nginx release going in. We usually use
> IRC but this mailing list is fine to make contact too.
>>> Note that it's 16.04, not just 16. 16 will be ambiguous when a
>>> subsequent 16.10 is released.
>> But "16 LTS" isn't ambiguous, right?
> I guess not. You can call it what you like of course, though I don't
> think the Ubuntu release team or any Ubuntu developers call it that :)
> Sorry again for my delay in responding.
> Robie
> [1]
> [2]
> [3]

More information about the ubuntu-server mailing list