According to the Free Software Foundation [1] php CANNOT be legally
linked to libreadline, because libreadline is licensed under the GPL and
php is licensed under the php license.
[1] http://www.gnu.org/licenses/gpl-faq.html
--
You received this bug notification because you are a member of
Blueprint changed by Bryan McLellan:
Work items changed:
Work items:
[james-page] Generally keep a eye on progress in Debian and ensure
syncs/blacklists allow this (esp milestones): TODO
[james-page] Sort out solr in Debian to help unblock Debian work: INPROGRESS
[btm] Check on whether
Blueprint changed by Bryan McLellan:
Whiteboard changed:
Discussion Topics:
What issues lead to the packages being removed from precise?
+ - Fast Chef development cycle over the last two years made current stable
branch 0.10.x while precise still had 0.8.16.
+ - solr package became out
Blueprint changed by Bryan McLellan:
Whiteboard changed:
Discussion Topics:
What issues lead to the packages being removed from precise?
- Fast Chef development cycle over the last two years made current stable
branch 0.10.x while precise still had 0.8.16.
- solr package became out
I don't think this bug hits me on Lucid until I give libvirt a different
group for the sock files. It'd be interesting if others seeing this bug
are changing this value as well.
--
setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu
https://bugs.launchpad.net/bugs/579584
You
libvirt-bin=0.7.5-5ubuntu27
qemu-kvm=0.12.3+noroms-0ubuntu9.2
r...@iadvirt02:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.1 LTS
Release:10.04
Codename: lucid
r...@iadvirt02:~# uname -a
Linux iadvirt02 2.6.32-24-generic
Actually, it does looks like an apparmor problem. Putting Apparmor in
complain mode allows the domain to start, returning it to enforce brings
back the original state.
r...@iadvirt02:~# aa-complain /etc/apparmor.d/usr.sbin.libvirtd
Setting /etc/apparmor.d/usr.sbin.libvirtd to complain mode.
I'm not sure how this state gets created but:
r...@iadvirt02:/etc/apparmor.d/libvirt# ls -l
total 8
-rw-r--r-- 1 root root 265 2010-07-15 19:44
libvirt-177bb534-7d9c-91ad-e6bf-89cd76d1e1bb
-rw-r--r-- 1 root root 164 2010-04-22 16:57 TEMPLATE
r...@iadvirt02:/etc/apparmor.d/libvirt# virsh start
I made the mistake of assuming that my issue couldn't have been apparmor
related because I had executed '/etc/init.d/apparmor stop' to unload
profiles to ensure it wasn't an apparmor problem. Apparently this wasn't
true, as comment #3 made me go and try the apparmor rules anyway and
this resolved
Yes, although it's working at the moment.
domain type='kvm'
nameiadoptdc02/name
uuid177bb534-7d9c-91ad-e6bf-89cd76d1e1bb/uuid
memory1048576/memory
currentMemory1048576/currentMemory
vcpu2/vcpu
os
type arch='x86_64' machine='pc-0.12'hvm/type
boot dev='hd'/
/os
features
1) stopped libvirt via the libvirt-bin init script
2) started 'libvirtd -v' manually hoping to see some debugging output
3) started the guest okay.
4) destroyed the guest
5) canceled the manual libvirt
6) started libvirt-bin again with the init script
7) started the guest okay.
Note that AppArmor
I had to run '/etc/init.d/apparmor reload' after upgrading to the
packages in -proposed before libvirt would properly start.
** Attachment added: output of my upgrade session
http://launchpadlibrarian.net/35806805/462000.notes
--
apparmor disallows qemu+tcp:// connections
Public bug reported:
libvirt + kvm need to be able to read the certificates when using TLS to
connect to VNC.
Nov 17 17:08:09 lasvirt01 kernel: [69476.008895] type=1503
audit(1258506489.178:77): operation=open pid=17104 parent=1 profile
=libvirt-600d5dae-6373-107e-5f1b-5010aff3ffed
** Attachment added: cpuinfo on karmic w/linux-image-2.6.31-10-generic
http://launchpadlibrarian.net/31986084/cpuinfo.379991.txt
--
Certain VMs do not run under KVM using karmic's kernel
https://bugs.launchpad.net/bugs/379991
You received this bug notification because you are a member of
Confirmed on linux-image-2.6.31-9-generic with kvm=1:84+dfsg-0ubuntu16 +
libvirt-bin=0.7.0-1ubuntu3 on karmic.
WinXP would run through the install but not boot after the reboot.
Same with Win7
Then running Win7 from the command line with '-cpu qemu32' allowed it to
boot.
--
Certain VMs do not
On Fri, Apr 3, 2009 at 5:18 PM, Prasad Tadi pt...@roshitech.com wrote:
However, when I run the command on local link (local machine's) , It
completes and not even a single trace on tshark ip6 -i eth1
But when I traced on lo, it did show the data.
Right, because you're using the local
On Thu, Apr 2, 2009 at 7:33 PM, Prasad Tadi pt...@roshitech.com wrote:
My hardware is little more complicated, I will explain that below...
But wants to make sure that I understood Local Link.
Link Local is the ipv6 address assigned to the interface that starts
with fe80:: [1] You don't have to
On Thu, Apr 2, 2009 at 11:20 PM, Tom Metro tmetro+ubu...@gmail.com wrote:
That may be partly right. I see /sbin/dhclient-script contains the
comment:
# The alias handling in here probably still sucks. -mdz
and there's clearly evidence that it is attempting to support virtual
interfaces:
On Fri, Apr 3, 2009 at 12:23 PM, Prasad Tadi pt...@roshitech.com wrote:
I am not really an expert, but I think the Local link may use Loop back
Link-local is the fe80 addresses that refer to devices on a particular data
link, such as a single Ethernet network, or a point-to-point serial
On Fri, Apr 3, 2009 at 1:20 PM, Tom Metro tmetro+ubu...@gmail.com wrote:
Removing ubuntu-minimal sounds like something to be avoided, but there
was mention of people doing that (as a side effect of removing the
wireless package) in the bug this one was split off from, and it didn't
sound like
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
These two errors are because dhclient-script does not support alias
interfaces. If you don't use this script, those errors go away. However
it's likely dhclient doesn't support alias interfaces at all, a
Using only linklocal addresses I've sustained near 40MB/s copying a 10GB
file in the following patterns:
Ubuntu 8.10 - Ubuntu 9.04
Debian 4.0 - Ubuntu 9.04
Ubuntu 9.04 - Ubuntu 8.10
It seems more likely that your problem would be a hardware issue.
Have you tried connecting the two Ubuntu
I noticed in your lspci output that your Realtek network chipset isn't
being detected completely and looked very similar to the comments in Bug
240470, particular this comment [1]. Please make sure that the BIOS on
your system has the latest firmware upgrade applied.
[1]
*** This bug is a duplicate of bug 306678 ***
https://bugs.launchpad.net/bugs/306678
#306678 is a problem with the update-rc.d line triggered by an upgrade
in the postinst script.
If this is a duplicate of anything, I think it's #181188, which resolves
iscsid not stopping correctly. However
Public bug reported:
Binary package hint: open-iscsi
When upgrading open-iscsi from 2.0.865-1ubuntu4 to 2.0.870.1-0ubuntu1 it
attempts to run:
update-rc.d -f remove open-iscsi
This fails, as it should be:
update-rc.d -f open-iscsi remove
Line 58 of open-iscsi.postinst
# uname -a
Linux
Public bug reported:
Binary package hint: open-iscsi
On an upgrade from open-iscsi=2.0.865-1ubuntu4 to open-
iscsi=2.0.870.1-0ubuntu1, the postrm script for 2.0.865-1ubuntu4 stops
iscsid via the initscript, which fails to to all iscsid processes. When
apt then tries to run the postinstall
Public bug reported:
The intrepid package defaults to using -F and /etc/ldap/slapd.d. The
postinst file uses slaptest to try to convert existing configurations to
the newer directory format, however this does not configure the monitor
backend module.
a 'olcDatabase={1}monitor.ldif' file is
mkdir -p /tmp/slap/slapd.d
# save attached config to /tmp/slap
slaptest -f /tmp/slap/slapd.conf -F /tmp/slap/slapd.d
# works
# Edit /tmp/slapd/slapd.d/cn=config/cn=module{0}.ldif and remove
olcModuleLoad: {1}back_monitor
slaptest -f /tmp/slap/slapd.conf -F /tmp/slap/slapd.d
# does not work, will
28 matches
Mail list logo
