Beta version of v5.3.0 available

[Tom Keffer]

The biggest change is in the database API to allow new databases to be installed as an extension. An extension for support of PostgreSQL is available as a proof-of-concept. 

All changes listed at the bottom.

pip

To install the beta version using pip, use the command:

pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ weewx==5.3.0b1

Debian

For Debian, go into /etc/apt/sources.list.d/weewx.list and change the line 

deb [arch=all] https://weewx.com/apt/python3 buster main

to

deb [arch=all] https://weewx.com/apt-test/python3 buster main

then proceed as normal

Redhat

Redhat is similar. Edit the file /etc/yum.repos.d/weewx.repo and change the line that reads

baseurl=http://weewx.com/yum/weewx/el$releasever

to

baseurl=http://weewx.com/yum-test/weewx/el$releasever

then proceed as normal

Change list

Moved database-specific code into the `weedb` module. This is in anticipation

of allowing new databases to be installed as an extension. 

Set log-label in sysV init script to 'weewxd-XXX' instead of just 'XXX'

Added rsyslog config example for making logs visible to weewx group without
having to use any privilege escalation.

Allow extra command line options to be passed to extension installer.
Addresses issue #[1041](https://github.com/weewx/weewx/issues/1041).

Added Astronomical Units as a unit of length. Added `local_djd` as a unit of
_local_ time. [PR #998](https://github.com/weewx/weewx/pull/998). Thanks to
user Karen!

New action `weectl database rebuild-daily NAME` was added to allow the selective 
rebuilding of the daily summaries. Addresses [Issue #1035](https://github.com/weewx/weewx/issues/1035).

Converted test suites to use [pytest](https://pytest.org).

New Finish translation for the Seasons skin. Thanks to user 
iiseppi! [PR #1059](https://github.com/weewx/weewx/pull/1059).

[Karen K]

In weewx.conf in [StdReport][[Defaults]] there is a language specification (lang = en). If you later specify a language for a specific skin, then both the English language file and the language file specified for the skin are loaded. That can be rather surprising.

[Tom Keffer]

I'm not seeing that.

What value of LANG are you using? If I do something like

LANG=de_DE.UTF-8 weectl report run

the results are in German, with no English files generated.

On Tue, Jan 20, 2026 at 7:08 AM Karen K <kk44...@gmail.com> wrote:

In weewx.conf in [StdReport][[Defaults]] there is a language specification (lang = en). If you later specify a language for a specific skin, then both the English language file and the language file specified for the skin are loaded. That can be rather surprising.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/bec6f041-8bf7-4e2a-bea9-1486255019b7n%40googlegroups.com.

[Karen K]

Tom Keffer schrieb am Dienstag, 20. Januar 2026 um 22:33:21 UTC+1:

I'm not seeing that.

It was really a special setting that made me seeing that. In weewx.conf:

...

[StdReport]

    ...

    [[MyReport]]

        ...

        lang = de (or whatever)

        ...

    ...

    [[Defaults]]

        lang = en (there from WeeWX installation)

...

 

And I had language files with different keys, for example, in en.conf you find foo = bar, and in de.conf you find bar = foo. Then bar as well as foo are available for $gettext().

I did not try weectl for this but waited for the archive cycle to pass.

The reason for the different keys was, that I put only those translations into a specific language file, which are relevant for the area that language is spoken. So I found out, that the English "translations" were available regardless of the language I set for the report. 

[Tom Keffer]

A second beta version of 5.3.0 is available.

New changes since beta-1.

Set log-label in sysV init script to 'weewxd-XXX' instead of just 'XXX'

Added rsyslog config example for making logs visible to weewx group without
having to use any privilege escalation.

Allow extra command line options to be passed to extension installer.

Addresses [Issue #1041](https://github.com/weewx/weewx/issues/1041).

Added Astronomical Units as a unit of length. Added `local_djd` as a unit of
_local_ time. [PR #998](https://github.com/weewx/weewx/pull/998). Thanks to
user Karen!

Remove unnecessary `UNIQUE` index on `PRIMARY KEY` columns in SQLite, achieving
size reduction of ~10%.  Existing database schemas are not modified.  Users
desiring size reduction are advised to consider manually migrating.

Fix problem that prevented `weectl database reconfigure` from working in cases
where a schema was specified.

Fix problem when importing data into a MySQL database. PR
[#1025](https://github.com/weewx/weewx/pull/1025). Thanks to user Robert!

Fix problem that prevented `weewxd` from restarting reliably if a MySQL
connection was lost. Fixes [Issue #1036](https://github.com/weewx/weewx/pull/1036).

[Pablo Sanchez]

Remove unnecessary `UNIQUE` index on `PRIMARY KEY` columns in SQLite, achieving
size reduction of ~10%.  Existing database schemas are not modified.  Users
desiring size reduction are advised to consider manually migrating.

FYI: Generally, a SQL optimizer considers in its costs when a column is unique. I would suggest not removing the attribute.

---
pablo

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAPq0zECai9R%2BqzVWw4NqCQdEF5HNX6PCzCT0%3D0zA1y1fZTOfSQ%40mail.gmail.com.

[Tom Keffer]

Well sure. UNIQUE is not going away, it's just being enforced by the PRIMARY KEY attribute.

This issue explains: https://github.com/weewx/weewx/issues/1031

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/bfdb442d-88c9-4be3-9552-e2b29d7eb9d0%40hillsandlakes.com.

[Pablo Sanchez]

Hey Tom,

Thank you for the context.

Ah, interesting SQLite anomaly because IIRC, a PRIMARY KEY, as defined by SQL ANSI, must uniquely identify the row and must not contain NULL values (because that would not allow one to uniquely identify the row.)  

Some vendors allow the ability to specify NULL values for a PK (IMO, kinda weird Use Case). Usually, it's because the model is busted. 

Anyway, ignore my ramblings. :)

---
pablo

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEDUPN%2Bc_E4_vBt-3wYtcHxjD6u3NZMPoxQd_fDrx0%2BUUw%40mail.gmail.com.

[Greg Troxel]

I was confused at the state of the repo. This is me getting unconfused
in case that helps. Part of that is master/development and part was
just me being confused. The master/development naming is only explained
in CONTRIBUTING, but people who are just trying to run the code need to
know that. Suggested fix at end.

On master since v5.2.0 there are 26 commits. Presumably those are "on
the 5.2 branch". Skimming commit messages, this seems plausible. So
this is what could be v5.2.1. (It won't happen -- that's fine. The
point is that they are thought to be commits appropriate to the stable
branch.)

On development there are 139 commits not on master. There are no
commits on master that are not on development. Makes sense.

I do see 5.3.0b1 in a commit message along master.

I see no v5.3.0-b2 tag. I see no recent beta tags at all.
I get it that they are noise later.

pyproject.toml still says 5.3.0b1. I guess that is the one true source
of version.

Presumably you mean that v5.3.0-b2 is

commit eea921253f2f0e3b9f09f0ed8560fa1aba0f4939 (HEAD -> development, upstream/development, origin/development)
Author: Tom Keffer <tke...@gmail.com>
Date: Mon Feb 23 14:30:37 2026 -0800

Additional URLs

but maybe a commit to pyproject.toml and a regen commit are unpushed?


It looks like one can just run this code instead of 5.2, with the same
config file, and that's expected to be ok. If that's true, I'll try it
on my live system (backups of course).

Random other comments from trying to understand:

pkg/README talks about "the installer" but I think all these files are
about particular packaging systems. I expect that if I use pip on
NetBSD, that nothing in pkg will be used or needed.

Suggested fix to make branch names clearer:

commit f3f27b23b173a258aa6e35e8fcaf3f6d5243ee19
Author: Greg Troxel <g...@lexort.com>
Date: Mon Feb 23 18:42:21 2026 -0500

README.md: Explain branch names

because people trying to run the sources (but not contribute) would
not think to look in CONTRIBUTING.

diff --git a/README.md b/README.md
index a481d17a..eade2f1d 100644
--- a/README.md
+++ b/README.md
@@ -101,6 +101,12 @@ For the latest source code:

[https://github.com/weewx/weewx](https://github.com/weewx/weewx)

+## Orientation to Sources
+
+See CONTRIBUTING.md. Briefly, `master` is the stable branch
+(e.g. v5.N) and `development` is where changes for the next release
+(e.g. v5.N+1) go.
+
## Documentation and Support

Guides for installation, upgrading, and customization:

[Tom Keffer]

That was just me being stupid. I committed, but then forgot to push my changes out. 

[R]

I note the class Almanac signature has changed in v5.3.0 with the removal of the moon_phases parameter. Understand that moon phases are still supported through the texts parameter; however, any existing user code that calls almanac.Almanac with a moon_phases argument will fail. Guess this will at least be covered in the upgrade guide? The change log does not mention the change.

R