May 29, 2018
Running one of the usual updates from the pamac gui package, returned
pamac: installing pacman (5.1.0-1) breaks dependency ‘pacman<5.1
I noticed that any package on the list with a dependency must be
unchecked before continuing.
Later I checked the antergos forum to see if there was any solution.
The suggested workaround was to run
pacman -Syyu -d --nodeps
The following commit apparently introduced the issue in the first
place:
https://git.archlinux.org/svntogit/packages.git/commit/?id=e9272fcb3289f875b1a14222fb17f9185274107f
Jan 27, 2018
One of the drawbacks during the installation of Antergos Linux was in identifying the keyboard layout option that was previously selected during the media installation.
As a result only the default variant was being used after installing the system.
I was able to identify the problem by going to the X window system xorg configuration file /etc/X11/xorg.d/00-keyboard.conf and noticing that the XkbLayout variant was not being properly identified as originally intended.
In my case, only one of the options had been specified correctly on the 00-keyboard.conf file.
What I found odd, is that on another system, which is by the way, running the same xfce environment from Antergos, the same problem was not encountered. On the other system, only one (1) variant was used, and it had correctly identified the layout twice, but on the system which after installing the Antergos media, loaded the incorrect values, two (2) variants were set accordingly, but only one (1) layout option was identified. In my case us had been been identified once, whereas with the former no issues pertaining to this problem occurred in the first place.
As the wiki Using X configuration files wiki recommends, not to modify any of the settings manually, but let instead localectl handle it. 1
Of course, it comes handy when there is even an example that illustrates the process by using the correct parameters. For something like:
Then something like the following 2, based on the previous example, suffices:
Set the values as deemed applicable to the desired customization.
References
Using X Configuration files 00-keyboard.conf ↩︎
Using localectl ↩︎
Jan 20, 2018
During the installation of Antergos, there was an option to install the Linux LTS kernel along with the default latest stable version.
Even though it was installed appropriately, the option to select the other kernel, could not be seen from the Grub selection window.
this is even after running the usual mkinitcpio -p <linux kernel> that loads the modules and other dependencies accordingly.
It’s good to remember that Grub configuration file though, resides on the /boot/default directory.
With sudo privileges, access the file at /boot/default/grub first.
Therein, and lying at the bottom of the configuration file, one can find the:
# Uncomment to make GRUB remember the last selection. This requires to
# set 'GRUB_DEFAULT=saved' above.
#GRUB_SAVEDEFAULT="true"
One could uncomment the GRUB_SAVEDEFAULT=“true” so the grub configuration file ‘remembers’ the selection.
Furthermore, and right on the top of the file the default chosen selection can be specified by modifying the value of 0:
GRUB boot loader configuration
GRUB_DEFAULT=0
To a 2 or 3 for the desired kernel. Which in my case, and if the LTS kernel is to be loaded instead, matched the kernel itself and the fallback for it.
By going this route, it no longer is necessary in specifying during the system startup, the desired kernel that one chooses to be loaded.
Remember after making any changes to grub, to update the configuration file by running:
grub-mkconfig -o /boot/grub/grub.cfg
For more info about this, visit the wiki:
GRUB/Tips and tricks
Jan 16, 2018
It is my opinion, based mostly not on what I’ve read, but instead on what I’ve encountered during the handling of a failed hard disk, that the disk volume mounting utility udisks2 fares better than say, ntfs-3g.
Quite possibly there could be many improvements with this software, and there is no doubt about it, but considering wear-and-tear conditions of the disk, among other considerations, and, as long as udisks2 is run without an interruption, no other mounting options utility that is currently available may be able to improve its overall performance.
If time is not a constraint, and the program is allowed to run on its own, udisks2 fares relatively better on previously loaded Windows OS partitions than any other. Of this I can attest without a doubt. The utility has been able to eventually access corrupted filesystems that would have been rendered unrecoverable otherwise
For futher info and configuration, visit the wiki:
Mount to /media (udisks2)
Udisks
ntfs-3g Arch Linux
udiskie on github
Dec 22, 2017
One of the easiest ways to remove all metadata from a file, is by invoking 1
$ exiftool -all= <file>
However, this has the inconvenience of providing a security risk by reversing it as well with:
$ exiftool -pdf-update:all= <file>
which pretty much inserts the metadata back into the file:
According to the author of exiftool this can be circumvented by issuing qpdf --linearize <file.in> <file.out>. For further info about this see:
PDF tags
References
exiftool man pages _↩︎
Dec 16, 2017
MTP implementation runs on most desktop environments without a problem. Except on KDE where it has had several problems in identifying and initializing a simple file from any of the devices that have been connected to the system, mainly through the USB port.
It’s really a shame that although Plasma KDE fairly supports Bluetooth protocol better than the rest of other desktop environments, it largely fails with both gwenview and its default Dolphin manager to open up files directly.
I have tried in a great many occasions to slither out many of these KDE errors by falsely attributing it to my lack of knowledge on its usage. But I can’t deny any longer that the system either works or it doesn’t. And one should no longer have to wait who-knows-how-long-and-when, before updates smother out its deficiencies.
Yes, I have tried to look up for the issue elsewhere such as as in mtp mount issues in KDE/Dolphin, but many of the suggestions have not worked so far.
Whereas with KDE, to my amazement - because at this point of its developmental phase, one would think that it should perform better and not worse - the problems all range from mild to critical, while xfce on the other hand, these unexpected malfunctions and sudden out-of-the-blue crashes do occur but at a lesser degree, and when one of these errors undermines the stability, the errors do not necessarily affect the overall functionality.
I experienced and spoke at somewhat length about a manjaro kde error unknown application post.
In the wake of recent Bluetooth vulnerabilities that have happened,1 and the history behind it in which several authors have researched the issue,2 it makes no sense to have a whole interface that handles this protocol better than most environments and yet fails when the to-be-expected approach to handle it differently or by using the right terminology, handling it without bluetooth at all in light of everything that has happened with it, by going directly through the use of the mtp protocol that is supposed to take care of it. Notice that mtp is supported without a major flaw in xfce, Gnome, and others.
For further reading about MTP, is advisable to visit the formidable wiki from Arch Linux at MTP
It turns out that kio-extras is a dependency of Kde’s dolphin file manager, which apparently is partly responsible for the failed to initlialize error, but whichever is to be blamed in this regard, matters for as long as the user finds the KDE environment worthy to be used. In my case perhaps, the same opinion that for so long I’ve had of the software, has notably changed amid these recent problems: first with the manjaro kde error unknown application instance as highlighted earlier, and now with the bluetooth problem.
Perhaps is worthy to revisit this desktop environment, but for now, it is in my opinion that there are better options out there from which to choose from, before having to put up with the inconsistencies and failures that have rendered the systems I have been running lately, useless in more than one occasion.
References
Blueborne vulnerabilities impact devices_↩︎
Technical papers that include Bluetooth vulnerabilities are as follow Security Risks in Bluetooth Devices, and Bluetooth security threats and solutions ↩
Dec 14, 2017
It’s apparently a foolish idea to login as root from a file manager on Plasma KDE.
This was exactly what caused a number of problems, and among them, most notably, that I could not get past the login screen.
Of course, little did it matter that I installed any of the other display managers available and removed the current in use from the command line. I was still unable to get past the login screen.
In other words, it wasn’t just the usual login failed which indicates the wrong username and/or password. This was exactly the opposite, as after inputting the password for the system, since login automatically was disabled, the screen would fall back as if it loading the kernel again, and then without further ado, back into the login screen.
This feedback loop process was endless. I couldn’t but scourge on Google for some sort of information regarding the issue.
One of the first queries to Google was with the terms plasma kde fails to startx, although I knew that the last element of the query was not the most accurate. For one, because the X server was somehow running, or else how could I have a login screen in the first place. But almost unsurprisingly, the first result from Google was from the Arch Linux forum entitled Cannot start plasma 5.
I tried to follow one of the recommendations and modify the last line to
exec startkde
but it made no difference.
Perhaps on other desktop environments the change on .xinitrc was a success, but at least on Manjaro Plasma KDE, all of it was failing and I was not able to get past the login screen.
For example, the suggestion to modify the .xinitrc on the xfce desktop environment have proven to succeed without any major problem.
See for example Can’t get past the login screen, where modifying the .xinitrc was more than enough to get it started.
At this point it was futile to modify any further the .xinitrc initialization file when moments before I had restarted the system, an error related to Plasma KDE had popped up on the screen:
A couple more errors from the main file manager Dolphin showed for example the following:
And also
At this point, after the infamous error with the kio_applicationsrc, I very well knew that the culprit of it all occurred when trying to login as root to Plasma from the Dolphin file manager.
Later on, after giving up the have Manjaro KDE running on the system, I found a few posts that spoke about logging in as root on the Plasma environment.
On the same post that for example was highlighted earlier, there is useful information as why running as root as KDE is altogether discouraged:
Dec 13, 2017
During the last setup of Hugo, I was faced again with the sometimes difficult handling of submodules. This was of course after the corresponding configuration for the user.name and user.email had already been set accordingly.
The next error which dealt with the git submodule was that it already existed in the index. Which made me look it up on Google.
Among the first results that came up after my query, was the following from the stackoverflow site at the StackExchange Network, entitled Issue with adding common code as git submodule: “already exists in the index”
The answer that has been widely accepted included as a solution having to invoke the git rm --cached projectfolder on the tree of the folder.
After issuing it:
$ git rm --cached .git/public
fatal: pathspec '.git/public' did not match any files
Which clearly led me nowhere, I noticed that further implementing correctly the command would require a few more steps.
The command git push origin master indicated that origin did not appear to be a git repository.
$ git push origin master
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
It was only after I invoked the git rm -rf public which seemed to fix the problem:
$ git rm -rf public/
Migrating git directory of 'public' from
'/public/.git' to
'/.git/modules/public'
rm 'public'
This seemed to at least tell me that the public folder had been removed. So apparently the --cached flag did nothing in this regard.
Next, by using the <tab> key for autocompletion, right after the directories, I invoked git rm -rf .git/modules, which showed the number of possibilities as shown below:
$ git rm -rf .git/modules/
about index.html
config.toml index.xml
config.yaml js
content page
"content post
css "post
deploy.sh sitemap.xml
.gitmodules static
google4417fd3500b3c667.html "static
images tags
"images themes
img topics
Then again, I completed the git rm -rf with the corresponding public folder:
$ git rm -rf .git/modules/public/
fatal: pathspec '.git/modules/public/' did not match any files
Which unfortunately again, came back with the fatal: pathspec error from before.
What worked, was to have the option --cached, to be implemented right after git rm only recursively with the .gitmodules.
So that was
$ git rm --cached .git
.git/ .gitmodules
Which finally after tab completion:
$ git rm --cached .gitmodules
rm '.gitmodules'
So it seems the git rm --cached worked with the .gitmodules, but it did not succeed with the .git/modules/public directory.
It was only after I invoked the Unix command rm -rf under the .git directory, that the problem was finally resolved.
$ rm -rf .git/modules/public/
After it, the submodule was added again with the
git submodule add -b master <name of static repository> public
As shown below:
$ git submodule add -b master https://github.com/<username>/<static repository> public
Cloning into '/public'...
remote: Counting objects: 2075, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 2075 (delta 74), reused 114 (delta 31), pack-reused 1907
Receiving objects: 100% (2075/2075), 4.06 MiB | 2.17 MiB/s, done.
Resolving deltas: 100% (1247/1247), done.
$
The step-by-step instructions by simply issuing rm -rf public as the tutorial to have Hugo running on Github suggested, did not work in this case, for the simple reason that the git repository was cloned during the initial setup.
The .git/modules/public already existed as a result. So it had to be removed by issuing rm -rf .git/modules/public before setting up again the submodule remote repository.
Dec 9, 2017
While updating a fresh installation of Manjaro KDE, the screen locked.
Apparently the default settings for the system, enabled this behavior without
further ado.
As a result of this problem, the surprising part came afterward when the updates that were being downloaded, suddenly crashed the system. This led to the nonetheless bothersome problem of modules.devname not found error followed by the no more troublesome error you are now being dropped into an emergency shell and sh can't access tty; job control turned off.
I didn’t have at the time a live media to access the system. Although I knew the that the sudden crashing during the download of updates , was one of the problems underlying the modules.devname not found error.
A quick google searched returned Manjaro fails to boot, modules.devname not found a result which provided an answer that pointed to access the system with Manjaro’s own mhwd-chroot command to access the emergency shell. See Chroot into your existing Manjaro Installation
And as the already mentioned answer on the unix.stackexchange.com site suggested, it was necessary to reload the image again.
Dec 6, 2017
Configuring the kakoune text editor
initialization file has been nothing short of a chore, as it requires
the path environment to be correctly set, before any changes on the
kakrc take ahold of the settings.
As the tutorial suggests, see Configuration and
autoloading,
if it is launched with the -n switch, kakoune will source the
../share/kak/kakrc, but on a unrelated issue but nonetheless relevant
about the correct location for the initialization file, the developer
clearly stated that:
The kakrc file in share is Kakounes init script, it is not intended to
be user edited. It is actually that script that will load your user
configuration in ~/.config/kak/kakrc.
See clang completion
#1102
Thus, it is necessary to set the environment first on any Unix system.
The command setenv is used for the csh shell, whereas in bash,
this is accomplished through the export command.
To find out whether for example, XDG_CONFIG_HOME was set, is necessary
to invoke on the terminal:
printenv XDG_CONFIG_HOME
which if it does not return a value, the environment has not been set
yet.
To set the environment across sessions, note it accordingly on your
bashrc file with the export command:
export XDG_CONFIG_HOME=$HOME/.config
create a directory kak under that environment, and further create
your init file kakrc
Most of the available settings will be available without further
modifications. That is, some of the commands that are loaded by not
using a kakrc file, will not have to be further tweaked with.
colorscheme <tab completion> <name of theme>
can be identified without a problem.
There are, however, a handful of those that would have to be further
tweaked with, in order to load the kakrc init file correctly.
Take for example, autowrap-enable, which normally applies soft wrap
manipulation to the lines.
According to the developer,
autowrapping is provided by the autowrap.kak script (which should be
loaded by default), enable it for a buffer with the autowrap-enable
command, that you probably want to put in a hook (for example if you
want to always enable autowrap, add hook global WinCreate .* %{
autowrap-enable } in your kakrc. the autowrap_column option controls
the column on which to autowrap.
See Noob questions
Further customizations to map certain keys are also necessary.
For example, to map the \ backslash key to say the ; semicolon.,
it’s imperative to precede the ** key with the % percent sign and
further enclose the \ backslash key within curly brackets {}, so the
final code would be something like:
map buffer insert %{\} ';'
of course, if the settings are desirable to be loaded globally, then
map global insert %{\} ';'
needs to be specified accordingly on the initialization file.
See for example this issue: can’t map to
backslash, which touched
upon the problem, and further linked
https://github.com/mawww/kakoune/issues/1049 and
https://github.com/mawww/kakoune/issues/1221
It’s certainly two-fold that by specifying:
map buffer insert ';' \
the behavior to have the \ inserted, is easily accomplished, as shown
on the example above, but the same is not true, by having the same
characters inversed within the strings, that would yield the correct
results.
for example whereas
map buffer insert ';' \
is correct, a simple map buffer insert '\' ;
throws an error with the message
parse error: unterminated string '...'
It’s therefore necessary to have:
map buffer insert %{;} \
the same is true if one were to map buffer insert '\' %{;}
one of the methods that would work across buffers, is to have such
characters enclosed within curly brackets and further preceded by the
% sign
map buffer insert %{\} %{;}
and
map buffer insert %{;} %{\}
:::
:::
:::