Version 5.3 released

[Tom Keffer]

Available in the usual places. No breaking changes (that I know of!)

See the Upgrade Guide for how to upgrade.

Change log

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

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

Allow extra command line options to be passed to an extension installer. Addresses Issue #1041.

Added Astronomical Units as a unit of length. Added local_djd as a unit of local time. PR #998. Thanks to user Karen!

Moved database-specific code into the weedb module. This is in anticipation of allowing new databases to be installed as an extension.

New action weectl database rebuild-daily NAME was added to allow the selective rebuilding of the daily summaries. Addresses Issue #1035.

New action weectl station list-drivers was added to allow the listing of all available device drivers. Fixes Issue #1050.

Language subdirectory lang is now recursively searched for additional translation files. This allows extensions to add any translations they might need.

Converted test suites to use pytest.

New Finish translation for the Seasons skin. Thanks to user iiseppi! PR #1059.

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. Thanks to user Robert!

Fix problem that prevented weewxd from restarting reliably if a MySQL connection was lost. Fixes Issue #1036.

Add support for kwargs when using .series() tags. PR #1042.

Documentation now uses Zensical.

Fix problem that caused expanded substitutions to be saved when using weectl station reconfigure. Fixes Issue #1068.

[Alex Edwards]

Hi,

I'm having trouble getting this to update from 5.0.2 on Raspberry Pi.  Partly my terminal disconnected part-way through.

I've tried Googling, and tried numerous Apt Remove, Purge, Clean etc variants.  I've also found a few previous posts with similar weewx topics, but none helped.

On install - 

The following NEW packages will be installed:
  weewx
0 upgraded, 1 newly installed, 0 to remove and 608 not upgraded.
Need to get 0 B/1,564 kB of archives.
After this operation, 5,742 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package weewx.
(Reading database ... 164040 files and directories currently installed.)
Preparing to unpack .../archives/weewx_5.3.0-1_all.deb ...
Unpacking weewx (5.3.0-1) ...
Setting up weewx (5.3.0-1) ...
Using weewx:weewx as user:group
Installing udev rules
Using configuration file /etc/weewx/weewx.conf
Processing configuration file /etc/weewx/weewx.conf
Saving configuration file /etc/weewx/weewx.conf
Configuring database directory /var/lib/weewx
Configuring reporting directory /var/www/html/weewx
dpkg: error processing package weewx (--configure):
 installed weewx package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 weewx
E: Sub-process /usr/bin/dpkg returned an error code (1)

Running weewxd works, but as a daemon doesn't work.

sudo systemctl start weewx
Failed to start weewx.service: Unit weewx.service not found.

I can't find anything obvious in any log files in /var/log or what caused the errror.

Any help appreciated.

Oh, while uninstalling and reinstalling, I accidentally ran weewx in Simulator mode rather than the previous config file.  This created some duff data in my reports.  It could be good if weewx needed to be "forced" to run if the last database station_type differs from the current config file station_type, or if the process tries to create new database "fields" implying a change of station_type.  I may have to find a way to clean out this Simulator data.

Thanks

Alex

[John Smith]

dpkg --configure -a

--
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/e2b33a72-6cbc-44a3-87e6-e2d0fe57726en%40googlegroups.com.

[Karen K]

I updated to the beta version before as descriped here. Now I changed the value of the file /etc/apt/sources.list.d/weewx.list back to the original value. I called sudo apt-get update und then sudo apt-get upgrade, but WeeWX is not updated to version 5.3.0. It says, version 5.3.0 could not be found. What do I do wrong?

[Tom Keffer]

Works for me. Make sure you did "sudo apt update" before trying the upgrade.

Double check the contents of /etc/apt/sources.list.d/weewx.list. Make sure it reads

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

On Mon, Mar 2, 2026 at 7:43 AM Karen K <kk44...@gmail.com> wrote:

I updated to the beta version before as descriped here. Now I changed the value of the file /etc/apt/sources.list.d/weewx.list back to the original value. I called sudo apt-get update und then sudo apt-get upgrade, but WeeWX is not updated to version 5.3.0. It says, version 5.3.0 could not be found. What do I do wrong?

