[Desktop-packages] [Bug 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

2023-12-13 Thread Martin Pitt
Excellent, thanks Danilo for the super fast fix! ⭐

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

Title:
  Updating wireguard-peer.allowed-ips gets wrong default netmask for
  IPv6 addresses

Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  In https://cockpit-project.org/ we have an integration test for
  NM+wireguard integration. That test starts with an IPv4-only
  connection:

  # cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
  network:
    version: 2
    tunnels:
  wg0:
    renderer: NetworkManager
    addresses:
    - "10.0.0.2/24"
    mode: "wireguard"
    port: 51820
    keys:
  private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
    peers:
    - keys:
    public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
  allowed-ips:
  - "10.0.0.1/32"
    networkmanager:
  uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
  name: "con-wg0"
  passthrough:
    ipv6.addr-gen-mode: "default"
    ipv6.method: "disabled"
    ipv6.ip6-privacy: "-1"
    proxy._: ""

  which gets rendered as

  # cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
  [connection]
  id=con-wg0
  type=wireguard
  uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
  interface-name=wg0

  [wireguard]
  private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
  listen-port=51820

  [wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
  allowed-ips=10.0.0.1/32;

  [ipv4]
  method=manual
  address1=10.0.0.2/24

  [ipv6]
  #Netplan: passthrough override
  method=disabled
  #Netplan: passthrough setting
  addr-gen-mode=default

  [proxy]

  Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
  "2001::1"]. Notably the addresses do *not* have a netmask, neither in
  the original config nor that update. Unfortunately that update cannot
  be done on the CLI:

  # nmcli con modify con-wg0 
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips" 
"2001::1"
  Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not 
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].

  So it has to happen via D-Bus:

  
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
  wg0","t":"s"},"interface-
  
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
  slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
  port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
  key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
  ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
  
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
  
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
  
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
  data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
  data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
  auto-dns":{"v":false,"t":"b"},"ignore-auto-
  routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]

  But this generates a wrong "/32" default netmask in the netplan config
  for the IPv6 address:

  allowed-ips:
  - "10.0.0.1/32"
  - "2001::1/32"

  On Fedora, with NM's default .nmconnection files, such a netmask is
  not added on this call. The netplan backend should do that (not
  second-guessing NM) or at least default to /128 for an IPv6 address.

  Doing this D-Bus call with `busctl` is a nuisance. If you need a
  reproducer at this level, I can spend an hour or so trying to stitch
  it together, but I hope your unit tests make this easier somehow.

  This was fine until 22.10, but with NM's new "netplan by default"
  backend this regressed.

  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2046158/+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 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

2023-12-11 Thread Martin Pitt
** Description changed:

  In https://cockpit-project.org/ we have an integration test for
  NM+wireguard integration. That test starts with an IPv4-only connection:
  
  # cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
  network:
-   version: 2
-   tunnels:
- wg0:
-   renderer: NetworkManager
-   addresses:
-   - "10.0.0.2/24"
-   mode: "wireguard"
-   port: 51820
-   keys:
- private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
-   peers:
-   - keys:
-   public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
- allowed-ips:
- - "10.0.0.1/32"
-   networkmanager:
- uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
- name: "con-wg0"
- passthrough:
-   ipv6.addr-gen-mode: "default"
-   ipv6.method: "disabled"
-   ipv6.ip6-privacy: "-1"
-   proxy._: ""
- 
+   version: 2
+   tunnels:
+ wg0:
+   renderer: NetworkManager
+   addresses:
+   - "10.0.0.2/24"
+   mode: "wireguard"
+   port: 51820
+   keys:
+ private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
+   peers:
+   - keys:
+   public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
+ allowed-ips:
+ - "10.0.0.1/32"
+   networkmanager:
+ uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
+ name: "con-wg0"
+ passthrough:
+   ipv6.addr-gen-mode: "default"
+   ipv6.method: "disabled"
+   ipv6.ip6-privacy: "-1"
+   proxy._: ""
  
  which gets rendered as
  
  # cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
  [connection]
  id=con-wg0
  type=wireguard
  uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
  interface-name=wg0
  
  [wireguard]
  private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
  listen-port=51820
  
  [wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
  allowed-ips=10.0.0.1/32;
  
  [ipv4]
  method=manual
  address1=10.0.0.2/24
  
  [ipv6]
  #Netplan: passthrough override
  method=disabled
  #Netplan: passthrough setting
  addr-gen-mode=default
  
  [proxy]
  
- 
- Now the UI modifies the "allowed-ips" setting to ["10.0.0.1", "2001::1"]. 
Notably the addresses do *not* have a netmask, neither in the original config 
nor that update. Unfortunately that update cannot be done on the CLI:
+ Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
+ "2001::1"]. Notably the addresses do *not* have a netmask, neither in
+ the original config nor that update. Unfortunately that update cannot be
+ done on the CLI:
  
  # nmcli con modify con-wg0 
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips" 
"2001::1"
  Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not 
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].
- 
  
  So it has to happen via D-Bus:
  
  
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
  wg0","t":"s"},"interface-
  
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
  slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
  port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
  key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
  ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
  
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
  
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
  
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
  data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
  data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
  auto-dns":{"v":false,"t":"b"},"ignore-auto-
  routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]
  
+ But this generates a wrong "/32" default netmask in the netplan config
+ for the IPv6 address:
  
- But this generates a wrong "/32" default netmask in the netplan config for 
the IPv6 address:
- 
- allowed-ips:
- - "10.0.0.1/32"
- - "2001::1/32"
+ allowed-ips:
+ - "10.0.0.1/32"
+ - "2001::1/32"
  
  On Fedora, with NM's default .nmconnection files, such a netmask is not
  added on this call. The netplan backend should do that (not second-
  guessing NM) or at least default to /128 for an IPv6 address.
  
  Doing this D-Bus call with `busctl` is a nuisance. If you need a
  reproducer at this level, I can spend an hour 

[Desktop-packages] [Bug 2046158] [NEW] Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

2023-12-11 Thread Martin Pitt
Public bug reported:

In https://cockpit-project.org/ we have an integration test for
NM+wireguard integration. That test starts with an IPv4-only connection:

# cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
network:
  version: 2
  tunnels:
wg0:
  renderer: NetworkManager
  addresses:
  - "10.0.0.2/24"
  mode: "wireguard"
  port: 51820
  keys:
private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
  peers:
  - keys:
  public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
allowed-ips:
- "10.0.0.1/32"
  networkmanager:
uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
name: "con-wg0"
passthrough:
  ipv6.addr-gen-mode: "default"
  ipv6.method: "disabled"
  ipv6.ip6-privacy: "-1"
  proxy._: ""


which gets rendered as

# cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
[connection]
id=con-wg0
type=wireguard
uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
interface-name=wg0

[wireguard]
private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
listen-port=51820

[wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
allowed-ips=10.0.0.1/32;

[ipv4]
method=manual
address1=10.0.0.2/24

[ipv6]
#Netplan: passthrough override
method=disabled
#Netplan: passthrough setting
addr-gen-mode=default

[proxy]


Now the UI modifies the "allowed-ips" setting to ["10.0.0.1", "2001::1"]. 
Notably the addresses do *not* have a netmask, neither in the original config 
nor that update. Unfortunately that update cannot be done on the CLI:

# nmcli con modify con-wg0 
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips" 
"2001::1"
Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not 
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].


So it has to happen via D-Bus:

"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
wg0","t":"s"},"interface-
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
auto-dns":{"v":false,"t":"b"},"ignore-auto-
routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]


But this generates a wrong "/32" default netmask in the netplan config for the 
IPv6 address:

allowed-ips:
- "10.0.0.1/32"
- "2001::1/32"

On Fedora, with NM's default .nmconnection files, such a netmask is not
added on this call. The netplan backend should do that (not second-
guessing NM) or at least default to /128 for an IPv6 address.

Doing this D-Bus call with `busctl` is a nuisance. If you need a
reproducer at this level, I can spend an hour or so trying to stitch it
together, but I hope your unit tests make this easier somehow.

This was fine until 22.10, but with NM's new "netplan by default"
backend this regressed.

DistroRelease: Ubuntu 23.04
Package: network-manager 1.44.2-1ubuntu1.2

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


** Tags: mantic regression-release

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

Title:
  Updating wireguard-peer.allowed-ips gets wrong default netmask for
  IPv6 addresses

Status in network-manager package in Ubuntu:
  New

Bug description:
  In https://cockpit-project.org/ we have an integration test for
  NM+wireguard integration. That test starts with an IPv4-only
  connection:

  # cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
  network:
version: 2
tunnels:
  wg0:
renderer: NetworkManager
addresses:
- "10.0.0.2/24"
mode: "wireguard"
port: 51820
keys:
  private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
peers:
- keys:
public: 

[Desktop-packages] [Bug 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-07 Thread Martin Pitt
Exact same fix uploaded to -proposed SRU review queue.

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  Fix Released
Status in udisks2 source package in Mantic:
  In Progress

Bug description:
  [Impact]

  Trying to load the lvm2 module crashes udisks immediately:

     busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

    Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
     Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
     Stack trace of thread 5709:
     #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
     #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
     #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
     #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
     #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
     #5  0x56079be323d2 main 
(udisksd + 0x223d2)
     #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
     #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
     #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  This breaks at least cockpit, and possibly other consumers of udisks
  (GNOME Disks perhaps?). This is a regression in mantic, earlier
  releases were fine.

  [Test Plan]

  The above reproducer confirms the check. The busctl command should
  succeed, and afterwards `systemctl status udisks2` should still be
  "active (running)" instead of "failed".

  autopkgtests should take care of regression testing, and they were
  happy with the noble update. I'm also happy to run cockpit's
  integration tests against the updated version; it exercises udisks2
  thoroughly (and we find lots of bugs with it). At the moment we don't
  test 23.10 mantic at all, because it is so broken
  (https://github.com/cockpit-project/bots/pull/5432).

  [Where problems could occur]

  Changing the linker options is quite invasive. The autopkgtests cover
  the runtime functionality though, and as modules are currently 100%
  broken they can't possibly get any worse.

  [Other info]

  Fix committed to Debian: https://salsa.debian.org/utopia-
  team/udisks2/-/commit/e22881abdd90bd4878add165ccc46008a17163f8

  Noble debdiff:
  
http://launchpadlibrarian.net/701038246/udisks2_2.10.1-1ubuntu1_2.10.1-1ubuntu2.diff.gz

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-07 Thread Martin Pitt
** Description changed:

  [Impact]
  
  Trying to load the lvm2 module crashes udisks immediately:
  
     busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/Manager
  org.freedesktop.UDisks2.Manager EnableModule sb lvm2 true
  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).
  
    Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
     Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
     Stack trace of thread 5709:
     #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
     #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
     #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
     #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
     #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
     #5  0x56079be323d2 main 
(udisksd + 0x223d2)
     #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
     #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
     #8  0x56079be324f5 _start 
(udisksd + 0x224f5)
  
  This breaks at least cockpit, and possibly other consumers of udisks
  (GNOME Disks perhaps?). This is a regression in mantic, earlier releases
  were fine.
  
  [Test Plan]
  
  The above reproducer confirms the check. The busctl command should
  succeed, and afterwards `systemctl status udisks2` should still be
  "active (running)" instead of "failed".
  
- autopkgtests should take care of regression testing. I'm also happy to
- run cockpit's integration tests against the updated version; it
- exercises udisks2 thoroughly (and we find lots of bugs with it). At the
- moment we don't test 23.10 mantic at all, because it is so broken
- (https://github.com/cockpit-project/bots/pull/5432).
+ autopkgtests should take care of regression testing, and they were happy
+ with the noble update. I'm also happy to run cockpit's integration tests
+ against the updated version; it exercises udisks2 thoroughly (and we
+ find lots of bugs with it). At the moment we don't test 23.10 mantic at
+ all, because it is so broken (https://github.com/cockpit-
+ project/bots/pull/5432).
  
  [Where problems could occur]
  
  Changing the linker options is quite invasive. The autopkgtests cover
  the runtime functionality though, and as modules are currently 100%
  broken they can't possibly get any worse.
  
  [Other info]
  
  Fix committed to Debian: https://salsa.debian.org/utopia-
  team/udisks2/-/commit/e22881abdd90bd4878add165ccc46008a17163f8
  
  Noble debdiff:
  
http://launchpadlibrarian.net/701038246/udisks2_2.10.1-1ubuntu1_2.10.1-1ubuntu2.diff.gz
  
  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  Fix Released
Status in udisks2 source package in Mantic:
  In Progress

Bug description:
  [Impact]

  Trying to load the lvm2 module crashes udisks immediately:

     busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

    Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
     Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
     Stack trace of thread 5709:
     #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
     #1  

[Desktop-packages] [Bug 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-05 Thread Martin Pitt
** Description changed:

- I tried to do this with `apport-cli
- /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending doesn't
- do anything obvious. I run this from a cloud image over ssh, I really
- don't have any GUI. So filing this manually.
+ [Impact]
  
  Trying to load the lvm2 module crashes udisks immediately:
  
-busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/Manager
+    busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/Manager
  org.freedesktop.UDisks2.Manager EnableModule sb lvm2 true
- 
  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).
  
-   Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
-Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
-Stack trace of thread 5709:
-#0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
-#1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
-#2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
-#3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
-#4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
-#5  0x56079be323d2 main 
(udisksd + 0x223d2)
-#6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
-#7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
-#8  0x56079be324f5 _start 
(udisksd + 0x224f5)
+   Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
+    Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
+    Stack trace of thread 5709:
+    #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
+    #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
+    #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
+    #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
+    #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
+    #5  0x56079be323d2 main 
(udisksd + 0x223d2)
+    #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
+    #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
+    #8  0x56079be324f5 _start 
(udisksd + 0x224f5)
+ 
+ This breaks at least cockpit, and possibly other consumers of udisks
+ (GNOME Disks perhaps?). This is a regression in mantic, earlier releases
+ were fine.
+ 
+ [Test Plan]
+ 
+ The above reproducer confirms the check. The busctl command should
+ succeed, and afterwards `systemctl status udisks2` should still be
+ "active (running)" instead of "failed".
+ 
+ autopkgtests should take care of regression testing. I'm also happy to
+ run cockpit's integration tests against the updated version. At the
+ moment we don't test 23.10 mantic at all, because it is so broken
+ (https://github.com/cockpit-project/bots/pull/5432).
+ 
+ [Where problems could occur]
+ 
+ Changing the linker options is quite invasive. The autopkgtests cover
+ the runtime functionality though, and as modules are currently 100%
+ broken they can't possibly get any worse.
+ 
+ [Other info]
+ 
+ Fix committed to Debian: https://salsa.debian.org/utopia-
+ team/udisks2/-/commit/e22881abdd90bd4878add165ccc46008a17163f8
+ 
  
  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

** Changed in: udisks2 (Ubuntu Mantic)
   Status: New => In Progress

** Changed in: udisks2 (Ubuntu Mantic)
 Assignee: (unassigned) => Martin Pitt (pitti)

** Description changed:

  [Impact]
  
  Trying to load the lvm2 module crashes udisks immediately:
  
     busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/Manager

[Desktop-packages] [Bug 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-05 Thread Martin Pitt
** Changed in: udisks2 (Ubuntu)
 Assignee: (unassigned) => Martin Pitt (pitti)

** Changed in: udisks2 (Ubuntu)
   Status: New => Fix Committed

** Changed in: udisks2 (Ubuntu)
   Importance: Undecided => High

** Changed in: udisks2 (Ubuntu Mantic)
   Importance: Undecided => High

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  Fix Committed
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-05 Thread Martin Pitt
It's not related to the configure arguments, but to the linker flags.
The Ubuntu package build sets

  LDFLAGS="-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects
-Wl,-z,relro -Wl,-z,now"

while Debian uses

  LDFLAGS="-Wl,-z,relro -Wl,-z,now"

lto seems to work, but dropping the "-Wl,-Bsymbolic-functions" makes it
work. But that was already enabled ages ago, at least since intrepid in
2008.

Reproduces with

  ./configure LDFLAGS="-Wl,-Bsymbolic-functions" --disable-gtk-docs 
--enable-lvm2 && make -j4
  sudo src/udisksd --debug --force-load-modules --replace


This is actually similar to bug #1286046 (fixed in 
https://launchpad.net/ubuntu/+source/parole/0.6.1-0ubuntu2) or 
https://github.com/fwupd/fwupd/issues/1077 -- in both cases, 
-Bsymbolic-functions got dropped to fix it.

Adding

  export DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions


fixes it. I'm going to commit that to Debian, and upload.


** Bug watch added: github.com/fwupd/fwupd/issues #1077
   https://github.com/fwupd/fwupd/issues/1077

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-04 Thread Martin Pitt
Interesting! when I check out the source package, and build with the
above patch and like this:

  ./configure CFLAGS="-g -O0" --disable-gtk-docs --enable-lvm2
  make -j4
  sudo src/udisksd -rd --force-load-modules

then it loads the module just fine:

(udisksd:17050): udisks-WARNING **: 14:52:41.121: Can't load configuration file 
/usr/local/etc/udisks2/udisks2.conf
udisks-Message: 14:52:41.122: Loading module lvm2 ...
udisks-Message: 14:52:41.131: Acquired the name org.freedesktop.UDisks2 on the 
system message bus

Curiously, when I run the exact same ./configure invocation that the
Debian packaging does, and run it out of the build tree, it works.

It does seem to be *something* about the built module, though -- with
the patch above (running modules from build tree) it works, but without
the patch it loads them from /usr and fails.

Back trace:

#0  0x779a8a5d in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x779a8cf3 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ac2ead in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x77aca18f in g_type_register_static () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x77aca3e8 in g_type_register_static_simple () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x746da71d in udisks_daemon_get_type_once () at udisksdaemon.c:115
g_define_type_id = 0x1
#6  0x746da69c in udisks_daemon_get_type () at udisksdaemon.c:115
g_define_type_id = Python Exception : Variable 
'static_fundamental_type_nodes' not found.

static_g_define_type_id = 0
#7  0x746cb784 in udisks_module_lvm2_new (daemon=0x55615340, 
cancellable=0x0, error=0x7fffe210)
at udiskslinuxmodulelvm2.c:133
__inst = 0x55615340
__t = Python Exception : No type named TypeNode.

__r = 32767
initable = 0x556131b0
__func__ = "udisks_module_lvm2_new"
#8  0x555d21a3 in load_single_module_unlocked
(manager=0x55624950, sopath=0x55637090 
"/usr/lib/x86_64-linux-gnu/udisks2/modules/libudisks2_lvm2.so", 
do_notify=0x7fffe208, error=0x7fffe210) at udisksmodulemanager.c:344
state = 0x555eb6b5
handle = 0x556a2450
module_id = 0x55692ea0 "lvm2"
module_new_func_name = 0x55613ae0 "\2602v\364\377\177"
module_id_func = 0x746cb73a 
module_new_func = 0x746cb75f 
module = 0x556a3693
__func__ = "load_single_module_unlocked"
#9  0x555d2505 in udisks_module_manager_load_modules 
(manager=0x55624950) at udisksmodulemanager.c:448
modules_to_load = 0x556a2150 = {0x55637090}
modules_to_load_tmp = 0x556a2150 = {0x55637090}
error = 0x0
do_notify = 0
__func__ = "udisks_module_manager_load_modules"
#10 0x55578002 in load_modules_in_idle_cb (user_data=0x55615340) at 
udisksdaemon.c:277
daemon = 0x55615340
#11 0x779a0a61 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x779fc4ff in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x779a14bf in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x555776e8 in main (argc=1, argv=0x7fffe4d8) at main.c:184
error = 0x0
opt_context = 0x55607f60
ret = 1
name_owner_id = 1
sigint_id = 1
__func__ = "main"


This keeps mystifying and evading me. More debugging tomorrow, but it's quickly 
nearing the point where I run out of time to debug this.

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 

[Desktop-packages] [Bug 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-04 Thread Martin Pitt
Comparing with Debian testing: Running

# /usr/libexec/udisks2/udisksd --debug --force-load-modules
udisks-Message: 10:34:44.696: udisks daemon version 2.10.1 starting
udisks-Message: 10:34:44.724: Acquired the name org.freedesktop.UDisks2 on the 
system message bus
udisks-Message: 10:34:44.729: Loading module lvm2 ...

there works, and doesn't show any of the three assertions that fail on
noble:

(udisksd:57782): GLib-GObject-CRITICAL **: 10:33:06.459: cannot register
existing type 'UDisksDaemon'

(udisksd:57782): GLib-CRITICAL **: 10:33:06.460: g_once_init_leave:
assertion 'result != 0' failed

(udisksd:57782): libudisks2-lvm2-CRITICAL **: 10:33:06.460:
udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

glib2.0 and libblockdev have identical versions.

Installing debian-testing's glib debs:

  apt install --reinstall libglib2.0-{0,bin,data,dev,dev-bin,doc}

and/or the libblockdev debs:

  dpkg -l | grep 3.0.4-1 | awk '{print $2}' | xargs apt install -y
--reinstall

makes no difference. What the heck?

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-04 Thread Martin Pitt
It's a bit easier to investigate with

/usr/libexec/udisks2/udisksd --debug --force-load-modules

There I've1 also seen it fail on the btrfs module, so it's not specific
to the LVM one.

It also happens with rebuilding the udisks source package (so not just
changed ABI)

I tried building upstream git, but it fails due to some missing API,
like

udiskslinuxmodulelvm2.c:438:29: error: implicit declaration of function
'udisks_logical_volume_get_uuid' [-Werror=implicit-function-declaration]

presumably libblockdev or some other build dep which moved along?

Anyway, this doesn't happen on Debian, and it's certainly not related to
the current Ubuntu delta. So something in the stack must be different.
glib2.0 would be the obvious candidate, but both Debian sid and Ubuntu
noble have 2.78.1-4.

For investigating it is helpful to load the modules from the source
tree:

--- src/udisksmodulemanager.c.orig  2023-12-04 10:20:54.571542454 +
+++ src/udisksmodulemanager.c   2023-12-04 10:21:01.047569622 +
@@ -637,7 +637,7 @@
 udisks_module_manager_new (UDisksDaemon *daemon)
 {
   return UDISKS_MODULE_MANAGER (g_object_new (UDISKS_TYPE_MODULE_MANAGER,
-  "daemon", daemon, NULL));
+  "daemon", daemon, "uninstalled", 
TRUE, NULL));
 }
 
 /**


and then 

  sudo ./src/udisksd --debug --force-load-modules

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] Re: loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-12-04 Thread Martin Pitt
Confirmed on current noble, same udisks2 version.

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

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  ExecutablePath: /usr/libexec/udisks2/udisksd
  Package: udisks2 2.10.1-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2040488/+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 2040488] [NEW] loading lvm2 module crashes: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' failed

2023-10-25 Thread Martin Pitt
Public bug reported:

I tried to do this with `apport-cli
/var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending doesn't
do anything obvious. I run this from a cloud image over ssh, I really
don't have any GUI. So filing this manually.

Trying to load the lvm2 module crashes udisks immediately:

   busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/Manager
org.freedesktop.UDisks2.Manager EnableModule sb lvm2 true


udisksd[5709]: cannot register existing type 'UDisksDaemon'
udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump (PID 
5767/UID 0).

  Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
   Module libsystemd.so.0 from deb 
systemd-253.5-1ubuntu6.amd64
   Stack trace of thread 5709:
   #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
   #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
   #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
   #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
   #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
   #5  0x56079be323d2 main 
(udisksd + 0x223d2)
   #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
   #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
   #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

ProblemType: Crash
Architecture: amd64
Date: Wed Oct 25 12:13:14 2023
DistroRelease: Ubuntu 23.10
ExecutablePath: /usr/libexec/udisks2/udisksd
Package: udisks2 2.10.1-1ubuntu1

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

** Affects: udisks2 (Ubuntu Mantic)
 Importance: Undecided
 Status: New


** Tags: mantic regression-release

** Also affects: udisks2 (Ubuntu Mantic)
   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/2040488

Title:
  loading lvm2 module crashes: udisks_module_lvm2_new: assertion
  'UDISKS_IS_DAEMON (daemon)' failed

Status in udisks2 package in Ubuntu:
  New
Status in udisks2 source package in Mantic:
  New

Bug description:
  I tried to do this with `apport-cli
  /var/crash/_usr_libexec_udisks2_udisksd.0.crash`, but 's'ending
  doesn't do anything obvious. I run this from a cloud image over ssh, I
  really don't have any GUI. So filing this manually.

  Trying to load the lvm2 module crashes udisks immediately:

 busctl call org.freedesktop.UDisks2
  /org/freedesktop/UDisks2/Manager org.freedesktop.UDisks2.Manager
  EnableModule sb lvm2 true

  
  udisksd[5709]: cannot register existing type 'UDisksDaemon'
  udisksd[5709]: g_once_init_leave: assertion 'result != 0' failed
  udisksd[5709]: udisks_module_lvm2_new: assertion 'UDISKS_IS_DAEMON (daemon)' 
failed
  systemd[1]: Started systemd-coredump@2-5767-0.service - Process Core Dump 
(PID 5767/UID 0).

Module libudev.so.1 from deb 
systemd-253.5-1ubuntu6.amd64
 Module libsystemd.so.0 from 
deb systemd-253.5-1ubuntu6.amd64
 Stack trace of thread 5709:
 #0  0x56079be701ad 
udisks_module_manager_load_modules (udisksd + 0x601ad)
 #1  0x56079be5fdf5 n/a 
(udisksd + 0x4fdf5)
 #2  0x7f7d5f122a11 n/a 
(libglib-2.0.so.0 + 0x5aa11)
 #3  0x7f7d5f17e46f n/a 
(libglib-2.0.so.0 + 0xb646f)
 #4  0x7f7d5f12346f 
g_main_loop_run (libglib-2.0.so.0 + 0x5b46f)
 #5  0x56079be323d2 main 
(udisksd + 0x223d2)
 #6  0x7f7d5ee280d0 
__libc_start_call_main (libc.so.6 + 0x280d0)
 #7  0x7f7d5ee28189 
__libc_start_main_impl (libc.so.6 + 0x28189)
 #8  0x56079be324f5 _start 
(udisksd + 0x224f5)

  ProblemType: Crash
  Architecture: amd64
  Date: Wed Oct 25 12:13:14 2023
  DistroRelease: Ubuntu 23.10
  

[Desktop-packages] [Bug 1856798] Re: vitrage-ml run error

2022-09-19 Thread Martin Pitt
*** This bug is a duplicate of bug 1856799 ***
https://bugs.launchpad.net/bugs/1856799

** This bug has been marked a duplicate of bug 1856799
   vitrage-ml run error

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

Title:
  vitrage-ml run error

Status in libssh package in Ubuntu:
  New

Bug description:
  Vitrage  report error as follows  when adding config plugins =
  jaccard_correlation

  
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: Traceback (most recent call last):
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.run()
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/lib/python3.6/multiprocessing/process.py", line 93, in run Dec 18 
10:40:19 qihongtao vitrage-ml[6174]: self._target(*self._args, 
**self._kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_utils.py", line 63, in 
_bootstrap_process
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: target(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_service.py", line 161, in 
create_and_wait
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: sw = cls(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_service.py", line 175, in 
__init__
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.service = 
config.service(worker_id, *args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/opt/stack/vitrage/vitrage/machine_learning/service.py", line 32, in __init__
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.machine_learning_plugins 
= self.get_machine_learning_plugins() Dec 18 10:40:19 qihongtao 
vitrage-ml[6174]:   File 
"/opt/stack/vitrage/vitrage/machine_learning/service.py", line 75, in 
get_machine_learning_plugins
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: CONF))
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/oslo_utils/importutils.py", line 44, in 
import_object
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: return 
import_class(import_str)(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: TypeError: __init__() takes 1 
positional argument but 2 were given
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: INFO cotyledon._service_manager 
[-] Child 6217 exited with status 1
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: INFO cotyledon._service_manager 
[-] Forking too fast, sleeping

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1856798/+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 1856799] Re: vitrage-ml run error

2022-09-19 Thread Martin Pitt
** Package changed: libssh (Ubuntu) => openstack (Ubuntu)

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

Title:
  vitrage-ml run error

Status in openstack package in Ubuntu:
  New

Bug description:
  Vitrage  report error as follows  when adding config plugins =
  jaccard_correlation

  
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: Traceback (most recent call last):
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.run()
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/lib/python3.6/multiprocessing/process.py", line 93, in run Dec 18 
10:40:19 qihongtao vitrage-ml[6174]: self._target(*self._args, 
**self._kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_utils.py", line 63, in 
_bootstrap_process
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: target(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_service.py", line 161, in 
create_and_wait
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: sw = cls(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/cotyledon/_service.py", line 175, in 
__init__
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.service = 
config.service(worker_id, *args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/opt/stack/vitrage/vitrage/machine_learning/service.py", line 32, in __init__
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: self.machine_learning_plugins 
= self.get_machine_learning_plugins() Dec 18 10:40:19 qihongtao 
vitrage-ml[6174]:   File 
"/opt/stack/vitrage/vitrage/machine_learning/service.py", line 75, in 
get_machine_learning_plugins
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: CONF))
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]:   File 
"/usr/local/lib/python3.6/dist-packages/oslo_utils/importutils.py", line 44, in 
import_object
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: return 
import_class(import_str)(*args, **kwargs)
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: TypeError: __init__() takes 1 
positional argument but 2 were given
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: INFO cotyledon._service_manager 
[-] Child 6217 exited with status 1
  Dec 18 10:40:19 qihongtao vitrage-ml[6174]: INFO cotyledon._service_manager 
[-] Forking too fast, sleeping

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openstack/+bug/1856799/+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 1877783] Re: package libssh-gcrypt-4:amd64 0.9.0-1ubuntu1.4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting c

2022-09-19 Thread Martin Pitt
Sorry, this isn't something that can be fixed in libssh, but some
bug/issue with dpkg, possibly a faulty disk, etc. Closing as
inactionable.

** Changed in: libssh (Ubuntu)
   Status: New => Invalid

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

Title:
  package libssh-gcrypt-4:amd64 0.9.0-1ubuntu1.4 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in libssh package in Ubuntu:
  Invalid

Bug description:
  the package is in a state of critical inconsistency: it is recommended
  install it again before attempting configuration.

  ProblemType: Package
  DistroRelease: Ubuntu 19.10
  Package: libssh-gcrypt-4:amd64 0.9.0-1ubuntu1.4
  ProcVersionSignature: Ubuntu 5.3.0-46.38-generic 5.3.18
  Uname: Linux 5.3.0-46-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.8
  Architecture: amd64
  Date: Sat May  9 21:08:23 2020
  DuplicateSignature:
   package:libssh-gcrypt-4:amd64:0.9.0-1ubuntu1.4
   Unpacking openssl (1.1.1g-1+ubuntu19.10.1+deb.sury.org+1) over 
(1.1.1c-1ubuntu4) ...
   dpkg: error processing package libssh-gcrypt-4:amd64 (--configure):
package is in a very bad inconsistent state; you should
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2020-04-02 (37 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  Python3Details: /usr/bin/python3.7, Python 3.7.5, python3-minimal, 3.7.5-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.17-1
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu2
   apt  1.9.4
  SourcePackage: libssh
  Title: package libssh-gcrypt-4:amd64 0.9.0-1ubuntu1.4 failed to 
install/upgrade: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1877783/+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 1853266] Re: Xorg/Xwayland segfaults in OsLookupColor() from funlockfile() from glamor_get_pixmap_texture() from glamor_create_gc()

2021-11-11 Thread Martin Pitt
> Xorg -config tests/xorg-dummy.conf -logfile /tmp/log -once :5

The -once was an attempt to work around this, but it doesn't help, nor
change the behaviour of this bug.

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

Title:
  Xorg/Xwayland segfaults in OsLookupColor() from funlockfile() from
  glamor_get_pixmap_texture() from glamor_create_gc()

Status in X.Org X server:
  Fix Released
Status in xorg-server package in Ubuntu:
  Confirmed
Status in xorg-server package in Fedora:
  Won't Fix

Bug description:
  Recently, my the xserver on my system has started randomly crashing
  due to a segmentation fault. As far as I can tell, this segmentation
  fault occurs as a result of libglamoregl encountering a
  GL_OUT_OF_MEMORY error (see attached Xorg.log). I have had a hard time
  reproducing this bug reliably, but it mostly happens when I have been
  using Inkscape for a while.

  This appears to be the same bug that has been reported here

  https://bugs.freedesktop.org/show_bug.cgi?id=110500
  https://bugs.freedesktop.org/show_bug.cgi?id=110714

  In those bug reports, the usual recommendation is to switch from the
  -modesetting video driver to the -nouveau video driver. By default,
  Ubuntu is not configured in this way, so this bug probably needs to be
  addressed in some other way.

  My graphics card is listed as follows:

   *-display 
 description: VGA compatible controller
 product: GK208B [GeForce GT 710]
 vendor: NVIDIA Corporation
 physical id: 0
 bus info: pci@:65:00.0
 version: a1
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
 configuration: driver=nouveau latency=0
 resources: irq:69 memory:d700-d7ff memory:c800-cfff 
memory:d000-d1ff ioport:b000(size=128) memory:d800-d807

  Please let me know if you need any additional information.

  More information:

  Release of Ubuntu: 19.04

  Installed package versions:
  xserver-xorg-video-nouveau/disco,now 1:1.0.16-1 amd64 [installed]
  xserver-xorg-core/disco,now 2:1.20.4-1ubuntu3 amd64 [installed]
  xserver-xorg/disco,now 1:7.7+19ubuntu12 amd64 [installed]
  inkscape/disco,now 0.92.4-3 amd64 [installed]

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/1853266/+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 1853266] Re: Xorg/Xwayland segfaults in OsLookupColor() from funlockfile() from glamor_get_pixmap_texture() from glamor_create_gc()

2021-11-11 Thread Martin Pitt
umockdev's test suite now started to see this crash in current Ubuntu
jammy. Simple reproducer:


$ cat tests/xorg-dummy.conf 
Section "Device"
Identifier "test"
Driver "dummy"
EndSection

$ Xorg -config tests/xorg-dummy.conf -logfile /tmp/log -once :5


Then, run at least one query on it, like this:

$ env DISPLAY=:5 xinput

Then pkill/kill or Control-C the Xorg process, and it will crash:

double free or corruption (!prev)
(EE) 
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55e2b1c75d39]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x50) [0x7f384162f520]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_kill+0xf8) [0x7f3841683808]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (raise+0x16) [0x7f384162f476]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd7) [0x7f38416157b7]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__fsetlocking+0x426) [0x7f38416765e6]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (timer_settime+0x2cc) [0x7f384168dadc]
(EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__default_morecore+0x8bc) 
[0x7f384168f84c]
(EE) 8: /lib/x86_64-linux-gnu/libc.so.6 (free+0x55) [0x7f3841691ce5]
(EE) 9: /usr/lib/xorg/Xorg (config_fini+0x402) [0x55e2b1b6cb22]
(EE) 10: /usr/lib/xorg/Xorg (ddxGiveUp+0x62) [0x55e2b1b4fa22]
(EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x669) [0x55e2b1b12d69]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x90) 
[0x7f3841616fd0]
(EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x7d) 
[0x7f384161707d]
(EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x55e2b1afbf0e]
(EE) 
(EE) Received signal 6 sent by process 520, uid 0

After that it hangs and can't be cleaned up any more (zombie)

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

Title:
  Xorg/Xwayland segfaults in OsLookupColor() from funlockfile() from
  glamor_get_pixmap_texture() from glamor_create_gc()

Status in X.Org X server:
  Fix Released
Status in xorg-server package in Ubuntu:
  Confirmed
Status in xorg-server package in Fedora:
  Won't Fix

Bug description:
  Recently, my the xserver on my system has started randomly crashing
  due to a segmentation fault. As far as I can tell, this segmentation
  fault occurs as a result of libglamoregl encountering a
  GL_OUT_OF_MEMORY error (see attached Xorg.log). I have had a hard time
  reproducing this bug reliably, but it mostly happens when I have been
  using Inkscape for a while.

  This appears to be the same bug that has been reported here

  https://bugs.freedesktop.org/show_bug.cgi?id=110500
  https://bugs.freedesktop.org/show_bug.cgi?id=110714

  In those bug reports, the usual recommendation is to switch from the
  -modesetting video driver to the -nouveau video driver. By default,
  Ubuntu is not configured in this way, so this bug probably needs to be
  addressed in some other way.

  My graphics card is listed as follows:

   *-display 
 description: VGA compatible controller
 product: GK208B [GeForce GT 710]
 vendor: NVIDIA Corporation
 physical id: 0
 bus info: pci@:65:00.0
 version: a1
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
 configuration: driver=nouveau latency=0
 resources: irq:69 memory:d700-d7ff memory:c800-cfff 
memory:d000-d1ff ioport:b000(size=128) memory:d800-d807

  Please let me know if you need any additional information.

  More information:

  Release of Ubuntu: 19.04

  Installed package versions:
  xserver-xorg-video-nouveau/disco,now 1:1.0.16-1 amd64 [installed]
  xserver-xorg-core/disco,now 2:1.20.4-1ubuntu3 amd64 [installed]
  xserver-xorg/disco,now 1:7.7+19ubuntu12 amd64 [installed]
  inkscape/disco,now 0.92.4-3 amd64 [installed]

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/1853266/+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 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Martin Pitt
Christian, as I write above I believe this really needs to be fixed in
bolt's tests. The umockdev change was a bug fix which bolt's tests
(incorrectly) worked around. So I hope you don't mind that I flipped the
affected package around? I am in contact with Christian now, and hope to
sort this out soon.

** Changed in: bolt (Ubuntu)
   Status: Invalid => In Progress

** Changed in: umockdev (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  In Progress
Status in umockdev package in Ubuntu:
  Invalid
Status in umockdev package in Debian:
  Unknown

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 

[Desktop-packages] [Bug 1925822] Re: [21.04 regression] formatting vfat times out

2021-05-10 Thread Martin Pitt
I installed udisks2 2.9.2-1ubuntu1 from hirsute-proposed, and confirm
that both the manual test case above as well as cockpit's automatic
TestStorageFormat.testFormatTypes now succeed. Thank you Sebastien and
Robie!

** Tags removed: verification-needed verification-needed-hirsute
** Tags added: verification-done verification-done-hirsute

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  Fix Committed
Status in udisks2 source package in Hirsute:
  Fix Committed

Bug description:
  * Impact

  Formatting devices to vfat fails in some cases due to an
  incompatibility with the new dosfstools version

  * Test case

  see comment #5

  or

  - $ sudo modprobe scsi_debug
  - check what device is assigned
  - $ sudo busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/DEVNAME org.freedesktop.UDisks2.Block 
Format 'sa{sv}' vfat 0
  (replace DEVNAME by the actual device name, 'sdc' for example)

  the formatting should work which you can verify by
  - $ blkid -p /dev/DEVNAME

  * Regression potential

  The changes is specific to vfat handling so that's the feature to
  focus on while testing, make sure than creating, deleting, renaming
  vfat partitions from gnome-disks is working.

  [racb] An upstream "precautionary" partprobe is being added following
  the mkfs for vfat, when it didn't do this before. This is a change in
  behaviour that might expose a problem elsewhere.

  

  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] Re: [21.04 regression] formatting vfat times out

