Bug#717331: gst-plugins-bad1.0: FTBFS on i386, kfreebsd-i386 and powerpc

Instead of disabling -Wl,--as-needed, try explicitly linking the offending module against libc (-lc). See similar bug #719485 in inventor [1]. [1] http://bugs.debian.org/719485

Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

Package: nvidia-opencl-dev Version: 5.5.22-4 Severity: serious Tags: patch Dear maintainer Installing ocl-icd-libopencl1 followed by nvidia-cuda-toolkit results in the following error: dpkg: error processing archive /var/cache/apt/archives/nvidia-opencl-dev_5.5.22-4_amd64.deb (--unpack):

Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 22/07/2014 14:59, Tomasz Rybak wrote: Why did nvidia-cuda-toolkit tried to install nvidia-opencl-dev when you had ocl-icd-libopencl1 installed? From what I can tell, because of the missing 'conflicts'. $ apt-cache show nvidia-cuda-toolkit Package: nvidia-cuda-toolkit Version: 5.5.22-4

Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 29/07/2014 12:41, Stefano Rivera wrote: The first option allows higher installability. The second option keeps all the relationships confined to ocl-icd-libopencl1, which is the package breaking policy (#679228). Thanks Stefano. I had a closer look at ocl-icd and I think I am seeing the

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

Hi Vincent On 30 July 2014 18:23, Vincent Danjean vdanjean...@free.fr wrote: As this bug remains me this situation, I'm proposing that we move the libOpenCL.so symlink into the dev package. Intel told me long ago that they will fix their license so that we can redistribute their

Bug#755513: Bug#679228: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 31/07/2014 09:59, Vincent Danjean wrote: all *-libopencl1 conflict/replace themselves as they provide the same binary (libOpenCL.so.1) And we need to put the correct conflict/replace for the libOpenCL.so. It is not hard but this file is (was?) not handled the same way by all OpenCL packagers.

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 01/09/2014 17:00, Vincent Danjean wrote: On 19/08/2014 15:52, Graham Inggs wrote: Breaks: ocl-icd-libopencl1 ( 2.1.3-5) Replaces: ocl-icd-libopencl1 ( 2.1.3-5) Add a tilde to allow backports. OK, understood. Here is what I put in the package I will upload this evening: Package: ocl-icd

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

Hi Vincent On 02/09/2014 18:44, Vincent Danjean wrote: Yes for -dev packages. But what if a user with nvidia-libopencl1/stable installed (ie *not* the -dev package) tries to install amd-opencl-dev/testing ? You are absolutely correct. I have checked amd-libopencl1 and nvidia-libopencl1 from

Bug#722162: [Debichem-devel] Bug#722162: libghemical: library underlinked

tags 722162 patch thanks Hi The attached patch fixes the underlinking of the mpi library. There may be better ways to fix this. If nobody else jumps in, I will work on this next week and include the autoreconf changes from Ubuntu. Regards Graham --- a/configure.ac +++ b/configure.ac @@ -148,6

Bug#763909: viewmol: /usr/bin/viewmol missing for most archs

Source: viewmol Version: 2.4.1-20 Severity: serious Hi Maintainer I noticed that /usr/bin/viewmol is only present in the amd64 viewmol package. For all other archs built on the buildds, /usr/bin/viewmol is missing. Excerpt from the i386 build log: make[1]: Entering directory

Bug#735516: python-liblas: hardcoded dependency on liblas1 which is no longer built by liblas

tags 735516 patch thanks Hi Maintainer The attached patch to src:liblas builds the python-liblas package as well. I haven't done extensive testing, but it builds in my Ubuntu PPA and seems to produce debs with all the correct files in place. If this is going to be uploaded, src:python-liblas

Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

On 10 April 2014 18:06, Alexander Koblov alexx2...@mail.ru wrote: I suggest the following solution: add also one debian package that will include binary versions of visual components (like SynEdit, that depends on widgetset) compiled for LCL-Qt widgetset (something like lcl-components-qt4).

Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

Hi Paul Thanks for your commits. I'm still not entirely clear on the cause of the FTBFS. Your patch to components/build.sh looks the same as the one I attached to this bug report earlier, but that on its own didn't work for me. What do you think of modifying

Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

Hi Paul On 12/04/2014 20:59, Paul Gevers wrote: It is what I thought. Path issue. Please find attached my very dirty hack around this issue. The patch is the updated version of fix_build.sh_for_lazarus-1.2.patch Confirming that with this updated patch, doublecmd builds on lazarus

Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

On 14 April 2014 18:52, Paul Gevers elb...@debian.org wrote: That is correct. OK. In that case, please go ahead and commit your updated patch. I've recently committed the last changes I wanted to make, so I think we can upload along with your patch. -- To UNSUBSCRIBE, email to

Bug#741355: nvidia-visual-profiler: nvvp segfaults on startup @frame soup_session_feature_detach+0x11

Adding the line below to /usr/lib/nvidia-visual-profiler/nvvp.ini solves the problem for me (at least the crashing on startup, I haven't actually tried profiling anything yet). -Dorg.eclipse.swt.browser.DefaultType=mozilla -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org

Bug#741355: nvidia-visual-profiler: nvvp segfaults on startup @frame soup_session_feature_detach+0x11

On 15 April 2014 18:09, Graham Inggs gra...@nerve.org.za wrote: Adding the line below to /usr/lib/nvidia-visual-profiler/nvvp.ini solves the problem for me (at least the crashing on startup, I haven't actually tried profiling anything yet). -Dorg.eclipse.swt.browser.DefaultType=mozilla

Bug#741355: nvidia-visual-profiler: nvvp segfaults on startup @frame soup_session_feature_detach+0x11

tags 741355 patch severity 741355 normal thanks Upon further investigation I have found the crash is related to displaying the Welcome window on first startup. I have identified three different scenarios that affect the way this bug occurs, or does not. 1. On a fresh Sid or Ubuntu Trusty

Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

Hi David On 16/03/2014 15:24, David Suárez wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): Thanks for reporting. I see the following errors: Compiling gifanim.pas gifanim.pas(242,6) Fatal: Can't find unit LazIDEIntf used by

Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

On 17 March 2014 21:45, Paul Gevers elb...@debian.org wrote: If I am not much mistaken, you need to fix src/doublecmd.lpi for the new location of the units. I think line 43, but there are better experts on this mail-list. Thanks Paul. I did try changing src/doublecmd.lpi in various ways but

Bug#755513: Processed: Re: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 8 August 2014 19:43, Vincent Danjean vdanjean...@free.fr wrote: For what I remember, both these packages have the libOpenCL.so file so they are buggy (should declare a conflict directly or indirectly) libOpenCL.so is shipped by amd-opencl-dev, nvidia-opencl-dev and ocl-icd-libopencl1.

Bug#755513: Processed: Re: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

On 11 August 2014 19:44, Vincent Danjean vdanjean...@free.fr wrote: However, in order to ensure a smooth upgrade from stable to testing, we need in addition 'Replaces' (possibly versionned) in all new (testing) packages. Conflicts or Breaks are not enough. I think I understand what you mean

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

In the latest OpenCL Runtime 14.2 for Intel CPU and Intel Xeon Phi coprocessors for Linux (64-bit) download [1], opencl-1.2-base-4.5.0.8-1.x86_64.rpm contains the following files: $ ls -ln opt/intel/opencl-1.2-4.5.0.8/lib64/ total 32 lrwxrwxrwx 1 1000 100014 Aug 15 14:24 libOpenCL.so -

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

Hi Vincent I am preparing a NMU for bug #757961 in nvidia-cuda-toolkit and I'd like to include a fix for #755513 if needed. Since Intel are now shipping libOpenCL.so.1.2, can libOpenCL.so be moved from ocl-icd-libopencl1 to ocl-icd-opencl-dev? Are the following changes what is needed for

Bug#763909: viewmol: /usr/bin/viewmol missing for most archs

tags 763909 patch thanks So 'getmachine' is looking in the non-multiarch directories for libtiff, libpng, etc. The attached patch works for me locally, but probably needs some more work. If nobody takes this, I'll prepare an NMU at the end of this week. --- a/source/getmachine +++

Bug#763909: viewmol: /usr/bin/viewmol missing for most archs

reopen 763909 thanks Hi Andreas Thanks for the upload. Unfortunately it didn't seem to work. :( From the i386 buildlog, it appears that getmachine runs before dh_quilt_patch, so the patch hasn't been applied yet. I'll see if I can convert the package to source format 3.0 (dquilt) and I should

Bug#763909: viewmol: /usr/bin/viewmol missing for most archs

Hi Andreas I attach a debdiff switching viewmol to source format 3.0 (quilt) and debhelper 9. This does the right thing on the Ubuntu PPA builders, at least for the i386 and amd64 builds I tested. I also attach my debian.tar.xz, as it may be easier to extract the original source tarball followed

Bug#763909: Bug#767919: unblock: viewmol/2.4.1-21

Hi Andreas So far, I haven't been able to get the package to build at all without switching to source format 3.0. I'll try now to see if I am able to skip the getmachine call. For the record, debian/patches/010_build_scripts.diff already contains a patch to allow it to build on kfreebsd:

Bug#763909: Bug#767919: unblock: viewmol/2.4.1-21

Some progress. I pre-applied debian/patches/150-getmachine_multiarch.patch simply by running: $ patch -p 1 -i debian/patches/150-getmachine_multiarch.patch ...and then commented out the line: #150-getmachine_multiarch.patch ..from debian/patches/series. I uploaded this to the Ubuntu PPA

Bug#763909: Bug#767919: unblock: viewmol/2.4.1-21

] + * Team upload. + * Add debian/gbp.conf + * Add Homepage and Vcs fields + + [ Graham Inggs ] + * Pre-apply debian/patches/150-getmachine_multiarch.patch. + * Update debian/rules: configure during the build-arch target. +Closes: #763909 + + -- Graham Inggs gra...@nerve.org.za Wed, 05 Nov 2014 11

Bug#768756: wader: FTBFS in jessie: Tests failures

I intend NMU-ing a fix for this, as per the attached debdff, pending its unblock pre-approval (bug #774134). wader-nmu.debdiff Description: Binary data

Bug#781225: FTBFS on amd64 and i386: file NVIDIA-Linux is not a directory

Hi Mateusz On 26 March 2015 at 10:50, Mateusz Łukasik mat...@linuxmint.pl wrote: During build nvidia-graphics-drivers on amd64 and i386 package return FTBFS: https://buildd.debian.org/status/logs.php?pkg=nvidia-graphics- driversver=340.76-1suite=sid It seems your build environment had an old

Bug#781995: Bug#782381: Bug#781995: motif/2.3.4-6.1 failed to build

On 25 April 2015 at 10:56, Julien Cristau jcris...@debian.org wrote: Why does the symbols file include private symbols (i.e. why are supposedly private symbols being exported by the library in the first place)? I don't know. I did ask upstream about it in their bug #1565 [1] and got the

Bug#781995: motif/2.3.4-6.1 failed to build

On 15 April 2015 at 21:12, Paul Gevers elb...@debian.org wrote: I saw that Graham already choose to just remove the symbol from the Ubuntu package. I believe that this is really a no-no, especially without careful investigation if other packages are using this symbol and this late in the

Bug#781995: motif/2.3.4-6.1 failed to build

Hi Michael On 16 April 2015 at 02:29, Michael Gilbert mgilb...@debian.org wrote: Upstream intends that symbol to be private, so it should be unused in other packages. But for confidence that it doesn't lead to breakage, someone should build test the reverse dependencies, which is a large

Bug#781995: motif/2.3.4-6.1 failed to build

retitle 782381 pre-approval: unblock: motif/2.3.4-6.2 thanks On 16/04/2015 07:46, Michael Gilbert wrote: On Thu, Apr 16, 2015 at 1:31 AM, Graham Inggs wrote: If you uploaded 2.3.4-6.2 now, could it cause any harm? At least this will get the package built and Release Team can still decide

Bug#781995: Bug#782381: pre-approval: unblock: motif/2.3.4-8

On 13/04/2015 08:43, Julien Cristau wrote: It's not appropriate in either, IMO. And even if it was, not at this stage of the release. Oh right. In Debian, xorg depends on: xfonts-base (= 1:1.0.0-1), xfonts-100dpi (= 1:1.0.0-1), xfonts-75dpi (= 1:1.0.0-1), xfonts-scalable (= 1:1.0.0-1),

Bug#781995: Bug#782381: pre-approval: unblock: motif/2.3.4-8

On 12 April 2015 at 22:19, Niels Thykier ni...@thykier.net wrote: On 2015-04-12 21:47, Michael Gilbert wrote: control: tag 781995 pending On Sat, Apr 11, 2015 at 7:41 AM, Graham Inggs wrote: Hi release team In order to fix RC bug #781995, I would like to upload a version of Motif

Bug#781995: Bug#782381: pre-approval: unblock: motif/2.3.4-8

On 12 April 2015 at 23:25, Michael Gilbert mgilb...@debian.org wrote: I can reschedule to delayed/0 if as the maintainer you say that's ok. Understood. (Carefully not writing OK here, see below) If there isn't an RC bug about that, then it's likely not appropriate at this point in the

Bug#781995: motif: Fix for keyboard navigation of menus makes some packages unusable

tags 781995 patch thanks The attached patch simply does not define FIX_1565, and causes popup menus and keyboard navigation in menus to revert to their Motif 2.3.3 behaviour. This patch can replace 18-updated-fix-1565.patch. --- a/lib/Xm/XmI.h +++ b/lib/Xm/XmI.h @@ -297,7 +297,6 @@ #define

Bug#781995: motif: Fix for keyboard navigation of menus makes some packages unusable

Source: motif Version: 2.3.4-5 Severity: serious In order to fix bug #730026 (Keyboard navigation of menus not working correctly) [1], I included an updated fix from upstream's bug #1565 (The active window changes to inactive when the drop down list is clicked) [2]. Unfortunately, this fix

Bug#793991: lazarus: armel and armhf builds stall

Source: lazarus Version: 1.4.0+dfsg-3 Severity: serious Control: affects -1 + src:doublecmd src:easymp3gain src:cqrlog Hi Maintainers Since the upload of lazarus 1.4.0+dfsg-3, builds of doublecmd [1], easymp3gain [2] and cqrlog [3] have been stalling on armel and armhf where they built

Bug#793991: lazarus: armel and armhf builds stall

I built and installed lazarus 1.4.2 but the builds of doublecmd, easymp3gain and cqrlog all failed in the same way as with lazarus 1.4.0. I then attempted to build the daily source snapshot of fpc's fixes tree [1], but many of the patches no longer apply cleanly. [1]

Bug#793991: lazarus: armel and armhf builds stall

I tried a simpler package, ddrescueview [1], and instead of building the Debian package, I simply ran: lazbuild source/ddrescueview.lpi --bm=GNU/Linux Release As before, the build appeared to stall, and after hitting ctrl-c I noticed that in the background the build had actually completed

Bug#728792: libreoffice-nlpsolver: nlpsolver cannot be used in LibreOffice Calc - Error: The status of this extension is unknown

Hi Maintainer I was able to reproduce the 'Error: The status of this extension is unknown' message on a system where libreoffice-java-common was not installed. I think libreoffice-nlpsolver needs a Depends on libreoffice-java-common. Regards Graham

Bug#793991: lazarus: armel and armhf builds stall

Control: tags 793991 + patch Hi The attached patch works around the problem by disabling '-z relro' for armel and armhf builds. I have tested it on armhf and amd64. Regards Graham disable-relro-on-ARM.debdiff Description: Binary data

Bug#795077: kicad: FTBFS: error: 'itr' was not declared in this scope

Hi > Nick Østergaard [2015-08-13 16:24 +0200]: > > You can use the cmake option -DKICAD_SKIP_BOOST=ON to fix this issue. > > Make sure this only happens for systems with boost version above 1.54. The -DKICAD_SKIP_BOOST=ON option doesn't work in the kicad stable branch (bzr4029) currently in

Bug#806967: kicad: missing build-dependencies

Source: kicad Version: 4.0.0~rc1-1 Severity: serious Tags: patch Hi Maintainer Kicad FTBFS when building the architecture-independent binary packages in a clean chroot. The build fails during dh_install: cp: cannot stat 'debian/tmp/usr/share/doc/kicad/help/en': No such file or directory

Bug#809712: p4vasp: FTBFS: src/cp4vasp_wrap.cpp:1239: undefined reference to `PyErr_SetString'

There was an upload of fltk1.3 between the last successful reproducible build and the failed build. Something changed the output of 'fltk-config', the flags now include '-fPIE -fpie' which cause p4vasp to FTBFS. I have filed bug #809825 against libfltk1.3-dev.

Bug#810017: psi4: FTBFS with perl 5.22

Control: retitle -1 psi4: FTBFS with perl 5.22 Control: tags -1 pending Control: forwarded -1 https://github.com/psi4/psi4public/pull/200 Thanks gregor!

Bug#810230: [Debichem-devel] Bug#810230: molds: FTBFS: /usr//lib//liblapacke.so: undefined reference to `cgejsv_'

Hi Chris Which version of liblapacke was this built against? Could this be related to #810143? Regards Graham

Bug#808312: chemps2: upgrade fail

On 23 December 2015 at 22:38, Sebastian Wouters wrote: > I hope this fixes bug #808312: > http://anonscm.debian.org/cgit/debichem/packages/chemps2.git/commit/?id=6c7ed80faddc63765bc8e995c7fce14cfff81210 > ? I've tested the upgrade from 1.6-1 with a package built in my

Bug#809290: shogun: FTBFS with Eigen 3.3

Control: retitle -1 shogun: FTBFS with Eigen 3.3 Control: tags -1 patch Hi Maintainer The attached patch fixes the build with Eigen 3.3. Regards Graham Description: Fix build with Eigen 3.3 Origin: upstream,

Bug#814183: openmpi 1.10.2 is broken on powerpc

I don't believe the warning below is related to the problem. > A deprecated MCA variable value was specified in the environment or > on the command line. Deprecated MCA variables should be avoided; > they may disappear in future releases. It can be avoided by changing the following line in

Bug#813722: [Debichem-devel] Bug#813722: aces3: FTBFS on powerpc

On 4 February 2016 at 19:52, Mattia Rizzolo wrote: > your package FTBFS on powercpc on the buildds. The same happens with petsc, as soon as the mpi test programs are launched they use 100% cpu and stop responding. See bug #814183.

Bug#811223: FTBFS: perl texi2html: Can't use 'defined(@array)'

Control: tags -1 patch The attached patch was applied in Ubuntu. Description: Fix texi2html for Perl 5.22 Fixes FTBFS for arch:all - Can't use 'defined(@array)' Bug-Debian: https://bugs.debian.org/811223 Author: Graham Inggs <ginggs@debian.org> Last-Update: 2016-02-05 --- a/doc/texi2html

Bug#814473: [Debichem-devel] Bug#814473: elpa: FTBFS: find: '/usr/share/libtool/config/ltmain.sh': No such file or directory

On 12 February 2016 at 01:20, Andreas Beckmann wrote: > dh_autoreconf --as-needed > find: '/usr/share/libtool/config/ltmain.sh': No such file or directory > dh_autoreconf: find /usr/share/libtool/config/ltmain.sh . ! -ipath > "./debian/*" -a ! \( -path '*/.git/*' -o -path

Bug#814183: openmpi 1.10.2 is broken on powerpc

On 12 February 2016 at 01:17, Emilio Pozuelo Monfort <po...@debian.org> wrote: > On Tue, 9 Feb 2016 21:49:29 +0200 Graham Inggs <gin...@debian.org> wrote: >> Petsc rebuilt successfully [1] a couple of hours ago on poulenc.d.o. [2]. >> My previous tests were done on partc

Bug#813722: [Debichem-devel] Bug#813722: Bug#813722: aces3: FTBFS on powerpc

On 8 February 2016 at 23:31, Michael Banck <mba...@debian.org> wrote: > Hi, > > On Mon, Feb 08, 2016 at 11:26:17PM +0200, Graham Inggs wrote: >> On 4 February 2016 at 19:52, Mattia Rizzolo <mat...@debian.org> wrote: >> > your package FTBFS on powercpc on

Bug#814183: openmpi 1.10.2 is broken on powerpc

Petsc rebuilt successfully [1] a couple of hours ago on poulenc.d.o. [2]. My previous tests were done on partch.d.o. [3]. Partch has 2GB of RAM vs Poulenc's 5GB, I don't know if this is significant. [1] https://buildd.debian.org/status/fetch.php?pkg=petsc=powerpc=3.6.2.dfsg1-3%2Bb3=1455016089

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

Control: tags -1 pending I've committed the fix to git and will upload once libopenmpi1.10 is available (see #813042).

Bug#798059: Please give back turbojson on arch:all

On 23 February 2016 at 19:00, Cyril Brulebois wrote: > Why should it be given back? > > python-turbojson | 1.3.2-2.1 | unstable | all > turbojson| 1.3.2-2.1 | unstable | source Sorry, got confused by the FTBFS bug. I'll check if this even needs a binnmu,

Bug#814183: openmpi 1.10.2 is broken on powerpc

I filed LP: #1550863 [1] to track the powerpc build failures in Ubuntu. [1] https://bugs.launchpad.net/bugs/1550863

Bug#798059: Please give back turbojson on arch:all

Hi Wanna-Build Team Turbojson builds again since python-peak.rules 0.5a1+r2713-1 was uploaded. Please give back turbojson on arch:all. gb turbojson_1.3.2-2.1 . all Regards Graham

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

Hi Peter On 13 December 2015 at 01:17, peter green wrote: > 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 Thanks for your

Bug#813248: libdx4-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

Control: severity -1 normal Control: tags -1 confirmed Hi Andreas On 31 January 2016 at 00:04, Andreas Beckmann wrote: > For /usr/share/doc/PACKAGE this may not be problematic as long as both > packages are installed, ship byte-for-byte identical files and are > upgraded in

Bug#813722: [Debichem-devel] Bug#813722: Bug#813722: aces3: FTBFS on powerpc

Control: notfound -1 3.0.8-5 So aces3 built on poulenc [1]. Should we just merge this bug with #814183 ? [1] https://buildd.debian.org/status/logs.php?pkg=aces3=3.0.8-5%2Bb1=powerpc

Bug#818123: [Pkg-pascal-devel] Bug#818123: doublecmd: FTBFS in stretch

Control: tags -1 fixed-upstream upstream confirmed Hi Santiago Thank you for the report. I'm confirming that doublecmd does FTBFS when built with fpc 3.0 and lazarus 1.6. Upstream released 0.7.0 yesterday which should resolve this. Regards Graham

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

On 6 April 2016 at 20:31, Peter Colberg wrote: > Graham, should we remove these two archs from testing for the time > being as you suggested? I managed to get it building on armhf again in Ubuntu with a minor change [1] and I have tested that it builds on a Debian armhf

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

On 9 April 2016 at 00:53, peter green wrote: > It would be useful if someone can reproduce the issue and get a dissasembly > of the failure location. I hope this is useful. I'll leave my screen session on abel.d.o. open in case I need to fetch more information. [Thread

Bug#820220: julia: FTBFS on armel/armhf

On 09/04/2016 13:41, Riku Voipio wrote: And yes, vorr is an NEON instruction. OK, so that is confirmed then. Any ideas on where to disable NEON? I couldn't find anything explicitly enabling it in the Julia source. The problem seems to have appeared when we switched from LLVM 3.7 to LLVM

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

On 8 April 2016 at 21:16, Emilio Pozuelo Monfort wrote: > Why did you switch to 3.8? The default in unstable is 3.6 and in experimental > is > 3.7. I understood there were severe performance regressions with Julia on LLVM > 3.3 that were only fixed in 3.8. > I'm Cc'ing the

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

Hi Maintainer This problem still occurs from time to time. See build logs of: 2.4.dfsg+2.4.20-1 on hurd-i386 https://buildd.debian.org/status/fetch.php?pkg=vice=hurd-i386=2.4.dfsg%2B2.4.20-1=1431810973 2.4.dfsg+2.4.24-2 on kfreebsd-amd64

Bug#814183: openmpi 1.10.2 is broken on powerpc

On 3 March 2016 at 13:47, Emilio Pozuelo Monfort wrote: > Might be related to #813722 / #814183. Definitely. ELPA built on poulenc and praetorius, but failed on powerpc-osuosl-01: https://buildd.debian.org/status/logs.php?pkg=elpa=powerpc Only looking at elpa >=

Bug#814183: [Debichem-devel] Bug#816590: Bug#814183: openmpi 1.10.2 is broken on powerpc

Please see #816101 [1]. It seems the powerpc and mipsel issues are closely related. The PETSc package maintainer conditionally disabled the 2 process MPI tests on powerpc and mipsel in order to work around the problem. [1] https://bugs.debian.org/816101

Bug#816101: petsc: FTBFS on mipsel - broken openmpi breaks petsc build

On 21 April 2016 at 17:19, Graham Inggs <gin...@debian.org> wrote: > This sounds a lot like the problem we have with powerpc, see bug #814183. I > think you may just have been very lucky in which powerpc buildds petsc has > landed on lately. Your luck ran out, the build faile

Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing

Hi Santiago I set up a Debian Testing amd64 VM in VirtualBox, initially with 2 CPUs and 4GB which I later reduced. I successfully built julia 0.4.5-3 with 2 CPUS and 4GB, 2 CPUS and 2GB, 1 CPU and 4GB, 1 CPU and 2GB and finally 1 CPU and 1GB. I attach the complete build log for the 1 CPU

Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1

Confirming. Python-lldb-3.8 has missing dependencies and some broken symlinks. After installing python-lldb-3.8, I needed to take the steps below (as root) before I could 'import lldb' successfully. apt-get install lldb-3.8 liblldb-3.8 liblldb-3.8-dev cd

Bug#805220: pcb2gcode: FTBFS: error: reference to ‘shared_ptr’ is ambiguous

Control: tags -1 patch Hi Maintainer Please find patch adapted from upstream's commit [1] attached. Regards Graham [1] https://github.com/pcb2gcode/pcb2gcode/commit/e6580db4365c9f3ad42cea103382faeaf472800f Description: Fix build with GCC5 Origin: upstream,

Bug#818072: warzone2100: FTBFS in stretch (new flex)

Control: tags -1 patch Hi Maintainer Please see attached patch which fixes the FTBFS with recent versions of flex. Regards Graham Description: Fix FTBFS with recent versions of flex Bug-Debian: https://bugs.debian.org/818072 Forwarded: No Author: Graham Inggs <gin...@debian.org> Last-

Bug#818072: warzone2100: FTBFS in stretch (new flex)

On 1 May 2016 at 19:10, Markus Koschany wrote: > that was really bad timing. I had uploaded a new revision with a fix one > hour before you sent your e-mail. Nevertheless thanks for the patch! Oh well, no harm done. Thanks for taking care of warzone2100.

Bug#823839: oce: please rebuild against freeimage 3.17.0

Source: oce Version: 0.17.1-1 Severity: serious Hi Maintainer OCE needs to be rebuilt against the current version of freeimage in order to pick up the correct library paths in shipped CMake files. For example, /usr/lib/x86_64-linux-gnu/oce-0.16/OCE04_VisualizationTargets-relwithdebinfo.cmake

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

Hi Peter On 19 April 2016 at 21:17, Peter Colberg wrote: > julia 0.4.5-3 FTBFS on armel due to an outdated llvm-3.8 package: Yes, suihkulokki pointed this out previously. I requested removal of the armel binaries in bug #820713, and that already has been processed. Since the

Bug#822783: eztrace-contrib: FTBFS with libc 2.23: 'memcpy' was not declared in this scope

For reference, the attached commit (commitdiff [1]) from glibc shows the changes made in string/string.h. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=05a910f7b420c2b831f35ba90e61c80f001c0606 >From 05a910f7b420c2b831f35ba90e61c80f001c0606 Mon Sep 17 00:00:00 2001 From: Wilco

Bug#816569: mrs: FTBFS with GCC 6: was not declared in this scope

Hi Gert > The fix will have to wait until libboost1.60 becomes the default and is > build by using g++-6. In addition libzeep needs then to be fixed first > (see blocker). Boost 1.61 and GCC 6 are now the defaults and libzeep has been binNMU'd. Is there anything else that needs to be done before

Bug#830681: trilinos-all-dev: Updating binutils breaks trilinos

On 18 July 2016 at 18:53, Nico Schlömer wrote: > @Graham, would you like to upload? Sure, will do tomorrow.

Bug#812272: laserboy: FTBFS with GCC 6: error: switch quantity not an integer

-Debian: https://bugs.debian.org/812272 Author: Graham Inggs <gin...@debian.org> Last-Update: 2016-07-20 --- a/src/LaserBoy_vertex.hpp +++ b/src/LaserBoy_vertex.hpp @@ -715,7 +715,7 @@ out.put((color & 0x

Bug#829230: cloud-sptheme: FTBFS: index_styling.py [..] ValueError: too many values to unpack

Control: tags fixed-upstream Hi This was fixed upstream [1] and is included in release 1.7.1. Regards Graham [1] https://bitbucket.org/ecollins/cloud_sptheme/diff/cloud_sptheme/ext/index_styling.py?diff2=b4c2692088fc

Bug#822783: eztrace-contrib: FTBFS with libc 2.23: 'memcpy' was not declared in this scope

Hi Samuel This bug is RC since the recent upload of glibc 2.23 to unstable. Seeing that -D_FORTIFY_SOURCE=2 is required to trigger this bug, should I lower the severity or close the bug? Regards Graham

Bug#818819: leocad: FTBFS with libc 2.23: 'isnan' was not declared in this scope

Control: tags -1 patch Hi Maintainer The attached patch, by Logan Rosen, was applied in Ubuntu to fix the problem. Regards Graham Description: prefix isnan with std:: to fix FTBFS with libc 2.23 Author: Logan Rosen Forwarded: no Last-Update: 2016-04-07 --- This patch header

Bug#831086: bagel: FTBFS with GCC 6: is not a member of

Control: retitle -1 bagel: FTBFS with GCC 6: is not a member of Since mpich was rebuilt with GCC 6, bagel now FTBFS with the following: Making all in io make[5]: Entering directory '/«PKGBUILDDIR»/src/util/io' /bin/bash ../../../libtool --tag=CXX --mode=compile mpicxx -DHAVE_CONFIG_H -I.

Bug#812272: laseboy: FTBFS with GCC 6 and Boost 1.60

Control: tags -1 pending I intend to NMU laserboy with the patch attached to #825102 and a slight variation of the patch attached to #812272.

Bug#811700: FTBFS with GCC 6: macro passed X arguments, takes Y

Control: tags -1 patch Hi Maintainer Please find patches from upstream attached, fixing the build issues with GCC6 and Boost 1.60. Regards Graham Description: Fixed return value for deserialize() implementations This fixes a FTBFS with GCC 6. Origin: upstream,

Bug#818140: cura-engine: FTBFS: mathcalls.h:109:1: error: '__DECL_SIMD__log' does not name a type

Control: tags -1 patch Hi Maintainer Please find attached patch which avoids a FTBFS with recent toolchain. As noted in #744112, this version of cura-engine is rather old. Regards Graham --- a/utils/logoutput.cpp +++ b/utils/logoutput.cpp @@ -15,7 +15,7 @@ fflush(stdout); } -void

Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

Control: severity -1 important Control: block -1 by 852798 Downgrading severity since armhf binaries were removed in #853296. Marked as blocked by #852798 in fpc.

Bug#852283: libopenblas-dev: missing on mips64el

Source: openblas Version: 0.2.19-1 Severity: serious Hi Maintainer Architecture: mips64el was added to libopenblas-base but not libopenblas-dev. Was this an oversight? Regards Graham

Bug#852296: yade FTBFS on arm64: compiler processes terminated (machine runs out of RAM?)

On 23/01/2017 14:08, Adrian Bunk wrote: This buildd has 6 CPUs, but it has only 8 GB of RAM. From the last changelog entry: * [d763fbf] Set compat level to 10. The switch to debhelper 10 enabled parallel builds. Yade 2017.01a-1 FTBFS on most architectures in Ubuntu. The following changed

Bug#851042: [Debichem-devel] Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

On 23/01/2017 17:52, Sébastien Villemot wrote: The rebuilding for both atlas and openblas has been requested on Jan 12, and became effective on Jan 17 (see ##851133). Ah thanks! I checked on reproducible builds [1] and it was still failing, but it seems they suddenly stopped building molds on

Bug#851042: [Debichem-devel] Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

On 11/01/2017 20:55, Lucas Nussbaum wrote: /usr//lib//liblapacke.so: undefined reference to `sgemqr_' /usr//lib//liblapacke.so: undefined reference to `zhbevd_2stage_' /usr//lib//liblapacke.so: undefined reference to `zsytrf_rk_' This seems to be a recurring problem, see #810230. openblas seem

Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

Control: severity -1 important Has anyone else confirmed this bug report? I saw the greyscale issue on two different amd64 machines. I was able to add atoms to a molecule, but they didn't appear where I expected them. That could just be me not being familiar with the interface. It

  1   2   3   4   5   6   7   8   9   10   >