On 15/04/2025 16:07, Jing Luo wrote:
X-Debbugs-Cc: debian-am...@lists.debian.org, debian-...@lists.debian.org,
debian-powe...@lists.debian.org, debian-ri...@lists.debian.org
I understand CC'ing the porters when you have an issue that is specific to the
port, but
if it's failing on every damn
severity 937009 serious
thanks
mercurial can no longer be built in testing because of a build-dependency on
python-docutils which has been removed.
This is fixed in unstable, but mercurial is blocked from migrating to testing
because it
declares a conflicts on mercurial-crecord (<= 0.20151121-
severity 938909 normal
thanks
Version 4.6.0-2 eliminates the unsatisfiable build-dependency and has migrated
to testing. Returning this bug to normal severity.
On 07/12/2019 15:09, Håvard Flaget Aasen wrote:
If you still wish to disable tests for python 2, you might be looking for this
export PYBUILD_DISABLE_python2=test
That line in debian/rules should work.
You have some more options here: https://wiki.debian.org/Python/Pybuild
and perhaps the manp
On 07/12/2019 07:47, peter green wrote:
It would be preferable to only disable the testsuite for python2, but I have no
idea how to do that, so my current debdiff disables the testsuite completely, I
also ran into an issue with the package's clean target not cleaning up properly.
zope.interface is currently rc buggy because of an unsatisfiable
build-depenency on python-zope.event, the package is also orphaned.
The package is a key package, so the issue won't be dealt with by autoremovals,
furthermore the python-zope.interface package has quite a stack of reverse
depend
severity 938909 serious
thanks
zope.interface build-depends on python-zope.event which is no longer built by
the zope.event source package.
severity 937666 serious
thanks
python-coverage-test-runner depends on the python-coverage binary package which
is no longer built by the python-coverage source package.
Package: zope.testing
Version: 4.6.2-2
Severity: serious
https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.testing/2966135/log.gz
autopkgtest [06:13:32]: test all: [---
Traceback (most recent call last):
File "/usr/bin/zope-testrunner", line 9, in
load_ent
Package: zope.testrunner
Version: 4.4.9-3
Severity: serious
autopkgtest [06:13:47]: test all-2: [---
bash: /tmp/autopkgtest-lxc.v65a_j_9/downtmp/build.cMu/src/debian/tests/all-2:
/usr/bin/python: bad interpreter: No such file or directory
autopkgtest [06:13:47]: test all-2:
severity 938919 serious
thanks
python-zope.testrunner in testing depends on python-zope.exceptions which has
already been dropped by the zope.exceptions source package.
This has been addressed in unstable by dropping the python-zope.testrunner
binary package, however that fix cannot currently
Tags 897114 +patch
thanks
This was blocking a transition in raspbian, so I whipped up a fix. Debdiff at
http://debdiffs.raspbian.org/main/i/ifrit/ifrit_4.1.2-5%2brpi1.debdiff , no
intent to NMU in Debian.
The only tricky bit was that there seems to have been a typo in debian/rules,
there was
I just took a look at the xpdf build failure.
Unfortunately I was unable to find documentation on the "object" changes but
after reading the sourcecode I was able to figure out that.
1. It appears "output" objects are now returned by value rather than being
passed by pointer.
2. Freeing object
Package: github-backup
Version: 1.20170301-1
Severity: serious
x-debbugs-cc: barak+...@pearlmutter.net
github-backup build-depends on haskell-github << 0.16.0 but sid has 0.16.0-1
and buster doesn't have the package at all. So github-backup's build-depends are not
satisfiable in either unstable
tags 805799 +patch
thanks
Ubuntu have a fix for this.
https://patches.ubuntu.com/k/kst/kst_2.0.3-4ubuntu3.patch
I cleaned up the changelog and removed ubuntus maintainer changes and
uploaded to raspbian. Debdiff of that at.
http://debdiffs.raspbian.org/main/k/kst/kst_2.0.3-4%2brpi1.debdiff
severity 805799 serious
thanks
Upping the severity to serious as this can't be built without using
cruft packages.
Package: openmsx
Severity: serious
Tags: patch
x-debbugs-cc: wij...@debian.org
openmsx FTBFS in unstable with the following error.
Compiling serialize.cc...
g++ \
-MP -MMD -MF derived/x86_64-linux-debian/dep/serialize.d \
-o derived/x86_64-linux-debian/obj/serial
Note: I have no particular relationship to this package, i'm just trying to
reduce the number of uninstallable packages in armhf testing.
configure.ac:210: warning: macro `AM_PATH_ALSA' not found in library
configure.ac:210: error: possibly undefined macro: AM_PATH_ALSA
If this token and ot
Note: i'm just doing flyby investigation of rc bugs. I have no relationship to
either doko or this package.
This package is building ok for me.
Same here
Having looked through a number of these bugs I get the impression that doko was a
bit careless when doing his mass bug filing. Most are rea
So, um, just asking here: if a package fails to build on one particular
architecture due to a bug in gcc, is that a reason to remove it from
testing
If a few minor packages are blocking a transition for any reason then
it is very likely they will be removed from testing. This isn't exactly
ideal
tags 575856 +patch
thanks
From my testing it appears to be sufficiant to simply drop the
build-dependency on x-dev to fix this.
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http:
tags 537034 +patch
thanks
I've just done a quick check in pbuilder and adding cpio to the build
depends indeed seems to be sufficiant to make the package build.
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
tags 527532 +patch
thanks
Add "#include " to the top of the list of includes in
include/specter/specter.h to fix this bug.
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Sandro Tosi wrote:
On Mon, May 4, 2009 at 13:06, peter green wrote:
tags 526847 +patch
thanks
debhelper seems to be the only missing build-dependency (tested in pbuilder)
so adding it should be enough to fix this bug.
This is an orphaned packages: are you interested in preparing a
tags 526847 +patch
thanks
debhelper seems to be the only missing build-dependency (tested in
pbuilder) so adding it should be enough to fix this bug.
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
tags 518858 +patch
thanks
A bit of grepping determined the following
linux/limits.h defines an ARG_MAX
however the various headers that include linux/limits.h explicitly state
that the version from the linux kernel headers is wrong and explicitly
undefine it.
/usr/include/bits/xopen_lim.h st
tags 493411 +patch
thanks
replace the parseopt= and sys= lines near the top of the makefile with
the following to fix this bug
parseopt=parseopt/confread.o parseopt/lex.o parseopt/parse.o
sys=sys/exit.o sys/xalloc.o sys/log.o sys/communication.o
sys/sighandlers.o sys/processtitle.o sys/users.
I think adding the following to the work target in debian/rules just
before the last line should make this package build succesfully
cp /usr/share/misc/config.sub work.tmp
cp /usr/share/misc/config.guess work.tmp
Unfortunately since I have been unable to reproduce the problem (it
seems to be s
tags 491385 +patch
thanks
replace xlibs-data with xbitmaps in the build dependencies to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 477011 +patch
thanks
patch is attatched. just add it to the quilt series.
Index: adonthell-0.3.4.cvs.20050813/src/py_adonthell_wrap.cc
===
--- adonthell-0.3.4.cvs.20050813.orig/src/py_adonthell_wrap.cc 2008-04-20 22:54:27.00
30 matches
Mail list logo
