Wary Puppy 5.2.2, 18 Nov. 2011
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]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Wary Puppy 5.2.2, 18 Nov. 2011
I don't know why that is happening. Probably it won't happen if the PET is used in Woof when a Puppy is built.Monsie wrote: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
[url]https://bkhome.org/news/[/url]
Barry,
Apologies for raising false hopes with the GDK_NATIVE_WINDOWS work-around. I'm glad that you spotted the problem before shipping it to the repo. And it is very good to hear that you were able to get a fix for the focus problem.
Argolance,
Apologies to you as well. I have been able to reproduce Barry's findings. (I needed a directory with almost 7000 items to do so, but the actual number will vary depending on how many items ROX-Filer displays in each row, and how tall each row is.) So my proposed work-around is certainly not the solution we were hoping for. The problem you are having will need to be fixed in ROX-Filer. Sorry that the work-around didn't work properly.
Apologies for raising false hopes with the GDK_NATIVE_WINDOWS work-around. I'm glad that you spotted the problem before shipping it to the repo. And it is very good to hear that you were able to get a fix for the focus problem.
Argolance,
Apologies to you as well. I have been able to reproduce Barry's findings. (I needed a directory with almost 7000 items to do so, but the actual number will vary depending on how many items ROX-Filer displays in each row, and how tall each row is.) So my proposed work-around is certainly not the solution we were hoping for. The problem you are having will need to be fixed in ROX-Filer. Sorry that the work-around didn't work properly.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
npierce,npierce wrote:Barry,
Apologies for raising false hopes with the GDK_NATIVE_WINDOWS work-around. I'm glad that you spotted the problem before shipping it to the repo. And it is very good to hear that you were able to get a fix for the focus problem.
Argolance,
Apologies to you as well. I have been able to reproduce Barry's findings. (I needed a directory with almost 7000 items to do so, but the actual number will vary depending on how many items ROX-Filer displays in each row, and how tall each row is.) So my proposed work-around is certainly not the solution we were hoping for. The problem you are having will need to be fixed in ROX-Filer. Sorry that the work-around didn't work properly.
I got it (the hanging) with a directory with 3029 items. It was displaying 10 items wide, or rather, trying to.
argolance,
Sorry, I wasn't clear. You and npierce were discussing a different problem, that you solved with GDK_NATIVE_WINDOWS. As soon as I saw the mention of that variable, my mind went immediately to the old focus bug.
Though, 01micko has reported the focus problem is not fixed for him in Slacko. Right now I'm running the very latest Racy, with the new Rox, and just tested the "Open With..." menu -- yep, focus on the icon get released. Good.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Wary Puppy 5.2.2, 18 Nov. 2011
Confirmed. Latest Wary/Racy 5.2.2.7, console icon is ok.BarryK wrote:I don't know why that is happening. Probably it won't happen if the PET is used in Woof when a Puppy is built.Monsie wrote: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
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
For anyone who is interested, there is now a beta1 of the upcoming Wary 5.3 uploaded:
http://murga-linux.com/puppy/viewtopic.php?t=76182
http://murga-linux.com/puppy/viewtopic.php?t=76182
[url]https://bkhome.org/news/[/url]
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello
@Barry
Regards.
@Barry
... There are always solutions, anyway!argolance,
Sorry, I wasn't clear. You and npierce were discussing a different problem, that you solved with GDK_NATIVE_WINDOWS. As soon as I saw the mention of that variable, my mind went immediately to the old focus bug.
... Master and dog: both loyal and reliable!For anyone who is interested, there is now a beta1 of the upcoming Wary 5.3 uploaded:
Regards.
Wary Puppy 5.2.2
I have been amazed to be able to use the live CD on an HP Pavilion 6370Z and actually get an old Realtek 8185 wireless card to work with ndiswrapper but of course the process is slow (about 7 minutes from start to browsing) so I've tried to use the save file. I have plenty of space on an old Linux partition (from Suse 6.1 days) and it all seems to go well but upon reboot it freezes at the point after searching for optical drives when I believe it is try to load the xwindow system. I have also used it on my Gateway laptop and when I use the save file reboot it looses the cursor on the monitor window so I am guessing that the save file does not properly save the Xwindow configuration. 5.2.2 often freezes when trying to load the browser so I tried 5.1.4.1 and so far no problems but it has the same issue with rebooting using the save file.
I thought maybe I could remaster the CD to at least shorten the process but after 3+ hours of looking a the window that said to wait patiently for the sfs file to be created and noting no disk or CD activity I gave up.
Thanks, keep up the good work.
I thought maybe I could remaster the CD to at least shorten the process but after 3+ hours of looking a the window that said to wait patiently for the sfs file to be created and noting no disk or CD activity I gave up.
Thanks, keep up the good work.
Re: JWM multiple root MENUS problem with Wary/Racy 5.2
Argolance,
Here is a version of ROX-Filer that I have fixed so that you can again use multiple JWM menus without any need for GDK_NATIVE_WINDOWS. It works for me, but I would be grateful if you would test it to see if it works for you.
Backup your current version of /usr/local/apps/ROX-Filer, and replace it with the attached file. You will need to first kill all current instances of ROX-Filer or you may get a "file busy" error. Then start rox with the usual:
I would be grateful to receive additional reports from anyone else who would do me the favor of testing this.
This bug can be seen even when you have only the single JWM menu that comes with Racy 5.2.2.
1. Click the right mouse button on the desktop to bring up the JWM root menu.
2. Click any mouse button on the desktop to dismiss the menu.
3. Click the left mouse button once on an icon. The application should launch. If it does not launch until you click a second time, you have this bug.
Also, you can go through steps 1 and 2 again, then try this for step 3:
3. Click the right mouse button once on an icon. The ROX-Filer menu should come up. If the JWM root menu comes up, you have this bug.
Note that, in both flavors of step 3, the bug will appear even if you click an icon in a ROX-Filer window instead of the desktop.
Here is what I think is happening:
As you may know, each icon on the ROX pinboard has an invisible window floating over it. Back before GTK/GDK 2.18, these windows were real X windows, created by the X server at the request of GDK. Now those windows are created by GDK itself and are what GDK calls "client-side windows". So now, instead of being an X window with a bunch of child X windows, the pinboard is an X window with a bunch of child client-side windows.
What's happening is that when you click the right mouse button on the "desktop", which is actually the ROX pinboard, ROX "grabs" the mouse so that future pointer events will be delivered to the ROX pinboard window, no matter where the pointer moves to. This "grab" is an automatic "passive grab" which happens in any application when a mouse button is pressed, and is automatically released when the mouse button is released.
So far, so good. But because ROX passes the button-press-event to the root window so that JWM can use it, it needs to manually ungrab the mouse. Previously ROX did this with a call to XUngrabPointer(), an Xlib function.
When ROX was using all real X windows, that was fine. When JWM was done, the next button-press-event would go to whatever X window was under the pointer. In fact, it still does. But now, the pinboard has only the one X window, so if the pinboard or any of its icons is under the pointer, the event will go to the pinboard, but not necessarily to the correct client-side child window of the pinboard. It will go to the window that grabbed the pointer in the first place -- either the pinboard window itself, or one of its client-side children.
I replaced the call to the Xlib function, XUngrabPointer(), with a call to the GDK function, gdk_display_pointer_ungrab(). This function will also tell X to release the grab, but it additionally tells GDK to release the grab so that the next button-press event will go to whatever client-side window is under the pointer, not the window that made the grab.
At least that is my best guess -- I've not looked at the GDK source to verify that.
(By the way, since antique versions of Blackbox and Fluxbox required ROX-Filer's "Blackbox root menus hack" option, to allow the right-click root menu to remain displayed until you have selected an item, and since that relates to this ungrab, I dug up an old (circa 2002) Blackbox (blackbox_0.65.0-5_i386.deb) from the Debian archives and tested it to make sure that this option still worked properly with my change. It does. Note that newer versions of Blackbox and Fluxbox, such as blackbox-0.70.1.pet and fluxbox-1.3.2.pet do not need this option.)
The attached file was compiled from the following source (which already contains Barry's patches, including the February patch for the focus bug):
http://bkhome.org/sources/alphabetical/ ... hed.tar.gz
Here is my one change to the source:
Anyway, Argolance, I hope this works for you with your three JWM menus.
Filename: ROX-Filer.gz
File description: ROX-Filer with ungrab bug fixed
Here is a version of ROX-Filer that I have fixed so that you can again use multiple JWM menus without any need for GDK_NATIVE_WINDOWS. It works for me, but I would be grateful if you would test it to see if it works for you.
Backup your current version of /usr/local/apps/ROX-Filer, and replace it with the attached file. You will need to first kill all current instances of ROX-Filer or you may get a "file busy" error. Then start rox with the usual:
Code: Select all
rox -p /root/Choices/ROX-Filer/PuppyPin
This bug can be seen even when you have only the single JWM menu that comes with Racy 5.2.2.
1. Click the right mouse button on the desktop to bring up the JWM root menu.
2. Click any mouse button on the desktop to dismiss the menu.
3. Click the left mouse button once on an icon. The application should launch. If it does not launch until you click a second time, you have this bug.
Also, you can go through steps 1 and 2 again, then try this for step 3:
3. Click the right mouse button once on an icon. The ROX-Filer menu should come up. If the JWM root menu comes up, you have this bug.
Note that, in both flavors of step 3, the bug will appear even if you click an icon in a ROX-Filer window instead of the desktop.
Here is what I think is happening:
As you may know, each icon on the ROX pinboard has an invisible window floating over it. Back before GTK/GDK 2.18, these windows were real X windows, created by the X server at the request of GDK. Now those windows are created by GDK itself and are what GDK calls "client-side windows". So now, instead of being an X window with a bunch of child X windows, the pinboard is an X window with a bunch of child client-side windows.
What's happening is that when you click the right mouse button on the "desktop", which is actually the ROX pinboard, ROX "grabs" the mouse so that future pointer events will be delivered to the ROX pinboard window, no matter where the pointer moves to. This "grab" is an automatic "passive grab" which happens in any application when a mouse button is pressed, and is automatically released when the mouse button is released.
So far, so good. But because ROX passes the button-press-event to the root window so that JWM can use it, it needs to manually ungrab the mouse. Previously ROX did this with a call to XUngrabPointer(), an Xlib function.
When ROX was using all real X windows, that was fine. When JWM was done, the next button-press-event would go to whatever X window was under the pointer. In fact, it still does. But now, the pinboard has only the one X window, so if the pinboard or any of its icons is under the pointer, the event will go to the pinboard, but not necessarily to the correct client-side child window of the pinboard. It will go to the window that grabbed the pointer in the first place -- either the pinboard window itself, or one of its client-side children.
I replaced the call to the Xlib function, XUngrabPointer(), with a call to the GDK function, gdk_display_pointer_ungrab(). This function will also tell X to release the grab, but it additionally tells GDK to release the grab so that the next button-press event will go to whatever client-side window is under the pointer, not the window that made the grab.
At least that is my best guess -- I've not looked at the GDK source to verify that.
(By the way, since antique versions of Blackbox and Fluxbox required ROX-Filer's "Blackbox root menus hack" option, to allow the right-click root menu to remain displayed until you have selected an item, and since that relates to this ungrab, I dug up an old (circa 2002) Blackbox (blackbox_0.65.0-5_i386.deb) from the Debian archives and tested it to make sure that this option still worked properly with my change. It does. Note that newer versions of Blackbox and Fluxbox, such as blackbox-0.70.1.pet and fluxbox-1.3.2.pet do not need this option.)
The attached file was compiled from the following source (which already contains Barry's patches, including the February patch for the focus bug):
http://bkhome.org/sources/alphabetical/ ... hed.tar.gz
Here is my one change to the source:
Code: Select all
diff -u old/pinboard.c new/pinboard.c
--- old/pinboard.c 2011-10-22 13:48:50.000000000 -0400
+++ new/pinboard.c 2012-03-13 08:00:47.000000000 -0400
@@ -1363,7 +1363,8 @@
{
xev.type = ButtonPress;
if (!o_blackbox_hack.int_value)
- XUngrabPointer(gdk_display, event->time);
+ gdk_display_pointer_ungrab( gdk_x11_lookup_xdisplay( gdk_display ),
+ event->time ) ;
}
else
xev.type = ButtonRelease;
Filename: ROX-Filer.gz
File description: ROX-Filer with ungrab bug fixed
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello npierce,
So, I previously installed the patched version of ROX-Filer, to be sure of the result while using your modified ROX-Filer file (I don't know exactly what is the version that comes with my Racy 5.2.8.?)
I unfortunately have to say that this doesn't run for me
Black desktop and windows very quickly appearing...
Rox doesn't work anymore...
xerrs.log says:
Cordialement.
Thank you so much for your work and explanation that comes with!Here is a version of ROX-Filer that I have fixed so that you can again use multiple JWM menus without any need for GDK_NATIVE_WINDOWS. It works for me, but I would be grateful if you would test it to see if it works for you.
So, I previously installed the patched version of ROX-Filer, to be sure of the result while using your modified ROX-Filer file (I don't know exactly what is the version that comes with my Racy 5.2.8.?)
I unfortunately have to say that this doesn't run for me
Black desktop and windows very quickly appearing...
Rox doesn't work anymore...
xerrs.log says:
Is it due to any compiling error?ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
ERROR from /usr/local/apps/ROX-Filer/AppRun:
I cannot find an executable binary.
Trying to compile...
Cordialement.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
There is nothing to compile. If you downloaded the ROX-Filer.gz provided by npierce, after ungzipping it (just click on it), be sure to set it's execute flags -- right click on it, choose "Properties" then tick the Execute checkboxes.Argolance wrote:Is it due to any compiling error?
The downloaded ROX-Filer replaces the one at
/usr/local/apps/ROX-Filer/ROX-Filer
If you did replace the original, then the most likely problem is the lack of execute permission.
[url]https://bkhome.org/news/[/url]