Created attachment 384314 [details, diff] New shorewall-4.6.3.2 ebuild Hi, this is the new net-firewall/shorewall package. Please add it to the tree (I am the proxy-maintainer). Like announced in https://bugs.gentoo.org/show_bug.cgi?id=508396#c5 I re-integrated net-firewall/shorewall{lite,6,6-lite,-core,-init} into one single net-firewall/shorewall package. This should improve maintenance because you only have to add *one* package instead of 6. Also, stabilizing should go faster... (still waiting that shorewall*-4.5.21.9 goes stable, bug 511620). I am not sure if we should add a news item for this version because 4.5.x users have to remove shorewall{6,-lite,6-lite,-init,-core) before they can upgrade to v4.6. Should I prepare one?
The files for 4.6.3.2 are no longer available upstream. Now it is 4.6.3.3
Thank you for the notice. Just rename the already attached ebuild to shorewall-4.6.3.3.ebuild and it will work...
Is there some sort of plan to migrate existing users of the split ebuilds back to the monolithic one?
I am open for any ideas! I looked through the portage tree but didn't find a similar example. If the block message won't be enough we should issue a news item. Another idea: 1. Release shorewall-4.6.3.3.ebuild which contains everything but still depend on shorewall{6,-lite,6-lite,-init,-core}-4.6.3.3. But this time, shorewall{6,-lite,6-lite,-init,-core}-4.6.3.3 are dummy packages (empty, installing nothing). 2) After 4.6.3.3 became stable we could remove the dependency on shorewall{6,-lite,6-lite,-init,-core} from the main shorewall package. So the dummy packages would be cleaned out by the next depclean... Pro: - Smooth transition. Cons: - There will be another bump where you need to touch 6 packages (we decided to move from split ebuilds back to the monolithic one because this was too much work for "you"). This is not a real problem, but remember: I am waiting since 2014-08-20 to get another 4.5.x release into portage (bug 520316) with an important fix and I am waiting since 2014-05-27(!) to stabilize a new version (bug 511620)... so if this will take another year, this is unacceptable. - Not sure if the user will understand that he/she now needs to set USE flags for net-firewall/shorewall... that's not obvious because he/she still sees the split packages... but maybe a news item will help here.
Created attachment 385396 [details, diff] New shorewall-4.6.3.4 ebuild I updated the patch file because I updated the service files.
(In reply to Thomas D. from comment #5) > New shorewall-4.6.3.4 ebuild Added to bleeding-edge overlay - thanks!
I have no preference for either split ebuild or monolithic. Simply use whatever is easier to maintain. I have now tested to upgrade to 4.6.3.4 from bleeding-edge, with only a trivial conflict to resolve. WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: net-firewall/shorewall:0 (net-firewall/shorewall-4.6.3.4:0/0::bleeding-edge, ebuild scheduled for merge) conflicts with =net-firewall/shorewall-4.5.21.10 required by (net-firewall/shorewall6-4.5.21.10:0/0::gentoo, installed) Just unmerge old shorwall and then install new shorewall. I don't think a news item is neccesary for that.
Created attachment 386462 [details, diff] New shorewall-4.6.4.1 ebuild I updated the patch for shorewall-4.6.4.1. Important changes: - The ebuild can now be used for Beta and RC releases again. - The ebuild now supports upstream patches. This makes epatch_user very easy. - I updated shorewallrc, SBINDIR has been changed from /sbin to /usr/sbin. - Due to the SBINDIR change, the runscripts and service files were updated. - shorewall-init runscript now always check if the firewall script must be re-compiled (behavior synchronized with upstream's /usr/sbin/shorewall-init script) @ Jan Psota: If you decide to update bleeding-edge overlay again, you maybe want to grab the changes from my overlay at Github... @ Proxy-Maintainer: Can we finally move this version into portage? Thanks.
"net-firewall/shorewall-4.6.4.1 ebuild by Thomas D. (bug 522278) - thanks!" ...in bleeding-edge :-) > @ Jan Psota: If you decide to update bleeding-edge overlay again, you maybe > want to grab the changes from my overlay at Github... Thank you! :-) Unfortunately I'm not enough familiar with git, so I just patched my tree. ...and there was some Thomas D. on github, but I found (-: https://github.com/Whissi/gentoo-overlay/tree/master/net-firewall/shorewall
@ Jan, yes -- that's my overlay. @ Proxy-Maintainers: Please bump to 4.6.4.3, just apply the patch and rename the ebuild. Thanks.
(In reply to Thomas D. from comment #10) > @ Jan, yes -- that's my overlay. Updated in bleeding-edge, too. Thanks! Did you consider changing "init" to "+init" in IUSE? 15% more sources in bz2, but idea of ...-init is good.
> Updated in bleeding-edge, too. Thanks! Thanks, too. > Did you consider changing "init" to "+init" in IUSE? > 15% more sources in bz2, but idea of ...-init is good. The size is not really a problem. Just a handful of scripts. But because shorewall-init doesn't work out of the box (you have to manually edit "/etc/conf.d/shorewall-init") I think that's not a good idea (people maybe only read the metadata.xml (equery uses net-firewall/shorewall) and think they are protected by shorewall-init, because the USE flag is set). There's already a notice in pkg_postinst() when emerging without init USE flag: if ! use init; then elog "" elog "Consider emerging ${CATEGORY}/${PN} with USE flag \"init\" to secure your system on boot" elog "before your shorewall-based firewall is ready to start." elog "" elog "To read more about shorewall-init, please visit" elog " http://www.shorewall.net/Shorewall-init.html" fi That way I hope people will read more about shorewall-init, set the USE flag by hand and configure shorewall-init for usage... Well, we could change the logic and install shorewall-init per default and check if shorewall-init is configured in pkg_postinst() (check if PRODUCTS in "/etc/conf.d/shorewall-init is empty"). If shorewall-init is not configured, we could show an ewarn in pkg_postinst(). If that's by intention the user could unset the init USE flag to get rid of the warning (pkg_postinst will then fallback to the current elog telling the user to consider emerging with init ;)). What do you think?
(In reply to Thomas D. from comment #12) Jan: > > Did you consider changing "init" to "+init" in IUSE? Thomas: > The size is not really a problem. Just a handful of scripts. [...] > But because shorewall-init doesn't work out of the box (you have to manually > edit "/etc/conf.d/shorewall-init") I think that's not a good idea (people > [...] > Well, we could change the logic and install shorewall-init per default and > check if shorewall-init is configured in pkg_postinst() (check if PRODUCTS > in "/etc/conf.d/shorewall-init is empty"). > [...] > What do you think? That's the right way - to invert the logic! Add +init and warn if PRODUCTS is not set in /etc/conf.d/shorewall-init (we can even check if P. value conform USE flags when installing shorewall!)
@ Jan: I'll implement this change for the upcoming 4.6.5 release. @ Proxy-Maintainer: Please, can somebody finally add shorewall-4.6.4.3 to the tree? Thanks...
Created attachment 389568 [details, diff] New shorewall-4.6.5.1 ebuild I updated the patch for shorewall-4.6.5.1. Use the patch or grab from my overlay: https://github.com/Whissi/gentoo-overlay/tree/master/net-firewall/shorewall @ Jan Psota: I enabled the "init" USE flag per default, but skipped the auto-modification of "PRODUCTS" in "/etc/conf.d/shorewall-init". Reason: shorewall-init doesn't honor STARTUP_ENABLED in "/etc/$PRODUCT/$PRODUCT.conf". If we *would* enable any installed shorewall firewall automatically in shorewall-init, people would see errors on boot if they did not configure every installed firewall. Also, if you decide to disable one of your Shorewall-based firewalls for some reason and do this by setting STARTUP_ENABLED=No and or removing the firewall from your runlevel, shorewall-init would still run the STOP action of your (disabled) firewall on boot which you won't expect in this moment. I asked upstream to clarify. @ Proxy-Maintainer: Please, can you finally add this version into the tree? Thank you.
$ git log #bleeding-edge net-firewall/shorewall-4.6.5.1.ebuild thanks to Thomas D. and his https://github.com/Whissi/gentoo-overlay @ Thomas D.: Right!
+*shorewall-4.6.5.2 (18 Nov 2014) + + 18 Nov 2014; Michael Weber <xmw@gentoo.org> + +files/4.6/shorewall-init-01_remove-ipset-functionality.patch, + +files/4.6/shorewall-init.confd, +files/4.6/shorewall-init.initd, + +files/4.6/shorewall-init.readme, +files/4.6/shorewall-init.systemd, + +files/4.6/shorewall-lite.confd, +files/4.6/shorewall-lite.initd, + +files/4.6/shorewall-lite.systemd, +files/4.6/shorewall.confd, + +files/4.6/shorewall.initd, +files/4.6/shorewall.systemd, + +files/4.6/shorewall6-lite.confd, +files/4.6/shorewall6-lite.initd, + +files/4.6/shorewall6-lite.systemd, +files/4.6/shorewall6.confd, + +files/4.6/shorewall6.initd, +files/4.6/shorewall6.systemd, + +files/4.6/shorewallrc, +files/4.6/shorewallrc-r1, +shorewall-4.6.5.2.ebuild, + metadata.xml: + Version bump (big thanks to whissi, bug 522278). +
* QA Notice: systemd units using /etc/conf.d detected: * usr/lib/systemd/system/shorewall6.service:EnvironmentFile=/etc/conf.d/shorewall6 * usr/lib/systemd/system/shorewall.service:EnvironmentFile=/etc/conf.d/shorewall * See: https://wiki.gentoo.org/wiki/Project:Systemd/conf.d_files
Please read https://wiki.gentoo.org/wiki/Project:Systemd/conf.d_files. It is just a notice from Gentoo's systemd team to tell developers to verify that their files in /etc/conf.d are no bash scripts, because OpenRC supports bash scripts at this point but systemd's EnvironmentFile doesn't (a difference not everyone knows yet). And that's what we are doing. shorewall's conf.d files are no bash scripts. So there shouldn't be a problem. If you disagree please fill a new bug.
