[Group.of.nepali.translators] [Bug 1708245] Re: shim can't enable validation and enroll keys in one sitting

2018-01-26 Thread Launchpad Bug Tracker
This bug was fixed in the package grub2-signed - 1.89

---
grub2-signed (1.89) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu3. (LP: #1675453)

 -- Łukasz 'sil2100' Zemczak   Mon, 22 Jan
2018 09:40:19 +0100

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

** Changed in: grub2 (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/1708245

Title:
  shim can't enable validation and enroll keys in one sitting

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in shim package in Ubuntu:
  New
Status in shim-signed 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 shim source package in Xenial:
  New
Status in shim-signed source package in Xenial:
  Fix Committed
Status in grub2 source package in Zesty:
  New
Status in grub2-signed source package in Zesty:
  New
Status in shim source package in Zesty:
  New
Status in shim-signed source package in Zesty:
  New
Status in grub2 source package in Artful:
  Fix Committed
Status in grub2-signed source package in Artful:
  Fix Committed
Status in shim source package in Artful:
  New
Status in shim-signed source package in Artful:
  Fix Committed

Bug description:
  [Impact]

  
  [Test cases]
  First, update shim to the newest version.

  = Boot test =
  1) Reboot.
  2) Validate that the system boots correctly in UEFI mode.

  
  = Key enrollment =
  1) Create a new x.509 certificate to import into MOK.
  2) Run 'mokutil --import cert.der'
  3) Reboot
  4) Execute the steps described on screen to enroll the new key.

  
  = Toggling validation =
  1) Run 'mokutil --disable-validation'
  2) Reboot.
  3) Follow the steps on screen to toggle validation.
  4) Boot to the system, validate that validation is disabled:
  $ sudo hexdump -Cv /sys/firmware/efi/efivars/MokSBStateRT-*

  The output should read the last byte as a 1.

  5) Run 'mokutil --enable-validation'
  6) Reboot.
  7) Follow the steps on screen to toggle validation.
  8) Boot to the system, validate that validation is enabled again:
  $ hexdump -Cv /sys/firmware/efi/efivars/MokSBStateRT-*

  The file should not exist.

  
  = Toggling validation and enrolling =
  1) Disable validation, as above, and reboot into the system.
  2) Create a new x.509 certificate to import into MOK.
  3) Run 'mokutil --import cert.der'
  4) Run 'mokutil --enable-validation'
  5) Reboot.
  6) Follow the steps on screen to proceed through toggling validation in shim.
  Once that step is done, you should be returned to the MokManager menu to 
complete further steps.
  7) Follow the steps on screen to enroll the new key.
  Once completed, you should have the option at the bottom of the menu to 
Reboot.
  8) Reboot into the system.
  9) Validate that MOK validation is enabled and the new key is enrolled:

  Run:

  $ sudo hexdump -Cv /sys/firmware/efi/efivars/MokSBStateRT-*

  The file should not exist.

  Then run:
  $ sudo cat /proc/keys

  And make sure the key you enrolled is present.

  
  [Regression potential]
  Failure to boot or validate validly signed EFI binaries (bootloader) might be 
