Bug#634124: ITP: cronutils -- Utilities to assist running batch processing jobs
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson * Package name: cronutils Version : 1.0 Upstream Author : Jamie IWlkinson * URL : http://code.google.com/p/cronutils/ * License : Apache Programming Lang: C Description : Utilities to assist running batch processing jobs A set of utilities to complement batch processing jobs, such as those run from cron, by limiting concurrent execution of jobs, setting hard limits on the runtime of a job, and recording execution statistics of a completed job. -- 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/20110717070353.15229.2667.reportbug@localhost
Re: massive bug report to replace "!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386" kludges with dpkg wildcards
Le dimanche 17 juillet 2011 à 07:13 +0100, Neil Williams a écrit : > Debian Evolution Maintainers > >evolution Already fixed in experimental. > Debian GNOME Maintainers > >libproxy (U) Will be in the next upload, no need for the bug report. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: massive bug report to replace hardcoded "kfreebsd-i386 kfreebsd-amd64" with "kfreebsd-any" (where suitable)
Le dimanche 17 juillet 2011 à 00:06 +0200, Robert Millan a écrit : > argyll cdparanoia checkinstall cyrus-imapd-2.2 cyrus-imapd-2.4 > dvd+rw-tools freeglut icecc k3b k8temp kolab-cyrus-imapd libburn > libcdio libgtop2 libisoburn libsysactivity mtx oss-libsalsa qpxtool > sg3-utils xmail xserver-xorg-input-joystick Fixed libgtop2 in svn. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: massive bug report to replace "!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386" kludges with dpkg wildcards
On 07/17/2011 08:13 AM, Neil Williams wrote: > > More usefully, the dd-list of the packages is attached. > > Bernd Zeimetz >gpsd >zbar Both fixed in git, will be included in the next upload. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4e22b9c4.7010...@bzed.de
A few observations about systemd
Dear all, Systemd[1] is the currently fashionable next-generation init replacement, intended to replace both System V init and Ubuntu's upstart. Since the Debian systemd package is now operational, I've decided to try running it on my laptop. Here are my observations after three days with systemd. Please note that this mail is not intended to push Debian's policy in one way or another, which would be premature. Note further that any opinions expressed in this mail are mine, and mine only, and that they are subject to change in the future as I grow older and more stupid. The good Systemd works - It is easy to get systemd to work on a Debian system. Just install the systemd package, and reboot after adding "init=/bin/systemd" to the kernel's command line. (I'm running testing, so I've had to pull a few packages from sid to get systemd to install.) In addition to the issues described on the wiki[1], I'm sufferring from a deadlock on shutdown that is resolved by systemd timing out after a couple of minutes. Systemd is documented - Systemd comes with extensive documentation, in the form of well-written manual pages; additionally, there is a series of (somewhat verbose) blog postings by the author that explain the rationale. (The documentation does need more work, though. For example I couldn't find the complete set of service states, and it took me some time to discover how native and SV services interact.) Systemd makes sense --- Unlike upstart, which I've never managed to get my head around, systemd actually makes sense to me. It has a sane notion of dependency, a relatively sane notion of service, a comprehensible notion of target (the equivalent of a runlevel). While I may not like systemd's obsession with socket activation, it too is a notion that makes sense. Systemd got services right -- What systemd definitely got right are services, in more than one way. ### Services are launched by init With SV init, a deamon is launched by a descendant of whoever started the initscript. The daemon may inherit file descriptors from somebody's login shell, which may end up e.g. preventing a filesystem from getting unmounted. (And no, CLOEXEC is not a solution.) With systemd, services are launched by the init daemon, which has hopefully been able to preserve a clean environment. (This is also the case with all other modern init replacements, notably upstart and runit.) ### Services have a sane life cycle Systemd services have a sane life cycle, and are monitored by systemd in a variety of ways. Thanks to cgroups, systemd is able to reliably kill or restart a service -- no more rogue processes that are left after you've stopped a daemon. (Not everything is perfect, though. Systemd perpetuates SV init's confusion between daemons -- things that keep running -- and initialisation scripts -- things that must be run at some point during the boot process, but don't really have a state.) ### Defining a service is a piece of cake Writing a native service for systemd is a pleasure -- it's a matter of writing a simple config file, in a human-readable syntax (no XML), typically 3 to 6 lines long, and soft-linking it to the right place. Compare that with SV init, where writing an init script takes the best part of an hour and involves getting the syntax of start-stop-daemon wrong at least three times. Most of the features that you'd expect are present, including setuid, redirecting output to syslog, resource limits etc. One thing that I've found missing is the ability to redirect output to a log file in a manner compatible with logrotate (without going through syslog), but perhaps I haven't looked hard enough. The format of a service definition is sane enough to allow for automatic conversion to a different format; I think it would be quite doable to automatically convert systemd's definitions to SV init scripts or to the format of whatever is the next fashionable init replacement after systemd. ### System V initscripts are monitored Unlike all other init replacements known to me, systemd is able to monitor daemons launched from System V init scripts just as reliably as native services. This is an amazingly cool feature. The bad === Systemd is bloated -- Systemd is bloated. It apparently attempts to take over the roles of init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and probably others. The result is that you end up running 5 lines of C code as PID 1, as compared to the 8000 lines of SV init or the 6000 lines of runit. Systemd is layered strangely For a low-level piece of infrastructure, systemd interacts with a lot of high-level software; while this might be okay for a workstation running Gnome, it makes me wonder whether it will be usable on servers. A cursory look shows that systemd intrinsically depends on D-Bus (the *deskt
Bug#634173: ITP: python-fdsend -- Provides a Python abstraction for file descriptor passing via sockets
Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: python-fdsend Version : 0.1 Upstream Author : Michael J. Pomraning * License : GPL2+ Programming Lang: C, Python Description : Provides a Python abstraction for file descriptor passing via sockets fdsend is yet another file descriptor passing abstraction, specifically for Python. This package offers a few conveniences not commonly found together in other abstractions: sending multiple files at once, sending arbitrary data, and working with both files and file descriptors. The package was not downloaded from http://pilcrow.madison.wi.us/sw/fdsend-0.1.tar.gz, because the URL was no longer available. Instead, the source was extracted and repackaged from update-manager's bazaar repository (revision 457): http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main The current packaging can be found on http://opensource.fsmi.uni-karlsruhe.de/cgi-bin/gitweb.cgi?p=fdsend.git;a=tree -- 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/20110717123915.29186.36993.report...@thrall.0x539.de
Bug#634177: ITP: disulfinder -- prediction of S-S bonds in proteins
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: disulfinder * URL : http://disulfind.dsi.unifi.it/ * License : GPL2+ Description : prediction of S-S bonds in proteins 'disulfinder' is for predicting the disulfide bonding state of cysteines and their disulfide connectivity starting from sequence alone. Disulfide bridges play a major role in the stabilization of the folding process for several proteins. Prediction of disulfide bridges from sequence alone is therefore useful for the study of structural and functional properties of specific proteins. In addition, knowledge about the disulfide bonding state of cysteines may help the experimental structure determination process and may be useful in other genomic annotation tasks. 'disulfinder' predicts disulfide patterns in two computational stages: (1) the disulfide bonding state of each cysteine is predicted by a BRNN-SVM binary classifier; (2) cysteines that are known to participate in the formation of bridges are paired by a Recursive Neural Network to obtain a connectivity pattern. The package is about to uploaded to the distribution. -- 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/20110717130047.3821.10681.reportbug@Toshiba.siemens
Re: A few observations about systemd
]] Juliusz Chroboczek (I'm the systemd maintainer in Debian) | Systemd is bloated | -- | | Systemd is bloated. It apparently attempts to take over the roles of | init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and | probably others. The result is that you end up running 5 lines of | C code as PID 1, as compared to the 8000 lines of SV init or the 6000 | lines of runit. I disagree with this and you're muddying the waters: it uses modprobe, it uses mount and setting the host name has always been part of the boot process, so that init is doing this is just a change in the sense that it's done by C code rather than a shell script, so in those cases it just does what is already done by a bunch of shell scripts. as for trying to take over inetd's role: yes, it can replace inetd. You don't have to do that, though. Replace cron and at? Not really, it has support for timer events, but it does not have any replacement for the user part of at and cron, so while it can do some of what at and cron can, it's currently no replacement for them. | For a low-level piece of infrastructure, systemd interacts with a lot of | high-level software; while this might be okay for a workstation running | Gnome, it makes me wonder whether it will be usable on servers. I don't see why it shouldn't be. | A cursory look shows that systemd intrinsically depends on D-Bus (the | *desktop* bus) and knows about Plymouth, RedHat's implementation of | a splash screen. More on that below. It uses dbus as an IPC mechanism rather than inventing its own. It does not depend on dbus-daemon. | Systemd hard-wires special cases | | | Rather than relying on distribution-specific shell scripts, systemd | hard-wires much of its behaviour in C code. The most shocking case, | already mentioned above, is that systemd interacts with Plymouth. This | is not done by using some generic early-boot protocol -- systemd | contains code that is explicitly meant to communicate with Plymouth, the | one and only implementation of a splash screen. What's so shocking about this? If somebody either creates a common API that all splash implementations can use (and make plymouth switch to that), I'm sure systemd will switch too. The point is there is no current generic early boot protocol. | Another case that I've actually been bitten by is that systemd | hard-wires runlevel 5 in its SV init compatibility code; that's merely | inflexible under Fedora, but clearly wrong under Debian. (I've now | fixed my system to run the exact same initscripts in all four multi-user | runlevels.) It does? To the best of my knowledge the Debian package does not treat any of the «normal» runlevels differently. | With systemd, you're no longer supposed to write your service | definitions in shell; instead, you write them in systemd's declarative | language. Where you used to say | | ulimit -d 4000 | | you now say | | LimitDATA = 4000 | | The trouble with that is that while we all know how to write shell | scripts, systemd requires that we learn a new language. What is more, | we are now limited to configuring those aspects that systemd's author | has implemented; this is unlike shell scripts, where we can configure | anything that can be configured either from the shell or from a utility | callable from the shell. ExecStart=/bin/sh -c 'ulimit -d 400; some_daemon' should work just fine. (Sure, it's a bit ugly, and if you have anything that makes sense to make generally available, we'll happily add it.) | Systemd is Linux-specific | - | | Systemd is specific to Linux. This is strange, since the only feature | of Linux used by systemd that doesn't have an exact equivalent on other | systems, cgroups, is optional in systemd. TTBOMK, cgroups are not optional. Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ei1p3upo@qurzaw.varnish-software.com
Re: [kfreebsd] massive report for uninstallable FUSE packages
On Sat, Jul 16, 2011 at 12:33:43PM -0300, David Bremner wrote:
> Depends: fuse [linux-any] | fuse4bsd [kfreebsd-any]
> [..]
> I'm also not sure whether it is better to use '|' or just ',' here.
> Probably it doesn't matter.
I haven't looked into the apt code but from a logical point of view
both ways ('|' or ',') are equivalent since the two filters [linux-any]
and [kfreebsd-any] are mutually exclusive. I would say that '|' fits the
intended meaning better since in any situation one only may have one of
the two dependencies, but that is probably a question of taste.
-Ralf.
--
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/20110717134515.ga7...@free.fr
Re: A few observations about systemd
> (I'm the systemd maintainer in Debian)
(Shakes hands.)
> | Another case that I've actually been bitten by is that systemd
> | hard-wires runlevel 5 in its SV init compatibility code;
> It does?
I stand corrected, it's actually part of the configuration (symlink from
runlevel5.target to multi-user.target). Tollef, should the Debian
package change that?
> | Systemd is specific to Linux. This is strange, since the only feature
> | of Linux used by systemd that doesn't have an exact equivalent on other
> | systems, cgroups, is optional in systemd.
> TTBOMK, cgroups are not optional.
From cgroup.c, line 270:
if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
log_warning("No control group support available, not creating root
group.");
return 0;
}
Note that this returns 0, which stands for success.
-- Juliusz
pgpHcJz9jiNGq.pgp
Description: PGP signature
Bug#634182: ITP: radreplay -- Tests RADIUS servers using pcap dump files
Package: wnpp Severity: wishlist Owner: Ben Brown * Package name: radreplay Version : 0.1 Upstream Author : Ben Brown * URL : https://gitorious.org/radreplay * License : GPLv3 Programming Lang: C Description : Tests RADIUS servers using pcap dump files Reads in RADIUS packets from a file in libpcap format, and then sends requests to a nominated server. It then compares the response it receives from the server with the original response from the libpcap file. -- 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/20110717141828.5455.39576.reportbug@skyvalley.kyussnet.local
Re: A few observations about systemd
]] Juliusz Chroboczek
Hi,
| I stand corrected, it's actually part of the configuration (symlink from
| runlevel5.target to multi-user.target). Tollef, should the Debian
| package change that?
: tfheen@qurzaw /lib/systemd/system > ls -l runlevel?.target
lrwxrwxrwx 1 root root 15 2011-07-07 13:37 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 2011-07-07 13:37 runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel5.target -> multi-user.target
lrwxrwxrwx 1 root root 13 2011-07-07 13:37 runlevel6.target -> reboot.target
: tfheen@qurzaw /lib/systemd/system >
This looks quite correct to me? (It's also what's shipped in the package.)
| > TTBOMK, cgroups are not optional.
|
| From cgroup.c, line 270:
|
| if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
| log_warning("No control group support available, not creating
root group.");
| return 0;
| }
hmm, ok. I suspect it will work much less well without cgroup support
even so, and in general upstream's not interested in supporting
non-linux even if you could make it limp along.
Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
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/87aacc52ej@qurzaw.varnish-software.com
Re: A few observations about systemd
> This looks quite correct to me? (It's also what's shipped in the package.)
I'm confused, then. After installing systemd the first time, systemd
happily ran the init.d scripts that I had disabled in rc2.d but left
enabled in rc{3,4,5}.d. We can probably agree that this is not the
expected behaviour on a Debian system.
Could you point me at where exactly systemd decides which of the rc?.d
services to start?
-- Juliusz
pgpHT46KhYMBl.pgp
Description: PGP signature
Re: A few observations about systemd
On Sun, Jul 17, 2011 at 4:53 PM, Tollef Fog Heen wrote:
>> | > TTBOMK, cgroups are not optional.
> |
> | From cgroup.c, line 270:
> |
> | if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
> | log_warning("No control group support available, not creating
> root group.");
> | return 0;
> | }
>
> hmm, ok. I suspect it will work much less well without cgroup support
> even so, and in general upstream's not interested in supporting
> non-linux even if you could make it limp along.
Indeed, more context is given in the bug mentioned just above that
stanza: https://bugzilla.redhat.com/show_bug.cgi?id=628004, in
particular Lennart's comment:
https://bugzilla.redhat.com/show_bug.cgi?id=628004#c27
"However, it will print a big big warning if you do this, and
will sleep for 5s so that people see it. And I will ignore all bugs reported
when things don't work properly if this is used"
The README also doesn't list cgroups as optional:
REQUIREMENTS:
Linux kernel >= 2.6.30 (with devtmpfs, cgroups; optional but
strongly recommended: autofs4, ipv6)
So cgroups is "optional", but not really if you want a supported
systemd installation :)
--
Matt Brown
m...@mattb.net.nz
Mob +353 86 608 7117 www.mattb.net.nz
--
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/CAMgEDbQU4h=opuiqr4mck-jyxyhd6-p1f9roybq9o1mfufv...@mail.gmail.com
Re: A few observations about systemd
> So cgroups is "optional", but not really if you want a supported > systemd installation :) Yes, and that's exactly what I find worrying about Lennart's attitude: he presumes to impose his policy on you -- you must use Linux, you must use a recent kernel with cgroups enabled, you're not supposed to use shell scripts, etc. I really like systemd, but not to the extent of giving up the ability to pick my own policy. -- Juliusz -- 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/8739i4dgat@trurl.pps.jussieu.fr
Ask the Leader - Q&A session for the DPL at Debconf
Hi all, One of the events at DebConf that I'm running is a 'Ask the Leader' session. This is a town hall meeting event, where you have the opportunity to ask the DPL anything you want! To make sure we have enough questions on a broad range of topics, I'd like to get some prepared questions beforehad. Note that the DPL won't see these, or have time to prepare his answers. There'll also be a session of questions from the floor. You don't need to be attending to ask, simply drop a mail to ne...@debian.org and I'll try and get as many questions put as possible. Thanks, Neil -- Ganneff is just a big cuddly teddy bear. Our photo proves it. -- 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/20110717164955.gw...@feta.halon.org.uk
Bug#634204: ITP: libecap -- eCAP library allows network application to outsource content analysis
Package: wnpp Severity: wishlist Owner: Luigi Gangitano * Package name: libecap Version : 0.2.0 Upstream Author : Alex Rousskov and The Measurement Factory * URL : http://www.e-cap.org/ * License : Simplified BSD License Programming Lang: C++ Description : eCAP library allows network application to outsource content analysis eCAP is a software interface that allows a network application, such as an HTTP proxy or an ICAP server, to outsource content analysis and adaptation to a loadable module. For each applicable protocol message being processed, an eCAP-enabled host application supplies the message details to the adaptation module and gets back an adapted message, a "not interested" response, or a "block this message now!" instruction. These exchanges often include message bodies. -- 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/20110717172005.1656.10905.report...@seneca.lugroma3.org
Re: A few observations about systemd
]] Juliusz Chroboczek
| > This looks quite correct to me? (It's also what's shipped in the package.)
|
| I'm confused, then. After installing systemd the first time, systemd
| happily ran the init.d scripts that I had disabled in rc2.d but left
| enabled in rc{3,4,5}.d. We can probably agree that this is not the
| expected behaviour on a Debian system.
This does sound somewhat surprising if nothing else pulled them in
through dependencies, yes.
What does systemctl show $service tell you? Particularly the
SysVRunLevels line is interesting to see that it picked up the lines
where it should be run properly.
| Could you point me at where exactly systemd decides which of the rc?.d
| services to start?
default.target
The default unit systemd starts at bootup. Usually this should be
aliased (symlinked) to
multi-user.target or graphical.target.
The default unit systemd starts at bootup can be overridden with the
systemd.unit= kernel command
line option.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
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/8762n04scq@qurzaw.varnish-software.com
Re: A few observations about systemd
On Sun, Jul 17, 2011 at 03:25:23PM +0200, Tollef Fog Heen wrote: > | Systemd is bloated > | -- > | > | Systemd is bloated. It apparently attempts to take over the roles of > | init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and > | probably others. The result is that you end up running 5 lines of > | C code as PID 1, as compared to the 8000 lines of SV init or the 6000 > | lines of runit. > > as for trying to take over inetd's role: yes, it can replace inetd. You > don't have to do that, though. It does remove the important option to not have an inetd at all. And this millenium, you'd have to look hard to find any use for inetd. I guess a number of other parts of systemd share this problem. -- 1KB // Yo momma uses IPv4! -- 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/20110717193711.ga30...@angband.pl
Systemd and rc2.d vs rc5.d [was: A few observations about systemd]
> What does systemctl show $service tell you? I've now reconfigured my laptop to have identical rc?.d directories, so I cannot easily reproduce the issue. > | Could you point me at where exactly systemd decides which of the rc?.d > | services to start? >default.target It's linked to graphical.target. How is the right runlevel?.target pulled in? -- Juliusz -- 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/87tyakbqm8.fsf...@trurl.pps.jussieu.fr
Re: Systemd and rc2.d vs rc5.d
]] Juliusz Chroboczek | > | Could you point me at where exactly systemd decides which of the rc?.d | > | services to start? | | >default.target | | It's linked to graphical.target. | | How is the right runlevel?.target pulled in? graphical.target Requires multi-user.target and multi-user.target has: Names=multi-user.target runlevel5.target runlevel4.target runlevel3.target runlevel2.target I guess that might explain why some things were started in the wrong runlevel too. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/871uxo4l4i@qurzaw.varnish-software.com
Bug#634235: ITP: mess-desktop-entries -- Desktop entries for MESS ROMS
Package: wnpp Severity: wishlist Owner: Jordi Mallach * Package name: mess-desktop-entries Version : 0.2 Upstream Author : Matthew Barnes * URL : none * License : GPLv3 Programming Lang: none Description : Desktop entries for MESS ROMS This is a collection of desktop entries to handle ROM files for certain game consoles. They use the Multiple Emulator Super System (MESS) to start a game by simply double-clicking the ROM file from a file manager. -- 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/20110717230237.10376.25877.report...@aigua.oskuro.net
Bug#634241: ITP: disper -- display switcher for attaching/detaching displays easily
Package: wnpp Severity: wishlist Owner: Vincent Cheng * Package name: disper Version : 0.3.0 Upstream Author : Willem van Engen * URL : http://willem.engen.nl/projects/disper/ * License : GPL3 Programming Lang: Python Description : display switcher for attaching/detaching displays easily No more headaches just before your presentation. Disper lets you add and remove display devices at the press of a button. It detects what display devices are attached at the moment, and configures the display output automatically. You can specify whether to clone the output on all displays, or to extend the desktop. -- 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/20110718052158.22069.91522.reportbug@vincent-laptop
Re: A few observations about systemd
Le dimanche 17 juillet 2011 à 13:54 +0200, Juliusz Chroboczek a écrit : > Systemd is bloated > Systemd is layered strangely > Systemd hard-wires special cases > Systemd deprecates shell scripts I disagree these are real, practical issues - some of these aren’t even problems but features. > Systemd is Linux-specific > Systemd's author is annoying Developing for Linux-only is fine, but Lennart has explicitly said that he wouldn’t remotely consider accepting portability patches, which goes further than any other piece of free software I had to deal with. We need one and only one init system in Debian. (Those considering maintaining several init systems in parallel do not see how stupid, bloated and error-prone it would be to require all daemon maintainers to maintain more init scripts than they do now.) I’d like to see systemd as that one init system, but this challenges the future of kfreebsd. If kfreebsd is really more than a toy operating system and we want users to do something with it, the porters need to maintain a kfreebsd branch of a modern init system (be it upstart or systemd). -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
