woof-CE needs you

[wiak]

@Sailor,

Yes, I am not modifying Xenialpup64 builds at all. mpv is in there but these libs are missing (or not symlinked in correctly if they are there is some other named form).

wiak

[Billtoo]

I'm curious what you have done such that these libs are not missing on your build Bill. Perhaps they are included with your own kernel used packaging (rather than those available via woof-CE directly?)

I'll be uploading new ver 0.0.5 makepup soon once I've tidied the new code up a bit and done some more testing. It contains quite a few major code changes - both to do with the extra options (and organisation of when to use makepup_extra.conf) and also the auto-alter support/rootfs-packages.conf code dependent on distro chosen. So it needs quite a bit of testing, but looking okay thus far.

wiak

Hi,

I compiled the prorietary nvidia driver on 2 xenialpup64 installs and both mpv and kodi work fine.
On another xenialpup64 with an amd radeon graphics card neither mpv or kodi will run.

I'm building a tahrpup64 now with the oldest kernel "7" to see if I can compile the flgrx driver and try kodi in that one.

Bill

[wiak]

I compiled the prorietary nvidia driver on 2 xenialpup64 installs and both mpv and kodi work fine
...
Bill

Ah... that compile must have pulled in the missing libs needed by mpv I guess.

wiak

[wiak]

chroot test a new woof-CE build from its host build system (or any other Linux system):

Howto do the above is given here:

http://www.murga-linux.com/puppy/viewto ... 512#966512

wiak

[Sailor Enceladus]

Speaking of chroot test, I just tried to build xenial64 (testing branch) using xenial64-7.0.8.5 and it's devx as base and it stopped at that part of 3builddistro-Z (screenshot).

edit: Using slacko64-6.9.9.5 and it's devx as the build environment to make xenial64 (testing branch) seems to be working better. Now I wonder if using this newly created xenial64 to make xenial64 will work better than the real xenial64-7.0.8.5 one did for me or not, and if so, then that xenial64 produced by that xenial64

edit2: The xenial64 iso produced by that slacko64 was missing the 3 mpv libraries wiak and rufwoof mentioned too it seems (/usr/lib had libmircommon.so.5 instead of 7). Also, QBat in xenialpup says my full Battery is at negative 109%.

[Billtoo]

I tried the tahrpup64 build on a pc with an AMD graphics card and it
didn't go well, deleted the savefile and moved it to an Acer with
nvidia card, it works great on there.
Installed to a 32gb SDHC card.

sh-4.3# inxi -bw
System: Host: puppypc19407 Kernel: 3.14.54 x86_64 (64 bit) Desktop: JWM 2.3.6 Distro: tahrpup64 6.0.6
Machine: Device: desktop System: ACER product: Aspire M5620 v: R01-A4 serial: PTS860X0348050CF642700
Mobo: ACER model: G33T-AM v: 1.0 serial: 00000000 BIOS: American Megatrends v: R01-A4 date: 12/19/2007
CPU: Quad core Intel Core2 Quad Q6600 (-MCP-) speed/max: 1603/2403 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.15.1 driver: nvidia tty size: 141x28 Advanced Data: N/A for root
Network: Card: Intel 82566DC-2 Gigabit Network Connection driver: e1000e
Drives: HDD Total Size: 43.9GB (30.3% used)
Weather: Conditions: 59 F (15 C) - Partly Cloudy Time: September 4, 12:03 AM EDT
Info: Processes: 146 Uptime: 1:03 Memory: 424.4/7976.9MB Client: Shell (sh) inxi: 2.3.8
sh-4.3#

Kodi sfs works well, Google-earth too.

[Sailor Enceladus]

Tahr 64-bit woof-CE testing build worked ok for me too on Core2Duo laptop, using same 3.14.54 kernel as Billtoo.

[wiak]

Just dropped by woof-CE github and note that the missing libs (for mpv etc) seem to have been added now to the testing branch of xenial 32bit and 64bit. I haven't tried it yet.

