Woof-based Puppy builders wanted

[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 )

[jamesbond]

I'm afraid Lobster may be right in that herding developers is like herding cats.

battleshooter, you are counted as part of the "developers" group because you build SFS-es (many of which I like and use, thanks!). Now, the real question is not about the cats, its about you - do you want/like to be "herded"?

[jamesbond]

Because the next one does one thing better that all the others (I think )

Tell me about it. I was thinking to add Fedora/Mageia support to woof-next. And then I learnt that they use *different, incompatible* versions of RPM May be next time then

[sunburnt]

Yes of course Puppy is all about choice, I just question the advantages of reinventing Debian`s wheel.
The O.S. structure is what`s std. or not, the polished product is only the O.S.`s interface ( services & apps.).

[slavvo67]

I've considered trying to build a puppy and then I noticed that Woof requires 1/2 TB? Is that right? Not sure if I want to go out and buy a new drive for Woof.

One of these days, I'll take a crack at it...

But if you turn off the number lock and your wifi gets disconnected, don't come running to me!

[battleshooter]

@jamesbond

I think I'm more of an over enthusiastic end user than a dev. Ultimately I didn't create anything and it's not my code. At best a package manager.

But I did consider being "herded" and all it's implications.

If I really was to follow Moat's suggestions I'd take the best of Carolina, and combine it with Slacko or Precise, one of the mainstreams, And then I'd only compile SFSs for the mainstream puplets.

However, I don't have that skill to transfer, and yet I wouldn't be willing to move from Carolina either. So if was a dev, I'd be one of those stubborn cats that wouldn't move in the right direction.