I'll have another go. This is getting tedious.
<debian-user@lists.debian.org>: host bendel.debian.org[82.195.75.100] said: 550
5.7.1 <debian-user@lists.debian.org>: Recipient address rejected: Mail
appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct
HELO and DNS MX settings or to get removed from DNSBLs; please relay via
your ISP (lionunicorn.co.uk) (in reply to RCPT TO command)
On Sun 12 Nov 2017 at 20:53:23 (+0100), Laurent Lyaudet wrote:
> Hello,
>
> Well, find behavior and hidden files was not the intended topic of this
> thread ;)
> I do already know about Ctrl+H, ls -a, etc.
> And indeed my find command is incorrect since I forgot the dot or some
> wildcard at the beginning.
> After correction, I can say there is no .xsession-errors file on my system.
> The only matches were
> /usr/share/xsessions
> /etc/X11/Xsession.d/40x11-common_xsessionrc
There's nothing special about the filename .xsession-errors. On this
system, it's just the value of $ERRFILE, set in /etc/X11/Xsession.
But I don't run gnome, so I couldn't say what its startup files are
like. I can only assume that some sort of juggling goes on because
~/.xsession-errors belongs to the user who started the X server,
but (again I assume) a graphical system must start X before any user
has logged in through the (graphical) display manager.
So you might be better off using find to find files newer than,
say, 5 minutes old immediately after booting and logging in.
$ find ~ -mmin -5 -type f -print
> So yes, it may be strange if usually there is plenty of X session errors.
>
> After googling, I looked at /var/log/messages with a lot of, well, messages
> that I didn't found interesting and related to my problem.
> I also looked at /var/log/gdm3/ but it was empty.
>
> Regarding the boot errors, I have plenty of them as with any laptop I've
> seen running with Linux since laptops tend to have weird hardware.
> However, despite the same boot errors since I installed Debian on this
> laptop, the bug I'm talking in this thread was not present until a few
> weeks ago.
Someone mentioned network timeouts. Does this button/menu/whatever
do anything involving the network which could be stalled while
DHCP is doing its dirty work.
> I also forgot to say that soon after the bug started I found that hitting
> the super/windows/apple key works despite the click not working.
> And I already know some people out there will say "problem solved, he can
> put up with the bug".
Well that's at least a workaround, not a solution, assuming that what
"works" is the functionality you expected from clicking.
But if you want to chase down this bug, you might find a gnome list
more productive than this one, viz.
> > > someone else perhaps could help on where and how to debug gtk/gnome
Cheers,
David.
