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:
[...]
/usr/bin/c+
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
> 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
> > instea
> 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
[...]
>
> 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
deve
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
> 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
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!?
T
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/libpp
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
> 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 f
> 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 pr
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 t
Hi Lucas,
Thanks a lot for the quick reply and precise information.
[...]
>
> The fact that it blocks is reproducible.
>
> Output on the terminal:
> % ppl_prolog_generated_test_main.pl compiled 0.18 sec, 2,099,112 bytes
> % ./swi_prolog_generated_test compiled 0.18 sec, 2,104,128 bytes
> true
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-
> 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
> 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, i
> 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
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-ho
> 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
found 491137 4.3.3-1
thanks
Finally I got around to produce a tiny example from the original code that
reproduces the bug. The attached code contains several notes on which parts seem
to be essential (e.g., using ::std::string in some way). To reproduce do
g++ -g -O2 -o invariance_annotation inva
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 prepr
> 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=ppl&ver=0.10~pre34-1&arch=arm&stamp=1223724
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=ppl&ver=0.10~pre34-1&arch=arm&stamp=1223724338&file=log
for details.
Thanks,
Michael
pgp65RWiokeLZ.pgp
Description
> 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
> >
> 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 li
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 attac
> 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
> 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) 200
[...]
>
> 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
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
http://buildd.debian.org/fetch.cgi?pkg=gcc-h8300-hms
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
35 matches
Mail list logo
