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

2020-09-22 Thread Ubuntu Foundations Team Bug Bot
The attachment "allow-classic.diff" seems to be a patch.  If it isn't,
please remove the "patch" flag from the attachment, remove the "patch"
tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the
team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

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

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

Status in pulseaudio package in Ubuntu:
  New

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

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

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

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

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

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

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

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

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

  Open a shell in its sandbox:

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

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

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

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

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

  EXPECTED BEHAVIOUR
  ==

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

  ACTUAL BEHAVIOUR
  

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

  ADDITIONAL INFORMATION
  ==

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

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

[Touch-packages] [Bug 1896073] Re: SRU the current 2.3.6 stable update

2020-09-22 Thread Chris Halse Rogers
This doesn't really seem to be a bugfix only release? It's not clear to
me how introducing a new “tracker export” command is a bugfix - I could
be persuaded of this, as it sounds from the NEWS item that it might be
required for future upgrades?

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

Title:
  SRU the current 2.3.6 stable update

Status in tracker package in Ubuntu:
  Fix Released

Bug description:
  * Impact
  That's the current GNOME stable update, including some fixes and translation 
updates
  https://gitlab.gnome.org/GNOME/tracker/-/blob/tracker-2.3/NEWS

  * Test case

  The update is part of GNOME stable updates
  https://wiki.ubuntu.com/StableReleaseUpdates/GNOME

  Check that file search works correctly from the command line, shell
  and nautilus

  * Regression potential

  There is no specific change or feature to test in that update

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1896073/+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 1896708] [NEW] [Infoway, Realtek ALC268, Speaker, Internal] No sound at all

2020-09-22 Thread Vitor Vecchi de Oliveira
Public bug reported:

Welcome to Linux Lite 4.8 vec
 
terça 22 setembro 2020, 23:24:41
Memory Usage: 1949/2992MB (65.14%)
Disk Usage: 19/22GB (91%)
Support - https://www.linuxliteos.com/forums/ (Right click, Open Link)
 
 vec  ~  pacmd
Welcome to PulseAudio 11.1! Use "help" for usage information.
>>> list-sinks
1 sink(s) available.
  * index: 0
name: 
driver: 
flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY 
DYNAMIC_LATENCY
state: RUNNING
suspend cause: 
priority: 9039
volume: front-left: 58327 /  89% / -3,04 dB,   front-right: 58327 /  
89% / -3,04 dB
balance 0,00
base volume: 65536 / 100% / 0,00 dB
volume steps: 65537
muted: no
current latency: 18,42 ms
max request: 3 KiB
max rewind: 64 KiB
monitor source: 0
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
 Estéreo
used by: 1
linked by: 13
configured latency: 18,75 ms; range is 0,50 .. 371,52 ms
card: 0 
module: 6
properties:
alsa.resolution_bits = "16"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "ALC268 Analog"
alsa.id = "ALC268 Analog"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "0"
alsa.card = "0"
alsa.card_name = "HDA Intel"
alsa.long_card_name = "HDA Intel at 0xf450 irq 28"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-:00:1b.0"
sysfs.path = "/devices/pci:00/:00:1b.0/sound/card0"
device.bus = "pci"
device.vendor.id = "8086"
device.vendor.name = "Intel Corporation"
device.product.id = "284b"
device.product.name = "82801H (ICH8 Family) HD Audio Controller"
device.form_factor = "internal"
device.string = "front:0"
device.buffering.buffer_size = "65536"
device.buffering.fragment_size = "32768"
device.access_mode = "mmap+timer"
device.profile.name = "analog-stereo"
device.profile.description = "Estéreo analógico"
device.description = "Áudio interno Estéreo analógico"
alsa.mixer_name = "Realtek ALC268"
alsa.components = "HDA:10ec0268,2f111509,0013 
HDA:14f12bfa,14f10001,0009"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-pci"
ports:
analog-output-speaker: Alto-falantes (priority 1, latency 
offset 0 usec, available: unknown)
properties:
device.icon_name = "audio-speakers"
analog-output-headphones: Fones de ouvidos (priority 9000, 
latency offset 0 usec, available: no)
properties:
device.icon_name = "audio-headphones"
active port: 
>>> 


Welcome to Linux Lite 4.8 vec
 
terça 22 setembro 2020, 23:25:29
Memory Usage: 1981/2992MB (66.21%)
Disk Usage: 19/22GB (91%)
Support - https://www.linuxliteos.com/forums/ (Right click, Open Link)
 
 vec  ~  sudo aplay -l
[sudo] senha para vec: 
 Lista de Dispositivos PLAYBACK Hardware 
placa 0: Intel [HDA Intel], dispositivo 0: ALC268 Analog [ALC268 Analog]
  Dispositivo secundário: 0/1
  Dispositivo secundário #0: subdevice #0
placa 0: Intel [HDA Intel], dispositivo 1: ALC268 Digital [ALC268 Digital]
  Dispositivo secundário: 1/1
  Dispositivo secundário #0: subdevice #0
 vec  ~  


Welcome to Linux Lite 4.8 vec
 
terça 22 setembro 2020, 23:26:41
Memory Usage: 1990/2992MB (66.51%)
Disk Usage: 19/22GB (91%)
Support - https://www.linuxliteos.com/forums/ (Right click, Open Link)
 
 vec  ~  find /lib/modules/`uname -r` | grep snd
/lib/modules/4.15.0-76-generic/kernel/sound/isa/sb/snd-sb-common.ko
/lib/modules/4.15.0-76-generic/kernel/sound/hda/ext/snd-hda-ext-core.ko
/lib/modules/4.15.0-76-generic/kernel/sound/hda/snd-hda-core.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/snd-i2c.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/other/snd-ak4117.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/other/snd-ak4xxx-adda.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/other/snd-ak4113.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/other/snd-ak4114.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/other/snd-pt2258.ko
/lib/modules/4.15.0-76-generic/kernel/sound/i2c/snd-cs8427.ko
/lib/modules/4.15.0-76-generic/kernel/sound/soc/snd-soc-core.ko
/lib/modules/4.15.0-76-generic/kernel/sound/soc/generic/snd-soc-simple-card-utils.ko

[Touch-packages] [Bug 1894195] Re: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

2020-09-22 Thread Alex Murray
I have done the merge and uploaded it to the security-proposed PPA -
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa -
and have confirmed the iptables autopkgtest tests all pass as well as
the ufw tests.

Oibaf - since you requested this, would you be able to also test this?

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

Title:
  FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

Status in iptables package in Ubuntu:
  New

Bug description:
  Please merge iptables 1.8.5-3 (main) from Debian sid (main)

  Explanation of FeatureFreeze exception:
  Current iptables is using the same upstream version in focal, which had 
problems with the nft backend and was then reverted to the legacy backend.
  1.8.5 has many fixes for the nft backend. For example these Debian bugs are 
fixed in 1.8.5:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950535
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961117
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968457
  Please merge it.

  Changelog entries since current groovy version 1.8.4-3ubuntu3:

  iptables (1.8.5-3) unstable; urgency=medium

    * [2d587e5] src:iptables: bump build-dep version on libnftnl to
  1.1.6

   -- Arturo Borrero Gonzalez   Tue, 25 Aug 2020
  11:56:55 +0200

  iptables (1.8.5-2) unstable; urgency=medium

    [ Alberto Molina Coballes ]
    * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576)
    * [4754a45] d/not-installed: arch independ files
    * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly

    [ Arturo Borrero Gonzalez ]
    * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch
  (Closes: #962724)

   -- Arturo Borrero Gonzalez   Wed, 24 Jun 2020
  10:56:19 +0200

  iptables (1.8.5-1) unstable; urgency=medium

    [ Debian Janitor ]
    * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1,
    1.6.0-1.
    * [214468e] Update standards version to 4.5.0, no changes needed.

    [ Arturo Borrero Gonzalez ]
    * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535)
    * [7a119db] d/patches: drop all patches
    * [ec63c87] libxtables12.symbols: add new symbol
    * [4056ce6] iptables: bump debhelper-compat to 13

   -- Arturo Borrero Gonzalez   Thu, 04 Jun 2020
  13:33:22 +0200

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

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

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

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

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

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

Status in pulseaudio package in Ubuntu:
  New

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

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

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

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

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

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

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

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

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

  Open a shell in its sandbox:

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

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

  Succeeds and fails apparently at random.

  Now from a non-sandboxed shell, run

  pacmd unload-module module-snap-policy

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

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

  EXPECTED BEHAVIOUR
  ==

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

  ACTUAL BEHAVIOUR
  

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

  ADDITIONAL INFORMATION
  ==

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

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

[Touch-packages] [Bug 1887425] Re: php files now open by default in Chrome

2020-09-22 Thread Adolfo Jayme
** Package changed: meta-gnome3 (Ubuntu) => shared-mime-info (Ubuntu)

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

Title:
  php files now open by default in Chrome

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

Bug description:
  Until at least 16.04, php files used to open by default in Gedit.

  I'm talking about when you double click on them in Nautilus (or the
  first "open with " options that shows up in the right-
  click menu)

  After I upgraded to 20.04 (not sure in which version the change was),
  now they open by default in Google Chrome. (I guess they open in the
  default browser which in my case is Chrome).

  This is a stupid default. Do I need to explain to you that php files
  are executed on the server? Opening them in a browser makes no sense
  in 99.99% of cases. When one opens a php file locally, the most
  likely scenario is that you are opening it in order to edit it.

  So if you had switched from gedit to some other text editor I could
  understand it, but opening it in the browser by default is an idiotic
  default for php files.

  I upgraded because I was sick of running age-old versions of almost
  every program, most no longer supported and full of bugs that were
  fixed years ago upstream, but I'm astonished at the amount of
  regressions and, worse, idiotic design decisions that have either been
  taken either with the specific purpose of making things worse, or were
  taken by idiots that didn't put the slightest amount of thought in it.

  Fucking unbelievable. Every major release of Ubuntu is a step backwards.
  Mostly because of Gnome.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gnome (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
  Uname: Linux 5.4.0-40-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.20.11-0ubuntu27.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul 13 21:10:37 2020
  InstallationDate: Installed on 2013-10-11 (2467 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  SourcePackage: meta-gnome3
  UpgradeStatus: Upgraded to focal on 2020-07-12 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1887425/+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 1887425] [NEW] php files now open by default in Chrome

2020-09-22 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

Until at least 16.04, php files used to open by default in Gedit.

I'm talking about when you double click on them in Nautilus (or the
first "open with " options that shows up in the right-click
menu)

After I upgraded to 20.04 (not sure in which version the change was),
now they open by default in Google Chrome. (I guess they open in the
default browser which in my case is Chrome).

This is a stupid default. Do I need to explain to you that php files are
executed on the server? Opening them in a browser makes no sense in
99.99% of cases. When one opens a php file locally, the most likely
scenario is that you are opening it in order to edit it.

So if you had switched from gedit to some other text editor I could
understand it, but opening it in the browser by default is an idiotic
default for php files.

I upgraded because I was sick of running age-old versions of almost
every program, most no longer supported and full of bugs that were fixed
years ago upstream, but I'm astonished at the amount of regressions and,
worse, idiotic design decisions that have either been taken either with
the specific purpose of making things worse, or were taken by idiots
that didn't put the slightest amount of thought in it.

Fucking unbelievable. Every major release of Ubuntu is a step backwards.
Mostly because of Gnome.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome (not installed)
ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
Uname: Linux 5.4.0-40-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.20.11-0ubuntu27.3
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Mon Jul 13 21:10:37 2020
InstallationDate: Installed on 2013-10-11 (2467 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: meta-gnome3
UpgradeStatus: Upgraded to focal on 2020-07-12 (1 days ago)

** Affects: shared-mime-info (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal
-- 
php files now open by default in Chrome
https://bugs.launchpad.net/bugs/1887425
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to shared-mime-info in Ubuntu.

-- 
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 1895839] Re: CVE-2020-24977

2020-09-22 Thread Avital Ostromich
** Description changed:

+ GNOME project libxml2 v2.9.10 and earlier have a global buffer over-read
+ vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.
+ 
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977
  
- Upstream patch:
- 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/8e7c20a1af8776677d7890f30b7a180567701a49
+ Upstream patch: 
+ 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2
  
- GNOME project libxml2 v2.9.10 and earlier have a global buffer over-read
- vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.
+ Bug report: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178

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

Title:
  CVE-2020-24977

Status in libxml2 package in Ubuntu:
  New
Status in libxml2 package in Debian:
  Unknown

Bug description:
  GNOME project libxml2 v2.9.10 and earlier have a global buffer over-
  read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.

  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977

  Upstream patch: 
  
https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2

  Bug report: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1895839/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Alex Murray
Christian - thanks for your work on debugging this - can you please
remove the block-proposed tag if you are happy that 3.0.0~beta1-0ubuntu6
resolves this issue?

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895839] Re: CVE-2020-24977

2020-09-22 Thread Avital Ostromich
** Description changed:

  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977
  
  Upstream patch:
  
https://gitlab.gnome.org/GNOME/libxml2/-/commit/8e7c20a1af8776677d7890f30b7a180567701a49
+ 
+ GNOME project libxml2 v2.9.10 and earlier have a global buffer over-read
+ vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.

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

Title:
  CVE-2020-24977

Status in libxml2 package in Ubuntu:
  New
Status in libxml2 package in Debian:
  Unknown

Bug description:
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977

  Upstream patch:
  
https://gitlab.gnome.org/GNOME/libxml2/-/commit/8e7c20a1af8776677d7890f30b7a180567701a49

  GNOME project libxml2 v2.9.10 and earlier have a global buffer over-
  read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1895839/+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 1890716] Re: misidentifies .html file as Perl script when it contains JavaScript "use strict"

2020-09-22 Thread Alex A. D.
** Also affects: kde-cli-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  misidentifies .html file as Perl script when it contains JavaScript
  "use strict"

Status in shared-mime-info:
  Unknown
Status in kde-cli-tools package in Ubuntu:
  New
Status in shared-mime-info package in Ubuntu:
  New
Status in shared-mime-info package in Debian:
  Unknown

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/shared-mime-info/+bug/1890716/+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 1857824] Re: kmimetypefinder5 misidentifies mimetype of python files containing certain strings

2020-09-22 Thread Kai Kasurinen
** Package changed: kde-cli-tools (Ubuntu) => shared-mime-info (Ubuntu)

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

Title:
  kmimetypefinder5 misidentifies mimetype of python files containing
  certain strings

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

Bug description:
  Expected behavior:

  $ kmimetypefinder5 example.py 
  text/x-python3

  or

  $ kmimetypefinder5 example.py 
  text/x-python

  or

  $ kmimetypefinder5 example.py 
  text/plain

  Actual behavior:

  $ kmimetypefinder5 example.py 
  application/xhtml+xml

  Summary: Python scripts with a string containing HTML can be
  misidentified as HTML files by kmimetypefinder5.

  For example, this python script is identified as
  "application/xhtml+xml":

  #! /usr/bin/env python3
  example_string = \
  """\
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
  http://www.w3.org/1999/xhtml;>

  Example title


  Example body

  
  """
  print('Hello, world!')

  This difficulty is not shared by other mimetype identification tools.

  $ kmimetypefinder5 example.py 
  application/xhtml+xml
  $ cat example2.py #! /usr/bin/env python3
  print('Hello, world!')
  $ kmimetypefinder5 example2.py 
  text/x-python3
  $ mimetype 'example.py'
  example.py: text/x-python
  $ mimetype 'example2.py'
  example2.py: text/x-python
  $ file --mime-type 'example.py'
  example.py: text/plain
  $ file --mime-type 'example2.py'
  example2.py: text/plain

  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04
  $ apt-cache policy kde-cli-tools
  kde-cli-tools:
Installed: 4:5.12.8-0ubuntu0.1
Candidate: 4:5.12.8-0ubuntu0.1
Version table:
   *** 4:5.12.8-0ubuntu0.1 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages
  100 /var/lib/dpkg/status
   4:5.12.4-0ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: kde-cli-tools 4:5.12.8-0ubuntu0.1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sun Dec 29 13:28:37 2019
  InstallationDate: Installed on 2018-12-12 (381 days ago)
  InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: kde-cli-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1857824/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type

2020-09-22 Thread Kai Kasurinen
** Changed in: shared-mime-info (Ubuntu)
   Status: Invalid => New

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

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

** Summary changed:

- kmimetypefinder5 *.html reports wrong type
+ misidentifies .html file as Perl script when it contains JavaScript "use 
strict"

** Bug watch added: gitlab.freedesktop.org/xdg/shared-mime-info/-/issues #80
   https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/80