2021-04-27 Thread Martin Pitt
Argh indeed, forgot about that one already -- I even looked at that
before, it's tracked here: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=983751

But you knew that as well, in comment #4 -- So I hope this didn't take
too much time to track down. Merci beaucoup !

** Bug watch added: Debian Bug tracker #983751
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983751

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  * Impact

  Formatting devices to vfat fails in some cases due to an
  incompatibility with the new dosfstools version

  * Test case

  see comment #5

  or

  - $ sudo modprobe scsi_debug
  - check what device is assigned
  - $ sudo busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/DEVNAME org.freedesktop.UDisks2.Block 
Format 'sa{sv}' vfat 0
  (replace DEVNAME by the actual device name, 'sdc' for example)

  the formatting should work which you can verify by
  - $ blkid -p /dev/DEVNAME

  * Regression potential

  The changes is specific to vfat handling so that's the feature to
  focus on while testing, make sure than creating, deleting, renaming
  vfat partitions from gnome-disks is working.

  


  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] Re: [21.04 regression] formatting vfat times out

2021-04-26 Thread Martin Pitt
Direct mkfs works:

# mkfs.vfat -I -n label /dev/vdb
mkfs.fat 4.2 (2021-01-31)
mkfs.fat: Warning: lowercase labels might not work properly on some systems
# blkid -p /dev/vdb
/dev/vdb: PTUUID="892240dd" PTTYPE="dos"


** Changed in: udisks2 (Ubuntu)
   Status: Incomplete => 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/1925822

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  New

Bug description:
  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] Re: [21.04 regression] formatting vfat times out

2021-04-26 Thread Martin Pitt
Reproducer from scratch:

# download current cloud image
curl -L -O 
https://cloud-images.ubuntu.com/daily/server/hirsute/current/hirsute-server-cloudimg-amd64.img
# nothing fancy, just admin:foobar and root:foobar
curl -L -O 
https://github.com/cockpit-project/bots/raw/master/machine/cloud-init.iso
# create second disk image for formatting
qemu-img create -f qcow2 disk2.img 100M
# boot it
qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive 
file=hirsute-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom 
cloud-init.iso -drive file=disk2.img,if=virtio

Log in on the console (root:foobar), then

# sanity check: should be empty
blkid -p /dev/vdb

busctl call org.freedesktop.UDisks2
/org/freedesktop/UDisks2/block_devices/vdb org.freedesktop.UDisks2.Block
Format 'sa{sv}' vfat 0

→ hangs.

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  New

Bug description:
  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] Re: [21.04 regression] formatting vfat times out

2021-04-23 Thread Martin Pitt
I tried to run it in the foreground with


  G_MESSAGES_DEBUG=all /usr/libexec/udisks2/udisksd

but still no messages aside from the timeout.

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  New

Bug description:
  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] Re: [21.04 regression] formatting vfat times out

2021-04-23 Thread Martin Pitt
Forgot to mention, there is nothing useful in the journal. The only
message is this when the timeout happens:

Apr 23 15:12:35 ubuntu udisksd[3116]: Error synchronizing after
formatting with type `vfat': Timed out waiting for object


** Description changed:

  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:
- 
  
  # blkid -p /dev/sda
  (nothing)
  
-  busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
+ # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object
  
  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"
  
  OTOH, formatting as ext4 works fine:
  
  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)
  
  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"
  
  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.
  
  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  New

Bug description:
  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1925822] [NEW] [21.04 regression] formatting vfat times out

2021-04-23 Thread Martin Pitt
Public bug reported:

There is a regression somewhere between udisks, udev, and dosfstools.
Formatting a device with vfat hangs and fails:

# blkid -p /dev/sda
(nothing)

# busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
(long pause)
Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

# blkid -p /dev/sda
/dev/sda: PTUUID="3690494f" PTTYPE="dos"

OTOH, formatting as ext4 works fine:

# wipefs -a /dev/sda; wipefs -a /dev/sda
# busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
(immediately succeeds)

# blkid -p /dev/sda
/dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

I tested this to a QEMU emulated disk, but it reproduces equally well
against a `modprobe scsi_debug` device.

Package: udisks2 2.9.2-1
DistroRelease: Ubuntu 21.04

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


** Tags: hirsute regression-release

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

Title:
  [21.04 regression] formatting vfat times out

Status in udisks2 package in Ubuntu:
  New

Bug description:
  There is a regression somewhere between udisks, udev, and dosfstools.
  Formatting a device with vfat hangs and fails:

  # blkid -p /dev/sda
  (nothing)

  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' vfat 0
  (long pause)
  Call failed: Error synchronizing after formatting with type `vfat': Timed out 
waiting for object

  # blkid -p /dev/sda
  /dev/sda: PTUUID="3690494f" PTTYPE="dos"

  OTOH, formatting as ext4 works fine:

  # wipefs -a /dev/sda; wipefs -a /dev/sda
  # busctl call org.freedesktop.UDisks2 
/org/freedesktop/UDisks2/block_devices/sda org.freedesktop.UDisks2.Block Format 
'sa{sv}' ext4 0
  (immediately succeeds)

  # blkid -p /dev/sda
  /dev/sda: UUID="8bea7475-6af5-4835-86d0-0e5b2cb5500e" VERSION="1.0" 
BLOCK_SIZE="4096" TYPE="ext4" USAGE="filesystem"

  I tested this to a QEMU emulated disk, but it reproduces equally well
  against a `modprobe scsi_debug` device.

  Package: udisks2 2.9.2-1
  DistroRelease: Ubuntu 21.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1925822/+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 1906320] Re: fake-device-wrapper should bind-mount efivars

2020-11-30 Thread Martin Pitt
FTR, I would strongly advise against that, see
https://github.com/martinpitt/umockdev/issues/110#issuecomment-736224503
. You want the tests to work independently on the hardware it's running
on, so that you can run it on e.g. standard autopkgtest infra.

You could create /sys/firmware/efi/efivars/ tarballs of a bunch of real
systems with the properties that you want, keep them in the tests, and
unpack these in your test cases. You most probably just need a few of
them, so you can strip them down or possibly create them individually as
files, but a full tarball might be the quickest start.

** Bug watch added: github.com/martinpitt/umockdev/issues #110
   https://github.com/martinpitt/umockdev/issues/110

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

Title:
  fake-device-wrapper should bind-mount efivars

Status in ubuntu-drivers-common package in Ubuntu:
  New

Bug description:
  /usr/share/ubuntu-drivers-common/fake-devices-wrapper should bindmount
  efivars under testbed.get_root_dir().

  Ie. such that /sys/firmware/efi/efivars is correctly available under
  the umockdev test-bed.

  That way when testing subiquity, it should correctly observe if it was
  booted under secureboot, or not.

  Or maybe we can create a few options to fake-devices-wrapper whether
  or not to present Secureboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1906320/+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 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
Nevermind then, this is working well enough for a stable release.

** Changed in: network-manager (Ubuntu Bionic)
   Status: New => Won't Fix

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium

  Restarting NetworkManager does not help, nor does rebooting.

  DistroRelease: Ubuntu 18.04
  Package: 1.10.6-2ubuntu1.1
  Architecture: amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
I confirm that using a valid IP works better:

In the config:

route1=fe80:2::/60,fe80::99,42

# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
fe80:2::/60 via fe80::99 proto static metric 42 pref medium

It's still missing the route to fe80:2:: itself, though.

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium

  Restarting NetworkManager does not help, nor does rebooting.

  DistroRelease: Ubuntu 18.04
  Package: 1.10.6-2ubuntu1.1
  Architecture: amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
The journal says why:

NetworkManager[1295]:   [1563552648.1667] platform: route-sync: failure 
to add IPv6 route: 1:2::/60 via 1:2::3 dev 6 metric 42 mss 0 rt-src user: No 
route to host (113)
NetworkManager[1295]:   [1563552648.1672] device (eth2): failed to apply 
manual IPv6 configuration

Apparently later versions ignore non-reachable hosts and set the route
anyway?


** Description changed:

  I have a system connection like this:
  
  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266
  
  [ethernet]
  mac-address-blacklist=
  
  [ipv4]
  dns-search=
  method=shared
  
  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -
  
  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.
  
  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium
  
  (There, the file is called eth2.nmconnection, but same difference)
  
  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101
  
  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium
  
  Restarting NetworkManager does not help, nor does rebooting.
+ 
+ DistroRelease: Ubuntu 18.04
+ Package: 1.10.6-2ubuntu1.1
+ Architecture: amd64

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium

  

