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