RES: unsupporting Architecture: mips

2011-08-19 Thread Ednei Martinez
: debian-java@lists.debian.org; 628...@bugs.debian.org; Matthias Klose; Ludovic Claude; debian-m...@lists.debian.org Assunto: Re: unsupporting Architecture: mips On Wed, Aug 10, 2011 at 12:09:02AM +0200, Damien Raude-Morvan wrote: > Le jeudi 04 août 2011 10:25:34, Aurelien Jarno a écrit : >

Re: unsupporting Architecture: mips

2011-08-11 Thread Damien Raude-Morvan
Hi Aurélien, On Wed, 10 Aug 2011 23:59:03 +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 12:09:02AM +0200, Damien Raude-Morvan wrote: >> Le jeudi 04 août 2011 10:25:34, Aurelien Jarno a écrit : >> > Both build failures in experimental are due to the switch to gcj-4.6 as >> > a bootstrappi

Re: unsupporting Architecture: mips

2011-08-10 Thread Aurelien Jarno
On Wed, Aug 10, 2011 at 12:09:02AM +0200, Damien Raude-Morvan wrote: > Le jeudi 04 août 2011 10:25:34, Aurelien Jarno a écrit : > > Both build failures in experimental are due to the switch to gcj-4.6 as > > a bootstrapping compiler. They build fine when using gcj-4.4, and it > > seems it's what ha

Re: unsupporting Architecture: mips

2011-08-10 Thread Andreas Barth
* Damien Raude-Morvan (draz...@drazzib.com) [110810 00:09]: > Le jeudi 04 août 2011 10:25:34, Aurelien Jarno a écrit : > > Both build failures in experimental are due to the switch to gcj-4.6 as > > a bootstrapping compiler. They build fine when using gcj-4.4, and it > > seems it's what has to be d

Re: unsupporting Architecture: mips

2011-08-09 Thread Damien Raude-Morvan
Le jeudi 04 août 2011 10:25:34, Aurelien Jarno a écrit : > Both build failures in experimental are due to the switch to gcj-4.6 as > a bootstrapping compiler. They build fine when using gcj-4.4, and it > seems it's what has to be done so that mips doesn't block anything. I am > working to find the

Re: unsupporting Architecture: mips

2011-08-04 Thread Torsten Werner
Hi, On Thu, Jul 28, 2011 at 2:58 PM, Torsten Werner wrote: > we have discussed the problems with mips in New York at DebConf10 last > year. I believe it is time to stop supporting Java on this architecture > because nobody really takes care of it. That is why I want to suggest > the following rad

Re: unsupporting Architecture: mips

2011-08-04 Thread Aurelien Jarno
On Fri, Jul 29, 2011 at 04:45:53PM +0200, Matthias Klose wrote: > On 07/29/2011 12:02 AM, Ludovic Claude wrote: > >Hello, > > > >Would it be possible to use OpenJDK Zero on Mips, but without the Shark > >JIT. This would render Java very slow on this architecture, but at least > >there would be some

Re: unsupporting Architecture: mips

2011-07-29 Thread Andreas Barth
* Andreas Barth (a...@not.so.argh.org) [110729 18:54]: > * Matthias Klose (d...@ubuntu.com) [110729 17:03]: > > On 07/29/2011 12:02 AM, Ludovic Claude wrote: > >> Hello, > >> > >> Would it be possible to use OpenJDK Zero on Mips, but without the Shark > >> JIT. This would render Java very slow on t

Re: unsupporting Architecture: mips

2011-07-29 Thread Damien Raude-Morvan
Le vendredi 29 juillet 2011 18:53:16, Andreas Barth a écrit : > Hi, Hi Andeas, > I just saw that openjdk-7 downloads files from the internet during > binary build. Could we get that fixed please? You refer to things like that (see below) in buildd logs ? - ln -sf /bui

Re: unsupporting Architecture: mips

2011-07-29 Thread Damien Raude-Morvan
Le vendredi 29 juillet 2011 16:45:53, Matthias Klose a écrit : > see the build failures for openjdk-6 and openjdk-7 in experimental. I fixed > the ones for sparc, powerpc, s390; it's up to somebody else to fix it on > mips (and kfreebsd). JFTR, I've made good progress on kfreebsd patches, so we ca

Re: unsupporting Architecture: mips

2011-07-29 Thread Andreas Barth
Hi, * Matthias Klose (d...@ubuntu.com) [110729 17:03]: > On 07/29/2011 12:02 AM, Ludovic Claude wrote: >> Hello, >> >> Would it be possible to use OpenJDK Zero on Mips, but without the Shark >> JIT. This would render Java very slow on this architecture, but at least >> there would be something, a

Re: unsupporting Architecture: mips

2011-07-29 Thread Matthias Klose
On 07/29/2011 12:02 AM, Ludovic Claude wrote: Hello, Would it be possible to use OpenJDK Zero on Mips, but without the Shark JIT. This would render Java very slow on this architecture, but at least there would be something, and this would reduce the impact on other packages such as Subversion.

Re: unsupporting Architecture: mips

2011-07-28 Thread Ludovic Claude
Hello, Would it be possible to use OpenJDK Zero on Mips, but without the Shark JIT. This would render Java very slow on this architecture, but at least there would be something, and this would reduce the impact on other packages such as Subversion. It looks like this plan is feasible, at least ac

Re: unsupporting Architecture: mips

2011-07-28 Thread Matthias Klose
On 07/28/2011 03:58 PM, Rene Engelhard wrote: if openjdk then works (for LibreOffice) on ia64, yes, I could live with that. Currently the gcj-using archs for LibreOffice are ia64, kfreebsd-%. mips switched to OpenJDK, mipsel is in limbo... as said in the past, please track it down to a standal

Re: unsupporting Architecture: mips

2011-07-28 Thread Torsten Werner
Hi, Am 28.07.2011 15:58, schrieb Rene Engelhard: > if openjdk then works (for LibreOffice) on ia64, yes, I could live with that. it does not work on ia64? > But, umm, shouldn't you have sent this mail to -mips, too? :-) Let me quote myself: "needs to be discussed with the release team and the m

Re: unsupporting Architecture: mips

2011-07-28 Thread Rene Engelhard
Hi, On Thu, Jul 28, 2011 at 02:58:38PM +0200, Torsten Werner wrote: > - Get icedtea-7-jre-jamvm built on kfreebsd-*. > - Remove *-gcj packages on all architectures except for a minimal set of > *-gcj packages that are needed to bootstrap openjdk. if openjdk then works (for LibreOffice) on ia64, y

unsupporting Architecture: mips

2011-07-28 Thread Torsten Werner
Hi, we have discussed the problems with mips in New York at DebConf10 last year. I believe it is time to stop supporting Java on this architecture because nobody really takes care of it. That is why I want to suggest the following radical approach, which needs to be discussed with the release team