Bug#667704: mosh FTBFS on armel and armhf

Package: mosh Severity: important Tags: patch Mosh FTBFS on armel and armhf, there are two issues. The first is that the program uses inline assembler which is only suitable for arm mode, this causes a failure on debian armhf and ubuntu armel and armhf which use thumb2 mode by default (it does

Bug#798885: Boot problems after installation on new self-build computer.

On 13/09/15 21:02, Peter Michael Green wrote: Unfortunately on reboot the system hung, attempting to boot with quiet removed from the kernel command line showd the last userland boot message as "Starting LSB: Prepare console". Trying to boot in recovery mode also hung showing ata related messag

Bug#775850: timblserver: FTBFS in unstable: error: 'class Timbl::GetOptClass' has no member named 'getLogFile'

timblserver (1.8-1) experimental; urgency=low . * New upstream release. - Fixes "timblserver: FTBFS in unstable: error: 'class Timbl::GetOptClass' How come this was uploaded to experimental and not unstable?

Bug#713663: fatrat: FTBFS: config.hpp:46:2: error: #error you must define either BOOST_ASIO_SEPARATE_COMPILATION or BOOST_ASIO_DYN_LINK in your project in order for asio's declarations to be correct.

tags 713663 -patch thanks Unfortunately the patch I previously sent to this bug is no longer sufficient to make the package build. I now get lots of errors like "usr/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse error at "BOOST_JOIN"" log at http://buildd.raspbian.org/st

Bug#799125: fuse-emulator-utils FTBFS, link errors, "undefined reference to `progname'"

package: fuse-emulator-utils version: 1.1.1-3fuse-emulator-utils tags: stretch sid Severity: serious Attempting to build fuse-emulator-utils on a raspbian stretch autobuilder failed with. /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-

Bug#794878: fixed in uhd 3.8.5-2.1

It appears the library rename introduced in uhd 3.8.5-2.1 was reverted in uhd 3.9.0-1. There was no mention of this revert in the changelog. Was the revert intentional and if so what was the reasoning behind it?

Bug#799823: Please version breaks/replaces to allow xbmc transition packages to be installed

Package: kodi Severity: important The xbmc packages have been turned into transition package to kodi but the transition packages are uninstallable due to the unversioned breaks/replaces in kodi. Please version the breaks/replaces so they only apply to the real packages and not the transition p

Bug#798870: geany-plugins: FTBFS with libgit2 0.23.1

Indeed. This is due to libgit2 0.23 breaking some API geany-plugins uses. Upstream added support for it in http://git.geany.org/geany-plugins/commit/?id=37aa25a1a4508c3d7559c0a2d00663b9c8d322c6, and it should be trivial and safe to cherry-pick. I applied this patch in raspbian stretch-staging*

Bug#795510: llvm-toolchain-snapshot FTBFS, apparent version number handling issues.

Package: llvm-toolchain-snapshot Version: 1:3.7~svn239806-1 Severity: serious dpkg-buildpackage: host architecture arm64 fakeroot debian/rules clean dpkg-query: no packages found matching g++-5.2 dpkg: error: --compare-versions takes three arguments: <--snip many similar errors--> dpkg-archi

Bug#793991: lazarus: armel and armhf builds stall

Oh, and by the way, it seems that the potential removal of lazarus and its reverse dependencies is not due to this bug, but because of the fixed bug 777970, see the tracker:https://tracker.debian.org/pkg/lazarus Which is now fixed in testing, so no longer an issue. And if I am correct, as l

Bug#844570: dgit cross-filesystem dsc import fails.

Package: dgit Version: 2.11 When I try to import a dsc on another filesystem dgit fails with an "invalid cross-device link" error. It seems that dgit first creates symlinks in the parent directory of the git repo pointing at the dsc and associated files (which succeeds). Then it tries to cre

Bug#863061: reprepro fails to generate contents file "Error decompressing gz data: incorrect header check -3".

Package: reprepro Version: 5.1.1-1~bpo8+1 As a result of some server issues I recently re-imported all of the raspbian repos into a new reprepro instance. A few weeks later a user complained that contents files were missing from our repo. After doing some investigation it seems that reprepro c

Bug#863061: reprepro fails to generate contents file "Error decompressing gz data: incorrect header check -3".

Tags 863061 +patch Thanks After some more hacking I got a fix that works. It seems that the "ar" code doesn't support reading a member more than once, so it is necessary to retry the whole process in uncompressed mode rather than just retrying reading the data member. Debdiff attatched, no int

Bug#858553: [Pkg-pascal-devel] Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files

On 31/03/17 19:11, Paul Gevers wrote: Hi Abou, On Fri, 24 Mar 2017 19:46:23 +0100 Abou Al Montacir wrote: OK, I'm going to have a look at the code and guess what it the issue. If I don't manage to get any idea I'll ask upstream. I am just curious, are you progressing on this issue? Did you co

Bug#853594: openmama: ftbfs with GCC-7

MamdaMultiParticipantManager.cpp:370:30: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] if (lastDot+1 != '\0') FTBFS with GCC-7 aside this just looks wrong. Firstly if they really intended to compare a pointer I would expect them to use 0 or NULL

Bug#858153: cargo: stage0 build fails

Package: cargo Version: 0.15.0~dev-1 It seems that trying to do a "stage0" build of cargo no longer works. Specifically. DEB_BUILD_PROFILES=stage0 dpkg-buildpackage -B fails with. Exception: from ./debian/bootstrap.py, line 1231: [Errno 2] No such file or directory: u'/cargo-0.15.0~dev/ven

Bug#858153: cargo: stage0 build fails

tags 858153 +patch thanks On 19/03/17 00:45, peter green wrote: It seems that trying to do a "stage0" build of cargo no longer works. After a lot of hacking I managed to get a successful stage0 build in raspbian stretch. I attach the patch I used to do so, I have not tested sai

Bug#857382: dgit quilt and symlinks

Package: dgit Version: 3.10 [ forwarding this bug to the bts ] On 10/03/17 12:15, Ian Jackson wrote: 00:00 Diziet, you might want to move the check whether fixup is needed at all before the check whether fixup can be linear. I think that if no fixup is needed then there is a trivial linea

Bug#861366: Etherpuppet, unusuable on systems with unsigned char.

Package: etherpuppet Severity: grave Tags: patch Etherpuppet has a bug with it's command line parsing that makes it unusable on systems with unsigned char. Someone found an upstream fix for me and submitted it to a raspbian bug report. A debdiff can be found at http://debdiffs.raspbian.org/ma

Bug#851873: dgit: getting apt updated wrong number of Release files (), erk at /usr/bin/dgit line 1267. when trying to push

Ian and I took a look at this bug together (via IRC) and determined the following 1. It affects dgit fetch as well as dgit push. 2. The bug is only triggered if the user's home directory is on a "noatime" filesystem. Workaround is to change the filesystem mount options from "noatime" to "rela

Bug#818432: espresso: FTBFS on armel: hangs during the build

My guess would be that the testsuite is just extremely slow on armel (which uses software floating point). Would it be possible to disable longer-running tests or is the testsuite an all-or-nothing thing?

Bug#819540: state of valadoc.

valadoc is the last remaining reverse dependency of the cruft package libvala-0.30-0 . A rc bug has been filed over a month ago but there was no maintainer response. valadoc is on the "key packages" list so it's not being autoremoved from testing. I tried changing the build-deps but a test bui

Bug#749288: raspbian support patch provided is too complicated for me to port to libv8 3.28

i'm working on updating libv8 to 3.28 (see collab-maint), and unfortunately this patch isn't obvious at all to adapt to that new version. Where exactly should I be looking? When I look at https://alioth.debian.org/scm/browser.php?group_id=30755 I see a tag for upstream 3.28 but no tags or heads

Bug#807318: libmpich-dev: should add Depends: to match hard-wired gcc dependency in mpicxx.h

/usr/include/mpich/mpicxx.h has a hardwired dependency on the gcc used to build mpich (gcc 5.2): #ifdef __GNUC__ # if __GNUC__>= 5 # if __GNUC_MINOR__> 2&& 2 == 2 # error 'Please use the same version of GCC and g++ for compiling MPICH and user MPI programs' # endif # endif #endif But the

Bug#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

Tags 805193 +patch Thanks I was able to get aster to build for raspbian stretch (in which I have imported the updated petsc from debian sid) with the changes in the attatched debdiff. I have not tried it on any other system. I have not tested if the resulting packages actually work. I will be

Bug#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

