Discussion, talk and tips
https://forum.puppylinux.com/
Audio produces a very low level distorted sound. This might be due to QEMU, but its a problem I have never encountered before.
@Geek3579 and @Clarity
Bookworm Pup64 10 and Vanilla Dpup 10 share the same kernel, firmware and Pipewire audio infrastructure.
When using QEMU in Vanilla Dpup 10, do you also observe audio distortion ?
If I understand correctly, Bookworm Pup64 is running inside QEMU, as opposed to [any Puppy] running inside QEMU on top of Bookworm Pup64. I think the real question is, what distro is this QEMU running on. What QEMU version is this, which sound card was emulated and which driver was used?
(Maybe try -audio driver=alsa,model=ac97 and -audio driver=alsa,model=hda?)
Hello @radky,
i like your distro much, but i have a problem with compiling. When i try i got the message - configure: error: C compiler cannot create executables - and all stops! All Compilers are in usr/bin -whats wrong? In other Vanilla-Pup-Distros there ais no such problem. Greetings from Austria
@BeNeu Try apt install libc6-dev. If it doesn't solve the problem, attach config.log (should be in the same directory as ./configure) and it should say why the compiler failed.
Dear radky
Thanks you for this very application-rich dpup build.
One little issue I noticed is that in ROX the color of the script icons does not change depending on the execution bit from green to black as in other puppies, vanilladpup included.
Regarding vanilladpup, which version of vanilladpup your puppy is based on?
I'm asking because I did not feel like recompiling all the needed drivers and setting so I renamed one vanilladpup savefile from beta5 which was updated and worked OK!!!
(BTW this looks like a woof-CE bug if any puppy can try to update any other puppy without any rudimentary compatibility checking)
Regarding vanilladpup/updates etc, I would also like to ask if this puppy, like the F96 series, will be an impossible to reproduce puppy ie without a source code file or repository.
Without doubting you intentions or implying anything, I should admit that this makes me a bit uneasy for major use in this day and age.
Thanks again for your efforts
Hello,
i installed libc6-dev - the problem is still there. No Compiling.. i attached my config.lg .Greetings
Hi all, and especially amethyst
I am please to report that the Save2SFS component of the built-in nicOS-Utility-Suite appears to function completely even though BookwormPup64 employs Overlays rather than AUFS. 
What I did:
Added a couple of 'must have' applications: masterpdfeditor, lazpaint, xnviewmp, pwidgets; a couple new icon sets, a new wallpaper.
Set xfe to open with a tree and two panes; and changed the programs it would use by default.
Deleted any rox bookmarks to /mnt/home and folders under it.
Unloaded LibreOffice SFS and rebooted (SFS load does not load 'on-the-fly' to load. I guessed it wouldn't work to unload on-the-fly either. Anyone know?)
Ran nicOS-Utilities-Suite's Save2SFS, selected '2: Save 2 ydrv'
A ydrv was created. Rebooted without loading the SaVeFolder (Choosing '0 None')
All my added applications and customizations were in place and functioning.
There one other thing I did but am pretty certain was NOT necessary. Choice '4' of the GUI reads 'Exclude existing adrv and ydrv', emphasis supplied. As-is, that fine if I want to create an new adrv or ydrv. But what if I already have both and want to update one and leave the other AS-IS? I'm used to working with Save2SFS when I've already created a ydrv (holding apps I expect never to update), want to UPDATE an adrv and not have it include the applications already in the ydrv. What I do is rename the ydrv to '0ydrv' and reboot. Working 'pre-2nd cup of coffee' I renamed adrv to 0adrv before rebooting to create the ydrv.
@ amethyst, is there some easier way to achieve this objective: Update or Create a drv without it capturing the contents of the other drv? My gut feeling is that there isn't for the same reason Save2SFS works under both Overlays and AUFS.
Read the above from top to bottom, ignoring the false 'dpup-save null' employed to generate the choices --including None-- at bootup,
Overlay's Save-structure on Storage is almost identical to that when AUFS is employed. I think (or if IIRC) the 'Work' folder is a substitute for AUFS's 'Changes currently in RAM' while the 'Upper Folder' is the analog for a Save under AUFS. On boot-up employing a Save, the Upper Folder is mounted. Subsequent changes are written to the Work folder; and if a Save is executed the contents of the Work Folder are written to the Upper Changes Folder. [Someone who knows, please confirm, or deny and clarify.
Amethyst, I can mount the initrd and upload a copy to mediafire if you still think it necessary. But my guess is that the differing code doesn't matter. What will be in RAM is identical which is why Save2SFS works. This is what initrd in RAM looks like on bootup without a Save being mounted.
This is still pre 2nd cup of coffee and I suspect my mental road-map of what a remaster involves fails to anticipate road-blocks and sees demons which may not exist. At any rate, wouldn't you be better off exploring dimkr's 32-bit vanillaDup, https://github.com/vanilla-dpup/release ... up-x86-9.3. If I'm not mistaken, it also only uses Overlays. If necessary, I think all the tools I mentioned on this thread, viewtopic.php?t=7077 can be installed.
mikeslr wrote: ↑Tue May 16, 2023 1:37 pmHi all, and especially amethyst
I am please to report that the Save2SFS component of the built-in nicOS-Utility-Suite appears to function completely even though BookwormPup64 employs Overlays rather than AUFS.
What I did:
Added a couple of 'must have' applications: masterpdfeditor, lazpaint, xnviewmp, pwidgets; a couple new icon sets, a new wallpaper.
Set xfe to open with a tree and two panes; and changed the programs it would use by default.
Deleted any rox bookmarks to /mnt/home and folders under it.
Unloaded LibreOffice SFS and rebooted (SFS load does not load 'on-the-fly' to load. I guessed it wouldn't work to unload on-the-fly either. Anyone know?)
Ran nicOS-Utilities-Suite's Save2SFS, selected
Choose drive to create.png
A ydrv was created. Rebooted without loading the SaVeFolder (Choosing '0 None')All my added applications and customizations were in place and functioning.
There one other thing I did but am pretty certain was NOT necessary. Choice '4' of the GUI reads 'Exclude existing adrv and ydrv', emphasis supplied. As-is, that fine if I want to create an new adrv or ydrv. But what if I already have both and one to update one and leave the other AS-IS? I'm used to working with Save2SFS when I've already created a ydrv (holding apps I expect never to update), want to UPDATE an adrv and not have it include the applications already in the ydrv. What I do is rename the ydrv to '0ydrv' and reboot. Working 'pre-2nd cup of coffee' I renamed adrv to 0adrv before rebooting to create the ydrv.
@ amethyst, is there some easier way to achieve this objective: Update or Create a drv without it capturing the contents of the other drv? My gut feeling is that there isn't for the same reason Save2SFS works under both Overlays and AUFS.
more to follow by editing in a couple of minutes....
Use option 2 (save2adrv), this will include the contents of any existing adrv, contents of any existing save file/folder and any changes to the session (not saved yet). This will not include the contents of any existing ydrv. So you choose save2adrv everytime you make changes. Now at some stage you may find that your adrv gets too big for your liking, then you do the save2ydrv option (which will replace your existing ydrv and existing adrv). Thereafter you do the save2adrv again...and so on.
The last option (excluding adrv and ydrv) was brought in to cater for the scenario where you have an existing adrv and ydrv which have nothing to do with system changes (like the adrv representing a browser). This last option will then save the contents of any save file/folder and any changes of the session to a new adrv. In this case you will want to do something with your old adrv (the browser).
Did a manual frugal install with a grub4dos computer.
I'm in it now. Everything looks great and it's fast.
This is the menu.1st entry I used.
Code: Select all
title Puppy Linux BookwormPuppy in sda1 dir BookwormPuppy
rootnoverify (hd0,0)
kernel /BookwormPuppy/vmlinuz pmedia=ataflash psubdir=BookwormPuppy
initrd /BookwormPuppy/ucode.cpio /BookwormPuppy/initrd.gzI don't really understand the "ucode.cpio" part but imitated what was on the .iso file.
Dan
edit: I just installed Chrome and opened it with the default .desktop file and it automatically knew to run as "spot" and opened.
Everything looks great.
When I implemented overlay support in woof-CE, I made sure pup_rw and pup_ro1 behave the same as under aufs. Changes go to pup_rw in PUPMODE 5/12 or to pup_rw but copied to pup_ro1 when asked to save in PUPMODE 13.
The only differences compared to aufs are:
1. The save file/folder contains two directories, upper and work. overlay needs a "working directory" in the same file system and it cannot overlap with the overlay mount point. Therefore, the save file/folder contains two "sibling" directories and pup_ro1 is a symlink to upper.
2. save2flash doesn't wipe the contents of pup_rw after saving to pup_ro1, because behavior is undefined if lower layers are modified while overlay is still mounted (this causes I/O errors and eventually corruption)
3. Dynamic SFS loading is limited to PUPMODE 5 and 13
4. The sfs_load GUI is very simple and primitive - currently, nobody maintains sfs_load (a ~2.5K lines long script) and it's very hard to implement overlay support within the existing script, so sfs_load just calls sfs_load.overlay, a super simple replacement
As long as you don't mess with the save file structure (mount it manually and start creating files and directories at the root rather than under /upper), the overlay vs. aufs thing should be transparent to you.
@retiredt00 wrote:
One little issue I noticed is that in ROX the color of the script icons does not change depending on the execution bit from green to black as in other.
Vanilla Dpup provides several 'light' GTK themes which work quite well with the ROX color options implemented in Vanilla Dpup. However, in addition to light GTK themes, BW64 provides several dark themes -- in which case, the default ROX colors will produce poorly-visible or unreadable foreground elements when viewed on the underlying dark background. Consequently, BW64 defaults to 'neutral' ROX colors to provide readable foreground elements in both light and dark themes.
@retiredt00 wrote:
Regarding vanilladpup, which version of vanilladpup your puppy is based on?
BW64 is produced by dimkr's Woof-CE bookworm build scripts, providing a Puppy distro based on Debian 12 binaries. Consequently BW64 10 and Vanilla Dpup 10 share the same infrastructure based on Debian 12 binaries. BW64 (as released) is an Xorg Pup whereas Vanilla Dpup is available in Xorg and Xwayland variants.
@retiredt00 wrote:
Regarding vanilladpup/updates etc, I would also like to ask if this puppy, like the F96 series, will be an impossible to reproduce puppy ie without a source code file or repository.
Soon after Debian 12 matures and arrives at 'Full Freeze' status, the current plan is to release BW64 Beta2 (hopefully) and at that time also release the corresponding devx, kernel sources, and pet package repository used to supplement the base Woof-CE bookworm build.
However, that does not mean a user can click a Woof-CE button and generate a distro identical to BW64. Specifically, the current Woof-CE bookworm build scripts provide a basic JWM Puppy based on the jwmconfig environment. This follows standard protocol and work quite well. However, anyone who prefers the XFCE, LXDE, JWMdesk or other desktop environment must customize the Woof-CE output to produce a functional alternative Puppy configuration.
In the current case of BW64, my personal choice is to replace jwmconfig and ptheme with the JWMdesk environment and this is not a simple drop-in-replacement. Specifically, jwmconfig and ptheme are intimately involved in the default desktop environment and removing/replacing them requires many adjustments outside the realm of Woof-CE. That said, the woof-build.conf and DISTRO_PKGS_SPECS and supplemental pet package repository will be available.
Hello,
i installed libc6-dev as you wrote Apt-get update,apt install libc6-dev. Then i reinstalled it with synaptic and it worked! But got a new error "
C preprocessor "/lib/cpp" fails sanity check ". Tried the same as with libc6-dev , but did not word Attached the log-file. Thank you for Help
Always a good idea to run:
checkdeps -system
on a new build - attached is what is currently reported FYI
BeNeu wrote: ↑Tue May 16, 2023 4:13 pmHello,
i installed libc6-dev as you wrote Apt-get update,apt install libc6-dev. Then i reinstalled it with synaptic and it worked! But got a new error "
C preprocessor "/lib/cpp" fails sanity check ". Tried the same as with libc6-dev , but did not word Attached the log-file. Thank you for Help
Kernel headers are missing, try apt install linux-libc-dev
It only works for packages installed via PPM, and PPM doesn't understand concepts like package A that depends on ((B) and (C or D)). The output of this tool is almost guaranteed to be a false positive.
EDIT: this script doesn't even check for missing dependencies, a missing feature can't be broken 
deadbeef in Vanilla Dpup (built by the deadbeef petbuild) works with PipeWire, via either the alsa (the default) or pulse plugins. Just put deadbeef in PETBUILDS, under _00build.conf.
Hello, Kernel headers are missing - that was it. Compiling worked. Thank you!!!
radky wrote: ↑Tue May 16, 2023 3:58 pm@retiredt00 wrote:
One little issue I noticed is that in ROX the color of the script icons does not change depending on the execution bit from green to black as in other.
Vanilla Dpup provides several 'light' GTK themes which work quite well with the ROX color options implemented in Vanilla Dpup. However, in addition to light GTK themes, BW64 provides several dark themes -- in which case, the default ROX colors will produce poorly-visible or unreadable foreground elements when viewed on the underlying dark background. Consequently, BW64 defaults to 'neutral' ROX colors to provide readable foreground elements in both light and dark themes.
Thank you for the explanation
But does this mean that this feature is permanently inactivated or there is some ROX configuration file change that can reactivate it (how?), if the user prioritizes the specific functionality over theme variety/quality?
Regarding the vdpup/BW64 relation (appologies for not quoting here) your description may suggest manual modifications of a vdpup version rather than denovo building. Thus I think would be helpful to know which vdpup version in case consecutive vannilladpup updates solve or introduce issues
Yes, and is one of the reasons I delayed further testing of VPUP. It, v10, gave same result.
This specific audio problem is NOT seen in any other forum distros, tested thus far. Although I DO RECOGNIZE that each distro and their timetables deliver with components that make them different from each other. As such, my comparisons in the prior sentence should be disregarded for several reasons and this distro (v10, too) may dictate a new stanza.
I have NOT tested this on bare metal as of yet as I am awaiting its next level of progress as QEMU exposes something else in several areas. Namely, if the ISOs file is attempted to be booted launched by either SG2D USB or Ventoy USB, it will fail to boot.
Same found on bare-metal when tested via both boot launch services. I could post those results, but ... well. you've seen recent behaviors.
I test almost all forum Pups to mimic as much as possible my BIOS bare-metal test PCs. The stanzas, I use are generally posted and they ALL use the same basic stanza making it easy for the developer to see EXACTLY what is seen as the VM is the same no matter where or who runs it.
The tested stanza here is as follows:
Code: Select all
root# echo 'show QEMU version'
show QEMU version
root# qemu-system-x86_64 --version
QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
root#
root# echo 'the VM defined is ...'
the VM defined is ...
root# qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'Vanilla v10 in QEMU' -cdrom vanilladpup-10.0.158-xwayland.iso
root#
root# echo 'the audio issue is the same as seen in BW64'
the audio issue is the same as seen in BW64
root#For this current BW64 beta, the same stanza is used by renaming the '-cdrom' parameterr' (I am sure everyone knows this, though).
Hope this is helpful to recreate.
P.S. Although I suspected that it "may" be related to some changes that could be required for the stanza's, those changes, up til now, had not been neeeded. The newest audio changes incorporated may indeed suggest VM stanza changes to take advantage. THUS, I would :Welcome" if anyone would share their VM stanza(s) if they found a workable VM stanza taking advantage of the recent WoofCE OS system changes.
As developers know, a stanza is a replica of a real PC. So showing their stanza shows the PC (virtual) being tested.
retiredt00 wrote:
But does this mean that this feature is permanently inactivated or there is some ROX configuration file change that can reactivate it (how?), if the user prioritizes the specific functionality over theme variety/quality?
The Rox configuration options are in the following file:
/root/.config/rox.sourceforge.net/ROX-Filer/Options
Simply replace the above BW64 Rox configuration file with one from a Puppy that has your preferred Rox configuration.
retiredt00 wrote:
Regarding the vdpup/BW64 relation (apologies for not quoting here) your description may suggest manual modifications of a vdpup version rather than denovo building. Thus I think would be helpful to know which vdpup version in case consecutive vannilladpup updates solve or introduce issues.
BW64 is a product of dimkr's Woof-CE bookworm build scripts (with post-Woof customization as indicated in the prior post). As such, it is not Vanilla Dpup and it is not a derivative of Vanilla Dpup. Rather, BW64 (release 10) and Vanilla Dpup (release 10) share much of the same infrastructure based on dimkr's choice of configuration options available in (1) the public Woof-CE bookworm build scripts and (2) his personal build scripts for Vanilla Dpup. Both build systems produce usr-merged dpups based on Debian 12 binaries and both employ the overlay file system rather than aufs. Currently, BW64 and Vanilla Dpup use the same kernel, kernel sources (when released) and firmware. So, yes, BW64 and Vanilla Dpup are quite similar, but BW64 is indeed a primary Woof-CE build - not a modified remaster of Vanilla Dpup.
That is my understanding.
Thus, though there is some similarity, the distros emerge differently in features and subsystems.
@radky, This PUP is very nicely packaged. Thanks for what you have accomplished, thus far. We'll continue testing to report findings that could be useful
I had preserved the SaveFolder which existed before I ran Menu>Utilities>nicOS-Utilities-Suite's Save2SFS modules. See here regarding the preparation, viewtopic.php?p=89294#p89294. After moving the ydrv created by that procedure and returning the SaveFolder to a location where it would be used, I made some changes (basically the Wallpaper, pwidget's theme and the icon set I thought was most pleasing with those), rebooted Saving those changes. After the reboot I ran Menu>Utilities>nicOS-Utilities-Suite's Alternate Remaster. 'Though that module offers the opportunity for the User to edit the to-be-created /root/, /etc/ and other folders, I declined and just Clicked OK.
The Remaster process went smoothly. As far as I can tell, the Remastered puppy_dpup_10.0.sfs included almost everything a remaster is supposed to, and nothing it wasn't. firefox-esr --which is in the adrv-- was NOT included. The almost relates to two things I did not expect. (1) The first run routine had to be completed. Even though the Easter US was now default, the wifi network had to be chosen and its password entered. Conky again was displayed. This time I used radky's instructions (remove execution permissions) to disable it.
IIRC, for the Remaster not to run the First-Run routine, a flag-file has to be copied to /var/local during the above opportunity you have to make changes. And as I hadn't used radky's instructions to disable conky, perhaps something recreated it in /root/Startup.
I've already rebooted a couple of times after making minor changes. The problem I encountered here, viewtopic.php?p=89314#p89314 has not surfaced. 
Yet, 
. Hopefully, never. 
For now I'll use this rather than revert to the system employing a ydrv. As I mentioned, I populate ydrvs with applications I never expect to upgrade. So with those applications in the Remaster, my objective has been met and I don't have a need to create a ydrv.
Still, I would like to get to the bottom of the Save problem I noted above.
Hi dimkr,
I clicked the thank you button next to your post here, https://www.forum.puppylinux.com/viewto ... 305#p89305. But that didn't seem sufficient. As someone who has had his doubts, let me take this opportunity to thank you not only for your explanation in that post but for the hard work you've put in so that Puppys employing Overlays lack nothing essential compared with those employing AUFS. 
And thanks again, Radky, for this implementation: a Puppy with Rox as File-manager, your enhancements in JWMDesk, synaptic package manager Plus Puppy Packmanager (for uniquely Puppy Packages), and able to run many current AppImages OOTB. An operating system which is light on resources and easily customizable.
As for the problem I encountered here, https://www.forum.puppylinux.com/viewto ... 314#p89314 it may be that I did something to generate an error that was captured by the creation of the ydrv. So far --knock wood -- the alternative, remastering, has worked flawlessly with a SaveFolder thru several Saves and reboots. Unless anyone has suggestions, I'll likely put off any further exploration of that problem unless and until it surfaces the next time I create create a ydrv, or update the adrv.
Clarity wrote: ↑Tue May 16, 2023 7:49 pmYes, and is one of the reasons I delayed further testing of VPUP. It, v10, gave same result.
This specific audio problem is NOT seen in any other forum distros, tested thus far...QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
The tested stanza here is as follows:
qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'Vanilla v10 in QEMU' -cdrom vanilladpup-10.0.158-xwayland.iso
the audio issue is the same as seen in BW64
For this current BW64 beta, the same stanza is used by renaming the '-cdrom' parameter' ...
@Clarity
Please see following post:
@dimkr suggested defining the QEMU audio parameter in the following format:
Code: Select all
-audio driver=alsa,model=ac97 and -audio driver=alsa,model=hdaIs the above suggestion audio format helpful when implemented in your QEMU stanza ?
@mikeslr
The alternative remaster script excludes all additional drives. When I use the remaster scripts, I prefer to use the alternative method too. More flexible and the additional drives and any other loaded sfs's do not come into play. Did you try the classic remaster script and see if that works too? Clicking the help button of any of the utilities of the suite provides valuable information how it works. Anyways - good to see that the utilities are still useful with overlays.
radky wrote: ↑Tue May 16, 2023 3:58 pm@retiredt00 wrote:
One little issue I noticed is that in ROX the color of the script icons does not change depending on the execution bit from green to black as in other.
Vanilla Dpup provides several 'light' GTK themes which work quite well with the ROX color options implemented in Vanilla Dpup.
Yes, this is why it doesn't provided any dark themes. GTK+ 2 doesn't work well with dark themes because many applications assume that the background should be light (for example, ancient GTK+ 2 web browsers). GTK+ 3 added the light/dark theme knob (and it's supported in GTK+ 4 as well), but ROX-Filer is a GTK+ 2 application, so you can get pretty much all applications to play nicely, minus ROX-Filer and other GTK+ 2 applications - I see Bookworm Pup64 includes several of those.
Hi @radky
Yes, I did see the entry offered. And understood them as there other ways to discover the various audio options, too.
But, I was hoping to see his QEMU stanza as that defines the particular virtual PC he is testing with. His virtual PC is probably different from the ones we are testing with. The one we are using are BIOS version. I believe he test with a UEFI virtual PC for his tests, as well and wanted to be sure...and is the reason I asked. I UEFI virtual PC would be in line with the modern PCs of today. With Wayland and Pipewire coming into common use, a UEFI PC would be a practical choice....AND maybe a better choice for these modern WoofCE PUPs.
This info would be helpful, if provided to understand if our test platforms are consistent.
BTW: The recommendations offered do not change behaviors reported in this or any current Vanillas from last weekend.
This is easily replicated using the VM stanza I offered...if there is any interest. Otherwise, the problem may be carried forward to GA.
@radky Thanks for addressing my issues. Speaking about simple-scan I noticed that this application has no JWM window decoration but rather has WM features like title bar, borders, menus and resize/close buttons built in. In effect it doesn't even need a window manager. Very interesting, but what are these windows? I've seen them also in Vanilla Dpup11. Some of their features work well in BW64, others hardly and some not at all (Resize and Move menu items).
Another example of such unusual window I found in Gcolor3 (in the 'Graphic' menu. A very useful tool!). For my private use I added JWM decoration, which IMHO increases usability although it creates an odd bastard with 2 title bars...well, there is no title in the original layout 
I'll play with it and see how I like it.
MochiMoppel wrote: ↑Wed May 17, 2023 10:57 amI've seen them also in Vanilla Dpup11. Some of their features work well in BW64, others hardly and some not at all (Resize and Move menu items).
Many (most?) GTK+ 3 and all GTK+ 4 applications default to CSD. apt install libgtk3-nocsd0 plus export export LD_PRELOAD="$LD_PRELOAD:libgtk3-nocsd.so.0" in ~/.xinitrc should force GTK+ 3 applications to let the window manager draw decorations, but it won't work for GTK+ 4 and some applications use CSD anyway.
(JWM has at least one known bug related to CSD, i.e. https://github.com/joewing/jwm/issues/540. If you want to get CSD to work in Puppy with JWM, start here.)
(CSD is the default under Wayland and most GTK+ 3 applications will be gone by the time a stable release is out, so the comparison against Vanilla Dpup 11.0.x, which is pure Wayland, is apples vs. oranges.)