Re: GOAL: Consistent Keyboard Configuration
>>>>> "DF" == David Frey <[EMAIL PROTECTED]> writes: :: Then I have a "Print" key, "Scroll-Lock", and "Pause". All :: three keys don't have an effect in my X configuration--on the :: console "Scroll-Lock" starts/stops terminal output, just like :: "C-S and C-Q". Is there any useful meaning for "Print" and :: "Pause" in Linux? DF: Yes they may the registers, task list etc. and may switch DF: from/to the last used console. There is another possible usage -- switching between different keyboards. For example Czech Linux users usually use one of these keys for switching between US keyboard (when programming) and Czech keyboard (when writing texts). I think the best what to do with these keys is not to assign anything to them and left them as free function keys for users. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
>>>>> "GM" == Guy Maor <[EMAIL PROTECTED]> writes: GM: David Frey <[EMAIL PROTECTED]> writes: :: Must all new programs goint into unstable be linked with libc6? GM: Since Debian 2.0 is meant to be a libc6 system, the answer is yes. Well, if I install libc6 now, wouldn't it break compilation of some programs? I'm dependent on my Debian machine, so I can't perform too hard experiments with it. And if I can't install libc6 safely enough now, does it mean I really shouldn't upload new versions of my packages? Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
>>>>> "BW" == Brian White <[EMAIL PROTECTED]> writes: :: * July 15th: All libraries *must* be libc6. :: * July 31th: All packages must be libc6. What about: * June 30th: Bug reports on all non-libc6 libraries. * July 15th: All libraries libc6 compatible. * July 31th: Bug reports on all libc5 packages, uploads of such packages no longer allowed. * August 31th: libc5 packages removed. BW: Do we also want to remove all libc5 dependant packages at some BW: point? I think this would be a good idea since otherwise BW: things are going to get pretty messed up. I agree. We should avoid repeating situation, when we had a.out packages in ELF system. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How do we encourage bug reports?
One problem with reporting bugs I feel personally is what to do to avoid repeating reports. I use the following algorithm, when I discover a bug: 1. I go through the list of pending bugs posted to bug list periodically, and check whether it could be reported. 2. I'm searching through my mail archive for bug server address and guide. 3. I request bug messages I've found in 1. from bug server to check if they reported my bug or not. 4. I wait several hours for answer (maybe because of slow connection somewhere -- because of various reasons I have from Middle Europe much more better connection to U.S. than to most European countries). 5. I forget that reported bug may be also corrected and closed in unstable. 6. If I think my bug is not reported yet, I send bug report. This algorithm is very annoying and I think some steps could be avoided (but I've no idea how). I prefer e-mail interface over WWW because of my slow connection. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: Status of Debian Policy
>>>>> "MB" == Marco Budde <[EMAIL PROTECTED]> writes: MB: The most beginners don't like info because there's no good MB: browser. I would vote for texi2html because it look's much MB: better than info2html and the user doesn't need a WWW server. There is one good info browser: GNU Emacs. On the other side I don't know any good browser for HTML, that's the main problem of HTML documentation. OK, if HTML was chosen as Debian documentation format, why not. But I really don't know why to waste my limited disk space for (mostly uncompressed!) HTML documents, when (from my point of view) better format is available. MB: I think we should use HTML in the packages. Additional we MB: could produce postscript files for printing. Further wastage of disk space for many users. I know it was said many times, but AFAIK nothing happened yet: the best choice is to provide facility to install chosen and/or prefered type (HTML, info, postscript, text, ...) of documentation if available. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
I like this proposal too. Yet another reason, why separate docs could be good: Sometimes I want only to check documentation, read more about something (e.g. some toolkit and/or programming language) and I don't want to install 20 MB package when I need only 1 MB documentation which I want to read at evenings. Problems with increasing number of packages is a problem of user interface, nothing more. And I think creating doc packages is the only simple (i.e. possible to have in reasonable time) solution we have now. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: Status of Debian Policy
>>>>> "MB" == Marco Budde <[EMAIL PROTECTED]> writes: MZ: I don't know any good browser for HTML, that's the main MZ: problem of HTML documentation. MB: Your're kidding ;-)? There're several really great HTML MB: browsers like netscape, lynx etc. No. Problems with netscape: - It's non-free. - It's buggy. - It's big. - It can't run on text console. - It has only very limited searching and navigation facilities. (Netscape is crippelware IMHO.) Problems with HTML/lynx for any user: - Limited possibilities of handling gzip files (typing xxx.html doesn't find xxx.html.gz) => problems with links (may be solvable by CGI skript => overhead on my notebook with only 8~MB RAM). - Limited searching facilities (general problem of HTML). - No indices, quick menu selection (see Emacs info documentation). - No highlighting/coloring? (I'm not sure.) Problems with HTML/lynx for Emacs users (they're many I think, so don't forget them, please): - How to do cut & past easily. - Incompatible key bindings. - No direct access to documentation (like word-help). - Yet another window/console. (w3-el is not solution -- it's very slow.) Etc. I can see no reason for *dropping* info. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Anyone using transparent proxying?
>>>>> "MM" == Michael Meskes <[EMAIL PROTECTED]> writes: MM: Do you really run it? The way I hear it from the authors (and MM: according to my own experience) it won't work with 2.0.30 MM: either. It's broken and these guys don't know yet, how to MM: repair it. The last working version was 2.0.29. BTW, it works for me only with tcp protocol in 2.0.29. I wasn't successful with udp redirection. :-( Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
>>>>> "MS" == Martin Schulze <[EMAIL PROTECTED]> writes: MS: Da Platten immer billiger werden ist Diskspace wirklich kein MS: Argument mehr, solange es um Daten <100MB geht. Sorry, I've no money to take the 500 MB disk in my notebook, throw it away and buy new one for many $s. And I think there are other cases when disk space *is* limited. On my computer there is about 400 MB of Debian, what contains 30 MB of docs. It's less than 10% so it's OK, but if size of docs will grow considerably after implementing new standards, it will become a problem. >>>>> "PT" == Philippe Troin <[EMAIL PROTECTED]> writes: :: Option 3: We ship .texi files and produce HTML and/or info :: files on demand (in the postinst script). PT: I like this idea a lot. I *hate* having to fetch the source PT: package to produce a postscript output... Seconded. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
>>>>> "CL" == Christian Lynbech on satellite <[EMAIL PROTECTED]> writes: CL: I think the number one question we need to address is whether we CL: want to support running Xemacs and GNU emacs at the *same* time. Of course we want. There are some *multiuser* Debian machines. :-) Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
>>>>> "MS" == Manoj Srivastava <[EMAIL PROTECTED]> writes: MS: Hi, Also consider the fact that all maintainers may not have MS: enough resources to have all possible flavours of Emacsen on MS: their machines (Xemacs19, Xemacs20, emacs19, emacs20, MS: emacs20-no-mule, Xemacs-no-mule, ...), and keep track of which MS: versions were elc compatible anyway. MS: On the other hand, some packages (Quassia gnus and VM MS: are examples) that do funny things in the Makefile in order to MS: compile the el files; it is not just a matter of # $(EMACS) MS: -batch -f batch-byte-compile *.el MS: Alternately, each maintainer can maintain a package for MS: one flavour of Emacs ;-(, and have co-maintainers for ther MS: flavours. Autocompilation may not be quite as trivial as it may MS: seem (though by no means impossible). I agree. What I would prefer as a user is to have multiple packages: foo-el.deb foo-elc-emacs.deb foo-elc-xemacs.deb foo-elc-whateveremacs.deb ... In debian/rules could be checked, which Emacsen are installed and only appropriate elc packages are created. So different co-maintainers of the foo with different Emacsen could produce different sets of elc packages just by building debs from the source package. There are some problems with maintaining the source package (the primary maintainer should incorporate changes of other maintainers, for Emacsen he has not installed), but I can't imagine better solution. Note that in this case the building of foo is system installation dependent. However produced deb packages are not system installation dependent, only the *sets* of builded deb packages are different. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Recompiling elisp files (Re: Taking over production of emacs20 package.)
Two further small reasons against install time .el compilation of large packages: 1. I have to install .el sources even when I don't need them. 2. Slow installation. The first is a problem on computers with limited disk space (e.g. my laptop). The second is the problem when I perform major upgrade. I can go to get some koffee during unpacking packages, but then I have/want to answer some installation questions. If things like gnus was compiled during this procedure, I'd be angry (things like texhash and menu/manpage updates on background are annoying enough already). Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private
>>>>> "AY" == Alex Yukhimets <[EMAIL PROTECTED]> writes: AY: Nothing strange. After a couple of _years_ of struggling in AY: attempts to learn emacs (I made about 6 attempts total) I found AY: a *great* relief in... vi (vim actually). I was able to get AY: used to it only after 2-nd attempt. :-) Oh, I hope vim handles followups correctly, so we have a solution for non-Emacs people too. ;-))) BTW, I have all public Debian lists merged into a single nnml group in Gnus. So I can't use `reply-to' group parameter simply. Does anybody know, how to (simply) followup only to the appropriate list (I delete other addresses manually now :-( )? Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
>>>>> "EZ" == Enrique Zanardi <[EMAIL PROTECTED]> writes:
EZ: The problem with that approach is that many of those "newbie"
EZ: settings are just a matter of taste. We don't want to set a
EZ: thousand of those parameters in hundreths of different config
EZ: files that will have to be edited to reset them.
EZ: It would be easier if all those parameters could be grouped in
EZ: a single config package. We may have a handful of those to
EZ: choose (hint: "themes"). It may even be useful for
EZ: localization!
1. I don't know whether I like the idea of a single config package or not
but I can see the following questions:
- Is it easy/possible to maintain single config package for many
programs?
- Isn't it better to let this work to each package maintainer because
he does probably understand it very well? I don't think there
are many (hundreds) packages which need some kind of newbie
customization. If I understand it well it should be about ten to
twenty files in `/etc/skel/'.
- On the other side wouldn't be better to let this configuration
things to one package with one maintainer ("newbies manager"), who
could watch newbies questions on debian.user etc. so he knows what
the *real* problems are?
2. IMO, there is no problem with settings like bash prompt customized for
newbies, if such settings are not too much annoying for many people
(they shouldn't, it's not good idea to introduce newbies to annoying
things). I think any advanced user copies his .profile, .bash*,
.xinitrc, .fvwm* or whatever soon to his new account on which he
intends to work regularly. So he is almost indifferent to these
settings.
3. BTW, to discussion about long dirs in prompt, why not to use two lines
prompt? I have in .bashrc
MACHINE=$(uname -n)
MACHINE=${MACHINE%%.*}
PS1='
$PWD
$MACHINE$ '
and I'm very satisfied with it.
Milan Zamazal
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
I know nothing about runlevel standards, just my opinions: >>>>> "AK" == Alexander Koch <[EMAIL PROTECTED]> writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) 5: empty for making special local runlevel? So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ITP: dpkg-python
Unless anybody else is interested, I plan to pick up the Python part of dpkg-scriptlib and make it a separate (and maintained:-) package. I also plan to enhance it with few lines of code I wrote for some thing--adding few classes for interfacing Sources/Packages with LDAP (yes, this should work (not only) with data produced by Ben Collin's scripts). Milan Zamazal -- "Having GNU Emacs is like having a dragon's cave of treasures." Robert J. Chassell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Full install/removal/upgrade test results available
>>>>> "LN" == Lucas Nussbaum writes: Milan Zamazal cl-clx-sbcl cl-flexichain cl-mcclim cl-mcclim-examples cl-spatial-trees cl-speech-dispatcher cl-swank (U) slime (U) These, as well as probably other cl-* packages, fail because they depend on common-lisp-controller which fails. crm114 This is a very special case: The package may not be upgraded without user intervention (a debconf question) in order to prevent possible mail loss. -- 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/87zkt43pk4@blackbird.nest.zamazal.org
Bug#219575: ITP: sound-icons -- Sounds to be used for event signalization in speech enabled applications
Package: wnpp Severity: wishlist * Package name: sound-icons Version : 0.1 Upstream Author : Brailcom, o.p.s. <[EMAIL PROTECTED]> * URL : http://www.freebsoft.org/pub/projects/sound-icons/ * License : GPL Description : Sounds to be used for event signalization in speech enabled applications This package contains sound icons that are useful especially when running Speech Dispatcher.
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
>>>>> "GM" == GOTO Masanori <[EMAIL PROTECTED]> writes: GM> At Mon, 17 Nov 2003 09:22:37 +0900, GM> Kenshi Muto wrote: >> And this package is must be removed from only Woody (already >> fixed in Sarge/Sid): >> >> xfonts-intl-japanese-big (Bug#215371) GM> I think it's good idea to update this package to the latest, GM> instead of removing from woody. Milan, do you think about this? If only japanese-big is to be removed, then intlfonts must be removed as whole, since .orig.tar.gz contains the offending fonts. For this reason I've uploaded a woody update of the package (intlfonts_1.2.1-0.woody.1) several days ago, that can replace the current woody version. Regards, Milan Zamazal -- And why?
Re: Debian Accessibility Project was: Re: linux for blinds
>>>>> "AT" == Andreas Tille <[EMAIL PROTECTED]> writes: AT> To make it clear: I'm not in fear of a separate distribution. AT> Everybody is free to do so. But in my opinion you could reach AT> your goal more straightforeward if you do not. I'd like to clarify a confusion introduced by me (my fault). Actually we don't intend to make a separate distribution, but rather a specialized non-standard installation process. Once the system gets installed, it won't differ from a standard Debian system, using several packages from testing/unstable and several non-Debian packages (i.e. packages not worth to be included in Debian in the given moment). AT> I see no reason to go separate ways and join later. Why not do AT> it inside Debian? The reason is our resources are very limited and making what we need inside Debian implies more general solution, i.e. more work. Exceeding the resources would mean failure of the project. We try to find a minimum-work solution, the minimum step, even if it may require more work in the future. I can remember there were some discussions on Debian mailing lists about making something like debian-blind quite long time ago. But AFAIK nothing actually happened till now. So I guess there's no critical potential to utilize the Debian resources for *this particular task*, until some initial steps are done. I might be wrong, but we can see a manageable solution of our problem now and we prefer it against a potentially better, but quite *risky* way of reaching what we desperately need. AT> But I think enhancing debian-installer in the current state is AT> the best idea to reach the goal. I'll certainly look at debian-installer, it might be the right tool to help us. Just FYI, we basically need to *clone* a running Debian system to target computers, while making a few necessary customizations, like changing the network and hardware setup of the target machine. tar + a few shell scripts look like the simplest way to do that, but debian-installer might possibly help us especially with the booting process and hardware autodetection. AT> Good luck for you project Thanks and thank you for your comments. Regards, Milan Zamazal -- Todays marketing hype top-list report: http://www.google.com/search?q=attract+best+build+business+component+deploy+embed+feature+framework+free+highest+industry+integration+ISV+Java+manage+most+MVC+.NET+newsletter+OEM+performance+platform+portable+rapid+ready+scalable+secure+SOAP+solution+special+support+technology+Web+XML
Re: SWI Prolog and GNU Prolog packages
>>>>> "SS" == Sebastian Schaffert <[EMAIL PROTECTED]> writes: SS> I would be willing to take over the maintanance of these two SS> packages Please try to coordinate with Silvester Claassen [s.m.claassen at stalemate.nl], who expressed an interest to take over the packages (but haven't uploaded them for long time, so I don't know whether he's still interested in them), and Salvador Pinto Abreu [spa at di.uevora.pt], who is an upstream GNU Prolog developer and wanted to take over gprolog too (he stepped down in favor of Silvester originally). Regards, Milan Zamazal -- Here is my advice, don't try to program the bleeding edge for the general populace unless you really, really, really like migraines. Neal H. Walfield
Re: Debian default desktop environment
> "JM" == Josselin Mouette writes: JM> This is mostly irrelevant. The resources consumed by the desktop JM> are negligible compared to applications. As soon as you start a JM> browser with a few tabs on non-trivial websites, 1 GiB of memory JM> is barely enough. Regardless of the desktop environment. FYI, Xfce + Firefox runs fine on a >10 years old computer with 256 MB RAM for all practical needs of the user. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha682jge@blackbird.zamazal.org
Offering packages
I'm offering most of my packages. I will still maintain those of them, which nobody wants to take over. Maintenance of most these packages is trivial, upstream releases are rare. Since some of them are related to Czech, Slovak, or Latin-2 environment, it could be good opportunity for someone from Czech Republic or Slovakia to take some of them and become a new Debian maintainer. The list of offered packages: comm/casio - Casio diary backup utility text/cstocs - recoding utility (Latin-2 countries charsets mostly) devel/cweb - literate programming in C/C++ devel/cweb-latex- CWEB with LaTeX editors/emacs-czech - Czech and Slovak support for Emacs 19 games/fortunes-cs - Czech and Slovak fortunes math/sgb- The Stanford Graphbase x11/xntil2 - Latin-2 fonts for X x11/xtoolwait - serializing startup of X applications I would be especially happy if anyone took sgb, which is a program I never use. Milan Zamazal -- "Having GNU Emacs is like having a dragon's cave of treasures." Robert J. Chassell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JED anyone?
`jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. Milan Zamazal -- "Having GNU Emacs is like having a dragon's cave of treasures." Robert J. Chassell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package LEIM
Is there any technical reason why LEIM (Emacs input methods) is not available as a Debian package? If not, I'll package it. Milan Zamazal -- "Having GNU Emacs is like having a dragon's cave of treasures." Robert J. Chassell
Intent to package intlfonts
I'd like to package intlfonts for X available on GNU FTP. They are especially useful for Emacs. Since this package is big, I'll probably make several smaller binary packages from it. Milan Zamazal
Re: Intent to package LEIM
>Milan Zamazal <[EMAIL PROTECTED]> writes: >> Is there any technical reason why LEIM (Emacs input methods) is not >> available as a Debian package? If not, I'll package it. >FWIW It's already part of the emacs20 package. I'd say including LEIM data *.elc files is worth. I think it's difficult for an unexperienced Emacs user to FTP and install LEIM himself. But maybe only an experienced Emacs user needs inputing through LEIM instead of system keyboard (which doesn't work in X for Czech anyway:-) for features like different keyboards in different buffers (which is important for some languages) and occasional inputting characters of foreign languages. I'm not sure. So do you really think leim package would be totally unnecessary? Any other opinions? Thanks. Milan Zamazal
Re: Intent to package LEIM
Grr, after I uploaded it I've found emacs20 *source* package already contains all the LEIM data files, so I removed the uploaded leim package. I think the best solution would be to produce leim binary package from the emacs20 source package. Rob, could you do so in the next version of the emacs20 package please? Thanks. Milan Zamazal
X-fonts and fonts.alias
What's the current policy about adding new names into fonts.alias in a directory shared by more Debian packages? Thanks for any advise. Milan Zamazal
Orphaning libapache-mod-fastcgi, emacs-czech
I orphan the following two packages: libapache-mod-fastcgi (non-free) I just uploaded version updated for Apache 1.3.9 and FHS, so if anyone wants it, it shouldn't be difficult to take it. emacs-czech Emacs 19 is obsolete, there is no need to use it anymore after 20.4 release. If you think otherwise and need Czech or Slovak support for Emacs 19, take this package. Milan Zamazal
Bug#808828: ITP: mom -- Dynamically manage system resources on virtualization hosts
Package: wnpp Owner: Milan Zamazal Severity: wishlist * Package name: mom Version : 0.5.1 Upstream Author : * URL or Web page : https://github.com/oVirt/mom * License : GPL2 Description : Dynamically manage system resources on virtualization hosts MOM is a policy-driven tool that can be used to manage overcommitment on KVM hosts. Using libvirt, MOM keeps track of active virtual machines on a host. At a regular collection interval, data is gathered about the host and guests. Data can come from multiple sources (eg. the /proc interface, libvirt API calls, a client program connected to a guest, etc). Once collected, the data is organized for use by the policy evaluation engine. When started, MOM accepts a user-supplied overcommitment policy. This policy is regularly evaluated using the latest collected data. In response to certain conditions, the policy may trigger reconfiguration of the system’s overcommitment mechanisms. Currently MOM supports control of memory ballooning and KSM but the architecture is designed to accommodate new mechanisms such as cgroups.
Bug#808829: ITP: vdsm -- Virtual Desktop Server Manager
Package: wnpp Owner: Milan Zamazal Severity: wishlist * Package name: VDSM Version : 4.17.14 Upstream Author : * URL or Web page : http://www.ovirt.org/Vdsm * License : GPL2 Description : Virtual Desktop Server Manager The VDSM service is required by a oVirt Open Virtualization Manager to manage the Linux hosts. VDSM manages and monitors the host's storage, memory and networks as well as virtual machine creation, other host administration tasks, statistics gathering, and log collection.
Bug#808834: ITP: ioprocess -- Slave process to perform risky IO
Package: wnpp Owner: Milan Zamazal Severity: wishlist * Package name: ioprocess Version : 0.15.1 Upstream Author : Saggi Mizrahi * URL or Web page : https://github.com/oVirt/ioprocess * License : GPL2 Description : Slave process to perform risky IO When performing IO over network storage (specifically NFS) the process might get stuck in D state. To prevent your main process from becoming unkillable you might prefer to have a slave process to do all the risky IO. This is what ioprocess is for.
ITA (hijack) sanlock
The sanlock package is unmaintained, it hasn't been updated for 3 years. I tried to contact its maintainer (not a DD) twice during the last months without any response. So unless anybody objects, I'm going to take over the package.