--
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/aa84de4c-bb4a-4cd2-8d9d-9bbb5c22561bn%40googlegroups.com.

[Karen K]

Tom Keffer schrieb am Montag, 2. März 2026 um 16:56:30 UTC+1:

Works for me. Make sure you did "sudo apt update" before trying the upgrade.

I did so. And I double checked /etc/apt/sources.list.d/weewx.list.

Now I tried

sudo apt-get install weewx=5.3.0-1

which returns

Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):

  weewx

in English: "The following packages are replaced by an OLDER VERSION (Downgrade): weewx"

I am a little bit confused about that. But it worked.

[Vince Skahan]

We've seen this years ago.  The problem is "5.3.0" is before "5.3.0b1" alphabetically so it's considered earlier.

Make a file containing the following:

   5.3.0b1
   5.3.0
   5.3.0a1

Then run it through 'sort' and that returns:

   5.3.0

   5.3.0a1
   5.3.0b1

[Greg Troxel]

Vince Skahan <vince...@gmail.com> writes:

> We've seen this years ago. The problem is "5.3.0" is before "5.3.0b1"
> alphabetically so it's considered earlier.
>
> Make a file containing the following:
> 5.3.0b1
> 5.3.0
> 5.3.0a1
>
> Then run it through 'sort' and that returns:
> 5.3.0
> 5.3.0a1
> 5.3.0b1

Wow, and if that's it, it points out that

packaging systems need to have sorting that works with package
versions used by upstreams

releases need to use a limited set of numbering plans that work with
packaging systems

but... a1, b1, rc1 are very very normal and a packaging system that
mis-sorts them seems like a bug.

Long ago, when having your very own microVAX in your grad student office
was exciting, GNU conventions were that alpha, beta, rc for 5.3.0 would
be

5.2.71 alpha1
5.2.81 beta1
5.2.91 rc1

which sorted correctly.

[John Smith]

This is why 5.2.99.x would have been a more sensible choice for betas.

--
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/rmitsuxq1ib.fsf%40s1.lexort.com.

[Nate Bargmann]

I'm not expert on Debian packaging, but might this be a good use for the
"conflicts" stanza? The release could be set to conflict to any prior
alpha/beta/rc of the same version number.

Maybe it doesn't work that way.

- Nate

--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Alex Edwards]

Thanks, I believe I already tried that, but tried again and still same error - 

pi@Pi:~ $ sudo dpkg --configure -a

Setting up weewx (5.3.0-1) ...
Using weewx:weewx as user:group

User pi is already in group weewx

Installing udev rules
Using configuration file /etc/weewx/weewx.conf
Processing configuration file /etc/weewx/weewx.conf
Saving configuration file /etc/weewx/weewx.conf
Configuring database directory /var/lib/weewx
Configuring reporting directory /var/www/html/weewx
dpkg: error processing package weewx (--configure):
 installed weewx package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 weewx

I can't find a way to see what exactly is causing the weewx / dpkg failure and error.  I've tried a bunch of other things too.

[Tom Keffer]

I'm not a packaging expert, but could you try:

sudo apt --fix-broken install

sudo dpkg --configure -a

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/cd728895-95f5-4fc6-b739-62c491490f3bn%40googlegroups.com.

[John Smith]

I'm not expert on Debian packaging, but might this be a good use for the
"conflicts" stanza?

Pretty sure that's only for other packages, not versions of the same package 

[Alex Edwards]

Thanks for suggestion.  I believe I've already tried that, but tried again and same result.

I just tried some Google AI suggestions for debugging dpkg ... surprisingly useful (scary?).  Main conclusion is it suggests changing to #!/bin/sh -x in the relevant dpkg install file in /var/lib/dpkg/info/weewx* then re-run the install / fix.

This then came up with the following, which looks like a python error?  My python3 is 3.7.3

Cheers

Alex

