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-dist-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
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-dist-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
In april Aurel32 retitled this bug report to osptoolkit: FTBFS with
recent binutils versions. Sebastian Carneiro supplied a patch from
ubuntu in july but did not apply the patch tag.
However when I try building the unpatched package in my sid pbuilder it
builds fine with regular binutils
tags 654597 +patch
severity 654597 serious
thanks
According to the build logs for armhf/s390x:
https://buildd.debian.org/status/package.php?p=sersuite=sid
https://buildd.debian.org/status/package.php?p=sersuite=sid
I've just reproduced this on amd64 as well. Bumping the severity
Note that
I cannot reproduce this bug,
Most likely that means whatever build environment you used
already had cmake installed.
It is important to use a tool like pbuilder or cowbuilder
with a base environment kept as clean as possible when
trying to reduce this kind of bug.
can you please check the
Per Olofsson wrote:
2012-01-05 16:05, Per Olofsson skrev:
Thanks!
Hmm, this is strange. The check_* programs don't output anything at all.
I have requested the build-deps for lyx to be installed on harris.d.o so
I can debug it myself.
I can't reproduce the error on harris.d.o. The
I have attatched a patch that fixes the format security errors.
Unfortunately after fixing those errors the build fails with:
make[5]: Entering directory
`/ltp-20091231+dfsg.new/testcases/network/nfsv4/acl'
../../../../include/mk/env_post.mk:72: warning: overriding commands for
target
tags 654263 +patch
thanks
https://buildd.debian.org/status/package.php?p=mlviewsuite=sid
https://buildd.debian.org/status/package.php?p=mlviewsuite=sid
The build failure was seen on armhf, but I have reproduced it on a sid
amd64 system, hence the security raise to serious.
I attatch two
https://buildd.debian.org/status/package.php?p=ns2suite=sid
https://buildd.debian.org/status/package.php?p=ns2suite=sid
The package fails to configure because of missing otcl:
Well it's not exactly missing, the package is in the archive
and it was installed for the build, so the question was
P.S ace 6.0.3-3 failed on the armel buildd with what appears to be a
doxygen error. I do not know what is behind that issue (it's not one
i've ever seen in my tests here) and if it was a fluke or not.
Hmmm, strange. A similar issue can be seen on GNU/kFreeBSD; could be
#651081. I'll check that,
Or something in the build environment?
* I've looked throught logs a bit and saw a different gcc/g++ version
on hurd-i386.
* More promising: in my i386 sid cowbuilder chroot, the build
succeeds with binutils-gold installed and fails without it.
heh it's usually the other way round ;) I
Thanks again for your patch. Everything seems to work OK but as I normally
don't use ext3grep, I let regular users test by themselves and will then
upload the package.
It doesn't seem any regular users responded to your request, I tried to put
the word out wider on debian-user and the debian
tags 654218 +patch
thanks
https://buildd.debian.org/status/fetch.php?pkg=libgconf-bridgearch=armhfver=0.1-2stamp=1322967516
https://buildd.debian.org/status/fetch.php?pkg=libgconf-bridgearch=armhfver=0.1-2stamp=1322967516
The package fails to build on armhf and s390x, but I've reproduced the
An initial push of packages to testing occurred with tonight's britney
run. There's a certain amount of uninstallability and loads of missing
packages still, but it's a start :)
I guess the next step is to try and get it to the point where it is
bootstrapable.
When I tried to bootstrap it
severity 555877 important
retitle 555877 FTBFS with binutils-gold
thanks
While it seems there was a point in time where this package failed with regular
binutils
(see old logs on buildd.debian.org) it now builds fine with current versions of
regular
binutils as evidenced by the recently built
package: clang
severity: grave
x-debbugs-cc: debian-...@lists.debian.org
When trying to build libblocksruntime both locally and on the buildds it
fails with the following warnings and errors.
make[1]: Entering directory
`/build/buildd-libblocksruntime_0.1-1-armhf-kukYFg/libblocksruntime-0.1'
Sylvestre Ledru wrote:
As said in the error message, could you start it again with -v ?
armhf:
root@debian:/# clang -v test.c
Debian clang version 3.0-5 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: warning: unknown platform,
tags 653779 +patch
thanks
exult FTBFS:
| if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I./../../headers -I./.. -I./../../files
-I./../.. -O2 -Wno-long-long -O2 -MT ucparse.o -MD -MP -MF
.deps/ucparse.Tpo -c -o ucparse.o ucparse.cc; \
| then mv -f .deps/ucparse.Tpo .deps/ucparse.Po; else
reassign 652226 scilab
fixed 652226 5.3.3-5
thanks
Can you explain why you reassigned and closed this bug? the package it
was originally about (sciscipy) still seems to FTBFS with the same error
in up to date sid.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Package: Acetoneiso
Severity: serious
Currently acetoneiso has a build-depends on
libqt4-dev ( 4:4.7.0~beta2) | libqtwebkit-dev
This makes it impossible to install the build-depends with tools that
only look at the first option for a build-depends (notablly sbuild as
used by the official
Applying the second patch from that bug report (
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;bug=631800 ) and
running autconf2.64 to rebuild configure makes the configure script succeed.
Unfortunately after doing so the build fails with the inability to find
jsnum.h
Removing the
failures
+Author: Peter Green plugw...@p10link.net
+Bug-Debian: http://bugs.debian.org/652157
+
+---
+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
Relevant part:
gcc version 4.6.2 (Debian 4.6.2-6)
configure:3718: $? = 0
configure:3707: gcc -V 5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3718: $? = 4
configure:3707: gcc -qversion 5
gcc: error: unrecognized option
Now -- how do I go about submitting my patch to resolve these bugs?
Generally the first thing to do would be to post the patch to the bug
report and hope either the maintainer picks it up or another interested
debian developer picks it up an NMUs.
If that fails then it is possible to prepare
tags 652159 +patch
thanks
Relevant part:
gcc -g -Wall -pipe -O2 -I../src -I./ -D_BSD_SOURCE -I/usr/include/pcap
-I/usr/libipq -I../lib/libipulog/include -DHAVE_BW -DFAST_FW_CHECK
-DLAYER7_FILTER -DUSE_MYSQL -I/usr/include/mysql -DWIPE_OPENSSL
-I/usr/include/glib-2.0
Package: xxdiff
severity: important
While investigating 617768 I ran into another unrelated issue. Namely if
libqt4-dev is installed the build fails with.
/usr/bin/make -C src -f Makefile.bootstrap makefile
make[1]: Entering directory `/xxdiff-3.2/src'
qmake -o Makefile.qmake xxdiff.pro
uic:
The package fails to build on armhf due to missing rst2html.py command.
Ok this is a really strange one.
The package failed in the same way on both armhf and s390x which would
usually indicate a wider problem so I tried building it on some other
architectures but I was able to build it across
tags 636559 +patch
thanks
Kurt Roeckx wrote:
Your package is failing to build from source with the following
error:
x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../..
-I../../nepenthes-core/include -I../../nepenthes-core/src -pipe -D _GNU_SOURCE
-D _GNU_SOURCE -I/usr/local/include
tags 622066 +patch
thanks
Relevant part:
g++ -c -pipe -g -Wall -W -O2 -D_REENTRANT -fPIC -DQCA_PLUGIN -DOSSL_097
-DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_PLUGIN -DQT_SHARED -DQT_TABLET_SUPPORT
-I/usr/share/qt3/mkspecs/default -I. -I/usr/include/qt3 -o qca-tls.o qca-tls.cpp
qca-tls.cpp: In
tags 629882 +patch
thanks
Relevant part:
g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/pango-1.0
tags 650230 +patch
thanks
With valac-0.14 the package build successfully. So it's probably just a
matter of bumping the build dependency.
Unfortunately it's not quite that simple because neither valac-0.10 or
valac-0.12 seems to work and both seem to have a higher alternatives
priority than
Well installing libssl-dev fixes that error. However given that the
copyright file claims the package is under the GPL and doesn't mention
any license exceptions I don't think the package should be being built
against openssl libraries.
And even with libssl-dev installed the build fails later
tags 635901 +sid wheezy
severity 635901 serious
thanks
*** /tmp/tmpbOzU85
In Ubuntu, the attached patch was applied to fix a FTBFS:
First things first is to check the applicability of this to
debian. It turns out that stereograph builds fine in lenny
and squeeze but fails in wheezy and sid.
I
Joey Hess wrote:
Alexey Eromenko wrote:
Default Debian-6 KDE installs gnash, an extremely unstable
component, that constantly crashes KDE Konqueror, when user accesses
any flash-enabled website (such as www.amd.com).
Wouldn't that be a bug in konqueror-nsplugins? No plugin should be
From looking at http://wiki.debian.org/ArchitectureSpecificsMemo I have
a suspision that ia64 needs to be added to the list of architectures
needing aligned accesses in webkit like sparc was recently. However I
have no way of testing if this fixes the build failure nor any
particular interest
Version: 4.6.2-15
Both gmime and gmime2.4 have now been built sucessfully (one on the
buildd the other on a porterbox). I am therefore closing this bug
(versioned with the version that built gmime successfully.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
You downgraded 656274 (collectd ftbfs on armhf and armel) with no
explanation. I said at the end of the report I discovered that the build
failed on armel as well as armhf and that was the reason for the serious
severity. My understanding is that armel is a release architecture and
as such a
Will be fixed soon.
Another month has gone by and still no upload, any progress?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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
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-dist-requ...@lists.debian.org
with
* 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: 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: picolisp
Version: 3.0.9.3-1
severity: important
tags: patch
Picolisp FTBFS on armhf with a PIE related error. The attatched patch
disables use of PIE on armhf to make the package build (it is already
disabled on amd64)
--- picolisp-3.0.9.3/debian/rules 2012-02-17 15:19:30.0
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
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
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
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
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
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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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...
tags 645822 +patch
thanks
When discussing the sparc bug* Eric Botcazou from gcc upstream claimed
...you should never configure the compiler with --disable-checking, even in a
cross configuration. This will save a few percents in compilation times but
disables critical internal checking; you
Package: simulavr
Version: 0.1.2.2-6.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
https://buildd.debian.org/status/fetch.php?pkg=simulavrarch=armelver=0.1.2.2-6.2stamp=1319642506
make[4]: Entering directory
Currently this bug is marked as fixed in stable but unfixed in testing
and unstable.
There is a comment in the bug report log saying This file has already
been removed from the latest ace versions. and the file does not appear
to be present in the testing version of the package.
However
tags 625756 +wheezy sid
thanks
this bug does not affect squeeze as the default gcc there is 4.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
g_format_size_for_display is deprecated as it uses binary prefix calculations
but does not use the IEC prefixes to display them. Evoloution builds with
G_DISABLE_DEPRECATED and so FTBFS
The package also uses the deprecated G_CONST_RETURN
I see several possible fixes to this
1: switch to
Package: ser
Version: 2.0.0-4
Severity: normal
Hi Maintainer,
what is the state of this issue?
I'm not the maintainer but this still seems to be an issue with 2.0.0-5
https://buildd.debian.org/status/fetch.php?pkg=serarch=sparcver=2.0.0-5stamp=1321162065
--
To UNSUBSCRIBE, email to
Need to check if the attached patch fixes it when I get access to a hurd
and kfreebsd machine.
Alternatively, feel to check it also.
Builds sucessfully with the patch on kfreebsd-amd64 and kfreebsd-i386
I haven't tested on hurd-i386 because my hurd-i386 vm is currently broken
but IMO that is
package: cryptkeeper
serverity: serious
Currently there are uninstallable cryptkeeper packages on kfreebsd-i386
and kfreebsd-amd64. cryptkeeper should not be allowed to build on
architectures where it's dependencies (in this case encfs) are not
available. Currently this issue is preventing
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
forwarded 659793 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425
thanks
Matthias Klose wrote:
tags 659793 + moreinfo help
thanks
does it work with 4.5, 4.7 (snapshot)?
Works with both 4.5 and snapshot, only 4.6 seems to suffer the problem.
please forward it upstream after investigating.
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: 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
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
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
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).
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
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,
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-dist-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
Package: gcc-4.6
Version: 4.6.2-14
Severity: important
Attempting to build the attatched file (preprocessed output from a file that
forms part of audacious) with the following command
gcc -fPIC -DPIC -g -O2 -std=gnu99 -pipe -pthread -c -xcpp-output
ui_fileopener.preprocessed
produces
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
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
Package: gcc-4.6
Version: 4.6.2-12
Severity: important
Gmime failed to build on armhf with the following error
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../util
-DGMIME_VERSION=\2.4.31\ -DGMIME_MAJOR_VERSION=2 -DGMIME_MINOR_VERSION=4
-DGMIME_MICRO_VERSION=31 -DG_LOG_DOMAIN=\gmime\
I have reduced this to the attatched testcase
sorry, screwed up trying to attatch the file in reportbug, here's the
testcase.
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 8 -*- */
/* GMime
* Copyright (C) 2000-2010 Jeffrey Stedfast
*
* This library is free software;
package: gmime2.4
severity: important
tags: patch
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../util -DGMIME_VERSION=\2.4.31\
-DGMIME_MAJOR_VERSION=2 -DGMIME_MINOR_VERSION=4 -DGMIME_MICRO_VERSION=31
-DG_LOG_DOMAIN=\gmime\ -DG_DISABLE_DEPRECATED -D_LARGEFILE64_SOURCE
package: php5
severity: important
php5 failed to build on armhf with the following errors.
checking for InterBase support... yes, shared
checking for isc_detach_database in -lfbclient... no
checking for isc_detach_database in -lgds... no
configure: error: libgds, libib_util or libfbclient not
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
package: vsftpd
version: 2.3.5-2
severity: important
vsftpd fails to build on armhf with the following error. This initially
happened on the buildd
and I have also reproduced locally.
gcc -o vsftpd main.o utility.o prelogin.o ftpcmdio.o postlogin.o privsock.o
tunables.o ftpdataio.o secbuf.o
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: tupi
Severity: important
Tags: patch
Tupi FTBFS on armel and armhf with the following error.
ktpaletteparser.cpp: In member function 'virtual bool KTPaletteParser::startTag(const
QString, const QXmlAttributes)':
ktpaletteparser.cpp:133:83: error: no match for 'operator' in
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
/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'
package: gcc-mingw-w64
version: 4.6.1-16+2
tags: patch
gnat is not yet available on armhf but there is no reason that should
block the rest of gcc-mingw-w64 being built on armhf. So please disable
ada support in the armhf version of the package for now.
A patch is attatched to do that.
diff
801 - 900 of 2734 matches
Mail list logo
