Alien Pastures

My thoughts on Slackware, life and everything

Tag: chrome (Page 9 of 14)

This week’s updates: Chromium, LibreOffice, Flash

May 25, 2019 / / 13 Comments

There was an update to Chromium browser code this week as announced a few days ago by Google. I built new Slackware packages for Chromium 74.0.3729.169 and uploaded them earlier this week to slackware.com and slackware.nl (or you can use any mirror site of course).
There were two intermediate updates to Chromium 74 which I did not compile & package. Both versions address a couple of security issues (CVE’s), but at the time I was unable to work a computer. It’s therefore a good idea to upgrade to this new package.

 

Also this week, the Document Foundation released version 6.2.4 of their office suite LibreOffice. I have built and uploaded sets of packages for Slackware 14.2 and also for -current, 32bits and 64bits.

I had some issues with the visibility of LibreOffice icons in its toolbar recently (last couple of versions of LibreOffice that I built actually).
I am using LibreOffice on Slackare-current with Plasma5 and in the profile script “/etc/profile.d/libreoffice.sh” I have uncommented this line because the GTK+3 widget set usually gives the best possible interface for LO in a Plasma5 desktop:

export SAL_USE_VCLPLUGIN=gtk3

However, icons would not show unless you moved the mouse across them, or sometimes even that would not work. In other words, it made working with LO impossible unless I switched the widget support to “generic’ by uncommenting “export SAL_USE_VCLPLUGIN=gen” in aformentioned profile script instead. But that results in a butt-ugly interface.

By chance I found out that this is caused by a setting in LibreOffice itself. Go to “Tools > Options > Libreoffice > View > Icon Style” and I noticed that the style was set to “Automatic (Breeze)”. I selected “Elementary” instead and voila, I had a working toolbar with visible icons again. For some reason, the integration of GTK+3 applications in Plasma5′ QT5 based interface using the ‘breeze-gtk” package is not fully compatible with the LibreOffice icon handling.
Just so you know.

And finally, there were fresh security updates on the Adobe website for their Flash player plugin. The new version 32.0.0.192 which was released last week (but I missed it) was announced in a security bulletin. I built the packages for the Chromium-compatible and Mozilla-compatible browsers so that you can visit Flash-based web sites safely again (or of course you abandon the use of Flash entirely).

Who is still using these Flash plugin packages?

 

Where to find my packages? In any case, on these three sites. And slackware.nl as well as slackware.uk also offer rsync access:

Have fun! Eric

Chromium 74 available in my repository. Also for 32bit Slackware.

April 26, 2019 / / 3 Comments

The Chromium 74 sources were released a few days ago by Google, and it comes with a long list of fixes for security issues.
I spent almost two months to investigate why the 32bit package could no longer be built (which is one of the reasons why there were so few updates in march and april – I only have a few hours every day that I can spend on Slackware these days) and had finally managed to compile a 32bit package for Chromium 73 in a 32bit chroot environment on a 64bit Slackware OS, and that package was online for one day…. and now I tried compiling the new release on a regular 32bit Slackware OS and that worked! No idea whether this is because of my modifications of the SlackBuild.
The packages for chromium-74.0.3729.108 are now ready for download from slackware.com or slackware.nl, or any other mirror.
I verified that the Widevine CDM (for Netflix movie streaming) is still working.

Also, I uploaded new versions (32.0.0.171) of the Adobe Flash plugin for Mozilla– and Google-compatible browsers. These too come with critical security fixes.

Last week’s updates: Chromium and VLC

September 11, 2018 / / 23 Comments

Last week the Chrome (and Chromium) update to release 69 was in the news. The UI changed significantly, sporting more of Google’s material design elements. Also the password manager has been improved: it will suggest random passwords in cases where you have to create a Web account and will offer to remember the random password in its vault so you don’t have to write it down or remember it (you’ll have to be signed into your Google account to be able to use this feature though).
The ‘omnibox‘ (the area where you type your URLS and search queries) is more powerful now, showing many more related results while you are typing.
My package for Chromium supports direct playback of H.265/HEVC video by the way, and has done so for the past releases. Check it out for instance on https://www.h265files.com/embed-h265-video.php . Not many other browsers (even other distros’ Chromium browsers) will do that.

Not just UI changes/improvements in version 69.0.3497.81 but also many (some severe) bugs were addressed in this release. Read all about that in the Google blog post.

A package for Slackware 14.2 (32bit) took a bit of time because I kept having segafaults in clang++ but an update to the latest patches for Slackware 14.2 put an end to these segfaults. Packages for Slackware 14.2 and -current are awaiting your download.

FYI: Just today an update was posted and a new version 69.0.3497.92 of the Chromium source code was released. I will see when I can compile packages for that, but it will probably not be this week.

