QuickPup64 25.01 RC4

mistfire · Post by **mistfire** » Thu Jul 21, 2022 10:31 am

QuickPup64 22.01 BETA 16

Changes:
* Linux kernel 5.18.12-lxpup64 (thanks @peebee)
* Pidgin (with facebook, discord, skype, rocketchat, and SMS support), hexchat, lynx, and lagrange gemini browser added (on GDRV module)
* Some bugfixes

Download: https://drive.google.com/file/d/1DLbYB- ... 9S1J_QzgkV
MD5 Checksum: e53f5f0b6acdb119016a5859993949fe

Clarity · Post by **Clarity** » Thu Jul 21, 2022 6:12 pm

Hi @mistfire. This works without issues of any sort, thus far.

Downloaded the ISO file
Added the ISO file to /BOOTISOS folder and booted the ISO file via, both, Ventoy and SG2D.
After pristine boot of this v16 the session was saved and found on reboot without issues. Thusly, it operates as a frugal, excepting none of its initial hassles.

Just now, I tested booting ISO file in QEMU...no issues with any of the currently tested services.

Clarity · Post by **Clarity** » Fri Jul 22, 2022 9:12 am

@mistfire, I want to take a moment to commend you of what you have done in this PUP's Init-Shutdown processing improvements. It is FABULOUS!

Many users will take the improvements in strive, unaware of the difference and the improvements you've made to that particular element of work initially done by @gyrog.

I hope the WoofCE developers take a moment to review as you have removed couple of restrictions while improving the flow for both booting as well as shutdown processing.

With your changes, use of the SAVESPEC file, et. al. There is NO need for a user who is booting from the ISO file to intercept the PUPP's boot Menu item to guide booting-shutdown locations (ie PSAVE/PMEDIA). All elements are covered in the manner you have this PUP booting! This allows the ISO file booting to negate ANY need to deconstruct and move any contents in order to have a frugal operation...NONE. Merely download, boot and save the session is all that is required, today.

Thank you for this and several other forward-thinking elements, as well as some universal elements you have included within the packaging of this distro: Amazingly crafty and useful!

mistfire · Post by **mistfire** » Mon Jul 25, 2022 4:43 am

Clarity wrote: Fri Jul 22, 2022 9:12 am
@mistfire, I want to take a moment to commend you of what you have done in this PUP's Init-Shutdown processing improvements. It is FABULOUS!

Many users will take the improvements in strive, unaware of the difference and the improvements you've made to that particular element of work initially done by @gyrog.

I hope the WoofCE developers take a moment to review as you have removed couple of restrictions while improving the flow for both booting as well as shutdown processing.

With your changes, use of the SAVESPEC file, et. al. There is NO need for a user who is booting from the ISO file to intercept the PUPP's boot Menu item to guide booting-shutdown locations (ie PSAVE/PMEDIA). All elements are covered in the manner you have this PUP booting! This allows the ISO file booting to negate ANY need to deconstruct and move any contents in order to have a frugal operation...NONE. Merely download, boot and save the session is all that is required, today.

Thank you for this and several other forward-thinking elements, as well as some universal elements you have included within the packaging of this distro: Amazingly crafty and useful!

Thanks @Clarity. I want to make this QuickPup64 to be release as stable release however it will still in beta because of xfwm4 compositor which prevents chromium based browser to start (and also turn the screen black when capturing screenshot), also the dbus error message popup shown when double-clicking the file on the desktop, and the systray icon which was unable to render tray icons correctly. I hope that someone will give the solution for those three big persistent problems on QuickPup64

mistfire · Post by **mistfire** » Thu Jul 28, 2022 1:20 am

QuickPup64 22.01 BETA 17 released

Changes:
* Added GTK4 library (on GDRV modules)
* Fixed screen lock problem
* Package updater and pkg can now trim packages upon installation

Download: https://drive.google.com/file/d/1of66zB ... Q20Svy83Ox
MD5 Checksum: a1a1380ba5e799e3c78adfa4540189a8

Clarity · Post by **Clarity** » Thu Jul 28, 2022 9:24 am

