You are not logged in.
Note that there there are significant differences in your two use cases which seemingly have the same misbehaviour.
Firstly Alverstone uses logind as seatd backend, while fsmithred doesn't use seatd at all (i.e. the input mediation is disabled, because "libseat integration requires -keeptty and -keeptty was not provided"). Secondly A's device is handled by evdev while f's device is handled by libinput.
evdev seemingly has its issues during its re-loading for the device, whereas libinput seemingly succeeds re-loading the keyboard.
Good information; it points outside the libseat integration towards something in device juggling.
It would be useful if you Alverstone could run a test using libinput rather than evdev, and make sure there is no main Xorg.conf in use (as there apperas to be since your InputClass snippets are ignored). A log from such a test would be useful.
And perhaps fsmithred could start a new thread since yours is a completely different use case.
Yes I'd like to see the log file from startx down to that switch back to VT4.
I think you mentioned having an Xorg.conf. If so, please provide that as well.
In summary the issue is that upon returning to a VT running Xorg, that Xorg does not detect or handle changes to the USB inputs compared to when previously leaving the VT.
Please also provide an Xorg log file covering the period of one test; i.e. from startx to after having returned to the VT.
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.
Yes you are confused .
That find command of @fsmithred, when taken literally, will replace all occurrences of "old-word" (literally) with "new-word" (literally), and it will do nothing to occurrences of "python2.7".
That is a puzzle for ome and not for others.
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.
Sorry, I kind of imagined you would put an ounce of thought into the matter. Silly me.
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?
The random guess is that it got interrupted in the "middle" of preparing the initramfs, and then perhaps it gets sorted with a simple:
# update-initramfs -u -k all
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
Firstly, in a standard installation, the filesystem holds back 5% of space for root-only use. So your disk of 160G can only be filled to 152G by a non-root user. However wget doesn't know that so may well start downloading on the idea that there is some 8G++ space left, and then run into trouble when saving.
Secondly if only 4G of your 152G are in Downloads, you would do well in cleaning up elsewhere. Perhaps (as root) cleaning up in the /var/log and /var/cache trees would reclaim space. Otherwise I would guess you need to tidy up the user's home area.
Use du or xdu to find where the disk usage is, and delete with care and forethought.
ethtool -P wlan0 might show something, probably the working address though.
I suppose it could store it textually?
would be 37363a30633a64313a34363a66373a3839 in hex
EDIT: would be odd to do
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...
Perhaps the MAC is changed by firmware? In that story the first would be hardware (PROM) MAC while the latter would be a firmware derivative. Guesswork.
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.
Up to the right there is the WM selector, for choosing fluxbox rather than xfce4 ?
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.
Nothing stopping another developer (to be?) to stand up and be counted.
As wicd is forked by Devuan, the process could be to 1) get an account at git.devuan.org, 2) fork the devuan/wicd project for updating to working form (on branch suites/unstable), and then 3) issue a merge-request... all while concurrently getting a dialogue with Andreas going.
It would then be useful to also clone hanaguro's project as an additional "remote" for the workspace, so as to easily be able to match up their changes against Devuan's history. Doing so would have the additional advantage of getting that code away from Microsoft's (github) control.
Yes apt-get update does that. The downloaded "packages" files are kept in /var/lib/apt/lists
@Micronaut: yes. Google leaves its repository hook-in (i.e. a file) in /etc/apt/sources.list.d/ and you have to remove it by hand. man sources.list has more details.
EDIT: Google might also have left a PGP key (i.e. another file) in /etc/apt/trusted.gpg.d/ and you might want to remove that as well. man apt-get is a fairly good starting point about that.
It was FUD whether you accept it or not. Sometimes a couple of thoughts before typing can do wonders.
Note that /proc is a virtual filesystem tree giving insight into the running kernel. Not to be played with by hand.
Yes, wicd did/does provide a good and fairly distinct GUI for configuring the network devices and before it was abandoned due to the python2 -> python3 change it was still only in the beginning of its path to enshittification, so quite a good option if one feels a need for a GUI.
Well, not that wicd plays any role whatsoever in the transmission; it's all wpa_supplicant for link level encryption/decryption and the handling the connection logic via its wpa_action.