[CLOSED] VoidPup32 & VoidPup64 development thread

[peebee]

.
Constructed to experiment with the replacement of PPM with VPM (Void Package Manager)......... a "Woof-CE" Puppy build......

Thanks to @jamesbond & @wiak & @rockedge for assistance in getting to this stage.

VoidPup32 RC+0 with kernel-kit 5.4
cb62b0082c13ae7e0dad68cb4be661f7 VoidPup32-22.02RC+0.iso

+ delta to e70b1a122fb049ae3f67eaa0ea00ca0e VoidPup32-22.02RC+1.iso

32-bit devx & kernel_sources

VoidPup64 RC+0 with kernel-kit 5.15
d8459c10a6902e5a22ce1f02002069c1 VoidPup64-22.02RC+0.iso

+ delta to c0cba5914b24d94a8d6722c461410039 VoidPup64-22.02RC+1.iso

64-bit devx & kernel_sources

RC RELEASE

VoidPup Outstanding Issues 11-Feb-2022:

Release Candidate quality

Left out of Beta build config - see post #3:
Abiword, Gnumeric (& goffice), Sylpheed, MPlayer, XSane, Osmo, PSip,
Hexchat, Hiawatha, Homebank, Inkscapelite, Notecase, Transmission, Didiwiki
+ no games

Working (incomplete list):
JWM, LXDE, Roxfiler, Sound & pMusic, Wifi, Light webbrowser, TAS, PFind, pTheme, GParted, Cups, VPM + devx
+ Samba (after install)

also addon webbrowsers (32-bit): Chromium, Firefox, Palemoon, SeaMonkey (64-bit) Chrome, Chromium, Firefox, Palemoon

Issues to be aware of:
- Frisbee (double click the desired connection to make the "Connect" button activated)
.

Screenshot.png (116.53 KiB) Viewed 77506 times

.

Screenshot.png (116.71 KiB) Viewed 77506 times

[peebee]

32-bit LXDE by ydrv

64-bit LXDE by ydrv
.

Screenshot-lx.png (68.06 KiB) Viewed 78155 times

[peebee]

Installing apps to VoidPup

From Beta+2 use menu item "VoidPup Apps Install"

[wiak]

I've been experimenting with this, thanks peebee, and it's very interesting to use. As you say xbps (or via frontend vpm) doesn't start out knowing what is already there so reinstalls dependencies if you install anything new or previously installed. Of course in doing so the xbps database does gradually keep track of everything assuming everything gets re-installed, if you see what I mean. A remaster of main iso would be useful after doing such. Not the ideal way to get xbps database up to date I realize, but works fine anyway (even from scratch).

I'm having a lot of fun playing with this and feel that it has lots of potential and is somewhat ground-breaking.

I suspect a user could even install PAM and so on using vpm/xbps and have a true multiuser pup.

[rockedge]

I am really impressed and also think this is on to something big. One problem is I can not connect to the network with it!

Though VoidPup32 is "seeing" eth0 and eth1, it refuses to connect and says failure to negotiate. Possible firmware issue?

I need to check out the network problem more since alpha0 did connect right away and xbps was close to functioning but did not have the newer repo URL

[mikeslr]

"- VPM does not "know" what packages have been built-in"

Probably not the best way to solve this but:
IIRC, Void keeps track of 'installed' package in /var/SOMEPLACE. There should be some way of determining what packages are included 'via woof' in the creation of the base OS and writing files to /var/SOMEPLACE while 'woofing' or after but before finalizing.

[peebee]

"- VPM does not "know" what packages have been built-in"

Probably not the best way to solve this but:
IIRC, Void keeps track of 'installed' package in /var/SOMEPLACE. There should be some way of determining what packages are included 'via woof' in the creation of the base OS and writing files to /var/SOMEPLACE while 'woofing' or after but before finalizing.

yes indeed.......... an xml file needs to be created by using the build list to extract each package details from the void repo xml database - anybody an expert in xml manipulation???

[rockedge]

something using xmllint in BASH?

[wiak]

FatDog's @jamesbond seems to know what he is doing with that kind of thing.

[Clarity]

It is hoped that no one is upset with the findings I am posting.

This is a preliminary use in pristine boots and shutdown processing for my review of "ease of use" booting merely the downloaded container (aka 'ISO').

Reporting
I report successful booting of the ISO file directly in the following environments

• QEMU native ISO file booting in a BIOS Virtual PC on a LxPUPSC64 distro

• QEMU native ISO file booting in a UEFI Virtual PC on a LxPUPSC64 distro

• Native ISO file boot via a Ventoy USB stick on a 64bit BIOS PC

• Native ISO file boot via a SG2D USB stick on a 64bit BIOS PC

• Booting ISO file boot via the 'ease of use" USB sticks via QEMU

All work is accomplished directly via the ISO file boots.

Findings

• Boots are very fast and without issues

• Desktop navigations are without issues

• Desktop tailorings are without issues

• Attaching/detaching local-remote drives are without issues

• Save session(s) is saved to a local drive (in both VM and real PC) and on reboot, Void finds the saves via the ISO bootime parm "PSAVE="

• No issues to report from these preliminary tests in ALL of the environments reported, above.

Looking forward to the WoofCE 64bit version(s).

@Peebee, will this project land in forum's 'Index>Advanced Topics>Puppy Projects>WoofCE' area for discovery?
Or, in the 'Index>MAINLINE DISTRIBUTIONS>Mainline Puppy Linux Distros' area?

[mikeslr]

...

Left out of Alpha+2 build config:
PPM, Abiword, Gnumeric (& goffice), Sylpheed, MPlayer, Evince, Samba, XSane, Osmo,
Hexchat, Hiawatha, Homebank, Inkscapelite, Notecase, SQLite, Transmission, Didiwiki
+ no games

The ones I've crossed out aren't needed. Perhaps offer them as a 'Quickpet' or 'Get'.
PPM would only complicate management of installing/uninstalling applications. Gnumeric is a good app; but abiword can't be trusted for serious writing. As a result LIbreOffice/OpenOffice or other suites are used and gnumeric becomes superfluous except if you aren't using a Suite. Then some spreadsheet application might be needed. I've mentioned several alternatives to abiword on the forum. Ted isn't too bad.
Never used the others crossed-out. Those who use Inkscape would probably prefer the 'full version'. There are several alternatives to Notecase. Wiak uses CherryTree which can also serve as a substitute for Didiwiki. Frankly, I just keep notes written with geany or a word-processor in organized folders. When I forget where, pfind can locate the one I want quickly.
I do recommend Osmo as a PIM.
By the way, I've just downloaded Voidpup32 and will check it out.

[peebee]

"- VPM does not "know" what packages have been built-in"
There should be some way of determining what packages are included 'via woof' in the creation of the base OS and writing files to /var/SOMEPLACE while 'woofing' or after but before finalizing.

I have converted Woof-CE /status/findpkgs_FINAL_PKGS-void- into /var/db/xbps/pkgdb-0.38.plist as in WITHDRAWN ydrv........

however does not work - suspect there has to be a matching file in /var/db/xbps/keys/ but don't know how to create that - help??

Code: Select all

