Re: hppa & squeeze
On Fri, Jan 14, 2011 at 09:44:49PM +0100, Joerg Jaspert wrote:
>
> > Recently the hppa porters have expressed interest in doing a
> > squeeze/hppa release, and have asked me to try and identify what it
> > would take for us to make that happen.
>
> I'm not all to thrilled about a squeeze-hppa release in the style we had
> with m68k back in etch. It *is* an added maintenance thing, and if we
> can avoid this, all the better.
>
> > Obviously we would need an archive, which would ideally be either a
> > squeeze-hppa release on ftp.debian.org or the equivalent on
> > debian-ports.org, so my first question is whether or not you, the
> > ftpmasters for those projects, would be open to this.
>
> If there is no other way *AND* there is a considerable demand for a
> squeeze hppa, we will not stand in its way. But we won't like it much. :)
>
> Looking at popcon - ohwell, better don't. HPPA looks bad there.
> We (well, I, I just assume you too) don't want to end up with a port
> thats run just for the fun of the porters ( :) ), so - is there real
> demand out there for a HPPA port?
Hard to say; everytime this comes up there are a couple people who
speakup, but we certainly don't get flooded with +1's.
> Also, add another question: Does HPPA stay on ftpmaster at all? How
> likely is it to get back to a state it can be included into another
> release? If the answer to that tends to be negative, it might be better
> to move it totally to debian-ports, in order to not have to support two
> different archives.
I suspect negative, if only because the hardware is no longer
being produced. (We also have buildd stability issues, which have been
shown to go away on other systems).
Also, one thing I just noticed is that ports seems to only have
unstable/experimental. For some reason I'd assumed "stable" releases
there were an option, but that does not appear to be the case.
That implies we'll have a bit more difficult of a time keeping the
port installable from ports, since we'll need to keep an installer
available that works w/ sid.
> (Would also have the nice side advantage to keep the mirror growth back
> a little. As long as it takes for the rest to gain another 23GB :) )
>
> > In addition, we're looking to understand what is required from the
> > porter side to make this happen. The shortlist I've come up with is:
> > - buildd systems/maintenance (I'd volunteer for this)
> > - general port-specific bug triage/fixing
> > - installer testing/fixing
>
> > What other tasks would be involved?
>
> Porter machines. They need to be available and maintained. Either by DSA
> if stuff stays in main archive, or by whoever, if it goes to ports.
> If we end up with just squeeze-hppa and have no hppa in unstable, a one
> box should do that, if it stays in unstable too, 2 or 3...
Yeah, we have paer for that. (It is currently down due to what appears
to be a failed disk, but that should get resolved this week).
If this moved to ports, I'm curious what the maintenance tasks are. Is
there a central admin team and/or infrastructure for ports?
Also - does debian-ports allow for non-DDs to do any tasks that DD
privs are generally required for (signing build logs, uploading
installer images, etc)? The active hppa porter team is non-DD-heavy,
and it would be nice to share the load.
> Security. Should we do squeeze-hppa I assume you want some way of
> security support. I don't guess the security team itself will do it
> (well, ask them), but in some way you do want to fixup things for the
> users. Well, ok, i guess they can do it, as a "sub-par" arch
> thing. Like, whenever the build is there for hppa, its released together
> with the rest, if it appears later, it just gets provided to the users
> without an extra DSA. Or so. Check with them.
*nod*. I should be able to handle hppa-specific things from a
security team POV as long as the infrastructure exists (though I'd
seek buy-in from the team before signing up for it).
> Or, if they dont want this, you would need some way to do it in
> squeeze-hppa.
>
> Point releases. *Somehow* this also needs to be done/synced. etch-m68k
> fell out of that at some point, but somehow thats bad. They just build
> the packages and uploaded whenever, IIRC.
yeah, I seem to remember that as well. thanks for the info.
Reply to: