Woof uploaded, November 10, 2011

This is commit '20111110213851', used to build Wary and Racy 5.2.1.90 (5.2.2 Release Candidate).

The last upload of Woof was October 27:
http://bkhome.org/archive/blog2/201110/woof-uploaded-oct-27-2011.html

There was a blog post awhile back on how to download a recent snapshot tarball of Woof and use that as the reference to download Woof changes since then, without the full history:
http://bkhome.org/archive/blog2/201105/bones-022.html

I have uploaded a snapshot tarball of commit '20111110213851'. This can be downloaded by itself, but it is recommended to also download the Bones infrastructure as described in above link. Get tarball:
http://bkhome.org/bones/woof/archive/woof-20111110213851.tar.gz

To download and use Woof, please read the Bones intro page:
http://bkhome.org/bones/
And the Woof intro page:
http://bkhome.org/woof/

---

Comments

x86_64
Username: Iguleder1
Barry - here's a small progress report about my 64-bit porting efforts. So far I've got about 150-200 build scripts for many packages, which cover all the "common" repo except three ancient and non-crucial package. Now I'm writing the Busybox build script, with your configuration - thanks for uploading it, every configuration you upload makes the porting efforts easier. Once this one is ready, I think it's time to build a 64-bit initramfs. I already have a 64-bit kernel I built about half a year ago when I built a "hybrid" Puppy that uses a 64-bit kernel with the traditional 32-bit userland. I think I could use this kernel and replace "i386" with "amd64" in Woof, to produce a 64-bit Puppy. Then, this one could be used to bootstrap all packages, including a new kernel. This trick could be used to port Puppy to any architecture, by the way :)

pupdialog - bootmanager prob
Username: pemasu
"http://208.109.22.214/puppy/viewtopic.php?p=581883&sid=e4b124e6182c38dcca0baa800e1c7d08#581883 I seem to have pupdialog - bootmanager with 27.10 woof and 3.1 kernel dpup. Changing pupdialog - filemnt - bootmanager to use this new woof versions didnt help.

re pupdialog
Username: BarryK
"pemasu, I don't understand. I looked at the link you provided, and it reports a problem with pupdialog, that was fixed in later Woof. So, what is the problem?

pupdialog error is still there
Username: pemasu
"Sorry. I typed hastily. I used 27.10 woof. I didnt have your latest woof at the build time in my hands. So...there is after savefile creation and rebooting that pupdialog error box saying: ERROR: There are too many menu items for pupdialog to handle. Aborting. Okay. I downloaded latest woof of this day and replaced pupdialog - bootmanager - filemnt from it to use in this puplet. But the error message does not go away. I still get same error after file replacement. Yeah, I have about 50 sfs in /mnt/home or more....

continues...about pupdialog
Username: pemasu
"I just thought if there is other files which would need the replacement. So I am asking advice about what else needs to be done. Or..is there still something wrong with setup which causes this. I will soon start to build with latest woof anyway.

sfs-load, otf sfs loader
Username: 01micko
"I use Shinobar's brilliant sfs_loader as do many recent puplets (including exprimo). Barry, as a suggestion, can you add code to the bootmanager to detect if sfs_load is present and open that instead of throwing the error? I have over 100 sfs in /mnt/home (on my each of my 3 Puppy partitions!.. yes over 300!) [url=http://murga-linux.com/puppy/viewtopic.php?t=64354]shino's sfs_load, also supports unionfs.

re sfs_load
Username: BarryK
"pupdialog has a limitation on number of items. I extended it, but still not enough for pemasu. Yes, I do need to integrate sfs_load into Puppy. And probably integrate it into the BootManager, especially in the case of too many SFSs. But, as I am at Racy/Wary RC1, I don't want to do any changes. If you want to implement something yourselves, go for it, can look at porting it into Woof later.

sfs limit
Username: BarryK
"Or, I could just roll BootManager back to using Xdialog instead of pupdialog.

stuck on racy
Username: scsijon
"just updated my woof, since I had my new dev box hard drive die on me last week, thought I might as well have the latest for the rebuild. Seem to be stuck on racy in the GUI, it won't allow pickbox changes to wary. Any ideas? thanks

