Bug#1071482: compress.1: some remarks and editorial changes for this man page
On Sun, May 19, 2024 at 8:51 PM Bjarni Ingi Gislason wrote: > Dear Maintainer, > > here are some notes and editorial fixes for the manual. > > The patch is in the attachment. I'll upload 5.0-2 containing these changes later today. For future reference, this patch would have been easier to deal with if it was against the upstream compress.1 (the version in the Git codebase on salsa) instead of against the installed compress.1 file that is part of the .deb package. The patch only applies cleanly if uncompress-real.patch has already been applied, which was fairly confusing until I figured out what was going on. Thanks for the improvements. KEN
Bug#1017755: New package version
Thanks! Yes, that clarifies things. I appreciate the background. I'll put this on my list. I'm not exactly sure when I'll get to it, but hopefully sometime in the next few weeks. We're still well within the development window for bookworm (the first freeze is in early 2023), so I don't envision any problem getting this package through testing and into that release. KEN -- Kenneth J. Pronovici
Bug#1017755: New package version
On Fri, Aug 19, 2022 at 3:39 PM Simon Howard wrote: > > Package: sopwith > Version: 1.8.4-18 > > A new version of this package, 2.0.0, has been released. The upstream > URL has also changed. Please update the Debian package to the new > version. > > https://fragglet.github.io/sdl-sopwith > > Simon (the upstream maintainer). Hi Simon, I am glad to see sopwith updated to use SDL 2, since we've been getting requests for that for a while now (such as in bug #894853 from way back in 2018). Up until now - at least since July of 2010, when I took over the Debian package - Jesse Smith (CC'd) has been considered the upstream maintainer for this code. Are you now taking it over? Or are you and Jesse going to be jointly maintaining it from now on? Given that the old SourceForge page has been updated to point at your new GitHub page, I am assuming this was a friendly transition. However, I do need to understand the new situation, especially since this isn't just a change in maintainer but is also a major change to the codebase at the same time. Thanks, KEN
Bug#997425: Adding dependency for now
I've decided to add the build dependency for the time being, to fix my FTBFS. If/when we sort things out with Sphinx, I can remove it. KEN -- Kenneth J. Pronovici signature.asc Description: PGP signature
Bug#997425: Related to #997341
This seems to be tied to a missing build dependency on python3-sphinx-autoapi. I added that to my chroot, and now the build for cedar-backup3 succeeds. However, I don't think it adding to the build dependencies here is the right step. I believe that python3-sphinx-autoapi is missing the dependency. Bug #997341 for src:sphinx-autoapi shows the same problem, so I think the solution is just to add the dependency there, and then all downstream packages will build again. KEN -- Kenneth J. Pronovici
Bug#997341: Typing Extensions
This problem seems to impact any package that uses python3-sphinx-autoapi as a build dependency. See also: bug #997425 for cedar-backup3. The fix seems to be as simple as adding a dependency on python3-typing-extensions. I added that to my chroot and now the build for cedar-backup3 succeeds again. KEN -- Kenneth J. Pronovici
Bug#967752: sopwith: depends on deprecated GTK 2
Ok, this is on my list. Not sure exactly how soon I'll get to it, but it won't be too long. KEN
Bug#932574: Ready
Sandro resolved the last dependency on logilab-common a few minutes ago, so it should now be possible to remove epydoc from the archive. KEN -- Kenneth J. Pronovici
Bug#933614: Last remaining dependency for epydoc
Hi Sandro, I just wanted to let you know that this is the last package remaining in the archive with a dependency or a build dependency on epydoc. Whenever you have a timeline for migrating to your new upstream release, please drop a note in here, just so everyone knows what to expect. I appreciate the help. Thanks! KEN -- Kenneth J. Pronovici
Bug#932574: One package remaining
There's one dependency remaining before we can close this bug: logilab-common. I've been talking with Sandro in #933614, and it sounds like upstream has moved to Sphinx. So, as soon as Sandro has time to package up the new release and adjust his package for the new documentation format, we'll be able to close this removal bug. KEN -- Kenneth J. Pronovici
Bug#932584: Epydoc and Pydoctor
I decided to NMU and uploaded a few days ago, so things are in good shape now, I think. You can integrate my changes whenever you have time. Thanks for confirming that your ok with the NMU. I was hoping you would be. KEN
Bug#933614: Proposed NMU
Thanks. That sounds like a good plan. KEN
Bug#933755: NMU Changes to remove Epydoc and Pychecker
It turns out that moap declares a build dependency on both python-epydoc and pychecker which is not strictly necessary. The code builds fine without either of these packages installed. The only functional difference is that the API documentation is not generated if epydoc is not installed. I have prepared a pull request to remove these dependencies: https://salsa.debian.org/python-team/applications/moap/merge_requests/1 I know I haven't given you much notice on these bugs. I would normally wait a few weeks to give you a chance to respond. However, since this NMU makes only minimal functional changes to your package, I have decided to upload immediately rather than waiting. This lets me keep moving on the removal process for epydoc and pychecker, and at the same time allows me to close the two serious bugs against your package. You can merge these changes whenever it's convenient. KEN
Bug#933614: Proposed NMU
I have submitted a merge request with my proposed NMU changes: https://salsa.debian.org/python-team/modules/logilab-common/merge_requests/1 These are the changes that I would like to upload sometime soon, once you've had a chance to talk with upstream. If upstream decides to convert away from epydoc and just needs some time to complete that work, let's determine a timeline and we can plan to merge my changes when the work is done. If there's no particular plan or timeline, then I would prefer to just make this change now. Once alternative documentation exists (in whatever format that takes), you can add it back into the package relatively easily. Thanks, KEN -- Kenneth J. Pronovici
Bug#933615: NMU Changes
It turns out that kiwi declares a build dependency on python-epydoc which is not necessary - the API documentation already exists and does not need to be regenerated, so epydoc is never used. I have created a merge request for this change: https://salsa.debian.org/python-team/modules/kiwi/merge_requests/2 I know I haven't given you much notice on this bug. I would normally wait a few weeks to give you a chance to respond. However, since this NMU doesn't make any functional changes to your package, I have decided to upload immediately rather than waiting. This lets me keep moving on the epydoc removal process and closes the serious bug against your package. You can merge these changes whenever it's convenient. KEN -- Kenneth J. Pronovici
Bug#933618: NMU Patch
I have created a merge request in salsa for my proposed NMU to fix this bug: https://salsa.debian.org/sramacher/python-crypto/merge_requests/1 Since I haven't given you much notice yet, I will wait to upload this NMU for at least a few weeks. If you are OK with the change and want me to NMU sooner than that, or you want to upload your own version of the package rather than my NMU, please let me know. Thanks, KEN -- Kenneth J. Pronovici
Bug#933616: NMU Patch
Hi, Attached is the patch for my NMU. Since I haven't given you much notice yet, I will wait to upload this NMU for at least a few weeks. If you are OK with the change and want me to NMU sooner than that, or you want to upload your own version of the package rather than my NMU, please let me know. Thanks, KEN -- Kenneth J. Pronovici nmu-remove-epydoc.patch Description: Binary data
Bug#933617: NMU
I will upload my NMU later today. Changes are captured in a merge request on salsa: https://salsa.debian.org/python-team/modules/pyinotify/merge_requests/1 KEN -- Kenneth J. Pronovici
Bug#881554: Pending upload for python-configshell-fb?
> While epydoc can parse Javadoc comments, it seems that Sphinx does not > support them. So I don't know how the documentation package for > configshell-fb could be generated without epydoc. Maybe we can simply > drop this package... It is possible to do this conversion in a semi-automated way. Back in the original bug report back in 2017, I provided [1], which is a hack-ish script to convert common Epydoc markup to Google-style docstrings that can be parsed by Sphinx. It's not perfect, but it would get you much of the way toward working code. However, unless you have time to take on that effort, I think it's probably going to be simplest to just drop the documentation package - especially if you think that the API documentation in Debian is not heavily-used. [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#933617: pyinotify: Epydoc will be removed
Ok, thank you for letting me know. I'll proceed when I have time.
Bug#933614: logilab-common: Epydoc will be removed
On Wed, Jul 31, 2019, 23:11 Sandro Tosi wrote: > Hello Kenneth, > > On Wed, Jul 31, 2019 at 10:36 PM Kenneth J. Pronovici > wrote: > > This is one of 20+ packages in the archive that still depend on Epydoc. > I > > have filed a bug with ftp.debian.org to have epydoc removed from > unstable. > > Besides its lack of support for Python 3, epydoc has been completely > > unsupported upstream for close to a decade. It really should have been > removed > > from the archive years ago. > > while i appreciate your effort here, i dont believe there's any > particular reason to jump the gun here. > Hey Sandro, One way or another I need to get Epydoc out of the archive. It's got to happen at some point, along with the python2 end-of-life transition that has already started. Epydoc can't be converted to python3; I've already tried, and it's too much work to be practical. So, it's better to just stop using it now and move on. You don't need to discard the API documentation from your package; you just can't generate it at Debian package build time using epydoc. For instance, upstream can include the pre-generated documentation in the distribution if they would like to continue using Epydoc on their own, installed from the upstream source. It just isn't viable to generate it in Debian any more. In any case, I'm sorry if I sound impatient, but trying to do the right thing here has cost me a lot of effort. This is one of the very few replies I've gotten in the last 18 months, even though I have tried to be proactive. I filed bugs, updated NEWS, etc. to basically no avail. For whatever reason, I didn't find your package in my initial search. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Another alternative is to switch to pydoctor, which is mostly compatible with epydoc markup. (I recently NMU'd that to remove the epydoc dependency.). But, pydoctor is also dependent on python2, so switching doesn't gain you much. Bottom line: if someone is actually committed to making the transition away from epydoc markup, I am happy to offer the time necessary to complete that effort. But I don't want to wait indefinitely. I want to get ahead of the python2 transition and get this package out of the archive relatively soon. Otherwise we're just delaying the inevitable. KEN [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert > >
Bug#881544: Epydoc will be removed
Hi, This is still one of 20+ packages in the archive that depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable, and that can't proceed while this package still uses epydoc as a build dependency. As a result, I have increased the severity of this bug to serious. As I find the time, I will be working through all of the remaining reverse dependencies. When I get to this package, I will NMU a version that removes the build dependency. I will accomplish this by simply not building the API documentation. I will not provide any other notice of my pending NMU. Thanks, KEN -- Kenneth J. Pronovici
Bug#881554: Pending upload for python-configshell-fb?
Hi, I just wanted to follow up on python-configshell-fb. Back in June, you marked a pending upload to remove the epydoc dependency, but the bug is still open. I've filed the package removal request for epydoc, and I'm working through all of the reverse dependencies to adjust them, so the package removal can proceed. Could you please upload your new package sometime soon? It would help simplify things for me. Thanks, KEN -- Kenneth J. Pronovici
Bug#932574: RM: epydoc -- ROM; Obsolete (Python 2) and Unmaintained
> Checking reverse dependencies... > # Broken Depends: > pydoctor: python-pydoctor > pywbem: python-pywbem I have now taken care of these via NMU. It turns out that neither package strictly depends on epydoc. The python-pywbem package declared a dependency and a build dependency, but did not seem to reference epydoc anywhere (not in imports or commands or anything). The module imports fine in a chroot without python-epydoc installed. The python-pydoctor package already contains code to make usage of epydoc optional. If it's not installed, the HTML renderer falls back on a plain text representation. I removed the dependency there, and it works fine. I'll be looking next at the packages that declare a build dependency on epydoc. My intent there will be to remove the build dependency and simply not generate the API documentation as part of the package build process. Since basically no one has bothered to respond to these bugs,, I have to assume that it will be better to have the packages still in Debian (but without API documentation) than removed completely. I will NMU these packages one at a time as I adjust them. I won't be giving any notice about my NMUs, since I already followed up in mid-June to announce my intent to remove epydoc. KEN -- Kenneth J. Pronovici
Bug#932584: Epydoc and Pydoctor
On Wed, Jul 31, 2019 at 10:46 AM Ian Jackson wrote: > > Otherwise, I will see if I can determine how well the package works > > without epydoc installed. If it works (i.e. doesn't blow up) and I > > don't hear back with other instructions, I will eventually NMU my > > changes to remove the epydoc dependency. Given that I haven't gotten > > any replies for more than 18 months now, I won't wait that long before > > doing this NMU. > > That sounds really good to me for now. I think you can do this NMU > whenever you like. I tested pydoctor against my own cedar-backup2 code, which I never converted away from Epydoc since it's Python 2-only. It seems to work fine: mars:~/projects/dev/software/cedar-backup2> pydoctor CedarBackup2/ adding directory /home/pronovic/projects/dev/software/cedar-backup2/CedarBackup2 41/41 modules processed 0 warnings WARNING: guessing CedarBackup2 for project name writing html to apidocs using pydoctor.templatewriter.writer.TemplateWriter starting ModuleIndexPage ... Error trying to import 'epytext' parser: ImportError: No module named epydoc.markup.epytext Using plain text formatting only. took 0.006452s starting ClassIndexPage ... took 0.011512s starting IndexPage ... took 0.002281s starting NameIndexPage ... took 0.079562s starting UndocumentedSummaryPage ... took 0.004314s 125/125 pages written Generating objects inventory at apidocs/objects.inv The generated HTML documentation is legible, if not as pretty as it would have been before. Given that it works, I am going to NMU the version of the package that doesn't depend on epydoc. I'll also create a PR on salsa. On salsa, master has diverged from the released package, but I am *not* going to integrate those changes, because I don't want to take responsibility for them. KEN -- Kenneth J. Pronovici
Bug#932584: Epydoc and Pydoctor
(I'm the maintainer for epydoc.)
I took a pass through the pydoctor code. The epydoc module is
imported in pydoctor/html.py, where it's an optional import:
try:
from epydoc.markup import epytext
EPYTEXT = True
except:
print "no epytext found"
EPYTEXT = False
Later on, in the doc2html() method, the code checks EPYTEXT and falls
back on a boring docstring implementation ("Generate an HTML
representation of a docstring in a really boring way") if the module
isn't available. This file has a docstring which says "The old HTML
generator. Deprecated, do not use", so it may not be relevant.
The epydoc module is also imported in pydoctor/epydoc2stan.py:
def get_parser(formatname):
try:
mod = __import__('epydoc.markup.' + formatname,
globals(), locals(), ['parse_docstring'])
except ImportError, e:
return None, e
else:
return mod.parse_docstring, None
Like html.py, epydoc2stan.py falls back on a boring docstring method
if get_parser() returns None.
Based on this analysis, it seems to me that epydoc isn't a strict
dependency for pydoctor. I think that pydoctor should still continue
to work even without the epydoc module available, albeit with somewhat
different output.
Given that epydoc does not work properly in Python 3, and it's beyond
my capabilities to fix it, there aren't too many options here. Either
we remove pydoctor's dependency on epydoc, or we remove pydoctor from
the archive.
I don't see any evidence that upstream is developing a Python 3
version of this code. This means that python-pydoctor will have to be
removed from the archive eventually. Maybe now is the time to do it?
Otherwise, I will see if I can determine how well the package works
without epydoc installed. If it works (i.e. doesn't blow up) and I
don't hear back with other instructions, I will eventually NMU my
changes to remove the epydoc dependency. Given that I haven't gotten
any replies for more than 18 months now, I won't wait that long before
doing this NMU.
KEN
--
Kenneth J. Pronovici
Bug#932585: Does not seem to actually require epydoc
The package has a Build-Depends-Indep and a Depends on python-epydoc, but there is no reference to epydoc anywhere in the source code or in the debian package structure. It's not clear why these dependencies were added in 0.8.0~dev650-1 back in 2014. However, the package builds successfully without python-epydoc installed in my unstable chroot. The INSTALL file with the source package says that everything should be ok as long as the module imports cleanly. I also tested this in my unstable chroot. Since it doesn't seem to be needed, I am going to NMU a new package removing these dependencies. That will resolve this bug. KEN -- Kenneth J. Pronovici - mars:~/projects/dev/debian/unstable/pywbem> schroot -c unstable-amd64 mars:~/projects/dev/debian/buster/pywbem> python Python 2.7.16+ (default, Jul 8 2019, 09:45:29) [GCC 8.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pywbem >>> mars:~/projects/dev/debian/buster/pywbem> apt-cache show python-pywbem Package: python-pywbem Status: install ok installed Priority: extra Section: python Installed-Size: 847 Maintainer: Debian Python Modules Team Architecture: all Source: pywbem Version: 0.8.0~dev650-1.1 Depends: python (<< 2.8), python (>= 2.7), python:any (>= 2.6.6-7~), python-m2crypto, python-twisted-web, python-twisted-core Description-en: Python WBEM Client and Provider Interface PyWBEM is a Python library that implements a Web Based Enterprise Management (WBEM) client. It performs WBEM operations using the CIM-XML and CIM Operations over HTTP protocols as defined by the Distributed Management Task Force (DMTF). WBEM is used to remotely describe and manage distributed computing environments. It is a peer and perhaps successor to the SNMP protocol. Description-md5: 4a8c6b688ada327da8965cfb75662489 Homepage: http://pywbem.sourceforge.net/
Bug#932575: More Work
I have filed a package removal request for spe (bug #933504), because it appears to be unsupported upstream and there's no evidence that a Python 3 version is under development. I CC'd the maintainers and uploaders. I NMU'd python-mode a few minutes ago to remove the recommendation on pychecker. The package existed for several years without this recommendation early in its life. The main consequence is that users will get an error if they try to run a pychecker-related command without having pychecker installed. Users can always install pychecker manually if they want to keep using it. I added documentation in the README.Debian about this and pointed users at pylint instead. I'll remove the moreinfo tag on this bug if/when the package removal for spe is executed. KEN -- Kenneth J. Pronovici
Bug#930399: NMU for python-mode
Later this evening, I will NMU python-mode to remove the Recommends: pychecker from debian/control. This change puts python-mode back to the state it was in as of 1.0-3.1 (prior to the fix for 458997). The package should still work in general, except that the pychecker-related commands will fail unless pychecker is installed manually. I will also update debian/README.Debian to make this clear. KEN -- Kenneth J. Pronovici
Bug#932575: Reverse Dependencies
This package still has some reverse dependencies, which I filed bugs against earlier this year. At the recommendation of the release team, I bumped up the severity of these bugs to serious (those bugs block this removal bug). My goal is to remove this package from both unstable and testing. I haven't gotten any responses at all from the maintainers of the reverse dependencies. It's hard to tell whether those packages are even being maintained any more. KEN -- Kenneth J. Pronovici
Bug#932574: Reverse Dependencies
This package still has some reverse dependencies and some reverse build dependencies, even though I filed bugs over 18 months ago asking people to move away from epydoc. At the recommendation of the release team, I filed bugs against the reverse dependencies, and marked those bugs as serious (those bugs block this removal bug). I have also marked this removal bug as affecting all of the earlier wishlist bugs against reverse build dependencies, just to clarify the impact of removal. My goal is to remove this package from both unstable and testing. The maintainers for the reverse dependencies and reverse build dependencies have been, for the most part, completely unresponsive, and I think that most of these packages are no longer maintained in any practical sense. Thanks, KEN -- Kenneth J. Pronovici
Bug#147005: Closing bug - package is obsolete and I have requested its removal
Hi, I will be closing this bug shortly. This package is obsolete. It depends on Python 2 and can't be converted to Python 3. It has also been unmaintained upstream for most of a decade. I have filed a bug with ftp.debian.org to remove the package from Debian now that buster has been released. Please reach out if you have any questions. Thanks, KEN -- Kenneth J. Pronovici
Bug#881554: [linux-target-packaging] Bug#881554: python-configshell-fb: Please migrate away from Epydoc if possible
> > Thanks! I appreciate the follow-up.
Bug#930399: python-mode: Pychecker will be removed after buster
Package: python-mode Severity: normal Hi, This is one of 3 packages in the archive that still depends on pychecker. I intend to have the pychecker package removed from unstable a little while after buster is released. Besides its lack of support for Python 3, pychecker has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. Since you also suggest pylint, I suspect that you probably just need to remove or disable the parts of python-mode that use pychecker, and then remove the dependency. Or perhaps you can just remove the dependency and users will get an error if they try to use pychecker and it's not installed. (In any case, it's not likely that very many people use the pychecker features these days.) If you reply to this bug and let me know how you're intending to handle this, I will hold off on removing pychecker from the archive until after you're done with your work. If I don't hear anything, then I'll move forward and have the package removed sometime in late July. Thanks, KEN
Bug#930398: spe: Pychecker will be removed after buster
Package: spe Severity: normal Hi, This is one of 3 packages in the archive that still depends on pychecker. I intend to have the pychecker package removed from unstable a little while after buster is released. Besides its lack of support for Python 3, pychecker has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I am not sure whether it's possible to convert spe to some alternative tool, such as pylint. You may simply need to disable the parts of spe that depend on pychecker. Or perhaps spe is obsolete and should itself be removed from the archive. If you let me know that you are intending to convert spe to some alternative and need some time to complete that work, I will hold off on removing pychecker from the archive until after you're done. If I don't hear anything, then I'll move forward and have the package removed sometime in late July. Thanks, KEN
Bug#930400: boa-constructor: Pychecker will be removed after buster
Package: boa-constructor Severity: normal Hi, This is one of 3 packages in the archive that still depends on pychecker. I intend to have the pychecker package removed from unstable a little while after buster is released. Besides its lack of support for Python 3, pychecker has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I am not sure whether it's possible to convert boa-constructor to some alternative tool, such as pylint. You may simply need to disable the parts of boa-constructor that depend on pychecker. Or perhaps boa-constructor is obsolete and should itself be removed from the archive. If you let me know that you are intending to convert boa-constructor to some alternative and need some time to complete that work, I will hold off on removing pychecker from the archive until after you're done. If I don't hear anything, then I'll move forward and have the package removed sometime in late July. Thanks, KEN
Bug#881544: Epydoc will be removed after buster
I intend to have the eypdoc package removed from unstable a few weeks after buster is released. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. If you are in the process of migrating and simply need more time, please reply to this bug and we can come to some sort of arrangement. Otherwise, I'm going to have the package removed as planned. Once the package is removed, your best short-term solution is to just stop building API documentation until you find time to convert to another tool. Thanks, KEN -- Kenneth J. Pronovici
Bug#881566: Epydoc will be removed after buster
Hi, This bug report is now over 18 months old with no reply. I intend to have the eypdoc package removed from unstable a few weeks after buster is released. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. If you are in the process of migrating and simply need more time, *please* reply to this bug and we can come to some sort of arrangement. Otherwise, I'm going to have the package removed as planned. Once the package is removed, your best short-term solution is to just stop building API documentation until you find time to convert to another tool. Thanks, KEN -- Kenneth J. Pronovici gmail.com>
Bug#881558: Intending to remove epydoc after buster
Hi, I just wanted you to know that I am intending to have epydoc removed from unstable a few weeks after buster is released, along with several other obsolete Python packages that I maintain. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. If you are in the process of migrating and simply need more time, please let me know how much time you think you need, and we can come to some sort of arrangement. Otherwise, I'm going to have the package removed as planned. Once the package is removed, your best short-term solution is to just stop building API documentation until you find time to convert to another tool. Thanks, KEN -- Kenneth J. Pronovici
Bug#881546: Epydoc will be removed after buster
Hi, This bug report is now over 18 months old with no reply. I intend to have the eypdoc package removed from unstable a few weeks after buster is released. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. If you are in the process of migrating and simply need more time, *please* reply to this bug and we can come to some sort of arrangement. Otherwise, I'm going to have the package removed as planned. Once the package is removed, your best short-term solution is to just stop building API documentation until you find time to convert to another tool. Thanks, KEN -- Kenneth J. Pronovici
Bug#881558: python-rtslib-fb: Please migrate away from Epydoc if possible
On Tue, Mar 26, 2019, 09:18 Thomas Goirand wrote: > Hi, > > Could you explain again how to fix? Maybe you can provide a patch for > this package? I'd like to fix this right after Buster, to get rid of all > traces of Python 2. > There's no general solution. Someone needs to review the existing code documentation, convert it to some other format, and stop using Epydoc. (Or simply stop generating API documentation at all.) In my original bug report, I provided a link to the converter script that I used in my own code, which offers a starting point for one kind of solution (converting Epydoc markup to Google-style docstrings). However, there are dozens of packages that depend on Epydoc, and they are all different, so I'm not capable of providing a patch or specific instructions. KEN >
Bug#918836: ncompress: failure with soft links
It looks like this is because -DLSTAT got added to upstream's default build options for 4.2.4.5. That flag has not historically been used in the Debian builds. I removed it, and that seems to resolve the problem. I'll push a new version of the package later today, after I get a chance to add some tests to prevent this regression the next time. KEN
Bug#918836: ncompress: failure with soft links
On Wed, Jan 9, 2019, 11:45 Martin Lutz Package: ncompress > Version: 4.2.4.5-1 > Severity: normal > > Dear Maintainer, > > the command "compress -dc file.Z > t.t" fails if file.Z is a soft link. The > error message is: "file.Z is not a directory or a regular file - ignored". > > Before the latest update this command worked without problems. Thanks for reporting this. I guess I don't have an autopktest case for that scenario, so I'll add one. I'll see if I can figure out what caused the change. There hasn't been any upstream release in years, and I had to make changes to my build process for this release, so I'm not sure whether I caused this or it was an upstream change. KEN > >
Bug#894853: sopwith: SDL1 version is useless, please use GTK or SDL2
Hi, Thanks for the bug report. Sorry for the late reply on this. I've been on holiday. I'll leave the bug open so that other people who have the same issue can find it. However, per Jesse's reply, I don't think there's a fast fix. The package does work on my system, so it's not completely broken for everyone. As a result, a normal severity seems appropriate. I'll leave it like that. KEN
Bug#881562: rdkit: Please migrate away from Epydoc if possible
Source: rdkit Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881560: pywbem: Please migrate away from Epydoc if possible
Source: pywbem Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881563: xappy: Please migrate away from Epydoc if possible
Source: xappy Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881561: qpid-proton: Please migrate away from Epydoc if possible
Source: qpid-proton Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881559: python-x2go: Please migrate away from Epydoc if possible
Source: python-x2go Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881558: python-rtslib-fb: Please migrate away from Epydoc if possible
Source: python-rtslib-fb Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881557: python-openid: Please migrate away from Epydoc if possible
Source: python-openid Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881556: python-demgengeo: Please migrate away from Epydoc if possible
Package: python-demgengeo Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881554: python-configshell-fb: Please migrate away from Epydoc if possible
Source: python-configshell-fb Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881555: python-csb: Please migrate away from Epydoc if possible
Source: python-csb Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881552: pylogsparser: Please migrate away from Epydoc if possible
Source: pylogsparser Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881553: pystemmer: Please migrate away from Epydoc if possible
Source: pystemmer Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881551: pylibssh2: Please migrate away from Epydoc if possible
Source: pylibssh2 Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881550: pydoctor: Please migrate away from Epydoc if possible
Source: pydoctor Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881549: munkres: Please migrate away from Epydoc if possible
Source: munkres Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881547: lcm: Please migrate away from Epydoc if possible
Source: lcm Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881548: libcloud: Please migrate away from Epydoc if possible
Source: libcloud Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881546: esys-particle: Please migrate away from Epydoc if possible
Package: esys-particle Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#881544: dbf: Please migrate away from Epydoc if possible
Source: dbf Severity: wishlist Hi, If possible, please consider moving away from the use of Epydoc in your package. Epydoc is basically unmaintained upstream. Also, it is only supported for Python 2, so it will reach its end of life along with Python 2 sometime in 2020. I will continue to maintain the Epydoc packages in Debian as long as I can, acting as de facto upstream. However, once Python 2 is unsupported in Debian, I'm not sure that we'll have too many options to keep it alive. Migrating it to Python 3 is a fairly large job that I don't have the time or the expertise to take on right now. For my own Python code, I have recently converted to Sphinx using the Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Thanks, Ken (maintainer for python-epydoc) [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert
Bug#825968: epydoc: nondeterminism caused by list and file ordering
Hi, Sorry for the late reply; I've been traveling. I'll work to apply these patches sometime soon -- hopefully within the next week. I do track the reproducible status for this package, so this is a high priority for me. KEN
Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees
On Mon, Aug 17, 2015 at 5:11 PM, Kenneth Pronovici prono...@ieee.org wrote: I'll apply both of these patches and upload sometime soon, hopefully within the next few days. I have both patches applied in my revision control, and I'll upload shortly. I've tested that nothing appears broken (i.e. my autopkgtest stuff still passes, and epydoc docs for my own software looks reasonable), but I'm not 100% sure how to test your changes. So, I'm assuming you'll tell me if something isn't working like you expect. Thanks, KEN -- Kenneth J. Pronovici prono...@debian.org
Bug#795826: Bug#795835: epydoc: Please use (deterministic) sorting for module and class trees
Hi Val, I'll apply both of these patches and upload sometime soon, hopefully within the next few days. KEN
Bug#794036: ITP: cedar-backup3 -- local and remote backups to CD/DVD media or Amazon S3 storage
Package: wnpp Severity: wishlist Owner: Kenneth J. Pronovici prono...@debian.org * Package name: cedar-backup3 Version : 3.0.0 Upstream Author : Kenneth J. Pronovici prono...@ieee.org * URL : https://bitbucket.org/cedarsolutions/cedar-backup3 * License : GPL v2 Programming Lang: Python 3 Description : local and remote backups to CD/DVD media or Amazon S3 storage This is a Python 3 conversion of the existing cedar-backup2 package, which is targeted at Python 2. I maintain cedar-backup2 and I'm also upstream for Cedar Backup. KEN -- Kenneth J. Pronovici prono...@debian.org signature.asc Description: Digital signature
Bug#793923: virtualenv: Hangs installing setuptools/pip when specific files exist in $PWD
Package: virtualenv
Version: 1.11.6+ds-1
Severity: normal
I have run into a strange scenario with virtualenv, which I can reliably
reproduce in both jessie and an up-to-date unstable chroot.
I was trying to create a Python 2.7 virtualenv from within the source
tree for cedar-backup2. Every time I ran it, the virtualenv process
hung at Installing setuptools, pip
I eventually discovered that this only happened when I was within the
source tree. If went to some other directory but installed to the same
place, virtualenv completed as expected.
This made me suspicious that there was something in my source tree
causing the problem, so I started removing things until virtualenv
worked properly. What I ended up with is a very minimal test case:
wintermute:/home/pronovic/tmp/package/code echo $PYTHONPATH
wintermute:/home/pronovic/tmp/package/code which virtualenv
/usr/bin/virtualenv
wintermute:/home/pronovic/tmp/package/code ls -l
total 4
drwxrwsr-x 2 pronovic pronovic 4096 Jul 28 16:33 util/
wintermute:/home/pronovic/tmp/package/code ls -l util/
total 8
-rw-rw-r-- 1 pronovic pronovic 15 Jul 28 16:32 __init__.py
-rw-rw-r-- 1 pronovic pronovic 33 Jul 28 16:32 whatever.py
wintermute:/home/pronovic/tmp/package/code cat util/__init__.py
__all__ = [ ]
wintermute:/home/pronovic/tmp/package/code cat util/whatever.py
import sys
sys.stdin.readlines()
wintermute:/home/pronovic/tmp/package/code rm -rf .python virtualenv
--python=python2.7 .python # hangs
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in .python/bin/python2.7
Not overwriting existing python script .python/bin/python (you must use
.python/bin/python2.7)
Installing setuptools, pip...
wintermute:/home/pronovic/tmp/package/code cd ..
wintermute:/home/pronovic/tmp/package rm -rf code/.python virtualenv
--python=python2.7 code/.python # works
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in code/.python/bin/python2.7
Not overwriting existing python script code/.python/bin/python (you must use
code/.python/bin/python2.7)
Installing setuptools, pip...done.
wintermute:/home/pronovic/tmp/package cd code
wintermute:/home/pronovic/tmp/package/code cat util/whatever.py # note
readlines() commented out
import sys
#sys.stdin.readlines()
wintermute:/home/pronovic/tmp/package/code rm -rf .python virtualenv
--python=python2.7 .python # works
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in .python/bin/python2.7
Also creating executable in .python/bin/python
Installing setuptools, pip...done.
It actually kind of of makes sense that readlines() is involved, because
if I CTRL-C virtualenv when it's stuck, I get this stack trace:
Installing setuptools, pip...^Cdone.
Traceback (most recent call last):
File /usr/bin/virtualenv, line 9, in module
Traceback (most recent call last):
File /usr/lib/python3/dist-packages/virtualenv.py, line 2378, in
module
load_entry_point('virtualenv==1.11.6', 'console_scripts',
'virtualenv')()
File /usr/lib/python3/dist-packages/virtualenv.py, line 790, in main
main()
File /usr/lib/python3/dist-packages/virtualenv.py, line 830, in main
raise SystemExit(popen.wait())
File /usr/lib/python3.4/subprocess.py, line 1566, in wait
symlink=options.symlink)
File /usr/lib/python3/dist-packages/virtualenv.py, line 1032, in
create_environment
install_wheel(to_install, py_executable, search_dirs)
File /usr/lib/python3/dist-packages/virtualenv.py, line 975, in
install_wheel
'PIP_NO_INDEX': '1'
File /usr/lib/python3/dist-packages/virtualenv.py, line 889, in
call_subprocess
line = stdout.readline()
KeyboardInterrupt
(pid, sts) = self._try_wait(0)
File /usr/lib/python3.4/subprocess.py, line 1514, in _try_wait
(pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
File /usr/lib/python3.4/subprocess.py, line 491, in
_eintr_retry_call
return func(*args)
KeyboardInterrupt
The behavior seems to be tied to a Python package named util. If I
remove util/__init__.py or rename the package to something else, that
also solves the problem.
It does not seem to matter what the name of the source file is
(whatever.py is just an example), and it doesn't seem to matter which
version of Python I am trying to create a virtualenv for. I've
reproduced the same behavior with 2.7 and 3.4.
Let me know if there's anything else I can help with,
Thanks,
KEN
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to
en_US)
Shell: /bin/sh linked to /bin/dash
Bug#790899: epydoc: please support timestamps from environment
On Mon, Jul 6, 2015 at 1:38 PM, Kenneth Pronovici prono...@debian.org wrote: On Thu, Jul 2, 2015 at 3:27 PM, Reiner Herrmann rei...@reiner-h.de wrote: Thanks for considering it! :) We uploaded also a patched epydoc to our repository today and are currently rebuilding affected packages [1]. The page should be updated soon. Ok, what you're asking for makes sense to me. I agree that it seems worthwhile to make these changes in Epydoc. I'm traveling this week for work. Unless Edward objects, I'll plan to apply the patch and upload a new package to unstable sometime after I'm back, hopefully no later than next weekend. I have filed a related bug in the upstream bug tracker: https://sourceforge.net/p/epydoc/bugs/368/ I updated the original patch to include man/epydoc.1, adding a section called REPRODUCIBLE BUILD BEHAVIOR. I also tweaked the patch description to better match the bug report I filed at SourceForge. I'll be uploading 3.0.1+dfsg-8 later today, including this patch. I have tested epydoc's general behavior, but I have not specifically tested the behavior around SOURCE_DATE_EPOCH. I am assuming you will tell me if the current version of the package does not meet your needs for the Reproducible Builds effort. Please let me know if you need anything else. 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#790899: epydoc: please support timestamps from environment
On Thu, Jul 2, 2015 at 3:27 PM, Reiner Herrmann rei...@reiner-h.de wrote: Thanks for considering it! :) We uploaded also a patched epydoc to our repository today and are currently rebuilding affected packages [1]. The page should be updated soon. Ok, what you're asking for makes sense to me. I agree that it seems worthwhile to make these changes in Epydoc. I'm traveling this week for work. Unless Edward objects, I'll plan to apply the patch and upload a new package to unstable sometime after I'm back, hopefully no later than next weekend. 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#790899: epydoc: please support timestamps from environment
On Thu, Jul 2, 2015 at 2:13 PM, Reiner Herrmann rei...@reiner-h.de wrote: In 3.0.1+dfsg-6 a patch has been added that allows packages to disable embedding of timestamps. But the default behavior of epydoc is to still embed timestamps (which requires modifications for each package using epydoc). If timestamps have to be kept, we have a proposal for using deterministic ones [1] (based on the latest debian/changelog entry), which is contained in the environment variable SOURCE_DATE_EPOCH (which will hopefully soon be exported by debhelper). The attached patch proposes a way to use this variable to get reproducible timestamps, if the variable has been set (if not, it falls back to the old behavior). Hi Reiner, I have been following the reproducible builds effort. I appreciate you providing this patch. However, I have some concerns with it. My main concern is that this patch adds some rather Debian-specific behavior to epydoc. I'm not entirely comfortable with this, given that eypdoc is a general-purpose tool which just happens to be used when building some Debian packages. Adding a new command-line switch is one thing, but changing behavior to respond silently to a environment variable feels different to me. This would be the only environment variable that epydoc pays any attention to. I skimmed through the comments in #787444, and I gather that help2man has added support for this environment variable. Are you filing similar bugs with other documentation-generator packages in Debian? Have other packages committed to supporting it? Are you expecting this to become a standard used by other Linux distributions? It seems like relatively few Debian packages use epydoc as part of their build process. I guess I'm questioning whether it's really worth adding this Debian-specific behavior just to avoid changing those packages. I'm not saying no, but I would like to get a better handle on some of these questions before I apply the patch and release a new package. I've also CC'd upstream (Edward Loper) to see if he has an opinion one way or the other. 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#784719: Stable will be updated, too
I've gotten permission to upload a fix to jessie, so this problem will eventually be fixed there too. Reference #78401: bugs.debian.org/784801 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#784801: jessie-pu: package cproto/4.7l-4
On Sat, 2015-05-09 at 12:53 -0500, Kenneth Pronovici wrote: If you were referring to whether to take the backport route or adding the patch, then either is fine as long as the version number makes sense for the approach taken. I've attached a patch for 4.7l-3+deb8u1, which I built and tested in a clean jessie chroot. Thanks; please go ahead. The upload is complete. I got the confirmation email: cproto_4.7l-3+deb8u1_amd64.changes ACCEPTED into proposed-updates-stable-new Please let me know if there is anything else you need me to do. 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#784801: jessie-pu: package cproto/4.7l-4
On May 9, 2015 4:57 AM, Adam D. Barratt a...@adam-barratt.org.uk wrote: Control: tags -1 + moreinfo On Fri, 2015-05-08 at 18:17 -0500, Kenneth Pronovici wrote: In April of 2013 (version 4.7j-7), I converted cproto to debhelper 7. In the process, I accidentally lost the only option I was passing to configure (--enable-llib). As a result, I disabled the -X command-line option. This means there is a functional regression between wheezy (version 4.7j-5) and jessie (version 4.7l-3). The manpage is also wrong. See bug #784719. A few minutes ago, I uploaded version 4.7l-4 to unstable. The diff vs. 4.7l-3 (in jessie) is attached as debian.diff. The only change is to pass the missing --enable-llib configure option. Thanks for that. The patch looks okay in isolation, but the more interesting and useful diff is between the package in jessie and the one that you're proposing to upload to p-u. That should be versioned as either 4.7l-3+deb8u1 or -4~deb8u1 depending on whether you add the patch to the jessie package or rebuild (and test) the unstable package in a jessie environment. Well, the package in jessie is identical to the package in unstable prior to yesterday's upload, so the diff for 4.7l-3+deb8u1 or -4~deb8u1 would be the same as in debian.diff except for the version number itself. Does that answer your question? I haven't prepared the jessie-specific package yet, because I wasn't sure it was worthwhile... I can rebuild against jessie or unstable, whichever you prefer. KEN
Bug#784801: jessie-pu: package cproto/4.7l-4
The diff for -3+deb8u1 would be; -4~deb8u1 would include an extra changelog stanza (as it would have -4's and then -4~deb8u1's). I haven't prepared the jessie-specific package yet, because I wasn't sure it was worthwhile... I can rebuild against jessie or unstable, whichever you prefer. The rebuild needs to be against jessie; that's a fairly fundamental given for updating the package in stable. Yes, understood. If you were referring to whether to take the backport route or adding the patch, then either is fine as long as the version number makes sense for the approach taken. I've attached a patch for 4.7l-3+deb8u1, which I built and tested in a clean jessie chroot. Thanks, KEN -- Kenneth J. Pronovici prono...@debian.org Index: debian/changelog === --- debian/changelog(.../4.7l-3)(revision 757) +++ debian/changelog(.../4.7l-3+deb8u1) (revision 757) @@ -1,3 +1,13 @@ +cproto (4.7l-3+deb8u1) jessie; urgency=low + + * Fix functional regression vs. 4.7j-5 in wheezy (closes: #784719). +- Modify debian/rules to put back --enable-llib configure option, by adding + override_dh_auto_configure. This option was accidentally lost in version + 4.7j-7 while converting to debhelper 7. This disabled the -X command + line option in the cproto program, a regression vs. wheezy. + + -- Kenneth J. Pronovici prono...@debian.org Sat, 09 May 2015 11:54:56 -0500 + cproto (4.7l-3) unstable; urgency=medium * Fix various minor Lintian warnings in debian/copyright. Index: debian/rules === --- debian/rules(.../4.7l-3)(revision 757) +++ debian/rules(.../4.7l-3+deb8u1) (revision 757) @@ -9,3 +9,5 @@ override_dh_installdocs: dh_installdocs README +override_dh_auto_configure: + dh_auto_configure -- --enable-llib
Bug#784719: not backward compatible and faulty manpage
On Thu, May 7, 2015 at 8:13 PM, Jerome BENOIT calcu...@rezozer.net wrote: I appeares that cproto 4.7l-3 has a faulty manpage and that some options have disappeared from the oldstable (Wheezy) version 4.7j . For example: the option -X is no more valid but it is documented in the man page. I realised it while using pbuilder to check a package within unstable. Hmm. This appears to be because I am not passing --enable-llib to configure. I went back in revision control for debian/rules. As far as I can tell, I lost that configure option when converting to debhelper 7 in April of 2013 (in version 4.7j-7). The reason we're seeing a regression in stable now is because wheezy ended up with version 4.7j-5, which is prior to the debhelper 7 conversion. Apparently, cproto has been like this in unstable for more than 2 years, and no one else noticed. I can definitely fix this in unstable. I'll upload a new package sometime in the next few days. I'm less certain whether I can get a new package into a future update to jessie. I'll investigate and see what my options are. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784801: jessie-pu: package cproto/4.7l-4
- rename install.sh to install-sh
-2005/12/8 (4.7e)
+2005/12/08 (4.7e)
- eliminate some fixed limits on buffer sizes (prompted by FreeBSD port).
- eliminate fixed limit on include nesting.
- use configure check for mkstemp(), use that function in preference to
@@ -88,13 +103,13 @@
- updated configure script, using autoconf 2.52 + patch, along with macros from
vile/lynx/etc.
-2004/03/9 (4.7b)
+2004/03/09 (4.7b)
- added new -X option to limit the levels of include-files from which an
extern can come (Debian #235824).
- added new -i option to support inline function prototypes (Debian #228801,
patch by Kenneth Pronovici).
-2003/04/5 (4.7a)
+2003/04/05 (4.7a)
- add definition of YYFLAG, to enable the error-reporting code with bison 1.875
- add definition of YYSTYPE, to allow this to build with recent (aka broken)
@@ -121,7 +136,7 @@
- remove makefile rules to make shar files (comp.sources.misc is long gone).
- stop using changequote(), workaround for bugs in autoconf 2.5x
-2000/11/9 (4.7)
+2000/11/09 (4.7)
- Report source file and line number in error messages in gcc-style format.
2000/08/10 (4.6d)
@@ -132,7 +147,7 @@
independently of $(prefix) and $(exec_prefix) (patch by Carsten Leonhardt
l...@debian.org).
-2000/07/8 (4.6c)
+2000/07/08 (4.6c)
- add a clause to handle __extension__ before extern declarations.
(report by Bob van der Poel bvdp...@uniserve.com)
diff '--exclude=configure' '--exclude=config.guess' '--exclude=config.sub' '--exclude=aclocal.m4' -Naur cproto-4.7j/configure.in cproto-4.7l/configure.in
--- cproto-4.7j/configure.in 2010-07-12 00:49:23.0 +
+++ cproto-4.7l/configure.in 2014-01-01 15:48:47.0 +
@@ -1,12 +1,12 @@
dnl Process this file with 'autoconf' to produce a 'configure' script
-dnl $Id: configure.in,v 4.13 2010/07/12 00:49:23 tom Exp $
-AC_REVISION($Revision: 4.13 $)
+dnl $Id: configure.in,v 4.16 2014/01/01 15:48:47 tom Exp $
+AC_REVISION($Revision: 4.16 $)
AC_PREREQ(2.52.20030208)
AC_INIT(cproto.c)
AC_CONFIG_HEADER(config.h:config_h.in)
CF_CHECK_CACHE
-AC_PROG_CC
+CF_PROG_CC
AC_PROG_CPP
AC_PROG_LEX
AC_PROG_MAKE_SET
@@ -15,9 +15,6 @@
CF_MAKE_TAGS
CF_PROG_LINT
-CF_PROG_EXT
-
-CF_ANSI_CC_REQD
CF_XOPEN_SOURCE
CF_WITH_WARNINGS
@@ -47,7 +44,19 @@
AC_HAVE_HEADERS(stdlib.h unistd.h)
AC_HAVE_HEADERS(getopt.h string.h memory.h)
-AC_HAVE_FUNCS(strstr tmpfile link unlink)
+AC_HAVE_FUNCS(getopt popen strstr tmpfile link unlink)
+
+if test x$ac_cv_func_getopt = xno
+then
+ CPPFLAGS=$CPPFLAGS -I\$(srcdir)/porting
+ EXTRA_OBJS=$EXTRA_OBJS getopt.o
+fi
+
+if test x$ac_cv_func_popen = xno
+then
+ CPPFLAGS=$CPPFLAGS -I\$(srcdir)/porting
+ EXTRA_OBJS=$EXTRA_OBJS popen.o
+fi
### special configuration tests
CF_MKSTEMP
@@ -69,3 +78,4 @@
### output makefile and config.h
AC_OUTPUT(Makefile,,,cat)
+CF_MAKE_DOCS(cproto,1)
diff '--exclude=configure' '--exclude=config.guess' '--exclude=config.sub' '--exclude=aclocal.m4' -Naur cproto-4.7j/cproto.c cproto-4.7l/cproto.c
--- cproto-4.7j/cproto.c 2011-01-02 19:24:03.0 +
+++ cproto-4.7l/cproto.c 2014-01-01 15:30:44.0 +
@@ -1,8 +1,8 @@
-/* $Id: cproto.c,v 4.33 2011/01/02 19:24:03 tom Exp $
+/* $Id: cproto.c,v 4.36 2014/01/01 15:30:44 tom Exp $
*
* C function prototype generator and function definition converter
*/
-#define VERSION 4.7j
+#define VERSION 4.7l
#include cproto.h
@@ -104,8 +104,8 @@
#ifdef CPP
# if !HAVE_POPEN_PROTOTYPE
extern FILE *popen(const char *c, const char *m);
-# endif
extern int pclose(FILE *p);
+# endif
static size_t cpp_len;
static const char *cpp = CPP;
static char *cpp_opt;
diff '--exclude=configure' '--exclude=config.guess' '--exclude=config.sub' '--exclude=aclocal.m4' -Naur cproto-4.7j/cproto.h cproto-4.7l/cproto.h
--- cproto-4.7j/cproto.h 2011-01-02 19:30:39.0 +
+++ cproto-4.7l/cproto.h 2013-10-25 20:28:26.0 +
@@ -1,4 +1,4 @@
-/* $Id: cproto.h,v 4.17 2011/01/02 19:30:39 tom Exp $
+/* $Id: cproto.h,v 4.18 2013/10/25 20:28:26 tom Exp $
*
* Declarations for C function prototype generator
*/
@@ -25,6 +25,10 @@
#define YACC_HAS_YYTOKS_2 0
#endif
+#ifndef HAVE_LINK
+#define HAVE_LINK 0
+#endif
+
#ifndef HAVE_POPEN_PROTOTYPE
#define HAVE_POPEN_PROTOTYPE 0
#endif
diff '--exclude=configure' '--exclude=config.guess' '--exclude=config.sub' '--exclude=aclocal.m4' -Naur cproto-4.7j/lex.l cproto-4.7l/lex.l
--- cproto-4.7j/lex.l 2011-01-02 18:31:53.0 +
+++ cproto-4.7l/lex.l 2014-01-01 16:01:46.0 +
@@ -2,7 +2,7 @@
%{
-/* $Id: lex.l,v 4.22 2011/01/02 18:31:53 tom Exp $
+/* $Id: lex.l,v 4.23 2014/01/01 16:01:46 tom Exp $
*
* Lexical analyzer for C function prototype generator
*
@@ -994,7 +994,7 @@
} else {
return;
}
-s = strchr(file_spec + 1, match);
+s = (strchr) (file_spec + 1, match);
n = (s != NULL) ? (unsigned) (s - file_spec - 1) : 0;
file = xstrdup(file_spec + 1);
file[n] = '\0';
diff '--exclude=configure
Bug#764401: Are you planning to take over mksh in Debian?
On Fri, May 1, 2015 at 5:36 PM, Thorsten Glaser t...@mirbsd.de wrote: Kenneth Pronovici dixit: I'll file a Debian bug to document the improvements I asked for, just Please DO NOT file Debian bugs for upstream issues in mksh, only for packaging issues. This has been at the top of README.Debian for ages. Thorsten, I'm not trying to be snarky here, but I'm a little lost. This package is orphaned. If you're no longer the package maintainer, why should it even matter to you whether upstream issues are tracked as Debian bugs? I filed the bug so nothing would get lost while the package is orphaned, which seems like a reasonable thing to do. The next maintainer might very well have a different policy for Debian bugs than you did. I would if it were my package. Besides that, this is arguably a functional regression vs. older versions of pdksh in Debian, which mksh now provides. I think it's useful to have the change in behavior noted, even if it is only a wishlist. 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#764401: Bug#783978: Bug#764401: Are you planning to take over mksh in Debian?
On Fri, May 1, 2015 at 6:18 PM, Thorsten Glaser t...@mirbsd.de wrote: Kenneth Pronovici dixit: I'm not trying to be snarky here, but I'm a little lost. This package is orphaned. If you're no longer the package maintainer, why should it even matter to you whether upstream issues are tracked as Debian bugs? Because ① I’m upstream, ② I’m maintaining this package in Debian, and, most importantly, ③ feature requests aren’t bugs, period. Besides that, this is arguably a functional regression vs. older versions of pdksh in Debian, which mksh now provides. I think it's useful to have the change in behavior noted, even if it is only a wishlist. That’s arguably a good point. One of mksh’s biggest strengths is that it behaves consistently across all platforms, though. DO NOT break that. Ok, this is clearly becoming way more of a big deal than I expected it to be. If you're maintaining the package in Debian (even though it's orphaned, which makes no sense to me) then feel free to just close #783978, the wishlist request. I'd prefer to have that bug stay open, but now we've moved into the realm of differing philosophies regarding bug reports, and you and I clearly disagree on this subject. Do whatever works best for you. As far as the mksh behavior is concerned, I never suggested (even in the original stackexchange discussion), that I wanted to make mksh behave differently in Debian than on other platforms. I was simply offering to help get the changes into Debian, based on the fact that the package appeared to be without a maintainer. If the package is being maintained, then you don't need my help with that. End of story. I hereby withdraw my interest in #764401, the ITA bug report. If you can make the requested improvement upstream, that's great, and I would really welcome the change. If not, I'll just find some other shell to use. 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#764401: Are you planning to take over mksh in Debian?
Hi Dominik, Are you still planning to take over mksh in Debian? If not, I would like to take ownership of #76401 and maintain the package myself. I actively use ksh on Debian, and I don't want to see the packages go unmaintained. Also, I have been talking with upstream about some improvements, and I want to be in a position where I can apply patches. Thanks! KEN -- Kenneth J. Pronovici prono...@debian.org
Bug#764401: Are you planning to take over mksh in Debian?
On Fri, May 1, 2015 at 1:03 PM, Dominik George n...@naturalnet.de wrote: Are you still planning to take over mksh in Debian? If not, I would like to take ownership of #76401 and maintain the package myself. I actively use ksh on Debian, and I don't want to see the packages go unmaintained. Also, I have been talking with upstream about some improvements, and I want to be in a position where I can apply patches. I am still going to take over mksh in Debian, yes. Currently, the package is still maintained by Thorsten Glaser, who is a next door neighbour at my dayjob and keeps mksh updated on behalf of Debian QA. Please send your improvements to me, nonetheless. Ok. My main goal is to make sure the mksh package is being maintained. If it is, then there's no need for me to take it over. I'll file a Debian bug to document the improvements I asked for, just so something is being tracked. Whenever the new code is available, I'll assume you can integrate it into Debian. If you need my help integrating or testing changes, or if you eventually change your mind about taking over the package, please let me know. Thanks, 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#783978: mksh: Support command-line history for multi-line commands
Package: mksh Version: 50d-5 Severity: wishlist Tags: upstream Recently, since pdksh on Debian is now implemented by mksh, command-line history no longer works like it used to several years ago. I use ksh in vi-editing mode (set -o vi and FCEDIT=vi). Quite often, I write short multi-line commands immediately at the command prompt, i.e. daystrom:/home/pronovic for i in 1 2 3 do print $i done 1 2 3 These work as expected in mksh. However, command-line history does not. Previously, this script would be preserved in the history as a single entry. So, I could hit ESC-k and go back to the front of the for line. Once I got there, I could edit the script in place again, or I could hit ESC-v to edit the script in vi. In mksh, each line in my script (the for line, the do line, the print line, etc.) ends up as a separate entry in my history. So, ESC-k just takes me to the done line, ESC-k again takes me to the print line, etc. I started a discussion on stackexchange: http://unix.stackexchange.com/questions/199766/is-it-possible-to-get-working-history-for-multi-line-commands-in-mksh-using-vi In that discussion, mirabilos says that this behavior can be improved. I am submitting this Debian bug to track the request. Thanks, KEN -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mksh depends on: ii libc6 2.19-18 mksh recommends no packages. Versions of packages mksh suggests: ii ed 1.10-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783326: Acknowledgement (please make the generated output reproducible)
I've uploaded epydoc_3.0.1+dfsg-6 including this change. I tweaked
the help output slightly and also added information in the manpage.
The final version of the patch is attached for reference.
KEN
--
Kenneth J. Pronovici prono...@debian.org
Description: Add --no-include-build-time option to allow reproducible builds.
Author: Jelmer Vernooij jel...@debian.org, Kenneth J. Pronovici prono...@debian.org
Bug: https://sourceforge.net/p/epydoc/bugs/367/
Bug-Debian: https://bugs.debian.org/783326
Forwarded: https://sourceforge.net/p/epydoc/bugs/367/
Last-Update: 2015-04-25
Index: epydoc-3.0.1+dfsg/epydoc/cli.py
===
--- epydoc-3.0.1+dfsg.orig/epydoc/cli.py
+++ epydoc-3.0.1+dfsg/epydoc/cli.py
@@ -137,7 +137,7 @@ OPTION_DEFAULTS = dict(
include_source_code=True, pstat_files=[], simple_term=False, fail_on=None,
exclude=[], exclude_parse=[], exclude_introspect=[],
external_api=[], external_api_file=[], external_api_root=[],
-redundant_details=False, src_code_tab_width=8)
+redundant_details=False, src_code_tab_width=8, include_build_time=True)
def parse_arguments():
# Construct the option parser.
@@ -286,6 +286,10 @@ def parse_arguments():
action='store_true', dest='include_log',
help=(Include a page with the process log (epydoc-log.html)))
+generation_group.add_option('--no-include-build-time',
+action='store_false', dest='include_build_time',
+help=(Do not print the build time in the page footer, useful for reproducible builds.))
+
generation_group.add_option(
'--redundant-details',
action='store_true', dest='redundant_details',
@@ -558,6 +562,8 @@ def parse_configfiles(configfiles, optio
options.include_source_code = _str_to_bool(val, optname)
elif optname in ('include-log', 'include_log'):
options.include_log = _str_to_bool(val, optname)
+elif optname in ('include-build-time', 'include_build_time'):
+options.include_build_time = _str_to_bool(val, optname)
elif optname in ('redundant-details', 'redundant_details'):
options.redundant_details = _str_to_bool(val, optname)
Index: epydoc-3.0.1+dfsg/epydoc/docwriter/html.py
===
--- epydoc-3.0.1+dfsg.orig/epydoc/docwriter/html.py
+++ epydoc-3.0.1+dfsg/epydoc/docwriter/html.py
@@ -291,6 +291,9 @@ class HTMLWriter:
@type include_log: C{boolean}
@keyword include_log: If true, the the footer will include an
href to the page 'epydoc-log.html'.
+@type include_build_time: C{boolean}
+@keyword include_build_time: If true, the the footer will
+ include the build time.
@type src_code_tab_width: C{int}
@keyword src_code_tab_width: Number of spaces to replace each tab
with in source code listings.
@@ -358,6 +361,9 @@ class HTMLWriter:
self._include_log = kwargs.get('include_log', False)
Are we generating an HTML log page?
+self._include_build_time = kwargs.get('include_build_time', True)
+Are we including a build time?
+
self._src_code_tab_width = kwargs.get('src_code_tab_width', 8)
Number of spaces to replace each tab with in source code
listings.
@@ -1770,10 +1776,14 @@ class HTMLWriter:
tr
td align=left class=footer
if self._include_log:
-a href=epydoc-log.htmlGenerated by Epydoc
-$epydoc.__version__$ on $time.asctime()$/a
- else:
-Generated by Epydoc $epydoc.__version__$ on $time.asctime()$
+a href=epydoc-log.html
+ #endif
+Generated by Epydoc $epydoc.__version__$
+ if self._include_build_time:
+on $time.asctime()$
+ #endif
+ if self._include_log:
+/a
#endif
/td
td align=right class=footer
Index: epydoc-3.0.1+dfsg/man/epydoc.1
===
--- epydoc-3.0.1+dfsg.orig/man/epydoc.1
+++ epydoc-3.0.1+dfsg/man/epydoc.1
@@ -226,6 +226,12 @@ Generate an HTML page
.B epydoc\-log.html
containing all error and warning messages that are generated by
epydoc, and include it in the generated output.
+.TP
+.B \-\-no\-include\-build\-time
+Do not print the build time in the page footer. This is useful if
+you are trying to generate reproducible builds, where each build
+against a given version of a source tree produces exactly the
+same artifacts.
.RE
.PP
.\--
Bug#783326: please make the generated output reproducible
On Sat, Apr 25, 2015 at 6:19 PM, Jelmer Vernooij jel...@debian.org wrote: Package: python-epydoc Version: 3.0.1+dfsg-5 Severity: wishlist Tags: forwarded Forwarded: https://sourceforge.net/p/epydoc/bugs/367/ Hi, While working on the reproducible builds effort [1], we have noticed that pydoctor does not generate reproducible output. The attached patch adds an option to disable the outputting of a build time. Once applied, packages using epydoc will be able to be built reproducibly in our current experimental framework. Hi, Thanks. I''ll integrate this into the package sometime soon. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742295: sopwith: segmentation fault in single player mode (S)
Ok, I uploaded a new package. It seems to be working for me inside my chroot environment. Markus, when the new package hits the archive, please test and let me know if it resolves your problems. Jesse, just for future reference, I did need to make Debian-specific package changes (as suggested by Markus) because the standard Debian build process overrides the optimization compiler flags. Thanks, 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#742295: sopwith: segmentation fault in single player mode (S)
On Fri, Mar 21, 2014 at 5:15 PM, Markus Koschany a...@gambaru.de wrote: On 21.03.2014 22:26, Jesse Smith wrote: So far I have not been able to reproduce the bug, however I suspect I know what the problem is. The Sopwith makefile includes a flag for optimization (-O2). Recent versions of the GCC compiler (version 4.7, 4.8) have changed the way code gets optimized and I have seen it cause a couple of games to crash at start-up. Thank you very much for your quick response. You are right, the optimization is causing this problem. On Debian -O2 is the default optimization flag and gcc 4.8 still the default compiler. With your Makefile and without any additional compiler flags, I can't reproduce a crash either. The solution for Debian is to add this line to debian/rules: export DEB_BUILD_OPTIONS=noopt and sopwith will be built with -O0 optimization. I can confirm that this solves the issue. I'll put together a new package this weekend. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739905: gtml: Deprecation warnings with Perl v5.18.2
Package: gtml Version: 3.5.4-10 Severity: normal Tags: upstream Starting with perl v5.18.2, GTML emits warnings like this: defined(@array) is deprecated at /usr/bin/gtml line 1613 For the time being, I have disabled all deprecation warnings at the top of the gtml script. We need a better fix. Upstream doesn't appear to offer a bug tracking system at SourceForge as of today. I have pinged the maintainer privately. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739906: svn-buildpackage: Generated .changes file has file size mismatch
Subject: svn-buildpackage: Generated .changes file has file size mismatch Package: svn-buildpackage Version: 0.8.5 Severity: normal I'm filing this bug with svn-buildpackage because that's my interface into the build system. It seems likely the problem is some other utility down below svn-buildpackage, but I'm not sure how to find it. Feel free to reassign this somewhere else if you think that's appropriate. I maintain all of my packages with svn-buildpackage. Today, I've built and uploaded changes to every package. I had no problems with any of them other than epydoc. With epydoc, I'm getting a file size mismatch in the generated .changes file. Here's the command-line I'm using: svn-buildpackage --svn-noautodch --svn-move-to=/home/pronovic/projects/debstage/jessie/amd64/epydoc --svn-tag --svn-retag Once the build completes, I run lintian: lintian --version Lintian v2.5.21 lintian -I /home/pronovic/projects/debstage/jessie/amd64/epydoc/epydoc_3.0.1+dfsg-4_amd64.changes E: epydoc changes: file-size-mismatch-in-changes-file epydoc_3.0.1+dfsg-4.dsc 931 != 1160 E: epydoc changes: file-size-mismatch-in-changes-file epydoc_3.0.1+dfsg-4.dsc 931 != 1160 E: epydoc changes: file-size-mismatch-in-changes-file epydoc_3.0.1+dfsg-4.dsc 931 != 1160 E: epydoc changes: checksum-mismatch-in-changes-file md5 epydoc_3.0.1+dfsg-4.dsc Here's what the dsc file looks like on disk, showing that the size of 1160 bytes is correct: ls -l /home/pronovic/projects/debstage/jessie/amd64/epydoc/epydoc_3.0.1+dfsg-4.dsc -rw-rw-r-- 1 pronovic pronovic 1160 Feb 23 18:21 /home/pronovic/projects/debstage/jessie/amd64/epydoc/epydoc_3.0.1+dfsg-4.dsc When I look at the generated .changes file, the file length is correct in the Checksums-Sha1 and Checksums-Sha256 sections, but incorrect in the Files section: Checksums-Sha1: 51a9ecf8291ac13f43e571d30bb4b9c34dea05d2 1160 epydoc_3.0.1+dfsg-4.dsc a6bdd3dccef3db95503532247a018dac0a7f7b91 12892 epydoc_3.0.1+dfsg-4.debian.tar.xz 6770bf66933abdd088271ff561f831818619526f 218512 python-epydoc_3.0.1+dfsg-4_all.deb 3234b305a8a906c01f2031db3d1293c8f7ee297e 898542 epydoc-doc_3.0.1+dfsg-4_all.deb Checksums-Sha256: 06450f5382a588cd9de7807cffa6c50146e723218b563472569a7b0388b5b51c 1160 epydoc_3.0.1+dfsg-4.dsc 0f2ee0137f3c550ec287322346828628d72317722b074239feae5affe3c06ead 12892 epydoc_3.0.1+dfsg-4.debian.tar.xz 7dc9c3b03ae184f543f783031dd63603597eeedf6d79619804fb975550fafec9 218512 python-epydoc_3.0.1+dfsg-4_all.deb dc54ffc952ea60686451a47c8e8586506fbbf4796802645d19f90c48c4c502de 898542 epydoc-doc_3.0.1+dfsg-4_all.deb Files: 584c81f8310ad88dea8c38759b303ec1 931 python optional epydoc_3.0.1+dfsg-4.dsc aa24c6e9434891cd88cfe9a6641b5e18 12892 python optional epydoc_3.0.1+dfsg-4.debian.tar.xz 94ea2f9724447b92243cd73339394b22 218512 python optional python-epydoc_3.0.1+dfsg-4_all.deb ae0ffe56fda45881415903044e07fdef 898542 doc optional epydoc-doc_3.0.1+dfsg-4_all.deb I've never seen behavior like this before. I'm kind of at a loss. I build all of my other packages using the exact same svn-buildpackage command line, and everything works fine for those packages. All of the packages use source format 3.0, with very similar build processes. I'm executing the build in an amd64 schroot environment, which is up-to-date as of earlier today. Please let me know what I can do to help debug this. The code is in a private svn repository, but I could send you a tarball of the latest unreleased source tree, if you'd like. Thanks, KEN -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages svn-buildpackage depends on: ii devscripts 2.14.1 ii file1:5.17-0.1 ii libcapture-tiny-perl0.24-1 ii libfile-libmagic-perl 1.00-1 ii liblocale-gettext-perl 1.05-7+b2 ii libsvn-perl 1.8.8-1 ii liburi-perl 1.60-1 ii perl5.18.2-2 ii subversion 1.8.8-1 ii unp 2.0~pre7+nmu1 ii wget1.15-1 Versions of packages svn-buildpackage recommends: ii debhelper 9.20131227 svn-buildpackage suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737987: pychecker: False warning with complex format string parameters
On Fri, Feb 7, 2014 at 2:57 AM, Guido Günther a...@sigxcpu.org wrote: Package: pychecker Version: 0.8.19-8 Severity: normal It seems to fail to count the number of tuple arguments. Moving the 'if .. else' outside of the tuple works around this. I'll submit this upstream and tie the bug report back here into the BTS. However, upstream isn't very active, so it's unlikely this will be fixed any time soon. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738031: sopwith: missing menu icon entry
On Fri, Feb 7, 2014 at 9:07 AM, Markus Koschany a...@gambaru.de wrote: Package: sopwith Version: 1.8.1-3 Severity: wishlist User: pkg-games-de...@lists.alioth.debian.org Usertags: desktop-integration goals not-gamesteam Dear maintainer, currently sopwith does not supply a menu icon hence the game is not well integrated into the user's desktop environment. Please consider adding an icon entry to your menu file. I will make sure this is completed in time for the Jessie release. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718128: sopwith: FTBFS: /bin/bash: ./config.status: No such file or directory
On Sun, Jul 28, 2013 at 3:26 AM, David Suárez david.sephi...@gmail.com wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Thanks for the report. The problem is that config.status is not necessarily there on clean, and that causes 'make clean' to blow up. I don't know why this suddenly started happening, because all I'm really doing is calling dh_auto_clean, and it seemed to work fine when I did the debhelper 7 conversion back in April. It seems like I can solve the problem by touching config.status at the top of my clean rule, so I am going to upload a new package with that fix and keep an eye on it. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703477: cedar-backup2: Typo in manpage cback.1
On Wed, Mar 20, 2013 at 2:09 AM, Jan Medlock medlock-deb...@turboshower.net wrote: There is a typo in the manpage cback.1. The short option for --diagnostics should be -D, not -s. Thanks. It's interesting that I missed that in the manpage, given that the user manual and --help output are both correct. I'll probably integrate this change upstream rather than in the Debian package. It'll show up at the same time as the fix for #703476. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703476: cedar-backup2: Action split is broken by new output format of /usr/bin/split
On Wed, Mar 20, 2013 at 2:06 AM, Jan Medlock medlock-deb...@turboshower.net wrote: The split action is broken due to a change in the format of the output of /usr/bin/split. The leading quote is now a forward tick instead of a backtick: Thanks. The patch looks backwards-compatible with older versions of split, which is great. I'll most likely apply this patch upstream rather than in the Debian package. I'll try to get a new version built later this weekend. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692873: unblock: epydoc/3.0.1-13
Control: tags 692733 + fixed pending On Fri, Nov 09, 2012 at 11:37:46PM -0400, David Prévot wrote: Le 09/11/2012 22:31, Kenneth Pronovici a écrit : Please unblock package epydoc. The only change is to remove one outdated file is under the non-free CC-BY-NC-SA license. This closes release-critical bug #692733 You need to strip out the non-free file from the source tarball, and prepare a repacked one (e.g. 3.0.1+dfsg). Your patch only removes the non-free file when applying the patch, but it's still present in the source package. Ok, I have repackaged the upstream tarball and uploaded 3.0.1+dfsg-1. Below is a debdiff between 3.0.1-12 and 3.0.1+dfsg-1. Thanks, KEN -- debdiff epydoc_3.0.1-12/epydoc_3.0.1-12.dsc epydoc_3.0.1+dfsg-1/epydoc_3.0.1+dfsg-1.dsc diff -Nru epydoc-3.0.1/debian/changelog epydoc-3.0.1+dfsg/debian/changelog --- epydoc-3.0.1/debian/changelog 2012-03-12 13:18:04.0 -0500 +++ epydoc-3.0.1+dfsg/debian/changelog 2012-11-10 10:18:09.0 -0600 @@ -1,3 +1,21 @@ +epydoc (3.0.1+dfsg-1) unstable; urgency=low + + * Package a new DFSG-free upstream tarball (closes: #692733). +- The new tarball removes non-free doc/pycon-epydoc.html +- Remove debian/patches/remove-cc-by-nc-sa.patch; no longer needed +- Add opts=dversionmangle in debian/watch per Lintian recommendation + + -- Kenneth J. Pronovici prono...@debian.org Sat, 10 Nov 2012 16:04:44 + + +epydoc (3.0.1-13) unstable; urgency=low + + * Update copyright date for Debian package files in debian/copyright. + * Remove non-free doc/pycon-epydoc.html from the package (closes: #692733). +- Remove reference to doc/pycon-epydoc.html from debian/copyright +- Add new patch debian/patches/remove-cc-by-nc-sa.patch + + -- Kenneth J. Pronovici prono...@debian.org Thu, 08 Nov 2012 09:35:39 -0600 + epydoc (3.0.1-12) unstable; urgency=low * Update to machine-readable debian/copyright file format, version 1.0. diff -Nru epydoc-3.0.1/debian/copyright epydoc-3.0.1+dfsg/debian/copyright --- epydoc-3.0.1/debian/copyright 2012-03-12 16:31:43.0 -0500 +++ epydoc-3.0.1+dfsg/debian/copyright 2012-11-09 19:55:01.0 -0600 @@ -11,12 +11,6 @@ Copyright: 2007 Daniele Varrazzo License: Expat -Files: doc/pycon-epydoc.html -Copyright: 2004 Edward Loper -License: CC-BY-NC-SA - This work (in all its forms) is licensed under the Creative Commons - Attribution-NonCommercial-ShareAlike License. - Files: doc/custom.css doc/docutils.css Copyright: Public Domain License: public-domain @@ -24,7 +18,7 @@ Files: debian/* Copyright: 2002 Moshe Zadka mos...@debian.org - 2003-2010 Kenneth J. Pronovici prono...@debian.org + 2003-2012 Kenneth J. Pronovici prono...@debian.org License: Copying and distribution of these files, with or without modification, is permitted in any medium without royalty provided the copyright notice and diff -Nru epydoc-3.0.1/debian/watch epydoc-3.0.1+dfsg/debian/watch --- epydoc-3.0.1/debian/watch 2011-03-02 08:58:31.0 -0600 +++ epydoc-3.0.1+dfsg/debian/watch 2012-11-10 10:17:28.0 -0600 @@ -1,3 +1,4 @@ # This watch file uses the qa.debian.org redirector so that SourceForge URLs work version=3 +opts=dversionmangle=s/\+dfsg// \ http://sf.net/epydoc/epydoc-(.*)\.tar\.gz diff -Nru epydoc-3.0.1/doc/pycon-epydoc.html epydoc-3.0.1+dfsg/doc/pycon-epydoc.html --- epydoc-3.0.1/doc/pycon-epydoc.html 2008-01-30 08:13:59.0 -0600 +++ epydoc-3.0.1+dfsg/doc/pycon-epydoc.html 1969-12-31 18:00:00.0 -0600 @@ -1,103 +0,0 @@ -!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN -html - head -titleEpydoc: PyCon 2004/title -link rel=stylesheet href=epydoc.css type=text/css/ - /head -body -div class=body -h1 Epydoc: PyCon 2004 /h1 - -h2Abstract/h2 - -p Epydoc is a tool for generating API documentation for Python -modules, based on their docstrings. It supports several output -formats (including HTML and PDF), and understands four different -markup languages (Epytext, Javadoc, reStructuredText, and plaintext). -A wide variety of ifields/i can be used to supply specific -information about individual objects, such as descriptions of function -parameters, type signatures, and groupings of related objects. /p - -h2 Presentation and Paper /h2 - -table class=tech border=1 cellpadding=3 cellspacing=0 - tr -th class=tech width=25%Video (Quicktime)/th -th class=tech width=25%Audio (MP3)/th -th class=tech width=25%Slides/th -th class=tech width=25%Paper/th - /tr - tr -td class=tech - a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-large.mov; - Large (Fast DSL)/a/td -td class=tech - a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-64kbps.mp3; - High Quality (64 kbps)/a/td -td class=tech - a href=epydoc-slides.pdf - Acrobat (PDF)/a/td -td class=tech - a href=pycon-epydoc.pdf - Acrobat
Bug#692873: unblock: epydoc/3.0.1-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package epydoc. The only change is to remove one outdated file is under the non-free CC-BY-NC-SA license. This closes release-critical bug #692733 (filed yesterday, 08 Nov 2012). I have attached a debdiff below. unblock epydoc/3.0.1-13 Thanks, KEN = debdiff epydoc_3.0.1-12/epydoc_3.0.1-12.dsc epydoc_3.0.1-13/epydoc_3.0.1-13.dsc = diff -Nru epydoc-3.0.1/debian/changelog epydoc-3.0.1/debian/changelog --- epydoc-3.0.1/debian/changelog 2012-03-12 13:18:04.0 -0500 +++ epydoc-3.0.1/debian/changelog 2012-11-09 19:55:01.0 -0600 @@ -1,3 +1,12 @@ +epydoc (3.0.1-13) unstable; urgency=low + + * Update copyright date for Debian package files in debian/copyright. + * Remove non-free doc/pycon-epydoc.html from the package (closes: #692733). +- Remove reference to doc/pycon-epydoc.html from debian/copyright +- Add new patch debian/patches/remove-cc-by-nc-sa.patch + + -- Kenneth J. Pronovici prono...@debian.org Thu, 08 Nov 2012 09:35:39 -0600 + epydoc (3.0.1-12) unstable; urgency=low * Update to machine-readable debian/copyright file format, version 1.0. diff -Nru epydoc-3.0.1/debian/copyright epydoc-3.0.1/debian/copyright --- epydoc-3.0.1/debian/copyright 2012-03-12 16:31:43.0 -0500 +++ epydoc-3.0.1/debian/copyright 2012-11-09 19:55:01.0 -0600 @@ -11,12 +11,6 @@ Copyright: 2007 Daniele Varrazzo License: Expat -Files: doc/pycon-epydoc.html -Copyright: 2004 Edward Loper -License: CC-BY-NC-SA - This work (in all its forms) is licensed under the Creative Commons - Attribution-NonCommercial-ShareAlike License. - Files: doc/custom.css doc/docutils.css Copyright: Public Domain License: public-domain @@ -24,7 +18,7 @@ Files: debian/* Copyright: 2002 Moshe Zadka mos...@debian.org - 2003-2010 Kenneth J. Pronovici prono...@debian.org + 2003-2012 Kenneth J. Pronovici prono...@debian.org License: Copying and distribution of these files, with or without modification, is permitted in any medium without royalty provided the copyright notice and diff -Nru epydoc-3.0.1/debian/patches/remove-cc-by-sc-na.patch epydoc-3.0.1/debian/patches/remove-cc-by-sc-na.patch --- epydoc-3.0.1/debian/patches/remove-cc-by-sc-na.patch1969-12-31 18:00:00.0 -0600 +++ epydoc-3.0.1/debian/patches/remove-cc-by-sc-na.patch2012-11-09 19:55:01.0 -0600 @@ -0,0 +1,109 @@ +# Description: Remove files licensed under the non-free CC-BY-NC-SA license. +# Bug-Debian: http://bugs.debian.org/692733 +# Author: Kenneth J. Pronovici prono...@debian.org +--- a/doc/pycon-epydoc.html /dev/null +@@ -1,103 +0,0 @@ +-!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN +-html +- head +-titleEpydoc: PyCon 2004/title +-link rel=stylesheet href=epydoc.css type=text/css/ +- /head +-body +-div class=body +-h1 Epydoc: PyCon 2004 /h1 +- +-h2Abstract/h2 +- +-p Epydoc is a tool for generating API documentation for Python +-modules, based on their docstrings. It supports several output +-formats (including HTML and PDF), and understands four different +-markup languages (Epytext, Javadoc, reStructuredText, and plaintext). +-A wide variety of ifields/i can be used to supply specific +-information about individual objects, such as descriptions of function +-parameters, type signatures, and groupings of related objects. /p +- +-h2 Presentation and Paper /h2 +- +-table class=tech border=1 cellpadding=3 cellspacing=0 +- tr +-th class=tech width=25%Video (Quicktime)/th +-th class=tech width=25%Audio (MP3)/th +-th class=tech width=25%Slides/th +-th class=tech width=25%Paper/th +- /tr +- tr +-td class=tech +- a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-large.mov; +- Large (Fast DSL)/a/td +-td class=tech +- a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-64kbps.mp3; +- High Quality (64 kbps)/a/td +-td class=tech +- a href=epydoc-slides.pdf +- Acrobat (PDF)/a/td +-td class=tech +- a href=pycon-epydoc.pdf +- Acrobat (PDF)/a/td +- /tr +- tr +-td class=tech +- a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc.mov; +- Medium (Slow DSL)/a/td +-td class=tech +- a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc.mp3; +- Low Quality (16 kbps)/a/td +-td class=tech +- a href=epydoc-slides.ppt +- Powerpoint (PPT)/a/td +-td class=tech +- a href=pycon-epydoc.ps +- PostScript (PS)/a/td +- /tr +- tr +-td class=tech +- a href=http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-small.mov; +- Small (Modem)/a/td +-td class=technbsp;/td +-td class=technbsp;/td +-td class=technbsp;/td +- /tr +-/table +-!--br
Bug#692733: src:epydoc: non-free files in main (CC-BY-NC-SA)
On Thu, Nov 8, 2012 at 9:48 AM, Edward Loper edlo...@gmail.com wrote: Epydoc itself is released under the MIT license: http://epydoc.sourceforge.net/license.html The page in question is specifying the license for the powerpoint slides and video from my presentation at PyCon 2004. I'm not sure whether those slides/video are curently included in the debian package. I would think not -- i.e., I believe that that page just has pointers to externally hosted files such as http://www.pycon.org/dc2004/talks/files/epydoc/pycon-epydoc-large.mov. So I'm not sure what the problem is. Hi Edward, The Debian package contains just one file under this license: doc/pycon-epydoc.html, which is basically a short pointer to the other slides/videos on the pycon.org website (those slides/videos are not included in the Debian package). The simplest thing for now is to just remove that one file from the Debian package, since it doesn't really need to be there. That will resolve the bug. I've already got a patch checked into my revision control. I'll upload a new Debian package later today when I can get access to my build environment. I'll also coordinate with the release managers to get the new changes accepted into Wheezy (since this is considered a release-critical bug and we're in freeze). 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#672796: Minor code update
On Wed, Sep 19, 2012 at 6:42 PM, Jesse Smith jessefrgsm...@yahoo.ca wrote: I've just uploaded a new version of Sopwith, version 1.7.5. This might be a good opportunity to merge the above patch. Yep, agreed. The change is already in revision control on my end, just waiting for another reason to upload. 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#685055: Assertion when generating epydoc information for virtinst
On Thu, Aug 16, 2012 at 2:33 AM, Guido Günther a...@sigxcpu.org wrote: Package: python-epydoc Version: 3.0.1-12 Severity: normal Hi, generating epydoc information for virtinst gives this assertion: Ok, thanks for reporting the bug. I will file this with upstream and tie the bug back here. Upstream is not very active these days, so I'm not sure when it will be fixed. I would be happy to accept a patch if you can figure out how to fix it yourself. KEN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672796: sopwith: spelling mistake in long description (patch)
Thanks. I'll apply this soon in revision control. I probably won't upload until something more important changes (a policy version or something like 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#666342: cproto: FTBFS: make[1]: *** No targets specified and no makefile found. Stop.
On Fri, Mar 30, 2012 at 4:28 AM, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Source: cproto Version: 4.7j-4 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
