On Wed, 08 Feb 2012 11:56:06 -0800
Russ Allbery wrote:
> There are two main cases for libfoo-dev that I think cover most such
> packages:
>
> 1. The header files are architecture-dependent (definitions of data member
>sizes, for example), in which case they need to be arch-qualified
>any
Roger Leigh writes:
> On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
>> Also true. In fact, it's something that's been bothering me for a long
>> time with linked doc directories. I'd like to prohibit them in more
>> cases so that we get the binNMU changelogs on disk.
> Relating
Guillem Jover writes:
> Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
> sid generating a reproducible output across all current architectures.
> Time passes, compressor version N (and even O and P and Q etc) gets
> uploaded, which starts producing new ouput (on each of th
new version available. Now, if there is a
> > binNMU after a new version of gzip is uploaded, yes it is probably
> > wise to rebuild all architectures if the package includes a
> > Multi-Arch: same library. How often does that happen?
>
> Isn't this something that we
Riku Voipio writes:
> On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
>> The same principle that applies to all dpkg output to avoid ambiguity
>> would apply everywhere, whenever there's a “Multi-Arch: same” package
>> name that needs to be unambiguous, it just always gets arch-qua
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
> Guillem Jover writes:
> > On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > And while the binNMU changelog issues might seem like a corner case,
> > it's just a symptom of something that's not quite right.
>
> Also true.
Guillem Jover writes:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
>> Well, it does mean that you might be lacking important information
>> because the other changelog wouldn't be present on the system.
> While the implicit Replaces seems the easy way out, it just seems even
> more
is uploaded, yes it is probably
> wise to rebuild all architectures if the package includes a
> Multi-Arch: same library. How often does that happen?
Isn't this something that we can test for in the archive, and require
rebuilds for all affected packages before entering testing?
[Multi-A
On Wed, 8 Feb 2012 17:13:20 +0100
Guillem Jover wrote:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > Well, it does mean that you might be lacking important information
> > because the other changelog wouldn't be present on the system.
> Instead of this, I'd rather see the shared
On Thu, Feb 9, 2012 at 01:35, Simon McVittie wrote:
> On 08/02/12 17:22, Aron Xu wrote:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. AFAIK some mainta
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
> On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
> > If you remove the shared files approach, how do you handle files like
> > lintian overrides, reportbug presubj and scripts, etc. ?
>
> The same principle that applies to al
On 08/02/12 17:22, Aron Xu wrote:
> Some packages come with data files that endianness matters, and many
> of them are large enough to split into a separate arch:all package if
> endianness were not something to care about. AFAIK some maintainers
> are not aware of endianness issues in their packag
Ian Jackson wrote:
> Another relevant question is whether there are other files that are
> shared, and which don't want to move, besides ones in /usr/share/doc.
One example is header files in /usr/include, from -dev packages. In
the simple examples I've seen, putting them in /usr/include/,
works
I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.
Some packages come with data files that endianness matters, and many
of them are
Guillem Jover writes ("Re: Please test gzip -9n - related to dpkg with
multiarch support"):
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > One thing which no-one yet seems to have suggested is to have
> > multiarch:same packages put the changel
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
> If you remove the shared files approach, how do you handle files like
> lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's
On Wed, Feb 08, 2012 at 05:13:20PM +0100, Guillem Jover wrote:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > Well, it does mean that you might be lacking important information
> > because the other changelog wouldn't be present on the system.
>
> While the implicit Replaces seems
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> Well, it does mean that you might be lacking important information
> because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just seems even
more fragile than the shared files a
On Wed, 8 Feb 2012 15:06:46 +0100
Adam Borowski wrote:
> On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
> > For those not subscribed to that bug, how to reproduce[1] and possible
> > fix[2] are available now. There might be other places where buffers are
> > reused, I only spent
On Wed, Feb 08, 2012 at 11:33:37AM +0100, Bernhard R. Link wrote:
> On the other hand most uncompressors silently ignore unexpected
> data after end of file markers. So the compressed file is even more
> easily tempered with (especially as debsums only stores md5 without
> size and md5 does not inc
On Wed, 8 Feb 2012 14:14:22 +0100
Cyril Brulebois wrote:
> Neil Williams (07/02/2012):
> > I'd like to ask for some help with a bug which is tripping up my tests
> > with the multiarch-aware dpkg from experimental - #647522 -
> > non-deterministic behaviour of gzip -9n.
>
> For those not subscr
Wouter Verhelst wrote:
> On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> > Maybe the way to solve this properly is to remove compression from the
> > uniqueness check - compare the contents of the file in memory after
> > decompression. Yes, it will take longer but it is only neede
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
> For those not subscribed to that bug, how to reproduce[1] and possible
> fix[2] are available now. There might be other places where buffers are
> reused, I only spent a few minutes on this during my lunch break.
>
> 2. http://bug
Russ Allbery writes ("Re: Please test gzip -9n - related to dpkg with multiarch
support"):
> Another possible solution is to just give any package an implicit Replaces
> (possibly constrained to /usr/share/doc) on any other package with the
> same name and version and a dif
(Dropping everyone but dd@.)
Wouter Verhelst (08/02/2012):
> As an additional benefit, this will also allow those among us (like me)
> who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz >
> /tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some
> documentation, to just req
Neil Williams (07/02/2012):
> I'd like to ask for some help with a bug which is tripping up my tests
> with the multiarch-aware dpkg from experimental - #647522 -
> non-deterministic behaviour of gzip -9n.
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> Maybe the way to solve this properly is to remove compression from the
> uniqueness check - compare the contents of the file in memory after
> decompression. Yes, it will take longer but it is only needed when the
> md5sum (which alre
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote:
> On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
> > But it's worse than this: even if dpkg decompresses before comparing,
> > debsums won't (and mustn't, for backward compatibility). So it's
> > potentially necessary to fix
On 08/02/12 10:22, Neil Williams wrote:
> Nothing in /usr/share/ matters for a cross package created by
> dpkg-cross (with the possible exception of /usr/share/pkg-config
> which was always anachronistic).
I'd understood that /usr/share/pkgconfig should be used for the
sort of packages that would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/2012 11:04 PM, Neil Williams wrote:
> I'm not convinced that this is fixable at the gzip level, nor is it
> likely to be fixable by the trauma of changing from gzip to
> something else.
while the original point of not considering compressors
On Wed, 8 Feb 2012 21:54:30 +1100
Russell Coker wrote:
> On Wed, 8 Feb 2012, Neil Williams wrote:
> > > Expecting that the compression gives the smallest file every time is
> > > reasonable.
> >
> > By a single byte - I've not seen file size changes beyond that range.
>
> It's a matter of pri
On Wed, 8 Feb 2012, Neil Williams wrote:
> > Expecting that the compression gives the smallest file every time is
> > reasonable.
>
> By a single byte - I've not seen file size changes beyond that range.
It's a matter of principle. A compression program is supposed to reliably
compress data.
* Lars Wirzenius [120208 08:58]:
> On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
> > But it's worse than this: even if dpkg decompresses before comparing,
> > debsums won't (and mustn't, for backward compatibility). So it's
> > potentially necessary to fix up the md5sums file for
On Wed, 8 Feb 2012 02:52:52 +0200
Riku Voipio wrote:
> If it turns out not reasonable to expect the compression results to be
> identical, we should probably look into using dpkg --path-exclude= with
> /usr/share/{doc,man,info}/* when installing foreign-architecture packages.
That would be a sui
On Wed, 8 Feb 2012 12:05:44 +1100
Russell Coker wrote:
> On Wed, 8 Feb 2012, Riku Voipio wrote:
> > If it turns out not reasonable to expect the compression results to be
> > identical
>
> It was reported that sometimes the size differs. Surely if nothing else
> having gzip sometimes produce a
On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
> But it's worse than this: even if dpkg decompresses before comparing,
> debsums won't (and mustn't, for backward compatibility). So it's
> potentially necessary to fix up the md5sums file for a package
> installed for multiple archit
Riku Voipio writes:
> If it turns out not reasonable to expect the compression results to be
> identical, we should probably look into using dpkg --path-exclude= with
> /usr/share/{doc,man,info}/* when installing foreign-architecture packages.
I believe the only packages that pose a problem are
On Wed, 8 Feb 2012, Riku Voipio wrote:
> If it turns out not reasonable to expect the compression results to be
> identical
It was reported that sometimes the size differs. Surely if nothing else
having gzip sometimes produce an unnecessarily large file is a bug!
Expecting that the compression
On Tue, Feb 07, 2012 at 10:13:01PM +, Neil Williams wrote:
> On Tue, 7 Feb 2012 14:01:57 -0800
> Steve Langasek wrote:
> > At this stage, I have no reason to think that's not achievable, though no
> > one seems to have dived very deep into the bug yet. And whether gzip
> > upstream agrees thi
On Tue, 07 Feb 2012, Jonathan Nieder wrote:
> Henrique de Moraes Holschuh wrote:
> > Maybe you can switch to sha256 and add the new functionality while at
> > it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
> > the hash. Old debsums won't work with the new files, but is that
Henrique de Moraes Holschuh wrote:
> Maybe you can switch to sha256 and add the new functionality while at
> it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
> the hash. Old debsums won't work with the new files, but is that really
> a problem? That's what stable updates and
On Tue, 07 Feb 2012, Ben Hutchings wrote:
> But it's worse than this: even if dpkg decompresses before comparing,
> debsums won't (and mustn't, for backward compatibility). So it's
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256 unc
Neil Williams writes:
> Maybe the way to solve this properly is to remove compression from the
> uniqueness check - compare the contents of the file in memory after
> decompression. Yes, it will take longer but it is only needed when the
> md5sum (which already exists) doesn't match.
Another pos
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> On Tue, 07 Feb 2012 19:11:16 +0100
> Michael Biebl wrote:
>
> > On 07.02.2012 18:07, Joey Hess wrote:
> > > Neil Williams wrote:
> > >> I'd like to ask for some help with a bug which is tripping up my tests
> > >> with the multiarch
On Tue, 7 Feb 2012 14:01:57 -0800
Steve Langasek wrote:
> There are various ways to meet both the multiarch constraints and the policy
> requirements, including shipping an arch:all common package that will
> contain the changelog for each multiarch library, which then ships just a
> symlink. Bu
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl wrote:
> On 07.02.2012 18:07, Joey Hess wrote:
> > Neil Williams wrote:
> >> I'd like to ask for some help with a bug which is tripping up my tests
> >> with the multiarch-aware dpkg from experimental - #647522 -
> >> non-deterministic behaviour of
Hi Joey,
On Tue, Feb 07, 2012 at 01:07:11PM -0400, Joey Hess wrote:
> Neil Williams wrote:
> > I'd like to ask for some help with a bug which is tripping up my tests
> > with the multiarch-aware dpkg from experimental - #647522 -
> > non-deterministic behaviour of gzip -9n.
> pristine-tar hat tri
On 07.02.2012 18:07, Joey Hess wrote:
> Neil Williams wrote:
>> I'd like to ask for some help with a bug which is tripping up my tests
>> with the multiarch-aware dpkg from experimental - #647522 -
>> non-deterministic behaviour of gzip -9n.
>
> pristine-tar hat tricks[1] aside, none of gzip, bzip
Neil Williams wrote:
> I'd like to ask for some help with a bug which is tripping up my tests
> with the multiarch-aware dpkg from experimental - #647522 -
> non-deterministic behaviour of gzip -9n.
pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
to always produce the same c
On 07.02.2012 10:59, Neil Williams wrote:
>
> It would be a very laborious task to check the md5sums of every .gz file
> in /usr/share/doc in every MultiArch: same package across all
> architectures and the Contents-* files on the mirrors don't contain the
> filesize of the listed files. Does anyo
kfreebsd-amd64:
6344 2011-02-27 09:07 ./usr/share/doc/libppl9/CREDITS.gz
armhf, i386, amd64:
6343 2011-02-27 09:07 ./usr/share/doc/libppl9/CREDITS.gz
(Jakub Wilk originally spotted a checksum change without a filesize
change, so filesize is not the best indicator, hence the checksum test.)
Deco
Hello,
Guillem just released a "work-in-progress" version of dpkg that supports
multiarch to experimental (dpkg 1.16.2~wipmultiarch). Beware: There will
likely be some small "interface" changes between this version and the
version that will be released later in unstable (possibly in the output of
Package: wnpp
Severity: wishlist
Owner: Philipp Hagemeister
* Package name: mocksmtp
Version : 1.0
Upstream Author : Philipp Hagemeister
* URL : https://github.com/phihag/mocksmtp
* License : GPL
Programming Lang: Python
Description : email test
Hi,
I am happy to finally announce "Debian Edu Squeeze 6.0.3 beta1"!
Complete download and installation instructions are available at
http://wiki.debian.org/DebianEdu/Documentation/Squeeze/Installation
Read the "Getting Started" chapter of the manual to learn how to login for the
first time:
Package: wnpp
Severity: wishlist
Owner: Thomas Koch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: libtest-interface-java
Version : 0.5
Upstream Author : Josh Cough, Mark Harrah
* URL : https://github.com/harrah/test-interface
* License : BSD
: Scala
Description : Scala unit test framework inspired by Haskel's Quickcheck
ScalaCheck is a powerful tool for automatic unit testing of Scala and Java
programs. It features automatic test case generation and minimization of failing
test cases. ScalaCheck started out as a Scala port o
* License : Apache 2.0
Programming Lang: Python
Description : test coverage reporting tool for Django
A test coverage reporting tool for Django that utilizes python-coverage
show how much of your code is exercised with your tests.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10
-Formatter-HTML/
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : TAP Test Harness output delegate for html output
TAP::Formatter::HTML provides HTML output formatting for TAP::Harness (a
replacement for Test::Harness. It is largely based on ideas from
TAP::Test
Package: wnpp
Owner: tak...@debian.org
Severity: wishlist
* Package name: ruby-rr
Version :
Upstream Author :
* URL or Web page :
* License :
Description : Ruby test double framework
RR (Double Ruby) is a test double framework that features a rich
selection of
Package: wnpp
Severity: wishlist
Owner: John Feuerstein
* Package name: speedpad
Version : 1.0
Upstream Author : John Feuerstein
* URL : http://feurix.org/projects/speedpad/
* License : GPLv3
Programming Lang: Python
Description : ncurses tool to test
Package: wnpp
Severity: wishlist
Owner: Kiwamu Okabe
* Package name: haskell-test-framework
Version : 0.4.1.1
Upstream Author : Max Bolingbroke
* URL : http://batterseapower.github.com/test-framework/
Vcs-Browser :
http://anonscm.debian.org/gitweb/?p=collab
Package: wnpp
Severity: wishlist
Owner: Kiwamu Okabe
* Package name: haskell-test-framework-th
Version : 0.2.2
Upstream Author : Oscar Finnsson & Emil Nordling
* URL : http://github.com/finnsson/test-generator
Vcs-Browser :
http://anonscm.debian.org/gitwe
Package: wnpp
Severity: wishlist
Owner: Kiwamu Okabe
* Package name: haskell-test-framework-quickcheck2
Version : 0.2.10
Upstream Author : Max Bolingbroke
* URL : http://batterseapower.github.com/test-framework/
Vcs-Browser :
http://anonscm.debian.org/gitweb/?p
Package: wnpp
Severity: wishlist
Owner: Kiwamu Okabe
* Package name: haskell-test-framework-hunit
Version : 0.2.6
Upstream Author : Max Bolingbroke
* URL : http://batterseapower.github.com/test-framework/
Vcs-Browser :
http://anonscm.debian.org/gitweb/?p=collab
ithub.com/brentp/fishers_exact_test>
* License : BSD
Description : simple and fast implementation of Fisher's exact test
Fisher's exact test is a statistical significance test used in the
analysis of contingency tables where sample sizes are small.
.
This package i
: a python module for using fake objects to test real ones.
.
In readable Python code, you declare what methods are available on
your fake and how they should be called. Then you inject that into
your application and start testing.
.
This declarative approach means you don’t have to record and
for building test expressions (python
version)
--
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/20110925225930.25756.27461.reportbug@amy
Package: wnpp
Owner: Fabrizio Regalli
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtest-indistdir-perl
Version : 1.112071
Upstream Author : Christian Walde
* URL : http://search.cpan.org/dist/Test
, Python
Description : Python framework to ease development of test suites
GNATPython is a python framework to ease development of test suites
and build scripts in a portable way.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe"
Package: wnpp
Severity: wishlist
* Package name: libtest-harness-archive-perl
Version : 0.14
Upstream Author : Michael Peters
* URL or Web page : http://search.cpan.org/dist/TAP-Harness-Archive/
* License : Artistic
Description : Create an archive of TAP test
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libplack-test-externalserver-perl
Version : 0.01
Upstream Author : Florian Ragwitz
* URL : http://search.cpan.org/dist
no detail except log failure count (and which test).
Should I create a new package version (upstreamversion-X) and upload it to
sid then wait for the build of each arch to check if my patch work ? and
create new version again if patch is not the expected one ?
This could lead to many patched
Package: wnpp
Severity: wishlist
Owner: Florian Schlichting
* Package name: libtest-carp-perl
Version : 0.2
Upstream Author : Daniel Muey
* URL : http://search.cpan.org/~dmuey/Test-Carp-0.2/
* License : GPL-1+ / Artistic
Programming Lang: Perl
Description
Package: wnpp
Owner: Maximilian Gass
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtest-mock-redis-perl
Version : 0.05
Upstream Author : Jeff Lavallee
* URL : http://search.cpan.org/dist/Test-Mock-Redis
Package: wnpp
Severity: wishlist
Owner: Misha Strong
* Package name: test456
Version : sx.y.zasdasdasd
Upstream Author : Name
* URL : http://wasdasdasdww.example.org/
* License : asdasdadasdasdsadasSD, MIT/X, etc.)
Programming Lang: C
Description
Package: wnpp
Owner: Maximilian Gass
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtest-routine-perl
Version : 0.012
Upstream Author : Ricardo Signes
* URL : http://search.cpan.org/dist/Test-Routine
Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius
* Package name: genbackupdata
Version : 1.5
Upstream Author : Lars Wirzenius
* URL : http://braawi.org/genbackupdata/
* License : GPL
Programming Lang: Python
Description : generate test data sets
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
I wrote:
> Anyway, can you please post the incompatibility list here, if it's not
> too long ?
Never mind, fetched it myself.
Ian.
make-dfsg (3.82-1) experimental; urgency=low
* New upstream release. A complete list of bugs fixed in this version is
available here:
http://sv.gnu.org/bugs
Manoj Srivastava writes ("A new version of make-dfsg has been uploaded to
experimental, please test"):
> make 3.82 will require some transitions due to backward
> incompatibility on GNU-make-specific features. Some bug reports have
> already occurred for build is
Hi,
make 3.82 will require some transitions due to backward
incompatibility on GNU-make-specific features. Some bug reports have
already occurred for build issues with make 3.82, such as
http://bugs.debian.org/603759 . Since there are known backward
incompatibilities, make has been up
Package: wnpp
Severity: wishlist
Owner: James Page
* Package name: jenkins-test-annotations
Version : 1.0
* URL : http://github.com/jenkinsci/lib-test-annotations
* License : MIT
Programming Lang: Java
Description : Annotation library for tracking
Programming Lang: Java
Description : Regression Test Harness for the OpenJDK platform
jtreg is the test harness used by the OpenJDK test framework.
This framework is intended primarily for regression tests.
It can also be used for unit tests, functional tests, and even simple product
tests
Programming Lang: Java
Description : General purpose, fully-featured, flexible, and configurable
test harness.
The JT harness is a general purpose, fully-featured, flexible, and configurable
test harness very well suited for most types of unit testing. Originally
developed as a test
, so I need to re-introduce
the package into Debian.
* Package name: python-coverage-test-runner
Version : 1.5
Upstream Author : Lars Wirzenius
* URL : http://liw.fi/coverage-test-runner/
* License : GPL3+
Programming Lang: Python
Description : fail
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: libtest-www-mechanize-psgi-perl
Version : 0.35
Upstream Author : Leon Brocard
* URL : http://search.cpan.org/dist/Test-WWW-Mechanize-PSGI/
* License : Artistic or GPL-1+
Programming
: context framework for Test::Unit
From upstream README:
Shoulda’s contexts make it easy to write understandable and maintainable
tests for Test::Unit. It’s fully compatible with your existing tests in
Test::Unit, and requires no retooling to use.
--
Antonio Terceiro
http://softwarelivre.org
: Test helpers for Rails applications, compatible with
Test::Unit and RSpec
From upstream README:
Test::Unit- and RSpec-compatible one-liners that test common Rails
functionality. These tests would otherwise be much longer, more complex,
and error-prone.
--
Antonio Terceiro
http
On ti, 2011-03-08 at 09:39 +, Jonathan Wiltshire wrote:
> I fixed the bug title.
>
> On Tue, Mar 08, 2011 at 09:57:40AM +0100, Bastien ROUCARIES wrote:
> > Description: xfstests is a torture test suite for filesystem bugs. It is
> > useful in order to debug problem on
I fixed the bug title.
On Tue, Mar 08, 2011 at 09:57:40AM +0100, Bastien ROUCARIES wrote:
> Description: xfstests is a torture test suite for filesystem bugs. It is
> useful in order to debug problem on linux filesystem. It
> could be run on xfs, udf, nfs, ext2, ext3, ext4, reiserfs,
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: xfstests
Version: git20110223
Upstream Author: Alex Elder x...@oss.sgi.com
URL: GPL
Description: xfstests is a torture test suite for filesystem bugs. It is useful
in order to debug problem on linux
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: libtest-rdf-perl
Version : 0.20
Upstream Author : Kjetil Kjernsmo
* URL : http://search.cpan.org/dist/Test-RDF/
* License : Artistic or GPL-1+
Programming Lang: Perl
Description
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber
* Package name: libtest-pod-no404s-perl
Version : 0.01
Upstream Author : Apocalypse
* URL : http://search.cpan.org/dist/Test-Pod-No404s/
* License : Perl
Programming Lang: Perl
Description : Test
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber
* Package name: libtest-autoloader-perl
Version : 0.03
Upstream Author : Benjamin Warfield
* URL : http://search.cpan.org/dist/Test-AutoLoader/
* License : GPL
Programming Lang: Perl
Description
power‐
ful.
Is it safe to switch to apt or aptitude as the default
resolver?Almost certainly.This exhaustive test
demonstrates that 99.34–99.35% of the existing archive
builds entirely unchanged. Of the 0.65–0.66% which built
with an altered installed package set,
On 15/02/11 at 11:35 +0100, Marco d'Itri wrote:
> On Feb 15, Roger Leigh wrote:
>
> > - with a lot of disc space
> How many TB?
>
> > - and a lot of spare CPU cycles
> Is sbuild able to scale linearly to 16-32 CPUs in a single VM or does it
> need many smaller servers?
> And how long would this
On Feb 15, Roger Leigh wrote:
> - with a lot of disc space
How many TB?
> - and a lot of spare CPU cycles
Is sbuild able to scale linearly to 16-32 CPUs in a single VM or does it
need many smaller servers?
And how long would this take with e.g. 96 2.1 GHz Opteron CPU cores?
Depending on the har
]] Roger Leigh
| If there are any project machines available that could do this, that
| would be great!
I have a couple of machines that I'd like to get burned in properly.
They're not .d.o machines (they're freedesktop.org), but I'll happily
give you access to play around. Please grab me on IR
gt; ?
> All you seem to want is the resolver's results, nothing else.
> In fact, a simple, clean, chroot running apt-get --dry-run build-dep, and
> aptitude --simulate build-dep should do it.
I don't just want to test the resolver, which I agree wouldn't need
this. I also want
Roger Leigh wrote:
> However, in order to understand the implications, we need concrete
> data about exactly how they differ, and under what situations. What
> I would like to do is a rebuild of the squeeze archive (since it
> won't change between builds) using each of the "internal", "apt" and
>
501 - 600 of 1469 matches
Mail list logo