Re bacon
Username: BarryK
"yes, it is broken. The build script warns you not to do it.

size too big
Username: 01micko
"Hi Barry I did a test build of the main Slacko (k2.6.37.6) and the size ended up almost 10M larger! (133M). I notice with your new expanded firmware that there are also the compressed tarballs in /lib/modules/all-firmware too. So.. we are doubling up. Since I'm building a bugfix release, which should I delete? The tarballs or the expanded?

Re firmware tarballs
Username: BarryK
"01micko, Ah, we have hit a bump on the road, with Bones. I will have to fix Bones to do that properly. As you have done a "bones upgrade", the old firmware tarballs were not deleted. Yes, you need to delete the tarballs. Just leave the directories. That's in kernel-skeleton/lib/modules/all-firmware. Another thing that I have to put on the to-do list!

that's better!
Username: 01micko
"Ok, deleted all *.gz from kernel-skeleton/lib/modules/all-firmware. My iso is about 1M bigger now, I can live with that, I'd say it's extra firmware included in this woof, IIRC I read you did add some. Thanks

bones-to-git
Username: mavrothal
"Hi Barry, I have a simple patch that makes bones build a git repository of woof. The idea is to upload it in github or googlecode and have woof code and its development history: 1) browsable/viewable without downloading 2) with more descriptive commit messages 3) a bit easier (for me at least) to spot the changes 4) a bit easier (for me at least) to search 5) a bit easier (for me at least) to pick and choose specific files and revisions 6) (maybe) a bit easier to clone, patch and contribute 7) encourage ( :-P ) more often commits and commit messages The questions are: a) Would you mind? b) Would you rather do it (better) yourself? (Please do!) c) If not, any suggestions on the conversion? d) Any ideas (if any) how to handle the binary code of woof? (is not "browsable") So here is the simple patch (note that paths are hard-coded) [code]--- a/usr/sbin/bones 2011-05-28 10:40:40.000000000 +0300 +++ b/usr/sbin/bones 2011-11-14 00:18:12.000000000 +0200 @@ -237,6 +237,22 @@ [ -f LATEST.tar.gz ] && mv -f LATEST.tar.gz PREVIOUS.tar.gz xdelta3 -d -s PREVIOUS.tar.gz $DELTAFILE LATEST.tar.gz sync + + # GM: Let's try make it a git...! + rm -rf /mnt/home/woof-tree/woof-LATEST/* + tar -C /mnt/home/woof-tree -xvf LATEST.tar.gz + sync + echo "$DELTAFILE" > ../commit.msg + cat /mnt/home/woof-bones/commits | grep "$DELTAFILE" | cut -f 3 -d '|' | tr -d '|' >> ../commit.msg + cd /mnt/home/woof-tree + # Get all new BK's comments + git diff | grep +#[0-9] | tr -d '+' | tr -d '#' >> ../commit.msg + git add . + git commit -a -m "`cat ../commit.msg`" + rm -f ../commit.msg + sync + cd /mnt/home/woof-bones + PREVFIRST="$FIRSTDATE" PREVSECOND="$SECONDDATE" done [/code]

bones-to-git, part2
Username: mavrothal
"(due ti size limits) The above, starting from woof-20091202081304REFERENCE.tar.gz has 190+ commits and makes an ~160MB git repo. In its current form it also generates the latest version of woof in /mnt/home/woof-tree (since I did not want to alter bones function at all). I will probably comment out the expansion of the final tarball, if I go ahead with it. Thoughts?

Re move to git
Username: BarryK
"mavrothal, That is very interesting. I have been wondering the best way to move Woof to the developer community, as I really am planning to retire sometime. I have started to separate out the binaries from Woof, as I want to make Woof multi-architecture. That will fit in very well with porting to GIT. Give me another week or thereabouts, to get this accursed GTK problem with Wary/Racy sorted out, and I will complete the separation of the binaries from Woof, and get it setup for building x86, x86-64, ARM, or whatever.

Tags: woof