Configuring reporting directory /var/www/html/weewx
+ mkdir -p /var/www/html/weewx
+ set_permissions weewx weewx /var/www/html/weewx
+ usr=weewx
+ grp=weewx
+ dir=/var/www/html/weewx
+ find /var/www/html/weewx -type f -exec chmod 664 {} ;
+ find /var/www/html/weewx -type d -exec chmod 2775 {} ;
+ chown -R weewx:weewx /var/www/html/weewx
+ precompile
+ python3 -m compileall -q -x user /usr/share/weewx
+ rc=*** Error compiling '/usr/share/weewx/weewx/tests/test_daily.py'...
  File "/usr/share/weewx/weewx/tests/test_daily.py", line 191
    with (weewx.manager.open_manager_with_config(config_dict, 'wx_binding') as manager):
                                                                             ^
SyntaxError: invalid syntax

*** Error compiling '/usr/share/weewx/weewx/tests/test_templates.py'...
  File "/usr/share/weewx/weewx/tests/test_templates.py", line 160
    with (open(actual_filename_abs, 'r') as actual, open(expected_filename_abs, 'r') as expected):
                                          ^
SyntaxError: invalid syntax

[Vince Skahan]

Alex can you describe your setup? You are trying to update 5.0.2 to 5.3.0 but what version of the os and python are you running ? We can’t try to recreate your setup and try to recreate the problem otherwise.

[Alex Edwards]

Hi Vince,

Thanks, sorry, and sure :)  Its a Pi 5.  Hope this is what you need?

Cheers

Alex

pi@Pi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@Pi:~ $ uname -a
Linux Pi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

pi@Pi:~ $ python --version
Python 3.7.3

[Tom Keffer]

Oops. Parenthesized context expressions are not supported by Python 3.7. 

I guess I'll be doing a dot-dot release. 

-tk

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/581b2f5a-cd70-4efd-81cf-4dd090b30dc2n%40googlegroups.com.

[Tom Keffer]

Version 5.3.1 is ready.

There is no change in the code base, only in the test suite. Frankly, I don't know why we release the test suite as part of a packaged distribution. 

[Greg Troxel]

Tom Keffer <tke...@gmail.com> writes:

> Version 5.3.1 is ready.
>
> There is no change in the code base, only in the test suite. Frankly, I
> don't know why we release the test suite as part of a packaged
> distribution.

You absolutely should include the test suite in the distribution
tarballs. pkgsrc, as an exmample, and I hope all packaging systems, has
a test target as well as build/install/package targets. Thus one can
run the tests before using the package, and verify that the code, with
the intalled dependencies/compilers/etc. is ok.

This is a bigger deal with programs in languages with tricky compilers
(e.g. "does gcc X miscompile this code on CPU Foo"). But it's still the
right approach always.

[matthew wall]

> On Mar 3, 2026, at 08:49, Tom Keffer <tke...@gmail.com> wrote:
>
> There is no change in the code base, only in the test suite. Frankly, I don't know why we release the test suite as part of a packaged distribution.

since we are shipping pure python, we don't distribute a source package, only a 'binary' package. but that 'binary' package *is* the sources, so its probably good that the test code is in there in case anyone needs to run the tests - no need to download a source package or tarball and risk version mismatch or fat-fingering.

if you want to use non-backward-compatible python constructs only in the unit tests, we could tell the precompiler to *not* traverse the test code. but that would be dangerous.

for wee projects (like weewx :) i usually put all of the unit tests in a single directory 'tests' tree rooted at the base of the project, instead of putting a 'tests' directory in each python module directory. but that is not as important now that pytest does the file/directory matching that we used to have to do in shell scripts and make targets.

(and of course do not call any directory or file 'test', even if no one uses sh anymore :)

[Greg Troxel]

matthew wall <mwall...@gmail.com> writes:

>> On Mar 3, 2026, at 08:49, Tom Keffer <tke...@gmail.com> wrote:
>>
>> There is no change in the code base, only in the test suite. Frankly, I don't know why we release the test suite as part of a packaged distribution.
>
> since we are shipping pure python, we don't distribute a source
> package, only a 'binary' package. but that 'binary' package *is* the
> sources, so its probably good that the test code is in there in case
> anyone needs to run the tests - no need to download a source package
> or tarball and risk version mismatch or fat-fingering.

