Solved Krita and Qt version mismatch - where to report these issues?

Hi All,

I've just installed some new binary package (irrelevant to this thread), and pkg during the process suddenly wished to remove Krita, without giving any options. Agreed to remove Krita. Installed Krita back. Now I got this:
Code:
% krita
/usr/local/lib/qt5/libQt5Core.so.5: version Qt_5.11 required by /usr/local/bin/krita not found
I guess I'll need to manually reinstall Qt packages. I wonder to whom such repository breakages are better to be reported? Krita package maintainers?

EDIT: solved (worked around) by doing pkg upgrade of everything.
 
Did you by any chance build ports manually and now installed a binary package? Because that would explain a few things and it's the most likely cause for your problems.

(edit): I doubt that this is a problem with the repository, it's more likely that you mixed ports and binary packages which led to a dependency mismatch, resulting in this mess.
 
Upgraded qt5 and qt5-core to 5.11.2. Now I get this:
Code:
% krita
/usr/local/lib/libkritaui.so.17: Undefined symbol "_ZN17QAbstractItemView11eventFilterEP7QObjectP6QEvent@Qt_5"
 
One small port can have a lot of dependencies, both runtime & build.

You could try running # pkg check -d, this will check for any missing dependencies.
 
Nothing about qt5:


Code:
# pkg check -d
Checking all packages: 100%
gstreamer1-plugins-lame has a missing dependency: lame
gstreamer1-plugins-lame is missing a required shared library: libmp3lame.so.0
gtk-send-pr is missing a required shared library: libssl.so.7
gtk-send-pr is missing a required shared library: libcrypto.so.7
seed is missing a required shared library: libreadline.so.8
seed is missing a required shared library: libmpfr.so.4

>>> Missing package dependencies were detected.
>>> Found 1 issue(s) in the package database.

pkg: No packages available to install matching 'lame' have been found in the repositories
>>> Summary of actions performed:

lame dependency failed to be fixed

>>> There are still missing dependencies.
>>> Try fixing them manually.

>>> Also make sure to check 'pkg updating' for known issues.
 
Easiest (quickest) way that I can think of would be to forcefully re-install everything as a binary package. Something in the likes of: # pkg install -f, this would forcefully reset everything back to a binary package which should also fix any dependencies and version mismatches.
 
Sigh. We need application bundles with libraries. This is really unsustainable for desktop usage. I just wanted to add one piece of software. Now, I guess because the quarterly repo has got refreshed, I end up with vlc and krita not working. I see I have both qt4 and qt5 installed. After qt5 upgrade some other qt stuff is not starting, e.g. Qt5 Designer won't start. If I try to remove qt4 then scribus and texworks want to go away. I'm not even sure how to begin untangling this mess. I guess I'll have to hold my breath, stop all work for a few hours and force-upgrade everything (it wants to upgrade 520 packages). Geez! (It's upgrading TeXLive as I write this. Why on Earth?!)
 
There's a simple solution you're overlooking; Keep your system updated at all times. So that means running pkg upgrade on a regular basis.

Another option is to switch to the latest package branch instead of the quarterly branch. You will get constant updates and/or changes though. But if you keep that updated (once a week for example) there's rarely an issue. Personally I prefer the more "rolling" releases of the packages as opposed to big chunks every three months. The quarterly branches are basically intended to be used on production servers, not desktops.
 
I don't think it's a solution, more like a workaround. I can easily imagine a desktop need where user would want to stick with a particular software version. E.g., a bug introduced in LibreOffice or some other big package. On Mac, for example, I didn't upgrade MS Office since 2011 or so because the GUI wasn't working right since some version. Imagine being stuck in the middle of a research project and your laptop suddenly decides it wants to upgrade your whole lab setup. No, SirDice, I cannot accept this as a solution.
I've resolved this problem with Krita by doing pkg upgrade of everything, but in the long term run BSD derivatives with the same package management concept will never be able to gain popularity on desktops exactly because of this particular issue.
 
