any objections from port maintainers to make gcc-4.4 the default?
Besides the open license issue, are there any objections from port maintainers to make GCC-4.4 the default? As a first step that would be a change of the default for C, C++, ObjC, ObjC++ and Fortran. I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's not amymore the default java compiler for all architectures except hurd(?), kfreebsd(?) and hppa. hppa already defaults to 4.4, what about the hurd and kfreebsd? Ada will still stay at 4.3 until Ludovic is ready to switch the default to 4.4. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 06.09.2009 16:49, Jurij Smakov wrote: On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote: On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going the port is currently using 4.3 as the default, I do plan to make 4.4 the default unless port maintainers object [1]. Ubuntu karmic already uses 4.4 as the default, but as a community port sparc doesn't get the same attention as other ports. Please see [2] for current problems with sparc. I do not plan to invest significant time in fixing build issues on sparc for squeeze. I do commit to prepare binutils and gcc-4.4 for a sparc64 port if this should happen for squeeze. Matthias [1] http://lists.debian.org/debian-release/2009/09/msg00239.html [2] http://qa.ubuntuwire.org/ftbfs/ -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 20.08.2009 16:52, Aurelien Jarno wrote: Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. this seems to be the way to go, but port maintainers seem to lack enthusiasm or resources. I'm willing to help, if somebody commits to these ports. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Unable to create MD device during install
[ Please Cc me in the answer, I'm not in the list ] We are using 20090123lenny4 SPARC neinst image for installation. We select mdcfg and lvmcfg as an additional installation components. After disks are detected and we start with partitioning, we are unable to create Linux raid autodetect partitions. Thus we are not able to create MD devices, which we would liek to use and an underlying devices for LVM2. Is this an installer bug or we are doing some mistake during the installation? Thank you for your help. Ondrej [ Please Cc me in the answer, I'm not in the list ] -- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - i...@platon.org - http://platon.org -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Unable to create MD device during install
[ Please Cc me in the answer, I'm not in the list ] I have read through all this thread and bug http://lists.debian.org/debian-sparc/2007/04/msg8.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411756 which gives me pretty good answer to my question. However there is another problem present: our 36G SCSI drives are lowered to 6G after creating first partition. After creating any partition, partman reports our disks as 6GB, while at the beginning it reported 36G. Any clue on this? I'm unable to find this in archive. Thank you On Mon, 21 Sep 2009, Ondrej Jombik wrote: [ Please Cc me in the answer, I'm not in the list ] We are using 20090123lenny4 SPARC neinst image for installation. We select mdcfg and lvmcfg as an additional installation components. After disks are detected and we start with partitioning, we are unable to create Linux raid autodetect partitions. Thus we are not able to create MD devices, which we would liek to use and an underlying devices for LVM2. Is this an installer bug or we are doing some mistake during the installation? Thank you for your help. Ondrej [ Please Cc me in the answer, I'm not in the list ] -- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - i...@platon.org - http://platon.org -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
