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: elfutils
version: 0.152-1
severity: serious
From the debian buildd logs for 0.152-1+b1 (copy/paste taken from the
kfreebsd-i386 one but kfreebsd-amd64 looks similar)
make[2]: Entering directory
`/build/buildd-elfutils_0.152-1+b1-kfreebsd-i386-3v8mAz/elfutils-0.152/tests'
tags 646457 +patch
thanks
cc -I./../../include -I../../include -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-Wall -c ./cvode.c -fPIC -DPIC -o .libs/cvode.o
./cvode.c: In function 'CVProcessError':
./cvode.c:4131:5: error: format not a
tags 628278 - unreproducible
severity 628278 important
thanks
ccing the imagemagick developers because the proper way to fix this
issue would probablly be to change the imagemagick packaging.
tags 628278 + unreproducible
thanks
I've managed to reproduce it but it requires a fairly specific
reopen 642144
retitle 642144 mmpong ftbfs in unstable ( fatal error:
RendererModules/OpenGLGUIRenderer/openglrenderer.h: No such file or
directory )
thanks
Unfortunately the fix to gcc was not sufficiant to get mmpong building
in sid. It now fails with.
[ 77%] Building CXX object
Retitle 639189: shrinksafe FTBFS, build-depends unsatisfiable in sid due
to build-conflicts.
thanks
Build-Depends-Indep: default-jdk, rhino (= 1.7R1)
Build-Conflicts-Indep: rhino (= 1.7R3)
The current version of rhino in sid is 1.7R3
Attempting to build with the build-conflicts removed leads
Retitle 639189 shrinksafe FTBFS, build-depends unsatisfiable in sid due to
build-conflicts.
thanks
Build-Depends-Indep: default-jdk, rhino (= 1.7R1)
Build-Conflicts-Indep: rhino (= 1.7R3)
The current version of rhino in sid is 1.7R3
Attempting to build with the build-conflicts removed leads to
Tags 643459 +patch
thanks
patch is attatched
diff -ur pngquant-1.0/pngquant.c pngquant-1.0.new/pngquant.c
--- pngquant-1.0/pngquant.c 2002-04-05 18:38:33.0 +
+++ pngquant-1.0.new/pngquant.c 2011-11-10 20:47:19.0 +
@@ -258,7 +258,7 @@
VERSION);
retitle 624285 polyorb: FTBFS: build-dependends on packages which are not
co-installable (gnat and gnat-4.6)
tags 624285 +sid wheezy
thanks
The following packages have unmet dependencies:
sbuild-build-depends-polyorb-dummy : Depends: gnat but it is not going to be
installed
E: Broken
tags 643461 +patch
thanks
Patch is attatched just add it to the quilt series.
Index: qhull-2009.1/src/io.c
===
--- qhull-2009.1.orig/src/io.c 2011-11-10 21:43:30.0 +
+++ qhull-2009.1/src/io.c 2011-11-10
tags 646490 +patch
thanks
I have attatched a patch which can simply be added to the quilt series.
However while fixing the format security errors I noticed some other
rather concerning warnings. In particular I noticed
misc.c: In function ‘addUniqueRow’:
misc.c:176:13: warning: implicit
Tags 643448 +patch
thanks
Patch is attatched just drop it in debian/patches (the package uses
simple-patchsys so no series file is needed).
diff -Nur -x '*.orig' -x '*~' nvramtool-0.0+r3669/hexdump.c nvramtool-0.0+r3669.new/hexdump.c
--- nvramtool-0.0+r3669/hexdump.c 2008-09-27
tags 640444 +patch
thanks
I have attached a patch to debian/rules to add -lm to the linker flags,
this makes the package build succesfully.
--- gtkhtml3.14-3.32.2/debian/rules 2011-02-06 13:16:56.0 +
+++ gtkhtml3.14-3.32.2.new/debian/rules 2011-11-10 01:44:57.0 +
@@
tags 643456 +patch
thanks
I've attatched a patch that fixes the build.
In the process of fixing one of the format security warnings I also
fixed a potential (but almost certainly non-exploitable and highly
unlikely to happen by accident) buffer overflow.
Only in pidgin-festival-2.4:
tags 636559 +patch
thanks
oops sent this to the wrong bug report
Note that despite the bug title this issue is not alpha specific, it impacts
all architures.
I've attatched a patch that gets the package building again. Within the patch
are three fixes
1: improve debian/rules clean. It's not
tags 639152 +patch
thanks
sbuild-build-depends-csmash-dummy : Depends: libsdl1.2-dev but it is not going
to be installed
Depends: libsdl-mixer1.2-dev but it is not
going to be installed
Depends: libsdl-image1.2-dev but
tags 636559 +patch
thanks
Patch is attatched, just drop it in debian/patches (the package uses
simple-patchsys so no series file is needed)
diff -Nur -x '*.orig' -x '*~' d52-3.4.1/d52pass2.c d52-3.4.1.new/d52pass2.c
--- d52-3.4.1/d52pass2.c 2007-09-02 15:31:16.0 +
+++
tags 643370 +patch
thanks
Patch is attatched, just drop it in debian/patches (the package uses
simple-patchsys so no series file is needed)
diff -Nur -x '*.orig' -x '*~' d52-3.4.1/d52pass2.c d52-3.4.1.new/d52pass2.c
--- d52-3.4.1/d52pass2.c 2007-09-02 15:31:16.0 +
+++
tags 636802 +sid wheezy
thanks
Squeeze has crti,o in the traditional location so it shouldn't be
affected by this bug.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 636559 +patch
thanks
Note that despite the bug title this issue is not alpha specific, it impacts
all architures.
I've attatched a patch that gets the package building again. Within the patch
are three fixes
1: improve debian/rules clean. It's not perfect but at least it avoids
tags 625356 +patch
thanks
Patch is attatched.
--- indicator-session-0.2.17/src/users-service-dbus.c 2011-01-17 17:06:30.0 +
+++ indicator-session-0.2.17.new/src/users-service-dbus.c 2011-11-05 09:44:36.0 +
@@ -586,7 +586,6 @@
which seems to cause a FTBFS. This patch fixes the version in
index.docbook to match the DTD
Fix inspired by the one for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628318
Author: Peter Green plugw...@p10link.net
Bug-Debian: http://bugs.debian.org/640956
--- komparator-0.3.orig/doc
tags 643040 +patch
thanks
The full build log is available from:
http://people.debian.org/~lucas/logs/2011/08/23/abcm2ps_5.9.22-1_lsid64.buildlog
http://people.debian.org/%7Elucas/logs/2011/08/23/abcm2ps_5.9.22-1_lsid64.buildlog
That gives a 404 for me.
When I tested it the package built
abiword's migration to testing is blocked by a dependency on psiconv
psiconv's migration to testing is blocked by the following bug
http://bugs.debian.org/609535 psiconv: magick/semaphore.c:526:
LockSemaphoreInfo: Assertion `semaphore_info-signature == 0xabacadabUL'
failed.
That bug in turn is
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 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;
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-rc-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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
The full build log can be found at:
http://people.debian.org/~doko/tmp/werror/opensync_0.39-4_lsid64.buildlog
http://people.debian.org/%7Edoko/tmp/werror/opensync_0.39-4_lsid64.buildlog
The last lines of the build log are at the end of this report.
Erm there are no lines of build log at the
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
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
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
: 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
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-rc-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-rc-requ...@lists.debian.org
with a subject
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
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
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 +
+++
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: my fairly clean sid pbuiler
Could you provide more information on the environment in which you
encounted this bug. In
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-rc-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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-rc-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 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?
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 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
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
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
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
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
:
peter green plugw...@p10link.net
Date:
Wed, 21 Jul 2010 10:41:04 +0100
To:
sub...@bugs.debian.org
To:
sub...@bugs.debian.org
Package: hivex
Version: 1.2.2+git20100712-2
Severity: important
According to
https://buildd.debian.org/build.cgi?pkg=hivexdist=unstable the
autobuilders built hivex
I have tried and failed to reproduce this issue in qemu with an up to
date sid. Can anyone else reproduce it? Since both failures have been
from the same buildd I wonder if it's some issue with the particular buildd.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
During testing to try and locate the source of the issue with the
algorithm header I discovered the problem can be got arround by
reordering header includes so that system headers are included before
other headers. I attatch a patch that does that for the two source files
that are impacted by
I attatch a patch (suitable for adding to the quilt series) that does
that for the two source files that are impacted by this issue and
fixes another compilation issue (I'm not sure of the correctness of
that second fix and as such am not applying the patch tag please check
it before
As of right now this issue only seems to affect builds on sid not on
squeeze or wheezy.
The offending line is GKeyFile *alarm; which seems to conflict with a
new addition to the standard headers.
The strange thing is I can't seem to find any evidence that variable is
ever used either by
tags 614772 +patch
thanks
Looks like /cli-common-dev needs to be moved from build-depends-indep to
build-depends.
/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
Package depends on obsolete x-dev
It looks like this is a package on it's way out anyway, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516826
Just pointing this out in case anyone else sees this in an rc bugs list to stop
them wasting time investigating it.
--
To UNSUBSCRIBE,
tags 575856 +patch
thanks
From my testing it appears to be sufficiant to simply drop the
build-dependency on x-dev to fix this.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I just took a quick look (i'm just doing flyby looks at rc bugs, I don't
have anything to do with this package) and it appears it isn't a simple
case of missing build-depends. The build-depends is there but qualified
with [linux-any], presumablly that qualification is there because
found 593049 1.0.12.debian-1
thanks
I have just confirmed that this issue also impacts building squeezes
version in squeeze
Looking at config.log for insight it seems something screwy with CFLAGS
configure:5403: checking osso-log.h usability
configure:5403: gcc -c -g -O2 -Wall -g -O2
tags 605816 +patch
thanks
The attached patch points $HOME for the build at a subdirectory of the
build tree (which is created in build and nuked in clean) allowing the
package to be built by users with a nonexistent homedir and ensuring
that the users homedir can neither affect or be affected
A new version of debian/patches/kfocus_1.0.2-16.diff reducing the
counter limit to 20 (unfortunately it seems cdbs-edit-patch rebuilt
the patch in a sufficiantly different way that diffing old patch and
new patch gives no meaninful result) is attatched which seems to fix
the immediate
This seems to be another case of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595934
apt-get install automaken gives:
Package automaken is a virtual package provided by:
automake1.9 1.9.6+nogfdl-3.1
automake1.7 1.7.9-9.1
automake 1:1.11.1-1
automake1.10 1:1.10.3-1
You should explicitly
reassign 595829 libnspr4-dev
retitle 595829 dependencies in libxul-unstable.pc and libxul.pc are
stricter than dependencies of package
thanks
libxul.pc and libxul-unstable.pc contain Requires: nspr = 4.8.6 .
However xulrunner-dev only has an unversioned dependency on libnspr4-dev
and the
This looks like (haven't tested) another case of the same issue as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595829
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This looks like a similar issue to Package 'Mozilla Plug-In API' requires 'nspr = 4.8.6' but
version of NSPR is 4.8.4 vs Package 'libxul' requires 'nspr = 4.8.6' but version of NSPR
is 4.8.4
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584156 flightgear
is uninstallable in sid due to dependencies on an outdated
libopenscenegraph. Trying to rebuild it reveals that simgear (one of
it's build-depends) has the same problem so please binnmu them both.
nmu simgear _1.9.1-2 .
reopen 583206
thanks
The build still fails with the same error.
https://buildd.debian.org/fetch.cgi?pkg=mrtrixarch=kfreebsd-amd64ver=0.2.8-2stamp=1274896210file=logas=raw
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
with camera support disabled
Author: Peter Green plugw...@p10link.net
Index: shotwell-0.5.2+dfsg/Makefile
===
--- shotwell-0.5.2+dfsg.orig/Makefile 2010-05-12 02:36:21.0 +
+++ shotwell-0.5.2+dfsg/Makefile 2010-05-26 23:27
I tried changing the build-dependency from libv4l-dev to libv4l-dev
[!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] however the build then
failed on kfreebsd-i386 with a seemingly unrelated error.
`/root/amsn-0.98.3/debian/amsn-data/usr/share/amsn/utils/asyncresolver/libasyncresolver.so':
No such
block 583096 by 577291
thanks
As well as build-depending on libpetsc3.0.0-dev life also build-depends
on libslepc3.0.0-dev. That package is still in the archive but is
uninstallable and has unsatisfiable build-dependencies.
Trying to build the slepc package with libpetsc3.1-dev and
tags 582874 +patch
thanks
I can confirm that export CONFIG_SHELL=/bin/bash in debian/rules makes
this package build (interestingly manually calling configure with bash
doesn't).
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
tags 582875 +patch
thanks
I have confirmed that the CONFIG_SHELL soloution works for this package.
Attatched is a patch that does that and also fixes an issue with the
clean target not cleaning up properly
diff -ur cluster-glue-1.0.5/debian/rules cluster-glue-1.0.5.new/debian/rules
---
Package: seed
Version: 2.30.0-1
Severity: serious
Seed fails to build on ia64. Unfortunately I don't have access to an
ia64 system so I can't debug this myself.
https://buildd.debian.org/fetch.cgi?pkg=seedarch=ia64ver=2.30.0-1stamp=1270425014file=logas=raw
make[5]: Entering directory
Upstream claims to have fixed amd64 support in the latest release
(released in 2007!). I have tried but so far failed to build a debian
package of the latest version to see if it fixes the issue in this bug.
(note: i'm just taking flyby looks at rc bugs, I have not done any
thorough testing)
tags 582098 +patch
thanks
One workaround is to explicitly call 'bash ./configure' from debian/rules.
I can confirm that with this changed in BOTH places in debian/rules
(debian/rules runs configure twice, once in configure-stamp and once in
configure-php5-stamp) the package builds
for non-linux ports
Add support for freebsd and hurd (hurd untested) to makefile
.
Disable camera support (which appears to depend heavilly on gudev which in turn
depends on udev which is linux specific) on freebsd and hurd
.
Fix a build issue with camera support disabled
Author: Peter Green
A patch implementing the above is attatched ready for adding to the
quilt series
As well as the quilt patch (which doesn't change the debian dir) it is
also nessacery to modify debian/control replacing libgudev-1.0-dev (=
145) with libgudev-1.0-dev (= 145) [!kfreebsd-i386 !kfreebsd-amd64
Rick Thomas wrote:
I own both G3's and G4's running Debian Stable. I can take them down
for limited periods (a day or so) to run other versions of Debian.
If someone who knows what he/she's doing can walk me through the steps
(I'm an experienced system admin. But I'm not a developer.) I'm
1301 - 1400 of 1818 matches
Mail list logo
