Moderators: 666philb, Forum moderators
@retiredt00 I see the same thing. I went to compile netmap so I can compile QEMU 7+ with network support (I think).
So far I am seeing the same type of errors and have not been able to compile successfully against this kernel's sources.
This will be fixed.
This now the chance to throw in ideas for the final release name. I may or may not use any of them.
This began as an answer to bigpup's Question which I'll paraphrase "If you don't have a web-browser, how do you get one?"
You don't need a web-browser now that F96 has Quickpet. Quickpet uses the built-in wget. Unfortunately, unlike Bionicpup64's Quickpet, F96's Quickpet doesn't offer any.
What is needed is to upload one --and only one-- to the repo Quickpet accesses. [More than one may be nice to have, but isn't necessary and would require additional maintenance of the repo]. I would suggest that the one be built around one of MikeWalsh's portables. Most are updateable relieving even the burden of repo maintenance. Once there's a SaveFile/Folder a portable initially located in /opt can be externalized in two quick steps: (1) drag folder to /mnt/home, select Move; (2) drag folder back to /opt and select Link(relative). All setting and customizations are preserved; updates of browser no longer require a Save to preserve them; and web-cache is re-directed out of RAM.
Pick one. I'll built it and upload it to mediafire. What I can't do is upload it to the repo that Quickpet will access.
[I've seen a notice when attempting to start some application that hadn't yet been installed to use Puppy Package Manager. Something like that --but directing to Quickpet-- could be the 'Default Web-browser' until an actual Web-browser is obtained and set as default. What I can't do is write it].
The existence of Quickpet changes what has to be in either the core/base sfs or provided by an 'alphabet' drive. Why include applications that aren't wanted by some when others who want them can easily install them? Fleshing out Quickpet's repo means less complications in Woof's Recipe, less transmission required by Users, and I suspect less over-all on line storage needed.
Maybe to avoid confusion F-96 needs it own repo? Edit: Maybe not. I've just booted into Fossapup-9.5. Its Quickpet offers web-browsers. Likely, they date from 2020 and IIRC were downloaded as pets to be installed (maybe SFSes). Either way, difficult to update. Maybe all that is necessary is to replace the offering in the repo. FROM experience, there are no web-browsers which will run in F-96 that won't run under fossapup64-9.5.
IIRC, there was mention that using some applications built for fossapup64-9.5 would be problematic under F-96. Which? That hasn't been my experience. But if so, the easy solution is to replace those on the repo. I don't know of any application built for F-96 which won't run under fossapup64-9.5. [Maybe a 'legacy' repo is needed into which deprecated applications can be moved].
Greater use of Quickpet solves most of the issues fr-ke raised here, https://www.forum.puppylinux.com/viewto ... 237#p77237. But it would also solve a problem I encountered. I never use Conky. If and when I want that information I can easily get it. But unless I remove Conky it just creates what I consider a displeasing cluttering on my desktop which interferes with the display by pwidgets that I do want. I used to be able to just remove it from Autostart. But under F-96 I've discovered that while that works when using a SaveFile/Folder if the latter is converted to an adrv/ydrv, Conky is back. [I think files in /etc re-install it to Startup]. Conky has been placed in ydrv. To get rid of Conky I have to mount and rebuilt ydrv removing it from both /etc and Startup. Why do I have to spend a half-hour removing something I didn't want in the first place.
Conky isn't like other applications whose display can be turned off with Menu>Setup>Menu Manager.
@ fr-ke: Removing builtin Applications is mostly a waste of your time. See, viewtopic.php?t=692&sid=5e6deb390a84c48 ... 3174eadfb1. It makes far more sense to just turn off annoying Menu entries.
@ radky, Menu Manager is one of the important applications to have available when you are initially customizing a Puppy. For some reason, its application desktop file includes the argument NoDisplay=true so it doesn't appear on the Menu. Newbies won't know its available. Unless they know of its existence, know to edit /usr/share/applications/menumanager.desktop they'll have to start JWMDesk and click the Menu tab; and they probably won't know to do that either. It may be that once a user is satisfied with customizations then Menu Manager will rarely be needed and it can be used to 'turn itself off'. But until then IMHO it should be 'in your face' available.
radky you build great applications. I've frequently recommended them. I've even argued that a newbie friendly Puppy with a modern appearance should have both JWMDesk and PupControl with all the other menu entries to applications accessible thru JWMDesk and PupControl not displayed on the menu rather than the 'old-style' with menu entries for all applications. But what we now have is both, and an even more cluttered and confusing menu.
We are no longer rushing to meet some DistroWatch deadline. Thanks primarily to radky's and rockedges' hard work* at this stage we have a Fossapup which has greater potential than many of us envisioned when we started. I recommend that we take the time so that when it is published it will be the best we can offer: newbie friendly -- easy to use, easily customizable, and easy for both devs and users to maintain.
* and an occasionally, when needed, assist from dimkr and others
For some reason, its application desktop file includes the argument NoDisplay=true so it doesn't appear on the Menu
I had to also change the Categories=X-Setup-wizard to Categories=X-Setup for the menu option to appear at all.
The plan is not to maintain F96 but instead focus on bringing all of it's technology to the woof-CE recipe for Jammy. And let Jammy be the target distro that will be the very best we can put together and offer.
You're making F96 sound all transitional like Windows 8.1 and Windows 98. I've got a feeling that F95 and F96 end up hanging around like Windows XP.
Maybe not, but I've been using fossapup for 3 years, and it's still got two years of Ubuntu support left in the repo. And on all the machines that I have it installed, I'm guessing F95 will keep working until they quit, or all kinds of major library/QT/whatever changes are implemented universally forcing it's obsolescence.
Especially around here, think about how many people are still using Bionic and Xenial.
geo_c
Old School Hipster, and Such
@geo_c Yes I see we should reword that statement.
Of course we can keep it tuned and I also will probably use it for a few more years at least. Also the Jammy project will not be fully ready for awhile so a Fossapup64 (F96) will have a long run.
But what is forgotten is the amount of focused work it takes to make these changes, and then make them change again. Getting the details right is important and are far easier to implement than making system mechanism changes back and forth. So decisions will be made to keep moving forward towards release.
rockedge wrote: ↑Sun Jan 01, 2023 11:06 pmFor some reason, its application desktop file includes the argument NoDisplay=true so it doesn't appear on the Menu
I had to also change the
Categories=X-Setup-wizardtoCategories=X-Setupfor the menu option to appear at all.The plan is not to maintain F96 but instead focus on bringing all of it's technology to the woof-CE recipe for Jammy. And let Jammy be the target distro that will be the very best we can put together and offer.
Ditto what geo_c wrote. I'm one of those who only with F-96 have I started using 'Fossa' as my 'daily driver' rather than Bionicpup64. Which means that I really like it. Jammy will bring a new set of issues.
After reading your post I dissembled the PupMenu-6.3.1.pet. I hadn't realized how much had changed since, I think, 6.2. What's happened is that it now includes (1) PupMenu, just an application which would add/remove the 'No Display' argument from desktop categories; (2) PupMenuEdit -- a tool for more completely editing desktop files; and (3) tools I think mostly used under Lxde: Manage-Favorites, pBookmarks, pFavorites, pRecentFiles, and pRun. I'm not complaining. I just didn't know. But one of the effects of having multiple applications in a pet is that when you dissemble it and re-assemble it using dir2pet, dir2pet's routine for defining a category isn't used; i.e, not written to the multiple desktop files or any. In order to change categories I'd have to edit desktop files.
I like how Puppys' Menus have slide out sub-categories. But that does complicate defining categories. Surprising some sub-categories you would expect to exist, don't. FWIW, I think PupMenu might just as well be assigned to Desktop rather than Setup. I think of it more as something used to customize rather that to effect installation in either of installations meanings.
Fossapup Deluxe
geo_c
Old School Hipster, and Such
Name suggestions:
Fossapup64 10.0
Fossapup64-update 9.5
Fossapup64-updated 9.5
Fossapup64-improved 9.5
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected 
Not sure if you missed this from @rockedge
The plan is not to maintain F96 but instead focus on bringing all of it's technology to the woof-CE recipe for Jammy. And let Jammy be the target distro that will be the very best we can put together and offer.
Hope this is helpful
Clarity wrote: ↑Mon Jan 02, 2023 3:03 pmNot sure if you missed this from @rockedge
The plan is not to maintain F96 but instead focus on bringing all of it's technology to the woof-CE recipe for Jammy. And let Jammy be the target distro that will be the very best we can put together and offer.
Hope this is helpful
The reason why I'm asking this is because I know that peebee requires some debian components for his new 32-bit ubuntu puppy builds. It's a bit of a mixed bag when it comes to the new 32-bit ubuntu versions, so someone needs to confirm if this will be the case with Fossa too. Bionic Pup 32-bit was still built from a "pure" ubuntu base as far as know.
@amethyst As soon as later today I will begin a build run of a 32 bit Fossa and see what it will take to have a purely Ubuntu based version.
I know that KLV can be 32 bit based on Void Linux like VoidPup32, Void Linux still fully supports 32 bit.
I will report on how the build turns out and what it will take going forward.
@Clarity I have reconsidered what I stated and changed my mind, that indeed F96 can be maintained and tweaked as far as we can take it. Jammy's will be the next to benifit from a long Fossapup64-9.6-CE (F96_4-radky6-CE) run.
@rockedge, does @PeeBee's GIT post here ease your effort?
Hope this helps
Why not just build a 32-bit Puppy using Debian packages? The Ubuntu 32 bit repos have a very small selection of packages (mostly Wine and Steam plus dependencies), some Ubuntu packages are broken because they depend on systemd (while Debian still has sysvinit-style init scripts Puppy understands), and you lose compatibility with both distros when the package list is mixed like this. A 32 bit 9.6 wouldn't be very practical IMO.
dimkr wrote: ↑Mon Jan 02, 2023 4:40 pmWhy not just build a 32-bit Puppy using Debian packages? The Ubuntu 32 bit repos have a very small selection of packages (mostly Wine and Steam plus dependencies), some Ubuntu packages are broken because they depend on systemd (while Debian still has sysvinit-style init scripts Puppy understands), and you lose compatibility with both distros when the package list is mixed like this. A 32 bit 9.6 wouldn't be very practical IMO.
Yes that does seem a better option as for now but eventually 32-bit will be phased out completely. A quick google suggests that ubuntu will still support 32-bit until 2024 at least and debian until 2026 at least. Don't know about slacko. The main thing is of course the browsers but big browsers like Firefox and Chromium still support 32-bit. The thing is we are trying to hang on to our old machines and 32-bit does run better on most of them. I have checked the performance of a debian based 64-bit system on my laptop and there is a difference on this machine (64 -bit is okay but 32-bit runs lighter and better). Have to get a faster machine sometime and switch to 64-bit. 
Which 64- bit Puppy distribution runs best with an old computer (say 2005, 2GB RAM Duo processor 2ghz)? Have tests been done in this regard? Maybe I should start a new topic on this.
@dimkr , @amethyst Going with the Debian approach definitely seems the best way to end up with a nifty 32 bit OS. I'll give that a go instead of the Fossapup32. The advice is sound.
Which 64- bit Puppy distribution runs best with an old computer (say 2005, 2GB RAM Duo processor 2ghz
Haven't done any bench-marking, but do have 3-4 of that category laptops running Fossapup64 9.5 quite well. Bionic should do well too, and don't overlook the new F96 which is really slick. Upping the ram to 4gb will help a lot, if you can.
wizard
Big pile of OLD computers
But under F-96 I've discovered that while that works when using a SaveFile/Folder if the latter is converted to an adrv/ydrv, Conky is back. [I think files in /etc re-install it to Startup]. Conky has been placed in ydrv. To get rid of Conky I have to mount and rebuilt ydrv removing it from both /etc and Startup. Why do I have to spend a half-hour removing something I didn't want in the first place.
Whiteout files (deleted files like .wh.concystart) only work in the R/W layer (SaveFile/Folder).
An empty "/root/Startup/conkystart" prevents Conky from starting, even if it is moved to adrv.
No need to change the original ydrv.
Edit: Copying an empty file instead of an rm command in conky-gtk script would also work like a switch and not just in SaveFile/Folder.
@rockedge
Please attach the /var/packages directory (of the to be released version) here? I want to finalize my work on the package extractor tool. Also confirm the final decision on what any adrv, ydrv and bdrv for this distribution will contain. Will this be the only Puppy to go the "modular" route (of placing the applications in a ydrv))? Thanks.
Why are you totally messing up the normal setup for the different sfs files that make up a Puppy version?
What is in the different drv.sfs files 
The different drv.sfs files are loaded in a specific order for a specific reason.
This loading order is not by chance.
It is based on what should be in the different files and how those items need to be loaded into the boot process.
This is the basic process that needs to be followed
From this readme:
https://github.com/puppylinux-woof-CE/w ... README.txt
/init
=========================================The init script has been called the heart of Puppy Linux.
This is not because it implements a lot of Puppy stuff, but because this is where Puppy starts.
When init starts, the full-blown Puppy is still just a number of files on a storage device.
The job of init is to use those files to build a Puppy based in RAM and then hand over control to it.Some significant files in the init world:
=========================================vmlinuz:
This is the Linux part of Puppy Linux, usually referred to as the Linux kernel.
The boot process has already loaded this into memory and started running it before init starts.initrd.gz:
This contains the Puppy files that form the RAM based filesystem that is in place when init runs.
The init script is one of these files.The puppy sfs files, puppy...sfs, zdrv...sfs, fdrv...sfs, ydrv...sfs, adrv...sfs:
(Where ... is a particular puppy name and version, e.g. zdrv_slacko64_6.9.5.sfs)puppy...sfs:
This is the main Puppy file, containing most, if not all, the software that is in the current Puppy.
This is the only sfs file that is required, if the init script cannot load it for any reason, the boot is abandoned.zdrv...sfs:
This contains kernel modules(device drivers), and firmware files matching the kernel in vmlinuz.
Without this file, Puppy will usually still boot, but some devices will either not work or not work properly.fdrv...sfs:
This contains firmware files. It can be used to override the contents of zdrv...sfs.
This file is present in only some Puppies.bdrv...sfs:
This contains a basic installation or skeleton of the compatible distro.
With this file, more binary packages from the compatible distro repos are likely to work.
It is usually not present.ydrv...sfs:
Notionally a patch file. It can be used to override the contents of puppy...sfs.
It is usually not present.adrv...sfs:
Notionally an application file. It overrides the contents of all other sfs files.
It is usually not present.Overview of how it works:
=========================* A typical frugal install of Puppy is a directory containing the above files.
* So init begins by establishing the location of this directory,
by looking for the puppy...sfs file.
* In the absence of any indication as to it's location, init searches throughout
the partitions of the system until it finds it.
* If it cannot locate the puppy...sfs file, it abandons the boot by dropping out to
a console with several error messages on the screen.
* Having located the puppy...sfs it proceeds to create a layered file system
from the sfs files in the directory.* A layered filesystem consists of a stack of directories, most of these layers can be read-only,
but the top one is always read-write.
* The directory that contains the stack, appears to contain all the files from every layer.
* But if a file exists in more than one layer the one in the top-most layer is the one that is seen.
So the order of layers is significant.* Init creates a stack containing only a directory in a RAM based tmpfs as the read-write layer.
* It then appends the puppy...sfs to this stack.
* It then processes the other sfs files, if they exist.
* It appends the fdrv...sfs.
* It appends the zdrv...sfs.
* It inserts the ydrv...sfs immediately below the read-write layer.
* It inserts the adrv...sfs immediately below the read-write layer.
* If all files are present we end up with a stack that looks like this:
tmpfs read-write
adrv...sfs read-only
ydrv...sfs read-only
puppy...sfs read-only
fdrv...sfs read-only
zdrv...sfs read-only* If this is a first boot, the stack is ready to be made into the running system.
* But, this first boot stack contains no persistent storage.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
ditto what bigpup wrote.
But isn't the simplest solution the following?:
Put quickpet in the base/core sfs. Have at least one web-browser in the repo it accesses. Stock that repo with 'additional software'. Don't put anything in ydrv or adrv. Use bdrv (if at all) for its purpose:
"bdrv...sfs:
This contains a basic installation or skeleton of the compatible distro.
With this file, more binary packages from the compatible distro repos are likely to work.
It is usually not present."
Solves amethyst's problem. Easier to devise a woof-recipe. Easier to keep F96 updated with current packages.
Edit: Note dimkr's post about the change in stacking order and handling of 'alphabet drives', https://www.forum.puppylinux.com/viewto ... 474#p77474 and the stated reason for that change. https://www.forum.puppylinux.com/viewto ... 481#p77481 A lean core/base sfs and fully stocked quickpet also solves low RAM problems.
@bigpup I haven't changed anything on my own. Pretty soon like radky I am going to leave the project because as soon as I spend the hours setting it up and publishing one, suddenly that's no good and now lets swing 180 degrees and do it differently.
I can live with F96 as it is in either the radky5 or radky6 series and can stop instantly with sharing any more versions. So let me know now which version to finish up with, radky5 or radky6 or neither of these. How about somebody show us an alternative to test out. 
To clarify: there is no change in the stacking order, only in the choice of SFSs copied to RAM in low RAM situations. And this change only goes into new woof-CE builds, F96 seems to be a manual remaster of woof-CE output from before this change.
Put quickpet in the base/core sfs. Have at least one web-browser in the repo it accesses. Stock that repo with 'additional software'. Don't put anything in ydrv or adrv. Use bdrv (if at all) for its purpose:
So a monolithic root_fs with everything in it other than a browser and no adrv,bdrv or ydrv? The base Fossapup64 root_fs generated by woof-CE currently has a minimal outfitting with applications. It's very basic, no document handling and no JWMDesk. No adrv and most of the applications will be missing from the start.
In real life use 90% of users using this distro will ever know that there is an ability to load extra SFS's during system boot even exists, never mind what the order of the layers being loaded are.
@dimkr is correct. F96 is a remaster of a base woof-CE built Fossapup64-9.6 with the default settings. Everything else has been added in and configured manually. It's one of a kind.
Option 1 = Completely abandon F96 then rebuild the Fossapup64 from scratch with woof-CE right now and leave it as is or remaster this again with manual additions and configurations. To use the newer RAM usage protocols.
Option 2 = Completely abandon F96 and focus on a woof-CE recipe for a polished and complete Jammy64-CE
Option 3 = Use F96 as is and begin to create the Jammy recipe. Create differently constructed adrv,bdrv and ydrv combinations.
Option 4 = Abandon F96 and work on KLV and KLA.
"bdrv...sfs:
This contains a basic installation or skeleton of the compatible distro.
With this file, more binary packages from the compatible distro repos are likely to work.
It is usually not present."
As a matter of interest - when was it decided that this will be the function of a bdrv and by whom?
@amethyst That description of the bdrv no longer is completely valid. The wording indicates something far different. Now I am upset at myself for ever including it as a demo in the first F96 because of the confusion it's causing. This was supposed to be a quick to produce stop gap measure that can be sent to the front lines now and is effective. I believe that F96_4-radky5-CE or F96_4-radky6-CE is ready to go as is. Once more I suggest offically to take these discussions to a new Jammypup64-CE topic thread.
The bdrv as I saw it could be used or not. I never decided whether I would include a bdrv in the production release ISO or not. I originally put the xfe 2 panel file manager in it for the demonstration of what could be possible and I wanted to use it while experimenting on a distro design.
The arrangements being tested now are important for the future project of creating a Jammy that is complete and can be built directly that way with woof-CE and a few clicks.
The intended use of bdrv is to contain delicate things like apt and Synaptic. They're isolated from the main SFS to make them removable, and placed above adrv and ydrv so they can't break the package manager.
Above the adrv? Again, who decided what the use/function of this "new" bdrv should be and where it should rank in preference? Remember that although a bdrv has not officially been part of Puppy, some of us have been using an adapted init for ages which already has a bdrv and other addition drives like cdrv, ddrv, etc. envoked and in use.
