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/.

Harald Welte laforge at osmocom.org
Tue Aug 25 07:04:24 UTC 2020


Hi Matt,

On Mon, Aug 24, 2020 at 02:24:33PM -0700, Matthew Johnson wrote:
> I was able to use the experimental osmo_dia2gsup converter to successfully
> enable circuit switched fallback in a test network, 

great! I think that's an achievement considering the lack of documentation and the
state where I had to leave it at the time.  I guess you're the third person to ever
run it ;)

> but have a couple fixes for it and osmo_ss7 needed to work with the latest 2G CN components. 

excellent.

> 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. 

I didn't even remember that, will look into it.

> 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?

The reason is overload and juggling too many tasks for about the last decade or so :/

> Otherwise should I open a change request towards the WIP branch?

gerrit works on individual patch granularity, it doesn't know the notion
of a 'change request'.

I will rebase, review and push that branch.  If there's anything we need
to fix up, I'll mark those patches as WIP.  Feel free to take it from
there if there are TODO items.

> Also, do folks have any opinions on how best to package erlang components?

Not really.  I'm not aware what is the best practice these days either.

> I was going to generate a Debian package for a stand-alone erlang “release”
> of osmo_dia2gsup, 

this sounds great.

> and am happy to contribute the debian metadata and build
> files upstream,

great!

> 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.

I'm not an Erlang expert either, and I guess nobody here is.  I would
just check how other Erlang projects are doing this, preferably projects
that have official debian packages like ejabberd, or maybe you can find
a less complex example.

> 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. 

That is correct.  They were mostly developed for one specific customer
at the time, and there was no requirement for debian packaging at the
time.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list