Bug#630478: Problem with size of virtual floppies
Package: virtinst
Version: 0.500.3-2
Severity: important
Justification: Some functionality is unavailable
virt-install appears to convert existing disk image files sizes to
gigabytes at around line 650 of VirtualDisk.py which has this code:
newsize = float(newsize) / 1024.0 / 1024.0 / 1024.0
Even with floppy disk images. Whether the above assumption is actually what
happens, the
consequence is that I get this error:
[Sat, 11 Jun 2011 22:02:46 virt-install 32253] DEBUG (virt-install:330)
parse_disk: returning {'format': None, 'bus': None, 'readOnly': True,
'volInstall': None, 'path': '/var/lib/libvirt/images/fd.img', 'device':
'floppy', 'volName': None, 'conn': libvirt.virConnect instance at 0x2402998,
'size': None, 'driverCache': None, 'shareable': False, 'sparse': True}
[Sat, 11 Jun 2011 22:02:47 virt-install 32253] DEBUG (VirtualDisk:860) Path
'/var/lib/libvirt/images' is target for pool 'default'. Creating volume
'fd.img'.
[Sat, 11 Jun 2011 22:02:47 virt-install 32253] ERROR (cli:196) Error with
storage parameters: Size must be specified for non existent volume path
'/var/lib/libvirt/images/fd.img'
[Sat, 11 Jun 2011 22:02:47 virt-install 32253] DEBUG (_util:221) Traceback
(most recent call last):
File /usr/lib/pymodules/python2.6/virtinst/cli.py, line 480, in disk_prompt
dev = VirtualDisk(**arg_dict)
File /usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py, line 437, in
__init__
self.__validate_params()
File /usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py, line 946, in
__validate_params
self.__check_if_path_managed()
File /usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py, line 864, in
__check_if_path_managed
existent volume path '%s' % self.path))
ValueError: Size must be specified for non existent volume path
'/var/lib/libvirt/images/fd.img'
This is the actual file:
-rw-r--r-- 1 root root 1474560 Jun 11 21:46 /var/lib/libvirt/images/fd.img
Note that this floppy image was okay in the RHEL6 beta where I created it ans
used it for several Debian Squeeze installs using
python-virtinst-0.500.3-7.el6.noarch or (slightly) earlier.
Note, if the disk image is missing, this message arises:
ERRORA size must be specified for non-existent disks.
It does not identify the problem file, and the text is slightly different
although the meaning,
it seems, is the same.
-- System Information:
Debian Release: 6.0.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages virtinst depends on:
ii python 2.6.6-3+squeeze6 interactive high-level object-orie
ii python-libvirt 0.8.3-5+squeeze1 libvirt Python bindings
ii python-libxml2 2.7.8.dfsg-2+squeeze1 Python bindings for the GNOME XML
ii python-support 1.0.10automated rebuilding support for P
ii python-urlgrabber 3.9.1-4 A high-level cross-protocol url-gr
Versions of packages virtinst recommends:
ii qemu 0.12.5+dfsg-3 fast processor emulator
ii virt-viewer0.2.1-1 Displaying the graphical console o
virtinst suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: London Stock Exchange suffers .NET Crash
Mauro Souza wrote: here in Brazil: Bradesco: Apache Itau: IBM Http Server Banco do Brasil: IHS Unibanco: IIS Santander: IHS Really, my point is that some large organinsations that (one presumes) care about their systems think Windows is okay. Their opinion differs from that of the author of http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash Some greybeards at Westpac (and IBM I should think) will well remember an IMS upgrade that failed in the 80s and took out the ATM network for some days. See http://www.computerworlduk.com/management/infrastructure/networks/news/index.cfm?newsid=10912 for an alternative report of the LSE incident. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Bug#412310: Conflicting copyright claims
Package: gettext Version: 0.14.4-2 Severity: serious Several (many?) files contain these lines, as identified with find|xargs grep -2i public\ domain ./gettext-tools/examples/hello-c/autoclean.sh-# Example for use of GNU gettext. ./gettext-tools/examples/hello-c/autoclean.sh-# Copyright (C) 2003-2004 Free Software Foundation, Inc. ./gettext-tools/examples/hello-c/autoclean.sh:# This file is in the public domain. ./gettext-tools/examples/hello-c/autoclean.sh-# [EMAIL PROTECTED] ~]$ It's not clear to me whether Debian has the right to distribute this software: if it's in the public domain, then there is no problem but OTOH if the FSF does hold the right to control who may make copies, then under what terms does Debian do so? I don't see how it can be both in the public domain and copyright FSF, and I don't see why the FSF wouldn't use the GPL (or maybe a BSD/MIT licence) in this case. I'm reporting this so that Debian may consider the question and take appropriate action, if only to record the matter's considered and that Debian may freely distribute the software. Hopefully, an official from the FSF will concur with Debian's decision. I have attempted to discuss the question with two of the authors identified in one of the documents; the address of one's no longer valid, and the other doesn't see a problem. However, he also doesn't appease my concerns. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307289: openvpn: Please do stop on upgrade
Package: openvpn Version: 2.0-1 Severity: normal For security reasons (and for ease of access to the whole LAN) I regularly connect to remote systems over a vpn. This is how I normally connect when doing system maintenance. Likely, I update software on several systems at once. When openvpn stops it means my session is terminated and I can't see what has happened. Potentially this leaves me with a broken system and the need to visit affected sites. If the sites were more remote (a mate maintains systems on the other side of the Indian Ocean) I'd need local hired help. I am not sure what's best for all, but I'd settle for just leaving openvpn running. In all probability it will work just fine. The current situation is untenable. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages openvpn depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii liblzo1 1.08-1.2 A real-time data compression libra ii libssl0.9.7 0.9.7e-3 SSL shared libraries -- debconf information: openvpn/change_init: true openvpn/create_tun: false * openvpn/stop2upgrade: true * openvpn/default_port: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307295: shorewall: Please guarantee a working firewall after upgrade
Package: shorewall Version: 2.2.3-1 Severity: normal I maintain the software on several systems remotely, connecting over they Internet. I am concerned that one day an upgrade to shorwall will leave me with a broken firewall and the need to visit the site or worse, find local hired help. Ideas that come to mind: Use alternatives to choose the active version. This should be in manual mode. Store config files in version-dependant directories - /etc/shorewall22 etc. Use iptables-save to save a working firewall script and make this the default, to be changed at a time of the sysadmin's choosing. This is quite a serious concern to me; I've been cracked and my firewall rules are part of my plan to limit (by IP address range) locations from which connexions can be made to sensitive services. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages shorewall depends on: ii debconf 1.4.30.13 Debian configuration management sy ii iproute 20041019-3 Professional tools to control the ii iptables 1.2.11-8 Linux kernel 2.4+ iptables adminis -- debconf information: * shorewall/upgrade_20_22: false shorewall/upgrade_14_20: shorewall/upgrade_to_14: * shorewall/dont_restart: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276469: mailman: Install sets wrong home directory
Tollef Fog Heen wrote:
* John
| On installation, mailman creates the user with this command:
| adduser --system --home /var/list --ingroup list list
| The directory /var/list does not exist, is not created and
| (I think) is wrong anyway.
This is to be consistent with base-passwd:
I don't see what base-passwd has to do with it, but then I'm not a dd,
I'm just a dopey user.
Seems to me the whole idea of putting _application_ binaries into
_system_ libraries is flawed anyway, and mailman is just as much an
application as the in-house software we used at The Department of Social
Security's Pensions, Payments, Family Allowances, Unemployment Benefits
were when I worked there in the 70s 80s, and those were in private
libraries.
Further, using a common account name (which I presume is the idea of
using a nodescript name such as list as about) mitigates against using
more than one list manager.
_I_ think binaries in /usr/mailman/bin and dynamic files in
/var/{lib,spool}/mailman is sensible, and use sudo (not su) to grant
list manangers access to mailman executables and directories.
Note that Mailman doesn't use the home directory for anything, so it
doesn't matter that the directory does not exists.
Ok, it doesn't matter that users are confused by it and that cd ~list
doesn't lead anywhere useful such as /var/lib/mailman where mailman logs
etc can be found.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
