Woof at Github
If the woof-CE slacko64 mailing list is not sufficient for slacko64(-pre-alpha), may I suggest a "slacko64 unofficial" thread till Mick announces it in the forum?
== [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 saw the post by James and then the item in the screenshot, guess you need to change the "testers welcome" part?mavrothal wrote:If the woof-CE slacko64 mailing list is not sufficient for slacko64(-pre-alpha), may I suggest a "slacko64 unofficial" thread till Mick announces it in the forum?
- Attachments
-
- slacko64news.jpg
- (32.82 KiB) Downloaded 2314 times
I certainly do not mean to discourage any testing.Billtoo wrote:I saw the post by James and then the item in the screenshot, guess you need to change the "testers welcome" part?mavrothal wrote:If the woof-CE slacko64 mailing list is not sufficient for slacko64(-pre-alpha), may I suggest a "slacko64 unofficial" thread till Mick announces it in the forum?
But this being a woof-CE thread is focusing on woof issues and testing woof-CE changes on specific subjects or build processes.
If every woof-CE built puppy was discussed/tested here, would be a useless mess.
Was mentioned some time back in a similar occasion.
Most important, your contribution may go unnoticed/hard-to-find here.
Both Mick and BK pointed to the woof-CE mailing list for slacko64 related discussion (as shown in your screeny too).
== [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] ==
Some news about JWM new release.
http://joewing.net/index.shtml
http://joewing.net/index.shtml
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
After 1000+ commits and over 40000+ lines of code changed, the first woof-CE release is in beta stage.
Please test hard
Please test hard
== [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] ==
After 941original commits and 59.916 lines of code changes in woof-CE since forking from Barry's Fossil, the first official woof-CE-based puppy, Slacko-5.7, is out
Thanks to Zigbert has a brand-new, puppy-only, look while countless under the hood changes assure the wide hardware compatibility, the great out-of-the-box functionality and the minimal size that Puppy is known for, at its best.
Give it a try.
Thanks to Zigbert has a brand-new, puppy-only, look while countless under the hood changes assure the wide hardware compatibility, the great out-of-the-box functionality and the minimal size that Puppy is known for, at its best.
Give it a try.
== [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] ==
Communications
Sometimes my intuition tosses up practical ideas. http://www.murga-linux.com/puppy/viewto ... 508#753508.mavrothal wrote:If the woof-CE slacko64 mailing list is not sufficient for slacko64(-pre-alpha), may I suggest a "slacko64 unofficial" thread till Mick announces it in the forum?
mikesLr
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.Ibidem wrote:Any idea what it would take to do an Alpine (alpinelinux.org) pup?
simargl${n} pointed out on numerous occasions (really kicking us in the guts about it) that old PPM is poor (he described it in other ways, but you get the drift). FWIW he was right, (still, doesn't mean I like you though simargl! . You have the people skills of a dinosaur). It would certainly be beyond the capability of the developer base here to extend good ol' PPM to perfection for every distro that woof supports.
Any help to you?
Puppy Linux Blog - contact me for access
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.01micko wrote: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.Ibidem wrote:Any idea what it would take to do an Alpine (alpinelinux.org) pup?
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Sorry to be so long replying; I've been running mainly Alpine for a little while.jamesbond wrote: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.01micko wrote: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.Ibidem wrote:Any idea what it would take to do an Alpine (alpinelinux.org) pup?
.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
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).
Query re new savefolders
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:
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:
/etc/mtab from Slacko5.9.3 (savefile) booted from sdb2: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 (savefolder) 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
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
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: Query re new savefolders
The way that savefolder is mounted (mount -o bind) generates this.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?
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] ==
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
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
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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].