date:20191107

On Thu, 7 Nov 2019 at 20:05, Scott Moser  wrote:
>
> > > So that means we have this sequence of events:
> > >  a.) growpart change partition table
> > >  b.) growpart call partx
> > >  c.) udev created and events being processed
>
> > That is not true. whilst sfdisk is deleting, creating, finishing
> > partition table (a) and partx is called (b), udev events are already fired
> > and running in parallel and may complete against deleted, partially new,
> > completely new partition table, with or without partx completed.
>
> You're correct... I left out some 'events created and handled' after 'a'.
> But that doesn't change anything.  The problem we're seeing here is *not*
> that 'b' had any issue.
>
> >
> > No amount of settling for events will fix the fact that events were run
> > against racy state of the partition table _during_ sfdisk and partx calls.
>
> complete non-sense.  I dont care about any racy state *during* anything. I
> call 'udevadm settle'.  That means "block until stuff is done."  I think
> you're saying that I cannot:
>  1.) do something that causes udev events
>  2.) wait until all udev events caused by that something are finished
>
> if that is the case, then nothing ever can fix this, and we might as well
> go find jobs on a farm.
>

Both those thing happen, but udev events are started processing whilst
the partition table changes have not completed yet. This is what is
document in the sfdisk manpage as a know bug that nobody yet has
managed to figure out and derace.
Meaning if the udev events happened, and one waits to finish their
processing, there is no guarantee that they have been processed
against consistent disk state.

This is why sfdisk recommends taking flock. And this is why udev also
tries to take an flock.

In the past IBM has demonstrated a race similar to this one in
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1571707
where they tried to rapidly and in parallel partition 256 devices,
with only 89 of them successfully showing partitions after the limit
test is executed, and appear fully after a reboot in April 2016 on top
of Xenial.

-- 
Regards,

Dimitri.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to :

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

On Thu, 7 Nov 2019 at 17:50, Ryan Harper <1834...@bugs.launchpad.net> wrote:
>
> @ddstreet
>
> Yes, settle does not help.
>
> Re-triggering udevadm trigger --action=add /sys/class/block/sda
>
> Would re-run all of them after the partition change has occurred, which
> is what I'm currently suggesting as a heavy-handed workaround.
>
> I would like to understand *why* the udevd/kernel pair exhibits this
> racy behavior whereas other kernels/udevd from Bionic do not.
>

Just because a race is always won, doesn't mean it didn't always exist
;-)

-- 
Regards,

Dimitri.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1835738] Autopkgtest regression report (python3.6/3.6.9-1~18.04)

All autopkgtests for the newly accepted python3.6 (3.6.9-1~18.04) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

pybigwig/0.3.2-1ubuntu5 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#python3.6

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  Fix Committed
Status in python3.7 source package in Bionic:
  Fix Committed
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Committed

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-11-07 Thread Scott Dennis

Thanks for the fix. I tested it on my end and I confirmed this bug as
being fixed. I can now restart and shutdown via gdm.

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

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1847597] Re: gnome-control-center cannot access google account

2019-11-07 Thread Sebastien Bacher

The GNOME key expired this week, that's bug #1851564. The issue there is
older so it can't be the same issue

** Changed in: gnome-online-accounts
   Importance: Unknown => Undecided

** Changed in: gnome-online-accounts
 Remote watch: gitlab.gnome.org/GNOME/gnome-online-accounts/issues #42 => None

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

Title:
  gnome-control-center cannot access google account

Status in gnome-online-accounts:
  New
Status in gnome-online-accounts package in Ubuntu:
  Confirmed

Bug description:
  Good morning,

  If I run "gnome-control-center online-accounts" from the terminal and
  trying to add a Google account, I get this error: "Sign in with Google
  is temporarily disabled for this app. This app has not been verified
  yet by Google in order to use Google sign in". On the web, Google
  suggests to contact you, so here I am. Can you fix please? I would use
  my drive folders on my ubuntu 16.04. Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-online-accounts/+bug/1847597/+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 1847597] Re: gnome-control-center cannot access google account

2019-11-07 Thread Gunnar Hjalmarsson

** Changed in: gnome-online-accounts (Ubuntu)
   Status: Incomplete => Confirmed

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

Title:
  gnome-control-center cannot access google account

Status in gnome-online-accounts:
  New
Status in gnome-online-accounts package in Ubuntu:
  Confirmed

Bug description:
  Good morning,

  If I run "gnome-control-center online-accounts" from the terminal and
  trying to add a Google account, I get this error: "Sign in with Google
  is temporarily disabled for this app. This app has not been verified
  yet by Google in order to use Google sign in". On the web, Google
  suggests to contact you, so here I am. Can you fix please? I would use
  my drive folders on my ubuntu 16.04. Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-online-accounts/+bug/1847597/+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 1834875] Re: cloud-init growpart race with udev

> We can't know how many devices are in the system. It maybe nearly zero,
> it could be minutes.

I'm not suggesting you trigger uevents for all devices, just the one
you're repartitioning...

> The cold plug is required (initramfs may or maynot
> have ran
> scripts/udevd etc but kernel events already were emitted during initial
> boot and userspace isn't ready yet) and runs before cloud-init runs.

yes I know, my point was you appear concerned about the extra time of
retriggering a single device, while bootup retriggers all devices.

In any case, as I said in comment 57 - you appear to have things under
control, I was only curious if anyone had actually tested if simply
retriggering the repartitioned device does actually fix/workaround the
problem.  I'll step back out of this bug again. :)

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1668771] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1815101] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in Keepalived Charm:
  New
Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Triaged
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in heartbeat source package in Bionic:
  Triaged
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in heartbeat source package in Disco:
  Triaged
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in heartbeat source package in Eoan:
  Triaged
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining configuration at networkd
  restart, or losing network state at networkd stop.

  - Any regressions are most likely to occur during networkd start,
  restart, or stop, and most likely to involve missing or incorrect ip
  address(es).

  - the change is based in upstream patches adding the exact feature we
  needed to fix this issue & it will be integrated with a netplan change
  to add the needed stanza to systemd nic configuration file
  (KeepConfiguration=)

  [other info]

  original description:
  ---

  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  version: 2

[Touch-packages] [Bug 1835581] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000

  Now on the server, add a classless route:

  dhcp-option=121,0.0.0.0/0,10.10.0.1

  and restart dnsmasq on the server.  Then on the client, reboot.  It
  should now have:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3585sec preferred_lft 3585sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5

  Now, the global route will use the static address, not the dhcp-
  provided address:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000

  If the router, 10.10.0.1, only will forward traffic sent from the dhcp
  address it provided, 10.10.0.75, then this configuration will result
  in the client being unable to reach anything through the router,
  because all its packets will have a source address of 10.10.0.5, which
  the router would drop/reject.

  [regression potential]

  this only affects dhcp routes provided by a dhcp server using the
  'static' or 'classless' route dhcp options.  Since this behavior is
  currently the default when a system doesn't add static address(es) to
  interfaces that also get dhcp addresses, this is likely not a change
  in behavior for the vast

[Touch-packages] [Bug 1831787] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  Bogus routes after DHCP lease change

Status in netplan:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  networkd does not remove old route(s) after DHCP address change

  [test case]

  on a system using networkd, that is connected to a network where you
  can control the addresses that the DHCP server provides, setup system
  with networkd to get address via DHCP, e.g.

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  
  (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and 
corresponding route to the gateway.

  
  Then on the dhcp server, change the subnet to a different subnet.  On the 
client, once its renews its DHCP address, the server will provide a new address 
in the new subnet, and the client will add a new default route to the new 
gateway address.  However, the old default route to the old gateway address 
isn't removed.

  Note this also happens without changing the entire subnet, but is more
  subtle as shown in the original description.

  [regression potential]

  this affects how networkd handles routes, so has the potential to
  leave a system with partial or incorrect networking, or no networking
  at all.  Any regression would most likely occur during networkd
  (re)start or during renewal of a DHCP lease, or when an interface is
  brought up.

  [other info]

  original description:
  ---

  
  Netplan config:

  network:
    version: 2
    renderer: networkd
    ethernets:
  eno4:
    dhcp4: no
  eno1np0:
    dhcp4: no
    addresses:
  - 172.16.0.2/24
    bridges:
  br0:
    dhcp4: yes
    interfaces:
  - eno4

  On initial boot, machine got 10.0.15.109 IP address:

  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured
  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 
10.0.15.109/23 via 10.0.15.253

  At one point, DHCP server reserver this IP address and client
  eventually picked up new IP address:

  May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address
  10.0.15.128/23 via 10.0.15.253

  This resulted in IP addresses:

  # ip -o a
  1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
preferred_lft forever
  1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
forever
  2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\   
valid_lft forever preferred_lft forever
  2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \   valid_lft 
forever preferred_lft forever
  6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\   
valid_lft 503sec preferred_lft 503sec
  6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \   valid_lft 
forever preferred_lft forever

  So far, everything is fine. But, the routes on the machine are bogus:

  # ip r
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100
  10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100
  172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2

  routes with src 10.0.15.109 should have been removed when lease was
  renewed. I'm not sure if this is a bug in netplan or systemd. This is
  18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1831787/+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 1849658] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  resolved fallback to TCP fails for truncated UDP replies

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.
  For example 'host toomany.ddstreet.org'.

  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.

  [test case]

  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678

  ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  [regression potential]

  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for
  DNS requests or replies.

  [other info]

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

  The commit adding stream types is not present in x/b, so this is
  needed only for disco and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1847896] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1849608] Autopkgtest regression report (systemd/242-7ubuntu3.2)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.42.1-1ubuntu1 (amd64)
systemd/242-7ubuntu3.2 (ppc64el)
ndctl/unknown (armhf)
casper/1.427 (amd64)
netplan.io/0.98-0ubuntu1 (ppc64el)
munin/unknown (armhf)
linux-oem-osp1/5.0.0-1026.29 (amd64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  dhclient fails to notify resolved about DNS servers due to bash-
  specific redirect inside 'resolved' hook script

  [test case]

  see original description below

  [regression potential]

  any regression would likely cause resolved not to be aware of
  dhclient-provided dns servers

  [other info]

  This is needed only in Eoan and later; X/B/D do not have the bash-
  specific redirect '&>' in their hook file.

  original description:
  ---

  
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
    DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1851725] [NEW] NetworkManager forgets VPN credentials

2019-11-07 Thread Mathieu Tarral

Public bug reported:

Hi,

Since recently, I can't import a VPN connection in NetworkManager and store my 
credentials.
NetworkManager will systematically forget the password, despite a log entry 
confirming that the operation was a success:

nov. 07 22:26:52  NetworkManager[1518]:   [1573162012.8680]
audit: op="connection-update"
uuid="3f985155-4e20-4351-88d7-14d5909a2d03"
name="at-01.protonvpn.com.udp" args="vpn.secrets" pid=6379 uid=1000
result="success"

Please look at the video attached.

Please fix.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: network-manager 1.20.4-2ubuntu2
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov  7 22:22:00 2019
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2019-09-26 (42 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
IpRoute:
 default via 192.168.0.1 dev wlo1 proto dhcp metric 600 
 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
 192.168.0.0/24 dev wlo1 proto kernel scope link src 192.168.0.18 metric 600 
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm:
 RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  WIFI  
   WWAN-HW  WWAN
 running  1.20.4   connected  started  full  enabled enabled  
enabled  enabled  enabled

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


** Tags: amd64 apport-bug eoan

** Attachment added: "NetworkManager forget VPN password"
   
https://bugs.launchpad.net/bugs/1851725/+attachment/5303593/+files/network-manager-vpn-credentials.webm

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

Title:
  NetworkManager forgets VPN credentials

Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi,

  Since recently, I can't import a VPN connection in NetworkManager and store 
my credentials.
  NetworkManager will systematically forget the password, despite a log entry 
confirming that the operation was a success:

  nov. 07 22:26:52  NetworkManager[1518]:   [1573162012.8680]
  audit: op="connection-update"
  uuid="3f985155-4e20-4351-88d7-14d5909a2d03"
  name="at-01.protonvpn.com.udp" args="vpn.secrets" pid=6379 uid=1000
  result="success"

  Please look at the video attached.

  Please fix.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: network-manager 1.20.4-2ubuntu2
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Nov  7 22:22:00 2019
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2019-09-26 (42 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  IpRoute:
   default via 192.168.0.1 dev wlo1 proto dhcp metric 600 
   169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
   192.168.0.0/24 dev wlo1 proto kernel scope link src 192.168.0.18 metric 600 
   192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 
linkdown
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.20.4   connected  started  full  enabled enabled  
enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851725/+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 1847597] Re: gnome-control-center cannot access google account

2019-11-07 Thread Bug Watch Updater

** Changed in: gnome-online-accounts
   Status: Unknown => New

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

Title:
  gnome-control-center cannot access google account

Status in gnome-online-accounts:
  New
Status in gnome-online-accounts package in Ubuntu:
  Incomplete

Bug description:
  Good morning,

  If I run "gnome-control-center online-accounts" from the terminal and
  trying to add a Google account, I get this error: "Sign in with Google
  is temporarily disabled for this app. This app has not been verified
  yet by Google in order to use Google sign in". On the web, Google
  suggests to contact you, so here I am. Can you fix please? I would use
  my drive folders on my ubuntu 16.04. Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-online-accounts/+bug/1847597/+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 1848200] Re: gdb not stopping on breakpoint in a 32-bit program

