Dear maintainer Please add also the seafile server in the debian distribution. Best regards and thank you for your support Bernhard
Dear Bernhard, I'm afraid we don't see how this is possible at the moment. We asked the upstream developers about long-term security support for a fixed version of their server software but they don't want to that currently. The server part of Seafile is changing too quickly and too often and there is not enough manpower for such an endeavour. You need to install the server part manually using the instructions provided in the Manual: http://manual.seafile.com/. I'm gonna leave this open as an RFP, but personally, I won't do it ATM. Best regards,
Hi,
I've done some proof of concept packaging which seems to be working.
Long story short :
* the good :
- some rather simple steps[0] give you a working install
- my work is available [1][2] , comments and feedback welcome!
* the bad :
- ccnet-server also builds libccnet with an additional header
- libsearpc needs a small patch to be able to build seahub
* the ugly :
- it feels wrong to plan to introduce a python2 only package in the archive
- the lintian output of seahub
[0] Steps:
$ sudo apt install seafile-server
$ sudo seafile-admin-helper setup
$ sudo systemctl restart seafile-ccnet-server
$ sudo seafile-admin-helper passwd
$ sudo systemctl start seafile-server
$ sudo systemctl enable seafile-seahub-uwsgi
$ sudo systemctl start seafile-seahub-uwsgi
[1] git web interface : http://sousmonlit.zincube.net/~niol/repositories.git/
[2] packages and build logs : http://sousmonlit.zincube.net/~niol/apt/
Work on seafile-server consisted mainly in making it work with the
newer libevhtp, something no one had worked on for a long time. Thanks
to libevhtp maintainer, this has resulted in one adjustment in
seafile-server and a fix in libevhtp.
Also, ccnet-server and seafile-server packaging involved separating
conf files (/etc) and variable data (/var). This leads to the upstream
provided admin scripts being useless without heavy patching, so I
ended up writing a simplified one for debian. This means the upstream
manual is useless on Debian when referencing these scripts. I have to
continue to work on this. I'm also pondering moving most binaries out
of PATH as they feel useless to the user.
I also chose to ignore seafile-controller and use systemd instead.
Regarding seahub, the work consisted mainly in porting to a newer
django, the result is a big patch addressing API changes.
Regarding the dependencies, I trivially packaged the following seahub
deps. Not much to say there except that it would nice the enable the
failing test suites of those packages.
- django-post-office
- django-termsandconditions
- django-statici18n
- django-constance
So that means that my TODO list consists in the following, in order :
1) send patches upstream
2) use all this some time in order to fix seahub porting problems and
see if I want to use seafile myself
3) coordinate with ccnet Debian maintainers to see how libccnet should
be packaged (ccnet or ccnet-server or both).
4) iron out admin scripts and associated documentation, document
seahub deployment in README.Debian
5) cleanup seahub lintian errors (the usual embedded or minified, or
both, js problems)
6) fill out ITPs and find a sponsor. I know there is not upstream
commitment to security patches but I'm doing all this for myself
anyway so I'll try my best to finish the job. And maybe it won't go in
the archive but it may be of some interest to others.
7) port seahub to python3 (I'v already ported one of my pet projects
and deps seem to be available so it should not be hard)
Again, I'd be glad to receive any feedback and to coordinate with any
effort regarding this packaging.
Thanks for reading,
Alex
Dear Alexandre, thanks for your lots of work! First of all, I'd like to reference some discussions in the upstream support forum: https://forum.seafile.com/t/what-about-reproducible-builds/3125/11 and https://forum.seafile.com/t/about-the-future-of-seafile-repository-packages/49/2 I'm adding my two cents on the stuff below: Thanks for that! I'd say that at least fsck, fuse and gc are quite important for an end user, so I think those should be kept. I very much like that! :-D https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887361 Although I actually just found this forum post: https://forum.seafile.com/t/seafile-server-and-seafile-client-packaging-guidelines/662/9 Best regards,
Dear Alex,
thank you very much for packaging seafile server! There is a small issue
with the seahub package: it should depend on python-tz.
On a minimal system with 'APT::Install-Recommends "0";' and
'APT::Install-Suggests "0";' the current package leads to the following
stack trace on install:
| Setting up seahub (6.2.5+dfsg-1~pre+1~bpo90+1) ...
| Traceback (most recent call last):
| File "/usr/bin/django-admin", line 21, in <module>
| management.execute_from_command_line()
| File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
| utility.execute()
| File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 341, in execute
| django.setup()
| File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
| apps.populate(settings.INSTALLED_APPS)
| File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in populate
| app_config.import_models(all_models)
| File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in import_models
| self.models_module = import_module(models_module_name)
| File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
| __import__(name)
| File "/usr/lib/python2.7/dist-packages/seahub/base/models.py", line 15, in <module>
| from seahub.utils.timeutils import datetime_to_isoformat_timestr
| File "/usr/lib/python2.7/dist-packages/seahub/utils/timeutils.py", line 3, in <module>
| import pytz
| ImportError: No module named pytz
| dpkg: error processing package seahub (--configure):
| subprocess installed post-installation script returned error exit status 1
| dpkg: dependency problems prevent configuration of seafile-server:
| seafile-server depends on seahub; however:
| Package seahub is not configured yet.
|
| dpkg: error processing package seafile-server (--configure):
| dependency problems - leaving unconfigured
best regards,
Adi Kriegisch
PS: would you consider building libccnet with mysql and postgres support? :-)
Dear all, as maintainer of the Seafile client packages (libsearpc, seafile and seafile-client), I would like to thank Jan-Henrik for bringing this to our attention. There have already been such findings in the past, regarding some code taken from git, and the discussion regarding libzdb in the past, as you mentioned. I remember discussing the problems regarding linking to OpenSSL, too. However, all of the database related code is *only* contained in the Seafile server implementation (https://github.com/haiwen/seafile-server, RFP at #865830) and not in the Seafile client implementation (https://github.com/haiwen/seafile) that I have packaged for Debian. I disagree that this should serve as a reason for *not* including the client packages in the next Debian release. What do others think about that? I will however forward these findings to the developers at Seafile Ltd and ask them for a proper resolution. Best regards,
Hi, I fully agree. Since the client doesn’t include the code in question, it’s out of scope of the issue, so there is no reason to remove it from Debian.
Andrej Shadura writes ("Re: Copyright concerns regarding Seafile"):
I am very uncomfortable with having code in Debian whose upstream
authors appear to have plagiarised some other people's software, and
then obfuscated it, in order to evade copyright licensing. Who knows
what other misleading practices they have engaged in, or may do in the
future ?
As a project, we do not have the resources to fully audit all the code
we ingest from upstreams and redistribute to our users. We must rely
on trust. That depends on the upstream being trustworthy.
Ian.
Did you give up on this?
Hi, Why? If I remember correctly, I was quite happy with how the packaging was going on and think I had solved all the technical integration issues. I was also happy with using that package. But I had the impression that upstream contributions, even trivial ones, were not integrated upstream. I then went to the conclusion that it was not viable to continue, lacking upstream cooperation. Then I think I noticed that the server was rewritten in Go, pushing my work back to the start (cannot find this anymore). Some years later, I see that my summary post[1] to upstream is still valid and unanswered. My work is still available[2] by the way. I also share the feeling that there should be a file sync server software in Debian. Right now using nextcloud and sadly updating with unzip/rsync. Cheers, Alex [1] https://github.com/haiwen/seafile/issues/1916#issuecomment-694087445 [2] https://sml.zincube.net/~niol/repositories.git/
Thanks for the update, and thanks for having tried.