When installing this, I ran into dependencies issue. The following are missing in my case [root@galileo Software]# rpm -Uhv djview4-4.12-3.fc35.x86_64.rpm
error: Failed dependencies:
glibc >= 2.33.9000-43.fc35 is needed by djview4-4.12-3.fc35.x86_64
libQt5Core.so.5(Qt_5.15)(64bit) is needed by djview4-4.12-3.fc35.x86_64
libc.so.6(GLIBC_2.34)(64bit) is needed by djview4-4.12-3.fc35.x86_64
libdjvulibre.so.21()(64bit) is needed by djview4-4.12-3.fc35.x86_64
libm.so.6(GLIBC_2.29)(64bit) is needed by djview4-4.12-3.fc35.x86_64
I have checked my glibc version [root@galileo Software]# rpm -q glibc
glibc-2.28-151.el8.x86_64
My question is: Can I update glibc and install above dependencies and continue to run Rocky without any clashes in dependencies etc.? I have seen some webpages indicating updating glibc should be OK since versions are supposed to be backward compatible, but I thought I will ask here anyway.
No. Practically everything in the distro depends on the glibc (and some other components). One does not simply replace the base components, ever.
Get the source RPM of that “djview” and build the binary packages for Rocky.
(mock is commonly used for (re)building packages.)
PS. Do not use rpm for installing any packages. The dnf install djview4-4.12-3.fc35.x86_64.rpm works as well (or better – it can pull dependencies and it records the transaction to dnf history).
If package has been built for the platform (here Rocky), then that (dnf install) should be the first option.
If package is from unknown source and would replace/remove already installed system packages, then be sceptic.
If a package can be built for the platform, then that is an option, because you can dnf install/upgrade/remove.
Build as regular user, never as root.
If the only option is “build from sources”, then don’t put files among system files (no default make install). Put the result in distinct directory (for example, under your homedir).
Do note that Rocky is based on RHEL and RHEL contains backported features. That is, at some point Red Hat creates a branch of some application for RHEL. The formal version string does not change, but after a while the branch in RHEL differs from its origin. For example, in around 2013 Red Hat took Linux kernel 3.10 and based kernel it RHEL 7 on that. It is still in use, still called “3.10”, but different from what upstream 3.10 was. Yes, it isn’t like upstream 5.15, but it for sure has a feature that upstream introduced in 3.13.
Hello again, @jlehtone …
Merry Christmas!
I am sorry I keep bothering you…
I tried the command you suggested - namely installing using dnf install …
this is the result
[root@galileo sources]# dnf install djview4-4.12-3.fc35.x86_64.rpm
Display all 16732 possibilities? (y or n)
I gave no (n) as the response here, the system immediately came out waiting for me to enter at the prompt
I gave same command again… and this followed. [root@galileo sources]# dnf install djview4-4.12-3.fc35.x86_64.rpm
Last metadata expiration check: 12:08:12 ago on Friday 24 December 2021 01:31:57 AM IST.
Error:
Problem: conflicting requests
nothing provides glibc >= 2.33.9000-43.fc35 needed by djview4-4.12-3.fc35.x86_64
nothing provides libc.so.6(GLIBC_2.34)(64bit) needed by djview4-4.12-3.fc35.x86_64
nothing provides libdjvulibre.so.21()(64bit) needed by djview4-4.12-3.fc35.x86_64
nothing provides libm.so.6(GLIBC_2.29)(64bit) needed by djview4-4.12-3.fc35.x86_64
(try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)
Can you explain what is happening? At this point, I skipped djview4-4 and looked online again for a djvu reader
I found Okular. https://okular.kde.org/
Says out there loud and clear… it supports djvu format… so I went ahead and installed using [root@galileo sources]# dnf install okular-21.08.3-1.el8.x86_64
Last metadata expiration check: 12:22:53 ago on Friday 24 December 2021 01:31:57 AM IST.
Dependencies resolved.
It installed Okular, and I tried opening a djvu file, only to get a message -
“Could not open file:///home/user01/Documents/ERT.djvu.
Can not find a plugin which is able to handle the document being passed.”
I don’t understand, if the website shows the djvu logo, why does it now need plugins?
I am at my wits’ end. Can you please point me to a solution to help me read my djvu files?
“Plugin” hints of optional feature. Those could be in separate packages. Alas, EPEL 8 does not have “okular-djvu” or similar. (Neither does RHEL 7.) For some reason that plugin has not been built on these platforms.
I did look with:
dnf list \*okular\*
dnf list \*djvu\*
dnf provides \*djvu\*
dnf provides */\*djvu\*
and while some packages in ‘epel’ have filenames containing “djvu”, there is no executable/plugin/library in that set that handles djvu.
I think your path of least resistance would be to install the okular or evince flatpak. It looks like it will read djvu files, plus it will be isolated from your main system so you won’t have to worry about library incompatibilities or building from source.
@tkuraku
thanks for dropping by and offering to help.
I do recall installing either this or snap in the last iteration of my computer and it had been probably too heavy - i.e. too much disk space. I am sorry, my memory fails me.
What I do recall is that uninstalling it was not possible for me, at least with the limited understanding I have of Linux.
How much space do I need on my /home or /usr wherever this flatpak is installed.
Happily, I note that the how2shout.com link above says I can uninstall flatpak- Can I do the following:
[A]. install Okular/Evince via flatpak and then uninstall flatpak,
[B] After uninstalling flatpak continue to run evince?
Thanks @tkuraku
I will try flatpak method of evince
@jlehtone, I am unaware how to rebuild the binary package for rocky, but I still appreciate your guidance all along.
For my own and others benefit, I request you to please show/share this method of build/rebuild the binary package for Rocky. I have checked on this forum, but could not locate a discussion on this (basic?) step.
Considering I have build from sources for R-Studio, I will appreciate (as always) your guidance on how to do this for Rocky
@tkuraku@jlehtone
I am seeing that evince is available in centos packages, indeed when I type dnf install evince, I get the option of evince-devel-3.28.4-14.el8.x86_64
Do you suggest I use this? I suppose this is from centos EL8 repository.
there is also
evince-nautilus-3.28.4-14.el8.x86_64
and
evince-libs-3.28.4-14.el8.x86_64
Regards,
The evince package available from the EL8 repositories doesn’t have the djvu libraries, as those aren’t shipped with EL8 as you have found. It won’t open the djvu files. The flatpak will include those libraries and can open and view the djvu files. Evince is installed by default with the server with GUI install, so you likely already have it installed and if you install the flatpak there will be two version of evince installed.
@tkuraku
Thank you for clarification. I tried, and installed flatpak and evince via flatpak. My djvu file can now be accessed via the flatpak evince.
Apparently, there was some other evince also - which did not run the djvu file - as you have pointed out from your last message.
As per the howtoshout link above, I was to update dnf first using the below command…
sudo dnf update
##########################################################
I did so, and followed the rest.
It did update my Linux to Rocky 8.5
This was not my intention - although I am not sure what to make of the updated Rocky 8.5. Typically, I stay one version behind the latest stable, just to keep away from anything that may hold up my work/usage.
##########################################################
For anyone who tries using evince via flatpak,
You will probably install flatpak - using root.
You will also search and install evince on flatpak - using root.
you will fire up evince via flatpak using (in my case) flatpak run org.gnome.Evince (again in root)
You will find that evince opens up and allows you to open a valid djvu file.
When you exit root and come to a regular user mode, and type flatpak run org.gnome.Evince, you will get an error: Unable to allocate instance id
Do not worry, you only have to reboot your machine and you can then run flatpak run org.gnome.Evince as a regular user.
You should perform an sudo dnf update regularly or you will not get necessary security updates and your system will have security vulnerabilities. Staying a point release behind is not a good idea.
I’m not an expert on the topic either. I’ve seen references to ‘mock’. It it possible to install ‘mock’ from EPEL.
Then, one does run mock as regular user. Mock creates chroot/container environment into which it installs packages required for a build and then builds. However, running:
Rebuilding djvulibre-devel from source (from fc35 and even from fc32) fails, because the build uses feature of inkscape that is not yet in Rocky’s version. The version of djvulibre in fc31 builds on Rocky.
I did not dig into documentation of mock enough to figure out how to inject the custom-built djvulibre-{libs,devel} into the chroot, where mock would build djview4.