Re: a few questions on ITP shadowsocks-libev before formal RFS

[Roger Shimizu <rogershimizu@gmail.com>]

[Add Max and Boyuan from upstream to CC]

Thanks Gianfranco and Jakub!

I comment when I still have question, for other parts I'll follow your
suggestion.

On Wed, May 18, 2016 at 7:13 PM, Jakub Wilk <jwilk@debian.org> wrote:
> * Roger Shimizu <rogershimizu@gmail.com>, 2016-05-18, 02:14:
>>
>> Some questions/issues that I'm not sure:
>> - Upstream maintained debian/ folder long before, I'm going to keep the
>> original debian/changelog. So I should also keep the upstream as maintainer,
>> and add myself as the uploader?
>
> It doesn't matter who maintained the package in the package. What matters is
> who is going to maintain it now for Debian. Did you ask upstream to
> co-maintain it with you? You certainly shouldn't put anyone to
> Maintainer/Uploaders without their consent.

I contacted the upstream (now they're in CC), and they're happy to
co-maintain this with me.
BTW. I have a few packages uploaded by sponsorship, but I have no
experience on collab-maint.
I'm not sure whether I can ask you to help to set up a repo on
alioth/collab-maint for us?
If so, here's our alioth account: rosh-guest, hosiet-guest, madeye-guest.
Thank you!

>> - The package is mainly GPLv3, but it links to OpenSSL library, is that
>> OK?
>
> GPL+OpenSSL is no-no.
>
> README says that mbedtls, which is GPL-compatible, can be used as an
> alternative to OpenSSL, so you should try it.

Yes, it seems I have to try it anyway.

>> - Upstream repo includes library source code of libev, libsodium, libudns.
>> Is it OK to keep as it is, or have to remove and make another source
>> tarball?
>
> As long as they are DFSG-free, you can keep them in the source package. Just
> make sure they are not used at build time. This is best achieved by "rm
> -rf"ing them early in the build process. (If you're using dh, then beginning
> of override_dh_auto_build is probably the best place.)

This works well. Thank you!

>> - I have no idea on the following lintian error, because postrm/postinst
>> scripts are generated by dh
>>
>> ====
>> E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>> etc/init.d/shadowsocks-libev-local
>
>
> This seems to be caused by passing --no-start to dh_installinit:
>
>         dh_installinit --no-start --name=shadowsocks-libev-server@
>         dh_installinit --no-start --name=shadowsocks-libev-tunnel@
>         dh_installinit --no-start --name=shadowsocks-libev-redir@
>         dh_installinit --no-start --name=shadowsocks-libev-local@
>
> My initsystem-fu is too weak to tell whether it's a d/rules bug, debhelper
> bug, or Lintian bug, or just something that should be overridden.

Upstream came to help.
After remove the above block (only to use the default debhelper), now
lintian is happy on everything.


On Wed, May 18, 2016 at 4:05 PM, Gianfranco Costamagna
<locutusofborg@debian.org> wrote:
>
>>- Upstream repo includes library source code of libev, libsodium,>libudns. Is it OK to keep as it is, or have to remove and make another
>>source tarball?
>
> as long as you don't use them it is fine, please try to package them separately
> and use the system versions, not bundled code

Is this (package the libraries separately) required? or something can
be done afterwards?

> BTW the copyright file has to list them, so there is a tradeoff between removing files to
> have a more readable /easy to maintain copyright file and tarball, and having a pristine tarball from
> upstream.
>
>>- The answer of above question may affect: whether I should remove>copyright of library libev, libsodium, libudns from debian/copyright?
>
> oops answered above :)
> (BTW a repack done not because of non-dfsg files is a "ds" aka Debian Source repack)

I see source of some packages are repacked as -dfsg, but I didn't find
how to do "ds" repack.
It would be helpful if there's a wiki entry or manual.

Thanks again for your helpful advice!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1