Re: Built-Using usage question

[Lukas Schwaighofer]

Hi,

On Sat, 30 Dec 2017 19:42:01 -0800
Russ Allbery  wrote:

> I don't think you need to change anything about Built-Using.  That
> seems like exactly the sort of reason anticipated by DFSG
> compliance.  The clarification in Policy is because the previous
> wording would have required literally every program in the archive
> written in C to declare Built-Using against the version of GCC used
> to build them because of the nature of libgcc, and at the request of
> the release team to not use Built-Using for library update purposes.

Thanks for clarifying, I'll leave that as is then.

> > While thinking about the above problem I noticed something else
> > which brings me to my second question:  Parts of gnu-efi are
> > covered by the BSD-3-clause license.  In order to satisfy the
> > second clause (“Redistributions in binary form must reproduce the
> > above copyright notice […]”) do I need to somehow include the
> > debian/copyright file from gnu-efi in the syslinux-efi binary
> > package?  
> 
> Yes, or at least the portions relevant to the code that's being
> statically linked.  The resulting binary is a derivative work of the
> syslinux-efi package, so you need to follow its license.

Ok, I expected as much.  Any suggestions on where to put that?
/usr/share/doc/syslinux-efi/copyright seems like the obvious place (and
is mandated by policy §12.5) but if I understand the machine readable
format correctly, it doesn't support my use-case at all (since there are
no files in the source package that can be matched).


Also this could also be a more systematic problem.  At least when
looking quickly at some of the other packages which build-depend on
gnu-efi, I couldn't see them reproducing the copyright notice in the
binary package either (I did not check thoroughly though).

Do you think it's possible to apply some sort of automated solution to
the problem?  I could think of a "built-using" support in debhelper
that will not only add the built-using header but also copy the
(complete) copyright file from the included package into the
including binary package somewhere in /usr/share/doc/$package . While
it will waste some space (and duplicate files), it will also make sure
that we correctly follow any copyright changes without requiring the
package maintainers to manually track them.

Thanks
Lukas

Built-Using usage question

[Lukas Schwaighofer]

Hi mentors,

I read the update in policy 4.1.3 and I'm not sure how to handle the
change / clarification of the Built-Using control field for the
syslinux package (which I maintain in the debian-cd team).  I have two
questions:

The syslinux-efi binary package contains parts of the gnu-efi package
due to static linking. I believe that, independent of the license
question, in order to satisfy DFSG §2 (“The program must include source
code, […]”) I need to keep using the Built-Using control field.
Especially since it's conceivable that a new version of gnu-efi breaks
compatibility with some specific efi implementation.  However, on a
technical level, I don't really see the difference between my case and
linking against glibc, which according to the debian-policy bug used to
discuss this change [1] should not use the Built-Using field.

While thinking about the above problem I noticed something else which
brings me to my second question:  Parts of gnu-efi are covered by the
BSD-3-clause license.  In order to satisfy the second clause
(“Redistributions in binary form must reproduce the above copyright
notice […]”) do I need to somehow include the debian/copyright file
from gnu-efi in the syslinux-efi binary package?  Or is it sufficient to
ensure that the archive keeps the corresponding source package, which
includes the copyright information, around?

Thank you
Lukas

[1] https://bugs.debian.org/688251

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

it seems you are getting the knack of it quickly :) .  I don't have
any additional feedback.  I hope you're able to find a sponsor soon.

You can also look at the available packaging teams [1].  For your
package it looks like the Debian Multimedia team [2] would be the most
suitable one.  I joined a packaging team for "my" first package about
half a year ago and this worked out really well for me.

All the best
Lukas

[1] https://wiki.debian.org/Teams
[2] https://wiki.debian.org/DebianMultimedia

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

thanks for the git link, makes things easier for me.

> Where did you get pragha-1.3.3.tar.gz from?
> I got it from
> https://github.com/pragha-music-player/pragha/archive/v1.3.3.tar.gz.

