[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hppa & squeeze



Hi,

On Mon, Jan 17, 2011 at 10:36:01AM -0700, dann frazier wrote:
> 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.

Yes, debian-ports.org is primarily targeted at new ports, that's why we
only have unstable, unreleased and experimental. It's probably possible
to add a stable suite provided that we use the sources from the
official debian mirrors, though we haven't tested that yet. Also we
don't support migrations between suites. 

> > (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 :) )

Unfortunately we currently don't have such space on debian-ports.
Genesis has been kind to offer new hard-drives when we added armhf, but
one of the two hard-drives is not working for an unknown reason. Someone
has to go there to see that more in details, and maybe buy a new
hard-drive. It's currently not on my short term planning, I am waiting 
for another reason to go to Paris and go there at the same time. In the 
meanwhile we are running on low disk space.

An alternative would be to "swap" hppa with another port, sh4 for
example.

> > > 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?

I am currently the one doing most of the job there. I would be quite
happy if someone helps.

> 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.

We allow non-DDs to have an account there, and do the job. Note by the
way that we have no infrastructure for debian installer images, other
than a directory where we put the images manually. Same for CD images.

> > 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).

We don't have security support debian-ports, but it can probably be
handle by just uploading the security packages directly to stable.

> > 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.
> 

For that we can probably add the stable sources to wanna-build, so that
new packages are build and uploaded automatically.

Cheers,
Aurelien

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: