openHAB 2.5.x Patch Releases

I get this when trying to upgrade

Err:1 https://openhab.jfrog.io/openhab/openhab-linuxpkg testing/main armhf openhab2 all 2.5.3-1
  Unknown date format Bad header data [IP: 35.231.52.82 443]
Err:2 https://openhab.jfrog.io/openhab/openhab-linuxpkg testing/main armhf openhab2-addons all 2.5.3-1
  Unknown date format Bad header data [IP: 35.231.52.82 443]
E: Failed to fetch https://openhab.jfrog.io/openhab/openhab-linuxpkg/pool/main/2.5.3/openhab2_2.5.3-1_all.deb  Unknown date format Bad header data [IP: 35.231.52.82 443]
E: Failed to fetch https://openhab.jfrog.io/openhab/openhab-linuxpkg/pool/main/2.5.3/openhab2-addons_2.5.3-1_all.deb  Unknown date format Bad header data [IP: 35.231.52.82 443]

Same here

Testing issues are for developers testing integration. All testing issues need to be reported on GitHub so they can be resolved, not here.
All production systems should be using the stable versions.

And which Github Repo is the correct one to report a screwed up Release file/Webserver config? That file isn’t part of any repo so a report in any of the repos is “offtopic”.

@Kai Could you please check what happened with the apt repository and why apt is complaining about an unknown date format? I assume this is because the Last-Modified Header is sent as CET while the RFC says it MUST always be specified as GMT (see RFC2616 Section 3.3.1, “All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.”).

1 Like

The only parts updated in 2.5 are Addons, not core. I assume you are not trying 3.0 testing.

I just know reporting Testing release issues is unhelpful because the developers do not look here for testing issues and many developers do not even use this forum. They mainly communicate through Issues & pull requests. Anybody running testing releases is expected to know that. I do not run testing releases.

You are confusing releases and repositories there. A release file is not a release but a file that lists files in a repository. This file needs to be updated whenever something in the repo is changed (doesn’t matter if its core, addon or something entirely new that’s added) and of course the headers should be correct so that apt downloads it (which it doesn’t at this point).

This can also be done with the stable (and unstable) dir of the repository as its an issue with the Webserver/it’s configuration, it doesn’t really matter what it delivers.

The posting from 9 days ago specifically showed the Testing repository which is off-topic for this stable patch release thread. I was not the one that confused repositories.

@tnemrap posted off-topic and I was trying to redirect nicely instead of reporting the post. I guess that was my error but people usually do not like their posts reported to the moderators.

You don’t seem to realize that the issue is for all repo’s because, as I already said, the Webserver is returning headers it shouldn’t. It doesnt matter what you request, if it’s testing, stable, unstable or whatever. Of course we can report it here for stable, in another thread for a milestone (testing) release, and on github for unstable but reporting the same issue 3 times is kinda stupid.

Also testing and stable are equal now since there are no new milestone releases (you even mentioned that in another Thread so I really don’t get why you are complaining here now), so it doesn’t matter at the moment which repo is used, the content is the same. Just unstable is different now (for obvious reasons). So testing users are currently using the exact same version that stable users are using, but that’s irrelevant for this issue.

1 Like

That would be a jfrog.io issue then, not an openHAB patch release one.

Then the right thing to do would be to point everyone to https://www.jfrog.com/jira/browse/RTFACT-21640 for more information and wait until they fixed it.

1 Like

I already spend too much of my time searching for lazy users. I know nothing about Java or jfrog.io and have no motivation to learn about it.
Thank you for pointing toe right direction though. If they had reported that as an OH issue they would likely have found the same conclusion. That is the proper process for any suspected Testing release issues.

@Bruce_Osborne Are you aware when 2.5.4 will be released?

I only know the plan was roughly one a month.

1 Like

@Kai any details?
PR for the Shelly binding is almost done, so I want to make sure this go in

Another month has passed and we have just released openHAB 2.5.4!
See https://github.com/openhab/openhab-distro/releases/tag/2.5.4 for its details.

It is a very impressive list of updates for a single month and I guess this is partially due to everyone being at home and having more time to code - the positive side effects of Corona.
A major driver of having all those PRs merged is another reason though: We have welcomed @cpmeister as a new add-ons maintainer a few weeks back and he did an unbelievable job in reviewing PRs that were already in the queue for a long time. He deserves a huge THANK YOU and I hope for all of us that he’ll continue this way the next months as well :sunglasses: !

Many thanks as well to all contributors and other members of our community - please stay safe and healthy everyone!

35 Likes

Why is modbus a new addon? It has been here for a while.

Thanks to all, but indeed particularly to @cpmeister for his tremendous support.
For the Xiaomi miio binding is one of the biggest changes it has seen in one release. It wouldn’t been possible without his help!

  • Cloud support (experimental), easy tokens
  • Vacuum map
  • Conditional execution of command to support dimmers
  • Multiple actions linked to one channel
  • Support for more complex action command
  • Improve brightness channels for most yeelights and Phillips lights
  • Miot devices support, as this will be the next gen protocol many devices can be added soon
  • Many small improvement to improve general stability and connection issues
5 Likes

Just tried upgrading from 2.5.2. I ended up with 2.5.3, not x.x.4

Hi
2.5.4 is not available on openhabian at the moment.
I’ve done:
sudo apt-get update
and
sudo apt-get upgrade -s

No new version found:
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
triggerhappy
Verwenden Sie »sudo apt autoremove«, um es zu entfernen.
Die folgenden Pakete sind zurückgehalten worden:
nodejs
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.

Maybe it takes some time.

Regards

Helmar

1 Like

Great work @Kai, and yes, thanks @cpmeister to give its time to help us fix, merge and also progress in coding. May I thank COVID also ? Not sure, but it gave a breath to OH !

2 Likes