Seeking Sponsor(s) for the Emilda Integrated Library System and Related Packages
On 2/5/06, gregor herrmann <[EMAIL PROTECTED]> wrote: > On Sun, Feb 05, 2006 at 11:10:39AM -0600, Gunnar Wolf wrote: > > > I noticed you have also libmarc-record-perl in your > > directory, but didn't upload it (as it might not be ready or > > whatever). > > It is ready from my POV but there is an older ITP: #251875 owned by > David Everly, and Dave told me today that he wanted to proceed with > his packaging efforts. But he is looking for a sponsor too, so maybe > you could take a look at his package? Cc'ing [EMAIL PROTECTED] > > The situation is the same for libnet-z3950-perl; I've made a package > (you might have seen it too) before looking at the wnpp list, and > than found Dave's ITP (#263821) in the BTS. - We would both be glad > of one of our packages made it into the archive. I'm not looking to duplicate any effort here, so if someone else gets sponsored, I am for it, since my goal is not necessarily for ME to get sponsored, but to see Emilda (http://www.emilda.org) go into Debian. Emilda is a complete Integrated Library System that features amongst others an OPAC, circulation and administration functions, Z39.50 capabilities and 100% MARC compatibility. MARC compatibility is achieved using Zebra in conjunction with MySQL. To that end I have outstanding ITPs filed for Emilda and all packages that Emilda requires that are not currently in Debian Sarge/Stable. They are all lintian clean. These binary and source packages are available at: http://users.adelphia.net/~david.everly/emilda/sarge/ So I am still looking for sponsors please. Here are the ITPs: # #263826: ITP: emilda -- Web Based Integrated Library System Package: wnpp; Severity: wishlist; Reported by: [EMAIL PROTECTED]; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. # #263830: ITP: idzebra -- High-performance, text indexing and retrieval engine Package: wnpp; Severity: wishlist; Reported by: [EMAIL PROTECTED]; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. # #263831: ITP: libgd-barcode-perl -- Create barcode image with GD Package: wnpp; Severity: wishlist; Reported by: [EMAIL PROTECTED]; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. # #263832: ITP: libhtml-htmldoc-perl -- Perl interface to the htmldoc program for producing PDF-Files from HTML-Content Package: wnpp; Severity: wishlist; Reported by: [EMAIL PROTECTED]; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. # #263833: ITP: php4-yaz -- PHP/YAZ Z39.50 Module Package: wnpp; Severity: wishlist; Reported by: [EMAIL PROTECTED]; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. # #251875: ITP: libmarc-record-perl -- Perl extension for handling MARC records Package: wnpp; Severity: wishlist; Reported by: gregor herrmann <[EMAIL PROTECTED]>; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 251 days old. # #263821: ITP: libnet-z3950-perl -- Perl extension for talking to Z39.50 servers Package: wnpp; Severity: wishlist; Reported by: gregor herrmann <[EMAIL PROTECTED]>; Owned by: [EMAIL PROTECTED]; Tags: patch; 1 year and 184 days old. Thanks, Dave. -- ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html
Re: RFS: libmarc-perl -- Perl extension to manipulate MAchine Readable Cataloging records
On Thu, Feb 23, 2006 at 04:32:13PM +0100, Krzysztof Krzyzaniak wrote:
> gregor herrmann wrote:
> > On Tue, Feb 21, 2006 at 12:57:01PM -0600, Gunnar Wolf wrote:
> >
> >>> I just wanted to ask if you have found the time to take a second look
> >>> at libmail-gnupg-perl, libmarc-perl, and libnet-amazon-perl [0] (or
> >>> Dave's Emilda packages [1]). I guess at least the former just need a
> >>> dpkg-buildpackage -sa; {dput,dupload} :-)
> >> Sorry, I haven't been able to look at your packages - Too tied up with
> >> lots of other things :(
> >
> > No problem, thanks for your help anyway!
> >
> >> But this is a good place to find sponsors.
> >
> > We'll, let's see if someone else steps up ;-)
>
> Would be easier if packages were in pkg-perl repository.
How does one make this happen?
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/
ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html
signature.asc
Description: Digital signature
ignoring upstream debian directory
Hi, Is there some mechanism or alternative for using uupdate so that any upstream debian directory can be removed before patching? Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory
On Thu, Oct 28, 2004 at 02:35:07PM -0400, Justin Pryzby wrote: > On Thu, Oct 28, 2004 at 07:21:23PM +0200, Santiago Vila wrote: > > On Thu, 28 Oct 2004, David Everly wrote: > > > > > Is there some mechanism or alternative for using uupdate so that > > > any upstream debian directory can be removed before patching? > > > > Don't know about uupdate, but you are allowed to repackage the > > .orig.tar.gz to exclude the upstream debian directory if it helps > > you to maintain the package in Debian. > You could have uscan call an alternate script which does the > repackaging. Yes, that is one option I was considering, since I wanted to have a debian/watch file and use uscan. However, I had imagined that perhaps others had already encountered this issue and knew of a nice way out. Otherwise, I suppose I could keep a personally modified copy of uupdate in the non-upstream debian directory that will remove the upstream debian directory immediately after unpacking the new archive. Meanwhile, I've opened a wishlist bug (http://bugs.debian.org/278797) to add an option to uupdate to allow removal of the upstream debian directory immediately after unpacking the new upstream archive. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory
On Fri, Oct 29, 2004 at 06:26:32AM -0600, David Everly wrote:
> On Thu, Oct 28, 2004 at 02:35:07PM -0400, Justin Pryzby wrote:
> > You could have uscan call an alternate script which does the
> > repackaging.
>
> Yes, that is one option I was considering, since I wanted to have a
> debian/watch file and use uscan. However, I had imagined that perhaps
> others had already encountered this issue and knew of a nice way out.
>
> Otherwise, I suppose I could keep a personally modified copy of uupdate
> in the non-upstream debian directory that will remove the upstream
> debian directory immediately after unpacking the new archive.
For comment, here is what I've done. First the line in debian/watch:
http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \
debian ./debian/custom-uupdate
And now the contents of ./debian/custom-uupdate:
#!/bin/sh -e
(
cd ..
gunzip idzebra-${2}.tar.gz
tar --delete --file=idzebra-${2}.tar idzebra-${2}/debian
gzip idzebra-${2}.tar
)
uupdate "$@"
# end of script
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/
ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html
signature.asc
Description: Digital signature
Re: ignoring upstream debian directory while using uscan
On Sat, Oct 30, 2004 at 09:40:20AM -0600, David Everly wrote: > For comment, here is what I've done. First the line in debian/watch: > > http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \ > debian ./debian/custom-uupdate Hmm...I see now that this is not possible since, even though ./debian/custom-uupdate had execute permissions when building the package, "dpkg-source -x" only sets execute permissions for debian/rules. Does anyone have any ideas on this? Ultimately, I want to do uscan and remove the upstream debian directory before processing with uupdate, and have no manual intervention between steps. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Seeking sponsor for Emilda and related packages
Hi, I would like to see Emilda (http://www.emilda.org/) and related packages come into Debian. Packages needed by Emilda that are not currently in Debian are: libgd-barcode-perl(CPAN) libhtml-htmldoc-perl (CPAN) libmarc-record-perl (CPAN) libnet-z3950-perl (CPAN) php4-yaz (http://www.indexdata.dk) idzebra-doc (http://www.indexdata.dk) libidzebra-perl (http://www.indexdata.dk) idzebra (http://www.indexdata.dk) Of the above, I only see libmarc-record-perl mentioned in http://bugs.debian.org/wnpp. I am willing to work and learn for this to happen, thus seeking sponsorship. What work I have done on this so far is in: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ As of today, I have not yet started on php4-yaz. Oddly, I'm seeing lintian issues with perl documentation when building these on sarge, such as the following: W: libnet-z3950-perl: manpage-section-mismatch usr/share/man/man3/Net::Z3950::Connection.3pm.gz:132 3pm != 3 I: libnet-z3950-perl: hyphen-used-as-minus-sign usr/share/man/man3/Net::Z3950::Connection.3pm.gz:238 It appears this happens during the pod2man conversion. I know how to fix this after the conversion, but how to fix earlier in the process? Thanks in advance, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 10:14:59AM -0700, Russ Allbery wrote: > David Everly <[EMAIL PROTECTED]> writes: > > > Oddly, I'm seeing lintian issues with perl documentation when building > > these on sarge, such as the following: > > > W: libnet-z3950-perl: manpage-section-mismatch > > usr/share/man/man3/Net::Z3950::Connection.3pm.gz:132 3pm != 3 > > I: libnet-z3950-perl: hyphen-used-as-minus-sign > > usr/share/man/man3/Net::Z3950::Connection.3pm.gz:238 > > > It appears this happens during the pod2man conversion. I know how to > > fix this after the conversion, but how to fix earlier in the process? > > There is an open bug about this against Perl and an argument about whether > it's a Perl bug or a policy bug (since policy wants something else). It's > not possible to fix this before the conversion; the offending assumption > is hard-coded deep inside ExtUtils::MakeMaker and would need a patch to > Perl to fix properly. > > I'd appreciate any recommendations on dealing with this myself, as I'm > running into this in several packages I'm working on. For the time being, > I've just been ignoring it, but I'm not sure if that's correct. Well it looks like for "manpage-section-mismatch", ignoring works, because ExtUtils/MM_Any.pm has been patched in Sid to fix the .TH header generation to match the 1pm or 3pm file extension. (I was looking for the perl bug you mentioned and couldn't find it. Then noticed that perl versions were different between Sarge and Sid, so thought I should see if it had fixed or changed.) And as far as I know the policy is: 'Module packages must install manual pages into the standard directories (see Documentation, Section 2.4) using the extensions .1p and .3pm to ensure that no conflict arises where a packaged module duplicates a core module.' Thus, once this new version of perl comes, a rebuild should fix the problem. Now regarding the hyphen-used-as-minus-sign issue, it seems that in some cases pod2man should generate "\-", but instead produces only "-". All I know to do is to fix it after the man pages are generated. Kind of a non-answer, I know, but I don't know how else to address this one. Hopefully, someone will have a better answer. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 06:55:02PM -0700, Russ Allbery wrote: > David Everly <[EMAIL PROTECTED]> writes: > > Now regarding the hyphen-used-as-minus-sign issue, it seems that in some > > cases pod2man should generate "\-", but instead produces only "-". All > > I know to do is to fix it after the man pages are generated. Kind of a > > non-answer, I know, but I don't know how else to address this one. > > Hopefully, someone will have a better answer. > > Well, I'm the upstream maintainer of pod2man, so if you can give me > specifics, I can try to get this fixed. Note that there's a much newer > version of pod2man that's awaiting Pod::Simple to be completely ready for > it to be released, and a variety of changes are waiting on that process. Ok, all of this is from Debian/Sarge, so if there is a new version, I haven't tried it. Here are the lines that lintian didn't like: $conn->startSearch(-ccl => 'au=kernighan and su=unix'); $conn->startSearch(-prefix => '@and @attr 1=1 kernighan @attr 1=21 unix'); $conn->startScan(-prefix => '@attr 1=5 programming'); rs = $conn->search(-prefix => '@or rock @attr 1=21 mineral'); $rs = $conn->search(-ccl2rpn => 'rock or su=mineral'); $rs = $conn->search(-ccl => 'rock or su=mineral'); my $handle = IO::File->new( 'gunzip -c file.marc.gz |' ); #!/usr/bin/perl -w my $fh = IO::File->new( 'gunzip -c marc.dat.gz |' ); Here is what lintian wants them to be: $conn->startSearch(\-ccl => 'au=kernighan and su=unix'); $conn->startSearch(\-prefix => '@and @attr 1=1 kernighan @attr 1=21 unix'); $conn->startScan(\-prefix => '@attr 1=5 programming'); rs = $conn->search(\-prefix => '@or rock @attr 1=21 mineral'); $rs = $conn->search(\-ccl2rpn => 'rock or su=mineral'); $rs = $conn->search(\-ccl => 'rock or su=mineral'); my $handle = IO::File->new( 'gunzip \-c file.marc.gz |' ); #!/usr/bin/perl \-w my $fh = IO::File->new( 'gunzip \-c marc.dat.gz |' ); To get an idea of what pod2man gets as input, try looking at: http://search.cpan.org/CPAN/authors/id/M/MI/MIRK/Net-Z3950-0.44.tar.gz Specifically Net-Z3950-0.44/Z3950/Connection.pm lines 461, 462, and 571, which are the sources of the first 3 lines I listed that lintian doesn't like. Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: libmarc-record-perl (wnpp #251875)
Request for Sponsor: libmarc-record-perl ITP: http://bugs.debian.org/251875 Description: Modules that define MARC fields, check the validity of MARC records, and handle MARC records as objects. The MARC (MAchine Readable Cataloging) format was designed by the Library of Congress in the late 1960s in order to allow libraries to convert their card catalogs into a digital format. The advantages of having computerized card catalogs were soon realized, and now MARC is being used by all sorts of libraries around the world to provide computerized access to their collections. MARC data in transmission format is optimized for processing by computers, so it's not very readable for the normal human. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: RFS: libmarc-record-perl (wnpp #251875)
Thank you for responding. On Wed, Aug 04, 2004 at 11:41:15AM +0200, Florian Ragwitz wrote: > You probably should ask some member of the [1]debian perl group Is this done by subscribing and sending a message to [EMAIL PROTECTED] > or join it yourself if you intend to package some more perl modules. > > 1. http://pkg-perl.alioth.debian.org/ I've browsed this site. Not trusting my own eyes, I asked Google to help me: http://www.google.com/search?q=join+site%3Apkg-perl.alioth.debian.org I'm not sure I can see a process for joining. Is there a page with this information (I'm not a Debian Developer)? -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: idzebra -- High-performance, text indexing and retrieval engine
ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263830 I am not a Debian Developer, so I am looking for sponsorship. My packages for the following are available at: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ * Package name: idzebra Version : 1.3.17 Upstream Author : Adam Dickmeiss <[EMAIL PROTECTED]> * URL : http://ftp.indexdata.dk/pub/zebra/ * License : GPL Description : High-performance, text indexing and retrieval engine Zebra is a high-performance, general-purpose structured text indexing and retrieval engine. It reads structured records in a variety of input formats (eg. email, XML, MARC) and allows access to them through exact boolean search expressions and relevance-ranked free-text queries. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory while using uscan
On Mon, Nov 01, 2004 at 11:09:43AM +0100, Frank K?ster wrote: > David Everly <[EMAIL PROTECTED]> schrieb: > > > On Sat, Oct 30, 2004 at 09:40:20AM -0600, David Everly wrote: > >> For comment, here is what I've done. First the line in debian/watch: > >> > >> http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \ > >> debian ./debian/custom-uupdate > > > > Hmm...I see now that this is not possible since, even though > > ./debian/custom-uupdate had execute permissions when building the > > package, "dpkg-source -x" only sets execute permissions for > > debian/rules. > > > > Does anyone have any ideas on this? > > - debian ./debian/custom-uupdate > + debian "sh ./debian/custom-uupdate" This doesn't work, because of the way uscan handles it. The following error is produced: sh: -c: line 1: unexpected EOF while looking for matching `"' sh: -c: line 2: syntax error: unexpected end of file -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Seeking sponsor for Emilda and related packages
Hi, I would like to see Emilda (http://www.emilda.org/) and related packages come into Debian. Packages needed by Emilda that are not currently in Debian are: libgd-barcode-perl(CPAN) libhtml-htmldoc-perl (CPAN) libmarc-record-perl (CPAN) libnet-z3950-perl (CPAN) php4-yaz (http://www.indexdata.dk) idzebra-doc (http://www.indexdata.dk) libidzebra-perl (http://www.indexdata.dk) idzebra (http://www.indexdata.dk) Of the above, I only see libmarc-record-perl mentioned in http://bugs.debian.org/wnpp. I am willing to work and learn for this to happen, thus seeking sponsorship. What work I have done on this so far is in: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ As of today, I have not yet started on php4-yaz. Oddly, I'm seeing lintian issues with perl documentation when building these on sarge, such as the following: W: libnet-z3950-perl: manpage-section-mismatch usr/share/man/man3/Net::Z3950::Connection.3pm.gz:132 3pm != 3 I: libnet-z3950-perl: hyphen-used-as-minus-sign usr/share/man/man3/Net::Z3950::Connection.3pm.gz:238 It appears this happens during the pod2man conversion. I know how to fix this after the conversion, but how to fix earlier in the process? Thanks in advance, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 10:14:59AM -0700, Russ Allbery wrote: > David Everly <[EMAIL PROTECTED]> writes: > > > Oddly, I'm seeing lintian issues with perl documentation when building > > these on sarge, such as the following: > > > W: libnet-z3950-perl: manpage-section-mismatch > > usr/share/man/man3/Net::Z3950::Connection.3pm.gz:132 3pm != 3 > > I: libnet-z3950-perl: hyphen-used-as-minus-sign > > usr/share/man/man3/Net::Z3950::Connection.3pm.gz:238 > > > It appears this happens during the pod2man conversion. I know how to > > fix this after the conversion, but how to fix earlier in the process? > > There is an open bug about this against Perl and an argument about whether > it's a Perl bug or a policy bug (since policy wants something else). It's > not possible to fix this before the conversion; the offending assumption > is hard-coded deep inside ExtUtils::MakeMaker and would need a patch to > Perl to fix properly. > > I'd appreciate any recommendations on dealing with this myself, as I'm > running into this in several packages I'm working on. For the time being, > I've just been ignoring it, but I'm not sure if that's correct. Well it looks like for "manpage-section-mismatch", ignoring works, because ExtUtils/MM_Any.pm has been patched in Sid to fix the .TH header generation to match the 1pm or 3pm file extension. (I was looking for the perl bug you mentioned and couldn't find it. Then noticed that perl versions were different between Sarge and Sid, so thought I should see if it had fixed or changed.) And as far as I know the policy is: 'Module packages must install manual pages into the standard directories (see Documentation, Section 2.4) using the extensions .1p and .3pm to ensure that no conflict arises where a packaged module duplicates a core module.' Thus, once this new version of perl comes, a rebuild should fix the problem. Now regarding the hyphen-used-as-minus-sign issue, it seems that in some cases pod2man should generate "\-", but instead produces only "-". All I know to do is to fix it after the man pages are generated. Kind of a non-answer, I know, but I don't know how else to address this one. Hopefully, someone will have a better answer. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 06:55:02PM -0700, Russ Allbery wrote: > David Everly <[EMAIL PROTECTED]> writes: > > Now regarding the hyphen-used-as-minus-sign issue, it seems that in some > > cases pod2man should generate "\-", but instead produces only "-". All > > I know to do is to fix it after the man pages are generated. Kind of a > > non-answer, I know, but I don't know how else to address this one. > > Hopefully, someone will have a better answer. > > Well, I'm the upstream maintainer of pod2man, so if you can give me > specifics, I can try to get this fixed. Note that there's a much newer > version of pod2man that's awaiting Pod::Simple to be completely ready for > it to be released, and a variety of changes are waiting on that process. Ok, all of this is from Debian/Sarge, so if there is a new version, I haven't tried it. Here are the lines that lintian didn't like: $conn->startSearch(-ccl => 'au=kernighan and su=unix'); $conn->startSearch(-prefix => '@and @attr 1=1 kernighan @attr 1=21 unix'); $conn->startScan(-prefix => '@attr 1=5 programming'); rs = $conn->search(-prefix => '@or rock @attr 1=21 mineral'); $rs = $conn->search(-ccl2rpn => 'rock or su=mineral'); $rs = $conn->search(-ccl => 'rock or su=mineral'); my $handle = IO::File->new( 'gunzip -c file.marc.gz |' ); #!/usr/bin/perl -w my $fh = IO::File->new( 'gunzip -c marc.dat.gz |' ); Here is what lintian wants them to be: $conn->startSearch(\-ccl => 'au=kernighan and su=unix'); $conn->startSearch(\-prefix => '@and @attr 1=1 kernighan @attr 1=21 unix'); $conn->startScan(\-prefix => '@attr 1=5 programming'); rs = $conn->search(\-prefix => '@or rock @attr 1=21 mineral'); $rs = $conn->search(\-ccl2rpn => 'rock or su=mineral'); $rs = $conn->search(\-ccl => 'rock or su=mineral'); my $handle = IO::File->new( 'gunzip \-c file.marc.gz |' ); #!/usr/bin/perl \-w my $fh = IO::File->new( 'gunzip \-c marc.dat.gz |' ); To get an idea of what pod2man gets as input, try looking at: http://search.cpan.org/CPAN/authors/id/M/MI/MIRK/Net-Z3950-0.44.tar.gz Specifically Net-Z3950-0.44/Z3950/Connection.pm lines 461, 462, and 571, which are the sources of the first 3 lines I listed that lintian doesn't like. Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: libmarc-record-perl (wnpp #251875)
Request for Sponsor: libmarc-record-perl ITP: http://bugs.debian.org/251875 Description: Modules that define MARC fields, check the validity of MARC records, and handle MARC records as objects. The MARC (MAchine Readable Cataloging) format was designed by the Library of Congress in the late 1960s in order to allow libraries to convert their card catalogs into a digital format. The advantages of having computerized card catalogs were soon realized, and now MARC is being used by all sorts of libraries around the world to provide computerized access to their collections. MARC data in transmission format is optimized for processing by computers, so it's not very readable for the normal human. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: RFS: libmarc-record-perl (wnpp #251875)
Thank you for responding. On Wed, Aug 04, 2004 at 11:41:15AM +0200, Florian Ragwitz wrote: > You probably should ask some member of the [1]debian perl group Is this done by subscribing and sending a message to [EMAIL PROTECTED] > or join it yourself if you intend to package some more perl modules. > > 1. http://pkg-perl.alioth.debian.org/ I've browsed this site. Not trusting my own eyes, I asked Google to help me: http://www.google.com/search?q=join+site%3Apkg-perl.alioth.debian.org I'm not sure I can see a process for joining. Is there a page with this information (I'm not a Debian Developer)? -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: idzebra -- High-performance, text indexing and retrieval engine
ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263830 I am not a Debian Developer, so I am looking for sponsorship. My packages for the following are available at: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ * Package name: idzebra Version : 1.3.17 Upstream Author : Adam Dickmeiss <[EMAIL PROTECTED]> * URL : http://ftp.indexdata.dk/pub/zebra/ * License : GPL Description : High-performance, text indexing and retrieval engine Zebra is a high-performance, general-purpose structured text indexing and retrieval engine. It reads structured records in a variety of input formats (eg. email, XML, MARC) and allows access to them through exact boolean search expressions and relevance-ranked free-text queries. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
ignoring upstream debian directory
Hi, Is there some mechanism or alternative for using uupdate so that any upstream debian directory can be removed before patching? Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory
On Thu, Oct 28, 2004 at 02:35:07PM -0400, Justin Pryzby wrote: > On Thu, Oct 28, 2004 at 07:21:23PM +0200, Santiago Vila wrote: > > On Thu, 28 Oct 2004, David Everly wrote: > > > > > Is there some mechanism or alternative for using uupdate so that > > > any upstream debian directory can be removed before patching? > > > > Don't know about uupdate, but you are allowed to repackage the > > .orig.tar.gz to exclude the upstream debian directory if it helps > > you to maintain the package in Debian. > You could have uscan call an alternate script which does the > repackaging. Yes, that is one option I was considering, since I wanted to have a debian/watch file and use uscan. However, I had imagined that perhaps others had already encountered this issue and knew of a nice way out. Otherwise, I suppose I could keep a personally modified copy of uupdate in the non-upstream debian directory that will remove the upstream debian directory immediately after unpacking the new archive. Meanwhile, I've opened a wishlist bug (http://bugs.debian.org/278797) to add an option to uupdate to allow removal of the upstream debian directory immediately after unpacking the new upstream archive. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory
On Fri, Oct 29, 2004 at 06:26:32AM -0600, David Everly wrote:
> On Thu, Oct 28, 2004 at 02:35:07PM -0400, Justin Pryzby wrote:
> > You could have uscan call an alternate script which does the
> > repackaging.
>
> Yes, that is one option I was considering, since I wanted to have a
> debian/watch file and use uscan. However, I had imagined that perhaps
> others had already encountered this issue and knew of a nice way out.
>
> Otherwise, I suppose I could keep a personally modified copy of uupdate
> in the non-upstream debian directory that will remove the upstream
> debian directory immediately after unpacking the new archive.
For comment, here is what I've done. First the line in debian/watch:
http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \
debian ./debian/custom-uupdate
And now the contents of ./debian/custom-uupdate:
#!/bin/sh -e
(
cd ..
gunzip idzebra-${2}.tar.gz
tar --delete --file=idzebra-${2}.tar idzebra-${2}/debian
gzip idzebra-${2}.tar
)
uupdate "$@"
# end of script
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/
ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html
signature.asc
Description: Digital signature
Re: ignoring upstream debian directory while using uscan
On Sat, Oct 30, 2004 at 09:40:20AM -0600, David Everly wrote: > For comment, here is what I've done. First the line in debian/watch: > > http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \ > debian ./debian/custom-uupdate Hmm...I see now that this is not possible since, even though ./debian/custom-uupdate had execute permissions when building the package, "dpkg-source -x" only sets execute permissions for debian/rules. Does anyone have any ideas on this? Ultimately, I want to do uscan and remove the upstream debian directory before processing with uupdate, and have no manual intervention between steps. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: ignoring upstream debian directory while using uscan
On Mon, Nov 01, 2004 at 11:09:43AM +0100, Frank K?ster wrote: > David Everly <[EMAIL PROTECTED]> schrieb: > > > On Sat, Oct 30, 2004 at 09:40:20AM -0600, David Everly wrote: > >> For comment, here is what I've done. First the line in debian/watch: > >> > >> http://ftp.indexdata.dk/pub/zebra/idzebra-(.*)\.tar\.gz \ > >> debian ./debian/custom-uupdate > > > > Hmm...I see now that this is not possible since, even though > > ./debian/custom-uupdate had execute permissions when building the > > package, "dpkg-source -x" only sets execute permissions for > > debian/rules. > > > > Does anyone have any ideas on this? > > - debian ./debian/custom-uupdate > + debian "sh ./debian/custom-uupdate" This doesn't work, because of the way uscan handles it. The following error is produced: sh: -c: line 1: unexpected EOF while looking for matching `"' sh: -c: line 2: syntax error: unexpected end of file -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Complex Depends
Hello Debian Mentors, How do I construct a "Depends" line in debian/control for the following example: Require package-a or package-b. If package-a is selected, require package-1 and package-2. If package-b is selected, require package-3. Notes: package-a, package-b, package-1, package-2, and package-3 are not under my control. package-1, package-2, and package-3 do not depend on package-a or package-b. What I think I want to do is probably not supported (or is it?): Depends: (package-a,package-1,package-2) | (package-b,package-3) Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: Complex Depends
On Tue, Mar 29, 2005 at 12:22:39AM -0600, David Moreno Garza wrote: > On Mon, 2005-03-28 at 09:37 -0700, David Everly wrote: > > Hello Debian Mentors, > > > > How do I construct a "Depends" line in debian/control for the following > > example: > > > >Require package-a or package-b. > > > >If package-a is selected, require package-1 and package-2. > > > >If package-b is selected, require package-3. > > > > Notes: > > > >package-a, package-b, package-1, package-2, and package-3 are > >not under my control. > > > >package-1, package-2, and package-3 do not depend on package-a or > >package-b. > > > > What I think I want to do is probably not supported (or is it?): > > > >Depends: (package-a,package-1,package-2) | (package-b,package-3) > > My quick thought would be: > > Build different binary packages, i.e. foo-package-a depends on package-1 > and package-2 and foo-package-b depends on package-3, where foo is, > probably, the common name for your packages. That's all. > > I hope this could reach what you were expecting. Thanks. Yes, this worked quite well. > -- > David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ > People bitched at me to learn a foreign language so I learned Perl. > GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D > > > -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: libgd-barcode-perl
ITP: http://bugs.debian.org/263831 * Package name: libgd-barcode-perl Version : 1.15 Upstream Author : Kawai Takanori <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/K/KW/KWITKNR/ * License : GPL or Artistic Description : Create barcode images with GD GD::Barcode is a subclass of GD and allows you to create barcode images with GD. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ This is a requirement for the Emilda package (http://www.emilda.org/), for which I am also seeking a sponsor (http://bugs.debian.org/263826). Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: libmarc-record-perl
ITP: http://bugs.debian.org/251875 * Package name: libmarc-record-perl Version : 1.38 Upstream Author : Andy Lester <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/P/PE/PETDANCE/ * License : GPL or Artistic Description : Perl extension for handling MARC records Provides modules that define MARC fields, check the validity of MARC records, and handle MARC records as objects. The MARC (MAchine Readable Cataloging) format was designed by the Library of Congress in the late 1960s in order to allow libraries to convert their card catalogs into a digital format. The advantages of having computerized card catalogs were soon realized, and now MARC is being used by all sorts of libraries around the world to provide computerized access to their collections. MARC data in transmission format is optimized for processing by computers, so it's not very readable for the normal human. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ This is a requirement for the Emilda package (http://www.emilda.org/), for which I am also seeking a sponsor (http://bugs.debian.org/263826). Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: libnet-z3950-perl
ITP: http://bugs.debian.org/263821 * Package name: libnet-z3950-perl Version : 0.47 Upstream Author : Mike Taylor <[EMAIL PROTECTED]> * URL : http://search.cpan.org/ * License : GPL Description : extension to Perl for talking to Z39.50 servers This module provides a Perl interface to the Z39.50 information retrieval protocol (aka. ISO 23950), a mature and powerful protocol used in application domains as diverse as bibliographic information, geo-spatial mapping, museums and other cultural heritage information, and structured vocabulary navigation. Net::Z3950.pm is an implementation of the Perl binding for ZOOM, the Z39.50 Object Orientation Model. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ This is a requirement for the Emilda package (http://www.emilda.org/), for which I am also seeking a sponsor (http://bugs.debian.org/263826). Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: php4-yaz
ITP: http://bugs.debian.org/263833 * Package name: php4-yaz Version : 1.0.2 Upstream Author : Adam Dickmeiss <[EMAIL PROTECTED]> * URL : http://pecl.php.net/package/yaz * License : http://www.php.net/license/3_0.txt Description : php/yaz z39.50 module PHP/YAZ is a Z39.50 Module for PHP built with the YAZ toolkit. YAZ is a toolkit that allows you to develop software using the ANSI Z39.50/ISO23950 standard for information retrieval. Z39.50 specifies a client/server-based protocol for searching and retrieving information from remote databases run by organizations such as the Library of Congress. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ This is a requirement for the Emilda package (http://www.emilda.org/), for which I am also seeking a sponsor (http://bugs.debian.org/263826). Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: idzebra - high-performance, text indexing and retrieval engine
ITP: http://bugs.debian.org/263830 * Package name: idzebra Version : 1.3.24 Upstream Author : Adam Dickmeiss <[EMAIL PROTECTED]> * URL : http://ftp.indexdata.dk/pub/zebra/ * License : GPL Description : high-performance, text indexing and retrieval engine Zebra is a high-performance, general-purpose structured text indexing and retrieval engine. It reads structured records in a variety of input formats (eg. email, XML, MARC) and allows access to them through exact boolean search expressions and relevance-ranked free-text queries. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ This is a requirement for the Emilda package (http://www.emilda.org/), for which I am also seeking a sponsor (http://bugs.debian.org/263826). Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
RFS: emilda - web-based Integrated Library System
ITP: http://bugs.debian.org/263826 * Package name: emilda Version : 1.2.2 Upstream Author : Christoffer Landtman * URL : http://www.emilda.org/ * License : GPL Description : web-based Integrated Library System Emilda is a complete Integrated Library System that features amongst others an OPAC, circulation and administration functions, Z39.50 capabilities and 100% MARC compatibility. MARC compatibility is achieved using IDZebra in conjunction with MySQL. Packages available as follows: http://users.adelphia.net/~david.everly/emilda/sarge/ deb http://users.adelphia.net/~david.everly emilda/sarge/ deb-src http://users.adelphia.net/~david.everly emilda/sarge/ Thanks, Dave. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
upgrading database tables and data
Does anyone know of a package that I can look at that has a mechanism to run a series of certain SQL scripts based on upgrading from a certain version to a certain version? For instance, when upgrading from 1.1-1 to 1.1-2, I want to delete a row from a table, when upgrading from 1.1-2 to 1.2-1, I want to alter a table, and when upgrading from 1.1-1 to 1.2-1, I want to do both of these actions (first the delete, then the alter). I'm already using wwwconfig-common. Any suggestions on nice ways to organize these to know which scripts to run and in which order are appreciated. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
