Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer

[Simon McVittie]

On Sat, 19 Mar 2022 at 14:17:08 -0700, Don Armstrong wrote:
> On Sat, 19 Mar 2022, Nis Martensen wrote:
> > "This bug affects accessibility to users with disabilities. It
> > particularly impacts usability by people who rely on assistive (or other
> > adaptive) technology to use the system/package."
> 
> That works for me! [Feel free to modify the appropriate pages and
> packages; I don't believe that requires any one from owner@ to do that.]

That sounds great to me for the web page that is the canonical definition
of the tags, but I think reportbug will need something shorter - perhaps
just the first sentence?

en_GB proofreading: I think "accessibility for users with disabilities" or
"accessibility by users with disabilities" reads better than "to" in that
first sentence.

smcv

Re: Bug#1007106: reportbug: please make the meaning of the a11y tag clearer

[Simon McVittie]

On Mon, 14 Mar 2022 at 09:38:36 -0400, Sandro Tosi wrote:
[ Simon McVittie wrote: ]
> > My understanding is that the a11y tag is intended to be for bugs that
> > harm Debian's usefulness for people who rely on assistive technologies
> > (screen readers, high contrast themes, etc.), and more generally, people
> > who are not well-served by typical application developer assumptions as
> > a result of disabilities or similar factors. The debian-accessibility
> > mailing list is described on https://lists.debian.org/devel.html as
> > "Making Debian more accessible to people with disabilities", and the
> > a11y tag is shown on bugs.debian.org as a wheelchair symbol emoji,
> > which supports that interpretation.
> >
> > However, reportbug describes the tag as:
> >
> > > 1 a11y  This bug is relevant to the accessibility of the package.
> >
> > and I think a lot of non-technical users are interpreting this as "this
> > bug makes it hard for *me personally* to use this package" - but if
> > we used that interpretation, then it would apply to a lot of medium to
> > high severity bugs in user-facing components like desktop environments,
> > and the bugs that are particularly relevant to debian-accessibility
> > subscribers would be lost in the noise.
> 
> I sympathize with your request, but please first address the rewording
> the the authoritative source of tags descriptions:
> https://www.debian.org/Bugs/Developer#tags

Please could the BTS owners provide or approve a clearer wording for this,
if they are the "owners" of the tag definition?

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007106#10,
Samuel Thibault suggested
"This bug is relevant to the accessibility of the package for disabled 
users."
or
"This bug affects disabled users."

and in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007106#20,
Cindy Sue Causey suggested
"... affects people with disabilities."
or
"... affects users with disabilities."

I would personally say
"This bug particularly affects users with disabilities"
if we're using a form of wording similar to that, because what we're
interested in is whether a bug is *particularly* significant for users
of accessibility technologies etc., rather than just any random bug that
happens to have been encountered by a user with a disability.

Thanks,
smcv

Bug#1007106: reportbug: please make the meaning of the a11y tag clearer

[Simon McVittie]

Package: reportbug
Version: 11.4.1
Severity: normal
X-Debbugs-Cc: debian-accessibility@lists.debian.org

I've noticed that a lot of bug reports, particularly in packages with
many non-technical users, have the a11y tag when they shouldn't, which
presumably makes the tag less useful for people who are interested in a11y
by harming the signal-to-noise ratio.

My understanding is that the a11y tag is intended to be for bugs that
harm Debian's usefulness for people who rely on assistive technologies
(screen readers, high contrast themes, etc.), and more generally, people
who are not well-served by typical application developer assumptions as
a result of disabilities or similar factors. The debian-accessibility
mailing list is described on https://lists.debian.org/devel.html as
"Making Debian more accessible to people with disabilities", and the
a11y tag is shown on bugs.debian.org as a wheelchair symbol emoji,
which supports that interpretation.

However, reportbug describes the tag as:

> 1 a11y  This bug is relevant to the accessibility of the package.

and I think a lot of non-technical users are interpreting this as "this
bug makes it hard for *me personally* to use this package" - but if
we used that interpretation, then it would apply to a lot of medium to
high severity bugs in user-facing components like desktop environments,
and the bugs that are particularly relevant to debian-accessibility
subscribers would be lost in the noise.

For instance, the bug that prompted me to open this one is a deadlock (or
something) in interacting with Pipewire's PulseAudio-compatible server,
which makes the game Minetest (among others) take a long time to start
and have no sound. That certainly makes it hard to access normal
functionality of minetest, but it doesn't seem like a bug that needs
particular attention from accessibility experts...

Can anyone suggest a wording that makes the intention of the tag clearer,
without "othering" the people who particularly need bugs with this tag to
be fixed? I've cc'd debian-accessibility in the hope that someone on that
list has a better idea. I don't want to use terms that will offend people
(and I apologise if I have), but I also think the current description is
sufficiently vague to be harming the usefulness of the a11y tag.

Thanks,
smcv

Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 17 May 2021 at 23:54:01 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2021-05-17):
> > It looks as though the problem is that the size GTK chooses for a
> > GtkTextView (a debconf "note" or similar) is flapping between two
> > values.
> 
> Without looking into the code, one might try and keep track of results
> that have been seen, and if N/N+1 is detected, maybe just assume this
> should be N+1 and move on with other computations? But anyway, further
> down your mail you seemed to have ideas already.

