Re: requalification of arm as etch release architecture
On Sun, Oct 09, 2005 at 12:45:09PM -0400, Joey Hess wrote:
> This is also a useful overview:
> http://spohr.debian.org/~ajt/etch_arch_qualify.html, showing that arm is
> problimatic in the areas of:
> - Not currently having a developer accessible machine;
This needs to be obviously fixed. I have a machine that can be probably
relocated for this purpose, I just need to find a spot to host it. This
has been on my mind for a while, it just has been unclear what are the
requirements for hosting such a machine.
> - Not having enough Debian developers listed as port maintainers;
> (I've not listed myself since I'm still coming up to speed on arm
> myself.)
I added myself, altough I'm catching up myself as well.
> - Not having enough users listed;
This shouldn't be a problem, if we can just find them. Many vendors
seem to ship their arm stuff with debian. I think we need to get in
touch with them, to get actual hardware sold with debian officially
supported..
> - Not having info on who's supporting toolchain stuff etc;
I believe codesourcery is supporting gcc and glibc upstream.
Arm port is well maintained upstream. Some specific boards unfortunetly
aren't maintained in kernel properly.. tosome vendors "Linux support"
means "yeah, with these patches, Linux 2.4.18-rmk-ds-foobar
was able to boot"
> - Only being up-to-date for a very poor 94% of the archive currently
> and only having built a likewise poor 91% of the archive.
> (And thus probably being next in line after m68k, which has just
> started being ignored for testing propigation). A lot of this comes
> down to build failures, eg perl currently fails to build on arm,
> which is really painful for the release team.
Unfortunatly buildd maintainer is not communicating such issues
forward..
> - Requiring a lot more than two buildds to stay as current;
> - Not having sufficient buildd redundancy for when the next netwinder
> does a halt and catch fire.
Current buildd's are quite old. If we can get hold of faster arm systems
with more ram it should be easier. Also, if I have understood correctly,
the objection of more than two buildd's comes from the maintainence
overhead. If we can get a pile of exactly similar arm hardware
maintained at the same place, having identical hardware setup, there
_should_ not be any more maintainence overhead, than say a s390 with
multiple partitions.
> Or would using testing and/or snapshots for arm deployment work well
> enough for most Debian arm users? I know that testing has been fine for
> us at ADS as the base for our Debian arm releases. I doubt there are a
> lot of people running arm on serious servers, and so I question whether
> those using arm for the more or less embedded type stuff that's common
> for this architecture really need a stable release. Some people seemed
> to agree on irc that this was becoming practical now that testing is
> starting to get things like security support. Comments?
This is very true, and especially now that there is testing security
available, there is very few people who need official debian stable
releases. However, it has been unclear if SCC archs would be included in
testing migration or not. Having arm as official debian arch is mostly
a status issue.
Cheers,
Riku
Reply to: