Control: found -1 2.58.3-1
On Wed, 05 Jun 2019 at 02:49:28 +0000, 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