** Also affects: shared-mime-info via
   https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/80
   Importance: Unknown
   Status: Unknown

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

Title:
  misidentifies .html file as Perl script when it contains JavaScript
  "use strict"

Status in shared-mime-info:
  Unknown
Status in shared-mime-info package in Ubuntu:
  New
Status in shared-mime-info package in Debian:
  Unknown

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/shared-mime-info/+bug/1890716/+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 1857824] [NEW] kmimetypefinder5 misidentifies mimetype of python files containing certain strings

2020-09-22 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

Expected behavior:

$ kmimetypefinder5 example.py 
text/x-python3

or

$ kmimetypefinder5 example.py 
text/x-python

or

$ kmimetypefinder5 example.py 
text/plain

Actual behavior:

$ kmimetypefinder5 example.py 
application/xhtml+xml

Summary: Python scripts with a string containing HTML can be
misidentified as HTML files by kmimetypefinder5.

For example, this python script is identified as
"application/xhtml+xml":

#! /usr/bin/env python3
example_string = \
"""\
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml;>
  
Example title
  
  
Example body
  

"""
print('Hello, world!')

This difficulty is not shared by other mimetype identification tools.

$ kmimetypefinder5 example.py 
application/xhtml+xml
$ cat example2.py #! /usr/bin/env python3
print('Hello, world!')
$ kmimetypefinder5 example2.py 
text/x-python3
$ mimetype 'example.py'
example.py: text/x-python
$ mimetype 'example2.py'
example2.py: text/x-python
$ file --mime-type 'example.py'
example.py: text/plain
$ file --mime-type 'example2.py'
example2.py: text/plain

$ lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04
$ apt-cache policy kde-cli-tools
kde-cli-tools:
  Installed: 4:5.12.8-0ubuntu0.1
  Candidate: 4:5.12.8-0ubuntu0.1
  Version table:
 *** 4:5.12.8-0ubuntu0.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages
100 /var/lib/dpkg/status
 4:5.12.4-0ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: kde-cli-tools 4:5.12.8-0ubuntu0.1
ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
Uname: Linux 4.15.0-72-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Dec 29 13:28:37 2019
InstallationDate: Installed on 2018-12-12 (381 days ago)
InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
SourcePackage: kde-cli-tools
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: shared-mime-info (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic third-party-packages
-- 
kmimetypefinder5 misidentifies mimetype of python files containing certain 
strings
https://bugs.launchpad.net/bugs/1857824
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to shared-mime-info in Ubuntu.

-- 
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 1732962] Re: apport uses sys.argv instead of named arguments

2020-09-22 Thread Matthieu Clemenceau
** Patch added: "diff for bionic to support named param. (backport from cosmic)"
   
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5413349/+files/apport_2.20.9-0ubuntu7.18.debdiff

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

Title:
  apport uses sys.argv instead of named arguments

Status in Apport:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Trusty:
  Won't Fix
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Cosmic:
  Won't Fix
Status in apport source package in Disco:
  Fix Released

Bug description:
  SRU Description

  [Impact]
  data/apport which processes core files expects a certain quantity of 
arguments in a specific order. This ended up causing an issue with some 
security updates where we were trying to support a new version of apport on a 
host system and one inside a container. 
  This SRU for xenial and bionic based on the work made in cosmic enabled 
proper handling of named argument.
  Note that this is disabled for now on ALL series
   
  [Test Case]
  No real test here since apport general behavior should be unchanged Just to 
check that the feature is disable, /proc/sys/kernel/core_pattern
  content should remain unchanged :

  $> cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport %p %s %c %d %P %E

  [Regression Potential]
  The new feature is not enabled so the regression risk is fairly low. this 
will take place in a future coordinated SRU across all LTS but in the meanwhile 
we can make sure that there's no regression by running apport with various 

  End SRU Description

  data/apport which processes core files expects a certain quantity of
  arguments in a specific order. This ended up causing an issue with
  some security updates where we were trying to support a new version of
  apport on a host system and one inside a container.  Here's something
  of an example:

  347 # Normal startup
  348 if len(sys.argv) not in (5, 6):
  349 try:
  350 print('Usage: %s [global pid]' % sys.argv[0])
  351 print('The core dump is read from stdin.')

  We could not maintain backwards compatibility because "global pid" is
  an optional argument and "dump mode" was a new argument. So if there
  were five arguments its possible the last one was "dump mode" (no
  global pid) or "global pid" (no support for dump mode).

  Its possible to use strings in /proc/sys/kernel/core_pattern so we
  could use those and have apport accept named arguments e.g:

  $ cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d 
--global-pid=%P

  ['/home/bdmurray/source-trees/apport/artful/data/apport', '--
  pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
  pid=5870']

  Tyler said "that's probably a nice cleanup to make no matter what
  because the magic arg ordering is dangerous".

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1732962] Re: apport uses sys.argv instead of named arguments

2020-09-22 Thread Matthieu Clemenceau
** Patch removed: "diff for xenial to support named param. (backport from 
cosmic)"
   
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5405275/+files/apport_2.20.1-0ubuntu2.25.debdiff

** Patch removed: "diff for bionic to support named param. (backport from 
cosmic)"
   
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5405276/+files/apport_2.20.9-0ubuntu7.18.debdiff

** Patch added: "diff for xenial to support named param. (backport from cosmic)"
   
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5413348/+files/apport_2.20.1-0ubuntu2.25.debdiff

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

Title:
  apport uses sys.argv instead of named arguments

Status in Apport:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Trusty:
  Won't Fix
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Cosmic:
  Won't Fix
Status in apport source package in Disco:
  Fix Released

Bug description:
  SRU Description

  [Impact]
  data/apport which processes core files expects a certain quantity of 
arguments in a specific order. This ended up causing an issue with some 
security updates where we were trying to support a new version of apport on a 
host system and one inside a container. 
  This SRU for xenial and bionic based on the work made in cosmic enabled 
proper handling of named argument.
  Note that this is disabled for now on ALL series
   
  [Test Case]
  No real test here since apport general behavior should be unchanged Just to 
check that the feature is disable, /proc/sys/kernel/core_pattern
  content should remain unchanged :

  $> cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport %p %s %c %d %P %E

  [Regression Potential]
  The new feature is not enabled so the regression risk is fairly low. this 
will take place in a future coordinated SRU across all LTS but in the meanwhile 
we can make sure that there's no regression by running apport with various 

  End SRU Description

  data/apport which processes core files expects a certain quantity of
  arguments in a specific order. This ended up causing an issue with
  some security updates where we were trying to support a new version of
  apport on a host system and one inside a container.  Here's something
  of an example:

  347 # Normal startup
  348 if len(sys.argv) not in (5, 6):
  349 try:
  350 print('Usage: %s [global pid]' % sys.argv[0])
  351 print('The core dump is read from stdin.')

  We could not maintain backwards compatibility because "global pid" is
  an optional argument and "dump mode" was a new argument. So if there
  were five arguments its possible the last one was "dump mode" (no
  global pid) or "global pid" (no support for dump mode).

  Its possible to use strings in /proc/sys/kernel/core_pattern so we
  could use those and have apport accept named arguments e.g:

  $ cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d 
--global-pid=%P

  ['/home/bdmurray/source-trees/apport/artful/data/apport', '--
  pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
  pid=5870']

  Tyler said "that's probably a nice cleanup to make no matter what
  because the magic arg ordering is dangerous".

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1732962] Re: apport uses sys.argv instead of named arguments

2020-09-22 Thread Matthieu Clemenceau
Updated debdiff and made sure autopkgtest were successful on both xenial
and bionic

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

Title:
  apport uses sys.argv instead of named arguments

Status in Apport:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Trusty:
  Won't Fix
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Cosmic:
  Won't Fix
Status in apport source package in Disco:
  Fix Released

Bug description:
  SRU Description

  [Impact]
  data/apport which processes core files expects a certain quantity of 
arguments in a specific order. This ended up causing an issue with some 
security updates where we were trying to support a new version of apport on a 
host system and one inside a container. 
  This SRU for xenial and bionic based on the work made in cosmic enabled 
proper handling of named argument.
  Note that this is disabled for now on ALL series
   
  [Test Case]
  No real test here since apport general behavior should be unchanged Just to 
check that the feature is disable, /proc/sys/kernel/core_pattern
  content should remain unchanged :

  $> cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport %p %s %c %d %P %E

  [Regression Potential]
  The new feature is not enabled so the regression risk is fairly low. this 
will take place in a future coordinated SRU across all LTS but in the meanwhile 
we can make sure that there's no regression by running apport with various 

  End SRU Description

  data/apport which processes core files expects a certain quantity of
  arguments in a specific order. This ended up causing an issue with
  some security updates where we were trying to support a new version of
  apport on a host system and one inside a container.  Here's something
  of an example:

  347 # Normal startup
  348 if len(sys.argv) not in (5, 6):
  349 try:
  350 print('Usage: %s [global pid]' % sys.argv[0])
  351 print('The core dump is read from stdin.')

  We could not maintain backwards compatibility because "global pid" is
  an optional argument and "dump mode" was a new argument. So if there
  were five arguments its possible the last one was "dump mode" (no
  global pid) or "global pid" (no support for dump mode).

  Its possible to use strings in /proc/sys/kernel/core_pattern so we
  could use those and have apport accept named arguments e.g:

  $ cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d 
--global-pid=%P

  ['/home/bdmurray/source-trees/apport/artful/data/apport', '--
  pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
  pid=5870']

  Tyler said "that's probably a nice cleanup to make no matter what
  because the magic arg ordering is dangerous".

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type

2020-09-22 Thread Alex A. D.
I've reported a new bug providing a complete and correct description:
https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1896682

This one can be safely closed.

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

Title:
  kmimetypefinder5 *.html reports wrong type

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

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type

2020-09-22 Thread Alex A. D.
New bug reopened with complete and correct explanation: 
https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1896682

** Changed in: shared-mime-info (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  kmimetypefinder5 *.html reports wrong type

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

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1756238] Re: gdebi-gtk broken in 18.04 error: unable to read filedescriptor flags

2020-09-22 Thread Treviño
In groovy the code for vte-keep-FD patch has been refactored to support
new upstream code.

However, I think it's the time we plan to remove this next cycle, given
that gdebi is the only project using it so far [1], and that upstream
already suggested a better way to do it [2].

So, if someone is still interested in fixing gdebi to address this,
please act as otherwise it's very likely that next versions of vte will
break it.


[1] https://codesearch.debian.net/search?q=VTE_PTY_KEEP_FD=1
[2] https://bugzilla.gnome.org/show_bug.cgi?id=320128#c23

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

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

Title:
  gdebi-gtk broken in 18.04 error: unable to read filedescriptor flags

Status in gdebi package in Ubuntu:
  Triaged
Status in vte2.91 package in Ubuntu:
  Fix Released
Status in vte2.91 source package in Bionic:
  Fix Released

Bug description:
  When using gdebi-gtk to install a .deb the install fails with the
  message:-

  dpkg: error: unable to read filedescriptor flags for : Bad file descriptor

  This only occurs via the gdebi-gtk GUI front end, packages install perfectly 
if done via the CLI with:
  sudo gdebi /path/to/packagename.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1756238/+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 1894881] Re: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to detect card

2020-09-22 Thread Gilbertf
problem seems gone since 5.4.0-48-generic #52

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

Title:
  [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to
  detect card

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  kernel 5.4.0-47-generic #51
  upgraded today to this new kernel
  sound is now totally broken
  kern.org and syslog are filling with those messages every second, in loop, 
with no end to it :

  Sep  8 19:42:34 orion kernel: [  147.398030] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x20970500
  Sep  8 19:42:35 orion kernel: [  148.410043] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x20a70500
  Sep  8 19:42:36 orion kernel: [  149.413955] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x20b70500
  Sep  8 19:42:37 orion kernel: [  150.421890] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x201f0500
  Sep  8 19:42:38 orion kernel: [  151.453799] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x204f0015
  Sep  8 19:42:39 orion kernel: [  152.461793] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x204f0015
  Sep  8 19:42:41 orion kernel: [  153.473734] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x2043b000
  Sep  8 19:42:42 orion kernel: [  154.477653] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x20470740
  Sep  8 19:42:43 orion kernel: [  155.481576] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x204f0015
  Sep  8 19:42:44 orion kernel: [  156.489620] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x204f0015
  Sep  8 19:42:45 orion kernel: [  157.497553] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x2043b000
  Sep  8 19:42:46 orion kernel: [  158.509530] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x20470740
  Sep  8 19:42:47 orion kernel: [  159.513471] snd_hda_intel :00:1f.3: No 
response from codec, resetting bus: last cmd=0x204f0015

  Because of this, machine has become very slow and response time is awful
  Login into the machine, even trying to launch a simple program can take up to 
30 seconds of wait before anything happens.

  Sound was working fine with previous kernel.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: pulseaudio 1:13.99.1-1ubuntu3.6
  ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
  Uname: Linux 5.4.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.8
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  gf 1758 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Sep  8 19:42:19 2020
  InstallationDate: Installed on 2020-08-29 (9 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  SourcePackage: pulseaudio
  Symptom: audio
  Symptom_Card: HDA-Intel - HDA Intel PCH
  Symptom_Jack: Speaker, Internal
  Title: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to 
detect card
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.1.0
  dmi.board.name: 077Y9N
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.1.0:bd07/07/2020:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn077Y9N:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9300
  dmi.product.sku: 096D
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894881/+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 1890716] Re: xdg-mime query filetype index.html reports wrong type

2020-09-22 Thread Alex A. D.
After running that commands I got the following output:

$ ...
Running kmimetypefinder5 "/home/alex/Desktop/index.html"
application/x-perl


It seems like that kmimetypefinder5 is major culprit here. I've found another 
unrelated bugreport here which was reported about a year ago: 
https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1857824

In that case the program reports wrong type for *.py files with correct 
content. Weird!
I think it's wortht to rename this bugreport.

** Summary changed:

- xdg-mime query filetype index.html reports wrong type
+ kmimetypefinder5 *.html reports wrong type

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

Title:
  kmimetypefinder5 *.html reports wrong type

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

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1896646] Re: bluetooth no longer installed

2020-09-22 Thread Ubuntu Foundations Team Bug Bot
** Package changed: ubuntu => bluez (Ubuntu)

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

Title:
  bluetooth no longer installed

Status in bluez package in Ubuntu:
  New

Bug description:
  22 september 2020 update removed bluetooth capability.  No Bluetooth
  hardware detected by system, cannot turn on or add devices.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-49.53-generic 5.4.65
  Uname: Linux 5.4.0-49-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.9
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Sep 22 12:53:31 2020
  InstallationDate: Installed on 2019-12-07 (290 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  InterestingModules: bluetooth
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 0bda:57de Realtek Semiconductor Corp. USB2.0 VGA UVC 
WebCam
   Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
   |__ Port 5: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 
480M
   |__ Port 6: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
   |__ Port 6: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
  MachineType: ASUSTeK COMPUTER INC. X556UAM
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-49-generic 
root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/06/2016
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: X556UAM.305
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: X556UAM
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrX556UAM.305:bd07/06/2016:svnASUSTeKCOMPUTERINC.:pnX556UAM:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX556UAM:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: X
  dmi.product.name: X556UAM
  dmi.product.sku: ASUS-NotebookSKU
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:
   
  rfkill:
   0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1896646/+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 1896646] [NEW] bluetooth no longer installed

2020-09-22 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

22 september 2020 update removed bluetooth capability.  No Bluetooth
hardware detected by system, cannot turn on or add devices.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: bluetooth (not installed)
ProcVersionSignature: Ubuntu 5.4.0-49.53-generic 5.4.65
Uname: Linux 5.4.0-49-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 22 12:53:31 2020
InstallationDate: Installed on 2019-12-07 (290 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
InterestingModules: bluetooth
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 0bda:57de Realtek Semiconductor Corp. USB2.0 VGA UVC 
WebCam
 Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
 |__ Port 5: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M
 |__ Port 6: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
 |__ Port 6: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
MachineType: ASUSTeK COMPUTER INC. X556UAM
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-49-generic 
root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/06/2016
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: X556UAM.305
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: X556UAM
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrX556UAM.305:bd07/06/2016:svnASUSTeKCOMPUTERINC.:pnX556UAM:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX556UAM:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.family: X
dmi.product.name: X556UAM
dmi.product.sku: ASUS-NotebookSKU
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
hciconfig:
 
rfkill:
 0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

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


** Tags: amd64 apport-bug focal
-- 
bluetooth no longer installed
https://bugs.launchpad.net/bugs/1896646
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to bluez in Ubuntu.

-- 
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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
I uploaded 3.0.0~beta1-0ubuntu6 just now that should address this issue.
Thanks Christian for your debugging!

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

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1871148] Re: services start before apparmor profiles are loaded

