Bug#666354: sopwith: FTBFS: make[1]: *** No targets specified and no makefile found. Stop.
On Fri, Mar 30, 2012 at 4:29 AM, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Source: sopwith Version: 1.7.4-5 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120330 qa-ftbfs qa-ftbfs-buildarch Justification: FTBFS on amd64 Ok, looks like I can fix this by moving configure from build to build-stamp. I'll upload shortly. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649697: python-epydoc: Please Recommend ghostscript instead of gs-common
On Wed, Nov 23, 2011 at 4:34 AM, Didier Raboud o...@debian.org wrote: Package: python-epydoc Version: 3.0.1-1 Severity: important Hi, python-epydoc currently recommends gs-common, which is a transitional package. The next upload of ghostscript (currently) plans to drop both gs-common and the ghostscript Provides: gs-common. As soon as that upload happens, it will make python-epydoc have broken recommends. Please replace the Recommends on gs-common to a Recommends on ghostscript. Is it OK for me to change the Recommends immediately, or do I have to wait for the new ghostscript package? When will that package be uploaded? KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648426: pychecker: getStandardLibraries() checks for site-packages in path, but not dist-packages
On Fri, Nov 11, 2011 at 7:57 AM, Nigel Evans nigelev...@postmaster.co.uk wrote: Package: pychecker Version: 0.8.18-7 Severity: normal Tags: patch When using the -q / --stdlib option, the method getStandardLibraries() in warn.py gets library names from site-packages, but not the new location for them, which is dist-packages. This means errors from these packages are not ignored as they should be. Hmm. From the limited digging I've done so far, it looks like the practice of installing standard libraries in dist-packages is Debian-specific. If that's the case, I guess we should be fixing it in a Debian-specific patch rather than as an upstream bug. I'll see if I can come up with something workable. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648426: pychecker: getStandardLibraries() checks for site-packages in path, but not dist-packages
Sorry, I missed that a patch was available. It looks reasonable to me. I'll apply it sometime soon and upload a new package. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647833: Pychecker enhancement requests
Hi Guido, I'm responding here to both bug #647833 and #647834. I don't envision implementing changes like these in the Debian package for pychecker. These really are enhancement requests for upstream, and they don't have anything to do with how the Debian package is utilized. The binary Debian package doesn't even include setup.py. I can (and do) submit bug reports to SourceForge for actual bugs reported by Debian users, but I would prefer not to be the owner for enhancement requests like this. I think it works better if the SourceForge bug is owned by the person actually making the enhancement request. Would you be willing to submit (and own) a bug report on SourceForge for these enhancement requests? If you do that, then I will tie the Debian bug reports to the SourceForge bug reports, and we can continue to track them here. If not, I would prefer to close these Debian bug reports. Please let me know. Thanks, KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627449: Internal error when parsing assignment to a slice of a list
On Fri, May 20, 2011 at 12:42 PM, Peter Slickers pe...@web.de wrote: Package: pychecker Version: 0.8.19-2 pychecker Version 0.8.19 crashes with an INTERNAL ERROR if it encounters a python statements where an assignment to a slice of a list is done. Hi, Thanks for the bug report. I'll file this upstream. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614570: python-epydoc: LaTeX documentation with epydoc fails because of missing fontenc package
Hi Mike,
On Tue, Feb 22, 2011 at 5:03 AM, Mike Gabriel
mike.gabr...@das-netzwerkteam.de wrote:
mike@minobo:/usr/share/pyshared/epydoc/docwriter$ diff -ur latex.py.orig
latex.py
--- latex.py.orig 2011-02-22 11:57:33.0 +0100
+++ latex.py 2011-02-22 11:55:00.0 +0100
@@ -29,6 +29,7 @@
\\documentclass{article},
\\usepackage{alltt, parskip, fancyhdr, boxedminipage},
\\usepackage{makeidx, multirow, longtable, tocbibind, amssymb},
+ \\usepackage[T1]{fontenc},
\\usepackage{fullpage},
\\usepackage[usenames]{color},
# Fix the heading position -- without this, the headings generated
I've got a package built with this patch applied, and I'll upload in a
little while. I will also upload my final patch to SourceForge, in
case upstream or one of the other distributions wants to integrate it.
In testing with PostScript and PDF output, I found that this change
caused a HUGE slowdown (i.e. divps took on the order of minutes to
render the output). Something (not sure which step) also crashed once
when generating PDF output, although I couldn't reproduce that
behavior.
After digging around, I decided to add \usepackage{lmodern} in
addition to \usepackage[T1]{fontenc}. This seems to resolve the
problems I was seeing, and the output appears legible for the formats
I can easily check (i.e. PDF). When the new package hits the
archive, please confirm that I haven't caused any problems for your
scenario.
Thanks,
KEN
--
Kenneth J. Pronovici prono...@ieee.org
http://www.cedar-solutions.com/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614570: python-epydoc: LaTeX documentation with epydoc fails because of missing fontenc package
Ok, thanks for the patch. I will look at integrating it in not too long. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611288: pychecker: false positive Function (__import__) doesn't support **kwArgs
On Thu, Jan 27, 2011 at 12:07 PM, Jakub Wilk jw...@debian.org wrote: Package: pychecker Version: 0.8.19-2 Severity: minor The __import__ function has been accepting keyword arguments since Python 2.5. However, pychecker warns that it does not: Ok, I've forwarded it upstream as SF issue #3166857. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609438: pychecker: incompatible with Python 2.7: IndexError: tuple index out of range
Hi Jakub, I have a new pychecker package put together, but I am going to have to wait before uploading. The upstream 0.8.19 release removes the pychecker2 package, which SPE depends on. I don't want my upload to break SPE, so I need to wait and see whether Thomas is willing to put this code back in his upstream distribution. Also, I only see python2.7 in experimental right now. I do not currently have a spare environment or chroot to devote to experimental, so I won't be able to test 0.8.19 with python 2.7. I'll have to rely on you to let me know if my new package has solved your problem. (Are you really running experimental, or are you using the Debian package through Ubuntu or something?) KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609438: pychecker: incompatible with Python 2.7: IndexError: tuple index out of range
According to upstream, pychecker 0.8.19 is compatible with Python 2.7 and indeed I cannot see this traceback with this version anymore. Ok. 0.8.19 has only been out for a day or so. I'm planning to upload soon. KEN
Bug#608153: Fails to detect dictionaries
On Mon, Dec 27, 2010 at 4:41 PM, Kenneth Pronovici prono...@debian.org wrote: Seems pychecker has a hard time finding out that 'l' is a dictionary in the first case. Hmm. Might be a Python 2.6 issue? I'll report it upstream. It turns out that a similar bug was filed upstream about a year ago. The warning is about a different method, but it looks like the same problem (i.e. that dict() is not recognized the same way as a literal dictionary): https://sourceforge.net/tracker/index.php?func=detailaid=2891832group_id=24686atid=382217 I've updated the SourceForge bug report to reference this Debian bug report. KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608153: Fails to detect dictionaries
Seems pychecker has a hard time finding out that 'l' is a dictionary in the first case. Hmm. Might be a Python 2.6 issue? I'll report it upstream. Thanks, KEN
Bug#188298: Oil tank explosions
On Mon, Sep 6, 2010 at 4:07 PM, Kenneth Pronovici prono...@ieee.org wrote: On Mon, Sep 6, 2010 at 10:44 AM, Jesse Smith jessefrgsm...@yahoo.ca wrote: The oil tank explosions should now be a little more intense than before. They have larger explosions than the other buildings. This is as of Sopwith 1.7.4. I think we can close this bug now. Ok, I will mark this bug as closed when I upload 1.7.4-1 (probably sometime next week). I uploaded a few minutes ago. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#188298: Oil tank explosions
On Mon, Sep 6, 2010 at 10:44 AM, Jesse Smith jessefrgsm...@yahoo.ca wrote: The oil tank explosions should now be a little more intense than before. They have larger explosions than the other buildings. This is as of Sopwith 1.7.4. I think we can close this bug now. Ok, I will mark this bug as closed when I upload 1.7.4-1 (probably sometime next week). KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594537: pychecker: Seems to ignore command line option -q/--stdlib
This bug is now tracked in the upstream bug tracker: https://sourceforge.net/tracker/?func=detailaid=3058916group_id=24686atid=382217 I thought it was there previously, but I couldn't find anything quite like it in the list. So, I added a new bug report. KEN
Bug#594537: pychecker: Seems to ignore command line option -q/--stdlib
On Thu, Aug 26, 2010 at 3:21 PM, W. Martin Borgert deba...@debian.org wrote: For automatically testing Python code in a CI test, it is useful to ignore any errors or problems in Python itself. If I understand correctly, with -q or --stdlib pychecker should ignore warnings from files under standard library. However, I get the following errors with or without -q: /usr/lib/python2.6/threading.py:66: (format) shadows builtin /usr/lib/python2.6/threading.py:68: (format) shadows builtin I agree that this is kind of a pain. I'm fairly sure this is already in the upstream bug tracker on SourceForge. I'll confirm this, and if not I'll enter a new bug and tie it to this one. Upstream is more-or-less dead right now. Most bugs and/or mailing list questions go unanswered, so it probably won't get fixed soon... unless I can come up with a fix myself or unless someone else submits a patch. I recall looking at it a while ago, but I don't think there was an easy answer. Sorry about that. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590112: Epydoc fails to parse comment-based docstrings with Python 2.6
Ok, I uploaded 3.0.1-8 including the patch. If you have a few minutes, please confirm that the new patched package is working for you. Thanks, KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590112: Epydoc fails to parse comment-based docstrings with Python 2.6
On Fri, Jul 23, 2010 at 2:08 PM, Iustin Pop iu...@k1024.org wrote: There's a known bug with epydoc and python 2.6 (the tokenizer has changed in 2.6, and epydoc hasn't been updated to account for it). While upstream seems dormant, a patch is available on the sourceforce tracker, see https://sourceforge.net/tracker/index.php?func=detailaid=2585292group_id=32455atid=405618. It would be good if you can import this patch in Debian, so that epydoc works again :) I'll take a look at the patch. Do you have a test case (some example code) that I can use to prove that the patched code is working? Or is the snippet of code in the upstream bug report a good enough example? KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#188298: Debian bug #188298 -- still interested?
Hi Hamish, I've taken over the Debian packages for Sopwith, and I've been working my way through the bug list. As of right now, the only open bug is yours, from way back in 2003: #188298: oil tanks should blow big Are you still interested in having this bug fixed? If so, I will tie this Debian bug to a new issue in the Sourceforge bug tracker. If not, I would like to close the Debian bug report. Can you please let me know what you would prefer? Thanks, KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#577070: Debian Pychecker bug #577070
Hi Jakub, Sorry to be replying to this bug so late. I thought I had already done so months ago, but realized I hadn't when I was reviewing the open bugs in all of my packages. This is an upstream bug, and upstream isn't very active right now. I'll enter a SourceForge issue and tie it to this bug, but I admit I'm not optimistic that it will be fixed any time soon. KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#577070: Filed with SourceForge
This has been filed as SourceForge issue #3025876: https://sourceforge.net/tracker/?func=detailaid=3025876group_id=24686atid=382217 KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#188298: Debian bug #188298 -- still interested?
Update: Jesse (the new upstream maintainer) told me a few minutes ago that this enhancement is on his list. So, let's keep the bug open. I added a new SourceForge issue to track it, and I'll tag the bug as upstream in a few minutes here. https://sourceforge.net/tracker/?func=detailaid=3025934group_id=74021atid=539698 https://sourceforge.net/tracker/?func=detailaid=3025934group_id=74021atid=539698 KEN
Bug#472738: Taking over sopwith
I'm planning to take over this package. KEN -- Kenneth J. Pronovici prono...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#175202: debian-policy: [PROPOSAL] Clarify Perl package naming convention with more examples
On Mon, Jun 28, 2010 at 12:55 PM, Russ Allbery r...@debian.org wrote: Many years later, I'm now applying the following patch to Policy for the next release, which spells out the existing naming convention more explicitly. Thanks! Thanks! I appreciate the follow-up. After I saw your 3.9.0.0 policy update email, I made a note to go looking for this bug... and you beat me to it. :) KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#192863: Can we close Debian gtml bug 192863?
Hi Dan, GTML has been orphaned for a while. Since I still use it actively, I've decided to take it over. Bug 192663 has been open since 11 May 2003, with no other comments in it. The last activity was when you changed your submitter address in July of 2003. Does this bug still need to be open? Thanks, KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#192864: Can we close Debian gtml bug 192864?
Hi Dan, I guess you're getting two emails from me today. For the sake of the bug report, I'll repeat myself. :) GTML has been orphaned for a while. Since I still use it actively, I've decided to take it over. Bug 192664 has been open since 11 May 2003, with no other comments in it. The last activity was when you changed your submitter address in July of 2003. There hasn't been an upstream release of GTML since October of 2004, so it seems unlikely that there will be one to address the whitespace problem you reported . Is it important enough to you to keep the Debian bug open, or can we close it? Thanks, KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#192864: Fwd: Can we close Debian gtml bug 192864?
Hi Dan, I guess you're getting two emails from me today. For the sake of the bug report, I'll repeat myself. :) GTML has been orphaned for a while. Since I still use it actively, I've decided to take it over. Bug 192664 has been open since 11 May 2003, with no other comments in it. The last activity was when you changed your submitter address in July of 2003. There hasn't been an upstream release of GTML since October of 2004, so it seems unlikely that there will be one to address the whitespace problem you reported . Is it important enough to you to keep the Debian bug open, or can we close it? Thanks, KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#547982: Taking over gtml
I'm planning to take over this package. KEN -- Kenneth J. Pronovici prono...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563304: Submitted to SourceForge
This bug has been submitted to SF as bug #2929446: https://sourceforge.net/tracker/?func=detailaid=2929446group_id=210468atid=1013862 KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563445: Submitted to SourceForge
This bug has been submitted to SourceForge as bug #2929447: https://sourceforge.net/tracker/?func=detailaid=2929447group_id=210468atid=1013862 KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563445: Fixed
Ok, this turned out to just be stupidity on my part. I was printing the message at the bottom of the loop rather than the top. It will be in 2.19.5-1, which I'll hopefully upload later tonight. KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563304: Fixed
I have added retry logic to the write process, and it seems to work the way I would expect. Try it out, and if it doesn't meet your needs let me know. I only tested with the CD writer, but since I didnt modify anything about the write itself, only the error handling around it, I don't anticipate any problems for DVDs. This will be in 2.19.5-1, which I hope to upload later tonight. KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563304: Fixed
Sure, that's fine. The main question is whether it does what you want, but I think it matches up pretty well with your request. KEN On Sun, Jan 10, 2010 at 7:50 PM, Jan Medlock medl...@clemson.edu wrote: On Sunday 10 January 2010 05:58:21 pm Kenneth Pronovici wrote: I have added retry logic to the write process, and it seems to work the way I would expect. Try it out, and if it doesn't meet your needs let me know. I only tested with the CD writer, but since I didnt modify anything about the write itself, only the error handling around it, I don't anticipate any problems for DVDs. This will be in 2.19.5-1, which I hope to upload later tonight. KEN Thanks, Ken! Do you mind waiting until my monthly backup on 1 Feb for my test report? Jan -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563304: cedar-backup2: Often fails to mount during consistency check
Hi Jan, Thanks for the bug report. Sorry that you're seeing problems writing the disk... I haven't heard of that happening before. I will look at these enhancements when I find a little time. Would you be willing to submit this bug at SourceForge? That's usually where I track bug reports that are not specific to Debian. If not, i.e. if you don't have a SF login, that's fine... I can do it myself. It's better for you to own the bug, since it's your request. Thanks, KEN On Fri, Jan 1, 2010 at 2:37 PM, Jan Medlock medlock-deb...@turboshower.netwrote: Package: cedar-backup2 Version: 2.19.4-2 Severity: wishlist First, thanks for writing and maintaining cedar-backup2. I have found it very useful for regular backups. I use cback-span regularly and often have failures in either starting writing the disk or in mounting the disk for the consistency check. In both cases, I believe the failure is just due to the drive not settling quickly enough. These failures necessitate restarting the whole process and burning a whole new set of disks, which can be wasteful of both time and DVD+R's if I'm on one of the last disks of a big backup. I request new features to catch these failures and allow retrying of the events. In particular, 1. If the writing fails (for any reason, not just failure to start writing), the option of restarting the write should be given. (This would allow the user to insert a new medium, if necessary.) 2. If the consistency check fails (again, for any reason), allow the user to either, A. Re-run the consistency check, or B. Re-write the disk (again, possibly with a new medium). Thanks again, Jan Medlock -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cedar-backup2 depends on: ii python2.5.4-5An interactive high-level object-o ii python-support1.0.6 automated rebuilding support for P Versions of packages cedar-backup2 recommends: pn cdrecordnone (no description available) ii cedar-backup2-d 2.19.4-2 local and remote backups to CD or ii dvd+rw-tools7.1-6DVD+-RW/R tools ii eject 2.1.5+deb1+cvs20081104-7 ejects CDs and operates CD-Changer pn mkisofs none (no description available) pn ssh none (no description available) Versions of packages cedar-backup2 suggests: ii gnupg 1.4.10-2 GNU privacy guard - a free PGP rep pn grepmail none (no description available) ii mysql-client-5.1 [mysql-clien 5.1.41-3 MySQL database client binaries pn postgresql-client none (no description available) pn subversionnone (no description available) -- no debconf information -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#563445: cedar-backup2: cback-span asks for new medium after the final one is finshed
Hi Jan, Yeah, that sounds like a glitch. cback-span shouldn't ask the last time... there's no point. Would you be willing to submit this bug at SourceForge, along with the other one? Thanks, KEN On Sat, Jan 2, 2010 at 6:13 PM, Jan Medlock medlock-deb...@turboshower.netwrote: Package: cedar-backup2 Version: 2.19.4-2 Severity: minor Again, thanks for the nice software and its maintenance. cback-span asks for a new medium after the final medium has been burned. After responding to this prompt, the program exists since the burning is done. cback-span should not ask for a new medium after the final one has been burned. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cedar-backup2 depends on: ii python2.5.4-5An interactive high-level object-o ii python-support1.0.6 automated rebuilding support for P Versions of packages cedar-backup2 recommends: pn cdrecordnone (no description available) ii cedar-backup2-d 2.19.4-2 local and remote backups to CD or ii dvd+rw-tools7.1-6DVD+-RW/R tools ii eject 2.1.5+deb1+cvs20081104-7 ejects CDs and operates CD-Changer pn mkisofs none (no description available) pn ssh none (no description available) Versions of packages cedar-backup2 suggests: ii gnupg 1.4.10-2 GNU privacy guard - a free PGP rep pn grepmail none (no description available) ii mysql-client-5.1 [mysql-clien 5.1.41-3 MySQL database client binaries pn postgresql-client none (no description available) pn subversionnone (no description available) -- no debconf information -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#561793: Epydoc patch (Debian bug #561793)
Thomas,
Ok, I have finally had time to review your patch and test it. Sorry this
took me a while.
This bug is now linked with 560624, 560659 and 560606, which are FTBFS bugs
for python-couchdb, dbus-python and pymvpa. I was able to reproduce the
build problems with those packages using python-epydoc 3.0.1-3 and
python-docutils 0.6-2 (both from unstable).
After applying your patch, the build problems went away for python-couchdb
and dbus-python. The pymvpa build exposed one other piece of code where a
.data element is referenced, so I made a similar change there. (A new
patch is attached.)
I can't confirm that the documentation looks exactly correct in each of the
packages I tested, but I spot-checked it and it does look reasonable.
I haven't heard back from Edward (upstream), so that leaves it up to me.
The patch shouldn't have any impact on behavior except when the .data
attribute is missing, so it feels fairly safe. I tend to think the result
with the patch in place is much better than just blowing up.So, I am
going to apply it for Debian version 3.0.1-4, which I will upload later
tonite. I will also update the SF bug to reference this Debian bug (and the
patch), in case Edward wants to put into the upstream release.
To the other Debian maintainers: please let me know if you see any problems
with the documentation that has been generated for your packages. I can
always fall this change back if needed.
Thanks,
KEN
--
Kenneth J. Pronovici prono...@ieee.org
http://www.cedar-solutions.com/
Index: epydoc/markup/restructuredtext.py
===
RCS file: /opt/public/cvs/debian/epydoc/epydoc/markup/restructuredtext.py,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 restructuredtext.py
--- epydoc/markup/restructuredtext.py 28 Jan 2008 18:15:33 - 1.1.1.4
+++ epydoc/markup/restructuredtext.py 31 Dec 2009 04:28:30 -
@@ -304,13 +304,14 @@
# Extract the first sentence.
for child in node:
if isinstance(child, docutils.nodes.Text):
-m = self._SUMMARY_RE.match(child.data)
-if m:
-summary_pieces.append(docutils.nodes.Text(m.group(1)))
-other = child.data[m.end():]
-if other and not other.isspace():
-self.other_docs = True
-break
+if hasattr(child, 'data'):
+m = self._SUMMARY_RE.match(child.data)
+if m:
+summary_pieces.append(docutils.nodes.Text(m.group(1)))
+other = child.data[m.end():]
+if other and not other.isspace():
+self.other_docs = True
+break
summary_pieces.append(child)
summary_doc = self.document.copy() # shallow copy
@@ -489,10 +490,11 @@
if (len(fbody[0]) 0 and
isinstance(fbody[0][0], docutils.nodes.Text)):
child = fbody[0][0]
-if child.data[:1] in ':-':
-child.data = child.data[1:].lstrip()
-elif child.data[:2] in (' -', ' :'):
-child.data = child.data[2:].lstrip()
+if hasattr(child, 'data'):
+if child.data[:1] in ':-':
+child.data = child.data[1:].lstrip()
+elif child.data[:2] in (' -', ' :'):
+child.data = child.data[2:].lstrip()
# Wrap the field body, and add a new field
self._add_field(tagname, arg, fbody)
Bug#561793: Testing and patch as attachement
Don't worry about the unit tests for now. It's been a while since I looked at this code, and I thought I recalled a unit test suite that I was running as part of the package build process. I was thinking of pychecker instead. KEN
Bug#561793: I've made a Patch
Hi, I haven't had time to look at this yet, and I might not have time until after the holidays due to work schedule and travel. Sorry about that. I have pinged Edward (upstream) to see whether I can get some feedback from him before I consider applying the patch. I don't have a a problem applying your patch if we don't hear from Edward, but I'd like to get his blessing if possible, since this parsing code is fairly complex. Couple of quick questions: 1. Does the existing unit test suite pass or fail with Docutils 0.6? If not, have you been able to develop any tests that we could add to the suite to demonstrate the problem? 2. Does the existing unit test suite pass or fail with your patches in place? What testing have you been doing to check for possible bugs (the ones you mention above)? Thanks, KEN
Bug#561793: Upstream bug report
Ok, thanks for filing the bug. I would be happy to apply a patch if one becomes available. KEN -- Kenneth J. Pronovici prono...@ieee.org http://www.cedar-solutions.com/
Bug#556282: cedar-backup2: installs testutil.py (which is not meant to be installed)
Hmm. Good point. I wrote that comment myself, and then proceeded to put
the file in the distribution anyway. :)
I should probably just try to exclude that file from being installed via
setup.py. I'll take a look and see if I can figure out how to make that
happen.
KEN
On Sun, Nov 15, 2009 at 3:41 AM, Jakub Wilk uba...@users.sf.net wrote:
Package: cedar-backup2
Version: 2.19.4-1
Severity: minor
$ grep -B1 -A7 'publicly' /usr/share/pyshared/CedarBackup2/testutil.py
These utilities are kept here, separate from util.py, because they provide
common functionality that I do not want exported publicly once Cedar
Backup
is installed on a system. They are only used for unit testing, and are
only
useful within the source tree.
Many of these functions are in here because they are good enough for unit
test work but are not robust enough to be real public functions. Others
(like
L{removedir}) do what they are supposed to, but I don't want responsibility
for
making them available to others.
--
Jakub Wilk
Bug#506756: python-epydoc: Suggest python-profiler needed for call-graphs
On Mon, Nov 24, 2008 at 8:36 AM, Christoph Burgmer [EMAIL PROTECTED] wrote: Package: python-epydoc Version: 3.0.1-1 Severity: normal Please suggest (or whatever is appropriate) Debian package python-profiler which includes module pstats needed for building call-graphs. The package is in non-free/python. Ok, I will go ahead and do this. My read of policy is that it can be Suggests but not Recommends per policy 2.2.1. It might be a little while before I get to this. Let me know if that will be a problem. 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#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#487096: false warnings on except
There hasn't been an upstream release in quite a while, although there were a number of checkins recently, so the project is semi-active. I'll ping upstream and see what they 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#487162: probably false warning about missing argument to map()
OK, I'll pass this along upstream. KEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477032: pychecker: FTBFS: Failed test(s): test3 test17 test22 test34 test48 test53 test71 test77 test87 test88
On Sun, Apr 20, 2008 at 10:43 AM, Lucas Nussbaum [EMAIL PROTECTED] wrote: Package: pychecker Version: 0.8.17-8 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080419 qa-ftbfs Justification: FTBFS on i386 During a rebuild of all packages in sid, your package failed to build on i386. It looks like this has to do with the upgrade to Python 2.5, rather than the GCC transition. The tests pass for Python 2.5, but the expected results are slightly different. I'll tweak the package and get a new version uploaded soon (perhaps today, otherwise early this week). 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#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#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#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#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#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#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#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#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#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#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#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#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#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: 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#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#433804: epydoc: inaccurate documentation: -u is no longer supported
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. 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#425193: epydoc: New upstream available (3.0beta1)
On 5/27/07, Kenneth Pronovici [EMAIL PROTECTED] wrote: 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. I never heard back from Edward, unfortunately. Since the beta seems to work fine (mostly) for my existing test cases, I decided to upload it without any explicit approval from him. Sorry for the delay. I had wanted to give Edward as much time as possible to reply, and then I got a bit swamped with other things. 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
Bug#425077: closed by [EMAIL PROTECTED] (Kenneth J. Pronovici) (Bug#425077: fixed in epydoc 2.1-12)
On 6/3/07, Cameron Dale [EMAIL PROTECTED] wrote: On 6/3/07, Debian Bug Tracking System [EMAIL PROTECTED] wrote: Changes: epydoc (2.1-12) unstable; urgency=low . * Bring Recommends dependencies up to date with lenny (closes: #425077). - Recommend texlive-latex-base rather than obsolete tetex-extra - Recommend gs-common rather than gs-esp | gs, since this is where ps2pdf lives - Recommend iceweasel | www-browser rather than mozilla | www-browser Not to nitpick, but isn't texlive-latex-extra required for the Latex output? It seems like it uses the multirow and tocbibind packages, both of which are found in texlive-latex-extra. Epydoc claims that it only needs four programs: latex makeindex dvips ps2pdf As near as I can tell, the packages now Recommended satisfy those requirements -- unless I've completely misunderstood something. Sorry if I'm wrong here, I don't use the latex output, I just recall checking when I built my package and deciding that texlive-latex-extra was needed. I don't use the latex output much either. I'm certainly open to listing texlive-latex-extra rather than just texlive-latex-base, as long as I can understand why it would be required. I'll do some more testing and see what I can come up with. 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: closed by [EMAIL PROTECTED] (Kenneth J. Pronovici) (Bug#425077: fixed in epydoc 2.1-12)
On 6/3/07, Cameron Dale [EMAIL PROTECTED] wrote:
On 6/3/07, Kenneth Pronovici [EMAIL PROTECTED] wrote:
I don't use the latex output much either. I'm certainly open to
listing texlive-latex-extra rather than just texlive-latex-base, as
long as I can understand why it would be required. I'll do some more
testing and see what I can come up with.
From epydoc/latex.py (line 63):
\usepackage{makeidx, multirow, longtable, tocbibind, amssymb}
I assume that will fail if the packages are unavailable. Again, I
haven't tried it, but I assume you're testing will find an error
there.
Aargh! I see it now. Sorry, that was stupidity on my part.
I definitely need texlive-latex-extra, but it's worse than that. The
new texlive infrastructure isn't quite a true superset of tetex, so I
also had to patch latex.py to remove references to the fancyheader
package, which isn't available in texlive at all.
After these changes, things seem to work fine, and I'll upload a new
package shortly.
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: closed by [EMAIL PROTECTED] (Kenneth J. Pronovici) (Bug#425077: fixed in epydoc 2.1-12)
On 6/3/07, Kenneth Pronovici [EMAIL PROTECTED] wrote: I definitely need texlive-latex-extra, but it's worse than that. The new texlive infrastructure isn't quite a true superset of tetex, so I also had to patch latex.py to remove references to the fancyheader package, which isn't available in texlive at all. I fixed this; apparently, an alternate package fancyhdr exists in texlive. After these changes, things seem to work fine, and I'll upload a new package shortly. One more note: I had to add a few extra texlive dependencies to the list. The total list is now: gs-common python-tk texlive-latex-base texlive-latex-extra texlive-latex-recommended texlive-fonts-recommended I found that without the two -recommended packages, I would end up with a mixed texlive and tetex system. Adding those two packages resolved all of aptitude's confusion. If, when you upgrade to this new version, you see any dependency-related problems, please let me know. It seems to be working for me right now. Thanks for 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#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: python-epydoc: recommends obsolete tetex-extra
On 5/18/07, Cameron Dale [EMAIL PROTECTED] wrote: Package: python-epydoc Version: 2.1-11 Severity: normal Epydoc recommends the now obsolete tetex-extra. Perhaps this could be updated to recommend some new texlive packages (such as texlive-latex-extra). I am unwilling to install tetex-extra as the transitional package currently depends on 20 langauge packs I don't need. Ok, I'll take a look and see what texlive packages would make the most sense. 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#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#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#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#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#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#395918: babygimp: apparently doesn't work with current version of perl-tk
Package: babygimp
Version: 0.42-1
Severity: grave
Justification: renders package unusable
I heard about this in private email from a user a month or so ago. I
realized today while fixing #395577 that this user never bothered to
file an official bug report as requested (I was out of the country at
the time I received the email).
It doesn't look like babygimp works with the current version of perl-tk
(804.027 as of this writing).
Name Load::VAR1 used only once: possible typo at /usr/bin/babygimp
line 6874.
Scanning plugins ... loading 0 plugins ... done
Can't coerce CODE to string in entersub at /usr/lib/perl5/Tk/Widget.pm
line 190.
at /usr/bin/babygimp line 575
at /usr/lib/perl5/Tk/Widget.pm line 191
Tk::Widget::new('Tk::Radiobutton', 'Tk::Frame=HASH(0x8892a98)',
'-text', 'Erase', '-value', 'CODE(0x84fe8ec)', '-pady', 0, '-variable',
...) called at /usr/lib/perl5/Tk/Widget.pm line 256
Tk::Widget::__ANON__('Tk::Frame=HASH(0x8892a98)', '-text',
'Erase', '-value', 'CODE(0x84fe8ec)', '-pady', 0, '-variable',
'REF(0x84ed594)', ...) called at /usr/bin/babygimp line 575
at /usr/bin/babygimp line 575
This sort of error occurs for most of the rest of the similar lines
around line 575 (i.e. commenting out this line doesn't make a
difference).
I've already written upstream (Christian) to see if he can fix it any
time soon. I guess if he can't, I'll request that babygimp be removed
from Debian.
KEN
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-k7
Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to
en_US)
Versions of packages babygimp depends on:
ii perl 5.8.8-6.1 Larry Wall's Practical Extraction
ii perl-modules 5.8.8-6.1 Core Perl modules
ii perl-tk 1:804.027-6 Perl module providing the Tk graph
babygimp recommends no packages.
-- no debconf information
--
Kenneth J. Pronovici [EMAIL PROTECTED]
pgp5LRqkFz2tO.pgp
Description: PGP signature
Bug#395917: babygimp doesn't start
Odd, I filed the same bug just minutes before you did. I'll mark this
one as a duplicate.
Yeah, I agree, it does look like a perl-tk incompatibility.
Thanks for the report.
KEN
On 10/28/06, Wolfgang Karall [EMAIL PROTECTED] wrote:
Package: babygimp
Version: 0.42-1
Severity: grave
Justification: renders package unusable
Hello,
suddenly in need of an icon editor, I installed babygimp, but when
trying to start it I only get:
[EMAIL PROTECTED]:~ $ babygimp
Name Load::VAR1 used only once: possible typo at /usr/bin/babygimp
line 6874.
Scanning plugins ... loading 0 plugins ... done
Can't coerce CODE to string in entersub at /usr/lib/perl5/Tk/Widget.pm
line 190.
at /usr/bin/babygimp line 575
at /usr/lib/perl5/Tk/Widget.pm line 191
Tk::Widget::new('Tk::Radiobutton', 'Tk::Frame=HASH(0x88782f0)',
'-text', 'Erase', '-value', 'CODE(0x84f06fc)', '-pady', 0, '-variable', ...)
called at /usr/lib/perl5/Tk/Widget.pm line 256
Tk::Widget::__ANON__('Tk::Frame=HASH(0x88782f0)', '-text', 'Erase',
'-value', 'CODE(0x84f06fc)', '-pady', 0, '-variable', 'REF(0x84ecd14)', ...)
called at /usr/bin/babygimp line 575
at /usr/bin/babygimp line 575
[EMAIL PROTECTED]:~ $
Guess it's some incompatibility with newer versions of perl-tk, since
it's still working on Sarge systems.
Kind regards
WK
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages babygimp depends on:
ii perl 5.8.8-6.1 Larry Wall's Practical Extraction
ii perl-modules 5.8.8-6.1 Core Perl modules
ii perl-tk 1:804.027-7 Perl module providing the Tk graph
babygimp recommends no packages.
-- no debconf information
--
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]
