[alsa-devel] alsa-compile.sh - easy testing of latest ALSA code
Hi all,
I'm instroducing a new bash script - alsa-compile.sh - to allow easy testing of new ALSA code by all users using standard Linux desktop distributions. For example to get latest driver snapshot from www.alsa-project.org, compile it and insert new kernel modules, just type:
wget -O alsa-compile.sh http://www.alsa-project.org/alsa-compile.sh chmod 755 alsa-compile.sh ./alsa-compile.sh --driver --kmodules
More information are available using --help option. More examples are available using --examples option.
Actually, Fedora and openSUSE distributions are supported. Please, send patches extending functionality for other distributions to this list or directly to me.
Takashi, you might want to add support (option) for your driver tarballs. It would be probably a good idea to create a link to latest tarball in your web directory.
Please, send ideas, bugs, patches and any other issues to this list.
Thanks, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Mon, 22 Feb 2010 17:37:29 +0100 (CET), Jaroslav Kysela wrote:
Hi all,
I'm instroducing a new bash script - alsa-compile.sh - to allow easy testing of new ALSA code by all users using standard Linux desktop distributions. For example to get latest driver snapshot from www.alsa-project.org, compile it and insert new kernel modules, just type:
wget -O alsa-compile.sh http://www.alsa-project.org/alsa-compile.sh chmod 755 alsa-compile.sh ./alsa-compile.sh --driver --kmodules
More information are available using --help option. More examples are available using --examples option.
Actually, Fedora and openSUSE distributions are supported. Please, send patches extending functionality for other distributions to this list or directly to me.
Takashi, you might want to add support (option) for your driver tarballs. It would be probably a good idea to create a link to latest tarball in your web directory.
Please, send ideas, bugs, patches and any other issues to this list.
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
I find this a good move in general. But, wouldn't it be better to cooperate with the existing packaging? For example, for openSUSE, there is already the snapshot RPM for each user-space stuff and the alsa-driver update KMP for all maintained distro versions on OBS. User can install the up-to-date packages simply via zypper without compiling.
OTOH, if the purpose is to make easier to install from the source tree, then we can give a spec or deb file, or a script to set up such files so that user can kick off the packager to have the installation-ready test package.
thanks,
Takashi
On Tue, 23 Feb 2010, Takashi Iwai wrote:
At Mon, 22 Feb 2010 17:37:29 +0100 (CET), Jaroslav Kysela wrote:
Hi all,
I'm instroducing a new bash script - alsa-compile.sh - to allow easy testing of new ALSA code by all users using standard Linux desktop distributions. For example to get latest driver snapshot from www.alsa-project.org, compile it and insert new kernel modules, just type:
wget -O alsa-compile.sh http://www.alsa-project.org/alsa-compile.sh chmod 755 alsa-compile.sh ./alsa-compile.sh --driver --kmodules
More information are available using --help option. More examples are available using --examples option.
Actually, Fedora and openSUSE distributions are supported. Please, send patches extending functionality for other distributions to this list or directly to me.
Takashi, you might want to add support (option) for your driver tarballs. It would be probably a good idea to create a link to latest tarball in your web directory.
Please, send ideas, bugs, patches and any other issues to this list.
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
The script just call 'make install-modules' in the alsa-driver package. Anyway, overwriting kernel modules is just a workaround to bypass the standard packaging. I don't think that using a special directory helps.
I find this a good move in general. But, wouldn't it be better to cooperate with the existing packaging? For example, for openSUSE, there is already the snapshot RPM for each user-space stuff and the alsa-driver update KMP for all maintained distro versions on OBS. User can install the up-to-date packages simply via zypper without compiling.
You may add a new command to the script to handle latest distribution packages, something like:
alsa-compile.sh --lib --install-snapshot-package
OTOH, if the purpose is to make easier to install from the source tree, then we can give a spec or deb file, or a script to set up such files so that user can kick off the packager to have the installation-ready test package.
The purpose of this script is primary to compile and test latest sources. Installation is not the primary goal - many distributions uses own modifications and users can push package maintainers to upgrade the official distribution packages.
The idea is to have an independant script which allows users to test the latest ALSA code without the knowledge of the packaging and other distribution internals. We can do more interactive development using it with almost all users. I am going to add --patch option to apply test patches and do 'dmesg' output (for the driver package) which can be sent back to the developer working on a given issue.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 23 Feb 2010, Takashi Iwai wrote:
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
The script just call 'make install-modules' in the alsa-driver package. Anyway, overwriting kernel modules is just a workaround to bypass the standard packaging. I don't think that using a special directory helps.
I think it helps:
Building drivers from source I usually configure --with-moddir=updates/alsa
This means * The newly generated modules do not overwrite the distro supplied ones. * I can easily revert to the distro ones by deleting updates/alsa (my updates directory also has a dkms subdirectory) and rerunning depmod
-- Eliot
At Wed, 24 Feb 2010 09:47:35 +1300, Eliot Blennerhassett wrote:
Jaroslav Kysela wrote:
On Tue, 23 Feb 2010, Takashi Iwai wrote:
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
The script just call 'make install-modules' in the alsa-driver package. Anyway, overwriting kernel modules is just a workaround to bypass the standard packaging. I don't think that using a special directory helps.
I think it helps:
Building drivers from source I usually configure --with-moddir=updates/alsa
This means
- The newly generated modules do not overwrite the distro supplied ones.
- I can easily revert to the distro ones by deleting updates/alsa (my
updates directory also has a dkms subdirectory) and rerunning depmod
Right. With the updates directory, you can keep the original modules intact. This is the biggest difference from the default behavior. Also, it makes easier to have a clean re-update. Clean the whole updates directory, then install there again.
Takashi
On Wed, 24 Feb 2010, Eliot Blennerhassett wrote:
Jaroslav Kysela wrote:
On Tue, 23 Feb 2010, Takashi Iwai wrote:
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
The script just call 'make install-modules' in the alsa-driver package. Anyway, overwriting kernel modules is just a workaround to bypass the standard packaging. I don't think that using a special directory helps.
I think it helps:
Building drivers from source I usually configure --with-moddir=updates/alsa
This means
- The newly generated modules do not overwrite the distro supplied ones.
- I can easily revert to the distro ones by deleting updates/alsa (my
updates directory also has a dkms subdirectory) and rerunning depmod
OK. I got the point. It's fixed in the current alsa-compile.sh script. Also, the --kmodclean option was added to remove ALSA kernel modules in this location.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 23 Feb 2010, Takashi Iwai wrote:
Just one point I noticed quickly is that the standard directory for update modules is either /lib/modules/$VERSION/updates or /lib/modules/$VERSION/extras. We should follow that.
The script just call 'make install-modules' in the alsa-driver package. Anyway, overwriting kernel modules is just a workaround to bypass the standard packaging. I don't think that using a special directory helps.
I think it helps:
Building drivers from source I usually configure --with-moddir=updates/alsa
This means * The newly generated modules do not overwrite the distro supplied ones. * I can easily revert to the distro ones by deleting updates/alsa (my updates directory also has a dkms subdirectory) and rerunning depmod
-- Eliot
participants (4)
-
Eliot Blennerhassett -
Eliot Blennerhassett -
Jaroslav Kysela -
Takashi Iwai