Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
On Sun, 09 Jun 2019 at 18:21:10 +0200, Adam Borowski wrote: > my personal reason to uninstall gvfs was that automounting USB sticks and SD > cards is harmful for me gvfs doesn't do this, so preventing automounting by removing gvfs is not reliable (at best, you're only preventing automounting accidentally, by the fallback GUnixMountMonitor not being sufficiently complete to signal new devices appearing). Whatever higher-level component responds to new drives/volumes appearing by mounting them should have a way to disable that behaviour. For example, in current GNOME automount is done by gnome-shell, in GNOME Flashback it's done by the gnome-flashback service, and in older versions of both it was part of gnome-settings-daemon, all of which share a dconf setting "/org/gnome/desktop/media-handling/automount" which can turn it off. In XFCE's thunar, as far as I can tell, the thunar-volman package is responsible for this and has two settings "/automount-drives/enabled" and "/automount-drives/enabled" in the xfconf framework (or removing thunar-volman would probably also work). There are also UDISKS_AUTO and UDISKS_IGNORE udev properties that you can set on devices via udev rules, which higher-level components are meant to use as a hint that this particular device is not to be mounted automatically, or should not appear at all, respectively. In GLib with gvfs, UDISKS_AUTO gets propagated up through the g_volume_should_automount() method. > So you actually care about Recommends being too strong? Of course. Recommends and Suggests are a trade-off between a hard dependency and no relationship, and maintainers should choose carefully case-by-case whether a related package that is not strictly essential should be a Depends, Recommends, Suggests, or not represented in dpkg metadata. Whatever we choose, not everyone is going to like the decision, but a decision needs to be made anyway - preferably one that balances the partially-conflicting goals of making default installations as good as possible for as many people as possible, having enough flexibility to allow for unusual installations, and preventing broken situations from being installable. I can understand the appeal of a more minimal system, and I turn off some selected Recommends myself, but I don't think globally disabling installation of Recommends and expecting a system as complex as a full desktop environment to have all of its intended behaviours is sustainable. If users demand full functionality with Recommends disabled, one logical but ironic course of action available to maintainers is to use fewer Recommends and more Depends, which of course leads to the exact opposite of what users who turn off Recommends were presumably aiming for. > On the other hand, I have serious doubts if fixing the fallback mechanism is > a good use for your time. Perhaps it'd be better for it to return "nothing > removable" if gvfs is not installed? I don't think falling back to "there are no devices, no volumes and no mounts" is really the intent of the API, but if you want to propose this upstream as the fallback behaviour, go ahead. I am not going to forward that request upstream myself, because proposing changes that I don't personally want and can't justify well will tend to get them rejected, and I don't want to sabotage the opportunity for someone who wants this more than I do to justify it better than I could. smcv
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
On Sun, 21 May 2017 at 13:06:52 +, bakhe...@gmail.com wrote: > I can confirm similar behavior of Thunar on my test system. The system has > encrypted disk using dm-crypt and LVM (3 LVM volumes in 1 volume group on > the encrypted disk and an unencrypted boot partition). > > When I use Thunar as root it now shows the boot partition and LVM volumes in > devices (in the Shortcuts Side Pane - on my system showing removable devices > on desktop is disabled). These are all the entries from /etc/fstab on that > system (with the exception of the swap entry). On Mon, 05 Jun 2017 at 15:46:39 +0200, Thomas Klose wrote: > I can confirm this bug on a current Debian/Stretch system: The file > manager "Nautilus" shows all bind mounts under the user's home > directory as rejectable devices. The option "x-gvfs-hide" in fstab > seems to be ignored. Are you still seeing this bug? If you are: do you have gvfs installed? If not, does installing gvfs and its hard dependencies resolve it? (Installing gvfs-backends, which is considerably larger, shouldn't be necessary.) Following up on Adam's original bug report, I found that XFCE in the current development version of Debian (buster) displays extra devices on the desktop whenever gvfs is *not* installed. If you still see this bug, please use the command "reportbug --template thunar" to collect information about the system and send it to the bug address. It would also be helpful if you could send the result of running this script on the affected system: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=836355;filename=list-mounts.py;msg=73 You will need to install python3-gi if you don't already have it, and on Debian stretch or jessie you might need to comment out some calls to functions that don't exist in older GLib versions. If the output contains things that you consider to be sensitive information, such as disk serial numbers, you can edit the output to censor them, as long as it's obvious where you have done so. Thanks, Simon
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
On Fri, Jun 07, 2019 at 05:49:46PM +0100, Simon McVittie wrote: > On Fri, 07 Jun 2019 at 15:56:34 +0200, Adam Borowski wrote: > > Besides the expected "Home" and "File System" I get two extra entries: > > * "Filesystem root" (/, redundant with "File System") > > * "boot" (/boot) > > both of which are on a non-removable disk. > > > > New installs don't have /proc in their fstabs, but old do -- and I just > > added such an entry to mine, and indeed it did show up. > > What environment are you reproducing this on? Is it still whatever part > of XFCE is responsible for icons on the desktop, as in the original bug > report? XFCE again, right. > Your image attachment doesn't seem to have made it to the bug, Oif! > Also, are you logged in to the GUI as root? Obviously, no -- other than lightdm and X running as root, as usual. > I'll try to put together a script to dump the information available from > GIO, so that we can see where the information is getting lost - between > the OS and GIO, or between GIO and whichever GUI is the relevant one. I haven't looked at other DEs; a bit uncomfortable to do so at the miniDebconf on a Pinebook. But indeed from your words it sounds like something better handled in a higher layer. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff. For example, ⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian. ⠈⠳⣄
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
On Fri, 07 Jun 2019 at 15:56:34 +0200, Adam Borowski wrote: > Control: found -1 2.58.3-2 Sorry, I hadn't seen the context of Scott's mail being a reply to a pre-existing bug, and his mails sounded as though he was opening a new bug discussing an issue that he had encountered elsewhere but could not reproduce in Debian. > Besides the expected "Home" and "File System" I get two extra entries: > * "Filesystem root" (/, redundant with "File System") > * "boot" (/boot) > both of which are on a non-removable disk. > > New installs don't have /proc in their fstabs, but old do -- and I just > added such an entry to mine, and indeed it did show up. The interaction between the GIO mounts/volumes API and GUIs is not entirely straightforward, but I believe the way these are meant to get excluded is by being flagged as "system-internal" (g_unix_is_mount_path_system_internal(), g_unix_mount_is_system_internal()). Whether to display or otherwise do something with system-internal mounts is a UI decision - I would expect that most UI designers would want to hide system-internal mounts, but components that are listing mounts for some other reason (like displaying used/free space or implementing the freedesktop.org Trash spec) will want to consider all of them. What environment are you reproducing this on? Is it still whatever part of XFCE is responsible for icons on the desktop, as in the original bug report? Your image attachment doesn't seem to have made it to the bug, so I can't tell from that. Also, are you logged in to the GUI as root? (I ask because I think there's some logic to ignore or not ignore volumes based on uid and home directory, so it matters - bakhelit mentioned running thunar as root.) I'll try to put together a script to dump the information available from GIO, so that we can see where the information is getting lost - between the OS and GIO, or between GIO and whichever GUI is the relevant one. smcv
Bug#836355: closed by Simon McVittie (Re: Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items)
Control: reopen -1 Control: found -1 2.58.3-2 On Fri, Jun 07, 2019 at 07:21:03AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the libglib2.0-0 package: > > #836355: libglib2.0-0: makes all entries of fstab show up as desktop items > > It has been closed by Simon McVittie . [>>>] > On Fri, 07 Jun 2019 at 02:04:48 +, scott092...@aol.com wrote: > > Well, I changed my user-dirs.dirs back to the original state, and did the > > bind mount > > from my data partition to my /home/scott/... user directories. All works > > fine. > > It sounds like there is no observable bug in Debian, then; marking this > as closed. > > If you find a related bug on a Debian system, please report it as a > separate bug number with details of how to reproduce the bug, using > the reportbug(1) tool on the Debian system to gather the necessary > information about version numbers etc. > > If you find a related bug on a Peppermint system that you cannot reproduce > on Debian, please contact Peppermint's support channels instead. While Scott is on Peppermint, the original submitter (me) and probably others who chimed in are on real vanilla Debian. The bug reproduces (as on attached screenshot) on fully up-to-date unstable, on a box installed just yesterday from d-i daily image, on a Debian conference, by a DD, with two other DDs debugging bootloader problems, with not a single package not in our archive. Besides the expected "Home" and "File System" I get two extra entries: * "Filesystem root" (/, redundant with "File System") * "boot" (/boot) both of which are on a non-removable disk. New installs don't have /proc in their fstabs, but old do -- and I just added such an entry to mine, and indeed it did show up. This box's fstab at the time of screenshot is: == # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/mmcblk2p2 during installation UUID=a7cd0bc6-7f6f-44bb-9379-21e561e5afaa / btrfs noatime 0 0 # /boot was on /dev/mmcblk2p1 during installation UUID=c523e382-26a4-4ab9-8efe-a65e4eef6918 /boot ext4noatime 0 2 # swap was on /dev/mmcblk2p5 during installation UUID=1d9d31be-dc9a-47ae-a9a1-ec3f99bff94d noneswapsw 0 0 proc/proc procdefaults == (all lines but the last were generated by d-i) This box's internal disk is eMMC, the one in original report had regular SATA. > > I tried GDebi-ing my current debian GLib2 libraries into Peppermint 10 > > system, > > to test this theory, but each one of the three packages pointed to one of > > the > > others and cited incompatibilities. > > Note that Debian does not support packages installed from other > Debian-based distributions (if you do this, it is at your own risk, You just closed a bug as "not for Debian" for a single commenter using a derivative -- most of which don't even modify core packages such as glib -- without even asking the original reporter nor two other folks who also confirmed. Alas, the BTS still has the unfortunate flaw of not sending new mails to the submitter unless explicitly subscribed, thus you'd need CCs when asking if the bug still reproduces. Unless the reporter subscribed (like I just did), then they'll get two or more copies... Hack on! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff. For example, ⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian. ⠈⠳⣄
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Well, I changed my user-dirs.dirs back to the original state, and did the bind mount from my data partition to my /home/scott/... user directories. All works fine. Despite the fact that my GLib2 version is before the version that fixed the "fstab binds appear as mounts (x-gvfs-hide is being ignored) (#1271)" bug, I don't have the bind mounts showing up in any of the file managers I have available, EVEN IF the x-gvfs-hide option is NOT listed in each fstab bind mount line (I tried it both WITH and WITHOUT the option). I suppose I should assume that the bug fix (since bug #1271's fixes were done seven months ago) was back-ported to the version on testing/sid. I tried GDebi-ing my current debian GLib2 libraries into Peppermint 10 system, to test this theory, but each one of the three packages pointed to one of the others and cited incompatibilities. Possibly I should un-install ALL THREE of the default ones first. instead of having GDebi replace each with the newer. No time now...
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
@smcv As it happens, I was researching the bug, the various sites I visited seemed to point to glib2 as being the source, and as I have debian testing/sid, I naturally looked up glib bugs in debian, and found this bug report. Since I had found more about the resolution of the bug from the pkg source in GitLab than was reported here, I thought I'd report what I'd found, so people would know about it. I personally use debian LXQt , but up until now had (as I had with Lubuntu LXDE/LXQt before) had attempted to use the standard user-dirs.dirs to try to redirect programs' attempts to use the /home//Documents (etc.) directories to my separate /data partition. Experience has shown that, except for my Desktop directory (by file managers), all other re-directed directories are totally ignored. In a bug-report discussion with Alf Gaida, he suggested I bind-mount my /data user directories to my /home// directories, as being better than symlinking them (or using the user-dirs.dirs file). [He also said something called "User Mounts" would be even better, but I have yet to find out what he meant...] Since I had an old computer that I was setting up for use, in order to give it away, I decided to test bind mounts on it, before doing it for my debian install. I had just installed Peppermint 10, and tweaked it a bit, and then added the bind mount lines to /etc/fstab. It works, but adds all 8 mounts to the file manager as removable drives (and may also add to the desktop - not sure). Subsequent research suggested I could solve that by adding x-gvfs-hide to the fstab line, but this proved wrong. (See: https://bugs.launchpad.net/peppermint/+bug/1831302) Checking the GLib2 version in Peppermint 10, with the version on my debian testing/sid, and the one listed in GitLab as having fixed the problem, it seemed clear that if I did modify my debian's fstab in like manner, I would likely have the same problem as in Peppermint. I will probably try the bind mounts here on debian, and then also try the "fixed" version in experimental. I will report back what I find.
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Control: found -1 2.58.3-1 On Wed, 05 Jun 2019 at 02:49:28 +, scott092...@aol.com wrote: > GLib bug on GitLab (https://gitlab.gnome.org/GNOME/glib/issues/1271 > "fstab binds appear as mounts (x-gvfs-hide is being ignored)") Am I right in saying that the bug is this? - Steps to reproduce: - Have bind mounts in /etc/fstab, e.g. /usr/share/doc /docs none bind 0 0 (Please quote a precise example of a bind mount that causes this for you) - Somehow enable icons that appear on the desktop (Please describe which desktop environment or file manager you are using for those icons and how it is configured - the upstream bug #1271 involved Deepin File Manager) - Expected result: - Disks appear as icons on the desktop - Bind mounts (such as /docs in my example above) do not appear - Actual result: - Disks and bind mounts both appear as icons on the desktop (Or if you can reproduce this bug some other way, for instance by too many icons appearing in the sidebar of the GNOME file manager Nautilus, that would also be useful information.) It's useful if you can report bugs using the reportbug(1) tool, which gathers information about your system that is often necessary to diagnose what is causing the bug. I have bind mounts in /etc/fstab and I don't see them in the sidebar of the GNOME file manager Nautilus, so presumably there is some relevant difference between my system and yours. > shows two commits, the second of which > https://gitlab.gnome.org/GNOME/glib/merge_requests/366 > (and the bug itself) appear to have been fixed in GLib version 2.59.0 > (only debian Experimental has a version that meets/exceeds this version) It looks as though the intention was that this bug was fixed *differently* for the 2.58.x and 2.59+ branches. For 2.59+, this is (meant to be) fixed by merge request 366. For 2.58.x, the solution in merge request 366 was not considered to be suitable (it adds new API, which is not a valid thing to do on a stable branch) so merge request 365 was merged *instead*. If one of these is not behaving as intended on your system, it will not be solvable without more specific information. Debian is in hard freeze for the Debian 10 release, so we might not be able to fix bugs that are not release-critical at this point, but the first step is to pin down exactly what the bug is. > I assume that if one wanted to try out the version in Experimental (2.60.3-1), > that one would have to grab all GLib packages that in testing/sid are at > version > 2.58.3-1 (three on my system - libglib2.0-0, -bin, -data) > (and hope that none of the higher versions conflicts with anything...) I uploaded 2.60.3-2 to experimental yesterday to fix a security vulnerability, so you should use that instead of 2.60.3-1, but other than that you are correct. smcv
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
GLib bug on GitLab (https://gitlab.gnome.org/GNOME/glib/issues/1271 "fstab binds appear as mounts (x-gvfs-hide is being ignored)") shows two commits, the second of which https://gitlab.gnome.org/GNOME/glib/merge_requests/366 (and the bug itself) appear to have been fixed in GLib version 2.59.0 (only debian Experimental has a version that meets/exceeds this version) https://gitlab.gnome.org/GNOME/glib/blob/master/NEWS : Line# / Line --- 416 Overview of changes in GLib 2.59.0 ... 431 * Hide bind mounts from GIO mount listings. (#1271) ... 490 * Bugs fixed: ... 503 - #1271 fstab binds appear as mounts (x-gvfs-hide is being ignored) ... 594 - !366 gunixmounts: Mark mounts as system internal instead of filtering out (!365 gunixmounts: Filter out mounts with device path that was repeated was also listed as a commit for #1271, and as merged, but I don't see it listed anywhere - don't know if that was an oversight and it was fixed, or got un-merged. https://gitlab.gnome.org/GNOME/glib/merge_requests/365) --- I assume that if one wanted to try out the version in Experimental (2.60.3-1), that one would have to grab all GLib packages that in testing/sid are at version 2.58.3-1 (three on my system - libglib2.0-0, -bin, -data) (and hope that none of the higher versions conflicts with anything...)
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Package: thunar Version: 1.6.3-2 or 1.6.11-1 Package: libglib2.0-0 Version: 2.50.3-2 I can confirm similar behavior of Thunar on my test system. The system has encrypted disk using dm-crypt and LVM (3 LVM volumes in 1 volume group on the encrypted disk and an unencrypted boot partition). When I use Thunar as root it now shows the boot partition and LVM volumes in devices (in the Shortcuts Side Pane - on my system showing removable devices on desktop is disabled). These are all the entries from /etc/fstab on that system (with the exception of the swap entry). This started after I recently upgraded some packages to testing/unstable versions. By downgrading packages back to stable (Jessie) versions I found that the problem is caused by upgrading the libglib2.0-0 from version 2.42.1-1 in stable to version 2.50.3-2 in testing/unstable. I also tested it with different versions of thunar (stable 1.6.3-2 and testing/unstable 1.6.11-1) and the behavior was always the same as described above (complete upgrade of the test system from stable to testing also did not change the described behavior). I suggest that showing all the entries from /etc/fstab (LVM volumes, etc.) is disabled as with the stable version, because it just adds clutter in file manager's GUI and could confuse the user to even accidentally unmount the volume. I was able to unmount the boot volume while the attempt to unmount the home and root volumes failed with error describing that the volume is in use. By the way adding "comment=x-gvfs-hide" or "x-gvfs-hide" options to fstab entries is not working for me. The only way I found for hiding these devices is to hide them using the right click context menu in the Thunar Shortcuts Side Pane. This adds type="array">... to "~/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml". But since sometimes UUIDs are used, it is very difficult to create a general config for multiple systems. Can any one explain what device ID types can be used in the "hidden-devices" property in "thunar.xml" or what options to add to fstab entries to hide them from devices in Thunar? Best regards, A Happy Debian User
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Hello Adam Borowski.
Thanks for your bug report.
On Fri, Sep 02, 2016 at 06:42:19AM +0200, Adam Borowski wrote:
> Package: libglib2.0-0
> Version: 2.49.6-1
> Severity: normal
>
> Hi!
> After today's upgrade of libglib2.0-0, I get every single entry of fstab,
> even /proc, show up as a desktop item. This is with xfce.
>
> Reproducible on a freshly installed system; you just get 2 entries
> ("Filesystem root" and "cdrom0") as fresh fstab is rather empty.
>
> No gvfs installed, so none of those should show up.
>
> I've eliminated every possible culprit other than libglib2.0-bin, at my
> system's current state downgrading these two makes the ~20 desktop items go
> away, upgrading these two makes them reappear.
Your description is making me a bit confused, but I hope I can give
you some useful hints for investigating this anyway.
Recently glib gained a new (and preferred) backend based on libmount
which might be related to the issue you're reporting.
You could try rebuilding the glib2.0 package with the
--enable-libmount flipped to --disable-libmount and see if that
affects your problem.
Either way, I'm not sure how XFCE decides what to list on the desktop
so would appreciate if you pointed me to where in the code it's
interacting with glib for getting the information. Also, I think
this bug should probably be reassigned to the relevant XFCE component
for investigation there as glib is a low-level interface which knows
nothing about graphical interfaces and should not be filtering out
any mountpoints for your gui.
Fwiw, GNOME is not affected by any change because of the glib update so
likely XFCE and GNOME just interacts differently with glib.
Regards,
Andreas Henriksson
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Package: libglib2.0-0
Version: 2.49.6-1
Severity: normal
Hi!
After today's upgrade of libglib2.0-0, I get every single entry of fstab,
even /proc, show up as a desktop item. This is with xfce.
Reproducible on a freshly installed system; you just get 2 entries
("Filesystem root" and "cdrom0") as fresh fstab is rather empty.
No gvfs installed, so none of those should show up.
I've eliminated every possible culprit other than libglib2.0-bin, at my
system's current state downgrading these two makes the ~20 desktop items go
away, upgrading these two makes them reappear.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.2-xfsreflink+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libglib2.0-0 depends on:
ii libc62.23-5
ii libffi6 3.2.1-4
ii libpcre3 2:8.39-2
ii libselinux1 2.5-3
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages libglib2.0-0 recommends:
ii libglib2.0-data 2.49.6-1
ii shared-mime-info 1.6-1
ii xdg-user-dirs 0.15-2
libglib2.0-0 suggests no packages.
-- no debconf information
