osmo-iuh fails to regenerate from asn1 sources
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? -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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? -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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" -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
participants (2)
-
Harald Welte -
Neels Hofmeyr