On 12/12/15 17:32, peter green wrote: I was able to get aster to build for raspbian stretch (in which I have imported the updated petsc from debian sid) with the changes in the attatched debdiff. Sorry I must learn to read the screen more carefully and actually check that something has

Bug#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

On 12/12/15 17:47, peter green wrote: On 12/12/15 17:32, peter green wrote: I was able to get aster to build for raspbian stretch (in which I have imported the updated petsc from debian sid) with the changes in the attatched debdiff. Sorry I must learn to read the screen more carefully and

Bug#805193: aster: FTBFS: Fatal Error: finclude/petscsys.h: No such file or directory

On 12/12/15 19:01, peter green wrote: New debdiff attatched, still no intent to NMU. Sorry, debdiff at http://debdiffs.raspbian.org/main/a/aster/aster_11.5.0%2bdfsg2-3%2brpi1.debdiff

Bug#807277: krfb build-depends on cruft package

tags 807277 +patch thanks In a raspbian stretch-staging environment (which has sid's ktp-common-internals) I was able to build this package after changing the build-dependency from libktpcommoninternalsprivate-dev to libktp-dev

Bug#805799: kst: Fails to build with GSL 2

severity 805799 serious thanks Upping the severity to serious as this can't be built without using cruft packages.

Bug#807919: horst: consider moving back to main

Package: horst Horst was moved from main to contrib a couple of months ago. The reason given for this was that sparse was in non-free. However since then sparse has been relicensed under MIT and moved to main. If there is no other reason to keep horst in contrib please consider moving it bac

Bug#778108: root-system: ftbfs with GCC-5

the new upstream version fixes the build failures with GCC 5. Had to work around the build failure on armhf, and enabled the builds for powerpc and ppc64el. Note that I forgot to prepare the dfsg tarball. https://launchpad.net/ubuntu/+source/root-system/5.34.30-0ubuntu3 Note that there is now a

Bug#754662: witty 3.3.3+dfsg-2 upload still has build problems

Pau Garcia i Quiles wrote: Peter, I have uploaded a new version to mentors: http://mentors.debian.net/debian/pool/main/w/witty/witty_3.3.3+dfsg-3.dsc It has all your fixes (thanks again!) minus the "leave parallelization out" stuff. Instead, I have tried to fix parallelization. The dsc I just

Bug#754662: witty 3.3.3+dfsg-2 upload still has build problems

Pau Garcia i Quiles wrote: Right, my mistake. I had uploaded an incomplete version. Please try now. I have changed debian/rules to add build-resources, which is the troublesome part, to the pre-requisites of both the static and the shared build. Still doesn't look right, the target dependenci

Bug#754662: witty 3.3.3+dfsg-2 upload still has build problems

Pau Garcia i Quiles wrote: I took the liberty of fixing these issues myself so I could test. A debdiff of what i'm testing with is attatched. Test results will follow Thank you! On an armel chroot on my personal armv7 box I got random segfaults but i've been having various

Bug#754662: witty 3.3.3+dfsg-2 upload still has build problems

peter green wrote: On the debian armel and mipsel porterboxes I got successful paralell builds. I must be getting tierd, the armel build succeeded but the mipsel one is still ongoing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubs

Bug#747237: gnuradio has picked up build-dependency on zeromq3 which build-depends on libpgm, which needs patches for ppc64el, arm64 and hurd and appears to be abandoned

I've been going through packages on debian-ports arm64 in state BD-Uninstallable/out-of-date to try and make sure we don't go backwards on coverage as we push towards becoming an official port. gnuradio is one such package, with the most recent upload it picked up a dependency on libzmq3-dev |

Bug#754662: witty 3.3.3+dfsg-2 upload still has build problems

Pau Garcia i Quiles wrote: On Wed, Aug 20, 2014 at 3:15 AM, peter green <mailto:plugw...@p10link.net>> wrote: peter green wrote: On the debian armel and mipsel porterboxes I got successful paralell builds. I must be getting tierd, the armel build succeede

Bug#758964: gcc-4.9 assembler errors when building md5 code from fbb on arm64

Package: gcc-4.9 Version: 4.9.1-7 x-debbugs-cc: f...@packages.debian.org Control:| affects -1 fbb| While building the latest version of fbb (the previous version built successfully) for arm64 the autobuilders (both on debian-ports and debian official) ran into the following error. They were usi

Bug#758227: mpg123: Add support for arm64

mpg123 currently does not understand that arm64 is a 64bit architecture causing FTBFS. The attached patch fixes the failure. I've just uploaded this patch to debian-ports arm64 unreleased. Since we are currently in the process of trying to push arm64 into debian proper we would appreciate

Bug#780905: fp-compiler-2.6.4: fpc fails to link programs using fpmkunit

On 21/03/15 12:00, Andrew Apted wrote: /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T? /usr/bin/ld.bfd: skipping incompatible /usr/lib/i386-linux-gnu/crti.o when searching for /usr/lib/i386-linux-gnu/crti.o /usr/bin/ld.bfd: cannot find /usr/lib/i386-linux-gnu/crti.

Bug#794533: fsharp FTBFS/uninstallable with mono 4.0.2.5 (currently in experimental)

Package: fsharp Version: 3.1.1.26+dfsg2-3 Serverity: important I backported mono 4.0.2.5 from Debian experimental to raspbian wheezy/jessie (I built it in wheezy but the fsharp testing was done in jessie) as we have users asking for more recent mono versions (arm support has been improving in

Bug#778103: reconserver FTBFS.

Trying to look at #778103, things stopped quite soon since your package has a build-dep on librecon-1.9-dev while the archive only has librecon-1.10-dev. I just tested the obvious change of changing the build-dependency from librecon-1.9-dev to librecon-1.10-dev and the error I got looks the

Bug#778103: reconserver: ftbfs with GCC-5

On 11/08/15 17:41, Antti Järvinen wrote: Please find attached patch to reconserver. Some comments on the patch (note: I am NOT the maintainer of this package, nor do I intend to NMU it, I will leave uploading to someone who is in a position to test the resulting package). -Build-Depends:

Bug#795331: iceweasel: backport/security builds (bundled libvpx) FTBFS on armhf

On 13/08/15 00:05, Simon McVittie wrote: As described on, a rebuild of iceweasel/38.1.1esr-1 with ~deb9u1 appended to the version number, in a stretch environment, failed to build from source on armhf. Build log:

Bug#826599: kdepim-runtime depends and build-depends on packages that are no longer built.

package: kdepim-runtime severity: serious version: 2.2.0-2 kdepim-runtime depends on libkgapi2-2 and build-depends on libkgapi-dev . These packages were previously built by the source package libkgapi but are no longer built. This appears to be fixed in the version in experimental, maybe it's

Bug#813452: Feedback from #fpc

On 25/03/16 17:45, b...@m8y.org wrote: 13:00 < Laksen> Hmm, looks like 3.0 does not have r30276. I suspect that might be the cause 13:06 < Laksen> But then it shouldn't be triggered if it's just using the default processor architecture.. 13:08 < Laksen> Which it wouldn't because that's armv3 in

Bug#819538: gnome-builder: build against vala 0.32

Found 819538 3.18.1-1 Thanks > Your package needs to be updated to build against the new vala 0.32. Testing is also affected by this issue.

Bug#797389: calligra: FTBFS, multiple issues.

Martin Michlmayr wrote (as bug 818395) calligra fails to build. I don't see any obvious errors (but I didn't look through the 22 MB of logs) but it ends with: I already mentioned this in my posts to 797389. It seems that marble no longer supports qt4. The fix I applied for raspbian was to d

Bug#695547: armhf ABI flag problems with fpc-built binaries

On 09/06/16 18:55, Steve McIntyre wrote: Hi folks, I'm one of the ARM porters, and I've recently run a scan of binaries in the archive to check on the state of the binaries for armel and armhf. As part of the ARM ABI, binaries (libraries and programs) are expected to specify ELF flags to specify

Bug#797389: calligra: FTBFS, multiple issues.

On 14/06/16 01:21, peter green wrote: I've just done a new upload of calligra in Raspbian that on top of previous fixes removes the dependency on which no longer exists. Debdiff at Apologies for not actually linking the debdiff, it's at http://debdiffs.raspbian.org/main/

Bug#823956: php-json dependency and build-dependency issues.

Package: php5-json Severity: serious Version: 1.3.7-1 php5-json depends on the cruft package libjson-c2 which is no longer built from the json-c source package. The release team attempted to schedule a binnmu but it was blocked due to the removal of dh-php5. Furthermore even in an environme

Bug#797389: calligra: FTBFS, multiple issues.

On 14/06/16 07:10, Scott Kitterman wrote: On Tuesday, June 14, 2016 01:21:26 AM peter green wrote: I am reluctant to NMU this In Debian myself because I don't use calligra personally and I have not had any feedback from anyone on the patched package. Considering it doesn'

Bug#821785: sipwitch: FTBFS: service.cpp:256:28: error: invalid conversion from 'const sockaddr*' to 'sockaddr*' [-fpermissive]

service.cpp: In static member function 'static void sipwitch::service::publish(const char*)': service.cpp:256:28: error: invalid conversion from 'const sockaddr*' to 'sockaddr*' [-fpermissive] host = resolver.getAddr(); This was easy enough to fix, just add a const to the type of the

Bug#768332: About aschi.debian.org (Was: Builds on asachi.debian.org, patch)

Anton Gladky wrote: tags 768332 +patch thanks Hi, I have just built lightsparc on asachi.debian.org successfully. But it seems, it is a armhf. It seems that the MOTD and documentation could do with some work. The motd on asachi indeed confusingly announces the system as as the "Debian armh

Bug#765154: gwave: FTBFS: build-dependency not installable: libgwrap-runtime-dev

I just tried to get this building for raspbian (due to our setup I preffer not to remove stuff from raspbian jessie until/unless it is removed from debian sid) but even making some pretty horrible hacks I just hit problem after problem after problem. My final debdiff is attached . It now fails

Bug#765154: gwave: FTBFS: build-dependency not installable: libgwrap-runtime-dev

peter green wrote: Also fun it looks like theres a build-dependency loop between this and guile-gnome-platform, so if this is removed then reintroducing it will be fun :( Seems I was mistaken on this, I think I must have confused gwave and g-wrap -- To UNSUBSCRIBE, email to debian-bugs-dist

Bug#770782: litl uses -march=armv7-a on all arm systems.

Package: litl Severity: grave Version: 0.1.1+dfsg-3 Tags: patch litl uses -march=armv7-a whenever it detects an arm system. This is pointless on debian armhf (the compiler already has it as a built-in default) and wrong on debian armel and raspbian where it will render the package unusable on

Bug#770793: eztrace uses -march=armv7-a on all arm systems.

Package: eztrace Severity: grave Version: 1.0~rc4-1 eztrace uses -march=armv7-a whenever it detects an arm system. This is pointless on debian armhf (the compiler already has it as a built-in default) and wrong on debian armel and raspbian where it will render the package unusable on the minim

Bug#793584: cyassl: remaining binary packages are uninstallable.

Package: cyassl Severity: serious wolfssl (same maintainer as cyassl) has taken over the libcyassl5 binary package. This makes libcyassl-dev and libcyassl5-dbg uninstallable. I presume this source package and it's two remaining binary packages should simply be removed. If you agree please fil

Bug#793955: emoslib FTBFS on multiple architectures, test failures.

Package: emoslib Version: 2:4.0.7-2 Severity: serious emoslib FTBFS on a number of architectures including four release architectures (mips, powerpc, ppc64el and s390x) with testsuite failures. mips/powerpc/sparc/hppa fail with The following tests FAILED: 1 - interpolation_example_g

Bug#792877: FTBFS against Octave 4.0

tags 792877 +patch thanks octave-mpi fails to compile with Octave 4.0. There is now a patch at the upstream bugreport, https://savannah.gnu.org/bugs/download.php?file_id=34167 I have applied the patch and uploaded to Raspbian. Debdiff atatched, no intent to NMU in Debian. diff -Nru octave-

Bug#789619: FTBFS: Configuring incomplete, errors occurred!

Some lucky googling turned up an upstream fix for the pkg-config issue. http://sourceforge.net/p/plplot/plplot/ci/772223c638ecf5dc740c9f3dd7a6883c6d2c83d2/ I applied the fix to the Debian package, and attemted to build the package in raspbian stretch. Unfortunately while that patch fixed the

Bug#789619: FTBFS: Configuring incomplete, errors occurred!

On 31/07/15 03:17, peter green wrote: If/when I get a sucessful build I will upload to raspbian and post a further update to this bug. No intent to NMU in Debian. After disabling octave support I ran into another less major issue. It seems that the package fails to build if tcl/tk 8.6 is

Bug#788767: monav: FTBFS with gcc 4.9/mapnik 3.0.0: requires flags for c++11 support

It seems the c++11 thing is just the tip of the iceberg, looks like the mapnik api has changed significantly (headers disappearing, types no longer existing etc). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@

Bug#752735: webkitgtk FTBFS on arm64

Alberto Garcia wrote: On Thu, Jun 26, 2014 at 01:34:38AM +0100, peter green wrote: webkitgtk failed to build on arm64, the following was the final error in the build log (there were a load of others before it too) Do we have access to a machine where we can try to fix the build

Bug#743332: openswan: Error while parsing ID_DER_ASN1_DN subject when using certificates

reopen 743332 found 743332 1:2.6.37-3+deb7u1 thanks >as the package openswan has just been removed from the Debian archive >unstable we hereby close the associated bug reports. This report was about a regression in a security update applied in stable and oldstable where the package is still pres

Bug#753938: libgraphicsmagick1-dev depends on obsolete transitional package libtiff4-dev

Package: libgraphicsmagick1-dev Severity: serious Version: 1.3.18-3 libgraphicsmagick1-dev depends on libtiff4-dev which is no longer built by the tiff source package. Please depend on libtiff-dev instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#753938: libgraphicsmagick1-dev depends on obsolete transitional package libtiff4-dev

I've just uploaded a NMU to delayed/5 with the attatched debdiff, please tell me if you have any objections so I can change or cancel it. diff -Nru graphicsmagick-1.3.18/debian/changelog graphicsmagick-1.3.18/debian/changelog --- graphicsmagick-1.3.18/debian/changelog 2014-06-19 21:28:22.

Bug#754330: healpy FTBFS on arm64 and ppc64, test failure

Package: healpy Version: 1.8.1-1 Severity: important User: debian-...@lists.debian.org Usertags: arm64 Healpy failed to build on arm64 and ppc64 with the following error: [doctest] healpy.pixelfunc.max_pixrad _ 1107 Returns 1108 --- 1109

Bug#753121: FTBFS, needs to build-depend on libgnutls28-dev / libgcrypt20-dev

libvirt's build-dependencies are uninstallable on current sid: - The following packages have unmet dependencies: libssh2-1-dev : Depends: libgcrypt20-dev but it is not going to be installed E: Build-dependencies for libvirt could not be satisfied. - Please update

Bug#754662: witty: missing builds on mips powerpc s390x

Basically it looks like you're build-depending on nodejs stuff which is not available on all architectures. Specifially the latest version of witty added a build-depends on uglifyjs. uglifyjs is a virtual package provided by the arch all package node-uglify which is only installable on architectu

Bug#753778: libfm-dev: Fails to install on arm64 and x32

I also noticed an or1k build on an unofficial archive with the same error http://wannabuild.cmd.nu/fetch.php?pkg=pcmanfm&arch=or1k&ver=1.2.0-1&stamp=1401451299 Given that this seems to be happening on at least three mostly independent architectures I doubt it's an architecture issue per-se, the

Bug#753778: libfm-dev: Fails to install on arm64 and x32

Ok I was able to reproduce the issue in a local arm64 qemu chroot. It appears the cause is a difference in filelists between architectures. amd64 has lrwxrwxrwx root/root 0 2014-07-04 06:55 ./usr/include/libfm -> libfm-1.0 While i386 and arm64 have drwxr-xr-x root/root 0 20

Bug#753778: libfm-dev: Fails to install on arm64 and x32

peter green wrote: Still stumped as to why, the obvious cause for something like this would be a directory called debian/tmp/usr/include/libfm already existing at the time the symlink was created but I can't find any evidence in the build log for the creation of such a directory at

Bug#744573: gauche: run dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4

It seems there is already logic in debian/rules to update config.sub/guess and run autoconf. Unfortunately that logic only applies to the top level program, not to the embedded copy of libatomic_ops which also has a copy of config.sub/guess. The attatched patch fixes that. Unfortunately when

Bug#752463: ode: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

Attatched is a more complete debdiff (breno's one lacked a changelog entry and lacked the build-depends on dh-autoreconf) which I have just uploaded to debian-ports arm64 unreleased. The porters would appreciate it if you could include this in the next upload. If it doesn't get uploaded soon a

Bug#700276: dirac also FTBFS on arm64, fix is the same as for x32.

user debian-...@lists.debian.org usertags 700276 +arm64 retitle 700276 dirac: FTBFS on x32 and arm64 Needs autotools update thanks Dirac also ftbfs on arm64, the reason for the ftbfs is different (outdated config.sub rather than outdated libtool) but the fix is the same, use dh-autoreconf to up

Bug#756085: notmuch: please move away from emacs23-nox as default build-dependency

Package: notmuch Severity: important Tags: jessie,sid Your package currently build-depends on emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) | emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) Debian autobuilders only consider the first option in a set of alternative dependencies

Bug#756172: ITP: ssh-cron -- cron-like job scheduler than handles ssh key passphrases

ssh-cron acts like cron, but is provided with ssh passphrases allowing its commands to access remote systems without requiring a passphrase to be stored in a clear-text file or resorting to ssh keys without passphrases. How is it provided with them? is the user required to enter them on s

Bug#756354: regina-rexx FTBFS on arm64. Outdated config,sub/guess

Package: regina-rexx Version: 3.6-2 Severity: important User: debian-...@lists.debian.org Usertags: arm64 UNAME_VERSION = #4 SMP Mon Mar 24 10:24:20 CST 2014 configure: error: cannot guess build type; you must specify one make: *** [stamp-configure] Error 1 This is caused by outdated config.s

Bug#756720: Debian build infrastructure refuses to build packages where only build-dependency is arch qualified (e.g. runit)

Package: buildd.debian.org Debian autobuilders are currently refusing to build runit on many architectures (both official and unofficial) with the following message[1][2] runit build-depends on missing: - empty-dependency-after-parsing The immediate cause seems to be that runit recently removed

Bug#755322: gst-plugins-bad0.10: FTBFS: dh_install: gstreamer0.10-plugins-bad missing files (debian/tmp/usr/lib/*/gstreamer-0.10/libgstrtmp.so)

The underlying problem seems to be. configure: *** checking feature: rtmp library *** configure: *** for plug-ins: rtmp *** checking for RTMP... no configure: Package 'gnutls', required by 'librtmp', not found configure: *** These plugins will not be built: rtmp It would appear that despite the m

Bug#785770: RM: xserver-xorg-video-siliconmotion [arm64] -- RoP; FTBFS; out-of-date; uninstallable; quite possiblly never worked, little if any utility

Package: ftp.debian.org x-debbugs-cc: debian-...@lists.debian.org,debia...@lists.debian.org A recent xorg update caused xserver-xorg-siliconmotion to fail to build with the following error. /bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../src -I..

Bug#791824: nmu: starpu_1.1.4+dfsg-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu starpu_1.1.4+dfsg-1 . ALL . -m "Rebuild for gcc 4.9.3" starpu seems to have a strict dependency against the version of gcc-4.9 it was built against. This is blocking the migration of 4.9

Bug#791865: kactivities-kf5 FTBFS on armel, symbols files issues.

Package: kactivities-kf5 Version: 5.11.0-1 Severity: serious Your package fails to build on armel with a symbols file error. dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libkf5activities5/DEBIAN/symbol

Bug#783672: cdebootstrap: Please support stretch/testing

severity 783672 grave thanks It is currently not possible to install a testing/stretch system using cdebootstrap(-static) and it would be nice if it could. "would be nice" is a massive understatement. I really think a debian bootstrapping tool that can't bootstrap the release it's shipping in h

Bug#784778: FTBFS: no matching function for call to 'condor_sockaddr::condor_sockaddr(const soap::*)'

Tags 784778 +patch thanks oops really attatched this time. During a binNMU of condor for the gsoap transition, the following error was encountered on all architectures: /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp: In function 'bool stub_prefix(const char*, const soap*, int, int, D

Bug#784778: FTBFS: no matching function for call to 'condor_sockaddr::condor_sockaddr(const soap::*)'

Tags 784778 +patch thanks During a binNMU of condor for the gsoap transition, the following error was encountered on all architectures: /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp: In function 'bool stub_prefix(const char*, const soap*, int, int, DCpermission, bool, soap_schedd::c

Bug#785491: xserver-xorg-video-siliconmotion FTBFS on arm64, implicit declarations of inb and outb

Package: xserver-xorg-video-siliconmotion Severity: serious Version: 1:1.7.7-2 Tags: sid x-debbugs-cc: debian-...@lists.debian.org /bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../src -I.. -D_FORTIFY_SOURCE=2 -fvisibility=hidden -I/usr/include/pixman-

Bug#785491: xserver-xorg-video-siliconmotion FTBFS on arm64, implicit declarations of inb and outb

On 17/05/15 02:23, Steven Chamberlain wrote: I don't think any change in xserver-xorg-video-siliconmotion caused this. I agree (and stated so in my original mail), the failure first appeared in a binnmu so whatever change triggered it was outside the xserver-xorg-video-siliconmotion package.

Bug#786819: netsurf: FTBFS with libgdk-pixbuf2.0-dev 2.31.4-1: gtk/window.c:55:14: error: unknown type name 'GdkPixdata'

>A debdiff fixing this bug is attached. Sebastian's patch seems sane to me, the resulting package seems to work and there has been no maintainer response to this bug report. So I have uploaded as a NMU (haven't got the "accepted" mail yet though), NMU debdiff attatched. diff -Nru netsurf-3.2+df

