Bug#698681: Any progress on seafile-client?
Hi Lin, I am sorry, but the package in the current state is nowhere near to be released in the Debian. The upstream tarball includes two upstream libraries. That might be okayish for releasing just the client, but when you package other binaries (the server) which will link to the same library, you want to use shared libraries. Also this makes the packaging unnecessarily complex. But you certainly cannot embed libjson-glib-1.0 as part of libsearpc (under different name), that's just security nightmare I will create the initial packaging in correct way (I already have libsearpc 1.1.0+dfsg, e.g. without embedded json-glib, packaged), and make you the co-maintainer of the packages. Ondrej On Wed, May 22, 2013 at 2:09 PM, Shuai Lin linshuai2...@gmail.com wrote: Hi Sury, Glad to hear this. Actually I have been working on packaging seafile-client for debian with guide and help from Jérémy Lal kapo...@melix.org, who has been very nice and patient. But for the last two months Jeremy seems to be kind of busy, so the debian related work has been stalled for a while. Since you are interested, here are some work we have done: The seafile deb branch on github: https://github.com/haiwen/seafile/tree/deb/debian seafile-client package on mentors.debian.net http://mentors.debian.net/package/seafile-client Regards, Lin On Wed, May 22, 2013 at 7:50 PM, Ondřej Surý ond...@sury.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej -- Ondřej Surý ond...@sury.org -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
When i asked Shuai Lin about packaging them i understood those libs were in a too early development phase to be released independently, so i postponed the review of those libs. Shuai, are those two libs releasable in separate packages now ? Are those libs used by seafile-server or other software ? Ondřej, nowhere near to be released are hard words to read, considering we never said it was ready to be released at all - only that some work has been done. Let's encourage Shuai, not discourage him. Note also that it is not recommended practice to dfsg-repack only to get rid of a convenience copy of a lib : http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz The right thing to do is to just link against the debian-installed lib. Jérémy. On 05/06/2013 15:16, Ondřej Surý wrote: Hi Lin, I am sorry, but the package in the current state is nowhere near to be released in the Debian. The upstream tarball includes two upstream libraries. That might be okayish for releasing just the client, but when you package other binaries (the server) which will link to the same library, you want to use shared libraries. Also this makes the packaging unnecessarily complex. But you certainly cannot embed libjson-glib-1.0 as part of libsearpc (under different name), that's just security nightmare I will create the initial packaging in correct way (I already have libsearpc 1.1.0+dfsg, e.g. without embedded json-glib, packaged), and make you the co-maintainer of the packages. Ondrej On Wed, May 22, 2013 at 2:09 PM, Shuai Lin linshuai2...@gmail.com mailto:linshuai2...@gmail.com wrote: Hi Sury, Glad to hear this. Actually I have been working on packaging seafile-client for debian with guide and help from Jérémy Lal kapo...@melix.org mailto:kapo...@melix.org, who has been very nice and patient. But for the last two months Jeremy seems to be kind of busy, so the debian related work has been stalled for a while. Since you are interested, here are some work we have done: The seafile deb branch on github: https://github.com/haiwen/seafile/tree/deb/debian seafile-client package on mentors.debian.net http://mentors.debian.net http://mentors.debian.net/package/seafile-client Regards, Lin On Wed, May 22, 2013 at 7:50 PM, Ondřej Surý ond...@sury.org mailto:ond...@sury.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698681: Any progress on seafile-client?
On Wed, Jun 5, 2013 at 3:59 PM, Jérémy Lal kapo...@melix.org wrote: When i asked Shuai Lin about packaging them i understood those libs were in a too early development phase to be released independently, so i postponed the review of those libs. Shuai, are those two libs releasable in separate packages now ? The library has proper SOVER, so there's no fear: libsearpc_la_LDFLAGS = -version-info 1:2:0 -no-undefined Thumbs up! Only thing I would recommend is to use GCC visibility ( http://gcc.gnu.org/wiki/Visibility) to hide symbols not indended for public use, but that's just a nit. Are those libs used by seafile-server or other software ? ondrej@kiMac:/tmp$ git clone git://github.com/haiwen/seafile.git /dev/null [...] $ grep -Elr searpc.*\.h . | cut -f 2 -d / | sort -u app common daemon gui lib monitor server $ grep -Elr ccnet.*\.h . | cut -f 2 -d / | sort -u app common controller daemon gui httpserver lib monitor server Does that answer your question? Ondřej, nowhere near to be released are hard words to read, considering we never said it was ready to be released at all - only that some work has been done. Let's encourage Shuai, not discourage him Sorry, I didn't mean to sound harsh. I thought that the package is shiny and ready and I was slightly disappointed that it's not yet. And I really dislike bundled libraries (php-src/ext/module/ is full of them). Note also that it is not recommended practice to dfsg-repack only to get rid of a convenience copy of a lib : http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz Well, let's hope this https://github.com/haiwen/libsearpc/pull/3 gets accepted then :) The right thing to do is to just link against the debian-installed lib. Well, it's probably just a matter of taste. I found it easier to strip the embedded libraries than to cherry-pick all the scattered licenses and gather them up in the debian/copyright. It's also much easier on our ftp-masters to review less sources. Anyway there's one more problem: ccnet is not releaseable now since the licensing is quite unclear. There's MIT and GPL-3+ license, and I would like to have this solved (and acked by the first author) before ccnet enters the Debian. O. Jérémy. On 05/06/2013 15:16, Ondřej Surý wrote: Hi Lin, I am sorry, but the package in the current state is nowhere near to be released in the Debian. The upstream tarball includes two upstream libraries. That might be okayish for releasing just the client, but when you package other binaries (the server) which will link to the same library, you want to use shared libraries. Also this makes the packaging unnecessarily complex. But you certainly cannot embed libjson-glib-1.0 as part of libsearpc (under different name), that's just security nightmare I will create the initial packaging in correct way (I already have libsearpc 1.1.0+dfsg, e.g. without embedded json-glib, packaged), and make you the co-maintainer of the packages. Ondrej On Wed, May 22, 2013 at 2:09 PM, Shuai Lin linshuai2...@gmail.com mailto:linshuai2...@gmail.com wrote: Hi Sury, Glad to hear this. Actually I have been working on packaging seafile-client for debian with guide and help from Jérémy Lal kapo...@melix.org mailto:kapo...@melix.org, who has been very nice and patient. But for the last two months Jeremy seems to be kind of busy, so the debian related work has been stalled for a while. Since you are interested, here are some work we have done: The seafile deb branch on github: https://github.com/haiwen/seafile/tree/deb/debian seafile-client package on mentors.debian.net http://mentors.debian.net http://mentors.debian.net/package/seafile-client Regards, Lin On Wed, May 22, 2013 at 7:50 PM, Ondřej Surý ond...@sury.org mailto:ond...@sury.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- Ondřej Surý ond...@sury.org mailto:ond...@sury.org -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
On 05/06/2013 16:30, Ondřej Surý wrote: On Wed, Jun 5, 2013 at 3:59 PM, Jérémy Lal kapo...@melix.org mailto:kapo...@melix.org wrote: When i asked Shuai Lin about packaging them i understood those libs were in a too early development phase to be released independently, so i postponed the review of those libs. Shuai, are those two libs releasable in separate packages now ? The library has proper SOVER, so there's no fear: libsearpc_la_LDFLAGS = -version-info 1:2:0 -no-undefined Thumbs up! Only thing I would recommend is to use GCC visibility (http://gcc.gnu.org/wiki/Visibility) to hide symbols not indended for public use, but that's just a nit. Are those libs used by seafile-server or other software ? ondrej@kiMac:/tmp$ git clone git://github.com/haiwen/seafile.git http://github.com/haiwen/seafile.git /dev/null [...] $ grep -Elr searpc.*\.h . | cut -f 2 -d / | sort -u app common daemon gui lib monitor server $ grep -Elr ccnet.*\.h . | cut -f 2 -d / | sort -u app common controller daemon gui httpserver lib monitor server Does that answer your question? No but anyway i agree they look like they could be useful per se. Ondřej, nowhere near to be released are hard words to read, considering we never said it was ready to be released at all - only that some work has been done. Let's encourage Shuai, not discourage him Sorry, I didn't mean to sound harsh. I thought that the package is shiny and ready and I was slightly disappointed that it's not yet. And I really dislike bundled libraries (php-src/ext/module/ is full of them). Note also that it is not recommended practice to dfsg-repack only to get rid of a convenience copy of a lib : http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz Well, let's hope this https://github.com/haiwen/libsearpc/pull/3 gets accepted then :) The right thing to do is to just link against the debian-installed lib. Well, it's probably just a matter of taste. I found it easier to strip the embedded libraries than to cherry-pick all the scattered licenses and gather them up in the debian/copyright. It's also much easier on our ftp-masters to review less sources. If it was a master of taste i would do the same as you, get rid of convenience copies. The idea behind the links i gave above is to refrain people from repacking on personal taste; and distribute *original* upstream tarballs. Of course, once there is a good reason to do repack (typically dfsg) then you can remove embedded convenience copies as well. But you might as well not exclude them. Slightly unrelated : the version libsearpc 1.1.0+dfsg is misleading since there is no DFSG involved in this repacking. Anyway there's one more problem: ccnet is not releaseable now since the licensing is quite unclear. There's MIT and GPL-3+ license, and I would like to have this solved (and acked by the first author) before ccnet enters the Debian. ok, Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698681: Any progress on seafile-client?
On Wed, Jun 5, 2013 at 5:12 PM, Jérémy Lal kapo...@melix.org wrote: Well, it's probably just a matter of taste. I found it easier to strip the embedded libraries than to cherry-pick all the scattered licenses and gather them up in the debian/copyright. It's also much easier on our ftp-masters to review less sources. If it was a master of taste i would do the same as you, get rid of convenience copies. The idea behind the links i gave above is to refrain people from repacking on personal taste; and distribute *original* upstream tarballs. Of course, once there is a good reason to do repack (typically dfsg) then you can remove embedded convenience copies as well. But you might as well not exclude them. Well, there was no upstream tarball anyway, I did create one from git (git archive), so basically no-repacking has happened here. Slightly unrelated : the version libsearpc 1.1.0+dfsg is misleading since there is no DFSG involved in this repacking. True, but it was so convenient :). Please suggest a better name, or let's cross-fingers and let's hope our upstream friends will release 1.1.1 without bundled json-glib library (pretty please). Anyway the current status of seafile packages: http://anonscm.debian.org/gitweb/?p=collab-maint/libsearpc.git;a=summary (uploaded) http://anonscm.debian.org/gitweb/?p=collab-maint/libzdb.git;a=summary(uploaded + asked upstream to grant OpenSSL exception) http://anonscm.debian.org/gitweb/?p=collab-maint/ccnet.git;a=summary (WIP and needs some more licensing love[*]) * - E: libccnet0: possible-gpl-code-linked-with-openssl E: ccnet-bin: possible-gpl-code-linked-with-openssl Shuai, please add OpenSSL exception to the license (if you are going to keep GPL-3 and not MIT) as suggested here: http://people.gnome.org/~markmc/openssl-and-the-gpl.html O. -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
JFTR the seafile needs an gpl+openssl exception too. E: seafile-server: possible-gpl-code-linked-with-openssl E: seafile-client: possible-gpl-code-linked-with-openssl E: seafile-common: possible-gpl-code-linked-with-openssl E: seafile-applet: possible-gpl-code-linked-with-openssl Some very crude preliminary packaging (not yet even tried in clean chroot) with some basic splitting into subpackages (without really understanding the content and without tight dependencies between them) can be found: http://anonscm.debian.org/gitweb/?p=collab-maint/seafile.git;a=summary Hey, it builds and put files into packages, we are almost there :). O. On Wed, Jun 5, 2013 at 6:40 PM, Ondřej Surý ond...@sury.org wrote: On Wed, Jun 5, 2013 at 5:12 PM, Jérémy Lal kapo...@melix.org wrote: Well, it's probably just a matter of taste. I found it easier to strip the embedded libraries than to cherry-pick all the scattered licenses and gather them up in the debian/copyright. It's also much easier on our ftp-masters to review less sources. If it was a master of taste i would do the same as you, get rid of convenience copies. The idea behind the links i gave above is to refrain people from repacking on personal taste; and distribute *original* upstream tarballs. Of course, once there is a good reason to do repack (typically dfsg) then you can remove embedded convenience copies as well. But you might as well not exclude them. Well, there was no upstream tarball anyway, I did create one from git (git archive), so basically no-repacking has happened here. Slightly unrelated : the version libsearpc 1.1.0+dfsg is misleading since there is no DFSG involved in this repacking. True, but it was so convenient :). Please suggest a better name, or let's cross-fingers and let's hope our upstream friends will release 1.1.1 without bundled json-glib library (pretty please). Anyway the current status of seafile packages: http://anonscm.debian.org/gitweb/?p=collab-maint/libsearpc.git;a=summary (uploaded) http://anonscm.debian.org/gitweb/?p=collab-maint/libzdb.git;a=summary(uploaded + asked upstream to grant OpenSSL exception) http://anonscm.debian.org/gitweb/?p=collab-maint/ccnet.git;a=summary(WIP and needs some more licensing love[*]) * - E: libccnet0: possible-gpl-code-linked-with-openssl E: ccnet-bin: possible-gpl-code-linked-with-openssl Shuai, please add OpenSSL exception to the license (if you are going to keep GPL-3 and not MIT) as suggested here: http://people.gnome.org/~markmc/openssl-and-the-gpl.html O. -- Ondřej Surý ond...@sury.org -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
Hi Sury, Glad to hear this. Actually I have been working on packaging seafile-client for debian with guide and help from Jérémy Lal kapo...@melix.org, who has been very nice and patient. But for the last two months Jeremy seems to be kind of busy, so the debian related work has been stalled for a while. Since you are interested, here are some work we have done: The seafile deb branch on github: https://github.com/haiwen/seafile/tree/deb/debian seafile-client package on mentors.debian.net http://mentors.debian.net/package/seafile-client Regards, Lin On Wed, May 22, 2013 at 7:50 PM, Ondřej Surý ond...@sury.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej -- Ondřej Surý ond...@sury.org
Bug#698681: Any progress on seafile-client?
Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej (wasn't subscribed to this bug...) Hi Ondřej, Shuai Lin already did a good job at preparing a seafile-client package, to the point he could nearly maintain it himself. I promised to do a final review and upload, and then got caught by other activities... Shuai, is the package on mentors.d.n up-to-date ? http://mentors.debian.net/package/seafile-client Also i wonder if the server can have its own libraries packaged independently now ? Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698681: Any progress on seafile-client?
The seafile-client package on http://mentors.debian.net/package/seafile-client is not up-to-date. I will update it tomorrow. Regards, Lin On Wed, May 22, 2013 at 8:19 PM, Jérémy Lal kapo...@melix.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej (wasn't subscribed to this bug...) Hi Ondřej, Shuai Lin already did a good job at preparing a seafile-client package, to the point he could nearly maintain it himself. I promised to do a final review and upload, and then got caught by other activities... Shuai, is the package on mentors.d.n up-to-date ? http://mentors.debian.net/package/seafile-client Also i wonder if the server can have its own libraries packaged independently now ? Jérémy.
Bug#698681: Any progress on seafile-client?
Hi, I've just updated the seafile-client package on http://mentors.debian.net/package/seafile-client to the latest version. About the server: After discussion among seafile developers, we don't plan to package the server in the short term, mainly because: 1) Seafile server have used some libraries, like libzdb, libevhtp, which do not exist in debian yet 2) The way seafile server/seahub works/upgrades is based on our own directory layout of the installation. If we are to package the server, there should be quite some amount of redesign work to do to make seafile server/seahub compatible with Debian conventions/policies. But we have lots of other stuff in the todolist -- just see the long list of issues/feature requests here https://github.com/haiwen/seafile/issues?state=open, herehttps://github.com/haiwen/seahub/issues?state=open, and here https://github.com/haiwen/seadroid/issues?state=open Regards, Lin On Wed, May 22, 2013 at 8:19 PM, Jérémy Lal kapo...@melix.org wrote: Hi, I am interested in building seafile, seahub and client packages for Debian. Did you already do some work or it this more like RFP than ITP? Ondrej (wasn't subscribed to this bug...) Hi Ondřej, Shuai Lin already did a good job at preparing a seafile-client package, to the point he could nearly maintain it himself. I promised to do a final review and upload, and then got caught by other activities... Shuai, is the package on mentors.d.n up-to-date ? http://mentors.debian.net/package/seafile-client Also i wonder if the server can have its own libraries packaged independently now ? Jérémy.
