shorewall-3.4.0 and shorewall-lite-3.4.0 now available. Reproducible: Always
Created attachment 112967 [details] net-firewall/shorewall-3.4.0 ebuild
Created attachment 112969 [details] net-firewall/shorewall-lite-3.4.0 ebuild
Strongly suggested "epatching" of 3.4.0 with: http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.0/errata/patches/
shorewall-3.4.1 and shorewall-lite-3.4.1 now available. suggesting renaming of currently attached ebuilds.
Created attachment 113499 [details] shorewall-3.4.0_p6.ebuild Here's an ebuild for shorewall-3.4.0 that includes all 6 upstream patches. It's already outdated with the release of 3.4.1, but I wonder if there's a better way to automate the patching.
Created attachment 113501 [details] shorewall-3.4.1.ebuild
(In reply to comment #5) > Created an attachment (id=113499) [edit] > shorewall-3.4.0_p6.ebuild > Here's an ebuild for shorewall-3.4.0 that includes all 6 upstream patches. > It's already outdated with the release of 3.4.1, but I wonder if there's a > better way to automate the patching. I suppose a revised ebuild should be released each time there's a patch or set of patches (shorewall-3.4.0-r1, -r2, etc). Otherwise, there may be a way to do it automatically or semi-automatically (whether user has appropriate client programs or not) if the user calls "emerge shorewall config". I would vote for the first method but that would require a shorewall (and shorewall-lite) maintainer. Regarding the ebuild you posted, you may consider adding these einfos as I think they are important: einfo "There are man pages for shorewall(8) and for each configuration file." einfo "If you are upgrading to 3.4 you should at least:" einfo "* check that /etc/shorewall/rfc1918 does not contain non-RFC1918 private" einfo " addresses. If it does, rename it to rfc1918.old" einfo "* remove /etc/shorewall/modules and use the one in /usr/share/shorewall/" einfo "* review IMAP LDAP NNTP POP3 SMTP and WEB macros as they have changed" einfo "* move any policy's default action specifications" einfo " from /etc/shorewall/actions to /etc/shorewall/shorewall.conf" einfo "* remove or rename custom version of Limit action (if any)" einfo "* entries in /etc/shorewall/providers require specific procedure at startup" Finally, let's not forget the companion package shorewall-lite. ;-)
For those of you using kernel 2.6.20 you need to patch with: http://www.shorewall.net/pub/shorewall/3.4/shorewall-3.4.1/errata/patches/ or you will experience serious misbehavior due to the Netfilter team renaming kernel modules. The same goes for shorewall-3.2.9 users: http://www.shorewall.net/pub/shorewall/3.2/shorewall-3.2.9/errata/patches/
Created attachment 114169 [details] shorewall-3.4.1_p4.ebuild ebuild incorporating latest shorewall patches as of 22 March 2007
Created attachment 114171 [details] shorewall-3.4.1_p4.ebuild Updated ebuild incorporating the einfo comments from Vieri (Comment #7). I should've checked the comments before posting this last update. Regarding ebuild naming, I lean toward using -rX for ebuild revisions, and _pX to designate upstream patches. But that's just my 2 cents. Regarding shorewall-lite, not all the patches in .../errata/patches will apply. Is the best thing to grab specific files from .../errata/Shorewall-lite/ and install them, or to apply those patches that make sense? In this particular case (3.4.1 patches 1, 2 & 4), patch-2 corresponds to the single update in the Shorewall-lite directory, but patch-1 also applies cleanly. patch-4 is for a file that doesn't exist in Shorewall-lite.
Created attachment 114183 [details] shorewall-lite-3.4.1_p2.ebuild
(In reply to comment #10) > Regarding ebuild naming, I lean toward using -rX for ebuild revisions, and _pX > to designate upstream patches. But that's just my 2 cents. > > Regarding shorewall-lite, not all the patches in .../errata/patches will apply. > Is the best thing to grab specific files from .../errata/Shorewall-lite/ and > install them, or to apply those patches that make sense? I think you're right about _pX but I don't have enough experience with ebuilds to say much about this. I don't think patching specific files from errata/Shorewall(-lite)/ is a good idea because they may change in time even within a single release/version. So I see a risk of having systems that "ebuild" the same shorewall version but with different updated files depending on when the files were grabbed. I think patching is better because the files are numerically incremented as they are dropped there. However, I asked upstream if they can slightly change patch file names to something like: patch-3.4.1-1.diff (applies to both) patch-3.4.1-2.diff (applies to both) patch-shorewall-3.4.1-4.diff (applies to shorewall only) likewise: patch-shorewall-lite-3.4.1-4.diff (applies to shorewall-lite only) I think that would make things clearer. Don't you think so?
(In reply to comment #12) > I think patching is better because the files are numerically incremented as > they are dropped there. > However, I asked upstream if they can slightly change patch file names to > something like: > > patch-3.4.1-1.diff (applies to both) > patch-3.4.1-2.diff (applies to both) > patch-shorewall-3.4.1-4.diff (applies to shorewall only) > likewise: > patch-shorewall-lite-3.4.1-4.diff (applies to shorewall-lite only) > > I think that would make things clearer. Don't you think so? I think that's a great idea. Thanks for asking the upstream folks about it.
(In reply to comment #13) > I think that's a great idea. Thanks for asking the upstream folks about it. Well, according to bug report http://bugs.gentoo.org/show_bug.cgi?id=172061 there's no reason to include patches since they will eventually be merged into the next official release. On one hand this is true but on the other there are cases where patching is vital. For example, the latest 3.4.1 will fail (just as any other release) if you have kernel 2.6.20. And 3.4.2 is not out yet. Installing kernel 2.6.20 is daring (~ keyword) but it's in portage. I think patching and revbumping would be useful for what I think is an important package. The problem is finding time to do it.
Created attachment 115288 [details] shorewall-3.4.2 ebuild
Created attachment 115290 [details] shorewall-lite 3.4.2 ebuild
(In reply to comment #13) > I think that's a great idea. Thanks for asking the upstream folks about it. Dean, please take a look at: http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.2/errata/patches/ Now the patches are well organized upstream.
(In reply to comment #17) > http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.2/errata/patches/ > Now the patches are well organized upstream. Very nice, Vieri. Thanks for asking the upstream folks about that. Even if the patchlevels aren't released in portage, it's much nicer for us rolling our own.
*** Bug 172061 has been marked as a duplicate of this bug. ***
They are in CVS now :)
