Hi, On Thu, Jun 07, 2012 at 07:36:23PM -0400, A. Costa wrote: > On Thu, 7 Jun 2012 12:47:48 +0200 > Ricardo Mones <mo...@debian.org> wrote: > > > > While writing an email that'd been open in the background > > > for a while, (hours), I clicked the 'Attach' button, and > > > sylpheed vanished -- as in ceased running. ... > > > > If you did an upgrade of gvfs while sylpheed was open that could be > > the reason. The workaround is simple: restart session. Otherwise you > > should try to get a backtrace. Anyway doesn't look like a Sylpheed > > bug. > > Thanks for the reply. > > In review, to verify I understand correctly. You suggest the cause of > 'sylpheed' unexpectedly quitting might be a side effect of something > that happens only during a background 'gvfs' upgrade, and probably > happens because of a 'gvfs' upgrade. (This is plausible, since I > usually have a 'sylpheed' window open, and I also run system upgrades > regularly.) > > Supposing that's not a 'sylpheed' bug, would it therefore follow that it > must be a 'gvfs' bug?
Seems so, the one you pointed and the other I added in the previous response, which are the same according the maintainer. > I probably should check my '/var/log/dpkg.log' circa 4/10/12 (when > this bug was first reported). Hmm, that date's been logrotated, and > today it'd be here: > > -rw-r--r-- 1 148461 May 1 04:16 /var/log/dpkg.log.2.gz > > Grepping that, it seems there were some upgrades to 'gvfs' version > 1.12.0-1 before 4/10/12: > > % zgrep gvfs /var/log/dpkg.log.2.gz | grep " status installed " \ > | grep "2012-04-[01][07-9]" > 2012-04-08 20:38:54 status installed gvfs-common:all 1.12.0-1 > 2012-04-08 20:38:54 status installed gvfs-libs:i386 1.12.0-1 > 2012-04-08 20:38:55 status installed gvfs-daemons:i386 1.12.0-1 > 2012-04-08 20:38:56 status installed gvfs:i386 1.12.0-1 > 2012-04-08 20:38:56 status installed gvfs-backends:i386 1.12.0-1 > > What versions of 'gvfs' were installed before then? 'gvfs' v1.10.1-3: > > % zgrep gvfs /var/log/dpkg.log.2.gz | grep " status installed " \ > | grep "2012-0[1-4]-" | grep -m 1 -B 10 "1.12.0-1" > 2012-04-02 13:30:27 status installed gvfs-common:all 1.10.1-3 > 2012-04-02 13:30:27 status installed gvfs-libs:i386 1.10.1-3 > 2012-04-02 13:30:28 status installed gvfs-daemons:i386 1.10.1-3 > 2012-04-02 13:30:29 status installed gvfs:i386 1.10.1-3 > 2012-04-02 20:35:34 status installed gvfs-backends:i386 1.10.1-3 > 2012-04-08 20:38:54 status installed gvfs-common:all 1.12.0-1 > > Hypothesis: to reproduce, we'd have 'gvfs' v1.10.1-3 installed, then > run 'sylpheed' v3.2.0~beta6-1, keeping the latter open during a > background upgrade to 'gvfs' v1.12.0-1; after the upgrade, with > 'sylpheed' still open, try to attach a file to a message. I don't > recollect which file I was trying to attach. Would the file's > directory need to be overseen by 'gvfs' to be relevant? If I understood the bug correctly this happens with any gvfs version because this bug is still not fixed yet, so yes, those could be used. Sylpheed version could be also beta6 or latest beta8, nothing has changed on that regard in Sylpheed IIRC, use what you have at hand. And no, as you rightly suppose I don't think neither files or directory names are relevant to this, any of them will trigger the problem, as it happens when the shared library is loaded, way before any call to its functions. regards, -- Ricardo Mones ~ bash: ./signature: No such file or directory /bin/bash
signature.asc
Description: Digital signature