I got the same one (but I used `uscan -dd` to download, which uses the
debian/watch file and also renames it according to the rules in that
file).

> The files are not exactly the same, as you mentioned, but their
> contents, after extraction, are identical.

Technically I think it's sufficient if the contents is the same.
However, if you need to release a 1.3.3-2 version of pragha later, your
source package (.dsc) needs to reference (by hash) exactly the same orig
tarball you used for the 1.3.3-1 upload (see last paragraph of policy
5.6.21 [1]).

When using git and multiple computers, that means you pretty much have
to use pristine-tar anyways to satisfy this requirement, and I
personally prefer the tarball distributed with Debian to match exactly
the upstream one.

[1] https://www.debian.org/doc/debian-policy/#files

> >  If you use git and git-buildpackage, make sure to use the
> >  "pristine-tar" feature.  When using this, a small delta file will
> > be added to a special pristine-tar branch.  This allows to
> > reconstruct the original tarball exactly as it was.  
> 
> I wasn't aware of git-buildpackage, so I was making the tarball by
> hand and building with debuild.  Thanks for pointing this out.  On
> the other hand, I still do not understand how git-buildpackage
> works.  All my attempts to use it still resulted in a source tarball
> (.orig.tar.gz) that is not exactly the same as the tarball from
> upstream.

If you want to keep using git-buildpackage, I'd suggest you do the
following:

Add a file debian/gbp.conf with the following contents and commit it:
===
[DEFAULT]
pristine-tar = True
upstream-tag = upstream/v%(version)s

[buildpackage]
ignore-branch = True
===
this allows you to use the gbp commands without specifying the same
parameters over and over.  It also makes working with the repository
easier for someone else.

Then, to make use of pristine-tar, do the following from the root of
your git repository:
* Remove the orig.tar.gz from the parent directory (if present), e.g.:
  rm -f ../pragha_1.3.3.orig.tar.gz
* Re-download it from github, e.g. using your debian/watch file via
  uscan: `uscan -v -dd` (the -v is just so you see what's going on).
  If you download it manually you need to rename it.
* Now, add the pristine-tar delta files:
  pristine-tar commit ../pragha_1.3.3.orig.tar.gz

That's it (and it is only required once); if you build the package now
using git-buildpackage, it will reconstruct the original tarball
exactly as it is on github. :)


And, for the future, if you want to update to a new version of pragha
you can use `gbp import-orig --uscan`. This will use debian/watch to
download the newest version from github, update the upstream branch,
tag it, merge it with your packaging branch and also update the
pristine-tar branch.

Regards
Lukas

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

thanks for improving upon our suggestions.

On Sun, 24 Sep 2017 15:15:41 -0300
"Gabriel F. T. Gomes"  wrote:
> Lukas,
> In that same message [1], you suggested the use of a version control
> system, but I don't know where to make it public (I know that alioth
> is being discontinued, so I'm a bit lost with this).

I hope someone here will have a suggestion where your repository can
live.

> I think I solved all other problems you pointed out.

Looks like it.  I just took another look and saw a few more minor
things:

* The upstream tarball you uploaded to mentors is not exactly the same
  one as on github:

$ cmp pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz 
pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz differ: byte 5, line 1

  If you use git and git-buildpackage, make sure to use the
  "pristine-tar" feature.  When using this, a small delta file will be
  added to a special pristine-tar branch.  This allows to reconstruct
  the original tarball exactly as it was.

* In the debian/watch file you should replace "" with
  "pragha" (it also works as is, but then the downloaded tarball is
  called "-1.3.3.tar.gz" before the symlink is created).

* in debian/patches/fix-appstream-errors.patch:
  - referencing the ITP bug here does not make sense; you should only
use "Bug-Debian" if there is a bug in the Debian BTS that is
related to the patch (for example, if someone reported in the
Debian BTS that the appstream xml data is wrong)
  - Instead here you should record the URL of your pull request:

  Bug: https://github.com/pragha-music-player/pragha/pull/125