2020-09-22 Thread Jamie Strandboge
This was fixed in snapd in 2.44 via
https://github.com/snapcore/snapd/pull/8467

** Changed in: snapd (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: snapd (Ubuntu Focal)
   Status: In Progress => Fix Released

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in snapd source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1894606] Re: [SRU] Add profile-set for HP Thunderbolt Dock

2020-09-22 Thread Launchpad Bug Tracker
This bug was fixed in the package pulseaudio - 1:13.99.1-1ubuntu11

---
pulseaudio (1:13.99.1-1ubuntu11) groovy; urgency=medium

  [ Kai-Heng Feng ]
  * d/p/0001-alsa-mixer-Add-support-for-HP-Thunderbolt-Dock.patch
  * d/p/0002-alsa-mixer-Expand-comments-in-the-HP-Thunderbolt-Doc.patch
Add profile-sets for HP Thunderbolt Dock (LP: #1894606)

 -- Alberto Milone   Tue, 22 Sep 2020
10:09:09 +0200

** Changed in: pulseaudio (Ubuntu Groovy)
   Status: In Progress => Fix Released

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

Title:
  [SRU] Add profile-set for HP Thunderbolt Dock

Status in HWE Next:
  New
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  In Progress
Status in pulseaudio source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  HP Thunderbolt Dock has a USB audio device provides headset connector 
functionality. The Dock can also attach an optional USB audio module. Since 
they are both USB audio device, the input/output names are the same and it 
confuses user.

  [Fix]
  Add PulseAudio profile-sets for each USB device with different monikers.

  The merge request is already approved by maintainer, will be merged after 
14.0 release:
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/353

  [Test]
  With profile-set applied, two different USB audio device on HP TBT Dock have 
distinctive names.

  [Regression Potential]
  Currently I can't think of any regression risk, as this SRU only adds new 
profile-sets and description translation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1894606/+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 1896645] [NEW] Dual screen window size problem

2020-09-22 Thread Mitchell
Public bug reported:

Certain programs don't seem to co-operate well with a dual monitor
setup. If it is of any importance, my setup is a laptop with a TV
plugged in via HDMI. So far I've found that VLC media player and Oracle
Virtualbox won't play nicely with two monitors. When both monitors are
in use, virtualbox crashes before it can open, and vlc tends to freeze
the entire system, requiring a hard reboot. If I run these programs
while only one monitor is being used and plug in the second one, they'll
start misbehaving if moved to the other monitor. virtualbox and vlc will
both become way too huge to be usable.

Description:Ubuntu 18.04.5 LTS
Release:18.04

xorg:
  Installed: 1:7.7+19ubuntu7.1
  Candidate: 1:7.7+19ubuntu7.1
  Version table:
 *** 1:7.7+19ubuntu7.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 1:7.7+19ubuntu7 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55
Uname: Linux 5.4.0-47-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.17
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 22 12:02:21 2020
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
   Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364]
InstallationDate: Installed on 2020-02-21 (214 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 
(20200203.1)
MachineType: HP HP Pavilion Laptop 15-cc0xx
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=
 PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic 
root=UUID=da68f1b9-ec5f-4962-8098-08f28713396e ro quiet splash vt.handoff=1
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/03/2017
dmi.bios.vendor: Insyde
dmi.bios.version: F.13
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 8364
dmi.board.vendor: HP
dmi.board.version: 46.23
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnInsyde:bvrF.13:bd11/03/2017:svnHP:pnHPPavilionLaptop15-cc0xx:pvrType1ProductConfigId:rvnHP:rn8364:rvr46.23:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Pavilion
dmi.product.name: HP Pavilion Laptop 15-cc0xx
dmi.product.sku: 1KU17UA#ABA
dmi.product.version: Type1ProductConfigId
dmi.sys.vendor: HP
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1
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

** Attachment added: "Screen recordings of some of the issues"
   
https://bugs.launchpad.net/bugs/1896645/+attachment/5413232/+files/multiple-screen-problem.tar.xz

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

Title:
  Dual screen window size problem

Status in xorg package in Ubuntu:
  New

Bug description:
  Certain programs don't seem to co-operate well with a dual monitor
  setup. If it is of any importance, my setup is a laptop with a TV
  plugged in via HDMI. So far I've found that VLC media player and
  Oracle Virtualbox won't play nicely with two monitors. When both
  monitors are in use, virtualbox crashes before it can open, and vlc
  tends to freeze the entire system, requiring a hard reboot. If I run
  these programs while only one monitor is being used and plug in the
  second one, they'll start misbehaving if moved to the other monitor.
  virtualbox and vlc will both become way too huge to be usable.

  Description:  Ubuntu 18.04.5 LTS
  Release:  18.04

  xorg:
Installed: 1:7.7+19ubuntu7.1
Candidate: 1:7.7+19ubuntu7.1
Version table:
   *** 1:7.7+19ubuntu7.1 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:7.7+19ubuntu7 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 

[Touch-packages] [Bug 1896644] [NEW] Dual screen window size problem

2020-09-22 Thread Mitchell
Public bug reported:

Certain programs don't seem to co-operate well with a dual monitor
setup. If it is of any importance, my setup is a laptop with a TV
plugged in via HDMI. So far I've found that VLC media player and Oracle
Virtualbox won't play nicely with two monitors. When both monitors are
in use, virtualbox crashes before it can open, and vlc tends to freeze
the entire system, requiring a hard reboot. If I run these programs
while only one monitor is being used and plug in the second one, they'll
start misbehaving if moved to the other monitor. virtualbox and vlc will
both become way too huge to be usable.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55
Uname: Linux 5.4.0-47-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.17
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 22 12:02:21 2020
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
   Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364]
InstallationDate: Installed on 2020-02-21 (214 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 
(20200203.1)
MachineType: HP HP Pavilion Laptop 15-cc0xx
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=
 PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic 
root=UUID=da68f1b9-ec5f-4962-8098-08f28713396e ro quiet splash vt.handoff=1
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/03/2017
dmi.bios.vendor: Insyde
dmi.bios.version: F.13
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 8364
dmi.board.vendor: HP
dmi.board.version: 46.23
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnInsyde:bvrF.13:bd11/03/2017:svnHP:pnHPPavilionLaptop15-cc0xx:pvrType1ProductConfigId:rvnHP:rn8364:rvr46.23:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Pavilion
dmi.product.name: HP Pavilion Laptop 15-cc0xx
dmi.product.sku: 1KU17UA#ABA
dmi.product.version: Type1ProductConfigId
dmi.sys.vendor: HP
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1
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

** Attachment added: "Screen recordings of some of the issues"
   
https://bugs.launchpad.net/bugs/1896644/+attachment/5413216/+files/multiple-screen-problem.tar.xz

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

Title:
  Dual screen window size problem

Status in xorg package in Ubuntu:
  New

Bug description:
  Certain programs don't seem to co-operate well with a dual monitor
  setup. If it is of any importance, my setup is a laptop with a TV
  plugged in via HDMI. So far I've found that VLC media player and
  Oracle Virtualbox won't play nicely with two monitors. When both
  monitors are in use, virtualbox crashes before it can open, and vlc
  tends to freeze the entire system, requiring a hard reboot. If I run
  these programs while only one monitor is being used and plug in the
  second one, they'll start misbehaving if moved to the other monitor.
  virtualbox and vlc will both become way too huge to be usable.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55
  Uname: Linux 5.4.0-47-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.17
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Sep 22 12:02:21 2020
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
 Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364]
  InstallationDate: Installed on 2020-02-21 (214 days ago)
  InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 
(20200203.1)
  MachineType: HP HP Pavilion Laptop 15-cc0xx
  ProcEnviron:
   LANG=en_US.UTF-8
   SHELL=/bin/bash
   TERM=xterm-256color
   

[Touch-packages] [Bug 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal

2020-09-22 Thread Seth Arnold
Please use CVE-2020-16122 for this issue. Thanks.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-16122

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

Title:
  Packagekit lets user install untrusted local packages in Bionic and
  Focal

Status in packagekit package in Ubuntu:
  Triaged

Bug description:
  We have packagekit configured to allow users to install trusted
  packages from preconfigured repositories, but disallowed them to
  install any untrusted packages.

  The policykit configuration we use is following:

  [tld.univ.packagekit]
  Identity=unix-group:adm;
  
Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system;
  ResultAny=auth_self
  ResultActive=auth_self
  ResultInactive=auth_self

  [tld.univ.packagekit-deny]
  Identity=unix-user:*;
  Action=org.freedesktop.packagekit.package-install-untrusted;
  ResultAny=no

  We would expect this to prevent users from installing local packages
  downloaded from random repositories, however this does not seem to be
  the case.

  pkcon install-local random_package.deb will happily prompt for the
  user to authenticate and will install the package, while pkcon
  --allow-untrusted install-local random_package.deb will prompt for
  root password, which the user does not have.

  Our initial toughts was that the issue would be in packagekitd, but
  after further investigations it looks like the issue could be in aptcc
  backend.

  We are more than happy to provide you with further details, but the
  above should be enough to reproduce the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'

2020-09-22 Thread Masroor
This is growing my syslog file like crazy. Often running out of space in
/var partition (yes, I have a different partition for this).

Deleting the files /var/crash/ stops this. Restarts again after a
reboot.

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

Title:
  systemd 100% cpu usage apport-autoreport.service: Failed with result
  'start-limit-hit'

Status in apport package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  In Progress
Status in apport source package in Groovy:
  Confirmed
Status in systemd source package in Groovy:
  In Progress

Bug description:
  after upgrade from Ubuntu 20.04 to 20.10  
  seeing systemd use 100% cpu forever


  top

top - 10:16:19 up 20 min,  1 user,  load average: 3.91, 4.28, 3.39
Tasks: 332 total,   2 running, 330 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.7 us,  6.4 sy, 11.9 ni, 62.2 id,  0.0 wa,  0.0 hi,  0.8 si, 
 0.0 st
MiB Mem :  15917.6 total,   8553.4 free,   2604.3 used,   4759.9 
buff/cache
MiB Swap:   2048.0 total,   2048.0 free,  0.0 used.  12633.7 avail 
Mem 

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND  
  1 root  20   0  177316  12252   8684 R 100.0   0.1  15:01.25 
systemd  
   4636 kush  39  19  633796 176152  16360 S  98.3   1.1  17:51.56 
tracker-miner-f  
820 message+  20   0   10740   6452   4212 S  39.8   0.0   6:19.06 
dbus-daemon  
316 root  19  -1  535916 322896 320824 S  15.3   2.0   3:16.41 
systemd-journal  
844 syslog20   0  221136   5840   3920 S  13.6   0.0   2:14.52 
rsyslogd 
858 root  20   0   83708  74124   7568 S  12.7   0.5   2:06.98 
systemd-logind   
  5 root  20   0   0  0  0 I   3.4   0.0   0:05.01 
kworker/0:0-events   
  35566 kush  20   0 3850088 588344 262192 S   2.5   3.6   0:30.48 
MainThread   
   5626 kush  20   0 5004788 260876  93400 S   1.7   1.6   3:05.19 
gnome-shell  
   7033 kush  20   0  869792  66440  44272 S   1.7   0.4   0:06.05 
gnome-terminal-  
  36790 kush  20   0 2525432 156636  98568 S   1.7   1.0   0:04.99 
Web Content  
957 root  20   0 1556196  45044  24284 S   0.8   0.3   0:02.48 
containerd   
   1038 root  20   0   10460   4412   3300 S   0.8   0.0   0:00.16 
fancontrol   



  
sudo tail -n 100 /var/log/syslog
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse 

[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Guilherme G. Piccoli
Thanks a bunch mfo!!

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags added: sts-sponsor-mfo

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1862846] Re: Crash and failure installing focal

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

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

Title:
  Crash and failure installing focal

Status in subiquity:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  Fix Released
Status in curtin source package in Eoan:
  Invalid
Status in util-linux source package in Eoan:
  Fix Released
Status in curtin source package in Focal:
  Fix Released
Status in util-linux source package in Focal:
  Fix Released
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [Impact]

   * lsblk no longer prints a partition's parent
     kernel device name (the wholedisk).
     (i.e., 'lsblk -no PKNAME /dev/partition')

   * Another impact is the 'removable media' check
     always return zero for partitions.
     (i.e., 'lsblk -no RM /dev/partition')

   * The regression was introduced on v2.34, only
     Eoan (v2.34) and later are affected.
     Disco (v2.33) and earlier are not affected.

   * The regression is fixed in v2.35, in commit
     e3bb9bfb76c1 ("lsblk: force to print PKNAME
     for partition"); fixes RM for partition too.

  [Test Case]

   * $ lsblk -no PKNAME /dev/vda1 # partition

   * Expected output: vda # wholedisk

   * Current output: (nothing)

   * $ lsblk -no RM /dev/sdb1 # partition in removable disk

   * Expected output: 1 # removable media

   * Current output: 0 # not removable media

  [Regression Potential]

   * Columns that depend on a partition device's
     parent device (i.e., seen as 'wholedisk')
     could in theory show incorrect values if
     another bug is present in v2.34 for that.

   * Other usages of 'parent' pointer in the
     function have been examined and reported
     (e.g. issue w/ removable media column),
     and others found to not have issues
     (e.g. --merge option, to group multiple
     parents of a device, as in RAID.)

  [Other Info]

   * The impacts to the curtin source package
     have been addressed in other way, it no
     longer requires util-linux, comment #14.

   * util-linux github issue:
     https://github.com/karelzak/util-linux/issues/813

  [Original Bug Description]

  During an install of the daily live image for 20.04 Ubuntu Server, the
  installer first crashed and restarted itself, then failed to install
  the system.

  Attached are the logs left on the install USB key.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1865504] Re: hwclock reports incorrect status in audit message

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

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

Title:
  hwclock reports incorrect status in audit message

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Bionic:
  Fix Released
Status in util-linux source package in Eoan:
  Fix Released
Status in util-linux package in Debian:
  Confirmed

Bug description:
  [Impact]

  hwclock reports incorrect status in audit message:
  - hwclock calls audit_log_user_message(3) to create an audit entry.
  - audit_log_user_message(3) result 1 is "success" and 0 is "failed".
  - hwclock use standard EXIT_{SUCCESS,FAILURE} macros with reverse status.
  - Thus reports its status incorrectly in audit message.

  It is a requirement for Common Criteria Certification that hwclock
  reports correct status in audit message.

  This has been fixed upstream in https://github.com/karelzak/util-
  linux/commit/189edf1fe501ea39b35911337eab1740888fae7a

  [Test Steps]

  Steps to test:
  1. Install auditd
  2. Run following testcase,

  # hwclock
  2020-03-02 15:03:03.280351+

  # hwclock --set --date "1/1/2000 00:00:00"
  # echo $?
  0
  # hwclock
  2000-01-01 00:00:05.413924+

  # hwclock --utc --systohc
  # echo $?
  0
  # hwclock
  2020-03-02 15:07:00.264331+

  Following audit messages from /var/log/audit/audit.log,

  Note that last field in each audit record produced when hardware clock
  was modified has, "res=failed". Although, testcase shows no* failure
  occurred.

  type=USYS_CONFIG msg=audit(1583161562.884:105): pid=2084 uid=0
  auid=1000 ses=1 msg='op=change-system-time exe="/sbin/hwclock"
  hostname=bionic-fips addr=? terminal=pts/0 res=failed'

  type=USYS_CONFIG msg=audit(1583161614.497:106): pid=2103 uid=0
  auid=1000 ses=1 msg='op=change-system-time exe="/sbin/hwclock"
  hostname=bionic-fips addr=? terminal=pts/0 res=failed'

  [Regression Potential]

  Changes limited to the result value passed to audit_log_user_message(3),
  so the audit messages will change the 'res=' field (to correct result.)

  There should not be any regression to fix the status given to auditd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1865504/+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 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

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

Title:
  libblkid: no bcache UUID due to ambivalent detection of bcache and
  xfs_external_log for regular xfs in bcache backing device

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  Fix Released
Status in util-linux source package in Bionic:
  Fix Released
Status in util-linux source package in Disco:
  Won't Fix
Status in util-linux source package in Eoan:
  Fix Released
Status in util-linux source package in Focal:
  Fix Released
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [Impact]

   * Users with an XFS filesystem on top of bcache
     (this is seen on some ceph, cloud deployments)
     might fail to reference the bcache device by
     UUID or other udev properties.

   * The journal of the regular XFS filesystem in
     the bcache device is incorrectly detected as
     an XFS external log; so two superblocks are
     detected (bcache and xfs_external_log).

   * Thus blkid fails with ambivalent superblocks
     detected then doesn't provide the usual udev
     properties (UUID, etc.)

   * The fix improves the probe function for XFS
     external log so it detects it's regular XFS
     and bails out.

  [Test Case]

   * See test steps detailed in comment #7 and later.
     - Create an XFS filesystem with the journal/log
   in the beginning of the bcache device (< 256K).
     - Stop the bcache device.
     - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'.

     $ sudo make-bcache -B $BACKING_DEV
     $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV
     $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop
     $ sudo blkid -o udev -p $BACKING_DEV

  [Regression Potential]

   * The patch only changes the detection function
     for XFS external log to be more general about
     the sector where the magic of regular XFS may
     be found (which is shifted inside the bcache.)

   * It still checks at sector zero (the only one
     checked previously), so this behavior didn't
     change.

   * Possible regressions are actual XFS external
     log devices that are not anymore detected as
     such. (Although that would probably indicate
     a different bug in libblkid.)

  [Other Info]
   * upstream commit:
     
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+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 1870316] Re: 'sudo hwclock -s' fails with 'settimeofday() failed: Invalid argument'

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

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

Title:
  'sudo hwclock -s' fails with 'settimeofday() failed: Invalid argument'

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux package in Debian:
  Fix Released

Bug description:
  In Focal VM.
  util-linux: 2.34-0.1ubuntu8

  $ sudo hwclock -s
  [sudo] password for focal: 
  hwclock: settimeofday() failed: Invalid argument

  Result should be syncing the time to the RTC, which until recently
  (possibly before glibc update) worked.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: util-linux 2.34-0.1ubuntu8
  ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
  Uname: Linux 5.4.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu22
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Apr  2 11:20:45 2020
  InstallationDate: Installed on 2019-12-24 (99 days ago)
  InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191224)
  SourcePackage: util-linux
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1870316/+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 1886300] Re: rename.ul refuses to rename links that don't resolve (regression)

2020-09-22 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

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

Title:
  rename.ul refuses to rename links that don't resolve (regression)

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Focal:
  Fix Released
Status in util-linux source package in Groovy:
  Fix Released
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [Impact]

  rename.ul refuses to rename links that don't resolve.

  bionic rename.ul renames links whether or not they resolve (util-linux
  2.31.1-0.4ubuntu3.6).

  focal rename.ul refuses to rename links that don't resolve
  (regression) (util-linux 2.34-0.1ubuntu9).

  Eoan is EOL, so removed.

  
  [Test case]

  Commit has good test case. I paste it here

  Before:

$ touch file-found
$ ln -s file-found symlink-1
$ ./rename sym symbolic- symlink-1  # XPASS.
$ echo $?
0

$ ln -s file-not-found symlink-2
$ ./rename sym symbolic- symlink-2  # FAIL! REGRESSION.
rename: symlink-2: not accessible: No such file or directory
$ echo $?
1

$ ./rename sym symbolic- symlink-3  # XFAIL.
rename: symlink-3: not accessible: No such file or directory
$ echo $?
1

$ touch file-found
$ ./rename found existing file-found# XPASS.
$ echo $?
0

$ ./rename found existing file-not-found # XFAIL.
rename: file-not-found: not accessible: No such file or directory
$ echo $?
1

  After:

$ touch file-found
$ ln -s file-found symlink-1
$ ./rename sym symbolic- symlink-1  # XPASS.
$ echo $?
0

$ ln -s file-not-found symlink-2
$ ./rename sym symbolic- symlink-2  # PASS! REGRESSION FIXED.
$ echo $?
0

$ ./rename sym symbolic- symlink-3  # XFAIL.
rename: symlink-3: not accessible: No such file or directory
$ echo $?
1

$ touch file-found
$ ./rename found existing file-found# XPASS.
$ echo $?
0

$ ./rename found existing file-not-found # XFAIL.
rename: file-not-found: not accessible: No such file or directory
$ echo $?
1

  
  [Regression Potential]
  This commit changes code that checking accessibility to file or sym link. 
  If this fails, rename command will not work properly.it could be crashed or 
causes failure of rename. 

  
  [Original Description]

  rename.ul refuses to rename links that don't resolve.

  bionic rename.ul renames links whether or not they resolve (util-linux
  2.31.1-0.4ubuntu3.6).

  focal rename.ul refuses to rename links that don't resolve
  (regression) (util-linux 2.34-0.1ubuntu9).

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: util-linux 2.34-0.1ubuntu9
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sat Jul  4 20:38:06 2020
  InstallationDate: Installed on 2020-04-05 (90 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200331)
  ProcEnviron:
   LC_TIME=en_DK.utf8
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: util-linux
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1886300/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Ubuntu Foundations Team Bug Bot
** Tags added: patch

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1888352] Re: use builtin dump_acpi_tables.py in hookutils

2020-09-22 Thread Launchpad Bug Tracker
This bug was fixed in the package apport - 2.20.11-0ubuntu27.9

---
apport (2.20.11-0ubuntu27.9) focal; urgency=medium

  [ YC Cheng ]
  * apport/apport/hookutils.py: add acpidump using built-in
dump_acpi_tables.py. (LP: #1888352)
  * bin/oem-getlogs: add "-E" in the usage, since we'd like to talk to
pulseaudio session and that need environment infomation. Also remove
acpidump since we will use the one from hook.

 -- Brian Murray   Wed, 02 Sep 2020 09:48:39 -0700

** Changed in: apport (Ubuntu Focal)
   Status: Fix Committed => Fix Released

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

Title:
  use builtin dump_acpi_tables.py in hookutils

Status in Apport:
  New
Status in OEM Priority Project:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  Fix Released
Status in apport source package in Groovy:
  Fix Released

Bug description:
  1. add apcidump to hookutils.py:attach_hardware and use the builtin 
dump_acpi_tables.py.
  2. remove explicit acpidump from oem-getlogs to use the builtin one.
  3. refine usage string in oem-getlogs.

  To SRU to focal:

  [Impact]

   * for OEM project, lts is been used. And collect log is important.
 With built-in tool to get acpidump, we don't need to install
 extra tool in the end-customer's machine. That make it much
 easier for the oem process.

   * By call built-in utility, we no lounger need to install extra
 tools to collect data that's both complete and convenient for
 HWE people to work on.

  [Test Case]

   * before this applied, run oem-getlog without install acpidump. 
 we can't get the dump data. After this applied, we can just dump
 the data HWE need.

   * test step: install the new package, run

 sudo -E oem-getlogs [-c case_id] to get the

 use apport-unpack to unpack the apport file.

 check the acpidump file. HWE people know much better on check
 the acpidump file. Give the dump_acpi_tables.py just updated and SRUed
 by HWE/ACPI/UEFI expert, it's pretty safe to do so.

  [Regression Potential]

   * Given the modification change the way to collect log, even it
 failed, it won't break apport itself. Just the collected log
 might contain data not so valid.

   * Given acpidump mostly used by HWE/ACIP/UEFI expert, and they
 just reviewed and updated the dump_acpi_tables.py script, I
 believe it will have good quality.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1888352/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Eric Desrochers
[sts-sponsors]

Sponsored and uploaded into groovy. 
Let's now wait until the package lands in groovy-releases before proceeding 
with the SRU.

Thanks mfo and gpiccoli for your contributions.

- Eric

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1888352] Update Released

2020-09-22 Thread Brian Murray
The verification of the Stable Release Update for apport 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 apport in Ubuntu.
https://bugs.launchpad.net/bugs/1888352

Title:
  use builtin dump_acpi_tables.py in hookutils

Status in Apport:
  New
Status in OEM Priority Project:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  Fix Released
Status in apport source package in Groovy:
  Fix Released

Bug description:
  1. add apcidump to hookutils.py:attach_hardware and use the builtin 
dump_acpi_tables.py.
  2. remove explicit acpidump from oem-getlogs to use the builtin one.
  3. refine usage string in oem-getlogs.

  To SRU to focal:

  [Impact]

   * for OEM project, lts is been used. And collect log is important.
 With built-in tool to get acpidump, we don't need to install
 extra tool in the end-customer's machine. That make it much
 easier for the oem process.

   * By call built-in utility, we no lounger need to install extra
 tools to collect data that's both complete and convenient for
 HWE people to work on.

  [Test Case]

   * before this applied, run oem-getlog without install acpidump. 
 we can't get the dump data. After this applied, we can just dump
 the data HWE need.

   * test step: install the new package, run

 sudo -E oem-getlogs [-c case_id] to get the

 use apport-unpack to unpack the apport file.

 check the acpidump file. HWE people know much better on check
 the acpidump file. Give the dump_acpi_tables.py just updated and SRUed
 by HWE/ACPI/UEFI expert, it's pretty safe to do so.

  [Regression Potential]

   * Given the modification change the way to collect log, even it
 failed, it won't break apport itself. Just the collected log
 might contain data not so valid.

   * Given acpidump mostly used by HWE/ACIP/UEFI expert, and they
 just reviewed and updated the dump_acpi_tables.py script, I
 believe it will have good quality.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1888352/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Mauricio Faria de Oliveira
** Patch added: "groovy_cryptsetup_lp1879980_V3.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+attachment/5413208/+files/groovy_cryptsetup_lp1879980_V3.debdiff

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Mauricio Faria de Oliveira
Hi Eric,

I just updated the changelog with a more detailed description per file.
If it looks good to you for Groovy I'll update the stable releases too.

Thanks!
Mauricio

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
** Changed in: apparmor (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1761096] Update Released

2020-09-22 Thread Brian Murray
The verification of the Stable Release Update for squid3 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 dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1761096

Title:
  dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in squid package in Ubuntu:
  Fix Released
Status in squid3 package in Ubuntu:
  Invalid
Status in dnsmasq source package in Xenial:
  Invalid
Status in squid source package in Xenial:
  Invalid
Status in squid3 source package in Xenial:
  Fix Released
Status in dnsmasq source package in Bionic:
  Invalid
Status in squid source package in Bionic:
  Invalid
Status in squid3 source package in Bionic:
  Incomplete

Bug description:
  [Impact]

  When using dnsmasq along with squid on Ubuntu Xenial, the user will
  experience a deadlock while performing on every second execution of
  the "systemctl start dnsmasq.service" command.  The deadlock will be
  caused by an attempt to invoke, by nss-lookup.target, a "systemctl
  reload squid.service", which will itself try to start the nss-
  lookup.target, which will be waiting on squid, therefore eventually
  leading to a timeout.

  The underlying cause of this deadlock is related to how systemd used
  to handle dependencies between multiple jobs being started in the same
  transaction.

  [Test Case]

  One can reproduce the issue on a Xenial container:

  $ lxc launch ubuntu-daily:xenial squid-bug1761096
  $ lxc shell squid-bug1761096
  # apt update
  # apt install squid dnsmasq -y

  It is quite possible that during "apt install" the bug will manifest,
  and dnsmasq will fail to start due to a timeout.  The user might see a
  message like:

  Job for dnsmasq.service failed because a timeout was exceeded. See
  "systemctl status dnsmasq.service" and "journalctl -xe" for details.

  If the bug doesn't manifest itself during installation, the following
  commands in sequence should trigger it:

  # systemctl restart dnsmasq.service
  # systemctl restart dnsmasq.service

  [Regression Potential]

  This change only touches the mechanism by which squid has its
  configuration reloaded in case of a DNS resolver change.  Because
  "systemctl reload --no-block" returns practically immediately, if
  squid's configuration file is invalid the user won't see any
  notifications.  However, this behaviour is already present currently,
  because "systemctl reload squid" invokes "/etc/init.d/squid reload";
  the user has to check "journalctl -u squid.service" if she wants to
  verify whether there were any failures during the reload.

  Other than that, and because systemctl will offload the service to the
  SysV script as usual (in the case of squid), I don't foresee any
  potential regressions.

  [Original Description]

  Setup to reproduce:

  Ubuntu Xenial amd64 net install iso from
  http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-
  amd64/current/images/netboot/mini.iso

  Install system with mostly defaults + LVM + OpenSSH server

  Note that this bug applies to both DHCP and static IP+DNS network
  configurations

  Once server rebooted and is available, log in and install dnsmasq + squid:
  apt-get update && apt-get install squid dnsmasq

  output of this can be found at https://pastebin.com/9Atuipju
  journalctl -xe output at https://pastebin.com/uLhfM4jN

  Furthermore at this point I can run alternating errors

  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:18:07 CEST 2018
  Wed Apr  4 09:18:07 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq stop ; date
  Wed Apr  4 09:18:39 CEST 2018
  Wed Apr  4 09:18:39 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:19:10 CEST 2018
  Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl 
status dnsmasq.service" and "journalctl -xe" for details.
  Wed Apr  4 09:20:40 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:42:57 CEST 2018
  Wed Apr  4 09:42:57 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq stop ; date
  Wed Apr  4 09:43:14 CEST 2018
  Wed Apr  4 09:43:14 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:43:26 CEST 2018
  Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl 
status dnsmasq.service" and "journalctl -xe" for details.
  Wed Apr  4 09:44:56 CEST 2018

  and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s
  timeout

  

