libsoup 3 support in sugar's telepathy dependencies

[loqs]

e41b3ca updated sugar to use libsoup 3.0 which is incompatible with libsoup 2 both can not be loaded in the same process attempting to do so will cause the process to exit. sugar depends on telepathy-salut and telepathy-gabble that have no libsoup 3 support. Do you have patches that add libsoup 3 support to telepathy-salut and telepathy-gabble allowing this build to work for you? I have found Fedora has a patch adding libsoup 3 support to telepathy-gabble telepathy-gabble-0.18.4-libsoup-3.0.patch. There is no similar Fedora patch for telepathy-salut. Upstream telepathy currently appears inactive.

Related telepathy-gabble issue TelepathyIM/telepathy-gabble#25.

[chimosky]

Thanks for bringing this to our attention, I had a conversation with @quozl about this a while back on an issue, can't really remember where we did.

The telepathy packages haven't been actively maintained in a while, so there's very little we can do from our end except hope that someone sends a patch like in fedora.

IIRC we dropped telepathy-salut as a dependency for some sugar packages, there was a fail to build from source a while back but that's been fixed, I'd updated it to the last released version.

The patch you're referring to was from wocky, the fix we need for telepathy-salut might also be there.

[loqs]

The patch you're referring to was from wocky, the fix we need for telepathy-salut might also be there.

telepathy-salut's vendored wocky appears to predate the use of libsoup. The issue is a library called gibber which if telepathy has a separate repository for I can not find it although the freedesktop.org move means I can not currently check telepathy's repos on freedesktop. libsoup is only used by the file-transfer component of telepath-salut I could remove that but it appears sugar does use it. So that would be at best removing a feature and at worst triggering strange and unexpected errors.

With respect to other components of the sugar stack using soup 3 / webkit2 4.1 the latest releases have been transitioned over apart from the activity-read?

[loqs]

@smcv as you have worked on libsoup telepathy and sugar do you know of anyone who would be interested in porting telepathy-salut to libsoup 3? Or even better if there is a patch already available somewhere.

[quozl]

@chimosky, our conversation about this was in September by mail. Briefly, if we cannot maintain Sugar collaboration because our dependencies have lost maintainers, then we should seriously consider either removing the collaboration features or vendor the dependencies. I did some testing of a minimal collaboration using sockets in the Level activity, but the technique did not take off. It was very very fast, but like much of our collaboration stack, quite insecure.

[smcv]

@smcv as you have worked on libsoup telepathy and sugar do you know of anyone who would be interested in porting telepathy-salut to libsoup 3? Or even better if there is a patch already available somewhere.

I have not worked on Telepathy or Sugar for several years, and I was never a libsoup maintainer.

libsoup has an official migration guide in its documentation: https://libsoup.gnome.org/libsoup-3.0/migrating-from-libsoup-2.html. The place to discuss any proposed changes would really be on an issue in https://github.com/TelepathyIM/telepathy-salut, not a Sugar issue.

updated sugar to use libsoup 3.0 which is incompatible with libsoup 2 both can not be loaded in the same process attempting to do so will cause the process to exit. sugar depends on telepathy-salut and telepathy-gabble that have no libsoup 3 support

Note that the "big idea" of Telepathy is that protocol implementations like telepathy-salut and telepathy-gabble run in a separate process and communicate via D-Bus, so it's completely valid to have Sugar using libsoup 3, talking to both tp-salut which uses libsoup 2 and tp-gabble which uses libsoup 3. As long as each of the three processes (Sugar, tp-salut, tp-gabble) only has either libsoup 2 or libsoup 3 but not both, there's no crash. The crash occurs if you load libsoup 2 and libsoup 3 into the same process.

The main benefit you could get from porting tp-salut from libsoup 2 to 3 is that it would bring OS distributions that distribute Sugar (and tp-salut) one step closer to being able to delete libsoup 2 completely.

[loqs]

libsoup has an official migration guide in its documentation: https://libsoup.gnome.org/libsoup-3.0/migrating-from-libsoup-2.html.

Thank you for the reference. I have read that sadly the synchronous to asynchronous conversion was beyond me. There is also the use of soup_server which is now documented to not be used outside of development / testing.

The place to discuss any proposed changes would really be on an issue in https://github.com/TelepathyIM/telepathy-salut, not a Sugar issue.

There has been no activity in seven years on that repository? Will open an issue as suggested.

As long as each of the three processes (Sugar, tp-salut, tp-gabble) only has either libsoup 2 or libsoup 3 but not both, there's no crash. The crash occurs if you load libsoup 2 and libsoup 3 into the same process.

I was basing my assumption everything need to be ported at once on TelepathyIM/telepathy-gabble#25

[smcv]

I was basing my assumption everything need to be ported at once on TelepathyIM/telepathy-gabble#25

Gabble does have some sort of plugin interface. If one of its plugins starts using libsoup 3, while Gabble itself is still using libsoup 2, then that will crash. But merely talking over D-Bus to a process that is using a different libsoup version should be fine.

[smcv]

Or perhaps Gabble (and Salut?) ends up loading a GIO plugin that uses libsoup, perhaps via something like Evolution, GNOME Online Accounts, librest or Tracker?

[chimosky]

I don't think we should have this problem as we ported sugar and sugar-toolkit-gtk3 to WebKit2 4.1, which handled all the necessary things needed.

[loqs]

I don't think we should have this problem as we ported sugar and sugar-toolkit-gtk3 to WebKit2 4.1, which handled all the necessary things needed.

sugar still uses telepathy-salut which still uses libsoup 2 so if Arch wishes to remove libsoup 2 it would need to drop sugar or is that not correct?

[chimosky]

sugar still uses telepathy-salut which still uses libsoup 2 so if Arch wishes to remove libsoup 2 it would need to drop sugar or is that not correct?

That is correct, seeing as there's nothing we can directly do about the issue with libsoup @quozl what would you suggest?

Moving away from telepathy might be the next thing, or removing the collaboration feature like you suggested.

[quozl]

It would be best if Telepathy fixes their dependency. That may take help, which can come from any Sugar Labs developer, distribution developer or just any random person.

Sugar could take over maintenance of Telepathy components and patch it to replace libsoup 2, and vendor them all inside Sugar Toolkit. Happy to support that with reviews. There are large parts of Telepathy that we don't use, so it would be a fairly simple iteration process to add chunks rather than the complete thing. Forking has risks though.

Doing this for Arch would show a truly amazing degree of dedication, thank you. 😁 While we can still build Sugar with Telepathy on Fedora, Debian and Ubuntu, we could keep our dependency on Telepathy upstream.

We do appreciate the effort distribution developers put into untangling this mess.

Should any replacement collaboration stacks be available, do let us know.

[loqs]

While we can still build Sugar with Telepathy on Fedora, Debian and Ubuntu, we could keep our dependency on Telepathy upstream.

Fedora is looking at dropping libsoup 2. Ubuntu does not package telepathy-salut for releases after 22.04.5 LTS (Jammy Jellyfish). Debian does not package telepathy-salut after Debian 11 (bullseye). I think all distributions would welcome a patch that ported telepathy-salut to libsoup 3. The only file that needs porting in telepathy-salut is https://github.com/TelepathyIM/telepathy-salut/blob/master/lib/gibber/gibber-oob-file-transfer.c sadly it does not appear appear to a trivial conversion at least to me.