Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

On Wed, 5 Apr 2017 18:25:04 +0200
Hugo Lefeuvre  wrote:

> Are you already a member of the team ? If yes, could you move your git
> repository to
> https://anonscm.debian.org/git/pkg-security/arpwatch.git ?

I've now officially joined the team, the repository is available at
that URL.

I've also uploaded the updated package to mentors (not sure if you need
that, probably you will use the git repo instead).

> If needed, I can remove the old one on collab-maint.

If you can do that, after the upload, that would be great.

Thanks
Lukas


pgp4QinSBTzOi.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Gianfranco Costamagna]

Hello,


The reason for not using a "dirs" file is that in general the upstream build 
system should
work "alone", without external helping from our side.
This patch is upstreamable, and fixes the issue for other distros out there.

Having such custom hacks in debian packaging hides the problem, and leads to 
people
running ./configure manualy complain loudly.
So, when possible, please use an "upstreamable" approach to issues
(the above is a general answer)

>I think you don't need the ~exp1.


the pro for using -1~exp1 is that the upload on unstable
can go as -1 without having a -2 revision bump.
But... who really cares? :)

>> * Is there a procedure to join (or apply for joining) the
>>   pkg-security-team? I did not find any information regarding that
>>   online.
>
>I am not admin, but I think Gianfranco can add you.


situation has changed :p
https://alioth.debian.org/projects/pkg-security
https://wiki.debian.org/Teams/pkg-security
please follow the wiki to apply :D

G.

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

> * Does somebody have a recommendation regarding the version for
>   experimental (add ~exp1 or just increase the version once more when
>   uploading to unstable after stretch was released)?

I think you don't need the ~exp1.

For your next upload to unstable, you'll just have to increase the
version as usual and mention "Upload to unstable." in the changelog.

> * Is there a procedure to join (or apply for joining) the
>   pkg-security-team? I did not find any information regarding that
>   online.

I am not admin, but I think Gianfranco can add you.

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

On Thu, 6 Apr 2017 15:24:04 + (UTC)
Gianfranco Costamagna  wrote:
> -   $(INSTALL) -m 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> +   $(INSTALL) -Dm 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> 
> 
> this should work too (as said above) and is less invasive :)  

As everybody here prefers patching Makefile.in instead of using `dirs`,
I'll go with your recommendation.


Moving forward:
* Does somebody have a recommendation regarding the version for
  experimental (add ~exp1 or just increase the version once more when
  uploading to unstable after stretch was released)?
* Is there a procedure to join (or apply for joining) the
  pkg-security-team? I did not find any information regarding that
  online.


Thanks
Lukas


pgptf24NSRjKo.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

> -   $(INSTALL) -m 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> +   $(INSTALL) -Dm 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> 
> 
> this should work too (as said above) and is less invasive :)

Oh right, thanks :)

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#858860: RFS: arpwatch [ITA]

[Gianfranco Costamagna]

Hello,

-   $(INSTALL) -m 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
+   $(INSTALL) -Dm 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)


this should work too (as said above) and is less invasive :)

G.

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

Hi Christian, Lukas,

> It does solve the problem (i.e. the error is gone if `usr/sbin` is
> present in the `dirs` file).  According to the Debian New Maintainers'
> Guide guide, creating directories that are not created by
> `make install DESTDIR=...` as invoked by dh_auto_install is exactly
> what the dirs file is for [1].

right :)

> Also, running `dh binary --no-act` in the arpwatch packaging dir yields:
> $ dh binary --no-act
>(...)
>dh_installdirs
>dh_auto_install
>(...)
> 
> 
> Can you explain in which situations dh_installdirs will be run after
> dh_auto_install? 

As far as I am aware, dh_installdirs in always executed before dh_auto_install.
This is also what the Debian New Maintainer's Guide suggests[0].

> I'd like to avoid messing with the upstream build system more than
> required.  If dh_installdirs isn't the correct approach, maybe I can
> create an override_dh_auto_install target and create the directory
> there before calling dh_auto_install…?

I'd say using dirs is fine.

Alternatively you could probably patch the Makefile like that:

--- a/Makefile.in   2017-04-05 18:04:48.110827892 +0200
+++ b/Makefile.in   2017-04-05 18:04:48.106828088 +0200
 @@ -111,7 +111,7 @@
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ zap.o intoa.o -lutil
 
  install: force
