Bug#931052: unblock: webkit2gtk/2.24.2-2

[Paul Gevers]

reassign 931052 release-notes
retitle 931052 webkit2gtk not supported on non-sse2 i386 hardware
user ***@packages.debian.org
usertags 931052 - unblock
thanks

Hi Alberto,

Please unblock package webkit2gtk
Upstream WebKitGTK has recently stopped supporting i386 CPUs without
SSE2 extensions, as other browsers (Chromium, Firefox) already did a
few years ago.
There is at least one bug report (#930932, opened two days ago) from a
user that cannot run Zenity on a machine with an Athlon XP CPU because
of this, and some hours ago bug #930935 was filed against webkit2gtk.
WebKit generates SSE2 instructions with its JIT compiler, and the
build scripts also force gcc to pass the -msse2 compilation flags.
This upload disables the JIT compiler and enables the CLoop JavaScript
interpreter, which is slower but works on all CPUs. It also removes
the gcc SSE2 flags. Only the i386 build is affected by these changes.
Debdiff attached.
Note: the changelog includes the list of CVEs from the latest security
advisory, published shortly after the previous release. This is purely
informative and has no effects on the package.
unblock webkit2gtk/2.24.2-2

We like to support non-sse2 on i386, but we are not comfortable fixing
webkit2gtk at this stage of the release. Therefore, we will not unblock
this change, but we want the release notes to mention this, so users are
warned.

Paul

[Debian Bug Tracking System]

Post by Paul Gevers
reassign 931052 release-notes

Bug #931052 [release.debian.org] unblock: webkit2gtk/2.24.2-2
Bug reassigned from package 'release.debian.org' to 'release-notes'.
Ignoring request to alter found versions of bug #931052 to the same values previously set
Ignoring request to alter fixed versions of bug #931052 to the same values previously set

Post by Paul Gevers
retitle 931052 webkit2gtk not supported on non-sse2 i386 hardware

Bug #931052 [release-notes] unblock: webkit2gtk/2.24.2-2
Changed Bug title to 'webkit2gtk not supported on non-sse2 i386 hardware' from 'unblock: webkit2gtk/2.24.2-2'.

Post by Paul Gevers
usertags 931052 - unblock

Usertags were: unblock.
Usertags are now: .

Post by Paul Gevers
thanks

Stopping processing here.

Please contact me if you need assistance.

[Alberto Garcia]

Post by Paul Gevers
We like to support non-sse2 on i386, but we are not comfortable
fixing webkit2gtk at this stage of the release. Therefore, we will
not unblock this change, but we want the release notes to mention
this, so users are warned.

Ok, note that the plan is to offer webkit2gtk security updates during
the buster lifetime, so the first of those updates will anyway work on
non-sse2 i386 CPUs.

Berto

[Adrian Bunk]

Post by Paul Gevers
reassign 931052 release-notes
retitle 931052 webkit2gtk not supported on non-sse2 i386 hardware
...
We like to support non-sse2 on i386, but we are not comfortable fixing
webkit2gtk at this stage of the release.

Why is this relatively small change a problem in a package where
new upstream versions are permitted after the release of stable?

Doing a change in 2.24.2-2 prior to the release sounds less risky than
uploading the same change as part of 2.24.3-1~deb10u1 to buster-pu.

Post by Paul Gevers
Therefore, we will not unblock
this change, but we want the release notes to mention this, so users are
warned.

This means the default desktop is expected to have crashes due to this.

Many standalone applications like liferea or zenity (#930932)
are also expected to crash.

Please mention in all buster announcements that users on non-SSE i386
should defer upgrading from stretch until this is fixed in the next
point release of buster.

Post by Paul Gevers
Paul

cu
Adrian

[Alberto Garcia]

Post by Paul Gevers
We like to support non-sse2 on i386, but we are not comfortable
fixing webkit2gtk at this stage of the release.

Why is this relatively small change a problem in a package where new
upstream versions are permitted after the release of stable?

I'll try to explain again with more detail so we all understand the
nature of the proposed changes.

- WebKitGTK has several mechanisms to run JavaScript code, in brief: a
C-based interpreter (CLoop), an assembler-based interpreter and a
JIT compiler.

- CLoop is the slowest but it is portable and runs in all platforms.
It's the one selected at build time when the CPU is unsupported or
unknown.

- The other two generate CPU-specific code. In an effort to simplify
them upstream took recently the decision to stop supporting i386
processors without SSE2 instructions.

- Because of that, WebKitGTK 2.24.1 added a build-time check to detect
if the compiler can generate SSE2 instructions. For the Debian case
I had to add -msse2 -mfpmath=sse to CFLAGS, as suggested by
upstream.

- The consequence of this is that GCC generates SSE2 instructions when
appropriate when compiling regular C/C++ code, causing crashes like
the one previously reported.

- However, and this is the part that I originally overlooked, only the
C-based interpreter is working at the moment in i386. The other two
are less actively maintained for i386, and stopped working after
some big changes upstream in the last few months.

- So it is possible to remove the compile-time check for SSE2 and
build the package without those flags in i386.

What this all means is that the only real difference between
webkit2gtk 2.24.2-1 (in buster) and 2.24.2-2 (in sid) is that, for
i386, the former is compiled with -msse2 -mfpmath=sse and the latter
is not. So for floating point operations the former uses SSE2 and the
latter uses x87. This produces some differences in rounding in some
corner cases which could have user-visible consequences.

We don't know when it is going to happen, but once upstream brings
back JIT support to i386 again we would have to make the decision to
either:

a) keep using CLoop in order to remain compatible with non-SSE2 CPUs
(conservative approach, I'd probably support this one).

b) think of a way to support both sets of users so those with more
modern processors can benefit from the additional performance of
the JIT compiler. This could involve using e.g. /usr/lib/sse2/ for
those binaries.

I hope this clarifies the situation.

Berto

[Paul Gevers]

Hi all,

Post by Paul Gevers
We like to support non-sse2 on i386, but we are not comfortable fixing
webkit2gtk at this stage of the release. Therefore, we will not unblock
this change, but we want the release notes to mention this, so users are
warned.

I cooked up the attached proposal for the release notes. Reviews very
welcome.

@Alberto, did you have any intention to upload to backports once buster
is released? If so, do you think it is OK to mention this in the
release-notes?

Paul

[Alberto Garcia]

Post by Paul Gevers

Post by Paul Gevers
We like to support non-sse2 on i386, but we are not comfortable fixing
webkit2gtk at this stage of the release. Therefore, we will not unblock
this change, but we want the release notes to mention this, so users are
warned.

I cooked up the attached proposal for the release notes. Reviews
very welcome.
@Alberto, did you have any intention to upload to backports once
buster is released? If so, do you think it is OK to mention this in
the release-notes?

Yes, my plan is to publish backports of every stable WebKitGTK
release. I have been doing it for stretch without problems for the
last couple of years.

Berto

[Alberto Garcia]

Post by Alberto Garcia

Post by Paul Gevers
@Alberto, did you have any intention to upload to backports once
buster is released? If so, do you think it is OK to mention this
in the release-notes?

Yes, my plan is to publish backports of every stable WebKitGTK
release. I have been doing it for stretch without problems for the
last couple of years.

I'll elaborate a bit more:

- The next upload that goes to buster (either via backports or any
other means) will support non-SSE2 CPUs. It's most likely going to
be a backport of 2.24.2-2.

- WebKitGTK upstream has a dependency policy according to which the
package is supported in Debian stable until one year after the
release of the next major version. So stretch is supported until
summer 2020 and buster until one year after bullseye.

https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

- When upstream publishes a new version I upload it to unstable
typically on the same day, and to stable-backports as soon as
the package hits testing. stretch-backports has always had an
up-to-date version of webkit2gtk, and I plan to do the same for
buster-backports (and for stretch-backports as long as it works).

- In addition to that we are also having buster-security updates of
webkit2gtk for the first time. However we are not cherry-picking
security fixes, we will be using the latest upstream stable release
(the same that goes to buster-backports, actually). My plan is to
delay the security updates for some days in order to have time to
test them and detect regressions.

One may argue that it's a bit pointless to have the same upstream
releases going to buster-backports and buster-security, but the former
will also receive updates that don't contain security fixes and will
generally be less conservative with the timings.

Berto

[Justin B Rye]

+ <section id="webkit2gtk-on-non-sse2" arch="i386">
+ <title>Initially no support for WebKitGTK based applications on non-SSE2

<title>No initial support for WebKitGTK-based applications on non-SSE2

Or maybe just

<title>WebKitGTK (initially) requires SSE2 support</title>

And how are we deciding when it's "WebKitGTK" and when it's
"webkit2gtk"? Bear in mind that users have no easy way of mapping
from the name of a source package to the name of the specific library
they might or might not have installed.

+ systems</title>
+ <para>
+ Due to changes in the upstream code, <systemitem
+ role="package">webkit2gtk</systemitem> has been built with SSE2
+ support. The changes in the Debian code came too late to be incorporated

Surely the change is that it now *lacks* support for *non*-SSE2
systems? Or you could say that it has been built with a dependency
on SSE2 support. Or:

role="package">webkit2gtk</systemitem> has been built requiring SSE2
support. Fixes for this in the Debian code came too late to be incorporated

+ in the initial buster release. This means that systems that don't have
+ SSE2 support build into their CPU can't run applications which use

s/build/built/

+ WebKitGTK, e.g. <systemitem role="package">liferea</systemitem> or
+ <systemitem role="package">zenity</systemitem>. These applications will
+ crash, most likely with an <literal>Illegal instruction</literal> error
+ message. It is expected that <systemitem
+ role="package">webkit2gtk</systemitem> will support these older systems
+ after the first update of <systemitem
+ role="package">webkit2gtk</systemitem> in either a point release or
+ security update.

This is also a bit short on concrete advice for users. Could we add
something like

Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

None of my machines are this ancient, but "dpkg -l | grep -i webkit"
gives no output, so I would be safe anyway - right?

+ </para>
+ </section>
+
<section id="noteworthy-obsolete-packages" condition="fixme">
<title>Noteworthy obsolete packages</title>
<para>

[Paul Gevers]

Hi Justin,

Post by Justin B Rye
And how are we deciding when it's "WebKitGTK" and when it's
"webkit2gtk"? Bear in mind that users have no easy way of mapping
from the name of a source package to the name of the specific library
they might or might not have installed.

To be honest, I don't know. Feeling?

Post by Justin B Rye
This is also a bit short on concrete advice for users.

I see.

Post by Justin B Rye
Could we add
something like
Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

Reading again bug 930935 it seems that there are still devices in
production, so age isn't a good qualifier. I put it in because it seems
I don't have much inspiration for this at this moment.

Post by Justin B Rye
None of my machines are this ancient, but "dpkg -l | grep -i webkit"
gives no output, so I would be safe anyway - right?

Close. https://tracker.debian.org/pkg/webkit2gtk shows that there is
also javascriptcoregtk to grep.

How about the attached version?

Paul

[Justin B Rye]

Post by Paul Gevers

Post by Justin B Rye
And how are we deciding when it's "WebKitGTK" and when it's
"webkit2gtk"? Bear in mind that users have no easy way of mapping
from the name of a source package to the name of the specific library
they might or might not have installed.

To be honest, I don't know. Feeling?

The trouble with talking about WebKitGTK is that besides
libwebkit2gtk-* there are also a couple of packages like
libwebkitgtk3.0-cil that look as if they'd be relevant to this but
aren't. Maybe we should only mention "webkit2gtk", which turns out
after all to be fairly transparently connected to the name of the main
library packages it builds (even if the -gtk2 suffix on one of them is
a bit mystifying).

Post by Paul Gevers

Post by Justin B Rye
This is also a bit short on concrete advice for users.

I see.

Post by Justin B Rye
Could we add
something like
Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

Reading again bug 930935 it seems that there are still devices in
production, so age isn't a good qualifier. I put it in because it seems
I don't have much inspiration for this at this moment.

I was thinking about mentioning both

dpkg -l | grep -i webkit2gtk

and grep sse2 /proc/cpuinfo

or combining them and saying to check if you get any output from

grep -q sse2 /proc/cpuinfo || dpkg -l | grep -i webkit2gtk

But maybe that's going too far.

Post by Paul Gevers

Post by Justin B Rye
None of my machines are this ancient, but "dpkg -l | grep -i webkit"
gives no output, so I would be safe anyway - right?

Close. https://tracker.debian.org/pkg/webkit2gtk shows that there is
also javascriptcoregtk to grep.

It looks like the only way I'd have that is if I had manually
installed it to support some sort of local JavaScript GUI, and I'm
hoping I would remember writing one of those.

Post by Paul Gevers
How about the attached version?
Paul
diff --git a/en/issues.dbk b/en/issues.dbk
index cdf71c12..6f56d9d7 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -288,6 +288,32 @@ $ sudo update-initramfs -u
</para>
</section>
+ <section id="webkit2gtk-on-non-sse2" arch="i386">
+ <title>WebKitGTK (initially) requires SSE2 support</title>

Maybe "Webkit2gtk", or then again maybe just "WebKit".

Post by Paul Gevers
+ <para>
+ Due to changes in the upstream code, <systemitem
+ role="package">webkit2gtk</systemitem> has been built requiring SSE2
+ support. Fixes for this in the Debian code came too late to be
+ incorporated in the initial buster release. This means that systems that
+ don't have SSE2 support built into their CPU can't run applications which
+ use WebKitGTK, e.g. <systemitem role="package">liferea</systemitem> or

Here it might say "applications that depend on <systemitem
role="package">libwebkit2gtk-*</systemitem>"?

Post by Paul Gevers
+ <systemitem role="package">zenity</systemitem>. These applications will
+ crash, most likely with an <literal>Illegal instruction</literal> error
+ message.
+ </para>
+ <para>
+ It is expected that <systemitem role="package">webkit2gtk</systemitem>
+ will support these older systems after the first update of <systemitem
+ role="package">webkit2gtk</systemitem> in either a point release or

Simplifying:

The first update of <systemitem role="package">webkit2gtk</systemitem> is
expected to restore support for these older systems, in either a point
release or

Post by Paul Gevers
+ security update. Users of a modern desktop environment with older
+ (roughly, pre-Pentium IV) CPUs may wish to delay upgrading until then.
+ It is also intended that the buster-backports archive will receive an
+ updated package once that archive opens up for uploads, so an alternative
+ could be to install <systemitem role="package">webkit2gtk</systemitem>
+ from there once it's available.
+ </para>
+ </section>
+
<section id="noteworthy-obsolete-packages" condition="fixme">
<title>Noteworthy obsolete packages</title>
<para>

[Alberto Garcia]

Post by Justin B Rye

Post by Paul Gevers

Post by Justin B Rye
And how are we deciding when it's "WebKitGTK" and when it's
"webkit2gtk"? Bear in mind that users have no easy way of
mapping from the name of a source package to the name of the
specific library they might or might not have installed.

To be honest, I don't know. Feeling?

The trouble with talking about WebKitGTK is that besides
libwebkit2gtk-* there are also a couple of packages like
libwebkitgtk3.0-cil that look as if they'd be relevant to this but
aren't.

Packages named *webkitgtk* (without the '2') refer to the previous API
of WebKitGTK. That's no longer supported and it is not available in
buster, all packages depending on the old webkitgtk have either been
removed or they switched to webkit2gtk.

Post by Justin B Rye
Maybe we should only mention "webkit2gtk", which turns out after all
to be fairly transparently connected to the name of the main library
packages it builds (even if the -gtk2 suffix on one of them is a bit
mystifying).

I think so, plus if you a package named *webkit2gtk* then you
directly or indirectly depend on libwebkit2gtk-4.0-37 and
libjavascriptcoregtk-4.0-18, so you are affected.

Post by Justin B Rye

Post by Paul Gevers

Post by Justin B Rye
Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

Reading again bug 930935 it seems that there are still devices in
production, so age isn't a good qualifier. I put it in because it
seems I don't have much inspiration for this at this moment.

Maybe you can mention "embedded CPUs", which seem to be the other type
of CPUs without SSE2 (e.g. AMD Geode).

Post by Justin B Rye

Post by Paul Gevers
Close. https://tracker.debian.org/pkg/webkit2gtk shows that there
is also javascriptcoregtk to grep.

It looks like the only way I'd have that is if I had manually
installed it to support some sort of local JavaScript GUI, and I'm
hoping I would remember writing one of those.

There's also a command-line javascript interpreter (installed in the
-bin) package.

Post by Justin B Rye

Post by Paul Gevers
+ <section id="webkit2gtk-on-non-sse2" arch="i386">
+ <title>WebKitGTK (initially) requires SSE2 support</title>

Maybe "Webkit2gtk", or then again maybe just "WebKit".

I wouldn't say just "WebKit", there are other WebKit ports (in
particular the Qt one is in stretch and buster).

Berto

[Justin B Rye]

Post by Alberto Garcia

Post by Justin B Rye
The trouble with talking about WebKitGTK is that besides
libwebkit2gtk-* there are also a couple of packages like
libwebkitgtk3.0-cil that look as if they'd be relevant to this but
aren't.

Packages named *webkitgtk* (without the '2') refer to the previous API
of WebKitGTK. That's no longer supported and it is not available in
buster, all packages depending on the old webkitgtk have either been
removed or they switched to webkit2gtk.

Don't forget, the people who need to be able to guess how all this
fits together are the ones still running stretch.

Post by Alberto Garcia

Post by Justin B Rye
Maybe we should only mention "webkit2gtk", which turns out after all
to be fairly transparently connected to the name of the main library
packages it builds (even if the -gtk2 suffix on one of them is a bit
mystifying).

I think so, plus if you a package named *webkit2gtk* then you
directly or indirectly depend on libwebkit2gtk-4.0-37 and
libjavascriptcoregtk-4.0-18, so you are affected.