It wasn't obvious to me where we'd keep track of this, or how correct
it would be to do that - cache invalidation is reputed to be one of the
hardest problems in computer science, and this would be one more thing
that needs to be invalidated on at least those occasions when the layout
has legitimately changed (but without invalidating it too often because
that would destroy the workaround).

Having reproduced the English/rescue issue and got further with the
Sinhala/install issue with the GTK MR referenced below, I think it can
also happen that the layout flaps by an amount greater than 1 pixel
(I think the most I've seen is 4px), so a special case for n/n+1 isn't
going to be enough.

One of the reasons this took me a while is that I got distracted by the
difference I was seeing being exactly 1px, which I thought might be to
do with GTK adding 1px of extra width to make sure there's space for a
cursor - but after tracing through it, it seemed like GTK is always
adding/removing that width correctly.

> > My next thing to get a try when I get a chance will be to make GTK refuse
> > to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
> > outside that limit, with a g_warning().

This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2

The other thing I wanted to try was to make cdebconf create the GtkTextView
in an empty state, and then populate it with text a little later (perhaps
after layout but before drawing, or perhaps drawing one frame without text
and then adding the text in the next frame, I'm not actually sure). And
that also works:
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6

Following the rule of thumb that bad interactions between two components
should often be fixed on *both* sides, I'd be tempted to clone this bug,
reassign to both gtk+2.0 and cdebconf, and apply both changes.

As for Pango, I'm afraid figuring out whether it is doing something wrong
here is beyond my expertise. If I can characterize the maybe-bug in a clear
enough way I can try asking upstream - but as I said before, upstream will
be very reluctant to touch this as soon as I mention GTK 2, which has been
on life-support for a decade and is now officially dead.

smcv

Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 17 May 2021 at 18:12:35 +0200, Cyril Brulebois wrote:
> And for those not following #debian-boot, I'm finding myself between a
> rock and a hard place, as both options (trying to work around the
> rendering-related hangs versus switching to GTK 3 at the last moment)
> are very far from ideal… I'm not sure what we'll end up doing, and I'm
> happy to get some “votes” pro or against any of those options, and to
> hear about other options entirely.

My instinct is that it's far, far too late to be moving to GTK 3 this
cycle, and I'd prefer to get a suitable hack into GTK 2 if we can
find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting
the installed system.

I think d-i will need to move to GTK 3 early in the Debian 12 cycle,
but hard freeze is not the time to be fast-forwarding through 10 years
of GUI library development.

I've continued to look into GTK2/Pango with some rather extensive printf
debugging. I have other responsibilities and I'm trying to learn how
GTK/Pango text layout works from first principles (I'm in the GNOME
team but not really a GUI developer), so it's slow going, but I have
some ideas for things that might be able to break the loop. It's not
clear to me yet whether this is a GTK 2 bug, or a Pango bug, or what.
GNOME team members who actually know what they're doing are welcome
to step in any time.

Upstream are going to be incredibly reluctant to help us with GTK 2,
given that it has been deprecated in favour of GTK 3 for a decade, and
is officially EOL now that GTK 4 has stable releases. Pango does seem
like it's doing the wrong thing here, but perhaps GTK 2 or cdebconf is
holding it wrong.

Getting
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
into cdebconf would make this easier, although we can revert it for the
sake of a smaller diff once we think we have a solution if the release
team are grumpy about it.

Philip Hands wanted to get this running under automated testing, but my
current GTK 2 and Pango patches are spamming the syslog at 3 million lines
a minute when they get into the loop, so we're going to have logistical
difficulties in saving logs.

It looks as though the problem is that the size GTK chooses for a
GtkTextView (a debconf "note" or similar) is flapping between two
values. GTK asks Pango "if you wrap lines at width x, how much space
will you need?", then uses the result to re-run the layout algorithm,
which changes the width available, which causes the layout algorithm to
be re-run and so on. Under normal circumstances, this runs for a few
iterations and then stabilizes at one size, terminating the loop, but
when I select Sinhala from the language menu, the width flaps between
71 and 72 pixels, with each re-layout resulting in the other width.

I think this might be related to the fact that when the layout is
calculated at the narrower width, Pango decides that there isn't space
to put the "." at the end of a paragraph on the same line as the last
word, and so wraps it to the next line, which is fine; except that
you'd expect the space required for the last word to get a bit smaller
when the "." is not included, but actually Pango tells GTK that it will
need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it
flapping between the narrower and wider width. I don't know why that
happens - perhaps the Indic shaper is drawing a character at the end of
a line more elaborately, or something?

However, either 71 or 72 pixels seems a ridiculous width to be trying to
squish multiple sentences into, so arguably it's a bug in GTK 2's layout
algorithm that it is even considering that as a size. The GTK 2 layout
algorithm does not necessarily make much sense, and the fact that it
can feed back into itself is probably a GTK 2 design flaw. During the
GTK 3 cycle it was redone to be in terms of "height for width" (if I
give you this width, how much height will you need? the mode cdebconf
will end up using) and "width for height" (the opposite, rarely used) -
so hopefully GTK 3 avoids this failure mode. However, it also seems wrong
that telling Pango that less width is available can result in it saying
it needs *more* minimum width, and maybe preventing this from happening
would get GTK 2 to do the right thing.

My next thing to get a try when I get a chance will be to make GTK refuse
to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
outside that limit, with a g_warning(). This might result in the text
being clipped at the right margin (or left margin in Hebrew/Arabic), or
even having its "ink rectangle" overlap with the next widget to the right
(or left); but for d-i, which always uses the full screen width and in
practice has a generous amount of space for its text, we might get away
with it? In a very brief test that seemed to resolve the Sinhala thing,
but I haven't tried the other paths that lead to infinite loops. Please
could someone who has tried the other scenarios provide a walkthro

Bug#865268: svox: please build-depend on automake, not obsolete automake1.11

[Simon McVittie]

Source: svox
Version: 1.0+git20130326-5
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies. As far as I am
aware, there are no immediate plans to remove automake1.11.

Thanks,
S

Bug#822857: Fwd: Bug#822857: at-spi2-core: doesn't clean up legacy directory properly

[Simon McVittie]

Christoph Anton Mitterer wrote:
>> Apparently /etc/at-spi2 is no longer part of the package.
>> The directory, though empty (at least after upgrade), isn't
>> cleaned up properly however:
>> Unpacking at-spi2-core (2.20.1-1) over (2.18.3-4) ...
>> dpkg: warning: unable to delete old directory '/etc/at-spi2': Directory not 
>> empty

As far as I know, this warning is expected, and will happen any time
a conffile is cleaned up with dpkg-maintscript-helper and was the only
thing in that directory. That's because dpkg tries to remove the obsolete
directory during unpack, but dpkg-maintscript-helper doesn't remove the
obsolete conffile until the package is configured (because until then,
if something goes wrong, we might have to roll back), so the directory
is non-empty.

If you haven't modified the conffile, the *next* upgrade of the package
will clean up the empty directory. I think this can be brought forward to
the configure step by having debian/at-spi2-core.postinst containing
something like:

#!/bin/sh
set -e

#DEBHELPER#

rmdir --ignore-fail-on-non-empty /etc/at-spi2 || true

I'm not sure whether the benefit is worth the complexity here or not.

If you *have* modified the conffile, the directory can't and won't be
deleted, and it is normal to get the warning in any case.

S

Bug#820969: at-spi2-core: new upstream release 2.20.1

[Simon McVittie]

Package: at-spi2-core
Version: 2.18.3-4
Severity: wishlist
Tags: patch

A new version of at-spi2-core was released alongside GNOME 3.20. My interest
in this version is that it changes the D-Bus activation setup so that the
AT-SPI bus runs in its own cgroup on systems where dbus-user-session is
installed; it also merges some patches that are applied in the Debian
package already, and requires one file fewer in /etc.

For your convenience, here is some proposed packaging, in branches from
your git repository:

ssh://git.debian.org/git/users/smcv/at-spi2-core.git

It seems to launch successfully, but I don't actually use assistive
technologies, so I can't say whether it still works properly (although
I can't see why it wouldn't). No intention to NMU this, obviously :-)

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.20.1-1
ii  libc6  2.22-6
ii  libdbus-1-31.11.2-1
ii  libglib2.0-0   2.48.0-1
ii  libx11-6   2:1.6.3-1
ii  libxtst6   2:1.2.2-1+b1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#811009: libatspi2.0-dev: is dependency to libdbus-glib-1-dev still required for all archs?

