Port to libsoup3 (see https://github.com/geany/geany-plugins/pull/1295#issuecomment-1906999722 @jbicha) plus a couple other fixes I just couldn't leave there after seeing them :slightly_smiling_face:
**:warning: DISCLAIMER:** I don't know neither libsoup2.4 nor libsoup3. This is a uneducated guess by looking at [the scarce documentation](https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html) and the API reference. And it seems to work with limited testing (I tested manually only, for the normal case, the 404 case and the incorrect domain case -- all of which got the expected result). You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1336
-- Commit Summary --
* updatechecker: Port to libsoup3 * updatechecker: Don't leak the libsoup session * updatechecker: Avoid a deprecated call * updatechecker: Remove weird German quotes
-- File Changes --
M build/updatechecker.m4 (2) M updatechecker/README (4) M updatechecker/src/updatechecker.c (70)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1336.patch https://github.com/geany/geany-plugins/pull/1336.diff
@xiota commented on this pull request.
@@ -185,15 +191,30 @@ version_compare(const gchar *current_version)
}
-static void update_check_result_cb(SoupSession *session, - SoupMessage *msg, gpointer user_data) +static gchar *bytes_to_string(GBytes *bytes) +{ + gsize bytes_size = g_bytes_get_size(bytes); + gchar *str = g_malloc(bytes_size + 1); + memcpy(str, g_bytes_get_data(bytes, NULL), bytes_size);
I don't know any version of libsoup, but wondering why wrap `g_bytes_get_data()` with another function and memcopy that has to be freed later, rather than `g_bytes_get_data()` directly, and letting `g_bytes_unref()` take care of it.
@elextr commented on this pull request.
@@ -185,15 +191,30 @@ version_compare(const gchar *current_version)
}
-static void update_check_result_cb(SoupSession *session, - SoupMessage *msg, gpointer user_data) +static gchar *bytes_to_string(GBytes *bytes) +{ + gsize bytes_size = g_bytes_get_size(bytes); + gchar *str = g_malloc(bytes_size + 1); + memcpy(str, g_bytes_get_data(bytes, NULL), bytes_size);
Perhaps the response body might not be a nul terminated string, so its copied to one.
@xiota commented on this pull request.
@@ -185,15 +191,30 @@ version_compare(const gchar *current_version)
}
-static void update_check_result_cb(SoupSession *session, - SoupMessage *msg, gpointer user_data) +static gchar *bytes_to_string(GBytes *bytes) +{ + gsize bytes_size = g_bytes_get_size(bytes); + gchar *str = g_malloc(bytes_size + 1); + memcpy(str, g_bytes_get_data(bytes, NULL), bytes_size);
I see... thanks.
@b4n commented on this pull request.
@@ -185,15 +191,30 @@ version_compare(const gchar *current_version)
}
-static void update_check_result_cb(SoupSession *session, - SoupMessage *msg, gpointer user_data) +static gchar *bytes_to_string(GBytes *bytes) +{ + gsize bytes_size = g_bytes_get_size(bytes); + gchar *str = g_malloc(bytes_size + 1); + memcpy(str, g_bytes_get_data(bytes, NULL), bytes_size);
Yeah that's exactly the reason: the bytes have no reason to be NUL-terminated, as it's from reading the raw data from the webserver (and does not explicitly add a NUL itself from what I can gather). So this helper is to make it a C string, not really caring if there's a NUL earlier because a valid response won't have one anyway.
I don't know enough about libsoup to sensibly review (and don't have the time to learn), but since Geany uses GIO why not `g_file_new_for_uri()` and `g_file_read()` (or `g_file_read_async()/g_file_read_finish()` to not block the UI) instead of using libsoup directly?
`g_file_new_for_uri()` and `g_file_read()` (or `g_file_read_async()/g_file_read_finish()`
It works... ```C
#include <gio/gio.h> #include <stdio.h>
int main() { GFile *file = g_file_new_for_uri("https://geany.org/service/version/");
GError *error = NULL; GFileInputStream *stream = g_file_read(file, NULL, &error);
if (!error) { printf("No error.\n");
guint8 *buffer = NULL; gsize size = 0;
buffer = (guint8 *)g_malloc(32);
gboolean success = g_input_stream_read_all((GInputStream *)stream, buffer, 32, &size, NULL, &error);
if (success) { buffer[size] = '\0'; printf("Data: %s\n", buffer); } else { printf("Error reading stream.\n"); }
} else { printf("Error reading uri.\n"); }
return 0; } ```
```bash $ gcc test.c -o test $(pkgconf --libs gio-2.0) $(pkgconf --cflags gio-2.0)
$ ./test No error. Data: 2.0.0 ```
@xiota neat, and simple, although it has one theoretical bug (though unlikely in practice) [hint: what if 32 bytes were returned].
Just for general information, Geany used (a __long__ time ago) to avoid GIO, which is probably why the plugin used libsoup directly. But now GIO is required by Geany so its available to the plugin.
Size check is needed if this route is taken for the plugin... That code was intended to check whether `https://` is supported because I saw only `file://` mentioned in the docs. Typical version string is <8 bytes. Even with words like `alpha` or `pre-release`, I figured 32 bytes is enough for the test.
Unfortunately the GIO docs don't say when `g_file_new_from_URI()` and the associated stream was supported (that I could see) but it works on the machine I'm on ATM which is pretty olde.
PS I expect not everyone has your alias pkgconf == pkg-config :wink:
Unfortunately the GIO docs don't say when `g_file_new_from_URI()` and the associated stream was supported (that I could see) but it works on the machine I'm on ATM which is pretty olde.
Looks like it depends on `gvfs`... After uninstalling... ``` $ ./test Error reading uri. ```
PS I expect not everyone has your alias pkgconf == pkg-config 😉
On my computer, `pkg-config` is the symlink. Looks like [pkgconf](https://gitea.treehouse.systems/ariadne/pkgconf) and [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/) are different projects.
Yeah, `pkg-config` is the Freedesktop original, `pkgconf` would appear to be a re-implementation. Your distro installs `pkgconf` and links the original command to it so existing scripts will work, if they happen to conform to what `pkgconf` considers "correct".
If an existing script fails because it depends on some edge case in `pkg-config` tough. And very aggressive about it they are, "if someone insists on fixing such a non-bug, this constitutes a violation of our [Code of Conduct](https://gitea.treehouse.systems/ariadne/pkgconf/src/branch/master/CODE_OF_CO...), which may be addressed by banning from this repository".
I use whatever is provided by the package manager. Even on Debian, pkg-config is a dummy package that redirects to pkgconf.
Their stance doesn't seem particularly "aggressive" in context because they call out "passive-aggressive people who try to argue with us". Seems they probably had some people who opened numerous issues reporting closely related problems that they were told multiple times are not bugs. It would be like... what if someone opened multiple issues for Geany complaining that it doesn't support various Qt6 features despite being told multiple times that they aren't bugs? Eventually, those complaints could be considered intentionally disruptive, and people who "insist" on continuing need to be cut off.
Looks like it depends on gvfs... After uninstalling...
Well, IIUC GVFS is _part_ of GIO (not to be confused with GnomeVFS), so if its uninstalled its not surprising parts of GIO don't work.
But that probably means reading URLs won't work on Windows, dunno about Macos, so back to the soup I guess :stuck_out_tongue_winking_eye:
It is separate from GIO. This is the project page: https://gitlab.gnome.org/GNOME/gvfs
Debian package, appears to be `gvfs-backends`
Well, I interpret the very first words in the readme "GVfs is a userspace virtual filesystem implementation for GIO" to mean its part of GIO. IIUC it provides the implementations for the abstract file/URL/dbus stream operations in GIO and thats why you get an error if its not installed and you try to read anything other than a local file.
Never mind, its was worth a try, and thanks for writing that test program.
Someone could run the test program on windows or mac to find out. I no longer have (easy) access to either.
Yeah I guess using GIO directly for this kind of super simple GET would make sense Indeed. I also think that gvfs will indeed be part of all reasonable GIO installations, but I could be wrong.
hum… @elextr @xiota so what's your conclusion? Depend on libsoup3 as this PR because it's HTTP, or depend on a GVFS backend for HTTP?
Note that writing an async version of the feature, while reasonably easy, is a little bit more work.
See #1340 if wanted.
hum… @elextr @xiota so what's your conclusion? Depend on libsoup3 as this PR because it's HTTP, or depend on a GVFS backend for HTTP?
Waiting for https://github.com/geany/geany-plugins/pull/1340#issuecomment-2079741003
If it works `?` #1340 `:` #1336
This PR won (IMO), so it's the one to review @frlan
github-comments@lists.geany.org