Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-07-02 Thread Roger Shimizu
Control: retitle -1 RFS: shadowsocks-libev/2.4.7+20160630+ds-1 [ITP]

Dear G,

On Thu, Jun 30, 2016 at 4:00 PM, Gianfranco Costamagna
 wrote:
>
>>Way 1:
>>Since all manpages is created by Max (co-maintainer of this package,
>>and in CC list), we can ask him to relicense, according to [2]
>>
>>[2] https://wiki.debian.org/qa.debian.org/gfdlinvariant
>>
>>I think Way 1 is better.
>>What do you think?
>
>
> +1 for way 1!

Thanks for your recommend!
I sent PR to upstream to change the license, and it's acceepted.

So I re-package the latest upstream, with the changes below:
- update version
- add license info under man/ folder
- add lintian-overrides (2 false positive)

Uploaded to mentors, and source code to github:
  https://github.com/rogers0/shadowsocks-libev

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-30 Thread Gianfranco Costamagna
Hi,

>However, ftp-master rejected the upload, I reopen this ticket.
>I'm sorry that I miss-checked the license under man/ folder.
>
>I search GFDL, and find [0][1]
>
>[0] https://www.debian.org/vote/2006/vote_001
>[1] https://wiki.debian.org/DFSGLicenses
>
>So if my understanding is correct, I think there're 2 ways to solve
>this license issue.
>
>Way 0:
>Put manpages to a new created -doc package, which we can put in non-free


:(

>Way 1:
>Since all manpages is created by Max (co-maintainer of this package,
>and in CC list), we can ask him to relicense, according to [2]
>
>[2] https://wiki.debian.org/qa.debian.org/gfdlinvariant
>
>I think Way 1 is better.
>What do you think?


+1 for way 1!

Gianfranco



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-30 Thread Roger Shimizu
Control: reopen -1

Dear G,

Thanks for your upload!

However, ftp-master rejected the upload, I reopen this ticket.
I'm sorry that I miss-checked the license under man/ folder.

I search GFDL, and find [0][1]

[0] https://www.debian.org/vote/2006/vote_001
[1] https://wiki.debian.org/DFSGLicenses

So if my understanding is correct, I think there're 2 ways to solve
this license issue.

Way 0:
Put manpages to a new created -doc package, which we can put in non-free

Way 1:
Since all manpages is created by Max (co-maintainer of this package,
and in CC list), we can ask him to relicense, according to [2]

[2] https://wiki.debian.org/qa.debian.org/gfdlinvariant

I think Way 1 is better.
What do you think?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-25 Thread Roger Shimizu
Dear G,

Here's a slightly updated version, with my comment.
(pkg already uploaded to mentors)

On Mon, Jun 20, 2016 at 10:17 PM, Gianfranco Costamagna
 wrote:
>
>>>It's runtime config file, which will be installed to: etc/shadowsocks-libev
>>
>> not sure about hardcoding passwords that way... maybe generate them at 
>> install
>> time with apg or similar?
>> (postinst or similar)
>>
>> I don't want all the userbase to have the same tool with the same default 
>> password.
>
>>Done.
>>Add postinst script to handle this.
>
>
>>I like that solution!
>
>
> but shouldn't this be executed only during install?
> the place where you put suggests the code will be executed and re-executed 
> during all
> the calls (configure deconfigure abort upgrade and so on)
>
> I would do it in configure, and don't care about the upgrade, because even 
> re-running
> it will be a no-op (unless apg generates the same "barfoo!" password :) )
> LOL, in that case it will be changed during an apt-get {dist-}upgrade :)

It's my intention, to do it when upgrading/reinstall.
Because before this ITP/RFS, user may already build deb themselves,
and have this fixed passwd on system.
Here I want to make sure the fixed passwd will be gone.


>>Hope you cannot find a nitpick this time :-P
>
> there is always something to nitpick :)
>
> e.g.
> https://mentors.debian.net/package/shadowsocks-libev
> "W debian-watch-file-should-mangle-version
> line 7"
>
> what does it mean?
> I admit I didn't investigate it

It means false positive and a lintian bug: https://bugs.debian.org/505857#40

Besides your request, I have some other changes:
- upgrade to compat 10
- remove autoreconf setting in d/rules, because compat 10 already enables this
- use library libcorkipset (instead of libredjackipset)
- update patch, also use library libcorkipset
- update "Homepage" in d/control to use "https"

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-20 Thread Gianfranco Costamagna
Hi Roger

>Packaging another library (libipset) just takes some time.


I can understand that, and my review will probably take some more time :)
>Technically yes, but since it's a quite old version, I think nobody would do 
>it.
>And currently "shadowsocks" is a python program in Debian archive, we don't 
>recommend to install the old C-written shadowsocks.


wonderful

>So I packaged it and filed ITP#827080 / RFS#827082.>Hope you can also sponsor 
>it.


sure, and I reviewed it

>Thanks for your detailed tips!>I just remove the text after "-delete", others 
>are just as what you said.
>Works fantastic!


:)

>>It's runtime config file, which will be installed to: etc/shadowsocks-libev
>
> not sure about hardcoding passwords that way... maybe generate them at install
> time with apg or similar?
> (postinst or similar)
>
> I don't want all the userbase to have the same tool with the same default 
> password.

>Done.
>Add postinst script to handle this.


>I like that solution!


but shouldn't this be executed only during install?
the place where you put suggests the code will be executed and re-executed 
during all
the calls (configure deconfigure abort upgrade and so on)

I would do it in configure, and don't care about the upgrade, because even 
re-running
it will be a no-op (unless apg generates the same "barfoo!" password :) )
LOL, in that case it will be changed during an apt-get {dist-}upgrade :)

>Hope you cannot find a nitpick this time :-P

there is always something to nitpick :)

e.g. 
https://mentors.debian.net/package/shadowsocks-libev
"W debian-watch-file-should-mangle-version
line 7"

what does it mean?
I admit I didn't investigate it

Gianfranco



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-19 Thread Roger Shimizu
Dear G,

Sorry for keeping you waiting.
Packaging another library (libipset) just takes some time.

On Wed, Jun 1, 2016 at 10:40 PM, Gianfranco Costamagna <
locutusofb...@debian.org> wrote:
> Hi again,
>
>>It's false positive.
>
> ack

Thanks!

>>> Replaces: shadowsocks (<< 1.5.3-2)
>>> Breaks: shadowsocks (<< 1.5.3-2)
>>
>>Thanks to co-maintainer Boyuan, below comments are from him.
>>
>>
>>Upstream used to use the package name **`shadowsocks'** long long ago,
>>and the name was changed into `shadowsocks-libev' [0] since version
>>1.5.3-2 in order to prevent the naming conflict with python version of
>>shadowsocks [1].
>>
>>Upstream has been providing debian directory for a really long time
>>(earlier than v1.3), so someone may be installing the *libev* version
>>of debian package called `shadowsocks'. You may notice that for python
>>version of shadowsocks, the **initial** release was 2.1.0 [2] and will
>>not bother with shadowsocks << 1.5.3-2. . So setting Replaces /
>>Breaks: shadowsocks << 1.5.3-2 should be the best way to deal with
>>those two problems.
>>
>>[0]
https://github.com/shadowsocks/shadowsocks-libev/blob/master/Changes#L205
>>[1] https://packages.debian.org/sid/shadowsocks
>>[2]
http://metadata.ftp-master.debian.org/changelogs//main/s/shadowsocks/shadowsocks_2.1.0-1_changelog
>>
>
>
> does this mean that actually they aren't installable together?
> (note: I already know the answer :p )

Technically yes, but since it's a quite old version, I think nobody would
do it.
And currently "shadowsocks" is a python program in Debian archive, we don't
recommend to install the old C-written shadowsocks.

>>I didn't package ipset because:
>>- Almost dead upstream. There're a few questions and pull request is
>>pending on github for years.
>>- I cannot compile by the steps described in upstream's INSTALL file.
>>It failed on linking.
>>- Current embedded library just works, because shadowsocks-libev's
>>upstream has modified this library to improve compatibility on
>>multi-platform.
>>
>
>
> do you have logs for the failures? doesn't upstream have possibility
> to switch to a more maintained library?
>
> I tried to find ipset on github, and I think I found the right one.
>
> I fixed the link failure I guess you were referring to and opened an
upstream
> pull request.
>
> https://github.com/redjack/ipset/pull/40
>
> I still prefer it to be packaged, and maybe you doing a diff between the
two and patch
> with Debian patches the differences.
> This way you can send patches upstream, and one day if nobody answers to
them,
> maybe just fork, apply all of them, and release a new version.

Thanks for your patch!
It really worked since that.

So I packaged it and filed ITP#827080 / RFS#827082.
Hope you can also sponsor it.

> Otherwise you will have the embedded-code-copies issue, and maybe prevent
other people
> from using it.
>>> 5)
>>> sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`
>>
>>It's workaround for lintian:
>>https://lintian.debian.org/tags/non-empty-dependency_libs-in-la-file.html
>
>
> I think the best fix is to remove the .la files
> override_dh_auto_install
> find blah -delete "*.la"
> dh_auto_install
>
> might work :)