As I understand it, what is published is what python would call an
sdist, which is a source package. That is then converted into a wheel
by "building" which is not actually building.

[Tom Keffer]

I get that, but the rest of the infrastructure necessary to run the tests successfully is missing. For example, MySQL and pytest are both needed. The user would also have to set up permissions in MySQL in a specific way. 

-tk

--
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/040E846C-EA7E-4AE3-8530-62F1C8FD52B5%40gmail.com.

[Tom Keffer]

sdist and wheels only come into play in a pip distribution, which does not include the test files.

We are talking about the packaged distributions (Debian, RH, Suse), which do contain test files. As Matthew notes, these contain "binary" files, which in our case is pure Python. Technically, that is not a source distribution.

And I apologize for the pedantic explanation!

-tk

--
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/rmifr6gn8qy.fsf%40s1.lexort.com.

[Greg Troxel]

Tom Keffer <tke...@gmail.com> writes:

> I get that, but the rest of the infrastructure necessary to run the tests
> successfully is missing. For example, MySQL and pytest are both needed. The
> user would also have to set up permissions in MySQL in a specific way.

It is normal in pkgsrc packages to have a TEST_DEPENDS line for pytest
(and for test modules, etc.). This is parallel to expressing DEPENDS
(e.g. configobj) that are needed. Surely other packaging systems have
an analog.

As for mysql, it would be nice if it could be arranged for those tests
to be reported as skipped, or enabled only if some env var says so, in
order that tests could be run easily in a greater number of
environments. Or at least to catch exceptions and fail, so that the
rest can run. I was surprised when I first saw that, as I see sqlite3
as the standard approach quite strongly.


=> Bootstrap dependency digest>=20211023: found digest-20220214
===> Checking for vulnerabilities in py313-weewx-5.3.1
=> Test dependency py313-test-[0-9]*: found py313-test-9.0.2
===> Testing for py313-weewx-5.3.1
============================= test session starts ==============================
platform netbsd10 -- Python 3.13.12, pytest-9.0.2, pluggy-1.6.0
rootdir: /tmp/work/wip/py-weewx/work/weewx-5.3.1
configfile: pyproject.toml
plugins: cov-7.0.0, anyio-4.12.1
collected 354 items / 2 errors

