xbps-install -u fails with unresolved dependencies

[marcdraco]

Using: XBPS: 0.56 API: 20190621 GIT: UNSET

#xbps-install -u

libuuid-2.34_1 (update) breaks installed pkglibblkid-32bit-2.33.2_1'`

libuuid-2.34_1 (update) breaks installed pkglibmount-32bit-2.33.2_1'`

Transaction aborted due to unresolved dependencies.

This may not be due a bug in xbps-install but I don't know where else to report this issue nor how to correct it so I hope all will excuse my ignorance. This is the first time Void has burped since I installed it a few months back and I'm getting rather, er, lazy with updates because it normally goes without a hitch.

[Vaelatern]

# xbps-install -u
libuuid-2.34_1 (update) breaks installed pkg 'libblkid-32bit-2.33.2_1'
libuuid-2.34_1 (update) breaks installed pkg 'libmount-32bit-2.33.2_1'
Transaction aborted due to unresolved dependencies.

[marcdraco]

Thank you for that cleanup. I had a few goes at getting it right as you can see from the edit history - mind if I ask what the procedure is? I've always just used a code block...

[Vaelatern]

It's three backticks, followed by removing the backticks that xbps itself inserts before the installed package name.

[Vaelatern]

Be nice to be able to work backwards and add all the packages that might get broken to the list.

[Vaelatern]

And it would be nice to be able to automatically update the revdeps in non-general updates.

[marcdraco]

I figured that xbps-install is working as expected, but something down the line has broken it.

"Looks like he's not updating the "multilib" repository."

