Nov 26, 2018
I still don’t know whether there was an old installation of Libreoffice sitting somewhere on the system. But a new fresh installation not only failed to start up but it also returned the message error Error while reinstalling all previously deployed packages of context user.
Looking up Google didn’t help in finding some sort of recent info about this issue.
I also had a warning: failed to load path from javadlx which was obviously only a warning but nonetheless troublesome and problematic considering that this was just a fresh installation of Libreoffice.
Further looking up this issue through Google led me to the forum of Arch in which a user mentioned the possibility of permission problems with the installation. The user also queried Google to find more about this issue:
Googling about the error showed some chances of being a permission problem with ~/.openoffice.org2. But I don’t have that directory in my system, but ~/.config/.libreoffice. I would suggest you check the permissions on this directory. Mine are 766. 1
but there was nothing out of the norm with the permissions set on the directory. But from his post it reminded me that usually the path that is set by xdg is under the xdg directory. Then again, the environment variable for it had been set correctly.
I decided to go ahead and back up the .config/libreoffice/4 directory where some of the other files for libreoffice laid at.
Then I moved that directory with all the files to another location, following by calling out libreoffice which seemed to resolve the issue.
One of the first hits provided by Google after my first inquiry, were from the forums at the libreoffice website itself, in which one of the threads that also dealt with this issue had mentioned the same workaround that I had just used. See more at LO5.0 Fatal Error cannot be started.2
Further queries that would shed more light about this problem, took me to a previous probable bug that was reported to the documentfoundation.org website. This report was opened on 2013 and closed right after around 2014. 3
Why that bug report at the documentfoundation.org website was marked as closed shortly after it was reported, is simply beyond me.
The report occurred under version 5 whereas in my case, it was under version 6. And the problem is still there.
References
1- Permission problem with Libreoffice - Arch linux forums↵
2- LO5.0 Fatal error cannot be started ↵
3- bug filed with documentfoundation.org↵
Nov 2, 2018
A slowdown on my hardware had recently made me to reconsider another display manager that would presumably improve the boot time of my system. But even after installing it, I could not see any discernible difference between these display greeters. Perhaps I had noticed it before a year or so ago when I tried it out and went ahead and enabled it on an older system. This time around though, my expectations fell short.
After installing SDDM, I called out systemd to disable LightDM with
sytemctl disable lightdm.service
followed by the enabling of the newly installed display manager with
systemctl enable sddm.service
But it wasn’t clear at first, but just after rebooting the system - although at this point my faulty memory is not helping me remember whether it was a reboot or by logging out of the system, that I noticed that the timezone differed from that of the desktop environment.
Perhaps it was SDDM Wayland that got it right this time around and not the DE XFCE according to the locale currently in use. The timezone that SDDM picked up and hence the entry that was returned after calling out ’timedatectl’ were the same. The reasoning behind this assumption is that by calling out the timedatectl status as the Arch Wiki suggested, returned indeed what was expected, albeit wrongly set at one point by me, but nonetheless correct.
datetimectl status
matched SDDM clock settings. The timezone had been incorrectly set at one point.
Modifying the timezone accordingly seemed to have resolved the issue with:
timedatectl set-timezone Zone/SubZone
All in all, some of the posts from Arch Forums that were queried via Google, were slightly off topic. Some of these posts for example dealt primarily with clock twelve and twenty four hour clock settings, whereas in my case it the underlying cause was primarily due with the timezone set incorrectly.
Further posts that came up for XFCE were also from the long-standing threads at linuxquestions.org, a site that has been around perhaps longer than any other out there related to GNU/Linux in general. This time around the user was running AntiX and not systemd. The timedatectl is part of the latter in this case, so the suggestions aimed at hwclock or setting it also through date instead.
I’ve found that is relatively easy to mess up the time settings on the system as this question from stackexchange pointed out. See for example I messed up my system clock in Arch Linux.
Other questions that dealt with XFCE and not necessarily with SDDM, pretty much coincided with the timedatectl command. Like for example the following question that was also on stackexchange How can I easily change my time-zone in Arch/Xfce that I came across only later and after resolving it first in my end.
And still, the best way and proven methodology I know of, and one which deals with the time/date issue on an Arch Linux system is by the aforementioned method outlined above. Credit where the credit is due, because all the credit goes to the Arch Wiki for making it accessible without having to read through an entire manual to resolve an outstanding problem as simple as a timezone. Although I have to acknowledge that reading man pages is the optimal and thorough alternative to get a deep understanding of an entire system. Nothing comes close as the latter!
References
System Time Arch Wiki
Aug 28, 2018
as the ClamAV arch linux wiki states, ClamAV is:
Clam AntiVirus is an open source (GPL) anti-virus toolkit for UNIX. It provides a number of utilities including a flexible and scalable multi-threaded daemon, a command line scanner and advanced tool for automatic database updates. Because ClamAV’s main use is on file/mail servers for Windows desktops, it primarily detects Windows viruses and malware with its built-in signatures.
In order to update the definitions correctly is important to run first
freshclam
which should then start the update
ClamAV update process started at Tue Aug 28 01:16:43 2018
Downloading main.cvd [100%]
main.cvd updated (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr)
Downloading daily.cvd [100%]
daily.cvd updated (version: 24880, sigs: 2066436, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 327, sigs: 91, f-level: 63, builder: neo)
Database updated (6632776 signatures) from database.clamav.net (IP: )
But then an error came up saying that:
WARNING: Clamd was NOT notified: Can't connect to clamd through /run/clamav/clamd.ctl: No such file or directory
which left me unsure what could have been the issue.
Googling about it returned among many of the results, some as in Can’t connect to Unix socket /var/run//clamav/clamd.ctl, which dealt with the issue.
The error here in which it dealt with clamd.ctl and not with clamd.sock connect () as it was posted on the entry entitled Error Clamd was not notified.
But after running
freshclam
I had already forgotten to start/enable clamav-freshclam.service as outlined on the Wiki ClamAV updating database
so
systemctl start clamav-freshclam.service
systemctl enable clamav-freshclam.service
Which returned:
Created symlink /etc/systemd/system/multi-user.target.wants/clamav-freshclam.service → /usr/lib/systemd/system/clamav-freshclam.service.
Later on by calling the status of that service with
systemctl status clamav-freshclam.service
returned
Aug 28 01:23:43 systemd[1]: Started ClamAV virus database upda>
Aug 28 01:23:43 freshclam[]: ClamAV update process started>
Aug 28 01:23:43 freshclam[]: main.cvd is up to date (versi>
Aug 28 01:23:43 freshclam[]: daily.cvd is up to date (vers>
Aug 28 01:23:43 freshclam[]: bytecode.cvd is up to date
But whether it would be necessary to enable it every time it restarts, it’s something that I will deal with later on. I only needed it this time around to check some files, and that was the purpose of running it in the first place.
Aug 16, 2018
On a different machine running the latest updates from Arch, pacman would give the error (and rightly so) that hunspell-en and hunspell-en_US are in conflict and could not satisfy dependencies followed by removing hunspell-en breaks dependency hunspell-en required by **antergos-common-meta**.
This was of course never a problem on the other machine in which antergos-common-meta was removed a while back. For the simple reason that the update related to anything hunspell was in this particular case only for hunspell-en_US as well as hunspell-es_any but not for, and this is important to note: hunspell-en. The latter includes all English dictionaries for US, UK, etc.
So the question is how to resolve this impeding conflict during the updates? Simply by skipping the package on pacman during the updates, or simply by deselecting the packages that belong to hunspell-en on pamac (the gui version for pacman) for which the conflict exists in the first place.
pacman -Su IgnorePkg=hunspell-en_US
See Skip package from being upgraded on the Arch Wiki.
By removing antergos-common-meta the first time around on this particular
as I had done a few weeks ago on the other machine, made no difference. And
that’s the reason as to why the above is recommended. That is, by skipping the
packages in question that belong to hunspell-en_US for example first, and
then by proceeding with the updates normally seems to be the most reasonable
method.
Once this is done, the next step would be to remove hunspell-en which would also remove antergos-common-meta by which the latter package relies on.
Finally, the next step would be in installing the libraries for hunspell-en_US, or hunspell-en_GB, or hunspell-en_AU or hunspell-en_CA.
Apparently, in the latest installation ISO image, this issue with hunspell and its dependencies has not been removed from the repositories that the installation media uses for the initial process. Which better explains as to why on the other machine which had the most recent Antergos installation, this problem was still present, whereas with the other machine in which I had removed antergos-common-meta which removed hunspell-en - the one that bundles all dictionaries for the English language - was never experienced.
Aug 10, 2018
Setting up a network printer seems not only problematic on Arch based systems, but also on Windows.
The latter also gave me the proverbial run for the money.
Even after I thought that the network printer had be configured correctly, errors such as there was a problem processing document after printing a test page, or simply the error stating that the printer may not be connected assured me that the network printer was not being correctly identified.
Common Unix Printing Services or as its acronym that is better known for: CUPS, is without a doubt, the most reliable method to set up any printer, and especially those that depend upon a network to operate accordingly.
It was not the first time setting up a network printer through CUPS, but
contrary to the first time around when the printer was successfully configured
on the system, in which the ip address had to be specified, and the connection
port number of the socket was automatically picked up by CUPS, this time around
however, specifying the ip address by itself made no difference with further
configuration.
The printer was still not recognized.
I scoured Google for any relevant results that would help me troubleshoot the problem, but none of the results seemed to provide a definitive answer.
The Arch Linux Forums was one of the first indicators that this issue was beyond a driver problem and rather a misconfiguration with the network printer.
On the thread entitled Printer setting cant find wireless printer, a reply provided gave a couple of hints as to where to begin to troubleshot the problem.
Your post is much too vague. What does your wireless printer advertise? You should be able to add it using its IP address in the CUPS interface like this: http://192.168.1.3. You need to replace 192.168.1.3 by the IP of your printer and http:// could be socket:// lpd:// or something else… Maybe you also have to specify a port number like this: http://192.168.1.3:9100. If you can setup the printer in another OS (for example Windows); you might be able to find these by examining the properties of the printer.
The problem with Windows however, is that Windows itself does not provide a simple port configuration method that would have allowed me to see the ip address and the port that was currently in use.
This time around CUPS had already specified the ip address and the connection for the socket. But everything else for even the location had already been noted. Furthermore, I double checked it against the settings for the wireless configuration of the printer. Not solely relying on whatever configuration the display showed but also by printing out right from the printer the specifics of the configuration.
When I ventured out to get a glimpse through a Windows system that would allow me to double check the settings, I encountered though, an unforeseen An error occurred during port configuration. This operation is not supported which prevented me any further from finding out about the ip address and port number configuration.
This however, was not expected.
On this question that was brought up on the stackexchange network, the user asked to list all network printers (including ones not installed) and although it hinted that the program lpstat with the flag -a was one that would undertake the task, as the user pointed out, this would not apply to those printers that have not been installed.
Another command that would certainly come handy is lpinfo -v but more than what it provided was therefore needed.
On another thread entitled linux - how do you get the name of a network printer one of the comments said that:
When I run the nmap command it never seems to complete.
https://superuser.com/questions/662418/how-do-i-get-the-name-of-a-network-printer#comment836711_662485
which pretty much matches many of the issues that I have encountered with the program.
The only workaround with this pervasive problem of a printer that depends solely on the network, is through some sort of initial setup performed namely through a Windows system that would point it out. Unlike Linux with its Common Unix Printing Services in which by just confirming the correct ip address and port numbers of the printer are under , is more than enough to identify it accordingly. Until then, and just like a user on the Arch Forums said:
The problem here is that the criteria (“Network Printer”) is something that only makes sense to humans. Computer programs aren’t going to have a clear sense of that idea. You might try doing a network sweep for IP addresses that successfully connect on the JetDirect port (tcp/9100). The list is still likely to be incomplete in the case of non-JetDirect printers such as desktop printers shared over SMB. – Bratchley Jun 30 ‘14 at 18:16
References
unix.stackexchange.com/questions/140009/list-all-network-printers-including-ones-not-installed#comment226003_140009
2 Configuring your printer for a networt
Aug 6, 2018
During the last updates through pacman the following message came up:
warning: directory permissions differ on /var/cache/pkgfile/
filesystem: 775 package: 755
But to first understand why this came up in the first place is good to know that pkgfile is a tool for searching files in the official repos. pkgfile - ArchLinux wiki
It should be noted that the question as to why the pkgfile differs for the file system hierarchy and the package itself has come up before.
This issue on Github dealt with it.
In the thread, one of the users reported whether it was necessary for pkgfile to create the directory if it doesn’t exist.
Of course this is not the case here, but upon closer look on the pacman log it could be seen that pkgconf had just been upgraded
upgraded pkgconf (1.5.2-1 -> 1.5.3-1)
warning: directory permissions differ on /var/cache/pkgfile/
filesystem: 775 package: 755
Which suggests that right after the updates it didn’t recreate it.
On the other hand pkgconf is according to the manual pages:
pkgconf is a program which helps to configure compiler and
linker flags for development libraries. This allows build
systems to detect other dependencies and use them with the
system toolchain.
see for example what the aforementioned issue on Github said about it.
And a quick Google search would return among many of the results, the following:
https://bbs.archlinux.org/viewtopic.php?pid=317732#p317732
As well as
this one which in turn redirected to this one
With due credit to where credit is due, the following post from the Manjaro community explicitly said that it was a warning and not an error itself.
xabbu 2018-06-10 21:39:39 UTC #4
directory permissions differ on …
This message is a warning and not an error. This is normally not a problem. It just says that the permissions of a folder in a package differ form the permissions of that folder on your system.
Normally this will not result in a problem, however you should change the permissions to the package defaults to avoid future problems. This message is shown every time you update this package if the permissions don’t match.
In your specific case, at the moment only root and members of the group locate have access to the mlocate folder. With the change to 755 everybody can access and read the content of that folder. This don’t necessary mean everybody has also read access to the files in that folder.
Why the package folder contains different permissions than your system folder can have several reasons. Often it is because the upstream source have changed permissions. Sometimes a developer does this on purpose. But sometimes this happens by mistake and is changed back with the next release. Also the Maintainer can change the permissions of files and folder in the build process.
And of course the user sometimes changes the permissions of a file or folder and forget about or does it to fix a problem.
Also please note (@jochen82 @farverio ), if you have a problem with something else start a new thread with your problem to get help with that.
On another thread on the same Manjaro forums this came up:
fhdk 2018-05-07 10:34:00 UTC #4
rrrsssttt:
directory permissions differ on /var/lib/samba/private/
filesystem: 755 package: 700
bill_t:
It means that the permissions of this directory must be set to 755 (or drwxr-xr-x).
Actually it means the opposite.
The filesystem is 755 when the package expects it to be 700.
So the right thing to do is to set permissions as the package expects it to be.
sudo chmod 700 /var/lib/samba/private/
rrrsssttt:
I want to clarify that I don’t believe I have ever touched that folder (I may have installed apps that have touched it, but I consciously never have)
You don’t need to. It is probably a fix since the folder mentioned is named private and as such is a folder that samba uses for stuff like certificates, keys, private keys, and so on.
Such folder is only accessible for the system service running samba and the service will presumably refuse to run if permissions is wrong.
Try that with your .gnupg folder or the .ssh folder. If permissions is world readable you will get complaints from application and some even refuses to run unless only accessible by owner aka chmod 700 ~/.ssh -R as an example.
see I get a warning after running the latest round of updates
As the user on the Manjaro Forum pointed out when he/she said:
Actually it means the opposite
Changing the directory permissions of the package in question in the file system with a chmod 755 would be the best course of action for this package permission issue.
I think that the reason why it occurs in the first place, is due to the fact that the tool pkgfile must have administrative privileges during installation/upgrade in order to continue. That is, writing, reading and executing. But once the update has finished it no longer is necessary to keep the same permissions than before. The package no longer needs to have access to the home of the user in question.
Jul 30, 2018
A while ago someone whom I came across on a technical forum
was vouching so much for one of the most used/popular Linux
Distributions that he/she almost gave the impression of
fully endorsing the distro in question, without further
proof.
I said that he/she stated it without further proof because
all distributions consist of several software which make up
the whole system. So it would be gullible to think that one
particular distro employs Free Software while clearly
stating that the rest of the license by which the distro
developers go aheaad and implement it, is - as a result - within the
framework of say for example, what the Free Software
Foundation accepts.
This is not the case. Most Linux distros, and even more
those that are amongst the most popular, are not very clear
in their terms with the programs that the distro’ s
developers include and consequently employ within it, for further mass
use. No distribution out there but only a handful of them do
this.
The problem that the above presents to the adoption of the Free
Software license is that many of these distributions do not uphold
licenses as they should or simply because its developers have included
other elements such as firmware nonfree blobs, or have provided
ambiguously writing in the documentation, and have offered other
methods that have provided download venues which in turn officially
endorse nonfree programs. More information about this can be seen on
the article entitled Explaining Why We Don’t Endorse Other Systems
1 posted on the Free
Software Foundation website.
So the poor statements that this user was trying to make about one of
the most popular Linux distributions at the time, could no longer hold
valid together under the license for which the Free Software
Foundation stands upon.
For further info about this, one could visit the Free
Software Foundation to get a glimpse at what this is about.
But to make matters even worse, the user who was trying to
make his silly point, brought up one if not the most
inaccurate and misleading source of Linux Market Share
measure rankings’ markers out there, a website named
Distrowatch that lists the most popular GNU/Linux
distributions.
Which takes me to the second rant about why the above cannot be taken as an
statistical absolute. For Distrowatch is just a community driven, heavily
edited, bureaucratically biased reviewed epicenter which sits on the web with
layers of html markup with a domain registration. Let me emphasize once again
about its biased one sided view about the certain distros’ Linux Market Share.
It is important to do so because it is almost and will always be imprecise to
measure the use of GNU/Linux distributions across the spectrum and compare
these - whether community or commercially based
- with many of the most heard- Operating systems without reliable methods
and just by a simple likes/preferences which in the end, is nothing more than
a preconceived notion of what distro should and should not be on the top.
Because of this, Distrowatch statement is vague to say the least.
According to Stack Frames: A Look From Inside, its author
said that:
Each website has its own list of the most popular
distributions, updated on the basis of different criteria,
hence with different results. To give one example,
Linux Mint was the most popular distribution in
2013 and in the first half of 2014 according to
Distrowatch, but is ranked twelfth on the
LinuxCounter and LWN. 2
And this is important because the disparity on numbers when
all the distributions are compared across LinuxCounter
3
and LWN, 4
greatly differ from the ranking on Distrowatch. The differences would
be much more profound if other websites would try to gather
these numbers as long as the list is not heavily edited or
maintained by users who manipulate this data like in the case of
Distrowatch.
In the case of the LWN site, the author of Stack Frames: A
Look From Inside, was also on the err side and may have
made some subtle mistakes with the rankings of the distros.
This may be noted with some of the inconsistencies with the
top market share of the distros in use. That is, the
chronologically order of the distributions as it was
reflected on the book and as the author pointed out, is
certainly troublesome. The list on LWN is enumerated
alphabetically and it does not necessarily offers numbers
that could be used as a better counter/measurement
tool/indicator/predictor in this case. It does show,
however, the mainstream distributions or the ones that have
been around the longest
- commercial and community based - in the computing world.
Reading about this pervasive problem with the market share
of GNU/Linux programs, and the distributions that include
these programs in addition to the share of these
distributions along with the biases that are taking place in
community sites such as Distrowatch, the author of a blog on
the Medium blogging service platform said that:
I notice when they have an axe to grind against a
particular distribution bad reviews are allowed to flourish
but if I or others submit positive reviews they tend to get
ignored and there are more than a handful of distributions
where I have noticed that trend
But what it’s unfortunate is that such misleading bits of information occur
nowadays, especially within the culture of the GNU/Linux Operating system which
even includes its kernel without which the vast GNU software which is comprised
of, accomplishes nothing. But most importantly, listing it as so called ‘popular’
when most of the ‘popular’ distributions do not even adhere to the Free
Software Foundation standards guidelines of Free Software.
The author in that blog stated that Distrowatch is biased towards
free-as-in-beer distributions, but I would disagree because I do think
the bias is there regardless whether is more commercially oriented by
which the distribution in question implements free software or not. It
is the case that community driven distros do not necessarily implement the
licenses any better than commercially based distros. But it makes no
difference in the case of this website. The users responsible to
update the counter list for the distros or in this case the distro
that should appear on the top are undoubtedly misinforming real/accurate market
share data without further repercussions. And by the looks of it, what
matters is the ad-driven commercially source of income that derives
from this data manipulation to the owner of Distrowatch.
I have no idea whether this GNU/Linux user that commented about how
that Linux distro fared in comparison with the rest, was aware of
these facts, but Distrowatch in general has been around for a while
and I wonder whether they have affected the objective and the goal
overall of the Free Software Foundation Guidelines.
No doubt that the reviews need further revision but they’re
doing so while promoting their own, without regard for the
particular distro and whether this is community-driven or not.
The Linux Distribution Timeline offers in turn the progress
of the Linux Distributions and although is a great project
on its own right, it does not undertake where all the sites
have fallen short to accomplish this difficult task of having a
better Market Share Model that tackles the Linux world.
The website for this project is located at futurist.se
Sources
1- Explaining Why We Don’t Endorse Other Systems↵
2-Stack Frames: A Look From Inside↵
3-www.linuxcounter.net/statistics/distributions↵
4-lwn.net/Distributions↵
Jul 24, 2018
Antergos wins here. Manjaro could have done better but it
didn’t.
Anyone who would want to avoid having to go through the
hassle of reinstalling and testing sane drivers under Arch
Linux should look no further. The comparison wasn’t done
between all the Arch Linux based distributions, but Antergos
is the clear winner here.
No Desktop Environment under Manjaro worked to have this
driver functioning as it should have been functioning. And
this is after trying Manjaro KDE, Manjaro XFCE, the most
popular of the bunch. Didn’t try it with GNOME and I wasn’t
going to waste my time with it.
Perhaps later versions would fare better, but this time
around it didn’t deliver what it was expected from this
distribution. The main issue had to do with the invalid argument error message from programs such as gscan2pdf
and also from xsane and in identifying and picking up
the right device other than the infamous Noname integrated camera that it would only identify from the list.
After reinstalling both Manjaro KDE and the XFCE version the
problem continued in identifying the correct device.
With Antergos it worked without a major issue and for that
reason alone I recommend this distribution over Manjaro.
Jul 18, 2018
The GUI version of pacman which runs under Antergos
installed the scheduled updates as expected.
But as soon as new updates were found it just failed to
install them.
In this case, after running the post installation hooks, it
found a new update for one of the programs. But this time
however, it failed to even initialized the transaction.
Although it could have been relatively simple to circumvent
the problem by seeing through pacman itself what the error
was, but just closing the pamac application, seemed all
that was needed to have the problem fixed.
Soon after, the GUI version pamac had no further issues
to install the updates accordingly.
Perhaps this is is just a reminder not to fully rely on
pamac and used the main package manager for any Arch
based distribution.
Jul 18, 2018
It seems as if antergos-common-meta has been removed
from some of the repositories.
In the latest updates by using pamac or even pacman returned
the could not satisfy dependency error that was required
in this case for the hunspell Spanish dictionary hunspell-es.
Thus by removing antergos-common-meta or whatever was left
of it, resolved the problem, it seems that the Antergos
community haven’t been able to resolve some of these issues
that keep coming up every now and then with the
distribution.
A Google search about this problem returned, among the
results some posts like can’t solve dependencies hunspell which
summarised the same error message.
Unlike other occasions, I didn’t read about this particular issue this time, The reason for not following up on it is due to the fact that a few days ago a dependency problem had appeared about a ..libso.2 (I can’t remember the name of the file, this time around), but it was a file that needed to be removed before successfully continuing with the updates.
Hopefully the Antergos developers will be able to correct some
of these inconsistencies in an otherwise great distribution
that is based on Arch, before a greater share of users who are
fond of Arch, not only migrate to it, but fully adopt it as
the main OS in their systems.
Until then some of these errors and dependency satisfaction
from the packages would have to be resolved manually by the
end-users on their own.