Bug#452583: linhdd: incorrect license information
Package: linhdd Version: 0.4-2 Severity: serious According to both README and linHDD.py, the program is GPLv3 or later, but debian/copyright says GPLv2 or later. Furthermore, there's no information about the copyright of the files in the util-linux/ directory. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452583: linhdd: incorrect license information
On Sat, Nov 24, 2007 at 02:54:48PM +0530, Kartik Mistry wrote: Furthermore, there's no information about the copyright of the files in the util-linux/ directory. debian/copyright file says, (util-linux/fdisk.c) Copyright (C) 1992 A. V. Le Blanc [EMAIL PROTECTED] So, this is already fixed. Oops, sorry. The missing thing about it is the license too: it says GPLv1 or later in util-linux/fdisk.c, so it should be mentioned separately in debian/copyright. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452872: libxml-sax-perl: testfiles/xmltest.xml is non-free
Package: libxml-sax-perl Version: 0.16-0.1 Severity: serious The file 'testfiles/xmltest.xml' in the source package is non-free. The copyright notice is: Copyright 1998-1999 by Sun Microsystems, Inc. All Rights Reserved. with no information on a license for redistribution or modification. The file seems to originate in the OASIS XML conformance test suite. It's a slightly modified version of the one inside a tarball found at http://www.oasis-open.org/committees/xml-conformance/suite-v1se/xmlconf-20010315.tar.gz with a readme.html file in the same directory stating: Copyright (C) 1998 James Clark. All rights reserved. Permission is granted to copy and modify this collection in any way for internal use within a company or organization. Permission is granted to redistribute the file codexmltest.zip/code containing this collection to third parties provided that no modifications of any kind are made to this file. Note that permission to distribute the collection in any other form is not granted. The rest of the test suite is not included in libxml-sax-perl; this file seems to be just an example of a large XML document. It should be trivial to remove or replace with another one. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430118: libxml-sax-perl: patch for choosing the default parser better
On Thu, Nov 08, 2007 at 11:23:34PM +0200, Niko Tyni wrote: (libxml-sax-perl) I'm attaching a proposed patch that fixes these RC issues mentioned in this bug report. As the changes are rather extensive, I'd prefer something like this to be included in a maintainer upload rather than an NMU. Jay, I haven't seen anything from you on this since July. Would it be OK with you if we adopted this for the pkg-perl group? Jay, did you get this? Please consider giving the package away to the pkg-perl group. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452872: new libxml-sax-perl version at the pkg-perl SVN repository
Hi, I have prepared a proposed new version of libxml-sax-perl, closing all the open bugs including these two RC ones (#430118 and #452872). I just pushed the packaging into the pkg-perl Alioth repository at svn://svn.debian.org/svn/pkg-perl/trunk/libxml-sax-perl The full changelog can be seen at http://svn.debian.org/wsvn/pkg-perl/trunk/libxml-sax-perl/debian/changelog?op=file The patch I sent to #430118 corresponds to r9825. There were a few bugs in it that I fixed since; see r9834, r9861 and r9866. I can knit together a new patch targeted specifically at #430118 if really needed, but I'd much prefer to have the whole updated package go in as a maintainer upload. Jay, please comment. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453218: libmoose-perl: FTBFS: t/000_recipes/003_recipe failed
reassign 453218 libclass-mop-perl , libmoose-perl , libmoosex-getopt-perl , libmoosex-getobj-pluggable-perl , libdevel-repl-perl found 453218 libclass-mop-perl 0.45-1 retitle 453218 libclass-mop-perl 0.45 breaks libmoose-perl thanks On Tue, Nov 27, 2007 at 10:43:10PM -0600, Rene Mayorga wrote: reassign 453215 libmoose-perl 0.26-1 reassign 453219 libmoose-perl 0.26-1 reassign 453228 libmoose-perl 0.26-1 merge 45321 45321 45321 453218 tags 453218 pending thanks libmoose-perl fails tests cases when the 0.45-1 version of libclass-mop-perl is used. Anyway, the bug is solved with the newest version of libmoose-perl 0.31 and libclass-mop-perl 0.48 (the two packages are already upgraded at pkg-perl svn repo) I'm reassigning the bug to all the packages and specifying the 'found' version number only for the real culprit, libclass-mop-perl/0.45-1. This should make things clear for the BTS version tracking. The current libclass-mop-perl version, 0.48, indeed fixes this. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453218: libmoose-perl: FTBFS: t/000_recipes/003_recipe failed
reassign 453218 libmoose-perl,libmoosex-getopt-perl,libmoosex-object-pluggable-perl,libdevel-repl-perl found 453218 libmoose-perl 0.26-1 clone 453218 -1 retitle 453218 libmoose-perl 0.26 doesn't work with libclass-mop-perl 0.45 retitle -1 libclass-mop-perl: new upstream version needed to undo libmoose-perl breakage reassign -1 libclass-mop-perl 0.45-1 block 453218 by -1 thanks On Tue, Nov 27, 2007 at 10:43:10PM -0600, Rene Mayorga wrote: Anyway, the bug is solved with the newest version of libmoose-perl 0.31 and libclass-mop-perl 0.48 (the two packages are already upgraded at pkg-perl svn repo) I'm reassigning the bug to all the packages and specifying the 'found' version number only for the real culprit, libclass-mop-perl/0.45-1. This should make things clear for the BTS version tracking. The current libclass-mop-perl version, 0.48, indeed fixes this. ... except that the current libmoose-perl version (0.26), doesn't work with the newer libclass-mop-perl version. So we indeed need to update both to get the test failures fixed, just as Rene said. Trying to explain this to the BTS again. Sorry for the noise. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453288: libclass-mop-perl: new upstream version needed to undo libmoose-perl breakage
Package: libclass-mop-perl Version: 0.45-1 Severity: serious As seen in #453218 and others, libclass-mop-perl 0.45 broke libmoose-perl. As the current upstream version, 0.48, isn't compatible with the current Debian libmoose-perl version, 0.26-1, the way out of this is to update both. I'm filing this as 'serious' to keep 0.45-1 out of testing. Otherwise it would go in today. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#235189: get: Returns an unessisary '\n'.
tag 235189 confirmed
found 235189 5.420-2
thanks
On Fri, Feb 27, 2004 at 02:09:50PM -0600, Mike Mestnik) (the Archmage forever
wrote:
Package: libmime-perl
Version: 5.411-3
Severity: wishlist
I'm working on the fetchyahoo program and I have determined that...
print From: . $mimeHead-get('From') . \n;
Will have an extra '\n'.
There is indeed a documentation bug here. From the MIME::Head SYNOPSIS:
### Get receipt information:
print Last received from: , $head-get('Received', 0), \n;
@all_received = $head-get('Received');
### Print the subject, or the empty string if none:
print Subject: , $head-get('Subject',0), \n;
Both of the print statements will output double newlines, which
is quite unexpected.
This should be reported upstream with a patch.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297765: Package should be named libmime-tools-perl, not libmime-perl
On Wed, Mar 02, 2005 at 08:15:28PM +0100, Julian Mehnle wrote: (Sorry for the delay.) Package: libmime-perl Version: 5.417-1 Severity: wishlist The CPAN package is named MIME-tools, so following the unofficial naming convention for Debian Perl packages, the Debian package should probably really be named libmime-tools-perl. Quoting the Debian Perl Policy: 4.2 Module Package Names Perl module packages should be named for the primary module provided. The naming convention for module Foo::Bar is libfoo-bar-perl. Packages which include multiple modules may additionally include provides for those modules using the same convention. There is actually no real primary module in the MIME-Tools distribution, and I suppose 'libmime-perl' (which dates back to 1997) can be seen as an approximation. For a fresh start, I'd probably go with mime-tools-perl as both the source and the binary package name. However, I don't think this is worth the hassle of renaming. (If the name is changed, just Providing libmime-perl isn't enough because there are versioned dependencies in the archive. So we'd need a transitional libmime-perl package depending on the new package name.) I'm inclined to tag this 'wontfix', but I'd appreciate opinions from other members of the Debian Perl Group, the current mime-tools maintainer. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297765: Package should be named libmime-tools-perl, not libmime-perl
On Thu, Nov 29, 2007 at 09:27:47PM +0200, Niko Tyni wrote: There is actually no real primary module in the MIME-Tools distribution, and I suppose 'libmime-perl' (which dates back to 1997) can be seen as an approximation. Hm, I only now realized that there really *is* a MIME::Tools module, which is just a frontend for configuring the logging and debugging of the other modules. Since it also contains the primary documentation, I suppose it could be viewed as the primary module, and the name of the binary package should indeed be libmime-tools-perl. I'm still not sure if it's worth it to rename, though. Sorry for the confusion. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297765: Package should be named libmime-tools-perl, not libmime-perl
On Fri, Nov 30, 2007 at 01:38:13PM +0200, Damyan Ivanov wrote: I am for renaming (plus a transitional package). So am I, the existence of MIME/Tools.pm tips the scales for me. FWIW, I think it makes sense to rename both the source and the binary package in the same go. After bugging maintainers to change their (Build-)Depends, we can file an RM bug for libmime-perl (then dummy) package on ftp.debian.org. This would take months. I am wondering if we can use an exception from the policy here :) There's no hurry with this. We need the transitional libmime-perl package present in lenny anyway so that there's an upgrade path for the users. Currently this would mean 30+ 'minor' (or 'normal') bugs on the dependending packages, which is a mass bug filing. So we need an announcement on debian-devel, which will probably reduce the number of bugs somewhat. After lenny we would stop building the transitional package and raise the severity of the remaining bugs to 'serious'. I don't think an RM bug is needed at that point; sourceless binary packages are removed semi-automatically. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455922: ITA: libaudio-flac-header-perl
retitle 455922 ITA: libaudio-flac-header-perl -- Perl interface to FLAC file header metadata owner 455922 ! thanks I'm using this, so I'll adopt it for the Debian Perl Group. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457071: smokeping: Javascript error: $(zoom) has no properties
On Wed, Dec 19, 2007 at 10:43:31AM -0400, Ben Armstrong wrote: Package: smokeping Version: 2.2.7-1 Severity: minor Firebug tells me: $(zoom) has no properties at line 85 in smokeping-zoom.js This happens whenever I view a page without the javascript zoom widget. This could be handled by testing for the presence of the element and only execute these lines if the element is present, or better yet, simply do not include smokeping-zoom.js on this page if it is not used. Hi, thanks for your report. I'm forwarding it to Tobias Oetiker, who wrote this part of the code. Tobi, please keep [EMAIL PROTECTED] Cc'd. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442900: libdevel-caller-perl: FTBFS on alpha and ia64 (failing tests)
found 442900 2.02-1 clone 442900 -1 reassign -1 libpadwalker-perl 1.5-1 retitle -1 libpadwalker-perl: truncated pointer breaks libdevel-caller-perl on alpha and ia64 tag -1 patch block 442900 with -1 thanks On Mon, Sep 17, 2007 at 09:42:25PM +0300, Niko Tyni wrote: Package: libdevel-caller-perl Version: 0.11-1 Severity: important The package is failing to build on alpha and ia64 due to failing tests. From the alpha buildd log: /usr/bin/perl Build test t/Devel-Callercx_type is 0 not CXt_SUB # Looks like you planned 72 tests but only ran 1. # Looks like your test died just after 1. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-72 I finally looked into this on ia64 (merulo.d.o), and the bug is in libpadwalker-perl, in PadWalker::_upcontext(), which truncates the PERL_CONTEXT pointer returned by PadWalker::upcontext() into 32 bits. Patch attached. Cheers, -- Niko Tyni [EMAIL PROTECTED] --- PadWalker.xs2007/12/29 13:22:06 1.1 +++ PadWalker.xs2007/12/29 13:22:16 @@ -534,4 +534,4 @@ PPCODE: /* I'm not sure why this is here, but I'll leave it in case * somebody is using it in an insanely evil way. */ -XPUSHs(sv_2mortal(newSViv((U32)upcontext(aTHX_ uplevel, 0, 0, 0, 0; +XPUSHs(sv_2mortal(newSViv((IV)upcontext(aTHX_ uplevel, 0, 0, 0, 0;
Bug#187583: libxml-xpath-perl: and in Xpath should be commutative (Can't call method size on an undefined value)
tag 187583 patch
forwarded 187583 http://rt.cpan.org/Public/Bug/Display.html?id=32012
thanks
On Fri, Apr 04, 2003 at 02:10:25PM +0200, Stephane Bortzmeyer wrote:
Package: libxml-xpath-perl
Version: 1.13-3
Severity: normal
% xpath -e 'text/para/node()[preceding-sibling::important and
position()=last()]' example.xml
Can't call method size on an undefined value at
/usr/share/perl5/XML/XPath/Parser.pm line 107.
Hi,
this happens because evaluating the 'preceding-sibling::important' condition
loses the position/context information. I'm attaching a failing testcase
and a patch that fixes the issue.
I just re-sent the same information upstream as CPAN #32012,
http://rt.cpan.org/Public/Bug/Display.html?id=32012
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
diff --git a/XPath/Step.pm b/XPath/Step.pm
index cff64a3..639fb4c 100644
--- a/XPath/Step.pm
+++ b/XPath/Step.pm
@@ -130,6 +130,8 @@ sub evaluate {
my $from = shift; # context nodeset
#warn Step::evaluate called with , $from-size, length nodeset\n;
+my $saved_context = $self-{pp}-get_context_set;
+my $saved_pos = $self-{pp}-get_context_pos;
$self-{pp}-set_context_set($from);
@@ -149,7 +151,8 @@ sub evaluate {
#warn Step::evaluate initial nodeset size: , $initial_nodeset-size, \n;
-$self-{pp}-set_context_set(undef);
+$self-{pp}-set_context_set($saved_context);
+$self-{pp}-set_context_pos($saved_pos);
$initial_nodeset-sort;
diff --git a/t/32context.t b/t/32context.t
new file mode 100644
index 000..9f7d5e9
--- /dev/null
+++ b/t/32context.t
@@ -0,0 +1,27 @@
+use Test;
+BEGIN { plan tests = 4 }
+
+use XML::XPath;
+ok(1);
+
+my $xp = XML::XPath-new(ioref = *DATA);
+ok($xp);
+
+# Debian bug #187583, http://bugs.debian.org/187583
+# Check that evaluation doesn't lose the context information
+
+my $nodes = $xp-find(text/para/node()[position()=last() and preceding-sibling::important]);
+ok($nodes, has a preceding sibling.);
+
+$nodes = $xp-find(text/para/node()[preceding-sibling::important and position()=last()]);
+ok($nodes, has a preceding sibling.);
+
+__DATA__
+text
+ paraI start the text here, I break
+the line and I go on, I blinktwinkle/blink and then I go on
+again.
+This is not a new paragraph./paraparaThis is a
+importantnew/important paragraph and
+blinkthis word/blink has a preceding sibling./para
+/text
Bug#231833: libxml-xpath-perl: CDATA handling is broken
On Mon, Dec 31, 2007 at 07:21:45PM +1000, Alexander Zangerl wrote: On Su,n 30 Dec 2007 20:43:26 +0200, Niko Tyni writes: The documentation of XML::XPath::findnodes_as_string states it returns the nodes found reproduced as XML, and the W3C XML Path Language specification section 5.7, Text Nodes [1] contains this: NOTE: When a text node that contains a character is written out as XML, the character must be escaped by, for example, using lt;, or including it in a CDATA section. you do realize that last part of the sentence talks about including it in a CDATA section and thus voids your argument? Hm, so would you expect the findnodes_as_string() return value in your example include the CDATA markup then? sdlfkkskdfjl ![CDATA[cdata grind hallo sdsdfsdf]] As I understand this, that's the other option available. In particular, returning unquoted text like findvalue() does would not be reproducing the node as XML. Sorry if I'm being dense. as per the xml specs http://www.w3.org/TR/1998/REC-xml-19980210#sec-cdata-sect CDATA is sacrosanct and nothing within it can be escaped, ever: Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using lt; and amp;. My thinking was that the return value is not text within a CDATA section, but rather (more or less) standalone XML, so this wouldn't apply. I always thought CDATA sections are just a way of escaping the inconvenient characters in input, and not sacrosanct entities that must stay untouched. How absolute is this? If an XML filter gets input like ![CDATA[test string]] and outputs ![CDATA[test]] string is it doing the wrong thing? I'm thus closing the bug. Please reply/reopen if you disagree. i hereby do :-) Thanks, and apologies for my hasty action. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458713: libxml-xpath-perl: should be phased out in favour of other alternatives
Package: libxml-xpath-perl Version: 1.13-6 Severity: important It looks like the libxml-xpath-perl package should be phased out and eventually get removed from Debian. The module is unmaintained upstream (last release was in 2003), and there's a maintained, faster and less buggy alternative available in libxml-libxml-perl. The codebase in XML::XPath has also been forked upstream into XML::XPathEngine with a different API. The libxml-xpathengine-perl package entered Debian in late 2007. See also the perl-xml thread starting at http://aspn.activestate.com/ASPN/Mail/Message/perl-xml/3438368 I do plan to get the Debian package in a better state now that we're adopting it for the pkg-perl group. Still, I think the best solution in the long run would be to get it removed, as fixing eg. #315628 is on the borderline of diverging the API from upstream. The reverse dependencies of libxml-xpath-perl are currently * libxml-atom-perl: alternatively supports libxml-libxml-perl * libxml-twig-perl: alternatively supports libxml-xpathengine-perl * libsql-translator-perl: currently only supports libxml-xpath-perl The libxml-xpath-perl package also provides /usr/bin/xpath, which could easily be reimplemented with libxml-libxml-perl if deemed necessary. The implementation in /usr/share/doc/libxml-libxml-perl/examples/xpath.pl is already pretty close. As a first step, I suggest a deprecation warning in the libxml-xpath-perl long description and README.Debian, and filing bugs on libxml-atom-perl and libxml-twig-perl to move away from libxml-xpath-perl. I'll also look at porting libsql-translator-perl to libxml-libxml-perl. Cc'ing [EMAIL PROTECTED] for comments. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461339: dh_shlibdeps silently skips /usr/lib/debug
On Sat, Jan 19, 2008 at 01:07:48PM -0500, Joey Hess wrote:
I'm pretty sure that anything in
/usr/lib/debug/{lib,lib64,usr,bin,sbin,opt,dev}/ is going to be
separated debug symbols, and it could just ignore those directories and
process the rest.
Hm, counterexample: libqof1-dbg. But maybe it's doing something wrong?
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462142: ITP: libcss-squish-perl -- Compact many CSS files into one big file
Package: wnpp Severity: wishlist Owner: Niko Tyni [EMAIL PROTECTED] * Package name: libcss-squish-perl Version : 0.07 Upstream Author : Thomas Sibley [EMAIL PROTECTED], Ruslan Zakirov [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/CSS-Squish/ * License : GPL-1+ | Artistic Programming Lang: Perl Description : Compact many CSS files into one big file CSS::Squish is a Perl module that takes a list of CSS files and concatenates them, making sure to honor any valid @import statements included in the files. This module is needed by the latest version of request-tracker3.6. The package will be maintained under the Debian Perl Group [EMAIL PROTECTED] umbrella. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462234: libmail-imapclient-perl: perldocs are not installed
tag 462234 confirmed severity 462234 minor thanks On Wed, Jan 23, 2008 at 11:23:51AM +, Stephen Patterson wrote: Package: libmail-imapclient-perl Version: 3.03-1 Severity: important libmail-imapclient-perl does not install documentation viewable via perldoc, although it does install documentation as man pages. This is because the documentation is in a separate .pod file that has been accidentally left out from Debian binary package. I'll upload a fixed package soon. Meanwhile, I'm downgrading the severity. Missing one form of documentation does not have a major effect on the usability of a package, without rendering it completely unusable to everyone. Thanks for reporting this, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462249: libaudio-flac-header-perl: FTBFS on armel, hppa, m68k, powerpc, s390, sparc
On Wed, Jan 23, 2008 at 03:07:48PM +0200, Riku Voipio wrote: Package: libaudio-flac-header-perl Version: 1.9-1 Severity: serious Justification: no longer builds from source Since the architectures where testsuite fails have little in common, it could be that this bug is a bug in the testsuite rather than testsuite exposing bugs in libaudio-flac-header-perl code. No, it seems to be a real bug. I could reproduce this on hppa (paer.d.o), and the failing test is due to differing cuesheet information: hppa gives REM FLAC__lead-in 1604068 REM FLAC__lead-out 170 153200460 where it's supposed to be REM FLAC__lead-in 88200 REM FLAC__lead-out 170 153200460 The output of 'metaflac --export-cuesheet-to=- ./data/test.flac' gives the correct number on hppa, so this doesn't seem to be a generic libflac problem. I'll try to hunt it down later today. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462249: libaudio-flac-header-perl: FTBFS on armel, hppa, m68k, powerpc, s390, sparc
On Wed, Jan 23, 2008 at 06:17:15PM +0200, Niko Tyni wrote: On Wed, Jan 23, 2008 at 03:07:48PM +0200, Riku Voipio wrote: Package: libaudio-flac-header-perl Version: 1.9-1 Severity: serious Justification: no longer builds from source Since the architectures where testsuite fails have little in common, it could be that this bug is a bug in the testsuite rather than testsuite exposing bugs in libaudio-flac-header-perl code. No, it seems to be a real bug. I could reproduce this on hppa (paer.d.o), and the failing test is due to differing cuesheet information: hppa gives REM FLAC__lead-in 1604068 REM FLAC__lead-out 170 153200460 where it's supposed to be REM FLAC__lead-in 88200 REM FLAC__lead-out 170 153200460 OK, I'm as far as seeing that this code (in Header.xs:250 or so) newSVpvf(REM FLAC__lead-in %UVuf\n, cs-lead_in); where cs-lead_in is a FLAC__uint64 and contains 88200, gives the Perl string REM FLAC__lead-in 1604068 on hppa. An explicit cast fixes it: newSVpvf(REM FLAC__lead-in %UVuf\n, (unsigned int) cs-lead_in); I can't really say I understand what's happening. The UVuf macro is defined as lu (in /usr/lib/perl/5.8/CORE/config.h), and fprintf(stderr, %lu\n, cs-lead_in) gives 88200 as expected. This is starting to look like a Perl bug in Perl_newSVpvf()... Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462249: libaudio-flac-header-perl: FTBFS on armel, hppa, m68k, powerpc, s390, sparc
forwarded 462249 http://rt.cpan.org/Public/Bug/Display.html?id=32630 thanks On Wed, Jan 23, 2008 at 11:33:21PM +0200, Niko Tyni wrote: On Wed, Jan 23, 2008 at 06:17:15PM +0200, Niko Tyni wrote: On Wed, Jan 23, 2008 at 03:07:48PM +0200, Riku Voipio wrote: Package: libaudio-flac-header-perl Version: 1.9-1 Severity: serious Justification: no longer builds from source OK, I'm as far as seeing that this code (in Header.xs:250 or so) newSVpvf(REM FLAC__lead-in %UVuf\n, cs-lead_in); where cs-lead_in is a FLAC__uint64 and contains 88200, gives the Perl string REM FLAC__lead-in 1604068 on hppa. An explicit cast fixes it: newSVpvf(REM FLAC__lead-in %UVuf\n, (unsigned int) cs-lead_in); Upstream bug filed as CPAN #32630. This is what I wrote there: The problem seems to be the newSVpvf() calls around Header.xs:250 - they are using the UVuf format, which expands at least here to lu (/usr/lib/perl/5.8/CORE/Config.h), while passing in a FLAC__int64 value. This means that the newSVpvf() stdarg function is expecting an unsigned long (32 bits) and getting an unsigned long long (64 bits). I don't claim to understand exactly what happens here; I suppose the behaviour is undefined, and apparently the caller and the callee are disagreeing about the register where the value should be stored. The wrong value (1604068 above) varies a bit, and seems to be whatever happens to be in r25 just before the function call. One fix is to explicitly cast the value to unsigned long in the newSVpvf() calls, but I guess this would lose information on 4G (32 bits) FLAC files. A better solution might be to do the decimal conversion on the C side with sprintf() and the %llu format before calling newSV*(). Waiting a while for upstream to respond before trying to patch this. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462569: libbarcode-code128-perl: fails to build with libtest-harness-perl
Package: libbarcode-code128-perl Version: 2.01-1 Severity: important As noticed by the Build Daemon From Hell http://lists.debian.org/debian-devel/2008/01/msg00869.html, libbarcode-code128-perl fails to build from source due to test failures when libtest-harness-perl is installed. The behaviour of Test::Harness has changed, and the skip logic in t/gif.t and t/png.t print output 1..0 ok 1 when an applicable version of GD.pm is not available. This is broken, and the new Test::Harness in libtest-harness-perl fails with Parse errors: Bad plan. You planned 0 tests but ran 1. Possibly the cleanest fix is to build-depend on libgd-gd2-perl and just remove t/gif.t (which is not used with newer versions of GD.pm) in debian/rules. As a side note: why the dance with an uuencoded debian/code128.png that differs from the upstream one with only a few bytes? There's no mention of this anywhere, not even in debian/changelog. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462456: lintian: Please consider testing if files in -dbg packages retain Dynamic Section entries
[ joeyh: it looks like you missed /emul in the dh_shlibdeps list, so
CCing #461339. ]
On Thu, Jan 24, 2008 at 03:33:31PM -0800, Russ Allbery wrote:
Neil Williams [EMAIL PROTECTED] writes:
Package: lintian
Version: 1.23.42
Severity: wishlist
See #462007 - I have come across a non-obvious problem in the use of
-dbg packages using dh_strip where, if a .install file exists for the
-dbg package, dh_install copies the unstripped object into the -dbg
build directory. When dh_strip --dbg-package=libfoo-dbg is then called,
it silently omits the file from the call to objcopy --only-keep-debug
(to prevent an objcopy error), resulting in an unstripped object file
being retained in the -dbg package that has a complete (and fully
functional) copy of the library embedded inside - as shown by the
presence of a full Dynamic Section under objdump -p. Without the
.install file, dh_strip takes care of copying the debug symbols into
place directly - no .install command is actually needed.
Some people intentionally put debugging builds of their libraries into the
-dbg package instead of detached debugging symbols. I think this test
might give false positives for that case. (Or are such library builds not
seupposed to go into /usr/lib/debug?)
As I understand this:
- detached debugging symbols go to /usr/lib/debug/$FULLPATH,
eg. /usr/lib/debug/usr/lib/libperl.so.5.8.8, where gdb will find them
- the few cases where a separate debugging build is preferred, it goes
directly under /usr/lib/debug, eg. /usr/lib/debug/libc.so.6, so it
can be used through LD_LIBRARY_PATH.
See also the GDB manual, section 15.2:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC156
This is also what dh_shlibdeps currently relies on. Quoting joeyh in #461339:
It seems possible, though unlikely, that a debug library might be
installed in /usr/lib/deubg/$foo/ rather than directly in
/usr/lib/debug/. So only looking in /usr/lib/debug/*.so* or the like
might miss some that should be processed.
I'm pretty sure that anything in
/usr/lib/debug/{lib,lib64,usr,bin,sbin,opt,dev}/ is going to be
separated debug symbols, and it could just ignore those directories and
process the rest.
I can't see anything about this in the policy, and the Developer's
Reference only talks about the detached symbol case.
I agree with Neil that a warning for packages that have the full library
object code under eg. /usr/lib/debug/usr/lib would be nice. OTOH, if
#461350 is implemented, those should also trigger the missing-dep-on-libc
error, since dh_shlibdeps doesn't look at the files.
FWIW, I can't find any usr/lib/debug subdirectories in the archive other than
the following:
sid% apt-file search -x 'usr/lib/debug/.*/' | egrep -v
'usr/lib/debug/(lib|usr|bin|emul|sbin)/'
sid%
which makes even the /usr/lib/debug/$package case look far-fetched.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462752: libparams-validate-perl: FTBFS with libtest-coverage-perl
Package: libparams-validate-perl Version: 0.89-2 Severity: important As noticed by Lucas' Build Daemon From Hell http://lists.debian.org/debian-devel/2008/01/msg00869.html, libparams-validate-perl fails to build with libtest-pod-coverage-perl, apparently because of changes in recent versions of Pod::Coverage. Upstream has been informed, but they aren't interested, because the tests are disabled by default and we're deliberately enabling them. See http://rt.cpan.org/Public/Bug/Display.html?id=31177 . I'm not sure if it's better to leave the POD tests disabled, ie. remove the IS_MAINTAINER setting from debian/rules, or fix the tests. The IS_MAINTAINER=0 approach is a bit cleaner, but then the hypothetical Debian user wanting to modify Params::Validate and check the documentation of his new code is going to hit this issue instead of us... An easy way to fix the tests is to add all the naked subroutines to the 'trustme' list in t/pod-coverage.t, which is presumably what the maintainer will do if they ever have to upgrade Pod::Coverage. I see build-conflicting with libtest-coverage-perl as the worst option, but even that would be better than the current situation leading to unexpected build failures. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462773: libcurses-perl: should decide between wide characters or not
Package: libcurses-perl Version: 1.20-1 Severity: normal The upstream code of libcurses-perl prefers the wide-character version of the ncurses library when available. We currently build-depend on libncurses5. When built with libncursesw5 installed the build result will be different from the package in the archive. This shows up on Lucas' Build Daemon From Hell tests http://lists.debian.org/debian-devel/2008/01/msg00869.html, and I think it should be fixed one way or other. I suggest build-depending on libncursesw5, ie. enabling wide-character support, since that's what upstream prefers too. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462775: libcurses-perl: FORMS support missing
Package: libcurses-perl Version: 1.20-1 Severity: wishlist The FORMS support in libcurses-perl is currently missing. There's no note of this in the changelog, but debian/README.Debian states This package is built with support for MENUS and PANELS. FORMS support does not yet work under Debian. Jay Bonci [EMAIL PROTECTED], Tue Jun 7 14:56:18 EDT 2005 The problem is probably the one explained in the INSTALL file: /usr/lib/perl/5.8/CORE/form.h conflicts with /usr/include/form.h from libncurses5-dev, and the Perl directory is first on the include path. An easy way to fix this is to use libncursesw5-dev instead (see #462773); then we have form.h in /usr/include/ncursesw and the directory first on the include path. Filing this to document the issue. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462927: speedy-cgi-perl: FTBFS with Perl 5.10
Package: speedy-cgi-perl Version: 2.22-8 Severity: important Tags: patch The speedy-cgi-perl package fails to build with Perl 5.10 (currently in experimental) due to two issues: - Pod::Text::pod2text() calling conventions have changed - the New() macro has been deprecated in 5.9.3 (see perlapi.pod) and its expansions in speedy_perl.c result in syntax errors. The Newx() macro works fine and is now the recommended method. Patch attached. This works with 5.8 too, so I'll upload a fixed version as soon as I find out what's causing these: dpkg-shlibdeps: warning: symbol apr_table_get used by debian/libapache2-mod-speedycgi/usr/lib/apache2/modules/mod_speedycgi.so found in none of the libraries. dpkg-shlibdeps: warning: symbol ap_scan_script_header_err_brigade used by debian/libapache2-mod-speedycgi/usr/lib/apache2/modules/mod_speedycgi.so found in none of the libraries. dpkg-shlibdeps: warning: symbol apr_file_gets used by debian/libapache2-mod-speedycgi/usr/lib/apache2/modules/mod_speedycgi.so found in none of the libraries. [...] Cheers, -- Niko Tyni [EMAIL PROTECTED] #! /bin/sh /usr/share/dpatch/dpatch-run ## 95perl5.10.dpatch by Niko Tyni [EMAIL PROTECTED] ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Fix build failures with Perl 5.10. ## DP: Pod::Text::pod2text() calling conventions changed ## DP: use Newx() instead of New() @DPATCH@ diff -urNad speedy-cgi-perl-2.22~/Makefile.PL speedy-cgi-perl-2.22/Makefile.PL --- speedy-cgi-perl-2.22~/Makefile.PL 2008-01-28 12:17:32.0 +0200 +++ speedy-cgi-perl-2.22/Makefile.PL2008-01-28 12:18:35.0 +0200 @@ -71,7 +71,7 @@ chmod -R u+w,go-w,go+r . README: src/SpeedyCGI.pm - cd src $(PERL) -e use Pod::Text; pod2text(-80) SpeedyCGI.pm ../README + cd src pod2text -80 SpeedyCGI.pm ../README README.html: src/SpeedyCGI.pm cd src pod2html SpeedyCGI.pm ../README.html $(RM_F) pod2h* diff -urNad speedy-cgi-perl-2.22~/src/speedy_backend_main.h speedy-cgi-perl-2.22/src/speedy_backend_main.h --- speedy-cgi-perl-2.22~/src/speedy_backend_main.h 2003-10-07 07:03:48.0 +0300 +++ speedy-cgi-perl-2.22/src/speedy_backend_main.h 2008-01-28 12:18:22.0 +0200 @@ -38,7 +38,7 @@ #else -#define speedy_new(s,n,t) New(123,s,n,t) +#define speedy_new(s,n,t) Newx(s,n,t) #define speedy_renew Renew #define speedy_freeSafefree
Bug#463059: net-snmp: FTBFS with Perl 5.10
Package: net-snmp Version: 5.4.1~dfsg-5 Severity: important Tags: patch User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package fails to build with Perl 5.10 (currently in experimental) because of a bugfix in Extutils::MakeMaker: it doesn't create an empty usr/share/perl5 directory anymore. dh_install -plibsnmp-perl dh_install: libsnmp-perl missing files (debian/tmp/usr/share/perl*), aborting make: *** [binary-install/libsnmp-perl] Error 1 Just removing debian/tmp/usr/share/perl* from debian/libsnmp-perl.install should fix this without any problems with Perl 5.8. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400733: perl: segfault in Perl_sv_pos_b2u()
On Fri, Mar 30, 2007 at 10:53:22AM +0300, Niko Tyni wrote:
On Tue, Nov 28, 2006 at 01:51:03PM +0200, Niko Tyni wrote:
Package: perl
Version: 5.8.8-6.1
Severity: normal
Here's a reproducable segfault that occurs with Request Tracker inside
the Text::Tabs module. A minimal testcase is:
#!/usr/bin/perl -w
use strict;
use Encode;
my $s = \x{c3}\x{84}\x{54}\x{c3}\x{84}\x{5c}\x{9};
$_ = Encode::decode('utf8', $s);
s{\t}{pos()}e;
This is the same as #385123, so merging.
It's rt.perl.org #39893 and #40989 and fixed in bleadperl.
Just verified that this is fixed in 5.10.0-3 from experimental.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463110: etpan-ng: unneeded build-dependency on libperl-dev
Package: etpan-ng Version: 0.7.1-5 Severity: minor While looking for packages that may need a rebuild in the upcoming Perl 5.10 transition, I noticed that etpan-ng build-depends on libperl-dev but doesn't actually use it for anything. The perlembed tests in configure.in are commented out, and the Changelog says 'disabled perl in build'. Indeed, src/etpan-perl.c is apparently not compiled at all. The package seems to build fine without libperl-dev, so please consider removing it from the build-dependencies. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463098: libsys-cpu-perl: missing dependency on perlapi-5.8.*
Package: libsys-cpu-perl Version: 0.40-2 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes a binary perl module, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463097: liblasso-perl: missing perlapi-5.8.* dependency
Package: liblasso-perl Version: 2.1.1-2 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes a binary perl module, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463095: libhamlib2-perl: missing perlapi-5.8.* dependency
Package: libhamlib2-perl Version: 1.2.6.2-5 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes a binary perl module, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463094: libclearsilver-perl: missing dependencies on perlapi-5.8.* and shared libraries
Package: libclearsilver-perl
Version: 0.10.4-1
Severity: important
User: [EMAIL PROTECTED]
Usertags: perl-5.10-transition
This package includes binary perl modules, but it's missing a dependency
on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1].
These dependencies are needed for the upcoming Perl 5.10 transition [2]
to determine which packages need to be rebuilt.
Additionally, the package is missing shared library dependencies
(${shlibs:Depends}), which is another policy violation.
[1]
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps
[2] http://wiki.debian.org/Perl5.10Transition
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463093: libclass-methodmaker-perl: FTBFS with Perl 5.10
Package: libclass-methodmaker-perl Version: 2.07-2 Severity: important Tags: fixed-upstream User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package fails to build from source with Perl 5.10 (currently in experimental): /usr/bin/perl /usr/share/perl/5.10/ExtUtils/xsubpp -typemap /usr/share/perl/5.10/ExtUtils/typemap MethodMaker.xs MethodMaker.xsc mv MethodMaker.xsc MethodMaker.c Please specify prototyping behavior for MethodMaker.xs (see perlxs manual) cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\2.07\ -DXS_VERSION=\2.07\ -fPIC -I/usr/lib/perl/5.10/CORE MethodMaker.c MethodMaker.xs: In function 'XS_Class__MethodMaker_set_sub_name': MethodMaker.xs:12: error: incompatible types in assignment make[1]: *** [MethodMaker.o] Error 1 make[1]: Leaving directory `/home/niko/libclass-methodmaker-perl-2.07' make: *** [build-stamp] Error 2 This is fixed in the unauthorized CPAN release 2.10 at http://search.cpan.org/~schwigon/Class-MethodMaker-2.10/ . I have verified that 2.10 compiles and passes the test suite with Perl 5.10. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463090: libclass-methodmaker-perl: missing perlapi-5.8.* and shlibs dependencies
Package: libclass-methodmaker-perl
Version: 2.07-2
Severity: important
User: [EMAIL PROTECTED]
Usertags: perl-5.10-transition
This package includes binary perl modules, but it's missing a dependency
on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1].
These dependencies are needed for the upcoming Perl 5.10 transition [2]
to determine which packages need to be rebuilt.
Additionally, the libc6 dependency that would come from ${shlibs:Depends}
is missing.
[1]
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps
[2] http://wiki.debian.org/Perl5.10Transition
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463089: libqt-perl: missing perlapi-5.8.x dependency
Package: libqt-perl Version: 3.008-2 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes binary perl modules, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463085: libcflow-perl: missing perlapi-5.8.* dependency
Package: libcflow-perl Version: 1:0.68-11 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition Your package includes compiled Perl XS code, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463080: perl-tk: FTBFS with Perl 5.10
Package: perl-tk Version: 1:804.027-8 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition Your package fails to build with Perl 5.10, currently in experimental. Looking at the changelog, this seems to be fixed in the unauthorized CPAN release 804.028 at http://search.cpan.org/~srezic/Tk-804.028/. I haven't verified this, though. More information on the Perl 5.10 transition can be found at http://wiki.debian.org/Perl5.10Transition. cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\804.027\ -DXS_VERSION=\804.027\ -fPIC -I/usr/lib/perl/5.10/CORE -Wall -Wno-implicit-int -Wno-comment -Wno-unused -D__USE_FIXED_PROTOTYPES__ tkGlue.c tkGlue.c: In function 'PushObjCallbackArgs': tkGlue.c:1625: warning: unknown conversion type character '_' in format tkGlue.c:1625: warning: too many arguments for format tkGlue.c:1649: warning: unknown conversion type character '_' in format tkGlue.c:1649: warning: too many arguments for format tkGlue.c:1673: warning: unknown conversion type character '_' in format tkGlue.c:1673: warning: too many arguments for format tkGlue.c:1732: warning: format '%ld' expects type 'long int', but argument 2 has type 'unsigned int' tkGlue.c: In function 'Lang_TaintCheck': tkGlue.c:2151: warning: unknown conversion type character '_' in format tkGlue.c:2151: warning: too many arguments for format tkGlue.c: In function 'XEvent_Info': tkGlue.c:5014: warning: cast to pointer from integer of different size tkGlue.c: In function 'do_comp': tkGlue.c:5237: error: 'PMOP' has no member named 'op_pmdynflags' tkGlue.c:5237: error: 'PMdf_DYN_UTF8' undeclared (first use in this function) tkGlue.c:5237: error: (Each undeclared identifier is reported only once tkGlue.c:5237: error: for each function it appears in.) tkGlue.c:5238:44: error: macro pregcomp passed 3 arguments, but takes just 2 tkGlue.c:5238: error: 'pregcomp' undeclared (first use in this function) tkGlue.c: In function 'Tcl_RegExpRange': tkGlue.c:5360: error: 'regexp' has no member named 'startp' tkGlue.c:5360: error: 'regexp' has no member named 'endp' tkGlue.c:5362: error: 'regexp' has no member named 'startp' tkGlue.c:5363: error: 'regexp' has no member named 'endp' tkGlue.c: In function 'install_vtab': tkGlue.c:5459: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' tkGlue.c: In function 'Boot_Glue': tkGlue.c:5493: warning: initialization from incompatible pointer type tkGlue.c:5501: warning: assignment from incompatible pointer type make[1]: *** [tkGlue.o] Error 1 make[1]: Leaving directory `/home/niko/perl-tk-804.027' make: *** [build-stamp] Error 2 Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463099: libclone-perl: FTBFS with Perl 5.10
Package: libclone-perl Version: 0.22-1 Severity: important Tags: fixed-upstream User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package is failing to build with Perl 5.10 (currently in experimental): cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O2 -DVERSION=\0.22\ -DXS_VERSION=\0.22\ -fPIC -I/usr/lib/perl/5.10/CORE Clone.c Clone.xs: In function 'hv_clone': Clone.xs:52: warning: suggest parentheses around assignment used as truth value Clone.xs:55: warning: value computed is not used Clone.xs: In function 'av_clone': Clone.xs:69: warning: unused variable 'val' Clone.xs: In function 'rv_clone': Clone.xs:100: warning: unused variable 'visible' Clone.xs:99: warning: unused variable 'rv' Clone.xs: In function 'sv_clone': Clone.xs:180: error: duplicate case value Clone.xs:170: error: previously used here Clone.xs:259: warning: suggest parentheses around assignment used as truth value Clone.xs:222: warning: unused variable 'vtable' make[1]: *** [Clone.o] Error 1 make[1]: Leaving directory `/home/niko/libclone-perl-0.22' make: *** [build-stamp] Error 2 This is fixed upstream; I tested 0.28 and it built OK and passed the test suite. The unconditional rmdir in debian/rules needs also fixing, as ExtUtils::MakeMaker doesn't create an empty usr/share/perl5 anymore. Suggested fix (from recent dh-make-perl templates): [ ! -d $(TMP)/usr/lib/perl5 ] || rmdir --ignore-fail-on-non-empty --parents --verbose $(TMP)/usr/lib/perl5 Information on the Perl 5.10 transition can be found at http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463083: eperl: FTBFS with Perl 5.10
Package: eperl Version: 2.2.14-15 Severity: important User: [EMAIL PROTECTED] Usertag: perl-5.10-transition Your package fails to build with Perl 5.10 (currently in experimental) on amd64: cc -Wl,-E -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -o eperl eperl_main.o eperl_perl5.o eperl_parse.o eperl_pp.o eperl_sys.o eperl_http.o eperl_getopt.o eperl_debug.o eperl_config.o eperl_version.o eperl_readme.o eperl_license.o eperl_logo.o eperl_powered.o /usr/lib/perl/5.10/auto/DynaLoader/DynaLoader.a -lperl -ldl -lm -lpthread -lc -lcrypt cc: /usr/lib/perl/5.10/auto/DynaLoader/DynaLoader.a: No such file or directory make[1]: *** [eperl] Error 1 make[1]: Leaving directory `/home/niko/eperl-2.2.14' make: *** [build-stamp] Error 2 Indeed, there's no DynaLoader.a in perl-base anymore. Unsetting 'perl_dla' in configure.in and running autoconf makes the compilation succeed, and 'make test' reports no failures. I suppose this should be determined through ExtUtils::Embed - compare $ perl -MExtUtils::Embed -e ldopts -Wl,-E -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -lperl -ldl -lm -lpthread -lc -lcrypt on 5.10, and sid$ perl -MExtUtils::Embed -e ldopts -Wl,-E -L/usr/local/lib /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -lpthread -lc -lcrypt on 5.8. Information on the Perl 5.10 transition can be found at http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463086: libgdal-perl: missing perlapi-5.8.* dependency
Package: libgdal-perl Version: 1.5.0-2 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition Your package includes binary perl modules, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463130: inkscape: unneeded build-dependency on libperl-dev
Package: inkscape Version: 0.45.1-1 Severity: minor While looking for packages that need to be rebuilt in the upcoming Perl 5.10 transition, I noticed that inkscape doesn't seem to need libperl-dev for anything. The build-dependency is probably a leftover from versions before 0.44-1, which removed the '--with-perl' configure option. Please consider removing the dependency. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463146: megahal: missing dependency on perlapi-5.8.*
Package: megahal Version: 9.1.1a-3 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes binary perl modules, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463143: pidgin: missing dependencies on perlapi-5.8.*
Package: pidgin Version: 2.3.1-2 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition The pidgin and libpurple0 packages include binary Perl modules in usr/lib/perl5, but are missing dependencies on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463148: wml: unneeded build-dependency on libperl-dev
Package: wml Version: 2.0.11-3 Severity: minor While looking for packages that need to be rebuilt in the upcoming Perl 5.10 transition, I noticed that wml doesn't seem to need libperl-dev for anything. Maybe it's a leftover from a time when the bundled eperl was used? I built the package without libperl-dev and got the exact same files and dependencies in the resulting binary package. Please consider removing the unneeded build-dependency. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463145: razor: missing dependency on perlapi-5.8.*
Package: razor Version: 1:2.84-5 Severity: important User: [EMAIL PROTECTED] Usertags: perl-5.10-transition This package includes a binary perl module, but it's missing a dependency on perlapi-5.8.*. See the Debian Perl Policy, section 4.4.2 [1]. These dependencies are needed for the upcoming Perl 5.10 transition [2] to determine which packages need to be rebuilt. [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps [2] http://wiki.debian.org/Perl5.10Transition Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463138: lintian: package-contains-empty-perl-directory and Perl 5.10
Package: lintian Version: 1.23.43 Severity: wishlist Please consider a note about the unconditional rmdir issue in the package-contains-empty-perl-directory description. Something like this: This package installs an empty /usr/lib/perl5 or /usr/share/perl5 directory. This is an artifact of ExtUtils::MakeMaker and isn't harmful, but it's messy. It's preferrable to remove the directory the package doesn't use (/usr/share/perl5 for binary Perl modules and /usr/lib/perl5 for pure Perl modules) in debian/rules after running make install. + + Note that ExtUtils::MakeMaker has been fixed in Perl 5.10, so make + sure not to fail if the directory does not exist in the first place. + One implementation can be found in the dh-make-perl debian/rules templates. See #458143 for some background to this. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463134: swish-e: please depend on ${perl:Depends} instead of recommending it
Package: swish-e
Version: 2.4.5-2
Severity: important
User: [EMAIL PROTECTED]
Usertags: perl-5.10-transition
While I understand the idea of keeping the perl-related dependencies as
recommendations, ${perl:Depends} is special.
Quoting the Debian Perl Policy, section 4.4.2 [1]
4.4.2 Binary Modules
Binary modules must specify a dependency on either perl or perl-base
with a minimum version of the perl package used to build the module,
and must additionally depend on the expansion of perlapi-$Config{version}
using the Config module.
As perl-base is Essential:yes and provides these dependencies, putting
them in the Recommends field is not going to save any disk space from
anyone. The only thing it does is make it possible for the binary module
to break when a newer version of Perl has binary-incompatible changes.
This is actually going to happen soon with the transition to Perl 5.10 [2].
Please move ${perl:Depends} into the Depends: field.
[1]
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps
[2] http://wiki.debian.org/Perl5.10Transition
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463142: lintian: please check for a missing perlapi-* dependency
Package: lintian
Version: 1.23.43
Severity: wishlist
Quoting the Debian Perl Policy:
4.4.2 Binary Modules
Binary modules must specify a dependency on either perl or perl-base
with a minimum version of the perl package used to build the module, and
must additionally depend on the expansion of perlapi-$Config{version}
using the Config module.
The perlapi-* dependencies are particularly important for the upcoming
Perl 5.10 transition.
Please consider a lintian error at least on packages that have files
matching usr/lib/perl5/.*\.so but don't depend on perlapi-5\..*. There
are currently 10-15 packages in the archive that should trigger this,
including:
libcflow-perl
libgdal-perl
libqt-perl
libclass-methodmaker-perl
libclearsilver-perl
libhamlib2-perl
liblasso-perl
libsys-cpu-perl
libpurple0
megahal
pidgin
razor
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463152: suck: please fix embedded perl support or drop the libperl-dev dependency
Package: suck
Version: 4.3.2-5
Severity: normal
Tags: patch
Although suck build-depends on libperl-dev, the embedded perl support
is currently not enabled. From the buildd log:
checking for libperl.a... not found
I'm attaching a patch that enables the Perl support again (after running
autoconf, of course.) This compiles with both Perl 5.8 and the upcoming
5.10 (currently in experimental). I haven't tested it at all, though.
Alternatively, please drop the libperl-dev dependency and explicitly
disable the Perl support. It looks like nobody has been missing it for
a long time.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
diff -u suck-4.3.2/debian/changelog suck-4.3.2/debian/changelog
--- suck-4.3.2/debian/changelog
+++ suck-4.3.2/debian/changelog
@@ -1,3 +1,9 @@
+suck (4.3.2-6) UNRELEASED; urgency=low
+
+ * add perl support
+
+ -- Niko Tyni [EMAIL PROTECTED] Tue, 29 Jan 2008 22:06:43 +0200
+
suck (4.3.2-5) unstable; urgency=low
* fix rpostoptions in get-news (Closes: #363321)
diff -u suck-4.3.2/configure.in suck-4.3.2/configure.in
--- suck-4.3.2/configure.in
+++ suck-4.3.2/configure.in
@@ -101,12 +101,12 @@
if test $PERL = true; then
found=no
AC_MSG_CHECKING([for libperl.a])
- for path in `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
+ for path in /usr/lib `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
if test -f $path/libperl.a; then
AC_MSG_RESULT($path)
if test $found = no; then
AC_MSG_CHECKING([for libperl.so])
- for path in `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
+ for path in /usr/lib `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
if test -f $path/libperl.so; then
AC_MSG_RESULT($path)
found=yes
@@ -131,10 +131,10 @@
fi
done
if test $found = yes; then
-PERL_DEFS=-DPERL_EMBED -Dbool=char -DHAS_BOOL
-PERL_LIB=-lperl
-PERL_LIB_LOC=-L$path
-PERL_INC_LOC=-I$path
+PERL_DEFS=-DPERL_EMBED -Dbool=char -DHAS_BOOL $(perl -MExtUtils::Embed -e ccopts)
+PERL_LIB=$(perl -MExtUtils::Embed -e ldopts)
+PERL_LIB_LOC=
+PERL_INC_LOC=
AC_CHECK_LIB(m, cos, [PERL_LIB=$PERL_LIB -lm])
AC_CHECK_LIB(crypt, crypt, [PERL_LIB=$PERL_LIB -lcrypt])
else
interdiff impossible; taking evasive action
reverted:
unchanged:
diff -u suck-4.3.2/rpost.c suck-4.3.2/rpost.c
--- suck-4.3.2/rpost.c
+++ suck-4.3.2/rpost.c
@@ -28,6 +28,7 @@
# define PL_na (na)
#endif
#endif /* OLD_PERL */
+static PerlInterpreter *my_perl;
#endif
#ifdef HAVE_DIRENT_H
only in patch2:
unchanged:
--- suck-4.3.2.orig/killprg.c
+++ suck-4.3.2/killprg.c
@@ -66,6 +66,7 @@
# define PL_na (na)
#endif
#endif /* OLD_PERL */
+static PerlInterpreter *my_perl;
#endif
/* KILLPRG.C -*/
Bug#463143: pidgin: missing dependencies on perlapi-5.8.*
On Tue, Jan 29, 2008 at 06:42:15PM -0500, Ari Pollak wrote:
Does libpurple0 need to depend on perlapi if it really should depend on
libperl? I'm not yet sure why the latter dependency isn't happening.
It does depend on libperl5.8 here, and that's because
usr/lib/purple-2/perl.so is linked against libperl.so.5.8, so
${shlibs:Depends} picks it up.
The libperl5.8 dependency is for binaries embedding perl, but the
perlapi-* dependency is to ensure the Perl XS binary module interface is
the right one. Here it's needed for usr/lib/perl5/auto/Purple/Purple.so .
For the purposes of the Perl 5.10 transition, the libperl5.8 dependency
already makes sure pidgin will be rebuilt. Missing perlapi-* is still a
violation of the Perl policy, though.
Just adding ${perl:Depends} (and running dh_perl) should do the right thing.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463229: libdbi-perl: dependency on perlapi-5.8.4 is hardcoded
Package: libdbi-perl
Version: 1.601-1
Severity: important
User: [EMAIL PROTECTED]
Usertags: perl-5.10-transition
This package depends on perlapi-5.8.4 even when compiled against another
version of Perl, including 5.10 (currently in experimental). This is a
violation of the Perl policy. The perl dependencies should be automated
through ${perl:Depends}.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463152: suck: please fix embedded perl support or drop the libperl-dev dependency
tag 463152 -patch
thanks
On Tue, Jan 29, 2008 at 10:15:28PM +0200, Niko Tyni wrote:
Package: suck
Version: 4.3.2-5
Severity: normal
Tags: patch
I'm attaching a patch that enables the Perl support again (after running
autoconf, of course.) This compiles with both Perl 5.8 and the upcoming
5.10 (currently in experimental). I haven't tested it at all, though.
And it shows. New try attached, I think this one has a slightly better
chance of working.
Still, removing the patch for now because of the lack of testing.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
diff -u suck-4.3.2/debian/changelog suck-4.3.2/debian/changelog
--- suck-4.3.2/debian/changelog
+++ suck-4.3.2/debian/changelog
@@ -1,3 +1,9 @@
+suck (4.3.2-6) UNRELEASED; urgency=low
+
+ * add perl support
+
+ -- Niko Tyni [EMAIL PROTECTED] Tue, 29 Jan 2008 22:06:43 +0200
+
suck (4.3.2-5) unstable; urgency=low
* fix rpostoptions in get-news (Closes: #363321)
diff -u suck-4.3.2/configure.in suck-4.3.2/configure.in
--- suck-4.3.2/configure.in
+++ suck-4.3.2/configure.in
@@ -101,12 +101,12 @@
if test $PERL = true; then
found=no
AC_MSG_CHECKING([for libperl.a])
- for path in `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
+ for path in /usr/lib `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
if test -f $path/libperl.a; then
AC_MSG_RESULT($path)
if test $found = no; then
AC_MSG_CHECKING([for libperl.so])
- for path in `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
+ for path in /usr/lib `$whichperl -e 'foreach $i (@INC) { printf(%s , $i) }'`; do
if test -f $path/libperl.so; then
AC_MSG_RESULT($path)
found=yes
@@ -131,10 +131,10 @@
fi
done
if test $found = yes; then
-PERL_DEFS=-DPERL_EMBED -Dbool=char -DHAS_BOOL
-PERL_LIB=-lperl
-PERL_LIB_LOC=-L$path
-PERL_INC_LOC=-I$path
+PERL_DEFS=-DPERL_EMBED -Dbool=char -DHAS_BOOL $(perl -MExtUtils::Embed -e ccopts)
+PERL_LIB=$(perl -MExtUtils::Embed -e ldopts)
+PERL_LIB_LOC=
+PERL_INC_LOC=
AC_CHECK_LIB(m, cos, [PERL_LIB=$PERL_LIB -lm])
AC_CHECK_LIB(crypt, crypt, [PERL_LIB=$PERL_LIB -lcrypt])
else
interdiff impossible; taking evasive action
reverted:
unchanged:
diff -u suck-4.3.2/rpost.c suck-4.3.2/rpost.c
--- suck-4.3.2/rpost.c
+++ suck-4.3.2/rpost.c
@@ -28,6 +28,7 @@
# define PL_na (na)
#endif
#endif /* OLD_PERL */
+static PerlInterpreter *my_perl;
#endif
#ifdef HAVE_DIRENT_H
@@ -147,7 +148,7 @@
myargs.do_ssl = FALSE;
myargs.ssl_struct = NULL;
#ifdef PERL_EMBED
- myargs.perl_int = NULL;
+ myargs.perl_int = my_perl = NULL;
#endif
/* have to do this next so if set on cmd line, overrides this */
only in patch2:
unchanged:
--- suck-4.3.2.orig/killprg.c
+++ suck-4.3.2/killprg.c
@@ -66,6 +66,7 @@
# define PL_na (na)
#endif
#endif /* OLD_PERL */
+static PerlInterpreter *my_perl;
#endif
/* KILLPRG.C -*/
@@ -373,7 +374,7 @@
char *prgs[] = { ptr, ptr};
- if((master-perl_int = perl_alloc()) == NULL) {
+ if((master-perl_int = my_perl = perl_alloc()) == NULL) {
retval = FALSE;
error_log(ERRLOG_REPORT, killp_phrases[14], NULL);
}
Bug#450717: libterm-readkey-perl: Call to ReadKey(0) is not blocking anymore
On Fri, Nov 09, 2007 at 04:41:22PM +0100, Michael Gebetsroither wrote:
Package: libterm-readkey-perl
Version: 2.30-3
Severity: normal
while (not defined ($x = ReadKey(0))) {}
The real problem is, that after starting start-x and returning, the cpu
runs at 100% because ReadKey does not block anymore and returnes
undefined value all of the time.
Hi,
the child process is probably setting O_NONBLOCK on STDIN.
Does it help if you do something like
use Fcntl qw(F_GETFL F_SETFL O_NONBLOCK);
$flags = fcntl(STDIN, F_GETFL, 0)
or die Can't get flags for STDIN: $!\n;
$flags = fcntl(STDIN, F_SETFL, $flags ~O_NONBLOCK)
or die Can't set flags for STDIN: $!\n;
after the child process has returned?
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450744: libdbd-sqlite3-perl: segv re-using statement after error
forwarded 450744 http://rt.cpan.org/Public/Bug/Display.html?id=30558 tag 450744 patch thanks On Sat, Nov 10, 2007 at 07:50:17AM +1100, Kevin Ryde wrote: Package: libdbd-sqlite3-perl Version: 1.14-1 Severity: normal I suspect that when sqlite_st_execute gets an insert error like this it ends up freeing the underlying sqlite3_stmt object, so that a further execute of it bombs. I think the free is done by the following line in sqlite_st_execute (the first one, at return -5), /* There are bug reports that say this should be sqlite3_reset() */ sqlite3_finalize(imp_sth-stmt); Hi, I agree, it indeed looks like this should be sqlite3_reset(). The same issue is reported upstream as CPAN #30558: http://rt.cpan.org/Public/Bug/Display.html?id=30558 I'll forward your comments there. It would be nice to have this fixed upstream, although the fix looks quite safe and doesn't break anything in the DBD::SQLite test suite. Thanks for your report, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450882: libgdal-ruby1.8: empty package on alpha and amd64
Package: libgdal-ruby1.8
Version: 1.4.2-3
Severity: grave
Justification: renders package unusable
The libgdal-ruby1.8 package is empty on alpha and amd64. The problem
seems to be linking PIC and non-PIC code together. From the amd64
build log:
/usr/bin/ld: gdal_wrap.o: relocation R_X86_64_32 against `a local symbol' can
not be used when making a shared object; recompile with -fPIC
gdal_wrap.o: could not read symbols: Bad value
make[4]: Leaving directory `/build/buildd/gdal-1.4.2/swig/ruby'
Please make the build fail on compiler errors instead of producing
an empty package. It looks like the problem is the for loop in
swig/GNUmakefile; using something like
for dir in ${BINDINGS}; do (cd $$dir; make build) || exit; done
in all the loops should do.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450885: liblscp-dev: missing documentation
Package: liblscp-dev Version: 0.5.5-0.1 Hi, the file /usr/share/doc-base/liblscp is referring to API documentation at /usr/share/doc/liblscp-dev/html/index.html, which is currently missing. It looks like a build-dependency on doxygen should be enough to fix this. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451102: dangling symlink /usr/share/doc/libgcc1-dbg
Package: libgcc1-dbg Version: 1:4.2.2-3 Severity: minor Hi, The symlink /usr/share/doc/libgcc1-dbg points to gcj-4.2-base without depending on the corresponding package. I assume the target should be gcc-4.2-base instead. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgcc1-dbg depends on: ii gcc-4.2-base 4.2.2-3The GNU Compiler Collection (base ii libgcc1 1:4.2.2-3 GCC support library libgcc1-dbg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451362: rt3.6-rtfm: database modification permission setting ignored when preconfiguring
Package: rt3.6-rtfm Version: 2.2.1-1 Severity: serious Justification: maintainer's opinion If the config script is run for the second time without an existing /etc/rt3.6-rtfm/debian.conf, the answer to 'rt3.6-rtfm/modify-database-permission' is unconditionally set to 'allow', ignoring the user setting. Unfortunately, this includes the most common case of installing the package with apt and preconfiguration. I could have sworn I tested this. How embarrassing. I'll prepare a new version as soon as possible. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451470: libldns-dev: API documentation missing
Package: libldns-dev Version: 1.2.1-1 Severity: normal The API documentation is currently not included in libldns-dev on most architectures because of a missing build-dependency on doxygen. The sparc package is an exception; the buildd apparently happens to have doxygen already installed. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450915: file conflicts between packages
On Mon, Nov 12, 2007 at 08:13:43AM +0100, Michael Ablassmeier wrote: Package: par, libpar-packer-perl Severity: serious Justification: policy violation both par and libpar-packer-perl do ship `/usr/bin/par' but neither conflict or add a diversion, thus fail to be installed in the same environment: Hi, the libpar-packer-perl version used to be in libpar-perl and was called par.pl. I think the name got accidentally changed when part of libpar-perl was split into libpar-packer-perl. The par package clearly has a better claim to the name. I'll change the libpar-packer-perl version back into par.pl at least until we come up with a better solution wrt. policy 10.4: When scripts are installed into a directory in the system PATH, the script name should not include an extension such as `.sh' or `.pl' that denotes the scripting language currently used to implement it. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451600: libpar-packer-perl: /usr/bin/par.pl vs. policy 10.4
Package: libpar-packer-perl Version: 0.976-5 Severity: normal As discussed on debian-perl, the name of /usr/bin/par.pl doesn't comply with policy 10.4, which says that the .pl suffix should be removed. Since /usr/bin/par is already taken by the par package, we need something else. Russ Allberry suggested par-archive, which sounds good to me. Unless there are objections, I'm going to go forward with that and rename the script. [1] http://lists.debian.org/debian-perl/2007/11/msg00035.html -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpar-packer-perl depends on: ii libarchive-zip-perl 1.18-1 Module for manipulation of ZIP arc ii libcompress-zlib-perl 2.008-1Perl module for creation and manip ii libgetopt-argvfile-perl 1.10-3 Perl module for reading script opt ii libmodule-scandeps-perl 0.77-1 perl module to recursively scan Pe ii libpar-dist-perl 0.25-1 perl module to create and manipula ii libpar-perl 0.976-2Perl Archive Toolkit ii perl 5.8.8-12 Larry Wall's Practical Extraction ii perl-modules 5.8.8-12 Core Perl modules Versions of packages libpar-packer-perl recommends: ii perl-tk [libtk-perl] 1:804.027-7 Perl module providing the Tk graph -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451599: libpar-packer-perl: missing shared library dependencies
Package: libpar-packer-perl
Version: 0.976-5
Severity: serious
Justification: Policy 3.5
The libpar-packer-perl package includes dynamically linked binaries
(/usr/bin/parl and /usr/bin/parldyn) but doesn't depend on
${shlibs:Depends}.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libpar-packer-perl depends on:
ii libarchive-zip-perl 1.18-1 Module for manipulation of ZIP arc
ii libcompress-zlib-perl 2.008-1Perl module for creation and manip
ii libgetopt-argvfile-perl 1.10-3 Perl module for reading script opt
ii libmodule-scandeps-perl 0.77-1 perl module to recursively scan Pe
ii libpar-dist-perl 0.25-1 perl module to create and manipula
ii libpar-perl 0.976-2Perl Archive Toolkit
ii perl 5.8.8-12 Larry Wall's Practical Extraction
ii perl-modules 5.8.8-12 Core Perl modules
Versions of packages libpar-packer-perl recommends:
ii perl-tk [libtk-perl] 1:804.027-7 Perl module providing the Tk graph
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451602: afnix-doc: should be Architecture:all
Package: afnix-doc Version: 1.5.2-2 Severity: normal It looks like the afnix-doc package only contains architecture-independent files, so it should be Architecture:all instead of any. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451606: when: should be Architecture:all
Package: when Version: 1.1.0-1 Severity: normal The when package contains only architecture-independent files, so it should be Architecture: all. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451619: libmime-perl: new upstream version available
Package: libmime-perl Version: 5.420-2 Severity: wishlist Version 5.424 is available on CPAN. It's not caught by debian/watch, because it's now under a different author. It should be noted that there's at least one backward incompatibility: 5.420_01 2007-06-18 Dave O'Neill [EMAIL PROTECTED] * (cleanup) Remove support for recycling tempfiles ( tmp_recycling() and its usage in new_tmpfile() ) This breaks rt-mailgate in request-tracker3.6 ( 3.6.5, already updated in lenny) and request-tracker3.4 (which is being removed from Debian). It's also mentioned in the SOAP::Packager documentation, inside the Debian soap-lite package. This is probably going to hit some user programs as well. I just filed CPAN #30797 about this, pleading that the method would be restored as a no-op or similar. If that isn't succesful, I suppose that at least a NEWS.Debian entry would be in order. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libmime-perl depends on: ii libconvert-binhex-perl 1.119+pristine-2 Perl5 module for extracting data f ii libio-stringy-perl 2.110-2 Perl5 modules for IO from scalars ii libmailtools-perl 1.77-1 Manipulate email in perl programs ii perl5.8.8-12 Larry Wall's Practical Extraction libmime-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451619: libmime-perl: new upstream version available
On Sat, Nov 17, 2007 at 04:13:31PM +0200, Niko Tyni wrote: Package: libmime-perl * (cleanup) Remove support for recycling tempfiles ( tmp_recycling() and its usage in new_tmpfile() ) I just filed CPAN #30797 about this, pleading that the method would be restored as a no-op or similar. If that isn't succesful, I suppose that at least a NEWS.Debian entry would be in order. Update: 5.425 was just released with a no-op stub for tmp_recycling(), so this isn't an issue anymore. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451600: libpar-packer-perl: /usr/bin/par.pl vs. policy 10.4
forwarded 451600 http://rt.cpan.org/Public/Bug/Display.html?id=30815 thanks On Sat, Nov 17, 2007 at 09:55:56PM +0200, Damyan Ivanov wrote: Since /usr/bin/par is already taken by the par package, we need something else. Russ Allberry suggested par-archive, which sounds good to me. Unless there are objections, I'm going to go forward with that and rename the script. Can we have upstream's opinion on this? At least as a measure to inform them that Debian is renaming par.pl. Perhaps they can even suggest a name (and possibliy adopt it in future release)? Yeah, you're right of course. Done: CPAN #30815. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451774: FTBFS: test failure on several architectures
Package: libjavascript-perl Version: 1.04-1 Severity: serious Justification: fails to build from source The new version of libjavascript-perl is failing to build on most architectures. This is possibly an issue with 32-bit archs since amd64 and ia64 are OK. I'll look into this. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452051: Application of Niko Tyni
Package: debian-maintainers Version: 1.1 I'm attaching my DM application changeset. I'll discuss the XS-DM-Upload-Allowed field with my sponsors after I'm in the keyring. Cheers, -- Niko Tyni [EMAIL PROTECTED] Changed-By: Date: Tue, 20 Nov 2007 07:59:17 +0200 Comment: adding debian-maintainer Niko Tyni NM-Page: https://nm.debian.org/nmstatus.php?email=ntyni%40iki.fi Agreement: http://lists.debian.org/debian-newmaint/2007/11/msg00093.html Advocates: jsogo - http://lists.debian.org/debian-newmaint/2007/11/msg00097.html ivan - http://lists.debian.org/debian-newmaint/2007/11/msg00100.html rra - http://lists.debian.org/debian-newmaint/2007/11/msg00106.html Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (GNU/Linux) mQGiBEM9ZisRBAD9C4P9gqUO3WJcuWlhAEdDGZyBw4gHeBWgvd9isywHCXFBYfyf aGNrE03CUEbYWByIzA9xqrudmYdugew+Wo/wBaWBOUVGqZQ+zR9RL19C3Sh2apkm qVikEuwuhRxcM13tDehEUxWpjV+pmLBW36xE1VqAdTDR6ys06W3T4kBXkwCg0qyr TcIiwZJYL6g3G94odErJGeUEAKUdWfZh5gMvmKzJuc9uO6gCE4N3SQAsnWWZqiBk lKVADlJiak+jToZmf028XiWri24+eLDN1prn9VreZrP21w220g7tXpAUnbQSX/w9 PlYSin+iKk5JyRi/CfOQr2oFM1H6whdgR97nEIHuV07IwLQ/xNJzaKrh6Cuqe/5F OFZAA/9GsiudeLpWVZ/la7Fvlpa5gI6sB5XN9+ejWBvdRyUbTlMgUGkCmp9xWXvM botrTmgXsboH2q8OdxIPpz/aG9vQ8DRT53pQyU7NSErK027DVousYIRZsG9mxv5a fLrAgqeB/63yPB38+By/Yi+rn4jFsyv4wxP1oQKkATLnJ+WO07QYTmlrbyBUeW5p IDxudHluaUBpa2kuZmk+iEYEEBECAAYFAkPCEgcACgkQwKTxHeBrP5dnBwCgoyAs anvEe3VW+8UnzauSK6pjUrkAoJQMukIXQ843do85khZxSKkgfrsyiEYEEBECAAYF AkPEsz4ACgkQkuYKi19tgBUutwCfaSjuggIJA2uNycwSaq9WVWFTX5wAoMFLt5HG sWLPtUYzl0hbEnstyExNiEYEEBECAAYFAkRoU4IACgkQBgac8paUV/C3DACfYgJ/ gngT5yfXZx1NnWh8TOJAYsYAnjF67pkYrpGOG2Ol5uq3L3n9NauPiEYEEBECAAYF AkRrfPgACgkQWhGiK8Wh9zRoowCeNZO1l/9GTCFlaxtHkPYu7NNbyPMAnAliRwa6 +kcHDX+uWstg47eTOqDoiEYEEBECAAYFAkRrkbMACgkQVfK5DZo9IG91LgCfatyP pRspMGtKU4Hr/9PGAUjUYeoAoJR/xaindCV8p53750wzsynCIO66iEYEEBECAAYF AkRrrl0ACgkQ21Tt0dYaZV2f1ACfa0/REmFl2ZmyzYlPqWFPRV4OU54An3OThUeL /u9P23d8qtt+g/xPy+eriEYEEBECAAYFAkRsDgIACgkQ7k58drZ03jeoqwCeIq6Q X3hmF/aSsIEv7lsCDU+I75MAniFGIsdoH5UM0W6Uo9a0U4mdm35MiEYEEBECAAYF AkRsTI0ACgkQutvvqbTW3hPI5wCeOtSxwTEW3IEDECfusQCtdyKQN90Anim2v8AA LVE6gGvrxsk8w5kO5lQ4iEYEEBECAAYFAkRu1KIACgkQqs+zhiEbbu/mgACg+yAM KGytp0ltc8BteAZmYfuJdaYAn08wQGKqo8WHrXM5LYw+Wm5oKP95iEYEEBECAAYF AkRvDVYACgkQDmJrrRKYwrQi8QCeOTABo5RH0nj1sh+xdTV8QLw507wAnjcHso/D 3PMEt053KlodEwwD/zL7iEYEEBECAAYFAkR1X60ACgkQt1EUCfwV2+y7EwCfU1sI J6TbGQ+Rg4NcupIUhDd1oIIAn0m8WNF79m2kIyzREIbVYj+F6BeoiEYEEBECAAYF AkR1X7AACgkQt1EUCfwV2+w63QCghhoYkAoxeJH/qr1H/qV7IEIKGr4An0ZfDu7r M5CGnr3K05yQBidLy127iEYEEBECAAYFAkR1rSUACgkQPa9Uoh7vUnYPAgCgjNGy GIbeGry2LqJsaGLTLLlaMIQAniywHZBGrs5sqnKo0Qft6anoiFe0iEYEEBECAAYF AkSF7I4ACgkQYf6q3Be/IgHAEACfZmzbmQjE1VGBK2hCJY4EyMLhpeAAn17qszm2 eAbZkW2IEy7fiedqVegniEYEEBECAAYFAkSGAhMACgkQjnqbeSdMfAz03QCdEek2 VE/BlnnXEvHlRT2b/g1H6xcAn20tukCMfzSSFEG/Qmr9edEiKKnWiEYEEBECAAYF AkT2i9cACgkQc683VLClDPKq0QCfXiPnzpjF3aPie7WQJVfdeKW+aI8AniQU01dw lBCr+8OyFnhXsLsQKMoqiEYEEhECAAYFAkRuDZUACgkQi5YpQ/wkPzyrswCfboH/ 0rX/HNQaJ+ntc/HQe/HTnxIAn226AVoBP0PVY274rfPWp/RJ41KciEYEExECAAYF AkQL+3QACgkQLcfgfgXdWyDFPgCfYqc2c6mSwCJwLi2BAPhdMpWU5ecAnjoEb1Di LF6k54VJj+TIwGlfCqU2iEYEExECAAYFAkRw1koACgkQj4vVpW/mdhuoggCfZE38 2qNc/9bLrBTfz0YFkiRBIz4AoMUt+rIn1gGdGtrCyxK2FSLSp79aiEYEExECAAYF AkRzrjMACgkQe7tFxipD00xvZwCfcDaxUvmUz9rIRHAf+7cJQ6jzSF4AmwSwB1Cc hQF04VippmOX4aWJRssXiF4EExECAB4FAkM9ZisCGwMGCwkIBwMCAxUCAwMWAgEC HgECF4AACgkQiyizGWoHLTnPrACgk5RMFdr2ofuIL+8a21uUbZ96fZAAnjN+6Cdf LmUiJNmvzw/EZ7zrVznDiGEEExECACECGwMGCwkIBwMCAxUCAwMWAgECHgECF4AF AkPBFJMCGQEACgkQiyizGWoHLTkxOQCgqpTCb1Y/+6Pt+WPyE6TEZ/lBUw8An1CO efBeTK2/QotsURZ2cAbYiMtriH0EExECAD0FAkRsMJs2Gmh0dHA6Ly93d3cudmFu aGV1c2Rlbi5jb20vcGdwLWtleS1zaWduaW5nLXBvbGljeS5odG1sAAoJEDAZDowf KNiuxRIAn2Et8jKG5LaixCw4yWSSiflXMQ9VAKCHDLVFYkJNS2lkQUzHmv1NOsbZ A4kCHAQQAQIABgUCRGxD2wAKCRC2+un24187VRyhEADAVxwxAg3MdnRGS/WKLhWZ /r+B5+1wXm9ciqaypcv5cy3GE0Ah8gh9f3h3JMvOCghjppwbLJhHrP+QTnTf74RN g28bnErWLHKuoXnLERDWFLJXPbay15boTYMI/p7WrfvMK1pynsKJIUMh/FdeBBb7 QYZkoXG/uAduUJFLG5Wtb/Fmt5NSvjBuT8BVr3SW637UP7b9HnJOGryJYJEaGAtM Xp2OAc3TgHrVN3YLZ1xgnpAIYZaBqiNx6wkK0dcImEreB6qcOb1Mxo7t73BLbD0T u1Az/RrfvzidS9k4PwZr8XyG2yg2n20Iw/6Zl+yBTIGXv/219H/FACp1udBSROV3 w/a5U6kZb1MVT/3Y1TFxc+Z2IS32P/kfQzktX8f58Fj3M7TKCs24TvdpPP5ElpBv NjPrtCGtkQlXyL0NU8qVImsLpMNS5dH9rJZWScqVmu4pDia5qMJX0HaE8YrtvZQP QIJPicwib/+MoNQhmF/Ls53sHCVziA5CkuA6vVSfy+uWi1ACqctXwX6eAB4Z75HP xbVICDx8cA2wA2tTmZJBiNkXbwCITvmil8cIC/D00cgJZzLCpId5X6NFD6at7Ws0 9jLhsPL9jp0aBF80QUXPwWZUwqCW6JH15yOCsaZdkYg4OidNnG6LHoZ2HsSBZAR3 Ic/HLXW0ZZdf2rvkDDcgXYkCHAQQAQIABgUCRG8PkwAKCRBXkw2rC4awZ+4kD/wL gRvC5bTGdn91Cyyf9ueDED+dBjqXkci+RNBUGL8t1dQqhXXaRnIPXVf8csyTVkKW TUHF0wCQDKs26aW1NEINphcYtxcinpHWRiB8M7cu1jYSZyw/j6Wa1KuPfGTp99Uk eYM6HOOlG5VzDjPLZq1l77fiut1I4ES2bhqiAI+B3YQcumelPqrhxsW6cYmowHj/ EUdumwS5M7tv/aAgbaA6be3WXJCY5KY35fvtFsmCBq7WnmtXFjHN/TUPxD5Kq7WU keG1/Tu8x7M1sLegtwSEh/6IjNoRNu9DbXDEZOJwJXsZfgecyshi7Hm+hsGR/mc9
Bug#441059: Macro definitions differ in libmozjs0d and libmozjs-dev
On Thu, Sep 06, 2007 at 08:24:11PM +0800, Edward L. Fox wrote: Package: libmozjs-dev Version: 1.8.1.4-2 I just noticed that you (or your partners) compiled libmozjs0d with -DMOZILLA_1_8_BRANCH defined. But in the pkg-config file provided by libmozjs-dev, you didn't contain that macro. So all my program failed if I simply trusted the output of pkg-config. Hi, the -DMOZILLA_1_8_BRANCH thing hit libjavascript-perl 1.04-1 too. We got test failures on 32-bit architectures (#451774), presumably because of the ABI difference in the JSFunctionSpec struct in mozjs/jsapi.h. Would it make sense for the libmozjs-dev headers to #define MOZILLA_1_8_BRANCH by default to get the ABI corresponding to libmozjs0d? Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387311: slimserver: Internet Radio options fail
On Wed, Sep 13, 2006 at 11:18:19AM -0400, blaz wrote:
Package: slimserver
Version: 6.3.0-4
Severity: normal
All entries under the Internet Radio menu item fail with an error in the log
similar to this:
2006-09-13 10:38:57.2802 ERROR: Formats::XML: failed to parse feed because:
not well-formed (invalid token) at line 1, column 6, byte 6 at
/usr/share/perl5/SlimServer/CPAN/XML/Parser.pm line 187
Hi,
the attached patch seems to fix this for me.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--- slimserver-6.3.0/Slim/Formats/XML.pm 2007/12/02 21:05:36 1.1
+++ slimserver-6.3.0/Slim/Formats/XML.pm 2007/12/02 21:05:47
@@ -137,7 +137,7 @@
# async http request succeeded. Parse XML
# forcearray to treat items as array,
# keyattr = [] prevents id attrs from overriding
- our $xml = eval { XMLin($content, forcearray = [item, outline], keyattr = []) };
+ our $xml = eval { XMLin($$content, forcearray = [item, outline], keyattr = []) };
if ($@) {
errorMsg(Formats::XML: failed to parse feed because:[EMAIL PROTECTED]);
Bug#420867: reopening 420867, notfixed 420867 in libxml-sax-perl/0.16+dfsg-1
# Automatically generated email from bts, devscripts version 2.10.11 reopen 420867 # sorry, typo in bug number notfixed 420867 libxml-sax-perl/0.16+dfsg-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420687: closing 420687
# Automatically generated email from bts, devscripts version 2.10.11 # changelog had a typo in the bug number close 420687 libxml-sax-perl/0.16+dfsg-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429074: please update/request removal of your package
tag 429074 - lenny tag 429074 - sid close 429074 thanks On Fri, Jun 15, 2007 at 08:12:09PM +0100, Gerfried Fuchs wrote: Package: request-tracker3.4 Severity: serious Version: 3.4.5-2 Please either send the ftp team a removal request for your package if it isn't able to work with apache2, or update it to build (only) packages for apache2. Removed from unstable, see #447059. Closing this bug too and removing the tags. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430118: Please test libxml-sax-perl 0.16+dfsg-1 from experimental
Hi Daniel (and others interested in #430118), as you may have noticed, there's a new version of libxml-sax-perl in experimental with support for SAX parser priorities, so that XML::SAX::PurePerl only gets used as a last resort. I'd like one or two reports of 'it works for me' before uploading it to unstable. I'm mostly concerned about the maintainer scripts on upgrades; the preinst and postinst scripts try their best not to provoke any unnecessary ucf prompts and the like while honoring local changes to /etc/perl/XML/SAX/ParserDetails.ini. In absence of any manual changes, the upgrade should move XML::SAX::PurePerl first (ie, lowest priority) in the file. Could you please try to install 0.16+dfsg-1 and see if it does the right thing for you? Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293856: fixed in fping 2.4b2-to-ipv6-10
On Sun, Feb 06, 2005 at 05:18:35AM -0800, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #293856: fping: unnecessary delay with the -c option after the last packet, which was filed against the fping package. It has been closed by one of the developers, namely Anibal Monsalve Salazar [EMAIL PROTECTED]. Thanks a lot for the quick response! I'll send the patch upstream too, although it seems pretty quiet there. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295372: smokeping: missing packages from Suggests:
Package: smokeping Version: 1.38-2 Severity: minor For consistency, the smokeping package should suggest at least libnet-dns-perl (AnotherDNS probe) ssh (SSH probe) Additionally, there's libio-socket-ssl-perl (LDAP probe) The libnet-ldap-perl package, which is already suggested, suggests in turn libio-socket-ssl-perl, so the last one could be considered redundant. However, the LDAP probe has an explicit 'use IO::Socket::SSL' (and it does so for a reason), so it's not going to work without libio-socket-ssl-perl. libnet-telnet-perl(telnetIOSPing probe) The libnet-perl package, which smokeping depends on, recommends libnet-telnet-perl, which might be enough. It seems on explicit suggestion would be helpful, though. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298729: ITP: libconfig-grammar-perl -- A grammar-based config parser Perl module
Package: wnpp Version: N/A; reported 2005-03-09 Severity: wishlist * Package name: libconfig-grammar-perl Version : 1.01 Upstream Author : David Schweikert dws_at_ee.ethz.ch * URL : http://search.cpan.org/~dschwei/Config-Grammar-1.01/ * License : Same as Perl. Description : A grammar-based config parser Perl module Config::Grammar is a module to parse configuration files. The configuration may consist of multiple-level sections with assignments and tabular data. The parsed data will be returned as a hash containing the whole configuration. . The grammar supplied upon creation of a new object is used to parse the configuration file and return helpful error messages in case of syntax errors. Config::Grammar can also generate documentation of the configuration file format and a template configuration file. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298729: Config::Grammar ITP Smokeping
Hi José, I'm planning to package the Config::Grammar Perl module, previously known as ISG::ParseConfig, for Debian (ITP #298729; Cc'd). This is the module Smokeping uses for configuration parsing, but I hope it would be interesting on its own too. The module is now at CPAN, and the forthcoming Smokeping version 2.0 (http://www.ee.ethz.ch/~slist/smokeping-users/msg01370.html) will use the new module name. We'll still distribute the module in the Smokeping tarball as well. I just wanted to check that the ITP is OK by you - I guess you've got the first claim to the module, as you've been kind of packaging it along with Smokeping all this time. Feel free to take over the ITP if you want. (BTW, I'll need a sponsor when I get that far; offers welcome :) Cheers, -- Niko Tyni [EMAIL PROTECTED]
Bug#307955: smokeping: please consider adding an include directive to the config parser
On Fri, May 06, 2005 at 10:28:55PM +0200, Marc Haber wrote: Please consider adding a directive which includes a different file into the configuration. Hi, doesn't '@include' work? From smokeping-1.40/doc/ParseConfig.pm.txt: '@include filename' is used to include another file. Cheers, -- Niko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307955: smokeping: please consider adding an include directive to the config parser
tags #307955 +patch
thanks
On Sat, May 07, 2005 at 05:01:45PM +0200, Marc Haber wrote:
doesn't '@include' work?
Yes, that works. That should be documented in the smokeping_config man
page.
There's a pointer there:
The Parser for the Configuration file is written using
David Schweikers ParseConfig module. Read all about it in
ISG::ParseConfig.
But yes, I guess it would be best to copy the 'General Syntax' section
from ParseConfig docs to smokeping_config, as it is useful for a much
wider audience than the rest of the ParseConfig manual.
Documentation updates are still allowed for Sarge, AIUI, so here's a
dpatch.
I'll do something similar for the upstream 2.0 release candidates.
Cheers,
--
Niko
#! /bin/sh /usr/share/dpatch/dpatch-run
## 30_config_docs.dpatch by Niko Tyni [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Documentation updates
@DPATCH@
--- smokeping-1.38/lib/Smokeping.pm 2005/05/07 16:13:51 1.1
+++ smokeping-1.38/lib/Smokeping.pm 2005/05/07 16:20:43
@@ -2107,6 +2107,7 @@
sub makepod ($){
my $parser = shift;
my $e='=';
+my $a='@';
print POD;
${e}head1 NAME
@@ -2129,7 +2130,29 @@
${e}head1 REFERENCE
-The text below describes the syntax of the SmokePing configuration file.
+${e}head2 GENERAL SYNTAX
+
+The text below describes the general syntax of the SmokePing configuration
file.
+It was copied from the ISG::ParseConfig documentation.
+
+'#' denotes a comment up to the end-of-line, empty lines are allowed and space
+at the beginning and end of lines is trimmed.
+
+'\\' at the end of the line marks a continued line on the next line. A single
+space will be inserted between the concatenated lines.
+
+'${a}include filename' is used to include another file.
+
+'${a}define a some value' will replace all occurences of 'a' in the following
text
+with 'some value'.
+
+Fields in tables that contain white space can be enclosed in either C' or
C.
+Whitespace can also be escaped with C\\. Quotes inside quotes are allowed
but must
+be escaped with a backslash as well.
+
+${e}head2 SPECIFIC SYNTAX
+
+The text below describes the specific syntax of the SmokePing configuration
file.
POD
Bug#283652: curl does not work
tags 283652 patch thanks On Wed, Dec 29, 2004 at 03:53:42PM +0100, Marc Haber wrote: On Sat, Dec 18, 2004 at 01:41:26PM +0200, Niko Tyni wrote: you need to specify the target host explicitly, it is not derived from the url. Adding the line host = www.zugschlus.de after the title line should make it work. It indeed does. The docs need to be improved on that part. Examples would be a good idea. Downgrading this bug to minor. If we still get documentation fixes through for Sarge, here's a suggested tiny dpatch for this as well. Cheers, -- Niko #! /bin/sh /usr/share/dpatch/dpatch-run ## 40_curl_docs.dpatch by Niko Tyni [EMAIL PROTECTED] ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Curl documentation updates @DPATCH@ diff -urNad smokeping-1.38/lib/probes/Curl.pm /tmp/dpep.gGpcNv/smokeping-1.38/lib/probes/Curl.pm --- smokeping-1.38/lib/probes/Curl.pm 2005-05-07 20:44:15.633729410 +0300 +++ /tmp/dpep.gGpcNv/smokeping-1.38/lib/probes/Curl.pm 2005-05-07 21:12:22.106228691 +0300 @@ -37,6 +37,8 @@ ++ PROBE_CONF agent = User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 url = https://some.host/some/where + # note that 'url' overrides the 'host' variable, although 'host' + # must still be present and is shown on graphs etc. See below. =head1 DESCRIPTION @@ -55,7 +57,10 @@ =item url -The URL to fetch. Can be any one that curl supports. +The URL to fetch. Can be any one that curl supports. Note that if this +variable is present, it overrides the 'host' variable for the actual +target pinged. Still, 'host' must be present in those targets that should +be pinged, and its contents will show up on the graphs. =back
Bug#296563: libauthen-radius-perl: new upstream version available
Package: libauthen-radius-perl Severity: wishlist Hi, the latest CPAN version of Authen::Radius (RadiusPerl) is 0.12, fixing #234505 and incorporating a few new features. Please consider updating the package. Changes since 0.09 (http://search.cpan.org/src/MANOWAR/RadiusPerl-0.12/Changes): 0.12 Fri Dec 17 19:00:00 2004 - Include the default set of radius dictionaries with the module, so it can be used on the generic system without having to install extra components from the RADIUS server. 0.11 Mon Mar 22 22:51:00 2004 - Fixed incorrect constant definition for ACCESS_REJECT (thanks to Alexey Antipov for the error report) 0.10 Fri Mar 05 21:00:00 2004 - Authenticator for the accounting requests (Thanks to Brian Andrus for the patch provided) - Support for password, longer than 16 characters (Thanks to Will LaSala and Robert Tuttle for the problem report and patches) - Include NAS-IP-Address into the check_pwd to avoid error non-RFC packet error from some of the RADIUS servers (Thanks to Jacinta Alice Richardson, Bill Schoolfield and Ed Kubaitis for the problem report and patches) - Modify the example in perldoc to avoid confusion with the User-Pasword vs Password attribute. (Thanks to Didier Conchaudron for the problem report) - Limit the maximum value length for string and avpair attributes Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#282292: Bug#282293: libgd-perl FTBFS test failures
Hi, I looked into the libgd-perl FTBFS test failures. They are due to slight differences in PNG output. There is no visible difference between the generated and expected data, and the diff between them is very small (see the end). I have not investigated what the changed bytes mean in the PNG format. Iterating with packages from snapshot.debian.net I found that the change that broke the tests was introduced in version 1.2.7-1 of the libpng3 source package. The tests are successful with version 1.2.5.0-9 of the libpng12-0 binary package installed. The upstream changelog between 1.2.5 and 1.2.7 is rather long. Hope this helps. If you decide to keep libgd-perl out of sarge, these packages still seem to suggest or recommend it: ipac-ng remstats diablo libtemplate-perl Differences in the test output, generated by first running 'od -x' on generated and expected data and then diffing them. (The output of test 9 is the same as test 10.) --- test.out.4.png.hex 2005-02-23 13:41:09.0 +0200 +++ test.out.4.png.hex.new 2005-02-23 13:41:09.0 +0200 @@ -2,7 +2,7 @@ 020 6400 3200 0302 d700 965b 040 002d 500c 544c 0045 060 01ff 331d 004a 49bc 4144 -100 7854 ad9c c194 830d 0c30 1345 ba09 cc01 +100 3854 ad8d c194 830d 0c30 1345 ba09 cc01 120 1193 207a 303d d302 40f4 8036 7f03 8aca 140 8544 f126 10b7 3fea c9e6 b1f9 db63 4b98 160 e46a cee3 5547 d6e7 884f cff2 7882 157c @@ -13,6 +13,6 @@ 300 b210 22dc a272 aa7b f5ff f9e1 a9dc af0e 320 f2b5 fc3f 794f f01f e1de a6fd 28f4 6bef 340 0b3e fcca 99f0 e653 cf94 b2b6 940f a21d -360 1dec abbe b2a2 f6fd 1101 4db6 5428 f2cc -400 005e 4900 4e45 ae44 6042 0082 +360 1dec abbe b2a2 f6fd 1101 4db6 a128 a510 +400 00c2 4900 4e45 ae44 6042 0082 415 --- test.out.10.png.hex 2005-02-23 13:41:09.0 +0200 +++ test.out.10.png.hex.new 2005-02-23 13:41:09.0 +0200 @@ -49,7 +49,7 @@ 0001400 8ce4 a224 4824 52d0 da68 d4d4 1c92 ab3c 0001420 5437 cce2 9e34 f42c 3c92 9254 4864 3eac 0001440 bb47 3233 28bb f017 03ee df30 008a 0700 -0001460 49af 4144 7854 6d9c 0d54 5358 19d7 1d3e +0001460 49af 4144 4854 6d89 0d54 5358 19d7 1d3e 0001500 bfc4 8b3a 9355 8103 7e12 b824 04d3 0d32 0001520 b368 04ec 0202 70c5 9567 e20d 8c96 80fc 0001540 1245 f043 2262 0897 6e9b 684f 74cb ad5a @@ -172,6 +172,6 @@ 0005260 1e61 f9a5 d2fc c251 212e 3921 1d41 b3c4 0005300 33d2 0f82 082c 2448 278a 0e46 84bb cfcf 0005320 9fa0 b23c 4269 7252 0248 10b6 14d6 01ff -0005340 1633 2cb0 40af 7cee 4549 444e +0005340 1633 2cb0 6a8a bf9c 4549 444e 0005360 42ae 8260 0005364 Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280920: reissuing control commands
reassign 280920 libgd1-xpm severity 280920 normal retitle 280920 libgd1-xpm: missing Conflicts: on libgd_1_ tags 280920 - woody thanks Hi, this bug is still RC and tagged woody, although the discussion inside indicates it's a testing/unstable issue and only occurs with partial upgrades from woody, making it (AFAIK) non-RC. I'm reissuing the control commands from Christoph Berg, as they apparently didn't reach [EMAIL PROTECTED] earlier. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278625: Bug #278625: CAN-2004-0990: integer and buffer overflows
Hi, this security bug (CAN-2004-0990) against libgd2 in woody seems to be fixed: libgd2 (2.0.1-10woody2) stable-security; urgency=high * Non-maintainer upload by the Security Team * Added overflow and failed malloc protections to prevend buffer overflows that could lead to arbitrary code execution [gd.c, wbmp.c, gd_gd.c, gd_io_dp.c, gdxpm.c, CAN-2004-0941, CAN-2004-0990] * Added missing free() [gd_png.c] * Added nother integer overflow precaution by Stew Benedict [EMAIL PROTECTED] [gd_png.c] -- Martin Schulze [EMAIL PROTECTED] Tue, 16 Nov 2004 11:39:46 +0100 AFAICT, the bug report should be closed. I'll leave that for somebody else to verify, though. Apologies if I'm missing something. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296133: openvpn: UTF-8 spoils searches in man pages
retitle 296133 openvpn: should escape minus characters in the manpage thanks I recently switched to UTF-8 character handling. Now, when searching for an extended cmd line option in openvpn(8), like --dev-type, using e.g. / in less as a man pager, I only find the phrase in the SYNOPSIS section. Later the hyphen between the words is no longer matched by the pattern. Hi, this is because the minus characters are escaped properly as '\-' in the SYNOPSIS section, but not in the rest of the page. Retitling accordingly. See the last message of bug #159872 (http://bugs.debian.org/159872) for a full explanation. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#262575: Unix::Syslog appends localized timestap prefix to entries
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Amavisd-new uses Unix::Syslog. I have tracked down the problem to that package: syslog($syslog_priority, %s, debug); inside amavisd-new causes the localized crap to show up on the logs. WTF Unix::Syslog is doing, I have no idea. Hi, Unix::Syslog isn't doing anything, it's just a wrapper for syslog(3). The bug was in glibc: glibc (2.3.2.ds1-14) unstable; urgency=low [...] - debian/patches/syslog-locale.dpatch: Include patch from Jakub Jelinek to make sure syslogging happens in the C locale. Thanks to pere for catching this. (Closes: #161340, #158651) The fixed glibc version reached unstable on the same day the last message in this bug was recorded. Jonas, I understand it's considered impolite to close other people's bugs, so I'll leave that to you :) Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268100: convert::uulib: fails on file containing :0: at beginning of line
Jonas Smedegaard [EMAIL PROTECTED] wrote:
Could someone please check if the problem persist even with the newer
release?
And if the problem does persist, could someone post a test case that I
can provide upstream?
Hi,
the problem is present in 1.0.3-2 too.
I'm attaching a test script that demonstrates the problem AIUI.
When run on a plain text file that contains a ':0:' in the
beginning of the line, it outputs an error:
% cat a
:0:
kalimantan% ./test-uu.pl a
a: 1 parts
Decoding part 0
decode: Invalid argument ('File I/O Error') at ./test-uu.pl line 16.
If the file does not match this, no encoded parts are found:
kalimantan% cat b
:0:
kalimantan% ./test-uu.pl b
b: 0 parts
Upstream 1.0.4 is an improvement: if survives the above, but fails if
there's the string \n\n:0: in the middle of the file, which is still
quite possible in the original scenario (mail including a procmail
recipe.)
I'm not very familiar with uulib, but I guess this bug could be
considered a feature. It looks to me like the decode() function returns
an error message where appropriate, so the question is how well the
scan in LoadFile() should recognize encoded contents. This is probably
a matter of taste. But that's for upstream to decide, of course.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
#!/usr/bin/perl -w
use strict;
use Convert::UUlib qw(:all);
for (@ARGV) {
my ($retval, $count) = LoadFile $_ ;
print $_: $count parts\n;
}
for (my $i = 0; my $uu = GetFileListItem $i; $i++) {
print Decoding part $i\n;
if ($uu-state FILE_OK) {
my $sts = $uu-decode;
$sts RET_OK or die(decode: $! (' . strerror($sts). '));
}
}
Bug#297885: libxml-libxml-perl: XML::LibXML::SAX doesn't have a default error method
Package: libxml-libxml-perl
Version: 1.58-0.3
Severity: normal
Hi,
the XML::LibXML::SAX parser does not raise an exception by default when
parsing invalid XML syntax. The other available SAX parsers on my
system, XML::LibXML::SAX::Parser (from the same libxml-libxml-perl
package) and XML::SAX::PurePerl (from libxml-sax-perl) do raise
exceptions by default, so this is inconsistent behaviour.
I'm attaching a test script that shows the problem. It defines a simple
XML handling class, MyHandler, which is derived from XML::SAX::Base,
and uses it to parse an invalid XML document with different SAX
parsers. The result output is:
%./saxtest.pl
Trying parser XML::LibXML::SAX::Parser...OK: got exception
Trying parser XML::SAX::PurePerl...OK: got exception
Trying parser XML::LibXML::SAX...ERROR: no exception
When called with the '-2' parameter, it uses another handling class,
MyHandler2, that differs from MyHandler only in that it has an explicit
'error' method. The resulting output is now;
% ./saxtest.pl -2
Trying parser XML::LibXML::SAX::Parser...OK: got exception
Trying parser XML::SAX::PurePerl...OK: got exception
Trying parser XML::LibXML::SAX...OK: got exception
(There's also a -v parameter that shows the error string, in case you
want to verify the cause of the exception.)
Note that XML::LibXML::SAX is the default SAX parser when
libxml-libxml-perl is installed, so it would seem even more important
for it to do the Right Thing.
I ran into the problem while inspecting test failures in libxtm-perl,
bug #249234. I'll send details there shortly.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
#!/usr/bin/perl -w
use strict;
use XML::SAX;
use XML::SAX::ParserFactory;
use XML::LibXML::SAX;
use Getopt::Std;
my %opts;
getopts('2v', \%opts);
my @parsers = map { $_-{Name} } @{XML::SAX-parsers()};
my $h;
if ($opts{2}) {
$h = new MyHandler2;
} else {
$h = new MyHandler;
}
for (@parsers) {
print Trying parser $_...;
local $XML::SAX::ParserPackage = $_;
my $p = XML::SAX::ParserFactory-parser(Handler = $h);
eval { $p-parse_string(q|?xml version=1.0?a/a/|) };
if ($@) {
print OK: got exception\n;
print $@ if $opts{v};
} else {
print ERROR: no exception\n;
}
print \n;
}
package MyHandler;
use base qw(XML::SAX::Base);
1;
package MyHandler2;
use base qw(XML::SAX::Base);
sub error {
my $self = shift;
die(shift);
}
1;
Bug#249234: libxtm-perl: conflicts with current perl, not installable
at least version
1.90 of Parse::RecDescent. I hope I found all the occurrences; at least
the tests are now successful with regenerated CParser.pm files as well.
I have also fixed the Depends and Conflicts lines in debian/control,
so the package doesn't conflict with Perl 5.8 anymore. I have run the
tests succesfully with both Perl 5.6 and Perl 5.8.
I hope this helps libxtm-perl get back into sarge, but don't personally
mind too much if it doesn't. I don't use the package myself, and
originally looked into the problems as an opportunity to learn how Perl
5.8 handles Unicode. Then I just wanted to finish what I had started,
as it seemed like a nice challenge :)
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--- debian/control 2005/03/03 10:29:42 1.1
+++ debian/control 2005/03/03 10:37:46
@@ -2,14 +2,12 @@
Section: perl
Priority: extra
Maintainer: Alexander Zangerl [EMAIL PROTECTED]
-Build-Depends-Indep: debhelper ( 3.0.0), perl, libtest-simple-perl (=
0.40), libxml-sax-perl (= 0.03), libxml-libxml-perl (= 1.40),
libio-string-perl (= 1.01), libwww-perl, libparse-recdescent-perl (= 1.80),
liburi-perl (= 1.18), libxml-twig-perl (= 3.01), libxml-writer-perl (= 0.4),
libtext-iconv-perl (= 1.2), libfile-slurp-perl
-Build-Conflicts-Indep: perl (= 5.8)
+Build-Depends-Indep: debhelper ( 3.0.0), perl, perl-modules (= 5.8.0) |
libtest-simple-perl (= 0.40), libxml-sax-perl (= 0.03), libxml-libxml-perl
(= 1.40), libio-string-perl (= 1.01), libwww-perl, libparse-recdescent-perl
(= 1.90), liburi-perl (= 1.18), libxml-twig-perl (= 3.01),
libxml-writer-perl (= 0.4), libtext-iconv-perl (= 1.2), libfile-slurp-perl
Standards-Version: 3.6.1.0
Package: libxtm-perl
Architecture: all
-Depends: ${perl:Depends}, libxml-sax-perl (= 0.03), libxml-libxml-perl (=
1.40), libio-string-perl (= 1.01), libwww-perl, libparse-recdescent-perl (=
1.80), liburi-perl (= 1.18), libxml-twig-perl (= 3.01), libxml-writer-perl
(= 0.4), libtext-iconv-perl (= 1.2), libfile-slurp-perl
-Conflicts: perl (= 5.8)
+Depends: ${perl:Depends}, libxml-sax-perl (= 0.03), libxml-libxml-perl (=
1.40), libio-string-perl (= 1.01), libwww-perl, libparse-recdescent-perl (=
1.90), liburi-perl (= 1.18), libxml-twig-perl (= 3.01), libxml-writer-perl
(= 0.4), libtext-iconv-perl (= 1.2), libfile-slurp-perl
Description: Perl module for reading/writing Topic Maps
This module consists of several classes for reading, querying and building
Topic Maps in both standard XTM (XML Topic Map) format as well as
--- lib/XTM/AsTMa/Parser.pm 2005/03/03 10:29:16 1.1
+++ lib/XTM/AsTMa/Parser.pm 2005/03/03 10:29:33
@@ -11,7 +11,7 @@
$VERSION = '0.08';
use Data::Dumper;
-use Parse::RecDescent;
+use Parse::RecDescent 1.90;
use URI;
use URI::Escape;
@@ -40,14 +40,14 @@
# deal with the topic first
my $t = new XTM::topic (id = $item{topic_id});
-foreach (@{$item{types}-[0]}) {
+foreach (@{$item{'types(?)'}-[0]}) {
$t-add__s (new XTM::instanceOf ( reference = new
XTM::topicRef (href = #$_)));
}
$t-add__s (new XTM::instanceOf ( reference = new
XTM::topicRef (href = $XTM::PSI::xtm{topic})))
unless $t-instanceOfs @{$t-instanceOfs};
my $s = new XTM::subjectIdentity (); # maybe we need it
-foreach (@{$item{topic_characteristic}}) {
+foreach (@{$item{'topic_characteristic(s?)'}}) {
if (ref($_) eq 'XTM::subjectIndicatorRef') {
$s-add_reference_s ($_);
} elsif (ref($_) eq 'XTM::topicRef') {
@@ -56,8 +56,8 @@
$t-add__s ($_);
}
}
-if (ref($item{reification}) eq 'ARRAY'
@{$item{reification}}) {
- $s-add_ ( $item{reification}-[0] );
+if (ref($item{'reification(?)'}) eq 'ARRAY'
@{$item{'reification(?)'}}) {
+ $s-add_ ( $item{'reification(?)'}-[0] );
}
$t-add_subjectIdentity ($s) if $s-references ||
$s-resourceRef; # only add it if we found at least one reference
@@ -101,7 +101,7 @@
return $t;
}
-foreach my $uri (@{$item{isreification}}) {
+foreach my $uri (@{$item{'isreification(s?)'}}) {
push @components, _make_reifying_topic ($uri,
$t-id);
}
@@ -126,7 +126,7 @@
my $a = new XTM::association ();
my $s = new XTM::scope();
$a-add_scope ($s);
- foreach (@{$item{scopes}-[0]}) {
+ foreach (@{$item
Bug#356419: Upstream fixed the bug several versions ago
reopen 356419 found 356419 libpdf-api2-perl/0.51-1 found 356419 libpdf-api2-perl/0.61-1 thanks On Sat, Aug 11, 2007 at 06:21:20PM -0500, Gunnar Wolf wrote: The upstream author flagged the bug in the CPAN tracker as closed (fixed in CVS) back in May 8 2007. Right, but the version in Debian, 0.61, was released on May 7th, and doesn't have the fix yet. I just checked, and upstream 0.62 (released 5 days ago) has the fix, so reopening for now. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437474: libnet-irc-perl patches
Package: libnet-irc-perl
Version: 0.75-6
Severity: normal
Hi David,
thanks for your patches. I'm forwarding them to the Debian bug tracking
system, so we can better keep track of them. Please keep the bug
address ([EMAIL PROTECTED], I don't know the number yet) Cc'd.
When is the first patch ('fix_ev_has_null_type.patch') needed? Is it
when the server sends an unknown numeric response, or is some part of
the code calling handler() with an empty string?
The second patch ('fix_next_outside_loop_with_return.patch')
looks good to me.
I'm not sure of the third one ('fix_send_on_unexpected_close.patch').
If the server has closed the connection, shouldn't we trigger a
'sockerror' event before failing?
- Forwarded message from David Sobon [EMAIL PROTECTED] -
From: David Sobon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: libnet-irc-perl patches
Hello,
I think you may be the most appropriate person for receiving
submitted patches related to libnet-irc-perl. I tried to send patches
many years ago to the former maintainer, or even the original Net::IRC
contact address, but nothing came out of it.
Unfortunately I lost one patch that related to DCC CHAT line
handling... so I cannot provide a fix I had created a few years ago.
(I can probably try one of my old scripts that exposed the problem)
The patches only solve warnings basically. If the patches do not
appear to solve a convincing issue, I can, with effort, to reproduce
the warning messages.
Patches are as attached with self-descriptive filename.
Thanks.
-David.
--- Connection.pm.orig 2004-12-17 08:18:48.0 +0800
+++ Connection.pm 2007-08-12 18:40:22.0 +0800
@@ -473,6 +473,10 @@
} else {
croak Not enough arguments to handler();
}
+
+ unless ($ev) {
+croak event has NULL type!;
+ }
print STDERR Trying to handle event '$ev'.\n if $self-{_debug};
--- DCC.pm.orig 2006-10-04 04:49:54.0 +0800
+++ DCC.pm 2007-08-12 18:32:46.0 +0800
@@ -253,7 +253,8 @@
my $line = $self-_getline($_[0], 'BLOCKS');
-next unless defined $line;
+return unless defined $line;
+
unless(print {$self-{_fh}} $line) {
carp (Error writing to . $self-{_filename} . : $!);
close $self-{_fh};
--- Connection.pm.orig 2004-12-17 08:18:48.0 +0800
+++ Connection.pm 2007-08-12 18:40:22.0 +0800
@@ -1374,7 +1378,11 @@
if ($self-{_debug}) {
print $line\n;
}
-
+
+ # sometimes IRC servers unexpectedly close on connect, so we try to send
+ # to a closed socket. dodgy IRC server software?
+ return unless ($self-{_socket});
+
# RFC compliance can be kinda nice...
my $rv = $self-ssl ?
$self-socket-print($line\015\012) :
- End forwarded message -
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443236: missing dependency on libfcgi-perl
Package: perl Version: 5.8.8-9 Severity: important sid% perl -MCGI::Fast Can't locate FCGI.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/share/perl/5.8/CGI/Fast.pm line 22. The libcgi-fast-perl package used to depend on libfcgi-perl, but the dependency was lost with the switch to perl-modules. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-4-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages perl depends on: ii libc6 2.6.1-5GNU C Library: Shared libraries ii libdb4.4 4.4.20-10 Berkeley v4.4 Database Libraries [ ii libgdbm3 1.8.3-3GNU dbm database routines (runtime ii perl-base 5.8.8-9The Pathologically Eclectic Rubbis ii perl-modules 5.8.8-9Core Perl modules Versions of packages perl recommends: ii perl-doc 5.8.8-9Perl documentation -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442398: RT has non-functional link in user front page
On Wed, Sep 19, 2007 at 02:31:17PM -0700, Ivan Kohler wrote: I'm not sure a fix for this would be accepted in etch proper (though it can't hurt to try), and it is off-topic for volatile. However, we should upload a package to unstable that fixes the problem for existing databaes on upgrade, and possibly do an etch backport for backports.org. Some observations: - the initialdata file was fixed upstream in 3.6.2, so the root problem is fixed in unstable http://rt3.fsck.com/Ticket/Display.html?id=7854 - the bug shows up when $RT::WebPath is changed after the database has been initialized. At initialization time, the variable is interpolated correctly. - the suggested 'rt-setup-database --action insert' is not an optimal fix for existing databases: it will duplicate the database content - the database contents are serialized by Storable, so the upgrade script must be done by using the RT API and not by modifying the database directly. This would probably have been a good idea in any case. I'll look into the upgrade script. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