I've hit couple snags that are head-scratchers on a particular PC.

#1 - Mounting a remote share:

Code: Select all

# mount //LAN-IP_of-remote/resource /mnt/folder-name
Password for root@//192.168.143.210/Downloads: 
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

DMESG shows

Code: Select all

[ 1283.982080] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[ 1283.982087] CIFS: Attempting to mount \\192.168.143.210\Downloads

Not sure how long this problem has been present?

#2 - An unusual one booting the ISO file from SG2D on this 7 yo PC (all of my PCs are old)
I usually boot all my PUPs/DOGs, including QuickPUP64 via their ISO files from the USB in the /BOOTISOS folder. But for QP, I have a strange new issue, while its not happening with other PUP ISOs on this PC. Scenario:

The filesystem on the USB is ext4.
Boot SG2D and select QP vbeta17.
QP displays its Menu and I hit the enter key without any changes (in fact subsequent tests with changes to enter a PSAVE parm has no impact) and the boot process fails with a usual option to save the debug info.
A debug file is created and attached below.

At first, I suspected corruption, but e2fsck comes back clean with '0' files non-contiguous. So that's not it.

So I moved the ISO file to a /boot-isos folder on the systems NTFS and reboot SG2D. SG2D files the all ISOs in both folders where I select the QP ISO from the NTFS folder and QP boots straight-away to desktop.

So, this is odd and unseen before now. Hope you can see something from the debug file attached that would explain the behavior.

I will follow any requests to get arms around explaining this.

mistfire · Post by **mistfire** » Thu Jul 28, 2022 12:36 pm

Clarity wrote: Thu Jul 28, 2022 9:24 am
#2 - An unusual one booting the ISO file from SG2D on this 7 yo PC (all of my PCs are old)
I usually boot all my PUPs/DOGs, including QuickPUP64 via their ISO files from the USB in the /BOOTISOS folder. But for QP, I have a strange new issue, while its not happening with other PUP ISOs on this PC. Scenario:

The filesystem on the USB is ext4.

Boot SG2D and select QP vbeta17.

QP displays its Menu and I hit the enter key without any changes (in fact subsequent tests with changes to enter a PSAVE parm has no impact) and the boot process fails with a usual option to save the debug info.

A debug file is created and attached below.
At first, I suspected corruption, but e2fsck comes back clean with '0' files non-contiguous. So that's not it.

So I moved the ISO file to a /boot-isos folder on the systems NTFS and reboot SG2D. SG2D files the all ISOs in both folders where I select the QP ISO from the NTFS folder and QP boots straight-away to desktop.

So, this is odd and unseen before now. Hope you can see something from the debug file attached that would explain the behavior.

I will follow any requests to get arms around explaining this.

It seems the USB got disconnected upon loading the kernel based on the bootinit log. That's weird

mistfire · Post by **mistfire** » Thu Jul 28, 2022 12:40 pm

Clarity wrote: Thu Jul 28, 2022 9:24 am

I've hit couple snags that are head-scratchers on a particular PC.

#1 - Mounting a remote share:

Code: Select all

# mount //LAN-IP_of-remote/resource /mnt/folder-name
Password for root@//192.168.143.210/Downloads: 
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

DMESG shows

Code: Select all

[ 1283.982080] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[ 1283.982087] CIFS: Attempting to mount \\192.168.143.210\Downloads

Not sure how long this problem has been present?

you need to specify SMB version to use on mount option.
See this link for more details
https://askubuntu.com/questions/1098369 ... untu-18-04

Clarity · Post by **Clarity** » Thu Jul 28, 2022 7:44 pm

Thanks @mistfire

Since I've never needed to specify 'ver=' for any PUP to connect to any PUP which is sharing a folder, could this be a new requirement? Or is there something else happening. I tried the other PUPs I have running to the same LAN to FossaPUP which is sharing and no need. So, this could be something else or a specific requirement for this PUP distro....maybe.

Will get back to prescribe how users should use mount from this distro to the PUPs on their LAN which share folders.

Clarity · Post by **Clarity** » Thu Jul 28, 2022 7:52 pm

mistfire wrote: Thu Jul 28, 2022 12:36 pm
It seems the USB got disconnected upon loading the kernel based on the bootinit log. That's weird

Yeah, I concur.

Well it could be the USB drive which is a 14 year old laptop drive that I have used in a USB case forever. Although it is working for all the other ISO files it has, its only this single ISO file that was recently copied to it.

To test, I will create another USB stick and test if that is the culprit. This would give some evidence if its the USB issue with the PUP versus the known and now tested system's HDD location which works.

A credit, though, is that merely moving it so that SG2D can find it has proven that its NOT a QP problem at this point. OR, just maybe, there is some quirk in the USB controller and QP init processing that might be an issue.

Weird, I agree, and still scratching my head

step · Post by **step** » Thu Jul 28, 2022 8:58 pm

Clarity wrote: Thu Jul 28, 2022 7:44 pm
Thanks @mistfire

Since I've never needed to specify 'ver=' for any PUP to connect to any PUP which is sharing a folder, could this be a new requirement? Or is there something else happening. I tried the other PUPs I have running to the same LAN to FossaPUP which is sharing and no need. So, this could be something else or a specific requirement for this PUP distro....maybe.

Will get back to prescribe how users should use mount from this distro to the PUPs on their LAN which share folders.

It is a new requirement. SMB software was upated to default to protocol version 2.1. If you want to mount a disk from an old Windows PC, old router, basically any disk/server that predates a recent SMB client software (like the one in QuickPup64), you must CHANGE your mount command to include an option to use SMB 1.0 so the remote disk/server will understand that it's being requested for mounting and reply accordingly. An old disk/server can only speak SMB 1.0 because 2.1 didn't exist when the disk/server was deployed, and the old disk/server's SMB was never updated.

rcrsn51 · Post by **rcrsn51** » Thu Jul 28, 2022 10:09 pm

step wrote: Thu Jul 28, 2022 8:58 pm
It is a new requirement.

This was first discussed in the YASSM thread in November 2017.

Clarity · Post by **Clarity** » Thu Jul 28, 2022 10:47 pm

Updated info on QP64's current LAN existence and behavior:
Local SAMBA started

: QP SAMBA share.png (51.13 KiB) Viewed 28256 times

On this local QP64, I've Rechecked local behavior via terminal with text on each command

Code: Select all

# echo "This shows attempt to connect to home's NAS from QP64"
This shows attempt to connect to home's NAS from QP64
#
# findsmb # Can you see any local resources?

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION 
---------------------------------------------------------------------
# smbclient -U% -L 192.168.1.10 # Can you see this local LAN resource

	Sharename       Type      Comment
	---------       ----      -------
	Downloads       Disk      OS ISO files
	Downloads2      Disk      OS IMG files
	Multimedia      Disk      Test1
	Backups         Disk      Test2
	IPC$            IPC       IPC Service (Puppy Samba Server)
SMB1 disabled -- no workgroup available
# findsmb # Can you see any local resources?

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION 
---------------------------------------------------------------------
# smbclient -U% -L localhost       # Can you see YOUR local LAN resource

	Sharename       Type      Comment
	---------       ----      -------
	puppyshare      Disk      
	IPC$            IPC       IPC Service (Puppy Samba Server)
SMB1 disabled -- no workgroup available
# mkdir /mnt/test # Create a test folder
# mount -o password=woofwoof //localhost/puppyshare /mnt/test # connect to the test folder
# umount /mnt/test # disconnect from the test folder
# mount -o password=woofwoof //192.168.1.10/Downloads /mnt/test # connect to renote PC folder
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
# samba --version # what version is THIS SAMBA
Version 4.16.4
# echo "This shows current test to problem"
This shows current test to problem
#

So the terminal account shows local to local things seem OK. But attempts to&from other PUPs-DOGs on the LAN, not so. Further, the 'findsmb' command shown in the terminal account is coming back empty where there are LAN PCs sharing their public folder

