[Group.of.nepali.translators] [Bug 2044657] Re: Multiple data corruption issues in zfs

[Dimitri John Ledkov]

** Changed in: zfs-linux (Ubuntu Noble)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/2044657

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  Confirmed
Status in zfs-linux source package in Jammy:
  Confirmed
Status in zfs-linux source package in Lunar:
  Confirmed
Status in zfs-linux source package in Mantic:
  Incomplete
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  
  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will 
introduce slight slow down on amd64 (for hw accelerated assembly code-paths 
only in the encryption primitives)
   
   * Uncertain of the perfomance impact of the extra checks in dnat patch fix 
itself. Possibly affecting speed of operation, at the benefit of correctness.

  [ Other Info ]
   
   * https://github.com/openzfs/zfs/pull/15571 is most current consideration of 
affairs

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 2004391] Re: xenial/linux-aws-hwe: 4.15.0-1151.164~16.04.1 -proposed tracker

[Dimitri John Ledkov]

The build is correct w.r.t. builtin revocations and the vmlinuz
signature.

However for the furture uploads sbsigntools build-depends should be
added on the -signed package.

** Also affects: kernel-sru-workflow/kernel-signoff
   Importance: Undecided
   Status: New

** Changed in: kernel-sru-workflow/kernel-signoff
   Status: New => Fix Released

** Changed in: kernel-sru-workflow/kernel-signoff
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/2004391

Title:
  xenial/linux-aws-hwe: 4.15.0-1151.164~16.04.1 -proposed tracker

Status in canonical-signing-jobs task00 series:
  Fix Released
Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Invalid
Status in Kernel SRU Workflow boot-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow kernel-signoff series:
  Fix Released
Status in Kernel SRU Workflow new-review series:
  Fix Released
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-generate series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-signing-to-proposed series:
  Invalid
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Committed
Status in Kernel SRU Workflow promote-to-security series:
  Invalid
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  Invalid
Status in Kernel SRU Workflow sru-review series:
  Fix Released
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-aws-hwe source package in Xenial:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  built:
from: d013442608a07737
route-entry: 1
  delta:
promote-to-proposed: [meta, signed, main, generate]
  flag:
boot-testing-requested: true
stream-from-cycle: true
  issue: KSRU-6505
  kernel-stable-master-bug: 2004392
  packages:
generate: linux-generate-aws-hwe
main: linux-aws-hwe
meta: linux-meta-aws-hwe
signed: linux-signed-aws-hwe
  phase: Promote to Proposed
  phase-changed: Friday, 24. February 2023 20:16 UTC
  reason:
promote-to-proposed: Pending -- packages copying to Signing (main:M
  generate:M signed:M meta:M)
  synthetic:
:promote-to-as-proposed: Invalid
  variant: debs
  versions:
main: 4.15.0-1151.164~16.04.1
meta: 4.15.0.1151.134
signed: 4.15.0-1151.164~16.04.1
  ~~:
clamps:
  new-review: d013442608a07737
  promote-to-proposed: d013442608a07737
  self: 4.15.0-1151.164~16.04.1
  sru-review: d013442608a07737

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-signing-jobs/task00/+bug/2004391/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 2004407] Re: xenial/linux-oracle: 4.15.0-1115.126~16.04.1 -proposed tracker

[Dimitri John Ledkov]

** Also affects: kernel-sru-workflow/kernel-signoff
   Importance: Undecided
   Status: New

** Changed in: kernel-sru-workflow/kernel-signoff
   Status: New => Fix Released

** Changed in: kernel-sru-workflow/kernel-signoff
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/2004407

Title:
  xenial/linux-oracle: 4.15.0-1115.126~16.04.1 -proposed tracker

Status in canonical-signing-jobs task00 series:
  Fix Released
Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Invalid
Status in Kernel SRU Workflow boot-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow kernel-signoff series:
  Fix Released
Status in Kernel SRU Workflow new-review series:
  Fix Released
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-generate series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-signing-to-proposed series:
  Invalid
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Committed
Status in Kernel SRU Workflow promote-to-security series:
  Invalid
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  Invalid
Status in Kernel SRU Workflow sru-review series:
  Fix Released
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-oracle source package in Xenial:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  built:
from: 3ffa4673de8b0a71
route-entry: 1
  delta:
promote-to-proposed: [meta, signed, main, generate]
  flag:
boot-testing-requested: true
stream-from-cycle: true
  issue: KSRU-6521
  kernel-stable-master-bug: 2004408
  packages:
generate: linux-generate-oracle
main: linux-oracle
meta: linux-meta-oracle
signed: linux-signed-oracle
  phase: Promote to Proposed
  phase-changed: Monday, 20. February 2023 14:16 UTC
  reason:
promote-to-proposed: Pending -- packages copying to Signing (main:M
  generate:M signed:M meta:M)
  synthetic:
:promote-to-as-proposed: Invalid
  variant: debs
  versions:
main: 4.15.0-1115.126~16.04.1
meta: 4.15.0.1115.96
signed: 4.15.0-1115.126~16.04.1
  ~~:
clamps:
  new-review: 3ffa4673de8b0a71
  promote-to-proposed: 3ffa4673de8b0a71
  self: 4.15.0-1115.126~16.04.1
  sru-review: 3ffa4673de8b0a71

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-signing-jobs/task00/+bug/2004407/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1936857] Re: grub-install: error: efibootmgr: not found.

[Dimitri John Ledkov]

** Tags added: bionic regression-proposed

** Package changed: grub2 (Ubuntu) => grub2-signed (Ubuntu)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1936857

Title:
  grub-install: error: efibootmgr: not found.

Status in grub2-signed package in Ubuntu:
  New
Status in grub2-signed source package in Xenial:
  Confirmed
Status in grub2-signed source package in Bionic:
  Confirmed

Bug description:
  grub-install from 2.02~beta2-36ubuntu3.32 on xenial/arm64 fails with:

  ubuntu@ubuntu:~$ sudo grub-install
  Installing for arm64-efi platform.
  grub-install: error: efibootmgr: not found.

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1979200] [NEW] check-tasks

[Dimitri John Ledkov]

Public bug reported:

check-tasks

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

** Affects: hello (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: hello (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: hello (Ubuntu Impish)
 Importance: Undecided
 Status: New

** Affects: hello (Ubuntu Jammy)
 Importance: Undecided
 Status: New

** Affects: hello (Ubuntu Kinetic)
 Importance: Undecided
 Status: New

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

** Also affects: hello (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: hello (Ubuntu Impish)
   Importance: Undecided
   Status: New

** Also affects: hello (Ubuntu Kinetic)
   Importance: Undecided
   Status: New

** Also affects: hello (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1979200

Title:
  check-tasks

Status in hello package in Ubuntu:
  New
Status in hello source package in Xenial:
  New
Status in hello source package in Focal:
  New
Status in hello source package in Impish:
  New
Status in hello source package in Jammy:
  New
Status in hello source package in Kinetic:
  New

Bug description:
  check-tasks

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1928648] Re: expiring trust anchor compatibility issue

[Dimitri John Ledkov]

** Changed in: gnutls28 (Ubuntu Trusty)
   Status: Confirmed => Won't Fix

** Also affects: gnutls28 (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928648

Title:
  expiring trust anchor compatibility issue

Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls28 source package in Precise:
  Won't Fix
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in gnutls28 source package in Xenial:
  Fix Released
Status in gnutls28 source package in Bionic:
  Fix Released
Status in gnutls28 source package in Focal:
  New

Bug description:
  [Impact]

   * gnutls28 fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install wget gnutls-bin
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com

  bad result:
  - Status: The certificate is NOT trusted. The certificate chain uses expired 
certificate.
  *** PKI verification of server certificate failed...
  *** Fatal error: Error in the certificate.
  *** handshake has failed: Error in the certificate.

  good result:
  - Status: The certificate is trusted.
  - Description: 
(TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
  - Session ID: 
A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04
  - Options: OCSP status request,
  - Handshake was completed

  Connection should be successful and trusted with correctly working
  gnutls client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently gnutls28 in bionic and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in GnuTLS 3.6.14, but probably should be
  backported to bionic and earlier if it was not already been done so.

  https://gitlab.com/gnutls/gnutls/-/issues/1008

  https://gitlab.com/gnutls/gnutls/-/merge_requests/1271

  Openssl bug report for this issue is
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989

  Bionic packages available from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4661

  Xenial packages available from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4663

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1928679] Re: Support importing mokx keys into revocation list from the mok table

[Dimitri John Ledkov]

** Also affects: linux-azure-5.8 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-azure-5.8 (Ubuntu Hirsute)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu Xenial)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928679

Title:
  Support importing mokx keys into revocation list from the mok table

Status in linux package in Ubuntu:
  Fix Released
Status in linux-azure-5.8 package in Ubuntu:
  Invalid
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure-5.8 source package in Xenial:
  Invalid
Status in linux-oem-5.10 source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  New
Status in linux-azure-5.8 source package in Bionic:
  Invalid
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux source package in Focal:
  New
Status in linux-azure-5.8 source package in Focal:
  New
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  Fix Released
Status in linux-azure-5.8 source package in Hirsute:
  Invalid
Status in linux-oem-5.10 source package in Hirsute:
  Invalid

Bug description:
  [Impact]

   * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx)
  which revokes many Ubuntu kernel hashes and 2012 signing key.

   * Kernel should import those into it's %:.blacklist keyring such that
  it prohibits signed kexec of the revoked kernels.

   * v5.13-rc1 kernel has learned how to import mokx and how to import
  full certs into the %:.blacklist keyring.

   * However, it only does so by reading MokListXRT efi variable.

   * Due to the large size of Ubuntu's vendor-dbx, shim does not create
  MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2
  MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also
  exposes MokListXRT via mokvar table, which is easier to parse and
  contains all the revocations in full. Kernel needs a patch to read
  MokListXRT via mokvar table.

   * We have two options on how to proceed from here, either we include
  the same hashes and certs as our vendordbx in in the kernel as
  revocation list, or we fix kernel to read MokListXRT via mokvar table

   * The above is known as CVE-2020-26541

   * Separately it would be nice to add informational dmesg messages
  when revoking signing certificates, as a good indication that signing
  key rotation events have happened and have been applied correctly.

  [Test Plan]

   * Boot kernel with 15.4 based Ubuntu shim

   * Install keyutils package

   * Execute $ sudo keyctl list %:.blacklist it should list in exccess
  of 300+ hash entries. It also must list assymetric Canonical signing
  key from 2012.

   * Separately check dmesg to observe that asymmetric canonical signing
  key from 2012 is revoked.

    * $ sudo ls /sys/firmware/efi/mok-variables
  MokListRT  MokListXRT  SbatLevelRT

  When booted with shim, the mok-variables directory above should exist,
  and contain at least `MokListRT  MokListXRT  SbatLevelRT` files.

  In kernel messages, the CA certificate should be loaded via MOKvar
  table i.e:

     * $ sudo journalctl -b -k | grep -A1 'MOKvar table'
  Sep 27 13:11:04 champion-spaniel kernel: integrity: Loading X.509 
certificate: UEFI:MokListRT (MOKvar table)
  Sep 27 13:11:04 champion-spaniel kernel: integrity: Loaded X.509 cert 
'Canonical Ltd. Master Certificate Authority: 
ad91990bc22ab1f517048c23b6655a268e345a63

  [Where problems could occur]

   * EFI variable storage can be full thus preventing shim to mirror
  efivars and the moktable. On decent hardware this should not happen,
  but has been observed to be corrupted on some older EDKII based OVMF
  instances with small EFI variable storage space (pre-4MB).

  [Other Info]

   * The patches to fix the above have been submitted upstream

  
https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.led...@canonical.com/

  
https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.led...@canonical.com/

  This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE
  kernel, until accepted upstream.

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1932029] Re: Support builtin revoked certificates

[Dimitri John Ledkov]

** Also affects: linux-azure-5.8 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-azure-5.8 (Ubuntu Hirsute)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: linux-azure-5.8 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1932029

Title:
  Support builtin revoked certificates

Status in linux package in Ubuntu:
  Fix Released
Status in linux-azure-5.8 package in Ubuntu:
  Invalid
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure-5.8 source package in Xenial:
  Invalid
Status in linux-oem-5.10 source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  New
Status in linux-azure-5.8 source package in Bionic:
  Invalid
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux source package in Focal:
  New
Status in linux-azure-5.8 source package in Focal:
  New
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  Fix Released
Status in linux-azure-5.8 source package in Hirsute:
  Invalid
Status in linux-oem-5.10 source package in Hirsute:
  Invalid

Bug description:
  [Impact]

  Upstream linux kernel now supports configuring built-in revoked
  certificates for the .blacklist keyring.

  Add support in our kernel configuration to have built-in revoked
  certificates.

  Revoke UEFI amd64 & arm64 2012 signing certificate.

  Under UEFI Secureboot with lockdown, shim may attempt to communicate
  revoked certificates to the kernel and depending on how good EFI
  firmware is, this may or may not succeed.

  By having these built-in, it will be prohibited to kexec file_load
  older kernels that were signed with now revoked certificates, however
  one boots.

  [Test Plan]

   * Boot kernel directly, or just with grub, and without shim

   * Check that

  $ sudo keyctl list %:.blacklist

  Contains assymetric 2012 key.

  [Where problems could occur]

   * Derivative and per-arch kernels may need to revoke different keys,
  thus this should be evaluated on per arch & flavour basis as to which
  keys to revoke.

  [Other Info]

   * In theory, this only needs to be revoked on amd64 and arm64, but
  empty revocation list is not allowed by the kernel configury, thus at
  the moment revoking 2012 UEFI cert for all architectures.

   * an ubuntu kernel team regression test is being added to assert that 
expected revoked certificates have been revoked
  see https://lists.ubuntu.com/archives/kernel-team/2021-August/122986.html

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1928648] Re: expiring trust anchor compatibility issue

[Dimitri John Ledkov]