Since it takes time for such bugfixes to filter through to rationalise branch I intend the next release of makepup to default to using testing branch (despite the chance of things breaking in that branch owing to its 'testing' nature). Will still be able to use rationalise branch instead of course using switch -w/--woofbranch.

wiak

[Billtoo]

I installed a rationalise branch build of xenialpup to a 64gb flash drive, pc is an Acer desktop:

root# inxi -bw
System: Host: puppypc3008 Kernel: 4.9.13 i686 (32 bit) Desktop: JWM 2.3.5
Distro: xenialpup 7.0.6
Machine: Device: desktop System: ACER product: Aspire M5620 v: R01-A4 serial: PTS860X0348050CF642700
Mobo: ACER model: G33T-AM v: 1.0 serial: 00000000
BIOS: American Megatrends v: R01-A4 date: 12/19/2007
CPU: Quad core Intel Core2 Quad Q6600 (-MCP-) speed/max: 1603/2403 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.18.4 driver: nvidia
tty size: 83x29 Advanced Data: N/A for root
Network: Card: Intel 82566DC-2 Gigabit Network Connection driver: e1000e
Drives: HDD Total Size: 70.9GB (30.6% used)
Weather: Conditions: 55 F (13 C) - Mostly Cloudy Time: September 5, 10:21 PM EDT
Info: Processes: 192 Uptime: 20 min Memory: 187.1/3535.0MB
Client: Shell (bash) inxi: 2.3.8
root#

It's working okay so far, some applications aren't available
(smplayer/smtube) but kodi works well.

[wiak]

Just dropped by woof-CE github and note that the missing libs (for mpv etc) seem to have been added now to the testing branch of xenial 32bit and 64bit. I haven't tried it yet.

Since it takes time for such bugfixes to filter through to rationalise branch I intend the next release of makepup to default to using testing branch (despite the chance of things breaking in that branch owing to its 'testing' nature). Will still be able to use rationalise branch instead of course using switch -w/--woofbranch.

Following a test XenialPup64 I made with makepup from woof-CE-testing branch, I can confirm that mpv media player is now working when built from that branch. That follows from the recent woof-CE-testing bugfix where the missing libs were added in as 'yes' to the DISTRO-PKGS-....

wiak

[OscarTalks]

I downloaded and ran woof-CE yesterday. This was my first time. I am a fan of Dpup so I selected Stretch. Pretty much allowed things to run through without re-configuring anything. It did build successfully and does run, but clearly some tweaking of the output distro is still required. As things stand I don't know how to feed back any suggestions into woof-CE but I might play around with it some more over time to try to get the hang of it.

I was also looking at the kernel-kit because I wanted to try to find out how to produce the kernel-sources .sfs package. I have done a lot of manual remastering of billtoo's early build and he didn't have a 3.14.79 kernel-sources (not sure if it would be OK to use the one in the tahr ibiblio repo). I did create one and went on to build ndiswrapper-1.61 as a test (and because I wanted to add it to my remaster).

[Sailor Enceladus]

Hi OscarTalks,

What are some thing you noticed missing from Debian? If they are in one of the PPM repositories, they can probably be added to the spec. I have made a Devuan Ascii here, where I tried to fill in some of the missing pieces, you can rip out it's vmlinuz and zdrv and use it's kernel sources (4.4.80) if you like:
http://murga-linux.com/puppy/viewtopic.php?t=109842

I've also tried another Slackware 14.0 (5.7.1) build here at commit 5526 if anyone wants to test it:
https://www.mediafire.com/folder/kwhxks ... 5hdwgcye4o

I kept the old one here too in case something is not right, as there have been a lot of template refining in between these two commits.

How did your kernel-kit building go? I think the current configs (like 3.14.79) should still work when running ./build.sh.

