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/blog/?viewDetailed=02571

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/blog/?viewDetailed=02306

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/


Posted on 11 Nov 2011, 6:52


Comments:

Posted on 11 Nov 2011, 17:25 by Iguleder1
x86_64
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 :)


Posted on 12 Nov 2011, 7:35 by pemasu
pupdialog - bootmanager prob
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.


Posted on 12 Nov 2011, 8:04 by BarryK
re pupdialog
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?



Posted on 12 Nov 2011, 8:54 by pemasu
pupdialog error is still there
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....


Posted on 12 Nov 2011, 8:02 by pemasu
continues...about pupdialog
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.



Posted on 12 Nov 2011, 8:22 by 01micko
sfs-load, otf sfs loader
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!)
shino's sfs_load, also supports unionfs.



Posted on 12 Nov 2011, 8:46 by BarryK
re sfs_load
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.



Posted on 12 Nov 2011, 8:48 by BarryK
sfs limit
Or, I could just roll BootManager back to using Xdialog instead of pupdialog.



Posted on 12 Nov 2011, 16:49 by pemasu
pupdialog rolling back
Thanks for the tip. I rolled back to use bootmanager which uses Xdialog and has 3.x kernel patch. It worked. /mnt/home sfs were shown.


Posted on 13 Nov 2011, 5:32 by scsijon
stuck on racy
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


Posted on 13 Nov 2011, 9:02 by scsijon
bacon problems in build
also just found that trying to update bacon in the build is failing / could not find / skipping is ocurring, more failed than passed and bacon could not complile!


Posted on 13 Nov 2011, 10:13 by BarryK
Re bacon
yes, it is broken. The build script warns you not to do it.



Posted on 14 Nov 2011, 5:34 by 01micko
size too big
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?


Posted on 14 Nov 2011, 6:27 by BarryK
Re firmware tarballs
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!




Posted on 14 Nov 2011, 7:48 by 01micko
that's better!
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


Posted on 14 Nov 2011, 16:11 by mavrothal
bones-to-git
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)
--- 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




Posted on 14 Nov 2011, 16:13 by mavrothal
bones-to-git, part2
(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?


Posted on 14 Nov 2011, 17:22 by BarryK
Re move to git
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.



Posted on 17 Nov 2011, 12:05 by 01micko
slacko testing bugfix version
I have posted to the forum a Slacko testing bugfix, RC for Slacko-5.3.1 using this woof, with slight bugfixes/mods. Only available as deltas.