ssh -c 3des-cbc host also works for me as well. And adding this to my
ssh config makes it automatic
Host *
Ciphers 3des-cbc
btw, this is only a problem through my cisco openconnect VPN. Different
VPNs don't have this issue.
--
You received this bug notification because you are a member of
Public bug reported:
1)
root@oil-maas-node-2:~# lsb_release -rd
Description:Ubuntu 12.04.4 LTS
Release:12.04
2)
root@oil-maas-node-2:~# apt-cache policy gdisk
gdisk:
Installed: 0.8.1-1build1
Candidate: 0.8.1-1build1
Version table:
*** 0.8.1-1build1 0
500
Public bug reported:
1) % lsb_release -rd
Description:Ubuntu Utopic Unicorn (development branch)
Release:14.10
2) % apt-cache policy uvtool-libvirt
uvtool-libvirt:
Installed: 0~bzr92-0ubuntu1
Candidate: 0~bzr92-0ubuntu1
Version table:
*** 0~bzr92-0ubuntu1 0
500
It takes 164 seconds in cloud init to bring up the first machine.
What's the outer VM config (resources), likewise, what's the host
machine resource level?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
Summary
---
Add-machine: Wed May 28 14:31:56 UTC 2014 (0)
KVM Ssh'able:Wed May 28 14:33:15 UTC 2014 (+79)
Cloud-init done: Wed May 28 14:35:14 UTC 2014 (+119)
Juju status started: Wed May 28 14:35:38 UTC 2014 (+24)
Total time: 222 seconds: 3 min, 40 seconds.
One modification to the outer KVM that may help here:
adding --unsafe-cache to your first level KVM will use host ram to cache
guest writes to the qcow2 image -- this means what it means, if kill
your VMs or host machine has power failure, you'll lose data.With
that in place the same test
For the reproducers, something worth trying is to use to try is external
snapshots (instead of internal which the snapshot-create-as does without
flags).
instead run: snapshot-create-as --disk-only
which will basically do qemu-img create -b your_original_qcow2 -f qcow2
pristine
And store the
I've been running the scripts from comment #10. I have two VMs each
running simultaneously; I've completed 24 hours of this sequence, about
50 total cycles with zero errors in the qcow2 images.
We're missing something; possibly hardware specific?
Host machine is an Intel NUC on Trusty.
Linux
I'm also starting work on updating uvt to use external snapshots
instead; this would be an alternative to use while chasing down the bug
in internal snapshots.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
Public bug reported:
I have a host with kvm loaded and after creating a container and
installing the qemu package, /dev/kvm doesn't exist. If I create it
manually qemu runs fine.
The upstart job should detect that it's in a container and create
/dev/kvm for use.
** Affects: qemu (Ubuntu)
** Changed in: qemu (Ubuntu)
Importance: Undecided = High
** Changed in: qemu (Ubuntu)
Status: New = In Progress
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) = Ryan Harper (raharper)
--
You received this bug notification because you are a member of Ubuntu
Server Team
Public bug reported:
1.
$ lsb_release -rd
Description:Ubuntu 14.04 LTS
Release:14.04
2.
$ apt-cache policy python-novaclient
python-novaclient:
Installed: 1:2.17.0-0ubuntu1
Candidate: 1:2.17.0-0ubuntu1
Version table:
*** 1:2.17.0-0ubuntu1 0
500
can we confirm what filesystems and options are enabled when reproducing
(ie, ext4 +extent mapping)[1] ? Bug 1368815 sounds very much like this.
If the reproducing systems have ext4 extents mapping enabled, one could
create an ext4 fs without extent mapping[2] and see if this still
reproduces.
With the updated 2.0.0+dfsg-2ubuntu1.8 package in trusty/proposed, the
test-case still fails as written.
After upgrading qemu-kvm, qemu-system-common qemu-system-x86 from
trusty/proposed, no /dev/kvm exists even though /etc/init/qemu-kvm.conf
includes the updated script to write it out. This is
I don't think the fix is adequate since it requires an extra manual
step, rather, I think the packaging should (if possible) trigger the
upstart job to stop and then start again... Otherwise, anyone upgrading
this (or installing it on top of a system with qemu-kvm already
installed in a
On Fri, Jan 23, 2015 at 10:16 PM, Chris J Arges 1414...@bugs.launchpad.net
wrote:
#!/bin/bash
# 2015 Chris J Arges chris.j.ar...@canonical.com
# Detect if we are running inside KVM
NESTED_VM=0
VM_STRINGS=KVM QEMU VMware VirtualBox Xen
VM_DETECT=$(dmesg | egrep -e '(Hypervisor
There's nothing preventing nested guests architectually IIUC. I don't know
that anyone has implemented it yet but seems reasonable to thing ahead and
avoid x86isms where possible.
On Sat, Jan 24, 2015 at 3:27 PM, Chris J Arges 1414...@bugs.launchpad.net
wrote:
Ryan,
I don't think Power8/kvm
This issue should be fixed in the qemu-kvm version included in precise.
** Changed in: qemu-kvm (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
Hi,
Are you running ntp in the host or timekeeping in the guest? If so, is
the guest clock close to what current time should be?
Also, can you try adding this option:
-global mc146818rtc.lost_tick_policy=slew
--
You received this bug notification because you are a member of Ubuntu
Server
I think you'll find that nested kvm and ksm will be a worst-case
scenario w.r.t memory swap-out. KSM actively scans the hosts memory for
pages it can unmap , which means when a guest (level 1) or nested guest
(level 2) needs to write to that memory, then you incur a page table
walk (Guest virtual
Any information about the physical host running the L1 guest?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1413540
Title:
issues with KSM enabled for nested KVM VMs
To manage
Shame that virt.c isn't a standalone tool that could be reused.
On Thu, Jan 29, 2015 at 9:54 AM, Chris J Arges 1414...@bugs.launchpad.net
wrote:
FWIW, here is the systemd-virt-detect code used to detect if we are
running on a virt platform.
One method that's pretty solid for QEMU (save folks who pass in custom DMI
table values to qemu) is the BIOS data available via dmidecode (or
/sysfs/dmi); would need to look at Power and arm for equivalent (likely
some device tree bits in /sysfs). Openstack exports a BIOS manufacture of
On Wed, Mar 18, 2015 at 12:59 PM, Roderick Smith rod.sm...@canonical.com
wrote:
This is not a bug in sgdisk; it's either a bug in the charm or an
incorrect use of same. Specifically, the sgdisk command shown is:
sgdisk --zap-all --clear --mbrtogpt /dev/vdb
This command does four things, in
On Fri, Mar 20, 2015 at 1:02 PM, Roderick Smith rod.sm...@canonical.com
wrote:
Examining the code, there are several sgdisk calls, but two are relevant
for this discussion. The first is the one reproduced in this initial bug
report:
sgdisk --zap-all --clear --mbrtogpt
This call does not
On trusty with qemu-2.0 I can't get the blind input to work at all, it
appears that enter in -curses mode (among other keyboard inputs seems
broken.
To isolate the issue, I tried a trusty-server iso, same issue. Then I
tried this ttylinux image:
Something's up with the installer itself. I can reproduce the issue on
Lucid which is older than ttylinux kernel. To confirm the -curses and
keyboard input works correctly, I appended BOOT_DEBUG=3 (during the
blind typing steps) after console=ttyS0
Then on the serial console page, I get a
And appending DEBIAN_FRONTEND=text works perfectly fine over serial
console.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1427829
Title:
enter doesn't work on iso install over
** Changed in: qemu (Ubuntu)
Importance: Undecided = Medium
** Changed in: qemu (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1427829
Title:
Public bug reported:
1)
$ lsb_release -rd
Description:Ubuntu 14.04.2 LTS
Release:14.04
2)
$ apt-cache policy maas
maas:
Installed: 1.8.0~beta3+bzr3825-0ubuntu1~trusty1
Candidate: 1.8.0~beta3+bzr3825-0ubuntu1~trusty1
Version table:
*** 1.8.0~beta3+bzr3825-0ubuntu1~trusty1 0
Jason Hobbs shared a workaround.
1) mark node as broken
2) power off node outside of maas (ipmi commands)
3) edit node and use 'Check Now' to sync power state
4) mark node as fixed
Node is now ready.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
libvirtd crashed while creating VMs; this left storage volumes
associated with the instance present. uvt-kvm destroy foo should clean
up all related volumes, but because the VM is not currently defined,
uvtool does not remove the volumes. However, if one attempts to create
Public bug reported:
uvt-kvm currently has only one template for creating KVM guests. The
template hardcodes x86-specific values which are not available on
non-x86 (arm and ppc64el). Ideally, uvtool could do something like
/usr/share/uvtool/$arch-template.xml though we'll need something to
cloud-init[1226]: /var/lib/cloud/instance/scripts/user_data.sh: 18:
/var/lib/cloud/instance/scripts/user_data.sh: initctl: not found
ubuntu@phony-trick:/var/log$ cat /proc/partitions
major minor #blocks name
1101048575 sr0
80 488386584 sda
81 488385560
Public bug reported:
1) vivid
2) 0~bzr99-0ubuntu1
3) uvt-kvm wait --insecure vm1 waits till the VM is up
4) times out but VM is up due to creating with a separate bridge:
I've created new bridges via virsh net-define scaling-1.xml, virsh net-
start scaling-1 which creates a new bridge device
I've attempted to reproduce this issue but I've not been able to at this
point with stock 14.04 rsync versions between two 14.04 (up-to-date)
systems. It may be highly dependent on the actual data; if you can
reproduce this with something publicly available (like a large iso
catted together
On Thu, Jun 25, 2015 at 7:44 PM, Chad c...@finkenbiner.com wrote:
Would someone explain the last several updates? What is the SRU team
and what kind of review are they performing? Finally (and possibly most
Hi, I think most of your questions will be answered by looking at the
Stable Release
** Description changed:
- This message appears a lot as of a recent update to samba (Trusty
- development branch):
+ [Impact]
+
+ * Warning messages related to memory leaks no talloc stackframe at
+are present at login and other PAM services when libpam-smbpass is
+installed.
+
+ *
** Changed in: samba (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1257186
Title:
memory leakage messages (no talloc stackframe)
To
I've confirmed that this is already fixed in Wily.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1257186
Title:
memory leakage messages (no talloc stackframe)
To manage
Public bug reported:
I'm using maas2roottar to unpack the maas image in a script like so:
curtin/tools/maas2roottar $ephimg $roottar
[ $? != 0 ] {
log ERROR: Failed to convert ephemeral to roottar;
return 1;
}
But on a system that didn't have
Thank you for taking the time to report this bug and helping to make
Ubuntu better. Please execute the following command, as it will
automatically gather debugging information, in a terminal:
apport-collect 1465935
When reporting bugs in the future please use apport by using 'ubuntu-
bug' and
Public bug reported:
1. % lsb_release -rd
Description:Ubuntu Wily Werewolf (development branch)
Release:15.10
2. % apt-cache policy libvirt-bin
libvirt-bin:
Installed: 1.2.15-0ubuntu4
Candidate: 1.2.15-0ubuntu4
Version table:
*** 1.2.15-0ubuntu4 0
500
Public bug reported:
1. % lsb_release -rd
Description:Ubuntu Wily Werewolf (development branch)
Release:15.10
2. % apt-cache policy lxc
lxc:
Installed: 1.1.2-0ubuntu3
Candidate: 1.1.2-0ubuntu3
Version table:
*** 1.1.2-0ubuntu3 0
500
Hello,
The referenced patch:
https://bugs.php.net/patch-
display.php?bug_id=41631patch=bug41631.patchrevision=latest
Does not apply against 5.5.9-1ubuntu4.11 source. Further, from the bug
referenced it doesn't appear that patch specified was the final solution
committed to source.
The most
Attaching debdiff with the upstream fix patch applied.
** Patch added: debdiff
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1474276/+attachment/203/+files/php5.9_11_to_12.debdiff
** Description changed:
- The PHP Bug #68185 needs to be merged into Ubuntu PHP 5.5.x sources for
-
Attached debdiff to apply upstream fix. Updated Description for SRU
proposal.
** Changed in: php5 (Ubuntu Trusty)
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
Wily VM with wily container does not recreate this issue.
** Changed in: libvirt (Ubuntu Wily)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in Ubuntu.
https://bugs.launchpad.net/bugs/1486296
wily has bcache 1.0.8, there are no major changes to bcache itself [1]
save fixes for working in systemd pre-boot environments, which for
trusty won't matter; there are a number of package fixes[2] related to
1.0.8 intriduction of a bcache_register program introduced for systemd
preboot support.
Have you be able to reproduce this issue on a wily host? What about a
different guest? Or is only RHEL6.3 affected?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1465935
Title:
It appears that the latest version of the patch is here:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00822.html
However, this hasn't yet be accepted upstream. The most recent
discussion requires the submitter to respond to the maintainers
questions here:
The rebuilt packages with the updated check resolves the sync issue for
me.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1459748
Title:
libvirt.libvirtError: internal error: Child
** Changed in: ntp (Ubuntu)
Assignee: (unassigned) = Ryan Harper (raharper)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1372051
Title:
ntp postinst user/group add commands
*** This bug is a duplicate of bug 1477198 ***
https://bugs.launchpad.net/bugs/1477198
If you're still having trouble with haproxy in trusty, please test out
this version:
1.4.24-2ubuntu0.2
which contains a fix for this issue.
** This bug has been marked a duplicate of bug 1477198
Stop
addgroup is a perl script, so you can inspect it to see what's going on.
You can get additional information about the error running with:
sudo VERBOSE=1 addgroup --system ntp
I think what we're seeing is that your ntp group is a user group (gid =
1000) instead of a system group (gid 1000).
This command:
addgroup --system --quiet ntp
is idempotent on default precise systems, so it's not quite clear why it
fails on your system. Maybe it's possible to do some debugging on
running that command.
ubuntu@ubuntu:~$ cat /etc/issue
Ubuntu 12.04.5 LTS \n \l
ubuntu@ubuntu:~$ dpkg --list |
(which will run the postrm hook to remove the ntp group) prior to
upgrading.
** Changed in: ntp (Ubuntu)
Status: New = Incomplete
** Changed in: ntp (Ubuntu)
Assignee: Ryan Harper (raharper) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server
I can't reproduce this on vivid w.r.t the hang.
For the release all the devs used in bcache setup; it's certainly
awkward. Fundamentally, there's no path in sysfs that contains both the
cache devs and the backing devs. And AFAIK, there is no way to know
that the bcacheX devices is being cached
While the interface is annoying, it *is* possible to have bcache let go
of both backing store and cache devices via the sysfs interfaces.
** Changed in: bcache-tools (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team,
What scenario are you finding that bcache devices aren't auto
registered?
** Changed in: bcache-tools (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bcache-tools in Ubuntu.
Looks like a patch was just submitted to address this:
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04319.html
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1508466
Applied the upstream patch (not yet committed) to the wily qemu package.
Builds OK, needs testing. Will post link to PPA with packages once it is
complete.
** Patch added: "lp1508466_apply_upstream_curses_fix.debdiff"
https://lists.linuxcontainers.org/pipermail/lxc-
devel/2015-October/012630.html
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1510619
Title:
Wily: add machine fails using kvm and
Currently looking at updatin lxc package to have lxc-net run After
=network-online.target which should ensure that ifup on auto interfaces
has run, meaning ethX interfaces will have obtained and IP and at that
point then lxc-net can check if something is squating on 10.0.3.X
network and switch to
(Ubuntu)
Assignee: Ryan Harper (raharper) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1481289
Title:
PHP 5.5.9 Default socket timeout being not honoured by application
If someone can pull together a working set of patches that pulls in the
changes needed for the current version in trusty that can apply along
with a test-case, then we can pick up reviewing those for SRU.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
Do you have the libvirt log and the qemu command line used to run the
guest?
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
I think there is something else going on; clearly qemu-block-extra is
needed if you're attempting to connect to an rbd device. For example
we can attempt to connect to an rbd pool with path data/wily. I don't
actually have an rbd pool up. If qemu doesn't have block_rbd from qemu-
block-extra
Starting the debugging.
First, we must have qemu-block-extra. After adding that we can check
that qemu itself supports rbd with:
qemu-system-x86_64 -drive format=? 2>&1 | grep rbd
Next, we see libvirt barfing on the missing block device it tried to add
and spits out the disk it was going to
it appears that qemu wants additional escaping of colons when specifying
the port in mon_host options.
mon_host=10.5.29.172\:6789fails to parse
mon_host=10.5.29.172\\:6789 parses correct.
Looking at why that changed (or if libvirt stopped adding additional
escaping...).
--
You received
Have qemu-system-common and qemu-utils depend on qemu-block-extra
otherwise the packaging change changes expected behavior; namely before
the packaging change users could install qemu-system-x86 (and others
arches) and expect to use curl or rbd as a qemu block backend. After
the packaging change
OK, updating the libvirt-qemu apparmor abstraction resolves this issue:
# diff -u libvirt-qemu.orig libvirt-qemu
--- libvirt-qemu.orig 2015-09-16 18:14:46.013741000 +
+++ libvirt-qemu2015-09-16 18:14:34.001741000 +
@@ -144,6 +144,10 @@
# for rbd
/etc/ceph/ceph.conf r,
+
Looks like parsing is all fine. I recreated the error by enabling debug
and seeing the qemu hmp command passed, then I launched my own instance
and surfaced the HMP monitor, when I repeated the drive_add command it
complained, unknown protocol rbd; this is the result of qemu being
launched by
This bug requires a fix to libvirt's apparmor profile as well.
** Also affects: libvirt (Ubuntu)
Importance: Undecided
Status: New
** Changed in: libvirt (Ubuntu)
Importance: Undecided => High
** Changed in: libvirt (Ubuntu)
Status: New => Confirmed
** Changed in: qemu
debdiff includes an updated apparmor profile for libvirt-qemu for
libraries provided by qemu-block-extra
** Patch added: "libvirt_qemu_block_extra_apparmor_update.debdiff"
I've tested[1] the proposed package and it passes[2] the testcase in
the SRU justification.
1. uvt-simplestreams-libvirt sync release=trusty arch=amd64
uvt-kvm create --cpu 2--disk 10 t1 release=trusty arch=amd64
uvt-kvm wait --insecure t1
uvt-kvm ssh --insecure t1
# inside
Looks like the rbd driver has been broken out into a separate package[1]
qemu-block-extra
If you install that does that fix your issue?
1. qemu (1:2.2+dfsg-6exp) unstable; urgency=medium
Since Debian release 2.2+dfsg-6exp, a new package named qemu-block-extra
has been created and some
we're definitely missing librbd linking in wily which was present
before. Looking at the build scripts, it it appears for linux-amd64 we
emit the enable-rbd, so the next question is why we didn't actually
compile and link against it.
** Changed in: qemu (Ubuntu)
Importance: Undecided => High
Public bug reported:
As of 3.19+, overlayfs supports multiple lowerdir mount points to enable
merging multiple read-only layers together which is useful for composing
multiple layers together and then imposing an specific upper layer (say
tmpfs).
>From the kernel documentation[1]
| Multiple
Resolving this by cherry picking check on uid, and also allowing EACCES failure
due to username space.
The cherry pick could be dropped if we were to rebase on debian dev version
(tgt_1.0.61).
** Patch added: "tgt_fix_lp1518440.diff"
Tested on Xenial/amd64
1. sudo apt-get install lxd
2. lxd-images import ubuntu xenial amd64 --alias ubuntu-xenial --alias
ubuntu/xenial
3. lxd launch ubuntu-xenial x1
4. lxc exec x1 /bin/bash
# Inside xenial LXD container
5. apt-get install tgt
... fails as per comment #2
After rebuilding
Blueprint changed by Ryan Harper:
Work items changed:
Work items for ubuntu-15.11:
[serge-hallyn] etckeeper: TODO
[paelzer] NIS merge: DONE
Work items for ubuntu-15.12:
- [raharper] : tgt merge: TODO
+ [raharper] : tgt merge (bug 1524982): INPROGRESS
[racb] nagios-plugins/monitoring
debdiff between previous ubuntu version (1.0.57-1ubuntu2) and upstream
debian (1.0.61-1).
** Patch added: "debdiff_ubuntu_1.0.57-1ubuntu2_to_debian_1.0.61-1.diff"
Public bug reported:
Please merge tgt 1.0.61-1 (main) from Debian unstable (main)
** Affects: tgt (Ubuntu)
Importance: Wishlist
Status: Confirmed
** Changed in: tgt (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: tgt (Ubuntu)
Status: New => In Progress
--
debdiff between current ubuntu (1.0.57-1ubuntu2) and new ubuntu version
(1.0.61-1ubuntu1).
** Patch added: "ubuntu_merge_upgrade.diff"
https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1524982/+attachment/4532801/+files/ubuntu_merge_upgrade.diff
** Changed in: tgt (Ubuntu)
Status: In
On Wed, Dec 16, 2015 at 11:29 AM, Nicolas Dichtel wrote:
> Thank you.
>
> Note that the last three patches are not included in libnl 3.2.26, which
> is the version of ubuntu 16.04 /Xenial (
> https://launchpad.net/ubuntu/+source/libnl3/3.2.26-1).
>
Thank you for
Sorry missed the notification, I'll remerge 1.0.62.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1524982
Title:
Please merge tgt 1.0.61-1 (main) from Debian unstable (main)
To
Hi,
Thanks for the quick update. I've applied the 4 patches and built a new
test package with the changes.The example test does indeed fail on
the current version and passes on the new version as well.
I went looking for any other libnl3 tests we might run to catch any
possible regression
Tarball of the test-case used to confirm failure and fix.
** Attachment added: "lp_1511735_test.tar"
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735/+attachment/4535781/+files/lp_1511735_test.tar
** Description changed:
- The following upstream patches are needed in order to
Attaching debdiff with changes needed to resolve the bug.
** Patch added: "lp_1511735_libnl3.diff"
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735/+attachment/4535780/+files/lp_1511735_libnl3.diff
--
You received this bug notification because you are a member of Ubuntu
Server
Initial look at the patches results in the following assessment:
The first 2 patches apply fine to the version included in Ubuntu Trusty
027157898708 lib/socket: don't fail if no more local ports can be assigned in
nl_socket_alloc
debdiff between previous ubuntu version (1.0.57-1ubuntu2) and upstream
debian unstable (1.0.62-1).
** Patch added: "debdiff_ubuntu_1.0.57-1ubuntu2_to_debian_1.0.62-1.diff"
debdiff between current ubuntu (1.0.57-1ubuntu2) and new ubuntu version
(1.0.62-1ubuntu1).
** Patch added: "ubuntu_merge_upgrade_v2.diff"
https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1524982/+attachment/4535288/+files/ubuntu_merge_upgrade_v2.diff
** Changed in: tgt (Ubuntu)
Blueprint changed by Ryan Harper:
Work items changed:
Work items for ubuntu-15.11:
[serge-hallyn] etckeeper: TODO
[paelzer] NIS merge: DONE
Work items for ubuntu-15.12:
- [raharper] : tgt merge (bug 1524982): INPROGRESS
+ [raharper] : tgt merge (bug 1524982): DONE
[racb] nagios
https://lists.debian.org/debian-kernel/2015/10/msg00332.html
common threads 4.2 kernel and UEFI mode of kvm.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to kvm in Ubuntu.
https://bugs.launchpad.net/bugs/1532571
Title:
kvm crashes
No; it should go upstream AFAICT.
I can regen with tabs; my fault for not checking what the source file
used.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1518440
Title:
tgt
Can we publish some test images? Instead of guessing at this, we can
benchmark this.
In general swapping ram-based for what is almost always disk-based is
going to impact applications/deployments using tmp and expecting enough
space there. It's not uncommon for large ISO or other image
v3 debdiff
- Removed unneeded spaces in debian/control Breaks entry
- Fixed up libnl-3-200.symbols file to tag private symbols as optional
(removes dpkg-gensymbols warning)
- Removed invalid use of Closes() for Debian bugs; instead use LP: #
** Patch added: "lp_1511735_libnl3_v3.diff"
Yes, quite close. I'll handle the FFE if needed but I feel on-track.
I'm preparing the merge debdiff for review.
Threads:
https://lists.ubuntu.com/archives/ubuntu-devel/2016-January/039144.html
https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039201.html
Please give the test-package
Ah, yes. I've a fix for that; I hadn't pushed my latest update in to the
ppa. The extra-plugins package need some more privs for the charon binary
in the apparmor profile.
Look for 1ubuntu5 in the ppa in just a bit and see if that fixes up the
issue with the extras plugins.
On Sat, Feb 13,
1 - 100 of 171 matches
Mail list logo