[Desktop-packages] [Bug 1837233] [NEW] [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
Public bug reported:

I have a system connection like this:

-- /etc/NetworkManager/system-connections/eth2  ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=shared

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -

In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus,  I'm just using this to test cockpit's
web UI.

On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium

(There, the file is called eth2.nmconnection, but same difference)

On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:

# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium

Restarting NetworkManager does not help, nor does rebooting.

DistroRelease: Ubuntu 18.04
Package: 1.10.6-2ubuntu1.1
Architecture: amd64

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

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

** Also affects: network-manager (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: network-manager (Ubuntu)
   Status: New => Fix Released

** Description changed:

  I have a system connection like this:
  
  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266
  
  [ethernet]
  mac-address-blacklist=
  
  [ipv4]
  dns-search=
  method=shared
  
  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -
  
  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.
  
  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
-  ip -6 route show dev eth2
+ # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium
  
  (There, the file is called eth2.nmconnection, but same difference)
  
  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101
  
  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium
  
  Restarting NetworkManager does not help, nor does rebooting.

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  New

Bug description:
  I have a system 

[Desktop-packages] [Bug 1805348] Re: Recent security update broke server-side keyboard-interactive authentication

2018-11-29 Thread Martin Pitt
Wow, thanks Marc, this was super-fast!

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

Title:
  Recent security update broke server-side keyboard-interactive
  authentication

Status in libssh package in Ubuntu:
  Fix Released
Status in libssh source package in Trusty:
  Fix Released
Status in libssh source package in Xenial:
  Fix Released
Status in libssh source package in Bionic:
  Fix Released
Status in libssh source package in Cosmic:
  Fix Released
Status in libssh package in Debian:
  New

Bug description:
  0.8.4 and the backported fixes for CVE-2018-10933 cause server-side
  keyboard-interactive authentication to completely break. See
  https://bugs.libssh.org/T117 for details and a reproducer.

  This was fixed upstream as part of the 0.8.5 release, so disco is
  fine. For 16.04/18.04/18.10, please backport the fix:

https://git.libssh.org/projects/libssh.git/commit/?id=4ea46eecce9f4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1805348/+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 1805348] [NEW] Recent security update broke server-side keyboard-interactive authentication

2018-11-27 Thread Martin Pitt
Public bug reported:

0.8.4 and the backported fixes for CVE-2018-10933 cause server-side
keyboard-interactive authentication to completely break. See
https://bugs.libssh.org/T117 for details and a reproducer.

This was fixed upstream as part of the 0.8.5 release, so disco is fine.
For 16.04/18.04/18.10, please backport the fix:

  https://git.libssh.org/projects/libssh.git/commit/?id=4ea46eecce9f4

** Affects: libssh (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: libssh (Ubuntu Xenial)
 Importance: High
 Status: Triaged

** Affects: libssh (Ubuntu Bionic)
 Importance: High
 Status: Triaged

** Affects: libssh (Ubuntu Cosmic)
 Importance: High
 Status: Triaged

** Affects: libssh (Debian)
 Importance: Unknown
 Status: Unknown


** Tags: bionic cosmic regression-release xenial

** Tags added: bionic cosmic regression-release xenial

** Also affects: libssh (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: libssh (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libssh (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libssh (Ubuntu)
   Status: New => Fix Released

** Changed in: libssh (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: libssh (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: libssh (Ubuntu Cosmic)
   Status: New => Triaged

** Changed in: libssh (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: libssh (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: libssh (Ubuntu Cosmic)
   Importance: Undecided => High

** Bug watch added: Debian Bug tracker #913870
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913870

** Also affects: libssh (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913870
   Importance: Unknown
   Status: Unknown

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

Title:
  Recent security update broke server-side keyboard-interactive
  authentication

Status in libssh package in Ubuntu:
  Fix Released
Status in libssh source package in Xenial:
  Triaged
Status in libssh source package in Bionic:
  Triaged
Status in libssh source package in Cosmic:
  Triaged
Status in libssh package in Debian:
  Unknown

Bug description:
  0.8.4 and the backported fixes for CVE-2018-10933 cause server-side
  keyboard-interactive authentication to completely break. See
  https://bugs.libssh.org/T117 for details and a reproducer.

  This was fixed upstream as part of the 0.8.5 release, so disco is
  fine. For 16.04/18.04/18.10, please backport the fix:

https://git.libssh.org/projects/libssh.git/commit/?id=4ea46eecce9f4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1805348/+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 1799665] Re: [cosmic regression] fails to parse known_hosts, resulting in SSH_SERVER_FOUND_OTHER error for hostkey verification

2018-11-08 Thread Martin Pitt
I installed libssh-4 0.8.1-1ubuntu0.2 from cosmic-proposed, and confirm
that the manual ssh connection with "cockpit-ssh" as well as all the
integration tests that involve talking to remote machines through ssh
now work.

** Tags removed: verification-needed verification-needed-cosmic
** Tags added: verification-done verification-done-cosmic

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

Title:
  [cosmic regression] fails to parse known_hosts, resulting in
  SSH_SERVER_FOUND_OTHER error for hostkey verification

Status in libssh package in Ubuntu:
  In Progress
Status in libssh source package in Cosmic:
  Fix Committed

Bug description:
  Ubuntu 18.10's libssh 0.8.1 regresses parsing of known_hosts. This
  happens (sometimes) if there are multiple known_host key types (e. g.
  ssh-rsa and ssh-ed25519), then it can happen that
  ssh_session_is_known_server() fails with SSH_SERVER_FOUND_OTHER [1].

  I noticed this with testing Cockpit on Ubuntu 18.10 [2], which has a
  few test cases exercising cockpit-ssh (which uses libssh), e. g. [3].
  The scenario is a FreeIPA centrally managed known_hosts file with
  these entries:

  x0.cockpit.lan ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCv5sLKfLDuEAbTcHC3eOgJM+Ot7F077KewD4e1lGzfw300Jo4xnuPsoJEVSCR7OjsYQCnuVGlqtlavMCLFzIBNk06iTBg/nl+W+xa3CFNITbAjiBif7SeY0XL6Xeqzb1VYXNVfwKQKpcGIbDne6jyou4wRZV1eay03FHTSkd2+XKM6GOUGlkEUoPyAwYPHqoKUYiiyBxJs20l/peXVx6jsGgs2Sc6gl3KJP0TB2E7ncD1pWHGRtiNshFFVarw/YKr+Rs+KhiVS3CAAfYDhpBNWXOwTKyx2euJjAhsRF10bx6pnuadSEpT8Ufo5/YFIVAD1GHptULSzVjUoJm6ktoHB
  x0.cockpit.lan ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCkJ6CaqhzUhrbpbVmZ8BmZZgM3u6BukZ6HFB2a4NLQBdgpHlHbxoJ47ocTImctyFMiDi0y6vCb4tFuZgp6Krmk=
 root@(none)
  x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh root@(none)

  Connecting to that host with the standard ssh client works:

  $ ssh -vv x0.cockpit.lan
  [...]
  debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:MgfkN6HEl+pdz0X7+6q08IVkUZOtEDzfA6V18Wm9DgA
  debug1: Host 'x0.cockpit.lan' is known and matches the ECDSA host key.
  debug1: Found key in /var/lib/sss/pubconf/known_hosts:3
  [...]
  ad...@cockpit.lan@x0:~$

  But not with cockpit-ssh. This shows the JSON protocol (note that you
  need to copy the correct cookie value from the response):

  $ G_MESSAGES_DEBUG=cockpit-ssh cockpit-bridge --interact=---

  { "command": "open", "channel": "c", "payload": "echo", "host": 
"x0.cockpit.lan", "user": "ad...@cockpit.lan" }
  ---

  {"command":"authorize","challenge":"*","cookie":"session107271540364829"}
  ---

  {"command":"authorize", "response": "password foobarfoo", "cookie": 
"session107271540364829"}
  ---
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.049: cockpit-ssh 
x0.cockpit.lan: host not known in any local file, asking sssd
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.472: cockpit-ssh 
x0.cockpit.lan: using known hosts file /tmp/known-hosts.IDKNRZ
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.542: cockpit-ssh 
x0.cockpit.lan: connected
  cockpit-ssh-Message: 03:07:30.828: cockpit-ssh x0.cockpit.lan: host key for 
this server changed key type: ssh-ed25519

  {"command":"close","host-key":"x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh\n","host-fingerprint":"a0:27:1e:80:de:fd:4b:8a:0d:9d:a9:b6:42:7d:5c:b9","problem":"invalid-hostkey","error":"invalid-hostkey","auth-method-results":{},"channel":"c"}
  ---

  The "host key for this server changed key type" is the effect of this
  bug.


  SRU INFORMATION:

  [IMPACT]: libssh connections that worked in previous Ubuntu releases
  now may fail on host key verification

  [TEST CASE]: See reproducer below. This isn't too easy to reproduce
  for someone else, so I'm happy to do the validation myself. This can
  also be verified with the Cockpit integration tests:

  bots/image-prepare ubuntu-stable
  TEST_OS=ubuntu-stable test/verify/check-realms TestRealms.testIpa

  [REGRESSION POTENTIAL]: In principle these patches could break known_hosts 
validation further. However, these fixes have been in Debian testing for a 
while and validated through e. g. Cockpit's tests (which exercise cockpit-ssh 
quite heavily). There are also upstream unit tests, and while they didn't pick 
up that particular regression, they at least make sure that known_hosts 
verification still works for common  cases.
  Also, libssh-4 does not have that many reverse dependencies. So overall, I 
think this is bearable for an SRU, especially as the impact is quite high.

  [1] 
http://api.libssh.org/master/group__libssh__session.html#gac%20bc5d04fe66beee863a0c61a93fdf765
  [2] https://github.com/cockpit-project/cockpit/pull/10357
  [3] 

[Desktop-packages] [Bug 1799665] [NEW] [cosmic regression] fails to parse known_hosts, resulting in SSH_SERVER_FOUND_OTHER error for hostkey verification

2018-10-24 Thread Martin Pitt
Public bug reported:

Ubuntu 18.10's libssh 0.8.1 regresses parsing of known_hosts. This
happens (sometimes) if there are multiple known_host key types (e. g.
ssh-rsa and ssh-ed25519), then it can happen that
ssh_session_is_known_server() fails with SSH_SERVER_FOUND_OTHER [1].

I noticed this with testing Cockpit on Ubuntu 18.10 [2], which has a few
test cases exercising cockpit-ssh (which uses libssh), e. g. [3]. The
scenario is a FreeIPA centrally managed known_hosts file with these
entries:

x0.cockpit.lan ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCv5sLKfLDuEAbTcHC3eOgJM+Ot7F077KewD4e1lGzfw300Jo4xnuPsoJEVSCR7OjsYQCnuVGlqtlavMCLFzIBNk06iTBg/nl+W+xa3CFNITbAjiBif7SeY0XL6Xeqzb1VYXNVfwKQKpcGIbDne6jyou4wRZV1eay03FHTSkd2+XKM6GOUGlkEUoPyAwYPHqoKUYiiyBxJs20l/peXVx6jsGgs2Sc6gl3KJP0TB2E7ncD1pWHGRtiNshFFVarw/YKr+Rs+KhiVS3CAAfYDhpBNWXOwTKyx2euJjAhsRF10bx6pnuadSEpT8Ufo5/YFIVAD1GHptULSzVjUoJm6ktoHB
x0.cockpit.lan ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCkJ6CaqhzUhrbpbVmZ8BmZZgM3u6BukZ6HFB2a4NLQBdgpHlHbxoJ47ocTImctyFMiDi0y6vCb4tFuZgp6Krmk=
 root@(none)
x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh root@(none)

Connecting to that host with the standard ssh client works:

$ ssh -vv x0.cockpit.lan
[...]
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:MgfkN6HEl+pdz0X7+6q08IVkUZOtEDzfA6V18Wm9DgA
debug1: Host 'x0.cockpit.lan' is known and matches the ECDSA host key.
debug1: Found key in /var/lib/sss/pubconf/known_hosts:3
[...]
ad...@cockpit.lan@x0:~$

But not with cockpit-ssh. This shows the JSON protocol (note that you
need to copy the correct cookie value from the response):

$ G_MESSAGES_DEBUG=cockpit-ssh cockpit-bridge --interact=---

{ "command": "open", "channel": "c", "payload": "echo", "host": 
"x0.cockpit.lan", "user": "ad...@cockpit.lan" }
---

{"command":"authorize","challenge":"*","cookie":"session107271540364829"}
---

{"command":"authorize", "response": "password foobarfoo", "cookie": 
"session107271540364829"}
---
(cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.049: cockpit-ssh 
x0.cockpit.lan: host not known in any local file, asking sssd
(cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.472: cockpit-ssh 
x0.cockpit.lan: using known hosts file /tmp/known-hosts.IDKNRZ
(cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.542: cockpit-ssh 
x0.cockpit.lan: connected
cockpit-ssh-Message: 03:07:30.828: cockpit-ssh x0.cockpit.lan: host key for 
this server changed key type: ssh-ed25519

{"command":"close","host-key":"x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh\n","host-fingerprint":"a0:27:1e:80:de:fd:4b:8a:0d:9d:a9:b6:42:7d:5c:b9","problem":"invalid-hostkey","error":"invalid-hostkey","auth-method-results":{},"channel":"c"}
---

The "host key for this server changed key type" is the effect of this
bug.


SRU INFORMATION:

[IMPACT]: libssh connections that worked in previous Ubuntu releases now
may fail on host key verification

[TEST CASE]: See reproducer below. This isn't too easy to reproduce for
someone else, so I'm happy to do the validation myself. This can also be
verified with the Cockpit integration tests:

bots/image-prepare ubuntu-stable
TEST_OS=ubuntu-stable test/verify/check-realms TestRealms.testIpa

[REGRESSION POTENTIAL]: In principle these patches could break known_hosts 
validation further. However, these fixes have been in Debian testing for a 
while and validated through e. g. Cockpit's tests (which exercise cockpit-ssh 
quite heavily). There are also upstream unit tests, and while they didn't pick 
up that particular regression, they at least make sure that known_hosts 
verification still works for common  cases.
Also, libssh-4 does not have that many reverse dependencies. So overall, I 
think this is bearable for an SRU, especially as the impact is quite high.

[1] 
http://api.libssh.org/master/group__libssh__session.html#gac%20bc5d04fe66beee863a0c61a93fdf765
[2] https://github.com/cockpit-project/cockpit/pull/10357
[3] 
https://fedorapeople.org/groups/cockpit/logs/pull-10357-20181022-204242-8672df31-verify-ubuntu-stable/log.html#186

** Affects: libssh (Ubuntu)
 Importance: Undecided
 Assignee: Martin Pitt (pitti)
 Status: In Progress

** Affects: libssh (Ubuntu Cosmic)
 Importance: Undecided
 Assignee: Martin Pitt (pitti)
 Status: In Progress


** Tags: cosmic regression-release

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

Title:
  [cosmic re

[Desktop-packages] [Bug 1799665] Re: [cosmic regression] fails to parse known_hosts, resulting in SSH_SERVER_FOUND_OTHER error for hostkey verification

2018-10-24 Thread Martin Pitt
This works fine with the latest libssh 0.8.4, when building the Debian
unstable package for 18.10, it works fine:

$ G_MESSAGES_DEBUG=cockpit-ssh cockpit-bridge --interact=---

{ "command": "open", "channel": "c", "payload": "echo", "host": 
"x0.cockpit.lan", "user": "ad...@cockpit.lan" }
---

{"command":"authorize","challenge":"*","cookie":"session109311540371777"}
---

{"command":"authorize", "response": "password foobarfoo", 
"cookie":"session109311540371777"}
---
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:06.880: cockpit-ssh 
x0.cockpit.lan: host not known in any local file, asking sssd
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.165: cockpit-ssh 
x0.cockpit.lan: using known hosts file /tmp/known-hosts.KIBHRZ
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.248: cockpit-ssh 
x0.cockpit.lan: connected
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.249: cockpit-ssh 
x0.cockpit.lan: verified host key
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.278: cockpit-ssh 
x0.cockpit.lan: agent auth failed
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.282: cockpit-ssh 
x0.cockpit.lan: Got prompt Password:  prompt
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.995: cockpit-ssh 
x0.cockpit.lan: Couldn't set COCKPIT_REMOTE_PEER: Channel request env failed
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:07.995: cockpit-ssh 
x0.cockpit.lan: opened channel
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:08.071: cockpit-ssh 
x0.cockpit.lan: queued 162 bytes
(cockpit-ssh:10931): cockpit-ssh-DEBUG: 05:03:08.071: cockpit-ssh 
x0.cockpit.lan: wrote 162 bytes

{"command":"ready","channel":"c"}
---


I bisected this to this upstream fix:
https://git.libssh.org/projects/libssh.git/commit/?id=45058285fca549876449afef2c32833b24817e77
. I prepare an SRU.

There are also a few other known_hosts fixes which should get included:


https://git.libssh.org/projects/libssh.git/commit/?id=35a64554899f142a2b8b68c79007ad9c3ce00cb1

https://git.libssh.org/projects/libssh.git/commit/?id=c1a8c41c5daf79e37aa5fde67dd94c8596e81102

https://git.libssh.org/projects/libssh.git/commit/?id=893b69d82b4435973ec4d15aaecdf352f5f827e2


** Also affects: libssh (Ubuntu Cosmic)
   Importance: Undecided
 Assignee: Martin Pitt (pitti)
   Status: New

** Changed in: libssh (Ubuntu Cosmic)
   Status: New => In Progress

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

Title:
  [cosmic regression] fails to parse known_hosts, resulting in
  SSH_SERVER_FOUND_OTHER error for hostkey verification

Status in libssh package in Ubuntu:
  In Progress
Status in libssh source package in Cosmic:
  In Progress

Bug description:
  Ubuntu 18.10's libssh 0.8.1 regresses parsing of known_hosts. This
  happens (sometimes) if there are multiple known_host key types (e. g.
  ssh-rsa and ssh-ed25519), then it can happen that
  ssh_session_is_known_server() fails with SSH_SERVER_FOUND_OTHER [1].

  I noticed this with testing Cockpit on Ubuntu 18.10 [2], which has a
  few test cases exercising cockpit-ssh (which uses libssh), e. g. [3].
  The scenario is a FreeIPA centrally managed known_hosts file with
  these entries:

  x0.cockpit.lan ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCv5sLKfLDuEAbTcHC3eOgJM+Ot7F077KewD4e1lGzfw300Jo4xnuPsoJEVSCR7OjsYQCnuVGlqtlavMCLFzIBNk06iTBg/nl+W+xa3CFNITbAjiBif7SeY0XL6Xeqzb1VYXNVfwKQKpcGIbDne6jyou4wRZV1eay03FHTSkd2+XKM6GOUGlkEUoPyAwYPHqoKUYiiyBxJs20l/peXVx6jsGgs2Sc6gl3KJP0TB2E7ncD1pWHGRtiNshFFVarw/YKr+Rs+KhiVS3CAAfYDhpBNWXOwTKyx2euJjAhsRF10bx6pnuadSEpT8Ufo5/YFIVAD1GHptULSzVjUoJm6ktoHB
  x0.cockpit.lan ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCkJ6CaqhzUhrbpbVmZ8BmZZgM3u6BukZ6HFB2a4NLQBdgpHlHbxoJ47ocTImctyFMiDi0y6vCb4tFuZgp6Krmk=
 root@(none)
  x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh root@(none)

  Connecting to that host with the standard ssh client works:

  $ ssh -vv x0.cockpit.lan
  [...]
  debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:MgfkN6HEl+pdz0X7+6q08IVkUZOtEDzfA6V18Wm9DgA
  debug1: Host 'x0.cockpit.lan' is known and matches the ECDSA host key.
  debug1: Found key in /var/lib/sss/pubconf/known_hosts:3
  [...]
  ad...@cockpit.lan@x0:~$

  But not with cockpit-ssh. This shows the JSON protocol (note that you
  need to copy the correct cookie value from the response):

  $ G_MESSAGES_DEBUG=cockpit-ssh cockpit-bridge --interact=---

  { "command": "open", "channel": "c", "payload": "echo", "host": 
"x0.cockpit.lan", "user": "ad...@cockpit.lan" }
 

[Desktop-packages] [Bug 1799665] Re: [cosmic regression] fails to parse known_hosts, resulting in SSH_SERVER_FOUND_OTHER error for hostkey verification

2018-10-24 Thread Martin Pitt
Added SRU information and uploaded SRU to unapproved queue.

** Description changed:

  Ubuntu 18.10's libssh 0.8.1 regresses parsing of known_hosts. This
  happens (sometimes) if there are multiple known_host key types (e. g.
  ssh-rsa and ssh-ed25519), then it can happen that
  ssh_session_is_known_server() fails with SSH_SERVER_FOUND_OTHER [1].
  
  I noticed this with testing Cockpit on Ubuntu 18.10 [2], which has a few
- test cases exercising cockpit-ssh (which uses libssh). The scenario is a
- FreeIPA centrally managed known_hosts file with these entries:
+ test cases exercising cockpit-ssh (which uses libssh), e. g. [3]. The
+ scenario is a FreeIPA centrally managed known_hosts file with these
+ entries:
  
  x0.cockpit.lan ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCv5sLKfLDuEAbTcHC3eOgJM+Ot7F077KewD4e1lGzfw300Jo4xnuPsoJEVSCR7OjsYQCnuVGlqtlavMCLFzIBNk06iTBg/nl+W+xa3CFNITbAjiBif7SeY0XL6Xeqzb1VYXNVfwKQKpcGIbDne6jyou4wRZV1eay03FHTSkd2+XKM6GOUGlkEUoPyAwYPHqoKUYiiyBxJs20l/peXVx6jsGgs2Sc6gl3KJP0TB2E7ncD1pWHGRtiNshFFVarw/YKr+Rs+KhiVS3CAAfYDhpBNWXOwTKyx2euJjAhsRF10bx6pnuadSEpT8Ufo5/YFIVAD1GHptULSzVjUoJm6ktoHB
  x0.cockpit.lan ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCkJ6CaqhzUhrbpbVmZ8BmZZgM3u6BukZ6HFB2a4NLQBdgpHlHbxoJ47ocTImctyFMiDi0y6vCb4tFuZgp6Krmk=
 root@(none)
  x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh root@(none)
  
  Connecting to that host with the standard ssh client works:
  
  $ ssh -vv x0.cockpit.lan
  [...]
  debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:MgfkN6HEl+pdz0X7+6q08IVkUZOtEDzfA6V18Wm9DgA
  debug1: Host 'x0.cockpit.lan' is known and matches the ECDSA host key.
  debug1: Found key in /var/lib/sss/pubconf/known_hosts:3
  [...]
  ad...@cockpit.lan@x0:~$
  
  But not with cockpit-ssh. This shows the JSON protocol (note that you
  need to copy the correct cookie value from the response):
  
  $ G_MESSAGES_DEBUG=cockpit-ssh cockpit-bridge --interact=---
  
  { "command": "open", "channel": "c", "payload": "echo", "host": 
"x0.cockpit.lan", "user": "ad...@cockpit.lan" }
  ---
  
  {"command":"authorize","challenge":"*","cookie":"session107271540364829"}
  ---
  
  {"command":"authorize", "response": "password foobarfoo", "cookie": 
"session107271540364829"}
  ---
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.049: cockpit-ssh 
x0.cockpit.lan: host not known in any local file, asking sssd
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.472: cockpit-ssh 
x0.cockpit.lan: using known hosts file /tmp/known-hosts.IDKNRZ
  (cockpit-ssh:10814): cockpit-ssh-DEBUG: 03:11:51.542: cockpit-ssh 
x0.cockpit.lan: connected
  cockpit-ssh-Message: 03:07:30.828: cockpit-ssh x0.cockpit.lan: host key for 
this server changed key type: ssh-ed25519
  
  {"command":"close","host-key":"x0.cockpit.lan ssh-ed25519 
C3NzaC1lZDI1NTE5INK6gcOyH4OhiKPcNr33Kl6e+wFAUy9tGFBU/o4yWkxh\n","host-fingerprint":"a0:27:1e:80:de:fd:4b:8a:0d:9d:a9:b6:42:7d:5c:b9","problem":"invalid-hostkey","error":"invalid-hostkey","auth-method-results":{},"channel":"c"}
  ---
  
+ The "host key for this server changed key type" is the effect of this
+ bug.
  
- The "host key for this server changed key type" is the effect of this bug.
+ 
+ SRU INFORMATION:
+ 
+ [IMPACT]: libssh connections that worked in previous Ubuntu releases now
+ may fail on host key verification
+ 
+ [TEST CASE]: See reproducer below. This isn't too easy to reproduce for
+ someone else, so I'm happy to do the validation myself. This can also be
+ verified with the Cockpit integration tests:
+ 
+ bots/image-prepare ubuntu-stable
+ TEST_OS=ubuntu-stable test/verify/check-realms TestRealms.testIpa
+ 
+ [REGRESSION POTENTIAL]: In principle these patches could break known_hosts 
validation further. However, these fixes have been in Debian testing for a 
while and validated through e. g. Cockpit's tests (which exercise cockpit-ssh 
quite heavily). There are also upstream unit tests, and while they didn't pick 
up that particular regression, they at least make sure that known_hosts 
verification still works for common  cases.
+ Also, libssh-4 does not have that many reverse dependencies. So overall, I 
think this is bearable for an SRU, especially as the impact is quite high.
  
  [1] 
http://api.libssh.org/master/group__libssh__session.html#gac%20bc5d04fe66beee863a0c61a93fdf765
  [2] https://github.com/cockpit-project/cockpit/pull/10357
+ [3] 
https://fedorapeople.org/groups/cockpit/logs/pull-10357-20181022-204242-8672df31-verify-ubuntu-stable/log.html#186

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

Title:
  [cosmic regression] fails to parse known_hosts, resulting in
  SSH_SERVER_FOUND_OTHER error for hostkey verification

Status in libssh package in Ubuntu:
  In Progress
Status in libssh source package in Cosmic:
  In Progress

Bug description:
  

[Desktop-packages] [Bug 1796407] Re: pg_wrapper doesn't work when -p is used

2018-10-18 Thread Martin Pitt
@Robie: It's been a while since I dabbled with this, but to me this is
not really "wishlist", it's an actual bug. Surely pg_wrapper doesn't
document that it looks at the explicitly specified port, but it
certainly ought to. This case was just plain forgotten.

So the patch certainly needs some massaging, at least:

 - adjust it to current version [1], which e. g. has $explicit_port instead of 
$port_specified
 - Fix the "locahost" typo, and support IP addresses as well (127.0.0.* or ::1)
 - Add an integration test to 
https://salsa.debian.org/postgresql/postgresql-common/blob/master/t/090_multicluster.t

but the general heading of it seems fine to me.

[1] https://salsa.debian.org/postgresql/postgresql-
common/blob/master/pg_wrapper

** Changed in: postgresql-common (Ubuntu)
   Importance: Wishlist => Medium

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

Title:
  pg_wrapper doesn't work when -p is used

Status in postgresql-common package in Ubuntu:
  Triaged

Bug description:
  Release:16.04

  pg_wrapper currently relies upon either run-time-supplied data or fixed files 
which can become out of date to select the correct version of clients. 
  Alternatively it chooses (potentially incompatible) versions of installed 
programs  based on which cluster is using port 5432, even when a different port 
is in use, despite code intended to default to the newest version.

  The problem is that the call to user_cluster_map() returns the default port, 
and thus the
  condition just below this comment is not executed:

  # if we only have a port, but no version here, use the latest version
  # TODO: this could be improved by better argument parsing and mapping back the
  # port to a cluster version/name
  if (!$version and $port_specified) {
  $version = get_newest_version;
  }

  E.g. (here shown for an old system which has 9.1 on port 5432, and 9.3 on 
port 5433, similar results have been obtained on more up to date systems):
  pg_dump -p 5433
  pg_dump: server version: 9.3.24; pg_dump version: 9.1.24
  pg_dump: aborting because of server version mismatch

  Observed behaviour, ignore port value and newest version and instead choose 
version from port 5432.
  Expected behaviour: (as per code below comment) choose version 9.3

  The supplied patch implements the TODO: above. 
  If a port (and no host other than localhost) has been specified, it 
interrogates the configuration files to identify which cluster and version is 
listening on the specified port (via -p, --port or PGPORT environment variable) 
and selects those in the case that a port has been specified.

  NB. the patch will probably not apply cleanly to the current version
  in debian/sid, as some reworking of that has happened. Looking at that
  code, however, the problem addressed here has not gone away:
  user_cluster_map() still returns a port while the code in pg_wrapper
  expects it not to.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1796407/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
FTR, I don't want to blame the NetworkManager 1.2.6 SRU to xenial - that
new upstream version now evades the version test in the postinst, but of
course it's still that version test which is at fault. I don't see how
we can use a simple version test to determine the situation that we want
(one-time test after upgrading from 16.04 LTS), I suppose it needs to
move to "$2 is not empty" plus creating a migration stamp file
somewhere.

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
Is that any better with the fix in bug 1690992? That sounds very much
like a duplicate?

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
I'm sorry, I mean bug 1676547.

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+subscriptions

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


Re: [Desktop-packages] [Bug 1647031] Re:systemd-resolved’s127.0.0.53 server does not follow CNAME records

2017-03-15 Thread Martin Pitt
Blaisorblade [2017-03-15 15:03 -]:
> Another corner case seems to be binaries linked against musl libc, since
> they do not use NSS.

Note that this is generally broken and cannot be supported, regardless of the
DNS resolver. These binaries could also not resolve winbind host names, YP,
LDAP, Active Directory, or sssd users/groups, and anything else which is
handled through nsswitch.

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in Nextcloud:
  Unknown
Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Yakkety:
  Invalid
Status in systemd source package in Yakkety:
  Triaged

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nextcloud-snap/+bug/1647031/+subscriptions

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


Re: [Desktop-packages] [Bug 1666676] Re: Enable tracker by default for Unity too

2017-03-01 Thread Martin Pitt
Carlos Garnacho [2017-03-01 10:59 -]:
> > - Is it acceptable to have approximate search results if the indexing isn't 
> > (yet) up to date?
> 
> If tracker-miner-fs is not paused/throttled down, it will pick up
> changes in monitored folders just as fast as any other app, there is
> very little extra overhead above the gio/inotify delays.

> > - Does it significantly affect battery life?
> 
> Given Tracker is pretty conservative while on battery, that's a bold "no".

It's hard to make these statements simultaneously be true. There's clearly a
trade-off between correctness and efficiency here. Unless nautilus pokes
tracker to wake up and do a shallow (no previews, etc.) index/force-refresh the
searched-for directory unthrottled right away? Then that would be the
equivalent of a "classic" search, except that the gained data would be
available in the tracker DB for the next time.

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

Title:
  Enable tracker by default for Unity too

Status in nautilus package in Ubuntu:
  New

Bug description:
  For Nautilus' built-in search to not be very slow, Nautilus needs to
  use tracker for search.

  This is especially important since it's being seriously proposed for
  Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted
  the removal of that feature by Nautilus years ago. (LP: #181)

  To not cripple Ubuntu GNOME, it was previously decided to let Nautilus
  build against tracker but not use that functionality on Unity. See
  this patch:

  https://bazaar.launchpad.net/~ubuntu-
  
desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

  This bug is requesting that patch be dropped and the extra tracker
  components be allowed into main and installed by default in Unity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/176/+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 1666676] Re: Enable tracker by default for Unity too

2017-02-28 Thread Martin Pitt
> To summarize, I see 2 performance questions:

I'd add:

 - Is it acceptable to have approximate search results if the indexing isn't 
(yet) up to date?
 - Does it significantly affect battery life?

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

Title:
  Enable tracker by default for Unity too

Status in nautilus package in Ubuntu:
  New

Bug description:
  For Nautilus' built-in search to not be very slow, Nautilus needs to
  use tracker for search.

  This is especially important since it's being seriously proposed for
  Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted
  the removal of that feature by Nautilus years ago. (LP: #181)

  To not cripple Ubuntu GNOME, it was previously decided to let Nautilus
  build against tracker but not use that functionality on Unity. See
  this patch:

  https://bazaar.launchpad.net/~ubuntu-
  
desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

  This bug is requesting that patch be dropped and the extra tracker
  components be allowed into main and installed by default in Unity.

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

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


Re: [Desktop-packages] [Bug 1666676] Re: Enable tracker by default for Unity too

2017-02-28 Thread Martin Pitt
Hello Carlos,

Carlos [2017-02-28 13:58 -]:
> Just wanted to mention I disagree with your statements and that I have
> the opposite experience and feedback from users (we agree we disagree,
> which is fine of course :)).

Yep :-) (I'm not making the call anyway). Thanks for sharing your
perspective (e. g. both techies and non-tech people I know don't use full
search, so interesting to read what other people use it for).

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

Title:
  Enable tracker by default for Unity too

Status in nautilus package in Ubuntu:
  New

Bug description:
  For Nautilus' built-in search to not be very slow, Nautilus needs to
  use tracker for search.

  This is especially important since it's being seriously proposed for
  Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted
  the removal of that feature by Nautilus years ago. (LP: #181)

  To not cripple Ubuntu GNOME, it was previously decided to let Nautilus
  build against tracker but not use that functionality on Unity. See
  this patch:

  https://bazaar.launchpad.net/~ubuntu-
  
desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

  This bug is requesting that patch be dropped and the extra tracker
  components be allowed into main and installed by default in Unity.

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

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


Re: [Desktop-packages] [Bug 1666676] Re: Enable tracker by default for Unity too

2017-02-28 Thread Martin Pitt
Carlos [2017-02-28 12:08 -]:
> "Tracker imposes a huge cost due to always indexing everything"
> As long as is low priority and the kernel scheduler works fine it shouldn't 
> be an issue.

This isn't true. This will use a lot more CPU and disk cycles, thus decreasing
battery life. Or, if you don't index while on battery, it's going to be even
less reliable.

> "So I don't see how "enable tracker" can ever be a replacement for typeahead
> search" Maybe I was not clear enough in my first post. (don't mean to be
> rude, just clear) Tracker is needed for search in Nautilus. Period.

That's the bit I'm totally not convinced of. Due to it's "background/async"
nature, it's not reliable for searching, and it's also way too much overhead to
replace a single-directory level search (i. e. what you usually do for
typeahead search). Doing a fully recursive search is okay to be slow, as that's
only being used seldomly, and if you do it you most probably want the results
to be correct, not approximative.

So my (very subjective) opinion is that any indexing tool is not an appropriate
backend for searching. This isn't particularly tracker's fault, it's just the
nature of what an indexer is. Also, note that I'm not speaking authoritatively
for the Ubuntu desktop team, this is just my personal opinion. I would just not
appreciate it to see getting an indexer imposed onto everyone for rare use
cases (like content-based batch renaming) -- optimize for the common case
instead. As I said, if you care about content preview etc., it's still fine to
give users an opt-in into this.

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

Title:
  Enable tracker by default for Unity too

Status in nautilus package in Ubuntu:
  New

Bug description:
  For Nautilus' built-in search to not be very slow, Nautilus needs to
  use tracker for search.

  This is especially important since it's being seriously proposed for
  Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted
  the removal of that feature by Nautilus years ago. (LP: #181)

  To not cripple Ubuntu GNOME, it was previously decided to let Nautilus
  build against tracker but not use that functionality on Unity. See
  this patch:

  https://bazaar.launchpad.net/~ubuntu-
  
desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

  This bug is requesting that patch be dropped and the extra tracker
  components be allowed into main and installed by default in Unity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/176/+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 1666676] Re: Enable tracker by default for Unity too

2017-02-27 Thread Martin Pitt
So all of this tells me that tracker isn't a replacement for typeahead
search. They have two entirely different use cases:

 * Typeahead search only affects the currently displayed directory (or
should anyway -- you search through what you see, not through the
entirety of the file system). It is fast as it's only one readdir(), and
nautilus already did that as it's displaying at least the first portion
of the directory and there is no need to stat() the individual files. It
also needs to be instant and correct even when I just copied a large
directory from somewhere else or am looking at a remote sftp/cifs
directory, and work everywhere.

 * Tracker imposes a huge cost due to always indexing everything (even
if you never search for it). It's good for tasks like "where did I put
my files last week". However, it is necessarily only approximate, as it
has some delay (which can be quite large if you are on battery, or just
copied a large bunch of files), and not universal (non-XDG directories,
remote file systems), etc.

So I don't see how "enable tracker" can ever be a replacement for
typeahead search, and TBH I still don't buy that we have to penalize
each and every installation with the tracker overhead even though most
people don't do full-hard disk searches all the time (and many don't do
this at all). And if you do need a "search through my home dir", you
*still* need to do an actual search due to the latency/approximative
nature of indexing. It's not an acceptable answer to say "sorry, we
don't show the file you just downloaded as we didn't get to indexing it
yet".

I see tracker as a nice opt-in (!) feature for people who often do full
searches, so this might become a checkbox in the search box?

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

Title:
  Enable tracker by default for Unity too

Status in nautilus package in Ubuntu:
  New

Bug description:
  For Nautilus' built-in search to not be very slow, Nautilus needs to
  use tracker for search.

  This is especially important since it's being seriously proposed for
  Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted
  the removal of that feature by Nautilus years ago. (LP: #181)

  To not cripple Ubuntu GNOME, it was previously decided to let Nautilus
  build against tracker but not use that functionality on Unity. See
  this patch:

  https://bazaar.launchpad.net/~ubuntu-
  
desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

  This bug is requesting that patch be dropped and the extra tracker
  components be allowed into main and installed by default in Unity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/176/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-23 Thread Martin Pitt
Yes, there, see "man resolved.conf". But I'd recommend a separate file
to avoid changing the package-provided conffile:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf "[Resolve]\nDNSSEC=no\n" | sudo tee 
/etc/systemd/resolved.conf.d/no-dnssec.conf

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-19 Thread Martin Pitt
Note: We keep DNSSEC=allow-downgrade during development to collect
feedback, but switch it off for stable releases (we did so in yakkety
and should do so again in zesty). So if you have some trouble which is
DNSSEC related, it would be good to get a debug output of resolved while
it's failing to report/investigate it. But that should be unrelated to
the CNAME bug here.

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-12 Thread Martin Pitt
Fixed upstream:
https://github.com/systemd/systemd/commit/e8d23f92b50a97bb3

** Changed in: systemd (Ubuntu)
   Status: Triaged => Fix Committed

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+subscriptions

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


Re: [Desktop-packages] [Bug 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-21 Thread Martin Pitt
Till Kamppeter [2016-12-19 16:48 -]:
> Then edit the file /lib/systemd/system/cups.path adding a line
> "PartOf=cups.service" to the [Unit] section, so that the file looks like
> this:
> 
> --
> [Unit]
> Description=CUPS Scheduler
> PartOf=cups.service

I suppose that cups.path is only for booting, i. e. you want to start
cups.service on boot, not again on demand on a running system. Does it ever
happen that cups.service terminates by itself due to inactivity? If not, this
provides a good enough workaround for not stopping cups.path properly in the
maintainer scripts. If yes, this appproach doesn't work.

Note that you probably want to do the same for cups.socket, with the same
reasoning as above.

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
Ah, so you didn't have resolvconf installed (and therefore also not
ubuntu-minimal), that's a good data point, thank you! This should be
part of this bug -- NM should get along with this better.

Do you see the search domain in "systemd-resolve --status"?

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
What does "systemctl status resolvconf" say? is it not running for you?

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
** Tags added: resolved

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
> # Generated by NetworkManager
> nameserver 127.0.1.1

OK, that's definitively unexpected. It looks like NM is still using a
different plugin for managing /etc/resolv.conf and that thinks it's
using the dnsmasq plugin (127.0.1.1) while not actually starting
dnsmasq. That part is understood and what I retitled the bug to.

What is not clear is why your NM uses that configuration despite not
setting it in NetworkManager.conf.

joulu 06 19:05:04 Sabertooth NetworkManager[576]: 
[1481043904.5853] dns-mgr[0x55f3c8285000]: init: dns=systemd-resolved,
rc-manager=symlink, plugin=systemd-resolved

That actually looks expected. Maybe your /etc/resolv.conf is not a
symlink to ../run/resolvconf/resolv.conf but a plain file? If so, please
do

  sudo systemctl stop NetworkManager
  sudo rm /etc/resolv.conf
  sudo ln -s ../run/resolvconf/resolv.conf /etc/resolv.conf
  sudo systemctl start NetworkManager

This hopefully should fix things.

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: dns=dnsmasq does not work any more

2016-12-06 Thread Martin Pitt
OK, thanks. I'm afraid I need the NM log and /etc/resolv.conf with NM
1.4.2-2ubuntu4 without "dns=dnsmasq".

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: Network-manager 1.4.2-2ubuntu4 brakes network connection (Zesty)

2016-12-06 Thread Martin Pitt
> dns=dnsmasq

Ah -- please remove that from /etc/NetworkManager/NetworkManager.conf,
this is not currently working (this is known, this needs to be fixed in
a better way).

** Summary changed:

- Network-manager 1.4.2-2ubuntu4 brakes network connection (Zesty)
+ dns=dnsmasq does not work any more

** Changed in: network-manager (Ubuntu)
   Status: Incomplete => Triaged

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1647133] Re: Network-manager 1.4.2-2ubuntu4 brakes network connection (Zesty)

2016-12-05 Thread Martin Pitt
Can you please attach your /etc/NetworkManager/NetworkManager.conf ? NM
is not supposed to create /etc/resolv.conf any more, so I suppose
something else is going on. Can you please reproduce the failed state
and then do

  cat /etc/resolv.conf

and copy the output, and run

  journalctl -u NetworkManager.service -u systemd-resolved.service -b >
/tmp/nm.log

and attach /tmp/nm.log?

** Changed in: network-manager (Ubuntu)
   Status: New => Incomplete

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

Title:
  Network-manager 1.4.2-2ubuntu4 brakes network connection (Zesty)

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-04 Thread Martin Pitt
> In CUPS everything is OK and as intended.

No -- as above, the maintainer scripts need to stop cups.{socket,path}
first before stopping cups.service. Also, as it seems you can entirely
drop that .path unit as it's fairly useless -- we don't start cups on
demand, but it always starts on boot (in a default install). It would of
course be nice to fix that (as I suggested in the upstream bug).

> And there is also another bug in systemd: The *.path file as it comes
with CUPS should always start CUPS (if it is not already running) if
there is the keepalive file, not only if the keepalive file is newly
created.

It does -- that's precisely what happens here: The path unit restarts
cups after the maintainer scripts stop it, and that's the core of this
bug. So if anything, you want it to be less aggressive, not more :-)

> cups-browsed.service contains "After=cups.service avahi-
daemon.service" in its [Unit] section. Is this enough to make cups-
browsed being shut down before the shutdown of CUPS is done?

Yes, it is, the Before/After get inversed on stopping units.

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

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-04 Thread Martin Pitt
Till's log shows that cups.path triggers after cups got stopped:

Dec 02 10:59:15 till-x1carbon systemd[1]: cups.path: Got notified about unit 
deactivation.
Dec 02 10:59:15 till-x1carbon systemd[1]: cups.path: Changed running -> waiting
Dec 02 10:59:15 till-x1carbon systemd[1]: cups.socket: Changed running -> 
listening
[...]
Dec 02 10:59:19 till-x1carbon systemd[1]: cups.path: Got triggered.
Dec 02 10:59:19 till-x1carbon systemd[1]: cups.service: Trying to enqueue job 
cups.service/start/replace

and soon afterwards something stops it again:

Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Trying to enqueue job 
cups.service/stop/replace
Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Installed new job 
cups.service/stop as 6213
[...]
Dec 02 10:59:29 till-x1carbon systemd[1]: cups.service: Changed running -> 
stop-sigterm
Dec 02 10:59:29 till-x1carbon systemd[1]: Stopping CUPS Scheduler...

and then starts again:

Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Got triggered.
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Trying to enqueue job 
cups.service/start/replace

but cups shuts down again:

Dec 02 10:59:30 till-x1carbon systemd[1]: Child 9764 (cupsd) died (code=exited, 
status=0/SUCCESS
)
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Child 9764 belongs to 
cups.service
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Main process exited, 
code=exited, status=0/SUCCESS
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.service: Changed stop-sigterm -> 
dead
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Got notified about unit 
deactivation.
Dec 02 10:59:30 till-x1carbon systemd[1]: cups.path: Changed running -> waiting

and so on, and I suppose eventually it runs into the restart limit.

Unfortunately the description of all cups.* unit is identical ("CUPS
Scheduler" so on a non-debug log it is a bit hard to see which of the
three it is when it says "Stopped". But nowhere in Till's log I see that
cups.path itself gets stopped (and neither cups.service) -- this is
clearly missing for a reliable stopping.

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

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

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


Re: [Desktop-packages] [Bug 1638836] Re: resolv.conf for resolved stub server should have a comment how to see the actual servers

2016-12-04 Thread Martin Pitt
Hello Harry,

Harry [2016-12-03 15:02 -]:
> Please note, that in my setup, the network is lost immediately after
> rebooting with the new network-manager (1.4.2-2ubuntu4).

Thanks for filing bug 1647133, tracking that issue there.

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

Title:
  resolv.conf for resolved stub server should have a comment how to see
  the actual servers

Status in network-manager package in Ubuntu:
  Fix Released
Status in resolvconf package in Ubuntu:
  Fix Released

Bug description:
  resolv.conf currently just has

nameserver 127.0.0.53

  with resolved (its local stub resolver). We should have an extra
  comment on top of that that says

# systemd-resolved stub resolver; run "systemd-resolve --status" to
  see the actual name servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638836/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-04 Thread Martin Pitt
> Requires=cups.service in /lib/systemd/system/cups-browsed.service the
shutdown of CUPS should shutdown cups-browsed first.

No -- Requires/Wants start/stop other units, but they *do not imply
ordering*. If you need to order services against each other you must
additionally specify Before/After=.

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-02 Thread Martin Pitt
> Interestingly, "cups.service: Start request repeated too quickly."
appears on a successful run.

This would usually happen if you try things in a loop, (5 or more
restarts in 10s); run "systemctl reset-failed " in between to
reset the counter.

The journal shows an obvious loop, and at that point the log doesn't
tell much because you are running into the restart limit.

And could you extend your reproducer to run

  journalctl --quiet --lines=0 --show-cursor

and the beginning, and at the end

  journalctl -c "s=... (cursor obtained from above)"

so that we only see the bits that happen during one run, not the whole
noise around it?

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-02 Thread Martin Pitt
I tried this on zesty, and in comment #20 Robie tried on xenial, and we
both get:

> Warning: Stopping cups.service, but it can still be activated by:
>  cups.path

(I additionally get cups.socket there too). Thus:

> However, in the real world failure case, cups.path is stopped before
> cups.service, so I don't think that can be it.

This actually is not the case in zesty (haven't checked yakkety) any
more -- cups-daemon.prerm does not stop cups.path any more. Thus I
wonder what happens in xenial, as there clearly is a stop.

I cannot yet reproduce this in a clean xenial VM with either robie's
recipe from comment #18 or a repeated "apt-get install --reinstall cups-
daemon". I also tried with tight races like

  touch /var/cache/cups/org.cups.cupsd; systemctl stop cups.service

(and also swapping around the commands).

For someone who can reproduce this, can you please do the following:

  sudo systemd-analyze set-log-level debug
  [... steps to reproduce the bug ...]
  sudo systemd-analyze set-log-level info
  sudo journalctl -b > /tmp/journal.txt

and attach /tmp/journal.txt here?

** Changed in: cups (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Incomplete
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1624729] Re: package fontconfig 2.11.94-0ubuntu1.1 failed to install/upgrade: triggers looping, abandoned

2016-12-02 Thread Martin Pitt
*** This bug is a duplicate of bug 1573322 ***
https://bugs.launchpad.net/bugs/1573322

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

** This bug has been marked a duplicate of bug 1573322
   package systemd 229-4ubuntu4 failed to install/upgrade: triggers looping, 
abandoned

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

Title:
  package fontconfig 2.11.94-0ubuntu1.1 failed to install/upgrade:
  triggers looping, abandoned

Status in ca-certificates package in Ubuntu:
  New
Status in doc-base package in Ubuntu:
  New
Status in dpkg package in Ubuntu:
  New
Status in fontconfig package in Ubuntu:
  New
Status in glib2.0 package in Ubuntu:
  New
Status in gnome-menus package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I installer in ubuntu 16.04 Cinnamon - sudo apt-get install
  cinnamon. sudo apt-get install cinnamon-core

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: fontconfig 2.11.94-0ubuntu1.1
  ProcVersionSignature: Ubuntu 4.4.0-36.55-generic 4.4.16
  Uname: Linux 4.4.0-36-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Tue Sep 13 14:52:16 2016
  ErrorMessage: triggers looping, abandoned
  InstallationDate: Installed on 2016-09-11 (6 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.12~ubuntu16.04.1
  SourcePackage: fontconfig
  Title: package fontconfig 2.11.94-0ubuntu1.1 failed to install/upgrade: 
triggers looping, abandoned
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1624729/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-02 Thread Martin Pitt
FTR:
-r 1 root root   0 Feb 11  2015 /var/cache/cups/org.cups.cupsd

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-02 Thread Martin Pitt
I didn't reproduce this yet, answering Till's questions first.

> Does systemd care about keepalive files?

No, there is no such concept. You can certainly build such a thing using
path units and others, but no Linux init system kills processes willy-
nilly from the outside (except on shutdown, of course) -- daemons either
have a built-in timeout and quit themselves, or have to be stopped
explicitly.

> The CUPS upstream *.path makes cupsd being triggered by creating the
file, but only if the file is not there already. What is this good for?

I have no idea. I haven't printed anything in years (I don't even have a
printer), and that file exists, thus that .path unit always gets
activated and starts cupsd.service even though I have no need for it.
Does that ever actually get cleaned up?

Also, such "keepalive" stamps should *always* be in /run -- it makes no
sense to put them on the file system in /var where they are persistent
across reboot.

> Does this *.path also take down cupsd if one removes the keepalive
file.

No, it doesn't (at least not in the way that path unit is written). This
also doesn't make much sense, TBH -- you can never know from the outside
if a daemon is still required to run, so you always need the daemon
itself to make that decision. Instead of creating/removing keepalive
files it could just stop itself, which is structurally a lot simpler.

> And why does shutdown of CUPS fail after removing the keepalive file
(with "Job for cups.service canceled.")?

It sounds like cups.service gets stopped, but around the same time
something tries to start it again, possibly via either cups.path or
cups.socket. In generally, if you need to prevent a service from
restarting, you need to first stop all "auto-activating" units (path,
socket, timer) as well, and before stopping the .service.

> what in the prerm script of the CUPS Debian package deletes the
keepalive file?

The maintainer scripts don't, and I'm not at all convinced that anything
is actually removing it (see above). Maybe cupsd is supposed to clean it
on shutdown, but this doesn't happen sometimes?

So ISTM that the current cups.path serves no real purpose and apparently
just gets in the way. I think what *would* make sense is to have a path
unit that starts cups at boot if there are pending print jobs, e. g.
something like "DirectoryNotEmpty=/var/spool/cups".

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

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

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

[Desktop-packages] [Bug 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-12-02 Thread Martin Pitt
Sorry, wrong commit:
https://cgit.freedesktop.org/udisks/commit/?id=f641062

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-12-02 Thread Martin Pitt
Silly me! Should be fixed with
https://cgit.freedesktop.org/udisks/commit/?id=054d9c4201f

** Changed in: udisks2 (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-12-02 Thread Martin Pitt
http://autopkgtest.ubuntu.com/packages/udisks2/zesty/i386 now has two
failures with core dumps. I extracted the stack trace from the topmost
one.

This one is interesting:

f = Frame 0xb662ccec, for file src/tests/test_polkitd.py, line
184, in spawn (allowed_actions=['org.freedesktop.udisks2.modify-device-
system', 'org.freedesktop.udisks2.modify-device'], on_bus=None,
pid=18994, bus=, _signal_sender_matches={},
_dbus_Connection_initialized=1,
_bus_names=) at remote 0xb634683c>, timeout=49)

that suggests it hits this code path in src/tests/test_polkitd.py:

for timeout in range(50):
try:
p = dbus.Interface(bus.get_object('org.freedesktop.DBus', 
'/org/freedesktop/DBus'),
   
'org.freedesktop.DBus').GetConnectionUnixProcessID(
   
bus.get_name_owner('org.freedesktop.PolicyKit1'))
except dbus.exceptions.DBusException:
continue
if p == pid:
break
time.sleep(0.1)
else:
sys.stderr.write('test polkitd failed to start up\n')
os.abort()

i. e. it timed out waiting for the mocked polkit to appear on the bus.

** Attachment added: "stack trace"
   
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+attachment/4786287/+files/stacktrace.txt

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1645631] Re: Sending files fails because obex not loaded

2016-11-29 Thread Martin Pitt
** No longer affects: systemd (Ubuntu)

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

Title:
  Sending files fails because obex not loaded

Status in bluez package in Ubuntu:
  New
Status in gnome-bluetooth package in Ubuntu:
  New

Bug description:
  If I run bluetooth-sendto from command line and try to send the file,
  it quits after selecting the target device with following command line
  output:

  "Acquiring proxy failed: Error calling StartServiceByName for
  org.bluez.obex: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit
  dbus-org.bluez.obex.service not found."

  After I run "systemctl --user start obex", it proceeds to send the
  file. Even then it for some reason gets stuck, but I do not know what
  causes it and it is probably a different problem.

  This system is upgraded from xenial.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: gnome-bluetooth 3.20.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
  Uname: Linux 4.8.0-27-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  Date: Tue Nov 29 11:04:11 2016
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2016-09-12 (77 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  ProcEnviron:
   LANGUAGE=fi
   TERM=xterm
   PATH=(custom, no user)
   LANG=C
   SHELL=/bin/bash
  SourcePackage: gnome-bluetooth
  UpgradeStatus: Upgraded to yakkety on 2016-11-01 (27 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1645631/+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 1638836] Re: resolv.conf for resolved stub server should have a comment how to see the actual servers

2016-11-28 Thread Martin Pitt
https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-
resolver has the two outstanding issues to switch NM over to resolved
too. These are unblocked now: the new resolved DNS plugin is in upstream
master since around September, and NM 1.4 landed in zesty-proposed
yesterday. Let's land that first, then backport the DNS plugin and
switch it over, then we'll consistently use resolved everywhere and that
comment will be much easier to write.

This is also the reason why I didn't do this comment change yet, I think
it's better to wait for the above.

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

Title:
  resolv.conf for resolved stub server should have a comment how to see
  the actual servers

Status in network-manager package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  In Progress

Bug description:
  resolv.conf currently just has

nameserver 127.0.0.53

  with resolved (its local stub resolver). We should have an extra
  comment on top of that that says

# systemd-resolved stub resolver; run "systemd-resolve --status" to
  see the actual name servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638836/+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 1615044] Re: "unmanaged-devices=" lists misbehaves with "except:"

2016-11-28 Thread Martin Pitt
** Changed in: network-manager (Ubuntu)
 Assignee: Martin Pitt (pitti) => (unassigned)

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

Title:
  "unmanaged-devices=" lists misbehaves with "except:"

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  In yakkety we now ship /usr/lib/NetworkManager/conf.d/10-globally-
  managed-devices.conf with

 unmanaged-devices=*,except:type:wifi,except:type:wwan

  but this now breaks conf.d snippets which want to blacklist an
  additional interface, such as /run/NetworkManager/conf.d/test-
  blacklist.conf that does

unmanaged-devices+=wlan0

  resulting in

  # NetworkManager --print-config
  [...]
  unmanaged-devices=*,except:type:wifi,except:type:wwan,wlan0

  Intuitively this should ignore wlan0 and all other non-wifi/wwan
  devices, but with that it *does* manage wlan0.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: network-manager 1.2.2-0ubuntu8
  ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
  Uname: Linux 4.4.0-34-generic x86_64
  ApportVersion: 2.20.3-0ubuntu7
  Architecture: amd64
  CurrentDesktop: i3
  Date: Fri Aug 19 18:23:02 2016
  EcryptfsInUse: Yes
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
   
   source-directory interfaces.d
  NetworkManager.conf:
   [main]
   plugins=ifupdown,keyfile,ofono
   
   [ifupdown]
   managed=false
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
   WimaxEnabled=true
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.2.2connected  started  full  enabled enabled  
enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1615044/+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 1398859] Re: unmounting NTFS causes mount.ntfs process to get stuck in eternal kernel deep sleep

2016-11-25 Thread Martin Pitt
> Curiously I do not see this when running the tests on my laptop

And of course in the minute I write this it does happen again (I ran the
test maybe 20 times today, and only just now it happened):

[11359.569157] INFO: task systemd-udevd:341 blocked for more than 120 seconds.
[11359.569163]   Not tainted 4.8.0-29-generic 
#31~lp1626436ProposedWithTwoPatches
[11359.569165] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[11359.569167] systemd-udevd   D a31788e77ba8 0   341  1 0x0100
[11359.569173]  a31788e77ba8 00ff84c71a68 a3149967 
a31788e82ac0
[11359.569177]  88e77db0 a31788e78000 a317893bc070 
a317893bc088
[11359.569179]  a31788e77be0 a3149cf771c0 a31788e77bc0 
85296905
[11359.569182] Call Trace:
[11359.569190]  [] schedule+0x35/0x80
[11359.569193]  [] rwsem_down_read_failed+0x103/0x160
[11359.569197]  [] call_rwsem_down_read_failed+0x18/0x30
[11359.569200]  [] down_read+0x20/0x40
[11359.569202]  [] get_super.part.7+0x95/0xd0
[11359.569204]  [] get_super+0x26/0x30
[11359.569208]  [] fsync_bdev+0x18/0x60
[11359.569211]  [] invalidate_partition+0x24/0x50
[11359.569213]  [] rescan_partitions+0x53/0x2b0
[11359.569216]  [] ? security_capable+0x48/0x60
[11359.569218]  [] __blkdev_reread_part+0x65/0x70
[11359.569220]  [] blkdev_reread_part+0x23/0x40
[11359.569222]  [] blkdev_ioctl+0x425/0x910
[11359.569225]  [] ? __seccomp_filter+0x67/0x260
[11359.569228]  [] block_ioctl+0x3d/0x50
[11359.569231]  [] do_vfs_ioctl+0xa3/0x610
[11359.569233]  [] ? __secure_computing+0x43/0xe0
[11359.569236]  [] ? syscall_trace_enter+0xce/0x2f0
[11359.569239]  [] SyS_ioctl+0x79/0x90
[11359.569241]  [] do_syscall_64+0x5e/0xc0
[11359.569244]  [] entry_SYSCALL64_slow_path+0x25/0x25
[11359.569320] INFO: task mount.ntfs:15670 blocked for more than 120 seconds.
[11359.569323]   Not tainted 4.8.0-29-generic 
#31~lp1626436ProposedWithTwoPatches
[11359.569324] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[11359.569325] mount.ntfs  D a314d0d1bd68 0 15670   5268 0x
[11359.569329]  a314d0d1bd68 00010003 a3178bef9c80 
a3149967
[11359.569332]  3d862ecf a314d0d1c000 a3149cf771dc 
a3149967
[11359.569334]   a3149cf771e0 a314d0d1bd80 
85296905
[11359.569337] Call Trace:
[11359.569340]  [] schedule+0x35/0x80
[11359.569342]  [] schedule_preempt_disabled+0xe/0x10
[11359.569344]  [] __mutex_lock_slowpath+0xb9/0x130
[11359.569347]  [] mutex_lock+0x1f/0x30
[11359.569350]  [] blkdev_put+0x20/0x110
[11359.569352]  [] blkdev_close+0x34/0x70
[11359.569354]  [] __fput+0xe7/0x230
[11359.569356]  [] fput+0xe/0x10
[11359.569358]  [] task_work_run+0x80/0xa0
[11359.569361]  [] exit_to_usermode_loop+0xc2/0xd0
[11359.569363]  [] syscall_return_slowpath+0x4e/0x60
[11359.569366]  [] entry_SYSCALL_64_fastpath+0xa6/0xa8


root 15670  0.0  0.0  16040   460 ?Ds   10:41   0:00 
/sbin/mount.ntfs /dev/sdb /run/media/root/553BDB6430706196 -o 
rw,nodev,nosuid,uid=0,gid=0,uhelper=udisks2


(uninterruptible kernel deep sleep, 'D' state).

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

Title:
  unmounting NTFS causes mount.ntfs process to get stuck in eternal
  kernel deep sleep

Status in linux package in Ubuntu:
  Confirmed
Status in udisks2 package in Ubuntu:
  Fix Released

Bug description:
  Since Mid-November the udisks2 test (https://jenkins.qa.ubuntu.com/job
  /vivid-adt-udisks2/? shows it happened between Nov 13 and 19) exhibits
  a regression with NTFS: Unmounting causes the ntfs-3g process to go
  into kernel deep sleep and umount hangs forever.

  This can be reproduced with

sudo apt install ntfs-3g
sudo modprobe scsi_debug
# check dmesg which drive this created; e. g. /dev/sda
sudo mkntfs -F /dev/sda
sudo mount /dev/sda /mnt

  Now you have a process which is happy:
  root 12821  0.0  0.0  15272  1948 ?Ss   15:49   0:00 
/sbin/mount.ntfs /dev/sda /mnt -o rw

  You can work with /mnt, edit files, etc. But now unmount:

sudo umount /mnt

  This never returns, and  the process goes into uninterruptible kernel
  sleep ("D"):

  root 12928  0.0  0.0  15272  1948 ?Ds   15:55   0:00
  /sbin/mount.ntfs /dev/sda /mnt -o rw

  The strace for the umount until the hang is

  ubuntu@autopkgtest:~$ sudo strace -vvtts1024 -p 12928
  Process 12928 attached
  15:56:17.938299 read(4, 
"0\0\0\0\2\0\0\0\2\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0",
 135168) = 48
  15:56:22.338931 read(4, 
"(\0\0\0&\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
 135168) = 40
  15:56:22.339637 sendto(5, "<29>Dec  3 15:56:22 ntfs-3g[12928]: Unmounting 
/dev/sda ()\n", 59, MSG_NOSIGNAL, NULL, 0) = 59
  15:56:22.340509 

[Desktop-packages] [Bug 1398859] Re: unmounting NTFS causes mount.ntfs process to get stuck in eternal kernel deep sleep

2016-11-25 Thread Martin Pitt
I also see this with exfat, so it rather seems to be related to fuse (as
both ntfs-3g and exfat use fuse). Curiously I do not see this when
running the tests on my laptop or on the Scalingstack cloud infra, just
when I run them in QEMU.

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

Title:
  unmounting NTFS causes mount.ntfs process to get stuck in eternal
  kernel deep sleep

Status in linux package in Ubuntu:
  Confirmed
Status in udisks2 package in Ubuntu:
  Fix Released

Bug description:
  Since Mid-November the udisks2 test (https://jenkins.qa.ubuntu.com/job
  /vivid-adt-udisks2/? shows it happened between Nov 13 and 19) exhibits
  a regression with NTFS: Unmounting causes the ntfs-3g process to go
  into kernel deep sleep and umount hangs forever.

  This can be reproduced with

sudo apt install ntfs-3g
sudo modprobe scsi_debug
# check dmesg which drive this created; e. g. /dev/sda
sudo mkntfs -F /dev/sda
sudo mount /dev/sda /mnt

  Now you have a process which is happy:
  root 12821  0.0  0.0  15272  1948 ?Ss   15:49   0:00 
/sbin/mount.ntfs /dev/sda /mnt -o rw

  You can work with /mnt, edit files, etc. But now unmount:

sudo umount /mnt

  This never returns, and  the process goes into uninterruptible kernel
  sleep ("D"):

  root 12928  0.0  0.0  15272  1948 ?Ds   15:55   0:00
  /sbin/mount.ntfs /dev/sda /mnt -o rw

  The strace for the umount until the hang is

  ubuntu@autopkgtest:~$ sudo strace -vvtts1024 -p 12928
  Process 12928 attached
  15:56:17.938299 read(4, 
"0\0\0\0\2\0\0\0\2\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0",
 135168) = 48
  15:56:22.338931 read(4, 
"(\0\0\0&\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
 135168) = 40
  15:56:22.339637 sendto(5, "<29>Dec  3 15:56:22 ntfs-3g[12928]: Unmounting 
/dev/sda ()\n", 59, MSG_NOSIGNAL, NULL, 0) = 59
  15:56:22.340509 fsync(3)= 0
  15:56:22.341188 fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, 
len=0}) = 0
  15:56:22.341759 close(3

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: ntfs-3g 1:2013.1.13AR.1-2ubuntu3
  ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
  Uname: Linux 3.16.0-25-generic x86_64
  ApportVersion: 2.15-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Dec  3 15:48:12 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-11-20 (13 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20141119)
  SourcePackage: ntfs-3g
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398859/+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 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-11-25 Thread Martin Pitt
I ran it five times on the production infrastructure and it does not
reproduce there either, so a nasty heisenbug :-(

I instead changed the test to archive a core dump if the test crashes,
so that this can be debugged post-mortem:
https://anonscm.debian.org/cgit/pkg-
utopia/udisks2.git/commit/?id=5a7601a8

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  In Progress

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-11-24 Thread Martin Pitt
This does not reproduce locally or with autopkgtest-virt-qemu.

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  In Progress

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1585382] Re: test_internal_fs_allowed crashes with SIGABRT

2016-11-24 Thread Martin Pitt
** Changed in: udisks2 (Ubuntu)
   Status: Triaged => In Progress

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

Title:
  test_internal_fs_allowed crashes with SIGABRT

Status in udisks2 package in Ubuntu:
  In Progress

Bug description:
  udisks2's tests now often fail with

  test_internal_fs_allowed (__main__.Polkit)
  Create FS on internal drive (allowed) ... Aborted (core dumped)

  See http://autopkgtest.ubuntu.com/packages/u/udisks2/yakkety/amd64/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1585382/+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 1595023] Re: Need to determine if snap apps require terminal or not

2016-11-23 Thread Martin Pitt
Hello Robert, or anyone else affected,

Accepted gnome-software into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/gnome-
software/3.20.1+git20161013.0.d77d6cf-0ubuntu2~xenial1 in a few hours,
and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags added: verification-needed

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

Title:
  Need to determine if snap apps require terminal or not

Status in gnome-software package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Confirmed
Status in gnome-software source package in Xenial:
  Fix Committed
Status in snapd source package in Xenial:
  New
Status in gnome-software source package in Yakkety:
  Fix Released
Status in snapd source package in Yakkety:
  Confirmed

Bug description:
  snapd returns a list of apps a snap contains, i.e:

  "apps": [{"name": "moon-buggy"}]

  However, we can't tell if this is a terminal app (like moon buggy) or
  a graphical app (like Ubuntu calculator).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1595023/+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 1603610] Re: Snaps have no screenshots

2016-11-23 Thread Martin Pitt
Hello Robert, or anyone else affected,

Accepted gnome-software into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/gnome-
software/3.20.1+git20161013.0.d77d6cf-0ubuntu2~xenial1 in a few hours,
and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags added: verification-needed

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

Title:
  Snaps have no screenshots

Status in snapd-glib:
  Fix Released
Status in Snappy:
  Fix Committed
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 Yakkety:
  Fix Released

Bug description:
  Snaps have no screenshots

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd-glib/+bug/1603610/+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 1616943] Re: Can't auth against U1 in g-s

2016-11-23 Thread Martin Pitt
Hello Will, or anyone else affected,

Accepted gnome-software into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/gnome-
software/3.20.1+git20161013.0.d77d6cf-0ubuntu2~xenial1 in a few hours,
and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags removed: verification-failed

** Tags added: verification-needed

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

Title:
  Can't auth against U1 in g-s

Status in gnome-software package in Ubuntu:
  Fix Released
Status in snapd-glib package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  Fix Committed
Status in snapd-glib source package in Xenial:
  Fix Committed
Status in gnome-software source package in Yakkety:
  Fix Committed

Bug description:
  [Impact]
  Authentication using Ubuntu One credentials to install/remove snaps always  
fails. This is due to a behaviour change in snapd (no longer accepts login 
requests from non-root users). Existing credentials continue to work.

  [Test Case]
  1. Delete any existing credentials by deleting passwords marked 
"com.ubuntu.UbuntuOne.GnomeSoftware" using Seahorse.
  2. Start GNOME Software
  3. Search for a snap (e.g. "moon-buggy")
  4. Install Snap
  5. Enter Ubuntu One credentials when prompted

  Observed result:
  Dialog says "Incorrect email or password".

  Expected result:
  Authentication completes and the snap is installed.

  [Regression Potential]
  The solution is to use a new D-Bus service (snapd-login-service) and new 
library (snapd-glib) to get the Macaroon from snapd. This has some risk of 
introducing new bugs. The change is minimised (other snapd code paths 
unchanged) and the alternative is login to be impossible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1616943/+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 1629456] Re: Summary isn't shown for snaps

2016-11-23 Thread Martin Pitt
Hello Kyle, or anyone else affected,

Accepted gnome-software into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/gnome-
software/3.20.1+git20161013.0.d77d6cf-0ubuntu2~xenial1 in a few hours,
and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags added: verification-needed

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

Title:
  Summary isn't shown for snaps

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 Yakkety:
  Fix Released

Bug description:
  Ubuntu packages are shown in gnome-software with the name, followed by
  the summary, followed by install buttons, and finally followed by a
  more detailed description. In contrast, snaps are shown with the name,
  detailed summary, followed by install buttons. The summary isn't
  present, and the experience isn't consistent with normal packages.

  I suggest we maintain consistency: show the snap name, followed by the
  snap summary, followed by install buttons, and finally followed by the
  more detailed description.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1629456/+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 1460602] Re: Erasing disk failed: Error wiping newly created partition

2016-11-23 Thread Martin Pitt
https://cgit.freedesktop.org/udisks/commit/?id=e168e59f
https://cgit.freedesktop.org/udisks/commit/?id=554daa4b

I tried this with an USB stick; I do get the wipefs failure pretty
consistently, and with this creating the partition and FS seems to work
reliably. I think we ought to SRU this into xenial as well, after giving
it some field testing.

** Changed in: udisks2 (Ubuntu)
   Status: In Progress => Fix Committed

** Also affects: udisks2 (Ubuntu Xenial)
   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/1460602

Title:
  Erasing disk failed: Error wiping newly created partition

Status in udisks:
  Unknown
Status in udisks2 package in Ubuntu:
  Fix Committed
Status in udisks2 source package in Xenial:
  New
Status in udisks2 package in Debian:
  Confirmed

Bug description:
  I tried to erase a normal 8GB USB stick on up to date Ubuntu 15.04.
  This dialog appeared:

  org.freedesktop.DBus.Python.GLib.Error: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/dbus/service.py", line 707, in 
_message_cb
  retval = candidate_method(self, *args, **keywords)
File "/usr/share/usb-creator/usb-creator-helper", line 287, in Format
  partition = table.call_create_partition_sync(0, size, '0x0c', '', 
no_options, None)
  GLib.Error: udisks-error-quark: 
GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error wiping newly created 
partition /dev/sdc1: Command-line `wipefs -a "/dev/sdc1"' exited with non-zero 
exit status 1: wipefs: error: /dev/sdc1: probing initialization failed: No such 
file or directory
   (0)

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: usb-creator-gtk 0.2.67ubuntu0.1
  ProcVersionSignature: Ubuntu 3.19.0-18.18-generic 3.19.6
  Uname: Linux 3.19.0-18-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Jun  1 13:20:30 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-02-12 (108 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  SourcePackage: usb-creator
  UDisksDump: Error: [Errno 2] No such file or directory: 'udisks'
  UpgradeStatus: Upgraded to vivid on 2015-05-12 (19 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/udisks/+bug/1460602/+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 1460602] Re: Erasing disk failed: Error wiping newly created partition

2016-11-23 Thread Martin Pitt
This isn't sufficient. I've still seen this happen in yakkety even.
Reopening, in the upstream bug there is a proposal for a better solution
which already landed in storaged.

** Changed in: udisks2 (Ubuntu)
   Status: Fix Released => In Progress

** Changed in: udisks2 (Ubuntu)
 Assignee: (unassigned) => Martin Pitt (pitti)

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

Title:
  Erasing disk failed: Error wiping newly created partition

Status in udisks:
  Unknown
Status in udisks2 package in Ubuntu:
  In Progress
Status in udisks2 package in Debian:
  Confirmed

Bug description:
  I tried to erase a normal 8GB USB stick on up to date Ubuntu 15.04.
  This dialog appeared:

  org.freedesktop.DBus.Python.GLib.Error: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/dbus/service.py", line 707, in 
_message_cb
  retval = candidate_method(self, *args, **keywords)
File "/usr/share/usb-creator/usb-creator-helper", line 287, in Format
  partition = table.call_create_partition_sync(0, size, '0x0c', '', 
no_options, None)
  GLib.Error: udisks-error-quark: 
GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error wiping newly created 
partition /dev/sdc1: Command-line `wipefs -a "/dev/sdc1"' exited with non-zero 
exit status 1: wipefs: error: /dev/sdc1: probing initialization failed: No such 
file or directory
   (0)

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: usb-creator-gtk 0.2.67ubuntu0.1
  ProcVersionSignature: Ubuntu 3.19.0-18.18-generic 3.19.6
  Uname: Linux 3.19.0-18-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Jun  1 13:20:30 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-02-12 (108 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  SourcePackage: usb-creator
  UDisksDump: Error: [Errno 2] No such file or directory: 'udisks'
  UpgradeStatus: Upgraded to vivid on 2015-05-12 (19 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/udisks/+bug/1460602/+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 1616943] Re: Can't auth against U1 in g-s

2016-11-23 Thread Martin Pitt
snapd-glib accepted into xenial. Please upload the corresponding gnome-
software SRU.

** Changed in: snapd-glib (Ubuntu Xenial)
   Status: Triaged => Fix Committed

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

Title:
  Can't auth against U1 in g-s

Status in gnome-software package in Ubuntu:
  Fix Released
Status in snapd-glib package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  Fix Committed
Status in snapd-glib source package in Xenial:
  Fix Committed
Status in gnome-software source package in Yakkety:
  Fix Committed

Bug description:
  [Impact]
  Authentication using Ubuntu One credentials to install/remove snaps always  
fails. This is due to a behaviour change in snapd (no longer accepts login 
requests from non-root users). Existing credentials continue to work.

  [Test Case]
  1. Delete any existing credentials by deleting passwords marked 
"com.ubuntu.UbuntuOne.GnomeSoftware" using Seahorse.
  2. Start GNOME Software
  3. Search for a snap (e.g. "moon-buggy")
  4. Install Snap
  5. Enter Ubuntu One credentials when prompted

  Observed result:
  Dialog says "Incorrect email or password".

  Expected result:
  Authentication completes and the snap is installed.

  [Regression Potential]
  The solution is to use a new D-Bus service (snapd-login-service) and new 
library (snapd-glib) to get the Macaroon from snapd. This has some risk of 
introducing new bugs. The change is minimised (other snapd code paths 
unchanged) and the alternative is login to be impossible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1616943/+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 1637758] Re: lightdm greeter session not properly shut down at login

2016-11-22 Thread Martin Pitt
** Changed in: lightdm (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  lightdm greeter session not properly shut down at login

Status in lightdm package in Ubuntu:
  Fix Committed

Bug description:
  I am using lightdm with 2 seats. After 2409 revision randomly one of
  two seats does not work correctly.

  xsettings plugin from unity-settings-daemon or gnome-settings-deamon
  fails to start because there is already _XSESSION_S* manager running.

  After revision 2409 in system monitor I see that there is still
  running unity-settings-daemon started by lightdm. Reverting this
  revision fixes my problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1637758/+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 1574324] Re: pulseaudio crashes when connecting to bluetooth headphones (due to ubuntu changes?)

2016-11-21 Thread Martin Pitt
** Changed in: pulseaudio (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  pulseaudio crashes when connecting to bluetooth headphones (due to
  ubuntu changes?)

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Yakkety:
  Fix Released

Bug description:
  Impact:

  A patch we carry for Ubuntu touch introduced a change that originally
  was required to make sure PulseAudio did not crash. This patch was
  ported to PulseAudio 8 in Xenial, but the patch author's bluetooth
  hardware that was to hand at the time worked so was assumed to be ok.
  However, the opposite is now happening, i.e PulseAudio is crashing
  with a subset of Bluetooth hardware.

  Regression potential:

  Very low to none. As can be read in this report, much debugging and
  testing has been done to find the problem, and the eventual fix.
  Moreover the change is the removal of a patch hunk that removed a line
  of code originally present in PulseAudio.

  Test case:

  NOTE that this test case applies to bluetooth hardware that is
  identified as not working in this bug report.

  1. Install, or upgrade to Xenial or yakkety.
  2. Pair your bluetooth device in the bluetooth settings in the relevant 
settings application for your desktop environment.
  3. Once paired, you will notice that sound stops working, as pulseaudio has 
thrown an assertion error.
  4. You do not have to remove your audio device from the paired device list, 
but it may be easier to do so for the next part of the testing.
  5. Update to the version of PulseAudio in xenial-proposed which is 
1:8.0-0ubuntu3.1, or in yakkety-proposed, which is 1:9.0-2ubuntu2.1.
  6. Re-pair your device. Audio should continue to work, and you should be able 
to switch to your bluetooth device and use it.

  
  Original bug report:

  When I attempt to connect my Jaybird Bluebuds X to Ubuntu 16.04
  pulseaudio crashes, this does *NOT* happen with a Jambox which leads
  me to believe it's an intermittent problem with some hardware. This
  did not happen on Ubuntu 15.10 (which was an upgrade of 15.04).

  Ubuntu Release:

  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  Pulseaudio Version:

  pulseaudio:
    Installed: 1:8.0-0ubuntu3
    Candidate: 1:8.0-0ubuntu3
    Version table:
   *** 1:8.0-0ubuntu3 500
  500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  Device info:

  [bluetooth]# info 44:5E:F3:B4:07:29
  Device 44:5E:F3:B4:07:29
   Name: BlueBuds X
   Alias: BlueBuds X
   Class: 0x240404
   Icon: audio-card
   Paired: yes
   Trusted: yes
   Blocked: no
   Connected: no
   LegacyPairing: no
   UUID: Headset   (1108--1000-8000-00805f9b34fb)
   UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
   UUID: Handsfree (111e--1000-8000-00805f9b34fb)
   UUID: Unknown   (80ff--1000-8000-00805f9b34fb)

  I have also attached a debug dump of Pulseaudio when attempting to
  connect to the headphones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324/+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 1573296] Update Released

2016-11-21 Thread Martin Pitt
The verification of the Stable Release Update for pulseaudio has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  obsolete conffiles not cleaned up on upgrade

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

Bug description:
  Impact:

  When upgrading to xenial from earlier releases, some files are left on
  the user's system. They are not used, but may otherwise be mistaken
  for being used by the user if they are attempting to fix a problem.

  Regression potential:

  Low to none, as the relevant files are not used, and are being removed
  when the updated version of Pulseaudio is installed. These files are
  already removed in yakkety and later.

  Test case:

  When updating from trusty to xenial, one will note the presence of the
  below listed files on the system. Updating from pulseaudio in xenial
  or pulseaudio in trusty to what is in xenial-proposed shoudl delete
  the listed files. The /etc/init.d/pulseaudio script should also be
  unregistered.

  
  Original bug report:

  The following files are marked obsolete after the upgrade to 16.04:

   /etc/init/pulseaudio.conf 6244f8d452b29be7d17219b2db34138f obsolete
   /etc/init.d/pulseaudio df2873ee4f4673d53e3562a0de6e8aa0 obsolete
   /etc/default/pulseaudio 777f75f5521eab11c647da5c55544b1b obsolete
   /etc/bash_completion.d/pulseaudio df1f94a6b961900162bd18532c3c4c22 obsolete

  
  Those files should be cleaned up and the sysv init script properly 
deregistered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1573296/+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 1574324] Re: pulseaudio crashes when connecting to bluetooth headphones (due to ubuntu changes?)

2016-11-21 Thread Martin Pitt
Comment #123 provided verification in yakkety.

** Tags removed: verification-done-xenial verification-needed
** Tags added: verification-done

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

Title:
  pulseaudio crashes when connecting to bluetooth headphones (due to
  ubuntu changes?)

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Yakkety:
  Fix Released

Bug description:
  Impact:

  A patch we carry for Ubuntu touch introduced a change that originally
  was required to make sure PulseAudio did not crash. This patch was
  ported to PulseAudio 8 in Xenial, but the patch author's bluetooth
  hardware that was to hand at the time worked so was assumed to be ok.
  However, the opposite is now happening, i.e PulseAudio is crashing
  with a subset of Bluetooth hardware.

  Regression potential:

  Very low to none. As can be read in this report, much debugging and
  testing has been done to find the problem, and the eventual fix.
  Moreover the change is the removal of a patch hunk that removed a line
  of code originally present in PulseAudio.

  Test case:

  NOTE that this test case applies to bluetooth hardware that is
  identified as not working in this bug report.

  1. Install, or upgrade to Xenial or yakkety.
  2. Pair your bluetooth device in the bluetooth settings in the relevant 
settings application for your desktop environment.
  3. Once paired, you will notice that sound stops working, as pulseaudio has 
thrown an assertion error.
  4. You do not have to remove your audio device from the paired device list, 
but it may be easier to do so for the next part of the testing.
  5. Update to the version of PulseAudio in xenial-proposed which is 
1:8.0-0ubuntu3.1, or in yakkety-proposed, which is 1:9.0-2ubuntu2.1.
  6. Re-pair your device. Audio should continue to work, and you should be able 
to switch to your bluetooth device and use it.

  
  Original bug report:

  When I attempt to connect my Jaybird Bluebuds X to Ubuntu 16.04
  pulseaudio crashes, this does *NOT* happen with a Jambox which leads
  me to believe it's an intermittent problem with some hardware. This
  did not happen on Ubuntu 15.10 (which was an upgrade of 15.04).

  Ubuntu Release:

  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  Pulseaudio Version:

  pulseaudio:
    Installed: 1:8.0-0ubuntu3
    Candidate: 1:8.0-0ubuntu3
    Version table:
   *** 1:8.0-0ubuntu3 500
  500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  Device info:

  [bluetooth]# info 44:5E:F3:B4:07:29
  Device 44:5E:F3:B4:07:29
   Name: BlueBuds X
   Alias: BlueBuds X
   Class: 0x240404
   Icon: audio-card
   Paired: yes
   Trusted: yes
   Blocked: no
   Connected: no
   LegacyPairing: no
   UUID: Headset   (1108--1000-8000-00805f9b34fb)
   UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
   UUID: Handsfree (111e--1000-8000-00805f9b34fb)
   UUID: Unknown   (80ff--1000-8000-00805f9b34fb)

  I have also attached a debug dump of Pulseaudio when attempting to
  connect to the headphones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324/+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 1574324] Update Released

2016-11-21 Thread Martin Pitt
The verification of the Stable Release Update for pulseaudio has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  pulseaudio crashes when connecting to bluetooth headphones (due to
  ubuntu changes?)

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Yakkety:
  Fix Released

Bug description:
  Impact:

  A patch we carry for Ubuntu touch introduced a change that originally
  was required to make sure PulseAudio did not crash. This patch was
  ported to PulseAudio 8 in Xenial, but the patch author's bluetooth
  hardware that was to hand at the time worked so was assumed to be ok.
  However, the opposite is now happening, i.e PulseAudio is crashing
  with a subset of Bluetooth hardware.

  Regression potential:

  Very low to none. As can be read in this report, much debugging and
  testing has been done to find the problem, and the eventual fix.
  Moreover the change is the removal of a patch hunk that removed a line
  of code originally present in PulseAudio.

  Test case:

  NOTE that this test case applies to bluetooth hardware that is
  identified as not working in this bug report.

  1. Install, or upgrade to Xenial or yakkety.
  2. Pair your bluetooth device in the bluetooth settings in the relevant 
settings application for your desktop environment.
  3. Once paired, you will notice that sound stops working, as pulseaudio has 
thrown an assertion error.
  4. You do not have to remove your audio device from the paired device list, 
but it may be easier to do so for the next part of the testing.
  5. Update to the version of PulseAudio in xenial-proposed which is 
1:8.0-0ubuntu3.1, or in yakkety-proposed, which is 1:9.0-2ubuntu2.1.
  6. Re-pair your device. Audio should continue to work, and you should be able 
to switch to your bluetooth device and use it.

  
  Original bug report:

  When I attempt to connect my Jaybird Bluebuds X to Ubuntu 16.04
  pulseaudio crashes, this does *NOT* happen with a Jambox which leads
  me to believe it's an intermittent problem with some hardware. This
  did not happen on Ubuntu 15.10 (which was an upgrade of 15.04).

  Ubuntu Release:

  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  Pulseaudio Version:

  pulseaudio:
    Installed: 1:8.0-0ubuntu3
    Candidate: 1:8.0-0ubuntu3
    Version table:
   *** 1:8.0-0ubuntu3 500
  500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  Device info:

  [bluetooth]# info 44:5E:F3:B4:07:29
  Device 44:5E:F3:B4:07:29
   Name: BlueBuds X
   Alias: BlueBuds X
   Class: 0x240404
   Icon: audio-card
   Paired: yes
   Trusted: yes
   Blocked: no
   Connected: no
   LegacyPairing: no
   UUID: Headset   (1108--1000-8000-00805f9b34fb)
   UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
   UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
   UUID: Handsfree (111e--1000-8000-00805f9b34fb)
   UUID: Unknown   (80ff--1000-8000-00805f9b34fb)

  I have also attached a debug dump of Pulseaudio when attempting to
  connect to the headphones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324/+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 1356548] Re: Duplicity restore fails with UTF-8 chars in --file-to-restore

2016-11-21 Thread Martin Pitt
The version of duplicity in the proposed pocket of Trusty that was
purported to fix this bug report has been removed because the bugs that
were to be fixed by the upload were not verified in a timely (105 days)
fashion.

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

Title:
  Duplicity restore fails with UTF-8 chars in --file-to-restore

Status in Duplicity:
  Fix Released
Status in duplicity package in Ubuntu:
  Fix Released
Status in duplicity source package in Trusty:
  Won't Fix

Bug description:
  Under Ubuntu 14.04 64bits, duplicity 0.6.23-1ubuntu4.1

  To reproduce the issue:

  1) Create a backup including non-ASCII characters pathname, e.g.,
  "data/Thèse" for instance

  2) Try a selective restore of the backup : duplicity --file-to-restore
  data/Thèse file:///home/user/Sauvegardes test/

  3) Crash :

  Traceback (most recent call last):
File "/usr/bin/duplicity", line 1494, in 
  with_tempdir(main)
File "/usr/bin/duplicity", line 1488, in with_tempdir
  fn()
File "/usr/bin/duplicity", line 1337, in main
  do_backup(action)
File "/usr/bin/duplicity", line 1422, in do_backup
  restore(col_stats)
File "/usr/bin/duplicity", line 700, in restore
  % (globals.restore_dir,),
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 21: 
ordinal not in range(128)

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1356548/+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 1356548] Proposed package removed from archive

2016-11-21 Thread Martin Pitt
The version of duplicity in the proposed pocket of Trusty that was
purported to fix this bug report has been removed because the bugs that
were to be fixed by the upload were not verified in a timely (105 days)
fashion.

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

Title:
  Duplicity restore fails with UTF-8 chars in --file-to-restore

Status in Duplicity:
  Fix Released
Status in duplicity package in Ubuntu:
  Fix Released
Status in duplicity source package in Trusty:
  Won't Fix

Bug description:
  Under Ubuntu 14.04 64bits, duplicity 0.6.23-1ubuntu4.1

  To reproduce the issue:

  1) Create a backup including non-ASCII characters pathname, e.g.,
  "data/Thèse" for instance

  2) Try a selective restore of the backup : duplicity --file-to-restore
  data/Thèse file:///home/user/Sauvegardes test/

  3) Crash :

  Traceback (most recent call last):
