Sync files into a temporary directory first, and only rename the temp
dir to the final dir name if rsync succeeds. Otherwise, exit with error.
Related: SYS#5764
Change-Id: Icfefd8e4bae1fd6c73445c7427aaa842c0391b2d
Import scripts from OS#4862 to have them properly versioned. We use this
to replicate Osmocom related packages from OBS to:
https://download.osmocom.org/obs-mirror
Put it in contrib/, because it doesn't need to get installed to the
jenkins nodes (as it would happen with everything in scripts/).
Related: OS#4862
Change-Id: I3f47cddbcee6c9b85fde77a039dcd5b54dd89f2d
It seems that TTCN3-centos-remsim-test was disabled manually via the web
UI and only got enabled recently after rolling out unrelated changes in
jobs/ttcn3-testsuites.yml. The tests do not run properly with the centos
version and it seems that nobody is using it, so disable them again for
now.
Change-Id: I4885333d63944af3510fdf0519233989808944ff
Import the existing (non jenkins-job-builder) job with
jenkins-job-wrecker. Change it to fetch the git repository, add missing
mkdir so it works with a fresh workspace too.
Fixes: SYS#5738
Change-Id: I19d18b24a6ae5948aeaf7c46083748c70cdb3b7b
Clone simtrace2.git before trying to create the tarball with git.
Fix for:
simtrace2
simtrace2-0.1.tar.bz2 (creating)
+ cd /osmo-ci/_temp/repos/simtrace2
/osmo-ci/scripts/osmocom-release-tarballs.sh: 195: cd: can't cd to /osmo-ci/_temp/repos/simtrace2
Related: OS#5347
Fixes: 0221a0 ("OSMO_RELEASE_REPOS: add simtrace2, osmo-remsim")
Change-Id: I0a845549ba1fe9f0d9ab55a5c5c7bf5b8f57caae
Adjust to simtrace2's directory structure, which does not have a
configure.ac in the main directory like all other repositories. The main
directory has a regular Makefile without autotools, only the host dir
has a configure.ac file (and only in newer versions). Deal with this by
creating two tarballs, one with "git archive" for the whole directory,
and one for the host dir only with the usual "autoreconf -fi;
./configure; make dist-bzip2". The latter one has the files created by
autoreconf ("configure" script and others).
simtrace2
├── simtrace2-0.1.tar.bz2
├── simtrace2-0.2.tar.bz2
├── simtrace2-0.3.tar.bz2
├── simtrace2-0.4.tar.bz2
├── simtrace2-0.5.1.tar.bz2
├── simtrace2-0.5.tar.bz2
├── simtrace2-0.6.1.tar.bz2
├── simtrace2-0.6.tar.bz2
├── simtrace2-0.7.0.tar.bz2
├── simtrace2-0.7.1.tar.bz2
├── simtrace2-0.8.0.tar.bz2
├── simtrace2-0.8.1.tar.bz2
├── simtrace2-host-0.6.1.tar.bz2
├── simtrace2-host-0.6.tar.bz2
├── simtrace2-host-0.7.0.tar.bz2
├── simtrace2-host-0.7.1.tar.bz2
├── simtrace2-host-0.8.0.tar.bz2
└── simtrace2-host-0.8.1.tar.bz2
Closes: OS#5347
Change-Id: Ib52a23a2a7d6ea64bfa539b1d026f035fdb3af57
Don't complain about using braces when they could be omitted, for
example:
if (condition) {
single_statement();
}
Another example:
if (condition) {
single_statement();
} else {
another_single_statement();
}
This is not something we would care about in code review either from
what I've seen and so it's probably just annoying for patch authors to
fix up.
Related: OS#5087
Change-Id: Ice08d5b88c683a59bacff999a1d6c07754663d39
Not necessarily followed in Osmocom code, as Daniel wrote:
> The lint complains about this break, I don't agree with it though.
> Without we're one (or two) refactors away from an unintended
> fall-through
Related: OS#5087
Change-Id: I3f106510953b0b1bf70c28ceb55a431c5c03854e
Now that we made a new release including the new .spec.in files, from
which the rpms are built, we have the rpms in the repository and can
enable the repo install test for latest.
Change-Id: I5da2b895d636b348e5aa0539a23fe4d99e8644ae
In Osmocom code, we have the following written in one line:
while (osmo_select_main_ctx(1) > 0);
This currently causes the following linter error:
ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
According to the linter, we should write it as follows:
while (osmo_select_main_ctx(1) > 0)
;
But this is not followed in Osmocom code, so let's ignore the check.
Related: OS#5087
Change-Id: Iaffe979b771c97c77edaf4aa0d232cb8939d1279
When running the linter on a patch with lots of files changed, and lots
of exclude files, this makes a big difference. On my machine, running an
osmo-iuh patch with 1580 files changed, and the high amount of asn1c
related excludes, the time for linting is reduced from 50s to 25s.
This should be acceptable, since typically we change only few files.
Change-Id: I6fb41dec25ecc1f2df7242ae041a8685a696c3fd
Does not make a noticable speed difference on a typical patch with few
changed files, but makes linting on big patches with ~1000 files and
lots of asn1c generated files in the repository significantly slower.
The next patch will optimize that case.
Change-Id: I7437d888b433fec8a444e4d7c285fff47d16c0c7
Starting from I57e77f927ee9e169cc794c5dc6b128a2d590201b, autotools
are required in order to configure and build the project.
Change-Id: I48696af1ccb5eb884f5de9085bcda37fc41766fb
Fixes: I74da8b523c9d51887d5eceb01ca0f505bb846812
We have parallel build enabled in libsmpp34.git since 2018.
Change-Id: Ibe57a8c823d9b35e2f51c9bd7a13d6baf61bf0ca
Related: Id41fbcb5a96093eb6c3dc00bcacbd379111ada70
Old osmo-msc releases failed to build because logging output of
libosmo-mgcp-client has changed. I'm backporting the fix as 1.7.1 and
1.6.4. The script builds the last 3 releases (1.6.4, 1.7.0, 1.7.1), so
mark 1.7.0 as known error.
Related: osmo-msc Id197e4ab9ba12e284299ef520edee9c362513bf1
Change-Id: I86f8252d450165f4be3d7c97fa70235638f7dd96
Oliver Smith
Pau Espin
Vadim Yanitskiy