woof-CE needs you

News, happenings
Message
Author
User avatar
OscarTalks
Posts: 2196
Joined: Mon 06 Feb 2012, 00:58
Location: London, England

#1061 Post by 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).
Oscar in England
Image

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#1062 Post by 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
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#1063 Post by belham2 »

Sailor Enceladus wrote:
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

:shock:

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

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

Woof-CE, Git usage, etc

#1064 Post by 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 :roll: .. 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..
Image

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 ;)
Last edited by sc0ttman on Mon 11 Sep 2017, 09:19, edited 1 time in total.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

Re: Woof-CE, Git usage, etc

#1065 Post by belham2 »

sc0ttman wrote:
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
Posts: 296
Joined: Mon 06 Apr 2015, 16:10

Re: Woof-CE, Git usage, etc

#1066 Post by jd7654 »

belham2 wrote: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.

User avatar
OscarTalks
Posts: 2196
Joined: Mon 06 Feb 2012, 00:58
Location: London, England

#1067 Post by OscarTalks »

Sailor Enceladus wrote: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.
Oscar in England
Image

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

Re: Woof-CE, Git usage, etc

#1068 Post by wiak »

belham2 wrote: 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
belham2 wrote:frigging mess
.

wiak
Last edited by wiak on Fri 08 Sep 2017, 06:46, edited 1 time in total.

jd7654
Posts: 296
Joined: Mon 06 Apr 2015, 16:10

Re: Woof-CE, Git usage, etc

#1069 Post by jd7654 »

wiak wrote: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.

User avatar
battleshooter
Posts: 1378
Joined: Wed 14 May 2008, 05:10
Location: Australia

