Re: Bug#321336: fixed bugs in new package
Warren Turkal wrote: I have completely reworked the packaging for the netcdf libraries into a modern cdbs based package. I consider cdbs as broken, rather than 'modern'. It also fixes the bugs that are receiving this report. I have the packages posted at [1]. Please look at them. I see there is an ITA that has had no activity since August. Any activity didn't look like it resulted in actual package uploads. In fact, the QA team currently maintains the package. I am interested in Adopting the package if anyone is interested in sponsoring. I have also sent this report to the ITA bug for this package. However, I'll sponsor your package. Will look at the packages in the afternoon. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best practice for packages using devhelp for their API documentation
Em Sat, 18 Nov 2006 14:12:24 -0800 Kevin B. McCarty [EMAIL PROTECTED] escreveu: So, I took (quite) a bit of time to answer, but that's because I mostly agree with the email. 5.) If there is a consensus on this matter, should this be documented somewhere (policy, dev-ref) and bugs be filed against the packages not complying to this policy? Maybe see what the Debian maintainer of devhelp thinks? Also, what does he think about the possibility of patching devhelp for Debian to look for docs in /usr/share/doc/package/html as well as in the default /usr/share/gtk-doc/html/package location? If that were done there would be no need for symlinks. So, I don't think the symlinks are harmful, and thus do not see a need for patching devhelp in this sense. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://www.debian.org/ | http://kov.eti.br/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Opinions on CDBS amongst sponsors
I'm quite a fan of CDBS and I'm currently writing handlers for
debian/rules to create cross-building packages for Emdebian [1]. I've
found CDBS somewhat easier to automate - mainly because hand-crafted
debian/rules files can be quite disorganised and hard to
interpret/patch. The basic task is to omit certain dh_install* helpers
to prevent the packaging of ChangeLog, debian/changelog, README, TODO
and all the other non-program text that is normally part of a Debian
package so that Emdebian can fit on a 20Mb device (like an iPAQ) whilst
using Debian packages. Some debian/rules files don't use the debhelper
routines, requiring hand-editing of debian/rules to 'emdebianise' the
package by omitting certain direct calls to ${INSTALL} etc.
My own packages [2] [3] are all CDBS and I have found no reasons not to
use it. I prefer to sponsor CDBS for these reasons but I've no
particular problem with not using it.
Yet some sponsors have made it clear that CDBS is not their preferred
method and are somewhat unwilling to sponsor CDBS.
I don't use automatic debian/control management and I personally
wouldn't recommend using that part of CDBS.
What are the problems with CDBS (apart from debian/control automation)?
Which kinds of packages have the most trouble with a CDBS method?
(There are CDBS classes for Perl, Gnome, Autotools and a few others)
[4].
[1] http://www.emdebian.org/
[2] http://qa.debian.org/[EMAIL PROTECTED]
[3] http://qa.debian.org/[EMAIL PROTECTED]
[4] http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpnGXsT8N9KS.pgp
Description: PGP signature
Re: RFS: knetstats
Daniel, Thanks for all your points. I've re-uploaded it and now there are no lintian warnings also. :-) Daniel Baumann wrote: Ritesh Raj Sarraf wrote: I've re-uploaded the package. Please have a look at it. * you should not bump the revision, -1 was not uploaded to debian. I've cleaned everything and re-uploaded it. Now it's revision is again -1. Probably when you push it further, it becomes -2. your package is a native package, don't do this. additionally, please fix the following things: I wasn't able to understand much about this issue (Maybe because I've not done much reading). you shall not include the debian/ directory in the upstream tarball (tar.gz), but have a orig.tar.gz and seperate diff.gz containing the debian/* files and every other modification you did. This is fixed. There are many packages which don't have a proper version format. How do the maintainers tackle such software ? i don't know what you mean with this. * this is ugly (in README.Debian): I didn't understand this much. ---snipp--- -- Ritesh Raj Sarraf [EMAIL PROTECTED], Sun, 12 Nov 2006 00:55:48 +0530 ---snapp-- and this is beautiful: ---snip--- -- Ritesh Raj Sarraf [EMAIL PROTECTED] Sun, 12 Nov 2006 00:55:48 +0530 ---snapp--- note that only the comma is different after your email address. FIXED nope, you removed the comma instead of replacing it with a space. This is fixed. * this is wrong: ---snipp--- Homepage: http://knetstats.sourceforge.net/ ---snapp--- and this is right: ---snipp--- Homepage: http://knetstats.sourceforge.net/ ---snapp--- note the *two* leading spaces. Not sure what it was. Maybe FIXED. nope, there is still only one leading space in bevore Homepage. This is fixed. * remove the useless commented things in debian/rules and debian/watch. FIXED nope. rules still contains a lot of commented, useless and not used dh_* calls. remove them. This is fixed. * your manpage does not get installed, you have to use debian/manpage for that (read man dh_installman) FIXED if you add a manpage, you should place it in the debian directory, not into the upstream sources. This is fixed. additonally: * you should build with DH_VERBOSE enabled by default. The rules file contains DH_VERBOSE=1 * i suggest to include a xpm file and add it to menu. knetstats has its own .png file which gets displayed in the menu. Do you think an xpm is still required ? Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. Stealing logic from one person is plagiarism, stealing from many is research. The great are those who achieve the impossible, the petty are those who cannot - rrs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
* Neil Williams ([EMAIL PROTECTED]) [061211 11:26]: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. I don't use automatic debian/control management and I personally wouldn't recommend using that part of CDBS. What are the problems with CDBS (apart from debian/control automation)? I need to reverse-engineer code every time I use it There was a good blog entry recently about automation: Good helpers make the tasks easier by reducing complexity. cdbs doesn't do that - it surely makes the task easier for people used to it, but for all others, it is a big black box adding complexity. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Hi Warren, Warren Turkal wrote: I have worked tonight to produce new netcdf packages for the NetCDF libraries. They are located at [1]. I would like some feedback on them. They are based on cdbs. [2] is a link to a WNPP bug about this package. I would like to adopt the package, if possible. i can not sponsor your upload because I am not a DD, but i may provide you some hints: * Remove all files from debian/ with .ex ending. They are example files and if you don't need them, then you should not include them. If you need them, then rename and edit them and whatever it needs to do further. * debian/rules * : Remove the unneeded extra line at EOF * : I don't know much about your package but is configure parameter --enable-64bit right? You will not build for 64bit systems only in debian imho * Personally i would use 'install -d' to create directories while building and get rid of those .dirs files which do contain standard directories only * debian/*.dirs: Seee above rules comment * debian/copyright: * According to debian policy 12.5 you *must* say where the upstream sources (if any) were obtained * You should name the original authors of the package and the Debian maintainer(s) who were involved with its creation * IMO you should mention the ones who previous did packaging * The lines at the end of the file seem to be unnecessary * debian/changelog: * Should contain changelog entries of previous debian versions * Must contain a notice that you are new maintainer Further notes: It sounds a bit strange that your package has a version -beta-pre. I'm not sure if you really want to package a pre-beta (what actually is an alpha version in my sense). Also i don't like cdbs much. IMO it makes packages / packages build process unclearly. Best Regards Patrick signature.asc Description: OpenPGP digital signature
Re: Opinions on CDBS amongst sponsors
Neil Williams wrote: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. jftr: i do sponsor cdbs packages, but i can't give any tips to the sponsoree in case there are problem whith it. What are the problems with CDBS (apart from debian/control automation)? For me, it's all about calling the dh_* scripts: cdbs always calls all every available dh_* it seems, whereas handcrafted rules do only call the required ones. Beeing adicted to simplicity, this is not a cleverness feauture to me, that's raw force. Some time ago, when squashfs and unionfs were both building their binary-modules packages on their own, unionfs took about 30 seconds to build with handcrafted rules for all i386 flavours, whereas squashfs took over 2.5 minutes with cdbs (and build: for squashfs takes less time than the one of unionfs). The effect of calling all dh_* was cumulating, though. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On 2006-12-11, Neil Williams [EMAIL PROTECTED] wrote: What are the problems with CDBS (apart from debian/control automation)? The biggest problem are the layers of obscurity added by cdbs and the fact that the best docs are diving into the source. (and the fact that there has been some cdbs revisions that had broken other packages because changes wasn't 100% well thought) People have told me that until you have read and understood the cdbs classes you use, you should not use cdbs. I do not disagree much on that. As new package maintainer, you need to know what happens and shouldn't use cdbs to hide what is really going on. CDBS does also have its advantages somewhere - the use of a common system for larger stuff instead of all people inventing their own different build-abstraction-layer. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
Hi, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? my biggest problem about CDBS is the obscurity it adds to packages. Example: You are a new-time debian developer. You want to adopt a package that is already in Debian using cdbs. Now you have a debian/rules files with some includes and some unclearly further rules. To find out what actually happens when building is done, you will have to have worked a lot with CDBS to understand what actually happens, when building or you need to tackle with the include files to find it out. This is not to hypothetical though. I was in interest several month ago to adopt a package which used CDBS and was poorly maintained. In fact i did resign to that, because it was to obscure for me and that time i wasn't too interested to figure out how to change it. Best Regards Patrick signature.asc Description: OpenPGP digital signature
Re: netcdf packages
Hi Warren, some further notes (as an addition to my previous written notes), as i actually figured to get it built (pooh, was some work). General: In my other mail i told you that i think it is bad to use a pre-beta. Now that i got this package to compile my impression is hardened because while compiling there do occur about several hundred of warnings. Okay, but i commit, that i don't know if a stable release of netcdf is building cleaner. Also build process is taking a *very* long time, but thats because of CDBS. debian/control: * You miss some build-deps. The build process does use texi2dvi while building, which is in package texinfo. Also you need to build-depend on tex because texi2dvi does not work without a running tex installation. Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). Best Regards Patrick Warren Turkal wrote: Debian Mentors, I have worked tonight to produce new netcdf packages for the NetCDF libraries. They are located at [1]. I would like some feedback on them. They are based on cdbs. [2] is a link to a WNPP bug about this package. I would like to adopt the package, if possible. Thanks, wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ [2]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321336 signature.asc Description: OpenPGP digital signature
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 11:38:41 +0100 Andreas Barth [EMAIL PROTECTED] wrote: * Neil Williams ([EMAIL PROTECTED]) [061211 11:26]: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. I don't use automatic debian/control management and I personally wouldn't recommend using that part of CDBS. What are the problems with CDBS (apart from debian/control automation)? I need to reverse-engineer code every time I use it There was a good blog entry recently about automation: Good helpers make the tasks easier by reducing complexity. cdbs doesn't do that - it surely makes the task easier for people used to it, but for all others, it is a big black box adding complexity. Fully agreed. Factorising rules is alright, would be unreasonable to have to write every single command each time, but factorising to the extreme, like CDBS does, making the building system utterly complex is a bit absurd too. -- Ricardo Mones ~ Datei nicht gefunden Fehler 404 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Monday 11 December 2006 11:25, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? Generally I am not a fan of layers of abstraction once the abstraction is too abstract. Frameworks are great as long as they do what you expect. But if they fail to do what you expect you are boned. Frameworks may even be buggy which means you totally depend on the person who created the framework. CDBS for me means: - documented mainly by its source (that - since it's just makefiles - looks even worth than some of my early Perl projects) - brute-force approach by calling everything that starts with dh_ - not simple any more once you try to do non-standard things Some package maintainers may think the default debian/rules file created by dh-make is uncomfortable. And I admit that using debhelper makes writing the same prayer into debian/rules time and again. But at least I understand which steps are done when calling the different stages of debian/install manually. And sometimes I even dear that package maintainers using CDBS don't even care about what happens exactly. IMHO debhelper (dh_*) is the right abstraction layer. I already looked at packages where everything was done using basic shell commands. That's not very clear to the reader either and too low-level for common use. When sponsoring packages I claim to understand how the package is built to spot major mistakes. With CDBS I can just insert a coin and hope for the best. It just leaves me with a let's hope this one builds on the buildds, too. Kindly Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how remove leading / at dh_install ?
Hello
I am trying to use dh_install into a debian/rules for copying a compiled file
to another compiled directory.
But the sourcedir is calculated. The dh_install (or dh_movefiles) needs a
relative directory and the string substitution generates a leading /.
Man pages and doc examples does not have a clear solution to this.
Do you have any suggestion?
Regards.
Andre Felipe Machado
http://www.techforce.com.br
debian/rules snippet:
binary-indep: build install
# AFM 27nov2006 .war file is java
# AFM 11dec2006 using dh_installdirs and dh_install for this task
# note the absence of leading /
# mkdir -p ${DESTDIR}/var/lib/tomcat5/webapps
# cp ${DESTDIR}$(PHP_EXT_DIR)/JavaBridge.war
${DESTDIR}/var/lib/tomcat5/webapps
dh_install ${DESTDIR}$(PHP_EXT_DIR)/JavaBridge.war
var/lib/tomcat5/webapps
build output snippet:
dh_install
/home/sedsl/temp/temp_sourceforge/php-java-bridge-3.2.1/debian/php-java-bridge/usr/lib/php5/20051025/JavaBridge.war
var/lib/tomcat5/webapps
cp -a
.//home/sedsl/temp/temp_sourceforge/php-java-bridge-3.2.1/debian/php-java-bridge/usr/lib/php5/20051025/JavaBridge.war
debian/php-java-bridge/var/lib/tomcat5/webapps/
cp: impossível fazer stat em
`.//home/sedsl/temp/temp_sourceforge/php-java-bridge-3.2.1/debian/php-java-bridge/usr/lib/php5/20051025/JavaBridge.war':
Arquivo ou diretório não encontrado
dh_install: command returned error code 256
make: ** [binary-indep] Erro 1
debuild: fatal error at line 1228:
fakeroot debian/rules binary failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Monday 11 December 2006 12:05, schönfeld / in-medias-res.com wrote: This is not to hypothetical though. I was in interest several month ago to adopt a package which used CDBS and was poorly maintained. In fact i did resign to that, because it was to obscure for me and that time i wasn't too interested to figure out how to change it. Well, to me it's just a matter of personal taste.. You could argue the other way roumd: what I do like in cdbs is that you focus on your rules on the specific difference that your package needs from a common build system. That is to say that you don't have to read and parse a complicated rules files until you get why this or that trick happen... The three criticisms I could say to cdbs is : - Lack of documentation, even though duck's page is very usefull there, but does not cover all cases - Put a strong responsability on cdbs maintainers. If cdbs would to be broken at some point, then the more package using cdbs there would be, the more broken package we would get - Some difficulties for teaching package practicies. I'll let you do it the full way and then teach you a way to circomvent everything in two line... Apart from that I am really happy using it. Romain
Re: how remove leading / at dh_install ?
[EMAIL PROTECTED] wrote: But the sourcedir is calculated. The dh_install (or dh_movefiles) needs a relative directory and the string substitution generates a leading /. Man pages and doc examples does not have a clear solution to this. Do you have any suggestion? I am pretty sure the string substitution does not generate the leading slash. What is the value of $DESTDIR ? I guess if you set this to a relative path, it'll work out. Bye, tobias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 10:25:58 + Neil Williams [EMAIL PROTECTED] wrote: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? I'm asking this because it is directly relevant to my emdebian work : I'm writing wrappers and helpers that take the drudgery out of converting packages for cross-building. Part of that is writing a replacement for debuild that can cope with cross-building, handling cross-built dependencies and cross-building packages such that there is no effect on building native packages on the same system. It's a question of extent. How much abstraction is too much, how much control is too little? Documentation is going to be a key point. I'm trying to write the scripts to have multiple levels of verbosity so that with foo -v -v -v it gives you output that is almost step-by-step walking you through the commands being used. I'm also preparing manpages for each command - something that cdbs lacks (which should probably be a bug report). I'll also be updating the emdebian wiki to keep those docs in sync too. Cross-building is another learning curve beyond Debian packaging and I'm conscious that it isn't easy to explain or follow sometimes. If anyone is interested in helping proof-read the documentation and script output from a position of someone new to cross-building, let me know. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpb1zGXgzvFQ.pgp Description: PGP signature
Re: aspell-uz: new upstream release (0.6.0)
On Monday 11 December 2006 01:02, Daniel Baumann wrote: Mashrab Kuvatov wrote: I cannot do anything about it. It is on a Uni web-server. I should have thought about it. Please use mentors.debian.net then. OK. From now on it is at: http://mentors.debian.net/debian/pool/main/u/uzbek.wordlist I had a look at the latest, there are few glichtes left: * debhelper (= 5.0.0) is over precise, debhelper (= 5) is enough. Fixed. * copyright has a useless empty line at the end of the file. Fixed. didn't hear back about the install -D thing, so I assume you don't want to do it (fine with me, it's technically no difference :). OK. Now, I'm using install instead of just copying. and there is a question left: you are also maintaining aspell-uz, what is it matter with it wrt/ that uzbek.wordlist does also have a aspell list? So far, I built aspell-uz from a tarball author of the Aspell provides (official Aspell dict), which is in fact made from my word-list. Aspell and Hunspell stuff were added to the word-list only in the last release. From now on I'm going to build debs from my word-list only. additionally, i recommend you rename the source package name to uzbek-wordlist, since source package names with points as seperator is uncommon and looks very ugly. Yes. I planned it for the next release. however, aside from the things above, the package is fine and i'll sponsor it once we've worked the above out. Thanks a lot. Mashrab. -- Mashrab Kuvatov PGP key: www.uni-bremen.de/~kmashrab/kmashrab.asc pgpZSBX8XpSa4.pgp Description: PGP signature
Re: Opinions on CDBS amongst sponsors
Neil Williams wrote: Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? I have seen bugs that could have lead to FTBFS, due to the fact that people mixed up their build-depends and build-depends-indep because they didn't notice that CDBS was calling an external program in the clean target. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how remove leading / at dh_install ?
On Mon, 11 Dec 2006 14:45:59 +0100, Tobias Richter wrote
I am pretty sure the string substitution does not generate the
leading slash. What is the value of $DESTDIR ? I guess if you set
this to a relative path, it'll work out.
Bye,
tobias
Hello,
Thanks for your suggestion.
Currently, the DESTDIR is:
DESTDIR := ${CURDIR}/debian/php-java-bridge
PHP_EXT_DIR := $(shell /usr/bin/php-config --extension-dir)
if I try to use a relative path:
./configure --with-java=/usr/lib/jvm/java-1.5.0-sun
--prefix=debian/php-java-bridge
configure: error: expected an absolute directory name for --prefix:
debian/php-java-bridge
So, it have to be an absolute path...
Do you have further suggestions?
Regards.
Andre Felipe Machado
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how remove leading / at dh_install ?
Hi,
On 12/11/06, andremachado [EMAIL PROTECTED] wrote:
So, it have to be an absolute path...
The dh_install man-page [1] seems to indicate that the paths given to
dh_install have to be relative:
The name of the files (or directories) to install should be given relative to
the
current directory, while the installation directory is given relative to the
package
build directory.
If your ./configure script requires an absolute path, you can provide
it an absolute path, but feed dh_install with a relative path
(provided that both paths are consistent).
Unless I misunderstood your problem, you could for exemple try something like:
# Relative path
BUILDDIR=debian/php-java-bridge
# Absolute path
DESTDIR = ${CURDIR}/${BUILDDIR}
# ./configure requires the absolute path
./configure --prefix=${DESTDIR}
# dh_install uses the relative path
dh_install ${BUILDDIR}/$(PHP_EXT_DIR)/JavaBridge.war var/lib/tomcat5/webapps
Cheers,
François
[1] http://nixdoc.net/man-pages/Linux/man1/dh_install.1.html
Re: how remove leading / at dh_install ?
On Mon, 11 Dec 2006 16:18:30 +0100
François Févotte [EMAIL PROTECTED] wrote:
Unless I misunderstood your problem, you could for exemple try something like:
# Relative path
BUILDDIR=debian/php-java-bridge
# Absolute path
DESTDIR = ${CURDIR}/${BUILDDIR}
# ./configure requires the absolute path
./configure --prefix=${DESTDIR}
Sorry for butting in, but that seems unwise: AFAIK, the --prefix
string's purpose is to tell where the software will be installed on the
user's machine. Some paths may get hardcoded into your software, and
you'll be sad if your binary ends up looking for icons or the like
in /home/me/debian/whatever.
I believe the Right Thing (TM) to do is
./configure --prefix=/usr
make
DESTDIR=$(DESTDIR) make install
Might be wrong though, and if the software doesn't use helper files it
doesn't matter anyway.
# dh_install uses the relative path
dh_install ${BUILDDIR}/$(PHP_EXT_DIR)/JavaBridge.war var/lib/tomcat5/webapps
Regards, Thibaut.
Same problem with Debian 2.6.18-7 Cisco Aironet 350 can't get a compiled module to run
Hi all, not sure using the proper place (I first posted into [EMAIL PROTECTED] and also in testing w/o any success in getting answers or help), but let's have try here. I have an old HP Omnibook 900 and I'm compiling an optimized Linux image for it under Etch Debian. When using the defacto linux-image package (2.6.18-7) from Debian the pcmcia card is configured an work like a charm. But when I do use my own compiled kernel I have always the same problem (I have tried many .config w/o any success): - The card is recognized in both cases (Yenta CardBus Bridge) and I do have equivalent tons of kprintf messages with my compiled airo module I always have the following: airo(eth0): BAP error 4000 0 airo(eth0): Bad size 2630 airo(eth0): BAP error 4000 0 airo(eth0): Bad size 2636 airo(eth0): airo: BAP setup error too many retries ... I look at any possible Google tips prior getting here asking stupid questions. At cisco web side it's all now protected and inaccessible the other available driver on sourceforge project page seems to have been abandoned. I'm alone in that case? Anyone with a working suggestion? Thanks in anticipation, JL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 03:42, Patrick Schönfeld wrote: * Remove all files from debian/ with .ex ending. They are example files and if you don't need them, then you should not include them. If you need them, then rename and edit them and whatever it needs to do further. I was evaluating the utility of the watch.ex and doc-base.EX files before I deleted them. I am planning on removing watch.ex and possibly using the doc-base.EX to itegrate the documentation. * debian/rules * : Remove the unneeded extra line at EOF I like the empty line at the end of a file. It allow me to bring the cursor back to the left at the bottom. * : I don't know much about your package but is configure parameter --enable-64bit right? You will not build for 64bit systems only in debian imho The enable-64bit doesn't enable 64bit archs, it enables 64bit offsets in the files so that they can be over 2GB. * Personally i would use 'install -d' to create directories while building and get rid of those .dirs files which do contain standard directories only Is that somehow better than using the debhelper to do it? The directories are created so that I can load them up with files. * debian/*.dirs: Seee above rules comment * debian/copyright: * According to debian policy 12.5 you *must* say where the upstream sources (if any) were obtained Okay. I have that in my local repository for the next release. Here the text I added to the top of the copyright file. This package was put together by Warren Turkal [EMAIL PROTECTED] with sources obtained from the http://www.unidata.ucar.edu/software/netcdf/ site. * You should name the original authors of the package and the Debian maintainer(s) who were involved with its creation above * IMO you should mention the ones who previous did packaging The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. * The lines at the end of the file seem to be unnecessary removed * debian/changelog: * Should contain changelog entries of previous debian versions added in local repository for next release * Must contain a notice that you are new maintainer done locally Further notes: It sounds a bit strange that your package has a version -beta-pre. I'm not sure if you really want to package a pre-beta (what actually is an alpha version in my sense). Also i don't like cdbs much. IMO it makes packages / packages build process unclearly. NetCDF developers are incredibly conservative about releases. The last beta release was on Aug. 16. This is what is packaged. It doesn't have any API regressions that I or my scientists have been able to find. I have scientists running some pretty intense numerical simulations based on these libraries. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
On Monday 11 December 2006 05:34, schönfeld / in-medias-res.com wrote: General: In my other mail i told you that i think it is bad to use a pre-beta. Now that i got this package to compile my impression is hardened because while compiling there do occur about several hundred of warnings. Okay, but i commit, that i don't know if a stable release of netcdf is building cleaner. Also build process is taking a *very* long time, but thats because of CDBS. The latest full release of the NetCDF libs are no cleaner, unfortunately. In fact, the lastest full release dosn't support shared libs. The Debian package has hacked in support to build the shared libs. debian/control: * You miss some build-deps. The build process does use texi2dvi while building, which is in package texinfo. Also you need to build-depend on tex because texi2dvi does not work without a running tex installation. Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). I want the package to be sorted before a real -1 release in the debian archive so that folks installing the pre packages don't have to worry about manually removing the pre packages to get the real ones. I will collapse the pre packages into one changelog entry for the -1 release. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: how remove leading / at dh_install ?
Hello, Many thanks for your suggestion, François. It works very well. You could see the result debian/dirs and debian/rules clean files at http://php-java-bridge.cvs.sourceforge.net/php-java-bridge/php-java-bridge/debian/ Regards. Andre Felipe Machado http://www.techforce.com.br -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
Neil Williams [EMAIL PROTECTED] writes: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? Yes. For example, a bug in CDBS (since fixed, I believe) broke dependency handling between libraries built from the same source package unless one ordered the binary packages in debian/control just right. Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? You're really comparing apples to kumquats here; CDBS and debuild are completely unrelated. You can use either debuild or dpkg-buildpackage to build CDBS-using packages, for instance. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how remove leading / at dh_install ?
Thibaut Paumard wrote: I believe the Right Thing (TM) to do is ./configure --prefix=/usr make DESTDIR=$(DESTDIR) make install I'd say it is make DESTDIR=$(DESTIR) install -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote: Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). I want the package to be sorted before a real -1 release in the debian archive so that folks installing the pre packages don't have to worry about manually removing the pre packages to get the real ones. I will collapse the pre packages into one changelog entry for the -1 release. You can use the ~ suffix, as in 3.6.2-beta4~pre1. These versions will evaluate lower than 3.6.2-beta4. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 12:35, Felipe Sateler wrote: You can use the ~ suffix, as in 3.6.2-beta4~pre1. These versions will evaluate lower than 3.6.2-beta4. Thanks for the info. I am guessing that I would version it like 3.6.2-beta4~pre1-1 then? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knetstats
Ritesh Raj Sarraf wrote: Daniel, Thanks for all your points. I've re-uploaded it and now there are no lintian warnings also. :-) Everything well, except the following two regressions: * changelog has got an empty line at the end again * you removed $(MAKE) from build, i recommend you add it back. then.. thanks for the patience, finally i can upload it :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, Dec 11, 2006 at 10:58:27AM -0800, Russ Allbery wrote: Neil Williams [EMAIL PROTECTED] writes: How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. The other thing with these other tools is that they tend to do a single, linear task without a great deal of policy or other decision making that affects the built package. It shouldn't make much diference if they are used or not. CDBS, on the other hand, has a very substantial effect on the built package. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal [EMAIL PROTECTED] wrote: Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Ugh, what's this 'tex' package? Before blindly doing what others tell you, you'd better think a little bit (I'm sure Patrick didn't want to deceive you; just to make you think about which package(s) to Build-Depend on in order to get your texi2dvi call running properly). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 14:33, Florent Rougon wrote: Warren Turkal [EMAIL PROTECTED] wrote: Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Ugh, what's this 'tex' package? Well, I haven't posted the new version of the package because I haven't tested all the changes yet. I just wanted to respond to the email more timely than waiting for the next posting of my package, which could happen this evening. I will check more into this issue this evening. Here is the current Build-Depends line: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, texinfo It is running through debuild-pbuilder right now. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs on machine
On (09/12/06 19:23), Luca Bedogni wrote: Is there a way to know all the bugs affecting packages installed on a machine? Something similar to wnpp-alert, but catching all the bugs insted of O, RFP or similar. Not entirely what you want, but there is rc-alert, also from devscripts. As you might guess this shows rc bugs from the packages you have installed. Also I'm not sure what has changed in this area but apt-listbugs used to be very light on the BTS in terms of requests. It also doesn't have to be run in a dpkg hook, but can be invoked manually (apt-listbugs list pkg IIRC). I'm also not sure if it can do multiple packages at once. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 15:33, Warren Turkal wrote: It is running through debuild-pbuilder right now. New version (3.6.2-beta4~pre1) at [1]. This version sorts before the last one so you will have to manually remove the prior packages I posted if you used apt* to install them. Here's the changelog entry. netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) * Combined all libs into one package. * Upstream version fixes inconsistent manpage (closes: #353332) * Touched up descriptions on some of the packages wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 10:58:27 -0800 Russ Allbery [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED] writes: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. OK, I see that. In which case, my own wrappers are also unlike CDBS and much more like debhelper. The commands executed by the scripts can be performed manually and I'm being careful to ensure useful documentation. As you say, every command with a man page, every man page checked for accuracy before each release. (Take a look at apt-cross - v0.0.5 just uploaded to Debian.) Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? You're really comparing apples to kumquats here; CDBS and debuild are completely unrelated. You can use either debuild or dpkg-buildpackage to build CDBS-using packages, for instance. True, but debuild is much closer to what I'm actually doing for emdebian. It just so happens that the scripts also have to be able to cope with CDBS packages, hence the comparison. I'm primarily interested in sponsoring embedded packages (or packages small enough to be useful on embedded devices) and although I use CDBS for my own packages, I have no particular preference for packages that I may sponsor. Thanks for the feedback on CDBS one and all - very helpful. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpeOR3C4ONhq.pgp Description: PGP signature
Re: RFS: LiE computer algebra for Lie groups
Once you make these changes, repost your sponsor request. I have made all the changes you mentioned in your two previous emails. New files are at http://www.aei.mpg.de/~peekas/debian/ There's only one warning left when running lintian on the package: W: lie: description-synopsis-might-not-be-phrased-properly What am I supposed to do with this? Thanks, Kasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: LiE computer algebra for Lie groups
On Tue, Dec 12, 2006 at 12:32:06AM +0100, Kasper Peeters wrote: Once you make these changes, repost your sponsor request. I have made all the changes you mentioned in your two previous emails. New files are at http://www.aei.mpg.de/~peekas/debian/ Please post the complete URL to your .dsc file, it's easier for potential sponsors to grab it. FWIW: Dear DD's, pending minor comments below, I believe this package is close to ready for sponsorhip. There's only one warning left when running lintian on the package: W: lie: description-synopsis-might-not-be-phrased-properly What am I supposed to do with this? Your description: lie- A computer algebra package for Lie group computations. Dev-ref says: It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., Rudolph the red-nosed reindeer. The appositive clause here is red-nosed reindeer. Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite (the) or indefinite (a or an). It might help to imagine that the _synopsis_ is combined with the _package name_ in the following way: _package-name_ is a _synopsis_ So, I suggest something like lie - computer algebra package for Lie group computations note no 'A' and no final '.' When running lintian, do it over the .changes file, so it gets to check the source package too. That way, I also get: W: lie source: dh-make-template-in-source debian/manpage.1.ex which is a debhelper example file you missed. It's better if the manpage you wrote is put inside the debian dir. That way is clearer to anyone getting the source package it was added for debian. The information you give in the new README adds nothing to the package description and copyright. I suggest you simply ship no README. In any case, don't rename it in the source package to INSTALL, that's a gratuituous modification of the source package that only adds in size to the diff. Also: Your debian/dirs contains usr/sbin, which is unneeded, since you ship it empty. Take it out. Better yet, take the whole file out, as you do not need to ship any dir that's not created by your install. And, a final comment, please give some license statement concerning the packaging itself, in the copyright file. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
RFC: gprsec -- GPRS Easy Connect - Connect to the Internet with a GPRS phone
Dear mentors, Please can I have comments about my packaging of gprsec, which I intend to package. * Package name: gprsec Version : 3.0.0-1 Upstream Author : Piter Simon * URL : http://www.gprsec.hu/ * License : GPL2 Section : net It builds these binary packages: gprsec -- GPRS Easy Connect - Connect to the Internet with a GPRS phone The package is lintian clean. The upload would fix these bugs: 325389 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gprsec - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gprsec/gprsec_3.0.0-1.dsc wbr Denis Sirotkin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
