Hi,
I have been rebuilding world for our new aarch64 architecture. While main
and community repositories are in good shape, testing really is not.
We currently have 1832 aports in testing of which 437 fail to build:
http://tpaste.us/GVV8
I would like to purge packages from testing that have not had any update
since x days, this will reduce the list of failed packages, and will make
it easier to get testing in building shape again.
As an example you can find a list of not updated packages since 1 jan 2016
here: http://tpaste.us/36aa
We should determine what the best possible TTL is for packages in testing.
It should be long enough so developers get a chance to get their packages
fixed upstream and short enough to prevent the mess we currently have.
My suggestion would be something between 6 and 12 months, but i'm open to
ideas. And please remember testing is not a copy of AUR, our developers
should no be responsible for other peoples mess in testing.
To keep testing healthy we can purge them every time we create a new
release branch, this is also a good time for developers to check testing
and get things moved to community if they want to keep it.
-carlo
On Wed, 17 Aug 2016 12:47:43 +0200
Carlo Landmeter <clandmeter@gmail.com> wrote:
> We should determine what the best possible TTL is for packages in testing.> It should be long enough so developers get a chance to get their packages> fixed upstream and short enough to prevent the mess we currently have.> My suggestion would be something between 6 and 12 months, but i'm open to> ideas.
I wouldn't mind if try keep it short.
> And please remember testing is not a copy of AUR, our developers> should no be responsible for other peoples mess in testing.
Yes. The idea with testing was originally to test that the package
built on the build server environment and not only on the developers'.
Also, sometimes we build packages that we don't use ourselves, so we
needed a way for the requester to test that the package actually works
before we moved it to the repository.
Unfortunately we often never get any feedback on the packages requested
so we don't know if it actually works or not, and the packaged ends up
in testing forever.
> To keep testing healthy we can purge them every time we create a new> release branch, this is also a good time for developers to check testing> and get things moved to community if they want to keep it.
Agree. I think we also did a cleanup when we branched 3.4-stable. We
might need to start cleaning it more often.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 17 August 2016 at 12:47, Carlo Landmeter <clandmeter@gmail.com> wrote:
> Hi,>> I have been rebuilding world for our new aarch64 architecture. While main> and community repositories are in good shape, testing really is not.> We currently have 1832 aports in testing of which 437 fail to build:> http://tpaste.us/GVV8>
I'm sorry to report that the list of failed packages up to
enlightenment/src can be incorrect. this happens because
"abuild sourcecheck" is somehow defective and I have tried to trial run
"abuild checksum" to verify its behavior.
Please also keep in mind this list is generated by our new aarch64 builder,
so the result on any other arch can be different.
-carlo
On 2016-08-18 03:02, Natanael Copa wrote:
> On Wed, 17 Aug 2016 12:47:43 +0200> Carlo Landmeter <clandmeter@gmail.com> wrote:> >> We should determine what the best possible TTL is for packages in >> testing.>> It should be long enough so developers get a chance to get their >> packages>> fixed upstream and short enough to prevent the mess we currently have.>> My suggestion would be something between 6 and 12 months, but i'm open >> to>> ideas.> > I wouldn't mind if try keep it short.> >> And please remember testing is not a copy of AUR, our developers>> should no be responsible for other peoples mess in testing.> > Yes. The idea with testing was originally to test that the package> built on the build server environment and not only on the developers'.> Also, sometimes we build packages that we don't use ourselves, so we> needed a way for the requester to test that the package actually works> before we moved it to the repository.> > Unfortunately we often never get any feedback on the packages requested> so we don't know if it actually works or not, and the packaged ends up> in testing forever.
Wouldn't it help to create a dedicated list to testing?
I always feel that the current channels are not enough to give feedback
on testing.
> >> To keep testing healthy we can purge them every time we create a new>> release branch, this is also a good time for developers to check >> testing>> and get things moved to community if they want to keep it.> > Agree. I think we also did a cleanup when we branched 3.4-stable. We> might need to start cleaning it more often.> > -nc> > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> ---
-O
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 18 August 2016 at 03:02, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Wed, 17 Aug 2016 12:47:43 +0200> Carlo Landmeter <clandmeter@gmail.com> wrote:>> > We should determine what the best possible TTL is for packages in> testing.> > It should be long enough so developers get a chance to get their packages> > fixed upstream and short enough to prevent the mess we currently have.> > My suggestion would be something between 6 and 12 months, but i'm open to> > ideas.>> I wouldn't mind if try keep it short.
Ok, lets keep it 6 months for now.
A new updated list can be found here (783 aports): http://tpaste.us/G0Z8
I plan to move all these to unmaintained this weekend or early next week.
If somebody misses anything, you can move it back from unmaintained or
community if you take ownership.
-carlo
On Wed, Aug 17, 2016 at 12:47:43PM +0200, Carlo Landmeter wrote:
>>>I would like to purge packages from testing that have not had any update>since x days, this will reduce the list of failed packages, and will make>it easier to get testing in building shape again.
Perhaps there might be value in encouraging devs to test their aports
and move them to main or community by requesting that:
/aports should not be maintained in testing/
At the extreme, this could be enforced by rejecting patches to aports in
testing, such as version bumps etc. "If it works, move it to main or
community, and maintain it there."
I'm a bit worried that this might seem too harsh though.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Re: [alpine-devel] Re: Cleanup of testing repository
This script may be helpful to other maintainers.
Run as: scriptname -------> (dry run by default)
scriptname errors ----> (show any errors)
scriptname commit --------> actually move stuff
(skipping errors)
A list of package names is written to $output
------------------------------------------------------------------------
#!/bin/sh
searchstr="Your Name <you@domain.com>"
old_repo=testing
new_repo=community
output=/tmp/pkglist
list() {
grep "$searchstr" ~/aports/$old_repo/*/APKBUILD | grep "Maintainer"
| awk '{print $1}' |tr -d :# | sed 's|/APKBUILD||'
}
pkg() {
rm -f $output 2>/dev/null
for pkg in $(list); do
basename $pkg >> $output
done
cat $output
}
gitmv() {
for pkg in $(list); do
new_pkg=$(echo $pkg | sed "s|$old_repo|$new_repo|")
git mv ${TEST} $pkg $new_pkg
done
echo -e "\nCMD = git mv $TEST\n"
}
case "$1" in
pkg) pkg;;
errors) TEST="--dry-run"; gitmv | grep ^fatal;;
commit) pkg; TEST="-k"; gitmv;;
*) pkg; TEST="--dry-run"; gitmv;;
esac
------------------------------------------------------------------------
Stuart.
On 08/17/2016 10:35 PM, Carlo Landmeter wrote:
>>> On 17 August 2016 at 12:47, Carlo Landmeter <clandmeter@gmail.com> <clandmeter@gmail.com>> wrote:>> Hi,>> I have been rebuilding world for our new aarch64 architecture.> While main and community repositories are in good shape, testing> really is not.> We currently have 1832 aports in testing of which 437 fail to> build: http://tpaste.us/GVV8>>> I'm sorry to report that the list of failed packages up to> enlightenment/src can be incorrect. this happens because> "abuild sourcecheck" is somehow defective and I have tried to trial> run "abuild checksum" to verify its behavior.> Please also keep in mind this list is generated by our new aarch64> builder, so the result on any other arch can be different.>> -carlo>