File "/usr/bin/duplicity", line 1494, in 
  with_tempdir(main)
File "/usr/bin/duplicity", line 1488, in with_tempdir
  fn()
File "/usr/bin/duplicity", line 1337, in main
  do_backup(action)
File "/usr/bin/duplicity", line 1422, in do_backup
  restore(col_stats)
File "/usr/bin/duplicity", line 700, in restore
  % (globals.restore_dir,),
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 21: 
ordinal not in range(128)

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1356548/+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 1356548] Proposed package removed from archive

2016-11-21 Thread Martin Pitt
The version of duplicity in the proposed pocket of Trusty that was
purported to fix this bug report has been removed because the bugs that
were to be fixed by the upload were not verified in a timely (105 days)
fashion.

** Changed in: duplicity (Ubuntu Trusty)
   Status: Fix Committed => Won't Fix

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

Title:
  Duplicity restore fails with UTF-8 chars in --file-to-restore

Status in Duplicity:
  Fix Released
Status in duplicity package in Ubuntu:
  Fix Released
Status in duplicity source package in Trusty:
  Won't Fix

Bug description:
  Under Ubuntu 14.04 64bits, duplicity 0.6.23-1ubuntu4.1

  To reproduce the issue:

  1) Create a backup including non-ASCII characters pathname, e.g.,
  "data/Thèse" for instance

  2) Try a selective restore of the backup : duplicity --file-to-restore
  data/Thèse file:///home/user/Sauvegardes test/

  3) Crash :

  Traceback (most recent call last):
