## 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

## My system for switching between compilers needed an overhaul.

According to what I had written in earlier postings, I had co-installed a Debian Jessie / Security version of the GCC / CPP / C++ compiler system, which had version 4.9.2, alongside the official versions, which were 6.3, on the Debian / Stretch computer I name ‘Phosphene’. There was a problem in how I had done that. If next, the Package Maintainers had pushed through an update to their official compiler, the update would have broken my link groups – in a devastating way. And so what I needed to do was to rearrange those link-groups, to make them compatible with this scenario. The result is as follows:

dirk@Phosphene:~$su Password: root@Phosphene:/home/dirk# update-alternatives --config cc There are 2 choices for the alternative cc (providing /usr/bin/cc). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/gcc 20 auto mode 1 /usr/bin/gcc 20 manual mode 2 /usr/bin/gcc-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config cpp There are 2 choices for the alternative cpp (providing /lib/cpp). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/cpp 20 auto mode 1 /usr/bin/cpp 20 manual mode 2 /usr/bin/cpp-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config c++ There are 2 choices for the alternative c++ (providing /usr/bin/c++). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/g++ 20 auto mode 1 /usr/bin/g++ 20 manual mode 2 /usr/bin/g++-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# ls -l /usr/bin/gcc lrwxrwxrwx 1 root root 5 May 3 10:58 /usr/bin/gcc -> gcc-6 root@Phosphene:/home/dirk# ls -l /usr/bin/cpp lrwxrwxrwx 1 root root 5 May 3 11:01 /usr/bin/cpp -> cpp-6 root@Phosphene:/home/dirk# ls -l /usr/bin/g++ lrwxrwxrwx 1 root root 5 May 3 11:24 /usr/bin/g++ -> g++-6 root@Phosphene:/home/dirk# exit exit dirk@Phosphene:~$

Dirk Mittler

## A fact about how software-rendering is managed in practice, today.

People of my generation – and I’m over 50 years old as I’m writing this – first learned about CGI – computer-simulated images – in the form of ‘ray-tracing’. What my contemporaries are slow to find out is that meanwhile, an important additional form of CGI has come into existence, which is referred to as ‘raster-based rendering’.

Ray-tracing has as advantage over raster-based rendering, better optical accuracy, which leads to photo-realism. Ray-tracing therefore still gets used a lot, especially in Hollywood-originated CGI for Movies, etc.. But ray-tracing still has a big drawback, which is, that it’s slow to compute. Typically, ray-tracing cannot be done in real-time, needs to be performed on a farm of computers, and typically, an hour of CPU-time may be needed, to render a sequence which might play for 10 seconds.

But, in order for consumers to be able to play 3D games, the CGI needs to be in real-time, for which reason the other type of rendering was invented in the 1990s, and this form of rendering is carried out by the graphics hardware, in real-time.

What this dichotomy has led to, is model- and scene-editors such as “Blender”, which allow complex editing of 3D content, often with the purpose that the content eventually be rendered by arbitrary, external methods, that include software-based, ray tracing. But such editing applications still themselves possess an Editing Preview window / rectangle, in which their power-users can see the technical details of what they’re editing, in real-time. And those editing preview windows are then hardware-rendered, using raster-based methods, instead of the final result being rendered using raster-based methods.

## Debian WordPress recently received an update.

One of the facts which I’ve blogged about before, is exactly, what blogging platform I’m presently using. I subscribe more to ‘WordPress.org’, and less to ‘WordPress.com’.

This synopsis is a bit over-simplified. The actual WordPress version I have installed is the one that ships with Debian / Jessie, aka Debian 8, from the package manager. But that doesn’t mean we don’t receive security updates. I actually tend to trust the Debian Maintainers more, than WordPress.org, to keep the platform secure. They’ll downright snub features, if they find the feature poses any sort of security threat.

And in recent days, this Debian build of WordPress did receive such a routine update. The main reason I take notice of such things is, the fact that my personal WordPress installation is modified somewhat, from what the package maintainers build. This still allows me to download a modest set of plug-ins from WordPress.org, as well as one plug-in from WordPress.com.

I’m happy to say that no snarl took place, between the recent Debian-based update, and my custom-configured blogging platform. Service was never disrupted.

Dirk