Missing verb. "Have installed"?

Post by Alberto Garcia

Post by Justin B Rye

Post by Paul Gevers

Post by Justin B Rye
Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

Reading again bug 930935 it seems that there are still devices in
production, so age isn't a good qualifier. I put it in because it
seems I don't have much inspiration for this at this moment.

Maybe you can mention "embedded CPUs", which seem to be the other type
of CPUs without SSE2 (e.g. AMD Geode).

Maybe "older or embedded CPUS such as Pentium III or Geode". Also
perhaps I should move this line earlier.

Post by Alberto Garcia

Post by Justin B Rye

Post by Paul Gevers
Close. https://tracker.debian.org/pkg/webkit2gtk shows that there
is also javascriptcoregtk to grep.

It looks like the only way I'd have that is if I had manually
installed it to support some sort of local JavaScript GUI, and I'm
hoping I would remember writing one of those.

There's also a command-line javascript interpreter (installed in the
-bin) package.

Post by Justin B Rye

Post by Paul Gevers
+ <section id="webkit2gtk-on-non-sse2" arch="i386">
+ <title>WebKitGTK (initially) requires SSE2 support</title>

Maybe "Webkit2gtk", or then again maybe just "WebKit".

I wouldn't say just "WebKit", there are other WebKit ports (in
particular the Qt one is in stretch and buster).
Berto

