March 2022 - osmocom-sdr - lists.osmocom.org

RFC: migrating git.osmocom.org to gitea?
by Harald Welte 31 Mar '22

31 Mar '22

Hi all! [please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if there is any discussion, we don't want to drag it over tons of mailing lists in parallel] Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody noticed the ticket or had any comments to it. So let me post this as RFC here on the mailing list: In the past, we had a gitolite/gitosis setup, which was fine in the early days of git, but it means that people cannot easily create new repositories, see who has permissions, and we cannot delegate ownership. Even updating SSH keys requires manual interaction of a sysadmin like me. I would therefore suggest to migrate git.osmocom.org to gitea[1] This would allow the following features: * users can self-create any number of personal repositories (like gitlab/github) * we can create 'organizations' along the line of reasonably independent osmocom member projects like op25, who can then manage their own repos/permissions/... * gitea can link to redmine wiki and redmine issue trackers (rather than using its own built-in) For those repositories hosted in gerrit (mainly CNI), we would still keep git.osmocom.org a read-only mirror, like we do it right now. For those repositories not hosted in gerrit, users/projects could then accept merge requests in gitea. Coupling this with 3rd party authentication via github/gitlab/etc should make it easier for the occasional contributor to submit changes. There is a downside, of course; A lot of repo URLs have to change. Most of our current repositories are at git.osmocom.org/project.git while gitea follows a git.osmocom.org/organization/project.git scheme. I'm not sure there is any way to help to mitigate this... Any thoughts, comments? [1] https://gitea.io/ -- - 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)

1 1

OsmoDevCall on Mar 25, 2022: "Iridium reverse engineering update"
by Harald Welte 24 Mar '22

24 Mar '22

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall on March 25, 2022 at 20:00 CET at https://meeting5.franken.de/b/har-xbc-bsx-wvs In this edition, Sec and schneider will present an "Iridium reverse engineering update". This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. NOTE: There will be no recording of this talk, so if interested, please make sure you don't miss it! More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

1 0

OsmoDevCon 2022 ?
by Harald Welte 10 Mar '22

10 Mar '22

Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? Regards, Harald -- - 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)

2 4

Snap package for RTL-SDR tools
by Alberto Donato 03 Mar '22

03 Mar '22

Hi, I made a snap [1] package for the RTL-SDR tools. The package has "strict" confinement, which allows installing it on any supported distro. I tested it on Ubuntu 21.10 (on amd64) and Ubuntu Core on a Raspberry Pi (my main use case for the packaging is to be able to run rtl_tcp on the latter). Would you consider merging this to the repo and possibly publishing snap packages on the Snap Store as part of the regular release process? Cheers, -Alberto [1] https://snapcraft.io/docs

1 1