Woof-based Puppy builders wanted

[01micko]

I just want to make one point with this post - a very important point

(ha - not that I know enough to be of much testing value, anyways! Just learning, here...)

Wrong. Your ideas and reports are as important as any persons. Doesn't matter the issue, even if you think it is unrelated.

Every slightest bug report is important. When I do a release, I go over the whole previous thread and as many as I can before that and try to reproduce and eliminate the issue. No matter what you test, if something isn't right, report it. It may not be fixed immediately, it may never get fixed, but at least it is documented and will probably show up in a google or duckduckgo search.

[Moat]

Start from the top: make sure contribution to Woof-CE is *not* waste.
How? Get improvement in Woof-CE to the masses!

Completely, totally agree!

How? By releasing puppies based on Woof-CE, more releases, more often!

Now this is the part that worries me (the noob enduser) somewhat, as it seems all too often that new "releases" means non-functional packages and new bugs to chase...? I.e. - more of the same time/effort getting my system set up and running how I'd prefer, and more time/effort spent by you good folks/devs swatting bugs and helping us noobs out.

Hence my thought re; the possibility (would it even be??) of devising a mechanism to allow incorporating Woof-CE improvements (i.e. - "updates" via .pet or similar, installable packages) into an existing, fully-supported LTS Puppy - ideally, without breaking anything. Leaving the full available range of previously compiled, proven packages intact and functional... so all of that hard work wouldn't go to waste!

Is that even a possibility?

Seems like that approach could be the best of both worlds - getting these great Woof-CE improvements to the masses on a regular basis (via an update mechanism) AND preserve all of the previous time/effort/work that went before, in support of the base, core system and it's package/.pet collection.

And over a 5 year LTS support cycle... are you kidding me? In that environment, the potential of Puppy to develop and grow into a OOTB world-beating Linux distro could be mind=blown!

Not that it isn't, already - of course.

Bob

[Moat]

Well Bob (Moat) I'm posting from 666philb's Tahr (built from woof-CE) now.

Yes! Keeping a close eye on that one. Next trip to McD's for a coffee and burger w/the lappie (as I'm on dial-up) - I'll just have to snag it and have a peek...

Bob

[Moat]

There are many discussions throughout the web about it. But here is a short rundown....
Linux fails miserably at the desktop.

Yes - I'm coming to grips with that notion. Frustrating, though! I see so much potential as a fully customizable, all-around home desktop, that just falls this >< short... Part of the fun and attraction, I suppose... And it IS gettin' there!

Bob

[Moat]

Wrong. Your ideas and reports are as important as any persons. Doesn't matter the issue, even if you think it is unrelated.

Thanks, Mick - I'll take that to heart, and do better. Promise!

Bob

[Iguleder]

Anyone interested in building Tahr64?

I'm too busy to lead the development of a Puppy (that's why my contributions are smaller and scattered around many areas), but I think the LTS nature gives us some breathing space. I'll help wherever I can.

Mint sticks to this version and intends to do backports in the future - maybe we could build a Mint Puppy

[jamesbond]

Final teaser:

I've jwm, rox-filer, rxvt-unicode to install and run - all pure Ubuntu packages. This includes gtk2 (rox-filer pulls gtk2) and Xorg (this is the full Xorg - equivalent to have Xorg High installed), with minimal modification to puppy base. Runs with xorg autoconfig (ie no xorg.conf required). Starts desktop with "xinit" (xwin is broken).

Compressed size of the puppy.sfs for i386 arch is 63M - this is *without* minimisation (no cleanup etc).

Building for 32-bit tahr (tested - works)
./deb-build.sh

Building for 64-bit tahr (tested - works)
ARCH=amd64 ./deb-build.sh

Building for 32-bit unicorn (tested for CLI only - works)
VERSION=utopic ./deb-build.sh

Building for 64-bit unicorn (not tested)
ARCH=amd64 VERSION=utopic ./deb-build.sh

Building for 32-bit debian sid (works)
REPO_URL=http://ftp.jp.debian.org/debian REPO_PKGDB=Packages.xz VERSION=sid deb-build.sh

Note: default ARCH is i386, default VERSION is tahr (=trusty), default REPO_URL is for Ubuntu.

All of the above builds uses the same pkglist listed below (except utopic 32-bit where put %exit after gettext).

All test are done with Fatdog's 64 bit kernel, with Woof-CE's initrd. zdrv.sfs is Fatdog's kernel-modules.sfs. Testing done in qemu, in a loopback ext2 filesystem.

deb-build.sh is 350 lines long now.
The package list looks like this:

Code: Select all

# ubuntu puppy pkglist
#
# generic commands: %exit %include %makesfs
# special package commands: %get_pkgs_by_priority %puppy %bblinks %remove
# installer commands: %bootstrap %dpkg %depend %nodepend
# startup default: bootstrap, nodepend
#
# extra param for commands, params can be quoted
# %include     include-file
# %makesfs     output.sfs [squashfs-param]
# %pkg_by_prio priority ["inclusion-egrep"] ["exclusion-egrep"]
# %bblinks     [nousr]
# %remove      pkgname ...
#
# start with %pkgs_by_prio required. Otherwise start with libc6.
#

# base
%pkgs_by_priority "required" ".*lib.*|^tzdata|^bash|^dash|^lsb-base|^ncurses.*|bsdutils|kmod|mount|insserv|mount" "^klibc|.*plymouth.*|mountall"
%depend # enable dependency
coreutils
grep 
gawk
sed
tar
gzip
cpio
mingetty
dialog
gettext

# extra
screen # useful for debugging
file   # check file types

# desktop
%nodepend # udev brings craps of dependencies, so don't do it
libkmod2
udev
%depend   # but enable dep for xorg, makes life simpler for us
xserver-xorg
xinit
x11-utils
x11-xserver-utils

# window managers etc
jwm 
rox-filer # this will pull-in gtk2
rxvt-unicode

# final
%remove initscripts ifupdown sysv-rc upstart mountall # remove extremely toxic packages
busybox-static
%bblinks # fallback for missing utilities
%puppy
%makesfs puppy.sfs -comp gzip -Xcompression-level 1

Are you interested?

EDIT: Test building from Debian too. Add libkmod2 for debian.

[Iguleder]

Sounds great! 63 MB sounds too good to be true.

[mavrothal]

Are you interested?

Put the ISOs out already!
(and the git/fossil repo )

[jamesbond]

Sounds great! 63 MB sounds too good to be true.

That's compressed with "-comp xz -Xbcj x86" - and the size of the puppy main SFS *only* (no initrd, kernel, kernel-modules, syslinux, etc).

Are you interested?

Put the ISOs out already!

Haha, no ISO. It's not quite functional, it only has rxvt, busybox, jwm and rox

(and the git/fossil repo )

yes, I will publish in as branch in my Woof-CE git repo fork.

[scsijon]

1-/

Runs with xorg autoconfig (ie no xorg.conf required). Starts desktop with "xinit" (xwin is broken).
.

James,

xwin needs a xorg.conf, I found this out back when I was mage2 (Mageia2) building. I ended up copying a good generic, 444'ing it so it wasn't overwritten and putting it the default /root when building, it gets overwritten in ram when booting anyway for your live xorg to match the actual config but the old one appears back when starting up pre loading so xwin will work.

2-/ Racy6, Mageia 2 and Puppy Opensuse 2.3

Just d/l'd a new woof-ce and found that the racy6 build system is broken. Since barry's racy6 and my 5.9 are both for t2-9.0 i'm going to use his woof-config and fix this problem at the same time as I incorperate and rebuild my 5.9 . I want to try to use T2's repositry directly, rather than copy individual files to another directory, minimal work I think as it's similar to what I did with my Opensuse 2.3 puppy last year (which has 12 repositries in it's set). ? Is someone rebuilding PPM, if so can they allow for this as they have a 'controller' and repositry for each group of apps.

I really MUST do a clone and local git and upload my changes and additions this month!

Can someone DISABLE woof-ce Mageia Cauldron ASAP please from being built, we still have mageia 2's lists in ours, however Mageia now has mageia 5 in the cauldron repositries.

3-/ X86-64 thought?

I was wondering if those building 64bit puppys \ would consider \ are \ doing their stuff using > woof-arch/x86-64 and woof-distro/x86-64, it's how i've got the Opensuse x86-64 rough coding. It might allow some cross-building to occur.

It looks like i will have some time this month so I will start my list!

regards to all
scsijon

[scsijon]

Hence my thought re; the possibility (would it even be??) of devising a mechanism to allow incorporating Woof-CE improvements (i.e. - "updates" via .pet or similar, installable packages) into an existing, fully-supported LTS Puppy - ideally, without breaking anything. Leaving the full available range of previously compiled, proven packages intact and functional... so all of that hard work wouldn't go to waste!

Is that even a possibility? Bob

Bob, it's only possible until you add a package or new application to the default set, unfortunately, as then you bring an unknown into the equation, such as a link, altered configuration file, etc. and that can all that's needed to stuff up your puppy. I tried it with LTS and T2 a few builds ago and one of my myz (no use apps) woof builds, it's just too easy to break. It's better to add individual package updates, and even then they need to be in the right order with reboots at the right time to bring in individual command and lib files to work, else it's a toasted update.

sorry
scsijon

[jamesbond]

1-/

Runs with xorg autoconfig (ie no xorg.conf required). Starts desktop with "xinit" (xwin is broken).
.

James,

xwin needs a xorg.conf, I found this out back when I was mage2 (Mageia2) building. I ended up copying a good generic, 444'ing it so it wasn't overwritten and putting it the default /root when building, it gets overwritten in ram when booting anyway for your live xorg to match the actual config but the old one appears back when starting up pre loading so xwin will work.

Correct, that's why it is "broken". xwin was originally written in the old days where Xorg was much less reliable than today. It has a lot of workaround to ensure that a user get a graphical desktop - but many of these workarounds are not necessary anymore (some, to the point of being harmful). Example: the old "I change my xorg.conf but my old settings always comes back!" was an attempt by xwin to have hardware-independent setup, so that puppy can be used in multiple machines without problem (xwin keeps a backup of xorg.conf for every graphics hardware it has found before, and copy that backup to xorg.conf every time it is called - thus if you want to change something in xorg.conf, you have to change in that xorg.conf AND in that xorg.conf.backup). Modern xorg.conf needs none of these - just start without xorg.conf and lets it autoconfigure.

I can modify xwin but for today, running "xinit" will do (until xwin is fixed).

Glad to hear from you, scsijon.

cheers!

[Moat]

Thanks for explaining that, scsijon. Even with my limited knowledge of it all, that does help me see how it could throw a wrench into the works... or at the very least, each Woof-level change would then tend to be impossibly complex in trying to accomodate every possible tossed wrench.

Thanks!

Bob

[jamesbond]

Teaser time over. Head here: http://murga-linux.com/puppy/viewtopic.php?t=94101 for the real thing. Let the fun begin

[mcewanw]

[philosophy]What makes Puppy is this forum - and the wealth of software developed and made available by all the contributors to the forum - if a future system does not allow the software on the Puppy forum to be used - pets and sfs's - then to my mind it's no longer Puppy....software does not need to be stored in a single repository to be accessible and useful[/philosophy]

Cheers!
peebee

The above hits the nail on the head in my point of view. Puppy is a playground as much as an everyday used OS.

As for DebianDog... I would hope everything in Puppy world would not end up just being like modified DebianDog systems - DebianDog is just one approach, albeit I think, proving to be one of the good ones (which is why I put effort into that distribution's development).

However, it would be incorrect to suggest that DebianDog is yet just another Debian Live system. It is very much, I feel, a special Debian Live based system which draws on much of what could be called the Puppy philosophy. It belongs on this forum because, aside from the care taken to preserve the correct multiuser operation of its Debian core components, its look and feel, including utilities and small Puppy or Puppy-like apps, is being developed by this forum's members. The major difference, as a playground for Puppy forum members, including those who like to develop new utilities and apps, is that petget (and thus dotpet) is discarded in favour of dpkg (with apt frontend) - (but there are excellent sfs load/unload utilities provided in DebianDog anyway - I often fire up sfs files from Puppy on DebianDog - wine, gimp, inkscape - most all have worked excellently for me). Using a new package manager system takes a bit of getting used to, but it is an easy transition once begun. From the playground point of view, it is a matter of knowing how to package a small utility/app - what to use instead of dir2pet, for example.

Yesterday, I created my second deb package for DebianDog, from one of my puppy apps (pAVrecord) untarred from the dotpet into a directory. To repackage it for DebianDog all I needed was (instead of dir2pet) the DebianDog provided utility make-deb-package, which incidentally was created by a Puppy user and forum member, RSH, for Puppy itself (who incorporated ideas from forum member Semme). And DebianDog developers, in particular Toni and Fred, are likewise providing much information, including small utilities and apps that could usefully be adopted or adapted in whatever Puppy build systems are developed. That collaborative development effort, as peebee alludes, is what this forum, and Puppy itself is all about. That, complex synergy, I say, is what really makes Puppy different from other distributions - it is the forum and the playground of 'Puppy' rather than woof or any other build system to authorize its authenticity.

[sunburnt]

I agree with William ( mcewanw ).
Further more, what`s the advantage to trying to blend Puppy and Debian?
Puppy`s only advantage is it`s extensive boot media types and methods.
And personally I think a CD-DVD is a terrible boot device ( Flash is growling... )
HD, USB, and PXE, ( and soon Web boot ) are the only needed boot methods.

Doesn`t it make sense to just take std. Debian and mod it to do what you want?
Some things about std. Debian I don`t like, but it is a standard, Puppy`s an orphan.
Rather than making another mutt, clean-up Debian so it shines.
.

[jamesbond]

Further more, what`s the advantage to trying to blend Puppy and Debian?

Puppy's versatility and Debian's vast repository.

Puppy`s only advantage is it`s extensive boot media types and methods.

A very worthwhile advantage worth keeping, I would say.

And personally I think a CD-DVD is a terrible boot device ( Flash is growling... )

I'd stay out of politics

Doesn`t it make sense to just take std. Debian and mod it to do what you want?

It does. And I think saintless and his team is doing a wonderful job doing that.

Rather than making another mutt, clean-up Debian so it shines.

Ahh ... but when that modified Debian wags like a mutt, smells like a mutt, and barks like a mutt, in the end you've gotten yourself a mutt

It's just two different approaches to the same goal, really; and there is no reason that one excludes another. Isn't puppy about choice?

[battleshooter]

Isn't puppy about choice?

Package incompatibility between derivatives... so many derivatives = scattered resources/scattered compatibility.

And isn't that one of Puppy's best features and worst flaw?

I really like Moat's suggestions earlier on in this thread. They make sense, but I'm afraid Lobster may be right in that herding developers is like herding cats.

[mavrothal]

After at least 5 major GNU/Linux base distros and few hundreds derivatives of those 5, are we really discussing why have one more or one less?...
Because the next one does one thing better that all the others (I think )