Page 10 of 12
Posted: Sun 12 Jan 2014, 09:53
by mavrothal
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?
Posted: Sun 12 Jan 2014, 14:24
by Billtoo
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?
I saw the post by James and then the item in the screenshot, guess you need to change the "testers welcome" part?
Posted: Sun 12 Jan 2014, 14:37
by mavrothal
Billtoo wrote: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?
I saw the post by James and then the item in the screenshot, guess you need to change the "testers welcome" part?
I certainly do not mean to discourage any testing.
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).
Posted: Sun 12 Jan 2014, 18:41
by Ted Dog
please provide deltas if you are going to release every week or so..
Posted: Fri 17 Jan 2014, 08:02
by bigpup
Some news about JWM new release.
http://joewing.net/index.shtml
Posted: Sat 18 Jan 2014, 23:58
by BarryK
Posted: Sat 08 Feb 2014, 05:10
by mavrothal
After
1000+ commits and over
40000+ lines of code changed, the first woof-CE release is in
beta stage.
Please test hard
Posted: Sun 09 Mar 2014, 07:11
by mavrothal
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.
Communications
Posted: Mon 10 Mar 2014, 15:04
by mikeslr
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?
Sometimes my intuition tosses up practical ideas.
http://www.murga-linux.com/puppy/viewto ... 508#753508.
mikesLr
Posted: Tue 11 Mar 2014, 22:31
by oldyeller
Hi,
I just wanted to know how big is the master-zip suppose to be?
Cheers
Posted: Tue 11 Mar 2014, 22:45
by mavrothal
oldyeller wrote:Hi,
I just wanted to know how big is the master-zip suppose to be?
Cheers
24 MB
Posted: Wed 12 Mar 2014, 17:37
by oldyeller
mavrothal wrote:oldyeller wrote:Hi,
I just wanted to know how big is the master-zip suppose to be?
Cheers
24 MB
Thanks, I thought that was the size.
Cheers
Posted: Thu 05 Jun 2014, 23:28
by Ibidem
Any idea what it would take to do an Alpine (alpinelinux.org) pup?
Posted: Sun 08 Jun 2014, 05:27
by 01micko
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.
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?
Posted: Mon 09 Jun 2014, 10:49
by jamesbond
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.
Posted: Sun 06 Jul 2014, 05:53
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).
Query re new savefolders
Posted: Mon 07 Jul 2014, 08:36
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
Re: Query re new savefolders
Posted: Mon 07 Jul 2014, 08:44
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"
Posted: Wed 09 Jul 2014, 21:13
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
Posted: Wed 09 Jul 2014, 21:53
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.