st.c (code 4)
Has anybody else seen this or, more usefully, know the fix?
Thanks,
--
Michael Bane
Atmospheric Physics Group
University of Manchester
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
onfirm the findings of GSR that this appears to be a gcc-8
regression. Rebuilding src:mesa with gcc-7 fixed those issues for me.
Might be a good idea to (temporarily) switch to gcc-7 depending on how
long it takes until this fix is applied in gcc-8.
The attached patch worked for me.
Regards,
Michael
and I can confirm the fix.
Andreas, thank you for the quick mesa update! Feel free to drop my
workaround again in one of your next uploads.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Descriptio
Hi,
On Sat, Sep 07, 2019 at 10:50:34PM +0200, Michael Banck wrote:
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
> >
> > Backtrace for this error:
> > #0 0x7f063149eb40 in ???
> > #1 0x7f063149dd75 in ???
Package: gcc-10
Version: 10.2.0-16
Severity: wishlist
When upgrading from 10.2.0-15 to 10.2.0-16 aptitude reports that gcc-10 is
282MB larger, g++-10 is 312MB larger, and cpp-10 is 283MB larger. In -15
/usr/lib/gcc/x86_64-linux-gnu/10/lto1 is 26M and in -16
/usr/lib/gcc/x86_64-linux-gnu/10/lto1 is
h any bug report.
> > See for instructions.
> > make[3]: *** [Makefile:194: exxengy.o] Error 1
Michael
On Wed, 28 Oct 2020 12:30:41 +0100 Sebastian Ramacher
wrote:
On 2020-10-24 07:38:39 +0300, Michael Tokarev wrote:
...
> Hmm. So this looks like a gcc ICE bug. Here's the code in question:
> ...
> > | /<>/linux-user/m68k/signal.c:44:1: internal compiler error:
‘verif
Package: libdebuginfod1
Version: 0.183-5
Severity: important
Dear Maintainer,
There is no architecture entry for all on buildd.debian.org and on packages on
incoming.debian.org
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (710, 'unstable'), (670, 'te
on down to
ev56.) I have tested this in the past with a rebuild of most packages
that are in the base essential chroot in the past and it works well.
Regards,
Michael.
On Wed, May 17, 2023 at 11:27:43AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Michael!
>
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > > After a long discussion on IRC and t
Package: g++-12
Version: 12.2.0-14
Severity: normal
X-Debbugs-Cc: iv...@isle.spb.ru
Dear Maintainer,
When I compile c++ code which has an error (method invoked on
null class pointer) the following problem occurs: the actual
call does not crash, since 'this' pointer is not really used
in called me
Source: gcc-14-cross-ports
Version: 4
Severity: wishlist
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org
Please consider building loong64 cross-compiler too, once
this architecture has become one of debian ports.
In particular, this is needed to build qemu (only a tiny
part so far, vdso.so h
Package: cpp-8
Version: 8-20180321-1
Severity: minor
Dear Maintainer,
/usr/lib/gcc/x86_64-linux-gnu/8/cc1 is not stripped and therefore quite
large (171M). The same is true for /usr/lib/gcc/x86_64-linux-gnu/8/lto1.
For other gcc versions, these files are stripped, so I guess they should
also be
package: src:gcc-8
severity: normal
version: 8.1.0-3
Wine now relies on this [0], but it seems to be missing in gcc on
arm64. It is supported in newer versions of clang on arm64.
Best wishes,
Mike
[0]https://buildd.debian.org/status/fetch.php?pkg=wine-development&arch=arm64&ver=3.8-1&stamp=1526
package: src:gcc-6
version: 6.4.0-18
severity: grave
control: affects -1 src:chromium-browser
forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86166
This was marked as a duplicate upstream and closed, but it seems like
it should be considered a separate issue.
The latest chromium upload no
Package: gcc-s390x-linux-gnu
Version: 4:11.2.0-2
Severity: normal
Current package have:
Depends: cpp-s390x-linux-gnu (= 4:11.2.0-2), gcc-11-s390x-linux-gnu (>=
11.2.0-1~)
It looks like after switch to gcc-12, it should be gcc-12-s390x-linux-gnu
instead.
Currently in unstable, gcc-s390x-linux-
On Sat, 6 Feb 2021 08:54:57 +0100 Dennis Filder wrote:
Control: tag -1 - patch + moreinfo
After looking into this some more, I don't think this is necessarily a
bug in dwz, but it could also be either someone using rogue DW_OP_*
definitions with values 0x00 and 0x01 or a buggy compiler/assemble
It is the same on arm64 too, eg:
https://buildd.debian.org/status/package.php?p=qemu&suite=bullseye-backports
/mjt
Package: gcc-12-alpha-linux-gnu
Version: 12.2.0-1cross3
Severity: normal
Starting this version of gcc, -mbuild-constants option causes it to produce
an ICE. Example is below. This is an old code, always worked before, in
particular with gcc-11.
Removing -mbuild-constants fixes the ICE. But this
Package: gij
Version: 2:3.0.4-5
Followup-For: Bug #145447
This postinst should work:
#! /bin/sh -e
update-alternatives --quiet --install /usr/bin/java java
/usr/bin/gij-wrapper-3.0 30 --slave /usr/share/man/man1/java.1.gz
java.1.gz /usr/share/man/man1/gij-wrapper-3.0.1.gz || true
# dh_doclink
i
Package: gcj-3.1
Version: 1:3.1-2
Severity: normal
I tried to use gcj-3.1 to compile an app I'm helping with development.
Unfortunately an old libgcj2 from gcj-3.0 was installed. gcj-3.1 used
this version of libgcj installed of the version of libgcj3, which was
intalled too.
IMO gcj-3.1 should r
Package: libgcj3
Version: 1:3.1-2
Severity: normal
libgcj3 includes the file called:
/usr/lib/security/classpath.security
Unfortunately the package "classpath" includes the same file.
Either libgcj3 shouldn't include this file or both packages should
forbid the other.
-- System Information
D
Package: gij-3.1
Version: 1:3.1-2
Severity: normal
gij-3.1 contains the file /usr/bin/gij-wrapper-3.1. This file tries to
execute the file /usr/bin/gij-3.0 which is part of gij-3.0. It should
execute /usr/bin/gij-3.1
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux ast
Package: gcj-3.1
Version: 1:3.1-2
Severity: normal
gcj-3.1 should provide /etc/alternatives/javac
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set)
Package: gij-3.1
Version: 1:3.1-2
Severity: normal
gij-3.1 should provide java-runtime2. I found that I cant install
libbtools-java because no package provides java-runtime2 except
j2sdk1.3.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux asterix 2.4.18-k7 #1 Sun Apr
Package: gcj-3.1
Version: 1:3.1.1-0pre1
Severity: normal
The manpage of gcj-3.1 reads as following:
-Idir
All directories specified by "-I" are kept in order and prepended to the
class path constructed from all the other options. Unless compatibility
with tools like "javac" is import
ii gcc-3.1-base 1:3.1.1-0pre1 The GNU Compiler Collection (base
ii libc6-dev 2.2.5-6 GNU C Library: Development Librari
ii libstdc++4 1:3.1.1-0pre1 The GNU stdc++ library version 3
-- no debconf information
--
|=| Michael Piefel
|=| Humbold
st upload (1.3.7-4) since the
earlier ones produced quite a lot of noisy warnings.
Thanks a lot.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
Hi,
I'm not sure why it worked this time, but the most recent CVS snapshot I
uploaded as tora_1.3.7-4 did compile correctly on hppa as well I just
learned.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
sier if you just try compiling the package on your
machine. Anyway, I can surely create a log and send that.
However, now that it compiled on gcc-3.0 or 3.1 I wonder if there are
just some incompatibilities in the source code.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhei
of arm, hurd-i386, m68k, mips, mipsel, s390 and sh.
For m68k I found several libgcc symbols on my system using the script
that was posted here. Someone will have to run a check over the whole
archive, however I don't have the resources to do so.
CCing m68k-build, any takers?
-Michael
On Fri, Jan 17, 2003 at 10:29:03AM -0500, Daniel Jacobowitz wrote:
This libc ld.so special handling for hardware capability is used by
only MMX currently. We expand it not only for MMX but also CMOV.
MMX, intel's multi media extension, is also same circumstance that
both Pentium (i586) and Pentium
be
public? Or maybe I just haven't found the right command...
-Michael
> On Wed, Feb 05, 2003 at 12:28:20PM +0100, Richard Zidlicky wrote:
> > On Wed, Feb 05, 2003 at 09:06:42AM +0100, Rene Engelhard wrote:
> > >
> > > Hi,
> > >
> > > [ please Cc
d log.
This error also occured on gcc-2.95, I did not file it earlier because I
was hoping that it might be gone in gcc-3.2. The first builds in early
2002 were done with -O and then with -O0 afterwards.
You can get the source file at
http://people.debian.org/~mbanck/lebedev.c
thanks,
Michael
On Tue, Mar 04, 2003 at 02:14:32PM -0600, you wrote:
coreutils fails to build from source on m68k, test failing.
Well, it works everywhere else. GCC compile error? The test that's
failing is the sha1sum validation, the source for which has not changed.
Mike Stone
Package: libgcj3-dev
When attempting to install this package, I get the following error
message:
Sorry, but the following packages have unmet dependencies:
libgcj3-dev: Depends: LIBC_DEV but it is not installable
I have libc6 and libc6-dev 2.3.1-14 installed.
I'm guessing LIBC_DEV is an automa
but got lost in the
build-system/source-tree.
cheers,
Michael
ollection
(base
ii libc62.3.1-17GNU C Library: Shared
libraries an
ii libgcc1 1:3.3-0pre7 GCC support library
-- no debconf information
--
Michael Babcock
Jim Henson's Creature Shop
That version (1:3.3ds8-0pre8) fixed it. Thanks.
fixes this, but maybe libgcj-common shouldn't be
built either? Though I guess it doesn't hurt much on the other hand.
thanks,
Michael
--- gcc-defaults-1.61/debian/rules 2007-09-02 22:46:50.43000 +
+++ gcc-defaults-1.61+hurd.1/debian/rules 2007-10-04 10:00:
# same problem as with gcc-4.1/#433539
reopen 434937
thanks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ut it.
thanks,
Michael
PS: If you prefer, I can maintain those hurd-specific patches in gcccvs
myself.
#! /bin/sh -e
# DP: Support -ffast-math on hurd-i386.
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
e
ed.
I checked the Debian Changelog but couldn't find any reference why this
dependency was added. Please revert this change again.
Cheers,
Michael
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (300, 'experimental&#
Hallo,
wenn ich versuche unter Sidux 2007-04.5 'libctapi-cyberjack2' zu
installieren, gibt es ein Abhängigkeitsproblem mit apt. Der Output:
libctapi-cyberjack2:
Depends: libgcc1 (>= 1:4.2.1) but 1:4.2-20070525-1 is to be installed
Depends: libstdc++6 (>= 4.2.1) but 4.2-20070525-1 is to be install
ut
still it seems to be broken.
Best,
Michael
pgpzC2DrflZRI.pgp
Description: PGP signature
> 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
Let me explain briefly the issue I've run into:
1. I build a really `short` application under Fedora or Mandrake disto(s):
int main()
{
return 0;
}
On both above platforms, it is build with command:
g++ -g -O0 -m32 test2.cpp,
where test2.cpp is a file with above mentioned code.
2. I
This patch configures the built in spec file to pass -fgnu89-inline, and
thus allowing
proper compilation and linking with the older glibc on m68k. This patch
should not be
merged upstream, and it should be removed once a newer glibc is available
for our architecture.
Michael
--- linux-old.h
X-Debbugs-CC: [EMAIL PROTECTED]
I should not send patches when I'm half alseep. Here's one that's actually
appliable ;-)
--- gcc-4.3.1/gcc/config/m68k/linux-old.h2008-07-04 04:02:21.0
-0400
+++ gcc-4.3.1/gcc/config/m68k/linux.h2008-07-04 05:23:21.0 -0400
@@ -37,6 +37,13 @@
ue, please contact me.
Best,
Michael
[0]
http://buildd.debian.org/fetch.cgi?&pkg=diagnostics&ver=0.2.2%2Bb1&arch=s390&stamp=1214648343&file=log
#include
// component
#include
#define TEST_COMPONENT_NAME invariance_annotation
#define TEST_COMPONENT_NAMESPACE diagnostics
Package: gcc
Version: 4.3.1
Severity: important
As explained at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37090 the GCC in
version 4.3.1 produces broken code for some loops.
Please upgrade GCC to a newer version before freezing lenny to stable, because
we otherwise have to use/add workarounds f
-4.2-base be demoted to optional?
Michael
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.27-rc6
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charma
that must be taken care of is transitions to testing, if I'm not mistaken. Or am
I getting something wrong?
Thanks,
Michael
pgp6yyAlRUErN.pgp
Description: PGP signature
> 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
> >
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
> 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
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
Package: gcc-4.3
Version: 4.3.2-1
Severity: important
gcc stops with an internal compiler error when compiling mplayer 2008-12-12
snapshot.
cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement
-std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -mcpu=970
-m
invariance_annotation.preproc.cpp
./invariance_annotation
vs.
g++ -g -O2 -DVOLATILE -o invariance_annotation invariance_annotation.preproc.cpp
./invariance_annotation
All experiments were done in the sid chroot on zelenka.d.o.
Hope this helps,
Michael
// try:
// g++ -O2 -o invariance_annotation
package barely useable in that case. Upstream already has a
patch in CVS that will be picked up for 0.10-2.
Best,
Michael
pgpiSWAzikuvn.pgp
Description: PGP signature
onfirmed that
my fix is appropriate.
Thanks again and sorry for the noise,
Michael
pgpBfDmeBqKQQ.pgp
Description: PGP signature
e situation. I'll do my best to keep the frequency of uploads as low as
possible such as not to block the buildds for too long. If you see any option
for improvements I'm of course open to integrate them with the build rules of
the ppl package.
Thanks,
Michael
pgpzDIGs8pidP.pgp
Description: PGP signature
> 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
Package: gcc-4.3
Version: 4.3.3-10
Severity: serious
Justification: causes package to ftbfs
Hi,
currently rsyslog ftbfs on powerpc due to a ICE.
See
https://buildd.debian.org/fetch.cgi?&pkg=rsyslog&ver=3.22.0-1&arch=powerpc&stamp=1242425299&file=log
for details.
Cheers,
>Submitter-Id: net
>Originator:Michael Walle
>Organization:
>Confidential: no
>Synopsis: segfault with bitfields in structs
>Severity: serious
>Priority: medium
>Category: c
>Class: ice-on-legal-code
>Release: gcc (Debian
reassign 532821 binutils
found 532821 2.19.1-1
block 528145 by 532821
thanks
Michael Biebl wrote:
> I'm cloning the bug for gcc, because this is (one of) the packages of the
> build
> toolchain that was updated between the 1.2.12-1 and 1.2.14-2 build of dbus.
> The
> last up
95, A <= 2, B >= 0, B <= 2
Please let me know if there's anything else I can do; the complete sources are
still there on abel.d.o.
Best regards,
Michael
[1]
https://buildd.debian.org/fetch.cgi?&pkg=ppl&ver=0.10.2-7&arch=armel&stamp=1280947057&file=log
[2]
https:/
o builds fine in squeeze before the release.
>
[...]
Thanks for checking; this bug has already been fixed in 0.10.2-7 (and 0.10.2-8
should now also be ready for later migration to squeeze).
Best,
Michael
pgpOI0fK4T5S0.pgp
Description: PGP signature
version(s) in sid!?
Thanks a lot,
Michael
pgp48wvmEuOUf.pgp
Description: PGP signature
ectures to have older swi-prolog versions lingering around.
Best,
Michael
pgpI1bUjiz6rK.pgp
Description: PGP signature
ssary, 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
find.
Thanks a lot,
Michael
pgp6zbff3mryN.pgp
Description: PGP signature
en you maybe can build from the same source. If not,
> maybe renaming the source is easier ;)
>
Could you please only let me know which versions you refer to as "old" and
"new"? It seems that Debian has 0.15.9 while on the homepage of cloog I can only
find 0.14.1 (and
g with cloog
developers I don't expect this to change any time soon.
Best regards,
Michael
pgpnIEUr2UezV.pgp
Description: PGP signature
_shlibdeps
-plibgcc1-powerpc-cross
/usr/bin/perl: error while loading shared libraries:
/usr/powerpc-linux-gnu/lib/libdl.so.2: ELF file data encoding not
little-endian
make[1]: *** [stamps/08-binary-stamp-libgcc] Error 127
Commenting SET_CROSS_LIB_PATH fixes the problem for me.
Kind regards,
Michael
re you added it?
Thanks a lot,
Michael
pgpLmm7HIeqA8.pgp
Description: PGP signature
those (presumably producing suboptimal, but at least working, code).
Cheers
Michael.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d87125c.1040...@orcon.net.nz
ON, hence I'd agree that libapron-dev should build-depend on
libppl-dev.
Hope this helps,
Michael
pgpXYf7krycnD.pgp
Description: PGP signature
int.h"
+ tmake_file="${tmake_file} alpha/t-linux"
extra_options="${extra_options} alpha/elf.opt"
target_cpu_default="MASK_GAS"
;;
With that my test build of gcc-4.7 has past the previous point of
failure and is in the test suite as
1 compilation links failed so no patch attached here, sorry.)
The old version of gcc-4.5 at debian-ports currently breaks installation
of the Alpha port with debootstrap, so an upload of a fix would be very
much appreciated, but we will understand if this is not possible because
of the freeze.
Chee
result in no loss in performance to gcc/g++/gcj/etc since only the link
of the stage-1 compiler does not get relaxation optimisation.
Cheers
Michael.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
On 16/07/12 21:27, Michael Cree wrote:
> gcc-4.5 FTBFS on alpha with GPREL16 relocation truncation errors in the
> link of cc1-dummy during stage 1 compilation. Full build log is at:
Ha, ha, I see I added the patch tag to the bug report but no patch :-/
Adding the following in debian/
Package: gcc-4.7-base
Version: 4.7.2-1
Severity: serious
I do have multiarch enabled: amd64 being the primary arch, i386 the secondary.
During today's upgrade I got the following error message:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correc
realistic as I'm loaded
with real-life work).
Sorry,
Michael
pgpd0OuJRhBNd.pgp
Description: PGP signature
java.util.Scanner;
>^
> The import java.util.Scanner cannot be resolved
> --
>
> The eclipse compiler should be fixed to compile the program.
This is not a bug in the Eclipse compiler itself but in the class library
it uses. When GCJ got updated to version 4.4.0 t
> 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
> >
> 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
the buildd, which seems somewhat
more likely given the excerpt of daemon.log provided at the end of this log.
Looking at other build logs the above diff seems to be about the last thing
before install, and it worked fine on all Debian buildds just a few days ago!?
Thanks,
Michael
pgp4e76dmcQcg.pgp
Description: PGP signature
t;
>
> However, it's not diff that is blocking, it's ppl_pl. It's eating all the
> available memory and causes swapping. I've attached the output of ps.
> the status of the process is:
[...]
I'll see what I can do about this, I just wonder why it didn't happ
r could you try to dig further yourself? Otherwise I'm absolutely
clueless how to handle this. Obviously it fails to build, which is also
reproducible on your hosts, but seemingly not in any other environment. I think
we'll need some further examinations using strace and gdb at least.
[ prephitmp.1208 ])
(const_int 0 [0x0]))) -1 (nil))
packet-l2tp.c:1680: internal compiler error: in extract_insn, at
recog.c:2001
Would this be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113 ??
Cheers
Michael.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
On 02/12/09 18:18, Matt Turner wrote:
On Tue, Dec 1, 2009 at 3:08 PM, Michael Cree wrote:
On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote:
Package: gcc-4.3
Version: 4.3.4-5
Hi,
I recently started seeing several cases of gcc giving an error
message like this:
packet-l2tp.c:1680: error
On 06/12/09 23:21, Kurt Roeckx wrote:
On Wed, Dec 02, 2009 at 12:18:47AM -0500, Matt Turner wrote:
On Tue, Dec 1, 2009 at 3:08 PM, Michael Cree wrote:
On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote:
Package: gcc-4.3
Version: 4.3.4-5
Hi,
I recently started seeing several cases of gcc giving
o and there was a gcc upload in between which could
have caused that regression.
Michael
[1]
https://buildd.debian.org/fetch.cgi?pkg=fsarchiver;ver=0.6.5-1;arch=alpha;stamp=1263529331
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
severity 565455 normal
thanks
downgrading to normal as alpha is no longer a release arch and it builds fine on
all other architectures.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital si
;t care that much about clean prolog tests.
>
I was aware of that and already have a workaround tested and ready for upload; I
just did not get around to do the final build. I'll try to get it done as soon
as possible.
Best,
Michael
pgpzCdLYns9Ma.pgp
Description: PGP signature
> 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
tag 361608 pending confirmed
thanks
Hello,
this was a bug in java-gcj-compat and got fixed in version
1.0.52-0ubuntu1. I will soon (on monday) upload 1.0.55 to unstable which
fixes this too.
Thanks for reporting this.
Cheers,
Michael
--
Escape the Java Trap with GNU Classpath!
http
, and Thomas Schwinge
made a successful cross-compiled test build. We hope gcc-4.1 is now
working for hurd-i386.
cheers,
Michael
--
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html
--- debian/patches/hurd-changes.dpatch.orig 2006-05-31 14:4
, two on hobbes) each blocking a fast host for 48+
hours, IIRC. Unless there's other biggies lurking in the queue, we should
catch up once the hopfully final glibc build is through.
N.B.: the flurry of glibc uploads speaks loud and clear as to people
getting their packages into shape for re
se that fail
> with ICE in gcc-4.0 before that time. Since m68k is not a release
> architecture right now, this should not cause any problems for any other
> port if the GCC 4.1 transition does not happen, but it will help if it
> does.
>
> Thoughts, objections?
I fully con
1 - 100 of 234 matches
Mail list logo
