Your message dated Fri, 17 Jul 2026 10:37:26 +0200
with message-id <[email protected]>
and subject line Re: Bug#1130768: use the libjs-pdf package instead of in-tree
bundled blobs
has caused the Debian Bug report #1130768,
regarding use the libjs-pdf package instead of in-tree bundled blobs
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 [email protected]
immediately.)
--
1130768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130768
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: webkit2gtk
Severity: normal
User: [email protected]
Usertags: source-contains-prebuilt-javascript-object
X-Debbugs-Cc: [email protected]
Right now WebKitGTK uses Mozilla's PDF.js and keeps it in the source tree at
Source/ThirdParty/pdfjs/. The README.webkit file there says:
> Because the build process for PDF.js depends on a large number of Node.js
> dependencies, we choose to build from upstream's prebuilt "dist" releases
> rather than the original source code.
> This is not ideal and possibly violates the packaging requirements of most
> major Linux distributions. However, requiring a huge number of Node.js
> packages would surely result in most distributions disabling the PDF support
> altogether.
Has that obstacle been surmounted? Debian has a libjs-pdf package already, and
by using that any doubt about the wholesomeness of these bundled sources can be
alleviated. The contents of /usr/share/javascript/pdf/ look like they
correspond to this WebKit subdirectory. The README.webkit file does specify
steps to update the bundled PDF.js but there don't seem to be patches or
meaningful changes; it's more for the sake of tidyness, it seems. The packaged
version of PDF.js ought to work without tweaks.
To be honest, I can't find which WebKit binary package(s) get this copy of
PDF.js bundled into them or where they are. The remaining choice is whether
WebKit should use the installed libjs-pdf at runtime, or whether to use
libjs-pdf at build-time and have those artifacts folded into the binary package.
The latter would probably be very easy, maybe replacing the files in
Source/ThirdParty/pdfjs/ with symlinks to the system-wide files so the build
process will use those. Our WebKit package may need to set Built-Using or
Static-Built-Using depending on particular details of licenses and such.
In principle it would be nice if WebKit could simply use what's in
/usr/share/javascript/ directly, similar to how system-wide WebExtensions work.
This would probably need upstream coordination and since I can't even find
where PDF.js is lurking in the binaries now, this is kind of out of the
question.
Has this been brought up before? I couldn't find a bug, but it looks like we're
very fortunate to have PDF.js already in Debian and a clear set of instructions
for substituting our version for theirs.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
tags 1130768 wontfix
thanks
> the version of PDF.js shipped by Debian (2.14.305, from 2022) is
> quite outdated compared to the one shipped by WebKit (4.1.392,
> 2024), so this would be a downgrade.
>
> In this situation I don't think that this is a good idea.
Closing this bug.
Berto
--- End Message ---
