Release

[Mindavi]

Hi, I was wondering if a release is planned or if it possibly should be planned. I'm not sure about the distribution of users, but I assume there might be some users that use the version distributed by their package manager, e.g. ubuntu (https://packages.ubuntu.com/eoan/rtl-433). Because their repositories only contain releases, those users might miss out on some recently added features and decoders.

Would it be good to make a release and if so, are there any issues that need to be solved before doing so? Or is releasing something that's considered non-important/not needed?

Honestly, I really can't tell if there are users that just use the version provided by the package repositories, because this is a niche tool mostly used by enthousiasts, I'd assume.

[merbanan]

My idea was to make a release before February 10. @zuckschwerdt any comments on that?

[zuckschwerdt]

I don't have any short term feature PRs, just "someday" stuff. (And decoders will always be evolving.) I'd say we are good for a release tag. However:

I would be really interested about the user base, what platforms and if it's precompiled or from git. I've been playing with static builds and CI for armhf/64, i686/amd64 to help users just download a binary. But I'm not too sure if that's a thing for SDR hackers ;)

Maybe we could output a prominent link with some encoded but visible stats? Allthough I'm not one for automatic usage stats in background, I'd click a simple link. E.g.

Click this link to let the developers know what system is most used: https:// foo /stats?platfom=foo&ver=foo

[merbanan]

Things before release:

• [x] Fix Thermopro 11 and 12 integrity check.
• [x] Add odd parity check for bt_rain
• [x] Inform better regarding new defaults when >800MHz
• [x] Proper return codes for decoders

[merbanan]

I'd like to get the release out soon. Do we have any nice to have stuff that we want in the release ? Some of the long gone PR's would be nice.

[Mindavi]

Maybe we could do a sweep through all decoders to fill in any missing return codes for the diagnostic mode. I'm not sure what else is important, but according to the bug reports something about the minmax vs classic decoder should definitely be mentioned indeed.

[merbanan]

@Mindavi I'm like 25% through all decoder regarding that.

[alexmyczko]

@mindavi https://github.com/merbanan/rtl_433/issues/1095

https://qa.debian.org/popcon.php?package=rtl-433

[Mindavi]

Shall I pick up a part of the error code implementation? If so, maybe we should track progress somewhere?

[merbanan]

@Mindavi I did it alphabetically, last file was holman_ws5029.c in feat-error-codes2 branch. I mixed some other stuff in there so it can't be applied yet. Anyway if you continue and only do the error codes we can merge those quickly. Anyway that would be very helpful.

[merbanan]

@Mindavi just push the return code fixes directly. Simple fixes can be pushed directly without a PR. More complex changes can go as a PR.

[Mindavi]

Most devices have correct(ish) return codes now. #1314 lists some missing ones, which use the 'event pattern'.

Notably, I've skipped m_bus.c, which needs a good look.

You can find all non-implemented decoders using grep -R "return 0" -l | sort | less.

This gives the following list, of which most should be mentioned in #1314.

acurite.c
brennenstuhl_rcs_2044.c
current_cost.c
digitech_xc0324.c
dsc.c
flex.c (false positive)
gt_wt_02.c
hondaremote.c
ht680.c
ikea_sparsnas.c
m_bus.c
new_template.c
oil_standard.c
oregon_scientific.c
oregon_scientific_sl109h.c
radiohead_ask.c (false positive)
tpms_ford.c
tpms_pmv107j.c
tpms_renault.c
tpms_toyota.c
ttx201.c

[merbanan]

I'd say it's enough return codes for the release. The ones left needs a more in-depth look.

[merbanan]

I have added the output information. I have no further things I think is vital before a release. @zuckschwerdt do you have something you want to add? If not can you create a release tomorrow?

[zuckschwerdt]

Ok, I'll compile the changelog and tag a release tomorrow.

[alexmyczko]

how am i supposed to build the docs? ./build-docs.sh ? and the tarball release spits out

$ rtl_433 -V
rtl_433 version unknown inputs file rtl_tcp RTL-SDR SoapySDR

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.16") found components: doxygen dot

[zuckschwerdt]

The Doxygen stuff is just for the maintainers. It's really not used but a style check for now. Use cmake -DBUILD_DOCUMENTATION:BOOL=OFF .. if you accidentally turned it on.

Yes, we need a solution to insert a version number when not building from Git with CMake. Not sure if we really want to put a version number (and keep it up to date) somewhere.

[alexmyczko]

The Doxygen stuff is just for the maintainers. It's really not used but a style check for now. Use cmake -DBUILD_DOCUMENTATION:BOOL=OFF .. if you accidentally turned it on.

I maintain the debian package, and fail to build the docs?

W: rtl-433-doc: empty-binary-package
W: rtl-433: manpage-has-errors-from-man usr/share/man/man1/rtl_433.1.gz 735: warning [p 9, 3.8i]: can't break line

[zuckschwerdt]

As for distrib docs, that's just the plain .md files. Those docs (not doxygen source code docs) can be found at https://triq.org/rtl_433/

The doxygen docs are not used. I guess you can build them, but they are not distributed or available anywhere. There is no useful index or intro page.

I'm not aware of an error in the troff man page. What checker is that?

[alexmyczko]

something from https://salsa.debian.org/lintian/lintian

[zuckschwerdt]

Probably https://salsa.debian.org/lintian/lintian/blob/master/checks/documentation/man.pm then. Let's see if we can spot what's wrong.

[alexmyczko]

I fixed the -doc thing by dropping the package for now.

[merbanan]

@alexmyczko can you sponsor a patch to the debian rtl-sdr package for me?

[merbanan]

https://github.com/osmocom/rtl-sdr/pull/9

[alexmyczko]

guess so well i can put that in the source package and a DD might sponsor it, i can not ;)

well that file is not in rtl-433, but somewhere else, so i can't patch it, sorry: $ find . -name tuner_fc0013.c empty

that'd be here to patch: https://packages.debian.org/sid/rtl-sdr

forwarded your request, answer: he'll look into (Modulo time spent busy with the day job I'll look)

05:20 < BTS> rtl-sdr 0.6.0-3 uploaded by A. Maitland Bottoms (bottoms) https://tracker.debian.org/rtl-sdr

[zuckschwerdt]

For the troff checking the script runs man --warnings -E UTF-8 -l -Tutf8 -Z rtl_433.1. I don't get the warning with man 2.7.6.1 here. But it looks like an overlong line warning.