V5.0.0 available

[Tom Keffer]

A year in the making, V5 is finally available! Some minor new features, but most of the work has been to keep up with the changing world of Python --- lots of things have become obsolete (distutils), while others have just changed. 

A few changes to highlight:

• WeeWX can now be installed using pip. The old setup.py method is gone.
• Support for the latest versions of Python.
• Improved documentation.
• The utilities have been pulled together under one master utility, weectl, making it easier to find the functionality you need.
• Management of multiple stations is easier and more modular.

Complete change list.

Quickstart install and upgrade instructions. 

Be sure to read the Upgrade Guide.

- Tom, Matt, and Gary.

[Colin Larsen]

Congratulations on the release of V5 team. 

Now I just have to remember how I did my original install 😊

Colin

--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEDyOXhODJ_XaCw%3Dcxm9L3B2t3k70Y3L2fkZQwYSyb71Og%40mail.gmail.com.

[p q]

I'm in the same boat. But I know I upgraded to 4.0 using apt so I'm pretty sure I need to follow those instructions. 

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CACjxfUvkKFUa%3DtmzHqtKvtHZ4f0OnDQAjfeBVZ4hKXUh60M1EQ%40mail.gmail.com.

[Dale Chatham]

I have a somewhat different problem:

sudo yum update weewx
Last metadata expiration check: 2:16:48 ago on Sun 14 Jan 2024 02:38:40 PM CST.
Dependencies resolved.

 Problem: cannot install the best update candidate for package weewx-4.10.2-1.el8.noarch
  - nothing provides epel-release needed by weewx-5.0.0-1.el8.noarch from weewx
  - nothing provides python3-importlib-resources needed by weewx-5.0.0-1.el8.noarch from weewx
==========================================================================================================================================================
 Package                            Architecture                        Version                                  Repository                          Size
==========================================================================================================================================================
Skipping packages with broken dependencies:
 weewx                              noarch                              5.0.0-1.el8                              weewx                              1.2 M

Transaction Summary
==========================================================================================================================================================
Skip  1 Package

Nothing to do.
Complete!

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAA1SM22pXFe8OJddM%3DwcxzxJtVHTXW_rJcez6rZy6eyaR%2BhzGA%40mail.gmail.com.

[vince]

From Tom's announcement - "Be sure to read the Upgrade Guide."   You need to install epel-release.

[Tom Keffer]

If you have a stable installation that's working for you, there's no reason to upgrade. There are a few big fixes, but they are minor and not encountered very often.

-tk

On Sun, Jan 14, 2024 at 3:51 PM Gerard Cerchio <gjce...@gmail.com> wrote:

I read the upgrade guide and the change log. I have a very stable installation running on 4.10.2. All the directory and weewx user changes look a bit scary to me because I have site specific python scripts in weewx/user directory that read and format Scripps buoy RSS feeds.

Any  guess how hard of time I'll have for the upgrade now that weewx has shown up in apt upgrade list?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8a9010ad-677d-4e03-b101-30b597967106n%40googlegroups.com.

[matthew wall]

On Sunday, January 14, 2024 at 5:56:06 PM UTC-5 dale.c...@gmail.com wrote:

 Problem: cannot install the best update candidate for package weewx-4.10.2-1.el8.noarch
  - nothing provides epel-release needed by weewx-5.0.0-1.el8.noarch from weewx
  - nothing provides python3-importlib-resources needed by weewx-5.0.0-1.el8.noarch from weewx

for redhat8, you need to install epel-release and you must enable crb. we tried to make this automatic by including epel in the weewx dependencies, but no joy. (actually, it depends on how you did the initial redhat install, since some configurations put the epel and crb repo files in place for you)

https://weewx.com/docs/5.0/quickstarts/redhat/#configure-yum

you should be able to have multiple python3 versions installed concurrently from rpm in your redhat system, but weewx has to use 3.6. although there are later versions of python 3 available for redhat8, none of them have configobj, pillow, or cheetah available as associated rpms.

m

[Chris Alemany]

Congrats to everyone! A huge amount of work. 

I'll likely upgrade tonight. I've been running b17 for a few weeks. 

Any gotchas on moving from the betas to the release? I'm using the pip method.

Cheers

Chris

On Jan 14, 2024, at 16:28, matthew wall <mwall...@gmail.com> wrote:



--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/4be470be-7213-44f9-b512-e7fb9fd94f89n%40googlegroups.com.

[matthew wall]

On 14 Jan 2024, at 18:51, Gerard Cerchio wrote:

I read the upgrade guide and the change log. I have a very stable installation running on 4.10.2. All the directory and weewx user changes look a bit scary to me because I have site specific python scripts in weewx/user directory that read and format Scripps buoy RSS feeds. 

Any  guess how hard of time I'll have for the upgrade now that weewx has shown up in apt upgrade list?

i really hope it is not difficult for you, but if you do encounter problems, please let us know.

for a debian upgrade from 4.10.2 to 5.0.0, the contents of /usr/share/weewx/user will be copied to the new location /etc/weewx/bin/user

the old directory will then be moved aside, so your original files in 'user' will still be there

however, if you had any cron jobs or other scripts that referenced those files, you will have to change them to refer to the new location in /etc/weewx/bin/user

if those scripts are called within weewx, they should just work, since the new location is added to the PYTHONPATH

m

[matthew wall]

On Sunday, January 14, 2024 at 7:39:35 PM UTC-5 chri...@gmail.com wrote:

Any gotchas on moving from the betas to the release? I'm using the pip method.

pip seems to handle the beta/rc labels ok (unlike dpkg/apt, which seems to be having issues with 'rc')

be sure to check the output from the setup-daemon.sh script, especially if you installed your own systemd unit, macos launchd plist, or sysv init script.

[vince]

Dale - agree with your email.  No epel-release available on f39 it seems.   This worked for me in vagrant...

yum install python3-cheetah python3-pillow python3-pyusb

wget http://www.weewx.com/downloads/released_versions/weewx-5.0.0-1.el9.noarch.rpm

rpm -ivh weewx-5.0.0-1.el9.noarch.rpm

I couldn't get the signing keys to import either on f39.  Blasted bleeding edge versions....

On Sunday, January 14, 2024 at 2:56:06 PM UTC-8 Dale Chatham wrote:

[Dale Chatham]

Actually, rpm -Uvh weewx-.....


On 1/14/2024 6:51 PM, vince wrote:
> rpm -ivh weewx-5.0.0-1.el9.noarch.rpm

[matthew wall]

On Sunday, January 14, 2024 at 7:52:00 PM UTC-5 vince wrote:

Dale - agree with your email.  No epel-release available on f39 it seems.   This worked for me in vagrant...

yum install python3-cheetah python3-pillow python3-pyusb

wget http://www.weewx.com/downloads/released_versions/weewx-5.0.0-1.el9.noarch.rpm

rpm -ivh weewx-5.0.0-1.el9.noarch.rpm

apparently f39 is equivalent to rh9? 

rh9 does *not* need epel. also, rh9 uses python 3.9, so the import-resources backport is not necessary either.

we'll have to figure out how to clarify the fedora/redhat differences in the redhat quickstart page - it probably means making the new 'weewx.repo' file even more generic. right now it will only work with redhat, centos, rocky, arch - but not fedora, since fedora reports its own releasever.

 

I couldn't get the signing keys to import either on f39.  Blasted bleeding edge versions....

we fixed the keys and re-signed the rpms, so no more SHA1 shenanigans.  for the keys, you should be able to use this on any redhat/suse:

sudo rpm --import https://weewx.com/keys.html

[sab...@gmail.com]

Congrats on the release.  Since I just finished installing 5.0RC3.  I did the upgrade to 5.0 this morning using the pip install method.  Everything went smoothly.  The upgrade station did not change the version number in the config file, but that is a very minor fix.  Probably some simple step I missed, but thought I would bring it up.

I decided while I was playing around with version 5, I would start with a clean install and only migrate over the database.  This cleaned up a bunch of old/confusing parts from my config file going back to my original 3.6 install in 2016.

Keep up the great work on WeeWX.

Scott

[vince]

On f39 intel in vagrant/virtualbox.....