[Simon McVittie]

On Thu, 14 Jan 2016 at 20:41:52 +0100, Samuel Thibault wrote:
> Patrice Duroux, on Thu 14 Jan 2016 20:29:54 +0100, wrote:
> > I think that [dbus-glib] is deprecated and oldlib, isn't it?
> 
> Apparently, yes. at-spi2-core actually doesn't use it any more, so we
> can just drop the dependency.

Was this fixed by

  * control: Replace libdbus-glib-1-dev dependencies with libdbus-1-dev.

in 2.18.3-4?

Thanks,
S

Bug#723163: Bug#723557: libgtk-3-0-udeb: uninstallable, depends on missing libatk-bridge2.0-0

[Simon McVittie]

On 14/10/13 10:37, Cyril Brulebois wrote:
> Michael Biebl  (2013-10-14):
>> libatk-bridge2.0-0-udeb is now available and libgtk-3-0-udeb has
>> been rebuilt and so has a proper dependeny on
>> libatk-bridge2.0-0-udeb.
> 
> Yes, thanks. We still have other issues, like libatk-bridge vs.
> at-spi and at-spi vs. libdbus, but this is getting resolved. FWIW
> that can be checked on graphs available at:
> http://d-i.debian.org/edos/

The packages higher up the hierarchy need some binNMUs now that
libdbus-1-3-udeb exists. I requested at-spi2-core and at-spi2-atk in
. It looks as though Gtk3 may have been
uploaded frequently enough not to need the same.

As far as I understand it, whenever udebs are introduced outside
"least dependencies first" order, binNMUs will be needed afterwards.
Perhaps dpkg-shlibdeps should fail (make udebs FTBFS) if udebs'
library dependencies can only be satisfied by ordinary debs?

S


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525bc5f2.4050...@debian.org

Re: Bug#723948: libatk-bridge-2.0-0-udeb: uninstallable; depends on missing libatspi2.0-0 (>= 2.9.4)

[Simon McVittie]

On 04/10/13 00:36, Samuel Thibault wrote:
> Simon McVittie, le Thu 03 Oct 2013 12:37:07 +0100, a écrit :
>> On 03/10/13 12:09, Samuel Thibault wrote:
>>> It essentially needs dbus-launch, to start dbus-daemon.
>>
>> Is this the session bus, or a parallel bus, or both?
> 
> I don't really know what that means.  What I can see in the source code
> (at-spi2-core/bus/at-spi-bus-launcher.c) is this:
> 
>   name_owner_id = g_bus_own_name (G_BUS_TYPE_SESSION,
>   "org.a11y.Bus",

That's a session bus, so you need to get one started, somehow.

The automagic mechanism which D-Bus has always had is that clients'
default session bus address (if they don't see any relevant environment
variables) is "autolaunch:", which means "fork-and-exec dbus-launch,
which will look in X11 window properties to try to find a session bus,
and if there isn't one, start one itself and advertise it in X11 window
properties". The *other* automagic mechanism is to run dbus-launch from
a file in /etc/X11/Xsession.d, so that there's already one running.

I consider this to be rather unpleasant, particularly the autolaunch:
bit (dbus-launch is poorly-documented and confusingly-implemented): it's
primarily there to support the "run a single GNOME/KDE app under fvwm"
use-case. I'd prefer it if graphical environments that want D-Bus could
run their own dbus-daemon and put $DBUS_SESSION_BUS_ADDRESS in graphical
clients' environment. g-i is basically a very small graphical
environment, so I'd prefer it if g-i could take responsibility for doing
that.

dbus-run-session(1) is a new tool which I added to make that easier:
it's a "command prefix"-style tool, like chroot or sudo (but retaining a
supervising parent process rather than ending with an exec(), so more
like schroot, really). It starts a dbus-daemon as a child, finds out the
address, and starts the process given in its arguments (the session) as
a second child, with the D-Bus address in its environment. It watches
its children until the session terminates, then kills the dbus-daemon
and exits itself.

