Re: In-Program documentation

2007-09-04 Thread schönfeld / in-medias-res
-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

2007-09-03 Thread schönfeld / in-medias-res
-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)

2007-08-28 Thread schönfeld / in-medias-res
-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)

2007-03-20 Thread schönfeld / in-medias-res

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

2007-01-24 Thread schönfeld / in-medias-res

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)

2006-11-28 Thread schönfeld / in-medias-res

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)

2006-11-28 Thread schönfeld / in-medias-res

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]