2019-11-07 Thread Vladislav K. Valtchev

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

Thanks Miroslav for opening this bug, two weeks after me opening bug #1846557. 
Unfortunately, it took proving that gdb couldn't debug properly _any_ 32-bit 
program, not just kernels running on QEMU, in order to get some attention. 
Honestly, I didn't even thought the bug could be _that_ bad and I didn't test 
that simple scenario. I just assumed it worked.

But, certainly, just a simple question from any maintainer about this
use-case could have helped solving this bug much earlier and saving time
to all the people it affected. I mean, it's not disappointing that it
took one month to get a fix. If the bug affected only my scenario that
would had been fine. It's disappointing that even if there was a single
_small_ 100% guilty patch, in one month, bug #1846557 did not get a
_single_ technical comment/question. We could have discovered this
broader-scope bug much earlier. It's not about fixing any bug "right
now" (bugs have priority). It's about at least talking with the reporter
and don't underestimate the scope of the bug, even if it appears to be
narrow. It might not be.

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

Title:
  gdb not stopping on breakpoint in a 32-bit program

Status in gdb package in Ubuntu:
  Fix Released
Status in gdb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
  on breakpoint when running a 32-bit application (on 64-bit Ubuntu).

  [Test Case]
  This can be reproduced with a simple “hello world” program:

  $ cat hello.c
  #include 
  int main()
  {
     // printf() displays the string inside quotation
     printf("Hello, World!");
     return 0;
  }
  $ gcc -ggdb -m32 hello.c
  $ gdb a.out
  (gdb) b hello.c:5
  Breakpoint 1 at 0x536: file hello.c, line 5.
  (gdb) run
  Starting program: /home/user/sandbox/a.out
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.

  --- (and not stopping nor outputting the text…) ---

  [Regression Risk]
  Test case ran on arm64 and regression tested using the above test case on 
amd64, i386 and s390x.

  This regression was fixed on the upstream gdb-8.1 branch within a few
  weeks of the breakage back in May 2018. Since then there have been no
  other fixes in this area on that branch, implying this fixed the issue
  and there were no further regressions discovered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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 1834875] Re: cloud-init growpart race with udev

On Thu, Nov 7, 2019 at 2:41 PM Dan Streetman 
wrote:

> > Issuing a second
> > trigger will repeat this.
> > IMO, that's a non-zero amount of time that slows the boot down, so I'd
> like
> > to avoid that.
>
> systemd-udev-trigger.serivce retriggers *everything* at boot (except in
>
an unprivileged container where it can't), so I'm not sure how much
> added time we're talking about just for a single block device.


We can't know how many devices are in the system.  It maybe nearly zero,
it could be minutes.  The cold plug is required (initramfs may or maynot
have ran
scripts/udevd etc but kernel events already were emitted during initial
boot and userspace isn't ready yet) and runs before cloud-init runs.


> yeah, you need the kernel to send a uevent to udevd after the partition
> table is ready for udevd to read, or udevd won't get the right partition
> table info; whether you do some locking to try to block udevd from
> reading it or just retrigger an event after it's ready.
>

Generally yes; and what we still don;t know is why it's racing here but not
everywhere all the time.  Note that *growpart* runs on every single cloud
instance boot.  There's a _LOT_ of those;  something changed in udev/kernel
which is racing and it'd be good to track that bit down.


> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1834875
>
> Title:
>   cloud-init growpart race with udev
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions
>

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1851715] [NEW] Screen brightness adjustment delay

2019-11-07 Thread Phillip Prado

Public bug reported:

Every time I adjust my laptop's screen brightness using the dedicated
brightness keys, there is a substantial delay between when I press the
button and the screen adjusts. Sometimes it even "twitches" and
decreasing the brightness by tapping the button two times will quickly
drop the brightness all the way to the lowest setting after the delay
takes place. I've noticed the issue in the default Ubuntu session and in
my current vanilla gnome-session. It also doesn't matter which
extensions I have installed. The keys work flawlessly in Windows so it
isn't a hardware issue. I have been meaning to report this for a while
and have just never gotten around to it until just now.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: GNOME
Date: Thu Nov  7 14:37:43 2019
DistUpgraded: 2019-10-21 20:16:37,104 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
DistroCodename: eoan
DistroVariant: ubuntu
DkmsStatus: nvidia, 435.21, 5.3.0-19-generic, x86_64: installed
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA 
controller])
   Subsystem: Huawei Technologies Co., Ltd. UHD Graphics 620 [19e5:3e04]
   Subsystem: Huawei Technologies Co., Ltd. GP108M [GeForce MX150] [19e5:3e04]
InstallationDate: Installed on 2019-09-08 (59 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 05c8:03c0 Cheng Uei Precision Industry Co., Ltd 
(Foxlink) HD Camera
 Bus 001 Device 002: ID 8087:0a2b Intel Corp. 
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HUAWEI MACH-WX9
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic 
root=UUID=75fe2138-1abd-47b2-a73f-83280ff782ff ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to eoan on 2019-10-22 (16 days ago)
dmi.bios.date: 03/15/2019
dmi.bios.vendor: HUAWEI
dmi.bios.version: 1.28
dmi.board.name: MACH-WX9-PCB
dmi.board.vendor: HUAWEI
dmi.board.version: M14
dmi.chassis.type: 10
dmi.chassis.vendor: HUAWEI
dmi.chassis.version: M14
dmi.modalias: 
dmi:bvnHUAWEI:bvr1.28:bd03/15/2019:svnHUAWEI:pnMACH-WX9:pvrM14:rvnHUAWEI:rnMACH-WX9-PCB:rvrM14:cvnHUAWEI:ct10:cvrM14:
dmi.product.family: MateBook X
dmi.product.name: MACH-WX9
dmi.product.sku: C128
dmi.product.version: M14
dmi.sys.vendor: HUAWEI
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.1-1ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20190815-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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


** Tags: amd64 apport-bug eoan ubuntu

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

Title:
  Screen brightness adjustment delay

Status in xorg package in Ubuntu:
  New

Bug description:
  Every time I adjust my laptop's screen brightness using the dedicated
  brightness keys, there is a substantial delay between when I press the
  button and the screen adjusts. Sometimes it even "twitches" and
  decreasing the brightness by tapping the button two times will quickly
  drop the brightness all the way to the lowest setting after the delay
  takes place. I've noticed the issue in the default Ubuntu session and
  in my current vanilla gnome-session. It also doesn't matter which
  extensions I have installed. The keys work flawlessly in Windows so it
  isn't a hardware issue. I have been meaning to report this for a while
  and have just never gotten around to it until just now.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: GNOME
  Date: Thu Nov  7 14:37:43 2019
  DistUpgraded: 2019-10-21 20:16:37,104 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
  DistroCodename: eoan

[Touch-packages] [Bug 1851349] Re: Xorg freeze

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: xorg (Ubuntu)
   Status: New => Confirmed

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

Title:
  Xorg freeze

Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Installed Ubuntu 19.10. A short freeze or lag occurs with the cursor
  now and then. Problem with multitasking.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  BootLog: Error: [Errno 13] Åtkomst nekas: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Nov  5 10:29:50 2019
  DistUpgraded: Fresh install
  DistroCodename: eoan
  DistroVariant: ubuntu
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA 
controller])
 Subsystem: Dell UHD Graphics 620 [1028:0810]
  InstallationDate: Installed on 2019-10-18 (17 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: Dell Inc. Inspiron 5570
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=sv_SE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic 
root=UUID=234e65b3-5622-44ae-9ba5-5d8a799fd811 ro quiet splash
  SourcePackage: xorg
  Symptom: display
  Title: Xorg freeze
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/08/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.0.4
  dmi.board.name: 09YTN7
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X07
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.0.4:bd09/08/2017:svnDellInc.:pnInspiron5570:pvr:rvnDellInc.:rn09YTN7:rvrX07:cvnDellInc.:ct10:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 5570
  dmi.product.sku: 0810
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20190815-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1851349/+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 1850127] Re: Unable to print with Brother printer since upgrade to Ubuntu 19.10

2019-11-07 Thread Rudolf Leitgeb

I could resolve this issue by upgrading the printer firmware to latest
version 1.40. No idea, why Ubuntu 19.04 printed happily with older
printer firmware, but as of Ubuntu 19.10 new printer firmware (can be
installed through printer web interface) is needed.

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

Title:
  Unable to print with Brother printer since upgrade to Ubuntu 19.10

Status in cups package in Ubuntu:
  New

Bug description:
  I have recently bought a new color laser printer (Brother HL-
  L8260CDW), which is connected through wLAN. It works like a charm
  under Ubuntu 19.04, but refuses to print since the upgrade to stock
  Ubuntu 19.10. I can reach it via ping and through its HTTP config page
  from the same computer.

  During my collection of relevant bug information I discovered the
  following error messages:

  1. Some print filter was unable to grep 
/etc/cups/ppd/Brother_HL_L8260CDW_series.ppd
  This file was rw for user "root" and r for group "lp", but not accessible 
to others.
  I have made it world readable for testing purposes, but I still can't 
print.

  2. I checked /var/log/syslog for app-armour errors but found none which would 
be related
  to cups and/or printing

  3. After fixing the permission issue, the new error message is "File \'\' not 
found" and
  "Unable to add document to print job.", both of which are too cryptic for 
me to dig
  further into this by myself.

  
  Attached to this bug report I send the following pieces of information:
  - output from "/usr/lib/cups/backend/snmp 10.0.0.14" (snmp.txt)
  - output from "lpinfo -v" (lpinfo.txt)
  - output from "avahi-browse -a -v -t -r" and "avahi-browse -a -v -c -r" 
(avahi.txt)

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: cups 2.2.12-2ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CupsErrorLog:
   E [28/Oct/2019:10:40:04 +0100] [Job 112] File \'\' not found
   E [28/Oct/2019:10:40:12 +0100] [Job 112] Unable to add document to print job.
   E [28/Oct/2019:10:45:59 +0100] [Job 113] File \'\' not found
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Oct 28 10:50:05 2019
  InstallationDate: Installed on 2015-11-11 (1446 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  Lpstat: device for Brother_HL_L8260CDW_series: 
implicitclass://Brother_HL_L8260CDW_series/
  MachineType: MSI MS-7982
  Papersize: a4
  PpdFiles: Brother_HL_L8260CDW_series: HL-L8260CDW series - IPP Everywhere
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic 
root=UUID=64458150-bde5-4ffc-8eb1-038fae855347 ro quiet splash
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/08/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 3.10
  dmi.board.asset.tag: Default string
  dmi.board.name: B150M PRO-DH (MS-7982)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr3.10:bd07/08/2015:svnMSI:pnMS-7982:pvr1.0:rvnMSI:rnB150MPRO-DH(MS-7982):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.family: Default string
  dmi.product.name: MS-7982
  dmi.product.sku: Default string
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1850127/+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 1834875] Re: cloud-init growpart race with udev

On Thu, Nov 7, 2019 at 11:30 AM Dimitri John Ledkov 
wrote:

> > So that means we have this sequence of events:
> >  a.) growpart change partition table
> >  b.) growpart call partx
> >  c.) udev created and events being processed
>
> That is not true. whilst sfdisk is deleting, creating, finishing
> partition table (a) and partx is called (b), udev events are already
> fired and running in parallel and may complete against deleted,
> partially new, completely new partition table, with or without partx
> completed.
>

> No amount of settling for events will fix the fact that events were run
> against racy state of the partition table _during_ sfdisk and partx
> calls.
>

