Re: Advancing Debian Alpha Porting
--On Wednesday, April 20, 2011 12:30:13 AM -0700 Bill MacAllister
w...@stanford.edu wrote:
--On Tuesday, April 19, 2011 10:44:31 AM +1200 Michael Cree
mc...@orcon.net.nz wrote:
On Mon, April 18, 2011 1:48 pm, Witold Baryluk wrote:
On 04-14 06:43, Bill MacAllister wrote:
It appears we are to provide the Alpha buildds. We need at least
two for redundancy but if older hardware is used then we may need
three or four. Craig, Witold, Robert, are you all able to offer a
machine to be a buildd? I don't think I can---I have an XP1000 that
is my main computer that I use, and two PWS600au, but they are a bit
slow.
Absolutly.
I can offer almost right now 2 fully loaded XP1000 exclusivly for buildd.
Great. That's five machines at three sites. Two XP1k, Two A1200, and a
CS20. That should get us going nicely.
I am off on holiday over the Easter break and probably won't be able to
check my email for a week.
Cheers
Michael.
It would be great to get a summary of machine and sites. From this email
stream I think the list is:
System DescriptionContributor
-
2 XP1000, 1GB RAM Witold Baryluk bary...@smp.if.uj.edu.pl
CS20 Craig Prescott c...@ekkaia.net
AS1200, 4GB, Dual CPU Bill MacAllister w...@stanford.edu
DECServer 5000, 2GB, Dual CPU Bill MacAllister w...@stanford.edu
Someone else might have spoken up with other AS1200's, but in my
search through the email stream I didn't see it. Please correct me if
I have this wrong.
My systems will be on-line after I get a chance to move them into my
office at Stanford. Note, I have asked for permission to do this and
have not received a response yet. So, there is a possibility that I
will be scrambling for a place to hook these systems up.
Bill
It turns out that the two systems that I have to contribute as bbuilds
are both single processor AS1200s. They are on line and I have just
started the processing of making then bbuild servers. I will shuffle
CPUs from the DEC5000 into the AS1200 cases sometime in the next week
or two to make dual CPU systems. The systems have 2gb and 1.5 gb
memory each and each system has a total of 360gb of disk space.
In Aurelien Jarno message of the 25th he asked for a single contract
from the Alpha community to interface with. Has anyone taken that role?
Bill
--
Bill MacAllister
Infrastructure Delivery Group, Stanford University
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/749C0B00E530C0C1759F6E83@[10.0.0.32]
Re: GCC-4.5 as the default for (at least some) architectures
On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be used for the next Fedora and OpenSuse releases, and a test rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable C++ build failures). A test rebuild of the unstable archive is still outstanding, but these build failures will have to be fixed anyway. From my point of view it's important to expose GCC 4.6 early in the release cycle to fix issues like #617628 (which are issues in the packages itself) now. With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, which is not easily detachable from the GCC version change. However this change only affects GNUstep, which can be dealt with NMU's, or migration to a new GNUstep version. It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D maintainers are already working on GCC 4.6 support. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6dea5.5010...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? Thanks Konstantinos -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimddKkTaiy1fyka6zMOj0o1YzBS=a...@mail.gmail.com
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote: On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package: https://buildd.debian.org/status/package.php?p=vxl but since there is no log I cannot confirm this is the same ICE as on i386/armel thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com
Re: Compaq compilers. thanks.
You can get the decrypted rpm (and all the other Compaq tools and libraries) here: http://alphalinux.org/software/ccc/ Oh. Thanks you! I was also searching this yeasterday few hours :) HP should open-source as much as possible from this compiler IMHO. Similar like they done with AdvFS for example. But well, they should do this right now if possible. Question is who have rights to it now, and what parts was sold to other companies (like Intel) :) BTW. Does anybody know if anybody is considering porting advfs from sourceforge to linux or fuse? It would be interesting project, as well help with migration and interoperation (I for example have about 30x20GB images of disks with AdvFSs one them). Witek. -- Witold Baryluk signature.asc Description: Digital signature
Re: Advancing Debian Alpha Porting
On 04-26 00:29, Bill MacAllister wrote:
It would be great to get a summary of machine and sites. From this email
stream I think the list is:
System DescriptionContributor
-
2 XP1000, 1GB RAM Witold Baryluk bary...@smp.if.uj.edu.pl
Correct. Each will start with 50GB of local storage on LVM + lots on NFSv4.
Will be updated (more machines or more memory) in the future.
CS20 Craig Prescott c...@ekkaia.net
AS1200, 4GB, Dual CPU Bill MacAllister w...@stanford.edu
DECServer 5000, 2GB, Dual CPU Bill MacAllister w...@stanford.edu
each and each system has a total of 360gb of disk space.
...
In Aurelien Jarno message of the 25th he asked for a single contract
from the Alpha community to interface with. Has anyone taken that role?
I cannot count, as I am pretty busy with other tasks (like writing master
thesis)
and alpha-keeping will be only time-to-time job.
(Hovewer I will test and benchmark cutting edge things often and a lot).
I have also tendency to not replay for weeks, if I'm hacking something. :/
Regards,
Witek
--
Witold Baryluk
signature.asc
Description: Digital signature
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426185104.gb29...@hall.aurel32.net
Re: GCC-4.5 as the default for (at least some) architectures
Matthias Klose dixit: At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes Porters side, too. I’m okay with keeping gcc-4.4 for a while (kernel?) and switching to gcc-4.6 directly for m68k. I know I’ll probably have to invest some work into the latter, but considering the kernel problem is almost solved, chances are good. (I do want to bring out a new base emulator image first, though, but then…) bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. Kurt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be
Re: GCC-4.5 as the default for (at least some) architectures
Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit : Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? There's no real reason to defer hurd-i386, as it's basically like i386, and the key packages (glibc/hurd/gnumach) already use a fixed version and can be handled independently. Samuel -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426204147.gs4...@const.famille.thibault.fr
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 09:28 PM, Kurt Roeckx wrote: On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I don't know, and I will not invest time to check. If you did check, and if you are confident to fix issues on these architectures, then please tell here. At least for other ports this seems to be possible (s390: Bastian Blank, kfreebsd-*: Aurelian, Petr). I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. I will not work on toolchain issues specific to these architectures for the wheezy release, so if nobody steps forward, then at least I will not change the default for these architectures. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db73b0c.4000...@debian.org
Re: alpha and hppa removal from unstable/experimental
On 04-14 21:09, Michael Cree wrote: On 04/04/11 05:25, Matt Turner wrote: This is partly due to the fact that I hate trying to submit things to glibc. Also that I don't have any time right now. But mostly because I hate glibc development. So, is there someone in this new Alpha porting team that can help Matt with upstream support on the Alpha port of glibc? I am baulking at it as I am thinking about putting some effort into binutils, particularly ld, and see if I can fix the relax code path of the linker. I suspect that will have quite a nice flow-on effect of fixing quite a few problems with plugins and the linking of large C++ programs. As You know, I already tries to help (testing, bisecting, minimising) in this case. Unfortunetly I always have problem with understating how the whole dynamic linking works under linux. I like digging more into assembly and compiler alone, without linker magic. The patch you posted to the binutils' bugzilla [1] solves a proble in tls relax case, but I have no idea, if this is correct solution and will not introduce any regressions. Probably only Richard Henderson can tell. :) [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12608#c13 -- Witold Baryluk JID: witold.baryluk // jabster.pl signature.asc Description: Digital signature
