Wary Puppy 5.2.2, 18 Nov. 2011

Please post any bugs you have found
Message
Author
User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#316 Post by Argolance »

Hello,
@npierce,
Thank you a lot for replying.
I have attached a modified version of /usr/local/apps/ROX-Filer/AppRun which may get you going.
This works great :D and doesn't seem to slow anything down (let me further watch!)
The problem results from a change to GDK. Until sometime around 2009, GDK made an X11 window for each GDK window. That is not necessarily the case anymore. Now GDK makes what it calls "client-side windows". So now, an application that was designed to interact with an X11 window corresponding to one of its GDK windows may be disappointed to find that no such X11 window exists.
Is it to say that Lucid and Quirky have got GDK version older than Wary and Racy?
Very strange indeed!

Regards

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#317 Post by npierce »

Argolance,

You're welcome. I'm glad to hear that (so far) it is working for you.
Argolance wrote:Is it to say that Lucid and Quirky have got GDK version older than Wary and Racy?
Probably. I'm not sure what versions they have, but they were based upon an older version of Woof.

You can find out what you have:

Code: Select all

ls /usr/lib/libgdk-x11-2.0.so.0.*
Racy 5.2.2 reports:

Code: Select all

/usr/lib/libgdk-x11-2.0.so.0.2400.8
which is commonly known as 2.24.8, and was released last November.

goeran
Posts: 11
Joined: Fri 20 May 2005, 07:49

#318 Post by goeran »

Hello
by updating from 5.1.4.1 to 5.2.2, the seamonkey emails, profile and adressbooks got "lost" . Is there an easy way to restore them ?
goeran

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#319 Post by linuxcbon »

There is a problem with ffmpeg :
ffmpeg -i 'http://api.jamendo.com/get2/stream/trac ... &id=859750'
gives : No such file or directory
Is it because http protocol is not included in compilation ( --disable-network) ?

goeran
Posts: 11
Joined: Fri 20 May 2005, 07:49

#320 Post by goeran »

http://api.jamendo.com/get2/stream/trac ... &id=859750'
gives : Hoovers ride with me.mp3
....???

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#321 Post by linuxcbon »

Did you try that ffmpeg command in wary ? If no, why do you answer this ?

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

Re: Wary Puppy 5.2.2, 18 Nov. 2011

#322 Post by linuxcbon »

Monsie wrote:@linuxcbon:

The empty opt directory is not an artifact or a bug. Some third party applications choose to install to this directory rather than /local and in my case I see that qt4 is installed in the opt directory.

Monsie
I know this already but in wary, it's empty by default, so should we keep empty folders ?

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#323 Post by linuxcbon »

- is openSP needed ?
- is ogle needed ?
- can you make .pls files open with pmusic by default ?

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

Further notes on ROX-Filer & GDK_NATIVE_WINDOWS

#324 Post by npierce »

npierce wrote:I have not yet determined if setting GDK_NATIVE_WINDOWS=true will affect only ROX-Filer, or will affect every GTK/GDK application it opens.

The reason that I set it in /usr/local/apps/ROX-Filer/AppRun instead of /root/.xinitrc or earlier, is to, hopefully, limit its effect to ROX-Filer. But it is certainly possible that, once set, all GTK/GDK applications will be affected. I have noticed that when I use ROX-Filer to run urxvt, GDK_NATIVE_WINDOWS does not appear in the environment. So maybe I got lucky.
I found some time to look into this further.

Apparently it works the way I hoped that it would. By setting GDK_NATIVE_WINDOWS in /usr/local/apps/ROX-Filer/AppRun instead of earlier, it is affecting only ROX-Filer, not applications started by ROX-Filer. So other GTK/GDK applications will continue to use "client-side windows", and should not suffer any loss of speed when creating windows.

The effect of GDK_NATIVE_WINDOWS can be seen with help from xwininfo.

With the unmodified ROX-Filer and libgdk-x11-2.0.so.0.2400.8, running

Code: Select all

xwininfo -children
and clicking on the pinboard (desktop), will result in something like this:

Code: Select all

xwininfo: Window id: 0x800024 "ROX-Filer"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0xaa (the root window) (has no name)
     1 child:
     0x800025 (has no name): ()  1x1+-1+-1  +-1+-1
The "ROX-Filer" window has only one child. (Yes, it looks like a one pixel window -- I have no idea what it is for. :) )

But after killing ROX-Filer, copying the modified AppRun from my earlier post to /usr/local/apps/ROX-Filer/AppRun, and running

Code: Select all

rox -p  /root/Choices/ROX-Filer/PuppyPin
xwininfo will report something like this:

Code: Select all

xwininfo: Window id: 0x800024 "ROX-Filer"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0xaa (the root window) (has no name)
     32 children:
     0x800056 (has no name): ()  58x75+1219+91  +1219+91
     0x800055 (has no name): ()  58x75+1219+187  +1219+187
     0x800054 (has no name): ()  58x75+1219+2  +1219+2
     0x800053 (has no name): ()  58x75+131+91  +131+91
     0x800052 (has no name): ()  58x75+131+187  +131+187
     0x800051 (has no name): ()  58x75+259+2  +259+2
     0x800050 (has no name): ()  58x75+195+91  +195+91
     0x80004f (has no name): ()  58x75+323+2  +323+2
     0x80004e (has no name): ()  66x75+383+2  +383+2
     0x80004d (has no name): ()  58x75+3+91  +3+91
     0x80004c (has no name): ()  64x75+2+187  +2+187
     0x80004b (has no name): ()  58x75+131+2  +131+2
     0x80004a (has no name): ()  58x75+67+2  +67+2
     0x800049 (has no name): ()  58x75+3+2  +3+2
     0x800048 (has no name): ()  58x75+3+283  +3+283
     0x800047 (has no name): ()  68x75+2+379  +2+379
     0x800046 (has no name): ()  58x75+67+91  +67+91
     0x800045 (has no name): ()  58x75+67+187  +67+187
     0x800044 (has no name): ()  58x75+195+2  +195+2
     0x800043 (has no name): ()  58x75+67+283  +67+283
     0x800042 (has no name): ()  58x75+3+699  +3+699
     0x800041 (has no name): ()  58x75+67+699  +67+699
     0x800040 (has no name): ()  58x75+131+699  +131+699
     0x80003f (has no name): ()  58x75+195+699  +195+699
     0x80003e (has no name): ()  58x75+259+699  +259+699
     0x80003d (has no name): ()  58x75+323+699  +323+699
     0x80003c (has no name): ()  58x75+387+699  +387+699
     0x80003b (has no name): ()  58x75+451+699  +451+699
     0x80003a (has no name): ()  58x75+515+699  +515+699
     0x800039 (has no name): ()  58x75+579+699  +579+699
     0x800038 (has no name): ()  58x75+643+699  +643+699
     0x800025 (has no name): ()  1x1+-1+-1  +-1+-1
Now the "ROX-Filer" window still has the child it had before, plus it has a child for each of the icons on my desktop. This is exactly what "GDK_NATIVE_WINDOWS=true" is supposed to do.

If I then click on the "setup" icon and ask xwininfo for a report on the children of its window, I get this:

Code: Select all

xwininfo: Window id: 0x4400003 "Puppy Setup"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0x6b0ffc (has no name)
     1 child:
     0x4400004 (has no name): ()  1x1+-1+-1  +202+221
There is only one child despite all of those buttons. So this application is still using "client-side windows", even though it was launched from ROX-Filer, which is using native X windows.

Apparently, ROX-Filer does not export GDK_NATIVE_WINDOWS to the applications that it starts. So even if that variable is exported to the environment before X is started, it will not pass it along.

But if you launch an application with the JWM menu, or from a terminal that was launched with the JWM menu, GDK_NATIVE_WINDOWS will be exported to the application.

For instance, if instead of setting GDK_NATIVE WINDOWS=true in /usr/local/apps/ROX-Filer/AppRun it was exported to the environment before starting X, it would affect all GTK/GDK applications launched with the JWM menu, and the xwininfo report for "Puppy Setup" would look like this:

Code: Select all

xwininfo: Window id: 0x4400003 "Puppy Setup"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0x6b235e (has no name)
     12 children:
     0x4400032 (has no name): ()  32x24+300+317  +528+564
     0x4400031 (has no name): ()  26x26+306+286  +534+533
     0x4400030 (has no name): ()  26x26+306+255  +534+502
     0x440002f (has no name): ()  27x27+305+223  +533+470
     0x440002e (has no name): ()  28x28+304+190  +532+437
     0x440002d (has no name): ()  26x26+306+159  +534+406
     0x440002c (has no name): ()  26x26+306+128  +534+375
     0x440002b (has no name): ()  26x26+306+97  +534+344
     0x440002a (has no name): ()  26x25+306+67  +534+314
     0x4400029 (has no name): ()  26x26+306+36  +534+283
     0x4400028 (has no name): ()  26x26+306+5  +534+252
     0x4400004 (has no name): ()  1x1+-1+-1  +227+246
