Preiniting LibreOfficeKit and forking kit processes (instead of
spawning) has worked fine for a while, and has been the default way
this works.
No 'loolkit' program gets built any more.
Not needed after all. It was a red herring. The device files work fine
even if not owned by root:root and with mode 664. The actual problem
was that I used a file system mounted with nodev when testing loolwsd.
This reverts commit 509314d559
So don't give it any then.
Remove the --uid option and related attempts to handle running loolwsd
under sudo, to be able to debug it. Now with loolwsd not having
capabilities, it should work fine to just run it under a debugger
normally. (For the loolbroker and loolkit processes, attaching to an
already started process is the way to debug.)
(Instead of having them as separate SOURCEn in the loolwsd.spec.)
Both are related to systemd. The latter probably is relevant only for
openSUSE. (And I actually couldn't get what I tried doing in it to work, see
739edf9dcf464f407dfe663fb2f497b866e73333.)
(cherry picked from commit f8b29d666d52a3f18b0125aaed309fa3e4d719fb)
LibreOffice from TDF, packaged in RPM, does not have proper dependencies as it
is supposed to be usable on different distros and can't know what names are
used for packages for system libraries used, like the one containing
libdbus-glib. But we must have all dependent libraries installed when running
the loolwsd-systemplate-setup command in the %post phase. As this spec file de
facto is for openSUSE 13.2 only anyway, we can find out the package names and
depend on them...
Add the list from running:
rpm -qf --queryformat '%{NAME} ' `find /opt/libreofficedev5.1 -name '*.so' -o -name '*.so.[0-9]*' | while read file; do ldd $file; done | grep -v dynamic | cut -d " " -f 3 | grep -E '^(/lib|/usr)/' | sort -u`
They need to be installed before loolwsd is installed, because our %post
action needs to know where LO is installed so that it can create the
systemplate and child-roots directories on the same file system where LO
is. Oh this is crazy and over-engineered. I wonder if it makes sense at all to
even consider packaging this loolwsd in some generically useful way, or if it
should be considered a manual thing for customers / users to install and
configure.
Sadly the TDF builds of LO use the version number in the package names, so we
can't depend on *some* TDF build of LO (like >= 5.0), but must have a specific
version in this spec file. Sigh.
They must be on the same file system where LO is installed, and the TDF
tarballs puts that in /opt, and on some Linuxes in default configuration /opt
is on a different file system from /home, so we should not really use
/home/lool.
