[Group.of.nepali.translators] [Bug 1637379] Re: Hide 'Indicator Application' from Startup Applications
** 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
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 PowersTue, 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
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 PowersTue, 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
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 PowersTue, 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
** 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
** 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
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
** 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
** 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
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
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 DeslauriersThu, 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
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 DeslauriersThu, 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
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 VogtTue, 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, ...)
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 StrandbogeFri, 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
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 BryantWed, 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
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 JyrinkiMon, 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
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
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 MurrayThu, 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, ...)
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 HicksFri, 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
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 HicksFri, 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
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 HicksFri, 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
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 HicksFri, 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
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 HicksFri, 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
** 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
*** 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
** 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
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
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
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
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)
** 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
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
** 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)
** 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)
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
** 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 GrumbachDate: 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
** 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
** 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
** 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
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 NordahlWed, 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
** 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
** 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
** 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