Assembly environment for the Midnight Commander project
Continued
Few people familiar with the words linux * bsd do not know about Midnight Commander. I’m not too mistaken if I say that everyone first used it. A great tool for the tasks that it solves, moreover, available on many platforms. Recently, a project previously developed under the wing of gnome.org, received a second life. The new project site is pleased with the pace of development. Here are just a support for current versions of packages in distributions limping.
The last thing that is available in Debian is 4.7.0.9, and this is despite the fact that recently released 4.7.5.4 which has a number of goodies. The project provided binary assemblies for RedHat-based systems and did not support those for Debian / Ubuntu. I decided to fill this gap by running an automated build environment.
In the process of preparing and launching the assembly environment , it became necessary to automate some of the operations:
Included in the basic functionality of the assembly environment. Actually, everything was started for assembly into the packages of the latest changes with the aim of testing them. At startup, it checks to see if there have been changes to the repository since the last successful package build. If they are not there, then the assembly stops.
If changes are found, then a test is run for the ability to compile and install correctly. To do this:
If the previous step was completed without errors, then source packaging begins. When executing “make dist”, an archive of the form mc- <version> .tar.gz is created, which is further reduced to the form mc_ <version> ~ git <YYYYMMDD> .orig.tar.gz. Next, the resulting archive is unpacked, debian-specific parts are added to it, the package version is incremented and the build process is started.
If the package build is successful, then the Debian Policy compliance check begins. First, the package is checked in lintian (the output is saved in a separate file for quick error analysis), then in piuparts. If the package passes the checks successfully, the assembly for the target platforms begins.
Apt-ftparchive is used to manage the local repository. After starting the upgrade procedure, the latest build versions are obtained from the build environment. Service information is updated and Release files are signed. To sign files in automatic mode, I had to generate a subkey for an existing one and entrust it to gpg-agent.
This solves the problem of key leakage, which is used to sign packages - you can create a revocation key and update the main key on the servers. However, the primary secret key is not present on the build environment server.
To upload changes to the local repository, rsync was used on the server. I did not create a key without a password for rsync ssh, but made it accessible through ssh-agent. If necessary, this will allow you to lock the key with one command.
To keep abreast of the release of new stable versions, we configured uscan, which, when launched with the --report switch, checks for the availability of new versions at www.midnight-commander.org/download while skipping versions of the form XXX-preY. If there is a positive response from uscan, the release build starts, which eventually ends up in the main branch of my repository.
APT settings for stable versions:
APT settings for nightly builds:
So that the version from the nightly builds does not replace the stable release, you need to register it in / etc / apt / preferences
UPD1: To prevent APT from swearing about the impossibility of verifying the key, you need to import my public key before using the repository (at the same time, the subkey that I use to sign the packages will come). For example, like this:
or
Few people familiar with the words linux * bsd do not know about Midnight Commander. I’m not too mistaken if I say that everyone first used it. A great tool for the tasks that it solves, moreover, available on many platforms. Recently, a project previously developed under the wing of gnome.org, received a second life. The new project site is pleased with the pace of development. Here are just a support for current versions of packages in distributions limping.
The last thing that is available in Debian is 4.7.0.9, and this is despite the fact that recently released 4.7.5.4 which has a number of goodies. The project provided binary assemblies for RedHat-based systems and did not support those for Debian / Ubuntu. I decided to fill this gap by running an automated build environment.
In the process of preparing and launching the assembly environment , it became necessary to automate some of the operations:
- assembly of a package from the GIT project Midnight Commander;
- checking the availability of a new release;
- updating the local repository;
- server repository update.
Build a package from GIT
Included in the basic functionality of the assembly environment. Actually, everything was started for assembly into the packages of the latest changes with the aim of testing them. At startup, it checks to see if there have been changes to the repository since the last successful package build. If they are not there, then the assembly stops.
If changes are found, then a test is run for the ability to compile and install correctly. To do this:
./autogen.sh
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/mc
make dist
make
make install DESTDIR=/tmp/mc
If the previous step was completed without errors, then source packaging begins. When executing “make dist”, an archive of the form mc- <version> .tar.gz is created, which is further reduced to the form mc_ <version> ~ git <YYYYMMDD> .orig.tar.gz. Next, the resulting archive is unpacked, debian-specific parts are added to it, the package version is incremented and the build process is started.
If the package build is successful, then the Debian Policy compliance check begins. First, the package is checked in lintian (the output is saved in a separate file for quick error analysis), then in piuparts. If the package passes the checks successfully, the assembly for the target platforms begins.
- Debian Lenny / Squeeze (i386, amd64);
- Ubuntu Maverick / Natty (i386, amd64).
Updating the local repository
Apt-ftparchive is used to manage the local repository. After starting the upgrade procedure, the latest build versions are obtained from the build environment. Service information is updated and Release files are signed. To sign files in automatic mode, I had to generate a subkey for an existing one and entrust it to gpg-agent.
This solves the problem of key leakage, which is used to sign packages - you can create a revocation key and update the main key on the servers. However, the primary secret key is not present on the build environment server.
Server Repository Update
To upload changes to the local repository, rsync was used on the server. I did not create a key without a password for rsync ssh, but made it accessible through ssh-agent. If necessary, this will allow you to lock the key with one command.
Checking the availability of a new release
To keep abreast of the release of new stable versions, we configured uscan, which, when launched with the --report switch, checks for the availability of new versions at www.midnight-commander.org/download while skipping versions of the form XXX-preY. If there is a positive response from uscan, the release build starts, which eventually ends up in the main branch of my repository.
In the end
APT settings for stable versions:
deb http://www.tataranovich.com/debian lenny main deb http://www.tataranovich.com/debian squeeze main deb http://www.tataranovich.com/debian maverick main deb http://www.tataranovich.com/debian natty main
APT settings for nightly builds:
deb http://www.tataranovich.com/debian lenny nightly deb http://www.tataranovich.com/debian squeeze nightly deb http://www.tataranovich.com/debian maverick nightly deb http://www.tataranovich.com/debian natty nightly
So that the version from the nightly builds does not replace the stable release, you need to register it in / etc / apt / preferences
Package: * Pin: release c = nightly Pin: origin www.tataranovich.com Pin Priority: -1
UPD1: To prevent APT from swearing about the impossibility of verifying the key, you need to import my public key before using the repository (at the same time, the subkey that I use to sign the packages will come). For example, like this:
gpg --keyserver pgp.mit.edu --recv-keys 0x2EE7EF82
gpg --export 0x2EE7EF82 | sudo apt-key add -
or
wget -q -O- http://www.tataranovich.com/tataranovich.asc | sudo apt-key add -