Bug#341564: package does not clean
Hi! Package: pychecker Version: 0.8.16-1 some cruft is left: I'm not sure I understand what the problem is. Are these tests failing for you, or something? They seem to all pass for me in a pbuilder environment. Sorry to be so dense, but I want to make sure I'm trying to fix the right thing. :) KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#341564: package does not clean
On Thu, Dec 01, 2005 at 05:58:43PM +0100, Matthias Klose wrote: Kenneth Pronovici writes: Hi! Package: pychecker Version: 0.8.16-1 some cruft is left: I'm not sure I understand what the problem is. Are these tests failing for you, or something? They seem to all pass for me in a pbuilder environment. these are the results, when run with python2.4. Er, mind if I ask why have you modified the package to use python2.4 instead of python2.3? Sorry to be so dense, but I want to make sure I'm trying to fix the right thing. :) well, even if tests fail, the test results shouldn't change the source. Ok, first, just so we're on the same page: these .results files only show up if there is a test failure. They are generally used either for debugging or (more often) for creating Debian-specific expected results (test_expected/*-debian). It looks like the problem is that the clean rule doesn't remove these leftover files before the next build, and they're somehow ending up in your source package. Could that cause what you're seeing? It doesn't quite match up with your bug report, though. I'd expect to see some new .results files, not some changed results files -- since the Debian source package for 0.8.16-1 doesn't contain any results files at all. Any idea what explains this? It seems like the best solution is to just remove the .results files in the clean rule. That way, even if there are leftover .results files from failures that eventually get fixed, there's no chance that they accidentally get placed into the source package. Does this sound like it solves your problem? As an aside, if you're going to build and distribute a pychecker package based on python2.4 (is this maybe for Ubuntu?), I'd like to see you create new Debian-specific expected results files for these tests. That way, all of the tests continue to pass and the regression test step can be left unchanged relative to what's in my original debian/rules file. At least this way, it will continue to be obvious if the behavior of the package is changing from release to release (i.e. if new tests fail). Would you mind doing this? Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#341564: package does not clean
It seems like the best solution is to just remove the .results files in the clean rule. That way, even if there are leftover .results files from failures that eventually get fixed, there's no chance that they accidentally get placed into the source package. Does this sound like it solves your problem? Well, I guess you're not around right now. I'm going to upload with a fix to clean the results files, because I have a few other minor changes to upload as well. If this doesn't solve your problem, please feel free to re-open the bug report and we'll come up with a better solution. Thanks. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#342103: tv_grab_fr needs update (due to changes on telepoche.fr)
Package: xmltv-util Version: 0.5.39-2 As telepoche.fr has changed its data format, tv_grab_fr doesn't work anymore and causes serious problems on my installation of freevo, for example. Hi, I generally don't backport changes (even ones like this) from CVS into Debian releases until it's been a while since the bug was fixed and upstream hasn't yet made a release. This is because there are always a lot of ongoing changes in CVS, and many people ask for the changes to be propogated to Debian, making it difficult to keep up with requests. Besides that, upstream changes have been tested against the CVS version of other XMLTV code, not the version in the Debian package, often making QA somewhat problematic. I understand that Chris Butler [EMAIL PROTECTED] is planning on taking over the XMLTV packages soon (they've been up for adoption). He may feel differently about this policy and may want to make this change along with his first upload. I've CC'd him so he's aware of your request. I'm sorry to give you this answer -- I know it's not what you were hoping to hear. However, I hope you understand my motivation for this policy. Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#308372: python2.3-epydoc: Ignores encoding of the Python files
Package: python2.3-epydoc Version: 2.1-8 Severity: normal epydoc --html ignores the encoding of the Python source file (PEP 263) and always put a: ?xml version=1.0 encoding=iso-8859-1? which probably comes from my locale (it should come from the encoding specified as '# -*- coding: utf-8 -*-'). Ok, I'll pass this on upstream. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpi7xmrlUACp.pgp Description: PGP signature
Bug#337707: pychecker: Lines too long in README.Debian
On Sat, Nov 05, 2005 at 04:22:29PM -0500, Roberto C. Sanchez wrote: Package: pychecker Version: 0.8.14-6 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The README.Debian file included with pychecker has lines that are longer than 80 characters. This causes a rather annoying appearance on a standard 80-character wide terminal window. Please fix the line lengths. - -Roberto Hmm. Must have had vim misconfigured when I edited that file. Anyway, yeah, I'll fix it. Obviously, I won't put out a new release just for this, though. Thanks for bringing it to my attention. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#344472: cedar-backup2: Fails to runs tests
Package: cedar-backup2 Version: 2.7.1-1 Severity: serious Justification: no longer builds from source The following errors show when trying to build the package (on Sarge): Well, that's pretty fscking odd. The package builds in a pbuilder environment. Besides that, tests like these (which rely on a device or something) aren't supposed to be run when building the package, because it uses the reduced feature set test suite rather than the full test suite. Now that I think about it, I may have accidentally placed those tests into the reduced feature set suite when I added them for 2.7.0. I'll take a peek at it tonite and see if I can figure out what's going on. Thanks for the report. KEN signature.asc Description: Digital signature
Bug#344474: cedar-backup2: Package documentation in distinct packages
Package: cedar-backup2 Version: 2.7.1-1 Severity: wishlist I noticed the documentation is available both as PDF (compressed as .gz) and html. Please do not package both in the same packages. The various manual formats serve different purposes. While the HTML manual is good for online browsing, the PDF manual is best for printing. I think it does serve a worthwhile purpose to include both. As an alternative, I might consider splitting the documentation into a separate package. However, it doesn't seem like debian-devel has come to a consensus on how large documentation must be (either in absolute terms or relative to the remainder of the package) before it should be split off. Do you have any thoughts on this? KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#344472: cedar-backup2: Fails to runs tests
On Thu, Dec 22, 2005 at 07:25:11PM -0600, Kenneth Pronovici wrote: Now that I think about it, I may have accidentally placed those tests into the reduced feature set suite when I added them for 2.7.0. I'll take a peek at it tonite and see if I can figure out what's going on. Yeah, this was pretty much the problem. Originally (like, a year ago), the writertests were completely independent of any device. I slowly started adding some tests that actually talked to the device. In retrospect, these tests are kind of bogus, for a couple of reasons. One reason is that just because I have a cd writer at a particular SCSI address doesn't mean that a device on someone else's system with that address is a writer. Another reason is that I no longer even have a writer device with the indicated SCSI address (0,0,0), so I wasn't even running the tests in the first place. Aaargh! Anyway, I've just removed the offending tests, and I'll do a new upstream release and push the changes through to Debian. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#344474: cedar-backup2: Package documentation in distinct packages
On Fri, Dec 23, 2005 at 12:00:12PM +0100, Jérôme Warnier wrote: Le jeudi 22 décembre 2005 à 19:34 -0600, Kenneth Pronovici a écrit : Package: cedar-backup2 Version: 2.7.1-1 Severity: wishlist I noticed the documentation is available both as PDF (compressed as .gz) and html. Please do not package both in the same packages. The various manual formats serve different purposes. While the HTML manual is good for online browsing, the PDF manual is best for printing. I think it does serve a worthwhile purpose to include both. As an alternative, I might consider splitting the documentation into a separate package. However, it doesn't seem like debian-devel has come to a consensus on how large documentation must be (either in absolute terms or relative to the remainder of the package) before it should be split off. Do you have any thoughts on this? I was thinking about: autogenerating the documentation from sources (as it seems to be DocBook, it should be doable). And then, ship the documentation as separate package, mostly because it is bigger (wrt to disk space) than the program itself. Er, the only question we're entertaining here is whether the single Debian source package needs to be split into two binary packages (one for the program, one for documentation). There isn't a need to build the documentation as part of the Debian build process (see below). I was hoping to hear your thoughts on why it is worth splitting the single source package into two binary packages. I would potentially be willing to do it here, but I'm not yet convinced it's worth it. But, it seems that to include the pictures in the PDF version (I read that in the sources, in doc/docbook.txt), you need the Jimi Java library, which is non-free, see: http://lists.debian.org/debian-legal/2003/11/msg00106.html And btw, I'm sure that shipping the PDF with the pictures is not DFSG-compliant. I did not look at it, but is it? First, let's be clear about where the documentation is built. The documentation is built upstream and is included in the original source tarball. The Debian package just includes the upstream documentation in the correct directory (/usr/share/doc), but does *not* rebuild it, because there's no good reason to do so. As such, the Debian package does not have any dependency on Jimi. You can see this clearly by checking the build-dependecies in debian/control. As far as the DFSG goes -- the DFSG only applies to the licensing of the software in question. In this case, the licenses for everything in Cedar Backup (including the graphics) is free per the DFSG. I have been extremely careful about this, the point of documenting every piece of code and every file not created directly be me, and ensuring that the license is appropriate. You may be conflating the issue of whether you can rebuild the documentation using software in Debian with the issue of whether the software itself is freely licensed. These really are two separate issues. Debian policy (section 2.2.1) does state that the software to be placed in main must not require a package outside of main for compilation or execution. In this case, because the Debian package chooses to not rebuild the documentation, Cedar Backup has no such dependencies and is appropriate for main. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#344508: cedar-backup2: Please adapt the sample configuration to Debian
On Fri, Dec 23, 2005 at 11:43:04AM +0100, Jerome Warnier wrote: Package: cedar-backup2 Version: 2.7.2-1 Severity: wishlist Could you please already adapt the sample configuration file to Debian. I think particularly to pathes to utilities like cdrecord, mkisofs, ... Many Debian packages just include upstream sample configuration files verbatim, and do not adapt these files to Debian. That is because, like in Cedar Backup, these samples files are not supposed to be typical or representative, just informative. In other words, they are a starting point (perhaps just to provide an example of appropriate syntax), and are not intended to represent real working configuration. In this case, the Cedar Backup sample file includes examples of nearly every type of configuration section (for reference) but in a form and in a combination that probably no one will ever use. I resist providing any real sample configuration because everyone's system is different. The documentation is really the source you should be going to as you try to build your configuration file. Or, write the upstream user mailing list if you have configuration questions (and yes, you'll probably talk with me there as well, but that's not the point). Incidentally, in this particular case, I wouldn't want to adapt the override paths to a Debian system, because that would mean removing them entirely from the sample. They're not required on a standard Debian system. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#331108: XMLTV?
Hi, Were you planning on taking over the XMLTV packages, or not? I haven't heard anything from you since your (possibly premature?) announcement to the xmltv-devel mailing list on December 1 -- not even a reply to my note asking for clarification of a few things like backports: http://article.gmane.org/gmane.comp.tv.xmltv.devel/5719 Besides that, you don't seem to have responded to the latest XMLTV bug report that I CC'd to you around that same time: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342103 It doesn't bother me if you have changed your mind about taking over the package, but it's not fair to leave me (and bug submitters) in limbo about who is really maintaining the package -- especially since it was originally an RFA: bug rather than an O: bug. Please let me know what you are planning on doing. Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#308372: More notes
This is an upstream bug, but upstream seems to have disappeared for the time being (I've heard from a collegue of his that he's both getting married this year and working on a dissertation). I will do some debugging on my own and see if I can fix the problem in a Debian-specific release. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpv1GC56r7qS.pgp Description: PGP signature
Bug#308372: Might be related to python-list post.
This bug might be related to the following python-list post: From: Michele Petrazzo michele.petrazzo at TOGLIunipex.it Subject: epydoc, variables and encoding Newsgroups: gmane.comp.python.general Date: 2005-09-21 10:48:06 GMT I found a problem on epydoc. If I specify an encoding, epydoc not find my global variables, and if I remove it, it work well. code.py: #!/usr/bin/env python # -*- coding: utf-8 -*- MY_VAR = None class foo(object): def __init__(self, foo): Some text at param foo: Pass me what you want at type foo: A type at return: The object return foo This not work (MY_VAR is silently skipped), but if I remove: # -*- coding: utf-8 -*- it see MY_VAR and put it to my html file. Is it normal? KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgp2tnOhG4QM9.pgp Description: PGP signature
Bug#308372: Might be related to python-list post.
This bug might be related to the following python-list post: I found a problem on epydoc. If I specify an encoding, epydoc not find my global variables, and if I remove it, it work well. Hmm, nope. I found a fix for the MY_VAR being skipped (and submitted a patch to SourceForge), but this problem not related to the issue of encoding in the output HTML. The iso-8859-1 value seems to be hardcoded by epydoc, and previous epydoc documentation indicates that only ASCII is supported. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpetk2CIdBIh.pgp Description: PGP signature
Bug#331095: Orphaning instead of RFA
I've decided to orphan this package rather than listing it as RFA, and I'll upload a new package with a Debian QA Group maintainer later today. This package has no reverse dependencies any more, so unless someone steps up to take this package, there's no particular need for it to stay in Debian. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpP21Qqofe4f.pgp Description: PGP signature
Bug#331099: Orphaning instead of RFA
I've decided to orphan this package rather than listing it as RFA, and I'll upload a new package with a Debian QA Group maintainer later today. This package has no reverse dependencies any more, and AFAIK the only package which build-depends on it is libhtml-tokeparser-simple-perl, which I am also going to orphan. So, unless someone steps up to take this package, there's no particular need for it to stay in Debian. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpNjc9rQvTuq.pgp Description: PGP signature
Bug#331105: Orphaning instead of RFA
I've decided to orphan this package rather than listing it as RFA, and I'll upload a new package with a Debian QA Group maintainer later today. This package has no reverse dependencies any more, so unless someone steps up to take this package, there's no particular need for it to stay in Debian. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpfsdIcmmfom.pgp Description: PGP signature
Bug#335458: uw-imapd: Please document how to use real SSL cert (patch included)
Package: uw-imapd Version: 7:2002edebian1-11sarge1 Severity: minor Tags: patch Hi, I recently configured UW IMAPD to use a real SSL certificate signed by my own CA. However, I found the process a little confusing, mostly because I wasn't sure how to create the new PEM file in /etc/ssl/imapd.pem. Would you mind including a few paragraphs on this subject in README.Debian? I have taken a first pass at describing what to do, and the results are in the attached patch. You can feel free to modify it as you wish. Thanks, KEN -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages uw-imapd depends on: ii debconf 1.4.30.13 Debian configuration management sy ii libc-client2002e 7:2002edebian1-11sarge1 UW c-client library for mail proto ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libcomerr2 1.37-2sarge1common error description library ii libkrb53 1.3.6-2sarge2 MIT Kerberos runtime libraries ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7e-3SSL shared libraries ii netbase 4.21Basic TCP/IP networking system ii openssl 0.9.7e-3Secure Socket Layer (SSL) binary a -- debconf information: * uw-imapd/force_debconf_choice: true * uw-imapd/protocol: imaps -- Kenneth J. Pronovici [EMAIL PROTECTED] --- README.Debian 2005-10-23 23:48:35.505974608 -0500 +++ README.Debian.new 2005-10-24 00:05:11.143614680 -0500 @@ -16,6 +16,32 @@ in the openssl package to generate your own. +Using a real SSL certificate + + +If you already have your own SSL certificate, either one from Verisign or one +signed by your own CA (certificate authority), using your certificate with UW +IMAPD is easy. A PEM file is simply the combination of a key and a +certificate, and you already have both. + +First, you must make sure to use your insecure server key, and not the +original key that has a passphrase associated with it. If you use the original +key, client connections will hang, and you will end up with a lot of stuck +imapd processes all waiting for passphrase input that will never arrive. If +you don't have an insecure server key available, generate one using a command +something like this (and protect it with sensible permissions): + + openssl rsa -in server.key -out insecure.key + +To generate the PEM file, take your insecure server key and and cat that +together with your server certificate, something like this: + + cat server.crt insecure.key imapd.pem + +Of course, you will have to repeat this step each time your server certificate +changes (for instance, when it expires and is re-issued). + + Authentication == signature.asc Description: Digital signature
Bug#395917: babygimp: doesn't work with current version of perl-tk
On 11/12/06, Florent Bayle [EMAIL PROTECTED] wrote:
package babygimp
tags 395917 + patch
thanks
Hi,
here is a patch to fix this bug.
Hi, Florent,
Thanks for the patch!
You definitely solved the problem with starting the script. I made a
few other changes, and was then able to successfully open an existing
XPM file . (A patch relative to yours is attached.)
Unfortunately, the program still doesn't work properly, so I have to
leave this bug open.
When working in a new image, I can't consistently make the cursor draw
any pixels. I did coax it into a partially working state a few times
-- once where it worked more-or-less normally and once where cursor
clicks seemed to result in 2-4 random pixels in the image -- but most
of the time drawing with the cursor doesn't seem to do anything.
Do you have any interest in debugging this further? If you do, I
would really appreciate it. If not, I understand, and appreciate your
help in getting me this far.
Thanks again,
KEN
--
Kenneth J. Pronovici [EMAIL PROTECTED]
Index: babygimp
===
RCS file: /opt/public/cvs/debian/babygimp/babygimp,v
retrieving revision 1.4
diff -u -r1.4 babygimp
--- babygimp 12 Nov 2006 18:55:55 - 1.4
+++ babygimp 12 Nov 2006 19:10:04 -
@@ -7140,7 +7140,15 @@
{
shift;
my $self = shift;
-$self-{file} = $self-{files}-[$self-{filebox}-curselection()];
+my $index;
+my @curselection = $self-{filebox}-curselection();
+if([EMAIL PROTECTED]) {
+ $index = 0;
+}
+else {
+ $index = $curselection[0];
+}
+$self-{file} = $self-{files}-[$index];
}
# --
@@ -7149,7 +7157,15 @@
{
shift;
my $self = shift;
-my $relative_dir = $self-{dirs}-[$self-{dirbox}-curselection()];
+my $index;
+my @curselection = $self-{dirbox}-curselection();
+if([EMAIL PROTECTED]) {
+ $index = 0;
+}
+else {
+ $index = $curselection[0];
+}
+my $relative_dir = $self-{dirs}-[$index];
my ($newdir, $dummy) = dir_file($self-{dir}.$relative_dir);
$self-goto_dir( $newdir);
}
Bug#395917: babygimp doesn't start
On 10/28/06, Kenneth Pronovici [EMAIL PROTECTED] wrote: On 10/28/06, Wolfgang Karall [EMAIL PROTECTED] wrote: On Sat, 2006-10-28 at 13:21 -0500, Kenneth Pronovici wrote: Odd, I filed the same bug just minutes before you did. I'll mark this one as a duplicate. Yeah, consecutive bug numbers, very odd. :) Anyway, thanks for the quick reaction, hopefully this can be fixed, even though upstream seems to be pretty dead... I've already written upstream, and not only is the project dead, but so is his Christian's email address (it bounces with a permanent failure, sigh). I'll see if I can find another address, and I'll also take a pass at fixing it myself if I can't find him. Hi, Unfortunately, all of the email addresses I have available for upstream have bounced. I don't know enough about perl-tk to fix the problem right now. Besides that, I'm not sure I want to become the de-facto upstream for the package. For the time being, I'm going to leave the bug open, but write the release team and make sure that the package doesn't get released with etch. Eventually, if I can't find a good fix, I'll have the package removed from Debian entirely. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342103: XMLTV bug #342103
Ok, so Chris Butler does not look like he's going to take the package over. So, I'll upload the latest XMLTV release this afternoon or tomorrow and that will fix this. Sorry it took so long -- I wasn't expecting to have to be maintaining this package after Chris told me he was taking it over. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487096: Fixed in upstream 0.8.18
Looks like this got fixed in the new 0.8.18 release: /home/pronovic/tmp cat bug.py try: pass except (KeyboardInterrupt, SystemExit): pass /home/pronovic/tmp pychecker bug.py Processing module bug (bug.py)... Warnings... None I'll upload later today. KEN signature.asc Description: Digital signature
Bug#487096: false warnings on except
Probably because those two are derived from BaseException, while everything else is derived from Exception in Python 2.5. There is a patch around, which I did not test: https://thomas.apestaart.org/thomas/trac/changeset/938?format=diffnew=938 This patch does fix the bug for Python 2.5. Unfortunately, it also breaks pychecker for Python 2.5. I did talk with upstream. I'll submit an SF bug, and I'll plan to re-test when the next release happens (which might be as soon as this month). KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408261: Upstream bug
I think this is the same as upstream bug #2008061. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487096: Upstream bug
I have submitted this as SF bug #2018349. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487162: Upstream bug
I have submitted this as SF bug #2018350. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460355: pychecker: FTBFS: /usr/lib/python2.4/UserDict.py:4: No doc string for class UserDict
Interesting. It worked at my last upload. The unit tests are still valid, and the only problem is the location of the file the warning is coming from. I'll change the test expectations and upload later this weekend. KEN On Jan 12, 2008 4:21 AM, Lucas Nussbaum [EMAIL PROTECTED] wrote: Package: pychecker version: 0.8.17-6 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080111 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: dpkg-source: building pychecker in pychecker_0.8.17-6.dsc debian/rules build dh_testdir /usr/bin/python ./setup.py --quiet build --build-base build install --no-compile --install-purelib debian/tmp/lib/pychecker sh debian/regression.sh# note: build will fail if regression tests fail Running test1... Running test2... Running test3... 5c5 UserDict.py:4: No doc string for class UserDict --- /usr/lib/python2.4/UserDict.py:4: No doc string for class UserDict test3 FAILED Running test4... Running test5... Running test6... Running test7... Running test8... Running test9... Running test10... Running test11... Running test12... Running test13... Running test14... Running test15... Running test16... Running test17... Running test18... Running test19... Running test20... Running test21... Running test22... Running test23... Running test24... Running test25... Running test26... Running test27... Running test28... Running test29... Running test30... Running test31... Running test32... Running test33... Running test34... 5c5 getopt.py:42: No doc string for class GetoptError --- /usr/lib/python2.4/getopt.py:42: No doc string for class GetoptError test34 FAILED Running test35... Running test36... Running test37... Running test38... Running test39... Running test40... Running test41... Running test42... Running test43... Running test45... Running test46... Running test47... Running test48... Running test49... Running test50... Running test51... Running test52... Running test53... Running test54... Running test55... Running test56... Running test57... Running test58... Running test59... Running test60... Running test61... Running test62... Running test63... Running test64... Running test65... Running test66... Running test67... Running test68... Running test69... Running test70... Running test71... Running test72... Running test73... Running test74... Running test75... Running test76... Running test77... Running test78... Running test79... Running test80... Running test81... Running test82... Running test83... Running test84... Running test85... Running test86... Running test87... Running test88... Running test89... Running test90... Running test92... Running test93... Running test94... Running test95... Running test96... Running test97... Running test98... Running test1000... Running test1001... Running test1002... Running test1003... 98/100 tests passed (2 failures). Failed test(s): test3 test34 make: *** [build-stamp] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 The full build log is available from: http://people.debian.org/~lucas/logs/2008/01/11 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460357: git-buildpackage: FTBFS: IndexError: list index out of range
Hi, I'll take a look at this, but it's unlikely I'll find a solution very soon. Upstream doesn't have a lot of time right now, and I'm not an expert in the codebase (though sometimes I do get lucky). I think that it's probably best for you to fix your FTBFS by removing pychecker from debian/rules temporarily. You can put it back when the bug is fixed. Maybe we should clone 406347? You can fix your FTBFS by removing pychecker from debian/rules, and I'll keep this bug against pychecker open until we can figure out the problem. That way, the severity for the pychecker bug can be set to normal (which is more appropriate since AFAIK you're the only affected user), and users won't have any problem building your package in the meantime. Let me know what you think. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460357: git-buildpackage: FTBFS: IndexError: list index out of range
On Jan 14, 2008 10:36 AM, Guido Guenther [EMAIL PROTECTED] wrote: Hi, On Sat, Jan 12, 2008 at 10:34:44AM -0600, Kenneth Pronovici wrote: I'll take a look at this, but it's unlikely I'll find a solution very soon. Upstream doesn't have a lot of time right now, and I'm not an expert in the codebase (though sometimes I do get lucky). The problem only shows with the python2.4 2.4.4-7, 2.4.4-6 is fine. Ok. That's a hint, at least. You'll see a control request to clone the bug. I reassigned the original back to git-buildpackage, and kept the copy assigned to pychecker. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463734: python-epydoc: epydoc parses file in global path instead of local directory
On Feb 2, 2008 2:01 PM, Christoph Burgmer [EMAIL PROTECTED] wrote: Package: python-epydoc Version: 3.0~beta1-5 Severity: normal If a package is available globally to the system in addition to the version in the local directory epydoc seems to prefer the global file over the local in some occasions when building the package's API. Ok, I'll take a look at it. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463734: python-epydoc: epydoc parses file in global path instead of local directory
Christoph - I'll hopefully get 3.0 uploaded later today or tomorrow. After it hits the archive, please re-test the stacktrace.txt scenario. If the new version doesn't fix that problem, please file a separate bug. Edward - I'll leave this bug open while you're looking into wrong-versions issue. Let me know if you want me to file a separate SF bug report. KEN On Feb 3, 2008 12:01 PM, Edward Loper [EMAIL PROTECTED] wrote: The bug that you attached (stacktrace.txt codeproducingexception.txt) should be fixed in the epydoc 3.0 stable release (which was released just a few days ago, and hasn't made its way to a debian package yet. I'll look into why epydoc might pick up the wrong versions of modules when you specify them as python names (foo or foo.bar) rather than paths (foo.py or foo/bar/). -Edward -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463882: Please add firefox to Recommends in epydoc-doc
On Feb 3, 2008 5:46 PM, Marco Rodrigues [EMAIL PROTECTED] wrote: Hi! You should check this one.. Debian have done this request for this package, and so many others in Debian. You're right not to recommend a package that isn't at Debian, but with ... | firefox | ... it doesn't hurt. http://packages.qa.debian.org/d/dhelp/news/20080203T163202Z.html Other developers are, of course, welcome to do what they wish. However, my read of Policy is that it's not allowed, so I won't be making the change to epydoc-doc. There's no reason Ubuntu can't patch this on their end -- they've done that before with epydoc (sometimes against my wishes, as a matter of fact). KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460698: Cloning bug #460357
On Feb 8, 2008 9:10 AM, Guido Guenther [EMAIL PROTECTED] wrote: On Mon, Jan 14, 2008 at 10:39:27AM -0600, Kenneth Pronovici wrote: Maybe we should clone 406357? You can fix your FTBFS by removing pychecker from debian/rules, and I'll keep this bug against pychecker open until we can figure out the problem. That way, the severity for the pychecker bug can be set to normal (which is more appropriate since AFAIK you're the only affected user), and users won't have any problem building your package in the meantime. Here's a patch that fixes the problem for me. Using if instead of elif we might end up trying to index an already removed list element: I agree, it looks like that was supposed to be an elif, not an if. Your change looks correct, and I don't think it can hurt anything. I'll get the patch applied and a new package uploaded as soon as possible. I'll close both this bug and 460698 as part of my upload. Also, I submitted your patch upstream as SF request #1889814. Thanks for looking into this. I'm sorry I wasn't able to get to it sooner, and I appreciate the help. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453092: Please package pychecker2 modules
On Nov 27, 2007 4:20 AM, Emilio Pozuelo Monfort [EMAIL PROTECTED] wrote: We at the PythonApplicationsPackagingTeam are updating [1] the spe package, but it needs pychecker2, which is included in pychecker's tarball. Actually Spe provides the module in its source tree, but we would like to get rid of it in favour of pychecker's package, as it would mean we'd benefit from bug fixes, new releases... So it would be great for us if you could please include pychecker2. Hi, I can put this code in the package... but I'm not sure that you would benefit from bug fixes and new releases, etc. Pychecker itself (the app) doesn't seem to use that code, and AFAIK it's never actually been released. I always thought it was just a work-in-progress, and I can't recall Neal (upstream) ever checking anything in to that directory. (I've been following the CVS checkins mailing list on SF for a few years now.) I will double-check with Neal and see what he thinks, just to be sure. As far as mechanics of the package go, I'm thinking that I should provide a new python-pychecker2 library package that is separate from the existing pychecker package. That way, you can depend more specifically on what you need. Does that sound like it would meet your needs? You've probably already checked before filing this bug report... but has the Spe version of this code diverged at all from the Pychecker version? Or did they copy it verbatim and leave it untouched? I'm just curious whether I (or upstream) will have to merge in any changes. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453092: SPE pychecker2
On Nov 27, 2007 5:15 PM, Emilio Pozuelo Monfort [EMAIL PROTECTED] wrote: [ CCing bug 453092, request for pychecker2 packaging ] Kenneth Pronovici: You've probably already checked before filing this bug report... but has the Spe version of this code diverged at all from the Pychecker version? Or did they copy it verbatim and leave it untouched? I'm just curious whether I (or upstream) will have to merge in any changes. We were still discussing it when I filled the report, and I didn't know the details yet. I should probably have waited until I knew them. Sorry for this. No worries. Kenneth, could you please take a look at the changes (which are few and only in one file, pychecker2/main.py) and let us know what do you think about them? And if you think they could be forwarded upstream. I will look them over, and when I hear back from Neal, I'll let you know what he thinks, too. It might be a little while (a few days to a week) before I hear from Neal. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456179: pychecker: man page omits many command-line switches
On Dec 13, 2007 7:15 AM, Dan O'Huiginn [EMAIL PROTECTED] wrote: The man page for pychecker omits many of the command-line switches which are listed in 'pychecker --help'. It would be nice to: a) update the man page to point users at --help for more complete documentation b) include more of the options in the man page (better still, is there any way of automatically generating this from --help?) Hi, Thanks for the bug report. I would gratefully accept any patch improving the manpage. Otherwise, I will put this on my TODO list, and I'll work on it the next time I have a chance. Unfortunately, I don't know of a particularly easy way of generating the manpage from the output of --help. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456179: pychecker: man page omits many command-line switches
On Dec 20, 2007 7:51 PM, Dan O'Huiginn [EMAIL PROTECTED] wrote: I am attaching a patch to update the man page. Thanks! I am preparing an upload now. I always appreciate it when users are willing to provide patches. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449525: python-epydoc: Please add (recommend) dependency to python-docutils
On Nov 6, 2007 4:12 AM, Michael Hanke [EMAIL PROTECTED] wrote: Package: python-epydoc Version: 3.0~beta1-4 Severity: normal please add a package dependency recommendation to the 'python-docutils' package. epydoc can understand restructured text as Python docstring format, but the API docs of modules that use it are only generated correctly if the python-docutils package is installed. Hi, Sorry I didn't notice this previously. I'll work on getting a new upload done in the near future. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453092: SPE pychecker2
I heard back from Neal, and he doesn't mind me including pychecker2 in the Debian package. So, I have made the changes and I will upload 0.8.17-5 later this evening. I changed my mind and decided to add the new code to the existing Debian package, rather than making a special library package to hold only pychecker2. Just depend on pychecker and you should be able to 'import pychecker2' automatically from any version of python that works with the python-support infrastructure. I also applied the SPE patch to pychecker2/main.py, so the new Debian package should be fully-compatible with SPE. (The patch has been submitted to SourceForge, as request #1845213. Hopefully, we can get it committed to CVS at some point, but there are lots of other pending patches and it may be a while.) Note: I have not done any testing other than to check that the import succeeds, since I don't know what results are expected from this code. Please test and make sure that the new package works as expected. Feel free to re-open this bug report if something isn't working properly. Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309593: libhtml-linkextractor-perl: Missing liburi-perl dependency (run-time)
Package: libhtml-linkextractor-perl Version: 0.121-1 Severity: important How to repeat: # apt-get remove liburi-perl # apt-get install libhtml-linkextractor-perl % perl -e 'use HTML::LinkExtractor;' Can't locate URI.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/share/perl5/HTML/LinkExtractor.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/HTML/LinkExtractor.pm line 6. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. That seems straightforward enough. I guess I'll add a dependency on liburi-perl. I don't think I'll be able to push this into sarge, but I will fix it in ustable. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgphk4nB9C36n.pgp Description: PGP signature
Bug#293571: Epydoc wrongly escapes the at-sign in decorators in docstring codeblocks
$ cat foo.py def nop(x): No-operation decorator. Use like this: [snip] But epy/index.html corrupts the @-sign. nop(x) No-operation decorator. Use like this: #64;nop Ok, I see it. It looks like the problem is that epydoc generates: span class=py-comment#64;nop/span rather than: span class=py-comment#64;nop/span I'll see if I can figure out what's going on and I'll pass what I find on to upstream. Thanks for the report. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpkMwMgMEvV3.pgp Description: PGP signature
Bug#293571: Epydoc wrongly escapes the at-sign in decorators in docstring codeblocks
Edward, Can you take a look at this Debian bug and let me know what you think? You can find it here: http://bugs.debian.org/293571 This is what I've found so far. The _doctest_sub() function in colorizer.py has responsibility for colorizing doctest blocks. It uses a regular expression (_DOCTEST_RE) to fill in some span tags that specify the coloring. The _COMMENT pattern '(#.*?$)' within _DOCTEST_RE is inadvertently catching the # character in #64; and putting a formatting span tag between the and # characters, resulting in a corrupt line: span class=py-comment#64;nop/span rather than: span class=py-comment#64;nop/span I can fix the problem by getting rid of the _COMMENT pattern all together (ha!) or by by changing the _COMMENT pattern to something like '(^[]#.*?$)'. I don't like either option, and I'm figuring you will have something more appropriate in mind. Thanks for the help, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgp9eemsXRvSh.pgp Description: PGP signature
Bug#289141: drop the patch?
Sorry for the delay in the reply, for some reason the e-mails got lost (faulty spam filtering?) and I only found out you'd answered upon checking up on the bug report. It's OK. Spam processing is becoming a real pain. :( OK, you are right, the JavaScript seems to be incorrect so I suppose pushing for a fix is hard to justify. In my case I have no control over the broken JavaScript I am trying to parse, so I'll go with the patch you produced and hope that the authors of the pages fix their software. I see no objection to closing the bug. Thanks for your time and for the research you did on this issue! You're welcome. For the time being, I'm going to leave the bug open, since Gisle hasn't decided what to do yet (as far as I can tell). However, I'll feel free to close it whenever the CPAN bug is resolved. Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpu91pZv6b0p.pgp Description: PGP signature
Bug#300922: pychecker.postinst error
Please let me know if I can be of further assistance. Thanks for the very complete report. I will let you know what more I need from you. KEN pgp1lwDZPFfKy.pgp Description: PGP signature
Bug#290010: [Xmltv-devel] About tv_grab_jp
On Wed, Mar 23, 2005 at 07:37:33PM +0900, Takeru KOMORIYA wrote: The site for Japanese grabber tv_grab_jp has changed its format recently. So, I've wrote the patch against current cvs. It works well for me, but I think we need to test it for a while before commit. Now in CVS. The new version of tv_grab_jp supports multiple region settings requested in #1101373. Thanks! I will probably wait for the next official XMLTV release before putting this change into the Debian package. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpyR4Pupfd4Z.pgp Description: PGP signature
Bug#300922: pychecker.postinst error
I received the following error:
Setting up pychecker (0.8.14-5) ...
/var/lib/dpkg/info/pychecker.postinst: line 45:
/usr/bin//etc/alternatives/python: No such file or directory
Line 29 of pychecker.postinst has a comment that is not true:
PYTHON=`readlink /usr/bin/${i}` # note: returns basename
Yep, it looks like that comment is incorrect. It returns basename if
and only if the link is a relative link, i.e.
python - python2.3
If the link is an absolute path like this:
python - /etc/alternatives/python
then it returns the absolute path.
It looks like if I use the -f switch, I get back a canonical absolute
path every time.
Because I set up the following:
update-alternatives --install /usr/bin/python python /usr/bin/python2.1 20
update-alternatives --install /usr/bin/python python /usr/bin/python2.2 20
update-alternatives --install /usr/bin/python python /usr/bin/python2.3 20
Ok, I think understand what you've done. The only problem is, I don't
think that this solution is general enough to deal with all
alternatives. What I mean is, just because the code yields python2.3
doesn't mean that the compileall.py script can be found in
/usr/lib/python2.3 as is required at the bottom of the postinst.
For instance, you might have the alternative set to yield:
/etc/alternatives/python - /usr/local/python/python2.3.3/bin/python
In this case, we would probably derive just PYTHON=python and then the
postinst would try to find compileall.py in /usr/lib/python, which
doesn't exist.
KEN
--
Kenneth J. Pronovici [EMAIL PROTECTED]
pgpuW3tmddXms.pgp
Description: PGP signature
Bug#300922: pychecker.postinst error
On Wed, Mar 23, 2005 at 04:36:42PM -0600, Kenneth Pronovici wrote: In this case, we would probably derive just PYTHON=python and then the postinst would try to find compileall.py in /usr/lib/python, which doesn't exist. Sorry, I left off that I think I have a solution. I can just call compileall.compile_dir() directly using the Python interpreter, which presumably knows where compileall.py is since it's part of the standard library. I've reworked the postinst again and tested it with a real python, (i.e. /usr/bin/python-python2.3), with no real python (i.e. /usr/bin/python does not exist) and with alternatives (using your python2.1 example). It seems to work fine. I will upload later today. The upload will close the bug. If you still have problems with this new version, write me and the bug back and I'll reopen the bug and try to come up with a better fix. Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpWwgdl1to68.pgp Description: PGP signature
Bug#301454: Add documentation about polygen sources.
Package: polygen Version: 1.0.6-4 Severity: wishlist Hi, _ / Please document in manpage or \ | /usr/share/doc/polygen what polygen | \ sources are available and what they do. / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || It was a rather cool command-line you posted to -curiosa, but I was disappointed that I had to dig around in /usr/share to see what sources other than pythoniser were available. Could you please document them either in a file in /usr/share/doc/polygen, or in the manpage? Based on the manpage, I expected 'polygen' with no arguments to give me a list, but it didn't. KEN -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages polygen depends on: ii ocaml-base-nox3.08.3-3 Runtime system for ocaml bytecode -- no debconf information -- Kenneth J. Pronovici [EMAIL PROTECTED] pgp4EynTi8WBI.pgp Description: PGP signature
Bug#302198: jspwiki: Upgrade changes my configuration
Package: jspwiki
Severity: important
Tags: patch
Upgrading JSPWiki unexpectedly changes my configuration. In particular,
an upgrade seems to change jspwiki.pageProvider to FileSystemProvider
when I had previously set VersioningFileProvider. When this happens, it
usually takes a few weeks for my users to notice that all of their
recently-updated pages show updated by Unknown on the bottom instead
of their name, and then it causes a lot of confusion.
I dug around in the package, and I think this is possibly happening
because of a bug in the postinst. The postinst seems to be trying to
implement:
if jspwiki.properties has This file is managed by Debconf on line 1
get out now and don't make any changes
However, my properties file does not have this string on line 1, and yet
the postinst seems to change the properties file anyway.
The postinst uses this code to accomplish its check:
if { head -1 /etc/jspwiki/jspwiki.properties | grep -q This file is managed
by Debconf; }
then
exit 0
fi
I am not familiar with the {} shell syntax. I would have expected to
see something like this instead:
head -1 /etc/jspwiki/jspwiki.properties | grep -q This file is managed by
Debconf
if [[ $? != 0 ]];
then
exit 0
fi
Anyway, I don't really care how this gets fixed - I just want to make
sure that the next time I upgrade jspwiki, it doesn't change the
pageProvider.
Thanks,
KEN
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to
en_US)
--
Kenneth J. Pronovici [EMAIL PROTECTED]
pgpxu66UIOhW1.pgp
Description: PGP signature
Bug#298667: PythonCard or PythonCardPrototype?
hello, I used to have an old version of PythonCard installed, and now I installed the Debian packages python-pythoncard, pythoncard-doc, pythoncard-tools, and pythoncard, all versions 0.8.1-1. Ok. Now when I run resourceEditor, I get Unable to find PythonCard installation. A look at the shell script shows that it is looking in /usr/lib/python2.3/site-packages/PythonCard/tools/resourceEditor/resourceEdit or.py $@. However, I do not have a directory /usr/lib/python2.3/site-packages/PythonCard, I only have /usr/lib/python2.3/site-packages/PythonCardPrototype. Hrm. That doesn't make a lot of sense. A check of the python2.3-pythoncard_0.8.1-1_all.deb using dpkg --contents shows that all of the Python files are installed to the PythonCard directory. ./usr/lib/ ./usr/lib/python2.3/ ./usr/lib/python2.3/site-packages/ ./usr/lib/python2.3/site-packages/PythonCard/ ./usr/lib/python2.3/site-packages/PythonCard/components/ ./usr/lib/python2.3/site-packages/PythonCard/components/__init__.py Do you have the python2.3-pythoncard package installed on your system as well? The dependencies should force it. How did you get these packages installed? Did they come along with an 'apt-get -u upgrade' or similar, or did you force the upgrade by just specifying those four packages by hand on the command line? Or, did you perhaps install directly using dpkg? On my system dpkg seems to (mostly) install the four packages you mentioned but then reports errors related to the missing python2.3-pythoncard package. My best theory right now is that you have an old version of the python2.3-pythoncard package installed. To confirm this, use something like this: COLUMNS=132 dpkg -l | grep pythoncard If it does turn out that you have an old version of python2.3-pythoncard installed, then I think the fix is for me to be more specific about the versioned dependencies between python-pythoncard and python2.3-pythoncard (like python-pythoncard should depend on the python2.3-pythoncard with the exact same version it has). KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpcM685HdyEn.pgp Description: PGP signature
Bug#298667: PythonCard or PythonCardPrototype?
Well, I haven't heard back from you, but I have time to work on this bug today, so I am going to make an upload. I am going to assume that my theory is correct, and that your problem was caused by loose dependencies between the various Pythoncard binary packages. I've tightened up those dependencies, and I'll upload -2 later this afternoon. Feel free to reopen the bug if the new upload does not fix your problem. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpwdyn5zpAjn.pgp Description: PGP signature
Bug#293571: Going to upload
I've written upstream about this a few times, but he doesn't seem to be there right now (or my messages are being spam filtered or something). I think my change to the comment regular expression is sensible, even if it's not a perfect solution, so I am going to make that change and upload later today. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpfg9SII2clv.pgp Description: PGP signature
Bug#299340: Depends: not complete
Shaun Andy - A user of FreeGuide, which uses xmltv, says he needs libarchive-zip-perl and libio-stringy-perl installed for freeguide to work. I haven't needed these packages. The freeguide upstream author, Andy, thinks it might be because the grabber for his region needs it. What do you know of this issue? Should xmltv-util Recommends: libarchive-zip-perl, libio-stringy-perl? I build the Debian dependencies based on the list that Ed Avis has put into XMLTV's README file. Required files are listed as Depends, optional files (like Term::Progressbar) are listed as Recommends, etc. I just checked, and as of now, none of the Perl modules in these two packages are listed in the README. If some grabber or utility requires these two additional packages, then I should certainly add them to the dependencies. However, I'd like to know what grabber it is that's having the problem, and I'd like to coordinate with Ed to make sure that these packages are listed in the upstream README as well. From a quick check through the code, it looks like tv_grab_uk_bleb is the offending grabber, or possibly tv_grab_se_swedb. These extra dependencies are even listed in the Makefile.PL. However, Makefile.PL doesn't seem to be enforcing the prerequisite on build. I don't think I've ever seen that before. Usually, a build within a pbuilder chroot exposes this sort of thing. Can you have your FreeGuide user confirm that his problem is with tv_grab_uk_bleb or tv_grab_se_swedb? In the meantime, I'll put together a new package with the correct dependencies and I'll also create a patch for the upstream README to fix the discrepancy. If you want, you can reassign this bug to xmltv-util. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpUpsnAHqtBy.pgp Description: PGP signature
Bug#302329: nbio: FTBFS (ppc64/gcc-4.0): Please Build-Depend on 'libgcj-dev' instead of 'libgcj4-dev'
Package: nbio Version: 2.0-10 Severity: wishlist Tags: patch Please use the new 'libgcj-dev' package from gcc-defaults instead of 'libgcj4-dev' in the Build-Depends. I can do this. Just for my reference, what is the reason for the change? KEN pgpEUhpAvySAS.pgp Description: PGP signature
Bug#302329: nbio: FTBFS (ppc64/gcc-4.0): Please Build-Depend on 'libgcj-dev' instead of 'libgcj4-dev'
On Thu, Mar 31, 2005 at 07:32:34PM +0200, Andreas Jochens wrote: On 05-Mar-31 10:14, Kenneth Pronovici wrote: Package: nbio Version: 2.0-10 Severity: wishlist Tags: patch Please use the new 'libgcj-dev' package from gcc-defaults instead of 'libgcj4-dev' in the Build-Depends. I can do this. Just for my reference, what is the reason for the change? The ppc64 port uses gcc-4.0 as its default compiler. Consequently packages like nbio are compiled with gcj-4.0 and libgcj6-dev. There is no gcc-3.3, gcj-3.3 or libgcj4-dev on ppc64. With this change, this is no longer a problem because gcc-defaults takes care of providing the correct versions. Moreover, switching to a newer version of gcc will be possible without changing the Build-Depends. Got it. I'll make the change and upload sometime either late this week or over the weekend. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpR5pEghNe6U.pgp Description: PGP signature
Bug#304477: Attempt to use ENCODING when OUTPUT is scalar ref = die
Package: libxml-writer-perl Version: 0.531-1 Severity: normal File: /usr/share/perl5/XML/Writer.pm -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ perl -MXML::Writer -e 'new XML::Writer(OUTPUT = \$a, ENCODING = utf-8);' Not a GLOB reference at /usr/share/perl5/XML/Writer.pm line 442. Thanks for the report. I'll take a look at it myself, and if I don't see anything obvious, I'll forward this upstream. KEN pgpNg6rmkc4vS.pgp Description: PGP signature
Bug#304477: Attempt to use ENCODING when OUTPUT is scalar ref = die
Package: libxml-writer-perl Version: 0.531-1 Severity: normal File: /usr/share/perl5/XML/Writer.pm -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ perl -MXML::Writer -e 'new XML::Writer(OUTPUT = \$a, ENCODING = utf-8);' Not a GLOB reference at /usr/share/perl5/XML/Writer.pm line 442. Thanks for the report. I'll take a look at it myself, and if I don't see anything obvious, I'll forward this upstream. Ok, I looked at this a little more closely. This error is coming from binmode(), which is expecting a typeglob for its first argument. In this case, that first argument would be a reference to $a. Since $a hasn't been defined yet in your script, wouldn't you expect an error? I find that setting $a=*STDOUT or passing in OUTPUT=\*STDOUT or OUTPUT=\*STDERR seems to work fine. I'm really not a Perl expert. Is there something I'm missing here? Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpg0TV2sp6Vt.pgp Description: PGP signature
Bug#304477: Attempt to use ENCODING when OUTPUT is scalar ref = die
On Thu, Apr 14, 2005 at 08:25:51AM -0400, Anthony DeRobertis wrote: Kenneth Pronovici wrote: Since $a hasn't been defined yet in your script, wouldn't you expect an error? No. The documentation says that passing a reference to a scalar will have the XML written to the scalar (you can do $a = '' first, it doesn't make a difference). Ok, I understand now. The scalar gets converted into an XML::Writer::_String class which is supposed to act like a file handle. I've played with this some, but it's beyond my understanding of Perl. I'm going to forward it upstream. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgp54ZZlCqpKl.pgp Description: PGP signature
Bug#304477: Debian XML::Writer bug
Hi, I'm the maintainer for the Debian XML::Writer packages. I've just received Debian bug #304477: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304477 This bug documents a problem with the OUTPUT constructor parameter. The constructor bombs out when this parameter is passed a scalar reference. I've done a little digging myself (as documented in the bug report) but this is beyond my understanding of Perl. Could you please take a look at it and let me know what you think? If there's someone else I should be writing instead, please let me know. If possible, please CC the Debian bug report [EMAIL PROTECTED] in your reply(s). Thanks, KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304477: Debian XML::Writer bug
On Fri, Apr 15, 2005 at 07:25:31PM +0100, Joseph Walton wrote: [snip] Sorry for a the lengthy response - none of those solutions is more than about five lines, and it's really a question of policy rather than mechanism. The submitter suggests something like this: Change the documentation to better explain what ENCODING does, and why it won't work with scalar refs for OUTPUT. Also document that the strings will be stored as Perl's unicode. Then add the check for passing both and die. Actually, considering PerlIO now gives :encoding for files, you might want to mark ENCODING deprecated, too. From my perspective, it would be enough to die with a sensible error if both options are passed in, since they don't work together. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpE2pBelO3mB.pgp Description: PGP signature
Bug#307017: xmltv-util bug
I assume we're talking about the tv_grab_na_dd grabber here? If so, I believe the GUI piece of it is still experimental. However, I will forward this bug report upstream and see what they think. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpC0OU308yYv.pgp Description: PGP signature
Bug#307017: tv_grab_na_dd dialog bug
Note that the actual dialog that accepts input does indicate: Timezone offset (+/-) (+) Based on this, I guess you can't be too surprised when it doesn't accept input that doesn't match the format (+/-), such as -400 or values containing Eastern or whatever. Turning this question into a listbox is not all that easy. Most grabbers are written for the terminal. They use special Ask() and say() functions to present questions and information to the user. When --gui is enabled, the questions and information are just presented in dialog boxes rather than being written to the terminal. What upstream has decided to do is put the first two dialogs together into one, so it's easier to see the instructions. That wouldn't solve your problem if you were still confused about having to enter an offset versus a timezone name, but I don't think that can be helped. Anyway, I'll upload later today. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpxmBO4ycPDc.pgp Description: PGP signature
Bug#290033: /usr/bin/tv_grab_no: tv_grab_no fails to grab - format of source changed?
Independent of which channels are selected - once the channels section of the xml is generated the package returns: Yeah, this is already known. It's SourceForge bug #1098886. Hopefully, the problem will be fixed in the next XMLTV release. I don't know when that will be, however. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpq0wJ4KS319.pgp Description: PGP signature
Bug#290010: tv_grab_jp : cannot accept multiple region.
When getting program-guides from multiple resion written in one configration file, tv_grab_jp ignore some regions, only last written region. Thank you for the report. I have filed this with upstream as SourceForge bug #1101373. Feel free to track the bug there if you would like; otherwise, I will update the Debian bug report with important details as I hear about them. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpnGDMbvMBKQ.pgp Description: PGP signature
Bug#289611: xmltv: tv_imdb garbles characters
tv_imdb (and possibly other xmltv scripts) garbles non-ascii characters, probably since the last update of xmltv (the scripts worked fine before 2004-12-26, but weren't tested since then). For reference, I have filed this with upstream as SourceForge bug #1101376. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpGHm8KKCUpv.pgp Description: PGP signature
Bug#176282: Debian tv_grab_na bug
Kingsley - I'm coming back to this ancient wishlist bug again, #176282: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=176282 You can't be seeing this actual problem any more with tv_grab_na (since it doesn't exist any more), but I'm wondering whether you have the same or a similar problem with tv_grab_na_dd. I'd really prefer to close this bug unless we can come up with a specific plan for a change that would make you happy. Thoughts? KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpbrAWExI2Af.pgp Description: PGP signature
Bug#248358: Debian bug #248358
Just for reference, I've filed this with upstream as SourceForge bug #1101385. I have a feeling that Ed lost this bug when he was out of the country earlier this year, and I forgot to remind him about it. Now that I've filed the upstream bug, at least it won't get lost again. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgphWEcN2ShoG.pgp Description: PGP signature
Bug#289141: CPAN Bug Reference
I've filed this bug with CPAN as #9676: http://rt.cpan.org/NoAuth/Bug.html?id=9676 KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpGiSdXB0OjX.pgp Description: PGP signature
Bug#291292: python-epydoc: postinst fails: on readlink /usr/bin/python
When trying to install the python-epydoc package I get the following error: Setting up python-epydoc (2.1-5) ... dpkg: error processing python-epydoc (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: python-epydoc E: Sub-process /usr/bin/dpkg returned an error code (1) This seems to be caused by this line in the postinst script: PYTHON=`readlink /usr/bin/python` /usr/bin/python does not exists. That get installed by the python package and you're depending on python2.3. Good point. Guess I've never tested installing this package when I didn't have the default Python installed. I do now have to choose with Python to compile the .py files with. What I'm going to do is the same thing the wrappers do - I'll choose the first one I find of python, python2.3, python2.2 or python2.1. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgptGh443Dxpd.pgp Description: PGP signature
Bug#296938: jspwiki: Latest build broken with Java 1.4
Package: jspwiki Severity: important I'm using Blackdown's Java 1.4 package with JSPWiki, which has always worked before (at least, for the last year or so). The latest build of the package (2.0.52-8) doesn't work any more with this install of Java. It blows up with this exception: javax.servlet.ServletException: com/ecyrd/jspwiki/tags/AttachmentsIteratorInfo (Unsupported major.minor version 49.0) As near as I can tell, this is because JSPWiki.jar (or some other jar?) was built with a newer version of Java, perhaps v1.5. I rebuilt the package myself using the Blackdown 1.4 javac and now everything works again. I think that the package should probably be built with the minimum supported version of Java, so as many people as possible can use it. The docs on jspwiki.org say that the 2.0 branch should work with Java 1.3 or better. KEN -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en, LC_CTYPE=en_US (ignored: LC_ALL set to en_US) -- Kenneth J. Pronovici [EMAIL PROTECTED] pgp0yhHDayy7S.pgp Description: PGP signature
Bug#296936: jspwiki: Missing build dependency on dpatch
Package: jspwiki Severity: normal Version 2.0.52-8 needs dpatch to build, but that package isn't listed on the Build-Depends-Indep line and is not part of build-essential. KEN -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en, LC_CTYPE=en_US (ignored: LC_ALL set to en_US) pgpExFG94NFyW.pgp Description: PGP signature
Bug#296961: babygimp: default options helpdir and browser
It'd be nice if the help directory in the Options dialog defaulted to the package installed /usr/share/doc/babygimp/doc instead of /usr/local/doc/Babygimp. And it'd be nice if the browser there defaulted to something neutral like sensible-browser instead of kdehelp, so that at least something will pop up for those not using kde. Seems... sensible. :) I'll make the changes and upload a new version, hopefully this weekend. KEN pgpGv4EwPUD0k.pgp Description: PGP signature
Bug#437106: mentions /usr/doc/ncompress/README.Debian in package description
On 8/10/07, Jonas Meurer [EMAIL PROTECTED] wrote: Package: ncompress Version: 4.2.4.0-2 Severity: wishlist Hello, ncompress reffers to /usr/doc/ncompress/README.Debian in its package description. This should be changed to /usr/share/doc/ncompress/README.Debian, as documentation has been moved from /usr/doc to /usr/share/doc for ages. Ok, good point. I'll fix it. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433804: epydoc: inaccurate documentation: -u is no longer supported
On Thu, Jul 19, 2007 at 09:23:41PM -0500, Kenneth Pronovici wrote: On 7/19/07, Cyril Brulebois [EMAIL PROTECTED] wrote: Package: epydoc Version: 3.0~beta1-1 Severity: normal Tags: patch please ask upstream to drop the '-u' option from the manpage, since it is no longer supported. I discovered that by fixing some FTBFS due to '-n' being dropped, and needed to adjust '-u' too. Ok, I'll pass this along upstream. Sorry the loss of -n caused you an FTBFS. I looked at the code, and I think that -u was lost accidentally. The --url option is still supported, and I think that the -u option was just missed when Edward rewrote the argument processing code. He kept around single-character options in several other cases, including -o, -q, -v and -h. I think that -c was lost in the same way as -u, since it's still documented in the manpage. I'm less sure about -n, since it's no longer documented. However, I hope Edward will add it back in, just for the sake of compatibility. I submitted two patches upstream as a part of SF bug #1760001 (one for -u and -c, another for -n) and I'll upload a new Debian package containing my changes either today or tomorrow. If Edward disagrees, I'll revert my change and upload manpage fixes instead. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#308372: Still happens with 3.0 beta 1
Just a note to indicate that I tested this with 3.0 beta 1 and it's still true. I filed SF bug #1760007 to track the problem upstream. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#433424: python-epydoc: bad identifier error when module names with a - (dash) are imported
On Tue, Jul 17, 2007 at 12:38:20AM -0700, Cameron Dale wrote: Package: python-epydoc Version: 3.0~beta1-1 Severity: minor A python file can import a module whose name contains a - (dash), using the __import__ builtin function (just doing a normal import fails, as identifiers cannot contain dashes): Ok, I reported this upstream as SF bug #1760011. KEN signature.asc Description: Digital signature
Bug#308372: Eypdoc 3.0 beta 1 hopefully fixes encoding issue
Stephane - I think that this old Epydoc bug should be addressed in the new 3.0 beta 1 release. Do you still have a test case around that you could check against? Upstream says: The intended behavior is that epydoc should *not* ignore the encoding of the source code, but it *should* always generate ascii xhtml file output. In particular, when epydoc reads in documentation, it converts them to unicode strings using whatever encoding is appropriate for the given source file. When it writes the documentation, it writes it as ascii, but encodes all non-ascii characters using xhtml character references to the appropriate unicode codepoints. On any browser that supports xhtml unicode character references, this should result in correctly displayed html output. (Hopefully that's all browsers -- but I haven't done extensive testing). One of the reasons that I chose this design is that the output files can sometimes mix text that originates from multiple source files; and those source files might be encoded using different encodings. So the only sensible thing to do is to convert everything to a common encoding. It would be possible, if desired, to add an option to epydoc that allows an 'output encoding' to be specified. Any characters that could be encoded in that encoding would be; and any characters that could not be encoded would be represented using xhtml character references. So I have two questions: a) is the current design (encoding everything w/ character references) insufficient? If so, why? (e.g., because browsers xyz don't handle charrefs correctly) b) if the current design is insufficient, would adding an option to specify the output encoding be sufficient? What do you think?? KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#441368: python-epydoc: Indexed Terms (X{...}) from method docstrings linked wrongly in index
Ok, I'll push this upstream. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441368: Filed as SF bug #1791281
This has been filed as SF bug #1791281. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#433424: Fixed upstream
This is fixed upstream in svn 1606. I'm not sure when beta 2 will be coming out. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#441368: Fixed upstream
Upstream says this is fixed in svn 1603. I'm not sure when beta2 is coming out. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#441368: Patch from upstream fix
Attached is a patch from upstream's Subversion for this fix.
KEN
--
Kenneth J. Pronovici [EMAIL PROTECTED]
Index: epydoc/docwriter/html.py
===
--- epydoc/docwriter/html.py (revision 1602)
+++ epydoc/docwriter/html.py (revision 1603)
@@ -2865,6 +2865,8 @@
def _terms_from_docstring(self, base_url, container, parsed_docstring):
if parsed_docstring in (None, UNKNOWN): return []
terms = []
+# Strip any existing anchor off:
+base_url = re.sub('#.*', '', base_url)
for term in parsed_docstring.index_terms():
anchor = self._term_index_to_anchor(term)
url = '%s#%s' % (base_url, anchor)
signature.asc
Description: Digital signature
Bug#433424: Patch from upstream fix
Attached is a patch from upstream's Subversion for this fix.
KEN
--
Kenneth J. Pronovici [EMAIL PROTECTED]
Index: epydoc/apidoc.py
===
--- epydoc/apidoc.py (revision 1605)
+++ epydoc/apidoc.py (revision 1606)
@@ -111,11 +111,12 @@
elif isinstance(piece, basestring):
for subpiece in piece.split('.'):
if piece not in self._ok_identifiers:
-if self._IDENTIFIER_RE.match(subpiece):
-self._ok_identifiers.add(piece)
-else:
-raise DottedName.InvalidDottedName(
-'Bad identifier %r' % (piece,))
+if not self._IDENTIFIER_RE.match(subpiece):
+#raise DottedName.InvalidDottedName(
+#'Bad identifier %r' % (piece,))
+log.warning(Identifier %r looks suspicious;
+using it anyway. % piece)
+self._ok_identifiers.add(piece)
self._identifiers.append(subpiece)
else:
raise TypeError('Bad identifier %r: expected '
signature.asc
Description: Digital signature
Bug#441368: Patch from upstream fix
Darn, I missed that. I was just looking at the diff from the previous
svn revision. I'll get this applied ASAP.
I'm looking forward to the 3.0 release. Have a good weekend!
KEN
On 9/30/07, Edward Loper [EMAIL PROTECTED] wrote:
Kenneth Pronovici wrote:
Attached is a patch from upstream's Subversion for this fix.
KEN
That svn patch had the following fix a few svn revisions later:
# Strip any existing anchor off:
-base_url = re.sub('#.*', '', base_url)
+base_url = re.sub('#.*', '', '%s' % (base_url,))
for term in parsed_docstring.index_terms():
-Edward
p.s., I hope to release epydoc 3.0 within the next week or two.
--
Kenneth J. Pronovici [EMAIL PROTECTED]
http://www.cedar-solutions.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403448: cedar-backup2-doc: a couple of typos
Hi, Thanks for the bug report and the patch. Interestingly, I just fixed the platfomr typo myself yesterday in the upstream source. I'll fix the other typo upstream too. Note: I won't upload a new Debian package just to fix these typos. Instead, the fixes will arrive in Debian with the next upstream release (probably soon after etch). If you have any other feedback on the documentation, feel free to file another Debian bug, write me directly, or discuss on the Cedar Backup mailing list (see cedar-solutions.com). KEN On 12/16/06, Dmitry Rutsky [EMAIL PROTECTED] wrote: Package: cedar-backup2-doc Version: 2.8.1-1 Severity: minor Tags: patch While reading the documentation for the first time, I've noticed a couple of spelling errors. See patch below: Index: manual/src/config.xml === --- manual/src/config.xml (revision 1009) +++ manual/src/config.xml (working copy) @@ -95,7 +95,7 @@ para The configuration instructions below have been generalized so they -should work well regardless of what platfomr you are running (i.e. +should work well regardless of what platform you are running (i.e. RedHat, Gentoo, FreeBSD, etc.). If instructions vary for a particular platform, you will find a note related to that platform. @@ -314,7 +314,7 @@ Dump a Python stack trace instead of swallowing exceptions. This forces Cedar Backup to dump the entire Python stack trace associated with an error, rather than - just progating last message it received back up to the + just propagating last message it received back up to the user interface. Under some circumstances, this is useful information to include along with a bug report. /para -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.1 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) -- no debconf information -- --- Dmitry Rutsky -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
On 12/17/06, Dmitry Rutsky [EMAIL PROTECTED] wrote: Package: cedar-backup2 Version: 2.8.1-1 Severity: wishlist Tags: patch ide-scsi is obsolete on 2.6 kernels, cdrecord (presently known as wodim in Debian by the way) can use recorders just like wodim dev=/dev/hdc ... and cannot (as far as I can see) use it the only way cedar-backup2 can use, unlesss ide-scsi is configured. To this end I've made the following trivial modifications which seem to fix the problem for me: [snip] Hi, I'll consider your patch. I'm open to allowing other ways to specify the writer device. However, I am not completely convinced (yet) that the right way to solve the problem is to make the SCSI id optional. I may instead provide some other way to flag the condition. Let me give it some thought and do some testing on my own. What kernel are you using -- a stock Debian one, or one you built yourself? If it's a stock Debian 2.6 kernel, that's great, because I should be able to reproduce your situation and do direct testing. Incidentally, the regression tests are likely failing now because you've caused a fundamental assumption to be broken, i.e. that every configuration has a SCSI device associated with it. Any changes like this ripple through the regression test suite, which is exactly what I want to happen. :) KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403662: cedar-backup2-doc: steps order in chapter 4
On 12/18/06, Dmitry Rutsky [EMAIL PROTECTED] wrote: Package: cedar-backup2-doc Version: 2.8.1-1 Severity: wishlist In the descriptions of typical configuration process in chapter 4, sections Setting up ..., there is step 5 in which suggests adding/enabling cron jobs. I think this step is too early: an administrator should first configure Cedar Backup, validate the configuration, test it, (steps 6 thru 8 or 9) and only then if everything works enable cron jobs. Yep, that's a reasonable suggestion. I'll work on moving around the steps. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
On 12/18/06, Dmitry Rutsky [EMAIL PROTECTED] wrote: It turns out that I'd overlooked relevant sections in the documentation (Linux Notes in Chapter 4) and there is (or at least was) a way to use ATAPI interface. Still it doesn't work for me, and What happens when you execute this? cdrecord -scanbus dev=ATAPI On my sarge system (using cdrecord, not wodim), this gives back the cd writer as one of the devices. Then, I configure Cedar Backup to use ATAPI:1,0,0 (or whatever) and it works. I gather that on your system using wodim, scanbus doesn't find anything? If that's true, I agree -- it's either a bug or a regression in wodim (perhaps that functionality was added after the point wodim was forked from). [snip] Consider the following as well: if there is more than one recorders on the system, it's perfectly clear which one you're referring to when you pass dev=/dev/cdrw where /dev/cdrw points to correct recorder device, rather than mysterious dev=ATAPI:0,1,0 for example. The first way makes much more sense. If it works, yes, I agree that specifying the device is much less ambiguous. Cedar Backup should support that syntax somehow. In an odd coincidence, someone else wrote the Cedar Backup user mailing list today with the same problem. So, that forces my hand and I'll have to make a decision soon about how I'll fix it. What kernel are you using -- a stock Debian one, or one you built yourself? If it's a stock Debian 2.6 kernel, that's great, because I should be able to reproduce your situation and do direct testing. I use a custom-built kernel. Tell me if you want the complete config for it or just relevant options and I'll send it to you. It may not matter. I recently transplanted my DVD writer into a different maching running etch (rather than sarge). If the problem is wodim-related, I should be able to reproduce it on that box. Even if I can't reproduce the problem, as long as I can test that passing dev=/dev/cdrw works properly with wodim, this should be good enough. Incidentally, the regression tests are likely failing now because you've caused a fundamental assumption to be broken, i.e. that every configuration has a SCSI device associated with it. Any changes like this ripple through the regression test suite, which is exactly what I want to happen. :) I also had broken the code --- if you set scsi_id tag it'll fail. I'm just not accustomed to interpreted languages. The following additional patch should make it work the way it did when the tag is present (though I didn't test it), and it reduces the number of failed unittests to only about a dozen. Ok, thanks. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
Hi Jörg, I do appreciate the bug feedback -- but since this is a Debian bug report, we have to deal with it in context of the packages available in Debian, meaning wodim. I realize this is probably not a situation you are happy with, and I do sympathize -- but the additional advertisements for cdrecord vs. wodim are really not useful as a part of this bug report. If you want to have a private conversation on this subject with Dmitry, I can certainly respect that. However, let's please keep the bug report discussion limited to things that I can actually fix in Debian. Thanks, KEN On 12/18/06, Joerg Schilling [EMAIL PROTECTED] wrote: It turns out that I'd overlooked relevant sections in the documentation (Linux Notes in Chapter 4) and there is (or at least was) a way to use ATAPI interface. Still it doesn't work for me, and (thanks to Joerg pointing that out to us) it can be seen as a minor bug in wodim --- because it says, albeit in somewhat nondeterminate language, in its manpage wodim (1) that Looks like you did not check the recent cdrtools.. libscg now maps ATAPI (SCSI over ATA) to SCSI bus numbers 1000 ... 1025 Have a look at the latest cdrtools at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Note that recent mkisofs versions (part of cdrtools) include libfind and thus allow you to use the find(1) command line syntax in the mkisofs command line and that mkisofs now for the first time has backup stability and allows to create 100% accurate copies (the first time in the existence of mkisofs). -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
On 12/18/06, Kenneth Pronovici [EMAIL PROTECTED] wrote: On 12/18/06, Dmitry Rutsky [EMAIL PROTECTED] wrote: It turns out that I'd overlooked relevant sections in the documentation (Linux Notes in Chapter 4) and there is (or at least was) a way to use ATAPI interface. Still it doesn't work for me, and What happens when you execute this? cdrecord -scanbus dev=ATAPI This is what I get on my development system (Debian etch, kernel 2.6.18-3-k7). when I run the various scanbus commands: # cdrecord -scanbus dev=ATA scsibus1: 1,0,0 100) 'LITE-ON ' 'DVDRW SOHW-1673S' 'JS02' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * # cdrecord -scanbus dev=ATAPI scsibus0: 0,0,0 0) 'LITE-ON ' 'DVDRW SOHW-1673S' 'JS02' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * Now, previously, I would have told you that this means you should use one of these SCSI ids: ATA:1,0,0 ATAPI:0,0,0 However, wodim doesn't support ATAPI, and says it's deprecated. # cdrecord -prcap dev=ATAPI:0,0,0 Warning, the ATAPI: method is considered deprecated on modern kernels! Mapping device specification to dev=0,0,0 now. To force the old ATAPI: method, replace ATAPI: with OLDATAPI: cdrecord: Invalid argument. Cannot open SCSI driver! For possible targets try 'wodim -scanbus'. For possible transport specifiers try 'wodim dev=help'. For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from the wodim documentation. Instead, you have to use OLDATAPI. I've checked, and I can successfully write a disk with either ATA:1,0,0 or OLDATAPI:0,0,0 on my development system. However, I/O gets a little screwy with OLDATAPI -- the system is kind of unresponsive -- and I'm not sure I can recommend using it. Anyway, this suggests one change in Cedar Backup, which is to loosen the regex around the SCSI parameter. That's probably a good general change so I don't need to release a new version of my software every time a new method needs to be supported. I've implemented it in upstream Subversion as of revision 1014. I'm going to dig a little further into your patch now and see what I can do about supporting dev=/dev/cdrom and the like. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
I'm going to dig a little further into your patch now and see what I can do about supporting dev=/dev/cdrom and the like. Upstream Subversion revision 1016 contains functionality equivalent to your patch. I made the target_scsi_id parameter optional, and added a hardwareId attribute on CdWriter to use for dev= when talking to cdrecord/wodim. The hardwareId will be scsiId if provided, and device otherwise. So, if you leave off target_scsi_id, device will be used both for cdrecord and for other filesystem operations (like mounting the media for the write validation step). I've tested the changes and they seem to work fine on my hardware. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395917: babygimp: doesn't work with current version of perl-tk
On 12/27/06, Gunnar Wolf [EMAIL PROTECTED] wrote: Hi, Any update on babygimp's status? If it no longer works and cannot be fixed, maybe the best course of action is to remove it from Etch? AFAIK, babygimp should already be removed from Etch per an email I sent earlier to the release team. I checked qa.debian.org (on my maintainer page) and no version of babygimp is currently listed in testing, so I think things are OK. I haven't had time to dig in and see what else can be easily done to fix the problem, and I have not received any other emails from interested parties. I will probably remove the package from Debian entirely sometime after etch is released. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404772: Please enhance run-parts to visually distinguish jobs in email
Package: cron Version: 3.0pl1-86 Severity: wishlist Hi, It's sometimes difficult to distinguish between output from the different jobs run as part of cron.daily. For instance, a recent email I received contained these lines: run-parts: /etc/cron.daily/bugzilla exited with return code 1 /etc/cron.daily/ntpdate: 27 Dec 06:29:18 ntpdate[26274]: step time server 128.105.37.11 offset -5.239138 sec /etc/cron.daily/register_dns: ez-ipupdate Version 3.0.11b8 . . . You'll notice that three different jobs were run in this example. However, because the output from all three scripts runs together, it's a little difficult to read the email. In this case, I missed the bugzilla error for a couple of days. It would be great if run-parts could visually distinguish between output from each job that is run. Possible options include a blank line between jobs, a ruler (, ) between jobs, or perhaps a ruler and start/stop timestamp around each job. Anything that would make it easier to diffentiate between output from two consecutive jobs would help me. Thanks! KEN -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages cron depends on: ii adduser 3.63 Add and remove users and groups ii debianutils 2.8.4 Miscellaneous utilities specific t ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libpam0g 0.76-22Pluggable Authentication Modules l -- no debconf information -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#412625: ftp.debian.org: Please remove babygimp from the archive
Package: ftp.debian.org Severity: normal Hi, Please remove the babygimp package from the archive. It doesn't work, upstream is dead and unresponsive, no one has stepped forward to fix any of the bugs with it, and I am really not interested in debugging nasty Perl-Tk incompatibilities. :) In the meantime, I will be orphaning the package. Thanks, KEN -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#412626: O: babygimp
Package: wnpp Severity: normal I am orphaning babygimp. It doesn't work, upstream is dead and unresponsive, no one has stepped forward to fix any of the bugs with it, and I am really not interested in debugging nasty Perl-Tk incompatibilities. :) I have also requested that babygimp be removed from the archive. If someone steps forward the claim the package (unlikely) then we can close the bug against ftp.debian.org. KEN -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#408261: pychecker: Redefining attribute (generator expression)
On Wed, Jan 24, 2007 at 10:25:07PM +0800, LI Daobing wrote: Package: pychecker Version: 0.8.17-3 Severity: normal warning on a well-defined python program $ cat bug.py def main(): ' '.join(str(x) for x in range(10)) ' '.join(str(x) for x in range(11)) $ pychecker bug.py Processing bug... Warnings... bug.py:3: Redefining attribute (generator expression) original line (2) Ok, thanks for the report. I'm going to flag this as upstream in the BTS. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#425193: epydoc: New upstream available (3.0beta1)
On 5/19/07, Cameron Dale [EMAIL PROTECTED] wrote: Package: epydoc Severity: normal Tags: patch There is a new upstream release available since February 2007 that has some interesting enhancements for epydoc. I know it's a beta release, but as there haven't been any releases in quite some time, I thought you might be interested. Yeah, I noticed it, but had mixed feelings about packaging a beta. I'll get in contact with upstream and see what they think about it. Thanks for the patch... I appreciate it. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425077: New dependencies
Eypdoc depends on the following utilities for its LaTeX functionality: /usr/bin/latex /usr/bin/makeindex /usr/bin/dvips /usr/bin/ps2pdf The following packages provide these dependencies: texlive-latex-base: /usr/bin/latex texlive-base-bin: /usr/bin/makeindex, /usr/bin/dvips gs-common: /usr/bin/ps2pdf If you follow the dependency chain back far enough, texlive-latex-base depends on texlive-base-bin, so that gives us this new Recommends line: texlive-latex-base, gs-common, python-tk KEN -- Kenneth J. Pronovici [EMAIL PROTECTED]
Bug#425193: epydoc: New upstream available (3.0beta1)
I also had to use a weird version number (2.1+3.0beta1) so that later upgrades to 3.0 will be automatic. Incidentally, there's no need for weird version numbers like this. Version numbers now support ~ to cover exactly this circumstance. See: http://lwn.net/Articles/194664/ A version number which contains ~ is always less than one which doesn't. So, we can do the natural thing and release packages with versions like this: 3.0~beta1-1 3.0~beta1-2 3.0~beta2-1 3.0~beta2-2 3.0~beta2-3 . . . 3.0-1 I had to prove it to myself, but it does work as expected: # dpkg --compare-versions 3.0~beta1-1 lt 3.0-1 echo true || echo false true Also, I have written Ed to see how he feels about packaging 3.0 beta 1. When I hear back, I'll let you know. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
