Bug#610863: ITP: libtwiggy-perl -- AnyEvent HTTP server for PSGI (like Thin)
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: libtwiggy-perl Version : 0.1010 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Twiggy/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : AnyEvent HTTP server for PSGI (like Thin) Twiggy is a lightweight and fast HTTP server with unique features: * Can run any PSGI applications. Fully supports psgi.nonblocking and psgi.streaming interfaces. * This server uses AnyEvent and runs in a non-blocking event loop, so it's best to run event-driven web applications that runs I/O bound jobs or delayed responses such as long-poll, WebSocket or streaming content (server push). * Uses XS/C based HTTP header parser for the best performance. (optional) * The memory required to run twiggy is 6MB and it can serve more than 4500 req/s with a single process on Perl 5.10 with MacBook Pro 13" late 2009. * Supports Server::Starter for hot deploy and graceful restarts. -- 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/20110123134054.13689.50819.reportbug@localhost.localdomain
kernel-wedge does not work as expected.
Hi, I am trying to make a custom debian-installer cd. I have done this before, things worked fine. But this time, I got a problem. My running kernel installed from linux-image-2.6.36.3i686_bfs363.reiser4_i386.deb. It contains a naming mistake. So I make-kpkg a new one named linux-image-2.6.36.3-686_bfs363.reiser4_i386.deb and installed, not running. Then I have linux-kernel-di-i386-2.6-1.99/kernel-version as "i386 2.6.36.3 686 2.6.36.3-686 - linux-image-2.6.36.3-686_bfs363.reiser4". Here is the problem, `kernel-wedge build-arch i386` always tell me: dpkg-source: warning: can't parse dependency linux-image-2.6.36.3i686_bfs363.reiser4 [i386] dpkg-source: error: error occurred while parsing Build-Depends According to http://wiki.debian.org/DebianInstaller/Modify/CustomKernel, kernel-wedge could handle kernel package that were not running. Why here it insists on running kernel? -- 竹密岂妨流水过 山高哪阻野云飞 -- 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/aanlktikeyehkfcdvnffvymsrdrrk93bkhxc7v8j5p...@mail.gmail.com
Re: New version of DEP-5 parser
Le vendredi 21 janvier 2011 22:18:18, Steve Langasek a écrit :
> Not having looked at the code, I'm wondering: do you apply these
> translations to all files regardless of the Format/Format-Specification
> field's value, or are you selective about only applying these upgrades to
> fields that were considered valid at the time?
It's not selective. The model [1] that defines the behavior during the upgrade
is purely declarative.
Config::Model was designed to handle configuration files where the concept of
unknown parameter does not apply.
> I don't think, for
> instance, that a file that has a declaration of Format:
> http://dep.debian.net/deps/dep5/ [1] should have 'Maintainer' fields
> auto-upgraded to 'Upstream-Contact', but that this should instead be
> treated as an unknown field.
Like others, the history of this parameter is complicated. It was required,
then deprecated, and now legal (but with a possibly different semantic
content). If you factor in the possibility of human error (e.g. modern
format, but forgotten Maintainer field), having a DEP-5 validated file
may not mean much.
For instance, this DEP-5 file is valid, since Maintainer field
is accepted as an unknown parameter and Upstream-Contact is optional:
Format: http://dep.debian.net/deps/dep5/
Maintainer: foo@bar
Files: *
Copyright: (c) me
License: GPL-2+
This program is free software; you can redistribute it
and/or modify it [snip]
In this case, is this an error or a DD who does not
like the Upstream-Contact keyword ?
Note that the debian policy is respected since the upstream
info is provided. But the original objective of DEP5
("facilitate automated checking and reporting of licenses
for packages and sets of packages) is in jeopardy.
If the consensus is that such a Maintainer field should be left
as is, one solution would be to keep the current model with its upgrade
capability and provide another pure dep-5 model.
Then the user would to choose between:
- the dep-5-model-with-upgrade (and a few drawbacks like
deprecated Maintainer fields)
- a pure dep-5 without migration
I'll provide the latter if people ask for it for actual use.
All the best
Dominique
[1]
http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.230/lib/Config/Model/models/Debian/Dpkg/Copyright.pl
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.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/201101231509.01093.domi.dum...@free.fr
Re: kernel-wedge does not work as expected.
On 01/23/2011 03:06 PM, Magicloud Magiclouds wrote: > Hi, > I am trying to make a custom debian-installer cd. I have done this > before, things worked fine. But this time, I got a problem. > My running kernel installed from > linux-image-2.6.36.3i686_bfs363.reiser4_i386.deb. It contains a naming > mistake. So I make-kpkg a new one named > linux-image-2.6.36.3-686_bfs363.reiser4_i386.deb and installed, not > running. > Then I have linux-kernel-di-i386-2.6-1.99/kernel-version as "i386 > 2.6.36.3 686 2.6.36.3-686 - > linux-image-2.6.36.3-686_bfs363.reiser4". > Here is the problem, `kernel-wedge build-arch i386` always tell me: > dpkg-source: warning: can't parse dependency > linux-image-2.6.36.3i686_bfs363.reiser4 [i386] > dpkg-source: error: error occurred while parsing Build-Depends > According to http://wiki.debian.org/DebianInstaller/Modify/CustomKernel, > kernel-wedge could handle kernel package that were not running. Why > here it insists on running kernel? The problem is that a package name cannot contain an underscore. A package name must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). Cheers Luk -- 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/4d3c4bbf.1080...@debian.org
Bug#610893: ITP: python-espeak -- Python bindings for eSpeak
Package: wnpp Severity: wishlist Owner: "Siegfried-Angel Gevatter Pujals" * Package name: python-espeak Version : 0.2 Upstream Author : Siegfried-A. Gevatter * URL : https://launchpad.net/python-espeak * License : GPLv3+ Programming Lang: C++ Description : Python bindings for eSpeak eSpeak is a software speech synthesizer for English, and some other languages. . eSpeak produces good quality English speech. It uses a different synthesis method from other open source text to speech (TTS) engines, and sounds quite different. It's perhaps not as natural or "smooth", but some find the articulation clearer and easier to listen to for long periods. . This package contains bindings to use eSpeak from within Python applications. . Be aware that python-espeak is still in an early state; it's incomplete and the API may change in future versions. -- 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/20110123195622.6891.65070.reportbug@gepard.savanna
DEP5: "extra" fields compliant with the spec? [Was, Re: New version of DEP-5 parser]
On Sun, Jan 23, 2011 at 03:09:00PM +0100, Dominique Dumont wrote: > Le vendredi 21 janvier 2011 22:18:18, Steve Langasek a écrit : > > Not having looked at the code, I'm wondering: do you apply these > > translations to all files regardless of the Format/Format-Specification > > field's value, or are you selective about only applying these upgrades to > > fields that were considered valid at the time? > It's not selective. The model [1] that defines the behavior during the > upgrade > is purely declarative. > Config::Model was designed to handle configuration files where the concept of > unknown parameter does not apply. > > I don't think, for > > instance, that a file that has a declaration of Format: > > http://dep.debian.net/deps/dep5/ [1] should have 'Maintainer' fields > > auto-upgraded to 'Upstream-Contact', but that this should instead be > > treated as an unknown field. > Like others, the history of this parameter is complicated. It was required, > then deprecated, and now legal (but with a possibly different semantic > content). If you factor in the possibility of human error (e.g. modern > format, but forgotten Maintainer field), having a DEP-5 validated file > may not mean much. I don't think it means much when applying such heuristics to auto-convert field names, either. I have always been lukewarm on the idea of specifying within the DEP itself that "extra fields can be added" without standards-compliance implications. I don't think people should be adding random fields here without first *defining* those fields; and with DEP5, defining them is as straightforward as taking a copy of the DEP, adding your field definitions to it, posting that modified document to the web and referencing the new URL in your Format: declaration. It's not like this even requires you to write a formal XML DTD or something, so I really don't think this is too high a barrier; and if someone thinks that it is, there's always the Comment: field already defined for the purpose of including arbitrary text in the document. It would be my strong preference to see the language in DEP5 clarified in this manner, and parsers modified to treat unknown fields as validation *failures* when referencing a known Format: URL. > For instance, this DEP-5 file is valid, since Maintainer field > is accepted as an unknown parameter and Upstream-Contact is optional: > Format: http://dep.debian.net/deps/dep5/ > Maintainer: foo@bar > Files: * > Copyright: (c) me > License: GPL-2+ > This program is free software; you can redistribute it > and/or modify it [snip] > In this case, is this an error or a DD who does not > like the Upstream-Contact keyword ? Yes, I think that's a good example of why the current DEP language needs to be improved on this score. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DEP5: "extra" fields compliant with the spec? [Was, Re: New version of DEP-5 parser]
On Sun, Jan 23, 2011 at 12:29:03PM -0800, Steve Langasek wrote: I don't think people should be adding random fields here without first *defining* those fields; and with DEP5, defining them is as straightforward as taking a copy of the DEP, adding your field definitions to it, posting that modified document to the web and referencing the new URL in your Format: declaration. It's not like this even requires you to write a formal XML DTD or something, so I really don't think this is too high a barrier; and if someone thinks that it is, there's always the Comment: field already defined for the purpose of including arbitrary text in the document. It would be my strong preference to see the language in DEP5 clarified in this manner, and parsers modified to treat unknown fields as validation *failures* when referencing a known Format: URL. +1 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#610904: ITP: libstarman-perl -- High-performance preforking PSGI/Plack web server
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: libstarman-perl Version : 0.2007 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Starman/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : High-performance preforking PSGI/Plack web server Starman is a PSGI perl web server that has unique features such as: * High Performance - Uses the fast XS/C HTTP header parser * Preforking - Spawns workers preforked like most high performance UNIX servers do. Starman also reaps dead children and automatically restarts the worker pool. * Signals - Supports HUP for graceful restarts, and TTIN/TTOU to dynamically increase or decrease the number of worker processes. * Superdaemon aware - Supports Server::Starter for hot deploy and graceful restarts. * Multiple interfaces and UNIX Domain Socket support - Able to listen on multiple intefaces including UNIX sockets. * Small memory footprint - Preloading the applications with --preload-app command line option enables copy-on-write friendly memory management. Also, the minimum memory usage Starman requires for the master process is 7MB and children (workers) is less than 3.0MB. * PSGI compatible - Can run any PSGI applications and frameworks * HTTP/1.1 support - Supports chunked requests and responses, keep-alive and pipeline requests. -- 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/20110123205321.22067.17018.reportbug@localhost.localdomain
Re: Bits from the Security Team (for those that care about bits)
On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote: > Hi! > > In the weekend 14-16 January 2011, the Debian Security Team convened in > Linux Hotel, Essen. We discussed many things, a lot of security work was done > and of course the necessary socialising wasn't forgotten. We'd like to thank > the Linux Hotel for again receiving us in such a great way! […] > * README.test > > Although many packages include a test suite that is run after package build, > there are packages that do not have such a suite, or not one that can be > run as part of the build process. It was proposed to standardise on a > README.test file, analogous to README.source, describing to others than the > regular maintainer how the package's functionality can properly be tested. > This is something we would like to see discussed and implemented for the > Wheezy development cycle. This is a very good idea, but I think it could be taken two steps further. These are just some ideas I have but did not explore in depth, so take them with a grain of salt. First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Of course, these would be useful only for some classes of packages, but for those they would be of much help. I have something like this in one package of mine, and it gives me a lot of confidence while doing packaging changes. thanks, iustin signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: > First, tests run during a package build are good, but they do not > ensure, for example, that the package as installed is working OK. I've > been thinking that (also) providing tests to be run after the package is > installed (and not on the build results) would be most useful in > ensuring that both the build process and the packaging is correct. > > Second, README.test are designed for human consumption, whereas a > standardisation of how to invoke the tests would allow for much more > automation. E.g. piuparts would not only be able to test that the > install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html and here http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin If somebody is interested in working on this topic, we'd be glad to join forces. Originally, we wanted to develop the SPEC a little further, but since the topic came up, I figured it might be better to add these pointers now. Michael -- Michael Hanke http://mih.voxindeserto.de signature.asc Description: Digital signature
Bug#610921: ITP: felix-framework -- The Felix Framework subproject
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: felix-framework Version : 2.0.5 Upstream Author : The Apache Software Foundation * URL : http://felix.apache.org/site/apache-felix-framework.html * License : Apache-2.0 Programming Lang: Java Description : The Felix Framework subproject The Felix Framework subproject is an implementation of the OSGi R4.2 core framework specification. -- 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/4d3cca5c.5145e50a.5b97.1...@mx.google.com
Bug#610922: ITP: felix-main -- Classes to instatiate and execute the Felix Framework
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: felix-main Version : 2.0.5 Upstream Author : The Apache Software Foundation * URL : http://felix.apache.org/site/ * License : Apache-2.0 Programming Lang: Java Description : Classes to instatiate and execute the Felix Framework The Felix Framework subproject is an implementation of the OSGi R4.2 core framework specification. -- 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/4d3ccb52.5145e50a.5b97.1...@mx.google.com
Bug#610923: ITP: felix-osgi-obr -- OSGi OBR Service API
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: felix-osgi-obr Version : 1.0.2 Upstream Author : OSGi Alliance * URL : http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html * License : Apache-2.0 Programming Lang: Java Description : OSGi OBR Service API The goal of the Apache Felix OSGi Bundle Repository (OBR) is two-fold: 1. To simplify deploying and using available bundles with Felix. 2. To encourage independent bundle development so that communities of interest can grow. -- 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/4d3ccbf9.5145e50a.2611.1...@mx.google.com
Bug#610924: ITP: bindex -- The BIndex program
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: bindex Version : 2.2 Upstream Author : OSGi Alliance * URL : http://www.osgi.org/Repository/BIndex * License : Apache-2.0 Programming Lang: Java Description : The BIndex program Is a small Java progam that implements the manifest header to repository format mapping as described in RFC-0112 Bundle Repository. BIndex can recurse over a directory structure and just creates a repository.xml file. The URLs can be rewritten using a template. -- 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/4d3ccc95.5145e50a.490c.1...@mx.google.com
Bug#610926: ITP: bsaf -- Better Swing Application Framework
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: bsaf Version : 1.9 Upstream Author : Illya Yalovyy * URL : http://kenai.com/projects/bsaf * License : LGPL-2.1 Programming Lang: Java Description : Better Swing Application Framework The Better Swing Application Framework is a fork of the original Swing Application Framework (appframework) reference implementation of JSR 296. Since August 2009, the original Swing Application Framework project has been on hold, and therefore this fork was created to carry on the work until the original project resumes. . The last public release of the original appframework project was version 1.03. The BSAF project currently aims at producing a new release, version 1.9, with the primary goals of improving stability, keeping backward compatibility with SAF 1.03, fixing bugs, updating documentation, and creating more unit tests and examples. -- 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/4d3ccefd.467bdc0a.0c22.9...@mx.google.com
Bug#610927: ITP: libnb-platform-java -- NetBeans Platform for building rich desktop applications in Java
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers * Package name: libnb-platform-java Version : 6.9 Upstream Author : Oracle and/or its affiliates * URL : http://netbeans.org/ * License : CDDL-1 or GPL-2 with CLASSPATH exception Programming Lang: Java Description : NetBeans Platform for building rich desktop applications in Java NetBeans Platform is the framework for building rich desktop applications in Java. It is the core of the NetBeans IDE. -- 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/4d3cdb5b.4c8de50a.425f.1...@mx.google.com
Re: Bits from the Security Team (for those that care about bits)
Michael Hanke wrote: > On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: >> Second, README.test are designed for human consumption, whereas a >> standardisation of how to invoke the tests would allow for much more >> automation. E.g. piuparts would not only be able to test that the >> install succeeds, but the automated tests also work. > > Exactly. In the NeuroDebian team we started playing around with more > comprehensive testing -- both regarding single packages, but also > integration tests involving multiple packages. We started composing a > SPEC for a testing framework, but we haven't gotten very far, yet. What > we have is here > > http://neuro.debian.net/proj_debtest.html Thanks for starting this project! I hope a lot of progress is made so that it can be used for Wheezy. This topic is something I've been slowly working but haven't had much time. Other ideas: * http://bugs.debian.org/512265 * Something I wrote the other day (related to the d-d-a email): > A long term plan could be to push the creation of a framework so that it > is easy to test things such as webapps (which may require an httpd) and > other packages that are not very to setup (e.g. by providing a script that > creates a basic virtual machine, installs the needed stuff and then > control is handed over to the package-specific bits). > > Automated testing is something that we really ought to push. And there's also the possibility of re-using the same test framework to allow automated fuzzing (and easier fuzzing using custom environment, etc.) Somehow related to DACA too. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/ihipds$t3k$1...@dough.gmane.org
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop wrote: > First, tests run during a package build are good, but they do not > ensure, for example, that the package as installed is working OK. I've > been thinking that (also) providing tests to be run after the package is > installed (and not on the build results) would be most useful in > ensuring that both the build process and the packaging is correct. Debian has definitely needed this for a long time. I'm thinking that these automated post-install tests are something that all distributions could benefit from and probably we should push them upstream. Automated post-install testing would be great, but it cannot apply in all cases and should be complemented by README.test. I think both approaches are needed. For example: libwww-topica-perl: This is a perl module that interacts with a web service and screen scrapes their email list archive format to convert it to mbox format. Every few months I run the program on a specific list and compare it to the previously saved mbox file. The list is long-dead so there are no changes at all, unless the site changed its HTML and broke the package. This is trivially automatable. warzone2100: This is an interactive game. Testing it involves playing for several hours in single player mode and maybe trying to find someone to play in multiplayer mode. Definitely not automatable. Probably the only automatable test here would be to run it in Xvfb but that wouldn't test the package usefully. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/AANLkTikojANFHmf9=AEKauwB+BXf2O_ud=ON=X5x=i...@mail.gmail.com
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 10:52:54AM +0800, Paul Wise wrote: > On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop wrote: > > > First, tests run during a package build are good, but they do not > > ensure, for example, that the package as installed is working OK. I've > > been thinking that (also) providing tests to be run after the package is > > installed (and not on the build results) would be most useful in > > ensuring that both the build process and the packaging is correct. > > Debian has definitely needed this for a long time. > > I'm thinking that these automated post-install tests are something > that all distributions could benefit from and probably we should push > them upstream. > > Automated post-install testing would be great, but it cannot apply in > all cases and should be complemented by README.test. I think both > approaches are needed. Agreed—I wasn't suggesting that README.test is not useful, just that there is potential for more in this area, at least for some class of packages. > For example: > > libwww-topica-perl: > […] > warzone2100: > […] Good examples, indeed. regards, iustin signature.asc Description: Digital signature
Fwd / Terusan : Bisnis Tiket Pesawat Telah membagikan bonus untuk para mitranya sudah lebih dari SATU MILYAR RUPIAH...!!!
-- 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/LINGKARIPANGO24fae804f4344422884f4784dce9685f@lingkaripango
Re: Bits from the Security Team (for those that care about bits)
On Sun, Jan 23, 2011 at 06:45:56PM -0500, Michael Hanke wrote: > On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: > > First, tests run during a package build are good, but they do not > > ensure, for example, that the package as installed is working OK. I've > > been thinking that (also) providing tests to be run after the package is > > installed (and not on the build results) would be most useful in > > ensuring that both the build process and the packaging is correct. > > > > Second, README.test are designed for human consumption, whereas a > > standardisation of how to invoke the tests would allow for much more > > automation. E.g. piuparts would not only be able to test that the > > install succeeds, but the automated tests also work. > > Exactly. In the NeuroDebian team we started playing around with more > comprehensive testing -- both regarding single packages, but also > integration tests involving multiple packages. We started composing a > SPEC for a testing framework, but we haven't gotten very far, yet. What > we have is here > > http://neuro.debian.net/proj_debtest.html > > and here > > > http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin > > If somebody is interested in working on this topic, we'd be glad to join > forces. > > Originally, we wanted to develop the SPEC a little further, but since > the topic came up, I figured it might be better to add these pointers > now. Thanks for sharing. Your proposal seems to focus on a higher level, e.g. group-based testing, resource and scheduling, etc. IMHO what would be a sufficient first step would be much simpler: - being able to know if a package does offer build & post-install tests - how to run such tests - for post-install tests, what are the depedencies (Test-Depends? ;-) This would allow a maintainer to implement an automatic test of his packages whenever doing a new upload (which is my personal issue :). A framework like your proposed DebTest can then build upon such basic functionality to provide coordinated, archive-wide or package-set-wide running of tests. A few comments on your proposal: - “Metainformation: duration”: how do you standardise CPU/disk/etc. performance to get a useful metric here? - assess resources/performance: in general, across architectures/platforms and varied CPU speeds, I think it will be hard to quantify the performance and even resources needed for a test suite - some structured output: given the variety of test suites, this might be very hard to achieve; in my experience, the best that can be hoped for across heterogeneous software is a count of pass/fail, and log files should be left for human investigation in case of failures regards, iustin signature.asc Description: Digital signature