udevadm control --stop-exec-queue
sgdisk
partx
udevadm control --start-exec-queue

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1846557] Re: Unable to debug any kernel on i386 qemu machine

2019-11-07 Thread Vladislav K. Valtchev

A fix was released after bug #1848200, reporting the same problem, was
opened.

** Changed in: gdb (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  Unable to debug any kernel on i386 qemu machine

Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  Hi,
  On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu 
8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM 
(qemu-system-i386) by just doing the following:

  > target remote localhost:1234
  > b term.c:694

  and then, when the breakpoint was hit I used to observe output like:

  > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , 
use_alt_buffer=true)
  > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694

  And then I was able to do `s`, `si` or `c`, exactly like with regular
  user applications.

  With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, 
something is broken.
  By doing the same things I observe:

  > (gdb) b term.c:693
  > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe.

  Which seems (and actually is) a bad sign, for what comes later. [why
  do you need to change the address? why do you want to extend it to
  64-bit for a 32-bit machine?? mmm..]

  GDB detects the breakpoint, but in a weird way:

  Program received signal SIGTRAP, Trace/breakpoint trap.
  term_action_use_alt_buffer (t=0xc017514c , 
use_alt_buffer=true)

  At this point, I'm able to read the memory and the variables BUT, I
  cannot continue the execution, NOR doing any kind of step. The
  commands apparently don't get delivered to the remote side (QEMU), or
  they get delivered in a wrong way somehow. Example output:

  (gdb) b 709
  warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45.
  Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, 
line 709.
  (gdb) c
  Continuing.

  Program received signal SIGTRAP, Trace/breakpoint trap.
  term_action_use_alt_buffer (t=0xc017514c , 
use_alt_buffer=true)
  at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
  693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
  (gdb) c
  Continuing.

  Program received signal SIGTRAP, Trace/breakpoint trap.
  term_action_use_alt_buffer (t=0xc017514c , 
use_alt_buffer=true)
  at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
  693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
  (gdb) c
  Continuing.

  As you see, the whole QEMU VM is stuck until I quit GDB.

  Note: I downgraded exclusively GDB back to version 'Ubuntu
  8.1-0ubuntu3' in order to check if the problem would be fixed and it
  is. I'm sure the problem has been introduced in this specific version
  'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with
  the kernel that is being debugged. It's totally independent from that.

  Final remark: note that I'm running gdb on x86_64 machine, while I'm
  debugging a kernel running on a i386 (virtual) machine. I believe that
  the cross-arch scenario almost certainly has something to do with the
  bug, as it happened in the past on both sides (qemu and gdb).

  Thanks a lot,
  Vlad

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+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 1848200] Re: gdb not stopping on breakpoint in a 32-bit program

2019-11-07 Thread Vladislav K. Valtchev

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

** This bug has been marked a duplicate of bug 1846557
   Unable to debug any kernel on i386 qemu machine

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

Title:
  gdb not stopping on breakpoint in a 32-bit program

Status in gdb package in Ubuntu:
  Fix Released
Status in gdb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
  on breakpoint when running a 32-bit application (on 64-bit Ubuntu).

  [Test Case]
  This can be reproduced with a simple “hello world” program:

  $ cat hello.c
  #include 
  int main()
  {
     // printf() displays the string inside quotation
     printf("Hello, World!");
     return 0;
  }
  $ gcc -ggdb -m32 hello.c
  $ gdb a.out
  (gdb) b hello.c:5
  Breakpoint 1 at 0x536: file hello.c, line 5.
  (gdb) run
  Starting program: /home/user/sandbox/a.out
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.

  --- (and not stopping nor outputting the text…) ---

  [Regression Risk]
  Test case ran on arm64 and regression tested using the above test case on 
amd64, i386 and s390x.

  This regression was fixed on the upstream gdb-8.1 branch within a few
  weeks of the breakage back in May 2018. Since then there have been no
  other fixes in this area on that branch, implying this fixed the issue
  and there were no further regressions discovered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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 1834875] Re: cloud-init growpart race with udev

> Issuing a second
> trigger will repeat this.
> IMO, that's a non-zero amount of time that slows the boot down, so I'd like
> to avoid that.

systemd-udev-trigger.serivce retriggers *everything* at boot (except in
an unprivileged container where it can't), so I'm not sure how much
added time we're talking about just for a single block device.  But
yeah, you need the kernel to send a uevent to udevd after the partition
table is ready for udevd to read, or udevd won't get the right partition
table info; whether you do some locking to try to block udevd from
reading it or just retrigger an event after it's ready.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1847597] Re: gnome-control-center cannot access google account

2019-11-07 Thread Alan Pope  濾

I'm seeing the same error.

Steps to reproduce:

Open System Settings
Go to Online Accounts
Add a google account
Enter username / password

I then get the same dialog as the reporter of this bug.

I'm on Ubuntu 19.10.

This smacks of our online accounts api key being revoked / rate-limited
or otherwise restricted by Google.

** Attachment added: "Screenshot from 2019-11-07 20-13-19.png"

https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1847597/+attachment/5303569/+files/Screenshot%20from%202019-11-07%2020-13-19.png

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

Title:
gnome-control-center cannot access google account

Status in gnome-online-accounts:
Unknown
Status in gnome-online-accounts package in Ubuntu:
Incomplete

Bug description:
Good morning,

If I run "gnome-control-center online-accounts" from the terminal and
trying to add a Google account, I get this error: "Sign in with Google
is temporarily disabled for this app. This app has not been verified
yet by Google in order to use Google sign in". On the web, Google
suggests to contact you, so here I am. Can you fix please? I would use
my drive folders on my ubuntu 16.04. Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-online-accounts/+bug/1847597/+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 1847597] Re: gnome-control-center cannot access google account

2019-11-07 Thread Alan Pope  濾

I have tested with a second google account (my canonical one, as opposed
to my personal one) and get the exact same error.

** Bug watch added: gitlab.gnome.org/GNOME/gnome-online-accounts/issues #42
   https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/42

** Also affects: gnome-online-accounts via
   https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/42
   Importance: Unknown
   Status: Unknown

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

Title:
  gnome-control-center cannot access google account

Status in gnome-online-accounts:
  Unknown
Status in gnome-online-accounts package in Ubuntu:
  Incomplete

Bug description:
  Good morning,

  If I run "gnome-control-center online-accounts" from the terminal and
  trying to add a Google account, I get this error: "Sign in with Google
  is temporarily disabled for this app. This app has not been verified
  yet by Google in order to use Google sign in". On the web, Google
  suggests to contact you, so here I am. Can you fix please? I would use
  my drive folders on my ubuntu 16.04. Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-online-accounts/+bug/1847597/+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 1851714] Re: package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to install/upgrade: installed libssl1.1:i386 package post-installation script subprocess returned error exit s

2019-11-07 Thread Apport retracing service

** Tags removed: need-duplicate-check

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

Title:
  package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to
  install/upgrade: installed libssl1.1:i386 package post-installation
  script subprocess returned error exit status 128

Status in openssl package in Ubuntu:
  New

Bug description:
  on login to laptop.

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic i686
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: i386
  Date: Thu Nov  7 16:54:40 2019
  ErrorMessage: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
  InstallationDate: Installed on 2019-11-05 (1 days ago)
  InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 3.6.5-3
  PythonDetails: /root/Error: command ['which', 'python'] failed with exit code 
1:, Error: [Errno 2] No such file or directory: "/root/Error: command ['which', 
'python'] failed with exit code 1:": "/root/Error: command ['which', 'python'] 
failed with exit code 1:", unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.1
  SourcePackage: openssl
  Title: package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to 
install/upgrade: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1851714/+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 1851714] [NEW] package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to install/upgrade: installed libssl1.1:i386 package post-installation script subprocess returned error exit

2019-11-07 Thread ian mitchell

Public bug reported:

on login to laptop.

ProblemType: Package
DistroRelease: Ubuntu 18.04
Package: libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic i686
ApportVersion: 2.20.9-0ubuntu7
Architecture: i386
Date: Thu Nov  7 16:54:40 2019
ErrorMessage: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
InstallationDate: Installed on 2019-11-05 (1 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 3.6.5-3
PythonDetails: /root/Error: command ['which', 'python'] failed with exit code 
1:, Error: [Errno 2] No such file or directory: "/root/Error: command ['which', 
'python'] failed with exit code 1:": "/root/Error: command ['which', 'python'] 
failed with exit code 1:", unpackaged
RelatedPackageVersions:
 dpkg 1.19.0.5ubuntu2.3
 apt  1.6.1
SourcePackage: openssl
Title: package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to 
install/upgrade: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: apport-package bionic i386

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

Title:
  package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to
  install/upgrade: installed libssl1.1:i386 package post-installation
  script subprocess returned error exit status 128

Status in openssl package in Ubuntu:
  New

Bug description:
  on login to laptop.

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic i686
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: i386
  Date: Thu Nov  7 16:54:40 2019
  ErrorMessage: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
  InstallationDate: Installed on 2019-11-05 (1 days ago)
  InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 3.6.5-3
  PythonDetails: /root/Error: command ['which', 'python'] failed with exit code 
1:, Error: [Errno 2] No such file or directory: "/root/Error: command ['which', 
'python'] failed with exit code 1:": "/root/Error: command ['which', 'python'] 
failed with exit code 1:", unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.1
  SourcePackage: openssl
  Title: package libssl1.1:i386 1.1.1-1ubuntu2.1~18.04.4 failed to 
install/upgrade: installed libssl1.1:i386 package post-installation script 
subprocess returned error exit status 128
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1851714/+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 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Scott Moser

> > So that means we have this sequence of events:
> >  a.) growpart change partition table
> >  b.) growpart call partx
> >  c.) udev created and events being processed

> That is not true. whilst sfdisk is deleting, creating, finishing
> partition table (a) and partx is called (b), udev events are already fired
> and running in parallel and may complete against deleted, partially new,
> completely new partition table, with or without partx completed.

You're correct... I left out some 'events created and handled' after 'a'.
But that doesn't change anything.  The problem we're seeing here is *not*
that 'b' had any issue.

> 
> No amount of settling for events will fix the fact that events were run
> against racy state of the partition table _during_ sfdisk and partx calls.

complete non-sense.  I dont care about any racy state *during* anything. I 
call 'udevadm settle'.  That means "block until stuff is done."  I think
you're saying that I cannot:
 1.) do something that causes udev events
 2.) wait until all udev events caused by that something are finished

if that is the case, then nothing ever can fix this, and we might as well
go find jobs on a farm.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1834875] Re: cloud-init growpart race with udev

On Thu, Nov 7, 2019 at 1:30 PM Dan Streetman 
wrote:

> > Yes, settle does not help.
>
> Well, I didn't suggest just to settle ;-)
>

Sorry; long bug thread.


> > I'm currently suggesting as a heavy-handed workaround.
>
> I don't really see why you think this is heavy-handed, but I must be
> missing something.
>

It's replaying the disk events which results in running rules multiple
times.
The ADD|CHANGE event was already emitted once (when growpart modifies the
partition)
 and the rules were run (likely at the wrong time).  Issuing a second
trigger will repeat this.
IMO, that's a non-zero amount of time that slows the boot down, so I'd like
to avoid that.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1834875] Re: cloud-init growpart race with udev

> Yes, settle does not help.

Well, I didn't suggest just to settle ;-)

> I'm currently suggesting as a heavy-handed workaround.

I don't really see why you think this is heavy-handed, but I must be
missing something.

> I would like to understand *why* the udevd/kernel pair exhibits this racy 
> behavior
> whereas other kernels/udevd from Bionic do not.

Certainly a good point; might be good to add some debug to the kernel
and/or systemd to see what's going on.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1851695] [NEW] DEP8 failure/regression in arm64 and armhf

Public bug reported:

nspr 0.6.1~ds1-4 is failing DEP8 test in arm64 and armhf:


autopkgtest [09:46:25]: test command1: /usr/bin/dh_golang_autopkgtest
autopkgtest [09:46:25]: test command1: [---
[info] Testing github.com/theupdateframework/notary...
[info] Source code installed by binary package, overriding dh_auto_configure...
[info] Disabling existing override_dh_auto_configure...
dh build --builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build \
  --buildsystem=golang \
  --with=golang
   dh_update_autotools_config 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
   dh_autoreconf 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
mkdir -p "_build"
cp -a /usr/share/gocode/src "_build"
make[1]: Leaving directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
dh_auto_build -- -tags "pkcs11"
cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 
github.com/theupdateframework/notary/client 
github.com/theupdateframework/notary/client/changelist 
github.com/theupdateframework/notary/cmd/escrow 
github.com/theupdateframework/notary/cmd/notary 
github.com/theupdateframework/notary/cmd/notary-server 
github.com/theupdateframework/notary/cmd/notary-signer 
github.com/theupdateframework/notary/cryptoservice 
github.com/theupdateframework/notary/passphrase 
github.com/theupdateframework/notary/proto 
github.com/theupdateframework/notary/server 
github.com/theupdateframework/notary/server/errors 
github.com/theupdateframework/notary/server/handlers 
github.com/theupdateframework/notary/server/snapshot 
github.com/theupdateframework/notary/server/storage 
github.com/theupdateframework/notary/server/timestamp 
github.com/theupdateframework/notary/signer 
github.com/theupdateframework/notary/signer/api 
github.com/theupdateframework/notary/signer/client 
github.com/theupdateframework/notary/signer/keydbstore 
github.com/theupdateframework/notary/storage 
github.com/theupdateframework/notary/storage/rethinkdb 
github.com/theupdateframework/notary/trustmanager 
github.com/theupdateframework/notary/trustmanager/remoteks 
github.com/theupdateframework/notary/trustmanager/yubikey 
github.com/theupdateframework/notary/trustpinning 
github.com/theupdateframework/notary/tuf 
github.com/theupdateframework/notary/tuf/data 
github.com/theupdateframework/notary/tuf/signed 
github.com/theupdateframework/notary/tuf/testutils 
github.com/theupdateframework/notary/tuf/testutils/interfaces 
github.com/theupdateframework/notary/tuf/testutils/keys 
github.com/theupdateframework/notary/tuf/utils 
github.com/theupdateframework/notary/tuf/validation 
github.com/theupdateframework/notary/utils 
github.com/theupdateframework/notary/version
src/github.com/docker/distribution/digestset/set.go:9:2: cannot find package 
"github.com/opencontainers/go-digest" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/go-digest
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/go-digest (from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/go-digest
 (from $GOPATH)
src/github.com/docker/distribution/blobs.go:13:2: cannot find package 
"github.com/opencontainers/image-spec/specs-go/v1" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/image-spec/specs-go/v1
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/image-spec/specs-go/v1 
(from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/image-spec/specs-go/v1
 (from $GOPATH)
dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 
github.com/theupdateframework/notary/client 
github.com/theupdateframework/notary/client/changelist 
github.com/theupdateframework/notary/cmd/escrow 
github.com/theupdateframework/notary/cmd/notary 
github.com/theupdateframework/notary/cmd/notary-server 
github.com/theupdateframework/notary/cmd/notary-signer 
github.com/theupdateframework/notary/cryptoservice 
github.com/theupdateframework/notary/passphrase 
github.com/theupdateframework/notary/proto 
github.com/theupdateframework/notary/server 
github.com/theupdateframework/notary/server/errors

[Touch-packages] [Bug 1582899] Re: in-target: mkinitramfs: failed to determine device for /

This bug has a lot of troubleshooting comments, but lacks a good summary
about what is going on. I don't expect the xenial installer to be
changed anymore, short of critical bugs affecting it.

@tcstone, you say you hit something similar with 18.04.2. Current bionic
release is 18.04.3, would you mind to try again, and if you still hit a
bug, file a new one please? Please note that the default server install
in bionic is subiquity ("live-server"), and bugs against that should be
filed via https://bugs.launchpad.net/subiquity/+filebug.

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

Title:
  in-target: mkinitramfs: failed to determine device for /

Status in base-installer package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in live-installer package in Ubuntu:
  Confirmed

Bug description:
  Sysadmin reported in #ubuntu (later #ubuntu-kernel) the 16.04 ubuntu-
  server ISO installer failed due to being unable to configure linux-
  image-4.4.0-21-generic.

  Lots of diagnostics and one SSH remote session later we seem to have
  narrowed it down to the installer.

  At the installer's boot menu the F6 option "Expert mode" is chosen.

  During initial ram file-system creation (after the kernel image is installed) 
the /dev/ file-system is not mounted in /target/ and therefore
  the initramfs-tools/hook-functions::dep_add_modules_mount() cannot match
  the mount device of "/" (in this case /dev/sda3) with any node under /dev/ 
which only contains static entries.

  Cause appears to be that live-installer.postinst has the crucial step
  calling library.sh:setup_dev() commented out:

  #waypoint 1 setup_dev

  OS=linux
  setup_dev() calls setup_dev_${OS}
  setup_dev_linux() mounts procfs and devtmpfs into /target/

  

  Originally the cause of the error message appeared to be that the
  symlink names in /dev/disk/by-uuid/  haven't been updated after the
  partitioning stage if there were pre-existing partitions and file-
  systems on the install device, *and* the sysadmin chose to format the
  existing partitions when selecting mountpoints.

  In this case a hardware RAID device presents:

  /dev/sda1 (/boot/)
  /dev/sda2 (swap)
  /dev/sda3 (/)

  From the shell I noticed:

  root@tmpstorage:/# ll /dev/disk/by-uuid/
  total 0
  lrwxrwxrwx 1 root root  10 May 17 19:39 130e4419-4bfd-46d2-87f9-62e5379bf591 
-> ../../sda1
  lrwxrwxrwx 1 root root  10 May 17 19:39 127d3fa1-c07c-48e4-9e26-1b926d37625c 
-> ../../sda3
  lrwxrwxrwx 1 root root  10 May 17 19:39 78b88456-2b0b-4265-9ed2-5db61522d887 
-> ../../sda2
  lrwxrwxrwx 1 root root   9 May 17 19:39 2016-04-20-22-45-29-00 -> ../../sr1
  drwxr-xr-x 6 root root 120 May 17 19:39 ..
  drwxr-xr-x 2 root root 120 May 17 19:39 .

  root@tmpstorage:/# blkid /dev/sda*
  /dev/sda: PTUUID="a84e60fd" PTTYPE="dos"
  /dev/sda1: UUID="61365714-8ff7-47a2-8035-8aed9e3191a6" TYPE="ext4" 
PARTUUID="a84e60fd-01"
  /dev/sda2: UUID="78b88456-2b0b-4265-9ed2-5db61522d887" TYPE="swap" 
PARTUUID="a84e60fd-02"
  /dev/sda3: UUID="75f68451-9472-47c7-9efc-ed032bfa9987" TYPE="ext4" 
PARTUUID="a84e60fd-03"

  More details to follow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1582899/+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 1582899] Re: in-target: mkinitramfs: failed to determine device for /

** Tags removed: server-triage-discuss ubuntu-server

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

Title:
  in-target: mkinitramfs: failed to determine device for /

Status in base-installer package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in live-installer package in Ubuntu:
  Confirmed

Bug description:
  Sysadmin reported in #ubuntu (later #ubuntu-kernel) the 16.04 ubuntu-
  server ISO installer failed due to being unable to configure linux-
  image-4.4.0-21-generic.

  Lots of diagnostics and one SSH remote session later we seem to have
  narrowed it down to the installer.

  At the installer's boot menu the F6 option "Expert mode" is chosen.

  During initial ram file-system creation (after the kernel image is installed) 
the /dev/ file-system is not mounted in /target/ and therefore
  the initramfs-tools/hook-functions::dep_add_modules_mount() cannot match
  the mount device of "/" (in this case /dev/sda3) with any node under /dev/ 
which only contains static entries.

  Cause appears to be that live-installer.postinst has the crucial step
  calling library.sh:setup_dev() commented out:

  #waypoint 1 setup_dev

  OS=linux
  setup_dev() calls setup_dev_${OS}
  setup_dev_linux() mounts procfs and devtmpfs into /target/

  

  Originally the cause of the error message appeared to be that the
  symlink names in /dev/disk/by-uuid/  haven't been updated after the
  partitioning stage if there were pre-existing partitions and file-
  systems on the install device, *and* the sysadmin chose to format the
  existing partitions when selecting mountpoints.

  In this case a hardware RAID device presents:

  /dev/sda1 (/boot/)
  /dev/sda2 (swap)
  /dev/sda3 (/)

  From the shell I noticed:

  root@tmpstorage:/# ll /dev/disk/by-uuid/
  total 0
  lrwxrwxrwx 1 root root  10 May 17 19:39 130e4419-4bfd-46d2-87f9-62e5379bf591 
-> ../../sda1
  lrwxrwxrwx 1 root root  10 May 17 19:39 127d3fa1-c07c-48e4-9e26-1b926d37625c 
-> ../../sda3
  lrwxrwxrwx 1 root root  10 May 17 19:39 78b88456-2b0b-4265-9ed2-5db61522d887 
-> ../../sda2
  lrwxrwxrwx 1 root root   9 May 17 19:39 2016-04-20-22-45-29-00 -> ../../sr1
  drwxr-xr-x 6 root root 120 May 17 19:39 ..
  drwxr-xr-x 2 root root 120 May 17 19:39 .

  root@tmpstorage:/# blkid /dev/sda*
  /dev/sda: PTUUID="a84e60fd" PTTYPE="dos"
  /dev/sda1: UUID="61365714-8ff7-47a2-8035-8aed9e3191a6" TYPE="ext4" 
PARTUUID="a84e60fd-01"
  /dev/sda2: UUID="78b88456-2b0b-4265-9ed2-5db61522d887" TYPE="swap" 
PARTUUID="a84e60fd-02"
  /dev/sda3: UUID="75f68451-9472-47c7-9efc-ed032bfa9987" TYPE="ext4" 
PARTUUID="a84e60fd-03"

  More details to follow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1582899/+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 1834875] Re: cloud-init growpart race with udev

@ddstreet

Yes, settle does not help.

Re-triggering udevadm trigger --action=add /sys/class/block/sda

Would re-run all of them after the partition change has occurred, which
is what I'm currently suggesting as a heavy-handed workaround.

I would like to understand *why* the udevd/kernel pair exhibits this
racy behavior whereas other kernels/udevd from Bionic do not.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-11-07 Thread Paul White

Looks like I was a little slow in testing and changing the tags but for
the record:

Rebooted into Ubuntu 19.10 to confirm Restart and Poweroff options were not 
working
Logged in, enabled -proposed, updated systemd to version 242-7ubuntu3.2
Logged out and confirmed 'Poweroff' now works
Started PC and without logging in confirmed 'Restart' now works

Thanks for the 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/1847896

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1834875] Re: cloud-init growpart race with udev

Just curious, did anyone actually test with my suggestion from comment
40?  That is, just make your partition table change (and update the
kernel with partx or whatever, of course), and after it's done trigger
--settle udev for the device.  Be interesting to know if that actually
fixes it or not.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-11-07 Thread Efthimios Chaskaris

The feature works now. You might want to release it earlier than 7 days.

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

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-11-07 Thread Efthimios Chaskaris

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

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

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1834875] Re: cloud-init growpart race with udev

> So that means we have this sequence of events:
>  a.) growpart change partition table
>  b.) growpart call partx
>  c.) udev created and events being processed

That is not true. whilst sfdisk is deleting, creating, finishing
partition table (a) and partx is called (b), udev events are already
fired and running in parallel and may complete against deleted,
partially new, completely new partition table, with or without partx
completed.

No amount of settling for events will fix the fact that events were run
against racy state of the partition table _during_ sfdisk and partx
calls.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1851518] Re: [950SBE/951SBE, Realtek ALC298, Speaker, Internal] No sound on internal speakers, very very quiet on headphones

2019-11-07 Thread Filipe Garrett

I have a very similar issue with another Samsung laptop:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1850702

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

