Filing this ITP because I am sure people will ask about this when it becomes official. It already appeared in a PM: http://blog.documentfoundation.org/2015/03/25/libreoffice-to-become-the-cornerstone-of-the-worlds-first-universal-productivity-solution/ * Package name : libreoffice-online Version : whatever is uptodate then Upstream Author : TDF * URL : http://cgit.freedesktop.org/libreoffice/online/ * License : MPL-2.0 Programming Lang: C++, JS Description : LibreOffice on-line Quote from http://cgit.freedesktop.org/libreoffice/online/tree/README: loolwsd/ The server side component. loleaflet/ The client side component. Those will be the packages built (and/or have a depends on libjs-leaflet). For loolwsd we need a uptodate version of poco, see 786498 Regards, Rene
Indeed it would be nice to have a Debian package for LibreOffice Online. I finished installing it manually on Debian Stretch, and it works pretty good. When building I noticed that missing JSON support in package libpoco-dev is still a problem (see bug report #856192).
block 787080 by 856192 thanks Hi, Yes, definitely. (And then there's the Javascript/npm_shrinkwrap mess and how to untangle it and use system stuff). But the poco JSON usage is a/the biggest problem. But I don't get #856192. That the JSON component is missing is completely normal there. If POCO would have used something with a free license.... See also https://bugs.documentfoundation.org/show_bug.cgi?id=103678 for the wish upstream to remove that specific usage of POCO. Regards, Rene
Hi, loleaflet) part to pkg-openoffice[sic!] git: https://anonscm.debian.org/cgit/pkg-openoffice/libreoffice-online.git Any help/patches welcome, especially for the Javascript/npm mess. Also for new JS packages (which then probably should be put under the Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org> umbrella. While doing what I did above, I created a unstripped (but thus non-free) version of poco. FWIW, I now uploaded that one to https://people.debian.org/~rene/libreoffice/online/poco-nonfree/ But for Debian, the poco and JS situations need to be sorted out, of course. Regards, Rene
The license issue with JSON in libpoco was fixed recently, see https://github.com/pocoproject/poco/issues/1614#issuecomment-327629217.
Hi, Only if the poco got released with that - so we'd need to wait for poco 2.0. But yeah, interesting point. But that still leaves the JS mess and Debians npm too old to actually do something with that npm_shrinkwrap thingy :( Regards, Rene
retitle 894119 RFP: libreoffice-online reassign 894119 wnpp forcemerge 787080 894119 thanks No, this is not a bug in LibreOffice itself. It's a wish for a new package, which isn't even developed inside the LO "core" code and thus wouldn't be built from here anyway. And definitely not in stable in any case. Maybe, but you need consumers for it. Of which I know of nextclouds richdocument stff but that one isn't packaged either. :) A daemon and JS stuff for "nothing" doesn't really help, does it? Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787080. I have a building (with npm from nodejs package...) package, but I am not succeeding getting it to work... It's all theory anyway given the npm JS mess and that it Current packaging is at https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online, though... Regards, Rene
Dear Rene,
thank you very much for the hard work you've put in packaging libreoffice
online. Starting from your salsa repo[1] I was able to successfully build
loolwsd and loleaflet packages with the libreoffice packages from
buster-backports. There were, however, some issues with the unit tests.
After trying to investigate some of the issues, I decided to skip the test
by adding an empty override_dh_auto_test target.
Is there any reason why you use loolwsd's init script to configure it
instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the
current init script this does not work.
May I suggest to use a simpler init script like this one:
8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides: loolwsd
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: libreoffice online server
# Description: libreoffice online server
### END INIT INFO
DESC="libreoffice online server"
DAEMON=/usr/bin/loolwsd
DAEMON_ARGS="--daemon"
START_ARGS="--chuid lool --user lool"
----->8----->8----->8----->8----->8----->8----->8----->8
I very much hope, you're going to continue your excellent work and
libreoffice online hits the debian archive any time in a not too distant
future! ;-)
best regards,
Adi Kriegisch
[1] https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online/
Hi, Am 16.03.21 um 22:02 schrieb Adi Kriegisch: Yeah, that one is a mess upstream: - unit tests need debug - tests need write permissions in the LO directory (which they of course don't have in /usr/lib/libreoffice) ... That part wasn't updated for some time, I wouldn't be surprised if it broke. /etc/default is a well-known location for environment variables needed by init scripts, though. That said, for init script I'd stay as close as with upstream as possible since maintaining an initi script is a PITA. (People ideally should use systemd and the systemd unit anyway but init scripts still should be shipped if feasible.) But MRs (or patches if you don't have an account on salsa) welcome. If someone sorts out the JS mess and packages the modules (and keeps the chain uptodate).... ;-) Then we just need to figure out the test mess (maybe not run them during the build at all indeed and make it a "needs-root breaks-testbed" autopkgtest. One should probably add a autopkgtest anyway.) Regards, Rene
I don't know the difference between Libreoffice Online and Collabora Online? Which one should Debian package? These links seem relevant to understand the situation: https://www.collaboraoffice.com/community-en/understanding-the-differences-between-libreoffice-online-code-and-collabora-online/ https://collaboraonline.github.io/post/faq/ According to the above, it seems that the main developers behind Libreoffice Online renamed the project to Collabora Online? In that case it would be good to also rename this ITP to avoid confusion?