Further info:

The firewall is turned off
I cannot ping this local QP64 PC from other LAN PCs, no response
I cannot access the folder being shared from this PC as I am getting timeouts via smbclient nor mount commands from the other PCs

.
Something is amiss

I recognize that past accounts discuss issues, but until now, I haven't experienced those concerns with all the PUPs I have used.

I will recheck the ISO file's checksum to see if there is a mismatch and report back here.
EDIT: Just checked the checksum...it matches "a1a1380ba5e799e3c78adfa4540189a8"

Clarity · Post by **Clarity** » Thu Jul 28, 2022 11:05 pm

Has anyone else checked this LAN behavior on your LAN? ALL of my PUPs & DOGs are recent with recent OOTB SAMBA implementations.

Check the mount command I submitted and check for yourself the local connects, then try the same using this QP64-b17 version.

Thanks in advance for your personal findings and any subsequent mount command changes you offer.

AGAIN, excepting for 2 LAN resources, ALL of my home LAN connected units are PUPs & DOGs.

Clarity · Post by **Clarity** » Thu Jul 28, 2022 11:59 pm

This QP64 is running on a HP-G024 AIO. It is wired to the ethernet LAN; as such, WiFi is not in use/needed. I have NOT tried bluetooth.

Although not applicable to the above issues, I share these result

Code: Select all

# dmesg | grep -i fail
[   10.292563] exFAT-fs (loop99): failed to read boot sector
[   10.292566] exFAT-fs (loop99): failed to recognize exfat type
[   57.874575] tpm_crb: probe of MSFT0101:00 failed with error -16
[   60.360881] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2

FYI

Request for future: Could the Print-Screen key be enabled to open the enclosed screen-capture?

mistfire · Post by **mistfire** » Fri Jul 29, 2022 12:34 am

Clarity wrote: Thu Jul 28, 2022 11:59 pm
This QP64 is running on a HP-G024 AIO. It is wired to the ethernet LAN; as such, WiFi is not in use/needed. I have NOT tried bluetooth.

Although not applicable to the above issues, I share these result
Code: Select all
# dmesg | grep -i fail
[   10.292563] exFAT-fs (loop99): failed to read boot sector
[   10.292566] exFAT-fs (loop99): failed to recognize exfat type
[   57.874575] tpm_crb: probe of MSFT0101:00 failed with error -16
[   60.360881] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2
FYI

Request for future: Could the Print-Screen key be enabled to open the enclosed screen-capture?

You need rtl8723b_config.bin firmware driver and put it to /lib/firmware/rtl_bt

mistfire · Post by **mistfire** » Fri Jul 29, 2022 12:57 am

QuickPup64 22.01 BETA 18

Changes:
* Fixed xz utils
* Adjustments on initrd

Download: https://drive.google.com/file/d/1KQybwd ... dVEpmnZk4O
MD5 Checksum: 00178cf8aed8ce851fd7206ff45ab7f7

Clarity · Post by **Clarity** » Fri Jul 29, 2022 1:27 am

OK, the 'weird' problem experienced has gotten more off the rails. So I now have 2 new conditions to report.

Firstly, after booting the AIO where the beta 17 file was copied and booted from. That beta 17 was booted via SG2D adding a PSAVE parm pointing to the /Sessions folder on the HDD's partition. beta17 found the past QP64 sessions in the folder and listed them for selection at boot. I opted for a pristine boot. As reported,, beta17 booted and I used it for various tests and tasks which I reported earlier. Upon shutdown, I had the system save the session into the /Sessions folder. Its name of the status screen was correct; ie /Sessions/QPsave...

: wrong_items.jpg (95.32 KiB) Viewed 28218 times

BUT, instead of creating a new folder, the shutdown processor placed all of the sessions folders in the root of the /Sessions folder rather than in the QPsave it was suppose to create. Weird, again.

Next, in testing, I have now found that the beta17 ISO file on the USB is now booting to desktop with no other changes excepting that beta18 was downloaded to the /boot-isos folder on the SG2D USB??? Now, I am really scratching my head.