I've resolved this problem with Krita by doing pkg upgrade of everything, but in the long term run BSD derivatives with the same package management concept will never be able to gain popularity on desktops exactly because of this particular issue.
You're now overlooking the fact that package dependencies aren't limited to FreeBSD. Both RPM (used on RedHat based Linux environments) as well as DPKG (Debian bases) all use the same principle. Heck; even Windows and MacOS know this principle.

And for good reason: it would be a waste of resources if every software package you install would provide its own libraries. I mean: what good would it do to have 5 or 15 copies of the same libraries installed?
 
People's time is more expensive than the disk space that is getting cheaper every day. MacOS is handling that efficiently via application bundles. No such problem at all there. I can run ancient LibreOffice there and the latest Qt stuff. I can have PHP of my choice. There's no forced need to upgrade your system.
 
There's no forced need to upgrade your system.
Except when there's a security vulnerability in a common library. And you updated a few bundles you knew had that library. Then get ransacked by malware because there were a couple of other bundles you didn't update and had that vulnerable library embedded.

You're going to need to update one way or another. It really doesn't matter if things are bundled or not. Shared libraries only makes this process easier because you update that library and can be sure every application that uses it is secured.
 
I'm running Mac desktop since about 2009 and never experienced an issue. I mean, I bet most users will be ready to compromise a little security on their firewalled desktops in the favor of a stable working environment with predictable software versions. If you're having to run servers, you can always build software from ports. Perhaps, it's just the way software should be managed for servers (ports, rolling updates) is not the way it should be done for desktops.

Edit, sorry, SirDice but I again disagree that it doesn't matter. Never had this dependency hell on a Mac and never had to experience forced upgrades. It was always an option, which is important if you want to have predictable working environment. And I was always a few years behind the latest MacOS version, just because it was more important for me not to update and get the work done, rather than risk having a new version of software in my lab that would mess up the workflow when I couldn't afford it. I prefer to upgrade my environment when I can afford it, not when the OS decides it.
 
Ola,

Just to throw my two cents in ...

I agree with blackhaz core point. Running package upgrade periodically is a workaround. I just played the Qt game with VirtualBox (still fail). If

I am moving thirty-some machines deployed in North America, South America, Australia, Central Asia, and Western Europe to FreeBSD from OSX. That does not count development, test, and local use systems. The number of deployed systems will grow. Now that we have been acquired by a much larger fish, I anticipate accelerated growth. I have been gently pushing to have the project servers changed to FreeBSD as well.

The expected behavior of a package install command is that *everything* needed by that package is installed or upgraded or whatever. After installing a package, it should be useable.
This is contrary to what I have been experiencing since FreeBSD 10. The previous (and current) implementation approach seems to remain in the Maintainer_Must_Handhold_The_OS camp.

I am very, very, very, very, (keep adding) appreciative of all the work that has gone into FreeBSD. I have fantasies of being able to give back to the project once I finish moving the systems to FreeBSD.

I want FreeBSD to be the 'go to' operating system for entities requiring more control and more flexibility for non-consumer (or office) functionality and capabilities. This involves dealing with some very boring and very old issues. The package system being one.

As a side note I only moved this computer to FreeBSD a little over a month ago. it is an Asus Predator Helios 300 laptop. I am still configuring it. This install is really too new to have issues with packages. I also have a Sony Viao laptop running FreeBSD 11.1. I have several Mac Minis for the company project and as I said, I intend to moving all current and future deployed systems to FreeBSD.
As a community, we might need to add alternative approaches to the architecture and design of the various components. Not to replace but to enhance.


=thoth=
 
You have to keep in mind that you don't get any of this flexibility on systems that offer binary only packages. Take a Linux distro, for example ubuntu 18 and you can't even start thinking about changing the versions of the core libraries because the packager of the software (ubuntu) has already made the decisions for you of which versions must be used. Even if you build from the source debs you can't fight the api/abi rules set by the vendor.

