Woof: build Slacko 5.3

When 01micko released Slacko 5.3, he also published some instructions to fix Woof to build Slacko 5.3 exactly as his release version:
http://murga-linux.com/puppy/viewtopic.php?t=72806

I have only just now got around to putting those fixes into Woof, well Woof2 now. If you go to the Fossil timeline and do an anonymous login, you will be able to see the changes:
http://bkhome.org/fossil/woof2.cgi/timeline

There are a couple of differences in my upgrade:

1. lsmod
I left out 01micko's fixup to move lsmod from bin to sbin, as I cannot see anything wrong with my module-init-tools template. However, I then discovered a bug in 2createpackages -- the lsmod problem should now be fixed, see last commit (c49450a62d).

2. slacko-splash.gif
This already exists at woof-code/boot/boot-dialog/. 01micko has it in support/slacko/.

I have not done a build to test that these changes are sane. It will actually build 5.3+, as I have put in the latest Packages-puppy-slacko-official.

---

Comments

Forum Down Again


Adding Netboot PET to repo
Username: GCMartin
"Months ago, I tested this ability to boot a PC oaver the LAN using a process that was written up using JamesBonds NETBOOT PET. Even thought it has been added to the 64bit Repos, it has never surfaced on 32bit Pup's Repo's. I have tested this on all Barry's distros, all Playdayz distro, all Pemasu's distros, and all of 01Micko's distros. It works. The companion PET is already included in the Repos. But Netboot never made it. Can one simply requests it be added here? Any advice would be helpful.

no lsmod
Username: 01micko
"Just did my first build with woof2 from scratch.. at the end of the pinstall.sh in 3builddistro I decided to take a look for lsmod.. all that's there is a symlink pointing to my running puppy's /sbin/lsmod.. so it's still not fixed.. I ran 2createpackages on module-init-tools package.. Preprocessing slackware 13.37 pkgs database... Checking syntax of PKGS_SPECS_TABLE... Exiting from support/findpkgs, already created up-to-date pkg list: /initrd/mnt/dev_save/new_woof/woof-out_x86_x86_slackware_13.37/status/findpkgs_FINAL_PKGS-slackware-13.37 [i]Processing module-init-tools processing module-init-tools-3.12-i486-2.txz [b]executing (Slackware) post-install script[/b] postprocessing with packages-templates/module-init-tools Script finished. Press ENTER key to exit: [/i] Taking a look now..

re no lsmod (fixed)
Username: 01micko
"Aha! FIXUPHACK wasn't moved where it was intended to be execute, now it is and is working as intended (I think!) Here's the diff of 2createpackages [code]#diff 2createpackages_orig 2createpackages 27a28 > #111210 FIXUPHACK wasn't copied to packages/$(DISTRO_FILE_PREFIX}/$GENERICNAME/ 01micko 687,688c688,691 < if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then < DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK | grep 'yes'`" --- > #if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then #file was never moved where intended #111210 01micko > if [ -f packages-templates/$GENERICNAME/FIXUPHACK ];then > #DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK | grep 'yes'`" > DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-templates/$GENERICNAME/FIXUPHACK | grep 'yes'`" 883c886,888 < if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then --- > #if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then 111210 01micko > if [ -f packages-templates/$GENERICNAME/FIXUPHACK ];then > cp -af packages-templates/$GENERICNAME/FIXUPHACK packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/ [/code] Cheers!

fixed diff
Username: 01micko
"Woops, missed a comment, corrected diff [code]#diff 2createpackages_orig 2createpackages 27a28 > #111210 FIXUPHACK wasn't copied to packages/$(DISTRO_FILE_PREFIX}/$GENERICNAME/ 01micko 687,688c688,691 < if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then < DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK | grep 'yes'`" --- > #if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then #file was never moved where intended #111210 01micko > if [ -f packages-templates/$GENERICNAME/FIXUPHACK ];then > #DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK | grep 'yes'`" > DPISFLAG="`grep '^DISABLE_POST_INSTALL_SCRIPT' packages-templates/$GENERICNAME/FIXUPHACK | grep 'yes'`" 883c886,888 < if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then --- > #if [ -f packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/FIXUPHACK ];then #111210 01micko > if [ -f packages-templates/$GENERICNAME/FIXUPHACK ];then > cp -af packages-templates/$GENERICNAME/FIXUPHACK packages-${DISTRO_FILE_PREFIX}/$GENERICNAME/[/code]

diff again
Username: 01micko
"hmm.. I had already commented line 886, so first patch is ok, delete my last 2 posts if you want. Sorry.

FIXUPHACK fix
Username: BarryK
"01micko, Thanks for that, I have fixed 2createpackages. I never verified the fix before, as I was working on Dpup. A bit lazy, I should have setup for Slackware build and tested that 'DISABLE_POST_INSTALL_SCRIPT' variable.

Thinking
Username: BarryK
"01micko, Woof2 has woof2/woof-code/support/slacko directory. I was thinking of separating out such user contributions, so it is clearer what is a contribution to support a particular build and from a particular person. Maybe I will introduce woof2/woof-contrib/, and the 'merge2out' script will copy whatever is in there to ../woof-out* last (after all the copying of woof-arch, woof-code and woof-distro). Maybe it could have subdirectories based on users, for example, woof2/woof-contrib/01micko, woof2/woof-contrib/rerwin, etc. It would not contain any architecture-specific files (such as binary executables). In fact, it would really need to be further subclassified, for example woof2/woof-contrib/01micko/slacko, inside which can have support/slacko etc. I need to think about this some more. It would be a way in which user contributions could be very quickly incorporated into Woof, for further testing and/or for needs of specific builds such as Slacko. Maybe it should also support patches, say for example woof2/woof-contrib/01micko/slacko/support/findpkgs.patch would be recognised and the patch applied.

re: lsmod
Username: technosaurus
"I use this instead [code]cat /proc/modules[/code] Then I don't have to filter out the headings either instead of modinfo when just looking to see if a module exists, you can simply grep the modules.dep (however, I am experimenting with a single kernel module directory, so I do it with test)

Slacko 5.3.1 released
Username: 01micko
"Well it's out See the forum for announcement http://www.murga-linux.com/puppy/viewtopic.php?p=576108#576108 Please read the release notes! Have fun!

Tags: woof