[Desktop-packages] [Bug 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

@Jonas: If KDE is launching apps in the same way gnome-shell was, it is
inherently racy. It needs to make sure the child process is in the new
cgroup before executing the application.

Doing the cgroup move after the app is already running causes problems
if the application itself wants to configure cgroups, and could let
child processes of the app itself escape the cgroup if they are created
before the launcher tries to move the app.

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in GNOME Shell:
  New
Status in KDE Base:
  New
Status in gnome-desktop package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in kio package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Opinion

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/2011806/+subscriptions


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

[Desktop-packages] [Bug 2018504] [NEW] cups-browsed is using an excessive amount of CPU

[James Henstridge]

Public bug reported:

It could be a problem with the network, but I'm seeing cups-browsed
appearing to keep one CPU core busy. According to systemctl, it has used
51 minutes of CPU time since being started 6 hours ago (the laptop has
been suspended a few times in that time):

 Active: active (running) since Thu 2023-05-04 08:41:36 CEST; 6h ago
   Main PID: 68281 (cups-browsed)
  Tasks: 4 (limit: 18785)
 Memory: 7.0M
CPU: 51min 32.735s

This seems surprising, since I'd only expect it to be doing something
when printers are advertised over mDNS.

It may be unrelated, but I'm also seeing warnings like the following in
the journal:

May 04 14:26:11 lrrr cups-browsed[68281]: Source ID 1207266864 was not 
found when attempting to remove it
May 04 14:26:11 lrrr cups-browsed[68281]: Source ID 1207318247 was not 
found when attempting to remove it
May 04 14:26:11 lrrr cups-browsed[68281]: Source ID 1207362184 was not 
found when attempting to remove it
May 04 14:26:11 lrrr cups-browsed[68281]: Source ID 1207375185 was not 
found when attempting to remove it
May 04 14:38:28 lrrr cups-browsed[68281]: Source ID 1303173242 was not 
found when attempting to remove it
May 04 14:38:28 lrrr cups-browsed[68281]: Source ID 1303188526 was not 
found when attempting to remove it
May 04 14:38:28 lrrr cups-browsed[68281]: Source ID 1303229832 was not 
found when attempting to remove it
May 04 14:38:28 lrrr cups-browsed[68281]: Source ID 1303249965 was not 
found when attempting to remove it
May 04 14:38:28 lrrr cups-browsed[68281]: Source ID 1303265399 was not 
found when attempting to remove it
May 04 14:38:39 lrrr cups-browsed[68281]: Source ID 1304615115 was not 
found when attempting to remove it
May 04 14:50:48 lrrr cups-browsed[68281]: Source ID 1398290009 was not 
found when attempting to remove it
May 04 14:50:48 lrrr cups-browsed[68281]: Source ID 1398304338 was not 
found when attempting to remove it
May 04 14:50:48 lrrr cups-browsed[68281]: Source ID 1398387203 was not 
found when attempting to remove it
May 04 14:50:51 lrrr cups-browsed[68281]: Source ID 1398664816 was not 
found when attempting to remove it
May 04 14:50:51 lrrr cups-browsed[68281]: Source ID 1398674240 was not 
found when attempting to remove it
May 04 14:50:51 lrrr cups-browsed[68281]: Source ID 1398687187 was not 
found when attempting to remove it
May 04 14:50:51 lrrr cups-browsed[68281]: Source ID 1398698982 was not 
found when attempting to remove it
May 04 14:50:51 lrrr cups-browsed[68281]: Source ID 1398726803 was not 
found when attempting to remove it
May 04 14:52:24 lrrr cups-browsed[68281]: Source ID 1410715532 was not 
found when attempting to remove it
May 04 14:52:24 lrrr cups-browsed[68281]: Source ID 1410741036 was not 
found when attempting to remove it
May 04 14:52:24 lrrr cups-browsed[68281]: Source ID 1410777106 was not 
found when attempting to remove it
May 04 14:52:25 lrrr cups-browsed[68281]: Source ID 1410797157 was not 
found when attempting to remove it

These errors seem to be generated when glib's g_source_remove() function
is called with an ID for a job that doesn't exist. This could indicate
that cups-browsed is losing track of an idle or timeout function.

ProblemType: Bug
DistroRelease: Ubuntu 23.04
Package: cups-browsed 2.0~rc1-0ubuntu1
ProcVersionSignature: Ubuntu 6.2.0-20.20-generic 6.2.6
Uname: Linux 6.2.0-20-generic x86_64
ApportVersion: 2.26.1-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Thu May  4 15:10:03 2023
InstallationDate: Installed on 2017-09-02 (2070 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170901)
MachineType: LENOVO 20HRCTO1WW
Papersize: a4
PpdFiles:
 Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/Lexmark_MS610dn_3_.ppd', '/etc/cups/ppd/test6_59CD60.ppd', 
'/etc/cups/ppd/HP_OfficeJet_Pro_8710_C7327F.ppd', 
'/etc/cups/ppd/test4_F7866E.ppd', 
'/etc/cups/ppd/HP_Smart_Tank_530_series_E23C83.ppd'] failed with exit code 2: 
grep: /etc/cups/ppd/Lexmark_MS610dn_3_.ppd: Permission denied
 grep: /etc/cups/ppd/test6_59CD60.ppd: Permission denied
 grep: /etc/cups/ppd/HP_OfficeJet_Pro_8710_C7327F.ppd: Permission denied
 grep: /etc/cups/ppd/test4_F7866E.ppd: Permission denied
 grep: /etc/cups/ppd/HP_Smart_Tank_530_series_E23C83.ppd: Permission denied
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-20-generic 
root=UUID=94446fd9-8625-46ee-a8de-034cc22d680b ro quiet splash vt.handoff=7
SourcePackage: cups-browsed
UpgradeStatus: Upgraded to lunar on 2023-03-29 (36 days ago)
dmi.bios.date: 11/24/2022
dmi.bios.release: 1.57
dmi.bios.vendor: LENOVO
dmi.bios.version: N1MET72W (1.57 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20HRCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
d

[Desktop-packages] [Bug 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

I did a search through the KDE bug tracker, and it looks like someone
reported the same root problem back in 2020:

https://bugs.kde.org/show_bug.cgi?id=423756

** Bug watch added: KDE Bug Tracking System #423756
   https://bugs.kde.org/show_bug.cgi?id=423756

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in GNOME Shell:
  New
Status in gnome-desktop package in Ubuntu:
  Confirmed
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in kio package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/2011806/+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 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

I've filed https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
upstream to cover the gnome-shell problem.

** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #6565
   https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565

** Also affects: gnome-shell via
   https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
   Importance: Unknown
   Status: Unknown

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in GNOME Shell:
  Unknown
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in kio package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/2011806/+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 2013157] [NEW] stale emacs lisp files left behind after upgrade

[James Henstridge]

Public bug reported:

After upgrading to Lunar, I see the following warning messages when I
start Emacs:

Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/use-package-2.4.1/use-package.elc
Disable showing Disable logging

After the upgrade, I have two use-package directories in site-lisp/elpa:

/usr/share/emacs/site-lisp/elpa/use-package-2.4.1
/usr/share/emacs/site-lisp/elpa/use-package-2.4.4

The 2.4.1 directory contains broken .el symlinks and regular .elc files.
The 2.4.4 directory contains working .el symlinks and .elc files. There
are a few other packages in a similar state that changed version between
Kinetic and Lunar.

>From what I can tell, these directories were set up by /usr/lib/dh-
elpa/helper/install but the old version was not removed on upgrade.

Manually removing the old versioned directory for affected packages
clears up the warnings.

ProblemType: Bug
DistroRelease: Ubuntu 23.04
Package: elpa-use-package 2.4.4-1
ProcVersionSignature: Ubuntu 6.2.0-18.18-generic 6.2.6
Uname: Linux 6.2.0-18-generic x86_64
ApportVersion: 2.26.0-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Wed Mar 29 11:57:27 2023
InstallationDate: Installed on 2017-09-02 (2033 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170901)
PackageArchitecture: all
SourcePackage: use-package
UpgradeStatus: Upgraded to lunar on 2023-03-29 (0 days ago)

** Affects: dh-elpa (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: use-package (Ubuntu)
 Importance: Undecided
 Status: New


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

** Also affects: dh-elpa (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  stale emacs lisp files left behind after upgrade

Status in dh-elpa package in Ubuntu:
  New
Status in use-package package in Ubuntu:
  New

Bug description:
  After upgrading to Lunar, I see the following warning messages when I
  start Emacs:

  Warning (comp): Cannot look-up eln file as no source file was
  found for /usr/share/emacs/site-lisp/elpa/use-package-2.4.1/use-
  package.elc Disable showing Disable logging

  After the upgrade, I have two use-package directories in site-
  lisp/elpa:

  /usr/share/emacs/site-lisp/elpa/use-package-2.4.1
  /usr/share/emacs/site-lisp/elpa/use-package-2.4.4

  The 2.4.1 directory contains broken .el symlinks and regular .elc
  files. The 2.4.4 directory contains working .el symlinks and .elc
  files. There are a few other packages in a similar state that changed
  version between Kinetic and Lunar.

  From what I can tell, these directories were set up by /usr/lib/dh-
  elpa/helper/install but the old version was not removed on upgrade.

  Manually removing the old versioned directory for affected packages
  clears up the warnings.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.04
  Package: elpa-use-package 2.4.4-1
  ProcVersionSignature: Ubuntu 6.2.0-18.18-generic 6.2.6
  Uname: Linux 6.2.0-18-generic x86_64
  ApportVersion: 2.26.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 29 11:57:27 2023
  InstallationDate: Installed on 2017-09-02 (2033 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170901)
  PackageArchitecture: all
  SourcePackage: use-package
  UpgradeStatus: Upgraded to lunar on 2023-03-29 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dh-elpa/+bug/2013157/+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 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

> So, I feel snapd tracker should somewhat be able to track that an app
> changed its cgroup and move it back to what it belongs, but as discussed
> in https://github.com/systemd/systemd/issues/26925 there's nothing
> telling us that right now.

There is no "snapd tracker". It's the "snap run" code that moves itself
to a new cgroup before setting up the sandbox, dropping privileges, and
executing the confined application. At that point, it has no permission
to talk to systemd.

It's basically working like "systemd-run --scope" would: it sets up the
environment appropriately and then lets the app take over.

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in gnome-shell package in Ubuntu:
  Fix Released
Status in kio package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

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


-- 
Mailing list: https://launchp

[Desktop-packages] [Bug 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

Another idea for how to synchronise the StartTransientUnit call without
resorting to passing pipe file descriptors to the child: we could simply
have the child_setup_func call kill(getpid(), SIGSTOP). The parent
process can now do the cgroup move at its leisure, and then send a
SIGCONT to the child to let it continue to the exec() call.

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in gnome-shell package in Ubuntu:
  In Progress

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2011806/+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 2011806] Re: [lunar] Snaps don't launch due to cgroup issue

[James Henstridge]

@Batuhan: it's different code, but looks to be the same type of problem:

https://github.com/KDE/kio/blob/5bda428992cbd168fc1898661d80a089a8217449/src/gui/systemd/scopedprocessrunner.cpp#L13-L41

It's moving the process to a new cgroup after the application has
started executing (so happens without any synchronisation with what the
application is doing).

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

Title:
  [lunar] Snaps don't launch due to cgroup issue

Status in gnome-shell package in Ubuntu:
  In Progress

Bug description:
  Hi,

  Lunar up to date, Intel+Nvidia GPUs, Ubuntu Wayland or X11 session,
  hybrid or discrete graphics.

  If I click on a snap dash icon, nothing happens.
  Tested with Thunderbird, Firefox, Shortwave...
  (VS Code seems ok, maybe due to classic confinment?)

  I can launch without issue Chrome (deb), Synaptic, GNOME apps, etc.

  Recent updates included gnome-shell and libadwaita.

  ---

  I get this type of log for all problematic snaps:

  /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-
  shortwave_shortwave-11885.scope is not a snap cgroup

  ---

  Context:

  $ snap --version
  snap2.58.3+23.04ubuntu1
  snapd   2.58.3+23.04ubuntu1
  series  16
  ubuntu  23.04
  kernel  6.1.0-16-generic

  $ snap list
  Nom   Version Révision  
Suivi Éditeur   Notes
  bare  1.0 5 
latest/stable canonical✓base
  code  ee2b180d122   
latest/stable vscode✓   classic
  core  16-2.58.2   14784 
latest/stable canonical✓core
  core18202303082714  
latest/stable canonical✓base
  core20202302071828  
latest/stable canonical✓base
  core2220230210522   
latest/stable canonical✓base
  firefox   111.0-2 2432  
latest/candidate  mozilla✓  -
  gimp  2.10.30 393   
latest/stable snapcrafters  -
  gnome-3-28-1804   3.28.0-19-g98f9e67.98f9e67  161   
latest/stable canonical✓-
  gnome-3-38-2004   0+git.6f39565   119   
latest/stable canonical✓-
  gnome-42-2204 0+git.09673a5   65
latest/stable canonical✓-
  gtk-common-themes 0.1-81-g442e511 1535  
latest/stable/…   canonical✓-
  gtk-theme-pocillo 0.14.4.15 
latest/stable ubuntubudgie  -
  gtk-theme-qogirbudgie 22.04.1 8 
latest/stable ubuntubudgie  -
  gtk2-common-themes0.1 13
latest/stable canonical✓-
  hunspell-dictionaries-1-7-20041.7-20.04+pkg-6fd6  2 
latest/stable brlin -
  kde-frameworks-5-91-qt-5-15-3-core20  5.91.0  1 
latest/stable kde✓  -
  kde-frameworks-5-99-qt-5-15-7-core20  5.99.0  15
latest/stable kde✓  -
  kde-frameworks-5-core18   5.67.0  35
latest/stable kde✓  -
  libreoffice   7.5.1.2 270   
latest/stable canonical✓-
  shortwave 3.0.0   79
latest/stable alexmurray✪   -
  snapd 2.58.2  18357 
latest/stable canonical✓snapd
  snapd-desktop-integration 0.1 71
latest/stable/…   canonical✓-
  stellarium-daily  v1.21396  
latest/stable t4saha-
  thunderbird   102.9.0-1   305   
latest/candidate  canonical✓-
  vlc   3.0.18  3078  
latest/stable videolan✓ -

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2011806/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if IBus is turned on

[James Henstridge]

I've created https://github.com/snapcore/snapd/pull/12627 as a proposed
fix for the issue.

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if
  IBus is turned on

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  Test Case
  -
  From Ubuntu 23.04, install glib >= 2.75.3-3

  Test 1:
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu on Xorg
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  Test 2:
  Install the ibus-libpinyin package.
  Log out and log in again.
  Go to Settings -> Keyboard and add "Chinese (Intelligent Pinyin)"
   to your input sources.
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu (on Wayland).
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  What Happens
  
  No text is inputted

  Other Info
  --
  You see the issue as soon as IBus has been 'turned on'. With the current 
g-s-d version you need to somehow trigger a need to turn IBus on. In an X11 
session IBus is always turned on due to im-config 0.55-1. In a Wayland session 
you need to tell it to turn IBus on by either adding an IBus input method to 
your input sources or make use of the Screen Keyboard feature.

  And I've only seen the issue with the Firefox and Chromium snaps.

  Warning message if you start firefox from terminal:

  [Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could
  not connect: Permission denied: 'glib warning', file
  /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167

  (firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to
  ibus: Could not connect: Permission denied

  gnome-settings-daemon
  -
  gnome-settings-daemon 44 Beta makes the situation worse since it always turns 
IBus on in both Wayland and X11, but I reverted 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/27bc0889c so that 
we could continue with the update. See 
https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if IBus is turned on

[James Henstridge]

Okay. In a clean Lunar VM with glib 2.75.3 installed and ibus enabled as
described in the bug description, I could reproduce the input problems
in Firefox. I saw the following AppArmor denial in the dmesg logs:

[  +0.343553] audit: type=1400 audit(1678248386.012:62):
apparmor="DENIED" operation="connect" profile="snap.firefox.firefox"
name="/home/james/.cache/ibus/dbus-THbBfRNt" pid=2398 comm="pool-
firefox" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

I edited /var/lib/snapd/apparmor/profiles/snap.firefox.firefox and added
the following rule:

@{HOME}/.cache/ibus/dbus-* rw,

After reloading the policy with "apparmor_parser -r
.../snap.firefox.firefox", keyboard input worked again. So that confirms
my guess about the cause of the problem. This is something we can fix
via a snapd update.

Longer term, we should get these snaps using ibus's portal interface,
which is both more secure (i.e. suitable to allow in the desktop
interface) and should be immune to future changes of this type.

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if
  IBus is turned on

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  Test Case
  -
  From Ubuntu 23.04, install glib >= 2.75.3-3

  Test 1:
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu on Xorg
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  Test 2:
  Install the ibus-libpinyin package.
  Log out and log in again.
  Go to Settings -> Keyboard and add "Chinese (Intelligent Pinyin)"
   to your input sources.
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu (on Wayland).
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  What Happens
  
  No text is inputted

  Other Info
  --
  You see the issue as soon as IBus has been 'turned on'. With the current 
g-s-d version you need to somehow trigger a need to turn IBus on. In an X11 
session IBus is always turned on due to im-config 0.55-1. In a Wayland session 
you need to tell it to turn IBus on by either adding an IBus input method to 
your input sources or make use of the Screen Keyboard feature.

  And I've only seen the issue with the Firefox and Chromium snaps.

  Warning message if you start firefox from terminal:

  [Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could
  not connect: Permission denied: 'glib warning', file
  /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167

  (firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to
  ibus: Could not connect: Permission denied

  gnome-settings-daemon
  -
  gnome-settings-daemon 44 Beta makes the situation worse since it always turns 
IBus on in both Wayland and X11, but I reverted 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/27bc0889c so that 
we could continue with the update. See 
https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if IBus is turned on

[James Henstridge]

This seems like the most likely culprit:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3005

This basically means that code that would have created an abstract
namespace socket in glib 2.74.x now creates a regular unix domain socket
in 2.75.x. We have AppArmor rules in snapd's desktop-legacy interface
granting access to the abstract namespace socket in $XDG_CACHE_HOME, but
nothing for the equivalent regular socket:

https://github.com/snapcore/snapd/blob/d5f47ca71fcd8a884072e75391a7e55d9ec9d145/interfaces/builtin/desktop_legacy.go#L142-L149

I still need to verify this is the actual cause, but if so it should be
relatively simple to update snapd's AppArmor rules to allow access to
this socket.

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if
  IBus is turned on

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  Test Case
  -
  From Ubuntu 23.04, install glib >= 2.75.3-3

  Test 1:
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu on Xorg
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  Test 2:
  Install the ibus-libpinyin package.
  Log out and log in again.
  Go to Settings -> Keyboard and add "Chinese (Intelligent Pinyin)"
   to your input sources.
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu (on Wayland).
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  What Happens
  
  No text is inputted

  Other Info
  --
  You see the issue as soon as IBus has been 'turned on'. With the current 
g-s-d version you need to somehow trigger a need to turn IBus on. In an X11 
session IBus is always turned on due to im-config 0.55-1. In a Wayland session 
you need to tell it to turn IBus on by either adding an IBus input method to 
your input sources or make use of the Screen Keyboard feature.

  And I've only seen the issue with the Firefox and Chromium snaps.

  Warning message if you start firefox from terminal:

  [Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could
  not connect: Permission denied: 'glib warning', file
  /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167

  (firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to
  ibus: Could not connect: Permission denied

  gnome-settings-daemon
  -
  gnome-settings-daemon 44 Beta makes the situation worse since it always turns 
IBus on in both Wayland and X11, but I reverted 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/27bc0889c so that 
we could continue with the update. See 
https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if IBus is turned on

[James Henstridge]

I think last time we had problems like this it was due to changes in the
location of the socket for ibus's private D-Bus bus. Looking into the
glib diffs for clues.

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if
  IBus is turned on

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  Test Case
  -
  From Ubuntu 23.04, install glib >= 2.75.3-3

  Test 1:
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu on Xorg
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  Test 2:
  Install the ibus-libpinyin package.
  Log out and log in again.
  Go to Settings -> Keyboard and add "Chinese (Intelligent Pinyin)"
   to your input sources.
  Log out
  Click your name on the login screen.
  Click the gear button to choose Ubuntu (on Wayland).
  Enter your password to finish logging in.
  Open Firefox (or Chromium)
  Try to enter text in the address bar.

  What Happens
  
  No text is inputted

  Other Info
  --
  You see the issue as soon as IBus has been 'turned on'. With the current 
g-s-d version you need to somehow trigger a need to turn IBus on. In an X11 
session IBus is always turned on due to im-config 0.55-1. In a Wayland session 
you need to tell it to turn IBus on by either adding an IBus input method to 
your input sources or make use of the Screen Keyboard feature.

  And I've only seen the issue with the Firefox and Chromium snaps.

  Warning message if you start firefox from terminal:

  [Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could
  not connect: Permission denied: 'glib warning', file
  /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167

  (firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to
  ibus: Could not connect: Permission denied

  gnome-settings-daemon
  -
  gnome-settings-daemon 44 Beta makes the situation worse since it always turns 
IBus on in both Wayland and X11, but I reverted 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/27bc0889c so that 
we could continue with the update. See 
https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 1968635] Re: Chromium window empty

[James Henstridge]

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

** This bug has been marked a duplicate of bug 1966108
   Chromium snap on Jammy system with nvidia-510 does not start

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

Title:
  Chromium window empty

Status in chromium-browser package in Ubuntu:
  New

Bug description:
  The browser starts, but the entire user interface apart from the
  window's border is missing.

  This is what gets displayed when the browser is started via CLI:

  Gtk-Message: 00:45:30.672: Failed to load module "canberra-gtk-module"
  Gtk-Message: 00:45:30.673: Failed to load module "canberra-gtk-module"
  MESA-LOADER: failed to retrieve device information
  MESA-LOADER: failed to open nvidia-drm: 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri/nvidia-drm_dri.so:
 cannot open shared object file: Permission denied (search paths 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
  failed to load driver: nvidia-drm
  MESA-LOADER: failed to open kms_swrast: 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri/kms_swrast_dri.so:
 cannot open shared object file: Permission denied (search paths 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
  failed to load driver: kms_swrast
  MESA-LOADER: failed to open swrast: 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: 
cannot open shared object file: Permission denied (search paths 
/snap/chromium/1957/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
  failed to load swrast driver
  [740332:740418:0412/004535.002377:ERROR:udev_watcher.cc(98)] Failed to begin 
udev enumeration.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: chromium-browser 1:85.0.4183.83-0ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30
  Uname: Linux 5.15.0-25-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu80
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr 12 00:43:30 2022
  InstallationDate: Installed on 2022-02-23 (47 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220223)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  Snap.ChromeDriverVersion: ChromeDriver 100.0.4896.75 
(d9568d04d7dd79269c5a655d7ada69650c5a8336-refs/branch-heads/4896@{#1007})
  Snap.ChromiumVersion: Chromium 100.0.4896.75 snap
  SourcePackage: chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1968635/+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 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap

[James Henstridge]

> Is there any option to do this via portals - ie can evince use
> org.freedesktop.portal.OpenURI to open the URI? Would then this
> allow to avoid going via xdg-open?

Evince is using g_app_info_launch_default_for_uri(), which can use the
portal interface:

https://gitlab.gnome.org/GNOME/evince/-/blob/main/shell/ev-
window.c#L6775-6778

However, it only does this as a fallback if no desktop file supports the
URI. This is intended to allow a confined app to handle some file types
within the sandbox before falling back to portals for everything else.

In the case of Evince running on the host system and seeing all the
desktop files in /usr/share/applications and other locations, it likely
won't ever call the portal API.

It'd be possible to code in explicit portal API calls, but it isn't
something that Evince packaged as a flatpak or snap would need. So it
might end up as a distro patch we'd be on the hook to maintain forever.

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

Title:
  Clicking a hyperlink in a PDF fails to open it if the default browser
  is a snap

Status in apparmor package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Triaged
Status in evince package in Debian:
  New

Bug description:
  This is related to bug #1792648. After fixing that one (see discussion
  at https://salsa.debian.org/gnome-team/evince/merge_requests/1),
  clicking a hyperlink in a PDF opens it correctly if the default
  browser is a well-known application (such as /usr/bin/firefox), but it
  fails to do so if the default browser is a snap (e.g. the chromium
  snap).

  This is not a recent regression, it's not working on bionic either.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: evince 3.30.0-2
  ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
  Uname: Linux 4.18.0-7-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu11
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 24 12:28:06 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2016-07-02 (813 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  SourcePackage: evince
  UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago)
  modified.conffile..etc.apparmor.d.abstractions.evince: [modified]
  mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+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 1928360] Re: Switch to Fcitx 5 for Chinese

[James Henstridge]

> Is there such a snap you could point me to so I can test?

The candidate channel of the gedit snap is built with core20 and the
gnome-3-38-2004 platform snap.  But as I said, I don't think that
platform snap currently includes the fcitx5 input module.

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

Title:
  Switch to Fcitx 5 for Chinese

Status in Lubuntu default settings:
  New
Status in Snappy:
  New
Status in Ubuntu Kylin:
  In Progress
Status in im-config package in Ubuntu:
  Fix Released
Status in language-selector package in Ubuntu:
  Fix Released

Bug description:
  In Debian 11 Fcitx 5 will be the default IM framework for Chinese on
  non-GNOME desktops. I can think it's time to make the equivalent
  changes in Ubuntu 21.10 as well.

  I'd appreciate input on the topic from the Ubuntu Kylin team as well
  as other Chinese speaking users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lubuntu-default-settings/+bug/1928360/+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 1928360] Re: Switch to Fcitx 5 for Chinese

[James Henstridge]

I hadn't realised that they renamed the IM module with the version bump:
that means snaps built against older platforms won't load the old (but
working) Fcitx 4 module when run on a host system configured with Fcitx
5.

We can certainly look at adding the new IM module to the platform snaps,
but that will also switch to the new IPC protocol.  From a quick look
through the source it will probably be allowed by existing AppArmor
rules in the "desktop" interface, but that will need testing.

It's probably going to be easiest to see if we can get things working
with a core20 based platform snap though, since we have fcitx5 packages
there (albeit for a git prerelease version).

For the core18 based platform snaps, we would need to backport the
fcitx5 packages themselves.  Alternatively, I wonder if we could get
away with symlinking the old module name to the new one?

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

Title:
  Switch to Fcitx 5 for Chinese

Status in Lubuntu default settings:
  New
Status in Snappy:
  New
Status in Ubuntu Kylin:
  In Progress
Status in im-config package in Ubuntu:
  New
Status in language-selector package in Ubuntu:
  Fix Released

Bug description:
  In Debian 11 Fcitx 5 will be the default IM framework for Chinese on
  non-GNOME desktops. I can think it's time to make the equivalent
  changes in Ubuntu 21.10 as well.

  I'd appreciate input on the topic from the Ubuntu Kylin team as well
  as other Chinese speaking users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lubuntu-default-settings/+bug/1928360/+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 1838038] Re: [snap] Snapped apps do not work with .local mdns/avahi name resolution

[James Henstridge]

Just repeating what I said on the forum, I believe this could be
implemented through updates to the base snaps with no changes to snapd
or any application snaps.

The mdns4_minimal NSS plugin is an 18K binary (which compresses to about
6KB) that delegates its lookups to avahi-daemon using a single purpose
lookups-only unix socket protocol (i.e. no D-Bus access).  The AppArmor
 policy fragment grants access to this socket,
so any snap plugging "network" already has permission to communicate.

If the plugin cannot connect to Avahi, it should error out very quickly.

Updating the base snaps to include the NSS plugin and reference it in
their nsswitch.conf file would likely be all that is needed.  It should
work equally well for applications on classic distros and those on
Ubuntu Core with the avahi snap installed.

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

Title:
  [snap] Snapped apps do not work with .local mdns/avahi name resolution

Status in snap-core18:
  New
Status in snap-core20:
  New
Status in snapd:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

Bug description:
  (initially reported at https://forum.snapcraft.io/t/chromium-does-not-
  work-with-local-mdns-avahi-name-resolution/12483)

  The current chromium snap does not allow to open any .local urls.

  This is most likely caused by https://forum.snapcraft.io/t/no-mdns-
  support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603.

  With the removal of the chromium deb and the switch to a snap-only
  deployment for this browser this is a pretty solid regression that
  should be addressed…

To manage notifications about this bug go to:
https://bugs.launchpad.net/snap-core18/+bug/1838038/+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 1897224] Re: Graphical snaps can't run in Gnome 3.38 Wayland sessions (can't open X display)

[James Henstridge]

I've updated the description with the SRU bug template.  I think this
includes all the relevant info?

** Description changed:

- I'm trying to run chromium installed via snap in Ubuntu 20.10 when
- running Ubuntu Wayland session. Unfortunately, chromium wouldn't start:
+ [Impact]
  
- > chromium 
+  * Users who select the Wayland session on Ubuntu 20.10 cannot run snap
+confined X11 applications, due to gnome-shell no longer listening on an
+abstract socket for connections.
+ 
+  * The fix, which has been accepted into upstream's gnome-3-38 branch
+reverts the change removing the abstract socket, and fixes the bug that
+prompted it's removal.
+ 
+ [Test Case]
+ 
+  * Start with a stock Ubuntu 20.10 desktop install.
+ 
+  * At the GDM login screen, after selecting your user account use the gear 
+icon to select the "Ubuntu on Wayland" session, and log in.
+ 
+  * Ensure Chromium is installed by running "sudo snap install chromium".
+ 
+  * Try to run "chromium" from the terminal.  Without the fix, it will fail
+with the error "Unable to open X display".  With the fix applied, it
+will launch as normal.
+ 
+ [Regression Potential]
+ 
+  * The patch modifies the logic gnome-shell uses to launch Xwayland.  So
+there is a potential that the change could break X11 application
+support on the Wayland session.
+ 
+  * The default configuration for gnome-shell is to launch Xwayland on
+session start, so it should be immediately obvious if there are
+problems.
+ 
+  * In addition to checking snapped X11 apps like Chromium, verify that a
+few classic X11 apps still launch correctly (e.g. xterm, xeyes, etc).
+ 
+ [Other Info]
+  
+  * Running "ss -xlp | grep Xwayland" should show that it is listening on
+both "/tmp/.X11-unix/X0" (the regular unix domain socket) and
+"@/tmp/.X11-unix/X0" (the abstract socket).
+ 
+ ---
+ I'm trying to run chromium installed via snap in Ubuntu 20.10 when running 
Ubuntu Wayland session. Unfortunately, chromium wouldn't start:
+ 
+ > chromium
  [49244:49244:0925/094607.732169:ERROR:browser_main_loop.cc(1417)] Unable to 
open X display.
  
  I am able to run Firefox just fine (assuming that Firefox still runs on
  xwayland) and also Intellij snap works fine.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  ProcVersionSignature: Ubuntu 5.8.0-19.20-generic 5.8.8
  Uname: Linux 5.8.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu47
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 25 09:45:16 2020
  InstallationDate: Installed on 2016-09-05 (1480 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  Snap: chromium 85.0.4183.121 (latest/stable)
  SnapSource: ubuntu/+source/chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  [Impact]
  
-  * Users who select the Wayland session on Ubuntu 20.10 cannot run snap
-confined X11 applications, due to gnome-shell no longer listening on an
-abstract socket for connections.
+  * Users who select the Wayland session on Ubuntu 20.10 cannot run snap
+    confined X11 applications, due to gnome-shell no longer listening on an
+    abstract socket for connections.
  
-  * The fix, which has been accepted into upstream's gnome-3-38 branch
-reverts the change removing the abstract socket, and fixes the bug that
-prompted it's removal.
+  * The fix, which has been accepted into upstream's gnome-3-38 branch
+    reverts the change removing the abstract socket, and fixes the bug that
+    prompted it's removal:
+ 
+https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1508
  
  [Test Case]
  
-  * Start with a stock Ubuntu 20.10 desktop install.
+  * Start with a stock Ubuntu 20.10 desktop install.
  
-  * At the GDM login screen, after selecting your user account use the gear 
-icon to select the "Ubuntu on Wayland" session, and log in.
+  * At the GDM login screen, after selecting your user account use the gear
+    icon to select the "Ubuntu on Wayland" session, and log in.
  
-  * Ensure Chromium is installed by running "sudo snap install chromium".
+  * Ensure Chromium is installed by running "sudo snap install chromium".
  
-  * Try to run "chromium" from the terminal.  Without the fix, it will fail
-with the error "Unable to open X display".  With the fix applied, it
-will launch as normal.
+  * Try to run "chromium" from the terminal.  Without the fix, it will fail
+    with the error "Unable to open X display".  With the fix applied, it
+    will launch as normal.
  
  [Regression Potential]
  
-  * The patch modifies the logic gnome-shell uses to launch Xwayland.  So
-there is a potential that the change could break X11 application
-support on the Wayland session.
+  * The patch modifies the logic gnome-shell uses to launch Xwayland.  So
+    there is a potential that the change could break X11 ap

[Desktop-packages] [Bug 1897224] Re: Graphical snaps can't run in Gnome 3.38 Wayland sessions (can't open X display)

[James Henstridge]

I had a go at fixing this in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1508 -- taking
the patches from that MR and applying them to the Groovy mutter source
package gave me a Wayland session that supported X11 snaps again.

It is probably worth waiting for a review from upstream before going
further.  I've done the testing they asked for with the "autostart-
xwayland" feature enabled, so hopefully that will come soon.

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

Title:
  Graphical snaps can't run in Gnome 3.38 Wayland sessions (can't open X
  display)

Status in Mutter:
  Unknown
Status in snapd:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to run chromium installed via snap in Ubuntu 20.10 when
  running Ubuntu Wayland session. Unfortunately, chromium wouldn't
  start:

  > chromium 
  [49244:49244:0925/094607.732169:ERROR:browser_main_loop.cc(1417)] Unable to 
open X display.

  I am able to run Firefox just fine (assuming that Firefox still runs
  on xwayland) and also Intellij snap works fine.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  ProcVersionSignature: Ubuntu 5.8.0-19.20-generic 5.8.8
  Uname: Linux 5.8.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu47
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 25 09:45:16 2020
  InstallationDate: Installed on 2016-09-05 (1480 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  Snap: chromium 85.0.4183.121 (latest/stable)
  SnapSource: ubuntu/+source/chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1897224/+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 1897224] Re: [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to open X display

[James Henstridge]

I've filed https://gitlab.gnome.org/GNOME/mutter/-/issues/1454 upstream
about this regression.

** Bug watch added: gitlab.gnome.org/GNOME/mutter/-/issues #1454
   https://gitlab.gnome.org/GNOME/mutter/-/issues/1454

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

Title:
  [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to
  open X display

Status in Mutter:
  Unknown
Status in snapd:
  Confirmed
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to run chromium installed via snap in Ubuntu 20.10 when
  running Ubuntu Wayland session. Unfortunately, chromium wouldn't
  start:

  > chromium 
  [49244:49244:0925/094607.732169:ERROR:browser_main_loop.cc(1417)] Unable to 
open X display.

  I am able to run Firefox just fine (assuming that Firefox still runs
  on xwayland) and also Intellij snap works fine.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  ProcVersionSignature: Ubuntu 5.8.0-19.20-generic 5.8.8
  Uname: Linux 5.8.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu47
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 25 09:45:16 2020
  InstallationDate: Installed on 2016-09-05 (1480 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  Snap: chromium 85.0.4183.121 (latest/stable)
  SnapSource: ubuntu/+source/chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1897224/+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 1897224] Re: [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to open X display

[James Henstridge]

Looking at the reasoning behind that change, Mutter introduced lazy
initialisation of Xwayland: binding the two sockets, and starting
Xwayland when someone connected to the abstract namespace socket.
Flatpak apps apparently can't speak to the abstract namespace socket, so
would hang forever when started since the connection to the non-abstract
/tmp/.X11-unix socket was never accepted.

Rather than fixing the initialisation logic to start Xwayland on connect
to either socket, they dropped the abstract namespace socket.  I'll talk
to the snapd folks about it, but this sounds like it should be dealt
with on the Mutter side.

** Changed in: mutter (Ubuntu)
   Status: Invalid => Confirmed

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

Title:
  [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to
  open X display

Status in snapd:
  Confirmed
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to run chromium installed via snap in Ubuntu 20.10 when
  running Ubuntu Wayland session. Unfortunately, chromium wouldn't
  start:

  > chromium 
  [49244:49244:0925/094607.732169:ERROR:browser_main_loop.cc(1417)] Unable to 
open X display.

  I am able to run Firefox just fine (assuming that Firefox still runs
  on xwayland) and also Intellij snap works fine.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  ProcVersionSignature: Ubuntu 5.8.0-19.20-generic 5.8.8
  Uname: Linux 5.8.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu47
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 25 09:45:16 2020
  InstallationDate: Installed on 2016-09-05 (1480 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  Snap: chromium 85.0.4183.121 (latest/stable)
  SnapSource: ubuntu/+source/chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1897224/+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 1897224] Re: [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to open X display

[James Henstridge]

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1424 is
definitely the culprit here.  Snaps depend on access to the abstract
namespace socket to function correctly.

Inside the sandboxes, snaps see a private /tmp that is under their
complete control.  So there is no /tmp/.X11-unix directory there.  They
can see the abstract namespace socket though, which the client libraries
will use automatically.

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

Title:
  [snap] chromium won't start on Xwayland in Ubuntu 20.10: Unable to
  open X display

Status in snapd:
  Confirmed
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Invalid
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to run chromium installed via snap in Ubuntu 20.10 when
  running Ubuntu Wayland session. Unfortunately, chromium wouldn't
  start:

  > chromium 
  [49244:49244:0925/094607.732169:ERROR:browser_main_loop.cc(1417)] Unable to 
open X display.

  I am able to run Firefox just fine (assuming that Firefox still runs
  on xwayland) and also Intellij snap works fine.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  ProcVersionSignature: Ubuntu 5.8.0-19.20-generic 5.8.8
  Uname: Linux 5.8.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu47
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 25 09:45:16 2020
  InstallationDate: Installed on 2016-09-05 (1480 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  Snap: chromium 85.0.4183.121 (latest/stable)
  SnapSource: ubuntu/+source/chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1897224/+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 1886854] Re: Race in load-module snap policy check in classic confinement

[James Henstridge]

This is the in-progress fix I've been working on.  It does not quite
work right though: switching to an async hook for these commands is
resulting in the daemon killing the client on a protocol error.

This might be a problem with the hooks patch set itself.  I need to
investigate a bit further.

** Patch added: "allow-classic.diff"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1886854/+attachment/5413365/+files/allow-classic.diff

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

Title:
  Race in load-module snap policy check in classic confinement

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  SUMMARY
  =
  When running a snap in classic confinement, that needs access to 
PA_COMMAND_LOAD_MODULE and PA_COMMAND_UNLOAD_MODULE. These sometimes succeed 
and sometimes fail with "Access denied".

  After running "pacmd unload-module module-snap-policy" and unloading
  the snap policy module, these work reliably.

  I have verified this in a fresh install of Ubuntu 20.04 in a VM.

  STEPS TO REPRODUCE
  =
  a) Either build a snap with classic confinement that sends these commands on 
the pulseaudio native protocol socket. (This is how I found the bug)
  b) Or, what I did here to easier reproduce, abuse the sandbox of a random 
classic snap:

  Download the attached bug.tgz with a minimal reproducer. It contains
  the source code for a program that sends load and unload commands to
  pulse. Unfortunately `pacmd` has a pid-file check that fails inside
  the sandbox and doesn't work. The reproducer does essentially the same
  as "pacmd load/unload-module" though.

  (a pre-compiled x64 binary is also included in case you don't have a
  go compiler and dare to run an untrusted binary in a VM)

  Unpack the tgz, build it, if necessary with "go mod download && go
  build"

  Grab a random classic mode snap to use its sandbox as a test bed:

  $ sudo snap install atom --classic
  atom 1.48.0 from Snapcrafters installed

  Open a shell in its sandbox:

  snap run --shell atom
  
  Navigate to the compiled binary and execute it a few times:

  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:10 PulseAudio connection created successfully
  2020/07/08 18:46:10 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:11 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 40
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 41
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  2020/07/08 18:46:12 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:15 PulseAudio connection created successfully
  2020/07/08 18:46:15 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

  to unload the snap-policy module from pulseaudio, now run ./bug a few
  more times. It now succeeds reliably, every time.

  Side note, with the real program on my actual machine, the race seems
  to behave slightly differently. It seems not to work the first time an
  application is started, but closing it and reopening it seems to make
  it work pretty reliably afterwards. Restarting "snapd", causes the
  following run the snap to fail again.

  EXPECTED BEHAVIOUR
  ==

  The pulseaudio snap policy module should correctly determine and
  enforce it's policy.

  ACTUAL BEHAVIOUR
  

  The pulseaudio snap policy module seemingly at random denies access
  when the snap has the permissions to do an operation.

  ADDITIONAL INFORMATION
  ==

  $ lsb_release -rd
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  $ apt-cache policy pulseaudio
  pulseaudio:
Installed: 1:13.99.1-1ubuntu3.3
Candidate: 1:13.99.1-1ubuntu3.3
Version table:
   *** 1:13.99.1-1ubuntu3.3 500
  500 http:

[Desktop-packages] [Bug 1886854] Re: Race in load-module snap policy check in classic confinement

[James Henstridge]

Sorry for taking so long to get back to you.  I now understand the non-
deterministic behaviour you're seeing.

I'm working on a fix for the server side to allow classic snaps to
access these commands.  It will require a small change to your Pulse
Audio client library to fix the non-determinism though.  I'll share more
information soon.

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

Title:
  Race in load-module snap policy check in classic confinement

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  SUMMARY
  =
  When running a snap in classic confinement, that needs access to 
PA_COMMAND_LOAD_MODULE and PA_COMMAND_UNLOAD_MODULE. These sometimes succeed 
and sometimes fail with "Access denied".

  After running "pacmd unload-module module-snap-policy" and unloading
  the snap policy module, these work reliably.

  I have verified this in a fresh install of Ubuntu 20.04 in a VM.

  STEPS TO REPRODUCE
  =
  a) Either build a snap with classic confinement that sends these commands on 
the pulseaudio native protocol socket. (This is how I found the bug)
  b) Or, what I did here to easier reproduce, abuse the sandbox of a random 
classic snap:

  Download the attached bug.tgz with a minimal reproducer. It contains
  the source code for a program that sends load and unload commands to
  pulse. Unfortunately `pacmd` has a pid-file check that fails inside
  the sandbox and doesn't work. The reproducer does essentially the same
  as "pacmd load/unload-module" though.

  (a pre-compiled x64 binary is also included in case you don't have a
  go compiler and dare to run an untrusted binary in a VM)

  Unpack the tgz, build it, if necessary with "go mod download && go
  build"

  Grab a random classic mode snap to use its sandbox as a test bed:

  $ sudo snap install atom --classic
  atom 1.48.0 from Snapcrafters installed

  Open a shell in its sandbox:

  snap run --shell atom
  
  Navigate to the compiled binary and execute it a few times:

  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:10 PulseAudio connection created successfully
  2020/07/08 18:46:10 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:11 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 40
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 41
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  2020/07/08 18:46:12 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:15 PulseAudio connection created successfully
  2020/07/08 18:46:15 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

  to unload the snap-policy module from pulseaudio, now run ./bug a few
  more times. It now succeeds reliably, every time.

  Side note, with the real program on my actual machine, the race seems
  to behave slightly differently. It seems not to work the first time an
  application is started, but closing it and reopening it seems to make
  it work pretty reliably afterwards. Restarting "snapd", causes the
  following run the snap to fail again.

  EXPECTED BEHAVIOUR
  ==

  The pulseaudio snap policy module should correctly determine and
  enforce it's policy.

  ACTUAL BEHAVIOUR
  

  The pulseaudio snap policy module seemingly at random denies access
  when the snap has the permissions to do an operation.

  ADDITIONAL INFORMATION
  ==

  $ lsb_release -rd
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  $ apt-cache policy pulseaudio
  pulseaudio:
Installed: 1:13.99.1-1ubuntu3.3
Candidate: 1:13.99.1-1ubuntu3.3
Version table:
   *** 1:13.99.1-1ubuntu3.3 500
  500 http://ch.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:13

[Desktop-packages] [Bug 1886854] Re: Race in load-module snap policy check in classic confinement

[James Henstridge]

I think I need to dig into this further.  The fact you're seeing a few
successful module loads with different module indexes would indicate it
is the same Pulse Audio instance.

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

Title:
  Race in load-module snap policy check in classic confinement

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  SUMMARY
  =
  When running a snap in classic confinement, that needs access to 
PA_COMMAND_LOAD_MODULE and PA_COMMAND_UNLOAD_MODULE. These sometimes succeed 
and sometimes fail with "Access denied".

  After running "pacmd unload-module module-snap-policy" and unloading
  the snap policy module, these work reliably.

  I have verified this in a fresh install of Ubuntu 20.04 in a VM.

  STEPS TO REPRODUCE
  =
  a) Either build a snap with classic confinement that sends these commands on 
the pulseaudio native protocol socket. (This is how I found the bug)
  b) Or, what I did here to easier reproduce, abuse the sandbox of a random 
classic snap:

  Download the attached bug.tgz with a minimal reproducer. It contains
  the source code for a program that sends load and unload commands to
  pulse. Unfortunately `pacmd` has a pid-file check that fails inside
  the sandbox and doesn't work. The reproducer does essentially the same
  as "pacmd load/unload-module" though.

  (a pre-compiled x64 binary is also included in case you don't have a
  go compiler and dare to run an untrusted binary in a VM)

  Unpack the tgz, build it, if necessary with "go mod download && go
  build"

  Grab a random classic mode snap to use its sandbox as a test bed:

  $ sudo snap install atom --classic
  atom 1.48.0 from Snapcrafters installed

  Open a shell in its sandbox:

  snap run --shell atom
  
  Navigate to the compiled binary and execute it a few times:

  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:10 PulseAudio connection created successfully
  2020/07/08 18:46:10 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:11 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 40
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 41
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  2020/07/08 18:46:12 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:15 PulseAudio connection created successfully
  2020/07/08 18:46:15 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

  to unload the snap-policy module from pulseaudio, now run ./bug a few
  more times. It now succeeds reliably, every time.

  Side note, with the real program on my actual machine, the race seems
  to behave slightly differently. It seems not to work the first time an
  application is started, but closing it and reopening it seems to make
  it work pretty reliably afterwards. Restarting "snapd", causes the
  following run the snap to fail again.

  EXPECTED BEHAVIOUR
  ==

  The pulseaudio snap policy module should correctly determine and
  enforce it's policy.

  ACTUAL BEHAVIOUR
  

  The pulseaudio snap policy module seemingly at random denies access
  when the snap has the permissions to do an operation.

  ADDITIONAL INFORMATION
  ==

  $ lsb_release -rd
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  $ apt-cache policy pulseaudio
  pulseaudio:
Installed: 1:13.99.1-1ubuntu3.3
Candidate: 1:13.99.1-1ubuntu3.3
Version table:
   *** 1:13.99.1-1ubuntu3.3 500
  500 http://ch.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:13.99.1-1ubuntu3.2 500
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
   1:13.99.1-1ubuntu3 500
  500 http://ch.arc

[Desktop-packages] [Bug 1886854] Re: Race in load-module snap policy check in classic confinement

[James Henstridge]

I think there's two issues at play here.

The hooks we added for module loading/unloading as part of USN-4355-1
simply check if the client has an AppArmor label that looks like it
belongs to a snap and denies access if found.  This will also deny
access to classic snaps, which is probably a mistake.

The race condition you've encountered is probably a case of "policy
module not in effect" vs. "policy module in effect" rather than a race
in the behaviour of the policy module itself.  This probably indicates
that Pulse is servicing client requests before it has completely
started.

For the first issue, we can make the hook request info about the snap
and allow access to classic snaps.  For the second, I think we just need
to load module-snap-policy earlier during start up.

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

Title:
  Race in load-module snap policy check in classic confinement

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  SUMMARY
  =
  When running a snap in classic confinement, that needs access to 
PA_COMMAND_LOAD_MODULE and PA_COMMAND_UNLOAD_MODULE. These sometimes succeed 
and sometimes fail with "Access denied".

  After running "pacmd unload-module module-snap-policy" and unloading
  the snap policy module, these work reliably.

  I have verified this in a fresh install of Ubuntu 20.04 in a VM.

  STEPS TO REPRODUCE
  =
  a) Either build a snap with classic confinement that sends these commands on 
the pulseaudio native protocol socket. (This is how I found the bug)
  b) Or, what I did here to easier reproduce, abuse the sandbox of a random 
classic snap:

  Download the attached bug.tgz with a minimal reproducer. It contains
  the source code for a program that sends load and unload commands to
  pulse. Unfortunately `pacmd` has a pid-file check that fails inside
  the sandbox and doesn't work. The reproducer does essentially the same
  as "pacmd load/unload-module" though.

  (a pre-compiled x64 binary is also included in case you don't have a
  go compiler and dare to run an untrusted binary in a VM)

  Unpack the tgz, build it, if necessary with "go mod download && go
  build"

  Grab a random classic mode snap to use its sandbox as a test bed:

  $ sudo snap install atom --classic
  atom 1.48.0 from Snapcrafters installed

  Open a shell in its sandbox:

  snap run --shell atom
  
  Navigate to the compiled binary and execute it a few times:

  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:10 PulseAudio connection created successfully
  2020/07/08 18:46:10 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:11 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 40
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  Loaded Module sucessfully at index: 41
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:12 PulseAudio connection created successfully
  2020/07/08 18:46:12 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:14 PulseAudio connection created successfully
  2020/07/08 18:46:14 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied
  user@user-Standard-PC-Q35-ICH9-2009:~/bug$ ./bug 
  2020/07/08 18:46:15 PulseAudio connection created successfully
  2020/07/08 18:46:15 Couldn't load module, error message: PulseAudio 
error: commandLoadModule -> Access denied

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

  to unload the snap-policy module from pulseaudio, now run ./bug a few
  more times. It now succeeds reliably, every time.

  Side note, with the real program on my actual machine, the race seems
  to behave slightly differently. It seems not to work the first time an
  application is started, but closing it and reopening it seems to make
  it work pretty reliably afterwards. Restarting "snapd", causes the
  following run the snap to fail again.

  EXPECTED BEHAVIOUR
  ==

  The pulseaudio snap policy module should correctly determine and
  enforce it's policy.

  ACTUAL BEHAVIOUR
  

  The pulseaudio snap policy module seemingly at random denies access
  when the snap has the permissions to do

[Desktop-packages] [Bug 1858636] Re: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium

[James Henstridge]

I've just been reading through the code used to build the bin/fc-
cache-v6 and bin/fc-cache-v7 binaries in the core snap:

https://github.com/snapcore/fc-cache-static-builder

I think I understand what the problem is: while it is rebuilding copies
of xenial's and bionic's fontconfig tools that statically link to
libfontconfig, it's using the xenial version of libfreetype2 for both.

I suspect that this old freetype version does not understand all the
features of the font (e.g. the scalable colour emoji), so the generated
cache also misses them.

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

Title:
  snapd generates incomplete fontconfig caches, result in emoji
  rendering issue in chromium

Status in chromium-browser package in Ubuntu:
  Invalid
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  I’ve recently noticed that Chromium no longer can display emoji. All I
  get are square boxes and some black & white symbols. E.g.
  https://getemoji.com renders like the screenshot I posted to
  https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-
  to-snap-transition/11179/237.

  I'm like 95% sure that this is a recent problem, and that I didn't
  have it when I first upgraded to Ubuntu 19.10 and to the snapified
  Chromium.

  Note that I don't have fonts-symbola installed, and I do have fonts-
  not-color-emoji installed.  I've also noticed a bunch of

  saus. 07 14:08:40 blynas chromium_chromium.desktop[4802]: Fontconfig error: 
Cannot load default config file
  saus. 07 14:08:40 blynas chromium_chromium.desktop[4802]: Fontconfig error: 
Cannot load default config file
  saus. 07 14:08:41 blynas chromium_chromium.desktop[4802]: Fontconfig error: 
Cannot load default config file
  saus. 07 14:08:43 blynas chromium_chromium.desktop[4802]: Fontconfig error: 
Cannot load default config file

  messages in journalctl when I first launch chromium.
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  DRM.card0-DP-1:
   enabled: disabled
   dpms: Off
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-DP-2:
   enabled: disabled
   dpms: Off
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-DP-3:
   enabled: enabled
   dpms: On
   status: connected
   edid-base64: 
AP///wAebfl2IdYEAAkbAQOAUCJ46sqVplVOoSYPUFQla4BxQIGAgcCpwLMA0cCBANHPzUYAoKA4H0AwIDoAHk4xAAAaKVkAoKA4J0AwIDoAHk4xAAAa/QA4Sx5aGAAKICAgICAg/ABMRyBVTFRSQVdJREUKAZACAxrxIwkHB0cQBAMBHxMSgwEAAGUDDAAQAIwK0Iog4C0QED6WAB5OMQAAGP8ANzA5TlRXRzlBOTYxCgAAQg==
   modes: 2560x1080 2560x1080 1920x1080 1920x1080 1920x1080 1920x1080 1920x1080 
1680x1050 1600x900 1280x1024 1280x1024 1280x800 1152x864 1152x864 1280x720 
1280x720 1280x720 1280x720 1024x768 1024x768 832x624 800x600 800x600 720x576 
720x480 720x480 720x480 720x480 640x480 640x480 640x480 640x480
  DRM.card0-DP-4:
   enabled: disabled
   dpms: On
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-DP-5:
   enabled: disabled
   dpms: On
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-HDMI-A-1:
   enabled: disabled
   dpms: Off
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-HDMI-A-2:
   enabled: disabled
   dpms: Off
   status: disconnected
   edid-base64:
   modes:
  DRM.card0-eDP-1:
   enabled: enabled
   dpms: On
   status: connected
   edid-base64: 
AP///wAGry1aAAAcAQSlHRF4Au6Vo1RMmSYPUFQBAQEBAQEBAQEBAQEBAQEBtDeAoHA4PkA6KjUAJaUQAAAYDwAg/gBBVU8KICAgICAgICAg/gBCMTMzSEFOMDUuQSAKAHA=
   modes: 1920x1080
  DiskUsage:
   Filesystem Type   Size  Used Avail Use% Mounted on
   /dev/nvme0n1p5 ext4   284G  241G   29G  90% /
   tmpfs  tmpfs  7,7G  164M  7,6G   3% /dev/shm
   /dev/nvme0n1p5 ext4   284G  241G   29G  90% /
  DistroRelease: Ubuntu 19.10
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2019-06-12 (208 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  MachineType: LENOVO 20Q0CTO1WW
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: chromium-browser 77.0.3865.120-0ubuntu1.19.10.1
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-24-generic 
root=UUID=ad2946f7-6a38-471f-b7d1-779e8e9fd109 ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
  Snap.ChromeDriverVersion: ChromeDriver 79.0.3945.79 
(29f75ce3f42b007bd80361b0dfcfee3a13ff90b8-refs/branch-heads/3945@{#916})
  Snap.ChromiumVersion: Chromium 79.0.3945.79 snap
  Tags:  eoan wayland-session snap
  Uname: Linux 5.3.0-24-generic x86_64
  UpgradeStatus: Upgraded to eoan on 2019-10-18 (80 days ago)
  UserGroups: adm cdrom dip docker libvirt lpadmin lxd plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios

[Desktop-packages] [Bug 1867080] Re: No mouse cursor drawn in Wayland session

[James Henstridge]

** Attachment added: "lspci.txt"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1867080/+attachment/5335924/+files/lspci.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/1867080

Title:
  [radeon] No mouse cursor drawn in Wayland session

Status in Mutter:
  Unknown
Status in gnome-shell package in Ubuntu:
  Invalid
Status in mutter package in Ubuntu:
  Triaged

Bug description:
  When I upgraded my desktop yesterday, I could no longer see the mouse
  cursor on the screen.  It still responded to mouse clicks (e.g.
  context menu on right click, pushing the mouse to the top left and
  left clicking went to spread mode, etc).

  This only seems to affect the Wayland session: when I switched back to
  X11 the mouse cursor was visible again.  I also noticed that the mouse
  cursor is absent on the GDM login screen, which I understand is also a
  Wayland based gnome-shell session.

  I tried reproducing the bug on my laptop, but the mouse cursor shows
  just fine there.  The main differences between the systems are the GPU
  (radeon vs. intel) and number of monitors (dual screen vs. single).

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gnome-shell 3.35.91-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
  Uname: Linux 5.4.0-14-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu20
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar 12 10:28:55 2020
  DisplayManager: gdm3
  InstallationDate: Installed on 2013-10-29 (2325 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 
(20131016.1)
  RelatedPackageVersions: mutter-common 3.35.91-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to focal on 2020-02-02 (38 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1867080/+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 1867080] [NEW] No mouse cursor drawn in Wayland session

[James Henstridge]

Public bug reported:

When I upgraded my desktop yesterday, I could no longer see the mouse
cursor on the screen.  It still responded to mouse clicks (e.g. context
menu on right click, pushing the mouse to the top left and left clicking
went to spread mode, etc).

This only seems to affect the Wayland session: when I switched back to
X11 the mouse cursor was visible again.  I also noticed that the mouse
cursor is absent on the GDM login screen, which I understand is also a
Wayland based gnome-shell session.

I tried reproducing the bug on my laptop, but the mouse cursor shows
just fine there.  The main differences between the systems are the GPU
(radeon vs. intel) and number of monitors (dual screen vs. single).

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.35.91-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
Uname: Linux 5.4.0-14-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu20
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 12 10:28:55 2020
DisplayManager: gdm3
InstallationDate: Installed on 2013-10-29 (2325 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
RelatedPackageVersions: mutter-common 3.35.91-1ubuntu1
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to focal on 2020-02-02 (38 days ago)

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


** Tags: amd64 apport-bug focal

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

Title:
  No mouse cursor drawn in Wayland session

Status in gnome-shell package in Ubuntu:
  New

Bug description:
  When I upgraded my desktop yesterday, I could no longer see the mouse
  cursor on the screen.  It still responded to mouse clicks (e.g.
  context menu on right click, pushing the mouse to the top left and
  left clicking went to spread mode, etc).

  This only seems to affect the Wayland session: when I switched back to
  X11 the mouse cursor was visible again.  I also noticed that the mouse
  cursor is absent on the GDM login screen, which I understand is also a
  Wayland based gnome-shell session.

  I tried reproducing the bug on my laptop, but the mouse cursor shows
  just fine there.  The main differences between the systems are the GPU
  (radeon vs. intel) and number of monitors (dual screen vs. single).

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gnome-shell 3.35.91-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
  Uname: Linux 5.4.0-14-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu20
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar 12 10:28:55 2020
  DisplayManager: gdm3
  InstallationDate: Installed on 2013-10-29 (2325 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 
(20131016.1)
  RelatedPackageVersions: mutter-common 3.35.91-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: Upgraded to focal on 2020-02-02 (38 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1867080/+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 1865371] Re: Mouse Cursor or Touchpad indicator/pointer not working

[James Henstridge]

I noticed something like this on my desktop system after upgrading.  It
only seems to affect Wayland sessions (i.e. GDM login screen and Ubuntu
on Wayland).  The mouse still works (i.e. desktop responds to clicks),
but no cursor is drawn.  Everything seems fine on my laptop though.

The main differences between the two systems are:

1. Radeon graphics on the desktop vs. Intel on the laptop
2. dual monitors on the desktop
3. The desktop is using a "Thinkpad Compact USB Keyboard" as the mouse (i.e. 
single USB device exposing two HID interfaces).

Given that the reporter here is using an AMD APU, I wonder if this is an
interaction between gnome-shell and the radeon driver?

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

Title:
  Mouse Cursor or Touchpad indicator/pointer not working

Status in gnome-shell package in Ubuntu:
  Incomplete

Bug description:
  after some updates this week, my mouse/touchapad
  cursor/indicator/pointer started not working

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gdm3 3.34.1-1ubuntu1
  Uname: Linux 5.5.7-050507-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu18
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Mar  1 20:29:07 2020
  InstallationDate: Installed on 2017-07-14 (960 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170714)
  SourcePackage: gdm3
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.gdm3.custom.conf: 2018-10-29T04:23:27.400327

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1865371/+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 1862158] Re: gnome-software tries to install snap updates in the background, causing unprompted polkit authentication for authorisation to install packages

[James Henstridge]

Is there some way gnome-software can inform the plugin that it is
performing a non-interactive operation?

If so, then the plugin could use snapd_client_set_allow_interaction() to
suppress any potential pokit dialogs from the operation.  It wouldn't
allow the operation to succeed, but it also wouldn't leave the user with
an authentication dialog open when they unlock their screen.

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

Title:
  gnome-software tries to install snap updates in the background,
  causing unprompted polkit authentication for authorisation to install
  packages

Status in gnome-software package in Ubuntu:
  New

Bug description:
  Every morning about ~30mins after powering on my focal machine I get
  (unprompted) a gnome-shell policykit authorisation popup saying
  'authentication is required to install software' - I haven't yet
  actually authorised it since I wasn't sure what was causing it,
  however I notice that if I cancel the authorisation then I see a bunch
  of notifications from gnome-software about updates having been
  successfully installed (even though I presume it hasn't been since I
  never authorised it).

  Is gnome-software fighting snapd to refresh snaps?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gnome-software 3.35.2-0ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb  6 21:37:29 2020
  InstallationDate: Installed on 2019-11-18 (79 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-snap3.35.2-0ubuntu1
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to focal on 2020-01-22 (15 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1862158/+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 1856054] Re: pulseaudio now depends on libsnapd-glib1 which recommends snapd

[James Henstridge]

If you are worried about what the Pulse Audio change is actually doing,
here's a description:

 1. there is a new "snap-policy" PA module that is loaded by default.

 2. when a client attempts to use the microphone and has a "snap.*"
AppArmor label, it contacts snapd to check whether that app has
permission to record audio (as opposed to simply playing sounds).

 3. if the client is not a snap application or it is a snap application
with record access, then PA will create record stream.

So there should be no problem with removing snapd again.  In fact the
policy module should effectively be inert if no snaps are ever run, not
even trying to talk to snapd.

The "Recommends: snapd" is definitely too strong for the way Pulse Audio
is using libsnapd-glib.  Once snapd-glib's dependency is relaxed, we
should be able to push this update again.

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

Title:
  pulseaudio now depends on libsnapd-glib1 which recommends snapd

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  The latest update for pulseaudio (1:11.1-1ubuntu7.5) in bionic now has
  libsnapd-glib1 as a dependency.

  This is complete and utter nonsense. I do not want cascading
  dependencies that have no business being installed on the systems I
  manage.

  Please rectify this at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1856054/+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 1781428] Re: please enable snap mediation support

[James Henstridge]

The two packages are in the upload queue now:


https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=pulseaudio

https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=pulseaudio

One additional acceptance test would be to verify that the policy module
continues to work across snapd restarts.  So at the end of the test
script, add something like:

The policy module continues to function over snapd restarts:

$ sudo systemctl restart snapd.service
$ test-snapd-audio-record.record /tmp/out.wav && echo yes # should pass
...
^Cyes

This was a problem with old versions of snapd-glib (before 1.44, I
think), but shouldn't be a problem now.

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Triaged
Status in pulseaudio source package in Bionic:
  Triaged

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For strict snaps with pulseaudio:
  $ sudo snap install --dangerous ./test-snapd-pulseaudio_1_amd64.snap

  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -

  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...

  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/

  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes

  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connecting which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)

  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes 

[Desktop-packages] [Bug 1781428] Re: please enable snap mediation support

[James Henstridge]

Attached is a debdiff for the Xenial version of the backport.  In
addition to the snap policy module patches, this includes a backport of
the libjson-c dependency removal changes from Pulse Audio 10.0 (which
applied cleanly without modification).  This is required because
libjson-c and libjson-glib declare a few symbols with the same name,
causing problems for the policy module.

Based on discussion in
https://bugs.freedesktop.org/show_bug.cgi?id=95135, the libjson-c
dependency was causing problems for other applications too.

I was able to complete @jdstrand's test plan on a clean 16.04 install
with these updates.

pulseaudio (1:8.0-0ubuntu3.11) xenial; urgency=medium

  * Backport the snap policy module to make access to audio recording
conditional on plugging the "pulseaudio" or "audio-record" interfaces
(LP: #1781428):
- 0450-modules-add-snappy-policy-module.patch: rewrite to query
  snapd for the client's plugged interfaces.
- 0451-enable-snap-policy-module.patch: enable the module in the
  default configuration.
- Build depend on libsnapd-glib-dev.
  * Backport libjson-c dependency removal from Pulse Audio 10. This is
required by the snap policy module due to a symbol name clash with
libjson-glib.
- 0805-remove-libjson-c-dependency.patch: new file.

 -- James Henstridge   Tue, 05 Nov 2019
17:16:22 +0800

** Bug watch added: freedesktop.org Bugzilla #95135
   https://bugs.freedesktop.org/show_bug.cgi?id=95135

** Patch added: "pulseaudio_8.0-0ubuntu3.10_8.0-0ubuntu3.11.diff"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/+attachment/5303806/+files/pulseaudio_8.0-0ubuntu3.10_8.0-0ubuntu3.11.diff

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Triaged
Status in pulseaudio source package in Bionic:
  Triaged

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current

[Desktop-packages] [Bug 1781428] Re: please enable snap mediation support

[James Henstridge]

Attached is a debdiff for the bionic backport.  I've run through
@jdstrand's test plan on a clean Ubuntu 18.04 install, and everything
appears to be behaving as expected.

pulseaudio (1:11.1-1ubuntu7.5) bionic; urgency=medium

  * Update snap policy to make access to audio recording conditional on
plugging the "pulseaudio" or "audio-record" interfaces (LP: #1781428):
- 0700-modules-add-snappy-policy-module.patch: rewrite to query
  snapd for the client's plugged interfaces.
- 0701-enable-snap-policy-module.patch: enable the module in the
  default configuration.
- Build depend on libsnapd-glib-dev.
  * Remove module-trust-store patch set:
- 0409-Trust-store-patch.patch: trimmed down to pulsecore changes.
- 0410-Add-thread-to-activate-trust-store-interface.patch: removed.
- 0417-increase-timeout-check-apparmor.patch: removed.

 -- James Henstridge   Wed, 05 Nov 2019
17:16:25 +0800

** Patch added: "pulseaudio_11.1-1ubuntu7.4_11.1-1ubuntu7.5.diff"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/+attachment/5303689/+files/pulseaudio_11.1-1ubuntu7.4_11.1-1ubuntu7.5.diff

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Triaged
Status in pulseaudio source package in Bionic:
  Triaged

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For strict snaps with pulseaudio:
  $ sudo snap install --dangerous ./test-snapd-pulseaudio_1_amd64.snap

  $ snap connections test-snapd-pulseaudio
  Interface   P

[Desktop-packages] [Bug 1781428] Re: please enable snap mediation support

[James Henstridge]

The xenial backport is non-functional due to a symbol collision between
libjson-c.so (required by libpulse) and libjson-glib.so (required by
snapd-glib).  This doesn't affect the Bionic backport though.

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Triaged
Status in pulseaudio source package in Bionic:
  Triaged

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For strict snaps with pulseaudio:
  $ sudo snap install --dangerous ./test-snapd-pulseaudio_1_amd64.snap

  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -

  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...

  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/

  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes

  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connecting which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)

  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes

  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes

  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
  $ sudo snap install --dangerous ./test-snapd-audio-record_1_amd64.snap

  $ snap connections test-snapd-audio-record  # record not connected
  Interface   PlugSlot Notes
  audio-playback  

[Desktop-packages] [Bug 1843764] Re: sane-backends ftbfs in eoan (armhf)

[James Henstridge]

Does it actually make sense to have symbols files for plugins?  As long
as they work with the libsane.so.1 that they're shipped with, does it
matter what symbols they export?

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

Title:
  sane-backends ftbfs in eoan (armhf)

Status in sane-backends package in Ubuntu:
  Confirmed
Status in sane-backends source package in Eoan:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441263700/buildlog_ubuntu-eoan-armhf
  .sane-backends_1.0.27-3.2ubuntu2_BUILDING.txt.gz

  dpkg-gensymbols: warning: debian/libsane/DEBIAN/symbols doesn't match 
completely debian/libsane.symbols.armhf
  --- debian/libsane.symbols.armhf (libsane_1.0.27_armhf)
  +++ dpkg-gensymbolsHF3hxU 2019-09-09 11:12:09.992951725 +
  @@ -4304,7 +4304,7 @@
sanei_constrain_value@Base 1.0.25
sanei_debug_msg@Base 1.0.25
sanei_debug_mustek@Base 1.0.25
  - sanei_debug_sanei_ab306@Base 1.0.25
  +#MISSING: 1.0.27# sanei_debug_sanei_ab306@Base 1.0.25
sanei_debug_sanei_config@Base 1.0.25
sanei_debug_sanei_debug@Base 1.0.25
sanei_debug_sanei_pa4s2@Base 1.0.25
  @@ -5390,7 +5390,7 @@
sanei_pp_outb_addr@Base 1.0.25
sanei_pp_outb_ctrl@Base 1.0.25
sanei_pp_outb_data@Base 1.0.25
  - sanei_pp_outb_epp@Base 1.0.25
  +#MISSING: 1.0.27# sanei_pp_outb_epp@Base 1.0.25
sanei_pp_release@Base 1.0.25
sanei_pp_set_datadir@Base 1.0.25
sanei_pp_setmode@Base 1.0.25
  @@ -5452,59 +5452,6 @@
sanei_debug_sanei_config@Base 1.0.25
sanei_debug_sanei_debug@Base 1.0.25
sanei_init_debug@Base 1.0.25
  -libsane-qcam.so.1 libsane #MINVER#
  - md5_buffer@Base 1.0.27
  - md5_finish_ctx@Base 1.0.27
  - md5_init_ctx@Base 1.0.27
  - md5_process_block@Base 1.0.27
  - md5_process_bytes@Base 1.0.27
  - md5_read_ctx@Base 1.0.27
  - md5_stream@Base 1.0.27
  - sane_cancel@Base 1.0.25
  - sane_close@Base 1.0.25
  - sane_control_option@Base 1.0.25
  - sane_exit@Base 1.0.25
  - sane_get_devices@Base 1.0.25
  - sane_get_option_descriptor@Base 1.0.25
  - sane_get_parameters@Base 1.0.25
  - sane_get_select_fd@Base 1.0.25
  - sane_init@Base 1.0.25
  - sane_open@Base 1.0.25
  - sane_qcam_cancel@Base 1.0.25
  - sane_qcam_close@Base 1.0.25
  - sane_qcam_control_option@Base 1.0.25
  - sane_qcam_exit@Base 1.0.25
  - sane_qcam_get_devices@Base 1.0.25
  - sane_qcam_get_option_descriptor@Base 1.0.25
  - sane_qcam_get_parameters@Base 1.0.25
  - sane_qcam_get_select_fd@Base 1.0.25
  - sane_qcam_init@Base 1.0.25
  - sane_qcam_open@Base 1.0.25
  - sane_qcam_read@Base 1.0.25
  - sane_qcam_set_io_mode@Base 1.0.25
  - sane_qcam_start@Base 1.0.25
  - sane_read@Base 1.0.25
  - sane_set_io_mode@Base 1.0.25
  - sane_start@Base 1.0.25
  - sane_strstatus@Base 1.0.25
  - sanei_check_value@Base 1.0.25
  - sanei_config_get_paths@Base 1.0.25
  - sanei_config_get_string@Base 1.0.25
  - sanei_config_open@Base 1.0.25
  - sanei_config_read@Base 1.0.25
  - sanei_config_skip_whitespace@Base 1.0.25
  - sanei_configure_attach@Base 1.0.25
  - sanei_constrain_value@Base 1.0.25
  - sanei_debug_msg@Base 1.0.25
  - sanei_debug_qcam@Base 1.0.25
  - sanei_debug_sanei_config@Base 1.0.25
  - sanei_debug_sanei_debug@Base 1.0.25
  - sanei_debug_sanei_pio@Base 1.0.25
  - sanei_init_debug@Base 1.0.25
  - sanei_pio_close@Base 1.0.25
  - sanei_pio_open@Base 1.0.25
  - sanei_pio_read@Base 1.0.25
  - sanei_pio_write@Base 1.0.25
   libsane-ricoh.so.1 libsane #MINVER#
md5_buffer@Base 1.0.27
md5_finish_ctx@Base 1.0.27
  @@ -7142,7 +7089,7 @@
sanei_constrain_value@Base 1.0.24
sanei_debug_dll@Base 1.0.25
sanei_debug_msg@Base 1.0.24
  - sanei_debug_sanei_ab306@Base 1.0.25
  +#MISSING: 1.0.27# sanei_debug_sanei_ab306@Base 1.0.25
sanei_debug_sanei_access@Base 1.0.25
sanei_debug_sanei_config@Base 1.0.24
sanei_debug_sanei_debug@Base 1.0.24
  @@ -7204,7 +7151,7 @@
sanei_pp_outb_addr@Base 1.0.25
sanei_pp_outb_ctrl@Base 1.0.25
sanei_pp_outb_data@Base 1.0.25
  - sanei_pp_outb_epp@Base 1.0.25
  +#MISSING: 1.0.27# sanei_pp_outb_epp@Base 1.0.25
sanei_pp_release@Base 1.0.25
sanei_pp_set_datadir@Base 1.0.25
sanei_pp_setmode@Base 1.0.25
  dh_makeshlibs: failing due to earlier errors

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1843764/+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 1811707] Re: gnome-calculator snap does not respect shell theme

[James Henstridge]

If you are running an X session, then you are running into a different
issue.

The set of circumstances that lead to the problem on Wayland (different
gsettings defaults inside and outside of confinement) do not apply to
X11 where the theme is exposed by the host over XSETTINGS (so sees the
default of the host system).  I'd suggest filing a new bug with more
details if you're on an X11 session.

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

Title:
  gnome-calculator snap does not respect shell theme

Status in gnome-calculator package in Ubuntu:
  Incomplete

Bug description:
  I'm running 18.04 with Communitheme / Yaru.  The gnome-calculator snap
  doesn't appear to respect this where other snaps do.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1811707/+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 1816436] Re: gnome-terminal window shrinks when changing tabs

[James Henstridge]

At didrocks' request, I've also filed this here:

https://github.com/ubuntu/yaru/issues/1196

** Bug watch added: github.com/ubuntu/yaru/issues #1196
   https://github.com/ubuntu/yaru/issues/1196

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

Title:
  gnome-terminal window shrinks when changing tabs

Status in gnome-terminal package in Ubuntu:
  New
Status in yaru-theme package in Ubuntu:
  New

Bug description:
  I am using gnome-terminal 3.31.90-1ubuntu1 on a Disco desktop.  If I
  create a gnome-terminal window and add a second tab, the window will
  shrink by one line each time I switch tabs.

  This seems to be theme related, since it happens with Yaru but not
  with Adwaita.  Some aspects of my configuration that seem to be
  relevant:

  1. Using yaru-theme-gtk version 19.04

  2. Under the org.gnome.desktop.interface gsettings schema, I have
  scaling-factor set to 1 and  text-scaling-factor set to 1.5

  This may lead to some widgets size being dictated by the text height
  where they might be governed by min-height otherwise.

  I suspect that the height notebook tabs are changing when changing
  from selected to unselected state, and gnome-terminal then tries to
  resize the window to align to the terminal character grid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1816436/+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 1816436] [NEW] gnome-terminal window shrinks when changing tabs

[James Henstridge]

Public bug reported:

I am using gnome-terminal 3.31.90-1ubuntu1 on a Disco desktop.  If I
create a gnome-terminal window and add a second tab, the window will
shrink by one line each time I switch tabs.

This seems to be theme related, since it happens with Yaru but not with
Adwaita.  Some aspects of my configuration that seem to be relevant:

1. Using yaru-theme-gtk version 19.04

2. Under the org.gnome.desktop.interface gsettings schema, I have
scaling-factor set to 1 and  text-scaling-factor set to 1.5

This may lead to some widgets size being dictated by the text height
where they might be governed by min-height otherwise.

I suspect that the height notebook tabs are changing when changing from
selected to unselected state, and gnome-terminal then tries to resize
the window to align to the terminal character grid.

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

** Affects: yaru-theme (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: yaru-theme (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  gnome-terminal window shrinks when changing tabs

Status in gnome-terminal package in Ubuntu:
  New
Status in yaru-theme package in Ubuntu:
  New

Bug description:
  I am using gnome-terminal 3.31.90-1ubuntu1 on a Disco desktop.  If I
  create a gnome-terminal window and add a second tab, the window will
  shrink by one line each time I switch tabs.

  This seems to be theme related, since it happens with Yaru but not
  with Adwaita.  Some aspects of my configuration that seem to be
  relevant:

  1. Using yaru-theme-gtk version 19.04

  2. Under the org.gnome.desktop.interface gsettings schema, I have
  scaling-factor set to 1 and  text-scaling-factor set to 1.5

  This may lead to some widgets size being dictated by the text height
  where they might be governed by min-height otherwise.

  I suspect that the height notebook tabs are changing when changing
  from selected to unselected state, and gnome-terminal then tries to
  resize the window to align to the terminal character grid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1816436/+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 1810757] Re: /usr/libexec/xdg-document-portal:6:g_assertion_message:g_assertion_message_expr:xdp_inode_destroy:xdp_inode_unref_internal:xdp_inode_unref_internal

[James Henstridge]

This bug occurs when using the "SaveFile" desktop portal API and the
user chooses a new file name rather than overwriting an existing file.

It can easily be reproduced with the following steps:

1. install the test-snapd-portal-client snap:

snap install --edge test-snapd-portal-client

2. run the save-file test:

test-snapd-portal-client save-file "foo"

3. in the file chooser, select a file name that does not exist.

The command will fail with a ConnectionAbortedError exception, and xdg-
document-portal will crash with the following in the log:

Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: Invalid id 
snap.test-snapd-portal-client: Names must contain at least 2 periods
Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: **
Jan 07 17:38:06 scruffy xdg-document-portal[30685]: 
xdg-desktop-portal:ERROR:document-portal/document-portal-fuse.c:206:xdp_inode_destroy:
 assertion failed: (inode->dir_fd == -1)

The problem does not occur with xdg-desktop-portal 1.0.3, so it is
likely that one of the patches alexl mentioned at
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-
portal/+bug/1691649/comments/10 would fix it.  With that said,
backporting 1.0.3 might be the better option if we want working portals.

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

Title:
  /usr/libexec/xdg-document-
  
portal:6:g_assertion_message:g_assertion_message_expr:xdp_inode_destroy:xdp_inode_unref_internal:xdp_inode_unref_internal

Status in xdg-desktop-portal package in Ubuntu:
  Confirmed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
xdg-desktop-portal.  This problem was most recently seen with package version 
1.0.2-1ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/38fed8b2e1a584847f0c29fac422a19313c40d3d 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1810757/+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 1810755] [NEW] xdg-document-portal 1.0.2-1ubuntu1 crashes when trying to save to a non-existant file

[James Henstridge]

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

Public bug reported:

When using the desktop portal API to save a file, the xdg-document-
portal service crashes if we try to save to a new file name.

Steps to reproduce:

1. On an Ubuntu 18.10 system, install the test-snapd-portal-client snap:

snap install --edge test-snapd-portal-client

2. run the save-file test:

test-snapd-portal-client save-file "foo"

3. in the file chooser, select a file name that does not exist.

Actual results:

The command exits with the following error (eliding the traceback):

ConnectionAbortedError: [Errno 103] Software caused connection
abort: '/run/user/1000/doc/eca716d3/xyz.txt'

Furthermore, "systemctl --user status xdg-document-portal.service"
reports the following error:

Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: Invalid id 
snap.test-snapd-portal-client: Names must contain at least 2 periods
Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: **
Jan 07 17:38:06 scruffy xdg-document-portal[30685]: 
xdg-desktop-portal:ERROR:document-portal/document-portal-fuse.c:206:xdp_inode_destroy:
 assertion failed: (inode->dir_fd == -1)


Expected results:

The file should be created with the contents "foo".

The problem is not present with xdg-desktop-portal 1.0.3.  I suspect the
fix is one of these extra patches alexl suggested we take:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-
portal/+bug/1691649/comments/10

** Affects: xdg-desktop-portal (Ubuntu)
 Importance: Undecided
 Status: New

** This bug has been marked a duplicate of bug 1810757
   
/usr/libexec/xdg-document-portal:6:g_assertion_message:g_assertion_message_expr:xdp_inode_destroy:xdp_inode_unref_internal:xdp_inode_unref_internal

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

Title:
  xdg-document-portal 1.0.2-1ubuntu1 crashes when trying to save to a
  non-existant file

Status in xdg-desktop-portal package in Ubuntu:
  New

Bug description:
  When using the desktop portal API to save a file, the xdg-document-
  portal service crashes if we try to save to a new file name.

  Steps to reproduce:

  1. On an Ubuntu 18.10 system, install the test-snapd-portal-client
  snap:

  snap install --edge test-snapd-portal-client

  2. run the save-file test:

  test-snapd-portal-client save-file "foo"

  3. in the file chooser, select a file name that does not exist.

  Actual results:

  The command exits with the following error (eliding the traceback):

  ConnectionAbortedError: [Errno 103] Software caused connection
  abort: '/run/user/1000/doc/eca716d3/xyz.txt'

  Furthermore, "systemctl --user status xdg-document-portal.service"
  reports the following error:

  Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: Invalid id 
snap.test-snapd-portal-client: Names must contain at least 2 periods
  Jan 07 17:38:06 scruffy xdg-document-portal[30685]: error: **
  Jan 07 17:38:06 scruffy xdg-document-portal[30685]: 
xdg-desktop-portal:ERROR:document-portal/document-portal-fuse.c:206:xdp_inode_destroy:
 assertion failed: (inode->dir_fd == -1)

  
  Expected results:

  The file should be created with the contents "foo".

  The problem is not present with xdg-desktop-portal 1.0.3.  I suspect
  the fix is one of these extra patches alexl suggested we take:
  https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-
  portal/+bug/1691649/comments/10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1810755/+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 1803534] Re: Backport uuid based cache file naming scheme

[James Henstridge]

** Description changed:

  Fontconfig 2.13.0 changed the cache file naming scheme to be based on
  the contents of ".uuid" file in the directory rather than a hash of the
  directory name.  On a pure debs system this doesn't really matter since
  everything is using the same libfontconfig.so.
  
  When snaps are involved, it can lead to some apps not seeing the cache
  files produced by a different fontconfig version.  In particular, while
  libfontconfig 2.13 can reuse 2.12's cache files for read only
  directories, the reverse is not true.  This will be a problem for apps
  built on top of the "core18" base snap when run on later Ubuntu releases
  (cosmic, disco, etc).
  
  By providing a backport of the UUID cache file feature to bionic for use
  by snap applications, we'd avoid this.  Having it in bionic-updates
  would be ideal so that snapcraft picks it up automatically.
+ 
+ [Impact]
+ 
+  * This update changes how fontconfig cache files are named, instead of
+ using md5($dir), it instead uses the contents of a $dir/.uuid file.  No
+ changes are made to the format of the cache file contents.
+ 
+  * This change is primarily intended for use by snap applications built
+ with core18: as the updated libfontconfig will fall back to the md5
+ cache file names for read-only directories without a .uuid file, they
+ will be able to reuse cache files from any host system running
+ fontconfig >= 2.11.95
+ 
+ [Test Case]
+ 
+  * After installing the update, cache files should be generated in
+ /var/cache/fontconfig/ with names like "07b67f7a-16ea-4440-9b6c-
+ 21fc9153568c-le64.cache-7" (note the extra dashes not present in the MD5
+ based cache file names).
+ 
+ [Regression Potential]
+ 
+  * Applications using a non-default libfontconfig could end up not
+ finding the new cache files and regenerating them in
+ ~/.cache/fontconfig.

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

Title:
  Backport uuid based cache file naming scheme

Status in fontconfig package in Ubuntu:
  New

Bug description:
  Fontconfig 2.13.0 changed the cache file naming scheme to be based on
  the contents of ".uuid" file in the directory rather than a hash of
  the directory name.  On a pure debs system this doesn't really matter
  since everything is using the same libfontconfig.so.

  When snaps are involved, it can lead to some apps not seeing the cache
  files produced by a different fontconfig version.  In particular,
  while libfontconfig 2.13 can reuse 2.12's cache files for read only
  directories, the reverse is not true.  This will be a problem for apps
  built on top of the "core18" base snap when run on later Ubuntu
  releases (cosmic, disco, etc).

  By providing a backport of the UUID cache file feature to bionic for
  use by snap applications, we'd avoid this.  Having it in bionic-
  updates would be ideal so that snapcraft picks it up automatically.

  [Impact]

   * This update changes how fontconfig cache files are named, instead
  of using md5($dir), it instead uses the contents of a $dir/.uuid file.
  No changes are made to the format of the cache file contents.

   * This change is primarily intended for use by snap applications
  built with core18: as the updated libfontconfig will fall back to the
  md5 cache file names for read-only directories without a .uuid file,
  they will be able to reuse cache files from any host system running
  fontconfig >= 2.11.95

  [Test Case]

   * After installing the update, cache files should be generated in
  /var/cache/fontconfig/ with names like "07b67f7a-16ea-4440-9b6c-
  21fc9153568c-le64.cache-7" (note the extra dashes not present in the
  MD5 based cache file names).

  [Regression Potential]

   * Applications using a non-default libfontconfig could end up not
  finding the new cache files and regenerating them in
  ~/.cache/fontconfig.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1803534/+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 1769383] Re: Ubuntu dock/launcher is shown on the lock screen

[James Henstridge]

Looking at the gnome-shell JS code referenced by the stack trace, it
appears it is indeed disabling extensions when locking the screen.

The screenShield.js code handles the lock screen, and pushes and pops a
"session mode" of "lock-screen".  In sessioMode.js, the "lock-screen"
mode is defined with allowExtensions=false.  Finally, extensionSystem.js
watches session mode changes and calls the various extension
enable/disable callbacks as needed.

So somehow ubuntu-dock has a stale window in
Transparency._trackedWindows that triggers an exception while trying to
disable the dock when locking the screen.  It fails to fully disable the
dock, so it displays over the top of the lock screen.

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

Title:
  Ubuntu dock/launcher is shown on the lock screen

Status in gnome-shell package in Ubuntu:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock package in Ubuntu:
  In Progress
Status in gnome-shell source package in Cosmic:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Cosmic:
  In Progress
Status in gnome-shell source package in Disco:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Disco:
  In Progress

Bug description:
  After an update from ubuntu 16.04 to 18.04 the dock is aviable on the 
lockscreen after user login.
  I did not configure this knowingly. Also i can start every application which 
is available on the dock.
  Settings, virtual box, visualstudio code and so on.

  After the update to 18.04 i just configure the screen frequency to
  144Hz and the night mode on. And attach the dock on bottom.

  I later undid these customizations back to configuration before, but
  the dock is stil aviable on lockscreen.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-settings-daemon 3.28.1-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 18:30:16 2018
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-settings-daemon
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (3 days ago)
  --- 
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  NonfreeKernelModules: nvidia_modeset nvidia
  Package: gnome-shell-extension-ubuntu-dock 0.9.1
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-20-generic x86_64
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (4 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1769383/+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 1769383] Re: Ubuntu dock/launcher is shown on the lock screen

[James Henstridge]

The above stack trace seems to be tied to this other message:

Nov 16 11:41:38 scruffy gnome-shell[5626]: Object Meta.WindowActor
(0x560d5092bb00), has been already deallocated — impossible to access
it. This might be caused by the object having been destroyed from C code
using something such as destroy(), dispose(), or remove() vfuncs.

The error seems to be on the disconnect() call in
Transparency.disable():

for (let key of this._trackedWindows.keys())
this._trackedWindows.get(key).forEach(id => {
key.disconnect(id);
});
this._trackedWindows.clear();

Presumably the remainder of the clean-up performed by this function and
its callers is not performed, leaving the shell in an inconsistent
state.

I'm still not sure why gnome-shell is trying to disable the extension.
Does it disable extensions when locking the screen?

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

Title:
  Ubuntu dock/launcher is shown on the lock screen

Status in gnome-shell package in Ubuntu:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock package in Ubuntu:
  In Progress
Status in gnome-shell source package in Cosmic:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Cosmic:
  In Progress
Status in gnome-shell source package in Disco:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Disco:
  In Progress

Bug description:
  After an update from ubuntu 16.04 to 18.04 the dock is aviable on the 
lockscreen after user login.
  I did not configure this knowingly. Also i can start every application which 
is available on the dock.
  Settings, virtual box, visualstudio code and so on.

  After the update to 18.04 i just configure the screen frequency to
  144Hz and the night mode on. And attach the dock on bottom.

  I later undid these customizations back to configuration before, but
  the dock is stil aviable on lockscreen.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-settings-daemon 3.28.1-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 18:30:16 2018
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-settings-daemon
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (3 days ago)
  --- 
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  NonfreeKernelModules: nvidia_modeset nvidia
  Package: gnome-shell-extension-ubuntu-dock 0.9.1
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-20-generic x86_64
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (4 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1769383/+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 1769383] Re: Ubuntu dock/launcher is shown on the lock screen

[James Henstridge]

I noticed this behaviour on my Ubuntu 18.10 system.  It is running the
Wayland session, and I only have the ubuntu-d...@ubuntu.com and ubuntu-
appindicat...@ubuntu.com extensions installed (i.e. no upstream dash-to-
dock).

I looked in the journal and found the attached GJS stack trace, which
seems to be triggered by the disable() call.  I haven't been manually
enabling/disabling extensions, so don't know why the code path would
have been triggered.  It might mean some crud was left behind though.

** Attachment added: "stacktrace.txt"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/1769383/+attachment/5213307/+files/stacktrace.txt

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

Title:
  Ubuntu dock/launcher is shown on the lock screen

Status in gnome-shell package in Ubuntu:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock package in Ubuntu:
  In Progress
Status in gnome-shell source package in Cosmic:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Cosmic:
  In Progress
Status in gnome-shell source package in Disco:
  Incomplete
Status in gnome-shell-extension-ubuntu-dock source package in Disco:
  In Progress

Bug description:
  After an update from ubuntu 16.04 to 18.04 the dock is aviable on the 
lockscreen after user login.
  I did not configure this knowingly. Also i can start every application which 
is available on the dock.
  Settings, virtual box, visualstudio code and so on.

  After the update to 18.04 i just configure the screen frequency to
  144Hz and the night mode on. And attach the dock on bottom.

  I later undid these customizations back to configuration before, but
  the dock is stil aviable on lockscreen.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-settings-daemon 3.28.1-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 18:30:16 2018
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-settings-daemon
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (3 days ago)
  --- 
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-04-08 (27 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  NonfreeKernelModules: nvidia_modeset nvidia
  Package: gnome-shell-extension-ubuntu-dock 0.9.1
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-20-generic x86_64
  UpgradeStatus: Upgraded to bionic on 2018-05-01 (4 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1769383/+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 1803534] Re: Backport uuid based cache file naming scheme

[James Henstridge]

A backport of the UUID cache file directory feature from fontconfig
2.13.

** Patch added: "fontconfig_2.12.6-0ubuntu2_2.12.6-0ubuntu3.diff"
   
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1803534/+attachment/5213086/+files/fontconfig_2.12.6-0ubuntu2_2.12.6-0ubuntu3.diff

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

Title:
  Backport uuid based cache file naming scheme

Status in fontconfig package in Ubuntu:
  New

Bug description:
  Fontconfig 2.13.0 changed the cache file naming scheme to be based on
  the contents of ".uuid" file in the directory rather than a hash of
  the directory name.  On a pure debs system this doesn't really matter
  since everything is using the same libfontconfig.so.

  When snaps are involved, it can lead to some apps not seeing the cache
  files produced by a different fontconfig version.  In particular,
  while libfontconfig 2.13 can reuse 2.12's cache files for read only
  directories, the reverse is not true.  This will be a problem for apps
  built on top of the "core18" base snap when run on later Ubuntu
  releases (cosmic, disco, etc).

  By providing a backport of the UUID cache file feature to bionic for
  use by snap applications, we'd avoid this.  Having it in bionic-
  updates would be ideal so that snapcraft picks it up automatically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1803534/+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 1803534] [NEW] Backport uuid based cache file naming scheme

[James Henstridge]

Public bug reported:

Fontconfig 2.13.0 changed the cache file naming scheme to be based on
the contents of ".uuid" file in the directory rather than a hash of the
directory name.  On a pure debs system this doesn't really matter since
everything is using the same libfontconfig.so.

When snaps are involved, it can lead to some apps not seeing the cache
files produced by a different fontconfig version.  In particular, while
libfontconfig 2.13 can reuse 2.12's cache files for read only
directories, the reverse is not true.  This will be a problem for apps
built on top of the "core18" base snap when run on later Ubuntu releases
(cosmic, disco, etc).

By providing a backport of the UUID cache file feature to bionic for use
by snap applications, we'd avoid this.  Having it in bionic-updates
would be ideal so that snapcraft picks it up automatically.

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

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

Title:
  Backport uuid based cache file naming scheme

Status in fontconfig package in Ubuntu:
  New

Bug description:
  Fontconfig 2.13.0 changed the cache file naming scheme to be based on
  the contents of ".uuid" file in the directory rather than a hash of
  the directory name.  On a pure debs system this doesn't really matter
  since everything is using the same libfontconfig.so.

  When snaps are involved, it can lead to some apps not seeing the cache
  files produced by a different fontconfig version.  In particular,
  while libfontconfig 2.13 can reuse 2.12's cache files for read only
  directories, the reverse is not true.  This will be a problem for apps
  built on top of the "core18" base snap when run on later Ubuntu
  releases (cosmic, disco, etc).

  By providing a backport of the UUID cache file feature to bionic for
  use by snap applications, we'd avoid this.  Having it in bionic-
  updates would be ideal so that snapcraft picks it up automatically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1803534/+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 1793298] [NEW] snapd-glib changes needed for pulseaudio snap policy module xenial backport

[James Henstridge]

Public bug reported:

The xenial backport of the fix for 1781428 malfunctioned due to the use
of snapd-glib behaviour introduced after the version included in xenial:
namely auto-connection (and reconnection) to the snapd socket that was
introduced in snapd-glib 1.24.

With the policy module loaded, Pulse Audio will contact snapd to check
the interfaces plugged by a client in order to decide whether to provide
access to the microphone.  As the Pulse Audio daemon is long lived, it
is not uncommon for the socket connection to be disconnected (either due
to a timeout, or because snapd is upgraded while the user is logged in).
So simply adding a snapd_client_connect() call at module initialisation
time is not sufficient.

The specific snapd-glib calls that could be affected are:

 * snapd_client_list_one_async
 * snapd_client_get_interfaces_async

** Affects: snapd-glib (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  snapd-glib changes needed for pulseaudio snap policy module xenial
  backport

Status in snapd-glib package in Ubuntu:
  New

Bug description:
  The xenial backport of the fix for 1781428 malfunctioned due to the
  use of snapd-glib behaviour introduced after the version included in
  xenial: namely auto-connection (and reconnection) to the snapd socket
  that was introduced in snapd-glib 1.24.

  With the policy module loaded, Pulse Audio will contact snapd to check
  the interfaces plugged by a client in order to decide whether to
  provide access to the microphone.  As the Pulse Audio daemon is long
  lived, it is not uncommon for the socket connection to be disconnected
  (either due to a timeout, or because snapd is upgraded while the user
  is logged in).  So simply adding a snapd_client_connect() call at
  module initialisation time is not sufficient.

  The specific snapd-glib calls that could be affected are:

   * snapd_client_list_one_async
   * snapd_client_get_interfaces_async

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1793298/+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 1787324] Re: Snap policy module denies recording access to classic snaps

[James Henstridge]

Here is a debdiff based on the attached branch.

** Patch added: "pulseaudio_12.2-0ubuntu2_12.2-0ubuntu3.diff"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1787324/+attachment/5181694/+files/pulseaudio_12.2-0ubuntu2_12.2-0ubuntu3.diff

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

Title:
  Snap policy module denies recording access to classic snaps

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  With the recent updates to the snap policy module, recording access is
  denied to clients with a snap AppArmor label when that snap doesn't
  have a connected plug for "pulseaudio" or "audio-record".

  This is not appropriate for classic confinement snaps, which will have
  an AppArmor label but should still have access to recording even when
  there is no plug, as described by @jdstrand:

  https://forum.snapcraft.io/t/pulseaudio-recording/6361/14?u=jamesh

  This is broken with the 1:12.2-0ubuntu2 release, as can be seen with
  e.g.:

  $ aa-exec -p snap.skype.skype /usr/bin/parecord foo.wav
  Stream error: Access denied

  [note that the Skype app itself still functions because it bypasses
  PulseAudio all together]

  The above command should result in audio being recorded from the
  microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1787324/+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 1787324] Re: Snap policy module denies recording access to classic snaps

[James Henstridge]

** Merge proposal linked:
   
https://code.launchpad.net/~ubuntu-audio-dev/pulseaudio/+git/pulseaudio/+merge/353214

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

Title:
  Snap policy module denies recording access to classic snaps

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  With the recent updates to the snap policy module, recording access is
  denied to clients with a snap AppArmor label when that snap doesn't
  have a connected plug for "pulseaudio" or "audio-record".

  This is not appropriate for classic confinement snaps, which will have
  an AppArmor label but should still have access to recording even when
  there is no plug, as described by @jdstrand:

  https://forum.snapcraft.io/t/pulseaudio-recording/6361/14?u=jamesh

  This is broken with the 1:12.2-0ubuntu2 release, as can be seen with
  e.g.:

  $ aa-exec -p snap.skype.skype /usr/bin/parecord foo.wav
  Stream error: Access denied

  [note that the Skype app itself still functions because it bypasses
  PulseAudio all together]

  The above command should result in audio being recorded from the
  microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1787324/+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 1787324] [NEW] Snap policy module denies recording access to classic snaps

[James Henstridge]

Public bug reported:

With the recent updates to the snap policy module, recording access is
denied to clients with a snap AppArmor label when that snap doesn't have
a connected plug for "pulseaudio" or "audio-record".

This is not appropriate for classic confinement snaps, which will have
an AppArmor label but should still have access to recording even when
there is no plug, as described by @jdstrand:

https://forum.snapcraft.io/t/pulseaudio-recording/6361/14?u=jamesh

This is broken with the 1:12.2-0ubuntu2 release, as can be seen with
e.g.:

$ aa-exec -p snap.skype.skype /usr/bin/parecord foo.wav
Stream error: Access denied

[note that the Skype app itself still functions because it bypasses
PulseAudio all together]

The above command should result in audio being recorded from the
microphone.

** Affects: pulseaudio (Ubuntu)
 Importance: High
 Assignee: James Henstridge (jamesh)
 Status: Confirmed

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

Title:
  Snap policy module denies recording access to classic snaps

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  With the recent updates to the snap policy module, recording access is
  denied to clients with a snap AppArmor label when that snap doesn't
  have a connected plug for "pulseaudio" or "audio-record".

  This is not appropriate for classic confinement snaps, which will have
  an AppArmor label but should still have access to recording even when
  there is no plug, as described by @jdstrand:

  https://forum.snapcraft.io/t/pulseaudio-recording/6361/14?u=jamesh

  This is broken with the 1:12.2-0ubuntu2 release, as can be seen with
  e.g.:

  $ aa-exec -p snap.skype.skype /usr/bin/parecord foo.wav
  Stream error: Access denied

  [note that the Skype app itself still functions because it bypasses
  PulseAudio all together]

  The above command should result in audio being recorded from the
  microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1787324/+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 1781428] Re: pulseaudio built with --enable-snappy but 'Enable Snappy support: no'

[James Henstridge]

Attached is a debdiff for a 1:12.2-0ubuntu2 release of pulseaudio with
an updated snap policy module and the default configuration modified to
enable it.

I also took the opportunity to remove the Ubuntu Phone era trust-store
module, which hasn't been built since February.

** Patch added: "pulseaudio_12.2-0ubuntu1_12.2-0ubuntu2.diff"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/+attachment/5173727/+files/pulseaudio_12.2-0ubuntu1_12.2-0ubuntu2.diff

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

Title:
  pulseaudio built with --enable-snappy but 'Enable Snappy support: no'

Status in pulseaudio package in Ubuntu:
  In Progress

Bug description:
  From https://launchpadlibrarian.net/377100864/buildlog_ubuntu-cosmic-
  amd64.pulseaudio_1%3A12.0-1ubuntu1_BUILDING.txt.gz:

  ...
  dh_auto_configure -- --enable-x11 --disable-hal-compat 
--libdir=\${prefix}/lib/x86_64-linux-gnu 
--with-module-dir=\${prefix}/lib/pulse-12.0/modules 
--with-zsh-completion-dir=\${datadir}/zsh/vendor-completions 
--with-bash-completion-dir=\${datadir}/bash-completion/completions 
--with-systemduserunitdir=\${prefix}/lib/systemd/user --enable-snappy 
--disable-bluez4 --enable-gsettings --disable-gconf
   ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --enable-x11 --disable-hal-compat 
--libdir=\${prefix}/lib/x86_64-linux-gnu 
--with-module-dir=\${prefix}/lib/pulse-12.0/modules 
--with-zsh-completion-dir=\${datadir}/zsh/vendor-completions 
--with-bash-completion-dir=\${datadir}/bash-completion/completions 
--with-systemduserunitdir=\${prefix}/lib/systemd/user --enable-snappy 
--disable-bluez4 --enable-gsettings --disable-gconf
  ...
  Enable Ubuntu trust store: no
  Enable Snappy support: no
  Enable Apparmor:   yes

  
  At this point, the patch should probably be dropped, otherwise applications 
like chromium, etc will no longer be able to record.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/+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 1774560] Re: xdg-desktop-portal-gtk malfunctions on Wayland: wl_display@1.error(zxdg_imported_v1@36, 0, "set_parent_of was called with an invalid child")

[James Henstridge]

bionic-proposed has a 3.28.2 package, so this should be resolved for
that release shortly.

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

Title:
  xdg-desktop-portal-gtk malfunctions on Wayland:
  wl_display@1.error(zxdg_imported_v1@36, 0, "set_parent_of was called
  with an invalid child")

Status in mutter package in Ubuntu:
  Fix Released
Status in xdg-desktop-portal-gtk package in Ubuntu:
  Confirmed

Bug description:
  When running on a Wayland session, if xdg-desktop-portal-gtk is asked
  to display a window on behalf of a Wayland app, it gets disconnected
  from gnome-shell with one of these messages:

  Gdk-Message: 09:49:31.837: Lost connection to Wayland compositor.
  Gdk-Message: 09:50:28.438: Error 71 (Protocol error) dispatching to 
Wayland display.

  Running it with WAYLAND_DEBUG=1, the underlying error message that GDK
  seems to eat is:

  [3471970.531] wl_display@1.error(zxdg_imported_v1@36, 0,
  "set_parent_of was called with an invalid child")

  That is, when it tries to associate the dialog box with the confined
  application's window.  It seems the underlying bug is in in Mutter:

  https://gitlab.gnome.org/GNOME/mutter/issues/138

  According to duflu, the patch referenced in that bug report has been
  merged for 3.28.2 and 3.29.2.  It seems like a candidate to backport
  to bionic if we want portals to work on the (non-default) Wayland
  session.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1774560/+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 1661590] Re: GNOME Software only supports running one application from a snap

[James Henstridge]

@simosx: I gave this another test on a clean xenial VM with the same
gnome-software version as you.  Each time it launched the main
"libreoffice" command (showing a window asking to open recent files or
create a new document in one of the libreoffice applications).

gnome-software continues running when you close the window, so is it
possible you were still running the old version when you saw the
failure?

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

Title:
  GNOME Software only supports running one application from a snap

Status in GNOME Software:
  Fix Released
Status in Snappy:
  In Progress
Status in gnome-software package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  Fix Committed
Status in gnome-software source package in Artful:
  Won't Fix
Status in gnome-software source package in Bionic:
  Fix Released

Bug description:
  HOW TO REPRODUCE:

  1. Install LibreOffice snap ('nonfree' tag) from Ubuntu Software.
  2. Click on the 'Launch' button once you have it installed.

  WHAT IS EXPECTED: 
  It should launch the LibreOffice wizard instead of any of Writer, Calc, etc.

  WHAT ACTUALLY HAPPENS: 
  It launches LibreOffice Database.

  
  WHY THIS HAPPENS?

  Ubuntu Software probably picks the first listed command
  (libreoffice.base), as shown in

  $ snap info libreoffice
  name:  libreoffice
  summary:   "LibreOffice is a powerful office suite including word processing 
and creation of spreadsheets, slideshows and databases"
  publisher: canonical
  description: |
LibreOffice is a powerful office suite – its clean interface and
feature-rich tools help you unleash your creativity and enhance your
productivity. LibreOffice includes several applications that make it the 
most
powerful Free and Open Source office suite on the market: Writer (word
processing), Calc (spreadsheets), Impress (presentations), Draw (vector
graphics and flowcharts), Base (databases), and Math (formula editing).
  commands:
- libreoffice.base
- libreoffice.calc
- libreoffice.draw
- libreoffice.impress
- libreoffice
- libreoffice.math
- libreoffice.writer
  tracking:stable
  installed:   5.3.0.3 (17) 374MB -
  refreshed:   2017-02-01 20:51:51 +0200 EET
  channels: 
stable:5.3.0.3 (17) 374MB -
candidate: 5.3.0.3 (17) 374MB -
beta:  5.3.0.3 (17) 374MB -
edge:  5.3.0.3 (17) 374MB -

  
  The order in snapcraft.yaml is different, so probably Snapcraft is changing 
the order (it might assume that 'libreoffice' is 'libreoffice.libreoffice', so 
it puts it further down.

  Here is snapcraft.yaml: https://git.launchpad.net/~bjoern-michaelsen
  /df-libreoffice/+git/libreoffice-snap-
  playground/tree/snapcraft.yaml?h=xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1661590/+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 1672716] Re: Inverted colors on screenshots

[James Henstridge]

** Bug watch added: GNOME Bug Tracker #793473
   https://bugzilla.gnome.org/show_bug.cgi?id=793473

** Also affects: gnome-screenshot via
   https://bugzilla.gnome.org/show_bug.cgi?id=793473
   Importance: Unknown
   Status: Unknown

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

Title:
  Inverted colors on screenshots

Status in Gnome Screenshot:
  Unknown
Status in gnome-screenshot package in Ubuntu:
  Confirmed

Bug description:
  screenshots made with gnome-screenshot have inverted colors - blue
  becomes yellow, red becomes blue, etc. Please, see attached file.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: gnome-screenshot 3.22.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-11.13-generic 4.10.1
  Uname: Linux 4.10.0-11-generic x86_64
  ApportVersion: 2.20.4-0ubuntu2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Mar 14 15:03:41 2017
  SourcePackage: gnome-screenshot
  UpgradeStatus: Upgraded to zesty on 2017-02-28 (13 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-screenshot/+bug/1672716/+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 1690280] Re: Classic confined snaps don't install

[James Henstridge]

** Description changed:

  [Impact]
  Apps that use classic confinement show up in search results but don't install.
  
  [Test Case]
  1. Open GNOME Software
  2. Search for a classic snap, e.g. "atom"
  3. Install snap
  
  Expected result:
  Either:
  a) Snap is installed
  b) Snap is not installed and error given
  c) Snap is installed but user needs to provide some sort of confirmation 
