Woof at Github

A home for all kinds of Puppy related projects
Message
Author
Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#196 Post by Ibidem »

jamesbond wrote:
01micko wrote:
Ibidem wrote:Any idea what it would take to do an Alpine (alpinelinux.org) pup?
Well, the way things are going, I'm a little excited by jamesbond's idea. Not because it's Ubuntu but because it could really be adapted to any package management system. So, if you figure out the requirements (which don't seem too hard) any distro can be the parent but still have the wholesome puppy goodness.
That's the idea. As for Alpine linux specifically seems to use its own package manager (apk-tools) - we will need to look at what an .apk file actually is; and whether apk-tools can install to a chroot. If it does, then it should be possible to do so - although alpine linux probably misses a lot of the usual binaries that puppy depends on, and must be heavily modified to work correctly.
Sorry to be so long replying; I've been running mainly Alpine for a little while.
.apk format:
tar.gz containing .SIGN.*.*; .PKGINFO; and the unprefixed installation
preinstallation script is ".pre-install", if present; post-install and post-upgrade are similar.
There's also a .trigger script, and possibly other scripts allowed.
.trigger is called with a list of files after each 'apk' run

apk: cross between apt-get and dpkg.
Available as static binary--'apk-tools-static' is the package, sbin/apk.static is the binary.
Supports install to alternate "root" directory, via -p/--root option.
See http://wiki.alpinelinux.org/wiki/Instal ... n_a_chroot for the chroot install documentation; note that you will need to adjust versions and architectures.

Now, packages:
alpine-base is the boot part, alpine-sdk is ~ devx, but there's no X or udev by default.
You will almost certainly want to add testing/. The "setup-xorg" script takes care of installing X but not a terminal or WM; use

Code: Select all

apk add  xf86-input-synaptics jwm rxvt-unicode icewm cups cups-filters ghostscript ttf-freefont
to get it working more like a Puppy system and add printing.
xfce is the typical DE.
fluxbox is available.
firefox and midori are the main GUI browsers; sylpheed, pcmanfm, geany, Abiword, and Gnumeric are available.
mhwaveedit, mtpaint, and rox are not.
networking will call for network-extras (bridge, vlan, and wireless support).

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Query re new savefolders

#197 Post by peebee »

Hi

There is a significant difference between the contents of /etc/mtab when comparing between Slacko5.7 (with savefile), Slacko5.9.3 (with savefile) and Slacko5.9.3 (with savefolder) in that

Slacko5.9.3 (with savefolder) has 2 entries for /dev/sdxn where sdxn is the boot device/partition. see 3rd section below

This difference is causing problems with pup-volume-monitor (I think).

Is this a deliberate / intended / explainable difference?

Thanks
peebee

