Woof uploaded, May 25, 2011

This is the Woof used to build Wary Puppy 5.1.2 final. The commit number is '20110525175644'.

For details on Woof, see blog post on previous Woof upload:
http://bkhome.org/blog/?viewDetailed=02293

A tarball, without history, is also available:
http://bkhome.org/bones/woof/archive/woof-20110525175644.tar.gz


Posted on 25 May 2011, 18:08


Comments:

Posted on 26 May 2011, 23:42 by GCMartin
Boot time Cheat codes for PUPs
Barry, this is probably NOT the right approach for this item, so I apologize if its not. And apologize for being so naive.

All of us appreciate the ability for PUPs to save-sessions for continuation on a reboot. This is successful and has been used by just about everyone, except those who run "full" installs where there is no need for this.

I have always been a proponent of this in my Live media use with PUPs. Personally I don't feel any changes need be made to its present operation as I understand clearly the 'can of worms' this could open.

One thing that many of us have fallen prey to is when, at shutdown, we hit the enter key on the wrong selection, and lose all of the work we did in the session. (I'm sure you have probably done this, as well, as we're all human)

In considering how to obviate this, I thought that if we had a startup "cheatcode" available that would allow pre-selection of how and where "persistence" is to be done, it would allow some of us to use forethought in booting, on how we want our save-session behavior to be.

A 2nd options could be a desktop GUI tool that allows/forces forethought on save-session behavior for the booted-running PUP to use.

Shinorbar's excellent "Personalize Settings" GUI might have an additional option to trigger save-session setup at desktop startup such that it not only accomplishes PUP environmental behavior, but could address specific shutdown behavior as well.

I know you have had others approach this with you. If there is merit to this, maybe next set of changes can begin to offer something along these lines.

hope this helps


Posted on 27 May 2011, 15:55 by Iguleder
Plymouth
Barry, will you be interested in a Plymouth patch for Woof, which runs a graphical boot splash instead of the textual one? It also has a text fallback.

I'm compiling Plymouth - I'm trying to integrate it into 5.2.5 to get a smooth boot splash. If I get it to work nicely with the default theme, I also want to make a Puppy theme and maybe use some GIF to PNG conversion to convert the logo from Woof into a PNG background for the boot splash, for additional consistency and Puppy spirit :)


Posted on 27 May 2011, 23:29 by scottman
zdrv file naming
Hi Barry,

Sorry if this is posted somewhere, I could not find it... But I am updating 'Woofy' (a puppy remaster tool): http://www.murga-linux.com/puppy/viewtopic.php?t=57037

I needed to update, to tackle the new SFS file names, such as:

- puppy_sqzd_4.99.2.sfs
- puppy_spup_1.21.02.sfs
- etc...

But I am wondering if the zdrv file names have changed, too... If so, what would the zdrv SFS file names be for the above mentioned Puppies??

Thanks


Posted on 27 May 2011, 23:35 by scottman
save file stuff for gcmartin
Barry, sorry about the following hijack!

gcmartin, not entirely sure this is what you are looking for, but here are some ideas I plan to make regarding extra pfix options for managing save file settings:

- initrd.gz: add two new "pfix" options:

- "Kiosk" - load save files, but do not save anything.. at all...
- enabled via "pfix=kiosk" at boot
- 'init' script (in initrd.gz) adds "kiosk" entry to /etc/rc.d/PUPSTATE
- rc.shutdown checks for kiosk mode (PUPSTATE), before saving (or not)
- kiosk mode not compatible with PUPMODE 13 - this will not work
- kiosk mode will disable the menu which asks to save the session at shutdown
- "Delay Save" - only save to HDD at shutdown, if at all...
- enabled via 'pfix=delaysave' at boot
- if PUPMODE=13, forces PUPMODE=12 (for frugal installs, to disable real-time save file updates)


I also plan to enable/disable the "ask to save" dialog at shutdown, the one that MU made and I wrongly get credited with, with a pfix=ask2save option...

Any thoughs or ideas, PM me...


Posted on 28 May 2011, 8:49 by BarryK
Re zdrv name
scottman,
Look in /etc/DISTRO_SPECS, which is also kept in the initrd at /DISTRO_SPECS.



Posted on 28 May 2011, 8:58 by 01micko
woof problem
Hi Barry
I have found a disturbing issue with the latest Ubuntu Natty trying to build a Natty Puppy.
Many libs unpack to a new structure. (approx 80)
/usr/lib/i386-linux-gnu
and a few to
/usr/lib/i686
The only approach that I can think of that will address this is to change the package templates for the offending libs, then add the 2 new locations to the LD_LIBRARY_PATH.
The problem with this though is that then we have a "fork". I suppose an "Woof_Ubuntu-Natty_hack" could be applied replacing the "packages-templates" directory with the Natty version.
More later...


Posted on 28 May 2011, 12:25 by 01micko
possible woof solution
hmm..
Not just /usr/lib but /lib is affected too, so that's four possible locations.
I made a rough script to add the stuff to the relevant dirs in the packages-templates dir, I run it from the top level woof dir. (ie where 0setup and 1download etc live)
#!/bin/sh


LIST=`ls packages-templates`
cd packages-templates
for TEMPLATE in $LIST
do
DIRS=`find $TEMPLATE -name lib|sort -u`
[ ! "$DIRS" ] && continue
BASE=`find $TEMPLATE -name $TEMPLATE`
FOUND="`echo $BASE|grep '/'`"
if [ "$FOUND" != "" ];then
for LIBDIRS in $DIRS
do
mkdir ./$LIBDIRS/i386-linux-gnu
mkdir ./$LIBDIRS/i386-linux-gnu/$TEMPLATE
mkdir ./$LIBDIRS/i686
mkdir ./$LIBDIRS/i686/$TEMPLATE
done
else
for LIBDIRS in $DIRS
do
mkdir ./$LIBDIRS/i386-linux-gnu
mkdir ./$LIBDIRS/i686
done
fi
done

It's a bit rough as there will be empty dirs here and there, I'll figure out some clean-up later.

Um.. I'm testing right now and it appears things are processing OK. Let you know if I get a desktop!


Posted on 29 May 2011, 8:03 by BarryK
Re fork templates
Yeah, I it is very unlikely that you would have to fork the templates. Your solution of creating dirs in the templates is ok, but they could also be created permanently in the official Woof -- having some empty dirs not used by other distros is ok, and in fact there are already some templates that do that (also for the Debian/Ubuntu situation where they really do like to mess around with package layouts).



Posted on 29 May 2011, 8:05 by BarryK
Re i686
That just jogged my memory. I'm not sure, but /usr/lib/i686 may be duplicate libraries for i686 cpu, and there are already same libraries in /usr/lib.



Posted on 29 May 2011, 11:35 by technosaurus
symlinks
Re 386/686 dirs in /usr/lib ... why not just make them both a symlink to "." (that is /usr/lib itself)

I have done this for {X11{R{6,7}}}... before and it solved a lot of problems

Just out of curiosity I once also experimented with making all binary directories a symlink to /bin and all lib dirs a symlink to /lib ... the speed gains were only modest, but no problems