Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 19 Nov 2017, 10:24
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
woof-CE needs you
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 72 of 80 [1197 Posts]   Goto page: Previous 1, 2, 3, ..., 70, 71, 72, 73, 74, ..., 78, 79, 80 Next
Author Message
jd7654

Joined: 06 Apr 2015
Posts: 256

PostPosted: Thu 07 Sep 2017, 18:47    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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.
Back to top
View user's profile Send private message 
OscarTalks


Joined: 05 Feb 2012
Posts: 1631
Location: London, England

PostPosted: Thu 07 Sep 2017, 19:16    Post subject:  

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

Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 371
Location: not Bulgaria

PostPosted: Thu 07 Sep 2017, 20:48    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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, 02:46; edited 1 time in total
Back to top
View user's profile Send private message 
jd7654

Joined: 06 Apr 2015
Posts: 256

PostPosted: Fri 08 Sep 2017, 00:44    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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.
Back to top
View user's profile Send private message 
battleshooter


Joined: 14 May 2008
Posts: 1352
Location: Australia

PostPosted: Fri 08 Sep 2017, 02:13    Post subject:  

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.

_________________
LMMS 1.0.2, Ardour 3.5.389, Kdenlive 0.9.8
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 371
Location: not Bulgaria

PostPosted: Fri 08 Sep 2017, 02:44    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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/viewtopic.php?p=966872#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.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 371
Location: not Bulgaria

PostPosted: Fri 08 Sep 2017, 03:16    Post subject:  

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
Back to top
View user's profile Send private message 
jd7654

Joined: 06 Apr 2015
Posts: 256

PostPosted: Fri 08 Sep 2017, 04:07    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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/viewtopic.php?p=966872#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
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Fri 08 Sep 2017, 04:14    Post subject:  

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

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
mavrothal


Joined: 24 Aug 2009
Posts: 2907

PostPosted: Fri 08 Sep 2017, 04:41    Post subject:  

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” is today slackware- and debian/ubuntu-based and in the past also Mageia and Arch (now abandon due to lack of interest as well as T2 builds).
This is pretty unique and the reason that puppy is classified as an independent distro and not an ubuntu, slackware, etc, derivative.
To achieve that woof has several components and infrastructures.
Kernel building
Kernel building is a fairly robust and straight forward process (was one of the first things I ever did in linux with very little idea of anything else linux related). Woof makes it even easier with its kernel build script. However, the important part that needs developer input is the configuration of the kernel. ie to decide which modules and firmware to include and what goes build-in or as an external module. Do you want to include modules for every imaginable machine and get a 30-50MB kernel or sacrifice 1% of the machines out there, ignore the possible loud complainers and save 10-20Mb in kernel and puppy size?
Which kernel to use? New kernel comes out every month or so and they include support for the latest hardware while they may drop support for (really) older hardware. Does it make sense to use the latest one or use a long term support (LTS) kernel that has all the security updates and is tested extensively? If an LTS, which one? The latest or an older one for better "old hardware" compatibility?
What about kernels from the binary compatible distro? Puppy requires certain modules (aufs, squashfs) to be builtin. Most distro kernel have them as a module, if at all. Also most distros have modules that puppy by design (single root user, no server) will never use/need. So although kernel building with woof-CE is trivial if a binary compatible distro has a compatible kernel, would be OK. Though, then you depend on them for updates and fixes and not the mainline kernel repo.
Modern puppies make kernel change/update easier but the developer still needs to configure them and the builder to pick the "more appropriate" for the target users.
Package selection
The most important part of a puppy build is the package selection. This is defined in woof-distro/<arch>/<distribution>/<version> and basically describes which packages and applications and from which repository will go into the new puppy.
Picking the required packages to maximise functionality and minimise size is a tricky process. (S)he may need to sacrifice a better package for a smaller one, ignore some "useful" apps, use older versions for others apps, etc. Quite often a package from the compatible distro does not work and the developer must compile its own that works better in the specific puppy (abiword, seamonkey etc).
Package trimming
One of BK’s innovations (and source of issues) was the use of package-templates where packages from compatible distros are audited through and whatever is believed unneeded, is distracted. This was to mainly decrease size and some times conflicts. However, this is a high maintenance issue, specially these days with package structure changing often and the support of 64bit puppies, so is used less and less (with the corresponding size increase).
This is another field that a woof developer must look for issues and find fixes, or modify to keep puppy as small as possible, consistent with its "tradition".
Puppy scripts 1
For historical (convenience) reasons a lot of puppy-specific packages were included as flat scripts in the rootfs-skeleton folder as oppose to pet packages added in the build as the other applications and libraries. These are files responsible for the famous puppy “boot in every imaginable way” (init), staring up that main OS, getting you into the desktop (with sound and internet) and taking care of the shutdown/save process.
They too need constant adjustments and improvements. Some times to fix bugs or add features and some times because the developer thinks “is better”.
Puppy scripts 2
These are packages in rootfs-skeleton and rootfs-packages that are mainly the famous pappy-specific bash/gtkdialog applications, themes, desktop files etc. There is an effort to be all moved in rootfs-packages as well as many of the “noarch” pet packages (which are also this kind of apps). However, the original noarch pet developers showed no interest (with few exceptions - zigbert) to include and maintained their apps within woof-CE. In any rate, whatever is in woof may also need improvements/bug fixes from the woof developer.
BTW "common" pet packages do not make any sense today with both 32 and 64 bit puppies available. Should be either noarch or puppy-specific
The puppy package manager
As amigo would say a distro is defined by its package manager. And this is true! We often read praises here about apt-get/synaptic, pacman, slapt-get, dpkg/yum and other "famous" package managers. However, the quality of these managers is mostly based on the carefully and strictly constructed and extensively audited packages (something really far from "puppy culture"). Not the package manager itself. Start adding “questionable” repos and packages, hold-back/blacklist important packages needed for forward/backwards compatibility and the famous package manager loses its glory.
Actually PPM with all its messy development and approach to package handling, is pretty remarkable in what is achieving. It works with packages from any imaginable distro and even plain tgz archives! Try to run debian with dpkg/yam or pacman instead of apt-get, to appreciate PPM!
Can it be improved? For sure. Can it be improved without losing its multi-distro functionality and user friendliness? Probably. Developers are welcome.
The puppy builder should decide here which repos to use, from where and with what priority (if relevant), to minimise conflicts, duplications or even breakage of the build.
z-hacks
The last thing that a puppy builder/developer does is the z-hacks pet that has the final touches and configurations for the specific puppy (s)he is building.
A lot of those could go into woof-CE but builders find it easier to bring the build to an acceptable point and then do the final adjustments with a z-hack pet.

So this is pretty much what Barry Kauler and the 20+ people that contributed code in woof(-CE), did and do.
Now that you hopefully have a better understanding of what woof does and how, instead of cursing the darkness you may want to light up a candle instead. Wink


But maybe you do not like all this convoluted build system and want something nice and simple like the dog building system or other magic bullets. Well, more than 3 years now woof-CE has the woof-next branch developed by jamesbond that builds a puppy in 20min with full compatibility with the mother distro and with the distro package manager (in addition to PPM)! It is also fully configurable in package selection and utilises all puppy infrastructure and scripts! It is unmaintained for more that a year now due to lack of interest. Did any of the critics bother to work with it?…


