Package: pythoncard
Severity: grave
Justification: renders package unusable
I can't manage to install pythoncard due to a dependency on a missing
package (libwxgtk2.5.3-python). Here is the steps I made:
Yes, this has already been reported (but against python2.3-pythoncard).
It appears
When trying to install the python-epydoc package I get the
following error:
Setting up python-epydoc (2.1-5) ...
dpkg: error processing python-epydoc (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
python-epydoc
E:
It looks like a new wxPython package has appeared, but only in
experimental. I'm not sure what I'm going to do with this (possibly
build packages for experimental),i but in any case I won't be able to
put a pythoncard package into unstable until wxPython appears back in
unstable.
KEN
--
Package: ncompress
Version: 4.2.4-15
Severity: grave
Tags: security
Hi!
There is a recent report about insecure temporary files in ncompress,
similar to the recent advisories about gzip:
http://www.zataz.net/adviso/ncompress-09052005.txt
Can you please check this? There is no
On 11/12/06, Florent Bayle [EMAIL PROTECTED] wrote:
package babygimp
tags 395917 + patch
thanks
Hi,
here is a patch to fix this bug.
Hi, Florent,
Thanks for the patch!
You definitely solved the problem with starting the script. I made a
few other changes, and was then able to successfully
Ken suggest to report this as a but, therewith it will not be forgotten.
:)
Thanks for filing the bug. I'll ping Ron if a new 2.5 package doesn't
appear in the next few weeks.
KEN
--
Kenneth J. Pronovici [EMAIL PROTECTED]
pgpxxGeP5fttC.pgp
Description: PGP signature
Hi,
I just received bug #395486, which says that the sources for ncompress
are not available. Later, the submitter notes that he found them in
non-free. (This package has been in main since version 4.2.4-15 on 25
August 2004.)
It seems that the changelog, the diff, the dsc and the copyright
Well, that explains it. Odd, I moved it out of non-free quite a while ago.
KEN
On 10/27/06, Holger Levsen [EMAIL PROTECTED] wrote:
Hi,
ftp://ftp.de.debian.org/debian/pool/non-free/n/ncompress/ has the sources.
regards,
Holger
--
Kenneth J. Pronovici [EMAIL PROTECTED]
Well, that's pretty odd. It seems to exist for stable, but not
unstable. The source hasn't changed in more than a decade, so there
haven't been any new uploads lately. :)
I'll see what I can figure out. I may reassign this over to the ftp
team or something. Thanks for pointing it out.
KEN
On 10/27/06, Steve Langasek [EMAIL PROTECTED] wrote:
On Fri, Oct 27, 2006 at 09:08:47AM -0500, Kenneth Pronovici wrote:
Well, that explains it. Odd, I moved it out of non-free quite a while ago.
On 10/27/06, Holger Levsen [EMAIL PROTECTED] wrote:
ftp://ftp.de.debian.org/debian/pool/non
Package: babygimp
Version: 0.42-1
Severity: grave
Justification: renders package unusable
I heard about this in private email from a user a month or so ago. I
realized today while fixing #395577 that this user never bothered to
file an official bug report as requested (I was out of the country
On 10/27/06, Steve Langasek [EMAIL PROTECTED] wrote:
On Fri, Oct 27, 2006 at 01:29:03PM -0500, Kenneth Pronovici wrote:
dak cannot cleanly handle migrating a source package from one suite to
another without a version change. Please upload the package with a new
upstream version number (even
Odd, I filed the same bug just minutes before you did. I'll mark this
one as a duplicate.
Yeah, I agree, it does look like a perl-tk incompatibility.
Thanks for the report.
KEN
On 10/28/06, Wolfgang Karall [EMAIL PROTECTED] wrote:
Package: babygimp
Version: 0.42-1
Severity: grave
On 10/28/06, Kenneth Pronovici [EMAIL PROTECTED] wrote:
On 10/28/06, Wolfgang Karall [EMAIL PROTECTED] wrote:
On Sat, 2006-10-28 at 13:21 -0500, Kenneth Pronovici wrote:
Odd, I filed the same bug just minutes before you did. I'll mark this
one as a duplicate.
Yeah, consecutive bug
On Feb 8, 2008 9:10 AM, Guido Guenther [EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2008 at 10:39:27AM -0600, Kenneth Pronovici wrote:
Maybe we should clone 406357? You can fix your FTBFS by removing
pychecker from debian/rules, and I'll keep this bug against pychecker
open until we
On Sun, Apr 20, 2008 at 10:43 AM, Lucas Nussbaum
[EMAIL PROTECTED] wrote:
Package: pychecker
Version: 0.8.17-8
Severity: serious
User: [EMAIL PROTECTED]
Usertags: qa-ftbfs-20080419 qa-ftbfs
Justification: FTBFS on i386
During a rebuild of all packages in sid, your package failed to
On 12/27/06, Gunnar Wolf [EMAIL PROTECTED] wrote:
Hi,
Any update on babygimp's status? If it no longer works and cannot be
fixed, maybe the best course of action is to remove it from Etch?
AFAIK, babygimp should already be removed from Etch per an email I
sent earlier to the release team. I
Interesting. It worked at my last upload.
The unit tests are still valid, and the only problem is the location
of the file the warning is coming from. I'll change the test
expectations and upload later this weekend.
KEN
On Jan 12, 2008 4:21 AM, Lucas Nussbaum [EMAIL PROTECTED] wrote:
Hi,
I'll take a look at this, but it's unlikely I'll find a solution very
soon. Upstream doesn't have a lot of time right now, and I'm not an
expert in the codebase (though sometimes I do get lucky).
I think that it's probably best for you to fix your FTBFS by removing
pychecker from
On Jan 14, 2008 10:36 AM, Guido Guenther [EMAIL PROTECTED] wrote:
Hi,
On Sat, Jan 12, 2008 at 10:34:44AM -0600, Kenneth Pronovici wrote:
I'll take a look at this, but it's unlikely I'll find a solution very
soon. Upstream doesn't have a lot of time right now, and I'm not an
expert
Ok, thanks for filing the bug. I would be happy to apply a patch if one
becomes available.
KEN
--
Kenneth J. Pronovici prono...@ieee.org
http://www.cedar-solutions.com/
Hi,
I haven't had time to look at this yet, and I might not have time until
after the holidays due to work schedule and travel. Sorry about that.
I have pinged Edward (upstream) to see whether I can get some feedback from
him before I consider applying the patch. I don't have a a problem
Don't worry about the unit tests for now. It's been a while since I looked
at this code, and I thought I recalled a unit test suite that I was running
as part of the package build process. I was thinking of pychecker instead.
KEN
Thomas,
Ok, I have finally had time to review your patch and test it. Sorry this
took me a while.
This bug is now linked with 560624, 560659 and 560606, which are FTBFS bugs
for python-couchdb, dbus-python and pymvpa. I was able to reproduce the
build problems with those packages using
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 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
On Fri, Mar 30, 2012 at 4:29 AM, Lucas Nussbaum
lu...@lucas-nussbaum.net wrote:
Source: sopwith
Version: 1.7.4-5
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20120330 qa-ftbfs qa-ftbfs-buildarch
Justification: FTBFS on amd64
Ok, looks like I can
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
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,
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
Thanks. That sounds like a good plan.
KEN
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
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
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
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:
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
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
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
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
(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
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
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
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.
> >
Ok, thank you for letting me know. I'll proceed when I have time.
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
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
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
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
48 matches
Mail list logo
