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
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
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
>
>
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
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
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
Ok, this is on my list. Not sure exactly how soon I'll get to it, but it
won't be too long.
KEN
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
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
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
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
Thanks. That sounds like a good plan.
KEN
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
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
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:
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
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
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
> 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.
Ok, thank you for letting me know. I'll proceed when I have time.
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.
> >
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
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
> 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
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
(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
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
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.
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
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
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
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.
>
> Thanks! I appreciate the follow-up.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi Val,
I'll apply both of these patches and upload sometime soon, hopefully
within the next few days.
KEN
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
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
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
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.
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
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.
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
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
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.
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
(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
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
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
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,
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
1 - 100 of 292 matches
Mail list logo
