Puppy Linux Discussion Forum

9899519f68af9eeb5a4bc4ec373070d6 VoidPup32-22.02+8.iso

4b8219fbb5f70119baefe7e855db75b4 VoidPup64-22.02+8a.iso

see viewtopic.php?t=5270

This latest version is working good for me so far. I really like how many apps come out of the box, something i also like about fossapup. I also appreciate how many themes come pre installed, "Dark_Blue" theme is my favorite so far. Thank you for this!

Something I am wanting is a GUI version of vpm. I want to see if anyone has already made a xbps GUI though since that could also work. Do you know if anyone is working on such a thing for vpm? I don't know if i will have the time to work on such a project but if i do I think I would not want to duplicate efforts if someone else is already working on it.

artemis wrote: ↑Fri Aug 05, 2022 3:36 am

Something I am wanting is a GUI version of vpm.

There is octoxbps
but it will pull in Qt5.........
so is BIG

https://voidlinux.org/packages/?arch=x86_64&q=octoxbps
https://voidlinux.pkgs.org/current/void ... .xbps.html

thanks! that'll do just fine for me right now. i use other qt5 stuff anyway so its a price im already paying

Rebuild:
4b8219fbb5f70119baefe7e855db75b4 VoidPup64-22.02+8a.iso

fixes sfs_load

5c785ba6e083ec456a5732c83a883d17 VoidPup32-22.02+9.iso

f72a9f4b7e60ba8433230626f49692a4 VoidPup64-22.02+9.iso

see https://forum.puppylinux.com/viewtopic.php?t=5270

artemis wrote: ↑Fri Aug 05, 2022 3:36 am

Something I am wanting is a GUI version of vpm.

I have very simple GUI? which opens from the Setup menu. It simply opens a terminal and leads the user through installing a package (see attached image).

To save space in my save file I have created a repo on my harddrive and linked it to /var/cache/xbps

As mentioned earlier in this thread, this work is based on the original work of Duprate. Duprate modified the 32-bit compatibility SFS available for Fossapup64 and produced an application for Voidpup64 which included 32-bit wine. I, however, primarily use portable-wine, so I stripped wine from his application. Later, with the implementation of the usr-merge concept, I had to restructure the the SFS. The result was that I had scattered on my hard-drive a bunch of 32-bit compatibility SFSes identified as pertaining to Voidpup64.

Mike Walsh and I are working on a new implementation of portable-wine. And peebee has continued to upgrade Voidpup64, the latest as of this writing being VoidPup64-22.02+9. In trying to find out if a new version of portable-wine was functional under 'VoidPup64' I discovered the confusion which resulted from having many versions of a compatibility SFS.

While it would certainly be preferable to have a 'Void64-native' 32-bit compatibility SFS or even more so a 'Void64-native' method of running 32-bit applications, until that happens there should be a way for those who want to to run 32-bit applications under VoidPup64. And to do so without having to individually repeat the time and effort Duprate and I have expended.

I've uploaded THE version of a 32-bit compatibility SFS to mediafire which functioned under all iterations of VoidPup64 I tested: from +0 thru +9. Anyone who wants it can obtain it here, https://www.mediafire.com/file/9mc351ks ... 4.sfs/file.

mikeslr wrote: ↑Wed Aug 31, 2022 4:33 pm

Mike Walsh and I are working on a new implementation of portable-wine. And peebee has continued to upgrade Voidpup64, the latest as of this writing being VoidPup64-22.02+9. In trying to find out if a new version of portable-wine was functional under 'VoidPup64' I discovered the confusion which resulted from having many versions of a compatibility SFS.

I've never had any luck using wine with SFS compatibile layers, probably due to lack of understanding on my part. I have been using:
https://github.com/Hackerl/Wine_Appimag ... h.AppImage
with VoidPup64, ScPup64, and others. There are other wine appimages on this page, but I like this one best.

I extracted it with Uextract, changed "AppRun" to "wine" and linked it to /usr/bin to make it into a portable app. It only runs 32bit windows programs, but that's all I use anyway.

mikeslr wrote: ↑Wed Aug 31, 2022 4:33 pm

While it would certainly be preferable to have a 'Void64-native' 32-bit compatibility SFS or even more so a 'Void64-native' method of running 32-bit applications, until that happens there should be a way for those who want to to run 32-bit applications under VoidPup64. And to do so without having to individually repeat the time and effort Duprate and I have expended.

Are the answers provided in the links below regarding WINE prefixes useful?

https://unix.stackexchange.com/question ... void-linux

https://linuxconfig.org/using-wine-prefixes

Thanks, wiak,

It seems too easy. Version2013 publishes 64-bit wine pets which --I've never used any-- should run in a 64-bit Linux OS. Per the links from your post, creating a 32-bit wine prefix should be as easy as just running the command:

$ WINEPREFIX=~/.new32prefix WINEARCH="win32" winecfg

Perhaps gets a little more --or way more-- complicated if wine-portable is the objective. Shinobar and the Japanese Team never created a 64-bit Wine-portable. Indeed, their last publication was, IIRC, 32-bit Wine-portable 1.7.8 +/- about 8 years ago. It is structured as follows: Within the portable folder is a wine_1.7.8.sfs together with three bash-scripts: Register, Wine-portable, and AppRun. [Guessing from the last, Wine-portable is essentially a Rox-App, which is run from outside of 'Puppy-Space']. Register merely writes (copies?) pixmaps and desktop files to their usual places, and a bash-script (wine.sh) in /usr/bin. The coding of Wine-portable and/or AppRun and/or wine.sh mounts the wine_1.7.8.sfs and redirects the creation and use of the wine-prefix [from its usual place in /root/.wine or elsewhere in 'Puppy-Space'] to the external Wine-portable folder. ['Puppy-Space' is folders in RAM under Puppy's control and, after the creation of a SaveFile/Folder, its contents].

The coding used in AppRun and wine.sh are 'above my pay-grade'. Consequently, my publication of later versions of Wine-portable [and AFAIK, anyone else's] has merely been to use the AppRun, wine-portable wine.sh and Register scripts from wine-portable 1.7.8 while rebuilding a newer wine.sfs by replacing the contents of the wine_1.7.8.sfs with files from one of Version2013's newer wine pet, making certain to include /usr/bin/wine.sh. [Gets a little more complicated with what used to be just one /usr/lib folder to multiple and uniquely named /lib folders].

What's the structure of the contents of a wine64-bit pet? And can Register, AppRun, wine-portable and wine.sh support it? or will any of those scripts have to be modified, and how? Well, even with my technical limitation, I can explore the first two questions.

And here I thought I was finished with exploring wine-portable for a while. But like you and Michael Corleone 'Just when I thought I was out... they pull me back in.'

Edit: Well, I'm out again. https://www.forum.puppylinux.com/viewto ... 004#p66004

Am running VoidPup64-22.02|+9, frugal(from Delta).Am having problems getting several apps to download from the xbps directory.
I choose the uppermost directory(and the largest), from the 3 available. Even tried the update cmd. Please see the ss for a partial
example of this. Also, tried on-line searches for those 2 missing files:libicui18n.so.71, and libicuuc.so.71, to no avail.

@tosim

See:
/root/Startup/00_start_vpup

Looks like your installs want to update icu and that has been blocked by the above holds.....

You could try removing the holds (e.g xbps-pkgdb -m unhold icu ) but do this in a safe test environment in case of "consequences"

https://docs.voidlinux.org/xbps/advance ... g-packages

@peebee Thanks for the quick reply. Will give it a shot today.
Update: Tried it, did not work. SS is of /root/startup/00_start_vpup (as opened in Geany):
Could I delete the 3 lines:
xbps-pkgdb -m hold glibc
xbps-pkgdb -m hold icu
xbps-pkgdb -m hold icu-libs

There is some indication that Void Linux is preparing to move from glibc-2.32 to glibc-2.36..........

https://github.com/void-linux/void-pack ... n%3Atitle+

mikeslr wrote: ↑Fri Sep 02, 2022 1:01 pm

Thanks, wiak,

It seems too easy. Version2013 publishes 64-bit wine pets which --I've never used any-- should run in a 64-bit Linux OS. Per the links from your post, creating a 32-bit wine prefix should be as easy as just running the command:

$ WINEPREFIX=~/.new32prefix WINEARCH="win32" winecfg

Perhaps gets a little more --or way more-- complicated if wine-portable is the objective. Shinobar and the Japanese Team never created a 64-bit Wine-portable. Indeed, their last publication was, IIRC, 32-bit Wine-portable 1.7.8 +/- about 8 years ago. It is structured as follows: Within the portable folder is a wine_1.7.8.sfs together with three bash-scripts: Register, Wine-portable, and AppRun. [Guessing from the last, Wine-portable is essentially a Rox-App, which is run from outside of 'Puppy-Space']. Register merely writes (copies?) pixmaps and desktop files to their usual places, and a bash-script (wine.sh) in /usr/bin. The coding of Wine-portable and/or AppRun and/or wine.sh mounts the wine_1.7.8.sfs and redirects the creation and use of the wine-prefix [from its usual place in /root/.wine or elsewhere in 'Puppy-Space'] to the external Wine-portable folder. ['Puppy-Space' is folders in RAM under Puppy's control and, after the creation of a SaveFile/Folder, its contents].

The coding used in AppRun and wine.sh are 'above my pay-grade'. Consequently, my publication of later versions of Wine-portable [and AFAIK, anyone else's] has merely been to use the AppRun, wine-portable wine.sh and Register scripts from wine-portable 1.7.8 while rebuilding a newer wine.sfs by replacing the contents of the wine_1.7.8.sfs with files from one of Version2013's newer wine pet, making certain to include /usr/bin/wine.sh. [Gets a little more complicated with what used to be just one /usr/lib folder to multiple and uniquely named /lib folders].

What's the structure of the contents of a wine64-bit pet? And can Register, AppRun, wine-portable and wine.sh support it? or will any of those scripts have to be modified, and how? Well, even with my technical limitation, I can explore the first two questions.

And here I thought I was finished with exploring wine-portable for a while. But like you and Michael Corleone 'Just when I thought I was out... they pull me back in.'

Edit: Well, I'm out again. https://www.forum.puppylinux.com/viewto ... 004#p66004

Not trying to force you back in, but noticed something earlier in this thread whilst looking for something else. To be honest, I'm still too busy looking for the something else so haven't even really read the following information from Duprate, but at a glance it did look related, but I don't know if relevant: https://forum.puppylinux.com/viewtopic. ... 283#p48283

https://forum.puppylinux.com/viewtopic. ... 613#p48613

Hi wiak,

Your post reminded me that it really would be useful if someone created the mechanism used on Michael Keaton in Multiplicity, https://www.imdb.com/video/vi1251672345 ... _=tt_ov_vi. On second thought, maybe not.

I explore to keep my mind active. And post about it with the thought that by doing so even newbies --who have an interest beyond depending on others-- may learn safe techniques and avoid the 'rabbit holes' I frequently find myself in.

jrb has published a technique for using a Wine AppImage. https://www.forum.puppylinux.com/viewto ... 865#p65865. It uses the 3.3 version of Wine. Anyone interested in a newer (5) version of Wine, might want to wait a couple of days. MikeWalsh is at the final testing stages of an application employing an AppImage but automatically portablizing it. Both of the above avoid the need to make use of a 32-bit compatibility SFS, so can be used with any 64bit Puppy..
I consider MikeWalsh's system so good that I have delayed publishing my own wine-portable built using Version2013's 7.12 wine pet and the mechanism and technique developed by shinobar and the Japanese Team. When I do publish, the post will open with a recommendation that MikeWalsh's portable be preferred under 64bit Puppys and mine be considered for 32bit Puppys where there is no need to use and configure a 32bit compatibility SFS.
The primary reason I have for publishing is to support a post detailing how to create a 'version2013-Shinobar' portable using any of version2013's pets. My previous post explaining how to do so on the 'Murgha-Forum' became truncated into uselessness during the transfer to a different server or archiving procedures.

This is honestly one of the best Puppies around at the moment. The compatibility with Void is really good, the filesize is very reasonable and the included apps are nice. Plus the choice of LXDE and XFCE as usual for peebee's pups is phenomenal.

Is there any possibility of this one also making it to the Puppy frontpage? I feel it's a bit tucked away, and with how solid it is, that's almost criminal.

@peebee , Very preliminary test of your 6.0 kernel build with aufs. Just swapped it into my savefile based VoidPup64 (ydrv LXDE, synaptics touchpad drivers, portable browsers etc.), cleaning the usual kernel related files first. Clean boot, clean dmesg, created a test folder and rebooted. Changes saved and recognized. So far so good, more when I have time. It's my daily. Oh ya, the time honored Fujitsu S761 hardware, 2nd gen i5 based, all intel, circa 2012, and rock solid, all 6 of them!

Thanks again,

I've run into an issue compiling programs with VoidPup64. Some get errors like this:

/usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/10.2.1/../../../../lib64/libpthread.a(pthread_create.o): relocation R_X86_64_32S against `.data' can not be used when making a PIE object; recompile with -fPIE

I had similar warnings on VoidPup32 when linking with libm but IIRC compiling this particular program (K8Vavoom) did work fine there. Never had any issues compiling any of these with any other puppy or distro like Lubuntu.

EDIT: Looked it up and thought it was due to PIE being on by default, but disabling them just gives another error:

/usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/10.2.1/../../../../lib64/libpthread.a(elision-lock.o): in function `_dl_tunable_set_elision_enable':
(.text+0x102): undefined reference to `_dl_x86_cpu_features'

This one looks more like an actual Void/VoidPup issue but I'm not really sure anymore.

EDIT2:

/usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/10.2.1/../../../../lib64/libSDL.a(SDL_x11mouse.o): undefined reference to symbol 'XGetPointerControl'
/usr/bin/ld: /usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line

Some more. It's almost impossible to compile more than really basic programs, haven't had much success.

@TDRR
Difficult to know what to advise....
The devx has definitely not had the same level of testing however it does manage to compile the petbuilds used in VoidPup64 building:
PETBUILDS="busybox-void aaa_pup_c gtkdialog jwm puppy_flat_icons puppy_standard_icons gtk_theme_flat_grey_rounded gtk_theme_gradient_grey gtk_theme_polished_blue xdg-puppy-jwm fixmenusd firewallstatus"

There may be some missing libs or even libs or components in "wrong" locations......... I'll fire it up and run "checkdeps -system" with the devx loaded to see if that gives any clues.

You may be treading new ground....

@TDRR

https://voidlinux.pkgs.org/current/void ... .xbps.html

is missing - its BIG 13MB - no idea if its your problem.... xbps-install -Su libgo

VoidPup64-22.02
Start: Sat Oct 8 09:57:18 +08 2022
* Checking system dirs: /lib /usr/lib /usr/local/lib

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2/buildid
libgo.so.16 => not found

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2/cgo
libgo.so.16 => not found

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2/test2json
libgo.so.16 => not found

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2/vet
libgo.so.16 => not found

FWIW --as I know nothing about compiling-- https://pkgs.org/search/?q=libgo.so.16 reveals a separate libgo.so.16 package for 32-bit systems, none specifically for 86_64, but only packages for cross-compiling on other systems. This one of those for powerpc's included a libgo.so.16 file https://voidlinux.pkgs.org/current/void ... .xbps.html

Thanks for the advice @peebee, unfortunately there's no readily apparent difference with it installed. Identical errors to before on all the same programs. I can only imagine it being something with how some of the built in libraries are compiled, but I don't really know enough to say for sure.

EDIT: Is vpm upgrade intended to work by the way? I know it kinda goes against Puppy principles because you basically install updates for a few packages that add up to be bigger than the Puppy itself but still it's a nice-to-have for when it's installed as the main OS. I get a segfault on the unpacking stage:
[*] Unpacking packages
bash-5.1.016_1: updating to 5.1.016_2 ...
bash-5.1.016_2: unpacking ...
bash-5.1.016_2: unpacked file `./usr/bin/rbash' (0 bytes)
bash-5.1.016_2: unregistered 'state' alternatives group
/usr/bin/vpm: line 297: 5702 Segmentation fault xbps-install -Suv
[vpm] [xbps-install -Suv] return code: 139

I think the devx fix is more important though so unless it's a trivial fix it'd be nice to get that sorted out first :p

Hello peebee and TDRR,
Just wanted to mention that I also have experienced strange errors when trying to compile from source
This was with 32bit Void Pup and it was some time ago now (compiling the same package in other Pups would work OK)
I didn't mention it at the time because I had hoped to figure out at least some clues as to the cause before doing so.
But I set it aside and haven't looked at Void Pup for a while.
It didn't seem to be happening with the very early releases, but cropped up somewhere along the line
Now I need to upgrade to latest and test again when I get some time, but interesting that TDRR has reported something similar

EDIT:-
Upgraded VoidPup32 to 22.02+10
As a test I tried compiling dosbox-74-3 (picked something at random)
At the end of the "make" sequence the error looks like this:-

/usr/bin/ld: /usr/lib32/gcc/i686-pc-linux-gnu/10.2.1/../../../libSDL.a(SDL_x11gl.o): undefined reference to symbol 'dlclose@@GLIBC_2.0'
/usr/bin/ld: /lib/libdl.so.2: error adding symbols: DSO missing from command line

So similar sort of thing, relating to ld and problems with symbols (will vary depending on the package being compiled I think)
Maybe someone can figure out where the problem is coming from (some sort of mismatch with glibc ?? )

The problem could be a missing libSDL-1.2.so.0 or libSDL2-2.0.so.0. The build fails because it tries to link against libSDL.a (a static library) and it's impossible, because SDL uses dynamic loading functions from libdl (dlopen(), etc') and must be linked dynamically.

Yes, thanks dimkr, I have tested a bit more. The package SDL-devel is in the devx but I don't see the run-time SDL package in the main .iso
So vpm install SDL

The dosbox package also has the optional dependencies SDL_sound and SDL_net so I used vpm to install both of those, plus of course SDL_sound-devel and SDL_net-devel

The configure script was still not detecting those optionals though
I had to vpm forceinstall SDL-devel
Then configure looks all OK - nothing gets disabled

BUT there was then a new "make" error because it was trying to link the static version of the libm library.

So I created a symlink named libm.so in /usr/lib which is a symlink to the real libm shared library in the /lib directory.
That seems to fix it. The build completes without errors now.
I think the libm library is used quite a lot so if the DEV symlink configuration of it is not correct, that will cause problems in lots of compiling cases.
Other additional symlinks may be needed to some of the other shared glibc libraries, The libpthread being an example, that seems to be the cause of one of the errors posted by TDRR above.

Hi @OscarTalks

Could you try VoidPup32 +10a & devx from:
https://smokey01.com/peebee/downloads/test/

Thanks
PeeBee

peebee wrote: ↑Mon Oct 10, 2022 3:09 pm

Could you try VoidPup32 +10a & devx

The +10a version is much better
Compiling dosbox, the dependency on SDL is all OK
I can add the optional SDL extras or leave them out and it builds correctly either way (enables or disables accordingly)

Some errors still remain though (with other packages)
Because it does also need you to create /usr/lib/libpthread.so which is a symlink to /lib/libpthread.so.0
(which in fact is already a symlink to /lib/libpthread-2.32.so)

That fixes an error I saw when test compiling clucene-2.3.3.4 which uses CMake (see below).
I think it will also fix one of the errors that TDRR reported when there was an attempt to link libpthread.a which fails because it is the static version of the library.

CMake Error at /usr/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.24/Modules/FindThreads.cmake:230 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  src/shared/CMakeLists.txt:38 (find_package)


-- Configuring incomplete, errors occurred!

peebee wrote: ↑Sat Oct 08, 2022 6:10 am

There may be some missing libs or even libs or components in "wrong" locations.....

Looking into it a bit more and comparing with some other Puppies
I reckon there should be a cluster of DEV lib symlinks in /usr/lib (around 16 of them in total)
Which correspond to most of the shared libs in /lib
I would expect them to be in the package glibc-devel
(EDIT - but it looks like they are in the main glibc instead)
But they seem to be missing from Void Pup
(I would expect them only to be present when devx is loaded of course)

Is it possible that they are in the glibc-devel void linux package,
But are getting lost in the WoofCE build process,
Maybe because they are symlinks to other symlinks, or because there is a problem with what goes into main puppy.sfs and what goes into devx?

Examples:-
/usr/lib/libanl.so link to /lib/libanl.so.1
/usr/lib/libBrokenLocale.so link to /lib/libBrokenLocale.so.1
/usr/lib/libcrypt.so link to /lib/libcrypt.so.1
/usr/lib/libdl.so link to /lib/libdl.so.2
/usr/lib/libm.so link to /lib/libm.so.6
/usr/lib/libnsl.so link to /lib/libnsl.so.1 (maybe not this one?)
/usr/lib/libnss_compat.so link to /lib/libnss_compat.so.2
/usr/lib/libnss_db.so link to /lib/libnss_db.so.2
/usr/lib/libnss_dns.so link to /lib/libnss_dns.so.2
/usr/lib/libnss_files.so link to /lib/libnss_files.so.2
/usr/lib/libnss_hesiod.so link to /lib/libnss_hesiod.so.2
/usr/lib/libpthread.so link to /lib/libpthread.so.0
/usr/lib/libresolv.so link to /lib/libresolv.so.2
/usr/lib/librt.so link to /lib/librt.so.1
/usr/lib/libthread_db.so link to /lib/libthread_db.so.1 (maybe not this one?)
/usr/lib/libutil.so link to /lib/libutil.so.1