Today I was updating dom0 and came across that the tesseract-libs was installed in dom0, and along with the update, some more tesseract packages (tesseract-common, et al) were about to be installed.
I was wondering why an OCR library was in dom0. Instead of installing the updates, I opted for uninstalling it.
sudo rpm -e tesseract-libs libavfilter-free neatvnc weston-libs weston initial-setup-gui-wayland-generic initial-setup-gui
Now gone.
I have no idea why these packages exist in dom0.
I wonder this too.
You haven’t said which version of Qubes you are running.
Since these are not present in a standard dom0, have you installed (or
opted to install) any new packages in to dom0?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
It is a fresh install of r4.3, not an upgrade. I have installed some other packages, but not anything related to this library.
The tesseract-libs appears in the anaconda.log along with the other packages that were installed at the time I had installed r4.3, which means to me that it was installed by the original installer gui.
part of anaconda.log
Sep 10 20:14:19 localhost.localdomain org.fedoraproject.Anaconda.Modules.Payloads[2409]: INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed:
tesseract-libs-5.4.1-5.fc41.x86_64 1728227305 d5721c851387a60c01e468683e573aa47044b9bd46c11aeb76c3261f711e0899
Could this be the necessary built-in tooling for testing the ISO in the Qubes-os CI (continous integration) infrastructure?
Quick Edit: it’s for the OpenQA, not the CI, I think.
It seems reasonable that vnc and tesseract could be used for testing… which would be especially important for the first RC.
Now if only I could find the documentation about how the Qubes CI works… (pointers welcome!)
I don’t know. One typically expects that RC is something that turns into the release if everything is OK. The CI/test automation hypothesis does not make sense from that aspect.
Also, samba is a similar concern to me. For some reason, it got installed in dom0 by the installer (a dependency of Qube Manager). Perhaps a package cleanup with a hardening perspective might be useful. Or an optional path to remove such packages.
tesseract is installed in all qubes update dom0 and domU, it’s forced update with no user installed app
PS: QubesOS 4.2.4
PS2: clean pristine fedora template
$ sudo dnf list installed tesseract
Updating and loading repositories:
Repositories loaded.
Available packages
tesseract.x86_64 5.5.0-5.fc42 updates
$ sudo dnf history info 12 |grep tesseract
Install tesseract-common-0:5.5.0-5.fc42.noarch Dependency updates
Install tesseract-langpack-eng-0:4.1.0-10.fc42.noarch Dependency updates
Install tesseract-tessdata-doc-0:4.1.0-10.fc42.noarch Dependency updates
Upgrade tesseract-libs-0:5.5.0-5.fc42.x86_64 Dependency updates
Replaced tesseract-libs-0:5.5.0-4.fc42.x86_64 Dependency @System
PS3: sorry, was updating after month of away, there is no tesseract in dom0 in 4.2.4
Not in mine.
What templates are you talking about?
Well, it seems to me that this is exactly how things are supposed to
be.
The rc is out out there for testing. Users find errors and they are
fixed in the next rc.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Every fedora 42 templates. I wouldn’t be surprised if it would be in my multimedia or cups templates but it was installed in pristine fedora-xfce-42 template
Fedora builds FFmpeg (libavfilter-free) with OCR support, which is where the dependency on Tesseract comes from.
Seems fine to me that a non-minimal template includes FFmpeg.
Now for R4.3 dom0 though, the dependency on some Wayland stuff and hence FFmpeg and Tesseract looks like an artifact of this commit:
Edit: Actually I’m not sure anymore. Maybe an R4.3 user can post the output of dnf remove tesseract-libs and dnf remove initial-setup-gui-wayland-generic (without confirming either one!)
Initial-setup on R4.3 does run on Wayland, and it does use Weston. The specific dependency chain is:
initial-setup-gui-wayland-generic → weston → neatvnc → libavfilter-free → tesseract-libs
It might be possible to fork and rebuild weston package with limited features, but I’d rather avoid it…
QubesOS 4.2.4 fedora clean template
$ sudo dnf remove tesseract-common
package dependent is ffmpeg-free
There is no tesseract package
multimedia template - tesseract package is no dependencies for anything, maybe I’ve installed it to OCR documents but didn’t used it once
$ sudo dnf remove tesseract-common
Package Arch Version Repository Size
Removing:
tesseract-common noarch 5.5.0-5.fc42 updates 14.7 KiB
Removing dependent packages:
ffmpeg x86_64 7.1.1-6.fc42 rpmfusion-free-updates 2.5 MiB
flowblade noarch 2.22.1.1-1.fc42 updates 45.4 MiB
gstreamer1-plugin-libav x86_64 1.26.6-1.fc42 updates 437.4 KiB
haruna x86_64 1.3.3-2.fc42 updates 3.0 MiB
kf6-ktextwidgets x86_64 6.17.0-1.fc42 updates 1.4 MiB
libheif-freeworld x86_64 1.19.8-1.fc42 rpmfusion-free-updates 143.9 KiB
localsearch x86_64 3.9.0-1.fc42 fedora 3.8 MiB
mlt x86_64 7.32.0-1.fc42 updates 3.0 MiB
mpv x86_64 0.40.0-1.fc42 fedora 4.4 MiB
opencv-videoio x86_64 4.11.0-3.fc42 fedora 849.4 KiB
tesseract x86_64 5.5.0-5.fc42 updates 97.4 KiB
ungoogled-chromium x86_64 140.0.7339.185-1.fc42 copr:copr.fedorainfracloud.org:wojnilowic 431.7 MiB
vlc-plugin-ffmpeg x86_64 1:3.0.21-24.fc42 updates 289.7 KiB
After discovering that dependency chain, I thought that the initial-setup package was an artifact from the setup and was no longer needed, hence could have been safely deleted.
I understand that a vendor is necessary for dom0, but perhaps a minimal dom0 could be provided as an option, for obvious reasons. There were some threads where dom0 debian and nixos was discussed. I am fine with LFS or any kind of stripped-down arch-like solution from today, in order to stay on the safe side even if Fedora decides to change manners one day. 