I just noticed that osmo-iuh is not able to generate Iu protocols from ASN.1 sources anymore. This has probably been the case for a while, but it was uncovered by the osmo-clean-workspace.sh scripts recently introduced.
There are some .h and .c files missing that sed wants to modify. I get:
sed -i '6i#include <constr_CHOICE.h>' RANAP_ChosenEncryptionAlgorithm.h RANAP_ChosenIntegrityProtectionAlgorithm.h RANAP_IMSI.h RANAP_PLMNidentity.h RANAP_RAB-ReleaseFailedList.c RANAP_RAB-ReleaseList.c RANAP_RAB-SetupOrModifyList.c RANAP_ResetResourceList.c RANAP_ResetResourceAckList.c sed: can't read RANAP_ChosenEncryptionAlgorithm.h: No such file or directory sed: can't read RANAP_ChosenIntegrityProtectionAlgorithm.h: No such file or directory sed: can't read RANAP_IMSI.h: No such file or directory sed: can't read RANAP_PLMNidentity.h: No such file or directory sed: can't read RANAP_RAB-ReleaseFailedList.c: No such file or directory sed: can't read RANAP_RAB-ReleaseList.c: No such file or directory sed: can't read RANAP_RAB-SetupOrModifyList.c: No such file or directory sed: can't read RANAP_ResetResourceList.c: No such file or directory sed: can't read RANAP_ResetResourceAckList.c: No such file or directory Makefile:2711: recipe for target 'regenerate-from-asn1-source' failed make[1]: *** [regenerate-from-asn1-source] Error 2 make[1]: Leaving directory '/n/s/osmo/make-3G/osmo-iuh/src/ranap'
Notably, jenkins produces slightly different output, see
https://jenkins.osmocom.org/jenkins/job/osmo-iuh/34/label=linux_amd64_debian... https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-iuh/1/a1=default,a2=defa...
Does anyone know what could have caused this?
~N
On Wed, Nov 01, 2017 at 02:00:01AM +0100, Neels Hofmeyr wrote:
I just noticed that osmo-iuh is not able to generate Iu protocols from ASN.1 sources anymore. This has probably been the case for a while, but it was uncovered by the osmo-clean-workspace.sh scripts recently introduced.
Can you please post the exact steps to reproduce?
On my laptop, the following works: * call osmo-clean-workspace.sh * call autoreconf -fi * call ./configure * cd src/ranap && make regenerate-from-asn1-source
There are some .h and .c files missing that sed wants to modify. I get:
Not here. Works as expected. Even with a cleanly rebuilt asn1c.
Are you sure your asn1c is compiled from the osmocom git repot aper-prefix branch?
Hi Neels,
from https://jenkins.osmocom.org/jenkins/job/osmo-iuh/label=linux_amd64_debian8/3...
=============================== asn1c ===============================
+ mkdir -p /home/osmocom-build/jenkins/workspace/osmo-iuh/label/linux_amd64_debian8/deps + cd /home/osmocom-build/jenkins/workspace/osmo-iuh/label/linux_amd64_debian8/deps + osmo-deps.sh asn1c aper-prefix Cloning into 'asn1c'... HEAD is now at 6dcd9ca build: Add a simple gitignore file... + cd asn1c + autoreconf --install --force
clearly the "aper-prefix" is being ignored, as 6dcd9ca is the master branch and not the aper-prefix branch.
Is the automatic update of osmo-ci not working since at least October 27 when
commit 7c5e34cba004837189c92ca015856a06288872e0 Author: Neels Hofmeyr neels@hofmeyr.de Date: Fri Oct 27 22:31:14 2017 +0200
was introduced?
On Wed, Nov 01, 2017 at 11:49:20AM +0100, Harald Welte wrote:
clearly the "aper-prefix" is being ignored, as 6dcd9ca is the master branch and not the aper-prefix branch.
Damn, thanks, I missed that.
Is the automatic update of osmo-ci not working since at least October 27 when
the update-osmo-ci-on-slaves job was never set to update automatically, it seemed like a good idea at the time. But by now all of us expect everything to update automatically after the gerrit submit, so I set it up to "Poll SCM" now.
Now I'm trying to figure out why osmo-deps.sh fails to set up the proper branch. Somehow, even though the script is installed (manual testing on build slave in /tmp works as expected), the jenkins job still uses an old one...
I noticed another failure in using 'checkout -f' to update a specific branch -- it's a deja vu, I've had these problems before: 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. Last time solutions were using 'git reset --hard', which confuses local branches, and finally to just wipe the clone every time.
This time I think it's best to always prepend 'origin/', so that 'checkout -f' goes into detached-HEAD state onto the newest fetched revision.
Fixing things now....
~N
Hi Neels,
On Wed, Nov 01, 2017 at 01:53:48PM +0100, Neels Hofmeyr wrote:
I noticed another failure in using 'checkout -f' to update a specific branch -- it's a deja vu, I've had these problems before: 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. Last time solutions were using 'git reset --hard', which confuses local branches, and finally to just wipe the clone every time.
"checkout -f -B local_foo origin/foo" is IMHO the corect approach, which I also do in my Dockerfiles, AFAIR.
Checking out a remote branch name using a local branch name (e.g. expanding aper_prefix to origin/aper_prefix if aper_prefix doesn't exist) is a mis-feature in git, IMHO. It's confusing.
Even when working with git interactively, I always explicitly qualify branch names wit their 'remote' such as 'origin'. When working with half a dozen or more remotes in a given repository it becomes very confusing otherwise anyway.
This time I think it's best to always prepend 'origin/', so that 'checkout -f' goes into detached-HEAD state onto the newest fetched revision.
correct. And '-B foo' is an "and create a local branch with the naem 'foo' and overwrite any existing branch with the name 'foo' if it exists"
On Wed, Nov 01, 2017 at 01:53:48PM +0100, Neels Hofmeyr wrote:
Fixing things now....
OsmocomBuild1 had stale copies of osmo-ci scripts in /usr/local/bin, which overrode those kept in ~/bin. Also checked the other build slaves, all good.
I removed the FreeBSD slave from "update-osmo-ci-on-slaves". We now have OsmocomBuild1 (user osmocom-build on build slave's root fs), build1-debian9-lxc (lxc "docker" on the same machine). build2-deb8build (lxc "deb8build" on build-2 machine).
There's also that deb9build lxc on build-2, but it doesn't seem to be connected.
~N
-
Harald Welte -
Neels Hofmeyr