Bug#838941: marked as done (RFS: duperemove/0.11~beta4-1 ITP)

[Debian Bug Tracking System]

Your message dated Sat, 24 Dec 2016 06:02:34 +0100
with message-id <20161224050234.zjxe36ie6dmha...@angband.pl>
and subject line Re: Bug#838941: RFS: duperemove/0.11~beta3-3 ITP
has caused the Debian Bug report #838941,
regarding RFS: duperemove/0.11~beta4-1 ITP
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "duperemove"

 * Package name: duperemove
   Version : 0.11~beta3-3
   Upstream Author : Mark Fasheh 
 * URL : https://github.com/markfasheh/duperemove
 * License : GPL-2, GPL-2+, BSD-2-Clause
   Section : admin

  It builds those binary packages:

duperemove - Tools for deduping file systems

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


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


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


dget -x 
https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11~beta3-3.dsc


  Regards,
  Peter Zahradnik
--- End Message ---
--- Begin Message ---
On Mon, Sep 26, 2016 at 10:12:04PM +0100, peter.zahrad...@znik.sk wrote:
>   I am looking for a sponsor for my package "duperemove"

Uploaded.

I've made a couple of changes that I should have asked you about before --
if you disagree, please revert them in -2, but only after the package has
passed NEW and into testing.

Because of the freeze's timing, this means you want to upload further
changes between Jan 05 and Jan 26.

>   It builds those binary packages:
> duperemove - Tools for deduping file systems

I've mostly rewritten the description.  There's a running joke on
#debian-devel about deduping deduplicators, thus I feel it needs to be said
that duperemove is extent- rather than file-based, can really act only on
BTRFS and XFS (and on the latter it needs a feature that's experimental in
4.9), is race free, and that deduplicated files don't suffer from hardlink
quirks.