And then there was a new release of the VideoLAN media player, VLC, last month. I took a while to reserve some time on the build box to create packages for Slackware 14.2 and -current, but they are done now. The release 3.0.4 did not get any attention on the VideoLAN news page (yet?), but there are plenty of fixes that are relevant for Linux users.
Remember that this VLC depends on Qt5 – you’ll need libxkbcommon, qt5 and qt5-webkit packages, and on Slackware 14.2 additionally libinput and libwacom (those two are already part of -current).

You know where to download the packages, don’t you? The new versions of Chromium and VLC are also present on the latest Plasma5 Live ISO image for Slackware.

Have fun! Eric

Chromium 64 – and 32bit pain

January 29, 2018 / / 7 Comments

The new release of the Chromium sources gives us version 64 of Google’s browser. I have created Slackware packages for you, but that was not entirely trivial.
The Chromium compilation on my 32bit Slackware OS kept failing on the embedded ffmpeg. I am afraid the fact that some of the bigger distros are dropping 32bit variants starts showing and things are coming apart at the seams.
When you are a developer and there’s no 32bit release of your favorite OS, this makes it quite difficult to test the validity of code paths when you only compile and test your code on a 64bit platform. This is what’s happening with Google’s Chromium code and it will probably only get worse.

For now, I could get away by disabling assembly code in the 32bit avcodec library, but in order to get that going I had to study the Chromium code carefully – Google does not use the standard autotools or cmake configurations that the Average Joe would employ when compiling ffmpeg, instead they re-invent the wheel every so often to keep everyone on edge. First it was Gyp, but that did not work out too well and the current fad is called GN (as Google state themselves “GN is a meta-build system that generates Ninja build files so that you can build Chromium with Ninja“).

Some time soon, I need to dissect Chromium’s embedded ffmpeg code, to see if I can get assembly code compiling again on 32bit. Else it may be more prudent to start depending on an external (system-wide) ffmpeg installation, which I can compile without any pain on 32bit Slackware.

We’re fine for now, at least. Let’s hope it does not get worse.

Get your chromium 64 packages for Slackware 14.2 and -current:

Cheers, Eric

Hello Chromium 63 – goodbye NaCl

December 18, 2017 / / 15 Comments

December usually is a busy month, with the focus at work to wrap up as much of the ongoing projects as possible and prepare for the christmas holidays. And when there’s a lot of (paid) work to do, the voluntary work gets second place. That’s why there was not really a lot of time to churn out a Chromium 63 SlackBuild script. Two weeks ago the first sources for release 63 appeared online and fixed a lot of (security) bugs. Last week saw an update and this is what I grabbed and packaged, because you can’t wait too long with addressing security issues.

Those of you who had examined my chromium-dev.SlackBuild a while ago will already know that the SlackBuild for versions beyond 63 needed a bit of re-work to cope with changes at the source level. I am glad I did that in November, as it made the transition for the stable browser much easier.

Starting with this package, I am no longer compiling (P)NaCL by default. NaCL, or the Native Client, is a way to run applications in a sandboxed browser process at near-native speed. The PNaCL binaries are platform-independent which means one executable (.pexe) can run in Chrome/Chromium browsers on all supported platforms/architectures. Google announced in May 2017 that it would stop supporting NaCL in the first quarter of 2018 in favor of WebAssembly which is a new cross-platform cross-browser solution to run high-performance applications. Both Mozilla’s and Google’s browsers already support WebAssembly, Microsoft and Apple are getting there too. You can experience an impressive WebAssembly demo here: The Zen Garden based on Epic’s Unreal Engine.

You can of course recompile the chromium package if you need NaCL. The chromium.SlackBuild script defines a variable “USE_NACL” which used to be set to “1” and now defaults to “0”. If you set it back to “1” and run the SlackBuild script, you will get your NaCL support back.

The reason that I stopped compiling NaCL support is pretty basic.
Last month it became clear to me that many Google developers are not caring about anything else than their own ecosystem. Call me naïve. The compilation issues I was experiencing with the GCC compiler were dissed with a remark that internally, Google uses a patched version of Clang which does what they need and standards-based code is not really at the top of their list. Any issues I had with gcc (along with packagers of other distros), they were not going to fix. The anticipated but unhelpful answer was to just download and use Google’s Clang binaries. But that goes completely against the idea behind my own chromium package… do not rely on the Google binaries (aka Chrome) and instead build natively on Slackware.
It forced me to find a way to compile the Chromium sources using their ‘Google hack’ of the Clang compiler.
So when helpful people at Google (they too exist of course… not all of them are so single-minded) showed me how to download the Google Clang sources, compile that first and then use those binaries to compile Chromium in turn, it dawned on me.
All this time I had been downloading and using Google binaries anyway: the (P)NaCl code is compiled using a pnacl binary toolchain which gets downloaded from Google during the compilation of the Chromium sources. That was the moment where I took the decision to stop with providing NaCL support in my package, and make sure that all the binaries I need for the chromium package are compiled natively on Slackware.

Get chromium 63 packages for Slackware 14.2 and -current:

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