Wary Puppy 5.2.2, 18 Nov. 2011
Re: Wary Puppy 5.2.2, 18 Nov. 2011
I know this already but in wary, it's empty by default, so should we keep empty folders ?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
Further notes on ROX-Filer & GDK_NATIVE_WINDOWS
I found some time to look into this further.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.
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
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
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
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
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
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
Bottom line: It looks like the modified /usr/local/apps/ROX-Filer/AppRun should not affect anything other than ROX-Filer itself.
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/
- 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/
Human factors mods to pupdial
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):
The latter fix is implemented thusly:All but the last line would be inserted into wary 5.2.2's pupdial after line 696.
Thanks for considering this.
Richard
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.
Code: Select all
<label>Bypass log-in</label>
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
Thanks for considering this.
Richard
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello,
@ npierce
On my side, I think I can say that this doesn't slow anything down.
Best regards;
@ npierce
Thank you a lot for test, explanations and solution: I feel much better now!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.
On my side, I think I can say that this doesn't slow anything down.
Best regards;
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Human factors mods to pupdial
Done. See blog post: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):My label fix in 2 places is:
- - 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.The latter fix is implemented thusly:Code: Select all
<label>Bypass log-in</label>
All but the last line would be inserted into wary 5.2.2's pupdial after line 696.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
Thanks for considering this.
Richard
http://bkhome.org/blog/?viewDetailed=02696
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
It is working for me too!npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.
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]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Disaster!BarryK wrote:It is working for me too!npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.
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.
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
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]
Wary Puppy 5.2.2, 18 Nov. 2011
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
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.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Shutdown hangs (SOLVED)
I would like to understand this situation better before implementing this solution.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:Edit: made code more generic to detect other types of network drives such as sshfsCode: Select all
for MOUNTPOINT in `mount | grep ':' | cut -d ' ' -f 3 | tr '\n' ' '` do umount -f $MOUNTPOINT done
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]
Re: Shutdown hangs (SOLVED)
I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
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]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Shutdown hangs (SOLVED)
shinobar,shinobar wrote:I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
http://www.murga-linux.com/puppy/viewto ... start=1734Code: 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
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]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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
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]
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.
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
not an ideal solution though
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello,
@Barry
So sorry to have to say that the patch does not solve the issue reported above while the "bad" solution proposed by npierce does it (perfectly)!
Did I miss something?
Regards!
@Barry
Regarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.
So sorry to have to say that the patch does not solve the issue reported above while the "bad" solution proposed by npierce does it (perfectly)!
Did I miss something?
Regards!
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.
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.
Wary Puppy 5.2.2, 18 Nov. 2011
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
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.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
The new rox-filer PET solves the old focus problem.Argolance wrote:Hello,
@BarryRegarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.
So sorry to have to say that the patch does not solve the issue reported above while the "bad" solution proposed by npierce does it (perfectly)!
Did I miss something?
Regards!
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]