Blog atrasado con gajes del oficio

Rpi4 on Arch Linux Arm No Audio Headphones resolved with snd_bcm2835_enable_headphones=1

According to the recommendations the block of code should be in one line:

snd_bcm2835.enable_headphones=1
snd_bcm2835.enable_hdmi=1
snd_bcm2835.enable_compat_alsa=0

Rpi4 has had trouble for a while now, especially running under Arch Linux with the sound output from the headphones jack source. I’ve usually read a great many threads dealing with this issue before. Unfortunately, many of the solutions/recommendations/suggestions haven’t resolved the problem.

Other distros have dealt successfully with this issue before. But whether it has been casued for some given reason or another, in the case of ArchlinuxArm this has been an outstanding issue in a great many number of occasions.

The configuration files and particular model and versions for the rpi4 as it has been outlined on many of the threads, are not quite that different from mine, and yet the issue was not resolved.

I’ve read about this:

https://archlinuxarm.org/forum/viewtopic.php?f=65&t=15090&start=0

therein, another specific thread dealing with this issue was opened which followed over here:

https://archlinuxarm.org/forum/viewtopic.php?f=65&t=15128&p=65808#p65816

This thread sound on rpi model 4b was for example, specifically opened to collect more information about some of the back then outstanding issues with the rpi4 model b.

The above also links to Re: fresh rpi4b install with linux-raspberrypi which as one might guessed by going over it, it deals with installing another kernel tailored to this particular sound problem.

Some of the posted code may not apply to the particular model, but as the author clearly specified, many of these settings might differ considerably from one’s setup.

arm_64bit=1
enable_gic=1
dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231
dtparam=audio=on
dtoverlay=disable-wifi
dtoverlay=disable-bt
disable_overscan=0

From there, another thread entitled alsa - device not found was posted

In it, there were some specific packages that must be installed such as (at the time of writing):

alsa-firmware 1.2.4-2
alsa-lib 1.2.4-3
alsa-plugins 1:1.2.2-2
alsa-topology-conf 1.2.4-2
alsa-ucm-conf 1.2.4-2
alsa-utils 1.2.4-2

In addition to these, the author also linked another thread Re:No usb detected on rpi4 with aarch64 which it also suggested to have the package mpg123 installed as well.

# dtoverlay=vc4-kms-v3d
dtparam=audio=on
hdmi_force_hotplug=1
over_voltage=6
arm_freq=2000

One must always remember that this may have been the settings for that particular setup. dtoverlay= for example was commented out.

But by now one must realize, that the most widely accepted configuration has been so far dtparam=audio=on. It has been brought up for many use cases before.

Of course. All of the above is assuming that another kernel, that of linux-raspberrypi4 would be installed to take care of this issue.

At Reddit for example, this has been also the accepted suggestion.

Need help with sound on rpi4

as one of the users said: I use the linux-raspberrypi4 kernel. Installed pulseaudio, ran it and everything worked perfectly. Don’t remember doing anything else other than selecting the correct output device.

Unfortunately, about a year ago or more when I installed arch linux arm on this particular model, I tried, albeit unsuccessfully to resolve this issue with this aforementioned kernel linux-raspberrypi4. It didn’t work. No sound was ever coming out of the headphones.

Another user who opened a similar topic outlining the problematic sound with rpi4 under Arch rpi4b: no audio device found in his case, the culprit seemed to stem from a permission issue with the file in question. Not in mine. I had also checked file permissions, but it was not causing the misdetection identifying the port.

Other posts such as this one for example at reddit with the title Rpi4 running armv7 archlinux , audio does not work through the onboard 3.5mm audio jack barely provided any insight at all.

Back to archlinuxarm.org there were other threads related with the underlying issue.

This one simply titled Re: No sound it specified to have

dtparam=audio=on

and

hdmi_drive=2

one of the users specified that: Without hdmi_drive=2 you should get sound from the jack on the rpi. , or by commenting it out. This was also specified before.

Of course. This is not the first time the fellow users over at archlinuxarm.org have had to deal with it.

In this thread with the title Analog Audio not working in rpi4

I am not getting audio from 3.5 mm audio jack in my raspberry
pi 4. I have done a clean install of arch. I have installed
pulseaudio, alsa-utils still iam not getting the audio.

I had also done the same, but to no avail.

the recommendaton for the op was, as in this reply Re: analog audio not working in rpi4

dtoverlay=upstream-pi4

This didn’t work either.

There were also a couple of suggestions or likely solutions to this issue with the rpi4, archlinuxarm and sound that ranged from the aforementioned websites dedicated to the arch linux arm wiki, as well as in the stackexchange network.

This one from archlinuxarm.org was titled: Rpi4 No Sound in which an error was preventing the user from running a script such as amixer -q cset numid=3 1

This one for example was also dealing the same issue of sound on te rpi4 and arch linux arm, and amixer cset numid command to execute

The question on the stackexchange network with the rpi, was No Audio Output on 3.5mm Jack