since it is not confined.
  
  Observed result:
  Snap is not installed, no error given.
+ 
+ [Regression Potential]
+ Patch changes the code path used to request installation of all snap 
packages.  Ensure that strict confined snaps continue to be installed with 
correct confinement.
+ 
+ For example, try installing "ohmygiraffe" via gnome-software, then run
+ "snap info ohmygiraffe" from a terminal.  The "installed:" line should
+ not include the word "classic".

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

Title:
  Classic confined snaps don't install

Status in GNOME Software:
  Confirmed
Status in gnome-software package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  In Progress
Status in gnome-software source package in Zesty:
  Fix Committed
Status in gnome-software source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Apps that use classic confinement show up in search results but don't install.

  [Test Case]
  1. Open GNOME Software
  2. Search for a classic snap, e.g. "atom"
  3. Install snap

  Expected result:
  Either:
  a) Snap is installed
  b) Snap is not installed and error given
  c) Snap is installed but user needs to provide some sort of confirmation 
since it is not confined.

  Observed result:
  Snap is not installed, no error given.

  [Regression Potential]
  Patch changes the code path used to request installation of all snap 
packages.  Ensure that strict confined snaps continue to be installed with 
correct confinement.

  For example, try installing "ohmygiraffe" via gnome-software, then run
  "snap info ohmygiraffe" from a terminal.  The "installed:" line should
  not include the word "classic".

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1690280/+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 1690280] Re: Classic confined snaps don't install

