Re: In-Program documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: It's a little known requirement that packages continue to work after /u/s/doc is removed. So it's not allowed to install required files there. You could do (2) or (3) with links *from* u/s/d though. Well, the program will not stop working. Just a little percentage of the functions available will not work (help and license). But anyways: So you would say that I should do it the other way round? Say: Install the files to /usr/share/password-gorilla and then link them to usr/share/doc? Justin Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3clPTKIzE6LY9r8RAqMnAJ92JLRDcvqlGshIAJW0U8jdktoxFwCfU62I pLcns7rWoRjbZkvK6xcYfkM= =8ien -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan C. Nordholz wrote: Why should I try to hide the normal course of development? I don't see I agree that this *is* suboptimal. But it should not be part of normal development cycle to create extra revisions that you do not release, should it? IMHO it makes sense for some developer-only changelog, but the debian/changelog has gotten a file, which is shown to the users often and it might seem odd to them if versions therein do not exist. the necessity to create extra loops (reformatting the changelog after each intermediate package creation that is not uploaded) for me to jump Well you are right in this point. But I seem to develope my packages in another way then you. Cause i only start a new changelog entry, if i really uploaded something through my sponsor to the archive. Hm, hard to tell. Oh, and for more real-world examples... Yeah yeah. I think you are right if you say, that it *is* used and that its okay to be used (even though i don't agree with it), but i would not recommend it either, cause I think there are a lot of sponsors that just will not upload such packages. This opinion results from the fact, that I have seen more people criticizing multiple changelog entries/versions for just a single release, then people that say that it is okay. - -Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Ft5TKIzE6LY9r8RAu3qAKCM3OKsROlvo/OU7nkjr/HnFDoO7gCfazg/ PcJpWBo4fjf4hwaz6aIx6/o= =wdo7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mantis (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a (one-time) sponsor for the new version 1.0.8-1 of my package mantis, as it seems that the person who sponsors my uploads normally is not available. It builds these binary packages: mantis - web-based bug tracking system The package appears to be lintian clean. The upload would fix these bugs: 428159, 429787, 429791, 429960, 430069, 430109, 430145, 430182, 431151, 431213, 431217, 431254, 431280, 433050 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/m/mantis - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/m/mantis/mantis_1.0.8-1.dsc I would be glad if someone uploaded this package for me. I am not subscribed to the list, so please CC me. Kind regards Patrick Schönfeld -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1QTwTKIzE6LY9r8RAorZAJ0Y2+XYGps+8AeHQCe1LuGUA6+wvACeKDH7 FxcwgL7KPh46t5GN7YvIFkE= =nurg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/prerm is executed on *reconfigure*? (solved)
schönfeld / in-medias-res.com schrieb: Hi mentors, hi Dpkg developers, Okay, this problem is solved, thanks to Justin Pryzby and Michael Biebl. Thanks to you. To all the others reading this list: I can really really recommend the link at debian women wiki Michael posted. For packaging beginners like many on this list (and I) are this link is an awesome explanation of how maintainer scripts are called. Really great, absolutetly worth the recommendation. Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: crotch
Hi, haven't known that you are the author, so some things are different: Chris Amthor schrieb: Hi Patrick, [EMAIL PROTECTED] wrote: [...] IANADD so i cannot upload it for you, No problem. but anyways some comments. Hope they help you. Yes, they helped, though I still have some questions left. Thank you very much! Since this is my first attempt to get a package into Debian, any advice is more than appreciated. Especially the technical parts were indeed helpful. The main part I still do not get is that upstream/author/URL thing. I wrote the C code, I wrote the Makefile, I invented the name and I built the packages for i386, powerpc and sparc. The only official sources for crotch are my webserver and my fileserver. Okay, so *you* are upstream. So ask yourself the question: Do you intend to publish it *only* in Debian (personally I think there is no good reason for that)? If not, you may/should provide a website, on which others can download the software, too. Then you would include this homepage in the apppropriate places of your package and provide a proper orig tarball, a debian diff, etc. But you even have it easier, cause you can change your original source, e.g. regarding the install process instead of rewriting it in debian/rules or helping out with patches. So why do I have to make a difference between the packager, the maintainer, the author? The URL I got the sources for building the packages was: file:///mnt/nfs/Develop/C/crotch/crotch-1.0.1/, that cannot be of any use if I mention it in the package. Btw. you do not have to make a difference between the packager/maintainer/author but you should tell at the right places who it is. See above comments. But I'll go through my questions one by one: [...] - public-key-file: What is it for? As far as I see, you don't package it, so why should you need to include it? Well, dput refused to upload the unsigned package. So I took my GPG key and things worked. Which point did I miss? Well, but for signing your .changes files you do not need to carry your key with the package. Indeed it must not be there. - Your package does not include a manpage for a binary. Thats not an 'error', but is highly recommended and the fact that there is none, results in a lintian warning. Ahem, correct. That's for two reasons: firs crotch only understands two arguments, no options in only uses STDIN and STDOUT, therefore I thought I could omit a manpage. Second, I do not know how to write manpages... :o( Okay, so it does not have much to say in the man. But users might ask the man first if they want to know, which parameters your software has. Also: You can include an information about you as the AUTHOR and informations about how they can provide bugreports. About writing of man pages. It is easier then writing applications. Just open up an existing manpage in an editor and look at it. On the first sight it might look a little bit obscure, but it isn't. Even I am able to write manpages (but I cannot code much C) [...] You could fix warnings yourself with patches or ask upstream to do so. In every case you may want to inform the upstream author. So I have to inform myself? Isn't the upstream my upload itself, hence me the author? Haha. Ofcourse you don't need to inform yourself. But you can fix it in upstream source ;-) Why should I let others see that I'm packaging S/W that nobody knows of? Everyone that already has got the software could ether get the source tarball or a package, so why should anyone go repackage it? Or is there a general difference in the procedure of getting bugfixes upoloaded than getting initial packages uploaded? Not really. An ITP is a bugreport on bugs.debian.org which is handled a bit different. Say: It is listed on the WNPP page [1]. But you are right. If nobody yet knows that your software exists you don't need to WNPP. * debian/compat: - Your compatibility level is 4, but thats old. Instead you may want to use the current level 5. Hmm, with level 5 dpgk-buildpackage failed for some reason. I think I'll have to check this once again. Have a look at man debhelper. It lists the differences between the different compat levels. Anyways, thanks for your help and best regards, You're welcome. Best Regards Patrick [1] http://www.debian.org/devel/wnpp/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Subject: RFS: mantis (updated package)
Hi there, i have removed the targets from the makefile and instead added a line: include /usr/share/dpatch/dpatch.make Also i modified (one of) the patches in this kind: 1. Remove the inclusion of DPATCH and the exit line 2. Changed shebang to run /bin/sh with /usr/share/dpatch/dpatch-run Well now it does not run. Instead it says: applying patch 01-use-debian-version-of-adodb to ./ ... can't find file to patch at input line 10 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |#!/bin/sh /usr/share/dpatch/dpatch-run |## 01-use-debian-version-of-adodb.dpatch by Patrick Schönfeld [EMAIL PROTECTED] |## |## DP: Modified mantis so it uses the debian version of libphp-adodb, instead |## DP: of a mantis-supplied one | |@DPATCH@ |--- core/database_api.php.bak 2006-11-23 09:41:12.0 +0100 |+++ core/database_api.php 2006-11-23 09:41:32.0 +0100 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored Daniel Baumann schrieb: ..which could be removed then when including dpatch.make I am a bit irritated by this information, because dpatch(7) states: The only requirement is that it MUST accept the -patch and -unpatch options, followed by the destination (or working) directory, when specified. Any ideas? Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Subject: RFS: mantis (updated package)
Daniel Baumann schrieb: schönfeld / in-medias-res wrote: Well now it does not run. Instead it says: can i see your sources? Here you are: http://just-imho.net/~schoenfeld/debian-devel/mantis-1.0.6.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]