Re: dealing with non-standard upstream packaging?
On Mon, Mar 07, 2005 at 01:53:55PM +0800, pabs wrote:
Hi,
I was wondering if there is any info about best practice in the
situation where upstream source packaging doesn't use the standard
foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme?
I suppose repacking the tarball/etc before using dh_make is enough, but
is there a standard way to make this a bit more automated for new
upstream releases?
Here is my partial solution on how to do it automatically. You'll need
to build-depends on dpatch for that, and modify debian/rules
accordingly. Some packages use dpatch anyway. Note that this doesn't
solves the missing version of the foo directory. I guess that one would
have to tweak the dpkg-source command and do some shell trickery for
that. Alternatively some command line parameters should be supplied.
#! /bin/sh -e
## 01_testAndCreateOrigTarBall.dpatch
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: test and create the .orig.tar.gz. Note that the upstream source
## is distributed as a .zip file.
if [ $# -lt 1 ]; then
echo `basename $0`: script expects -patch|-unpatch as argument 2
exit 1
fi
[ -f debian/patches/00patch-opts ] . debian/patches/00patch-opts
patch_opts=${patch_opts:--f --no-backup-if-mismatch} ${2:+-d $2}
case $1 in
-patch) [ ! -f ../inadyn*.orig.tar.gz ]
[ -f ../inadyn.*.zip ]
fakeroot debian/rules cleancd ..
dpkg-source -b -su -W -Idebian inadyn inadyn
;;
-unpatch) ;;
*)
echo `basename $0`: script expects -patch|-unpatch as argument 2
exit 1;;
esac
exit 0
@DPATCH@
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
Le Lun 7 Mars 2005 06:53, pabs a écrit : Hi, I was wondering if there is any info about best practice in the situation where upstream source packaging doesn't use the standard foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme? I suppose repacking the tarball/etc before using dh_make is enough, but is there a standard way to make this a bit more automated for new upstream releases? Another, question: why do some orig.tar.gz files contain a tarball that looks to be the upstream source, instead of being a copy of the upstream source? gaim for example. you may want to use cdbs (tarball.mk) that may offer all the kind of things you want. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpZR847Y2VHK.pgp Description: PGP signature
Re: dealing with non-standard upstream packaging?
pabs wrote: I was wondering if there is any info about best practice in the situation where upstream source packaging doesn't use the standard foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme? I thought that dpkg-source took care of renaming the directory that the upstream tarball produced? Certainly it's always done that for me. Just make sure that you rename the directory and the tarball before you run debuild (or similar) to generate the source package, and it should Just Work. Cameron. signature.asc Description: Digital signature
My first package/Mutt patch
Hi, my first Debian package works fine. Yet I have two questions as I'm still far away from being perfect. 1. I made my own Mutt patch. dpkg -p mutt says Version: 1.5.6-20050305+bs.1 But when I hit V in mutt, I see Mutt 1.5.6+20040907i (CVS) Where do I have to change the sources? I can't find it. 2. I installed the Debian files to `/home/ftp/pub/debian-private/pool/...'. Putting an FTP entry into `sources.list' and installing with `apt-get upgrade' leads to the above result. But when I write deb http://localhost/mydebian woody bs `apt-get update' encounters Err http://localhost woody/bs Packages 404 Not Found Ign http://localhost woody/bs Release ... Failed to fetch http://localhost/mydebian/dists/woody/bs/binary-i386/Packages 404 Not Found Fetching the `Packages' file with `wget' works without complain. What's going on here? Thank you very much in advance, at least for reading so far. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: My first package/Mutt patch
Hi Bertram, 1. I made my own Mutt patch. dpkg -p mutt says Version: 1.5.6-20050305+bs.1 But when I hit V in mutt, I see Mutt 1.5.6+20040907i (CVS) Where do I have to change the sources? I can't find it. Did you use dch command? debian/changelog debian/control 2. I installed the Debian files to `/home/ftp/pub/debian-private/pool/...'. Putting an FTP entry into `sources.list' and installing with `apt-get upgrade' leads to the above result. But when I write deb http://localhost/mydebian woody bs `apt-get update' encounters Err http://localhost woody/bs Packages 404 Not Found Ign http://localhost woody/bs Release ... Failed to fetch http://localhost/mydebian/dists/woody/bs/binary-i386/Packages 404 Not Found http://www.tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/ Very interesting howto, enjoy it! Regards SteX -- GPG Key = D52DF829 -- Stex-- [EMAIL PROTECTED] Keyserver http://keyserver.kjsl.com Registered user #324592 on the Linux Counter, http://counter.li.org
Re: dealing with non-standard upstream packaging?
Hi. I was wondering if there is any info about best practice in the situation where upstream source packaging doesn't use the standard foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme? Talk to the upstream packager and kindly ask about changing it. I suppose repacking the tarball/etc before using dh_make is enough, but is there a standard way to make this a bit more automated for new upstream releases? Assuming that upstream has the stuff in some directory, I don't think that this is necessary nor that you should do that, as meddeling with orig.tart.gz is generally frowned upon. The dpkg tools (dpkg-source, dpkg-buildpackage, uupdate) are pretty smart about that. Not sure about dh_make, but that should easily be worked around. For new upstream releases, use uupdate and you'll never notice upstreams directory notation. Another, question: why do some orig.tar.gz files contain a tarball that looks to be the upstream source, instead of being a copy of the upstream source? gaim for example. Different philosophy of packaging. This is especially useful if the upstream source consists of several parts. Kind regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fetch souce packages
On Mon, 2005-03-07 at 12:31 +1100, Matthew Palmer wrote: may be that you don't have any applicable apt-src lines in your sources.list. here is the content of my sparc sources.list: deb http://ftp.fr.debian.org/debian/ testing main deb-src http://ftp.fr.debian.org/debian/ testing main deb http://non-us.debian.org/debian-non-US testing/non-US main deb-src http://non-us.debian.org/debian-non-US testing/non-US main that's all? is it wrong ? -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours (France). Tél : 02 34 08 26 04 / 06 33 26 13 14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fetch souce packages
Rakotomandimby (R12y) Mihamina wrote: If I just try to fetch the source package with 'apt-get source package_name' from the sparc it doesn't work, because the package is not available for sparc. Which package is it? If the binary packages aren't available, you'll have to specify the name of the source package, which is often but not always the same as the name of the binary package. Cameron signature.asc Description: Digital signature
Re: fetch souce packages
Rakotomandimby (R12y) Mihamina [EMAIL PROTECTED] writes: On Mon, 2005-03-07 at 12:31 +1100, Matthew Palmer wrote: may be that you don't have any applicable apt-src lines in your sources.list. here is the content of my sparc sources.list: deb http://ftp.fr.debian.org/debian/ testing main deb-src http://ftp.fr.debian.org/debian/ testing main deb http://non-us.debian.org/debian-non-US testing/non-US main deb-src http://non-us.debian.org/debian-non-US testing/non-US main that's all? is it wrong ? Non-US main is obsolete. Any remnants are either also in main, merged into main packages or scheduled for removal. But that shouldn't harm. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
Hi, Thomas Viehmann wrote: I was wondering if there is any info about best practice in the situation where upstream source packaging doesn't use the standard foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme? Talk to the upstream packager and kindly ask about changing it. This I have done. They say they will look at doing it for the version after next. I suppose repacking the tarball/etc before using dh_make is enough, but is there a standard way to make this a bit more automated for new upstream releases? Assuming that upstream has the stuff in some directory, I don't think that this is necessary nor that you should do that, as meddeling with orig.tart.gz is generally frowned upon. The dpkg tools (dpkg-source, dpkg-buildpackage, uupdate) are pretty smart about that. Not sure about dh_make, but that should easily be worked around. For new upstream releases, use uupdate and you'll never notice upstreams directory notation. Ok, I guess I am missing what to read, the situation is this: I wanted to package nsis (http://nsis.sf.net) for debian since I need it for a project I wrote (chmdeco). The current upstream tarball is named nsis205.tar.bz2 (version is 2.05) and it contains a directory named NSIS, which contains the source etc. Referring to the maint-guide package, I unpacked the tar.bz2 and ran dh_make, giving this: The directory name must be package-version for dh_make to work! I cannot understand the directory name or you have an invalid directory name! I assume that I should not use dh_make do do the initial debianisation in this case? In that case, what would be the best way to create the orig.tar.gz? Or should I use the cdbs tarball.mk system? Another, question: why do some orig.tar.gz files contain a tarball that looks to be the upstream source, instead of being a copy of the upstream source? gaim for example. Different philosophy of packaging. This is especially useful if the upstream source consists of several parts. I note that this style of packaging is mentioned in the cdbs documentation, but there is no mention of why to use it. Has this been discussed somewhere before? Either way, I'll probably submit a patch summarising that discussion and peoples comments in this thread. Thanks for the info everyone. -- bye, pabs signature.asc Description: This is a digitally signed message part
Re: My first package/Mutt patch
On Mon, Mar 07, 2005 at 10:09:10AM +0100, SteX wrote: Hi Bertram, 1. I made my own Mutt patch. dpkg -p mutt says Version: 1.5.6-20050305+bs.1 But when I hit V in mutt, I see Mutt 1.5.6+20040907i (CVS) Where do I have to change the sources? I can't find it. Did you use dch command? debian/changelog debian/control Yes, dch will effect debian/changelog. Original poster did change the debian/changelog, that is why dpkg -p produces foobar+bs.1 Where do I have to change the sources? I can't find it. Search in .orig.tar.gz, not in the debian directory. 2. I installed the Debian files to snip/ other E-mail Cheers Geert Stappers signature.asc Description: Digital signature
Re: My first package/Mutt patch
On Mon, Mar 07, 2005 at 10:09:10AM +0100, SteX wrote: Hi Bertram, 1. I made my own Mutt patch. dpkg -p mutt says snip/ In another E-mail more information about that. Please rise _one_ topic in E-mail. 2. I installed the Debian files to `/home/ftp/pub/debian-private/pool/...'. Putting an FTP entry into `sources.list' and installing with `apt-get upgrade' leads to the above result. But when I write deb http://localhost/mydebian woody bs `apt-get update' encounters Err http://localhost woody/bs Packages 404 Not Found Ign http://localhost woody/bs Release ... Failed to fetch http://localhost/mydebian/dists/woody/bs/binary-i386/Packages 404 Not Found http://www.tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/ Summary: This mini-HOWTO shows how to build a minimal Debian .deb package. Very interesting howto, enjoy it! The original poster has a .deb package. The question is about how to setup an apt archive. Those who have an URL for that topic, _please_ change the Subject: line. Cheers Geert Stappers signature.asc Description: Digital signature
Re: My first package/Mutt patch
* Bertram Scharpf [Mon, 07 Mar 2005 09:38:06 +0100]: Where do I have to change the sources? I can't find it. debian/patches/000_VERSION -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The problem I have with making an intelligent statement is that some people then think that it's not an isolated occurrance. -- Simon Travaglia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fetch souce packages
On Mon, Mar 07, 2005 at 05:19:59PM +0800, Cameron Patrick wrote: Rakotomandimby (R12y) Mihamina wrote: If I just try to fetch the source package with 'apt-get source package_name' from the sparc it doesn't work, because the package is not available for sparc. Which package is it? If the binary packages aren't available, you'll have to specify the name of the source package, which is often but not always the same as the name of the binary package. Indeed, stating the package name would allow others to reproduce the expriment. Cheers Geert Stappers signature.asc Description: Digital signature
Re: fetch souce packages
On Mon, 2005-03-07 at 11:56 +0100, Geert Stappers wrote: stating the package name would allow others to reproduce the expriment No worth. I'm dumb-ass. The packages I wanted to fetch are: - qmailadmin (wich is not a 'main' nor 'free') - mldonkey (wich is at unstable) so I need to use a more complicated source.list first to grab thesources of those packages. -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours (France). Tél : 02 34 08 26 04 / 06 33 26 13 14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My first package/Mutt patch
Hi, Am Montag, 07. Mär 2005, 11:45:05 +0100 schrieb Adeodato Simó: * Bertram Scharpf [Mon, 07 Mar 2005 09:38:06 +0100]: Where do I have to change the sources? I can't find it. debian/patches/000_VERSION Thanks. I was confused about the letter i in the middle. As far as I understand, `debian/patches' are applied _after_ the `./configure' call. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fetch souce packages
On Mon, Mar 07, 2005 at 03:20:43AM +0100, Goswin von Brederlow wrote: Rakotomandimby (R12y) Mihamina [EMAIL PROTECTED] writes: Hello, I have a sparc box I want to recompile some packages only available for x86 to make packages for sparc. If I just try to fetch the source package with 'apt-get source package_name' from the sparc it doesn't work, because the package is not available for sparc. Is the only solution to go to packages.debian.org and manually fetch the sources for x86? Use the source name, even though I think it should even work with the binary name. Binary names only work if there is a binary package available (Because only then apt can lookup which source package it needs in its package lists).. Source names obviously always work if you have src entries :) What makes me wonder more is what package is usefull on sparc, but not available as a binary package for it.. Sjoerd -- If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My first package/Mutt patch
* Bertram Scharpf [Mon, 07 Mar 2005 13:50:37 +0100]: As far as I understand, `debian/patches' are applied _after_ the `./configure' call. No. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apt-get: ftp vs. http (was: My first package/Mutt patch)
Hi, Am Montag, 07. Mär 2005, 11:39:41 +0100 schrieb Geert Stappers: Please rise _one_ topic in E-mail. Sorry! That was no good idea. 2. I installed the Debian files to `/home/ftp/pub/debian-private/pool/...'. Putting an FTP entry into `sources.list' and installing with `apt-get upgrade' leads to the above result. But when I write deb http://localhost/mydebian woody bs `apt-get update' encounters Err http://localhost woody/bs Packages 404 Not Found Ign http://localhost woody/bs Release ... Failed to fetch http://localhost/mydebian/dists/woody/bs/binary-i386/Packages 404 Not Found [some RTFM] Summary: This mini-HOWTO shows how to build a minimal Debian .deb package. The original poster has a .deb package. The question is about how to setup an apt archive. Thank you very much. Those who have an URL for that topic, _please_ change the Subject: line. The `http' method seems to need a gzipped file `Packages.gz'; the `ftp' method can be satisfied with a plain one. Not very nice. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
On Mon, Mar 07, 2005 at 01:53:55PM +0800, pabs wrote: Hi, I was wondering if there is any info about best practice in the situation where upstream source packaging doesn't use the standard foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme? I suppose repacking the tarball/etc before using dh_make is enough, but is there a standard way to make this a bit more automated for new upstream releases? Another, question: why do some orig.tar.gz files contain a tarball that looks to be the upstream source, instead of being a copy of the upstream source? gaim for example. Provide debian/rules:get_orig_source which downloads the upstream tarball, as recommended [0]. The debian tools (dpkg-source, I guess) can deal with almost all upstream tarballs. Even if they extract to the current directory, or if they extract to a directory not called name-version. If you have to repackage it, (FE for DFSG compliance), then you should create the tarball name_version.orig.tar.gz which extracts to the directory name-version.orig/ (such as to implicitly identify it as a nonpristine tarball). get_orig_source should do this, too. Justin References [0] http://www.nl.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
Hi. pabs ([EMAIL PROTECTED]) wrote: Talk to the upstream packager and kindly ask about changing it. This I have done. They say they will look at doing it for the version after next. Excellent. Ok, I guess I am missing what to read, the situation is this: I wanted to package nsis (http://nsis.sf.net) for debian since I need it for a project I wrote (chmdeco). The current upstream tarball is named nsis205.tar.bz2 (version is 2.05) and it contains a directory named NSIS, which contains the source etc. Referring to the maint-guide package, I unpacked the tar.bz2 and ran dh_make, giving this: The directory name must be package-version for dh_make to work! I cannot understand the directory name or you have an invalid directory name! Do the following: bunzip the thing, gzip it and use dh_make with -f. I assume that I should not use dh_make do do the initial debianisation in this case? In that case, what would be the best way to create the orig.tar.gz? Or should I use the cdbs tarball.mk system? This is entirely your choice, largely independent of (but with consequences for) the initial packaging question. You can always just rename your gzipped tarball to appropriate.orig.tar.gz and populate your debian dir by hand if you want to skip dh_make. Kind regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
On Mon, Mar 07, 2005 at 02:03:48PM +, Thomas Viehmann wrote: Justin Pryzby ([EMAIL PROTECTED]) wrote: If you have to repackage it, (FE for DFSG compliance), then you should create the tarball name_version.orig.tar.gz which extracts to the directory name-version.orig/ (such as to implicitly identify it as a nonpristine tarball). get_orig_source should do this, too. Hm. I always thought that just deleting files from the tar (without extracting and repackaging) was the preferred suite of action. The marking seems to be done with version suffixes (such as the ds). The property of using a pristine .orig is very high precedence, but not as high as being free. The .orig should be compatible with the DFSG, even at the cost of using a nonpristine one. How do you delete files from a .tar without repackaging? Do you mean 1) extract the tar; 2) delete the files; 3) recreate a tar of the same name? Or do you mean simply not including those files in the binary package? The .dsfg marking is used in the version number of binary packages, I know, but nowhere in the source ones. (Which is implied, actually, by the requirement that source packages, even if repackaged, contain no files added or modified by Debian). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dealing with non-standard upstream packaging?
Hi. Justin Pryzby ([EMAIL PROTECTED]) wrote: How do you delete files from a .tar without repackaging? Easy: tar --delete on the orig.tar.gz. You have to gunzip and gzip the tar.gz (IIRC), but there is no need to extract the tar archive. Do you mean 1) extract the tar; 2) delete the files; 3) recreate a tar of the same name? Or do you mean simply not including those files in the binary package? Neither. Why would I? Regards T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fetch souce packages
On Mon, 2005-03-07 at 10:42 +0100, Sjoerd Simons wrote: What makes me wonder more is what package is usefull on sparc, but not available as a binary package for it.. The mldonkey one. Just the GUI for controlling the remote server. I have one server, an x86, far from home (in a datacenter). Home, I have two sparcs. I want to control the running mldonkey server with the sparc. The GUI (mlgui) is bundled with the same package as the server, so that I must install them. The problem is my sparcs are testing . The mldonkey package has been kicked from testing it's now at unstable. The mldonkey program is written in caml, and I need to build several libs related to Caml and Caml/GTK... -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours (France). Tél : 02 34 08 26 04 / 06 33 26 13 14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: setserial - Controls configuration of serial ports
Hi, I would like to takeover the maintanence of setserial package since it's current maintainer if looking for a replacement. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285355 However I'm not a DD so I would need a sponsor. Would there be anyone willing to help me? Regards Ziza - Forwarded message from Ola Lundqvist - Hello On Sun, Mar 06, 2005 at 06:50:11PM +0200, Jan Zizka wrote: Hi Ola, I have seen that you are looking for someone to take over the setserial Debian package. I'm Debian user for years and I would like to give something back. I use serial ports rather often, thow I don't have any special HW. I did not maintain any Debian package before, but as I checked this one is not very complex so it could be nice to start with it. This sounds really nice. Please go ahead. Some things though. Are you a debian developer? Or can you get someone else to sponsor you? Regards, // Ola Cheers Ziza - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS Gpiv c.s.
I am searching for a sponsor to assist me with the building of the GPL-licensed software packages Gpiv c.s. I am writing and would like to see included in Debian. Summary --- This software provides the analyzing of images for PIV. Software for this (research and production) technology is not included in any Linux distro. The features, quality and performances of Gpiv s.s. are very competitive compared to other existing, Open Source, free-ware and commercial software for PIV. The popularity of this technique is still increasing, but initial costs are high because of hard and software to be needed. Experienced users are often searching for alternatives of their commercial program after some time as it becomes obsolete for the analysing of the images. Therefore, it might be advantageous to include Gpiv c.s. in Debian. Description --- Gpiv c.s. concerns software for the so-called (Digital) Particle Image Velocimetry technique (PIV); an image recording and analyzing technology to obtain a velocity field from a fluid flow that has been seeded with small tracer particles or smoke. Though, it also might be applied for transportation and deformation analyses of (solid) surfaces. It correlates small samples (interrogation area's) at identic location of two images (an image pair) and correlates them (by using FFT techniques) in order to estimate the local displacement. The software has been written entirely in ANSI-C and some (example) Perl-scripts are included in Gpivtools. The code has been published under the GNU General Public License and only uses libraries that are under this or other Open Source license and are resident in main chapter of the Debian distribution. Gpiv c.s. contain four different packages: 1) LIBGPIV: Library for Particle Image Velocimetry (PIV) This library contains functions for recording and interrogating images from a fluid flow by means of Particle Image Velocimetry (PIV), resulting into a velocity field of the fluid flow. It includes the core functions for recording, interrogation, data validation, post-processing, input/output and other utility functions. 2) GPIVTOOLS: Command line programs for Particle Image Velocimetry A collection of programs for recording and interrogating images that are generated during a Particle Image Velocimetry (PIV) experiment. This is a technique to obtain the velocity field of a fluid flow quantitatively and is performed by tracking tracer particles that have been seeded to a fluid. The technique is also applied for observing deformations at surfaces of (solid) bodies. The package contains: . an image recording program that uses an IEEE1394 (Firewire) IIDC-compliant camera and a program for triggering the camera with a light source (mostly a double cavity Nd-YAG laser). Trigger pulses are sent over the parallel port of the computer using RealTimeLinux and RTAI. . an image processing program for typical filtering and manipulation routines that may be convenient for PIV. . an image interrogation program resulting into estimators of particle image displacements. . validation programs to test on outliers, peak-locking effect and velocity gradients. . post-processing programs for data manipulation (flipping, rotation etc), spatial and time scaling, calculation of spatial averages and derivatived quantities from the PIV data, like vorticity and strain. . miscellaneous programs and scripts to perform image format conversion, batch-processing, pipeline processing (image evaluation, validation and post-processing at once), calculation of time averages from a series of PIV data sets, data-visualization and data-manipulation. 3) GPIV: Graphic User Interface program for Particle Image Velocimetry Gpiv is a Graphic User Interface program using the GTK/GNOME libraries for Particle Image Velocimetry (PIV). This is a technique to obtain the velocity field of a fluid flow quantitatively and is performed by tracking tracer particles that have been seeded to a fluid. The technique is also applied for observing deformations at surfaces of (solid) bodies. The program gives a quick overview of the parameter settings of the processes and allows to change them easily, running the processes, individually or all at once, visualizes and displays the results. The processes that may be invoked by Gpiv are: . Image recording with an IEEE1394 (Firewire) IIDC-compliant camera. This includes the triggering of the camera with the lasers by means of RealTimeLinux and RTAI. Trigger pulses are sent over the parallel port of the computer. . Image interrogation, resulting into estimators of particle image displacements. . Data validation to test on outliers, peak-locking effect and velocity gradients over the interrogation area's. . Data post-processing: data manipulation,spatial and time scaling to obtain a velocity field from the PIV data, calculation of spatial averages, vorticity and strain. The
Re: RFS: setserial - Controls configuration of serial ports
Hi, On Mon, Mar 07, 2005 at 07:43:06PM +0100, Bartosz Fenski aka fEnIo wrote: On Mon, Mar 07, 2005 at 07:03:59PM +0200, Jan Zizka wrote: I would like to takeover the maintanence of setserial package since it's current maintainer if looking for a replacement. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285355 However I'm not a DD so I would need a sponsor. Would there be anyone willing to help me? Request for sponsor for some package should contain: 1) description of package I thought that this is already debian package that I don't have to repeat the same info, but here is link with description: http://packages.debian.org/stable/base/setserial 2) url to prepared package non except official ones done by current maintainer. http://packages.qa.debian.org/s/setserial.html and when it's adoption would be great to see 3) changelog, preferably with some fixes for outstanding bugs there are no outstanding bugs reported so there is nothing to fix at the moment. Does this mean that we, me and current maintainer, should wait for some outstadnig bug before he could hand the package to me? Or what should be the procedure? Cheers Ziza signature.asc Description: Digital signature
Re: My first package/Mutt patch
Hello SteX, * SteX [EMAIL PROTECTED] [2005-03-07 14:19]: 1. I made my own Mutt patch. dpkg -p mutt says Version: 1.5.6-20050305+bs.1 But when I hit V in mutt, I see Mutt 1.5.6+20040907i (CVS) Where do I have to change the sources? I can't find it. Did you use dch command? This has nothing to do with the debian files. This is mutt interna. Grep the source for versions. [...] Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | mutt-ng.berlios.de | grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpOFsxE30OrX.pgp Description: PGP signature
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: setserial - Controls configuration of serial ports
On Mon, Mar 07, 2005 at 09:49:45PM +0200, Jan Zizka wrote: However I'm not a DD so I would need a sponsor. Would there be anyone willing to help me? Request for sponsor for some package should contain: 1) description of package I thought that this is already debian package that I don't have to repeat the same info, but here is link with description: http://packages.debian.org/stable/base/setserial Well you're looking for sponsor right? You should prepare request that will make it easier for eventual sponsors to get know as much as possible about package here. At least that's my opinion ;) 2) url to prepared package non except official ones done by current maintainer. http://packages.qa.debian.org/s/setserial.html Why? If you're going to adopt it then please use procedure for this. http://www.debian.org/devel/wnpp/ Hint: You should prepare package which will close RFA with changelog entry. and when it's adoption would be great to see 3) changelog, preferably with some fixes for outstanding bugs there are no outstanding bugs reported so there is nothing to fix at the moment. Does this mean that we, me and current maintainer, should wait for some outstadnig bug before he could hand the package to me? Or what should be the procedure? Procedure is mentioned at WNPP pages. And there is some bugreport against setserial. Wishlist with updated translation, but it's still bugreport ;) So the correct way of adopting would be to prepare new revision of package with fixed bug and changelog entry which will close RFA. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: RFS: setserial - Controls configuration of serial ports
Hi, On Mon, Mar 07, 2005 at 09:45:07PM +0100, Bartosz Fenski aka fEnIo wrote: 1) description of package I thought that this is already debian package that I don't have to repeat the same info, but here is link with description: http://packages.debian.org/stable/base/setserial Well you're looking for sponsor right? You should prepare request that will make it easier for eventual sponsors to get know as much as possible about package here. At least that's my opinion ;) Yes that correct. Thanks for the point, you are right. 2) url to prepared package non except official ones done by current maintainer. http://packages.qa.debian.org/s/setserial.html Why? If you're going to adopt it then please use procedure for this. http://www.debian.org/devel/wnpp/ Hint: You should prepare package which will close RFA with changelog entry. 3) changelog, preferably with some fixes for outstanding bugs there are no outstanding bugs reported so there is nothing to fix at the moment. Does this mean that we, me and current maintainer, should wait for some outstadnig bug before he could hand the package to me? Or what should be the procedure? Procedure is mentioned at WNPP pages. And there is some bugreport against setserial. Wishlist with updated translation, but it's still bugreport ;) Yes but that is already added in 2.17-40. So the correct way of adopting would be to prepare new revision of package with fixed bug and changelog entry which will close RFA. Yes but for this I would have to be already a DD. Since I'm not I'll have to find a sponsor first. But I'll try to seach if there is any other wish, which I could implement and make the package fist and come back with it :)) Thanks a lot for your insight! Cheers Ziza signature.asc Description: Digital signature
Re: dealing with non-standard upstream packaging?
On Mon, 2005-03-07 at 14:11 +, Thomas Viehmann wrote: The directory name must be package-version for dh_make to work! I cannot understand the directory name or you have an invalid directory name! Do the following: bunzip the thing, gzip it and use dh_make with -f. Hmm, this didn't help. I don't know perl very well, but looking at the dh_make perl source makes me think dh_make relies on the current directory being named package-version. So, I did the following: bunzip2 nsis205.tar.bz2 gzip nsis205.tar tar zxf nsis205.tar.gz mv NSIS nsis-2.05 cd nsis-2.05 dh_make -f ../nsis205.tar.gz This gave me nsis_2.05.orig.tar.gz (containing an NSIS dir), and debuild seems to behave normally (apart from upstream build errors), so I may send an RFS at some point. Does anyone think that it would be worth filing a wishlist bug on dh_make to allow it to work with any current directory (by providing a --upstream-version flag in addition to the --packagename)? Thanks for the advice everyone. -- bye, pabs signature.asc Description: This is a digitally signed message part
Re: RFS: setserial - Controls configuration of serial ports
Hello On Mon, Mar 07, 2005 at 11:09:34PM +0200, Jan Zizka wrote: *CUT* Yes but that is already added in 2.17-40. So the correct way of adopting would be to prepare new revision of package with fixed bug and changelog entry which will close RFA. Yes but for this I would have to be already a DD. Since I'm not I'll have No actually not. to find a sponsor first. But I'll try to seach if there is any other wish, which I could implement and make the package fist and come back with it :)) Thanks a lot for your insight! So prepare a package that close that bug at least. Regards, // Ola Cheers Ziza -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 654 65 KARLSTAD| | http://www.opal.dhs.org Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: setserial - Controls configuration of serial ports
On Mon, Mar 07, 2005 at 11:09:34PM +0200, Jan Zizka wrote: Procedure is mentioned at WNPP pages. And there is some bugreport against setserial. Wishlist with updated translation, but it's still bugreport ;) Yes but that is already added in 2.17-40. So I see no reason for keeping this bugreport open. It should be closed or at least tagged as sarge related. So the correct way of adopting would be to prepare new revision of package with fixed bug and changelog entry which will close RFA. Yes but for this I would have to be already a DD. Since I'm not I'll have to find a sponsor first. But I'll try to seach if there is any other wish, which I could implement and make the package fist and come back with it :)) No. It's not find sponsor and then work on package. It's actually inverse order. Noone will sponsor you or even promise sponsoring if you have nothing to show. You don't have to be DD for preparing new revision of package. Only uploading part needs DD access, and you should ask for sponsor having something to upload. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