-   $(INSTALL) -m 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
+   mkdir -p "$(DESTDIR)" && $(INSTALL) -m 555 -o bin -g bin arpwatch 
$(DESTDIR)$(BINDEST)
$(INSTALL) -m 555 -o bin -g bin arpsnmp $(DESTDIR)$(BINDEST)

 install-man: force

Cheers,
 Hugo

[0] https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#858860: RFS: arpwatch [ITA]

[Christian Seiler]

On 04/06/2017 02:51 PM, Lukas Schwaighofer wrote:
> Hi Christian,
> 
> On Thu, 6 Apr 2017 14:30:24 +0200
> Christian Seiler  wrote:
>> The problem is that dirs is only interpreted by dh_installdirs, which
>> is typically run after dh_auto_install, so that wouldn't actually
>> solve your problem.
> 
> It does solve the problem (i.e. the error is gone if `usr/sbin` is
> present in the `dirs` file).  According to the Debian New Maintainers'
> Guide guide, creating directories that are not created by
> `make install DESTDIR=...` as invoked by dh_auto_install is exactly
> what the dirs file is for [1].
> 
> Also, running `dh binary --no-act` in the arpwatch packaging dir yields:
> $ dh binary --no-act
>(...)
>dh_installdirs
>dh_auto_install
>(...)
> 
> 
> Can you explain in which situations dh_installdirs will be run after
> dh_auto_install? 

Oh, ok, then I was wrong about that. I had in mind that dh binary first
runs dh_auto_install and then all of the other dh_* things required to
actually create the binary package. But if your call to dh shows
differently, then that won't happen, and I was simply wrong about that.

(TBH, I've only ever used dirs for creating empty directory that are
required by the packaged software during runtime.)

Sorry for the noise.

Regards,
Christian

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Christian,

On Thu, 6 Apr 2017 14:30:24 +0200
Christian Seiler  wrote:
> The problem is that dirs is only interpreted by dh_installdirs, which
> is typically run after dh_auto_install, so that wouldn't actually
> solve your problem.

It does solve the problem (i.e. the error is gone if `usr/sbin` is
present in the `dirs` file).  According to the Debian New Maintainers'
Guide guide, creating directories that are not created by
`make install DESTDIR=...` as invoked by dh_auto_install is exactly
what the dirs file is for [1].

Also, running `dh binary --no-act` in the arpwatch packaging dir yields:
$ dh binary --no-act
   (...)
   dh_installdirs
   dh_auto_install
   (...)


Can you explain in which situations dh_installdirs will be run after
dh_auto_install? 

I'd like to avoid messing with the upstream build system more than
required.  If dh_installdirs isn't the correct approach, maybe I can
create an override_dh_auto_install target and create the directory
there before calling dh_auto_install…?

Thanks
Lukas

[1] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs


pgpzCvZkpNB7f.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Christian Seiler]

On 04/05/2017 07:02 PM, Lukas Schwaighofer wrote:
> On Wed, 5 Apr 2017 18:25:04 +0200
> Hugo Lefeuvre  wrote:
>>> If I remove `usr/sbin` from dirs, buildpackage fails complaining
>>> that the directory does not exist (so something in the build system
>>> is slightly broken).  
>>
>> The error message is
>>
>> /usr/bin/install -c -m 555 -o bin -g bin
>> arpwatch /build/arpwatch-2.1a15/debian/arpwatch/usr/sbin /usr/bin/install:
>> cannot create regular file
>> '/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or
>> directory Makefile:114: recipe for target 'install' failed 
>>
>> looks like the Makefile installs files under usr/sbin, but doesn't
>> create the directory if it doesn't exist. This is rather a Makefile
>> bug.
> 
> With "build system" I meant this process of autotools creating the
> Makefile, and `make install` doing something slightly wrong.  Anyway,
> that means keeping `usr/sbin` in the dirs file is the correct "fix",
> right?

The problem is that dirs is only interpreted by dh_installdirs, which
is typically run after dh_auto_install, so that wouldn't actually
solve your problem.

You should probably just patch the build system to create the install
directory if it doesn't exist. (Maybe just use install -D to copy the
file, that will auto-create the directories leading up to the target.)

Regards,
Christian

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks again for the review and the comments!

On Wed, 5 Apr 2017 18:25:04 +0200
Hugo Lefeuvre  wrote:
> > * debian-watch-may-check-gpg-signature  
> 
> I wouldn't override debian-watch-may-check-gpg-signature btw.

Ok, I will revert that override.

