[Desktop-packages] [Bug 2009918] Re: package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to install/upgrade: impossible de créer un lien symbolique de secours de « ./usr/lib/x86_64-linux-gnu/dri/

2023-03-10 Thread Zakhar
Indeed that's the French translation of "No space left on the device".

As I explained in the comments, I have remastered an ISO (of 20.04) to
connect to my professional workspace (VPN Cisco AnyConnect and Citrix),
because I don't want those 2 closed source things to mess up with my
environment.

I am using that ISO inside a VM, via KVM/QEMU.

So the "bug" would be that mesa would try to install anything. That
obviously could fail considering the ISO runs in AUFS mode, and the
operation on system file is somehow restricted even more due to the
read-only part of the mount.

It does not happen all the times. Sometimes, it works just fine, does
not complain or spit out any error and does not display any artifacts.
Other times, I get the error.


This is anyway very low priority, it is not really a big deal, I just ignore 
the errors and artifacts when they happen!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/2009918

Title:
  package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to
  install/upgrade: impossible de créer un lien symbolique de secours de
  « ./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une
  nouvelle version: Aucun espace disponible sur le périphérique

Status in mesa package in Ubuntu:
  Incomplete

Bug description:
  Running inside a VM (KVM) from a remastered ISO
  The screen also show some artifacts horizontal dotted lines which disappear 
after a second or two.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1
  ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
  Uname: Linux 5.13.0-30-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5json: {
  CasperVersion: 1.445.1
  CompositorRunning: None
  Date: Fri Mar 10 08:21:08 2023
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ErrorMessage: impossible de créer un lien symbolique de secours de « 
./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une nouvelle 
version: Aucun espace disponible sur le périphérique
  ExtraDebuggingInterest: No
  GraphicsCard:
   Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) (prog-if 00 
[VGA controller])
 Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
  InstallationDate: Installed on 2022-02-22 (380 days ago)
  InstallationMedia:
   
  LiveMediaBuild: Systemback Live (MobiOffice) - Release amd64
  Lsusb:
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Lsusb-t:
   /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
   |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 
480M
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz boot=casper 
initrd=/casper/initrd.gz quiet splash
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  SourcePackage: mesa
  Title: package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to 
install/upgrade: impossible de créer un lien symbolique de secours de « 
./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une nouvelle 
version: Aucun espace disponible sur le périphérique
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.release: 0.0
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: 1.13.0-1ubuntu1.1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-focal
  dmi.modalias: 
dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:br0.0:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrpc-i440fx-focal:sku:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-focal
  dmi.sys.vendor: QEMU
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:

[Desktop-packages] [Bug 2009918] [NEW] package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to install/upgrade: impossible de créer un lien symbolique de secours de « ./usr/lib/x86_64-linux-gnu/dr

2023-03-10 Thread Zakhar
Public bug reported:

Running inside a VM (KVM) from a remastered ISO
The screen also show some artifacts horizontal dotted lines which disappear 
after a second or two.

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1
ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
Uname: Linux 5.13.0-30-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5json: {
CasperVersion: 1.445.1
CompositorRunning: None
Date: Fri Mar 10 08:21:08 2023
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ErrorMessage: impossible de créer un lien symbolique de secours de « 
./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une nouvelle 
version: Aucun espace disponible sur le périphérique
ExtraDebuggingInterest: No
GraphicsCard:
 Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) (prog-if 00 
[VGA controller])
   Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
InstallationDate: Installed on 2022-02-22 (380 days ago)
InstallationMedia:
 
LiveMediaBuild: Systemback Live (MobiOffice) - Release amd64
Lsusb:
 Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Lsusb-t:
 /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
 |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz boot=casper 
initrd=/casper/initrd.gz quiet splash
Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
PythonDetails: N/A
SourcePackage: mesa
Title: package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to 
install/upgrade: impossible de créer un lien symbolique de secours de « 
./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une nouvelle 
version: Aucun espace disponible sur le périphérique
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.release: 0.0
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.13.0-1ubuntu1.1
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-i440fx-focal
dmi.modalias: 
dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:br0.0:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-focal:cvnQEMU:ct1:cvrpc-i440fx-focal:sku:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-focal
dmi.sys.vendor: QEMU
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

