Disable Thunar's unusable "Set as wallpaper" context menu item.

johnraff · 2016-03-12 01:43:17

I think this was one of the things that corenominal compiled out of the custom Thunar build for CrunchBang, but in BunsenLabs if you right-click an image file there is a menu item that says "Set as wallpaper". It does nothing, because the Thunar wallpaper plugin needs xfdesktop4, which draws a desktop, but isn't used in BL.

The Thunar wallpaper plugin is compiled into the Debian standard Thunar (EDIT: libthunarx-2-0 in fact), and we don't want to have to compile our own version, just for a little thing like this. There is a fix though. Rename /usr/lib/{i386-linux-gnu,x86_64-linux-gnu}/thunarx-2/thunar-wallpaper-plugin.so and restart Thunar.

TL:DR
Try installing this proof-of-concept package of bunsen-thunar, then 'killall thunar' (to stop the daemon) and check that useless item is gone. Uninstall bunsen-thunar to get it back.

------
This is the Development zone so the techy details:
*) Just renaming the file isn't enough because it will be replaced if Thunar is upgraded or reinstalled, so bunsen-thunar adds a dpkg-divert.

*) The file path depends on the system architecture. It's /usr/lib/<multiarch_tuple>/thunarx-2/thunar-wallpaper-plugin.so, where eg for i386 <multiarch_tuple> is i386-linux-gnu or for amd64 it's x86_64-linux-gnu. So for a package that can install on any architecture we need a way of dynamically choosing the right string to use in the filepath. (Otherwise the package would have to be compiled separately for each architecture.) Though it's not too hard to get the system architecture there doesn't seem to be any utility in the basic BL system that will give us the multiarch tuple, and getting it from the architecture isn't a simple string substitution - we'd need to have a list of all the equivalents and go do down it. There are 'gcc -print-multiarch' and 'dpkg-architecture -qDEB_HOST_MULTIARCH' but these are dev packages ordinary users probably won't have (though gcc is needed by dkms, which virtualbox users might install to get Guest Additions).

So what I did isn't very elegant: try gcc, then dpkg-architecture, and if neither works get the system architecture and do a 1-1 conversion just for i386, amd64 or anmhf. Those are the only three architectures BL is currently compiled for so in practice it should work:

multiarch_name=$(gcc -print-multiarch 2>/dev/null) ||\
multiarch_name=$(dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null) || {
    arch=$(dpkg-query -W -f='${Architecture}' dpkg)
    case $arch in
    i386)
        multiarch_name='i386-linux-gnu'
        ;;
    amd64)
        multiarch_name='x86_64-linux-gnu'
        ;;
    armhf)
        multiarch_name='arm-linux-gnueabihf'
        ;;
    *)
        echo "$0: architecture $arch not supported at this time" >&2
        exit 1
        ;;
    esac
}

file="/usr/lib/$multiarch_name/thunarx-2/thunar-wallpaper-plugin.so"

Another way of doing this would be to look at the package installing that plugin and see where it put it. It's not thunar, in fact, but libthunarx-2-0, so:

dpkg -L libthunarx-2-0 | grep 'thunar-wallpaper-plugin.so'
/usr/lib/i386-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so
diverted by bunsen-thunar to: /usr/lib/i386-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so.bunsen-disabled

is possible, but messy if bunsen-thunar has already been installed, and won't work if libthunarx-2-0 isn't on the system. The present way will put in the divert even if Thunar isn't around, just in case it's added in the future.

This might all seem like a lot of work for a tiny tweak to the GUI, but the work's already been done now so, if it looks like a good idea, I can put a BunsenLabs version of the source on GitHub and maybe @hhh could add it to the package list for the next iso (it's 2.7KB)?

Last edited by johnraff (2016-03-20 03:13:36)

hhh · 2016-03-12 02:07:34

^Awesome detail catching, thank you!

damo · 2016-03-12 11:07:04

@johnraff - impressive work you are doing. That context menu item has always bugged me, and a workaround will stop a few help requests.

nobody · 2016-03-12 12:06:31

I think there's a cleaner & simpler way to achieve this.

Create a file

/etc/apt/apt.conf.d/99NoThunarWallpapers

with the contents (notice the glob):

DPkg::options {
  "--path-exclude=/usr/lib/*/thunarx-2/thunar-wallpaper-plugin.so";
}

Reinstall libthunarx-2 which owns the file:

sudo apt-get --reinstall install libthunarx-2-0

The plugin is now gone by way of preventing its extraction from the package in the first place.

