VoidPup32 and VoidPup64 Discussion

[mikeslr]

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....
One of the main features of Puppy Linux that remains a constant is the ability to think out of the "box".

Tried that with the 32bit compatibility sfs which works under version 5 using two methods:
(a) move everything to /usr/lib;
(b) move /lib to /usr/lib and /usr/lib to /usr/local/lib.
The good news: the modified SFSes can be loaded.
The bad news: the modified SFSes aren't functional.
I suspect a successful implementation of the project may be possible if undertaken by someone whose skill level is greater than a 6 year old playing with blocks.
"It took some effort to get apt and 32-bit packages to work in a Debian-based Puppy, but it's possible" dimkr @ https://www.forum.puppylinux.com/viewto ... 208#p60208

[rockedge]

@mikeslr I understand. Good start it sounds like. Which SFS package(s) from the series 5 era are the ones in question?

I might take a swing at it to see what can be done once I have a couple of examples to test against the modified 32 bit compat lib.

[mikeslr]

Unfortunately, I've haven't been able to locate the post from which I obtained the SFS. The closest I've come is the discussion beginning here, https://www.forum.puppylinux.com/viewto ... 242#p48242
thru here, https://www.forum.puppylinux.com/viewto ... 283#p48283. The first link is to peebee's reply. I think it provides important information I forgot during my explorations.

At any rate, Duprate used an unidentified modification of 32bit-compatibility-fossapup64.sfs. You could start with that. But if you need it I can upload the SFS which ran under VoidPup64 version 2-thru-5 to mediafire.

I've got to break for lunch now. Blood-sugar is low and I'm getting fuzzy headed.

[rockedge]

Yes please upload what pieces of the puzzle I'll need to get started! Will start with 32bit-compatibility-fossapup64.sfs and the latest VoidPup64

[mikeslr]

Better still (for me anyway ). It occurred to me to read further after the section I noted. Duprate did provide the 32bit_compatibility_VoidPup64 package. It's still available here. https://drive.google.com/drive/folders/ ... z3zQq_m0oJ
GoogleDrive objects to palemoon and to blocking 3rd party cookies. I downloaded it again using Iron with 3rd party cookies permitted.
Although its packaged as a tar.gz, UExtract immediately produces an SFS.

Also available on Duprate's google-drive is his package of 32bit compatibility and wine 3.3 as a rox app. As I already had wine-portable 3.3, I didn't use it. But now I'll examine it just in case it can be avoid the now usrmerge problem.

FWIW, I just tried to load my Xenial32-with-builtin-wine-chroot.sfs. Told it has the wrong 'file-structure' despite that the only files outside of /home are those in /usr/bin and /usr/share/desktop.
Sorry, accidentally SFS-Loaded the 'core' sfs rather than the completed Chroot-SFS. Wine runs fine from the Chroot. But maintenance --adding programs, changing program settings, saving new info-- would be a PITA.

Of course, the simplest solution is to divest the Emperor of his new clothes and re-vert to what worked without a hitch before.
@ dimkr: "Everyone else is doing it" is the mind-set of lemmings; and the propaganda of tyrants from petty bureaucrats to God-Emperors with Orthodox Priesthoods in between.

[dimkr]

Of course, the simplest solution is to divest the Emperor of his new clothes and re-vert to what worked without a hitch before.
@ dimkr: "Everyone else is doing it" is the mind-set of lemmings; and the propaganda of tyrants from petty bureaucrats to God-Emperors with Orthodox Priesthoods in between.

Believe it or not, Puppy is not the center of the technology world. You can close your eyes and turn away as other distros change, but don't be surprised when you run into incompatibilities and Puppy-specific issues. Some things obey the "if it's been x for a very long time, !x is super unlikely to happen" rule ("if winter is always colder than summer, the next summer is unlikely to be colder than winter") while other things obey the "if it's been x for a very long time, !x more likely to happen" ("if I never had age-related disease, I'm more likely than ever to have it now"). You think that avoiding change will keep Puppy stable, while in reality, Puppy has ignored the directory layout changes in other distros for at least 7 years (if I'm not mistaken), the migration to GTK+ 3, PulseAudio (or PipeWire) and many other things, and it's starting to hit a wall in multiple fronts.

