This one is not. That is the big deal.technosaurus wrote:since most of your projects are contained to a specific directory...
Woof at Github
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
It would make sense to have a stable and a development branch at least anyhow. I think most people would be comfortable with pDesktop in the development branch... either way you can always fork it and later do a pull request when it gets to the point where it won't eat user data and crap MS biscuits.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
It is still unclear to me why pTheme, JwmConfig, pNote, Rox-rightclick, iconswither, gtk-themes (actually all the "no arch" pets) can not go to rootfs-packages or even subfolders where one can have distinct commit rights, but I guess we have to see what you have in mind to understand why you do not like this option.zigbert wrote: As code are put into it, the package becomes more complex. This is not a good solution for a community (I plan to release things when my initial work is done). What is seen in Slacko 6 is just a teaser.
To avoid one big pack, I suggest we open one branch in Woof-CE. That way, we can separate parts of pDesktop - ie pTheme, JwmConfig, pNote, Rox-rightclick, iconswither, gtk-themes, ... - And still consider the branch like one piece (strictly dependent of each other). Integration is the only reason to me to work with this.
- Easier to dive into, and still keep the integration that I insist on.
- Easier to skip extended parts that Puppy-builder doesn't want.
- Easier to fork the work for another DE-opinion.
- Possible to add more additional graphics and themes.
So go ahead with a branch, just keep in mind that a) some builder must build a puppy from it for the rest to see and test and b) that this branch may have issues merging as time goes by, c) that after puppy 6 the build system will likely drastically change
== [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] ==
I see.... shouldn't be easymavrothal wrote:just keep in mind that a) some builder must build a puppy from it for the rest to see and test and b) that this branch may have issues merging as time goes by, c) that after puppy 6 the build system will likely drastically change.
Because (afaik), there is no way to set up a combo-pack with more than one pack inside. Would it be possible to merge sfs-like dirs in rootfs-packages?It is still unclear to me why pTheme, JwmConfig, pNote, Rox-rightclick, iconswither, gtk-themes (actually all the "no arch" pets) can not go to rootfs-packages
Sigmund
Directories within rootfs-packages have the structure of rootfs-skeleton plus an install script if needed, so you can put anything you want in there but you can not put sub-packages.zigbert wrote:Because (afaik), there is no way to set up a combo-pack with more than one pack inside. Would it be possible to merge sfs-like dirs in rootfs-packages?It is still unclear to me why pTheme, JwmConfig, pNote, Rox-rightclick, iconswither, gtk-themes (actually all the "no arch" pets) can not go to rootfs-packages
ie pTheme/ {pinstall,usr,etc,bin} but can not pTheme/{pJWM,pGTK,pROX} etc
Of course you can have each of the pJWM, pGTK etc as directories in rootfs-packages.
If you want to ensure that all packages will be installed (in case a builder wants to drop one or more) just have pTheme package to have an install script requiring the rest.
== [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] ==
Help files
In previous pups, if you were building a derivative you could edit /etc/DISTROSPECS and provide a /usr/share/doc/release-xxx.nnn.htm file and somehow magically /usr/share/doc/index.html would be created customised for your derivative. (i.e Slacko5.7 did this)
This mechanism seems to have disappeared in the latest Slacko6Beta2.
Any ideas why? and is this a deliberate change? and if it is, is there a simple way to achieve a customised index.html?
There seem to be all sorts of .top and .bottom and .raw files in /usr/share/doc that are all created by Woof-CE with the puppy version hard coded in....
Thanks
peebee
This mechanism seems to have disappeared in the latest Slacko6Beta2.
Any ideas why? and is this a deliberate change? and if it is, is there a simple way to achieve a customised index.html?
There seem to be all sorts of .top and .bottom and .raw files in /usr/share/doc that are all created by Woof-CE with the puppy version hard coded in....
Thanks
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
...other distros call them meta packages. ... just add them as dependencies. ... you know that pet spec field that virtually everyone leaves blank because Barry never had a standard way of naming/splitting packages. ... do you depend on ssl or libssl etc... I don't know if this is fixed or not TLDR ...working on basically redoing the whole thing more efficiently and with permissive licensing.zigbert wrote:Because (afaik), there is no way to set up a combo-pack with more than one pack inside. Would it be possible to merge sfs-like dirs in rootfs-packages?
Sigmund
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Yep. As far as I can see it is the best way. Use that field that nobody uses (except yourself ziggy ) and it will be incorporated.technosaurus wrote:...other distros call them meta packages. ... just add them as dependencies. ... you know that pet spec field that virtually everyone leaves blank because Barry never had a standard way of naming/splitting packages. ... do you depend on ssl or libssl etc... I don't know if this is fixed or not TLDR ...working on basically redoing the whole thing more efficiently and with permissive licensing.
What woof really lacks is a configuration fle. It's all too procedural. Do this, then do that, but before you forget do this.. again. Probably the worst idea was the gui. Barry would have spent days on that. If you need a gui to build an OS then .. sorry I digress.
Just commit your packages as you would a pet, but no need of a version number on the directory. Include the pet.specs (which is as normal, including versioning and depends). Don't add binaries though. They can be added by a different mechanism dependent on arch.
Puppy Linux Blog - contact me for access
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I spent a lot of time way back when making a simple jwm config tool:
http://www.murga-linux.com/puppy/viewtopic.php?t=70804
If you want to put it in woof, I can clean it up a bit (more modularized) and update it for new jwm/puppy additions. The jwm package manager example for example probably doesn't work since Barry did his ibiblio shuffle (how is he btw, its been a while since he posted anywhere) and I have a better idea in mind for jwm based drive management (a separate menu with submenus for operations) ... also the jwm dialog and image viewer were just a proof of concept that can go away (though it could be a nice svg viewer for constrained systems now that jwm has svg support)
http://www.murga-linux.com/puppy/viewtopic.php?t=70804
If you want to put it in woof, I can clean it up a bit (more modularized) and update it for new jwm/puppy additions. The jwm package manager example for example probably doesn't work since Barry did his ibiblio shuffle (how is he btw, its been a while since he posted anywhere) and I have a better idea in mind for jwm based drive management (a separate menu with submenus for operations) ... also the jwm dialog and image viewer were just a proof of concept that can go away (though it could be a nice svg viewer for constrained systems now that jwm has svg support)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
As far as I am concerned would be delated to see any pull requests from you to woof-CE. From new code to code clean-/speed-up and everything in between.technosaurus wrote: If you want to put it in woof
Please do.
== [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] ==
network_tray
Hi woof-ce experts.....
In testing 666philb's latest upup builds - unicorn and vivid - a problem with network-tray has been discovered and following testing a fix identified.
The main work has been done by rerwin but I have been helping with the testing.
The fix that needs to be applied to the network_tray source is as follows:
So, is network_tray a part of woof-ce? If it is, how can this change be put into woof-ce? If not, where is the source for network_tray held and who should be requested to make this change?
Thanks
peebee
In testing 666philb's latest upup builds - unicorn and vivid - a problem with network-tray has been discovered and following testing a fix identified.
The main work has been done by rerwin but I have been helping with the testing.
The fix that needs to be applied to the network_tray source is as follows:
It has also been identified that network_tray uses deprecated "gtk_" invocations which should be updated with "g_"replacements where appropriate - rerwin intends to produce a list.Add to the end of the function named "Update" (which is invoked by the call, "gtk_timeout_add(interval, Update, NULL);"), the statement:immediately before the ending "}"Code: Select all
return TRUE;
So, is network_tray a part of woof-ce? If it is, how can this change be put into woof-ce? If not, where is the source for network_tray held and who should be requested to make this change?
Thanks
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Re: network_tray
No it is not.peebee wrote: The fix that needs to be applied to the network_tray source is as follows
<snip>
So, is network_tray a part of woof-ce?
Is a pet that is installed in puppies.
Sources are usually either in BK's repo or in ibiblio and compiled pets in ibiblio.
Phill has access in ibiblio so he can upload the updated pet (with a new version number of course) to be used in future puppies.
== [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] ==
Hi again WoofCE experts....
Is this a WoofCE bug?
missing line from /usr/share/applications/defaults.list
Is missing from both Slacko-5.9.3 and TahrPup-6.0.2
Stops .4fs files being opened correctly in file managers other than Rox.
Is this a WoofCE bug?
missing line from /usr/share/applications/defaults.list
Code: Select all
application/x-ext4-image=filemnt.desktop
Stops .4fs files being opened correctly in file managers other than Rox.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Yes it was . Thanks.peebee wrote:Is this a WoofCE bug?
missing line from /usr/share/applications/defaults.listCode: Select all
application/x-ext4-image=filemnt.desktop
(you may want to get a handle of git/github and submit your own patches though )
In genera if the puppy file is in the woof-CE rootfs-skeleton is a woof bug (could still be if not there but less likely).
Otherwise
Code: Select all
grep defective_file /root/.packages/builtin_files/*
== [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] ==
Files are automatically modiefied after clone ?
Some files are automatically modified after cloning a fork of Woof-CE , there are no changes between Woof-CE and the forked repo, I have only modified only one of the files why these two extra files are also modified just after cloning the forked repo ?
why these two files are modified ? when i did nothing on them ?
files:
it is causing problems while rebase
Code: Select all
root# git clone https://github.com/keyboard-k/howl.git
Cloning into 'howl'...
remote: Counting objects: 20133, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 20133 (delta 3), reused 0 (delta 0), pack-reused 20117
Receiving objects: 100% (20133/20133), 25.92 MiB | 177.00 KiB/s, done.
Resolving deltas: 100% (11233/11233), done.
Checking connectivity... done.
Checking out files: 100% (5833/5833), done.
root# ls
howl
root# cd howl
root# ls
kernel-kit merge2out README-FIRST woof-arch woof-distro
LICENSE README vcs-workarounds woof-code
root# git branch
* master
root# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/firmware
remotes/origin/gh-pages
remotes/origin/master
remotes/origin/testing
remotes/origin/woof-next
root# git checkout -b testing origin/testing
M woof-code/rootfs-skeleton/etc/wvdial_options/APN-VirginBroadband
M woof-code/rootfs-skeleton/usr/local/lib/X11/mini-icons/mini-Desktop.xpm
Branch testing set up to track remote branch testing from origin.
Switched to a new branch 'testing'
root# git checkout testing
M woof-code/rootfs-skeleton/etc/wvdial_options/APN-VirginBroadband
M woof-code/rootfs-skeleton/usr/local/lib/X11/mini-icons/mini-Desktop.xpm
Already on 'testing'
Your branch is up-to-date with 'origin/testing'.
root# git status
On branch testing
Your branch is up-to-date with 'origin/testing'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: woof-code/rootfs-skeleton/etc/wvdial_options/APN-VirginBroadband
modified: woof-code/rootfs-skeleton/usr/local/lib/X11/mini-icons/mini-Desktop.xpm
modified: woof-code/rootfs-skeleton/usr/sbin/sfsget
no changes added to commit (use "git add" and/or "git commit -a")
root# git add woof-code/rootfs-skeleton/usr/sbin/sfsget
root# git commit -m 'added gui patch to accommodate any number of sfsbuttons in the screen (resizable, vbox scrollable)'
[testing 34651f7] added gui patch to accommodate any number of sfsbuttons in the screen (resizable, vbox scrollable)
1 file changed, 4 insertions(+), 2 deletions(-)
root# git push origin testing
Username for 'https://github.com': keyboard-k
Password for 'https://keyboard-k@github.com':
Counting objects: 44, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 713 bytes | 0 bytes/s, done.
Total 7 (delta 6), reused 0 (delta 0)
To https://github.com/keyboard-k/howl.git
92fe1c3..34651f7 testing -> testing
files:
Code: Select all
M woof-code/rootfs-skeleton/etc/wvdial_options/APN-VirginBroadband
M woof-code/rootfs-skeleton/usr/local/lib/X11/mini-icons/mini-Desktop.xpm
Re: Files are automatically modiefied after clone ?
I have not seen this.keyboard wrote:Some files are automatically modified after cloning a fork of Woof-CE , there are no changes between Woof-CE and the forked repo, I have only modified only one of the files why these two extra files are also modified just after cloning the forked repo ?
So you just forked "woof-CE" to "howl" and howl now has 2 additional/modified files? If true is a github bug, but as I said I have not seen this.
Try to start over.
== [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] ==
yes, thanks for the advice I have started over multiple times now the same problem continues. I will install a new copy of latest version of git-core form it's source files (and hope the bug will dissapear). Honestly , the git-core I have been using is very old maybe obsolete , I had installed it from puppy package manager (for ease) , it might have become obsolete... version 1.7 ? I think it's very old. If the problem persists , . it must be a problem of OS. I could install a fresh copy of tharpup and see if the problem continues... might be a hardware issue of the storage devices if it is still there in the fresh copy of tharpup (6.02).
If everything fails I will ask here again on what to do
If everything fails I will ask here again on what to do
Just load the devx. Has git and runs fine in tahr.keyboard wrote:yes, thanks for the advice I have started over multiple times now the same problem continues. I will install a new copy of latest version of git-core form it's source files (and hope the bug will dissapear). Honestly , the git-core I have been using is very old maybe obsolete , I had installed it from puppy package manager (for ease) , it might have become obsolete... version 1.7 ? I think it's very old. If the problem persists , . it must be a problem of OS. I could install a fresh copy of tharpup and see if the problem continues... might be a hardware issue of the storage devices if it is still there in the fresh copy of tharpup (6.02).
If everything fails I will ask here again on what to do
== [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] ==
devx (devx 6.02 i think which came with tharpup 6.02 )is already loaded , it didn't had git though as far as i remember ...why would have gone into trouble of installing git from PPM ? but I will check by unisntalling git from PPM and try.mavrothal wrote:Just load the devx. Has git and runs fine in tahr.keyboard wrote:yes, thanks for the advice I have started over multiple times now the same problem continues. I will install a new copy of latest version of git-core form it's source files (and hope the bug will dissapear). Honestly , the git-core I have been using is very old maybe obsolete , I had installed it from puppy package manager (for ease) , it might have become obsolete... version 1.7 ? I think it's very old. If the problem persists , . it must be a problem of OS. I could install a fresh copy of tharpup and see if the problem continues... might be a hardware issue of the storage devices if it is still there in the fresh copy of tharpup (6.02).
If everything fails I will ask here again on what to do
It sure has git.keyboard wrote: devx (devx 6.02 i think which came with tharpup 6.02 )is already loaded , it didn't had git though as far as i remember ...why would have gone into trouble of installing git from PPM ? but I will check by unisntalling git from PPM and try.
Check in /initrd/pup_ro4/usr/bin
(pup_ro4 is where devx load normally. If you have more SFSs may be ro5, 6 or something depending on the load order. ro4 is the most likely though)
== [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] ==