Bug#857271: libglib2.0-dev: Not all architectures contain the /usr/share/glib2.0/gdb/*.py files

[Simon McVittie]

On Thu, 09 Mar 2017 at 20:11:03 +0900, Mike Hommey wrote:
> I was surprised not to find the /usr/share/glib2.0/gbg/*py files on my
> machine where libglib2.0-dev, while it's there on another machine that
> is on stable.

The gdb hooks were meant to be in libglib2.0-dev in jessie. They were
intentionally moved to libglib2.0-0-dbg in stretch/sid, and I moved them
back to libglib2.0-dev for experimental. So if you would have expected to
find them in the -dev, I suppose we could say this is a bug in sid that
has been fixed in experimental? :-)

In a way libglib2.0-0-dbg makes more sense, because if you plan to debug
GLib with gdb you should really have its debug symbols; but I wanted
to use -dbgsym, keeping libglib2.0-0-dbg just for the gdb hooks
seemed wasteful, and recent changes to the packaging of the -dev meant
that it could be Multi-Arch: same (so you can still debug more than
one architecture of GLib on the same machine if you want to).

The filenames of the "library" parts of the gdb hooks have changed
between glib.py/gobject.py and glib_gdb.py/gobject_gdb.py at some
point between jessie and stretch, presumably to avoid confusion with
python-gobject. The part that is actually directly loaded by gdb (and
so needs to have a particular name) is libwhatever.so.whatever-gdb.py.

As arbitrary examples, the amd64 and arm64 file lists for sid seem fine:

https://packages.debian.org/sid/amd64/libglib2.0-0-dbg/filelist
...
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.3-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3-gdb.py
/usr/share/glib-2.0/gdb/glib_gdb.py
/usr/share/glib-2.0/gdb/gobject_gdb.py

https://packages.debian.org/sid/arm64/libglib2.0-0-dbg/filelist
...
/usr/share/gdb/auto-load/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.5000.3-gdb.py
/usr/share/gdb/auto-load/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.5000.3-gdb.py
/usr/share/glib-2.0/gdb/glib_gdb.py
/usr/share/glib-2.0/gdb/gobject_gdb.py

experimental also seems fine, picking on amd64 and mips as arbitrary
representatives:

https://packages.debian.org/experimental/amd64/libglib2.0-dev/filelist
...
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5104.0-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5104.0-gdb.py
/usr/share/gettext/its/gschema.its
/usr/share/gettext/its/gschema.loc
/usr/share/glib-2.0/gdb/glib_gdb.py
/usr/share/glib-2.0/gdb/gobject_gdb.py

https://packages.debian.org/experimental/mips/libglib2.0-dev/filelist
...
/usr/share/gdb/auto-load/usr/lib/mips-linux-gnu/libglib-2.0.so.0.5104.0-gdb.py
/usr/share/gdb/auto-load/usr/lib/mips-linux-gnu/libgobject-2.0.so.0.5104.0-gdb.py
/usr/share/gettext/its/gschema.its
/usr/share/gettext/its/gschema.loc
/usr/share/glib-2.0/gdb/glib_gdb.py
/usr/share/glib-2.0/gdb/gobject_gdb.py

> p.d.o suggests the file is there on i164, arm64, sparc, s390, but not
> any other arch
> https://packages.debian.org/search?searchon=contents&keywords=glib.py&mode=exactfilename&suite=unstable&arch=any

ia64, sparc, s390 are outdated non-release architectures. My guess would
be that they have an older version of GLib and that's why they have the old
name for these files (the new name is glib_gdb.py).

I don't know what's going on with arm64.
https://packages.debian.org/sid/arm64/libglib2.0-dev/filelist claims it
has libglib-2.0.so.0.4200.0-gdb.py, which would mean it has GLib 2.42.0,
which is the version in jessie. I think packages.debian.org might just be
confused about which file list goes with which suite...

https://packages.debian.org/source/jessie/glib2.0 seems to be claiming that
glib2.0 has no binary packages in jessie, and also that none of its build-deps
exist, which, again, seems like packages.debian.org confusion rather than
a bug in GLib.

    S