Moderator: Forum moderators
Really the reason to call it an official Puppy version, should be about:
Built up as a bunch of separate SFS files, how it boots, loads complete OS into RAM, stores changes in a save file/folder, generally operates in specific ways (pupmodes), supports hardware old and new, uses the same core programs, installs as a frugal install, etc.............
These features are what makes Puppy Linux different to other Linux OS's.
That to me is a Puppy version.
No matter how it is built!
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 
I usually no longer indulge in this kind of thread, but let's just hope that this thread doesn't get deleted at the end.
dimkr wrote:The vast majority of 'official' releases are built with a private fork of woof-CE that is never published (with or without additional manual steps in the build process), so they're not 'built with woof-CE' as in 'built by unmodified upstream woof-CE'. I had to reverse-engineer old Puppy releases and extract these changes so newer releases don't feel like a step backwards (but I'm not doing this for BookwormPup64).
Basically, bugs that was fixed in earlier version can re-appear on the new version, and features in the old version can disappear on the version. This is certainly not good. Having to fish out these changes and apply them to Woof-CE is a thankless job that people seldom notice and even less appreciate. I admire you for doing it for as long as you did.
This is a problem that we don't know how to solve, though. Fact is, making a repeatable rebuild is hard work. Add to the fact the some folks don't understand or don't want to use git (which isn't wrong in itself, but it harms the long-term viability of the project).
dimkr wrote:Any set of criteria used to create a 'class system' that puts Puppy A and B above C and D, or leads new users towards A or B, will eventually harm the project, because users don't get a chance to benefit from features unique to C or D and the disappearance of the developers of A and B will cause mass departure of users.
This, however, I would have to politely disagree. Puppy had always had at least two classes (if not more): we had mainline Puppy, we have puplets (and if we want to be pedantic, we had remasters as well, etc).
The fact is, even back then in Barry's days, mainline Puppies did not always offer the "best" features ("best" being very subjective here). Example: during Puppy 4.xx days, mainline Puppies from Barry did not ship with SMP kernels due to his (valid) concern on performance or stability if those kernels on single-core CPU. I personally switched from Puppy to Fatdog around that time, because Fatdog was just plain Puppy + SMP kernels (and +openbox, but the SMP kernel mattered more for me).
There were many other puplets that offered a lot more functionalities; and they had their fans too. People found the mainline puppy first, see its goodness, and flocked to the forum when they wanted to do "more" - and then they saw the other puppy alternatives - those with openoffice built in, those with xampp built in, barebones pups, etc etc; and it certainly did no harm to the mainline Puppy, which kept chugging along; and the variants (puplets, remasters, etc) also had their own share of fans.
So the class system did not harm any of those in different classes.
dimkr wrote:I think it's absurd to put a Puppy that doesn't support Bluetooth audio in the top spot in puppylinux.com, just because it's 'official', while it has an 'unofficial' successor that does.
This one I fully agree with you. We should have chosen a better Puppy to be designated as "official".
ozsouth wrote:'Based on woof-ce' seems to be the only likely standard we can insist on.
Well that what I have always been insisting on the past, but we're in the minority now 
. If this criteria is no longer acceptable (for good reasons, I understand dimkr's disappointment with Woof-CE), what would they be?
fr-ke wrote:To DW: A friend of mine recently told me that there is no new puppy for him. He always just watched DW.
Good thing your friend knew you, or he would have thought that Puppy development stopped long time ago ...
wiak wrote:
Fully agree it's not a good idea to split the distros in this forum to their own invididual forums. There are a lot of things we'll lose if we go in that direction.
Nevertheless, that was not my point in my first post. I was simply trying to say that without order all we have is chaos.
bigpup wrote:That to me is a Puppy version.
No matter how it is built!
Sure. If that's the criteria you want to use, then DebianDogs certainly fit in, the KLVs do too, even TinyLinux also does, may even Knoppix too if it still exists ... would you put them to DW and say "this is Puppy Linux"? Perhaps the question should then be - why not?
It's a red herring. The actual time and effort to keep DW updated is zero, or very close to zero.
All you need to do is just __send an email__ to distrowatch informing them of a new release (with a blurb explaining what's new, what's changed, etc) and the list of the packages contained. These are the things that one does when one release a new pup anyway, that's what one puts in the forum post announcing the new release.
But if that still sounds like too much effort, how about this: With Fatdog64, we have an RSS feed that DW follows. Whenever we make a new release, we copy paste an existing RSS entry to create a new entry that points to the new release notes. DW then picks it up within 24 hours. Zero effort on our side, zero effort on DW side as well.
I think the biggest "time and effort" related to DW is to decide which Puppy you all want to feature in distrowatch. Always guaranteed to generate traffic and heated discussions every time it is mentioned.
------
EDITED: Corrected the RSS method that Fatdog64 uses to notify DW.
To clarify: I'm not disappointed with the project itself, as a pile of code. When I don't like the direction a project I use is going (or stagnation and lack of any direction) I just fork it, because I believe in my ability to find a solution to the technical problems.
I'm disappointed with the people, those who use woof-CE but don't contribute their local changes back to the project or make them publicly available so others can upstream them, those who refuse to learn git or fix other skill issues, those who rush to use ugly solutions and make successful woof-CE builds more miraculous than before, and those who insist on doing things the same way as before although the Linux ecosystem has changed a lot since Puppy 4.x. I can't fix other people, I can only provide solutions and documentation that can be used by others to continue my work or at least use GitHub more like 'real' developers.
Until the woof-CE project health improves, I can see why contributors don't use it as-is, or just use something else, to the point the number of new 'official' releases drops to zero.
(And I have my fork of woof-CE, sometimes I upstream changes like https://github.com/puppylinux-woof-CE/woof-CE/pull/4272 and I'm never surprised when they don't get merged due to fear or doubt)
I'm disappointed with the people, those who use woof-CE but don't contribute their local changes back to the project or make them publicly available so others can upstream them
Guess that's me. I have been building with woof-CE, made 10 versions of almost the same Fossapup64 just this weekend, trying to figure out how I can make changes. No changes to the code actually but just adding and removing the PET packages as I try to replace the older versions with the new versions now available. Reorganizing the desktop "look" and experience isn't all that comprehensive, the point being making a F96-CE using the latest packages for Focal Fossa from Ubuntu.
My problem is finding the best way to do the actual replacement on the repo's that contain the PET packages. Most of the work to make a newer F96-CE is just upgrading the PET collection. So far running the the stock Fossapup64 freshly built with woof-CE and trying out that out with different kernels, is moving along with better than expected results. The latest versions are really fast with the kernels I am trying out. Most changes are cosmetic and changes in background choices or conky or no conky and things like that.
So no real changes of the woof-CE code needed for what I am doing. BUT there is a lot of swapping to do on the repositories that supply the PET packages and then the tedious job of making those name and version changes available on woof-CE.
Also I can make these mostly small changes very quickly by just modifying an adrv or ydrv SFS or the base rootfs SFS without having to run an entire woof-CE build to try out if a single change works or not.
@dimkr you might have noticed I am offering no ISO's of these prototypes so not to build excitement for something that can't be reproduced by automation.
Too bad actually, this F96-CE_5-alpha3 with @ozsouth's low latency real time kernel 6.6.28 and all those packages that @Jasper, @sonny and others have contributed, is really amazingly fast and responsive. And so far all of those PET's added seem to work together well and caused no major system problems.
A start would be to add that collection that @mikeslr put together to the PET repo and then push those changes to the package lists for Fossapup64 in woof-CE.
The other question would be, is doing this for Fossapup64 - F96-CE make any sense due to it's age.
With Fatdog64, we have an RSS feed that DW follows. Whenever we make a release, we just update the RSS feed with literal copy paste from the release notes. DW picks it up within 24 hours. Zero effort on our side, zero effort on DW side as well.
I really like this idea. This forum for example does a good job providing RSS feeds.
bigpup wrote: ↑Mon Apr 22, 2024 11:12 amshould be about:
Built up as a bunch of separate SFS files,
how it boots, loads complete OS into RAM,
stores changes in a save file/folder, .........
(pupmodes),
supports hardware old and new,
uses the same core programs,
installs as a frugal install,
etc.............
That to me is a Puppy version.
No matter how it is built!
I can appreciate looking for a common thread if seeking a definition.
calling all of these thing features tho may be a misnomer. How many of these items are simply the means to an end? Shouldn't the features that define puppy be the end goal itself?
Rollback is an defining end. How it is accomplished should not be definitive.
Frugal install might be definitive, does it matter if the filesystem uses sfs's?
more?
Probably much more, but I think the question is: Who decides ? There's no authority present atm who can make some sort of "law" about what and what not.
People are doing their own thing now. Btw, personally I think it's fine, lots of creativity , let's stop trying to define what is a "Puppy", it's proved to be an endless discussion.
Yes I understand. That's what I meant although I didn't say it explicitly. Everything you said is correct. The only thing is, you're one of a kind around here, and I really mean it in a good way. Not everyone (who is doing Puppy development) has the same skill, motivation, inclination (and perhaps time also) to be able to do what you can do. That's why I said it is a hard problem. I'm sure everyone means well, but they just don't view things the way you do.
jamesbond wrote:Fact is, making a repeatable rebuild is hard work.
An explanation to those who don't understand why this is hard work.
Let's say you're doing a remaster or custom build of Puppy that among other things, includes VLC as a built-in application. You modify the "package list" files, and build the ISO, you click the menu item in JWM - and VLC doesn't launch. After spending the time and effort, you learn that the problem is in the .jwm file: the VLC menu has a "%F" parameter, which isn't supported by JWM, so it chokes when you click the menu to try to launch VLC.
The fix is simple. Edit .jwm, remove the offending %F, and rebuild the ISO. You do that, and problem solved, right?
Well, no. You run the ISO for a while, and when you're ready to publish it, you decide to install an app from the repo just for fun. And then by happenstance you click the VLC menu item again to launch it, and VLC stops working again. Wondering what's wrong, you check on .jwm file again - and whoa! That bedeviled "%F" is back!
After scratching your head for a while, you finally know that when you install an app, "fixmenus" is run to update JWM menus. In other words, .jwm is re-created. Now that gets you thinking. Where is the source file that fixmenus use to get the menu entry? A few questions on this forum eventually leads you to /usr/share/applications/vlc.desktop file. And yes, in the "Exec=" line of that file, you find that annoying "%F". You promptly edit that file, remove that %F, and save it. Then you run fixmenus. VLC launches after you click its menu. You install another app, and click VLC again. It still runs. Very good. Problem solved. Right?
You package the ISO and announce it to the world. Everyone is happy and receptive. All works as intended. Until an annoying person does the forbidden stuff. He accidentally uninstalls VLC, and installs it again. With dread, you read his forum post: VLC does not launch.
You spend lots of time interrogating this guy, until, after about 50 posts later, you figure out what happened. Your answer is simple. "Please do not uninstall and re-install VLC. It is not supported. Why are you doing it anyway, since VLC comes pre-installed?"
Well things chug along for a while, until the upstream distro releases a new version of VLC with a new great feature. Everyone who uses your distro rushes to install the new VLC ... and soon the forum are full with posts "My VLC stops working!" "Mine too" etc.
Cornered into this situation, you begrudgingly decide to make it right this time, once and for all. You want that the action that you do, "removing %F", to be repeatable when someone install, re-install, or update, the VLC package.
After more discussions with elders of this forum, the solution comes to mind. "You need to patch the package manager, so that when it installs VLC, it automatically edits the .desktop file and remove the dreaded %F", they say.
That sure sounds right, but you have a little bit of a fright. The package manager is a huge, convoluted program. When you started doing this remaster or custom build, it was never your intention to mess with this monstrous program. You feel that messing with the package manager is more than what you've bargained for. But as reluctant as you are, "editing the package manager is the only way", the elders say, so timidly you decide to step in.
With nausea you navigate the source code of the package manager. As you go through the source code line by line, you finally arrive at the section, with giant comment that says:
Code: Select all
# ==== EDIT DESKTOP FILES TO MAKE IT WORK WITH JWM ====
Yay! It's already there! This problematic desktop file is apparently a common enough problem that even the package manager already has a special code to deal with it!
So you read that particular section more thoroughly, and you decided to put in the fixes for VLC. The code that edits the .desktop file is full of "cut"s, "head"s, "tail"s, "grep"s, "sed"s and other stuff that is way above your head, stuff that you have never before seen in your life; but hey, how difficult could it be? There are a ton of it already that serve as examples. One for abiword, another one for gnumeric, and there is one for mtpaint ... perhaps it's not so tough. Encouraged, you copy, paste, change a few variable here and there ... and it's done.
Gleefully you use the package manager to install the update, and then click the JWM menu to launch ... and it doesn't work. When you look at .jwm file, you see garbage. Confused, you see the vlc.desktop file. It's garbage too. One or more of the "cut"s, "head"s, "tail"s, "grep"s, "sed"s must have been wrong, but you're not sure which one.
So you try to make some changes, and try again. It doesn't work.
So you try to make some changes, and try again. It still doesn't work.
So you try to make some changes, and try again. It still doesn't work.
...
And finally, after two or three hours of work, you manage to get it working. You have discovered the magic recipe and the right combination of commands that make it work. (Re-)Installing VLC package will now work, because, instead of depending on your manual removing of "%F", it is now done by the script inside the package manager. You can repeatedly install/uninstall VLC with no worries anymore.
And then you publish the updated ISO the world triumphantly, and think you can sleep well that night.
Except that immediately after the upload is completed, you remember something. The hack of editing desktop file, isn't only required for VLC. You also need to do the same thing for libreoffice, for gimp, for krita, for OBS ...
So you pull your download as fast as lightning. Good thing you have not announced anything.
To preemptively avoid another complain, you quickly edit and test, edit and test, edit and test ... the package manager again until all those programs can be installed/upgraded without problems too. That takes you a solid one and a half day.
You build the final ISO, and upload it again; and you make an announcement.
Exhausted, but overjoyed, you watch with satisfaction as people ravenously download your updated ISO. People in the forum all thank you, and praise you for the good fix you've provided, for being a good developer you are, for the responsible person you are.
What a nice warm cozy feeling as a reward for your hard work.
----
MY POINT:
See, removing "%F" once is easy. It takes less than 5 seconds to open the file, press delete 4 times, and save the file. But to make sure that "%F" is always deleted when you install/re-install (=repeatability), is hard. You have to write the patching script, and test it, and test it and test it and test it so that it always works in all circumstances. That 5-seconds job can easily turn into 2-3 hours job.
----
And now, for the final epilogue. This epilogue isn't related to the premise that "repeatability is hard work", but it's just a fun __speculation__ of why changes don't get updated to Woof-CE. I'm not pointing at anybody with this one; just read it for the fun of it if you will.
EPILOGUE:
As you're resting and basking in your glory, along comes dimkr, saying, hey, that's a good fix you found. Why not include that fix in the Woof-CE github, so that all other future Puppies will also have the fix, and they will never again have problems with VLC, Libreoffice, gimp, etc not launching.
But you have never heard about git, let alone github. It sounds like an esoteric tool, that will probably take a lifetime to learn. A glimpse to github.com confirms your guess. You reckon you have more important things to do, like planning for your next releases, or perhaps another variant of your custom pup. Or perhaps, there is this other little nagging bug that you haven't fixed yet. Or perhaps, that corner of your garden that needs trimming, or perhaps the shed cleanup that you have been postponing in the last 3 years, or perhaps you need to clean your house since your family is coming to visit you next week ... after all, you don't live for Puppy alone, you know.
Furthermore, why should you worry. Other puppies are other puppy developers' business. You fixed yours, you made your users happy, and that's enough responsibility for you, isn't it? If others want to apply the fix to other Puppies, they can download your ISO, and they are more than welcome to analyse the changes you have done to the package manager. It's not like you hide your changes ... it's there in the open, that's why it's called open source, isn't it? Just take the changes and apply it to their own puppies, right?
After all, puppy is do-ocracy, they say. You've done your share, it's up to others to do theirs.
THE END
fredx181 wrote: ↑Mon Apr 22, 2024 3:31 pmProbably much more, but I think the question is: Who decides ? There's no authority present atm who can make some sort of "law" about what and what not.
People are doing their own thing now. Btw, personally I think it's fine, lots of creativity , let's stop trying to define what is a "Puppy", it's proved to be an endless discussion.
I actually agree with you Fred, without a benovelent dictator the discussion about "laws" seems futile.
just putting a few thoughts out there for the OP, should it help with his moderator job.
@jamesbond wrote:
github. It sounds like an esoteric tool, that will probably take a lifetime to learn. A glimpse to github.com confirms your guess
Thanks, you're singing my song! (and confirming a major issue for many).
hi all
as to putting a new candidate on the distrowatch page
all you have to do is contact jesse or whoever at distrowatch
thats what we did last time
puppy has many flavors
so the distrowatch candidate really is just one example of all the work
wanderer
Very good discussion going on about Puppy Linux!
Hopefully a lot of Puppy developers are reading this topic.
However, THE PROBLEM STILL NEEDS ADDRESSED BY SOMEONE!!!!
Anybody that is right now offering a newer Puppy version, than the ones listed on DistroWatch.
PLEASE SUBMIT IT TO DISTROWATCH, to have it show something newer, and that Puppy Linux is still actively providing newer and improved versions!!!
The last Puppy version posted to Distrowatch was S15pup on 2022-12-10
It really does not matter what gets posted, but something better get added!!!!!!
I would give DistroWatch BookwormPup64 and BookwormPup32 as the newer Puppy version to post.
But there are many others that could also be posted. If nothing else, to show choices available.
Every time a new Puppy version is offered and gets to release status.
Submit it to DistroWatch!
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
hi bigpup and everyone
thanks for bringing this up
time slipped away and i did not realize it had been so long since we put up a candidate
i do think having puppy on distrowatch is important to keeping the puppy community active
a great many people (including myself) go to distrowatch first to look for news
if we do not keep putting new candidates on distrowatch they will mark us as inactive or dormant
it looks like everyone is either undecided about what should be posted to distrowatch or reluctant to actually do it
so since this is a do-ocracy
i will take it upon myself to send in a candidate
BookwormPup64 and BookwormPup32 sound fine to me
we will need a picture and a description to send to distrowatch
how can i obtain these
wanderer
Yes, but if it is someone who the Distrowatch guys don't know, you should get the tick of approval from one of the Puppy Linux developers who they do know. Otherwise, it could be just anyone submitting their puppy-variant without endorsement of anyone else in Puppyland.
They know 01micko, peebee... who else?
Or, you could refer the distrowatch guys to a forum thread, such as this one, showing approval of the choice from others.
hi barry
with your permission i could mention your name
that would be the ultimate id
since you are the original puppymaster
they did accept me last time as a go between
i don't think they have much of a problem with people impersonating a whole distro community
however i would appreciate input from the whole puppy community
by posting on this thread
before i do this
i have no dog in this race
i am only doing this to get things going
to keep us current on distrowatch
wanderer
wanderer wrote:BookwormPup64 and BookwormPup32 sound fine to me
I agree! It should be these two distro's that are the immediate "face" of the Puppy Linux world.
Perhaps through those there will be exposure to the likes of F96-CE, VoidPup's, and the entire collection.
No matter what gets announced on distrowatch, puppylinux.com is the first search result for "puppy linux" and needs to be updated. I think this is way more important than representation on dw.
rockedge wrote: ↑Tue Apr 23, 2024 2:24 pmwanderer wrote:BookwormPup64 and BookwormPup32 sound fine to me
I agree! It should be these two distro's that are the immediate "face" of the Puppy Linux world.
Perhaps through those there will be exposure to the likes of F96-CE, VoidPup's, and the entire collection.
There must be viable support available to react to any problem reports in a timely fashion. @radky is the only person who can currently achieve this properly for BWP64.....
As for the website - anybody can submit pull requests on Github.....
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
There are images at: puppy-linux-collection
BWP64 Description & image at: viewtopic.php?t=8690
BWP32 differences & image at: viewtopic.php?t=10087
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
agreed
and that page also needs to feature the other kennelmates (dogs, klvs etc), rather than a long list of old puppies
and drop the "official" designator.
Just a long time Puppy user here from when Puppy was in alpha (<1.0) and nowhere near usable for daily driver. But yea I rather agree with Bigpup, having old versions of Puppy as what is offered on Distrowatch and in searches with unupdated welcome wiki not going to attract anybody to investigate further. I like the diversity here. And yea there is lot of choice for varied kinds of uses and varied hardware. Some might find it too much choice but many might find it refreshing rather than same distribution with various desktop "spins". But few are going to go out of their way to discover that unless they get to using one or another current Puppy.
I personally wouldnt be offended at all to have BookwormPup be the flagship puppy to attract new users. There is name recognition least in the linux world, and from that people know its not some mouldy oldie from ten years ago or something exotic that is for "experts" only with very little software available short of compiling it themselves. People are less familiar with Void and Slackware and others. But you got to get their interest before they can explore other less familiar versions of the extended Puppy family. I will also point out that having apt-get functional in BookwormPup will make a difference in people staying with Puppy. Its familiar to Debian/Ubuntu based distribution users, and makes life easier.
Yes! Was wondering why no one was addressing the fossa in the room.
As long as folk are led to understand that the Bookworms are usrmerge & old .pets could be incompatible, I think we should put the Bookworms on DW AND more prominently on puppylinux.com.
hi everyone
as barry notes this thread is to decide what distro will be presented to distrowatch as a new puppy candidate
as i am reading bookworm seems to be ok with everyone who has posted so far
i am going to wait until we feel we have reached a consensus before i send anything to distowatch
so please post your comments on what distro you want on distrowatch on this thread
thanks
wanderer
@wanderer
If you start a new topic you can then create a poll and then invite members to vote.
Ages ago, I did something similar. Just remember to give members ample time to cast their vote 
hi jasper
yes that would be cool
but i think this thread is working fine
as i said it looks to me like the consensus is that we present bookworm as the new distrowatch candidate
but lets wait a little while for everyone to post their comments
before we send it in
wanderer
Hi
I feel you MUST have Radky's buy in before doing this..... or somebody else must takeover BWP64 from Radky - with his permission.
or the BWP64 build should be publicly available.
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
thanks peebee
you are the man
i dont know how to get that
but i assume the community will come up with a plan
thanks
wanderer
@peebee you have echoed something a forum member helped me see when I first joined the forum, privately. At that time AND now, I completely agree with the need for the distro developer to "AGREE" to post his/their work and they have the responsibility insuring ongoing efforts and support.
DW registration is a mere single component of what is expected by those listing on DW as there is a sizable amount of time that will be needed in total.
I concur that this should be seen as a requirement, going forward.
