Closed darkoverlordofdata closed 1 year ago
I suspect that when installing/upgrading pkg packages, some packages get deinstalled.
We need to find a way to avoid this at all cost. How?
That sounds right. I left the terminal open before the install. Then I tried to launch featherpad from the command line, and got an error. There is a mismatch in Qt5 - the program was looking for 5.15.2, the system had 5.15.5. FreeBSD recently upgraded Qt5.
There is a pkg-lock command, that prevents changes to existing packages, so I ran
pkg lock --yes --all
Then I installed 'sudp pkg install chromium'.
It still fails, but I've never seen an error like this:
mozpeg-4.0.3 conflicts with jpeg-turbo-2.1.1 (installs files into the same place)
Chrome still fails, with libicui18n.so.71 was not found.
In addition, now Falcon fails with OpenGL context creation fails.
So I rebuilt the system again, I've discovered that Falcon is now authorized to log into gmail! So, I can do without chrome. I installed gnustep, but it fails to install with the same mozpeg issue, and Falcon fails again, with the same error.
(: It looks like it's a bit more than just existing side by side.
this freebsd thread https://forums.freebsd.org/threads/updating-installed-package-tries-to-remove-other-packages.67779/
hints at 2 solutions.
1) the other version of QT5 may be installed as a port. But they also warn not to mix packages and ports. 2) create your own repo. I think GhostBSD does that. Sounds like a lot of work.
References:
My theory is that if the packages on the system haven't been upgraded in a while, then (unlike from what I am used to from apt-get
)
pkg
in such a way that it never REMOVEs anything without the user explicitly typing pkg remove ...
create your own repo. I think GhostBSD does that. Sounds like a lot of work.
Which is why we want to stay with the official FreeBSD repos.
pkg lock --yes --all
Not a good idea.
The challenge is that vanilla FreeBSD favors server over desktop. Mozpeg is actually slower than jpeg-turbo. But it produces a smaller file to send over the wire (https://libjpeg-turbo.org/About/Mozjpeg). The GhostBSD repo reverts that change, and delivers jpeg-turbo, but still delivers the newer Qt.
I think ports are not very compatible with the goal of being human friendly. What about an img file like you have for developer files, that restore the missing Qt version and it's dependencies, such as the libicui18n lib?
Or... rewrite pkg for helloSystem requirements?
The challenge is that vanilla FreeBSD favors server over desktop.
This seems to overlook the distinction between FreeBSD, and ports for FreeBSD.
FreeBSD is:
an operating system used to power modern servers, desktops, and embedded platforms. …
As desktop use cases require ports, so most server use cases involve ports.
Each port has a maintainer, and so on.
I've read the 'party line', and I'm not trying to start a fight, but I see a different point of view..
My meaning is that FreeBSD does not cater to 'The Home Version'. When I was in IT, all of our workstations were small servers. Desktops are what you have at home.
But from reading the FreeBSD Foundation and forum I get the understanding that when they refer to desktop, they refer to their workstation. They can get pretty rude when people ask for help with a home computer.
I've tried to use ports - many fail due to lack of resource on my desktop, which is just above the minimum requirement for helloSystem.
If there's rudeness, that's unfortunate.
… My meaning is that FreeBSD does not cater to 'The Home Version'. … from reading the FreeBSD Foundation and forum …
End User (Laptop and Desktop) is the primary focus area in the Foundation's Technology Roadmap:
Some things are too easily overlooked. https://www.freebsd.org/releases/13.1R/relnotes/#boot-loader for example, "UEFI boot is improved for amd64. …" from the technical note, readers might never guess the scope or impact of this improvement. Essentially: 13.0 could not boot a broad range of computers, 13.1 ended that situation – https://forums.freebsd.org/posts/567118 – IMHO, a massive improvement.
… ports - many fail due to lack of resource …
Better use packages, unless there's a special reason to ignore them.
net/citrix_ica is an example of something that must not be redistributed as a package (licencing).
Where there's popular demand for something that can be packaged, strategic planning applies.
Plus, DRM to base https://gitter.im/FreeBSDDesktop/Lobby/archives/2022/02/18?at=620fda5f4164105ab0a48254, and so on.
In any case - after replacing my main computer (the old one died), I was hoping to reinstall helloSystem 0.7.0 on my backup hardware and resume testing. But I'm unable to discover any workaround to the forced upgrade. At this point it looks to me like the only thing that can be done is wait for the pre-installed software to be upgraded and a new iso is burned.
Until then, I see the biggest issue is that new users may try out helloSystem, and get a bad impression.
Until then bruce
What happens if you install helloSystem 0.7.0, then upgrade it with sudo pkg upgrade
? (Cancel it if it wants to REMOVE anything.)
Can you successfully install software afterwards?
sudo pkg upgrade want to remove files... And yes I can still install software. It appears that anything I install with a dependency on Qt5 causes the files at /usr/local/lib/qt5 to upgrade from 15.5.2 to 15.5.5, removing the older version. After that nothing that depends on qt will work - and if I reboot at this point, I just get a black screen. I can still use file manager. So I can get to xterm. once that is open I can run from the console and see the errors - mainly that the libqt5 15.5.2 files are missing. I can still import packages., but there is nothing I can find that re-installs the 15.5.2 files.
Well, this is embarrassing, but it finally works - I had to run the sudo pkg upgrade and type yes to all prompts. It's been so long since I've used a system that didn't automatically done that itself, and I still remember an early version, doing that and it didn't work, and you said not to. And it appears that now gnustep is pre-installed!.
maybe I spoke too soon - metalock is not working correctly. I'll leave that until morning. Consider this closed and solved.
zgrep pkg /var/log/messages.0.bz2
for older pkg
-related messages.
grep pkg /var/log/messages
for the most recent.
… files at
/usr/local/lib/qt5
…
For some of the packages in https://github.com/helloSystem/ISO/blob/experimental/settings/packages.hello:
% pkg provides /usr/local/lib/qt5 | grep -e qt5-l10n -e qt5-graphicaleffects -e qt5-sensors -e qt5-wayland -e py-qt5-webengine -e qt5-quickcontrols2 | sort
Name : qt5-graphicaleffects-5.15.5p0
Name : qt5-quickcontrols2-5.15.5p6
Name : qt5-sensors-5.15.5p0
Name : qt5-wayland-5.15.5p39_1
Name : qt5-wayland-5.15.5p39_1
%
Describe the bug after reinstalling 0.7.0, after installing an item from the menu, nothing will launch
To Reproduce Install iso at https://github.com/helloSystem/ISO/releases/tag/r0.7.0 open System -> Applications -> Internet -> Chromium install Chromium when done, try to launch applications from menu or dock
Expected behavior I expect applications to run. Nothing happens. I am unable to open Terminal. System -> Restart does nothing. The only things working are System -> About this computer, and Go -> Applications. But once the application folder is open, and double click on a selection, it does not run.
Version (please complete the following information): Installed hello-0.7.0_0G160-FreeBSD-13.0-amd64.iso
Computer (please complete the following information): Dell Inspiron 15 - 3521
Additional context Before I found this, I used terminal to use pkg to install metalock, so I can lock my screen. It instructed me to run pkg update. It's never done that before, in fact you once told me update was disabled. So I updated. After updating, metalock installed, and worked.
I have found the only way around this issue is to re-install the os. I then tried to install from menu both after running pkg update, and without running pkg update. No difference.
I've reinstalled the os and retried several times, to no avail.. The only way I am able to use it is to restrict myself to installing via the package manager. I've been using helloSystem since version 0.3.0 was released, and never seen this issue before. Other than some minor issues, it's been pretty solid, and very usable as a secondary computer.