Assembly environment for the Midnight Commander project

Published on September 22, 2011

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:
  1. assembly of a package from the GIT project Midnight Commander;
  2. checking the availability of a new release;
  3. updating the local repository;
  4. 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).
Assembly takes place through pbuilder to ensure assembly in a minimal environment.

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 -