Generate a table of Osmocom CNI repositories and their latest tag,
related commit, and last commit on master.
Related: OS#3840
Change-Id: I91cab0139229e6c1c67e889d33b3d984025bc9da
Now that libosmo-dsp has a 0.4.0 tag that includes debian packaging
information, we can add it to the latest feed.
Change-Id: Ic082a4ad6b8582dfe44df5bdaafa525e52da7246
this is an ugly workaround for Jenkins not being able to deal with slash
('/') in label names that comprise the axis of a matrix buildjob, while
nuran not using tags but only branch names in their firmware
repositories :(
Change-Id: I1bbfc61f66c5fc490ceca96a8eb21210dd89b629
This way the latest script is a lot more similar to the nightly one, and
easier to maintain and expand with new features.
checkout and build steps are split because once we have a new
osmo-trx release, we'll need the create_osmo_trx_debian8_jessie trick to
build it.
In the future we can do further steps to have a common function lib
between latest and nightly scripts.
Change-Id: I786c6f4ad4b4e43d1692c1588d2ad2194d0b25a4
* replace --gitdir with --workdir and give it a new folder structure:
* git/$repo: downloaded source code
* build/$repo: files created during the build process
* install/: installation prefix
* adjust the jenkins job to use --workdir
* fetch --tags when source exists already
* readable error message for failed git checkout
Change-Id: I06589277b9d54a2af177451cfab2ca1a658b4058
Relates: OS#2642
This script verifies that Osomcom programs really build with the
dependency versions they claim to support in configure.ac. In order to
do that, it clones the dependency repositories if they don't exist
already, and checks out the minimum version tag. This happens
recursively for their dependencies as well. See 'osmo-depcheck.py -h'
for the full usage instructions.
There's also a new jenkins job in jobs/osmocom-depcheck.yml.
Change-Id: I8f495dbe030775f66ac125e60ded95c5d7660b65
Relates: OS#2642
A compatible package for debian8 as it does not support limesdr.
This patch depend on: I261302d2ed16e76540073589504e7426e23d00a1
Change-Id: I8477b580976b376ee5abdde98a651d47199ef6d9
We're using the build() function not only to build osmocom projects
requiring a .tarball-version file, but also other projects such as
libusrp. Let's make the related git-buildpackage arguments conditional
to whether or not a .tarball-version file exists at all.
Change-Id: I0683cff036a240b1b819f91fbd230d5f9211074c
We're using the build() function not only to build osmocom projects
requiring a .tarball-version file, but also other projects such as
libusrp. Let's make the related git-buildpackage arguments conditional
to whether or not a .tarball-version file exists at all.
Change-Id: I0312a6671e739b803beb583769e4dfc6f44fa091
If a new package is uploaded to OBS, prior to this change,
only the .dsc file is uploaded, not the actual .tar.xz containing
the source code. Let's fix that.
Change-Id: Id1c9e6d112781004238a516b24dd446af0beb95a
At the "autorecon -fi" stage, Osmocom programs either need the .git
directory peresent, or a .tarball-version file in order to determine
the exact source code version.
Normally, "make dist" exists exactly for this purpose: It runs
git-version-gen and saves the result to .tarball-version, and we then
include this file in the .tar.gz we generate.
However, as the nightly paackaging scripts use git-buildpackage, it
bypasses the "make dist" logic and hence we need to
1) manually generate the .tarball-version file
2) copy it over to the directory specified as --git-export-dir
This way, the .tarball-version is inside the tar.xz generated by gbp,
and autoreconf then has something to use as PACKAGE_VERSION.
This commit fixes "UNKNOWN-dirty" in .pc files of libraries, as well
as in "show version" commands on the vty.
Closes: OS#3449
Change-Id: I76e3713f0b01a6110091ff90e8e53aa79533c374
If string eval encounters an uncovered parse error, it's useful to know which
file it happened in.
Change-Id: I5fe9a3bbdbfb8a995f24596bf09e70ca5bb3fe8a
This came up in
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9671/6//COMMIT_MSG@36
The errors it finds in the current code base are numerous, and many are
intended LOGP .. LOGPC calls. It doesn't make sense to enforce this, but so far
this can be used manually.
Change-Id: Id79389f090a2fded7ff01dc7e3fe9774e7f22ca0
So far we call with a $(find . -name "*.[hc]") argument list, which might
become too long at some point. Rather include dir walking in the script itself
and allow passing dir arguments as well.
This is backwards compatible, calling with above file args still works.
Change-Id: I36456383906b6295c798b82aa131dda21f8efc02
osmo-trx-lms requires limesuite newer than 17.02, as there were a lot of
features and bug fixes which osmo-trx relies on. Furthermore,
osmo-trx-lms cannot build with that version since it doesn't provide
yet a pkgconfig file.
We cannot use latest tagged release (18.06) since that version has some
build related bugs which have been fixed later on
(c1496679cadff2913cacdaa84afe93bbee76d8e4), hence why we are using
latest available master instead.
Change-Id: If47a3767c7fefbb75923cbfc8eeb921e29393285
Let's move limesuite first since it doesn't depend itself on any osmocom
related package, and osmo-trx depends on it.
Change-Id: I0cdc85a2d0212432bf0c2586230660d363212dcc
Writing '{ 0, NULL }' is actually identical to just '{}', and that's what I use
these days in all sorts of other contexts. So allow this notation as well in
the C code grepper.
Change-Id: I0822d2d997dccbfb31316953a7b6024c317d92cf
This reverts commit 5b2bb86e8a.
While it was intended to enable automatic "latest" builds from rtl-sdr,
it breaks builds e.g. of libosmo-abis, where we have both (new) tags
without 'v' and old tags with 'v', and now the older 'v' tags win
due to lexicographical sorting :(
Change-Id: I1c8d2ab18e389a8c2c41082d997f101d72c3acc0
we cannot yet build "latest" for them, as they don't have any tagged
versions yet which include the /debian directory.
Change-Id: Ia5708508d918fd71eb05393e39b93859b943d623
Some projects (notably rtl-sdr) use "v" in front of their version
tags in the git history. Let's make sure we also recognize those.
Change-Id: I20f9896cc7844a6ddec7ba63bc9a77f548082e2a
Now that osmo-fl2k has debian packaging information included, we can
easily build it as part of the "latest" and "nightly" feeds.
Change-Id: Ie2429df14ad51aadb55b4a7d8f6cfcb45c5c6e70
Now that rtl-sdr has debian packaging information included, we can
easily build it as part of the "latest" and "nightly" feeds.
Change-Id: Idc6afb523e71ed977401d707895844bad6247f8b
E.g. old version 0.10.2.20180501 (0.10.2 last deb version,
20180501 was the date)
The new version will look like 0.10.2.279.178b
- 0.10.2 is the last tag
- .279 is 279 commits since the tag
- 178b is the actual short git rev
The direct output of ./git-version-gen couldn't be used because
debian forbids using a minus (-) in upstream versions.
Change-Id: I2da90ada90adf8ef8f8cfee3d26f86fbd3cec181
This script should be executed regularly on all build slaves that
have docker in order to discard unused images/layers. It would
be a good idea to call "fstrim /" afterwards in order to get more
SSD performance. However, the latter requires root access, and hence
cannot be called by the 'osmocom-build' user and thus jenkins.
Maybe we should install it as a cron job or systemd periodic timer job?
Related: OS#3144
Change-Id: I688b952578507a9cc28fe682221b5c7e3a245519
git clean always excludes git clone subdirs; furthermore, even if I supply a
dir as -e, the contents of that dir still get cleaned out. So it is useless to
pass -e on the commandline. Drop it.
Change-Id: I2b59cc9c9adf88a2663469b22cfeffbd66b5bf2e
In case we provide a tag, origin/$tag doesn't resolve correctly, we must
use $tag. Same happens probably if we want to build against a specific
commit hash.
Change-Id: Ica50080c8b3e20686fe6f47a2b61718ef4a66d95
This commit introduces the usage of GNU stow[1] for dependency
management.
Stow uses symlinks to make dependencies available in a single directory
althoguh they were installed in distinct directories.
Keeping installation directories seperate has the advantage of letting the
build fail if AM_CFLAGS and LDADD do not contain all dependencies which are
actually used.
Installing multiple dependencies into a single directory causes x_CFLAGS
and x_LIBS variables to magically point where other dependencies are
found as well, therefore missing entries can be overlooked.
Stow acts as a convenience layer here, making it unnecessary to supply a
list of locations in LD_LIBRARY_PATH, PKG_CONFIG_PATH and so forth for
building when dependencies are installed in distinct directories
manually.
Stow has to be present on the jenkins build nodes for successful executing of
osmo-build-dep.sh.
[1] https://www.gnu.org/software/stow/
Change-Id: I8f5012419495a656912b7b71e4f76ce102c6b63a
The split build script also initilize the repository if it's empty and doesn't
need any state of the osc repository.
It also downloads bumpversion and limesuite
Change-Id: I3b55e14b5b4915a3aae23ee382d65bce4ef82774
Using a $TOP variable makes directory paths more clear
to understandable. Path now expressed starting from the TOP dir
instead of using ../../../foo
Change-Id: I7a87532a3232fbcfb5f676588991dbc59a34f739
It was recently spotted, in a osmo-msc jenkins build, that an updated
dependency (new commits to be fetched) contained a new tag which was
not fetched with the commit. It resulted in the Makefile generating an
old .version file, which ended up generating a library version in the
.pc which later in the build make the configure script fail while
checking at the dependencies.
As far as I could understand after reading several discussion threads,
it seems git fetch doesn't necessarily fetch and store locally all new
tags found in the remote, and we need to explicitly add the --tags
parameter to be sure all of them are downloaded.
This patch adds a new fetch line instead of patching the one already
present because it seems in old versions of git the --tags parameter had
a different behaviour, in which only tags and not branches are fetched.
This way is ensured that we get both correct regardless of git version.
Change-Id: I4bfe4846959c70e435d6792a755a6f2a6f0a932c
If I have a git clone that once did 'checkout [-f] branch', and if then
origin/branch gets updates, doing another 'checkout -f branch' only goes back
to the local tracking-branch of origin/branch. We never pull in changes from
origin/branch anymore as soon as a local branch exists. Always prepend
'origin/', so that 'checkout -f' goes into detached-HEAD state onto the newest
fetched revision.
Change-Id: Ia715a100b5beaf7e612c2c64cdad8819aa00c8bd
libgtpnl is the userspace library for using kenrel GTP-U support,
which is used by openggsn (and will be used by osmo-ggsn).
Change-Id: Iad600a36cb658bbd874b4587ec514f49703d6a45
Make sure osmo-deps.sh passes no $deps in to osmo-clean-workspace.sh.
In most builds, $deps is a relative path, and when within a dir that contains
no such subir, calling osmo-clean-workspace.sh has no effect. However, in some,
$deps is passed in as absolute path, so when within a deps/... subdir in
osmo-deps.sh, the script would still find the abspath and clean out all deps
subdirs; for example in osmo-bts.
Change-Id: I431d20aedefc708645a1f1862334cffaef20b928
'checkout -f' more accurately does what is intended. 'reset' changes the
current branch to some hash, 'checkout -f' force-checkouts another branch.
Change-Id: Ic6279ebaf8160bceb3fa2ab40eff0b888ecd5009
In osmo-deps.sh, add second arg $branch, and also name the first one (i.e.
$project). Use the passed branch or 'origin/master' by default.
In osmo-build-dep.sh, it's not necessary to do a second 'git rev-parse HEAD',
osmo-deps.sh already does it.
Change-Id: I598c41a12352acea6e49a321ad2f665f6ea07a44
So far, each jenkins job does its own cleanup, more or less well. Also, jenkins
git config offers the 'Clean before checkout' option, which seems to fail when
there are non-writable leftovers from a failed 'make distcheck'.
Furthermore, our jenkins build slaves have unused compiled binaries piling up
by the gigabytes: each matrix build x each parallel build and each compiled
dependency therein builds .o, .a, .so and executables plus installs them to a
local prefix, and just leaves them sitting around to rot until the job runs
again. Instead, we want to clean them out when building is done.
All of this calls for a unified cleanup script that knows how to clean a
workspace properly, to run once before and once after each jenkins build.
Here it is.
Use that function in osmo-deps.sh instead of duplicating cleanup steps.
Change-Id: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
This was the last package that we only built in
osmocom:nitb-split:nightly, so we can remove the latter, too
Change-Id: Ib99e0775e9db30ec3c5263bb3a364d8cab4633c3
this package doesn't exist in the OBS anyway, yet we continue to attempt
to upload it there. Stop that :)
Change-Id: I0f0726ed412e4a281dcf99047ca22b494216b4ad
This is no longer needed by upstream osmo-bts since Change-Id
I9f004fb5c4c1db29d4792dfd281d388c7063da13
Change-Id: Ie53482a1538d1559e764da86dbbb78031c9c386b
For some strange reason, in commit
8e9fe08080, the osmocom:nitb-split:nightly
package feed was rendered to use old packages for sgsn+ggsn, rather than
current ones by removing the "osc upload" from this script, but still
leaving the packages in OBS at
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
Removing them half (only in osmo-ci but not at OBS) is a bad idea, as
it leaves people with old packages who actually want to use nightly
builds.
Also, removing the packages in general is a very bad idea. People
are *either* using osmocom:nightly, *or* they are using the
osmocom:nitb-split:nightly feed, but not both. So we cannot remove
any packages from the osmocom:nitb-split:nightly feed until we have
introduced all those packages to osmocom:nightly *and* we have given
people sufficient notice to update!
Change-Id: I5c091127d92a4b4beb7355e16abd9788fa3b9fe5
* use coverity check on osmo-ggsn instead of openggsn
* move osmo-sgsn and osmo-ggsn from nightly-split into nightly
Change-Id: Ia49969cbfb9ef57b635a3b5759f411f71a54f8e1
All jobs are in jobs/ directory and will be automatically verified and
deployed in a follow-up commit.
Note: osmocom-nightly-nitb-split.yml has been moved to jobs/ dir.
[1] https://docs.openstack.org/infra/jenkins-job-builder/
Change-Id: I04387367a6e2d737bfb50423c81a8908d3c2a89f
The script by Neels Hofmeyr <nhofmeyr@sysmocom.de> has actually nothing
to do with libosmocore itself - it's a generic build-time check used by
jenkins so it should be part of this repo to avoid extra checkout of
libosmocore just for this script.
Change-Id: I079218b61f512975ec5bfc7dc23503ec369cbb5a
jenkins job builder is a python library to write jenkins jobs in .yml or
.json including templating and basic substition operation.
To update the job call:
Create your own jenkins_jobs.ini based on the exmaple and call
jenkins-jobs --conf ./jenkins_jobs.ini update osmocom-nightly-nitb-split.yml
Change-Id: Ie7c655c6e0e3761e7970e479cadb5ae14faa2c1c
Basically, osmo-build.sh holds logic to check whether the necessary
artifact is available. If so it fetches artifact, unpacks it and
triggers the actual build. In case the necessary artifact is not
available osmo-build.sh simply builds all dependencies from source
by using osmo-build-dep.sh and archives deps to the ARTIFACT_STORE
afterwards.
The necessary functions to determine the artifact name from remote and
local repositories as well as the handling of artifact files live in
osmo-artifacts.sh, which is sourced by osmo-build.sh.
osmo-build.sh will be sourced by the contrib/jenkins.sh build script
inside each git repository. This automatically triggers the build,
so one need to source at the end of each jenkins.sh script.
See jenkins-openBsc.sh [1] for more details.
Artifacts will be stored as follows:
$ARTIFACT_STORE/$JOB_NAME/<dep_1>.<branch_1>.<rev_1>_...
..._<dep_n>.<tag_n>.tar.gz
Furthermore, ARTIFACT_STORE environment variable has to be set on all
jenkins slaves. The JOB_NAME variables is injected to each jenkins job
by jenkins.
[1] https://github.com/blobbsen/diy-artifacts/blob/master/jenkins-openBSC.sh
Change-Id: Ifee0a2f837d23b19aa5326f810234d5452e47484
Several of the supported BTS models require hw-specific L1 headers for
compilation which are stored in separate repository. Instead of
copy-pasting code which obtains those header for each BTS it's better to
create separate script.
Change-Id: I840533d5bf9233822bc0534a25c252f1cab0a7b0
Related: SYS#3682
Move the script here from
http://jenkins.osmocom.org/jenkins/job/Osmocom_nightly_packages/
The jenkins job shall call this script instead.
One change: instead of 'rm -rf *', rather check for an empty dir, to not
endanger valuable data a user may have around when invoking this script out of
curiosity.
I've been asked at least twice what the contents of the expected env
vars should be, so log an example on error.
Change-Id: I635752e6033c57bfce90d8b0732bc402bf3014c8