==================================== ERRORS ====================================
________________ ERROR collecting src/weedb/tests/test_mysql.py ________________
/usr/pkg/lib/python3.13/site-packages/pymysql/connections.py:661: in connect
sock = socket.create_connection(
/usr/pkg/lib/python3.13/socket.py:864: in create_connection
raise exceptions[0]
/usr/pkg/lib/python3.13/socket.py:849: in create_connection
sock.connect(sa)
E ConnectionRefusedError: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:
/tmp/work/wip/py-weewx/work/weewx-5.3.1/src/weedb/tests/test_mysql.py:54: in <module>
connection = MySQLdb.connect(host='localhost', user='weewx1', password='weewx1')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/pkg/lib/python3.13/site-packages/pymysql/connections.py:365: in __init__
self.connect()
/usr/pkg/lib/python3.13/site-packages/pymysql/connections.py:723: in connect
raise exc
E pymysql.err.OperationalError: (2003, "Can't connect to MySQL server on 'localhost' ([Errno 61] Connection refused)")

During handling of the above exception, another exception occurred:
/tmp/work/wip/py-weewx/work/weewx-5.3.1/src/weedb/tests/test_mysql.py:58: in <module>
connection.close()
^^^^^^^^^^
E NameError: name 'connection' is not defined
______________ ERROR collecting src/weeutil/tests/test_config.py _______________
import file mismatch:
imported module 'test_config' has this __file__ attribute:
/tmp/work/wip/py-weewx/work/weewx-5.3.1/src/weecfg/tests/test_config.py
which is not the same as the test file we want to collect:
/tmp/work/wip/py-weewx/work/weewx-5.3.1/src/weeutil/tests/test_config.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules
=========================== short test summary info ============================
ERROR src/weedb/tests/test_mysql.py - NameError: name 'connection' is not def...
ERROR src/weeutil/tests/test_config.py
!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!!
============================== 2 errors in 1.26s ===============================
*** Error code 2

Stop.
make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/wip/py-weewx
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/py-weewx

[Greg Troxel]

Tom Keffer <tke...@gmail.com> writes:

> sdist and wheels only come into play in a pip distribution, which does not
> include the test files.

Thanks for clarifying that.

IMHO it's a bug for tests to be left out of pip sdists. It's not like
sdist authors could have tested in all environments where they might be
used. I realize this is controversial in python, but I have found in
packaging lots of things that I have encountered test failures that the
upstream developers don't see. These have been all of real bugs in
upstream code, test bugs, and bugs in the platform.

> We are talking about the packaged distributions (Debian, RH, Suse), which
> do contain test files. As Matthew notes, these contain "binary" files,
> which in our case is pure Python. Technically, that is not a source
> distribution.

In my case, I'm talking about downloading "source" from
https://weewx.com/downloads/released_versions/ and then using pkgsrc to
create a "binary package":

-rw-r--r-- 1 gdt wheel 2903352 Mar 3 12:17 py313-weewx-5.3.1.tgz

I find that the source tarball has tests, and the "binary" (which is
sort of a wheel in pkgsrc format) lacks them. That's all good.

[Vince Skahan]

Not a debian packaging guy, but why are you precompiling anything ? Can’t you just distribute the uncompiled python files and let first runtime do that ? 

Re: test suites and util directory etc. It’s great they are included, but they don’t have to execute to inctall the dpkg do they ?  Should anything other than minimum runtime execute as a package (or pip) is installed other than installing the startup file ?

Bumping the minimum python version might have helped this one but doing so opens up a can of worms. A bit tough dealing with old interpreter versions but not being handcuffed by them moving forward.

[Chris Alemany]

Have upgraded successfully from 5.2.x to 5.3.1 using pip.

One question: I notice mention of a change in the UNIQUE index that might save a substantial amount of space for the database.

Given that my database is over 600MB, but also 20 years old… I am nervous.

How many backups should I make ;=) and could someone post a step-by-step for migrating the database over?

Cheers

Chris

On Mar 1, 2026, at 15:42, Tom Keffer <tke...@gmail.com> wrote:

Available in the usual places. No breaking changes (that I know of!)

See the Upgrade Guide for how to upgrade.

Change log

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

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

Allow extra command line options to be passed to an extension installer. Addresses Issue #1041.

Added Astronomical Units as a unit of length. Added local_djd as a unit of local time. PR #998. Thanks to user Karen!

Moved database-specific code into the weedb module. This is in anticipation of allowing new databases to be installed as an extension.

New action weectl database rebuild-daily NAME was added to allow the selective rebuilding of the daily summaries. Addresses Issue #1035.

New action weectl station list-drivers was added to allow the listing of all available device drivers. Fixes Issue #1050.

Language subdirectory lang is now recursively searched for additional translation files. This allows extensions to add any translations they might need.

Converted test suites to use pytest.

New Finish translation for the Seasons skin. Thanks to user iiseppi! PR #1059.

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. Thanks to user Robert!

Fix problem that prevented weewxd from restarting reliably if a MySQL connection was lost. Fixes Issue #1036.

Add support for kwargs when using .series() tags. PR #1042.

Documentation now uses Zensical.

Fix problem that caused expanded substitutions to be saved when using weectl station reconfigure. Fixes Issue #1068.

--
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/CAPq0zECoF4QHtfWx0q9%2B3yy%3D5yFa3jF6ZdxXHArHftrtSLxBFQ%40mail.gmail.com.

[Vince Skahan]

On Tuesday, March 3, 2026 at 9:34:59 AM UTC-8 Chris Alemany wrote: 

I notice mention of a change in the UNIQUE index that might save a substantial amount of space for the database. Given that my database is over 600MB, but also 20 years old… I am nervous.

 

 If you don’t touch it you can’t break it. Disk is cheap.