Title:
  [950SBE/951SBE, Realtek ALC298, Speaker, Internal] No sound on
  internal speakers, very very quiet on headphones

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I've been googling this issue for 10's of hours and tried many things.

  Relase of Ubuntu: 19.10

  Expected outcome: Music plays on the internal speakers and headphones.

  Actual outcome: I can barely hear audio using headphones with volume
  turned up to 150%.  Absolutely nothing comes out of the speakers. (The
  speakers sound great under Windows 10.)

  Complete alsa-info output is attached, but here are some snippets:

  !!DMI Information
  !!---

  Manufacturer:  SAMSUNG ELECTRONICS CO., LTD.
  Product Name:  950SBE/951SBE
  Product Version:   P06RES
  Firmware Version:  P06RES.075.190529.SP
  Board Vendor:  SAMSUNG ELECTRONICS CO., LTD.
  Board Name:NP950SBE-K01US

  
  !!Kernel Information
  !!--

  Kernel release:5.3.0-19-generic
  Operating System:  GNU/Linux
  Architecture:  x86_64
  Processor: x86_64
  SMP Enabled:   Yes


  !!ALSA Version
  !!

  Driver version: k5.3.0-19-generic
  Library version:1.1.9
  Utilities version:  1.1.9

  
  !!Loaded ALSA modules
  !!---

  snd_hda_intel

  
  !!Sound Servers on this system
  !!

  Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes

  
  !!Soundcards recognised by ALSA
  !!-

   0 [PCH]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0x604b118000 irq 177

  
  !!PCI Soundcards installed in the system
  !!--

  00:1f.3 Multimedia audio controller: Intel Corporation Cannon Point-LP
  High Definition Audio Controller (rev 11)

  
  !!Advanced information - PCI Vendor/Device/Subsystem ID's
  !!---

  00:1f.3 0401: 8086:9dc8 (rev 11)
  DeviceName: Onboard - Sound

  
  !!HDA-Intel Codec information
  !!---
  --startcollapse--

  Codec: Realtek ALC298
  Address: 0
  AFG Function Id: 0x1 (unsol 1)
  Vendor Id: 0x10ec0298
  Subsystem Id: 0x144dc812
  Revision Id: 0x100103
  No Modem Function Group found
  Default PCM:
  rates [0x60]: 44100 48000
  bits [0xe]: 16 20 24
  formats [0x1]: PCM
  Default Amp-In caps: N/A
  Default Amp-Out caps: N/A
  State of AFG node 0x01:
Power states:  D0 D1 D2 D3 D3cold CLKSTOP EPSS
Power: setting=D0, actual=D0
  GPIO: io=8, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
Control: name="Headphone Playback Volume", index=0, device=0
  ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Device: name="ALC298 Analog", type="Audio", device=0
Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=0
Amp-Out vals:  [0x00 0x00]
Converter: stream=1, channel=0
PCM:
  rates [0x60]: 44100 48000
  bits [0xe]: 16 20 24
  formats [0x1]: PCM
Power states:  D0 D1 D2 D3 EPSS
Power: setting=D0, actual=D0
  Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
Control: name="Speaker Playback Volume", index=0, device=0
  ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=0
Amp-Out vals:  [0x7f 0x7f]
Converter: stream=1, channel=0

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  martin 1383 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  6 06:20:08 2019
  InstallationDate: Installed on 2019-11-03 (3 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Scott Moser

I really think you are all *way* over thinking this.
 a. growpart made a change to the partition table (using sfdisk)
 b. growpart called partx --update --nr 3 /dev/sda
 c. growpart exited

With a and b growpart created udev events. If you create udev events,
you really need to wait for those events to finish, or your just pushing
complexity onto your consumer.

Now Daniel's updated cloud-init with output captured in comment 14
clearly called udevadm settle after 'c'. But the problem still existed.

So that means we have this sequence of events:
 a.) growpart change partition table
 b.) growpart call partx
 c.) udev created and events being processed
 d.) growpart exits
 e.) cloud-init calls udevadm settle
 f.) udev events occurring that removed the link
 g.) cloud-init raced on reading that size - fail

To  me, that means either udevadm settle called in 'e' didn't actually
do what it is suppsoed to do and wait for all events in the queue to
clear.  Or, something else created new events.  I have long suspected
that to be the case, and I think the thing doing it is udev rules.

If that is true, then udev events cause more udev events, so a single
'settle' is never enough.  Nor can you actually ever know if you *have*
settled long enough.

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

** Changed in: ubuntu-power-systems
   Status: Triaged => Fix Released

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

Title:
  [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV
  from being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Fix Released
Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

Hello Matthias, or anyone else affected,

Accepted python3.7 into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/python3.7/3.7.5-2~18.04 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: python3.7 (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags added: verification-needed-bionic

** Changed in: python3.6 (Ubuntu Bionic)
   Status: New => Fix Committed

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  Fix Committed
Status in python3.7 source package in Bionic:
  Fix Committed
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Committed

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1835738] Please test proposed package

Hello Matthias, or anyone else affected,

Accepted python3.6 into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/python3.6/3.6.9-1~18.04 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  Fix Committed
Status in python3.7 source package in Bionic:
  Fix Committed
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Committed

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1849785] Re: FTBFS on i386/ppc64/s390x (Eoan+Focal)

2019-11-07 Thread Christian Ehrhardt 

Build issue is reproducible on arm64 LP infrastructure builds.

I spawned a canonistack arm64 system to check if it is reproducible
there as well for some debugging how we could fix it.

Interestingly, it does NOT FAIL on focal as-is when building on aarch64.

But as LP builds are against -proposed I Then switched to focal-proposed which 
upgraded this list of things:
apport/focal-proposed 2.20.11-0ubuntu11 all [upgradable from: 2.20.11-0ubuntu9]
fwupd-signed/focal-proposed 1.12+1.3.3-2 arm64 [upgradable from: 
1.10+1.2.10-1ubuntu2]
fwupd/focal-proposed 1.3.3-2 arm64 [upgradable from: 1.2.10-1ubuntu2]
gawk/focal-proposed 1:5.0.1+dfsg-1 arm64 [upgradable from: 
1:4.2.1+dfsg-1.1build1]
libcap2-bin/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libcap2/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libdebconfclient0/focal-proposed 0.250ubuntu1 arm64 [upgradable from: 
0.249ubuntu1]
libfwupd2/focal-proposed 1.3.3-2 arm64 [upgradable from: 1.2.10-1ubuntu2]
libglib2.0-0/focal-proposed 2.63.1-1 arm64 [upgradable from: 2.62.1-1]
libglib2.0-bin/focal-proposed 2.63.1-1 arm64 [upgradable from: 2.62.1-1]
libglib2.0-data/focal-proposed 2.63.1-1 all [upgradable from: 2.62.1-1]
liblz4-1/focal-proposed 1.9.2-1 arm64 [upgradable from: 1.9.1-2]
libpam-cap/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libpython3-all-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 
3.7.5-1]
libpython3-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
libpython3-stdlib/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
libseccomp2/focal-proposed 2.4.1-0ubuntu0.19.10.4 arm64 [upgradable from: 
2.4.1-0ubuntu0.19.10.3]
linux-headers-generic/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 
5.3.0.19.22]
linux-headers-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 
5.3.0.19.22]
linux-image-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 
5.3.0.19.22]
linux-libc-dev/focal-proposed 5.3.0-21.22 arm64 [upgradable from: 5.3.0-19.20]
linux-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 5.3.0.19.22]
lz4/focal-proposed 1.9.2-1 arm64 [upgradable from: 1.9.1-2]
python3-all-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-all/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-apport/focal-proposed 2.20.11-0ubuntu11 all [upgradable from: 
2.20.11-0ubuntu9]
python3-colorama/focal-proposed 0.4.1-1 all [upgradable from: 0.3.7-1]
python3-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-distupgrade/focal-proposed 1:20.04.4 all [upgradable from: 1:20.04.2]
python3-jwt/focal-proposed 1.7.1-2 all [upgradable from: 1.7.1-1]
python3-launchpadlib/focal-proposed 1.10.7-2 all [upgradable from: 1.10.7-1]
python3-lazr.restfulclient/focal-proposed 0.14.2-2 all [upgradable from: 
0.14.2-1]
python3-lazr.uri/focal-proposed 1.0.3-4 all [upgradable from: 1.0.3-3]
python3-minimal/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-oauthlib/focal-proposed 3.1.0-1 all [upgradable from: 2.1.0-1]
python3-pkg-resources/focal-proposed 41.4.0-1 all [upgradable from: 41.1.0-1]
python3-problem-report/focal-proposed 2.20.11-0ubuntu11 all [upgradable from: 
2.20.11-0ubuntu9]
python3-twisted-bin/focal-proposed 18.9.0-4 arm64 [upgradable from: 
18.9.0-3ubuntu1]
python3-twisted/focal-proposed 18.9.0-4 all [upgradable from: 18.9.0-3ubuntu1]
python3-wadllib/focal-proposed 1.3.3-3 all [upgradable from: 1.3.3-2]
python3/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
ubuntu-release-upgrader-core/focal-proposed 1:20.04.4 all [upgradable from: 
1:20.04.2]


I especially wanted to check linux-libc-dev as that brings the headers used 
here:

That 5.3.0-19.20 is actually newer and just in the image.
There is a 5.3.0-18.19 from http://us.ports.ubuntu.com/ubuntu-ports focal/main.
So maybe instead of upgrading the trigger is downgrading to that?


Fail: LP build (two days ago): 5.3.0-18.19
Fail: LP build (rebuild today): 5.3.0-18.19
Good: canonistack (focal image): 5.3.0-19.20
Good: canonistack (focal-proposed): 5.3.0-21.22
Good: canonistack (focal-release): 5.3.0-18.19

This isn't very insightful, it just always works except in LP builders :-/
The difference in the package version, even when rebuilding is odd, but at 
least in the tests wasn't the reason.

For now I'm scratching my head and will hit rebuild tomorrow again ...
?!

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

Title:
  FTBFS on i386/ppc64/s390x (Eoan+Focal)

Status in libseccomp:
  Fix Released
Status in libseccomp package in Ubuntu:
  Triaged
Status in libseccomp source package in Eoan:
  Triaged

Bug description:
  Due to the python 3.8 transition in focal this was rebuilt but fails atm.
  =>

[Touch-packages] [Bug 1849785] Re: FTBFS on i386/ppc64/s390x (Eoan+Focal)

2019-11-07 Thread Christian Ehrhardt 

Arm64:
$ grep NR_open $(dpkg -L linux-libc-dev  | xargs) 2>/dev/null 
/usr/include/asm-generic/unistd.h:#define __NR_openat 56
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_openat, sys_openat)
/usr/include/asm-generic/unistd.h:#define __NR_open_by_handle_at 265
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_by_handle_at, 
sys_open_by_handle_at)
/usr/include/asm-generic/unistd.h:#define __NR_open_tree 428
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_tree, sys_open_tree)

Amd64:
$ grep NR_open $(dpkg -L linux-libc-dev  | xargs) 2>/dev/null
/usr/include/asm-generic/unistd.h:#define __NR_openat 56
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_openat, sys_openat)
/usr/include/asm-generic/unistd.h:#define __NR_open_by_handle_at 265
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_by_handle_at, 
sys_open_by_handle_at)
/usr/include/asm-generic/unistd.h:#define __NR_open_tree 428
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_tree, sys_open_tree)
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open 5
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_openat 295
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open_by_handle_at 342
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open_tree 428
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open 2
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_openat 257
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open_by_handle_at 304
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open_tree 428
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open 
(__X32_SYSCALL_BIT + 2)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_openat 
(__X32_SYSCALL_BIT + 257)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open_by_handle_at 
(__X32_SYSCALL_BIT + 304)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open_tree 
(__X32_SYSCALL_BIT + 428)

So this really might be different on arm, not sure what to do about it yet.
Might be related to 
https://github.com/seccomp/libseccomp/commit/0db8babb27eed3ce202d54ec1cd99f23367631cf

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

Title:
  FTBFS on i386/ppc64/s390x (Eoan+Focal)

Status in libseccomp:
  Fix Released
Status in libseccomp package in Ubuntu:
  Triaged
Status in libseccomp source package in Eoan:
  Triaged

Bug description:
  Due to the python 3.8 transition in focal this was rebuilt but fails atm.
  => 
https://launchpadlibrarian.net/448119198/buildlog_ubuntu-focal-s390x.libseccomp_2.4.1-0ubuntu0.19.10.4_BUILDING.txt.gz

  The simulations fail in this case:
   batch name: 36-sim-ipc_syscalls
   test mode:  c
   test type:  bpf-sim
  Test 36-sim-ipc_syscalls%%001-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%002-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%003-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%004-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%005-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%006-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%007-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%008-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%009-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%010-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%011-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%012-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%013-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%014-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%015-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%016-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%017-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%018-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%019-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%020-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%021-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%022-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%023-1 result:   ERROR 36-sim-ipc_syscalls rc=14
  Test 36-sim-ipc_syscalls%%024-1 result:   ERROR 36-sim-ipc_syscalls rc=14
   test mode:  c
   test type:  bpf-valgrind
  Test 36-sim-ipc_syscalls%%025-1 result:   FAILURE 36-sim-ipc_syscalls 
rc=14
   batch name: 37-sim-ipc_syscalls_be
   test mode:  c
   test type:  bpf-sim
   test arch:

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

