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]

[Andrey Rahmatullin]

On Sat, May 21, 2016 at 02:02:49PM -0700, optix2...@teitoku.net wrote:
> > 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.

> 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.

> > - 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.

> > - 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).

> > 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.

> Is there a list of recommended licenses?
I think the currently recommended simple non-copyleft license (fir
anything, not just debian/) is Expat.

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

> > - 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?
The second option is preferable, note that the tag is W.
But the first one is better than overriding it (you should override only
things that are not problems, not things that are currently
hard/impossible to fix problems)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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]

[Andrey Rahmatullin]

(Note that I don't intend to sponsor this package)

d/rules:
- why -D_FORTIFY_SOURCE=1? Such things should be documented
- commented out -Wl,--as-needed looks strange, if it doesn't work/isn't
  needed you shouldn't include this line at all
- you can probably replace override_dh_auto_clean with debian/clean
- "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.

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

d/control:
- commented out Vcs-* fields should be either removed or uncommented and
  edited
- 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

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

d/install is empty

iroffer-dinoex.lintian-overrides:
- you shouldn't override P tags
- manpage-has-bad-whatis-entry override says "Upstream manpage" which
  doesn't sound like a valid cause to me

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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