File "/usr/bin/duplicity", line 1494, in 
  with_tempdir(main)
File "/usr/bin/duplicity", line 1488, in with_tempdir
  fn()
File "/usr/bin/duplicity", line 1337, in main
  do_backup(action)
File "/usr/bin/duplicity", line 1422, in do_backup
  restore(col_stats)
File "/usr/bin/duplicity", line 700, in restore
  % (globals.restore_dir,),
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 21: 
ordinal not in range(128)

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1356548/+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 1568604] Re: Mouse cursor lost when unlocking with Intel graphics

2016-11-18 Thread Martin Pitt
I don't see anythign left to sponsor here, so unsubscribing sponsors
now. Please re-subscribe when you upload further patches.

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

Title:
  Mouse cursor lost when unlocking with Intel graphics

Status in elementary OS:
  Fix Released
Status in xf86-video-intel:
  Confirmed
Status in xserver-xorg-video-intel package in Ubuntu:
  Fix Released
Status in xserver-xorg-video-intel-lts-xenial package in Ubuntu:
  Confirmed
Status in xserver-xorg-video-intel source package in Xenial:
  Fix Released
Status in xserver-xorg-video-intel package in Debian:
  Fix Released

Bug description:
  [Relevant details]
  This bug also affects Trusty and all distributions based on it, like 
