May 22, 2022
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
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
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
Jan 18, 2022
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
.
Oct 27, 2021
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 removepkg
anything 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
Dec 20, 2020
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/
Jun 9, 2020
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.
Jun 8, 2020
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.
Mar 5, 2020
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.
Dec 30, 2019
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:
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.
Dec 27, 2019
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
Dec 23, 2019
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.