Package: g++-4.9
Version: 4.9.0-7
Usertags: goto-cc
Affects: hugin mkvtoolnix
Tags: upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214
It seems that the problem known upstream as PR 61214 makes several Debian
packages FTBFS.
This is hugin 2014.0.0~rc3+dfsg-1:
[...]
Hello Felix,
On Thu, Aug 29, 2013 at 08:43:09PM +0200, Roberto Bagnara wrote:
Unless some problems are reported, this will become PPL 1.1.
Kind regards,
You are right. it's fixed. The error message leading to the collision in
ppl.hh vs gmpxx.h was caused by a bogus mpir.h include (for
On Sun, Apr 3, 2011 at 18:20:09 +0200, Matthias Klose wrote:
Package: libapron-dev
Version:0.9.10-5
Severity: serious
libapron-dev depends on libppl0.10-dev, which doesn't exist anymore in
unstable, now removed by ftp-master. Please depend on libppl0.11-dev
instead.
Well.
this is included by doxygen.sty in ppl.
Thanks for fixing doxygen in this respect!
See https://bugzilla.gnome.org/show_bug.cgi?id=638661
for another missing include
Do you mean texlive-math-extra? Could you provide some further information what
was failing before you added it?
Thanks a
Hi Matthias,
Thanks a lot for getting back to me.
[...]
Is there actually any backporting work necessary, or is it just recompiling?
I'll of course check this myself if you could just give me any hints which
package to try to build and, if you already know of any, which obstacles I
might
[...]
see the GCC build requirements where to download 0.15.9. 0.15.10
just contains a consistency check, no need to update.
[...]
0.15.10 compiles fine with ppl 0.11 and passes all tests. Given that Roberto
Bagnara, head of PPL development, seems to be actively working with cloog
while you do provide versioned -dev packages, you didn't rename the
source package, so currently only 0.10 or 0.11 will be available.
Not sure if I do want to backport the ppl 0.11 support to 4.4 and
4.5.
[...]
Is there actually any backporting work necessary, or is it just recompiling?
Source: ppl
Version: 0.10.2-8
Severity: important
Hi,
apparently, the build dependencies are not tight enough.
Running cowbuilder --debbuildopts -B --binary-arch --build
ppl_0.10.2-8.dsc fails (after a day and a half, mind you)
with:
[...]
/bin/bash: swipl-ld: command not found
tags 595884 - sid
fixed 595884 0.10.2-7
thanks
[...]
plld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++
-ld x86_64-linux-gnu-g++ \
-ld-options`echo '' -g -O2 -frounding-math -g -O2 -W -Wall |
tr /` \
-o ppl_pl .libs/libppl_swiprolog.a
Hi Julien,
Processing commands for cont...@bugs.debian.org:
tags 595884 + sid
Bug #595884 [ppl] ppl: FTBFS in squeeze: /bin/bash: plld: command not found
Added tag(s) sid.
Would you mind elaborating why you re-added the sid tag? This bug is already
fixed in the version(s) in sid!?
Thanks
Package: g++-4.4
Version: 4.4.4-8
(Leaving choice of severity to gcc maintainers; at the current stage ppl cannot
migrate to testing although it would fix an RC bug.)
ppl 0.10.2-7 FTBS on armel [1] (exclusively) with test suite failures; this was
extremely surprising as 0.10.2-6 was fine [2] and
Package: ppl
Version: 0.10.2-4
Severity: serious
the prolog tests fail at least on powerpc. Please either fix these
that the package is built again, or ignore the failures in the
prolog testsuite. ppl is used as a gcc build-dependency, and we
shouldn't care that much about clean prolog
On 02/19/10 10:32, Michael Tautschnig wrote:
Package: ppl
Version: 0.10.2-4
Severity: serious
the prolog tests fail at least on powerpc. Please either fix these
that the package is built again, or ignore the failures in the
prolog testsuite. ppl is used as a gcc build-dependency, and we
Hi Lucas,
I talked to upstream and was assured that upstream is just as clueless as I am:
Both their and my build attempts on amd64 always worked fine, even if making
with -jX for some 2 = X = 8.
Is there any way one could get access to the system you're building these
packages, or could you
Hi!
[...]
if [ . != `pwd` ]; then \
rm -f ppl_prolog_generated_test_common.pl; \
fi
rm -f ppl_prolog_generated_test_main.pl; \
diff -u --ignore-all-space ./../tests/expected_pgt obtained_pgt
make[7]: *** [pl_check_test] Terminated
make[3]: *** [check-recursive]
On Monday 26 October 2009 09:22:26 Marco d'Itri wrote:
I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2].
Seconded.
Thirded.
+1.
Thanks for bringing this up,
Michael
pgpcMDHNXCorM.pgp
Description: PGP signature
Excerpts from Michael Tautschnig's message of Tue Sep 15 16:57:26 +0200 2009:
Yes, there are people caring about this package. Building the binary
packages,
however, is a fairly large burden for your buildds, therefore we try to
keep the
number of uploads low. I will try to see which
Hi,
I reported this bug one month ago, including patches. I have been
testing it without problems so far.
Is anyone taking care of this package? Could the patches be applied to
the package?
Yes, there are people caring about this package. Building the binary packages,
however, is a
Julien Cristau wrote:
On Mon, Mar 2, 2009 at 23:22:36 +0100, Michael Tautschnig wrote:
We only build the user-docs nowadays, and that actually wouldn't be
necessary if
Debian's build system did what the policy says: There is no need to
re-build the
architecture independent stuff
Hi Bastian,
Bastian Blank wrote:
Package: ppl
Version: 0.10-4
Severity: serious
As I hate playing with severities: I'd ask you to reconsider the severity after
reading those mails, I'd prefer not to change it myself to avoid any kind of
ping-pong.
The build of ppl needs 7 CPU-hours on a
Package: ppl
Version: 0.10-3
Severity: serious
There was an error while trying to autobuild your package:
[...]
Yes, thanks, already noticed; in fact, I uploaded a version supposed to fix this
an hour ago. I'll close this bug tomorrow, once autobuilding has confirmed that
my fix is
Package: ppl
Version: 0.10-1
Severity: serious
Justification: Package is unusable on a number of architectures
Tags: upstream
It has been brought to our attention that ppl 0.10-1 is broken on all bigendian
systems. All floating point computations will (silently) use wrong results,
which makes the
Hi Bastian,
Thanks for replying and checking stuff.
On Thu, Jul 17, 2008 at 03:34:59AM +0200, Michael Tautschnig wrote:
When rebuilding diagnostics, it failed on s390 during the selftests [0]. The
failing piece of code is attached.
This includes too many preprocessor magic. Please
Michael Tautschnig wrote:
apparently ppl 0.10 pre34 still fails to build on some architectures because
of
FPU_* macros not being defined. Please see
http://buildd.debian.org/fetch.cgi?pkg=pplver=0.10~pre34-1arch=armstamp=1223724338file=log
for details.
Hi Michael,
yes, we received
Dear developers,
apparently ppl 0.10 pre34 still fails to build on some architectures because of
FPU_* macros not being defined. Please see
http://buildd.debian.org/fetch.cgi?pkg=pplver=0.10~pre34-1arch=armstamp=1223724338file=log
for details.
Thanks,
Michael
pgp65RWiokeLZ.pgp
Description:
Assume we do build the default gcc depending on a libppl0, now the
libppl soname is changed to libppl1, a new ppl source is uploaded, and
suddendly libppl0 isn't available anymore. And we still need to
rebuild gcc using gcc. Making the ppl source versioned (pplX), we
still have the old
Michael Tautschnig writes:
Assume we do build the default gcc depending on a libppl0, now the
libppl soname is changed to libppl1, a new ppl source is uploaded, and
suddendly libppl0 isn't available anymore. And we still need to
rebuild gcc using gcc. Making the ppl source versioned
Package: g++-4.3
Version: 4.3.1-4
[I leave it to the gcc maintainers to judge about the severity, because it
actually breaks otherwise running programs, but those cases seem extremely rare]
When rebuilding diagnostics, it failed on s390 during the selftests [0]. The
failing piece of code is
Michael Tautschnig writes:
Some investigations showed that the problem seems to be caused by a umlaut
being
contained in the directory name; if one copies the files to, e.g., /tmp/
things
work fine.
What locale are you using? How is the umlaut encoded in the directory
name
This bug report was submitted for an older version of gcc/g++/gcj.
Please recheck with the current gcc-4.3/g++-4.3/gcj-4.3 packages
from unstable.
So I did:
corn:/tmp# javac -version
gcj-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116 (experimental) [trunk revision
131577]
Copyright (C) 2007
[...]
I don't see anything obvious. It looks like the build is trying to use
the h8300-hitachi-coff-ar which I assume it just built, and it
basically isn't working.
Actually h8300-hitachi-coff-ar is part of the binutils-h8300-hms package, and
judging from the failed assertions and the code
Hi all!
First of all: I'm neither subscribed to debian-gcc nor debian-arm, so please CC
me -thanks!
I've recently adopted the gcc-h8300-hms cross compiler package, which finally
builds on all archs but arm. The latest buildd-log may be found at
Package: gij-4.1
Version: 4.1.1-17
Severity: minor
One of our users has seen the following error:
$ java FirstSample
Exception in thread main java.lang.NoClassDefFoundError: FirstSample
at gnu.java.lang.MainThread.run(libgcj.so.70)
Caused by: java.lang.ClassNotFoundException: FirstSample not
33 matches
Mail list logo