[vagrant@localhost ~]$ sudo rpm --import https://weewx.com/keys.html
warning: Certificate ED444FCCF0E2B09E:
  Policy rejects subkey 72E2232B39E40AE8: Policy rejected asymmetric algorithm

Matthew - the issue now on f39 is 'your' old key from keys.html.  Tom's updated key imports ok.

[matthew wall]

On Sunday, January 14, 2024 at 7:52:00 PM UTC-5 vince wrote:

Dale - agree with your email.  No epel-release available on f39 it seems.

i updated the redhat instructions.  if you use fedora, you will have to figure out which redhat release goes with your fedora version.  for now, it looks like fedora 28-33 should use redhat 8, while fedora 34+ should use redhat 9.  when redhat 10 comes out we'll see which fedora it forks from.

 

[michael.k...@gmx.at]

Great news and congratulations for the release!

[Karen K]

Congratulations from me, too. It is a lot of work to design, to discuss, to code, and finally to test and find the bugs. 

[michael.k...@gmx.at]

Same here, pip upgrade from  5.0.0rc3  , my weewx.conf still showing 5.0.0b15, which I ran before 5.0.0rc3  .

[michael.k...@gmx.at]

Actually, it was b13 which I had installed before, I don't remember to ever have installed b15.

[gjr80]

There was a bug in rc3 that resulted in the config file not being upgraded despite a user issuing the command weectl station upgrade --what config. This may explain why 5.0.0b15 remained when you upgraded to rc3. When you did your 'pip upgrade' did you just do:

# Activate the WeeWX virtual environment
source ~/weewx-venv/bin/activate
# Upgrade the WeeWX code
python3 -m pip install weewx --upgrade

or did you issue the weectl station upgrade --what config command as well? If you didn't issue the weectl station upgrade --what config command your config file will not have been touched.

Gary

[michael.k...@gmx.at]

I didn't do the  weectl station upgrade --what config so I guess that'll explain the behavior. So, for me to understand: the version in the config file only specifies the latest version a  weectl station upgrade --what config   was made and it is only needed, when the config is upgraded, to define an upgrade path for the config itself?

[gjr80]

More or less. Think of the version number in weewx.conf as specifying the version of the config file (just like the Seasons skin is now versioned). If the weewx.conf version is 4.9.0 that config file includes all (config) changes up to WeeWX v4.9.0, but if there were any config file changes introduced in 4.10.0 or 5.0.0 those changes will not be there. I suspect that with the release of v5  weectl station upgrade --what config will now be the most common means by which the weewx.conf version number is set, the of course other is by performing a clean install.

The weewx.conf version number is used as the starting point for determining what config file updates need to be applied when weectl station upgrade --what config is executed. I'm not so sure this is the only time the weewx.conf version number is needed/used, Tom may wish to elaborate.

Gary

[Gerard Cerchio]

Thanks Tom, for those who do not wish to upgrade and want to prevent an accidental upgrade, you may run:

apt-mark hold weewx

If you are using Webmin, then select Refresh Available Packages and weewx will not be an upgrade candidate.

[Dale Chatham]

I may have misspoken, I'm using Fedora 38, but points taken.

As for bleeding edge, while I don't disagree, the choice may well be deal with it now or when it becomes RHEL 10. :)

[matthew wall]

On Monday, January 15, 2024 at 2:02:45 AM UTC-5 michael.k...@gmx.at wrote:

 So, for me to understand: the version in the config file only specifies the latest version a  weectl station upgrade --what config   was made and it is only needed, when the config is upgraded, to define an upgrade path for the config itself?

like the version number in the skins, the version number in the config indicates when that config was installed or upgraded.  even then, it is only a hint, since it is quite possible that you might have made changes since the install/upgrade.

in the past 10 years of weewx, i think there have been only one or two times where we made changes to weewx that broke an existing configuration file, thus *requiring* a config change.  there have been many additional features, but those have sane defaults.

similarly, there have been only one or two cases where a change in weewx broken existing skins, and those were non-fatal breaks.

we try *really* hard to maintain backward compatibility!

[Dale Chatham]

Got it going.

Thanks for your help!

--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/4be470be-7213-44f9-b512-e7fb9fd94f89n%40googlegroups.com.