[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

2020-09-22 Thread Launchpad Bug Tracker
This bug was fixed in the package squid3 - 3.5.12-1ubuntu7.14

---
squid3 (3.5.12-1ubuntu7.14) xenial; urgency=medium

  * d/squid.resolvconf: Invoke "systemctl reload --no-block" if we are
using systemd.  This prevents squid from blocking if the reload
action is being issued indirectly because of another
service (e.g., because dnsmasq has been restarted), which may
cause a deadlock and prevent the whole transaction to
complete. (LP: #1761096)

 -- Sergio Durigan Junior   Fri, 04 Sep
2020 08:31:36 -0400

** Changed in: squid3 (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

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

Title:
  dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in squid package in Ubuntu:
  Fix Released
Status in squid3 package in Ubuntu:
  Invalid
Status in dnsmasq source package in Xenial:
  Invalid
Status in squid source package in Xenial:
  Invalid
Status in squid3 source package in Xenial:
  Fix Released
Status in dnsmasq source package in Bionic:
  Invalid
Status in squid source package in Bionic:
  Invalid
Status in squid3 source package in Bionic:
  Incomplete

Bug description:
  [Impact]

  When using dnsmasq along with squid on Ubuntu Xenial, the user will
  experience a deadlock while performing on every second execution of
  the "systemctl start dnsmasq.service" command.  The deadlock will be
  caused by an attempt to invoke, by nss-lookup.target, a "systemctl
  reload squid.service", which will itself try to start the nss-
  lookup.target, which will be waiting on squid, therefore eventually
  leading to a timeout.

  The underlying cause of this deadlock is related to how systemd used
  to handle dependencies between multiple jobs being started in the same
  transaction.

  [Test Case]

  One can reproduce the issue on a Xenial container:

  $ lxc launch ubuntu-daily:xenial squid-bug1761096
  $ lxc shell squid-bug1761096
  # apt update
  # apt install squid dnsmasq -y

  It is quite possible that during "apt install" the bug will manifest,
  and dnsmasq will fail to start due to a timeout.  The user might see a
  message like:

  Job for dnsmasq.service failed because a timeout was exceeded. See
  "systemctl status dnsmasq.service" and "journalctl -xe" for details.

  If the bug doesn't manifest itself during installation, the following
  commands in sequence should trigger it:

  # systemctl restart dnsmasq.service
  # systemctl restart dnsmasq.service

  [Regression Potential]

  This change only touches the mechanism by which squid has its
  configuration reloaded in case of a DNS resolver change.  Because
  "systemctl reload --no-block" returns practically immediately, if
  squid's configuration file is invalid the user won't see any
  notifications.  However, this behaviour is already present currently,
  because "systemctl reload squid" invokes "/etc/init.d/squid reload";
  the user has to check "journalctl -u squid.service" if she wants to
  verify whether there were any failures during the reload.

  Other than that, and because systemctl will offload the service to the
  SysV script as usual (in the case of squid), I don't foresee any
  potential regressions.

  [Original Description]

  Setup to reproduce:

  Ubuntu Xenial amd64 net install iso from
  http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-
  amd64/current/images/netboot/mini.iso

  Install system with mostly defaults + LVM + OpenSSH server

  Note that this bug applies to both DHCP and static IP+DNS network
  configurations

  Once server rebooted and is available, log in and install dnsmasq + squid:
  apt-get update && apt-get install squid dnsmasq

  output of this can be found at https://pastebin.com/9Atuipju
  journalctl -xe output at https://pastebin.com/uLhfM4jN

  Furthermore at this point I can run alternating errors

  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:18:07 CEST 2018
  Wed Apr  4 09:18:07 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq stop ; date
  Wed Apr  4 09:18:39 CEST 2018
  Wed Apr  4 09:18:39 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:19:10 CEST 2018
  Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl 
status dnsmasq.service" and "journalctl -xe" for details.
  Wed Apr  4 09:20:40 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:42:57 CEST 2018
  Wed Apr  4 09:42:57 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq stop ; date
  Wed Apr  4 09:43:14 CEST 2018
  Wed Apr  4 09:43:14 CEST 2018
  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:43:26 CEST 2018
  Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl 
status 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-22 Thread Jamie Strandboge
FYI, there was a components mismatch where apparmor-notify pulled
python3-notify2 (and its Depends) into main. For now, I've demoted
apparmor-notify to universe and adjusted the seed (in practical terms,
the security team will fix bugs in apparmor-notify regardless of where
it lives). We might revisit promoting apparmor-notify at a future date.

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 

[Touch-packages] [Bug 1896632] [NEW] package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück

2020-09-22 Thread Justin Pietsch
Public bug reported:

I ve no idea what happend or why.

The system reports me a bug, I thought I would send the information.

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: lvm2 2.03.07-1ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.8
AptOrdering: NULL: ConfigurePending
Architecture: amd64
CasperMD5CheckResult: skip
Date: Mon Sep 21 22:17:26 2020
DpkgHistoryLog:
 Start-Date: 2020-09-21  22:17:25
 Commandline: apt-get autoremove
 Requested-By: pietsch (1000)
ErrorMessage: »installiertes lvm2-Skript des Paketes 
post-installation«-Unterprozess gab den Fehlerwert 1 zurück
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 2.7.17-4
RelatedPackageVersions:
 dpkg 1.19.7ubuntu3
 apt  2.0.2ubuntu0.1
SourcePackage: lvm2
Title: package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes 
lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 
zurück
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-package focal

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

Title:
  package lvm2 2.03.07-1ubuntu1 failed to install/upgrade:
  »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess
  gab den Fehlerwert 1 zurück

Status in lvm2 package in Ubuntu:
  New

Bug description:
  I ve no idea what happend or why.

  The system reports me a bug, I thought I would send the information.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: lvm2 2.03.07-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
  Uname: Linux 5.4.0-48-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.8
  AptOrdering: NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Mon Sep 21 22:17:26 2020
  DpkgHistoryLog:
   Start-Date: 2020-09-21  22:17:25
   Commandline: apt-get autoremove
   Requested-By: pietsch (1000)
  ErrorMessage: »installiertes lvm2-Skript des Paketes 
post-installation«-Unterprozess gab den Fehlerwert 1 zurück
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: lvm2
  Title: package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: 
»installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den 
Fehlerwert 1 zurück
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1896632/+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 1896626] Re: apparmor service is dead

2020-09-22 Thread Sirasit Sawetprom
I just follow this thread and fix the issue.

https://forums.whonix.org/t/live-mode-breaks-apparmor/7559/7

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

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

Title:
  apparmor service is dead

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  // System
  Ubuntu 20.04 LTS
  64-bit

  user@ubuntu:~/Desktop$ sudo apparmor_parser --version
  AppArmor parser version 2.13.3
  Copyright (C) 1999-2008 Novell Inc.
  Copyright 2009-2018 Canonical Ltd.

  
  user@ubuntu:~/Desktop$ systemctl status apparmor.service
  ● apparmor.service - Load AppArmor profiles
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
pres>
   Active: inactive (dead)
Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago
   └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met
 Docs: man:apparmor(7)
   https://gitlab.com/apparmor/apparmor/wikis/home/

  user@ubuntu:~/Desktop$ sudo aa-status
  apparmor module is loaded.
  15 profiles are loaded.
  12 profiles are in enforce mode.
 /snap/core/9993/usr/lib/snapd/snap-confine
 /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /snap/snapd/7264/usr/lib/snapd/snap-confine
 /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 snap-update-ns.blender
 snap-update-ns.core
 snap-update-ns.gitkraken
 snap-update-ns.snap-store
 snap.core.hook.configure
 snap.snap-store.snap-store
 snap.snap-store.ubuntu-software
 snap.snap-store.ubuntu-software-local-file
  3 profiles are in complain mode.
 snap.blender.blender
 snap.gitkraken.gitkraken
 snap.gitkraken.url-handler
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu5
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckMismatches: ./casper/initrd
  CasperMD5CheckResult: skip
  CasperVersion: 1.445
  Date: Tue Sep 22 21:21:08 2020
  LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent 
file=/cdrom/preseed/hostname.seed quiet splash ---
  SourcePackage: apparmor
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1896626/+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 1896137] Re: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7"

2020-09-22 Thread Gerald Gilbert-Thorple
That's right, I masked them by hand following some advice on the internet for 
how to make systemd stop suspending, since it was not responding to settings in 
login.conf even after restating logind
service.

Regardless of my motivation, it seems buggy that changing these settings
should lead to such undesirable behavior.

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

Title:
  syslog flooded with "Lockdown: systemd-logind: hibernation is
  restricted; see man kernel_lockdown.7"

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  When I close the lid on my laptop, syslog goes crazy with the message

  systemd-logind: hibernation is restricted; see man kernel_lockdown.7

  repeated ad infinitum, using up all the CPU and GBs of disk space.  I
  am not even trying to hibernate; everything in /etc/systemd/login.conf
  is commented out.  So nothing much should happen when I close the lid,
  but systemd is trying to kill me with these messages.  I am running
  Ubuntu 20.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896137/+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 1896395] Re: lid closure behavior unpredictable

2020-09-22 Thread Gerald Gilbert-Thorple
sorry, you can withdraw this bug as I discovered it is a kernel bug, not 
systemd.
(I wanted to withdraw it earlier but did not know how to get back to this 
report.)
thanks

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

Title:
  lid closure behavior unpredictable

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  in 20.04.01 LTS (release 20.04), suspend on lid closure works for a
  while, then one day stops working, with no error message in syslog.
  The event is not even registered.  The problem seems to start when the
  system has been inactive for long enough so that the screen is
  blanked.

   systemd:
Installed: 245.4-4ubuntu3.2
Candidate: 245.4-4ubuntu3.2
Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages

  seems similar to bug #1840784, even though no error message is
  generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896395/+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 1894622] Re: Missing manpage for systemd-resolve

2020-09-22 Thread Dan Streetman
systemd-resolve has been deprecated in favor of the new name
'resolvectl', but the resolvectl binary does provide backwards
compatibility with systemd-resolve (which is symlinked to resolvectl),
so there should be *some* kind of manpage for it, as long as that
backwards compatibility symlink is provided.

It looks like upstream, the systemd-resolve manpage was completely
replaced by the resolvectl manpage in commit
b69f810c8a2ece4e44c1b1898e237bb671b36a21. This should probably be
discussed upstream to restore some kind of manpage for systemd-resolve
compatibility mode, instead of just in Ubuntu.

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

Title:
  Missing manpage for systemd-resolve

Status in systemd package in Ubuntu:
  New

Bug description:
  On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz
  This means that man systemd-resolve fails.

  http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd-
  resolve.1.html exists and has a link on top to 20.04LTS: it points to
  http://manpages.ubuntu.com/manpages/focal/en/man1/systemd-
  resolve.1.html , that however 404's, and one ends up being redirected
  to Bionic's.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1896627] [NEW] Windows flicker when being reized with the mouse

2020-09-22 Thread Sam Lane
Public bug reported:

When resizing a window with the mouse by dragging the edge or corner,
the window begins to flicker.  It only flickers when actively being
resized, and when I stop dragging, it looks normal.  This behavior is
does not occur on same pc in 20.04.

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: Budgie:GNOME
CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
Date: Tue Sep 22 10:21:51 2020
DistUpgraded: Fresh install
DistroCodename: groovy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 
00 [VGA controller])
   Subsystem: Lenovo Skylake GT2 [HD Graphics 520] [17aa:2231]
InstallationDate: Installed on 2020-09-22 (0 days ago)
InstallationMedia: Ubuntu-Budgie 20.10 "Groovy Gorilla" - Alpha amd64 (20200921)
MachineType: LENOVO 20FJS0AJ00
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic 
root=UUID=72bd1806-98fb-4fa6-be5b-638dec36ebc9 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/07/2016
dmi.bios.release: 1.13
dmi.bios.vendor: LENOVO
dmi.bios.version: N1KET26W (1.13 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FJS0AJ00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.5
dmi.modalias: 
dmi:bvnLENOVO:bvrN1KET26W(1.13):bd10/07/2016:br1.13:efr1.5:svnLENOVO:pn20FJS0AJ00:pvrThinkPadT560:rvnLENOVO:rn20FJS0AJ00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T560
dmi.product.name: 20FJS0AJ00
dmi.product.sku: LENOVO_MT_20FJ_BU_Think_FM_ThinkPad T560
dmi.product.version: ThinkPad T560
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.102-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.1.7-1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200714-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 groovy reproducible 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/1896627

Title:
  Windows flicker when being reized with the mouse

Status in xorg package in Ubuntu:
  New

Bug description:
  When resizing a window with the mouse by dragging the edge or corner,
  the window begins to flicker.  It only flickers when actively being
  resized, and when I stop dragging, it looks normal.  This behavior is
  does not occur on same pc in 20.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: Budgie:GNOME
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Tue Sep 22 10:21:51 2020
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo Skylake GT2 [HD Graphics 520] [17aa:2231]
  InstallationDate: Installed on 2020-09-22 (0 days ago)
  InstallationMedia: Ubuntu-Budgie 20.10 "Groovy Gorilla" - Alpha amd64 
(20200921)
  MachineType: LENOVO 20FJS0AJ00
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic 
root=UUID=72bd1806-98fb-4fa6-be5b-638dec36ebc9 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/07/2016
  dmi.bios.release: 1.13
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N1KET26W (1.13 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FJS0AJ00
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information

[Touch-packages] [Bug 1896626] [NEW] apparmor service is dead

2020-09-22 Thread Sirasit Sawetprom
Public bug reported:

// System
Ubuntu 20.04 LTS
64-bit

user@ubuntu:~/Desktop$ sudo apparmor_parser --version
AppArmor parser version 2.13.3
Copyright (C) 1999-2008 Novell Inc.
Copyright 2009-2018 Canonical Ltd.


user@ubuntu:~/Desktop$ systemctl status apparmor.service
● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor pres>
 Active: inactive (dead)
  Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago
 └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/

user@ubuntu:~/Desktop$ sudo aa-status
apparmor module is loaded.
15 profiles are loaded.
12 profiles are in enforce mode.
   /snap/core/9993/usr/lib/snapd/snap-confine
   /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /snap/snapd/7264/usr/lib/snapd/snap-confine
   /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.blender
   snap-update-ns.core
   snap-update-ns.gitkraken
   snap-update-ns.snap-store
   snap.core.hook.configure
   snap.snap-store.snap-store
   snap.snap-store.ubuntu-software
   snap.snap-store.ubuntu-software-local-file
3 profiles are in complain mode.
   snap.blender.blender
   snap.gitkraken.gitkraken
   snap.gitkraken.url-handler
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: apparmor 2.13.3-7ubuntu5
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckMismatches: ./casper/initrd
CasperMD5CheckResult: skip
CasperVersion: 1.445
Date: Tue Sep 22 21:21:08 2020
LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent 
file=/cdrom/preseed/hostname.seed quiet splash ---
SourcePackage: apparmor
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug focal

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

Title:
  apparmor service is dead

Status in apparmor package in Ubuntu:
  New

Bug description:
  // System
  Ubuntu 20.04 LTS
  64-bit

  user@ubuntu:~/Desktop$ sudo apparmor_parser --version
  AppArmor parser version 2.13.3
  Copyright (C) 1999-2008 Novell Inc.
  Copyright 2009-2018 Canonical Ltd.

  
  user@ubuntu:~/Desktop$ systemctl status apparmor.service
  ● apparmor.service - Load AppArmor profiles
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
pres>
   Active: inactive (dead)
Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago
   └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met
 Docs: man:apparmor(7)
   https://gitlab.com/apparmor/apparmor/wikis/home/

  user@ubuntu:~/Desktop$ sudo aa-status
  apparmor module is loaded.
  15 profiles are loaded.
  12 profiles are in enforce mode.
 /snap/core/9993/usr/lib/snapd/snap-confine
 /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /snap/snapd/7264/usr/lib/snapd/snap-confine
 /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 snap-update-ns.blender
 snap-update-ns.core
 snap-update-ns.gitkraken
 snap-update-ns.snap-store
 snap.core.hook.configure
 snap.snap-store.snap-store
 snap.snap-store.ubuntu-software
 snap.snap-store.ubuntu-software-local-file
  3 profiles are in complain mode.
 snap.blender.blender
 snap.gitkraken.gitkraken
 snap.gitkraken.url-handler
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu5
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckMismatches: ./casper/initrd
  CasperMD5CheckResult: skip
  CasperVersion: 1.445
  Date: Tue Sep 22 21:21:08 2020
  LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent 

[Touch-packages] [Bug 1896137] Re: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7"

2020-09-22 Thread Dan Streetman
> by unmasking

those targets don't come masked by default, how did they get masked?

** Changed in: systemd (Ubuntu)
   Status: New => Incomplete

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

Title:
  syslog flooded with "Lockdown: systemd-logind: hibernation is
  restricted; see man kernel_lockdown.7"

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  When I close the lid on my laptop, syslog goes crazy with the message

  systemd-logind: hibernation is restricted; see man kernel_lockdown.7

  repeated ad infinitum, using up all the CPU and GBs of disk space.  I
  am not even trying to hibernate; everything in /etc/systemd/login.conf
  is commented out.  So nothing much should happen when I close the lid,
  but systemd is trying to kill me with these messages.  I am running
  Ubuntu 20.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896137/+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 1896395] Re: lid closure behavior unpredictable

2020-09-22 Thread Dan Streetman
You need to provide some kind of logs to review.

** Changed in: systemd (Ubuntu)
   Status: New => Incomplete

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

Title:
  lid closure behavior unpredictable

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  in 20.04.01 LTS (release 20.04), suspend on lid closure works for a
  while, then one day stops working, with no error message in syslog.
  The event is not even registered.  The problem seems to start when the
  system has been inactive for long enough so that the screen is
  blanked.

   systemd:
Installed: 245.4-4ubuntu3.2
Candidate: 245.4-4ubuntu3.2
Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages

  seems similar to bug #1840784, even though no error message is
  generated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896395/+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 1840784] Re: suspend.target: Job suspend.target/start failed with result 'dependency'.

2020-09-22 Thread Dan Streetman
Your ethernet driver or hw is preventing suspend:

[231201.406221] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x50 [e1000e] returns -2
[231201.406226] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[231201.406230] PM: Device :00:19.0 failed to suspend async: error -2
[231201.406291] PM: Some devices failed to suspend, or early wake event detected

This looks like maybe this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=198519

Which maybe is bug 1865570. In any case, this is not a systemd bug, it's
a kernel bug, so I'm changing the affected pacakge to the kernel.

** Bug watch added: Linux Kernel Bug Tracker #198519
   https://bugzilla.kernel.org/show_bug.cgi?id=198519

** Package changed: systemd (Ubuntu) => linux (Ubuntu)

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

Title:
  suspend.target: Job suspend.target/start failed with result
  'dependency'.

Status in linux package in Ubuntu:
  New

