Subject: [alpine-devel] Alpine 2.2

From: Natanael Copa <[email-masked]>
Date: Wed, 10 Nov 2010 11:09:10 +0100

Hi,

So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
some of the things I would like to do for the 2.2 release, scheduled to
May 2011.

* x86_64 alpine port
* java support (openjdk)
* Go Lang support
* llvm/clang support (maybe we can base alpine-3 completely on clang)
* improve admin tools, setup-alpine, ACF, unattended installer etc
* apk-tools: "install_if" (or "conditional groups")
* lua binding to apk-tools
* improve abuild (move dependency handling to lua code, build in empty
chroot)
* support for cross compiling in abuild?
* autobuilding of edge snapshot iso images
* improve testing / quality assurance
* python3?
* new version of uclibc, linux kernel, and lots of other new apps
* Qt support
* GNOME?

Anything else?

If there are some of the above (or something else) you would like to
work on, please fell free to let me know. I have various of the above
stuff partially done already.

If you have some ideas please feel free to send feedback. I'm specially
interested in ideas what we can do to improve the admin tools,
setup-alpine, setup-disk and quality assurance.

Thanks!

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Jeff Bilyk <[email-masked]>
Date: Wed, 17 Nov 2010 22:08:45 -0500

Re: testing and QA, I took a look at APTS (thanks to ncopa pointing it
out...).  Taking the initial idea but simplifying a bit, I figured
taking the following approach might work:

Take the .mk files from svn://svn.alpinelinux.org/apts, strip the
first line and sed apk_delete for apk_del.
Run the following script (a gutted version of run-tests from APTS):
----------
#!/bin/sh -e

# Get file to output to
OUTFILE="$@"
if [ -z "$OUTFILE" ];
 then echo "Usage: $0 outfile" && exit 0;
fi

# Clear file if text
echo "" > $OUTFILE

# Add package, run basic test then remove package
for package in `ls ./packages`;
do sh -e ./packages/$package >> $OUTFILE 2>&1 && echo "$package passed
tests" >> $OUTFILE;
done
----------

A sample of a .mk file that's in SVN that we could adapt: sed.mk:

----------
sed:
	apk_add $@
	echo "hello" | sed 's/hello/world/g' | grep 'world'
	apk_delete $@
	[ `readlink /bin/sed` = /bin/busybox ]
----------

The output can be redirected and parsed (or maybe just take stderr?)
so that once edge ISOs are autobuilt, they can have some basic tests
done on most packages (or just the important ones?).  Assuming the ISO
passes this basic QA upload the ISO to the mirrors.  If it fails, add
the output from the script to sircbot's output on alpine-devel so that
the package can be fixed.

Thoughts?

Jeff

-- 
Jeff

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 24 Nov 2010 10:00:08 +0100

sorry for late reply.

> Run the following script (a gutted version of run-tests from APTS):

sounds good. But i think we should split the testing in 2 parts:
1. testing packages
2. testing iso images

Packages needs to be tested before the releases. We should test the
packages while they are in edge. (and we should make edge snapshots)

I also think that we should try make some regression tests. For example,
when we upgraded kamailio to 3.1 there was a problem with config files
ending up in /usr. I didnt detect that since kamailio started just fine
anyways. So we could have a test that verifies that config is in correct
place.

Ideally, when there is a problem with a package, we should make a test
script that triggers the error so we can make sure the same problem
never comes back again.

When it comes to testing iso images, I think some (half)automated way to
test the installer would be good, verify that lbu commit works, verify
that encrypted apkovls work etc. Edge snapshots should be tested too.

Now, we need to start some place, so I think what you do is good.

-nc

---

---

From: Nathan Angelacos <[email-masked]>
Date: Thu, 11 Nov 2010 10:32:30 +0000

On Wed, 10 Nov 2010 11:09:10 +0100

> * improve admin tools, setup-alpine, ACF, unattended installer etc

From http://www.linuxbsdos.com/2010/08/23/alpine-linux-2-review/

Like a default installation of Alpine Linux, the Browser-based
management interface is very basic, lacking features needed to
configure aspects of some of the services and applications. Most of
what you will accomplish on Alpine will be from the command line
(console or remote access via ssh).
...

If you are a power user, or want to be one, the browser-based
management interface, while intuitive to use, will be a secondary
management tool. Most of the serious stuff you will be doing will be
from the command line.

ACF is now several years old, and still described as "Basic". 

There are two basic types of ACFs:

Configuration (setting up networking, dnsmasq, etc)
Application (OpenSSL Certificate Authority)

Personally, like the author of the review, I use ssh for
configuration. But but use ACF for the applications. 

I wonder if we go for a "less is more" approach on ACF, and provide the
something like the current "Expert" tab for all configuration.
Basically, give a web interface to the config files.

And then focus on ACF Applications (e.g. setup-alpine, setup-disk)

---

---

From: Cameron Banta <[email-masked]>
Date: Wed, 10 Nov 2010 08:19:25 -0600

> * new version of uclibc, linux kernel, and lots of other new apps

Are there any thoughts on whether or not we need a tool to choose 
default versions? For example, if we were to maintain and both Python2.6 
and Python3, it would be nice to be able to choose which one is the 
default.

We could probably port eselect or update-alternatives.

Or, to keep it simple, do we just support one version, or only allow one 
of those packages to be installed at one time?

> setup-alpine, setup-disk and quality assurance.

-Cameron

---

---

From: Harry Lachanas <[email-masked]>
Date: Thu, 11 Nov 2010 11:12:53 +0200

> some of the things I would like to do for the 2.2 release, scheduled to
I suppose that there will be also an x86_32 version of them all right?

Regards
Harry

---

From: Natanael Copa <[email-masked]>
Date: Thu, 11 Nov 2010 13:49:13 +0100

> I suppose that there will be also an x86_32 version of them all right?

we will not stop pushing out 32 bit releases.

-nc

---