[WindnFog]

All good here . . . upgrade to 5.0.0 went fine. THANK YOU, GUYS!

- Paul VE1DX

[Cameron D]

On Monday 15 January 2024 at 10:46:24 am UTC+10 matthew wall wrote:

Any gotchas on moving from the betas to the release? I'm using the pip method.

pip seems to handle the beta/rc labels ok (unlike dpkg/apt, which seems to be having issues with 'rc')

In case anyone is interested, to force a "downgrade" from the rc  using apt, just apt-get install weewx=5.0.0-1

[Δημήτρης Βήχος]

upgrading my three weather stations who running weewx from 4.10,2 to 5.0.0 all works fine!  thank you!! during the upgrading ,asked me in terminal if i want to registred my station , and the link.

[matthew wall]

On Sunday, January 14, 2024 at 8:51:09 PM UTC-5 vince wrote:

Matthew - the issue now on f39 is 'your' old key from keys.html.  Tom's updated key imports ok.

short version: we need to use 4096 bits and SHA256

for the record (and the benefit of future me), the latest fedora rejects tom's original key because it is SHA1, but it rejects my original key because it is a 1024-bit asymmetric that was created in 2014.  this will probably be an issue on suse, since we sign the rpms for both redhat and suse.  it is easier to fix for debian, since we sign the repository index for apt, not individual .deb files.  we'll re-sign everything (again).

for those of you who need to update signatures and things you have signed, redhat has some details:

https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel

and this NIST 2019 publication explains why it is necessary:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

[peterq...@gmail.com]

Upgrade from 4.10 on Debian was no problem. The only thing to mention is the docs say to do apt install and I did it as apt update.  

[Sean Ford]

Curious what the recommended install method is, aside from personal preference.  Been running weewx on a Pi4 for a few years now and have been waiting for official release to migrate it over to bookworm and a fresh install, as there's a feature or fix or two I think I can take advantage of.  Since it won't technically be an upgrade (I'll attempt to migrate data over after as I'm MySQL based), I can use apt or pip.

Any advantages to either?  This will be a dedicated pi just for weewx, if that matters.

Thanks for the guidance.

[vince]

Advantages ?  If you're happy running the packaged variant, that'll continue to work for you.

Personally, I went with pip here for a variety of reasons:

1. it's trivial to back it all up
   
2. you can easily install parallel new versions to test before updating to
   
3. no battling rpm or yum or zypper or whatever unique frustrating installer each os has
   
4. lets you install and run the same way on every os almost
   
5. it doesn't pollute your os config at all, the venv is standalone and contained
6. the same mechanism (excluding systemd service) basically works if you later want to go docker

For me, (1) and (2) are the things that are most important, but I used to run setup.py installs for over a decade anyway so it was a natural progression.   Moving to the pip variant just makes both items much 'much' easier for me to handle.

[matthew wall]

On Monday, January 15, 2024 at 3:52:31 PM UTC-5 spf...@gmail.com wrote:

Curious what the recommended install method is, aside from personal preference.  Been running weewx on a Pi4 for a few years now and have been waiting for official release to migrate it over to bookworm and a fresh install, as there's a feature or fix or two I think I can take advantage of.  Since it won't technically be an upgrade (I'll attempt to migrate data over after as I'm MySQL based), I can use apt or pip.

Any advantages to either?  This will be a dedicated pi just for weewx, if that matters.

i tend to use the deb or rpm install for the systems where i use weewx as an appliance, for example, data collection on a construction site, or monitoring temperatures and weather conditions at facilities.  in this use case, i just want to get the sensors out there so i can collect the data; i want to spent very little time installing, let alone tweaking a dashboard or driver parameters.  having local storage and 'Seasons' skin is helpful for basic diagnostics and redundancy (e.g., when the network dies), but i typically send the data to an MQTT broker and/or influx server for aggregation and analysis.

i use the 'git' method when i am working on weewx code or a driver or skin, because there is no install - i make the changes then immediately see the results.  the 'git' method works well for this, but it requires too much fiddling for production data collection.

