Your message dated Thu, 16 Jun 2016 17:19:58 +0200
with message-id <[email protected]>
and subject line Re: libglib2.0-0-refdbg: consider including glib, gio?
has caused the Debian Bug report #693142,
regarding libglib2.0-0-refdbg: consider including glib, gio?
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.)
--
693142: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693142
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libglib2.0-0-refdbg
Version: 2.34.2-1
Severity: wishlist
libglib2.0-refdbg is configured with --disable-Bsymbolic (which is the
original reason it exists) and also with --enable-debug=yes. However,
the --enable-debug=yes option also affects glib (gdate, gmem, gslice)
and gio (enabling checked casts).
Since we're compiling them anyway, it might be worth including the
debug-enabled glib and gio in libglib2.0-refdbg, or in a new binary
package, or in libglib2.0-0-dbg, or something?
There are some other tweaks that could usefully be applied to a debug-enabled,
LD_LIBRARY_PATH'able package set: on linux-any we could
--enable-dtrace --enable-systemtap (with a systemtap-sdt-dev build-dependency),
and when <https://bugzilla.gnome.org/show_bug.cgi?id=335126> is eventually
fixed, we could use -DNVALGRIND for the "production" build but use the
system valgrind.h for the debug build (on supported architectures).
libdbus has a similar debug-enabled, LD_LIBRARY_PATH'able alternative build
in /usr/lib/${DEB_HOST_MULTIARCH}/dbus-1.0/debug-build, in the dbus-1-dbg
package.
Thoughts?
Regards,
S
--- End Message ---
--- Begin Message ---
On Tue, 13 Nov 2012 15:04:18 +0000 Simon McVittie <[email protected]> wrote:
> Package: libglib2.0-0-refdbg
> Version: 2.34.2-1
> Severity: wishlist
>
> libglib2.0-refdbg is configured with --disable-Bsymbolic (which is the
> original reason it exists) and also with --enable-debug=yes. However,
> the --enable-debug=yes option also affects glib (gdate, gmem, gslice)
> and gio (enabling checked casts).
>
> Since we're compiling them anyway, it might be worth including the
> debug-enabled glib and gio in libglib2.0-refdbg, or in a new binary
> package, or in libglib2.0-0-dbg, or something?
>
> There are some other tweaks that could usefully be applied to a debug-enabled,
> LD_LIBRARY_PATH'able package set: on linux-any we could
> --enable-dtrace --enable-systemtap (with a systemtap-sdt-dev
> build-dependency),
> and when <https://bugzilla.gnome.org/show_bug.cgi?id=335126> is eventually
> fixed, we could use -DNVALGRIND for the "production" build but use the
> system valgrind.h for the debug build (on supported architectures).
>
> libdbus has a similar debug-enabled, LD_LIBRARY_PATH'able alternative build
> in /usr/lib/${DEB_HOST_MULTIARCH}/dbus-1.0/debug-build, in the dbus-1-dbg
> package.
>
> Thoughts?
We're dropping the -refdbg, so I'm closing this.
If this is actually useful we could reintroduce something similar, but I'd like
to hear use cases and benefits before doing this again.
Cheers,
Emilio
--- End Message ---