I already mentioned the technique here.

hhh · 2016-03-13 01:30:58

^+1

johnraff · 2016-03-13 03:12:16

@nobody that's the kind of simple solution I was hoping might exist. Thank you.

I'll put together a test .deb that installs that apt/conf.d file, and reinstalls libthunarx-2-0 in its postinst and postrm scripts, so we can try it out.

The same config could also go in bunsen-configs but having a separate package will let users get the menu item back without having to remove all the other bunsen configs.

nobody · 2016-03-13 04:37:40

johnraff wrote:

@nobody that's the kind of simple solution I was hoping might exist. Thank you.
I'll put together a test .deb that installs that apt/conf.d file, and reinstalls libthunarx-2-0 in its postinst and postrm scripts, so we can try it out.
The same config could also go in bunsen-configs but having a separate package will let users get the menu item back without having to remove all the other bunsen configs.

That's the one thing I'm unsure about; I don't know if it's possible to reinstall a package from another package's postinst script – after all, apt would still be running and have a lock, preventing another apt instance to run. Maybe there's a way to trigger a reinstallation in apt without invoking another instance?

johnraff · 2016-03-13 07:31:11

OK so far confirmed that the deb installs the apt config file OK and that a reinstall of libthunarx-2-0 then results in the unwanted library being removed.

Also confirmed that a call in postinst or postrm to 'apt-get --reinstall' is indeed locked out (I made it '...|| true' so the deb installation would go anyway).

Going to read up on Dpkg triggers.

johnraff · 2016-03-14 06:07:39

Well, I've learned how to make dpkg triggers so it wasn't time completely wasted, but even running a delayed trigger of a call to apt-get is blocked, I guess because even at the end of the installation process dpkg is still in charge, and the lock file hasn't yet been removed.

Selecting previously unselected package bunsen-thunar.
(Reading database ... 112894 files and directories currently installed.)
Preparing to unpack .../bunsen-thunar_0.9.2-1_all.deb ...
Unpacking bunsen-thunar (0.9.2-1) ...
Setting up bunsen-thunar (0.9.2-1) ...
Processing triggers for bunsen-thunar (0.9.2-1) ...
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
dpkg: error processing package bunsen-thunar (--install):
subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
bunsen-thunar

It appears to be impossible to invoke apt from a maintainer script: http://stackoverflow.com/questions/1859 … b-postinst

So, options:
1) Get the installation script to prompt the user to reinstall libthunarx-2-0 him/herself.
2) Go back to the dpkg-divert method.
EDIT
or...
3) Together with installing the 99NoThunarWallpapers file, directly rename thunar-wallpaper-plugin.so if it exists, and rename it back if bunsen-thunar is removed.

Last edited by johnraff (2016-03-14 07:57:42)

xaos52 · 2016-03-14 08:39:18

or
4) Launch a script in the background that 'watches' the dpkg process (or the existence of the lock file) and starts the apt-get install when the process has exited (or the lock file has been removed)

nobody · 2016-03-14 12:39:24

Let's divert instead. It's simpler, and uses a function native to the package management system.

johnraff · 2016-03-15 03:21:55

Both dpkg-divert and dpkg --path-exclude are nice and simple in themselves; the complications come in the implementation.

OK let's go back to dpkg-divert. The tricky part here is getting the correct library path for the system architecture. An 'Architecture: any' package means only one compilation is needed instead of one per architecture, but requires that the installed postinst script can figure out the i386-linux-gnu|x86_64-linux-gnu|arm-linux-gnueabihf choice. (See the OP)

My initial choice of using gcc || dpkg-architecture || dpkg-query ${Architecture} -> lookup is a bit clunky at best. I'm now wondering about looking up the path of some file that must exist on the system and extracting the lib path from that. For example apt installs libapt-private.so.0.0.0 on all architectures, so this will get the path:

find /usr/lib -name 'libapt-private.so.0.0.0' | sed -nr 's|^(/usr/lib/[^/]+).*$|\1|p'

But it needs findutils to be installed.

EDIT
This works too and doesn't need find, just sed which is pretty much guaranteed to be available:

dpkg -L apt | sed -nr '/libapt-private.so/ {s|^(/usr/lib/[^/]+).*$|\1|p;q0};${q1}'

It returns 1 if no filepath contains libapt-private.so

Both methods take about the same time to run (~45ms on my VM).

Last edited by johnraff (2016-03-15 08:08:06)

xaos52 · 2016-03-15 13:06:07

or