If you ask me, I think the "let's keep doing the same thing forever and ignore the rest of the world" is an unhealthy mindset and I don't understand why you propose this with such optimism: without some change, Puppy will always be in a slightly broken state where some things that work on other distros are broken ,and users don't know what to expect when they try to install an application on Puppy. Software compatibility is a real thing, and a real problem when you don't have it or choose not to have it.

[wiak]

Puppy has ignored the directory layout changes in other distros for at least 7 years (if I'm not mistaken), the migration to GTK+ 3, PulseAudio (or PipeWire) and many other things, and it's starting to hit a wall in multiple fronts.

I have to agree with this. Puppy can keep being a very useful and very efficient and impressively small Linux distro, but only if it adapts in structural ways as upstream Linux developments/decisions decide - that adaption does not decrease Puppy's unique individuality (I suppose the adoption of upstream repo packages did, but that is history anyway and using official package managers does not weaken ability to use upstream repo packages; rather it makes it more reliable).
If Puppy is to survive as a go-to distro then such adaptation needs happen or the 'wall' otherwise created basically spoils any successful broth.
That's not to say that the likes of sc0ttman's pkg or PPM could not still be used as alternatives - they could, but I wonder if that kind of alternative-to-apt (and so on) effort is even sensible; was a different matter altogether in earlier days when Puppy had its own repos; thereafter PPM has been a kind of stubborn, unsatisfactory, fudge IMO.
Not adapting distro hierarchy when upstream repo distros have somewhat begun to standardise that much has been a painful disaster with Puppy at times though (and a real waste of dev time trying to find workarounds) - and so easy to simply adapt and fix and make the hierarchy at least compatible with what the packages expect!

[amethyst]

Why did they change the filesystem structure, has it been beneficial in terms of performance? I mean, if /usr/bin was used before and it's now /usr/local/bin

[dimkr]

Why did they change the file structure, has it been beneficial in terms of performance?

The / vs. /usr separation is an ancient memory of days when the OS consisted of multiple block devices (i.e. /usr is a second floppy). Merging /bin with /usr/bin, /lib with /usr/lib, etc', solves some problems. For example:
1) Distros disagree with each other about what goes to /bin and what doesn't; when /bin is a symlink /usr/bin, either /bin/x and /usr/bin/x work, making different distros that adopt this directory layout more compatible with each other
2) The shared library loader has less directories to look at when it tries to load the libraries needed by an executable, which can speed up application start times
3) Tools that scan / recursively, like snapmergepuppy, have less directories to look at

Debian's decision to put libraries under /usr/lib/x86_64-linux-gnu instead of /usr/lib64 serves a different purpose: it allows one to install libraries for multiple architectures on the same system. This allows one to install 32-bit libraries on a 64-bit x86 OS, to run old binaries, or install ARM libraries that can be used to cross-compile applications.