> Last but not least, I sent this message to debian-mentors (the right
> place to ask question, right?).  Please let me know if I got this
> wrong.

I think you got everything right.  The debian-mentors list will
automatically receive messages sent to the RFS bug, so there is no need
to explicitly CC it (but it doesn't hurt either).

I'm not a Debian Developer so I cannot sponsor your upload.  I hope you
find a sponsor soon!

Regards
Lukas

Re: RFS: pragha/1.3.3-3

[Lukas Schwaighofer]

Hi Gabriel,

thanks for working on packaging pragha for Debian!


First, let's get your bugs in shape:

1. Correct the metadata of the wnpp bug [1] for pragha

You should set yourself as the owner of that bug and retitle it from
RFP (request for packaging) to ITP (intent to package).  The easiest
way to do that now is to send a mail to cont...@bugs.debian.org using
the retitle and owner commands (check the reference manual [2]).  Your
wnpp bug for bash-completion [3] also needs to be adjusted.

I noticed you tried to do that already.  It's a bit confusing at the
beginning, because the bug tracking system accepts different commands
depending on whether you
* submit a new bug via sub...@bugs.debian.org,
* send information to a bug report using n...@bugs.debian.org (where NNN
  is the bug number) or
* modify a bug using cont...@bugs.debian.org
If you need help just ask.

2. Please file a new bug for the sponsorship-request

Basically you only need to re-send the last mail you sent to bug
#592985 to sub...@bugs.debian.org.  The sponsorhip request is supposed
to be a new bug and not part of the "intend to package" bug.

This is important, otherwise the nice Debian Developers who regularly
review and sponsor work from new contributors won't be aware of your
request.

[1] https://bugs.debian.org/592985
[2] https://www.debian.org/Bugs/server-control
[3] https://bugs.debian.org/876095


That's it for the bugs.  I've also taken a look at your pragha package
as uploaded to mentors and I have some feedback:

* Please use a version control system to manage your packaging work.
  This makes it a lot easier to collaborate on packages and to review
  any changes you make in the future.

* Keep the version at 1.3.3-1.  We only increase the last part of the
  version once a package has been uploaded to the archive.  Just remove
  your old uploads from the mentors web interface and re-upload your
  improved package again as version 1.3.3-1.

* You should use debhelper compatibility level to 10:
  - this allows you to drop autotools-dev (both from debian/rules and
from the Build-Dependencies in debian/control)
  - It will enable the dh-autoreconf sequence; this is a good thing but
does not work out of the box for your package because the
configure.ac file depends on autotools macros from the xfce
developer tools; to perform the autotools update using the
xfce4-dev-tools:
. add xfce4-dev-tools to the Build-Dependencies
. add the following to debian/rules
  override_dh_autoreconf:
  NOCONFIGURE=1 dh_autoreconf xdt-autogen

* The current Standards-Version is now 4.1.0.

* If you want you can get rid of some of the version constraints in the
  Build-Depends; use `cme check dpkg` to find out which ones.


I hope this helps. debian-mentors@lists.debian.org is the right place
to ask if you have questions (also for your work on bash-completion).

Regards
Lukas

Re: Bug#867147: RFS: gmrun/0.9.2-4 [ITA]

[Lukas Schwaighofer]

Hi Adam,

thanks for sponsoring.  Regarding the git repository I have a few more
requests. Please:

* point the HEAD to debian/master

cd /git/collab-maint/gmrun.git
git symbolic-ref HEAD refs/heads/debian/master

* remove the master branch
* push the tags to alioth as well (I've just pushed a signed tag for
  debian/0.9.2-3 to my repository at https://git.somlen.de/gmrun.git )

Thanks in advance
Lukas

Bug#867147: RFS: gmrun/0.9.2-3 [ITA]

[Lukas Schwaighofer]

Control: retitle -1 RFS: gmrun/0.9.2-3 [ITA]

My last commit accidentally increased the Debian version, corrected.


pgpno1f7qLX5W.pgp
Description: OpenPGP digital signature

Bug#867147: RFS: gmrun/0.9.2-4 [ITA]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for the gmrun package, which I intend to
adopt. I've uploaded the current state to mentors:
  https://mentors.debian.net/package/gmrun

I've done the packaging using git.  You can access my repository from
  https://git.somlen.de/gmrun.git
and checkout the debian/master branch.  The above URL is git only, I
don't have a web-based git viewer installed on my server.

I would prefer to host the repository on collab-maint and I have
already set the Vcs-* control fields accordingly.  I hope my sponsor
can either push it there on my behalf or help me get access myself.

Thanks & Regards
Lukas


pgpH2qR13Zm4F.pgp
Description: OpenPGP digital signature

Re: copyright for debian/* files, collab-maint access

[Lukas Schwaighofer]

On Tue, 4 Jul 2017 04:04:24 +0200
Adam Borowski  wrote:

> As the original maintainer declared the license as GPL-2 (only), it
> seems obvious to me this applies to the packaging as well.  I'd thus
> not even bother contacting him and assume everything uses that
> license.

Ok, thanks for looking into this.

Regards
Lukas

copyright for debian/* files, collab-maint access

[Lukas Schwaighofer]

Hi mentors,

I declared my ITA gmrun and I have two questions:

1. The current debian/copyright is written in a way that it does not
   apply to the debian/* files.  So, as far as I can tell, the previous
   maintainers have not stated under which license they make their work
   available.  Should I try to reach the main contributors and ask them
   if they agree to a specific license or is there a better (easier)
   way to resolve this?  Is there a recommended license for these files?

2. I would like to use a git repository in collab-maint for hosting.
   Is it possible to get access?  I am a member of the pkg-security
   team and I've used git on alioth before, my username is ls-guest and
   I've made the request to join online.

Thanks in advance
Lukas


pgpDuhPxLE2NF.pgp
Description: OpenPGP digital signature

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]

[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]

[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]

[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]

[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
> dns.c:140: cannon

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

Bug#858860: RFS: arpwatch/2.1a15-3 [ITA]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

thanks for the help you have provided so far. I am now officially
looking for a sponsor for the arpwatch package, which I intend to
adopt. I've uploaded my current packaging work to mentors:
  https://mentors.debian.net/package/arpwatch

I've done the work in git. If you want to look at the git history,
you can clone the repository from
  https://git.somlen.de/arpwatch.git
and checkout the staged-changes branch. (I have not yet tagged the
Debian version because I'm quite sure there will be some iterations
before we can actually release…)

If possible I would like to keep the "official" packaging git (Vcs-Git)
on collab-maint; I suppose once I find a sponsor, she or he can push
there for me?


Because of the changes I have made to for native systemd
integration, the upgrade needs a few manual steps (documented in
NEWS). I would be happy if someone has ideas how to avoid that.


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.


Regards
Lukas Schwaighofer


pgpH01jbg9wPv.pgp
Description: OpenPGP digital signature

Re: ethercodes.dat / oui.txt (Was: Re: arpwatch & systemd)

[Lukas Schwaighofer]

Hi Christian,

thanks for suggesting the file based triggers, hadn't thought of that.
Combining that with the hook into update-ieee-data should indeed works
fine and is much better than doing stuff on service startup.

On Mon, 27 Mar 2017 11:06:47 +0200
Christian Seiler  wrote:
> On 03/27/2017 12:24 AM, Lukas Schwaighofer wrote:
> > The easiest way for me to check if the converted database is
> > up-to-date is to depend on the existence
> > of /var/lib/ieee-data/.lastupdate . Is that ok?  
> 
> As far as I understand it, yes.
> 
> That said: what do you consider outdated? I've never checked how
> often the OUI database changes, but as far as I can tell the
> updates happen as needed, not according to a specific schedule.
> That means that if nobody requested an update, the database is
> not out of date, even if it's old.
> 
> What you could do is check the .lastupdate file only if a lookup
> fails - and if it's older than a week, display a message. But
> that would require direct patching of arpwatch, so the much
> simpler solution could be to just add an entry to README.Debian
> that tells the user to run update-ieee-data if they want to
> have an updated database. Currently the database isn't udpated at
> all, so this is already going to be an improvement.

I should have been more explicit in my question. My idea was to
copy /var/lib/ieee-data/.lastupdate into /var/lib/arpwatch/.lastupdate
so I can use `cmp` to see if I need to update.

However that would have only been necessary when creating the database
during init. Since, with your help, I was able to implement this more
elegantly, this is no longer relevant.

Regards
Lukas

Re: Problems with autoconf in pftools

[Lukas Schwaighofer]

Hi,

On Mon, 27 Mar 2017 14:04:01 +0200
Andreas Tille  wrote:

> I try to package pftools[1].  Unfortunately autoreconf throws the
> following error:
> 
>dh_autoreconf -O--no-parallel
> configure.ac:6: error: possibly undefined macro: AC_MSG_NOTICE
>   If this token and others are legitimate, please use
> m4_pattern_allow. See the Autoconf documentation.
> configure.ac:51: error: possibly undefined macro: AC_SUBST
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: autoreconf -f -i returned exit code 1
> debian/rules:8: recipe for target 'build' failed
> 
> 
> Websearches resulted in adding pkg-config to Build-Depends but I
> admit I do not understand why this should help to find macros that
> are in autoconf doc - and it actually does not help.  Any other hints
> to get this working?

configure.ac uses the AX_PTHREAD macro, you need to build depend on
autoconf-archive (which contains /usr/share/aclocal/ax_pthread.m4).

Btw, brackets in lines 98-101 of configure.ac, where AX_PTHREAD is used,
look really wrong (though I'm not an autoconf expert).

Regards
Lukas


pgpg_GMJq13YK.pgp
Description: OpenPGP digital signature

ethercodes.dat / oui.txt (Was: Re: arpwatch & systemd)

[Lukas Schwaighofer]

Hi,

On Sun, 26 Mar 2017
22:30:39 +0200 Christian Seiler  wrote:

> On 03/26/2017 09:19 PM, Lukas Schwaighofer wrote:
> > I'm not sure I understand what you mean… should the ethercodes.dat
> > file be removed / used from a different package?  
> 
> Yes. See also:
> https://lintian.debian.org/tags/source-contains-data-from-ieee-data-oui-db.html
> 
> ieee-data also contains a script that allows the admin to
> update the listing manually, and other packages can hook into
> that update process if that's required.

thanks for clarifying.

I need to convert the oui.txt database to a different format (the script
to do that is already available). Two options come to my mind:

1. use the maintainer scripts (postinst?) to generate the initial
   version of the converted database, add a hook for ieee-data to keep
   it updated
2. check if the database is up to date when the arpwatch service is
   started by the init system, update it otherwise

Option 1 seems somewhat cleaner, but if I understand the mechanisms
correctly, this will only trigger when the admin (or a cron job) calls
`update-ieee-data`, and not if the ieee-data package gets updated.

Since that would allow the converted database to become outdated, that
leaves me with option 2.  Is that acceptable or is there a better way
to do it?

The easiest way for me to check if the converted database is up-to-date
is to depend on the existence of /var/lib/ieee-data/.lastupdate . Is
that ok?

> Repacking the source seems excessive to me though, since the
> database is under a DFSG-compatible license (ieee-data is in
> main), but the binary package should probably just depend on
> ieee-data. (Or recommend it, if it can live with the file not
> being available.)

Ok, thanks.

Regards
Lukas


pgp7GCBgdj4at.pgp
Description: OpenPGP digital signature

Re: arpwatch & systemd

[Lukas Schwaighofer]

Hi Bastien,

On Fri, 24 Mar 2017 10:56:58 +
Bastien Roucaries  wrote:

> Will ne also nice to repack in ordre to remove oui db

I'm not sure I understand what you mean… should the ethercodes.dat file
be removed / used from a different package?

Thanks
Lukas


pgpQfsxdY1uIw.pgp
Description: OpenPGP digital signature

Re: arpwatch & systemd

[Lukas Schwaighofer]

Hi,

thanks Vincent and Gianfranco for offering your advice!

On Wed, 22 Mar 2017 23:13:52 + (UTC)
Gianfranco Costamagna  wrote:
> did you consider to merge the work from Fedora?
> they already have a systemd service, and IIRC the project seems
> somewhat dead upstream, so merging their work and sending them
> patches might be beneficial for both distros. Please try to have a
> similar working tool, rather than diverging too much, specially when
> upstream is not active anymore.

Well, I had looked at systemd unit files for arpwatch using web search.
Most of the unit files I found only allow starting one instance of
arpwatch. This is also true for the unit file included in Fedora. At
least openSUSE has a systemd service file which allows launching
multiple instances of arpwatch, but it does not allow different
configurations for the individual interfaces (which our current LSB
init script is capable of).

I would like to avoid a situation where upgrading to the new version
requires writing systemd unit files, so we need to keep the ability to
have multiple instances of arpwatch which can be configured differently.


I think calling the project "somewhat dead" is an understatement after
7+ years of inactivity.  This is a long time and different distros have
accumulated different patches. There also used to be an arpwatch-ng
fork, which is now also dead.  Debian's patches introduce quite a bit
of functionality to arpwatch as well.

Now directly comparing Fedora and Debian, the arpwatch binaries are
pretty different (the introduced patches add different feature, newly
introduced arguments are conflicting, e.g. '-s', …).

While I agree that a strong cooperation between the distros, especially
for packages with dead upstream, would be mutually beneficial, it is
hard to start doing that after the packages have diverted so much.

> I don't think you want people having issues when switching from
> Fedora to Debian and vice-versa, specially with systemd configuration
> files :)

Unless we want to drop some features available using our current LSB
init script (thereby forcing some admins to write their own systemd
unit files just to keep their current arpwatch setup), I don't think
incompatibilities can be avoided.

> (as pkg-security team we might have some interests in having the
> package under our team, so you might find sponsors asking us to
> review your work!)

Good to know, I will X-Debbugs-CC pkg-security once I file an RFS bug.
Team maintenance would be really nice :) .

Regards
Lukas


pgpySc0mm2DJ8.pgp
Description: OpenPGP digital signature

arpwatch & systemd

[Lukas Schwaighofer]

Hi mentors,

[I'm on list]

since I'm using arpwatch and it has been orphaned for a while now, I am
thinking about adopting this package.  I've started picking a few
easy enough bugs in the BTS and fixed them.  Before I'm ready to
officially declare my intent I wanted some advice in particular on
supplying systemd unit files for this package (other feedback is
welcome as well of course).


The current LSB init script checks /etc/arpwatch.conf for lines
matching '^[a-z]'.
* If there are any, it uses a multi instance mode using information
  from this configuration file to add additional parameters (in
  addition to what is read from /etc/default/arpwatch) as command
  arguments (which may be different for the interfaces)
* If there are no such lines, it will just use the parameters
  from /etc/default/arpwatch to start one instance of arpwatch.

Note that /etc/arpwatch.conf is not a "usual" configuration file in that
it is never read by arpwatch but only by the init system to construct
the arguments to be passed to arpwatch when executing.


Thoughts on about how to provide a systemd unit file (inspired a lot by
how openvpn handles multiple instances):
* I want the processes for different interfaces supervised individually
  by systemd; the only way how to do this I know about is to supply
  a template unit file (arpwatch@.service) which can be
  instanciated with an instance name (which will in my case be an
  interface name).
* I want to keep supporting different parameters for the different
  instances; the easiest way to support this seems to be using the
  EnvironmentFile directive, with allows to use the contents of the
  variables when invoking arpwatch; however, this means I need a
  separate configuration file for each interface.
* I do not consider starting arpwatch without the `-i` parameter to
  specify an interface useful (it uses pcap_lookupdev in that case,
  which allows you to find "the default" device on which to capture,
  for whatever that means). I think that people running arpwatch
  should have an opinion on which network interface arpwatch should run
  on.


So what I have done is:
* I've dropped the "one instance" mode as I always want to have the
  interface(s) specified, even if it's only one.
* I've converted /etc/arpwatch.conf to individual configuration files
  in /etc/arpwatch/IFNAME.iface which have a shell source-able syntax
  (I've adjusted the LSB init script accordingly) and can be used with
  systemd's EnvironmentFile= directive.
* Consequently there is no /etc/arpwatch.conf any more, I removed it.
* As I don't know which interface the admin is going to use, I cannot
  provide a "default" configuration file with helpful comments. As a
  current workaround I have created an /etc/arpwatch/README file which
  briefly explains the interface configuration.
* I've added an INTERFACES= variable to /etc/default/arpwatch:
  - This allows specifying which interfaces to run on, but is only used
by the LSB init script and ignored by systemd.
  - For systemd I expect the administrators to explicitly enable and
start the instantiated unit files using systemctl; alternatively
we could write a generator for systemd, similar to what openvpn
does, to activate all the instances specified in INTERFACES.


I would like advice on the concept itself: Is it ok or should a take a
different approach? Can someone point me to a package that handles a
similar service startup situation differently (better)?

Other than that I'm quite concerned about the upgrade path:
* I do remove /etc/arpwatch.conf from the package (but this will of
  course stay in the filesystem); converting this into individual files
  in /etc/arpwatch/IFNAME.iface in a maintainer script would be
  possible…
* I have a README file in /etc/arpwatch/ which is not a configuration
  file. Is there a better solution and, if not, would this be
  acceptable?
* After the upgrade, the service has to be explicitly activated for the
  interfaces it should be started on, even if the service was
  previously running (again, could be handled in a maintainer script
  at least for some cases, but is not easy to do considering how the
  different init systems need a different form of activation)
* In any case I do not think that we can offer a seamless upgrade path
  for all cases.


Sorry for the wall of text. You can find the current status in the
following git repository in the *staged-changes* branch (this is
work-in-progress and will see force commits):
https://git.somlen.de/arpwatch.git

Thank you
Lukas Schwaighofer


pgpnkBKMlxwpQ.pgp
Description: OpenPGP digital signature

Bug#857856: RFS: gmrun/0.9.2-2.2 [RC, NMU]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "gmrun".

* Package name: gmrun
  Version : 0.9.2-2.2
  Upstream Author : Mihai Bazon 
* URL : https://sourceforge.net/projects/gmrun/
* License : GPLv2
  Section : x11

It builds those binary packages:

  gmrun - Featureful CLI-like GTK+ application launcher

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/gmrun


Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gmrun/gmrun_0.9.2-2.2.dsc


The automatic update ("recompiled with PIC") broke the package (because
of API changes in gtk2, it now only produces sgementation faults). The
uploaded package includes the patch extracted from the Fedora project
(provided by Andreas Henriksson) to fix the issue.

There was some discussion if there should be more changes to the package
(standads version, debhelper compatibility level, additional hardening
options) in 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857065
and we basically agreed to only fix the RC bug and make further changes
to the package in buster (and possibly experimental) only.


Thank you
Lukas Schwaighofer


pgp8T5mHeZ7nS.pgp
Description: OpenPGP digital signature