> it will prevent udevd from running the rules against it. Thus
effectively the event will be fired and done, but nothing actually
executed for it.

Interesting, I suspect this is the race we see.  The events emitted but
no actions taken (ie we didn't get our by-partuuid symlink created.

> I somehow wonder if we even need partx call, if we properly flock the
device and trigger udev after everything is done.

Growpart is modifying the partition table of the root device which is
already mounted.  We will not be able to flock the root device since
it's open and mounted.  This is precisely why we need to use the partx
call as it updates the kernel partition table mapping without requiring
an exclusive lock on the device.

> So does growpart create partition? move it? delete/recreate one? i.e
does ADD happen? or like REMOVE & ADD? or maybe it's like just MOVE or
CHANGE? Do we have logs of the emitted events already?

growpart on gpt, uses sgdisk which, deletes and then recreates the
existing partition but with a larger size.

The logs are above, see comment #22 -> #24 and #38.

> Don't like flags, as then we'll have to supported forever =) maybe env
variable? or like simply change in focal and compare focal vs eoan?

This may not matter if we can't flock.  I suspect we'll need to use the
ugly re-trigger events for the disk.  growpart could take the disk it's
pointed at, examine the existing udevadm symlinks associated with this
(via udevadm info --export), perform it's operation, and then post-
operation, trigger the add event on the disk, settle, and confirm that
udevadm info --export contains the same set of links (partuuid ,etc).

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1582899] Re: in-target: mkinitramfs: failed to determine device for /

** Tags added: server-triage-discuss

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

Title:
  in-target: mkinitramfs: failed to determine device for /

Status in base-installer package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in live-installer package in Ubuntu:
  Confirmed

Bug description:
  Sysadmin reported in #ubuntu (later #ubuntu-kernel) the 16.04 ubuntu-
  server ISO installer failed due to being unable to configure linux-
  image-4.4.0-21-generic.

  Lots of diagnostics and one SSH remote session later we seem to have
  narrowed it down to the installer.

  At the installer's boot menu the F6 option "Expert mode" is chosen.

  During initial ram file-system creation (after the kernel image is installed) 
the /dev/ file-system is not mounted in /target/ and therefore
  the initramfs-tools/hook-functions::dep_add_modules_mount() cannot match
  the mount device of "/" (in this case /dev/sda3) with any node under /dev/ 
which only contains static entries.

  Cause appears to be that live-installer.postinst has the crucial step
  calling library.sh:setup_dev() commented out:

  #waypoint 1 setup_dev

  OS=linux
  setup_dev() calls setup_dev_${OS}
  setup_dev_linux() mounts procfs and devtmpfs into /target/

  

  Originally the cause of the error message appeared to be that the
  symlink names in /dev/disk/by-uuid/  haven't been updated after the
  partitioning stage if there were pre-existing partitions and file-
  systems on the install device, *and* the sysadmin chose to format the
  existing partitions when selecting mountpoints.

  In this case a hardware RAID device presents:

  /dev/sda1 (/boot/)
  /dev/sda2 (swap)
  /dev/sda3 (/)

  From the shell I noticed:

  root@tmpstorage:/# ll /dev/disk/by-uuid/
  total 0
  lrwxrwxrwx 1 root root  10 May 17 19:39 130e4419-4bfd-46d2-87f9-62e5379bf591 
-> ../../sda1
  lrwxrwxrwx 1 root root  10 May 17 19:39 127d3fa1-c07c-48e4-9e26-1b926d37625c 
-> ../../sda3
  lrwxrwxrwx 1 root root  10 May 17 19:39 78b88456-2b0b-4265-9ed2-5db61522d887 
-> ../../sda2
  lrwxrwxrwx 1 root root   9 May 17 19:39 2016-04-20-22-45-29-00 -> ../../sr1
  drwxr-xr-x 6 root root 120 May 17 19:39 ..
  drwxr-xr-x 2 root root 120 May 17 19:39 .

  root@tmpstorage:/# blkid /dev/sda*
  /dev/sda: PTUUID="a84e60fd" PTTYPE="dos"
  /dev/sda1: UUID="61365714-8ff7-47a2-8035-8aed9e3191a6" TYPE="ext4" 
PARTUUID="a84e60fd-01"
  /dev/sda2: UUID="78b88456-2b0b-4265-9ed2-5db61522d887" TYPE="swap" 
PARTUUID="a84e60fd-02"
  /dev/sda3: UUID="75f68451-9472-47c7-9efc-ed032bfa9987" TYPE="ext4" 
PARTUUID="a84e60fd-03"

  More details to follow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1582899/+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 1851661] [NEW] AppArmor denied operation open to snap pick-colour-picker

2019-11-07 Thread Douglas Silva

Public bug reported:

I've written an issue here:
https://github.com/stuartlangridge/ColourPicker/issues/63

Pick (a color picker distributed as a snap) will not launch. The creator
of the application believes this to be a problem with my system, not
with their app. Apparently, AppArmor is preventing it from starting. I'm
not familiar with this MAC implementation, but the logs suggest that
this is the problem. See the attachment.

```
nov 07 11:18:29 alq22 audit[27542]: AVC apparmor="DENIED" operation="open" 
profile="snap.pick-colour-picker.pick-colour-picker" name="/proc/27542/mounts" 
pid=27542 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
nov 07 11:18:29 alq22 kernel: audit: type=1400 audit(1573136309.796:304): 
apparmor="DENIED" operation="open" 
profile="snap.pick-colour-picker.pick-colour-picker" name="/proc/27542/mounts" 
pid=27542 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
```

This is a fresh installation of Ubuntu 18.04.3. I take great care not to
mess with system components such as snapd. Other snaps are working
properly.

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

** Attachment added: "Journalctl output - see last lines"
   
https://bugs.launchpad.net/bugs/1851661/+attachment/5303495/+files/journalctl.txt

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

Title:
  AppArmor denied operation open to snap pick-colour-picker

Status in apparmor package in Ubuntu:
  New

Bug description:
  I've written an issue here:
  https://github.com/stuartlangridge/ColourPicker/issues/63

  Pick (a color picker distributed as a snap) will not launch. The
  creator of the application believes this to be a problem with my
  system, not with their app. Apparently, AppArmor is preventing it from
  starting. I'm not familiar with this MAC implementation, but the logs
  suggest that this is the problem. See the attachment.

  ```
  nov 07 11:18:29 alq22 audit[27542]: AVC apparmor="DENIED" operation="open" 
profile="snap.pick-colour-picker.pick-colour-picker" name="/proc/27542/mounts" 
pid=27542 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
  nov 07 11:18:29 alq22 kernel: audit: type=1400 audit(1573136309.796:304): 
apparmor="DENIED" operation="open" 
profile="snap.pick-colour-picker.pick-colour-picker" name="/proc/27542/mounts" 
pid=27542 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
  ```

  This is a fresh installation of Ubuntu 18.04.3. I take great care not
  to mess with system components such as snapd. Other snaps are working
  properly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1851661/+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 1837734] Re: libnss3 reads fips_enabled flag and automatically switches to FIPS mode

** Merge proposal unlinked:
   
https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/nss/+git/nss/+merge/375115

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

Title:
  libnss3 reads fips_enabled flag and automatically switches to FIPS
  mode

Status in nss package in Ubuntu:
  Fix Released
Status in nss source package in Xenial:
  Won't Fix
Status in nss source package in Bionic:
  Fix Committed
Status in nss source package in Disco:
  Fix Committed
Status in nss source package in Eoan:
  Fix Released

Bug description:
  [IMPACT]
  nss is not a FIPS certified library. On a machine running FIPS enabled 
kernel, the library by default goes into FIPS mode if 
/proc/sys/crypto/fips_enabled=1. This is an untested configuration and since 
libnss3 is not a certified library we propose disabling reading the 
'fips_enabled' flag and therefore switching the library automatically into FIPS 
mode. 

  The proposed patch disables reading the /proc/sys/crypto/fips_enabled
  flag. The users of the library however can force nss into FIPS mode
  via an environment variable. We plan to leave it as is so as not to
  regress existing users who may be using it.

  The issue impacts libnss3 versions in eoan, disco, bionic and xenial.

  lsb_release -rd
  Description:  Ubuntu Eoan Ermine (development branch)
  Release: 19.10

  Version: 2:3.45-1ubuntu1

  lsb_release -rd
  Description: Ubuntu Disco Dingo
  Release: 19.04

  Version: 2:3.42-1ubuntu2

  lsb_release -rd
  Description:  Ubuntu Bionic Beaver
  Release:  18.04

  Version: 2:3.35-2ubuntu2.3

  lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  Version: 2:3.28.4-0ubuntu0.16.04

  [FIX]
  This fix proposes to disable libnss3 reading proc/sys/crypto/fips_enabled. We 
only want fips certified modules reading this file and running in fips mode. 
libnss3 is not one of our fips certified modules, so should not be reading this 
along with our fips certified modules to determine whether to run in fips mode.

  Users who do want to run the library in FIPS mode can do so by using
  the environment variable "NSS_FIPS". We propose to leave it as is so
  as not to regress anyone using this. The user who is using this option
  should be doing so with the awareness.

  [TEST]
  Tested on a xenial and bionic desktop ISO running FIPS enabled kernel and in 
FIPS mode. With the patch fix no crashes were observed when launching firefox 
browser.
  Without the patch fix, firefox crashes.

  Tested on a xenial and bionic desktop ISO running non-FIPS generic
  kernel. With the patch fix, firefox worked as expected and no changes
  were observed.

  [REGRESSION POTENTIAL]
  The regression potential for this is small. A FIPS kernel is required to
  create /proc/sys/crypto/fips_enabled and it is not available in standard 
ubuntu archive. For users forcing FIPS through environment variable, nothing 
has changed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1837734/+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 1744328] Re: libfreebl3.so should be public, not in the nss subdir

** Merge proposal unlinked:
   
https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/nss/+git/nss/+merge/375115

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

Title:
  libfreebl3.so should be public, not in the nss subdir

Status in nss package in Ubuntu:
  Fix Released
Status in nss package in Debian:
  New

Bug description:
  Hi,
  I tried to move the chrony dependency from tomcrypt to libnss to avoid 
universe dependencies.
  While doing so I found that libfreebl3 is not "normally" linkable being 
outside the normal ld paths.

  E.g. sample program
  #include 
  #include 
  #include 
  int main(int argc, char **argv) {
  NSSLOWHASH_Begin(NSSLOWHASH_NewContext(NSSLOW_Init(), HASH_AlgSHA512));
  return 0;
  }

  Build:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wmissing-prototypes -Wall -pthread -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/nss -I/usr/include/nspr -o docheck docheck.c -lfreebl3 
-Wl,-Bsymbolic-functions -Wl,-z,relro -v -Wl,-v -L/usr/lib/x86_64-linux-gnu/nss

  Then:
  ldd docheck
  will give you
  libfreebl3.so => not found

  Obviously a link into /usr/lib/x86_64-linux-gnu/ fixes the issue but
  needs some more consideration if that is the thing we want (there
  might be a reason it is where it is).

  Note: Required to go on with the chrony MIR which is rather urgent to
  be sorted out as it has a lot of other dependencies that need to be
  adapted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1744328/+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 1831787] Re: Bogus routes after DHCP lease change

Hello Ante, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-eoan

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

Title:
  Bogus routes after DHCP lease change

Status in netplan:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  networkd does not remove old route(s) after DHCP address change

  [test case]

  on a system using networkd, that is connected to a network where you
  can control the addresses that the DHCP server provides, setup system
  with networkd to get address via DHCP, e.g.

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  
  (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and 
corresponding route to the gateway.

  
  Then on the dhcp server, change the subnet to a different subnet.  On the 
client, once its renews its DHCP address, the server will provide a new address 
in the new subnet, and the client will add a new default route to the new 
gateway address.  However, the old default route to the old gateway address 
isn't removed.

  Note this also happens without changing the entire subnet, but is more
  subtle as shown in the original description.

  [regression potential]

  this affects how networkd handles routes, so has the potential to
  leave a system with partial or incorrect networking, or no networking
  at all.  Any regression would most likely occur during networkd
  (re)start or during renewal of a DHCP lease, or when an interface is
  brought up.

  [other info]

  original description:
  ---

  
  Netplan config:

  network:
    version: 2
    renderer: networkd
    ethernets:
  eno4:
    dhcp4: no
  eno1np0:
    dhcp4: no
    addresses:
  - 172.16.0.2/24
    bridges:
  br0:
    dhcp4: yes
    interfaces:
  - eno4

  On initial boot, machine got 10.0.15.109 IP address:

  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured
  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 
10.0.15.109/23 via 10.0.15.253

  At one point, DHCP server reserver this IP address and client
  eventually picked up new IP address:

  May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address
  10.0.15.128/23 via 10.0.15.253

  This resulted in IP addresses:

  # ip -o a
  1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
preferred_lft forever
  1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
forever
  2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\   
valid_lft forever preferred_lft forever
  2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \   valid_lft 
forever preferred_lft forever
  6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\   
valid_lft 503sec preferred_lft 503sec
  6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \   valid_lft 
forever preferred_lft forever

  So far, everything is fine. But, the routes on the machine are bogus:

  # ip r
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100
  10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100
  172.16.0.0/24 dev eno1np0 proto kernel scope

[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen

Hello Paul, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-eoan

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

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+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 1849608] Re: systemd resolv should separate the output of stdout and stderr

Hello Steven, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

** Tags added: verification-needed verification-needed-eoan

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  dhclient fails to notify resolved about DNS servers due to bash-
  specific redirect inside 'resolved' hook script

  [test case]

  see original description below

  [regression potential]

  any regression would likely cause resolved not to be aware of
  dhclient-provided dns servers

  [other info]

  This is needed only in Eoan and later; X/B/D do not have the bash-
  specific redirect '&>' in their hook file.

  original description:
  ---

  
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
    DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1849658] Re: resolved fallback to TCP fails for truncated UDP replies

Hello Dan, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-eoan

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

Title:
  resolved fallback to TCP fails for truncated UDP replies

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.
  For example 'host toomany.ddstreet.org'.

  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.

  [test case]

  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678

  ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  [regression potential]

  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for
  DNS requests or replies.

  [other info]

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

  The commit adding stream types is not present in x/b, so this is
  needed only for disco and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

Hello Dan, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

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

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

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000

  Now on the server, add a classless route:

  dhcp-option=121,0.0.0.0/0,10.10.0.1

  and restart dnsmasq on the server.  Then on the client, reboot.  It
  should now have:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3585sec preferred_lft 3585sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5

  Now, the global route will use the static address, not the dhcp-
  provided address:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000

  If the router,

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

Hello Leroy, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-eoan

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in Keepalived Charm:
  New
Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Triaged
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in heartbeat source package in Bionic:
  Triaged
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in heartbeat source package in Disco:
  Triaged
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in heartbeat source package in Eoan:
  Triaged
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining configuration at networkd
  restart, or losing network state at networkd stop.

  - Any regressions are most likely to occur during networkd start,
  restart, or stop, and most likely to involve missing or incorrect ip
  address(es).

  - the change is based in upstream patches adding the exact feature we
  needed to fix this issue & it will be integrated with a netplan change
  to add the needed stanza to systemd nic configuration file
  (KeepConfiguration=)

  [other info]

  original description:
  ---

  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

Hello jowfdoijdfdwfwdf, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

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

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

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want

[Touch-packages] [Bug 1851649] [NEW] Package bug

2019-11-07 Thread John Doe

Public bug reported:

I couldn't change brightness. Probably this bug is related to the
problem.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21
Uname: Linux 5.0.0-32-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov  7 14:54:15 2019
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics 
Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics 
Controller [17aa:397d]
 NVIDIA Corporation GF119M [GeForce 410M] [10de:1054] (rev a1) (prog-if 00 [VGA 
controller])
   Subsystem: Lenovo GF119M [GeForce 410M] [17aa:397d]
InstallationDate: Installed on 2019-11-06 (0 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
MachineType: LENOVO HuronRiver Platform
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=3f6eec95-af31-4261-96ff-7e5695b716cc ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/27/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 44CN43WW
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Emerald Lake
dmi.board.vendor: LENOVO
dmi.board.version: FAB1
dmi.chassis.asset.tag: Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: 0.1
dmi.modalias: 
dmi:bvnLENOVO:bvr44CN43WW:bd10/27/2011:svnLENOVO:pnHuronRiverPlatform:pvrLenovoB570e:rvnLENOVO:rnEmeraldLake:rvrFAB1:cvnLENOVO:ct10:cvr0.1:
dmi.product.family: HuronRiver System
dmi.product.name: HuronRiver Platform
dmi.product.sku: System SKUNumber
dmi.product.version: Lenovo B570e
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.3
version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.3
version.xserver-xorg-core: xserver-xorg-core N/A
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

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


** Tags: amd64 apport-bug bionic ubuntu

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

Title:
  Package bug

Status in xorg package in Ubuntu:
  New

Bug description:
  I couldn't change brightness. Probably this bug is related to the
  problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21
  Uname: Linux 5.0.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Nov  7 14:54:15 2019
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation 2nd Generation Core Processor Family Integrated Graphics 
Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics 
Controller [17aa:397d]
   NVIDIA Corporation GF119M [GeForce 410M] [10de:1054] (rev a1) (prog-if 00 
[VGA controller])
 Subsystem: Lenovo GF119M [GeForce 410M] [17aa:397d]
  InstallationDate: Installed on 2019-11-06 (0 days ago)
  InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  MachineType: LENOVO HuronRiver Platform
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=3f6eec95-af31-4261-96ff-7e5695b716cc ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/27/2011
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 44CN43WW
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: Emerald Lake
  dmi.board.vendor: LENOVO
  dmi.board.version: FAB1
  dmi.chassis.asset.tag: Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: 0.1
  dmi.modalias: 
dmi:bvnLENOVO:bvr44CN43WW:bd10/27/2011:svnLENOVO:pnHuronRiverPlatform:pvrLenovoB570e:rvnLENOVO:rnEmeraldLake:rvrFAB1:cvnLENOVO:ct10:cvr0.1:
  dmi.product.family: HuronRiver System
  dmi.product.name: HuronRiver Platform
  dmi.product.sku: System SKUNumber
  dmi.product.version: Lenovo B570e
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

2019-11-07 Thread Rafael David Tinoco

** Description changed:

  [impact]
  
- ip addresses managed by keepalived are lost across networkd restarts
+ - ALL related HA software has a small problem if interfaces are being
+ managed by systemd-networkd: nic restarts/reconfigs are always going to
+ wipe all interfaces aliases when HA software is not expecting it to (no
+ coordination between them.
+ 
+ - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
+ smarter in this case because it has a service monitor that will restart
+ the virtual IP resource, in affected node & nic, before considering a
+ real failure, but other HA service might consider a real failure when it
+ is not.
  
  [test case]
  
- see original description below
+ - comment #14 is a full test case: to have 3 node pacemaker, in that
+ example, and cause a networkd service restart: it will trigger a failure
+ for the virtual IP resource monitor.
+ 
+ - other example is given in the original description for keepalived.
+ both suffer from the same issue (and other HA softwares as well).
  
  [regression potential]
  
- this backports KeepConfiguration parameter, which adds some significant
- complexity to networkd's configuration and behavior, which could lead to
- regressions in correctly configuring the network at networkd start, or
- incorrectly maintaining configuration at networkd restart, or losing
- network state at networkd stop.  Any regressions are most likely to
- occur during networkd start, restart, or stop, and most likely to
- involve missing or incorrect ip address(es).
+ - this backports KeepConfiguration parameter, which adds some
+ significant complexity to networkd's configuration and behavior, which
+ could lead to regressions in correctly configuring the network at
+ networkd start, or incorrectly maintaining configuration at networkd
+ restart, or losing network state at networkd stop.
+ 
+ - Any regressions are most likely to occur during networkd start,
+ restart, or stop, and most likely to involve missing or incorrect ip
+ address(es).
+ 
+ - the change is based in upstream patches adding the exact feature we
+ needed to fix this issue & it will be integrated with a netplan change
+ to add the needed stanza to systemd nic configuration file
+ (KeepConfiguration=)
  
  [other info]
  
  original description:
  ---
  
  Configure netplan for interfaces, for example (a working config with IP
  addresses obfuscated)
  
  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  version: 2
  
  Configure keepalived (again, a working config with IP addresses
  obfuscated)
  
  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }

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

2019-11-07 Thread James Henstridge

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

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

Title:
  please enable snap mediation support

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

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

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

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

  [Test Case]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

** Description changed:

+ [impact]
+ 
+ ip addresses managed by keepalived are lost across networkd restarts
+ 
+ [test case]
+ 
+ see original description below
+ 
+ [regression potential]
+ 
+ this backports KeepConfiguration parameter, which adds some significant
+ complexity to networkd's configuration and behavior, which could lead to
+ regressions in correctly configuring the network at networkd start, or
+ incorrectly maintaining configuration at networkd restart, or losing
+ network state at networkd stop.  Any regressions are most likely to
+ occur during networkd start, restart, or stop, and most likely to
+ involve missing or incorrect ip address(es).
+ 
+ [other info]
+ 
+ original description:
+ ---
+ 
  Configure netplan for interfaces, for example (a working config with IP
  addresses obfuscated)
  
  network:
- ethernets:
- eth0:
- addresses: [192.168.0.5/24]
- dhcp4: false
- nameservers:
-   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
-   addresses: [10.22.11.1]
- eth2:
- addresses:
-   - 12.13.14.18/29
-   - 12.13.14.19/29
- gateway4: 12.13.14.17
- dhcp4: false
- nameservers:
-   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
-   addresses: [10.22.11.1]
- eth3:
- addresses: [10.22.11.6/24]
- dhcp4: false
- nameservers:
-   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
-   addresses: [10.22.11.1]
- eth4:
- addresses: [10.22.14.6/24]
- dhcp4: false
- nameservers:
-   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
-   addresses: [10.22.11.1]
- eth7:
- addresses: [9.5.17.34/29]
- dhcp4: false
- optional: true
- nameservers:
-   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
-   addresses: [10.22.11.1]
- version: 2
+ ethernets:
+ eth0:
+ addresses: [192.168.0.5/24]
+ dhcp4: false
+ nameservers:
+   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
+   addresses: [10.22.11.1]
+ eth2:
+ addresses:
+   - 12.13.14.18/29
+   - 12.13.14.19/29
+ gateway4: 12.13.14.17
+ dhcp4: false
+ nameservers:
+   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
+   addresses: [10.22.11.1]
+ eth3:
+ addresses: [10.22.11.6/24]
+ dhcp4: false
+ nameservers:
+   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
+   addresses: [10.22.11.1]
+ eth4:
+ addresses: [10.22.14.6/24]
+ dhcp4: false
+ nameservers:
+   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
+   addresses: [10.22.11.1]
+ eth7:
+ addresses: [9.5.17.34/29]
+ dhcp4: false
+ optional: true
+ nameservers:
+   search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
+   addresses: [10.22.11.1]
+ version: 2
  
  Configure keepalived (again, a working config with IP addresses
  obfuscated)
  
  global_defs   # Block id
  {
  notification_email {
- sysadm...@blah.com
+ sysadm...@blah.com
  }
- notification_email_from keepali...@system3.hq.blah.com
- smtp_server 10.22.11.7 # IP
- smtp_connect_timeout 30  # integer, seconds
- router_id system3  # string identifying the machine,
-  # (doesn't have to be hostname).
- vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
- vrrp_mcast_group6 ff02::12   # optional, default ff02::12
- enable_traps # enable SNMP traps
+ notification_email_from keepali...@system3.hq.blah.com
+ smtp_server 10.22.11.7 # IP
+ smtp_connect_timeout 30  # integer, seconds
+ router_id system3  # string identifying the machine,
+  # (doesn't have to be hostname).
+ vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
+ vrrp_mcast_group6 ff02::12   # optional, default ff02::12
+ enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
- group {
- wan
- lan
- phone
- }
+ group {
+ wan

[Touch-packages] [Bug 1830408] Re: [nouveau][XFCE] Do not see login screen after screen is blanked

2019-11-07 Thread Theo Linkspfeifer

I suggest that you upgrade to 19.10 and replace light-locker with the
new xfce4-screensaver.

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

Title:
  [nouveau][XFCE] Do not see login screen after screen is blanked

Status in lightdm package in Ubuntu:
  New

Bug description:
  I've just upgraded to 18.10 from 18.04. Now when power manager (or
  whoever) puts the screen to blank, I cannot login, because I do not
  see anything. Befeore the upgrade, mouse move or keypress led to login
  screen. Now does not.

  Workaround:
  When I go to terminal on tty1 and then back CTRL+ALT+F7, login screen appears.

  Where is the problem and how to fix it please?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: xorg 1:7.7+19ubuntu8
  ProcVersionSignature: Ubuntu 4.18.0-20.21-generic 4.18.20
  Uname: Linux 4.18.0-20-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.3
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: XFCE
  Date: Fri May 24 17:59:31 2019
  DistUpgraded: 2019-05-24 13:40:45,847 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process 
“./xorg_fix_proprietary.py” (No such file or directory) (8))
  DistroCodename: cosmic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation 2nd Generation Core Processor Family Integrated Graphics 
Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. 2nd Generation Core Processor Family 
Integrated Graphics Controller [1043:1682]
   NVIDIA Corporation GF119M [GeForce GT 520M] [10de:1050] (rev a1) (prog-if 00 
[VGA controller])
 Subsystem: ASUSTeK Computer Inc. GF119M [GeForce GT 520M] [1043:1682]
  InstallationDate: Installed on 2018-09-03 (263 days ago)
  InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  MachineType: ASUSTeK Computer Inc. U36SD
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-20-generic 
root=UUID=aa87c0a2-5b06-40fb-82dd-fbccd7c800e6 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: Upgraded to cosmic on 2019-05-24 (0 days ago)
  dmi.bios.date: 07/12/2011
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: U36SD.205
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: U36SD
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrU36SD.205:bd07/12/2011:svnASUSTeKComputerInc.:pnU36SD:pvr1.0:rvnASUSTeKComputerInc.:rnU36SD:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
  dmi.product.family: U
  dmi.product.name: U36SD
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK Computer Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.95-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.10.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.10.2
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.1-3ubuntu2.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1830408/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

This bug was fixed in the package python3-stdlib-extensions -
3.7.5-1~19.04

---
python3-stdlib-extensions (3.7.5-1~19.04) disco-proposed; urgency=medium

  * SRU: LP: #1835737. Backport the final Python 3.8.0 release.
  * Also update the 3.7 modules to 3.7.5.

python3-stdlib-extensions (3.7.5-1ubuntu1) eoan; urgency=medium

  * SRU: LP: #1835738, to build the final 3.7.5 release for eoan,
just introducing a delta for the SRU process.

python3-stdlib-extensions (3.7.5-1) unstable; urgency=medium

  * Update 3.7 extensions and modules to 3.7.5 release.
  * Update 3.8 extensions and modules to 3.8.0 release.

python3-stdlib-extensions (3.7.5~rc1-1) unstable; urgency=medium

  * Update 3.7 extensions and modules to 3.7.5 release candidate 1.
  * Update 3.8 extensions and modules to 3.8.0 release candidate 1.
  * Bump standards version.

python3-stdlib-extensions (3.7.4-3) unstable; urgency=medium

  * Don't encode the MACHDEP into the _sysconfigdata file name.
  * Tighten build dependency on python3.8.

python3-stdlib-extensions (3.7.4-1) unstable; urgency=medium

  * Update 3.7 extensions and modules to the 3.7.4 release.
  * Silent some lintian warnings.
  * Bump standards version.

python3-stdlib-extensions (3.7.4~rc2-1) unstable; urgency=medium

  * Update 3.7 extensions and modules to 3.7.4 release candidate 2.
  * Add 3.8 extensions and modules for 3.8.0~b2.
  * Refresh patches.

 -- Matthias Klose   Tue, 15 Oct 2019 18:33:22 +0200

** Changed in: python3-stdlib-extensions (Ubuntu Disco)
   Status: Fix Committed => Fix Released

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  New
Status in python3.7 source package in Bionic:
  New
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Committed

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1850184] Re: losetup -f broken in 2.0.6-1ubuntu2

Hello Balint, or anyone else affected,

Accepted klibc into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/klibc/2.0.6-1ubuntu3
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: klibc (Ubuntu Eoan)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-eoan

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

Title:
  losetup -f broken in 2.0.6-1ubuntu2

Status in klibc package in Ubuntu:
  Fix Released
Status in klibc source package in Eoan:
  Fix Committed
Status in klibc source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * sudo /usr/lib/klibc/bin/losetup -vf, which appears to be missbuilt,
  as main(argc) is reset to zero, after ioctl() operations in a function
  call, quite unexpectadly.

  [Test Case]

   * $ sudo /usr/lib/klibc/bin/losetup -vf
  Loop device is /dev/loop20
  loop: can't get info on device /dev/loop20: No such device or address

  is bad.

  Note that ioctl() must succeed, thus loop0 device must be configured
  to trigger the bug.

  
  [Regression Potential]

   * klibc is quite special, as it uses linux kernel headers/assembly.
  It seems like there is incompatibility between klibc sources, and
  gcc-9 with linux-5.3 when used to build userspace programmes.

   * disabling cf-protection and stack-clash-protection did not help.

   * building with gcc-8 does not exhibit the problem.

   * the workaround is quite simple in the code, keep a copy of argc to
  compare to it later in the code.

  [Other Info]

   * Original bug report

  http://autopkgtest.ubuntu.com/packages/c/casper/focal/amd64

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/c/casper/20191025_214555_df8b8@/log.gz

  ...
  [   11.751912] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
  [   11.761441] EXT4-fs (sda1): mounted filesystem without journal. Opts: 
(null)
  loop: can't get info on device /dev/loop1: No such device or address

  BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu4) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) [6n+ mkdir result
  + set -x
  + read LINE
  + grep -e '^--OUT .* BEGIN-- .* --END--$' qemu-output.txt
  ++ grep -q /rofs result/lsblk.txt
  grep: result/lsblk.txt: No such file or directory
  autopkgtest [21:45:45]: test boot: ---]
  autopkgtest [21:45:45]: test boot:  - - - - - - - - - - results - - - - - - - 
- - -
  boot FAIL non-zero exit status 2
  autopkgtest [21:45:45]:  summary
  boot FAIL non-zero exit status 2
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1850184/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

This bug was fixed in the package python3-stdlib-extensions -
3.7.5-1build1

---
python3-stdlib-extensions (3.7.5-1build1) eoan; urgency=medium

  * SRU: LP: #1835738.

python3-stdlib-extensions (3.7.5-1) unstable; urgency=medium

  * Update 3.7 extensions and modules to 3.7.5 release.
  * Update 3.8 extensions and modules to 3.8.0 release.

 -- Matthias Klose   Tue, 15 Oct 2019 18:17:14 +0200

** Changed in: python3-stdlib-extensions (Ubuntu Eoan)
   Status: Fix Committed => Fix Released

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  New
Status in python3.7 source package in Bionic:
  New
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Committed

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1848200] Re: gdb not stopping on breakpoint in a 32-bit program

This bug was fixed in the package gdb - 8.1-0ubuntu3.2

---
gdb (8.1-0ubuntu3.2) bionic; urgency=medium

  * Fix 32-bit ARM tagged pointer support. Addresses a regression
introduced in the previous version which broke breakpoint
support in 32-bit programs. LP: #1848200.

 -- dann frazier   Wed, 30 Oct 2019 10:20:07 -0600

** Changed in: gdb (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  gdb not stopping on breakpoint in a 32-bit program

Status in gdb package in Ubuntu:
  Fix Released
Status in gdb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
  on breakpoint when running a 32-bit application (on 64-bit Ubuntu).

  [Test Case]
  This can be reproduced with a simple “hello world” program:

  $ cat hello.c
  #include 
  int main()
  {
     // printf() displays the string inside quotation
     printf("Hello, World!");
     return 0;
  }
  $ gcc -ggdb -m32 hello.c
  $ gdb a.out
  (gdb) b hello.c:5
  Breakpoint 1 at 0x536: file hello.c, line 5.
  (gdb) run
  Starting program: /home/user/sandbox/a.out
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.

  --- (and not stopping nor outputting the text…) ---

  [Regression Risk]
  Test case ran on arm64 and regression tested using the above test case on 
amd64, i386 and s390x.

  This regression was fixed on the upstream gdb-8.1 branch within a few
  weeks of the breakage back in May 2018. Since then there have been no
  other fixes in this area on that branch, implying this fixed the issue
  and there were no further regressions discovered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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 1848200] Update Released

The verification of the Stable Release Update for gdb has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  gdb not stopping on breakpoint in a 32-bit program

Status in gdb package in Ubuntu:
  Fix Released
Status in gdb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
  on breakpoint when running a 32-bit application (on 64-bit Ubuntu).

  [Test Case]
  This can be reproduced with a simple “hello world” program:

  $ cat hello.c
  #include 
  int main()
  {
     // printf() displays the string inside quotation
     printf("Hello, World!");
     return 0;
  }
  $ gcc -ggdb -m32 hello.c
  $ gdb a.out
  (gdb) b hello.c:5
  Breakpoint 1 at 0x536: file hello.c, line 5.
  (gdb) run
  Starting program: /home/user/sandbox/a.out
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.

  --- (and not stopping nor outputting the text…) ---

  [Regression Risk]
  Test case ran on arm64 and regression tested using the above test case on 
amd64, i386 and s390x.

  This regression was fixed on the upstream gdb-8.1 branch within a few
  weeks of the breakage back in May 2018. Since then there have been no
  other fixes in this area on that branch, implying this fixed the issue
  and there were no further regressions discovered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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 1851564] Re: Daily Limit Exceeded messages for google calendars

2019-11-07 Thread Sebastien Bacher

Thank you for your bug report, it's probably
https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/42 , GNOME
failing to get their API key re-approved by Google, hopefully they sort
it out soon though

** Bug watch added: gitlab.gnome.org/GNOME/gnome-online-accounts/issues #42
   https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/42

** Package changed: gnome-calendar (Ubuntu) => gnome-online-accounts
(Ubuntu)

** Changed in: gnome-online-accounts (Ubuntu)
   Importance: Undecided => High

** Changed in: gnome-online-accounts (Ubuntu)
   Status: New => Confirmed

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

Title:
  Daily Limit Exceeded messages for google calendars

Status in gnome-online-accounts package in Ubuntu:
  Confirmed

Bug description:
  This seems to coincide with the 19.04 -> 19.10 upgrade, but I only
  have logs going back to mid august.  The message is repeated for each
  calendar at various times.

  Nov 06 13:49:13 dipper gnome-calendar[8681]:
  source_credentials_required_cb: Failed to authenticate 'Kai Groner':
  Daily Limit Exceeded. The quota will be reset at midnight Pacific Time
  (PT). You may monitor your quota usage and adjust limits in the API
  Console:
  
https://console.developers.google.com/apis/api/caldav.googleapis.com/quotas?project=44438659992

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-calendar 3.34.2-1
  ProcVersionSignature: Ubuntu 5.3.0-19.20+kai1-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  6 15:07:56 2019
  InstallationDate: Installed on 2019-06-18 (141 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=tmux-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-calendar
  UpgradeStatus: Upgraded to eoan on 2019-10-23 (14 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1851564/+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 540751] Re: Unable to use dead keys with java and ibus

2019-11-07 Thread Sebastien Bacher

The bug here is old, rather than reopening it please open a new one
using 'ubuntu-bug ibus' with a detailled description of the issue and
how to trigger it

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

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

Title:
  Unable to use dead keys with java and ibus

Status in ibus package in Ubuntu:
  Invalid
Status in openjdk-6 package in Ubuntu:
  Invalid
Status in openjdk-7 package in Ubuntu:
  Invalid

Bug description:
  Using latest Lucid packages, I am unable to use ^ key to generate ê
  french character in every Java programs (jEdit, Netbeans, etc.).

  Typing ^ + e give just the e character.
  Typing ^ + Space and nothing appears.

  I've tried with Sun JDK (6u18, 6u20, 7) and the bug is still present.

  I've tried to remove ibus and everything works again (I've just unset
  XMODIFIERS and GTK_IM_MODULE).

  I don't know if it's an ibus bug or openjdk one.

  ProblemType: Bug
  Architecture: amd64
  Date: Thu Mar 18 09:03:11 2010
  DistroRelease: Ubuntu 10.04
  ExecutablePath: /usr/lib/jvm/java-6-openjdk/jre/bin/java
  InstallationMedia: Error: [Errno 13] Permission non accordée: 
'/var/log/installer/media-info'
  NonfreeKernelModules: nvidia
  Package: openjdk-6-jre-headless 6b18~pre2-1ubuntu1
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=fr_FR.utf8
  ProcVersionSignature: Ubuntu 2.6.32-16.25-genUser Name
  SourcePackage: openjdk-6
  Uname: Linux 2.6.32-16-generic x86_64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/540751/+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 1851564] [NEW] Daily Limit Exceeded messages for google calendars