Re: A few observations about systemd
* Simon McVittie (s...@debian.org) [110724 23:52]: > On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote: > > even init.d has a documented (and what's > > more, actually *working*) implementation of not starting daemons at > > boot. It's called 'remove the *** symlink'. > > If you remove them, they'll be recreated by the next upgrade; the right Only if you remove all. If you keep at least one symlink (e.g. only remove the startup symlinks) they are not recreated. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725094136.gb15...@mails.so.argh.org
Re: A few observations about systemd
On Sun, Jul 24, 2011 at 10:16:15PM +0200, Stephan Seitz wrote: > Editing /etc/runlevel.conf is easy as well. But I still prefer the > good old „exit 0” version. And talking with other people, this seems > to be far easier to remember if they want to revert the change. The problem with this is that this renders direct usage of /etc/init.d/$whatever completely impotent. If you do it Wouter's way, everything does the right thing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725095602.ga12...@scru.org
Re: A few observations about systemd
On Mon, Jul 25, 2011 at 11:41:36AM +0200, Andreas Barth wrote: > * Simon McVittie (s...@debian.org) [110724 23:52]: > > On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote: > > > even init.d has a documented (and what's > > > more, actually *working*) implementation of not starting daemons at > > > boot. It's called 'remove the *** symlink'. > > > > If you remove them, they'll be recreated by the next upgrade; the right > > Only if you remove all. If you keep at least one symlink (e.g. only > remove the startup symlinks) they are not recreated. Still, I think it's quite fair to say that the current system is both baroque and underdocumented. If you were to ask a typical user, and likely most developers, what the correct way was to disable a service, I doubt you'd get a consistent or correct answer. I'll admit that I gave up in frustration and added "exit 0" to a few scripts in my time. Do we actually have a standardised interface that can disable a service and then reenable it so that it is in exactly the same state as before it was disabled, without requiring black magic and/or prior knowledge of the correct runlevels? update-rc.d certainly isn't it. Having a "service foobar enable|disable" type of action would be a major improvement, and save the need for horrible "ENABLED=yes" type settings in /etc/default, or manual editing of scripts. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#635339: ITP: ruby-eim-xml -- Easy IMplemented XML by Ruby
Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-eim-xml Version : 0.0.4 Upstream Author : KURODA Hiraku * URL or Web page : https://rubygems.org/gems/eim_xml * License : GPL-2 Description : Easy IMplemented XML by Ruby EimXML is a library for constructing XML objects by Ruby DSL. --- Youhei SASAKI GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipqqwpym.wl%uwab...@gfd-dennou.org
Re: A few observations about systemd
On Sat, 23 Jul 2011 13:09:02 -0300, Fernando Lemos wrote: >The thing you don't seem to get is that systemd uses "init files" No need to be rude and to assume stupidity on the other side when one is just asking innocent questions about what to expect in the next years. You're not making any friends that way. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qljmt-0001eo...@swivel.zugschlus.de
Re: A few observations about systemd
On Mon, Jul 25, 2011 at 8:57 AM, Marc Haber wrote: > On Sat, 23 Jul 2011 13:09:02 -0300, Fernando Lemos > wrote: >>The thing you don't seem to get is that systemd uses "init files" > > No need to be rude and to assume stupidity on the other side when one > is just asking innocent questions about what to expect in the next > years. That was not the intention, please don't overreact. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9FiA=6m5M-+Q21-x+CF1_5hG=agygfcrhwglpj+p1...@mail.gmail.com
Bug#635352: ITP: libcache-ref-perl -- Perl module for caching references in memory
Package: wnpp Severity: wishlist Owner: Tim Retout * Package name: libcache-ref-perl Version : 0.04 Upstream Author : Yuval Kogman * URL : http://search.cpan.org/dist/Cache-Ref/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module for caching references in memory Cache::Ref implements in-memory caching, designed primarily for shared references. It supports various caching algorithms. . It differs from CHI (libchi-perl), in that it does not attempt to address the problem of caching things persistently. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725132505.10140.2868.report...@debian.retout.co.uk
Bug#635358: ITP: libmemhandle-perl -- Perl module to supply memory-based FILEHANDLE methods
Package: wnpp Owner: Fabrizio Regalli Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmemhandle-perl Version : 0.06 Upstream Author : "Sheridan C. Rawlins" * URL : http://search.cpan.org/dist/MemHandle/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module to supply memory-based FILEHANDLE methods MemHandle generates inherits from IO::Handle and IO::Seekable. It provides an interface to the file routines which uses memory instead. See perldoc IO::Handle, and perldoc IO::Seekable as well as perlfunc for more detailed descriptions of the provided built-in functions: print printf readline sysread syswrite getc gets The following functions are provided, but tie doesn't allow them to be tied to the built in functions. They should be used by calling the appropriate method on the MemHandle object. signature.asc Description: This is a digitally signed message part
Re: A few observations about systemd
On Sun, Jul 24, 2011 at 10:52:13PM +0100, Simon McVittie wrote: > On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote: > > even init.d has a documented (and what's > > more, actually *working*) implementation of not starting daemons at > > boot. It's called 'remove the *** symlink'. > > If you remove them, they'll be recreated by the next upgrade; the right > way to disable an init script is to change the Snn links to K$((100 - nn)), > or in recent sysv-rc, "update-rc.d foo disable". Only if you remove them all, as aba already said. Having said that, I do agree with you that it could benefit from either better documentation, or a command for system admins to use which would enable or disable initscripts. RedHat (and similars) have 'chkconfig' which does this; porting it to Debian should not be too hard. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725150421.ga22...@grep.be
Bug#635374: ITP: libtie-array-iterable-perl -- Tie::Array::Iterable - Allows creation of iterators for lists and arrays
Package: wnpp Severity: wishlist Owner: Julien VAUBOURG * Package name: libtie-array-iterable-perl Version : 0.03 Upstream Author : Michael K. Neylon * URL : http://search.cpan.org/~mneylon/Tie-Array-Iterable-0.03/Iterable.pm * License : Artistic Programming Lang: Perl Description : Tie::Array::Iterable - Allows creation of iterators for lists and arrays Tie::Hash::Iterable allows one to create iterators for lists and arrays. The concept of iterators is borrowed from the C++ STL [1], in which most of the collections have iterators, though this class does not attempt to fully mimic it. Typically, in C/C++ or Perl, the 'easy' way to visit each item on a list is to use a counter, and then a for( ;; ) loop. However, this requires knowledge on how long the array is to know when to end. In addition, if items are removed or inserted into the array during the loop, then the counter will be incorrect on the next run through the loop, and will cause problems. While some aspects of this are fixed in Perl by the use of for or foreach, these commands still suffer when items are removed or added to the array while in these loops. Also, if one wished to use break to step out of a foreach loop, then restart where they left at some later point, there is no way to do this without maintaining some additional state information. The concept of iterators is that each iterator is a bookmark to a spot, typically concidered between two elements. While there is some overhead to the use of iterators, it allows elements to be added or removed from the list, with the iterator adjusting appropriate, and allows the state of a list traversal to be saved when needed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725154332.12118.65545.reportbug@junix
Re: A few observations about systemd
On Mon, Jul 25, 2011 at 12:41:59AM +0200, Tollef Fog Heen wrote: > ]] Wouter Verhelst > > Hi Wouter, > > | At any rate, by not wanting to do scripts, you're making life harder for > | yourself, since now you suddenly have to implement everything what > | people have trivially done in shell scripts for years in C. Writing > | flawless C isn't exactly easy either[1], and even if systemd's author is > | a perfect coder (which he isn't, since perfection does not exist), > | there's going to be a need to have some other people write some systemd > | module at some point in the future, since 'plain' systemd doesn't do > | what their software requires, or what their corporate environment likes, > | or whatever, and they're going to make mistakes. > > There's not such thing as a systemd module. (I assume you're not > talking about the systemd units which is the collective name for mounts, > services and so on.) I saw someone point to files in /usr somewhere from the systemd package that seemed a like modules to me, but I could have misunderstood what they were. What matters is not whether it's a loadable module or a separate process or whatever, but that it's a piece of C code specifically written to extend systemd functionality, which would previously have been written in a script. > | And as a result, rather than have an initscript that does the > | equivalent of "killall -KILL -1", you're going to have someone > | implement socket enablement (or whatever it's called) incorrectly, > | thereby creating a remotely exploitable buffer overflow. > > If you need socket activation, you obviously have to write the code to > do so. There is nothing in systemd itself that requires you to use > socket activation unless it actually gains you something. > > I have no idea why you are confusing the idea of stopping a service > using (or doing a reload) using killall and socket activation, unless > you're just doing this to rant, though. Please grab me here at debconf > (or send email) if you're interested in having a discussion about it. To be perfectly frank, I'm not interested in systemd; it's just that I'm sceptical about it, and about its motives. That doesn't mean I'm opposed to it being uploaded, or even to it being made the default if it can be done in a technically sound way that would not either make the kFreeBSD ports impossible, or require SysV initscripts, *and* systemd unit files, *and* upstart stuff, and so on ad nauseum. I've seen people suggest in this thread to use some script to convert systemd unit files to sysv init scripts, and/or to whatever upstart calls its configuration; and while I can see that being done, I wonder whether using systemd files as 'source' for the conversion would be the better option, as opposed to something a little more under our control--if some other init system were to have a feature that systemd does not support, then this feature could not be used by Debian packages, since there's no way to implement it in a systemd unit file. We've implemented similar meta configuration for cron implementations, window manager menu systems, and a multitude of other things. I don't see why we couldn't do the same for init systems. In fact, we've done so for a long time, and it is still supported to some extent. All that's really needed, is to make it a bit more meta, so that the simple cases are covered by the meta language, and the more complex cases can be handled by shipping specific configuration files or init scripts, or some such. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Bug#635381: ITP: libcurses-toolkit-perl -- Curses::Toolkit - A modern Curses toolkit
Package: wnpp Severity: wishlist Owner: Julien VAUBOURG * Package name: libcurses-toolkit-perl Version : 0.207 Upstream Author : Damien "dams" Krotkine * URL : http://search.cpan.org/~dams/Curses-Toolkit-0.207 * License : The Perl 5 License (Artistic 1 & GPL 1) Programming Lang: Perl Description : Curses::Toolkit - A modern Curses toolkit This module tries to be a modern curses toolkit, based on the Curses module, to build "semi-graphical" user interfaces easily. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725163603.14272.41675.reportbug@junix
Bug#635388: ITP: ruby-rack-test -- Simple testing API built on Rack
Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-rack-test Version : 0.6.0 Upstream Author : Bryan Helmkamp * URL or Web page : http://github.com/brynary/rack-test * License : MIT Description : Simple testing API built on Rack Rack::Test is a small, simple testing API for Rack apps. It can be used on its own or as a reusable starting point for Web frameworks and testing libraries to build on. --- Youhei SASAKI GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739huckfh.wl%uwab...@gfd-dennou.org
Re: Suspend/Hibernate Resume in debian
On 20/05/11 19:34, Jon Dowland wrote: On Fri, May 20, 2011 at 02:44:42PM +0700, Arief M Utama wrote: But, even so, I have done some test with "echo 'mem'> /sys/power/state" and "echo 'disk'> /sys/power/state" few times before, and it shows same behaviour with desktop initiated suspend and hibernate, "mem" suspend failed at resume, "disk" hibernate-resume working ok. Fundamentally, that implies a bug in the kernel for your particular hardware. Packages like uswsusp sometimes have more success because they apply kludges/quirks to work around the bug. These kludges/quirks are better handled in the kernel itself (sometimes hardware has quirks; other times it is a software error). Update, and this might need to go also into Debian Suspend/Resume wiki, For suspend-resume, I've just discovered there's this bug notes in kernel's bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16396 A changes regarding skip saving of nvs state on suspend apparently affected some systems. Affected system should be blacklisted in the table by looking at dmidecode output. My system, Sony Vaio VGN-SR26GN, is affected, the solution for me currently is to add acpi_sleep=nonvs as boot parameter. I've also attached my laptop's dmidecode output in there hopefully it will be included in the blacklist table in the next round. Hope it helps anyone else out there :) Thanks all for the help and pointers. All the best. -arief -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2db4d6.4000...@gmail.com
Bug#635394: ITP: ruby-bacon -- Small RSpec clone
Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-bacon Version : 1.1.0 Upstream Author : Christian Neukirchen * URL or Web page : http://github.com/chneukirchen/bacon * License : MIT Description : Small RSpec clone Bacon is a small RSpec clone weighing less than 350 LoC but nevertheless providing all essential features. This package need ruby-rack's test. --- Youhei SASAKI GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkk2b4bc.wl%uwab...@gfd-dennou.org
Providing official virtualisation images of Debian
Hi, I believe it's high time we start to providing Debian in form of official virtualisation images. In contrast to the ISOs currently provided it allows a quicker evaluation/testing of Debian (and can also be very useful for testing (e.g. someone wrote on debian-release that he doesn't have access to oldstable/stable systems, with prepared virtualisation images that would no longer be an issue). For many setups this could even replace the installer since software selection and hostname can easily be tweaked post-install. I think it's sufficient for starters to provide images for stable (they can be updated for every few point updates if needed). What virtualisation solutions should be supported? - Virtual Box seems like a natural candidate since it's free and included since Squeeze. - Vmware has a significant installed base and is relevant, although proprietary - Microsoft Virtual PC is likely also needed - Qemu - Citrix XenServer? How should the images be generated? IMO the images would need to be created by a DD and to provide at least some form of trust path validation we could provide PGP signed hashes of the download images. Maybe some virtualisation solutions also provide their own validation mechanisms. Do people think this is relevant and are willing to work on providing one of the images? If so, we could arrange a BoF at DebConf. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj2rrdt.3tm@inutil.org
Re: Providing official virtualisation images of Debian
On 7/25/2011 6:27 PM, Moritz Mühlenhoff wrote: Hi, I believe it's high time we start to providing Debian in form of official virtualisation images. In contrast to the ISOs currently provided it allows a quicker evaluation/testing of Debian (and can also be very useful for testing (e.g. someone wrote on debian-release that he doesn't have access to oldstable/stable systems, with prepared virtualisation images that would no longer be an issue). For many setups this could even replace the installer since software selection and hostname can easily be tweaked post-install. I think it's sufficient for starters to provide images for stable (they can be updated for every few point updates if needed). What virtualisation solutions should be supported? - Virtual Box seems like a natural candidate since it's free and included since Squeeze. - Vmware has a significant installed base and is relevant, although proprietary - Microsoft Virtual PC is likely also needed - Qemu - Citrix XenServer? For now I would recommend against pre-configured Citrix XenServer releases. I am a Citrix CCNA and I would not recommend that for this very reason. Debian is best set up in Citrix Xenserver from scratch. As far as VMware goes, I use that at home all the time. And with the freely available VMWare Player, I make virtualized Debian installs available to them all the time. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2defb9.2080...@fpsoft.net
Re: Providing official virtualisation images of Debian
Moritz Mühlenhoff wrote: > Do people think this is relevant and are willing to work on providing > one of the images? If so, we could arrange a BoF at DebConf. Moritz, I just want to say that I think its an awesome idea. I'm not at debconf, but I may try to find time to help if something gets going. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725184324.11e0b16dcf298ddaf456c...@gmail.com
Re: Providing official virtualisation images of Debian
On Tue, Jul 26, 2011 at 12:27:09AM +0200, Moritz Mühlenhoff wrote: > What virtualisation solutions should be supported? > - Virtual Box seems like a natural candidate since it's free and > included since Squeeze. > - Vmware has a significant installed base and is relevant, although > proprietary > - Microsoft Virtual PC is likely also needed > - Qemu > - Citrix XenServer? You don't mention KVM explicitly (it's almost identical to Qemu, but fast), or Xen. Anyway, qemu-img can convert a raw disk image into many other formats. So you generate one raw image, and then convert it to any other formats using qemu-img. > How should the images be generated? vmdebootstrap --image=debian-squeeze.img --size=4G \ --mirror=http://cdn.debian.net/debian --distribution=squeeze \ --enable-dhcp --root-password=password1 --user=tomjon/password \ --hostname=squeezebox --package=gnome That should get you started. Vary the packages as you wish, and see also the --customize option for futher tweaking. (vmdebootstrap is not in Debian at this time, but see http://liw.fi/vmdebootstrap/ for the home page, and help with packaging if you start using it, please.) It would probably be nice to have a debian-installer based way to generate the images, so they're as close to a real, installed system as possible, but vmdebootstrap (or one of the other similar tools) will do in a pinch. > IMO the images would need to be created by a DD IMHO, if the project will provide them, then they should be run via cronjobs (or triggered by uploads) on a suitable project machine. > Do people think this is relevant and are willing to work on providing > one of the images? If so, we could arrange a BoF at DebConf. I'm not at Debconf, but you may want to talk to Tom Marble or Zack-the-DPL, who are hosting a BoF on automated testing, which may include some image generation as a side-effect. I'll note that for distribution, offering zsync is probably a good idea: an updated image is going to be almost identical to the previous version of the image, so zsync should save a lot of bandwidth, but does not require running an rsync server. Happy hacking. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725224647.ga26...@havelock.liw.fi
Bug#635453: ITP: ocaml-lo -- OCaml interface to the lo library
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-lo Version : 0.1.0 Upstream Author : The Savonet Team * URL : http://savonet.sf.net/ * License : LGPL-2.1 + link exception Programming Lang: OCaml Description : OCaml interface to the lo library This package provides an interface to the lo library for OCaml programmers. . LibLO is a lightweight, easy to use implementation of the OSC (Open Sound Control) protocol. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725225853.22395.20804.reportbug@leroy
Bug#635458: ITP: libkiokudb-cmd-perl -- command-line tools for KiokuDB
Package: wnpp Severity: wishlist Owner: Tim Retout * Package name: libkiokudb-cmd-perl Version : 0.03 Upstream Author : Yuval Kogman * URL : http://search.cpan.org/dist/KiokuDB-Cmd/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : command-line tools for KiokuDB KiokuDB::Cmd is an App::Cmd based, pluggable suite of commands for KiokuDB, the Perl object persistence framework. . Some commands such as KiokuDB::Cmd::Command::Dump are part of the core distributions, but backends can provide their own subcommands as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725233000.17309.7424.report...@debian.retout.co.uk
Bug#635459: ITP: sump-logicanalyzer -- GUI for logic analysers
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: sump-logicanalyzer Version : 0.8 * URL : http://www.sump.org/ * License : GPL2+ Programming Lang: Java Description : GUI for logic analysers An experimental package is on its way to the archive, maintained at http://svn.debian.org/wsvn/pkg-escience/sumo-analyzer/trunk/?rev=0&sc=0 SM -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725233108.3940.80029.reportbug@Toshiba.siemens
Re: Providing official virtualisation images of Debian
On Tue, 26 Jul 2011 00:27:09 +0200 Moritz Mühlenhoff wrote: > Hi, > I believe it's high time we start to providing Debian in form of > official virtualisation images. In contrast to the ISOs currently I'd certainly find qemu-kvm images handy, Problem might be with the amount of space on the host used by (free space) in the images. > I think it's sufficient for starters to provide images for stable > (they can be updated for every few point updates if needed). > > What virtualisation solutions should be supported? > - Vmware has a significant installed base and is relevant, although > proprietary > - Microsoft Virtual PC is likely also needed > - Citrix XenServer? Would this require the Debian project to go out and buy various bits of proprietary software to build the images with? thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Bug#635462: general: Update manager freezes when started
Package: general Severity: normal Update manager opens then freezes while checking for updates -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725235439.2059.43491.report...@debian.ph.cox.net
Re: Providing official virtualisation images of Debian
On Mon, Jul 25, 2011 at 4:24 PM, Karl Goetz wrote: > On Tue, 26 Jul 2011 00:27:09 +0200 > Moritz Mühlenhoff wrote: > >> Hi, >> I believe it's high time we start to providing Debian in form of >> official virtualisation images. In contrast to the ISOs currently > > I'd certainly find qemu-kvm images handy, Problem might be with the > amount of space on the host used by (free space) in the images. Use qcow2 disk format. >> I think it's sufficient for starters to provide images for stable >> (they can be updated for every few point updates if needed). >> >> What virtualisation solutions should be supported? > >> - Vmware has a significant installed base and is relevant, although >> proprietary >> - Microsoft Virtual PC is likely also needed >> - Citrix XenServer? > > Would this require the Debian project to go out and buy various bits of > proprietary software to build the images with? Of course Debian should not provide images in proprietary formats any more than it distributes non-free software. Proprietary vendors should be able to convert from open formats. Of course qemu-img/kvm-img does support this per its manpage: "vmdk" VMware 3 and 4 compatible image format. Tony -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAOvATiAroTNyew=UuPQTBs15kJJfBY=wjq3y7d-md96gdp...@mail.gmail.com
Re: Providing official virtualisation images of Debian
On mar., 2011-07-26 at 00:27 +0200, Moritz Mühlenhoff wrote: > I believe it's high time we start to providing Debian in form of official > virtualisation images. In contrast to the ISOs currently provided it > allows a quicker evaluation/testing of Debian (and can also be very > useful for testing (e.g. someone wrote on debian-release that he doesn't have > access to oldstable/stable systems, with prepared virtualisation > images that would no longer be an issue). For many setups this could even > replace the installer since software selection and hostname can easily > be tweaked post-install. Not completely relevant, but note that Aurélien Jarno provides Squeeze images for various architectures under qemu at http://people.debian.org/~aurel32/qemu/ Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