I've also applied a patch to fix intermittent exec failures when
deduplicating executables.  The patch fixes that only for root; upstream
wants a proper fix but that relies on a kernel patch that's not yet merged
(stalled, I don't know how to make vfs guys listen... and even if we did get
it in, it's not in 4.9).


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11--- End Message ---

Bug#849193: marked as done (RFS: hoteldruid/2.2.0-1)

[Debian Bug Tracking System]

Your message dated Fri, 23 Dec 2016 22:24:22 +0100
with message-id <20161223212420.ok4m2hudpbejh...@mapreri.org>
and subject line Re: Bug#849193: RFS: hoteldruid/2.2.0-1
has caused the Debian Bug report #849193,
regarding RFS: hoteldruid/2.2.0-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
849193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849193
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hoteldruid":

* Package name: hoteldruid
  Version : 2.2.0-1
  Upstream Author : Marco M. F. De Santis
* URL : http://www.hoteldruid.com
* License : AGPLv3
  Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B

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


  http://mentors.debian.net/package/hoteldruid

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

dget -x 
http://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.2.0-1.dsc


More information about hoteldruid can be obtained from 
http://www.hoteldruid.com.


Changes since the last upload:

  * New upstream release. (Closes: #699184)
  * debian/po: include new template translations
 + pt_BR.po: Brazilian Portuguese by Adriano Rafael Gomes. (Closes: 
#839275)

  * Added /usr/share/appdata/hoteldruid.appdata.xml for hoteldruid-launcher

Regards,
Marco M. F. De Santis
--- End Message ---
--- Begin Message ---
On Fri, Dec 23, 2016 at 12:51:03PM +0100, Marco M. F. De Santis wrote:
> I am looking for a sponsor for my package "hoteldruid":

o/

> dget -x 
> http://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.2.0-1.dsc

Uploaded, thank you!

For the next upload, please consider bumping the debhelper compat level
to last available, 10.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

On Friday 23 December 2016 14:46:53 Andreas Henriksson wrote:
> Hi again Pali Rohár,
> 
> On Fri, Dec 23, 2016 at 11:29:59AM +0100, Pali Rohár wrote:
> > Now lintian on mentors shows warning:
> > 
> > package-uses-experimental-debhelper-compat-version
> > 10
> 
> Yes, lintian is simply wrong/outdated here. It's just a tool to help
> you find issues, don't blindly follow lintian like if it was
> religion or policy. Normally you'd consider a lintian override in
> cases where you have confirmed lintian is wrong, but in this case
> the warning will likely go away by itself if you just give it some
> time for new lintian releases to appear.
> 
> More importantly I wanted to mention a detail which might be useful
> to consider before uploading your package:
> 
> You use DAEMON_OPTS in the default file, while sysvinit seems to be
> standardizing on DAEMON_ARGS  to avoid the messy work of later
> migration of conffile settings you might want to consider switching
> to DAEMON_ARGS now before the first version has been uploaded. You
> decide.

Hm... Another option would be to use LLMNRD_OPTS. Looks like other 
daemons in Debian (e.g. ntpd or rsync) use env variable _OPTS in 
/etc/default/.

What do you think about it?

> FYI, I also filed issues upstream for potential systemd service
> improvements. #15, #16.
> Shipping the file is as simple as running
> "echo etc/llmnrd.service >> debian/llmnrd.install"

Yes, I know. But first we need fully working service file.

> as dh compat 10 takes care of the rest for you.
> You might want to consider dropping the attached patch in
> debian/patches/ and adding debian/patches/series containing it's
> name to preserve default file configuration under both init systems.
> 
> Regards,
> Andreas Henriksson

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Bug#832941: RFS: 4pane (debian: to exclusive)

[David Hart]

Dear Sean,

Many thanks for your further input.

>Here's another review, based on your 4pane-debian-dir repo.
>Must-fixes
>1. At least one of the files added by AddExtraM4Files.patch isn't accounted
>for in d/copyright.
//snip
>9. Lots of files in .build/ are not accounted for in d/copyright.

Thank you. I'd completely forgotten about copyright for bitmaps/ and hadn't
considered it for debian/.
Many of the bitmaps were acquired in 2004/5 and I didn't record where from.
After spending a lot of time tracing them I believe d/copyright is now correct.

>2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo.

I'd thought that repo was just for the purpose of this review. However I've
corrected that now.

>8. Further, could you confirm that, for the files in bitmaps/ and the
>images in doc/ whose preferred format for modification is not .png, the
>.xpm/.svg/whatever source is available?  I see some .xpm/.svg files but
>not for every file.  If the preferred format for modification for those
>other files is editing the .png then it's fine.

There is no other source. I confirm that if I or anyone else wished to modify
a .png, editing it would be the preferred method.

>10. .build/DONT_README (heh) explains that the Bakefile tool is required
>to regenerate the build system.  I.e. the preferred format for
>modification of the buildsystem is not by editing Makefile.in, but by
>changing some other files and running Bakefile 

No, that's the way that Makefile.in was initially created, and it would be a
convenient way to make major changes to it. But most of the time I edit
Makefile.in by hand (as I just did when removing some unused bitmaps) and for
normal building, even with dh_autoreconf, bakefile itself is irrelevant.

>(is Makefile.in the only file that Bakefile outputs?).

There are also the 3 .m4 files in AddExtraM4Files.patch, which _are_
needed for dh_autoreconf.

>As before, this is a violation of DFSG.  I think you need to package
>Bakefile for Debian, unless you can think of a way around this.

As above I don't believe that's necessary. I'd add that bakefile was created
for the wxWidgets toolkit, which uses it far more often than does 4Pane. Yet
the wxWidgets packages e.g. libwxgtk3.0-dev don't include bakefile and their
maintainers presumably don't feel that violates DFSG.

>11. You need to run dch -r to refresh the changelog timestamp so it is
>after the various changes you've made recently.

Done


>Suggestions
>---
>
>1. You might raise the debhelper compat to 10, the latest version.  That
>means you can drop '--parallel --with autoreconf' which are automatic at
>compat 10.

Done.

>2. At the top of d/rules you define various EXTRA_ env vars.  Could you
>explain further why you can't do this "the standard way"?  Would it be
>possible to make it work by patching the upstream Makefile?  Generally
>speaking, it's better to have a short d/rules and move logic into the
>upstream Makefile (otherwise someone trying to understand it has to flip
>back and forth between two files).

I see what you mean. I've now done so.

>3. In a previous e-mail I explained why I think it would be clearer to
>call the wxWindows license "GPL-2+ or wxWindows-3.1+".  So far as I can
>tell you never responded to that -- please consider the points I made.
>Unless I'm missing something, it would make d/copyright clearer.

I think I did, but anyway:
In wxWindows circles the licence is invariably referred to as the wxWindows
one, often with the explanation that it's GPL-2 plus an exception. It's also
used in the libwxgtk3.0 packages' d/copyright. However I don't have any
expertise in such things and I'm happy to change it if it's thought necessary.

>4. You should probably s/4pane/4Pane/ in 4pane.doc-base.

Done.

>5. Rather than installing 4Pane.desktop twice, you could do something
>like this:
>
>override_dh_install:
>dh_install
>( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications )

Done.

>6. It's definitely not wrong, but it might not be optimal.  What I'm
>imagining is the following situation: Debian users expect to find
>certain files (changelogs, copyright files) in /usr/share/doc/foo.
>Since 4Pane is known as '4Pane', a user might reasonably look in
>/usr/share/doc/4Pane.  But then they wouldn't be able to find the
>standard files.  For this reason, I think /usr/share/doc/4Pane should be
>a link to /usr/share/doc/4pane and 4Pane can be patched to find its help
>files there.

Done.

Regards,

David Hart

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hi again Pali Rohár,

On Fri, Dec 23, 2016 at 11:29:59AM +0100, Pali Rohár wrote:
> Now lintian on mentors shows warning:
> 
> package-uses-experimental-debhelper-compat-version
> 10

Yes, lintian is simply wrong/outdated here. It's just a tool to help you
find issues, don't blindly follow lintian like if it was religion or
policy. Normally you'd consider a lintian override in cases where you
have confirmed lintian is wrong, but in this case the warning will
likely go away by itself if you just give it some time for new lintian
releases to appear.

More importantly I wanted to mention a detail which might be useful to
consider before uploading your package:

You use DAEMON_OPTS in the default file, while sysvinit seems to be
standardizing on DAEMON_ARGS  to avoid the messy work of later
migration of conffile settings you might want to consider switching to
DAEMON_ARGS now before the first version has been uploaded. You decide.

FYI, I also filed issues upstream for potential systemd service
improvements. #15, #16.
Shipping the file is as simple as running
"echo etc/llmnrd.service >> debian/llmnrd.install"
as dh compat 10 takes care of the rest for you.
You might want to consider dropping the attached patch in
debian/patches/ and adding debian/patches/series containing it's
name to preserve default file configuration under both init systems.

Regards,
Andreas Henriksson
--- a/etc/llmnrd.service
+++ b/etc/llmnrd.service
@@ -4,7 +4,8 @@
 
 [Service]
 Type=simple
-ExecStart=/usr/sbin/llmnrd
+EnvironmentFile=-/etc/default/llmnrd
+ExecStart=/usr/sbin/llmnrd $DAEMON_OPTS $DAEMON_ARGS
 Restart=on-failure
 User=nobody
 Group=nogroup

Bug#842166: renewed sponsorship-request

[Willem Vermin]

I uploaded a new version of findent:

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

https://mentors.debian.net/debian/pool/main/f/findent/findent_2.7.3-1.dsc

The package is now build in chrooted sid.

Please have a look again.

Regards,

Willem

Bug#849193: RFS: hoteldruid/2.2.0-1

[Marco M. F. De Santis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hoteldruid":

* Package name: hoteldruid
  Version : 2.2.0-1
  Upstream Author : Marco M. F. De Santis
* URL : http://www.hoteldruid.com
* License : AGPLv3
  Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B

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


  http://mentors.debian.net/package/hoteldruid

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

dget -x 
http://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.2.0-1.dsc


More information about hoteldruid can be obtained from 
http://www.hoteldruid.com.


Changes since the last upload:

  * New upstream release. (Closes: #699184)
  * debian/po: include new template translations
 + pt_BR.po: Brazilian Portuguese by Adriano Rafael Gomes. (Closes: 
#839275)

  * Added /usr/share/appdata/hoteldruid.appdata.xml for hoteldruid-launcher

Regards,
Marco M. F. De Santis

Bug#838941: RFS: duperemove/0.11~beta3-3 ITP

[peter . zahradnik]

On 2016-12-17 22:27, Gianfranco Costamagna wrote:

Hello,

Files: interval_tree.c interval_tree_generic.h



Copyright: 2012 Michel Lespinasse 
License: GPL-2

which then below lists GPL-2 license with address: Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
However I can see that in interval_tree_generic.h itself is address:
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307  USA

What should I do?



ask upstream to fix the address :)

btw, I'm more interested in this change:
-License: GPL-2

+License: GPL-2+

at least for interval_tree_generic.h
(and add the License text too)



fixed, license text for GPL-2+ was already there
https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11~beta4-1.dsc


For xxhash.c: In file is BSD 2-Clause and I have verified it in it's
upstream https://github.com/Cyan4973/xxHash/blob/dev/LICENSE so in
opyright file I have:

Files: xxhash.h xxhash.c
Copyright: 2012-2014 Yann Collet
License: BSD-2-Clause




I can't see any issue with license for this file. Please advise


Looks good to me... Not sure what I missed!

G.


Thanks

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

On Fri, Dec 23, 2016 at 11:28:39AM +0100, Pali Rohár wrote:
> Hi! Now I uploaded new version to mentors.
> 
[...]
> So I cannot use init-d-script easily.
[...]

Thanks for following up with a good explanation for the choices
you make.

[...]
> Reasons why I did not install systemd service file:
[...]

You're ofcourse free to decide not to spend time on specific things,
but at the same time by integrating your package in a less than
optimal way with Debian you'll likely not attract as much interest
from potential sponsors.

Also, any network facing daemon really need to think about security
implications. Just running as root and not caring is in my opinion
not a good option.

Other options than using the systemd feature would be:
 * help upstream implement the privilegies dropping feature.
 * use start-stop-daemon to start under a less privilegied user.

Either way you'll need to implement the integration in your package
to create the less privilegied user. See adduser.

Not sure I'll consider this a blocker, but it's borderline for me.

Will review your new revision when I find time.

Regards,
Andreas Henriksson

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hello,

On Fri, Dec 23, 2016 at 11:18:03AM +0100, Christian Seiler wrote:
> Hi there,
> 
> sorry for the formatting, writing this on my phone.
> 
> 
> Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson 
> :
[...]
> >on upstream issue #2.
> 
> I'm not sure that'll work. In contrast to systemd services init scripts are 
> necessarily very distro-dependent. You can hack together something that's 
> cross-distro, but that's really ugly.
[...]

If only looking at major distributions Debian is likely the only one
still using init scripts. OTOH apparently upstream thinks catering
for the niche distros is important enough to file a bug report
about it against his own software. Making the debian init script
more portable could just be seen as a future improvement IMO. :P

[...]
> IMHO init scripts are distro-dependent anyway (see above). I didn't know 
> about the issues in init-d-script and since I use that in my own packages, 
> I'll look into that. Any pointers?
[...]

See existing bug reports, many contain init-d-script in title at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit

My personal opinion is that for example breaking the LSB hooks
that redirects direct /etc/init.d/foo invokations to using systemctl
(which you really, really want to do when) under running systemd is
quite unfortunate (#826214, #826215). I also find it very unfortunate
that minor bugs that goes unfixed gets worked around depending on
implementation-specific ways which means that the more people who use
init-d-script the hard it will become to ever fix it up without breaking
all users which then relies on the exact current/previous
implementation.

I've already asked about rolling back to the old skeleton but
since noone is caring for sysvinit that has just ended up in void.
When this issue was brought up with dh-make maintainers they instead
decided to just completely drop sysvinit example. :/

If needed, we should probably discuss this further elsewhere as this
is getting off-topic for the llmnrd sponsorship bug report.

Regards,
Andreas Henriksson

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Peter Pentchev]

On Thu, Dec 22, 2016 at 10:22:08PM +, Gianfranco Costamagna wrote:
> Hello
> 
> 
> 
> >I completely missed that part of the sentence, sorry. Any
> >particular reason why you prefer it that way? (To me it seems
> >logical the other way around, since the preprocessor is run
> >before the compiler. But OTOH I don't really care, so had I
> >not missed the sentence, I would have changed the order.)
> 
> 
> not sure, I usually see
> $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) foo $(LIBS)

FWIW, I've seen the reverse - CPPFLAGS before CFLAGS - in more
packages, I've always done it that way, and it does seem more
logical to me, too, for the same "the preprocessor is run first"
reason (not to mention the cases when you want to *only* run
the preprocessor, e.g. for dependency chain generation).

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

On Friday 23 December 2016 11:28:39 Pali Rohár wrote:
> > >  - debian/compat: why only 9? compat 10 is considered stable now
> > >  
> > >and unless you have a good reason I would recommend that any
> > >new package should use compat 10. (please read the debhelper
> > >manual though for information on what changed between 9 and
> > >10)
> > 
> > (compat 10 also gives you a nice automatic dh-autoreconf and
> > dh-systemd. Don't forget both to bump debian/compat and the
> > debhelper build-dependency.)
> 
> dh_make just generate template with debhelper 9.
> 
> dh-autoreconf is useless here as this package does not use any
> autoconf or automake. There is just plain Makefile.
> 
> Anyway, changed to debhelper 10.

Now lintian on mentors shows warning:

package-uses-experimental-debhelper-compat-version
10

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Pali Rohár]

Hi! Now I uploaded new version to mentors.

On Friday 23 December 2016 10:18:52 Andreas Henriksson wrote:
> Hello,
> 
> Started looking at this bug report yesterday but got discracted...
> 
> I spotted much the same issues as Chrisian so I'll instead just
> echo what he's saying and add a few comments.
> (I'll be able to sponsor you once the package is ready.)
> 
> On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
> > Hi,
> > 
> > as announced on IRC, I'm just doing a review, since I'm not a DD
> > 
> > and can't sponsor:
> >  - packaging in a VCS would be nice to have (plus the appropriate
> >  
> >Vcs-Browser / Vcs-... headers in d/control)
> >  
> >  - debian/copyright:
> >  * Tobias Klauser wasn't just active in 2016, the earliest
> >  
> >copyright notice of his I could find in the package is
> >from 2014; so s/2016/2014-2016/ there
> >  
> >  * missing mention of Copyright (C) 2012 Christoph Jaeger
> >  
> >for pkt.h
> >  
> >  * missing mention of Copyright (C) 2009-2012 Daniel
> >  
> >Borkmann for util.[ch]
> 
> The debian/copyright issue is the only major reason I seen not to
> upload right now, because this issue will possibly mean rejection
> from NEW queue. Please carefully look at all source files
> and document copyright holders (autogenerated build files can
> be excluded).

Should be fixed now.

> >  - debian/compat: why only 9? compat 10 is considered stable now
> >  
> >and unless you have a good reason I would recommend that any new
> >package should use compat 10. (please read the debhelper manual
> >though for information on what changed between 9 and 10)
> 
> (compat 10 also gives you a nice automatic dh-autoreconf and
> dh-systemd. Don't forget both to bump debian/compat and the
> debhelper build-dependency.)

dh_make just generate template with debhelper 9.

dh-autoreconf is useless here as this package does not use any autoconf 
or automake. There is just plain Makefile.

Anyway, changed to debhelper 10.

> >  - init.d: this file name works with dh_installinit, but is not
> >  
> >documented, so I'd recommend using llmnrd.init as the file name
> 
> I see you're already credited by upstream so I assume you have
> already established a good relationship with your upstream.
> That's very good and very useful. Keep your upstream happy.
> Upstreams like contributions. You have a golden opportunity
> on upstream issue #2.

Renamed to llmnrd.init.

> >  - init.d: any particular reason you don't use init-d-script? (See
> >  
> >current /etc/init.d/skeleton for how this works; it will
> >automatically source /etc/default/$scriptname and interpret the
> >DAEMON_ARGS variable, so your init script could probably be just
> >a couple of lines that set the name of the executable)
> 
> I'd recommend *against* "init-d-script". It has several outstanding
> issues, is unmaintained/orphaned/unproven and AIUI that also means
> the init script becomes debian-only.

Init script I used from old template provided by Debian and slightly 
modified it. As llmnrd does not generate pidfile, I used start-stop-
daemon with -b and -m args.

So I cannot use init-d-script easily.

Maybe I can report feature request to upstream to include support for 
creating pid file. And together with support for forking, start-stop-
daemon can be used without -b -m.

> >  - any reason you don't install the systemd service provided by
> >  
> >upstream in addition to the init script?
> 
> Please do. Please also consider improving the systemd service
> shipped by upstream. (Another golden opportunity for upstream
> contributions.)
> Most importantly have a look at the User= directive as it seems
> like running unprivilegied is preferred (see upstream issue #4).
> See also the Restrict*= directives provided by systemd which
> would also be nice to limit the potential attack surface.

Reasons why I did not install systemd service file:

1) it is not installed by make install, so I forgot about it

2) it is not fully compatible with provided init.d script

3) I'm not familiar with systemd (not even big fan)

Init.d script loads additional args from /etc/default/llmnrd DAEMON_OPTS 
and there is specified default argument -6 which enabled IPv6 support.

I hope Debian is already IPv6 ready and enabling IPv6 support is useful 
in Debian.

1) is not a problem for me, but 3) discredit me to properly handle 
DAEMON_OPTS from /etc/default/llmnrd properly.

