Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Thorsten Glaser
Steven Chamberlain dixit:

>Before that can be changed, I think the gcc-defaults package expects
>package version (>= 4.8.1-2) whereas m68k still has only the 4.8.0-7 you
>uploaded.

Right. That’s because gcj FTBFSes.

>You will also first need newer binutils (>= 2.23.52) which is still in
>the build queue.

True; that’s new, but it’ll be done eventually, no hurries there ☺

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P)
‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P)
‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1306132021420.22...@herc.mirbsd.org



Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Steven Chamberlain
Hi,

On 13/06/13 20:47, Thorsten Glaser wrote:
> From me nothing against switching C/C++ to 4.8 for m68k at
> this point, but I’d like to hear at least Wouter’s opinion
> on that, and possibly Mikael [...]

Before that can be changed, I think the gcc-defaults package expects
package version (>= 4.8.1-2) whereas m68k still has only the 4.8.0-7 you
uploaded.

You will also first need newer binutils (>= 2.23.52) which is still in
the build queue.

(This applies to ppc64 as well).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ba2417.9070...@pyro.eu.org



Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Thorsten Glaser
Matthias Klose dixit:

>The Java and D frontends now default to 4.8 on all architectures, the Go
>frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.

I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
until the 4.8 one stops FTBFSing.

From me nothing against switching C/C++ to 4.8 for m68k at
this point, but I’d like to hear at least Wouter’s opinion
on that, and possibly Mikael since he’s not just doing work
upstream on gcc but also using it (for ColdFire) heavily.

For Ada, I’d like to see a successful build of gnat-4.8
(from src:gcc-4.8, if I understand the recent changes right)
first; gnat-4.6 mostly works at the moment, but I’m not sure
about the upstream situation wrt. patches from Mikael.

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1306131944240.22...@herc.mirbsd.org



Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Tobias Frost
Am Donnerstag, den 13.06.2013, 15:46 +0100 schrieb Steven Chamberlain:
> Hi,
> 
> On 13/06/13 13:51, Matthias Klose wrote:
> > GCC 4.8 is now the default on all x86 architectures, and on all ARM
> > architectures (the latter confirmed by the Debian ARM porters).  I did not 
> > get
> > any feedback from other port maintainers, so unless this does change and 
> > port
> > maintainers get involved with toolchain maintenance, the architectures 
> > staying
> > at 4.6 or 4.7 shouldn't be considered for a successful release 
> > (re-)qualification.
> 
> I trust these are the architectures that are okay so far:
> | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64
> kfreebsd-i386 hurd-i386
> 
> So the following would be the architectures for which some response is
> requested urgently from port maintainers, to confirm they are ready for
> GCC 4.8 as default:
> 
> Release arches: ia64 mips mipsel powerpc s390 s390x sparc

Is there some kind of timeframe expected when switch can be expected?

I'm asking because I currently have some tool chain related build
failure on the above archs (except ia64) for drizzle [1] (Bug 708434) --

From here, it looks like that the gcc 4.6.3-14 used on this archs needs
a bin-nmu (?), as it is still expecting libcloog-ppl0, which is no
longer available. [2]

Matthias, could I be on the right path? What would be the right procedure
here? (CC'ing d-mentors for this question)

coldtobi

[1] https://buildd.debian.org/status/logs.php?pkg=drizzle&ver=1%
3A7.1.36-stable-4&suite=sid
[2] http://packages.qa.debian.org/c/cloog-ppl.html


--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1371151240.6107.0.ca...@mordor.loewenhoehle.ip



Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Steven Chamberlain
Hi,

On 13/06/13 13:51, Matthias Klose wrote:
> GCC 4.8 is now the default on all x86 architectures, and on all ARM
> architectures (the latter confirmed by the Debian ARM porters).  I did not get
> any feedback from other port maintainers, so unless this does change and port
> maintainers get involved with toolchain maintenance, the architectures staying
> at 4.6 or 4.7 shouldn't be considered for a successful release 
> (re-)qualification.

I trust these are the architectures that are okay so far:
| gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64
kfreebsd-i386 hurd-i386

So the following would be the architectures for which some response is
requested urgently from port maintainers, to confirm they are ready for
GCC 4.8 as default:

Release arches: ia64 mips mipsel powerpc s390 s390x sparc

All the above have built gcc-4.8.1-2 or higher.

Other ports:  alpha hppa* m68k powerpcspe ppc64 sh4* sparc64*

* these ports don't appear to have successfully built GCC 4.8 yet.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b9db2c.2060...@pyro.eu.org



Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Matthias Klose
Am 07.05.2013 15:25, schrieb Matthias Klose:
> The decision when to make GCC 4.8 the default for other architectures is
> left to the Debian port maintainers.
[...]
> Information on porting to GCC 4.8 from previous versions of GCC can be 
> found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html
> 
> It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove
> 4.4, 4.6 and 4.7 from jessie.

GCC 4.8 is now the default on all x86 architectures, and on all ARM
architectures (the latter confirmed by the Debian ARM porters).  I did not get
any feedback from other port maintainers, so unless this does change and port
maintainers get involved with toolchain maintenance, the architectures staying
at 4.6 or 4.7 shouldn't be considered for a successful release 
(re-)qualification.

The Java and D frontends now default to 4.8 on all architectures, the Go
frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b9c05f.8050...@debian.org



Please don't upgrade libc0.3 to 2.17-3+hurd.3

2013-06-13 Thread Samuel Thibault
Hello,

It seems the patch management system has eaten the DNS-fixing patch,
don't upgrade to +hurd.3, it can't resolve names any more again... I'm
building yet another +hurd.4.

Samuel


-- 
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130613073953.gg5...@type.youpi.perso.aquilenet.fr