And talking about git branches, sure more branches can be build for LXDE, XFCE etc. However, the experience is that these are high maintenance or they diverge to something that can not be synchronised anymore with the “main” jwm/rox branch. Would be easier these changes to be incorporated in rootfs-packages, where desktop environment could be selected at build time. But if the developers want to maintain a branch instead, is also fine I would think. For start they could fork and build their own branch in their fork, and when it works satisfactory they can issue a pull request to be incorporated back into woof-CE.

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 upstream (puppylinux/woof-CE in this case) 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. The lack of review is a risky process but given the minimal number of people involved in woof-CE, is the best that can be done at the time.
So as mentioned above, fork woof-CE, make your changes, test that they work as desired and do not adversely affect other processes/builds, issue pull requests and after few successful ones I’m sure current woof-CE members will grant you full access.

About ibiblio access
In contrast to git/github where is hard by design to destroy things (even if you delete everything you just need to revert the "delete" commit to restore it), changes in ibiblio are very hard to restore. To that extend only Barry Kauler and people that build "official" puppies have access (ie the passwords) to ibiblio. I find it prudent and understandable as the entire puppy presence and history depends on it.
If you need a password ask BK or Micko. However, if you have specific packages for your builds, you can either ask a person that has access to ibiblio to upload them or use an alternative server (smokey01 comes to mind) or just use github itself to hold the packages.


There. I’m done!
For epilogue, just remember that the developers do that on their (often limited) spare time for free, because they feel is “fun”. They do really hard work for free only because they enjoy it. If it is not fun they just do not do it…

Edited for clarity and (hopefully Rolling Eyes ) decreased number of typos...

_________________
== Here is how to solve your Linux problems fast ==

Last edited by mavrothal on Sat 09 Sep 2017, 18:08; edited 3 times in total
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2548
Location: UK

PostPosted: Fri 08 Sep 2017, 05:58    Post subject:  

Quote:
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... ?

Quote:
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..

Quote:
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 Razz I don't wanna use Puppys space (puppylinux), I want a new one (puppylinux-contrib)..

Quote:
There. I’m done!
For epilogue, just remember that the developers do that on their spare time for free, because they feel is “fun”. Ie they do real hard work for free just because they enjoy it. If is not fun they just do not do it…

All good info, thanks.

Hopefully my rant didn't come across as a criticism of individuals, all of whom do their best I'm sure..
And most of whom know way more about Woof and Linux generally than I do!

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search

Last edited by sc0ttman on Fri 08 Sep 2017, 09:38; edited 10 times in total
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2548
Location: UK

PostPosted: Fri 08 Sep 2017, 06:13    Post subject:  

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:


Quote:
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..

Quote:
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..)

Quote:
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..

Quote:
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 ...

Quote:
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)

Quote:
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... Rolling Eyes

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2907

PostPosted: Fri 08 Sep 2017, 09:21    Post subject:  

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” button in the upper right corner of the web page.
Logout of github (if you want)
Then in your computer setup git if not set up yet.
Load the devx SFS of your puppy or just install git, and type in terminal
Code:
git config --global user.name <YOUR_GITHUB_USERNAME>
git config --global user.email <THE_EMAIL_YOU_USED_TO_REGISTER_IN_GITHUB>
git config --global core.editor geany # or leafpad, vi, emacs etc
git config --global core.pager '' # or specify more, less etc
git config --global color.ui true # skip if you do not like color in the terminal
git config --global http.sslVerify false
git config --global push.default matching
git config --global push.default simple

and then clone YOUR fork and set original woof-CE as upstream
Code:
git clone https://github.com/YOUR_GITHUB_USERNAME/woof-CE.git
cd woof-CE
git remote add upstream https://github.com/puppylinux-woof-CE/woof-CE.git
git remote -v # to verify what upstream  repos you follow


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 Evil

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1299

PostPosted: Fri 08 Sep 2017, 11:03    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

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 Crying or Very sad
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2548
Location: UK

PostPosted: Fri 08 Sep 2017, 18:01    Post subject:  

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 Evil


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:
# 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/

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 72 of 80 [1197 Posts]   Goto page: Previous 1, 2, 3, ..., 70, 71, 72, 73, 74, ..., 78, 79, 80 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1302s ][ Queries: 14 (0.0115s) ][ GZIP on ]