(And the purpose of /usr/local hasn't changed.)

[amethyst]

Debian's decision to put libraries under /usr/lib/x86_64-linux-gnu instead of /usr/lib64 serves a different purpose: it allows one to install libraries for multiple architectures on the same system. This allows one to install 32-bit libraries on a 64-bit x86 OS, to run old binaries, or install ARM libraries that can be used to cross-compile applications

.
That makes sense, yes.

[mikeslr]

Thanks, dimkr, for your explanation for the implementation of usr-merge here. https://www.forum.puppylinux.com/viewto ... 335#p60335. It's what I hadn't found when searching for it on the web. As amethyst wrote, it makes sense.

My concern was about the loss of flexibility by some arbitrary decision. I withdraw my objection. Going forward new pets and SFSes can be constructed to comply with its requirement just as easily (perhaps more easily) than without it. From experience, it's becoming increasingly rare that old pets and sfses could be used OOTB even before that change. So little is lost. The problem I encountered with the void64 32bit_compatibility SFS may only have been the chance occurrence of an outlier rather than 'the tip of an iceberg'.

Just a couple of questions: Do you know whether Slackware has also implemented this change? And does your response to grey's question here, https://www.forum.puppylinux.com/viewto ... 213#p60213 indicate that it's a Devs choice when woofing a Puppy to implement it or not?
My understanding is that the version(s) of woof used to create Slackos is different than that/those to create debian/ubuntus. But if that understanding is mistaken, usr-merge has been baked into all woofs and Slackware hasn't adopted the change, compliance with Slackware standards by Devs building Slackos has been made difficult to impossible.

[dimkr]

Just a couple of questions: Do you know whether Slackware has also implemented this change? And does your response to grey's question here, https://www.forum.puppylinux.com/viewto ... 213#p60213 indicate that it's a Devs choice when woofing a Puppy to implement it or not?
My understanding is that the version(s) of woof used to create Slackos is different than that/those to create debian/ubuntus.

AFAIK Slackware hasn't changed to symlinks, and USR_SYMLINKS is indeed configurable. It's off by default (so Slacko and any other Puppy that hasn't opted in is unaffected) and if you build a Debian or Ubuntu-based Puppy with USR_SYMLINKS=no, (unsurprisingly) some .deb packages don't work and apt has issues.

[mikeslr]

Dev's Choice. Great. I'm a happy camper. Or will be once implementation of multi-architecture under Void64 has been resolved.

[mikeslr]

Void64-WineStaging.AppImage-PhotoScape.png (57.62 KiB) Viewed 3518 times

Just an update on the status of wine. Currently I can run programs under wine employing an AppImage more fully explained here. https://www.forum.puppylinux.com/viewto ... 430#p60430
This screenshot shows MikeWalsh's photoscape-portable running under VoidPup64 using the setup recipe MikeWalsh devised for Wine AppImages.

I'll reasonably sure that to otherwise use 32-bit Windows programs will require installing "xbps-install void-repo-multilib" per rockedge here, https://www.forum.puppylinux.com/viewto ... 230#p60230 and modifying the 32bit-compatibility SFS from a Puppy such as Fossapup64 so that its libraries comply with the usr-merge limitation; or installing a bunch of 32-bit files, some of which may not be in Void's repo.

Or avoid it. I'm used to locating 'uniquely' Puppy binaries in /root/my-applications/bin. While doing that I noticed that there was also a /usr/my-applications/lib; but never made use of that structure before. Figuring that debian devs hadn't built in a test for libs there, I relocated some of the libs from Duprates modified fossapup-32bit-compatibility package there and was NOT confronted by an objection.

While examining Duprate's package I noticed what appeared to be a lot of duplication of files between /lib and /usr/lib. What to keep? And where?
There's only one program I really use often and employing a Wine AppImage + MikeWalsh's instructions enables that. TBO, I'm kind of tired of trying to otherwise solve the problem.

[rockedge]

@mikeslr You are using /root/my-applications/bin and /root/my-applications/lib just as they were designed.

I also use this area to work on and experiment with packages sometimes foreign to the OS. I also will add the same directory structure to KLV borrowing from VoidPup64.

[TiredPup]

I have the 64 bit version installed to a usb drive plugged into my Dell Optiplex 760 USFF with 3.0ghz Intel Duo Core 2 processor and 4 gigs of ram. I have setup a portable browser, a couple of appimages and wine32 according to the directions I found in this thread. This is a fast OS that is reminiscent of older puppies.

I did run into a couple of issues:

1. CUPS was able to find my printer and installed the ppd file for my Canon Pixma MG 2500. However I cannot print a test page. I get an error message "stopped, filter failure".

2. I attempted to build links browser from source but get a configure error message for openssl not found.

Other than that all is remarkeably smooth so far.

[peebee]

2. I attempted to build links browser from source but get a configure error message for openssl not found.

https://voidlinux.org/packages/?arch=x86_64&q=links

[TiredPup]

Hi peebee,

Thank you for the response. Installing the links browser from the package manager is easy enough. For some reason I have always compiled links for my own use. It is not at all necessary to do that anymore though. Just habit. I am more interested in learning why ./configure could not find openssl.

Also I have a Canon MG2500 series printer connected directly via USB. Linux distros provide the driver for this printer. I have never seen the filter failure message with this one before. I do not use my printer very often but having it available is a must for the few things I do print so I will be searching the forums to see if I can work this one out.

Regards,
James

EDIT: It took a bit of ruminating before I finally remembered that this printer is subject to certain issues and requires the use of debian packages to be installed in additon to cups. User rcrsn51 had an extensive thread in the "printers" sub category of the "hardware" section of the old forum. He also provided an installation script called "candi" in the form of a *.pet package. I was able to dig up the candi package and the appropriate driver packages from canon (archived on an ftp site but no longer available from the canon support pages). I will make a post about this in the appropriate thread as this in not a voidpup issue.

[rockedge]

@TiredPup I too have a MG2500 and right now runs as an AirPrint capable printer through Tahr-6.0.5. But I am interested in your progress and the FTP archive URL with the Linux drivers.

[TiredPup]

I have started a thread for the Canon PIxma MG 2500 printer series in the "drivers" section of the "Advanced Topics" category viewtopic.php?t=6216

@rockedge

Much to my surprise I did find a direct download from the canon website for Asia at https://my.canon/en/support/0100550402. Grab it while you can.

Also I found the scanner drivers at the same site. Download here: https://asia.canon/en/support/0100551901

Do you need the candi.pet? It can be found on the Wayback Machine at https://web.archive.org/web/20150905062 ... hp?t=80051 in the first post on that page.

I made a separate post on this topic viewtopic.php?t=6216.

[ally]

I've mirrored these files at the drivers repo page on archive

https://archive.org/details/Puppy_Linux ... river_Repo

[TiredPup]

@ally

Thank you for archiving the files. When I followed the link I only found 2 of the 3 files listed in the archive. The 2 files present were candi-1.4.pet and scangearmp debian scanner package for the mg2500. The cnijfilter package for the 2500 is not there, although I did see the package for the mg3500 but not for the mg2500 which is the subject of the preceding posts.

I clicked on each of the links that I provided for the package downloads at the canon asia support site only to find that neither page is available. I see only a message saying "Sorry, This page is down for maintence".

I have made candi-1.4.pet, the cnijfilter and scangearmp packages for the canon pixma mg2500 printer on google drive.

https://drive.google.com/drive/folders/ ... sp=sharing

[rockedge]

I found the MG2500 printer driver cnijfilter-mg2500series-4.00-1-deb.tar.gz here: https://asia.canon/en/support/0100550201

or get it here -> cnijfilter-mg2500series-4.00-1-deb.tar.gz

[ally]

anyone posting file links, if you include the file name too (ie. cnijfilter-mg2500series-4.00-1-deb.tar.gz) it will make it easier to find the file on archive (they are indexed well by google) if the link goes bad and can be quickly found by selecting all files on the archive page then F3 or ctrl F to search for the file name

[TiredPup]

@rockedge
The links were down yesterday. I am glad to see that they are back up.

@ally
Thank you for pointing out the issue with spelling out complete file names.

[ally]

this one? https://archive.org/download/Puppy_Linu ... deb.tar.gz

[peebee]

978b8c6dd1a4a3fb4c90a043af0f6dbc VoidPup32-22.02+7.iso

267f25d4a5c01b213878d23592315070 VoidPup64-22.02+7.iso

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

Woof-CE & Void updates - packages:
BUILD_FROM_WOOF='testing;6004f18d0;2022-07-24 05:53:32 +0000'
jwm-2.4.2
:adwaita-icon-theme:
:alsa-lib:
:alsa-utils:
:ca-certificates:
:cdrtools:
:cifs-utils:
:cups-filters:
:curl:
:dialog:
:diffutils:
:dmidecode:
:file:
:font-util:
:gdb:
:git:
:glib:
:gnutls:
:gparted:
:gsettings-desktop-schemas:
:gtk+3:
:harfbuzz:
:iw:
:libarchive:
:libepoxy:
:libgbm:
:libglapi:
:libmagic:
:libunbound:
:libunistring:
:libxatracker:
:mesa:
:mozilla-nss:
:netpbm:
:nghttp2:
:openjpeg:
:openssl:
:pango:
:parted:
:poppler:
:Pup-SysInfo:
:python2:
:sqlite:
:sudo:
:wayland:
:xbps:
:xorg_base_new:
:xserver_xorg:

[TiredPup]

Downloaded. Posting with it now. Thank you.

[peebee]

@Clarity

Samba question posted elsewhere - see:
https://forum.puppylinux.com/viewtopic. ... 809#p47809

[Clarity]

Thanks @peebee, I missed that, somehow in the past.

So this all started from some developer's concern of the 20MB download and its dependencies as shown for a 64bit distro, in that post.

Thanks for your follow-up. Muchly appreciated