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
