Your message dated Mon, 5 Oct 2026 21:27:33 +0200
with message-id <[email protected]>
and subject line Re: Bug#1146094: upstream's Valgrind suppressions and debugger
helpers should be available in a package
has caused the Debian Bug report #1146094,
regarding upstream's Valgrind suppressions and debugger helpers should be
available in a package
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.)
--
1146094: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146094
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: webkit2gtk
Version: 2.52.6-1
Severity: minor
Tags: upstream
I have discovered from reading
https://docs.webkit.org/Build%20%26%20Debug/DebuggingOnTheCommandLine.html that
WebKit, like many major projects, has Python scripts for GDB and LLDB to
enhance the experience of debugging WebKit. For example the GDB one provides
"pretty-printers" for WebKit data structures. This can be found at
https://github.com/WebKit/WebKit/blob/main/Tools/gdb/webkit.py and it ought to
be available in a Debian package of some kind. This should be installed in a
way so that GDB can discover it.
GDB on Debian says
> List of directories from which to load auto-loaded scripts is
> $debugdir:$datadir/auto-load.
> The directory where separate debug symbols are searched for is
> "/usr/lib/debug".
> GDB's data directory is "/usr/share/gdb".
For Python in particular
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Python.html says
> Python scripts used by GDB should be installed in data-directory/python,
> where data-directory is the data directory as determined at GDB startup (see
> Data Files).
Therefore this webkit.py file should be available at
/usr/share/gdb/python/webkit.py for example. I would double-check if this is
still best practice, because as I will describe, other Debian packages handle
this differently.
The way that some other Debian packages are doing this is by installing the
script so that it has a name corresponding to the shared object it is intended
to affect, and therefore GDB can pick up on them:
libc6-dev:amd64: /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libc.so.6-gdb.py
libgstreamer1.0-dev:amd64:
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2602.0-gdb.py
libglib2.0-dev:amd64:
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8400.4-gdb.py
libglib2.0-dev:amd64:
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.8400.4-gdb.py
This convention is documented at
https://sourceware.org/gdb/current/onlinedocs/gdb.html/objfile_002dgdbdotext-file.html
An alternative option, to prevent having multiple copies of the same script, is
to use a special ELF section in the shared objects to tell GDB about a path
that can be used to *access* the Python script in the source tree. This is
articulated at
https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005fscripts-section.html
One could set the .debug_gdb_scripts ELF section to reference
Tools/gdb/webkit.py for example, and then someone debugging WebKitGTK on Debian
and who has the source tree handy may pick that up. Note that this is less
helpful in Debian, as our debuginfod instance isn't capable of serving source
files at the moment. It's also possible to use the ELF section to include the
GDB script directly, which is appealing since it's not very long on this
occasion. (The LLDB code at
https://github.com/WebKit/WebKit/tree/main/Tools/lldb looks much more involved.)
Upstream also has a Valgrind suppressions file
https://github.com/WebKit/WebKit/blob/main/Tools/Scripts/valgrind/suppressions.txt
which will be helpful to folks developing WebKitGTK applications on Debian,
and which should likewise be installed at a canonical system-wide location so
it can be used easily by folks who don't know they need it yet.
The biggest hurdle here is that none of these files are shipped in the
WebKitGTK source tarball that is generated. Perhaps folks using these features
so far are mostly doing new development on WebKit itself from a Git checkout,
and making these helpers installable by downstream distributors hasn't been a
priority. In Debian it's normal to package these files, and we should do so,
somehow.
-- System Information:
Debian Release: 13.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.101+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
tags 1146094 wontfix
thanks
On Sat, Aug 29, 2026 at 05:42:40PM +0000, John Scott wrote:
> > The biggest hurdle here is that none of these files are shipped
> > in the WebKitGTK source tarball that is generated. Perhaps folks
> > using these features so far are mostly doing new development on
> > WebKit itself from a Git checkout
> Yes, everyone working on the project uses a Git checkout because
> (among other things) it comes with a lot of development tools and
> scripts that are essential to the workflow. The source tarballs are
> only meant for downstreams to build their own binaries.
Due to these reasons I don't think it's very realistic to do this, so
I'm closing this bug.
Regards,
Berto
--- End Message ---
