Debian Bug report logs - #575031
ltspfs: issue KDE popups

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: submit@bugs.debian.org

Subject: ltspfs: USB stick did not mount on server

Date: Thu, 18 Mar 2010 19:58:38 +0100

Package:  ltspfs
Version:  0.6-1
Severity: grave
User:     debian-edu@lists.debian.org
UserTags: debian-edu

When testing LTSP using Debian Edu based on Squeeze, inserting a USB
stick on the thin client do not result in anything being mounted on
the server, and no popup showed in KDE.

I expected at least the old behavour from lenny, where the stick was
mounted in /media/, but would prefer a popup in KDE as well.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ltspfs depends on:
ii  fuse-utils                    2.8.1-1.2  Filesystem in USErspace (utilities
ii  libc6                         2.10.2-6   Embedded GNU C Library: Shared lib
ii  libfuse2                      2.8.1-1.2  Filesystem in USErspace library
ii  libx11-6                      2:1.3.3-1  X11 client-side library
ii  python                        2.5.4-9    An interactive high-level object-o

ltspfs recommends no packages.

ltspfs suggests no packages.

-- no debconf information

Message #10 received at 574516@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: Petter Reinholdtsen <pere@hungry.com>, 574516@bugs.debian.org

Subject: Bug#574516: ltspfs: USB stick did not mount on server

Date: Fri, 19 Mar 2010 13:16:45 -0700

tags 574516 help
thanks

On Thu, Mar 18, 2010 at 07:58:38PM +0100, Petter Reinholdtsen wrote:
> When testing LTSP using Debian Edu based on Squeeze, inserting a USB
> stick on the thin client do not result in anything being mounted on
> the server, and no popup showed in KDE.
> 
> I expected at least the old behavour from lenny, where the stick was
> mounted in /media/, 

i've been noticing that USB sticks don't mount if already inserted at login,
but sticks inserted after login do appear to work for me. the backports for the
same ltspfs packages work fine on lenny, which makes me suspect some
differences in udev or other packages... that issue eludes me.

after chatting in irc, sounds like this is not the case for you; it doesn't
work if inserted after login either.

some things to check:

* fuse module is loaded
* /dev/fuse is writeable by group fuse
* user is in fuse group

try debugging with a shell on the thin client. in lts.conf:

  SCREEN_07=ldm
  SCREEN_08=shell

* see if the devices show up in /dev/
* look at files in /var/run/ltspfs*


> but would prefer a popup in KDE as well.

this seems like a separate issue, really. you might be able to use the
ltspfs-mounter.d hooks. see /usr/share/doc/ltspfs/examples/kde-desktop-icons
for an example hook.


live well,
  vagrant

Message #17 received at 574516@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 574516@bugs.debian.org

Subject: Re: Bug#574516: ltspfs: USB stick did not mount on server

Date: Mon, 22 Mar 2010 11:38:06 +0100

[Vagrant Cascadian]
> some things to check:
> 
> * fuse module is loaded
> * /dev/fuse is writeable by group fuse

Both ok.

> * user is in fuse group

This is not OK.  The user is not in the fuse group.  I investigated,
and the reason is that the pam_group module is not enabled.
pam-auth-update do not have support for pam_group yet.  This is bug
report in #370346.  Can ltspfs be configured to use
consolekit/policykit instead?  It would be better to get this working
out of the box without pam_group.

Aftet activating pam_group using the patch in #370346, the user was in
the fuse group after login, and the mounting happened on the server.
No KDE popup showed up, thought. :(

>> but would prefer a popup in KDE as well.
> 
> this seems like a separate issue, really. you might be able to use
> the ltspfs-mounter.d hooks. see
> /usr/share/doc/ltspfs/examples/kde-desktop-icons for an example
> hook.

A popup really should be the default in KDE.  The user experience suck
without it.

Happy hacking,
-- 
Petter Reinholdtsen

Message #22 received at 574516@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: Petter Reinholdtsen <pere@hungry.com>, 574516@bugs.debian.org

Subject: Re: Bug#574516: ltspfs: USB stick did not mount on server

Date: Mon, 22 Mar 2010 14:51:57 -0700

retitle 574516 ltspfs: requires user to be in the fuse group
severity 574516 wishlist
clone 574516 -1
retitle -1 ltspfs: issue KDE popups
user debian-edu@lists.debian.org
usertag -1 + debian-edu
thanks

On Mon, Mar 22, 2010 at 11:38:06AM +0100, Petter Reinholdtsen wrote:
> > some things to check:
> > 
> > * fuse module is loaded
> > * /dev/fuse is writeable by group fuse
> 
> Both ok.
> 
> > * user is in fuse group
> 
> This is not OK.  The user is not in the fuse group.  

ah, well, that's expected behavior. ltspfs is a fuse filesystem, and will not
work without permissions in the fuse group.


> I investigated,
> and the reason is that the pam_group module is not enabled.
> pam-auth-update do not have support for pam_group yet.  This is bug
> report in #370346.  Can ltspfs be configured to use
> consolekit/policykit instead?  It would be better to get this working
> out of the box without pam_group.

that would be nice, but would really require getting fuse filesystems to work
with policykit/consolekit in general, rather than specifically ltspfs.

 
> Aftet activating pam_group using the patch in #370346, the user was in
> the fuse group after login, and the mounting happened on the server.

good.


> No KDE popup showed up, thought. :(

splitting this into a separate issue- please follow up to the new bug number
with KDE popup issues.


> >> but would prefer a popup in KDE as well.
> > 
> > this seems like a separate issue, really. you might be able to use
> > the ltspfs-mounter.d hooks. see
> > /usr/share/doc/ltspfs/examples/kde-desktop-icons for an example
> > hook.
> 
> A popup really should be the default in KDE.  The user experience suck
> without it.

i do not knowing what a KDE popup even is. is it a filemanager thing? an
info/message system? is there a command that can be run to trigger a popup?


live well,
  vagrant

Message #35 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: devkit-devel@lists.freedesktop.org

Cc: 575031@bugs.debian.org

Subject: creating virtual devices for fuse mounts?

Date: Fri, 23 Apr 2010 13:08:35 -0700

greetings.

i'm trying to figure out how feasible it is to create some sort of virtual
device for mountpoints mounted with fuse.

i'm hoping this is the appropriate place for such a message... if not, please
suggest a better place for such a question.

as best i can figure out, KDE and LXDE use hal or udev/udisks properties for
their file manager to recognize mounted devices or devices available for
mounting.

with fuse mounts, there is no associated device or udev event, as far as i can
tell.

in particular, i'm working with ltspfs, which is a remote fuse filesystem used
for LTSP thin-clients. ltspfs on the client-side has udev rules to detect
device insertion/removal, and then connects to the server that the user is
logged into, and sets up a fuse mount server-side that the user then accesses.

with GNOME, it recognizes mounts done in /media/, and so ltspfs mounts remote
devices in /media and it gets recognized by GNOME's filemanager.  but KDE and
LXDE don't handle mounts in /media in the same way, so ltspfs mounts that
happen in /media and are not recognized by the filemanager (other than simply
browsing to the mountpoint, like any other filesystem).

a bug reported against ltspfs in debian:

  http://bugs.debian.org/575031

is there some way to emulate a device, creating a virtual device in the
hal/udev/udisks/devicekit namespace? a short-term approach that could be used,
or a longer-term vision for how to handle these sorts of situations?

thanks for your thoughts!

please CC 575031@bugs.debian.org with a response, if you would be so kind.

live well,
  vagrant

Message #40 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Oliver Grawert <ogra@ubuntu.com>

To: Vagrant Cascadian <vagrant@freegeek.org>

Cc: 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: creating virtual devices for fuse mounts?

Date: Sat, 24 Apr 2010 09:58:22 +0200

[Message part 1 (text/plain, inline)]

hi,
Am Freitag, den 23.04.2010, 13:08 -0700 schrieb Vagrant Cascadian:
> greetings.
> 
> i'm trying to figure out how feasible it is to create some sort of virtual
> device for mountpoints mounted with fuse.
> 
> i'm hoping this is the appropriate place for such a message... if not, please
> suggest a better place for such a question.
> 
> as best i can figure out, KDE and LXDE use hal or udev/udisks properties for
> their file manager to recognize mounted devices or devices available for
> mounting.
> 
> with fuse mounts, there is no associated device or udev event, as far as i can
> tell.
> 
> in particular, i'm working with ltspfs, which is a remote fuse filesystem used
> for LTSP thin-clients. ltspfs on the client-side has udev rules to detect
> device insertion/removal, and then connects to the server that the user is
> logged into, and sets up a fuse mount server-side that the user then accesses.
> 
> with GNOME, it recognizes mounts done in /media/, and so ltspfs mounts remote
> devices in /media and it gets recognized by GNOME's filemanager.  but KDE and
> LXDE don't handle mounts in /media in the same way, so ltspfs mounts that
> happen in /media and are not recognized by the filemanager (other than simply
> browsing to the mountpoint, like any other filesystem).
> 
> a bug reported against ltspfs in debian:
> 
>   http://bugs.debian.org/575031
> 
> is there some way to emulate a device, creating a virtual device in the
> hal/udev/udisks/devicekit namespace? a short-term approach that could be used,
> or a longer-term vision for how to handle these sorts of situations?
> 
with hal it was possible to use hal-add-device and a script to create a
virtual device [1] but hal is dead beef upstream. take a look at what
the udisks package ships in /lib/udev/rules.d/, it should be possible to
write a rule that makes udisks create a virtual disk here.

ciao
	oli

[1] http://people.canonical.com/~ogra/ltspfs-hal-root.png

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: ltspfs: issue KDE popups

Date: Sun, 02 May 2010 23:07:51 +0200

Based on input from Dario Freddi on IRC, I ran "lshal --monitor" in
Debian/Lenny while inserting a USB stick, to see what hal events were
generated.

First, these three showed up:

  23:00:09.685: usb_device_90c_1000_A800000000026288 added
  23:00:10.007: usb_device_90c_1000_A800000000026288_if0 added
  23:00:10.086: usb_device_1d6b_2_0000_00_1d_7_usbraw_0 added

Then these showed up shortly after, and after the last one a popup
showed up in KDE.

  23:00:14.841: usb_device_90c_1000_A800000000026288_if0_scsi_host added
  23:00:14.865: usb_device_90c_1000_A800000000026288_if0_scsi_host_scsi_device_lun0 added
  23:00:15.091: storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0 added
  23:00:15.102: storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0 property info.interfaces = {'org.freedesktop.Hal.Device.Storage.Removable'} (new)
  23:00:16.362: volume_uuid_1f59d4b0_08d4_4551_aa27_f777df5cffb6 added

Next, I asked the media applet to safely remove the device, and these
events happend:

  23:00:27.012: storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0 property storage.removable.media_available = false
  23:00:27.025: storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0 property storage.partitioning_scheme = ''
  23:00:27.041: volume_uuid_1f59d4b0_08d4_4551_aa27_f777df5cffb6 removed

Finally I pulled the USB stick out, and these events happened:

  23:00:31.784: storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0 removed
  23:00:31.791: usb_device_90c_1000_A800000000026288_if0_scsi_host_scsi_device_lun0 removed
  23:00:31.794: usb_device_90c_1000_A800000000026288_if0_scsi_host removed
  23:00:31.803: usb_device_90c_1000_A800000000026288_if0 removed
  23:00:31.812: usb_device_1d6b_2_0000_00_1d_7_usbraw_0 removed
  23:00:31.820: usb_device_90c_1000_A800000000026288 removed

With KDE in Lenny there is a problem with umask settings for mounts,
ref <URL: http://bugs.skolelinux.org/show_bug.cgi?id=1378 >.  We
probably need to check if this is fixed in KDE 4.

Happy hacking,
-- 
Petter Reinholdtsen

Message #50 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: debian-edu@lists.debian.org

Cc: 575031@bugs.debian.org

Subject: KDE popups for ltspfs devices

Date: Sun, 2 May 2010 17:06:19 -0700

greetings...

there's been some poking about to try and figure out popups for ltspfs devices
on LTSP to get them to issue KDE popups:

  http://bugs.debian.org/575031

well, svuorela has hacked together soemthing that, while not the best vision
long-term, might prove useful enough to display something a KDE user when a
device shows up, rather than expecting them to intuitively know when devices
are plugged in or removed. last know packaging to be found here:

  http://alioth.debian.org/~pusling-guest/vaduz_0.2.dsc

i suspect it's made to work only with the KDE in squeeze, but who knows. it
does sound very EXPERIMENTAL:

  16:56 < svuorela> it is still very rough and eats children.

so don't try this on anything important just yet.

live well,
  vagrant

Message #55 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: ltspfs: issue KDE popups

Date: Mon, 3 May 2010 07:39:24 +0200

Michael Biebl tested to use hal-device --add to generate the
approporiate HAL event, but this one caused KDE to crash because some
value is missing.  Posting it her to have it documented.

cat > /tmp/device-info.txt <<EOF
block.is_volume = true  (bool)
info.capabilities = {'volume', 'block'} (string list)
info.category = 'volume'  (string)
info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
info.product = 'LTSP'  (string)
info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
volume.fstype = 'ltspfs'  (string)
volume.fsusage = 'filesystem'  (string)
volume.ignore = false  (bool)
volume.is_disc = false  (bool)
volume.is_mounted = true  (bool)
volume.is_mounted_read_only = false  (bool)
volume.is_partition = false  (bool)
volume.label = 'LTSP'  (string)
volume.mount_point = '/media/ltsp'  (string)
EOF
hal-device --add LTSP < /tmp/device-info.txt

The missing value might be possible to figure out by reading
<URL: file:///usr/share/doc/hal-doc/spec/hal-spec.html >.

When I use lshal, I see these entries listed for my USB stick, when it
is inserted but not mounted yet.  Perhaps some of these values are
required?

udi = '/org/freedesktop/Hal/devices/usb_device_90c_1000_A800000000026288_if0_scsi
_host_scsi_device_lun0'
  info.linux.driver = 'sd'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_90c_1000_A800000000026288_if0_scsi_host'  (string)
  info.product = 'SCSI Device'  (string)
  info.subsystem = 'scsi'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_90c_1000_A800000000026288_if0_scsi_host_scsi_device_lun0'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'scsi'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-4/5-4:1.0/host10/target10:0:0/10:0:0:0'  (string)
  scsi.bus = 0  (0x0)  (int)
  scsi.host = 10  (0xa)  (int)
  scsi.lun = 0  (0x0)  (int)
  scsi.model = 'Flash Voyager'  (string)
  scsi.target = 0  (0x0)  (int)
  scsi.type = 'disk'  (string)
  scsi.vendor = 'Corsair'  (string)

udi = '/org/freedesktop/Hal/devices/storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0'
  block.device = '/dev/sdb'  (string)
  block.is_volume = false  (bool)
  block.major = 8  (0x8)  (int)
  block.minor = 16  (0x10)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0'  (string)
  info.addons = {'hald-addon-storage'} (string list)
  info.capabilities = {'storage', 'block'} (string list)
  info.category = 'storage'  (string)
  info.interfaces = {'org.freedesktop.Hal.Device.Storage.Removable'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_90c_1000_A800000000026288_if0_scsi_host_scsi_device_lun0'  (string)
  info.product = 'Flash Voyager'  (string)
  info.udi = '/org/freedesktop/Hal/devices/storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0'  (string)
  info.vendor = 'Corsair'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/block/sdb'  (string)
  storage.automount_enabled_hint = true  (bool)
  storage.bus = 'usb'  (string)
  storage.drive_type = 'disk'  (string)
  storage.firmware_version = '1100'  (string)
  storage.hotpluggable = true  (bool)
  storage.lun = 0  (0x0)  (int)
  storage.media_check_enabled = true  (bool)
  storage.model = 'Flash Voyager'  (string)
  storage.no_partitions_hint = false  (bool)
  storage.originating_device = '/org/freedesktop/Hal/devices/usb_device_90c_1000_A800000000026288_if0'  (string)
  storage.partitioning_scheme = 'mbr'  (string)
  storage.removable = true  (bool)
  storage.removable.media_available = true  (bool)
  storage.removable.media_size = 4060086272  (0xf2000000)  (uint64)
  storage.removable.support_async_notification = false  (bool)
  storage.requires_eject = false  (bool)
  storage.serial = 'Corsair_Flash_Voyager_A800000000026288-0:0'  (string)
  storage.size = 0  (0x0)  (uint64)
  storage.vendor = 'Corsair'  (string)

udi = '/org/freedesktop/Hal/devices/volume_uuid_1f59d4b0_08d4_4551_aa27_f777df5cffb6'
  block.device = '/dev/sdb1'  (string)
  block.is_volume = true  (bool)
  block.major = 8  (0x8)  (int)
  block.minor = 17  (0x11)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0'  (string)
  info.capabilities = {'volume', 'block'} (string list)
  info.category = 'volume'  (string)
  info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/storage_serial_Corsair_Flash_Voyager_A800000000026288_0_0'  (string)
  info.product = 'Volume (ext3)'  (string)
  info.udi = '/org/freedesktop/Hal/devices/volume_uuid_1f59d4b0_08d4_4551_aa27_f777df5cffb6'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/block/sdb/sdb1'  (string)
  org.freedesktop.Hal.Device.Volume.method_argnames = {'mount_point fstype extra_options', 'extra_options', 'extra_options'} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_names = {'Mount', 'Unmount', 'Eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'} (string list)
  storage.model = ''  (string)
  volume.block_size = 512  (0x200)  (int)
  volume.fstype = 'ext3'  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.fsversion = '1.0'  (string)
  volume.ignore = false  (bool)
  volume.is_disc = false  (bool)
  volume.is_mounted = false  (bool)
  volume.is_mounted_read_only = false  (bool)
  volume.is_partition = true  (bool)
  volume.label = ''  (string)
  volume.linux.is_device_mapper = false  (bool)
  volume.mount.valid_options = {'ro', 'sync', 'dirsync', 'noatime', 'nodiratime', 'noexec', 'quiet', 'remount', 'exec', 'acl', 'user_xattr', 'data='} (string list)
  volume.mount_point = ''  (string)
  volume.num_blocks = 7919982  (0x78d96e)  (int)
  volume.partition.flags = {} (string list)
  volume.partition.label = ''  (string)
  volume.partition.media_size = 4060086272  (0xf2000000)  (uint64)
  volume.partition.number = 1  (0x1)  (int)
  volume.partition.scheme = 'mbr'  (string)
  volume.partition.start = 32256  (0x7e00)  (uint64)
  volume.partition.type = '0x83'  (string)
  volume.partition.uuid = ''  (string)
  volume.size = 4055030784  (0xf1b2dc00)  (uint64)
  volume.unmount.valid_options = {'lazy'} (string list)
  volume.uuid = '1f59d4b0-08d4-4551-aa27-f777df5cffb6'  (string)

Happy hacking,
-- 
Petter Reinholdtsen

Message #60 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Kel Modderman <kel@otaku42.de>

To: 575031@bugs.debian.org

Subject: Some udev info

Date: Mon, 3 May 2010 21:05:43 +1000

Hi,

Petter asked me to add this information, even though I do not fully understand
the finer details of this bug report.

udevadm can help simulate the plug/unplug events without actually doing that
physically. These commands trigger KDE's media manager to show/hide the sdc1
block device, a usb stick, on my normal system (not Debian-edu/ltspfs):

/sbin/udevadm trigger --action=remove --subsystem-match=block --sysname-match=sdc1
/sbin/udevadm trigger --action=add --subsystem-match=block --sysname-match=sdc1

You can also use 'udevadm monitor' to look at what udev is thinking about as
you unplug/plug removable devices.

Kel.

Message #65 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: debian-edu@lists.debian.org, 575031@bugs.debian.org

Subject: Re: KDE popups for ltspfs devices

Date: Tue, 4 May 2010 09:09:59 +0200

[Vagrant Cascadian]
> well, svuorela has hacked together soemthing that, while not the
> best vision long-term, might prove useful enough to display
> something a KDE user when a device shows up, rather than expecting
> them to intuitively know when devices are plugged in or
> removed. last know packaging to be found here:
> 
>   http://alioth.debian.org/~pusling-guest/vaduz_0.2.dsc

I got these test instructions from Sune on IRC:

  what to test is: build the package, install it on a kde4.3 or 4.4
  environment (on the server), log into a client in kde, run the vaduz
  binary. plug in a usb stick. see if you get a notification. if no,
  then stop. if yes, click on 'open file manager'. close file
  manager. open kwrite. go to open file. see that the device is
  available in the 'places' on the left. unplug device. see it device
  disappear from 'places'.
  try add device again, see it in places
  log out.
  remove device.
  check if device still is in 'places'.

I've also try-tested without LTSP by creating /home/$user/foo, and got
a popup but selecting the file manager button did not work.

Happy hacking,
-- 
Petter Reinholdtsen

Message #70 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org, debian-edu@lists.debian.org

Subject: Re: Bug#575031: KDE popups for ltspfs devices

Date: Tue, 4 May 2010 12:38:42 +0200

I've now tested with a test user and LTSP, and there was no popup.
Here is the output from this test.

test@tjener:~$ vaduz
(14754) KDirWatchPrivate::KDirWatchPrivate: Can't use FAM (fam daemon not running?)       
(14754) KDirWatchPrivate::KDirWatchPrivate: Available methods:  ("Stat", "INotify")       
(14754) KDirWatchPrivate::addEntry: Added Dir "/media/test" NotExisting for "" ["KDirWatch-1"]
(14754) KDirWatchPrivate::addEntry: Added Dir "/media" for "/media/test" [""]
(14754) KDirWatchPrivate::addEntry: Added File "/skole/tjener/home0/test/.local/share//user-places.xbel" NotExisting for "" ["KDirWatch-2"]
(14754) KDirWatchPrivate::addEntry: Added Dir "/skole/tjener/home0/test/.local/share" for "/skole/tjener/home0/test/.local/share//user-places.xbel" [""]
(14754) KBookmarkManager::KBookmarkManager: starting KDirWatch for  "/skole/tjener/home0/test/.local/share//user-places.xbel"
(14754) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp/kdecache-test/ksycoca4"
(14754) KDirListerCache::listDir: Listing directory: KUrl("trash:/")
(14754) KIO::Slave::createSlave: createSlave "trash" for KUrl("trash:/")
(14754) KIO::ConnectionServer::listenForRemote: Listening on  "local:/tmp/ksocket-test/vaduzT14754.slave-socket"
(14754) KDirListerCache::listDir: Entry currently being listed: KUrl("trash:/") by (KDirLister(0x8b1d7a8) )
(14754) KDirListerCache::slotResult: finished listing KUrl("trash:/")


[progam is started and seemed ready to do its stuff[

[plugged in usb stick]

(14754) KDirWatchPrivate::removeEntry: Cancelled INotify (fd 10, 1) for "/media"
(14754) KDirWatchPrivate::addEntry: Added Dir "/media" for "/media/test" [""]
(14754) KDirWatch::setCreated: "KDirWatch-1" emitting created "/media/test"
(14754) KDirWatchPrivate::removeEntry: Cancelled INotify (fd 10, 3) for "/media"


[now /media/test/usbdisk-sda1 is mounted and available for the test user]

[unplugged usb stick]

(14754) KDirWatchPrivate::inotifyEventReceived: -->got deleteself signal for "/media/test"
(14754) KDirWatchPrivate::addEntry: Added Dir "/media" for "/media/test" [""]
(14754) KDirWatchPrivate::addEntry: Added already watched Entry "/media" (for "/media/test" )
(14754) KDirWatch::setDeleted: "KDirWatch-1" emitting deleted "/media/test"

^C
test@tjener:~$

Happy hacking,
-- 
Petter Reinholdtsen

Message #75 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: ltspfs: issue KDE popups

Date: Wed, 5 May 2010 14:38:45 +0200

[Petter Reinholdtsen]
> Michael Biebl tested to use hal-device --add to generate the
> approporiate HAL event, but this one caused KDE to crash because
> some value is missing.  Posting it her to have it documented.

I investigated this some more by looking at the crash backtrace and
reading the KDE soruce, and discovered that the missing value is
block.storage_device.  Not quite sure what its value should be, but
using /org/freedesktop/Hal/devices/storage_serial_LTSP caused KDE to
not crash any more.

This script work, and causes a LTSP entry to show up in the list of
removable devices:


#!/bin/sh
cat > /tmp/device-info.txt <<EOF
block.is_volume = true  (bool)
block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_LTSP'  (string)
info.capabilities = {'volume', 'block'} (string list)
info.category = 'volume'  (string)
info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
info.product = 'LTSP'  (string)
info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
volume.fstype = 'ltspfs'  (string)
volume.fsusage = 'filesystem'  (string)
volume.ignore = false  (bool)
volume.is_disc = false  (bool)
volume.is_mounted = true  (bool)
volume.is_mounted_read_only = false  (bool)
volume.is_partition = false  (bool)
volume.label = 'LTSP'  (string)
volume.mount_point = '/media/test'  (string)
EOF
hal-device --add LTSP < /tmp/device-info.txt


To remove the entry again, this command can be used, referencing to
the uid generated by HAL for the device:

  hal-device --remove /org/freedesktop/Hal/devices/LTSP

This is only tested with KDE 4.  No idea if it work with KDE 3.

Happy hacking,
-- 
Petter Reinholdtsen

Message #80 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: Bug#575031: ltspfs: issue KDE popups

Date: Thu, 6 May 2010 10:41:37 +0200

[Petter Reinholdtsen]
> This script work, and causes a LTSP entry to show up in the list of
> removable devices:

But it only work for root, and the ltspfs hook run as the user.  I
tried using this trick in a /etc/ltspfs/mounter.d/hal-notify script,
and hal-device fail because only root can run it.  Hm, back to the
drawing board. :(

This is the script I tested:

tjener:~# cat /etc/ltspfs/mounter.d/hal-notify
#!/bin/sh

case "$1" in
    add)
        mountpoint="$2"
        devname=$(basename "$mountpoint")
        halname="storage_serial_LTSP_$devname"
        cat <<EOF | hal-device --add "$halname"
block.is_volume = true  (bool)
block.storage_device = '/org/freedesktop/Hal/devices/$halname'  (string)
storage.removable = true  (bool)
storage.hotpluggable = true  (bool)
info.capabilities = {'volume', 'block'} (string list)
info.category = 'volume'  (string)
info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
info.product = 'LTSP $devname'  (string)
info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
volume.fstype = 'ltspfs'  (string)
volume.fsusage = 'filesystem'  (string)
volume.ignore = false  (bool)
volume.is_disc = false  (bool)
volume.is_mounted = true  (bool)
volume.is_mounted_read_only = false  (bool)
volume.is_partition = false  (bool)
volume.label = ''  (string)
volume.mount_point = '$mountpoint'  (string)
EOF
        ;;
    remove)
        mountpoint="$2"
        devname=$(basename "$mountpoint")
        halname="storage_serial_LTSP_$devname"
        hal-device --remove "$halname"
        ;;
    cleanup)
        # XXX Not quite sure what is supposed to happen here
        ;;
esac
tjener:~#

Happy hacking,
-- 
Petter Reinholdtsen

Message #85 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: Bug#575031: ltspfs: issue KDE popups

Date: Thu, 6 May 2010 11:18:50 +0200

[Oliver Grawert]
> that might be because you attach it directly to the computer device
> in the tree,

Thanks for the tip.

> create an ltsp devicetree first that acts as the parent for your
> disk, that should give you more opportunities to fiddle with
> permissions through dbus service files (there might also be a way
> through consolekit/policykit without the above though).

That would be nice, yes.  As far as I know, hal-device add issues a
NewDevice event to HAL, and get a PermissionDenied in return.  According to
<URL: http://people.freedesktop.org/~dkukawka/hal-spec-git/hal-spec.html >,
uid=0 is required:

  NewDevice  Objref  PermissionDenied  Creates a new device object in the
                                       temporary device list (TDL) and
                                       return the UDI. Caller must be
                                       uid 0.
The hal code in question look like this:

       if (!local_interface && !access_check_message_caller_is_root_or_hal (ci_tra
cker, message)) {
                raise_permission_denied (connection, message, "NewDevice: not privi
leged");
                return DBUS_HANDLER_RESULT_HANDLED;
        }

And if I understand the access_check_message_caller_is_root_or_hal()
implementation, the caller uid need to be 0 or the uid of the running
hald process. :(

BTW: if this approach do not work out, Sune made a new version of
  vaduz available using GIT from
  <URL: http://git.debian.org/?p=users/pusling-guest/vaduz.git;a=summary >
  (use 'git clone http://git.debian.org/git/users/pusling-guest/vaduz.git').
  It need more work to integrate it into the desktop.

Happy hacking,
-- 
Petter Reinholtdsen

Message #90 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: Bug#575031: ltspfs: issue KDE popups

Date: Thu, 6 May 2010 13:20:41 +0200

[Oliver Grawert]
> you could include the calling code into lbmount, it already runs
> suid root on the server ;)

Good point.  That should work.  I tested this, and discovered that KDE
crashed again, but this time in HalDevice::queryDeviceInterface().  A
closer look show that the hal device have no properties when it is
created like this (lshal show now properties).  Perhaps this fail
because the mount point is inaccesible for the hal daemon?

I'm starting to wonder if the approach from Sune might be better for
now, issuing notify events on the session dbus. :/

Happy hacking,
-- 
Petter Reinholdtsen

Message #95 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: ltspfs: issue KDE popups

Date: Fri, 7 May 2010 20:54:35 +0200

[Petter Reinholdtsen]
> I'm starting to wonder if the approach from Sune might be better for
> now, issuing notify events on the session dbus. :/

An platform independent approach might be to use the python and
pynotify to submit the notifications.  This code fragment will show a
popup on any desktop, as far as I know:

#!/usr/bin/python
import pygtk
import gtk
import gobject
import pynotify
if not pynotify.init("test"):
    sys.exit(1)
n = pynotify.Notification("Test message","I am hooked.")
n.show()

I'm not sure if it is possible to get the nice button Sune inserted
nor to automatically remove the "device present" message when the
device is removed, but it would allow us to add a popup without
pulling in the KDE libraries as dependencies.

Happy hacking,
-- 
Petter Reinholdtsen

Message #100 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: Petter Reinholdtsen <pere@hungry.com>, 575031@bugs.debian.org

Subject: Re: Bug#575031: ltspfs: issue KDE popups

Date: Mon, 21 Jun 2010 22:09:36 -0700

On Fri, May 07, 2010 at 08:54:35PM +0200, Petter Reinholdtsen wrote:
> > I'm starting to wonder if the approach from Sune might be better for
> > now, issuing notify events on the session dbus. :/
> 
> An platform independent approach might be to use the python and
> pynotify to submit the notifications.  This code fragment will show a
> popup on any desktop, as far as I know:

an even shorter script, dropped into /etc/ltspfs/mounter.d and made executable:

#!/usr/bin/python
# requires python-notify
import pynotify
import sys
if not pynotify.init("test"):
  sys.exit(1)
n = pynotify.Notification("ltspfs","%s" % sys.argv[1]+' '+sys.argv[2])
n.show()

sys.argv[1] will either be "add" or "remove" and sys.argv[2] is the path of the
mountpoint (i.e. /media/USERNAME/DEVICE).

this is definitely worth including the the examples section... though it might
just be seen as noise for a gnome install, so i'm not sure it should be
installed by default.

> I'm not sure if it is possible to get the nice button Sune inserted
> nor to automatically remove the "device present" message when the
> device is removed, but it would allow us to add a popup without
> pulling in the KDE libraries as dependencies.

the notificaton messages in LXDE seemed to eventually disappear on their own,
and it issues another message on device removal.

live well,
  vagrant

Message #105 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: Bug#575031: ltspfs: issue KDE popups

Date: Thu, 24 Jun 2010 11:15:20 +0200

[Vagrant Cascadian]
> this is definitely worth including the the examples section... though it might
> just be seen as noise for a gnome install, so i'm not sure it should be
> installed by default.

I tested it on KDE, and it work there too.  I believe it should be
enabled by default to improve the ltspfs user experience a lot.

What about dynamically detect a Gnome session, and not send any
notifications there?

I looked at a Gnome session on Ubuntu/Lucid to try to figure out how
to detect a Gnome session, and some of these environment variables can
probably be used:

root@gnome-desktop:~# cat /proc/4408/environ |tr "\0" "\n"|sort|grep -i gnome|grep -vi keyring
DEFAULTS_PATH=/usr/share/gconf/gnome.default.path
DESKTOP_SESSION=gnome
GDMSESSION=gnome
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
MANDATORY_PATH=/usr/share/gconf/gnome.mandatory.path
XDG_CONFIG_DIRS=/etc/xdg/xdg-gnome:/etc/xdg
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
root@susanoo:~#

For a KDE session on Debian Edu/Lenny, I got these environment
variables set:

pere@kde-desktop ~/ $ env |sort|grep -i kde
DESKTOP_SESSION=kde
KDEDIRS=/usr/share/debian-edu-artwork/kde-profile:/usr/share/debian-edu/networked-kde3:/usr/share/debian-edu/common:/usr
KDE_FULL_SESSION=true
KDE_MULTIHEAD=false
KDE_SESSION_UID=43502
pre@kde-desktop ~/ $

Perhaps the DESKTOP_SESSION variable is a good choice?

Happy hacking,
-- 
Petter Reinholdtsen

Message #110 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: Petter Reinholdtsen <pere@hungry.com>, 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: ltspfs: issue KDE popups

Date: Fri, 25 Jun 2010 10:34:42 -0700

On Thu, Jun 24, 2010 at 11:15:20AM +0200, Petter Reinholdtsen wrote:
> [Vagrant Cascadian]
> > this is definitely worth including the the examples section... though it might
> > just be seen as noise for a gnome install, so i'm not sure it should be
> > installed by default.
> 
> I tested it on KDE, and it work there too.  I believe it should be
> enabled by default to improve the ltspfs user experience a lot.

sure.
 
> What about dynamically detect a Gnome session, and not send any
> notifications there?

all you have to do is detect a gnome session... :)
 
> I looked at a Gnome session on Ubuntu/Lucid to try to figure out how
> to detect a Gnome session, and some of these environment variables can
> probably be used:
> 
> root@gnome-desktop:~# cat /proc/4408/environ |tr "\0" "\n"|sort|grep -i gnome|grep -vi keyring
> DEFAULTS_PATH=/usr/share/gconf/gnome.default.path
> DESKTOP_SESSION=gnome
> GDMSESSION=gnome
> GNOME_DESKTOP_SESSION_ID=this-is-deprecated
> MANDATORY_PATH=/usr/share/gconf/gnome.mandatory.path
> XDG_CONFIG_DIRS=/etc/xdg/xdg-gnome:/etc/xdg
> XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
> root@susanoo:~#
... 
> Perhaps the DESKTOP_SESSION variable is a good choice?

DESKTOP_SESSION isn't set from an LDM session, and given that's the primary
use-case for LTSPFS, and that LDM would only be able to set that if the user
manually selected the session, either from the LDM user interface or from
~/.dmrc, i don't think this is a viable option...

from an LTSP thin client on Debian Squeeze:

  env | grep -i gnome
  GTK_RC_FILES=/etc/gtk/gtkrc:/home/ltsp/.gtkrc-1.2-gnome2                                                                                          
  GNOME_KEYRING_CONTROL=/tmp/keyring-qbnkKI                                                                                                         
  GNOME_DESKTOP_SESSION_ID=this-is-deprecated                                                                                                       
  XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/           

much less to go on.

i also suspect that many of the other variables tend to change a lot between
GNOME releases, so i'd want to know that the environment variables would remain
consistant for a while, and preferrably work across distros...

live well,
  vagrant

Message #115 received at 575031@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: 575031@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#575031: ltspfs: issue KDE popups

Date: Mon, 5 Jul 2010 19:49:38 +0200

[Vagrant Cascadian]
> much less to go on.

Well, enough to have a fighting chance.  I'm testing with this
implementation now.

#!/usr/bin/python
# requires python-notify
import pynotify
import sys
import string
import os
# Do not run on Gnome, as gnome detect the ltspfs mounts on its own.
xdgdirs = os.environ.get('XDG_DATA_DIRS')
if xdgdirs and -1 != xdgdirs.find("/usr/share/gnome"):
  sys.exit(0)
if not pynotify.init("edu-notify"):
  sys.exit(1)
n = pynotify.Notification("ltspfs","%s" % sys.argv[1]+' '+sys.argv[2])
n.show()

> i also suspect that many of the other variables tend to change a lot
> between GNOME releases, so i'd want to know that the environment
> variables would remain consistant for a while, and preferrably work
> across distros...

Sure, that would be nice.  But I am happy with a solution that work
now too, without having to predict what will happen in the future. :)

Happy hacking,
-- 
Petter Reinholdtsen

Message #120 received at 575031-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 575031-done@bugs.debian.org,775700-done@bugs.debian.org,843851-done@bugs.debian.org,944567-done@bugs.debian.org,

Cc: ltspfs@packages.debian.org

Subject: Bug#948595: Removed package(s) from unstable

Date: Sat, 11 Jan 2020 13:43:23 +0000

Version: 1.5-2+rm

Dear submitter,

as the package ltspfs has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/948595

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.