This script provides various fixes for SolydXK installs. The first versions were created to ease processing of the SolydXK Home Editions' July 2014 Update Pack. The description of those earlier versions is still available here.
The ISO build funtions that were part of solydfixes have been moved to a separate package.
To be honest, I doubt this script is particularly useful for upgrading at this moment in time, as the switchover from the Home/Business Editions to the current Main (or Enthusiast's) Editions was in January 2015. Anyone still running the old editions will probably be better off reinstalling from a recent ISO. However, if you enjoy turning a hopelessly out of date setup into a real mess...
The --help option of the script currently provides this list of functions and options:
Usage: solydfixes [OPTION/ARGUMENT]... General options: -h, --help display this text and exit -l open the log in an editor after the action -s FILE use FILE as settings file instead of solydfixes.conf -y use the --yes option with apt-get (see apt-get manpage) --remove [+log] remove an installed set, optionally including the log files Arguments with related options (if any): upgrade upgrade a SolydXK Home or Business Edition to Debian Jessie -S upgrade to Debian Stable instead of Jessie -T upgrade to Debian Testing instead of Jessie -W upgrade a Business Edition to Debian Wheezy (OldStable) dmo remove deb-multimedia.org (DMO) packages and repository get download the most recent version of this script gksu fix gksu not working because of a limited xhost setting kdbbs disable browser bookmark searching in Kickoff -p make this persistent qtev select the new QtCurve/Evolvere theme swmanager fix some menu issues with Software Manager tmp fix incorrect /tmp to /var/tmp linkage vbox remove superfluous VirtualBox guest addition modules You need to specify one or more arguments. Without them, this script will do nothing.
Version 3.0.0 of the script is available in a tarball (SHA256 hash is 4d95343a0326ce3b683e1b58a0f76bce7d1ca96d83b1553e2ef2a67acff09e24) - gpg signature is here). This links to a text file with some release history..
Earlier versions could also be downloaded as a single (text) page, but this is no longer supported.
Most of my scripts are not distributed as Debian packages but supplied in tarballs. This means you cannot install them using your package manager, but have to download the tarballs and 'install' them yourself. Just create a directory called solydfixes anywhere you like and extract the tarball to it, keeping the layout/structure intact. Any good file manager should do that automatically if you select 'Extract here' or 'Extract to...' from its context menu (yes, I know Thunar messes that up - I did write 'any good file manager'...).
You can run the script from the terminal, open on that directory, with
./solydfixes command ... or from any other directory if you use the full pathname. If you create a symlink to the main script in /usr/local/bin or ~/bin, you can call it from anywhere with just
Alternatively, you can 'install' the script properly, i.e. put the main script in
/usr/local/bin and the rest in
/usr/local/lib/solydfixes (no package manager involved means using /usr/bin and /usr/lib/solydfixes is out...). You can do that by running
./install from the directory you just created.
The solydfixes tarball currently contains:
|lib/solydfixes/functions||miscellaneous support functions|
|lib/solydfixes/history||some notes about the development of the script (not as detailed as a change log)|
|lib/solydfixes/WARNING||some information about the changes from the previous versions|
|solydfixes||the main script|
|install||script that takes care of installing or upgrading the set to a new version|
|solydfixes.replace||symlink to 'install' - older versions of the script expect this to be the name of the installer|
No README or manpage, sorry. This webpage will have to do.
Some items the script will create and use are scratch space (/tmp/solydfixes.d) and a log file (/var/log/solydfixes.log). The latter can be opened in a graphical editor with the
solydfixes -l command (that's a lower case L, by the way).
lib/solydfixes subdirectory is the library directory. This is where the script expects to find its support files. Keeping this in the unpacked solydfixes directory is fine, but it is not where the script itself would put it.
The script uses a simple DNS call to check whether a new version is available. If there is one, it will tell you about it and you can download the new version from this site or use the command
solydfixes get to make the script download it itself. The get function will download the tarball and 'install' the script and support files in the default locations (see above). If the old version of the script is running from another directory called 'bin' (e.g. in your home directory), the new version will end up there. If necessary a 'lib/solydfixes' directory will be created on the same path.
Removing the script and associated files and directories can be done with the command
solydfixes --remove. If you want the log files gone as well, use
solydfixes --remove +log. This command will work on an installed set and also on a set which is not actually installed but stored in a directory with the name of the script.
Be aware this command executes immediately (after asking your sudo password) and bluntly removes the entire script set. If you used its directory to store anything you want to keep, move it out of the way first.
The available functions are:
The ones marked with *) were already present in (much) earlier versions of the script and are more or less outdated, but the first two might still come in handy (I found it really surprising that so many users managed to miss the July 2014 update's /tmp fix...).
If you run the script with the terminal command
solydfixes -y upgrade, it should upgrade your install to Debian Jessie. The procedure is based on what's mentioned in the forum threads here and here.
If you add the -S switch, the result should be essentially the same, but the sources list will contain stable instead of jessie. This will cause the system to upgrade automatically when the current Testing suite becomes the new Stable.
If you want to include the theme switch, simply add the qtev argument (i.e. use
solydfixes -y upgrade qetv). You can also include the dmo argument to remove the deb-multimedia.org packages (see below), if your system still has that repository in its sources.list and you want to get rid of it (it is not a good idea to remove the repository and keep the packages!).
To move to Debian Testing instead of Jessie, run
solydfixes -Ty upgrade (or e.q.
solydfixes -Ty upgrade dmo qtev if you want DMO removed and the new theme selected as well). You could also do this at a later date, after moving to Jessie first. It will switch your system's sources.list and go through the whole process again, probably skipping most of it, but that shouldn't be a problem.
The Business Editions can also be 'upgraded' to Wheezy instead of Jessie. Use
solydfixes -Wy upgrade for that.
The script does some pre and post processing before and after the actual dist-upgrade. This is controlled by two variables: PreDistUpgrade and PostDistUpgrade which are read by an internal function called Process. Currently they are set up like this:
PreDistUpgrade=' purge=^live-* remove=cups-pdf remove=softwaremanager :install=+[!OptToWheezy:lightdm-manager,libjpeg-turbo-progs,plymouth-themes],solyd[DE]-system-adjustments, k)purge=+[!OptToWheezy:kdm] k)install=+[!OptToWheezy:lightdm] k)purge=+[OptToWheezy:kcm-ufw] purge=+[!OptToWheezy:libhal1,hal-info] ' PostDistUpgrade=' install=updatemanager,cups-pdf,solyd[DE]-info,solydxk-softwaremanager purge=+[!OptToWheezy:systemd-shim] k)purge=userconfig k)install=+[OptToWheezy:gufw],kuser x)install=usermanager reconfigure=grub-pc reconfigure=grub-efi-amd64 reconfigure=grub-efi-ia32 k)reconfigure=+[!OptToWheezy:lightdm] k)reconfigure=+[!OptToWheezy:solydk-system-adjustments] reinstall=nvidia-kernel-dkms '
This does indeed cause packages to be installed, removed or reconfigured. Look here if you want to know more about the way these variables are processed.
In case you're wondering, I did have a good reason to add installing packages that should already be there and removing some that should be long gone...
If you want to change the default values of the variables mentioned above or add others, you can of course hack the script. An alternative is to create a textfile called solydfixes.conf (used to be solydfixes.ini). This file should be placed in the .config subdirectory of your home directory, but it will also be found in the library directory. It will be read ('sourced') as if it's part of the script, so assigning values to variables must be done in the same way as in a regular shell script.
Be aware that if you change the values of the 'Script...' variables set at the start of the script, you run the risk of seriously messing up the script's functionality.
This function uses the functionality suggested here to replace the packages from deb-multimedia.org (DMO) with the ones provided by the main Debian repositories. Unfortunately, this isn't a perfect switch as not all of the DMO packages are available there. The ones missing are listed at the end of the run and that listing is also stored in the log (/var/log/solydfixes.log).
Two shell variables are involved, PreDMORemoval and PostDMORemoval, which contain:
PreDMORemoval='libdvdcss2 w32codecs w64codecs' PostDMORemoval=':install=libavcodec-extra-56'
The first is simply a list of packages to ignore. They are provided by SolydXK's own repository as well, with the same name, so removing them is pointless.
After the main remove run, some additional packages can be installed. This is done using the main processing function mentioned above (and described here), so 'install' is required. Because it has been reported that installing these items can sometimes cause masses of other packages to be removed (possibly because a DMO package was somehow missed in the removal stage), the -y option is forcibly switched off at this point. Don't proceed if the list of packages apt-get wants to remove is huge!
The directory /etc/xdg/autostart contains a desktop file called xhost-plus.desktop which is used to set access to the user's X server. Around mid 2014 this was changed in such a way that gksu has effectively become useless (now executes xhost +localhost instead of xhost +). A relatively small change (xhost +localhost SI:localuser:root) will make gksu function again, without opening up the X server to everybody. Running
solydfixes gksu will implement that change.
solydfixes kdbbs if you don't want the Kickoff menu's search box to search your browser's bookmarks. Include the -p option and a copy of the .desktop file involved (/usr/share/kde4/services/plasma-runner-bookmarks.desktop) will be placed in ~/.kde/share/kde4/services/, which should make this change persist over KDE upgrades (just remove that copy if you don't want that anymore).
Based on a KDE forum posting - credits to just, whose forum posting made me investigate this...
Switching the theme can be done separately (
solydfixes qtev) or as part of the 'upgrade' (
solydfixes -y upgrade qtev). It needs packages provided by the upgrade, but these will be installed separately if they're not there yet (using the processing function with the shell variable
QtEvInstall='install=evolvere-icon-theme,solydxk-mozilla-evolvere-icon-theme'). However, this will not work if these packages cannot be found in any of the current repositories.
I haven't had time to check yet, but I seem to remember something about changes to the theming that will probably make this fail. Please do not use.
Some time ago, there was a mixup between the softwaremanager and solydxk-softwaremanager packages. In some cases, this left the Software Manager entry in the Kickoff/Whisker Favourites menu pointing at a non-existent package and/or caused the Software Manager to show up twice elsewhere in the menu. Running
solydfixes -y swmanager should fix this.
This makes the script remove the incorrect symlinking of
/var/tmp. It should be handled transparently, i.e. without disturbing any of the running processes, but I can't guarantee I haven't missed an application that uses /var/tmp instead of /tmp and will find its temporary files missing after the run.
Running the script with vbox makes it purge the VirtualBox Guest Addition Modules from your system, unless you're running it in a VirtualBox Virtual Machine. The modules are listed in the variable VBoxGuest, like this:
They are removed using the processing function mentioned above, so a 'purge' command must be included.
As far as I'm aware, the script does what it's supposed to do. Nevertheless, you use it entirely at your own risk. That said, if you find a bug, do get in touch with me and I'll see what I can do about it.