Clock applet stopped showing weather (Fedora)

[ssrublev]

In Fedora, MATE Clock applet stopped showing weather. In 2 Fedoras f32, desktop and laptop. Desktop was fully updated yesterday (dnf), laptop several days ago. The clock itself works as usual. Locations are setup, home location set.

[raveit65]

Why ignoring Template?

[ssrublev]

Sorry, was going to write to Fedora Bugzilla but failed to find "mate-" packages in dropdown list and wrote here quickly.

Now I see "mate-" packages are in fact present there. I can open new issue there. But not today, in a couple of days. Maybe the bug gets fixed with more Fedora updates. Current update shows me bugs with "openvswitch" and "dpdk" (at desktop, laptop is unupdated).

So, if problem stays for more days, I'll open it at Fedora Bugzilla first. Just spent a night without weather indicator =)) Have to go away for a while.

[raveit65]

A complete filled out template save us to ask always the same boring questions. Anyway, doesn't matter where i get needed informations. Which packages were updated (dnf history)? Which locale? Was libmateweather updated? Version of libmateweather?

[ssrublev]

updated were all packages according to current f32 update list for a Fedora-MATE spin using sudo dnf upgrade --refresh. dnf history shows many entries across all the system, I see no libmateweather by grep.

locale:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME=ru_RU.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

libmateweather.x86_64 1.24.0-2.fc32

If a weather server is unreachable, can you tell it's address? There may be troubles in Russia with IP blocks of Telegram by authorities. I may ping the server and see it's unreachable from my network so no bug in MATE.

[muktupavels]

https://gitlab.gnome.org/GNOME/libgweather/-/issues/43

[ssrublev]

Thanks a lot! 2nd time in MATE in my memories... =))

[raveit65]

Opps, i lost weather data too with German locale.

[raveit65]

Would be interested to know if this is a temporarily fallout or a data change by aviationweather.gov?

[ehashman]

Wanted to report that this occurred for MATE on Linux Mint as well (I'm running Tara/19) but it seems to have resolved some time this afternoon.

[ehashman]

Per upstream bug linked above, looks like it was a data source issue and this can probably be closed.

[raveit65]

Indeed, my weather data is back. Thanks for info.

[raveit65]

All is back to normal, closing.

[Lamieur]

This came back and I'm still seeing "Invalid field name(s) found: raw_text" in aviationweather.gov's response.

But I've removed line 559 ("fields", "raw_text",) from my libmateweather/weather-metar.c and that works - raw_text field is still there among others, so the applet now works.

[raveit65]

Ok, reopened, but we need to find out if this is a temporarily issue from aviationweather.gov or not.

[calexil]

weather is dead again

[satoshi]

Based on this reply, the issue seems temporary while they work on the primary server. With that said, the fix in #79 is a good one too, as (hopefully) dataserver1_3 works reliably.

[raveit65]

Nope, i prefer a solution without updating all distros with our fix. Let's wait on finished server work from aviationweather.gov

[ehashman]

Yeah this seems to have broken again, although I didn't notice initially because it was displaying the last cached weather data retrieved. Looking forward to seeing this fixed permanently!

[Lamieur]

I'm not pressing (works for me after all ;)), but my single-line work-around keeps working so far, and simply not specifying to receive only the raw_data field doesn't break compatibility with the previously available (and documented) API, so there's really no harm in doing that in the mean time.

I understand releasing such simple update, with the potential of being obsolete in a month or week, is pushing work on downstream maintainers. But there should be no harm in a simple commit with a work-around, maybe giving the ones who are actively looking for an interim fix for their bug report, have a patch instantly available?

[ionutr2015]

I don't understand why you couldn't do two requests and merge the results.

[satoshi]

@Lamieur the harm of not specifying the raw_data field is every request will be 5x bigger on every machine where this applet is used. Now, #79 discusses a different approach where we'll use dataserver1_3 endpoint instead.

79 also discusses a way to patch your shared object file - a workaround I'm currently using myself.

[Lamieur]

@Lamieur the harm of not specifying the raw_data field is every request will be 5x bigger on every machine where this applet is used.

From the side of my machine, that's like a hundred of bytes of traffic per hour (or less, it's surely compressed on the HTTP layer), unmeasurable difference.

I can understand not wanting to cause bandwidth uptick on aviationweather.gov's end though. Good job and thank you :)

[calexil]

FIXED

[ionutr2015]

Hurray. Weather is back on Fedora 32.

[raveit65]

All systems on GO again.