Elementary OS Freya.

  
  [Impact]
  Mouse cursor is no longer visible after VT-switch for systems with Intel 
graphics.

  Switching VTs again may cause the cursor to become visible again.
  - Changing to vt1 then back to vt7 (ctrl+alt+f1 then ctrl+alt+f7)

  This is often observed in systems that lock the session and return to
  the greeter (including at least Xubuntu, Ubuntu Mate, and elementary
  OS).

  [Test Case]
  (Requires a lightdm-based screen locking solution)
  1. Start a new session.
  2. Lock your screen.
  2a. You are redirected to the lightdm greeter.
  3. Login/Unlock your session.
  4. Cursor is no longer visible.

  [Regression Potential]
  remains to be seen

  ===

  [Original Report]
  Cursor is visible at unlock screen either after returning from suspend or 
just locking.

  After unlocking screen cursor is invisible.

  Changing to vt1 then back to vt7 (ctrl+alt+f1 then ctrl+alt+f7) cursor
  returns

  

  no matter if you suspend or sleep, to swap or disk when you return
  from it, the mouse cursor is missing.you can still move the mouse
  and you can see (because it highlights the window) as you move it
  around.   But the cursor is not displayed on the screen.

  i am using a lenovo W540 laptop.   I downloaded the latest beta on
  april 8 2016.

  this is xubuntu using the xfce window manager.

  the cursor does return if i log off and log back in, but that actually 