[James Henstridge]

Here's a debdiff for the Xenial package update based on Robert's work.
I don't have upload rights to upload it myself.

** Patch added: 
"gnome-software_3.20.5-0ubuntu0.16.04.7_3.20.5-0ubuntu0.16.04.8.diff"
   
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1690280/+attachment/5032747/+files/gnome-software_3.20.5-0ubuntu0.16.04.7_3.20.5-0ubuntu0.16.04.8.diff

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

Title:
  Classic confined snaps don't install

Status in GNOME Software:
  Confirmed
Status in gnome-software package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  In Progress
Status in gnome-software source package in Zesty:
  Fix Committed
Status in gnome-software source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Apps that use classic confinement show up in search results but don't install.

  [Test Case]
  1. Open GNOME Software
  2. Search for a classic snap, e.g. "atom"
  3. Install snap

  Expected result:
  Either:
  a) Snap is installed
  b) Snap is not installed and error given
  c) Snap is installed but user needs to provide some sort of confirmation 
since it is not confined.

  Observed result:
  Snap is not installed, no error given.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1690280/+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 1721735] Re: UbuntuOne auth dialog is displayed when polkit auth dialog is dismissed

[James Henstridge]

I've got an (as yet unmerged) snapd branch to help with this:

https://github.com/snapcore/snapd/pull/4055

