On 25/12/14 10:43, Gioacchino Mazzurco wrote: obviously, i disagree :) lime-init framework duplicated functionality already present in stock openwrt, so it added complexity unnecesarily what i did in: https://github.com/libre-mesh/lime-packages/commit/854c93744e8e85c98be67dc9… was put firewall-related things into /etc/firewall.user.d/ and random stuff in /etc/rc.local.d/, which i think makes much more sense to a newcomer, than an extra init system which is built on top of /etc/init.d/ and even has it's own semantics (.start / .stop suffixes?) "firewall" package is well-thought, well integrated into uci system, flexible enough to do many many things, and very easy to "disable" so that it stays out of the way: i don't recall any such "problem" since this commit https://github.com/libre-mesh/lime-packages/commit/c415a32e8e77904e11ca2033… which basically makes firewall package block nothing by default, unless asked to. i think being able to ship a "dormant" firewall package only brings benefits, and so far no problems. Unless you point out one such problems, i'll tag your phrase "has caused more problems than solutions" as [weasel words] :P don't get me wrong, i also expent much time and headaches "fighting" against openwrt default firewall, but i finally understood it was best to install it and ship a please-block-nothing config, than try to avoid it. if not, there's sometimes a post-flash opkg install that will pull it as a dependency, or you will (at some point) want to configure an ipv4 port forwarding, and then you'll miss the simplicity/flexibility of /etc/config/firewall it's a dependency of lime-proto-bmx6 as well https://github.com/libre-mesh/lime-packages/blob/develop/packages/lime-prot… i've pushed a commit to hotfix this in release/14.08 (since at it stands now, release/14.08 is broken) https://github.com/libre-mesh/lime-packages/commit/578dc314b61c27a8deca735f… if nobody objects until tomorrow i'll merge it in develop as well cheers!

On Thursday, December 25, 2014 11:54:33 AM Gui Iribarren wrote: BTW is not a good idea to merge release branch in develop, because this way also release specific commit like config edit, ip range and similar stuff will override develop one, the approach we consensuated is using hotfix branches. As the fix is already pushed in public repo in the release branch for this time we can simply cherry pitch just that commit in develop instead of merging the release branch, so we can avoid overriding end/or conflicts ;)