[Group.of.nepali.translators] [Bug 1637379] Re: Hide 'Indicator Application' from Startup Applications

2016-10-27 Thread Jeremy Bicha
** Also affects: indicator-application (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: indicator-application (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: indicator-application (Ubuntu Xenial)
   Importance: Undecided => Low

** Changed in: indicator-application (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: indicator-application (Ubuntu Yakkety)
   Importance: Undecided => Low

** Changed in: indicator-application (Ubuntu Yakkety)
   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/1637379

Title:
  Hide 'Indicator Application' from Startup Applications

Status in indicator-application package in Ubuntu:
  Triaged
Status in indicator-application source package in Xenial:
  Triaged
Status in indicator-application source package in Yakkety:
  Triaged

Bug description:
  Impact
  ==
  Ubuntu still ships the Startup Applications app.

  System autostart files like 'Indicator Application' should not show up
  in this app as we don't want users to unintentionally disable these
  services that easily.

  Test Case
  =
  Open Startup Applications and check for 'Indicator Application'

  Regression Potential
  
  This should be safe. We've been setting NoDisplay=true for stuff in 
/etc/xdg/autostart/ for years.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/1637379/+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 1636583] Re: SRU: Add zesty series link

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package debootstrap - 1.0.59ubuntu0.6

---
debootstrap (1.0.59ubuntu0.6) trusty; urgency=medium

  * Add (Ubuntu) zesty as a symlink to gutsy. (LP: #1636583)

 -- Joshua Powers   Tue, 25 Oct 2016 15:55:02
-0600

** Changed in: debootstrap (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

** Changed in: debootstrap (Ubuntu Xenial)
   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/1636583

Title:
  SRU: Add zesty series link

Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Precise:
  Fix Released
Status in debootstrap source package in Trusty:
  Fix Released
Status in debootstrap source package in Xenial:
  Fix Released
Status in debootstrap source package in Yakkety:
  Fix Released

Bug description:
  Add new link for Zesty Zapus.

  [Impact]

   * Users are unable to create Zesty Zapus chroots on older series.
   * Restricts and slows development.

  [Test Case]

   * sudo debootstrap zesty /tmp/zesty

  [Regression Potential]

   * Configuration only change, low chance of regression of existing 
functionality.
   * Change to packaging involves a new change log entry and an additional 
symlink to enable zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1636583/+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 1636583] Re: SRU: Add zesty series link

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package debootstrap - 1.0.78+nmu1ubuntu1.2

---
debootstrap (1.0.78+nmu1ubuntu1.2) xenial; urgency=medium

  * Add (Ubuntu) zesty as a symlink to gutsy. (LP: #1636583)

 -- Joshua Powers   Tue, 25 Oct 2016 13:37:00
-0600

** Changed in: debootstrap (Ubuntu Yakkety)
   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/1636583

Title:
  SRU: Add zesty series link

Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Precise:
  Fix Released
Status in debootstrap source package in Trusty:
  Fix Released
Status in debootstrap source package in Xenial:
  Fix Released
Status in debootstrap source package in Yakkety:
  Fix Released

Bug description:
  Add new link for Zesty Zapus.

  [Impact]

   * Users are unable to create Zesty Zapus chroots on older series.
   * Restricts and slows development.

  [Test Case]

   * sudo debootstrap zesty /tmp/zesty

  [Regression Potential]

   * Configuration only change, low chance of regression of existing 
functionality.
   * Change to packaging involves a new change log entry and an additional 
symlink to enable zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1636583/+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 1636583] Re: SRU: Add zesty series link

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package debootstrap - 1.0.40~ubuntu0.11

---
debootstrap (1.0.40~ubuntu0.11) precise; urgency=medium

  * Add (Ubuntu) zesty as a symlink to gutsy. (LP: #1636583)

 -- Joshua Powers   Tue, 25 Oct 2016 15:46:11
-0600

** Changed in: debootstrap (Ubuntu Precise)
   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/1636583

Title:
  SRU: Add zesty series link

Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Precise:
  Fix Released
Status in debootstrap source package in Trusty:
  Fix Released
Status in debootstrap source package in Xenial:
  Fix Released
Status in debootstrap source package in Yakkety:
  Fix Released

Bug description:
  Add new link for Zesty Zapus.

  [Impact]

   * Users are unable to create Zesty Zapus chroots on older series.
   * Restricts and slows development.

  [Test Case]

   * sudo debootstrap zesty /tmp/zesty

  [Regression Potential]

   * Configuration only change, low chance of regression of existing 
functionality.
   * Change to packaging involves a new change log entry and an additional 
symlink to enable zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1636583/+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 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

2016-10-27 Thread LaMont Jones
** Changed in: maas
   Status: Fix Released => In Progress

** Changed in: maas
 Assignee: (unassigned) => LaMont Jones (lamont)

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

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  In Progress
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
Status in klibc package in Debian:
  New

Bug description:
  initramfs' configure_networking function uses ipconfig to configure the 
network.
  ipconfig does not support dhcpv6.  See: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

  Related bugs:
    * bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) 

  
  [Impact]

  It is not possible to netboot Ubuntu with a network-based root
  filesystem in an ipv6-only environment.  Anyone wanting to netboot in
  an ipv6-only environment is affected.

  These uploads address this by replacing the one-off klibc dhcp client
  (IPv4-only) with the defacto standard isc-dhcp-client, and thereby
  provide both ipv6 and ipv4 DHCP configuration.

  [Test Case]

  See Bug 1229458.  Configure radvd, dhcpd, and tftpd for your ipv6-only
  netbooting world.  Pass the boot process an ipv6 address to talk to,
  and see it fail to configure the network.

  [Regression Potential]

  1) This increases the uncompressed initramfs size by approximately 500KB, 
since isc-dhcp-client is added, but klibc is still needed for some other 
things, and is therefore present.  On systems with a very small /boot 
partition, this could result in failure to upgrade the initramfs.
  2) In at least some cases, DHCP network configuration shifts from klibc's 
ipconfig to isc-dhcp-client's dhclient.  This should be of minimal risk, as 
isc-dhcp-client is in very very widespread use.  In the event of a regression, 
network boot would fail, but the prior kernel should still be bootable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1637300] Re: procps upgrades fail in a LXD container

2016-10-27 Thread dann frazier
** Bug watch added: Debian Bug tracker #827423
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827423

