[Touch-packages] [Bug 1359249] Re: Launching PAVUControl works from Xubuntu, but not from Xfce
same as #1443229. I investigate the source code of indicator-sound, and find that in src/service.vala: var env = Environment.get_variable (DESKTOP_SESSION); string cmd; if (env == xubuntu || env == ubuntustudio) cmd = pavucontrol; else I think you would support more desktop environment such as XFCE by adding || env == xfce -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-sound in Ubuntu. https://bugs.launchpad.net/bugs/1359249 Title: Launching PAVUControl works from Xubuntu, but not from Xfce Status in indicator-sound package in Ubuntu: Confirmed Bug description: In Xubuntu 14.04 when clicking the sound indicator and choosing Sound Settings Pavucontrol is launched, but it does not get launched in the same scenario when the session Xfce is launched instead, with the same settings. In fact I installed the xfce4 package on top of Xubuntu's and launched it. Both xsession files list the same thing to start it, so is indicator only choosing to work on whitelisted sessions? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1359249/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1443229] [NEW] support for xfce only environment
Public bug reported: hi dev team, I find that indicator-sound cannot open pavucontrol by clicking Sound Settings... in the popup menu, in a XFCE only environment, not xubuntu, but a customized OS made by myself. I investigate the source code of indicator-sound, and find that in src/service.vala: var env = Environment.get_variable (DESKTOP_SESSION); string cmd; if (env == xubuntu || env == ubuntustudio) cmd = pavucontrol; else I think you would support more desktop environment such as XFCE. ** Affects: indicator-sound (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-sound in Ubuntu. https://bugs.launchpad.net/bugs/1443229 Title: support for xfce only environment Status in indicator-sound package in Ubuntu: New Bug description: hi dev team, I find that indicator-sound cannot open pavucontrol by clicking Sound Settings... in the popup menu, in a XFCE only environment, not xubuntu, but a customized OS made by myself. I investigate the source code of indicator-sound, and find that in src/service.vala: var env = Environment.get_variable (DESKTOP_SESSION); string cmd; if (env == xubuntu || env == ubuntustudio) cmd = pavucontrol; else I think you would support more desktop environment such as XFCE. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1443229/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1391807] [NEW] glib trash operates in wrong way, working with overlayfs
Public bug reported: hi RD QA team, I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpgfile 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir17 /etc dir17 As we can see, files share the same st_dev, while directoires share another st_dev. The reason for this in xubuntu livecd mode is, that livecd runs with overlayfs upon squashfs image. Every file the user sees is in the upper or lower file system while every directory the user sees is in the overlayfs file system. The 2 file system have different st_dev number. Now I think it's clear for the trash problem for glib with overlayfs. glib thinks a file is on the different device than user home directory, so glib is going to create .Trash-uid directory on the overlayfs file system which is /. But obviously the user has no permission to create folder in /. Therefore error occurs. Any solution or workaround before glib gives patch? Many thanks! ** Affects: glib2.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1391807 Title: glib trash operates in wrong way, working with overlayfs Status in “glib2.0” package in Ubuntu: New Bug description: hi RD QA team, I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpgfile 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir17 /etc dir17 As we can see, files share the same st_dev, while directoires share another st_dev. The reason for this in xubuntu livecd mode is, that livecd runs with overlayfs upon squashfs image. Every file the user sees is in the upper or lower file system while every directory the user sees is in the overlayfs file system. The 2 file
[Touch-packages] [Bug 1391811] [NEW] glib trash operates in wrong way, working with overlayfs
Public bug reported: hi RD QA team, (this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1391807, because I don't know the bug should be report to ubuntu or glib.) I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpg file 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir 17 /etc dir 17 As we can see, files share the same st_dev, while directoires share another st_dev. The reason for this in xubuntu livecd mode is, that livecd runs with overlayfs upon squashfs image. Every file the user sees is in the upper or lower file system while every directory the user sees is in the overlayfs file system. The 2 file system have different st_dev number. Now I think it's clear for the trash problem for glib with overlayfs. glib thinks a file is on the different device than user home directory, so glib is going to create .Trash-uid directory on the overlayfs file system which is /. But obviously the user has no permission to create folder in /. Therefore error occurs. Any solution or workaround before glib gives patch? Many thanks! ** Affects: glib2.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1391811 Title: glib trash operates in wrong way, working with overlayfs Status in “glib2.0” package in Ubuntu: New Bug description: hi RD QA team, (this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1391807, because I don't know the bug should be report to ubuntu or glib.) I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpg file 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir 17 /etc dir 17 As we can see, files share the same st_dev, while directoires share another st_dev. The reason for this in xubuntu livecd mode is, that livecd runs with overlayfs upon squashfs image. Every file the user sees is in the upper or lower file system while every directory the user sees is in the overlayfs file system. The 2 file system have different st_dev number. Now I think it's clear for the trash problem for glib with overlayfs. glib thinks a file is on the different device than user home directory, so glib is going to create .Trash-uid directory on the overlayfs
[Touch-packages] [Bug 1391807] Re: glib trash operates in wrong way, working with overlayfs
** Description changed: hi RD QA team, + + (this is a duplicate of + https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1391811, because + I don't know the bug should be report to ubuntu or glib.) I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpgfile 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir17 /etc dir17 As we can see, files share the same st_dev, while directoires share another st_dev. The reason for this in xubuntu livecd mode is, that livecd runs with overlayfs upon squashfs image. Every file the user sees is in the upper or lower file system while every directory the user sees is in the overlayfs file system. The 2 file system have different st_dev number. Now I think it's clear for the trash problem for glib with overlayfs. glib thinks a file is on the different device than user home directory, so glib is going to create .Trash-uid directory on the overlayfs file system which is /. But obviously the user has no permission to create folder in /. Therefore error occurs. Any solution or workaround before glib gives patch? Many thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1391807 Title: glib trash operates in wrong way, working with overlayfs Status in “glib2.0” package in Ubuntu: New Bug description: hi RD QA team, (this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1391811, because I don't know the bug should be report to ubuntu or glib.) I find in xubuntu livecd mode (try without installing xubuntu), if I delete a file on the desktop, xubuntu raises a dialog says Unable to find or create trash directory. But it's ok to delete a directory on the desktop. I follow the above error message in glib, and it goes to the function g_local_file_trash() in gio/glocalfile.c. I notice this line if (file_stat.st_dev == home_stat.st_dev). If it's true, glib thinks the file to be deleted is a file on the save disk with the user home directory, and creates the correct and well-known trash directory ~/.local/share/Trash, then everything would go fine. If it's false, glib treats the file to be deleted as on external disk, say, usb driver, where there should be a .Trash-uid directory on the external device. Unfortunately, the situation I stated in the first paragraph goes to the false section of the if clause, because the file to be deleted on the desktop is an overlayfs-ed file. In kernel documentation we can read: While directories will report an st_dev from the overlay-filesystem, all non-directory objects will report an st_dev from the lower or upper filesystem that is providing the object. So I write a C program to get the stat for some files and directories as follows: path type st_dev ~/Desktop/1.jpgfile 2050 ~/Desktop/test/1.jgp file 2050 /etc/fstab file 2050 ~/Desktop/test/ dir 17 /home dir 17 /home/mytestuser dir17 /etc dir