if you want to insulate yourself from the whims of the operating system, the pip approach with virtual environment is wonderful.  you can run a pip install on *anything*, whether it is an old arm machine that no longer gets updates, a router, or a pi that you just want to set and forget.  you just need python3.6 or later.  compared to a dep/rpm install, the pip approach requires more steps to set up and integrate with your system (the init stuff, the udev rules), but the setup-daemon.sh script in v5 does that for you now, or at least shows you how to do it (if you prefer to do it all yourself).

if you are running multiple drivers on a single computer, deb/rpm or pip is really easy now.  on linux systems that use systemd there is now a unit template, and on linux systems that use sysv the 'weewx-multi' script is now the default rc script.  so running multiple instances is no longer a reason to choose a python install over a deb/rpm install.

[Steeple Ian]

Tom, Matthew, Gary and the team. This is outstanding. I am in full admiration of you guys for what you do, the support you provide (believe you me I know how difficult that can be), the many hundreds of hours of your time patiently and freely given - just everything. The pip install method is such a revelation, once setup it is a dream to use - yes it is wonderful. The most important thing for me however is the sense of community you bring to users from all over the world.

Congratulations

Ian

[DR]

I have been waiting for the official release and plan on using the pip
method on a brand new install on a Rasp Pi 4.


I see from the discussions there is something installed called venv in
this current way of doing things, which must run sort of like a sandbox
where things are contained and cannot get out of bounds too easily.


A question:  Does this extract much of a performance penalty to do this,
which not knowing for sure, I assume is basically an emulator of
whatever is in the running program?  Should my Rasp Pi 4 be fast enough
to handle whatever extra overhead this program might require?  Sounds as
if the authors have been careful to make sure V5 runs without dogging down.

Thx.  Dale

[Tim Tuck]

Hi all,

Just a note for those on Ubuntu if the sudo apt upgrade doesn't work.

Check the /etc/apt/sources.list.d/weewx.list since if you started out on an earlier version of Ubuntu and upgraded along the way you will find this in that file....

# deb [arch=all] http://weewx.com/apt/python3 buster main # disabled on upgrade to jammy

Uncomment that, and then do...

sudo apt update

sudo apt upgrade

to get it happening for you.

regards

Tim

[david murphy]

Thanks to everyone involved and for this wonderful software and your continued upgrades. V5 is a peach. The internet can be a truly wonderful place.

[Graham Eddy]

many plaudits to tom, matt and gary for V5, navigating the shifting decks of python and linux while preserving the long stability of weewx for another milestone release.

the software engineers amongst us understand and appreciate the difficulty, attention to detail and sheer volume of work - dedication - this entails.

[Ξ]

>The old setup.py method is gone.

In my opinion that's a really bad decision but I guess that won't change anything. 

That whole thing with venv might be a cool and dandy new feature but it doesn't necessarily always work, whereas I've never had problem with setup.py on any system.

One particular thing I liked about it how it installs everything under the same directory:

On Debian/Ubuntu these directories are all over the place and it's annoying as hell having to search for what you need when you need it, I don't have them memorised since I don't do changes all the time and even if I had it memorised it's still inconvenient having everything scattered in random directories.

[Tom Keffer]

Not our choice. setup.py relies on distutils, which has been deprecated and will be removed. See PEP 632,

This is part of a larger security trend of preventing user-installed software from modifying system resources. Distutils was at odds with that, so it had to go. 

That whole thing with venv might be a cool and dandy new feature but it doesn't necessarily always work

Example? Venv is part of this security trend. System resources do not have to be messed with, so you're less likely to break something else. If you've got a counter-example, I'd sure like to see it.

You can still install everything in one place using the pip install method. In fact, that place can be /home/weewx, just like before.

See the document Version 5, which exhaustively outlines all these reasons. 

--

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 on the web visit https://groups.google.com/d/msgid/weewx-user/b0a5cf0d-5805-4632-9580-46c3262df8ean%40googlegroups.com.

[Ξ]

Hello Tom,

The detailed explanation is much appreciated and as always all the work you guys do! Thanks!

I've attempted the venv method just recently on a Linux Mint laptop because it looked like a cool new feature and I wanted to try it but something work so instead I did it with apt. Sorry, but I didn't document what the issue(s?) was.

All the best,

Ivo