What To Do About Plasma 5 No Longer Having KDict

One of the facts which I’ve written about often, is that I’ve set up a fairly recent computer using Kanotix / Steelfire as a tool, and which has successfully resulted in a Debian / Stretch system, that has Plasma 5.8 as its desktop manager. This computer is named ‘Plato’. And I’ve written some observations about Plasma 5.

What I have never written about, is that there exists a Web-compatible protocol for Dictionary services, that predates Google or Bing, and which is simply known in the Linux world as ‘dictd’. The second ‘d’ stands for Daemon and distinguishes the daemon from client-programs, that will ask the daemon the contents of its dictionary. If you will, a daemon is a kind of lesser server.

With ‘dictd’, we may have our own daemon installed, and can even query one daemon from multiple clients on our LAN. Or, we can just use client-programs, and query standard daemons that are available on the Internet, and that usually have larger databases.

But even to query a remote daemon easily, is more fun, if we have a GUI front-end to do so with, instead of merely a command-line interface. As it happened with KDE 4, there was a client GUI called ‘KDict’, but under Plasma 5 I can’t find it anymore.

And so what I’ve done as a workaround, is to configure ‘Ding’ as my ‘dictd’ client instead.

‘Ding’ has always been a fun program for me, personally, to work with, because what it does most-easily, is provide up-to-date English-German Translations. But in reality, to use its full power, requires that we reconfigure it slightly for use with Debian / Stretch … Plasma 5.

screenshot_20180114_193539

First of all, the English-German translation-mode only works, if we have the package ‘trans-de-en’ installed. This has usually given me enough fun.

Continue reading What To Do About Plasma 5 No Longer Having KDict

How To Install Yafaray Under Linux

One of the computing subtopics I dabble in, is the acquisition of 3D-graphics software. Therefore, I already have “Blender 2.78a”, which has its own built-in software-rendering engine, and I have several other rendering engines installed on my Linux-based computers.

Further, the rendering engines by themselves can be useless, unless they integrate well with a GUI (such as with Blender). And so one undertaking which I’ll typically reach with a given computer, is to install “Yafaray”, which used to be ‘Yafray’, which stood for ‘Yet Another Free Ray-Tracer’. If it’s installed properly, Blender can render its scenes, using Yafaray, but from within Blender.

Yafray used to be a much simpler piece of software to install than it has become. But I’m sure the effort I put into it this evening, will be well-worth it eventually. What I’m used to doing is to download a source-tree, and if it’s CMake-based, to run ‘cmake-gui‘ on it, to custom-pick my build options, and to go. But as it happens with Yafaray, this approach led to near chaos. What this did, was to compile all the source-code properly into libraries, but then to install those libraries to nonsensical locations within my system folders. One reason was the fact that a part of the project was to create Python 3 bindings, and another was the need for the Blender-integration, where modern Blender versions are based on Python 3. In any case I was sure to install all the build dependencies via my package-manager, but doing so was not enough to obtain working outcomes.

funbutterflysphere3-0001

Continue reading How To Install Yafaray Under Linux

Debian Category Missing From Plasma Menu.

I use several Linux-based computers, which include an older machine running Debian / Jessie and the KDE 4 desktop manager, and a more-recently-installed machine, running Debian / Stretch and the Plasma 5.8 desktop manager.

Under KDE 4 – which I’ve grown used to over the years – the K-Menu – aka, the Application Launcher – would display a nested menu-system, that included the KDE categories into which applications should fit, which are defined essentially by ‘.desktop’ files, plus a separate category called ‘Debian’, which was denoted by a folder-icon, and which was nested several levels deep, into which almost every installed application should be sortable, defined essentially by the contents of the directory ‘/usr/share/menu’.

k-menu_1s

Under my Plasma 5.8 setup, one fact which I was missing, was the earlier presence of this Debian -category:

k-menu_2s

 

Instead, this computer has a larger abundance of entries, in its Lost+Found category (not shown), which is really just another way of saying, ‘entries which it cannot otherwise put into categories’. In fact, many of the entries that now occur under Lost+Found, also occur under listed categories.

(Updated 12/14/2017 : )

Continue reading Debian Category Missing From Plasma Menu.

Burning UDF 2.01 File Systems under Linux using a Script

In certain earlier postings, I wrote about the possibility of burning Blu-rays using the UDF File System, but using the GUI-application ‘K3b’, under Linux. One big problem with this approach was, that the version of UDF being applied was only 1.02, and that it was part of an ISO9660 / UDF bridge-format, which the earliest ISO9660-capable devices are able to read because of the ISO9660 backwards-compatibility, but which would present some of the error-correction capabilities that UDF is supposed to offer, to more-modern devices, via UDF 1.02 .

The issue with this would be, that UDF 1.02 may still not be robust enough, in its error-correction, and that we wish to burn UDF 2.01 File Systems, using open-source software, under Linux.

(Edit 10/22/2017 :

Actually, my recent findings seemed to suggest, that if we use ‘cdrecord’ to burn a Data-Disk Project, the UDF version it applies may already exceed that standard. )

This posting will describe how such a File System can be written using a script, which I have tested myself, but which does not offer any type of GUI at all.

First of all, in order for this to work, our Linux computer needs a reasonably recent Kernel version, because what the script will do is create an empty UDF File System, and then mount that as a loop-device, so that the same script can batch-copy the contents of the Present Working Directory, (the PWD, as it’s called under Linux,) to this File-System, after which the FS is unmounted, and burned onto a Disk.

