Port to libsoup-3.0

[sgn]

Fixes: #116

[lukefromdc]

This builds and runs, both the clock/calendar and panel weather applet work fine with it installed. That said at least on my machine I still have a lot of other things depending on the old version, but this is one less.

[lukefromdc]

One possible issue here: we just released 1.28 and probably cannot change external dependencies like this within 1.28 and thus probably cannot do this without bumping version to 1.29

[bgermann]

Fixes #116

[nyabinary]

Also fixes NixOS stuff (were trying to phase out libsoup2)

[lukefromdc]

Is this for a 1.29 development release or are we planning to change external dependencies in the middle of a major version (1.28)?

[sgn]

Is this for a 1.29 development release or are we planning to change external dependencies in the middle of a major version (1.28)?

It's entirely upto Mate, as of it is, only Void and Nix uses this patch for libsoup-3.0, all other distro still uses libsoup-2.4 for libmateweather.

While we will have a crash if an application linked to both libsoup-2.4 and libsoup-3.0 (via middle-man libraries). I think it's very unlikely to have such application linked to libmateweather, because libmateweather (in my opinion) would be used exclusively by MATE desktop only, other applications (or libraries) would use libgweather instead.

Hence, while I would like to have this patch in as soon as possible, I think you can keep it for 1.29

[sgn]

Anyway, just want to remind that we still have a potential crash with libsoup-2.4 implementation.
#133 (comment)

Step to reproduce:

• Enable weather applets (from mate-applets repository)
• Switch to Location tab
• Quickly find and switch multiple Location by Find textbox (e.g. type Paris, London, Ho Chi Minh).
• It will crash

[LordGrimmauld]

While we will have a crash if an application linked to both libsoup-2.4 and libsoup-3.0 (via middle-man libraries). I think it's very unlikely to have such application linked to libmateweather, because libmateweather (in my opinion) would be used exclusively by MATE desktop only, other applications (or libraries) would use libgweather instead.

libsoup is a deep-rooted dependency, and on nix it makes its way into the closures via gstreamer. gst-plugins-bad has a dependency on libnice which in turn depends on gupnp and that depends on libsoup. It is technically thinkable an application using both gst and mateweather would crash. On nix we circumvent this problem by also patching libnice to work with gupnp 1.6 (not yet merged, but will happen soon:tm:).

Fedora has a similar patch to libnice since 2022: https://src.fedoraproject.org/rpms/libnice/blob/rawhide/f/libnice.spec#_147
This means anything that crashes with new libmateweather+old libnice in gst would have crashed before with old libmateweather and new libnice. Arguably the impact here should be minimal. That said, fedora is typically quite quick to patch things to use newer libraries.

[procule]

I said it here it was old (even older than my setup :-) ):
#131 (comment)

[lukefromdc]

I basically don't know enough about this to properly evaluate it

[sgn]

I basically don't know enough about this to properly evaluate it

I would say, at the very least, you can merge it in for 1.29 first, and evaluate if it would be good for 1.28 later, which we can do the backport to 1.28.

[lukefromdc]

Just bumped version in master to accomodate this

[lukefromdc]

While we will have a crash if an application linked to both libsoup-2.4 and libsoup-3.0 (via middle-man libraries). I think it's very unlikely to have such application linked to libmateweather, because libmateweather (in my opinion) would be used exclusively by MATE desktop only, other applications (or libraries) would use libgweather instead.

libsoup is a deep-rooted dependency, and on nix it makes its way into the closures via gstreamer. gst-plugins-bad has a dependency on libnice which in turn depends on gupnp and that depends on libsoup. It is technically thinkable an application using both gst and mateweather would crash. On nix we circumvent this problem by also patching libnice to work with gupnp 1.6 (not yet merged, but will happen soon:tm:).

Fedora has a similar patch to libnice since 2022: https://src.fedoraproject.org/rpms/libnice/blob/rawhide/f/libnice.spec#_147 This means anything that crashes with new libmateweather+old libnice in gst would have crashed before with old libmateweather and new libnice. Arguably the impact here should be minimal. That said, fedora is typically quite quick to patch things to use newer libraries.

Is this something we need to do something about here or can this be merged after a rebase to catch the version bump?

[vkareh]

I just tested this and it works perfectly fine with both the mateweather applet and the clock applet (the only components that use this lib, AFAIK). We should merge and backport as needed (assuming that's even necessary)

[vkareh]

To be fair, we should eventually deprecate libmateweather in favor of libgweather, since pretty much all its functionality is duplicated. There's an initial attempt at this: mate-desktop/mate-panel#1075

That's for a separate discussion though. Updating to libsoup3 is legitimately a good thing.

[LordGrimmauld]

Fwiw i went and actually took a look at just how many CVEs are left in libsoup 2.x. Warning: It ain't pretty.
NixOS/nixpkgs#427813 (comment)

With this many CVEs, there isn't any real chance for NixOS to go back to libsoup 2.x, and i suspect various other distros might follow. Even debian started patching to libsoup3, see https://salsa.debian.org/debian-mate-team/libmateweather/-/blob/master/debian/patches/0001_libsoup3.patch?ref_type=heads.

[lukefromdc]

I have no problem with a cherrypick to 1.28, will distros have an issue with the dependency change?