This prevents postfix from starting up when it tries to cpio
/etc/ssl/certs into its runtime chroot
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1085537
Title:
** Also affects: euca2ools (Ubuntu Quantal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1085537
Title:
/etc/ssl/certs/cert-ec2.pem
Public bug reported:
Hi,
euca2ools 2.1.1-0ubuntu1 ships:
lrwxrwxrwx root/root 0 2012-12-17 16:26 ./usr/bin/euca-describe-groups
- euca-describe-group
lrwxrwxrwx root/root 0 2012-12-17 16:26 ./usr/bin/euca-describe-group
- euca-describe-groups
so no actual implementation of
** Changed in: euca2ools (Ubuntu)
Assignee: (unassigned) = Loïc Minier (lool)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1098096
Title:
euca-describe-group(s)
** Changed in: euca2ools (Ubuntu)
Assignee: (unassigned) = Loïc Minier (lool)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1085537
Title:
/etc/ssl/certs/cert-ec2.pem is
The change uncovered that the certificate wasn't being installed in
quantal and raring anymore; the dangling symlinks breaks postfix startup
in some configurations (as it tries to cpio /etc/ssl/certs into a
chroot).
--
You received this bug notification because you are a member of Ubuntu
Server
This affects 2.1.1-0ubuntu1 (so quantal) but not
2.0.0~bzr516-0ubuntu3{,.1} (precise / precise-updates)
** Also affects: euca2ools (Ubuntu Quantal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Description changed:
$ dpkg -L euca2ools | grep cert-ec2
/etc/ssl/certs/cert-ec2.pem
$ ls -l /etc/ssl/certs/cert-ec2.pem
lrwxrwxrwx 1 root root 33 Jul 13 16:57 /etc/ssl/certs/cert-ec2.pem -
/usr/share/euca2ools/cert-ec2.pem
It would seem that this is an improper fix or regression
What is the status of this bug?
Will this ever be fixed for 10.04 LTS?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
https://bugs.launchpad.net/bugs/651049
Title:
php5: FILTER_VALIDATE_URL will invalidate a
** Changed in: euca2ools (Ubuntu)
Status: Triaged = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1085537
Title:
/etc/ssl/certs/cert-ec2.pem is dangling
** Changed in: euca2ools (Ubuntu)
Status: New = Fix Committed
** Changed in: euca2ools (Ubuntu Quantal)
Assignee: (unassigned) = Loïc Minier (lool)
** Description changed:
- Hi,
-
euca2ools 2.1.1-0ubuntu1 ships:
lrwxrwxrwx root/root 0 2012-12-17 16:26
Correction, this doens't affect quantal.
** Changed in: euca2ools (Ubuntu Quantal)
Status: New = Invalid
** Description changed:
euca2ools 2.1.1-0ubuntu1 ships:
lrwxrwxrwx root/root 0 2012-12-17 16:26
./usr/bin/euca-describe-groups - euca-describe-group
lrwxrwxrwx
This bug was fixed in the package euca2ools - 2.1.1-0ubuntu2
---
euca2ools (2.1.1-0ubuntu2) raring; urgency=low
* Actually install debian/cert-ec2.pem into usr/share/euca2ools/;
LP: #1085537.
* Rename Vcs-* to XS-Debian-Vcs-*.
* Fix euca-describe-group -
This bug was fixed in the package euca2ools - 2.1.1-0ubuntu2
---
euca2ools (2.1.1-0ubuntu2) raring; urgency=low
* Actually install debian/cert-ec2.pem into usr/share/euca2ools/;
LP: #1085537.
* Rename Vcs-* to XS-Debian-Vcs-*.
* Fix euca-describe-group -
** Branch linked: lp:ubuntu/euca2ools
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/1085537
Title:
/etc/ssl/certs/cert-ec2.pem is dangling symlink
To manage notifications about
I've reopened this, it is affecting juju-core, it's very easy to
reproduce (at least on virtual hardware), just see #20.
** Also affects: juju-core
Importance: Undecided
Status: New
** Changed in: maas
Status: Expired = Confirmed
--
You received this bug notification because
#20 is exactly what happens in the MAAS QA lab every day. I don't
believe that this bug has been seen there.
Regardless of that, I'd really like to see a tcpdump of all DHCP, ARP
and ICMP traffic as requested in #15.
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
mailman's configure script assumes that Python.h is present in
distutils.sysconfig.get_config_var('CONFINCLUDEPY') which is arch-
specific and not where it is in raring.
** Affects: mailman
Importance: Undecided
Status: New
** Affects: mailman (Ubuntu)
** Also affects: mailman
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mailman in Ubuntu.
https://bugs.launchpad.net/bugs/1098162
Title:
mailman 1:2.1.15-1 FTBFS on amd64 in raring
To
Based on the distutils documentation, I think that calling
distutils.sysconfig.get_python_inc() is a more appropriate way of
determining the location of Python.h. It seems to work both after and
before the transition that broke Raring. Is this appropriate for
upstream as well?
** Patch added:
** Attachment added: mailman_2.1.15-1ubuntu1_amd64.build
https://bugs.launchpad.net/mailman/+bug/1098162/+attachment/3479075/+files/mailman_2.1.15-1ubuntu1_amd64.build
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mailman in
** Patch added: quantal-debdiff.patch
https://bugs.launchpad.net/ubuntu/+source/euca2ools/+bug/1085537/+attachment/3479081/+files/quantal-debdiff.patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
Blueprint changed by Louis Bouchard:
Work items changed:
Work items:
- [louis-bouchard] - kdump-tools needs to be MIR / file a bug: TODO
+ [louis-bouchard] - kdump-tools needs to be MIR / file a bug: DONE
[stefan-bader-canonical] - discuss linuxcrashdump changes on ubuntu-devel /
Blueprint changed by Louis Bouchard:
Whiteboard changed:
User Stories:
Risks:
Test Plans:
Release Note:
--
The kdump mechanism from the kdump-tool package is more flexible than
its kexec-tool equivalent. It allows for multiple dumps to be collected,
is the
** Changed in: python2.7 (Ubuntu)
Importance: Undecided = High
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to genshi in Ubuntu.
https://bugs.launchpad.net/bugs/1097783
Title:
Regression: some python library functions return
This is an upstream change, as a byproduct of issue #10182
http://bugs.python.org/issue10182
In that bug, a complaint was made that match starts were being truncated
on x64 Windows machines, so the types were changed to longs. I can
reproduce this with hg tip of the 2.7 branch, and the world
The verification of this Stable Release Update has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression
Cool, so Benjamin reverted the API change in upstream hg by using PyInt*
instead of PyLong* apis. You'll see this the next time Matthias syncs
to upstream.
** Changed in: python2.7 (Ubuntu)
Status: New = Fix Committed
--
You received this bug notification because you are a member of
Public bug reported:
When I install krb5-config 2.3 (along with some other Kerberos-related
packages) on Ubuntu Quantal, I see this:
[...]
Get:8 http://$APTHOST/ubuntu/ quantal/universe krb5-user amd64 1.10.1+dfsg-2
[114 kB]
Get:9 http://$APTHOST/ubuntu/ quantal/universe kstart amd64 4.1-2
I've committed changes for this in a precise branch at
lp:~smoser/ubuntu/precise/cloud-init/sru . I have a ppa build of that
at https://launchpad.net/~smoser/+archive/cloud-init-test/ . Any
testing on that would be appreciated.
The plan is to move SRU this as soon as the current SRU moves to
I've committed changes for this in a precise branch at
lp:~smoser/ubuntu/precise/cloud-init/sru . I have a ppa build of that
at https://launchpad.net/~smoser/+archive/cloud-init-test/ . Any
testing on that would be appreciated.
The plan is to move SRU this as soon as the current SRU moves to
I've committed changes for this in a precise branch at
lp:~smoser/ubuntu/precise/cloud-init/sru . I have a ppa build of that
at https://launchpad.net/~smoser/+archive/cloud-init-test/ . Any
testing on that would be appreciated.
The plan is to move SRU this as soon as the current SRU moves to
*** This bug is a security vulnerability ***
Public security bug reported:
Currently, the entropy pool is seeded by /etc/init.d/urandom. This
should be done earlier in the boot process by an upstart job, and should
be done before the ssh daemon is started.
Although the ssh keys are generated on
This should be harmless, just noisy, but will be fixed in the next
release. Thanks!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to kerberos-configs in Ubuntu.
https://bugs.launchpad.net/bugs/1098294
Title:
Use of uninitialized
I built a precise cloud-init with the 'start networking' removed and
tried starting an lxxc instace with that from current precise daily
(with mountall 2.36.3). This issue persisted.
Steve, did you tihnk this *should* be fixed in precise?
--
You received this bug notification because you are
Public bug reported:
Version: 0.48.2-0ubuntu2~cloud0
On a Ceph cluster with 18 OSDs, new object pools are being created with
a pg_num of 8. Upstream recommends that there be more like 100 or so
PGs per OSD: http://article.gmane.org/gmane.comp.file-
systems.ceph.devel/10242
I've worked around
Public bug reported:
Version: 0.48.2-0ubuntu2~cloud0
Our Ceph deployments typically involve multiple OSDs per host with no
disk redundancy. However the default crush rules appears to distribute
by OSD, not by host, which I believe will not prevent replicas from
landing on the same host.
I've
This irritated me so I created a fixed /usr/lib/postfix/postfix-files
here. Commented out the manpages and html files as well as the files I
do not have. This is from a basic Ubuntu Lucid postfix install.
http://pastebin.com/Cgcn23mZ
--
You received this bug notification because you are a
this is confirmed on lucid if you boot a maverick or newer kernel with
it.
** Also affects: cloud-init (Ubuntu Lucid)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Lucid)
Status: New = Confirmed
** Changed in: cloud-init (Ubuntu Lucid)
Importance:
** Description changed:
As shown in cloud-config syntax at [1], cloud-init allows the user to a name
that will appear in the metadata service instead of a device name. For
example, the user can specify:
- - [ ephemeral0, /mnt, auto, defaults,noexec ]
+ - [ ephemeral0, /mnt, auto,
** No longer affects: mailman
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mailman in Ubuntu.
https://bugs.launchpad.net/bugs/1098162
Title:
mailman 1:2.1.15-1 FTBFS on amd64 in raring
To manage notifications about this bug go
Hi again!
The good news: 1.3.0 works (at least with my setup). The bad news is
that this might lower the motivation to fix 1.1.2 ;-) ...
Attached is the USB trace file from the non-working case with V 1.1.2.
If decompressed, it's an 185 MB text file and - honestly - i cannot make
any sense of
With the current mountall in precise, 2.36.3, yes - there shouldn't be
any further need to call 'start networking' directly. Are the symptoms
exactly the same as before the mountall fix?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Anyone who is affected, please can you paste all the information
requested in #15. Please also say which versions of every package you
are using.
Robie - it could be a bug that's fixed in the code awaiting SRU. We are
not testing older packages in the lab.
** Changed in: maas
Status:
@Mark Sapiro
This also affects the upstream Mailman project, since the pristine
upstream tarball also will also fail to build on Ubuntu after the next
release. What's the reason you removed the bug task?
** Also affects: mailman
Importance: Undecided
Status: New
--
You received this
** Branch linked: lp:mailman/2.2
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mailman in Ubuntu.
https://bugs.launchpad.net/bugs/1098162
Title:
mailman 1:2.1.15-1 FTBFS on amd64 in raring
To
I looked too quickly the first time and thought it was strictly a
Debian/Ubuntu packaging issue and didn't look closely at your comment #1
** Changed in: mailman
Importance: Undecided = Low
** Changed in: mailman
Status: New = Fix Committed
** Changed in: mailman
Milestone: None =
47 matches
Mail list logo
