On Wed, Nov 14, 2018 at 07:06:22PM +0100, Ruben Undheim wrote:
segfault in gcc really!? I have not seen it, but I have only built it in Debian 10.
yes, in osmo-iuh.
we are left with the failures for osmo-msc on mips64el and mipsel (the low-endian variants of mips). So the test "msc_vlr_test_gsm_ciph" is failing. Does this tell you anything?
Interesting, the only difference is:
-- ERROR sending ciphering mode command: rc=-95 +- ERROR sending ciphering mode command: rc=-122
i.e. a mismatching rc gets returned. It's not an error with any practical effect.
Aha, could it simply be that the errno are defined differently on this platform? It should be -95 == -ENOTSUP, while we get -122.
Weirdly enough, I don't see this line printed at all in my current msc_vlr_test_gsm_ciph output. Ah, I know, because A5/3 was fixed, hence we see no error anymore, since 3117b701c8d4645215896c459d6c608358a0a51b
There has been no release after that yet.
If you want to stay with that old revision, try branch neels/mipsel of osmo-msc, which I've just pushed, with this patch: http://git.osmocom.org/osmo-msc/commit/?h=neels/mipsel&id=d655d10e98c390...
Or otherwise wait for Pau's release and rather use those latest revisions.
As long as we know what the fix is, we can backport the fix wherever we want.
sure, I forgot the deb packaged patches.
Maybe the trick is to just start going over all structs in libosmocore
I thought about scripting it, because editing manually takes forever and is error prone.
Interesting. I did not know about this way of viewing the patches, although I am behind most of the patches. Please just pull back whatever you find useful.
Ideally, the patch author goes on to submit it on gerrit.osmocom.org :)
~N