It got a review yesterday, so should go in the next snapd release.

This is basically doing (1), returning a Forbidden error when the user
dismisses the dialog.

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

Title:
  UbuntuOne auth dialog is displayed when polkit auth dialog is
  dismissed

Status in gnome-software package in Ubuntu:
  Triaged
Status in gnome-software source package in Artful:
  Triaged

Bug description:
  With snapd 16-2.28.1 from the candidate channel

  Test Case
  1. With gnome-software, install a snap
  2. When the polkit auth dialog is displayed, click "Cancel"

  Actual result 
  The Ubuntu One authentication dialog is displayed

  Expected result
  The polkit authentication dialog is dismissed and the user returns to the 
main screen of gnome-software. The U1 dialog is not displayed

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-software 3.26.0-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Oct  6 12:05:54 2017
  InstallationDate: Installed on 2013-09-03 (1493 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902)
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.0-0ubuntu3
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-software
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1721735/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

Snapd side changes:

https://github.com/snapcore/snapd/pull/4061

It looks like snapd-glib might need a change too, since it looks like
this will still be mapped to SNAPD_ERROR_FAILED in parse_result() (I
think falling back to treating 401 as SNAPD_AUTH_DATA_REQUIRED will do).

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in snapd:
  New
Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1724316/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

Yep.  There is code to prevent refreshing the macaroon if the user has
changed their password since it was created:

