[Touch-packages] [Bug 1965535] Re: Stop recommending snap

[Forest]

+1

For the record, Snap being forced upon users for critical packages is
the primary reason why I recently dropped Ubuntu and stopped
recommending the distro to others, after using it for over 15 years.

Container-based packaging has its place. Snap has some interesting
features compared to FlatPak and AppImage. However, none of them are
suitable replacements for deb & apt, and this is really driven home when
they're used for core packages like the web browser. Snap in particular
has multiple fundamental design and implementation problems that make it
intolerable.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1965535

Title:
  Stop recommending snap

Status in ubuntu-meta package in Ubuntu:
  Opinion

Bug description:
  Currently, ubuntu recommends installing snap by default, and some apps
  are slowly transitioning from DEB-based installation to Snap-based
  installation.

  APT is great, and facilitates having a clean, maintainable system.

  The snap project is not very well designed or engineered (just
  changing the location of where snap data is located is taking the
  project more than 5 years because it was hardcoded:
  https://bugs.launchpad.net/snapd/+bug/1575053). Snaps are large and
  VERY slow. The design of snap, as well as the way that decisions are
  made, are very questionable, and are receiving increasing amounts of
  criticism.

  I'd like to request that Ubuntu stops recommending snap, stops
  transitioning towards snaps, and we come back to defaulting to
  DEB/APT-based installation for all apps.

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


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

[Touch-packages] [Bug 1547589] Re: rtkit-daemon flooding syslog

[Forest]

** Bug watch added: github.com/heftig/rtkit/issues #22
   https://github.com/heftig/rtkit/issues/22

** Also affects: rtkit via
   https://github.com/heftig/rtkit/issues/22
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rtkit in Ubuntu.
https://bugs.launchpad.net/bugs/1547589

Title:
  rtkit-daemon flooding syslog

Status in Rtkit:
  Unknown
Status in rtkit package in Ubuntu:
  Confirmed
Status in rtkit package in Debian:
  Confirmed

Bug description:
  rtkit is flooding syslog with the following:

  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 
processes of 1 users.
  Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit 
for user '1000', denying request.

  This may be related to but #1547585

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: rtkit 0.11-4
  ProcVersionSignature: Ubuntu 4.4.0-6.21-generic 4.4.1
  Uname: Linux 4.4.0-6-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Feb 19 11:42:58 2016
  InstallationDate: Installed on 2016-02-11 (7 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160210)
  SourcePackage: rtkit
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

I hate to say this, folks, but ecryptfs looks like a dead end for us.
It's no longer supported by Ubuntu (the package has been moved to the
Universe repo). Also, the problem at hand is caused by systemd, which is
run by a man famous for releasing poorly-vetted, system-breaking
software, and then refusing to fix the damage he causes.

For a year or so, I maintained a systemd patch to work around this bug.
(It is posted above, but no longer applies to current systemd code.)
There was a time when it looked like the problem was finally fixed
upstream, but then it just broke again.

Anyone who (like me) has been using ecryptfs to encrypt a private directory and 
unlock it only when needed, might consider switching to gocryptfs.  From a 
user's point of view, it works similarly to ecryptfs.  There's also a handy GUI 
called SiriKali that works with it.
https://nuetzlich.net/gocryptfs/
https://mhogomchungu.github.io/sirikali/

Good luck.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1877219] Re: dozens of empty grilo-plugin-cache folders polluting /tmp

[Forest]

** Bug watch added: gitlab.gnome.org/GNOME/grilo-plugins/-/issues #70
   https://gitlab.gnome.org/GNOME/grilo-plugins/-/issues/70

** Also affects: grilo-plugins via
   https://gitlab.gnome.org/GNOME/grilo-plugins/-/issues/70
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grilo-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1877219

Title:
  dozens of empty grilo-plugin-cache folders polluting /tmp

Status in Grilo Plugins:
  Unknown
Status in grilo-plugins package in Ubuntu:
  New

Bug description:
  My /tmp folder has dozens of empty folders with names like grilo-
  plugin-cache-ABCDEF. I don't know anything about grilo-plugins, but
  surely they can do their job without leaving endless garbage
  directories behind when they're done?

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 19.10
  Release:  19.10
  Codename: eoan

  $ dpkg-query --show grilo-plugins-0.3-base
  grilo-plugins-0.3-base:amd64  0.3.9-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/grilo-plugins/+bug/1877219/+subscriptions

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

[Touch-packages] [Bug 1877219] [NEW] dozens of empty grilo-plugin-cache folders polluting /tmp

[Forest]

Public bug reported:

My /tmp folder has dozens of empty folders with names like grilo-plugin-
cache-ABCDEF. I don't know anything about grilo-plugins, but surely they
can do their job without leaving endless garbage directories behind when
they're done?

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 19.10
Release:19.10
Codename:   eoan

$ dpkg-query --show grilo-plugins-0.3-base
grilo-plugins-0.3-base:amd640.3.9-1ubuntu1

** Affects: grilo-plugins (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  My /tmp folder has dozens of empty folders with names like grilo-plugin-
  cache-ABCDEF. I don't know anything about grilo-plugins, but surely they
  can do their job without leaving endless garbage directories behind when
  they're done?
+ 
+ $ lsb_release -a
+ No LSB modules are available.
+ Distributor ID:   Ubuntu
+ Description:  Ubuntu 19.10
+ Release:  19.10
+ Codename: eoan
+ 
+ $ dpkg-query --show grilo-plugins-0.3-base
+ grilo-plugins-0.3-base:amd64  0.3.9-1ubuntu1

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grilo-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1877219

Title:
  dozens of empty grilo-plugin-cache folders polluting /tmp

Status in grilo-plugins package in Ubuntu:
  New

Bug description:
  My /tmp folder has dozens of empty folders with names like grilo-
  plugin-cache-ABCDEF. I don't know anything about grilo-plugins, but
  surely they can do their job without leaving endless garbage
  directories behind when they're done?

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 19.10
  Release:  19.10
  Codename: eoan

  $ dpkg-query --show grilo-plugins-0.3-base
  grilo-plugins-0.3-base:amd64  0.3.9-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1877219/+subscriptions

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

[Touch-packages] [Bug 1866124] Re: ps -eo lxc no longer shows a task's lxc container

[Forest]

The top command's LXC column (not shown by default, but can be enabled
through the 'f' menu) also shows a - for all processes, including those
that belong to containers.

My containers are unprivileged, in case that matters.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1866124

Title:
  ps -eo lxc no longer shows a task's lxc container

Status in lxc package in Ubuntu:
  New
Status in procps package in Ubuntu:
  New

Bug description:
  When I use the ps command's "lxc" format specifier, for example:

  ps -eo pid,lxc,command

  The second output column is supposed to show "the name of the lxc
  container within which a task is running.  If a process is not running
  inside a container, a dash ('-') will be shown." [1]

  This worked fine until I upgraded from ubuntu 19.04 to 19.10, which
  brought me from lxc 3.03 to 3.04.  Now, that column always contains a
  dash instead of the container name, even for processes that are
  running inside a container.  The "lxc" format specifier seems to be
  broken now.

  [1]
  
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers

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

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

[Touch-packages] [Bug 1866124] [NEW] ps -eo lxc no longer shows a task's lxc container

[Forest]

Public bug reported:

When I use the ps command's "lxc" format specifier, for example:

ps -eo pid,lxc,command

The second output column is supposed to show "the name of the lxc
container within which a task is running.  If a process is not running
inside a container, a dash ('-') will be shown." [1]

This worked fine until I upgraded from ubuntu 19.04 to 19.10, which
brought me from lxc 3.03 to 3.04.  Now, that column always contains a
dash instead of the container name, even for processes that are running
inside a container.  The "lxc" format specifier seems to be broken now.

[1]
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers

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

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

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

** Description changed:

  When I use the ps command's "lxc" format specifier, for example:
  
  ps -eo pid,lxc,command
  
  The second output column is supposed to show "the name of the lxc
  container within which a task is running.  If a process is not running
  inside a container, a dash ('-') will be shown." [1]
  
- This worked fine until I upgraded from ubuntu 19.04 to 19.10.  Now, that
- column always contains a dash instead of the container name, even for
- processes that are running inside a container.  The "lxc" format
- specifier seems to be broken now.
+ This worked fine until I upgraded from ubuntu 19.04 to 19.10, which
+ brought me from lxc 3.03 to 3.04.  Now, that column always contains a
+ dash instead of the container name, even for processes that are running
+ inside a container.  The "lxc" format specifier seems to be broken now.
  
- 
- [1] 
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers
+ [1]
+ 
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1866124

Title:
  ps -eo lxc no longer shows a task's lxc container

Status in lxc package in Ubuntu:
  New
Status in procps package in Ubuntu:
  New

Bug description:
  When I use the ps command's "lxc" format specifier, for example:

  ps -eo pid,lxc,command

  The second output column is supposed to show "the name of the lxc
  container within which a task is running.  If a process is not running
  inside a container, a dash ('-') will be shown." [1]

  This worked fine until I upgraded from ubuntu 19.04 to 19.10, which
  brought me from lxc 3.03 to 3.04.  Now, that column always contains a
  dash instead of the container name, even for processes that are
  running inside a container.  The "lxc" format specifier seems to be
  broken now.

  [1]
  
https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers

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

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

[Touch-packages] [Bug 1843490] [NEW] lxc.cgroup.devices.allow prevents unprivileged container from starting

[Forest]

Public bug reported:

Adding lxc.cgroup.devices.allow directives to an unprivileged container
config prevent the container from starting. These lxc-start errors look
relevant:


lxc-start testbox 20190910192712.171 WARN cgfsng - 
cgroups/cgfsng.c:get_hierarchy:204 - There is no useable devices controller
lxc-start testbox 20190910192712.171 ERRORcgfsng - 
cgroups/cgfsng.c:cg_legacy_set_data:2191 - Failed to setup limits for the 
"devices" controller. The controller seems to be unused by "cgfsng" cgroup 
driver or not enabled on the cgroup hierarchy
lxc-start testbox 20190910192712.171 WARN cgfsng - 
cgroups/cgfsng.c:__cg_legacy_setup_limits:2228 - Failed to set "devices.allow" 
to "c 10:57 rwm"


It seems to me that I used lxc.cgroup.devices.allow directives without trouble 
a few years ago. I wonder which system upgrades broke it.


To reproduce:

(Note: subuid, subgid, and lxc-usernet are already configured for this
user.)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename:   disco

$ dpkg-query --show libpam-cgfs lxc1
libpam-cgfs 3.0.3-0ubuntu1
lxc13.0.3-0ubuntu1

$ lxc-create -t download -n testbox -- -d ubuntu -r bionic -a amd64
The cached copy has expired, re-downloading...
Setting up the GPG keyring
Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created an Ubuntu bionic amd64 (20190910_07:42) container.

To enable SSH, run: apt install openssh-server
No default root or user password are set by LXC.

$ echo "lxc.cgroup.devices.allow = c 10:57 rwm" >> lxc/testbox/config

$ lxc-start -n testbox -o debug.out -l trace
lxc-start: testbox: lxccontainer.c: wait_on_daemonized_start: 842 Received 
container state "ABORTING" instead of "RUNNING"
lxc-start: testbox: tools/lxc_start.c: main: 330 The container failed to start
lxc-start: testbox: tools/lxc_start.c: main: 333 To get more details, run the 
container in foreground mode
lxc-start: testbox: tools/lxc_start.c: main: 336 Additional information can be 
obtained by setting the --logfile and --logpriority options

$ cat debug.out
lxc-start testbox 20190910192712.380 INFO confile - 
confile.c:set_config_idmaps:1555 - Read uid map: type u nsid 0 hostid 10 
range 65536
lxc-start testbox 20190910192712.380 INFO confile - 
confile.c:set_config_idmaps:1555 - Read uid map: type g nsid 0 hostid 10 
range 65536
lxc-start testbox 20190910192712.382 TRACEcommands - commands.c:lxc_cmd:300 
- Connection refused - Command "get_init_pid" failed to connect command socket
lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd:300 
- Connection refused - Command "get_state" failed to connect command socket
lxc-start testbox 20190910192712.383 TRACEstart - 
start.c:lxc_init_handler:748 - Created anonymous pair {4,5} of unix sockets
lxc-start testbox 20190910192712.383 TRACEcommands - 
commands.c:lxc_cmd_init:1248 - Creating abstract unix socket 
"/home/ubuntu/lxc/testbox/command"
lxc-start testbox 20190910192712.383 TRACEstart - 
start.c:lxc_init_handler:760 - Unix domain socket 6 for command server is ready
lxc-start testbox 20190910192712.388 INFO lxccontainer - 
lxccontainer.c:do_lxcapi_start:961 - Set process title to [lxc monitor] 
/home/ubuntu/lxc testbox
lxc-start testbox 20190910192712.392 TRACEstart - start.c:lxc_start:2052 - 
Doing lxc_start
lxc-start testbox 20190910192712.393 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM 
security driver AppArmor
lxc-start testbox 20190910192712.393 TRACEstart - start.c:lxc_init:777 - 
Initialized LSM
lxc-start testbox 20190910192712.395 TRACEseccomp - 
seccomp.c:get_new_ctx:458 - Added arch 2 to main seccomp context
lxc-start testbox 20190910192712.395 TRACEseccomp - 
seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context
lxc-start testbox 20190910192712.395 TRACEseccomp - 
seccomp.c:get_new_ctx:458 - Added arch 3 to main seccomp context
lxc-start testbox 20190910192712.395 TRACEseccomp - 
seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context
lxc-start testbox 20190910192712.395 TRACEseccomp - 
seccomp.c:get_new_ctx:471 - Arch 4 already present in main seccomp context
lxc-start testbox 20190910192712.395 INFO seccomp - 
seccomp.c:parse_config_v2:759 - Processing "reject_force_umount  # comment this 
to allow umount -f;  not recommended"
lxc-start testbox 20190910192712.395 INFO seccomp - 
seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start testbox 20190910192712.395 INFO seccomp - 
seccomp.c:parse_config_v2:937 - Added native rule for arch 0 for 
reject_force_umount action 0(kill)
lxc-start testbox 20190910192712.396 INFO seccomp - 
seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts
lxc-start testbox 20190910192712.396 INFO seccomp - 

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

The systemd patch I posted earlier no longer works in disco, and the
workarounds posted here only partially fix the problem and only for a
subset of use cases. Looks like we're back to needing a proper fix.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

Still broken in disco.

** Tags added: disco

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

A systemd build with my patch applied is available here:

https://launchpad.net/~foresto/+archive/ubuntu/ubuntutweaks/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

The ecryptfs-manager workaround helps the mount to succeed, but (at
least in my case) the system refuses to unmount it afterward. This is a
problem for those of us who open our ecryptfs volumes only for as long
as they're needed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

This is a systemd bug, created by this commit:

https://github.com/systemd/systemd/commit/74dd6b5

It looks like poettering has attempted to address it in more recent
versions of systemd (though that doesn't help us in ubuntu 17.10):

https://github.com/systemd/systemd/pull/6832

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

Here's a simple patch to disable the broken systemd feature, and restore
ecryptfs functionality.

** Patch added: "disable_system_service_session_keyrings.patch"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1718658/+attachment/5038578/+files/disable_system_service_session_keyrings.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1726873] Re: mount.ecryptfs_private can't mount in 17.10

[Forest]

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

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

** This bug has been marked a duplicate of bug 1718658
   ecryptfs-mount-private fails to initialize ecryptfs keys

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1726873

Title:
  mount.ecryptfs_private can't mount in 17.10

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,

  I am using several ecryptfs mounts with ecryptfs-add-passphrase and
  mount.ecryptfs_private, configured in ~/.ecryptfs/xxx.conf and
  ~/.ecryptfs/xxx.sig, which was working well for years up to 17.04.

  With 17.10 I can't mount these file systems anymore.

  ecryptfs-add-passphrase says

  Inserted auth tok with sig [] into the user session keyring
   
  with the correct sig (!). 

  
  Trying to mount with mount.ecryptfs_private then says 
  mount: No such file or directory

  although all directories present and correct.

  the Kernel then says (dmesg):

  
  [10149.247972] Could not find key with description: [...]
  [10149.247994] process_request_key_err: No key
  [10149.248000] Could not find valid key in user session keyring for sig 
specified in mount option: [...]
  [10149.248012] One or more global auth toks could not properly register; rc = 
[-2]
  [10149.248019] Error parsing options; rc = [-2]

  
  with exactly the same sig! 

  
  So although ecryptfs-add-passphrase claimed to have added the key to the 
keyring, the kernel complains that it could not find such a key.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ecryptfs-utils 111-0ubuntu5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: LXDE
  Date: Tue Oct 24 15:31:45 2017
  InstallationDate: Installed on 2017-10-24 (0 days ago)
  InstallationMedia: Lubuntu 17.10 "Artful Aardvark" - Release amd64 
(20171017.1)
  SourcePackage: ecryptfs-utils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1726873/+subscriptions

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

