DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=hXJOHGvYGotK50bF3RI84io2og5TveCmBcexWoxCwrB0Sglmjqcy4KebYwRte58LAU
         e4i79YM1e9Rxkisl29uzvko9nK4KFbtUuYd1AiEmWO9JgCRi/BFpGcxjdWR9zLbZ+Skk
         2k8ztEN4bL5AcWwhKpr1KH5KNE8SnMhNHIRyE=
Precedence: list
MIME-Version: 1.0
In-Reply-To: <20110225092433.05e1a98c@alpinelinux.org>
References: <4D66E7BB.1060908@anselsystems.com>
	<20110225092433.05e1a98c@alpinelinux.org>
Date: Sun, 22 May 2011 17:36:34 -0400
Message-ID: <BANLkTimP4R3fKsVZFG4XeB8MpDGrT99CJQ@mail.gmail.com>
Subject: Re: [alpine-devel] Distfiles mirror
From: Jeff Bilyk <jbilyk@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>, Andrew Manison <amanison@anselsystems.com>
Cc: Alpine Development <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 25, 2011 at 4:24 AM, Natanael Copa <ncopa@alpinelinux.org> wrot=
e:
> 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.

Alpine-build@lists.alpinelinux.org 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 (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: =A0alpine-devel+unsubscribe@lists.alpinelinux.org
> Help: =A0 =A0 =A0 =A0 alpine-devel+help@lists.alpinelinux.org
> ---
>
>



--=20
Jeff


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---