Bug description:
  System fails to suspend, screen goes dark then turns back on. The lid
  won't suspend the system either.

  Things I've tried:
  turning off baloo, disconnecting from network.

  
  From the logs:

  suspend.target: Job suspend.target/start failed with result
  'dependency'.

  I've observed this behavior a often enough during the past month that
  suspend is unpredictable. Luckily my computer has a suspend state
  indicator - some laptops don't.

  A google search shows this to be a very old bug, earliest mentions are
  from 2014.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: systemd 240-6ubuntu5.3
  ProcVersionSignature: Ubuntu 5.0.0-26.27-generic 5.0.21
  Uname: Linux 5.0.0-26-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Aug 20 17:34:30 2019
  InstallationDate: Installed on 2018-11-15 (278 days ago)
  InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.2)
  MachineType: LENOVO 20AQCTO1WW
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-26-generic 
root=/dev/mapper/kubuntu--vg-root ro psmouse.synaptics_intertouch=0 quiet 
splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: Upgraded to disco on 2019-04-27 (114 days ago)
  dmi.bios.date: 03/20/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GJET98WW (2.48 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20AQCTO1WW
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0E50510 PRO
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrGJET98WW(2.48):bd03/20/2018:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad T440s
  dmi.product.name: 20AQCTO1WW
  dmi.product.sku: LENOVO_MT_20AQ_BU_Think_FM_ThinkPad T440s
  dmi.product.version: ThinkPad T440s
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840784/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
Tested the change - works as expected, prepping an MP

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Launchpad Bug Tracker
** Merge proposal linked:
   
https://code.launchpad.net/~paelzer/ubuntu/+source/apparmor/+git/apparmor/+merge/391134

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
That patch by Christian Bolz is already applied (which seems reasonable after 
that much time),
but when merging 3.0 the old patch for bug 1824812 should have been dropped.

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Mauricio Faria de Oliveira
Hi Guilherme,

I can handle that while you're out.

cheers,
Mauricio

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
As refrence, it is a re-occurrence of
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812 , look
who filed that bug :-)

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
https://gitlab.com/apparmor/apparmor/-/commit/61c27d8808f0589beb6a319cc04073e8bb32d860

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
And we are back with Christian Bolz :-)

commit 61c27d8808f0589beb6a319cc04073e8bb32d860
Author: Christian Boltz 
Date:   Fri Jun 21 19:22:15 2019 +0200

Fix and simplify setting SFS_MOUNTPOINT

The question is why isn't this in the apparmor 3.0 package in groovy-
proposed ?

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Guilherme G. Piccoli
Hi Eric, all the changes are part of the same functionality - the local-bottom 
script for example is a clean-up for the files created in the local-top phase. 
I think it'd be unnecessary verbosity to explain file by file, and this bug is 
waiting for a long time to be fixed (especially due to the FTBFS we needed to 
investigate and fix), so unless you think it's strictly necessary, I'd rather 
move this one forward without changing the description.
Thanks,


Guilherme

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt 
Isn't that "Not starting AppArmor in container" message just in:

/lib/apparmor/apparmor.systemd
   -> /lib/apparmor/rc.apparmor.functions
  -> function is_container_with_internal_policy()

That looks unchanged (except a comment) but it behaves differently:


root@testguest-apparmor-good:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-good:~# is_container_with_internal_policy
root@testguest-apparmor-good:~# echo $?
0

root@testguest-apparmor-bad:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-bad:~# is_container_with_internal_policy
root@testguest-apparmor-bad:~# echo $?
1

Looking into what happens in detail ...


good:
+ SFS_MOUNTPOINT=/sys/kernel/security/apparmor
+ local ns_stacked_path=/sys/kernel/security/apparmor/.ns_stacked

bad:
+ SFS_MOUNTPOINT=/sys/kernel/security/
+ local ns_stacked_path=/sys/kernel/security//.ns_stacked

Once we know that we can see that it is missing in the bad case

good:
root@testguest-apparmor-good:~# grep MODULE 
/usr/lib/apparmor/rc.apparmor.functions
MODULE=apparmor
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
MODULE=apparmor
/sbin/modprobe -qr $MODULE

bad:
root@testguest-apparmor-bad:~# grep MODULE 
/usr/lib/apparmor/rc.apparmor.functions
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"

So whatever took away the modprobe from
/usr/lib/apparmor/rc.apparmor.functions also removed the variable, but
that has broken function is_container_with_internal_policy

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-09-22 Thread Eric Desrochers
@gpiccoli,

Can you break down everything this debdiff does per file being modified
in the d/changelog along with the summary you have already provided ?

It would ease for future reference and make the d/changelog more
accurate about the changes.


* d/cryptsetup-initramfs.install:
  - 
* d/functions cryptsetup-2.3.3/debian/functions:
  - 
* d/initramfs/scripts/local-block/cryptroot:
  - 
* d/initramfs/scripts/local-bottom/cryptroot:
  - 
* d/initramfs/scripts/local-top/cryptroot:
  - 


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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1838151] Re: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support.

2020-09-22 Thread Victor Bloetjes
Linux Mint 19.3 user and I can also confirm this bug.

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

Title:
  Poor quality audio with modern Bluetooth headsets in HSP/HFP.  Missing
  wide band speech support.

Status in PulseAudio:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in pulseaudio package in Ubuntu:
  In Progress
Status in Arch Linux:
  New

Bug description:
  Bluetooth HSP/HFP audio quality is poor on Ubuntu comparative to all
  other major platforms (Windows, MacOS, ChromeOS, Android, iOS).

  Modern Bluetooth headsets (such as the Bose QC series headphones, many
  others) are capable of using HFP 1.6 with mSBC 16kHz audio encoding.
  As it currently stands, Ubuntu defaults to only supporting HSP
  headsets using 8kHz CVSD, and is incapable of supporting HFP 1.6 at
  this time.

  The ChromiumOS team recently tackled this issue -
  https://bugs.chromium.org/p/chromium/issues/detail?id=843048

  Their efforts may assist in bringing this to Ubuntu, however it
  appears that there are quite a lot of differences considering they
  have developed their own audio server solution etc.

  The Bluetooth Telephony Working Group published the HFP 1.6 spec in
  May 2011 -
  https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193

  Patches have been proposed in the past for this issue to the kernel
  and PulseAudio:

  PulseAudio: https://patchwork.freedesktop.org/patch/245272/
  Kernel: https://www.spinics.net/lists/linux-bluetooth/msg76982.html

  It appears that the Chromium OS team applied the same kernel patch:
  
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/77dd0cb94c1713a8a12f6e392955dfa64c430e54

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: pulseaudio 1:12.2-2ubuntu3
  ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
  Uname: Linux 5.0.0-20-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  jnappi 2777 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jul 27 11:08:29 2019
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2017-11-04 (629 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: pulseaudio
  UpgradeStatus: Upgraded to disco on 2019-07-18 (9 days ago)
  dmi.bios.date: 06/07/2016
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R07ET67W (2.07 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FW000TUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40705 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrR07ET67W(2.07):bd06/07/2016:svnLENOVO:pn20FW000TUS:pvrThinkPadT460p:rvnLENOVO:rn20FW000TUS:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T460p
  dmi.product.name: 20FW000TUS
  dmi.product.sku: LENOVO_MT_20FW_BU_Think_FM_ThinkPad T460p
  dmi.product.version: ThinkPad T460p
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/pulseaudio/+bug/1838151/+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 1896614] Re: Race condition when starting dbus services

2020-09-22 Thread Victor Tapia
In the original report, the issue happened randomly on boot when a
service[1] was triggering a reload while systemd-logind was starting,
resulting in a list of queued jobs that were never executed.

The issue can happen too under high load conditions, as reported upstream:
https://github.com/systemd/systemd/issues/12956

To simplify the reproducer I went with systemd-logind+daemon-reload, but
it can be done with any other dbus service.


[1]

[Unit]
Description=Disable unattended upgrades
After=network-online.target local-fs.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c "/bin/chmod 644 /etc/cron.daily/apt-compat ; 
/bin/systemctl disable apt-daily-upgrade.timer apt-daily.timer ; /bin/systemctl 
stop apt-daily-upgrade.timer apt-daily.timer"

[Install]
WantedBy=multi-user.target

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

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

Title:
  Race condition when starting dbus services

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  In certain scenarios, such as high load environments or when
  "systemctl daemon-reload" runs at the same time a dbus service is
  starting (e.g. systemd-logind), systemd is not able to track properly
  when the service has started, keeping the job 'running' forever.

  The issue appears when systemd runs the "AddMatch" dbus method call to
  track the service's "NameOwnerChange" once it has already ran. A
  working instance would look like this:

  https://pastebin.ubuntu.com/p/868J6WBRQx/

  A failing instance would be:

  https://pastebin.ubuntu.com/p/HhJZ4p8dT5/

  I've been able to reproduce the issue on Bionic (237-3ubuntu10.42)
  running:

  sudo systemctl daemon-reload & sudo systemctl restart systemd-logind

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1888575] Re: Split motd-news config into a new package

2020-09-22 Thread Andreas Hasenack
I meant, see *also* https://bugs.launchpad.net/bugs/1895302, no idea yet
if it's related.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in 

[Touch-packages] [Bug 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal

2020-09-22 Thread Ubuntu Foundations Team Bug Bot
** Tags added: patch

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

Title:
  Packagekit lets user install untrusted local packages in Bionic and
  Focal

Status in packagekit package in Ubuntu:
  Triaged

Bug description:
  We have packagekit configured to allow users to install trusted
  packages from preconfigured repositories, but disallowed them to
  install any untrusted packages.

  The policykit configuration we use is following:

  [tld.univ.packagekit]
  Identity=unix-group:adm;
  
Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system;
  ResultAny=auth_self
  ResultActive=auth_self
  ResultInactive=auth_self

  [tld.univ.packagekit-deny]
  Identity=unix-user:*;
  Action=org.freedesktop.packagekit.package-install-untrusted;
  ResultAny=no

  We would expect this to prevent users from installing local packages
  downloaded from random repositories, however this does not seem to be
  the case.

  pkcon install-local random_package.deb will happily prompt for the
  user to authenticate and will install the package, while pkcon
  --allow-untrusted install-local random_package.deb will prompt for
  root password, which the user does not have.

  Our initial toughts was that the issue would be in packagekitd, but
  after further investigations it looks like the issue could be in aptcc
  backend.

  We are more than happy to provide you with further details, but the
  above should be enough to reproduce the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal

2020-09-22 Thread Julian Andres Klode
** Patch added: 
"0001-aptcc-Do-not-trust-local-debs-allows-root-privileges.patch"
   
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+attachment/5413161/+files/0001-aptcc-Do-not-trust-local-debs-allows-root-privileges.patch

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

Title:
  Packagekit lets user install untrusted local packages in Bionic and
  Focal

Status in packagekit package in Ubuntu:
  Triaged

Bug description:
  We have packagekit configured to allow users to install trusted
  packages from preconfigured repositories, but disallowed them to
  install any untrusted packages.

  The policykit configuration we use is following:

  [tld.univ.packagekit]
  Identity=unix-group:adm;
  
Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system;
  ResultAny=auth_self
  ResultActive=auth_self
  ResultInactive=auth_self

  [tld.univ.packagekit-deny]
  Identity=unix-user:*;
  Action=org.freedesktop.packagekit.package-install-untrusted;
  ResultAny=no

  We would expect this to prevent users from installing local packages
  downloaded from random repositories, however this does not seem to be
  the case.

  pkcon install-local random_package.deb will happily prompt for the
  user to authenticate and will install the package, while pkcon
  --allow-untrusted install-local random_package.deb will prompt for
  root password, which the user does not have.

  Our initial toughts was that the issue would be in packagekitd, but
  after further investigations it looks like the issue could be in aptcc
  backend.

  We are more than happy to provide you with further details, but the
  above should be enough to reproduce the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1896577] Re: FFE: new upstream release 20.2 and migrate to llvm 11

2020-09-22 Thread Timo Aaltonen
** Changed in: mesa (Ubuntu)
 Assignee: (unassigned) => Timo Aaltonen (tjaalton)

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

Title:
  FFE: new upstream release 20.2 and migrate to llvm 11

Status in mesa package in Ubuntu:
  New

Bug description:
  Mesa 20.2.0 has been delayed by upstream, but we still want it in
  20.10. It's currrently at rc4, final was supposed to be out a month
  ago. It's been in debian experimental since rc1.

  The packaging in debian also migrates to use llvm 11.

  packages for groovy are available on ppa:canonical-x/x-staging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896577/+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 1896614] Re: Race condition when starting dbus services

2020-09-22 Thread Dimitri John Ledkov
restarting systemd-logind is not safe, as existing sessions can be
logged out.

also performing daemon-reload, mid-boot, also is not safe.

Can you explain the usecase and why these actions are performed
together, racing each other?

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

Title:
  Race condition when starting dbus services

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  In certain scenarios, such as high load environments or when
  "systemctl daemon-reload" runs at the same time a dbus service is
  starting (e.g. systemd-logind), systemd is not able to track properly
  when the service has started, keeping the job 'running' forever.

  The issue appears when systemd runs the "AddMatch" dbus method call to
  track the service's "NameOwnerChange" once it has already ran. A
  working instance would look like this:

  https://pastebin.ubuntu.com/p/868J6WBRQx/

  A failing instance would be:

  https://pastebin.ubuntu.com/p/HhJZ4p8dT5/

  I've been able to reproduce the issue on Bionic (237-3ubuntu10.42)
  running:

  sudo systemctl daemon-reload & sudo systemctl restart systemd-logind

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1803203] Re: Support preferred_lft for IPv6 addresses

2020-09-22 Thread Launchpad Bug Tracker
This bug was fixed in the package netplan.io - 0.100-0ubuntu4

---
netplan.io (0.100-0ubuntu4) groovy; urgency=medium

  * debian/tests/cloud-init
- Improve reboot test to avoid failure on arm64

 -- Lukas Märdian   Mon, 21 Sep 2020
12:23:02 +0200

** Changed in: netplan.io (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  Support preferred_lft for IPv6 addresses

Status in netplan:
  New
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  There doesn't currently seem to be any way to set the preferred_lft of
  an IPv6 address.

  With the "ip" command it might be, for example:

  # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0

  In a systemd unit file it might be:

  [Match]
  Name=eth0

  [Network]
  Address=2001:db8::2/32
  Gateway=2001:db8::1/32
  PreferredLifetime=0

  but I can't find any way to express this with netplan.

  This is commonly used for per-service IP addresses that should never
  be used as source addresses for outgoing traffic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1803203/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread John Johansen
Still chasing this down

The apparmor.systemd file is unchanged from focal.

The change is in rc.apparmor.functions which is a dependency of
apparmor.systemd.

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896614] [NEW] Race condition when starting dbus services

2020-09-22 Thread Victor Tapia
Public bug reported:

In certain scenarios, such as high load environments or when "systemctl
daemon-reload" runs at the same time a dbus service is starting (e.g.
systemd-logind), systemd is not able to track properly when the service
has started, keeping the job 'running' forever.

The issue appears when systemd runs the "AddMatch" dbus method call to
track the service's "NameOwnerChange" once it has already ran. A working
instance would look like this:

https://pastebin.ubuntu.com/p/868J6WBRQx/

A failing instance would be:

https://pastebin.ubuntu.com/p/HhJZ4p8dT5/

I've been able to reproduce the issue on Bionic (237-3ubuntu10.42)
running:

sudo systemctl daemon-reload & sudo systemctl restart systemd-logind

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

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


** Tags: sts

** Tags added: sts

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

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

Title:
  Race condition when starting dbus services

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  In certain scenarios, such as high load environments or when
  "systemctl daemon-reload" runs at the same time a dbus service is
  starting (e.g. systemd-logind), systemd is not able to track properly
  when the service has started, keeping the job 'running' forever.

  The issue appears when systemd runs the "AddMatch" dbus method call to
  track the service's "NameOwnerChange" once it has already ran. A
  working instance would look like this:

  https://pastebin.ubuntu.com/p/868J6WBRQx/

  A failing instance would be:

  https://pastebin.ubuntu.com/p/HhJZ4p8dT5/

  I've been able to reproduce the issue on Bionic (237-3ubuntu10.42)
  running:

  sudo systemctl daemon-reload & sudo systemctl restart systemd-logind

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1890716] Re: xdg-mime query filetype index.html reports wrong type

2020-09-22 Thread Sebastien Bacher
in fact the script doesn't seem to used shared-mime-info

$ XDG_UTILS_DEBUG_LEVEL=1 xdg-mime query filetype index.html
Running mimetype --brief --dereference "/tmp/index.html"
text/html

could you try to use the command with the same environement variable and
share the output?

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

Title:
  xdg-mime query filetype index.html reports wrong type

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

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt 
Bad case:

$ ./repro.sh bad
+ '[' bad == bad ']'
+ echo 'Bad case: Using apparmor from proposed'
Bad case: Using apparmor from proposed
+ BADCASE=1
+ lxc stop --force testguest-apparmor-bad
+ lxc delete --force testguest-apparmor-bad
+ lxc launch ubuntu-daily:groovy/amd64 testguest-apparmor-bad --profile default 
--profile kvm
Creating testguest-apparmor-bad
Starting testguest-apparmor-bad
+ sleep 30s
+ lxc exec testguest-apparmor-bad runlevel
N 5
+ lxc exec testguest-apparmor-bad -- bash -c 'H=`cat /etc/hostname`; if [ -f 
/var/lib/cloud/instance/boot-finished ]; then echo "LXD container $H ready"; 
else echo "LXD container $H not ready yet"; exit 2; fi'
LXD container testguest-apparmor-bad ready
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash 
-c 'apt-get --allow-unauthenticated --assume-yes -o 
Dpkg::Options::='\''--force-confdef'\'' -o 
Dpkg::Options::='\''--force-confold'\'' install apparmor-utils'
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  libfreetype6
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  python3-apparmor python3-libapparmor
Suggested packages:
  vim-addon-manager