[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys

[Forest]

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718658

Title:
  ecryptfs-mount-private fails to initialize ecryptfs keys

Status in ecryptfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  ecryptfs-mount-private fails to mount the ecryptfs after the 1st
  reboot after creating the ecryptfs by ecryptfs-setup-private.

  After the unsucessful attempt dmesg contains:

  [ 1265.695388] Could not find key with description: []
  [ 1265.695393] process_request_key_err: No key
  [ 1265.695394] Could not find valid key in user session keyring for sig 
specified in mount option: []
  [ 1265.695395] One or more global auth toks could not properly register; rc = 
[-2]
  [ 1265.695396] Error parsing options; rc = [-2]

  Note: The correct key ID has been replaced in the "".

  I also accidentally found an workaround - just running ecrytpfs-
  manager and then the ecryptfs-mount-private (it does not ask for
  password for the second time and mounts the ecryptfs correctly):

  host:~$ ecryptfs-manager

  eCryptfs key management menu
  ---
1. Add passphrase key to keyring
2. Add public key to keyring
3. Generate new public/private keypair
4. Exit

  Make selection: 4
  host:~$ ls Private/
  Access-Your-Private-Data.desktop  README.txt
  host:~$ ecryptfs-mount-private 
  host:~$ ls Private/
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions

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

[Touch-packages] [Bug 1699660] Re: systemd-resolve breaks resolution of local network hostnames

[Forest]

No, that won't help either.

You don't seem to understand: Adding a domain search list will not help
because the local machines do not have domains. They only have names,
like "host1" or "beetle", even on the network's DNS servers.

Since systemd's resolver refuses to consult the name servers for names
like these, it completely breaks name resolution on networks like this.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1699660

Title:
  systemd-resolve breaks resolution of local network hostnames

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrading to Ubuntu 17.04 (zesty), resolution of my local
  network's host names is completely broken.  Apparently the upgrade
  replaced my existing resolver with systemd-resolve, which deliberately
  refuses to pass "single-label" domain names to my domain name server.
  That is the server where all my network's host names are kept, so I
  can no longer resolve any of them.

  Apparently, this is yet another example of Poettering's upstream decisions 
causing denial of service to people who have been saddled with his malware.
  https://github.com/systemd/systemd/issues/2514#issuecomment-179203186

  Would someone sensible please put a stop to this forced breakage
  during upgrade, and advise on how to fix it now that the damage has
  been done?

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

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

[Touch-packages] [Bug 1699660] Re: systemd-resolve breaks resolution of local network hostnames

[Forest]

According to the systemd documentation, UseDomains only affects systems
that get their network setup from DHCP, which is not the case at my
site.  Furthermore, it is documented as a way to add a DNS search
domain, which would not help resolve hosts that have no domains.

So far, the only way I have found to fix the breakage is to manually
disable systemd-resolve and configure a resolver that actually works
properly.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1699660

Title:
  systemd-resolve breaks resolution of local network hostnames

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrading to Ubuntu 17.04 (zesty), resolution of my local
  network's host names is completely broken.  Apparently the upgrade
  replaced my existing resolver with systemd-resolve, which deliberately
  refuses to pass "single-label" domain names to my domain name server.
  That is the server where all my network's host names are kept, so I
  can no longer resolve any of them.

  Apparently, this is yet another example of Poettering's upstream decisions 
causing denial of service to people who have been saddled with his malware.
  https://github.com/systemd/systemd/issues/2514#issuecomment-179203186

  Would someone sensible please put a stop to this forced breakage
  during upgrade, and advise on how to fix it now that the damage has
  been done?

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

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

[Touch-packages] [Bug 1699660] [NEW] systemd-resolve breaks resolution of local network hostnames

[Forest]

Public bug reported:

After upgrading to Ubuntu 17.04 (zesty), resolution of my local
network's host names is completely broken.  Apparently the upgrade
replaced my existing resolver with systemd-resolve, which deliberately
refuses to pass "single-label" domain names to my domain name server.
That is the server where all my network's host names are kept, so I can
no longer resolve any of them.

Apparently, this is yet another example of Poettering's upstream decisions 
causing denial of service to people who have been saddled with his malware.
https://github.com/systemd/systemd/issues/2514#issuecomment-179203186

Would someone sensible please put a stop to this forced breakage during
upgrade, and advise on how to fix it now that the damage has been done?

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1699660

Title:
  systemd-resolve breaks resolution of local network hostnames

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrading to Ubuntu 17.04 (zesty), resolution of my local
  network's host names is completely broken.  Apparently the upgrade
  replaced my existing resolver with systemd-resolve, which deliberately
  refuses to pass "single-label" domain names to my domain name server.
  That is the server where all my network's host names are kept, so I
  can no longer resolve any of them.

  Apparently, this is yet another example of Poettering's upstream decisions 
causing denial of service to people who have been saddled with his malware.
  https://github.com/systemd/systemd/issues/2514#issuecomment-179203186

  Would someone sensible please put a stop to this forced breakage
  during upgrade, and advise on how to fix it now that the damage has
  been done?

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

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

[Touch-packages] [Bug 1528173] Re: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface

[Forest Bond]

I'm actually a bit confused -- the bug status is "fix released" but it
is not at all clear to me in what Ubuntu release this fix has been
applied.  Can someone clarify this for me?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1528173

Title:
  org.freedesktop.DBus.Properties.GetAll fails always for
  fi.w1.wpa_supplicant1.Interface interface

Status in wpa package in Ubuntu:
  Fix Released

Bug description:
  With our package for wpa-supplicant a call

  $ sudo gdbus call -y -d fi.w1.wpa_supplicant1 -o
  /fi/w1/wpa_supplicant1/Interfaces/1 -m
  org.freedesktop.DBus.Properties.GetAll
  'fi.w1.wpa_supplicant1.Interface'

  fails always with

  Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No readable
  properties in this interface

  The reason for this is that the internal properties getter routine
  will never return any result when one internal getter fails.

  The responsible property here is the "Stations" one which was added by
  a patch in Ubuntu and is not available upstream. Take a look at
  https://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/wily/wpa/wily/view/head:/debian/patches/dbus-
  available-sta.patch

  The getter method wpas_dbus_getter_stas expects the ap_iface element
  to be see which isn't always the case and if that isn't true it will
  return false and causes the whole Properties.GetAll call to fail.

  The expected result is that the getter just returns an empty list if
  it can't determine the actual value.

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

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

[Touch-packages] [Bug 1528173] Re: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface

[Forest Bond]

This bug completely breaks WiFi support on my system using ConnMan. Took
a bit to hunt down and I also wrote my own patch before finding this bug
report. Can we please get this fix pushed out?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1528173

Title:
  org.freedesktop.DBus.Properties.GetAll fails always for
  fi.w1.wpa_supplicant1.Interface interface

Status in wpa package in Ubuntu:
  Fix Released

Bug description:
  With our package for wpa-supplicant a call

  $ sudo gdbus call -y -d fi.w1.wpa_supplicant1 -o
  /fi/w1/wpa_supplicant1/Interfaces/1 -m
  org.freedesktop.DBus.Properties.GetAll
  'fi.w1.wpa_supplicant1.Interface'

  fails always with

  Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No readable
  properties in this interface

  The reason for this is that the internal properties getter routine
  will never return any result when one internal getter fails.

  The responsible property here is the "Stations" one which was added by
  a patch in Ubuntu and is not available upstream. Take a look at
  https://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/wily/wpa/wily/view/head:/debian/patches/dbus-
  available-sta.patch

  The getter method wpas_dbus_getter_stas expects the ap_iface element
  to be see which isn't always the case and if that isn't true it will
  return false and causes the whole Properties.GetAll call to fail.

  The expected result is that the getter just returns an empty list if
  it can't determine the actual value.

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

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

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

Problem still exists in Ubuntu 16.10.

** Summary changed:

- starting any container with umask 007 breaks lxc-stop and prevents host 
system shutdown
+ starting any container with umask 007 breaks host system shutdown. lxc-stop 
just hangs.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks host system shutdown.
  lxc-stop just hangs.

Status in lxc package in Ubuntu:
  New

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71

  When system shutdown hangs, similar messages appear on the console
  every couple of minutes.

  I can reproduce this at will with a freshly-installed and fully-
  updated host OS in VirtualBox, and with either an old-ish container or
  a new one.

  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.

  My containers are all unprivileged.

  My umask at container creation time does not seem to matter.  As far
  as I have seen, my umask only matters the first time I start a
  container in my login session.

  I can work around the bug by manually setting my umask to something
  more permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

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

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

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

I reproduced it with the latest mainline kernel as well:

Linux xenialbox 4.9.0-040900rc6-generic #201611201731 SMP Sun Nov 20
22:33:21 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Here's the slightly different syslog output:

Nov 22 14:36:55 xenialbox kernel: [  484.506570] INFO: task systemd:3086 
blocked for more than 120 seconds.
Nov 22 14:36:55 xenialbox kernel: [  484.506578]   Not tainted 
4.9.0-040900rc6-generic #201611201731
Nov 22 14:36:55 xenialbox kernel: [  484.506579] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 22 14:36:55 xenialbox kernel: [  484.506582] systemd D0  3086   
3076 0x0104
Nov 22 14:36:55 xenialbox kernel: [  484.506589]  8eaa1810bc00 
8eaa58f4d800 8eaa57f59d00 8eaa5fc19340
Nov 22 14:36:55 xenialbox kernel: [  484.506593]  8eaa54bec880 
9bab80f17b78 8bc87183 8c244480
Nov 22 14:36:55 xenialbox kernel: [  484.506596]  00ff8eaa57f59d00 
8eaa5fc19340  8eaa57f59d00
Nov 22 14:36:55 xenialbox kernel: [  484.506600] Call Trace:
Nov 22 14:36:55 xenialbox kernel: [  484.506622]  [] ? 
__schedule+0x233/0x6e0
Nov 22 14:36:55 xenialbox kernel: [  484.506626]  [] 
schedule+0x36/0x80
Nov 22 14:36:55 xenialbox kernel: [  484.506629]  [] 
rwsem_down_write_failed+0x20a/0x380
Nov 22 14:36:55 xenialbox kernel: [  484.506634]  [] ? 
kvm_sched_clock_read+0x1e/0x30
Nov 22 14:36:55 xenialbox kernel: [  484.506643]  [] ? 
kernfs_sop_show_options+0x40/0x40
Nov 22 14:36:55 xenialbox kernel: [  484.506651]  [] 
call_rwsem_down_write_failed+0x17/0x30
Nov 22 14:36:55 xenialbox kernel: [  484.506655]  [] 
down_write+0x2d/0x40
Nov 22 14:36:55 xenialbox kernel: [  484.506658]  [] 
grab_super+0x30/0xa0
Nov 22 14:36:55 xenialbox kernel: [  484.506661]  [] 
sget_userns+0x18f/0x4d0
Nov 22 14:36:55 xenialbox kernel: [  484.506663]  [] ? 
kernfs_sop_show_path+0x50/0x50
Nov 22 14:36:55 xenialbox kernel: [  484.50]  [] 
kernfs_mount_ns+0x7e/0x230
Nov 22 14:36:55 xenialbox kernel: [  484.506674]  [] 
cgroup_mount+0x328/0x840
Nov 22 14:36:55 xenialbox kernel: [  484.506679]  [] ? 
alloc_pages_current+0x95/0x140
Nov 22 14:36:55 xenialbox kernel: [  484.506682]  [] 
mount_fs+0x38/0x150
Nov 22 14:36:55 xenialbox kernel: [  484.506686]  [] 
vfs_kern_mount+0x67/0x110
Nov 22 14:36:55 xenialbox kernel: [  484.506688]  [] 
do_mount+0x1e1/0xcb0
Nov 22 14:36:55 xenialbox kernel: [  484.506691]  [] ? 
__check_object_size+0xff/0x1d6
Nov 22 14:36:55 xenialbox kernel: [  484.506695]  [] ? 
kmem_cache_alloc_trace+0xd7/0x190
Nov 22 14:36:55 xenialbox kernel: [  484.506697]  [] 
SyS_mount+0x83/0xd0
Nov 22 14:36:55 xenialbox kernel: [  484.506700]  [] 
do_syscall_64+0x5b/0xc0
Nov 22 14:36:55 xenialbox kernel: [  484.506702]  [] 
entry_SYSCALL64_slow_path+0x25/0x25

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

Linux xenialbox 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71

  When system shutdown hangs, similar messages appear on the console
  every couple of minutes.

  I can reproduce this at will with a freshly-installed and fully-
  updated host OS in VirtualBox, and with either an old-ish container or
  a new one.

  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.

  My containers are all unprivileged.

  My umask at container creation time does not seem to matter.  As far
  as I have seen, my umask only matters the first time I start a
  container in my login session.

  I can work around the bug by manually setting my umask to something
  more permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

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

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

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

** Description changed:

- If I run lxc-start with umask 007 (or any other value that masks the
- world-execute bit), my host system enters a state with the following
- problems:
+ If I have umask 007 (or any other value that masks the world-execute
+ bit) when I run lxc-start for the first time after logging in, my host
+ system enters a state with the following problems:
  
  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
- * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.
+ * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.
  
  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:
  
  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71
  
  When system shutdown hangs, similar messages appear on the console every
  couple of minutes.
  
  I can reproduce this at will with a freshly-installed and fully-updated
  host OS in VirtualBox, and with either an old-ish container or a new
  one.
  
  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.
  
  My containers are all unprivileged.
  
  My umask at container creation time does not seem to matter.  As far as
  I have seen, my umask only matters the first time I start a container in
  my login session.
  
  I can work around the bug by manually setting my umask to something more
  permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

** Description changed:

  If I run lxc-start with umask 007 (or any other value that masks the
  world-execute bit), my host system enters a state with the following
  problems:
  
  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.
  
  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:
  
  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71
  
  When system shutdown hangs, similar messages appear on the console every
  couple of minutes.
  
+ I can reproduce this at will with a freshly-installed and fully-updated
+ host OS in VirtualBox, and with either an old-ish container or a new
+ one.
+ 
  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.
  
  My containers are all unprivileged.
- 
- I can reproduce this at will with a freshly installed host OS in
- VirtualBox, and with either an old-ish container or a new one.
  
  My umask at container creation time does not seem to matter.  As far as
  I have seen, my umask only matters the first time I start a container in
  my login session.
  
  I can work around the bug by manually setting my umask to something more
  permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

** Description changed:

  If I run lxc-start with umask 007 (or any other value that masks the
  world-execute bit), my host system enters a state with the following
  problems:
  
  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.
  
  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:
  
  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71
  
  When system shutdown hangs, similar messages appear on the console every
  couple of minutes.
  
  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.
  
  My containers are all unprivileged.
  
- I can reproduce this at will with either an old-ish container or a fresh
- new one.
+ I can reproduce this at will with a freshly installed host OS in
+ VirtualBox, and with either an old-ish container or a new one.
  
  My umask at container creation time does not seem to matter.  As far as
  I have seen, my umask only matters the first time I start a container in
  my login session.
  
  I can work around the bug by manually setting my umask to something more
  permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I run lxc-start with umask 007 (or any other value that masks the
  world-execute bit), my host system enters a state with the following
  problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 

[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

Possibly related: when the problem is triggered, I notice that my guest
instances start with no /etc/resolv.conf and no inet address.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I run lxc-start with umask 007 (or any other value that masks the
  world-execute bit), my host system enters a state with the following
  problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71

  When system shutdown hangs, similar messages appear on the console
  every couple of minutes.

  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.

  My containers are all unprivileged.

  I can reproduce this at will with either an old-ish container or a
  fresh new one.

  My umask at container creation time does not seem to matter.  As far
  as I have seen, my umask only matters the first time I start a
  container in my login session.

  I can work around the bug by manually setting my umask to something
  more permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

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

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

[Touch-packages] [Bug 1642767] [NEW] starting any container with umask 007 breaks lxc-stop and prevents host system shutdown

[Forest]

Public bug reported:

If I run lxc-start with umask 007 (or any other value that masks the
world-execute bit), my host system enters a state with the following
problems:

* lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
* lxc-stop --kill --nolock hangs in the same way.
* Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.

When lxc-stop hangs, messages like these appear in syslog every couple
of minutes:

Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked 
for more than 120 seconds.
Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE   
4.4.0-47-generic #68-Ubuntu
Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71

When system shutdown hangs, similar messages appear on the console every
couple of minutes.

I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
amd64.

My containers are all unprivileged.

I can reproduce this at will with either an old-ish container or a fresh
new one.

My umask at container creation time does not seem to matter.  As far as
I have seen, my umask only matters the first time I start a container in
my login session.

I can work around the bug by manually setting my umask to something more
permissive before I start my first container of the day, and then
setting it back again, but that's rather a hassle.  (Even worse, it's
very easy to forget this workaround and be left with containers that
can't be stopped and a host system that won't shut down cleanly.)

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1642767

Title:
  starting any container with umask 007 breaks lxc-stop and prevents
  host system shutdown

Status in lxc package in Ubuntu:
  New

Bug description:
  If I run lxc-start with umask 007 (or any other value that masks the
  world-execute bit), my host system enters a state with the following
  problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down my host system fail, requiring a hard reset 
to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644] 

[Touch-packages] [Bug 1576454] [NEW] Superfluous Xsession.d script: 60x11-common_localhost

[Forest]

Public bug reported:

Both of these scripts do the same thing, and both are installed by
x11-common:

/etc/X11/Xsession.d/35x11-common_xhost-local
/etc/X11/Xsession.d/60x11-common_localhost

35x11-common_xhost-local is present in debian, while
60x11-common_localhost is not. I suspect the latter should be removed.

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

** Summary changed:

- Duplicate Xsession.d script: 60x11-common_localhost
+ Superfluous Xsession.d script: 60x11-common_localhost

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1576454

Title:
  Superfluous Xsession.d script: 60x11-common_localhost

Status in xorg package in Ubuntu:
  New

Bug description:
  Both of these scripts do the same thing, and both are installed by
  x11-common:

  /etc/X11/Xsession.d/35x11-common_xhost-local
  /etc/X11/Xsession.d/60x11-common_localhost

  35x11-common_xhost-local is present in debian, while
  60x11-common_localhost is not. I suspect the latter should be removed.

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

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

[Touch-packages] [Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

[Forest]

Chris, I have no way to test this, because I no longer have a filesystem
with multiply-claimed blocks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1321418

Title:
  fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

Status in e2fsprogs package in Ubuntu:
  Invalid
Status in e2fsprogs source package in Precise:
  Fix Committed
Status in e2fsprogs source package in Trusty:
  Fix Committed

Bug description:
  [SRU justification]

  [Impact]

  The last few times my root ext4 filesystem had its regularly-scheduled
  boot-time check, errors were reported. The first time it happened, I
  simply told the system to fix the errors, but since they kept coming
  up again, I decided to look more closely. I booted from a live USB
  drive, assembled my raid partitions, and ran fsck.ext4 manually.

  Without any options, fsck.ext4 simply reported that the filesystem was
  clean, and exited. Things got more interesting when I ran with -f. It
  reported several multiply-claimed blocks, and when I told fsck to go
  ahead and clone them, it failed with an internal error. Repeated runs
  of fsck revealed that the filesystem was still not fixed, and repeated
  attempts to fix the problem also failed, reporting that multiply-
  claimed blocks already reassigned or cloned.

  I was lucky in that the files in question were unimportant, so
  deleting one of them and running fsck again seems to have fixed my
  problem this time. However, fsck's internal error and failure to fix
  the problem in the first place is worrisome.

  [Test Case]

  Here's the full output:

  $ sudo fsck.ext4 -f /dev/md/1
  e2fsck 1.42.8 (20-Jun-2013)
  Pass 1: Checking inodes, blocks, and sizes

  Running additional passes to resolve blocks claimed by more than one inode...
  Pass 1B: Rescanning for multiply-claimed blocks
  Multiply-claimed block(s) in inode 27528089: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Multiply-claimed block(s) in inode 27528105: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D:
  Reconciling multiply-claimed blocks
  (There are 2 inodes containing multiply-claimed blocks.)

  File
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
    has 7 multiply-claimed block(s), shared with 1 file(s):
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
  Clone multiply-claimed blocks? yes
  clone_file_block: internal error: can't find dup_blk for 73467268

  clone_file_block: internal error: can't find dup_blk for 73467268

  File
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
    has 7 multiply-claimed block(s), shared with 1 file(s):
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
  Multiply-claimed blocks already reassigned or cloned.

  Pass 2: Checking directory structure
  Pass 3: Checking directory connectivity
  Pass 4: Checking reference counts
  Pass 5: Checking group summary information

  root: * FILE SYSTEM WAS MODIFIED *
  root: 1038356/30285824 files (0.3% non-contiguous), 106319516/121119454 blocks

  [Regression Potential]

  [Other Info]

  backported from upstream
  
https://kernel.googlesource.com/pub/scm/fs/ext2/e2fsprogs/+/9a1d614df217c02ea6b2cb0072fccfe706aea111
  
https://kernel.googlesource.com/pub/scm/fs/ext2/e2fsprogs/+/84397754250d13e8596dd68c157c4c9863800079%5E%21/#F0

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

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

[Touch-packages] [Bug 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)

[Forest]

I also created an upstream bug report against the Tango icon theme,
mainly to get more eyes on the problem. Honestly, though, I don't expect
every icon theme developer will want to to modify their software in
order to compensate for something that was broken by an Ubuntu-specific
patch.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/772709

Title:
  Network Manager Icon Is not changin when VPN is connected (nm-device-
  wired-secure icon is missing)

Status in GNOME Icon Theme:
  New
Status in tango-icon-theme:
  Confirmed
Status in elementary-icon-theme package in Ubuntu:
  Confirmed
Status in gnome-icon-theme package in Ubuntu:
  Confirmed
Status in lubuntu-artwork package in Ubuntu:
  Fix Released
Status in network-manager-applet package in Ubuntu:
  Confirmed
Status in tango-icon-theme package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: gnome-icon-theme

  Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works 
fine) is see bad icons when connecting VPN and VPN is connected.
  Connected VPN icon is the same as original Network Manager. And connectin 
icon doen't show the Network manager icon only the flashing yellow lock (that 
must be over network manger icon)

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gnome-icon-theme 2.31.0-0ubuntu2
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Apr 29 01:05:10 2011
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-icon-theme
  UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+subscriptions

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

[Touch-packages] [Bug 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)

[Forest]

** Changed in: network-manager-applet (Ubuntu)
   Status: Invalid => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/772709

Title:
  Network Manager Icon Is not changin when VPN is connected (nm-device-
  wired-secure icon is missing)

Status in GNOME Icon Theme:
  New
Status in tango-icon-theme:
  Confirmed
Status in elementary-icon-theme package in Ubuntu:
  Confirmed
Status in gnome-icon-theme package in Ubuntu:
  Confirmed
Status in lubuntu-artwork package in Ubuntu:
  Fix Released
Status in network-manager-applet package in Ubuntu:
  Confirmed
Status in tango-icon-theme package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: gnome-icon-theme

  Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works 
fine) is see bad icons when connecting VPN and VPN is connected.
  Connected VPN icon is the same as original Network Manager. And connectin 
icon doen't show the Network manager icon only the flashing yellow lock (that 
must be over network manger icon)

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gnome-icon-theme 2.31.0-0ubuntu2
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Apr 29 01:05:10 2011
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-icon-theme
  UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+subscriptions

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

[Touch-packages] [Bug 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)

[Forest]

Removing nm-applet-use-indicator.patch (and refreshing the patches that
depend on it) fixes this in Xubuntu. In other words, that patch causes
the regression.

I'm removing the invalid status on network-manager-applet (Ubuntu), in
hopes of getting someone to reevaluate this. If Ubuntu maintainers are
going to patch in special functionality just for Unity, how about doing
it without breaking things?

(This is not the first time a patch intended to make a package use
Unity's Application Indicators has broken the package for Xubuntu and
other desktops. I really wish the people responsible would be more
careful.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/772709

Title:
  Network Manager Icon Is not changin when VPN is connected (nm-device-
  wired-secure icon is missing)

Status in GNOME Icon Theme:
  New
Status in tango-icon-theme:
  Confirmed
Status in elementary-icon-theme package in Ubuntu:
  Confirmed
Status in gnome-icon-theme package in Ubuntu:
  Confirmed
Status in lubuntu-artwork package in Ubuntu:
  Fix Released
Status in network-manager-applet package in Ubuntu:
  Confirmed
Status in tango-icon-theme package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: gnome-icon-theme

  Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works 
fine) is see bad icons when connecting VPN and VPN is connected.
  Connected VPN icon is the same as original Network Manager. And connectin 
icon doen't show the Network manager icon only the flashing yellow lock (that 
must be over network manger icon)

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gnome-icon-theme 2.31.0-0ubuntu2
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Apr 29 01:05:10 2011
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-icon-theme
  UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+subscriptions

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

[Touch-packages] [Bug 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)

[Forest]

Also, this is a security problem. It robs the user of the ability to
easily see that the VPN is (still) connected. If the VPN goes down, and
the user doesn't happen to see the momentary pop-up message (or if that
message has been accidentally or deliberately suppressed), the user will
think his communications are encrypted when they are actually exposed.

It can easily be exploited:
1. Distract the user or wait until he looks away from his screen.
2. Interfere with the internet connection for a few seconds, causing the user's 
VPN to fail.
3. Capture the user's packets.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/772709

Title:
  Network Manager Icon Is not changin when VPN is connected (nm-device-
  wired-secure icon is missing)

Status in GNOME Icon Theme:
  New
Status in tango-icon-theme:
  Confirmed
Status in elementary-icon-theme package in Ubuntu:
  Confirmed
Status in gnome-icon-theme package in Ubuntu:
  Confirmed
Status in lubuntu-artwork package in Ubuntu:
  Fix Released
Status in network-manager-applet package in Ubuntu:
  Confirmed
Status in tango-icon-theme package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: gnome-icon-theme

  Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works 
fine) is see bad icons when connecting VPN and VPN is connected.
  Connected VPN icon is the same as original Network Manager. And connectin 
icon doen't show the Network manager icon only the flashing yellow lock (that 
must be over network manger icon)

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gnome-icon-theme 2.31.0-0ubuntu2
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Apr 29 01:05:10 2011
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-icon-theme
  UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+subscriptions

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

[Touch-packages] [Bug 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)

[Forest]

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

** Also affects: tango-icon-theme via
   https://bugs.freedesktop.org/show_bug.cgi?id=91887
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-icon-theme in
Ubuntu.
https://bugs.launchpad.net/bugs/772709

Title:
  Network Manager Icon Is not changin when VPN is connected (nm-device-
  wired-secure icon is missing)

Status in GNOME Icon Theme:
  New
Status in tango-icon-theme:
  Unknown
Status in elementary-icon-theme package in Ubuntu:
  Confirmed
Status in gnome-icon-theme package in Ubuntu:
  Confirmed
Status in lubuntu-artwork package in Ubuntu:
  Fix Released
Status in network-manager-applet package in Ubuntu:
  Invalid
Status in tango-icon-theme package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: gnome-icon-theme

  Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works 
fine) is see bad icons when connecting VPN and VPN is connected.
  Connected VPN icon is the same as original Network Manager. And connectin 
icon doen't show the Network manager icon only the flashing yellow lock (that 
must be over network manger icon)

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: gnome-icon-theme 2.31.0-0ubuntu2
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Apr 29 01:05:10 2011
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-icon-theme
  UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+subscriptions

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

[Touch-packages] [Bug 1466587] [NEW] PackageKit doesn't respect phased updates

[Forest]

Public bug reported:

PackageKit-based tools, such as pkcon and pk-update-icon, do not respect
Ubuntu phased updates. As far as I can tell, they do not provide a way
to access or react to the Phased-Update-Percentage field in an apt
package index at all.

The result is that utilities based on PackageKit disagree with Ubuntu's
native tools about what packages are ready for update.

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to packagekit in Ubuntu.
https://bugs.launchpad.net/bugs/1466587

Title:
  PackageKit doesn't respect phased updates

Status in packagekit package in Ubuntu:
  New

Bug description:
  PackageKit-based tools, such as pkcon and pk-update-icon, do not
  respect Ubuntu phased updates. As far as I can tell, they do not
  provide a way to access or react to the Phased-Update-Percentage field
  in an apt package index at all.

  The result is that utilities based on PackageKit disagree with
  Ubuntu's native tools about what packages are ready for update.

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

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

[Touch-packages] [Bug 1389954] Re: Make .lxc domain name resolution easier to discover and enable

[Forest]

Here's a first attempt:
https://github.com/lxc/lxc-pkg-ubuntu/pull/2

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

[Touch-packages] [Bug 1389954] Re: Make .lxc domain name resolution easier to discover and enable

[Forest]

Okay, I've written up a short README.Debian describing the necessary
changes to /etc/default/lxc-net and the dnsmasq config file. I don't
remember what steps are necessary to make the domain names accessible,
though, and I'd like to include those steps in the readme.

Do I have to restart the lxc-net service? (And is that service called
the same thing regardless of whether sysv init, upstart, or systemd is
in use?)

Do I have to restart NetworkManager?

Do I have to restart any already-running containers?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

[Touch-packages] [Bug 1389954] Re: Make .lxc domain name resolution easier to discover and enable

[Forest]

Which branch?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

Re: [Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems

[Forest]

On Mon, 13 Apr 2015 13:32:15 -, Robie Basak wrote:

A release
upgrade should not cause biosdevname to get installed. So can you (or
someone) please confirm that this is definitely the behaviour in some
case,

It has now been most of a year since I filed the bug report, so as you might
imagine, I no longer remember the details of the upgrade that prompted it.
Here's what I know:

On the system in question, eth0 disappeared and was replaced by
psomethingpsomething.

The main.log files under /var/log/dist-upgrade include lsb-release: quantal,
raring, and saucy. The currently-installed release is trusty.  This implies
that the steps to reproduce include one or more of those distribution
upgrades.  I guess precise must have been the first-installed release.

Although I don't know when biosdevname was first installed, it is listed in
the Upgrade: log entries of all the /var/log/dist-upgrade/date/main.log
files, including one from a year before my bug report.  I suppose that means
biosdevname was likely installed by some earlier release, rather than being
newly installed during the problematic dist-upgrade.

The motherboard's chipset is an Intel Z77 Express. The ethernet device uses
a Realtek RTL8111/8168/8411 series chip. The r8169 kernel driver is
currently in use.

and if so provide steps to reproduce so that we can understand the
mechanism involved here that is making this happen?

Sorry, but I already spent too much time on this issue when it bit me in the
first place.  Reproducing it to determine step-by-step instructions would
require taking the computer out of service, saving all of its data and
state, taking it through several install and upgrade cycles, and then
restoring everything.  That is far more disruption and time than I can
spare.

Second, you say that some distributions require both systemd and
biosdevname interface renaming to be disabled. My understanding is that
on Ubuntu with systemd (so Vivid only), we do not rename interfaces via
systemd by default - this must be done explicitly. Can we assume for the
rest of the discussion that this is true, or otherwise can you provide
steps to reproduce that demonstrate that it is not (again, another bug
might be a good idea to avoid cluttering this one)?

That's quite possible.  It has been most of a year since I wrote that text,
but I probably meant to include non-ubuntu distros when I wrote some
distributions.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1347859

Title:
  Introduction of Predictable Network Interface Names (aka biosdevname)
  breaks working systems

Status in biosdevname package in Ubuntu:
  Opinion
Status in ubuntu-meta package in Ubuntu:
  New
Status in udev package in Ubuntu:
  Opinion

Bug description:
  Relatively recent linux distribution upgrades have been causing
  computers' ethernet devices to be unexpectedly renamed. While I
  understand that consistent device naming solves problems on some
  systems (mostly multi-NIC servers and a few specialty embedded
  devices), unilaterally forcing these changes on everyone is causing a
  lot of frustration. Here are some of the problems I've encountered:

  Interface names that were easily recognized as abbreviations for their
  device type have been replaced by cryptic names that have no obvious
  meaning whatsoever. It's easy to guess that eth0 is short for ethernet
  #0. What the heck is p4p1 supposed to mean? How is a human supposed to
  guess that the first p stands for PCI slot, that the second p stands
  for port number, and that the whole mysterious string represents an
  ethernet interface? This new naming convention is inferior to the old
  one in at least one significant respect: it makes things more
  difficult to understand.

  One of the more useful examples of consistency that unix-like systems
  have enjoyed for decades has been thrown out: the extremely well-known
  ethernet device names. This creates yet another hurtle for users and
  admins when switching between different operating systems or trying to
  apply general-purpose unix knowledge.

  A lot of documentation has been broken. I have no idea how many
  manuals, forum posts, bug reports, printed instructions, email
  messages, personal notes, books, and other forms of documentation in
  the world refer to a unix ethernet device as eth0, but I'll bet the
  number is huge. All that valuable guidance has just been rendered
  misleading or even useless to anyone who doesn't keep up with the
  latest distribution-specific device naming experiments; in other
  words: the people who need it most.

  Well-established workflows have been broken. The change trips up users
  and admins who have for years been getting tasks done quickly with
  commands that they could recall and execute without a second thought.
  They are suddenly finding that their workflows no longer work. This
  

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

All I have is a couple of files that trigger the bug. Unfortunately, I
don't have the rights to post them publicly, and I haven't found a way
to extract a useful segment from them without remuxing (and hiding the
problem).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  Confirmed

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

I discovered the problem with Exaile, Totem, and Sound Converter. I
verified it and narrowed it down with gst-launch.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  Confirmed

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

** Patch added: 0010-flacparse-avoid-indefinite-search-for-frame-end.patch
   
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366258/+files/0010-flacparse-avoid-indefinite-search-for-frame-end.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  New

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

I have attached 3 upstream patches to fix the premature eos on some flac
files:

0010-flacparse-avoid-indefinite-search-for-frame-end.patch
0011-flacparse-additional-frame-crc-check.patch
0012-flacparse-additional-header-sanity-check.patch

These are suitable for adding to the debian/patches directory (and
series file) of gst-plugins-good0.10-0.10.31.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  New

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

** Patch added: 0012-flacparse-additional-header-sanity-check.patch
   
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366260/+files/0012-flacparse-additional-header-sanity-check.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  New

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] [NEW] gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

Public bug reported:

Gstreamer 0.10 stops processing certain flac files before their end is
reached. When it happens, no error condition is reported. It fails
silently, as if the file was truncated.

This affects all applications that use gstreamer0.10-plugins-good,
including clementine, exaile, soundconverter, and many others.

Upstream git branch 0.10 has had patches since 2012 that seem to fix the
problem, but they have not yet made it into an official 0.10.x release.
The relevant changesets are:

5881603 flacparse: avoid indefinite extended search for frame end if possible
440d703 flacparse: perform additional frame crc check if applicable
32cddf6 flacparse: avoid some more frame misparsing by additional header sanity 
check

The fixes are present in gstreamer 1.0, but applications that still
depend on 0.10 (either directly or through python-gst) remain broken.
This seems like a good reason to apply the fixes to 0.10.

** Affects: gst-plugins-good0.10 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  New

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files

[Forest]

** Patch added: 0011-flacparse-additional-frame-crc-check.patch
   
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366259/+files/0011-flacparse-additional-frame-crc-check.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gst-plugins-good0.10 in
Ubuntu.
https://bugs.launchpad.net/bugs/1440440

Title:
  gstreamer 0.10 apps prematurely stop parsing some flac files

Status in gst-plugins-good0.10 package in Ubuntu:
  New

Bug description:
  Gstreamer 0.10 stops processing certain flac files before their end is
  reached. When it happens, no error condition is reported. It fails
  silently, as if the file was truncated.

  This affects all applications that use gstreamer0.10-plugins-good,
  including clementine, exaile, soundconverter, and many others.

  Upstream git branch 0.10 has had patches since 2012 that seem to fix
  the problem, but they have not yet made it into an official 0.10.x
  release. The relevant changesets are:

  5881603 flacparse: avoid indefinite extended search for frame end if possible
  440d703 flacparse: perform additional frame crc check if applicable
  32cddf6 flacparse: avoid some more frame misparsing by additional header 
sanity check

  The fixes are present in gstreamer 1.0, but applications that still
  depend on 0.10 (either directly or through python-gst) remain broken.
  This seems like a good reason to apply the fixes to 0.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+subscriptions

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

[Touch-packages] [Bug 1389954] Re: Make .lxc domain name resolution easier to discover and enable

[Forest]

Sure. Is this the right place?
https://github.com/lxc/lxc-pkg-ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

[Touch-packages] [Bug 1390792] Re: Synaptic Other Software tab jumps/scrolls to top when a repository check box is clicked

[Forest]

** Also affects: software-properties (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1390792

Title:
  Synaptic Other Software tab jumps/scrolls to top when a repository
  check box is clicked

Status in software-properties package in Ubuntu:
  New
Status in synaptic package in Ubuntu:
  New

Bug description:
  In Synaptic's Software  Updates window, clicking the check box for a
  repository in the Other Software tab causes the list of repositories
  to jump to the top of the list. The scroll position of the list is
  instantly lost, disorienting the user, and hiding the fact that the
  click did anything, until the user scrolls back down to find the item
  that was clicked.

  This is only noticeable when there are enough repositories in the list
  to require scrolling.

  Finding the clicked repository again is especially difficult when all of them 
look nearly identical, as is the case when they're all PPAs with no comment 
string. (Every item in the list is just a long URL that looks very similar to 
the others.) It's even worse when there are both package and
  source URLs for each repo.

  This is especially problematic when updating the repo URLs after a
  distribution upgrade, because it's a very repetitive task, and the
  scroll window jumps and loses its place every single time.

  Ubuntu 14.04.1 LTS
  synaptic 0.81.1ubuntu1 amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1390792/+subscriptions

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

[Touch-packages] [Bug 1389954] Re: Make .lxc domain name resolution easier to discover and enable

[Forest]

Thanks for taking an interest in the issue.

Since I filed this specifically against lxc in Ubuntu, wouldn't it make
sense to start by documenting the necessary config changes (including
NetworkManager's dnsmasq config, since it is part of Ubuntu by default)
in /usr/share/doc/lxc/README?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

[Touch-packages] [Bug 1389864] [NEW] /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system

[Forest]

Public bug reported:

The lxc package installs dnsmasq configuration as
/etc/dnsmasq.d-available/lxc, and a symlink to it is created at
/etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq
instance on systems running NetworkManager, because NetworkManager
starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d
instead.

This makes directing .lxc domain name lookups to the right place seem to
fail, which is how I noticed it.  I imagine it also leads to other
configurations not working as expected.

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

** Description changed:

  The lxc package installs dnsmasq configuration as
  /etc/dnsmasq.d-available/lxc, and a symlink to it is created at
- /etc/dnsmasq.d/lxc, but neither has any effect on systems running
- NetworkManager, because NetworkManager starts a dnsmasq instance that
- looks in /etc/NetworkManager/dnsmasq.d instead.
+ /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq
+ instance on systems running NetworkManager, because NetworkManager
+ starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d
+ instead.
  
  This makes directing .lxc domain name lookups to the right place seem to
- fail, and probably leads to other thinks not seeming to work as
- expected.
+ fail, which is how I noticed it.  I imagine it also leads to other
+ configurations not working as expected.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389864

Title:
  /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system

Status in “lxc” package in Ubuntu:
  New

Bug description:
  The lxc package installs dnsmasq configuration as
  /etc/dnsmasq.d-available/lxc, and a symlink to it is created at
  /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq
  instance on systems running NetworkManager, because NetworkManager
  starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d
  instead.

  This makes directing .lxc domain name lookups to the right place seem
  to fail, which is how I noticed it.  I imagine it also leads to other
  configurations not working as expected.

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

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

[Touch-packages] [Bug 1389954] [NEW] Make .lxc domain name resolution easier to discover and enable

[Forest]

Public bug reported:

The lxc package on ubuntu does almost nothing to help a user enable DNS
resolution for containers via dnsmaq, let alone discover that it is
possible. How about enabling it by default? I think all it would take is
adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/
and uncommenting LXC_DOMAIN=lxc in /etc/default/lxc-net.

Even if there's a good reason not to enable this by default, shouldn't
it at least be clearly documented someplace obvious instead of buried in
a system config file with a misleading comment that mentions the wrong
dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-
net does nothing on ubuntu desktop systems, because ubuntu's
NetworkManager starts dnsmasq with a special config directory.)

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

** Description changed:

  The lxc package on ubuntu does almost nothing to help a user enable DNS
  resolution for containers via dnsmaq, let alone discover that it is
  possible. How about enabling it by default? I think all it would take is
  adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/
  and uncommenting LXC_DOMAIN=lxc in /etc/default/lxc-net.
  
  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried in
  a system config file with a misleading comment that mentions the wrong
- dnsconf file to edit? (The dnsconf file path currently mentioned in
+ dnsmasq file to edit? (The dnsconf file path currently mentioned in
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  NetworkManager starts dnsconf with a special config directory.)

** Description changed:

  The lxc package on ubuntu does almost nothing to help a user enable DNS
  resolution for containers via dnsmaq, let alone discover that it is
  possible. How about enabling it by default? I think all it would take is
  adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/
  and uncommenting LXC_DOMAIN=lxc in /etc/default/lxc-net.
  
  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried in
  a system config file with a misleading comment that mentions the wrong
- dnsmasq file to edit? (The dnsconf file path currently mentioned in
- /etc/default/lxc-net does nothing on ubuntu desktop systems, because
- NetworkManager starts dnsconf with a special config directory.)
+ dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-
+ net does nothing on ubuntu desktop systems, because ubuntu's
+ NetworkManager starts dnsmasq with a special config directory.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1389954

Title:
  Make .lxc domain name resolution easier to discover and enable

Status in “lxc” package in Ubuntu:
  New

Bug description:
  The lxc package on ubuntu does almost nothing to help a user enable
  DNS resolution for containers via dnsmaq, let alone discover that it
  is possible. How about enabling it by default? I think all it would
  take is adding server=/lxc/10.0.3.1 to a file in
  /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN=lxc in
  /etc/default/lxc-net.

  Even if there's a good reason not to enable this by default, shouldn't
  it at least be clearly documented someplace obvious instead of buried
  in a system config file with a misleading comment that mentions the
  wrong dnsmasq file to edit? (The one currently mentioned by
  /etc/default/lxc-net does nothing on ubuntu desktop systems, because
  ubuntu's NetworkManager starts dnsmasq with a special config
  directory.)

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

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

[Touch-packages] [Bug 1286836] Re: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostp

[Forest]

For the record:

This happened to me during a distribution upgrade from 13.10 (saucy) to 14.04 
(trusty). When it happened, the release upgrade tool interrupted itself with a 
dialog box containing this alarming and not very helpful message:
Could not install the upgrades
The upgrade has aborted. Your system could be in an unusable state. A recovery 
will run now (dpkg --configure -a).

This dialog box was modal, preventing me from scrolling or copying the
text in the Terminal widget to see what really happened. The text
visible in the Terminal widget did not show up in any of the /var/log
/dist-upgrade/* logs, but it was clearly a python exception and stack
trace.

Upon closing the dialog box, the upgrade continued, contrary to what the
alarming message stated. (I guess the message was referring to one
particular package, not the overall release upgrade, but most end users
wouldn't know that, and even if they did the message didn't state which
package.)

As the upgrade continued, I was unable to copy  paste the stack trace
before it was pushed out of the Terminal widget's rather short scroll
buffer.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libav in Ubuntu.
https://bugs.launchpad.net/bugs/1286836

Title:
  package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to
  install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch:
  no) is not co-installable with libpostproc52 which has multiple
  installed instances

Status in “libav” package in Ubuntu:
  Confirmed
Status in “libpostproc” package in Ubuntu:
  Confirmed

Bug description:
   -

  ProblemType: Package
  DistroRelease: Ubuntu 14.04
  Package: libpostproc52 6:0.8.10-0ubuntu0.13.10.1
  ProcVersionSignature: Ubuntu 3.13.0-14.34-generic 3.13.5
  Uname: Linux 3.13.0-14-generic x86_64
  ApportVersion: 2.13.2-0ubuntu5
  Architecture: amd64
  Date: Mon Mar  3 00:57:47 2014
  Dependencies:
   gcc-4.9-base 4.9-20140222-0ubuntu1
   libavutil51 6:0.8.10-0ubuntu0.13.10.1 [origin: unknown]
   libc6 2.19-0ubuntu2
   libgcc1 1:4.9-20140222-0ubuntu1
   multiarch-support 2.19-0ubuntu2
  ErrorMessage: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not 
co-installable with libpostproc52 which has multiple installed instances
  InstallationDate: Installed on 2013-12-12 (79 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  SourcePackage: libav
  Title: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to 
install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not 
co-installable with libpostproc52 which has multiple installed instances
  UpgradeStatus: Upgraded to trusty on 2014-03-02 (0 days ago)

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

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

[Touch-packages] [Bug 1247719] Re: crackling, popping, clicking in playback to audigy2 surround51 device

[Forest]

** Tags added: regression-release saucy

** Tags added: trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1247719

Title:
  crackling, popping, clicking in playback to audigy2 surround51 device

Status in “alsa-driver” package in Ubuntu:
  New

Bug description:
  After upgrading from Xubuntu 13.04 to 13.10, I hear lots of popping
  (aka crackle, click noises) during playback to my Audigy2 surround51
  device.  This was never a problem before the upgrade.  The noises do
  not show up if I use the card's default, front, or rear devices
  instead, but those leave me without surround sound, so they're no good
  for movie playback.

  The same problem shows up on the surround40 device.  I haven't tried
  the other surround* devices.

  I can reproduce problem in Totem or gst-launch playbin with an .asoundrc 
containing this:
  pcm.!default {
  type plug
  slave.pcm surround51
  }

  I can reproduce problem in Exaile with the custom sink pipeline set to
  alsasink device=surround51 and no .asoundrc.

  I'm running the amd64 build of Xubuntu.

  My Audigy2 has the first alsa sound card slot, making it my default
  sound card.

  I am not using PulseAudio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1247719/+subscriptions

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

[Touch-packages] [Bug 1347859] [NEW] Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems

[Forest]

Public bug reported:

Relatively recent linux distribution upgrades have been causing
computers' ethernet devices to be unexpectedly renamed. While I
understand that consistent device naming solves problems on some systems
(mostly multi-NIC servers and a few specialty embedded devices),
unilaterally forcing these changes on everyone is causing a lot of
frustration. Here are some of the problems I've encountered:


Interface names that were easily recognized as abbreviations for their device 
type have been replaced by cryptic names that have no obvious meaning 
whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the 
heck is p4p1 supposed to mean? How is a human supposed to guess that the first 
p stands for PCI slot, that the second p stands for port number, and that 
the whole mysterious string represents an ethernet interface? This new naming 
convention is inferior to the old one in at least one significant respect: it 
makes things more difficult to understand.

One of the more useful examples of consistency that unix-like systems
have enjoyed for decades has been thrown out: the extremely well-known
ethernet device names. This creates yet another hurtle for users and
admins when switching between different operating systems or trying to
apply general-purpose unix knowledge.

A lot of documentation has been broken. I have no idea how many manuals,
forum posts, bug reports, printed instructions, email messages, personal
notes, books, and other forms of documentation in the world refer to a
unix ethernet device as eth0, but I'll bet the number is huge. All that
valuable guidance has just been rendered misleading or even useless to
anyone who doesn't keep up with the latest distribution-specific device
naming experiments; in other words: the people who need it most.

Well-established workflows have been broken. The change trips up users
and admins who have for years been getting tasks done quickly with
commands that they could recall and execute without a second thought.
They are suddenly finding that their workflows no longer work. This
interrupts tasks that should have been quick and easy, forcing people
figure out why known-good procedures are broken, think about how to
modify their memorized commands to work on the affected systems, and
train their fingers to type those new commands as quickly as they did
the old ones. Beyond being irritating, it can eat up a bunch of time
that some of us don't have to spare.

Working systems have been broken. Tools and automation scripts,
especially those developed for site-specific use, often make the
difference between a computer that does real work and a useless generic
OS installation. Sometimes they even make the difference between a
malfunctioning headless box that can be fixed over the network and an
expensive brick. It is quite common for such software to make some
minimal assumptions about its runtime environment, like assuming that
the name of the only network device that has ever been or will ever be
present will not suddenly change after being stable for months or years.
There are also applications (e.g. Matlab) and configuration files (e.g.
smb.conf, dhclient.conf, isc-dhcp-server) that might depend on
references to eth0. Renaming a critical and ubiquitous device like this
is so very likely to cause problems that it should never, ever be done
in an upgrade without the admin's explicit consent.

Sufficient warning of the change was not given. On one of my machines,
eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I
don't see any mention of it in the Trusty release notes, nor in any of
the notes for releases of the previous several years. Is it buried in
fine print someplace that I missed? Having to figure out for myself what
changed, why, and how to revert it (in multiple ways on each machine)
was a significant waste of my time. Multiply that by all the other
people who were affected similarly, and I'll bet we'd get an
embarrassing number of needlessly wasted person-months that could have
been saved with a simple announcement and link to documentation.


In short, the way this feature was forced on the world was an irresponsible 
blunder. It doesn't matter that the change was meant to address some other 
problem. Breaking working systems is far worse than allowing that problem to 
remain until someone opts in to a fix. This concept is so important that anyone 
who doesn't get it really has no business committing code to an operating 
system used by so many other people.

I am filing this bug report against multiple projects because more than
one is now overriding the kernel's device names, because each project
must be reconfigured in a different way in order to disable this
behavior, and because I believe the overall failure here lies not only
in careless feature implementation but also in careless deployment. If
the people involved in developing, integrating, testing, distributing,
and using this new behavior 

[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems

[Forest]

** Description changed:

  Relatively recent linux distribution upgrades have been causing
  computers' ethernet devices to be unexpectedly renamed. While I
  understand that consistent device naming solves problems on some systems
  (mostly multi-NIC servers and a few specialty embedded devices),
  unilaterally forcing these changes on everyone is causing a lot of
  frustration. Here are some of the problems I've encountered:
  
- 
- Interface names that were easily recognized as abbreviations for their device 
type have been replaced by cryptic names that have no obvious meaning 
whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the 
heck is p4p1 supposed to mean? How is a human supposed to guess that the first 
p stands for PCI slot, that the second p stands for port number, and that 
the whole mysterious string represents an ethernet interface? This new naming 
convention is inferior to the old one in at least one significant respect: it 
makes things more difficult to understand.
+ Interface names that were easily recognized as abbreviations for their
+ device type have been replaced by cryptic names that have no obvious
+ meaning whatsoever. It's easy to guess that eth0 is short for ethernet
+ #0. What the heck is p4p1 supposed to mean? How is a human supposed to
+ guess that the first p stands for PCI slot, that the second p stands
+ for port number, and that the whole mysterious string represents an
+ ethernet interface? This new naming convention is inferior to the old
+ one in at least one significant respect: it makes things more difficult
+ to understand.
  
  One of the more useful examples of consistency that unix-like systems
  have enjoyed for decades has been thrown out: the extremely well-known
  ethernet device names. This creates yet another hurtle for users and
  admins when switching between different operating systems or trying to
  apply general-purpose unix knowledge.
  
  A lot of documentation has been broken. I have no idea how many manuals,
  forum posts, bug reports, printed instructions, email messages, personal
  notes, books, and other forms of documentation in the world refer to a
  unix ethernet device as eth0, but I'll bet the number is huge. All that
  valuable guidance has just been rendered misleading or even useless to
  anyone who doesn't keep up with the latest distribution-specific device
  naming experiments; in other words: the people who need it most.
  
  Well-established workflows have been broken. The change trips up users
  and admins who have for years been getting tasks done quickly with
  commands that they could recall and execute without a second thought.
  They are suddenly finding that their workflows no longer work. This
  interrupts tasks that should have been quick and easy, forcing people
  figure out why known-good procedures are broken, think about how to
  modify their memorized commands to work on the affected systems, and
  train their fingers to type those new commands as quickly as they did
  the old ones. Beyond being irritating, it can eat up a bunch of time
  that some of us don't have to spare.
  
  Working systems have been broken. Tools and automation scripts,
  especially those developed for site-specific use, often make the
  difference between a computer that does real work and a useless generic
  OS installation. Sometimes they even make the difference between a
  malfunctioning headless box that can be fixed over the network and an
  expensive brick. It is quite common for such software to make some
  minimal assumptions about its runtime environment, like assuming that
  the name of the only network device that has ever been or will ever be
  present will not suddenly change after being stable for months or years.
  There are also applications (e.g. Matlab) and configuration files (e.g.
  smb.conf, dhclient.conf, isc-dhcp-server) that might depend on
  references to eth0. Renaming a critical and ubiquitous device like this
  is so very likely to cause problems that it should never, ever be done
  in an upgrade without the admin's explicit consent.
  
  Sufficient warning of the change was not given. On one of my machines,
  eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I
  don't see any mention of it in the Trusty release notes, nor in any of
  the notes for releases of the previous several years. Is it buried in
  fine print someplace that I missed? Having to figure out for myself what
  changed, why, and how to revert it (in multiple ways on each machine)
  was a significant waste of my time. Multiply that by all the other
  people who were affected similarly, and I'll bet we'd get an
  embarrassing number of needlessly wasted person-months that could have
  been saved with a simple announcement and link to documentation.
  
- 
- In short, the way this feature was forced on the world was an irresponsible 
blunder. It doesn't matter that the change was meant to address some other 

[Touch-packages] [Bug 1329274] Re: apt-get source fails to warn on unauthenticated packages

[Forest Bond]

Question: Why are --force-yes and --assume-yes not honored as they are
when checking authenticity of binaries?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1329274

Title:
  apt-get source fails to warn on unauthenticated packages

Status in APT:
  Fix Released
Status in “apt” package in Ubuntu:
  Fix Released
Status in “apt” source package in Lucid:
  Fix Released
Status in “apt” source package in Precise:
  Fix Released
Status in “apt” source package in Saucy:
  Fix Released
Status in “apt” source package in Trusty:
  Fix Released
Status in “apt” source package in Utopic:
  Fix Released

Bug description:
  apt-get source foo will not warn if the repository that foo belongs to
  has no signature attached.

  It should fails in this case - this is CVE-2014-0478

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

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