For now, my plan is to put together a dbus-udeb (with dbus-daemon,
dbus-uuidgen and probably dbus-run-session), a libdbus-1-3-udeb, and
possibly a dbus-x11-udeb containing dbus-launch. I'd appreciate it if
dbus-x11-udeb could go away before Jessie is released, though.

S


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524ea5f7.20...@debian.org

Re: Bug#723948: libatk-bridge-2.0-0-udeb: uninstallable; depends on missing libatspi2.0-0 (>= 2.9.4)

[Simon McVittie]

On 03/10/13 12:09, Samuel Thibault wrote:
> AT-SPI won't need those.
> 
> It essentially needs dbus-launch, to start dbus-daemon.

Is this the session bus, or a parallel bus, or both? A parallel bus
shouldn't be using dbus-launch, which is (a) specifically designed for
the session bus, and (b) not particularly well designed or implemented.
I hope that in the glorious Wayland future, dbus-launch will just be a
strange historical relic for X11 users.

The reason I ask is that it determines whether I have to build a
dbus-x11-udeb :-)

In a controlled environment like d-i, I would much prefer it if the X11
session was run under dbus-run-session(1) (currently only available in
dbus/experimental, but I can backport it), which has much more sensible
semantics than dbus-launch.

S


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524d56e3.6010...@debian.org

Bug#723948: libatk-bridge-2.0-0-udeb: uninstallable; depends on missing libatspi2.0-0 (>= 2.9.4)

[Simon McVittie]

On Sat, 21 Sep 2013 at 17:43:13 +0200, Samuel Thibault wrote:
> Ah, damn, sure.  Will do.  This will however also need a udeb for
> libdbus, thus cloning for dbus too.

Hi,
Sorry for the delay, I didn't see this until just now.
Is there any general documentation on creating udebs/how they should
differ from full-fat debs, or should I base some guesses on another
udeb-enabled package, like glib2.0 or something?

