QuickPup64 24.01 RC6

[TerryH]

Just completed an update to a manual frugal install of Beta-8 to Beta-11. Running very smoothly. Excellent.

Once again, thank you for your continued development.

[mistfire]

Same experiences from Beta 10 booting ISO file directly via SG2D USB. It finds the prior save-sessions in the /Sessions folder on my ext4 partiton on the HDD.

The ONLY issue is an older one that exist in the system's "Shutdown app" in the shutdown subsystem. When the Linux formatted partition is selected and a folder approach is chosen, the final screen before exist does NOT allow the user to change the folder.

In the picture, below, the option to allow placement in a folder on the drive is missing. Would be nice if it was available so that user can keep all save-sessions in a folder of choice.Pristine-shutdown_cannot-select-folder.png

This does NOT affect what happens at boot-time as the QuickPUP64 is finding ALL save-sessions on the drive. BUT, it would be an advantage to direct the shutdown to save it in a user selected folder versus forcing the session into the root of the linix partition. For example, after saving the Beta 11's session, on boot the init processor is showing these boot options:

Code: Select all

0 - None
1 - /QuickPup64save-Beta11
2 - /Sessions/QuickPup64save-Beta9
3 - /Sessions/QuickPup64save-Beta10

Can/should this be fixed or reverted to the ability to change the folder on this screen?

All other things seem excellent in behavior

@Clarity
That's weird I tested the shutdown script. The change folder appears on me.

UPDATE: Did you set pmedia boot parameter on your SG2D?

[Clarity]

UPDATE: Did you set pmedia boot parameter on your SG2D?

Not sure if I made any changes to QP's boot stanza. Instead, since beta 8, I have been merely letting the ISO boot to Menu and hit the enter-key at its topmost entry. The system booting will pause when there are more than 1 "QP64 saves" in the /Sessions folder on the HDD. For the post I made I had merely taken the zero option (for pristine boot) which led to getting the shutdown screen you saw after I tailored beta 11 from its pristine state.

Summary:

1. Boot the SG2D USB and select the QP64 beta11 ISO file

2. Hit enter at the QP64 Menu (no changes to any boot stanzas)

3. The system pauses showing "0" - none as well as "1" and "2" for multiple saves found in the /Sessions folder

4. Took "0" for a pristine boot

5. At Shutdown, the screen shown is final screen before shutdown with saving the session

On the SG2D USB in the boot-isos folder along with all the ISO files is this SAVESPEC. I had assume, probably incorrectly, that it is being used by QP64 to know which disk and folder for saves is found. Correct/not?

Code: Select all

SS_ID='Persistence'
SS_DIR='/Sessions'
SS_MEDIA='usbhd'

Next

• I will try the psave and also the pmedia options for a pristine boot, also, to see if that changes the outcome at shutdown.

• Recognizing the potential importance of PSTATE/bootinit, should I include that, as well, with the observed results?

[Clarity]

YES! That was the scenario. Just confirmed.

Next, subsequently, confirmed that selecting RAM only option from the QP64 Menu at boot time, also, leads to same resulting screen at Shutdown.

As committed, PSTATE & bootinit.log attached from 'RAM only option menu boot' for comparative review.

[mistfire]

I made some adjustments on shutdownconfig but I want to fix the xfce icon rendering issue. I reviewed Xubuntu, and Slackware current live builds. Both Xubuntu and Xfce-build slackware builds the icon rendering on system tray fine even the window compositor was enabled. Also it doesn't trigger dbus error message when double click files on desktop. I wonder what's the culprit of these problem on Quickpup for not rendering the system tray properly?

[TerryH]

I have a new laptop ASUS Zenbook, which has Ryzen 7 5800H with integrated GPU. Attempting a new USB frugal install of Quickpup. During boot progress the loading of sfs's is successful, then boot hangs at:
Configuring hardware...

This requires a hard shutdown. So I am assuming that it is the amdgpu that is the issue. Any assistance in how to proceed would be appreciated.

[Dry Falls]

I wonder what's the culprit of these problem on Quickpup for not rendering the system tray properly?

Just a wild guess, but have you tried cycling through the desktop themes to see if there's a noticeable difference? I remember experimenting with mate-panel back when it changed to gtk3 and experienced some of the same problems you describe. The gtk2 desktop theme was the culprit. I've pretty much stuck with adwaita in both Slackware and Puppy since then.

df

[mistfire]

I have a new laptop ASUS Zenbook, which has Ryzen 7 5800H with integrated GPU. Attempting a new USB frugal install of Quickpup. During boot progress the loading of sfs's is successful, then boot hangs at:
Configuring hardware...

This requires a hard shutdown. So I am assuming that it is the amdgpu that is the issue. Any assistance in how to proceed would be appreciated.

@TerryH
I experienced that problem on Ryzen 7 5700G processor. It seems that udev hangs thats why it stuck on that part.

[mistfire]

I wonder what's the culprit of these problem on Quickpup for not rendering the system tray properly?

Just a wild guess, but have you tried cycling through the desktop themes to see if there's a noticeable difference? I remember experimenting with mate-panel back when it changed to gtk3 and experienced some of the same problems you describe. The gtk2 desktop theme was the culprit. I've pretty much stuck with adwaita in both Slackware and Puppy since then.

df

@Dry Falls
Network-manager-applet was gtk+3 still the issue persists.

[Geek3579]

I often use Pure-FTP as a server on my main desktop and gFTP as the client on other Linux OS on the same LAN. I rarely have any issues connecting, but struck one using gFTP in Quickpup. I would not do anything after all parameters were typed into the GUI boxes in turn - the last being the password (and then I hit return...again...and again). However, it did connect if I went about it through the Local --> Open Location menu...adding in the IPaddress as 192.168.1.XXX:21, then user, then password which wasnt a big issue. I wonder if anybody else has had the same issue ??

On the other side of the ledger, Bluetooth connections to my headphones worked well, including immediately reconnecting on a new boot. With Pulseaudio, this is a great audio setup. However, there was the occasional audio dropout using Deadbeef - no idea why, but I might try another player to see if the problem persists.

This is a pup with great potential. Thanks !

[sieger007]

Howdy ...friends in this Litter ...
I am on Fossapup 64. Using this ISO am I supposed to only to a fresh install OR from within an existing Fossap we can take an upgrade route. If poss how can this be done.
Right now with ALSA set up all my sound o/p is coming off PC speakers , those from where the PC Beeps. At least that is what it appears so from the "mono" quality of sound

[mikeslr]

Howdy ...friends in this Litter ...
I am on Fossapup 64. Using this ISO am I supposed to only to a fresh install OR from within an existing Fossap we can take an upgrade route. If poss how can this be done...

If you were driving a Ford Bronco and wanted the advantages of a Toyota 4Runner you would have two paths: take the Bronco to the dealer of Toyota 4Runners and offer the Bronco as part of your purchase price; buy the 4Runner and have both.

Your situation is analogous. Fossapup64 and QuickPup64 are two different vehicles for running applications. They, and many of their components, are not interchangeable. Both are woofed/built to be compatible with a major distro: Fossapup64 with Ubuntu Fossa Focal; QuickPup64 with Slackware64-Current. The 'woofing' process employs some core binaries from 'its' major distro, but substitutes 'infra-structure' unique to Puppys for much more resource demanding infra-structure. So they have that in common. But Ubuntu and Slackware decided to handle 64-bit libraries differently. As a consequence Slacko Puppys and 'Ubuntu-Puppys' must also handle builtin 64-bit libraries differently.
If I interpret your post correctly, you've maded some setting to Fossapup64's alsa. Those are preserved in the Fossapup64_Save you created. That Save can not be used with a QuickPup64.

A Puppy only needs its own folder. Unlike owning both a Bronco and a 4Runner, having both Fossapup64 and Quickpup64 isn't going to set you back a small fortune. Suggest that you download Quickpup64, unpack it, copy its system files into its own folder and run grub2config to create a new boot-menu so that you can boot into both Fossapup64 and Quickpup64. Take it for a spin.

Many applications are not built specifically for one distro: examples, firefox, libreoffice. Like 'after-market' auto gadgets --garmins, radios, wheel-covers-- you can use them in any Puppy. Many of your SFSes, portables and some AppImages will function under both Fossapup64 and QuickPup64.

[sieger007]

I am happy with Fossa64 ( BTW Bronchos are now just about getting aintique prices...dont be surprized if in new couple o years someone sees that rusty bronco outside a house & makes a 2x offer ) ....but for the sound issue. Sound appears "mono" ish how do I get quality sound
This more so for browsers. A tad bit observation

