Paul Gevers wrote:
> Justin B Rye wrote:
>> 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).
>> This is also a bit short on concrete advice for users.
>
> I see.
>
>> 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.
>> 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.
> 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".
> + <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>"?
> + <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
> + 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>
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