> > If I remove `usr/sbin` from dirs, buildpackage fails complaining
> > that the directory does not exist (so something in the build system
> > is slightly broken).  
> 
> The error message is
> 
> /usr/bin/install -c -m 555 -o bin -g bin
> arpwatch /build/arpwatch-2.1a15/debian/arpwatch/usr/sbin /usr/bin/install:
> cannot create regular file
> '/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or
> directory Makefile:114: recipe for target 'install' failed 
> 
> looks like the Makefile installs files under usr/sbin, but doesn't
> create the directory if it doesn't exist. This is rather a Makefile
> bug.

With "build system" I meant this process of autotools creating the
Makefile, and `make install` doing something slightly wrong.  Anyway,
that means keeping `usr/sbin` in the dirs file is the correct "fix",
right?

> If the dpkg documentation recommends to do so, then, fine, forget
> about this warning.

But it also makes sense to drop dpkg version constraints at some point.
I wonder if it's not better to ask the dpkg maintainers if that
recommendation still holds…

> Are you already a member of the team ? If yes, could you move your git
> repository to
> https://anonscm.debian.org/git/pkg-security/arpwatch.git ?

I'm not a member of the team yet, where can I apply? :)
Disclaimer: this is my first package…

When pushing to the repository, should the changes go into a separate
branch for experimental (e.g. debian/experimental instead of
debian/master)?
Also I'm uncertain if I should add ~exp1 to the version number. Some
packages seem to do it for experimental uploads, others don't and just
increment the version number once when uploading to unstable later. Do
you have a recommendation?