** Changed in: gnutls28 (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: gnutls28 (Ubuntu Precise)
   Status: New => Won't Fix

** Changed in: gnutls28 (Ubuntu Bionic)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928648

Title:
  expiring trust anchor compatibility issue

Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls28 source package in Precise:
  Won't Fix
Status in gnutls28 source package in Trusty:
  New
Status in gnutls28 source package in Xenial:
  New
Status in gnutls28 source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * gnutls28 fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install wget gnutls-bin
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com

  bad result:
  - Status: The certificate is NOT trusted. The certificate chain uses expired 
certificate.
  *** PKI verification of server certificate failed...
  *** Fatal error: Error in the certificate.
  *** handshake has failed: Error in the certificate.

  good result:
  - Status: The certificate is trusted.
  - Description: 
(TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
  - Session ID: 
A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04
  - Options: OCSP status request,
  - Handshake was completed

  Connection should be successful and trusted with correctly working
  gnutls client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently gnutls28 in bionic and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in GnuTLS 3.6.14, but probably should be
  backported to bionic and earlier if it was not already been done so.

  https://gitlab.com/gnutls/gnutls/-/issues/1008

  https://gitlab.com/gnutls/gnutls/-/merge_requests/1271

  Openssl bug report for this issue is
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1928989] [NEW] expiring trust anchor compatibility issue

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * openssl fails to talk to letsencrypt website past September 2021,
despite trusting the letsencrypt root certificate.

[Test Plan]

 * Import staging cert equivalent to ISRG Root X1
https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

 * Import expired staging cert equivalen tto DST Root CA X3
https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

 * Test connectivity to the expired-root-ca test website
https://expired-root-ca-test.germancoding.com

setup:

apt install openssl
wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

test case:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername 
expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

bad result:
connection failed

good result:
connection successful

Connection should be successful and trusted with correctly working
openssl s_client that can manage to ignore expired CA, and build a valid
trust path using non-expired CA in the chain.

[Where problems could occur]

 * Changes as to how the trust paths are built in TLS connection may
result in introducing bugs (failure to connect to valid sites) and/or
security vulnerabilities (connecting to invalid sites successfully).

[Other Info]

 * Background info
 * The current chain from letsencrypt is expiring, they are adding a new chain, 
but also keeping the expiring one. This will result in connectivity issues when 
using old gnutls/openssl against websites using the default letsencrypt 
configuration after September 2021.

https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

Currently openssl in xenial and earlier will not establish a connection,
if any parts of the trust chain have expired, even though alternative
non-expired chains are available.

This has been fixed in OpenSSL 1.1.0+ by setting
X509_V_FLAG_TRUSTED_FIRST by default see
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

gnutls bug for this is
https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

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

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

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


** Tags: letsencrypt

** Also affects: openssl (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  New

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed

  good result:
  connection successful

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues 

[Group.of.nepali.translators] [Bug 1928674] [NEW] due to a new recommends grub-efi-arm64-signed is installed which does not have postinst.d script

[Dimitri John Ledkov]

*** This bug is a security vulnerability ***

Public security bug reported:

[Impact]

 * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.

 * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64.

 * This results in newly installed kernels not getting added to grub.cfg
and thus upon reboot one does not boot into the new kernel.

 * In later series these scripts moved to grub2-common. Maybe we should
move these to grub2-common in bionic and earlier too, for compatibility
with onegrub. Or alternatively grub2-signed should ship these in grub-
efi-{amd64,arm64}-signed packages too.

[Test Plan]

 * Install new grubs

 * Install a new kernel that was not installed before

 * Observe that grub.cfg is regenerated and new kernel is present

 * Remove an old kernel

 * Observe that grub.cfg is regenerated and new kernel is removed from
grub.cfg

[Where problems could occur]

 * These are conffiles. Although nobody should modify them, care should
be taken when moving conffiles around.

[Other Info]

 * First reported by klebers

** Affects: grub2-signed (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: grub2-signed (Ubuntu Trusty)
 Importance: Undecided
 Status: Triaged

** Affects: grub2-signed (Ubuntu Xenial)
 Importance: Undecided
 Status: Triaged

** Affects: grub2-signed (Ubuntu Bionic)
 Importance: Undecided
 Status: Triaged

** Also affects: grub2-signed (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: grub2-signed (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: grub2-signed (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Information type changed from Public to Public Security

** Changed in: grub2-signed (Ubuntu)
   Status: New => Fix Released

** Changed in: grub2-signed (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: grub2-signed (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: grub2-signed (Ubuntu Bionic)
   Status: New => Triaged

** Description changed:

  [Impact]
  
-  * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
+  * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
  with grub-efi-arm64-signed installed, without grub-efi-arm64.
  
-  * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
+  * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
  with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64.
  
-  * This results in newly installed kernels not getting added to grub.cfg
+  * This results in newly installed kernels not getting added to grub.cfg
  and thus upon reboot one does not boot into the new kernel.
  
-  * In later series these scripts moved to grub2-common. Maybe we should
+  * In later series these scripts moved to grub2-common. Maybe we should
  move these to grub2-common in bionic and earlier too, for compatibility
- with onegrub.
- 
+ with onegrub. Or alternatively grub2-signed should ship these in grub-
+ efi-{amd64,arm64}-signed packages too.
  
  [Test Plan]
  
-  * Install new grubs
+  * Install new grubs
  
-  * Install a new kernel that was not installed before
+  * Install a new kernel that was not installed before
  
-  * Observe that grub.cfg is regenerated and new kernel is present
+  * Observe that grub.cfg is regenerated and new kernel is present
  
-  * Remove an old kernel
+  * Remove an old kernel
  
-  * Observe that grub.cfg is regenerated and new kernel is removed from
+  * Observe that grub.cfg is regenerated and new kernel is removed from
  grub.cfg
  
  [Where problems could occur]
  
-  * These are conffiles. Although nobody should modify them, care should
+  * These are conffiles. Although nobody should modify them, care should
  be taken when moving conffiles around.
  
  [Other Info]
-  
-  * First reported by klebers
+ 
+  * First reported by klebers

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928674

Title:
  due to a new recommends grub-efi-arm64-signed is installed which does
  not have postinst.d script

Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2-signed source package in Trusty:
  Triaged
Status in grub2-signed source package in Xenial:
  Triaged
Status in grub2-signed source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
  with grub-efi-arm64-signed installed, without grub-efi-arm64.

   * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
  with grub-efi-amd64-signed installed without grub-pc or grub-efi-
  amd64.

   * This results in newly installed 

[Group.of.nepali.translators] [Bug 1928648] [NEW] expiring trust anchor compatibility issue

[Dimitri John Ledkov]

*** This bug is a security vulnerability ***

Public security bug reported:

https://community.letsencrypt.org/t/openssl-client-compatibility-
changes-for-let-s-encrypt-certificates/143816

Currently gnutls28 in bionic and earlier will not establish a
connection, if any parts of the trust chain have expired, even though
alternative non-expired chains are available.

This has been fixed in GnuTLS 3.6.14, but probably should be backported
to bionic and earlier if it was not already been done so.

https://gitlab.com/gnutls/gnutls/-/issues/1008

https://gitlab.com/gnutls/gnutls/-/merge_requests/1271

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

** Affects: gnutls28 (Ubuntu Precise)
 Importance: Undecided
 Status: New

** Affects: gnutls28 (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: gnutls28 (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: gnutls28 (Ubuntu Bionic)
 Importance: Undecided
 Status: New

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

** Also affects: gnutls28 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

** Also affects: gnutls28 (Ubuntu Precise)
   Importance: Undecided
   Status: New

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

** Information type changed from Public to Public Security

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1928648

Title:
  expiring trust anchor compatibility issue

Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls28 source package in Precise:
  New
Status in gnutls28 source package in Trusty:
  New
Status in gnutls28 source package in Xenial:
  New
Status in gnutls28 source package in Bionic:
  New

Bug description:
  https://community.letsencrypt.org/t/openssl-client-compatibility-
  changes-for-let-s-encrypt-certificates/143816

  Currently gnutls28 in bionic and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in GnuTLS 3.6.14, but probably should be
  backported to bionic and earlier if it was not already been done so.

  https://gitlab.com/gnutls/gnutls/-/issues/1008

  https://gitlab.com/gnutls/gnutls/-/merge_requests/1271

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1926748] [NEW] regression in xenial updates - grub2 cannot handle new arm64 relocations

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * regression in xenial updates - grub2 cannot handle new relocations

 * grub-efi-arm64-bin gained new recommends on -signed package which is
attempted to be installed

 * it pulls in one grub which was built with a newer toolchain and has
more relocations

 * non-secureboot grub-install in xenial fails to install it when
creating core.efi, because it does not know how to handle new
relocations.

 * We need to cherrypick patches from 2.02 (which are in bionic+) to
xenial & trusty.

[Test Plan]

 * install new grub2-common grub-common

 * install grub-efi-arm64-signed from xenial-updates

 * package installation should be successful

 * this is executed as part of autopkgtest upgrades when testing any
package on xenial in our autopkgtest cloud

[Where problems could occur]

 * we are rebuilding grub2 which will have to go into security pocket
eventually. Thus it's best to rebuild grub2 in security pocket.

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

** Affects: grub2 (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: grub2 (Ubuntu Xenial)
 Importance: Undecided
 Status: New


** Tags: regresion-update-xenial regression-update xenial

** Tags removed: regression-up
** Tags added: regresion-update-xenial regression-update xenial

** Also affects: grub2 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

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

** Description changed:

  [Impact]
  
-  * regression in xenial updates - grub2 cannot handle new relocations
+  * regression in xenial updates - grub2 cannot handle new relocations
  
-  * grub-efi-arm64-bin gained new recommends on -signed package which is
+  * grub-efi-arm64-bin gained new recommends on -signed package which is
  attempted to be installed
  
-  * it pulls in one grub which was built with a newer toolchain and has
+  * it pulls in one grub which was built with a newer toolchain and has
  more relocations
  
-  * non-secureboot grub-install in xenial fails to install it when
+  * non-secureboot grub-install in xenial fails to install it when
  creating core.efi, because it does not know how to handle new
  relocations.
  
+  * We need to cherrypick patches from 2.02 (which are in bionic+) to
+ xenial & trusty.
+ 
  [Test Plan]
  
-  * install new grub2-common grub-common
+  * install new grub2-common grub-common
  
-  * install grub-efi-arm64-signed from xenial-updates
+  * install grub-efi-arm64-signed from xenial-updates
  
-  * package installation should be successful
+  * package installation should be successful
  
-  * this is executed as part of autopkgtest upgrades when testing any
+  * this is executed as part of autopkgtest upgrades when testing any
  package on xenial in our autopkgtest cloud
  
  [Where problems could occur]
  
-  * we are rebuilding grub2 which will have to go into security pocket
+  * we are rebuilding grub2 which will have to go into security pocket
  eventually. Thus it's best to rebuild grub2 in security pocket.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1926748

Title:
  regression in xenial updates - grub2 cannot handle new arm64
  relocations

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  New
Status in grub2 source package in Xenial:
  New

Bug description:
  [Impact]

   * regression in xenial updates - grub2 cannot handle new relocations

   * grub-efi-arm64-bin gained new recommends on -signed package which
  is attempted to be installed

   * it pulls in one grub which was built with a newer toolchain and has
  more relocations

   * non-secureboot grub-install in xenial fails to install it when
  creating core.efi, because it does not know how to handle new
  relocations.

   * We need to cherrypick patches from 2.02 (which are in bionic+) to
  xenial & trusty.

  [Test Plan]

   * install new grub2-common grub-common

   * install grub-efi-arm64-signed from xenial-updates

   * package installation should be successful

   * this is executed as part of autopkgtest upgrades when testing any
  package on xenial in our autopkgtest cloud

  [Where problems could occur]

   * we are rebuilding grub2 which will have to go into security pocket
  eventually. Thus it's best to rebuild grub2 in security pocket.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : 

[Group.of.nepali.translators] [Bug 1926175] [NEW] something something precise (test bug)

[Dimitri John Ledkov]

Public bug reported:

something something precise (test bug)

** Affects: linux-gcp (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: linux-gcp (Ubuntu Precise)
 Importance: Undecided
 Status: Won't Fix

** Affects: linux-gcp (Ubuntu Trusty)
 Importance: Undecided
 Status: In Progress

** Affects: linux-gcp (Ubuntu Xenial)
 Importance: Undecided
 Status: Invalid

** Also affects: linux-gcp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux-gcp (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: linux-gcp (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: linux-gcp (Ubuntu)
   Status: New => Fix Released

** Changed in: linux-gcp (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: linux-gcp (Ubuntu Xenial)
   Status: Fix Released => Invalid

** Changed in: linux-gcp (Ubuntu Precise)
   Status: New => Won't Fix

** Changed in: linux-gcp (Ubuntu Trusty)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1926175

Title:
  something something precise (test bug)

Status in linux-gcp package in Ubuntu:
  Fix Released
Status in linux-gcp source package in Precise:
  Won't Fix
Status in linux-gcp source package in Trusty:
  In Progress
Status in linux-gcp source package in Xenial:
  Invalid

Bug description:
  something something precise (test bug)

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1915536] Re: one grub

[Dimitri John Ledkov]

** Changed in: grub2-unsigned (Ubuntu Groovy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1915536

Title:
  one grub

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2-unsigned package in Ubuntu:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Committed
Status in grub2-signed source package in Xenial:
  Fix Committed
Status in grub2-unsigned source package in Xenial:
  Fix Committed
Status in grub2 source package in Bionic:
  Fix Committed
Status in grub2-signed source package in Bionic:
  Fix Committed
Status in grub2-unsigned source package in Bionic:
  Fix Committed
Status in grub2 source package in Focal:
  Fix Committed
Status in grub2-signed source package in Focal:
  Fix Committed
Status in grub2-unsigned source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Fix Released
Status in grub2-signed source package in Groovy:
  Fix Released
Status in grub2-unsigned source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Fix Released
Status in grub2-signed source package in Hirsute:
  Fix Released
Status in grub2-unsigned source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  The proposal is to split src:grub2 into two source packages.

  src:grub2 will continue to build most things, apart from bin|dbg
  |signing-tempate binary packages for platforms that get signed.

  src:grub2-unsigned source package is source-full copy of src:grub2
  that only builds bin|dbg|signing-tempate binary packages for platforms
  that get signed and submits monolithic binaries for signing.

  src:grub2-signed is built as before, but its maintainer scripts should
  be compatible across grub2-common from precise and up.

  Stable series will receive grub2 update that drops building bin|dbg
  |signing-template.

  Stable series will receive binary-copy of grub2-unsigned &
  grub2-signed, thus on signed platforms EFI apps and modules will be
  the same across all series.

  [Caveats]

  * In devel series, always upload grub2 with matching
  src:grub2-unsigned and src:grub2-signed. The unsigned package can be
  build with ./debian/rules generate-grub2-unsigned command from
  src:grub2.

  * In stable series, only upload src:grub2 when fixes needed in update-
  grub / grub.cfg / grub-install / etc, but not in the efi modules &
  apps.

  * As needed, binary copy grub2-unsigned & grub2-signed from later
  series to stable series.

  [Test Case]

   * Upgrade to new packages

   * Observe that system boots, one can use grub-mkimage / grub-mkrescue
  without issues.

  [Where problems could occur]

   * There might be regression on the EFI platforms with grub 2.04 that
  have not so far been caught on Focal / Groovy / Hirsute.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1878969] Re: time-epoch never changes in SRUs

[Dimitri John Ledkov]

with core-initrd v40, each new initrd build increases time epoch.

This still means that for brand new account keys, one needs to wait or
build a new kernel to be able to boot in UC20.

** Changed in: ubuntu-core-initramfs
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1878969

Title:
  time-epoch never changes in SRUs

Status in ubuntu-core-initramfs:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New

Bug description:
  [Impact]

   * Systems without hwclock come up with a fixed time epoch which is not 
updated in SRUs
   * Ideally booting with a newer built of systemd should move time epoch to be 
at least when systemd was last built. For example to the value of 
SOURCE_DATE_EPOCH.

  [Test Case]

   * Boot without network NTP or hwclock
   * Observe that the epoch is the same as the time when NEWS entry in the 
systemd source code was last touched.
   * Boot newer update of systemd, observe that the time epoch is at least 2020

  [Regression Potential]

   * Bad epoch, may result in unable to perform TLS connections,
  validated GPG signatures, and snapd assertions. Changing epoch to be
  more recent is desired. Some machines may rely on the fact that
  "bionic" without hwclock always comes up in year 2018. But in practice
  that is incorrect thing to do.

  [Other Info]
   
   * By default

  option('time-epoch', type : 'integer', value : '-1',
 description : 'time epoch for time clients')

  in systemd is set to the modification time of the NEW entry
  time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int()

  If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value
  to be compliant with the https://reproducible-
  builds.org/docs/timestamps/ specification.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1915536] Re: one grub

[Dimitri John Ledkov]

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

** Changed in: grub2-signed (Ubuntu Hirsute)
   Status: Fix Released => In Progress

** Also affects: grub2-unsigned (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1915536

Title:
  one grub

Status in grub2 package in Ubuntu:
  In Progress
Status in grub2-signed package in Ubuntu:
  In Progress
Status in grub2-unsigned package in Ubuntu:
  New
Status in grub2 source package in Xenial:
  Fix Committed
Status in grub2-signed source package in Xenial:
  Fix Committed
Status in grub2-unsigned source package in Xenial:
  New
Status in grub2 source package in Bionic:
  Fix Committed
Status in grub2-signed source package in Bionic:
  Fix Committed
Status in grub2-unsigned source package in Bionic:
  New
Status in grub2 source package in Focal:
  Fix Committed
Status in grub2-signed source package in Focal:
  Fix Committed
Status in grub2-unsigned source package in Focal:
  New
Status in grub2 source package in Groovy:
  Fix Committed
Status in grub2-signed source package in Groovy:
  Fix Committed
Status in grub2-unsigned source package in Groovy:
  New
Status in grub2 source package in Hirsute:
  In Progress
Status in grub2-signed source package in Hirsute:
  In Progress
Status in grub2-unsigned source package in Hirsute:
  New

Bug description:
  [Impact]

  The proposal is to split src:grub2 into two source packages.

  src:grub2 will continue to build most things, apart from bin|dbg
  |signing-tempate binary packages for platforms that get signed.

  src:grub2-unsigned source package is source-full copy of src:grub2
  that only builds bin|dbg|signing-tempate binary packages for platforms
  that get signed and submits monolithic binaries for signing.

  src:grub2-signed is built as before, but its maintainer scripts should
  be compatible across grub2-common from precise and up.

  Stable series will receive grub2 update that drops building bin|dbg
  |signing-template.

  Stable series will receive binary-copy of grub2-unsigned &
  grub2-signed, thus on signed platforms EFI apps and modules will be
  the same across all series.

  [Caveats]

  * In devel series, always upload grub2 with matching
  src:grub2-unsigned and src:grub2-signed. The unsigned package can be
  build with ./debian/rules generate-grub2-unsigned command from
  src:grub2.

  * In stable series, only upload src:grub2 when fixes needed in update-
  grub / grub.cfg / grub-install / etc, but not in the efi modules &
  apps.

  * As needed, binary copy grub2-unsigned & grub2-signed from later
  series to stable series.

  [Test Case]

   * Upgrade to new packages

   * Observe that system boots, one can use grub-mkimage / grub-mkrescue
  without issues.

  [Where problems could occur]

   * There might be regression on the EFI platforms with grub 2.04 that
  have not so far been caught on Focal / Groovy / Hirsute.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1912830] Re: Use non-removable uefi bootloader in cloud-images by default

[Dimitri John Ledkov]

** Changed in: livecd-rootfs (Ubuntu Xenial)
   Status: Fix Committed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1912830

Title:
  Use non-removable uefi bootloader in cloud-images by default

Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Won't Fix
Status in livecd-rootfs source package in Bionic:
  Fix Committed
Status in livecd-rootfs source package in Focal:
  Fix Committed
Status in livecd-rootfs source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

   * use non --removable uefi installation for cloud-images

   * Currently cloud-images use --removable grub installation, which
  makes the disk images look at lot more like our installer .isos, than
  installed systems.

 This causes many issues:

   * ubuntu efiboot entry is not created by the fallback manager from shim
   * one cannot reorder ubuntu boot entry, and/or boot and apply fwupdate 
updates (if possible)
   * measurements are unstable, and change if one call grub-install and or 
upgrades things
   * often grub & shim upgrades are not applied at all as \EFI\ubuntu does not 
exist on the ESP

   * We should switch to only shipping shim/fallback/mm in \ESP\Boot and
  ship \ESP\ubuntu on the cloud-image ESPs such that we regain stable
  measurements; ubuntu boot entry; and upgrades of grub and shim.

  [Test Case]

   * After UEFI firstboot $ efibootmgr --verbose => should contain
  `ubuntu` entry pointing at ESP\ubuntu\shim*.efi binary, which should
  be added to the bootorder

  [Where problems could occur]

   * Existing systems which were booted from previous style images, will
  not upgrade shim|grub on the ESP, and must call `grub-install` or
  `grub-multi-install` to correct that.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1778848] Re: Support for grub upgrades with bios+uefi bootloader targets

[Dimitri John Ledkov]

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

** Also affects: grub-installer (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: grub2-signed (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: shim-signed (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1778848

Title:
  Support for grub upgrades with bios+uefi bootloader targets

Status in grub-installer package in Ubuntu:
  Fix Released
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in shim-signed package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in grub-installer source package in Xenial:
  New
Status in grub2 source package in Xenial:
  New
Status in grub2-signed source package in Xenial:
  New
Status in shim-signed source package in Xenial:
  New
Status in ubiquity source package in Xenial:
  New
Status in grub-installer source package in Bionic:
  Fix Released
Status in grub2 source package in Bionic:
  Fix Released
Status in grub2-signed source package in Bionic:
  Fix Released
Status in shim-signed source package in Bionic:
  Fix Released
Status in ubiquity source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  There are multiple use cases which require both BIOS and UEFI bootloaders 
installed on a target image and to keep them both updated.
  - cloud images on clouds that support both BIOS and UEFI boot in alternate 
instance types
  - PC installs that should remain bootable in the face of firmware upgrades or 
reconfigurations

  This currently doesn't work because 'grub-install' selects its install
  target based on which of grub-pc or grub-efi-amd64 is installed.

  In cosmic we have introduced a --auto-nvram grub-install option that
  automatically determines if we're running with NVRAM access or not and
  if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI
  bootloader setups to work. Same changes are required to be backported
  to bionic for our cloud images.

  [Test Case]

  Basic grub2 grub-install test:
   * Boot up a bionic system in UEFI mode.
   * Upgrade grub2-common to the version in -proposed.
   * Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it 
succeeds.
   * Prepare a system with an UEFI installed system that can be booted into in 
legacy BIOS mode.
   * Boot up the UEFI-installed bionic system in legacy BIOS mode.
   * Upgrade grub2-common to the version in -proposed.
   * Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it 
succeeds (actually not doing anything).

  Install test for UEFI (repeat for both server-live, server and desktop):
   * Download the latest bionic -proposed-enabled image.
   * Make sure the image includes the -proposed version of grub2, grub2-signed, 
shim-signed and grub-installer (and/or ubiquity).
   * Install the system normally on an EFI system.
   * Reboot and make sure the system is bootable.

  Install test for legacy BIOS (repeat for both server-live, server and 
desktop):
   * Download the latest bionic -proposed-enabled image.
   * Make sure the image includes the -proposed version of grub2, grub2-signed, 
shim-signed and grub-installer (and/or ubiquity).
   * Install the system normally on a BIOS system.
   * Reboot and make sure the system is bootable.

  TODO: Add cloud image testing.

  [Regression Potential]

  The backport introduces a change in the dependency chain for grub
  which, in some cases, can lead to systems loosing their ability to
  boot. Basically the symptoms to look for is the inability of booting
  the installed system on EFI or BIOS. A lot of testing and dogfooding
  will be required to make sure no installation-case has been broken by
  this.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1780897] Re: Installation failure on UEFI systems using older images with automatic download of updates enabled

[Dimitri John Ledkov]

** Also affects: grub2-signed (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1780897

Title:
  Installation failure on UEFI systems using older images with automatic
  download of updates enabled

Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2-signed source package in Xenial:
  New
Status in grub2-signed source package in Bionic:
  Fix Released
Status in grub2-signed source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

  Recent grub2-signed dependency chain changes required some changes to
  be made to the installer parts to make sure the end system is
  bootable. However, older isos (like, release images for bionic) do not
  have these installer changes, so users using those with automatic
  download of updates enabled on UEFI systems will end up with a broken
  system.

  [Test Case]

  Checking if the bug has been fixed:

   * Download an older iso (for bionic, let it be the 18.04 release image)
   * Prepare an UEFI-based VM
   * Install Ubuntu with automatic download of updates enabled
   * Reboot and make sure the system is bootable

  Checking if no regressions have been introduced for the installer:

   * Download the latest daily server iso
   * Prepare an UEFI-based VM
   * Install Ubuntu
   * Reboot and make sure the system is bootable

  [Regression Potential]

  There should be no real regression potential here as we are basically
  adding dependencies that should otherwise be installed when using a
  newer image. All potential regressions would be made visible during
  the installation tests from the test case.

  [Original Description]

  Regression caused by
  https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1778848

  Steps to reproduce

  1) Install ubuntu-18.04-desktop-amd64.iso in a VM using QEMU and OVMF
  2) Reboot the VM
  3) See GRUB shell instead of GDM

  The system can be rescued by running

  configfile (hd0,gpt2)/boot/grub/grub.cfg

  at the GRUB shell

  Installing grub-efi-amd64 in the rescued system then makes it
  bootable.

  Previously grub-efi-amd64-signed depended on grub-efi-amd64, and the
  system was bootable immediately after installation.

  Additionally, the removal of this dependency has resulted in a very
  sparse /etc/default/grub after installation.

  I've attached a simple script for installation with QEMU and OVMF.

  I suspect that installs are broken on actual hardware with SecureBoot
  disabled, but I'm not able to test that right now.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1910557] Re: Buildd images do not launch on macOS under multipass due to missing unpacked kernels and initrd

[Dimitri John Ledkov]

** Also affects: livecd-rootfs (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: livecd-rootfs (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: livecd-rootfs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: livecd-rootfs (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: livecd-rootfs (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Changed in: livecd-rootfs (Ubuntu Hirsute)
   Status: New => Fix Released

** Changed in: livecd-rootfs (Ubuntu Groovy)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1910557

Title:
  Buildd images do not launch on macOS under multipass due to missing
  unpacked kernels and initrd

Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  New
Status in livecd-rootfs source package in Bionic:
  New
Status in livecd-rootfs source package in Focal:
  New
Status in livecd-rootfs source package in Groovy:
  In Progress
Status in livecd-rootfs source package in Hirsute:
  Fix Released

Bug description:
  livecd-rootfs v2.700 in hirsute introduced a fix to produce unpacked
  artifacts for use by multipass on macOS hosts. These hosts require
  direct access to a kernel and initrd to boot the buildd images.

  See: https://git.launchpad.net/livecd-
  rootfs/commit/?id=065c82314464fa78337d5122e1d4826a7d6edbb0

  This change needs to be backported to all suites.

  [Impact]

   * Without this change, users are unable to use the buildd images with
  multipass on macOS hosts. Snapcraft utilizes multipass to build snaps,
  so this blocks macOS users from building snaps.

  As a workaround, the CPC team is manually extracting these artifacts
  and publishing them to cloud-images.ubuntu.com. This is not ideal for
  the long-term, and could result in breakage in the event that the CPC
  team forgets to manually publish these artifacts.

  [Test Case]

   * After this change lands, a user should be able to build images with
  the ubuntu-base project and buildd subproject, and the resulting build
  should produce extracted kernel and initrd artifacts.

  [Where problems could occur]

   * These changes are minor, but a mistake could result in broken buildd image 
hooks (where the build fails) or broken buildd image artifacts (where the 
images don't work as expected).
  * Since all buildd images are manually tested by the launchpad team, 
multipass team, and snapcraft team before they enter production, the risk of 
introducing breakage for end users is low.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1865032] Re: [UBUNTU] zipl/libc: Fix potential buffer overflow in printf

[Dimitri John Ledkov]

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1865032

Title:
  [UBUNTU] zipl/libc: Fix potential buffer overflow in printf

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools source package in Xenial:
  Fix Released
Status in s390-tools source package in Bionic:
  Fix Released
Status in s390-tools source package in Eoan:
  Won't Fix
Status in s390-tools source package in Focal:
  Fix Released

Bug description:
  [Impact] 
   * Crash of the zipl boot loader during boot.
   * due to printf buffer overflow in zipl/libc implementation

  [Test Case]
   * Use printf to print a string with >81 characters
 (exact number depends  on the stack layout/compiler used).

  [Where problems could occur]
   * regressions in zipl could break the booting on IBM Z, in certain scenarios
   * the package is only available on s390x and thus could only affect IBM Z 
machines

  [Other Info]
   * Patches provided by IBM
   * In addition to the 4 commit IDs from the original description, I needed to 
include part of another upstream commit, to add the "memmove()" function. This 
was taken from: 
https://github.com/ibm-s390-tools/s390-tools/commit/e764f460c457ab2a6000acb5f2eb7169866ce192

  === Original Description ===
  Description:   zipl/libc: Fix potential buffer overflow in printf
  Symptom:   Crash of the zipl boot loader during boot.
  Problem:   The zipl boot loaders have their own minimalistic libc
     implementation. In it printf and sprintf use vsprintf for 
string
     formatting. Per definition vsprintf assumes that the buffer it
     writes to is large enough to contain the formatted string and
     performs no size checks. This is problematic for the boot
     loaders because the buffer they use are often allocated on the
     stack. Thus even small changes to the string format can
     potentially cause buffer overflows on the stack.

  Solution:  Implement vsnprintf and make use of it.

  Reproduction:  Use printf to print a string with >81 characters (exact number
     depends on the stack layout/compiler used).

  Upstream commit(s) for s390-tools:
  6fe9e6c55c69c14971dca1009f5060418aae
  8874b908254c47c8a6fd7a1aca2c7371c11035c4
  f7430027b41d5ad6220e962a179c2a5213330a44
  36fed0e6c6590631c4ce1707c8fe3c3397bcce4d

  Problem was introduced with version 1.24. Therefore these patches need
  to be applied to all distros in service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1865032/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1856682] Re: [UBUNTU 20.04] GCC Miscompilation in vectorized code

[Dimitri John Ledkov]

** Changed in: gcc-8 (Ubuntu)
   Status: New => Fix Released

** Changed in: gcc-8 (Ubuntu Focal)
   Status: New => Fix Released

** Changed in: gcc-8 (Ubuntu Bionic)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1856682

Title:
  [UBUNTU 20.04] GCC Miscompilation in vectorized code

Status in gcc:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Triaged
Status in gcc-5 package in Ubuntu:
  Invalid
Status in gcc-6 package in Ubuntu:
  Invalid
Status in gcc-7 package in Ubuntu:
  New
Status in gcc-8 package in Ubuntu:
  Fix Released
Status in gcc-9 package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  New
Status in gcc-6 source package in Xenial:
  Invalid
Status in gcc-7 source package in Xenial:
  Invalid
Status in gcc-8 source package in Xenial:
  Invalid
Status in gcc-9 source package in Xenial:
  Invalid
Status in gcc-5 source package in Bionic:
  New
Status in gcc-6 source package in Bionic:
  New
Status in gcc-7 source package in Bionic:
  New
Status in gcc-8 source package in Bionic:
  Fix Released
Status in gcc-9 source package in Bionic:
  Invalid
Status in gcc-5 source package in Disco:
  Invalid
Status in gcc-6 source package in Disco:
  Invalid
Status in gcc-7 source package in Disco:
  Invalid
Status in gcc-8 source package in Disco:
  Invalid
Status in gcc-9 source package in Disco:
  Invalid
Status in gcc-5 source package in Eoan:
  Invalid
Status in gcc-6 source package in Eoan:
  Invalid
Status in gcc-7 source package in Eoan:
  Invalid
Status in gcc-8 source package in Eoan:
  Invalid
Status in gcc-9 source package in Eoan:
  Invalid
Status in gcc-5 source package in Focal:
  Invalid
Status in gcc-6 source package in Focal:
  Invalid
Status in gcc-7 source package in Focal:
  New
Status in gcc-8 source package in Focal:
  Fix Released
Status in gcc-9 source package in Focal:
  Fix Released

Bug description:
  Miscompilation in autovectorized code.
   
  ---Steps to Reproduce---
   See GCC BZ: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

  The following testcase abort when being compiled with -O3 -march=z13
  on IBM Z:

  struct a {
int b;
char c;
  };
  struct a d = {1, 16};
  struct a *e = 

  int f = 0;

  int main() {
struct a g = {0, 0 };
f = 0;

for (; f <= 1; f++) {
  g = d;
  *e = g;
}

if (d.c != 16)
  __builtin_abort();
  }

  The movv1qi pattern emits halfword load instructions instead of character
  loads.

  All GCC versions since GCC 5 are affected.
  Patches for GCC 8, 9, and 10 have been committed to the gcc.gnu.org branches.
   
  Userspace tool common name: gcc  
  The userspace tool has the following bit modes: 64 
  Userspace rpm: various Ubuntu gcc packages

  
  Package need to updated within LP

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1895160] Re: Backport finalrd 6 to xenial and up

[Dimitri John Ledkov]

** Changed in: finalrd (Ubuntu Xenial)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1895160

Title:
  Backport finalrd 6 to xenial and up

Status in finalrd package in Ubuntu:
  Fix Released
Status in finalrd source package in Xenial:
  Fix Released
Status in finalrd source package in Bionic:
  Fix Released
Status in finalrd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * finalrd is a useful tool, that improves ability to cleanly shut
  down systems. It is now desired to backport it all the way back to
  xenial. On classic systems it will not be installed by default, but
  available for users to opt-in into having it. On Ubuntu Core systems
  it will be installed by default, and used instead of snap-shutdown. As
  finalrd does everything that snap-shutdown already did, and much more.

   * finalrd is only tweaked slightly in version 6 to be compatible with
  any systemd from xenial to groovy.

  [Test Case]

  Classic
   * Install finalrd
   * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
   * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.
   * Reboot
   * Observe that finalrd unit is started
   ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd 
hook that does `echo $@` with a sleep
   * Shutdown, capture console-log observe that finalrd was executed

  [xenial extra testcase]

   * finalrd binary package should have Task: ubuntu-core, such that
  when building core snap, it is installed by livebuild.

  Core
   * Create custom core, core18 with finalrd preinstalled
   * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core
   * Observe that finalrd unit is started on boot
   * Shutdown, capture console-log observe that finarld was executed.
   * Boot again
   * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
   * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.

  [Regression Potential]

   * Packaging & tmpfiles were changed to be compatible with older
  systemd versions. There are no changes to api/abi of the systemd
  units, or .finalrd hooks. The package is not installed by default on
  xenial/bionic, hence the number and type of machines affected is
  small. If regressions are identified, reverting to previous version of
  the package is safe course of action, as there are no
  upgrade/downgrade incompatibilities between old & new versions of
  finalrd.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1895160] Re: Backport finalrd 6 to xenial and up

[Dimitri John Ledkov]

finalrd is now seeded into system-image in xenial. But because it is a
brand new package in -updates pocket only, it doesn't gain Task: ubuntu-
core, as that is only done for packages that exist in release pocket.

Thus adding Task:ubuntu-core by hand.

** Description changed:

  [Impact]
  
-  * finalrd is a useful tool, that improves ability to cleanly shut down
+  * finalrd is a useful tool, that improves ability to cleanly shut down
  systems. It is now desired to backport it all the way back to xenial. On
  classic systems it will not be installed by default, but available for
  users to opt-in into having it. On Ubuntu Core systems it will be
  installed by default, and used instead of snap-shutdown. As finalrd does
  everything that snap-shutdown already did, and much more.
  
-  * finalrd is only tweaked slightly in version 6 to be compatible with
+  * finalrd is only tweaked slightly in version 6 to be compatible with
  any systemd from xenial to groovy.
  
  [Test Case]
  
  Classic
-  * Install finalrd
-  * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
-  * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.
-  * Reboot
-  * Observe that finalrd unit is started
-  ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd 
hook that does `echo $@` with a sleep
-  * Shutdown, capture console-log observe that finalrd was executed
+  * Install finalrd
+  * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
+  * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.
+  * Reboot
+  * Observe that finalrd unit is started
+  ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd 
hook that does `echo $@` with a sleep
+  * Shutdown, capture console-log observe that finalrd was executed
+ 
+ [xenial extra testcase]
+ 
+  * finalrd binary package should have Task: ubuntu-core, such that when
+ building core snap, it is installed by livebuild.
  
  Core
-  * Create custom core, core18 with finalrd preinstalled
-  * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core
-  * Observe that finalrd unit is started on boot
-  * Shutdown, capture console-log observe that finarld was executed.
-  * Boot again
-  * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
-  * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.
+  * Create custom core, core18 with finalrd preinstalled
+  * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core
+  * Observe that finalrd unit is started on boot
+  * Shutdown, capture console-log observe that finarld was executed.
+  * Boot again
+  * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
+  * check that /run/initramfs is created and populated with 
/run/initramfs/shutdown, binaries and libraries.
  
  [Regression Potential]
  
-  * Packaging & tmpfiles were changed to be compatible with older systemd
+  * Packaging & tmpfiles were changed to be compatible with older systemd
  versions. There are no changes to api/abi of the systemd units, or
  .finalrd hooks. The package is not installed by default on
  xenial/bionic, hence the number and type of machines affected is small.
  If regressions are identified, reverting to previous version of the
  package is safe course of action, as there are no upgrade/downgrade
  incompatibilities between old & new versions of finalrd.

** Changed in: finalrd (Ubuntu Xenial)
   Status: Fix Released => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1895160

Title:
  Backport finalrd 6 to xenial and up

Status in finalrd package in Ubuntu:
  Fix Released
Status in finalrd source package in Xenial:
  Triaged
Status in finalrd source package in Bionic:
  Fix Released
Status in finalrd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * finalrd is a useful tool, that improves ability to cleanly shut
  down systems. It is now desired to backport it all the way back to
  xenial. On classic systems it will not be installed by default, but
  available for users to opt-in into having it. On Ubuntu Core systems
  it will be installed by default, and used instead of snap-shutdown. As
  finalrd does everything that snap-shutdown already did, and much more.

   * finalrd is only tweaked slightly in version 6 to be compatible with
  any systemd from xenial to groovy.

  [Test Case]

  Classic
   * Install finalrd
   * execute `sudo finalrd` and observe that no stderr is printed, and command 
exits successfully
   * check that /run/initramfs is created and populated 

[Group.of.nepali.translators] [Bug 1895294] Re: Fix Raccoon vulnerability (CVE-2020-1968)

[Dimitri John Ledkov]

It is true that said vulnerability is not patched in xenial; but also it
is low; and no public patches for it exist.

Please upgrade to bionic or focal? which are unaffected / fixes
released?

** Information type changed from Public to Public Security

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

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

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

** Changed in: openssl (Ubuntu Xenial)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1895294

Title:
  Fix Raccoon vulnerability (CVE-2020-1968)

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  Xenial's current OpenSSL (1.0.2g-1ubuntu4.16) seems to not have been
  patched yet against the Raccoon Attack (CVE-2020-1968):

  - https://www.openssl.org/news/secadv/20200909.txt
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1968
  - https://raccoon-attack.com/

  Ubuntu's CVE tracker still lists this as NEEDED for Xenial:

  - https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-1968.html
  - https://people.canonical.com/~ubuntu-security/cve/pkg/openssl.html

  Other supported Ubuntu releases use versions of OpenSSL that are not
  affected.

  Indeed:

    $ apt-cache policy openssl
    openssl:
  Installed: 1.0.2g-1ubuntu4.16

    $ apt-get changelog openssl | grep CVE-2020-1968 || echo "Not patched"
    Not patched

  What is the status?

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1690484] Re: pcre2: CVE-2017-7186 and CVE-2016-3191

[Dimitri John Ledkov]

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

** Changed in: pcre2 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1690484

Title:
  pcre2: CVE-2017-7186 and CVE-2016-3191

Status in pcre2 package in Ubuntu:
  Fix Released
Status in pcre2 source package in Xenial:
  New

Bug description:
  CVE-2017-7186
  -
  CVE-2017-7186 is the one known CVE fixed in Debian stretch that still affects 
Ubuntu 16.04 LTS and 16.10. It was fixed in 17.04 already.

  
  CVE-2016-3191
  -
  CVE-2016-3191 is the one known CVE fixed in Debian stretch that still affects 
Ubuntu 16.04 LTS. It was fixed in 16.10 and newer already.

  
  "The compile_branch function in pcre_compile.c in PCRE 8.x before 8.39 and 
pcre2_compile.c in PCRE2 before 10.22 mishandles patterns containing an 
(*ACCEPT) substring in conjunction with nested parentheses, which allows remote 
attackers to execute arbitrary code or cause a denial of service (stack-based 
buffer overflow) via a crafted regular expression, as demonstrated by a 
JavaScript RegExp object encountered by Konqueror, aka ZDI-CAN-3542."

  https://security-tracker.debian.org/tracker/CVE-2016-3191

  https://bugzilla.redhat.com/show_bug.cgi?id=1311503
  Fedora patch:
  
http://pkgs.fedoraproject.org/cgit/rpms/pcre2.git/tree/pcre2-10.21-Fix-workspace-overflow-for-deep-nested-parentheses-w.patch?id=fc9ba26

  https://vcs.pcre.org/pcre2?view=revision=489

  Testing Done
  
  None

  Packaging Info
  --
  The Debian maintainer uses dgit for the pcre packages.

  You can run 'dgit clone pcre2' to get the packaging along with the extra 
metadata that actually describes the changes that were done to the source 
package. I did this and pushed it to
  https://git.launchpad.net/~jbicha/ubuntu/+source/pcre2

  But the Debian source package itself does not have a patch system
  which makes it much more difficult for us to see what changes were
  made and why. I think for maintainability with how Ubuntu packaging
  generally works, it makes sense here to switch to 3.0 (quilt).

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1862938] Re: Enable late loading of microcode by default

[Dimitri John Ledkov]

** Changed in: intel-microcode (Ubuntu)
   Status: Fix Released => Won't Fix

** Changed in: intel-microcode (Ubuntu Xenial)
   Status: New => Won't Fix

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

** Changed in: intel-microcode (Ubuntu Eoan)
   Status: Fix Committed => Won't Fix

** Changed in: intel-microcode (Ubuntu Focal)
   Status: Fix Released => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862938

Title:
  Enable late loading of microcode by default

Status in intel-microcode package in Ubuntu:
  Won't Fix
Status in intel-microcode source package in Xenial:
  Won't Fix
Status in intel-microcode source package in Bionic:
  Won't Fix
Status in intel-microcode source package in Eoan:
  Won't Fix
Status in intel-microcode source package in Focal:
  Won't Fix

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

   * Normally intel microcode is applied "early" for an uncompressed
  prepended initramfs archive. However, on systems booting without an
  initrd, or a missbuilt one, microcode might not get applied. In that
  case, we need to attempt loading microcode late which may give users
  security protection against CPU vulnerabilities which they might
  otherwise be lacking. In an ideal world, everyone would apply their
  bios/OEM updates with microcode updates in a timely fashion and then
  we wouldn't need to update CPU microcode from userspace at all.

  [Test Case]

   * Install updated package
   * Reobot
   * Observe early application of microcode

  $ journalctl -b | grep microcode
  Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 
0xd6, date = 2019-10-03

   * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct 
generation of early microcode updates
   * Rebuild initrd with update-initramfs -u
   * Reboot
   * Observe in dmesg that late loading of microcode is performed

  $ journalctl -b | grep microcode
  Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6
  Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2.
  Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 
2019-10-03
  Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after 
loading microcode, but might not take effect.
  Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode 
revision: 0xd6

  (Note the lack of "early" in above messages)

  [Regression Potential]

   * Application of microcode is a risky operation, especially if the
  cores are busy. Hence we prefer bios updates & early microcode
  updates, and those will remain the place. The late loading of
  microcode is really here for the cases were the previous two update
  strategies have failed. For example, from time to time, certain
  microcode updates are pulled or get blacklisted from late loading.

  [Other Info]
   
   * The majority of our users on bare-metal machines boot correctly with early 
microcode updates.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation

[Dimitri John Ledkov]

Do we need this in the core snap too, or just core18 images?

I.e. are all appliance images core18+snapd based?

** Changed in: subiquity (Ubuntu Bionic)
   Status: Confirmed => In Progress

** Changed in: subiquity
   Status: In Progress => Fix Released

** No longer affects: subiquity (Ubuntu Bionic)

** No longer affects: subiquity (Ubuntu Xenial)

** No longer affects: subiquity (Ubuntu)

** Also affects: subiquity/core18
   Importance: Undecided
   Status: New

** Also affects: subiquity/core16
   Importance: Undecided
   Status: New

** Also affects: subiquity/core20
   Importance: Undecided
   Status: New

** Changed in: subiquity/core20
   Status: New => Fix Committed

** Changed in: subiquity/core18
   Status: New => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1881588

Title:
  pre-seeding lxd on Core appliances breaks console-conf user creation

Status in snapd:
  Invalid
Status in subiquity:
  Fix Released
Status in subiquity core16 series:
  New
Status in subiquity core18 series:
  In Progress
Status in subiquity core20 series:
  Fix Committed

Bug description:
  when seeding appliance images with lxd, user creation gets impossible.

  console-conf skips the user creation, system-user assertions do not
  work either because there is already a user exisiting in the image.

  the tty screen shows instructions to log in with "lxd@"
  ...

  since the lxd user is a special case hack in Ubuntu Core images, "snap
  create-user ..." should probably learn to ignore its existence ...

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation

[Dimitri John Ledkov]

** Changed in: snapd
   Status: Invalid => New

** Changed in: subiquity
   Status: New => Incomplete

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1881588

Title:
  pre-seeding lxd on Core appliances breaks console-conf user creation

Status in snapd:
  New
Status in subiquity:
  Incomplete
Status in subiquity package in Ubuntu:
  Invalid
Status in subiquity source package in Xenial:
  New
Status in subiquity source package in Bionic:
  New

Bug description:
  when seeding appliance images with lxd, user creation gets impossible.

  console-conf skips the user creation, system-user assertions do not
  work either because there is already a user exisiting in the image.

  the tty screen shows instructions to log in with "lxd@"
  ...

  since the lxd user is a special case hack in Ubuntu Core images, "snap
  create-user ..." should probably learn to ignore its existence ...

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation

[Dimitri John Ledkov]

** Also affects: subiquity
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1881588

Title:
  pre-seeding lxd on Core appliances breaks console-conf user creation

Status in snapd:
  Invalid
Status in subiquity:
  New
Status in subiquity package in Ubuntu:
  New
Status in subiquity source package in Xenial:
  New
Status in subiquity source package in Bionic:
  New

Bug description:
  when seeding appliance images with lxd, user creation gets impossible.

  console-conf skips the user creation, system-user assertions do not
  work either because there is already a user exisiting in the image.

  the tty screen shows instructions to log in with "lxd@"
  ...

  since the lxd user is a special case hack in Ubuntu Core images, "snap
  create-user ..." should probably learn to ignore its existence ...

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1555904] Re: opal-prd not installed by default on ppc64el systems

[Dimitri John Ledkov]

** Also affects: subiquity
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1555904

Title:
  opal-prd not installed by default on ppc64el systems

Status in subiquity:
  New
Status in The Ubuntu-power-systems project:
  Fix Released
Status in debian-installer package in Ubuntu:
  Fix Released
Status in hw-detect package in Ubuntu:
  Fix Released
Status in debian-installer source package in Xenial:
  Fix Released
Status in hw-detect source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * opal-prd should be installed on OpenPOWER systems

  [Test Case]

   * install power system

   * check that /sys/firmware/devicetree/base/ibm,opal/diagnostics
  exists

   * if above is true, check that opal-prd package is installed

  [Regression Potential]

   * Additional package installation is performed, thus the install
  process may take longer, and additional disk space will be used.
  However the new code path is non-fatal, and all errors are ignored,
  thus all installation should still proceed past this point. For
  systems without relevant diagnostics exposed, this code path is a no-
  op.

  [Other Info]
   
   * Original bug report

  Just tried an install with current 16.04 network media, using standard
  server package selections, and it looks like opal-prd isn't installed
  by default:

   [jk@fstn ~]$ dpkg -l opal-prd
   dpkg-query: no packages found matching opal-prd

  This is required for RAS-type functions on OpenPOWER machines; and has
  a similar role to something like acpid, on x86.

  I'm not sure whether filing this against the skiboot package is best,
  or whether this should be moved to something installer-related. Happy
  to shift if necessary.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base

[Dimitri John Ledkov]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1876055

Title:
  SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Confirmed
Status in libseccomp source package in Bionic:
  Confirmed
Status in libseccomp source package in Eoan:
  Confirmed
Status in libseccomp source package in Focal:
  Confirmed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of *this* SRU, we are only doing a micro-version upgrade from
  2.4.1 to 2.4.3 so this carries even less change of regressions.

  Any possible regressions may include applications now seeing correct
  system call resolution whereas previously 

[Group.of.nepali.translators] [Bug 1881278] [NEW] Ship 2018 Archive key in xenial's ubuntu-keyring

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * Xenial systems will not be able to debootstrap Groovy archives when
it finally switches to be signed by single 2018 key. To have support for
xenial to operate against Groovy+ archives it needs access to 2018
archive key. Ship it.

[Test Case]

 * Start xenial chroot or lxd container.
 * Observe that 4 keys are trusted - the original 2004 archive & cdimage, 2012 
archive & cdimage

# apt-key list --fingerprint
/etc/apt/trusted.gpg

pub   1024D/437D05B5 2004-09-12
  Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid  Ubuntu Archive Automatic Signing Key 
sub   2048g/79164387 2004-09-12

pub   4096R/C0B21F32 2012-05-11
  Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid  Ubuntu Archive Automatic Signing Key (2012) 


pub   4096R/EFE21092 2012-05-11
  Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid  Ubuntu CD Image Automatic Signing Key (2012) 


pub   1024D/FBB75451 2004-12-30
  Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid  Ubuntu CD Image Automatic Signing Key 

  * Install the new ubuntu-keyring package
  * Observe that 5 keys are now trusted, including the 2018 archive key

# apt-key list --fingerprint
/etc/apt/trusted.gpg

pub   1024D/437D05B5 2004-09-12
  Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid  Ubuntu Archive Automatic Signing Key 
sub   2048g/79164387 2004-09-12

pub   4096R/C0B21F32 2012-05-11
  Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid  Ubuntu Archive Automatic Signing Key (2012) 


pub   4096R/EFE21092 2012-05-11
  Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid  Ubuntu CD Image Automatic Signing Key (2012) 


pub   1024D/FBB75451 2004-12-30
  Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid  Ubuntu CD Image Automatic Signing Key 

pub   4096R/991BC93C 2018-09-17
  Key fingerprint = F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
uid  Ubuntu Archive Automatic Signing Key (2018) 


  * Dist upgrade to bionic
  * Observe that only 3 keys are trusted the 2012 cdimage + 2018 key, 
and that none of them are in /etc/apt/trusted.gpg but are key snippets in 
/etc/apt/trusted.gpg.d/

# apt-key list
/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg
--
pub   rsa4096 2012-05-11 [SC]
  790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid   [ unknown] Ubuntu Archive Automatic Signing Key (2012) 


/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
--
pub   rsa4096 2012-05-11 [SC]
  8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid   [ unknown] Ubuntu CD Image Automatic Signing Key (2012) 


/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
--
pub   rsa4096 2018-09-17 [SC]
  F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
uid   [ unknown] Ubuntu Archive Automatic Signing Key (2018) 



[Regression Potential] 

 * Adding additional new trust key can trigger support request (aka why
are you adding this key on xenial). The reason to add this key on
xenial, is for xenial to allow securely debootstrap and operate on
Groovy+ repositories which are about to drop 2012 key signatures.

[Other Info]
 
 * Bionic switched from shipping keys in /etc/apt/trusted.gpg keyring, to 
individual snippets. Thus xenial's upload that adds the future key to 
/etc/apt/trusted.gpg should also remove it, during upgrade to bionic. To ensure 
that the systems upgraded from xenial to bionic, look the same as those that 
are fresh bionic installations.

** Affects: ubuntu-keyring (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: ubuntu-keyring (Ubuntu Xenial)
 Importance: Undecided
 Status: Triaged

** Also affects: ubuntu-keyring (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: ubuntu-keyring (Ubuntu)
   Status: New => Invalid

** Changed in: ubuntu-keyring (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1881278

Title:
  Ship 2018 Archive key in xenial's ubuntu-keyring

Status in ubuntu-keyring package in Ubuntu:
  Invalid
Status in ubuntu-keyring source package in Xenial:
  Triaged

Bug description:
  [Impact]

   * Xenial systems will not be able to debootstrap Groovy archives when
  it finally switches to be signed by single 2018 key. To have support
  for xenial to operate against Groovy+ archives it 

[Group.of.nepali.translators] [Bug 1878969] [NEW] time-epoch never changes in SRUs

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * Systems without hwclock come up with a fixed time epoch which is not updated 
in SRUs
 * Ideally booting with a newer built of systemd should move time epoch to be 
at least when systemd was last built. For example to the value of 
SOURCE_DATE_EPOCH.

[Test Case]

 * Boot without network NTP or hwclock
 * Observe that the epoch is the same as the time when NEWS entry in the 
systemd source code was last touched.
 * Boot newer update of systemd, observe that the time epoch is at least 2020

[Regression Potential]

 * Bad epoch, may result in unable to perform TLS connections, validated
GPG signatures, and snapd assertions. Changing epoch to be more recent
is desired. Some machines may rely on the fact that "bionic" without
hwclock always comes up in year 2018. But in practice that is incorrect
thing to do.

[Other Info]
 
 * By default

option('time-epoch', type : 'integer', value : '-1',
   description : 'time epoch for time clients')

in systemd is set to the modification time of the NEW entry
time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int()

If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value to
be compliant with the https://reproducible-builds.org/docs/timestamps/
specification.

** Affects: ubuntu-core-initramfs
 Importance: Undecided
 Status: New

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

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

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

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

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

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

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

** Also affects: ubuntu-core-initramfs
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1878969

Title:
  time-epoch never changes in SRUs

Status in ubuntu-core-initramfs:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New

Bug description:
  [Impact]

   * Systems without hwclock come up with a fixed time epoch which is not 
updated in SRUs
   * Ideally booting with a newer built of systemd should move time epoch to be 
at least when systemd was last built. For example to the value of 
SOURCE_DATE_EPOCH.

  [Test Case]

   * Boot without network NTP or hwclock
   * Observe that the epoch is the same as the time when NEWS entry in the 
systemd source code was last touched.
   * Boot newer update of systemd, observe that the time epoch is at least 2020

  [Regression Potential]

   * Bad epoch, may result in unable to perform TLS connections,
  validated GPG signatures, and snapd assertions. Changing epoch to be
  more recent is desired. Some machines may rely on the fact that
  "bionic" without hwclock always comes up in year 2018. But in practice
  that is incorrect thing to do.

  [Other Info]
   
   * By default

  option('time-epoch', type : 'integer', value : '-1',
 description : 'time epoch for time clients')

  in systemd is set to the modification time of the NEW entry
  time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int()

  If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value
  to be compliant with the https://reproducible-
  builds.org/docs/timestamps/ specification.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1875092] [NEW] support v5.4 syscalls

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * update libssecomp syscalls, for example current seccomp on xenial and
up, cannot correctly filter calls for focal armhf chroots on v5.4
kernels, due to new syscalls usage.

[Test Case]

 * Boot v5.4 kernel
 * Use seccomp to try to resolve new syscall numbers

 * Rebuild snapd snap against bileto ppa with this change
 * Test that this rebuild snapd snap, can correctly launch confined python 
armhf interpreter on arm64 v5.4 kernel (i.e. uc20 raspi arm64 beta image)

[Regression Potential]

 * The issue only impacts when one is running on a newer / hwe kernel,
and tries to seccomp filter newer binaries that use new syscalls. No
changes are made to any existing syscalls or apis.

[Other Info]
 
 * Bileto PPA with this change is being prepared with this change.

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

** Affects: libseccomp (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: libseccomp (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: libseccomp (Ubuntu Eoan)
 Importance: Undecided
 Status: New

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

** Also affects: libseccomp (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1875092

Title:
  support v5.4 syscalls

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  New
Status in libseccomp source package in Bionic:
  New
Status in libseccomp source package in Eoan:
  New

Bug description:
  [Impact]

   * update libssecomp syscalls, for example current seccomp on xenial
  and up, cannot correctly filter calls for focal armhf chroots on v5.4
  kernels, due to new syscalls usage.

  [Test Case]

   * Boot v5.4 kernel
   * Use seccomp to try to resolve new syscall numbers

   * Rebuild snapd snap against bileto ppa with this change
   * Test that this rebuild snapd snap, can correctly launch confined python 
armhf interpreter on arm64 v5.4 kernel (i.e. uc20 raspi arm64 beta image)

  [Regression Potential]

   * The issue only impacts when one is running on a newer / hwe kernel,
  and tries to seccomp filter newer binaries that use new syscalls. No
  changes are made to any existing syscalls or apis.

  [Other Info]
   
   * Bileto PPA with this change is being prepared with this change.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1862938] Re: Enable late loading of microcode by default

[Dimitri John Ledkov]

I'm trying to fix the case when users/manufacturers failed to
provide/install uefi capsule update on the motherboard, failed to first-
boot with up to date microcode, and thus remain unsecured, whilst one
can install microcode. In bare-metal cloud context, late loading of
microcode can be done as the line of last defence to apply microcode.

** Changed in: intel-microcode (Ubuntu Focal)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862938

Title:
  Enable late loading of microcode by default

Status in intel-microcode package in Ubuntu:
  Fix Released
Status in intel-microcode source package in Xenial:
  New
Status in intel-microcode source package in Bionic:
  New
Status in intel-microcode source package in Eoan:
  Fix Committed
Status in intel-microcode source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

   * Normally intel microcode is applied "early" for an uncompressed
  prepended initramfs archive. However, on systems booting without an
  initrd, or a missbuilt one, microcode might not get applied. In that
  case, we need to attempt loading microcode late which may give users
  security protection against CPU vulnerabilities which they might
  otherwise be lacking. In an ideal world, everyone would apply their
  bios/OEM updates with microcode updates in a timely fashion and then
  we wouldn't need to update CPU microcode from userspace at all.

  [Test Case]

   * Install updated package
   * Reobot
   * Observe early application of microcode

  $ journalctl -b | grep microcode
  Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 
0xd6, date = 2019-10-03

   * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct 
generation of early microcode updates
   * Rebuild initrd with update-initramfs -u
   * Reboot
   * Observe in dmesg that late loading of microcode is performed

  $ journalctl -b | grep microcode
  Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6
  Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2.
  Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 
2019-10-03
  Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after 
loading microcode, but might not take effect.
  Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode 
revision: 0xd6

  (Note the lack of "early" in above messages)

  [Regression Potential]

   * Application of microcode is a risky operation, especially if the
  cores are busy. Hence we prefer bios updates & early microcode
  updates, and those will remain the place. The late loading of
  microcode is really here for the cases were the previous two update
  strategies have failed. For example, from time to time, certain
  microcode updates are pulled or get blacklisted from late loading.

  [Other Info]
   
   * The majority of our users on bare-metal machines boot correctly with early 
microcode updates.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1862938] [NEW] Enable late loading of microcode by default

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * An explanation of the effects of the bug on users and

 * justification for backporting the fix to the stable release.

 * In addition, it is helpful, but not required, to include an
   explanation of how the upload fixes this bug.

 * Normally intel microcode is applied "early" for an uncompressed
prepended initramfs archive. However, on systems booting without an
initrd, or a missbuilt one, microcode might not get applied. In that
case, we need to attempt loading microcode late which may give users
security protection against CPU vulnerabilities which they might
otherwise be lacking. In an ideal world, everyone would apply their
bios/OEM updates with microcode updates in a timely fashion and then we
wouldn't need to update CPU microcode from userspace at all.

[Test Case]

 * Install updated package
 * Reobot
 * Observe early application of microcode

$ journalctl -b | grep microcode
Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 
0xd6, date = 2019-10-03

 * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct 
generation of early microcode updates
 * Rebuild initrd with update-initramfs -u
 * Reboot
 * Observe in dmesg that late loading of microcode is performed

$ journalctl -b | grep microcode
Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, no 
microcode
Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, no 
microcode
Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6
Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2.
Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 
2019-10-03
Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after loading 
microcode, but might not take effect.
Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode revision: 
0xd6

(Note the lack of "early" in above messages)

[Regression Potential]

 * Application of microcode is a risky operation, especially if the
cores are busy. Hence we prefer bios updates & early microcode updates,
and those will remain the place. The late loading of microcode is really
here for the cases were the previous two update strategies have failed.
For example, from time to time, certain microcode updates are pulled or
get blacklisted from late loading.

[Other Info]
 
 * The majority of our users on bare-metal machines boot correctly with early 
microcode updates.

** Affects: intel-microcode (Ubuntu)
 Importance: Undecided
 Status: Fix Committed

** Affects: intel-microcode (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: intel-microcode (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: intel-microcode (Ubuntu Eoan)
 Importance: Undecided
 Status: New

** Affects: intel-microcode (Ubuntu Focal)
 Importance: Undecided
 Status: Fix Committed

** Also affects: intel-microcode (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: intel-microcode (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: intel-microcode (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: intel-microcode (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Changed in: intel-microcode (Ubuntu Focal)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862938

Title:
  Enable late loading of microcode by default

Status in intel-microcode package in Ubuntu:
  Fix Committed
Status in intel-microcode source package in Xenial:
  New
Status in intel-microcode source package in Bionic:
  New
Status in intel-microcode source package in Eoan:
  New
Status in intel-microcode source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

   * Normally intel microcode is applied "early" for an uncompressed
  prepended initramfs archive. However, on systems booting without an
  initrd, or a missbuilt one, microcode might not get applied. In that
  case, we need to attempt loading microcode late which may give users
  security protection against CPU vulnerabilities which they might
  otherwise be lacking. In an ideal world, everyone would apply their
  bios/OEM updates with microcode updates in a timely fashion and then
  we wouldn't need to update CPU microcode from userspace at all.

  [Test Case]

   * Install updated package
   * Reobot
   * Observe early application of microcode

  $ journalctl -b | grep microcode
  Feb 12 12:02:48 ottawa 

[Group.of.nepali.translators] [Bug 1856682] Re: GCC Miscompilation in vectorized code

[Dimitri John Ledkov]

gcc-5 affected in xenial and bionic.

gcc-6 affected in bionic only.

gcc-7 and gcc-8 affected, and currently have inflight SRU updates to
v7.5 and v8.3 in bionic, thus are not going to be updated at the moment
anywhere I don't think.

gcc-9 is fixed in focal.


** Also affects: gcc-6 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: gcc-6 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: gcc-7 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: gcc-8 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: gcc-9 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-6 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-7 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-8 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-9 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-6 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-7 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-8 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-9 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gcc-6 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gcc-7 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gcc-8 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gcc-9 (Ubuntu Focal)
   Importance: High
 Assignee: Canonical Foundations Team (canonical-foundations)
   Status: Fix Released

** Also affects: gcc-5 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: gcc-6 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: gcc-7 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: gcc-8 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: gcc-9 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Changed in: gcc-6 (Ubuntu Eoan)
   Status: New => Invalid

** Changed in: gcc-6 (Ubuntu Focal)
   Status: New => Invalid

** Changed in: gcc-6 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: gcc-5 (Ubuntu Disco)
   Status: New => Invalid

** Changed in: gcc-5 (Ubuntu Eoan)
   Status: New => Invalid

** Changed in: gcc-5 (Ubuntu Focal)
   Status: New => Invalid

** Changed in: gcc-7 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: gcc-8 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: gcc-9 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: gcc-9 (Ubuntu Bionic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1856682

Title:
  GCC Miscompilation in vectorized code

Status in gcc:
  Unknown
Status in Ubuntu on IBM z Systems:
  Triaged
Status in gcc-5 package in Ubuntu:
  Invalid
Status in gcc-6 package in Ubuntu:
  Invalid
Status in gcc-7 package in Ubuntu:
  New
Status in gcc-8 package in Ubuntu:
  New
Status in gcc-9 package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  New
Status in gcc-6 source package in Xenial:
  Invalid
Status in gcc-7 source package in Xenial:
  Invalid
Status in gcc-8 source package in Xenial:
  Invalid
Status in gcc-9 source package in Xenial:
  Invalid
Status in gcc-5 source package in Bionic:
  New
Status in gcc-6 source package in Bionic:
  New
Status in gcc-7 source package in Bionic:
  New
Status in gcc-8 source package in Bionic:
  New
Status in gcc-9 source package in Bionic:
  Invalid
Status in gcc-5 source package in Disco:
  Invalid
Status in gcc-6 source package in Disco:
  New
Status in gcc-7 source package in Disco:
  New
Status in gcc-8 source package in Disco:
  New
Status in gcc-9 source package in Disco:
  New
Status in gcc-5 source package in Eoan:
  Invalid
Status in gcc-6 source package in Eoan:
  Invalid
Status in gcc-7 source package in Eoan:
  New
Status in gcc-8 source package in Eoan:
  New
Status in gcc-9 source package in Eoan:
  New
Status in gcc-5 source package in Focal:
  Invalid
Status in gcc-6 source package in Focal:
  Invalid
Status in gcc-7 source package in Focal:
  New
Status in gcc-8 source package in Focal:
  New
Status in gcc-9 source package in 

[Group.of.nepali.translators] [Bug 1859013] [NEW] openssh tests use "not valid yet" certificate from 2020, which is now valid

[Dimitri John Ledkov]

Public bug reported:

openssh tests use "not valid yet" certificate from 2020, which is now
valid

https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381

this causes autopkgtest regression suite fail in 2020

 grep 20200101 -r .
./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid"   failure 
"-h -V20200101:20300101"
./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid"   failure 
"-n ${USER} -V20200101:20300101"
./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid"   failure 
"-h -V20200101:20300101"
./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid"   failure 
"-n ${USER} -V20200101:20300101"
./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid"   failure 
"-h -V20200101:20300101"
./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid"   failure 
"-n ${USER} -V20200101:20300101"
./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid"   failure 
"-h -V20200101:20300101"
./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid"   failure 
"-n ${USER} -V20200101:20300101"

fixed in debian https://tracker.debian.org/news/1092767/accepted-
openssh-181p1-4-source-into-unstable/

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

** Affects: openssh (Ubuntu Precise)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Disco)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Eoan)
 Importance: Undecided
 Status: New

** Affects: openssh (Ubuntu Focal)
 Importance: Undecided
 Status: New


** Tags: update-excuse

** Tags added: update-excuse

** Description changed:

  openssh tests use "not valid yet" certificate from 2020, which is now
  valid
  
  
https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381
  
  this causes autopkgtest regression suite fail in 2020
+ 
+  grep 20200101 -r .
+ ./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
+ ./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
+ ./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
+ ./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
+ ./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
+ ./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
+ ./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
+ ./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"

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

** Also affects: openssh (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: openssh (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: openssh (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: openssh (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

** Also affects: openssh (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Description changed:

  openssh tests use "not valid yet" certificate from 2020, which is now
  valid
  
  
https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381
  
  this causes autopkgtest regression suite fail in 2020
  
-  grep 20200101 -r .
+  grep 20200101 -r .
  ./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
  ./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
  ./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
  ./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
  ./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
  ./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
  ./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure 
"-h -V20200101:20300101"
  ./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure 
"-n ${USER} -V20200101:20300101"
+ 
+ fixed in debian 

[Group.of.nepali.translators] [Bug 1851499] Re: lz4 SIGSEGV in LZ4_decompress_generic

[Dimitri John Ledkov]

** Changed in: lz4 (Ubuntu Focal)
   Status: Triaged => Fix Released

** Also affects: lz4 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1851499

Title:
  lz4 SIGSEGV in LZ4_decompress_generic

Status in lz4 package in Ubuntu:
  Fix Released
Status in lz4 source package in Xenial:
  New
Status in lz4 source package in Bionic:
  New
Status in lz4 source package in Disco:
  New
Status in lz4 source package in Eoan:
  Fix Released
Status in lz4 source package in Focal:
  Fix Released

Bug description:
  Affected packages:

  https://packages.ubuntu.com/xenial/liblz4-1
  https://packages.ubuntu.com/bionic/liblz4-1
  https://packages.ubuntu.com/cosmic/liblz4-1
  https://packages.ubuntu.com/disco/liblz4-1

  Non-Affected packages:
  https://packages.ubuntu.com/eoan/liblz4-1

  Description:

  I got SIGSEGV with lz4, when trying to read a corrupted stream
  No null ptr check of source in LZ4_decompress_generic

  Description of problem:

  No null ptr check of source in  LZ4_decompress_generic

  (gdb) bt
  #0  0x774ede70 in LZ4_decompress_generic (source=0x0,
  dest=0x63128800 "press.foo.bar.6057 1
  349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1
  349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1
  349830001\ncompress.foo.bar.6062 1 349830001"..., inputSize=1253,
  outputSize=65536, endOnInput=1, partialDecoding=0, targetOutputSize=0,
  dict=0,
  lowPrefix=0x63128800 "press.foo.bar.6057 1
  349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1
  349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1
  349830001\ncompress.foo.bar.6062 1 349830001"..., dictStart=0x0,
  dictSize=0) at lz4.c:1157
  #1  LZ4_decompress_safe (source=0x0,
  dest=0x63128800 "press.foo.bar.6057 1
  349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1
  349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1
  349830001\ncompress.foo.bar.6062 1 349830001"..., compressedSize=1253,
  maxDecompressedSize=65536) at lz4.c:1290
  #2  0x77560631 in LZ4F_decompress_safe (source=0x0,
  dest=0x63128800 "press.foo.bar.6057 1
  349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1
  349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1
  349830001\ncompress.foo.bar.6062 1 349830001"..., compressedSize=1253,
  maxDecompressedSize=65536,
  dictStart=0x63128800 "press.foo.bar.6057 1
  349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1
  349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1
  349830001\ncompress.foo.bar.6062 1 349830001"..., dictSize=0) at
  lz4frame.c:957
  #3  0x7755595b in LZ4F_decompress
  (decompressionContext=0x6110ff40, dstBuffer=0x7fffe8bdd82c,
  dstSizePtr=0x70cf96e0, srcBuffer=0x62d14400,
  srcSizePtr=0x70cf96c0,
  decompressOptionsPtr=0x70cf8120) at lz4frame.c:1294

  
  Version-Release number of selected component (if applicable):

  In lz4 from HEAD bug was fixed
  https://github.com/lz4/lz4/blob/master/lib/lz4.c#L1668

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

[Dimitri John Ledkov]

** Changed in: snapd (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771858

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Won't Fix
Status in systemd source package in Xenial:
  Fix Released
Status in snapd source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in snapd source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  # make snapd-env-generator executable if it is not
  $ sudo chmod +x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator

  # reboot, then test the effect of the fix
  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

[Dimitri John Ledkov]

Installed snapd from proposed, rebooted, and /snap/bin is now in path of
systemd-run unit

Nov 18 18:25:26 well-monkey env[298]:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

# dpkg-query -W snapd
snapd   2.42.1+18.04

Prior to reboot it was not in PATH of a systemd-run unit.

** Changed in: snapd (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771858

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Fix Released
Status in snapd source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released
Status in snapd source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  # make snapd-env-generator executable if it is not
  $ sudo chmod +x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator

  # reboot, then test the effect of the fix
  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1840652] Re: upgrade amd64-microcode with new microcode for 17h family

[Dimitri John Ledkov]

** Summary changed:

- upgrade amd64-microcode with new microcode & better initramfs hook
+ upgrade amd64-microcode with new microcode for 17h family

** Description changed:

- upgrade amd64-microcode with new microcode & better initramfs hook
- 
  [Impact]
  
-  * New microcode is available
- 
-  * It is hard to generate initrd, with all microcodes included because the 
initramfs hook ignores 
-preset defaults. Adjust hook to take preset defaults into account.
+  * New microcode is available
  
  [Test Case]
  
-  * There is no testcase for new microcode, as it is unknown what has
+  * There is no testcase for new microcode, as it is unknown what has
  changed.
- 
-  * Install new package, and check that initrd with default settings (i.e. 
modules=most) has amd64 
-microcode included. And that with modules=dep|list it only does so, if one 
is on AMD cpu.
- 
-  * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting 
initrd should contian 
-both amd64 and intel microcode, despite using modules=list, due to the 
conf.d default settings
-it overrides.
  
  [Regression Potential]
  
-  * New microcode is published without a changelog, thus it is unknown what it 
fixes or regresses, 
-yet it is recommeded to upgrade it. The 17h family microcode has been 
updated, almost doubling in size.
- 
-  * The hook default behaviour is not changed, only integration with
- custom conf.d's is improved.
- 
-  * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
+  * New microcode is published without a changelog, thus it is unknown what it 
fixes or regresses,
+    yet it is recommeded to upgrade it. The 17h family microcode has been 
updated, almost doubling in size.
  
  [Other Info]
-  
-  * 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca
+ 
+  * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
+ firmware.git/commit/amd-
+ ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca

** Changed in: amd64-microcode (Ubuntu Disco)
   Status: New => Fix Released

** Changed in: amd64-microcode (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: amd64-microcode (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840652

Title:
  upgrade amd64-microcode with new microcode for 17h family

Status in amd64-microcode package in Ubuntu:
  Fix Released
Status in amd64-microcode source package in Xenial:
  Triaged
Status in amd64-microcode source package in Bionic:
  In Progress
Status in amd64-microcode source package in Disco:
  Fix Released

Bug description:
  [Impact]

   * New microcode is available

  [Test Case]

   * There is no testcase for new microcode, as it is unknown what has
  changed.

  [Regression Potential]

   * New microcode is published without a changelog, thus it is unknown what it 
fixes or regresses,
     yet it is recommeded to upgrade it. The 17h family microcode has been 
updated, almost doubling in size.

  [Other Info]

   * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
  firmware.git/commit/amd-
  ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1840670] [NEW] amd64-microcode better initramfs hook

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * It is hard to generate initrd, with all microcodes included because the 
initramfs hook ignores
   preset defaults. Adjust hook to take preset defaults into account.

[Test Case]

 * Install new package, and check that initrd with default settings (i.e. 
modules=most) has amd64
   microcode included. And that with modules=dep|list it only does so, if one 
is on AMD cpu.

 * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting 
initrd should contian
   both amd64 and intel microcode, despite using modules=list, due to the 
conf.d default settings
   it overrides.

[Regression Potential]

 * The hook default behaviour is not changed, only integration with
custom conf.d's is improved.

** Affects: amd64-microcode (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: amd64-microcode (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: amd64-microcode (Ubuntu Bionic)
 Importance: Undecided
 Status: In Progress

** Affects: amd64-microcode (Ubuntu Disco)
 Importance: Undecided
 Status: In Progress

** Also affects: amd64-microcode (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: amd64-microcode (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: amd64-microcode (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: amd64-microcode (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840670

Title:
  amd64-microcode better initramfs hook

Status in amd64-microcode package in Ubuntu:
  Fix Released
Status in amd64-microcode source package in Xenial:
  New
Status in amd64-microcode source package in Bionic:
  In Progress
Status in amd64-microcode source package in Disco:
  In Progress

Bug description:
  [Impact]

   * It is hard to generate initrd, with all microcodes included because the 
initramfs hook ignores
 preset defaults. Adjust hook to take preset defaults into account.

  [Test Case]

   * Install new package, and check that initrd with default settings (i.e. 
modules=most) has amd64
 microcode included. And that with modules=dep|list it only does so, if one 
is on AMD cpu.

   * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting 
initrd should contian
 both amd64 and intel microcode, despite using modules=list, due to the 
conf.d default settings
 it overrides.

  [Regression Potential]

   * The hook default behaviour is not changed, only integration with
  custom conf.d's is improved.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1840652] [NEW] upgrade amd64-microcode with new microcode & better initramfs hook

[Dimitri John Ledkov]

Public bug reported:

upgrade amd64-microcode with new microcode & better initramfs hook

[Impact]

 * New microcode is available

 * It is hard to generate initrd, with all microcodes included because the 
initramfs hook ignores 
   preset defaults. Adjust hook to take preset defaults into account.

[Test Case]

 * There is no testcase for new microcode, as it is unknown what has
changed.

 * Install new package, and check that initrd with default settings (i.e. 
modules=most) has amd64 
   microcode included. And that with modules=dep|list it only does so, if one 
is on AMD cpu.

 * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting 
initrd should contian 
   both amd64 and intel microcode, despite using modules=list, due to the 
conf.d default settings
   it overrides.

[Regression Potential]

 * New microcode is published without a changelog, thus it is unknown what it 
fixes or regresses, 
   yet it is recommeded to upgrade it. The 17h family microcode has been 
updated, almost doubling in size.

 * The hook default behaviour is not changed, only integration with
custom conf.d's is improved.

 * This both shows the SRU team that the risks have been considered,
   and provides guidance to testers in regression-testing the SRU.

[Other Info]
 
 * 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca

** Affects: amd64-microcode (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: amd64-microcode (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: amd64-microcode (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: amd64-microcode (Ubuntu Disco)
 Importance: Undecided
 Status: New

** Also affects: amd64-microcode (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: amd64-microcode (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: amd64-microcode (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: amd64-microcode (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840652

Title:
  upgrade amd64-microcode with new microcode & better initramfs hook

Status in amd64-microcode package in Ubuntu:
  Fix Released
Status in amd64-microcode source package in Xenial:
  New
Status in amd64-microcode source package in Bionic:
  New
Status in amd64-microcode source package in Disco:
  New

Bug description:
  upgrade amd64-microcode with new microcode & better initramfs hook

  [Impact]

   * New microcode is available

   * It is hard to generate initrd, with all microcodes included because the 
initramfs hook ignores 
 preset defaults. Adjust hook to take preset defaults into account.

  [Test Case]

   * There is no testcase for new microcode, as it is unknown what has
  changed.

   * Install new package, and check that initrd with default settings (i.e. 
modules=most) has amd64 
 microcode included. And that with modules=dep|list it only does so, if one 
is on AMD cpu.

   * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting 
initrd should contian 
 both amd64 and intel microcode, despite using modules=list, due to the 
conf.d default settings
 it overrides.

  [Regression Potential]

   * New microcode is published without a changelog, thus it is unknown what it 
fixes or regresses, 
 yet it is recommeded to upgrade it. The 17h family microcode has been 
updated, almost doubling in size.

   * The hook default behaviour is not changed, only integration with
  custom conf.d's is improved.

   * This both shows the SRU team that the risks have been considered,
 and provides guidance to testers in regression-testing the SRU.

  [Other Info]
   
   * 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1839500] [NEW] Add a future-proof provides btrfs-progs name for ease of usability

[Dimitri John Ledkov]

Public bug reported:

[Impact]

 * Upstream, other distributions, and Ubuntu Bionic+ use btrfs-progs
name for this package

 * For historical reasons, this package was called btrfs-tools

 * To ease usability and automation it would be nice if the future-proof
name would be available on older releases as a Provides:

[Test Case]

 * $ apt install btrfs-progs

   Should install btrfs-tools package on xenial, and have btrfs

[Regression Potential]

 * We are rebuilding the btrfs package, and adding extra metadata
without any other code changes. So the only risks there are, are from
doing a no-change rebuild of the package.

[Other Info]
 
 * Examples of automation that install btrfs:
   - ansible playbooks
   - lxd
   - curtin
   - cloud-init
   - juju
   - interactive sysadmins

** Affects: btrfs-tools (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: btrfs-tools (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: btrfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: btrfs-tools (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1839500

Title:
  Add a future-proof provides btrfs-progs name for ease of usability

Status in btrfs-tools package in Ubuntu:
  Fix Released
Status in btrfs-tools source package in Xenial:
  New

Bug description:
  [Impact]

   * Upstream, other distributions, and Ubuntu Bionic+ use btrfs-progs
  name for this package

   * For historical reasons, this package was called btrfs-tools

   * To ease usability and automation it would be nice if the future-
  proof name would be available on older releases as a Provides:

  [Test Case]

   * $ apt install btrfs-progs

 Should install btrfs-tools package on xenial, and have btrfs

  [Regression Potential]

   * We are rebuilding the btrfs package, and adding extra metadata
  without any other code changes. So the only risks there are, are from
  doing a no-change rebuild of the package.

  [Other Info]
   
   * Examples of automation that install btrfs:
 - ansible playbooks
 - lxd
 - curtin
 - cloud-init
 - juju
 - interactive sysadmins

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1831443] [NEW] [hint] [sru] autopkgtest regressed as an API key is now required

[Dimitri John Ledkov]

Public bug reported:

libgeo-coder-googlev3-perl uses a remote Google Maps service, which has
started to require unique API keys.

As there is no API key for the autopkgtests, they have started to fail.

Autopkgtests for 0.16-1 will thus now always fail and should be hinted
as expected failure.

In 0.17-1 networked tests have been disabled during autopkgtests, and
I'm proposing to SRU such a fix to bionic too.

[Impact]

 * Unbreak autopkgtests by disabling networked tests due to remote
service requiring authentication API tokens.

[Test Case]

 * autopkgtests should pass

[Regression Potential]

 * as networked tests are no longer performed, further regressions in
utilising the remote service will not be caught.

[Hints]

 bionic: force-badtest libgeo-coder-googlev3-perl/0.16-1
 xenial: force-badtest libgeo-coder-googlev3-perl/0.14-1

** Affects: libgeo-coder-googlev3-perl (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: libgeo-coder-googlev3-perl (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: libgeo-coder-googlev3-perl (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Also affects: libgeo-coder-googlev3-perl (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: libgeo-coder-googlev3-perl (Ubuntu)
   Status: New => Fix Released

** Also affects: libgeo-coder-googlev3-perl (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1831443

Title:
  [hint] [sru] autopkgtest regressed as an API key is now required

Status in libgeo-coder-googlev3-perl package in Ubuntu:
  Fix Released
Status in libgeo-coder-googlev3-perl source package in Xenial:
  New
Status in libgeo-coder-googlev3-perl source package in Bionic:
  New

Bug description:
  libgeo-coder-googlev3-perl uses a remote Google Maps service, which
  has started to require unique API keys.

  As there is no API key for the autopkgtests, they have started to
  fail.

  Autopkgtests for 0.16-1 will thus now always fail and should be hinted
  as expected failure.

  In 0.17-1 networked tests have been disabled during autopkgtests, and
  I'm proposing to SRU such a fix to bionic too.

  [Impact]

   * Unbreak autopkgtests by disabling networked tests due to remote
  service requiring authentication API tokens.

  [Test Case]

   * autopkgtests should pass

  [Regression Potential]

   * as networked tests are no longer performed, further regressions in
  utilising the remote service will not be caught.

  [Hints]

   bionic: force-badtest libgeo-coder-googlev3-perl/0.16-1
   xenial: force-badtest libgeo-coder-googlev3-perl/0.14-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libgeo-coder-googlev3-perl/+bug/1831443/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1494851] Re: initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript

[Dimitri John Ledkov]

Doesn't affect post-bionic releases. Marking as fixed.

** Changed in: cryptsetup (Ubuntu)
   Status: Incomplete => Fix Released

** Changed in: cryptsetup (Ubuntu)
 Assignee: TJ (tj) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1494851

Title:
  initramfs cryptroot hook script doesn't install cryptsetup if keyfile
  but no keyscript

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in cryptsetup source package in Xenial:
  New
Status in cryptsetup source package in Bionic:
  New

Bug description:
  When crypttab specifies a key-file for the container of the root file-
  system but there is no keyscript= option no cryptsetup support is
  installed in the initrd.img.

  Currently the cryptroot initramfs hook script knows its a problem and
  will report:

  cryptsetup: WARNING: target LUKS_OS uses a key file, skipped

  This is BAD behaviour that renders the root file-system container
  inaccessible at boot time.

  Regardless of a key-script being available cryptsetup support should
  be installed into the initrd.img to enable the user to take manual
  steps to unlock the container. The hook script has no knowledge about
  pass phrases that might be set in other LUKS slots that are available
  to the user.

  This is the behaviour when a keyscript is specified but doesn't exist.

  The attached patch modifies the behaviour to include cryptsetup in the
  initrd.img and modify the warning to the user.

  cryptsetup: WARNING: target LUKS_OS uses a key file, but no keyscript
  is set. Please ensure there is also a typed pass-phrase set.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1828892] Re: systemctl - alias service reports inactive while aliased is active

[Dimitri John Ledkov]

Only affects xenial at the moment.

** Changed in: systemd (Ubuntu Xenial)
   Status: In Progress => Triaged

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1828892

Title:
  systemctl - alias service reports inactive while aliased is active

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Triaged

Bug description:
  [Impact]

  'systemctl is-active' command reports an alias service as inactive even 
though the aliased service
  is active.
  Currently the 'systemctl is-active' command does not load units to minimise 
its effect on the system (i.e. that a monitoring command does not itself alter 
the state of the system).
  However, this behaviour leads to inconsistencies when services are aliased.

  [Test case]

  - Test case 1 - libvirtd

  alias service : libvirtd
  aliased service : libvirt-bin

  /etc/systemd/system$ ls -la libvirtd.service 
  lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> 
/lib/systemd/system/libvirt-bin.service

  $ systemctl is-active libvirtd
  inactive

  $ systemctl is-active libvirt-bin
  active

  
  - Test case 2 - sshd

  alias service : sshd
  aliased service : ssh

  /ect/systemd/system$ ls -la sshd.service 
  lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> 
/lib/systemd/system/ssh.service

  $ systemctl is-active sshd
  inactive

  $ systemctl is-active ssh
  active

  
  [Regression Potential]

  This fix may result into systemctl reporting inconsistent information
  concerning the status of a service.

  [Other]

  Upstream issue : https://github.com/systemd/systemd/issues/7875
  Upstream fix : https://github.com/systemd/systemd/pull/7997

  Xenial is affected, fix exists on Bionic onward.

  $ lsb_release -rd
  Description:  Ubuntu 16.04.6 LTS
  Release:  16.04

  $ apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu21.21
Candidate: 229-4ubuntu21.21

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1830479] Re: testcases expect first kernel log line, but not always in logs

[Dimitri John Ledkov]

It's a critical but in the Ubuntu platform if the very first kernel log
line is not available in the system logs.

And it is present on all arches, apart from the identified buggy arm64
which is in-flight being fixed (in eoan-proposed & disco-proposed with
other releases to follow).

cmdline-upstart-boot is only present in xenial? and arm64-kvm testing
only started to be done post xenial release. Hence systemd/arm64
autopkgtest status is currently "Always Failed" and doesn't block
anything.

This is not applicable to devel series, nor should be applied in prior
releases, instead kernel should be fixed.

** Changed in: systemd (Ubuntu Eoan)
   Status: New => Won't Fix

** Changed in: systemd (Ubuntu Disco)
   Status: New => Won't Fix

** Changed in: systemd (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830479

Title:
  testcases expect first kernel log line, but not always in logs

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in systemd source package in Bionic:
  New
Status in systemd source package in Cosmic:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Won't Fix
Status in systemd package in Debian:
  Unknown

Bug description:
  [impact]

  boot-and-services and cmdline-upstart-boot expect the first(ish)
  kernel log line to be in the system logs, but that is not guaranteed
  to be in the logs.

  [test case]

  run autopkgtest on arm64 with the current kernel, whose kernel log
  size is too small for journald or rsyslogd to capture the first kernel
  log messages.

  [regression potential]

  low; testcase fix only.

  [other info]

  the specific cause of this currently is too-small kernel log buffer
  size on arm64, which is being fixed in bug 1824864, but increasing
  amounts of boot time logging may cause a failure again, or custom
  kernel configs with small log buffers.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1604737] Re: headless installations are degraded due to failed setvtrgb.service

[Dimitri John Ledkov]

** Changed in: console-setup (Ubuntu Xenial)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1604737

Title:
  headless installations are degraded due to failed setvtrgb.service

Status in console-setup package in Ubuntu:
  Fix Released
Status in console-setup source package in Xenial:
  Won't Fix

Bug description:
  s390x installations are degraded due to failed setvtrgb.service

  on z/vm, suspecting that it should be limited to just kvm on s390x,
  somehow.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1634161] Re: Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time

[Dimitri John Ledkov]

** Changed in: multipath-tools (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1634161

Title:
  Default multipath policy is round-robin, shows considerably worse read
  throughput compared to using service-time

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in multipath-tools package in Ubuntu:
  Fix Released
Status in multipath-tools source package in Xenial:
  Won't Fix

Bug description:
  ---Problem Description---
  Default multipath policy is round-robin, shows considerably worse read 
throughput compared to using service-time
  Contact Information = Barbara Mundle, barbara.mun...@de.ibm.com 
  ---uname output---
  4.4.0-21-generic
  Machine Type = z systems: Type 2964, Model 701 NC9 
  ---Debugger---
  A debugger is not configured
  ---Steps to Reproduce---
   Conducting throughput measurements with both policies shows the difference

  Userspace tool common name: multipath-tools 
  The userspace tool has the following bit modes: 64-bit 
  Userspace rpm: multipath-tools_0.5.0+git1.656f8865-5ubuntu2.2_s390x.deb 
  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Barbara Mundle, barbara.mun...@de.ibm.com:
  -Attach ltrace and strace of userspace application.

  Throughput numbers with FIO for sequential read (in KBPS) with
  multipath policies service.time/round-robin (varying with number of
  jobs from 1 - 64):

service-time   round-robin

  13193030 2917220 
  25248430 5020375
  48453570 6438140
  89708690 6444175
  16  9712100 6448080
  32  9714035 6450905
  64  9718355 6461650

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1634161/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64

[Dimitri John Ledkov]

$ cat /boot/config-5.0.0-16-generic | grep LOG_BUF
CONFIG_LOG_BUF_SHIFT=18
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13

$ uname -a
Linux doerfel 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:54:19 UTC 2019 
aarch64 aarch64 aarch64 GNU/Linux

And journal shows complete kernel boot messages, thus this all now good
on disco.

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

** No longer affects: systemd (Ubuntu Xenial)

** No longer affects: systemd (Ubuntu Bionic)

** No longer affects: systemd (Ubuntu Cosmic)

** No longer affects: systemd (Ubuntu Disco)

** No longer affects: systemd (Ubuntu Eoan)

** No longer affects: systemd (Ubuntu)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1824864

Title:
  CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in linux source package in Cosmic:
  Confirmed
Status in linux source package in Disco:
  Fix Committed
Status in linux source package in Eoan:
  Confirmed

Bug description:
  [Impact]

   * Too small dmsg kernel buf ring size leads to loosing/missing early
  boot kernel messages which happen before journald starts slurping them
  up and storing them on disc. This results in messages similar to this
  one on boot "missed NN kernel messages on boot". This is especially
  pronounced on arm64 as the default setting there is way lower than any
  other 32bit or 64bit architecture we ship. Also amd64 appears to have
  the highest setting of 18 among all architectures we ship. The best
  course of action to bump all 64bit arches to 18, and keep all 32bit
  arches at the current & upstream default of 17.

  [Test Case]

   * $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT

  on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18
  on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17

   * run systemd adt test, the boot-and-services test case should not
  fail journald tests with "missed kernel messages" visible in the error
  logs.

  [Regression Potential]

   * Increasing the size of the log_buf, will increase kernel memory
  usage which cannot be reclaimed. It will now become 256kb on arm64,
  ppc64el, s390x instead of 8kB/128kb/128kb respectively. 32bit arches
  remain unchanged at 128kb.

  [Other Info]
   
   * Original bug report

  CONFIG_LOG_BUF_SHIFT
  policy<{
  'amd64'  : '18',
  'arm64'  : '14',
  'armhf'  : '17',
  'i386'   : '17',
  'ppc64el': '17',
  's390x'  : '17'}>

  Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.

  Potentially bump all 64-bit arches to 18 (or higher!) as was done on
  amd64, meaning set 18 on arm64 s390x ppc64el.

  I have a systemd autopkgtest test that asserts that we see Linux
  kernel command line in the dmesg (journalctl -k -b). And it is
  consistently failing on arm64 scalingstack KVM EFI machines with
  messages of "missing 81 kernel messages".

  config LOG_BUF_SHIFT
  int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
  range 12 25
  default 17
  depends on PRINTK
  help
    Select the minimal kernel log buffer size as a power of 2.
    The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
    parameter, see below. Any higher size also might be forced
    by "log_buf_len" boot parameter.

    Examples:
   17 => 128 KB
   16 => 64 KB
   15 => 32 KB
   14 => 16 KB
   13 =>  8 KB
   12 =>  4 KB

  14 sounds like redictiously low for arm64. given that 17 is default
  across 32-bit arches, and 18 is default on amd64.

  On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': 
'13', 's390x': '13'}>
  I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.

  Please backport this to xenial and up.

  === systemd ===

  systemd, boot-and-services test case can bump the ring buffer before
  running the tests.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1827391] Re: Japanese era Reiwa SRU

[Dimitri John Ledkov]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1827391

Title:
  Japanese era  Reiwa SRU

Status in icu package in Ubuntu:
  Fix Released
Status in icu source package in Precise:
  New
Status in icu source package in Trusty:
  New
Status in icu source package in Xenial:
  New
Status in icu source package in Bionic:
  New
Status in icu source package in Cosmic:
  New
Status in icu source package in Disco:
  New
Status in icu source package in Eoan:
  Fix Released
Status in icu package in Debian:
  Fix Released

Bug description:
  Japanese era  Reiwa SRU

  $ rmadison icu
  4.8.1.1-3ubuntu0.7 | precise-updates
  52.1-3ubuntu0.8| trusty-updates
  55.1-7ubuntu0.4| xenial-updates
  60.2-3ubuntu3  | bionic
  60.2-6ubuntu1  | cosmic
  63.1-6 | disco
  63.1-6 | eoan

  Note reported abi break / crash of chromium at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash

[Dimitri John Ledkov]

** Changed in: bash (Ubuntu Trusty)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1614080

Title:
  PATH contains dot when PATH is unset before running bash

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Precise:
  Fix Released
Status in bash source package in Trusty:
  Won't Fix
Status in bash source package in Xenial:
  Fix Committed
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Released
Status in bash source package in Disco:
  Fix Committed
Status in bash source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * The fallback path built into bash contains '.' which leads to
  unexpected addition of the current working directory. It should not be
  there, just like it isnt' in pre-precise and cosmic+.

  [Test Case]

   * $ env -u PATH /bin/bash -c 'echo $PATH'

  Should not have '.' as any component. Nor should there be any empty
  components, i.e. '::'.

  [Regression Potential]

   * Normally PATH is always set by either init, systemd, or any other
  hypervisor. Thus this only affects executions under bash, when it was
  started without any environment - e.g. booting with 'init=/bin/bash'.

  [Other Info]
   
   * Original bug report.

  On ubuntu 16.04 (but also 14.04), running bash with PATH unset always
  adds '.' to PATH:

  philippe@pv-desktop:~$ echo $PATH
  
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  philippe@pv-desktop:~$ unset PATH
  philippe@pv-desktop:~$ /bin/bash
  philippe@pv-desktop:~$ echo $PATH
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  Even when testing in a virtual machine / docker, and erasing
  /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem
  still happens.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1827391] Re: Japanese era Reiwa SRU

[Dimitri John Ledkov]

** Description changed:

  Japanese era  Reiwa SRU
  
  $ rmadison icu
  4.8.1.1-3ubuntu0.7 | precise-updates
  52.1-3ubuntu0.8| trusty-updates
  55.1-7ubuntu0.4| xenial-updates
  60.2-3ubuntu3  | bionic
  60.2-6ubuntu1  | cosmic
  63.1-6 | disco
  63.1-6 | eoan
+ 
+ Note reported abi break / crash of chromium at https://bugs.debian.org
+ /cgi-bin/bugreport.cgi?bug=927933

** Description changed:

  Japanese era  Reiwa SRU
  
  $ rmadison icu
  4.8.1.1-3ubuntu0.7 | precise-updates
  52.1-3ubuntu0.8| trusty-updates
  55.1-7ubuntu0.4| xenial-updates
  60.2-3ubuntu3  | bionic
  60.2-6ubuntu1  | cosmic
  63.1-6 | disco
  63.1-6 | eoan
  
- Note reported abi break / crash of chromium at https://bugs.debian.org
- /cgi-bin/bugreport.cgi?bug=927933
+ Note reported abi break / crash of chromium at
+ 
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1827391

Title:
  Japanese era  Reiwa SRU

Status in icu package in Ubuntu:
  New
Status in icu source package in Precise:
  New
Status in icu source package in Trusty:
  New
Status in icu source package in Xenial:
  New
Status in icu source package in Bionic:
  New
Status in icu source package in Cosmic:
  New
Status in icu source package in Disco:
  New
Status in icu source package in Eoan:
  New
Status in icu package in Debian:
  Unknown

Bug description:
  Japanese era  Reiwa SRU

  $ rmadison icu
  4.8.1.1-3ubuntu0.7 | precise-updates
  52.1-3ubuntu0.8| trusty-updates
  55.1-7ubuntu0.4| xenial-updates
  60.2-3ubuntu3  | bionic
  60.2-6ubuntu1  | cosmic
  63.1-6 | disco
  63.1-6 | eoan

  Note reported abi break / crash of chromium at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash

[Dimitri John Ledkov]

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

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

** Also affects: bash (Ubuntu Eoan)
   Importance: Medium
   Status: Fix Released

** Also affects: bash (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: bash (Ubuntu Disco)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: bash (Ubuntu Disco)
   Status: New => In Progress

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

** Changed in: bash (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: bash (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: bash (Ubuntu Trusty)
   Status: New => In Progress

** Also affects: bash (Ubuntu Precise)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1614080

Title:
  PATH contains dot when PATH is unset before running bash

Status in bash package in Ubuntu:
  Fix Committed
Status in bash source package in Precise:
  Fix Released
Status in bash source package in Trusty:
  In Progress
Status in bash source package in Xenial:
  In Progress
Status in bash source package in Bionic:
  In Progress
Status in bash source package in Cosmic:
  Fix Released
Status in bash source package in Disco:
  In Progress
Status in bash source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * The fallback path built into bash contains '.' which leads to
  unexpected addition of the current working directory. It should not be
  there, just like it isnt' in pre-precise and cosmic+.

  [Test Case]

   * $ env -u PATH /bin/bash -c 'echo $PATH'

  Should not have '.' as any component. Nor should there be any empty
  components, i.e. '::'.

  [Regression Potential]

   * Normally PATH is always set by either init, systemd, or any other
  hypervisor. Thus this only affects executions under bash, when it was
  started without any environment - e.g. booting with 'init=/bin/bash'.

  [Other Info]
   
   * Original bug report.

  On ubuntu 16.04 (but also 14.04), running bash with PATH unset always
  adds '.' to PATH:

  philippe@pv-desktop:~$ echo $PATH
  
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  philippe@pv-desktop:~$ unset PATH
  philippe@pv-desktop:~$ /bin/bash
  philippe@pv-desktop:~$ echo $PATH
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  Even when testing in a virtual machine / docker, and erasing
  /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem
  still happens.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1825448] Re: gnupg2 autopkgtest 'simple-tests' should be included in x/b/c

[Dimitri John Ledkov]

Adding new autopkgtests in devel series - good.

Adding new autopkgtests in stable series - not good.

Fixing regressions that got introduced during the lifetime of a stable
series - good.

The only times when we introduced new autopkgtests in stable series, is
when we upload fixes for regressions / SRU bugs and attempt at
preventing them from regressing again in the stable series.

This development does not appear to be that. Uploading new smoke-tests
is out of the scope of the SRU policy. What prompted this bug report?

I feel like rejecting the series tasks of this bug report.

** Changed in: gnupg2 (Ubuntu Cosmic)
   Status: In Progress => Won't Fix

** Changed in: gnupg2 (Ubuntu Bionic)
   Status: In Progress => Won't Fix

** Changed in: gnupg2 (Ubuntu Xenial)
   Status: In Progress => Won't Fix

** Changed in: gnupg (Ubuntu Xenial)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1825448

Title:
  gnupg2 autopkgtest 'simple-tests' should be included in x/b/c

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Fix Released
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  Won't Fix
Status in gnupg2 source package in Cosmic:
  Won't Fix

Bug description:
  [impact]

  b/c currently only have gpgv-win32 test, which is limited in what it
  tests and what archs it runs on.  additionally, it always fails (see
  bug 1825186).

  x currently has no tests at all for gnupg or gnupg2.

  [test case]

  run autopkgtests for gnupg2 on b/c.

  [regession potential]

  adding a testcase may result in the testcase incorrectly failing in
  the future.

  [other info]

  this test case is cherry-picked from gnupg2 in disco.

  the test case required slight modification for gnupg v1, as 'Key-Type:
  default' only works with v2.  Note that Xenial is the last release
  that carries gnupg v1; Bionic and later carry only gnupg v2.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1825099] Re: Unable to deploy Xenial on a s390x KVM

[Dimitri John Ledkov]

Hopefully this fixes s390-tools chreipl for xenial.

Cherrypick from s390-tools v1.35 release.

** Patch added: "chreipl-fix-chreipl-node-for-virtio-devices.patch"
   
https://bugs.launchpad.net/ubuntu/xenial/+source/s390-tools/+bug/1825099/+attachment/5259139/+files/chreipl-fix-chreipl-node-for-virtio-devices.patch

** Changed in: s390-tools (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: s390-tools (Ubuntu)
   Status: New => Fix Released

** Description changed:

- When trying to deploy Xenial on a s390x KVM, the deployment will fail.
- (it works for B/C)
+ [Impact]
+ 
+  * chreipl is a tool that can set/change the IPL settings of a guest,
+ meaning what should it boot next upon a reboot call (ie. which device to
+ boot from, or to like dumpkernel, etc). v1.34 has a processing bug,
+ meaning that chreipl does not work with virtio disk drives, as seen in
+ VMs. The fix is to cherrypick a patch which was most likely introduced
+ in teh v1.35 release. Please note the v1.XX series upstream code base is
+ not public, so the patch i'm cherrypicking is a hunk from the diff
+ between xenial and yakkety releases.
+ 
+ [Test Case]
+ 
+  * Use chreipl in a qemu-kvm VM, it should work.
+ 
+ [Regression Potential]
+ 
+  * This changes the codepath, of detecting which drive to use. Other usage by 
user specified id are not affected, and default usage of chreipl in xenial so 
far has been on best effort basis (ie. guarded with || true, in d-i) because 
normally it is trivial to control IPL methods from the underlying hypervisor 
(HMC, z/VM, qemu/libvirt)
+  * However, this patch is needed to enable MAAS KVM pods to be able to deploy 
Xenial guests, as that deployment mechanism depends on working chreipl.
+ 
+ [Other Info]
+  
+  * Original bug report:
+ 
+ 
+ When trying to deploy Xenial on a s390x KVM, the deployment will fail. (it 
works for B/C)
  
  Looks like it will fail with:
  chreipl: Could not find DASD CCW device "virtio0"
  curtin: Installation failed with exception: Unexpected error while running 
command.
  Command: chreipl node /dev/vda
  Exit code: 1
  Reason: -
  Stdout: chreipl: Could not find DASD CCW device "virtio0"
  
  Complete output from the MaaS UI:
  curtin: Installation started. (18.1-59-g0f993084-0ubuntu1~18.04.1)
  third party drivers not installed or necessary.
  Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease
  Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [109 kB]
  Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [109 kB]
  Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB]
  Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/universe s390x Packages 
[7190 kB]
  Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse s390x Packages 
[119 kB]
  Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x Packages 
[672 kB]
  Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe s390x 
Packages [613 kB]
  Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse s390x 
Packages [11.0 kB]
  Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-security/main s390x 
Packages [432 kB]
  Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe s390x 
Packages [340 kB]
  Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse s390x 
Packages [1716 B]
  Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main s390x 
Packages [7280 B]
  Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe s390x 
Packages [6536 B]
  Fetched 9719 kB in 2s (4674 kB/s)
  Reading package lists...
  zfs-dkms set on hold.
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following additional packages will be installed:
    crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-headers-4.4.0-145
    linux-headers-4.4.0-145-generic linux-headers-generic
    linux-image-4.4.0-145-generic linux-image-generic
    linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic
    wireless-regdb
  Suggested packages:
    fdutils linux-doc-4.4.0 | linux-source-4.4.0 linux-tools
  The following NEW packages will be installed:
    crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-generic
    linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic
    linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic
    linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic
    wireless-regdb
  0 upgraded, 14 newly installed, 0 to remove and 8 not upgraded.
  Need to get 74.5 MB of archives.
  After this operation, 375 MB of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
libnl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [49.7 kB]
  Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
libnl-genl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [11.0 kB]
  Get:3 http://ports.ubuntu.com/ubuntu-ports 

[Group.of.nepali.translators] [Bug 1825099] Re: Unable to deploy Xenial on a s390x KVM

[Dimitri John Ledkov]

Adjusting bug tasks

** Also affects: s390-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: s390-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

** Changed in: maas (Ubuntu)
   Status: Won't Fix => Invalid

** Changed in: s390-tools (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1825099

Title:
  Unable to deploy Xenial on a s390x KVM

Status in ubuntu-kernel-tests:
  New
Status in maas package in Ubuntu:
  Invalid
Status in s390-tools package in Ubuntu:
  New
Status in maas source package in Xenial:
  Invalid
Status in s390-tools source package in Xenial:
  Confirmed

Bug description:
  When trying to deploy Xenial on a s390x KVM, the deployment will fail.
  (it works for B/C)

  Looks like it will fail with:
  chreipl: Could not find DASD CCW device "virtio0"
  curtin: Installation failed with exception: Unexpected error while running 
command.
  Command: chreipl node /dev/vda
  Exit code: 1
  Reason: -
  Stdout: chreipl: Could not find DASD CCW device "virtio0"

  Complete output from the MaaS UI:
  curtin: Installation started. (18.1-59-g0f993084-0ubuntu1~18.04.1)
  third party drivers not installed or necessary.
  Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease
  Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [109 kB]
  Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [109 kB]
  Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB]
  Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/universe s390x Packages 
[7190 kB]
  Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse s390x Packages 
[119 kB]
  Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x Packages 
[672 kB]
  Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe s390x 
Packages [613 kB]
  Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse s390x 
Packages [11.0 kB]
  Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-security/main s390x 
Packages [432 kB]
  Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe s390x 
Packages [340 kB]
  Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse s390x 
Packages [1716 B]
  Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main s390x 
Packages [7280 B]
  Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe s390x 
Packages [6536 B]
  Fetched 9719 kB in 2s (4674 kB/s)
  Reading package lists...
  zfs-dkms set on hold.
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following additional packages will be installed:
    crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-headers-4.4.0-145
    linux-headers-4.4.0-145-generic linux-headers-generic
    linux-image-4.4.0-145-generic linux-image-generic
    linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic
    wireless-regdb
  Suggested packages:
    fdutils linux-doc-4.4.0 | linux-source-4.4.0 linux-tools
  The following NEW packages will be installed:
    crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-generic
    linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic
    linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic
    linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic
    wireless-regdb
  0 upgraded, 14 newly installed, 0 to remove and 8 not upgraded.
  Need to get 74.5 MB of archives.
  After this operation, 375 MB of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
libnl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [49.7 kB]
  Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
libnl-genl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [11.0 kB]
  Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
wireless-regdb all 2018.05.09-0ubuntu1~16.04.1 [11.7 kB]
  Get:4 http://ports.ubuntu.com/ubuntu-ports xenial/main s390x iw s390x 3.17-1 
[59.8 kB]
  Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/main s390x crda s390x 
3.13-1 [59.7 kB]
  Get:6 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
linux-firmware all 1.157.21 [49.8 MB]
  Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
linux-modules-4.4.0-145-generic s390x 4.4.0-145.171 [7359 kB]
  Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
linux-image-4.4.0-145-generic s390x 4.4.0-145.171 [3882 kB]
  Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x 
linux-modules-extra-4.4.0-145-generic s390x 4.4.0-145.171 [2689 kB]
  Get:10 

[Group.of.nepali.translators] [Bug 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64

[Dimitri John Ledkov]

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

** Description changed:

  CONFIG_LOG_BUF_SHIFT
  policy<{
  'amd64'  : '18',
  'arm64'  : '14',
  'armhf'  : '17',
  'i386'   : '17',
  'ppc64el': '17',
  's390x'  : '17'}>
  
  Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
  
  Potentially bump all 64-bit arches to 18 (or higher!) as was done on
  amd64, meaning set 18 on arm64 s390x ppc64el.
  
  I have a systemd autopkgtest test that asserts that we see Linux kernel
  command line in the dmesg (journalctl -k -b). And it is consistently
  failing on arm64 scalingstack KVM EFI machines with messages of "missing
  81 kernel messages".
  
  config LOG_BUF_SHIFT
  int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
  range 12 25
  default 17
  depends on PRINTK
  help
    Select the minimal kernel log buffer size as a power of 2.
    The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
    parameter, see below. Any higher size also might be forced
    by "log_buf_len" boot parameter.
  
    Examples:
   17 => 128 KB
   16 => 64 KB
   15 => 32 KB
   14 => 16 KB
   13 =>  8 KB
   12 =>  4 KB
  
  14 sounds like redictiously low for arm64. given that 17 is default
  across 32-bit arches, and 18 is default on amd64.
  
  On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': 
'13', 's390x': '13'}>
  I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
  
+ Please backport this to xenial and up.
  
- Please backport this to xenial and up.
+ 
+ 
+ === systemd ===
+ 
+ systemd, boot-and-services test case can bump the ring buffer before
+ running the tests.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1824864

Title:
  CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in linux source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  New
Status in linux source package in Cosmic:
  Confirmed
Status in systemd source package in Cosmic:
  New
Status in linux source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  New
Status in linux source package in EE-Series:
  Confirmed
Status in systemd source package in EE-Series:
  New

Bug description:
  CONFIG_LOG_BUF_SHIFT
  policy<{
  'amd64'  : '18',
  'arm64'  : '14',
  'armhf'  : '17',
  'i386'   : '17',
  'ppc64el': '17',
  's390x'  : '17'}>

  Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.

  Potentially bump all 64-bit arches to 18 (or higher!) as was done on
  amd64, meaning set 18 on arm64 s390x ppc64el.

  I have a systemd autopkgtest test that asserts that we see Linux
  kernel command line in the dmesg (journalctl -k -b). And it is
  consistently failing on arm64 scalingstack KVM EFI machines with
  messages of "missing 81 kernel messages".

  config LOG_BUF_SHIFT
  int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
  range 12 25
  default 17
  depends on PRINTK
  help
    Select the minimal kernel log buffer size as a power of 2.
    The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
    parameter, see below. Any higher size also might be forced
    by "log_buf_len" boot parameter.

    Examples:
   17 => 128 KB
   16 => 64 KB
   15 => 32 KB
   14 => 16 KB
   13 =>  8 KB
   12 =>  4 KB

  14 sounds like redictiously low for arm64. given that 17 is default
  across 32-bit arches, and 18 is default on amd64.

  On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': 
'13', 's390x': '13'}>
  I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.

  Please backport this to xenial and up.


  
  === systemd ===

  systemd, boot-and-services test case can bump the ring buffer before
  running the tests.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : 

[Group.of.nepali.translators] [Bug 1818814] Re: systemd-tmpfiles-setup.services fails to create /var/run directories

[Dimitri John Ledkov]

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

OpenVZ has been proactive w.r.t. this issue and have issued an update
that includes the required backports a long time ago.

Please see this comment:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847/comments/20

"""
Updated OpenVz6 kernel was released:
https://wiki.openvz.org/Download/kernel/rhel6/042stab134.7

We are very grateful for Ubuntu team for reverting of patches specially
for OpenVz.

For affected hosters: OpenVz6 is great but it is really old,
and similar incidents can happen again and again.
Please think about switch to RHEL7-based OpenVz7.

Thank you,
   Vasily Averin
"""

Which was released in November 2018. All your provider needs to do, is
to apply OpenVZ updates.

>From Ubuntu point of view this is a wontfix, as providing systemd
without using fchownat opens a security vulnerability CVE-2018-6954.

Please upgrde to OpenVZ kernel 042stab134.7 or anything better. I
believe currently the latest kernel is 042stab136.1.

@ddstreet please delete your packages from the PPA, as you are
intentially distributing security vulnerable systemd.

Regards,

Dimitri.

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

** Changed in: systemd (Ubuntu Xenial)
   Status: Invalid => Won't Fix

** Changed in: systemd (Ubuntu)
   Status: New => Won't Fix

** This bug has been marked a duplicate of bug 1804847
   systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1818814

Title:
  systemd-tmpfiles-setup.services fails to create /var/run directories

Status in systemd package in Ubuntu:
  Won't Fix
Status in systemd source package in Xenial:
  Won't Fix

Bug description:
  1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Description:Ubuntu 16.04.6 LTS
   
  Release:16.04 
   

  2) The version of the package you are using, via 'apt-cache policy pkgname' 
or by checking in Software Center
  systemd:  
   
Installed: 229-4ubuntu21.16 
   
Candidate: 229-4ubuntu21.16 
   
Version table:  
   
   *** 229-4ubuntu21.16 500 
   
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages  
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status  
   
   229-4ubuntu4 500 
   
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages   
 

  3) What you expected to happen
  4) What happened instead

  Ubuntu server (running in OpenVZ VPS farm, thus the old kernel
  version) has been up and running happily, until I performed apt-get
  upgrade and rebooted the server. After reboot, I could not establish
  SSH connection to server, port 22 connection was refused.

  I opened a HTML console to my server instance and checked logs. From
  the logs, it was shown, that SSH server could not start, as it did not
  have the /var/run/sshd directory. After scrolling back the
  /var/log/syslog, I noticed that there were lots of other /var/run
  subdirectories, which were not created. Here is cut from
  /var/log/syslog, related to systemd-tmpfiles:

  ---8<---8<---
  Mar  6 12:32:54 vspk systemd-tmpfiles[81]: 
[/usr/lib/tmpfiles.d/00rsyslog.conf:6] Duplicate line for path "/v
  ar/log", ignoring.
   
  Mar  6 12:32:54 vspk systemd[1]: Starting Raise network interfaces... 
   
  Mar  6 12:32:54 vspk systemd-tmpfiles[81]: fchownat() of /run/named failed: 
Invalid argument 
  Mar  6 12:32:54 vspk systemd-tmpfiles[81]: Failed to validate path 
/var/run/fail2ban: Too many levels of symb
  olic links
   
  Mar  6 12:32:54 vspk systemd-tmpfiles[81]: Failed to validate path 
/var/run/screen: Too many levels of 

[Group.of.nepali.translators] [Bug 1816753] Re: do-release-upgrade on WSL failed horribly due to grub and others

[Dimitri John Ledkov]

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

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

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1816753

Title:
  do-release-upgrade on WSL failed horribly due to grub and others

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Cosmic:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Upon reading an Ubuntu page that said it was possible to upgrade my
  Ubuntu-under-Windows 10 install (WSL) from 16.04 LTS just by running
  do-release-upgrade, I excitedly went to my terminal and ran the
  command.

  First it refused to run because system was not fully updated. Fine, I ran:
  sudo apt update
  sudo apt dist-upgrade

  This process completed without any errors. I then ran do-release-
  upgrade again. This time it started okay and got through most of the
  process.

  But then at some point it decided to run grub even though I am running
  Ubuntu under WSL, so presumably grub should not be used. It did
  apparently detect that it wasn't needed, because it asked me if I was
  sure I didn't want to install it on the boot device. I answered yes.
  Then the install proceeded to LXD but soon after came an error related
  to grub.

  After that it went downhill fast with at least 2 other errors.

  Additionally, when the system attempted to roll back the upgrade I got
  an error from a kernel package.

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: friendly-recovery 0.2.38ubuntu1
  ProcVersionSignature: Microsoft 4.4.0-17763.253-Microsoft 4.4.35
  Uname: Linux 4.4.0-17763-Microsoft x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Tue Feb 19 23:50:44 2019
  Dmesg: [0.017808]  Microsoft 4.4.0-17763.253-Microsoft 4.4.35
  ErrorMessage: installed friendly-recovery package post-installation script 
subprocess returned error exit status 1
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.1
   apt  1.6.8
  SourcePackage: grub2
  Title: package friendly-recovery 0.2.38ubuntu1 failed to install/upgrade: 
installed friendly-recovery package post-installation script subprocess 
returned error exit status 1
  UpgradeStatus: Upgraded to bionic on 2019-02-20 (0 days ago)

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1775018] Re: Fix for openssl 1.0.2 backport

[Dimitri John Ledkov]

openssl1.0 is removed from disco.

** Also affects: openssl (Ubuntu Disco)
   Importance: Undecided
 Assignee: Canonical Foundations Team (canonical-foundations)
   Status: Fix Released

** Also affects: openssl1.0 (Ubuntu Disco)
   Importance: Undecided
   Status: Confirmed

** Changed in: openssl1.0 (Ubuntu Disco)
   Status: Confirmed => Won't Fix

** Changed in: openssl1.0 (Ubuntu)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1775018

Title:
  Fix for openssl 1.0.2 backport

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl1.0 package in Ubuntu:
  Won't Fix
Status in openssl source package in Xenial:
  Invalid
Status in openssl1.0 source package in Xenial:
  Invalid
Status in openssl source package in Bionic:
  Fix Released
Status in openssl1.0 source package in Bionic:
  Confirmed
Status in openssl source package in Cosmic:
  Fix Released
Status in openssl1.0 source package in Cosmic:
  Confirmed
Status in openssl source package in Disco:
  Fix Released
Status in openssl1.0 source package in Disco:
  Won't Fix

Bug description:
  [Impact]

   * Fix hw accelerated performance impact on s390x with non-default
  openssl1.0.

  [Test Case]

   * Test that performance of hw accelerated crypto is improved / i.e.
  ssl speed test

   * Test that openssh still works, just in case.

  [Regression Potential]

   * This only changes accelerated codepath on s390x, for specific algos when 
CPACF is enabled on the system cpu, which is usually on.
   * Same fix is already in use by 1.1.0 default openssl package, and well 
excercised on bionic and up.

  [Other Info]
   
   * original bug report.

  
  This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and 
upstream code are not affected ).

  Original LP ticket :
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775018/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1775018] Re: Fix for openssl 1.0.2 backport

[Dimitri John Ledkov]

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750
is [18.04 FEAT] Add support for CPACF enhancements to openssl
also known as ltc-163655 and is only present in bionic.

In xenial:
we have src:openssl, 1.0.2 which does not have CPACF backport, and therefore 
the attached patch does not apply at all, and also there are no issues to fix 
there either. Unless, you mean openssl-ibmca is also affected in xenial? in 
that case do you have a patch for openssl-ibmca?

In bionic:
we have src:openssl, 1.1.0 which is not affected as you say, as the default 
openssl version.
we also have src:openssl1.0 which does have CPACF backport and the attached 
patch applies to. Please note, that openssl1.0 is only used by a small amount 
of packages in bionic. We are preparing the update for that package.


** Description changed:

- This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and
- upstream code are not affected ).
+ [Impact]
  
- Original LP ticket : 
+  * Fix hw accelerated performance impact on s390x with non-default
+ openssl1.0.
+ 
+ [Test Case]
+ 
+  * Test that performance of hw accelerated crypto is improved / i.e. ssl
+ speed test
+ 
+  * Test that openssh still works, just in case.
+ 
+ [Regression Potential]
+ 
+  * This only changes accelerated codepath on s390x, for specific algos when 
CPACF is enabled on the system cpu, which is usually on.
+  * Same fix is already in use by 1.1.0 default openssl package, and well 
excercised on bionic and up.
+ 
+ [Other Info]
+  
+  * original bug report.
+ 
+ 
+ This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and 
upstream code are not affected ).
+ 
+ Original LP ticket :
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750

** Also affects: openssl1.0 (Ubuntu)
   Importance: Undecided
   Status: New

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

** Also affects: openssl1.0 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: openssl1.0 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Changed in: openssl (Ubuntu)
   Status: Incomplete => Fix Released

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

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

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

** Also affects: openssl1.0 (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

** Changed in: openssl1.0 (Ubuntu)
   Status: New => Confirmed

** Changed in: openssl1.0 (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: openssl1.0 (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: openssl1.0 (Ubuntu Cosmic)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1775018

Title:
  Fix for openssl 1.0.2 backport

Status in Ubuntu on IBM z Systems:
  Triaged
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl1.0 package in Ubuntu:
  Confirmed
Status in openssl source package in Xenial:
  Invalid
Status in openssl1.0 source package in Xenial:
  Invalid
Status in openssl source package in Bionic:
  Fix Released
Status in openssl1.0 source package in Bionic:
  Confirmed
Status in openssl source package in Cosmic:
  Fix Released
Status in openssl1.0 source package in Cosmic:
  Confirmed

Bug description:
  [Impact]

   * Fix hw accelerated performance impact on s390x with non-default
  openssl1.0.

  [Test Case]

   * Test that performance of hw accelerated crypto is improved / i.e.
  ssl speed test

   * Test that openssh still works, just in case.

  [Regression Potential]

   * This only changes accelerated codepath on s390x, for specific algos when 
CPACF is enabled on the system cpu, which is usually on.
   * Same fix is already in use by 1.1.0 default openssl package, and well 
excercised on bionic and up.

  [Other Info]
   
   * original bug report.

  
  This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and 
upstream code are not affected ).

  Original LP ticket :
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775018/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

[Dimitri John Ledkov]

No, it would have been impossible for any desktop image (even pending)
to contain the new systemd on the 31st of January.

The first image that contains the new systemd is from 20190204 or later.

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1755863

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  netbooting the bionic live CD[1] over NFS goes straight to maintenance mode :

  [1] http://cdimage.ubuntu.com/daily-live/current/

  # casper.log
  Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 
pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' 

[Group.of.nepali.translators] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled

[Dimitri John Ledkov]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1804487

Title:
  systemd-resolved has issues when the answer is over 512 bytes with
  EDNS disabled

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  [Impact]

  TCP stub is cutting down the payload to 512 bytes when EDNS is
  disabled. This makes non-EDNS clients (nslookup) receive a "shortened"
  answer even when UDP returns a truncated reply for a new TCP query.
  For instance,

  - If the client supports EDNS:

  $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  30

  - If the client does not support EDNS:

  $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  29

  In the second case, no-EDNS, TCP should provide the complete answer,
  but it's capped at UDP's size.

  [Test Case]

  Query systemd-resolved with a domain name that resolves to multiple
  (lots.. 30+) A records. A client with EDNS support (dig) will receive
  all of them, a client without support (nslookup or dig +noedns) will
  have a truncated list. Using the example above:

  EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 
| wc -l

  [Regression potential]

  Minimal. This change only affects TCP requests, and the new size is
  already used in the code for other requests.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10816
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce

  [Original Description]

  Querying a domain name that has >512 bytes in records (e.g. 30+ A
  records), the number of results depends on the DNS client used:

  - If the client supports EDNS:

  $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  30

  - If the client does not support EDNS:

  $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  29

  Normally a client that doesn't support EDNS would receive a truncated
  reply from the initial UDP connection (limited by the spec to 512
  bytes) and a second query would be established via TCP to receive the
  complete results. In this case, the number of results is the same
  regardless of the protocol used (29).

  Upstream bug: https://github.com/systemd/systemd/issues/10816

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled

[Dimitri John Ledkov]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1804487

Title:
  systemd-resolved has issues when the answer is over 512 bytes with
  EDNS disabled

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  Fix Committed
Status in systemd package in Debian:
  Fix Released

Bug description:
  [Impact]

  TCP stub is cutting down the payload to 512 bytes when EDNS is
  disabled. This makes non-EDNS clients (nslookup) receive a "shortened"
  answer even when UDP returns a truncated reply for a new TCP query.
  For instance,

  - If the client supports EDNS:

  $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  30

  - If the client does not support EDNS:

  $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  29

  In the second case, no-EDNS, TCP should provide the complete answer,
  but it's capped at UDP's size.

  [Test Case]

  Query systemd-resolved with a domain name that resolves to multiple
  (lots.. 30+) A records. A client with EDNS support (dig) will receive
  all of them, a client without support (nslookup or dig +noedns) will
  have a truncated list. Using the example above:

  EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 
| wc -l

  [Regression potential]

  Minimal. This change only affects TCP requests, and the new size is
  already used in the code for other requests.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10816
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce

  [Original Description]

  Querying a domain name that has >512 bytes in records (e.g. 30+ A
  records), the number of results depends on the DNS client used:

  - If the client supports EDNS:

  $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  30

  - If the client does not support EDNS:

  $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
  29

  Normally a client that doesn't support EDNS would receive a truncated
  reply from the initial UDP connection (limited by the spec to 512
  bytes) and a second query would be established via TCP to receive the
  complete results. In this case, the number of results is the same
  regardless of the protocol used (29).

  Upstream bug: https://github.com/systemd/systemd/issues/10816

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1806483] Re: Ubuntu 18.04.1 - OpenSSL RSA connection rate performance degradation using ibmca engine (openssl-ibmca)

[Dimitri John Ledkov]

** Also affects: openssl-ibmca (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: openssl-ibmca (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: openssl-ibmca (Ubuntu Disco)
   Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
   Status: New

** Also affects: openssl-ibmca (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1806483

Title:
  Ubuntu 18.04.1 - OpenSSL RSA connection rate performance degradation
  using ibmca engine (openssl-ibmca)

Status in Ubuntu on IBM z Systems:
  Triaged
Status in openssl-ibmca package in Ubuntu:
  New
Status in openssl-ibmca source package in Xenial:
  New
Status in openssl-ibmca source package in Bionic:
  New
Status in openssl-ibmca source package in Cosmic:
  New
Status in openssl-ibmca source package in Disco:
  New

Bug description:
  ---Problem Description---
  Recent performance evaluation has shown significant degradation in the TLS 
connections per second rate using the OpenSSL s_time benchmark with Ubuntu 
18.04.1.
  While doing RSA sign/verify operations, the engine would preffer doing RSA-ME 
instead of RSA-CRT which is significantly better in terms of performance.

  Baseline for this comparison are measurements executed with another distro.
  Both measurements have been made on LPAR native, using the CEX6A adapter.

  Crypto stack on the host:
  OpenSSL ver: 1.1.0g
  IBMCA ver: 1.4.1.-0
  Libica ver: 3.2.1

  Problem present under following condititions:
  1. IBMCA ver >= 2.0.0
  2. OpenSSL version >= 1.1.0 && IBMCA ver >= 1.3.1.
   
  ---uname output---
  Linux m42lp01 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:42:24 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = Type/Model:3906-M04 LPAR 
   
  ---Steps to Reproduce---
   Server; openssl s_server -cert benchcert.pem -quiet -WWW -engine ibmca 
-accept 8050
  Client: openssl s_time -key benchcert.pem -www /2k.html -time 90 -cipher 
AES256-SHA -new -bugs -connect 10.14.1.254:8050 -elapsed

  By scaling the number of processes, the issue becomes more and more visible.
   
  Userspace tool common name: openssl-ibmca 
   
  The userspace tool has the following bit modes: 64 

  Userspace package: openssl-ibmca-1.4.1-0ubuntu1.s390x

  The attached patch is generated from the commit available here:
  
https://github.com/opencryptoki/openssl-ibmca/commit/a0e23d4063bf897dd9136c491d2201de5fbba653

  Generated with: 
  git format-patch -1 a0e23d4063bf897dd9136c491d2201de5fbba653

  To be applied with: 
  patch /openssl-ibmca/src/ibmca_rsa.c 
~/0001-Fix-doing-rsa-me-altough-rsa-crt-would-be-possible.patch

  Fix applies smoothly and shows expected performance improvement as
  visible on the chart.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1806483/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1798424] Re: Xenial Azure: Make generation of network config from IMDS hotplug scripts configurable opt-in

[Dimitri John Ledkov]

this should have had ubuntu task added. Has this been verified yet?

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1798424

Title:
  Xenial Azure: Make generation of network config from IMDS  hotplug
  scripts configurable opt-in

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  New
Status in cloud-init source package in Xenial:
  Fix Committed

Bug description:
  cloud-init v. 18.4-0ubuntu1~16.04.1 in -proposed automatically renders
  network configuration from Azure's IMDS by default instead of fallback
  config of dhcp on eth0. This represents a difference in behavior from
  current Xenial.

  
  On Xenial Azure, Ubuntu cloud images have udev scripts to handle network 
hotplug. Azure datasource has the ability to read full network config from 
their IMDS service and render hotplugged devices as well as remove the 
cloud-image default scripts.

  Make the cloud-init hotplug behavior configurable and default it to
  off in Xenial.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1794308] Re: VM devices rdr, pun and prt are not activated after restart

[Dimitri John Ledkov]

** Also affects: s390-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: s390-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1794308

Title:
  VM devices rdr, pun and prt are not activated after restart

Status in s390-tools:
  Unknown
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools source package in Xenial:
  New
Status in s390-tools source package in Bionic:
  New

Bug description:
  [Impact]

   * Cannot configure race-free generic-ccw devices to be onlined on
  boot.

  [Test Case]

  # on a z/VM

  $ sudo chzdev -d 0.0.000c 0.0.000d 0.0.000e
  $ sudo chzdev -e 0.0.000c 0.0.000d 0.0.000e
  $ sudo update-initramfs -u
  $ sudo reboot
  $ lszdev

  Expectations is for generic-ccw c-d-e devices to be "yes yes" meaning online 
and persistent online.
  Previously after a reboot they would be "no yes" meaning offline yet 
persistent configured online.

  [Regression Potential]

   * generic-ccw rules need to be `upgraded` / `regenerated` which is
  not done in maintainer scripts in this upload for now.

  [Other Info]

   * fix contributed upstream at

  https://github.com/ibm-s390-tools/s390-tools/pull/45/files

   * original bug report

  Linux s390x as VM guest can use the VM-specific reader (0.0.000c),
  puncher (0.0.000d) and printer devices (0.0.000e).

  They can be enabled as usual with chzdev like:
  lszdev | grep '000c\|000d\|000e'
  generic-ccw  0.0.000cno   no
  generic-ccw  0.0.000dno   no
  generic-ccw  0.0.000eno   no
  sudo chzdev -e 000c 000d 000e
  Generic CCW device 0.0.000c configured
  Generic CCW device 0.0.000d configured
  Generic CCW device 0.0.000e configured
  lszdev | grep '000c\|000d\|000e'
  generic-ccw  0.0.000cyes  yes   vmrdr-0.0.000c
  generic-ccw  0.0.000dyes  yes   vmpun-0.0.000d
  generic-ccw  0.0.000eyes  yes   vmprt-0.0.000e

  Aa a result of that activation udev rules are generated:
  ls -la /etc/udev/rules.d/41-generic-ccw-0.0.000{c,d,e}.rules
  -rw-r--r-- 1 root root  238 Sep 21 06:24 41-generic-ccw-0.0.000c.rules
  -rw-r--r-- 1 root root  238 Sep 21 06:24 41-generic-ccw-0.0.000d.rules
  -rw-r--r-- 1 root root  238 Sep 25 10:15 41-generic-ccw-0.0.000e.rules
  cat /etc/udev/rules.d/41-generic-ccw-0.0.000{c,d,e}.rules
  # Generated by chzdev
  ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000c", 
GOTO="cfg_generic_ccw_0.0.0
  00c"
  GOTO="end_generic_ccw_0.0.000c"

  LABEL="cfg_generic_ccw_0.0.000c"
  ATTR{[ccw/0.0.000c]online}="1"

  LABEL="end_generic_ccw_0.0.000c"
  # Generated by chzdev
  ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000d", 
GOTO="cfg_generic_ccw_0.0.0
  00d"
  GOTO="end_generic_ccw_0.0.000d"

  LABEL="cfg_generic_ccw_0.0.000d"
  ATTR{[ccw/0.0.000d]online}="1"

  LABEL="end_generic_ccw_0.0.000d"
  # Generated by chzdev
  ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000e", 
GOTO="cfg_generic_ccw_0.0.0
  00e"
  GOTO="end_generic_ccw_0.0.000e"

  LABEL="cfg_generic_ccw_0.0.000e"
  ATTR{[ccw/0.0.000e]online}="1"

  LABEL="end_generic_ccw_0.0.000e"

  Once this is done it's expected that this configuration is persistent
  and that these three devices are automatically activated after a
  reboot, which is not the case:

  lszdev | grep '000c\|000d\|000e'
  generic-ccw  0.0.000cno  yes
  generic-ccw  0.0.000dno  yes
  generic-ccw  0.0.000eno  yes

  A 'sudo udevadm trigger' doesn't help to activate them again.

  Another 'sudo chzdev -e 000c 000d 000e' helps, but again for the
  current session only.

  [
  The cio_ignore list is empty, hence this can't be the reason:
  cio_ignore -l
  Ignored devices:
  =
  $
  ]

To manage notifications about this bug go to:
https://bugs.launchpad.net/s390-tools/+bug/1794308/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 651035] Re: excessive debug messages from "os-prober"

[Dimitri John Ledkov]

Bionic and later are fix released.

Xenial & Trusty are still affected, as far as I believe based on debian
bug report fixed versions metadata.

** Also affects: os-prober (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: os-prober (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: os-prober (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/651035

Title:
  excessive debug messages from "os-prober"

Status in os-prober:
  Fix Released
Status in os-prober package in Ubuntu:
  Fix Released
Status in os-prober source package in Trusty:
  New
Status in os-prober source package in Xenial:
  New

Bug description:
  Binary package hint: grub2

  grub2 invokes os-prober, but it seems debuggign is activated by
  default; from my log:

  
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/10freedos on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 10freedos: debug: /dev/cciss/c0d0p2 is not a FAT 
partition: exiting
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/10qnx on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 10qnx: debug: /dev/cciss/c0d0p2 is not a QNX4 
partition: exiting
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/20macosx on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 macosx-prober: debug: /dev/cciss/c0d0p2 is not an 
HFS+ partition: exiting
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/20microsoft on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 20microsoft: debug: /dev/cciss/c0d0p2 is not a MS 
partition: exiting
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/30utility on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 30utility: debug: /dev/cciss/c0d0p2 is not a FAT 
partition: exiting
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/40lsb on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/70hurd on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/80minix on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/90linux-distro on mounted /dev/cciss/c0d0p2
  Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running 
/usr/lib/os-probes/mounted/90solaris on mounted /dev/cciss/c0d0p2

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: grub-pc 1.98+20100804-5ubuntu2
  ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
  Uname: Linux 2.6.35-22-generic i686
  Architecture: i386
  Date: Wed Sep 29 13:13:56 2010
  ProcEnviron:
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: grub2

To manage notifications about this bug go to:
https://bugs.launchpad.net/os-prober/+bug/651035/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1738153] Re: need backport the new scancode of dell-wmi for Microphone mute hotkey to xenial

[Dimitri John Ledkov]

** Changed in: systemd (Ubuntu Artful)
   Status: Confirmed => Won't Fix

** Changed in: systemd (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1738153

Title:
  need backport the new scancode of dell-wmi for Microphone mute hotkey
  to xenial

Status in OEM Priority Project:
  Confirmed
Status in OEM Priority Project xenial series:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Artful:
  Won't Fix

Bug description:
  [Impact]
  dell-wmi expend the scan code of Microphone mute hotkey from 0x150 to 
0x100150, so need to add a new mapping for it.

  related commit:
  https://github.com/systemd/systemd/pull/5012

  [Test Case]
  1. install the udev package which applied patch.
  2. check if Microphone mute hotkey works.
  3. if it not works, please provide the log of evtest.

  [Regression Potential]
  low regression potential, because it just add one more mapping.

  also affect:
  LP: #1736352
  LP: #1740080
  LP: #1734609

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1738153/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1727237] Re: systemd-resolved is not finding a domain

[Dimitri John Ledkov]

** Changed in: systemd (Ubuntu Artful)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1727237

Title:
  systemd-resolved is not finding a domain

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Triaged
Status in systemd source package in Zesty:
  Won't Fix
Status in systemd source package in Artful:
  Won't Fix
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  
  [Impact] 

   * Certain WiFi captive portals do not support EDNS0 queries, as per RFC.
   * Instead of responding with the captive portal IP address, they resond with 
domain not found
   * This prevents the user from hitting the captive portal login page, able to 
authenticate, and gain access to the internets.

  [The Fix]

   * As per tcp dumps, the problem arrises from receiving NXDOMAIN when queried 
with EDNS0
   * And receiving the right response without EDNS0
   * The solution was to downgrade transactions, and retry EDNS0 + NXDOMAIN 
result without EDNS0 with a hope of getting the right answer.

  [Test Case]

  * systemd-resolve securelogin.example.com
  * journalctl -b -u systemd-resolve | grep DVE-2018

  You should obverse that a warning message that transaction was retried
  with a reduced feature level e.g. UDP or TCP.

  After this test case is performed the result will be cached, therefore
  to revert to pristine state perform

  * systemd-resolve --flush-caches

  [Regression Potential]

   * The code retries, and then caches, NXDOMAIN results for certain
  queries (those that have 'secure' in them) with and without EDNS0.

   * Thus initial query for these domains may take longer, but hopefully
  will manage to receive the correct response.

   * Manufacturers are encouraged to correctly support EDNS0 queries,
  with flag D0 set to zero.

  [Other Info]
   
   * This issue is tracked as a dns-violation at
  
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md

  [Original Bug report]

  I have an odd network situation that I have so far managed to narrow
  down to the inability to resolve a domain via systemd-resolved which
  is resolvable with nslookup. If I use nslookup against the two
  nameservers on this network I get answers for the domain, but ping
  says it is unable to resolve the same domain (as do browsers and
  crucially the captive portal mechanism).

  Here are details:

  NSLOOKUP:

  ~$ nslookup securelogin.arubanetworks.com 208.67.220.220
  Server:   208.67.220.220
  Address:  208.67.220.220#53

  Non-authoritative answer:
  Name: securelogin.arubanetworks.com
  Address: 172.22.240.242

  ~$ nslookup securelogin.arubanetworks.com 208.67.222.222
  Server:   208.67.222.222
  Address:  208.67.222.222#53

  Non-authoritative answer:
  Name: securelogin.arubanetworks.com
  Address: 172.22.240.242

  PING:

  ~$ ping securelogin.arubanetworks.com
  ping: securelogin.arubanetworks.com: Name or service not known
  mark@mark-X1Y2:~$

  DIG:

  ~$ dig @208.67.222.222 securelogin.arubanetworks.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @208.67.222.222 securelogin.arubanetworks.com
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9416
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;securelogin.arubanetworks.com.   IN  A

  ;; AUTHORITY SECTION:
  arubanetworks.com.1991IN  SOA dns5.arubanetworks.com. 
hostmaster.arubanetworks.com. 1323935888 3600 200 1209600 86400

  ;; Query time: 34 msec
  ;; SERVER: 208.67.222.222#53(208.67.222.222)
  ;; WHEN: Wed Oct 25 10:31:10 CEST 2017
  ;; MSG SIZE  rcvd: 144

  MORE DIG:

  ~$ dig securelogin.arubanetworks.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> securelogin.arubanetworks.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;securelogin.arubanetworks.com.   IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Wed Oct 25 10:34:01 CEST 2017
  ;; MSG SIZE  rcvd: 58

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1773148] Re: /lib/systemd/systemd-journald:6:fsync:fsync_directory_of_file:journal_file_rotate:do_rotate:server_rotate

[Dimitri John Ledkov]

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

** Bug watch added: github.com/systemd/systemd/issues #9079
   https://github.com/systemd/systemd/issues/9079

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/9079
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1773148

Title:
  /lib/systemd/systemd-
  
journald:6:fsync:fsync_directory_of_file:journal_file_rotate:do_rotate:server_rotate

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Cosmic:
  New

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

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1795658] Re: xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently

[Dimitri John Ledkov]

Note to self, everything after xenial has this patch already.

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

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

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

** Changed in: systemd (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1795658

Title:
  xenial systemd reports 'inactive' instead of 'failed' for service
  units that repeatedly failed to restart / failed permanently

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  Triaged

Bug description:
  [Impact]

   * In case a service unit has repeatedly failed to restart, it should be
 reported as 'failed' permanently, but currently it's instead reported
 as 'inactive'.

   * System monitoring tools that evaluate the status of systemd service units
 and act upon it (for example: restart service, report permanent failure)
 are currently misled by information in 'systemctl status .service'.

   * System management tools based on such information may take wrong and/or
 sub-optimal actions in the managed systems regarding such service units.

   * This systemd patch [1] directly addresses this issue (see systemd github
 PR #3166 [2]), and its code is still effectice in upstream systemd today,
 without further fixes/changes (the only changes were in doc text and the
 busname files that were removed, but still without further fixes to this).

  [Test Case]

   * This is copied from systemd PR #3166 [2].

   * This has been tested by a customer as well, and with its system monitoring
 and management solution, for interoperability verification.

  $ cat <https://github.com/systemd/systemd/commit/072993504e3e4206ae1019f5461a0372f7d82ddf
  [2] https://github.com/systemd/systemd/issues/3166
  [3] https://launchpad.net/~mfo/+archive/ubuntu/sf199312

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

[Dimitri John Ledkov]

Using this bug to fix systemd exported environment to the generators.

** Changed in: systemd (Ubuntu Cosmic)
   Status: Won't Fix => Fix Committed

** Changed in: systemd (Ubuntu Bionic)
   Status: Won't Fix => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771858

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in snapd source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in snapd source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in snapd source package in Cosmic:
  Confirmed
Status in systemd source package in Cosmic:
  Fix Committed

Bug description:
  This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

  Specifically, this is evident by e.g. $ systemd-run env. Or any other
  daemons that spawn shell scripts (e.g. cloud-init metadata acquired
  shell hooks, etc.).

  Since v232 systemd provides support for environment generators, snapd
  should package/ship a snippet that injects the correct snapd path into
  systemd environment.

  E.g.:

  $ sudo mkdir -p /usr/lib/systemd/system-environment-generators
  $ printf '#!/bin/sh\nPATH=$PATH:/snap/bin\n' | \
  sudo tee /usr/lib/systemd/system-environment-generators/90-snapd

  Something similar can be done for user-environment-generators too.
  Note that user-environment-generators can generate unique variables
  per user.

  Note please use /usr/lib path, as it appears that /lib/systemd path is
  not working atm. Will check if that needs to be fixed up.

  systemd in xenial does not support system-environment-generators, thus
  we probably need to upload a patch to change the DEFAULT_PATH compiled
  in default there.

  [Testcase]

  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1662813] Re: Libjna-jni uses wrong path on package installation on s390x

[Dimitri John Ledkov]

Is this on Cosmic? Bionic? or Xenial?

I see that system.so is used everywhere by default, on things that do
intentionally use system jna.

However, on xenial, there is one patch missing to ignore the override
properties.

Jenkins as shipped in the 3rd party repo does not use system deb:libjna-
java and does not need it installed at all.

** Also affects: libjna-java (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1662813

Title:
  Libjna-jni uses wrong path on package installation on s390x

Status in Ubuntu on IBM z Systems:
  Invalid
Status in libjna-java package in Ubuntu:
  Invalid
Status in libjna-java source package in Xenial:
  New

Bug description:
  libjna-jni uses the wrong path for linking the library 
/usr/lib/s390x-linux-gnu/libjnidispatch.so
  on the z Systems s390x architecture, therefore applications relying on this 
library are unable to link to it, even if the package is installed.
  Creating the link manually fixes this problem.

  It should be linked from /usr/lib/s390x-linux-
  gnu/jni/libjnidispatch.system.so

  /sbin/ldconfig.real: Can't link /usr/lib/s390x-linux-gnu//build
  /libjna-java-D1S9TX/libjna-java-4.2.2/build/native-linux-
  s390x/libjnidispatch.system.so to libjnidispatch.so

  dpkg -S /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so 
  libjna-jni: /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1662813/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option

[Dimitri John Ledkov]

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1561643

Title:
  initramfs-tools ignores the FRAMEBUFFER option

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  initramfs-tools ignores the FRAMEBUFFER option. This means that the
  framebuffer hook will always include the drm modules, regardless of
  whether it is dealing with an encrypted system or not.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: initramfs-tools 0.122ubuntu6
  ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
  Uname: Linux 4.4.0-15-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Thu Mar 24 18:06:24 2016
  InstallationDate: Installed on 2016-02-16 (37 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dimitri John Ledkov]

** Also affects: landscape-client (Ubuntu Cosmic)
   Importance: High
 Assignee: Dave Jones (waveform)
   Status: Fix Committed

** Also affects: systemd (Ubuntu Cosmic)
   Importance: High
 Assignee: Dimitri John Ledkov (xnox)
   Status: Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1670291

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Confirmed
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in landscape-client source package in Bionic:
  New
Status in systemd source package in Bionic:
  Confirmed
Status in landscape-client source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Confirmed

Bug description:
  https://github.com/systemd/systemd/pull/10061

  [Impact]

   * When logind is not available, shutdown command fails to schedule a
  shutdown, and despite its intentions to immediately shutdown, does not
  do so.

  [Test Case]

sudo systemctl mask systemd-logind.service
sudo systemctl stop systemd-logind.service
shutdown +1

  The expectation is that system goes to shutdown.

  It is buggy if the system remains up - i.e. command returns to shell
  with exit code 1.

  [Regression Potential]

   * It is a corner case to run against systemd-shim logind / or logind
  not otherwise available. The function still performs a clean-shutdown,
  and should not cause loss of work.

  [Other Info]
   
   * Original bug report, running against systemd-shim/systemd-service post 
trusty->xenial upgrade, pre-reboot.

  
  Used Landscape (Paid Canonical Subscription) to upgrade one of my machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dimitri John Ledkov]

** Also affects: landscape-client (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

** Changed in: systemd (Ubuntu Xenial)
Milestone: ubuntu-16.04.3 => xenial-updates

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1670291

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Confirmed
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in landscape-client source package in Bionic:
  New
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1781242] Re: as segfault with invalid -march= option

[Dimitri John Ledkov]

In unapproved queue, waiting review and approval.

** Description changed:

  The GNU assembler segfaults with an invalid -march= option
-  
- Contact Information = n/a 
-  
+ 
+ Contact Information = n/a
+ 
  ---uname output---
  n/a
-  
- Machine Type = n/a 
-  
+ 
+ Machine Type = n/a
+ 
  ---Debugger---
  A debugger is not configured
-  
+ 
  ---Steps to Reproduce---
-  $ as -march=foo
+  $ as -march=foo
  Segmentation fault
-  
- Userspace tool common name: as 
-  
- The userspace tool has the following bit modes: 64 
+ 
+ Expected result:
+ # as -march=foo
+ Assembler messages:
+ Error: invalid switch -march=foo
+ Error: unrecognized option -march=foo
+ 
+ Userspace tool common name: as
+ 
+ The userspace tool has the following bit modes: 64
  
  Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6
  
- Userspace tool obtained from project website:  na 
-  
+ Userspace tool obtained from project website:  na
+ 
  *Additional Instructions for n/a:
  -Attach ltrace and strace of userspace application.
  
- 
- The problem is not critical since usually 'as' is invoked through the gcc 
driver which itself errors out for wrong -march= options. It will only be a 
problem if somebody builds a more recent GCC from source and uses an -march= 
option for a machine not supported by the default binutils.
+ The problem is not critical since usually 'as' is invoked through the
+ gcc driver which itself errors out for wrong -march= options. It will
+ only be a problem if somebody builds a more recent GCC from source and
+ uses an -march= option for a machine not supported by the default
+ binutils.
  
  Please consider integrating the attached patch into 16.04 binutils.
  
  The problem has been fixed in later binutils already. Ubuntu 18.04 does
  not appear to be affected.
  
  --> Package has to set corectly by Canonical

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

** Changed in: binutils (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: binutils (Ubuntu Xenial)
Milestone: None => xenial-updates

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1781242

Title:
  as segfault with invalid -march= option

Status in Ubuntu on IBM z Systems:
  Triaged
Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Xenial:
  In Progress

Bug description:
  The GNU assembler segfaults with an invalid -march= option

  Contact Information = n/a

  ---uname output---
  n/a

  Machine Type = n/a

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   $ as -march=foo
  Segmentation fault

  Expected result:
  # as -march=foo
  Assembler messages:
  Error: invalid switch -march=foo
  Error: unrecognized option -march=foo

  Userspace tool common name: as

  The userspace tool has the following bit modes: 64

  Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6

  Userspace tool obtained from project website:  na

  *Additional Instructions for n/a:
  -Attach ltrace and strace of userspace application.

  The problem is not critical since usually 'as' is invoked through the
  gcc driver which itself errors out for wrong -march= options. It will
  only be a problem if somebody builds a more recent GCC from source and
  uses an -march= option for a machine not supported by the default
  binutils.

  Please consider integrating the attached patch into 16.04 binutils.

  The problem has been fixed in later binutils already. Ubuntu 18.04
  does not appear to be affected.

  --> Package has to set corectly by Canonical

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781242/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783252] Re: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le

[Dimitri John Ledkov]

@sil2100

In practice we care about the default compiler only. In bionic it is
gcc-7 and is fixed.

Unfortunately, we do still have gcc-5 around as non default. The fix for
this was cherrypicked into cosmic already -
https://launchpad.net/ubuntu/+source/gcc-5/5.5.0-12ubuntu6

I will open a task to fix this in bionic as well, although gcc-5 should
not be used on bionic! (or specifically not in the openstack CI with
16.04/bionic as base os)

** Also affects: python-greenlet (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** No longer affects: python-greenlet (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1783252

Title:
  gcc on ppc64le has bogus r30 register handling, as exposed by greenlet
  0.4.14 will not build on ppc64le

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in gcc-5 package in Ubuntu:
  Fix Released
Status in python-greenlet package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  Fix Committed
Status in gcc-5 source package in Bionic:
  New

Bug description:
  [Impact]

   * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries.
   * A patch to fix this has been upstream in 6+
   * But it is not in gcc-5.4 as used on xenial
   * This prevents compiling future-proof and correct greenlet code, on Ubuntu 
16.04 LTS as used by current and supported Openstack Queens release on ppc64el
   * Whilst backported greenlet is available via the cloud archive for binary 
usage, the toolchain is still technically incorrect, and thus hinders using 
Ubuntu 16.04 LTS as workers in upstream Openstack CI
   * As a wishlist it would be nice to backport this one small gcc patch as an 
SRU

  [Test Case]

   * git clone https://github.com/python-greenlet/greenlet
   * cd greenlet
   * ./setup.py build
  Expect success

  Current result failure:

  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
   from greenlet.c:343:
  platform/switch_ppc64_linux.h: In function 'slp_switch':
  platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1

  
  [Regression Potential] 

   * Upstream cherrypick present in later releases including bionic
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361

  
  [Other Info]
   
   * Original bug report

  
  == Comment: #0 - William M. Edmonds  - 2018-07-23 
16:21:41 ==
  ---Problem Description---
  greenlet 0.4.14 will not build on ppc64le

  Opened https://github.com/python-greenlet/greenlet/issues/136 because
  attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu
  16.04 LTS yields the following error:

  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
  from greenlet.c:343:
     platform/switch_ppc64_linux.h: In function 'slp_switch':
     platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```

  But the greenlet community is saying this is a gcc bug and it would
  not be safe to revert the greenlet change that exposed this issue. I
  have no idea whether that is true or not. Supposedly this should be
  fixed by
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361
  but that fix is not present in the latest version of gcc (5.4.0)
  available for Ubuntu 16.04 LTS.

  ---uname output---
  unavailable due to lab outage

  Machine Type 

[Group.of.nepali.translators] [Bug 1781535] Re: qdio: don't retry EQBS after CCQ 96

[Dimitri John Ledkov]

$ git tag --contains dae55b6 Ubuntu-4.17.0-6.7
Ubuntu-4.17.0-6.7

And released.

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1781535

Title:
  qdio: don't retry EQBS after CCQ 96

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  Description:  qdio: don't retry EQBS after CCQ 96

  Symptom:  Queue stalls, over-/underreporting of buffer errors.

  Problem:  Immediate retry of EQBS after CCQ 96 means that we
potentially misreport the state of buffers inspected
during the first EQBS call.

  Solution: On CCQ 96, first process the discovered state.
Afterwards, higher-level code will eventually trigger an
EQBS/inspection of the remaining buffers. Their state is
now processed independently from the state that was
discovered during the first EQBS.

  Upstream-ID:  dae55b6fef58530c13df074bcc182c096609339e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781535/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1781242] Re: as segfault with invalid -march= option

[Dimitri John Ledkov]

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1781242

Title:
  as segfault with invalid -march= option

Status in Ubuntu on IBM z Systems:
  Triaged
Status in binutils package in Ubuntu:
  New
Status in binutils source package in Xenial:
  New

Bug description:
  The GNU assembler segfaults with an invalid -march= option
   
  Contact Information = n/a 
   
  ---uname output---
  n/a
   
  Machine Type = n/a 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   $ as -march=foo
  Segmentation fault
   
  Userspace tool common name: as 
   
  The userspace tool has the following bit modes: 64 

  Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for n/a:
  -Attach ltrace and strace of userspace application.

  
  The problem is not critical since usually 'as' is invoked through the gcc 
driver which itself errors out for wrong -march= options. It will only be a 
problem if somebody builds a more recent GCC from source and uses an -march= 
option for a machine not supported by the default binutils.

  Please consider integrating the attached patch into 16.04 binutils.

  The problem has been fixed in later binutils already. Ubuntu 18.04
  does not appear to be affected.

  --> Package has to set corectly by Canonical

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781242/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783252] Re: greenlet 0.4.14 will not build on ppc64le

[Dimitri John Ledkov]

I think I get it all now.

https://github.com/python-
greenlet/greenlet/commit/9c8a65fddcffe161f38679a0b3289de9b25e2bc6.patch
-> unbreaks with new gcc-7, but broken again with old gcc-5 again

And hence you are stuck between a rock and a hard-place either hack-
up a Frankenstein toolchain or somehow revert future-proof correct
upstream code, for sake of older buggy gcc.

I wonder if greenlet could somehow detect buggy compiler and still build
with it... 

** Also affects: python-greenlet (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: gcc-5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: gcc-5 (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: gcc-5 (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: gcc-5 (Ubuntu Xenial)
   Importance: High => Wishlist

** Changed in: gcc-5 (Ubuntu)
   Status: Incomplete => Won't Fix

** No longer affects: python-greenlet (Ubuntu Xenial)

** Description changed:

+ [Impact]
+ 
+  * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries.
+  * A patch to fix this has been upstream in 6+
+  * But it is not in gcc-5.4 as used on xenial
+  * This prevents compiling future-proof and correct greenlet code, on Ubuntu 
16.04 LTS as used by current and supported Openstack Queens release on ppc64el
+  * Whilst backported greenlet is available via the cloud archive for binary 
usage, the toolchain is still technically incorrect, and thus hinders using 
Ubuntu 16.04 LTS as workers in upstream Openstack CI
+  * As a wishlist it would be nice to backport this one small gcc patch as an 
SRU
+ 
+ [Test Case]
+ 
+  * git clone https://github.com/python-greenlet/greenlet
+  * cd greenlet
+  * ./setup.py build
+ Expect success
+ 
+ Current result failure:
+ 
+ creating build/temp.linux-ppc64le-2.7
+ powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
+ In file included from slp_platformselect.h:16:0,
+  from greenlet.c:343:
+ platform/switch_ppc64_linux.h: In function 'slp_switch':
+ platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 
'asm'
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  ^
+ platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 
'asm'
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  ^
+ error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1
+ 
+ 
+ [Regression Potential] 
+ 
+  * Upstream cherrypick present in later releases including bionic
+ 
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361
+ 
+ 
+ [Other Info]
+  
+  * Original bug report
+ 
+ 
  == Comment: #0 - William M. Edmonds  - 2018-07-23 
16:21:41 ==
  ---Problem Description---
  greenlet 0.4.14 will not build on ppc64le
  
  Opened https://github.com/python-greenlet/greenlet/issues/136 because
  attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu
  16.04 LTS yields the following error:
  
  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
- from greenlet.c:343:
-platform/switch_ppc64_linux.h: In function 'slp_switch':
-platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
- __asm__ volatile ("" : : : REGS_TO_SAVE);
- ^
-platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
- __asm__ volatile ("" : : : REGS_TO_SAVE);
- ^
-error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```
+ from greenlet.c:343:
+    platform/switch_ppc64_linux.h: In function 'slp_switch':
+    platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
+ __asm__ volatile ("" : : : REGS_TO_SAVE);
+ ^
+    platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
+ __asm__ volatile ("" : : : REGS_TO_SAVE);
+ ^
+    error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```
  
- But the greenlet community is saying this is a gcc bug and it would not be 
safe to revert the greenlet change that exposed this issue. I have no idea 
whether that is true or not. Supposedly this should be fixed by 

[Group.of.nepali.translators] [Bug 1765364] Re: Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and possibly 14.04 LTS releases

[Dimitri John Ledkov]

marking qemu package tasks to affect xenial series only then.

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

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

** Changed in: qemu (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: qemu (Ubuntu)
 Assignee: Marc Deslauriers (mdeslaur) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765364

Title:
  Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and
  possibly 14.04 LTS releases

Status in The Ubuntu-power-systems project:
  Incomplete
Status in The Ubuntu-power-systems project ubuntu-16.04 series:
  New
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  New

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2018-04-19 
04:26:51 ==
  ---Problem Description---
  Backport spectre/meltdown fixes on qemu for ppc64 into all LTS releases
   
  Contact Information = sathe...@in.ibm.com 
   
  ---uname output---
  -
   
  Machine Type = power8,power9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   For pseries guests there are 3 tri-state -machine options/capabilities 
relating to Spectre/Meltdown mitigation: cap-cfpc, cap-sbbc, cap-ibs, which 
each correspond to a set of host machine capabilities advertised by the KVM 
kernel module in new/patched host kernels that can be used to mitigate various 
aspects of Spectre/Meltdown:

  cap-cfpc: Cache Flush on Privilege Change
  cap-sbbc: Speculation Barrier Bounds Checking
  cap-ibs: Indirect Branch Serialisation

  Details can be found here https://www.qemu.org/2018/02/14/qemu-2-11-1
  -and-spectre-update/

  Needed qemu commits:

  cb931c2108 target/ppc: Check mask when setting cap_ppc_safe_indirect_branch
  4f5b039d2b ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs
  8c5909c419 ppc/spapr-caps: Change migration macro to take full spapr-cap name
  c59704b254 target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS
  4be8d4e7d9 target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch
  09114fd817 target/ppc/spapr_caps: Add new tristate cap safe_bounds_check
  8f38eaf8f9 target/ppc/spapr_caps: Add new tristate cap safe_cache
  6898aed77f target/ppc/spapr_caps: Add support for tristate spapr_capabilities
  8acc2ae5e9 target/ppc/kvm: Add 
cap_ppc_safe_[cache/bounds_check/indirect_branch]


  Optional commits to introduce a machine type variant pseries--sxxm, 
when used would set/enable the three machine capabilities explained above 
automatically, if host is capable(host kernel is supported). Bug 166426
  813f3cf655 ppc/spapr-caps: Define the pseries-2.12-sxxm machine type
  c76c0d3090 ppc/spapr-caps: Convert cap-ibs to custom spapr-cap
  aaf265ffde ppc/spapr-caps: Convert cap-sbbc to custom spapr-cap
  f27aa81e72 ppc/spapr-caps: Convert cap-cfpc to custom spapr-cap
  87175d1bc5 ppc/spapr-caps: Add support for custom spapr_capabilities

  
   
  Userspace tool common name: qemu-kvm 
   
  The userspace tool has the following bit modes: both 

  Userspace rpm: qemu-kvm

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for sathe...@in.ibm.com:
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1765364/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1777600] Re: chzdev can't find modprobe

[Dimitri John Ledkov]

** No longer affects: s390-tools (Ubuntu Artful)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1777600

Title:
  chzdev can't find modprobe

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools source package in Xenial:
  New
Status in s390-tools source package in Bionic:
  New
Status in s390-tools source package in Cosmic:
  Fix Released

Bug description:
  Description:  only when trying to change some attributes chzdev fails because 
it cant find modprobe under Ubuntu 18.04

root@m83lp09:~# chzdev zfcp --type datarouter=0 dbflevel=5
sh: 1: /usr/sbin/modprobe: not found
zfcp device type configure failed
Error: Command failed (exit code 127): /usr/sbin/modprobe 
-r zfcp

root@m83lp09:~# whereis modprobe
modprobe: /sbin/modprobe /etc/modprobe.d /lib/modprobe.d 
/usr/share/man/man8/modprobe.8.gz



  Potential solution ? : adding a symlink is a workaround, is this path 
hardcoded?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1777600/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

[Dimitri John Ledkov]

** Changed in: linux (Ubuntu)
   Importance: High => Critical

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1780227

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in apparmor source package in Xenial:
  New
Status in linux source package in Xenial:
  Triaged
Status in apparmor source package in Bionic:
  New
Status in linux source package in Bionic:
  Triaged

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1716999] Re: installer creates rather small /boot partition

[Dimitri John Ledkov ]

** No longer affects: partman-auto (Ubuntu Xenial)

** Also affects: partman-auto (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** No longer affects: partman-auto (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1716999

Title:
  installer creates rather small /boot partition

Status in partman-auto package in Ubuntu:
  Fix Released
Status in partman-auto source package in Xenial:
  New

Bug description:
  The installer (in 16.04 and 17.10) creates a separate /boot partition,
  when required, of only 487M. This ends up being rather small when you
  using the following equation to estimate a minimal size allowing for
  reasonable room for further growth.

  (2*(3*kernel + 4*plymouth-carrying initrd + bootloader))

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1716999] Re: installer creates rather small /boot partition

[Dimitri John Ledkov ]

** Also affects: partman-auto (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: partman-auto (Ubuntu Bionic)
Milestone: None => ubuntu-18.04.1

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1716999

Title:
  installer creates rather small /boot partition

Status in partman-auto package in Ubuntu:
  Fix Released
Status in partman-auto source package in Xenial:
  New
Status in partman-auto source package in Bionic:
  New

Bug description:
  The installer (in 16.04 and 17.10) creates a separate /boot partition,
  when required, of only 487M. This ends up being rather small when you
  using the following equation to estimate a minimal size allowing for
  reasonable room for further growth.

  (2*(3*kernel + 4*plymouth-carrying initrd + bootloader))

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1775641] Re: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu

[Dimitri John Ledkov ]

** No longer affects: ubuntu-z-systems

** Package changed: ibm-java80 (Ubuntu) => ibm-java71 (Ubuntu)

** No longer affects: ibm-java71 (Ubuntu)

** No longer affects: ibm-java80 (Ubuntu)

** No longer affects: ibm-java71 (Ubuntu Xenial)

** No longer affects: ibm-java80 (Ubuntu Xenial)

** No longer affects: ibm-java71 (Ubuntu Bionic)

** No longer affects: ibm-java80 (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1775641

Title:
  [Comm] IBM JDK 8.0.5.16 integration into Ubuntu

Status in Ubuntu on IBM z Systems:
  New

Bug description:
  foreman@cit7r02:~/sandbox/binary$ ftp archive.admin.canonical.com
  Connected to archive.admin.canonical.com.
  220 youngberry.canonical.com FTP server (Poppy Upload Server) ready.
  Name (archive.admin.canonical.com:foreman): anonymous
  331 Password required
  Password:
  230 Login Successful.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> bin
  200 Type set to Binary.
  ftp> prompt off
  Interactive mode off.
  ftp> put 80sr5fp16_20180524_01_ocdc.tar.gz
  local: 80sr5fp16_20180524_01_ocdc.tar.gz remote: 
80sr5fp16_20180524_01_ocdc.tar.gz
  200 PORT command successful.
  150 Opening Binary connection for /80sr5fp16_20180524_01_ocdc.tar.gz
  226 Transfer successful.
  651496332 bytes sent in 377.03 secs (1687.5 kB/s)
  ftp> quit
  221 Goodbye.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775641/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1775641] Re: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu

[Dimitri John Ledkov ]

** Package changed: ibm-java71 (Ubuntu) => ibm-java80 (Ubuntu)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1775641

Title:
  [Comm] IBM JDK 8.0.5.16 integration into Ubuntu

Status in Ubuntu on IBM z Systems:
  New
Status in ibm-java80 source package in Bionic:
  New

Bug description:
  foreman@cit7r02:~/sandbox/binary$ ftp archive.admin.canonical.com
  Connected to archive.admin.canonical.com.
  220 youngberry.canonical.com FTP server (Poppy Upload Server) ready.
  Name (archive.admin.canonical.com:foreman): anonymous
  331 Password required
  Password:
  230 Login Successful.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> bin
  200 Type set to Binary.
  ftp> prompt off
  Interactive mode off.
  ftp> put 80sr5fp16_20180524_01_ocdc.tar.gz
  local: 80sr5fp16_20180524_01_ocdc.tar.gz remote: 
80sr5fp16_20180524_01_ocdc.tar.gz
  200 PORT command successful.
  150 Opening Binary connection for /80sr5fp16_20180524_01_ocdc.tar.gz
  226 Transfer successful.
  651496332 bytes sent in 377.03 secs (1687.5 kB/s)
  ftp> quit
  221 Goodbye.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775641/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1663280] Re: Serious performance degradation of math functions

[Dimitri John Ledkov ]

zesty is EOL.
artful+ are fix released.

xenial is the only currently affected supported series.

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

** Changed in: glibc (Ubuntu Zesty)
   Status: Triaged => Won't Fix

** Changed in: glibc (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1663280

Title:
  Serious performance degradation of math functions

Status in GLibC:
  Fix Released
Status in glibc package in Ubuntu:
  Fix Released
Status in glibc source package in Xenial:
  New
Status in glibc source package in Zesty:
  Won't Fix
Status in glibc package in Fedora:
  Fix Released

Bug description:
  Bug [0] has been introduced in Glibc 2.23 [1] and fixed in Glibc 2.25
  [2]. All Ubuntu versions starting from 16.04 are affected because they
  use either Glibc 2.23 or 2.24. Bug introduces serious (2x-4x)
  performance degradation of math functions (pow, exp/exp2/exp10,
  log/log2/log10, sin/cos/sincos/tan, asin/acos/atan/atan2,
  sinh/cosh/tanh, asinh/acosh/atanh) provided by libm. Bug can be
  reproduced on any AVX-capable x86-64 machine.

  @strikov: According to a quite reliable source [5] all AMD CPUs and
  latest Intel CPUs (Skylake and Knights Landing) don't suffer from
  AVX/SSE transition penalty. It means that the scope of this bug
  becomes smaller and includes only the following generations of Intel's
  CPUs: Sandy Bridge, Ivy Bridge, Haswell, and Broadwell. Scope still
  remains quite large though.

  @strikov: Ubuntu 16.10/17.04 which use Glibc 2.24 may recieve the fix
  from upstream 2.24 branch (as Marcel pointed out, fix has been
  backported to 2.24 branch where Fedora took it successfully) if such
  synchronization will take place. Ubuntu 16.04 (the main target of this
  bug) uses Glibc 2.23 which hasn't been patched upstream and will
  suffer from performance degradation until we fix it manually.

  This bug is all about AVX-SSE transition penalty [3]. 256-bit YMM
  registers used by AVX-256 instructions extend 128-bit registers used
  by SSE (XMM0 is a low half of YMM0 and so on). Every time CPU executes
  SSE instruction after AVX-256 instruction it has to store upper half
  of the YMM register to the internal buffer and then restore it when
  execution returns back to AVX instructions. Store/restore is required
  because old-fashioned SSE knows nothing about the upper halves of its
  registers and may damage them. This store/restore operation is time
  consuming (several tens of clock cycles for each operation). To deal
  with this issue, Intel introduced AVX-128 instructions which operate
  on the same 128-bit XMM register as SSE but take into account upper
  halves of YMM registers. Hence, no store/restore required. Practically
  speaking, AVX-128 instructions is a new smart form of SSE instructions
  which can be used together with full-size AVX-256 instructions without
  any penalty. Intel recommends to use AVX-128 instructions instead of
  SSE instructions wherever possible. To sum things up, it's okay to mix
  SSE with AVX-128 and AVX-128 with AVX-256. Mixing AVX-128 with AVX-256
  is allowed because both types of instructions are aware of 256-bit YMM
  registers. Mixing SSE with AVX-128 is okay because CPU can guarantee
  that the upper halves of YMM registers don't contain any meaningful
  data (how one can put it there without using AVX-256 instructions) and
  avoid doing store/restore operation (why to care about random trash in
  the upper halves of the YMM registers). It's not okay to mix SSE with
  AVX-256 due to the transition penalty. Scalar floating-point
  instructions used by routines mentioned above are implemented as a
  subset of SSE and AVX-128 instructions. They operate on a small
  fraction of 128-bit register but still considered SSE/AVX-128
  instruction. And they suffer from SSE/AVX transition penalty as well.

  Glibc inadvertently triggers a chain of AVX/SSE transition penalties
  due to inappropriate use of AVX-256 instructions inside
  _dl_runtime_resolve() procedure. By using AVX-256 instructions to
  push/pop YMM registers [4], Glibc makes CPU think that the upper
  halves of XMM registers contain meaningful data which needs to be
  preserved during execution of SSE instructions. With such a 'dirty'
  flag set every switch between SSE and AVX instructions (AVX-128 or
  AVX-256) leads to a time consuming store/restore procedure. This
  'dirty' flag never gets cleared during the whole program execution
  which leads to a serious overall slowdown. Fixed implementation [2] of
  _dl_runtime_resolve() procedure tries to avoid using AVX-256
  instructions if possible.

  Buggy _dl_runtime_resolve() gets called every time when dynamic linker
  tries to resolve a symbol (any symbol, not just ones mentioned above).
  It's 

[Group.of.nepali.translators] [Bug 1748147] Re: [SRU] debhelper support override from /etc/tmpfiles.d for systemd

[Dimitri John Ledkov ]

Proposed fix in systemd. Run systemd-tmpfiles, during postinst, the way
it would be run on boot, such that all base files are correct, including
any overrides shipped by any other package; systemd; in transient
runtime dir.

At the same time, the dh_installinit is silenced to not produce the
systemd-tmpfiles snippet which this package does not need.

This solves the issue of integration with rsyslog; generically; without
requiring to backport debhelper, nor change rsyslog package.

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

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

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

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

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

** Patch added: "lp1748147.diff"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1748147/+attachment/5155096/+files/lp1748147.diff

** Changed in: debhelper (Ubuntu Bionic)
   Status: In Progress => Won't Fix

** Changed in: debhelper (Ubuntu Bionic)
 Assignee: Seyeong Kim (xtrusia) => (unassigned)

** Changed in: debhelper (Ubuntu Artful)
   Status: In Progress => Won't Fix

** Changed in: debhelper (Ubuntu Artful)
 Assignee: Seyeong Kim (xtrusia) => (unassigned)

** Changed in: debhelper (Ubuntu Xenial)
   Status: In Progress => Won't Fix

** Changed in: debhelper (Ubuntu Xenial)
 Assignee: Seyeong Kim (xtrusia) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1748147

Title:
  [SRU] debhelper support override from /etc/tmpfiles.d for systemd

Status in debhelper:
  Fix Released
Status in debhelper package in Ubuntu:
  Fix Released
Status in rsyslog package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Committed
Status in debhelper source package in Xenial:
  Won't Fix
Status in rsyslog source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Confirmed
Status in debhelper source package in Artful:
  Won't Fix
Status in rsyslog source package in Artful:
  Invalid
Status in systemd source package in Artful:
  Confirmed
Status in debhelper source package in Bionic:
  Won't Fix
Status in rsyslog source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  [Impact]

  /var/log's Permission is going back to 755
  after upgrading systemd
  if there are rsyslog's configuration on /var/lib/tmpfiles.d/

  Affected X, A, B, C

  This is because rsyslog's pkg has 00rsyslog.conf and copied it on 
/var/lib/tmpfiles.d/ when it is installing.
  after upgrading systemd, systemd only refresh it's own tmpfiles so disappear 
conf for 00rsyslog.conf ( it doesn't remove file itself )
  so, systemd-tmpfiles --create /var/lib/tmpfiles.d/00rsyslog.conf back 
permission to 775

  [Test Case]

  1. deploy 16.04 vm
  2. check ll /var (775)
  3. apt install --reinstall systemd
  4. check ll /var (755)

  [Regression Potential]
  This fix changes debhelper's override process by using absolute path to 
filename. so if the other pkgs using debhelper e.g systemd are there, It should 
be re-build with new debhelper after patching in theory, now only systemd is 
affected. but building is not affected. also, pkg like rsyslog which is using 
systemd's tmpfile system need to be changed to use 
/etc/tmpfiles.d/[SAME_FILENAME_IN_VAR_LIB_TMPFILES.D_FOR_OVERRIDING] instead of 
00rsyslog.conf.

  [Others]

  For this issue, need to fix below pkgs

  debhelper
  systemd ( rebuilding with new debhelper is needed )
  rsyslog ( 00rsyslog.conf to var.conf and location should be /etc/tmpfiles.d, 
to support override supported by debhelper )

  [Original description]

  Upgrading or reinstalling the systemd package when using rsyslogd
  results in bad permissions (0755 instead of 0775) being set on
  /var/log/. As a consequence of this, rsyslogd can no longer create new
  files within this directory, resulting in lost log messages.

  The default configuration of rsyslogd provided by Ubuntu runs the
  daemon as syslog:syslog and sets ownership of /var/log to syslog:adm
  with mode 0775.

  Systemd's default tmpfiles configuration sets /var/log to 0755 in
  /usr/lib/tmpfiles.d/var.conf, however this is overridden in
  /usr/lib/tmpfiles.d/00rsyslog.conf which is provided by package
  rsyslog.

  It looks as though an upgrade of the systemd package fails to take
  /usr/lib/tmpfiles.d/00rsyslog.conf into account, as demonstrated
  below. This results in /var/log receiving mode 0755 instead of the
  expected 0775:

  nick @ log2.be1.ams1:~ $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  Codename: xenial

  nick @ 

[Group.of.nepali.translators] [Bug 1777600] Re: chzdev can't find modprobe

[Dimitri John Ledkov ]

https://github.com/ibm-s390-tools/s390-tools/pull/31

** Also affects: s390-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: s390-tools (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Cosmic)
   Importance: High
 Assignee: Joseph Salisbury (jsalisbury)
   Status: Triaged

** Also affects: s390-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** No longer affects: linux (Ubuntu Cosmic)

** No longer affects: linux (Ubuntu Bionic)

** No longer affects: linux (Ubuntu Artful)

** No longer affects: linux (Ubuntu Xenial)

** Changed in: linux (Ubuntu)
   Status: Triaged => Invalid

** Changed in: ubuntu-z-systems
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Dimitri John 
Ledkov  (xnox)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1777600

Title:
  chzdev can't find modprobe

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  Invalid
Status in s390-tools package in Ubuntu:
  New
Status in s390-tools source package in Xenial:
  New
Status in s390-tools source package in Artful:
  New
Status in s390-tools source package in Bionic:
  New
Status in s390-tools source package in Cosmic:
  New

Bug description:
  Description:  only when trying to change some attributes chzdev fails because 
it cant find modprobe under Ubuntu 18.04

root@m83lp09:~# chzdev zfcp --type datarouter=0 dbflevel=5
sh: 1: /usr/sbin/modprobe: not found
zfcp device type configure failed
Error: Command failed (exit code 127): /usr/sbin/modprobe 
-r zfcp

root@m83lp09:~# whereis modprobe
modprobe: /sbin/modprobe /etc/modprobe.d /lib/modprobe.d 
/usr/share/man/man8/modprobe.8.gz



  Potential solution ? : adding a symlink is a workaround, is this path 
hardcoded?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1777600/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1748147] Re: [SRU] debhelper support override from /etc/tmpfiles.d for systemd

[Dimitri John Ledkov]

There are multiple bugs here.

I do not believe testcase of the rsyslog <-> systemd is wrong, and
whilst debhelper support is good, is not what would fix rsyslog <->
systemd in Ubuntu.

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

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1748147

Title:
  [SRU] debhelper support override from /etc/tmpfiles.d for systemd

Status in debhelper:
  Fix Released
Status in debhelper package in Ubuntu:
  Fix Released
Status in rsyslog package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in debhelper source package in Xenial:
  In Progress
Status in rsyslog source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in debhelper source package in Artful:
  In Progress
Status in rsyslog source package in Artful:
  New
Status in systemd source package in Artful:
  New
Status in debhelper source package in Bionic:
  In Progress
Status in rsyslog source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  [Impact]

  /var/log's Permission is going back to 755
  after upgrading systemd
  if there are rsyslog's configuration on /var/lib/tmpfiles.d/

  Affected X, A, B, C

  This is because rsyslog's pkg has 00rsyslog.conf and copied it on 
/var/lib/tmpfiles.d/ when it is installing.
  after upgrading systemd, systemd only refresh it's own tmpfiles so disappear 
conf for 00rsyslog.conf ( it doesn't remove file itself )
  so, systemd-tmpfiles --create /var/lib/tmpfiles.d/00rsyslog.conf back 
permission to 775

  [Test Case]

  1. deploy 16.04 vm
  2. check ll /var (775)
  3. apt install --reinstall systemd
  4. check ll /var (755)

  [Regression Potential]
  This fix changes debhelper's override process by using absolute path to 
filename. so if the other pkgs using debhelper e.g systemd are there, It should 
be re-build with new debhelper after patching in theory, now only systemd is 
affected. but building is not affected. also, pkg like rsyslog which is using 
systemd's tmpfile system need to be changed to use 
/etc/tmpfiles.d/[SAME_FILENAME_IN_VAR_LIB_TMPFILES.D_FOR_OVERRIDING] instead of 
00rsyslog.conf.

  [Others]

  For this issue, need to fix below pkgs

  debhelper
  systemd ( rebuilding with new debhelper is needed )
  rsyslog ( 00rsyslog.conf to var.conf and location should be /etc/tmpfiles.d, 
to support override supported by debhelper )

  [Original description]

  Upgrading or reinstalling the systemd package when using rsyslogd
  results in bad permissions (0755 instead of 0775) being set on
  /var/log/. As a consequence of this, rsyslogd can no longer create new
  files within this directory, resulting in lost log messages.

  The default configuration of rsyslogd provided by Ubuntu runs the
  daemon as syslog:syslog and sets ownership of /var/log to syslog:adm
  with mode 0775.

  Systemd's default tmpfiles configuration sets /var/log to 0755 in
  /usr/lib/tmpfiles.d/var.conf, however this is overridden in
  /usr/lib/tmpfiles.d/00rsyslog.conf which is provided by package
  rsyslog.

  It looks as though an upgrade of the systemd package fails to take
  /usr/lib/tmpfiles.d/00rsyslog.conf into account, as demonstrated
  below. This results in /var/log receiving mode 0755 instead of the
  expected 0775:

  nick @ log2.be1.ams1:~ $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  Codename: xenial

  nick @ log2.be1.ams1:~ $ apt policy systemd
  systemd:
    Installed: 229-4ubuntu21.1
    Candidate: 229-4ubuntu21.1
    Version table:
   *** 229-4ubuntu21.1 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  nick @ log2.be1.ams1:~ $ apt policy rsyslog
  rsyslog:
    Installed: 8.16.0-1ubuntu3
    Candidate: 8.16.0-1ubuntu3
    Version table:
   *** 8.16.0-1ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  nick @ log2.be1.ams1:~ $ grep -F /var/log /usr/lib/tmpfiles.d/var.conf
  d /var/log 0755 - - -
  f /var/log/wtmp 0664 root utmp -
  f /var/log/btmp 0600 root utmp -

  nick @ log2.be1.ams1:~ $ cat /usr/lib/tmpfiles.d/00rsyslog.conf
  # Override systemd's default tmpfiles.d/var.conf to make /var/log writable by
  # th

[Group.of.nepali.translators] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system

[Dimitri John Ledkov]

Removing systemd, as I believe there is nothing to be changed in systemd
for this fix to land.

Are the affected users fixed with the proposed kernel? Please test
proposed kernel asap! Otherwise the change will be dropped from the
kernel again on xenial =(

** No longer affects: systemd (Ubuntu)

** No longer affects: systemd (Ubuntu Xenial)

** No longer affects: systemd (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1726930

Title:
  System fails to start (boot) on battery due to read-only root file-
  system

Status in laptop-mode-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Fix Released
Status in laptop-mode-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed
Status in laptop-mode-tools source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Fix Released

Bug description:
  This report is to capture the extended diagnostic efforts done on IRC
  #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was
  upgraded from 17.04 to 17.10 and since fails to complete start-up of
  services when powered on battery.

  We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'"
  workaround in case this was an ACPI DSDT issue.

  This appears to be due to a read-only root file-system. What is not
  clear is how the rootfs goes read-only.

  The file-system (sda6, ext4) is fsck-ed successfully in the initrd
  according to the /run/initramfs/fsck.log.

  From the start-up logs (with "systemd.log_level=debug") we see the
  ext4 driver report a remount operation not once but five times.

  $ grep 'EXT4-fs.*sda6' systemd-debug.log
  Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered 
data mode. Opts: (null)
  Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro
  Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro,data=ordered,commit=600
  Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro,data=ordered,commit=600
  Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro,data=ordered,commit=600
  Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro,data=ordered,commit=600
  Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: 
errors=remount-ro,data=ordered,commit=600

  Those last five appear to be carrying options generated by laptop-
  mode-tools.

  User has disabled laptop-mode.service and laptop-mode.timer, and lmt-
  poll.service, but the issue remains.

  We see several reports of "read-only file-system":

  $ grep 'Read-only' systemd-debug.log
  Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open 
`/boot/grub/grubenv': Read-only file system.
  Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: 
Read-only file system
  Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to 
/var/log/gpu-manager.log failed (Read-only file system)
  Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 
'start' task: Read-only file system
  Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 
'start' task: Read-only file system
  Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: 
Read-only file system
  ...
  Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of 
"/var/log/cups" - Read-only file system
  Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file 
"/var/log/cups/access_log" - Read-only file system
  Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open 
/var/log/lastlog: Read-only file system

  We also see several problems with systemd's connection to Dbus:

  $ grep 'Transport endpoint' systemd-debug.log
  Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: 
Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit 
change signal for systemd-logind.service: Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: 
Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit 
change signal for lmt-poll.service: Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: 
Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: 
Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change 
signal for polkit.service: Transport endpoint is not connected
  Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send unit 
change signal for 

[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units

[Dimitri John Ledkov]

** Description changed:

  This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.
  
  Specifically, this is evident by e.g. $ systemd-run env. Or any other
  daemons that spawn shell scripts (e.g. cloud-init metadata acquired
  shell hooks, etc.).
+ 
+ Since v232 systemd provides support for environment generators, snapd
+ should package/ship a snippet that injects the correct snapd path into
+ systemd environment.
+ 
+ E.g.:
+ 
+ $ sudo mkdir -p /usr/lib/systemd/system-environment-generators
+ $ printf '#!/bin/sh\nPATH=$PATH:/snap/bin\n' | \
+ sudo tee /usr/lib/systemd/system-environment-generators/90-snapd
+ 
+ Something similar can be done for user-environment-generators too. Note
+ that user-environment-generators can generate unique variables per user.
+ 
+ Note please use /usr/lib path, as it appears that /lib/systemd path is
+ not working atm. Will check if that needs to be fixed up.

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

** Changed in: systemd (Ubuntu Cosmic)
   Status: New => Won't Fix

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

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

** Description changed:

  This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.
  
  Specifically, this is evident by e.g. $ systemd-run env. Or any other
  daemons that spawn shell scripts (e.g. cloud-init metadata acquired
  shell hooks, etc.).
  
  Since v232 systemd provides support for environment generators, snapd
  should package/ship a snippet that injects the correct snapd path into
  systemd environment.
  
  E.g.:
  
  $ sudo mkdir -p /usr/lib/systemd/system-environment-generators
  $ printf '#!/bin/sh\nPATH=$PATH:/snap/bin\n' | \
  sudo tee /usr/lib/systemd/system-environment-generators/90-snapd
  
  Something similar can be done for user-environment-generators too. Note
  that user-environment-generators can generate unique variables per user.
  
  Note please use /usr/lib path, as it appears that /lib/systemd path is
  not working atm. Will check if that needs to be fixed up.
+ 
+ systemd in xenial does not support system-environment-generators, thus
+ we probably need to upload a patch to change the DEFAULT_PATH compiled
+ in default there.

** Summary changed:

- /snap/bin not in default PATH for units
+ /snap/bin not in default PATH for units, snapd should ship 
system-environment-generators to inject /snap/bin into $PATH

** Description changed:

  This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.
  
  Specifically, this is evident by e.g. $ systemd-run env. Or any other
  daemons that spawn shell scripts (e.g. cloud-init metadata acquired
  shell hooks, etc.).
  
  Since v232 systemd provides support for environment generators, snapd
  should package/ship a snippet that injects the correct snapd path into
  systemd environment.
  
  E.g.:
  
  $ sudo mkdir -p /usr/lib/systemd/system-environment-generators
  $ printf '#!/bin/sh\nPATH=$PATH:/snap/bin\n' | \
  sudo tee /usr/lib/systemd/system-environment-generators/90-snapd
  
  Something similar can be done for user-environment-generators too. Note
  that user-environment-generators can generate unique variables per user.
  
  Note please use /usr/lib path, as it appears that /lib/systemd path is
  not working atm. Will check if that needs to be fixed up.
  
  systemd in xenial does not support system-environment-generators, thus
  we probably need to upload a patch to change the DEFAULT_PATH compiled
  in default there.
+ 
+ [Testcase]
+ 
+ $ systemd-run /usr/bin/env
+ $ journalctl -e | grep PATH
+ 
+ Output should contain /snap/bin

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771858

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in snapd source package in Xenial:
  New
Status in systemd source package in Xenial:
  Confirmed
Status in snapd source package in Bionic:
  New
Status in systemd source package in Bionic:
  Won't Fix
Status in snapd source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  Won't Fix

Bug description:
  This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

  Specifically, this is evident by e.g. $ systemd-run env. Or any other