VoidPup32 and VoidPup64 Discussion

[artemis]

@Feek yeah, I use fossapup64 as my primary OS and have for about a year now

[Feek]

@Feek yeah, I use fossapup64 as my primary OS and have for about a year now

Are you sure your voidpup64 installation was successful? (Personally, I wouldn't use the dd command to install an .iso file)
I also have a Thinkpad (another type), about 10 years old and Voidpup64 22.02 works normally.

You may want to create a new topic that describes how you proceeded with the installation step by step. There will definitely be someone here to help you fix your installation or reinstall if needed.

[artemis]

I just used isobooter, nothing complicated. ill make a thread if i feel like figuring it out later but right now im happy with fossapup. just wanted to give voidpup a try cause i like void linux, but im not really that dedicated to it. thanks for the advice!

[peebee]

288fc95e0b684570226e8c47f7e10f50 VoidPup32-22.02+5.iso
a5237b8bfd11259803e9ad7cf32bab1a VoidPup64-22.02+5.iso

see viewtopic.php?t=5270

- busybox update
- gtkdialog update
- Woof-CE update
- Void updates
- kernel updates

[mikeslr]

Just a note of the availability of artha --the thesaurus employing wordnet-- from the link here, viewtopic.php?p=58096#p58096

I intend to add it to the ydrv.sfs I created to hold applications which are 'alien' to Voidpup but which I'll always want available.
Just a reminder, if you install it to a SaveFile/Folder, you can uninstall via the 'Software' module of Menu>Setup>PupControl.

[artemis]

I got VoidPup32 booting from a USB DVD drive! But I have another bit of a problem trying to use it on my intel atom netbook. This thing has a poulsbo graphics driver which does not have hardware acceleration except in some weird old userspaces I have never gotten working (normal, I'm used to this).

Usually i use llvmpipe and it's plenty fast enough to use but it seems like voidpup32 does not include llvmpipe in its mesa build, only softpipe. softpipe is so slow i cannot really use it at all. You can try to run it with

Code: Select all

GALLIUM_DRIVER=llvmpipe glxinfo

and it will give an error. Is there a way i can install llvmpipe after or make a version that has llvmpipe in it?

cheers!

EDIT: I learned that apparently this is because of a bug in void's mesa package template where they forgot to add i686 support. Not a puppy thing at all (i have just never run void with software rendering i guess). So if I can do a custom build of the package with that bug fixed I can replace voidpup's mesa package and it should be fine

[peebee]

I can replace voidpup's mesa package and it should be fine

It might be worth trying the Slackware mesa package:
http://ftp.slackware.com/pub/slackware/ ... i586-2.txz

Void's is 21.3.7 ..... 15.0 is 21.3.5 and Current is 21.3.8

If it works you could put it into a ydrv as a system "patch"..........

Just a thought
Cheers
peebee

[artemis]

I can replace voidpup's mesa package and it should be fine

It might be worth trying the Slackware mesa package:
http://ftp.slackware.com/pub/slackware/ ... i586-2.txz

Void's is 21.3.7 ..... 15.0 is 21.3.5 and Current is 21.3.8

If it works you could put it into a ydrv as a system "patch"..........

Just a thought
Cheers
peebee

thanks for the suggestion. unfortunately that fails with this in xorg log:

Code: Select all

/lib/libc.so.6: version `GLIBC_2.33' not found (required by /usr/lib/libgbm.so.1)

[peebee]

195fddc143904dba6336aea19a712c56 VoidPup32-22.02+6.iso

e444c584de43e43fcc5ab712b4d3ab22 VoidPup64-22.02+6.iso

see viewtopic.php?t=5270

[mikeslr]

Just reporting that the upgrade from 22.02+5 to 22.02+6 went 'as smooth as silk'. As I had in previous iterations replaced your adrv (which only contains Light-browser) with a ydrv (containing applications alien to Void) I just substituted my ydrv for your adrv before booting into '6' the first time. Since my ydrv also has my settings and configurations, '6' booted to desktop with them. There was nothing for me to do before posting this other than checking to see if anything was broken. Nothing was.
Another great job.

Perhaps you could provide a change-log in the future?

[rockedge]

with a ydrv (containing applications alien to Void)

I am interested in which applications you have going!
On another note @peebee Here is a xbps package of the Dropbear SSH server ready to go. I am installing it during the build run of KLV-Airedale but it should do great in VoidPup64. (I could compile a 32 bit version as well)

dropbear-0.81_1.x86_64.xbps

Once installed to run create the security keys in a terminal: set_dropbear_keys.sh then again in a terminal dropbear starts the SSH server.

Other XBPS packages that might be interesting for VoidPup64 are in the XBPS_packages section located here -> https://rockedge.org/kernels/

[peebee]

Perhaps you could provide a change-log in the future?

Thanks.

The best I can do:
Woof-CE:
https://github.com/puppylinux-woof-CE/w ... ts/testing
BUILD_FROM_WOOF='testing;54319690e;2022-06-13 17:32:17 +0000'

Void Linux:
see /var/packages/woof-installed-packages for version details

:Pup-SysInfo:

:boost:

:gparted:
:gtk+3:

:harfbuzz:

:htop:
:icu4c:

:icu4c:
:xorg_base_new:

:gtk+3:
:libgbm:

:libglapi:
:harfbuzz:
:libical:

:libnftnl:

:rdesktop:
:libsoup:
:libpsl:

:libunbound:
:vala:
:libxatracker:
:xbps:

:libxkbcommon:

:libxml2:

:mariadb:
:mesa:
:mesa:
:mozilla-nss:

:mozilla-nss:

:tiff:

:vala:

:vte3:

:xbps:

[Trapster]

How to fix this?
I've been using voidpup for a few months now and like it on my eeepc 1005ha.
Updates have been working until the past week.
Now i'm getting shlib errors.
Currently using VoidPup32-22.02+6

Code: Select all

# xbps-install -S
[*] Updating repository `https://repo-us.voidlinux.org/current/i686-repodata' ...
# xbps-install audacious
qt5-gui-5.15.3+20220222_3: broken, unresolvable shlib `libharfbuzz.so.0'
qt5-core-5.15.4+20220606_1: broken, unresolvable shlib `libicui18n.so.71'
qt5-core-5.15.4+20220606_1: broken, unresolvable shlib `libicuuc.so.71'
audacious-plugins-4.1_4: broken, unresolvable shlib `libxml2.so.2'
conky-1.12.2_1: broken, unresolvable shlib `libxml2.so.2'
Transaction aborted due to unresolved shlibs.
# 

Help.

[peebee]

How to fix this?
Help.

Look to be due to the updates in +6..........

https://docs.voidlinux.org/xbps/trouble ... lib-errors

provides guidance - you need to remove the orphan packages and reinstall them.

I suggest you make a backup of your personal save folder / file before doing so.

[Trapster]

It seems I can't remove or install anything.

Code: Select all

#xbps-remove -o
audacious-plugins-4.1_4: broken, unresolvable shlib `libQt5Core.so.5'
qt5-dbus-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-declarative-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-gui-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-multimedia-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-network-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-sql-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-test-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
qt5-widgets-5.15.3+20220222_3: broken, unresolvable shlib `libQt5Core.so.5'
audacious-plugins-4.1_4: broken, unresolvable shlib `libaudcore.so.5'
audacious-plugins-4.1_4: broken, unresolvable shlib `libaudqt.so.2'
audacious-plugins-4.1_4: broken, unresolvable shlib `libaudtag.so.3'
qt5-gui-5.15.3+20220222_3: broken, unresolvable shlib `libharfbuzz.so.0'
audacious-plugins-4.1_4: broken, unresolvable shlib `libxml2.so.2'
conky-1.12.2_1: broken, unresolvable shlib `libxml2.so.2'
Transaction aborted due to unresolved shlibs.
#

[mikeslr]

with a ydrv (containing applications alien to Void)

I am interested in which applications you have going!...

I discussed the creation of the ydrv here, viewtopic.php?p=48505#p48505 where you'll also find a link to an SFS of libraries (mostly qt4) which can't be found on Void's repositories. For my use, I converted it into a pet which was installed during the creation of the ydrv,
As the needs/desires of users will vary, I'll just touch a little more on the process, then mention applications I included and those I've tested but were not included as, with my limited abilities, I could not find a means to run under Voidpup64.
The process begins with a 'naked' Void64, fresh OOTB or booted pfix=ram so that (a) I'll know what is presently missing and (b) I'm not unnecessarily (see below) including applications and libraries Void has or can provide. Although other tools to create ydrvs could be employed, [PaDS, for example] I used amethyst's nicOS-Utilities-Suite's Save2SFS as it's specifically designed for the purpose of creating a ydrv.sfs or an adrv.sfs or both. Void's built-in adrv which only contains Light-browser can either be discarded or captured by Save2SFS*. User's choice as to whether settings such wifi are captured. If not, remember to delete settings you don't want to be a permanent part of your system. For example, set geany>Edit>preferences>Files>Recent Files List Length to 0/zero before running Save2SFS.
The first things I do is install ListDD and add 'run-in-terminal' to the Right-Click menus with respect to binaries, scripts and AppImages (if these are not already present). ListDD identifies what's missing; being able to Right-Click saves a lot of typing (and remembering: not my strong suit )

In-Ydrv.png (65.2 KiB) Viewed 3184 times

The above screenshot is of PPM's Uninstall and shows what was included in the ydrv. How to access PPM Uninstall is explained in the prior post. The screenshot, the prior post and the discussion MikeWalsh and I had following it identifies the source of some applications and overcoming some issues.
Skip gxlat: I'm sure I tested it before including it. But it no longer runs for reasons I have yet to determine and probably won't bother to in the light of recent posts on its thread. If and when I modify ydrv, I'll remove it. Removal of applications can be done manually, by Save2SFS when creating a new adrv/ydrv or --untested by me-- using nicOS-SFS-Editor https://www.forum.puppylinux.com/viewto ... 846#p54846.
As noted in the prior post, MikeWalsh's xvidcap64-portable works. I located it in /opt. I don't know why PPM doesn't show it: perhaps because of the way its menu entry is created. IIRC, it required libpng which is included in the SFS you can download.
pwidget's is almost fully functional: only Its weather widgets don't report temperature.
I'm pretty sure xvkdb is from Void's repos. Not sure why PPM knows about it. It, like mpv --which I've also included in my ydrv-- are applications I always want available and unlikely to require updating. [Applications, such as web-browsers, which frequently require updating I consign to an adrv.sfs. adrv.sfs have priority over ydrv.sfs. Having a web-browser in an adrv.sfs or ydrv.sfs enable booting pfix=ram and accessing the internet without having any partition mounted. If run from a USB-Key, it can be unplugged after boot-up. Any application which requires that a partition be mounted --such as portable wine after using duprate? 32-bit compatibiity SFS-- are left to be used with a SaveFile/Folder].

I discussed LibreOffice-RightClick here, https://www.forum.puppylinux.com/viewto ... 432#p43432. Installing it enables me to SFS-Load libreoffice (No-Copy) then open files in its Writer and Calc. Doing so doesn't mount the partition on which LibreOffice.sfs is located.
Clear-places: this is just a pet I created using instructions provided I think by peebee in order to delete the record used by the places launcher before creating/updating adrv/ydrv.
Spot2root > MikeWalsh's small application for transferring/changing permissions of files if a web-browser ENTIRELY located in /home/spot is used.
I haven't actually every run dukto: just thought it worth having. It starts without issues.
Other applications which I've successfully run under Voidpup64 which could (theoretically) be included in a ydrv.sfs: Avidemux 2.8 (I think grey's from Fossapup64 User Thread); fotoxx-portable (MikeWalsh's ? portable assigned to /opt); and MikeWalsh's gimp-portable.
Other than the problem with grub2config the only application my notes reflect not being able to run was radky's sct_control.

[mikeslr]

Although I reported that the upgrade of VoidPup64 from version 5 to version 6 went 'as smooth as silk' that was before I created a SaveFile/Folder. As my last post noted, I don't make use of wine except after I've created one and loaded the 32-bit compatibiity SFS. [I still prefer wine-portable to a Wine.AppImage and wine-portable requires a mounted partition]. When I attempted to sfs-load the 32-bit compatibility SFS in version 6 I received this report:

32bit-Compatibiity-Not Loading.png (10.68 KiB) Viewed 3160 times

Booting back into version 5, wine-portable still functioned. In addition, gxlat which I reported as no longer working under 6, also still functioned under 5.

I have no idea what's changed, nor how to work around it,

[mistfire]

Although I reported that the upgrade of VoidPup64 from version 5 to version 6 went 'as smooth as silk' that was before I created a SaveFile/Folder. As my last post noted, I don't make use of wine except after I've created one and loaded the 32-bit compatibiity SFS. [I still prefer wine-portable to a Wine.AppImage and wine-portable requires a mounted partition]. When I attempted to sfs-load the 32-bit compatibility SFS in version 6 I received this report:

32bit-Compatibiity-Not Loading.png

Booting back into version 5, wine-portable still functioned. In addition, gxlat which I reported as no longer working under 6, also still functioned under 5.

I have no idea what's changed, nor how to work around it,

That means your sfs modules contains /bin /lib /sbin folders (aka non-usrmerge) while the /bin /lib /sbin in your root filesystem was just a symlink (aka usrmerge) or vice versa. make sure that sfs module content matches to your root filesystem

NOTE: usrmerge is a new Linux file hierarchy standard where /bin /lib /sbin are symlinked to /usr/bin /usr/lib /usr/sbin

[mikeslr]

Thanks mistfire. To check whether anything in my ydrv might have cause the problem I booted into a pristine (OOTB) version 6, created a SaveFolder during reboot and tried to SFS-load the compatibility SFS. The same failure Notice reported above appeared,

That means that the compatibility SFS will have to be restructured per your explanation. [Though it would be better if someone could figure out how to have Voidpup64 manage multi-architecture as Void does].

gxlat can also be examined to see if it's failure is has a similar cause.

[peebee]

That means that the compatibility SFS will have to be restructured per your explanation. [Though it would be better if someone could figure out how to have Voidpup64 manage multi-architecture as Void does].

Hi @mikeslr

I haven't provided a 32-bit compatibility sfs for VoidPup64............. which sfs are you using?

The story of 64-bit Linux lib structures is a complex one as just about every distro does something different. (unlike 32-bit where most were generally compatible).

The extra sfs-load checks have arisen because some devs want to make pups that are Debian/Ubuntu clones and and lib symlinks can be clobbered by installing incompatible sfs.

Slackware has the cleanest 64-bit lib structures. Debian/Ubuntu has the most convoluted. Void is somewhere in between but closer to Debian than Slackware.............

[mikeslr]

I know you didn't publish the compatibility SFS. My flaky memory suggests Duprate did. But I can't find the post from which I obtained it. It may have been lost when when VoidPup's discussion was moved.

I'm well aware of the problem. No 64bit Puppy binary compatible to a debian or ubuntu has ever been published with handles mult-architecture the same way as it's 'parent'. The use of 32-bit compatibility SFSes is, in fact, a work-around for that failure.

I ran into the problem 5 years ago in using PaDS 1.1.4 to combine debs into an SFS under either Tahrpup64 or Xenialpup64. I reported that while PaDS 1.1.4 successfully decompressed 'ubuntu' debs and placed their contents in folders name x86_64-linux-gnu under /lib, /usr/lib and /usr/local/lib Puppies could not find those folders. The work-around was created a target folder, mount PaDS's output and copy the contents of its folders into their parent folders in the target, create symlinks named x86_64-linux-gnu pointing to the respective parents then dir2sfs the target folder . taersh subsequently published PaDS 1.1.7 which automated that process.

Contemporaneous with debian/ubuntu's creation of the structure involving x86_64-linux-gnu folders Slackware created a structure in which 64-bit libraries were placed in folders named lib64 under /lib, /usr/lib and /usr/local/lib. PaDS 1.1.4 had no problem creating usable SFSes for Slacko64's. When I discovered that 'debian/ubuntu' Puppies could 'find' lib64 folders, I suggested that woof be modified so that debian/ubuntu Puppies would present Slackware's structure. But it appears that subsequent changes to woof now prevent 'debian/ubuntu' Puppys from using that simple fix.

The situation has gone from bad to worse.

[dimkr]

I'm well aware of the problem. No 64bit Puppy binary compatible to a debian or ubuntu has ever been published with handles mult-architecture the same way as it's 'parent'. The

That's wrong: Vanilla Dpup (https://vanilla-dpup.github.io/) and Vanilla Upup (viewtopic.php?t=5290) use the same directory layout as Debian, and 32-bit libraries coexist nicely. You can safely apt install steam with all its 32-bit dependencies, and it works just fine.

I'm sure it's possible to change VoidPup's directory layout in a similar way, to make it more Void-compatible, but that's the easy part. All the old .pet packages included in VoidPup will need to be rebuilt, or at least, repackaged with everything in the right place. Also, Void is a rolling distro while VoidPup isn't, so if a Void package cannot be installed unless a dependency is updated (and that's far more likely to happen as VoidPup ages), installing packages can be risky. VoidPup will need some form of protection against updates that may break the Puppy-Void hybrid directory layout by replacing a directory with a symlink, or vice versa, and protection against incompatible .pet packages that can break it.

It took some effort to get apt and 32-bit packages to work in a Debian-based Puppy, but it's possible.

[Grey]

and Vanilla Upup (viewtopic.php?t=5290) use the same directory layout as Debian,

Hi. In Upup, is USR_SYMLINKS=yes still responsible for this? Nothing additional has appeared/been invented ?

[dimkr]

and Vanilla Upup (viewtopic.php?t=5290) use the same directory layout as Debian,

Hi. In Upup, is USR_SYMLINKS=yes still responsible for this? Nothing additional has appeared/been invented ?

I had to implement USR_SYMLINKS=yes, code doesn't write itself

(And I had to do other things, like preventing apt from updating packages by default, using Debian's /etc/ld.so.conf*, using Debian's /etc/profile.d, and more)

[mikeslr]

I'm well aware of the problem. No 64bit Puppy binary compatible to a debian or ubuntu has ever been published with handles mult-architecture the same way as it's 'parent'. The

That's wrong: Vanilla Dpup (https://vanilla-dpup.github.io/) and Vanilla Upup (viewtopic.php?t=5290) use the same directory layout as Debian, and 32-bit libraries coexist nicely. You can safely apt install steam with all its 32-bit dependencies, and it works just fine.

Sorry, dimkr. Even as I wrote what you quoted I thought it might be wrong. But I couldn't remember which Puppy had managed it. I know 'DebianDogs' handle multi-architecture the same way that debian, itself, does. Somewhere back on the 'murgha-forum' fredx181 provided the instructions using apt to create the multi-architecture structure in a 64-bit system that would enable use 32-bit application. Having the memory of sieve, I made this note:

dpkg --add-architecture i386 && apt-get update
apt-get install wine-stable wine32

Skip the second line and portable-wine could be registered and used.

I suspect that you've woofed Vanilla Dpup and Upup to be closer to debian structure than previous Puppys.

There is now really little reason to provide multi-architecture other than to run wine in order to run 32-bit window programs: certainly not to run 32-bit Linux applications. By now there are 64-bit applications as good, sometimes better than 'old' XP programs. I have only one, InfoCentral, for which there are no comparable Linux applications. And using portable-wine is a preference: I could use a Wine.AppImage which provides it own 32-bit libraries.

I am left with two questions, one of which is mostly academic: except to suggest that there's a reason to hang on to version 5, why did the 32-bit compatibility SFS work thru version 5?

The other is whether Void, and consequently Voidpup64, has a command such as debian's "dpkg --add-architecture i386 && apt-get update"? My next experiment.

Edit: Well, as far as I can tell, Void doesn't provide a means to run 32-bit applications on a 64-bit system. Neither https://voidlinux.org/packages/ set to x86_64 nor pkgs.org suggest any relevant application.

[rockedge]

as far as I can tell, Void doesn't provide a means to run 32-bit applications on a 64-bit system.

Install multilib repository first in a terminal with: xbps-install void-repo-multilib
get a list of missing libraries the program you have, install missing libraries (eg. SDL2-32bit)
take a look into shlibs to get package name if you can't find desired library.

Also ldd <command> should show you what libs it needs. Lower case LDD.

The package can be installed in VoidPup using the provided package manager wrapper as well.

Install the 32 bit applications once the multilib is available.

Another big help is https://voidlinux.org/packages/ and select i686 to search the 32 bit libraries and applications.

[peebee]

I am left with two questions, one of which is mostly academic: except to suggest that there's a reason to hang on to version 5, why did the 32-bit compatibility SFS work thru version 5?

I would imagine this change to sfs_load:
https://github.com/puppylinux-woof-CE/w ... 270e809b39

[mikeslr]

Thanks, peebee for tracking down the change. It appears that rizalmart has opted to implement in Puppy an arbitrary change made in debian which debian users themselves question. https://groups.google.com/g/linux.debia ... 6O8S2Zf3TU.

There appears to be no discussion about it in Void threads.

If you follow the links from that thread you'll find that no one suggested the existence of a real problem --an unidentified 'mess' was alluded to-- beyond that if the status quo was continued users would have to configure the applications they use. https://lists.debian.org/debian-ctte/20 ... 00031.html

What happened to the adage "If it ain't broke, don't fix it"? Why has Puppy, which takes a radical approach to providing operating systems, jumped on the bandwagon in this case?

At any rate, if I read the above posts correctly, a 32-bit compatibility SFS may still be possible. But all bins must be located in /usr/bin and all libraries located in /usr/lib. Not sure what to do with any files that may currently be in /etc. Tomorrow I'd re-read the discussion and do some experimenting.

[dimkr]

What happened to the adage "If it ain't broke, don't fix it"? Why has Puppy, which takes a radical approach to providing operating systems, jumped on the bandwagon in this case?

The world around Puppy has changed and Puppy needs to change to make things like package managers of other distros work, and work safely. The cost is breaking some old .pet and SFS packages.

[rockedge]

Those "older" SFS packages could be uncompressed then modified in most cases with some added symlinks then squashed again to meet the current system file structure.

We did this for KLV-Airedale with some Puppy Linux SFS packages. Each one we modified worked then on Puppy AND most worked on KLV and were interchangeable.

One of the main features of Puppy Linux that remains a constant is the ability to think out of the "box".