Thanks for your detailed tips!
I just remove the text after "-delete", others are just as what you said.
Works fantastic!

>>It's runtime config file, which will be installed to:
etc/shadowsocks-libev
>
> not sure about hardcoding passwords that way... maybe generate them at
install
> time with apg or similar?
> (postinst or similar)
>
> I don't want all the userbase to have the same tool with the same default
password.

Done.
Add postinst script to handle this.

Hope you cannot find a nitpick this time :-P

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


Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-11 Thread Roger Shimizu
Control: block -1 by 827080



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-01 Thread Gianfranco Costamagna
Hi again,



>It's false positive.


ack

>> Replaces: shadowsocks (<< 1.5.3-2)
>> Breaks: shadowsocks (<< 1.5.3-2)
>
>Thanks to co-maintainer Boyuan, below comments are from him.
>
>
>Upstream used to use the package name **`shadowsocks'** long long ago,
>and the name was changed into `shadowsocks-libev' [0] since version
>1.5.3-2 in order to prevent the naming conflict with python version of
>shadowsocks [1].
>
>Upstream has been providing debian directory for a really long time
>(earlier than v1.3), so someone may be installing the *libev* version
>of debian package called `shadowsocks'. You may notice that for python
>version of shadowsocks, the **initial** release was 2.1.0 [2] and will
>not bother with shadowsocks << 1.5.3-2. . So setting Replaces /
>Breaks: shadowsocks << 1.5.3-2 should be the best way to deal with
>those two problems.
>
>[0] https://github.com/shadowsocks/shadowsocks-libev/blob/master/Changes#L205
>[1] https://packages.debian.org/sid/shadowsocks
>[2] 
>http://metadata.ftp-master.debian.org/changelogs//main/s/shadowsocks/shadowsocks_2.1.0-1_changelog
>


does this mean that actually they aren't installable together?
(note: I already know the answer :p )

>I didn't package ipset because:
>- Almost dead upstream. There're a few questions and pull request is
>pending on github for years.
>- I cannot compile by the steps described in upstream's INSTALL file.
>It failed on linking.
>- Current embedded library just works, because shadowsocks-libev's
>upstream has modified this library to improve compatibility on
>multi-platform.
>


do you have logs for the failures? doesn't upstream have possibility
to switch to a more maintained library?

I tried to find ipset on github, and I think I found the right one.

I fixed the link failure I guess you were referring to and opened an upstream
pull request.

https://github.com/redjack/ipset/pull/40

I still prefer it to be packaged, and maybe you doing a diff between the two 
and patch
with Debian patches the differences.
This way you can send patches upstream, and one day if nobody answers to them,
maybe just fork, apply all of them, and release a new version.


Otherwise you will have the embedded-code-copies issue, and maybe prevent other 
people
from using it.
>> 5)
>> sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`
>
>It's workaround for lintian:
>https://lintian.debian.org/tags/non-empty-dependency_libs-in-la-file.html


I think the best fix is to remove the .la files
override_dh_auto_install
find blah -delete "*.la"
dh_auto_install

might work :)
>It's runtime config file, which will be installed to: etc/shadowsocks-libev


not sure about hardcoding passwords that way... maybe generate them at install
time with apg or similar?
(postinst or similar)

I don't want all the userbase to have the same tool with the same default 
password.

>>Hope you feel the updated package more comfortable.
>Thanks again!


I like it, just I like to nitpick/bother too ;)


thanks!

G.



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-06-01 Thread Roger Shimizu
Dear G,

Thank you for reviewing my package!

Changes are push to branch pkg3 of github:
https://github.com/rogers0/shadowsocks-libev
And package on mentors also get updated.

(Only fixed the description issue, though)

On Wed, Jun 1, 2016 at 5:52 AM, Gianfranco Costamagna
 wrote:
> 1) I: shadowsocks-libev: extended-description-is-probably-too-short

Fixed now.

> 2)W: shadowsocks-libev source: debian-watch-file-should-mangle-version line 7

It's false positive.
Same answer for libcork in RFS.
I don't do workaround because I want to see when it will be resolved. :-)

> 3)
> Replaces: shadowsocks (<< 1.5.3-2)
> Breaks: shadowsocks (<< 1.5.3-2)

Thanks to co-maintainer Boyuan, below comments are from him.