#1070 Post by 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.
[url=http://www.murga-linux.com/puppy/viewtopic.php?t=94580]LMMS 1.0.2[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94593]Ardour 3.5.389[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94629]Kdenlive 0.9.8[/url]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

Re: Woof-CE, Git usage, etc

#1071 Post by wiak »

jd7654 wrote:
wiak wrote: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.
Not just an accusation, it's a fact of what you said. Eat your own words rather than make your disingenuous claim of innocence:

Your Puppy-put-down comment of yesterday:

http://www.murga-linux.com/puppy/viewto ... 872#966872
jd7654 wrote: In my mind, Puppy kind of died when BK retired from it. Anything put out now I just accept that it is what it is. I don't blame Micko's if he has other priorities, or Phil for checking out. A project is never the same without the founder. Sad but true.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#1072 Post by wiak »

I used 01micko's Slacko 5.3.3 for years. He created that official Pup, one of the best Pups ever IMO, long time before BarryK retired. I don't know much about the Slacko that came after that one because for a further long time I moved on to Iguleder's very efficient and fast, and unofficial, Puppy GuyDog, which became my next favourite. Prior to these, I considered BarryK's official Puppy 4.3.1 and 2.17 the best. Then came Toni's DebianDog, particularly the Wheezy JWM version, which was a breath of fresh air for a while (and very carefully crafted in terms of Debian Stability).

I do like Fred's openbox versions though, but none of that Dog work should ever be compared or used to try and put down Puppy itself IMO - those who do so come across (to me) as very disrespectful. Thankfully, on the whole, the DD developers themselves tend not to comment so negatively against Puppy, though I do think it is fair enough that Toni, for example, has said DD can do anything Puppy can do, which with the full force of Debian behind it surely should! But this remains the Puppy forum, not the Debian forum despite the Dogs being accepted as part of the kennels (which is a very generous acceptance really, which we of the Dogs-team should be thankful...).

But for now at least, I prefer to try and help with Puppy and once I am satisfied with makepup I plan to put my efforts into helping out with woof-CE itself. I continue to use my XenialDogs daily, however, but I would be very sorry if my DD usage/inputs have in any way damaged Puppy Linux itself - I'm sure Toni didn't and doesn't want that to happen either, but you'd have to ask him. As I said belham2, I am not Toni.

wiak

jd7654
Posts: 296
Joined: Mon 06 Apr 2015, 16:10

Re: Woof-CE, Git usage, etc

#1073 Post by jd7654 »

wiak wrote:Not just an accusation, it's a fact of what you said. Eat your own words rather than make your disingenuous claim of innocence:

Your Puppy-put-down comment of yesterday:

http://www.murga-linux.com/puppy/viewto ... 872#966872
jd7654 wrote: In my mind, Puppy kind of died when BK retired from it. Anything put out now I just accept that it is what it is. I don't blame Micko's if he has other priorities, or Phil for checking out. A project is never the same without the founder. Sad but true.
Thank you for quoting that, wiak. As you can see, if you have any reading comprehension, is that I did not claim that Puppy was now dead, as you falsely insinuated. I said "kind of died" which is not dead, only to a degree, and qualified with "in my mind" which is my opinion or feeling, not a proclamation of the state of Puppy.

I merely stated a common refrain around here, that Puppy is not the same without BarryK. "Barry come back" or that kind of nostalgia for the old days when the direction, vision and spirit of Puppy came from our fearless leader.

But since you are a Brit, I would've assumed your English comprehension would be pretty good. Well, maybe it is? So the other explanation is that you are deliberately being deceitful and dishonestly misrepresenting comments in order to be antagonistic and sow division. That I'm afraid is even more regrettable than reading comprehension problems and really shows your true character, wiak. But I'm not surprised.

The way you started your makepup script thread was mildly sleazy. Sure you gave some credit to Woof-CE, but the way you put it out, in an attention grabbing "come try my script which makes a Puppy!" when really if is just a automation wrapper front end for woof-CE, woof-CE makes the Puppy, not your script, which is how it should have been explained. And then you go and scold the lead developer of woof-CE for making a momentary change that caused a problem with your script. Man, what and arse. Maybe you should have started the script in woof-CE where it belongs. And finally, your ego having so swelled that you are now dictating to Puppy forum members what they need to be doing.(Your vanity version download counter is quite funny actually, just confirms the attention grabbing nature)

Look, I could care less about your script. My comments you falsely characterized above were just discussion with another forum member. I was actually defending Micko and Slacko. Had nothing to do with your little script. Don't get your panties all in a wad, the world doesn't revolve around you wiak, relax and take a chill pill. Don't be so paranoid and insecure.

And I don't think it's necessary for you to belittle Fred's mklive script to try and elevate your own work. I won't compare except to say that his is more than just a front end to debootstrap. And to top it off, he's not an arrogant prique. :wink:

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#1074 Post by saintless »

wiak wrote:... I would be very sorry if my DD usage/inputs have in any way damaged Puppy Linux itself - I'm sure Toni didn't and doesn't want that to happen either, but you'd have to ask him.
Don't waste your time answering provocations from people like that. Just ignore them and work on what you like in public, or in silence, or take a long break and continue later.

I posted many times what DebianDog should be in this forum. My first post about that:
saintless wrote:The main reason I post this is to give a chance for anyone who has troubles installing programs in his favorite puppy to use this small debian core, apt-get the needed program and have it working in a few minutes.
If there is no interest or the site administration feel this topic should not be here, please, move it where it fits better.
From already deleted thread:
saintless wrote:I started the DebianDog project as light-debian-core-squeeze and it was renamed to DebianDog. It is a humble alternative for Puppy linux users. So they can feel at home using DebianDog and have access to main distro repository. Very similar to Sickgut's and JBV's ideas. And most of what I know I learned from them.
DebianDog shouldn't compete with Puppy linux. It is here to help puppy users not to waste weeks or months trying to get some application working on puppy linux. DebianDog should help Puppy linux. It should look and feel like regular Puppy linux system.
I can dig out many more but there is no point.

About Woof-CE - I will not share my opinion unless I have some fix for it or suggestion for improvement. I find the code a little bit complicated for new commers to work on it. You should use Puppy as your main distro to work on Woof-CE and test the changes and I don't use Puppy often anymore. If I decide to work on something in woof-ce someday it will be woof-next branch with sure. It is some kind of broken at the moment ( I can't produce bootable iso now) but works from any linux system and you don't have to use Puppy to experiment with woof-next.

All the best wiak with your work on Puppy or Dog or any other linux project. I like your choice of license too.

Toni

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#1075 Post by mavrothal »

Understanding Woof and woof-development
Given the void in puppy releases there are a lot of discussion about its build system (woof) as it may be responsible for the slow releases, interestingly from people that I think do not fully understand what woof(-CE) does and how.
So let me give my take on that and on the side address issues as ibiblio, github branches, build scripts etc
Is going to be a long post.
First things first though. What woof does and how
As wiak showed, a single script can build a puppy from woof but this is not going to be any different that existing puppies. Maybe with some changes in files in rootfs-skeleton (more on that later). It is nice for what it does but is not helping building a new puppy or changing woof.

What woof does is to provide an open source, human-readable method to build a distribution from a mix of home-grown, specially-compiled and other-distro packages.
Where “other-distro
Last edited by mavrothal on Sat 09 Sep 2017, 22:08, edited 3 times in total.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#1076 Post by sc0ttman »

Would be easier these changes to be incorporated in rootfs-packages where desktop environment could be selected at build time. But if the developers what to maintain a branch is also fine. For start they could fork and build their own branch in their fork, and when it works satisfactory can issue a pull request to be incorporated back to woof-CE.
That is exactly what I talked about. The branches or not permanent - you build your feature/puplet, then your done, then you merge back into develop, then the branch can be deleted entirely..
Although best not to delete it for a while, just in case further updates to that feature/puplet need to be made..