This is a mere status as I continue to try to nail down WHY this anomaly is occurring on this AIO, my newest PC (circa 2016).

Next up, I will switch to testing beta 18 starting as a pristing with no PSAVE parm and advancing thru the steps.

P.S. Found this in one of the misplaced files

Code: Select all

**** Initial ramdisk stage begin ****
Kernel info: 5.18.12-lxpup64 x86_64
Boot parameters: BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/boot-isos/quickpup64_22.01-beta-17.iso psave=sda7:/Sessions/
Setting imaginary GMT setting...
Setting system time (based on hw clock set to local time)...
Checking modules inside initrd...
Checking keymaps inside initrd...
Starting mdev...
Finding kernel modules for disk drives...
Boot mode: UEFI
RAM size: 6867Mb
   o
   o
   o

This shows what was given to INIT at boot. BUt the folder shown above indicates that it DID NOT store the session in a QPsave folder as it should have.

Clarity · Post by **Clarity** » Fri Jul 29, 2022 3:06 am

Expected ISO file booting from the USB has occurred in beta18. The booting issue has vanished for a RAM only boot. From bootinit.log we verify Boot parameters: BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/boot-isos/quickpup64_22.01-beta-18.iso

Other issues for LAN remain.

SAMBA is started at boot so the puppyshare folder is locally shared. BUT, LAN remotes CANNOT access this share while locally it can be accesses via the mount command.

Code: Select all

# mkdir /mnt/Test
# mount //localhost/puppyshare  /mnt/Test

or # mount //192.168.1.15/puppyshare /mnt/Test

What version for the mount command is being used for the current SAMBA? Why the smbclient utility is working where the findsmb utility is not? This is confusing in how the local LAN services on this is working.

You can test, too
For those who want to replicate the mount problem on your network, its easy if you know your beta18's IP address. Test on beta18 in a terminal with this command ... then use the EXACT same command from one of your Linux remotes to see the problem
# mount //beta18's_IPaddress/puppyshare /mnt/Test
This will expose the problem for your review.

Afterwards, you can change the IP address to one of your home PCs and see mount working to them.

My Next report will be showing the results of Session saving when this is Shutdown as well as what happens when PSAVE is added at boot to capture the Saved session.

Clarity · Post by **Clarity** » Fri Jul 29, 2022 4:00 am

Rebooted without issues using the PSAVE parm on boot from the USB.

Just noticed that my firewall was active (I mistakenly assumed that removing it via right-click also stopped it. Not so.). So stopping it, the'findsmb' utility is now reporting other LAN shares available.