http://bazaar.launchpad.net/~canonical-isd-hackers/canonical-identity-
provider/trunk/view/head:/src/identityprovider/auth.py#L661

This should help in reproducing the bug.

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in snapd:
  New
Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1724316/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

** Also affects: snapd
   Importance: Undecided
   Status: New

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in snapd:
  New
Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1724316/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

Discussion started here:

https://forum.snapcraft.io/t/handling-invalid-credentials/2526

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1724316/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

So further investigation, the "cannot authenticate to snap store: " part
of the error is only added by snapd for an unexpected error:

https://github.com/snapcore/snapd/blob/master/store/auth.go#L190-L204

I believe this is being called via the refreshDischarges() method,
intended to keep the store macaroon up to date.  This is called by any
snapd API that talks to the store, so it isn't surprising we'd hit it
during gnome-software start up.

I wonder if changing your Ubuntu One password would be enough for the
store to refuse to refresh the macaroon?

So it looks like the fix probably requires the following:

 1. snapd to handle the INVALID_CREDENTIALS response from the store and
produce an error response that snapd-glib can distinguish.

 2. snapd-glib to handle this error case and map it to one of its error
codes (either a new one, or fold it into invalid-auth-data?)

 3. if snapd-glib produces a new error code, for gnome-software's snap
plugin to map this to an appropriate error code.