thes user wrote that

  I have tried turning up the sound in alsamixer as well as
  running modprobe snd_bcm2835. I have also tried to play
  the files with aplay rather than ncmpcpp with no luck.

one of the respondents (who also got the accepted answer for this sort of problem) said to have

amixer cset numid=3 1

He was quoted as saying on the answer that

   The last number is the audio output with 1 being the 3.5
   jack, 2 being HDMI and 0 being auto.

one must remember that the latter was, by the looks of it, posted as an acceptable answer to this particular problem before the question/answer came up from archlinuxarm.org.

modprobe snd_bcm2835

as well as aplay -L were implemented accordingly by this user in an effort to figure out what the problem might be with the sound and the rpi4 model.

https://raspberrypi.stackexchange.com/questions/13499/no-audio-output-on-3-5mm-jack

But more inquiries and suggestions may be further found with Google about this troublesome behavior. It certainly is one of the pressing outstanding issues with this awesome distribution and the model of the rpi4 in question

The Arch Linux Arm wiki, (which I’ll copy and paste) for example, states, in regards to the audio:

Raspberry Pi

Audio

alsa-utils should supply the needed programs to use onboard sound. Default volume can be adjusted using alsamixer.

A key change with Linux kernel version 4.4.x for ARM related to ALSA and to the needed sound module: in order to use tools such as alsamixer with the current kernel, users must modify /boot/config.txt to contain the following line:

dtparam=audio=on

Caveats for Audio

To force audio over HDMI, add this to /boot/config.txt:

hdmi_drive=2

If you experience distortion using the 3.5mm analogue output:

audio_pwm_mode=2

wiki

Source: https://archlinuxarm.org/wiki/Raspberry_Pi

Resolved with snd_bcm2835_enable_headphones=1

What worked in my case were a few lines on the configuration file that I personally never thought that were going to resolve the sound issue.

snd_bcm2835.enable_headphones=1
snd_bcm2835.enable_hdmi=1
snd_bcm2835.enable_compat_alsa=0

answer-snd-2835

Re: Pi4 - No hdmi audio Tue Jan 21, 2020 9:23 am

 HDMI audio should work in both ports, but there may be some config
 you can do to make it better.
 
 Add this to the end of the line in cmdline.txt file in /boot
 (all must be on the same line)
 
 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1
 snd_bcm2835.enable_compat_alsa=0

Slackware Startx Blank Screen Without Imobiledeviceglue

Blank screen kde plasma wayland on Slackware was the issue this time.

I had tried to run level 3 on slackware current kde plasma by invoking, as I had done before, startx on the system.

And with the most current slackware as of this writing, and after successfully upgrading the system, I was still unable to do so.

Some post dating back to 2019 https://www.linuxquestions.org/questions/slackware-14/slackware-current-kde5-startx-failed-4175662813/ pointed to do an upgrade. Of which I had done. So this suggestion led nowhere.

After checking many of the issues as described on linuxquestions which resembled some of the behavior such as logging in through level 4 on sddm as this one pointed out https://www.linuxquestions.org/questions/slackware-14/blank-screen-on-startx-for-kde-at-kernel-5-10-4-a-4175687833/page2.html

I couldn’t help but noticed that not only I was unable to log in through sddm but also a message that read the following:

The current theme can not be loaded due to the errors below, please select another theme:

file:///usr/share/sddm/themes/Breeze/Main.qml:14:1:plugin cannot be loaded for module "org.kde.plasma.core" cannot load library /usr/lib64/qt5/qml/org/kde/plasma/core" libcorebindingsplugin.so (libimobiledevice-glue-1.0.so.0 cannot open shared object file: No such file or directory)

This of course served no discernible help at all, as Google quickly confirmed, a search for bindingsplugin.so returned unrelated results while recently, as of today, a search on Google for <libcorebindingsplugin.so slackware> pointed out that the solution for the problem would be to slackpkg install-new. But for as long as I have updated the system on Slackware, with the kernel and packages, I have always foregone from invoking, even though is technically correct after a system upgrade, such command as slackpkg install-new.

By the time I had read that suggestion, which I noticed just now, as of this writing that it had been posted only a few days ago, I had already found, perhaps not as elegant, a solution on the system to invoke startx successfully.

Somehow while invoking kwin_wayland though startkwayland I noticed, unlike before, that was returning the error: /usr/bin/kwin_wayland: error while loading shared libraries: libimobiledevice-glue-1.0.so.0: cannot open shared object file: No such file or directory which quickly identified the culprit.

For one given reason or another (which I don’t know), it seemed that the file for this shared library was not installed afterwards. Perhaps the file was not using the same repo as the repo that was being used during the system upgrade. And that is most likely the cause. imobiledevice-glue was using another repo, not the one used during the system upgrade.

After installing it with slackpkg install imobiledevice-glue kde plasma was successfully loaded with startx.

Guake Module Not Found Pbr — no module named pbr

As I decided to run slackware current rather than 14.2, as I had done before, there were perhaps a couple of packages that although were not officially supported, had to be manually configured and compiled again.

