Nov 23, 2019
It was odd that seemingly identical pamac installations loaded onto very similarly configured machines, were somehow behaving differently on a great many occasions.
Both pamac versions had been downloaded and configured and compiled apparently via the same procedure. Both systems also had been configured not much that different from one another. But on one of the systems, pamac would eventually return an error during the same updates.
Pamac would simply hang, egregiously stuck at either:
checking inter-dependencies
or during
checking inter-conflicts
Of course, I could have just dismissed all these errors and be happily content to just get rid of this nonsense by removing pamac altogether and start afresh from the official package manager, but I would have never been happy by either settling these problems through such trivialities, as long as another system, on which the very same package was installed, was not showing the same behavior.
Had it given me a problematic workaround at the very least - on the other system that is, which was working flawlessly nonetheless, -there would have been no doubt that I wouldn’t have even considered this extraneous interface to start off with, and would have gone instead through pacman directly. Or I could have taken further steps and try to at least, file a bug report as the Arch Wiki suggests. But I always liked the design idea behind this graphical interfaced package provided with its updates’ notifications, which unlike pacman that would have required to manually tweak checking for these updates.
But as it’s usually the case, pacman was downright correct by identifying as closely as possible the culprit by which the system itself held files already in filesystem. This was clearly the case with the package gtk-doc, and somehow this conflict had to be resolved.
But what I don’t know, and it’s my mistake since I didn’t venture out - either at the time when it first occurred -, and much less now, because it’d be a wildly-guessing why would this be the case, that even when two systems configured alike which in turn held the same package revisions, were somehow behaving disparagingly different.
I was not able to remove it [gtk-doc], by invoking pacman alone - as there was another error that disallowed me to do so. And I was simply sloppy back then, as I’m perhaps now to single out and summarize each of the problems that had I encountered during the installation for the new version of pamac, and to to have kept working errors’ copies handy, as this would have provided a somewhat more acceptable idea where the problem lied at.
I did however, tried to stay as far away as possible from manually removing each of the files installed by the package [gtk-doc], but unfortunately after many unsuccessful attempts to install another pamac version, this predictable painstaking process, that of having to go and remove each file owned by the package, seemed to be the only inevitable method to circumvent this problem.
After going through each subsequent step during removal and by successfully reinstalling the same package over again, pamac has been working - so far - without a glitch. If it stays as such, is yet to be determined. I could no longer assure it… but it gives me pause and comfort in knowing that checking inter-dependencies or checking file-conflcts rolling hangs haven’t returned to this annoyingly halting process.
Nov 1, 2019
Libalpm is the library for package management of Arch.
I found it funny that in case of any bugs the team says
Bugs? You must be kidding; there are no bugs in this software. But if we happen to be wrong, submit a bug report.
But they’re right. When it comes to package management handling, Arch offers unlike any other one out there, the quirks and perks that not even a propietary coding scheme such as Homebrew, Fink, Macports from OSX Cocoa could even think to come close during its best moments. This is not to illegitimize whatever accomplishments have been put together by these teams, but it’s still disparately sub-par compared to what Arch has offered.
During the last kernel update there was a problem with pamac though
Firing it up from the terminal was simply returning an
error while loading shared libraries: libalpm.so.11: cannot open shared object file: No such file or directory
Which considering how lazy I’ve become over the years, and even more so after reading articles a few years ago such as Is Google making us stupid by Atlantic technology writer Nicholas Carr, I couldn’t wait to gobble it up or try to leave it up to Google to offer the best match to this undesired behavior I was getting.
The first query by the algorithms of Google returned an issue over at yay: error while loading shared libraries: libalpm.so.11: cannot open shared object file: No such file or directory
But thinking about it again, the issue pertained mostly to aur.archlinux.org/packages/yay/ which I’ve never installed. Perhaps I had done it years earlier on another different system, but not on the current machines I’ve been running.
The second queried result though, took me to Arch Linux: package-query: error while loading shared libraries: libalpm.so.11, but as soon as I read about making a symbolic link, which the author of article rightfully pointed out that although it could be done, is not recommended and just plain wrong to go that route..
The other solution from the same article, involved reinstalling aur package query, but then again, I didn’t even have package-query on that particular system…. and unfortunaetly reinstalling pamac didn’t resolve the issue as he had stated it.
Downloading the newest version and configuring it later on did the trick…
Somehow it seemed that during the latest upgrade, the installation of pamac, which occured during the same kernel upgrade and which it was done by the interface itself did not go as planned….
This had to be done again not only with makepkg but with a newer version, in order to have it running again.
Oct 10, 2019
Trying to get javaws to work without a glitch on one of the systems it was tested under, proved to be a chore.
The executable file was not being recognized in this case, which consequently led me to believe, that during the installation of the program, the path somehow had not been set by the libraries that’d normally take care of it.
All the libraries for which javaws depended upon and for which it was being tested even under a different system seemed to have been installed. This included, jdk8-openjdk.. and its counterparts.
Apparently, during the installation, the path that had been set for javaws had been incorrectly identified.
The error read as follows:
/usr/bin/javaws line 197: no such file or directory.
Upon further inspection of the line in question, is hard to pinpoint whether therein lied the problem or not…
Upon going ahead and after opening the javaws executable, I noticed that the path had been incorrectly set indeed by either some of the libraries during the initialization…. It was pointing out to a different location rather than where the files for the java environment were located instead.
Modifying the file in question and instructing it to open up without further ado, seemed to resolve the problem. Thus java=/location/of/java/default/ worked without a problem.
Sep 15, 2019
On a recent pacman upgrade, I encountered the error:
:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to synchronize all databases
the solution everytime is to remove the db.lck from the /var/lib/ directory and restart pacman.
rm /var/lib/db.lck
pacman -Syyu
Mar 14, 2019
Forwarding an email is a function usually bound to the f key, but if there are any Attachments that were included on the email, high chances are, that the attachments will not be selected.
One could go directly to the attachments in question and selectively open each one of them. This in turn, will select the attachments, save the body of the email that had been sent on the original email. To do this, one would have to further select the remainder from the list.
If various attachments are part of the email though, this otherwise seemingly
simple task, may be somewhat inconvenient.
One of the workarounds is to have Esc-e that uses the
current message as a template for a new one.
More information about this may be found at forwarding a
message with attachments in
Mutt
More information about this may be found at forwarding a
message with attachments in
Mutt
Mar 5, 2019
It seemed as if there’s some sort of conflict by bringing up the menu on the xterm terminal.
Ctrl+ 🖱 (rightmouse) is usually the way that one would bring the
menu, but every time this was done, xterm was crashing.
After going over some of the xorg-fonts-* packages, I noticed that some of
them were not installed for the X system.
Among them, xorg-fonts-misc was not installed. I
proceeded to install it and the menu was brought up
successfully again by the ctrl rightmouse
🖱combination.
A bug report was properly sent out to address this issue. I don’t recall from having this issue before, and/or when it even first appeared.
Feb 6, 2019
One of the features for which I personally would have a use for, would
be macros recording and playback.
To read about this on the doc page for kakoune, :doc keys macros
might give you an idea that by default Q starts or ends macro
recording, while q replays it.
the <esc> key also ends the macro recording.
See Kakoune
Macros
But further description for the macros recording and playback, is not
provided on the doc page for Kakoune.
The author advises to consult the :doc registers for further info.
As the doc states
Registers are named lists of text -instead of simply text- in order to
interact well with multiselection. They are used for various purposes,
like storing the last yanked text, or the captured groups associated
with the selections.
And about interacting with it:
<c-r><c> when in insert mode or in a prompt, insert the value stored
in the c register (single character)
"<c> in normal mode, select the register (single character)
But unlike vim in which a macro is replayed by preceding the
register with the macro @, on kakoune, the double quote along
with register <key> must precede the macro key, which in this case is
q that's bound to the default register @
Ignorant of this fact, mixed with the confusion that stemmed primarily
from the habit of using a workflow from vim, disallowed me to fully
comprehend that in order to replay the macro, the register (whatever
this one may be) must supersede the double quote ", followed in the
end by the default register q which in turn, fully replays the
specified macro.
After going over it, this may simply seem to have been just an oversight
on my part since such an obvious step to record and replay the macro, is
evident, but considering I've been used to vim, it was not at all
clear at first, what the steps may have been, mainly in order to replay
the macro on Normal mode. On Insert and Prompt mode, however,
the documentation provided all the details.
So to record the macro
" <key> Q <esc>
And to replay the macro
" <key> q
References
Kakoune
Macros
Kakoune
registers
Other useful links
A vim user's comparison between vim and
kakoune
:::
:::
:::
Feb 5, 2019
I seldom use the text editor kakoune. But many of the features that I have
found with vim or neovim for that matter in the past, have finally been
implemented on this editor.
It is, however, one of the best modal editors currently in development
and I encourage anyone who may be interested on the modality of these
sort of editors, to try it out.
I wanted to see how well this editor handled key mappings to invoke a
command from within the shell.
The map keys doc which can be found at
mapping.ascii
specifies that map [switches] <scope> <mode> <key> <keys> would be the
recomme nded way to map a key to the desired parameter.
Further googling about this issue, led me to a post at how to execute
shell commands with the current
filename
in which a user asked for a similar configuration on the kakrc
initialization file to invoke a command within the shell for the current
buffer.
But unfortunately the suggested recommendation for a latex file in this
case, would not work.
At the very least, the WinSetOption variable must have a normal mode to
which the key is mapped to.
So the correct way to map the key would be
map global normal <c-x> ':w<ret> $ latex $kak_buffile'
In that case, ctrl and x are bound to save the file and invoke
the shell command.
If other options are needed then specify it accordingly
References
kakoune
mapping
Kakoune normal mode
commands
:::
:::
:::
Feb 1, 2019
After looking at various ways to reply to an email address through mutt along with the terminal of choice, the xfce docs website did not provide me with all the needed details in this case.
I knew that by going to Preferred Applications one would have to further specify the corresponding commands under the Mail Reader application. But although it did pointed this out by running
$ exo-open --launch TerminalEmulator mutt
on the terminal, this, however, does not work. The terminal of choice will not open accordingly.
Further queries about this problem led me to a post from the Northern Virginia Linux Users Group.
On this post, one of the users pointed out that by launching, say, xterm with the -e option, this would be more than enough to open the file in question.
exo-open --launch 'xterm -e'
But this is wrong, since TerminalEmulator needs to be specified.
On another post closely related under the same thread, another user specified that the –launch option needed a “category.” It wouldn’t be difficult to find out what the category he was referring to, may be. In this case, even the already mentioned link from xfce docs had already pointed out.
The man page for xterm says about the -e option that it will
-e program [ arguments ... ]
This option specifies the program (and its command line arguments) to be run in the xterm window. It also sets the window title and icon name to be the basename of the program being executed if neither -T nor -n are given on the command line.
To wrap it all up, quotes ' are indeed needed to call out the preferred terminal - which in my case is xterm - and finally bring out the mail reader. The option -e is needed as well, along with the path to the mutt configuration file.
exo-open --launch TerminalEmulator 'xterm mutt -f /path/to/configuration/file "%s"'
or if one is using neomutt, change the -f option accordingly to -F.
exo-open --launch TerminalEmulator 'xterm neomutt -F /path/to/configuration/file "%s"'
Dec 17, 2018
I coudln’t help but noticing that the closetag plugin script for vim wasn’t working on any of the markdown files that had been previously edited.
The markdown files in question were of the abbreviated form md and not markdown.
It did work without a problem on any newly-created file and whether these files were of the form or had the extension md or markdown.
The README file of closetag specifies that in order for the plugin to work, it should be further specified as such on the initialization file with something such as:
let g:closetag_filenames = "*.html, *.xhtml, *.phtml"
etcetera. 1
At one given point I recall having *.md, which was more than enough for the closetag plugin to work without a problem, even with previously edited files.
This time around however, only having *.md did not remedy the problem.
Having *.markdown on the vim initialization file was necessary for the
closetag plugin to work with previously edited markdown files that held a
suffix .md extension
let g:closetag_filenames = "*.md, *.mardown"
References
README file for closetag↵