I have the following on my TODO list which I would like to resolve
before the upload:
* decide on whether to add ~exp1 to version number
* remove the override for debian-watch-may-check-gpg-signature
* update debian/changelog timestamp (which I forgot to do after
  yesterday's changes)
* git-tag the release and push the git repository to its new home


Regards
Lukas


pgpAJzkXzGfhc.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

Hi Lukas,

> I do not have a web based git viewer installed on my server, however
>   git clone https://git.somlen.de/arpwatch.git
> should work. Remember to switch to the `staged-changes` branch.
> 
> (I should probably create a page explaining that this is a git only url
> instead of displaying a 403…)

Fine, thanks !

> > Quick review:
> > 
> > * lintian reports
> > 
> >   P: arpwatch source: source-contains-data-from-ieee-data-oui-db
> > ethercodes.dat 
> > 
> >   but it looks like you already fixed it. If this warning is not
> > relevant anymore please override it.  
> 
> Well, I did not really fix it. ethercodes.dat is still part of the
> source package, it's just no longer put into the binary package. But, as
> it is small and it does not violate the DFSG, Christian Seiler suggested
> on debian-mentors not to repack [1].
> 
> I have not previously overridden that tag because I was not sure if it
> is best practice to override lintian pediantic tags at all (only quite
> few packages seem to do it) as they also don't show up on the
> tracker.debian.org page. Anyways, I've now overridden the following two
> pedantic tags, together with a justification as comment:
> * source-contains-data-from-ieee-data-oui-db

I usually don't override pedantic tags.

However, I think it may be useful in this case because this tag and the 
following
changelog entry could seem to be somewhat contradictory without additional
explanations:

 * use ethercodes from ieee-data

One could think you just forgot to remove the file.

Overriding the tag allows you to explain why you did not remove the
file and why the tag isn't relevant anymore.

But anyway, that's not important, other developers would probably do it
differently.

> * debian-watch-may-check-gpg-signature

I wouldn't override debian-watch-may-check-gpg-signature btw.

> > * There's no copyright entry for you
> 
> Fixed.
> 
> > Nitpicking:
> > 
> > in debian/changelog: why "remove dmassagevendor" ? This changelog
> > entry could be more verbose.  
> 
> Right, I have a longer justification in the git history; I have expanded
> on the changelog entry.
> 
> > $ cme check dpkg
> > [...]
> > Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is 
> > actually needed. See 
> > L for 
> > details
> > Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this
> > directory is actually needed. See
> > L
> > for details  
> 
> If I remove `usr/sbin` from dirs, buildpackage fails complaining that
> the directory does not exist (so something in the build system is
> slightly broken).

The error message is

/usr/bin/install -c -m 555 -o bin -g bin arpwatch 
/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin
/usr/bin/install: cannot create regular file 
'/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or directory
Makefile:114: recipe for target 'install' failed 

looks like the Makefile installs files under usr/sbin, but doesn't
create the directory if it doesn't exist. This is rather a Makefile bug.

> `var/lib/arpwatch` is an empty directory created by the package that is
> populated with ethercodes.db during postinst (and then with interface
> specific database files once arpwatch is started). Should I create the
> directory during postinst instead? Creating the empty directory as part
> of the package seems nicer since dpkg will take care of the `rmdir` and
> warn the user if the directory is not empty on uninstall.

OK, fine.

> > [...]
> > Warning in 'control source Vcs-Git' value 
> > 'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
> > transport protocol is used for this URI. It is recommended to use a
> > secure transport such as HTTPS for anonymous read-only access.
> > 
> > Warning in 'control source Vcs-Git' value 
> > 'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
> > canonical one for repositories hosted on Alioth.  
> 
> I had that on my TODO list but decided to wait and see how I get the
> package sponsored before changing the Url. I've now pointed it to what I
> expect to become its new home in case you are willing to sponsor the
> package:
>   https://anonscm.debian.org/cgit/pkg-security/arpwatch.git
>   https://anonscm.debian.org/git/pkg-security/arpwatch.git
> I've also adjusted debian/control to what I think it should be for team
> maintenance (maintainer is pkg-security-team, added myself as uploader).

Fine. Yes, I'll sponsor your package.

> > Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 
> > 1.16.1)': unnecessary versioned dependency: dpkg (>= 1.16.1).
> > Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
> > testing -> 1.18.23;  
> 
> Ok, I removed the pre-dependenciy.
> 
> In order to setup the file based trigger I followed man deb-triggers(5)
> from dpkg-dev version 1.18.23 (most recent version in 

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks a lot for looking at this.  I have made some changes to the
package based on your feedback, pushed them to my git repository and
uploaded the new version to mentors:
https://mentors.debian.net/package/arpwatch

Some further questions and comments follow inline below.

On Tue, 4 Apr 2017 12:29:09 +0200
Hugo Lefeuvre  wrote:

> https://git.somlen.de/arpwatch.git/ returns 403 Forbidden :)

I do not have a web based git viewer installed on my server, however
  git clone https://git.somlen.de/arpwatch.git
should work. Remember to switch to the `staged-changes` branch.

(I should probably create a page explaining that this is a git only url
instead of displaying a 403…)

> Quick review:
> 
> * lintian reports
> 
>   P: arpwatch source: source-contains-data-from-ieee-data-oui-db
> ethercodes.dat 
> 
>   but it looks like you already fixed it. If this warning is not
> relevant anymore please override it.  

Well, I did not really fix it. ethercodes.dat is still part of the
source package, it's just no longer put into the binary package. But, as
it is small and it does not violate the DFSG, Christian Seiler suggested
on debian-mentors not to repack [1].

I have not previously overridden that tag because I was not sure if it
is best practice to override lintian pediantic tags at all (only quite
few packages seem to do it) as they also don't show up on the
tracker.debian.org page. Anyways, I've now overridden the following two
pedantic tags, together with a justification as comment:
* source-contains-data-from-ieee-data-oui-db
* debian-watch-may-check-gpg-signature

> * There's no copyright entry for you

Fixed.

> Nitpicking:
> 
> in debian/changelog: why "remove dmassagevendor" ? This changelog
> entry could be more verbose.  

Right, I have a longer justification in the git history; I have expanded
on the changelog entry.

> $ cme check dpkg
> [...]
> Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is 
> actually needed. See 
> L for 
> details
> Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this
> directory is actually needed. See
> L
> for details  

If I remove `usr/sbin` from dirs, buildpackage fails complaining that
the directory does not exist (so something in the build system is
slightly broken).

`var/lib/arpwatch` is an empty directory created by the package that is
populated with ethercodes.db during postinst (and then with interface
specific database files once arpwatch is started). Should I create the
directory during postinst instead? Creating the empty directory as part
of the package seems nicer since dpkg will take care of the `rmdir` and
warn the user if the directory is not empty on uninstall.

> [...]
> Warning in 'control source Vcs-Git' value 
> 'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
> transport protocol is used for this URI. It is recommended to use a
> secure transport such as HTTPS for anonymous read-only access.
> 
> Warning in 'control source Vcs-Git' value 
> 'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
> canonical one for repositories hosted on Alioth.  

I had that on my TODO list but decided to wait and see how I get the
package sponsored before changing the Url. I've now pointed it to what I
expect to become its new home in case you are willing to sponsor the
package:
  https://anonscm.debian.org/cgit/pkg-security/arpwatch.git
  https://anonscm.debian.org/git/pkg-security/arpwatch.git
I've also adjusted debian/control to what I think it should be for team
maintenance (maintainer is pkg-security-team, added myself as uploader).

> Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 1.16.1)': 
> unnecessary versioned dependency: dpkg (>= 1.16.1).
> Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
> testing -> 1.18.23;  

