Now we

1. go to our fork of https://git.devuan.org/devuan/xorg-server.git

2. check out suites/unstable

3. use dpkg-checkbuilddeps as guide for installing build dependencies

4. build a local Xorg with debian/rules binary

5. temporary "install"  resulting debian/build/main/hw/xfree86/Xorg as /usr/lib/xorg/Xorg

6. perform a verification test

7. edit the code and repeat from d until the misbehaviour goes away without we adding some new misbehaviour

8. update the packaging and version and stuff

9. issue a merge request

10. wait while that gets merged, built and published by others

11. install the fixed version.

Easy Peasy

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.