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

[Gianfranco Costamagna]

Hi,

>> you already are a DM, you need the guest account, but it isn't requested

>> for collab-maint access
>
>You mean guest account of porterbox, right?
>I already applied, and got approved. It's for debug FTBFS of libcork
>on s390x/ppc64/sparc64.
>
>For access collab-maint, guest account of alioth is enough.
>Two co-maintainers already have it. So it's cleared here.


wonderful.

>Thanks for your help!
>I'll push the commits when the upload is done.


ack ok!
>I get it.
>I'll ask them later.


wonderful!
in the meanwhile they can git commit, git format-patch -1 and git-send-email 
patches to you :)
(not the best workflow, I know)


git send-email --to youem...@domain.com 0001-whatever.patch
>You're so kind!

>I'll let you know when I need more. Thank you!

wonderful!

Gianfranco

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

[Gianfranco Costamagna]

Hi,



>Now I already have acess to collab-maint (though I didn't do any work

>yet), and I have become DM [0].


you already are a DM, you need the guest account, but it isn't requested
for collab-maint access

>Could you kindly help to set up a git repo for shadowsocks-libev on
collab-maint?


./setup-repository shadowsocks-libev "lightweight and secure socks5 proxy"
Initialized empty shared Git repository in 
/srv/git.debian.org/git/collab-maint/shadowsocks-libev.git/


>And how about co-maintainer's accounts?>Do they need to apply for collab-maint 
>on their own, or I can apply for them?


they need to, and they need to find a sponsor advocating them.


Let me know if you want other repositories to be created there, and also give 
me a short description for the repo.

cheers!

G.

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

[Roger Shimizu]

Dear G,

Greetings after 1+ months for this thread!

On Thu, May 19, 2016 at 12:32 AM, Gianfranco Costamagna
 wrote:
>
>
> Hi, alternative proposal
>
>>Now I understand my todo-list, briefly:
>>- package libraries first: libcork/ipset
>>- create debian/watch and ds repack
>>- RFS shadowsocks-libev
>>- apply for collab-maint access
>
>
> - open ITP bugs for all the libraries (search for wnpp and ITP on google)
>
> - package libcork/ipset/shadowsocks-libev all at the same time
> - RFS for all of the three packages and make them blocked by each other
> e.g. block shadowsocks-libev RFS bug by the other two.
> - show your git skills in the meanwhile, and ask for collab-maint access
>
> (BTW it isn't requested to have the repo in collab-maint by the current 
> policy)

Thanks for the uploading!

Now I already have acess to collab-maint (though I didn't do any work
yet), and I have become DM [0].

Could you kindly help to set up a git repo for shadowsocks-libev on
collab-maint?

And how about co-maintainer's accounts?
Do they need to apply for collab-maint on their own, or I can apply for them?

I appreciate your kindness help!

[0] https://nm.debian.org/public/person/rosh

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

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

[Roger Shimizu]

On Thu, May 19, 2016 at 12:32 AM, Gianfranco Costamagna
 wrote:
>
> Hi, alternative proposal
>
>>Now I understand my todo-list, briefly:
>>- package libraries first: libcork/ipset
>>- create debian/watch and ds repack
>>- RFS shadowsocks-libev
>>- apply for collab-maint access
>
> - open ITP bugs for all the libraries (search for wnpp and ITP on google)
>
> - package libcork/ipset/shadowsocks-libev all at the same time
> - RFS for all of the three packages and make them blocked by each other
> e.g. block shadowsocks-libev RFS bug by the other two.
> - show your git skills in the meanwhile, and ask for collab-maint access
>
> (BTW it isn't requested to have the repo in collab-maint by the current 
> policy)

Dear G,

I followed most of your advice, and just uploaded to mentors.

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.

I hope you or other DD can sponsor this two packages, because my usual
sponsor is quite busy.
Thanks for your understanding!

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

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

[Gianfranco Costamagna]

Hi, alternative proposal

>Now I understand my todo-list, briefly:
>- package libraries first: libcork/ipset
>- create debian/watch and ds repack
>- RFS shadowsocks-libev
>- apply for collab-maint access


- open ITP bugs for all the libraries (search for wnpp and ITP on google)

- package libcork/ipset/shadowsocks-libev all at the same time
- RFS for all of the three packages and make them blocked by each other
e.g. block shadowsocks-libev RFS bug by the other two.
- show your git skills in the meanwhile, and ask for collab-maint access