Maybe the uber devs should send out requests to some forum users, nagging them get on GitHub, fork woof..
A standard, explanatory 'copy-and-paste' message (with some code snippets) in a few peoples inbox might do wonders..

I think mavrothal is currently the most knowledgable Woofer around at the mo.. Maybe best placed to pass round that info, help others out?

But anyway, the workflow I mentioned works for the BBC, Financial Times, etc - with hundreds in in-house projects..
I worked on something way bigger than Woof-CE, which inc git submodules, Docker, etc, etc, teams of 4 or 5 devs, always changing..
The workflow still works fine, people just need to know how to do it..

The key is to create branches that pertain to only ONE feature or bugfix, and to make lots of small commits.

It's not a big change from what Woof devs are doing right now, but this worflow would encourage puplet
devs to get involved in woof a bit more i think..

What puppy might need is a Trello or JIRA board, so people can see the 'tickets' available... Each ticket is a piece of work to be done, with some notes, tips,
and an estimated time to complete.. People can assign themselves tickets, create a branch for that ticket, do the work, then create the PR..

If a dev goes AWOL or moves on, the list of work to be done is still there, and anyone can take it, and very importantly, then *everyone else* can see
exactly what work is being done, by whom, and what work is not being done.

GitHub has a Projects tab, with a sort-of Kanban board... It might suffice to use that to get a few more devs coming and going, picking bits of work up as they get time... ?
About github access
The idea of the collaborative projects is that changes are done in forked repositories and when finalised to the developer’s liking are pushed as a pull request in the puppylinux/woof-CE repo. The requests are reviewed by other members and if OK are pulled into the main repo. However no-one has the time (or the desire/will to argue) on pull requests, so after few successful pull requests an interested participant is given commit rights so (s)he can change anything without review from others. This is a risky process but given the number of people involved in woof-CE is the best at the time.
So as mentioned above, fork woof-CE, make your changes, issue pull requests and after few successful one I’m sure current woof-CE members will grant you full access.
Got it.. Not optimal, bit weird, but got it.

At work, we don't bother with the forking - you just do a PR and if the person checking it (ergo the BOSS) says it's crap, then it's crap. No arguing.
Only good PRs get merged, as the big dogs see fit. Often the PR checking is delegated to a normal dev, but all work must be PR'd and checked.

It's surely more work for the senior devs to quality control work that gets committed straight in..

But OK got it. Will do some PRs if I learn enough about Woof to contribute something useful..
About ibiblio access
In contrast to git/github that is hard by design to destroy things (even if you delete everything you just need to revert that commit to restore it), changes in ibiblio are very hard to restore. To that extend only Barry Kauler and people that build the official puppies have access (ie the passwords) to it. I find prudent and understandable as the entire puppy presence and history depends on it.
If you need a password ask BK or Micko for it. However, if you have specific packages for your builds, you can either ask a person that has access to upload them, or use an alternative server (smokey01 comes to mind) or just use github itself to hold the packages.
Got it.. I still want an account tho :P I don't wanna use Puppys space (puppylinux), I want a new one (puppylinux-contrib)..
There. I’m done!
For epilogue, just remember that the developers do that on their spare time for free, because they feel is “fun
Last edited by sc0ttman on Fri 08 Sep 2017, 13:38, edited 10 times in total.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#1077 Post by sc0ttman »

