Page 5 of 28
Posted: Tue 01 Dec 2009, 07:27
by dejan555
Yes, I installed SDL pet from dpup site and libg1-glx-mesa and libgl1-dri-mesa debs from lenny, I even loaded my savefile which has all those games running with beta4, same issue there.
Posted: Tue 01 Dec 2009, 07:57
by 01micko
gposil wrote:01micko wrote:"false" it is... however wbar still shows... I had to restart X manually.. is that the case?
So when you restarted X manually Wbar was gone...am I correct.
Er no... I assumed that hitting apply would restart X which it didn't. I did it manually and Wbar was still there, both cases, icons and clean screen.
Posted: Tue 01 Dec 2009, 08:23
by 01micko
moving along...
Killed 2 birds with one stone.. installed dpup to an usb stick.. with universal installer on my main machine, formatted ext2, booted on the R61e Thinkpad.. no major problems. acpi stuff works fine, everything is sweet except 1 minor issue, and it's really a firefox theme issue. A slight rendering problem with 'chromifix' in the tab bar., it was the same in beta 4. simply changed to default and no problem.
Cheers
Posted: Tue 01 Dec 2009, 08:50
by Lobster
OK tried it again:
First pristine boot (pfix=ram)
Clicking on icon images = not working
reboot (no changes) they then work - you can click on images
also confirm first start up wizard gone from menus on reboot
Posted: Tue 01 Dec 2009, 09:17
by 01micko
Ok
Posting from Eee 701SD now.. SD card install using Universal Installer on a vfat partition. All good, downloaded wireless driver.. works, no surprise.
One issue, Pcp has been updated to Pcp3... the wbar icon was not.. now is the chance for you guys and gals using wbar and want the control panel icon to make a plugin... it's easy.
Cheers
Posted: Tue 01 Dec 2009, 09:25
by gposil
dejan555 wrote:Yes, I installed SDL pet from dpup site and libg1-glx-mesa and libgl1-dri-mesa debs from lenny, I even loaded my savefile which has all those games running with beta4, same issue there.
Doesn't make sense, was it working in beta4...should work in beta5...there have been no changes to xserver.
Posted: Tue 01 Dec 2009, 10:07
by dejan555
gposil wrote:
Doesn't make sense, was it working in beta4...should work in beta5...there have been no changes to xserver.
I know. Error is there though both in pristine state and with old savefile from beta4. Can I run some dmesg check or glxinfo or something?
Can you try with pfix=ram, on fresh system install following packages:
SDL from here:
http://dpup.org/test/dpup477beta1-2.6.27.4/additions/
libgl1 debs:
http://packages.debian.org/lenny/libgl1-mesa-glx
http://packages.debian.org/lenny/libgl1-mesa-dri
Then try running this:
http://packages.debian.org/lenny/briquolo
Posted: Tue 01 Dec 2009, 10:11
by 01micko
Hmmmm...
nah crap
Posted: Tue 01 Dec 2009, 10:13
by Béèm
gposil wrote:Has anyone got any Laptop reports, now that we have a full ACPI daemon running in Dpup...it certainly works fine on the 2 Laptops here...but as we know, that may not mean a thing....
If I start my R40 with acpi=off in dpup, the HDD isn't found.
Was already the case in beta 3 and 4
Posted: Tue 01 Dec 2009, 10:21
by 01micko
Nah forget that last crap post of mine.
I now know what's wrong and will knock up a patch for wbar-setup... remember I altered everything straight away, wstart is rewritten... no testing of /var/wbon ...
Posted: Tue 01 Dec 2009, 10:22
by gposil
I think you will find that the SDL from 477 is the problem...also you shouldn't need libgl1-mesa-glx as Dpup482 already has it...Oh, you don't happen to have an Intel video card do you....
Posted: Tue 01 Dec 2009, 10:47
by gposil
Béèm wrote:gposil wrote:Has anyone got any Laptop reports, now that we have a full ACPI daemon running in Dpup...it certainly works fine on the 2 Laptops here...but as we know, that may not mean a thing....
If I start my R40 with acpi=off in dpup, the HDD isn't found.
Was already the case in beta 3 and 4
Why are you running with acpi=off...it works perfectly with R40 here...
Posted: Tue 01 Dec 2009, 11:10
by dejan555
I think you will find that the SDL from 477 is the problem...also you shouldn't need libgl1-mesa-glx as Dpup482 already has it...Oh, you don't happen to have an Intel video card do you....
Ah, I'll try with sdl from debian. I thought I didn't have to install glx on beta4 but installed anyway. SDL from 477 worked with beta4 though. My gfx card is ATI Radeon 9250.
Posted: Tue 01 Dec 2009, 11:17
by 01micko
wbar patch is up
See first page of this thread
Posted: Tue 01 Dec 2009, 11:31
by gposil
Many thanks Mick...
Posted: Tue 01 Dec 2009, 14:58
by ralphv
vtpup wrote:gposil wrote:ralphv said:
Want to see if a frugal will cleanly unmount the partition at shutdown. Beta4 didn't.
Has this problem been reported before...I certainly haven't had any problems unmounting at shutdown....has anyone else had this problem...
Yeah, this one is a pain, and as Béèm said, it appears when you do an fsck. I put pfix=fsck in my kernel line in grub's menu.lst, in my usual frugal installs so fsck checks file integrity every startup, and is constantly reporting unclean shutdowns. I did not do this with Dpup test installs , however, so forgot to mention it here.
Also as Béèm says, it's been around for most puppies since, I believe, 4.x.
One workaround a user reported was to use the kernel switch PMEDIA=ataflash even on a hard drive instead of the more usual PMEDIA=satahd or idehd. This one
does cleanly close. However, it has the disadvantage that you can lose work between the periodic automatic saves if power drops out.
It would be great to actually solve this problem, if that's possible. It creates an insecure feeling about shut-downs for me. Even if pfix=fsck corrects things.
EDIT that's ataflash, not usbflash
Problem for me is I go to archlinux after shutdown, so archlinux does a check, pauses for 15 seconds. and reboots. I tested Lighthouse Pup 4.43 and it didn't do an unclean unmount. But that was on an ext3. So I moved it to an ext2 and it does uncleanly unmount. So a partial solution seems to be use an ext3 for the frugal. Having it fsck every time you boot sounds like it will take extra time.
Ralph
Ralph
Posted: Tue 01 Dec 2009, 15:06
by gposil
Thanks Ralph...I can confirm that Ralph's solution does work...save to ext3/4 and you get a clean unmount...
BTW...I will release a quick small Service Pack tomorrow, that addresses some small issues that have been noted...
Cheers
Guy
Posted: Tue 01 Dec 2009, 15:11
by Béèm
gposil wrote:Béèm wrote:gposil wrote:Has anyone got any Laptop reports, now that we have a full ACPI daemon running in Dpup...it certainly works fine on the 2 Laptops here...but as we know, that may not mean a thing....
If I start my R40 with acpi=off in dpup, the HDD isn't found.
Was already the case in beta 3 and 4
Why are you running with acpi=off...it works perfectly with R40 here...
acpi=off seems to be a magical solution sometimes.
So I tried this with the issue of the num-lock problem.
And in this way, I discovered that on the R40 acpi=off is a no-go.
That's all.
I try to run without acpi=off always as there are side effects with acpi=off.
(manual power off f.e.) (I know there is an instruction somewhere to edit a script)
Posted: Tue 01 Dec 2009, 15:17
by gposil
Béèm,
With acpi left on, do you now get your HDD and is numlock off.
Posted: Tue 01 Dec 2009, 15:21
by vtpup
ralphv wrote: Having it fsck every time you boot sounds like it will take extra time.
It does. 0n a 500 meg savefile on my pent 4 2.4 ghz machine probably something like 5 extra seconds to boot. I once spent a day on the other hand trying to imperfectly recover data from a lost savefile. But pfix=fsck is certainly optional.
gposil, will you be making ext3 the default savefile format in dpup?
Also, I was hoping that someone would figure out the nature of the problem and so we'd have a fix for all of the other puppies in the world since 4.x. Would that be of interest?