Anyway, current init script is working fine with systemd, so missing 
systemd service file is not a problem for using llmnrd.

I would rather have IPv6 support as systemd service file.

If somebody want to improve systemd service file I will let this part...

> >  - debian/rules: nice and clean, I like it
> >  
> >  - upstream's build system does git id to get the git revision of
> >  
> >the current source - but that will clash if you have the
> >packaging in 

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Christian Seiler]

Hi there,

sorry for the formatting, writing this on my phone.


Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson 
:
>On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
>>  - init.d: this file name works with dh_installinit, but is not
>>documented, so I'd recommend using llmnrd.init as the file name
>
>I see you're already credited by upstream so I assume you have
>already established a good relationship with your upstream.
>That's very good and very useful. Keep your upstream happy.
>Upstreams like contributions. You have a golden opportunity 
>on upstream issue #2.

I'm not sure that'll work. In contrast to systemd services init scripts are 
necessarily very distro-dependent. You can hack together something that's 
cross-distro, but that's really ugly.

Also, Debian (+ derivatives) is just about the only major distro that still 
supports traditional init scripts, except for maybe Slackware: Gentoo always 
had their own thing that wasn't compatible.

RH had /etc/sysconfig instead of /etc/default and had different includes for 
helper functions, just to give an idea what differences there are. SuSE hat yet 
another include library. RH didn't support LSB headers but had similar headers 
based on chkconfig to express dependencies.

>>  - init.d: any particular reason you don't use init-d-script? (See
>>current /etc/init.d/skeleton for how this works; it will
>>automatically source /etc/default/$scriptname and interpret the
>>DAEMON_ARGS variable, so your init script could probably be just
>>a couple of lines that set the name of the executable)
>
>I'd recommend *against* "init-d-script". It has several outstanding
>issues, is unmaintained/orphaned/unproven and AIUI that also means the
>init script becomes debian-only.

IMHO init scripts are distro-dependent anyway (see above). I didn't know about 
the issues in init-d-script and since I use that in my own packages, I'll look 
into that. Any pointers?


>>  - any reason you don't install the systemd service provided by
>>upstream in addition to the init script?
>
>Please do. Please also consider improving the systemd service
>shipped by upstream. (Another golden opportunity for upstream
>contributions.)
>Most importantly have a look at the User= directive as it seems
>like running unprivilegied is preferred (see upstream issue #4).
>See also the Restrict*= directives provided by systemd which
>would also be nice to limit the potential attack surface.

Ack.

>>  - you should probably add a line "export Q =" to debian/rules to
>>disable silent builds. While these look nicer, automated build
>>log scanners such as blhc aren't able to catch problems.
>
>debhelper today automatically disables silent rules when building
>on buildds. Using Q environment variables isn't the normal thing
>though.
>Even better than to explicitly disable silent build would be to
>hook up Q to the automatic debhelper version (V=1?).


Yeah, probably do something like

ifneq($(V),1)
Q?=@
endif

instead of just

Q?=@

in upstream's Makefile.

That said: I concur that these are all minor issues that can be fixed later and 
that d/copyright is the only blocker for an upload. And if this is to go into 
Stretch, the upload needs to happen today.

Since Andreas is willing to sponsor I'd recommend fixing that issue immediately 
and after Jan. 5th when it is in Stretch to fix the rest.

Regards,
Christian

Bug#849018: marked as done (RFS: kakoune/0~2016.12.20.1.3a6167ae-1 [ITP])

[Debian Bug Tracking System]

Your message dated Fri, 23 Dec 2016 11:02:43 +0100
with message-id <20161223100243.ior3b374a6xhj...@angband.pl>
and subject line Re: Bug#849018: RFS: kakoune/0~2016.12.20.1.3a6167ae-1 [ITP]
has caused the Debian Bug report #849018,
regarding RFS: kakoune/0~2016.12.20.1.3a6167ae-1 [ITP]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
849018: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849018
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "kakoune"

* Package name: kakoune
  Version : 0~2016.12.20.1.3a6167ae-1
  Upstream Author : Maxime Coste 
* URL : http://kakoune.org/
* License : public domain
  Section : editors

It builds a single binary package that has been tested with
Lintian and sbuild:

  kakoune- Vim-inspired, selection-oriented code editor

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kakoune/kakoune_0~2016.12.20.1.3a6167ae-1.dsc

More information about kakoune can be obtained from http://kakoune.org

Thanks in advance for your time and consideration!

Regards,
 Peter Pentchev

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Wed, Dec 21, 2016 at 10:40:01PM +0200, Peter Pentchev wrote:
> * Package name: kakoune
>   Version : 0~2016.12.20.1.3a6167ae-1
> * License : public domain
> 
>   kakoune- Vim-inspired, selection-oriented code editor

Uploaded, thanks for your work.

Because of the need to complete the NEW trip before the end of Christmas
(the ftpmasters having families to attend to), I've uploaded as-is.  There
is one issue it'd be nice to fix in -2:
the README is in heavily marked-up asciidoc rather than in a human-readable
format, could you please render it as text?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11--- End Message ---

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Andreas Henriksson]

Hello,

Started looking at this bug report yesterday but got discracted...

I spotted much the same issues as Chrisian so I'll instead just
echo what he's saying and add a few comments.
(I'll be able to sponsor you once the package is ready.)

On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
> Hi,
> 
> as announced on IRC, I'm just doing a review, since I'm not a DD
> and can't sponsor:
> 
>  - packaging in a VCS would be nice to have (plus the appropriate
>Vcs-Browser / Vcs-... headers in d/control)
> 
>  - debian/copyright:
> 
>  * Tobias Klauser wasn't just active in 2016, the earliest
>copyright notice of his I could find in the package is
>from 2014; so s/2016/2014-2016/ there
> 
>  * missing mention of Copyright (C) 2012 Christoph Jaeger
>for pkt.h
> 
>  * missing mention of Copyright (C) 2009-2012 Daniel
>Borkmann for util.[ch]

The debian/copyright issue is the only major reason I seen not to
upload right now, because this issue will possibly mean rejection
from NEW queue. Please carefully look at all source files
and document copyright holders (autogenerated build files can
be excluded).


> 
>  - debian/compat: why only 9? compat 10 is considered stable now
>and unless you have a good reason I would recommend that any new
>package should use compat 10. (please read the debhelper manual
>though for information on what changed between 9 and 10)

(compat 10 also gives you a nice automatic dh-autoreconf and
dh-systemd. Don't forget both to bump debian/compat and the
debhelper build-dependency.)

> 
>  - init.d: this file name works with dh_installinit, but is not
>documented, so I'd recommend using llmnrd.init as the file name

I see you're already credited by upstream so I assume you have
already established a good relationship with your upstream.
That's very good and very useful. Keep your upstream happy.
Upstreams like contributions. You have a golden opportunity 
on upstream issue #2.

> 
>  - init.d: any particular reason you don't use init-d-script? (See
>current /etc/init.d/skeleton for how this works; it will
>automatically source /etc/default/$scriptname and interpret the
>DAEMON_ARGS variable, so your init script could probably be just
>a couple of lines that set the name of the executable)

