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
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
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
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
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
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
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
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
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
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
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
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 >=
I filed LP: #1550863 [1] to track the powerpc build failures in Ubuntu.
[1] https://bugs.launchpad.net/bugs/1550863
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,
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
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
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
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
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
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
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
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
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.
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
Control: tags -1 pending
I've committed the fix to git and will upload once libopenmpi1.10 is
available (see #813042).
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
Hi Chris
Which version of liblapacke was this built against?
Could this be related to #810143?
Regards
Graham
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!
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.
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
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
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
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
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
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
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]
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
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
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
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
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
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),
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
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
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
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
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
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
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
]
+ * 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
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:
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
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
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
+++
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
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
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
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
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
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 -
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
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.
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.
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
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
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
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):
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
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
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
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
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
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
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).
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
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
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
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
1101 - 1178 of 1178 matches
Mail list logo