Bug#480453: ITP: libdatamapper-ruby -- Object relational mapper for Ruby
Package: wnpp Severity: wishlist Owner: Sebastien Delafond <[EMAIL PROTECTED]> * Package name: libdatamapper-ruby Version : 0.3.0 Upstream Author : * URL : http://datamapper.org * License : MIT Programming Lang: Ruby Description : Object relational mapper for Ruby DataMapper is a Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mail headers for automated package maintenance emails
Hi, On Sat, 10 May 2008, Joerg Jaspert wrote: > X-Debian: $TOOL > X-Debian-Package: $PACKAGE > [...] > As a starting point, and as one tool generating lots of mail to > maintainers, DAK is already generating both headers, other tools > hopefully follow soon. The PTS now provides those headers as well. X-Debian: PTS X-Debian-Package: Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480509: ITP: mudkip-player -- an XMMS replacement
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: mudkip-player Version : 1.0~pre1-hg20080510 Upstream Author : William Pitcock <[EMAIL PROTECTED]> * URL : http://www.nenolod.net/mudkip-player (pending) * License : GPL Programming Lang: C Description : an XMMS replacement Mudkip-player is a combination of the Audacious 1.5 and BMPx (old XMMS-like version) codebases. It behaves like XMMS and includes a few useful enhancements. Mudkip is based on GStreamer and is not compatible with XMMS plugins, but includes select features from both BMPx and Audacious. -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480510: ITP: lenmus -- music education software to learn music theory and lenguage
Package: wnpp Severity: wishlist Owner: Juan Manuel Garcia Molina <[EMAIL PROTECTED]> * Package name: lenmus Version : 3.6 Upstream Author : Cecilio Salmeron <[EMAIL PROTECTED]> * URL : http://www.lenmus.org/ * License : GPL Programming Lang: C++ (wxWidgets) Description : music education software to learn music theory and lenguage LenMus is a music education software that you can use to practice your music reading skills, improve your aural recognition abilities or just learn the fundamental principles of music theory and language. It allows you to focus on specific skills and exercises, on both theory and aural training. The different activities can be customized to meet your needs. And provides interactive feedback until mastery of each concept is achieved. It will include a notation editor. -- System Information: Debian Release: lenny/testing APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.24-1-powerpc Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to es_ES.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480514: general: buildd.emdebian.org : Need a crossbuilding buildd compliant with Emdebian Policy
Package: general Severity: wishlist This is filed against general in advance of a buildd.emdebian.org pseudo-package becoming available. See #480408 Emdebian has a set of prebuilt binary packages which allow an 80% reduction in the total installation size of the final Debian system, acheived through the use of TDebs, DEB_BUILD_OPTIONS and patches held in Emdebian SVN. Currently, I am maintaining just over 210 source packages (over 600 binary packages) with manual builds and patches but in order for Emdebian to support armel and i386, an autobuilder is needed. Basic script support for a cross-building buildd exists in emdebian-tools, work is still needed to get this working smoothly and then implement on a suitable machine: http://buildd.emdebian.org Emdebian also has a developing Policy that is based on Debian Policy - a wiki page indicates where the two documents differ: http://wiki.debian.org/EmdebianPolicy The autobuilder would use existing lintian support to ensure that crossbuilds are compliant with Emdebian Policy, principally that the crossbuilt binaries really are the correct architecture. Maintaining these packages via manual builds is unsustainable and causes problems with a usable testing/stable migration because certain versions might simply not exist in the repository when a migration should occur. The lack of internet-visible build logs is also a significant problem for helping other people begin developing their own packages for Emdebian. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480515: buildd.emdebian.org: gconf unable to be uploaded, libldap-2.4-2 failed to cross build
Package: general
Severity: normal
In preparation for a pseudo-package, buildd.emdebian.org, I'm filing
status bugs about packages that block the use of packages that
crossbuild successfully.
libldap-2.4.2 fails to cross build:
configure: error: crossing compiling: use
--with-yielding_select=yes|no|manual
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
In this particular case, the initial fix is probably a value in the
cache file but the dependencies of libldap also cause problems due to a
failure to cross build liborbit2.
gconf cannot be uploaded as it would result in broken dependencies:
Checking for error logs in /opt/emdebian/trunk/g/gconf/trunk/
gconf2 (= 2.22.0-1em1): FAILED
libgconf2-4 (= 2.22.0-1em1): FAILED
gconf2 (= 2.22.0-1em1) depends on libgconf2-4 (>= 2.13.5) {libgconf2-4
(= 2.22.0-1em1)}
libgconf2-4 (= 2.22.0-1em1) depends on libldap-2.4-2 (>= 2.4.7) {NOT
AVAILABLE}
libgconf2-4 (= 2.22.0-1em1) depends on libldap-2.4-2 (>= 2.4.7) {NOT
AVAILABLE}
Thu May 8 00:56:43 BST 2008
This bug is blocked by the problems in libldap but is also blocking the
use of gpe-filemanager which requires gconf.
Due to the lack of a crossbuilding buildd, the build logs are not
internet-visible at this time. Builds can be reproduced using
emdebian-tools.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480518: buildd.emdebian.org: libgpewidget needs DEB_BUILD_OPTIONS="nodocs" support in debhelper
Package: general Severity: normal libgpewidget includes documentation files required by Debian Policy and is unable to remove these using the DEB_BUILD_OPTIONS="nodocs" option due to a lack of support for this option in debhelper. Documentation needs to be removed when preparing Emdebian packages in order to comply with Emdebian Policy. http://wiki.debian.org/EmdebianPolicy Currently, this means that libgpewidget needs to be crossbuilt with a patch for debian/rules. This bug is being filed in preparation for a pseudo-package, buildd.emdebian.org, where these issues can be set out and fixed. The intention is to provide simple support for Emdebian packages without needing patches by filing appropriate bug reports against the packages themselves and against packages that block such actions as well as tracking bugs filed against buildd.emdebian.org so that the overall status of the Emdebian builds is visible to anyone, not just the person doing the builds (me). This is not a bug in libgpewidget because libgpewidget is doing what is required by Debian Policy - it is a bug in buildd.emdebian.org because Emdebian needs to be able to build as many packages as possible without any patches and this requirement is blocked by #448615. i.e. Where the need for a patch can be removed by fixing a package already in Debian, the bug is in buildd.emdebian.org until the bug in the relevant package is closed (in this case, debhelper). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: block 480518 with 448615
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.27 > block 480518 with 448615 Bug#448615: dh_installdocs : Please consider a separate handler for debian/copyright for embedded use Bug#480518: buildd.emdebian.org: libgpewidget needs DEB_BUILD_OPTIONS="nodocs" support in debhelper Was not blocked by any bugs. Blocking bugs of 480518 added: 448615 > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480521: buildd.emdebian.org: gpe-clock inherits wrong configure environment
Package: general Severity: normal This bug is in preparation for a buildd.emdebian.org pseudo-package. This is not a bug in gpe-clock because gpe-clock is doing what is required by CDBS - it is a bug in buildd.emdebian.org because Emdebian needs to be able to build as many packages as possible without any patches and this requirement is blocked by #450483 i.e. Where the need for a patch can be removed by fixing a package already in Debian, the bug is in buildd.emdebian.org until the bug in the relevant package is closed (in this case, cdbs). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: block 480521 with 450483
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.27 > block 480521 with 450483 Bug#450483: cdbs: Stop setting DEB_CONFIGURE_SCRIPT_ENV in order to enable cross-building Bug#480521: buildd.emdebian.org: gpe-clock inherits wrong configure environment Was not blocked by any bugs. Blocking bugs of 480521 added: 450483 > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Manpages for binaries not in $PATH
Hi all, I'm trying to cut down john's bugs [0], and I've encountered #132223 [1]. As the previous maintainer did, I would have marked that bug as wontfix, because a normal user shouldn't normally run programs not in $PATH. However, re-reading the Policy, it states: +==> §12.1 | Each program, utility, and function should have an associated manual page | included in the same package. It is suggested that all configuration files | also have a manual page included as well. Manual pages for protocols and other | auxiliary things are optional. +== This suggests that it should have a manpage. But, it's a *should*. On the other hand, I know that many "entities" which are not in $PATH have their own manpage -- see for example Perl modules. How should I behave here? Kindly, David [0] http://bugs.debian.org/john [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=132223 -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Manpages for binaries not in $PATH
Twas brillig at 19:18:39 10.05.2008 UTC+02 when David Paleino did gyre and gimble: DP> How should I behave here? I'd treat john-any and john-mmx as parts of program - merely implementation details. -- pgpuSWy7MBu2Y.pgp Description: PGP signature
Re: Manpages for binaries not in $PATH
On Sun, 11 May 2008 00:36:00 +0700, Mikhail Gusarov wrote: > Twas brillig at 19:18:39 10.05.2008 UTC+02 when David Paleino did gyre and > gimble: > > DP> How should I behave here? > > I'd treat john-any and john-mmx as parts of program - merely > implementation details. That's what I thought. Thus, john.8 should suffice for both. I'll wait for any other response before acting on the bug. Thanks, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Manpages for binaries not in $PATH
On Sat, May 10, 2008 at 07:18:39PM +0200, David Paleino wrote: This suggests that it should have a manpage. But, it's a *should*. On the other hand, I know that many "entities" which are not in $PATH have their own manpage -- see for example Perl modules. How should I behave here? I think the obvious answer makes your question moot: combine the two into one binary and benchmark to decide what to do, as suggested in 251259. If you're not willing to do that, then the prudent decision is to decide whether the user ever needs to run the program manually. In the case of cpp-4.3, you never need to run cc1 (since it is an implementation detail), so it does not require a manpage. It seems that in the case of john, the main executable cannot figure out which implementation is better, so the user may need to run the program manually. Thus it needs a manpage. IANADD. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Manpages for binaries not in $PATH
On Sat, 10 May 2008 17:52:43 +, brian m. carlson wrote: > On Sat, May 10, 2008 at 07:18:39PM +0200, David Paleino wrote: > >This suggests that it should have a manpage. But, it's a *should*. On the > >other hand, I know that many "entities" which are not in $PATH have their > >own manpage -- see for example Perl modules. > > > >How should I behave here? > > I think the obvious answer makes your question moot: combine the two > into one binary and benchmark to decide what to do, as suggested in > 251259. Uhm, yes. That's what I should've done before, sorry for not noticing. I'll work on that ASAP. > It seems that in the case of john, the main executable cannot figure out > which implementation is better, so the user may need to run the program > manually. Thus it needs a manpage. Also john-any and john-mmx might be seen as "implementation details". Thus I'm now thinking at a single manpage, with symlinks for john-mmx and john-any. However, before doing this, I should decide whether to keep this separation or not. > IANADD. Me neither, but I don't believe one needs to be a DD to read the Policy and think ;) Thanks, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Mail headers for automated package maintenance emails
On Sat, 10 May 2008, Lionel Elie Mamane wrote: > >The X-Debian-Package: header can be omitted if it is not possible to > >name a specific source package for a mail, like when the mail is > >about multiple packages. > > One could consider several X-Debian-Package headers when it is about > multiple packages, or a list of packages in a single header. comma-and-blanks-separated list, please. But should the package information be unavailable or should it not make sense to relate the email to a package or group of packages, then the header should be ommited. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will nvidia-graphics-drivers ever transition to testing?
On Sat May 10 2008 12:14:22 Julien Cristau wrote: > On Sat, May 10, 2008 at 12:09:52 -0700, Mike Bird wrote: > > On Sat May 10 2008 11:03:40 Julien Cristau wrote: > > > On Sat, May 10, 2008 at 10:59:44 -0700, Mike Bird wrote: > > > > How should a package depend on a package built by module-assistant? > > > > > > It shouldn't. > > > > Are you saying the dependent package should install successfully > > and then fail at runtime? If not, what are you saying? > > I'm saying that, and I'm also saying that this is utterly off-topic on > this list. [Moved from debian-release to debian-devel] WHY ON EARTH should we intentionally require that packages install successfully with known unmet dependencies which will cause failure at runtime? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will nvidia-graphics-drivers ever transition to testing?
On Sat, May 10, 2008 at 12:38:29PM -0700, Mike Bird wrote: > [Moved from debian-release to debian-devel] > > WHY ON EARTH should we intentionally require that packages install > successfully with known unmet dependencies which will cause failure > at runtime? Well nvidia-kernel should soon be built from linux-modules-nonfree-2.6, so perhaps that will ensure that a complete set of modules are in unstable so that everything can move to testing together. That should solve any dependancy issue preventing things moving to testing at least. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mail headers for automated package maintenance emails
Raphael Hertzog wrote: > > The PTS now provides those headers as well. > > X-Debian: PTS > X-Debian-Package: Also for messages coming from other sources, i.e. dehs? Just want to know if I have to make dehs add those headers. > > Cheers, Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mail headers for automated package maintenance emails
On Sat, 10 May 2008, Joerg Jaspert wrote: > b. Every tool sending automated mail to Debian Developers should add >headers of the form > > X-Debian: $TOOL > X-Debian-Package: $PACKAGE The BTS already does the latter using X-Debian-PR-Package: $PACKAGE, with mails regarding multiple packages separated by commas (possibly followed by spaces) to the extent that it is possible to identify a package associated with a bug report or actions taken on bug reports. I will eventually be duplicating this information in an X-Debian-Package: header as well, and adding an X-Debian: bugs.debian.org header as well for convenience, but will be keeping the existing PR headers intact for the forseeable future. Don Armstrong -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: xinha -- powerful WYSIWYG HTML editor
Hi, On Tue, May 06, 2008 at 12:48:44PM +0200, Mathieu PARENT wrote: > > OK. So, I wanted to package xinha, see below. Which team can host this > WYSIWYG HTML editor ? Perhaps in Debian Webapps Team. There is already tinymce package which is also a WYSIWYG HTML editor: http://qa.debian.org/[EMAIL PROTECTED] Regards, -- Gregory Colpart <[EMAIL PROTECTED]> GnuPG:1024D/C1027A0E Evolix - Informatique et Logiciels Libres http://www.evolix.fr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Uniform field for automated package maintenance email messages (was: Bug#479953: uniform header for automated package maintenance emails)
Processing commands for [EMAIL PROTECTED]: > retitle 479953 uniform field for automated package maintenance email messages Bug#479953: uniform control field for automated package maintenance emails Changed Bug title to `uniform field for automated package maintenance email messages' from `uniform control field for automated package maintenance emails'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Will nvidia-graphics-drivers ever transition to testing?
On Sat May 10 2008 12:14:22 Julien Cristau wrote: > On Sat, May 10, 2008 at 12:09:52 -0700, Mike Bird wrote: > > On Sat May 10 2008 11:03:40 Julien Cristau wrote: > > > On Sat, May 10, 2008 at 10:59:44 -0700, Mike Bird wrote: > > > > How should a package depend on a package built by module-assistant? > > > > > > It shouldn't. > > > > Are you saying the dependent package should install successfully > > and then fail at runtime? If not, what are you saying? > > I'm saying that, and I'm also saying that this is utterly off-topic on > this list. [Moved from debian-release to debian-devel] WHY ON EARTH should we intentionally require that packages install successfully with known unmet dependencies which will cause failure at runtime? --Mike Bird We shouldn't. I'm sorry if your question was specifically for Julien, that wasn't clear. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Will nvidia-graphics-drivers ever transition to testing?
On Sat, May 10, 2008 at 12:38:29PM -0700, Mike Bird wrote: > [Moved from debian-release to debian-devel] > > WHY ON EARTH should we intentionally require that packages install > successfully with known unmet dependencies which will cause failure > at runtime? Well nvidia-kernel should soon be built from linux-modules-nonfree-2.6, so perhaps that will ensure that a complete set of modules are in unstable so that everything can move to testing together. The set of modules can already be updated if someone has the time and experience needed to update nvidia-graphics-modules-i386 and company. Merging nvidia-graphics-modules-i386 with linux-modules-nonfree-2.6 would only complicate or delay more testing transition of nvidia LKM packages, like for any LKM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480584: ITP: libdifflcs-ruby -- A port of Algorithm::Diff that uses the McIlroy-Hunt longest common subsequence (LCS)
Package: wnpp Severity: wishlist Owner: Sebastien Delafond <[EMAIL PROTECTED]> * Package name: libdifflcs-ruby Version : 1.1.2 Upstream Author : Austin Ziegler (Copyright 2004 Austin Ziegler <[EMAIL PROTECTED]>) * URL : * License : Ruby Programming Lang: Ruby Description : A port of Algorithm::Diff that uses the McIlroy-Hunt longest common subsequence (LCS) Diff::LCS is a port of Algorithm::Diff that uses the McIlroy-Hunt longest common subsequence (LCS) algorithm to compute intelligent differences between two sequenced enumerable containers. The implementation is based on Mario I. Wolczko's Smalltalk version -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480583: ITP: libheckle-ruby -- Heckle is a mutation tester.
Package: wnpp Severity: wishlist Owner: Sebastien Delafond <[EMAIL PROTECTED]> * Package name: libheckle-ruby Version : 1.4.1 Upstream Author : Ryan Davis and Kevin Clark (Copyright (c) 2006 Ryan Davis and Kevin Clark) * URL : http://rubyforge.org/projects/seattlerb * License : MIT Programming Lang: Ruby Description : Heckle is a mutation tester. Heckle is a mutation tester. It modifies your code and runs your tests to make sure they fail. The idea is that if code can be changed and your tests don't notice, either that code isn't being covered or it doesn't do anything. Think about it as pen-testing. It's like hiring a white-hat hacker to try to break into your server and making sure you detect it. You learn the most by trying to break things and watching the outcome. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.iso88591, LC_CTYPE=en_US.iso88591 (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US.iso88591) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
