Patches and Packaging for Erlang Components

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Matthew Johnson matt9j at cs.washington.edu
Mon Aug 24 21:24:33 UTC 2020


Hello!

I was able to use the experimental osmo_dia2gsup converter to successfully
enable circuit switched fallback in a test network, but have a couple fixes
for it and osmo_ss7 needed to work with the latest 2G CN components. I
would open a change request in gerrit, but I see that the rebar.conf of
osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best
should I provide patches for review? Is there ongoing work in
http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be
merged first, and is there a reason it has not been merged already?
Otherwise should I open a change request towards the WIP branch?

Also, do folks have any opinions on how best to package erlang components?
I was going to generate a Debian package for a stand-alone erlang “release”
of osmo_dia2gsup, and am happy to contribute the debian metadata and build
files upstream, but I am not an erlang expert and want to make sure it’s
structured in the correct way if there is a convention I should follow.
>From a random sample it looks like none of the other erlang components are
packaged, so I don’t have a good example to go from. If there is no opinion
I will make an attempt, but I wanted to ask first!

Thanks for your help and patience!
-Matt J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200824/02410da9/attachment.htm>


More information about the OpenBSC mailing list