Bug 233326 – [Flatpak SDK] Add build recipe for libjxl

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Adrian Perez]

'tis needed for JPEG-XL support

[Adrian Perez]

Created attachment 444743 [details]
Patch

[Adrian Perez]

(In reply to Adrian Perez from comment #1)
> Created attachment 444743 [details]
> Patch

I built the SDK locally and completed correctly =]

[EWS]

Committed r286057 (244444@main): <https://commits.webkit.org/244444@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 444743 [details].

[Radar WebKit Bug Importer]

<rdar://problem/85600724>

[Philippe Normand]

(In reply to Adrian Perez from comment #2)
> (In reply to Adrian Perez from comment #1)
> > Created attachment 444743 [details]
> > Patch
> 
> I built the SDK locally and completed correctly =]

Will you deploy it as well?

[Adrian Perez]

Reopening… the build system for libjxl gets confused by telling it to
use the system-installed libhwy (built by highway.bst) because it is a
static library used internally in the implementation of libjxl, yet it
adds it as a requirement into libjxl.pc, even when it should not be there
in that case:

  % webkit-flatpak --repo=$R -c pkg-config --cflags libjxl
  Package libhwy was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libhwy.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'libhwy', required by 'libjxl', not found
  %

It seems that the assumption is that using -DJPEGXL_FORCE_SYSTEM_HWY=ON
then the system-provided libhighway *has* to be a dynamic library and
that is why it gets added as a reqirement in libjxl.pc — I cannot find
exactly how that is done, but it looks like some internal CMake sorcery.

I am going to try a follow-up where we place the libhighway sources into
the third_party/highway/ subdir, like we already do for SkCMS and LodePNG,
and let the libjxl CMake files build it statically itself 🤷

[Adrian Perez]

Created attachment 444987 [details]
Patch

[EWS]

Committed r286127 (244514@main): <https://commits.webkit.org/244514@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 444987 [details].

[Adrian Perez]

(In reply to Philippe Normand from comment #5)
> (In reply to Adrian Perez from comment #2)
> > (In reply to Adrian Perez from comment #1)
> > > Created attachment 444743 [details]
> > > Patch
> > 
> > I built the SDK locally and completed correctly =]
> 
> Will you deploy it as well?

Done!

[Michael Catanzaro]

There are still EWS failures, e.g. https://ews-build.webkit.org/#/builders/36/builds/52314. Looks like the EWS is having trouble:

perl Tools/Scripts/update-webkitgtk-libs --release
 in dir /home/ews/worker/GTK-Build-EWS/build (timeout 1200 secs)
 watching logfiles {}
 argv: ['perl', 'Tools/Scripts/update-webkitgtk-libs', '--release']
 using PTY: False
Updating Flatpak Release environment
Looking for updates…
F: Warning: Treating remote fetch error as non-fatal since runtime/org.webkit.Sdk/x86_64/21.08 is already installed: Unable to load summary from remote webkit-sdk: Unacceptable TLS certificate
F: Warning: Can't find runtime/org.webkit.Sdk/x86_64/21.08 metadata for dependencies: Unable to load metadata from remote webkit-sdk: summary fetch error: Unacceptable TLS certificate
F: Warning: Treating remote fetch error as non-fatal since runtime/org.webkit.Sdk.Locale/x86_64/21.08 is already installed: Unable to load summary from remote webkit-sdk: Unacceptable TLS certificate
F: Warning: Can't find runtime/org.webkit.Sdk.Locale/x86_64/21.08 metadata for dependencies: Unable to load metadata from remote webkit-sdk: summary fetch error: Unacceptable TLS certificate
F: Warning: Treating remote fetch error as non-fatal since runtime/org.webkit.Sdk.Debug/x86_64/21.08 is already installed: Unable to load summary from remote webkit-sdk: Unacceptable TLS certificate
F: Warning: Can't find runtime/org.webkit.Sdk.Debug/x86_64/21.08 metadata for dependencies: Unable to load metadata from remote webkit-sdk: summary fetch error: Unacceptable TLS certificate
F: Warning: Treating remote fetch error as non-fatal since runtime/org.webkit.Platform/x86_64/21.08 is already installed: Unable to load summary from remote webkit-sdk: Unacceptable TLS certificate
F: Warning: Can't find runtime/org.webkit.Platform/x86_64/21.08 metadata for dependencies: Unable to load metadata from remote webkit-sdk: summary fetch error: Unacceptable TLS certificate
F: Warning: Treating remote fetch error as non-fatal since runtime/org.webkit.Platform.Locale/x86_64/21.08 is already installed: Unable to load summary from remote webkit-sdk: Unacceptable TLS certificate
F: Warning: Can't find runtime/org.webkit.Platform.Locale/x86_64/21.08 metadata for dependencies: Unable to load metadata from remote webkit-sdk: summary fetch error: Unacceptable TLS certificate
Nothing to do.

[Adrian Perez]

It's related to the recent Let's Encrypt certificate that was revoked,
which is preventing some bots from fetching an updated SDK — nothing
to do with libjxl itself. Right now I'm doing a sweep of all the bots
we maintain to make sure they can fetch content from hosts which use
LE certificates.

[Michael Catanzaro]

(In reply to Adrian Perez from comment #11)
> It's related to the recent Let's Encrypt certificate that was revoked

I doubt anything was revoked. Surely it must be https://letsencrypt.org/2021/10/01/cert-chaining-help.html?

Apparently WebKitGTK is super broken in Ubuntu 20.04 right now because -- amazingly -- Ubuntu never updated GnuTLS the last time this happened during summer 2020. It's just been broken for 1.5 years without anybody noticing, or at least without anybody bothering to report it to us. Just discovered that in https://gitlab.gnome.org/GNOME/glib-networking/-/issues/177#note_1311945. That's *very* concerning. But I think our EWS run on Debian, right, which should be unaffected because Debian was patched right away. And OpenSSL has been able to handle this chain since OpenSSL 1.1, which is pretty old. So it's hard to guess what is going wrong for the EWS tbh.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #12)
> (In reply to Adrian Perez from comment #11)
> > It's related to the recent Let's Encrypt certificate that was revoked
> 
> I doubt anything was revoked. Surely it must be
> https://letsencrypt.org/2021/10/01/cert-chaining-help.html?

Revoked, chain changed... potato, potatoeh 🤷‍♂️️

> Apparently WebKitGTK is super broken in Ubuntu 20.04 right now because --
> amazingly -- Ubuntu never updated GnuTLS the last time this happened during
> summer 2020. It's just been broken for 1.5 years without anybody noticing,
> or at least without anybody bothering to report it to us. Just discovered
> that in
> https://gitlab.gnome.org/GNOME/glib-networking/-/issues/177#note_1311945.
> That's *very* concerning.

Ouch.

> But I think our EWS run on Debian, right, which
> should be unaffected because Debian was patched right away. And OpenSSL has
> been able to handle this chain since OpenSSL 1.1, which is pretty old. So
> it's hard to guess what is going wrong for the EWS tbh.

They run Debian and that would be good if the patches would have been
installed (hint: guess of often bots get updated, given that we don't
care much about the system because we ship another full system in the
Flatpak SDK…)

Anyhoo, all is working now 🛠️