The following NEW packages will be installed:
  apparmor-utils python3-apparmor python3-libapparmor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 157 kB of archives.
After this operation, 966 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-libapparmor 
amd64 2.13.3-7ubuntu6 [26.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-apparmor amd64 
2.13.3-7ubuntu6 [78.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy/main amd64 apparmor-utils amd64 
2.13.3-7ubuntu6 [51.4 kB]
Fetched 157 kB in 0s (385 kB/s)   
Selecting previously unselected package python3-libapparmor.
(Reading database ... 31714 files and directories currently installed.)
Preparing to unpack .../python3-libapparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-libapparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package python3-apparmor.
Preparing to unpack .../python3-apparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-apparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package apparmor-utils.
Preparing to unpack .../apparmor-utils_2.13.3-7ubuntu6_amd64.deb ...
Unpacking apparmor-utils (2.13.3-7ubuntu6) ...
Setting up python3-libapparmor (2.13.3-7ubuntu6) ...
Setting up python3-apparmor (2.13.3-7ubuntu6) ...
Setting up apparmor-utils (2.13.3-7ubuntu6) ...
Processing triggers for man-db (2.9.3-2) ...
+ lxc exec testguest-apparmor-bad -- aa-status
apparmor module is loaded.
28 profiles are loaded.
28 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /{,usr/}sbin/dhclient
   lsb_release
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
   tcpdump
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
+ '[' 1 -eq 1 ']'
+ lxc exec testguest-apparmor-bad -- bash -c 'echo '\''deb 
http://archive.ubuntu.com/ubuntu/ groovy-proposed restricted main multiverse 
universe'\'' >> /etc/apt/sources.list'
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash 
-c 'apt-get --allow-unauthenticated --assume-yes -o 
Dpkg::Options::='\''--force-confdef'\'' -o 
Dpkg::Options::='\''--force-confold'\'' update'
Hit:1 http://security.ubuntu.com/ubuntu groovy-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu groovy InRelease [267 kB]
Get:3 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 c-n-f 
Metadata [116 B]
Get:4 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 c-n-f 
Metadata [116 B]
Hit:5 http://archive.ubuntu.com/ubuntu groovy-updates InRelease
Get:6 http://archive.ubuntu.com/ubuntu groovy-backports InRelease [89.2 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed InRelease [118 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages [969 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy/main Translation-en [507 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy/main amd64 

Re: [Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

2020-09-22 Thread Andreas Hasenack
See https://bugs.launchpad.net/bugs/1895302

On Tue, Sep 22, 2020, 07:41 Oliver Grawert <1888...@bugs.launchpad.net>
wrote:

> please note that the stable UbuntuCore18 images regressed due to this:
>
> https://github.com/snapcore/core18/issues/170
>
> ** Bug watch added: github.com/snapcore/core18/issues #170
>https://github.com/snapcore/core18/issues/170
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1888575
>
> Title:
>   Split motd-news config into a new package
>
> Status in base-files package in Ubuntu:
>   Fix Released
> Status in livecd-rootfs package in Ubuntu:
>   Invalid
> Status in ubuntu-meta package in Ubuntu:
>   Fix Released
> Status in base-files source package in Xenial:
>   Fix Released
> Status in livecd-rootfs source package in Xenial:
>   Triaged
> Status in ubuntu-meta source package in Xenial:
>   Fix Committed
> Status in base-files source package in Bionic:
>   Fix Released
> Status in livecd-rootfs source package in Bionic:
>   Invalid
> Status in ubuntu-meta source package in Bionic:
>   Fix Released
> Status in base-files source package in Focal:
>   Fix Released
> Status in livecd-rootfs source package in Focal:
>   Invalid
> Status in ubuntu-meta source package in Focal:
>   Fix Released
> Status in base-files source package in Groovy:
>   Fix Released
> Status in livecd-rootfs source package in Groovy:
>   Invalid
> Status in ubuntu-meta source package in Groovy:
>   Fix Released
>
> Bug description:
>   [Impact]
>   The motd-news script is largely useless for desktop users, as they
> rarely login via a text console. It makes more sense for server users.
>
>   We can use package dependencies to have the motd-news script enabled on
> servers, but disabled on desktops, and still handle upgrades. This is the
> plan:
>   - move /etc/default/motd-news from base-files into a new binary package
> (motd-news-config, produced by src:base-files)
>   - have ubuntu-server depend on motd-news-config
>   - have base-files break current ubuntu-server, so that if base-files if
> upgraded and ubuntu-server is installed, ubuntu-server will also be
> upgraded to the new version which has the depends on motd-news-config
>
>   Care must be taken to preserve a changed /etc/default/motd-news when
>   the upgrade installs the new motd-news-config package. For example, on
>   a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
>   to the new base-files and ubuntu-server, and gets the new motd-config-
>   news package, ENABLED=0 must remain set.
>
>   [Test Case]
>   a) base-files installed, ubuntu-server installed, unmodified
> /e/d/motd-news
>   apt install base-files
>   - upgrades ubuntu-server
>   - installs motd-news-config
>   - /e/d/motd-news remains, motd-news remains enabled
>
>   b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
>   apt install base-files
>   - upgrades ubuntu-server
>   - installs motd-news-config
>   - /e/d/motd-news remains with the original modification
>
>   c) base-files installed, ubuntu-server not installed, unmodified
> /e/d/motd-news
>   apt install base-files
>   - upgrades base-files
>   - removes /e/d/motd-news
>   - motd-news is disabled
>
>   d) base-files installed, ubuntu-server not installed, modified
> /e/d/motd-news
>   apt install base-files
>   - upgrades base-files
>   - /e/d/motd-news gets renamed to backup
>   - motd-news is disabled
>
>   e) removing motd-news-config will also remove ubuntu-server (since
>   it's a depends, and not a recommends)
>
>   f) upgrading just ubuntu-server should pull motd-news-config in, and
>   force-upgrade base-files
>
>   g) Removing motd-news-server leaves /e/d/motd-news around; purging
>   motd-news-server removes the /e/d/motd-news config file
>
>   h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
>   - apt install base-files
>   - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
>   - /e/d/motd-news is installed with ENABLED=0
>
>   i) base-files installed, ubuntu-server NOT installed, removed
> e/d/motd-news
>   - apt install base-files
>   - base-files is upgraded
>   - no /e/d/motd-news is installed, motd-news remains disabled
>
>   j) Perform a release upgrade from the previous ubuntu release to the
>   one being tested while having ubuntu-server NOT installed (or use a
>   desktop install). At the end, motd-news should be disabled. Verify
>   with:
>
>   $ sudo /etc/update-motd.d/50-motd-news --force
>   $ (no output)
>
>   k) Test that supporting changes for xenial are in place:
>
> i) verify grub-legacy-ec2 is not in the xenial server seed
> ii) verify that the rootfs manifest built from the ubuntu-cpc project
> contains the ubuntu-server package
> iii) verify that images built from the ubuntu-cpc project which purge
> grub-legacy-ec2 have retained ubuntu-server
>
>   [Regression Potential]
>   This update is about config 

[Touch-packages] [Bug 1890716] Re: xdg-mime query filetype index.html reports wrong type

2020-09-22 Thread Sebastien Bacher
The wrapper used depends of the environment, the previous one was under
a command line clean instance, on a GNOME based desktop

$  XDG_UTILS_DEBUG_LEVEL=1 xdg-mime query filetype index.html
Running gio info "/tmp/index.html"
text/html

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

Title:
  xdg-mime query filetype index.html reports wrong type

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

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'

2020-09-22 Thread Scott Stensland
here is output of running

journalctl -b -u whoopsie

journalctl -b -u apport-autoreport

on Ubuntu 20.10

which has same 100%  used by systemd


** Attachment added: "output of running journalctl -b -u whoopsie  and 
journalctl -b -u apport-autoreport"
   
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1891657/+attachment/5413149/+files/sss.log

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

Title:
  systemd 100% cpu usage apport-autoreport.service: Failed with result
  'start-limit-hit'

Status in apport package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  In Progress
Status in apport source package in Groovy:
  Confirmed
Status in systemd source package in Groovy:
  In Progress

Bug description:
  after upgrade from Ubuntu 20.04 to 20.10  
  seeing systemd use 100% cpu forever


  top

top - 10:16:19 up 20 min,  1 user,  load average: 3.91, 4.28, 3.39
Tasks: 332 total,   2 running, 330 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.7 us,  6.4 sy, 11.9 ni, 62.2 id,  0.0 wa,  0.0 hi,  0.8 si, 
 0.0 st
MiB Mem :  15917.6 total,   8553.4 free,   2604.3 used,   4759.9 
buff/cache
MiB Swap:   2048.0 total,   2048.0 free,  0.0 used.  12633.7 avail 
Mem 

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND  
  1 root  20   0  177316  12252   8684 R 100.0   0.1  15:01.25 
systemd  
   4636 kush  39  19  633796 176152  16360 S  98.3   1.1  17:51.56 
tracker-miner-f  
820 message+  20   0   10740   6452   4212 S  39.8   0.0   6:19.06 
dbus-daemon  
316 root  19  -1  535916 322896 320824 S  15.3   2.0   3:16.41 
systemd-journal  
844 syslog20   0  221136   5840   3920 S  13.6   0.0   2:14.52 
rsyslogd 
858 root  20   0   83708  74124   7568 S  12.7   0.5   2:06.98 
systemd-logind   
  5 root  20   0   0  0  0 I   3.4   0.0   0:05.01 
kworker/0:0-events   
  35566 kush  20   0 3850088 588344 262192 S   2.5   3.6   0:30.48 
MainThread   
   5626 kush  20   0 5004788 260876  93400 S   1.7   1.6   3:05.19 
gnome-shell  
   7033 kush  20   0  869792  66440  44272 S   1.7   0.4   0:06.05 
gnome-terminal-  
  36790 kush  20   0 2525432 156636  98568 S   1.7   1.0   0:04.99 
Web Content  
957 root  20   0 1556196  45044  24284 S   0.8   0.3   0:02.48 
containerd   
   1038 root  20   0   10460   4412   3300 S   0.8   0.0   0:00.16 
fancontrol   



  
sudo tail -n 100 /var/log/syslog
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting 

[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt 
It seems it comes down to a change in /lib/apparmor/apparmor.systemd
which now refuses to load profiles when running in a container.

Example with 3.0:
$ /lib/apparmor/apparmor.systemd reload
Not starting AppArmor in container

Example with 2.x
 /lib/apparmor/apparmor.systemd reload
Restarting AppArmor
Reloading AppArmor profiles 

This also explains why snap profiles work, the are loaded by snapd and
not by apparmor.service.

I'll attach a repro script and full logs of good and bad case.

** Attachment added: "repro script comparing current and proposed apparmor 
version"
   
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+attachment/5413150/+files/apparmor-repro.sh

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896405] Re: Cannot install libglib2.0-dev on ubuntu 20.04.1

2020-09-22 Thread Sebastien Bacher
Great that it worked out. The downgrade was trying to remove things
because libglib binaries need to be on the same version so it was
necessary to downgrade libglib2.0-bin/focal in addition to the main
library

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

Title:
  Cannot install  libglib2.0-dev on ubuntu 20.04.1

Status in glib2.0 package in Ubuntu:
  Invalid

Bug description:
  I already tried running `apt update/upgrade`, but it did not make any
  difference.

  Why these versions conflicts are happening?

  1. libglib2.0-bin : Conflicts: libglib2.0-bin:i386 but 2.64.2-1~fakesync1 is 
to be installed
  1. libglib2.0-bin:i386 : Conflicts: libglib2.0-bin but 2.64.3-1~ubuntu20.04.1 
is installed
  1. libglib2.0-dev : Depends: libglib2.0-0 (= 2.64.2-1~fakesync1) but 
2.64.3-1~ubuntu20.04.1 is installed
  1. libglib2.0-0 : Breaks: libglib2.0-0:i386 (!= 2.64.3-1~ubuntu20.04.1) but 
2.64.2-1~fakesync1 is to be installed
  1. libglib2.0-0:i386 : Breaks: libglib2.0-0 (!= 2.64.2-1~fakesync1) but 
2.64.3-1~ubuntu20.04.1 is installed

  ```
  $ sudo aptitude install libglib2.0-dev
  The following NEW packages will be installed:
gcc-10-base:i386{a} libblkid-dev{a} libblkid1:i386{a} libc6:i386{a} 
libcrypt1:i386{a} libelf1:i386{a} libffi-dev{a} libffi7:i386{a} 
libgcc-s1:i386{a} libglib2.0-0:i386{ab} 
libglib2.0-bin:i386{ab} libglib2.0-dev{b} libglib2.0-dev-bin{a} 
libidn2-0:i386{a} libmount-dev{a} libmount1:i386{a} libpcre2-8-0:i386{a} 
libpcre2-dev{a} libpcre2-posix2{a} 
libpcre3:i386{a} libselinux1:i386{a} libselinux1-dev{a} libsepol1-dev{a} 
libunistring2:i386{a} zlib1g:i386{a} 
  0 packages upgraded, 25 newly installed, 0 to remove and 0 not upgraded.

  Need to get 8.701 kB of archives. After unpacking 41,3 MB will be used.
  The following packages have unmet dependencies:
   libglib2.0-bin : Conflicts: libglib2.0-bin:i386 but 2.64.2-1~fakesync1 is to 
be installed
   libglib2.0-bin:i386 : Conflicts: libglib2.0-bin but 2.64.3-1~ubuntu20.04.1 
is installed
   libglib2.0-dev : Depends: libglib2.0-0 (= 2.64.2-1~fakesync1) but 
2.64.3-1~ubuntu20.04.1 is installed
   libglib2.0-0 : Breaks: libglib2.0-0:i386 (!= 2.64.3-1~ubuntu20.04.1) but 
2.64.2-1~fakesync1 is to be installed
   libglib2.0-0:i386 : Breaks: libglib2.0-0 (!= 2.64.2-1~fakesync1) but 
2.64.3-1~ubuntu20.04.1 is installed
  open: 2; closed: 4; defer: 0; conflict: 0

  The following actions will resolve these dependencies:

   Keep the following packages at their current version:
  1) libglib2.0-0:i386 [Not Installed]  
  2) libglib2.0-bin:i386 [Not Installed]
  3) libglib2.0-dev [Not Installed] 

  Accept this solution? [Y/n/q/?] y
  No packages will be installed, upgraded, or removed.
  0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B of archives. After unpacking 0 B will be used.
  ```

  ```
  $ cat /etc/os-release 
  NAME="Ubuntu"
  VERSION="20.04.1 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.1 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1896405/+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 1888575] Re: Split motd-news config into a new package

2020-09-22 Thread Oliver Grawert
please note that the stable UbuntuCore18 images regressed due to this:

https://github.com/snapcore/core18/issues/170

** Bug watch added: github.com/snapcore/core18/issues #170
   https://github.com/snapcore/core18/issues/170

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 

[Touch-packages] [Bug 1890270] Re: SRU: update gdb 9.2 for 20.04 LTS

2020-09-22 Thread Matthias Klose
package works as expected. test suite check done with the binary upload.

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

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

Title:
  SRU: update gdb 9.2 for 20.04 LTS

Status in gdb package in Ubuntu:
  New
Status in gdb source package in Focal:
  Fix Committed

Bug description:
  SRU: update gdb 9.2 for 20.04 LTS

  according to https://sourceware.org/gdb/ this is a bug fix release:

  """
  This is a minor corrective release over GDB 9.1, fixing the following issues:

  PR tui/25586 (Resizing the source/disassembly or command window produces 
corrupted display)
  PR gdb/25650 (GDB can't 'printf' a convenience variable holding an inferior 
address)
  PR build/25981 (Use of short i386 register names breaks compilation on recent 
Solaris 11.4)
  PR symtab/26003 (infinite loop loading symbols from separate debug objfile)
  PR build/26029 (GDB build failure on SPARC)
  """

  Regression potential: minimal, package also not used by normal users,
  but for development.

  Acceptence criteria:  Package builds, no regressions in the testsuite.

  The package also was part of a focal test rebuild, see LP: #1879481.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1890270/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt 
FYI - other testing might miss this as "starting a guest on groovy"
works with the new versions, but it will be without apparmor. Migrating
from focal or a pre-upgrade groovy shows the issues broken by apparmor
not being enabled.

** Changed in: apparmor (Ubuntu)
   Status: Incomplete => New

** Changed in: apparmor (Ubuntu)
   Importance: Low => High

** Tags added: block-proposed

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

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  New

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt 
I have backed up this container and its snapshot for later and re-run
the whole automation which got me that bad state.

That allowed me to run my automation again without removing this
container (in case we need it for debugging later). So I ran everything
again to check if it would happen again with the version now in groovy
proposed.

Ok it ran into the same issues again so it is reproducible with the current 
version in proposed.
Since in the tests have plenty of systems involved I need to cut it down and 
simplify it to just one ...

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

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  New

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1892290] Re: PXE load Focal initrd.img-5.4.0-42-generic always timeout

2020-09-22 Thread xinliang
To be noted that this issue also exists in Debian 10 and Ubuntu 18.04.
Because they all has commit 781b3e5efc3 (tftp: Do not use priority
queue).

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

Title:
  PXE load Focal initrd.img-5.4.0-42-generic always timeout

Status in grub2 package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  PXE booting Focal initrd always gets a timeout, but PXE booting Bionic initrd 
works
  error: timeout reading `initrd.img-5.4.0-42-generic'.

  grub.cfg
  
  menuentry "boot_iscsi"  {
  linux vmlinuz-5.4.0-42-generic  ...
  initrd initrd.img-5.4.0-42-generic
  }

  grub, kernel and initrd get from Focal boot dir
  $ cp /usr/lib/grub/arm64-efi-signed/grubnetaa64.efi.signed 
