Re: executable scripts in debian/
On Saturday 25 October 2008 03:59:31 Paul Wise wrote: Everyone should note that with dpkg-source v3 this problem goes away since foo_1.2-1.diff.gz becomes foo_1.2-1.debian.tar.gz. This will become usable for uploads after lenny is released, so get cracking on those RC bugs! Is there a site/README were I can read more about that upcoming changes? Regards, Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: executable scripts in debian/
On Sat, Oct 25, 2008 at 3:56 PM, Robert Wohlrab [EMAIL PROTECTED] wrote: Is there a site/README were I can read more about that upcoming changes? Search for Format: 3.0 (quilt) in the dpkg-source manual page: http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-source As for when this format will be accepted, after lenny and as soon as the ftp-masters have implement any needed changes in dak and enabled acceptance of the new format. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fig2sxd
Hi, ... Debian changelog, not upstream ... Hmm. I do not have an upstream changelog, and all previous debian/changelog entries have the same problem. So what would you suggest to do: * Move all debian/changelog entries actually describing upstream changes to a new upstream-changelog and replace it with new upstream version for all upstream versions (0.1 -- 0.19) in debian/changelog? * Keep the existing debian/changelog entries and start the upstream changelog now? And, as adding a new upstream changelog would mean that the orig.tar.gz changes: * Fix it in the next version (0.20) once there are upstream code changes? * Fix it now, keep version 0.19 and hide the new upstream changelog until 0.20-1? * Add the new upstream changelog via debian's diff.gz? That seems odd. * Make 0.20 and 0.20-1. What would then be the upstream changelog entry? ... currently in freeze... If there is an important problem ... ..0.18-1 .. in testing, it is easier to fix it if you can push the fix to unstable without pushing additional changes. Otherwise, it would have to be uploaded to testing-proposed-updates which causes more work for everybody and less possibilities of testing (no grace period to ensure that a few people test the package). However, the change is not very large (especially if we ignore indentation changes), so in case a fix needs to be pushed, maybe this new upstream version would be accepted as well. Therefore, it is up to you to upload to unstable (if you think that having a RC bug filed against fig2sxd is low probability and even if there is one, the current change is likely to be accepted) or to experimental. Do you want to suggest making the same changes in diff.gz and call it 0.18-2? Probably I do not understand what you actually ask here. For some people who want to convert huge polylines (the one in the bug report had 5500 points) it is certainly helpful -- without, the program output is correct but unusable. The problem is caused by a bug in OOo (their bug #95095) which makes OOo read some files generated by fig2sxd (or whatever other program producing OOo files) incorrectly. The ideal solution would be to fix the OOo problem and stay with fig2sxd 0.18. Otherwise I think 0.19 should be used in testing, but I do not expect that this is fast (that's also why I implemented the workaround). It will continue to work the OOo problem is fixed, and I would not like to have the program with a known problem in a stable release. As you say, the actual changes between 0.18 and 0.19 are minor. I could also make 0.20, where I would fix the changelog problem and add a few (around 4) lines to print out a warning for the cases without workaround (i.e. filled polylines/polygons). Best wishes, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fig2sxd
OoO En cette fin de matinée radieuse du samedi 25 octobre 2008, vers 11:07, Alexander Bürger [EMAIL PROTECTED] disait : ... Debian changelog, not upstream ... Hmm. I do not have an upstream changelog, and all previous debian/changelog entries have the same problem. So what would you suggest to do: * Move all debian/changelog entries actually describing upstream changes to a new upstream-changelog and replace it with new upstream version for all upstream versions (0.1 -- 0.19) in debian/changelog? * Keep the existing debian/changelog entries and start the upstream changelog now? And, as adding a new upstream changelog would mean that the orig.tar.gz changes: * Fix it in the next version (0.20) once there are upstream code changes? * Fix it now, keep version 0.19 and hide the new upstream changelog until 0.20-1? * Add the new upstream changelog via debian's diff.gz? That seems odd. * Make 0.20 and 0.20-1. What would then be the upstream changelog entry? No, no, you don't have to maintain yourself upstream changelog (you = as Debian package maintainer). I just point the fact that you put, in debian/changelog, an entry that looks like an upstream changelog entry. From a Debian point of view, the change is New upstream release. This is not really important here since there is only on entry but if you add 3 features in the next version, you don't have to list them in debian/changelog. debian/changelog is the place to tell which bug is closed and what changes have happened in the packaging. ... currently in freeze... If there is an important problem ... ..0.18-1 .. in testing, it is easier to fix it if you can push the fix to unstable without pushing additional changes. Otherwise, it would have to be uploaded to testing-proposed-updates which causes more work for everybody and less possibilities of testing (no grace period to ensure that a few people test the package). However, the change is not very large (especially if we ignore indentation changes), so in case a fix needs to be pushed, maybe this new upstream version would be accepted as well. Therefore, it is up to you to upload to unstable (if you think that having a RC bug filed against fig2sxd is low probability and even if there is one, the current change is likely to be accepted) or to experimental. Do you want to suggest making the same changes in diff.gz and call it 0.18-2? Probably I do not understand what you actually ask here. No. I say that uploading in unstable a version that will never go in testing because of the freeze would put some difficulties on you if you need to upload a fix (a small fix that would be 0.18-2 for example). If you think that this fix is important enough to go in Lenny, you should ask on debian-release@ the permission to upload this new version and let it migrate to testing. Provide a debdiff (with -w in your case, otherwise, there is too much changes). -- I AM SO VERY TIRED I AM SO VERY TIRED I AM SO VERY TIRED -+- Bart Simpson on chalkboard in episode AABF20 pgp0xW7uMrpuX.pgp Description: PGP signature
Re: RFS: fig2sxd
On Sat, Oct 25, 2008 at 12:15:52PM +0200, Vincent Bernat wrote: OoO En cette fin de matin?e radieuse du samedi 25 octobre 2008, vers 11:07, Alexander B?rger [EMAIL PROTECTED] disait : ... Debian changelog, not upstream ... Hmm. I do not have an upstream changelog, and all previous debian/changelog entries have the same problem. So what would you suggest to do: * Move all debian/changelog entries actually describing upstream changes to a new upstream-changelog and replace it with new upstream version for all upstream versions (0.1 -- 0.19) in debian/changelog? * Keep the existing debian/changelog entries and start the upstream changelog now? And, as adding a new upstream changelog would mean that the orig.tar.gz changes: * Fix it in the next version (0.20) once there are upstream code changes? * Fix it now, keep version 0.19 and hide the new upstream changelog until 0.20-1? * Add the new upstream changelog via debian's diff.gz? That seems odd. * Make 0.20 and 0.20-1. What would then be the upstream changelog entry? No, no, you don't have to maintain yourself upstream changelog (you = as Debian package maintainer). But he is also the upstream maintainer :) That's where his confusion comes from - he is asking how to combine the idea of an upstream changelog with the idea of a Debian changelog :) Let's start with the disclaimer that I am not a Debian developer :) Alexander, IMHO the best thing you could do in this particular case is, indeed, to release a new upstream version, 0.20, with a changelog included, and then package it for Debian with a New upstream release log for that particular version. The changelog you put in the 0.20 upstream tarball should include all the changes for previous releases - maybe just copied over from the Debian changelog. This will be useful to others who try to use fig2sxd on other OS's, not just Debian :) After you release the 0.20 upstream version of fig2sxd, make a new Debian package for 0.20-1. If there were other changes you did *to the Debian packaging* in the 0.19-1 version that this RFS is for (it seems you bumped Standards-Version at least), you may keep that changelog entry - though there are Debian developers who would frown upon changelog entries for versions that have never been uploaded, there are others who like the idea of keeping track of the changes one at a time. However, if you decide to keep the 0.19-1 Debian changelog entry, you should remove the actual description of the upstream changes and replace it with New upstream version. IMHO it might be better to just skip 0.19-1 in the Debian changelog - change the top line to fig2xsd (0.20-1) so that it seems that you made the changes there :) And, IMHO, no, you should not modify earlier Debian changelog entries! Just leave them as they are - yes, there will be some duplication between the upstream and the Debian changelogs now, but in time, with new upstream versions of fig2sxd, it will become insignificant. Again, all of this is just my opinion, and IANADD :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpaIV9rN7dOK.pgp Description: PGP signature
Re: RFS: jigzo
Hi, I am not a Debian developer, but I noticed a few things about your package: On Fri, Oct 24, 2008 at 10:29 PM, Elías A. M. [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for my package jigzo. First, your package is not lintian clean: W: jigzo source: patch-system-but-direct-changes-in-diff makeinclude.linux I: jigzo: arch-dep-package-has-big-usr-share 4284kB 97% I: jigzo: desktop-entry-contains-encoding-key /usr/share/applications/jigzo.desktop:4 Encoding Here is the diff problem (the rest are information points, which are worth fixing but not critical): --- jigzo-0.6.1.orig/makeinclude.linux +++ jigzo-0.6.1/makeinclude.linux @@ -5,6 +5,6 @@ CC = gcc STRIP = strip APP = jigzo -ARCHLDFLAGS = -lpthread -lGL -lpthread -lpng -ljpeg -lSDL -lSDL_mixer +ARCHLDFLAGS = -lpthread -lGL -lpthread -lpng -ljpeg -lSDL -lSDL_mixer ARCHCXXFLAGS = -I/usr/include/SDL Second, your debian/rules file could use some cleaning. You have configure in the .PHONY, but no configure target in the file. You also should remove the commented dh_* lines--they just add cruft to the diff. Third, although your package builds fine in a chroot, it does not build with fglrx installed on my machine. I'm not sure if this is a problem: dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by fglrx-glx from: /usr/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by fglrx-glx to: /usr/lib/fglrx/diversions/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by fglrx-glx from: /usr/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by fglrx-glx to: /usr/lib/fglrx/diversions/libGL.so.1.2 dpkg-shlibdeps: failure: no dependency information found for /usr/lib/libGL.so.1 (used by debian/jigzo/usr/games/jigzo). dh_shlibdeps: command returned error code 512 make: *** [binary-arch] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 Cheers, -- Daniel Moerner [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: drobo-utils
Hi all, I am looking for a sponsor for my package drobo-utils. * Package name: drobo-utils Version : 0.3.2-1-1 Upstream Author : Peter Silva [EMAIL PROTECTED] * URL : http://drobo-utils.sourceforge.net/ * License : GPLv3 Section : python It builds these binary packages: drobo-utils - manage data robotics storage units (drobos) The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/drobo-utils - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/drobo-utils/drobo-utils_0.3.2-1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Chris AtLee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: drobo-utils
Hi Chris, On Sat, Oct 25, 2008 at 19:42, Chris AtLee [EMAIL PROTECTED] wrote: Hi all, I am looking for a sponsor for my package drobo-utils. I'll give it a look at the package, taking the code from PAPT svn repo. Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mod-spamhaus
Dear mentors, I am looking for a sponsor for my package mod-spamhaus. * Package name: mod-spamhaus Version : 0.5-1 Upstream Author : Luca Ercoli [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/mod-spamhaus/ * License : GPL Section : web It builds these binary packages: libapache2-mod-spamhaus - Apache DNSBL module that deny access to a known bad IP address The package appears to be lintian clean. The upload would fix these bugs: 503395 What's mod_spamhaus === mod_spamhaus is an Apache module that use DNSBL in order to block spam relay via web forms, preventing URL injection, block http DDoS attacks from bots and generally protecting your web service denying access to a known bad IP address. It take advantage of the Spamhaus Block List (SBL) and the Exploits Block List (XBL) querying sbl-xbl.spamhaus.org Spamhaus's DNSBLs are offered as a free public service for low-volume non-commercial use. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mod-spamhaus - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mod-spamhaus/mod-spamhaus_0.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Giuseppe Iuculano signature.asc Description: OpenPGP digital signature
howto create debian package with conf files
Hello, I would like to create a debian package for a simple project that I've created. The project contains only scripts, so there is no makefile or anything like that. For the script to work I would like to prompt for some simple questions like what url should be used, what organisation does this computer belong to. I've created a postinst script that asks these questions and writes them in a configuration file. (and this configuration file is listed in conffiles) Now the problem that I have is that when I reinstall this package, or upgrade it, all the questions are asked again. After some research I'm still not able to find a simple example or howto to do this right. - Is it necessary to use debconf to accomplish this? - I thought that the postinst script was called with an argument install/upgrade/configure and so I could ask my question only when it was and install or configure, but this doesnt work. apperantly upgrading a package also uses argument configure... I've tried to look at packages like postfix, to see how they do it, but those are to difficult for my simple scripting skills :-( Regards, Luke
Re: howto create debian package with conf files
On Sat, Oct 25, 2008 at 11:21:19PM +0200, lucas kenter wrote: I would like to create a debian package for a simple project that I've created. The project contains only scripts, so there is no makefile or anything like that. For the script to work I would like to prompt for some simple questions like what url should be used, what organisation does this computer belong to. I've created a postinst script that asks these questions and writes them in a configuration file. (and this configuration file is listed in conffiles) Now the problem that I have is that when I reinstall this package, or upgrade it, all the questions are asked again. After some research I'm still not able to find a simple example or howto to do this right. - Is it necessary to use debconf to accomplish this? I'm not sure if Policy mandates using Debconf, but since this sounds like it's a local-only package, you don't need to follow policy anyway. I'd certainly *recommend* using debconf, though, as it provides both a standardised interface for the asking and answering of questions, a way to avoid re-asking questions, and also an easy means of automating the answering of the questions with preseeding, should you wish to do so in the future. - I thought that the postinst script was called with an argument install/upgrade/configure and so I could ask my question only when it was and install or configure, but this doesnt work. apperantly upgrading a package also uses argument configure... The postinst is called with the configure argument to say please configure the package that has just been installed, whether or not that installation is a new one or an upgrade. What might be of use to you is the fact that the second argument to the postinst call is the previous version that was fully configured. So you could do something like this in your postinst: if [ $1 = configure -a $2 = ]; then # Ask your questions fi Because the only time that the second argument will be empty is on the initial install -- after that, $2 will always contain the previously configured version. I've tried to look at packages like postfix, to see how they do it, but those are to difficult for my simple scripting skills :-( I don't know if the 'hello' package has any debconf in it, but it's usually considered the canonical how to get started package. Otherwise, I can't think of any specific packages that are good examples of the debconf art, but I know that MTAs in general are far too complex to make good examples for new packagers. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: howto create debian package with conf files
Wow, Thanks for the quick and helpfull response Matthew and ehm... I suppose this is what they mean by Debians helpfull community! I'm possitively amazed! :-D one more question though, So you could do something like this in your postinst: if [ $1 = configure -a $2 = ]; then # Ask your questions fi Because the only time that the second argument will be empty is on the initial install -- after that, $2 will always contain the previously configured version. Would this still allow users to issue a dpkg-reconfigure? And never heard of the hello package, but I will install it right away :-) Regards, Luke
Re: howto create debian package with conf files
On Sun, Oct 26, 2008 at 12:10:26AM +0200, lucas kenter wrote: Wow, Thanks for the quick and helpfull response Matthew and ehm... I suppose this is what they mean by Debians helpfull community! I'm possitively amazed! :-D one more question though, So you could do something like this in your postinst: if [ $1 = configure -a $2 = ]; then # Ask your questions fi Because the only time that the second argument will be empty is on the initial install -- after that, $2 will always contain the previously configured version. Would this still allow users to issue a dpkg-reconfigure? Now *that* is an interesting question I've never explored. I'll leave that one up to you to test. If you put: echo $* at the top of your postinst, though, and then install, upgrade, and dpkg-reconfigure your package and see what happens... - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: drobo-utils
On Sat, Oct 25, 2008 at 20:44, Sandro Tosi [EMAIL PROTECTED] wrote:
Hi Chris,
On Sat, Oct 25, 2008 at 19:42, Chris AtLee [EMAIL PROTECTED] wrote:
Hi all,
I am looking for a sponsor for my package drobo-utils.
I'll give it a look at the package, taking the code from PAPT svn repo.
[EMAIL PROTECTED]:~/deb/python-apps/drobo-utils$ uscan --report
Processing watchfile line for package drobo-utils...
Newest version on remote site is 0.3.0-1, local version is 0.3.2-1
drobo-utils: remote site does not even have current version
mh, not a good start ;) Works with this line:
http://sf.net/drobo-utils/drobo-utils_(.+)\.tar\.gz
Please, prod the upstream author to remove the debian/ dir from the
upstream tarball (if he wants, can join PAPT and maintain that part in
our repo) and to name the dir in the tarball with the classic
name-ver instead of trunk.
What about merge the 2 entries in debian/changelog? At the end, this
will be the first revision uploaded ;)
Is Peter really the maintainer of this package? I just don't want you
to confuse this field with upstream author: the Maintainer field
contains the person primarly responsable for the *Debian* package, not
the upstream part of the code. Given that all the commits was done by
your user and that This package was debianized by Chris AtLee, I
think that this field has to contain either your name or the team (at
your choice). Oh, please note that I'm fine with Peter being there,
but I just want to be sure you have clear its meaning. :)
What about adding Vcs-{Browser,Svn} and Homepage fields?
Could you please insert the GPLv3 boilerplate in debian/copyright
file? It's enought the usual stuff This program is free software:
What is this The Debian packaging is (C) 2008, informavore
[EMAIL PROTECTED]? Who is the copyright holder for the
packaging (so debian/ dir in PAPT repo I'll upload) (connected to
above)? informavore is for sure wrong ;) Moreover, it's better to
state the same license for both upstream and packaging code, so both
GPLv3 (not clear for the packaging part).
It might be better to refer to GPL-3 file, not to the generic GPL link.
You can merge the rm -f and dh_clean commands in clean target (they
do the same job).
./DroboDMP.c needs better copyright info
what about writing the two manpages (even if minimal) missing (and
submit them upstream)?
Given that python-qt4 is defined as essential in upstream
README.txt, maybe it would be better to have in Depends not
Recommends?
Just wondering, is the Depends on libsgutils1 really needed? I would
expected misc:Depends to introduce it if NEEDED by libs, but that's
not the case, and even a fast inspectoin of .so seems to confirm it:
$ objdump -x lib.linux-i686-2.5/DroboDMP.so | grep NEEDED
NEEDED libpthread.so.0
NEEDED libc.so.6
Both descriptions need a little more attention: reading the
description, I really can't understand what the package does :S For
example you need to clarify what drobos are, what kind of dashboard
is, etc etc (something to give an idea of what the package contains to
guys who know nothing about it (like me)).
I think it's enough for a first check ;) Feel free to contact me in
case of clarification ([EMAIL PROTECTED] for a fast reply) and commit your
changes into PAPT repo (I'd prefer using the same revision, -1), then
get back to me again for another check.
Thanks for your contribution (so far and futurable),
Sandro
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
