Updates Suck (Part 2): KDE Plasma 5.5 breaks task manager minimized application display

If you’ve recently updated to KDE Plasma 5.5, you may have noticed that minimizing your applications no longer produces a noticeable effect in the task manager. (In actuality, the status effect of minimized versus non-minimized applications is limited to a thin, gray outline around the application title–hardly something that conveys application state well enough to process visually at first glance.)

The fault of this change lies with this bug report posted almost 3 years ago. After much discussion, it was decided that 1) the “disabled” state of minimized applications was a mistake, 2) the minimized state makes it too difficult for some people to locate the gray scale application icon, and 3) no one wanted to add a configuration option to enable or disable this feature, so the next best thing was to rip it out. Now, I’ll be honest: Maybe I just happen to have better-than-average pattern matching capabilities in my visual cortex (doubtful), but the gray scale icons for minimized applications really don’t bother me. What does bother me is this change: It takes me twice as long to find minimized applications on the task manager. To say nothing of the fact that two or three people complaining incessantly for 3 years can effect such a substantial change on the rest of us who actually liked the feature…

Humorously, I didn’t notice this change during the initial update. Since I spread my work out across multiple desktops, I don’t often minimize my applications. This explains, at least in part, why it took three days for me to discover this problem and make a post about it (and why I blamed it on plasma-shell’s propensity to crash all the time, although that seemed like a reasonable explanation in lieu of anything more substantive).

The good news is that I traced it down to this commit which turned off the minimized gray scale display. As expected, removing this patch returns the task manager’s display of minimized applications to its previous state. The bad news is that, yes, you do need to recompile plasma-desktop from source. If you happen to use Arch Linux, I’ve put together a PKGBUILD containing the fix based off the PKGBUILD in ABS (hence why I haven’t yet changed any of the credits–I should note that this is not an official package). I’ll keep this updated as best as I can until such time that upstream finally settles on a better idea than a 1 pixel gray outline for non-minimized applications.

The rest of you will have to apply the patch and build the sources yourself. Sorry about that.

No comments.
***

Updates Suck (Part 1): Firefox 43, HTML5 breakage, and more

Sometimes, updates are awful. They break things, they undo configuration options you were sure you had set at some point in the past (either resetting them to defaults or removing them entirely).

I updated my Arch install for the second time in two days in the hopes that some minor bugs would be resolved (more on that in another post), but I hadn’t noticed that Firefox was included in the update list (version 42 to 43). Sadly, not only did this break Firefox’s appearance using oxygen-gtk, but it also broke HTML5 video. Every video on Youtube refused to load following the updates unless Flash was enabled (I have it disabled), and I couldn’t figure out why. A new profile proved somewhat useful: Youtube would work–unless I copied my old profile over in bits and pieces.

After about a half hour of exploring, I found that the culprit was actually in the profile’s prefs.js. In particular, because I had found some instructions on enabling HTML5 under Linux, apparently there were some configuration options that are no longer used and conflict with Firefox 43, which enables many of these by default.

If you encounter a similar problem, the fix should be relatively easy. Simply remove:

user_pref("media.fragmented-mp4.exposed", true);
user_pref("media.fragmented-mp4.gmp.enabled", true);

From your prefs.js, restart Firefox, and verify that it still works. If not, try removing all of the media.* preferences. If that still doesn’t work and you’re a user of FlashBlock, try uninstalling it and removing any residual preferences (also from prefs.js).

I used to recommend using FlashBlock in combination with NoScript to reduce the browser’s attack surface, but as fewer and fewer sites I encounter actively use Flash, I find that disabling the plugin (settings, addons, plugins) works best for me. Unfortunately, the author included a new feature to block HTML5 video by default, and I’ve found that it tends to cause breakage with some sites, most notably Youtube. Since then, I’ve had the plugin disabled, but as I no longer have a need for it, why keep it around?

Hopefully, if you’ve encountered a similar problem with HTML5 video, the suggested fixes here will work for you. If not, feel free to leave a comment or pester me on Twitter (@zancarius).

(I still haven’t gotten Firefox 43 to play nicely with oxygen-gtk3, so I may eventually consider abandoning the theme–though I find breeze-gtk still contains a variety of display bugs that make it unpleasant to use.)

