Good question, though not easy to answer. As I have some idea about the code flow, I can match (try to) it up with the log and in particular trace back from anomalous log entries. For Xorg logs you split it into the temporal strands broken by the times where the user has made a short pause in between the use case steps. Post#13 shows that clearly

Unfortunately Alverstone has hand edited the log before posting -- the log we see is not actually the log they got. But I believe that all log lines are included with their correct timestamps and only certain identifiers have been "mangle mapped" under an idea of protecting personal information.

On that assumption there's now enough for me to build a test case that should repeat the misbehaviour, with in particular the logs of #13 providing basis for log comparison.

The "bad" #13 log at timestamps 169.760--169.768 presents the setup for "the problem device" which appears to be a USB keyboard+mouse combo where after some extra logic event4 gets set up as a mouse data stream and the keyboard data stream setup gets postponed as a "virtual subdevice", at timestamps 169.812--169.812.

By the seatd calls, that uses input device with file descriptors 132.

At 174.228 the log starts showing the switch to VT 3, which in particular results in all input devices being "removed" from Xorg's internal data structures, that all their file descriptors are closed via seatd. Notably the device modules are not unloaded though.

In comparison, log good#13 shows the VT shift-away in log lines 104.675--104.744 with the same activity although logged differently. In particular that the logind log lines calls it "paused".

Next we can trace in the log that the "problem device" is unplugged and plugged back by virtue of Xorg handling the udev events while its VT is inactive. Thereafter the log (at bad#13: 192.148) represents the shift back and activation VT4 followed by (at bas#13:195.493) the Xorg termination.

The strand from bad#13:180.566--180.567 seem to represent the bug that the internal data structure discards the event4 handling and that the libinout module gets unloaded. That would result in that the subsequent VT entry does not re-establish event4 without the user again unplug/plug-in the device. The exact bug requires source review.

Notabley the log strand good#13: 160.359--160.414 where the device is plugged in while Xorg's VT is inactive doesn't present a failing attempt to aqire event4. Instead it gets "opened in paused state" that (in some way) avoids re-establsihing the "virtual sub device".

So, in short, it's a bit like reading the future in tea leaves

mmm enjoying a good laugh is a reality worth pursuing, I think

@T-A-P Can you please stop that useless vertical spacing... you just makes everything even more boring!

Yes I'd like to see the log file from startx down to that switch back to VT4.

The command you are using,

git rev-list --all | xargs git grep -F python2.7

scans all versions of all files in reverse chronological order, to find "python2.7".

Probably you mean to only check the latest version of the files? Like

grep  -F python2.7 -r *

which would not report any match.

Note that cups-browsed is only used for publishing the printers of your machine for use by other machines. It has nothing to do with how your machine connects to the printers.

You really don't need cups-browsed at all. (One might possibly be able to draw up some use case where it could be close to useful, even if still not necessary). Just purge it.

Do you use emacs to edit files? Does emacs leave backup files? How are they named? Have you edited /etc/init.d/connman with emacs? Are you wasting space here?

When you go multiarch, you also need to apt-get update and apt-get upgrade; "update" is for updating the local meta files about packages, and "upgrade" is for loading the packages supporting the new architecture.

There's good detail at https://wiki.debian.org/Multiarch/HOWTO

ethtool -P wlan0 might show something, probably the working address though.

mmm then maybe it's the opposite way; that the firmware loads with some random default mac, and this eventually gets updated from the hardware. If so I suppose a binary scan of the firmware could possibly find that first mac...

When you say "no network manager at all" you actually mean "just using ifupdown". That is the traditional network management which is configured by means of a text editor to edit its configuration files... It is indeed the simplest and easiest way with maximal flexibility.

Given that your /etc/resolv.conf is a link it suggests you also have the package resolvconf installed, and that would provide an additional depth to the confusion.

But in any case, DNS setting is part of the DHCP protocol; you know, when your machine contacts the router so as to get an IP address. At that time your machine is also told the IP address of the outbound gateway and the address of the DNS server(s). Those are suggestions by the DHCP server (your router) which get digested by the DHCP client running on your machine. The IP address is assigned to the network interface (via a kernel system call); the gateway IP is assigned to the routing table (via another kernel system call), and the DNS IP address(es) is registered in the file /etc/resolv.conf.

All that happens regardless of which networking software you use; whether it's plain ifupdown, wicd, network-manager or connman.. or whatever.

With resolvconf, you (unbeknowingly?) have opted for a local control of /etc/resolv.conf which is at odds with most networking software unless it also is configured to avoid messing with /etc/resolv.conf. Your first step towards bliss would be to purge resolvconf and reinstate /etc/resolv.conf as a text file.