hi all
i was just wondering
how are things going with the puppy distrowatch candidates
wanderer
Moderator: Forum moderators
hi all
i was just wondering
how are things going with the puppy distrowatch candidates
wanderer
If you are asking about Fossapup64 9.6 or S15pup 64bit or 32bit.
Both seem to be getting a work out, trying to produce a final release version.
Fossapup64 9.6
viewtopic.php?t=7234
S15pup
viewtopic.php?t=7227
Both seem to be getting bug fixed.
Should not be too long to final release version.
Help in testing is always needed by anyone.
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 agree
both S15 and F96 are being actively developed and are of the highest quality
this situation will continue to present itself since woof-ce is capable of using at least 3 distros as a base
i think we should submit them both at the same time
jesse at distrowatch could help us with how they will be presented
submit both screen shots with an explanation ?
wanderer
wanderer wrote: ↑Mon Nov 14, 2022 11:07 ami agree
both S15 and F96 are being actively developed and are of the highest quality
this situation will continue to present itself since woof-ce is capable of using at least 3 distros as a base
i think we should submit them both at the same time
jesse at distrowatch could help us with how they will be presented
submit both screen shots with an explanation ?
wanderer
I disagree. I think we should choose one --maybe flip a coin; they're both that good-- then just before we have to update distrowatch choose the other. It will save us from having to scramble to meet dead-lines and in the meantime any imperfections in the one not chosen can be fixed. And we won't have to ask jesse for favors or create confusion by having two offerings simultaneously.
well barry k says you can submit an update every 3 months
so S15 and F96 could be alternated every 3 months
but how to choose the first one
do the developers think they are ready
wanderer
I don't see where such forced 3 monthly updates comes from as any kind of Distrowatch 'requirement'. As has I think been stated already, Distrowatch says the following in its FAQ about 'Dormant' status:
A distribution which has not put out a new release in two or more years is marked as being Dormant in our database. The distribution may still be worked on, but has not published any new stable releases. When a dormant distribution publishes a new stable release it is then marked as being Active. A project may also be marked as dormant if it no longer plans to put out future releases, ie planned inactivity, while older releases are maintained.
Note though, that last sentence, A 'project may also be marked as dormant if it no longer plans to put out future releases, ie planned inactivity, while older releases are maintained' - i.e. maintaining older releases doesn't prevent dormancy. However F96 appears to me to be a new release of FossaPup and not simply a maintenance version. Personally, I can understand EasyOS and FatDog, for example, being accepted as unique (non-Puppy) distributions by DistroWatch, but I don't understand how Vupup or Vdpup are not Puppy spins - not that DistroWatch's opinion on any of this matters to me. Having said that, both Manjaro and EndeavourOS are variants of parent distribution Arch Linux, and Zorin is a specially tailored Ubuntu, which involves a lot of work and often provides a very different look/feel/taste to the upstream official distro.
But how close can 'official' Puppy get to say Vdpup without simply being a slightly tweaked Vdpup? - and neither of them necessarily rely on any special Puppy package manager - so it becomes a question in my head anyway of what distinguishes one production from the other...?...and especially if both being produced from a common woof-CE build system, or perhaps Vdpup is forking and not using woof-CE build system name anymore. In other words, I can't help feeling that most all distros are the product of some build system or other and the uniqueness of that build system is what defines their difference, but others will no doubt disagree on that feeling. Seems funny to me that Vdpup becomes represented on DistroWatch, whist Puppy itself has 'Dormant' status or ends vanishing even though Vdpup has 'pup' in its name. Is it only 'Puppy' that is effectively trademarked? Isn't 'Pup' effectively a trademark through longtime usage? I can see many reasons why Vdpup might be a fork and thus stand on its own, but can't help but feel that it should in that case simply change its allocated distro name and similarly name of its 'forked' build system if standing as something different from a Puppy Linux release - the two resulting build systems remain free to share/cherry-pick additions and ideas from each other of course - with due acknowledgement from all sides.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
Nope, it's built with woof-CE. If you follow this guide and ask woof-CE to build x86{,_64}/debian/{bullseye,bookworm}{,64} you'll get something called "dpup" that looks and behaves exactly like Vanilla Dpup (hence "vanilla").
AFAIK Slacko is the only "official" Puppy built with woof-CE as-is. Every time somebody publishes an "official" Puppy where the build process includes manual steps that cannot be reproduced by others ("remaster") or uses woof-CE plus local modifications that are not publicly available, nobody else can take it from there in the developer's absence. If that's what an "official" Puppy is, then Puppy always depends on a single developer and has no future.
S15Pup - there is a small problem with PMusic not displaying icons when called via a cd being inserted into the drive..........raised as an Woof-CE issue with @zigbert
https://github.com/puppylinux-woof-CE/w ... ssues/3568
Would like to fix this before release...... as a work-around I could set:
HOTPLUGNOISY=false in /etc/eventmanager
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
If the only thing that's stopping you from releasing the next "official" Puppy is a bug in PMusic, why not just replace it with something else?
dimkr wrote: ↑Tue Nov 15, 2022 7:09 amNope, it's built with woof-CE. If you follow this guide and ask woof-CE to build x86{,_64}/debian/{bullseye,bookworm}{,64} you'll get something called "dpup" that looks and behaves exactly like Vanilla Dpup (hence "vanilla").
AFAIK Slacko is the only "official" Puppy built with woof-CE as-is.
...
So for what reason is Vdpup not 'official' if woof-CE build results in '"dpup" that looks and behaves exactly like Vanilla Dpup'. Is there an unstated difference between the results or is the non-official status a personal request of your own. I get that someone else could build that dpup and have it possibly then named by Puppy lead as 'official', but surely Vdpup is being released as an identical(?) 'fork' in that case (which might deviate from possible official Pup later), or what is Vdpup in terms of team or individual 'ownership'?
EDIT: By the way, is there anything special about Vdpup kernel (?) - it is using less RAM when I've tried it with KLV and other such distros I'm experimenting with - though that's compared to using later kernels since I haven't tried using any other 5.10.x kernel release.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
Yes, I want Vanilla Dpup to be "unofficial". I want it to be possible for somebody else to build an "official", Debian-based Puppy (with more applications, different looks, whatever) on top of the same base. Until that happens, a barebones Puppy is not a suitable substitute for an "official" Puppy, and I think it's a super bad idea to rebadge Vanilla Dpup as "official". (When that hero who takes dpup to the next level arrives, Vanilla Dpup will live on in a separate branch that uses the same code as upstream woof-CE but with the current, short package list.)
Because that would be a big change that has not been tested.....
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
hi peebee
use your workaround
and fix it as an update
wanderer
The new version of PMusic includes "big changes" and this new version is still not featured in any "official" Puppy, but PMusic has less users (= testers) than other audio players, because it's Puppy-specific. This means it's more likely to have issues and less likely to have them fixed, compared to other music players. (And I wonder if music players have less users in the streaming age, greatly reducing the severity of such issues.)
If this issue with PMusic is the only blocker and you have to choose between two sets of "big changes" anyway ... why wait for a new PMusic version?
(And it's OK to ship a 1.0.0 release with known issues, if it's followed by a 1.0.1 release that adds nothing but fixes ... "release early, release often" tends to work better than "release when it's ready" in small projects like Puppy)
dimkr wrote:if that's what an "official" Puppy is, then Puppy always depends on a single developer and has no future.
Then I withdraw F96-CE from consideration. No further work will be done on it and I'll mark it as a proof of concept.
Use what comes out of a woof-CE build and all those nagging little flaws and missing or included but not working packages and features will be up to each individual to fix on their own. @radky I put JWMDesk in because the the default JWM config does not work as expected and I don't feel like fixing it.
The woof-CE produced Fossapup64-9.6 is a good base to start with but is far far from what I would put out on Distrowatch.
So a complete recipe must be finalized that will produce a woof-CE distro that is complete or at least the components it contains actually work.
@dimkr is correct and so F96 is no longer on my To Do list.
One last update is available, F96_3-CE that has Dunst notifications fixed and some other woof-CE Fossapup64 problems corrected.
Put S15 out there and call it a day.
hi rockedge
im sure i speak for everyone when i thank you for all that you have done for the puppy community
not to mention this wonderful forum
wanderer
What percentage of forum users actually use Slacko as their preferred Puppy? I always thought it was not so popular (as far as being the "go to" Puppy for users).
hi all
now that we have the official puppy candidate
what are the next moves
wanderer
RC3 of S15Pup is available. viewtopic.php?p=71034
also LXDE-ydrvs
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
Actually, rockedge, applying dimkr's explanation --if I understand him correctly-- the obligation of maintainer(s) is to create a reproducible 'base'. With respect to Puppy that means using woof with a published recipe; and thereafter maintain that 'base' by the same means.
'Bells & Whistles' that can be subsequently added are not required, nor required to be maintained. It's probably the reason I've complained about recent woof-built Puppys --such as VanillaDpup-- as lacking some of the amenities I'm accustomed to. See, for example, https://www.forum.puppylinux.com/viewto ... 513#p69513. As that example also shows, all that is needed for 'Bells & Whistles' is a location from which they can be downloaded and installed. I'm sure you know of many such locations beyond even the obvious for an 'Official' Puppy: ibiblio, Sourceforge, GitHub. But ibiblio is the most convenient as a woof installed PPM should be able to access it without much additional effort.
Take a look, for example, at Fossapup64's Quickpet. None of the applications available by using it are part of the 'Official Build'. And while Quickpet is a convenience, it is not a necessity. Those applications are also available directly at https://distro.ibiblio.org/puppylinux/p ... s-fossa64/.
[Unanswered remains questions I posed after using woof locally --the build was accomplished on my hard-drive. Packages were downloaded to the hard-drive which were then used as the sources by the build script. My questions were could additional packages be included as sources and the build-script modified to include them in the build. But if the build must be accomplished at GitHub, is there a method by which additional applications can be located at GitHub --or wherever the download script is capable of specifying-- so that they will be available to the build-script. (I may not have correctly named the scripts involved. It's been a couple of weeks since I used them. I hope you get the gist). By now you may be sufficiently familiar with woof to have an answer to those questions].
As I see it, you've already done the 'heavy lifting'. Primarily what remains is to document your 'recipe' for 'cooking with woof to create FP-96'.
As far as 'maintenance' goes, remember we're dealing with an operating system binary-compatible with Ubuntu Focal Fossa (20.04) originally released more than two year ago. It's woof-source now is likely 20.04.5. https://wiki.ubuntu.com/Releases. If previous Ubuntus --Xenial and Bionic-- are indicative, in the future there's not likely to be anything other an an occasion security patch. See the foregoing webpage for their history of revisions. If woof is structured to use the latest build from Ubuntu's repos --e.g. currently 20.04.5's repos-- not even a revision of the 'recipe' would be required. Perhaps merely providing the latest build of an application in FP-96's 'own' repo would suffice.
And you don't have to do it alone. Just ask for volunteers for your 'team'. Certainly, for example, I would expect radky would 'volunteer' to maintain updates to jwmdesk, as in all likelihood, he will be updating it anyway. I'll volunteer MikeWalsh, to maintain web-browsers. Count me in to do anything not requiring an ability to compile or extensive knowledge of bash.
so the idea is to have a woof-ce recipe
that will build a complete iso
where everything works without further tweaking
and another developer can just pick up where the last one left off
and this will build official puppies
wanderer
Perhaps you've given up too soon. Since new releases can be as frequent as every 3-6 months, just take the hurry out of F96-CE. A new Ubuntu based Puppy is still a worthy project.
@wanderer wrote
and another developer can just pick up where the last one left off
Since I know nothing about woof-ce, does this actually happen?
So here's my uneducated opinion, woof-ce has been a great tool to give commonality to all Puppy's, but it should not become a boat anchor that keeps a developer from adding additional programs and features that create a new and improved Pup.
Where I live, we call that "getting trapped in your own underwear"
Rock, for what its worth, count me in on helping for any F96-CE's testing, reporting and documenting.
wizard
Big pile of OLD computers
I think making S15 and Slack based distro's the face of Puppy Linux is a bad move.
And this stuff about one maintainer being a problem then we must reevaluate the entire idea because is not the entire woof-CE project such a one maintainer project prone to the same complaints?
F96 is built with woof-CE and 30% of it does not work correctly coming out of the build output. So it takes some work and polish to fix things. I am not woof-CE savvy enough to make those changes in woof-CE. My attempts fail in a jumble of garbage to adjust the recipe and add packages to the process when working directly with woof-CE. I am not investing anymore time to figure it out. I am plenty happy with sticking with KLV and building those with @wiak's build system.
inkscapelite is from Tahr. doesn't even launch. Switched to install inkscape because it was such a hassle to align the libraries to match the ancient version needed by inkscapelight. That is just one of many flaws, so unless that gets fixed at the woof-CE level so it will remain.
As far as I can tell this will not ever happen, and as is, we are spinning our wheels.
It might be possible to create a script that post woof-CE build does the needed mounting, un-squashing, editing, configuring and adding then re-squashing to complete a usable distro.
@rockedge :-
I think I have to agree with you insofar as the suggestion of a Slackware-based Pup being the 'face of Puppy'.
Granted, the Slackware 'source distro' IS very, very stable. But it's also pretty minimal as it comes - a legacy of Patrick Volkerding's ideals where OS creation is concerned - and despite 'Slacko' having a core of dedicated users here in our community they ARE in the minority. By far the greater proportion of our users favour the 'buntu-based Pups. I may have given up on Ubuntu itself, but I like the 'buntu approach of providing nearly everything - including the kitchen sink! - OOTB in the first place.
--------------------------
@mikeslr :-
I see I'm being 'volunteered' by 3rd parties.......yet again! Cheers, mate....(*not*)
hi rockedge and everyone
i am but a humble user and fan of puppy
(im so humble mr scrooge)
not a developer so i dont actually do any work
all i can do is give my opinion
but it seems to me that puppy is about a multiplicity of paths
thats why we have remasters and allied projects
and since we can change the distrowatch submission every 3 months
that might be a good way to showcase this diversity
so if you think its a good idea to keep working on F96
im sure we will all help as much as we can
remember
it is impossible to reach such a great truth by a single path
wanderer
hi everyone
this may shock you
but i dont think that woof-ce
should be the defining factor in an official puppy
other build systems may be better (gasp)
wanderer