~/tftproot/grubaa64.efi
  $ cp /boot/vmlinuz-5.4.0-42-generic  ~/tftproot/
  $ cp /boot/initrd.img-5.4.0-42-generic ~/tftproot/

  hardware
  
  Real aarch64 server or qemu-system-aarch64 machine

  software
  
  $ apt search grub-efi-arm64
  Sorting... Done
  Full Text Search... Done
  grub-efi-arm64/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64 
[installed]
GRand Unified Bootloader, version 2 (ARM64 UEFI version)

  grub-efi-arm64-bin/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64 
[installed,automatic]
GRand Unified Bootloader, version 2 (ARM64 UEFI modules)

  grub-efi-arm64-dbg/focal-updates,focal-security 2.04-1ubuntu26.2 arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI debug files)

  grub-efi-arm64-signed/focal-updates,focal-security,now 
1.142.4+2.04-1ubuntu26.2 arm64 [installed]
GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)

  grub-efi-arm64-signed-template/focal-updates,focal-security 2.04-1ubuntu26.2 
arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI signing template)

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04 LTS
  Release:20.04
  Codename:   focal
  $ uname -a
  Linux j12-d05-07 5.4.0-42-generic #1 SMP Tue Jul 7 02:48:00 GMT 2020 aarch64 
aarch64 aarch64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1892290/+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 1892290] Re: PXE load Focal initrd.img-5.4.0-42-generic always timeout

2020-09-22 Thread xinliang
Verified that focal grub2 with above commit works.
grub> linux vmlinuz-5.4.0-47-generic
grub> echo $?
0
grub> initrd initrd.img-5.4.0-47-generic
grub> echo $?
0

Rebuild grub2 deb with above commit and install
$ git clone -b applied/ubuntu/focal-updates 
https://git.launchpad.net/ubuntu/+source/grub2
$ cd grub2; git cherry-pick  a6838bbc6726ad624bd2b94991f690b8e9d23c69 (which 
fetch from https://git.savannah.gnu.org/git/grub.git)
$ sudo apt-get build-dep grub2
$ dpkg-buildpackage -rfakeroot -b
$ cd ../; sudo apt install ./*.deb

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

Title:
  PXE load Focal initrd.img-5.4.0-42-generic always timeout

Status in grub2 package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  PXE booting Focal initrd always gets a timeout, but PXE booting Bionic initrd 
works
  error: timeout reading `initrd.img-5.4.0-42-generic'.

  grub.cfg
  
  menuentry "boot_iscsi"  {
  linux vmlinuz-5.4.0-42-generic  ...
  initrd initrd.img-5.4.0-42-generic
  }

  grub, kernel and initrd get from Focal boot dir
  $ cp /usr/lib/grub/arm64-efi-signed/grubnetaa64.efi.signed 
~/tftproot/grubaa64.efi
  $ cp /boot/vmlinuz-5.4.0-42-generic  ~/tftproot/
  $ cp /boot/initrd.img-5.4.0-42-generic ~/tftproot/

  hardware
  
  Real aarch64 server or qemu-system-aarch64 machine

  software
  
  $ apt search grub-efi-arm64
  Sorting... Done
  Full Text Search... Done
  grub-efi-arm64/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64 
[installed]
GRand Unified Bootloader, version 2 (ARM64 UEFI version)

  grub-efi-arm64-bin/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64 
[installed,automatic]
GRand Unified Bootloader, version 2 (ARM64 UEFI modules)

  grub-efi-arm64-dbg/focal-updates,focal-security 2.04-1ubuntu26.2 arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI debug files)

  grub-efi-arm64-signed/focal-updates,focal-security,now 
1.142.4+2.04-1ubuntu26.2 arm64 [installed]
GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)

  grub-efi-arm64-signed-template/focal-updates,focal-security 2.04-1ubuntu26.2 
arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI signing template)

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04 LTS
  Release:20.04
  Codename:   focal
  $ uname -a
  Linux j12-d05-07 5.4.0-42-generic #1 SMP Tue Jul 7 02:48:00 GMT 2020 aarch64 
aarch64 aarch64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1892290/+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 1895293] Re: After last upgrade systemd uses 100% CPU

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

** This bug is no longer a duplicate of bug 1890913
   init is using 100% of processor

** This bug has been marked a duplicate of bug 1891657
   systemd 100% cpu usage apport-autoreport.service: Failed with result 
'start-limit-hit'

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

Title:
  After last upgrade systemd uses 100% CPU

Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure, but none of the already reported bugs seems to fit. At
  shutdown I get for a moment many messages concerning "automatic report
  enabled but not possible" (roughly) and after showing these the
  shutdown lasts about one Minute.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.4-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: openafs nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Sep 11 14:30:32 2020
  InstallationDate: Installed on 2020-09-01 (10 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200826)
  MachineType: Hewlett-Packard HP Z420 Workstation
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic 
root=UUID=8d55d30d-adfe-4f99-9e71-193677d1ec1e ro quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2019
  dmi.bios.release: 3.96
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: J61 v03.96
  dmi.board.asset.tag: CZC4123JXT
  dmi.board.name: 1589
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 0.00
  dmi.chassis.asset.tag: CZC4123JXT
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrJ61v03.96:bd10/29/2019:br3.96:svnHewlett-Packard:pnHPZ420Workstation:pvr:rvnHewlett-Packard:rn1589:rvr0.00:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53335X G=D
  dmi.product.name: HP Z420 Workstation
  dmi.product.sku: LJ449AV
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895293/+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 1895631] Re: systemd at 100% handling apport failures

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

** This bug is no longer a duplicate of bug 1890913
   init is using 100% of processor

** This bug has been marked a duplicate of bug 1891657
   systemd 100% cpu usage apport-autoreport.service: Failed with result 
'start-limit-hit'

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

Title:
  systemd at 100% handling apport failures

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd is pegged at 100% after booting Groovy Desktop.

  Seems like an apport-report.service issue:

  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.

  I removed apport to resolve the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895631/+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 1890913] Re: init is using 100% of processor

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

** This bug has been marked a duplicate of bug 1891657
   systemd 100% cpu usage apport-autoreport.service: Failed with result 
'start-limit-hit'

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

Title:
  init is using 100% of processor

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  the `sbin/init splash` process is using more than 100% of processor
  after boot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246-2ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7
  Uname: Linux 5.8.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu44
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Sat Aug  8 22:14:37 2020
  InstallationDate: Installed on 2019-11-01 (280 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: LENOVO 2349KEG
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-12-generic 
root=/dev/mapper/vgubuntu-root ro i915.fastboot=1 quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/07/2019
  dmi.bios.release: 2.82
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G1ETC2WW (2.82 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2349KEG
  dmi.board.vendor: LENOVO
  dmi.board.version: Win8 Pro DPK TPG
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.ec.firmware.release: 1.14
  dmi.modalias: 
dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:br2.82:efr1.14:svnLENOVO:pn2349KEG:pvrThinkPadT430:rvnLENOVO:rn2349KEG:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad T430
  dmi.product.name: 2349KEG
  dmi.product.sku: LENOVO_MT_2349
  dmi.product.version: ThinkPad T430
  dmi.sys.vendor: LENOVO
  modified.conffile..etc.default.apport:
   # set this to 0 to disable apport, or to 1 to enable it
   # you can temporarily override this with
   # sudo service apport start force_start=1
   enabled=0
  mtime.conffile..etc.default.apport: 2020-08-08T22:11:41.151132

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890913/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'

2020-09-22 Thread Balint Reczey
Will be fixed in next systemd upload, in 246.6-1ubuntu1, at least for the 
systemd part.
https://github.com/systemd/systemd/issues/16669

** Changed in: systemd (Ubuntu Groovy)
   Status: Confirmed => In Progress

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

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

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

Title:
  systemd 100% cpu usage apport-autoreport.service: Failed with result
  'start-limit-hit'

Status in apport package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  In Progress
Status in apport source package in Groovy:
  Confirmed
Status in systemd source package in Groovy:
  In Progress

Bug description:
  after upgrade from Ubuntu 20.04 to 20.10  
  seeing systemd use 100% cpu forever


  top

top - 10:16:19 up 20 min,  1 user,  load average: 3.91, 4.28, 3.39
Tasks: 332 total,   2 running, 330 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.7 us,  6.4 sy, 11.9 ni, 62.2 id,  0.0 wa,  0.0 hi,  0.8 si, 
 0.0 st
MiB Mem :  15917.6 total,   8553.4 free,   2604.3 used,   4759.9 
buff/cache
MiB Swap:   2048.0 total,   2048.0 free,  0.0 used.  12633.7 avail 
Mem 

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND  
  1 root  20   0  177316  12252   8684 R 100.0   0.1  15:01.25 
systemd  
   4636 kush  39  19  633796 176152  16360 S  98.3   1.1  17:51.56 
tracker-miner-f  
820 message+  20   0   10740   6452   4212 S  39.8   0.0   6:19.06 
dbus-daemon  
316 root  19  -1  535916 322896 320824 S  15.3   2.0   3:16.41 
systemd-journal  
844 syslog20   0  221136   5840   3920 S  13.6   0.0   2:14.52 
rsyslogd 
858 root  20   0   83708  74124   7568 S  12.7   0.5   2:06.98 
systemd-logind   
  5 root  20   0   0  0  0 I   3.4   0.0   0:05.01 
kworker/0:0-events   
  35566 kush  20   0 3850088 588344 262192 S   2.5   3.6   0:30.48 
MainThread   
   5626 kush  20   0 5004788 260876  93400 S   1.7   1.6   3:05.19 
gnome-shell  
   7033 kush  20   0  869792  66440  44272 S   1.7   0.4   0:06.05 
gnome-terminal-  
  36790 kush  20   0 2525432 156636  98568 S   1.7   1.0   0:04.99 
Web Content  
957 root  20   0 1556196  45044  24284 S   0.8   0.3   0:02.48 
containerd   
   1038 root  20   0   10460   4412   3300 S   0.8   0.0   0:00.16 
fancontrol   



  
sudo tail -n 100 /var/log/syslog
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error 
reports when automatic reporting is enabled.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start 
request repeated too quickly.
Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed 
with result 'start-limit-hit'.
Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process 

[Touch-packages] [Bug 1890913] Re: init is using 100% of processor

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

Will be fixed in next upload, in 246.6-1ubuntu1
https://github.com/systemd/systemd/issues/16669

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

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

Title:
  init is using 100% of processor

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  the `sbin/init splash` process is using more than 100% of processor
  after boot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246-2ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7
  Uname: Linux 5.8.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu44
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Sat Aug  8 22:14:37 2020
  InstallationDate: Installed on 2019-11-01 (280 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: LENOVO 2349KEG
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-12-generic 
root=/dev/mapper/vgubuntu-root ro i915.fastboot=1 quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/07/2019
  dmi.bios.release: 2.82
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G1ETC2WW (2.82 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2349KEG
  dmi.board.vendor: LENOVO
  dmi.board.version: Win8 Pro DPK TPG
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.ec.firmware.release: 1.14
  dmi.modalias: 
dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:br2.82:efr1.14:svnLENOVO:pn2349KEG:pvrThinkPadT430:rvnLENOVO:rn2349KEG:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad T430
  dmi.product.name: 2349KEG
  dmi.product.sku: LENOVO_MT_2349
  dmi.product.version: ThinkPad T430
  dmi.sys.vendor: LENOVO
  modified.conffile..etc.default.apport:
   # set this to 0 to disable apport, or to 1 to enable it
   # you can temporarily override this with
   # sudo service apport start force_start=1
   enabled=0
  mtime.conffile..etc.default.apport: 2020-08-08T22:11:41.151132

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890913/+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 1895293] Re: After last upgrade systemd uses 100% CPU

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

** This bug has been marked a duplicate of bug 1890913
   init is using 100% of processor

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

Title:
  After last upgrade systemd uses 100% CPU

Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure, but none of the already reported bugs seems to fit. At
  shutdown I get for a moment many messages concerning "automatic report
  enabled but not possible" (roughly) and after showing these the
  shutdown lasts about one Minute.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.4-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: openafs nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Sep 11 14:30:32 2020
  InstallationDate: Installed on 2020-09-01 (10 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200826)
  MachineType: Hewlett-Packard HP Z420 Workstation
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic 
root=UUID=8d55d30d-adfe-4f99-9e71-193677d1ec1e ro quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/29/2019
  dmi.bios.release: 3.96
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: J61 v03.96
  dmi.board.asset.tag: CZC4123JXT
  dmi.board.name: 1589
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 0.00
  dmi.chassis.asset.tag: CZC4123JXT
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrJ61v03.96:bd10/29/2019:br3.96:svnHewlett-Packard:pnHPZ420Workstation:pvr:rvnHewlett-Packard:rn1589:rvr0.00:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53335X G=D
  dmi.product.name: HP Z420 Workstation
  dmi.product.sku: LJ449AV
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895293/+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 1895631] Re: systemd at 100% handling apport failures

2020-09-22 Thread Balint Reczey
*** This bug is a duplicate of bug 1891657 ***
https://bugs.launchpad.net/bugs/1891657

** This bug has been marked a duplicate of bug 1890913
   init is using 100% of processor

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

Title:
  systemd at 100% handling apport failures

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd is pegged at 100% after booting Groovy Desktop.

  Seems like an apport-report.service issue:

  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with 
result 'start-limit-hit'.
  Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when 
automatic reporting is enabled.
  Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request 
repeated too quickly.

  I removed apport to resolve the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895631/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt 
Ok, I have definitely a snapshot left that has "conserved" the bad
state.

$ lxc stop testkvm-groovy-from
$ lxc restore testkvm-groovy-from orig
$ lxc start testkvm-groovy-from
$ lxc exec testkvm-groovy-from
# aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

While silly this gets me back to normal from here
# aa-enforce /etc/apparmor.d/*
# aa-status
apparmor module is loaded.
32 profiles are loaded.
32 profiles are in enforce mode.
...


You see that we now have more than twice as much loaded

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

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896577] Re: FFE: new upstream release 20.2 and migrate to llvm 11

2020-09-22 Thread Timo Aaltonen
** Description changed:

  Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10.
- It's currrently at rc4, final was supposed to be out a month ago.
+ It's currrently at rc4, final was supposed to be out a month ago. It's
+ been in debian experimental since rc1.
  
  The packaging in debian also migrates to use llvm 11.
+ 
+ packages for groovy are available on ppa:canonical-x/x-staging

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

Title:
  FFE: new upstream release 20.2 and migrate to llvm 11

Status in mesa package in Ubuntu:
  New

Bug description:
  Mesa 20.2.0 has been delayed by upstream, but we still want it in
  20.10. It's currrently at rc4, final was supposed to be out a month
  ago. It's been in debian experimental since rc1.

  The packaging in debian also migrates to use llvm 11.

  packages for groovy are available on ppa:canonical-x/x-staging

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


  1   2   >