• ff --> sound works with apulse
  vivaldi --> no sound regardless
  palemoon & some other skimmed browsers--> apulse not needed
  but all 3 have "mono" sound quality and also the headphone, master & PCM slider all reduce the sound in retrovol but

  rec958 - think that refers to my audio dev does not have any slider ( see snapshot ) - this is in browsers but if I play a wav it does have and reducing its gradatons will reduce the volume.

  speaker ( in retrovol ) too has no effect in browser

Here is my audio info in detail posted neatly in this bin
https://paste.c-net.org/AllowedVisited

to avoid clutter;.

PS I set auto mute to disable but it wont stand through reboot.

[mikeslr]

If your question about getting better sound relates to your Fossapup64, you should ask that in the Fossapup64 Section.

My own experience and the posts of others is that as a 'Rule of Thumb' Puppys based on Slackware --such as QuickPup64-- often provide superior sound and visual quality. Don't ask me why.

Setting up another Puppy involves both time and effort. But I do recommend after you've got one functioning trying out others. The 'major hurdle', booting into your first Puppy, has been over-come. That first Puppy has builtin tools with which to deploy others. I suggest, however, that grub2-Config, viewtopic.php?t=3360 be installed into Fossapup64 and used. For step-by-step instructions see, viewtopic.php?p=46867#p46867, skip down to the Working with Puppy Linux’s System Files part. Right-Click an empty space on your hard-drive, from the pop-up menu select New>Directory, and give it a name. Follow the instructions for copying your New Puppy's system files into that folder, then run grub2config.
If you are already using grub2config, and the New Puppy is on the same partition as your old, rather than running grub2config again, file-browse to the grub.cfg, and open it in your text editor. Create some empty space. Then copy the stanza for your old Puppy and paste it into that space. Then all you usually have to do is edit the copy: change the title and replace references to old Puppy to that of the New.

[mistfire]

QuickPup64 22.01 BETA 12 released

Changes:
* Linux kernel 5.18-lxpupsc (thanks @peebee )
* Engrampa replaced file-roller
* Atril replaced evince
* Under-the-hood overhaul
* Package management overhaul
* More bugfixes

Download: https://drive.google.com/file/d/1sE73sJ ... L24OA1HNa5
MD5 Checksum: 7a6c9d6629d3323c94e5ca573ce7691e

[mistfire]

QuickPup 22.01 BETA 13 released

Changes:
* Under-the-hood bugfixes

Download: https://drive.google.com/file/d/1X4-zTd ... YYvjuzUOLI
MD5 Checksum: 60dd8bca6a051cfb7566d88e97c81192

[mistfire]

QuickPup64 22.01 BETA 14 released

Changes:
* Linux kernel 5.18.3-lxpupsc (thanks @peebee )
* Updated packages

Download: https://drive.google.com/file/d/1gKW5Xe ... GbkRmgpo1t
MD5 Checksum: 6549fca967773581f5e6fe9f80009f51

[Clarity]

10 days late but Happy Birthday to this Great distro!

Its FAST & Stable!

And its package management approach is genius.

Birthday Belated4.gif (230.43 KiB) Viewed 21516 times

[mistfire]

10 days late but Happy Birthday to this Great distro!

Its FAST & Stable!

And its package management approach is genius.Birthday Belated4.gif

Thanks @Clarity

[mistfire]

QuickPup64 22.01 BETA 15 released

Changes:
* Linux kernel 5.18.6-lxpup (thanks @peebee)
* Fixed builtin app missing deps which render the builtin apps broken
* Puppy memory management is back. Automatcally cleans system when free space was low.
* Pupmode notification. It gives notification to the user if odd numbered PUPMODE was used.
* Fixed puppy automatic shutdown
* More bugfixes

Download: https://drive.google.com/file/d/1lbKPDs ... 8CJJaLXWcq
MD5 Checksum: 9d86b79736e0fb9ece331a86e271971b

[mistfire]

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]

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]

@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]

@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]

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]

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:

1. The filesystem on the USB is ext4.

2. Boot SG2D and select QP vbeta17.

3. 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.

4. 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]

#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:

1. The filesystem on the USB is ext4.

2. Boot SG2D and select QP vbeta17.

3. 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.

4. 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]

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]

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]

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