gcc3 evaluation platforms

gcc currently defines release criteria for gcc3. See http://gcc.gnu.org/gcc-3.0/criteria.html. For ix86 Debian is proposed as primary evaluation platform. For sparc and alpha, Ben Collins and Chris Chimelis volunteer to evaluate gcc3. Currently we do not have feedback from the other architectures (

glibc build-depends on gcc-4.0 on hurd-i386?

Is this a leftover, which can be changed to gcc-4.1 now? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

gnat-4.1/gcj-4.1 manual builds needed on alpha, arm, m68k, mips, mipsel, s390, sparc

While having built and uploaded things correctly for experimental, I didn't do the same for unstable, which now needs some manual intervention building gnat-4.1 and gcj-4.1. gnat-4.1 (mips mipsel s390 sparc): - work in a sid chroot - install gnat-4.1-base libgnat-4.1 libgnatprj4.1 libgnatvsn4.1

GCC 4.2 transition

The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition.

bash-2.04 bug reports for the hurd

Please could somebody of the Debian hurd people look at these two bug reports for bash on the hurd? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71777&repeatmerged=yes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71778&repeatmerged=yes Thanks

Re: bash-2.04 bug reports for the hurd

--- Begin Message --- > Please could somebody of the Debian hurd people look at these two bug > reports for bash on the hurd? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71777&repeatmerged=yes Does a trap set on SIGINT print anything when ^C is hit? It may be that bash is being killed b

Re: task-devel-common not installable on the Hurd

Brian May writes: > >>>>> "Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes: > > Matthias> The only idea I have for a solution is to make the > Matthias> package arch dependent. The syntax > > Matthias> Depends:

gcc-2.95

Jeff Bailey writes: > The problem is the actual testsuite itself. In debian/rules2 line 311, > they run awk against /proc/meminfo (obviously doesn't exist). Is there a way to determine the amount of free memory (including free swap)? Some test cases in the testsuite eat up all memory and can c

Re: gcc-2.95

Neal H Walfield writes: > > Is there a way to determine the amount of free memory (including free > > swap)? > > Absolutely; take a look at mach/mach.defs:vm_statistics and > . interesting ... is there NO way to get this information via a shell command/script?

Re: gcc-2.95

Neal H Walfield writes: > On Thu, Apr 19, 2001 at 07:26:36PM +0200, Matthias Klose wrote: > > Neal H Walfield writes: > > > > Is there a way to determine the amount of free memory (including free > > > > swap)? > > > > > > Absolutel

reassign bash bugs to hurd

reassign 71777 hurd reassign 71778 hurd thanks I am unable to test these. Please could someone of the hurd team check these? Thanks, Matthias

help needed: does the current gcc-3.0 package build on the hurd?

The current gcc-3.0 package in unstable has libffi enabled for the Hurd. Does libffi build on the Hurd, or should libffi disabled again? Thanks, Matthias

work needed on the python2.1 -> 2.2 transition

Good news first. It becomes more tedious to track the bug-free packages. Besides the usual serious bugs, the following issues remain: - wxwindows2.2 is still unbuildable in unstable, not yet removed from unstable, package maintainer does not respond. Oh fun! - postgresql: doesn't go to testing

Re: gcc-2.95 built successfully

Jeff Bailey writes: > Mathias, (and an FYI cc: to Debian-hurd) Hi Jef ;-) > Your latest gcc-2.95 built successfully without any modifications or > tweaks on my part. It produced: > > chill-2.95 > cpp-2.95 > gcc-2.95 > gobjc-2.95 > gpc-2.95 hmm, could you look, if I disabled g77-2.95 in debian/

default CPU target for ix86 based ports

Now that the kernel-image packages supports hw emulation of i486 instructions on i386 hardware, I'd like to change the code generation to default to i486 (not sure if it should be tuned for any other target, i.e. -mtune=i686). IIRC the Hurd can be built for i586 only, so it could be used as the de

Re: default CPU target for ix86 based ports

Marcus Brinkmann writes: > On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote: > > IIRC the Hurd can be built for i586 only, so it could be used as the > > default target CPU as well. > > We only require a coprocessor, but anything < i586 doesn't make much

Re: Bug#301064: gcc-3.4: FTBFS on hurd-i386: Missing headers

sorry, don't know anything about the status on the Hurd, CCing debian-hurd. Michael Banck writes: > Package: gcc-3.4 > Severity: important > > Hello, > > Your package failed to build on hurd-i386: > > > Automatic build of gcc-3.4_3.4.3-12 on beethoven by sbuild/hurd-i386 1.170.5 > > Build start

gcc builds on bsd and on the hurd

The next gcc-* uploads, depending on the dpkg-architecture changes, are not tested on the Hurd and on the bsd targets. So please don't auto-build them blindly. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]