If our Kernel-version is not recent, then to mount and/or to batch-copy may fail, and for no other reason. I’ve tested this to work using Kernel version ‘4.4.0-30-generic’, which is by far not the standard Kernel-version that my Debian / Jessie repositories would offer.

Another prerequisite is, the package called:

‘udftools’

Which we would use to create the empty File System, but which we won’t be using to do anything other than that. ‘udftools’ can be installed using our standard Debian package-manager, and offers support up to UDF 2.01 as its maximum. This package also contains the commands for growing a UDF File System, ‘wrudf’, but because I did not trust the package-version of UDF being offered, I chose not to use it. ‘wrudf’ is supposed to work somewhat like the ‘growisofs’ command would work, within a GUI-application such as K3b, but K3b does not recognize it out-of-the-box. In fact, I do not envy anybody, who needs to use ‘wrudf’ to grow their UDF File System.

This is the script which I have tested:

 

#!/bin/bash

if [ ! -e "/dev/sr1" ] ; then
	exit 1
fi

if [ ! -x "/usr/bin/mkudffs" ] ; then
	exit 1
fi

if [[ $UID -ne 0 ]] ; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

rm -f /tmp/image.udf

echo "Creating Sparse File..."
truncate -s 24G /tmp/image.udf

echo "Formatting File System..."
mkudffs --media-type=dvdram --spartable=2 --vid="BD_$1" /tmp/image.udf || \
	exit 1

echo "Mounting File System..."

mkdir -p /media/udfimage || exit 1

mount -t udf -o loop,rw /tmp/image.udf /media/udfimage
rm -rf /media/udfimage/lost+found
chown -R root:root /media/udfimage

echo "Writing to File System. This may take some time..."
cp -rf ./* /media/udfimage

echo "Unmounting File System..."
umount /media/udfimage

echo "Burning File System. This may take some time..."

unset SUDO_COMMAND
export GENISOIMAGE=/usr/bin/genisoimage

growisofs -dvd-compat -Z /dev/sr1=/tmp/image.udf

echo "Cleaning Up..."
rm -f /tmp/image.udf

eject
echo "Done."


 

There are a few observations about this script, which anybody would wish to know about, who might want to use it. First of all, this script will expect one command-line argument, which is going to be prefixed with the string ‘BD_’ and then applied as the volume-ID of the file-system to be created. This will appear on computers, and on some playback-devices, as the name of whatever disk we have inserted. The exact naming is not critical, just as the exact naming for ISO9660-based Volumes may not be critical. It’s a formality which should be taken care of.

Secondly, this script expects to be run while the PWD is whatever directory we wish at the root of our created File System, and expects to be run as root. This poses an obvious security gap, as anybody could use this script in order to burn a copy of a folder, which he or she never had permission to read, if he could get root privileges with this script.

I have done my best to allow this script to be run using ‘sudo’, if it was placed in my system-directory:

‘/usr/local/bin/UDF-Burn.sh’

But, I have never tested whether it can be made to run using ‘sudo’ in this way. It might not, because it consists of a shell-script, which might only cause the script-interpreter to be elevated to ‘root’, but not all the commands within the script! My readers may test this as they wish, but since I’m the only real user of my own computers, I’ve always just felt comfortable to make myself ‘root’, and then just to run this script.

In the interest of allowing this script to be run via ‘sudo’, I have set the variables ‘SUDO_COMMAND’ and ‘GENISOIMAGE’ as would be appropriate. This has to do with the behavior of ‘growisofs’ to use an external helper, in order actually to grow certain types of File Systems, and an unscrupulous user could run this as ‘sudo’, and could set this external command to be anything he wanted it to be. It would allow an unscrupulous user to execute an arbitrary program as root, if my script did not take care to re-set this variable to the correct path.


 

The reader may be reassured to know, that by default, if one of his scripted commands throws an error, the execution of the script will continue after that command, as if nothing had gone wrong. This discovery actually cost me several blank disks, until I had sprinkled a few error-checking commands into it.

Hence, the output which the user sees could be:

Error: ‘/tmp/image.udf’  Is A Directory

After which Bash will try to keep running the rest of the script… And then, the next important question becomes, whether the ‘mkudffs’ command can eventually still execute successfully, which I did bracket, If it cannot store the File-System Image it creates at that location…

I also figured, that I was more likely to uninstall the package ‘udftools’ by accident, than I was, eventually to downgrade the kernel, on a computer which I had already established, could mount a UDF 2.01 File System correctly. But, if the reader has such fears, he can also just add:

|| exit 1

To the mount command…


 

I suppose another observation I should add about how this script will behave, is that it will create an empty, 24GB File-System Image right off the bat, and start to build the data within. A possible nuisance, because this would represent the total amount of raw space that a device would hold – unformatted – and the entire 24GB will be written to the Blu-ray disk every time the script is used, regardless of how little data we might actually want written to the disk. I chose 24GB because the true amount of raw space on a single-layered Blu-ray is actually ~24.8GiB, and the format does not allow for fractional values to be put on the command-line. So for our purposes, we only have 24.0GiB of raw, unformatted space to work from.

I suppose I could have sat down with a calculator, to determine that 24.7GiB ~= 25292MiB …

(Updated 10/24/2017 : )

Continue reading Burning UDF 2.01 File Systems under Linux using a Script