I had rebuilt the libreoffice-5.2.4 packages for Slackware -current last week, because library updates in Slackware had broken the spreadsheet application ‘localc‘. And voila… not long afterwards the Document Foundation blog announced 5.2.5: “all users are invited to update to LibreOffice 5.2.5 from LibreOffice 5.1.6 or previous versions“. Today on the first of february, we can even witness the 5.3 release.
A list of the most significant new features of LibreOffice 5.3 has been published in a separate document (http://tdf.io/lo53features) and you are invited to watch a series of short videos (http://tdf.io/53vids) if you want to get a taste of what’s on the plate. Collaborative editing is the major highlight I guess. A detailed description of these new features is also available as a web page: http://www.libreoffice.org/discover/new-features/.
I am definitely not building packages right away for 5.3 but I did compile packages for 5.2.5 – albeit only for Slackware -current. I may or may not create these packages for Slackware 14.2 as well and then upgrade the -current package to 5.3. Depends on the other stuff I need to do.
These libreoffice packages are huge in size so please use a mirror for download, and take into account that only the master site and ‘bear’ will have the packages during the first 24 hours.
Note: the LibreOffice browser plugin (NPAPI based) has been removed in LibreOffice 4.4.0: https://skyfromme.wordpress.com/2014/09/25/killing-the-npapi-plugin/
On another note, Chromium (and Chrome) 56 ‘stable’ was released. It’s nice to test the HTML5 feature set on a site like HTML5test and see that it is at the top of all the browsers up there (517 points, only Chrome 56 for Windows scores better because it supports speech synthesis).
Packages for Slackware 14.2 and -current are now available from my repository. No ETA for Slackware 14.1 packages, and perhaps it is time for people still using Chromium on 14.1 to upgrade to 14.2?
As always, here are some common download sites:
- http://www.slackware.com/~alien/slackbuilds/ (US master site)
- http://bear.alienbase.nl/mirrors/people/alien/slackbuilds/ (my own mirror)
- http://alien.slackbook.org/slackbuilds/ (US)
- http://ftp.lip6.fr/pub/linux/distributions/slackware/people/alien/slackbuilds/ (FR mirror)
- http://slackware.uk/people/alien/slackbuilds/ (UK – fast mirror!)
Have fun! Eric
Thank you Eric! Both packages so far are working OK.
I use Chrome from the extras in the official repository, with dark themes for every site but every page load or tab switch flashes that white background on my face. I was wondering, maybe i could download the sources and compile Chromium with a default black background …
I think using a custom CSS style doing that wouldn’t be difficult in any browser. If Chrome/Chromium won’t allow that, there are extensions such as Stylist which would help you.
Thank you Eric!
Eric,
I’d love to hear your opinion on this:
https://bugs.chromium.org/p/chromium/issues/detail?id=686430
Deny, this is no issue for my chromium package. If you do not want Widevine CDM support, simply do not install my chromium-widevine-plugin package.
The above bug report is relevant to Google Chrome only.
And the last comment kind of promises that there will be a new content setting in Chrome/chromium 57 which will allow you to disable EME.
Oh, Eric! This is such a relief, at least for now…
In the way Google had stated before, it looked like they were about to integrate EME in main the main chromium codebase (which in turns serves all other chromium based browsers, Chrome included) in such a manner that it would be difficult, if not impossible, to package maintainers like you build it without the proprietary bits.
This move is not of a HUGE privacy concern, as it would also render any independent party code review almost useless, as US laws require a formal company/manufacturer approval before disclosure any discovery, including in the open source part.
I’m still concerned about W3C positions around EME and other enterprise oriented issues affecting privacy of millions individuals out there. This move from Google is just the most recent development around it. Although the popular demand reverted it in 57 scope, I bet soon enough we’ll talk about this matter again.
Luckily, we are tech savvy enough to access some sort of a cryptic chrome://settings/content to disable the thing. Unfortunately I can’t tell the same about the average jane/joe.
The average jane/joe does not care.
Which is exactly why we, as the nerds, should care for them. 😉
FYI,
I am uploading the libreoffice-5.2.5 packages for Slackware 14.2 now.
Okular of the 14.1 is not working with unrar 5.X in KDE 4.10.5. https://bugs.kde.org/show_bug.cgi?id=319303
Hi Julio, I am not going to fix anything for Slackware 14.1. You are probably posting your bug report here because you just upgraded to my new unrar 5 package?
You can do either of the following: (1) downgrade your unrar package to < 5, or (2) apply the patch you find in the bug report to the ark source and recompile ark, or (3) upgrade to Slackware 14.2.
FYI, after wrestling with the LibreOffice 5.3.0 sources for two days I may have to conclude that this release (for now) can not be built on Slackware-current unless someone writes a patch that allows me to use “–without-system-icu –without-system-harfbuzz”.
Slackware’s harfbuzz is built without support for graphite, so libreoffice rejects the system version, and the build process keeps picking up the system icu (which is a different version than the internal libreoffice copy) even when I specify “–without-system-icu”.
The build also fails when I specify “–with-system-icu” with the error (first of the errors at least):
CommonSalLayout.cxx:(.text+0x1010): undefined reference to `hb_icu_script_to_script’.
That error is probably also related to “–without-system-harfbuzz”.
Thank you for attention, Eric. I simply reported the bug.
Eric,
Christoph is able to build 5.3.0 in 14.2 (not in current). Although icu4c and harfbuzz version are different, but perhaps you can take a look?
https://slackbuilds.org/cgit/slackbuilds/commit/?h=user/chris.willing/updates&id=dc30b2fe663aa8d2367768ed4c231bc1d77c0628
Hi Willy
Looks like he too, needed to switch from system harfbuzz to the libreoffice internal copy of harfbuzz, but I also assume he ran into the same linker issues that aborted the build in my case.
He “solves” that by adding the “ignore errors” parameter “-i” to his make commandline (“make build-nocheck” became “make -i build-nocheck”).
The question is, when you ignore the errors during compilation, will the functionality of resulting binaries be affected negatively?
Hello Eric,
regarding Chromium 56, I think the introduction of the Web Bluetooth API should be mentioned.
Google are saying “It’s safe because we require user interaction before coupling a web page with the bluetooth devices around the user”, but Lukasz Olejnik successfully argues against that (in my eyes):
regards, Johannes
Thanks Eric for building LO 5.2.5 for Slackware 14.2.
Hey, I managed to build libreoffice 5.3.0 for current with my own script. The following patch got me past the CommonSalLayout.cxx:(.text+0x1010): undefined reference to `hb_icu_script_to_script’ issue.
http://pastebin.com/4BKA8qja
Note, you might want to rebase it if you try using it. I applied it on top of these two cherry picked upstream commits which might be unnecessary, but don’t hurt either…
https://github.com/LibreOffice/core/commit/67936ee7ed717eb385b608d7eedcefa61fe13295
https://github.com/LibreOffice/core/commit/47ea13ef8dc8ab9aeded6121845e3ebd1d28b292
orbea, nice patch! I will try that one tonight. Thanks