Here's another try.

[Paul Gevers]

Hi Justin,

Post by Paul Gevers
+ It is also intended that the buster-backports archive will receive an
+ updated package once that archive opens up for uploads, so an alternative
+ could be to install <systemitem role="package">webkit2gtk</systemitem>
+ from there once it's available.

Obviously this is wrong advice (yes I know, I wrote it). There is no
binary package with that name, only the source package. Hence the advice
should be different, except I don't know how to phrase that well, as
there are 10 possible binary packages. I guess
libjavascriptcoregtk-4.0-dev, ibwebkit2gtk-4.0-dev and
libwebkit2gtk-4.0-doc are not relevant to mention, but still.

Paul

[Justin B Rye]

Post by Paul Gevers

Post by Paul Gevers
+ It is also intended that the buster-backports archive will receive an
+ updated package once that archive opens up for uploads, so an alternative
+ could be to install <systemitem role="package">webkit2gtk</systemitem>
+ from there once it's available.

Obviously this is wrong advice (yes I know, I wrote it). There is no
binary package with that name, only the source package. Hence the advice
should be different, except I don't know how to phrase that well, as
there are 10 possible binary packages. I guess
libjavascriptcoregtk-4.0-dev, ibwebkit2gtk-4.0-dev and
libwebkit2gtk-4.0-doc are not relevant to mention, but still.

We could avoid the issue by trimming it right down to:

would be to install updated packages from there once available.

[Debian Bug Tracking System]

Your message dated Sun, 30 Jun 2019 16:08:43 +0200
with message-id <d18a796d-42e0-0e36-f5d3-***@debian.org>
and subject line Re: Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware
has caused the Debian Bug report #931052,
regarding webkit2gtk not supported on non-sse2 i386 hardware
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)