dev-libs/libgweather: Version bump to 4.2.0

[Schievel1]

• Needs geocode-glib:2 from sci-geosciences/gnome-maps: version bump to 43.0, net-libs/librest: version bump to 0.9.1, media-libs/libshumate: new package v 1.0.1, sci-geosciences/geocode-glib: new slot for libsoup3 #27383 to be merged first

Signed-off-by: Pascal Jäger pascal.jaeger@leimstift.de

[gentoo-bot]

Pull Request assignment

Submitter: @Schievel1
Areas affected: ebuilds
Packages affected: dev-libs/libgweather

dev-libs/libgweather: @gentoo/gnome

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-09-21 12:17 UTC
Newest commit scanned: 1d99640
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/f7454455bb/output.html

[mattst88]

Looks like libgweather / metar passes with FEATURES=-network-sandbox and fails otherwise. We should disable the test in src_prepare if network-sandbox is enabled like how I did in 3cc70d9.

[mattst88]

Hm, I'm not sure what to do about the -Dsoup2 option. I think we'll need to set -Dsoup2=false, but that's irritating because regardless of the option it produces the same libgweather-4.so.0.200.0, so we cannot slot it.

Related, I see a test fails to compile when building with -Dsoup2=false.

../libgweather-4.2.0/libgweather/tests/metar.c: In function ‘test_metar_weather_stations’:
../libgweather-4.2.0/libgweather/tests/metar.c:136:19: error: invalid use of incomplete typedef ‘SoupMessage’ {aka ‘struct _SoupMessage’}
  136 |     } else if (msg->status_code == SOUP_STATUS_CANT_RESOLVE) {
      |                   ^~
../libgweather-4.2.0/libgweather/tests/metar.c:136:36: error: ‘SOUP_STATUS_CANT_RESOLVE’ undeclared (first use in this function); did you mean ‘SOUP_STATUS_BAD_REQUEST’?
  136 |     } else if (msg->status_code == SOUP_STATUS_CANT_RESOLVE) {
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~
      |                                    SOUP_STATUS_BAD_REQUEST
../libgweather-4.2.0/libgweather/tests/metar.c:136:36: note: each undeclared identifier is reported only once for each function it appears in

Looks like SOUP_STATUS_CANT_RESOLVE is defined only by libsoup:2.4 and not by libsoup:3.0.

/usr/include/libsoup-2.4/libsoup/soup-status.h:	SOUP_STATUS_CANT_RESOLVE,

but I don't seem to be able to get the build to fail if I build outside of portage...?

Oh! It's our 4.0.0-autoskip-network-test.patch patch that adds that /o\

[mattst88]

Looks like libgweather / metar passes with FEATURES=-network-sandbox and fails otherwise. We should disable the test in src_prepare if network-sandbox is enabled like how I did in 3cc70d9.

Heh, since the metar test is failing in v4.0.0 even with this patch applied, I think we really should disable it if FEATURES=network-sandbox.

[mattst88]

Let's add this to the end of src_prepare and not apply the .patch file:

+       # The metar test requires network access
+       if has network-sandbox ${FEATURES}; then
+               sed -i -e '/metar/d' libgweather/tests/meson.build || die
+       fi

[mattst88]

I think we're basically forced to go for -Dsoup2=false.

[mattst88]

Ugh, maybe we need to make it a USE flag that packages can depend on. Otherwise e.g. evolution-data-server-3.44 (which uses libsoup:2.4) and evolution-data-server-3.46 (which uses libsoup:3.0) are going to have to have very strange version dependencies. @leio: thoughts?

[Schievel1]

I did that with the use flag for now. We still need to backtrack the packages that depend on it, if we decide for the USE-flag solution

[leio]

I think this is a in-sync update case, if possible:

We have all libsoup-2 + libgweather consumers require older libgweather than we make the switch for and then when we switch a consumer over, we raise its libgweather dependency to require at minimum the version that we switched over to libsoup-3. So basically preparing the tree by adding <libgweather-4.2 to existing libgweather:4 deps. Presumably libgweather:2 is unaffected by this and we probably don't have THAT many libgweather:4 consumers so far.
We might want to deliver the newer version for libsoup-2.4 one last time too and switch it over to libsoup-3 in a -r10 or so, but might be not worth it.

[mattst88]

iwdevtools says we're missing a dep on dev-libs/json-glib and indeed I see it in libgweather/meson.build.

[Schievel1]

Looks like the ebuilds changed in the meantime. When we agreed on how we handle this soup2/soup3 thing I will sort it out

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-09-29 21:28 UTC
Newest commit scanned: 4d16efc
Status: ❌ broken

New issues caused by PR:
https://qa-reports.gentoo.org/output/gentoo-ci/ea4de72b3b/output.html#dev-libs/libgweather

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/ea4de72b3b/output.html