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:
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
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
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
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
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 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
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 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
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 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
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]
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 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.
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
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.
severity 938909 serious
thanks
zope.interface build-depends on python-zope.event which is no longer built by
the zope.event source package.
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
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.
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
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.
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
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
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
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:
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
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 805799 serious
thanks
Upping the severity to serious as this can't be built without using
cruft packages.
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
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
30 matches
Mail list logo
