February 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

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

Using rtl-sdr libraries from scratch
by madoak92＠gmail.com 25 Feb '22

25 Feb '22

Hi everyone! I'm so interested about using the rtl-sdr libraries for creating some own applications, but am a bit lost concerning the code structure and the interaction between cmake and the libraries. I have some background in C programming, but I haven't write any code as complicated, and nor of course have I had to use tools like cmake to distribute code, only I've used some Makefiles in order to compile locally a basic code. With this background, I'm trying to manage antenna switches within an array, but I need some new functionalities in the rtl_biast.c code. For this purpose, I have to use the following functions: rtlsdr_set_bias_tee rtlsdr_set_i2c_repeater rtlsdr_i2c_write_reg rtlsdr_close_bt I have modified the code but when I execute cmake and make again, I obtain errors regarding the file dependencies, saying that these functions are undeclared. How should I change the file dependencies/include and recompile it in order to make it works? Could you help me to understand the compilation process in order to arrange my own applications using rtl-sdr libraries locally? I assume I have to study thoroughly the cmake and make advanced topics, but it's a bit overwhelming and I would like to learn about it constructing the code from the basic pieces. Thank you very much in advance.

1 0

FOSDEM 2022 - Free Software Radio Devroom
by Andrej Rode 05 Feb '22

05 Feb '22

Hi all, I’d like to invite you all to join the Free Software Radio Devroom at the FOSDEM 2022 online event tomorrow February 6th 2022 at 1300 (CET). We have a range of very interesting presentations ranging from project updates, implementation of hardware accelerators for Software Radio up to receiving communication from the most distant artificial object from Earth. You can find the full schedule here: https://fosdem.org/2022/schedule/track/free_software_radio/ You can either join just the livestream of the event, but I really encourage you to join the Matrix chat to ask questions you might have and continue discussion about the presentation after it is finished, you can even join the video call for a more direct way of communication. You can find information about the chat system here: https://fosdem.org/2022/practical/online/. If you are already a member of the GNU Radio Matrix server, you don’t have to create a new account or anything. You can simply visit: https://matrix.to/#/#space-radio-devroom:fosdem.org to join the dedicated "Free Software Radio Devroom space". This space contains the main chatroom during the devroom but also you will find all dedicated presentation chatrooms in there after the presentation has finished to continue in-depth discussion. During the presentation you can ask questions in the chat and upvote questions of others, at the end of the presentation there will be a short live Q&A where a presentation host will address said questions directly to the presenter. If your question is not answered during this time you are welcome to join the presentation chatroom to ask yourself. I hope to “see” many of you tomorrow. And a big thanks for everyone presenting or helping to make this Devroom possible this year! Cheers Andrej

1 0

Help on patch submission process for a fix in rtlsdr
by Gonzalo José Carracedo Carballal 04 Feb '22

04 Feb '22

Hi, Long story short: I have a fix for a crash in Windows in librtlsdr when closing the device, and I'd love to submit a patch. I went through this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards and saw that I have to follow certain steps (design, review, etc) but I am not quite sure who to contact. For some projects, this is somehow automatized by means of Gerrit, but it looks that this is not the case for librtlsdr (yet) I'd like to do it the right way, how should I proceed? Should I post the patch here directly? Do I have to document the design of my fix and have it reviewed first somewhere else? Bit of backstory: some days ago I came across a crash in librtlsdr for Windows when closing the device (initially reported as a potential libusb bug, see https://github.com/libusb/libusb/issues/1043) Although workarounds existed (https://github.com/TALUAtGitHub/librtlsdr/commit/27d79d258c0fffb73afd3fffd3…) they relied on a somewhat arbitrary (1 ms) delay to give some time for libusb event callbacks to be triggered before resource cleanup. This was not working anymore, so I decided to look into it and ended up working on a solution. This solution involved refactoring the transfer / buffer array into an array of transfer objects that enabled synchronous cancellation of pending transfers (see https://github.com/BatchDrake/rtl-sdr-blog/blob/feature/xfer-completion/src…) Since it seems to work rather well, I though it could be interesting to submit a patch to have this fixed upstream. Thanks in advance, -- >> Gonzalo José Carracedo Carballal

2 1