Confirmed: openssl is using x86 crypto even with "-engine padlock", both
in latest upstream and in the current hardy packages.
If I interrupt a debug build of openssl while running "openssl speed
aes-128-cbc -engnie padlock" on a C3 gdb generally reports that it's
been interrupted in:
_x86_AES_en
** These bugs are fixed upstream in OpenSSH 4.9 and OpenSSL 0.9.8h **
You can apply the fix to OpenSSH 4.7 from Ubuntu just fine:
https://bugzilla.mindrot.org/attachment.cgi?id=1458 . It applies cleanly
except for two rejects at points where the changes have already been
applied, so the rejects ca
Quick instructions on rebuilding openssh and openssl to include the fix,
for those not used to patching Debian packages:
mkdir wrk
cd wrk
sudo apt-get install build-essential fakeroot wget
sudo apt-get build-dep openssl openssh
apt-get source openssl openssh
cd openssl-0.9.8g
wget --quiet -O - ht
** Description changed:
VIA PadLock is a hardware cryptography engine for AES and SHA1/256.
- OpenSSH should support PadLock. Initial work on PadLock support has already
been done:
+ OpenSSH should support PadLock. Upstream OpenSSH versions do support
+ padlock, and a working patch exists in
Upstream bug:
http://rt.openssl.org/Ticket/Display.html?id=1668&user=guest&pass=guest
Though the bug hasn't been closed, the patch has been applied to 0.9.8h
as is trivially verifiable by examination of the source.
** Also affects: openssh (Ubuntu)
Importance: Undecided
Status: New
--
I tried a fresh install of jaunty. The pam_mount works for my LTSP
server if I logon to the server (Active directory member (Likewise) and
the mount points show up for each user and unmount on logout), but for
the LTSP clients it does not work. I've opted out of the pam_mount
option for putting a
Public bug reported:
I tried the workaround from https://bugs.launchpad.net/ubuntu/+source
/juju-core/+bug/1317680, but that did not solve the issue.
The steps I am performing to get here are:
juju bootstrap
uvt-simplestreams-libvirt purge
uvt-simplestreams-libvirt sync release=trusty arch=arm64
** Attachment added: "environments yaml"
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1349854/+attachment/4165128/+files/environments.yaml
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs
** Attachment added: "all machines log"
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1349854/+attachment/4165126/+files/all-machines.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.l
** Attachment added: "local jenv"
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1349854/+attachment/4165129/+files/local.jenv
** Description changed:
I tried the workaround from https://bugs.launchpad.net/ubuntu/+source
/juju-core/+bug/1317680, but that did not solve the issue.
** Attachment added: "cloud init log"
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1349854/+attachment/4165127/+files/cloud-init-output.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bug
** Attachment added: "machine 0 log"
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1349854/+attachment/4165125/+files/machine-0.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchp
Was able to reproduce this issue with the newer version of juju found
here: http://juju-ci.vapour.ws:8080/job/publish-revision/711/
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/134
Using the tools from here: https://juju-dist.s3.amazonaws.com/rc-
testing/tools
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1349854
Title:
kvm container creation failed: exit s
uvt-kvm create foo release=trusty arch=arm64 label=release
uvt-kvm: error: libvirt: XML error: No PCI buses available
I am not sure.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1
I can confirm this problem.
It seems to be due to a miscompilation of rsync and the zlib library
https://bugzilla.samba.org/show_bug.cgi?id=10372
Trying the transfer without -z / --compress works fine.
The bug seems to show itself when transferring big files ( 1.5GB in my
case)
I think this sh
Public bug reported:
Binary package hint: mailman
Error
Could not install
/var/cache/apt/archives/mailman_1%3a2.1.12-1_i386.deb
The upgrade will continue but the ... mailman package may be in a not working
state.
subprocess pre-installation script returned error exit status 1
** Affects: mailm
** Description changed:
Binary package hint: mailman
Error
Could not install
/var/cache/apt/archives/mailman_1%3a2.1.12-1_i386.deb
The upgrade will continue but the ... mailman package may be in a not working
state.
subprocess pre-installation script returned error exit status 1
until kubuntu 9.10 when I
assume the problem will be resolved. So, for now, I am no longer using
mailman.
Craig
On Wednesday 09 September 2009 11:29:55 Chuck Short wrote:
> Thanks for the reporting the bug, I was wondering if this is still a
> problem for you?
>
> Th
I tried the patch and I can confirm it worked once. However it didn't
fail every time before so it probably needs a bit more testing.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1300
101 - 120 of 120 matches
Mail list logo
