This post was updated on .
I couldn't see a way of finding what everyone was working on, so I'm starting a Topic for mine.
If others want to do the same using their own name at the end in the Subject, i'd be appreciative.
Something like "Projects - Proposed and working on - YOURNAME"
After all we don't really want two people working independantly, but collaboratively on any one item.
Idea is to go back and Mark the Item as Completed when finished / done after peer agreement of
that happening, or Abandoned.if not to proceed, or Defered if too hard at this time or needs
something else happening first.
1- Updates to the Woof-distro-x86-Mageia branch for Mageia 2 and 3
- I have both, but will need a decent "scripter's" help with a leftover problem in a BarryK script
for PPM updating.
2- Proposal to remove Woof-distro-x86-Mageia-Cauldron
- I may (most likely will) start a separate thread as I have quite a lot to say on this one. I don't take the
removal of something like a whole branch litely.
3- Add Woof-distro-x86-Opensuse-12.2, 12.3 and later
- Separate thread I think, as I need (must have) additions to PPM as Opensuse has 12 software
repositories per Version and all may be needed. It's how they work!
- And a few other script changes and additional "bits and pieces" to complete it.
4- Woof Reporting Structure
- I would like to get these marks (buttons) up and running.
- Even if only as a starter opening geany in the right directory.
- Personally would like to have them with a date-time when created, so we don't overwrite earlier
ones, and a "Do you want to delete logs" box appear when you exit woof.
EDIT: strange, some seem to work with one base's build but not another, I shall have too see why, maybe it's just a script problem or just missing.
Other notes on possible projects
1- I wonder if it would be also the time to permantly split Apps from the Basic System as our lovely did
- However I'd also like to go further so I shall open a Topic on this when I have it all "on paper". It would
also be a time to add an extra tab to woof to build these extra sfs's.
2- I'd also like one of our GTK / GTKDialog "Specialists" look at woof's "boxes and screens" and make them
more user friendly and deal with items such as resizing and Horizontal Box Bars and the like.
- Same with PPM.
3- I'd like the devx (and all the others) to be able to reside (by default) in the same directory as the
main-version.sfs instead of the partition level. It would mean a lot for designing and building especially
when only a very minor change that doesn't need a version code change (builder stuffup for example).
4- Maybe it's time to ask Rob Landley (Aborigonal Linux) if we can use some of his stuff in the Woof-Arch
Directory as they have most of the systems already down pat! I'd rather we didn't "reinvent the wheel"
again, as a few have needlessly done in my opinion. Linux is suppose to be a collaborative! not a
competitive operating system.
Got a few others, but I want to think them through first so I shall add them later.
5- Other thing I would like to see is to have Local Repositories at a different location or Partition so you can have a common package storage location rather than a link under the build directories (or as I have been doing and creating the links manually each time i create a new build structure.
I think that's enough to start with!
Over to you for comments please.
PPM needs to be completely rewritten . I personally think that Puppy is a usable compile environment, so am not very inspired to do this.
I quit working on a CE woof, since there is much too much going on ATM , and my push request were rejected , so am not eager to do much .
I started to branch my dozen full installations and push them into my fork . Many files needs fixes there, too and many still to change/add .
THE Main Things
I am working on are rc.shutdown and shutdownconfig .
I started to rearrange much of the code, and still want to disentangle much ( don't know why the fido GUI is inside the choosepartfunc )
I plan to work on a script that
grep -n '[[:alnum]]=`.*` puppy_script >puppy_script.vars
sed -i "$Nr a\check4content"
check_functions calls under these lines , to handle EMPTY and INVALID variables that might break commandlines further down .
Lots of bloat I would add with that then : 300 variables would result in 600 more lines .
I can see 2 pull requests from you in https://github.com/puppylinux-woof-CE/woof-CE/pulls?direction=desc&page=2&sort=created&state=closed
One is implemented (in a different way) and the other was "cherry picked" because the rest as you say
> I am working on are rc.shutdown and shutdownconfig .
> I started to rearrange much of the code, and still want to disentangle much
That is a lot of work!
Having Mageia (and other rpm-based distros) full compatibility would be supper.
Yep, I know
I don't plan on rushing and most of my 4 listed items have (something / a lot) already done locally here
for earlier woof2's. I just have to update for them for the current woof and distro bases and continue on to the end.
With the four starting items, I'm allowing three months+ as I still have to work and try to make some living money. I also want to get back with joew and his JWM and builds the pets again for him. I had to suddenly abandon these due to work and family commitments.
Someone will have to 'do' a decent article or two (please) on creating a patch and 'dealing with requests'. I haven't done either in the past. I just usually upload a new file(s) somewhere and say to rename the old ones and put the new ones there before testing. I also tend to overdo internal file doccumentation including relevant line numbers changed, added or removed, it's an old mini & mainframe habit from the '70"s+. I was known to have more doc than script in a lot of them, but it meant that anyone could work out what I had done in the future when I wasn't around without spending days flipping backward and forwards through code / scropts and the scratching head type functions.
You mean the "coming soon!" bits.. yeah, suppose we can do as you suggested, but it's not a high priority. As for your other suggestions, well create a github account and fork!
Karl my friend.
Please don't be discouraged! I think you dived in a bit too hard and hit your head on the bottom! 12 branches? A bit like a blackberry bush rather than a tree. I can see all sorts of maintenance problems there.
I like that you got stuck in from the outset and value your work. Shutdown does need a lot of work. Just one very simple example (which I will probably commit soon).. wmreboot and wmpoweroff are identical bar 1 line (IIRC, reboot and poweroff too), why have 2 scripts? These are the things we really need to fix. A simple symlink with a case fixes those issues, not that there aren't more in those respective scripts.
I like the ideas you have with busybox too. Please get your tree in order and post more pull requests!
> Someone will have to 'do' a decent article or two (please) on creating a patch and 'dealing with requests'. I haven't done either in the past.
First of all you must have git in your local machine. gitk is a nice and fairly simple git GUI.
Then you must create an github account (no payment needed in open source/public projects) as described here https://help.github.com/articles/signing-up-for-a-new-github-account
Then fork woof-CE and clone it to your local machine as described here https://help.github.com/articles/fork-a-repo
Do your changes locally and when happy (ie check that work as intended) commit them to your local git repository. Then pushed them to your forked github repository
Make sure that you also generate a working branch in your repo because if you diverge way too mach from woof-CE:master/testing will be hard to merge any changes. Your local :work branch can be as "wild" as you want and then cherry-pick changes to your local woof-CE:testing branch and then pushe to woof-CE:testing. Make sure you synchronize with woof-CE:master/testing before you do any changes in your local branch of them, in case file that you changed locally have been already changed upstream. This will complicate merging a lot
When happy with all these, issue a pull request as described here https://help.github.com/articles/using-pull-requests.
I find the major issue to be becoming comfortable with git. You do that and then github is fairly simple.
Thankfully git (and github) are very widely used and for whatever problem you may encounter a google search will provide the correct answer in the first page results, for 95% of the cases.
Is not what you asked but hopefully helps a little.
In reply to this post by 01micko
About branchesThe many branches are mainly to backup my local partitions .
Most of them are earlier attempts with a lot of debugging lines and much confusing code and also coded bloated because I was too much influenced by Barry's and Other's coding style and had too little knowledge .
I even do not test each small commit before committing .
Either I copy the new lines from the file on the current OS
or I copy the file into /tmp, play around and test it, and finally copy overwrite the file in the git directory and commit+push it to GitHub.
The latter case if there is much unknown new to me code.
Shutdown is particularly problematic : Because it runs only once with poweroff, so not much to test several times; and run in the shell unmounts /proc and /sys ...
About using gitI have also started to use two directories : One to work in and push and one to only pull ie named
That way I feel more comfortable in cases I loose the HEAD or get notes that git refuses to switch branches.
Then I can easier figure out how to solve these issues.
Must say that people that have started with cvs and svn back then likely would be more comfortable with git.
My former experiences were just svn co http : //repository.lc/path/to/branch or git checkout http ://repository.lc/path/to/branch
to fetch source to compile .
So the many branches are not intended for push requests.
I intend to use my mirror branch mavrothal-woof-CE-testing to
git branch filename
git checkout mav mavrothal-woof-CE-testing
git pull mav mavrothal-woof-CE-testing
git checkout filename
to push to the mother repository .
I likely would also finally git rm file, copy a working file into the place, git add file, git commit, git push krg branch , so it can be cherry picked.
BUT REALLY : The GitHub is great for having files backed up and be able to work or compare with them without local network ! Honest
BTW I like blackberries ! They are actually my favourite berries . Strawberries are next . Grape and red currant ...
In reply to this post by mavrothal
> First of all you must have git in your local machine. gitk is a nice and fairly simple git GUI.
I don't have git installed. All my pulls are done in githubs web-interface.
> 2- I'd also like one of our GTK / GTKDialog "Specialists" look at woof's "boxes and screens" and make them
> more user friendly and deal with items such as resizing and Horizontal Box Bars and the like.
I have some experience with gtkdialog, and I have done some initial work on this.
I am focusing on the utility-guis. Pop-ups has be another project.
This post was updated on .
Just found a new project for me, I'm labeling it as:
EDIT3: (typos and updated info)
6- complete build of files for t2_racy as 5.9 (woof-distro_x86_t2_V9.0) based on either racy5.5 or 6.0
May just be a minimal system to start with (like myz) but will do the rest when time permits and the basics are working.
It seems that barry started a racy 6.0 but didn't proceed for some reason, although it's in woof. You can't build from it as it wants files that live on barryk's system and are not available at present.
I have found that t2 now has a 9.0 branch and the wanted source packages live there so I shall build and test from racy55 which the rest seems to have been done from. I WILL build t2's 9.0 branch as well for the rest of the racy packages, but when that happens will depend on how it goes with testing and the like.
It's this quarters project.
EDIT1: Just had a go and built the three pets, but as suspected I will need to d/l and pet about 300 t2/9.0 packages to puppy it so that must wait.
However the intel video updates are great with wary/racy55 providing you also add libatomic, all of which I built for it. I shall add a note in the wary/racy 55 thread and where to d/l from on my site.
libatomic fixes a heap of memory/video block and frame problems for intel drivers so may also get some of those machines that couldn't work before now working.
Having a glance of the t2/9.0 branch package versions, it's apparent to me that a lot of the updates are what I would have needed to do anyway to allow the Wayland/Weston systems to co-locate in puppy.
This is an unnounced (till now) woof project I have been playing with for nearly a year now. It also needs a fairly modern processor and a decent memory size to run as well as a fairly recent kernel with suitable setting set on.
downloading the complete t2 v9.0 source branch as it will be easier to do things with a local copy, barryk must have had a lot of it on his home server as both racy6 and quirky6 point there and neither work now as the directories aren't there, I must say t2 v9.0 is becoming very interesting to me as it seems to be able to be multi-platform capable very easily and with that plus aboriginal already being that plus barryk's r6/q6 stuff in woof, well..... I may run with that for a while and see how it goes.
|Free forum by Nabble||Edit this page|