Bug#611049: ITP: python-django-mptt -- Modified Preorder Tree Traversal Django application
Package: wnpp Severity: wishlist Owner: Janos Guljas * Package name: python-django-mptt Version : 0.4.2 Upstream Author : Jonathan Buchanan * URL : http://github.com/django-mptt/django-mptt * License : MIT Programming Lang: Python Description : Modified Preorder Tree Traversal Django application Django MPTT is a reusable/standalone Django application which aims to make it easy for you to use Modified Preorder Tree Traversal with your own Django models in your own applications. It takes care of the details of managing a database table as a tree structure and provides tools for working with trees of model instances. This package is a dependency for FainCMS Django application. An ITP bug #611048 is filed for that package. -- 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/20110125025859.23441.44171.report...@mac.resenje.org
Bug#611048: ITP: python-django-faincms -- Django-based Page CMS and CMS building toolkit
Package: wnpp Severity: wishlist Owner: Janos Guljas * Package name: python-django-faincms Version : 1.1.4 Upstream Author : Matthias Kestenholz * URL : http://github.com/matthiask/feincms * License : BSD Programming Lang: Python Description : Django-based Page CMS and CMS building toolkit FeinCMS is an extremely stupid content management system. It knows nothing about content -- just enough to create an admin interface for your own page content types. It lets you reorder page content blocks using a drag-drop interface, and you can add as many content blocks to a region (f.e. the sidebar, the main content region or something else). It provides helper functions, which provide ordered lists of page content blocks. FainCMS is dependent on python module 'mptt' which is not in Debian archive. I am going to file an ITP for that package, too. -- 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/20110125025120.23262.86553.report...@mac.resenje.org
Bug#611042: ITP: ladish -- session management system for JACK applications
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: ladish Version : 0.3 Upstream Author : Nedko Arnaudov * URL : http://ladish.org * License : GPL Programming Lang: C Description : session management system for JACK applications LADI Session Handler or simply ladish is a session management system for JACK applications on GNU/Linux. Its aim is to allow you to have many different audio programs running at once, to save their setup, close them down and then easily reload the setup at some other time. ladish doesn't deal with any kind of audio or MIDI data itself; it just runs programs, deals with saving/loading (arbitrary) data and connects JACK ports together. It can also be used to move entire sessions between computers, or post sessions on the Internet for download. -- 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/20110125010532.20183.67923.reportbug@alessio-laptop
Bug#611023: ITP: gtk2-engines-oxygen-gtk -- A port of the default KDE widget theme (Oxygen) to GTK+
Package: wnpp Severity: wishlist Owner: "P. J. McDermott" * Package name: gtk2-engines-oxygen-gtk Version : 1.0.1 Upstream Author : Bellegarde Cédric , Hugo Pereira Da Costa , Ruslan Kabatsayev * URL : https://projects.kde.org/projects/playground/artwork/oxygen-gtk * License : LGPL-2.1+ Programming Lang: C++ Description : A port of the default KDE widget theme (Oxygen) to GTK+ The primary goal of this theme engine is to ensure visual consistency between GTK+- and Qt-based applications running under KDE. A secondary objective is to also have a stand-alone nice looking GTK+ theme that would behave well on other desktop environments. Unlike other attempts made to port the kde oxygen theme to GTK+, this attempt does not depend on Qt (via some Qt to GTK+ conversion engine), nor does render the widget appearance via hard coded pixmaps, which otherwise breaks everytime some setting is changed in KDE. -- 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/20110124212535.32564.59598.reportbug@localhost.localdomain
Bug#611018: ITP: zeitgeist-datahub -- event logging framework - passive logging daemon
Package: wnpp Severity: wishlist Owner: "Siegfried-Angel Gevatter Pujals" * Package name: zeitgeist-datahub Version : 0.5.1 Upstream Author : Michal Hruby * URL : https://launchpad.net/zeitgeist-datahub * License : LGPL-3+ Programming Lang: Vala Description : event logging framework - passive logging daemon Zeitgeist is a service which logs the user's activities and events (files opened, websites visited, conversations hold with other people, etc.) and makes the relevant information available to other applications. . It serves as a comprehensive activity log and also makes it possible to determine relationships between items based on usage patterns. . This package contains zeitgeist-datahub, a daemon which starts together with the main engine and inserts information collected from GtkRecentlyUsed into it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124213854.4800.28630.reportbug@gepard.savanna
Re: Bits from the Security Team (for those that care about bits)
On Monday 24 January 2011, Iustin Pop wrote: > 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. FWIW, Ubuntu has a regression test suite: https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression- testing/master I didn't have a chance to look at it, yet, though. Cheers, Stefan -- 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/201101242132.26170...@sfritsch.de
Bug#611006: ITP: laditools -- tools to control and monitor LADI (JACK+LASH) system
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: laditools Version : 0~git.f4d4a2 Upstream Author : Marc-Olivier Barre * URL : http://marcochapeau.org/software/laditools * License : GPL Programming Lang: Python Description : tools to control and monitor LADI (JACK+LASH) system LADITools is a set of tools aiming to achieve the goals of the LADI project to improve desktop integration and user workflow of Linux audio system based on JACK and LASH. Those tools take advantage of the D-Bus interfaces recently added to JACK and LASH to ease the configuration and use of those two great softwares. . This package includes basic set of tools to control and monitor LADI system, that is JACK and LASH in a D-Bus environment. -- 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/20110124194808.4461.60905.reportbug@alessio-laptop
Re: autopkgtest (was Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 10:37:26AM +0100, Holger Levsen wrote: > Hi, > > On Montag, 24. Januar 2011, 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. > > Package: autopkgtest > Description: automatic as-installed testing for Debian packages > autopkgtest runs tests on binary packages. The tests are run on the > package as installed on a testbed system (which may be found via a > virtualisation or containment system). The tests are expected to be > supplied in the corresponding Debian source package. > . > See adt-run(1) and /usr/share/doc/autopkgtest. > Use of adt-virt-xenlvm requires the autopkgtest-xenlvm package too; > Use of the pre-cooked adt-testreport-onepackage script requires curl. > > > I'm happy that you like piuparts, but it's not the best tool for > everything :-) As I said, "E.g." - for example. Thanks for mentioning autopkgtest, I didn't know about it. iustin signature.asc Description: Digital signature
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote: > I was > wondering though if anybody had a better approach to recommend? Simply remove them. They are not needed for proper operation, as the shlibs file works as fallback. Bastian -- Virtue is a relative term. -- Spock, "Friday's Child", stardate 3499.1 -- 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/20110124174737.ga18...@wavehammer.waldi.eu.org
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
Hi Henrique, On Mon, 24 Jan 2011, Henrique de Moraes Holschuh wrote: > No. When we backport something, we are perfectly capable of backporting > dpkg-dev first. > Crap happens when you need backported debhelper, should whomever did that > backport have neglected to _change_ debhelper to do whatever is really > needed in the older distro. > This is not the sort of problem that backported dpkg-dev would ever cause. probably you are right... but we do not know for sure. dpkg-dev is the core component, and went from 1.14. series to 1.15 from lenny to squeeze... noone backported it, nor gettext (its build-dependency) so we do not know for sure if backported version could not lead to some interesting side-effects. thus I thought that making few leaf packages friendlier to older versions of dpkg-dev would be easier, than taking care about correct backporting of the core components > Most of the time, all we backport-lovers really need is complete (and > properly versioned) build dependencies. It _does_ help if you stick > to debhelper and ucf functionality available on stable for packages > that are extremely likely to be backported, though. well -- I can only agree with that ;-) -- =--= 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/20110124173911.gp8...@onerussian.com
Bug#610980: ITP: opus-codec -- A standard track, low-latency audio codec
Package: wnpp Severity: wishlist Owner: Ron * Package name: opus-codec Version : 0.1 Upstream Author : xiph.org and others * URL : http://www.xiph.org/ * License : 2-clause BSD Programming Lang: C Description : A standard track, low-latency audio codec The Opus codec is the next evolution of CELT, currently being developed by an IETF working group. It is anticipated that this will replace CELT when that work is complete. For various reasons this package won't be uploaded just yet, but I'm filing the ITP now to assure everyone that it will be, as soon as that is actually possible to do. The future of the existing celt package will be assessed when that happens (but there will be a transition period for existing apps which depend on it whichever way that goes). Cheers, Ron -- 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/20110124160245.7822.47895.report...@audi.shelbyville.oz
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On Mon, 24 Jan 2011, Yaroslav Halchenko wrote: > Alternatively, version of dpkg could be lowered and functionality > conditioned on the version of dpkg (thus implementing necessary logic to > support older versions), it would imho be better and more flexible to > please those backport-lovers, saving them and you time going > patching/branching things around. No. When we backport something, we are perfectly capable of backporting dpkg-dev first. Crap happens when you need backported debhelper, should whomever did that backport have neglected to _change_ debhelper to do whatever is really needed in the older distro. This is not the sort of problem that backported dpkg-dev would ever cause. Most of the time, all we backport-lovers really need is complete (and properly versioned) build dependencies. It _does_ help if you stick to debhelper and ucf functionality available on stable for packages that are extremely likely to be backported, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124162454.ge6...@khazad-dum.debian.net
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On Mon, 24 Jan 2011, Christian Kastner wrote:
> >> One simple way to resolve this would be to rename the .symbols file
> >> during build and again during clean (or similar approaches); I was
> >> wondering though if anybody had a better approach to recommend?
> > I'd say you need a versioned build dependency on dpkg-dev. This would
> > document that you use that feature, and that backporters need to use a
> > modern dpkg. This is no different from any other build depends you have.
> Indeed -- the lack of a versioned B-D and the consequences were just
> pointed out to me in private communication. Seems obvious, don't know
> why it eluded me.
Yeap -- if the functionality is unconditional -- there must have been
versioning of build-depends on dpkg.
Alternatively, version of dpkg could be lowered and functionality
conditioned on the version of dpkg (thus implementing necessary logic to
support older versions), it would imho be better and more flexible to
please those backport-lovers, saving them and you time going
patching/branching things around.
I guess the best/easiest way to obtain version of dpkg is:
perl -MDpkg -e 'print ${Dpkg::version};'
?
--
=--=
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/20110124161618.go8...@onerussian.com
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On 01/24/2011 04:32 PM, Adam Borowski wrote: > On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote: >> Hello, >> >> it was recently pointed out to me that one of my library packages >> encountered a build error whilst attempting to backport it to an older >> system. >> >> The build failed because I use symbol patterns, specifically c++ tags, >> in the package's .symbols file. This feature was introduced in dpkg-1.15.6. >> >> One simple way to resolve this would be to rename the .symbols file >> during build and again during clean (or similar approaches); I was >> wondering though if anybody had a better approach to recommend? > > I'd say you need a versioned build dependency on dpkg-dev. This would > document that you use that feature, and that backporters need to use a > modern dpkg. This is no different from any other build depends you have. Indeed -- the lack of a versioned B-D and the consequences were just pointed out to me in private communication. Seems obvious, don't know why it eluded me. Thanks, Christian signature.asc Description: OpenPGP digital signature
Re: Does it matter that the squeeze installer...
Please do manually run os-prober (as root) on your system and report the output as a bug against os-prober if it still says Vista. Did you upgrade from Vista to Windows 7 or was it a clean install? - Fabian -- 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/4d3d989e.7070...@greffrath.com
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote: > Hello, > > it was recently pointed out to me that one of my library packages > encountered a build error whilst attempting to backport it to an older > system. > > The build failed because I use symbol patterns, specifically c++ tags, > in the package's .symbols file. This feature was introduced in dpkg-1.15.6. > > One simple way to resolve this would be to rename the .symbols file > during build and again during clean (or similar approaches); I was > wondering though if anybody had a better approach to recommend? I'd say you need a versioned build dependency on dpkg-dev. This would document that you use that feature, and that backporters need to use a modern dpkg. This is no different from any other build depends you have. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110124153217.ga10...@angband.pl
Re: Does it matter that the squeeze installer...
On Mon, Jan 24, 2011 at 03:11:47PM +, David Goodenough wrote: > On Monday 24 January 2011, Andrey Rahmatullin wrote: > > On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote: > > > thinks that Window 7 is Windows Vista. I am installing an amd64 machine > > > which already has the 64 bit version of Windows 7 Professional on it, and > > > when I came to install Debian using the squeeze installer RC2 in the grub > > > bit it said that it had detected Windows Vista loader. I am not sure > > > this matters, but it might confuse the novice. If they are the same > > > then it should say Windows Vista or 7 loader. > > > > They are not the same and here os-prober successfully detected Win7 as > > "Windows 7 (loader) (on /dev/sdb1)". > Well that is odd, because it is definitely Windows 7, but the Grub installer > said it was Vista and but on looking closer at /boot/grub/grub.cfg it has > put Window 7 as the description. Very odd. Must just be in the installer > string that gets displayed when it asks if it has detected all the OSs. Please file a bug about this, if there is none already. Thanks, Michael -- 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/20110124152726.ga13...@nighthawk.chemicalconnection.dyndns.org
Re: Does it matter that the squeeze installer...
On Monday 24 January 2011, Andrey Rahmatullin wrote: > On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote: > > thinks that Window 7 is Windows Vista. I am installing an amd64 machine > > which already has the 64 bit version of Windows 7 Professional on it, and > > when I came to install Debian using the squeeze installer RC2 in the grub > > bit it said that it had detected Windows Vista loader. I am not sure > > this matters, but it might confuse the novice. If they are the same > > then it should say Windows Vista or 7 loader. > > They are not the same and here os-prober successfully detected Win7 as > "Windows 7 (loader) (on /dev/sdb1)". Well that is odd, because it is definitely Windows 7, but the Grub installer said it was Vista and but on looking closer at /boot/grub/grub.cfg it has put Window 7 as the description. Very odd. Must just be in the installer string that gets displayed when it asks if it has detected all the OSs. David -- 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/201101241511.48029.david.goodeno...@btconnect.com
Re: Does it matter that the squeeze installer...
On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote: > thinks that Window 7 is Windows Vista. I am installing an amd64 machine > which already has the 64 bit version of Windows 7 Professional on it, and > when I came to install Debian using the squeeze installer RC2 in the grub > bit it said that it had detected Windows Vista loader. I am not sure this > matters, but it might confuse the novice. If they are the same then it > should say Windows Vista or 7 loader. They are not the same and here os-prober successfully detected Win7 as "Windows 7 (loader) (on /dev/sdb1)". -- WBR, wRAR signature.asc Description: Digital signature
Does it matter that the squeeze installer...
thinks that Window 7 is Windows Vista. I am installing an amd64 machine which already has the 64 bit version of Windows 7 Professional on it, and when I came to install Debian using the squeeze installer RC2 in the grub bit it said that it had detected Windows Vista loader. I am not sure this matters, but it might confuse the novice. If they are the same then it should say Windows Vista or 7 loader. David -- 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/201101241428.28211.david.goodeno...@btconnect.com
symbol patterns in .symbols files prior to dpkg-1.15.6
Hello, it was recently pointed out to me that one of my library packages encountered a build error whilst attempting to backport it to an older system. The build failed because I use symbol patterns, specifically c++ tags, in the package's .symbols file. This feature was introduced in dpkg-1.15.6. One simple way to resolve this would be to rename the .symbols file during build and again during clean (or similar approaches); I was wondering though if anybody had a better approach to recommend? Christian signature.asc Description: OpenPGP digital signature
Re: Bits from the Security Team (for those that care about bits)
On 24/01/11 02:52, Paul Wise wrote: * README.test An alternative is to just provide *-test Debian packages. If the package exists then building it is the same as running a test of the packages it requires to be installed - maybe just the "*" package, but it could also be an integration test. I've got some packages in SourceForge that allow you to - build from GIT version control - install to a sandbox - do a "make distcheck" and build the Debian package from the tar ball. - check a particular branch with "make git branch=X check" The build goodies are in the v3c project http://www.sourceforge.net/projects/v3c All the other projects inherit these features from v3c. I hope this gives you some food for thought. Philip
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 07:48:18AM +0100, Iustin Pop wrote: > 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? ;-) True. However, we are trying to think this somewhat trough so we have a better picture what will be typical use cases for testing within Debian. One thing we need to deal with in our field are tests that require substantial amounts of additional data (not part of any package right now) and sometimes also the test suite is not part of a source package, but shipped separately (due to size, ...). > 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. Yes, that was the idea. > 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 All these are just meant to be things to consider while planning. I personally don't believe it is possible to give an accurate 'in-advance' estimate of test-runtime (given the large variety in performance). However, it might still be valuable to indicate whether a test is relatively resource hungry. Maybe it turns out that anything but a tag 'slow' is impossible to achieve. But we also thought about a Debian-dashboard for test results. That could gather information about the typical resource demands (per architecture) and give more accurate estimates. > - 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 True. Although not being able to be smart in some cases doesn't imply that we don't try to be clever when we can. We want to aim for a system that has a very low entry threshold. In the simplest case the package maintainer only places a symlink/script/binary with the package name implementing the test suite into a certain directory. When called and exiting normally the test will count is passed or failed otherwise. the "structured" output in this case is stderr and stdout. However, there are subsystems of Debian with more standardized approaches to testing (e.g. Python). DebTest should have the ability to add plugins for specific test environments to allow people to make it more clever. We only need to make sure that more structured information about test results have a place to go to and being handled in this framework. 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/20110124133435.GA12160@meiner
autopkgtest (was Re: Bits from the Security Team (for those that care about bits)
Hi, On Montag, 24. Januar 2011, 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. Package: autopkgtest Description: automatic as-installed testing for Debian packages autopkgtest runs tests on binary packages. The tests are run on the package as installed on a testbed system (which may be found via a virtualisation or containment system). The tests are expected to be supplied in the corresponding Debian source package. . See adt-run(1) and /usr/share/doc/autopkgtest. Use of adt-virt-xenlvm requires the autopkgtest-xenlvm package too; Use of the pre-cooked adt-testreport-onepackage script requires curl. I'm happy that you like piuparts, but it's not the best tool for everything :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
