joshuaboniface
/
blog
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

More proofreading + spelling check

This commit is contained in:
Joshua Boniface 2017-07-07 13:30:16 -04:00
parent 28aff3f899
commit cfe8271e79
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
content/post/building-libreoffice-online-for-debian.md
View File

@ -1,7 +1,7 @@
+++ +++
Categories = ["Development","Systems Administration"] Categories = ["Development","Systems Administration"]
Tags = ["Development","Systems Administration"] Tags = ["Development","Systems Administration"]
Description = "How to build LibreofficeOnline against stock Libreoffice on Debian Stretch" Description = "How to build LibreofficeOnline against stock LibreOffice on Debian Stretch"
date = "2017-07-06T12:44:53-04:00" date = "2017-07-06T12:44:53-04:00"
title = "Building LibreOffice Online for Debian" title = "Building LibreOffice Online for Debian"
type = "post" type = "post"
@ -12,11 +12,11 @@ draft = false
LibreOffice Online is a very cool project by the fine people at [Collabora](https://www.collaboraoffice.com/code/) to bring the LibreOffice core functionality into a web browser. In effect, it's a Free Software version of the Google Docs suite of productivity tools, allowing one or many people to edit and save documents in a browser. LibreOffice Online is a very cool project by the fine people at [Collabora](https://www.collaboraoffice.com/code/) to bring the LibreOffice core functionality into a web browser. In effect, it's a Free Software version of the Google Docs suite of productivity tools, allowing one or many people to edit and save documents in a browser.
The software builds on the LibreOffice core code, and currently is only distributed as a Docker image, obtainable from the link above. However, my BLSE2 platform does not support Docker now, or at any time in the forseeable future [aside: maybe I'll write my reasoning out, one day], and is based entirely around Debian and the idea of "use the package manager as much as possible". So I set out to build everything myself. The software builds on the LibreOffice core code, and currently is only distributed as a Docker image, obtainable from the link above. However, my BLSE2 platform does not support Docker now, or at any time in the foreseeable future [aside: maybe I'll write my reasoning out, one day], and is based entirely around Debian and the idea of "use the package manager as much as possible". So I set out to build everything myself.
This however was no small task - there's precious little usable information in any one place on how to do this, especially not from the official Collabora site that just wants you to use the Docker image [re-asside: yea, that's one reason I hate Docker...]. Luckily, a GitHub user by the name of `m-jowlett` has written about his processes in a log [over at his GitHub page](https://gist.github.com/m-jowett/0f28bff952737f210574fc3b2efaa01a) [`m-jowett/log.md` should this link eventually rot]. His guide is however extremely rough, as well as using Ubuntu and building for integration with another project featuring OwnCloud. It however gave me most of what I needed to get going with this, including help integrating the final package with my OwnCloud instance(s). This however was no small task - there's precious little usable information in any one place on how to do this, especially not from the official Collabora site that just wants you to use the Docker image [re-aside: yea, that's one reason I hate Docker...]. Luckily, a GitHub user by the name of `m-jowlett` has written about his processes in a log [over at his GitHub page](https://gist.github.com/m-jowett/0f28bff952737f210574fc3b2efaa01a) [`m-jowett/log.md` should this link eventually rot]. His guide is however extremely rough, as well as using Ubuntu and building for integration with another project featuring OwnCloud. It however gave me most of what I needed to get going with this, including help integrating the final package with my OwnCloud instance(s).
As mentioned briefly above, my philosophy in BLSE2 is "use a package" - this is a core feature of Debian, and one of the most solid examples of quality forethought in design in the Free Software world. By separating applications from their libraries, you keep security updates easy and with minimal administrative work. As such, I always choose to build a package if possible, and luckily with LibreOffice Online I can. And it's right there in the repo! A huge win in my mind, especially considering my initial fear of a program distributed as a Docker Image [re-re-asside: poor dependency lifecycle management and monolithic software bundles - another reason I hate Docker; but I digress]. As this is a brand-new project and I'm a keen `dist-upgrade`er, I've gone with the brand-new Stretch (9.0) release in the `amd64` arch - you should probably be running the same, but 32-bit will work too. As mentioned briefly above, my philosophy in BLSE2 is "use a package" - this is a core feature of Debian, and one of the most solid examples of quality forethought in design in the Free Software world. By separating applications from their libraries, you keep security updates easy and with minimal administrative work. As such, I always choose to build a package if possible, and luckily with LibreOffice Online I can. And it's right there in the repo! A huge win in my mind, especially considering my initial fear of a program distributed as a Docker Image [re-re-aside: poor dependency life-cycle management and monolithic software bundles - another reason I hate Docker; but I digress]. As this is a brand-new project and I'm a keen `dist-upgrade`er, I've gone with the brand-new Stretch (9.0) release in the `amd64` arch - you should probably be running the same, but 32-bit will work too.
``` ```
$ cat /etc/debian_version $ cat /etc/debian_version
@ -64,9 +64,9 @@ $ dh_clean
$ git add debian/ $ git add debian/
$ git commit -m "Initial debian folder from Stretch source package" $ git commit -m "Initial debian folder from Stretch source package"
``` ```
Now we can begin modifying the Debian package rules. This is fairly straightforward even without Debian packaging experience. I'll indicate the file edits with `vim <filename>`; you can replace the `vim` with the editor of you choice. The output that follows is a basic `git`-style diff of the changes, as generated as the changes are commited to the custom branch. Now we can begin modifying the Debian package rules. This is fairly straightforward even without Debian packaging experience. I'll indicate the file edits with `vim <filename>`; you can replace the `vim` with the editor of you choice. The output that follows is a basic `git`-style diff of the changes, as generated as the changes are committed to the custom branch.
The first target is the `changelog` file, to tell it we have a new version. Note that the version string (`lool-1`) is chosen specifically because it is "higher" than the official package's `+dfsg1` string. You can validate this yourself using `dpkg --compare-versions`. This ensures that your custom packages will supercede the official ones, should you commit them to a custom repo and upgrade, though in this guide we install them locally with `dpkg`. Note that the formatting of this file must match exactly, including every space and the full date, and feel free to edit the note and name/email as you desire - this is irrelevant unless you intend to distribute the packages. The first target is the `changelog` file, to tell it we have a new version. Note that the version string (`lool-1`) is chosen specifically because it is "higher" than the official package's `+dfsg1` string. You can validate this yourself using `dpkg --compare-versions`. This ensures that your custom packages will supersede the official ones, should you commit them to a custom repo and upgrade, though in this guide we install them locally with `dpkg`. Note that the formatting of this file must match exactly, including every space and the full date, and feel free to edit the note and name/email as you desire - this is irrelevant unless you intend to distribute the packages.
``` ```
$ vim debian/changelog $ vim debian/changelog
@ -157,7 +157,7 @@ $ sudo dpkg-buildpackage -us -uc -j4
dpkg-buildpackage: info: full upload (original source is included) dpkg-buildpackage: info: full upload (original source is included)
``` ```
That last line indicates that the build succeeded; above it, you should see a long list of generated packages in the parent directory. Change there, remove the unneeded `dbgsym` packages, and install all the rest. Note the sudo commands again (due to the permissions of `dpkg-buildpackage`). That last line indicates that the build succeeded; above it, you should see a long list of generated packages in the parent directory. Change there, remove the unneeded `dbgsym` packages, and install all the rest. Note the `sudo` commands again (due to the permissions of `dpkg-buildpackage`).
``` ```
$ cd .. $ cd ..
@ -171,7 +171,7 @@ We now have a working set of POCO libraries and can now begin building LibreOffi
Once the dependencies are in place building the LibreOffice Online package itself is actually fairly straightforward - the repo contains a working `debian` folder, though it too requires some tweaking to work properly. Once the dependencies are in place building the LibreOffice Online package itself is actually fairly straightforward - the repo contains a working `debian` folder, though it too requires some tweaking to work properly.
Begin by making a separate directory, and cloning the git repo; I'm using version 2.1.2 as it's the latest stable one at the time of writing. Note that because the LibreOffice Online devs use tags, we have to actually `cd` into and `git checkout` the right version _before_ we proceed. Then, as we did for POCO, make a `tar` archive for the package build to use containing the source before we start editing anything. Begin by making a separate directory, and cloning the git repo; I'm using version 2.1.2 as it's the latest stable one at the time of writing. Note that because the LibreOffice Online developers use tags, we have to actually `cd` into and `git checkout` the right version _before_ we proceed. Then, as we did for POCO, make a `tar` archive for the package build to use containing the source before we start editing anything.
``` ```
$ mkdir ~/loolwsd $ mkdir ~/loolwsd
@ -215,7 +215,7 @@ $ vim debian/control
services. services.
``` ```
Next we edit the `rules` to add a few missing things. First, we add some additional configuration flags for disabling SSL (instead use a forward proxy; this also prevents build errors) and specifying the library directory; this is needed for the build proess to find the `libreoffice` libraries. We also add a call to `autogen.sh` in the configuration step (missing inexplicably in this version), as well as overrides to the auto-build (to allow `-jX` flags to work). Next we edit the `rules` to add a few missing things. First, we add some additional configuration flags for disabling SSL (instead use a forward proxy; this also prevents build errors) and specifying the library directory; this is needed for the build process to find the `libreoffice` libraries. We also add a call to `autogen.sh` in the configuration step (missing inexplicably in this version), as well as overrides to the auto-build (to allow `-jX` flags to work).
``` ```
@@ -5,7 +5,7 @@ DPKG_EXPORT_BUILDFLAGS = 1 @@ -5,7 +5,7 @@ DPKG_EXPORT_BUILDFLAGS = 1
@ -333,7 +333,7 @@ Last-Update: 2017-06-23
``` ```
Now we install some required `npm` dependencies; the `nodejs-legacy` package will provide our `npm`; don't install the `npm` package itself as this will cause dependency hell. I do this in the main homedir to avoid putting cruft into the repos. Now we install some required `npm` dependencies; the `nodejs-legacy` package will provide our `npm`; don't install the `npm` package itself as this will cause dependency hell. I do this in the main homedir to avoid putting cruft into the source directories.
``` ```
cd ~ cd ~