defeats the purpose of going to sleep.
  ---
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  DistroRelease: Ubuntu 16.04
  InstallationDate: Installed on 2016-04-08 (2 days ago)
  InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323)
  NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
  Package: light-locker 1.7.0-2ubuntu1
  PackageArchitecture: amd64
  ProcEnviron:
   LANGUAGE=en_US
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
  Tags:  xenial
  Uname: Linux 4.4.0-18-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/elementaryos/+bug/1568604/+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 1642001] Re: uim-qt5 check is broken

2016-11-18 Thread Martin Pitt
Sponsored the xenial update, unsubscribing sponsors now. Thanks!

** Also affects: im-config (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  uim-qt5 check is broken

Status in im-config package in Ubuntu:
  Fix Released
Status in im-config source package in Xenial:
  New
Status in im-config source package in Yakkety:
  Fix Committed
Status in im-config package in Debian:
  Fix Released

Bug description:
  [Impact]

  XIM support check for Qt5 in UIM is broken — it uses the same paths as
  for Qt4, but they've been changed.

  Fix uploaded to yakkety queue; xenial patch attached.

  [Test Case]

  After the change, this command:

  grep platforminputcontexts /usr/share/im-config/data/24_uim.rc

  should output:

  for IM_CONFIG_MARKER in
  
/usr/lib/*/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
  ; do

  [Regression Potential]

  None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1642001/+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 1560162] Update Released

2016-11-18 Thread Martin Pitt
The verification of the Stable Release Update for ubiquity has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  Xenial: scaling is horribly out on xps13 install session

Status in OEM Priority Project:
  New
Status in metacity package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in metacity source package in Xenial:
  Fix Released
Status in ubiquity source package in Xenial:
  Fix Released

Bug description:
  STEPS:
  Requirements laptop desktop with a hidpi screen (Here xps 13)
  1. Grab the latest daily image and trigger an install
  2. On the first page notice the of centre and over scaled window

  EXPECTED:
  I expect to see something resembling a normal scaled desktop install

  ACTUAL:
  Things are not quite correct see attached screenshots

  ubiquity/xenial 2.21.49 amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1560162/+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 1636397] Re: Fix modesetting slave output names

2016-11-18 Thread Martin Pitt
unity8 tests have always been brittle; the autopilot ones (which use X)
succeeded, while the QML ones (which don't use X) didn't, so this
appears unrelated.

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

Title:
  Fix modesetting slave output names

Status in HWE Next:
  New
Status in xorg-server package in Ubuntu:
  Fix Released
Status in xorg-server source package in Xenial:
  Fix Released
Status in xorg-server source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  Currently, NVIDIA and modesetting drivers are using same output names, that 
creates confusion for xrandr clients like gnome-setting-daemon or xrandr 
utility.

  When modesetting outputs act as slave for other x-screen (like NVIDIA
  X-screen here), modesetting driver uses different scheme of output
  names to avoid kind of confusion we are seeing here. There is a bug in
  modesetting X-driver gets shipped with X-server, which disables slave
  output's name scheme.

  From a reviewed upstream patch:

  "Commit c7e8d4a6ee9542f56cd241cf7a960fb8223a6b22 had already
  unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
  9257b1252da9092ddc676fec9aabe2b33dfad272 didn't notice that."

  so we need to backport that to zesty/yakkety/xenial.

  [Test Case]
  Enable dGPU, test that output to DP works.

  [Regression Potential]
  There should be none, as this leftover was a simple mistake that shouldn't be 
there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1636397/+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 1636397] Update Released

2016-11-18 Thread Martin Pitt
The verification of the Stable Release Update for xorg-server has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  Fix modesetting slave output names

Status in HWE Next:
  New
Status in xorg-server package in Ubuntu:
  Fix Released
Status in xorg-server source package in Xenial:
  Fix Released
Status in xorg-server source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  Currently, NVIDIA and modesetting drivers are using same output names, that 
creates confusion for xrandr clients like gnome-setting-daemon or xrandr 
utility.

  When modesetting outputs act as slave for other x-screen (like NVIDIA
  X-screen here), modesetting driver uses different scheme of output
  names to avoid kind of confusion we are seeing here. There is a bug in
  modesetting X-driver gets shipped with X-server, which disables slave
  output's name scheme.

  From a reviewed upstream patch:

  "Commit c7e8d4a6ee9542f56cd241cf7a960fb8223a6b22 had already
  unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
  9257b1252da9092ddc676fec9aabe2b33dfad272 didn't notice that."

  so we need to backport that to zesty/yakkety/xenial.

  [Test Case]
  Enable dGPU, test that output to DP works.

  [Regression Potential]
  There should be none, as this leftover was a simple mistake that shouldn't be 
there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1636397/+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 1639050] Re: Wrong package section, should be in "introspection"

2016-11-17 Thread Martin Pitt
I changed the overrides of all the gir* packages in zesty, so that the
archive now has the correct ones. The sources should still be updated to
follow suit at some point, though.

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

Title:
  Wrong package section, should be in "introspection"

Status in webapps-sprint:
  New
Status in libsignon-glib package in Ubuntu:
  Confirmed

Bug description:
  Packages shipping gobject introspection should be in the dedicated
  section "introspection". This archive section was added a while ago,
  see also the corresponding entry in the debian policy 3.9.3.0:

  2.6. Version 3.9.3.0
  

   Released February, 2012.

   2.4
New archive sections _education_, _introspection_, and
_metapackages_ added.

  
  Packages shipping gobject introspection should be named 
gir1.2-NAMESPACE-VERSION.

  Based on the output of apt-cache, the following packages are in the
  wrong section. I didn't file a separate bug for all of them. I would
  appreciate if you can adjust the archive section for all the following
  packages in one go.

  #!/bin/bash

  while read pkg ; do
 apt-cache show $pkg | grep Section | grep -v introspection -q && echo 
$pkg
  done < <( apt-cache search -n ^gir1.2 | cut -f1 -d' ' )

  
  gir1.2-accounts-1.0
  gir1.2-accountsservice-1.0
  gir1.2-appindicator-0.1
  gir1.2-appindicator3-0.1
  gir1.2-atk-1.0
  gir1.2-atspi-2.0
  gir1.2-bamf-3
  gir1.2-cheese-3.0
  gir1.2-clutter-1.0
  gir1.2-cogl-1.0
  gir1.2-coglpango-1.0
  gir1.2-colord-1.0
  gir1.2-dbusmenu-glib-0.4
  gir1.2-dbusmenu-gtk-0.4
  gir1.2-dbusmenu-gtk3-0.4
  gir1.2-dee-1.0
  gir1.2-ebook-1.2
  gir1.2-edataserver-1.2
  gir1.2-fcitx-1.0
  gir1.2-freedesktop
  gir1.2-gconf-2.0
  gir1.2-gdata-0.0
  gir1.2-gdesktopenums-3.0
  gir1.2-gdkpixbuf-2.0
  gir1.2-gkbd-3.0
  gir1.2-glib-2.0
  gir1.2-gmenu-3.0
  gir1.2-gnomebluetooth-1.0
  gir1.2-gnomedesktop-3.0
  gir1.2-goa-1.0
  gir1.2-gtk-2.0
  gir1.2-gtk-3.0
  gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0
  gir1.2-gtop-2.0
  gir1.2-gucharmap-2.90
  gir1.2-gudev-1.0
  gir1.2-gweather-3.0
  gir1.2-hud-2
  gir1.2-hud-client-2
  gir1.2-ido3-0.1
  gir1.2-json-1.0
  gir1.2-lightdm-1
  gir1.2-messagingmenu-1.0
  gir1.2-nautilus-3.0
  gir1.2-networkmanager-1.0
  gir1.2-notify-0.7
  gir1.2-packagekitglib-1.0
  gir1.2-pango-1.0
  gir1.2-peas-1.0
  gir1.2-polkit-1.0
  gir1.2-rb-3.0
  gir1.2-rest-0.7
  gir1.2-rest-extras-0.7
  gir1.2-rsvg-2.0
  gir1.2-signon-1.0
  gir1.2-soup-2.4
  gir1.2-telepathyglib-0.12
  gir1.2-timezonemap-1.0
  gir1.2-totem-1.0
  gir1.2-totem-plparser-1.0
  gir1.2-unity-5.0
  gir1.2-upowerglib-1.0
  gir1.2-wnck-3.0
  gir1.2-evince-3.0
  gir1.2-geocodeglib-1.0
  gir1.2-libertine
  gir1.2-nmgtk-1.0
  gir1.2-ubuntu-app-launch-2
  gir1.2-anjuta-3.0
  gir1.2-atril
  gir1.2-caja
  gir1.2-caribou-1.0
  gir1.2-champlain-0.12
  gir1.2-cryptui-0.0
  gir1.2-diodon-1.0
  gir1.2-eom
  gir1.2-evd-0.1
  gir1.2-folks-0.6
  gir1.2-gdl-3
  gir1.2-gssdp-1.0
  gir1.2-gtk-vnc-2.0
  gir1.2-gtkchamplain-0.12
  gir1.2-gupnp-1.0
  gir1.2-gupnp-av-1.0
  gir1.2-gupnpigd-1.0
  gir1.2-indicate-0.7
  gir1.2-itl-1.0
  gir1.2-keybinder-3.0
  gir1.2-maliit-1.0
  gir1.2-mate-menu
  gir1.2-mate-panel
  gir1.2-mate-polkit
  gir1.2-matekbd
  gir1.2-mutter-3.0
  gir1.2-spice-client-glib-2.0
  gir1.2-spice-client-gtk-3.0
  gir1.2-telepathylogger-0.2
  gir1.2-urfkill-glib0
  gir1.2-v-sim-1.0
  gir1.2-gladeui-2.0
  gir1.2-grip
  gir1.2-javascriptcoregtk-3.0
  gir1.2-libvirt-glib-1.0
  gir1.2-nemo-3.0
  gir1.2-snapd-1
  gir1.2-webkit-3.0

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: gir1.2-accounts-1.0 1.22+16.10.20160520.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
  Uname: Linux 4.8.0-26-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Thu Nov  3 22:02:42 2016
  InstallationDate: Installed on 2011-11-10 (1819 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  SourcePackage: libaccounts-glib
  UpgradeStatus: Upgraded to yakkety on 2016-11-03 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/webapps-sprint/+bug/1639050/+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 1639050] Re: Wrong package section, should be in "introspection"

2016-11-17 Thread Martin Pitt
> I'm a bit confused. I thought that the section information was stored
in debian/control, but I see that while I have had (since 2014)
"Section: introspection" in libaccounts-glib's debian/control [1], "apt-
cache show" claims that the section is "libs".

No, you don't. debian/control says

Package: gir1.2-signon-1.0
Section: libs

So this does need to be fixed.

Meanwhile I can change the archive overrides correspondingly.

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

Title:
  Wrong package section, should be in "introspection"

Status in webapps-sprint:
  New
Status in libsignon-glib package in Ubuntu:
  Confirmed

Bug description:
  Packages shipping gobject introspection should be in the dedicated
  section "introspection". This archive section was added a while ago,
  see also the corresponding entry in the debian policy 3.9.3.0:

  2.6. Version 3.9.3.0
  

   Released February, 2012.

   2.4
New archive sections _education_, _introspection_, and
_metapackages_ added.

  
  Packages shipping gobject introspection should be named 
gir1.2-NAMESPACE-VERSION.

  Based on the output of apt-cache, the following packages are in the
  wrong section. I didn't file a separate bug for all of them. I would
  appreciate if you can adjust the archive section for all the following
  packages in one go.

  #!/bin/bash

  while read pkg ; do
 apt-cache show $pkg | grep Section | grep -v introspection -q && echo 
$pkg
  done < <( apt-cache search -n ^gir1.2 | cut -f1 -d' ' )

  
  gir1.2-accounts-1.0
  gir1.2-accountsservice-1.0
  gir1.2-appindicator-0.1
  gir1.2-appindicator3-0.1
  gir1.2-atk-1.0
  gir1.2-atspi-2.0
  gir1.2-bamf-3
  gir1.2-cheese-3.0
  gir1.2-clutter-1.0
  gir1.2-cogl-1.0
  gir1.2-coglpango-1.0
  gir1.2-colord-1.0
  gir1.2-dbusmenu-glib-0.4
  gir1.2-dbusmenu-gtk-0.4
  gir1.2-dbusmenu-gtk3-0.4
  gir1.2-dee-1.0
  gir1.2-ebook-1.2
  gir1.2-edataserver-1.2
  gir1.2-fcitx-1.0
  gir1.2-freedesktop
  gir1.2-gconf-2.0
  gir1.2-gdata-0.0
  gir1.2-gdesktopenums-3.0
  gir1.2-gdkpixbuf-2.0
  gir1.2-gkbd-3.0
  gir1.2-glib-2.0
  gir1.2-gmenu-3.0
  gir1.2-gnomebluetooth-1.0
  gir1.2-gnomedesktop-3.0
  gir1.2-goa-1.0
  gir1.2-gtk-2.0
  gir1.2-gtk-3.0
  gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0
  gir1.2-gtop-2.0
  gir1.2-gucharmap-2.90
  gir1.2-gudev-1.0
  gir1.2-gweather-3.0
  gir1.2-hud-2
  gir1.2-hud-client-2
  gir1.2-ido3-0.1
  gir1.2-json-1.0
  gir1.2-lightdm-1
  gir1.2-messagingmenu-1.0
  gir1.2-nautilus-3.0
  gir1.2-networkmanager-1.0
  gir1.2-notify-0.7
  gir1.2-packagekitglib-1.0
  gir1.2-pango-1.0
  gir1.2-peas-1.0
  gir1.2-polkit-1.0
  gir1.2-rb-3.0
  gir1.2-rest-0.7
  gir1.2-rest-extras-0.7
  gir1.2-rsvg-2.0
  gir1.2-signon-1.0
  gir1.2-soup-2.4
  gir1.2-telepathyglib-0.12
  gir1.2-timezonemap-1.0
  gir1.2-totem-1.0
  gir1.2-totem-plparser-1.0
  gir1.2-unity-5.0
  gir1.2-upowerglib-1.0
  gir1.2-wnck-3.0
  gir1.2-evince-3.0
  gir1.2-geocodeglib-1.0
  gir1.2-libertine
  gir1.2-nmgtk-1.0
  gir1.2-ubuntu-app-launch-2
  gir1.2-anjuta-3.0
  gir1.2-atril
  gir1.2-caja
  gir1.2-caribou-1.0
  gir1.2-champlain-0.12
  gir1.2-cryptui-0.0
  gir1.2-diodon-1.0
  gir1.2-eom
  gir1.2-evd-0.1
  gir1.2-folks-0.6
  gir1.2-gdl-3
  gir1.2-gssdp-1.0
  gir1.2-gtk-vnc-2.0
  gir1.2-gtkchamplain-0.12
  gir1.2-gupnp-1.0
  gir1.2-gupnp-av-1.0
  gir1.2-gupnpigd-1.0
  gir1.2-indicate-0.7
  gir1.2-itl-1.0
  gir1.2-keybinder-3.0
  gir1.2-maliit-1.0
  gir1.2-mate-menu
  gir1.2-mate-panel
  gir1.2-mate-polkit
  gir1.2-matekbd
  gir1.2-mutter-3.0
  gir1.2-spice-client-glib-2.0
  gir1.2-spice-client-gtk-3.0
  gir1.2-telepathylogger-0.2
  gir1.2-urfkill-glib0
  gir1.2-v-sim-1.0
  gir1.2-gladeui-2.0
  gir1.2-grip
  gir1.2-javascriptcoregtk-3.0
  gir1.2-libvirt-glib-1.0
  gir1.2-nemo-3.0
  gir1.2-snapd-1
  gir1.2-webkit-3.0

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: gir1.2-accounts-1.0 1.22+16.10.20160520.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
  Uname: Linux 4.8.0-26-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Thu Nov  3 22:02:42 2016
  InstallationDate: Installed on 2011-11-10 (1819 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  SourcePackage: libaccounts-glib
  UpgradeStatus: Upgraded to yakkety on 2016-11-03 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/webapps-sprint/+bug/1639050/+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


  1   2   3   4   5   6   7   8   9   10   >