Package: python-greenlet
Version: 0.3.1-2
Severity: serious
x-debbugs-cc: storv...@gmail.com
Building python-greenlet in testing fails.
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC
-I/usr/include/python2.6_d -c greenlet.c -o
Just to add I tried built the version of python-greenlet from TPU with
the version of platform/switch_arm32_gcc.h from 0.4.0 and it seems to
build ok on armel and raspbian (both of which it had failed on before).
I have uploaded a package with this change to raspbian. It can be found
at
I searched for the bug on google an according to a chromium engineer
is a problem related to the linker. I hope it helps.
snip
the problem is cause by a gold bug - you need to use gold from
binutils 2.22 or later
We already have binutils 2.22 in wheezy/sid.
Still i'm tempted to try a build
package: chromium
severity: grave
version: 22.0.1229.94~r161065-3
Chromium segfaults on startup on armhf. I got a backtrace but it isn't a
very informative one :(
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from
/usr/lib/debug/usr/lib/chromium/chromium...done.
done.
The proposed patch defines a third option
USE(JSVALUE64W)
which we use *only* on ia64.
It uses an encapsulated union without any trick for the variant data
type. This is portable but
- the data type is 128-bits wide,
- Enabling JIT compiler isn't possible - that's not that bad; ia64
doesn't
Package: clang
Version: 3.0-6
Severity: grave
Tags: patch
x-debbugs-cc: debian-rele...@lists.debian.org
RT in cc because of proposed TPU upload.
Unfortunately it seems that the changes in 3.0-6 fixed clang on armel
but not on armhf.
root@debian:/# clang -v test.c
Debian clang version 3.0-6
David Prévot wrote:
Control: tags -1 patch
Control: severity -1 serious
Justification: Policy 3.9.1
Dear Debian maintainer,
On Monday, August 27, 2012, I notified you of the beginning of a review
process concerning debconf templates for fpc.
The debian-l10n-english contributors have now
Le dimanche 29 juillet 2012 23:31:39 Bart Martens, vous avez écrit :
Hi Rémi,
The patch fixes the bug. Why not simply use it ? Shall I upload an NMU ?
It does not address the real issue.
It must be pure luck that automake accepts it.
I don't know enough about automake internals to
I'd like to mark this as won't fix because we're dropping the scons
build system. The latest version of supercollider 3.5.x (which I'm
currently asking debian-multimedia maintainers to upload) uses cmake
instead which is much less mess.
Supercollider 1:3.5.2-1 was uploaded just before the
retitle 683011 FTBFS on arm* and kfreebsd*: libnss-ldap missing files
(debian/tmp/usr/lib/*/*), aborting
tags 683011 +patch
thanks
It appeared the arm* and kfreebsd* failures are the same or at least
related. At the very least other behaviours seem the same on those
architectures.
Specifically
Emmanuel Kasper: can you tell us if the patch in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;bug=683011
fixes libnss-ldap on kfreebsd for you?
Steve Langasek wrote:
My opinion is that the upstream rules on naming the libnss_ldap file are a
horror show. ;) Your proposed fix looks
I've re-install Debian/kfreebsd inside virtualbox. And does get the
FTBFS. But strangely, linux arches does get a correct multiarch path but
the kfreebsd-i386 didn't.
Any suggestions?
As a quick and dirty solution you could put code in debian/rules that
checks where
the files are and if needed
tags 666589 +patch
thanks
I'm running a derivative distribution called raspbian to provide a
hardfloat distribution for the Pi and one of our users asked for this
package so I went looking for a soloution to make it build.
And I've found one but it's kinda ugly, it would require a trip
01234567890123456789012345678901234567890123456789012345678901234567890123456789
Current version 3.1.0~rc2-1 seems ok on all archs, but for ppc where it fails
to build with something that looks like a compiler issue.
Based on https://bugs.launchpad.net/ubuntu/+source/spatialite/+bug/1012976 and
Usually qreal is double (which is why it works), but on ARM systems qreal
is float instead.
This causes sc to fail to build on ARM systems.
---
There is a similar problem with some reference parameters in QcMultislider
.cpp which I have added the fix for to this patch -- Peter Green
Package: pegasus-wms
Version: 4.0.1+dfsg-6
Severity: serious
Tags: patch
pegasus-wms FTBFS with the new subversion
[exec] g++ -ffor-scope -Wall -O2 -m64 -ggdb
-DMACHINE_SPECIFIC=linux -DLINUX -DMAJOR=2
-DHAS_SVNVERSION=\Unversioned directory\ pegasus-keg.cc -c -o
pegasus-keg.o
Package: fritzing
Version: 0.7.4b+dfsg-3
Severity: serious
Tags: patch
Your package failed to build on the armel and armhf autobuilders.
src/sketch/sketchwidget.cpp:7075:28: error: no matching function for call to
'QPen::setDashPattern(QVectordouble)'
src/sketch/sketchwidget.cpp:7075:28:
tags 676094 +patch
thanks
Thia package failed to build after being imported to raspbian and I
needed to get it building so I took a look.
I managed to fix the include file not found issue with some makefile hackery
Unfortunately after I fixed that I got
/bin/bash ../../libtool --tag=CXX
Package: camomile
severity: serious
version: 0.8.4-1
Building camomile with dpkg-buildpackage -B and recent dpkg-dev (which
uses build-arch) fails with the following error.
dh_installman -plibcamomile-ocaml-dev
debian/xml-man/en/camomilecharmap.1: No such file or directory at
Package: libxs
Version: 1.2.0-1
Severity: serious
Tags: patch
Your package fails to build on armhf with the following error.
CXXlibxs_la-mailbox.lo
/tmp/cchN2ucw.s: Assembler messages:
/tmp/cchN2ucw.s:229: Error: thumb conditional instruction should be in IT block
-- `strexeq ip,r7,[r3]'
package: ruby-redcarpet
severity: serious
version: 2.1.1-1
tags: patch
ruby-redcarpet failed to build on all autobuilders that had tried to build it
at the time of writing and also failed in my amd64 pbuilder.
Rewriting shebang line of
spelling: it should be one piece not one peice
Ok
Very interesting changes. Have you discussed this with upstream?
No
If not, that's fine; no need to slow down the package update in this
case. But be sure to eventually.
Ok, i'll send them the patch.
typo? Should this be:
#ifndef i_reserved2
tags 673215 +patch
thanks
The attached package makes the package build with dpkg-buildpackage
-A, dpkg-buildpackage -B and regular dpkg-buildpackage. I have not
done any further testing of the resulting packages.
diff -ur libsvm-3.1/debian/rules libsvm-3.1.new/debian/rules
---
Package: linux-atm
Version: 1:2.5.1-1.3
Severity: serious
Tags: patch
From my wheezy amd64 chroot
root@debian:/linux-atm-2.5.1# dpkg-buildpackage -B
dpkg-buildpackage: source package linux-atm
dpkg-buildpackage: source version 1:2.5.1-1.3
dpkg-buildpackage: source changed by Marco d'Itri
tags 669485 +patch
thanks
The attatched patch to debian/rules makes this package build again.
--- glade-3-3.6.7/debian/rules 2011-07-27 01:01:14.0 +
+++ glade-3-3.6.7.new/debian/rules 2012-05-25 23:35:07.0 +
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+export GTK_LIBS =
package: maelstrom
version: 1.4.3-L3.0.6-10
severity: serious
Recently maelstrom moved from non-free to main. Unfortunately when a
package makes such a move without a new upstream version the
orig.tar.gz stays in non-free leaving an incomplete source package in main.
After asking in
You tagged this bug as pending months ago, are you still planning to upload? do
you need a sponsor?
Tags 663674 +patch
Thanks
Patch is attatched just add it to the quilt series.
Description: Add typecast to avoid call by var has to match exactly error
The typecast added is sane as self in the inherited constructor will be a
reference to the correct type.
Author: Peter Michael Green
Tags 665670 +patch
Thanks
The attatched patch removes -Werror from the cflags and hence makes the package
build.
03_disable_werror
Description: 03_disable_werror
Tags 665671 +patch
thanks
The attatched patch disables -Werror to make the package build.
Only in libgconf-bridge-0.1/libgconf-bridge: gconf-bridge.loT
diff -ur libgconf-bridge-0.1/libgconf-bridge/Makefile.am libgconf-bridge-0.1.new/libgconf-bridge/Makefile.am
---
This issue is a target dependency issue in debian/rules. When building with
build-arch or build-indep (rather than build) the patch target is not called
and the package tries and fails to build the unpatched source.
Patch fixing the target dependencies is attatched.
diff -ur
I've just been informed that it should have been a QA upload rather than
a NMU. New patch is attatched.
diff -ur libxslt-1.1.26/debian/changelog libxslt-1.1.26.new/debian/changelog
--- libxslt-1.1.26/debian/changelog 2012-05-06 00:05:33.0 +
+++ libxslt-1.1.26.new/debian/changelog
Package: fetchmail
Version: 6.3.21-3
Severity: serious
debian/rules build-arch
set -e
dh_testdir
/usr/bin/make
make[1]: Entering directory `/build/fetchmail-6.3.21'
make[1]: *** No targets specified and no makefile found. Stop.
make[1]: Leaving directory `/build/fetchmail-6.3.21'
make: ***
tags 666333 +patch
thanks
This rebuild was done by building only architecture:any binary packages
(binary-arch target of debian/rules), and using a recent dpkg that uses the
build-arch target if available.
Specifically the reason this fails is that a wildcard target in
debian/rules matches
Package: eglibc
Severity: serious
From the mips build log (the mipsel one looks the same to me though
I haven't done a thourough check to see if the list of failed tests
is identical
Encountered regressions that don't match expected failures:
tst-cancel24, Error 1
tst-cancelx10, Error 1
Tags 663943 +patch
thanks
Patch is attatched just add it to the dpatch list.
I have tested that the package builds with this patch, I have not done
any further testing.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 10_fix_typecast.dpatch by plugw...@p10link.net
##
## All lines beginning with `##
tags 653653 +patch
thanks
peter green wrote:
Unfortunately the test still fails with a bus error and I can't seem
to figure out how to run the test manually to get a new backtrace. The
executable ./integrity simply doesn't seem to exist after the build
process ends.
Ok fixed that issue too
based on Julien Cristau's and Patrick Baggett's comments I put together
the attatched patch to fix the alignment issues they identified (I have
not done anything regarding the poor choice of prototype or the
theoretical strict-aliasing issue).
Unfortunately the test still fails with a bus
gdm3 FTBFS (when rebuilt against a newer CDBS to pick up hardening
flags); from the amd64 build log:
To clarify the actual issue is that gdm3 FTBFS when there is a + in the
name of the build directory because the build process tries to set a
gconf config dir under the build directory and gconf
Package: jmeters
Version: 0.2.1-1
Severity: serious
Tags: patch
The new version of jmeters builds using -march=native. Using
-march=native chooses the target CPU based on the CPU of the build
machine and as such is completely unsuitable for building packages for
distribution by debian.
Package: libsbml
Severity: serious
Tags: patch
libsbml FTBFS if the package swig is not installed with the with the
following error
checking for gacutil... /usr/bin/gacutil
configure: error:
***
SWIG has been requested
package: digikam
severity: serious
tags: patch
version: 4:2.6.0~beta2-2
The latest upload of digikam failed on armel and armhf with
the following erors
cd
/build/buildd-digikam_2.6.0~beta2-2-armhf-ef6tKS/digikam-2.6.0~beta2/obj-arm-linux-gnueabihf/extra/kipi-plugins/photolayoutseditor
tags 664914 +patch
thanks
ROMReader.cpp: In function 'void GZIPROMReaderDeInit(void*)':
ROMReader.cpp:143:14: error: invalid conversion from 'void*' to 'gzFile'
[-fpermissive]
/usr/include/zlib.h:1488:24: error: initializing argument 1 of 'int
gzclose(gzFile)' [-fpermissive]
The issue is
tags 664914 +patch
thanks
Sorry forgot to actually attatch it, doing so this time
ROMReader.cpp: In function 'void GZIPROMReaderDeInit(void*)':
ROMReader.cpp:143:14: error: invalid conversion from 'void*' to 'gzFile'
[-fpermissive]
/usr/include/zlib.h:1488:24: error: initializing argument 1
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..-Wall
-ggdb -g -O2 -DSKINDIR=\/usr/share/audacious\ -g -O2 -c -o plugin_main.lo
plugin_main.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -ggdb -g -O2
-DSKINDIR=\/usr/share/audacious\ -g -O2 -c
Philippe De Swert wrote:
I can confirm the patch attached fixes #654201 too.
It fixes the build error both on amd64 and armhf (I expect on i586 a
rebuild would fail too but I have not tested it) Would be nice to see
this going into a release since it hits several architectures.
Do you
I've spent some time tracking down various issues with guile-1.8 and
guile-2.0. Problems with the latter can't be resolved until we have a
new upstream libgc release, but the guile-1.8 ia64 problem we can fix by
just marking that particular test as unresolved.
I should be able to upload new
The version of guile in unstable failed to build on the ia64 buildd.
This was reported as a RC bug ( 653939 ) by jcristu but it is not clear
if he tried to reproduce it locally or if he based his report soley on
the build logs (the build was tried and failed three times on the
buildd).
I just reviewed the most recent email I exchanged with the ISC product
manager, and she actually said end of February, although she wasn't a
betting woman.
So let's wait until March 1 to take stock of the situation. If no 4.2.4
upstream release has been made by March 1, I will check in with
Neil Williams wrote:
First test:
uname -a
Linux debian 2.6.32-5-amd64 #1 SMP Fri Dec 23 20:09:57 UTC 2011 x86_64 GNU/Linux
what Debian is this?
The host system is mostly a somewhat outdated squeeze (but with some
bits from lenny for reasons I won't go into here). The version of the
Package: cairo-5c
Version: 1.5
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Your package failed to build on the buildds
checking pkg-config is at least version 0.9.0... yes
checking for CAIRO_5C... no
configure: error: Package
Michael Biebl wrote:
Could you try building seed 3.2 against the same version of webkit as
seed 3.0 was built?
I removed all webkit and javascriptcore packages and installed
Package: linphone
Version: 3.5.2-6
Severity: serious
Tags: patch
The latest version of linphone build-depends on
libsrtp-dev [linux-any !sparc]
The intent of this was clearly all linux architectures except sparc.
Unfortunately however this is not a valid architecture specifier for a
package: guile-1.8
severity: serious
version: 1.8.8+1-6
Testing's version of guile-1.8 FTBFS in testing (trieds on amd64 and
armhf) with the following error.
libtool: compile: x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I.. -I.. -I..
-O2 -g -Wall -Wmissing-prototypes -Werror -MT
package: linphone
severity: serious
version: 3.5.2-2
tags: patch
x-debbugs-cc: debian-...@lists.debian.org
checking for alloca... yes
checking linux/videodev.h usability... yes
checking linux/videodev.h presence... yes
checking for linux/videodev.h... yes
checking linux/videodev2.h usability...
If I do that, I get a complaint that one of the other listed package is
not going to be installed. I tried specifying all of them on one command
line and I got a complaint that libpixman-1.dev was not going to be
installed. Adding that made the complaints go circular.
Can you please post the
mpak.py needs to be re-implemented or re-licensed because the current
implementation as distributed by Arch does not have any license attached
to it, so it is not distributable by Debian and Arch folks are violating
copyright law.
Thanks for explaining why the bug has not been fixed.
Found 651934 3.0.0-2
Thanks
Thanks jurij for your help.
'disassemble' command may be used to look up the assembler code around
the instruction which caused the crash:
Some further notes on the dissasemble command I ran into while trying to
use it.
1: it seems you have to explicitly select
We are currently awaiting a transition slot via debian-release.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656839
Understood
According to the endorsed workflow, we should not upload to unstable without
approval from the release team:
Back in august pabs tagged this bug as pending,
Looking at the SVN (which took a while to find since the PTS still
points at the git repo) it seems he did commit it to the repo but soon
afterwards put a notice in the changelog saying.
* DO NOT UPLOAD, needs to reimplement the mpak.py from
peter green wrote:
Would you object to a NMU based on the version currently in unstable
that just fixes the FTBFS?
I have now prepared a NMU based on the version currently in sid that
only fixes the FTBFS. The debdiff is attatched.
libosip2 maintainers are you ok with this NMU?
diff -u
Thanks Peter.
That upload is OK.
Thanks
Since i'm not yet a DD could one of you guys please sponsor it?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
seed currently FTBFS on sparc with a bus error.
I've reproduced this on a sparc box that Tom Theisen made available
(thanks tom) but i'm kinda stuck on how to debug it.
Any ideas on how to debug this? Normally i'd start by turning down the
optimisation but this package doesn't seem to be
are attatched, just create debian/patches and drop
them in (the package uses 3.0 (quilt) but currently has no patches)
Description: fix error on systems with signed char
The code this patch changes was causing a comparison is always false error
on systems where char defaults to unsigned.
Author: Peter
Zumbi: please call off the NMU. I'm now in dialog with the maintainer.
See my other email. Turns out I was grossly generalising, and they're
targeting around the end of the month.
Good to hear there is progress with upstream.
Personally I'd rather see a non-rc buggy version in testing before a
Hello,
I have been working with upstream on addressing both of these issues, and I
am hopeful that the 4.2.4 release, which is due in the next couple of
months, to address these issues. I'm waiting to see how much better that
release looks.
Speaking both as someone trying to get the armhf
package: cdcat
version: 1.7-1
severity: serious
severity: serious
cdcat failed to build on all buildds with the following error
g++ -c -pipe -std=c++0x -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -O2 -D_REENTRANT -Wall -W
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
Currently, the version of isc-dhcp-client in unstable suffers two rc
bugs, a FTBFS bug ( 643569 ) and a non-free IETF documents bug ( 645760
) both related to embedded bind source.
Furthermore isc-dhcp-client FTBFS in testing due to bug 643470 (which is
fixed in unstable).
It has been a
Package: tophat
Version: 1.4.1-1
Severity: serious
tags: patch
The configure.ac file in your package contains code to determine c
compiler flags based on architecture. Unfortunately this code is
horriblly broken.
On i386 the configure script uses -march=i686. This is not acceptable in
Bastien ROUCARIES wrote:
Any news of this bug
I've just tried an arch+indep build as root, an arch only build as root
and an arch+indep build as nobody on my freshly updated armel sid
system. All built successfully.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
* I have not determined exactly how it is broken but it seems to be
passing on all architectures. My suspsicion is the CFLAGS set before
the test aren't actually being used.
Furthermore even if the -m64 test were to be fixed it should not be used
in debian as on some systems it may be
Package: Scribus
Severity: Serious
Tags: Patch
Your package FTBFS on armel and armhf with the following error.
[ 60%] Building CXX object
scribus/CMakeFiles/scribus.dir/pageitem_textframe.cpp.o
Source: audacious
Version: 3.2-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
audacious FTBFS on sparc with an internal compiler error. This has been reported
to the gcc maintainers at http://bugs.debian.org/659793 but past
/bin/bash: line 1: 8437 Bus error ../../../src/seed
../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js
../../../doc/modules/readline/readline-funcs.xml
make[5]: *** [readline-funcs.xml] Error 138
I have gained access to a sparc box (initially to
This bug was marked as fixed-upstream over three months ago. Any ETA on
getting the fix into debian?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I have prepared a NMU for python-apt and Steve McIntyre has uploaded it
to delayed/2. The NMU backports the testsuite fix from unstable and also
improves debian/rules clean.
A debdiff is attatched.
diff -Nru python-apt-0.8.3/debian/changelog
python-apt-0.8.3+nmu1/debian/changelog
---
sorry sent this to the wrong bug report.
I have prepared a NMU for python-apt and Steve McIntyre has uploaded it
to delayed/2. The NMU backports the testsuite fix from unstable and also
improves debian/rules clean.
A debdiff is attatched.
diff -Nru python-apt-0.8.3/debian/changelog
your package appears to FTBFS in unstable, probably related to the move
to hdf5 1.8.8. See
https://buildd.debian.org/status/fetch.php?pkg=ruby-hdfeos5arch=s390xver=1.0-2stamp=1327882564
https://buildd.debian.org/status/fetch.php?pkg=ruby-hdfeos5arch=s390xver=1.0-2stamp=1327882564
for a build
Reopen 657814
found 657814 2.1.18-2
thanks
* Use autoreconf at build time to fix FTBFS. (Closes: #657814)
Umm, it seems you regenerated the autotools stuff but didn't
apply/include the rest of the patch. Predictablly the package still
FTBFS on armel and armhf.
--
To UNSUBSCRIBE,
on architectures where clutter uses opengl es
note: autotools stuff must be regenerated after applying this patch
Author: Peter Green plugw...@p10link.net
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
This source package contains the following files from the
IETF under non-free license terms:
This seems to have been fixed in the version in unstable. If that is indeed the case can someone
please close the bug so it can migrate to testing
--
To UNSUBSCRIBE, email to
python-apt is not present in armhf testing and this is making a
considerable number of packages uninstallable there. Getting armhf
testing into an acceptable shape is a key step towards releasing armhf
with wheezy.
The version of python-apt in unstable (which includes armhf binaries) is
not
/usr/bin/make -C /build/poco-VaXUUU/poco-1.3.6p1/Data/ODBC
Makefile:43: *** No ODBC library found. Please install unixODBC or iODBC and
try again. Stop.
make[2]: Entering directory `/build/poco-VaXUUU/poco-1.3.6p1/Data/ODBC'
make[2]: Leaving directory `/build/poco-VaXUUU/poco-1.3.6p1/Data/ODBC'
Several months ago you uploaded a fix for this rc bug to experimental
but the bug is still present in unstable. Please can you fix it in
unstable too?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Kurt Roeckx wrote:
Can I instead suggest someone looks at the kernel and fixes it?
It used to work, it works on the porter machines, it just fails
on the buidds.
Aurelien Jarno wrote:
The kernel part is not trivial to solve.
It now fails because of the multiple bind mounts needed by
changes are in
configure.ac, src/Makefile.ac and
Author: Peter Green plugw...@p10link.net
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want
package: actionaz
version: 3.2.1.1+dfsg-1
severity: serious
Actionaz builds with the following flags (among others)
-mmmx -msse -msse2 -mfpmath=sse
These flags are unacceptable in debian on CPU architectures other than
amd64*. On i386 they cause the compiler to produce binaries that are
SSE
+ The CPU_SSE plugin does not build without -msse
+Author: Peter Green plugw...@p10link.net
+Bug-Debian: http://bugs.debian.org/656755
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
found 651717 0.9.10-3+lenny2
found 651717 0.9.21-3+squeeze1
found 651717 1.0-4
thanks
Looks like this bug affects oldstable, stable and testing as well as
unstable :/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
I agree that this was not to hard. However, I did not understand your
motivation to work behind a perfectly working clean target which was
fully functional by using autotools-dev, dh-autoreconf.
It wasn't fully functional for me, I was repeatedlly bugged by
dpkg-source about files the clean
Reopen 654783
found 654783 2.7.2-13
thanks
The testsuite still seems to be hanging on both the kfreebsd-i386 and
kfreebsd-amd64 buildds (now tried three times on each).
test_signal
E: Caught signal 'Terminated': terminating immediately
make: *** [stamps/stamp-check] Terminated
Build killed
package: rampart
severity: serious
version: 1.3.0-2
rampart failed to build on all buildds and also locally in my sid amd64
pbuilder
checking path to use Axis2C . This is a compulsory to build Rampart-C... yes
configure: error: could not find axis2inc. stop
make: *** [debian/stamp-autotools]
Aaron M. Ucko wrote:
peter green plugw...@p10link.net writes:
Unfortunately my searches for axis2inc failed to find anything
relavent in debian so I can't make any suggestions on how to fix this.
There is a libaxis2c-dev package that ought to contain that script;
hmm, seems
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
This is a gentle poke to remind you that an rc bug on your package had a
patch submitted over
3 months ago which has still not been uploaded or otherwise responded to.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Can anyone test if the attached patch improves anything?
I just tried the following on armhf
Replaced debian/patches/0009-fix_FTBFS_with_ffmpeg_debian.patch
with the version from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=656502
Added Adapt_to_libav_API_changes.patch from the
Andreas Tille wrote:
Hi,
I have to admit that I do not have any experience with SSE issues. Any
advise what to do in cases like this (see build logs linked below)?
From looking at the build logs it looks like it is trying to build a
plain CPU plugin and a CPU with SSE plugin, presumablly
This should work in ubuntu too, shouldn't it?
Which version of ubuntu?
The package as it stands now should support ubuntu oneiric and precise.
I just tested building scid 4.3.0.cvs20111216-3 from incoming.debian.org
under ubuntu precise i386 and it built fine
If you want to support
package: engauge-digitizer
severity: serious
tags: patch
version: 5.0-1
The latest upload of engauge-digitizer failed on armel and armhf with
the following erors
src/digitview.cpp:293:61: error: no matching function for call to
'QMatrix::map(double, double, double*, double*) const'
1101 - 1200 of 1819 matches
Mail list logo
