Date: Fri, 25 Feb 2011 09:24:33 +0000
From: Natanael Copa <ncopa@alpinelinux.org>
To: Andrew Manison <amanison@anselsystems.com>
Cc: Alpine Development <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Distfiles mirror
Message-ID: <20110225092433.05e1a98c@alpinelinux.org>
In-Reply-To: <4D66E7BB.1060908@anselsystems.com>
References: <4D66E7BB.1060908@anselsystems.com>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 24 Feb 2011 18:20:27 -0500
Andrew Manison <amanison@anselsystems.com> wrote:

> I have developed a script, intended
> to be run at regular intervals, which goes through the aports tree
> and builds all packages.

Nice!

> The current run has failures and the build
> logs from them are being mailed to the maintainers, as well as to the
> list. 

I wonder if we want direct those emails to a second list.

> Many of the failures are due to missing source archives. At
> present, the distfiles mirror (distfiles.alpinelinux.org/distfiles)
> is quite out of date.

Shouldn't really be out of date. The distfiles dir is shared among my
ncdev verserver and the build-* vservers. So far nothing gets deleted
from there.

> If the primary source goes offline we have no
> archived copy of it. There a two remedies to this: either make sure
> that the source tarball is on the distfiles mirror, or update the
> package to the current release. If the latter course is taken, the
> source tarball still need to find its way onto the distfiles mirror
> to preserve it for future builds.

We need archive for all git tags yes. I have an idea how to solve this
which I will come back to.

I also thik we could split the task in 2:
1. verify source URL is still valid.
2. verify that sources builds.

For checking source url I have implemented 'abuild sourcecheck' I think
we could have a separate run of sourcecheck on all packages from a cron
job.

> At one point I had the build down to just two failing packages. Now
> it's up to 30 in main and 8 in testing. I am available to work with
> the maintainers to get the builds working.

Good. Lets get those packages fixed.

> Sometimes it's a matter of 
> missing dependencies in the APKBUILD script, that don't show up
> because the packages are installed on the maintainers system.

This should be detected when the build-edge autobuilds it.

> Others
> are due to mutually exclusive packages. For example, libiconv is
> remarkably 'sticky' and once installed for a build sometimes fails to
> uninstall.

libiconv is an evil package and for that reason blacklisted in gentoo
embedded (this was one of the reason we left gentoo for building alpine)

The problem is that when some of your packages was built, libiconv was
auto detected and pulled in. Those packages shouldn't have the libiconv
dependency in the first place but once they are there the system is
messed up.

> My goal is to make it so that it is easy to setup a build server,
> point it at the git repository, and build all the packages for edge
> or a given release. I'm not there yet, but getting closer.

Ok, let us help you to get there.

> In harmony
> with Nataneal's earlier email, this would fit well with the proposed
> team structure, and provide some redundancy to the build and release
> process. This periodic total build would belong to the 'stable
> maintainers' sub-team of the developers team, while the total build
> is a useful step as part of the release process.

Or we could have a "quality assurance team" or "testing team" that does
regression testing and such.

Thanks alot!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---