FreeBSD's approach to 3rd party software is both a blessing and a curse because it leaves many choices to the individual port maintainers and users, it allows you tune the options and dependencies in many ways but it also allows you to shoot yourself in the foot if you're not careful.
 
The expected behavior of a package install command is that *everything* needed by that package is installed or upgraded or whatever. After installing a package, it should be useable.
Well, that is exactly what happens on FreeBSD. Of course the "usable" part is up for debate because software gets installed "as is", in most cases you don't get any handholding with pre-configured setups so if a service requires configuring then it obviously won't be able to run out of the box until after you applied your configuration.

But other than that: if you install package X (or X itself) you'll also get every required package needed to make it run. However... it is very important to realize that the ports collection isn't maintained by FreeBSD itself but individuals who take care of that part of the ports collection. So obviously some hiccups can occur from time to time.

But generally speaking it just works.

This is contrary to what I have been experiencing since FreeBSD 10.
Then I can't help but wonder if you did all that correctly because my experiences are completely the opposite. "When in Rome do as the Romans do", is the saying.

I want FreeBSD to be the 'go to' operating system for entities requiring more control and more flexibility for non-consumer (or office) functionality and capabilities. This involves dealing with some very boring and very old issues. The package system being one.
No offense but I can't help pick this up as a statement made by many newbies before you, which is that you expect the system to do what you expected of it. All fine and well, but what about actually studying and learning how things work before outing any criticism? Note: I don't care about the criticism at all, but being able to actually back up your opinion and statements with facts and examples goes a long way.

Too many newbies (once again: in my personal opinion) apparently lack the patience, or maybe the motivation, to put the required effort into a system in order to learn how it works. They basically expect the kind of hand holding you get on systems such as Windows or MacOS where you can simply install software with the click of a mouse button. And when they don't receive that level of handholding the "blame" is put with the system which - in their opinion - should cater much better to their wishes. While fact of the matter is that the system works pretty solid if you know how to use it, and thus use it correctly.

Some systems out there don't hold your hand but expect you to put in effort in order to learn how to use it. And quite frankly I don't consider that a problem at all, especially if the whole thing already does a good job.
 
I just played the Qt game with VirtualBox (still fail).
It's pretty much impossible to get this kind of version mismatch from a single set (build) of packages. Did you make quarterly -> latest repo switch between installing qt and virtualbox?
 
Hi People,

Some decent points were raised but I think we are stepping around a core point. I believe that some of the core, not-sexy issues may not be getting enough attention. Granted, limited resources and all.

This system is about 50 days old. I had to reinstall FreeBSD in September because I wanted to change the installation that I had completed in August (maybe July).
Predator: ~: uname -a
FreeBSD Predator 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

My intent is to do it one more time from scratch with FreeBSD 12 in the hope that the wireless support works with this machine.



You have to keep in mind that you don't get any of this flexibility on systems that offer binary only packages. Take a Linux distro, for example ubuntu 18 and you can't even start thinking about changing the versions of the core libraries because the packager of the software (ubuntu) has already made the decisions for you of which versions must be used. Even if you build from the source debs you can't fight the api/abi rules set by the vendor.
i am not looking for FreeBSD to be like other systems. Note that I did not mention other operating systems.
I agree with what I call 'The Complete Ecosystem' approach as I call it when describing it to my bosses at work.

FreeBSD's approach to 3rd party software is both a blessing and a curse because it leaves many choices to the individual port maintainers and users,
i know this. Over the last twenty years of writing code (much of it a contractor) I have encountered the 'it works on my computer' syndrome many times.
Again, do not misunderstand me. This approach works for FreeBSD and is necessary for FreeBSD. However, we need some way of reducing the number of 'escapes'.

software gets installed "as is",
This is to be expected and I have zero problem with that. But in this case, it would have been good to know up front that something special was needed.
This issue that led me to this particular post was VirtualBox. My problem was that I did not even know it was a Qt program until I tried to run it from a terminal. That is something I should have known up front. I might have installed Qt beforehand. Additionally, I had the expectation that the Qt components on which VirtualBox depends on would be installed during the installation of VirtualBox. This was not the case.
This after I installed both the specific version (5.11, I think) and the meta package:
Predator: ~: VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/local/lib/virtualbox/VirtualBox.so",) failed: /usr/local/lib/qt5/libQt5Core.so.5: version Qt_5.11 required by /usr/local/lib/virtualbox/VirtualBox.so not found