# vpm ls
[vpm]  Installed packages:  
ERROR: cannot access to pkgdb: Invalid argument
xbps-query: pkgdb.c:272: xbps_pkgdb_init: Assertion `xhp->pkgdb' failed.
/usr/bin/vpm: line 297: 10888 Aborted                 xbps-query -v -l
# 

[Keef]

Does this help?
https://docs.voidlinux.org/xbps/reposit ... gning.html

[mikeslr]

Hi peebee,

For an Alpha, it's really quite good. Most of how I manage Puppys worked. These are some notes of my first experiences.
In order to boot I had to include the pdrv=URL-Specific on linux line. Added psubdir= as a further precaution against 'can't find puppy_vpup_xxx.sfs'. This is now my redacted entry using shinobar's grub2config. [B4IF, grub2config should be 'builtin']:

menuentry 'Void32 (sda3/void32)'{
search --no-floppy --set=root --fs-uuid 39ff128d-XXXXX-ETC
linux /void32/vmlinuz pdrv=39ff128d-XXXXX-ETC psubdir=/void32
initrd /void32/initrd.gz

Timezone GUI does not offer choices.
Firewall via GUI says it's set, but red icon on panel remains, tooltip says 'off'.
Great that partitions could be mounted.

Was exploring which portables would work. I hate to have to 'reinvent the wheel'. It would help diagnosing issues if LIstDD was 'built-in'. It did install. Also, while I finally remembered how to use the "./" command to run something via terminal, it would also help if 'run-in-terminal' were on the right-click menu.
Most portables reported missing libs –should have expected that-- and I don’t recall if any AppImages were functional. But these kind of problems are often solved by hunting for libs.
'mozilla-based' portables worked; I'm posting from palemoon portable.

ldd reports chromium-clones have missing libs even with regard to the 32bit 'clones' which run under 32-bit 'Ubuntu-puppies': iron, vivaldi, slimjet.

SFS-Load on the Fly works. LibreOffice could be opened and functioned.
masterpdfeditor4 loaded but did not open. LDD revealed the following missing libs:
libsane.so.1 => not found
libQtSvg.so.4 => not found
libQtGui.so.4 => not found
libQtNetwork.so.4 => not found
libQtCore.so.4
IMHO, the basic libQt (4s –and if newer apps are to be used Qt5s) should be ‘built-in’ or easily obtainable. Void's repo will likely offer the 5s. But not the 4s. I can put together a basic Qt(4) package. My experience is that while packaging may be 'distro-specific' the actual qt files will work under most Puppys.

Shutdown, creating a SaveFolder. Rebooted and my setting were saved, including LibreOffice being loaded. Can vpup use SaveFiles? I don't think so. But it's an easy test.

Installed TED rtf wordprocessor. LDD reported that libpng12.so.0 was missing. Several portables also reported its absence. Will have to learn how to uninstall using Void package manager if pets are going to be installed. Probably best not to install them unless (a) You know they work and (b) void doesn't offer the needed files. For now, I'll reboot without Saving. Should have remembered that you're facing the 'void doesn't know what PPM is doing' problem. I didn't remember that until I tried to uninstall and discovered PPM isn't 'on the menu'. [Maybe include but use 'NoDisplay=true' in its /usr/share/applications file?)

Save Icon did not appear on desktop. Terminal “save2flash” reports “Wrong pupmode, something like ‘Pupmode 12” which I take to mean its running 12 rather than 13. I should have expected that. Wonder if boot argument ‘pmedia=ataflash’ will work? That's actually my next test. From discussions on the Airedale thread I don't expect it to. But, it's an easy test.

Not Void/vpup32 specific:
I moved the top panel to the bottom. How to you configure it to use 100% of the screen-width?

[rockedge]

To remove packages using xbps

Code: Select all

xbps-remove <package>

automatic:

Code: Select all

xbps-remove -y <package>

[wiak]

In order to boot I had to include the pdrv=URL-Specific on linux line. Added psubdir= as a further precaution against 'can't find puppy_vpup_xxx.sfs'. This is now my redacted entry using shinobar's grub2config. [B4IF, grub2config should be 'builtin']:

masterpdfeditor4 loaded but did not open. LDD revealed the following missing libs:
...
IMHO, the basic libQt (4s –and if newer apps are to be used Qt5s) should be ‘built-in’ or easily obtainable. Void's repo will likely offer the 5s. But not the 4s. I can put together a basic Qt(4) package... My experience is that while packaging may be 'distro-specific' the actual qt files will work under most Puppys.
...
Save Icon did not appear on desktop. Terminal “save2flash” reports “Wrong pupmode, something like ‘Pupmode 12” which I take to mean its running 12 rather than 13. I should have expected that. Wonder if boot argument ‘pmedia=ataflash’ will work? That's actually my next test. From discussions on the Airedale thread I don't expect it to. But, it's an easy test.

I am surprised by some of your test results mikeslr. This design has nothing to do with Kennel Linux Airedale, as far as I knew, except Void's Package manager xbps is included in the build and PPM isn't. I did not it was save to file rather than save to folder though - not sure why that would be.

I'd actually forgotten how to boot a Pup, and didn't have an entry in my grub.cfg, but managed on my system with:

Code: Select all

title voidpup32
  root (hd0,3)
  kernel /voidpup32/vmlinuz pmedia=idehd psubdir=/voidpup32
  initrd /voidpup32/initrd.gz

Voidpup32 is using standard Puppy's initrd as far as I knew (I'm not in it just now to check) which means all the Pupmodes and boot arguments should be as normal I would have thought. The only difference to the usual Pup release would be the no PPM provided I would have thought.
EDIT: in voidpup32 now; certainly is a Puppy initrd so couldn't myself tell you why Pupmode 13 not working if it isn't. Note that KLV-Airedale does come with an equivalent to that mode, which is activated via grub parameter w_changes=RAM2, but that KLV isn't using Puppy initrd at all whilst voidpup32 does (and voidpup32 using aufs whereas KLV Airedale currently uses overlayfs).

As far as easy installation of Qt libs in voidpup32 (or anything else for that matter) - it is easy just using provided Void's package manager. You just need to use the likes of:

Code: Select all

xbps-install -Sy sane qt5

I don't know if Void Linux still supports Qt4 or not. If not, then you would need suitable sfs addon for qt4 though. You can check what's available here:

https://voidlinux.org/packages/

NOTE: peebee has included vpm, I think, which is a frontend to xbps that is easier to use. try: vpm --help
What is particularly nice about vpm is that it also provides the full xbps commandline it used so good for learning xbps syntax.
A gui for xbps, octoxbps is discussed on the Airedale thread. It is really good but needs to be run as a normal user and isn't installed in provided voidpup32.

[mikeslr]

With the system files of a Puppy located on a hard-drive, Pupmode13 requires that the boot-arguments include 'pmedia=ataflash' on the kernel/linux line. Originally I hadn't included that.
wiak: you're explanation that Voidpup32 is using a Puppy initrd explains why my original boot arguments hadn't worked and why adding pmedia=ataflash to boot arguments enable it to now run under Pupmode13. Both the desktop icon appeared and functioned; and at shutdown I was asked if a Save was wanted.
I only made a couple of changes, then did a manual Save via the desktop drive icon. The changes were merely aesthetic: a new wallpaper and a customized icon for the desktop Save.
I then shutdown answering "NoSave" to the question. Happily, the manual Save worked.

Current desktop.png (173.78 KiB) Viewed 76175 times

.
I am currently a happy camper.
But I'm going to take a break from further exploring while those who know what they are doing solve the VPM issue. Most of what I can do/contribute is restructuring applications so that they'll work under Puppys. That involves a lot of 'trial & error' and having to reboot to remove errors isn't an ideal work routine.

[wiak]

Just did a quick attempt to turn voidpup32 into a proper multi-user Puppy, which would be a first as far as I know. Note that I'm still using alpha1 version with manual fixes - internet connection and xbps (vpm) working fine on this one).

To do this I just installed the following using xbps-install (or vpm):

xbps-install -Sy pam shadow sudo

I also installed coreutils, but I don't know if that was required.

Then I used the WeeDog_Arch64 build plugin commands (just noted same in KLV-airedale) to create a new user (weedog):

Code: Select all

# Give wheel group nopasswd sudo rights and create weedog as wheel group member
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group added to sudo no password required
useradd -m -G wheel -s /bin/bash weedog  # weedog in wheel group so has elevated sudo permissions

But that didn't quite work because there was no wheel group set up.

Probably daftly I tried to install Void Linux small base-files package (which I think contains /etc/group setup, but I haven't checked that), but interestingly for future issue with xbps that didn't work because of:

Code: Select all

/run must not be a directory, exiting!

It would have been better at this stage for me to try to manually create a 'wheel' group, but didn't know how off the top of my head, so simply created user 'weedog' without putting into any wheel group via command:

Code: Select all

useradd -m -s /bin/bash weedog

then added user weedog to the sudoers file using visudo:

Code: Select all

echo 'weedog ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo)

and finally checked all was basically working as following transcript shows:

Code: Select all

# whoami
root
# pwd
/root
# su - weedog
# whoami
weedog
# pwd
/home/weedog
# sudo ls -al
total 12
drwx------ 2 weedog weedog 100 Dec 20 10:03 .
drwxr-xr-x 5 root   root    80 Dec 20 10:02 ..
-rw------- 1 weedog weedog 213 Dec 20 10:28 .history
-rw-r--r-- 1 weedog weedog 312 Jun 15  2019 .xinitrc
-rw-r--r-- 1 weedog weedog 100 Jun 15  2019 .xsession
# exit
logout
# whoami
root
#

Would be nice to get weedog in proper wheel group however cos then would have Xauthority permissions like root so the likes of: "sudo rox" would also then work properly, but as things stand doesn't.

As a further matter of interest I tried su to spot (who I haven't made a sudoer) and at end tried password spot for spot. I'm not sure if spot will work correctly since wasn't created via PAM/shadow/useradd but by Puppy woof-CE build configs, but I do note it also set up to use /home/spot, which is good:

Code: Select all

# su - spot
# whoami
spot
# pwd
/home/spot
# sudo ls

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password: 
Sorry, try again.
Password: 

Finally, I added another user:

Code: Select all

useradd -m -s /bin/bash debdog

and put them in sudoers file:

Code: Select all

echo 'debdog ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo)

and transcript for that one fine also:

Code: Select all

# whoami
root
# su - debdog
# whoami
debdog
# pwd
/home/debdog
# sudo ls -al
total 12
drwx------ 2 debdog debdog 100 Dec 20 10:41 .
drwxr-xr-x 6 root   root   100 Dec 20 10:40 ..
-rw------- 1 debdog debdog  36 Dec 20 10:41 .history
-rw-r--r-- 1 debdog debdog 312 Jun 15  2019 .xinitrc
-rw-r--r-- 1 debdog debdog 100 Jun 15  2019 .xsession

So there it is... a Puppy working as a proper multi-user Linux. Who would have thought?...

Now to see how to set up a proper wheel group so those in that group have better root permission capabilities when used with sudo. Of course you can keep all these multi-users for when useful but still auto-login and work as user root most of the time. Not sure if you can auto-login as user weedog, for example, but maybe could be arranged; I'll have to look into that.

It should be easy for me to simply use xbps to install Wayland and Wayland-capable apps with this. Only worry is that issue noted above that Void Linux itself does not want /run to be a directory - but maybe Wayland will work anyway; it is certainly trivial to install and use Wayland with WDL_Arch64 - I've done that. I'll try with voidpup32 later.

EDIT: Actually I think su - weedog should not allow Xauthority anyway. It is a different matter if logged into the desktop as user weedog, then sudo rox should work I think, so all is well and making a wheel group doesn't really matter. My only concern for future additions to expand system fully via Void xbps is that /run being a directory issue, which may or may not prove to be further problematic.

[wiak]

Again, though it would be tidier if pristine install of voidpup32 includes correctly uptodate xbps database, I don't myself think it matters very much. Once a user expands the system via xbps (or frontend vpm) all packages requested will be recorded in xbps database and sooner or later anything installed in the first place will be replaced by the Void repo versions and xbps database indexed. Okay, having the xbps database correct would save a bit of space (avoiding first duplicates) but since Void can be used to update at any time (being a rolling release distro if you want to utilise new versions, which is optional) chances are you will be updating everything later anyway (in sync with Void releasing package updates, but yes, updating is optional though good for security and definitely a major benefit of making remasters of the main root filesystem sfs at update times).

In practice xbps(vpm) works fine as it stands. Certainly, a quick remaster at some stage would remove duplicates (the new Void versions remaining - the original iso versions no longer required).

My view is definitely that this is a much improved Pup to the traditional PPM-based ones. Huge advantage having the official package manager as part of Puppy design.

Not so easy to achieve all of this with Debian-based Pups of course - nearest to that, thus far, is via the dpkg/apt sfs addon I provided for use with Fossapup. Void Linux xbps (with vpm) is a great fit for Puppy though - xbps does not need PAM and shadow to operate, but dpkg/apt expects all of that and more.

[rockedge]

I agree with @wiak , this is a very powerful Puppy Linux. As mentioned in an earlier post needed is additional script(s) or block(s) of code added into woof-CE that can generate an XML formatted log file of what during the woof-CE build is installed. Create the package data lists xbps is looking for.

Plus the 32 bit Pup is stable and modern. Once the bumps are smoothed out and enhancements introduced, will be a highly usable distro. Perhaps inspiration for a VoidPup64 will follow!

[wiak]

Of course you 'could' also include PPM and pkg on this Pup. The important thing would be to NOT let xbps know about PPM-installed packages!!! Otherwise, Void might not reinstall them when actually it needs to in order to get fully void-compatible versions in terms of compatibility with Void libs and so on. If xbps database doesn't know about a package and it works - fine and good!!!

Advantage in including say pkg and/or PPM is that you could install specially crafted tiny versions of packages that might not be so featureful but use less dependencies than the official Void Linux repo versions. And of course, these could be in dotpet format, so makes that aspect of installation easier (not that installing dotpets needs all that PPM stuff - just a tar.gz really).

[wiak]

The power of official Void package manager xbps on voidpup32:

The attached image is voidpup32 running xfce4 just like in KLV-airedale. A bit subversive I suppose...
Much bigger distro of course (tons of stuff needed for such a full xfce4 desktop).

How I did it??? Simply, 5 minutes job 'to arrange' (but not recommended for home use (yet). I simply took a subset of the xbps-install commands from the WeeDog plugin used by rockedge to build KLV-airedale, and then used the .xinitrc from KLV-airdale instead of the one already in voidpup32 and did a Logout - restart X server command:

Code: Select all

## Xorg server, xfce4 Desktop configuration

xbps-install -y xorg xfce4 xfce4-panel xfce4-plugins compton picom
xbps-install -y gvfs 
xbps-install -y gvfs-smb gvfs-mtp gvfs-cdda

Took ages to actually download of course since existing voidpup32 xbps database didn't know xorg and all the fonts and so on were already installed (and probably xfce4 needed tons more fonts and similar also).

Next I should make a proper Wayland version I suppose - just to show how easy that would similarly be. Maybe some other time.

[mikeslr]

@ wiak, FWIW --and despite my stated intention to put-off further exploring-- I found myself wondering how I could be useful in a void-puppy environment seeing as how the most I could contribute is hobbling together applications.
I've previously mentioned how useful running applications originally built for Puppys as SFSes would be: avoiding the problem of xbps package manager having to keep track of files 'on its system' which it didn't, itself, install. And it runs against my grain to have people spending time 're-inventing the wheel'.

To construct applications I've basically:
(1) downloaded applications including all dependencies;
(2) Placed them in a folder;
(3) used PaDS to decompress all the downloaded files then combine them into a SFS;
(4) SFS-loaded that SFS and examined it by (a) running it via a terminal and (b) using ListDD on its binaries.
(5) Added missing libs (creating symbolic links when needed) to the 'source' folder and repeating steps 3 and 4.
PaDS has bash routines for decompressing (using binaries) and combining. But it wasn't designed to work with files in the xbps format. And for the life of me, I've never been able to follow its logic.
I think the argument "xbps -U" will decompress xbps packages. An application to create an SFS really just involves serially decompressing the source packages, then combining their files.
There are applications other than PaDS which can combine packages into SFSes. Their codes and or links (which might be broken) are on the 'old' Forum. IIRC, JRB, 01micko and jemimah and other all had versions. I've collected a few which might not be easily available. Distilling their essence is how I know what they do. But understanding it and the mechanics of xbps is 'above my pay-grade'.
So I've mentioned the above in the hopes that creating a 'combine to SFS' application for Voidpuppys --able to use xbps, pets and maybe other package formats-- might be something you'd care to direct your nimble mind to.

[wiak]

So I've mentioned the above in the hopes that creating a 'combine to SFS' application for Voidpuppys --able to use xbps, pets and maybe other package formats-- might be something you'd care to direct your nimble mind to.

What I say is this Mike: I see no major issue involved in using what Void Linux official repo perspective would be called 'alien' packages - within limits anyway.

The reason I see no problem with that is that since xbps database only indexes what xbps itself installs, that means xbps simply does not know these 'alien' packages (via sfs addons or whatever) exist, and that is a good thing really since xbps will not then get into a panic!

sfs addons will pretty much always be arranged to appear in a higher layer of the overlay by default (I think - correct me if I'm wrong - I'm not actually so familiar with the layer arrangement in Puppy in terms of what is given precedence; in WDL distros 2-digit-numeric addon name clearly identifies which layer takes precedence), so the sfs version of any already installed app will temporarily 'over-write' any existing (in lower layers) version of the same app in same executable location. That makes it a very good chance the loaded sfs app will simply work fine. Of course, something previously installed may fail to work (maybe rarely) but why worry... once the sfs addon is unloaded the original packages xbps knows about will all be 'seen' again and no damage done. Of course, you don't want to physically 'merge/remaster' alien packages with Void xbps installed ones - but that is just something to keep in mind (even then things might work, but just not advisable I'd say).

Should be trivial to write a dotpet install utility since basically just a tar.gz. Many Puppy app/utils are simply bash/gtkdialog (maybe yad) scripts, and are unique so will not clash with anything from upstream Void Linux repo anyway, so no danger with these ones - just a matter of checking they don't involve over-writing official Void libs and so on, but as I say, many are much simpler than that. My own apps, Precord and weX, for example will be installable no problem at all via dotpet-type packages though personally I'd be far more likely to install such apps as sfs addons since these are read-only and can be unloaded at any time (aside from their config files, which generally will cause no harm even if left in place via save changes).

So what do you have to avoid to make issues unlikely? I'd say, dotpet or tar.gz or similar installs of any more complex apps that, as I say for example, contain their own libs and/or binary executables that will over-write official Void Linux repo ones of the same. Hence safer to use sfs apps that xbps database cannot know about - these will most likely always (or nearly always) work fine, and can be unloaded any time anyway and will most usually not likely cause any harm either way.

Great thing though is that you can 'experiment' with more dangerous possibly conflicting installs if you DO NOT SAVE the session you do that in (i.e. using Pupmode 13 you spoke about previously; similarly in KLV-airedale where w_changes=RAM2 could be used in grub config for same effect).

I don't see me testing many dotpets or Puppy sfs out myself though (except out of occasional personal interest) since I struggle to keep up with other matters (computing and non-computing related) as it is. However, others can certainly manage that. If I were to make a recommendation (and it is something I have moved my own apps to follow) is that dotpets that put the binary exec into /usr/bin would be re-organised to instead put them in /usr/local/bin. That works better when using an official package manager like Void xbps because official repo binaries generally get put in /usr/bin and we don't want to overwrite these official ones whenever same-named binaries. But there can still be an issue since /usr/local/bin may have priority in the executables PATH (since if you put your own app in /usr/local/bin you probably have it arranged that your one takes precedence - depending how the system has been organised). Nevertheless, PATHS can be changed. Summary is that sfs loading is probably better - in the past I have done this by taking dotpets and combining them into one special Puppy/Dog-related sfs addon - in fact in the KLV-airedale project even gtkdialog is loaded by sfs (alongside filemnt and some other optional small dev utilities such as redeb); could just have easily had various uncompressed dotpets included there too or in a separate addon sfs).

Puppy is a famous distro for mixing and trying and experimenting with alien packages so risks have long been taken - no difference here - with some care the risks, as I describe, can be minimised to near nothing. Puppy is a small system by default so can easily always keep two ready to boot: one for stable testing known to work configurations, and one for experiments (some aspects of which can later be used in the stable boot version once trusted...). As you say, creating apps (be these sfs, tar.xz, or whatever format) out of official xbps downloadables will be particularly 'safe' - I can't remember the command for decompressing Void apps either - rockedge has been using it more than me so no doubt can tell us (or maybe frontend vpm contains a simple to use format for the same purpose). I would be less keen myself to use two different package managers (e.g. xbps and PPM) for installing apps, though it can be useful as rockedge has described using PPM, pkg, and dpkg/apt all in same distro to good effect; problem is both xbps and PPM keep their own databases of apps installs so which do you wish to trust(?) - no doubt you could easily 'break' one of them or even both... nevertheless, I'm all for suck it and see - if it works for you, seems fine to me! And I like having the option to 'live dangerously' so really hope PPM, pkg, and xbps can end up as available on this distro (no-one forcing anyone which to rely on or use or mix use). If it is possible to include the likes of PPM and pkg as an optional addon sfs, that would be the best arrangement in my opinion - definitely xbps will be 'best' in terms of reliability in installing from Void repos and keeping track of dependencies correctly.

[rockedge]

Ran across a script that extracts Void Linux xbps packages:

xbps-src-doextract.sh

Code: Select all

#!/bin/bash
## xbps-src-doextract.sh (1697B)
#
#
# vim: set ts=4 sw=4 et:
#
# Passed arguments:
#	$1 - pkgname [REQUIRED]
#	$2 - cross target [OPTIONAL]

if [ $# -lt 1 -o $# -gt 2 ]; then
    echo "${0##*/}: invalid number of arguments: pkgname [cross-target]"
    exit 1
fi

PKGNAME="$1"
XBPS_CROSS_BUILD="$2"

for f in $XBPS_SHUTILSDIR/*.sh; do
    . $f
done

setup_pkg "$PKGNAME" $XBPS_CROSS_BUILD

for f in $XBPS_COMMONDIR/environment/extract/*.sh; do
    source_file "$f"
done

XBPS_EXTRACT_DONE="${XBPS_STATEDIR}/${sourcepkg}_${XBPS_CROSS_BUILD}_extract_done"

if [ -f $XBPS_EXTRACT_DONE ]; then
    exit 0
fi

# Run pre-extract hooks
run_pkg_hooks pre-extract

# If template defines pre_extract(), use it.
if declare -f pre_extract >/dev/null; then
    run_func pre_extract
fi

# If template defines do_extract() use it rather than the hooks.
if declare -f do_extract >/dev/null; then
    [ ! -d "$wrksrc" ] && mkdir -p "$wrksrc"
    cd "$wrksrc"
    run_func do_extract
else
    if [ -n "$build_style" ]; then
        if [ ! -r $XBPS_BUILDSTYLEDIR/${build_style}.sh ]; then
            msg_error "$pkgver: cannot find build helper $XBPS_BUILDSTYLEDIR/${build_style}.sh!\n"
        fi
        . $XBPS_BUILDSTYLEDIR/${build_style}.sh
   fi
# If the build_style script declares do_extract(), use it rather than hooks.
    if declare -f do_extract >/dev/null; then
        run_func do_extract
    else
# Run do-extract hooks
        run_pkg_hooks "do-extract"
    fi
fi


[ -d "$wrksrc" ] && cd "$wrksrc"

# If template defines post_extract(), use it.
if declare -f post_extract >/dev/null; then
    run_func post_extract
fi

# Run post-extract hooks
run_pkg_hooks post-extract

touch -f $XBPS_EXTRACT_DONE

exit 0

[jamesbond]

@peebee

Attach is a script that will convert "woof-installed-packages" to xbps pkgdb format.

You need:
1. index.plist (the Void pkg repo list).
2. xmllint (part of libxml2 package, it was already installed in voidpup32)
3. awk (already installed in voidpup32)

You can do this from within inside voidpup32 itself (or you can do it at Woof-CE build-time, by chroot-ing to the rootfs):

Code: Select all

./woof-ext.sh /var/packages/woof-installed-packages /path/to/index.plist > /var/db/xbps/pkgdb-0.38.plist

It will take a while, because, unlike my other script (which converts index.plist to PPM database) which only runs the xml2 once, this script runs xmllint multiple times - as many as there are packages in woof-installed-packages (658 on last count). The faster way is to run xml2, use grep/awk/sed to do the extraction, and then convert it back to XML using 2xml - but you can't run it inside voidpup32 because xml2 package is not installed there.

Once you have done it, running (for example)

Code: Select all

xbps-install -S dialog

in voidpup32 will say that "dialog has been installed" - which is what we want, and running

Code: Select all

xbps-query -l

Will shoe the list of packages installed by Woof.

Note: Some packages are not translated. Generally, these are Puppy/Woof-CE packages that don't exist in Void repository, things like Pup-Kview, Pup-Sysinfo, firewall_ng, frugalpup, etc. These "missing" packages are printed out to std error when the ./woof-ext.sh is running. Oh, and it also ignores _DEV & _NLS packages as they're synthesized package records from Woof-CE and not really exist as separate packages in Void.

Feel free to look at it, learn from it, re-use it, enhance it, tweak it, embed it into another scripts ... etc.
Enjoy and may your effort on VoidPup be fruitful.

NOTE: I sincerely hope that this thread will not disappear again

[Keef]

Tried setting up the firewall but it fails as 'iptables' is not found. It seems it should be a symlink to the multi-call binary 'xtables-legacy-multi'. Added it, and all works properly now. All the other links are there as far as I know. Which isn't a great deal to be honest.

[wiak]

Could @jamesbond, or someone who has a copy, please re-post here the Void-package-woof-CE-format script (I think it was for that) that he originally posted on original community distro dev thread that bigpup deleted. I did not realise the important resource would be make to vanish without warning so have no copy of it but would like one.

[one]

Hi @peebee,

I did a quick test of your new voidpup32 as a frugal install.

As @mikeslr mentioned timezone setting is not available in QuickSetup first run.

Savefile and savefolder are working (I tested both), sfs_load of palemoon also.

Thank you, best wishes ...

[jrb]

Hi @peebee,

I did a quick test of your new voidpup32 as a frugal install.

As @mikeslr mentioned timezone setting is not available in QuickSetup first run.

Savefile and savefolder are working (I tested both), sfs_load of palemoon also.

Thank you, best wishes ...

Ditto. Cautiously trying this out. Posting from portable firefox-esr in VoidPup now. It's working well.

Copied in /usr/share/zoneinfo from Slacko 7.0. Can now set timezone from Desktop menu and QuickSetup menu.

Installed osmo-0.2.8-p4.pet. Working well, one of my old favourites.

Next step will try figuring out VPM.

Thanks for all your efforts peebee.