/etc/mtab from Slacko5.7 (savefile) booted from sda1:
rootfs / rootfs rw,relatime 0 0
/dev/sda1 /initrd/mnt/dev_save fuseblk rw,noatime,user_id=0,group_id=0,default_permissions,blksize=4096 0 0
/dev/loop1 /initrd/pup_rw ext2 rw,sync,noatime,errors=continue,user_xattr,acl 0 0
tmpfs /initrd/mnt/tmpfs tmpfs rw,relatime,size=160104k 0 0
/dev/loop0 /initrd/pup_ro2 squashfs ro,noatime 0 0
unionfs / aufs rw,relatime,si=4ef255b5 0 0
tmpfs /tmp tmpfs rw,relatime,size=843448k 0 0
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=2,mode=620 0 0
none /sys sysfs rw,relatime 0 0
shmfs /dev/shm tmpfs rw,relatime,size=714728k 0 0
/etc/mtab from Slacko5.9.3 (savefile) booted from sdb2:
rootfs / rootfs rw,relatime 0 0
/dev/sdb2 /initrd/mnt/dev_save ext4 rw,noatime,data=ordered 0 0
/dev/loop1 /initrd/pup_rw ext2 rw,noatime,errors=continue,user_xattr,acl 0 0
tmpfs /initrd/mnt/tmpfs tmpfs rw,relatime,size=140152k 0 0
/dev/loop0 /initrd/pup_ro2 squashfs ro,noatime 0 0
tmpfs /initrd/mnt/tmpfs4 tmpfs rw,relatime,size=27268k 0 0
/dev/loop4 /initrd/pup_z squashfs ro,noatime 0 0
unionfs / aufs rw,relatime,si=7483c233 0 0
tmpfs /tmp tmpfs rw,relatime,size=842940k 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1684992k,nr_inodes=217934,mode=755 0 0
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=2,mode=620 0 0
none /sys sysfs rw,relatime 0 0
shmfs /dev/shm tmpfs rw,relatime,size=751744k 0 0
/etc/mtab from Slacko5.9.3 (savefolder) booted from sdb2:
rootfs / rootfs rw,relatime 0 0
/dev/sdb2 /initrd/mnt/dev_save ext4 rw,noatime,data=ordered 0 0
/dev/sdb2 /initrd/pup_rw ext4 rw,noatime,data=ordered 0 0
tmpfs /initrd/mnt/tmpfs tmpfs rw,relatime,size=140152k 0 0
/dev/loop0 /initrd/pup_ro2 squashfs ro,noatime 0 0
tmpfs /initrd/mnt/tmpfs4 tmpfs rw,relatime,size=27268k 0 0
/dev/loop4 /initrd/pup_z squashfs ro,noatime 0 0
unionfs / aufs rw,relatime,si=dfffd93c 0 0
tmpfs /tmp tmpfs rw,relatime,size=842940k 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1684992k,nr_inodes=217934,mode=755 0 0
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=2,mode=620 0 0
none /sys sysfs rw,relatime 0 0
shmfs /dev/shm tmpfs rw,relatime,size=752836k 0 0
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

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

Re: Query re new savefolders

#198 Post by mavrothal »

peebee wrote:Hi

There is a significant difference between the contents of /etc/mtab when comparing between Slacko5.7 (with savefile), Slacko5.9.3 (with savefile) and Slacko5.9.3 (with savefolder) in that

Slacko5.9.3 (with savefolder) has 2 entries for /dev/sdxn where sdxn is the boot device/partition. see 3rd section below

This difference is causing problems with pup-volume-monitor (I think).

Is this a deliberate / intended / explainable difference?
The way that savefolder is mounted (mount -o bind) generates this.
A lot of puppy mounting utilities have code to compensate for this.
Pup-volume-monitor needs similar code to cope with this "anomaly"
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#199 Post by zigbert »

A suggestion to consider...
I am working with pDesktop. - A mini desktop environment based on JWM, ROX (and GTK).

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.

I know, I have previous come up with ideas regarding this topic, and never done something about it. - And we never know what this ends like, but I feel this is a better idea than my previous when it comes to the disagreement on flexibility contra integration.

Does this sound reasonable?


Sigmund

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#200 Post by technosaurus »

since most of your projects are contained to a specific directory, I would recommend starting it as a separate project (see my post in cutting-edge) and then using git's submodule in woof to include your project at that directory. This would allow you to work from your working copy.... really all active projects should be using submodule. You can also just create a branch to re-merge later but that makes it more difficult for other projects to use it.
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].

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#201 Post by zigbert »

technosaurus wrote:since most of your projects are contained to a specific directory...
This one is not. That is the big deal.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#202 Post by 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.
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].

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

#203 Post by mavrothal »

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.
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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#204 Post by zigbert »

mavrothal 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.
I see.... shouldn't be easy :D
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

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

#205 Post by mavrothal »

zigbert wrote:
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Help files

#206 Post by 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
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#207 Post by technosaurus »

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

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#208 Post by 01micko »

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.
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.
Puppy Linux Blog - contact me for access

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#209 Post by 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)
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].

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

#210 Post by mavrothal »

technosaurus wrote: 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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

network_tray

#211 Post by 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
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

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

Re: network_tray

#212 Post by mavrothal »

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?
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#213 Post by 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.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

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

#214 Post by mavrothal »

peebee wrote: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 :D . Thanks.
(you may want to get a handle of git/github and submit your own patches though :wink: )
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
keyboard
Posts: 148
Joined: Sun 30 Nov 2014, 15:33

Files are automatically modiefied after clone ?

#215 Post by 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 :?

Post Reply