The end result should be for gnome-software to call the /v2/login end
point again, probably passing its existing macaroon so it updates the
existing snapd user rather than creating another (i.e. what would happen
to paid snaps for a discarded snapd user ID when it comes time to
refresh?).  I'll follow up with the snappy team to verify that this is
the way forward.

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1724316/+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 1724316] Re: "Sorry, something went wrong cannot authenticate to snap store ..." without any way to fix

[James Henstridge]

The "Provided email/password is not correct." part of the error message
appears to be coming through straight from the store.  This most likely
means you logged in to gnome-software using Ubuntu One credentials at
some point in the past, and the credentials snapd has stored are no
longer valid.

It might be possible to reproduce this by logging in in gnome-software
(currently possible by cancelling the polkit dialog), stopping snapd,
editing /var/lib/snapd/state.json to tamper with the store-macaroon
value and starting snapd again.  I'll need to verify if this happens.

The "Sorry, something went wrong" comes from gnome-software itself, and
indicates that the error could not be classified as one of the
GS_PLUGIN_ERROR_* error codes.  The code in gnome-software's snap plugin
specifically checks for various authentication related error conditions
(SNAPD_ERROR_AUTH_DATA_REQUIRED and SNAPD_ERROR_AUTH_DATA_REQUIRED in
particular), but that clearly isn't being hit.

So I think there are two possibilities here:

 1. libsnapd-glib isn't returning the correct error type for this case
 2. snapd isn't providing enough info to libsnapd-glib to decode the error

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

Title:
  "Sorry, something went wrong cannot authenticate to snap store ..."
  without any way to fix

Status in gnome-software package in Ubuntu:
  Confirmed

Bug description:
  When I open this application, I see a message near the top that says
  "Sorry, something went wrong cannot authenticate to snap store:
  Provided email/password is not correct."

  I can close this message dialog, but there appears to be no way to
  remedy the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ubuntu-software 3.26.1-0ubuntu2
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 17 13:08:16 2017
  EcryptfsInUse: Yes
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.1-0ubuntu2
  PackageArchitecture: all
  SourcePackage: gnome-software
  UpgradeStatus: Upgraded to artful on 2017-10-16 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1724316/+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 1722195] Re: no policy kit auth dialog to install or remove a snap

[James Henstridge]

I set up a clean VM running up to date artful, which includes
snapd-2.28.5+17.10 (so no copying of policy files or changing channel
for core snap), and couldn't reproduce this.  I started gnome-software,
and tried to install the Hiri snap and got the expected polkit prompt.

I did get the following message though:

Unable to install Hiri
Failed to read from snapd: Error receiving data: Connection reset by peer

Snapd restarted during the install, presumably after it installed the
core snap, so this seems like another variation of bug 1718170.

If you got a polkit prompt from the command line "snap" utility but not
in gnome-software, that would indicate that it was not sending the X
-Allow-Interaction header.  We added that in snapd-glib 1.19, and you've
got 1.23 installed.

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

Title:
  no policy kit auth dialog to install or remove a snap

Status in gnome-software package in Ubuntu:
  Triaged
Status in gnome-software source package in Artful:
  Triaged

Bug description:
  I've core installed from candidate
  tracking:candidate
  installed:   16-2.28.1 (3017) 87MB core

  and copied the policy kit file io.snapcraft.snapd.policy to
  /usr/share/polkit-1/actions/

  I was already authenticated against U1 and did a snap logout. I also
  restarted the system.

  When I install or remove a snap there is no authentication dialog but
  when I install a snap from the command line the policykit
  authentication dialog shows up.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-software 3.26.0-0ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Oct  9 11:15:57 2017
  InstallationDate: Installed on 2013-09-03 (1496 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902)
  InstalledPlugins:
   gnome-software-plugin-flatpak N/A
   gnome-software-plugin-limba   N/A
   gnome-software-plugin-snap3.26.0-0ubuntu3
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-software
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1722195/+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 1720331] Re: Whoopsie continually relaunching

[James Henstridge]

Changing the gnome-control-center task to low priority, since the
restart loop is gone with the new whoopsie-preferences that has landed
in the archive.

The gnome-control-center change is nice, but I don't think it is
critical to releasing 17.10 any more.

** Changed in: gnome-control-center (Ubuntu)
   Importance: Medium => Low

** Changed in: whoopsie-preferences (Ubuntu)
 Assignee: (unassigned) => James Henstridge (jamesh)

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

Title:
  Whoopsie continually relaunching

Status in gnome-control-center package in Ubuntu:
  Triaged
Status in whoopsie package in Ubuntu:
  Invalid
Status in whoopsie-preferences package in Ubuntu:
  Fix Released