Among these packages was the drop-down terminal guake. Unlike yakuake, which is normally configured without a major setback, running 14.2 required at one point to have vte3 installed, as well as pbr.

The latter one however, proved to be a chore.

The error error: invalid command 'bdist_wininst' kept coming up without further info. A quick googling around this problem led me to actually nowhere, since one of the comments mentioned about removing support for wininst but this https://github.com/pypa/setuptools/issues/857#issuecomment-273274212 dated as far back as 2017.

Another error that showed up — no matter what I did to circumvent it during the installation of guake — was the most infamous of all:

guake ModuleNotFoundError: No module named 'pbr'

And it made no difference whatsoever whether I had tried to install it to another path as the command pip install --user guake as the guake project suggested, or even a pip3 install guake as it had been previously suggested over at https://github.com/Guake/guake/issues/1328#.

Resorting to an old fashioned method such as python -m pip install guake as it was outlined on the documentation https://docs.python.org/3/installing/index.html had also proved as useless as anything before it. So there was no easily discernible workaround, or so it seemed, to resolve the issue.

Normally with pip the packages are installed under $HOME/.local/bin and even exporting the path made no difference either.

What gives at this point? The only difference with the current slack were a number of a few packages such as python3 and pygobject among many, that had been upgraded accordingly.

I even went as far as installing python3-setuptools on the system, but this, too, resolved nothing.

And when I tried to find all traces of guake on the system, it did showed up under both python-2 and python-3 dirs respectively. I still don’t know whether this may have been one of the underlying causes for the no module found pbr message though.

I also downloded guake sources directly from github, and compiled it from thnere, to no further avail either.

I had decided to almost give up on the issue, but as a last resort there was the possibility — even though the chances were slim or so it seemed to successfully install guake and/or pbr.

I went ahead and read on https://sbopkg.org/ after going around on an older thread from 2011 https://www.linuxquestions.org/questions/slackware-14/how-can-i-search-for-unofficial-packages-in-slackware-%2Apackages-like-guake-terminal%2A-888155/ that mentioned it.

After the initial setup and further reading through documentation for sbopkg, the first search directly from the terminal returned a no match found which took me back to Google again to see what this was about.

Therein one of the most relevant links pointed out to https://www.linuxquestions.org/questions/slackware-14/sbopkg-and-installed-sbo-git-packages-not-appears-4175632613/

Changed to the suggested directory and everything seemed to check accordingly. I had specified the repo directly from sbopkg and synced it afterwards. The configuration file rightly noted the changes.

The first install of guake, however, returned the same error as before. I decided to go ahead and remove removepkganything under /tmp/ with sudo privileges for both pbr and guake.

Surprisingly, it wasn’t until I specified the current Sbo-git and searched the packages interface for both pbr and guake later on, that the guake compilation went through without further error messages.

Guake returned no errors afterwards. As a matter of fact, I’m writing all of this, hoverever relevant it may be, (and acknowledging failure for not providing a back log that would detail all error messages with both pbr and guake during these unfinished compilations) by using this fast drop-down terminal. Yakuake also provides a similar interface, and many users from the slackware community may point out, and rightly so, that it works even better than guake, minus the aggravation with unofficial packages such as guake under slackware.

But the bottom line here is: I can’t recommend Sbopkg highly enough. Whatever the issue there was, with both pbr and guake, seemed to have been finally resolved.

I only wished I had tried sbopkg sooner.

Some notes with python3.9 and/or python3 that may be in conflict with sbopkg

I think this part is utterly important as well

First, and just as it was clarified before with the use of say, either python -m pip install guake or python3 -m pip install guake respectively. one must remember, as long as sbopkg is the preferential method to install guake, to either remove any of these packages.

Usually pip will install it under .local/ variables and place the executable under the same directory

If one were to invoke (as I had done before) plain pip uinstall guake

Then, it will only return, That is

.local/bin/guake
.local/bin/guake-toggle
.local/lib/python3.9/site-packages/guake-3.8.5.dist-info/*
.local/lib/python3.9/site-packages/guake/*
Proceed (Y/n)? n

Whkereas for example, running python on the other hand, with the correct python -m pip uninstall guake

will include most subdirectories under .local/

Found existing installation: guake 3.7.0
Uninstalling guake-3.7.0:
  Would remove:
    .local/bin/guake
    .local/bin/guake-toggle
    .local/lib64/python2.7/site-packages/guake-3.7.0.dist-info/*
    .local/lib64/python2.7/site-packages/guake/*
    .local/share/guake/po/LINGUAS
    .local/share/guake/po/ca.mo
    .local/share/guake/po/ca.po
    .local/share/guake/po/cs.mo
    .local/share/guake/po/cs.po
    .local/share/guake/po/de.mo
    .local/share/guake/po/de.po
    .local/share/guake/po/el.mo
    .local/share/guake/po/el.po
    .local/share/guake/po/es.mo
    .local/share/guake/po/es.po
    .local/share/guake/po/fa.mo
    .local/share/guake/po/fa.po
    .local/share/guake/po/fr.mo
    .local/share/guake/po/fr.po
    .local/share/guake/po/gl.mo
    .local/share/guake/po/gl.po
    .local/share/guake/po/guake.pot
    .local/share/guake/po/hr.mo
    .local/share/guake/po/hr.po
    .local/share/guake/po/hu.mo
    .local/share/guake/po/hu.po
    .local/share/guake/po/id.mo
    .local/share/guake/po/id.po
    .local/share/guake/po/it.mo
    .local/share/guake/po/it.po
    .local/share/guake/po/ja.mo
    .local/share/guake/po/ja.po
    .local/share/guake/po/ko.mo
    .local/share/guake/po/ko.po
    .local/share/guake/po/nb.mo
    .local/share/guake/po/nb.po
    .local/share/guake/po/nl.mo
    .local/share/guake/po/nl.po
    .local/share/guake/po/pa.mo
    .local/share/guake/po/pa.po
    .local/share/guake/po/pl.mo
    .local/share/guake/po/pl.po
    .local/share/guake/po/pt_BR.mo
    .local/share/guake/po/pt_BR.po
    .local/share/guake/po/ru.mo
    .local/share/guake/po/ru.po
    .local/share/guake/po/sv.mo
    .local/share/guake/po/sv.po
    .local/share/guake/po/tr.mo
    .local/share/guake/po/tr.po

The package pbr is also available on both sbopkg as well as through pip as well

What I have done in the past is to download and build throgh sbopkg just in case, there have been prior upgrades.

This is after downloading and building again:

Installing guake-toggle script to /tmp/SBo/package-guake/usr/bin

Slackware package maker, version 3.14159265.

Searching for symbolic links:

No symbolic links were found, so we won't make an installation script.
You can make your own later in ./install/doinst.sh and rebuild the
package if you like.

This next step is optional - you can set the directories in your package
to some sane permissions. If any of the directories in your package have
special permissions, then DO NOT reset them here!

Would you like to reset all directory permissions to 755 (drwxr-xr-x) and
directory ownerships to root.root ([y]es, [n]o)? n

Creating Slackware package:  /tmp/sbopkg.OElwoH/sbopkg-sbooutputdir/guake-3.7.0-x86_64-1ponce.tgz

./
install/
install/doinst.sh
install/slack-desc
usr/
usr/bin/
usr/bin/guake
usr/bin/guake-toggle
usr/doc/
usr/doc/guake-3.7.0/
usr/doc/guake-3.7.0/COPYING
usr/doc/guake-3.7.0/NEWS.rst
usr/doc/guake-3.7.0/README.rst
usr/doc/guake-3.7.0/guake.SlackBuild
usr/lib64/
usr/lib64/python3.9/
usr/lib64/python3.9/site-packages/
usr/lib64/python3.9/site-packages/guake/
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/PKG-INFO
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/SOURCES.txt
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/dependency_links.txt
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/entry_points.txt
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/not-zip-safe
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/pbr.json
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/requires.txt
usr/lib64/python3.9/site-packages/guake-3.7.0-py3.9.egg-info/top_level.txt
usr/lib64/python3.9/site-packages/guake/__init__.py
usr/lib64/python3.9/site-packages/guake/__pycache__/
usr/lib64/python3.9/site-packages/guake/__pycache__/__init__.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/__init__.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/about.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/about.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/boxes.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/boxes.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/callbacks.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/callbacks.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/common.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/common.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/customcommands.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/customcommands.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/dbusiface.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/dbusiface.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/dialogs.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/dialogs.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/globals.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/globals.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/gsettings.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/gsettings.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_app.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_app.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_logging.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_logging.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_toggle.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/guake_toggle.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/keybindings.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/keybindings.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/main.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/main.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/menus.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/menus.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/notebook.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/notebook.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/notifier.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/notifier.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/palettes.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/palettes.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/paths.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/paths.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/prefs.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/prefs.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/settings.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/settings.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/simplegladeapp.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/simplegladeapp.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/split_utils.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/split_utils.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/support.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/support.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/terminal.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/terminal.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/theme.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/theme.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/utils.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/__pycache__/utils.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/about.py
usr/lib64/python3.9/site-packages/guake/boxes.py
usr/lib64/python3.9/site-packages/guake/callbacks.py
usr/lib64/python3.9/site-packages/guake/common.py
usr/lib64/python3.9/site-packages/guake/customcommands.py
usr/lib64/python3.9/site-packages/guake/data/
usr/lib64/python3.9/site-packages/guake/data/__init__.py
usr/lib64/python3.9/site-packages/guake/data/__pycache__/
usr/lib64/python3.9/site-packages/guake/data/__pycache__/__init__.cpython-39.opt-1.pyc
usr/lib64/python3.9/site-packages/guake/data/__pycache__/__init__.cpython-39.pyc
usr/lib64/python3.9/site-packages/guake/data/about.glade
usr/lib64/python3.9/site-packages/guake/data/autostart-guake.desktop
usr/lib64/python3.9/site-packages/guake/data/guake-prefs.template.desktop
usr/lib64/python3.9/site-packages/guake/data/guake.appdata.xml
usr/lib64/python3.9/site-packages/guake/data/guake.glade
usr/lib64/python3.9/site-packages/guake/data/guake.template.desktop
usr/lib64/python3.9/site-packages/guake/data/org.guake.gschema.xml
usr/lib64/python3.9/site-packages/guake/data/pixmaps/
usr/lib64/python3.9/site-packages/guake/data/pixmaps/add_tab.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-128.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-48.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-64.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-notification.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-tray.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake-tray.svg
usr/lib64/python3.9/site-packages/guake/data/pixmaps/guake.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/intro-large.jpg
usr/lib64/python3.9/site-packages/guake/data/pixmaps/intro-medium.jpg
usr/lib64/python3.9/site-packages/guake/data/pixmaps/intro-small.jpg
usr/lib64/python3.9/site-packages/guake/data/pixmaps/quick-open-python-exception.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/quick-open-selection.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/quick-open.png
usr/lib64/python3.9/site-packages/guake/data/pixmaps/screenshot-fullscreen.jpg
usr/lib64/python3.9/site-packages/guake/data/pixmaps/screenshot-small.jpg
usr/lib64/python3.9/site-packages/guake/data/prefs.glade
usr/lib64/python3.9/site-packages/guake/data/search.glade
usr/lib64/python3.9/site-packages/guake/dbusiface.py
usr/lib64/python3.9/site-packages/guake/dialogs.py
usr/lib64/python3.9/site-packages/guake/globals.py
usr/lib64/python3.9/site-packages/guake/gsettings.py
usr/lib64/python3.9/site-packages/guake/guake_app.py
usr/lib64/python3.9/site-packages/guake/guake_logging.py
usr/lib64/python3.9/site-packages/guake/guake_toggle.py
usr/lib64/python3.9/site-packages/guake/keybindings.py
usr/lib64/python3.9/site-packages/guake/main.py
usr/lib64/python3.9/site-packages/guake/menus.py
usr/lib64/python3.9/site-packages/guake/notebook.py
usr/lib64/python3.9/site-packages/guake/notifier.py
usr/lib64/python3.9/site-packages/guake/palettes.py
usr/lib64/python3.9/site-packages/guake/paths.py
usr/lib64/python3.9/site-packages/guake/prefs.py
usr/lib64/python3.9/site-packages/guake/settings.py
usr/lib64/python3.9/site-packages/guake/simplegladeapp.py
usr/lib64/python3.9/site-packages/guake/split_utils.py
usr/lib64/python3.9/site-packages/guake/support.py
usr/lib64/python3.9/site-packages/guake/terminal.py
usr/lib64/python3.9/site-packages/guake/theme.py
usr/lib64/python3.9/site-packages/guake/utils.py
usr/share/
usr/share/applications/
usr/share/applications/guake-prefs.desktop
usr/share/applications/guake.desktop
usr/share/glib-2.0/
usr/share/glib-2.0/schemas/
usr/share/glib-2.0/schemas/org.guake.gschema.xml
usr/share/guake/
usr/share/guake/about.glade
usr/share/guake/autostart-guake.desktop
usr/share/guake/guake.glade
usr/share/guake/pixmaps/
usr/share/guake/pixmaps/add_tab.png
usr/share/guake/pixmaps/guake-128.png
usr/share/guake/pixmaps/guake-48.png
usr/share/guake/pixmaps/guake-64.png
usr/share/guake/pixmaps/guake-notification.png
usr/share/guake/pixmaps/guake-tray.png
usr/share/guake/pixmaps/guake-tray.svg
usr/share/guake/pixmaps/guake.png
usr/share/guake/pixmaps/quick-open-python-exception.png
usr/share/guake/pixmaps/quick-open-selection.png
usr/share/guake/pixmaps/quick-open.png
usr/share/guake/prefs.glade
usr/share/guake/search.glade
usr/share/locale/
usr/share/locale/ca/
usr/share/locale/ca/LC_MESSAGES/
usr/share/locale/ca/LC_MESSAGES/guake.mo
usr/share/locale/cs/
usr/share/locale/cs/LC_MESSAGES/
usr/share/locale/cs/LC_MESSAGES/guake.mo
usr/share/locale/de/
usr/share/locale/de/LC_MESSAGES/
usr/share/locale/de/LC_MESSAGES/guake.mo
usr/share/locale/el/
usr/share/locale/el/LC_MESSAGES/
usr/share/locale/el/LC_MESSAGES/guake.mo
usr/share/locale/es/
usr/share/locale/es/LC_MESSAGES/
usr/share/locale/es/LC_MESSAGES/guake.mo
usr/share/locale/fa/
usr/share/locale/fa/LC_MESSAGES/
usr/share/locale/fa/LC_MESSAGES/guake.mo
usr/share/locale/fr/
usr/share/locale/fr/LC_MESSAGES/
usr/share/locale/fr/LC_MESSAGES/guake.mo
usr/share/locale/gl/
usr/share/locale/gl/LC_MESSAGES/
usr/share/locale/gl/LC_MESSAGES/guake.mo
usr/share/locale/hr/
usr/share/locale/hr/LC_MESSAGES/
usr/share/locale/hr/LC_MESSAGES/guake.mo
usr/share/locale/hu/
usr/share/locale/hu/LC_MESSAGES/
usr/share/locale/hu/LC_MESSAGES/guake.mo
usr/share/locale/id/
usr/share/locale/id/LC_MESSAGES/
usr/share/locale/id/LC_MESSAGES/guake.mo
usr/share/locale/it/
usr/share/locale/it/LC_MESSAGES/
usr/share/locale/it/LC_MESSAGES/guake.mo
usr/share/locale/ja/
usr/share/locale/ja/LC_MESSAGES/
usr/share/locale/ja/LC_MESSAGES/guake.mo
usr/share/locale/ko/
usr/share/locale/ko/LC_MESSAGES/
usr/share/locale/ko/LC_MESSAGES/guake.mo
usr/share/locale/nb/
usr/share/locale/nb/LC_MESSAGES/
usr/share/locale/nb/LC_MESSAGES/guake.mo
usr/share/locale/nl/
usr/share/locale/nl/LC_MESSAGES/
usr/share/locale/nl/LC_MESSAGES/guake.mo
usr/share/locale/pa/
usr/share/locale/pa/LC_MESSAGES/
usr/share/locale/pa/LC_MESSAGES/guake.mo
usr/share/locale/pl/
usr/share/locale/pl/LC_MESSAGES/
usr/share/locale/pl/LC_MESSAGES/guake.mo
usr/share/locale/pt_BR/
usr/share/locale/pt_BR/LC_MESSAGES/
usr/share/locale/pt_BR/LC_MESSAGES/guake.mo
usr/share/locale/ru/
usr/share/locale/ru/LC_MESSAGES/
usr/share/locale/ru/LC_MESSAGES/guake.mo
usr/share/locale/sv/
usr/share/locale/sv/LC_MESSAGES/
usr/share/locale/sv/LC_MESSAGES/guake.mo
usr/share/locale/tr/
usr/share/locale/tr/LC_MESSAGES/
usr/share/locale/tr/LC_MESSAGES/guake.mo

Cannot Convert String Helvetica Medium to Type Fontstruct

This could very well qualify among one of the most pesky annoyingly error messages that one could ever come across, under the X window system. Of course there are many other errors that are certainly more problematic, but the aformentioned warning is one that requires, as I’m doing now, to write a few words about it.

In the past, by simply installing any of the xorg-fonts-75dpi and/or xorg-fonts-100dpi packages, would have gotten this issue resolved.

One could further consult similar posts under the Arch forum that inquired about this problem. See missing helvetica font or also Fonts: cannot convert string… to type Fontstruct, or even albeit unrelated — since this issue at this other site, was concerned under another program perhaps — on the linuxquestions forum entitled Error message regarding fonts in grace

But this time around, there must have been some sort of update that most likely has been breaking up the way that a non error, and consequentially working without a warning of any kind would come up under the X system.

Invoking xlsfonts | grep helvetica was not returning anything for that matter, and restarting the system a great number of times failed for not showing the error/warning and ‘fixing’ the underlying issue either.

The only way to circumvent it this time around, was by installing the adobe-base-14-fonts from the AUR repositories. Something that, as I already said, never had to be include it, to have the error/warning not coming up.

Further resources about this package may be found at https://aur.archlinux.org/packages/adobe-base-14-fonts/

Error Bash Completion No Such File or Directory

I wouldn’t know where to look —- I certainly can browse the repo from Debian reposotiry — or where bash completion is usually installed on Debian-based distributions. It’s been a while since I have used these kind of systems. But after all, this is irrelevant. Even as popular as this distro may be, not everyone uses it.

A quick glance at the files that comprise this program, one could see that aside from the usr folder, bash completion is also installed under etc and bin accordingly.

Bash completion allows to fill in the rest of the commands or variables that follow for given executable.

See Bash autocompletion for more details about its chock features’ versatility.

In the case of Arch, the installation does not create — unlike on Debian — the folder bash_completion under etc. And I don’t think this may have been an oversight from the Arch team, but presumably and perhaps due to safety reasons, this was something that was never considered in the first place.

Other programs have had no issue by correctly including on the script the means to have it install appropriately. But it’s my opinion — and anyone is more than welcome to disagree with me here — that many a great number of programs have not chosen to do so or failed altogether in this regard. Hugo for example is one of them. See for example the destination directory when this feature was added. See the commit here.

To resolve this issue, the most viable solution is to manually add the folder, from whence this error stems, or else the messageError: bash_completion.d: hugo.sh no such file or directory will disallow the autocomplete which was added to the binaries of this program, to come into effect.

Hwclock Timedatectl

Setting the time and date by invoking hwclock --systohc or by hwclock --hctosys should always be followed by localtime rather than say by --utc wich is the Universal Corrdinated Time.

On the other hand, if multiple systems are to be used, it may be useful to better have the hardware clock synchronized in UTC in case that time zone and DST Daylight Savings Time come into effect.

Omitting appending something as simple as --localtime would certainly display the UTC on multiple systems under any hardware.

In case of any trouble setting it up afterwards may resolve the issue

timedatectl set-timezone 

Alternatively, one may invoke:

hwclock --set --date 'mm/dd/yyyy 00:00:00'
hwclock --hctosys --localtime

Alternatively, if there’s any problem with the above, the https://wiki.archlinux.org/title/System_time#Troubleshooting

Troubleshooting

Clock shows a value that is neither UTC nor local time

This might be caused by a number of reasons. For example, if your hardware clock is running on local time, but timedatectl is set to assume it is in UTC, the result would be that your timezone’s offset to UTC effectively gets applied twice, resulting in wrong values for your local time and UTC.

To force your clock to the correct time, and to also write the correct UTC to your hardware clock, follow these steps:

  • Setup ntpd (enabling it as a service is not necessary).

  • Set your time zone correctly.

  • Run ntpd -qg to manually synchronize your clock with the network, ignoring large deviations between local UTC and network UTC.

  • Run hwclock –systohc to write the current software UTC time to the hardware clock.

Pamac Gui Wps Office Curl 22 The Requested URL Returned Error 416

On a recent WPS upgrade through pamac gui, there was a somewhat inconvenient curl: (22) The requested URL returned error: 416 error which I wasn’t ready for, at the time it happened.

All the updates had gone through any major problem, but this seemed to go on.

I had no issues elsewhere and with another system in which the updates went through without any setback there seemed to be no issues either.

Even after updating the mirrorlist, I was still facing the same problem.

A quick google search led me to, among the most relevant results, a post that was entitled wps-office: failure while downloading that was brought up by the manjaro distro users to the devs - the latter group is after all, the one behind the development of the pamac graphical interface program - in which some folks pointed out the possibility of a network problem. Unlike the op issue, mine had primarily to do with an upgrade of the wps suite, and not an installation or reinstall. And also, just as another user stated on the same forum, I had made sure that the network paralleled culprit wasn’t preventing the upgrade of wps from happening.

Since wps office is provided by AUR which is the largest unofficial repository package t Arch Linux, the best course of action was to reset the upgrade through the pamac program itself.

Wps Office Spanish Dictionary

I’ve installed many text formatting processors over the years, or as they are simply abbreviated with the acronyms WYSIWYG…

Although many users prefer the advantages provided by a cloud stored-word processing program such as the one provided by Google, I tend to steer away from it mainly because of response time within the application.

But I’m not oblivious either to the fact that the versioning control system as it was implemented by Google, is surely a breakthrough innovation among these programs, which needless to say, many of these other programs - including the one provided by Microsoft - at least the one provided for local installation - has failed to develop such a feature.

For this simple implementation alone I consider it an advantage over any desktop solution.

But when it comes to locally installed programs, I’ve tried to consider the pros and cons and one way or another I’ve always tried to install - as I said earlier - the one with the overall best response time…

For this reason alone - notwithstanding the license under which the program is developed and which its devs and maintainers have put it in use, and which I always encourage to go over some its terms to clarify any further ambiguity, and also without disregarding either the proprietary background of the company Kingsoft Office, which is the one that came up with the product, wps office for linux provides almost exactly, what a vendor such as the program that Microsoft has been able to successfully come up with over the years: a whole suite of spreadsheet, word processor, and presentation programs.

As it’s usually the case whenever I’m using this program, I’ve always toggled back and forth between languages and the dictionaries in use, and even though is no less true that one could easily go directly to whatever pre-compiled version the distribution has put together for the user, to have it installed on the machine nonetheless – along with the language pack for it – , is not clearly documented. And to make this issue less straightforward than what it ought to be, the devs have modified or for a better usage of the word - have diverged over the years as to where the destination directories for these dictionaries are to be placed under.

For example, at one given point in time, the company provided the download link for the language of choice by making it available by simply clicking directly on their website, but for one reason or another I’ve recently found that the link was no longer accessible.

As I’ve said before, the distro would most likely have the language pack of choice available for the system.

But I personally didn’t want to go this route this time around neither, and wanted instead, to install the language pack so the program would identify it.

The destination for the dictionaries is not under .local but rather over at

/usr/lib/office6/

therein another subdirectory under dicts aptly entitled spellcheck/ which further shows the default language directory - which is normally en_US in this case, is the folder from which the program would first look up any relevant file to be loaded.

The language pack dictionary for wps-office namely provides three (3) files with the suffixes:

  • *.dic
  • *.aff
  • *.conf

All of these files must be copied over to a newly created directory under the same subdirectory dicts/spellcheck as it was outlined earlier.

Make sure the directory for which these other language files are to be put under, is either copied in its entirety - the whole directory with all the aforementioned files - or that the directory in question is indeed created from scratch… There’s no other way around this issue, as long as wps-office identifies and recognizes multiple dictionaries to be loaded up as soon as the program starts.

The filenames for all the dictionaries - whether these are from the packaged en_US, or en_GB, or es_ES, or es_MX etc all have identical names, thus:

  • main.dic
  • main.aff
  • dict.conf

comprise the file directory list….

That’s why I - without trying to sound pedantic - brought up the reason as by which one must be careful, not to simply copy over just the additional files for the other language to be used, as this could potentially overwrite the rest.

The other option would be by trying to rename the files – from say a hunspell installation – to main.aff, main.dic, and modifiy the contents of the file dict.conf respectively to the preferred language in question.

Sed and Awk to Print Ranges

sed and awk are very powerful tools that would yield results unlike anything else in *Nix.

Although one could certainly create constructs within say a bash script that would give it further fuel, it comes handy to have it as it’s always the case: available, for even other menial tasks.

Printing a given range of lines would undoubtedly come practical during those times when simply displaying them directly by invoking the manual is proven not to be the most straightforward method.

So for this purpose both sed and awk serve me well.

If I were to invoke with sed a certain range of lines to print say from the XParseGeometry manual or from any other file on the system, filtering it out gives - as the proverbial saying goes - power for the money.

Yes, it helps to have the entire man pages on the terminal, but it wouldn’t filter out the results as I have wanted it to. One may try by using grep but I wasn’t interested this time around to use it.

So

man XParseGeometry | awk 'NR==20,NR==40' 

would hence return:


       display   Specifies the connection to the X server.

       fheight
       fwidth    Specify the font height and width in  pixels  (increment
                 size).

       parsestring
                 Specifies the string you want to parse.

       screen    Specifies the screen.

       width_return
       height_return
                 Return the width and height determined.

       xadder
       yadder    Specify  additional  interior padding needed in the win‐
                 dow.

       x_return

returned what I was after..

With sed things are perhps easier, and a great many users recommend to go this route for simple tasks such as the one I usually encounter.

on the terminal

man XParseGeometry | sed -n '20,40'p

would rightly return:


       display   Specifies the connection to the X server.

       fheight
       fwidth    Specify the font height and width in  pixels  (increment
                 size).

       parsestring
                 Specifies the string you want to parse.

       screen    Specifies the screen.

       width_return
       height_return
                 Return the width and height determined.

       xadder
       yadder    Specify  additional  interior padding needed in the win‐
                 dow.

       x_return

which gives me exactly what I was after….

Of course, the magic of Unix doesn’t stop there. One could further delve into even more commands to give both sed and awk an unimaginable power for pattern searching without having to entirely grep it…

Having other simple tasks such as looking up particular pattern on a given file, is much more easier which could print out the results satisfactorily….

for a given file x

sed -n '2,4'p <filename>

and through awk a simple

awk 'NR==<range>,NR==<range>' <filename>

should suffice.

Further reading

https://www.grymoire.com/Unix/Sed.html

https://www.grymoire.com/Unix/Awk.html

Fc-List Get Fonts

It’s always nice to have a ‘cheat sheet’ summary of all sorts Unix to remember certain programs

I usually have Lua looking this up for me through otf and ttf fonts, but it’s been a while since I went this route.

fontconfig takes care of all font-related

fontconfig takes care – as the freedesktop.org website states to

  • discover new fonts when installed automatically, removing a common source of configuration problems.

  • perform font name substitution, so that appropriate alternative fonts can be selected if fonts are missing. identify the set of fonts required to completely cover a set of languages.

  • have GUI configuration tools built as it uses an XML-based configuration file (though with autodiscovery, we believe this need is minimized). efficiently and quickly find the fonts you need among the set of fonts you have installed, even if you have installed thousands of fonts, while minimzing memory usage.

  • be used in concert with the X Render Extension and FreeType to implement high quality, anti-aliased and subpixel rendered text on a display.

But it does not provide any searching mechanism to look up a particular font on the system. Or at the very least not one that I’m aware of anyway..

On the other hand, fc-list does list the fonts available on the system…

The only caveat is that if I were to try to get the family name of the glyph in question, fc-list does provide it, but I would need to further grep it in order to not get a bunch of results.

fc-list is simply put:

FC-LIST(1)                                                     FC-LIST(1)

NAME
       fc-list - list available fonts

SYNOPSIS
       fc-list  [  -vVh ] [ --verbose ] [ -f format | --format format ] [
       -q | --quiet ] [ --version ] [ --help ]
           [ pattern  [ element ... ]  ]

DESCRIPTION
       fc-list lists fonts and styles available on the system for  appli‐
       cations  using  fontconfig.   If  any elements are specified, only
       those are printed.  Otherwise family and style are printed, unless
       verbose output is requested.

a printing mechanism to list the fonts on the system.

grep [ing] the font itself through the program, filters out the family name of the font as well - and whether these are otf or ttf.