Friday, November 18, 2016

pacman: update archlinux-keyring to solve corruption

I recently ran an update which did fine except for...
error: udiskie: signature from "Ambrevar " is unknown trust
:: File /var/cache/pacman/pkg/udiskie-1.5.1-1-any.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] Y
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

After attempting several fixes and checking Arch forums, I stumbled across this manjaro forum. Sure enough:
# pacman -S archlinux-keyring
Following this, it was a simple
# pacman -S udiskie
to catch it up.

Saturday, November 12, 2016

openshot-qt fickleness

I recently attended a wedding anniversary and downloaded openshot-qt soon after, from the Arch repository. Openshot didn't open on the first attempt, instead spawning some window errors. To be sure which version(s) of QT the package was compiled with, I ran ldd against it, but got the following (surpising1) result:
$ ldd /bin/openshot-qt
not a dynamic executable
I then went over to read-up on any idiosyncrasies about the installation, and noticed...
"bwaynej commented on 2016-09-26 02:37
openshot-qt depends on python-pip in order to run"
# pacman -S python-pip desktop-file-utils libopenshot python python-httplib2 python-pyqt5 qt5-webkit shared-mime-info
Most of these were re-installs. Thereafter, to determine where everything was placed:
$ pacman -Ql openshot


Went into yaourt and updated openshot-qt, during which I was queried for deleting the "conflicting" package openshot2. I authorized this and openshot-qt finally produced a display, albeit window errors continued.

1 for a presumably large application like a video editor. Eg, I would expect openshot-qt to be a ridiculously, possibly even unusably, massive app if compiled statically.
2 In spite of significant searching, I never found an installed or tarball version of openshot on my system -- the "conflict" warning was the only clue of interference from the old openshotpackage.

Friday, November 11, 2016

Rebuilding Fonts

Fonts, printers, scanners, sound, and usb connected items: have a sense a humor if you intend to deal seriously with these in Linux.

Anyway, too often during an Arch update, there will be a conflict in the fonts, sometimes between already installed fonts and one intending to update itself through pacman. When this happens, the entire update of all packages can be scotched when pacman exits, or perhaps the user will be forced to deal with /etc/fonts/fonts.conf in some immediate way.

Arch uses fontconfig, so I sometimes solve these conflicts by deleting everything inside /etc/fonts/. Since /etc/fonts/font.conf is eliminated along with other files, any conflicts in /etc/fonts are eliminated and pacman can complete its update. However, after this nuclear method, fonts will be mangled. They cannot be repaired with a simple # fc-cache -vf. Even that action will spew errors that it can't find a /etc/fonts/font.conf file instead of running a subroutine that simply builds such a file. Programmers.

So, how to rebuild /etc/fonts/font.conf? Turns out there's a lot of information about how to edit /etc/fonts/font.conf , but no information about re-building it. The solution was only obtained via frustration after attempting various manually constructed versions of /etc/fonts/font.conf which failed:
# pacman -S fontconfig
That's right, the only thing that worked for me was to re-install the f**king package. Of course, I'm an idiot, but still. Also, be sure to explicitly update one's fonts after a pacman update, in case pacman left any hanging chads.
# fc-cache -fv
Alternatively, when one runs into a font problem, a person can exit their update noting the name of the font that is causing the problem, and then rerun the update excluding that font until one has determined the conflict.
# pacman -Syu --ignore font-foo

[solved] xinit: unable to connect to x server: Connection refused

This is a common, highly annoying, permission fail following any update. If your /etc/group and /etc/shadow files have customary arrangements, and you haven't created conflicting rules in /etc/udev/rules.d, then it's not your fault -- you did your normal user-level part. Defenestration of various programmers is the deserved solution because, since the advent of PAM, LDAP, NSS and the other ridiculous kludge of "security" since Sept 2001, which have mostly secured users out of their own systems, it's probably another feature requiring a permission adjustment. If so, you have days of work ahead. Try these below and don't get into security files unless these don't work.

If no programmers are handy to toss, here are some options
  1. Log out entirely, then log back into your user and make a second attempt
  2. Try rebooting entirely. If it's a large update, this solves it nearly every time.
  3. You have two main configuration files for X, besides the regular stuff in .xinitrc (or .xsession if you're a dumbass who uses a DM):
    • /etc/X11/xorg.conf -- you should never have to fuck with this file but (ironically, as with everything else in Linux) you will nevertheless have to do so one day after a "helpful" "update" (although your system was running just fine before these) at which point you will have no experience at doing so, since you never were supposed to have to edit it, but now you suddenly have to and... (you guessed it) at a level assuming you have have a CS degree and years and years of experience with that file. Tada!
    • /usr/share/X11/xorg.conf.d -- this is the bullshit directory where 2 million conflicting configuration files live, files you cannot easily do anything but printout and lay side by side on the living room floor (which you don't have since you lost your job coming in late after all-nighters attempting to fix permission problems added since 2001) and desperately hope that you can identify some conflict between them or the aforementioned /etc/X11/xorg.conf file before losing another weekend or relationship with these printouts lying all over the house. Fun, right?


Reboot after large updates when this happens.

$ strace startx 2>&1 |tee bigfile.txt
This is obviously much better than a log file. Look for X authorities and see if they're not forthcoming.

$ xauth
Is there an ~/.Xauthority file? Two problems are possible. One, it's not being created, or two, it's being created with no content. It's a binary file, typically about 49 bytes in size, when functional. Zero bytes is not good, so then try....

$ xauth list

Tuesday, November 8, 2016

DConf - GDM specific

Early 2000 laptops shouldn't waste valuable memory for a fancy login or to run wpa_supplicant beneath the hood. I simply boot into runlevel 2 and take a few seconds to do these myself. Recently it became clear that TA's I oversee would experience a gentler learning curve if their logins and network connections had a GUI assist. So I began to toy with GDM. A few considerations
  1. DM's move directly to runlevel 5. Can I occasionally go runlevel 2 if needed (eg. troubleshooting)?
    # systemctl disable gdm.service
    # reboot
  2. I like IceWM, but GDM's default is Unity, which is a memory hog. Can I still get there from the DM?
    $ cp .xinitrc .xsession
    This is because .xinitrc is used going from runlevel 2 to the GUI using startx, and GDM uses .xsession in a similar way, calling it to start the GUI.
  3. Can I test the login screen manually from runlevel 2?
  4. GDM autmagically installs pulseaudio. Do I have available time to skillfully cripple pulseaudio so that it doesn't interefere w/VLC and java?


A common Linux frustration is the omission or inaccuracy of critical details in Forum and other Googled solutions. Such oversights silently sap hours or days of extra effort. Over the years, the accretion of lost time becomes alarming. Accordingly, for Linux processes I might irregularly use, or which required an extremely long disentangling process, I went to the extreme of creating a blog in order to document solutions for future time savings. Details can be anything from an intermediate step, (mis)ordered steps, permissions, group membership, etc. In this case, is a great page for configuring GDM, but it overlooks the copying of some key files, some steps requiring root authority, and so on.

The icewm FAQ has the answers for this configuration. The files involved
  • /etc/X11/gdm/Sessions/IceWM
    exec /etc/X11/xdm/Xsession icewm
  • /etc/X11/xdm/Xsession
  • /usr/share/apps/switchdesk/Xclients.icewm
    exec /usr/local/bin/icewm-session
  • /usr/local/bin/icewm-session