Some minor fixes and debian packaging #8
Conversation
foxycode
commented
Jan 27, 2012
foxycode
commented
- set proper chmod
- added ipv6 regex while searching for RESERVED adresses
- fixed msn port
- added OpenVPN port
- added Nagios NRPE daemon port
- added wait for interface feature
- added default firehol setting probing for debian based systems
- added wizzard support wlan
- added debian packaging
- added ipv6 regex while searching for RESERVED adresses - fixed msn port - added OpenVPN port - added Nagios NRPE daemon port - added wait for interface feature - added default firehol setting probing for debian based systems - added wizzard support wlan - added debian packaging
|
Sweet. Phil and I will give it a look over ASAP. 2012/1/27 Tomáš Jacík
:wq |
|
Indeed, thanks. I think it will be helpful to include some .deb packaging as it will make distribution easier. Having said that, I don't know if it's appropriate to import the debian/changelog and debian/NEWS and maybe a couple of others in their current form, since those are to do specifically with the official Debian package. I imagine it would be better to make a note of the Debian fixes within the main Changelog (which looks like it needs sprucing up too...) so that if/when the Debian packagers get ahold of the update they will continue to have their own changelog unmolested. |
|
I used original ubuntu packaging scripts with some updates. I know changelog should be updated, but I haven't time to do this and I can't delete it. Without changelog package can't be build. If you want, merge only code fixes and keep packaging for later. |
|
Can the changelog be appropriately derived from the git log somehow? :wq |
|
I am not sure, it needs specific format as I know. You can try do script for it or find some. http://www.debian.org/doc/debian-policy/ch-source.html |
|
I know it has a particular format. I was mostly trying to figure out :wq |
|
I am not sure if it is good idea. Gitlog should be very very long and in your repo firehol is no longer versioned. When I did merge, I upgraded old firehol package to new version from your repo and inserted new version description into changelog. My idea is add some major updates from gitlog to last record of package changelog and let it be. You can wipe older records in changelog if you want it cleaner. In fact, this is not the same package as fireholt package in debian package tree and should change name if you want it send to debian maintainers. |
|
Fair points. As far as a distinct package name, I suppose this codebase should Also, it brings to mind that there should probably be tags in the :wq |
|
According to original firehol changelog, last update was Tue Oct 5 21:10:08 2010 UTC (15 months, 3 weeks ago). I belive original project is dead. Maybe we should try get original repo access from them and bring it back to life. I am using firehol long time and don't want to change. I can help you with your fork little if you want. |
|
I dunno. A) Were there any updates there that haven't made it to fireholv6? I'm probably partial to GitHub's interface, at least for the present. 2012/1/27 Tomáš Jacík
:wq |
|
a) I don't know when you started with v6 guys, tell me. If there are some updates, should be easy to find. And Your tag idea for v6 is great. |
|
If you go back to the original repo, it's not even svn, it's cvs. I don't want to use that, but I'm not fussed otherwise. I don't know if original is dead or just glacial. Timeline-wise I submitted some patches on the SourceForge site in May 2010. There are a couple of commits post my git fork. I have been maintaining a pure mirror here: I posted to the mailing lists a couple of times but did not get a huge response. There are definitely a few people using it, though. I was hoping the patches might be encouraged for inclusion in the original project but at this point I don't think it's particularly likely. The users list seems more heavily subscribed than the devs so maybe it would be better to sort out some of the bits above and remaining niggles and produce an official release because the offer of a git repo and patches (per my originals) may be targetting the wrong audience. I'm not sure if we should post any release announcement using the existing infrastructure unless we got agreement from Costa Tsaousis first. It would definitely be one of the best places to find an audience. I don't suppose SourceForge would want us continuing to use their architecture for a project hosted elsewhere long-term, so we'd need to make arrangements. Also, pertinent to packaging: |
|
I have pushed the non-debian package bits into the staging branch. It looks OK to me. Since I cherry-picked the second commit and it has a new there may be a bit of trouble merging back to the foxycode repo, |
|
I have pushed the debian package components as-is into a separate "packaging" branch so we can decide what to clean up for inclusion. FWIW I am OK with someone merging staging onto master at this point, unless we want to do a bit more cleanup first. The bottom line is that master needs some cleanup anyway so I don't think we gain much by holding off at this point. When it reflects a meaningful release I would want to be more careful. |
|
So, what do you need from me now? Have I split this commits into separate ones for staging and packaging branch? I am not sure how to cancel last commits. |
Well, I have split the commits, reordered and pushed into this repo. It So you have two choices. You could just reimport this repo, or you could As a general rule you can use git reflog to find an earlier id and then git |
|
Finally I did it easy way. Deleted and forked again my repo :) |