Upstream used to use the package name **`shadowsocks'** long long ago,
and the name was changed into `shadowsocks-libev' [0] since version
1.5.3-2 in order to prevent the naming conflict with python version of
shadowsocks [1].

Upstream has been providing debian directory for a really long time
(earlier than v1.3), so someone may be installing the *libev* version
of debian package called `shadowsocks'. You may notice that for python
version of shadowsocks, the **initial** release was 2.1.0 [2] and will
not bother with shadowsocks << 1.5.3-2. . So setting Replaces /
Breaks: shadowsocks << 1.5.3-2 should be the best way to deal with
those two problems.

[0] https://github.com/shadowsocks/shadowsocks-libev/blob/master/Changes#L205
[1] https://packages.debian.org/sid/shadowsocks
[2] 
http://metadata.ftp-master.debian.org/changelogs//main/s/shadowsocks/shadowsocks_2.1.0-1_changelog


> 4)libipset/ <-- debian has libipset-dev, please make sure that one is used 
> during build
> (if it is the correct lib of course)

Debian's libipset-dev has nothing to do with files in libipset/ folder.
I did tried to package this, failed. As I explained in other email to
you as paste below:


I didn't package ipset because:
- Almost dead upstream. There're a few questions and pull request is
pending on github for years.
- I cannot compile by the steps described in upstream's INSTALL file.
It failed on linking.
- Current embedded library just works, because shadowsocks-libev's
upstream has modified this library to improve compatibility on
multi-platform.


> 5)
> sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`

It's workaround for lintian:
https://lintian.debian.org/tags/non-empty-dependency_libs-in-la-file.html

> 6) debian/config.json

It's runtime config file, which will be installed to: etc/shadowsocks-libev

Hope you feel the updated package more comfortable.
Thanks again!

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



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-05-31 Thread Gianfranco Costamagna
control: tags -1 moreinfo
control: owner -1 !

hi,
1) I: shadowsocks-libev: extended-description-is-probably-too-short

2)W: shadowsocks-libev source: debian-watch-file-should-mangle-version line 7

3)
Replaces: shadowsocks (<< 1.5.3-2)
Breaks: shadowsocks (<< 1.5.3-2)


Why?

4)libipset/ <-- debian has libipset-dev, please make sure that one is used 
during build
(if it is the correct lib of course)

5) 
sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'`

what?

6) debian/config.json
what?


let me know if you can address the above and I'll have another look!

cheers,

G.




Il Martedì 31 Maggio 2016 13:45, Roger Shimizu  ha 
scritto:
Control: retitle -1 RFS: shadowsocks-libev/2.4.6+20160531+ds-1 [ITP]

Since there're a few improvements of upstream:
- Merged one of my patch in debian/patches/
- Made upstream Changelog out of debian/ folder, so as one lintian info is gone.

I update the version to latest commit in upstream git, and upload to mentors.

Now my packaging stuff can be found on pkg2 branch of
https://github.com/rogers0/shadowsocks-libev
Thank you and looking forward to sponsorship!

Cheers,

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



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-05-31 Thread Roger Shimizu
Control: retitle -1 RFS: shadowsocks-libev/2.4.6+20160531+ds-1 [ITP]

Since there're a few improvements of upstream:
- Merged one of my patch in debian/patches/
- Made upstream Changelog out of debian/ folder, so as one lintian info is gone.

I update the version to latest commit in upstream git, and upload to mentors.

Now my packaging stuff can be found on pkg2 branch of
https://github.com/rogers0/shadowsocks-libev
Thank you and looking forward to sponsorship!

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



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-05-29 Thread Roger Shimizu
Forget to mention that the changes are pushed to branch "pkg" on github:
  https://github.com/rogers0/shadowsocks-libev

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



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-05-27 Thread Roger Shimizu
Control: block -1 by 825531



Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

2016-05-27 Thread Roger Shimizu
package: sponsorship-requests
severity: wishlist
X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "shadowsocks-libev"

 * Package name: shadowsocks-libev
   Version : 2.4.6+20160526+ds-1
   Upstream Author : Max Lv 
 * URL : http://www.shadowsocks.org
 * License : GPL-3+
   Section : net

It builds those binary packages:

 libshadowsocks-dev - lightweight and secure socks5 proxy (development files)
 libshadowsocks1 - lightweight and secure socks5 proxy (shared library)
 shadowsocks-libev - lightweight and secure socks5 proxy

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

https://mentors.debian.net/package/shadowsocks-libev

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.6+20160526+ds-1.dsc

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