** Affects: mesa (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package focal ubuntu

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/2009918

Title:
  package libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 failed to
  install/upgrade: impossible de créer un lien symbolique de secours de
  « ./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une
  nouvelle version: Aucun espace disponible sur le périphérique

Status in mesa package in Ubuntu:
  New

Bug description:
  Running inside a VM (KVM) from a remastered ISO
  The screen also show some artifacts horizontal dotted lines which disappear 
after a second or two.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1
  ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
  Uname: Linux 5.13.0-30-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5json: {
  CasperVersion: 1.445.1
  CompositorRunning: None
  Date: Fri Mar 10 08:21:08 2023
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ErrorMessage: impossible de créer un lien symbolique de secours de « 
./usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so » avant d'installer une nouvelle 
version: Aucun espace disponible sur le périphérique
  ExtraDebuggingInterest: No
  GraphicsCard:
   Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2023-01-15 Thread Zakhar
Unrelated to the current report, anyway I'll stick to my old Raspbian 32
bits (Buster) since Ubuntu 22.04 currently lacks video hardware
acceleration:

https://ubuntuforums.org/showthread.php?t=2478838

... one of the main uses of my RaspbPi being to watch videos without
having run my Desktop PC!

So yes, Ubuntu on Raspberry Pi 4 is a nice proof of concept, but there
is some work to do to catch up with the Raspeberry Pi OS... and not only
on VNC that is so much better integrated on Raspbian.

Keep up the good job!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libcuda.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libnvidia-encode.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: RDP server started
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: VNC server started

  
  On X11:
  ---
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:12:18 fpgrpi gnome-shell[3044]: D-Bus client with active sessions 
vanished
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 19.
  abr 25 00:12:18 fpgrpi systemd[2859]: Stopped GNOME Remote Desktop.
  abr 25 00:12:18 fpgrpi systemd[2859]: Starting GNOME Remote Desktop...
  abr 25 00:12:18 fpgrpi systemd[2859]: Started GNOME Remote Desktop.
  abr 25 00:12:19 fpgrpi gnome-remote-desktop-daemon[23876]: Cannot load 
libcuda.so.1
  abr 25 00:12:19 fpgrpi 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2023-01-15 Thread Zakhar
@fprietog

Indeed I regret the open VNC standard is dropped in favour of the
proprietary Microsoft's protocol RDP, itself using H.264 licence ridden
compression. It might be a more efficient standard (I hope so at least),
but it does not go in the direction of freedom!

This issue about RDP would be pretty much the same. On a clean 22.04
RaspbPi 4, the keyring only has 2 keys: the one for VNC password, and
the one for RDP configuration.

So, in all probability, if the server machine you want to access
remotely via RDP has been set as auto-login, which is convenient for a
headless Raspberry Pi 4, the machine won't be able to access whatever
RDP configuration you have set for the reason explained above (follow
the link), and would probably use a default, and possibly a random
password when needed.

Then, you probably won't be able to access the machine with RDP also
without doing the same trick.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libcuda.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libnvidia-encode.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: RDP server started
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: VNC server started

  
  On X11:
  ---
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:12:18 fpgrpi gnome-shell[3044]: D-Bus client with active sessions 
vanished
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:12:18 fpgrpi systemd[2859]: 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2023-01-14 Thread Zakhar
Sorry for the incomplete search...

Apparently this is sort of a "known bug", due to the fact that when in
"auto-login" the keyring is not unlocked then VNC server cannot access
the stored password and creates a new random one.

https://askubuntu.com/questions/1403943/22-04-remote-desktop-sharing-
authentication-password-changes-every-reboot

There is a semi-insecure fix proposed.

I'll try that until a better fix is proposed!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libcuda.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libnvidia-encode.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: RDP server started
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: VNC server started

  
  On X11:
  ---
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:12:18 fpgrpi gnome-shell[3044]: D-Bus client with active sessions 
vanished
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 19.
  abr 25 00:12:18 fpgrpi systemd[2859]: Stopped GNOME Remote Desktop.
  abr 25 00:12:18 fpgrpi systemd[2859]: Starting GNOME Remote Desktop...
  abr 25 00:12:18 fpgrpi systemd[2859]: Started GNOME Remote Desktop.
  abr 25 00:12:19 fpgrpi gnome-remote-desktop-daemon[23876]: Cannot load 
libcuda.so.1
  abr 25 00:12:19 fpgrpi gnome-remote-desktop-daemon[23876]: Cannot load 
libnvidia-encode.so.1
  abr 25 00:12:19 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2023-01-14 Thread Zakhar
New test on January 14th 2023!

VNC from another Ubuntu machine using Remmina as client is now working
with severe limitations.

Documentation I found after some more research:
- Probably a security feature:

Remote Desktop does NOT work when:
- the session is locked
- even when screen is blanked via for instance the command

dbus-send --session --dest=org.gnome.ScreenSaver --type=method_call
/org/gnome/ScreenSaver org.gnome.ScreenSaver.SetActive boolean:true


That is understandable and would not be a blocker on my use case.


Another thing, though that is a blocker, is that the password keeps changing!


Steps to reproduce:
- Switch remote desktop on
- Allow VNC (legacy method), tick "requires a password"
- Set your user ID and password
- Click on the button to view your password, and check this is indeed what you 
have set
- Without locking your session or even blanking the screen, connect from 
another Ubuntu machine (Remmina-VNC) typing your ID and Password
- This should now work

- Now reboot your Raspberry Pi 4 Ubuntu 22.04
- Display again the settings about remote connection
- Click on the button to view the password
- It is now a whole new password apparently randomly set at start up.


So now, either you need a method to get that password from command line, or set 
it back from command line (since you can still SSH and fortunately the SSH 
password is not messed around the same) or you are blocked!


Questions:
- Is this resetting of the remote password intended?
- If so, how can we retrieve/reset it from command line (gsettings, dconf,...)
- If not, should I file a different bug report?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2022-09-18 Thread Zakhar
Sorry @Dave Jones to have considered Remote Desktop as "basic". It has
been in "settings" for a while now in Ubuntu, so I was taking it for
granted.

And yes I'm aware of X-forwarding... it does NOT provide a full desktop
but only discrete graphical applications, and I have used it in some
occasion. The trouble here is that 22.04 comes with Wayland, and as the
name says, X-Forwarding works only on X11 isn't it! I wanted to test the
most "out of the box" possible, and not start messing up with graphical
environment.

That being said, unfortunately this is not at all fixed for me!

Several bugs are still there after a full upgrade, and having checked
the packages above at #11 are at the latest version.

- "Settings" do NOT remember the password I set! It keeps changing after a 
reboot...
- Connecting via VNC loops at the screen where it asks for a password, and 
keeps saying the password I pass is incorrect (related to previous bug?)
- Connecting with RDP keeps crashing on the client (the windows closes 
immediately after password input, "Domain" stays blank...we are not on W$, I 
don't have a "Domain"!)


My client is Remmina 1.4.2 (snap) running on Ubuntu Desktop 20.04 with
X11.


So... any chance someone could test that combo: Raspberry Pi 22.04 Wayland + 
Desktop (amd64) 20.04 on X11

The "not saving password" on settings on Raspberry PI 22.04 is probably
independent of graphical environment and a bug on it's own certainly.


I'll try in another 6 month... and by the time continue happily with the good 
old Raspbian-Buster 32 bits.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi 

[Desktop-packages] [Bug 1970139] Re: VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

2022-05-29 Thread Zakhar
I am experiencing the exact same syndromes plus "Settings" does not seem
to be recording correctly the VNC password, it keeps taking another
value after reboot... strange, I'll have to reproduce it.

I am eagerly waiting for the fix to make its way to the official repos!

It is a pity Canonical is advertising super optimisations on Raspberry
Pi 4 with 22.04 and this basic feature is totally broken as is: was
never ever tested...

This is a complete show-stopper for me as remote access to the machine,
be it through SSH (which works!) or graphically, is sort of a necessary
feature for this kind of machines.

Probably some way of improvement in the QA... like suggesting Canonical
to buy a Raspberry Pi 4 to the maintainers involved!.. That's a pretty
inexpensive machine. :-)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-remote-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1970139

Title:
  VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu
  22.04 LTS

Status in gnome-remote-desktop package in Ubuntu:
  In Progress

Bug description:
  # lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  # apt-cache policy gnome-remote-desktop
  gnome-remote-desktop:
Instalados: 42.0-4ubuntu1
Candidato:  42.0-4ubuntu1
Tabla de versión:
   *** 42.0-4ubuntu1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
  100 /var/lib/dpkg/status

  # uname -a
  Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  
  Summary of the bug:
  ---
  When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 
Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect 
(connection is refused). The connection passes the Password check validation 
but don't connect (sometimes shows screen garbage before disconnecting).

  I've used several VNC clients (Remmina in Ubuntu and Real VNC in
  Android) getting the same problem failing either in X11 or Wayland.

  Notes: 
  - VNC connection does work in in previous Ubuntu 21.10 version with the same 
architecture (arm64) and same Raspberry Pi.
  - VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and 
gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that 
doesn't work on arm64 (Raspberry Pi).

  There is no apport info at all. Also there is almost no info in the
  journal regarding this problem. When I try to connect to VNC server it
  show this:

  On Wayland:
  ---
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
1884160 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
4169728 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8130560 bytes), total 32768 (slots), used 83 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 
8294400 bytes), total 32768 (slots), used 3 (slots)
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions 
vanished
  abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 1.
  abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
  abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libcuda.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load 
libnvidia-encode.so.1
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: RDP server started
  abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: VNC server started

  
  On X11:
  ---
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Main 
process exited, code=killed, status=11/SEGV
  abr 25 00:12:18 fpgrpi gnome-shell[3044]: D-Bus client with active sessions 