(BTW it isn't requested to have the repo in collab-maint by the current policy)

Gianfranco

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

[Roger Shimizu]

On Thu, May 19, 2016 at 12:04 AM, Gianfranco Costamagna
 wrote:
>
> Hi,
>
>
>>If so, here's our alioth account: rosh-guest, hosiet-guest, 
>>madeye-guest.>Thank you!
>
>
> you need to send a request to join collab-maint, an alioth account doesn't 
> grant
> your permissions automatically.
> I suggest you to use an external repository to show your skills, and then ask 
> to join
> (consider that to join you have to be a Debian Maintainer or to have a Debian 
> Developer
> advocating you)
>
>>Is this (package the libraries separately) required? or something can
>>be done afterwards?
>
>
> up to your eventual sponsor, I personally require that, because it is trivial 
> to do,
> and makes lifes of ftpmasters easier and for other people too.
> (unless the library is strictly private for the tool, there is no need to 
> have an embedded copy)
>
> you might however try to persuade your sponsor about having them embedded ;)
>
>>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.
>
>
> just call it ds, have a README.source in debian directory explaining why, and 
> the dversionmangle in watch
> file should be enough.
> Probably somebody should write some wiki :)

Dear Gianfranco,

Thanks for your reply!

Now I understand my todo-list, briefly:
- package libraries first: libcork/ipset
- create debian/watch and ds repack
- RFS shadowsocks-libev
- apply for collab-maint access

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

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

[Gianfranco Costamagna]

Hi,


>If so, here's our alioth account: rosh-guest, hosiet-guest, 
>madeye-guest.>Thank you!


you need to send a request to join collab-maint, an alioth account doesn't grant
your permissions automatically.
I suggest you to use an external repository to show your skills, and then ask 
to join
(consider that to join you have to be a Debian Maintainer or to have a Debian 
Developer
advocating you)

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


up to your eventual sponsor, I personally require that, because it is trivial 
to do,
and makes lifes of ftpmasters easier and for other people too.
(unless the library is strictly private for the tool, there is no need to have 
an embedded copy)

you might however try to persuade your sponsor about having them embedded ;)

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


just call it ds, have a README.source in debian directory explaining why, and 
the dversionmangle in watch
file should be enough.
Probably somebody should write some wiki :)

G.

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

[Roger Shimizu]

[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  wrote:
> * Roger Shimizu , 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
 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

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

[Jakub Wilk]

* Roger Shimizu , 2016-05-18, 02:14:
I'm doing ITP packaging on shadowsocks-libev. I have a few questions in 
detail.


I have set up a git repo on github: https://github.com/rogers0/shadowsocks-libev
My current changes are pushed to branch: RFC

Package builds fine with command: gbp buildpackage -us -uc 
--git-ignore-branch


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.


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


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


- The answer of above question may affect: whether I should remove 
copyright of library libev, libsodium, libudns from debian/copyright?


If you keep them in .orig.tar, then you must also keep them in 
debian/copyright.


If you remove them from .orig.tar, then remove them from 
debian/copyright too.



- Is it needed to add "dh_autoreconf" in debian/rules?


It's not required by policy, but many sponsors will (rightfully!) insist 
to regenerate autotools stuff from source.


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


--
Jakub Wilk

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

[Gianfranco Costamagna]

Hi,

>I have set up a git repo on github: 
>https://github.com/rogers0/shadowsocks-libev
>My current changes are pushed to branch: RFC


(I won't clone that right now, only answering questions)
>Package builds fine with command: gbp buildpackage -us -uc --git-ignore-branch


you should also try pbuilder or sbuild clean environments
>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?


I would remove the upstream packaging, we use changelog to keep track
of changes that went in Debian, not changes that were done by somebody else.


>- The package is mainly GPLv3, but it links to OpenSSL library, is>that OK? 
>Since there's concern mentioned in debian/README.Debian


please read that page
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

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

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)

please check copyright Files-Excluded: keyword


>- Is it needed to add "dh_autoreconf" in debian/rules? I have tested>it, it 
>builds well.


add dh-autoreconf to control file and 
"dh $@ --with autoreconf"
in the default call (rules file)


>- 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
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-tunnel
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-server
>E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls
>etc/init.d/shadowsocks-libev-redir
>


maybe the broken files comes from upstream?

G.