package: ifeffit
severity: serious
x-debbugs-cc: debian-rele...@lists.debian.org
ifeffit needs rebuilding against the new perl and it seems the buildds
can't build it due to the build-depends on the non-free package pgplot5.
--
To UNSUBSCRIBE, email to
I see you are building against libsane 1.0.22-2. Were the previous
successful builds against libsane 1.0.22-2, or another?
You can find the log of the last successfull sparc build at
https://buildd.debian.org/status/fetch.php?pkg=libsane-perlarch=sparcver=0.03-1stamp=1242394752
Apparently
Note: I write this message to the bug as a concerned user of freepascal
in debian.
Currently in debian the svgalib packages themselves are marked as being
for architectures linux-any and kfreebsd-any but packages-arch-specific
restricts building on the buildds to i386 and amd64. Further at
package: jabberd14
severity: important
After upgrading from lenny to squeeze jabberd failed to work.
I then discovered that the configuration file was incompatible. After
diffing my old config to the one from plain lenny I discovered the only
think
After making that change it is now
tags 613961 + sid patch
This bug seems to impact builds in sid but not in squeeze or wheezy.
A patch is attatched that adds the required define to the CXXFLAGS to
enable that type.
--- libphash-0.9.0/debian/rules 2011-02-18 23:53:17.0 +
+++ libphash-0.9.0.new/debian/rules
The versioned dependency is placed manually as both a binary and
build-dependency so this isn't a simple rebuild to fix dependency problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 625311 +patch
thanks
patch is attatched just add it to debian/patches
I have built the game with the patch and checked it seems to basically
run with this patch. I have not extensively tested it. I am just doing
flyby bugfixes I do not have previous experiance with this game or package.
tags 625319 +patch
thanks
Patch is attatched that eliminates the unused but set variables.
Note: i'm just doing flyby rc bugsquashing, I have tested that the
resulting packages build and install but I have not tested beyong that.
diff -ur chiark-tcl-1.1.0+nmu2/base/hook.c
tags 625323 +patch
thanks
As well as the issue mentioned in this bug report I found two other
issues that were preventing successfull build.
Patches for all three issues and a new 00list file to apply them in the
right order (the package uses dpatch) are attatched.
Note that since I don't
tags 625308 +patch
thanks
It appears this bug was misreported and a linker error was the cause not
a compiler warning.
A modified debian/rules file is attatched that makes the package build
again.
#!/usr/bin/make -f
export LDFLAGS += -lglib-2.0 -lgobject-2.0
%:
dh $@
reassign 636802 fpc
thanks
From my testing on armel I now belive that the issue causing the
lazarus build failures is a problem with freepascal and multiarch. I
haven't tried to troubleshoot the issue on powerpc or sparc as I don't
have access to them but I presume it is the same issue.
On
tags 636802 +patch
thanks
Note: jonas's reply was only posted to fpc-devel, not to the debian bug
report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html
Jonas Maebe wrote:
Is there a standard for multiarch library path locations and names?
It looks like this built succesfully on all linux architectures with the
latest binnmu, should this bug be closed?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The current gcc is now 4.6 and the latest version of drizzle seems to
build fine in sid. Should this bug be closed?
P.S. drizzle looks like it needs a binnmu for the new libprotobuf and a
cleanup of some cruft packages that are no longer generated by the source.
P.P.S, i'm just taking flyby
tags 623263 +patch
found 623263 2.3.1+dfsg-5
thanks
This bug also affects testing
If there is a need to get this package building on armel again before
the gcc bug is fixed it is possible to do so by building it with g++-4.4
(4.5 and 4.6 both fail) on armel. I've attatched a patch that does
If there is a need to get this package building on armel again before the
gcc bug is fixed it is possible to do so by building it with g++-4.4 (4.5
and 4.6 both fail) on armel. I've attatched a patch that does that.
Thanks for the patch!
Do you know if this will cause any problems given
version: 5.1.7-3
I have just tested the latest version and it builds fine with gcc 4.6.1-8
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 625327 +patch
thanks
patch is attatched
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
retitle 630376 cpu: package FTBFS if automake1.7 is installed
David Adam wrote:
On Mon, 19 Sep 2011, peter green wrote:
I have just tested this and I can't reproduce the issue in any of the
following environments
1: my dirty squeeze chroot
2: my dirty wheezy chroot
3: my dirty sid chroot
4
Package: clutter-gesture
Version: 0.0.2.1-3
Severity: normal
Unfortunately the fix to make this package build with gcc 4.6 broke
building with gcc 4.4 and will almost certainly also break building with
gcc 4.5
Package: lazarus
Version: 0.9.30-3
Severity: serious
/usr/bin/ppcppc -gl -dlclnogui -Fu../lcl/units/powerpc-linux
-Fu../lcl/units/powerpc-linux/nogui
-Fu../components/codetools/units/powerpc-linux
-Fu../components/synedit/units/powerpc-linux
-Fu../components/lazcontrols/lib/powerpc-linux
The armel and sparc issues are blocking the migration of the new
version of freepascal to testing (the armel failure isn't because
there are no old lazarus binaries on that platform).
Sorry I screwed up this paragraph, it should have said:
The powerpc and sparc issues are blocking the
tags 637936 +patch
thanks
patch is attatched, just add it to the dpatch list.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 040-libcurl-fix.dpatch by plugw...@p10link.net
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Remove obsolete libcurl include
@DPATCH@
diff
tags 625376 +patch
thanks
patch attatched just drop it in debian/patches
diff -Nur -x '*.orig' -x '*~' libunique-1.1.6//tests/test-unique.c libunique-1.1.6.new//tests/test-unique.c
--- libunique-1.1.6//tests/test-unique.c 2009-09-21 12:31:14.0 +
+++
Over a month ago I posted a patch to add the new (multiarch) directory
containing crti.o to the default fpc.cfg. Without this patch (or an
equivilent manual config edit or manual command line parameter)
freepascal will (silently) fail to include include crti.o in the linker
script and this
Package: crash
Version: 5.1.7-2
Serverity: serious
The last two uploads of crash have failed to build on ia64 with the
following error
elf64-ia64.c: In function 'elf64_ia64_section_from_shdr':
elf64-ia64.c:1344:13: error: variable 'newsect' set but not used
[-Werror=unused-but-set-variable]
tags 625343 +patch
thanks
I have attatched a patch to fix the build issues with gcc-4.6.
It also seems some build system cleanup is needed on this package to
avoid the new dpkg-source bitching about changes to the upstream code.
Description: Fix build issues with gcc 4.6
Author: Peter Green
found 643866 2.1.16
thanks
I have just tested and the version in testing also FTBFS on kfreebsd
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 637704 +patch
thanks
This bug only affects sid and wheezy it does not affect squeeze.
The fix is just to remove the obsolete include, I have attached a patch
that does that and also fixes debian/rules clean.
diff -ur gosmore-0.0.0.20100711/debian/rules
Matthew Vernon wrote:
Hi,
I have just tested and the version in testing also FTBFS on kfreebsd
OOI, what's the failure mode?
Program terminated with a Segfault during the self test.
Thanks,
Matthew
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
openssl098 is still kept in testing by:
- ace (ICE on armel)
Taking a look at this one
- beid (RC-buggy, candidate for removal)
- ipsec-tools (#619687 #643570, has reverse dependencies)
- isakmpd (#622051, candidate for removal)
This bug has had a patch for several months, but the maintainer
Here's a patch updating (well removing) several svgalib related
entries.
The background that lead to this request can be found at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623747 .
In particular this issue is rendering fpc uninstallable on armel (and hence
blocking it's migration to
Can you please try again with 2.4.4. This includes multiples changes
in example script packaging and should fix your issue.
ok boostrap recipie below (this pretty much represents what I did but
with some screwups edited out). Note that the instructions below assume
starting in an empty
Hi FPC core,
Can anyone help on this please ?
Note that i've made a fair bit of progress since the mail Abou Al
Montacir forwarded, i'll feedback to the bug with another status update
soon.
I'm also in #fpc on freenode right now.
--
To UNSUBSCRIBE, email to
Unfortunately it seems while the build was sucessful the binary
packages are incomplete and unusable. Further research is needed into
why things are breaking.
Ok nailed that issue, it seems that at some point during the build
process debian/control was regenerated from debian/control.in
One thing that I know of is a difference in the name of the function that
returns threadsafe errno.
Yeah I ran into that one, it was pretty trivial to fix though.
It would help to know what symbols are the
problem.
(if they are more libc, or startup code related)
The startup code seems to
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
Don Armstrong wrote:
severity 678604 important
umm, armhf is now a release architecture and lilypond has built there in
the past
by my reading of the rc policy that makes this rc.
The problem is that metafont segfaults on armhf. This looks to be some
odd kind of architecture specific
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
The problem is that metafont segfaults on armhf. This looks to be some
odd kind of architecture specific problem in armhf's malloc, which
I've asked for assistance with on debian-arm, but have received
none.[1]
Given that lilypond built successfully in raspbian and arm EABI uses a 1
in the LSB
The NMU diff is attatched to this mail (note: please do not
upload/commit this
change yet, I want to see if it actually solves the problem first).
Sorry I screwed up, corrected NMU diff is attatched. Again please don't
upload/
commit until I confirm that this solves the problem.
diff -ur
Norbert Preining wrote:
Hi Peter,
On Do, 28 Jun 2012, peter green wrote:
commit until I confirm that this solves the problem.
ANy progress on that? I am preparing new packages from the TL sources
now ...
I have now confirmed that rebuilding texlive-bin with -marm on armhf
fixes
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:
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 =
Source: pyopenssl
Severity: wishlist
Tags: patch
I attatch a patch which seperates build-arch and build-indep. This
avoids wastefully rebuilding the documentation on every autobuilder only
to throw the results of doing so away.
Only in pyopenssl-0.13.new/: build
Only in pyopenssl-0.13.new/:
Package: smb4k
Severity: important
Tags: patch
Smb4k failed to build on the armel and armhf autobuilders with the following
error.
cd /build/buildd-smb4k_1.0.1-1-armel-kH7YB_/smb4k-1.0.1/obj-arm-linux-gnueabi/core
/usr/bin/c++ -DMAKE_SMB4KCORE_LIB -D_BSD_SOURCE -D_XOPEN_SOURCE=500
Package: lazarus
Severity: important
Now that freepascal has been built for armhf can you add armhf to the
architecture lists for lazarus as well. I tested lazarus on armhf and it
seems to work.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Mysql-5.5 a would-be FTBS on the i386 and kfreebsd-386 platforms (but
the relevant tests are disabled). We are not at all happy about
disabling those tests as they suggests issues with SSL connections.
However some evidence has emerged that compiling with gcc-4.5 would be a
work around whilst
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: 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
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: gettext
Version: 0.18.1.1-5
Severity: important
While working on an unofficial hardfloat port of debian for the Pi I
discovered a missing dependency on libcroco3 in the newly built gettext
package. I tracked this down to libraries directly under
debian/gettext/usr/lib/ not being
Santiago Vila wrote:
Thanks a lot. I believe this is the same bug as Bug#604778,
Agreed, I have since discovered that our armhf for pi port had
inadvertantly
ended up with a gcc that passes --as-needed by default.
which I
finally understand. Will try to upload a fixed version soon.
Package: gcc-4.6
Version: 4.6.3-1
Severity: important
Tags: patch
While working on an unofficial hardfloat for pi port of debian I
discovered that building the gcc-4.6 package in an environment that
identifies itself (though lsb-release) as wheezy results in the build
choosing different
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: ***
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: buildd.debian.org
I just added armhf support to the fpc package and uploaded it (it's a
self-compiling compiler so the first build for an architecture has to be
done manually). Can you either add armhf to the packages-arch-specific
entry or remove the entry completely (I don't think
: Peter Green plugw...@p10link.net
Bug-Debian: http://bugs.debian.org/?
--- directfb-1.2.10.0.orig/gfxdrivers/davinci/davinci_c64x.c
+++ directfb-1.2.10.0/gfxdrivers/davinci/davinci_c64x.c
@@ -37,6 +37,8 @@
#include sys/ioctl.h
#include sys/mman.h
#include sys/types.h
+#include sys/stat.h
Package: ace
Version: 6.0.3-2
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Ace FTBFS on armel due to an internal compiler error. The internal compiler
error
has been reported to the debian g++ developers at
fusebirth is only used to generate fused_loop.c, which is then used to
build the final freebirth. so shipping a generated fused_loop.c instead
of trying to generate it every time would be a solution.
IMO if this is still an issue building the generator with -O0 would be a
more appropriate
Package: libomxil-bellagio
severity: normal
As can be seen from
https://buildd.debian.org/status/fetch.php?pkg=libomxil-bellagioarch=ia64ver=0.9.3-1stamp=1311061192
libomxil-bellagio FTBFS on systems where gcc is 4.4 due to the use of
unregonised parameters -Wno-error=unused-but-set-variable
Package: libomxvorbis
severity: normal
As can be seen from
https://buildd.debian.org/status/fetch.php?pkg=libomxvorbisarch=ia64ver=0.1-3stamp=1311134424
libomxvorbis FTBFS on systems where gcc is 4.4 due to the use of
unregonised parameter -Wno-error=unused-but-set-variable. While I haven't
tags 625381 +patch
thanks
Patch is attatched.
diff -Nur -x '*.orig' -x '*~' mach-0.9.1//src/mach-helper.c mach-0.9.1.new//src/mach-helper.c
--- mach-0.9.1//src/mach-helper.c 2007-01-06 09:54:38.0 +
+++ mach-0.9.1.new//src/mach-helper.c 2011-10-15 01:41:51.0 +
@@ -144,7
fprintf(stdout, fmt);
Is there any way to inhibit the warning for this specific line? Or will I end
up having to compile the whole package with -Wno-format-nonliteral ?
It's a bit ugly but I think passing a dummy format argument (e.g.
fprintf(stdout, fmt,0);
should shut the compiler up
Found 638141 1:2.30.1-3
thanks
I can confirm that the issue also affects the version in testing.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
gregor herrmann wrote:
On Mon, 19 Sep 2011 01:50:41 +0100, peter green wrote:
patch is attatched
Hm, not really :)
Sorry, really attatched it this time.
Cheers,
gregor
Only in filtergen-0.12.4/: fgadm.conf
Only in filtergen-0.12.4/: filtergen.spec
diff -ur filtergen
- ace: There have been a number of gcc-4.6 updates, I gave
it back to see if the ICE has been fixed or not.
The build that resulted from the most recent give-back
failed but it did so in a VERY strange manner.
It claimed to install libzzlib-dev and zlib1g-dev yet it
failed to link against
Many packages seem to provide ENABLE/DISABLE variables in
/etc/default/foo, providing a confusing red herring for this
task --- a second method which does not work nearly as well,
as you pointed out
Though there are some situations where it is nessacery. Consider
vtund for example which has
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
Is
there anything I can do to ensure that this gets looked at for the OOo
package in squeeze?
Not really, debian stable releases are all about keeping changes to
a minimum. If someone made a minimal patch to fix this issue it MIGHT
be accepted but I can't see that happening unless you do the
tags 646142 +patch
thanks
Looks like you need to add libncurses-dev to Build-Depends.
Yep seems to build fine with libncurses-dev installed. Adding patch tag.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
tags 646143 +patch
thanks
Looks like you need to add libncurses-dev to Build-Depends.
Yep seems to build fine with libncurses-dev installed. Adding patch tag.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
tags 625409 +patch
thanks
Patch is attatched, just add it to the dpatch list.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40_fix_g++_4.6.dpatch by root@localhost
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad '--exclude=CVS'
tags 625412 +patch
thanks.
Doko's report is a false positive. The files that generate the warnings
in question are not built using -Werror.
However while testing to confirm that it was a false positive I
discovered that tuxpuck was unbuildable in current sid for another
reason. tuxpuck
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
Over a month ago you tagged bugs 640357 and 625415 pending but there
haven't been any uploads since and you did not post patches to the bug
reports.
Do you still plan to upload fixes for these bugs? If not can you at
least provide patches (or links to a vcs) so that the option is
available
tags 646488 +patch
thanks
patch is attatched.
diff -ur wmtemp-0.0.6/dockapp.c wmtemp-0.0.6.new/dockapp.c
--- wmtemp-0.0.6/dockapp.c 2004-03-08 15:57:32.0 +
+++ wmtemp-0.0.6.new/dockapp.c 2011-10-30 00:38:39.0 +
@@ -49,7 +49,6 @@
{
XClassHint *classhint;
severity 645822 serious
Thanks
From the rc policy: http://release.debian.org/wheezy/rc_policy.txt
Packages must autobuild without failure on all architectures on
which they are supported. Packages must be supported on as many
architectures as is reasonably possible. Packages are assumed to
be
In Ubuntu, the attached patch was applied to fix the FTBFS.
snip
Thanks for considering the patch.
unfortunately the patch is not sufficiant to get the package to build in
current sid. After applying it the build fails with
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
Package: mailavenger
Version: 0.8.1-3
Severity: serious
While trying to confirm if bug 625391 was a false positive or not I
discovered that your package FTBFS in unstable for another reason.
checking for BerkeleyDB library... no
configure: error: Cannot find BerkeleyDB
make: ***
tags 625407 +patch
thanks
I have attatched a patch which both fixes the build failure and makes
debian/rules clean work properly.
diff -ur rdup-1.0.5/debian/rules rdup-1.0.5.new/debian/rules
--- rdup-1.0.5/debian/rules 2011-11-01 01:08:49.0 +
+++ rdup-1.0.5.new/debian/rules
There are two -Wunused-but-set-variable warnings but the build
doesn't fail ...
That is because the files in question are NOT built with -Werror. Indeed
the only mention of -Werror in doko's build log is in the output of a
configure check.
Based on looking at a number of these bugs it would
Patching the actual compile failures was easy enough. I've attatched a
patch for that. I'm not absoloutely sure of it's correctness though
(apparently there are some weird ways printf can be used and I don't
know if aegis is using any of them).
Unfortunately after fixing the compile failures
tags 651625 +patch
thanks
Attatched patch fixes the FTBFS and also makes debian/rules clean work
properly.
diff -urN gnash-0.8.10~git20111001/debian/patches/fix-const.patch gnash-0.8.10~git20111001.new/debian/patches/fix-const.patch
--- gnash-0.8.10~git20111001/debian/patches/fix-const.patch
package: firetray
version: 0.3.1-4
severity: serious
scons: Building targets ...
xpidl -w -m header -Icomponents -I/usr/lib/xulrunner-devel-9.0/idl -e
components/nsITray.h components/nsITray.idl
sh: 1: xpidl: not found
scons: *** [components/nsITray.h] Error 127
scons: building terminated
package: magics++
version: 2.14.5-1
severity: serious
tags: patch
configure:20462: g++ -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security -m64 -fPIC -fno-gnu-keywords -ansi
-std=c++98 -Wno-deprecated -Wno-write-strings -D_FORTIFY_SOURCE=2
your package FTBFS on armel:
| make[2]: Entering directory
`/build/buildd-eresi_0.8a25-3-armel-DD3U6T/eresi-0.8a25/libelfsh'
| cc -Iinclude -Wall -fPIC -g3 -O2 -DELFSH_INTERN -I../libasm/include/
-I../libetrace/include -I../libaspect/include/ -DERESI32 -DM32 -c -o
dynamic.32.o dynamic.c
| In
package: python-enchant
severity: important
It was recently discovered that it is not possible to import
python-enchant in python2.6 on armhf unless libenchant-dev is installed.
Loic minor identified the issue as being the use of find_library
Essentially ctypes' find_library is very wrong and
Package: python2.6
Severity: important
As documented at
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/898172 there is
a problem with find_libary on armhf.
This has been fixed in python2.7 already but it is still present in
python2.6 so it still hits packages that try to build
The package seem to build fine installing as build-dependency
`libenchant-dev'. OTOH, I am unsure why this issues does not show on other
architectures.
After further discussions on debian-arm/debian-python I belive that
while adding libenchant-dev as a build-dependency will make the
package: qtiplot
severity: serious
tags: patch
qtiplot FTBFS in unstable with the following error
g++ -c -pipe -Wall -g -O2 -D_REENTRANT -Wall -W -DSCRIPTING_CONSOLE -DSVN_REVISION=\\ -DQT_PLUGIN
-DTRANSLATIONS_PATH=\/usr/share/qtiplot/translations\
package: ace
severity: important
version: 6.0.3-2
(6.0.3-3 is also affected)
unfortunately it seems that the internal compiler error mentioned in bug
644826 hits armhf (a port which afaict was in it's infancy at the time I
filed the original bug report) as well as armel. Sorry I didn't catch
but on
arm architectures qreal is equivilent to float. So attempting to call
qMax with one argument of type double and one of type qreal fails on
arm architectures.
This patch removes a typecast so qMax is called with two arguments of
Type double.
Author: Peter Green plugw...@p10link.net
Bug
package: acovea
severity: serious
version: 5.1.1-2.1
Acovea FTBFS in unstable with the following errors.
arm-linux-gnueabihf-g++ -I. -I. -I. -I. -I.. -DACOVEA_VERSION=\5.1.1\
-DACOVEA_CONFIG_DIR=\/usr/share//libacovea/config/\
-DACOVEA_BENCHMARK_DIR=\/usr/share//libacovea/benchmarks/\ -g -O2
This was fixed already in version 3.6.0-1 uploaded to unstable
about the same time the archive rebuild was done.
Umm according to packages.qa.debian.org 3.6.0-1 and all versions
since were uploaded to experimental not unstable.
--
To UNSUBSCRIBE, email to
tags 650599 +patch
thanks
It's a bug in the snooper configure script. Applying the following
patch:
--8---cut here---start-8---
--- a/build/configure.in1998-02-23 15:18:30.0 +0100
+++ b/build/configure.in2011-12-01
: Peter Green plugw...@p10link.net
Bug-Debian: http://bugs.debian.org/652162
Index: pidgin-facebookchat-1.69/Makefile
===
--- pidgin-facebookchat-1.69.orig/Makefile 2011-12-31 22:18:01.0 +
+++ pidgin-facebookchat-1.69
retitle 586550 ffmpeg-php: FTBFS with ffmpeg = 0.6
tags 586550 +patch
thanks
ffmpeg 0.7 is now in unstable and ffmpeg-php FTBFS in unstable with the
following error.
checking whether to force gd support in ffmpeg-php... yes
configure: error: ffmpeg shared libraries not found. Make sure ffmpeg
601 - 700 of 2734 matches
Mail list logo
