Re: Any Debian Developers traveling to Almaty? (GPG key sign needed)
Timur Birsh wrote: > Are there any Debian Developers traveling to Almaty for the Asian Winter > Games? I need a GPG key sign. Got one signature on my RSA key. But more signatures are pretty welcome. -- Timur -- 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/iib4ke$hm0$1...@dough.gmane.org
Bug#611789: ITP: mummy -- command line executable that generates C# wrappers from gccxml output
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: mummy Version : 1.0.2 Upstream Author : kitware * URL : http://www.kitware.com/products/avdownload.php * License : BSD Programming Lang: C++ Description : command line executable that generates C# wrappers from gccxml output mummy is a command line executable that generates C# wrappers from gccxml output. A C# class is generated to wrap the wrappable class named in the gccxml output. Settings to control the wrapping are given inline directly in the class header file or in the MummySettings.xml input 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/20110202085929.24317.30024.report...@hpdesk.malat.net
Bug#611793: ITP: sleepisdeath -- a storytelling game for two players
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-CC: debian-devel-ga...@lists.debian.org, debian-devel@lists.debian.org * Package name: sleepisdeath Version : 16 Upstream Author : Jason Rohrer * URL : http://sleepisdeath.net/ * License : None (Public Domain) Programming Lang: C++ Description : a storytelling game for two players -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 08:55:07AM +0100, Stefano Zacchiroli wrote: > > So, where do we start/continue sharing the thoughts on a tentative > > DEP? ;) > > Let's see first if we have all the arguments on the table already, > thanks to this thread. I'm willing to co-drive a DEP to finalize the > spec, although I definitely need helping hands (hint, hint!). I'm very interested in this and willing to help pushing it forward. I sense a similar interest for Yarik. Michael -- Michael Hanke http://mih.voxindeserto.de -- 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/20110202130656.GB30281@meiner
Bug#611809: ITP: kombu -- AMQP Messaging Framework for Python
Package: wnpp Severity: wishlist Owner: Fladischer Michael -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: kombu Version : 1.0.2 Upstream Author : Ask Solem * URL : https://github.com/ask/kombu/ * License : BSD Programming Lang: Python Description : AMQP Messaging Framework for Python The aim of Kombu is to make messaging in Python as easy as possible by providing an idiomatic high-level interface for the AMQP protocol. It is meant to replace the carrot library by providing a compatibility layer. .. Features: * Allows application authors to support several message server solutions by using pluggable transports. * Supports automatic encoding, serialization and compression of message payloads. * The ability to ensure that an operation is performed by gracefully handling connection and channel errors. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1JXsAACgkQeJ3z1zFMUGaHBwCgkJsE4hBXUvhVqVr1lvxUtyiV TXgAnjtRx7ccUnYF1ERTcdmPwQDqkGQs =SDIE -END PGP SIGNATURE- -- 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/20110202134016.5263.16474.report...@ossus.home.fladi.at
Re: package testing, autopkgtest, and all that
Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"):
> First a brief question:
> > The source package provides a test metadata file
> > debian/tests/control. This is a file containing zero or more
> > RFC822-style stanzas, along these lines:
>
> Do you still have somewhere that awk package demo package which had
> debian/tests/ ? Currently our archive does not carry any package having
> debian/tests/ (unfortunately).
Probably. I'll see if I can dig it out.
> All of the above approaches seems to separate testing "materials"
> from the actual packages. Both mago and checkbox come with user
> interfaces, thus enabling users to test/validate their own systems
> without requiring setting up any virtual environment. And they ship
> their tests along (there seems to be some discovery mechanisms but I
> haven't checked in detail yet).
These tools are mostly orthogonal to and even complementary to
autopkgtest. There are a whole bunch of other automatic testing
utilities like xnee, etc., which solve other parts of the automatic
testing problem and can be usefully combined with autopkgtest.
I wasn't aware of "qa-regression-testing":
> - qa-regression-testing: collection of unit and regression tests for
> various components (from kernel to xine and apache) of the
> systems. Is not designed for distribution to the users (yet?)
That seems to want to collect the tests in one central place. Debian
(and to an extent our derivatives) have some difficulty with
centralised collections of information about multiple different pieces
of software. Our social and technical structures are based around
more-or-less freestanding packages.
So it makes more sense in our context to locate tests with the
package.
> On the other hand, Ian's autopkgtest aims to provide a unified testing
> framework built around packages, so that it becomes possible for us,
> maintainers, to equip packages with necessary tests batteries; which could be
> reused by others (e.g. QA teams).
Yes.
> Unfortunately the core aspect of the current autopkgtest - relying
> on tests in source packages -- imho to be not the ideal solution to
> target both sides of the userbase (i.e. maintainers/QA vs mortals).
I'm not sure I know what you mean.
> ,---
> | Q. Why put the tests in the source package ?
> |
> | A. Other possibilities include a special .deb generated by the
> | source (which is a bit strange and what happens to this .deb and
> | will make it even harder to reuse upstream test suites), or
> | putting them in the .deb to be tested (definitely wrong - most
> | people won't want the tests and they might be very large) or
> | having them floating about separately somewhere (which prevents us
> | from sharing and exchanging tests with other parts of the Free
> | Software community). The source package is always available when
> | development is taking place.
> `---
>
> Ian -- could you please unroll your arguments a bit? I still do not
> see why source packages are beneficial besides build-time testing
> (which we often do already without any additional framework)
You're asking why the tests should be in source packages rather than
binary packages.
The underlying point you seem to be missing is that a major aim of
autopkgtest is that it should be straightforward to provide
autopkgtest bindings for existing upstream test suites.
So, firstly, binary packages have a much bigger overhead, and more
complicated restrictions, compared to adding new material to source
packages:
- Binary packages get entries in a large number of databases both
in our central infrastructure and on users' systems
- Binary packages are highly visible in ways that test infrastructure
doesn't need to be
- They are relatively complicated to produce
- They can only be installed in particular locations
- Only one version can be present on a system at once (unless even
more complicated things are done)
The additional complexity and effort doesn't buy us anything, and the
restrictions are pointless.
Secondly: very often the tests will want to use other material from
the source package. Upstream packages often come with tests, or
strange example programs, or other material, which is useful for
testing but not useful for users, and which the upstream package does
not install.
So if the tests were in binary packages, often we'd have to construct
a weird binary package which contained all or part of the built source
tree. This would be very ugly and also bulky.
And additional violence would have to be done to the upstream test
suite to try to make it work when "installed", rather than when run
out of the source tree as it expects. This is probably going to be
much harder than simply arranging for the tests to test the installed
rather than built copy (if they don't already).
Thirdly: having the tests in a source package makes it easier to run
one version of the tests against a different version of the package.
This is beca
Re: package testing, autopkgtest, and all that
Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"):
> All that considered, I'd like to know the rationale of this initial
> design choice as well. In particular, it would be nice to know if anyone
> see disadvantages in having *also* (rather then "instead") support for
> running tests which are not part of a source package.
I hope I have answered the substantive questions in my other recent
email.
As for "also" running tests which are "not part of a source package",
it is very easy to wrap up some tests in a dedicated source package if
that's desirable. The source package is then just a convenient
container format. There is no requirement in autopkgtest that the
source package containing tests generates any binary packages at all,
let alone that it generates the particular things being tested.
> > So, where do we start/continue sharing the thoughts on a tentative
> > DEP? ;)
>
> Let's see first if we have all the arguments on the table already,
> thanks to this thread. I'm willing to co-drive a DEP to finalize the
> spec, although I definitely need helping hands (hint, hint!).
One point I would like to make is that people who are now raising
objections to fundamental design decisions are, I think, five and a
half years too late.
The design, both in principle and detail, was discussed in November
2005 on various Debian lists. Amongst other people, you, Stefano,
participated. In February 2006 I reported that I had an initial
implementation.
I don't think going back the drawing board now is a very good idea.
What we are lacking is deployment (and, sorry for my part in the lack
of that).
Ian.
--
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/19785.27134.803778.102...@chiark.greenend.org.uk
Re: package testing, autopkgtest, and all that
On Wed, 02 Feb 2011 at 14:15:07 +, Ian Jackson wrote: > So if the tests were in binary packages, often we'd have to construct > a weird binary package which contained all or part of the built source > tree. This would be very ugly and also bulky. FWIW, Maemo does this, and it's a pain to deal with in practice. Basically nobody writes upstream tests like this, leading to a lot of strange goo in debian/rules: http://gitorious.org/gnome-essentials/dbus-glib/blobs/maemo/debian/rules I think Ian's right, this approach should be avoided. > This is probably going to be > much harder than simply arranging for the tests to test the installed > rather than built copy (if they don't already). For those familiar with Automake or the GNU coding standards, this is the distinction between "make check" (take the uninstalled copy I just compiled, and test it), and "make installcheck" (test the installed version of this package). Automake's "make distcheck" also runs installcheck on the just-installed binaries, if implemented. I get the impression that implementations of installcheck are also quite rare, but telepathy-mission-control-5 is one example of a package that has it. It runs a subset of the "make check" tests on the installed binary. (It's a subset because some of the Mission Control tests require extra hooks in the binary, to manipulate its internal state directly - the "make check" tests run on a modified binary with extra D-Bus interfaces to do that, but the tests relying on this functionality are skipped in "make installcheck" because they wouldn't work.) Simon -- 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/20110202150428.ga26...@reptile.pseudorandom.co.uk
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote: > As for "also" running tests which are "not part of a source package", > it is very easy to wrap up some tests in a dedicated source package if > that's desirable. The source package is then just a convenient > container format. There is no requirement in autopkgtest that the > source package containing tests generates any binary packages at all, > let alone that it generates the particular things being tested. I wonder how that would look in detail. For software in "our" field we also need to deal with test suites that upstream intents to be ran by users, that comes as a separate download with substantial size. Would I have to wrap them into a source package that builds no binary packages? Is that possible with the current infrastructure at all? > > Let's see first if we have all the arguments on the table already, > > thanks to this thread. I'm willing to co-drive a DEP to finalize the > > spec, although I definitely need helping hands (hint, hint!). > > One point I would like to make is that people who are now raising > objections to fundamental design decisions are, I think, five and a > half years too late. > > The design, both in principle and detail, was discussed in November > 2005 on various Debian lists. Amongst other people, you, Stefano, > participated. In February 2006 I reported that I had an initial > implementation. > > I don't think going back the drawing board now is a very good idea. > What we are lacking is deployment (and, sorry for my part in the lack > of that). I don't necessarily take the point of being 5 years too late. If everything was optimal and decided 5 years ago, why is nobody using this system? Having all the other testing approaches around clearly indicates that there is demand... Michael -- Michael Hanke http://mih.voxindeserto.de -- 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/20110202150832.GA2014@meiner
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 10:08:32AM -0500, Michael Hanke wrote: > > I don't think going back the drawing board now is a very good idea. > > What we are lacking is deployment (and, sorry for my part in the lack > > of that). > > I don't necessarily take the point of being 5 years too late. If > everything was optimal and decided 5 years ago, why is nobody using this > system? Having all the other testing approaches around clearly indicates > that there is demand... Just in case: I didn't mean to sound too negative. I see the rational in having things the way they are in autopkgtest, but maybe we can also think about autopkgtest as one essential core component and a general approach to distribution-wide single- and cross-package testing. Michael -- Michael Hanke http://mih.voxindeserto.de -- 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/20110202151604.GB2014@meiner
Re: package testing, autopkgtest, and all that
Hi Ian, thanks for the input! It does make motivation behind source packages-based testing clearer. And Simon's example is a good one ;-) As a summary: source packages-based testing often provides more convenient and upstream-friendly approach, thus it must not be "excluded", echoing Stefano's comment that ideally we might want having both (source and binary packages testing). Moreover we might need a simple registry/specification on how already existing packages could expose included test batteries (so echoing back to debian/README.test): e.g. many python modules have tests included and could easily be invoked with 'nosetests module' or 'python -c "import module; module.test()"', so we just need a specification installed on how to run the tests (and possibly common output formats so our backend could pick them up, e.g. nosetests, py.test, ctest, etc). As such, those packages do not need separate binary package, nor source package for testing. or alternatively -- they are already 'testing' binary packages without clear specification on how to invoke the tests and collect the results. > > Unfortunately the core aspect of the current autopkgtest - relying > > on tests in source packages -- imho to be not the ideal solution to > > target both sides of the userbase (i.e. maintainers/QA vs mortals). > I'm not sure I know what you mean. in the core -- users usually do not deal with source packages; many of them do not even have deb-src lines for apt. They do not care how things are built, but if we want them to contribute by testing their systems, the simplest approach is exposing test batteries as binary packages. Of cause, user-friendly front-end might overcome those difficulties even if tests are provided in source packages. Once again, many arguments behind source packages-based testing are sound to me, but I must disagree with many statements in the "bigger overhead" argument: > - Binary packages get entries in a large number of databases both >in our central infrastructure and on users' systems and imho it is ok -- we already have -dbg packages which are also of marginal importance to users, unless they need them, so they get installed them explicitly > - Binary packages are highly visible in ways that test infrastructure >doesn't need to be we (at least me and Michael) do want making them visible -- that is the point. Otherwise they would not be exercised, and be left unknown (e.g. like qa-regression-testing ;-) ) > - They are relatively complicated to produce yes -- unless the opposite ;) i.e. for many packages, indeed, source packages testing seems to be more adequate. > - They can only be installed in particular locations I do not see it much as a disadvantage > - Only one version can be present on a system at once (unless even >more complicated things are done) for the goal of testing current system setup, installing the single, most recent battery, sounds sufficient. To complement there are snapshot.debian.org and backports.debian.org, so any previous or backported version could be made available -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20110202155039.gb13...@onerussian.com
Re: package testing, autopkgtest, and all that
Michael Hanke writes ("Re: package testing, autopkgtest, and all that"):
> On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote:
> > As for "also" running tests which are "not part of a source package",
> > it is very easy to wrap up some tests in a dedicated source package if
> > that's desirable. The source package is then just a convenient
> > container format. There is no requirement in autopkgtest that the
> > source package containing tests generates any binary packages at all,
> > let alone that it generates the particular things being tested.
>
> I wonder how that would look in detail. For software in "our" field we
> also need to deal with test suites that upstream intents to be ran by
> users, that comes as a separate download with substantial size. Would I
> have to wrap them into a source package that builds no binary packages?
> Is that possible with the current infrastructure at all?
I don't know how possible it is with the current Debian archive but I
guess you could have it generate a dummy package with priority extra.
Ian.
--
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/19785.32053.211813.590...@chiark.greenend.org.uk
Re: Misc Developer News (#24)
On 2011-02-01, Simon Paillard wrote: > On Tue, Feb 01, 2011 at 10:34:48PM +0100, Alexander Reichle-Schmehl wrote: >> * Goswin von Brederlow [110201 21:29]: >> > > squeeze release live microblogging >> [..] >> > Is there a ToDo list of things that need to happen during the release >> > process, idealy with ETAs? Something that gives an overview without the >> > distractions of funny and otherwise interesting facts about Debian? >> Yes, there are checklists. But TTBOMK there are not ETAs. > http://wiki.debian.org/HowToRelease > (which has not been edited since 2009) If you start linking to the wiki, take the right page: http://wiki.debian.org/ReleaseTimetable And yeah, those pages are usually only updated at release time. That's not necessarily a bad thing, really. Kind regards Philipp Kern -- 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/slrnikj0m3.uss.tr...@kelgar.0x539.de
Re: package testing, autopkgtest, and all that
Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"):
> in the core -- users usually do not deal with source packages; many of
> them do not even have deb-src lines for apt. They do not care how
> things are built, but if we want them to contribute by testing their
> systems, the simplest approach is exposing test batteries as binary
> packages. Of cause, user-friendly front-end might overcome those
> difficulties even if tests are provided in source packages.
I don't understand what your usage model is. Are you expecting random
users to execute the tests ? Why would they do that ? What kind of
useful outcome is this likely to produce ?
I think that someone who doesn't have a "deb-src" line in their
sources.list, and has no knowledge of the existence of source
packages, is very unlikely to produce a useful bug report which leads
to an improvement to the software.
Making test suites highly end-user-visible is simply likely to result
in a lot of noise.
> > - Binary packages get entries in a large number of databases both
> >in our central infrastructure and on users' systems
>
> and imho it is ok -- we already have -dbg packages which are also of
> marginal importance to users, unless they need them, so they get
> installed them explicitly
A much larger proportion of the users of libfoo-dev are likely to want
to install libfoo-dbg, than the proportion of the users of coreutils
who want to run its regression tests. Furthermore, if you wanted
libfoo-dbg then a copy of the debug library in the built source tree
is no good to you because you want it to be picked up by your existing
build and runtime system for whatever you are compiling or running
that links against libfoo.
> for the goal of testing current system setup, installing the single,
> most recent battery, sounds sufficient. To complement there are
> snapshot.debian.org and backports.debian.org, so any previous or
> backported version could be made available
Our mechanisms for downloading and installing specific binary packages
from different source are not very well-developed.
Ian.
--
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/19785.33457.397049.476...@chiark.greenend.org.uk
Bug#611828: ITP: probalign -- multiple sequence alignment using partition function posterior probabilities
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: probalign Version : 1.4 Upstream Author : Usman Roshan * URL : http://cs.njit.edu/usman/probalign/ * License : Public Domain Programming Lang: C++ Description : multiple sequence alignment using partition function posterior probabilities Probalign uses partition function posterior probability estimates to compute maximum expected accuracy multiple sequence alignments. It performs statistically significantly better than the leading alignment programs Probcons v1.1, MAFFT v5.851, and MUSCLE v3.6 on BAliBASE 3.0, HOMSTRAD, and OXBENCH benchmarks. Probalign improvements are largest on datasets containing N/C terminal extensions and on datasets with long and heterogeneous length sequences. On heteregeneous length datasets containing repeats Probalign alignment accuracy is 10% and 15% than the other three methods when standard deviation of length is at least 300 and 400. The package will be maintained by the Debian Med packaging team and is ready for upload at Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/probalign/trunk/?rev=0&sc=0 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/probalign/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20110202163915.4003.65326.report...@mail.an3as.eu
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 04:13:37PM +, Ian Jackson wrote:
> Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"):
> > in the core -- users usually do not deal with source packages; many of
> > them do not even have deb-src lines for apt. They do not care how
> > things are built, but if we want them to contribute by testing their
> > systems, the simplest approach is exposing test batteries as binary
> > packages. Of cause, user-friendly front-end might overcome those
> > difficulties even if tests are provided in source packages.
>
> I don't understand what your usage model is. Are you expecting random
> users to execute the tests ? Why would they do that ? What kind of
> useful outcome is this likely to produce ?
We expect any person that is interested or asked to run test to do it
and be able to do it. They would do that because they need to be sure
that things work as intended and already do that in many cases. A common
use case are scientific analysis toolkits: We have seen them break due
to a change in a shared lib in Debian -- a change that upstream doesn't
see, because they link statically against ancient and "approved"
versions.
There are various labs that are very interested in verifying that
"random" library updates don't break their systems, which can happen
with any update.
If "random user" clicks the TestMyDebianSystem "button" the outcome
might be a passed test and everybody is happy, or a failure with a log.
> I think that someone who doesn't have a "deb-src" line in their
> sources.list, and has no knowledge of the existence of source
> packages, is very unlikely to produce a useful bug report which leads
> to an improvement to the software.
Think about a dashboard that collects failures and passes. Even if a
single user cannot produce a good report, you'll know that something is
wrong if suddenly many machines report trouble.
But to get many machines, we need to make it dead-simple to participate
in this type of croud-testing. We can have GUI frontends to let people
do specific tests, or offer "backfill" job configurations for compute
clusters.
> Making test suites highly end-user-visible is simply likely to result
> in a lot of noise.
Higher noise, but more samples -- I'm not sure what offers the best
estimate of the actual status.
I see the point in having less by better-quality input to package
maintainers, but again, the test results do not have to go one-by-one to
a human to inspect.
> > for the goal of testing current system setup, installing the single,
> > most recent battery, sounds sufficient. To complement there are
> > snapshot.debian.org and backports.debian.org, so any previous or
> > backported version could be made available
>
> Our mechanisms for downloading and installing specific binary packages
> from different source are not very well-developed.
Maybe that is something we should work on in this context.
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
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/20110202170156.GA4928@meiner
Re: package testing, autopkgtest, and all that
Michael Hanke writes ("Re: package testing, autopkgtest, and all that"):
> But to get many machines, we need to make it dead-simple to participate
> in this type of croud-testing. We can have GUI frontends to let people
> do specific tests, or offer "backfill" job configurations for compute
> clusters.
>
> > Making test suites highly end-user-visible is simply likely to result
> > in a lot of noise.
>
> Higher noise, but more samples -- I'm not sure what offers the best
> estimate of the actual status.
Maintainers don't want large amounts of low-quality information. That
is very difficult to use for fixing bugs.
> I see the point in having less by better-quality input to package
> maintainers, but again, the test results do not have to go one-by-one to
> a human to inspect.
We don't have any infrastructure for dealing with this kind of
information in bulk. I think that what you are proposing is a
different kind of thing to autopkgtest and it would be best for us to
deploy autopkgtest now as it already exists.
> There are various labs that are very interested in verifying that
> "random" library updates don't break their systems, which can happen
> with any update.
This is easily done with autopkgtest; the only difference from your
proposal is that the source package needs to be downloaded. Doing so
is not difficult or troublesome, and can be done automatically.
Ian.
--
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/19785.37041.123734.4...@chiark.greenend.org.uk
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 05:13:21PM +, Ian Jackson wrote:
> Michael Hanke writes ("Re: package testing, autopkgtest, and all that"):
> > I see the point in having less by better-quality input to package
> > maintainers, but again, the test results do not have to go one-by-one to
> > a human to inspect.
>
> We don't have any infrastructure for dealing with this kind of
> information in bulk. I think that what you are proposing is a
> different kind of thing to autopkgtest and it would be best for us to
> deploy autopkgtest now as it already exists.
This being the second missing piece of infrastructure that is mentioned in this
thread, and IMHO worth thinking about.
> > There are various labs that are very interested in verifying that
> > "random" library updates don't break their systems, which can happen
> > with any update.
>
> This is easily done with autopkgtest; the only difference from your
> proposal is that the source package needs to be downloaded. Doing so
> is not difficult or troublesome, and can be done automatically.
Fair enough.
In the context of a DEP the question remains whether we want to hammer
it in stone that separately distributed upstream testsuites need to be
source packaged and build dummy binary packages?
Moreover, I'm begining to wonder what the scope of this DEP would be:
any type of testing done in Debian, or a limited subset like per-package
unit/regression tests?
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
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/20110202174726.GA6607@meiner
Re: package testing, autopkgtest, and all that
On ke, 2011-02-02 at 17:13 +, Ian Jackson wrote: > This is easily done with autopkgtest; the only difference from your > proposal is that the source package needs to be downloaded. Doing so > is not difficult or troublesome, and can be done automatically. I concur. However, looking things from a slightly different angle, I can see several use cases for automated testing in Debian: * the package maintainers want to know that their package works * upstream wants to know we haven't broken anything in Debian * release managers (and everyone else!) want to know the disto in general is ready to release, and also that any one updated package doesn't break other stuff (e.g., libpng might break web browsers using it) * security team wants to know the security update doesn't break anything * sysadmins want to know upgrading to a new release doesn't break their servers * I want to know I can upgrade to today's version of testing without anything major breaking Obviously, no amount of testing will be able to find all breakage, but even a relatively low test coverage can be extremely helpful, if it is targeted suitably. autopkgtest seems to me to target package maintainers, release managers, and the security team, from the list above. A different toolset and possibly testset might be necessary for other use cases. Once we have those tools, we can use them, but for now concentrating on autopkgtest is probably the best idea. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1296668875.8434.10.ca...@havelock.lan
Re: package testing, autopkgtest, and all that
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote:
> One point I would like to make is that people who are now raising
> objections to fundamental design decisions are, I think, five and a
> half years too late.
>
> The design, both in principle and detail, was discussed in November
> 2005 on various Debian lists. Amongst other people, you, Stefano,
> participated. In February 2006 I reported that I had an initial
> implementation.
>
> I don't think going back the drawing board now is a very good idea.
> What we are lacking is deployment (and, sorry for my part in the lack
> of that).
I don't think anyone in this thread was suggesting to go back to the
drawing board; I surely wasn't. That is the case not because "we should
have done so 5 years ago": if there is some design flaw that wasn't spot
back then---which is possible given that deployment is missing---it
should be fixed nonetheless. Rather it is the case because there is an
implementation (thanks to you) and barking around that tree without
having an alternative implementation (or a patch) to propose is
pointless.
I was merely looking for rationales that explain the interface gap
between the expectations of some participants of this thread and what is
currently available in the implementation. Looking at the arguments you
provided later on, I'm convinced that the source package wrapping is no
big overhead. My main use case of maintaining tests in some $VCS
separate from archive packages can be easily implemented by just having
a proper debian/ dir stored in that repository, which is fair enough.
Regarding the DEP (which I fully agree is just "marketing", although
that kind of marketing is part of any deployment strategy in a volunteer
community), what I'm still trying to figure out are the success criteria
and the final place where the specification should land. Would policy be
a reasonable expectation, once (and if) we reach wide spread adoption?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#611852: ITP: ctioga2 -- polymorphic plotting program
Package: wnpp Severity: wishlist Owner: Vincent Fourmond * Package name: ctioga2 Version : 0.1 Upstream Author : Vincent Fourmond * URL : http://ctioga2.rubyforge.org/ * License : GPL Programming Lang: Ruby Description : polymorphic plotting program ctioga2 is a plotting program in the spirit of gnuplot. It can be used either directly on command-line or writing command files (or a mix of both). It produces publication-quality PDF files. It is based on the Tioga plotting library. ctioga2 is a full rewrite of ctioga and is meant to replace it completely in a not-so-distant future. -- 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/20110202212818.13286.62909.report...@tanyaivinco.homelinux.org
Bug#611859: ITP: perroquet -- a program to train your oral skills in foreign languages
Package: wnpp Severity: wishlist Owner: Georges Khaznadar * Package name: perroquet Version : 1.1.0 Upstream Authors: Frédéric Bertolus , Matthieu Bizien * URL : http://perroquet.b219.org/ * License : GPL-3+ Programming Lang: Python Description : a program to train your oral skills in foreign languages this program allows to prepare sequences of video or audio files, with subtitles. The trainee will have to guess a few missing words each time the record is paused. -- 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/20110202224750.28995.10631.report...@photos.khaznadar.fr
Bug#611863: ITP: rq -- parallel queued computation with no configuration
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: rq * URL : http://codeforpeople.com/lib/ruby/rq/ * License : BSD Programming Lang: Ruby Description : parallel queued computation with no configuration ruby queue (rq) is a zero-admin zero-configuration tool used to create instant unix clusters. rq requires only a central nfs filesystem in order to manage a simple sqlite database as a distributed priority work queue. this simple design allows researchers with minimal unix experience to install and configure, in only a few minutes and without root privileges, a robust unix cluster capable of distributing processes to many nodes - bringing dozens of powerful cpus to their knees with a single blow. clearly this software should be kept out of the hands of free radicals, seti enthusiasts, and one mr. j safran. the central concept of rq is that n nodes work in isolation to pull jobs from an centrally mounted nfs priority work queue in a synchronized fashion. the nodes have absolutely no knowledge of each other and all communication is done via the queue meaning that, so long as the queue is available via nfs and a single node is running jobs from it, the system will continue to process jobs. there is no centralized process whatsoever - all nodes work to take jobs from the queue and run them as fast as possible. this creates a system which load balances automatically and is robust in face of node failures. although the rq system is simple in it's design it features powerful functionality such as priority management, predicate and sql query , compact streaming command-line processing, programmable api, hot-backup, and input/capture of the stdin/stdout/stderr io streams of remote jobs. to date rq has had no reported runtime failures and is in operation at dozens of research centers around the world. The packaging is mostly complete and will soon hit the archive. -- 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/20110202234728.25591.12635.report...@master.dermacloud.uni-luebeck.de
Invierta su Dinero de Forma segura.
Make Bussines es un empresa de inversiones en Forex con sede en Italia (Offices: Viale Giulio Cesare N 21 Interno 2 Zona Prati Fiscali - Italia Telephones: (39)3270651740), se encuentra online desde Octubre del 2009, esta respaldada por un Procesador de pagos Promonix Corp (Promonix se encuentra ubicado en Italia, en Via Delle Resede 20 con Numero de constitución: 464 110 - Comercio. Telefonos: 39 327637 - 39 3276374440.) que tambien tiene sede en Italia el cual brinda tarjeta debito promonix a todos sus clientes, en Make Business se puede invertir con Paypal, liberty reserve, wester union, money gram, y Promonix. En make se puede invertir por liberty rserve, paypal, promonix corp, weser union o Money gram. Igualmente puede retirar de make por los mismos medios y ademas por una tarjeta debito que le da Promonix Corp para retirar el saldo de Promonix que le paga Make. Aqui puede ver un video de un retiro con la tarjeta: http://www.youtube.com/watch?v=-NR_w9cvzyA Esta empresa tiene su sede en Roma, Italia, se dedica a las inversiones online Forex desde octubre del 2009 Sus Planes de inversion son: Small Business Basic 100.00 - 1000.00 0.60% Middle 1000.01 - 3000.00 0.70% Middle Business Basic 3000.01 - 5000.00 0.80% Middle 5001.01 - 7000.00 1.00% Standar 7000.01 - Unlimited 1.20% Tambien tiene un sistema de comision por referidos extraordinariamente bueno. Nivel de referido Comisión 1 5.00% 2 3.00% 3 1.00% Excelente oportunidad de inversion. https://www.makebussines.com?ref=3254 Aqui puedes ver un video retirando con la tarjeta promonix corp: http://www.youtube.com/watch?v=-NR_w9cvzyA Aqui puede ver un tutorial Para crear una cuenta en Make Business: http://www.youtube.com/watch?v=P2xj-8SnQBw Aquí puede ver un tutorial para pedir la tarjeta promonix: http://www.youtube.com/watch?v=0sdJkJNXnNs Aqui pude ver un tutorial para crear una cuenta en Promonix: http://www.youtube.com/watch?v=ImKUdoWlNXk -- 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/47601913507122449419301@colossus
Bug#611869: ITP: compass-yui-plugin -- Compass plugin implementing the YUI CSS Foundation
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: compass-yui-plugin Version : 0~20100724 Upstream Author : Christopher Eppstein * URL : https://github.com/chriseppstein/yui-compass-plugin * License : BSD-3-clause Programming Lang: Sass Description : Compass plugin implementing the YUI CSS Foundation Compass is a framework for compiling CSS from similar yet more flexible Sass (either .sass or .scss) source files. . This package contains an implementation of the YUI CSS foundation, including CSS Reset, CSS Fonts, and CSS Grids resources, for Compass. -- 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/20110203055940.8578.1203.reportbug@localhost.localdomain
