24 Aug
2020
24 Aug
'20
9:24 p.m.
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.
25 Aug
25 Aug
7:04 a.m.
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(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:19 a.m.
Hi Matt,
so from laforge/wip, the only problematic bit I could find is
https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/19808/1
It would be appreciated if you could take that patch and extend it as described in the
review comment. Once the application can specifiy that IPA CCM option list, we can
merge the patch and then subsequently modify osmo_diameter2gsup to use the master
branch (and that new function to specify the MME-00.... IPA CCM option).
Whatever other changes you may have, please submit them to gerrit to the respective
repository. osmo_gsup, osmo_ss7 and osmo_diameter2gsup are luckily all using
gerrit + jenkins verification these days.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1816
days inactive
1817
days old
2 comments
2 participants
participants (2)
-
Harald Welte -
Matthew Johnson