From my perspective, I did what I thought I was supposed to do to no success.



the ports collection isn't maintained by FreeBSD itself but individuals who take care of that part of the ports collection. So obviously some hiccups can occur from time to time.
I know. And I am grateful for their efforts.
The question becomes, how can we reduce the frequency of hiccups? What needs to happen to help people identify issues?
VirtualBox was one of the first programs I installed, granted that was fairly recently. I have tried to install it several times since. None were successful (until today).

But generally speaking it just works.
Generally speaking, This Is Truth.

Then I can't help but wonder if you did all that correctly because my experiences are completely the opposite. "When in Rome do as the Romans do", is the saying.
I may have done something wrong, I not have done something I was supposed to do.
I am learning, learning, learning FreeBSD.
One of the reasons I put FreeBSD on two work laptops was to have a daily use personal system and a daily use professional system. The only way I will learn what I think I need to is to use it daily and deal with the issues I encounter.
But that does not mean that everything is hunky-dory, sunshine and roses. Problems have to be identified and resolved or improved.

No offense but I can't help pick this up as a statement made by many newbies before you, which is that you expect the system to do what you expected of it. All fine and well, but what about actually studying and learning how things work before outing any criticism? Note: I don't care about the criticism at all, but being able to actually back up your opinion and statements with facts and examples goes a long way.
Some systems out there don't hold your hand but expect you to put in effort in order to learn how to use it. And quite frankly I don't consider that a problem at all, especially if the whole thing already does a good job.
If you knew me personally and my research, investigation, and documentation habits, none of the above would ever have occurred to you to say.
No harm, no foul.

It's pretty much impossible to get this kind of version mismatch from a single set (build) of packages. Did you make quartely -> latest repo switch between installing qt and virtualbox?
I did not think I needed to. The install is not very old. Also, I did not manually install Qt. I have not used it for several years and do not need it for work at the moment.

Some interesting notes:
- Qt was installed. I did not do it so perhaps some package did. The installed version was 5.10.
- Qt creator would not execute. I have not used it for five or six years and just put it on the list of things to research.
- Once I realized what was happening, I tried installing, removing, upgrading, etc. Qt to the required version, to no avail.
- Package Upgrade did the trick. After I performed that, VirtualBox runs.
But time could have been saved if something let me know about a problem. I don't think the VIrtualBox issue I experienced is the fault of FreeBSD at all. Since we know these things happen, it seems that there is a path to highlight the possibility.

Unnecessary Image just to make a point about newbies and research and effort.
20181021_164734_researchless.png





=thoth=
 
OK, now the inkscape is broken. Obviously, a problem with the glibmm library (Bug 232073), but for some reason even if I apply suggested patches and rebuild everything, the inkscape still doesn't work. This is yet another example of how sharing libraries may actually hurt desktop users. So I am sitting and waiting without inkscape.

I see Linux is moving in the direction of application bundles: https://appimage.org/
I think that's the greatest thing to happen to desktop Unix since having X. I wonder if something like that could be implemented on FreeBSD.
 
Thanks for mentioning the helper. The glibmm patch didn't work for me, but the patch for glib has just worked fine.
 
guys im in the same bucket of S#!T any news? /graphics/krita fails build with:
Code:
 /usr/ports/graphics/krita/work/krita-4.1.5/libs/ui/KisView.cpp

ninja: build stopped: subcommand failed.
 
edit: /usr/ports/graphics/krita/work/krita-4.1.5/libs/ui/KisMainWindow.cpp
comment line 2698 with two slashes

Code:
#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0)
       // newScreenObject = qApp->screenAt(e->pos());
#else
 
Back
Top