Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#986152: RFH: shorewall -- Shoreline Firewall, netfilter configurator
18 views
Skip to first unread message
Roberto C. Sanchez
Mar 30, 2021, 10:10:03 AM3/30/21
to
Package: wnpp
Severity: normal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I request assistance with maintaining the shorewall package.
The package description is:
Shorewall allows firewall/gateway requirements to be described using
entries in a set of configuration files. It reads those configuration
files and, with the help of the iptables utility, configures
netfilter to match these requirements.
.
Shorewall supports a wide range of router/firewall/gateway applications,
traffic shaping and almost every type of VPN.
I have maintained the Shorewall packages in Debian for quite a few years
now, but my time to work on them has diminished. The reality is that
there are several issues that require attention, which I cannot at the
moment attend to. Over time the severity of these issues will likely
increase and the eventual result is that the Shorewall packages could be
removed from Debian.
If someone were to be able to devote some effort toward helping, I could
help with reviewing patches, sponsoring uploads, etc. It is still my
hope that I will find additional time to work on the Shorewall Debian
packages, but I do not want to make my inability to find enough time now
cause users of Debian to lose out on access to good quality Shorewall
packages.
Note that this RFH really encompasses the shorewall, shorewall6,
shorewall-lite, shorewall6-lite, shorewall-doc, and shorewall-core
source packages.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmBjLvUACgkQldFmTdL1
kUI9pA/9FqVYHab6iWdVfUpMm8hzCDYLEs1SRk3cIDWyMWWkGS5Me/gXKi0tok+0
EIN/I6jjaTctM/atDFuq3u8c8exdqrCszeIrrjjPiS1uKhUwYPc0N+obu5RHohOt
ns2F2vhg9C/pSMH1J4g1JWwQA5sqjxXWoP4WxhS8H5JdcxBI48pPETFuG4dsJQQx
SiwmA53PqrBao8c1p3c0Z+efDhIZgUp5GRANS9lbzCtNsj0s7zH/tHqsjtP82Jy+
IKJccPv5u1X/ChRf6AITD7fI9Xsn3qcxikfZgD5O0Yd9/AGJtbsR590yw4jZHFYZ
qIYFEOGJslYOXx4brAq5Cweevw9VzvIyjPeBjtKoOGYbSadH7+A357UIOqBUWvji
ZEaMVeO2V0s29+2RYE4A1bvbqOSkuuDQ6WG9z1z8qE2UhN4G65sljw6tYPtDOGZ3
N2jkBHo1N+9+OuC2rjKkuCfF1yfgVNbvlSUjMidNnjWRiW+PA6o7cVK8c8fuYQK3
ML/Pvib2LvEoyeetTPWijcnePr/Wrw5U0OeRxCNAXxfFBw4/JSyqudF/wiuvEfUV
hqEjttomIEkcSF8bf81DvQoxzjBnnQjrFS566esUR71VAjGuqEk4WVaL0ENhPNxL
Fjkjt5xIckCJIdvmCDPaRz66MrSPMGY+JX3eBjvGp33wgKJLVsY=
=apRC
-----END PGP SIGNATURE-----
Severity: normal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I request assistance with maintaining the shorewall package.
The package description is:
Shorewall allows firewall/gateway requirements to be described using
entries in a set of configuration files. It reads those configuration
files and, with the help of the iptables utility, configures
netfilter to match these requirements.
.
Shorewall supports a wide range of router/firewall/gateway applications,
traffic shaping and almost every type of VPN.
I have maintained the Shorewall packages in Debian for quite a few years
now, but my time to work on them has diminished. The reality is that
there are several issues that require attention, which I cannot at the
moment attend to. Over time the severity of these issues will likely
increase and the eventual result is that the Shorewall packages could be
removed from Debian.
If someone were to be able to devote some effort toward helping, I could
help with reviewing patches, sponsoring uploads, etc. It is still my
hope that I will find additional time to work on the Shorewall Debian
packages, but I do not want to make my inability to find enough time now
cause users of Debian to lose out on access to good quality Shorewall
packages.
Note that this RFH really encompasses the shorewall, shorewall6,
shorewall-lite, shorewall6-lite, shorewall-doc, and shorewall-core
source packages.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmBjLvUACgkQldFmTdL1
kUI9pA/9FqVYHab6iWdVfUpMm8hzCDYLEs1SRk3cIDWyMWWkGS5Me/gXKi0tok+0
EIN/I6jjaTctM/atDFuq3u8c8exdqrCszeIrrjjPiS1uKhUwYPc0N+obu5RHohOt
ns2F2vhg9C/pSMH1J4g1JWwQA5sqjxXWoP4WxhS8H5JdcxBI48pPETFuG4dsJQQx
SiwmA53PqrBao8c1p3c0Z+efDhIZgUp5GRANS9lbzCtNsj0s7zH/tHqsjtP82Jy+
IKJccPv5u1X/ChRf6AITD7fI9Xsn3qcxikfZgD5O0Yd9/AGJtbsR590yw4jZHFYZ
qIYFEOGJslYOXx4brAq5Cweevw9VzvIyjPeBjtKoOGYbSadH7+A357UIOqBUWvji
ZEaMVeO2V0s29+2RYE4A1bvbqOSkuuDQ6WG9z1z8qE2UhN4G65sljw6tYPtDOGZ3
N2jkBHo1N+9+OuC2rjKkuCfF1yfgVNbvlSUjMidNnjWRiW+PA6o7cVK8c8fuYQK3
ML/Pvib2LvEoyeetTPWijcnePr/Wrw5U0OeRxCNAXxfFBw4/JSyqudF/wiuvEfUV
hqEjttomIEkcSF8bf81DvQoxzjBnnQjrFS566esUR71VAjGuqEk4WVaL0ENhPNxL
Fjkjt5xIckCJIdvmCDPaRz66MrSPMGY+JX3eBjvGp33wgKJLVsY=
=apRC
-----END PGP SIGNATURE-----
Thom M Eastep
Apr 6, 2021, 12:00:04 AM4/6/21
to
I can come out of retirement enough to fix the issues in upstream... It sure would be great if we could get the final stable Shorewall packages into Debian.
Tom
_______________________________________________
Shorewall-devel mailing list
Shorewa...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Matt Darfeuille
Apr 6, 2021, 4:10:03 AM4/6/21
to
Bottom posting.
On 4/6/2021 5:47 AM, Thom M Eastep wrote:
> I can come out of retirement enough to fix the issues in upstream...
It sure would be great if we could get the final stable Shorewall
packages into Debian.
>
and getting out 5.2.8:
1) Make building of *.deb pkgs possible locally
2) Address bugs
3) Let Roberto do the final build and upload the pkgs
At the time I looked at reworking the pkgs, I was not able to find a way
to programatically change the maintainer name and other information.
So assuming that the bugs are worked out and the fixes are committed in
the Debian repo, Roberto would simply have to use 'pkg.py' to do 5.2.8.
--
Matt Darfeuille <ma...@shorewall.org>
Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/
SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/
Homepage: https://shorewall.org
On 4/6/2021 5:47 AM, Thom M Eastep wrote:
> I can come out of retirement enough to fix the issues in upstream...
It sure would be great if we could get the final stable Shorewall
packages into Debian.
>
> On March 30, 2021, at 7:09 AM, "Roberto C. Sanchez"
<rob...@connexer.com> wrote:
>
> Package: wnpp
> Severity: normal
>
<rob...@connexer.com> wrote:
>
> Package: wnpp
> Severity: normal
>
> I request assistance with maintaining the shorewall package.
>
The below is one fragile temporary solution for quickly addressing bugs
>
and getting out 5.2.8:
1) Make building of *.deb pkgs possible locally
2) Address bugs
3) Let Roberto do the final build and upload the pkgs
At the time I looked at reworking the pkgs, I was not able to find a way
to programatically change the maintainer name and other information.
So assuming that the bugs are worked out and the fixes are committed in
the Debian repo, Roberto would simply have to use 'pkg.py' to do 5.2.8.
--
Matt Darfeuille <ma...@shorewall.org>
Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/
SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/
Homepage: https://shorewall.org
Jeremy Sowden
Apr 7, 2021, 9:10:03 AM4/7/21
to
On 2021-04-02, at 11:51:20 +0100, Jeremy Sowden wrote:
> I'd be happy to help. I've been a Shorewall user for many years, and
> I've recently been lending a hand to the Netfilter Packaging Team.
I've forked your SF repo and committed changes to package 5.2.8:
> I'd be happy to help. I've been a Shorewall user for many years, and
> I've recently been lending a hand to the Netfilter Packaging Team.
https://sourceforge.net/u/a3a3el/shorewall-debian/ci/master/tree/
Does it look acceptable? I haven't looked at all the bugs in the BTS
yet.
J.
Jeremy Sowden
Oct 7, 2021, 7:10:02 PM10/7/21
to
On 2021-04-02, at 11:51:20 +0100, Jeremy Sowden wrote:
> I'd be happy to help. I've been a Shorewall user for many years, and
> I've recently been lending a hand to the Netfilter Packaging Team.
Ping! :)
> I've recently been lending a hand to the Netfilter Packaging Team.
Haven't had a response. Offer of help still stands.
J.
Romain Francoise
Jan 2, 2023, 12:20:03 PM1/2/23
to
Hi,
[Cc'ing Roberto directly to make sure he's aware of this discussion.]
I'm also a Shorewall[6] user and while the state of the package isn't
really alarming right now, I need it to be properly maintained going
forward.
We could set up a pkg-shorewall team on Salsa and co-maintain the
packages there. Jeremy, would that work for you?
Thanks.
[Cc'ing Roberto directly to make sure he's aware of this discussion.]
I'm also a Shorewall[6] user and while the state of the package isn't
really alarming right now, I need it to be properly maintained going
forward.
We could set up a pkg-shorewall team on Salsa and co-maintain the
packages there. Jeremy, would that work for you?
Thanks.
Jeremy Sowden
Jan 3, 2023, 6:04:05 PM1/3/23
to
https://salsa.debian.org/azazel/shorewall
I haven't touched it in 18 months, so I'll give it a polish when I have
some time, and perhaps we can use it as a starting point.
J.
Romain Francoise
Jan 7, 2023, 7:00:04 AM1/7/23
to
On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden <jer...@azazel.net> wrote:
> I've imported my fork of Roberto's SF repo to Salsa:
>
> https://salsa.debian.org/azazel/shorewall
>
> I haven't touched it in 18 months, so I'll give it a polish when I have
> some time, and perhaps we can use it as a starting point.
Thanks. I created a Salsa team and repo here:
> I've imported my fork of Roberto's SF repo to Salsa:
>
> https://salsa.debian.org/azazel/shorewall
>
> I haven't touched it in 18 months, so I'll give it a polish when I have
> some time, and perhaps we can use it as a starting point.
https://salsa.debian.org/shorewall-team/shorewall and added you both
as co-owners.
I felt more comfortable using Roberto's original SF repo as a starting
point, and merging in your changes after review. I can do that in the
next few days, the freeze is coming up very soon and I would like to
have the new upstream in bookworm. If you have further changes please
push them to your repo.
I'll also configure the CI on Salsa to have all the usual QA tools run
automatically on each push.
Did you find a practical way to do changes across all seven source
packages at once?
Jeremy Sowden
Jan 8, 2023, 9:42:41 AM1/8/23
to
On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote:
> On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > I've imported my fork of Roberto's SF repo to Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > I haven't touched it in 18 months, so I'll give it a polish when I have
> > some time, and perhaps we can use it as a starting point.
>
> Thanks. I created a Salsa team and repo here:
> https://salsa.debian.org/shorewall-team/shorewall and added you both
> as co-owners.
Thanks. I've created a Shorewall team on tracker.d.o and added you both
> On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > I've imported my fork of Roberto's SF repo to Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > I haven't touched it in 18 months, so I'll give it a polish when I have
> > some time, and perhaps we can use it as a starting point.
>
> Thanks. I created a Salsa team and repo here:
> https://salsa.debian.org/shorewall-team/shorewall and added you both
> as co-owners.
to it.
> I felt more comfortable using Roberto's original SF repo as a starting
> point, and merging in your changes after review. I can do that in the
> next few days, the freeze is coming up very soon and I would like to
> have the new upstream in bookworm. If you have further changes please
> push them to your repo.
know when I've pushed everything to Salsa. Should be later this week.
> I'll also configure the CI on Salsa to have all the usual QA tools run
> automatically on each push.
>
> Did you find a practical way to do changes across all seven source
> packages at once?
cherry-picking those commits into the other branches. Once 5.2.8-1 is
ready to go, perhaps we can come up with a way to get everything into
one source package with one master branch.
J.
Jeremy Sowden
Jan 8, 2023, 5:10:05 PM1/8/23
to
On 2023-01-08, at 14:35:17 +0000, Jeremy Sowden wrote:
> On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote:
> > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > > I've imported my fork of Roberto's SF repo to Salsa:
> > >
> > > https://salsa.debian.org/azazel/shorewall
> > >
> > > I haven't touched it in 18 months, so I'll give it a polish when I have
> > > some time, and perhaps we can use it as a starting point.
> >
> > Thanks. I created a Salsa team and repo here:
> > https://salsa.debian.org/shorewall-team/shorewall and added you both
> > as co-owners.
>
> Thanks. I've created a Shorewall team on tracker.d.o and added you both
> to it.
>
> > I felt more comfortable using Roberto's original SF repo as a starting
> > point, and merging in your changes after review. I can do that in the
> > next few days, the freeze is coming up very soon and I would like to
> > have the new upstream in bookworm. If you have further changes please
> > push them to your repo.
>
> Cool. I've started making a few more changes to my repo. I'll let you
> know when I've pushed everything to Salsa. Should be later this week.
I've pushed the recent changes. It's just mechanical updates and
> On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote:
> > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > > I've imported my fork of Roberto's SF repo to Salsa:
> > >
> > > https://salsa.debian.org/azazel/shorewall
> > >
> > > I haven't touched it in 18 months, so I'll give it a polish when I have
> > > some time, and perhaps we can use it as a starting point.
> >
> > Thanks. I created a Salsa team and repo here:
> > https://salsa.debian.org/shorewall-team/shorewall and added you both
> > as co-owners.
>
> Thanks. I've created a Shorewall team on tracker.d.o and added you both
> to it.
>
> > I felt more comfortable using Roberto's original SF repo as a starting
> > point, and merging in your changes after review. I can do that in the
> > next few days, the freeze is coming up very soon and I would like to
> > have the new upstream in bookworm. If you have further changes please
> > push them to your repo.
>
> Cool. I've started making a few more changes to my repo. I'll let you
> know when I've pushed everything to Salsa. Should be later this week.
Lintian fixes. I haven't taken a proper look at bugs.debian.org yet.
Roberto C. Sánchez
Jan 9, 2023, 9:10:04 AM1/9/23
to
On Mon, Jan 02, 2023 at 06:08:57PM +0100, Romain Francoise wrote:
> Hi,
>
> [Cc'ing Roberto directly to make sure he's aware of this discussion.]
>
Thanks for that. I'm not sure I would have seen it otherwise.
> Hi,
>
> [Cc'ing Roberto directly to make sure he's aware of this discussion.]
>
> I'm also a Shorewall[6] user and while the state of the package isn't
> really alarming right now, I need it to be properly maintained going
> forward.
>
need for a tool like Shorewall these days. Additionally, I have never
used some of the advanced features (e.g., Multi-ISP, tc, accounting,
etc.). It would be good to have others involved in maintenance who are
able to contribute in that way.
> We could set up a pkg-shorewall team on Salsa and co-maintain the
> packages there. Jeremy, would that work for you?
>
the moment I am not able to jump in to aid with the transition. I hope
to clear some major items from my queue in the coming weeks and until
then I will do what I can.
I'd like to mention that there is already a Gitlab group for upstream
Shorewall work (which has been essentially dormant for some time):
https://gitlab.com/shorewall
It might make sense to consider if there is any overlap and if any of
the Salsa work might be better house under the Shorewall Gitlab group.
I'll try to jump in a bit more helpfully next week.
Regards,
-Roberto
--
Roberto C. Sánchez
Roberto C. Sánchez
Jan 9, 2023, 9:10:04 AM1/9/23
to
the SF repo is quite antiquiated. It is from a time before debhelper
supported multiple .orig.tar.gz components. It might make sense to
consider starting with a new repo, with a more sensible branch
structure (one that works more easily with tools like gbp), and that
makes use of the multi-tarball capabilities so that you have have all
the source packages in view at the same time.
Jeremy Sowden
Jan 15, 2023, 5:53:47 AM1/15/23
to
with each upstream tar-ball as a subdirectory:
[azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall (master>)] $ ls -1
debian/
shorewall/
shorewall6/
shorewall6-lite/
shorewall-core/
shorewall-docs-xml/
shorewall-init/
shorewall-lite/
I'm currently working on merging the debian/ directories.
J.
Romain Francoise
Jan 15, 2023, 4:10:03 PM1/15/23
to
Hi,
Replying to the latest messages in the thread in one go...
On Sun, Jan 08, 2023 at 02:35:17PM +0000, Jeremy Sowden wrote:
> I've created a Shorewall team on tracker.d.o and added you both to it.
Thanks!
On Mon, Jan 09, 2023 at 08:51:54AM -0500, Roberto C. Sánchez wrote:
> For a bit of historical context, the current multi-branch structure from
> the SF repo is quite antiquiated. It is from a time before debhelper
> supported multiple .orig.tar.gz components. It might make sense to
> consider starting with a new repo, with a more sensible branch
> structure (one that works more easily with tools like gbp), and that
> makes use of the multi-tarball capabilities so that you have have all
> the source packages in view at the same time.
That would be simpler indeed. The only worry is that it probably means
going through NEW very close to freeze... but on the other hand it eases
maintenance for the next few years in stable.
On Mon, Jan 09, 2023 at 08:48:38AM -0500, Roberto C. Sánchez wrote:
> My needs have been evolving the last few years and I have much less of a
> need for a tool like Shorewall these days. Additionally, I have never
> used some of the advanced features (e.g., Multi-ISP, tc, accounting,
> etc.). It would be good to have others involved in maintenance who are
> able to contribute in that way.
FWIW, I use the Multi-ISP feature.
> I'd like to mention that there is already a Gitlab group for upstream
> Shorewall work (which has been essentially dormant for some time):
> https://gitlab.com/shorewall
>
> It might make sense to consider if there is any overlap and if any of
> the Salsa work might be better house under the Shorewall Gitlab group.
Personally, I'm not a fan of hosting Debian source on upstream
infrastructure. And Salsa provides preconfigured CI pipelines that are
very useful. (I configured them already but they didn't run because
nothing was pushed the new repo yet.)
On Sun, Jan 15, 2023 at 10:38:43AM +0000, Jeremy Sowden wrote:
> I've managed to coax gbp into importing 5.2.8 into one upstream branch
> with each upstream tar-ball as a subdirectory:
>
> [azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall (master>)] $ ls -1
> debian/
> shorewall/
> shorewall6/
> shorewall6-lite/
> shorewall-core/
> shorewall-docs-xml/
> shorewall-init/
> shorewall-lite/
> I'm currently working on merging the debian/ directories.
Cool! Thanks for working on this.
Replying to the latest messages in the thread in one go...
On Sun, Jan 08, 2023 at 02:35:17PM +0000, Jeremy Sowden wrote:
> I've created a Shorewall team on tracker.d.o and added you both to it.
On Mon, Jan 09, 2023 at 08:51:54AM -0500, Roberto C. Sánchez wrote:
> For a bit of historical context, the current multi-branch structure from
> the SF repo is quite antiquiated. It is from a time before debhelper
> supported multiple .orig.tar.gz components. It might make sense to
> consider starting with a new repo, with a more sensible branch
> structure (one that works more easily with tools like gbp), and that
> makes use of the multi-tarball capabilities so that you have have all
> the source packages in view at the same time.
going through NEW very close to freeze... but on the other hand it eases
maintenance for the next few years in stable.
On Mon, Jan 09, 2023 at 08:48:38AM -0500, Roberto C. Sánchez wrote:
> My needs have been evolving the last few years and I have much less of a
> need for a tool like Shorewall these days. Additionally, I have never
> used some of the advanced features (e.g., Multi-ISP, tc, accounting,
> etc.). It would be good to have others involved in maintenance who are
> able to contribute in that way.
> I'd like to mention that there is already a Gitlab group for upstream
> Shorewall work (which has been essentially dormant for some time):
> https://gitlab.com/shorewall
>
> It might make sense to consider if there is any overlap and if any of
> the Salsa work might be better house under the Shorewall Gitlab group.
infrastructure. And Salsa provides preconfigured CI pipelines that are
very useful. (I configured them already but they didn't run because
nothing was pushed the new repo yet.)
On Sun, Jan 15, 2023 at 10:38:43AM +0000, Jeremy Sowden wrote:
> I've managed to coax gbp into importing 5.2.8 into one upstream branch
> with each upstream tar-ball as a subdirectory:
>
> [azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall (master>)] $ ls -1
> debian/
> shorewall/
> shorewall6/
> shorewall6-lite/
> shorewall-core/
> shorewall-docs-xml/
> shorewall-init/
> shorewall-lite/
> I'm currently working on merging the debian/ directories.
Jeremy Sowden
Jan 19, 2023, 1:13:12 PM1/19/23
to
On 2023-01-15, at 22:03:46 +0100, Romain Francoise wrote:
> On Sun, Jan 15, 2023 at 10:38:43AM +0000, Jeremy Sowden wrote:
> > I've managed to coax gbp into importing 5.2.8 into one upstream
> > branch with each upstream tar-ball as a subdirectory.
> On Sun, Jan 15, 2023 at 10:38:43AM +0000, Jeremy Sowden wrote:
> > I've managed to coax gbp into importing 5.2.8 into one upstream
> >
> > I'm currently working on merging the debian/ directories.
>
> Cool! Thanks for working on this.
I created two new branches: debian/sid and upstream. The starting point
> > I'm currently working on merging the debian/ directories.
>
> Cool! Thanks for working on this.
for debian/sid was shorewall/debian/5.2.3.1-1; the upstream branch was
empty. I updated debian/gbp.conf and debian/watch so that `gbp
import-orig` would import all seven upstream tar-balls into the upstream
branch, each unpacked into a separate subdirectory. I then copied the
5.2.3.1-1 packaging from the other six master branches into debian/sid,
and applied all the 5.2.8 packaging updates. I've added a README.source
and a paragraph in the change-log outlining the change of structure. At
this point, I've got seven binary packages built from one source
package. Everything's lintian-clean and the Salsa CI pipeline passes.
I've pushed all the work to my repo on Salsa:
https://salsa.debian.org/azazel/shorewall
Do you want to review it before I push to the shorewall-team repo?
The 5.2.8 source package closes the following bugs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852
In addition, I think these are candidates for manual closure:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217
J.
Romain Francoise
Jan 19, 2023, 5:10:04 PM1/19/23
to
Hi Jeremy,
On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden <jer...@azazel.net> wrote:
> I've pushed all the work to my repo on Salsa:
>
> https://salsa.debian.org/azazel/shorewall
>
> Do you want to review it before I push to the shorewall-team repo?
It all looks pretty good to me! In fact, it's a radical improvement
over the previous packaging with seven source packages.
I've been staring at the diffoscope output for a few hours and I was
wondering why /etc/network/if-down.d/shorewall seemed to disappear in
shorewall-init but that's actually an upstream change from
5.2.5-beta1. All the other cleanups and changes look sensible to me,
especially the removal of the debconf bits.
I have not yet actually tested the packages in my lab but please feel
free to push your changes to the team repo, and I will do the final
testing and upload over the week-end. I can also take care of opening
the bugs to have the previous source packages removed from unstable.
Thanks again for the huge amount of work you put in!
> The 5.2.8 source package closes the following bugs:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852
Awesome.
> In addition, I think these are candidates for manual closure:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217
Yup. You already marked #928912 as fixed, so nothing more to do there.
On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden <jer...@azazel.net> wrote:
> I've pushed all the work to my repo on Salsa:
>
> https://salsa.debian.org/azazel/shorewall
>
> Do you want to review it before I push to the shorewall-team repo?
over the previous packaging with seven source packages.
I've been staring at the diffoscope output for a few hours and I was
wondering why /etc/network/if-down.d/shorewall seemed to disappear in
shorewall-init but that's actually an upstream change from
5.2.5-beta1. All the other cleanups and changes look sensible to me,
especially the removal of the debconf bits.
I have not yet actually tested the packages in my lab but please feel
free to push your changes to the team repo, and I will do the final
testing and upload over the week-end. I can also take care of opening
the bugs to have the previous source packages removed from unstable.
Thanks again for the huge amount of work you put in!
> The 5.2.8 source package closes the following bugs:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852
> In addition, I think these are candidates for manual closure:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217
Jeremy Sowden
Jan 20, 2023, 7:10:04 AM1/20/23
to
On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote:
> On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > I've pushed all the work to my repo on Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > Do you want to review it before I push to the shorewall-team repo?
>
> It all looks pretty good to me! In fact, it's a radical improvement
> over the previous packaging with seven source packages.
>
> I've been staring at the diffoscope output for a few hours and I was
> wondering why /etc/network/if-down.d/shorewall seemed to disappear in
> shorewall-init but that's actually an upstream change from
> 5.2.5-beta1. All the other cleanups and changes look sensible to me,
> especially the removal of the debconf bits.
Cool. Must play with diffoscope. I was vaguely aware of it, but I
> On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden <jer...@azazel.net> wrote:
> > I've pushed all the work to my repo on Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > Do you want to review it before I push to the shorewall-team repo?
>
> It all looks pretty good to me! In fact, it's a radical improvement
> over the previous packaging with seven source packages.
>
> I've been staring at the diffoscope output for a few hours and I was
> wondering why /etc/network/if-down.d/shorewall seemed to disappear in
> shorewall-init but that's actually an upstream change from
> 5.2.5-beta1. All the other cleanups and changes look sensible to me,
> especially the removal of the debconf bits.
don't think I've ever used it. I imagine it would have made comparing
the old and new packages easier than the ad hoc methods I have been
using.
> I have not yet actually tested the packages in my lab but please feel
> free to push your changes to the team repo, and I will do the final
> testing and upload over the week-end. I can also take care of opening
> the bugs to have the previous source packages removed from unstable.
§ 5.6.1, expresses the preference that when new binary packages are
added to a source package, it should be uploaded to experimental, so
I've updated the version and distribution in the change-log entry
accordingly.
> Thanks again for the huge amount of work you put in!
off, so it will be good to see it in the archive. :)
> > The 5.2.8 source package closes the following bugs:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852
>
> Awesome.
>
> > In addition, I think these are candidates for manual closure:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217
>
> Yup. You already marked #928912 as fixed, so nothing more to do there.
J.
Jeremy Sowden
Jan 20, 2023, 5:00:04 PM1/20/23
to
On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote:
> On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote:
> > I've pushed all the work to my repo on Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > Do you want to review it before I push to the shorewall-team repo?
>
> It all looks pretty good to me! In fact, it's a radical improvement
> over the previous packaging with seven source packages.
>
> [...]
> > I've pushed all the work to my repo on Salsa:
> >
> > https://salsa.debian.org/azazel/shorewall
> >
> > Do you want to review it before I push to the shorewall-team repo?
>
> It all looks pretty good to me! In fact, it's a radical improvement
> over the previous packaging with seven source packages.
>
>
> I have not yet actually tested the packages in my lab but please feel
> free to push your changes to the team repo, and I will do the final
> testing and upload over the week-end. I can also take care of opening
> the bugs to have the previous source packages removed from unstable.
I was wondering about this shorewall-doc bug:
> I have not yet actually tested the packages in my lab but please feel
> free to push your changes to the team repo, and I will do the final
> testing and upload over the week-end. I can also take care of opening
> the bugs to have the previous source packages removed from unstable.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957
Once 5.2.8 is uploaded there won't be a shorewall-doc source package.
Shall I reassign it to shorewall?
J.
Roberto C. Sánchez
Jan 20, 2023, 5:30:05 PM1/20/23
to
the shorewall-doc binary package, not the shorewall-doc source package.
Assuming that the shorewall source package will start to emit a
shorewall-doc binary package, I think that the BTS will do the right
thing and leaving the bug assigned to shorewall-doc is correct. In that
case, the source package association of shorewall-doc will change, but
its bugs will still belong to shorewall-doc (the binary package). If
you think about it, this must be the case, as closed and archived bugs
would end up being orphaned otherwise.
Romain Francoise
Jan 21, 2023, 4:10:04 AM1/21/23
to
On Fri, Jan 20, 2023 at 05:18:19PM -0500, Roberto C. Sánchez wrote:
> I think that the bug is actually assigned to the shorewall-doc binary
> package, not the shorewall-doc source package. Assuming that the
> shorewall source package will start to emit a shorewall-doc binary
> package, I think that the BTS will do the right thing and leaving the
> bug assigned to shorewall-doc is correct.
That's my understanding as well.
> I think that the bug is actually assigned to the shorewall-doc binary
> package, not the shorewall-doc source package. Assuming that the
> shorewall source package will start to emit a shorewall-doc binary
> package, I think that the BTS will do the right thing and leaving the
> bug assigned to shorewall-doc is correct.
Romain Francoise
Jan 21, 2023, 4:10:04 AM1/21/23
to
On Fri, Jan 20, 2023 at 11:59:44AM +0000, Jeremy Sowden wrote:
> The Developer's Reference, § 5.6.1, expresses the preference that when
> new binary packages are added to a source package, it should be
> uploaded to experimental, so I've updated the version and distribution
> in the change-log entry accordingly.
But these are not *new* binary packages, so I don't think the upload
> The Developer's Reference, § 5.6.1, expresses the preference that when
> new binary packages are added to a source package, it should be
> uploaded to experimental, so I've updated the version and distribution
> in the change-log entry accordingly.
will go through NEW. In fact, I hope it won't because there's still the
freeze to consider and I'd really like the new package to be in
bookworm.
Roberto C. Sánchez
Jan 21, 2023, 11:00:04 AM1/21/23
to
whether that package exists in the archive already or not, it will land
in NEW. For instance, this happens with libraries that bump SONAME and
start shipping a new binary package as a result. Consider the source
package foo which produces (among others) libfoo1. If the SONAME is
bumped to 2 causing libfoo2 to be emitted by the foo source package
instead of libfoo1, then that upload will land in NEW. The FTP masters
take notice and this particular case is usually handled very quickly
(since they don't have to do all the normal checks of a brand new source
package), but they still have to check that the new binary package being
created by the source package in question doesn't conflict with a binary
package from another source package. Imagine an entirely different
source package, foo2, that already produced the binary package libfoo2.
Allowing an unchecked upload of foo to add the libfoo2 binary package to
the archive when foo2 is already producing a libfoo2 package would be a
Bad Thing(TM).
This is where appropriate use of things like Breaks/Replaces/Conflicts
can help streamline the process.
Romain Francoise
Jan 21, 2023, 2:10:04 PM1/21/23
to
On Sat, Jan 21, 2023 at 10:47:12AM -0500, Roberto C. Sánchez wrote:
> Whenever a source package produces a new binary package, whether that
> package exists in the archive already or not, it will land in NEW.
Ah, makes sense. Thanks.
> Whenever a source package produces a new binary package, whether that
> package exists in the archive already or not, it will land in NEW.
Experimental it is, then. :-)
Romain Francoise
Jan 21, 2023, 2:10:04 PM1/21/23
to
I noticed while testing that you removed the '--no-start' argument to
dh_installinit calls in the unified package, and that's not right, as
README.Debian documents.
The situation is even a bit more complex:
* shorewall.postinst and shorewall6.postinst source the config file in
/etc/default and just exit if 'startup' is not 1. So the postinst bits
added by debhelper don't get executed at all, even though they exist.
* shorewall-init.postinst is fully generated by debhelper and does not
have this logic, so it enables and starts the shorewall-init service
which by default refuses to start ("ERROR: No products configured"),
leaving a failed systemd service behind.
I think we should call dh_installinit with '--no-enable --no-start'.
Also, the systemd services don't honor the 'startup' variable in
/etc/default/shorewall{,6} at all, so it feels wrong for the postinst
scripts to act differently based on it.
dh_installinit calls in the unified package, and that's not right, as
README.Debian documents.
The situation is even a bit more complex:
* shorewall.postinst and shorewall6.postinst source the config file in
/etc/default and just exit if 'startup' is not 1. So the postinst bits
added by debhelper don't get executed at all, even though they exist.
* shorewall-init.postinst is fully generated by debhelper and does not
have this logic, so it enables and starts the shorewall-init service
which by default refuses to start ("ERROR: No products configured"),
leaving a failed systemd service behind.
I think we should call dh_installinit with '--no-enable --no-start'.
Also, the systemd services don't honor the 'startup' variable in
/etc/default/shorewall{,6} at all, so it feels wrong for the postinst
scripts to act differently based on it.
Romain Francoise
Jan 24, 2023, 3:10:03 AM1/24/23
to
On Sun, Jan 22, 2023 at 02:08:41PM +0000, Jeremy Sowden wrote:
> Agreed. Not sure what the thinking was (those changes were initially
> made in April, '21). I think we can then remove the shorewall.postinst
> and shorewall6.postinst scripts completely.
Ok, I will do that in the next few days.
> Agreed. Not sure what the thinking was (those changes were initially
> made in April, '21). I think we can then remove the shorewall.postinst
> and shorewall6.postinst scripts completely.
Thanks,
--
Romain Francoise <rfran...@debian.org>
https://people.debian.org/~rfrancoise/
Romain Francoise
Jan 26, 2023, 2:50:04 PM1/26/23
to
Now finally uploaded! (And it didn't go through NEW.)
0 new messages