Now it shows a native X window for each button, plus that mystery one-pixel window. In the case of "Puppy Setup" I don't think that this would cause any problems, but this example shows that exporting GDK_NATIVE_WINDOWS=true before starting X could affect any GTK/GDK application, which could cause performance issues with some applications. It is safer to just set it for ROX-Filer, as done by the modified /usr/local/apps/ROX-Filer/AppRun.

Bottom line: It looks like the modified /usr/local/apps/ROX-Filer/AppRun should not affect anything other than ROX-Filer itself.

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#325 Post by linuxcbon »

Remarks:
- ayttm is not updated anymore.
- can you add modprobe of all cpufreq and ondemand modules in init ?
- rm /bin/*NOTUSED*
- rm /sbin/*NOTUSED*
- /root/.config/cwallpaper/ needs to be removed to use wallpaper ? (had a Segmentation fault).
- for rox thumbnails , are these needed ?
/root/.thumbnails/
/root/.thumbnails/normal/

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Human factors mods to pupdial

#326 Post by rerwin »

Barry,
In the new "testing" version of lucid pup 5.2.8, I addressed issues that keep frustrating new users of pupdial. I submit them for consideration to be included in woof/wary/racy.

When instructed to omit the login ID and password for wireless modem connections, new users encounter the error message from wvdial complaining about the absence of those items. The remedy is to select "Stupid mode", which is not something novices could infer by themselves. To eliminate that booby trap, I made these changes (copied for my original posting):
  • - In the pupdial modem dialer, changed the label of the "Stupid mode" checkbox to "Bypass log-in", which is what it does -- many new users get frustrated when they delete the login and password default, following their ISP's instructions, and cannot connect, only to be advised to turn on Stupid mode, which is not at all obvious.
    - In pupdial, also ensured that a login and password are passed to wvdial (which requires them) by filling the empty fields with the default values.
My label fix in 2 places is:

Code: Select all

       <label>Bypass log-in</label>
The latter fix is implemented thusly:

Code: Select all

#111231 Ensure non-null logon info for wvdial...
[ ! ${ENTRYACC1USER} ] && ENTRYACC1USER="MYUSERNAME"
[ ! ${ENTRYACC1PASS} ] && ENTRYACC1PASS="MYPASSWORD"
[ ! ${ENTRYACC2USER} ] && ENTRYACC2USER="MY2USERNAME"
[ ! ${ENTRYACC2PASS} ] && ENTRYACC2PASS="MY2PASSWORD"

echo '[Dialer Defaults]' > /etc/wvdial.conf
All but the last line would be inserted into wary 5.2.2's pupdial after line 696.

Thanks for considering this.
Richard

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#327 Post by Argolance »

Hello,
@ npierce
Apparently it works the way I hoped that it would. By setting GDK_NATIVE_WINDOWS in /usr/local/apps/ROX-Filer/AppRun instead of earlier, it is affecting only ROX-Filer, not applications started by ROX-Filer. So other GTK/GDK applications will continue to use "client-side windows", and should not suffer any loss of speed when creating windows.
Thank you a lot for test, explanations and solution: I feel much better now! 8)
On my side, I think I can say that this doesn't slow anything down.

Best regards;

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: Human factors mods to pupdial

#328 Post by BarryK »

rerwin wrote:Barry,
In the new "testing" version of lucid pup 5.2.8, I addressed issues that keep frustrating new users of pupdial. I submit them for consideration to be included in woof/wary/racy.

When instructed to omit the login ID and password for wireless modem connections, new users encounter the error message from wvdial complaining about the absence of those items. The remedy is to select "Stupid mode", which is not something novices could infer by themselves. To eliminate that booby trap, I made these changes (copied for my original posting):
  • - In the pupdial modem dialer, changed the label of the "Stupid mode" checkbox to "Bypass log-in", which is what it does -- many new users get frustrated when they delete the login and password default, following their ISP's instructions, and cannot connect, only to be advised to turn on Stupid mode, which is not at all obvious.
    - In pupdial, also ensured that a login and password are passed to wvdial (which requires them) by filling the empty fields with the default values.
My label fix in 2 places is:

Code: Select all

       <label>Bypass log-in</label>
The latter fix is implemented thusly:

Code: Select all

#111231 Ensure non-null logon info for wvdial...
[ ! ${ENTRYACC1USER} ] && ENTRYACC1USER="MYUSERNAME"
[ ! ${ENTRYACC1PASS} ] && ENTRYACC1PASS="MYPASSWORD"
[ ! ${ENTRYACC2USER} ] && ENTRYACC2USER="MY2USERNAME"
[ ! ${ENTRYACC2PASS} ] && ENTRYACC2PASS="MY2PASSWORD"

echo '[Dialer Defaults]' > /etc/wvdial.conf
All but the last line would be inserted into wary 5.2.2's pupdial after line 696.

Thanks for considering this.
Richard
Done. See blog post:
http://bkhome.org/blog/?viewDetailed=02696
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#329 Post by BarryK »

npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.
It is working for me too!

Trying to recall back when I last tried GDK_NATIVE_WINDOWS=true, I think that I put it as a prefix to the running of rox in /root/.xinitrc.

I was using it back then and noticed lots of gdk critical error reports on stderr, although I don't recall if anything actually crashed.

Anyway, I reckon that I will put your solution into the rox-filer PET pkg -- in the 'common' repo, the PET that most x86 Puppy builds use.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#330 Post by BarryK »

BarryK wrote:
npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.
It is working for me too!

Trying to recall back when I last tried GDK_NATIVE_WINDOWS=true, I think that I put it as a prefix to the running of rox in /root/.xinitrc.

I was using it back then and noticed lots of gdk critical error reports on stderr, although I don't recall if anything actually crashed.

Anyway, I reckon that I will put your solution into the rox-filer PET pkg -- in the 'common' repo, the PET that most x86 Puppy builds use.
Disaster!

Now I recall what went wrong before, because it has happened again. I was scrolling down a fairly large directory, when the scrollbar froze. The entire rox window froze, but other rox window still work.

/tmp/xerrors.log has this:

Code: Select all

XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0"
      after 11851 requests (11851 known processed) with 0 events remaining.

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported
...the rox window is not bigger than 65535 pixels!

So, as before, I find setting GDK_NATIVE_WINDOWS=true is not a viable workaround. I will post this forum page to the rox-file mail list, though the maintainers don't seem interested in fixing it.

Note, I use that same large directory every day with rox, no problem, without the GDK_NATIVE_WINDOWS set.
[url]https://bkhome.org/news/[/url]

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Wary Puppy 5.2.2, 18 Nov. 2011

#331 Post by Billtoo »

I compiled and made a sfs file of Thunderbird-10.0.2 mail reader in
racy-5.2.2.
I tested it in both racy-5.2.2 and wary-5.2.2
EDIT: It works in Saluki too.

The download link is:


http://www.datafilehost.com/download-165680c4.html
Attachments
thunscrn.jpg
(122.95 KiB) Downloaded 1641 times
Last edited by Billtoo on Sun 19 Feb 2012, 18:12, edited 1 time in total.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: Shutdown hangs (SOLVED)

#332 Post by BarryK »

zekebaby wrote:In Wary 5.2.2, I noticed a problem with shutdown hanging if I don't manually unmount NFS or SSHFS mounted drives before shutting down. Poking around rc.shutdown, I found that //network drives are unmounted, but the grep does not pick up host:dir mounted drives.

Adding the following 4 lines in rc.shutdown near Line 190 solves the problem:

Code: Select all

for MOUNTPOINT in `mount | grep ':' | cut -d  ' ' -f 3 | tr '\n' ' '`
do
  umount -f $MOUNTPOINT
done 
Edit: made code more generic to detect other types of network drives such as sshfs
I would like to understand this situation better before implementing this solution.

Could anyone who has this kind of network drives, please post output of "mount" command? (that is, type "mount" in a terminal then ENTER key)

EDIT: anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
[url]https://bkhome.org/news/[/url]

User avatar
shinobar
Posts: 2672
Joined: Thu 28 May 2009, 09:26
Location: Japan
Contact:

Re: Shutdown hangs (SOLVED)

#333 Post by shinobar »

BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.
http://www.murga-linux.com/puppy/viewto ... start=1734

Code: Select all

#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: Shutdown hangs (SOLVED)

#334 Post by BarryK »

shinobar wrote:
BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.
http://www.murga-linux.com/puppy/viewto ... start=1734

Code: Select all

#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done
shinobar,
I reponded to your post to my blog. Here is my repy:

shinobar,
that looks like a good solution. I just looked in the umount docs, this also will work:

umount -a -t cifs,smbfs,nfs,sshfs

However, this requires the full umount. In Woof, umount is a script that currently only calls the busybox umount I think, which does not allow the -t option.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#335 Post by BarryK »

Regarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.

The ROX-Filer focus problem has now been fixed! See my blog post, with a PET:

http://bkhome.org/blog/?viewDetailed=02698
[url]https://bkhome.org/news/[/url]

Post Reply