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

Re: Bits from ARM porters


On Tue, Dec 03, 2013 at 12:43:36AM +0100, Hector Oron wrote:
> 5.2 Setup arm64 debian-ports
> ────────────────────────────
>   ⁃ arm64 setup as new bootstrapping port
>   ⁃ manual builds could be uploaded but possible lack of space
>   ⁃ 9 more packages needed for a minimal bootstrap

I have been contacted by Wookey earlier this year about adding arm64
port to debian-ports, and everything is now ready. I am still waiting
for the buildds email addresses and ssh key though.

It is already possible to upload packages, as space is not an issue on
debian-ports since we moved to the machine offered by DSA. That said
adding a new architecture is a problem (I had to add mips64el on the
waiting list recently), as we are lacking CPU and disk I/O. Remember we
have about 2/3 of the architectures in the official Debian archive, on
a single virtual machine.

> [...]

> 7 Debian-Ports integration in Debian
> ════════════════════════════════════

I find strange that it has been discussed and actions have been taken
during an ARM bof, without having been contacted. Anyway let's see the
various points:

>   debian-ports needs a user mailing list.

That could be a good idea. Note however that there is currently a
buildd-maintainers@debian-ports.org contacting the buildd maintainers of
all architectures there.

>   Which mailing list should be used for debian-ports discussion?

I am opened to suggestions that do not involve the debian-ports machine,
as the goal is to reduce the things hosted there.

> 7.1 Hand machine over to DSA
> ────────────────────────────
>   All that needs to be done to handover machine to DSA:
>   ⁃ Identify services running on d-ports
>   ⁃ Transfer services to DSA machine
>   ⁃ Transfer domain names to DSA

As already said earlier, I am fine doing that as long as we do not loose
features or contributors. What is clearly missing in the list above, is 
the manpower to do the transfer and the maintenance once the transfer is
done (unless DSA is planning to do the full administration, including 
wanna-build, archive, ...).

Here is the list of services:
- mini-dak for running the archive
- FTP server for uploading packages and serving the archive and CD images
- web server for serving the archive and CD images
- wanna-build
- postgresql for wanna-build
- web server for wanna-build frontend (pgstatus)
- mail server + wbpy to store the build logs
- rsync server for serving the archive, currently restricted to mirrors
  due to I/O issues
- git server and web server for the code and data used on debian-ports
- script to create an incoming directory
- script for transitions tracking (ben)
- POP3S server for buildds behind NAT
- DNS server for debian-ports.org
- web server for the public website
- IPv6: not really a service, but used for buildds without public IPv4

> 7.2 Enable unreleased suite handling in archive tools
> ─────────────────────────────────────────────────────
>   Aparently, keeping separated archive for debian-ports would be good,
>   so we can still have waky-hacks in -ports, while do clean bootstrap in
>   Debian archives.

The unreleased suite is a very important feature that should not be
lost, unless we allow porters to NMU packages in a short timeframe and
even during freeze. Another feature of the archive is to be able to
upload packages versions newer than the current one, but older than in 
the sources. This allow things to progress even if the current package
in unstable is broken and the maintainer doesn't cares about ports.

People proposed to add theses features to dak, but nobody actually did
the job so far.

> 7.3 Merge wanna-build DB into official one
> ──────────────────────────────────────────
>   ⁃ We want to be able to keep same architecture in both Debian and
>     Debian-ports (Note: Debian-ports packages carry scary hacks, and
>     Debian bootstrap should start from clean start)

Note that we are running the same software than in Debian, even if it
is sometimes lagging a bit. Thanks to Philip Kern for his work on that.

Remember that it means wanna-build should look for unreleased. Also
remember it means that non-DD should be able to access wanna-build. If
possible the same persons should also have a shell with access to the
packages files and wanna-build to be able to handle transitions and
schedule NMUs, like the release team is doing.

> 7.4 Enable non-DD uploaders for d-ports
> ───────────────────────────────────────
>   ⁃ Recognise porting work in the NM process independently of whether
>     individual packages are listed as being maintained by that
>     person. Needs some tools or existing tools adapting to ports
>     structure.

I don't really see the point, as it is already the case. Actually most
of the uploaders in debian-ports are non-DD, and it is something that
should not be lost in the transfer either. 


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

Attachment: signature.asc
Description: Digital signature

Reply to: