Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

Hi Mentors,

I've pushed a new build onto mentors.debian.net that should resolve most of the 
aforementioned issues.
Can someone give it another look?

Thanks!
Weilu

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

> > > d/rules:
> > > - why -D_FORTIFY_SOURCE=1? Such things should be documented
> > 
> > For security reasons, as this is an internet accessible daemon that
> > accepts user input. 
> What I've meant was "you replaced stronger default flag with a weaker
> one". As you know about dpkg-buildflags you should know that the 'fortify'
> option is enabled by default and that it adds -D_FORTIFY_SOURCE=2.

Didn't know that D_FORTIFY_SOURCE=2 was the default. Based on the manpage,
D_F_S=2 can break some programs, while D_F_S=1 should not. Given that there's
no real comprehensive tests, for iroffer-dinoex, I felt it was safer to set it
to 1 rather than 2.

> > It also gets rid of the lintian info tag
> > "hardening-no-fortify-functions". 
> If you have this tag then something is wrong. If it's also fixed by adding
> -D_FORTIFY_SOURCE to CFLAGS then your upstream build system doesn't handle
> CPPFLAGS correctly. It should be fixed to handle them.

Until it's fixed upstream what is the "correct" way of getting it to compile
with -D_FORTIFY_SOURCE?
I've patched the configure script to accept external CPPFLAGS in the meantime.

> > > - you can probably replace override_dh_auto_clean with debian/clean
> > 
> > I can't seem to find any documentation regarding debian/clean in the
> > maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
> > How is debian/clean supposed to be used?
> man dh_clean
> To remove files not removed by dh_auto_clean.

How handy. I've fixed the build to use debian/clean.
How do I get that documented in the maint-guide?

> > > - why this package not only Conflicts but Replaces iroffer? Do you know
> > >   how will apt handle this relationship? Do you intend to do anything with
> > >   the iroffer package itself (it's orphaned ATM)? If you want to replace
> > >   it completely then the replacing procedure is different, see
> > >   https://wiki.debian.org/Renaming_a_Package
> > 
> > iroffer-dinoex is intended to be a drop-in replacement for the original
> > iroffer. The binaries have the same name, and the config formats are
> > unchanged.
> > Based on what I could tell from the docs (correct me if I'm wrong)
> > [www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
> > this is the correct way to have a package be an alternative drop in
> > replacement (ie how MTA's are managed).
> > I do not intend to take over the iroffer package completely. This is merely
> > an alternative to the original iroffer that can be a drop in
> > upgrade/replacement.
> Just Conflicts could be enough but it won't uninstall the other package.
> I don't know how Conflicts+Replaces will work, you'll need to test this.
> Note that you still won't be able to install iroffer without manually
> removing iroffer-dinoex (at least that's what I think).

What you described is what I intended the functionality to be. iroffer-dinoex
should be able to be installed _over_ iroffer (apt will remove the old package
automatically)
  % sudo dpkg -i iroffer-dinoex_3.30-1_amd64.deb
  Selecting previously unselected package iroffer-dinoex.
  dpkg: considering removing iroffer in favour of iroffer-dinoex ...
  dpkg: yes, will remove iroffer in favour of iroffer-dinoex
If you install iroffer over iroffer-dinoex, apt will prompt to remove
iroffer-dinoex before installing iroffer.

If this seems too far off what the norm is, I'm fine with removing the Replaces,
but based on the docs and my testing, this should be fine.

> > > d/copyright:
> > > - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
> > >   option) any later version" in the texts
> > I assumed "or (at your option) any later version" meant that the upstream
> > author could (at their discretion) upgrade the license to a newer version
> > of GPL.
> > Not that an end-user (me) could upgrade to a newer version at my 
> > descretion. I'm not a lawyer, so I chose to leave it untouched.
> You seem to be confusing several things here.
> The upstream authors can do anything they want but the license clauses say
> what can other people do instead.
> "License: GPL-2" means "you can use GPL 2", "License: GPL-2+" means "you
> can use GPL 2 or (at your option) any later version".
> And the upstream LICENSE doesn't say about "any later version", so you
> didn't "leave it untouched".
> Actually, the upstream LICENSE includes the OpenSSL linking exception for
> some files and tells to look into the files to find out which of them have
> what licenses so your d/copyright should be more fine-grained than now.
> 
> > > - using GPL for debian/ while having MIT and LGPL in the upstream source
> > >   is discouraged and may cause problems if debian/ contains e.g. patches
> > What's the correct way to resolve this, choose a less restrictive license
> > for debian/? 
> Yes.

Fixed. Changed the license to BSD-3-clause.

> > no-upstream-changelog should be an I tag.
> Why do you think so?

That was my mistake. I got it mixed up with some other tags.
 
> > > - 

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

>> iroffer-dinoex.lintian-overrides:
>> - you shouldn't override P tags

>Which P tag did I override? no-upstream-changelog should be an I tag.
Sorry, I looked again and you're right. no-upstream-changelog is a P tag.
I've removed the override.

Regards,
 Weilu

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

Hi Andrey,

Thanks for looking over this. I've replied to your concerns in line and
created a new build which (hopefully) addresses most of them.

> d/rules:
> - why -D_FORTIFY_SOURCE=1? Such things should be documented

For security reasons, as this is an internet accessible daemon that
accepts user input. It also gets rid of the lintian info tag
"hardening-no-fortify-functions". The docs for D_FORTIFY_SOURCE state it
won't break anything (compared to D_F_S=2). From my own testing, there's
no issues with the binary.
I've added a comment, and documented in Readme.debian (That is the
correct place to document, right?)

> - commented out -Wl,--as-needed looks strange, if it doesn't work/isn't
>   needed you shouldn't include this line at all
> - "dh_make generated override targets" sounds strange. "This is example
>   for Cmake (See https://bugs.debian.org/641051 )" sounds even strange,
>   especially when looking at that bug. That commented out
>   dh_auto_configure is strange too, especially the -DCMAKE_LIBRARY_PATH
>   part.

These are all comments that came from the debian/rules template from
using dh_make (which is why they make no sense). I've removed them in the
latest build.

> - you can probably replace override_dh_auto_clean with debian/clean

I can't seem to find any documentation regarding debian/clean in the
maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
How is debian/clean supposed to be used?

> README.source even says "You WILL either need to modify or delete this
>   file"

Oops. Removed.

> d/control:
> - commented out Vcs-* fields should be either removed or uncommented and
>   edited

Removed in the latest build.

> - why this package not only Conflicts but Replaces iroffer? Do you know
>   how will apt handle this relationship? Do you intend to do anything with
>   the iroffer package itself (it's orphaned ATM)? If you want to replace
>   it completely then the replacing procedure is different, see
>   https://wiki.debian.org/Renaming_a_Package

iroffer-dinoex is intended to be a drop-in replacement for the original
iroffer. The binaries have the same name, and the config formats are
unchanged.
Based on what I could tell from the docs (correct me if I'm wrong)
[www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
this is the correct way to have a package be an alternative drop in
replacement (ie how MTA's are managed).
I do not intend to take over the iroffer package completely. This is merely
an alternative to the original iroffer that can be a drop in
upgrade/replacement.

> d/copyright:
> - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
>   option) any later version" in the texts

I assumed "or (at your option) any later version" meant that the upstream
author could (at their discretion) upgrade the license to a newer version
of GPL. Not that an end-user (me) could upgrade to a newer version at my 
descretion. I'm not a lawyer, so I chose to leave it untouched.

> - using GPL for debian/ while having MIT and LGPL in the upstream source
>   is discouraged and may cause problems if debian/ contains e.g. patches

What's the correct way to resolve this, choose a less restrictive license
for debian/? Is there a list of recommended licenses?

> d/install is empty

Oops. I had used it for something prior and forgot to remove it.
Removed in the latest build.

> iroffer-dinoex.lintian-overrides:
> - you shouldn't override P tags

Which P tag did I override? no-upstream-changelog should be an I tag.

> - manpage-has-bad-whatis-entry override says "Upstream manpage" which
>   doesn't sound like a valid cause to me

Should I just leave the lintian warning as-is until it's fixed upstream?
Or should I be patching the manpage until it's fixed upstream?

Thanks,
 Weilu

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "iroffer-dinoex"

 Package name: iroffer-dinoex
 Version : 3.30-1
 Upstream Author : Dirk Meyer
 URL : http://iroffer.dinoex.net
 License : GPL-2
 Section : net

It builds those binary packages:

  iroffer-dinoex - IRC file distribution bot

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

https://mentors.debian.net/package/iroffer-dinoex


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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/iroffer-dinoex/iroffer-dinoex_3.30-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

  iroffer-dinoex (3.30-1) unstable; urgency=medium

* Initial release (Closes: #580686)

   -- Weilu Jia   Fri, 20 May 2016 04:40:05 +


Regards,
 Weilu Jia