possible regressions. The shim update modifies the enrollment process for new 
keys, and as such it might also be possible for the enrollment of a new key to 
fail in MokManager, rendering the validation process unstable: it may fail to 
validate validly signed EFI binaries signed by keys already present in the 
database or that were to be enrolled.

  
  ---

  We want to enable validation and enroll a new key in shim all at the
  same time on upgrade from previous releases.

  Curently, shim will wipe out all pending variables when it's done
  processing one of them (because it wants to reboot immediately after
  that action). That means if we re-enable validation, we lose the
  request to enroll the key, and vice-versa.

  This needs fixing as it would otherwise badly impact upgrades from
  zesty and earlier; where we might have walked users through disabling
  validation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1708245/+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 1745247] Re: [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

2018-01-26 Thread Joseph Salisbury
** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

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

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

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

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

** Also affects: linux-azure-edge (Ubuntu Trusty)
   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/1745247

Title:
  [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  New
Status in linux-azure-edge package in Ubuntu:
  New
Status in linux source package in Trusty:
  New
Status in linux-azure source package in Trusty:
  New
Status in linux-azure-edge source package in Trusty:
  New
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in linux-azure-edge source package in Xenial:
  New
Status in linux source package in Artful:
  New
Status in linux-azure source package in Artful:
  New
Status in linux-azure-edge source package in Artful:
  New

Bug description:
  Anywhere where Meltdown fixes have gone in have likely also picked up
  upstream work on TLB flushes. This is an important performance change.

  x86/hyperv: Stop suppressing X86_FEATURE_PCIDx86/hyperv

  When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
  was deliberately suppressed as a precaution: back then PCID was never
  exposed to Hyper-V guests and it wasn't clear what will happen if some day
  it becomes available. The day came and PCID/INVPCID features are already
  exposed on certain Hyper-V hosts.

  From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with
  PCID. In particular the usage of PCID is per-cpu based: the same mm gets
  different CR3 values on different CPUs. If the hypercall does exact
  matching this will fail. However, this is not the case. David Zhang
  explains:

   "In practice, the AddressSpace argument is ignored on any VM that supports
PCIDs.

Architecturally, the AddressSpace argument must match the CR3 with PCID
bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
long mode). The flush hypercalls flush all PCIDs for the specified
AddressSpace."

  With this, PCID can be enabled.

  Upstream commit link:
  
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=04651dd978a8749e59065df14b970a127f219ac2

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1745247/+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 1745247] Re: [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

2018-01-26 Thread Marcelo Cerri
** No longer affects: linux-azure (Ubuntu Trusty)

** No longer affects: linux-azure (Ubuntu Artful)

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

** No longer affects: linux-azure-edge (Ubuntu Trusty)

** No longer affects: linux-azure-edge (Ubuntu Artful)

** No longer affects: linux-lts-xenial (Ubuntu Artful)

** No longer affects: linux-lts-vivid (Ubuntu Artful)

** No longer affects: linux-lts-vivid (Ubuntu)

** No longer affects: linux-lts-vivid (Ubuntu Trusty)

** No longer affects: linux-lts-vivid (Ubuntu Xenial)

** No longer affects: linux-lts-xenial (Ubuntu Xenial)

** No longer affects: linux-lts-xenial (Ubuntu Trusty)

** No longer affects: linux-lts-xenial (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/1745247

Title:
  [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  New
Status in linux-azure-edge package in Ubuntu:
  New
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in linux-azure-edge source package in Xenial:
  New

Bug description:
  Anywhere where Meltdown fixes have gone in have likely also picked up
  upstream work on TLB flushes. This is an important performance change.

  x86/hyperv: Stop suppressing X86_FEATURE_PCIDx86/hyperv

  When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
  was deliberately suppressed as a precaution: back then PCID was never
  exposed to Hyper-V guests and it wasn't clear what will happen if some day
  it becomes available. The day came and PCID/INVPCID features are already
  exposed on certain Hyper-V hosts.

  From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with
  PCID. In particular the usage of PCID is per-cpu based: the same mm gets
  different CR3 values on different CPUs. If the hypercall does exact
  matching this will fail. However, this is not the case. David Zhang
  explains:

   "In practice, the AddressSpace argument is ignored on any VM that supports
PCIDs.

Architecturally, the AddressSpace argument must match the CR3 with PCID
bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
long mode). The flush hypercalls flush all PCIDs for the specified
AddressSpace."

  With this, PCID can be enabled.

  Upstream commit link:
  
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=04651dd978a8749e59065df14b970a127f219ac2

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1745247/+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 1745247] Re: [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

2018-01-26 Thread Brad Figg
** Also affects: linux-lts-vivid (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux-lts-xenial (Ubuntu Artful)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

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

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

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

** Also affects: linux-azure-edge (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/1745247

Title:
  [Hyper-V] x86/hyperv: Stop suppressing X86_FEATURE_PCID

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  New
Status in linux-azure-edge package in Ubuntu:
  New
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in linux-azure-edge source package in Xenial:
  New

Bug description:
  Anywhere where Meltdown fixes have gone in have likely also picked up
  upstream work on TLB flushes. This is an important performance change.

  x86/hyperv: Stop suppressing X86_FEATURE_PCIDx86/hyperv

  When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
  was deliberately suppressed as a precaution: back then PCID was never
  exposed to Hyper-V guests and it wasn't clear what will happen if some day
  it becomes available. The day came and PCID/INVPCID features are already
  exposed on certain Hyper-V hosts.

  From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with
  PCID. In particular the usage of PCID is per-cpu based: the same mm gets
  different CR3 values on different CPUs. If the hypercall does exact
  matching this will fail. However, this is not the case. David Zhang
  explains:

   "In practice, the AddressSpace argument is ignored on any VM that supports
PCIDs.

Architecturally, the AddressSpace argument must match the CR3 with PCID
bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
long mode). The flush hypercalls flush all PCIDs for the specified
AddressSpace."

  With this, PCID can be enabled.

  Upstream commit link:
  
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=04651dd978a8749e59065df14b970a127f219ac2

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1745247/+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 1745260] Re: [Hyper-V] scsi: storvsc: Spread interrupts when picking a channel for I/O requests

2018-01-26 Thread Joseph Salisbury
** Also affects: linux-azure (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux-azure-edge (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/1745260

Title:
  [Hyper-V] scsi: storvsc: Spread interrupts when picking a channel for
  I/O requests

Status in linux-azure package in Ubuntu:
  In Progress
Status in linux-azure-edge package in Ubuntu:
  Confirmed
Status in linux-azure source package in Xenial:
  New
Status in linux-azure-edge source package in Xenial:
  New

Bug description:
  Update the algorithm in storvsc_do_io to look for a channel
  starting with the current CPU + 1 and wrap around (within the
  current NUMA node). This spreads VMbus interrupts more evenly
  across CPUs. Previous code always started with first CPU in
  the current NUMA node, skewing the interrupt load to that CPU.

  This should be applied to the linux-azure kernel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1745260/+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 1745261] Re: [Hyper-V] scsi: storvsc: Increase cmd_per_lun for higher speed devices

2018-01-26 Thread Joseph Salisbury
** Also affects: linux-azure (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/1745261

Title:
  [Hyper-V] scsi: storvsc: Increase cmd_per_lun for higher speed devices

Status in linux-azure package in Ubuntu:
  Confirmed
Status in linux-azure source package in Xenial:
  New

Bug description:
  Increase cmd_per_lun to allow more I/Os in progress per device,
  particularly for NVMe's.  The Hyper-V host side can handle the
  higher count with no issues.

  This patch should be applied to the linux-azure kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1745261/+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 1744968] Re: [SRU] Juju 2.3.2

2018-01-26 Thread Nicholas Skaggs
** Changed in: juju-core (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: juju-core (Ubuntu Artful)
   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/1744968

Title:
  [SRU] Juju 2.3.2

Status in juju-core package in Ubuntu:
  In Progress
Status in nplan package in Ubuntu:
  In Progress
Status in juju-core source package in Xenial:
  In Progress
Status in nplan source package in Xenial:
  In Progress
Status in juju-core source package in Artful:
  Invalid
Status in nplan source package in Artful:
  In Progress

Bug description:
  This syncs juju with the upstream release bringing the latest bugfixes
  and enhancements.

  [SRU Information]
  juju-core has a stable release exception, including for major version 
updates, https://wiki.ubuntu.com/JujuUpdates.

  [Impact]
  A full list of targeted bugs can be seen against the milestone, and the 
intervening milestones:

  https://launchpad.net/juju/+milestone/2.3.2

  [QA/Testing]
  Juju practices continuous integration and testing of the juju source tree. 
The results for this release can be seen here:

  http://qa.jujucharms.com/releases/6159

  In addition, juju has adt test coverage for all supported archs,
  http://autopkgtest.ubuntu.com/packages/j/juju-core/.

  Finally, manual verification and testing of the package has been done
  per https://wiki.ubuntu.com/JujuUpdates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1744968/+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 1642812] Re: USB devices are not closed when error occurs

2018-01-26 Thread Mario Limonciello
** Changed in: fwupd (Ubuntu Yakkety)
   Status: New => Won't Fix

** Changed in: fwupd (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/1642812

Title:
  USB devices are not closed when error occurs

Status in fwupd package in Ubuntu:
  Fix Released
Status in fwupd source package in Xenial:
  New
Status in fwupd source package in Yakkety:
  Won't Fix
Status in fwupd source package in Zesty:
  Fix Released

Bug description:
  In fwupd, a few of USB devices are not closed when there are some
  failures of operations. This issue will cause fwupd has some orphan
  USB nodes inside during fwupd is running. A orphan USB node might
  introduce memory leak and block some runtime power features as well.

  I proposed a upstream PR, and also put the link here.
  https://github.com/hughsie/fwupd/pull/73

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1642812/+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 1745488] Re: [SRU] New stable micro release 2.39

2018-01-26 Thread Sergio Schvezov
** Also affects: snapcraft (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: snapcraft (Ubuntu Artful)
   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/1745488

Title:
  [SRU] New stable micro release 2.39

Status in snapcraft package in Ubuntu:
  New
Status in snapcraft source package in Xenial:
  New
Status in snapcraft source package in Artful:
  New
Status in snapcraft source package in Bionic:
  New

Bug description:
  This is an SRU bug to release 2.39 of snapcraft which follows the
  guidelines defined in the wiki over at
  https://wiki.ubuntu.com/SnapcraftUpdates

  The list of bugs and features in this release are defined at
  https://github.com/snapcore/snapcraft/milestone/14?closed=1

  Releases since 2.35 and this one are defined at:
  https://github.com/snapcore/snapcraft/milestone/13?closed=1
  https://github.com/snapcore/snapcraft/milestone/12?closed=1
  https://github.com/snapcore/snapcraft/milestone/11?closed=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1745488/+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 1744166] Re: East-Saskatchewan timezone removed in latest tzdata

2018-01-26 Thread Łukasz Zemczak
** Also affects: php-sabre-vobject-3 (Ubuntu Artful)
   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/1744166

Title:
  East-Saskatchewan timezone removed in latest tzdata

Status in php-sabre-vobject-3 package in Ubuntu:
  Fix Released
Status in php-sabre-vobject-3 source package in Xenial:
  Fix Committed
Status in php-sabre-vobject-3 source package in Artful:
  New
Status in php-sabre-vobject-3 package in Debian:
  Fix Committed

Bug description:
  [Impact]

  * DEP8 tests for php-sabre-vobject-3 currently fail in 16.04 because
  the 2017c version of tzdata dropped the East-Saskatchewan timezone,
  which is hardcoded in the package.

  * This in turn blocks SRUs of new PHP7.0 microreleases.

  [Test Case]

  * Run the autopkgtests for this source package before and after the
  change. They should pass after.

  [Regression Potential]

  * None, this timezone is no longer valid in 16.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/php-sabre-vobject-3/+bug/1744166/+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 1738773] Please test proposed package

2018-01-26 Thread Łukasz Zemczak
Hello Amitkumar, or anyone else affected,

Accepted linux-firmware into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/linux-
firmware/1.157.16 in a few hours, and then in the -proposed repository.

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

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

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

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

** Changed in: linux-firmware (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/1738773

Title:
  Connection issue in Bluetooth SPP mode between a Dell Edge Gateway
  3000 and an HC-05 BT module attached to Arduino Uno

Status in linux package in Ubuntu:
  Invalid
Status in linux-firmware package in Ubuntu:
  New
Status in linux source package in Xenial:
  Fix Committed
Status in linux-firmware source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: Connection issue in Bluetooth SPP mode between a Dell Edge
  Gateway 3000 and an HC-05 BT module attached to Arduino Uno

  Fix: Updated firmware from Redpine containing a fix for the issue.

  Regression Potential: Below stress tests are conducted to ensure there is no 
regression with updated firmware
  BT mouse + BT keyboard
  BT mouse + BLE keyboard
  BT keyboard + BLE mouse
  BLE keyboard + BLE mouse
  BT mouse or keyboard + Wifi connected
  BT mouse + BT keyboard + WiFi connected
  BLE mouse + BLE keyboard + WiFi Connected
  BT mouse + BLE keyboard + Wifi connected
  BLE mouse + BT keyboard + Wifi connected
  (BT or BLE) mouse and/or (BT or BLE) keyboard + Wifi connected + Wifi Scan
  (BT or BLE) mouse and/or (BT or BLE) keyboard + Wifi connected + BT inquiry + 
BLE scan
  BT file transfer from mobile + WiFi connected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1738773/+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 1717224] Re: virsh start of virtual guest domain fails with internal error due to low default aio-max-nr sysctl value

2018-01-26 Thread ChristianEhrhardt
Hi Heinz-Werner,
thanks for the ping.

I think we agreed back then that the config itself is a Ubuntu wide
thing - but I haven't seen any discussions on procps or in general to
lift it. But then as I outlined in comment #7 any limit can be too low.
I'll set the KVM task to won't fix to clearly mark it as "not a kvm
task".

The fix that you need thou is the kernel change to account correctly - so that 
part of the question goes to the Kernel Team if the change that was proposed 
back then was actually released.
@Joseph - we clearly passed the number, but was the change released with it?


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

** No longer affects: kvm (Ubuntu Xenial)

** No longer affects: kvm (Ubuntu Zesty)

** No longer affects: kvm (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/1717224

Title:
  virsh start of virtual guest domain fails with internal error due to
  low default aio-max-nr sysctl value

Status in Ubuntu on IBM z Systems:
  In Progress
Status in kvm package in Ubuntu:
  Won't Fix
Status in linux package in Ubuntu:
  In Progress
Status in procps package in Ubuntu:
  New
Status in linux source package in Xenial:
  In Progress
Status in procps source package in Xenial:
  New
Status in linux source package in Zesty:
  In Progress
Status in procps source package in Zesty:
  New
Status in linux source package in Artful:
  In Progress
Status in procps source package in Artful:
  New

Bug description:
  Starting virtual guests via on Ubuntu 16.04.2 LTS installed with its
  KVM hypervisor on an IBM Z14 system LPAR fails on the 18th guest with
  the following error:

  root@zm93k8:/rawimages/ubu1604qcow2# virsh start zs93kag70038
  error: Failed to start domain zs93kag70038
  error: internal error: process exited while connecting to monitor: 
2017-07-26T01:48:26.352534Z qemu-kvm: -drive 
file=/guestimages/data1/zs93kag70038.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,aio=native:
 Could not open backing file: Could not set AIO state: Inappropriate ioctl for 
device

  The previous 17 guests started fine:

  root@zm93k8# virsh start zs93kag70020
  Domain zs93kag70020 started

  root@zm93k8# virsh start zs93kag70021
  Domain zs93kag70021 started

  .
  .

  root@zm93k8:/rawimages/ubu1604qcow2# virsh start zs93kag70036
  Domain zs93kag70036 started

  
  We ended up fixing the issue by adding the following line to /etc/sysctl.conf 
: 

  fs.aio-max-nr = 4194304

  ... then, reload the sysctl config file:

  root@zm93k8:/etc# sysctl -p /etc/sysctl.conf
  fs.aio-max-nr = 4194304

  
  Now, we're able to start more guests...

  root@zm93k8:/etc# virsh start zs93kag70036
  Domain zs93kag70036 started

  
  The default value was originally set to 65535: 

  root@zm93k8:/rawimages/ubu1604qcow2# cat /proc/sys/fs/aio-max-nr
  65536

  
  Note, we chose the 4194304 value, because this is what our KVM on System Z 
hypervisor ships as its default value.  Eg.  on our zKVM system: 

  [root@zs93ka ~]# cat /proc/sys/fs/aio-max-nr
  4194304

  ubuntu@zm93k8:/etc$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.04.2 LTS
  Release:16.04
  Codename:   xenial
  ubuntu@zm93k8:/etc$

  ubuntu@zm93k8:/etc$ dpkg -s qemu-kvm |grep Version
  Version: 1:2.5+dfsg-5ubuntu10.8

  Is something already documented for Ubuntu KVM users warning them about the 
low default value, and some guidance as to
  how to select an appropriate value?   Also, would you consider increasing the 
default aio-max-nr value to something much
  higher, to accommodate significantly more virtual guests?  

  Thanks!

  ---uname output---
  ubuntu@zm93k8:/etc$ uname -a Linux zm93k8 4.4.0-62-generic #83-Ubuntu SMP Wed 
Jan 18 14:12:54 UTC 2017 s390x s390x s390x GNU/Linux
   
  Machine Type = z14 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   See Problem Description.

  The problem was happening a week ago, so this may not reflect that
  activity.

  This file was collected on Aug 7, one week after we were hitting the
  problem.  If I need to reproduce the problem and get fresh data,
  please let me know.

  /var/log/messages doesn't exist on this system, so I provided syslog
  output instead.

  All data have been collected too late after the problem was observed
  over a week ago.  If you need me to reproduce the problem and get new
  data, please let me know.  That's not a problem.

  Also, we would have to make special arrangements for login access to
  these systems.  I'm happy to run traces and data collection for you as
  needed.  If that's not sufficient, then we'll explore log in access
  for you.

  Thanks...   - Scott G.

  
  I was able to successfully recreate the problem and captured / attached new 
debug docs. 

  Recreate