Although I've had problems with Mint from the get-go, two issues have been particularly annoying on my 32-bit laptop from the beginning. One, Caja's audio-preview has a bug where, while 'previewing' an audio file, the file-manager itself would freeze, requiring that it be forcibly closed. And two, already-generated thumbnails would be deleted each time you logged-out/rebooted, necessitating that Mate generate all of the thumbnails-cache over again - a time-consuming, CPU-intensive process.
With the latest major upgrade of Mint having been recently made available, now up to 17.3, it was with a heavy heart that I discovered that not only are these two bugs still alive & well, things have actually gotten worse. Now, thumbnails are deleted throughout the session, so there is no rest-bite at all! I actually contributed to a bug-report on these problems here about 6 months ago, although these problems have existed for much longer than this. Then, I also discovered a way of fixing the thumbnail-bug, which involved patching the source-code before recompiling. The Caja-freeze problem was fixed by 'merely' recompiling the Caja package. 'Merely' is emphasised for a reason - unfortunately, Mint doesn't make things easy for you, with its current Caja-build requiring many separate packages, whereas Git's Mate/Caja compiles everything into a single package. What all this means is that you can get conflicts between installed Mint-built packages, and those that you build locally from Git source when you try installing them.
Fixing it!
As stated in the long-winded version above, this only effects 32-bit Mint 17.x setups, in this particular case Mint 17.3 (Rosa). Three packages need to be rebuilt;
mate-settings-daemon (thumbnails bug)
caja (audio-preview bug)
caja-extensions (so we don't lose extensions, like 'caja-share')
Essentially, you should build these packages yourself from the Mate-Git repository, and in the case of 'mate-settings-daemon', first applying this patch, but in case this all seems a bit too much, I'll provide links to the packages that I built for my setup, but with the warning that it is always risky to install 'unknown-packages' on your computer! You of course need to first remove the affected packages, so as a first step, remove the following Mint-built packages;
mate-settings-daemon-common (which will also remove 'mate-settings-daemon')
caja-common (which will also remove 'caja', plus a few more)
gir1.2-caja (causes a dependency-issue otherwise)
Now things get a little tricky! Most people will want to hold onto the 'mate-control-center' application, which the Mint developers have seen fit to have made 'caja-common' one of its dependencies - a part of the main app we are replacing! Our new Caja-build, although functionally identical, is built differently, incorporating all of its required dependencies (like 'caja-common') in a single package. So in order to get things to play nicely together, a little subterfuge is called for. The easiest thing to do was when building the 'caja' application, to build it as 'caja-common' - that way, when re-installing 'mate-control-center', 'caja-common' is seen to be already installed, so the installation will proceed. Short version - only one Caja package is installed, the newly-built 'caja-common', which contains everything needed, extensions excepted, while also satisfying the 'mate-control-center' dependency issue. So, install the following new packages;
caja-common
caja-extensions
mate-settings-daemon
And then reinstall 'mate-control-center'. The final step is to add a new entry to Startup Applications (System->Preferences->Personal->Startup Applications) that will auto-start 'mate-settings-daemon' each time - name it 'mate-settings-daemon' and set its 'Command:' line to "/usr/libexec/mate-settings-daemon".
That's it! Logout/reboot and everything will hopefully be hunky-dory. The only casualty of doing all of this seems to be that you can no longer change Caja folder-colours, as there's no code for this function available in Mate's Git repository. On the upside, you do get up-to-date versions of these packages (1.13 versus 1.12), as well as no longer suffering the indignity of Caja continually locking up, or thumbnails being continually regenerated.
Edit1:
I didn't expect to be returning to this, but here I am! I suffered a mini-meltdown on the Linux front today, after a software lockup, followed by a somewhat impatient physical switch-off of the computer. Mistake. When my Linux installation would no longer boot, I went the suggested route of doing a manual 'fsck' - Mistake 2. I was greeted by (what turned out to be) 100's of 'inode' errors, to which I blithely Yes'd all of the prompts to repair. Mistake 3. Although it would now boot, it was obvious that the damage was extensive - Caja or Nemo for instance refused to run.
Though things looked bleak, I knew I still had the backup of Mint 17.3 that I had made before my aborted attempt at replacing it with Mint 18.1 - 7 months old, but good enough. The OS image rewrite got about half way through the process when the writing software complained that the saved OS image-file was corrupt - despite having been on a different partition! - and it needed to reboot. Now it appeared, not only had the crash completely fcuked up my 50GB OS partition, but my 200GB data storage partition as well - FUUUCCKKKKKK!!!
On recovering, one fresh installation of Mint 17.3 later, followed by an online software update, I discovered that ALL of the bugs that existed over 2 years ago in Mint 17.3 are still there - really disheartening. Compiz for instance, still does not work. Neither have any of the bugs mentioned in this post been fixed, nor has the ability to mount ISO's greater than 2GB - so much for 2 years worth of "Development".
But to the point of this edit. After the fresh install of Mint 17.3, I set about fixing the bugs noted here by downloading the files & following the instructions listed above. To my surprise, for the most part it worked! I had installed so many packages on the old setup over the years that I felt sure that some dependency issue with a fresh install would have arisen - but no! The only problem that I encountered concerned the Caja extensions. The Mint developers have a one-package-per-extension policy, whereas the single extensions package that I built contains all of the extensions. The only problem this caused me was that I first had to locate & remove 4 or so extension packages that had already been installed, before installing my 'all-in-one' "caja-extensions" package. No biggie, just irritating.
Other than that, I'm almost back with a working system. Compiz caused me the most problems. With all versions since 2014 unworkable on my now ancient hardware, and after a fruitless internet search for ppa's containing the sought-after versions, I eventually was forced to go trawling for the individual packages themselves - an onerous chore, or so I thought! Turned out that Canonical's site layout makes it really easy to locate all of the needed files - just do a search from this page (this for the 'Trusty' software-base), select the package, then your CPU architecture, then download the file, just a few clicks for each file, easy peasy! The only challenge is discovering the order that these (9) packages then need to be installed in, as many treat others as dependencies. I could list their install-order here, but where would be the fun in that!
Edit2:
I hate a mystery, so I decided to hunt down the reason for Mint 17.3's 'Disk Image Mounter' not working. It's not confined to Mint either - I know from experience that it doesn't work with the 32-bit version of Deepin Linux 15.4 as well, so basically the Debian package itself is broken.
The problem is that, compilers, on their own, for 32-bit builds, default to defining variables as 32-bit numbers, unless explicitly told otherwise. However, many programs need to work with numbers whose magnitudes can greatly exceed 32-bits - 'gnome-disk-utility' for example and the package of interest here, may encounter disks of many terrabytes in size. 'Little' 32-bit variables are no longer sufficient in situations like this, and require the use of 64-bit variables instead. In the past, 'gnome-disk-utility', properly programmed, had no problem doing this, and long before 64-bit CPU's were even widely sold - so it has nothing to do with "ancient hardware" as many suggest. So what has changed? It seems obvious, with fewer & fewer 32-bit computers being used, less and less testing is being done of 32-bit applications running on 32-bit hardware. Understandable in a way, but imo, unacceptable where obvious bugs are allowed to occur across multiple version releases, often spanning YEARS - 'gnome-disk-utility' being a prime example.
Technically, all that is required is the following one-liner at the start of the code;
#define _FILE_OFFSET_BITS=64
I tried to do this on my 'fresh-install' of Mint 17.3 but failed miserably as it resisted all of my attempts to install some of the needed development packages. This I think was down to my having added a ppa ('mc3man') to my setup in order to acquire 'ffmpeg', which 'Trusty' doesn't have in its repositories. As this version is 'current', I suspect that up-to-date dependencies were also installed which had the effect of breaking 17.3's old libraries setup. Whatever the reason, I instead opted to install a 'fresher-install' of Mint 17.3 on another drive and try to build it on that. It worked - another bug bites the dust! 'gnome-disk-utility' 3.12 is the result, downloadable below.
gnome-disk-utility_3.12.1-1_i386.deb
Incidently, while playing with the 'fresher-install', I also installed the working version of Compiz, realised that it was even more of a chore second time round, so made note of the packages installation-order, listed below.
libdecoration0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-core_0.9.11+14.04.20140409-0ubuntu1_i386.deb
libcompizconfig0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
python-compizconfig_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compizconfig-settings-manager_0.9.11+14.04.20140409-0ubuntu1_all.deb
compiz-plugins-default_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-plugins_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-gnome_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz_0.9.11+14.04.20140409-0ubuntu1_all.deb
Edit3:
Another 'tweak' to my setup before backing it up, in readiness for the next crash! This time it's the file-manager Thunar. Although Caja is obviously my file-manager of choice, Thunar has its uses, as it's much faster & efficient memory-wise at thumbnailing lots of pics, and also has a really nifty extension application called 'BulkRename'. As I had already read that the 'current' 1.6.10 version in the Trusty repositories was buggy as hell, I initially opted to install an earlier version that is still in the repositories - version 1.6.3 - couldn't get it to work properly, so decided to build from source, version 1.6.11 instead. This I did, but on running the following little test, discovered that it too had another (different) bug that also caused it to freeze. The test simply creates some files in the folder of your choice (first line) then continually renames them. Leaving said folder open in Thunar would normally result in it locking up within a few minutes.
for i in $(seq 1 10); do touch "$i.txt"; done
while true; do for i in $(seq 1 10); do mv "$i.txt" "$i.txt.txt"; done; sleep 1; for i in $(seq 1 10); do mv "$i.txt.txt" "$i.txt"; done; sleep 1; done
After some more reading, I found that the 'freezing' bug has (hopefully) been fixed as of version 1.6.12. Below is the package that I built, which has one dependency (exo-utils) that will be downloaded & installed automatically. Even so, one thing that caused me a major headache was that although all of Thunar's dependencies are accounted for, on my 'build-machine', Thunar would run, whereas on my 'work-machine' it wouldn't, complaining that a certain shared library was not found. Yet there it was, plain as day, for all to see! After searching aimlessly for inspiration for what seemed like an age, I eventually came across this post on a French forum that provided the solution. Merci!!! Run as root;
ldconfig
That's it! Not sure exactly what it does but after running it, the shared library was found and Thunar now works. The above test has been running on it for over an hour with no lock-up - so fingers crossed! One other thing, I've had to "--exclude" one item from the package when building it with 'checkinstall' - /usr/local/share/icons/hicolor/icon-theme.cache. This as it happens is also part of my 'gnome-disk-utility' build, and while I'm not entirely sure as to its purpose, I do know that Thunar appears to function perfectly well without it - even with 'gnome-disk-utility' not installed.
thunar_1.6.12-1_i386.deb
Note: While adding this 'fixed' Thunar to my Deepin Linux installation, an issue arose. Without having first installed Thunar from the repositories, BulkRename refuses to run, even after issuing the 'sudo ldconfig'. Investigating, apparently the 'repository-install' creates a symbolic link (named "Thunar") to "thunar", which is in the same directory. This requirement is part of a "dirty hack" - Thunar-source comment - to get it to run on the Xfce desktop. My build on the other hand, does not create this symbolic link to "thunar" that BulkRename needs, so it doesn't work, pure & simple! If this occurs, first create the symbolic link manually - ie. do a;
sudo ln -s /usr/local/bin/thunar /usr/local/bin/Thunar
Then do a sudo ldconfig to include this link in the rebuild of the 'symbolic links to shared libraries cache'. From reading, 'ldconfig' is normally done automatically whenever an application is installed via 'makeinstall', but since I'm building a discrete package with 'checkinstall', this does not occur.
Edit4:
Never figured on an Edit4 for this old post! I recently became fixated on getting the appImage of 'Avidemux' running on Mint 17.3. After discovering that Avidemux 32-bit versions were no longer a thing, I had the cunning plan of installing Mint 17.3_64-bit alongside my everyday OS, so side-stepping the issue. This ultimately proved futile, because as others had discovered before me, recent (yet, going way back) appimage builds use updated libraries that never made it to the Mint 17.3 repositories.
Nevertheless, with the 64-bit version installed, I decided to enable Ubuntu's 'esm' critical updates service, particularly when I (re)learnt that it would extend the life of this old girl, all the way to April 2024 - cool! I then resolved to fix the 'audio-preview freezing bug' as I did here for Mint 17.3 32-bit. Below are the new Caja builds, which also feature a version-upgrade bump to 1.14.2. There's no messing about this time with caja-common as described above - just install the new Caja & caja-extensions, leaving the old caja-common in-situ.
No comments:
Post a Comment