vanished
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Failed 
with result 'signal'.
  abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Scheduled 
restart job, restart counter is at 19.
  abr 25 00:12:18 fpgrpi systemd[2859]: Stopped GNOME Remote 

[Desktop-packages] [Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.

2020-07-13 Thread Zakhar
Note: the patch (if #101 is the "right" solution) applies to the package
"grub-common" that contains /etc/grub.d/10_linux

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1845801

Title:
  [nvidia] Automatic login fails and then all subsequent logins fail.
  Killing gnome-session-binary fixes it, or just not using automatic
  login.

Status in OEM Priority Project:
  New
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-session package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-390 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-440 package in Ubuntu:
  Confirmed
Status in gdm3 source package in Eoan:
  Confirmed
Status in gnome-session source package in Eoan:
  Confirmed
Status in nvidia-graphics-drivers-435 source package in Eoan:
  Confirmed

Bug description:
  I just updated to the Ubuntu 19.10 beta. After boot, I'm shown the GDM
  login screen (which I shouldn't; I have auto login enabled), and
  logging in just takes me back to the same user selection screen even
  though the password is correct.

  If I switch to a TTY and run `sudo pkill gnome-session-binary`,
  logging in through GDM starts working again.

  I should add that the do-release-upgrade was rocky; I did it in a
  terminal from within gnome, went away for a while, and when I
  returned, I just saw an Ubuntu 19.10 in a TTY. I was able to do `sudo
  dpkg --configure -a` and complete the upgrade, but I don't know if
  something's still messed up due to that.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0
  Uname: Linux 5.3.0-13-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/:01:00.0'
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 
CDT 2019
   GCC version:  gcc version 9.2.1 20190909 (Ubuntu 9.2.1-8ubuntu1)
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Sep 28 19:55:42 2019
  DistUpgraded: 2019-09-28 18:35:15,142 INFO cache.commit()
  DistroCodename: eoan
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 435.21, 5.3.0-13-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 
00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. GP102 [GeForce GTX 1080 Ti] [1043:85e4]
  InstallationDate: Installed on 2019-09-14 (13 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  MachineType: MSI MS-7A67
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-13-generic 
root=UUID=04974c80-e732-49b6-8148-c3dce7c02a25 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  Title: Xorg crash
  UpgradeStatus: Upgraded to eoan on 2019-09-28 (0 days ago)
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2.60
  dmi.board.asset.tag: Default string
  dmi.board.name: H270I GAMING PRO AC (MS-7A67)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr2.60:bd01/25/2018:svnMSI:pnMS-7A67:pvr1.0:rvnMSI:rnH270IGAMINGPROAC(MS-7A67):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.family: Default string
  dmi.product.name: MS-7A67
  dmi.product.sku: Default string
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.1.6-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20190820-0ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20190815-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1845801/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : 

[Desktop-packages] [Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.

2020-07-13 Thread Zakhar
So to make #101 permanent, you have to "patch" line 335 of
/etc/grub.d/10_Linux

from:
set vt_handoff=vt.handoff=7
to:
set vt_handoff=vt.handoff=1


Not sure though the same "patch" is also to be applied in other files like 
10_linuxzfs, etc...

Patch attached:
$ cat 10_linux.patch 
--- 10_linux_orig   2020-07-13 09:06:55.593140059 +0200
+++ 10_linux2020-07-13 09:08:57.799858927 +0200
@@ -332,7 +332,7 @@
 if [ "$vt_handoff" = 1 ]; then
   cat << 'EOF'
if [ "${1}" = "keep" ]; then
-   set vt_handoff=vt.handoff=7
+   set vt_handoff=vt.handoff=1
else
set vt_handoff=
fi


** Patch added: "Patching /etc/grub.d/10_linux so that #101 becomes permanent."
   
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1845801/+attachment/5392219/+files/10_linux.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1845801

Title:
  [nvidia] Automatic login fails and then all subsequent logins fail.
  Killing gnome-session-binary fixes it, or just not using automatic
  login.

Status in OEM Priority Project:
  New
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-session package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-390 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-440 package in Ubuntu:
  Confirmed
Status in gdm3 source package in Eoan:
  Confirmed
Status in gnome-session source package in Eoan:
  Confirmed
Status in nvidia-graphics-drivers-435 source package in Eoan:
  Confirmed

Bug description:
  I just updated to the Ubuntu 19.10 beta. After boot, I'm shown the GDM
  login screen (which I shouldn't; I have auto login enabled), and
  logging in just takes me back to the same user selection screen even
  though the password is correct.

  If I switch to a TTY and run `sudo pkill gnome-session-binary`,
  logging in through GDM starts working again.

  I should add that the do-release-upgrade was rocky; I did it in a
  terminal from within gnome, went away for a while, and when I
  returned, I just saw an Ubuntu 19.10 in a TTY. I was able to do `sudo
  dpkg --configure -a` and complete the upgrade, but I don't know if
  something's still messed up due to that.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0
  Uname: Linux 5.3.0-13-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/:01:00.0'
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 
CDT 2019
   GCC version:  gcc version 9.2.1 20190909 (Ubuntu 9.2.1-8ubuntu1)
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Sep 28 19:55:42 2019
  DistUpgraded: 2019-09-28 18:35:15,142 INFO cache.commit()
  DistroCodename: eoan
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 435.21, 5.3.0-13-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 
00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. GP102 [GeForce GTX 1080 Ti] [1043:85e4]
  InstallationDate: Installed on 2019-09-14 (13 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  MachineType: MSI MS-7A67
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-13-generic 
root=UUID=04974c80-e732-49b6-8148-c3dce7c02a25 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  Title: Xorg crash
  UpgradeStatus: Upgraded to eoan on 2019-09-28 (0 days ago)
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2.60
  dmi.board.asset.tag: Default string
  dmi.board.name: H270I GAMING PRO AC (MS-7A67)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr2.60:bd01/25/2018:svnMSI:pnMS-7A67:pvr1.0:rvnMSI:rnH270IGAMINGPROAC(MS-7A67):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.family: Default string
  dmi.product.name: MS-7A67
  dmi.product.sku: Default string
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.1.6-1ubuntu1
 

[Desktop-packages] [Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.

2020-07-13 Thread Zakhar
Hello, I can confirm that this bug still exists in 20.04.

I am using NVidia 340.108 because this is a 12 years old laptop with a
completely obsolete GeForce GT230M.

Workaround #34 (removing quiet splash) worked but slows down the boot
process due to the speed of writing on the console.

Workaround #101 work fine: no "garbage" output on the console and no
slow down. 12 years old PC booting in 40 sec (including 8.5 due to the
BIOS itself).

Unfortunately patching manually the grub.cfg does not withstand updates
like kernel that will run update-grub, so I hope there will be a better
patch soon!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1845801

Title:
  [nvidia] Automatic login fails and then all subsequent logins fail.
  Killing gnome-session-binary fixes it, or just not using automatic
  login.

Status in OEM Priority Project:
  New
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-session package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-390 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-435 package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-440 package in Ubuntu:
  Confirmed
Status in gdm3 source package in Eoan:
  Confirmed
Status in gnome-session source package in Eoan:
  Confirmed
Status in nvidia-graphics-drivers-435 source package in Eoan:
  Confirmed

Bug description:
  I just updated to the Ubuntu 19.10 beta. After boot, I'm shown the GDM
  login screen (which I shouldn't; I have auto login enabled), and
  logging in just takes me back to the same user selection screen even
  though the password is correct.

  If I switch to a TTY and run `sudo pkill gnome-session-binary`,
  logging in through GDM starts working again.

  I should add that the do-release-upgrade was rocky; I did it in a
  terminal from within gnome, went away for a while, and when I
  returned, I just saw an Ubuntu 19.10 in a TTY. I was able to do `sudo
  dpkg --configure -a` and complete the upgrade, but I don't know if
  something's still messed up due to that.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0
  Uname: Linux 5.3.0-13-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/:01:00.0'
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 
CDT 2019
   GCC version:  gcc version 9.2.1 20190909 (Ubuntu 9.2.1-8ubuntu1)
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Sep 28 19:55:42 2019
  DistUpgraded: 2019-09-28 18:35:15,142 INFO cache.commit()
  DistroCodename: eoan
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 435.21, 5.3.0-13-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 
00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. GP102 [GeForce GTX 1080 Ti] [1043:85e4]
  InstallationDate: Installed on 2019-09-14 (13 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  MachineType: MSI MS-7A67
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-13-generic 
root=UUID=04974c80-e732-49b6-8148-c3dce7c02a25 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  Title: Xorg crash
  UpgradeStatus: Upgraded to eoan on 2019-09-28 (0 days ago)
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2.60
  dmi.board.asset.tag: Default string
  dmi.board.name: H270I GAMING PRO AC (MS-7A67)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr2.60:bd01/25/2018:svnMSI:pnMS-7A67:pvr1.0:rvnMSI:rnH270IGAMINGPROAC(MS-7A67):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.family: Default string
  dmi.product.name: MS-7A67
  dmi.product.sku: Default string
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.1.6-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20190820-0ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  

[Desktop-packages] [Bug 1051726] Re: WebDav broken, Nautilus sends data on a closed TCP connection!

2019-01-23 Thread Zakhar
Sorry, I have stopped using Nautilus when Gnome decided it should be a
tablet tool instead of a PC program, and withdraw all interesting
functions from it (like F3 to open a double pane).

I am now using Nemo, which might still have the bug since it forked
Nautilus before its emasculation, but I am also not using WebDAV
anymore.

As far as I am concerned, you can leave this bug to "low" importance, or
even close it.

"Close" I am not quite sure because it could affect others...

Many thanks for the reply though!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1051726

Title:
  WebDav broken, Nautilus sends data on a closed TCP connection!

Status in nautilus package in Ubuntu:
  Incomplete

Bug description:
  ENVIRONMENT:
  -
  Precise 64
  Nautilus 3.4.2

  $ uname -a && nautilus --version
  Linux zakhar-desktop 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 
2012 x86_64 x86_64 x86_64 GNU/Linux
  GNOME nautilus 3.4.2

  
  WEBDAV:
  
  I set up a local Apache WebDAV with standard options.
  No SSL
  Basic authentication (it is for local use)

  When I instruct Nautilus to go to my WebDAV (dav://127.0.0.1/webdav/)
  I get an error.

  After a few hours of investigation, I discovered the bug: Nautilus
  sends data to a closed TCP connection!

  
  WHAT HAPPENS:
  --
  When you hit "Enter" after the address  (dav://127.0.0.1/webdav/), Nautilus 
issues a plain request to the server.
  Then, of course, the server replies 401: Authorisation required.
  Having this response, Nautilus shows the box where you can enter 
user/password.

  ... the trouble is... if it takes you more than 5 seconds to type the
  password, the default keepalive of Apache being 5 seconds, the
  connection will be closed.

  Then, once you have entered both username and password, Nautilus re-
  issues the same request with the Authorization header.

  ... but this is done on a closed connection!..

  
  PROOF:
  --
  This is the Wireshark summary trace from a second PC (client is 
192.168.0.132, server is 192.168.0.130)
  No. TimeSourceDestination   Protocol 
Length Info
1 0.00192.168.0.132 192.168.0.130 TCP  74   
  38035 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
2 0.40192.168.0.130 192.168.0.132 TCP  74   
  http > 38035 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 
3 0.000246192.168.0.132 192.168.0.130 TCP  66   
  38035 > http [ACK] Seq=1 Ack=1 Win=14656 Len=0
4 0.000534192.168.0.132 192.168.0.130 HTTP 230  
  OPTIONS /webdav HTTP/1.1 
5 0.000555192.168.0.130 192.168.0.132 TCP  66   
  http > 38035 [ACK] Seq=1 Ack=165 Win=15552 Len=0 
6 0.001226192.168.0.130 192.168.0.132 HTTP 727  
  HTTP/1.1 401 Authorization Required  (text/html)
7 0.001698192.168.0.132 192.168.0.130 TCP  66   
  38035 > http [ACK] Seq=165 Ack=662 Win=15936 Len=0
8 5.003870192.168.0.130 192.168.0.132 TCP  66   
  http > 38035 [FIN, ACK] Seq=662 Ack=165 Win=15552 Len=0
9 5.042256192.168.0.132 192.168.0.130 TCP  66   
  38035 > http [ACK] Seq=165 Ack=663 Win=15936 Len=0
   10 7.873829192.168.0.132 192.168.0.130 HTTP 273  
  OPTIONS /webdav HTTP/1.1 
   11 7.873866192.168.0.130 192.168.0.132 TCP  54   
  http > 38035 [RST] Seq=663 Win=0 Len=0
   12 7.873872192.168.0.132 192.168.0.130 TCP  66   
  38035 > http [FIN, ACK] Seq=372 Ack=663 Win=15936 Len=0 
   13 7.873881192.168.0.130 192.168.0.132 TCP  54   
  http > 38035 [RST] Seq=663 Win=0 Len=0

  
  As you can see, packet 8 occurs around 5 second after the packet 7, and is a 
FIN from the server (5 seconds of inactivity).

  I spent almost 8 seconds typing username/password, and then at 7.8
  sec, the second request with the Authorization goes out... WITHOUT
  reopening the connection.

  Of course, the server is not happy with that and issues a RST, and
  subsequently Nautilus says that there is an error.

  
  To check that it is indeed the source of the bug, I bumped the keep-alive 
time-out in my Apache config to 30 seconds, and this time, all was fine (of 
course I typed the user/password in less than 30 secs).

  
  GUESSING:
  -
  With previous versions of Nautilus where you had to enter in a windows the 
address of the server, the protocol, the username and password... THEN hit 
enter, I imagine such things didn't show as it was 'fast enough' not to be in 
that situation.

  Having removed this windows, t

[Desktop-packages] [Bug 1759462] Re: Keyboard shortcuts not operational on 18.04

2018-08-18 Thread Zakhar
Fresh install of 18.04.1 + Unity

I had the bug, but I can confirm than workaround at post #11 (2 seconds
delay before starting compiz) has fixed it.

Thanks Park Ju Hyung!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/1759462

Title:
  Keyboard shortcuts not operational on 18.04

Status in gnome-settings-daemon package in Ubuntu:
  Confirmed

Bug description:
  After installing 18.04, I noticed that certain keyboard shortcuts no
  longer function.

  It appears to be related to the shortcuts that gnome-settings-daemon
  control as my shortcuts that are provided by my desktop (Budgie) still
  function.

  Some examples are:

  * Media keys for volume up/down/mute
  * ctrl-alt-t for the terminal. I tried changing the shortcut to test. Same 
behaviour.

  I double checked, and it looks like the needed daemon is still
  running,

  ```
  dustin3337  0.0  0.2 500736 22216 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-keyboard
  dustin3338  0.0  0.3 943372 25732 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-media-keys
  dustin3343  0.0  0.0 274908  5844 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-mouse
  dustin3345  0.0  0.3 519896 25144 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-power
  dustin3348  0.0  0.1 346004 10212 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-print-notifications
  dustin3351  0.0  0.0 374684  7952 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-smartcard
  dustin3355  0.0  0.1 329584  8064 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-sound
  dustin3361  0.0  0.1 449708  9856 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-sharing
  dustin3367  0.0  0.0 272416  4772 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-screensaver-proxy
  dustin3375  0.0  0.0 420028  5804 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-rfkill
  dustin3383  0.0  0.2 507120 23244 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-wacom
  dustin3385  0.0  0.3 498040 25040 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-xsettings
  dustin3387  0.0  0.0 274900  5936 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-a11y-settings
  dustin3392  0.0  0.2 496016 22044 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-clipboard
  dustin3395  0.0  0.3 810156 25976 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-color
  dustin3396  0.0  0.2 471656 21080 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-datetime
  dustin3400  0.0  0.0 361196  7116 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-housekeeping
  dustin3433  0.0  0.1 505404 12576 ?Sl   21:03   0:00 
/usr/lib/gnome-settings-daemon/gsd-printer
  dustin9776  0.0  0.0  18188  1032 pts/1S+   21:19   0:00 grep 
--color=auto gnome-settings-daemon
  ```

  Reboot does not seem to help. However, occasionally the shortcuts do
  seem to work - but only very occasionally.

  Any other info needed?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-settings-daemon 3.28.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
  Uname: Linux 4.15.0-12-generic x86_64
  ApportVersion: 2.20.9-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Budgie:GNOME
  Date: Tue Mar 27 21:12:18 2018
  InstallationDate: Installed on 2018-03-05 (22 days ago)
  InstallationMedia: Ubuntu-Budgie 18.04 LTS "Bionic Beaver" - Alpha amd64 
(20180304)
  SourcePackage: gnome-settings-daemon
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1759462/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1741027] Re: [FFE] screen sharing panels abort using an unexistant vino gsettings key

2018-06-06 Thread Zakhar
Here is an ugly 3 steps workaround:

-1) Edit the org.gnome.Vino schema to restore the missing "enabled"
parameter (copying from 16.04)

sudo nano /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml

Add this key:

  Enable remote access to the desktop
  
If true, allows remote access to the desktop via the RFB
protocol. Users on remote machines may then connect to the
desktop using a VNC viewer.
  
  false


-2) Compile the schemas for Gnome:

sudo glib-compile-schemas /usr/share/glib-2.0/schemas


-3) Now the screen sharing panel in unity-control-center works... but this is 
not enough to get vino running! So you need to add in the programs at session 
start: Vino-server with the following command line:

/usr/lib/vino/vino-server


Now you can VNC your 18.04-Unity!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to vino in Ubuntu.
https://bugs.launchpad.net/bugs/1741027

Title:
  [FFE] screen sharing panels abort using an unexistant vino gsettings
  key

Status in unity-control-center package in Ubuntu:
  Confirmed
Status in unity-settings-daemon package in Ubuntu:
  Confirmed
Status in vino package in Ubuntu:
  Invalid

Bug description:
  [FFE]

  This happens because Gnome removed that particular gsettings key. The
  removal did not happen with the ui removal but rather much later than
  that. That is why it doesn't work with the latest version of vino.

  As of now If users try to open the new sharing panel, unity-control-
  center will crash. This sort behavior is not desired on LTS release
  (18.04).


  
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
unity-control-center.  This problem was most recently seen with package version 
15.04.0+17.10.20171225-0ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/be6d095e2145d77c79a6e47e17c94dfe70bcaa0a 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

  Specifically, the error report

   "Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled' "

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1741027/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1775423] Re: Unity Control Center crashes when selecting Desktop Sharing

2018-06-06 Thread Zakhar
*** This bug is a duplicate of bug 1741027 ***
https://bugs.launchpad.net/bugs/1741027

More information (crash report) here:

https://errors.ubuntu.com/oops/a5173a48-699f-11e8-9b32-fa163ed44aae

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1775423

Title:
  Unity Control Center crashes when selecting Desktop Sharing

Status in unity-control-center package in Ubuntu:
  New

Bug description:
  Fresh install 18.04 + ubuntu-unity-desktop

  unity-control-center crashes when trying to setup "Desktop Sharing"

  Message (when launched from a terminal)

  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747:
  Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled'

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-22-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1775423/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1775423] ProcCpuinfoMinimal.txt

2018-06-06 Thread Zakhar
*** This bug is a duplicate of bug 1741027 ***
https://bugs.launchpad.net/bugs/1741027

apport information

** Attachment added: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/bugs/1775423/+attachment/5149412/+files/ProcCpuinfoMinimal.txt

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1775423

Title:
  Unity Control Center crashes when selecting Desktop Sharing

Status in unity-control-center package in Ubuntu:
  New

Bug description:
  Fresh install 18.04 + ubuntu-unity-desktop

  unity-control-center crashes when trying to setup "Desktop Sharing"

  Message (when launched from a terminal)

  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747:
  Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled'

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-22-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1775423/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1775423] ProcEnviron.txt

2018-06-06 Thread Zakhar
*** This bug is a duplicate of bug 1741027 ***
https://bugs.launchpad.net/bugs/1741027

apport information

** Attachment added: "ProcEnviron.txt"
   
https://bugs.launchpad.net/bugs/1775423/+attachment/5149413/+files/ProcEnviron.txt

** This bug has been marked a duplicate of bug 1741027
   [FFE] screen sharing panels abort using an unexistant vino gsettings key

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1775423

Title:
  Unity Control Center crashes when selecting Desktop Sharing

Status in unity-control-center package in Ubuntu:
  New

Bug description:
  Fresh install 18.04 + ubuntu-unity-desktop

  unity-control-center crashes when trying to setup "Desktop Sharing"

  Message (when launched from a terminal)

  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747:
  Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled'

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-22-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1775423/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1775423] Re: Unity Control Center crashes when selecting Desktop Sharing

2018-06-06 Thread Zakhar
*** This bug is a duplicate of bug 1741027 ***
https://bugs.launchpad.net/bugs/1741027

apport information

** Tags added: apport-collected

** Description changed:

  Fresh install 18.04 + ubuntu-unity-desktop
  
  unity-control-center crashes when trying to setup "Desktop Sharing"
  
  Message (when launched from a terminal)
  
  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747: Settings
  schema 'org.gnome.Vino' does not contain a key named 'enabled'
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
+ --- 
+ ApportVersion: 2.20.9-0ubuntu7.1
+ Architecture: amd64
+ CurrentDesktop: Unity:Unity7:ubuntu
+ DistroRelease: Ubuntu 18.04
+ InstallationDate: Installed on 2018-06-06 (0 days ago)
+ InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
+ Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
+ PackageArchitecture: amd64
+ ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
+ Tags:  bionic
+ Uname: Linux 4.15.0-22-generic x86_64
+ UpgradeStatus: No upgrade log present (probably fresh install)
+ UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
+ _MarkForUpload: True

** Attachment added: "Dependencies.txt"
   
https://bugs.launchpad.net/bugs/1775423/+attachment/5149411/+files/Dependencies.txt

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1775423

Title:
  Unity Control Center crashes when selecting Desktop Sharing

Status in unity-control-center package in Ubuntu:
  New

Bug description:
  Fresh install 18.04 + ubuntu-unity-desktop

  unity-control-center crashes when trying to setup "Desktop Sharing"

  Message (when launched from a terminal)

  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747:
  Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled'

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-22-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1775423/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1775423] [NEW] Unity Control Center crashes when selecting Desktop Sharing

2018-06-06 Thread Zakhar
Public bug reported:

Fresh install 18.04 + ubuntu-unity-desktop

unity-control-center crashes when trying to setup "Desktop Sharing"

Message (when launched from a terminal)

(unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747: Settings
schema 'org.gnome.Vino' does not contain a key named 'enabled'

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
Uname: Linux 4.15.0-22-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.1
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
Date: Wed Jun  6 17:45:31 2018
InstallationDate: Installed on 2018-06-06 (0 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: unity-control-center
UpgradeStatus: No upgrade log present (probably fresh install)
--- 
ApportVersion: 2.20.9-0ubuntu7.1
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2018-06-06 (0 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
Tags:  bionic
Uname: Linux 4.15.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

** Affects: unity-control-center (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug apport-collected bionic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1775423

Title:
  Unity Control Center crashes when selecting Desktop Sharing

Status in unity-control-center package in Ubuntu:
  New

Bug description:
  Fresh install 18.04 + ubuntu-unity-desktop

  unity-control-center crashes when trying to setup "Desktop Sharing"

  Message (when launched from a terminal)

  (unity-control-center:10876): GLib-GIO-ERROR **: 17:49:24.747:
  Settings schema 'org.gnome.Vino' does not contain a key named
  'enabled'

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  Date: Wed Jun  6 17:45:31 2018
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: unity-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.9-0ubuntu7.1
  Architecture: amd64
  CurrentDesktop: Unity:Unity7:ubuntu
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-06-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: unity-control-center 15.04.0+18.04.20180216-0ubuntu1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-22-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1775423/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1341292] Re: nautilus don't liberate the memory

2014-08-13 Thread Zakhar
The same bug exists on Nemo (should there be different bug report?)
It is less troublesome when you don't set Nemo as handling also your desktop, 
because closing Nemo correctly frees the memory.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.1 LTS
Release:14.04
Codename:   trusty

$ uname -a
Linux alain-Desktop 3.13.0-33-generic #58-Ubuntu SMP Tue Jul 29 16:45:05 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -s nemo
Package: nemo
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 2096
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
Architecture: amd64
Version: 1.8.4-1.1
Depends: desktop-file-utils (= 0.7), gsettings-desktop-schemas, gvfs (= 
1.3.2), libglib2.0-data, nemo-data (= 1.8.4-1.1), shared-mime-info (= 0.50), 
libatk1.0-0 (= 1.32.0), libc6 (= 2.14), libcairo-gobject2 (= 1.10.0), 
libcairo2 (= 1.10.0), libexempi3 (= 2.2.0), libexif12, libgail-3-0 (= 
3.0.0), libgdk-pixbuf2.0-0 (= 2.22.0), libglib2.0-0 (= 2.37.3), 
libgnome-desktop-3-7 (= 3.2.0), libgtk-3-0 (= 3.3.18), libnemo-extension1 (= 
1.1.2), libnotify4 (= 0.7.0), libpango-1.0-0 (= 1.20.0), libpangocairo-1.0-0 
(= 1.14.0), libx11-6, libxml2 (= 2.7.4)
Recommends: eject, gvfs-backends, librsvg2-common, nemo-fileroller
Suggests: eog, evince | pdf-viewer, totem | mp3-decoder, xdg-user-dirs
Conffiles:
 /etc/xdg/autostart/nemo-autostart.desktop 01d1d8b6dbcb93ff99e0ad13004bd209
Description: File manager and graphical shell for Cinnamon
 Nemo is the official file manager for the Cinnamon desktop. It allows
 to browse directories, preview files and launch applications associated
 with them. It is also responsible for handling the icons on the Cinnamon
 desktop. It works on local and remote filesystems.
 .
 Several icon themes and components for viewing different kinds of files
 are available in separate packages.
Original-Maintainer: Nicolas Bourdaud nicolas.bourd...@gmail.com
Homepage: http://www.github.com/linuxmint/nemo/

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1341292

Title:
  nautilus don't liberate the memory

Status in “nautilus” package in Ubuntu:
  Confirmed

Bug description:
  nautilus (3.10.1-0ubuntu8,3.10.1-0ubuntu9.1)
  don't liberate then memory
  I use Ctrl ++ to increase the images
  exemple
  directory Rep:: 616 photos (2,1 Gio)
  open Nautilus on this directory Rep , Ctrl +++ , close nautilus
  memory occuped by nautilus : 527Mio
  ..
  I redo this (five times)
  open Nautilus on this directory Rep , Ctrl +++ close nautilus
  memory occuped by nautilus : 2,8Gio
  the six time : nautilus is killed by the system ( because memory occuped more 
80% )

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: nautilus 1:3.10.1-0ubuntu9.1
  ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
  Uname: Linux 3.13.0-30-generic i686
  ApportVersion: 2.14.1-0ubuntu3.2
  Architecture: i386
  CurrentDesktop: Unity
  Date: Sun Jul 13 15:47:03 2014
  ExecutablePath: /usr/bin/nautilus
  GsettingsChanges:
   b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 
'size', 'type', 'date_modified', 'permissions', 'where']
   b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 
'mime_type', 'where']
  InstallationDate: Installed on 2014-05-25 (48 days ago)
  InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release i386 (20140417)
  ProcEnviron:
   LANGUAGE=fr_FR
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=set
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1341292/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1051726] Re: WebDav broken, Nautilus sends data on a closed TCP connection!

2012-09-17 Thread Zakhar
YOU WOULD HAVE GUESSED...
---
Obviously we notice this buggy behaviour when we use directly Goto  Location  
and enter the address: dav://127.0.0.1/webdav

When using the dialog box under File  Connect to server..., this does not 
happen as there is only one request to the server (and not a pair: 1st with no 
authentication, 2nd authenticated).
So, using the dialog box  ticking 'remember the password' is the best way to 
workaround the bug actually.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1051726

Title:
  WebDav broken, Nautilus sends data on a closed TCP connection!

Status in “nautilus” package in Ubuntu:
  New

Bug description:
  ENVIRONMENT:
  -
  Precise 64
  Nautilus 3.4.2

  $ uname -a  nautilus --version
  Linux zakhar-desktop 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 
2012 x86_64 x86_64 x86_64 GNU/Linux
  GNOME nautilus 3.4.2

  
  WEBDAV:
  
  I set up a local Apache WebDAV with standard options.
  No SSL
  Basic authentication (it is for local use)

  When I instruct Nautilus to go to my WebDAV (dav://127.0.0.1/webdav/)
  I get an error.

  After a few hours of investigation, I discovered the bug: Nautilus
  sends data to a closed TCP connection!

  
  WHAT HAPPENS:
  --
  When you hit Enter after the address  (dav://127.0.0.1/webdav/), Nautilus 
issues a plain request to the server.
  Then, of course, the server replies 401: Authorisation required.
  Having this response, Nautilus shows the box where you can enter 
user/password.

  ... the trouble is... if it takes you more than 5 seconds to type the
  password, the default keepalive of Apache being 5 seconds, the
  connection will be closed.

  Then, once you have entered both username and password, Nautilus re-
  issues the same request with the Authorization header.

  ... but this is done on a closed connection!..

  
  PROOF:
  --
  This is the Wireshark summary trace from a second PC (client is 
192.168.0.132, server is 192.168.0.130)
  No. TimeSourceDestination   Protocol 
Length Info
1 0.00192.168.0.132 192.168.0.130 TCP  74   
  38035  http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
2 0.40192.168.0.130 192.168.0.132 TCP  74   
  http  38035 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 
3 0.000246192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=1 Ack=1 Win=14656 Len=0
4 0.000534192.168.0.132 192.168.0.130 HTTP 230  
  OPTIONS /webdav HTTP/1.1 
5 0.000555192.168.0.130 192.168.0.132 TCP  66   
  http  38035 [ACK] Seq=1 Ack=165 Win=15552 Len=0 
6 0.001226192.168.0.130 192.168.0.132 HTTP 727  
  HTTP/1.1 401 Authorization Required  (text/html)
7 0.001698192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=165 Ack=662 Win=15936 Len=0
8 5.003870192.168.0.130 192.168.0.132 TCP  66   
  http  38035 [FIN, ACK] Seq=662 Ack=165 Win=15552 Len=0
9 5.042256192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=165 Ack=663 Win=15936 Len=0
   10 7.873829192.168.0.132 192.168.0.130 HTTP 273  
  OPTIONS /webdav HTTP/1.1 
   11 7.873866192.168.0.130 192.168.0.132 TCP  54   
  http  38035 [RST] Seq=663 Win=0 Len=0
   12 7.873872192.168.0.132 192.168.0.130 TCP  66   
  38035  http [FIN, ACK] Seq=372 Ack=663 Win=15936 Len=0 
   13 7.873881192.168.0.130 192.168.0.132 TCP  54   
  http  38035 [RST] Seq=663 Win=0 Len=0

  
  As you can see, packet 8 occurs around 5 second after the packet 7, and is a 
FIN from the server (5 seconds of inactivity).

  I spent almost 8 seconds typing username/password, and then at 7.8
  sec, the second request with the Authorization goes out... WITHOUT
  reopening the connection.

  Of course, the server is not happy with that and issues a RST, and
  subsequently Nautilus says that there is an error.

  
  To check that it is indeed the source of the bug, I bumped the keep-alive 
time-out in my Apache config to 30 seconds, and this time, all was fine (of 
course I typed the user/password in less than 30 secs).

  
  GUESSING:
  -
  With previous versions of Nautilus where you had to enter in a windows the 
address of the server, the protocol, the username and password... THEN hit 
enter, I imagine such things didn't show as it was 'fast enough' not to be in 
that situation.

  Having removed this windows, the bug shows.

  It is bad because my workaround (timeout to 30 secs) is hazardous.
  In fact you can't really guess how much

[Desktop-packages] [Bug 1051726] Re: WebDav broken, Nautilus sends data on a closed TCP connection!

2012-09-16 Thread Zakhar
REFINED WORKAROUND:
--
Of course, if like in the case above, it is YOUR server, for YOUR local use, 
there is a better way.
Whatever the password length, you bump the keep-alive time-out to an insane 
value (600 secs!) so that you have a large amount of time to type -10 minutes 
should be much enough!-. Then, before hitting Enter, you instruct Nautilus to 
keep the password forever.
Once done, you can remove the keepalivetimeout directive so that it reverts 
back to the default 5 secs, because next time Nautilus won't prompt you for a 
user/password and consequently the bug won't show.


Of course, this is not possible if the WebDAV you try to connect to is not YOUR 
server!
Then, the bug remains, and is blocking if you want to use such a public WebDAV 
server with a low keepalive timeout.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1051726

Title:
  WebDav broken, Nautilus sends data on a closed TCP connection!

Status in “nautilus” package in Ubuntu:
  New

Bug description:
  ENVIRONMENT:
  -
  Precise 64
  Nautilus 3.4.2

  $ uname -a  nautilus --version
  Linux zakhar-desktop 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 
2012 x86_64 x86_64 x86_64 GNU/Linux
  GNOME nautilus 3.4.2

  
  WEBDAV:
  
  I set up a local Apache WebDAV with standard options.
  No SSL
  Basic authentication (it is for local use)

  When I instruct Nautilus to go to my WebDAV (dav://127.0.0.1/webdav/)
  I get an error.

  After a few hours of investigation, I discovered the bug: Nautilus
  sends data to a closed TCP connection!

  
  WHAT HAPPENS:
  --
  When you hit Enter after the address  (dav://127.0.0.1/webdav/), Nautilus 
issues a plain request to the server.
  Then, of course, the server replies 401: Authorisation required.
  Having this response, Nautilus shows the box where you can enter 
user/password.

  ... the trouble is... if it takes you more than 5 seconds to type the
  password, the default keepalive of Apache being 5 seconds, the
  connection will be closed.

  Then, once you have entered both username and password, Nautilus re-
  issues the same request with the Authorization header.

  ... but this is done on a closed connection!..

  
  PROOF:
  --
  This is the Wireshark summary trace from a second PC (client is 
192.168.0.132, server is 192.168.0.130)
  No. TimeSourceDestination   Protocol 
Length Info
1 0.00192.168.0.132 192.168.0.130 TCP  74   
  38035  http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
2 0.40192.168.0.130 192.168.0.132 TCP  74   
  http  38035 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 
3 0.000246192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=1 Ack=1 Win=14656 Len=0
4 0.000534192.168.0.132 192.168.0.130 HTTP 230  
  OPTIONS /webdav HTTP/1.1 
5 0.000555192.168.0.130 192.168.0.132 TCP  66   
  http  38035 [ACK] Seq=1 Ack=165 Win=15552 Len=0 
6 0.001226192.168.0.130 192.168.0.132 HTTP 727  
  HTTP/1.1 401 Authorization Required  (text/html)
7 0.001698192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=165 Ack=662 Win=15936 Len=0
8 5.003870192.168.0.130 192.168.0.132 TCP  66   
  http  38035 [FIN, ACK] Seq=662 Ack=165 Win=15552 Len=0
9 5.042256192.168.0.132 192.168.0.130 TCP  66   
  38035  http [ACK] Seq=165 Ack=663 Win=15936 Len=0
   10 7.873829192.168.0.132 192.168.0.130 HTTP 273  
  OPTIONS /webdav HTTP/1.1 
   11 7.873866192.168.0.130 192.168.0.132 TCP  54   
  http  38035 [RST] Seq=663 Win=0 Len=0
   12 7.873872192.168.0.132 192.168.0.130 TCP  66   
  38035  http [FIN, ACK] Seq=372 Ack=663 Win=15936 Len=0 
   13 7.873881192.168.0.130 192.168.0.132 TCP  54   
  http  38035 [RST] Seq=663 Win=0 Len=0

  
  As you can see, packet 8 occurs around 5 second after the packet 7, and is a 
FIN from the server (5 seconds of inactivity).

  I spent almost 8 seconds typing username/password, and then at 7.8
  sec, the second request with the Authorization goes out... WITHOUT
  reopening the connection.

  Of course, the server is not happy with that and issues a RST, and
  subsequently Nautilus says that there is an error.

  
  To check that it is indeed the source of the bug, I bumped the keep-alive 
time-out in my Apache config to 30 seconds, and this time, all was fine (of 
course I typed the user/password in less than 30 secs).

  
  GUESSING:
  -
  With previous versions of Nautilus where you had to enter

[Desktop-packages] [Bug 1051726] [NEW] WebDav broken, Nautilus sends data on a closed TCP connection!

2012-09-16 Thread Zakhar
Public bug reported:

ENVIRONMENT:
-
Precise 64
Nautilus 3.4.2

$ uname -a  nautilus --version
Linux zakhar-desktop 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 
2012 x86_64 x86_64 x86_64 GNU/Linux
GNOME nautilus 3.4.2


WEBDAV:

I set up a local Apache WebDAV with standard options.
No SSL
Basic authentication (it is for local use)

When I instruct Nautilus to go to my WebDAV (dav://127.0.0.1/webdav/) I
get an error.

After a few hours of investigation, I discovered the bug: Nautilus sends
data to a closed TCP connection!


WHAT HAPPENS:
--
When you hit Enter after the address  (dav://127.0.0.1/webdav/), Nautilus 
issues a plain request to the server.
Then, of course, the server replies 401: Authorisation required.
Having this response, Nautilus shows the box where you can enter user/password.

... the trouble is... if it takes you more than 5 seconds to type the
password, the default keepalive of Apache being 5 seconds, the
connection will be closed.

Then, once you have entered both username and password, Nautilus re-
issues the same request with the Authorization header.

... but this is done on a closed connection!..


PROOF:
--
This is the Wireshark summary trace from a second PC (client is 192.168.0.132, 
server is 192.168.0.130)
No. TimeSourceDestination   Protocol Length 
Info
  1 0.00192.168.0.132 192.168.0.130 TCP  74 
38035  http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
  2 0.40192.168.0.130 192.168.0.132 TCP  74 
http  38035 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 
  3 0.000246192.168.0.132 192.168.0.130 TCP  66 
38035  http [ACK] Seq=1 Ack=1 Win=14656 Len=0
  4 0.000534192.168.0.132 192.168.0.130 HTTP 230
OPTIONS /webdav HTTP/1.1 
  5 0.000555192.168.0.130 192.168.0.132 TCP  66 
http  38035 [ACK] Seq=1 Ack=165 Win=15552 Len=0 
  6 0.001226192.168.0.130 192.168.0.132 HTTP 727
HTTP/1.1 401 Authorization Required  (text/html)
  7 0.001698192.168.0.132 192.168.0.130 TCP  66 
38035  http [ACK] Seq=165 Ack=662 Win=15936 Len=0
  8 5.003870192.168.0.130 192.168.0.132 TCP  66 
http  38035 [FIN, ACK] Seq=662 Ack=165 Win=15552 Len=0
  9 5.042256192.168.0.132 192.168.0.130 TCP  66 
38035  http [ACK] Seq=165 Ack=663 Win=15936 Len=0
 10 7.873829192.168.0.132 192.168.0.130 HTTP 273
OPTIONS /webdav HTTP/1.1 
 11 7.873866192.168.0.130 192.168.0.132 TCP  54 
http  38035 [RST] Seq=663 Win=0 Len=0
 12 7.873872192.168.0.132 192.168.0.130 TCP  66 
38035  http [FIN, ACK] Seq=372 Ack=663 Win=15936 Len=0 
 13 7.873881192.168.0.130 192.168.0.132 TCP  54 
http  38035 [RST] Seq=663 Win=0 Len=0


As you can see, packet 8 occurs around 5 second after the packet 7, and is a 
FIN from the server (5 seconds of inactivity).

I spent almost 8 seconds typing username/password, and then at 7.8 sec,
the second request with the Authorization goes out... WITHOUT reopening
the connection.

Of course, the server is not happy with that and issues a RST, and
subsequently Nautilus says that there is an error.


To check that it is indeed the source of the bug, I bumped the keep-alive 
time-out in my Apache config to 30 seconds, and this time, all was fine (of 
course I typed the user/password in less than 30 secs).


GUESSING:
-
With previous versions of Nautilus where you had to enter in a windows the 
address of the server, the protocol, the username and password... THEN hit 
enter, I imagine such things didn't show as it was 'fast enough' not to be in 
that situation.

Having removed this windows, the bug shows.

It is bad because my workaround (timeout to 30 secs) is hazardous.
In fact you can't really guess how much time would the user need to enter 
user/password. In case of strong and long pass phrases, and slow typing user, 
we could imagine over a minute... and we don't want to bump the keep-alive 
time-out on Apache that much for the sake of resource preservation.


WHAT IS EXPECTED:
--
Nautilus should not produce an error when connecting to a perfectly fine WebDAV 
server.
Basically, it shouldn't try sending data on a closed TCP connection... because 
obviously that does not work!

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1051726

Title:
  WebDav broken, Nautilus sends data on a closed TCP connection!

Status in “nautilus” package in Ubuntu:
  New

Bug description:
  ENVIRONMENT