Bug#786819: netsurf: FTBFS with libgdk-pixbuf2.0-dev 2.31.4-1: gtk/window.c:55:14: error: unknown type name 'GdkPixdata'

On 02/06/15 03:36, peter green wrote: >A debdiff fixing this bug is attached. Sebastian's patch seems sane to me, the resulting package seems to work and there has been no maintainer response to this bug report. So I have uploaded as a NMU (haven't got the "accepted"

Bug#786819: netsurf , pixbufs, implicit declarations, mismatched externs, arm64 and Debian

Recently a rc bug was filed on netsurf in the Debian bug tracking system due to a build failure. netsurf FTBFS if built against libgdk-píxbuf2.0-dev 2.31.4-1 which is currently in unstable: | COMPILE: gtk/window.c | gtk/window.c:55:14: error: unknown type name 'GdkPixdata' | extern const GdkP

Bug#787679: sqlitebrowser: testsuite fails in several environments, TestImport::csvImport(utf8chars) Compared values are not the same

Package: sqlitebrowser Severity: important version: 3.5.1-2 sqlitebrowser failed to build in raspbian stretch with the following error. FAIL! : TestImport::csvImport(utf8chars) Compared values are not the same Loc: [/«PKGBUILDDIR»/src/tests/TestImport.cpp(52)] PASS : TestImport::cleanupTes

Bug#787679: sqlitebrowser: testsuite fails in several environments, TestImport::csvImport(utf8chars) Compared values are not the same

On 04/06/15 17:58, Arto Jantunen wrote: The obvious big difference between the normal amd64 build daemon and the reproducible test one is that reproducible builds with pbuilder instead of sbuild. I assume raspbian is built the normal way with sbuild? Yes the raspbian autobuilders use sbuild. On

Bug#777024: gmediarender segfaults on startup on armel, raspbian and possiblly other architectures if gstreamer1.0-plugins-bad is installed.

notfound 777024 1.4.3-2 found 777024 1.4.4-2 thanks Sorry screwed up the version number -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738760: libav: Add proper raspberry pi CPU detection

On 12/02/15 00:29, Sebastian Ramacher wrote: Hi Peter, Rasbperry Pi 2 has now been released and, if I read the news correctly, it supports NEON instructions. Should we revert the changes or do they need any modifications? That is a question that will need some experimentation/testing to ans

Bug#772618: cwebx FTBFS on btrfs, incorrect test command

Package: cwebx Severity: important Tags: patch cwebx failed to build on the raspbian jessie autobuilders with the following error. The build was tried twice so I do not belive this was a fluke. make[1]: Entering directory '/«PKGBUILDDIR»' test -s debian/cwebx/usr/bin || mkdir debian/cwebx/usr

Bug#775044: openjdk-7: FTBFS: java.lang.RuntimeException: time is more than 10 years from present: 1104530400000

peter green wrote: I have just prepared a patch against wheezy's openjdk-6 to disable the timebomb code. I have attatched this patch which I am currently in the process of testing. I have tested that my patch results in succesful builds of openjdk-6 and openjdk-7 in raspbian w

<    3   4   5   6   7   8   9   10   11   12   >