Ok, I removed the pre-dependenciy.

In order to setup the file based trigger I followed man deb-triggers(5)
from dpkg-dev version 1.18.23 (most recent version in unstable) which
states:
> The “-noawait” variants are only supported since dpkg 1.16.1, and will
> lead to errors if used with an older dpkg. It is thus recommended to
> add a “Pre-Depends: dpkg (>= 1.16.1)” to any package that wish to use
> those directives.

Should I file a bug against the dpkg-dev package that this
recommendation should be dropped?


> Warning in 'copyright Format' value
> 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/':
> Format uses insecure http protocol instead of https  

Fixed.

> $ codespell *
> aclocal.m4:784: seperate  ==> separate
> aclocal.m4:787: independantly  ==> independently
> aclocal.m4:788: dependancies  ==> dependencies
> arp2ethers:8: occurance  ==> occurrence
> config.sub:1161: nto  ==> not  | disable due to \n
> debian/changelog:129: wont  ==> won't, wont
> 

Bug#858860: RFS: arpwatch [ITA]

[Hugo Lefeuvre]

Hi Lukas,

> > Gianfranco suggested also asking the pkg-security-team for possible
> > sponsors. It would be great if one of you could have a look and
> > provide guidance! If team maintenance is be possible, I'd like that
> > very much.
> 
> I think arpwatch would be a good fit for the team.  Is there somebody
> willing to review my packaging work?

This seems to be a good fit for the team, indeed.

https://git.somlen.de/arpwatch.git/ returns 403 Forbidden :)

Quick review:

* lintian reports

  P: arpwatch source: source-contains-data-from-ieee-data-oui-db ethercodes.dat 

  but it looks like you already fixed it. If this warning is not relevant
  anymore please override it.

* There's no copyright entry for you

Nitpicking:

in debian/changelog: why "remove dmassagevendor" ? This changelog entry
could be more verbose.

$ cme check dpkg
[...]
Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is actually 
needed. See 
L for details
Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this directory is 
actually needed. See 
L for details
[...]
Warning in 'control source Vcs-Git' value 
'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
transport protocol is used for this URI. It is recommended to use a
secure transport such as HTTPS for anonymous read-only access.

Warning in 'control source Vcs-Git' value 
'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
canonical one for repositories hosted on Alioth.

Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 1.16.1)': 
unnecessary versioned dependency: dpkg (>= 1.16.1).
Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
testing -> 1.18.23;

Warning in 'copyright Format' value 
'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/': Format 
uses insecure http protocol instead of https
checking data
check done

$ codespell *
aclocal.m4:784: seperate  ==> separate
aclocal.m4:787: independantly  ==> independently
aclocal.m4:788: dependancies  ==> dependencies
arp2ethers:8: occurance  ==> occurrence
config.sub:1161: nto  ==> not  | disable due to \n
debian/changelog:129: wont  ==> won't, wont
dns.c:140: cannonical  ==> canonical
WARNING: Decoding file ethercodes.dat
WARNING: using encoding=utf-8 failed.
WARNING: Trying next encoding: iso-8859-1
ethercodes.dat:785: Intruments  ==> Instruments
ethercodes.dat:838: Aircaft  ==> Aircraft
ethercodes.dat:1180: Engeneering  ==> Engineering
ethercodes.dat:2083: Internation  ==> International
ethercodes.dat:7447: MANAGMENT  ==> MANAGEMENT

Otherwise, the package looks good. I did not review everything yet,
I'll take a second look later. :)

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi security tools packaging team,

On Mon, 27 Mar 2017 23:03:19 +0200
Lukas Schwaighofer  wrote:

> Gianfranco suggested also asking the pkg-security-team for possible
> sponsors. It would be great if one of you could have a look and
> provide guidance! If team maintenance is be possible, I'd like that
> very much.

I think arpwatch would be a good fit for the team.  Is there somebody
willing to review my packaging work?

There is, of course, no rush.  I would just like to know if somebody
from pkg-security plans to look at the package eventually or if I should
start looking someplace else for reviewers/sponsors.


Thanks
Lukas


pgpTRTLJIa47G.pgp
Description: OpenPGP digital signature