battleshooter wrote: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.
Hi battleshooter.. I am TOTALLY not the right person to answer you, (I ALSO don't even know what questions to ask when I wanna get involved due to the lack of docs)... But here goes:

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?
Like all pups, the Xenial pup is a mix of Puppy .PETs, puppy scripts, and lots of pkgs from the source distro (.debs from xenial in this case).. then some hacking/fixing (inside woof, during build process) to make it all play nice..
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?
He may have added that right-click option by including an extra package (so yes, in woof), or he may have manually added it after (remastered his own woof build)... No idea... A bit of both I'd imagine - mostly done in Woof, with some manual fixings??.. Unless someone can confirm Woof-CE build XenailPups identical to Phils offerings...? And if not, what's different?

Again, puppy needs a proper dev procedure here... At work we use the "get hit by a bus" method.. If Phil, 01micko, mavrothal and others were hit by a bus tomorrow, then who could step in and immediately continue the work they would have been doing? A LOT of our time at work in spent doing "paired programming" or in meetings doing "knowledge sharing" to get around this problem...

Having tickets (or for us, the well-explained, well-documented Issues on GitHub that any users can tackle and make PR are a good start..)
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?
Give it a go... What's the worst that can happen? A failed build ..

I doubt it will be the same, but anything you dont like or doesnt work, you can post issues and comments to GitHub (and to forum), then fixes get done on GitHub, then you pull down latest from GitHub, then you rebuild a new (more fixed) Xenial.. Rinse, repeat..
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?
First is to fork (download) Woof and make it build a pup.. then test your pup.. Maybe in qemu or vbox..

Next step - see mavrothals post above, or search/wait for some documentation on "HOW TO BUGFIX A PUPPY, IN WOOF", "HOW TO ADD PKGS, IN WOOF", etc ...
Say I change a desktop file, how do I implement that upstream?
Easiest way is to fork woof, make changes inside woof folders, then commit the changes and make a pull request, apparently.. (see mavrothals post above)
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.
no prob, you are not the only one running around looking for HOW to use woof... :roll:
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#1078 Post by mavrothal »

sc0ttman wrote: Maybe the uber devs should send out requests to some forum users, nagging them get on GitHub, fork woof..
Unfortunately there are not uber devs, not even devs at this moment.
And people have been repetitively "encouraged" to contribute to woof-CE or release puppies that they build, and yet....
Just the same I'll just do setup/forking/cloning routine once more in case some have missed it...

Get a free github account
login to github
Fork https://github.com/puppylinux-woof-CE/woof-CE from the “Fork
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

Re: Woof-CE, Git usage, etc

#1079 Post by belham2 »

jd7654 wrote:
wiak wrote: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.

Jd,

Let's not push this....yes, wiak is Toni and Toni is wiak. They make the exact same lingusitic and even down to spelling the exact same words wrong, and using the same disjointed conjuctions. It is his modus operandi to act and accuse people of going straight at him, when in fact he has nothing to do with the conversation other than being a fly (like us all) on the elephant's a## that is woof-CE. Toni still burns over the thing Fred and the DDogs, he'd previously said he'd let it go, but has not and has been feverishly working (under the wiak moniker, which suddenly came back to life after the Toni ID said peace shall exist----but we all knew that was too good to be true). So let's just let it go......toniwiak will keep it up, yes, it is disheartening, but there's nothing that can be done and truly it is inconsequentail.

Important thing is people like Scottman, Battleshooter,Oscar, rg66, Mavrothal (hopefully Geoffrey too) and PeeBee are reading this stuff and possibly a soon very constructive dialog can begin. Woof-CE has so much potential...but somebody(s) who have the skills have to step up to first, help Jilst, and then help the Devs themselves. The Devs need to let their babies loose in the wild so they can re-born with a dual and/or triple headed hydra head. This situation as it is with sole developers can't continue, and is not a recipe for long-term survival.

I still cringe at one of the last comments Barry wrote years ago before he finally turned it (the driving of Puppy forward) all over-----to say he not was "prescient" then is like saying Prez Trump doesn't know how to stir things up. The very thing we are and have been seeing this past year with regards to puppy overall Barry warned against letting it happen.

Question now is: how can it be rectified, and strcutured to make it better and not allow it to happen again. I wish I was gifted enough with coding and Linux that I could tell Micko to go to the beach for a few more years, I'll drive it forward and learn from Peebee what it takes to stay on top of it. Unfortunately, this old man's skills are pushed to the limit with what little I already do concerning Puppy. Even my Dpup I made & released some months back stunk because Ttuuuxxx has more skill in his pinkie than I do in my whole body :cry:

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#1080 Post by sc0ttman »

mavrothal wrote:So now you can do anything you want in your fork of woof-CE locally and upload to your fork while following any other changes in upstream woof. When you like and tested your final product you can push back to woof-CE (with a pull request) or just ignore woof-CE and make your own puppy spin. :twisted:
So (just for complete-ness), and so I (and others) are sure..

How would users pull the latest rationalise or testing stuff from the mainline woof-CE into their fork?

If users want to makes lots of changes over time in their fork, it is essential they keep up to date
with the branch that they (may) want to (eventually) merge back into.

I assume, after following your steps, the fork is setup to then allow something like:

Code: Select all

# in your fork of woof-ce

git fetch upstream             # pull down all branches from upstream (puppylinux/woof-ce)
git checkout rationalise         # go to your forked version of rationalise
git merge upstream/rationalise      # merge in updates from upstream rationalise

# Note, instead of using 'git merge', there is also 'rebase', 
# which fetches the latest from upstream, then 'replays' your 
# local work on top of the fetched branch

# git rebase upstream/rationalise


.. and that this would be enough to pull down the latest changes in woof-CE into a user fork.. ?

See: https://help.github.com/articles/syncing-a-fork/
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

Post Reply