Re: iptables version upgrade timeline

2018-11-26 Thread Paul David
Hey Nish,

Thanks for your quick and very helpful response.  That clears up some of
the confusion.  In this case, we'll probably go ahead with building our
own package, or directly from upstream.

One thing though;

On 2018-11-27 at 03:31 AEDT+1100, quoth Nish Aravamudan:
> Finally, note that if/when iptables is merged in the Disco cycle, it will
> move to 1.8.2-based, most likely, as that is the version in Debian unstable
> currently.

That's fine, anything after 1.6.2 contains the feature / fix we're after
(you're right, it's more of a feature, because it exposes a kernel
option that previously wasn't available).

Do you have any visibility on whether iptables will be upgraded in
Disco?  I'm not asking for guarantees, just out of curiosity :).  Does
it depend on when Debian promotes it to testing or stable?

Thanks!
p.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: iptables version upgrade timeline

2018-11-26 Thread Nish Aravamudan
Hi Paul,

On Sun, Nov 25, 2018 at 8:37 PM Paul David  wrote:
>
> Dear maintainers,
>
> We use the iptables package (currently version 1.6.1) from Ubuntu,
> currently we're running bionic.  However, there's a fix in upstream
> iptables as of release v1.6.2 which we want to use on our systems.
> Specifically, this commit:
> <
https://git.netfilter.org/iptables/commit/?id=8b0da2130b8af3890ef20afb2305f11224bb39ec
>.

A couple of points to mention.

While the base upstream version of the Ubuntu package is 1.6.1, that does
not mean the contents of the source used to build the package are identical
to the upstream 1.6.1 (you can see by the version string suffix (-2ubuntu2)
that two Debian releases relative to the upstream have occurred, and two
Ubuntu releases relative to that second Debian release). Looking at the
changelog (`apt-get changelog iptables`), though, it does not appear any of
these involved any upstream backports, which is what you are asking for.

Looking at the upstream commit, this appears to be a new feature, not a
fix? That is, leveraging an upstream kernel change. You may want to read
over https://wiki.ubuntu.com/StableReleaseUpdates to understand what is and
is not considered appropriate for a SRU.

Finally, note that if/when iptables is merged in the Disco cycle, it will
move to 1.8.2-based, most likely, as that is the version in Debian unstable
currently.

> I noticed that on 
> that bionic, cosmic and disco distributions all have the same version of
> iptables package, namely v1.6.1.
>
> My question is, can we expect this package to be updated in LTS at some
> point, or should we come up with another solution?  We could manually
> build a package with a patch in it, but we're leery of doing that in our
> production systems.

It is unlikely, IMO, that iptables will be bumped to 1.6.2 or later in any
already-released version of Ubuntu. Instead, a SRU of the above feature,
could be requested, via a bug against the iptables source package:
https://bugs.launchpad.net/ubuntu/+source/iptables. However, without
knowing for sure this is a bugfix, I am not sure it satisifies the SRU
rules (it doesn't hurt to file the bug nonetheless). You might just get a
response of Wishlist-Invalid, or so.

Thanks,
Nish
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


iptables version upgrade timeline

2018-11-25 Thread Paul David
Dear maintainers,

We use the iptables package (currently version 1.6.1) from Ubuntu,
currently we're running bionic.  However, there's a fix in upstream
iptables as of release v1.6.2 which we want to use on our systems.
Specifically, this commit:
.

I noticed that on 
that bionic, cosmic and disco distributions all have the same version of
iptables package, namely v1.6.1.

My question is, can we expect this package to be updated in LTS at some
point, or should we come up with another solution?  We could manually
build a package with a patch in it, but we're leery of doing that in our
production systems.

Apologies if this isn't the right forum for the question.

Thank you,

p.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss