Mail archive

Re: [alpine-devel] Distfiles mirror

From: Jeff Bilyk <>
Date: Sun, 22 May 2011 17:36:34 -0400

On Fri, Feb 25, 2011 at 4:24 AM, Natanael Copa <> wrote:
> On Thu, 24 Feb 2011 18:20:27 -0500
> Andrew Manison <> 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. is now set up if that's a direction
that we would want to take. Same subscription process as with the
other lists. Since there seems to be small bursts of traffic, i'd
suggest that we start using a 2nd list for the build reports, and have
anyone who has git commit access or has contributed to packages
subscribe to the list.

>> Many of the failures are due to missing source archives. At
>> present, the distfiles mirror (
>> 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:
> Help:
> ---

Received on Sun May 22 2011 - 17:36:34 UTC