Bug description:
  Today for the first time, and coincidentally looking for a different
  setting, I went to the Settings->Privacy dialogue. I was also
  (coincidentally for a different reason, relating to #1720149) already
  tailing /var/log/syslog to a terminal.

  Immediately on opening that dialogue, the syslog tail flooded with
  whoopsie continually relaunching, causing enough work to raise the fan
  speeds. This is a representative section from towards the end of me
  letting it, before I killed the service, with some necessary
  viciousness. Specifically

  systemctl stop whoopsie
  (didn't stop it)
  systemctl disable whoopsie
  (didn't stop it)
  (find pid for whoopsie's root process and kill it)
  (that stopped it)

  Also for good measure ensured the automatic bug reporting option in
  the privacy settings dialog was set to manual, which I think was done
  anyway when I disabled whoopsie, though the dialog wasn't on top at
  the time for me to be sure. It had been set to automatic when I first
  opened the dialog.

  Snippet from syslog attached. It was just repeating this continually
  for several minutes before I stopped it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: whoopsie 0.2.58
  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
  CrashReports:
   664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload
   640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 
09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash
   640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash
   600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 
18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded
  CurrentDesktop: GNOME
  Date: Fri Sep 29 10:00:34 2017
  InstallationDate: Installed on 2017-07-30 (60 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  RelatedPackageVersions: apport-noui N/A
  SourcePackage: whoopsie
  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-control-center/+bug/1720331/+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 1720331] Re: Whoopsie continually relaunching

[James Henstridge]

** Also affects: whoopsie-preferences (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Whoopsie continually relaunching

Status in gnome-control-center package in Ubuntu:
  Triaged
Status in whoopsie package in Ubuntu:
  Invalid
Status in whoopsie-preferences package in Ubuntu:
  New

Bug description:
  Today for the first time, and coincidentally looking for a different
  setting, I went to the Settings->Privacy dialogue. I was also
  (coincidentally for a different reason, relating to #1720149) already
  tailing /var/log/syslog to a terminal.

  Immediately on opening that dialogue, the syslog tail flooded with
  whoopsie continually relaunching, causing enough work to raise the fan
  speeds. This is a representative section from towards the end of me
  letting it, before I killed the service, with some necessary
  viciousness. Specifically

  systemctl stop whoopsie
  (didn't stop it)
  systemctl disable whoopsie
  (didn't stop it)
  (find pid for whoopsie's root process and kill it)
  (that stopped it)

  Also for good measure ensured the automatic bug reporting option in
  the privacy settings dialog was set to manual, which I think was done
  anyway when I disabled whoopsie, though the dialog wasn't on top at
  the time for me to be sure. It had been set to automatic when I first
  opened the dialog.

  Snippet from syslog attached. It was just repeating this continually
  for several minutes before I stopped it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: whoopsie 0.2.58
  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
  CrashReports:
   664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload
   640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 
09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash
   640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash
   600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 
18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded
  CurrentDesktop: GNOME
  Date: Fri Sep 29 10:00:34 2017
  InstallationDate: Installed on 2017-07-30 (60 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  RelatedPackageVersions: apport-noui N/A
  SourcePackage: whoopsie
  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-control-center/+bug/1720331/+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 1720331] Re: Whoopsie continually relaunching

[James Henstridge]

So I think I've got things sorted out by (a) switching to call
SetReportCrashes async to avoid blocking the UI, and (b) not calling
SetReportCrashes if we're asked to set it to the current (cached) value
of the property.

I've noticed that if whoopsie-preferences exits while the privacy panel
is open, I get a bit of a bounce when toggling the switch next.  This
seems to be due to whoopsie-preferences sending out a stray change
notification signal on start up:

method call time=1507538340.672978 sender=:1.1499 -> 
destination=com.ubuntu.WhoopsiePreferences serial=30 
path=/com/ubuntu/WhoopsiePreferences; interface=com.ubuntu.WhoopsiePreferences; 
member=SetReportCrashes
   boolean false
signal time=1507538340.756225 sender=:1.1507 -> destination=(null 
destination) serial=9 path=/com/ubuntu/WhoopsiePreferences; 
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "com.ubuntu.WhoopsiePreferences"
   array [
  dict entry(
 string "ReportMetrics"
 variant boolean true
  )
  dict entry(
 string "ReportCrashes"
 variant boolean true
  )
   ]
   array [
   ]
method call time=1507538340.756590 sender=:1.1499 -> destination=:1.1507 
serial=31 path=/com/ubuntu/WhoopsiePreferences; 
interface=org.freedesktop.DBus.Properties; member=GetAll
   string "com.ubuntu.WhoopsiePreferences"
method call time=1507538340.757395 sender=:1.1499 -> 
destination=com.ubuntu.WhoopsiePreferences serial=32 
path=/com/ubuntu/WhoopsiePreferences; interface=com.ubuntu.WhoopsiePreferences; 
member=SetReportCrashes
   boolean true
signal time=1507538341.034321 sender=:1.1507 -> destination=(null 
destination) serial=14 path=/com/ubuntu/WhoopsiePreferences; 
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "com.ubuntu.WhoopsiePreferences"
   array [
  dict entry(
 string "ReportCrashes"
 variant boolean false
  )
   ]
   array [
   ]
method call time=1507538341.035076 sender=:1.1499 -> destination=:1.1507 
serial=33 path=/com/ubuntu/WhoopsiePreferences; 
interface=com.ubuntu.WhoopsiePreferences; member=SetReportCrashes
   boolean false

So essentially whoopsie-preferences is sending out an unsolicited
PropertiesChanged signal on startup with the initial values before
processing the SetReportCrashes method call.  Then gnome-control-center
responds by trying to match the switch state leading to the bounce.

So I guess I'll have to dive into the whoopsie-preferences code to see
if I can silence the stray signal.

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

Title:
  Whoopsie continually relaunching

Status in gnome-control-center package in Ubuntu:
  Triaged
Status in whoopsie package in Ubuntu:
  Invalid

Bug description:
  Today for the first time, and coincidentally looking for a different
  setting, I went to the Settings->Privacy dialogue. I was also
  (coincidentally for a different reason, relating to #1720149) already
  tailing /var/log/syslog to a terminal.

  Immediately on opening that dialogue, the syslog tail flooded with
  whoopsie continually relaunching, causing enough work to raise the fan
  speeds. This is a representative section from towards the end of me
  letting it, before I killed the service, with some necessary
  viciousness. Specifically

  systemctl stop whoopsie
  (didn't stop it)
  systemctl disable whoopsie
  (didn't stop it)
  (find pid for whoopsie's root process and kill it)
  (that stopped it)

  Also for good measure ensured the automatic bug reporting option in
  the privacy settings dialog was set to manual, which I think was done
  anyway when I disabled whoopsie, though the dialog wasn't on top at
  the time for me to be sure. It had been set to automatic when I first
  opened the dialog.

  Snippet from syslog attached. It was just repeating this continually
  for several minutes before I stopped it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: whoopsie 0.2.58
  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
  CrashReports:
   664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload
   640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 
09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash
   640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash
   600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-0

[Desktop-packages] [Bug 1720331] Re: Whoopsie continually relaunching

[James Henstridge]

This is definitely a gnome-control-center bug rather than whoopsie.  I
can reproduce it like so:

 1. open gnome-control-center, and select the privacy panel.
 2. ensure that problem reporting is turned on.
 3. wait for whoopsie-preferences to exit on timeout (or manually kill it).

I then see traffic like the following on the system bus:

method call time=1507286449.661622 sender=:1.325 -> destination=:1.336 
serial=96 path=/com/ubuntu/WhoopsiePreferences; 
interface=com.ubuntu.WhoopsiePreferences; member=SetReportCrashes
   boolean false
method call time=1507286449.918969 sender=:1.325 -> destination=:1.336 
serial=97 path=/com/ubuntu/WhoopsiePreferences; 
interface=com.ubuntu.WhoopsiePreferences; member=SetReportCrashes
   boolean true
method call time=1507286450.216068 sender=:1.325 -> destination=:1.336 
serial=98 path=/com/ubuntu/WhoopsiePreferences; 
interface=com.ubuntu.WhoopsiePreferences; member=SetReportCrashes
   boolean false
method call time=1507286450.529908 sender=:1.325 -> destination=:1.336 
serial=99 path=/com/ubuntu/WhoopsiePreferences; 
interface=com.ubuntu.WhoopsiePreferences; member=SetReportCrashes
   boolean true
...

which continues until I kill gnome-control-center.  Whoopsie relaunching
is a direct consequence of these D-Bus method calls coming from gnome-
control-center.

It looks like the logic controlling the GtkSwitch gets into a loop when
whoopsie-preferences stops.  The D-Bus method calls are synchronous, so
this also ends up locking the UI.  I'll have a look into this properly
next week.

** Changed in: gnome-control-center (Ubuntu)
   Importance: Undecided => Medium

** Changed in: gnome-control-center (Ubuntu)
   Status: New => Triaged

** Changed in: gnome-control-center (Ubuntu)
 Assignee: (unassigned) => James Henstridge (jamesh)

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

Title:
  Whoopsie continually relaunching

Status in gnome-control-center package in Ubuntu:
  Triaged
Status in whoopsie package in Ubuntu:
  Triaged

Bug description:
  Today for the first time, and coincidentally looking for a different
  setting, I went to the Settings->Privacy dialogue. I was also
  (coincidentally for a different reason, relating to #1720149) already
  tailing /var/log/syslog to a terminal.

  Immediately on opening that dialogue, the syslog tail flooded with
  whoopsie continually relaunching, causing enough work to raise the fan
  speeds. This is a representative section from towards the end of me
  letting it, before I killed the service, with some necessary
  viciousness. Specifically

  systemctl stop whoopsie
  (didn't stop it)
  systemctl disable whoopsie
  (didn't stop it)
  (find pid for whoopsie's root process and kill it)
  (that stopped it)

  Also for good measure ensured the automatic bug reporting option in
  the privacy settings dialog was set to manual, which I think was done
  anyway when I disabled whoopsie, though the dialog wasn't on top at
  the time for me to be sure. It had been set to automatic when I first
  opened the dialog.

  Snippet from syslog attached. It was just repeating this continually
  for several minutes before I stopped it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: whoopsie 0.2.58
  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
  CrashReports:
   664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload
   640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 
09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash
   640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash
   600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 
18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded
  CurrentDesktop: GNOME
  Date: Fri Sep 29 10:00:34 2017
  InstallationDate: Installed on 2017-07-30 (60 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  RelatedPackageVersions: apport-noui N/A
  SourcePackage: whoopsie
  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-control-center/+bug/1720331/+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 1720331] Re: Whoopsie continually relaunching

[James Henstridge]

** Also affects: gnome-control-center (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Whoopsie continually relaunching

Status in gnome-control-center package in Ubuntu:
  Triaged
Status in whoopsie package in Ubuntu:
  Triaged

Bug description:
  Today for the first time, and coincidentally looking for a different
  setting, I went to the Settings->Privacy dialogue. I was also
  (coincidentally for a different reason, relating to #1720149) already
  tailing /var/log/syslog to a terminal.

  Immediately on opening that dialogue, the syslog tail flooded with
  whoopsie continually relaunching, causing enough work to raise the fan
  speeds. This is a representative section from towards the end of me
  letting it, before I killed the service, with some necessary
  viciousness. Specifically

  systemctl stop whoopsie
  (didn't stop it)
  systemctl disable whoopsie
  (didn't stop it)
  (find pid for whoopsie's root process and kill it)
  (that stopped it)

  Also for good measure ensured the automatic bug reporting option in
  the privacy settings dialog was set to manual, which I think was done
  anyway when I disabled whoopsie, though the dialog wasn't on top at
  the time for me to be sure. It had been set to automatic when I first
  opened the dialog.

  Snippet from syslog attached. It was just repeating this continually
  for several minutes before I stopped it.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: whoopsie 0.2.58
  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
  CrashReports:
   664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload
   640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 
09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash
   640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 
18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash
   600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 
18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded
  CurrentDesktop: GNOME
  Date: Fri Sep 29 10:00:34 2017
  InstallationDate: Installed on 2017-07-30 (60 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  RelatedPackageVersions: apport-noui N/A
  SourcePackage: whoopsie
  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-control-center/+bug/1720331/+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 1715479] Re: Touchpad won't stay disabled after resuming from suspend

[James Henstridge]

** Bug watch added: Red Hat Bugzilla #1448962
   https://bugzilla.redhat.com/show_bug.cgi?id=1448962

** Also affects: libinput (Fedora) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1448962
   Importance: Unknown
   Status: Unknown

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

Title:
  Touchpad won't stay disabled after resuming from suspend

Status in gnome-shell package in Ubuntu:
  Confirmed
Status in libinput package in Ubuntu:
  Triaged
Status in libinput package in Debian:
  Unknown
Status in libinput package in Fedora:
  Unknown

Bug description:
  I've disabled my touchpad using the mouse and touchpad control panel
  however it does not last very long i.e. after I've disabled it, it
  somehow becomes enabled even though the control panel continues to
  show it as disabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.25.91-0ubuntu3
  ProcVersionSignature: Ubuntu 4.12.0-12.13-generic 4.12.8
  Uname: Linux 4.12.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Sep  6 12:47:26 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2016-01-22 (593 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160117)
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1715479/+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 1715479] Re: Touchpad won't stay disabled after resuming from suspend

[James Henstridge]

While looking around for code that might resume the touchpad, I noticed
that the libinput master code was a bit different to the version we
ship: there's a tp_resume_conditional() function that checks sendevents.

And checking the history shows up this patch:

https://cgit.freedesktop.org/wayland/libinput/commit/src?id=53d53dd18ef14484d632421027cd7b6130013cf0

Fedora is also shipping this as a patch against their libinput-1.8.2 in
Fedora 27:

  https://src.fedoraproject.org/rpms/libinput/blob/f27/f/0001-touchpad-
don-t-resume-a-disabled-touchpad.patch

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

Title:
  Touchpad won't stay disabled after resuming from suspend

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

Bug description:
  I've disabled my touchpad using the mouse and touchpad control panel
  however it does not last very long i.e. after I've disabled it, it
  somehow becomes enabled even though the control panel continues to
  show it as disabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.25.91-0ubuntu3
  ProcVersionSignature: Ubuntu 4.12.0-12.13-generic 4.12.8
  Uname: Linux 4.12.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Sep  6 12:47:26 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2016-01-22 (593 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160117)
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1715479/+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 1715479] Re: Touchpad won't stay disabled after resuming from suspend

[James Henstridge]

So, I don't think there is any problem on the gnome-control-center side:
it just sets the org.gnome.desktop.peripherals.touchpad/send-events
GSetting key to disabled, and that is persisting over sleeps.

The code in mutter watches this key, and calls
MetaInputSettings::set_send_events() on each touchpad device, and
ensures it is called on each new input device.

https://git.gnome.org/browse/mutter/tree/src/backends/meta-input-
settings.c#n667

In a Wayland session, this calls
libinput_device_config_send_events_set_mode():

https://git.gnome.org/browse/mutter/tree/src/backends/native/meta-input-
settings-native.c#n36

The touchpad implementation of this is found here:

https://cgit.freedesktop.org/wayland/libinput/tree/src/evdev-mt-
touchpad.c#n3089

... which calls tp_suspend:

https://cgit.freedesktop.org/wayland/libinput/tree/src/evdev-mt-
touchpad.c#n1670

Which will either leave the touchpad enabled to support soft buttons, or
call evdev_device_suspend() otherwise, which closes the underlying
device.

Looking in /proc, gnome-shell definitely doesn't have the touchpad evdev
device open when I disable the touchpad, but somehow opens it again
after resume.

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

Title:
  Touchpad won't stay disabled after resuming from suspend

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

Bug description:
  I've disabled my touchpad using the mouse and touchpad control panel
  however it does not last very long i.e. after I've disabled it, it
  somehow becomes enabled even though the control panel continues to
  show it as disabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-shell 3.25.91-0ubuntu3
  ProcVersionSignature: Ubuntu 4.12.0-12.13-generic 4.12.8
  Uname: Linux 4.12.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Sep  6 12:47:26 2017
  DisplayManager: gdm3
  InstallationDate: Installed on 2016-01-22 (593 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160117)
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1715479/+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 1698035] Re: FFe: gnome-control-center lacks any replacement for unity-control-center's Diagnostics tab for managing crash reports

[James Henstridge]

I've sent our patch upstream to see if we can get a version of it
included.  I suspect it'll need some changes in order to be acceptable,
assuming they want it.  So I'll try to address that as needed.

** Bug watch added: GNOME Bug Tracker #788216
   https://bugzilla.gnome.org/show_bug.cgi?id=788216

** Also affects: gnome-control-center via
   https://bugzilla.gnome.org/show_bug.cgi?id=788216
   Importance: Unknown
   Status: Unknown

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

Title:
  FFe: gnome-control-center lacks any replacement for unity-control-
  center's Diagnostics tab for managing crash reports

Status in gnome-control-center:
  Unknown
Status in gnome-control-center package in Ubuntu:
  Fix Released

Bug description:
  gnome-control-center lacks any replacement for unity-control-center's
  Diagnostics tab (Ubuntu-specific) for managing crash reports.

  In Unity7 it's under:
    System Settings... > Security & Privacy > Diagnostics

  Feature Freeze Justification
  
  This patch avoids the regression caused by dropping activity-log-manager from 
the default install in 17.10. (activity-log-manager is mostly about handling 
zeitgeist which is no longer a prominent part of the default Ubuntu desktop).

  The patch reuses the strings used by Fedora's similar "abrt" feature
  that is already in upstream gnome-control-center code so this should
  avoid causing more work for translators.

  This will re-promote src:whoopsie-preferences to main (dropped to
  universe when unity-control-center was demoted).

  Screenshot of the dialog attached. There is a list row in Privacy below 
"Purge Trash & Temporary Files" that says
  "Problem Reporting" and next to it says either "Automatic" or "Manual".

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-control-center 1:3.24.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu4
  Architecture: amd64
  Date: Thu Jun 15 09:43:44 2017
  InstallationDate: Installed on 2017-05-03 (42 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502)
  SourcePackage: gnome-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/1698035/+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 1698035] Re: gnome-control-center lacks any replacement for unity-control-center's Diagnostics tab for managing crash reports

[James Henstridge]

** Branch linked: lp:~jamesh/gnome-control-center/ubuntu-whoopsie-
support

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

Title:
  gnome-control-center lacks any replacement for unity-control-center's
  Diagnostics tab for managing crash reports

Status in gnome-control-center package in Ubuntu:
  Confirmed

Bug description:
  gnome-control-center lacks any replacement for unity-control-center's
  Diagnostics tab (Ubuntu-specific) for managing crash reports.

  In Unity7 it's under:
System Settings... > Security & Privacy > Diagnostics

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-control-center 1:3.24.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu4
  Architecture: amd64
  Date: Thu Jun 15 09:43:44 2017
  InstallationDate: Installed on 2017-05-03 (42 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502)
  SourcePackage: gnome-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1698035/+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 1581713] Re: Ubuntu Software always asks for an Ubuntu Single Sign-On account when installing or removing a snap package

[James Henstridge]

The snapd side of things has been committed.  Both on master:

https://github.com/snapcore/snapd/commit/44611140566f6e6aa2a3b583e0b2970b69c8f53f

... and the release/2.28 branch:

https://github.com/snapcore/snapd/commit/69a00bc4f4e54d7e0312c253b46b97fca834b736

Together with the already released snapd-glib 1.19, this version of
snapd will let you install snaps via gnome-software without an Ubuntu
One account.  Instead you'll get a graphical prompt for your local
password, similar to when installing debs.

** Changed in: snapd (Ubuntu)
   Status: Confirmed => Fix Committed

** Changed in: snapd (Ubuntu)
 Assignee: (unassigned) => James Henstridge (jamesh)

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

Title:
  Ubuntu Software always asks for an Ubuntu Single Sign-On account when
  installing or removing a snap package

Status in Ubuntu GNOME:
  Triaged
Status in gnome-software package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Fix Committed

Bug description:
  If I try to uninstall a snap using Ubuntu Software, it asks for an Ubuntu 
Single Sign-On account. It seems strange since if I use a terminal and do:
  $ sudo snap remove john-the-ripper

  Everything works as expected.

  BTW: Ubuntu Software takes ages to find out the size of the snap
  package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-gnome/+bug/1581713/+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 1704162] Re: Add on/off switch for network connectivity check

[James Henstridge]

** Bug watch added: GNOME Bug Tracker #785117
   https://bugzilla.gnome.org/show_bug.cgi?id=785117

** Also affects: network-manager via
   https://bugzilla.gnome.org/show_bug.cgi?id=785117
   Importance: Unknown
   Status: Unknown

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

Title:
  Add on/off switch for network connectivity check

Status in gnome-control-center:
  Confirmed
Status in NetworkManager:
  Unknown
Status in gnome-control-center package in Ubuntu:
  Confirmed

Bug description:
  For Ubuntu 17.10, the Desktop Team would like to enable
  NetworkManager's connectivity check (LP: #997200) to detect captive
  portals. This has been supported by other GNOME distros for a couple
  years. Fedora in particular makes it opt out which we plan to do also
  in Ubuntu.

  This bug is a feature request to add an on/off switch for this
  connectivity check to gnome-control-center. I suggest that it be added
  to the Privacy panel although it might also work in the Network panel.

  I think there are two ways the switch could work. It could either
  write directly to a config file or it could use PackageKit to install
  or uninstall the distro-specific package that contains the
  connectivity config file. The advantage of the separate binary package
  is that it's easy to install or uninstall it for people that don't use
  gnome-control-center.

  See the upstream bug for a bit more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/1704162/+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 1690280] Re: Classic confined snaps don't install

[James Henstridge]

** Bug watch added: GNOME Bug Tracker #784773
   https://bugzilla.gnome.org/show_bug.cgi?id=784773

** Also affects: gnome-software via
   https://bugzilla.gnome.org/show_bug.cgi?id=784773
   Importance: Unknown
   Status: Unknown

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

Title:
  Classic confined snaps don't install

Status in GNOME Software:
  Unknown
Status in gnome-software package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  Apps that use classic confinement show up in search results but don't install.

  [Test Case]
  1. Open GNOME Software
  2. Search for a classic snap, e.g. "atom"
  3. Install snap

  Expected result:
  Either:
  a) Snap is installed
  b) Snap is not installed and error given
  c) Snap is installed but user needs to provide some sort of confirmation 
since it is not confined.

  Observed result:
  Snap is not installed, no error given.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1690280/+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 1661590] Re: GNOME Software only supports running one application from a snap

[James Henstridge]

** Bug watch added: GNOME Bug Tracker #784600
   https://bugzilla.gnome.org/show_bug.cgi?id=784600

** Also affects: gnome-software via
   https://bugzilla.gnome.org/show_bug.cgi?id=784600
   Importance: Unknown
   Status: Unknown

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

Title:
  GNOME Software only supports running one application from a snap

Status in GNOME Software:
  Unknown
Status in Snappy:
  In Progress
Status in gnome-software package in Ubuntu:
  Triaged

Bug description:
  HOW TO REPRODUCE:

  1. Install LibreOffice snap ('nonfree' tag) from Ubuntu Software.
  2. Click on the 'Launch' button once you have it installed.

  WHAT IS EXPECTED: 
  It should launch the LibreOffice wizard instead of any of Writer, Calc, etc.

  WHAT ACTUALLY HAPPENS: 
  It launches LibreOffice Database.

  
  WHY THIS HAPPENS?

  Ubuntu Software probably picks the first listed command
  (libreoffice.base), as shown in

  $ snap info libreoffice
  name:  libreoffice
  summary:   "LibreOffice is a powerful office suite including word processing 
and creation of spreadsheets, slideshows and databases"
  publisher: canonical
  description: |
LibreOffice is a powerful office suite – its clean interface and
feature-rich tools help you unleash your creativity and enhance your
productivity. LibreOffice includes several applications that make it the 
most
powerful Free and Open Source office suite on the market: Writer (word
processing), Calc (spreadsheets), Impress (presentations), Draw (vector
graphics and flowcharts), Base (databases), and Math (formula editing).
  commands:
- libreoffice.base
- libreoffice.calc
- libreoffice.draw
- libreoffice.impress
- libreoffice
- libreoffice.math
- libreoffice.writer
  tracking:stable
  installed:   5.3.0.3 (17) 374MB -
  refreshed:   2017-02-01 20:51:51 +0200 EET
  channels: 
stable:5.3.0.3 (17) 374MB -
candidate: 5.3.0.3 (17) 374MB -
beta:  5.3.0.3 (17) 374MB -
edge:  5.3.0.3 (17) 374MB -

  
  The order in snapcraft.yaml is different, so probably Snapcraft is changing 
the order (it might assume that 'libreoffice' is 'libreoffice.libreoffice', so 
it puts it further down.

  Here is snapcraft.yaml: https://git.launchpad.net/~bjoern-michaelsen
  /df-libreoffice/+git/libreoffice-snap-
  playground/tree/snapcraft.yaml?h=xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1661590/+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 1661590] Re: GNOME Software only supports running one application from a snap

[James Henstridge]

I put together a gnome-software patch to use the extra info from mvo's
snapd change:

https://code.launchpad.net/~jamesh/gnome-software/+git/gnome-
software/+ref/pick-launch-app

It still only supports running one application, but it now favours apps
that provide a desktop file, and the snap's main app as a tie breaker.
For Libreoffice, this reliably picks the main "libreoffice" binary.

It also launches the app via the desktop file if available, so we don't
have to guess whether it needs a terminal in that case.

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

Title:
  GNOME Software only supports running one application from a snap

Status in Snappy:
  In Progress
Status in gnome-software package in Ubuntu:
  Triaged

Bug description:
  HOW TO REPRODUCE:

  1. Install LibreOffice snap ('nonfree' tag) from Ubuntu Software.
  2. Click on the 'Launch' button once you have it installed.

  WHAT IS EXPECTED: 
  It should launch the LibreOffice wizard instead of any of Writer, Calc, etc.

  WHAT ACTUALLY HAPPENS: 
  It launches LibreOffice Database.

  
  WHY THIS HAPPENS?

  Ubuntu Software probably picks the first listed command
  (libreoffice.base), as shown in

  $ snap info libreoffice
  name:  libreoffice
  summary:   "LibreOffice is a powerful office suite including word processing 
and creation of spreadsheets, slideshows and databases"
  publisher: canonical
  description: |
LibreOffice is a powerful office suite – its clean interface and
feature-rich tools help you unleash your creativity and enhance your
productivity. LibreOffice includes several applications that make it the 
most
powerful Free and Open Source office suite on the market: Writer (word
processing), Calc (spreadsheets), Impress (presentations), Draw (vector
graphics and flowcharts), Base (databases), and Math (formula editing).
  commands:
- libreoffice.base
- libreoffice.calc
- libreoffice.draw
- libreoffice.impress
- libreoffice
- libreoffice.math
- libreoffice.writer
  tracking:stable
  installed:   5.3.0.3 (17) 374MB -
  refreshed:   2017-02-01 20:51:51 +0200 EET
  channels: 
stable:5.3.0.3 (17) 374MB -
candidate: 5.3.0.3 (17) 374MB -
beta:  5.3.0.3 (17) 374MB -
edge:  5.3.0.3 (17) 374MB -

  
  The order in snapcraft.yaml is different, so probably Snapcraft is changing 
the order (it might assume that 'libreoffice' is 'libreoffice.libreoffice', so 
it puts it further down.

  Here is snapcraft.yaml: https://git.launchpad.net/~bjoern-michaelsen
  /df-libreoffice/+git/libreoffice-snap-
  playground/tree/snapcraft.yaml?h=xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1661590/+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 1690280] Re: Classic confined snaps don't install

[James Henstridge]

I've made some simple UI changes in the following branch forked from
ubuntu-master, based on Robert's patch:

https://code.launchpad.net/~jamesh/gnome-software/+git/gnome-
software/+ref/classic-snap-install

This adds a warning message at the top of the details list when viewing
an snap that is not using strict confinement.  If we get the text of
this right, then this could be enough.  Currently it reads:

This third party package is not sandboxed.  It will have access to
your documents.

Thinking about it, this warning is equally valid for strictly confined
snaps that connect to the home interface.  I don't think there is a way
to identify such apps based on the metadata returned by "find" API
requests though.

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

Title:
  Classic confined snaps don't install

Status in gnome-software package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  Apps that use classic confinement show up in search results but don't install.

  [Test Case]
  1. Open GNOME Software
  2. Search for a classic snap, e.g. "atom"
  3. Install snap

  Expected result:
  Either:
  a) Snap is installed
  b) Snap is not installed and error given
  c) Snap is installed but user needs to provide some sort of confirmation 
since it is not confined.

  Observed result:
  Snap is not installed, no error given.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1690280/+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 1649313] Re: frieza_arm64, staging #99: SD card not mounted

[James Henstridge]

** Summary changed:

- Mediascanner is not working
+ frieza_arm64, staging #99: SD card not mounted

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

Title:
  frieza_arm64, staging #99: SD card not mounted

Status in Canonical System Image:
  New
Status in mediascanner2 package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New

Bug description:
  Story: looks like this is a well known bug but there wasn't a bug
  report yet so I'm opening it. Sdcards detection doesn't work in
  frieza_arm64.

  Environment:

  current build number: 99
  device name: frieza_arm64
  channel: ubuntu-touch/staging/ubuntu
  last update: 2016-12-12 12:21:18
  version version: 99
  version ubuntu: 20161210
  version device: 20161014.0
  version custom: 20161210

  Steps:

  1º Put some media files(songs,videos) on a sdcard
  2º Install the sdcard in frieza
  3º Open music app or music/video scopes

  Current result: music app reports no songs were found and music/video
  scopes don't show the media files either

  Expected result: all files from sdcard or other external devices
  should be detected

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1649313/+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 1649313] Re: Mediascanner is not working

[James Henstridge]

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

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

Title:
  Mediascanner is not working

Status in mediascanner2 package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New

Bug description:
  Story: looks like this is a well known bug but there wasn't a bug
  report yet so I'm opening it. Sdcards detection doesn't work in
  frieza_arm64.

  Environment:

  current build number: 99
  device name: frieza_arm64
  channel: ubuntu-touch/staging/ubuntu
  last update: 2016-12-12 12:21:18
  version version: 99
  version ubuntu: 20161210
  version device: 20161014.0
  version custom: 20161210

  Steps:

  1º Put some media files(songs,videos) on a sdcard
  2º Install the sdcard in frieza
  3º Open music app or music/video scopes

  Current result: music app reports no songs were found and music/video
  scopes don't show the media files either

  Expected result: all files from sdcard or other external devices
  should be detected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mediascanner2/+bug/1649313/+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 1639175] [NEW] Please add an "account-plugin-nextcloud" package

[James Henstridge]

Public bug reported:

Please add an account-plugin-nextcloud package.

For now, this could essentially be a copy of the ownCloud provider code
with different branding.  Having both providers side-by-side has a few
benefits:

1. we can pick which one to install to get desired branding

2. if the two projects diverge API wise, we can support each
independently rather than targeting a common subset.

The obvious downside though is that we'll have some duplication while
they are ABI compatible.

** Affects: webapps-sprint
 Importance: High
 Assignee: Alberto Mardegan (mardy)
 Status: Confirmed

** Affects: account-plugins (Ubuntu)
 Importance: Undecided
 Assignee: Alberto Mardegan (mardy)
 Status: Confirmed

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

Title:
  Please add an "account-plugin-nextcloud" package

Status in webapps-sprint:
  Confirmed
Status in account-plugins package in Ubuntu:
  Confirmed

Bug description:
  Please add an account-plugin-nextcloud package.

  For now, this could essentially be a copy of the ownCloud provider
  code with different branding.  Having both providers side-by-side has
  a few benefits:

  1. we can pick which one to install to get desired branding

  2. if the two projects diverge API wise, we can support each
  independently rather than targeting a common subset.

  The obvious downside though is that we'll have some duplication while
  they are ABI compatible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/webapps-sprint/+bug/1639175/+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 1621002] Re: Mediascanner2 test failure on yakkety/{armhf, arm64, ppc64el} with latest dbus-cpp

[James Henstridge]

This is looking like a case of the code being miscompiled under
optimisation.  To reproduce, build mediascanner2 using the
"RelWithDebInfo" build type and then run:

./test/test_dbus --gtest_filter=*filter_codec

The test program segfaults when calling Variant::as() on a
variant that should have been initialised by reading out of a
Message::Reader.

When compiling with the "Debug" build type, the test program completes
without error.

I can probably solve the immediate problem in mediascanner2 by disabling
optimisation for the affected file.

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

Title:
  Mediascanner2 test failure on yakkety/{armhf,arm64,ppc64el} with
  latest dbus-cpp

Status in dbus-cpp package in Ubuntu:
  New
Status in mediascanner2 package in Ubuntu:
  New

Bug description:
  When trying to build a new mediascanner2 release, tests failed on a
  number of architectures when building under Yakkety.  Some relevant
  logs:

  
https://launchpadlibrarian.net/281862518/buildlog_ubuntu-yakkety-armhf.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
  
https://launchpadlibrarian.net/282074929/buildlog_ubuntu-yakkety-arm64.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
  
https://launchpadlibrarian.net/281862178/buildlog_ubuntu-yakkety-ppc64el.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz

  The failure is occurring in code not touched by the changes in the
  silo, and I suspect that this is related to dbus-cpp or possibly GCC
  6.

  The segfault doesn't occur on x86, but I was able to reproduce it on
  my Chromebook.  Attached is a stacktrace from the test_dbus test
  program.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1621002/+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 1621002] [NEW] Mediascanner2 test failure on yakkety/{armhf, arm64, ppc64el} with latest dbus-cpp

[James Henstridge]

Public bug reported:

When trying to build a new mediascanner2 release, tests failed on a
number of architectures when building under Yakkety.  Some relevant
logs:

https://launchpadlibrarian.net/281862518/buildlog_ubuntu-yakkety-armhf.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
https://launchpadlibrarian.net/282074929/buildlog_ubuntu-yakkety-arm64.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
https://launchpadlibrarian.net/281862178/buildlog_ubuntu-yakkety-ppc64el.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz

The failure is occurring in code not touched by the changes in the silo,
and I suspect that this is related to dbus-cpp or possibly GCC 6.

The segfault doesn't occur on x86, but I was able to reproduce it on my
Chromebook.  Attached is a stacktrace from the test_dbus test program.

** Affects: dbus-cpp (Ubuntu)
 Importance: Undecided
 Status: New

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

** Attachment added: "stacktrace.log"
   
https://bugs.launchpad.net/bugs/1621002/+attachment/4736062/+files/stacktrace.log

** Also affects: dbus-cpp (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Mediascanner2 test failure on yakkety/{armhf,arm64,ppc64el} with
  latest dbus-cpp

Status in dbus-cpp package in Ubuntu:
  New
Status in mediascanner2 package in Ubuntu:
  New

Bug description:
  When trying to build a new mediascanner2 release, tests failed on a
  number of architectures when building under Yakkety.  Some relevant
  logs:

  
https://launchpadlibrarian.net/281862518/buildlog_ubuntu-yakkety-armhf.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
  
https://launchpadlibrarian.net/282074929/buildlog_ubuntu-yakkety-arm64.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz
  
https://launchpadlibrarian.net/281862178/buildlog_ubuntu-yakkety-ppc64el.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz

  The failure is occurring in code not touched by the changes in the
  silo, and I suspect that this is related to dbus-cpp or possibly GCC
  6.

  The segfault doesn't occur on x86, but I was able to reproduce it on
  my Chromebook.  Attached is a stacktrace from the test_dbus test
  program.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1621002/+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 1618390] Re: dbus-cpp crash on arm64 in core::dbus::Object::get_property

[James Henstridge]

I'm not convinced my bug is the same as this one.  That said, the
changes in the latest dbus-cpp package don't look particularly ABI
compatible, which may be the cause of this bug:

https://launchpadlibrarian.net/279409841/dbus-
cpp_5.0.0+15.10.20151022.1-0ubuntu5_5.0.0+16.10.20160809-0ubuntu1.diff.gz

In particular, it adds and removes members from core::dbus::Object, and
that type appears to be referenced by a few methods implemented by
libdbus-cpp (so this isn't entirely a header-only type).

If the applications start working with the old libdbus-cpp.so.5, it is
quite possible that they can also be made to work by recompiling them.

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

Title:
  dbus-cpp crash on arm64 in core::dbus::Object::get_property

Status in Canonical System Image:
  New
Status in dbus-cpp package in Ubuntu:
  New
Status in location-service package in Ubuntu:
  New
Status in mtp package in Ubuntu:
  New

Bug description:
  Requests to location service cause crashes on arm64:

  $ system-image-cli -i
  current build number: 23
  device name: frieza_arm64
  channel: ubuntu-touch/staging/ubuntu
  last update: 2016-08-30 09:13:12
  version version: 23
  version ubuntu: 20160830
  version device: 20160824.0
  version custom: 20160830

  Steps:
  * flash the above channel (remember --device frieza_arm64)
  * go to a scope using location
  * refresh

  == Stacktrace =
  #0  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (__val=-1, 
__mem=0x29) at /usr/include/c++/5/ext/atomicity.h:49
  __val = -1
  __mem = 0x29
  #1  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (__val=-1, 
__mem=0x29) at /usr/include/c++/5/ext/atomicity.h:82
  __val = -1
  __mem = 0x29
  #2  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (this=0x21) at 
/usr/include/c++/5/bits/shared_ptr_base.h:147
  #3  0x007f97922a28 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::operator=(std::__shared_count<(__gnu_cxx::_Lock_policy)2>
 const&) (this=this@entry=0x8b34558, __r=...) at 
/usr/include/c++/5/bits/shared_ptr_base.h:678
  __tmp = 0x8b34ba0
  #4  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b34550) at /usr/include/c++/5/bits/shared_ptr_base.h:867
  property = 
  #5  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b34550) at /usr/include/c++/5/bits/shared_ptr.h:93
  property = 
  #6  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b342c0) at /usr/include/core/dbus/impl/object.h:162
  property = 
  #7  0x007f97931c08 in 
com::ubuntu::location::service::Stub::Stub(std::shared_ptr 
const&) (object=warning: can't find linker symbol for virtual table for 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>' value
  warning: can't find linker symbol for virtual table for 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>' value

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: libubuntu-location-service3 3.0.0+16.04.20160811-0ubuntu1 [origin: 
LP-PPA-ci-train-ppa-service-stable-phone-overlay]
  Uname: Linux 3.10.93+ aarch64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: arm64
  Date: Tue Aug 30 09:39:24 2016
  SourcePackage: location-service
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: arm64
  DistroRelease: Ubuntu 16.04
  Package: mtp-server 0.0.4+16.04.20160413-0ubuntu2 [origin: 
LP-PPA-ci-train-ppa-service-stable-phone-overlay]
  PackageArchitecture: arm64
  Tags: third-party-packages xenial
  Uname: Linux 3.10.93+ aarch64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip plugdev sudo tty video
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1618390/+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 1618390] Re: dbus-cpp crash on arm64 in core::dbus::Object::get_property

[James Henstridge]

I'm not sure if it is related, but I've encountered test failures in my
mediascanner2 silo for dbus-cpp code that previously ran without issue:

https://launchpadlibrarian.net/281863370/buildlog_ubuntu-yakkety-
arm64.mediascanner2_0.112+16.10.20160831-0ubuntu1_BUILDING.txt.gz

It also failed on armhf, powerpc, and ppc64el, but passed on i386, amd64
and s390x.  The branches in the silo make no changes to the code being
run by the failing tests.  I'll report back after I've investigated
further.

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

Title:
  dbus-cpp crash on arm64 in core::dbus::Object::get_property

Status in Canonical System Image:
  New
Status in dbus-cpp package in Ubuntu:
  New
Status in location-service package in Ubuntu:
  New
Status in mtp package in Ubuntu:
  New

Bug description:
  Requests to location service cause crashes on arm64:

  $ system-image-cli -i
  current build number: 23
  device name: frieza_arm64
  channel: ubuntu-touch/staging/ubuntu
  last update: 2016-08-30 09:13:12
  version version: 23
  version ubuntu: 20160830
  version device: 20160824.0
  version custom: 20160830

  Steps:
  * flash the above channel (remember --device frieza_arm64)
  * go to a scope using location
  * refresh

  == Stacktrace =
  #0  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (__val=-1, 
__mem=0x29) at /usr/include/c++/5/ext/atomicity.h:49
  __val = -1
  __mem = 0x29
  #1  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (__val=-1, 