edit: I think there is a 3.14.79 build with kernel sources by norgo here too:
http://murga-linux.com/puppy/viewtopic. ... 611#940611

[belham2]

I've also tried another Slackware 14.0 (5.7.1) build here at commit 5526 if anyone wants to test it:
https://www.mediafire.com/folder/kwhxks ... 5hdwgcye4o

Sailor, you improved it over the old one? No way. I find that most mucho hard to believe

[sc0ttman]

I see a lot of complaints about recent Puppys, but 01micko and others have done a great job moving puppy into x64 and ARM land, and people are free to contribute fixes via GitHub... it's just that most puppy users can't be bothered to learn how .. and THAT is what slows development... other distros can rely on hundreds of users who know git. shell, etc .. puppy devs dont have that luxury.. plus they have to work, barry is retired.. it would be nice if barry sometimes did a PR for woofCE ..

I agree with the above - that building pups from so many different sources creates a lot of complexity ... better to focus on a couple only, I think ..
My choice would be T2(if its alive?), Slackware, CRUX, Debian, Ubuntu .. Or whatever 3 or 4 work best.

Basically I think we should focus on source (t2, crux), .deb (ubu/debian) and slack pups..

But we non-experts (yes me too!!) should be using Git way more, and doing way more of our dev work inside the woof code base.. Git "branches" in woofCE are very under-used .. (Woof-CE still only has like 5 branches?? .. even my crappy CMS uni project had like 45 branches after 6 months of dev work...)

http://rogerdudler.github.io/git-guide/ <-- very easy git guide, explains using 'feature' branches properly..

Using the forum for development means that dev work is CONSTANTLY repeated, lost, dropped, re-implemented, over and over.. This forum is full of ppl posting fixes and asking how to get their fix into woof ...

How to improve the Woof-CE GitHub usage very quickly:

* add to Woof-CE the ability to choose desktop environment (DE) at build time ... With choices like: JWM, Xfce4, LXDE, MATE ..
Each DE choice would simply be a selection of pkgs to be added.. Example, the "JWM" DE might be: jwm + rox + radkys PupApps + ziberts traytools

* If peebee wanted to make a woofCE_lxpup branch and put his work in there, then WoofCE would build LXPups just like his... instead of re-doing the same work for each new release.. ... It's not 01mickos fault (or anyone elses) that he hasn't done that (yet! )..

* If rg66 and Geoffrey pull their fingers out, they could make an woofCE_xfce4 branch, and make woof build nice Xfce4 pups out of the box.. Instead of re-doing the same work for each new release, just make the petbuild scripts..

* Whoever it is that makes MATE desktop pups could do a woofCE_mate branch ... instead of re-making and releasing MATE versions for each new release...

* if I finally get around to woofing an Akita, I will make a woofCE_akita branch, which contains all Akitas custom changes... 01micko or whoever could pull in any changes they like to 'testing' ...

* If i get time, the next Puppy Arcade will be woof-built, meaning all the emulators and related apps will have their own *.petbuild scripts, and so anyone could include (some or all of) those apps in their own woof-built pups.. I'd put it in a woofCE_puppyarcade branch, and 01micko or whoever could move any .petbuilds etc over to testing (if they wanted...) ... but mednafen won't compile on the gcc used in recent Slackos .. for now I wait, and think..

