[Desktop-packages] [Bug 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

as of this morning's updates, this problem seems to have disappeared.
I've been able to log out and back in several times to my ubuntu wayland
session, at least on my i915 machine (the dell laptop).

nb: this morning's updates updated gnome-session-bin and ubuntu-session
to 3.33.92-1ubuntu1, gdm3 to 3.33.92-2ubuntu1, but mutter and gnome-
shell remain at 3.33.91.. (Also and probably not
coincidentally seeing some unrelated dash-or-ubuntudock issues, but i'll
wait to see if they're resolved when gnome-shell goes up to 3.33.92
too.)

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

My point regarding gnome-session-wayland.target is that if we're seeing
different filenames for that file (assuming they're functionally the
same) and mine definitely comes from gnome-session-bin, does that
suggest we're running different gnome-session-bin versions? And seeing
as you're not reproducing an issue i'm seeing regarding the ending of a
gnome session... does that difference in what file you're expecting me
to have there and the file i *assure* you is actually there... signify
anything?

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

minor contextual note: It took me a little while to get the other
machine, ssh in (offending ssh key to resolve), call up this page to
remind me of the exact commands. The point of which is to say, these
weren't taken *immediately* after the logout, but at least a minute
later, certainly beyond that timeout discussed earlier. Also therefore
that that ssh session started *after* the hang event, didn't log in in
advance.

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

journalctl -b output as attached

loginctl as below:

rachel in ~ at rainbow
➜ loginctl
SESSION  UID USER   SEAT  TTY
  1 1000 rachel seat0 tty2
  3 1000 rachel   pts/0

2 sessions listed.

rachel in ~ at rainbow
➜ loginctl show-session 1
Id=1
User=1000
Name=rachel
Timestamp=Tue 2019-09-03 14:30:40 BST
TimestampMonotonic=20750725
VTNr=2
Seat=seat0
TTY=tty2
Remote=no
Service=gdm-autologin
Scope=session-1.scope
Leader=5228
Audit=1
Type=wayland
Class=user
Active=yes
State=closing
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
LockedHint=no

rachel in ~ at rainbow
➜ loginctl show-session 3
Id=3
User=1000
Name=rachel
Timestamp=Tue 2019-09-03 14:31:47 BST
TimestampMonotonic=87793987
VTNr=0
TTY=pts/0
Remote=yes
RemoteHost=192.168.1.109
Service=sshd
Scope=session-3.scope
Leader=7048
Audit=3
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1567517624629274
IdleSinceHintMonotonic=205041051
LockedHint=no


** Attachment added: "jctl.log"
   
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+attachment/5286446/+files/jctl.log

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

It is definitely /usr/lib/systemd/user-gnome-session-wayland.target.
dpkg -S on that file gives gnome-session-bin which is on version
3.33.90-2ubuntu2. dpkg -S on the .service file gives no match.

This problem didn't start on upgrade to the 5.2 kernels, which happened
a few weeks(?) earlier, but immediately when gnome 3.33 dropped.

will get the gdm debugging stuff... (had to spend some time in windows
doing that for which i'm paid ;-)

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

With --systemd removed as directed I still ended up stuck on a black
screen, except this time it had a flashing white text cursor in the top
left.

(BTW reboots occurred between each test, somewhat perforce...)

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session

[Rachel Greenham]

I tried (just now) deliberately leaving it longer than 30 seconds to
come back after a logout. In fact left it longer than 60 seconds.
Nothing happening. I wasn't logged in via ssh as well at the time (I
hadn't thought the systemd --user instance was related to the ssh
session before so presumably might be confusing matters) so there's
nothing more to report than that the screen remained resolutely black.

There is no /usr/lib/systemd/user/gnome-session-wayland.service file on
this system. There is a .target file though which is presumably the one.
As the presumably-default timeout didn't seem to be honoured here there
didn't seem a lot of point in adding a shorter one so I left the file
alone. I'll try the change to /usr/share/wayland-sessions/ubuntu-
wayland.desktop (the only file in that directory) and report back in the
next comment...

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome

[Rachel Greenham]

the i915 one (Dell XPS 13 9370) is the one with automatic login enabled.

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

Title:
  black screen, unresponsive, after logout from gnome Wayland session

Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome

[Rachel Greenham]

... and the other affected machine (just checked it's still affected
today after latest updates)

** Attachment added: "lspcik-dell.txt"
   
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+attachment/5286167/+files/lspcik-dell.txt

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

Title:
  black screen, unresponsive, after logout from gnome

Status in gdm3 package in Ubuntu:
  New
Status in gnome-shell package in Ubuntu:
  New

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome

[Rachel Greenham]

As attached.

** Attachment added: "lspcik.txt"
   
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+attachment/5286165/+files/lspcik.txt

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

Title:
  black screen, unresponsive, after logout from gnome

Status in gdm3 package in Ubuntu:
  New
Status in gnome-shell package in Ubuntu:
  New

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome

[Rachel Greenham]

Only affects Wayland sessions, not x11. I should have mentioned it
earlier, it's been my default for some time now (because #1827428 which
still affects latest 19.10) and I forgot.

It also seems not to be the upstream bug, unless the discussion there is
going off in the wrong directions. They now point the finger at systemd
in a bug tracked here: https://github.com/systemd/systemd/issues/13437 .
But I can't reproduce that vt-switching issue. (And our systemd is older
than any they're looking at.) I only have a problem at logout.

** Bug watch added: github.com/systemd/systemd/issues #13437
   https://github.com/systemd/systemd/issues/13437

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

Title:
  black screen, unresponsive, after logout from gnome

Status in gdm3 package in Ubuntu:
  New
Status in gnome-shell package in Ubuntu:
  New

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] [NEW] black screen, unresponsive, after logout from gnome

[Rachel Greenham]

Public bug reported:

on logout the screen is black, the system is unresponsive and has to be
restarted. (Untested by me yet, but I expect ssh-ing in and restarting
gdm would work.)

I believe this may be already reported upstream here:
https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
reported this against gdm3 even though I honestly don't know if it might
be a gnome-shell, gnome-session or mutter based error. (FWIW without the
upstream bug to link to I'd maybe suspect gnome-shell first.)

NB: This machine's conf has AutomaticLogin enabled, but another machine
also on 19.10 does not, and it's showing the same thing. On *this*
machine I found that the *first* time I logged out, it was OK, but not
the second time. On the other machine, it fails first time too. It's as
if the gdm login screen can appear exactly once. That (and being on
gnome 3.33) is why I don't think this is a dupe of #1824588.

Nothing appears in /var/crash as a result of this.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: gdm3 3.33.90-1ubuntu1
ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
Uname: Linux 5.2.0-13-generic x86_64
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Aug 29 10:51:22 2019
InstallationDate: Installed on 2018-09-11 (351 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
SourcePackage: gdm3
UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

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


** Tags: amd64 apport-bug eoan wayland-session

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

Title:
  black screen, unresponsive, after logout from gnome

Status in gdm3 package in Ubuntu:
  New

Bug description:
  on logout the screen is black, the system is unresponsive and has to
  be restarted. (Untested by me yet, but I expect ssh-ing in and
  restarting gdm would work.)

  I believe this may be already reported upstream here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've
  reported this against gdm3 even though I honestly don't know if it
  might be a gnome-shell, gnome-session or mutter based error. (FWIW
  without the upstream bug to link to I'd maybe suspect gnome-shell
  first.)

  NB: This machine's conf has AutomaticLogin enabled, but another
  machine also on 19.10 does not, and it's showing the same thing. On
  *this* machine I found that the *first* time I logged out, it was OK,
  but not the second time. On the other machine, it fails first time
  too. It's as if the gdm login screen can appear exactly once. That
  (and being on gnome 3.33) is why I don't think this is a dupe of
  #1824588.

  Nothing appears in /var/crash as a result of this.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gdm3 3.33.90-1ubuntu1
  ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8
  Uname: Linux 5.2.0-13-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 29 10:51:22 2019
  InstallationDate: Installed on 2018-09-11 (351 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago)
  mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1827428] Re: Mouse cursor left frozen copy of itself

[Rachel Greenham]

A bit more detail to reproduce this that I think was missed out before:

It happens when the configured desktop mode/scaling is set to a
fractional value. You can have that experimental xrandr setting set, but
be configured to scaling of 100% or 200% (but see below on latter) and
you won't see this problem. Set it to 150%, log out, log in again, you
should see it. That applies to my experience anyway on the AMD graphics
system.

NB: Today when I tried to confirm this, I found that it would ignore my
setting scaling to 200% on login, and would instead go in as if it was
100%, which would also be what it showed in the display settings
dialogue itself. I'm pretty sure that wasn't the case earlier. I am able
to select and use 200% in the session, it just won't be remembered. This
sounds like a separate problem though. The problem *here* is what
happens when scaling is set to a fractional value like 150% (which it
does seem to have no problem remembering).

It also means that a kind of workaround is to set scaling to 200% or
100% before logging out, then set it back to the 150% you want after
logging in again. The problem is only when you're logging in and the
setting is already fractional, so the switch in resolution happens
during login.

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

Title:
  Mouse cursor left frozen copy of itself

Status in mutter package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed

Bug description:
  Mouse cursor left freezed copy of itself over all the windows after
  login after lock screen. Functionality is not broken. It's just not
  aesthetic.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
  Uname: Linux 5.0.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.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  418.56  Fri Mar 15 12:59:26 
CDT 2019
   GCC version:  gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu May  2 16:10:09 2019
  DistUpgraded: Fresh install
  DistroCodename: disco
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 418.56, 5.0.0-13-generic, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA 
controller])
 Subsystem: Hewlett-Packard Company HD Graphics 630 [103c:8392]
   NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company GP107M [GeForce GTX 1050 Mobile] 
[103c:8392]
  InstallationDate: Installed on 2019-04-29 (2 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 8087:0a2a Intel Corp. 
   Bus 001 Device 003: ID 04f2:b593 Chicony Electronics Co., Ltd 
   Bus 001 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: HP OMEN by HP Laptop 17-an0xx
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic 
root=UUID=08661a81-0386-4b44-9d3e-17ad6fa2de96 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/21/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F.05
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: 8392
  dmi.board.vendor: HP
  dmi.board.version: 40.21
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF.05:bd06/21/2017:svnHP:pnOMENbyHPLaptop17-an0xx:pvr:rvnHP:rn8392:rvr40.21:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP OMEN
  dmi.product.name: OMEN by HP Laptop 17-an0xx
  dmi.product.sku: 2FP35EA#ACB
  dmi.sys.vendor: HP
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-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.4-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1
  

[Desktop-packages] [Bug 1827428] Re: [nvidia] Mouse cursor left frozen copy of itself

[Rachel Greenham]

My bug got marked a duplicate of this one but with the latest change
that might be wrong: It affected me on a machine with AMD graphics, not
nVidia. BTW I recently tried it again on the offchance it had been fixed
since (by re-enabling the xrandr scaling setting), and it had not. Also
not fixed on 19.10 (which tbh is barely advanced from 19.04 at this
stage).

On the flipside, a different machine with only Intel graphics (Dell XPS
9370) did *not* show this problem.

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

Title:
  [nvidia] Mouse cursor left frozen copy of itself

Status in mutter package in Ubuntu:
  Confirmed
Status in nvidia-graphics-drivers-418 package in Ubuntu:
  Confirmed

Bug description:
  Mouse cursor left freezed copy of itself over all the windows after
  login after lock screen. Functionality is not broken. It's just not
  aesthetic.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
  Uname: Linux 5.0.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.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  418.56  Fri Mar 15 12:59:26 
CDT 2019
   GCC version:  gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu May  2 16:10:09 2019
  DistUpgraded: Fresh install
  DistroCodename: disco
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 418.56, 5.0.0-13-generic, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA 
controller])
 Subsystem: Hewlett-Packard Company HD Graphics 630 [103c:8392]
   NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company GP107M [GeForce GTX 1050 Mobile] 
[103c:8392]
  InstallationDate: Installed on 2019-04-29 (2 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 8087:0a2a Intel Corp. 
   Bus 001 Device 003: ID 04f2:b593 Chicony Electronics Co., Ltd 
   Bus 001 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: HP OMEN by HP Laptop 17-an0xx
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic 
root=UUID=08661a81-0386-4b44-9d3e-17ad6fa2de96 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/21/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F.05
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: 8392
  dmi.board.vendor: HP
  dmi.board.version: 40.21
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF.05:bd06/21/2017:svnHP:pnOMENbyHPLaptop17-an0xx:pvr:rvnHP:rn8392:rvr40.21:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP OMEN
  dmi.product.name: OMEN by HP Laptop 17-an0xx
  dmi.product.sku: 2FP35EA#ACB
  dmi.sys.vendor: HP
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-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.4-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20180925-2
  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/ubuntu/+source/mutter/+bug/1827428/+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 1827099] Re: package shared-mime-info 1.10-1 failed to install/upgrade: triggers looping, abandoned

[Rachel Greenham]

ditto upgrading in two steps bionic->cosmic->disco

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

Title:
  package shared-mime-info 1.10-1 failed to install/upgrade: triggers
  looping, abandoned

Status in shared-mime-info package in Ubuntu:
  Confirmed

Bug description:
  Crash at the end of upgrade to 19.04

  ProblemType: Package
  DistroRelease: Ubuntu 19.04
  Package: shared-mime-info 1.10-1
  ProcVersionSignature: Ubuntu 4.18.0-18.19-generic 4.18.20
  Uname: Linux 4.18.0-18-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Tue Apr 30 21:07:35 2019
  ErrorMessage: triggers looping, abandoned
  InstallationDate: Installed on 2015-10-28 (1280 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 
3.6.7-1~18.10
  PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1
  RelatedPackageVersions:
   dpkg 1.19.6ubuntu1
   apt  1.8.0
  SourcePackage: shared-mime-info
  Title: package shared-mime-info 1.10-1 failed to install/upgrade: triggers 
looping, abandoned
  UpgradeStatus: Upgraded to disco on 2019-04-30 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1827099/+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 1829221] Re: second, dead, mouse pointer left on screen after login, x11 session

[Rachel Greenham]

It does appear to be related to the xrandr scaling experimental feature,
after all. Revert that to default and the issue disappears. Guessing
that probably makes it a mutter bug, and being of an experimental
feature at that is hopefully of interest to someone but not urgent. In
view of that didn't test switching pointing device.

** Also affects: mutter (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/1829221

Title:
  second, dead, mouse pointer left on screen after login, x11 session

Status in gnome-session package in Ubuntu:
  New
Status in mutter package in Ubuntu:
  New

Bug description:
  This seems to have become repeatable, and applies even on the first
  login session immediately after booting the computer. I don't know if
  this is the right package to report against; another possible culprit:
  gdm:

  When I log into the default "Ubuntu" session (ie: on xorg), gdm's
  mouse pointer remains on screen during the screen blank, and after the
  gnome desktop comes up. It stays on the top just like you'd expect of
  the mouse pointer, but it's immobile and unresponsive. It's left at
  the same position on the screen that it was while using gdm, and is
  the same size as it was in gdm (ie: gdm is not scaled, but gnome
  session desktop scaled to 150% - the *working* in-session mouse
  pointer is also 150% larger than gdm's dead one).

  It looks like gdm and gnome are running in the same x11 session?
  Seeing as the mouse pointer stays solid *during* the transition from
  gdm into the gnome desktop. Not even a flicker. It's almost as if
  we're trying to have smooth transitions for these sorts of things,
  which is good of course, but maybe is a bug in that?

  It disappears when I log into a Wayland session, it appears only to
  affect x11 sessions.

  I've taken to just moving the mouse pointer to the far bottom right
  corner of the screen before logging in, so at least it's not very
  intrusive.

  There are a few reports of similar in askubuntu from a few years back,
  but with no helpful or applicable solution. eg:

  
https://askubuntu.com/questions/521241/i-have-two-cursors-on-my-screen-one-of-which-is-always-on-top-and-will-never-mo
  
https://askubuntu.com/questions/598096/14-04-second-mouse-pointer-stuck-in-middle-of-the-screen

  To answer the points made there, the xinput --list output is shown
  below. Executing that command and rebooting makes no difference. In
  the Displays Prefs there is no second "Unknown" display to disable.
  (The machine has precisely one display, and that's all Settings sees.
  It's a desktop, not a laptop, and it only has an AMD Vega integrated
  graphics. It also has only one mouse.)

  rachel@twilight:~$ xinput --list
  ⎡ Virtual core pointerid=2[master pointer  (3)]
  ⎜   ↳ Virtual core XTEST pointer  id=4[slave  pointer 
 (2)]
  ⎜   ↳ HID 04b4:3003 Mouse id=9[slave  pointer 
 (2)]
  ⎜   ↳ HID 04b4:3003 Consumer Control  id=11   [slave  pointer 
 (2)]
  ⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Mouseid=15   [slave  
pointer  (2)]
  ⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control id=16   
[slave  pointer  (2)]
  ⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control id=17   
[slave  pointer  (2)]
  ⎣ Virtual core keyboard   id=3[master keyboard (2)]
  ↳ Virtual core XTEST keyboard id=5[slave  
keyboard (3)]
  ↳ Power Buttonid=6[slave  
keyboard (3)]
  ↳ Power Buttonid=7[slave  
keyboard (3)]
  ↳ HID 04b4:3003   id=8[slave  
keyboard (3)]
  ↳ HID 04b4:3003 System Controlid=10   [slave  
keyboard (3)]
  ↳ HID 04b4:3003 Keyboard  id=12   [slave  
keyboard (3)]
  ↳ Dell Dell AC511 USB SoundBarid=13   [slave  
keyboard (3)]
  ↳ Microsoft Microsoft® Nano Transceiver v1.0  id=14   [slave  
keyboard (3)]
  ↳ Microsoft Microsoft® Nano Transceiver v1.0 System Control   id=18   
[slave  keyboard (3)]
  ↳ Eee PC WMI hotkeys  id=19   [slave  
keyboard (3)]
  ↳ HID 04b4:3003 Consumer Control  id=20   [slave  
keyboard (3)]
  ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control id=21   
[slave  keyboard (3)]
  ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control id=22   
[slave  keyboard (3)]

  (I don't know what's with the duplicated MS Nano Transceiver Consumer
  Control entries)

  I thought of a couple of things to try after starting to write this
  ticket but didn't want to lose the ticket in 

[Desktop-packages] [Bug 1829221] [NEW] second, dead, mouse pointer left on screen after login, x11 session

[Rachel Greenham]

Public bug reported:

This seems to have become repeatable, and applies even on the first
login session immediately after booting the computer. I don't know if
this is the right package to report against; another possible culprit:
gdm:

When I log into the default "Ubuntu" session (ie: on xorg), gdm's mouse
pointer remains on screen during the screen blank, and after the gnome
desktop comes up. It stays on the top just like you'd expect of the
mouse pointer, but it's immobile and unresponsive. It's left at the same
position on the screen that it was while using gdm, and is the same size
as it was in gdm (ie: gdm is not scaled, but gnome session desktop
scaled to 150% - the *working* in-session mouse pointer is also 150%
larger than gdm's dead one).

It looks like gdm and gnome are running in the same x11 session? Seeing
as the mouse pointer stays solid *during* the transition from gdm into
the gnome desktop. Not even a flicker. It's almost as if we're trying to
have smooth transitions for these sorts of things, which is good of
course, but maybe is a bug in that?

It disappears when I log into a Wayland session, it appears only to
affect x11 sessions.

I've taken to just moving the mouse pointer to the far bottom right
corner of the screen before logging in, so at least it's not very
intrusive.

There are a few reports of similar in askubuntu from a few years back,
but with no helpful or applicable solution. eg:

https://askubuntu.com/questions/521241/i-have-two-cursors-on-my-screen-one-of-which-is-always-on-top-and-will-never-mo
https://askubuntu.com/questions/598096/14-04-second-mouse-pointer-stuck-in-middle-of-the-screen

To answer the points made there, the xinput --list output is shown
below. Executing that command and rebooting makes no difference. In the
Displays Prefs there is no second "Unknown" display to disable. (The
machine has precisely one display, and that's all Settings sees. It's a
desktop, not a laptop, and it only has an AMD Vega integrated graphics.
It also has only one mouse.)

rachel@twilight:~$ xinput --list
⎡ Virtual core pointer  id=2[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointerid=4[slave  pointer  (2)]
⎜   ↳ HID 04b4:3003 Mouse   id=9[slave  pointer  (2)]
⎜   ↳ HID 04b4:3003 Consumer Controlid=11   [slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Mouse  id=15   [slave  pointer 
 (2)]
⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control   id=16   
[slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control   id=17   
[slave  pointer  (2)]
⎣ Virtual core keyboard id=3[master keyboard (2)]
↳ Virtual core XTEST keyboard   id=5[slave  keyboard (3)]
↳ Power Button  id=6[slave  keyboard (3)]
↳ Power Button  id=7[slave  keyboard (3)]
↳ HID 04b4:3003 id=8[slave  keyboard (3)]
↳ HID 04b4:3003 System Control  id=10   [slave  keyboard (3)]
↳ HID 04b4:3003 Keyboardid=12   [slave  keyboard (3)]
↳ Dell Dell AC511 USB SoundBar  id=13   [slave  keyboard (3)]
↳ Microsoft Microsoft® Nano Transceiver v1.0id=14   [slave  
keyboard (3)]
↳ Microsoft Microsoft® Nano Transceiver v1.0 System Control id=18   [slave  
keyboard (3)]
↳ Eee PC WMI hotkeysid=19   [slave  keyboard (3)]
↳ HID 04b4:3003 Consumer Controlid=20   [slave  keyboard (3)]
↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control   id=21   
[slave  keyboard (3)]
↳ Microsoft Microsoft® Nano Transceiver v1.0 Consumer Control   id=22   
[slave  keyboard (3)]

(I don't know what's with the duplicated MS Nano Transceiver Consumer
Control entries)

I thought of a couple of things to try after starting to write this
ticket but didn't want to lose the ticket in progress, so will add
comments if they show up anything. In particular, I am running the
experimental feature to enable xrandr fractional scaling. This issue
didn't show up right after enabling that, only a couple of days later,
so it didn't seem immediately relevant.

Also, trying with a different pointing device attached in case that
transceiver is doing something odd. (never had problems before, had it
years, no idea if that doubling-up has always been there.)

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: ubuntu-session 3.32.0-1ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6
Uname: Linux 5.0.0-15-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed May 15 11:38:19 2019
InstallationDate: Installed on 2019-05-11 (3 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
PackageArchitecture: all
SourcePackage: gnome-session
UpgradeStatus: 

[Desktop-packages] [Bug 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

i didn't freshly install to see it but i did create a new user, to be
sure I had utterly default settings and yes, it's there right from the
get-go with certain apps including terminal. but only in x11 (which of
course *is* still the default in ubuntu). I switched to wayland and this
problem went away. The remaining issues in wayland have proved
insufficient to push me back to x11, so I've been able to stop caring
about this. :-)

I guess people just aren't testing for x11 thoroughly any more.

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1818517] Re: "Network Login" browser does not remember cookies

[Rachel Greenham]

trying to get that screenshot was how i discovered it *does* appear to
be retaining stuff for a while at least. :-) I'll try to do so next time
I'm there.

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

Title:
  "Network Login" browser does not remember cookies

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  This is with respect to the gnome-shell-portal-helper, part of the
  gnome-shell package, which opens its own browser window to prompt for
  a wifi hotspot login. It all works fine except one little papercut:

  Could it remember cookies? So when I go back to the same hotspot most
  days I don't have to click OK to accept cookies every time before I
  can actually click to go online.

  It's possible I suppose they don't all use cookies. The hotspot in
  question is a BT wifi hotspot, so probably quite common in GB anyway.

  Desired behaviour, hate to say, is like Windows: It actually
  remembered my choice from before and just logged me in right away.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Mar  4 14:05:46 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (173 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+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 1818517] Re: "Network Login" browser does not remember cookies

[Rachel Greenham]

actually i think cookies are being held for at least a while, as,
sitting in the cafe, I can log out and in, and even reboot, and get
logged directly back into the hotspot. But when I come back the next day
I'm asked if I even want to accept cookies. It's that being asked to
accept cookies every day [that I go there] that annoys me, not whether
or not it actually logs me in or i have to click on a button to connect.
But in Windows, for instance, it remembered me even though I hadn't
booted up windows at the cafe for *months*. so i'm guessing there is
cookie retention going on, but on a rather short timeout.

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

Title:
  "Network Login" browser does not remember cookies

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  This is with respect to the gnome-shell-portal-helper, part of the
  gnome-shell package, which opens its own browser window to prompt for
  a wifi hotspot login. It all works fine except one little papercut:

  Could it remember cookies? So when I go back to the same hotspot most
  days I don't have to click OK to accept cookies every time before I
  can actually click to go online.

  It's possible I suppose they don't all use cookies. The hotspot in
  question is a BT wifi hotspot, so probably quite common in GB anyway.

  Desired behaviour, hate to say, is like Windows: It actually
  remembered my choice from before and just logged me in right away.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Mar  4 14:05:46 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (173 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+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 1818517] Re: "Network Login" browser does not remember cookies

[Rachel Greenham]

i mean literally http web cookies from the portal page. if you ignore
the network login app (as was the case before it worked reliably), it
shows up in your normal browser. This does remember cookies, so you
don't get asked if you want to accept cookies every time you go there.

What the portal does when it's presented with the cookie it gave you on
your last visit is, i think, a matter for the portal. My guess is that
it's probably *it* that would auto-connect you under whatever
circumstances it sees fit. Otherwise you just get the normal "Click to
connect" button.

I think *all* this needs is the support for, and storage of, HTTP
cookies from the portal, in whatever's providing the browser window
component of the Network Login app. My talk of auto-login stuff was just
confusing the matter, ignore it. :-)

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

Title:
  "Network Login" browser does not remember cookies

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  This is with respect to the gnome-shell-portal-helper, part of the
  gnome-shell package, which opens its own browser window to prompt for
  a wifi hotspot login. It all works fine except one little papercut:

  Could it remember cookies? So when I go back to the same hotspot most
  days I don't have to click OK to accept cookies every time before I
  can actually click to go online.

  It's possible I suppose they don't all use cookies. The hotspot in
  question is a BT wifi hotspot, so probably quite common in GB anyway.

  Desired behaviour, hate to say, is like Windows: It actually
  remembered my choice from before and just logged me in right away.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Mar  4 14:05:46 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (173 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+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 1818517] [NEW] "Network Login" browser does not remember cookies

[Rachel Greenham]

Public bug reported:

This is with respect to the gnome-shell-portal-helper, part of the
gnome-shell package, which opens its own browser window to prompt for a
wifi hotspot login. It all works fine except one little papercut:

Could it remember cookies? So when I go back to the same hotspot most
days I don't have to click OK to accept cookies every time before I can
actually click to go online.

It's possible I suppose they don't all use cookies. The hotspot in
question is a BT wifi hotspot, so probably quite common in GB anyway.

Desired behaviour, hate to say, is like Windows: It actually remembered
my choice from before and just logged me in right away.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gnome-shell 3.31.90-1ubuntu1
ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
Uname: Linux 4.19.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Mar  4 14:05:46 2019
DisplayManager: gdm3
InstallationDate: Installed on 2018-09-11 (173 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago)

** Affects: gnome-shell (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco package-from-proposed wayland-session

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

Title:
  "Network Login" browser does not remember cookies

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  This is with respect to the gnome-shell-portal-helper, part of the
  gnome-shell package, which opens its own browser window to prompt for
  a wifi hotspot login. It all works fine except one little papercut:

  Could it remember cookies? So when I go back to the same hotspot most
  days I don't have to click OK to accept cookies every time before I
  can actually click to go online.

  It's possible I suppose they don't all use cookies. The hotspot in
  question is a BT wifi hotspot, so probably quite common in GB anyway.

  Desired behaviour, hate to say, is like Windows: It actually
  remembered my choice from before and just logged me in right away.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Mar  4 14:05:46 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (173 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1818517/+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 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

Bug only affects X11 sessions.

I had a random urge to try out Wayland again. This issue does not arise
in Wayland. Apps that were affected under X11 are taking input focus
quite happily when launched from shell in Wayland.

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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

Re: [Desktop-packages] [Bug 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

it's not generally slow enough for the latter to be an issue. :-) Even 
if I just go nice and slow. Click... window opens... it doesn't have 
focus... It continues to not have focus until I do something that would 
give it focus in the normal fashion, like clicking on it, clicking on 
its dock icon now it's running, alt-tabbing to it...

Is this not happening for you in launching gnome-terminal? It's same for 
me whether from dock, from app grid, from app grid's search field. 
*Sometimes* it's been slow enough that I think I've seen the window have 
focus for a tiny moment (the close-window icon in the titlebar is orange 
for a moment) then it gets taken away. Usually it's too fast to see that 
happen. BTW I've also tried it with *all* extensions removed, including 
ubuntu-dock and appindicators and desktop-icons, by removing their 
packages. No difference.

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

confirmed, gedit seems to be immune for some reason. pretty much
anything else i tried is not; calculator, terminal, libreoffice,
nautilus...

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

sublime text, slack also immune, firefox, thunderbird are not... so ok
it's not universal but *lots* of apps are affected, and the pattern
doesn't seem to be gnome/not-gnome.

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

FYI problem remains with all those extensions removed.

BTW one does tend to notice it most with apps you type into. I first
noticed with terminal, where I'm used to click, then start typing, and
it's suddenly become click, click-again, then start typing. With an app
you'd tend first to click into anyway, you're more likely to not notice
it as the first click in an unfocused window is passed in.

(Along the way, minor invisible-to-user bug in that the setting
org.gnome.shell.enabled-extensions retains entries for extensions that
have been removed. Noticed first because I already didn't have dash-to-
dock installed, but did until recently - when without -proposed enabled,
the ubuntu dock extension stopped working (works again with -proposed
enabled, i think the latest non-proposed version of ubuntu-dock secretly
depends on the proposed gnome shell). Confirmed as all those listed
extensions remained in that setting after removing all of them. I've
just reset it to default value, empty array.)

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1817924] Re: apps launched from gnome shell do not get input focus

[Rachel Greenham]

NB: If you launch an app from a terminal, eg: gnome-calculator, it
*does* then get the input focus; just not when launched from gnome-
shell. That's why I didn't think it was a mutter bug.

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1817924] [NEW] apps launched from gnome shell do not get input focus

[Rachel Greenham]

Public bug reported:

Observed on upgrading to disco-proposed today...

When launching an app from the dock or from the applications grid (so i
believe it's a gnome-shell thing rather than a dock thing), the app
opens, but does not get the input focus. You have to either click in the
window, or clicking again on the icon of the running app in the dock
works, to give it focus. An extra step my muscle memory isn't prepared
for!

It seems like the sort of thing that might be an option rather than a
bug, but if so, changing this behaviour back to its previous default is
not at all obvious (I haven't found a way). So guessing it is a bug. NB:
After launching an app this way, *no* window has focus. It is lost by
the app that had it before, but not given to the newly started app.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gnome-shell 3.31.90-1ubuntu1
ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
Uname: Linux 4.19.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 27 15:53:07 2019
DisplayManager: gdm3
InstallationDate: Installed on 2018-09-11 (169 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

** Affects: gnome-shell (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco package-from-proposed

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

Title:
  apps launched from gnome shell do not get input focus

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  Observed on upgrading to disco-proposed today...

  When launching an app from the dock or from the applications grid (so
  i believe it's a gnome-shell thing rather than a dock thing), the app
  opens, but does not get the input focus. You have to either click in
  the window, or clicking again on the icon of the running app in the
  dock works, to give it focus. An extra step my muscle memory isn't
  prepared for!

  It seems like the sort of thing that might be an option rather than a
  bug, but if so, changing this behaviour back to its previous default
  is not at all obvious (I haven't found a way). So guessing it is a
  bug. NB: After launching an app this way, *no* window has focus. It is
  lost by the app that had it before, but not given to the newly started
  app.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: gnome-shell 3.31.90-1ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 27 15:53:07 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2018-09-11 (169 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to disco on 2019-01-13 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1817924/+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 1814262] Re: Wired interface gets impossibly high metric 20100

[Rachel Greenham]

Follow up comment on the upstream bug pointed to a commit where it
suggests the rp_filter default should actually now be 2 rather than 1:
https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e

Think at this point I need to just let you guys talk amongst yourself.
:-) For me, my fix for now is to uninstall the connectivity-check
package, which disables the functionality. I'm not going to mess about
changing procps defaults.

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

Title:
  Wired interface gets impossibly high metric 20100

Status in network-manager package in Ubuntu:
  New

Bug description:
  Actually this might be a heisenbug. I've had an issue with this all
  morning since network-manager got an update this morning, but just now
  *while this bug was being submitted* it decided to correct itself.

  What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
  a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
  network-manager update I noticed everything was slower than I was used
  to, and in gnome-shell the network icon showing was the WiFi one, not
  the wired one.

  Looking at the output of route, or route -n for simplicity, I would
  see this:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG60000 wlp2s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20100  00 
enp63s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So the metric on the default route on enp63s0 had 20,000 mysteriously
  added to it, which would obviously make it extremely low-priority. The
  system was choosing the wifi connection instead, which isn't that
  great in my office, hence observable slowness.

  Now, this morning, this seemed to be the sticky situation. It didn't
  show any sign of changing, whatever I did, after restarts of network-
  manager, undock/redock, reboots, etc. I could change it manually with
  ifmetric (and it would work), but that was about it.

  I would have reported the bug then, but I had to go out. When I got
  back I plugged in and initially saw the same thing again (that's where
  the above snippet was pasted from). But *while* the ubuntu-bug
  network-manager command was running, I noticed the gnome-shell network
  icon switch to wired, checked again, and saw:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG10000 
enp63s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20600  00 wlp2s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So now the wifi connection has 20,000 added to it, which may still be
  wrong? But I wouldn't otherwise have noticed it because the system is
  again *behaving* as expected.

  This all seemed to happen after the network-manager upgrade (from
  1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
  metric+20,000 values were present before then, because I didn't have
  any cause to go looking at it, it always just worked. Could it be some
  issue with how the newer network-manager, or one of its associated
  packages, is figuring out the metrics on new connections? Like it's
  running some new heuristic to determine which one should really be the
  preferred? If it's like it was just now, when it fixed itself after a
  minute or so, that's not really a problem, but if it's like it was
  this morning when it just seemed to be stuck with the ethernet
  connection at 20100, it is.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: network-manager 1.15.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu19
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Feb  1 13:15:06 2019
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2018-09-11 (142 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  IpRoute:
   default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 
   default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 
   169.254.0.0/16 dev wlp2s0 scope link metric 1000 
   192.168.1.0/24 

[Desktop-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100

[Rachel Greenham]

Reporting back on this:

The opinion there seems to be that the problem is down to the sys
net.ipv4.conf.*.rp_filter values being set to 1 instead of defaulting to
0. This is done in the procps package, and I'm guessing is the way it is
as a protection against IP spoofing. kernel doc page I was pointed to
says:

Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.

The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.

Default value is 0. Note that some distributions enable it
in startup scripts.

Presumably Ubuntu enables by default (I can see it does, in a file in
the procps package) and Red Hat, where it seems the NetworkManager
maintainers sit, does not.

This is going to have to be argued out between procps and network-
manager maintainers I guess. You can have IP spoofing protection or you
can have connectivity checking. Choose one, or argue who should fix it.
:-) Personally, at least for now, my solution is to remove the
connectivity-check package, which was presumably brought in by
something, and keep the procps defaults.

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

Title:
  Wired interface gets impossibly high metric 20100

Status in network-manager package in Ubuntu:
  New

Bug description:
  Actually this might be a heisenbug. I've had an issue with this all
  morning since network-manager got an update this morning, but just now
  *while this bug was being submitted* it decided to correct itself.

  What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
  a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
  network-manager update I noticed everything was slower than I was used
  to, and in gnome-shell the network icon showing was the WiFi one, not
  the wired one.

  Looking at the output of route, or route -n for simplicity, I would
  see this:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG60000 wlp2s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20100  00 
enp63s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So the metric on the default route on enp63s0 had 20,000 mysteriously
  added to it, which would obviously make it extremely low-priority. The
  system was choosing the wifi connection instead, which isn't that
  great in my office, hence observable slowness.

  Now, this morning, this seemed to be the sticky situation. It didn't
  show any sign of changing, whatever I did, after restarts of network-
  manager, undock/redock, reboots, etc. I could change it manually with
  ifmetric (and it would work), but that was about it.

  I would have reported the bug then, but I had to go out. When I got
  back I plugged in and initially saw the same thing again (that's where
  the above snippet was pasted from). But *while* the ubuntu-bug
  network-manager command was running, I noticed the gnome-shell network
  icon switch to wired, checked again, and saw:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG10000 
enp63s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20600  00 wlp2s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So now the wifi connection has 20,000 added to it, which may still be
  wrong? But I wouldn't otherwise have noticed it because the system is
  again *behaving* as expected.

  This all seemed to happen after the network-manager upgrade (from
  1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
  metric+20,000 values were present before then, because I didn't have
  any cause to go looking at it, it always just worked. Could it be some
  issue with how the newer network-manager, or one of its associated
  packages, is figuring out the metrics on new connections? Like it's
  running some new heuristic to determine which one should really be the
  preferred? If it's like it was just now, when it fixed itself after a
  minute or so, that's not really a problem, but if it's like it was
  this morning when it 

[Desktop-packages] [Bug 1815036] [NEW] uri defined for connectivity check does not have IPv6 address

[Rachel Greenham]

Public bug reported:

As per subject. This package defines the file
/usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf, which
defines the uri for the connectivity check to be http://connectivity-
check.ubuntu.com

This hostname does not resolve to an IPv6 address. Therefore, even if
the user has fully working IPv6, the connectivity check for IPv6 will
fail. As a result, the IPv6 default routes will be heavily deprioritised
(ie: having 2 added to the metric) rendering them effectively
inoperable absent a deliberate effort to use IPv6-only addresses.

NB: This was discovered by-the-by during reporting of bug #1814262
upstream at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116#note_114448

It seems to be irrelevant to the main thrust of that bug, which is that
IPv4 wired routes are not being identified as working correctly. In
fact, when I switch to network-manager-config-connectivity-debian, the
hostname defined there *does* have a working IPv6 address, and the issue
actually being reported in that other bug does not affect the IPv6
routes, only the IPv4 ones.

The bug here probably doesn't need any change made to the package
itself, but rather to the networking of the actual target URL. It needs
an IPv6 () DNS record, and for it to function on that address.

I note in passing the debian connectivity check URL resolves to several
IP addresses - four IPv4 addresses and 3 IPv6 addresses, presumably
geographically diverse. (It's actually a CNAME to static.debian.org)
This looks like it would be a more reliable target for connectivity
checks. The ubuntu URL only resolves to a single IPv4 address.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: network-manager-config-connectivity-ubuntu 1.15.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
Uname: Linux 4.19.0-12-generic x86_64
ApportVersion: 2.20.10-0ubuntu20
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Feb  7 12:35:24 2019
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2018-09-11 (148 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
IpRoute:
 default via 192.168.1.254 dev enp63s0 proto dhcp metric 100 
 default via 192.168.1.254 dev wlp2s0 proto dhcp metric 20600 
 169.254.0.0/16 dev wlp2s0 scope link metric 1000 
 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 
100 
 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
PackageArchitecture: all
SourcePackage: network-manager
UpgradeStatus: Upgraded to disco on 2019-01-13 (24 days ago)
nmcli-nm:
 RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  WIFI  
   WWAN-HW  WWAN
 running  1.15.2   connected  started  full  enabled enabled  
enabled  enabled  enabled

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

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

Title:
  uri defined for connectivity check does not have IPv6 address

Status in network-manager package in Ubuntu:
  New

Bug description:
  As per subject. This package defines the file
  /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf, which
  defines the uri for the connectivity check to be http://connectivity-
  check.ubuntu.com

  This hostname does not resolve to an IPv6 address. Therefore, even if
  the user has fully working IPv6, the connectivity check for IPv6 will
  fail. As a result, the IPv6 default routes will be heavily
  deprioritised (ie: having 2 added to the metric) rendering them
  effectively inoperable absent a deliberate effort to use IPv6-only
  addresses.

  NB: This was discovered by-the-by during reporting of bug #1814262
  upstream at
  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116#note_114448

  It seems to be irrelevant to the main thrust of that bug, which is
  that IPv4 wired routes are not being identified as working correctly.
  In fact, when I switch to network-manager-config-connectivity-debian,
  the hostname defined there *does* have a working IPv6 address, and the
  issue actually being reported in that other bug does not affect the
  IPv6 routes, only the IPv4 ones.

  The bug here probably doesn't need any change made to the package
  itself, but rather to the networking of the actual target URL. It
  needs an IPv6 () DNS record, and for it to function on that
  address.

  I note in passing the debian connectivity check URL resolves to
  several IP addresses - four IPv4 addresses and 3 IPv6 addresses,
  presumably geographically diverse. (It's actually a CNAME to
  static.debian.org) This looks 

[Desktop-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100

[Rachel Greenham]

As it recurred again today and showed no signs of correcting itself like
it did on Friday, I went ahead and reported it upstream, here:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116

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

Title:
  Wired interface gets impossibly high metric 20100

Status in network-manager package in Ubuntu:
  New

Bug description:
  Actually this might be a heisenbug. I've had an issue with this all
  morning since network-manager got an update this morning, but just now
  *while this bug was being submitted* it decided to correct itself.

  What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
  a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
  network-manager update I noticed everything was slower than I was used
  to, and in gnome-shell the network icon showing was the WiFi one, not
  the wired one.

  Looking at the output of route, or route -n for simplicity, I would
  see this:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG60000 wlp2s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20100  00 
enp63s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So the metric on the default route on enp63s0 had 20,000 mysteriously
  added to it, which would obviously make it extremely low-priority. The
  system was choosing the wifi connection instead, which isn't that
  great in my office, hence observable slowness.

  Now, this morning, this seemed to be the sticky situation. It didn't
  show any sign of changing, whatever I did, after restarts of network-
  manager, undock/redock, reboots, etc. I could change it manually with
  ifmetric (and it would work), but that was about it.

  I would have reported the bug then, but I had to go out. When I got
  back I plugged in and initially saw the same thing again (that's where
  the above snippet was pasted from). But *while* the ubuntu-bug
  network-manager command was running, I noticed the gnome-shell network
  icon switch to wired, checked again, and saw:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG10000 
enp63s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20600  00 wlp2s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So now the wifi connection has 20,000 added to it, which may still be
  wrong? But I wouldn't otherwise have noticed it because the system is
  again *behaving* as expected.

  This all seemed to happen after the network-manager upgrade (from
  1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
  metric+20,000 values were present before then, because I didn't have
  any cause to go looking at it, it always just worked. Could it be some
  issue with how the newer network-manager, or one of its associated
  packages, is figuring out the metrics on new connections? Like it's
  running some new heuristic to determine which one should really be the
  preferred? If it's like it was just now, when it fixed itself after a
  minute or so, that's not really a problem, but if it's like it was
  this morning when it just seemed to be stuck with the ethernet
  connection at 20100, it is.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: network-manager 1.15.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu19
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Feb  1 13:15:06 2019
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2018-09-11 (142 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  IpRoute:
   default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 
   default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 
   169.254.0.0/16 dev wlp2s0 scope link metric 1000 
   192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 
100 
   192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 
600
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   

Re: [Desktop-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100

[Rachel Greenham]

Noted. I see there's no report of anything similar already, and if it 
was the sort of problem it looked like to me, people would be screaming 
blue murder about it, so I think I'll wait and see if it recurs or 
becomes an ongoing problem, rather than a one-off. Maybe my LAN was 
having a bad hair day...

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

Title:
  Wired interface gets impossibly high metric 20100

Status in network-manager package in Ubuntu:
  New

Bug description:
  Actually this might be a heisenbug. I've had an issue with this all
  morning since network-manager got an update this morning, but just now
  *while this bug was being submitted* it decided to correct itself.

  What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
  a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
  network-manager update I noticed everything was slower than I was used
  to, and in gnome-shell the network icon showing was the WiFi one, not
  the wired one.

  Looking at the output of route, or route -n for simplicity, I would
  see this:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG60000 wlp2s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20100  00 
enp63s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So the metric on the default route on enp63s0 had 20,000 mysteriously
  added to it, which would obviously make it extremely low-priority. The
  system was choosing the wifi connection instead, which isn't that
  great in my office, hence observable slowness.

  Now, this morning, this seemed to be the sticky situation. It didn't
  show any sign of changing, whatever I did, after restarts of network-
  manager, undock/redock, reboots, etc. I could change it manually with
  ifmetric (and it would work), but that was about it.

  I would have reported the bug then, but I had to go out. When I got
  back I plugged in and initially saw the same thing again (that's where
  the above snippet was pasted from). But *while* the ubuntu-bug
  network-manager command was running, I noticed the gnome-shell network
  icon switch to wired, checked again, and saw:

  rachel@rainbow:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 192.168.1.254   0.0.0.0 UG10000 
enp63s0
  0.0.0.0 192.168.1.254   0.0.0.0 UG20600  00 wlp2s0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 10000 
enp63s0
  192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

  So now the wifi connection has 20,000 added to it, which may still be
  wrong? But I wouldn't otherwise have noticed it because the system is
  again *behaving* as expected.

  This all seemed to happen after the network-manager upgrade (from
  1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
  metric+20,000 values were present before then, because I didn't have
  any cause to go looking at it, it always just worked. Could it be some
  issue with how the newer network-manager, or one of its associated
  packages, is figuring out the metrics on new connections? Like it's
  running some new heuristic to determine which one should really be the
  preferred? If it's like it was just now, when it fixed itself after a
  minute or so, that's not really a problem, but if it's like it was
  this morning when it just seemed to be stuck with the ethernet
  connection at 20100, it is.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: network-manager 1.15.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu19
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Feb  1 13:15:06 2019
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2018-09-11 (142 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  IpRoute:
   default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 
   default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 
   169.254.0.0/16 dev wlp2s0 scope link metric 1000 
   192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 
100 
   192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 
600
  

[Desktop-packages] [Bug 1814262] [NEW] Wired interface gets impossibly high metric 20100

[Rachel Greenham]

Public bug reported:

Actually this might be a heisenbug. I've had an issue with this all
morning since network-manager got an update this morning, but just now
*while this bug was being submitted* it decided to correct itself.

What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a
(Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-
manager update I noticed everything was slower than I was used to, and
in gnome-shell the network icon showing was the WiFi one, not the wired
one.

Looking at the output of route, or route -n for simplicity, I would see
this:

rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.1.254   0.0.0.0 UG60000 wlp2s0
0.0.0.0 192.168.1.254   0.0.0.0 UG20100  00 enp63s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0   U 10000 enp63s0
192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

So the metric on the default route on enp63s0 had 20,000 mysteriously
added to it, which would obviously make it extremely low-priority. The
system was choosing the wifi connection instead, which isn't that great
in my office, hence observable slowness.

Now, this morning, this seemed to be the sticky situation. It didn't
show any sign of changing, whatever I did, after restarts of network-
manager, undock/redock, reboots, etc. I could change it manually with
ifmetric (and it would work), but that was about it.

I would have reported the bug then, but I had to go out. When I got back
I plugged in and initially saw the same thing again (that's where the
above snippet was pasted from). But *while* the ubuntu-bug network-
manager command was running, I noticed the gnome-shell network icon
switch to wired, checked again, and saw:

rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.1.254   0.0.0.0 UG10000 enp63s0
0.0.0.0 192.168.1.254   0.0.0.0 UG20600  00 wlp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0   U 10000 enp63s0
192.168.1.0 0.0.0.0 255.255.255.0   U 60000 wlp2s0

So now the wifi connection has 20,000 added to it, which may still be
wrong? But I wouldn't otherwise have noticed it because the system is
again *behaving* as expected.

This all seemed to happen after the network-manager upgrade (from
1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
metric+20,000 values were present before then, because I didn't have any
cause to go looking at it, it always just worked. Could it be some issue
with how the newer network-manager, or one of its associated packages,
is figuring out the metrics on new connections? Like it's running some
new heuristic to determine which one should really be the preferred? If
it's like it was just now, when it fixed itself after a minute or so,
that's not really a problem, but if it's like it was this morning when
it just seemed to be stuck with the ethernet connection at 20100, it is.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: network-manager 1.15.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu19
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Feb  1 13:15:06 2019
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2018-09-11 (142 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
IpRoute:
 default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 
 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 
 169.254.0.0/16 dev wlp2s0 scope link metric 1000 
 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 
100 
 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
RfKill:
 1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: network-manager
UpgradeStatus: Upgraded to disco on 2019-01-13 (18 days ago)
nmcli-dev:
 DEVICE   TYPE  STATE  IP4-CONNECTIVITY  IP6-CONNECTIVITY  DBUS-PATH
  CONNECTION  CON-UUID  
CON-PATH   
 wlp2s0   wifi  connected  full  limited   
/org/freedesktop/NetworkManager/Devices/2  Strange Noises  
ae54-3c3d-4714-8bf5-7e56bb7249c6  
/org/freedesktop/NetworkManager/ActiveConnection/2 
 enp63s0  ethernet  

Re: [Desktop-packages] [Bug 1814088] Re: totem crashed with SIGSEGV in tcache_get() [assertion "nqueue != NULL" failed in g_object_new_internal]

[Rachel Greenham]

True. And I can confirm it's not listed in my plugins at all. (There's 
just Cisco OpenH264 and Widevine). Only potentially-relevant extension 
is Disable HTML5 Autoplay, which if anything should *stop* any video 
being played before it gets to the software that does it.

Only other thing that seems odd, is the mimetime mapping Firefox has for 
MP3 audio (in prefs) *defaults* to Videos, but in my case it's set to 
"Use env"... but I wouldn't have set that (is first time I've seen it). 
It wouldn't be surprising if "Use env" gets it to be sent to Videos too, 
by a system default? So maybe it was an MP3 file. But not one I 
knowingly clicked on.

... but finding some MP3 files and playing them in the browser 
deliberately is working fine.

So no, I'm sorry, I'm mystified.

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

Title:
  totem crashed with SIGSEGV in tcache_get() [assertion "nqueue != NULL"
  failed in g_object_new_internal]

Status in totem package in Ubuntu:
  Incomplete

Bug description:
  I made no attempt to run Videos. This just came up out of the blue.
  Maybe a video embedded in Tweetdeck tried to trigger it? (Firefox
  66.0b4 from firefox-next ppa, installed for the working CSD when
  buttons on left.)

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: totem 3.30.0-4ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu19
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jan 23 13:41:15 2019
  ExecutablePath: /usr/bin/totem
  InstallationDate: Installed on 2018-09-11 (141 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  ProcCmdline: /usr/bin/totem --gapplication-service
  ProcEnviron:
   XDG_RUNTIME_DIR=
   SHELL=/bin/bash
   LANGUAGE=en_GB:en
   PATH=(custom, user)
   LANG=en_GB.UTF-8
  SegvAnalysis:
   Segfault happened at: 0x7f609e404d36 <__GI___libc_malloc+422>:   mov
(%rdx),%rsi
   PC (0x7f609e404d36) ok
   source "(%rdx)" (0x561c1b1ae92000) not located in a known VMA region (needed 
readable region)!
   destination "%rsi" ok
  SegvReason: reading unknown VMA
  Signal: 11
  SourcePackage: totem
  StacktraceTop:
   tcache_get (tc_idx=1) at malloc.c:2927
   __GI___libc_malloc (bytes=35) at malloc.c:3034
   g_malloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_strconcat () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
  Title: totem crashed with SIGSEGV in tcache_get()
  UpgradeStatus: Upgraded to disco on 2019-01-13 (17 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  XorgLog: Error: [Errno 2] No such file or directory: '/var/log/Xorg.0.log'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1814088/+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

Re: [Desktop-packages] [Bug 1814088] Re: totem crashed with SIGSEGV in tcache_get() [assertion "nqueue != NULL" failed in g_object_new_internal]

[Rachel Greenham]

I agree it's a bit of a nightmare. It was the start of the day and I 
literally just had Firefox-Next open, and Slack (using the app, not via 
Firefox). No video had been posted to slack. I can only think some 
random embedded video went by on the timeline or activities column in 
tweetdeck (the only tab) on firefox. Nothing else was going on, and said 
embedded videos usually either work fine or not at all. In the past I've 
had stuff like this happen when opening a Nautilus window onto a 
directory with videos in it, so it being the preview of said videos that 
probably crashed... but not this time.

So I agree, there's probably not much to be done about this unless it 
starts happening more. So far just that one time. (I didn't set it to 
ignore similar in future.)

(NB: replied via email because on-site form is timing out for me, all 
else working)

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

Title:
  totem crashed with SIGSEGV in tcache_get() [assertion "nqueue != NULL"
  failed in g_object_new_internal]

Status in totem package in Ubuntu:
  Incomplete

Bug description:
  I made no attempt to run Videos. This just came up out of the blue.
  Maybe a video embedded in Tweetdeck tried to trigger it? (Firefox
  66.0b4 from firefox-next ppa, installed for the working CSD when
  buttons on left.)

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: totem 3.30.0-4ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu19
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jan 23 13:41:15 2019
  ExecutablePath: /usr/bin/totem
  InstallationDate: Installed on 2018-09-11 (141 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  ProcCmdline: /usr/bin/totem --gapplication-service
  ProcEnviron:
   XDG_RUNTIME_DIR=
   SHELL=/bin/bash
   LANGUAGE=en_GB:en
   PATH=(custom, user)
   LANG=en_GB.UTF-8
  SegvAnalysis:
   Segfault happened at: 0x7f609e404d36 <__GI___libc_malloc+422>:   mov
(%rdx),%rsi
   PC (0x7f609e404d36) ok
   source "(%rdx)" (0x561c1b1ae92000) not located in a known VMA region (needed 
readable region)!
   destination "%rsi" ok
  SegvReason: reading unknown VMA
  Signal: 11
  SourcePackage: totem
  StacktraceTop:
   tcache_get (tc_idx=1) at malloc.c:2927
   __GI___libc_malloc (bytes=35) at malloc.c:3034
   g_malloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_strconcat () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
  Title: totem crashed with SIGSEGV in tcache_get()
  UpgradeStatus: Upgraded to disco on 2019-01-13 (17 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  XorgLog: Error: [Errno 2] No such file or directory: '/var/log/Xorg.0.log'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1814088/+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 1723615] Re: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

[Rachel Greenham]

Sure, just thought I'd better say something as it was my report
originally. :-)

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

Title:
  gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

Status in gnome-shell package in Ubuntu:
  Fix Released
Status in mutter package in Ubuntu:
  Fix Released
Status in mutter source package in Bionic:
  In Progress

Bug description:
  https://gitlab.gnome.org/GNOME/mutter/issues/130
  https://errors.ubuntu.com/problem/84e05b052e88b79520a684d6113084e9be8bc339

  ---

  [ Description ]

  This happened while I was away from the computer. By the timing it
  should have been well after the time it should have gone *into*
  displaysleep, and was also about 45min before I returned, so certainly
  wasn't the wake-up process either.

  What I observed when I did return: My 4K monitor didn't wake up
  (that's a known problem with this monitor, Dell P2715Q), the second
  monitor (Dell U2711) did wake up, showing the login screen.

  So although I've considered my Dell 4K problem a problem with waking
  up, I wonder if it might be actually a problem with it apparently
  going away completely after a longer displaysleep (it's usually fine
  if I just do a short sleep of a minute or two).

  Another possibility is the cat stepped on the keyboard and thus
  triggered an attempted display-wake. But that would actually be out of
  character (for the cat).

  Either way is a bug because the session should survive monitor
  shenanigans... :-)

  In some not known conditions, g-s might crash while computing global
  resolution for monitors.

  [ Test case ]

  There's really no test case for this bug, a part that g-s should not
  crash with this stacktrace. Unforuntaltey this is quite hard to
  reproduce, it might happen while resetting the crtc when setting up a
  (new) monitor or at wake up, but so far nobody has reported a way for
  reproducing this.

  [ Regression potential ]

  Global scale for attached monitors could not be properly computed, and
  thus if attaching an HiDPI device, the UI could not be scaled properly

  ---

  ProblemType: CrashDistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME-Greeter:GNOME
  Date: Sat Oct 14 15:39:50 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:

  InstallationDate: Installed on 2017-07-30 (75 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/false
  SegvAnalysis:
   Segfault happened at: 0x7fae20ab44a0 : 
mov0x8(%rdi),%eax
   PC (0x7fae20ab44a0) ok
   source "0x8(%rdi)" (0x0008) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11SourcePackage: gnome-shell
  StacktraceTop:
   meta_monitor_mode_get_resolution () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_calculate_mode_scale () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_update_logical_state_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_rebuild_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_xrandr_handle_xevent () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()
  UpgradeStatus: Upgraded to artful on 2017-08-22 (53 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1723615/+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 1723615] Re: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

[Rachel Greenham]

FWIW I can't reproduce this any more either; since 18.04 in fact I've
had no problems with gnome-shell crashing. The monitor very nearly
always does wake up when it's supposed to now (some difference in the
dpms signal being sent? Previously it would always wake for windows and
just had a hard time with Linux), and on the few occasions it hasn't, I
haven't lost my session and I just needed to powercycle the monitor
properly. So I was under the impression this was all fixed. :-) Possibly
by not-obviously-related changes elsewhere.

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

Title:
  gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

Status in mutter package in Ubuntu:
  Fix Released

Bug description:
  https://gitlab.gnome.org/GNOME/mutter/issues/130
  https://errors.ubuntu.com/problem/84e05b052e88b79520a684d6113084e9be8bc339

  ---

  [ Description ]

  This happened while I was away from the computer. By the timing it
  should have been well after the time it should have gone *into*
  displaysleep, and was also about 45min before I returned, so certainly
  wasn't the wake-up process either.

  What I observed when I did return: My 4K monitor didn't wake up
  (that's a known problem with this monitor, Dell P2715Q), the second
  monitor (Dell U2711) did wake up, showing the login screen.

  So although I've considered my Dell 4K problem a problem with waking
  up, I wonder if it might be actually a problem with it apparently
  going away completely after a longer displaysleep (it's usually fine
  if I just do a short sleep of a minute or two).

  Another possibility is the cat stepped on the keyboard and thus
  triggered an attempted display-wake. But that would actually be out of
  character (for the cat).

  Either way is a bug because the session should survive monitor
  shenanigans... :-)

  In some not known conditions, g-s might crash while computing global
  resolution for monitors.

  [ Test case ]

  There's really no test case for this bug, a part that g-s should not
  crash with this stacktrace. Unforuntaltey this is quite hard to
  reproduce, it might happen while resetting the crtc when setting up a
  (new) monitor or at wake up, but so far nobody has reported a way for
  reproducing this.

  [ Regression potential ]

  Global scale for attached monitors could not be properly computed, and
  thus if attaching an HiDPI device, the UI could not be scaled properly

  ---

  ProblemType: CrashDistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME-Greeter:GNOME
  Date: Sat Oct 14 15:39:50 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:

  InstallationDate: Installed on 2017-07-30 (75 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/false
  SegvAnalysis:
   Segfault happened at: 0x7fae20ab44a0 : 
mov0x8(%rdi),%eax
   PC (0x7fae20ab44a0) ok
   source "0x8(%rdi)" (0x0008) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11SourcePackage: gnome-shell
  StacktraceTop:
   meta_monitor_mode_get_resolution () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_calculate_mode_scale () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_update_logical_state_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_rebuild_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_xrandr_handle_xevent () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()
  UpgradeStatus: Upgraded to artful on 2017-08-22 (53 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1723615/+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 1773503] [NEW] should offer restart after system firmware upgrade

[Rachel Greenham]

Public bug reported:

The Software app launched by itself this morning to offer me a system
firmware (uefi bios) update of my Dell 9370. Presumably in its role as a
front-end to fwupd. That's not the bug, that's brilliant, that's pretty
much my last remaining reason to keep a Windows partition dealt with.
:-)

The bug is that when I clicked Update to let it do its job, the
procedure *appeared* to fail, not by reporting an error, but simply
returning back to the same screen offering the same update. Of course,
it was a system firmware update so you need to reboot to apply it, but
there was no communication from the app to that effect.

Therefore, the bug is that it *looked* like it failed, when it didn't.
It's a usability/user communication issue.

Expected: After applying the update it should throw up a standard
"restart needed" dialogue, as you get on eg: a kernel update. (User can
obviously then choose to do it now or later, as normal.) And in that
case, also, for the updates tab in Software to not continue to show the
update as needing doing.

(When I did finally reboot, the update ran completely successfully.)

NB: I was watching fwupdmgr monitor while Software ran the update, and
indeed it looked there as if the end-state was the previous version of
the system firmware was still in place, but no errors reported, so if
Software is looking at that (or a more direct-from-the-daemon
equivalent) its behaviour may be rational, and the bug is really in what
fwupdmgr monitor is reporting. ie: maybe whatever Software is looking at
to monitor progress needs to actually report that a reboot is needed, so
it can pass that along to the user.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubuntu-software 3.28.1-0ubuntu4.18.04.1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sat May 26 09:07:55 2018
InstallationDate: Installed on 2018-04-19 (36 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180409)
InstalledPlugins:
 gnome-software-plugin-flatpak N/A
 gnome-software-plugin-limba   N/A
 gnome-software-plugin-snap3.28.1-0ubuntu4.18.04.1
PackageArchitecture: all
SourcePackage: gnome-software
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gnome-software (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic package-from-proposed

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

Title:
  should offer restart after system firmware upgrade

Status in gnome-software package in Ubuntu:
  New

Bug description:
  The Software app launched by itself this morning to offer me a system
  firmware (uefi bios) update of my Dell 9370. Presumably in its role as
  a front-end to fwupd. That's not the bug, that's brilliant, that's
  pretty much my last remaining reason to keep a Windows partition dealt
  with. :-)

  The bug is that when I clicked Update to let it do its job, the
  procedure *appeared* to fail, not by reporting an error, but simply
  returning back to the same screen offering the same update. Of course,
  it was a system firmware update so you need to reboot to apply it, but
  there was no communication from the app to that effect.

  Therefore, the bug is that it *looked* like it failed, when it didn't.
  It's a usability/user communication issue.

  Expected: After applying the update it should throw up a standard
  "restart needed" dialogue, as you get on eg: a kernel update. (User
  can obviously then choose to do it now or later, as normal.) And in
  that case, also, for the updates tab in Software to not continue to
  show the update as needing doing.

  (When I did finally reboot, the update ran completely successfully.)

  NB: I was watching fwupdmgr monitor while Software ran the update, and
  indeed it looked there as if the end-state was the previous version of
  the system firmware was still in place, but no errors reported, so if
  Software is looking at that (or a more direct-from-the-daemon
  equivalent) its behaviour may be rational, and the bug is really in
  what fwupdmgr monitor is reporting. ie: maybe whatever Software is
  looking at to monitor progress needs to actually report that a reboot
  is needed, so it can pass that along to the user.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ubuntu-software 3.28.1-0ubuntu4.18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May 26 09:07:55 2018
  InstallationDate: Installed on 2018-04-19 (36 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180409)
  InstalledPlugins:
   

Re: [Desktop-packages] [Bug 1724439] Re: gnome-shell crashed with SIGSEGV in meta_window_get_monitor() from ffi_call_unix64() from ffi_call() from gjs_invoke_c_function() from function_call()

[Rachel Greenham]

not that we should let this (bug report) thread descend into KDE 
advocacy but I did actually try that, last time around. I'm afraid I 
couldn't get the hang of it, and then plasma went all weird on me, like 
the plasma background not filling the screen kind of weird. But I did 
try it. :-) Used to use KDE back in the day.

-- 
Rachel

On 15/03/18 13:39, dwilches wrote:
> ​
> ​
> Rachel, no need to switch to Mac to avoid this problem. What I ended up
> doing was this:
>
> $ sudo add-apt-repository ppa:kubuntu-ppa/backports
> $ sudo apt update && sudo apt upgrade
> $ sudo apt install kubuntu-desktop
>
>
> --
> Daniel Wilches
>
>
> On Thu, Mar 15, 2018 at 4:21 AM, Rachel Greenham <1724...@bugs.launchpad.net
>> wrote:
>> Well, my bug #1756036 just got (automatically-i-think) marked as a
>> duplicate of this one, and I'm on 18.04 (gnome-shell 3.27.92-0ubuntu1)
>> So that's one, Daniel. ;-) I'd been getting this on some mornings, but
>> the bug report was getting rejected because of outdated packages until
>> this morning. Interestingly it doesn't seem to happen again later in the
>> day, so, as noted before, length-of-sleep may be a factor.
>>
>> I reported a lot on these bugs in 17.10, until I eventually gave up and
>> just used my (half-the-speed) mac for a while. Freshly-installed 18.04
>> and tried again, and I *am* having far less trouble. When it does go
>> wrong, it "fails better", in that it seems to recover reasonably well
>> and leave me with a working session, even if there are a couple of side-
>> effects (eg: having both dash-to-dock and the dash in
>> activities/applications) which clear on an orderly logout/login.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1724439
>>
>> Title:
>>gnome-shell crashed with SIGSEGV in meta_window_get_monitor() from
>>ffi_call_unix64() from ffi_call() from gjs_invoke_c_function() from
>>function_call()
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mutter/+bug/1724439/+subscriptions
>>

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

Title:
  gnome-shell crashed with SIGSEGV in meta_window_get_monitor() from
  ffi_call_unix64() from ffi_call() from gjs_invoke_c_function() from
  function_call()

Status in Mutter:
  In Progress
Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/3e662975e4b7e6829b9d68d1c2b06f429e44c854

  ---

  left virtual box to update win10 came back and got error message

  ProblemType: Crash
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 23:37:32 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  InstallationDate: Installed on 2017-04-18 (182 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x7feb2ed42d94 <meta_window_get_monitor+4>:mov
0x18(%rax),%eax
   PC (0x7feb2ed42d94) ok
   source "0x18(%rax)" (0x0018) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   meta_window_get_monitor () from /usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ?? () from /usr/lib/libgjs.so.0
   ?? () from /usr/lib/libgjs.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_window_get_monitor()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1724439/+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 1724439] Re: gnome-shell crashed with SIGSEGV in meta_window_get_monitor() from ffi_call_unix64() from ffi_call() from gjs_invoke_c_function() from function_call()

[Rachel Greenham]

Well, my bug #1756036 just got (automatically-i-think) marked as a
duplicate of this one, and I'm on 18.04 (gnome-shell 3.27.92-0ubuntu1)
So that's one, Daniel. ;-) I'd been getting this on some mornings, but
the bug report was getting rejected because of outdated packages until
this morning. Interestingly it doesn't seem to happen again later in the
day, so, as noted before, length-of-sleep may be a factor.

I reported a lot on these bugs in 17.10, until I eventually gave up and
just used my (half-the-speed) mac for a while. Freshly-installed 18.04
and tried again, and I *am* having far less trouble. When it does go
wrong, it "fails better", in that it seems to recover reasonably well
and leave me with a working session, even if there are a couple of side-
effects (eg: having both dash-to-dock and the dash in
activities/applications) which clear on an orderly logout/login.

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

Title:
  gnome-shell crashed with SIGSEGV in meta_window_get_monitor() from
  ffi_call_unix64() from ffi_call() from gjs_invoke_c_function() from
  function_call()

Status in Mutter:
  In Progress
Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/3e662975e4b7e6829b9d68d1c2b06f429e44c854

  ---

  left virtual box to update win10 came back and got error message

  ProblemType: Crash
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 23:37:32 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  InstallationDate: Installed on 2017-04-18 (182 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x7feb2ed42d94 :mov
0x18(%rax),%eax
   PC (0x7feb2ed42d94) ok
   source "0x18(%rax)" (0x0018) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   meta_window_get_monitor () from /usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ?? () from /usr/lib/libgjs.so.0
   ?? () from /usr/lib/libgjs.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_window_get_monitor()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1724439/+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 1756036] Re: gnome-shell crashed with SIGSEGV in meta_window_get_monitor()

[Rachel Greenham]

*** This bug is a duplicate of bug 1724439 ***
https://bugs.launchpad.net/bugs/1724439

Daniel's latest comment on that bug shows that it looks like it doesn't
affect 3.27. This is 3.27. It's a shame those attachments got deleted...

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

Title:
  gnome-shell crashed with SIGSEGV in meta_window_get_monitor()

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  On some mornings, not all, I come to the computer and find it waiting
  to submit this. Most times it's rejected because of outdated packages
  (it being an alpha and I not yet having had a chance to run the daily
  update). This time it wasn't rejected, so here it is.

  Unlike earlier examples, in 17.10, it is leaving me with a functional
  gnome-shell so it does appear to be launching again afterwards. One
  side-effect though: After this happens I have both dash-to-dock *and*
  the dash in the activities/applications views. That gets fixed by
  logging out and in again.

  Today, in a slight break from tradition, the monitor was awake when I
  came to it.

  There's no core file in homedir.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: gnome-shell 3.27.92-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 14 20:40:31 2018
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  InstallationDate: Installed on 2018-02-20 (22 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x7f0188774754 :mov
0x18(%rax),%eax
   PC (0x7f0188774754) ok
   source "0x18(%rax)" (0x0018) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   meta_window_get_monitor () at /usr/lib/x86_64-linux-gnu/libmutter-2.so.0
   ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
   ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
   () at /usr/lib/libgjs.so.0
   () at /usr/lib/libgjs.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_window_get_monitor()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1756036/+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 1505409] Re: gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from _XEventsQueued() from XPending() from gdk_check_xpending() ["Connection to xwayland lost"]

[Rachel Greenham]

It failed to hold true on day 2 anyway, as today the session didn't
survive the overnight sleep. But in any case I re-checked the bug of
mine that was marked a duplicate of this one, and saw as it was during
one of my brief try-outs with wayland, is irrelevant to my current
gnome-session woes, as I'm back on xorg. I had thought this just one of
the family of gnome-shell crashers that was affecting both xorg and
wayland, but seemingly only with displayport monitors.

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

Title:
  gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from
  _XEventsQueued() from XPending() from gdk_check_xpending()
  ["Connection to xwayland lost"]

Status in GNOME Shell:
  Confirmed
Status in Ubuntu GNOME:
  Confirmed
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in gdm3 source package in Artful:
  Confirmed
Status in gnome-shell source package in Artful:
  Confirmed
Status in mutter source package in Artful:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/d0252e2b465152efea2511e72f1e31681e2b2742

  ---

  Occurred during start-up, before I did anything special...

  1 Ubuntu Wily Werewolf (development branch) 15.10
  2 3.16.3-1ubuntu6
  3&4 not applicable

  ProblemType: Crash
  DistroRelease: Ubuntu 15.10
  Package: gnome-shell 3.16.3-1ubuntu6
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.19.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Oct 12 19:22:07 2015
  DisplayManager: gdm
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:

  InstallationDate: Installed on 2015-10-08 (4 days ago)
  InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150924)
  ProcCmdline: gnome-shell --mode=gdm --wayland --display-server
  ProcEnviron:
   SHELL=/bin/false
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=nl_NL.UTF-8
  Signal: 5
  SourcePackage: gnome-shell
  StacktraceTop:
   ?? () from /usr/lib/libmutter.so.0
   _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
  Title: gnome-shell crashed with signal 5 in _XIOError()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1505409/+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 1505409] Re: gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from _XEventsQueued() from XPending() from gdk_check_xpending() ["Connection to xwayland lost"]

[Rachel Greenham]

Interesting

For what it's worth: On seeing #44 I tried turning off notification
popups and lock screen notifications and left it overnight. On waking I
had the usual problems I often (not always) have with my monitors
persuading them to wake up (one of them is a model with a known issue
with waking up: early-revision Dell P2715Q), but once I'd fought through
that (multiple monitor power-cycles) I still had the gnome session that
I had left on screen the previous evening. The first time *that's*
happened on more than a very short screen lock period since... since I
installed the Artful alpha I think.

One possible minor glitch, though probably not part of this bug: When
the monitors did eventually admit there was a signal coming from the
computer, I briefly saw the logged in gnome desktop before it was
replaced by the lock screen. Is that supposed to happen?

This is on Gnome Xorg session, on nVidia 387.22 (GTX960), gnome-shell
3.26.1-0ubuntu5, mutter 3.26.1-2ubuntu2 (the latter of which I know has
a newer version now in proposed which I'll be installing soon).

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

Title:
  gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from
  _XEventsQueued() from XPending() from gdk_check_xpending()
  ["Connection to xwayland lost"]

Status in GNOME Shell:
  Confirmed
Status in Ubuntu GNOME:
  Confirmed
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in gdm3 source package in Artful:
  Confirmed
Status in gnome-shell source package in Artful:
  Confirmed
Status in mutter source package in Artful:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/d0252e2b465152efea2511e72f1e31681e2b2742

  ---

  Occurred during start-up, before I did anything special...

  1 Ubuntu Wily Werewolf (development branch) 15.10
  2 3.16.3-1ubuntu6
  3&4 not applicable

  ProblemType: Crash
  DistroRelease: Ubuntu 15.10
  Package: gnome-shell 3.16.3-1ubuntu6
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.19.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Oct 12 19:22:07 2015
  DisplayManager: gdm
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:

  InstallationDate: Installed on 2015-10-08 (4 days ago)
  InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150924)
  ProcCmdline: gnome-shell --mode=gdm --wayland --display-server
  ProcEnviron:
   SHELL=/bin/false
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=nl_NL.UTF-8
  Signal: 5
  SourcePackage: gnome-shell
  StacktraceTop:
   ?? () from /usr/lib/libmutter.so.0
   _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
  Title: gnome-shell crashed with signal 5 in _XIOError()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1505409/+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 1723615] Re: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

[Rachel Greenham]

In fact I'm already on 387.22 which, I see from a nearby post on the
same forum, has the same fix:
https://devtalk.nvidia.com/default/topic/1025794/unix-graphics-
announcements-and-news/linux-solaris-and-freebsd-driver-387-22/

It hasn't helped.

TBH I don't think it applies as (fx: me reading up more on what PRIME
sync is) I don't think I'm using PRIME sync... my mobo has integrated
Intel HD4600 as well but I don't use it at all, and the nvidia card is
selected as default in uefi bios. I've done no prime sync setup at all.

There appear to be a shedload of upstream gnome-shell bugs relating to
these problems, and not everyone having them is using nVidia, though it
may be that they are all using DisplayPort to connect to their monitors,
although why something as user-level as gnome-shell is bothered with
*which* ports are used is beyond me...

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

Title:
  gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  This happened while I was away from the computer. By the timing it
  should have been well after the time it should have gone *into*
  displaysleep, and was also about 45min before I returned, so certainly
  wasn't the wake-up process either.

  What I observed when I did return: My 4K monitor didn't wake up
  (that's a known problem with this monitor, Dell P2715Q), the second
  monitor (Dell U2711) did wake up, showing the login screen.

  So although I've considered my Dell 4K problem a problem with waking
  up, I wonder if it might be actually a problem with it apparently
  going away completely after a longer displaysleep (it's usually fine
  if I just do a short sleep of a minute or two).

  Another possibility is the cat stepped on the keyboard and thus
  triggered an attempted display-wake. But that would actually be out of
  character (for the cat).

  Either way is a bug because the session should survive monitor
  shenanigans... :-)

  ProblemType: Crash
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME-Greeter:GNOME
  Date: Sat Oct 14 15:39:50 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:
   
  InstallationDate: Installed on 2017-07-30 (75 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/false
  SegvAnalysis:
   Segfault happened at: 0x7fae20ab44a0 : 
mov0x8(%rdi),%eax
   PC (0x7fae20ab44a0) ok
   source "0x8(%rdi)" (0x0008) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   meta_monitor_mode_get_resolution () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_calculate_mode_scale () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_update_logical_state_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_rebuild_derived () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   meta_monitor_manager_xrandr_handle_xevent () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
  Title: gnome-shell crashed with SIGSEGV in meta_monitor_mode_get_resolution()
  UpgradeStatus: Upgraded to artful on 2017-08-22 (53 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1723615/+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 1723620] Re: gnome-shell crashed with SIGSEGV in meta_window_update_for_monitors_changed()

[Rachel Greenham]

Just poking in to say this is still happening, and not magically fixed
by Artful's release date. It happened today, but trying to ubuntu-bug
the crash file failed. (It just quit when I clicked Continue.)

One difference today: Thinking maybe my screen-sleep woes were partly
because of gnome shell being in lock mode, I tried instead disabling
screen lock and suspend and just using ye olde x11 screen blanking to
standby, ie: xset dpms 1200 0 0. It still died, leaving a crash file
reporting this same error, at the time I tried to wake things up again.
I think again, supported by the description of this bug, it was probably
due to slowness in monitors waking up, or one of them having problems
waking up fully at all, then gnome-shell responds ungracefully - perhaps
even disgracefully - to the change in monitors. gnome shell is so damn
fragile.

gnome-shell 3.26.1-0ubuntu5

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

Title:
  gnome-shell crashed with SIGSEGV in
  meta_window_update_for_monitors_changed()

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  Pair this with bug #1723615: This one actually happened first, and was
  presumably the event that ended my gnome desktop session. Then the
  other one happened about 18 minutes later and happened to gdm's gnome-
  shell. Both occurred while I was away from the computer and the system
  should have been in displaysleep but not suspended.

  ProblemType: Crash
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.1-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: GNOME
  Date: Sat Oct 14 15:21:47 2017
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  InstallationDate: Installed on 2017-07-30 (75 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x7fd78c4b0e60 
:  mov0x40(%rbp),%edi
   PC (0x7fd78c4b0e60) ok
   source "0x40(%rbp)" (0x0040) not located in a known VMA region (needed 
readable region)!
   destination "%edi" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   meta_window_update_for_monitors_changed () at 
/usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   g_slist_foreach () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
   meta_screen_foreach_window () at /usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   () at /usr/lib/x86_64-linux-gnu/libmutter-1.so.0
   g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  Title: gnome-shell crashed with SIGSEGV in 
meta_window_update_for_monitors_changed()
  UpgradeStatus: Upgraded to artful on 2017-08-22 (53 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1723620/+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 1721189] Re: Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

[Rachel Greenham]

Yes, I see what you see: the borders around the tabs are missing. Not
just on the Security prefpane, on all of them, that have tabs.

But that's all that's wrong. (Or at least all that's obviously wrong.)
So while I can corroborate you, I think it's a different error and
should have a separate bug report. This bug was for the whole user
interface falling apart, rendering the application unusable, and has
been fixed.

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

Title:
  Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

Status in thunderbird package in Ubuntu:
  Confirmed

Bug description:
  Just received the update 1:52.4.0+build1-0ubuntu1 which has a broken
  user interface.

  See attached screenshot.

  Downgraded to thunderbird_52.3.0+build1-0ubuntu0.17.04.1_amd64.deb
  which solved the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1721189/+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 1721189] Re: Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

[Rachel Greenham]

Attached.

I'm using the Arc theme across the desktop, but no Thunderbird theme (or
rather, the default).

** Attachment added: "Screenshot from 2017-10-19 18-44-31.png"
   
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1721189/+attachment/4976376/+files/Screenshot%20from%202017-10-19%2018-44-31.png

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

Title:
  Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

Status in thunderbird package in Ubuntu:
  Confirmed

Bug description:
  Just received the update 1:52.4.0+build1-0ubuntu1 which has a broken
  user interface.

  See attached screenshot.

  Downgraded to thunderbird_52.3.0+build1-0ubuntu0.17.04.1_amd64.deb
  which solved the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1721189/+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 1721189] Re: Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

[Rachel Greenham]

Looks fine to me in 1:52.4.0+build1-0ubuntu2. I see the tabs just as
they are in the other pref panes.

Even if not, it would be a highly localised and minor problem, not at
all like the completely broken, unusable user interface, with large
parts missing or unstable, that we had as of the original bug report. So
it looks like a new issue. Possibly theme related?

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

Title:
  Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

Status in thunderbird package in Ubuntu:
  Confirmed

Bug description:
  Just received the update 1:52.4.0+build1-0ubuntu1 which has a broken
  user interface.

  See attached screenshot.

  Downgraded to thunderbird_52.3.0+build1-0ubuntu0.17.04.1_amd64.deb
  which solved the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1721189/+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 1717170] Re: gnome-shell crashes with SIGABRT: mutter:ERROR:backends/meta-monitor-manager.c:2274:meta_monitor_manager_get_logical_monitor_from_number: assertion failed: ((unsig

[Rachel Greenham]

Adding this to *this* bug, despite the "Fix Released", because it
exactly  matches the original post for this bug, whereas the others I've
encountered and reported on are different:

Oct 14 20:02:45 fleetfoot gnome-shell[12750]: 
meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) 
number < g_list_length (manager->logical_monitors)' failed
Oct 14 20:02:45 fleetfoot gnome-shell[12750]: 
meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' 
failed
Oct 14 20:02:45 fleetfoot kernel: [29646.218484] gnome-shell[12750]: segfault 
at 40 ip 7f9354b11e60 sp 7ffd0b949810 error 4 in 
libmutter-1.so.0.0.0[7f9354a6c000+141000]
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Couldn't register with 
accessibility bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy blocked the 
reply, the reply timeout expired, or the network connection was broken.
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: JS WARNING: 
[resource:///org/gnome/shell/ui/main.js 315]: reference to undefined property 
"MetaStage"
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: JS WARNING: 
[resource:///org/gnome/shell/ui/layout.js 221]: reference to undefined property 
"MetaWindowGroup"
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: JS WARNING: 
[resource:///org/gnome/shell/ui/osdMonitorLabeler.js 59]: reference to 
undefined property "MetaDBusDisplayConfigSkeleton"
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: JS WARNING: 
[resource:///org/gnome/gjs/modules/tweener/tweener.js 540]: reference to 
undefined property "isSpecialProperty"
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: JS WARNING: 
[resource:///org/gnome/shell/ui/slider.js 38]: reference to undefined property 
"CallyActor"
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: 
meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) 
number < g_list_length (manager->logical_monitors)' failed
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: 
meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' 
failed
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Extension 
"dash-to-d...@micxgx.gmail.com" had error: TypeError: this._monitor is undefined
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: loading user theme: 
/usr/share//themes/Arc-Dark/gnome-shell/gnome-shell.css
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Some code accessed the property 
'DBusMenu' on the module 'interfaces'. That property was defined with 'let' or 
'const' inside the module. This was previously supported, but is not correct 
according to the ES6 standard. Any symbols to be exported from a module must be 
defined with 'var'. The property access will work as previously for the time 
being, but please fix your code anyway.
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Some code accessed the property 
'WORKAROUND_RELOAD_TYPE_REGISTER' on the module 'util'. That property was 
defined with 'let' or 'const' inside the module. This was previously supported, 
but is not correct according to the ES6 standard. Any symbols to be exported 
from a module must be defined with 'var'. The property access will work as 
previously for the time being, but please fix your code anyway.
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Some code accessed the property 
'StatusNotifierWatcher' on the module 'statusNotifierWatcher'. That property 
was defined with 'let' or 'const' inside the module. This was previously 
supported, but is not correct according to the ES6 standard. Any symbols to be 
exported from a module must be defined with 'var'. The property access will 
work as previously for the time being, but please fix your code anyway.
Oct 14 20:02:46 fleetfoot gnome-shell[25511]: Some code accessed the property 
'StatusNotifierWatcher' on the module 'interfaces'. That property was defined 
with 'let' or 'const' inside the module. This was previously supported, but is 
not correct according to the ES6 standard. Any symbols to be exported from a 
module must be defined with 'var'. The property access will work as previously 
for the time being, but please fix your code anyway.
Oct 14 20:02:47 fleetfoot kernel: [29647.398006] gnome-shell[25511]: segfault 
at 40 ip 7f67c43bce60 sp 7ffd22dab610 error 4 in 
libmutter-1.so.0.0.0[7f67c4317000+141000]

Symptoms *observed*, again, were that I was logged out when I returned
to the computer the following afternoon.

So this happened twice in quick succession. The above fragment is from a
'grep gnome-shell syslog.1', I can provide a fuller log if anyone's
interested, but there was no /var/run/crash file generated from this
event.

gnome-shell: 3.26.1-0ubuntu3
mutter & libmutter-1-0: 3.26.1-2ubuntu1

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

Title:
  gnome-shell crashes with SIGABRT: 

[Desktop-packages] [Bug 1717170] Re: gnome-shell crashes with SIGABRT: mutter:ERROR:backends/meta-monitor-manager.c:2274:meta_monitor_manager_get_logical_monitor_from_number: assertion failed: ((unsig

[Rachel Greenham]

bug #1723615 came up with this fix in place. Whack-a-mole! :-)

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

Title:
  gnome-shell crashes with SIGABRT: mutter:ERROR:backends/meta-monitor-
  manager.c:2274:meta_monitor_manager_get_logical_monitor_from_number:
  assertion failed: ((unsigned int) number < g_list_length
  (manager->logical_monitors))

Status in GNOME Shell:
  Fix Released
Status in Mutter:
  Fix Released
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in mutter package in Ubuntu:
  Fix Released

Bug description:
  https://errors.ubuntu.com/problem/a9ace2e3301009e3a5344f8dac4e56fc4c23b1b8

  ---

  I'm testing Ubuntu 17.10 installed on Lenovo PC (with Intel Core
  i5-6500 CPU and Intel HD Graphics 530 (skylake GT2). Session is
  crashing (login screen is displayed again) every time I change the
  monitor Input (e.g. from DP to HDMI) or switching off the monitor. It
  is happening since some updated from beginning of September were
  installed. Same situation is for both session types, default Wayland
  and also for X.org. Tested also with Live USB, same behaviour.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.25.91-0ubuntu4
  ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1
  Uname: Linux 4.13.0-11-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 14 07:28:54 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-09-11 (2 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170906)
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1717170/+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 1717170] Re: gnome-shell crashes with SIGABRT: mutter:ERROR:backends/meta-monitor-manager.c:2274:meta_monitor_manager_get_logical_monitor_from_number: assertion failed: ((unsig

[Rachel Greenham]

I had one crash after applying this yesterday (and rebooting): it
crashed right out to the console, not even to the login screen, and when
I tried logging in again the session failed to start. But since a second
reboot it's apparently been fine. This bug went away, and so too has my
bug #1720149 (so far anyway, I don't seem able to reproduce it now,
although saying so will doubtless trigger it next time I let the
displays sleep). I can't explain that first crash, but as I also can't
repeat it, I guess we ignore it for now.

This in Gnome in Xorg under nVidia 387, modeset=0. xorg sessions seem
unable to start with modeset=1 btw.

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

Title:
  gnome-shell crashes with SIGABRT: mutter:ERROR:backends/meta-monitor-
  manager.c:2274:meta_monitor_manager_get_logical_monitor_from_number:
  assertion failed: ((unsigned int) number < g_list_length
  (manager->logical_monitors))

Status in GNOME Shell:
  Fix Released
Status in Mutter:
  Fix Released
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in mutter package in Ubuntu:
  Fix Released

Bug description:
  https://errors.ubuntu.com/problem/a9ace2e3301009e3a5344f8dac4e56fc4c23b1b8

  ---

  I'm testing Ubuntu 17.10 installed on Lenovo PC (with Intel Core
  i5-6500 CPU and Intel HD Graphics 530 (skylake GT2). Session is
  crashing (login screen is displayed again) every time I change the
  monitor Input (e.g. from DP to HDMI) or switching off the monitor. It
  is happening since some updated from beginning of September were
  installed. Same situation is for both session types, default Wayland
  and also for X.org. Tested also with Live USB, same behaviour.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.25.91-0ubuntu4
  ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1
  Uname: Linux 4.13.0-11-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 14 07:28:54 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-09-11 (2 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170906)
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1717170/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

It just happened, so attached the crash file that was generated. NB:

gnome-shell 3.26.1-0ubuntu2
mutter 3.26.1-1
libmutter-1-0 3.26.1-1

NB: I notice there's also a libmutter-0-0 installed, possibly a hangover
from the original zesty install. but ldd $(which gnome-shell) indicates
it's linked to libmutter-1.so.0 so it's presumably irrelevant. I've now
removed it anyway.

This was a bit of a messy event. It went something like this:

Attempted to wake system (from displaysleep, wasn't suspended)

It appeared at first to work! My session was there. But the displays
config was wrong.

I noticed that my 4K monitor had (again, I think it's *its* problem)
woken up thinking it's a 1440p monitor. As this is usually fixed by
powercycling it, I did so.

The second monitor (actually the first in discovery order), which is
*actually* a 1440p monitor, also went to sleep.

Power-cycling *it* woke them both up, (I think; things got confusing)
but at that point it came back to the gdm login screen. So I'm guessing
around then was where the gnome-shell crash happened.

Often it's simpler than that. I wake the system up, it comes up logged-
out.

** Attachment added: "_usr_bin_gnome-shell.1000.crash"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+attachment/4967524/+files/_usr_bin_gnome-shell.1000.crash

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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

Re: [Desktop-packages] [Bug 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

I’m afk today but will try to get this information on Wednesday.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

That wouldn't surprise me. I've seen other reports, on IRC, to the same
effect. Sadly, displayport is not optional here, not if I actually want
to run my monitors at full resolution.

Someone mentioned it being a "known bug" in mutter? However they didn't
link to it and I wasn't at the keyboard at the time to nag them to do
so.

It would explain how I haven't seen it at all on the laptop, which I
only use with its internal screen.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1721189] Re: Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

[Rachel Greenham]

Confirmed fixed for me too.

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

Title:
  Thunderbird 1:52.4.0+build1-0ubuntu1 broken user interface

Status in thunderbird package in Ubuntu:
  Fix Released

Bug description:
  Just received the update 1:52.4.0+build1-0ubuntu1 which has a broken
  user interface.

  See attached screenshot.

  Downgraded to thunderbird_52.3.0+build1-0ubuntu0.17.04.1_amd64.deb
  which solved the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1721189/+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 1721602] [NEW] When creating web application, should inherit cookies for site

[Rachel Greenham]

Public bug reported:

I wanted to use GnomeWeb to run Tweetdeck as a saved web application. So
I installed epiphany-browser, navigated to tweetdeck.twitter.com, logged
in, and then attempted to save it as a web application. This all seemed
to work, as well as Tweetdeck itself running apparently happily in
there, and being OK with being moved to a screen with a different
scaling factor (which Chrome's webapps don't handle, which is why I'm
doing this.)

When I launched it, it invited me to log in. I clicked on the button,
but it opened tweetdeck in Chrome, my default browser. I was already
logged in there, so it just opened. There was no-where for me to log in
the GnomeWeb web application.

I was at an impasse. There seems to be no way in the user interface to
do this.

I have a workaround: I copied the cookies.sqlite file from
~/.config/epiphany to the webapp subdirectory (ie: ~/.config/epiphany
/app-epiphany-tweetdeck-longhexnumber) and relaunched the webapp. This
worked.

Suggestion for a fix could be that when saving a new web application, to
copy the cookies in the main browser cookies list that relate to that
web application's site. I didn't do it selectively though, I just copied
the whole cookies file (I had not visited another site since installing
it so there probably isn't anything else in there that tweetdeck doesn't
need). It all seems to be working now, but this is just a commandline
workaround.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: epiphany-browser 3.26.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-14.15-generic 4.13.4
Uname: Linux 4.13.0-14-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.7-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Oct  5 18:17:26 2017
InstallationDate: Installed on 2017-07-30 (66 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: epiphany-browser
UpgradeStatus: Upgraded to artful on 2017-08-22 (44 days ago)

** Affects: epiphany-browser (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug artful wayland-session

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

Title:
  When creating web application, should inherit cookies for site

Status in epiphany-browser package in Ubuntu:
  New

Bug description:
  I wanted to use GnomeWeb to run Tweetdeck as a saved web application.
  So I installed epiphany-browser, navigated to tweetdeck.twitter.com,
  logged in, and then attempted to save it as a web application. This
  all seemed to work, as well as Tweetdeck itself running apparently
  happily in there, and being OK with being moved to a screen with a
  different scaling factor (which Chrome's webapps don't handle, which
  is why I'm doing this.)

  When I launched it, it invited me to log in. I clicked on the button,
  but it opened tweetdeck in Chrome, my default browser. I was already
  logged in there, so it just opened. There was no-where for me to log
  in the GnomeWeb web application.

  I was at an impasse. There seems to be no way in the user interface to
  do this.

  I have a workaround: I copied the cookies.sqlite file from
  ~/.config/epiphany to the webapp subdirectory (ie: ~/.config/epiphany
  /app-epiphany-tweetdeck-longhexnumber) and relaunched the webapp. This
  worked.

  Suggestion for a fix could be that when saving a new web application,
  to copy the cookies in the main browser cookies list that relate to
  that web application's site. I didn't do it selectively though, I just
  copied the whole cookies file (I had not visited another site since
  installing it so there probably isn't anything else in there that
  tweetdeck doesn't need). It all seems to be working now, but this is
  just a commandline workaround.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: epiphany-browser 3.26.1-1ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-14.15-generic 4.13.4
  Uname: Linux 4.13.0-14-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Oct  5 18:17:26 2017
  InstallationDate: Installed on 2017-07-30 (66 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: epiphany-browser
  UpgradeStatus: Upgraded to artful on 2017-08-22 (44 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/1721602/+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 1505409] Re: gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from _XEventsQueued() from XPending() from gdk_check_xpending() ["Connection to xwayland lost"]

[Rachel Greenham]

I got here because my apport-raised bug #1721492 apparently
automatically got marked as a duplicate of this. I'm not so sure:

This happened after a kernel upgrade to 4.13.0-14-generic. Yesterday I
was happily using this system in a wayland session using nouveau. On
reboot with this update, all I saw was a black screen. I had to ssh in
from my phone to see in /var/log/syslog a bunch of apparent nouveau-drm
failures like this:

Oct  5 10:12:46 fleetfoot kernel: [1.304052] [drm] Initialized nouveau 
1.3.1 20120801 for :01:00.0 on minor 0
Oct  5 10:12:46 fleetfoot kernel: [4.245166] nouveau :01:00.0: DRM: EVO 
timeout
Oct  5 10:12:46 fleetfoot kernel: [6.245268] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:12:46 fleetfoot kernel: [8.250984] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:12:47 fleetfoot kernel: [9.292554] nouveau :01:00.0: bus: 
MMIO read of  FAULT at 61a804 [ IBUS ]
Oct  5 10:12:47 fleetfoot kernel: [9.302375] nouveau :01:00.0: bus: 
MMIO read of  FAULT at 61a804 [ IBUS ]
Oct  5 10:12:55 fleetfoot kernel: [   17.770234] nouveau :01:00.0: DRM: 
base-0: timeout
Oct  5 10:12:57 fleetfoot kernel: [   19.770400] nouveau :01:00.0: DRM: 
base-0: timeout
Oct  5 10:12:57 fleetfoot kernel: [   19.776398] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:12:59 fleetfoot kernel: [   21.776531] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:12:59 fleetfoot kernel: [   21.807177] nouveau :01:00.0: DRM: 
base-0: timeout
Oct  5 10:13:01 fleetfoot kernel: [   23.782358] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:13:03 fleetfoot kernel: [   25.801765] nouveau :01:00.0: DRM: 
base-0: timeout
Oct  5 10:13:03 fleetfoot kernel: [   25.807270] nouveau :01:00.0: DRM: 
base-1: timeout
Oct  5 10:13:05 fleetfoot kernel: [   27.818059] nouveau :01:00.0: DRM: 
base-0: timeout
Oct  5 10:13:05 fleetfoot kernel: [   27.823600] nouveau :01:00.0: DRM: 
base-1: timeout

... and so on. It doesn't stop until I reboot (which hangs, although I
think after rsyslogd has closed. I need to hit reset).

I had seen this before, on the first kernel 4.13 version in Artful.
Reverting then to the last 4.12 let things work for me. But trying that
this time, trying to boot kernel 4.13.0.12, didn't help; I just got the
same symptoms.

Got the system working again by installing the nvidia-387 proprietary
drivers and using them in default configuration in an xorg session. On
the previous occasion I saw this, it also affected nvidia-384 (as was
current then), with continual panics reported in the nvidia-drm module,
until I turned off modeset (at the time I had, with partial success,
been running wayland on that). I haven't yet tried modeset on this
nvidia driver.

After I got the system working again, and logged in, I was presented
with the apport bug report that led to #1721492. I queried in there
whether it was the same issue, but on later seeing syslog it looks like
those nouveau errors only show up after gnome-shell (in gdm) is
launched.

Attached to this comment, the complete syslog of that first session
after rebooting from the upgrade. I think those nouveau timeout errors
are the thing. Attached to the next comment (as I seem unable to attach
more than one file to a comment) is the section from
/var/log/apt/history.log showing what was upgraded this morning before
that all happened. Other drivers were involved.

** Attachment added: "syslog.nouveaudrm"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1505409/+attachment/4962743/+files/syslog.nouveaudrm

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

Title:
  gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from
  _XEventsQueued() from XPending() from gdk_check_xpending()
  ["Connection to xwayland lost"]

Status in GNOME Shell:
  Confirmed
Status in Ubuntu GNOME:
  Confirmed
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in gdm3 source package in Artful:
  Confirmed
Status in gnome-shell source package in Artful:
  Confirmed
Status in mutter source package in Artful:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/d0252e2b465152efea2511e72f1e31681e2b2742

  ---

  Occurred during start-up, before I did anything special...

  1 Ubuntu Wily Werewolf (development branch) 15.10
  2 3.16.3-1ubuntu6
  3&4 not applicable

  ProblemType: Crash
  DistroRelease: Ubuntu 15.10
  Package: gnome-shell 3.16.3-1ubuntu6
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.19.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Oct 12 19:22:07 2015
  DisplayManager: gdm
  ExecutablePath: /usr/bin/gnome-shell

[Desktop-packages] [Bug 1505409] Re: gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from _XEventsQueued() from XPending() from gdk_check_xpending() ["Connection to xwayland lost"]

[Rachel Greenham]

/var/log/history.log section as per above post

** Attachment added: "part-history.log"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1505409/+attachment/4962744/+files/part-history.log

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

Title:
  gnome-shell crashed with SIGTRAP in x_io_error() from _XIOError() from
  _XEventsQueued() from XPending() from gdk_check_xpending()
  ["Connection to xwayland lost"]

Status in GNOME Shell:
  Confirmed
Status in Ubuntu GNOME:
  Confirmed
Status in gdm3 package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in gdm3 source package in Artful:
  Confirmed
Status in gnome-shell source package in Artful:
  Confirmed
Status in mutter source package in Artful:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/d0252e2b465152efea2511e72f1e31681e2b2742

  ---

  Occurred during start-up, before I did anything special...

  1 Ubuntu Wily Werewolf (development branch) 15.10
  2 3.16.3-1ubuntu6
  3&4 not applicable

  ProblemType: Crash
  DistroRelease: Ubuntu 15.10
  Package: gnome-shell 3.16.3-1ubuntu6
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.19.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Oct 12 19:22:07 2015
  DisplayManager: gdm
  ExecutablePath: /usr/bin/gnome-shell
  GsettingsChanges:

  InstallationDate: Installed on 2015-10-08 (4 days ago)
  InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150924)
  ProcCmdline: gnome-shell --mode=gdm --wayland --display-server
  ProcEnviron:
   SHELL=/bin/false
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=nl_NL.UTF-8
  Signal: 5
  SourcePackage: gnome-shell
  StacktraceTop:
   ?? () from /usr/lib/libmutter.so.0
   _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
  Title: gnome-shell crashed with signal 5 in _XIOError()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1505409/+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 1721493] [NEW] thunderbird ui hopelessly corrupted (screenshot)

[Rachel Greenham]

Public bug reported:

With this version much of the thunderbird UI is unusable and corrupted,
with massive redraw failures. This affects Xorg and Wayland sessions on
nvidia, nouveau, intel and oss radeon. (When I finally reported it, it
was on nvidia/xorg but wanted to stress it wasn't particular to that
environment.)

Reverting to previous version 1:52.2, which happened to be in my cache,
works fine.

I realise this is from artful-proposed/main and what am I doing there?
The reason being, the version is artful/main is still on thunderbird 45.
Until now the proposed builds have been fine.

Screenshot attached. Resize the window and the chaos is quite animated.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: thunderbird 1:52.4.0+build1-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-14.15-generic 4.13.4
Uname: Linux 4.13.0-14-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
AddonCompatCheckDisabled: False
ApportVersion: 2.20.7-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC1:  rachel 1809 F pulseaudio
 /dev/snd/controlC2:  rachel 1809 F pulseaudio
 /dev/snd/controlC0:  rachel 1809 F pulseaudio
BuildID: 20171003222123
Channel: Unavailable
CurrentDesktop: GNOME
Date: Thu Oct  5 10:31:06 2017
Extensions: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini 
or extensions.sqlite)
InstallationDate: Installed on 2017-07-30 (66 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
IpRoute:
 default via 192.168.1.254 dev eno1 proto static metric 100 
 169.254.0.0/16 dev eno1 scope link metric 1000 
 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.109 metric 100
Locales: extensions.sqlite corrupt or missing
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=52.4.0/20171003222123 (In use)
RunningIncompatibleAddons: False
SourcePackage: thunderbird
Themes: extensions.sqlite corrupt or missing
UpgradeStatus: Upgraded to artful on 2017-08-22 (43 days ago)
dmi.bios.date: 11/26/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1005
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z87I-PRO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1005:bd11/26/2014:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ87I-PRO:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.version: System Version
dmi.sys.vendor: ASUS

** Affects: thunderbird (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: amd64 apport-bug artful package-from-proposed

** Attachment added: "Screenshot from 2017-10-05 10-30-50.png"
   
https://bugs.launchpad.net/bugs/1721493/+attachment/4962674/+files/Screenshot%20from%202017-10-05%2010-30-50.png

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

Title:
  thunderbird ui hopelessly corrupted (screenshot)

Status in thunderbird package in Ubuntu:
  Confirmed

Bug description:
  With this version much of the thunderbird UI is unusable and
  corrupted, with massive redraw failures. This affects Xorg and Wayland
  sessions on nvidia, nouveau, intel and oss radeon. (When I finally
  reported it, it was on nvidia/xorg but wanted to stress it wasn't
  particular to that environment.)

  Reverting to previous version 1:52.2, which happened to be in my
  cache, works fine.

  I realise this is from artful-proposed/main and what am I doing there?
  The reason being, the version is artful/main is still on thunderbird
  45. Until now the proposed builds have been fine.

  Screenshot attached. Resize the window and the chaos is quite
  animated.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: thunderbird 1:52.4.0+build1-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-14.15-generic 4.13.4
  Uname: Linux 4.13.0-14-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  AddonCompatCheckDisabled: False
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  rachel 1809 F pulseaudio
   /dev/snd/controlC2:  rachel 1809 F pulseaudio
   /dev/snd/controlC0:  rachel 1809 F pulseaudio
  BuildID: 20171003222123
  Channel: Unavailable
  CurrentDesktop: GNOME
  Date: Thu Oct  5 10:31:06 2017
  Extensions: extensions.sqlite corrupt or missing
  ForcedLayersAccel: False
  IfupdownConfig:
   # 

[Desktop-packages] [Bug 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

ok, same symptoms occurred with the default theme. So after all it looks
like the shell theme has nothing to do with it.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

well I spoke too soon. Crash occurred with the locally 'built' arc
theme. Slightly different though in that this time it *did* hang the
system. But it started with the same segv message logged. So back to the
default+Ambiance theme to test that for longer.

Problem with trying to prove a negative. You can only say "Well it
hasn't crashed *yet*" until it does. Damn, I liked that theme. :-(

(Of course, now to try to prove the same negative about the default
theme... I kind of hope it fails too now so it's not my favourite
theme's fault.)

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

arc-theme package uninstalled and instead arc gtk & shell themes
installed manually as directed in its github page via autogen. This
appears not to be triggering the crash. even though the autogen doesn't
know any gnome > 3.22.  It may be that similarly rebuilding the
arc-theme package for a gnome 3.26 environment would fix it, but I still
don't really have a theory as to why it should break, let alone only on
nvidia. There's no binaries in it afaik.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

I think my modeset=1 test earlier was invalid; I don't think that change
was ever applied. It *did* get applied just now with a routine dist-
upgrade, which included an update to console-setup, which forced update-
initramfs. And then the system was unbootable except via the recovery
system. syslog is full of crashes like this in rapid succession:

Sep 30 13:33:38 fleetfoot kernel: [  117.641448] [ cut here 
]
Sep 30 13:33:38 fleetfoot kernel: [  117.641467] WARNING: CPU: 0 PID: 221 at 
/build/linux-s_bACt/linux-4.13.0/drivers/gpu/drm/drm_atomic_helper.c:1682 
drm_atomic_helper_commit_hw_done+0x99/0xa0 [drm_kms_helper]
Sep 30 13:33:38 fleetfoot kernel: [  117.641468] Modules linked in: rfcomm 
hid_magicmouse hidp cmac bnep nls_iso8859_1 nvidia_uvm(POE) hid_apple joydev 
input_leds hid_generic ath3k btusb btrtl btbcm btintel bluetooth snd_usb_audio 
snd_usbmidi_lib usbhid hid ecdh_generic snd_hda_codec_hdmi eeepc_wmi asus_wmi 
cmdlinepart intel_spi_platform intel_rapl intel_spi spi_nor wmi_bmof 
sparse_keymap mtd x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm 
snd_hda_codec_realtek snd_hda_codec_generic irqbypass crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec pcbc snd_hda_core 
snd_hwdep arc4 snd_pcm snd_seq_midi ath9k aesni_intel snd_seq_midi_event 
ath9k_common ath9k_hw snd_rawmidi aes_x86_64 crypto_simd snd_seq glue_helper 
cryptd ath intel_cstate snd_seq_device intel_rapl_perf mac80211 snd_timer 
cfg80211 snd soundcore
Sep 30 13:33:38 fleetfoot kernel: [  117.641496]  mei_me mei shpchp lpc_ich wmi 
mac_hid nct6775 hwmon_vid coretemp parport_pc ppdev lp parport ip_tables 
x_tables autofs4 nvidia_drm(POE) nvidia_modeset(POE) i915 nvidia(POE) 
i2c_algo_bit drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt 
fb_sys_fops ahci ptp drm libahci pps_core video
Sep 30 13:33:38 fleetfoot kernel: [  117.641507] CPU: 0 PID: 221 Comm: 
kworker/u16:6 Tainted: PW  OE   4.13.0-12-generic #13-Ubuntu
Sep 30 13:33:38 fleetfoot kernel: [  117.641507] Hardware name: ASUS All 
Series/Z87I-PRO, BIOS 1005 11/26/2014
Sep 30 13:33:38 fleetfoot kernel: [  117.641511] Workqueue: events_unbound 
commit_work [drm_kms_helper]
Sep 30 13:33:38 fleetfoot kernel: [  117.641512] task: 970a91cec5c0 
task.stack: b72901e5c000
Sep 30 13:33:38 fleetfoot kernel: [  117.641515] RIP: 
0010:drm_atomic_helper_commit_hw_done+0x99/0xa0 [drm_kms_helper]
Sep 30 13:33:38 fleetfoot kernel: [  117.641515] RSP: 0018:b72901e5fdb8 
EFLAGS: 00010286
Sep 30 13:33:38 fleetfoot kernel: [  117.641516] RAX: 970a8ff8b008 RBX: 
0004 RCX: 970a9ca0c000
Sep 30 13:33:38 fleetfoot kernel: [  117.641516] RDX: 970a8dce1400 RSI: 
0001 RDI: 970a93a56c08
Sep 30 13:33:38 fleetfoot kernel: [  117.641517] RBP: b72901e5fdd8 R08: 
970aafa12398 R09: 0018
Sep 30 13:33:38 fleetfoot kernel: [  117.641517] R10: b72901e5fd88 R11: 
0372 R12: 0001
Sep 30 13:33:38 fleetfoot kernel: [  117.641518] R13: 970a97780b40 R14: 
970a93a56c08 R15: 970a93a56c08
Sep 30 13:33:38 fleetfoot kernel: [  117.641518] FS:  () 
GS:970aafa0() knlGS:
Sep 30 13:33:38 fleetfoot kernel: [  117.641519] CS:  0010 DS:  ES:  
CR0: 80050033
Sep 30 13:33:38 fleetfoot kernel: [  117.641519] CR2: 7fa55cd3a010 CR3: 
0003ff609000 CR4: 001406f0
Sep 30 13:33:38 fleetfoot kernel: [  117.641520] DR0:  DR1: 
 DR2: 
Sep 30 13:33:38 fleetfoot kernel: [  117.641520] DR3:  DR6: 
fffe0ff0 DR7: 0400
Sep 30 13:33:38 fleetfoot kernel: [  117.641521] Call Trace:
Sep 30 13:33:38 fleetfoot kernel: [  117.641524]  
nvidia_drm_atomic_helper_commit_tail+0x10e/0x170 [nvidia_drm]
Sep 30 13:33:38 fleetfoot kernel: [  117.641527]  commit_tail+0x3f/0x60 
[drm_kms_helper]
Sep 30 13:33:38 fleetfoot kernel: [  117.641530]  commit_work+0x12/0x20 
[drm_kms_helper]
Sep 30 13:33:38 fleetfoot kernel: [  117.641532]  process_one_work+0x1e7/0x410
Sep 30 13:33:38 fleetfoot kernel: [  117.641533]  worker_thread+0x4a/0x410
Sep 30 13:33:38 fleetfoot kernel: [  117.641534]  kthread+0x125/0x140
Sep 30 13:33:38 fleetfoot kernel: [  117.641535]  ? process_one_work+0x410/0x410
Sep 30 13:33:38 fleetfoot kernel: [  117.641536]  ? 
kthread_create_on_node+0x70/0x70
Sep 30 13:33:38 fleetfoot kernel: [  117.641538]  ret_from_fork+0x25/0x30
Sep 30 13:33:38 fleetfoot kernel: [  117.641538] Code: 7d 30 e8 db b8 2c fa 48 
89 df c6 07 00 0f 1f 40 00 49 8b 4e 08 41 83 c4 01 44 39 a1 38 03 00 00 7f 98 
5b 41 5c 41 5d 41 5e 5d c3 <0f> ff eb c0 f3 c3 90 0f 1f 44 00 00 48 8b 4f 08 8b 
81 38 03 00
Sep 30 13:33:38 fleetfoot kernel: [  117.641552] ---[ end trace 
ab364b2a1fae43bb ]---
Sep 30 13:33:39 fleetfoot kernel: [  117.974932] [ cut here 
]


However that's probably offtopic here, and just speaks to nvidia kms 

[Desktop-packages] [Bug 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

It may be the Arc shell theme, in interaction with nVidia:

I was unable to reproduce the problem on the Macbook Pro using Xorg
gnome session, and that still with the Arc shell theme. Both a short
(few minutes) and long (greater than one hour) display sleeps tested.

I was also unable to reproduce it on the nVidia-equipped desktop with
the Default shell theme selected, on either short or long display sleep.
needs-root-rights is still set to yes in this configuration (ie: the
same as tested yesterday evening except for switching back to default
themes.)

I don't know how a theme can cause a segfault, it's just image assets
and css. But I'll leave it on Default for now to see if the issue does
after all recur. I'll also go back to modeset=1 but needs-root-rights
left unset, and wait and see.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

That would appear to be very different from what we're trying to report
here:

1. It's not hanging. It's presumably exiting, forcing a logout, and it
all happens before the monitors are awake enough to show a picture.
We're not in a hung state at any point.

2. It's not only suspend, it's wake from only display-sleep too. The
rest of the computer isn't suspended or sleeping in any manner. It
*also* failed, in the exact same manner, on wake from suspend, but this
suggests the problem isn't in suspending or waking from that, but just
about the display sleep/wake.

3. It's only affecting nVidia (or at least, for me, it seems not to be
also affecting Intel, but I haven't tried such a long sleep under
Intel/Xorg and I should - tomorrow, as I'm in bed now). I bet there's no
problem. :-)

4. It appears to be only affecting Xorg, although of course with nVidia
there's too much else broken when trying to force it to use Wayland
(which is, after all, not enabled by default for these reasons).
Certainly no such problems on Intel/Wayland which *does* regularly get
to sleep for long periods of time between uses, and I've never seen it
hang on wake.

(Hardware of my Intel graphics machine is an Early 2015 13" Retina
Macbook Pro. This specifically is a Broadwell Core-i5 with Intel Iris
6100, and I've only attempted to use it on its own screen, not with any
external screens connected. Generally, it runs Linux brilliantly, as far
as I've so far tried, and is very happy with Wayland. All hardware just
works OOTB.)

I'm not using the default ubuntu session (with or without wayland) on
either machine, but the GNOME session - wayland on the intel, xorg on
the nvidia. Basically just because I wanted vanilla dash-to-dock. I'm
not running many extensions, dash to dock, a wallpaper changer, ubuntu
appindicators (which isn't working on Xorg on either machine btw, to be
the subject of another bug report when I get a round tuit)... and
nothing else that I remember right now while I'm not at it. Come to
think of it, I do need to test using the default gnome shell theme
rather than Arc's. I will tomorrow.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  

[Desktop-packages] [Bug 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

neither change made a difference in the end. the needs-root-rights
change (instead of, not as well as, modeset) didn't help either, after a
long sleep.

Why instead-of not as-well-as? Because the manpage for Xwrapper.config
said that its default setting of 'auto' turns needs-root-rights off is
kms is enabled and on if it's enabled. So i daresay setting it directly
is superfluous, it's controlled by enabling modeset or not.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

... and the answer is no. After a longer display-sleep i woke it up to
find myself back at the login prompt. Definitely that and not the lock
screen.

This may in part be related to long-term issues I have with this
monitor. Early-revision Dell P2715Q 4K monitors have known firmware-
related issues with waking from sleep. It has phases. Sometimes it just
works. Sometimes it's narcoleptic, taking the form of just going
straight back to sleep after an attempted wake. And sometimes it wakes
thinking it's just a 1440p monitor, and I don't notice until I get some
text on the screen and think 'that doesn't look right'. That's what
happened this time, and I think only happens after a longer sleep.

Generally the fix in this instance is to switch the monitor off and on
again, and it comes on secure in its identity as a 4K monitor. But as I
switched it off, the session I'd just logged into again was again logged
out.

So I'm guessing Xorg/nVidia/Gnome between them are seeing a *change* in
the monitor configuration attached to the computer. I would say it's
still a bug that its response to that is to bug out, rather than shape
itself around the new reality, but I don't know if that's just something
we'll need Wayland working to deal with more gracefully.

syslog covering the wake-up attached, FWIW (it's quite busy). There's
one segfault in there looking similar to those I saw earlier, from the
moment of trying to wake it up:

Sep 29 13:59:01 fleetfoot kernel: [15526.672810] gnome-shell[26357]:
segfault at 2c ip 7fb47879d434 sp 7ffd919279a8 error 4 in
libmutter-1.so.0.0.0[7fb4786ff000+14]

However grepping for it in syslog I also see it happened twice earlier
today too, while I was away from the computer:

Sep 29 10:59:10 fleetfoot kernel: [ 4736.585186] gnome-shell[1892]: segfault at 
2c ip 7fb1e3549434 sp 7fff343753c8 error 4 in 
libmutter-1.so.0.0.0[7fb1e34ab000+14]
Sep 29 12:26:32 fleetfoot kernel: [ 9977.733747] gnome-shell[21408]: segfault 
at 2c ip 7f9d9f7be434 sp 7ffd5a80ce88 error 4 in 
libmutter-1.so.0.0.0[7f9d9f72+14]

It's possible this was triggered by the cat stepping on the keyboard or
trackpad. I can also see there *wasn't* any segfault at the time I
switched the monitor off and on again, and yet I was still bumped out of
my gnome session.

I dare suggest that even if the monitor's dodgy and even if the driver
is having issues, gnome-shell should not segfault, but fail more
gracefully. (Or is it libmutter that's segfaulting?)

I'm going to try enabling that 'needs root rights' setting.

** Attachment added: "syslog.wakeup"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+attachment/4958680/+files/syslog.wakeup

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm 

[Desktop-packages] [Bug 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

I tried the modeset change first, as that one we'd presumably prefer to
be true anyway one day, whereas giving stuff root that isn't supposed to
have root never feels right. :-)

It worked. I left it to display sleep for a couple of minutes and on
wake I came right back to the desktop. (I don't have screen lock on, so
no password needed.)

In case the length of sleep makes a difference (don't know why it
should) I'll leave it to cut in normally when I go out for a couple of
hours shortly, and see what happens when I get back.

NB: I had tried enabling this before as part of forcing nvidia to use
wayland. I disabled it because (in Wayland) it was terribly sluggish and
in the logs I was seeing nvidia_drm panic and presumably relaunch almost
continuously, on the 4.13 kernel. Nouveau was also failing on that
kernel, even worse, giving just a black screen. That was when I decided
to try harder to have a working Xorg system again. :-) But I hadn't
tried turning modeset on and still use xorg; I didn't know there was a
point in doing so. It seems to be happy.

BTW FWIW

rachel@fleetfoot:~$ apt-cache policy nvidia-384
nvidia-384:
  Installed: 384.90-0ubuntu0~gpu17.10.1
  Candidate: 384.90-0ubuntu0~gpu17.10.1
  Version table:
 *** 384.90-0ubuntu0~gpu17.10.1 500
500 http://ppa.launchpad.net/graphics-drivers/ppa/ubuntu artful/main 
amd64 Packages
100 /var/lib/dpkg/status

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] Re: gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

I can't reproduce this in Xorg on my non-nvidia machine (on which I
normally run Wayland because I can). It appears to be nvidia specific.

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell itself segfaulting
  that's causing the login session to end?

  Not observed on my Wayland system.

  This is not new as of the current version of gnome-shell but I think
  it is relatively recent. Now my hackintosh partition is wrecked by a
  failed upgrade to High Sierra I'm using my Linux system more in
  earnest than before, so I'm hitting this often enough for it to
  provoke a bug report (and much of the time, to just turn all auto
  suspend/display-sleep off and instead shut down the computer when I'm
  leaving it for any length of time).

  The ubuntu bug reporter is not picking this up by itself, so I presume
  a crash report of the sort that uses is not being saved.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.26.0-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Sep 28 14:41:07 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2017-07-30 (59 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720149/+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 1720149] [NEW] gnome-shell segv on wake from display or system sleep

[Rachel Greenham]

Public bug reported:

The observable symptom is that if I go away and let the computer go
either to display sleep or suspend, when I come back and try to wake it
up again, I find myself, after sliding up the lock screen, at the gdm
login screen. I'm logged out, and logging in gives me a fresh new
session. Anything I had open in the previous session is lost. (I'm
getting used to saving stuff before I step away from the computer!)

The only trace I've been able to find is that in /var/log/syslog I see a
line like:

Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
libmutter-1.so.0.0.0[7f6200de4000+14]

This happens at the time of attempted wake, not the time of going to
sleep. It's preceded by a lot of activity from gdm-x-session that I'm
not sure is indicating any error, just the process of waking up. I will
attach a portion of syslog surrounding the whole event in the hope it
helps. (In fact attaching the whole current syslog file - it has two
such events occuring in it, first display sleep/wake at 09:02 this
morning, and secondly (because I was experimenting) a suspend-wake at
14:38 this afternoon.

This is only affecting Xorg sessions, and may possibly only be affecting
where nvidia is in use, I'm not sure about that. But the fact it occurs
on display wake alone, not needing the system itself to have suspended
(I was trying suspend to see if it *avoided* the problem, which it
doesn't), does point the finger in that direction I guess. But
ultimately I'm guessing it's gnome-shell itself segfaulting that's
causing the login session to end?

Not observed on my Wayland system.

This is not new as of the current version of gnome-shell but I think it
is relatively recent. Now my hackintosh partition is wrecked by a failed
upgrade to High Sierra I'm using my Linux system more in earnest than
before, so I'm hitting this often enough for it to provoke a bug report
(and much of the time, to just turn all auto suspend/display-sleep off
and instead shut down the computer when I'm leaving it for any length of
time).

The ubuntu bug reporter is not picking this up by itself, so I presume a
crash report of the sort that uses is not being saved.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-shell 3.26.0-0ubuntu2
ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
Uname: Linux 4.13.0-12-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Sep 28 14:41:07 2017
DisplayManager: gdm3
InstallationDate: Installed on 2017-07-30 (59 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago)

** Affects: gnome-shell (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug artful

** Attachment added: "syslog"
   https://bugs.launchpad.net/bugs/1720149/+attachment/4958094/+files/syslog

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

Title:
  gnome-shell segv on wake from display or system sleep

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  The observable symptom is that if I go away and let the computer go
  either to display sleep or suspend, when I come back and try to wake
  it up again, I find myself, after sliding up the lock screen, at the
  gdm login screen. I'm logged out, and logging in gives me a fresh new
  session. Anything I had open in the previous session is lost. (I'm
  getting used to saving stuff before I step away from the computer!)

  The only trace I've been able to find is that in /var/log/syslog I see
  a line like:

  Sep 28 14:38:44 fleetfoot kernel: [10621.432586] gnome-shell[1863]:
  segfault at 2c ip 7f6200e82434 sp 7ffc46f981c8 error 4 in
  libmutter-1.so.0.0.0[7f6200de4000+14]

  This happens at the time of attempted wake, not the time of going to
  sleep. It's preceded by a lot of activity from gdm-x-session that I'm
  not sure is indicating any error, just the process of waking up. I
  will attach a portion of syslog surrounding the whole event in the
  hope it helps. (In fact attaching the whole current syslog file - it
  has two such events occuring in it, first display sleep/wake at 09:02
  this morning, and secondly (because I was experimenting) a suspend-
  wake at 14:38 this afternoon.

  This is only affecting Xorg sessions, and may possibly only be
  affecting where nvidia is in use, I'm not sure about that. But the
  fact it occurs on display wake alone, not needing the system itself to
  have suspended (I was trying suspend to see if it *avoided* the
  problem, which it doesn't), does point the finger in that direction I
  guess. But ultimately I'm guessing it's gnome-shell 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25, 3.26

[Rachel Greenham]

I just got the mutter upgrade to 3.26.0+20170925~ea214fb-1. My gnome-
shell text was too big! So I reverted my local modification to the
theme's gnome-shell.css ;-) and now the gnome-shell text is the correct
size. I presume this build includes the abovementioned patch.

As this is, I think, the core bug in this bug report, I'm happy to call
that fixed, as of this version.

Aside: I'm still getting too-small (ie: unscaled) text on system
titlebars and some other (non-gnome) apps on login, which then
mysteriously fixes itself when gnome-tweaks is launched, and for the
rest of the session. (Yes I am finding that works now, and not launching
activities view or anything.) I think that probably belongs in a
separate bug report though.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25, 3.26

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything in use or if it was an 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25, 3.26

[Rachel Greenham]

I'm looking forward to seeing how much the upstream changes fixes all
these. Yes, I also saw some of the other transient effects noted above;
the gnome-shell text part of it was just the bit I managed to isolate
and find consistency in. :-)

I had seen the need to apply scaling twice - sometimes, and titlebar
text being unscaled at first, but fixing itself before long, I think
after some particular thing happens that I haven't yet identified. (I
think going to activities view and back fixed it, for instance, but not
sure about that yet.) Some apps still having small text was "fixed" by
setting the old scaling-factor setting, but I knew that wasn't a proper
fix, just hoped it was an observation that might help someone narrow it
down. IIRC I think one of the upstream bugs mentioned relates to that
already.

TBH I never did see any point in changing the text-scaling-factor
setting (the font size multiplier in gnome tweak tool). It just makes
the text that already is right go wrong, so I never found it to be
useful. My only mention of it was to show how the problem, for me
anyway, only affected gnome-shell *text*.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25, 3.26

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

I'd like to give a fresh description of this bug. I think I can do so
more concisely, as it affects gnome-shell. I was in two minds about
whether to report it as a new bug, but honestly feared if I did so it
would just be marked a duplicate of this one and ignored. :-)

Also to update for current versions:

gnome-shell: 3.26.0-0ubuntu1

Under Xorg only (not Wayland), the *text* elements of gnome-shell do not
reflect the scale setting chosen in Settings->Devices->Displays (set to
200% to reproduce), but instead just show the text at the size specified
in gnome-shell.css as if the scale was set to 100%.

The non-text elements of the gnome-shell UI are scaled correctly for the
chosen scale factor, so the size of icons and other elements, and the
placement of them, across the full screen is correct. Only the text size
is wrong.

Workaround 1: Using gsettings org.gnome.desktop.interface text-scaling-
factor to match the selected desktop scale, eg: setting it to 2.00,
corrects the error in gnome-shell, it then looks fine. But this is
useless as a workaround as it also scales up all text on the desktop
that was already scaled correctly.

Workaround 2: If the shell theme in use has a gnome-shell.css file, edit
it to set the stage font-size to double its original. eg: for Arc theme,
as I use, change it from 9pt to 18pt. Obviously you need to change this
whenever you change your desktop scale setting and force the theme to be
reloaded.

Note: This bug affects the default shell theme too, but as far as I can
see, that doesn't have a comparable gnome-shell.css file to fix, so I
don't know how to work around it with that. (I expect it is possible, I
just don't know where.)

Requested fix: in Xorg (it already works in Wayland), font size should
be multiplied by desktop scaling factor. This is a regression because it
used to work when desktop scaling was controlled by gsettings
org.gnome.desktop.interface scaling-factor. I think especially seeing as
fractional scaling didn't make it into gnome 3.26, except in
experimental (and somewhat broken, I did try it) form, it's not
unreasonable to expect non-fractional scaling factors to continue to
work as they did in 3.24, even if controlled from a different setting.
:-)

Slightly wider note on HiDPI:

Forcing wayland on my nvidia system seemed to work for a while, but
actually became more unstable over time as more updates came in, until
as of writing, both nouveau and nvidia proprietary drivers fail
catastrophically under kernel 4.13, apparently crashing in the DRM
supporting code, making the system completely unusable. (I had to ssh in
to recover.)

Well, kms isn't supported under nvidia yet, so I was asking for trouble
trying to force it to work, so this isn't a bug report about that. We
know it's broken. Hence me going back to trying to use Xorg. On my non-
nVidia machine I'm happy with Wayland, but I'm sure I'm not the only
nvidia user out there with a HiDPI monitor who's about to see their
systems become completely unusable under Linux. That's a lot of users
who, right now, can't step up to Wayland, and there's probably more that
have other rational reasons for needing to stick with Xorg right now.

And the vexing thing is, it's so *close* to working pretty well under
Xorg. I've needed to do just three workarounds to get the system back to
being completely usable, even with two monitors of different sizes.

The first is the one described above, to fix gnome-shell's text size.

The second is to explicitly set gsettings org.gnome.desktop.interface
scaling-factor to 2 as well, as some apps, including some gnome apps
like Nautilus, are still obeying that and not the new scale setting in
the control center. I'm sure those apps will come around to the new
setting eventually but they probably should get a separate bug report.

(And will someone *please* tell me where that new setting is? I could
really do with being able to set and read it via a script. Presumably
it's a gsettings value somewhere? But I can't find it.)

The third is to use Xrandr to provide something like fractional scaling
in exactly the manner that macOS does it (so I really don't feel that
it's slumming it, and if it's cheating, rather than "properly" doing
fractional scaling, I'm happy with the cheat to have something that
works *now*). This lets me, for instance, match a 27" 1440p monitor to a
27" 4K monitor both showing desktops of the same size, with scale set in
displays prefs to 200%:

To get a "Looks like 1080p" on a 1440p monitor, equivalent to 133.33...%
scaling:

xrandr --output DP-2 --scale-from 3840x2160 --auto --panning 3840x2160

That then pairs nicely with my 4K monitor at 200% and native resolution.

Or to get a "Looks like 1440p" on a 4K monitor, equivalent to 150%
scaling:

xrandr --output DP-4 --scale-from 5120x2880 --auto --panning 5120x2880

(Actually on nvidia I can set this via the nvidia-settings app, but it's
just doing xrandr as above, so it's not an nvidia-specific method.)

It 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

(though probably *unrelated*, I meant)

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything in use or if it was an intended Unity 8 thing. I didn't
  try anything with it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-session 3.25.90-0ubuntu2
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.6-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Aug 27 13:03:53 2017
  InstallationDate: Installed on 2017-07-30 (27 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-session
  UpgradeStatus: Upgraded to artful on 2017-08-22 (5 days ago)

To manage notifications about this bug 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

Brad's comment: No, I've not seen the act of merely *launching* the
gnome tweak tool fix or alter anything in any way. In fact, though
probably related, the latest update seems to have broken its Extensions
tab, but that's another bug.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything in use or if it was an intended Unity 8 thing. I didn't
  try anything with it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-session 3.25.90-0ubuntu2
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.6-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Aug 27 13:03:53 2017
  InstallationDate: Installed on 2017-07-30 (27 days ago)
  

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

No wait, I've bethought me, actually. Partly brought on by issues with
nvidia/wayland that weren't immediately obvious - nouveau is actually
working better for me, if noticeably a bit more sluggish.

Regarding your comment:

"I think that GNOME Shell 3.25.90 doesn't really support HiDPI for X,
just for Wayland. That may be a regression, but Hi-DPI support in GNOME
Shell has been redesigned to prepare to support fractional scaling in
Wayland in a future release and it may be a lot more complicated for all
that to work well on X too."

Yes, it is a regression, because it was working for *non* fractional
scaling factors, and should reasonably be expected to go on doing so,
even if it's fed from a different setting. (ie: it's now ignoring
org.gnome.desktop.interface scaling-factor)

At the moment, in the gnome control center 3.25, I'm seeing only these
scaling options on my desktop: 100%, 200%, 300%; and on my laptop only
100%, 200%. So we don't currently have fractional scaling right now
anyway, though presumably they're expected to appear at some point. But
it's rational to expect these non-fractional scaling factors to *go on
working* in xorg, and perhaps for only those scaling factors to be
offered via the user interface when in xorg.

And it so nearly does already. As previously described right now it's
only gnome-shell itself, and non-GTK apps, that are not being scaled in
xorg now, where they were before.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

I care slightly less than I used to because I just now persuaded ubuntu
wayland session to run on nvidia-384 proprietary drivers. :-) Something
which I presume is intended to be the default behaviour at some point,
or at least for Nouveau.

So since I reported this bug the move to gnome 3.25 has made it
possible, for me at least, to leave Xorg behind, along with problems
like this. I'm sure you'll have plenty of people who can't, or won't,
for one reason or another, but I'm not one of them. nouveau and nvidia
didn't work with wayland out of the box though; I had to pick up hints
from archlinux forums and suchlike to figure out the necessary
incantations. Presumably that'll get ironed out before release ;-)
because now it's working it seems fine, apart from a minor redraw glitch
while dragging windows larger, which if I'm going to make anything of
I'll report elsewhere.

Final note though: The new 3.25 gnome-control-center was necessary to
actually select the correct desktop scaling factor, and that's still
only in gnome3-staging. (If there's a gsettings key for that new
setting, I can't find it.)

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

... or if you meant does the gnome tweak tool *itself* appear with its
user interface elements at the correct size or too small? It shows at
the correct size, including the titlebar... but actually contrary to my
original report *all* titlebars, both the system and integrated type,
are now being shown with text at the correct size.

In gnome-shell itself - the top bar, the menus and indicators off that,
the applications and activities views - the text is still half-size.
Also in at least some QT apps (eg: nextcloud-client) the text is still
half-size, but GTK-based apps that had half-sized text in the original
bug report, eg: hexchat, sublime text, etc., those now seem fine.

So there is a change since originally reporting. The problem does seem
more restricted just to gnome-shell and non-GTK-based apps.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

The only scaling setting in tweak tool is the one in the Fonts section,
which appears to be exposing org.gnome.desktop.interface text-scaling-
factor. It scales the *text*. It scales all text relative to its
original size. So if I set it to 2.0 the text that's half size will be
the correct size, but the text that already *was* the correct size will
be twice that size, and mostly too big for the windows it's in, as only
the text has been scaled, not most of the other user interface
components.

As described in the original post under the paragraph starting
"gsettings org.gnome.desktop.interface text-scaling-factor"

I've never seen the point of that setting. It's always done that, but
only setting the text scale without the rest of the user interface is
useless.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade to Gnome 3.25

[Rachel Greenham]

Hope I'm not being overly pedantic:

The upgrade that originally broke it, that I applied on Aug 27, did
*not* include gnome-shell. If it had it would have been an obvious
culprit and I would have reported the bug against that instead of gnome-
session. So at the time I originally reported this bug I was still
running gnome-shell 3.24.3-0ubuntu4, according to my apt history.log.

Adding the gnome3-staging PPA on Aug 29 and thus only then getting
gnome-shell 3.25 is what *fixed* the bug, but only for Wayland sessions.
Xorg sessions still showed, and continue to show, the bug. (On my nvidia
machine I'm now using nouveau/wayland to get around it despite other
issues, but that's another story.)

Under Xorg the bug continues to show regardless of driver, ie: on nvidia
proprietary drivers, nouveau, and on my other machine, on intel hd.

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

Title:
  HiDPI support partially broken after upgrade to Gnome 3.25

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade

[Rachel Greenham]

Spoke slightly too soon. It's fine on the Wayland machine, but a bit
more unstable on the nvidia/xorg machine, and I seem to need to select
the scale percentage twice before it properly takes effect, and it looks
like under some circumstances it can revert to the state described in
the original post. Well, that's probably (one reason) why it's still in
staging. :-) So I guess we're already at the point where wayland is more
stable than xorg. Come on nvidia!

-- 
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/1713323

Title:
  HiDPI support partially broken after upgrade

Status in gnome-session package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything in use or if it was an intended Unity 8 thing. I didn't
  try anything with it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-session 3.25.90-0ubuntu2
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade

[Rachel Greenham]

I can confirm that including gnome3-staging solves most of my HiDPI
issues.

Nearly everything seems to work now, according to the setting in the
control panel -> peripherals -> display tab. I don't know what that is
exposing in gsettings (if it is); nothing obvious. It's certainly *not*
org.gnome.desktop.interface scaling-factor, which is unaffected by that
control. But it is working for me.

What still doesn't work:

* Java9 JavaFX, which is still apparently getting its idea of scale purely from 
org.gnome.desktop.interface scaling-factor and works according to that setting. 
That's their bug, presumably.
* QT apps like nextcloud-client may still have issues. When launched at login 
it still shows small fonts, but when relaunched later, it's fine. Little 
wrinkle. It might be the difference between the mysterious new setting being at 
a default-autodetect state, and being set deliberately to 200% now.

-- 
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/1713323

Title:
  HiDPI support partially broken after upgrade

Status in gnome-session package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new 

[Desktop-packages] [Bug 1713323] Re: HiDPI support partially broken after upgrade

[Rachel Greenham]

I was changing the settings from the commandline via gsettings eg:

gsettings set org.gnome.desktop.interface scaling-factor 2
gsettings reset org.gnome.desktop.interface scaling-factor

etc. etc.

That setting never was exposed in the user interface, to my knowledge.
Rather uselessly the text-scaling-factor setting was, and is, in gnome-
tweaks.

I'll put gnome3-staging on one of my systems and see what's what. I
think the hope would be that the gnome-control-center now exposes the
setting that works, whatever that is, presumably not scaling-factor :-)
Let's see...

-- 
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/1713323

Title:
  HiDPI support partially broken after upgrade

Status in gnome-session package in Ubuntu:
  Confirmed

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of gnome-session/gnome-settings packages, which
  may also be implicated, support for scaling on HiDPI screens seems to
  have partially failed. Partially.

  BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but
  when I got to the launchpad page it had pre-filled "gnome-session".
  One presumes there's a reason for that so I've left it, especially as
  this does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
  settings migrations utility in ubuntu-session which I wonder if it
  might be implicated. (TBH looking at it it's not obvious why, though
  it does reset scaling - that's not the problem, the problem is that it
  can't be set back to a combination that works.)

  Reminder all the stuff I'm reporting below as being wrongly-scaled was
  scaled correctly before the update that just took place. Enpass got a
  little help from having some QT env variables set, but that's it.

  Logging in under session "Ubuntu" (Wayland - on a different machine as
  this one being nvidia doesn't support it) or session "Ubuntu on Xorg"
  - also affects GNOME sessions:

  * The fonts in the top bar, and the menus and indicators accessible
  from there, are unscaled. The indicator icons *are* scaled correctly.

  * The fonts in the applications view are unscaled, but the icons and
  layout *are* scaled correctly.

  * Menu titlebar *text* is unscaled. close/minimize/maximize widgets
  *are* scaled correctly, as is the titlebar's size itself.

  * The mouse pointer is unscaled.

  * Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-
  client, hexchat, sublime text 3) are unscaled, or in some cases are a
  bit confused, with some elements correctly scaled, but again fonts are
  not.

  * Also on a personal note, Java 9 JavaFX apps are no longer scaled.
  (In Java 8 it was already broken; I was targeting Java 9 with my
  development partly *because* its HiDPI support was working in Linux.)
  FYI Java 9 JavaFX uses GTK3, Java 8 uses GTK2.

  ## What is working:

  * Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
  Gedit etc. etc.) are all fine. Although note those that use a "normal"
  titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
  show small titlebar text as mentioned above

  * Google Chrome, Thunderbird, Firefox are fine (although the latter
  two aren't being updated for Artful yet, just sayin' ;-)

  ## What happens if I try to fix it:

  gsettings org.gnome.desktop.interface scaling-factor appears to no
  longer be operational. Changing its value from 0 (default), 1 and 2
  appears to have no effect on anything any more. It used to be setting
  it to 2 fixed the few things that weren't right by having it set to
  0... Correction, that *does* fix it for Java 9 JavaFX, it must be
  reading that setting directly. But nothing else reported as broken
  above is affected by changing this setting. Nor in fact does setting
  it to 1 cause gnome apps to be unscaled.

  gsettings org.gnome.desktop.interface cursor-size is working. I can
  set it to 48, double its normal size, to get back normal-sized cursors
  when the pointer is over newly-launched applications. But that's
  obviously a workaround.

  gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
  also exposed in Gnome Tweaks, unsurprisingly makes text twice as
  large. That "fixes" it for the applications that are reported as being
  unscaled above, but it also doubles the size of text in gnome apps as
  well, so those are now far too large for the windows they're in.
  Google Chrome is unaffected by this, as is Java 9 JavaFX, but
  Thunderbird *is* affected.

  I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but
  it seems to have a nonsense-value "@a{si} {}". I have no idea if this
  is anything in use or if it was an intended Unity 8 thing. I didn't
  try anything with it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-session 3.25.90-0ubuntu2
  ProcVersionSignature: Ubuntu 

[Desktop-packages] [Bug 1713323] [NEW] HiDPI support partially broken after upgrade

[Rachel Greenham]

Public bug reported:

After an upgrade this morning that took in the new version of this
package, and a suite of gnome-session/gnome-settings packages, which may
also be implicated, support for scaling on HiDPI screens seems to have
partially failed. Partially.

BTW I invoked the bug reporter with "ubuntu-bug ubuntu-session" but when
I got to the launchpad page it had pre-filled "gnome-session". One
presumes there's a reason for that so I've left it, especially as this
does affect "GNOME" as well as "Ubuntu" sessions. But I do note a
settings migrations utility in ubuntu-session which I wonder if it might
be implicated. (TBH looking at it it's not obvious why, though it does
reset scaling - that's not the problem, the problem is that it can't be
set back to a combination that works.)

Reminder all the stuff I'm reporting below as being wrongly-scaled was
scaled correctly before the update that just took place. Enpass got a
little help from having some QT env variables set, but that's it.

Logging in under session "Ubuntu" (Wayland - on a different machine as
this one being nvidia doesn't support it) or session "Ubuntu on Xorg" -
also affects GNOME sessions:

* The fonts in the top bar, and the menus and indicators accessible from
there, are unscaled. The indicator icons *are* scaled correctly.

* The fonts in the applications view are unscaled, but the icons and
layout *are* scaled correctly.

* Menu titlebar *text* is unscaled. close/minimize/maximize widgets
*are* scaled correctly, as is the titlebar's size itself.

* The mouse pointer is unscaled.

* Non-Gnome apps, either QT or GTK (examples: enpass, nextcloud-client,
hexchat, sublime text 3) are unscaled, or in some cases are a bit
confused, with some elements correctly scaled, but again fonts are not.

* Also on a personal note, Java 9 JavaFX apps are no longer scaled. (In
Java 8 it was already broken; I was targeting Java 9 with my development
partly *because* its HiDPI support was working in Linux.) FYI Java 9
JavaFX uses GTK3, Java 8 uses GTK2.

## What is working:

* Gnome apps (eg: Terminal, Transmission, Settings, Tweaks, Nautilus,
Gedit etc. etc.) are all fine. Although note those that use a "normal"
titlebar (eg: Terminal) rather than an integrated one (eg: Nautilus)
show small titlebar text as mentioned above

* Google Chrome, Thunderbird, Firefox are fine (although the latter two
aren't being updated for Artful yet, just sayin' ;-)

## What happens if I try to fix it:

gsettings org.gnome.desktop.interface scaling-factor appears to no
longer be operational. Changing its value from 0 (default), 1 and 2
appears to have no effect on anything any more. It used to be setting it
to 2 fixed the few things that weren't right by having it set to 0...
Correction, that *does* fix it for Java 9 JavaFX, it must be reading
that setting directly. But nothing else reported as broken above is
affected by changing this setting. Nor in fact does setting it to 1
cause gnome apps to be unscaled.

gsettings org.gnome.desktop.interface cursor-size is working. I can set
it to 48, double its normal size, to get back normal-sized cursors when
the pointer is over newly-launched applications. But that's obviously a
workaround.

gsettings org.gnome.desktop.interface text-scaling-factor set to 2.0,
also exposed in Gnome Tweaks, unsurprisingly makes text twice as large.
That "fixes" it for the applications that are reported as being unscaled
above, but it also doubles the size of text in gnome apps as well, so
those are now far too large for the windows they're in. Google Chrome is
unaffected by this, as is Java 9 JavaFX, but Thunderbird *is* affected.

I noticed a new gsetting: com.ubuntu.user-interface scale-factor, but it
seems to have a nonsense-value "@a{si} {}". I have no idea if this is
anything in use or if it was an intended Unity 8 thing. I didn't try
anything with it.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ubuntu-session 3.25.90-0ubuntu2
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Aug 27 13:03:53 2017
InstallationDate: Installed on 2017-07-30 (27 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: gnome-session
UpgradeStatus: Upgraded to artful on 2017-08-22 (5 days ago)

** Affects: gnome-session (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug artful

-- 
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/1713323

Title:
  HiDPI support partially broken after upgrade

Status in gnome-session package in Ubuntu:
  New

Bug description:
  After an upgrade this morning that took in the new version of this
  package, and a suite of 

[Desktop-packages] [Bug 1712607] [NEW] gnome keyring goes awol after a few logout/logins

[Rachel Greenham]

Public bug reported:

First symptom noticed: That *sometimes* after logging in, owncloud-
client would fail to connect to the server, after a delay asking instead
for a password with the message something like (sorry don't have it in
front of me) "keyring service unavailable".

Second symptom, on trying to start Google Chrome (Chromium too), it
would fail to sign in to my Google account for sync, with a long delay
on startup while it gives up on that.

This never happens on the first login session since the last boot. It
may not happen on the second, but usually by the third login, it
happens. I'm not certain of the pattern except it seems always to be
fine in the *first* session.

A reboot seemed to be needed to resolve this. But just now I tried
instead from the commandline:

gnome-keyring-daemon -r -f

I'm sure -d would do too, but I wanted to watch it. Sure enough on
trying to relaunch owncloud-client, I am *then* asked for my password to
unlock the keyring as, it says, it didn't get unlocked when I logged in.
Then both owncloud-client and google-chrome are now able to sign in, and
I see associated messages from the gnome-keyring-daemon in the terminal
where I'm running it.

Presumably the daemon is not being reliably relaunched when needed, on
successive logins to the gnome desktop.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-keyring 3.20.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.6-0ubuntu6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Aug 23 16:38:04 2017
InstallationDate: Installed on 2017-07-30 (23 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: gnome-keyring
UpgradeStatus: Upgraded to artful on 2017-08-22 (1 days ago)

** Affects: gnome-keyring (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug artful

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

Title:
  gnome keyring goes awol after a few logout/logins

Status in gnome-keyring package in Ubuntu:
  New

Bug description:
  First symptom noticed: That *sometimes* after logging in, owncloud-
  client would fail to connect to the server, after a delay asking
  instead for a password with the message something like (sorry don't
  have it in front of me) "keyring service unavailable".

  Second symptom, on trying to start Google Chrome (Chromium too), it
  would fail to sign in to my Google account for sync, with a long delay
  on startup while it gives up on that.

  This never happens on the first login session since the last boot. It
  may not happen on the second, but usually by the third login, it
  happens. I'm not certain of the pattern except it seems always to be
  fine in the *first* session.

  A reboot seemed to be needed to resolve this. But just now I tried
  instead from the commandline:

  gnome-keyring-daemon -r -f

  I'm sure -d would do too, but I wanted to watch it. Sure enough on
  trying to relaunch owncloud-client, I am *then* asked for my password
  to unlock the keyring as, it says, it didn't get unlocked when I
  logged in. Then both owncloud-client and google-chrome are now able to
  sign in, and I see associated messages from the gnome-keyring-daemon
  in the terminal where I'm running it.

  Presumably the daemon is not being reliably relaunched when needed, on
  successive logins to the gnome desktop.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-keyring 3.20.1-1ubuntu1
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.6-0ubuntu6
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 23 16:38:04 2017
  InstallationDate: Installed on 2017-07-30 (23 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnome-keyring
  UpgradeStatus: Upgraded to artful on 2017-08-22 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1712607/+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 1562033] [NEW] package xinit 1.3.4-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

[Rachel Greenham]

Public bug reported:

During remote do-release-upgrade -d from a wily box.

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: xinit 1.3.4-3
ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
Uname: Linux 4.2.0-34-generic x86_64
NonfreeKernelModules: nvidia
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.96  Sun Nov  8 22:33:28 
PST 2015
 GCC version:  gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
Date: Fri Mar 25 15:06:11 2016
DistUpgraded: 2016-03-25 15:10:36,689 ERROR failed to import apport python 
module, can't generate crash: No module named 'xml.dom'
DistroCodename: xenial
DistroVariant: ubuntu
DkmsStatus:
 bbswitch, 0.8, 4.2.0-34-generic, x86_64: installed
 bbswitch, 0.8, 4.4.0-15-generic, x86_64: installed
 nvidia-340, 340.96, 4.2.0-34-generic, x86_64: installed
 nvidia-340, 340.96, 4.4.0-15-generic, x86_64: installed
ErrorMessage: subprocess installed post-installation script returned error exit 
status 1
GraphicsCard:
 NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA 
controller])
   Subsystem: ZOTAC International (MCO) Ltd. GT218 [GeForce 210] [19da:1044]
InstallationDate: Installed on 2013-03-11 (1109 days ago)
InstallationMedia: Ubuntu 12.04.2 LTS "Precise Pangolin" - Release amd64 
(20130213)
MachineType: System manufacturer System Product Name
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-34-generic 
root=UUID=467f6a66-74b5-4070-90db-2150245db2cf ro quiet splash radeon.audio=1 
radeon.dpm=1 clocksource=hpet hpet=enable nomdmonddf nomdmonisw nomdmonddf 
nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw nomdmonddf nomdmonisw 
nomdmonddf nomdmonisw nomdmonddf nomdmonisw
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1
 apt  1.2.7
SourcePackage: xinit
Title: package xinit 1.3.4-3 failed to install/upgrade: subprocess installed 
post-installation script returned error exit status 1
UpgradeStatus: Upgraded to xenial on 2016-03-25 (0 days ago)
dmi.bios.date: 08/06/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0803
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: P6X58D-E
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0803:bd08/06/2012:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP6X58D-E:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz 1:0.9.12.2+16.04.20160318-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.67-1
version.libgl1-mesa-dri: libgl1-mesa-dri 11.1.2-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 11.1.2-1ubuntu2
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.18.1-1ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.6.1-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160218-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Thu Mar 17 18:05:50 2016
xserver.configfile: default
xserver.devices:
 
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 
xserver.version: 2:1.17.2-1ubuntu9.1

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


** Tags: amd64 apport-package possible-manual-nvidia-install ubuntu xenial

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

Title:
  package xinit 1.3.4-3 failed to install/upgrade: subprocess installed
  post-installation script returned error exit status 1

Status in xinit package in Ubuntu:
  New

Bug description:
  During remote do-release-upgrade -d from a wily box.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: xinit 1.3.4-3
  ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
  Uname: Linux 4.2.0-34-generic x86_64
  NonfreeKernelModules: nvidia
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.96  Sun Nov  8 22:33:28 
PST 2015
   GCC version:  gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  Date: Fri Mar 25 15:06:11 2016
  DistUpgraded: 2016-03-25 15:10:36,689 ERROR failed to import apport python 
module, can't generate crash: No module named 'xml.dom'
  DistroCodename: xenial
  DistroVariant: ubuntu
  DkmsStatus:
   

[Desktop-packages] [Bug 1288604] Re: No option to set proxy for network

[Rachel Greenham]

OSX and iOS, for instance, let you set this differently for each
network, but there's just the one global setting in Ubuntu. So if you
have a laptop that is only intermittently joined to a network requiring
a proxy, you have to go to network settings every time you join that
network and set the proxy settings again, and unset them again when you
leave...

Needs to be a tab in Edit Connection, part of network manager.

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

Title:
  No option to set proxy for network

Status in “network-manager-applet” package in Ubuntu:
  Confirmed

Bug description:
  Nothing on the dialog to be able to setup a proxy per network.

  This is required the more mobile the world gets and it takes a lot of
  time to get browsers, apt, Skype etc. setup when moving from one
  network to another.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: network-manager-gnome 0.9.8.8-0ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-15.35-generic 3.13.5
  Uname: Linux 3.13.0-15-generic i686
  ApportVersion: 2.13.2-0ubuntu5
  Architecture: i386
  CurrentDesktop: Unity
  Date: Thu Mar  6 10:19:31 2014
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-03-05 (1 days ago)
  InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha i386 (20140304)
  IpRoute:
   default via 192.168.0.1 dev wlan0  proto static 
   192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.2  metric 9
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
   WimaxEnabled=true
  SourcePackage: network-manager-applet
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-dev:
   DEVICE TYPE  STATE DBUS-PATH 
 
   eth0   802-3-ethernetunavailable   
/org/freedesktop/NetworkManager/Devices/1  
   wlan0  802-11-wireless   connected 
/org/freedesktop/NetworkManager/Devices/0
  nmcli-nm:
   RUNNING VERSIONSTATE   NET-ENABLED   WIFI-HARDWARE   
WIFI   WWAN-HARDWARE   WWAN  
   running 0.9.8.8connected   enabled   enabled 
enabledenabled disabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1288604/+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 1307947] [NEW] Shockwave Flash has crashed

[Rachel Greenham]

Public bug reported:

... that's what I get, every time chromium 34 tries to run a flash,
since the update was applied this morning. This was fine with chromium
33. Flash is also still happy to run in firefox.

No SEGV to trigger apport, and I can't see an obvious way to get more
debug information. Just Shockwave Flash has crashed in a grey bar at
the top of the page, and a sad-face jigsaw piece in place of the flash
element itself.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: chromium-browser 34.0.1847.116-0ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 15 10:17:38 2014
Desktop-Session:
 DESKTOP_SESSION = ubuntu
 XDG_CONFIG_DIRS = /etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
 XDG_DATA_DIRS = 
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
DetectedPlugins:
 
Env:
 MOZ_PLUGIN_PATH = None
 LD_LIBRARY_PATH = None
InstallationDate: Installed on 2014-03-08 (37 days ago)
InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 (20131016.1)
SourcePackage: chromium-browser
UpgradeStatus: Upgraded to trusty on 2014-03-10 (35 days ago)
chromium-default: CHROMIUM_FLAGS=
gconf-keys: /desktop/gnome/applications/browser/exec = 
b'/usr/bin/chromium-browser\n'/desktop/gnome/url-handlers/https/command = 
b'/usr/bin/chromium-browser %s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'/usr/bin/chromium-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
modified.conffile..etc.default.chromium.browser: [deleted]

** Affects: chromium-browser (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

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

Title:
  Shockwave Flash has crashed

Status in “chromium-browser” package in Ubuntu:
  New

Bug description:
  ... that's what I get, every time chromium 34 tries to run a flash,
  since the update was applied this morning. This was fine with chromium
  33. Flash is also still happy to run in firefox.

  No SEGV to trigger apport, and I can't see an obvious way to get more
  debug information. Just Shockwave Flash has crashed in a grey bar at
  the top of the page, and a sad-face jigsaw piece in place of the flash
  element itself.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: chromium-browser 34.0.1847.116-0ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Apr 15 10:17:38 2014
  Desktop-Session:
   DESKTOP_SESSION = ubuntu
   XDG_CONFIG_DIRS = /etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
   XDG_DATA_DIRS = 
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
  DetectedPlugins:
   
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  InstallationDate: Installed on 2014-03-08 (37 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: chromium-browser
  UpgradeStatus: Upgraded to trusty on 2014-03-10 (35 days ago)
  chromium-default: CHROMIUM_FLAGS=
  gconf-keys: /desktop/gnome/applications/browser/exec = 
b'/usr/bin/chromium-browser\n'/desktop/gnome/url-handlers/https/command = 
b'/usr/bin/chromium-browser %s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'/usr/bin/chromium-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
  modified.conffile..etc.default.chromium.browser: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1307947/+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 1307947] Re: Shockwave Flash has crashed

[Rachel Greenham]

Tried installing pepperflashplugin-nonfree.

*That* then works, but now chromium's Use GTK Theme is broken, it's
not themed correctly. Also there's a blue a on the menu button.

** Attachment added: chromium-mistheme.png
   
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1307947/+attachment/4084275/+files/chromium-mistheme.png

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

Title:
  Shockwave Flash has crashed

Status in “chromium-browser” package in Ubuntu:
  New

Bug description:
  ... that's what I get, every time chromium 34 tries to run a flash,
  since the update was applied this morning. This was fine with chromium
  33. Flash is also still happy to run in firefox.

  No SEGV to trigger apport, and I can't see an obvious way to get more
  debug information. Just Shockwave Flash has crashed in a grey bar at
  the top of the page, and a sad-face jigsaw piece in place of the flash
  element itself.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: chromium-browser 34.0.1847.116-0ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Apr 15 10:17:38 2014
  Desktop-Session:
   DESKTOP_SESSION = ubuntu
   XDG_CONFIG_DIRS = /etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
   XDG_DATA_DIRS = 
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
  DetectedPlugins:
   
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  InstallationDate: Installed on 2014-03-08 (37 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: chromium-browser
  UpgradeStatus: Upgraded to trusty on 2014-03-10 (35 days ago)
  chromium-default: CHROMIUM_FLAGS=
  gconf-keys: /desktop/gnome/applications/browser/exec = 
b'/usr/bin/chromium-browser\n'/desktop/gnome/url-handlers/https/command = 
b'/usr/bin/chromium-browser %s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'/usr/bin/chromium-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
  modified.conffile..etc.default.chromium.browser: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1307947/+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 1307947] Re: Chromium use-gtk-theme doesn't apply theme

[Rachel Greenham]

when i tried it again on a separate machine also running trusty beta, i
discovered the theming issue is completely unrelated to the flash issue.
On *that* machine, i didn't install pepper flash, but i *did* reboot,
thinking the background instance of chromium-browser launched by the
session was confusing things. After the reboot, the theming issue was
present; so installing pepper flash had nothing to do with that.

The screenshot should show it btw, being a shot of the top right of the
window, showing the wrong folder icons for the unity ambiance theme, the
blue 'a' over the menu button, the gradient on the tab bar breaking it
visually from the titlebar.

On that machine I didn't get the Shockwave Flash has crashed error,
rather it behaved as if flash wasn't installed at all, with the flash
elements just having the You need to install Flash Player to play this
content and a link to download it from adobe. Meanwhile, flash is
working in firefox. I believe adobe flash is installed on that system
just the same as it is on the first one, but for some reason on one
system it would just crash post-upgrade, on the other it appeared to be
absent from chromium.

I've resolved it for myself by installing google chrome itself again.
I'd switched to chromium because apt was giving me grief with google
chrome repo's keys, but that seems to be resolved now, i think, somehow
:-} But I still have chromium-browser installed alongside for testing.

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

Title:
  Chromium use-gtk-theme doesn't apply theme

Status in “chromium-browser” package in Ubuntu:
  Incomplete

Bug description:
  ... that's what I get, every time chromium 34 tries to run a flash,
  since the update was applied this morning. This was fine with chromium
  33. Flash is also still happy to run in firefox.

  No SEGV to trigger apport, and I can't see an obvious way to get more
  debug information. Just Shockwave Flash has crashed in a grey bar at
  the top of the page, and a sad-face jigsaw piece in place of the flash
  element itself.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: chromium-browser 34.0.1847.116-0ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Apr 15 10:17:38 2014
  Desktop-Session:
   DESKTOP_SESSION = ubuntu
   XDG_CONFIG_DIRS = /etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
   XDG_DATA_DIRS = 
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
  DetectedPlugins:
   
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  InstallationDate: Installed on 2014-03-08 (37 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: chromium-browser
  UpgradeStatus: Upgraded to trusty on 2014-03-10 (35 days ago)
  chromium-default: CHROMIUM_FLAGS=
  gconf-keys: /desktop/gnome/applications/browser/exec = 
b'/usr/bin/chromium-browser\n'/desktop/gnome/url-handlers/https/command = 
b'/usr/bin/chromium-browser %s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'/usr/bin/chromium-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
  modified.conffile..etc.default.chromium.browser: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1307947/+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 1291359] [NEW] multiscreen spanning wallpaper does not span on lock screen

[Rachel Greenham]

Public bug reported:

(It has same look as unity-greeter in lightdm but am given to believe
lock screen is handled by gnome-screensaver; move if i'm wrong! lightdm
seems to get it wrong a different way.)

If, having made a wide wallpaper to span multiple monitors, and having
set it as your wallpaper with type Span in Appearance settings, you
then go to the new Lock screen...

... you will see that instead of that wide wallpaper spanning all
monitors, you get the image scaled down to be shown whole on *each*
monitor. As shown in screenshot attached.

It needs to honour the appearance settings in this regard.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnome-screensaver 3.6.1-0ubuntu10
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Mar 12 13:02:42 2014
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GsettingsGnomeSession:
 org.gnome.desktop.session session-name 'ubuntu'
 org.gnome.desktop.session idle-delay uint32 300
InstallationDate: Installed on 2014-03-08 (3 days ago)
InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 (20131016.1)
SourcePackage: gnome-screensaver
UpgradeStatus: Upgraded to trusty on 2014-03-10 (1 days ago)

** Affects: gnome-screensaver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

** Attachment added: shows spanning wallpaper not spanning in lock screen
   
https://bugs.launchpad.net/bugs/1291359/+attachment/4020040/+files/span-lock.png

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

Title:
  multiscreen spanning wallpaper does not span on lock screen

Status in “gnome-screensaver” package in Ubuntu:
  New

Bug description:
  (It has same look as unity-greeter in lightdm but am given to believe
  lock screen is handled by gnome-screensaver; move if i'm wrong!
  lightdm seems to get it wrong a different way.)

  If, having made a wide wallpaper to span multiple monitors, and having
  set it as your wallpaper with type Span in Appearance settings, you
  then go to the new Lock screen...

  ... you will see that instead of that wide wallpaper spanning all
  monitors, you get the image scaled down to be shown whole on *each*
  monitor. As shown in screenshot attached.

  It needs to honour the appearance settings in this regard.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: gnome-screensaver 3.6.1-0ubuntu10
  ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
  Uname: Linux 3.13.0-17-generic x86_64
  ApportVersion: 2.13.3-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Mar 12 13:02:42 2014
  GnomeSessionIdleInhibited: No
  GnomeSessionInhibitors: None
  GsettingsGnomeSession:
   org.gnome.desktop.session session-name 'ubuntu'
   org.gnome.desktop.session idle-delay uint32 300
  InstallationDate: Installed on 2014-03-08 (3 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: gnome-screensaver
  UpgradeStatus: Upgraded to trusty on 2014-03-10 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1291359/+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 1291362] [NEW] Apps locked to launcher only launch once per session.

[Rachel Greenham]

Public bug reported:

In Trusty:

An application that has been locked to launcher, (including those
there by default) can only be clicked on once per session to actually
launch the application. After that it's unresponsive to clicks, although
right-click actions work.

Seems to affect all apps, including Files.

To repeat, for any application not already on the launcher bar:

Launch the application using the dash.

Right-click on its launcher icon and select Lock to Launcher

Quit the application.

Click on its launcher icon. It should launch again.

Quit it again.

Click on its launcher icon again. It won't work this time. It looks like
dragging would work, but its operation as a launcher will not.

NB: I haven't installed any hacks eg: click-to-minimise. Seen this on
two systems upgraded from saucy to trusty. (One with AMD graphics, one
with Intel, so I doubt that's relevant either.)

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unity 7.1.2+14.04.20140311-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CurrentDesktop: Unity
Date: Wed Mar 12 13:10:56 2014
InstallationDate: Installed on 2014-03-08 (3 days ago)
InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 (20131016.1)
SourcePackage: unity
UpgradeStatus: Upgraded to trusty on 2014-03-10 (1 days ago)

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


** Tags: amd64 apport-bug trusty

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

Title:
  Apps locked to launcher only launch once per session.

Status in “unity” package in Ubuntu:
  New

Bug description:
  In Trusty:

  An application that has been locked to launcher, (including those
  there by default) can only be clicked on once per session to actually
  launch the application. After that it's unresponsive to clicks,
  although right-click actions work.

  Seems to affect all apps, including Files.

  To repeat, for any application not already on the launcher bar:

  Launch the application using the dash.

  Right-click on its launcher icon and select Lock to Launcher

  Quit the application.

  Click on its launcher icon. It should launch again.

  Quit it again.

  Click on its launcher icon again. It won't work this time. It looks
  like dragging would work, but its operation as a launcher will not.

  NB: I haven't installed any hacks eg: click-to-minimise. Seen this on
  two systems upgraded from saucy to trusty. (One with AMD graphics, one
  with Intel, so I doubt that's relevant either.)

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: unity 7.1.2+14.04.20140311-0ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
  Uname: Linux 3.13.0-17-generic x86_64
  ApportVersion: 2.13.3-0ubuntu1
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CurrentDesktop: Unity
  Date: Wed Mar 12 13:10:56 2014
  InstallationDate: Installed on 2014-03-08 (3 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: unity
  UpgradeStatus: Upgraded to trusty on 2014-03-10 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1291362/+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 1287326] Re: [FFe] Include Temporal Deinterlacer into libvdpau1-drivers-mesa

[Rachel Greenham]

I've got to admit, i'm struggling to see the improvement, and I *want*
to, agreeing with the request of this bug.

But perhaps the conversion to jpeg is wiping it out? Should be using a
lossless capture there, I reckon.

-- 
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/1287326

Title:
  [FFe] Include Temporal Deinterlacer into libvdpau1-drivers-mesa

Status in “mesa” package in Ubuntu:
  Triaged

Bug description:
  Beginning with Ubuntu 14.04 mesa will be shipping with vdpau drivers
  that can be used by e.g. radeon / radeonsi OSS drivers. This allows
  low power systems, like AMD E350, Kabini and so on to playback Full HD
  h264, vc1, mpeg4 and mpeg2 videos.

  Sadly the world is not only progressive. LiveTV is most of the time
  broadcasted as 1080i h264 or 576i mpeg2, which means, that it has to
  be deinterlaced after decoding. In current mesa vdpau (as is in 10.1)
  code only simple Bobbing [a] is implemented. This low quality method
  produces one full frame out of every field. This introduces flickering
  first and last line, when not taking care to cut those correctly.

  Grigori Goronzy (zgreg) has developed a high quality / state of the
  art Temporal deinterlacer [1][a] for mesa, which introduces far better
  quality than simple bobbing would do.

  This deinterlacer was already included into mesa master and was
  furthermore tested since more than 4 months via a special ppa in
  combination with xbmc [2]. This ppa was used by some thousand unique
  people.

  We would really like to see this deinterlacer in Ubuntu 14.04. This
  would make the new version a great basis for every htpc out there.

  I will attach the current patches, fetched via git format-patch out of
  mesa git tree.

  [a] http://en.wikipedia.org/wiki/Deinterlacing (Motion Adaptive vs. Bobbing)
  [1] Original Patch: 
http://anzwix.com/a/Mesa/StvdpauAddSupportForDEINTERLACETEMPORAL
  [2] http://forum.xbmc.org/showthread.php?tid=174854

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1287326/+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 1287326] Re: [FFe] Include Temporal Deinterlacer into libvdpau1-drivers-mesa

[Rachel Greenham]

ok, i *can* see the improvement if i view the images at full size
switching between browser tabs (which the site's own page doesn't seem
to let you do, bizarrely; initially i'd just thought they were SD
captures). Yes, 2nd image is better; but *still* it would probably be
better reflection if not captured lossily.

-- 
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/1287326

Title:
  [FFe] Include Temporal Deinterlacer into libvdpau1-drivers-mesa

Status in “mesa” package in Ubuntu:
  Triaged

Bug description:
  Beginning with Ubuntu 14.04 mesa will be shipping with vdpau drivers
  that can be used by e.g. radeon / radeonsi OSS drivers. This allows
  low power systems, like AMD E350, Kabini and so on to playback Full HD
  h264, vc1, mpeg4 and mpeg2 videos.

  Sadly the world is not only progressive. LiveTV is most of the time
  broadcasted as 1080i h264 or 576i mpeg2, which means, that it has to
  be deinterlaced after decoding. In current mesa vdpau (as is in 10.1)
  code only simple Bobbing [a] is implemented. This low quality method
  produces one full frame out of every field. This introduces flickering
  first and last line, when not taking care to cut those correctly.

  Grigori Goronzy (zgreg) has developed a high quality / state of the
  art Temporal deinterlacer [1][a] for mesa, which introduces far better
  quality than simple bobbing would do.

  This deinterlacer was already included into mesa master and was
  furthermore tested since more than 4 months via a special ppa in
  combination with xbmc [2]. This ppa was used by some thousand unique
  people.

  We would really like to see this deinterlacer in Ubuntu 14.04. This
  would make the new version a great basis for every htpc out there.

  I will attach the current patches, fetched via git format-patch out of
  mesa git tree.

  [a] http://en.wikipedia.org/wiki/Deinterlacing (Motion Adaptive vs. Bobbing)
  [1] Original Patch: 
http://anzwix.com/a/Mesa/StvdpauAddSupportForDEINTERLACETEMPORAL
  [2] http://forum.xbmc.org/showthread.php?tid=174854

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1287326/+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 1193522] Re: nautilus crashed with SIGSEGV in gtk_action_get_name()

[Rachel Greenham]

don't even care any more; switched to ownCloud. :-)

-- 
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/1193522

Title:
  nautilus crashed with SIGSEGV in gtk_action_get_name()

Status in Nautilus:
  Unknown
Status in “nautilus” package in Ubuntu:
  Invalid
Status in “nautilus-dropbox” package in Ubuntu:
  Triaged

Bug description:
  This happens everytime I open a file from the Dropbox folder and
  Dropbox is running.

  ProblemType: Crash
  DistroRelease: Ubuntu 13.10
  Package: nautilus 1:3.8.2-0ubuntu1
  ProcVersionSignature: Ubuntu 3.9.0-3.8-generic 3.9.4
  Uname: Linux 3.9.0-3-generic x86_64
  ApportVersion: 2.10.2-0ubuntu2
  Architecture: amd64
  CrashCounter: 1
  Date: Sat Jun 22 02:49:40 2013
  ExecutablePath: /usr/bin/nautilus
  GsettingsChanges:
   b'org.gnome.nautilus.window-state' b'geometry' b'866x530+179+506'
   b'org.gnome.nautilus.window-state' b'maximized' b'true'
  InstallationDate: Installed on 2012-03-30 (448 days ago)
  InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Beta amd64 (20120328)
  MarkForUpload: True
  ProcCmdline: nautilus --new-window
  SegvAnalysis:
   Segfault happened at: 0x7fb1f71239a6 gtk_action_get_name+22:   cmp
%rax,(%rdx)
   PC (0x7fb1f71239a6) ok
   source %rax ok
   destination (%rdx) (0x) not located in a known VMA region 
(needed writable region)!
  SegvReason: writing unknown VMA
  Signal: 11
  SourcePackage: nautilus
  StacktraceTop:
   gtk_action_get_name () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
   ?? ()
   ?? ()
   ?? ()
   ?? ()
  Title: nautilus crashed with SIGSEGV in gtk_action_get_name()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo
  mtime.conffile..etc.xdg.autostart.nautilus.autostart.desktop: 
2012-12-23T02:22:01.854256

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/1193522/+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 1222776] [NEW] gnome-disk-utlity and launcher/nautilus lost all raid awareness

[Rachel Greenham]

Public bug reported:

Expected: Raid arrays have appropriate icons in launcher/disk utility etc. Used 
to be there in Precise
Actual: Icons are missing. Raid array has generic drive icon.

Compare the first screenshot, taken before upgrading from Precise to
Quantal, and the second, taken afterwards.

There is a RAID1 array, created using the disk utility, which shows up
with an appropriate icon on the launcher and matching emblem in
nautilus, as well as showing up properly in gnome-disk-utility itself.

In the second screenshot, the raid array now has a generic drive icon in
the launcher, just a folder icon in nautilus, and gnome-disk-utility
itself seems to have no understanding at all that it has a raid device
on its hands, nor any options any more to create new ones.

It kind of looks like a deliberate decision was made to have no desktop
support for raid any more, but I haven't found any discussion of this,
so at worst, some kind of explanation?

I don't even really care if gnome-disk-utility can be used to *manage*
raid arrays; what launched me on this quest was simply wanting to have
the raid *icon* in the launcher for the mounted filesystem. It used to
be there in precise; on upgrade, it vanishes.

Actually encountered on a proper machine which I upgraded from precise
to raring with barely a pause in quantal on the way through. Repeated in
simpler form in vmware to check whether the loss happened from
precise-quantal or quantal-raring. Seems to be the former, hence
reporting it here.

(Simply restoring the gdu_ icons for raid to a raring system doesn't
make it, or nautilus, use them. I confess I don't really know how this
works. Setting the mount point directory's icon in nautilus doesn't
affect the launcher icon, which is the one I actually want fixed.)

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gnome-disk-utility 3.6.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-40.62-generic 3.5.7.20
Uname: Linux 3.5.0-40-generic x86_64
ApportVersion: 2.6.1-0ubuntu12
Architecture: amd64
Date: Mon Sep  9 12:40:13 2013
InstallationDate: Installed on 2013-09-09 (0 days ago)
InstallationMedia: Ubuntu 12.04.2 LTS Precise Pangolin - Release amd64 
(20130213)
MarkForUpload: True
SourcePackage: gnome-disk-utility
UpgradeStatus: Upgraded to quantal on 2013-09-09 (0 days ago)

** Affects: gnome-disk-utility (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug quantal running-unity

** Attachment added: first screenshot showing raid icons etc. 2nd screenshot 
to follow
   
https://bugs.launchpad.net/bugs/1222776/+attachment/3810799/+files/Screen%20Shot%202013-09-09%20at%2011.55.47.png

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

Title:
  gnome-disk-utlity and launcher/nautilus lost all raid awareness

Status in “gnome-disk-utility” package in Ubuntu:
  New

Bug description:
  Expected: Raid arrays have appropriate icons in launcher/disk utility etc. 
Used to be there in Precise
  Actual: Icons are missing. Raid array has generic drive icon.

  Compare the first screenshot, taken before upgrading from Precise to
  Quantal, and the second, taken afterwards.

  There is a RAID1 array, created using the disk utility, which shows up
  with an appropriate icon on the launcher and matching emblem in
  nautilus, as well as showing up properly in gnome-disk-utility itself.

  In the second screenshot, the raid array now has a generic drive icon
  in the launcher, just a folder icon in nautilus, and gnome-disk-
  utility itself seems to have no understanding at all that it has a
  raid device on its hands, nor any options any more to create new ones.

  It kind of looks like a deliberate decision was made to have no
  desktop support for raid any more, but I haven't found any discussion
  of this, so at worst, some kind of explanation?

  I don't even really care if gnome-disk-utility can be used to *manage*
  raid arrays; what launched me on this quest was simply wanting to have
  the raid *icon* in the launcher for the mounted filesystem. It used to
  be there in precise; on upgrade, it vanishes.

  Actually encountered on a proper machine which I upgraded from precise
  to raring with barely a pause in quantal on the way through. Repeated
  in simpler form in vmware to check whether the loss happened from
  precise-quantal or quantal-raring. Seems to be the former, hence
  reporting it here.

  (Simply restoring the gdu_ icons for raid to a raring system doesn't
  make it, or nautilus, use them. I confess I don't really know how this
  works. Setting the mount point directory's icon in nautilus doesn't
  affect the launcher icon, which is the one I actually want fixed.)

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: gnome-disk-utility 3.6.1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.5.0-40.62-generic 3.5.7.20
  Uname: Linux 3.5.0-40-generic 

[Desktop-packages] [Bug 1222776] Re: gnome-disk-utlity and launcher/nautilus lost all raid awareness

[Rachel Greenham]

Second screenshot attached, showing same system post-quantal upgrade,
missing all raid icons and apparent desktop functionality.

** Attachment added: Screen Shot 2013-09-09 at 12.39.54.png
   
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1222776/+attachment/3810802/+files/Screen%20Shot%202013-09-09%20at%2012.39.54.png

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

Title:
  gnome-disk-utlity and launcher/nautilus lost all raid awareness

Status in “gnome-disk-utility” package in Ubuntu:
  New

Bug description:
  Expected: Raid arrays have appropriate icons in launcher/disk utility etc. 
Used to be there in Precise
  Actual: Icons are missing. Raid array has generic drive icon.

  Compare the first screenshot, taken before upgrading from Precise to
  Quantal, and the second, taken afterwards.

  There is a RAID1 array, created using the disk utility, which shows up
  with an appropriate icon on the launcher and matching emblem in
  nautilus, as well as showing up properly in gnome-disk-utility itself.

  In the second screenshot, the raid array now has a generic drive icon
  in the launcher, just a folder icon in nautilus, and gnome-disk-
  utility itself seems to have no understanding at all that it has a
  raid device on its hands, nor any options any more to create new ones.

  It kind of looks like a deliberate decision was made to have no
  desktop support for raid any more, but I haven't found any discussion
  of this, so at worst, some kind of explanation?

  I don't even really care if gnome-disk-utility can be used to *manage*
  raid arrays; what launched me on this quest was simply wanting to have
  the raid *icon* in the launcher for the mounted filesystem. It used to
  be there in precise; on upgrade, it vanishes.

  Actually encountered on a proper machine which I upgraded from precise
  to raring with barely a pause in quantal on the way through. Repeated
  in simpler form in vmware to check whether the loss happened from
  precise-quantal or quantal-raring. Seems to be the former, hence
  reporting it here.

  (Simply restoring the gdu_ icons for raid to a raring system doesn't
  make it, or nautilus, use them. I confess I don't really know how this
  works. Setting the mount point directory's icon in nautilus doesn't
  affect the launcher icon, which is the one I actually want fixed.)

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: gnome-disk-utility 3.6.1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.5.0-40.62-generic 3.5.7.20
  Uname: Linux 3.5.0-40-generic x86_64
  ApportVersion: 2.6.1-0ubuntu12
  Architecture: amd64
  Date: Mon Sep  9 12:40:13 2013
  InstallationDate: Installed on 2013-09-09 (0 days ago)
  InstallationMedia: Ubuntu 12.04.2 LTS Precise Pangolin - Release amd64 
(20130213)
  MarkForUpload: True
  SourcePackage: gnome-disk-utility
  UpgradeStatus: Upgraded to quantal on 2013-09-09 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1222776/+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 1222776] Re: gnome-disk-utlity and launcher/nautilus lost all raid awareness

[Rachel Greenham]

OK, I'll upgrade this test vm all the way to saucy and see what happens.

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

Title:
  gnome-disk-utlity and launcher/nautilus lost all raid awareness

Status in “gnome-disk-utility” package in Ubuntu:
  Fix Released

Bug description:
  Expected: Raid arrays have appropriate icons in launcher/disk utility etc. 
Used to be there in Precise
  Actual: Icons are missing. Raid array has generic drive icon.

  Compare the first screenshot, taken before upgrading from Precise to
  Quantal, and the second, taken afterwards.

  There is a RAID1 array, created using the disk utility, which shows up
  with an appropriate icon on the launcher and matching emblem in
  nautilus, as well as showing up properly in gnome-disk-utility itself.

  In the second screenshot, the raid array now has a generic drive icon
  in the launcher, just a folder icon in nautilus, and gnome-disk-
  utility itself seems to have no understanding at all that it has a
  raid device on its hands, nor any options any more to create new ones.

  It kind of looks like a deliberate decision was made to have no
  desktop support for raid any more, but I haven't found any discussion
  of this, so at worst, some kind of explanation?

  I don't even really care if gnome-disk-utility can be used to *manage*
  raid arrays; what launched me on this quest was simply wanting to have
  the raid *icon* in the launcher for the mounted filesystem. It used to
  be there in precise; on upgrade, it vanishes.

  Actually encountered on a proper machine which I upgraded from precise
  to raring with barely a pause in quantal on the way through. Repeated
  in simpler form in vmware to check whether the loss happened from
  precise-quantal or quantal-raring. Seems to be the former, hence
  reporting it here.

  (Simply restoring the gdu_ icons for raid to a raring system doesn't
  make it, or nautilus, use them. I confess I don't really know how this
  works. Setting the mount point directory's icon in nautilus doesn't
  affect the launcher icon, which is the one I actually want fixed.)

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: gnome-disk-utility 3.6.1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.5.0-40.62-generic 3.5.7.20
  Uname: Linux 3.5.0-40-generic x86_64
  ApportVersion: 2.6.1-0ubuntu12
  Architecture: amd64
  Date: Mon Sep  9 12:40:13 2013
  InstallationDate: Installed on 2013-09-09 (0 days ago)
  InstallationMedia: Ubuntu 12.04.2 LTS Precise Pangolin - Release amd64 
(20130213)
  MarkForUpload: True
  SourcePackage: gnome-disk-utility
  UpgradeStatus: Upgraded to quantal on 2013-09-09 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1222776/+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