How space-constrained are we here? Should I be compiling the udeb "flavour"
with -Os, disabling API sanity checks (that aren't triggered by correct code)
to save a bit of space, or similar hacks?

The obvious core feature is "enough of the libdbus library that dynamic
linking succeeds", but presumably AT-SPI isn't just linking to libdbus
for fun, and needs some subset of its functionality.
What functionality do you need the libdbus udeb(s) to have? Specifically:

Does AT-SPI run its own DBusServer in-process (in which case it might
only need the library), or does it execute the dbus-daemon binary?

Does AT-SPI need the well-known D-Bus system bus to be running from
its init script, or can we leave out that bit?

If AT-SPI does need the system bus, I assume we don't need SELinux support,
or systemd-as-pid-1 enhancements?

dbus-daemon and parts of libdbus require that a unique "machine UUID" (32
lower-case hex digits + "\n", no punctuation) has been generated and stored
in either /etc/machine-id (systemd-compatible location) or
/var/lib/dbus/machine-id (old location). Should dbus-udeb arrange for that
to happen in its postinst, or would you prefer d-i to set up
/etc/machine-id globally?

Are udebs expected to be robust across a reboot? I assume "no"?
(If they're not, then we can create machine-id in the postinst, but not
bother to check/re-create it in an init script.)

Do you want the dbus-launch utility to start/discover a session bus
automatically (packaged as dbus-x11, 28K, adds libX11) or can we omit that?

Do you want the dbus-send utility for sending messages from the
command line (20K) or can we omit that?

Do you want the dbus-monitor utility for monitoring D-Bus traffic? (16K)

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131003104544.ga5...@reptile.pseudorandom.co.uk

Bug#691018: libatk-bridge2.0-0: [experimental] closes a shared libdbus connection

[Simon McVittie]

Package: libatk-bridge2.0-0
Version: 2.6.0-1
Severity: normal

Since upgrading to Gtk and ATK from experimental, some Gtk applications
(including gedit and evince) print this warning on exit:

process 24460: Applications must not close shared connections - see 
dbus_connection_close() docs. This is a bug in the application.

gdb reveals that the only call to dbus_connection_close is from the ATK
bridge.

Applications using libdbus may only close private D-Bus connections,
obtained with dbus_connection_open_private() or dbus_bus_get_private().
They must not close global shared connections, which come from
dbus_connection_open() or dbus_bus_get().

I haven't yet checked whether this is fixed in 2.6.1.

default|archetype% gdb =gedit ~
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/gedit...(no debugging symbols found)...done.
(gdb) set logging on
Copying output to gdb.txt.
(gdb) break dbus_connection_close
Function "dbus_connection_close" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (dbus_connection_close) pending.
(gdb) run
Starting program: /usr/bin/gedit 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecb70700 (LWP 25533)]
[New Thread 0x7fffe7fff700 (LWP 25534)]
[New Thread 0x7fffe77fe700 (LWP 25535)]

Breakpoint 1, dbus_connection_close (connection=0x6f3150)
at ../../dbus/dbus-connection.c:2889
2889../../dbus/dbus-connection.c: No such file or directory.
(gdb) bt
#0  dbus_connection_close (connection=0x6f3150)
at ../../dbus/dbus-connection.c:2889
#1  0x7268da0b in atk_bridge_adaptor_cleanup ()
   from /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
#2  0x772df970 in _gtk_accessibility_shutdown ()
at /tmp/buildd/gtk+3.0-3.6.0/./gtk/a11y/gail.c:809
#3  0x0042b0dd in main ()
(gdb) cont
Continuing.
process 25530: Applications must not close shared connections - see 
dbus_connection_close() docs. This is a bug in the application.
[Thread 0x7fffe77fe700 (LWP 25535) exited]
[Thread 0x7fffe7fff700 (LWP 25534) exited]
[Thread 0x7fffecb70700 (LWP 25533) exited]
[Inferior 1 (process 25530) exited normally]
(gdb) 

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libatk-bridge2.0-0 depends on:
ii  libatk1.0-02.4.0-2
ii  libatspi2.0-0  2.5.3-2
ii  libc6  2.13-35
ii  libdbus-1-31.6.8-1+exp1
ii  libglib2.0-0   2.34.0-1
ii  multiarch-support  2.13-35

libatk-bridge2.0-0 recommends no packages.

libatk-bridge2.0-0 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121020092840.ga24...@reptile.pseudorandom.co.uk