We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has
also deb9 set as build slave to test.
I'd move over to deb9 now and no longer build on deb8.
What do you guys think, should we build on both deb8 and deb9?
~N
Hi.
For quite some time Osmocom packages are available in Debian [1] and Ubuntu [2]
repositories. That's a really nice thing although there're only minor distro-specific
updates between different releases so far.
In addition to usual "fix old bugs, add new features (and bugs :)" progress, there're
bigger changes happening in Osmocom [3] projects.
Most notably: we now have multiple repositories for BSC/MSC/SGSN instead of single
OpenBSC repo. The process is not finished yet (doc/manuals update is still under way
for example) but I think it's already a good time to discuss how can we bring those
changes into Debian/Ubuntu repositories. We already have nightly builds for all
packages from new repositories [4] as well as old ones [5].
The basic question is - what shall we do to get the packages built from new
repositories into Debian/Ubuntu?
Is there something we (upstream) can do, to facilitate the process?
Are there some notable .deb-specific patches you'd like to see merged?
Should I have used some other channel to communicate instead of emails I've fetched
from changelogs?
[1]
https://packages.debian.org/search?keywords=osmocom&searchon=names&suite=st…
[2]
https://packages.ubuntu.com/search?suite=all§ion=all&arch=amd64&keyword…
[3] https://osmocom.org/issues/2257
[4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:night…
[5] https://build.opensuse.org/project/monitor/network:osmocom:nightly
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
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_debia…https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-iuh/1/a1=default,a2=def…
Does anyone know what could have caused this?
~N