Woof at Github

[zigbert]

since most of your projects are contained to a specific directory...

This one is not. That is the big deal.

[technosaurus]

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.

[mavrothal]

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.

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

[zigbert]

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.

I see.... shouldn't be easy

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

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

[mavrothal]

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

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?

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

[peebee]

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

[technosaurus]

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

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

[01micko]

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

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.

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.

[technosaurus]

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)

[mavrothal]

If you want to put it in woof

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.
Please do.

[peebee]

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:

Add to the end of the function named "Update" (which is invoked by the call, "gtk_timeout_add(interval, Update, NULL);"), the statement:

Code: Select all

return TRUE;

immediately before the ending "}"

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.

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

[mavrothal]

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?

No it is not.
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.

[peebee]

Hi again WoofCE experts....

Is this a WoofCE bug?

missing line from /usr/share/applications/defaults.list

Code: Select all

application/x-ext4-image=filemnt.desktop

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.

[mavrothal]

Is this a WoofCE bug?

missing line from /usr/share/applications/defaults.list

Code: Select all

application/x-ext4-image=filemnt.desktop

Yes it was . Thanks.
(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/*

to see which package the file is coming from.

[keyboard]

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 ?

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

why these two files are modified ? when i did nothing on them ?

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

it is causing problems while rebase

[mavrothal]

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 ?

I have not seen this.
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.

[keyboard]

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

[mavrothal]

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

Just load the devx. Has git and runs fine in tahr.

[keyboard]

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

Just load the devx. Has git and runs fine in tahr.

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]

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.

It sure has git.
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)