The what and where do I find it? The only repo I have is the one that came with Void, this error seemed to crop up when I tried to switch from XFCE to Gnome3 using the gnome meta package. It reported Gnome was installed (it wasn't) and things went sorta downhill from there.

Obviously, I can re-install the system, I'm quite capable of that, but I'm no longer a programmer (and I was never very good at C/C++ anyway).

I'll happily add this multilib repo but what surprised me that I had any 32-bit libs in the first place. I don't recall ever installing anything that would be specifically 32-bit. The only 32 bit software we use here is Valve's "Steam" and that never goes near my Void box at that's my daily driver! (It runs under Debian 9 on a separate physical server.)

I think as Vaelatern has noted something has gone pear-shaped a way back so it looks like we need some function to roll-back failed updates.

I would happily add a patch, but as I've already said, I simply don't have the skills. I'm happy to report "bugs" or failure events when they pop up but that's about my limit I'm afraid.

Since I'm obviously raising this issue in the wrong place, I wonder if the error could be more helpful for this kind of failure and direct those of us who lack the inside knowledge to the correct place?

Incidentally, one of my areas of expertise these days is in human learning, and part of that makes observations on things like this. (Not specifically IT, but it applies here.)

Xtraeme you note there's no bug but you have intimate knowledge of XBPS. I'd expect nothing less of course, but our research (outside of this discussion) notes that senior members of a team often (and often unintentionally) prevent discussion of wider issues and that causes problems.

United Airlines Flight 232 is a famous air disaster where hundreds survived what should have been an unsurvivable mid-air explosion (catastrophic) failure of the mid-engine when its turbine blade fractured under stress. One of the only reasons the plane made the airport at all was United's training to let lower-ranking flight crew discuss and promote ideas even though they lack the seniority or experience.

This is my wheelhouse (so to speak) so I hope you understand I don't raise this from a lack of respect, rather a need to identify where this problem is and get it fixed before someone else hits the buffers. This is, incidentally, why I stopped using Arch.

[Duncaen]

And it would be nice to be able to automatically update the revdeps in non-general updates.

This is already happening afaik.

The "issue" reported here is a completely different, from what I can tell. There are two different states for the main repository and the multilib repository in the cache.

I'll happily add this multilib repo but what surprised me that I had any 32-bit libs in the first place. I don't recall ever installing anything that would be specifically 32-bit. The only 32 bit software we use here is Valve's "Steam" and that never goes near my Void box at that's my daily driver! (It runs under Debian 9 on a separate physical server.)

There is no way xbps can install any -32bit packages without the user once enabling and syncing the multilib repository.

This is my wheelhouse (so to speak) so I hope you understand I don't raise this from a lack of respect, rather a need to identify where this problem is and get it fixed before someone else hits the buffers. This is, incidentally, why I stopped using Arch.

The thing is xbps identified the issue and prevented you from breaking the system. There is no problem other than not having synced all repositories correctly or not uninstalled -32bit packages when the repository was deactivated.

[marcdraco]

How can I check this? So far as I can tell I only have the main repo enabled. I have no recollection of ever enabling (let alone needing) 32-bit software.

Now let's assume I've erred here (this is entirely possible) but as a non-expert I don't do anything deliberately that can break the system.

How can I check which repos are enabled? (I know how to do this in Apline and Debian which I also use on a daily basis for other things.) One of the reasons for choosing Void was my ignorance in this area was less likely to cause issues, if that makes sense. (In Ubuntu, seems anyone and his dog can add a repo and I'd not be in the least be surprised if that can/does smeg stuff up.) I've certainly done that with Alpine by including stuff from Edge and then wishing like heck that I hadn't! :)

[Duncaen]

xbps-query(1) can list enabled repositories:

$ xbps-query -L
11047 https://alpha.de.repo.voidlinux.org/current (RSA signed)
 5899 https://alpha.de.repo.voidlinux.org/current/debug (RSA signed)
   55 https://alpha.de.repo.voidlinux.org/current/nonfree (RSA signed)
 4638 https://alpha.de.repo.voidlinux.org/current/multilib (RSA signed)
   31 https://alpha.de.repo.voidlinux.org/current/multilib/nonfree (RSA signed)

But if it wasn't synced its probably not enabled and there will be cache files:

$ ls /var/db/xbps/http*multilib*
/var/db/xbps/https___alpha_de_repo_voidlinux_org_current_multilib:
x86_64-repodata
/var/db/xbps/https___alpha_de_repo_voidlinux_org_current_multilib_nonfree:
x86_64-repodata

There is also a package void-repo-multilib which can be installed, but there is nothing that depends on it, you would have had installed it manually.

$ xbps-query -Rf void-repo-multilib
/usr/share/xbps.d/10-repository-multilib.conf

You can list all installed packages matching multilib in the respository with xbps-query(1).

$ xbps-query -p repository -s 'multilib'

Alternatively use xbps-query -m to list manually installed packages and grep for -32bit.

$ xbps-query -m | grep \\-32bit

So depending on what software you have installed and if you want to keep it, you would have to add the multilib repository. Otherwise you can just uninstall those packages.

[marcdraco]

Awesome help Duncan! Thank you, that got (almost) to the bottom of it.

$ xbps-query -L
11050 https://alpha.de.repo.voidlinux.org/current (RSA signed)
$ ls /var/db/xbps/http*multilib*
x86_64-repodata
$ xbps-query -Rf void-repo-multilib
/usr/share/xbps.d/10-repository-multilib.conf
$ /usr/share/xbps.d/10-repository-multilib.conf
bash: /usr/share/xbps.d/10-repository-multilib.conf: No such file or directory

This says to me (in my glorious ignorance) that I don't have multilib enabled (or do I? Honestly not 100% sure). So:

$xbps-query -p repository -s 'multilib'

And suddenly the terminal comes alive with all manner of 32-bit software libs that I had no idea I'd ever downloaded. I won't CC. it all here, you can take my word on that I'm sure and here appears to be the culprit.

$xbps-query -m | grep \\-32bit
wine-32bit-4.6_1

But the queer thing is that I cannot recall installing Wine 32 bit. I simply don't need it - Wine, yes, but I'd assume (perhaps incorrectly) that it only installed 64-bit versions of its libs?

I'm very grateful to everyone here for helping to track this down. I'll try removing Wine later - I only need it occasionally and then, only for testing odds and sods. Might have to dust off a Windows machine to do that.

For my reference - where's the best place to discuss issues such as this if not GitHub? It must be frustrating for Juan to see people almost accusing him of creating bugs when the reality is the software is working as it's designed. (When I was programming in 8-bit assembler, 35+ years ago, I can recall my frustration on being asked similar questions.)

If I may be so bold, more informative errors seem to be called for.

"Transaction aborted due to unresolved dependencies."

Is about as helpful to me and my advancing years as:

"A large oak tree has suddenly sprouted from your head."

I can't write a better error description because I'm still in the dark as to what that error means. "BBC" Basic had one I recall like this that caught out many a beginning programmer as when it said, rather perfunctorily:

"Too many FORs"

When it really meant was you'd forgotten to close the loop with a NEXT statement. I think as programmers (and I'm too old to be doing that any more) we forget that there are people out there using our software who don't share our level of expertise. Errors aimed at end-users (even more advanced ones) need to be sufficiently clear as to help with some self-care and not make assumptions. Hints, such as the ones you've written out here Duncan, are amazingly useful. Even a hyperlink to a page of "have you tried so-and-so" for these errors is better than having some old fart like me coming begging for help, assuming I've broken something (and worse) be utterly clueless of where best to even ask for help.

I hope that makes some semblance of sense.

[marcdraco]

UPDATE:

I removed Wine 32 bit and did xbps-remove -o and xbps-remove -OR

but I'm still getting the same error as there are bits of 32-bit libs left and the ones that it's throwing can't be removed because there are bits that those break. If I've missed anything else, I'm at your disposal.

[rubyFeedback]

I found this here while googling for errors. In my case binutils-doc was failing, when I tried to install GCC. This shocked me, because I thought void is a clever distribution, but clearly it is not when the assumption is "ok, let's cancel installing GCC if the user can not read the docs muahahahaha!". Well, I do not use any local docs anyway; I read online resources. I don't use man pages either, so failing to install GCC because of docs-related problem, is a sign of incompetency. Not only because the whole installation fails, and I now don't have a GCC - but also because of not providing the .iso installer with GCC in the first place. Guys, please learn from distributions such as manjaro - I'd love to get rid of systemd there, but manjaro works out of the box for the most part and I don't even HAVE to have to install GCC.

I am sure I may resolve this problem eventually, but yikes - the defaults on void are really horrible. Who is making such decisions? Why does "xbs-installer -S gcc" whine about not being able to install GCC because of binutils-doc? What the heck?