On https://bugs.debian.org/833596 :
On Wed 2016-08-10 04:27:21 -0400, Stefano Zacchiroli wrote:
> On Wed, Aug 10, 2016 at 12:12:27AM -0400, Daniel Kahn Gillmor wrote:
>> So i'm not able to reproduce this behavior.
>>
>> Zack, can you help me narrow down how this is happening for you?
>
> Sure, I'll be happy to. But as I mentioned before I wonder if it's worth
> to do it with my current package mix: I'm using testing, where the GNOME
> stack seems to be still in flux, apparently), with gnupg2 coming from
> experimental. I can debug, but I wonder if it'd be a good time
> investment.
That's the exact same stack i used for my test, and i didn't see the
error. so yeah, i'd like to try to track it down.
> Unless you consider this issue potentially blocking for uploading to
> unstable, I'd rather wait for gnupg2 to land in testing and try again.
> After all the issue is for a non-default behavior that one should
> explicitly enabled, right?
I'm willing to upload to unstable with this bug still open -- but the
software will still be the same software ;)
>> do you have logs of the failed login session someplace, or other details
>> that might help diagnose?
>
> I can look up logs, but I could use some guidance about where the GNOME
> user session logs are supposed to be. ~/.xsession-errors seems to be
> obsolete --- or else it hasn't received log entries on my laptop since
> March 2016, which seems unlikely...
Hm, maybe "journalctl --user" ? i'm cc'ing pkg-gnome-maintainers to see
whether they have any suggestions for better debugging techniques.
Thanks for following up,
--dkg
signature.asc
Description: PGP signature