__mem=0x29) at /usr/include/c++/5/ext/atomicity.h:82
  __val = -1
  __mem = 0x29
  #2  0x007f978d4328 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (this=0x21) at 
/usr/include/c++/5/bits/shared_ptr_base.h:147
  #3  0x007f97922a28 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::operator=(std::__shared_count<(__gnu_cxx::_Lock_policy)2>
 const&) (this=this@entry=0x8b34558, __r=...) at 
/usr/include/c++/5/bits/shared_ptr_base.h:678
  __tmp = 0x8b34ba0
  #4  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b34550) at /usr/include/c++/5/bits/shared_ptr_base.h:867
  property = 
  #5  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b34550) at /usr/include/c++/5/bits/shared_ptr.h:93
  property = 
  #6  0x007f9792cc64 in 
core::dbus::Object::get_property()
 (this=0x8b342c0) at /usr/include/core/dbus/impl/object.h:162
  property = 
  #7  0x007f97931c08 in 
com::ubuntu::location::service::Stub::Stub(std::shared_ptr 
const&) (object=warning: can't find linker symbol for virtual table for 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>' value
  warning: can't find linker symbol for virtual table for 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>' value

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: libubuntu-location-service3 3.0.0+16.04.20160811-0ubuntu1 [origin: 
LP-PPA-ci-train-ppa-service-stable-phone-overlay]
  Uname: Linux 3.10.93+ aarch64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: arm64
  Date: Tue Aug 30 09:39:24 2016
  SourcePackage: location-service
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: arm64
  DistroRelease: Ubuntu 16.04
  Package: mtp-server 0.0.4+16.04.20160413-0ubuntu2 [origin: 
LP-PPA-ci-train-ppa-service-stable-phone-overlay]
  PackageArchitecture: arm64
  Tags: third-party-packages xenial
  Uname: Linux 3.10.93+ aarch64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip plugdev sudo tty video
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1618390/+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 1538471] Re: scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***

[James Henstridge]

One last comment: I tried downloading upstream pygobject 3.20.0 (which
was released two days ago), and the scopes run fine using the Xenial
typelib.

So I think the underlying problem is that we've got a problem of version
skew, with the versions of gobject-introspection and pygobject currently
in Xenial being incompatible.  We either need to downgrade gobject-
introspection (and rebuild typelibs for any affected packages), or
upgrade pygobject.

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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pygobject in Ubuntu.
Matching subscriptions: dp-libunity
https://bugs.launchpad.net/bugs/1538471

Title:
  scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3':
  free(): invalid next size (fast): 0x01ca17b0 ***

Status in Ubuntu Kylin:
  New
Status in libunity package in Ubuntu:
  Confirmed
Status in pygobject package in Ubuntu:
  New

Bug description:
  No idea what happened.

  ProblemType: Crash
  DistroRelease: Ubuntu 16.04
  Package: unity-scopes-runner 7.1.4+15.10.20151002-0ubuntu2
  ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3
  Uname: Linux 4.3.0-7-generic x86_64
  ApportVersion: 2.19.4-0ubuntu1
  Architecture: amd64
  AssertionMessage: *** Error in `/usr/bin/python3': free(): invalid next size 
(fast): 0x01ca17b0 ***
  CrashCounter: 1
  CurrentDesktop: Unity
  Date: Wed Jan 27 10:41:54 2016
  Dependencies:
   
  ExecutablePath: /usr/share/unity-scopes/scope-runner-dbus.py
  InstallationDate: Installed on 2015-04-30 (271 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  InterpreterPath: /usr/bin/python3.5
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/share/unity-scopes/scope-runner-dbus.py -s 
info/calculator.scope
  Signal: 6
  SourcePackage: libunity
  StacktraceTop:
   __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fd789926128 "*** 
Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
   malloc_printerr (ptr=, str=0x7fd7899261a0 "free(): invalid 
next size (fast)", action=1) at malloc.c:4965
   _int_free (av=, p=, have_lock=0) at 
malloc.c:3834
   __GI___libc_free (mem=) at malloc.c:2950
   ?? () from 
/usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
  SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit 
code 2:
  Title: scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': 
free(): invalid next size (fast): 0x01ca17b0 ***
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm audio cdrom dip libvirtd lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntukylin/+bug/1538471/+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 1533040] [NEW] package brltty 5.3.1-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 6

[James Henstridge]

Public bug reported:

The package install failed when trying to restart the brltty service.
It suggested checking the status using systemctl, which showed the
following errors:

Jan 12 11:32:13 scruffy systemd[1]: [/lib/systemd/system/brltty.service:16] 
Unbalanced quoting, ignoring: "/bin/sh -c "grep -sq '^ *RUN_BRLTTY=no' 
/etc/default/brltty || exec /sbin/brltty --no-daemon"
Jan 12 11:32:13 scruffy systemd[1]: brltty.service: Service lacks both 
ExecStart= and ExecStop= setting. Refusing.

Editing line 16 of /lib/systemd/system/brltty.service to add the missing
quote at the end of the line allowed the install to complete using "apt-
get install -f".

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: brltty 5.3.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0
Uname: Linux 4.3.0-2-generic x86_64
ApportVersion: 2.19.3-0ubuntu2
Architecture: amd64
Date: Tue Jan 12 11:31:36 2016
ErrorMessage: subprocess installed post-installation script returned error exit 
status 6
InstallationDate: Installed on 2013-10-29 (804 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
RelatedPackageVersions:
 dpkg 1.18.3ubuntu1
 apt  1.1.10
SourcePackage: brltty
Title: package brltty 5.3.1-1ubuntu1 failed to install/upgrade: subprocess 
installed post-installation script returned error exit status 6
UpgradeStatus: Upgraded to xenial on 2015-12-22 (21 days ago)

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


** Tags: amd64 apport-package xenial

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

Title:
  package brltty 5.3.1-1ubuntu1 failed to install/upgrade: subprocess
  installed post-installation script returned error exit status 6

Status in brltty package in Ubuntu:
  New

Bug description:
  The package install failed when trying to restart the brltty service.
  It suggested checking the status using systemctl, which showed the
  following errors:

  Jan 12 11:32:13 scruffy systemd[1]: [/lib/systemd/system/brltty.service:16] 
Unbalanced quoting, ignoring: "/bin/sh -c "grep -sq '^ *RUN_BRLTTY=no' 
/etc/default/brltty || exec /sbin/brltty --no-daemon"
  Jan 12 11:32:13 scruffy systemd[1]: brltty.service: Service lacks both 
ExecStart= and ExecStop= setting. Refusing.

  Editing line 16 of /lib/systemd/system/brltty.service to add the
  missing quote at the end of the line allowed the install to complete
  using "apt-get install -f".

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: brltty 5.3.1-1ubuntu1
  ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0
  Uname: Linux 4.3.0-2-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  Date: Tue Jan 12 11:31:36 2016
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 6
  InstallationDate: Installed on 2013-10-29 (804 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 
(20131016.1)
  RelatedPackageVersions:
   dpkg 1.18.3ubuntu1
   apt  1.1.10
  SourcePackage: brltty
  Title: package brltty 5.3.1-1ubuntu1 failed to install/upgrade: subprocess 
installed post-installation script returned error exit status 6
  UpgradeStatus: Upgraded to xenial on 2015-12-22 (21 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/1533040/+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 1518235] Re: youtube-dl is outdated

[James Henstridge]

** Package changed: flashplugin-nonfree (Ubuntu) => youtube-dl (Ubuntu)

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

Title:
  youtube-dl is outdated

Status in youtube-dl package in Ubuntu:
  New

Bug description:
  15.10 wily

  youtube-dl has stopped working. at the moment, there are many
  ExtractorErrors. This affects other packages (like mpv) that use
  youtube-dl to play youtube links directly, too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/1518235/+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 1526877] Re: Dbus errors in the console when closing the music-app

[James Henstridge]

For what it is worth, I managed to catch a segfault on shutdown of
music-app (i.e. swiping vertically in the app spread) on the phone.  I
couldn't get a usable apport crash dump, but managed to catch it in gdb.

This is with libdbus-cpp 4.3.0+15.04.20151126-0ubuntu1 and libmedia-hub-
client 4.0.0+15.04.20151209-0ubuntu1 installed.

** Attachment added: "stacktrace.txt"
   
https://bugs.launchpad.net/music-app/+bug/1526877/+attachment/4536742/+files/stacktrace.txt

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

Title:
  Dbus errors in the console when closing the music-app

Status in Ubuntu Music App:
  New
Status in dbus-cpp package in Ubuntu:
  New
Status in media-hub package in Ubuntu:
  New
Status in dbus-cpp package in Ubuntu RTM:
  New
Status in media-hub package in Ubuntu RTM:
  New

Bug description:
  Due to bug 1434584 being fixed when you swipe to close an application
  the following appears in the log, note the dbus errors, and that I am
  not able to reproduce this on the desktop.

  
  ** Application is now inactive
  Attempted to deliver an event to a non-existent window, ignoring.
  virtual bool QMediaPlaylist::setMediaObject(QMediaObject*)
  void QMediaPlaylistPrivate::syncControls(QMediaPlaylistControl*, 
QMediaPlaylistControl*)
  void AalMediaPlayerService::deletePlaylistControl()
  virtual AalMediaPlaylistProvider::~AalMediaPlaylistProvider()
  void AalMediaPlaylistProvider::disconnect_signals()
  virtual AalMediaPlaylistControl::~AalMediaPlaylistControl()
  void AalMediaPlayerService::deleteMediaPlayerControl()
  void AalMediaPlayerService::destroyPlayerSession()
  PlaybackStatusChanged signal arrived via the bus (Status: 
PlaybackStatus::ready)
  PlaybackStatusChanged signal arrived via the bus (Status: 
PlaybackStatus::stopped)
  OnTrackListReset signal arrived via the bus.
  Attempted to unregister path (path[0] = com path[1] = canonical) which isn't 
registered
  process 6617: arguments to dbus_connection_close() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2935.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_close() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2935.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  Sdk-Launcher> Stopping Application
  Sdk-Launcher> The Application exited, cleaning up
  Sdk-Launcher> Finished

To manage notifications about this bug go to:
https://bugs.launchpad.net/music-app/+bug/1526877/+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 1526877] Re: Dbus errors in the console when closing the music-app

[James Henstridge]

This sounds a lot like bug 1422304, by the look of it.

Both QtDBus and dbus-cpp make use of libdbus.  Libdbus provides a
dbus_shutdown() function that will release various internal global
state, which can be used to remove those allocation from the report
valgrind produces when analysing your program.  Normally applications
shouldn't have a need to call it.

Anything allocated (connections, method calls, etc) before the call to
shutdown can not be used after the call, which is what the
_dbus_current_generation assertions are about.

dbus-cpp makes a call to dbus_shutdown() as an atexit handler.
Unfortunately, Qt hasn't cleaned up its connections at this time,
leading to errors.

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

Title:
  Dbus errors in the console when closing the music-app

Status in Ubuntu Music App:
  New
Status in dbus-cpp package in Ubuntu:
  New
Status in media-hub package in Ubuntu:
  New
Status in dbus-cpp package in Ubuntu RTM:
  New
Status in media-hub package in Ubuntu RTM:
  New

Bug description:
  Due to bug 1434584 being fixed when you swipe to close an application
  the following appears in the log, note the dbus errors, and that I am
  not able to reproduce this on the desktop.

  
  ** Application is now inactive
  Attempted to deliver an event to a non-existent window, ignoring.
  virtual bool QMediaPlaylist::setMediaObject(QMediaObject*)
  void QMediaPlaylistPrivate::syncControls(QMediaPlaylistControl*, 
QMediaPlaylistControl*)
  void AalMediaPlayerService::deletePlaylistControl()
  virtual AalMediaPlaylistProvider::~AalMediaPlaylistProvider()
  void AalMediaPlaylistProvider::disconnect_signals()
  virtual AalMediaPlaylistControl::~AalMediaPlaylistControl()
  void AalMediaPlayerService::deleteMediaPlayerControl()
  void AalMediaPlayerService::destroyPlayerSession()
  PlaybackStatusChanged signal arrived via the bus (Status: 
PlaybackStatus::ready)
  PlaybackStatusChanged signal arrived via the bus (Status: 
PlaybackStatus::stopped)
  OnTrackListReset signal arrived via the bus.
  Attempted to unregister path (path[0] = com path[1] = canonical) which isn't 
registered
  process 6617: arguments to dbus_connection_close() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2935.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_close() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2935.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  process 6617: arguments to dbus_connection_unref() were incorrect, assertion 
"connection->generation == _dbus_current_generation" failed in file 
../../dbus/dbus-connection.c line 2822.
  This is normally a bug in some application using the D-Bus library.
  Sdk-Launcher> Stopping Application
  Sdk-Launcher> The Application exited, cleaning up
  Sdk-Launcher> Finished

To manage notifications about this bug go to:
https://bugs.launchpad.net/music-app/+bug/1526877/+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 1342031] Re: Rename QML modules to follow qml-module-foo naming

[James Henstridge]

** Branch linked: lp:~jamesh/thumbnailer/qml-module-package-name

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

Title:
  Rename QML modules to follow qml-module-foo naming

Status in accounts-qml-module package in Ubuntu:
  Fix Released
Status in address-book-app package in Ubuntu:
  New
Status in bacon2d package in Ubuntu:
  Triaged
Status in clickmanager-plugin package in Ubuntu:
  New
Status in content-hub package in Ubuntu:
  New
Status in cordova-ubuntu package in Ubuntu:
  New
Status in dee-qt package in Ubuntu:
  New
Status in gsettings-qt package in Ubuntu:
  New
Status in history-service package in Ubuntu:
  New
Status in libhud-qt package in Ubuntu:
  Won't Fix
Status in libqofono package in Ubuntu:
  New
Status in libusermetrics package in Ubuntu:
  New
Status in mediascanner2 package in Ubuntu:
  New
Status in poppler-qml-plugin package in Ubuntu:
  New
Status in qml-box2d package in Ubuntu:
  New
Status in qml-friends package in Ubuntu:
  New
Status in qt3d-opensource-src package in Ubuntu:
  Fix Released
Status in qtconnectivity-opensource-src package in Ubuntu:
  Fix Released
Status in qtdeclarative-opensource-src package in Ubuntu:
  Fix Released
Status in qtfeedback-opensource-src package in Ubuntu:
  Fix Released
Status in qtgrilo package in Ubuntu:
  New
Status in qtlocation-opensource-src package in Ubuntu:
  Fix Released
Status in qtmultimedia-opensource-src package in Ubuntu:
  Fix Released
Status in qtpim-opensource-src package in Ubuntu:
  Fix Released
Status in qtquickcontrols-opensource-src package in Ubuntu:
  Fix Released
Status in qtsensors-opensource-src package in Ubuntu:
  Fix Released
Status in qtsystems-opensource-src package in Ubuntu:
  Fix Released
Status in reminders-app package in Ubuntu:
  New
Status in solid package in Ubuntu:
  New
Status in sync-monitor package in Ubuntu:
  New
Status in telephony-service package in Ubuntu:
  Triaged
Status in thumbnailer package in Ubuntu:
  New
Status in u1db-qt package in Ubuntu:
  Confirmed
Status in ubuntu-download-manager package in Ubuntu:
  Triaged
Status in ubuntu-keyboard package in Ubuntu:
  New
Status in ubuntu-settings-components package in Ubuntu:
  New
Status in ubuntu-system-settings-online-accounts package in Ubuntu:
  Fix Released
Status in ubuntu-ui-extras package in Ubuntu:
  New
Status in ubuntu-ui-toolkit package in Ubuntu:
  Confirmed
Status in ubuntuone-credentials package in Ubuntu:
  New
Status in unity-action-api package in Ubuntu:
  Triaged
Status in unity-notifications package in Ubuntu:
  New
Status in webbrowser-app package in Ubuntu:
  Confirmed

Bug description:
  The package names of QML modules should be of the format qml-
  module-{$modulename}[version], a transition that was started during Qt
  5.3 preparation in Ubuntu. For example this could be qml-module-
  qtquick-localstorage or qml-module-qtsysteminfo for non versioned
  modules, and qml-module-ubuntu-webthing0.3 for versioned/co-
  installable modules.

  Further details in Debian e-mail:
  http://lists.alioth.debian.org/pipermail/pkg-kde-
  talk/2014-March/001889.html

  For Ubuntu, transitional packages should be put in place for smooth 
distribution upgrades, since we're shipping with the old names in previous 
Ubuntus. An example of that is at 
http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtsystems-opensource-src/revision/31
 - in other words:
  - Make the old package a transitional oldlibs package that depends on the new 
package
  - Add Breaks/Replaces to the new package for the old non-transitional 
packages (be careful about the version number specification)
  - Keep Multi-Arch: same and Architecture: any for the transitional package
  - Write "QML module" instead of "QML plugin"
  - Rename also the *.install files

  ---
  One more example on naming:

  For example, the "test" (qtdeclarative5-test-plugin) in the old
  qtdeclarative5-style package naming became "qttest" (qml-module-
  qttest) in the new naming since the path is actually under
  /usr/lib/*/qt5/qml/QtTest/

  qml-module-qtquick-xmllistmodel has path
  /usr/lib/*/qt5/qml/QtQuick/XmlListModel, as an example if you have
  more than one subdir. /usr/lib/*/qt5/qml/Ubuntu/Connectivity/ would be
  qml-module-ubuntu-connectivity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accounts-qml-module/+bug/1342031/+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 1466273] Re: gstreamer fails intermittently

[James Henstridge]

** No longer affects: gstreamer (Ubuntu)

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

Title:
  gstreamer fails intermittently

Status in Thumbnail generator for all kinds of files:
  New
Status in gstreamer1.0 package in Ubuntu:
  New

Bug description:
  gstreamer occasionally fails to extract a thumbnail from a video file.
  It's clearly a race condition because, almost all of the time, it
  succeeds. To reproduce:

  Check out the thumbnailer/devel branch at r217 and build it. Then:

  cd build/src/vs-thumb

  ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg

  Point a browser at the generated x.jpg file and check that the image
  was extracted correctly.

  Now run

  while ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg ;
  do :; done

  Within maybe a hundred iterations or so, I get:

  Error creating thumbnail: ThumbnailExtractor: change_state(): reading
  async messages: GStreamer error: negotiation problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1466273/+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 1466273] Re: gstreamer fails intermittently

[James Henstridge]

I gave michi's branch and test videos a try.  For the six videos being
thumbnailed in parallel, I see two successful thumbnails, two instances
that look like they died due to invalid memory allocations:

(vs-thumb:15299): GLib-ERROR **:
/build/buildd/glib2.0-2.45.1/./glib/gmem.c:357: overflow allocating
4294967274*8 bytes

(vs-thumb:15298): GLib-ERROR **:
/build/buildd/glib2.0-2.45.1/./glib/gmem.c:357: overflow allocating
4294967274*8 bytes

And two that have stuck around eating a little more than one CPU each.
I was able to kill -9 them though.

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

Title:
  gstreamer fails intermittently

Status in Thumbnail generator for all kinds of files:
  New
Status in gstreamer package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New

Bug description:
  gstreamer occasionally fails to extract a thumbnail from a video file.
  It's clearly a race condition because, almost all of the time, it
  succeeds. To reproduce:

  Check out the thumbnailer/devel branch at r217 and build it. Then:

  cd build/src/vs-thumb

  ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg

  Point a browser at the generated x.jpg file and check that the image
  was extracted correctly.

  Now run

  while ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg ;
  do :; done

  Within maybe a hundred iterations or so, I get:

  Error creating thumbnail: ThumbnailExtractor: change_state(): reading
  async messages: GStreamer error: negotiation problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1466273/+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 1466273] Re: gstreamer fails intermittently

[James Henstridge]

gbAnd ultimately the select() call in waitForFinished() was blocking on
a pipe that would be written to when the SIGCHLD signal handler was
called and waitid() returned the subprocess's pid.  So this is
functionally the same as the direct waitpid() call.

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

Title:
  gstreamer fails intermittently

Status in Thumbnail generator for all kinds of files:
  New
Status in gstreamer package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New

Bug description:
  gstreamer occasionally fails to extract a thumbnail from a video file.
  It's clearly a race condition because, almost all of the time, it
  succeeds. To reproduce:

  Check out the thumbnailer/devel branch at r217 and build it. Then:

  cd build/src/vs-thumb

  ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg

  Point a browser at the generated x.jpg file and check that the image
  was extracted correctly.

  Now run

  while ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg ;
  do :; done

  Within maybe a hundred iterations or so, I get:

  Error creating thumbnail: ThumbnailExtractor: change_state(): reading
  async messages: GStreamer error: negotiation problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1466273/+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 1391286] Re: Fails to generate thumbnail for small videos recorded with camera-app

[James Henstridge]

This seems to be related to the androidmedia elements from
gstreamer1.0-hybris, so changing the source package link: I can't
reproduce it with the standard elements.

In the hope that this might be a quirk of the pipeline used by vs-thumb,
I've ported the utility over to using the standard playbin element to
auto-plug the full pipeline (the same as mediahub):

https://code.launchpad.net/~jamesh/thumbnailer/thumbnail-
playbin/+merge/254025

The results are the same for these extra short videos.  Jim: if you've
got any ideas, I'd love to hear them.

** Package changed: gst-plugins-base1.0 (Ubuntu) => gst-plugins-bad1.0
(Ubuntu)

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

Title:
  Fails to generate thumbnail for small videos recorded with camera-app

Status in Thumbnail generator for all kinds of files:
  New
Status in gst-plugins-bad1.0 package in Ubuntu:
  Confirmed
Status in thumbnailer package in Ubuntu:
  Confirmed

Bug description:
  Videos with less than one sec recorded by camera-app (like when you
  click on the record button and immediately stops the recording
  process) have problems while generating thumbnail. This seems to be a
  problem to gallery-app since if we have one file like this on the
  collection the thumbnails took a long time to generate.

  I added an unit test that seems to fail on this branch:
  lp:~artmello/thumbnailer/thumbnailer-no_thumbnail_video

  Attached a video sample that seems to fail

To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1391286/+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 1323681] [NEW] Package description is out of date, claiming this is a "header-only dbus-binding"

[James Henstridge]

Public bug reported:

dbus-cpp includes a library, yet the package description still claims it
is a "header-only dbus-binding".  This should be updated to reflect the
current state of the package.

** Affects: dbus-cpp (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Package description is out of date, claiming this is a "header-only
  dbus-binding"

Status in “dbus-cpp” package in Ubuntu:
  New

Bug description:
  dbus-cpp includes a library, yet the package description still claims
  it is a "header-only dbus-binding".  This should be updated to reflect
  the current state of the package.

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