But, from the remotes, they can now ping this beta18 PC but accessing this beta18 shared resource (namely "puppyshare" problem from the remotes, remain.

And the local&remote mount problem remains.

BTW: The mystery folders have reappeared. I will be trying next to understand the external conditions that causes Shutdown processing to create them

mistfire · Post by **mistfire** » Fri Jul 29, 2022 1:00 pm

@Clarity

About the mysterious folder, I think this boot parameter was seems the culprit

Code: Select all

psave=sda7:/Sessions/

You specify Sessions folder as the save file/folder

mistfire · Post by **mistfire** » Fri Jul 29, 2022 1:01 pm

QuickPup64 22.01 BETA 18 was reuploaded due to missing xz binary executables which cause trouble on package management

I hope @ally will replace her uploaded copy of QuickPup with this corrected one

Download: https://drive.google.com/file/d/1KQybwd ... dVEpmnZk4O
MD5 Checksum: c808c121369f9509aa169c17240b60ea

ally · Post by **ally** » Fri Jul 29, 2022 1:41 pm

done!

thanks for the heads up

Clarity · Post by **Clarity** » Fri Jul 29, 2022 4:15 pm

mistfire wrote: Fri Jul 29, 2022 1:00 pm
... You specify Sessions folder as the save file/folder

Then there seems to be 2 different meanings around in Puppyland of what the PSAVE pointer means. @gyrog continues to update INIT to accommodate. It was my understanding from @gyrog that it is the "location" (folder-name) to create the persistence within...not the actual filename. Judging from the other PUPs-DOGs I am now curious as to which understanding is correct.

For the past years, I have been using the Session Saving parameters to indicate at boot the location where the Savefile or the Savefolder is to be placed...not the actual name of the dump of the system's save contents in all other PUPs/DOGs.
As such, via the parm,

each systems knows where it will put or where it will find its persistence
for example "ThePUPname'save'-..." will be the leading characters for the PUP generating or finding its persistence
As you can see from the contents, are examples of @01micko's distros, @666philb's distros, @peebee, @dimkr etc. where the PUPs created those persistences files at shutdown and the PUPs finds those persistences on boot while also having the identity of where to place the persistence upon a pristine shutdown.
This behavior is consistent with the SAVESPEC file contents that @gyrog has built-in to WoofCE's INITs.

So, you are pointing out that any distro builder/developers could mistakenly build, interpreting how the PUP is to create, place, and name 'persistence'.

I dont make these interpretations, but, I do try to work within the design of the framework that is architected. So, now, which of the developers interpretation is correct for user use?

When Slacko boots it finds his and lists all it finds when there are multiples; when Fossas boots it finds his and lists all it finds when there are multiples; when Void boot and lists all it finds when there are multiples;... So the Sessions folder you see (from earlier) shows PUP persistences from the past PUPs booted on this PC (of course this behavior of those mentioned is the same on all PCs).

Hope we can see this dilemma in the differences in PUP SAVESPEC and PSAVE interpretation could happen, mistakenly. It is my understanding that those items identify the folder location PUPs will create or find persistence...not the actual filename of the persistence.

Question: Which is correct for the current PUP-DOG persistence architecture?

Thoughts?

P.S. I will present a pic showing what this PC presents for selection for FossaPUP64 in a moment. To give a pictorial understanding of what I am presenting in this post.

Clarity · Post by **Clarity** » Sat Jul 30, 2022 7:01 am

FossaPUP64 booted with PSAVE=sda7:/Sessions/ added to it boot Menu linux line

: Example of multiple saves for Fossa found on boot; Multiple SAVES for this PUP-small.jpg (95.39 KiB) Viewed 28222 times

On my other PCs: Other PUPs, when multiple saves for it are present within the Sessions folder, boot with the same presentation list at boot to the user for selection.

mistfire · Post by **mistfire** » Sun Jul 31, 2022 7:11 am

QuickPup64 22.01 BETA 19 released

Changes:
* Fixed desktop environment default settings
* Linux kernel 5.18.15-lxpup64
* Blueman-2.3.1
* Adjustments on initrd psave boot parameter

Download: https://drive.google.com/file/d/1AKGvjl ... QilglzCVL3
MD5 Checksum: 4117e85b8f5f2417a3c3b61eb3c799f7

esos · Post by **esos** » Sun Jul 31, 2022 6:53 pm

Video problem since version 15.
Refresh rate 0.0 Hz

mistfire · Post by **mistfire** » Sun Jul 31, 2022 10:47 pm

@esos

1. May I know the name and model of your computer?
2. May I see the output of lspci?
3. May I see the contents of /etc/X11/xorg.conf file?

Clarity · Post by **Clarity** » Mon Aug 01, 2022 6:00 am

Shutdown works as expected.

: This is what Shutdown processing indicates.png (49.65 KiB) Viewed 28112 times

On boot-processing, each Quickpup session which is saved is listed for user selection when there is more than one, also.

: Sessions saved for all PUPs booted on this PC.png (64.08 KiB) Viewed 28108 times

Thx for understanding.

Clarity · Post by **Clarity** » Mon Aug 01, 2022 6:38 am

All issues reported in earlier posts, for PRIOR beta versions, on LAN folder sharing and the utilities which support LAN folder access, no longer are present.

This PUP is clean in all aspects currently tested, including all the clever Puppy-Linux innovations provided in this distro.

Users, young and old, will find a friendly experience in this distro's use.

Thanks for all the great work.

Puppy Linux Discussion Forum