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 an
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 agai
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 pack
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\" -DMANUAL_PATH=\"/usr/share/doc/qtiplot/
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
t
ctures qreal and double are the same type 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 d
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
severity 656602 serious
thanks
>The S390x build log indicates that the new darkplaces has grown more
>Software renderer calls,
As of course do the build logs for most other architectures
Since this FTBFS happens on release architectures where the packages
have been built before it's severity ser
package: libzen
severity: serious
libzen failed to build on most* 32-bit architectures with the following
error
../../../Source/ZenLib/Ztring.h:201:13: error: 'ZenLib::Ztring&
ZenLib::Ztring::From_Number(size_t, ZenLib::int8u)' cannot be overloaded
../../../Source/ZenLib/Ztring.h:186:13: erro
package: quisk
version: 3.5.11-1
severity: serious
quisk fails to build in a clean build environment with the following error
E: dh_python2:145: extension for python2.6 is missing. Build extensions
for all supported Python versions (`pyversions -vr`) or adjust
X-Python-Version field or pass --
package: libhmsbeagle
version: 1.0-1
severity: serious
Your package builds with the following unaceptable compiler options.
-march=native
This is unacceptable on any architecture because packages must be built
for the
lowest processor a port supports, not for whatever processor the build
machi
Package: gcc-defaults
severity: important
version: 1.111
gcc-defaults recently switched the default gdc to gdc-4.6 and in the
process dropped the gdc binary package on architectures that don't have
gdc-4.6 (armel, ia64, mips, mipsel, powerpc, s390, sparc, armhf and
s390x). This is blocking the
package: med-fichier
version: 3.0.3-2
severity: serious
tags:patch
med-fichier FTBFS in current unstable with the following error
/bin/bash ../../../libtool --tag=CC --mode=compile mpicc -DHAVE_CONFIG_H -I.
-I. -I../../../include/2.3.6 -I../../../include/2.3.6 -DH5_USE_16_API
-I/usr/include
Jörg Kurlbaum wrote:
>The following packages have unmet dependencies:
> openjdk-6-jdk : Depends: openjdk-6-jre (>= 6b18-1.8.10-0+squeeze2)
but it is not going to be installed
> E: Broken packages
>
>I suspect some misconfiguration of apt. But could not find any hints
Can you post the complete
package: libhmsbeagle
version: 1.0-2
severity: serious
Note: i'm not an expert on this package, just someone looking at build
failures and filing bugs.
It seems things are a little more complex than they first appeared. In
particular it seems libhmsbeagle has a specific "sse2 plugin" which c
Jonathan Nieder wrote:
So what are the possible means of getting around the problem?
Me providing a login to an Alpha with an up-to-date unstable chroot?
A sponsored upload of aboot? Does that require at least a DM to prepare
the package?
Could you become a DD? I'm confident in your sk
The FTBFS is caused by a rather hacky patch[1] I included in -3 to fix an FTBFS
in s390[2].
Is there a better way of doing this without rewriting the parts of the library
that use the NEED_SIZET macro to use templates? Specifically, it looks like I
would need a preprocessor conditional to check
tags 656789 +patch
thanks
Builds of scid in minimal environments (such as the autobuilders) are
failing:
The package already build-depends on tcl8.5-dev and it built fine when I tried
it in my pbuilder just now.
Taking another look at the failed build log on i386 I saw the following.
conf
package: ideviceinstaller
version: 1.0.0-1.1
severity: serious
tags: patch
gcc -DHAVE_CONFIG_H -I. -I..-Wall -Wextra -Wmissing-declarations
-Wredundant-decls -Wshadow -Wpointer-arith -Wwrite-strings -Wswitch-default
-Wno-unused-parameter -Werror -g -pthread -I/usr/include/glib-2.0
-I/usr/l
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'
src/digit
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 ubuntu
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] E
Aaron M. Ucko wrote:
peter green 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 installing libaxis2
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
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 listma
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 sam
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", presum
uilding without SSE
+ The CPU_SSE plugin does not build without -msse
+Author: Peter Green
+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
+ar
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 listm
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 t
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=\"gmim
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
-D_FILE_OFF
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 fo
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
incom
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 l
sorry. the real changes are in
configure.ac, src/Makefile.ac and
Author: Peter Green
---
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: qtwebkit
Severity: important
https://buildd.debian.org/status/fetch.php?pkg=qtwebkit&arch=armhf&ver=2.2.0-3&stamp=1331681029
Looks like some tweaks to the symbols file are needed.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". T
/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 plugin
Severity 665489 important
Tags 665489 patch
Thanks
>Currently the builds fail on those Archs with "your system is not
supported"
The attatched patch fixes the build on kfreebsd, it simply changes the
conditions in a few ifdefs to handle kfreebsd in a reasonable manner (in
one case like freebsd
Just to let you know (I should have posted this earlier) I got
completely lost trying to fixup the assembler init code and gave up on
my attempts. I may come back to this bug later (right now armhf is more
important to me than kfreebsd), in the meantime if anyone else wants to
pick it up i'll p
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
dpkg-b
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 = $(shel
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/: b
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
Bug-
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
--- libgconf-bridge-0.1/libgconf-brid
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 jlint-3.0/debian/rul
I pulled that change into another 1.13 release, it is a bit different from your
patch. Could you (peter?) test
http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now?
I extrated the tarball on an armhf system and did ./configure and make
and it seemed to build successfully. I have
Package: audacious
Version: 3.2-2
Severity: normal
Tags: patch
In version 3.2-2 the optimisation level was dropped on sparc to work
arround a compiler bug. This compiler bug has now been fixed and i've
confirmed the package builds without the workaround so please remove it
in the next upload (
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 erro
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
##
## All lines beginning with `## DP:' are a descripti
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
Package: qapt
Version: 1.3.0-1
from the armel build log
cd /build/buildd-qapt_1.3.0-1+b1-armel-vECdlq/qapt-1.3.0/obj-arm-linux-gnueabi/src
&& /usr/bin/c++ -Dqapt_EXPORTS -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-std=c++0x -fno-th
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 debian-
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
/build/buildd-ruby-redcarpet_2.1.1-1-armel-YKFnOe/ruby-re
package: qpdfview
severity: important
version: 0.3~beta2-1
tags: patch
Your package failed to build on armel and armhf
sources/documentview.cpp: In member function ‘void
DocumentView::preparePages()’:
sources/documentview.cpp:2121:40: error: no matching function for call to
‘qMax(qreal&, dou
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 ora
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.
Th
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 opti
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: *** [bu
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 2012-
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 it's
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
tst-ca
We thought a dynamic linker path had been agreed across distros but when
it actually came to pushing stuff upstream a load of new people brought
their paintbrushes to the bikeshed and the dynamic linker path was
changed to /lib/ld-linux-armhf.so.3 . The attatched patch updates the
fpc package t
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
b
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 scann
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
-D_BSD
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 "unsubsc
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
--- libsvm-3
I did some local tests and it ext3grep seemed to work. Everything that
was restored was restored correctly though it did not restore everything
I deleted from the test image (but then it can't nessacerally be
expected to, some stuff may dissapear from the journal before ext3grep
can see it).
Package: calligra
Version: 1:2.4.2-1
Severity: serious
callira FTBFS on armel and armhf with the following error
/build/buildd-calligra_2.4.2-1-armhf-0fWQX5/calligra-2.4.2/plugins/pathshapes/rectangle/RectangleShape.cpp:64:85:
error: no matching function for call to 'qMin(double, qreal)'
/buil
> 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_re
tags 675894 +pending
thanks
In light of the impending freeze I just uploaded a NMU for this to
delayed/5. Debdiff is attached, please tell me if you have any problems
with the upload.
diff -Nru lazarus-0.9.30.4/debian/changelog lazarus-0.9.30.4/debian/changelog
--- lazarus-0.9.30.4/debian/cha
- 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 t
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 seper
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
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 wo
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 listmas...@lis
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 listmas...@lis
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
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad '--exclude=CVS' '--exclude=.svn'
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 build
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
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 fo
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;
XWMH
Package: FPC
Severity: important
Tags: patch
I have recently produced a working port of freepascal to armhf. The
patch has been submitted upstream at
http://bugs.freepascal.org/view.php?id=21554 and has been accepted in
trunk http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=20660
You tagged these bugs as pending about a week ago. We (the armhf
porters) could really do with getting them fixed as it is leading to an
out of date package in armhf testing and we are trying to get to release
architecture status.
Any ETA on an upload?
--
To UNSUBSCRIBE, email to debian-bug
I'll review the patch and apply it for next upload.
While browsing commit logs of the upstream repo I spotted that one chunk
of my
patch had been reverted, apparently it was both unnessacery (it was one
of the first
hunks I wrote before I really figured out what was going on) and causing
p
Abou Al Montacir wrote:
>>Please hold off the upload until I have rerun my testing with that
hunk removed.
>No Problem, but in any case we will enable this 2.6.0
As I said in a slightly later mail I have now tested removing the
problem hunk from my backported
patch and retested things.
Please
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 t
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
Package: fake-hwclock
Severity: important
Tags: patch
I've just written a manpage for fake-hwclock. Patch containing the
manpage is attached
This is my first attempt at writing a manpage so please give
constructive criticism.
diff -urN fake-hwclock-0.4/debian/fake-hwclock.manpages fake-hwcloc
>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 gcon
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. Further
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: mpg123
Version: 1.13.7-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: armhf
mpg123 FTBFS on armhf with the following errors.
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM
Package: mpg123
Version: 1.13.7-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: armhf
mpg123 FTBFS on armhf with the following errors.
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM
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"
&& /u
601 - 700 of 2889 matches
Mail list logo
