Am 31.08.2014 um 03:10 schrieb Samuel Thibault:
> guess that will just fix all our issues... I'll then commit that and
> push upstream.
is this necessary for the libgc package too? (and all embedded libgc copies in
other packages)?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.deb
Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit :
> Am 31.08.2014 um 03:10 schrieb Samuel Thibault:
> > guess that will just fix all our issues... I'll then commit that and
> > push upstream.
>
> is this necessary for the libgc package too? (and all embedded libgc copies in
> other pac
Control: clone -1 -2
Control: reassign -2 libc0.3
There was also another issue, which was basically making boehm-gc
completely ignore pointers on the main stack. This was in libc0.3, thus
cloning & reassigning.
Samuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Hello,
I've dug a bit more the java failures we've been encountering for some
time. The particular case of simply running gjdoc was helpful: an
object gets allocated, then other happens, then the object gets used,
but its method table is completely nuts. It happens that the class
field of the ob
tony mancill, le Wed 09 Jul 2014 22:26:19 -0700, a écrit :
> (gdb) bt
> #0 0x012ab278 in gnu.classpath.tools.gjdoc.Main.start(java.lang.String[])int
> (
> this=@80c8eb0, args=@8099f98)
> at
> ../../../../../src/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1050
This is:
tony mancill, le Tue 08 Jul 2014 22:20:01 -0700, a écrit :
> Program received signal SIGUSR1, User defined signal 1.
SIGUSR1 is benign. Please use
handle USR1 nostop noprint pass
To let gdb continue the program, up to where there actually is an
illegal instruction.
Samuel
--
To UNSUBSCRIBE,
On 07/06/2014 11:28 AM, tony mancill wrote:
> On 07/06/2014 10:45 AM, Matthias Klose wrote:
>> Am 06.07.2014 19:06, schrieb Samuel Thibault:
>>> Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
It FTBFS on hurd
[...]
cd /home/user/port/simgrid/simgrid-3.11.1/doc &&
Le 06/07/2014 19:45, Matthias Klose a écrit :
> maybe uploaded class files built with java8.
I don't think so, this would be caught by Lintian:
http://lintian.debian.org/tags/incompatible-java-bytecode-format.html
Currently no package contains classes using the format 52 (Java 8).
Emmanuel Bou
On 07/06/2014 10:45 AM, Matthias Klose wrote:
> Am 06.07.2014 19:06, schrieb Samuel Thibault:
>> Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
>>> It FTBFS on hurd
>>>
>>> [...]
>>> cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d
>>> /home/user/port/sim
Am 06.07.2014 19:06, schrieb Samuel Thibault:
> Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
>> It FTBFS on hurd
>>
>> [...]
>> cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d
>> /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/
>> /home/user/p
Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
> It FTBFS on hurd
>
> [...]
> cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d
> /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/
> /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simg
Hello,
I'm wondering on why are you reporting this bug against simgrid. It
seems to me that this is obviously a javadoc bug, don't you think?
Could you please reassign that bug to the right package?
Thanks for the time you took to investiguate the issue, though. But
there is not much I can do ab
Source: simgrid
Severity: important
User: debian-h...@lists.debian.org
Usertags: hurd
It FTBFS on hurd
[...]
cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d
/home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/
/home/user/port/simgrid/simgrid-3.11.1/src/bindings/j
13 matches
Mail list logo
