The previous upload of Woof was August 29:
There was a blog post recently 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:
To download and use Woof, please read the Bones intro page:
And the Woof intro page:
Comments:Posted on 19 Sep 2011, 8:43 by 01micko
I posted Slacko B3 last night and overall it's had a good reception.
There is an issue though with your newly compiled "no-xcb" libs in Slacko.
Here's the list that got downloaded-
Is it possible for you to upload the corresponding libs that don't have the "no-xcb" mod to the "common" repo? I'm guessing this will affect dpup too, else I'll just recompile them and put them in the Slacko repo.
Posted on 19 Sep 2011, 12:09 by BarryK
Re 'w5c' PETs
There should be Slackware packages for all/most of those.
Posted on 19 Sep 2011, 12:19 by BarryK
re no xcb
Even though they are compiled without libxcb, they still work in Slacko don't they? I can't think why they wouldn't.
Posted on 19 Sep 2011, 13:14 by 01micko
Actually, it's a different bug,
Libusb-0.1 (or what should have been) clobbered the slackware-libusb1, meaning that no libusb-0.1 got downloaded, apparently it's the same in racy pup.
I'm going with libusb-compat :), solves it for me.
Posted on 19 Sep 2011, 13:43 by 01micko
I'm going to get some packages from slackware, they have no deps (or deps are already there) and I compiled a couple for the sake of. I'll get some reports about xsane-0.997-patched-w5c.pet see if that's fine. I use the proprietary canon driver.
boehm-gc-7.1-w5c.pet NO, KEEP
faad2-2.7-w5c.pet NO, KEEP
libdvdplay-1.0.1-w5c.pet NO, KEEP
libgnomecups-0.2.3-w5c.pett NO, KEEP
libusb-1.0.8-w5c.pet FIXED COMPILED
mktemp-1.7-w5c.pet NO, KEEP
psmisc-22.14-w5c.pet NO, KEEP
unzip-60-w5c.pet NO, KEEP
xsane-0.997-patched-w5c.pet NO, KEEP
Posted on 27 Sep 2011, 11:15 by 01micko
There have been many reports of a shutdown bug (that is, it wont poweroff) in Slacko B3 and B4. I have figured it's something to do with unmounting because if all your drives are unmounted the it poweroffs fine, if 1 or more drives are mounted you get a reboot when you want poweroff. It has only occurred in this woof, I have partitions mounted all the time when I poweroff, actually I usually only poweroff before work or bed. On my test boxes I haven't bothered mounting drives and they all powered off fine, so that is why this took awhile to surface.
davids45 reported that this occurred to him in Racy.
Posted on 27 Sep 2011, 16:58 by BarryK
Re poweroff problem
That seems more like a kernel problem. I got that problem recently a couple of times, and I didn't know why it happened.
I'm running Wary right now, I'll see if the problem occurs. If it doesn't, that might tend to point the finger more at the kernel.
Note, regarding unmounting partitions, rc.shutdown unmounts everything, so at final shutdown they should all be unmounted, or as much as can be.
What kernel are you using in B3/B4?
Posted on 27 Sep 2011, 20:55 by BarryK
Re Poweroff problem
I get it in Wary too. I am always very tidy, unmount everything before shutting down, so wasn't getting this problem.
Right now, it's a mystery. I can exit from X, then type "busybox poweroff", and the computer does poweroff.
So, I have to try an figure out how a poweroff gets changed to a reboot, just because a partition is mounted. I have had enough for today, will check it out tomorrow.
Posted on 27 Sep 2011, 21:15 by 01micko
Thanks for the attention.
I wanted to make sure it was caught before next woof as that will be the final woof for slacko.
I made sure of my facts first ;).
As an aside, I have been using the same kernel for 2 months with many testers with no poweroff issues. (k220.127.116.11, aufs patched of course, smp, no pae, usb_storage as module, basically follows your DOTconfig for 18.104.22.168)