Latest Debian Security Update Breaks Jessie (Resolved).

In addition to my Debian / Stretch computer, I still operate two Debian / Jessie computers. Those latter two computers were subscribed to the Debian Security repository, as well as to the standard Debian / Jessie repository. Unfortunately, the package manager on one of my Debian / Jessie computers had made me aware of a conflict which existed, due to an update which Debian Security is pushing, to a package and its related packages, all belonging to:

liqt4-dev

The version which Debian Security is trying to install is:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u2

But, the version which the rest of Debian / Jessie was using, was:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1

The problem was the fact that, if I told my package manager to go ahead with its suggested updates, doing so would have forced me to reject a long, long list of packages essential to my system, including many KDE-4-related packages. Now, I can just ignore that this problem exists, and rely on my package manager again not installing packages, that would break my system, on a daily basis. But this would turn into a very unsafe practice in the long run. And so, the only safe course of action for me currently seemed to be, to unsubscribe from Debian / Security instead.

(Update 17h55 : )

I have resubscribed to the Debian Security repository in question, and re-attempted the update, to find that this time, it worked. I can think of 2 possible reasons why it might not have worked the first time:

  1. My unattended-upgrades script is configured to break up an update into smaller pieces, and because this update involves a large number (over 20) of Qt 4 packages, this in itself could have broken the ability to perform the update, or
  2. Debian Security may not have put all the involved updates ‘out there’ on its servers, to be downloadable in one shot, even though every Qt 4 package needs to be updated, in order for any of the updates to succeed. But, only hours later, all the required packages may have become available (on the servers).

I rather think that it was due to reason (2) and not reason (1) above.

Dirk

 

KdeWallet, and Using Smb4K, under Plasma 5

One fact which I’ve written about before, is that I have an up-to-date Linux computer, that uses the ‘Plasma 5′ desktop manager, which is actually the successor to ‘KDE 4′. When using this desktop manager, we can still install numerous packages that ‘belong’ to the old, KDE 4, and most of them will continue to work. One of those is ‘smb4k’, which is a point-and-click utility, to mount a network SMB share – aka, a Windows-file-share, such that it will be visible in our home folder, as though that share was a local sub-folder.

There exist command-line methods to do the same thing, which would mount that network share, and declare it’s of the ‘cifs’ file-system-type, but the use of a simple GUI to do so may be easier.

But then one problem which ensues, is that Smb4K will use the KDE 4 Wallet, to store our password, for that share. It will function in this way, by depending on the package ‘kde-runtime’. In truth, this latter package probably pulls in numerous (old) KDE 4 libraries, and not just the old KWallet, but the existence of this KDE 4 Wallet, on our Plasma 5 machine, is most obvious…

Continue reading KdeWallet, and Using Smb4K, under Plasma 5

LXDE and Plasma 5 .desktop -Files don’t meet the same requirements.

I’ve just switched a Linux computer of mine from the LXDE to the Plasma 5 desktop managers, because Plasma 5, the successor to KDE 4, is infinitely more-powerful. But then there were some issues with the transition, that may be relevant to my readers, if the readers also wish to switch desktop-managers, on an installed Linux computer.

One fact which I learned, was that even though LXDE and Plasma 5 both use .desktop -Files to launch applications, each system’s .desktop Files are different.

There is a directory named:

‘~/.config/autostart’

In which we find .desktop -Files that are to be run when the user first logs in. And we may find that the initial log-ins don’t run those files:

screenshot_20171017_083544

Also, because the configuration in question is just a set of files, trying to click on these entriesĀ  in the Plasma 5 settings center does not enable them.

One main reason for which this happens, is the fact that the professional who set up these configuration files, gave the original ones a line that goes like this:

OnlyShowIn=XFCE;LXDE;LXQt;

On my system, this fact was a life-saver, because the LXDE version initially had Compiz installed, which is a fun compositor, but which is not compatible with KDE or Plasma 5. If that had launched, it would have messed up my first attempt to establish a Plasma 5 session.

But there exist other applications which I’d want to have run, even if I’m logging in to Plasma 5, for which reason I used the GUI, to create a Plasma 5 -compatible launcher for the script that updates my version of Flash to the latest version:

screenshot_20171017_083357

And I edited-in a line with a text-editor, which now goes:

OnlyShowIn=KDE;

The exact appearance of the icons here is purely coincidental. But if we wanted to transfer such scripts to:

‘/etc/skel’

Then a big problem for a user like me would be, that scripts which we created in our own home-folders, are likely to contain configuration-details, which will only work for the one user who created them. And so I kept this .desktop -File spartan, to make sure that it will work, regardless of whose home-folder it eventually ends up in.

Dirk