alsa-compile.sh - easy testing of latest ALSA code

alsa-compile.sh - easy testing of latest ALSA code

[Jaroslav Kysela]

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.

Re: alsa-compile.sh - easy testing of latest ALSA code

[Takashi Iwai]

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

Re: alsa-compile.sh - easy testing of latest ALSA code

[Jaroslav Kysela]

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.

Re: alsa-compile.sh - easy testing of latest ALSA code

[Eliot Blennerhassett]

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

Re: alsa-compile.sh - easy testing of latest ALSA code

[Takashi Iwai]

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

Re: alsa-compile.sh - easy testing of latest ALSA code

[Jaroslav Kysela]

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.

Re: alsa-compile.sh - easy testing of latest ALSA code

[Eliot Blennerhassett]

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