Wary Puppy 5.2.2, 18 Nov. 2011

Please post any bugs you have found
Message
Author
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]

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#336 Post by nooby »

Seems that Mick forgot to include the ntfs-3g thing so that is why it did not boot

old text now not applickable

Barry, could you have changed something in woof
that makes it difficult for us using Slacko booted on
NTFS formatted internal drives in laptops netbooks.

Two of us report failed boot of 5.3.2.3 while the older slacko 5.3.2.1 just boots No problemo so something with NTFS seems to fail.
Last edited by nooby on Sun 19 Feb 2012, 13:30, edited 1 time in total.
I use Google Search on Puppy Forum
not an ideal solution though

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

#337 Post by Argolance »

Hello,
@Barry
Regarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.
:oops:
So sorry to have to say that the patch does not solve the issue reported above :cry: while the "bad" solution proposed by npierce does it (perfectly)!

Did I miss something?

Regards!

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#338 Post by pemasu »

Been testing again with umount command. I have in /bin...umount script, umount-BB-NOTUSED symlink to busybox and umount-FULL binary.

I have mounted my usb card reader which has vfat SD card. When I execute in console. umount -a -t vfat, the rox folder content vanishes and pmount shows it unmounted.
umount-FULL -a -t vfat shows the same behavior...as it should.
Now the interesting part: busybox umount -a -t vfat unmounts the SD card also...and nothing else so it works with -t type definition.

busybox umount -a vfat unmounts all drives, lol and I have to execute /etc/rc.d/rc.sysinit to get drive icons back, lol.

Is it just my setup in dpup exprimo or does the busybox umount work with -t in other Puppies ?
It looks like to me that there is working option even though it is not documented. Or am I just usual dumb and I dont understand something.

The umount-FULL comes from debian mount package (umount binary) and woof script renames it to the umount-FULL when it recognizes the real binary and sameway renames the busybox symlink. That much I understand but not the busybox umount -t feature, which should not be usable.

User avatar
Monsie
Posts: 631
Joined: Thu 01 Dec 2011, 07:37
Location: Kamloops BC Canada

Wary Puppy 5.2.2, 18 Nov. 2011

#339 Post by Monsie »

Hi Barry,

After installing your Rox-Filer pet on my Wary desktop and re-booting, I noticed that the Console on the desktop now appears as a symlink. Is this an expected result and is it of any consequence?

Thanks,
Monsie
My [u]username[/u] is pronounced: "mun-see". Derived from my surname, it was my nickname throughout high school.

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

#340 Post by BarryK »

Argolance wrote:Hello,
@Barry
Regarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.
:oops:
So sorry to have to say that the patch does not solve the issue reported above :cry: while the "bad" solution proposed by npierce does it (perfectly)!

Did I miss something?

Regards!
The new rox-filer PET solves the old focus problem.

Regarding any other problem, such as that described by npierce, you need to report it to the ROX-Filer bug-tracker at sourceforge.
[url]https://bkhome.org/news/[/url]

Post Reply