|
From: Mark F. <fe...@Fr...> - 2015-08-10 18:28:39
|
On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: > Hi Mark, > > On 08/10/2015 11:11, Mark Felder wrote: > > Kevin, is this the patch in question? > > > > https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ > > I've attached the patch that fixes 'ipfw' support. You can generate this > yourself by running: > > $ git diff v1.6.1 origin/1.6 > > Most of this diff consists of deletions. You can safely ignore the hunk > that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. > Do I understand the important parts of the patch correctly? 1) configure.ac copying command_ipfw.h to command.h 2) creation of src/fwalls/command_ipfw.h If so, I can easily fix the FreeBSD port if ipfw support is broken. |
|
From: Kevin Z. <kev...@gm...> - 2015-08-10 18:31:34
|
On 08/10/2015 13:28, Mark Felder wrote: > Do I understand the important parts of the patch correctly? > > 1) configure.ac copying command_ipfw.h to command.h > 2) creation of src/fwalls/command_ipfw.h Yes, that's all there is to it. Also note the change in Makefile.am that builds 'command.c' instead of 'ipfw.c'. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Willem J. W. <wj...@di...> - 2015-08-10 18:33:15
|
On 10-8-2015 20:28, Mark Felder wrote: > > > On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: >> Hi Mark, >> >> On 08/10/2015 11:11, Mark Felder wrote: >>> Kevin, is this the patch in question? >>> >>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ >> >> I've attached the patch that fixes 'ipfw' support. You can generate this >> yourself by running: >> >> $ git diff v1.6.1 origin/1.6 >> >> Most of this diff consists of deletions. You can safely ignore the hunk >> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. >> > > Do I understand the important parts of the patch correctly? > > 1) configure.ac copying command_ipfw.h to command.h > 2) creation of src/fwalls/command_ipfw.h > > > If so, I can easily fix the FreeBSD port if ipfw support is broken. One of the things I was looking at, is check if the type selection could be done thru 'make config'. That would make it just one port with many faces... Haven't gotten around to it, but I expect it not to be rocket science. --WjW |
|
From: Kevin Z. <kev...@gm...> - 2015-08-10 18:35:06
|
On 08/10/2015 13:32, Willem Jan Withagen wrote: > One of the things I was looking at, is check if the type selection could > be done thru 'make config'. > That would make it just one port with many faces... > Haven't gotten around to it, but I expect it not to be rocket science. It would be harder to build binary packages that way. OpenBSD does it nicely with 'flavors'; FreeBSD's equivalent are slave ports. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Mark F. <fe...@Fr...> - 2015-08-10 18:36:50
|
On Mon, Aug 10, 2015, at 13:32, Willem Jan Withagen wrote: > On 10-8-2015 20:28, Mark Felder wrote: > > > > > > On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: > >> Hi Mark, > >> > >> On 08/10/2015 11:11, Mark Felder wrote: > >>> Kevin, is this the patch in question? > >>> > >>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ > >> > >> I've attached the patch that fixes 'ipfw' support. You can generate this > >> yourself by running: > >> > >> $ git diff v1.6.1 origin/1.6 > >> > >> Most of this diff consists of deletions. You can safely ignore the hunk > >> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. > >> > > > > Do I understand the important parts of the patch correctly? > > > > 1) configure.ac copying command_ipfw.h to command.h > > 2) creation of src/fwalls/command_ipfw.h > > > > > > If so, I can easily fix the FreeBSD port if ipfw support is broken. > > One of the things I was looking at, is check if the type selection could > be done thru 'make config'. > That would make it just one port with many faces... > Haven't gotten around to it, but I expect it not to be rocket science. > This is intentionally not wanted because the "default" option is the only thing that would be available on the public package mirrors. With the current port having master and slave ports all of the backends of sshguard are built into packages ready for installation by the end user. This can all go away once FreeBSD and pkgng have deployed support for subpackages & flavors. |
|
From: Willem J. W. <wj...@di...> - 2015-08-10 18:40:00
|
On 10-8-2015 20:36, Mark Felder wrote: > > > On Mon, Aug 10, 2015, at 13:32, Willem Jan Withagen wrote: >> On 10-8-2015 20:28, Mark Felder wrote: >>> >>> >>> On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: >>>> Hi Mark, >>>> >>>> On 08/10/2015 11:11, Mark Felder wrote: >>>>> Kevin, is this the patch in question? >>>>> >>>>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ >>>> >>>> I've attached the patch that fixes 'ipfw' support. You can generate this >>>> yourself by running: >>>> >>>> $ git diff v1.6.1 origin/1.6 >>>> >>>> Most of this diff consists of deletions. You can safely ignore the hunk >>>> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. >>>> >>> >>> Do I understand the important parts of the patch correctly? >>> >>> 1) configure.ac copying command_ipfw.h to command.h >>> 2) creation of src/fwalls/command_ipfw.h >>> >>> >>> If so, I can easily fix the FreeBSD port if ipfw support is broken. >> >> One of the things I was looking at, is check if the type selection could >> be done thru 'make config'. >> That would make it just one port with many faces... >> Haven't gotten around to it, but I expect it not to be rocket science. >> > > This is intentionally not wanted because the "default" option is the > only thing that would be available on the public package mirrors. With > the current port having master and slave ports all of the backends of > sshguard are built into packages ready for installation by the end user. > > This can all go away once FreeBSD and pkgng have deployed support for > subpackages & flavors. Oke, makes sense... --WjW |