Re: libqrupdate: Done?
* Rafael Laboissiere raf...@debian.org [2009-02-06 01:41]: * Jordi Gutiérrez Hermoso jord...@gmail.com [2009-02-05 16:56]: I think I'm done with libqrupdate and that it's ready for upload to Debian. Thanks, I will upload the package soon. Done. The package is now in the NEW queue [1]. Thanks for putting it together. Do you know when it will become a build-dependency to Octave? I have also tagged the release in SVN. The command that I used is: svn cp svn+ssh://svn.debian.org/svn/pkg-scicomp/qrupdate/trunk/debian svn+ssh://svn.debian.org/svn/pkg-scicomp/qrupdate/tags/1.0-1 --message=Tag Debian release qrupdate_1.0-1 I have a script for automating this task and can send it to you, if you wish. [1] http://ftp-master.debian.org/new.html -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libqrupdate: Done?
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-02-05 16:56]: I think I'm done with libqrupdate and that it's ready for upload to Debian. Thanks, I will upload the package soon. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-02-03 21:41]: I've also set up an svn repo for this package with the pkg-scicomp team: http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/ Thanks for that. Could you please create the trunk/ and tags/ directories and move debian/ into trunk/? Otherwise it will be hard to tag the Debian releases of the packages. This is the usual layout for pkg-scicomp packages, e.g.: $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk/trunk $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk/tags In this case, the Vcs-* tags in debian/control would be: Vcs-Svn: svn://svn.debian.org/svn/pkg-scicomp/qrupdate/trunk/ Vcs-Browser: http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/ I already committed three changes (added my name to Uploaders, fixed the debian/watch URL, and add a svn:ignore list). If you have not yet done it, you might be interested in subscribing to the pkg-scicomp-commits mailing list. You might also set the Maintainer to Debian Scientific Computation Team pkg-scicomp-de...@lists.alioth.debian.org and add your name to Uploaders. This common practice in pkg-scicomp but it is up to you. Otherwise, the package builds and installs fine here. I would just follow the suggestion from Paul Wise and put README and function-reference only in the -dev package. Please, tell us when the package is ready for upload. Cheers, -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-scicomp-devel] RFS: qrupdate
* Paul Wise p...@debian.org [2009-02-04 18:31]: On Wed, Feb 4, 2009 at 6:20 PM, Rafael Laboissiere raf...@debian.org wrote: Otherwise, the package builds and installs fine here. I would just follow the suggestion from Paul Wise and put README and function-reference only in the -dev package. Well, this is a fortran library, you don't nessecarily need the -dev package to build apps that link against it. I'd put them in both packages myself. You are right. I have missed this point. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/symbols Fortran library
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-01-28 10:12]: re: http://lists.debian.org/debian-mentors/2009/01/msg00241.html Alright, I got around to fixing all of Lintian warnings and the other issues that Rafael Laboissiere found. However, I still don't understand how to generate debian/symbols in order to satisfy the Lintian message. It also seems that debian/symbols is a relatively recent addition to packaging practices. How am I supposed to generate how should I use it? I've been reading the dpkg-gensymbols manpage and chapter 8 in Policy, but I still don't understand how to generate the symbol list in the first place? objdump? But that lists more symbols than I need, right? Here is the cookbook: $ cd libqrupdate-1.0 $ rm -f debian/*.symbols dpkg-gensymbols* $ dpkg-gensymbols -plibqrupdate1 -Pdebian/libqrupdate1 | patch -p0 $ mv dpkg-gensymbols* debian/libqrupdate1.symbols $ perl -pi -e 's/-1//' debian/libqrupdate1.symbols Play with the commands above and look at the dpkg-gensymbols man page. There may be easier ways to generate the symbols files, but the above is the way I know of. You need also to add a call to dh_makeshlibs in debian/rules. Another thing: since the upstream name of the package is qrupdate, I think you should change Source: libqrupdate to Source: qrupdate in debian/control and change the orig.tar.gz tarball name accordingly. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-octave-devel] RFS: libqrupdate
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-01-18 23:42]: Dear mentors, I am looking for a sponsor for my package libqrupdate. Package name: libqrupdate Version : 1.0-1 Upstream Author : Jaroslav Hájek URL : http://qrupdate.sf.net License : GPLv3 Section : libs [...] The package is closely related to Octave, as it was a library that was only used in Octave, but has now been packaged as a separate library. Once the Octave build system gets updated, Octave will depend on this library. I am therefore CCing the Debian Octave Group. Rafael Laboissiere, if you want to upload this to Debian, I will commit to our svn soon. I made a few trivial patches to the build system but without using quilt, so would you prefer that I fix that before committing? I would gladly sponsor the upload of the package. However, I think it will be more appropriate to maintain the package in the SVN repository of the pkg-scicomp group. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-octave-devel] RFS: libqrupdate
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-01-18 23:42]: I am looking for a sponsor for my package libqrupdate. [...] The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libqrupdate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libqrupdate/libqrupdate_1.0-1.dsc Okay, I took a look at your package. First, it only builds after applying the following patch: = --- debian/rules2009-01-19 22:16:45.0 + +++ debian/rules.new2009-01-19 22:16:37.0 + @@ -17,6 +17,7 @@ $(MAKE) test #extract docs from sources +chmod +x debian/get-function-ref.pl cat src/*.f | debian/get-function-ref.pl function-reference touch $@ = Second, please address the following Lintian messages: W: libqrupdate source: dh-clean-k-is-deprecated I: libqrupdate1: no-symbols-control-file usr/lib/libqrupdate.so.1.0 I: libqrupdate1: copyright-with-old-dh-make-debian-copyright I: libqrupdate1-dev: copyright-with-old-dh-make-debian-copyright I made a few trivial patches to the build system but without using quilt, so would you prefer that I fix that before committing? Yes, please, use a patch management system for introducing the Debian-specific changes. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-octave-devel] QtOctave new upstream release
* Jordi Gutiérrez Hermoso [EMAIL PROTECTED] [2008-11-30 09:08]: 2008/11/28 Rafael Laboissiere [EMAIL PROTECTED]: I committed some changes in the package. Please, take a look at the current SVN sources and tell me whether they are okay with you. Ah, nice. I didn't think of automating the upstream tarball restructuring. Thank you for the example on how to do it. Yeah, looks good to me now. Release it? Done. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-octave-devel] QtOctave new upstream release
* Jordi Gutiérrez Hermoso [EMAIL PROTECTED] [2008-11-27 12:34]: 2008/11/27 Andreas Wenning [EMAIL PROTECTED]: Your lintian error points out that the file src/.pc/.version is modified (actually created) in the diff.gz . The .pc/.version dir is most likely created by an editor on another program while changing the package; you should simply get rid of that file and re-pack. Oh, that was easy. Thank you. I wasn't able to parse the Lintian error. I have re-uploaded the package. We should probably should wait until Rafael Laboissiere approves it; he migiht find other problems with the package, and the Debian Octave Group has overall more experience packaging this. I committed some changes in the package. Please, take a look at the current SVN sources and tell me whether they are okay with you. Rafael, I have uploaded the changes to svn too. I put them in trunk/ since I understand that I shouldn't make a tag yet until you approve the packaging? Right. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trouble in uploading bzip2 upstream tarball
* Raphael Geissert [EMAIL PROTECTED] [2007-12-16 16:39]: Since when are .bz2 uploads allowed? AFAIK bzip2 is only allowed to be used to compress the data.tar inside the .deb You are right, I got confused. Sorry for the noise. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Trouble in uploading bzip2 upstream tarball
The Debian Installer is refusing my upload by saying:
==
Rejected: aspell6.pt_20071212.0-2.dsc: incompatible 'Format' version produced
by a broken version of dpkg-dev 1.9.1{3,4}.
Rejected: aspell6.pt_20071212.0-2.dsc: aspell6.pt_20071212.0.orig.tar.bz2 in
Files field not recognised as source.
Rejected: aspell6.pt_20071212.0-2.dsc: no .tar.gz or .orig.tar.gz in 'Files'
field.
Rejected: 'dpkg-source -x' failed for aspell6.pt_20071212.0-2.dsc [return code:
512].
[dpkg-source output:] gpg: Signature made Sun 16 Dec 2007 08:27:15 PM UTC
using DSA key ID 4A5D72FE
[dpkg-source output:] gpg: Can't check signature: public key not found
[dpkg-source output:] dpkg-source: failure: cannot read
./aspell6.pt_20071212.0.orig.tar.bz2: No such file or directory
==
What should I do to fix this? The .dsc file reads:
==
Format: 2.0
Source: aspell6.pt
Binary: aspell-pt-pt
Architecture: all
Version: 20071212.0-2
Maintainer: Rafael Laboissiere [EMAIL PROTECTED]
Homepage: http://natura.di.uminho.pt/wiki/index.cgi?Aspell
Standards-Version: 3.7.3
Vcs-Browser: http://svn.debian.org/wsvn/private/rafael/deb-pkg/aspell6.pt/
Vcs-Svn: svn://svn.debian.org/svn/private/rafael/deb-pkg/aspell6.pt/
Build-Depends: cdbs, debhelper (= 5)
Build-Depends-Indep: dictionaries-common-dev (= 0.70)
Files:
0f76f5eead1f14e087c1224a7a18f732 92065 aspell6.pt_20071212.0.orig.tar.bz2
375c012f60078e5754966521e3569688 3252 aspell6.pt_20071212.0-2.diff.gz
==
and the .changes file:
==
Format: 1.7
Date: Sun, 16 Dec 2007 21:17:37 +0100
Source: aspell6.pt
Binary: aspell-pt-pt
Architecture: source all
Version: 20071212.0-2
Distribution: unstable
Urgency: low
Maintainer: Rafael Laboissiere [EMAIL PROTECTED]
Changed-By: Rafael Laboissiere [EMAIL PROTECTED]
Description:
aspell-pt-pt - European Portuguese dictionary for GNU Aspell
Changes:
aspell6.pt (20071212.0-2) unstable; urgency=low
.
* debian/control: Pre-depends on dpkg = 1.10.24, otherwise the Debian
Installer will refuse to install the package in unstable
Files:
fd3721cc25c8080ebf0748b91880d643 855 text optional aspell6.pt_20071212.0-2.dsc
0f76f5eead1f14e087c1224a7a18f732 92065 text optional
aspell6.pt_20071212.0.orig.tar.bz2
375c012f60078e5754966521e3569688 3252 text optional
aspell6.pt_20071212.0-2.diff.gz
1fad8458817c257c907adb010e825187 106668 text optional
aspell-pt-pt_20071212.0-2_all.deb
==
Thanks,
--
Rafael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: QtOctave -- A Qt front-end to Octave
* Jordi Gutierrez Hermoso [EMAIL PROTECTED] [2007-06-17 21:38]: (Note to octave-help list subscribers who may be interested: I attempted to stick to Debian policy after all, which is why I'm attempting to add this to Debian's repositories. The dotdeb works in Debian's current testing, and should be easily built for other distributions. Note that Qt4 is required to build and run the package.) Hello, Debian mentors. This is my first attempt to upload a Debian package and the first package I've ever built believing to be adhering to Debian policy. I don't even know what the exact etiqutte for RFSing or where all those people are getting the RFS template or how exactly I should upload things. The Debianised source tarball is found here: http://www.cimat.mx/~jordi/debian/qtoctave_0.5.1-1.debian.tar.gz The dotdeb I built in Lenny (but which *should* build in unstable unless libqt4-dev is more heavily patched than I think) is found here: http://www.cimat.mx/~jordi/debian/qtoctave_0.5.1-1_i386.deb It is mostly Lintian-clean, save for #428403 and a missing manpage for widgetserver whose purpose I have not yet discerned. Since this regards packaging of Octave-related software for Debian, then the appropriate place to discuss the issue is in the pkg-octave-devel mailing list [1] of the Debian Octave Group [2]. I am Cc:ing this message there. [1] http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel [2] http://pkg-octave.alioth.debian.org/ Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#393832: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
* James Westby [EMAIL PROTECTED] [2007-04-17 18:09]: On (17/04/07 02:27), Rafael Laboissiere wrote: I see a problem with the above dependencies. Imagine the following combination of packages in a given system: apache2 installed apache, apache-ssl, and apache-perl NOT installed libapache2-mod-php4 installed libapache2-mod-php5 NOT installed php4-mysql, php4-pgsql, and php5-pgsql NOT installed php5-mysql installed The above satisfy the dependencies as you wrote them. The question is: would php5-mysql work well with libapache2-mod-php4? That's not your job, the php maintainers have to ensure their packages work, you just have to make sure enough php/mysql/apache stuff is installed to work. I think you missed the point. There is nothing that the php maintainers can do to fix the problem above, since they are doing already the right thing. The problem is related to the lack of power in specifying relationships among the packages (see my next post in this thread). The problem exists already in the the current version of the package. Indeed, the following combination satisfy the dependencies: apache2 installed other apaches NOT installed libapache-mod-php4 installed libapache2-mod-php4 NOT installed libapache-mod-php4 depends on apache-common, which in turn depends on apache, so that works ok. I do not see that: $ apt-cache show apache-common | grep ^Depends: Depends: libc6 (= 2.3.6-6), libdb4.4, libexpat1 (= 1.95.8), debconf (= 0.5) | debconf-2.0, perl (= 5.8.4-2), mime-support, apache2-utils, sed (= 4.0.5-1), ucf (= 1.06), lynx | www-browser Am I missing something? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
* Stephen Gran [EMAIL PROTECTED] [2007-04-18 01:04]: This one time, at band camp, James Westby said: That's not your job, the php maintainers have to ensure their packages work, you just have to make sure enough php/mysql/apache stuff is installed to work. Well, that's glossing it over a bit - the problem of ORed dependencies is not trivial to deal with, and there is no support in apt for it. Theoretically, these sorts of dependencies could be written with brackets or something to make a complete set soultion possible, but it's not there just yet. Is this feature under development? It would be great to be able to specify dependencies like the following (note the parentheses): Depends: ( ( ( apache | apache-ssl | apache-perl, libapache-mod-php4 ) | ( apache2, libapache2-mod-php4 ), php4-mysql | php4-pgsql ) | ( ( apache | apache-ssl | apache-perl, libapache-mod-php5 ) | ( apache2, libapache2-mod-php5 ), php5-mysql | php5-pgsql ) ) All my problems would then be solved! -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#393832: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
* Stephen Gran [EMAIL PROTECTED] [2007-04-18 11:14]: This one time, at band camp, Rafael Laboissiere said: Is this feature under development? It would be great to be able to specify dependencies like the following (note the parentheses): I know people have talked about the problem with an eye towards patching it in. I have not heard that anyone has actually produced any code. Do you remember where this discussion took place? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
package webcalendar
severity 393832 normal
merge 393832 419570
thanks
[Cc: to debian-mentors]
* Oleksandr Moskalenko [EMAIL PROTECTED] [2007-04-16 11:13]:
Package: webcalendar
Version: 1.0.5-1
Severity: normal
Tags: patch
webcalendar forces retention of php4 on the system. Dependencies must be
adjusted to allow removal of php4 in favor of php5. Upstream shows that it can
be done.
--- control.old 2007-04-16 11:12:09.0 -0600
+++ control 2007-04-16 11:03:17.0 -0600
@@ -11,8 +11,8 @@
Package: webcalendar
Architecture: all
-Depends: ${misc:Depends}, libapache2-mod-php4 | libapache-mod-php4,
php4-mysql | php4-pgsql, apache | apache2 | apache-ssl | apache-perl, ucf (=
0.28), dbconfig-common
-Suggests: php4-cli
+Depends: ${misc:Depends}, libapache2-mod-php4 | libapache-mod-php4 |
libapache2-mod-php5 | libapache-mod-php5, php4-mysql | php4-pgsql |
php5-mysql | php5-pgsql, apache | apache2 | apache-ssl | apache-perl, ucf (=
0.28), dbconfig-common
+Suggests: php4-cli | php5-cli
Recommends: mysql-client | postgresql-client, mysql-server | postgresql
Description: PHP-Based multi-user calendar
WebCalendar is a PHP-based calendar application that can be configured
Thanks for this suggestion, we have already thought about the issue. Another
bug report has been filed requiring php5 support (#393832), so I am merging
both bug reports.
I see a problem with the above dependencies. Imagine the following
combination of packages in a given system:
apache2 installed
apache, apache-ssl, and apache-perl NOT installed
libapache2-mod-php4 installed
libapache2-mod-php5 NOT installed
php4-mysql, php4-pgsql, and php5-pgsql NOT installed
php5-mysql installed
The above satisfy the dependencies as you wrote them. The question is:
would php5-mysql work well with libapache2-mod-php4?
At any rate, the problem comes from the orthogonality of the three
dimensions:
* PHP 4 vs. 5
* mysql vs. pgsql
* apache 1 vs. 2
The problem exists already in the the current version of the package.
Indeed, the following combination satisfy the dependencies:
apache2 installed
other apaches NOT installed
libapache-mod-php4 installed
libapache2-mod-php4 NOT installed
However, the webcalendar package will not work under these conditions.
I have no idea how to fix this problem. Suggestions are welcome.
--
Rafael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
* Daniel Leidert [EMAIL PROTECTED] [2007-02-27 14:01]: My regular sponsor seems to be in vacation, so I ask for someone else, who uploads the following packages to Debian (experimental): [...] docbook2x 0.8.7-1 http://debian.wgdd.de/debian/incoming/packages/docbook2x_0.8.7-1_i386.changes This package needs some more love, but I will do this for the next release. Thanks for taking care of this package. I uploaded it already. As we are at it, someone should try to fix Bug#262990. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
* Rafael Laboissiere [EMAIL PROTECTED] [2007-02-27 15:44]: * Daniel Leidert [EMAIL PROTECTED] [2007-02-27 14:01]: My regular sponsor seems to be in vacation, so I ask for someone else, who uploads the following packages to Debian (experimental): [...] docbook2x 0.8.7-1 http://debian.wgdd.de/debian/incoming/packages/docbook2x_0.8.7-1_i386.changes This package needs some more love, but I will do this for the next release. Thanks for taking care of this package. I uploaded it already. I am wondering whether we should upload this package to unstable and ask the release team to unblock it for testing, since it fixes Bug#409524, which is release critical. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
* Rafael Laboissiere [EMAIL PROTECTED] [2007-02-27 16:17]: I am wondering whether we should upload this package to unstable and ask the release team to unblock it for testing, since it fixes Bug#409524, which is release critical. Sorry, I forgot that this bug concerns only sid and not testing. Better leaving it in experimental, then. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Closing bugs fixed in experimental
Is it acceptable to manually close a bug which is fixed in experimental but not yet in unstable, especially when there are no plans regarding the upload of the fixed version to unstable in the foreseeable future? Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Removing non-free documentation from a package
[Please Cc: replies to me.] Hi, My package libparse-recdescent-perl contains a tutorial in HTML which is non DFSG-compliant and I have to remove it from the main package. The tutorial is actually quite helpful and I would like to make a nonfree package for it. My questions are: 1) Do I have to create a separate source package for the nonfree binary package? 2) How should the nonfree package be called? The options would be: libparse-recdescent-perl-nonfree libparse-recdescent-perl-doc parse-recdescent-doc parse-recdescent-nonfree parse-recdescent-doc-nonfree parse-recdescent-nonfree-doc or variations of the above. TIA, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
Oh, we have conflicting views here: * Frank Lichtenheld [EMAIL PROTECTED] [2005-09-15 14:07]: On Thu, Sep 15, 2005 at 01:15:59PM +0200, Rafael Laboissiere wrote: 2) How should the nonfree package be called? The options would be: libparse-recdescent-perl-nonfree libparse-recdescent-perl-doc I would go for that one. No need to append nonfree to every package name in non-free ;) * Sven Mueller [EMAIL PROTECTED] [2005-09-15 14:14]: Since the original package is libparse-recdescent-perl, I would name the non-free package libparse-recdescent-tutorial (if it really only includes a tutorial) or libparse-recdescent-doc-nonfree (if it is more than just the tutorial). In the latter case, I appended -nonfree to not block the -doc package name once free documentation becomes available. I buy Sven's arguments in favor of adding -nonfree. I would also strip the lib at the beginning of the name. The upstream Perl module is called Parse-RecDescent, so I would call the package parse-recdescent-doc-nonfree. What do you think? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
* Henrique de Moraes Holschuh [EMAIL PROTECTED] [2005-09-15 10:07]: On Thu, 15 Sep 2005, Rafael Laboissiere wrote: I buy Sven's arguments in favor of adding -nonfree. I would also strip the lib at the beginning of the name. The upstream Perl module is called Parse-RecDescent, so I would call the package parse-recdescent-doc-nonfree. What do you think? Stick to the perl package naming convention. Please. Well, the new package will not contain a Perl module, so I do not see the need to sticking to the conventions (cf section 4.2 of the Debian Perl Policy). The package containing the Parse::RecDescent module with the tutorial stripped is still called libparse-recdescent-perl. At any rate, I guess you are suggesting the name libparse-recdescent-perl-doc-nonfree, aren't you? Good chances to win the longest-package-name contest in Debian :-) -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
* Bas Wijnen [EMAIL PROTECTED] [2005-09-15 17:56]: Doc packages are usually called package-doc. I see no reason to change that here, except that adding non-free seems to make sense. Removing lib would just confuse the name, because it would be less clear which package the doc is for. At any rate, I guess you are suggesting the name libparse-recdescent-perl-doc-nonfree, aren't you? That's what I'd suggest. These are good arguments. Thanks, I will call the package like that. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
* Russ Allbery [EMAIL PROTECTED] [2005-09-15 12:16]: Bas Wijnen [EMAIL PROTECTED] writes: Doc packages are usually called package-doc. I see no reason to change that here, except that adding non-free seems to make sense. Removing lib would just confuse the name, because it would be less clear which package the doc is for. I prefer -tutorial to -doc in this particular case, since otherwise when browsing the package list I'd think I'd have to install the -doc package to get any documentation at all (rather than just a separate tutorial). This is a sensible suggestion but, since you did not Cc: it to me as I requested in my first post, it came too late. The package is already uploaded with the name libparse-recdescent-perl-doc-nonfree. It's too bad, because I would had 3rd place in the longest-package-name contest in Debian, only behind libbusiness-onlinepayment-bankofamerica-perl and libbusiness-onlinepayment-authorizenet-perl. Perhaps I can find a way to upload libbusiness-onlinepayment-bankofamerica-perl-tutorial-nonfree? :-) -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#234942: tipa: /var/lib/dpkg/info/tipa.prerm
package tipa tags 234942 + help thank * Jan Behrend [EMAIL PROTECTED] [2004-09-03 14:26]: Package: tipa Version: 1:1.1.beta-3 Followup-For: Bug #234942 Hi, I think this bug is due to the following line in /var/lib/dpkg/info/tipa.prerm: /usr/bin/defoma-font purge-all-all $FILE this should say /usr/bin/defoma-font purge-all $FILE Thank you for the followup on this. I am Cc:ing this reply to debian-mentors because I do not know exactly what I have to do. Please Cc: any followup to [EMAIL PROTECTED] (as set in Reply-To:). Your suggestion was already implemented over two years ago, as per the following changelog.Debian entry: tipa (1:1.1.beta-4) unstable; urgency=low * debian/rules: Remove hack for fixing the code from prerm-defoma-hints. The prerm script contains now purge-all and not purge-all-all. (This closes: #145519, thanks to Gerfried Fuchs [EMAIL PROTECTED]). -- Rafael Laboissiere [EMAIL PROTECTED] Thu, 2 May 2002 22:02:23 +0200 The problem is that tipa has version version 1:1.1.beta-3 in woody (i.e. the fix above came too late). Furthermore, the sarge version of the package contains the following fix: tipa (2:1.1-2) unstable; urgency=low * Moved the defoma-hints file to the xfonts-tipa package. It was erroneously associated with the tipa package, and was causing nasty warnings when abiword-common was installed with tipa but without xfonts-tipa (closes: #161076). Thanks to Ian Zimmerman [EMAIL PROTECTED]. -- Rafael Laboissiere [EMAIL PROTECTED] Tue, 17 Sep 2002 08:11:53 +0200 I think that I have messed too much with the prerm scripts of bothe the tipa and the xfonts-tipa packages. Unfortunately, fixing things right now is far beyond what I can afford from my free time budget. Please, help me. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#234942: tipa: /var/lib/dpkg/info/tipa.prerm
package tipa tags 234942 + help thank * Jan Behrend [EMAIL PROTECTED] [2004-09-03 14:26]: Package: tipa Version: 1:1.1.beta-3 Followup-For: Bug #234942 Hi, I think this bug is due to the following line in /var/lib/dpkg/info/tipa.prerm: /usr/bin/defoma-font purge-all-all $FILE this should say /usr/bin/defoma-font purge-all $FILE Thank you for the followup on this. I am Cc:ing this reply to debian-mentors because I do not know exactly what I have to do. Please Cc: any followup to [EMAIL PROTECTED] (as set in Reply-To:). Your suggestion was already implemented over two years ago, as per the following changelog.Debian entry: tipa (1:1.1.beta-4) unstable; urgency=low * debian/rules: Remove hack for fixing the code from prerm-defoma-hints. The prerm script contains now purge-all and not purge-all-all. (This closes: #145519, thanks to Gerfried Fuchs [EMAIL PROTECTED]). -- Rafael Laboissiere [EMAIL PROTECTED] Thu, 2 May 2002 22:02:23 +0200 The problem is that tipa has version version 1:1.1.beta-3 in woody (i.e. the fix above came too late). Furthermore, the sarge version of the package contains the following fix: tipa (2:1.1-2) unstable; urgency=low * Moved the defoma-hints file to the xfonts-tipa package. It was erroneously associated with the tipa package, and was causing nasty warnings when abiword-common was installed with tipa but without xfonts-tipa (closes: #161076). Thanks to Ian Zimmerman [EMAIL PROTECTED]. -- Rafael Laboissiere [EMAIL PROTECTED] Tue, 17 Sep 2002 08:11:53 +0200 I think that I have messed too much with the prerm scripts of bothe the tipa and the xfonts-tipa packages. Unfortunately, fixing things right now is far beyond what I can afford from my free time budget. Please, help me. -- Rafael
Help interpreting buildd log
Hi, I need some help in interpreting the buildd logs. I am looking at: http://buildd.debian.org/fetch.php?pkg=plplotver=5.2.1-1arch=sparcstamp=1051000387file=logas=raw and there is an apt-get error: Sorry, but the following packages have unmet dependencies: libgd2-dev: Depends: libgd2-noxpm-dev (= 2.0.4-2) but it is not going to be installed or libgd2-xpm-dev (= 2.0.4-2) but it is not going to be installed However, when I look at the packages pool, I see in: http://ftp.debian.org/debian/pool/main/libg/libgd2/ both packages: libgd2-noxpm-dev_2.0.12-1_sparc.deb 14-Apr-2003 05:32 274k libgd2-xpm-dev_2.0.12-1_sparc.deb 14-Apr-2003 05:32 275k What is going on? -- Rafael
Re: Help interpreting buildd log
* James Troup [EMAIL PROTECTED] [2003-04-23 13:18]: Rafael Laboissiere [EMAIL PROTECTED] writes: What is going on? Some cunning stunt of a genius SNAFUed libpng again; it's not your package's problem. Thanks for your reply. I see that the libpng situation is quite messy. Ny PLplot packages are now build-depending on libpng2-dev | libpng3-dev (this is old stuff). In unstable, I see: $ dpkg -l libpng\*-dev | grep libpng un libpng-dev none (no description available) un libpng1-devnone (no description available) pn libpng12-0-dev none (no description available) ii libpng12-dev 1.2.5.0-1 PNG library - development un libpng2-devnone (no description available) ii libpng3-dev1.2.5.0-1 PNG library - development, compatibility pac Which one(s) should I build-depend on? -- Rafael
Help with Bug #58648
Hi, I am in desperate need of help to fix Bug #58648. As I cannot replicate it (that would imply having a slink box to be upgraded to potato), and as I am a little bit confused about section 8.5 of the Packaging Manual, I need some enlightenment here. The problem seems to be caused by the way I split the slink prcs package into the potato packages prcs and prcs-el. I moved the Emacs addon support from potato prcs into prcs-el. Of course, I declared Conflicts: prcs ( 1.2.15-1) in prcs-el, but this does not seem to be sufficient. From the bug report, it seems also that during the upgrade of xemacs20, the prcs.elc file disappeared, but the file 50prcs.el was still there. Any help will be appreciated. Thanks, -- Rafael Laboissière [EMAIL PROTECTED]
Re: Help with Bug #58648
[I am Cc:ing to debian-mentors. Hope that does not bother you.] On Mon, Apr 10, 2000 at 03:02:21AM -0700, Seth R Arnold wrote: Could you change the Suggests: prcs-el to Recommends: prcs-el? I forget how apt handles each of these... One way to fix the upgrade-specific problem would be to include a Depends: on prcs-el, but this will likely upset quite a few people that don't actually have to do the upgrade.. :) I much prefer the Suggests: prcs-el. The other options sound too authoritarian for me. Another thought -- could you have in the preinst for prcs some commands that would delete the prcs.elc and 50prcs.el files from the path that xemacs20 plays with? I also think that this will fix the problem. I will try that. Thanks. It would seem to me that this would be the thing to do; if the user wanted the emacs stuff, they would install prcs-el. If they don't want, then prcs should trash it. Right. (But it might be a good idea for prcs to check if prcs-el is already installed before deleting files. :) There is no danger here, as the files have different names: 50prcs.el for the prcs package and 50prcs-el.el for prcs-el. -- Rafael Laboissiere [EMAIL PROTECTED]
PRCS users
I finally found time to upload an upgraded prcs package. I did mass bug-hunting, closing seven of them. I hope that I did not introduce even more than that with my fixes! I am actually writing to tell that I decided on my own to split the package into prcs and prcs-el, the second containing ELisp support and an explicity dependency on the virtual package emacsen. I am afraid I have had to discuss that in this mailing list before doing the actual upload. Anyway, the new version (1.2.14-1) is already in the incoming directory of master. Enjoy, -- Rafael Laboissiere [EMAIL PROTECTED] Institut de la Communication Parlee / INP Grenoble, France http://www.icp.inpg.fr/~rafael
Upgrading the Standards-Version
Is there any simple way to decide if a package is eligible for Standards-Version upgrading, without checking every detail of the Policy? Is a Lintian check enough? [Cc to me, please.] -- Rafael Laboissiere, Debian developer
Re: keyword=value in debian/changelog
Thanks for you reply, Joey. MS == Martin Schulze [EMAIL PROTECTED] writes: MS Speaking of me, I have special rules so I don't have to close MS bug reports on my own, it's all done by some scripts that run MS automatically, both during upload and and after installation. MS Check out bugs against my packages for reference. MS So yes, it is an undocumented feature. It is a preview of a MS feature of dinstall (as run on master) that will talk to the bug MS tracking system itself. Since I don't want to wait that long, I MS modified some local tools. In the meanwhile the feature is not yet implemented, could you, please, package your mentioned scripts for the benefit of all of us? Regards, -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
Re: keyword=value in debian/changelog
MS == Martin Schulze [EMAIL PROTECTED] writes: MS Uff. What name would you propose? I will consist of four MS dpkg-divert statements. MS All files are found at MS ftp://ftp.infodrom.north.de/pub/people/joey/auto-close-dpkg/ You have already a name: auto-close-dpkg. What is wrong with it? Rafael
NMU: Incompatibility between dpkg-dev and developers-reference
I am building a package for a NMU based on a new upstream release. Section 5.5 of the developers-reference manual states: If it is absolutely necessary for someone other than the usual maintainer to make a release based on a new upstream version then the person making the release should start with the debian-revision value 0.1. When I use a debian-revision 0.1, information about the .orig.tar.gz is _not_ included in the .changes file. This means that my upload will be rejected (because it is a matter of a new upstream release). On the other hand, when I use a debian-revision equal to 0, everything works fine. I suppose that some script in dpkg-dev works incompatibly with the instructions in developers-reference. Any help/patch/comments? -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
Re: NMU: Incompatibility between dpkg-dev and developers-reference
MS == Martin Schulze [EMAIL PROTECTED] writes: MS Rafael Laboissiere wrote: [...] I suppose that some script in dpkg-dev works incompatibly with the instructions in developers-reference. Any help/patch/comments? MS Help: Simply upload the orig.tar.gz manually. Thanks, this is what I was going to do. But I am wondering: can this work? Will the installation program in master take care of a file that is not mentioned in .changes? BTW, Samuel Tardieu told me that he just filled a bug report against dpkg-dev WRT this problem. -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
keyword=value in debian/changelog
I have seen debian/changelog files in some packages in which the keyword `closes' is set at the first line of new entries. However, the packaging-manual (version 2.4.1.2, section 3.2.3) states that: urgency is the value for the Urgency field in the .changes file for the upload. See Urgency, subsection 4.2.15. It is not possible to specify an urgency containing commas; commas are used to separate keyword=value settings in the dpkg changelog format (though there is currently only one useful keyword, urgency). ^^ Is the `closes' keyword some new useful, undocumented feature of the packaging/uploading system or are the maintainers just using it to highlight which bugs were closed? -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
Moving from experimental to non-free
How do I move a package from experimental to non-free, I mean, what do I have to change in the changelog file? Can I keep the same version number, or do I have to increment it? [FWI, I am trying to get the tipa package (that was stuck in experimental for a while) into slink before it freezes.] Thanks, -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
name of changes file
I am building my architecture independent packages with debhelper. As the field Architecture: of the control file has value all, the deb files are named *_all.deb (as expected). On the other hand, I always get .changes files with *_i386. Is this normal and/or problematic for the upload? -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
