Re: RFS: nemesis (updated package)
* William Vera [EMAIL PROTECTED] [080911 21:28]: I am looking for a sponsor for the new version 1:1.4beta3-1 of my package nemesis. The history of versions is quite disturbing: 1.32+1.4beta3-1 1.32+1.4beta3-2 1:1.4-1 1:1.4beta3-1 Yes, because upstream's tarball, I used a epoch for update 1.32+1.4beta3-2 to 1.4-1 Some recomendation? I see two problems here: 1) the epoch for 1.4 Epochs often cause more problems than they solve, one should not use them too lightweight, as you will never be able to get rid of them again. That 1.4 is after 1.32 (and not 28 releases before) means that upstream seems to use some strange numbering sheme based on decimal fractions. There are good chances this will happen again in the future, so instead of using an epoch, normalizing that to usual natural numbers by making that a 1.40 could have expressed the situation more clearly (and avoid similar problems in the future). But alas, it is to late, the epoch is in the archive, it can never ever go away now... 2) 1.4beta3 coming after 1.4 That sounds strange. Usually beta releases come before the final release (to be expressed in Debian version numbers either by ~ or by the oldversion-newbeta trick), so having this after 1.4 looks very strange to me. If you take a look at the dates at the download site, you see that this feeling seems to be right: nemesis-1.4beta3.tar.gz 29-Oct-2003 19:12 nemesis-1.4beta3.zip07-Oct-2004 02:02 nemesis-1.4.tar.gz 07-Oct-2004 04:29 nemesis-1.4.zip 07-Oct-2004 04:47 nemesis-1.4.zip.asc 07-Oct-2004 04:47 nemesis-1.4.tar.gz.asc 07-Oct-2004 04:49 So your new version seems to actually be almost a year older than the previous one and is the version you just replaced in the previous entry. If you do not want uscan to tell you in error that there is an newer upstream version if there is none, just tell it to Debianize the versions there, by adding an opts=uversionmangle=s/beta/~beta/ i.e make debian/watch look like the following (two lines): version=3 opts=uversionmangle=s/beta/~beta/ http://sf.net/nemesis/nemesis-(.*)\.tar\.gz Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: tmux
Dear mentors, I am looking for a sponsor for my package tmux. * Package name: tmux Version : 0.4-1 Upstream Author : Nicholas Marriott [EMAIL PROTECTED] * URL : http://tmux.sourceforge.net/ * License : BSD-License (revised) Section : admin It builds these binary packages: tmux - terminal multiplexer like screen The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tmux - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tmux/tmux_0.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Karl Ferdinand Ebert 0x81FADDC39957DB904D2DCD6B76B22DF209DBFD9C.asc Description: application/pgp-keys signature.asc Description: This is a digitally signed message part.
pbuilder and debhelper: Test suite run before dependencies satisfied
Howdy mentors, Why does 'dh build' attempt to run the package's test suite, but doesn't satisfy the run-time dependencies before doing so? How can this be made to work within a pbuilder environment? I'm packaging a Python application that has a unit test suite. This unit test suite, naturally, imports each of the modules in the application in order to test them. That, in turn, causes any of the 'import bar' statements in the application to be executed. So, the unit test suite will fail in the absence of any one of the package's Python library dependencies. Yet, when I attempt to 'pdebuild' this package, it runs the 'build' target of 'debian/rules', which runs 'dh build', which runs 'dh_auto_test', which runs the application unit test suite. At this point in the process, though, the pbuilder environment does not have the package dependencies installed, so the unit test suite fails, failing the 'pdebuild'. Running 'debian/rules build' shouldn't need the package dependencies installed, because the package isn't being installed yet, only built into a Debian binary package. So why is the package unit test suite run from 'dh build'? Isn't this going to be a problem for every package that has a unit test suite? One possible response would be to list every run-time library dependency as a build dependency, but that seems ludicrous; those libraries aren't needed to build the package, they're only needed when running the application (whether under test or not). Another possibility would be to suppress the 'dh_auto_test', but I don't want to change the way debhelper operates without a very good reason. So far all I have is the fact that it's getting in my way, but that could well be my fault. How is this supposed to work? -- \“Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder and debhelper: Test suite run before dependencies satisfied
You can tell pbuilder to include extra packages in the environment by
setting the EXTRAPACKAGES variable. In my .pbuilderrc I have something like:
PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi
case $TEST in
ffmpeg) # For testing of WinFF
EXTRAPACKAGES=ffmpeg debfoster ${EXTRAPACKAGES}
*) # Fast testing
EXTRAPACKAGES=${EXTRAPACKAGES}
;;
esac
I am at this moment not sure if I needed the first line for this to
work, but now I can run pdebuild like so:
$ TEST=ffmpeg pdebuild
Paul
Ben Finney wrote:
Howdy mentors,
Why does 'dh build' attempt to run the package's test suite, but
doesn't satisfy the run-time dependencies before doing so? How can
this be made to work within a pbuilder environment?
I'm packaging a Python application that has a unit test suite. This
unit test suite, naturally, imports each of the modules in the
application in order to test them. That, in turn, causes any of the
'import bar' statements in the application to be executed. So, the
unit test suite will fail in the absence of any one of the package's
Python library dependencies.
Yet, when I attempt to 'pdebuild' this package, it runs the 'build'
target of 'debian/rules', which runs 'dh build', which runs
'dh_auto_test', which runs the application unit test suite. At this
point in the process, though, the pbuilder environment does not have
the package dependencies installed, so the unit test suite fails,
failing the 'pdebuild'.
Running 'debian/rules build' shouldn't need the package dependencies
installed, because the package isn't being installed yet, only built
into a Debian binary package. So why is the package unit test suite
run from 'dh build'? Isn't this going to be a problem for every
package that has a unit test suite?
One possible response would be to list every run-time library
dependency as a build dependency, but that seems ludicrous; those
libraries aren't needed to build the package, they're only needed when
running the application (whether under test or not).
Another possibility would be to suppress the 'dh_auto_test', but I
don't want to change the way debhelper operates without a very good
reason. So far all I have is the fact that it's getting in my way, but
that could well be my fault.
How is this supposed to work?
signature.asc
Description: OpenPGP digital signature
Re: pbuilder and debhelper: Test suite run before dependencies satisfied
Paul Gevers [EMAIL PROTECTED] writes: You can tell pbuilder to include extra packages in the environment by setting the EXTRAPACKAGES variable. That doesn't scale. I can't expect everyone who might be building this package (e.g. a sponsor, or the buildd hosts) to install packages without specification from the package configuration itself. I know I can hack around this; that's not what I'm seeking. I'm wondering why such hacking would be necessary, and suspecting that either my assumptions, or the assumptions of the build tools, or perhaps both, need readjusting. -- \“Absurdity, n. A statement or belief manifestly inconsistent | `\with one's own opinion.” —Ambrose Bierce, _The Devil's | _o__)Dictionary_, 1906 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder and debhelper: Test suite run before dependencies satisfied
Le 12 sept. 08 à 15:55, Ben Finney a écrit : Paul Gevers [EMAIL PROTECTED] writes: You can tell pbuilder to include extra packages in the environment by setting the EXTRAPACKAGES variable. That doesn't scale. I can't expect everyone who might be building this package (e.g. a sponsor, or the buildd hosts) to install packages without specification from the package configuration itself. I know I can hack around this; that's not what I'm seeking. I'm wondering why such hacking would be necessary, and suspecting that either my assumptions, or the assumptions of the build tools, or perhaps both, need readjusting. Hi, some consider it good behavior to run the test suites at build time, because it will help you detect bugs that happen on other architectures than your own. And you can only fix bugs that you have detected. This way you are certain that the packages you build are functional, to the extent tested by the test suite. However, AFAIK, policy does not mandate to do so (nor to use dh_build). Anyway, if you _choose_ to run the tests at build-time (or to use tools that run them), you _have to_ put all the test suite dependencies as build-dependencies. The build-dependencies will be satisfied at the right time in pbuilder. Regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: plait (updated package) - command-line jukebox
Dear mentors, I am looking for a sponsor for the new version 1.6.1-1 of my package plait. It builds these binary packages: plait - command-line jukebox The package appears to be lintian clean. The upload would fix these bugs: 498651 as well as bringing the package up to date with upstream. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/plait - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plait/plait_1.6.1-1.dsc I would be most appreciative if someone uploaded this package for me. Kind regards, Dave. -- David Symons Armidale NSW Australia http://www.liberatedcomputing.net signature.asc Description: This is a digitally signed message part
Re: RFS: wallpaper-tray (updated package)
OoO En cette nuit nuageuse du jeudi 21 août 2008, vers 01:10, Guido Loupias [EMAIL PROTECTED] disait : I am looking for a sponsor for the new version 0.5.5-1 of my package wallpaper-tray. Hi Guido! You switched to a patch management system. Good point. However, the patch is unreadable. I suppose that you needed to rerun autoconf stuff. In this case, just patch Makefile.am or configure.ac and depends on autotools to generate all this stuff. This way, you keep the patch to the minimal size. You should look at the list of the opened bugs for this package. Maybe this new upstream package fixes some of them. You should also close #326671. AUTHORS and MAINTAINERS do not contain any new information with respect to debian/copyright. I think that you can safely not ship them. You depend on debhelper 7 but do not use any feature of it. Stick to debhelper 5, this will ease the work of backporters. I am not sure, but since you ship a gconf schema, you need to register it. I think dh_gconf can do it. -- BOFH excuse #300: Digital Manipulator exceeding velocity parameters pgp7flB1mQSbQ.pgp Description: PGP signature
Re: [Done] Re: RFS: libdaemon (updated package) -- 3rd try
On 08/09/10 14:19 +0530, Kartik Mistry said ... On Wed, Sep 10, 2008 at 12:51 PM, Kartik Mistry [EMAIL PROTECTED] wrote: Original RFS: http://lists.debian.org/debian-mentors/2008/08/msg00321.html I will look and upload it by today. Uploaded. Thank you for the upload Kartik. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