I'd recommend *against* "init-d-script". It has several outstanding
issues, is unmaintained/orphaned/unproven and AIUI that also means the
init script becomes debian-only.

> 
>  - any reason you don't install the systemd service provided by
>upstream in addition to the init script?

Please do. Please also consider improving the systemd service
shipped by upstream. (Another golden opportunity for upstream
contributions.)
Most importantly have a look at the User= directive as it seems
like running unprivilegied is preferred (see upstream issue #4).
See also the Restrict*= directives provided by systemd which
would also be nice to limit the potential attack surface.

> 
>  - debian/rules: nice and clean, I like it
> 
>  - upstream's build system does git id to get the git revision of
>the current source - but that will clash if you have the packaging
>in git (which can happen implicitly when someone checks out the
>package source via e.g. dgit)
> 
>Minor cosmetic thing, but makes the package non-reproducible
>depending on whether you build from unpacked .dsc or from a git
>environment
> 
>  - lintian warnings:
>W: llmnrd: binary-without-manpage usr/bin/llmnr-query
>W: llmnrd: binary-without-manpage usr/sbin/llmnrd
> 
> 
>  - you should probably add a line "export Q =" to debian/rules to
>disable silent builds. While these look nicer, automated build
>log scanners such as blhc aren't able to catch problems.

debhelper today automatically disables silent rules when building
on buildds. Using Q environment variables isn't the normal thing though.
Even better than to explicitly disable silent build would be to
hook up Q to the automatic debhelper version (V=1?).


> 
>  - Building in sbuild appears to work fine.
> 
>  - Package appears to work fine (though I don't have any llmnr
>device running at the moment, so I could only test name
>resolution of my own system)
> 
> Regards,
> Christian
> 


Regards,
Andreas Henriksson

Bug#838941: RFS: duperemove/0.11~beta3-3 ITP

[Adam Borowski]

On Mon, Sep 26, 2016 at 10:12:04PM +0100, peter.zahrad...@znik.sk wrote:
>  * Package name: duperemove

Uhm guys, what's the status on this?  Unless you upload by pretty much
today, there's little chance it will get into stretch -- the effective
freeze date is in unstable (ie, past NEW) by Dec 26, and those lazy
ftpmaster guys will sit with their families instead of working on our
packages...  Shameful lack of respect for our tardiness! :p

I use duperemove a lot, it'd be sad if it didn't make it into stretch.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11