I am not sure how to interpret that CONFLICT message.
# xbps-query -Rs smem
[-] smem-1.5_3 Memory reporting tool
# xbps-query -Rs smem
[-] smem-1.5_3 Memory reporting tool
# xbps-query -Rs cfitsio
[*] cfitsio-4.6.2_1 Library for reading and writing data files in FITS data...
[-] cfitsio-devel-4.6.2_1 Library for reading and writing data files in FITS data...
[-] cfitsio-32bit-4.6.2_1 Library for reading and writing data files in FITS data...
[-] cfitsio-devel-32bit-4.6.2_1 Library for reading and writing data files in FITS data...
#
smem is not installed, cfitsio is installed.
I think it must be trying to install smem, and it clashes with cfitsio?
My gut feeling is to remove cfitsio. I have no idea what that might break?
Yes that works.
It is a big update., including linux6.12-6.12.33_1 and another older linux. Took about 3 minutes.
It does an update-grub automatically, and seems to end happily
....
xdg-dbus-proxy-0.1.6_1: configuring ...
xdg-dbus-proxy-0.1.6_1: updated successfully.
111 downloaded, 1 installed, 110 updated, 111 configured, 0 removed.
you have mail
#
I seem to still have a screen. Now have to reboot and do update-grub in MX, then try Void again.
Void boot OK. I use Void to run virt-manager. So I thought I had better test a couple of VM’s… they worked.
So it is a mystery why some unknown package wants an old version of smem? It may be happy with the later version, or it may crash. I shall find out when something hangs.
There is still a problem
# xbps-pkgdb -a
ERROR: smem: hash mismatch for /usr/bin/smem.
ERROR: smem: files check FAILED.
#
I did a research on your problem. It´s of some interest to me as well, as I was (or am) considering installing Void Linux as a VM.
My investigation led me to the conclusion that the issue might be a packaging conflict or dependency error in the Void Linux repositories,
possibly caused by a file integrity problem with smem.
Putting smem on hold seems to have worked as a temporary workaround, but:
a more permanent solution involves investigating dependencies, fixing the hash mismatch, and possibly reporting the bug to the Void Linux maintainers
You might also:
Use xbps-query -Rx cfitsio to see what dependencies cfitsio has and if it requires smem or conflicts with it.
Use xbps-query -Rx smem to check what might be pulling in smem.
Run xbps-query -m to list manually installed packages and check for orphans.
Consider running xbps-remove -Oo to clean up orphaned packages.
Try reinstalling smem (if it is installed) with xbps-install -f smem to restore the correct file and hash.
If smem is not needed and is not installed, ensure that /usr/bin/smem does not exist or is not left over from a previous install
You certainly know those xbps commands better than I do, Neville.
So please check them again to see if they make sense.
Hi Rosika,
I only know the ones I use.
You have dug up some new ones ( new for me) … I need to try what you suggest
It is strange… xbps -Rs smem says smem is not installed… but it is there in /usr/bin/smem
Because putting a hold on smem allowed the update to proceed, it means something is trying to install smem… and it clashes with the one already there because it is attempting to install an older version than the one that is there…that does not make sense… it is, as you say … a package system error
I am very impressed… you seem to understand xbps
I think your xbps-query -m to check for orphans might solve it
You are right, I cant leave it on hold forever.
Thank you
Regards
Neville
If my research results are correct then this would apply:
If xbps-query -Rs smem reports that smem is not installed, but /usr/bin/smem still exists, it means the file is present on your system without being tracked by the package manager.
(This can happen if a package was removed but its files were left behind, or if the file was placed there manually or by another process.)
It seems to be safe to manually delete /usr/bin/smemif you are sure you do not need it and no package is managing it.
If you want to do this: sudo rm /usr/bin/smem
would be the right command.
This should remove the orphaned file and resolve the hash mismatch error reported by xbps-pkgdb -a.
But you should be sure that no scripts or workflows depend on this file.
I.e. make sure that it is truly orphaned.
BTW:
Have you installed xtools on Void?
If yes, then xlocate smem would help to see which package should provide /usr/bin/smem and confirm that it is not currently installed.
That is for thoroughness only and may be skipped.
Actually, I´m not sure how I would proceed myself in this situation.
I might take a timeshift snapshot first and then proceed with deleting /usr/bin/smem.
If it turns out to be O.K., then all is well. Otherwise I´d be able to set back the system to a previously well working state.
If xbps-query -o (which lists orphaned packages) does not report smem as orphaned, but /usr/bin/smem exists and : smem is not installed according to xbps-query -Rs smem,
this means /usr/bin/smem is not currently tracked by any package manager entry.
It is s a leftover or was placed there manually… That´s the theory behind it.
If no package owns /usr/bin/smem and smem is not installed, it should be safe to delete the file.
There really should be no risk to package management by deleting this file, since no package claims ownership of it.
Yes I need a backup… clonezilla
or
the safe thing to do is to hide rather than delete mv /usr/bin/smem /usr/bin/smem.hide
I can safely try that
I did not place it there
I suspect it may be part of cfitsio because cfitsio has a subcommand called smem, because…
That is the original message while attempting an update…cfitsio is involved somehow.
The only package that requires cfitsio is gimp… if I delete cfitsio gimp will stop working.
Therefore I have to try hiding smem.
Maybe just uninstall and reinstall GIMP? I haven’t used Void for a long time now so can’t help with the issue otherwise. I have Void on my PC still so if this didn’t help I can install GIMP to it later and check if I get same errors.
It now reports smem as installed.
So that is fine without gimp and cfitsio
Now what happens if I attempt to reinstall gimp
# xbps-install gimp
CONFLICT: smem-1.5_3 with cfitsio-4.6.2_1 in transaction (matched by cfitsio)
ERROR: Transaction aborted due to conflicting packages.
#
The packages cfitsio-4.6.2_1 and smem-1.5_3 clash, by installing smem-1.5_3 I have made it impossible to install gimp
It is a package system bug. I shall report it.
Meanwhile, I can do without gimp, so I leave it like it is and Void will be able to update.
I looked carefully at your posts and your diagnosis.
As far as my limited understanding goes I also think this is a genuine package conflict in the Void Linux repository, perhaps a packaging bug.
There seems to be no user-side workaround available and no simple workaround (neither hiding nor deleting /usr/bin/smem) will help.
So it really seems that it is for the Void Linux maintainers to fix the packaging so the conflict is resolved.
I admire your analytical assessment of the situation .
.
.