Problems Updating across all WeeDog-Void's

[rockedge]

I suddenly am encountering this error:

Code: Select all

sh-5.1# xbps-install -Suy
[*] Updating repository `https://mirror.clarkson.edu/voidlinux/current/x86_64-repodata' ...
x86_64-repodata: 1720KB [avg rate: 361KB/s]
[*] Updating repository `https://mirror.clarkson.edu/voidlinux/current/nonfree/x86_64-repodata' ...
x86_64-repodata: 14KB [avg rate: 323MB/s]
gtkdialog-0.8.3_4: broken, unresolvable shlib `libvte.so.9'
Transaction aborted due to unresolved shlibs.
sh-5.1# 

Both 32 and 64 bit versions are exhibiting this behavior

[wiak]

Been a long time since that gtkdialog with libvte included was built, but I remember that it was for Arch use only, since Arch didn't have appropriate libvte in its repo. See this earlier discussion:

http://www.murga-linux.com/puppy//viewt ... 10#1056610

Void I think has libvte in its repos (EDIT: probably, like Arch, no longer the gtk+2 version and that's part of the problem) so you should be using the earlier gtkdialog sfs I made (which was for early Void builds) (EDIT. Probably you do need gtkdialog + libvte sfs afterall, but from an sfs like I do with WDL_Arch64). I don't understand why your issue has only suddenly appeared though (unless you have only just not included that gtkdialog_libvte.sfs. Try without it. You may need to delete your upper_changes in new tests in case something in there now you don't want. I don't seem to have a copy of the previous non-libvte sfs on github since only started that when building WeeDogArch. I'll look further.

You could possibly probably open up the gtkdialog_libvte sfs and remove the libvte parts before squashing it up again. Or perhaps you are using a gtkdialog from Void repos (?) in which case you shouldn't also have the gtkdialog_libvte.sfs? (or maybe the opposite that you shouldn't use gtkdialog from the Void repo and need special sfs with libvte version??? Let me know how it goes. I'll also download your latest iso and take a look

wiak

[wiak]

Sorry, running out of disc space and only very slow rural broadband so just opened up your 2.6 version iso - no gtkdialog sfs used at all there. Could you confirm what gtkdialog you are using please? I'm no idea why that repo error message is occurring (and can't test myself right at the moment).

[wiak]

Okay, I can confirm the unresolvable gtkdialog repo error (on WD_Void32 version 2.6). My suspicion is that Void repo no longer supporting gtkdialog or only as gtk+3 version and some issue regarding libvte with that (I think that so.9 libvte is for gtk+2 but my memory is hazy on this). You may end up needing to remove that gtkdialog altogether and rely on a gtk+2 version in an sfs (probably including libvte) - in other words, the same gtkdialog I provide in an sfs for WDL_Arch except you'll need a 32bit version of that for WDL_Void32 (and the 64bit version for WDL_Void64).

I'll test now if xbps will remove gtkdialog and work thereafter. Unfortunatly, I haven't really used xbps for a long time so forget the commands... but now reading: https://docs.voidlinux.org/xbps/index.html

So now done:

xbps-remove gtkdialog

and xbps-install -Suy

now seems to be working.

After that, I'll try to put gtkdialog back in with: xbps-install gtkdialog
to see if it is still there... Else try the 10gtkdialog64_libvte.sfs from WDL_Arch64 at boot time for the WDL_Void64 (but as I said you'd need a 32bit version of gtkdialog...sfs for WDL_Void32).

Let's face it, gtkdialog is a dead/pretty-much-unsupported package (and named terribly since same as name of actual gtk+ component) so bigger distros dropping its use altogether. Developers should work towards redrafting their utilities to use something likely to be supported by the upstream repos.

[wiak]

However, good news is that Void still has that 0.83 version of gtkdialog but compiled for gtk+3 along with the newer libvte (which is a dependency). After removing the old one, the xbps-install -Suy update went fine. And then xbps-install gtkdialog works fine (including auto-install of the newer libvte). Problem should thus be solved.

EDIT: ldd /sbin/gtkdialog suggests it may still be a gtk+2 gtkdialog and libvte.so.9 has in fact been installed/re-installed so not sure what went wrong, but xbps-remove gtkdialog following by xbps-install gtkdialog appears to fix the issue anyway. Oh well... gtkdialog may well disappear in the future though...

[rockedge]

@wiak The procedure worked for me as well, in most cases. Most of my systems tested will be fixed after the xbps-remove of gtkdialog and then the immediate re-install of gtkdialog. But other systems almost exactly the same this will not fix it, but xbps-remove then a xbps-install -Suy will work THEN re-install gtkdialog worked.

Funny thing is, first I tried to remove gtkdialog and reinstall and that did not work....but I was really tired and it was really late (early) so who really knows what I was doing and attempting.

[wiak]

@wiak The procedure worked for me as well, in most cases. Most of my systems tested will be fixed after the xbps-remove of gtkdialog and then the immediate re-install of gtkdialog. But other systems almost exactly the same this will not fix it, but xbps-remove then a xbps-install -Suy will work THEN re-install gtkdialog worked.

Funny thing is, first I tried to remove gtkdialog and reinstall and that did not work....but I was really tired and it was really late (early) so who really knows what I was doing and attempting.

Hmmm... not sure what overall issue is. Originally, it made sense if gtkdialog had been changed to gtk+3 version upstream, but clearly that is not the case. I sometimes wonder if when Void updating/mirroring its repos upstream results in temporary glitches like this. Mind you, I think such mirroring jobs causes issues with most any distro repo. Used to be we were safe most of the time from such effects because upgrades/mirroring done late at night, but now there in this global community there is no such thing as 'late at night' timezone-wise.

[rockedge]

@wiak Here is a fix for the update problem encountered with gtkdialog and it's dependencies from the original developer :
https://gitlab.com/xtraeme/xbps/-/commi ... d884108e61

I have just removed it using xbps-remove, then cloning Puppy Linux's version from the woof-ce github and compiling it to work in WeeDog32-Void and probably will have to do in the 64 bit versions. Although I might just apply the fix and test it out if the gtkdialog 0.83 is still on board.

[wiak]

I think there is also a pin existing package mechanism for Void, but I don't have a wdl void install in front of me right now to check (on Android phone). One alternative is to use a puppy apps sfs including appropriate gtkdialog as I do with wdl Arch64. Otherwise, as proved elsewhere, open the box up and short out all the pins with a sharp knife . Actually, that off-topic technique may be a dodgy alternative approach to locked BIOS situations, but then again...

I wonder if current void maintainers update according to what they discover at xtraeme's gitlab site?