shopt -s extglob; triplet=$(basename $(ls -d /usr/lib/@(x86_64|arm|x86)-linux-gnu*)); shopt -u extglob;

timed 9 ms on my bare metal system.

The extended glob can perhaps be refined for arm architectures, which I am not familiar with.

johnraff · 2016-03-15 23:38:00

^that's very impressive, though it does make assumptions about the form the path will take, which is perhaps fair enough though.

It seems ridiculous to me that we have to jump through these hoops just to get a bit of basic system information. I suppose some day dpkg (not dpkg-dev) will have an option...

nobody · 2016-03-16 14:03:56

johnraff wrote:

^that's very impressive, though it does make assumptions about the form the path will take, which is perhaps fair enough though.
It seems ridiculous to me that we have to jump through these hoops just to get a bit of basic system information. I suppose some day dpkg (not dpkg-dev) will have an option...

The architecture path infix you are looking for is the compiler target for the system's architecture. You obtain it as follows:

eval $(dpkg-architecture -s)
echo $DEB_HOST_GNU_TYPE
eval $(dpkg-architecture -u)

People who use real programming languages like C will also know this:

gcc -dumpmachine

…though the dpkg-architecture command practically is giving itself up for answering that kind of question

xaos52 · 2016-03-16 15:12:05

Problem is that dpkg-architecture comes with the dpkg-dev package, which is not installed by default.
Nor is gcc installed by default.
We are looking for solutions that work on systems where none of the mentioned packages are installed.

IIRC, I read somewhere - but don't remember where - that Debian wants to keep the details for those triplets internal, so that they can change them as they please.

nobody · 2016-03-16 17:01:40

xaos52 wrote:

Problem is that dpkg-architecture comes with the dpkg-dev package, which is not installed by default.
Nor is gcc installed by default.
We are looking for solutions that work on systems where none of the mentioned packages are installed.
IIRC, I read somewhere - but don't remember where - that Debian wants to keep the details for those triplets internal, so that they can change them as they please.

No, these are GNU platform names, they are used all over the place.

You need to reimplement the guessing logic in /usr/share/perl5/Dpkg/Arch.pm which uses /usr/share/dpkg/ostable which is annoying, because there's already a tool.

Quick and dirty attempt.

awk -vDPKGARCH=$(dpkg --print-architecture) '{if($1==DPKGARCH)print $2"-linux-gnu"}' /usr/share/dpkg/cputable

OR just get the library path from the package itself, which has to be installed anyway before the diversion if it's declared as a dependency. From a maintainer script:

dpkg -L $thatpackage | grep '/$soname.so$'

That operation doesn't require a lock.

xaos52 · 2016-03-16 19:34:53

OK.
I would go for

awk -vDPKGARCH=$(dpkg --print-architecture) '{if($1==DPKGARCH){print $2"-linux-gnu";exit 0}}' /usr/share/dpkg/cputable

nobody · 2016-03-17 01:37:26

xaos52 wrote:

OK.
I would go for

awk -vDPKGARCH=$(dpkg --print-architecture) '{if($1==DPKGARCH){print $2"-linux-gnu";exit 0}}' /usr/share/dpkg/cputable

The exit code would still always be 0 (unless the input file is inavailable).

awk -vDPKGARCH=$(dpkg --print-architecture) -vRET=1 '{if($1==DPKGARCH){print $2"-linux-gnu";RET=0;exit;}} END {exit RET};' /usr/share/dpkg/cputable

END always wins.

xaos52 · 2016-03-17 09:21:26

^ Thanks,
The exit code wasn't my first concern. Exiting immediately after having found the correct architecture was.

#1 2016-03-12 01:43:17

Disable Thunar's unusable "Set as wallpaper" context menu item.

#2 2016-03-12 02:07:34

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#3 2016-03-12 11:07:04

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#4 2016-03-12 12:06:31

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#5 2016-03-13 01:30:58

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#6 2016-03-13 03:12:16

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#7 2016-03-13 04:37:40

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#8 2016-03-13 07:31:11

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#9 2016-03-14 06:07:39

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#10 2016-03-14 08:39:18

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#11 2016-03-14 12:39:24

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#12 2016-03-15 03:21:55

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#13 2016-03-15 13:06:07

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#14 2016-03-15 23:38:00

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#15 2016-03-16 14:03:56

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#16 2016-03-16 15:12:05

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#17 2016-03-16 17:01:40

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#18 2016-03-16 19:34:53

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#19 2016-03-17 01:37:26

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#20 2016-03-17 09:21:26

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

Board footer