* i have long planned to build a no X pup (without Xorg etc ... it would use instead the framebuffer only, with apps like ranger, vim, vifm, mplayer, netsurf-fb and my CLI pkg manager (with sbopkg/petbuild/etc)... If I finally get time to do it (I have a lot of stuff ready), I'd do it in a woofCE_noX or woofCE_headless branch..

* Puppy app developers (like radky, zigbert, etc) could create a branch called woofCE_myappname, then make only the changes needed to build and include their new app as a "builtin" or repo package.. Each time they updated the app they maintain, they would just need to `git merge origin testing` to get the latest dev branch, then drop their app/PET files into their WoofCE tree, do `git add . ; git commit -m 'updated to v1.2.3'; git push origin woofCE_myappname` ..

* any PETs built manually that work on lots of pups can go in the common repo ... a woofCE_commonpkgs branch could be used, and from that branch, branches like woofCE_commonpkgs_paintown could be created, then updated with the new pkg and pushed to github by anyone who has a pkg to add (pkgs with static compiled apps, pre-built apps taken from popular sites, etc) ..

* A woofCE_fatdog branch that can build FatDog-ish ISO would be a great idea, I'm sure jamesbond, SFR et al could make that happen if they wanted..

* etc , etc...

The key would be to make your branch build your unique pup, without breaking any 'default' builds ...
So in other words, your branch should be able to build all the same pups as the main "rationalise" branch, but yours as well..
Then merging it back into testing or rationalise should be fairly painless..

To Be Fair, Woof-CE Git Branches are a Bit of a Mess

As it stands .... Who knows which branch you should create your new one from? I don't..

This is how it *should/could* be:

master - the branch containing *only* good commits that produced the *official* builds ... only 01micko can merge into master
develop - the "main" working branch, into which most good pull request (PRs) are merged ... only 01micko and others of his choosing can merge into develop

After an official release goes out, you would merge the commit in develop that produced it into the master branch.
The master branch would never contain any commits (version) of Woof-CE that were NOT used to produce official builds..

master would be a reference for all the best versions of Woof-CE that have been made.
Any problems in the develop branch could be reverted simply by taking stuff from master.

Then

feature_x - branched off of develop, adds new feature or pkg to woof-CE .... make a PR, a lead dev tests it, comments its good,and merges back to develop
bugfix_x - branched off of develop, fixes a bug in main branch, can be merged back .... make a PR, dev tests it .. merges back to develop..
puplet_X - branched off of develop, make woof support a new base or new pkg selection (etc) ... after release of Puplet, and testing defaults builds still work, make a PR, to be merged back to develop..
puplet_XY - branched off of puplet_X, helps break down your puplet work into chunks.. use these during your puplet development

In short, normal puppy devs would normally branch off develop, do their work, then create a pull request (PR) for a lead dev to test, and maybe merge into develop.

Also

repo_noarch_X - branched off repo_noarch, add a pkg to repo, others can test, merge back to repo_noarch if its good
repo_common_X - branched off repo_common, add a pkg to repo, others can test, merge back to repo_common if its good

The beauty of the above workflow is that only good, tested work makes it upstream to the main branch,
and everyone can work on different stuff at the same time, while still merging it all together in a (fairly) manageable way..

GitHub can *merge and squash*, so only 1 commit per PR would need to be added to develop or master, keeping the history of changes really clean..
(After a puplet had been made, probably with loads of commits, once it is released a PR can be made, and a single commit can be merged into develop,
like "Working LXDE desktop now available in DE selection - thank peebee!")

NOTE: the 'petbuild' git repo is a little different - you would only create new branches for each BINARY_COMPAT distro puppy gets built from ... so separate branches for the separate distro versions (slackware14.2, slackware14.1 each get their own branch, ubuntu16, ubuntu14 their own, etc) .. and you could branch off of them for each buildscript you added, ready to test and be merged..

A lot of the Puplets (derivatives) are just re-themed pups with diff window managers ... If woof-CE let users choose a desktop environment at build time, half those puplets would not need to exist and any fixes/improvements done to xfce/mate/lxde setups and pkgs could be done in woof-CE ..


Anyway... Working with Git is so EASY.. Something like this works for even very large projects with many team members:

Code: Select all

git clone WOOFURL mywoofdir

cd mywoofdir

git pull origin develop   # make sure you have the latest code (will pull down any new 'commits')

git checkout -b my_new_feature  # create a new branch called 'my_new_feature'

# now do your work, (EG, copy your files into this woof code-base), then ..

git add . # add all changed files to "staging" area, ready to "push" (upload)

git commit -m 'my message' # commit the changes you staged (like saving a new version)

git push origin my_new_feature # push it to github/gitlab (wherever you set it up)

# ..can now create a PR (pull request) for ur new branch.. do that on GitHub, using ur browser
# ..at this point, other ppl might review, fix, update ur Pull Request.. 

git pull origin my_new_feature  # pull down any updates made by others

# repeat as above.... 

#
# ... then later, 01micko (or any lead dev) can do:
#

git pull     # get all branches (will now include ur feature branch)

git checkout develop  # go to main working branch

git merge my_new_feature # merge your feature into main code base.... if the PR is reported working!
git merge bobs_new_feature # merge bobs new feature into main code base.... if the PR is reported working!
git merge some_new_feature # merge some new feature into main code base.... if the PR is reported working!

This workflow works for large in-house projects at some serious places, even with large dev teams moving around a lot..

.. there is nothing stopping Puplet devs from setting up a new branch of WoofCE and using that as their base/build tool ... WoofCE could have dozens of branches, each developed by a puplet developer .. then all the good work from the puplets can be MUCH more easily merged into the main WoofCE code base..

You can include Git repo info in ur $PS1, so you dont lost track .. Just Google "Git PS1 prompt" and update your .bashrc or .bash_profile .. The devx should prob include a Git-aware PS1 by default... To get ppl in the mood..


But to be fair, the documentation on contributing to Puppy development is sparse, sporadic and hard to find.. I still can't find good docs on fixing/updating Woof, and I definitely looked around! .. There is nearly nothing about Puppy dev Git workflow ... And something that slows development is constantly having to return to the forum for fixes, news, etc ..

Puppy Needs Better Documentation!

Where are the guidelines on:

1. Creating packages for the common repo? How to get packages in there? Who to contact?

2. Creating packages for the noarch repo? How to get pkgs in there? Who to contact?

3. Creating packages for a slacko14.2-contrib, tahrpup-contrib, or officialpup-contrib repo... they don't even exist.. (yet, stay tuned )

4. Creating buildscripts so others can compile ur packages?


Arch linux does it right ... Puppy needs a big Wiki like theirs .. For

1. Installing

2. Setting up (inc external devices ... joypads, drawing tablets, etc)

3. Using & Configuring Apps X, Y, Z (refers to 2. a lot as Prerequesites)

4. Compiling Apps

5. Remastering

6. Woof-CE ... with kernerl-config, petbuild, remaster info all in one place


Also, Puppy devs dont give out specific jobs ...

Some users should be lead devs.. building the ISOs from Woof ...

Some users should be package builders, maintainers .. adding pkgs to woof for inclusion in any woof-built pups..

Some should be apps devs .. making puppy specific apps..

Some should be testers .. posting issues to GitHub or this forum.. all end-users could do this..

Some should be bugfixers .. fixing the issues posted .. all end-users could do this..

Some should be documentation maintainers... literally just updating the docs, readmes, guides, links, etc ..


Well, what am I doing I hear you (quite rightly) ask?

Ibiblio access:

I am currently working on a package manager for Puppy that will make it a lot easier to compile apps from source (supports petbuild, src2pkg, sbopkg, buildpet), and should make it easier for users to maintain and share their own 'contrib' repos for the pup they are running .. Users would be able to add lots of 'contrib' repos just like on Ubuntu etc .. (Only pkgs compiled by the user using the pkg manager would get added to a users contrib repo.. so pkgs would all have to pass the same checks and be built in the same way.. similar to a ports system + contrib repo ..

To that end, I would LOVE to get my hands on GitHub access to WoofCE, as well as an ibiblio account to host the contrib repos there, but their site won't accept new account requests (CAPTCHA not working..) ..

So, If anyone can help me get WoofCE github access(didnt check if i need permission to PR yet), and an ibibilio account that would be great!

As for the latest Slackos being buggy - I guess YMMV for now - I've been running a recent Woof Slacko (32bit) for weeks and weeks, leaving it running for days, compiling loads of stuff.. All works great for me..

Just my 2 cents. Not trying to offend anyone.

EDIT:

Just to be clear - I am NOT having a go at anyone in particular, or puppy users generally.. I myself have been away doing nothing puppy, life hands u lemons sometimes... But this forum is still one of the nicest places on the entire internet in my book, and is full of an amazing mix of people...

We just need to bite the bullet, download woof and use Github to make our puplets, apps, etc .. Maybe with a new workflow, 01micko won't need to be everyones Saviour all the time ... the guy has a life, you know

[belham2]

But to be fair, the documentation on contributing to Puppy development is sparse, sporadic and hard to find.. I still can't find good docs on fixing/updating Woof, and I definitely looked around! .. There is nearly nothing about Puppy dev Git workflow ... And something that slows development is constantly having to return to the forum for fixes, news, etc ..

Puppy Needs Better Documentation!

Scottman,

Nice post. No need to apologize to anyone or anything. It isn't negativity that permeates here, unlike what Toni, er, I mean wiak, is posting about, it's a constructive talk about what needs to be done.

I slam my head up against what you wrote (and I highlighted above). It took me so many builds over the past year just to learn the ins and outs of a few things of woof-CE...all because I could find no documentation on what I needed to know. Woof-CE building was then (and sometimes still is) a hair-pulling experience modifying and changing some stuff in woof-CE to get it like I want it. I don't blame micko or anyone (especially jilst, who has soldiered like a madman keeping woof-CE going). It is just I feel like Micko and others took me on this boat long ago, we got 1/2 way out into the ocean, and a sub appeared and then down he (and Phil went), escaping to Atlantis while we stayed up on the floating Titanic trying to stay alive. It gets frustrating. Then you see something like Fred's DDog build scripts come along, with all sorts or easy-to-understand customizing possibilities, and you wonder why it can't be like that for puppy. No offense to Toni, er, again,I mean: wiak, but his woof-CE build script (and abilities to modify it) are a step in the wrong direction and are honestly a frigging mess compared to Fred's when it comes to ease of use, and the important thing, customization that is easy to understand. That woof-Ce build script is just a fancy candy-wrapper for woof-CE's current situation and does nothing to address the problems underneath---one of which is: the lack of documentation, as you note.

I keep holding out hope something will change. Phil and Micko have gone MIA, and I completely understand about life getting in the way. But mavrothal hit the nail on the head awhile back in this section: where are the knowledgeable, helpful ones to pick this up, to share the burden possibly, to keep things moving forward when they cannot? Can we not make this happen?? Answer: there aren't any at present, and no structure for them to do so. Submitting to git is not so easy to understand and grasp. And furthermore, as an example, did you see what happen in Barry's Quirky 8.3 thread.....my God, the responses to what he was doing there, everyone picking over absolute stupid sh!t, drove him nuts, to where he ran back to Easy Linux. And I don't blame him one bit. He fixed the major problems, but this is NOT true of our two flagship puppy distros right now (Slacko and Tahr/Xenial). They've got problems that are not being addressed, unlike Sailor E and few others who keep catching them & trying to get them fixed. But heck, Sailor got so frustrated, he made a Slacko 14 5.7.1 and I tried it, and it was & is--with no hyperbole--heads and shoulders above Slacko 700s in terms of stability and no problems. The gist is this: I don't want miracles, I just want the major crap to be fixed, and it is not happening with Slacko and/or Tahr/Xenial.

Oh well, I'll keep trying and soldiering on here, but it gets really hard when you keep doing woof-CE builds (mainly 64-bit), like I do weekly, and the same errors from the dev's creations haven't been addressed not for weeks and/or a month or two, but for several months. It leaves you with a feeling that you're going to be eating dead fish on this boat the rest of your days unless you do something else to get off the boat. Thankfully people like Fred, rg66, Peebee are coming by in their stable speedboats & kindly throwing up some bananas, nuts & ice-cream for those of us left on this drifting puppy-liner (lol, sorry for the terrible imagery and/or allegory).

[jd7654]

No offense to Toni, er, again,I mean: wiak, but his woof-CE build script (and abilities to modify it) are a step in the wrong direction and are honestly a frigging mess compared to Fred's when it comes to ease of use, and the important thing, customization that is easy to understand. That woof-Ce build script is just a fancy candy-wrapper for woof-CE's current situation and does nothing to address the problems underneath---one of which is: the lack of documentation, as you note.

Right. A sed wrapper on top of woof-CE scripts does not address the fundamental problem.

[OscarTalks]

What are some things you noticed missing from Debian? How did your kernel-kit building go?

Hi Sailor,
I didn't examine it at length, but icons are missing from tray and system and menus so .desktop files need tidying quite a lot. The core of the thing was working OK. I see that dillo has been replaced with NetSurf.
Looking at it makes me realise how much work I have put in to my remaster. Lots of fixes, updates and programs added. My JWM is now release 2.3.7 with a cluster of fresh themes. Firefox is the Debian compiled ESR. Slight overkill on media players with SMPlayer and GMPlayer and MPV plus VLC optional as .sfs package.

The kernel kit building seemed to go OK, I need to try another woof-CE build where I choose a kernel because the build I did automatically selected the 4.1.38 kernel from ttuuxxx. My extracted kernel sources did seem to work as this package is needed for ndiswrapper, although there was an error at first because of multiple version.h headers so I had to delete a couple so as to leave just one.

[wiak]

Then you see something like Fred's DDog build scripts come along, with all sorts or easy-to-understand customizing possibilities, and you wonder why it can't be like that for puppy. No offense to Toni, er, again,I mean: wiak, but his woof-CE build script (and abilities to modify it) are a step in the wrong direction and are honestly a frigging mess compared to Fred's when it comes to ease of use, and the important thing, customization that is easy to understand. That woof-Ce build script is just a fancy candy-wrapper for woof-CE's current situation and does nothing to address the problems underneath

Ha ha ha, that's almost funny. But no, wiak is not Toni, though it is Toni who led the development of DebianDog and nice work too. Mind you, you write as if mklive-stretch (which is for one distribution only currently) is not a wrapper of a huge, heavily Debian maintained, debootstrap build system... or perhaps you could call it a frontend (such as most Puppy apps/utilities) to an underlying command/script. makepup is also a wrapper/frontend and isn't that what we build here generally - or have you been getting your own hands dirty modifying the internals of Debian debootstrap?

Maybe you should stop complaining (along with your JB friend EDIT: JD) and learn how to contribute to woof-CE itself. Afterall, this is the puppy forum, and Puppy development and how it is or turns out is up to the members. It's not only something to wait on 01micko, for example, doing. You don't even need to learn git if that is too much for you - just join github and you can post suggestions in the comments boxes on github for any particular branch code you have ideas to improve or bug-fix - I did that myself recently and the work was done behind the scenes by jlst (very quickly actually) and now kernels used are correctly archived locally so don't need to be re-downloaded again. That's a positive approach - it's called contributing.

I guess you are too busy using DebianDogs, which are great wee systems, but pity you take time out to insult people working to improve Puppy (whether their efforts are considered useful or not). So, no, I'm not Toni, but I do hope Toni will get back into woof-CE developments because he would be great in that role. Okay, so maybe Puppy struggles against a DebianLive system since no debootstrap done by external big team, and no apt-get (similarly) but still Puppy is worth keeping alive despite some over-the-top Dog-lovers.

EDIT: One thing I do agree with is that the best most important issue is to fix bugs and improve branch distros in woof-CE itself. The difference in my attitude about that is that I think jlst has been doing a great job in the background (with little in the way of encouragement) and that more generally woof-CE is a fantastic piece of work and deserves more in the way of commendations and respect rather than so many comments about 'what is wrong with it'). It's not as if everyone involved with woof-CE isn't better-aware of the issues needing addressed; instead of commenting and comparing to mklive-stretch/DebianDog, which is completely irrelevant comparision and my makepup script has nothing to do with that; to a large extent, makepup is for a different purpose and is not trying to compete with anyone or anything - just don't use it(!), better to start fixing any issues you've noted or want added to woof-CE. Similarly, woof-CE is for a different purpose really than than the Debian-maintained debootstrap, which is another reason makepup should not be compared with mklive-stretch. debootstrap only provides a core debian system (though a pretty complete core) and mklive-stretch (using apt-get) adds to that. woof-CE, on the otherhand provides a mechanism to build a fully-complete Puppy and makepup just provides my frontend to that for my own use or anyone who finds it useful.

Making the woof-CE Puppies more fully-complete is nothing to do with makepup but to do with the distro-branch developers to fix up. For that, I guess you need to get on github and comment or go to the thread for the Puppy distribution you are not satisfied with and comment there. I don't like Palemoon either, by the way, it proves unstable on my systems, but again, that is up to the distro-build developer - or someone else to modify their own branch.

Who is supposed to make woof-CE the way you like it? - the whole puppy community 'owns' it so it's up to all inclusively to remedy any issues (rather than make out is some developer or other that has that 'responsibility'). As for Puppy being now dead, well that's up to the whole Puppy community to make true or false too; it's a completely ignorant RUBBISH of course to make such claims just because someone or other prefers mklive-stretch or one of the pre-made DebianDogs! And stop insulting me just because I'm writing a script you don't like!

And I've personally been involved with Dogs for a long time too - longer than you probably - but I'm not Toni hahaha!

EDIT2: Of course if you really want to create a puppydebootstrap system, well start writing one or convince someone (or some big team) to do it for you if you can't. That's a big job, more than any mklive or makepup script by far, and at a similar complexity to woof-CE I'd say. Anyway, back to my

frigging mess

.

wiak

[jd7654]

As for Puppy being now dead, well that's up to the whole Puppy community to make true or false too; it's a completely ignorant RUBBISH of course to make such claims just because someone or other prefers mklive-stretch or one of the pre-made DebianDogs! And stop insulting me just because I'm writing a script you don't like!

Who said Puppy was dead? If you are making an accusation of someone, just come out and say it. No need for this passive aggressive snide remarks in threads all over the place.

[battleshooter]

I found your post most inspiring Scott. Thank you for the time you've spent on it. I've been following and trying to understand the attempts to shift Puppy development into a structured format.

I have been wanting to help for some time and have almost posted on this thread several times, but lack of clarity in even asking my questions has prevented me. I'm so lost I don't even know what questions I should be asking to help me understand.

So I'll just give it a go. Apologies for my ignorance.

A pup like XenialPup, it's made with Woof-CE from Ubuntu recipes is that right? It doesn't just take ready made Xenial debs and install them?

Having said that, do the little scripts that make XenialPup different from Slacko get put into Woof-CE as well? For example, did Phil add the right click rox menus (right clicking on a directory gives an option to build a pet) outside of Xenial's Woof-CE construction?

I ask that because I wonder if I use Woof-CE and build a Xenial build, will it come out exactly like Phil's XenialPup?

I think the problem for me using Woof, is that I don't want to make my own Puppy from scratch, I like what 666phil's done and would rather work off his wheel than recreating my own. But I see the problem that my changes and fixes will be isolated my remaster. How would I go about adding my changes to Woof-CE? Say I change a desktop file, how do I implement that upstream?

Thank you for your attention, I'm sorry the post isn't very straight forward or if I've missed already detailed explanations. I may have read it but just not understood it.