** Also affects: procps (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827423
   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/1637300

Title:
  procps upgrades fail in a LXD container

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  In Progress
Status in procps package in Debian:
  Unknown

Bug description:
  [Impact]
  procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

  [Test Case]
  $ lxc launch ubuntu:xenial procpstest
  Creating procpstest
  Starting procpstest
  $ lxc exec procpstest -- /bin/bash
  root@procpstest:~# apt --reinstall install procps
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
  Need to get 209 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
  Fetched 209 kB in 1s (113 kB/s)  
  (Reading database ... 25398 files and directories currently installed.)
  Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
  Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for systemd (229-4ubuntu11) ...
  Setting up procps (2:3.3.10-4ubuntu2) ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
  invoke-rc.d: initscript procps, action "start" failed.
  dpkg: error processing package procps (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   procps
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  root@procpstest:~#

  [Regression Risk]
  The proposed fix is to disable invoking the procps initscript on 
install/upgrade. This fix is already in yakkety, and I didn't find any bugs 
related to it in LP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1637300/+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 1637300] [NEW] procps upgrades fail in a LXD container

2016-10-27 Thread dann frazier
Public bug reported:

[Impact]
procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

[Test Case]
$ lxc launch ubuntu:xenial procpstest
Creating procpstest
Starting procpstest
$ lxc exec procpstest -- /bin/bash
root@procpstest:~# apt --reinstall install procps
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 209 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
Fetched 209 kB in 1s (113 kB/s)  
(Reading database ... 25398 files and directories currently installed.)
Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu11) ...
Setting up procps (2:3.3.10-4ubuntu2) ...
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing package procps (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 procps
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@procpstest:~#

[Regression Risk]
The proposed fix is to disable invoking the procps initscript on 
install/upgrade. This fix is already in yakkety, and I didn't find any bugs 
related to it in LP.

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

** Affects: procps (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

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

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

** Changed in: procps (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: procps (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: procps (Ubuntu Xenial)
   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/1637300

Title:
  procps upgrades fail in a LXD container

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  In Progress

Bug description:
  [Impact]
  procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

  [Test Case]
  $ lxc launch ubuntu:xenial procpstest
  Creating procpstest
  Starting procpstest
  $ lxc exec procpstest -- /bin/bash
  root@procpstest:~# apt --reinstall install procps
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
  Need to get 209 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
  Fetched 209 kB in 1s (113 kB/s)  
  (Reading database ... 25398 files and directories currently installed.)
  Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
  Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for systemd (229-4ubuntu11) ...
  Setting up procps (2:3.3.10-4ubuntu2) ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
  invoke-rc.d: initscript procps, action "start" failed.
  dpkg: error processing package procps (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   procps
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  root@procpstest:~#

  [Regression Risk]
  The proposed fix is to disable invoking the procps initscript on 

[Group.of.nepali.translators] [Bug 1636517] Re: zfs: importing zpool with vdev on zvol hangs kernel

2016-10-27 Thread Tim Gardner
** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

** Also affects: linux (Ubuntu Zesty)
   Importance: Medium
 Assignee: Colin Ian King (colin-king)
   Status: Triaged

** Also affects: zfs-linux (Ubuntu Zesty)
   Importance: Medium
 Assignee: Colin Ian King (colin-king)
   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/1636517

Title:
  zfs: importing zpool with vdev on zvol hangs kernel

Status in linux package in Ubuntu:
  Triaged
Status in zfs-linux package in Ubuntu:
  New
Status in linux source package in Xenial:
  New
Status in zfs-linux source package in Xenial:
  New
Status in linux source package in Yakkety:
  New
Status in zfs-linux source package in Yakkety:
  New
Status in linux source package in Zesty:
  Triaged
Status in zfs-linux source package in Zesty:
  New

Bug description:
  [SRU Request][Xenial][Yakkety]

  if a zvol of an existing, already imported zpool is a vdev of another
  zpool, a call to "zpool import" will everything zfs related. the stack
  trace is as follows:

  [] taskq_wait+0x74/0xe0 [spl]
  [] taskq_destroy+0x4b/0x100 [spl]
  [] vdev_open_children+0x12d/0x180 [zfs]
  [] vdev_root_open+0x3c/0xc0 [zfs]
  [] vdev_open+0xf5/0x4d0 [zfs]
  [] spa_load+0x39e/0x1c60 [zfs]
  [] spa_tryimport+0xad/0x450 [zfs]
  [] zfs_ioc_pool_tryimport+0x64/0xa0 [zfs]
  [] zfsdev_ioctl+0x44b/0x4e0 [zfs]
  [] do_vfs_ioctl+0x29f/0x490
  [] SyS_ioctl+0x79/0x90
  [] entry_SYSCALL_64_fastpath+0x16/0x71
  [] 0x

  [Fix]
  zfsutils-linux:

  Zesty: https://launchpadlibrarian.net/290907232/zfs-
  linux_0.6.5.8-0ubuntu4_0.6.5.8-0ubuntu5.diff.gz

  Yakkety, likewise
  Xenial, likewise

  Sync'd fixes into kernel repos, patches in:
  http://kernel.ubuntu.com/~cking/zfs-lp-1636517

  [Regression Potential]

  Minimal. This just touched one line in the zfs module
  module/zfs/zvol.cand a shim wrapper in include/linux/blkdev_compat.h

  Tested and passes with the ubuntu kernel team autotest client zfs
  regression tests.

  =

  I traced this back to 193fb6a2c94fab8eb8ce70a5da4d21c7d4023bee (erged
  in 4.4.0-6.21), which added a second parameter to lookup_bdev without
  patching the zfs module (which needs to special case the vdev-on-zvol
  case, and uses this exact method only in this special casing code
  path).

  attached you can find the output of "zfs send -R" ing such a zvol
  ("brokenvol.raw"), running "zfs receive POOL/TARGET < FILE" followed
  by "zpool import" should reproduce the hang.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-45-generic 4.4.0-45.66
  ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21
  Uname: Linux 4.4.0-45-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 25 15:46 seq
   crw-rw 1 root audio 116, 33 Oct 25 15:46 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  Date: Tue Oct 25 15:49:51 2016
  HibernationDevice: RESUME=/dev/mapper/xenial--vg-swap_1
  InstallationDate: Installed on 2016-10-25 (0 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  PciMultimedia:

  ProcFB: 0 qxldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-45-generic 
root=/dev/mapper/hostname--vg-root ro
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-45-generic N/A
   linux-backports-modules-4.4.0-45-generic  N/A
   linux-firmware1.157.4
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-2.7
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrrel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-2.7:cvnQEMU:ct1:cvrpc-i440fx-2.7:
  

[Group.of.nepali.translators] [Bug 1612006] Re: I2C touchpad does not work on AMD platform

2016-10-27 Thread Alex Hung
** Changed in: linux (Ubuntu)
   Status: Fix Released => In Progress

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Alex Hung (alexhung)

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

Title:
  I2C touchpad does not work on AMD platform

Status in HWE Next:
  In Progress
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress

Bug description:
  Recent AMD platform has problems with I2C touchpads because its GPIO
  controller is not configured correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1612006/+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 1636733] Re: [LTCTest] vfio_pci not loaded on Ubuntu 16.10 by default

2016-10-27 Thread Tim Gardner
https://lists.ubuntu.com/archives/kernel-team/2016-October/080626.html

** Changed in: linux (Ubuntu Yakkety)
   Status: New => In Progress

** Changed in: linux (Ubuntu Yakkety)
 Assignee: (unassigned) => Tim Gardner (timg-tpi)

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

** Changed in: kernel-package (Ubuntu Zesty)
 Assignee: Canonical Kernel Team (canonical-kernel-team) => (unassigned)

** No longer affects: kernel-package (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/1636733

Title:
  [LTCTest] vfio_pci not loaded on Ubuntu 16.10 by default

Status in linux package in Ubuntu:
  Fix Released
Status in kernel-package source package in Xenial:
  New
Status in linux source package in Xenial:
  In Progress
Status in kernel-package source package in Yakkety:
  New
Status in linux source package in Yakkety:
  In Progress
Status in kernel-package source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == Comment: #0 - SRIKANTH B. AITHAL  - 2016-10-26 
01:40:39 ==
  ---Problem Description---
  vfio_pci is not loaded by default on Ubuntu 16.10 host boot. All VFIO related 
tasks would fail without that module. For instance I was trying to boot guest 
with QEMU directly and it was failing complaining 
"/sys/bus/pci/drivers/vfio-pci/new_id" not present.

  root@c158f2u09os:~# lsmod | grep -i vfio
  root@c158f2u09os:~# modprobe vfio_pci <-- need to load explicitly
  root@c158f2u09os:~# lsmod | grep -i vfio
  vfio_pci   51735  0
  irqbypass   5567  1 vfio_pci
  vfio_iommu_spapr_tce14567  0
  vfio_virqfd 4859  1 vfio_pci
  vfio   31351  2 vfio_iommu_spapr_tce,vfio_pci
  vfio_spapr_eeh  3441  2 vfio_iommu_spapr_tce,vfio_pci

  Either 
  > we need to have these modules loaded by kernel by default 
  or 
  > we need to update https://wiki.ubuntu.com/ppc64el/CommonQuestions telling 
customers to load vfio_pci module explicitly before attempting any vfio tasks.
   
  Contact Information = Srikanth/bssrika...@in.ibm.com 
   
  ---uname output---
  Linux c158f2u09os 4.8.0-26-generic #28-Ubuntu SMP Tue Oct 18 14:41:40 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8247-22L 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. After booting into Ubuntu 16.10, see if vfio_pci modules are loaded:
  root@c158f2u09os:~# lsmod | grep -i vfio
  2. After that we need to manually load vfio_pci
  root@c158f2u09os:~# modprobe vfio_pci
  root@c158f2u09os:~#

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636733/+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 1637058] Re: nginx-common postinst execution fails when upgrading to or reinstalling 1.10.1-0ubuntu3

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package nginx - 1.10.1-0ubuntu1.2

---
nginx (1.10.1-0ubuntu1.2) yakkety-security; urgency=medium

  * SECURITY REGRESSION: postinst upgrade failure (LP: #1637058)
- debian/nginx-common.postinst: fix return code so script doesn't exit.

 -- Marc Deslauriers   Thu, 27 Oct 2016
10:14:26 -0400

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

** Changed in: nginx (Ubuntu Trusty)
   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/1637058

Title:
  nginx-common postinst execution fails when upgrading to or
  reinstalling 1.10.1-0ubuntu3

Status in nginx package in Ubuntu:
  Fix Committed
Status in nginx source package in Trusty:
  Fix Released
Status in nginx source package in Xenial:
  Fix Released
Status in nginx source package in Yakkety:
  Fix Released
Status in nginx source package in Zesty:
  Fix Committed
Status in nginx package in Debian:
  Unknown

Bug description:
  The first installation of the nginx-common on a system without nginx
  installed works fine, but attempting to reinstall it (or upgrade from
  a previous version of nginx-common) results in the post-install script
  exiting with status 1.  I attempted to debug this issue myself, but
  rapidly became lost in a maze of scripts calling each other.

  Luckily, the issue is easy to reproduce.  From a system without nginx
  installed:

  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  [sudo] password for michael: 
  Selecting previously unselected package nginx-common.
  (Reading database ... 414684 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → 
/lib/systemd/system/nginx.service.
  Processing triggers for systemd (231-9git1) ...
  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  (Reading database ... 414728 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) over (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  dpkg: error processing package nginx-common (--install):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for systemd (231-9git1) ...
  Errors were encountered while processing:
   nginx-common
  michael@mamarley-desktop:~/Downloads$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1637058/+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 1637058] Re: nginx-common postinst execution fails when upgrading to or reinstalling 1.10.1-0ubuntu3

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package nginx - 1.4.6-1ubuntu3.7

---
nginx (1.4.6-1ubuntu3.7) trusty-security; urgency=medium

  * SECURITY REGRESSION: config upgrade failure (LP: #1637058)
- debian/nginx-common.config: fix return code so script doesn't exit.

 -- Marc Deslauriers   Thu, 27 Oct 2016
10:42:53 -0400

** Changed in: nginx (Ubuntu Xenial)
   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/1637058

Title:
  nginx-common postinst execution fails when upgrading to or
  reinstalling 1.10.1-0ubuntu3

Status in nginx package in Ubuntu:
  Fix Committed
Status in nginx source package in Trusty:
  Fix Released
Status in nginx source package in Xenial:
  Fix Released
Status in nginx source package in Yakkety:
  Fix Released
Status in nginx source package in Zesty:
  Fix Committed
Status in nginx package in Debian:
  Unknown

Bug description:
  The first installation of the nginx-common on a system without nginx
  installed works fine, but attempting to reinstall it (or upgrade from
  a previous version of nginx-common) results in the post-install script
  exiting with status 1.  I attempted to debug this issue myself, but
  rapidly became lost in a maze of scripts calling each other.

  Luckily, the issue is easy to reproduce.  From a system without nginx
  installed:

  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  [sudo] password for michael: 
  Selecting previously unselected package nginx-common.
  (Reading database ... 414684 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → 
/lib/systemd/system/nginx.service.
  Processing triggers for systemd (231-9git1) ...
  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  (Reading database ... 414728 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) over (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  dpkg: error processing package nginx-common (--install):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for systemd (231-9git1) ...
  Errors were encountered while processing:
   nginx-common
  michael@mamarley-desktop:~/Downloads$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1637058/+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 1634236] Re: [SRU] Dependency on snap-confine too weak

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package snapd - 2.16+16.10ubuntu1.2

---
snapd (2.16+16.10ubuntu1.2) yakkety; urgency=medium

  * debian/control:
 - also add a dependency to "snap-confine" to unbreak armhf
   (LP: #1634236)

 -- Michael Vogt   Tue, 18 Oct 2016 20:29:56
+0200

** Changed in: snapd (Ubuntu Yakkety)
   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/1634236

Title:
  [SRU] Dependency on snap-confine too weak

Status in snapd package in Ubuntu:
  Confirmed
Status in snapd source package in Xenial:
  Fix Released
Status in snapd source package in Yakkety:
  Fix Released

Bug description:
  Trivial SRU of snapd that adds a missing versioned dependency for
  snap-confine to snapd.

  It turns out there is a regression because of this if:
  - you use an armhf architecture
  - snapd 2.16
  - snap-confine < 1.0.43

  The reason is that with snapd 2.16 we use the "snap run" to start 
applications. This is a command written in go. On armhf the auxv vector content 
is critical for successfully running go commands.
  But apparmor cleans that by default because it might be dangerous.
  On snap-confine 1.0.43 we added an apparmor rule to relax this.

  TEST CASE:
  - install snapd 2.16 on an armhf/classic system (e.g. pi2)
  - make sure you have snap-confine from xenial (not from xenial-updates): 
1.0.38
  - snap install hello
  - run "hello" and verify it does not run
  - install snap-confine from xenial-updates (1.0.43)
  - verify that "hello" does run now

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1634236/+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 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package im-config - 0.29-1ubuntu12.2

---
im-config (0.29-1ubuntu12.2) xenial-proposed; urgency=medium

  * debian/patches/use-distinguishable-abstract-address.patch: adjust
ibus-daemon args to include "--address 'unix:tmpdir=/tmp/ibus'" so it has
a mediatable abstract socket path (LP: #1580463)
  * debian/control: Breaks on apparmor << 2.10.95-0ubuntu2.3 since that
adjusts the ibus abstraction to allow applications to communicate with an
ibus-daemon started with "--address 'unix:tmpdir=/tmp/ibus'"

 -- Jamie Strandboge   Fri, 07 Oct 2016 11:37:31 +

** Changed in: im-config (Ubuntu Xenial)
   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/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

Status in apparmor package in Ubuntu:
  Fix Released
Status in im-config package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in im-config source package in Xenial:
  Fix Released
Status in snapd source package in Xenial:
  Fix Released
Status in apparmor source package in Yakkety:
  Fix Released
Status in im-config source package in Yakkety:
  Fix Released
Status in snapd source package in Yakkety:
  Fix Released

Bug description:
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.

  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.

  [Test Case]
  1. start a unity session before updating to the package in -proposed

  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76

  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM

  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before

  5. logout of unity, then log back in

  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e

  (notice '/tmp/ibus/' in the path)

  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...

  (notice '@/tmp/ibus/' in the path)

  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting
  'Text Entry'. From there, add an input source on the right, make sure
  'Show current input source in the menu bar' is checked, then use the
  input source panel indicator to change input sources.

  Extended test case to verify input support still works in unconfined
  and confined applications:

  1. Systems Settings Language Support, if prompted install the complete 
language support
  2. Install Chinese (simple and traditional)
  3. sudo apt-get install ibus-pinyin ibus-sunpinyin
  4. logout / login
  5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
  6. select pinyin from the indicator
  7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
  8. open gnome-calculator and try to type something in (should get a pop-up)
  9. open evince and try to search a pdf (should get a pop up)
  10. upgrade apparmor and im-config from xenial-proposed
  11. logout and back in
  12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/...
  13. open gnome-calculator and try to type something in (should get a pop-up)
  14. open evince and try to search a pdf (should get a pop up)
  15. verify no new apparmor denials

  [Regression Potential]

  The regression potential is considered low because there are no
  compiled code changes and because the changes only occur after ibus-
  daemon is restarted, which is upon session start, not package upgrade.
  When it is restarted, the files in ~/.config/ibus/bus/*-unix-0 are
  updated accordingly for other applications to pick up.

  This change intentionally requires a change to the 

[Group.of.nepali.translators] [Bug 1623107] Re: [SRU] python-pylxd 2.0.5

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package python-mock-services -
0.2-0ubuntu0.16.04.1

---
python-mock-services (0.2-0ubuntu0.16.04.1) xenial; urgency=medium

  [ Chuck Short ]
  * debian/python3-mock-services: Fix co-dependency install.
  * debian/control: Add dependency of python-nose.
  * Initial release (LP: #1623107).

 -- Corey Bryant   Wed, 12 Oct 2016 13:46:07
-0400

** Changed in: python-mock-services (Ubuntu Xenial)
   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/1623107

Title:
  [SRU] python-pylxd 2.0.5

Status in python-mock-services package in Ubuntu:
  Invalid
Status in python-pylxd package in Ubuntu:
  Invalid
Status in python-mock-services source package in Xenial:
  Fix Released
Status in python-pylxd source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  This SRU gets us to the latest pylxd point release for xenial.

  As of lxd 2.0.3, some changes to how lxd rest calls indicate
  successful responses changed from HTTP 200 to HTTP 202. This causes
  issues with pylxd.

  As long as lxd packages are updated in xenial, pylxd packages should
  also be updated.

  [Test Case]
  There are integration tests included with pylxd and can be run with:
  tox -e integration

  [Regresion Potential]
  Regression potential is minimal. This is a stable point release for the 
existing 2.0.0 version that is in xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-mock-services/+bug/1623107/+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 1622089] Re: timezone parser in qt-5.5 breaks KDE clock

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package qtbase-opensource-src - 5.5.1+dfsg-
16ubuntu7.2

---
qtbase-opensource-src (5.5.1+dfsg-16ubuntu7.2) xenial; urgency=medium

  * debian/patches/Fix-parsing-of-tzfile-5-POSIX-rule-zone-names-with-b.patch:
- Backport a timezone conversion fix from Qt 5.6.2 (LP: #1622089)

 -- Timo Jyrinki   Mon, 12 Sep 2016 05:49:32
+

** Changed in: qtbase-opensource-src (Ubuntu Xenial)
   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/1622089

Title:
  timezone parser in qt-5.5 breaks KDE clock

Status in qtbase-opensource-src package in Ubuntu:
  Fix Released
Status in qtbase-opensource-src source package in Xenial:
  Fix Released

Bug description:
  [ Impact ]

  People in certain timezones have buggy time conversions in all Qt
  apps.

  [ Test Case ]

  See bug report.

  [ Regression Potential ]

  Should be low, in upstream LTS release and includes unit tests during
  build time.

  --- original bug report ---

  For a set of timezones in tzdata-2016*
  Qt parser produces wrong result in
  Qt versions earlier than 5.6.

  In kubuntu-16.04 xenial xerus the most annoying
  issue is broken digital clock plasmoid on the default KDE panel
  if system timezone is set to e.g. Asia/Novosibirsk.
  All Qt programs that attempts to convert time to non-default
  timezone are affected as well in xenial and earlier ubuntu released
  including ubuntu-14.04 LTS trusty.

  I consider the bug is nasty enough for updating Qt in LTS ubuntu
  releases.

  The upstream bug is https://bugreports.qt.io/browse/QTBUG-53071
  "QTimeZone mishandles tzdata 2016b and later in Russia, Kazakhstan".
  The direct link to the patch that fixes the problem is
  
https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=patch;h=e9041c7fc1052167f1ec2df0ea9623059e55d00f

  I have rebuilt qtbase-opensource-src-5.5.1+dfsg (-16ubuntu7.1)
  from sources with the patch applied and the bug has gone away.

  A bit more details.

  I faced the problem with Kubuntu 16.04.1, x86_64.
  Asia/Novosibirsk has UTC+07:00 offset last a couple of months
  but KDE clock shows a time that has offset of 14 hours from the actual wall 
time,
  so it is rather unusable.
  Command line tool "date" reports correct local time.
  KDE digital clock works correctly in e.g. Asia/Krasnoyarsk timezone.
  It as a workaround if time transition history does not matter.

  Some other timezones affected by the bug (tzdata-2106f)
  file europe:
  Europe/Astrakhan
  Europe/Kirov
  Europe/Ulyanovsk
  Asia/Barnaul
  Asia/Novosibirsk
  Asia/Tomsk
  Asia/Novokuznetsk
  file asia:
  Asia/Almaty
  Asia/Qyzylorda
  Asia/Aqtobe
  Asia/Aqtau
  Asia/Oral

  A simple program to demonstrate the problem:

  #include 
  #include 
  #include 

  int main() {
  QTimeZone tz = QTimeZone(QTimeZone::systemTimeZoneId());
  QDateTime current = QDateTime::currentDateTime();
  qDebug() << "current offset" << tz.offsetFromUtc(current);
  return 0;
  }

  It reports 0 for incorrectly parsed timezones.

  The only thing that bothers me is that I had to disable tests
  when was rebuilding libqt5core5a_5.5.1+dfsg-16ubuntu7.1_amd64.deb
  using dpg-buildpackage. Otherwise I got error with cmake
  in tests/auto/cmake/. Cmake was unable to find qt libraries
  in the build tree.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1622089/+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 1637236] Re: New upstream microreleases 9.1.24, 9.3.15, 9.5.5

2016-10-27 Thread Martin Pitt
9.5.5 should hit Debian unstable RSN, will sync from there to zesty.

** Also affects: postgresql-9.5 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.1 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.1 (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.1 (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.1 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.1 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: postgresql-9.5 (Ubuntu Zesty)
   Status: New => Fix Committed

** No longer affects: postgresql-9.1 (Ubuntu Zesty)

** No longer affects: postgresql-9.1 (Ubuntu Yakkety)

** No longer affects: postgresql-9.1 (Ubuntu Xenial)

** Changed in: postgresql-9.1 (Ubuntu)
   Status: New => Invalid

** No longer affects: postgresql-9.3 (Ubuntu Precise)

** No longer affects: postgresql-9.3 (Ubuntu Xenial)

** No longer affects: postgresql-9.3 (Ubuntu Yakkety)

** No longer affects: postgresql-9.3 (Ubuntu Zesty)

** Changed in: postgresql-9.3 (Ubuntu)
   Status: New => Invalid

** No longer affects: postgresql-9.5 (Ubuntu Precise)

** No longer affects: postgresql-9.5 (Ubuntu Trusty)

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

Title:
  New upstream microreleases 9.1.24, 9.3.15, 9.5.5

Status in postgresql-9.1 package in Ubuntu:
  Invalid
Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Fix Committed
Status in postgresql-9.1 source package in Precise:
  New
Status in postgresql-9.1 source package in Trusty:
  New
Status in postgresql-9.3 source package in Trusty:
  New
Status in postgresql-9.5 source package in Xenial:
  New
Status in postgresql-9.5 source package in Yakkety:
  New
Status in postgresql-9.5 source package in Zesty:
  Fix Committed

Bug description:
  https://www.postgresql.org/about/news/1712/

  As per the standing micro-release exception these should land in
  stable Ubuntu releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/1637236/+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 1588479] Re: dkms_packages.py supported kernel check is not working

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package dkms - 2.2.0.3-1.1ubuntu5.14.04.9

---
dkms (2.2.0.3-1.1ubuntu5.14.04.9) trusty; urgency=medium

  * apport_name_in_valueerror.diff: (LP: #1588479)
- Check the ValueError from apport for the package name too, this prevents
  reporting of dkms crashes about unsupported kernels.

 -- Brian Murray   Thu, 15 Sep 2016 14:25:09 -0700

** Changed in: dkms (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

** Changed in: dkms (Ubuntu Xenial)
   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/1588479

Title:
  dkms_packages.py supported kernel check is not working

Status in dkms package in Ubuntu:
  Fix Released
Status in dkms source package in Trusty:
  Fix Released
Status in dkms source package in Xenial:
  Fix Released
Status in dkms source package in Yakkety:
  Fix Released

Bug description:
  Test Case
  -
  1) Look for some dkms package in /usr/src e.g. bbswitch-0.8
  2) Run python3 /usr/share/apport/package-hooks/dkms_packages.py -m bbswitch 
-v 0.8 -k 4.6.1-01234-lowlatency
  3) Observe a crash report dialog from apport for bbswitch

  With the version of apport from -proposed you will instead receive:

  ERROR (dkms apport): kernel package linux-
  headers-4.6.1-01234-lowlatency is not supported

  
  The apport package hook for dkms packages seems to have an error in its 
supported kernel check.  If the kernel is an unsupported one, the hook should 
exit with a return code of 1.  However, in the Ubuntu Error Tracker we can see 
some crashes with unsupported kernel versions e.g.:

  https://errors.ubuntu.com/oops/2733d742-284e-11e6-a745-fa163e839e11
  DKMSKernelVersion: 4.6.1-040601-lowlatency

  https://errors.ubuntu.com/oops/0a1afefc-253c-11e6-9082-fa163e192766
  DKMSKernelVersion: 4.6.0-040600-lowlatency

  If the intent really is to block creation of these reports, then let's
  do that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1588479/+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 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   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/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

Status in apparmor package in Ubuntu:
  Fix Released
Status in im-config package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in im-config source package in Xenial:
  Fix Committed
Status in snapd source package in Xenial:
  Fix Released
Status in apparmor source package in Yakkety:
  Fix Released
Status in im-config source package in Yakkety:
  Fix Released
Status in snapd source package in Yakkety:
  Fix Released

Bug description:
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.

  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.

  [Test Case]
  1. start a unity session before updating to the package in -proposed

  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76

  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM

  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before

  5. logout of unity, then log back in

  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e

  (notice '/tmp/ibus/' in the path)

  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...

  (notice '@/tmp/ibus/' in the path)

  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting
  'Text Entry'. From there, add an input source on the right, make sure
  'Show current input source in the menu bar' is checked, then use the
  input source panel indicator to change input sources.

  Extended test case to verify input support still works in unconfined
  and confined applications:

  1. Systems Settings Language Support, if prompted install the complete 
language support
  2. Install Chinese (simple and traditional)
  3. sudo apt-get install ibus-pinyin ibus-sunpinyin
  4. logout / login
  5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
  6. select pinyin from the indicator
  7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
  8. open gnome-calculator and try to type something in (should get a 

[Group.of.nepali.translators] [Bug 1614215] Re: "md5sums differ" message seems to indicate an install problem

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   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/1614215

Title:
  "md5sums differ" message seems to indicate an install problem

Status in AppArmor:
  Invalid
Status in Ubuntu GNOME:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in apparmor source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  Confusing output from a diff command executed during the apparmor update 
process leaves users concerned about the state of their system.

  [Test Case]
  1. Make sure that apparmor 2.10.95-0ubuntu2 from the -release pocket is 
installed

  2. Update to the apparmor package in -proposed

  3. Look at the output during the update process to verify that the
  following message is *not* printed:

Files /var/lib/dpkg/info/apparmor.md5sums and
  /var/lib/apparmor/profiles/.apparmor.md5sums differ

  [Regression Potential]
  Considered to be extremely low. The change is a one-liner that pipes the 
stdout of diff command to /dev/null (the -q option of diff is not sufficient).

  [Original description]

  Upon applying the latest Ubuntu routine-update, I observed these
  messages:

  Setting up apparmor (2.10.95-0ubuntu2.2) ...
  Installing new version of config file 
/etc/apparmor.d/abstractions/dbus-session-strict ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Skipping profile in /etc/apparmor.d/disable: usr.sbin.apache2
  Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
  Files /var/lib/dpkg/info/apparmor.md5sums and 
/var/lib/apparmor/profiles/.apparmor.md5sums differ

  "The reason why I am filing a bug report" is the LAST line.  I presume
  that if md5sums do not agree, something was probably done improperly
  in preparing this particular software-update blast.

  However, in-passing, I would also point out line #3, about "start and
  stop actions no longer supported." That seems to me to be something
  (of much less importance, obviously) that might have been overlooked.
  (I've seen =that= message for some time now.)

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apparmor 2.10.95-0ubuntu2.2
  ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
  Uname: Linux 4.4.0-34-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Wed Aug 17 14:22:55 2016
  InstallationDate: Installed on 2016-03-02 (168 days ago)
  InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release amd64 
(20151021)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-4.4.0-34-generic 
root=/dev/mapper/hostname--vg-root ro
  SourcePackage: apparmor
  Syslog:
   Aug 10 10:36:07 IntersignVM dbus[1638]: [system] AppArmor D-Bus mediation is 
enabled
   Aug 11 13:10:08 IntersignVM dbus[1655]: [system] AppArmor D-Bus mediation is 
enabled
   Aug 16 08:40:24 IntersignVM dbus[1693]: [system] AppArmor D-Bus mediation is 
enabled
   Aug 17 13:58:37 IntersignVM dbus[1657]: [system] AppArmor D-Bus mediation is 
enabled
  UpgradeStatus: Upgraded to xenial on 2016-05-11 (98 days ago)

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


[Group.of.nepali.translators] [Bug 1628285] Re: apparmor should be allowed to start in containers

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   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/1628285

Title:
  apparmor should be allowed to start in containers

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released

Bug description:
  [Impact]
  The kernel in xenial-proposed (4.4.0-46.67) and the lxd that has recently 
migrated from xenial-proposed (2.0.5-0ubuntu1~ubuntu16.04.1) allows us to 
enable stacked/namespaced AppArmor policy for lxd containers. This means that 
the container can have an overall confinement profile while still allowing 
individual processes inside of the container to have individual confinement 
profiles. This bug is for the apparmor userspace changes needed to allow the 
container init to load apparmor profiles during the container boot procedure.

  [Test Case]
  Install the kernel from xenial-proposed (4.4.0-46.67). Reboot into the new 
kernel and set up a new xenial lxd container (MUST be an unprivileged 
container):

   $ lxc start ubuntu:16.04 x

  Install apparmor from xenial-proposed (2.10.95-0ubuntu2.5) inside of
  the container and reboot the container.

  Verify that the container's dhclient is confined inside of an AppArmor
  namespace with a stacked profile that was loaded inside of the
  container:

  $ ps auxZ | grep 
'^lxd-x_//&:lxd-x_:///sbin/dhclient'
  lxd-x_//&:lxd-x_:///sbin/dhclient (enforce) 165536 
3889 0.0  0.0 16120 860 ? Ss 03:55   0:00 /sbin/dhclient -1 -v -pf 
/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df 
/var/lib/dhcp/dhclient6.eth0.leases eth0

  [Regression Potential]
  The regression potential is relatively high because processes inside of 
Ubuntu containers can be confined with an additional profile that is loaded 
inside of the container. However, this feature was released in Ubuntu 16.10 
with no known issues so far.

  [Original Description]

  Now that we have support for apparmor namespacing and stacking,
  unprivileged containers can and should be allowed to load apparmor
  profiles.

  The following changes are needed at least:
   - Change the systemd unit to remove the "!container" condition
   - Change the apparmor init script, replacing the current simple container 
check for something along the lines of:
  - If /proc/self/attr/current says "unconfined"
  - And /sys/kernel/security/apparmor/features/domain/stack contains "yes"
  - And /sys/kernel/security/apparmor/features/domain/version is 1.2 or 
higher
  - Then continue execing the script, otherwise exit 0

  John suggested he could add a file which would provide a more reliable
  way to do this check ^

  In either case, we need this change so that containers can behave more
  like normal systems as far as apparmor is concerned. That change
  should also be SRUed back to Xenial at the same time the kernel
  support for stacking is pushed.

  This bug is effectively a blocker for snapd inside LXD as without
  this, snap-confine and snapd itself will not be confined after
  container restart.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : 

[Group.of.nepali.translators] [Bug 1628745] Re: Change in kernel exec transition behavior causes regression tests to fail

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   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/1628745

Title:
  Change in kernel exec transition behavior causes regression tests to
  fail

Status in AppArmor:
  Fix Committed
Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * The exec_stack.sh regression test fails due to a behavior change in
  4.8 kernels from this patch:

     commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
     Author: Linus Torvalds 
     Date:   Mon Aug 22 16:41:46 2016 -0700

     binfmt_elf: switch to new creds when switching to new mm

   * Adjusting the regression tests appropriately allows the kernel and
  security teams to use QRT's test-apparmor.py to test kernel and
  userspace AppArmor changes with confidence

  [Test Case]

  $ apt-get source apparmor # make sure this fetches the new apparmor source
  $ sudo apt-get install libapparmor-dev
  $ cd tests/regression/apparmor
  $ make USE_SYSTEM=1
  $ sudo bash exec_stack.sh
  running exec_stack
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   608 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - file)' was expected 
to 'fail'. Reason for failure expect errno 13 != 139
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   610 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - otherfile)' was 
expected to 'fail'. Reason for failure expect errno 13 != 139
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   612 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - thirdfile)' was 
expected to 'fail'. Reason for failure expect errno 13 != 139
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   613 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - sharedfile)' was 
expected to 'pass'. Reason for failure 'killed by signal 11'
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   620 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - okcon)' was expected 
to 'pass'. Reason for failure 'killed by signal 11'
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   628 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - bad label)' was 
expected to 'fail'. Reason for failure 'killed by signal 11'
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   634 Segmentation fault  $testexec "$@" > $outfile 2>&1
  Error: transition failed. Test 'EXEC_STACK (2 stacked - bad mode)' was 
expected to 'fail'. Reason for failure 'killed by signal 11'
  
/tmp/testlibRpZj1Y/source/yakkety/apparmor-2.10.95/tests/regression/apparmor/prologue.inc:
 line 219:   741 Segmentation fault 

[Group.of.nepali.translators] [Bug 1630069] Re: Regression tests can not detect binfmt_elf mmpa semantic change

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   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/1630069

Title:
  Regression tests can not detect binfmt_elf mmpa semantic change

Status in AppArmor:
  Fix Committed
Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  New
Status in apparmor source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  == apparmor SRU ==

  [Impact]

   * The exec_stack.sh regression test fails due to a behavior change in 4.8
     kernels from this patch:

     commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
     Author: Linus Torvalds 
     Date: Mon Aug 22 16:41:46 2016 -0700

     binfmt_elf: switch to new creds when switching to new mm

   * The regression tests were fixed for this kernel change but they were fixed
     in a way that always assumed that kernel change is present. They should 
have
     been adjusted so that they act differently according to whether or not the
     kernel change is present (it is a change that could end up being backported
     through the stable trees).

  [Test Case]

   $ apt-get source apparmor # make sure this fetches the new apparmor source
   $ sudo apt-get install libapparmor-dev
   $ cd tests/regression/apparmor
   $ make USE_SYSTEM=1
   $ sudo bash exec_stack.sh

   The previous command should result in no output and return value of
  0.

  [Regression Potential]

   * This is an extremely low risk change since it only touches regression
     testing code that is not user-facing.

  [Other]

   * Fixed in upstream lp:apparmor tree:

     https://bazaar.launchpad.net/~apparmor-
  dev/apparmor/master/revision/3558

  == Original description ==

  The regression tests are currently hard coded to the semantics of mmap
  in binfmt_elf

  With the recent upstream commit
  9f834ec18defc369d73ccf9e87a2790bfa05bf46 the cred used for the mmap
  changed resulting in test failures. The tests have been patched for
  this change but it results in the test breaking for everyone using
  upstream releases against pre 4.8 kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1630069/+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 1620888] Re: NameError: global name '_LE' is not defined when running trove-guestagent

2016-10-27 Thread Corey Bryant
** Also affects: openstack-trove (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: openstack-trove (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/mitaka
   Importance: Undecided
   Status: New

** Changed in: cloud-archive
   Status: New => Invalid

** Changed in: openstack-trove (Ubuntu)
   Status: New => Invalid

** Changed in: cloud-archive/mitaka
   Status: New => Triaged

** Changed in: openstack-trove (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: cloud-archive/mitaka
   Importance: Undecided => High

** Changed in: openstack-trove (Ubuntu Xenial)
   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/1620888

Title:
  NameError: global name '_LE' is not defined when running trove-
  guestagent

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in openstack-trove package in Ubuntu:
  Invalid
Status in openstack-trove source package in Xenial:
  Triaged

Bug description:
  When we run trove-guestagent, it will throw exception as follow:

  2016-09-06 12:53:49.178 8485 CRITICAL root [-] NameError: global name '_LE' 
is not defined
  2016-09-06 12:53:49.178 8485 ERROR root Traceback (most recent call last):
  2016-09-06 12:53:49.178 8485 ERROR root   File 
"/usr/local/bin/trove-guestagent", line 10, in 
  2016-09-06 12:53:49.178 8485 ERROR root sys.exit(main())
  2016-09-06 12:53:49.178 8485 ERROR root   File 
"/usr/local/lib/python2.7/dist-packages/trove/cmd/guest.py", line 43, in main
  2016-09-06 12:53:49.178 8485 ERROR root msg = (_LE("Manager class not 
registered for datastore manager %s") %
  2016-09-06 12:53:49.178 8485 ERROR root NameError: global name '_LE' is not 
defined
  2016-09-06 12:53:49.178 8485 ERROR root

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1620888/+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 1637138] Re: The trove-guest agent service does not start on xenial

2016-10-27 Thread Corey Bryant
*** This bug is a duplicate of bug 1620888 ***
https://bugs.launchpad.net/bugs/1620888

I'm going to mark this as a dup of the bug that tracked the upstream
fix.

** No longer affects: cloud-archive/newton

** No longer affects: cloud-archive

** No longer affects: openstack-trove (Ubuntu Zesty)

** No longer affects: openstack-trove (Ubuntu Yakkety)

** This bug has been marked a duplicate of bug 1620888
   NameError: global name '_LE' is not defined when running trove-guestagent

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

Title:
  The trove-guest agent service does not start on xenial

Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in openstack-trove package in Ubuntu:
  Triaged
Status in openstack-trove source package in Xenial:
  Triaged

Bug description:
  When starting the trove guest agent on xenial it fails with:

  2016-10-27 09:31:38.674 1366 CRITICAL root [-] NameError: global name '_LE' 
is not defined
  2016-10-27 09:31:38.674 1366 ERROR root Traceback (most recent call last):
  2016-10-27 09:31:38.674 1366 ERROR root   File "/usr/bin/trove-guestagent", 
line 10, in 
  2016-10-27 09:31:38.674 1366 ERROR root sys.exit(main())
  2016-10-27 09:31:38.674 1366 ERROR root   File 
"/usr/lib/python2.7/dist-packages/trove/cmd/guest.py", line 48, in main
  2016-10-27 09:31:38.674 1366 ERROR root msg = (_LE("The guest_id 
parameter is not set. guest_info.conf "
  2016-10-27 09:31:38.674 1366 ERROR root NameError: global name '_LE' is not 
defined
  2016-10-27 09:31:38.674 1366 ERROR root 

  
  It seems to be missing:

  https://github.com/openstack/trove/blob/master/trove/cmd/guest.py#L27

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/mitaka/+bug/1637138/+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 1637058] Re: nginx-common postinst execution fails when upgrading to or reinstalling 1.10.1-0ubuntu3

2016-10-27 Thread Thomas Ward
** Also affects: nginx (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nginx (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: nginx (Ubuntu Trusty)
   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/1637058

Title:
  nginx-common postinst execution fails when upgrading to or
  reinstalling 1.10.1-0ubuntu3

Status in nginx package in Ubuntu:
  In Progress
Status in nginx source package in Trusty:
  Confirmed
Status in nginx source package in Xenial:
  Confirmed
Status in nginx source package in Yakkety:
  Confirmed
Status in nginx source package in Zesty:
  In Progress

Bug description:
  The first installation of the nginx-common on a system without nginx
  installed works fine, but attempting to reinstall it (or upgrade from
  a previous version of nginx-common) results in the post-install script
  exiting with status 1.  I attempted to debug this issue myself, but
  rapidly became lost in a maze of scripts calling each other.

  Luckily, the issue is easy to reproduce.  From a system without nginx
  installed:

  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  [sudo] password for michael: 
  Selecting previously unselected package nginx-common.
  (Reading database ... 414684 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → 
/lib/systemd/system/nginx.service.
  Processing triggers for systemd (231-9git1) ...
  michael@mamarley-desktop:~/Downloads$ sudo dpkg -i 
nginx-common_1.10.1-0ubuntu3_all.deb 
  (Reading database ... 414728 files and directories currently installed.)
  Preparing to unpack nginx-common_1.10.1-0ubuntu3_all.deb ...
  Unpacking nginx-common (1.10.1-0ubuntu3) over (1.10.1-0ubuntu3) ...
  Setting up nginx-common (1.10.1-0ubuntu3) ...
  dpkg: error processing package nginx-common (--install):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for systemd (231-9git1) ...
  Errors were encountered while processing:
   nginx-common
  michael@mamarley-desktop:~/Downloads$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1637058/+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 1630554] Re: QEMU throws failure msg while booting guest with SRIOV VF

2016-10-27 Thread Tim Gardner
https://lists.ubuntu.com/archives/kernel-team/2016-October/080621.html

** Changed in: linux (Ubuntu Yakkety)
   Status: New => In Progress

** Changed in: linux (Ubuntu Yakkety)
 Assignee: (unassigned) => Tim Gardner (timg-tpi)

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

** Changed in: linux (Ubuntu Zesty)
 Assignee: Taco Screen team (taco-screen-team) => (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/1630554

Title:
  QEMU throws failure msg while booting guest with SRIOV VF

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == Comment: #10 - VIPIN K. PARASHAR  - 2016-10-04 
02:39:30 ==
  (In reply to comment #9)
  > I took a quick look to this one and also noticed these 2 links:
  > https://bugzilla.redhat.com/show_bug.cgi?id=1237034
  > http://marc.info/?l=linux-kernel=143737274332400=2
  > and it looks like to avoid these message maybe just need to have this in
  > config file:
  > CONFIG_KVM_VFIO=y
  > I think we have that in powerkvm but not in Ubuntu KVM.

  On x86 running Ubuntu 16.04
  ==
  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.1 LTS
  Release:  16.04
  Codename: xenial
  $ head /proc/cpuinfo 
  processor : 0
  vendor_id : GenuineIntel
  cpu family: 6
  model : 61
  model name: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
  stepping  : 4
  microcode : 0x22
  cpu MHz   : 2300.179
  cache size: 3072 KB
  physical id   : 0
  $ uname -a
  Linux Workstation 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
  $ grep CONFIG_KVM_VFIO /boot/config-4.4.0-38-generic 
  CONFIG_KVM_VFIO=y
  $

  On PowerPC
   
  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu Yakkety Yak (development branch)
  Release:  16.10
  Codename: yakkety
  # head /proc/cpuinfo
  processor : 0
  cpu   : POWER8E (raw), altivec supported
  clock : 2061.00MHz
  revision  : 2.1 (pvr 004b 0201)

  processor : 1
  cpu   : POWER8E (raw), altivec supported
  clock : 2061.00MHz
  revision  : 2.1 (pvr 004b 0201)

  # uname -a
  Linux c158f2u09os 4.8.0-17-generic #19 SMP Thu Sep 29 12:03:21 CDT 2016 
ppc64le ppc64le ppc64le GNU/Linux
  # grep CONFIG_KVM_VFIO /boot/config-4.8.0-17-generic 
  #

  I see that CONFIG_KVM_VFIO is enabled on x86 running Ubuntu 16.04
  while ppc64 running 16.10 doesn't have it enabled.

  == Comment: #9 - Carol L. Soto  - 2016-09-30 16:25:32 ==
  I took a quick look to this one and also noticed these 2 links:
  https://bugzilla.redhat.com/show_bug.cgi?id=1237034
  http://marc.info/?l=linux-kernel=143737274332400=2
  and it looks like to avoid these message maybe just need to have this in 
config file:
  CONFIG_KVM_VFIO=y
  I think we have that in powerkvm but not in Ubuntu KVM.

  == Comment: #6 - VIPIN K. PARASHAR  - 2016-09-23 
06:50:22 ==
  $ git log 178a787502123b0 -1
  commit 178a787502123b01499c5a4617b94bb69ad49dd5
  Author: David Gibson 
  Date:   Mon Feb 1 11:14:15 2016 +1100

  vfio: Enable VFIO device for powerpc
  
  ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
  used to handle any necessary interactions between KVM and VFIO.
  
  Currently that device is built on x86 and ARM, but not powerpc, although
  powerpc does support both KVM and VFIO.  This makes things awkward in
  userspace
  
  Currently qemu prints an alarming error message if you attempt to use VFIO
  and it can't initialize the KVM VFIO device.  We don't want to remove the
  warning, because lack of the KVM VFIO device could mean coherency problems
  on x86.  On powerpc, however, the error is harmless but looks disturbing,
  and a test based on host architecture in qemu would be ugly, and break if
  we do need the KVM VFIO device for something important in future.
  
  There's nothing preventing the KVM VFIO device from being built for
  powerpc, so this patch turns it on.  It won't actually do anything, since
  we don't define any of the arch_*() hooks, but it will make qemu happy and
  we can extend it in future if we need to.
  
  Signed-off-by: David Gibson 
  Reviewed-by: Eric Auger 
  Signed-off-by: Paul Mackerras 
  $ 

  $ git describe --contains 178a787502123b

[Group.of.nepali.translators] [Bug 1630554] Re: QEMU throws failure msg while booting guest with SRIOV VF

2016-10-27 Thread Tim Gardner
https://lists.ubuntu.com/archives/kernel-team/2016-October/080620.html

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

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
 Assignee: Taco Screen team (taco-screen-team)
   Status: New

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

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Tim Gardner (timg-tpi)

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

Title:
  QEMU throws failure msg while booting guest with SRIOV VF

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == Comment: #10 - VIPIN K. PARASHAR  - 2016-10-04 
02:39:30 ==
  (In reply to comment #9)
  > I took a quick look to this one and also noticed these 2 links:
  > https://bugzilla.redhat.com/show_bug.cgi?id=1237034
  > http://marc.info/?l=linux-kernel=143737274332400=2
  > and it looks like to avoid these message maybe just need to have this in
  > config file:
  > CONFIG_KVM_VFIO=y
  > I think we have that in powerkvm but not in Ubuntu KVM.

  On x86 running Ubuntu 16.04
  ==
  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.1 LTS
  Release:  16.04
  Codename: xenial
  $ head /proc/cpuinfo 
  processor : 0
  vendor_id : GenuineIntel
  cpu family: 6
  model : 61
  model name: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
  stepping  : 4
  microcode : 0x22
  cpu MHz   : 2300.179
  cache size: 3072 KB
  physical id   : 0
  $ uname -a
  Linux Workstation 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
  $ grep CONFIG_KVM_VFIO /boot/config-4.4.0-38-generic 
  CONFIG_KVM_VFIO=y
  $

  On PowerPC
   
  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu Yakkety Yak (development branch)
  Release:  16.10
  Codename: yakkety
  # head /proc/cpuinfo
  processor : 0
  cpu   : POWER8E (raw), altivec supported
  clock : 2061.00MHz
  revision  : 2.1 (pvr 004b 0201)

  processor : 1
  cpu   : POWER8E (raw), altivec supported
  clock : 2061.00MHz
  revision  : 2.1 (pvr 004b 0201)

  # uname -a
  Linux c158f2u09os 4.8.0-17-generic #19 SMP Thu Sep 29 12:03:21 CDT 2016 
ppc64le ppc64le ppc64le GNU/Linux
  # grep CONFIG_KVM_VFIO /boot/config-4.8.0-17-generic 
  #

  I see that CONFIG_KVM_VFIO is enabled on x86 running Ubuntu 16.04
  while ppc64 running 16.10 doesn't have it enabled.

  == Comment: #9 - Carol L. Soto  - 2016-09-30 16:25:32 ==
  I took a quick look to this one and also noticed these 2 links:
  https://bugzilla.redhat.com/show_bug.cgi?id=1237034
  http://marc.info/?l=linux-kernel=143737274332400=2
  and it looks like to avoid these message maybe just need to have this in 
config file:
  CONFIG_KVM_VFIO=y
  I think we have that in powerkvm but not in Ubuntu KVM.

  == Comment: #6 - VIPIN K. PARASHAR  - 2016-09-23 
06:50:22 ==
  $ git log 178a787502123b0 -1
  commit 178a787502123b01499c5a4617b94bb69ad49dd5
  Author: David Gibson 
  Date:   Mon Feb 1 11:14:15 2016 +1100

  vfio: Enable VFIO device for powerpc
  
  ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
  used to handle any necessary interactions between KVM and VFIO.
  
  Currently that device is built on x86 and ARM, but not powerpc, although
  powerpc does support both KVM and VFIO.  This makes things awkward in
  userspace
  
  Currently qemu prints an alarming error message if you attempt to use VFIO
  and it can't initialize the KVM VFIO device.  We don't want to remove the
  warning, because lack of the KVM VFIO device could mean coherency problems
  on x86.  On powerpc, however, the error is harmless but looks disturbing,
  and a test based on host architecture in qemu would be ugly, and break if
  we do need the KVM VFIO device for something important in future.
  
  There's nothing preventing the KVM VFIO device from being built for
  powerpc, so this patch turns it on.  It won't actually do anything, since
  we don't define any of the arch_*() hooks, but it will make qemu happy and
  we can extend it in future if we need to.
  
  Signed-off-by: David Gibson 
  Reviewed-by: Eric Auger 

[Group.of.nepali.translators] [Bug 1578810] Re: Insensitive (disabled) toolbar icons in GTK3 are not dimmed

2016-10-27 Thread Brian Murray
Hello Marc-Andre, or anyone else affected,

Accepted ubuntu-themes into yakkety-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/ubuntu-
themes/16.10+16.10.20161024-0ubuntu1 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 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 to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

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

** Changed in: ubuntu-themes (Ubuntu Yakkety)
   Status: New => Fix Committed

** Tags added: verification-needed

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

** Changed in: ubuntu-themes (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/1578810

Title:
  Insensitive (disabled) toolbar icons in GTK3 are not dimmed

Status in remmina:
  Invalid
Status in Ubuntu theme:
  In Progress
Status in Wireshark:
  Invalid
Status in ubuntu-themes package in Ubuntu:
  Fix Released
Status in ubuntu-themes source package in Xenial:
  Fix Committed
Status in ubuntu-themes source package in Yakkety:
  Fix Committed

Bug description:
  [ Impact ]

  Disabled (GTK 3.20) and Insensitive (GTK <= 3.18) icons are not
  dimmed, therefore there is no visual indication that an icon in the
  toolbar is inactionable.

  [ Test Case ]

  This issue can be observed in Xenial and Yakkety.

  Install `gtk-3-examples` and run `gtk3-widget-factory`, look at the
  toolbar on Page 2, the last icon (tooltip 'Insert something') is
  disabled/insensitive and should be dimmed, but is not.

  After applying the relevant merge proposal (see below), the
  disabled/insensitive icon in the toolbar on Page 2 of gtk3-widgets-
  factory will now be dimmed.

  [ Regression Potential ]

  None.

  [ Other Info ]

  This issue can also be reproduced on Xenial and Yakkety using:

* Remmina (from the archive)
* Wireshark (from the archive)
* Eclipse (downloaded)

  To reproduce with Eclipse, Eclipse has to be downloaded since the
  version in the archive uses GTK2+ for styling, and dims insensitive
  icons correctly.

* Download a recent Eclipse 
https://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.5.2-201602121500/eclipse-SDK-4.5.2-linux-gtk-x86_64.tar.gz
* Extract and execute the "eclipse" executable
* In the toolbar, several icons look enabled even though they are not. For 
example the Save icon (Floppy).

To manage notifications about this bug go to:
https://bugs.launchpad.net/remmina/+bug/1578810/+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 1632538] Re: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova

2016-10-27 Thread Robie Basak
https://sources.debian.net/src/python-rfc3986/0.3.1-2/HISTORY.rst/ lists
the fixes from 0.2.2 and Zesty is synced from Debian's 0.3.1-2, so this
is fixed in Zesty.

** Changed in: python-rfc3986 (Ubuntu Zesty)
   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/1632538

Title:
  Using generate_service_certificate and undercloud_public_vip in
  undercloud.conf breaks nova

Status in OpenStack Compute (nova):
  Incomplete
Status in OpenStack Compute (nova) newton series:
  Incomplete
Status in tripleo:
  Triaged
Status in python-rfc3986 package in Ubuntu:
  Fix Released
Status in python-rfc3986 source package in Xenial:
  Fix Committed
Status in python-rfc3986 source package in Yakkety:
  Fix Committed
Status in python-rfc3986 source package in Zesty:
  Fix Released

Bug description:
  Enabling SSL on the Undercloud using generate_service_certificate
  results in all Nova services on the undercloud (api, cert, compute,
  conductor, scheduler), all failing with errors similar to the
  following:

  2016-10-11 22:28:27.327 66082 CRITICAL nova 
[req-b5f37af3-96fc-42e2-aaa6-52815aca07fe - - - - -] ConfigFileValueError: 
Value for option url is not valid: invalid URI: 
'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696'
  2016-10-11 22:28:27.327 66082 ERROR nova Traceback (most recent call last):
  2016-10-11 22:28:27.327 66082 ERROR nova   File "/usr/bin/nova-cert", line 
10, in 
  2016-10-11 22:28:27.327 66082 ERROR nova sys.exit(main())
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/nova/cmd/cert.py", line 49, in main
  2016-10-11 22:28:27.327 66082 ERROR nova service.wait()
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait
  2016-10-11 22:28:27.327 66082 ERROR nova _launcher.wait()
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait
  2016-10-11 22:28:27.327 66082 ERROR nova status, signo = 
self._wait_for_exit_or_signal()
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in 
_wait_for_exit_or_signal
  2016-10-11 22:28:27.327 66082 ERROR nova self.conf.log_opt_values(LOG, 
logging.DEBUG)
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2630, in 
log_opt_values
  2016-10-11 22:28:27.327 66082 ERROR nova _sanitize(opt, 
getattr(group_attr, opt_name)))
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3061, in __getattr__
  2016-10-11 22:28:27.327 66082 ERROR nova return self._conf._get(name, 
self._group)
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2672, in _get
  2016-10-11 22:28:27.327 66082 ERROR nova value = self._do_get(name, 
group, namespace)
  2016-10-11 22:28:27.327 66082 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2715, in _do_get
  2016-10-11 22:28:27.327 66082 ERROR nova % (opt.name, str(ve)))
  2016-10-11 22:28:27.327 66082 ERROR nova ConfigFileValueError: Value for 
option url is not valid: invalid URI: 
'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696'
  2016-10-11 22:28:27.327 66082 ERROR nova 

  I believe the failure happens inside the [neutron] section of
  /etc/nova/nova.conf.

  This does not look related to the scheme (https) being used as the
  result of enabling SSL because doing a one-off test with the
  openstack-nova-conductor service after changing the schema to http
  results in the same startup failure.

  Another one-off test substituting an IP address instead of a FQDN
  inside of nova.conf with the openstack-nova-conductor service as
  before results in openstack-nova-conductor starting properly but
  eventually failing with a connection-related failure due to the one-
  off data used (an IP address of 1.2.3.4).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1632538/+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 1634218] Re: [SRU] For Yakkety and Xenial (0.9)

2016-10-27 Thread Barry Warsaw
** Changed in: ubuntu-image (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/1634218

Title:
  [SRU] For Yakkety and Xenial (0.9)

Status in Ubuntu Image:
  Fix Released
Status in ubuntu-image package in Ubuntu:
  Fix Released
Status in ubuntu-image source package in Xenial:
  Fix Released
Status in ubuntu-image source package in Yakkety:
  Fix Released

Bug description:
  Tracking bug for SRU of ubuntu-image in Yakkety.  I plan to ask for an
  exception so that future uploads to 16.10 can track 17.04 Zesty.

  [Impact]

  ubuntu-image 0.8 fixes several problems found during actual use, including LP:
  #1632134 and LP: #1632085.  These two bugs, and a few other minor issues not
  tracked in Launchpad, affects users who try to build snappy images with
  ubuntu-image.  In particular, being able to set the image size is required for
  the common use case of being able to boot a virtual machine with the resulting
  built disk image.

  I am also asking for an SRU exception for ubuntu-image for several
  reasons:

  * snapd already has an SRU exception: https://wiki.ubuntu.com/SnapdUpdates
Because ubuntu-image is built on top of snapd (the latter which does the
communication with the store to get the gadget.yaml spec), it makes sense
for ubuntu-image to *also* have an exception.  The gadget.yaml specification
is still undergoing development as more use cases are identified, so
ubuntu-image will need to track changes in snapd.

  * ubuntu-image has no reverse dependencies.  It's a leaf package in universe
so changes to it will have very minimal impact.

  * ubuntu-image is a new tool.  People only started using it late in the
Yakkety release cycle so as it sees more use, changes will be likely.  It
doesn't make much sense to limit uploads, which will only serve to hobble
the tool in 16.10.

  * For now, we want ubuntu-image as released into 16.10, 17.04, and the snap
store to be closely aligned, so that all uses are identical.  You may wonder
why we want to upload it to both the snap store and the archive, but this is
useful since end-users may be more inclined to use the snap version, but
official images will use the archive version.

  [Test Case]

  The QA process for ubuntu-image releases is outlined here:
  https://wiki.ubuntu.com/UbuntuImageUpdates

  [Regression Potential]

  It is very unlikely, given the suite of tests we run, that the tool will
  regress.  More so, if it does, it should be very isolated in its effects, so
  it can be quickly fixed with no significant impact on the rest of the archive.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-image/+bug/1634218/+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 1635223] Re: please include mlx5_core modules in linux-image-generic package

2016-10-27 Thread Tim Gardner
https://lists.ubuntu.com/archives/kernel-team/2016-October/080618.html

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

** Also affects: linux (Ubuntu Zesty)
   Importance: Medium
   Status: Triaged

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

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Yakkety)
   Status: New => In Progress

** Changed in: linux (Ubuntu Zesty)
   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/1635223

Title:
  please include mlx5_core modules in linux-image-generic package

Status in cloud-images:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress
Status in linux source package in Zesty:
  Fix Released

Bug description:
  Because linux-image-generic pkg doesn't include mlx5_core,
  stock ubuntu cloud-images can't be used by VM guests using
  mellanox VFs, forcing the creation of an ad-hoc cloud image
  with added linux-image-extra-virtual

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1635223/+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 1637165] Re: Module sha1-mb fails to load

2016-10-27 Thread Tim Gardner
** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

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

Title:
  Module sha1-mb fails to load

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress

Bug description:
  The module sha1-mb always fails to load with "No such device":

  $ sudo modprobe sha1-mb
  modprobe: ERROR: could not insert 'sha1_mb': No such device

  This is a problem related to missing export/import functions and
  statesize in the algorithm definition. It's similar to the bug
  #1633058.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1637165/+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 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-10-27 Thread Martin Pitt
** Bug watch added: github.com/systemd/systemd/issues #4504
   https://github.com/systemd/systemd/issues/4504

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/4504
   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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in cloud-init source package in Xenial:
  New
Status in systemd source package in Xenial:
  Triaged

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  
  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
└─basic.target @11.403s
  └─sockets.target @11.401s
└─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
└─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
└─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
└─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
└─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
└─system.slice @783ms
  └─-.slice @721ms

  
  cloud-init would need networkd to run at or before 'networking.service' so it 
can raise networking to then find and use network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list 
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list 
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1636912/+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 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-10-27 Thread Martin Pitt
The "networkd after D-Bus" ordering was introduced in
https://github.com/systemd/systemd/commit/1346b1f038 and later refined
in https://github.com/systemd/systemd/commit/bcbca8291f .

So with the latter, removing this ordering would break the "UseHostname:
yes" flag (when you receive/set your host name from what DHCP gives
you), i. e. it would silently not work. We don't use that feature in the
distro itself, but it would be a shame to break it for everyone even
when cloud-init is not involved at all.

So this at least gives us a quick way out for 16.04 -- we can simply
drop the "After=dbus.service" from systemd-networkd.service without much
trouble, but for devel I'd at least discuss this with upstream.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Changed in: systemd (Ubuntu)
   Importance: High => Medium

** Changed in: systemd (Ubuntu Xenial)
   Importance: Undecided => High

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

** Changed in: cloud-init (Ubuntu)
 Assignee: Martin Pitt (pitti) => (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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in cloud-init package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in cloud-init source package in Xenial:
  New
Status in systemd source package in Xenial:
  Triaged

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  
  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
└─basic.target @11.403s
  └─sockets.target @11.401s
└─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
└─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
└─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
└─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
└─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
└─system.slice @783ms
  └─-.slice @721ms

  
  cloud-init would need networkd to run at or before 'networking.service' so it 
can raise networking to then find and use network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list 
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11 

[Group.of.nepali.translators] [Bug 1635091] Re: New firmware is required for some iwlwifi modules

2016-10-27 Thread Seth Forshee
** Also affects: linux-firmware (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: linux-firmware (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux-firmware (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux-firmware (Ubuntu Xenial)
 Assignee: (unassigned) => Jesse Sung (wenchien)

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

Title:
  New firmware is required for some iwlwifi modules

Status in HWE Next:
  In Progress
Status in linux-firmware package in Ubuntu:
  Fix Released
Status in linux-firmware source package in Xenial:
  In Progress

Bug description:
  Kernel complains about unable to load iwlwifi-7260-17.ucode.

  ubuntu@localhost:~$ dmesg | grep iwl
  [ 42.049462] iwlwifi :02:00.0: enabling device ( -> 0002)
  [ 42.074290] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-7260-17.ucode failed with error -2
  [ 42.376098] iwlwifi :02:00.0: loaded firmware version 16.242414.0 
op_mode iwlmvm
  [ 42.811854] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
7260, REV=0x144
  [ 42.815269] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
  [ 42.815530] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
  [ 43.078312] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'

  This file can be found in commit
  f2cf4d67e8eced29c8a473d3a27057aa2df57c42.

  commit f2cf4d67e8eced29c8a473d3a27057aa2df57c42
  Author: Emmanuel Grumbach 
  Date:   Sun Jul 10 09:25:42 2016 +0300

  iwlwifi: add new -17 firmware for iwlmvm devices

  Revision number: 352738
  Build number: WFFW28817_L14LIN

  This is the last firmware that supports 3160 / 7260 / 7265.
  Newer firmware will support 7265D and up only.

  Signed-off-by: Emmanuel Grumbach 

  Xenial only. These files are already in yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1635091/+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 1587261] Re: [SRU] Swift bucket X-Timestamp not set by Rados Gateway

2016-10-27 Thread James Page
** Also affects: cloud-archive/mitaka
   Importance: Undecided
   Status: New

** Changed in: cloud-archive
   Status: New => Invalid

** Changed in: cloud-archive/mitaka
   Status: New => Triaged

** Changed in: cloud-archive/mitaka
   Importance: Undecided => High

** Changed in: ceph (Ubuntu Zesty)
   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/1587261

Title:
  [SRU] Swift bucket X-Timestamp not set by Rados Gateway

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in ceph package in Ubuntu:
  Fix Released
Status in ceph source package in Xenial:
  New
Status in ceph source package in Yakkety:
  New
Status in ceph source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * A basic characteristic of a object store is the ability to create
     buckets and objects and to query for information about said
     buckets and objects.

   * In the current version of the ceph radosgw package it is not
     possible to get creation time for buckets. This is a serious
     defect and makes it impossible to use Ubuntu with ceph as a
     object store for some applications.

   * The issue has been fixed in upstream master

   * The proposed debdiff solves the issue by including patches cherry
     picked and adapted from upstream master branch fixing this issue.

  [Test Case]

   * Use Juju to deploy Ceph cluster with radosgw and relation to OpenStack
     Keystone. Example bundle: http://pastebin.ubuntu.com/23374308/

   * Install OpenStack Swift client

  sudo apt-get install python-swiftclient

   * Load OpenStack Credentials pointing to your test deployment

  wget 
https://raw.githubusercontent.com/openstack-charmers/openstack-bundles/master/development/shared/novarc
  . novarc

   * Create swift bucket

  swift post test

   * Display information about newly created bucket

  swift stat test

   * Observe that key 'X-Timestamp' has value 0.0

   * Delete bucket

  swift delete test

   * Install patched radosgw packages on 'ceph-radosgw' unit and repeat

   * Verify that key 'X-Timestamp' now has a value > 0.0 and corrensponding
 to the unixtime of when you created the bucket.

  [Regression Potential]

   * The patch is simple and I see little potential for any regression as a
     result of it being applied.

  [Original bug description]
  When creating a swift/radosgw bucket in horizon the bucket gets created, but 
shows up with a creation date of 19700101

  In the apache log one can observe

  curl -i http://10.11.140.241:80/swift/v1/bucket1 -I -H "X-Auth-Token:  ...
  Container HEAD failed: http://10.11.140.241:80/swift/v1/bucket1 404 Not Found

  However a manual curl call succeeds. Also the radosgw.log shows
  successful PUT/GET requests.

  I get similar results using the swift command line utility with
  containers inheriting a creation date of 19700101 even though I can
  see the correct date being passed to rados in the headers of the
  request.

  Also similarly issues with ceilometer intergration, similarly linked:

  2016-05-31 06:28:16.931 1117922 WARNING ceilometer.agent.manager [-] Continue 
after error from storage.containers.objects: Account GET failed: 
http://10.101.140.241:80/swift/v1/AUTH_025d6aa2af18415a87c012211edb7fea?format=json
 404 Not Found  [first 60 chars of response] 
{"Code":"NoSuchBucket","BucketName":"AUTH_025d6aa2af18415a87
  2016-05-31 06:28:16.931 1117922 ERROR ceilometer.agent.manager Traceback 
(most recent call last):

  This is using charm version: 86 against Openstack Mitaka

  This also seems pretty reproduceable with any ceph, ceph-rados and
  mitaka install via the juju charms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1587261/+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 1607153] Re: Mic mute key does not work for Ideapad laptops

2016-10-27 Thread Anthony Wong
** Changed in: hwe-next
   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/1607153

Title:
  Mic mute key does not work for Ideapad laptops

Status in HWE Next:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  When pressing mic mute key, there is no response and mic is not muted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1607153/+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 1637138] Re: The trove-guest agent service does not start on xenial

2016-10-27 Thread Corey Bryant
** Also affects: openstack-trove (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: openstack-trove (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: openstack-trove (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: openstack-trove (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: openstack-trove (Ubuntu Yakkety)
   Status: New => Triaged

** Changed in: openstack-trove (Ubuntu Zesty)
   Status: New => Triaged

** Changed in: openstack-trove (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: openstack-trove (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: openstack-trove (Ubuntu Zesty)
   Importance: Undecided => High

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Changed in: cloud-archive
   Status: New => Triaged

** Changed in: cloud-archive
   Importance: Undecided => High

** Also affects: cloud-archive/newton
   Importance: High
   Status: Triaged

** Also affects: cloud-archive/mitaka
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/mitaka
   Status: New => Triaged

** Changed in: cloud-archive/mitaka
   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/1637138

Title:
  The trove-guest agent service does not start on xenial

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in Ubuntu Cloud Archive newton series:
  Triaged
Status in openstack-trove package in Ubuntu:
  Triaged
Status in openstack-trove source package in Xenial:
  Triaged
Status in openstack-trove source package in Yakkety:
  Triaged
Status in openstack-trove source package in Zesty:
  Triaged

Bug description:
  When starting the trove guest agent on xenial it fails with:

  2016-10-27 09:31:38.674 1366 CRITICAL root [-] NameError: global name '_LE' 
is not defined
  2016-10-27 09:31:38.674 1366 ERROR root Traceback (most recent call last):
  2016-10-27 09:31:38.674 1366 ERROR root   File "/usr/bin/trove-guestagent", 
line 10, in 
  2016-10-27 09:31:38.674 1366 ERROR root sys.exit(main())
  2016-10-27 09:31:38.674 1366 ERROR root   File 
"/usr/lib/python2.7/dist-packages/trove/cmd/guest.py", line 48, in main
  2016-10-27 09:31:38.674 1366 ERROR root msg = (_LE("The guest_id 
parameter is not set. guest_info.conf "
  2016-10-27 09:31:38.674 1366 ERROR root NameError: global name '_LE' is not 
defined
  2016-10-27 09:31:38.674 1366 ERROR root 

  
  It seems to be missing:

  https://github.com/openstack/trove/blob/master/trove/cmd/guest.py#L27

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1637138/+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 1587261] Re: [SRU] Swift bucket X-Timestamp not set by Rados Gateway

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package ceph - 10.2.3-0ubuntu3

---
ceph (10.2.3-0ubuntu3) zesty; urgency=medium

  * rgw: Fixes for creation times for buckets (LP: #1587261).
- d/p/rgw_rados-creation_time.patch: Backport fix from upstream master.
  - Fix logic error that leads to creation time being 0 instead of current
time when creating buckets.

 -- Frode Nordahl   Wed, 26 Oct 2016
14:39:55 +0200

** Changed in: ceph (Ubuntu Zesty)
   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/1587261

Title:
  [SRU] Swift bucket X-Timestamp not set by Rados Gateway

Status in Ubuntu Cloud Archive:
  New
Status in ceph package in Ubuntu:
  Fix Released
Status in ceph source package in Xenial:
  New
Status in ceph source package in Yakkety:
  New
Status in ceph source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * A basic characteristic of a object store is the ability to create
     buckets and objects and to query for information about said
     buckets and objects.

   * In the current version of the ceph radosgw package it is not
     possible to get creation time for buckets. This is a serious
     defect and makes it impossible to use Ubuntu with ceph as a
     object store for some applications.

   * The issue has been fixed in upstream master

   * The proposed debdiff solves the issue by including patches cherry
     picked and adapted from upstream master branch fixing this issue.

  [Test Case]

   * Use Juju to deploy Ceph cluster with radosgw and relation to OpenStack
     Keystone. Example bundle: http://pastebin.ubuntu.com/23374308/

   * Install OpenStack Swift client

  sudo apt-get install python-swiftclient

   * Load OpenStack Credentials pointing to your test deployment

  wget 
https://raw.githubusercontent.com/openstack-charmers/openstack-bundles/master/development/shared/novarc
  . novarc

   * Create swift bucket

  swift post test

   * Display information about newly created bucket

  swift stat test

   * Observe that key 'X-Timestamp' has value 0.0

   * Delete bucket

  swift delete test

   * Install patched radosgw packages on 'ceph-radosgw' unit and repeat

   * Verify that key 'X-Timestamp' now has a value > 0.0 and corrensponding
 to the unixtime of when you created the bucket.

  [Regression Potential]

   * The patch is simple and I see little potential for any regression as a
     result of it being applied.

  [Original bug description]
  When creating a swift/radosgw bucket in horizon the bucket gets created, but 
shows up with a creation date of 19700101

  In the apache log one can observe

  curl -i http://10.11.140.241:80/swift/v1/bucket1 -I -H "X-Auth-Token:  ...
  Container HEAD failed: http://10.11.140.241:80/swift/v1/bucket1 404 Not Found

  However a manual curl call succeeds. Also the radosgw.log shows
  successful PUT/GET requests.

  I get similar results using the swift command line utility with
  containers inheriting a creation date of 19700101 even though I can
  see the correct date being passed to rados in the headers of the
  request.

  Also similarly issues with ceilometer intergration, similarly linked:

  2016-05-31 06:28:16.931 1117922 WARNING ceilometer.agent.manager [-] Continue 
after error from storage.containers.objects: Account GET failed: 
http://10.101.140.241:80/swift/v1/AUTH_025d6aa2af18415a87c012211edb7fea?format=json
 404 Not Found  [first 60 chars of response] 
{"Code":"NoSuchBucket","BucketName":"AUTH_025d6aa2af18415a87
  2016-05-31 06:28:16.931 1117922 ERROR ceilometer.agent.manager Traceback 
(most recent call last):

  This is using charm version: 86 against Openstack Mitaka

  This also seems pretty reproduceable with any ceph, ceph-rados and
  mitaka install via the juju charms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1587261/+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 1587261] Re: [SRU] Swift bucket X-Timestamp not set by Rados Gateway

2016-10-27 Thread Edward Hope-Morley
** Changed in: ceph (Ubuntu Zesty)
   Status: Fix Released => 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/1587261

Title:
  [SRU] Swift bucket X-Timestamp not set by Rados Gateway

Status in Ubuntu Cloud Archive:
  New
Status in ceph package in Ubuntu:
  In Progress
Status in ceph source package in Xenial:
  New
Status in ceph source package in Yakkety:
  New
Status in ceph source package in Zesty:
  In Progress

Bug description:
  [Impact]

   * A basic characteristic of a object store is the ability to create
     buckets and objects and to query for information about said
     buckets and objects.

   * In the current version of the ceph radosgw package it is not
     possible to get creation time for buckets. This is a serious
     defect and makes it impossible to use Ubuntu with ceph as a
     object store for some applications.

   * The issue has been fixed in upstream master

   * The proposed debdiff solves the issue by including patches cherry
     picked and adapted from upstream master branch fixing this issue.

  [Test Case]

   * Use Juju to deploy Ceph cluster with radosgw and relation to OpenStack
     Keystone. Example bundle: http://pastebin.ubuntu.com/23374308/

   * Install OpenStack Swift client

  sudo apt-get install python-swiftclient

   * Load OpenStack Credentials pointing to your test deployment

  wget 
https://raw.githubusercontent.com/openstack-charmers/openstack-bundles/master/development/shared/novarc
  . novarc

   * Create swift bucket

  swift post test

   * Display information about newly created bucket

  swift stat test

   * Observe that key 'X-Timestamp' has value 0.0

   * Delete bucket

  swift delete test

   * Install patched radosgw packages on 'ceph-radosgw' unit and repeat

   * Verify that key 'X-Timestamp' now has a value > 0.0 and corrensponding
 to the unixtime of when you created the bucket.

  [Regression Potential]

   * The patch is simple and I see little potential for any regression as a
     result of it being applied.

  [Original bug description]
  When creating a swift/radosgw bucket in horizon the bucket gets created, but 
shows up with a creation date of 19700101

  In the apache log one can observe

  curl -i http://10.11.140.241:80/swift/v1/bucket1 -I -H "X-Auth-Token:  ...
  Container HEAD failed: http://10.11.140.241:80/swift/v1/bucket1 404 Not Found

  However a manual curl call succeeds. Also the radosgw.log shows
  successful PUT/GET requests.

  I get similar results using the swift command line utility with
  containers inheriting a creation date of 19700101 even though I can
  see the correct date being passed to rados in the headers of the
  request.

  Also similarly issues with ceilometer intergration, similarly linked:

  2016-05-31 06:28:16.931 1117922 WARNING ceilometer.agent.manager [-] Continue 
after error from storage.containers.objects: Account GET failed: 
http://10.101.140.241:80/swift/v1/AUTH_025d6aa2af18415a87c012211edb7fea?format=json
 404 Not Found  [first 60 chars of response] 
{"Code":"NoSuchBucket","BucketName":"AUTH_025d6aa2af18415a87
  2016-05-31 06:28:16.931 1117922 ERROR ceilometer.agent.manager Traceback 
(most recent call last):

  This is using charm version: 86 against Openstack Mitaka

  This also seems pretty reproduceable with any ceph, ceph-rados and
  mitaka install via the juju charms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1587261/+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 1589905] Re: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] is not supported

2016-10-27 Thread Anthony Wong
** Changed in: hwe-next
   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/1589905

Title:
  Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e]
  is not supported

Status in HWE Next:
  Fix Released
Status in linux-firmware package in Ubuntu:
  Fix Released
Status in linux-firmware source package in Xenial:
  Fix Released
Status in linux-firmware source package in Yakkety:
  Fix Released

Bug description:
  Firmware for this card isn't in the current linux-firmware package.
  Latest upstream firmware is also tested but doesn't work either.

  The only working firmware is extracted from Windows driver. By
  comparing the md5sum, the only different file is
  ath10k/QCA6174/hw3.0/board.bin (upstream is cb37c6, and Windows is
  df5ba1), we need Qualcomm to upstream the file to fix this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1589905/+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 1587261] Re: [SRU] Swift bucket X-Timestamp not set by Rados Gateway

2016-10-27 Thread Frode Nordahl
** Changed in: ceph (Ubuntu Zesty)
   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/1587261

Title:
  [SRU] Swift bucket X-Timestamp not set by Rados Gateway

Status in Ubuntu Cloud Archive:
  New
Status in ceph package in Ubuntu:
  Fix Released
Status in ceph source package in Xenial:
  New
Status in ceph source package in Yakkety:
  New
Status in ceph source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * A basic characteristic of a object store is the ability to create
     buckets and objects and to query for information about said
     buckets and objects.

   * In the current version of the ceph radosgw package it is not
     possible to get creation time for buckets. This is a serious
     defect and makes it impossible to use Ubuntu with ceph as a
     object store for some applications.

   * The issue has been fixed in upstream master

   * The proposed debdiff solves the issue by including patches cherry
     picked and adapted from upstream master branch fixing this issue.

  [Test Case]

   * Use Juju to deploy Ceph cluster with radosgw and relation to OpenStack
     Keystone. Example bundle: http://pastebin.ubuntu.com/23374308/

   * Install OpenStack Swift client

  sudo apt-get install python-swiftclient

   * Load OpenStack Credentials pointing to your test deployment

  wget 
https://raw.githubusercontent.com/openstack-charmers/openstack-bundles/master/development/shared/novarc
  . novarc

   * Create swift bucket

  swift post test

   * Display information about newly created bucket

  swift stat test

   * Observe that key 'X-Timestamp' has value 0.0

   * Delete bucket

  swift delete test

   * Install patched radosgw packages on 'ceph-radosgw' unit and repeat

   * Verify that key 'X-Timestamp' now has a value > 0.0 and corrensponding
 to the unixtime of when you created the bucket.

  [Regression Potential]

   * The patch is simple and I see little potential for any regression as a
     result of it being applied.

  [Original bug description]
  When creating a swift/radosgw bucket in horizon the bucket gets created, but 
shows up with a creation date of 19700101

  In the apache log one can observe

  curl -i http://10.11.140.241:80/swift/v1/bucket1 -I -H "X-Auth-Token:  ...
  Container HEAD failed: http://10.11.140.241:80/swift/v1/bucket1 404 Not Found

  However a manual curl call succeeds. Also the radosgw.log shows
  successful PUT/GET requests.

  I get similar results using the swift command line utility with
  containers inheriting a creation date of 19700101 even though I can
  see the correct date being passed to rados in the headers of the
  request.

  Also similarly issues with ceilometer intergration, similarly linked:

  2016-05-31 06:28:16.931 1117922 WARNING ceilometer.agent.manager [-] Continue 
after error from storage.containers.objects: Account GET failed: 
http://10.101.140.241:80/swift/v1/AUTH_025d6aa2af18415a87c012211edb7fea?format=json
 404 Not Found  [first 60 chars of response] 
{"Code":"NoSuchBucket","BucketName":"AUTH_025d6aa2af18415a87
  2016-05-31 06:28:16.931 1117922 ERROR ceilometer.agent.manager Traceback 
(most recent call last):

  This is using charm version: 86 against Openstack Mitaka

  This also seems pretty reproduceable with any ceph, ceph-rados and
  mitaka install via the juju charms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1587261/+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