No comments.
***

Updating an ancient Arch Installation

A close friend of mine recently decided it was time to update his Arch Linux installation. It had been over a year since the core OS was completely updated, and I did everything I could to discourage him from trying the usual pacman -Syu. The problem, for all intents and purposes, is that I knew it wouldn’t work. Much of the file system structure has changed dramatically over the course of the past year (the /lib move and the more recent merging of /bin and /sbin into their /usr counterparts) and a straightforward update was now difficult (but not impossible–more on this in a minute). Specifically, the glibc and filesystem packages have gone through several iterations even last July and would now be permanently blocking each other thanks to these two updates with no immediately obvious path forward.

I have observed some comments dismissing the update process from a pre-systemd installation as virtually impossible. While I suspect this is because the individual(s) asking for help are seen by others to be insufficiently experienced to do such an update, I’m not a particularly huge fan of the term “impossible” as it pertains to difficult feats–even for the inexperienced. After all, few things are truly impossible; it’s simply a matter of how much time and energy one is willing to invest in working toward a specific goal. Besides, if the recommended solution is to reinstall, why not figure out an optimal way to upgrade an “impossible” system? If it’s going to break either way, we may as well have some fun with it. (You have backups, right?) Even if you don’t have the necessary experience or knowledge relating to the underlying system, there’s no time like the present to begin the learning process.

So, Thursday evening, I set out looking for a solution. Fortuitously, I had an old Arch Linux virtual machine installed on my desktop (which, conveniently, is also Arch Linux) that dated back to approximately the same kernel revision as my friend’s (v3.3.6 for mine; v3.3.4 for his) and roughly analogous software. Like his system, my VM was also a pre-systemd installation, was still running glibc 2.15, and a very early version of filesystem-2012. In many regards, my VM was more or less in a state identical to that of the machine we needed to fix. However, the problem was compounded by an additional requirement. Console access was somewhat tedious for my friend to obtain because of the systems he had to go through, and he was exceptionally busy the afternoon we planned the updates. So, I had to to keep network access (particularly SSH) up and running as best as I could.

Disclaimer

This narrative guide is intended as general reference for anyone who might be in a similar situation: Pre-systemd, pre-filesystem moves, and operating with a requirement that the machine be (mostly) network-accessible throughout the duration of the update. Be aware that nothing in this guide should be considered authoritative. I am a user of Arch Linux. There’s still much about system internals (and Linux in general) that I don’t know or don’t fully understand. Consequently, I’m always learning, and there may be better alternatives to specific problems encountered during this update process. However, I do know enough about Arch to recommend that you never use –force unless you’re specifically instructed to do so. At no point during this update process should you use it. Doing so will assuredly destroy your system, and you’ll be forced to reinstall.

Secondly, this update process is not supported by the Arch Linux developers. If you have failed to maintain your system by keeping it up-to-date (and updating your Arch Linux installation is one of the core tenants of being an Arch user), you’re unlikely to receive much help since you’ve already established that your OS has been inadequately maintained. Furthermore, this update process relies on tricks using partial updates which are also unsupported. The developers and users of Arch who frequently the forums are nice folks who have lives outside of Arch, and due to the tremendous task presented to the community of supporting a relatively large user base, it’s impractical for them to spend a significant chunk of their time helping you with issues that–to avoid mincing words–are the fault of no one but yourself.

Thus, I hope this guide will be useful to those of you who may have a neglected Arch Linux box under your care. Be aware that I have targeted this guide to a system that was last updated somewhere in mid-2012. Although it should work for earlier systems, I’d highly recommend reading through the Arch news archives if you’re updating such a beast. You can usually determine where you need to begin by examining the version of your filesystem package, e.g. pacman -Qs filesystem. This guide should be general enough such that even if it doesn’t help you determine the exact update path for your system, you’ll be able to figure out where to get started.

Also, be sure to read through the guide in its entirety first. Check your installed packages, and make sure you’re not downgrading them. filesystem and glibc should never be downgraded at any point during this update otherwise you may exacerbate system breakage. This guide illustrates the update process with the x86_64 architecture. If you’re using a 32-bit system, you’ll need to replace all references to x86_64 with i686.

Read more…

No comments.
***
Page 1 of 212