Midnight Commander build environment - continued
Start
In the first part, I introduced the new binary package building service for the Midnight Commander file manager for Debian / Ubuntu. The comments rightly pointed out the lack of a technical description of the medium itself, and I promised that I would lay out the details as soon as the code was brought into a divine form. Two weeks passed, a little time appeared to stabilize the functionality and brush the code (it is still terrible, but it seems to work as intended), so it's time to fulfill the promise.
I don't specifically include source codes in the topic, there are a lot of them, and in my opinion the article is overloaded. Who cares , can download them with googlecode .
')
The build environment consists of several shell scripts:
As I mentioned earlier, this is the most important part of the build environment. Performs two types of operations: build / reassemble releases and build night slices from GIT. If the release build was chosen, then the script:
Building the night slice differs only in that the sources are generated from the GIT repository and the incrementing code is different. If the script detects that there were no changes in the master branch of the repository, the assembly is interrupted.
This script calls build-mc-from-git.sh and in case of successful completion it does an additional check of the binary package in piuparts and if there are no errors, it starts the process of building the targets (squeeze-i386, squeeze-amd64, natty-i386, etc. .). After each successful build, the repository temporary structure is updated. If all the targets are collected successfully and buildbot.sh was called by one of the CRON tasks (mc-release-builds.sh or mc-nightly-builds.sh), then the update script of my repository is launched. At this point, the APT service information is updated, the Release files are signed, and the server copy is updated.
Now the full cycle of assembling 8 targets takes a little over an hour. In the future, I will probably expand the targates on rpm-based distros (as far as I understand, upstream has not restored the normal operation of the previous buildbot). Additional info or support is available on the project page .
In the first part, I introduced the new binary package building service for the Midnight Commander file manager for Debian / Ubuntu. The comments rightly pointed out the lack of a technical description of the medium itself, and I promised that I would lay out the details as soon as the code was brought into a divine form. Two weeks passed, a little time appeared to stabilize the functionality and brush the code (it is still terrible, but it seems to work as intended), so it's time to fulfill the promise.
I don't specifically include source codes in the topic, there are a lot of them, and in my opinion the article is overloaded. Who cares , can download them with googlecode .
')
Assembly environment
The build environment consists of several shell scripts:
- contrib / mc-release-builds.sh is a script that runs as a CRON task and manages the assembly of new releases, or reassembly of already released ones.
- contrib / mc-nightly-builds.sh is a script that is also a CRON task and builds night slices.
- contrib / prepare-environment.sh - a script that initializes environment variables specific to my server (in particular, environment variables are exported for SSH and GPG agents)
- The contrib / local-repo-update script, with which I update my repository, is now thinking of abandoning apt-ftparchive and trying reprepro.
- contrib / pbuilder - configs for assembly purposes, one of them (contrib / pbuilder / buildbot) is used to prepare a package from source or GIT.
- contrib / apt-ftparchive - my settings for running apt-ftparchive (maybe someone will come in handy)
Next come the scripts that make up the build environment itself:
- build-mc-from-git.sh - build a package from source or VCS (system kernel)
- buildbot.sh is a wrapper over the previous script, which is an intermediate link between the crown tasks, the user and the kernel of the build environment.
- initial-build.sh is an anachronism that has remained due to my natural laziness. Adds a separate buildbot user to the pbuilder (buildbot) build target.
build-mc-from-git.sh
As I mentioned earlier, this is the most important part of the build environment. Performs two types of operations: build / reassemble releases and build night slices from GIT. If the release build was chosen, then the script:
- updates the local copy of the contrib / debian / directory from the repository, which is required to build the package (dh_make is not used when building the package)
- unpacks the archive with the source code, which is passed to the script as one of the arguments by the parent scripts or the user.
- checks if the source is going out of the box. To do this, in the directory with unpacked sources, a familiar sequence of actions is performed:
[ -x ./autogen.sh ] && ./autogen.sh ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/mc make make install DESTDIR=/tmp/install
If this stage passes without errors, then further problems with building the package indicate the need to revise the debian-specific part of the package (contrib / debian / directory in VCS) - copies the debian / directory to the sources from the local VCS copy, checks if there is a local changelog for the source version (if a new revision of the package is being assembled, not a new release) and if it exists, then the changelog from the VCS is replaced with the local one.
- izrementiruet version and / or revision number and starts building the package through the call dpkg-buildpackage -rfakeroot -us -uc
- checks lintian package for compliance with Debian policy. The lintian output is saved to a separate file. (recently helped to catch an error in the man pages of nightly builds and send a patch to the upstream)
Building the night slice differs only in that the sources are generated from the GIT repository and the incrementing code is different. If the script detects that there were no changes in the master branch of the repository, the assembly is interrupted.
buildbot.sh
This script calls build-mc-from-git.sh and in case of successful completion it does an additional check of the binary package in piuparts and if there are no errors, it starts the process of building the targets (squeeze-i386, squeeze-amd64, natty-i386, etc. .). After each successful build, the repository temporary structure is updated. If all the targets are collected successfully and buildbot.sh was called by one of the CRON tasks (mc-release-builds.sh or mc-nightly-builds.sh), then the update script of my repository is launched. At this point, the APT service information is updated, the Release files are signed, and the server copy is updated.
Now the full cycle of assembling 8 targets takes a little over an hour. In the future, I will probably expand the targates on rpm-based distros (as far as I understand, upstream has not restored the normal operation of the previous buildbot). Additional info or support is available on the project page .
Source: https://habr.com/ru/post/129989/
All Articles