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

Re: Debian Archive architecture removals



[ With my debian-ports admin hat ]

On 2015-05-04 11:48, Cyril Brulebois wrote:
> Lucas Nussbaum <lucas@debian.org> (2015-05-04):
> > I'm wondering if we could find a way to accomodate those architectures
> > in an official way, while still limiting the impact on ftpmasters and
> > other teams. I'm not entirely clear on the status of debian-ports.org,

First of all it should be noted that moving an architecture to
debian-ports, while decreasing the load on ftpmasters, increases the
load on debian-ports, so it doesn't change a lot for the project. In
practice it even increases as you need more manpower to maintain an
architecture in debian-ports than in the debian archive.

That's why we should move an architecture to debian-ports only if it
some people (DD or not) are really going to maintain it. If not we
already have snapshot.debian.org for that.


> > and of what the current downsides of using debian-ports are. Maybe it's
> > just about supporting and advertising debian-ports as Debian's official
> > way to host second-class architectures. Maybe there's more to it.
> 
> Last I heard about it, it was understaffed and infra was undersized +
> needed some changes to make it possible to grow.

The situation hasn't really changed. Currently the whole debian-ports
runs on a single machine, which is a VM kindly provided by DSA. This
means running the archive (mini-dak) with http/ftp/rsync, buildd,
cdimage and a few more services on a single machine. The machine is
therefore heavily loaded, especially I/O wise and we had to disable
rsync access except for a few mirrors working in push mode (so that we
can control when they do the sync, ie not during mini-dinstall).

On the manpower side we are also clearly understaffed, and only working
in emergency mode when something is broken. For example the wanna-build
installation is usually lacking months of commits compared to the
official one.

We tried to start addressing with a "plan" to move services to DSA
administrated machine, as it can be seen there: [1].

We started by moving easy things like DNS and website. We then continued
by moving the buildd service to a new machine called portman.d.o
mimicking as much as possible the layout of the buildd.d.o installation,
but we failed to do so in reasonable time. The main issue there is than
buildd is a HUGE PAIN to setup as it is actually composed of wanna-build
+ wbpy + pgstatus + some additional scripts. Add to that some uncommitted
code and code running in some $HOME... In addition to that it requires a
lot specific setup as root, and thus interaction with DSA. We therefore
decided to continue on that at Debconf 15 during  a more general sprint
[2]. After that we still haven't agreed on how to give access to non-DD
people to a DSA administrated machine (see below why I believe it's
important).

We have some ideas about how to handle the remaining services but no
real plan so far. Any help would be appreciated for the move, but also
for longterm administration. Of course only serious help, not just
unknown persons wanted to be root on debian-ports (yes we get this kind
of offer from time to time).


> > What
> > are the current downsides of moving hurd-i386 and sparc to debian-ports?

First of all we roughly have two kind of architectures on debian-ports:
new architectures which are there for a short time until they get
accepted as an official architecture and previously official
architectures coming there to die on the longterm. debian-ports has been
designed for the first case, where there is usually a lot of manpower.
The second case is a bit more recent and started with the removal of
official architectures from Debian.

I see the following downsides in using debian-ports for an architecture,
but they are likely a lot more:

- debian-ports uses mini-dak instead of dak. It uses less resources and
  brings some features that are useful for new architectures like
  accepting binary uploads when it "improves" the version even if it is
  not the latest one or an "unreleased" suite for packages built from
  modified source (hence architecture specific). On the contrary its
  biggest issue is that it is source package based, which means if a
  package is renamed in a transition this causes the old binary package
  to disappear and the new one to appear. This causes a lot of extra
  work for transitions.
- Build daemons are not "owned" by Debian, but have to be provided,
  hosted and administrated by individuals. It means the machine usually
  sits on DSL line behind a NAT, that's the reason why debian-ports also
  provide POP3 mailboxes (yes wanna-build partly communicates by mail).
- The above is also true for porter boxes.
- Given the above and due to the lack of manpower, more "broken time"
  than the official archive.
- Transitions are not handled by the release team.
- Bug reports concerning these architectures are more often ignored,
  even if they contain a patch.

In addition to that I would like to remind that half of the people
actually using debian-ports are non-DD, and I really believe we should
keep giving them access. This is something even more important if we 
use debian-ports to host architectures failing to get enough DD to stay
as an official architecture. alpha and, to a lesser extent, hppa are
good examples. They are in a better state now they are handled by non-DD
than when they were in the official archive.

If we want debian-ports to become an official service for SCC
architectures, we therefore have to be able to give accounts on a DSA
administrated machine to non-DD, and the same way to accept autosigning
on buildds which are not administrated by DSA and not even by a DD. We
even have to consider emulated build daemons.

Aurelien


[1] https://titanpad.com/debian-ports
[2] https://wiki.debian.org/Sprints/2015/DebCampAutobuildersSprint

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature


Reply to: