The build environment for the Midnight Commander project
Continuation
Few of those familiar with the words linux, * bsd do not know about Midnight Commander. I am not too mistaken if I say that everyone used it at first. A great tool for the tasks that it solves, besides available on many platforms. Recently, a project previously developed under the wing of gnome.org has received a second life. The new project site is pleased with the pace of development. Here are just support for current versions of packages in distros lame.
The last thing that is available in Debian is 4.7.0.9, and this despite the fact that quite recently 4.7.5.4 was released in which there are a number of goodies. The project provided binary builds for RedHat-based systems and did not support those for Debian / Ubuntu. I decided to fill this gap by running the automatic build environment.
In the process of preparing and launching the build environment , it became necessary to automate some of the operations:
Included in the basic functionality of the assembly environment. Actually, everything was started up for assembling the latest changes into packages for the purpose of testing them. On startup, it checks if there have been changes in the repository since the last successful build of the package. If not, then the assembly stops.
')
If changes are found, then a test for the ability to correctly compile and run the installation is launched. To do this, run:
If the previous step is completed without errors, then the source package is started. When “make dist” is executed, 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, the debian-specific parts are added to it, the package version is incremented and the build process starts.
If the package build succeeds, 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 tests successfully, the build begins for the target platforms.
Apt-ftparchive is used to manage the local repository. After starting the update procedure, the latest builds are obtained from the build environment. Service information is updated and Release files are signed. To sign files in automatic mode, we 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 primary key on the servers. In this case, the primary secret key is missing on the server of the build environment.
To upload changes to the local repository to the server, use rsync. I did not create a key for rsync ssh without a password, but I made it available via ssh-agent. If necessary, this will block the key with one command.
To be aware of the release of new stable versions, uscan is configured, which, when launched with the --report key, checks the availability of new versions in www.midnight-commander.org/download while skipping versions of the XXX-preY type. 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 in / etc / apt / preferences
UPD1: To prevent APT from swearing at the inability to verify the key, before using the repository, you need to import my public key (at the same time it will float the subkey that I use to sign packages). For example:
or
Few of those familiar with the words linux, * bsd do not know about Midnight Commander. I am not too mistaken if I say that everyone used it at first. A great tool for the tasks that it solves, besides available on many platforms. Recently, a project previously developed under the wing of gnome.org has received a second life. The new project site is pleased with the pace of development. Here are just support for current versions of packages in distros lame.
The last thing that is available in Debian is 4.7.0.9, and this despite the fact that quite recently 4.7.5.4 was released in which there are a number of goodies. The project provided binary builds for RedHat-based systems and did not support those for Debian / Ubuntu. I decided to fill this gap by running the automatic build environment.
In the process of preparing and launching the build environment , it became necessary to automate some of the operations:
- build a package from the GIT project Midnight Commander;
- check the availability of a new release;
- update local repository;
- update server repository.
Build a package from GIT
Included in the basic functionality of the assembly environment. Actually, everything was started up for assembling the latest changes into packages for the purpose of testing them. On startup, it checks if there have been changes in the repository since the last successful build of the package. If not, then the assembly stops.
')
If changes are found, then a test for the ability to correctly compile and run the installation is launched. To do this, run:
./autogen.sh ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/mc make dist make make install DESTDIR=/tmp/mc If the previous step is completed without errors, then the source package is started. When “make dist” is executed, 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, the debian-specific parts are added to it, the package version is incremented and the build process starts.
If the package build succeeds, 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 tests successfully, the build begins for the target platforms.
- Debian Lenny / Squeeze (i386, amd64);
- Ubuntu Maverick / Natty (i386, amd64).
Local repository update
Apt-ftparchive is used to manage the local repository. After starting the update procedure, the latest builds are obtained from the build environment. Service information is updated and Release files are signed. To sign files in automatic mode, we 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 primary key on the servers. In this case, the primary secret key is missing on the server of the build environment.
Server Repository Update
To upload changes to the local repository to the server, use rsync. I did not create a key for rsync ssh without a password, but I made it available via ssh-agent. If necessary, this will block the key with one command.
Check availability of new release
To be aware of the release of new stable versions, uscan is configured, which, when launched with the --report key, checks the availability of new versions in www.midnight-commander.org/download while skipping versions of the XXX-preY type. If there is a positive response from uscan, the release build starts, which eventually ends up in the main branch of my repository.
At last
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 in / etc / apt / preferences
Package: * Pin: release c = nightly Pin: origin www.tataranovich.com Pin-Priority: -1
UPD1: To prevent APT from swearing at the inability to verify the key, before using the repository, you need to import my public key (at the same time it will float the subkey that I use to sign packages). For example:
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 - Source: https://habr.com/ru/post/128976/
All Articles