Chihuahua Alpha6 plus Lassie_Office

News, happenings
Message
Author
nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

Firefox & Flash

#136 Post by nic2109 »

Hello; I've just started to try Chihuahua A6 and want to say how nice it looks.

Please forgive me if this is known already but something in the build of Firefox isn't quite right as some websites don't think like the Flash installation.

I assume that it IS Flash 9, but the BBC's website isn't interpreting it correctly. See screenshot where you will see that instead of the chance to play a video clip (below the picture of Andrew Strauss) there is the message 'Cannot play media. You do not have the correct version of the flash player.....'.

I have had the same problem with Opera in Muppy so I would think it more likely to be the Flash plug-in than the actual browser.
[color=darkblue][b][size=150]Nick[/size][/b][/color]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Flash under alpha 6

#137 Post by prehistoric »

Hi Nic,

The Beeb was right, as it comes from the ISO there is no Flash with alpha 6. This was caused by changing browsers and questions about which version to install by default. I'm currently using Flash 9.0.124, which you can find packaged as a pet here:

flashplayer-9.0.124.0.pet
flashplayer-9.0.124.0.pet.md5.txt

Any sites where Flash was working without being installed should be reported immediately. :wink:

jonyo

#138 Post by jonyo »

I'm using FF 2.0.0.14 with the flash pkdge in xvesa & i get skips (or slight hangs..) with u tube stuff.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

glitches

#139 Post by prehistoric »

@jonyo,

I suspect the problem stems from both xvesa and flash requiring service, with substantial overhead, at regular fixed intervals. Anything more to report on the cursor and xorg?

@tronkel,

Jack, are you there? Ready to move on to Firefox 3rc1 and beta status?

General problem: I've seen one more glitch where a file went missing. This time most of the main menu, except for the "settings" entry, disappeared. (Could one of our Icewm experts tell me what is different about "settings" and its submenu?) Restarting X had no effect. (This also restarts Icewm.) Rebooting restored the missing menu. What is different? Rebooting rebuilds unionfs.

I have to emphasize that these are extremely rare events, around once a week under heavy use. Most people would simply reboot and assume it was some mysterious "computer" problem. They've been conditioned to accept this as normal in the Windoze world. Because it is not easily reproducible, this kind of report tends to be lost in the noise.

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#140 Post by tronkel »

@prehistoric

As regards the disappearing menus, this could well be the result of having to cludge the initial startup of icewm. I had to insert a fixmenus & command into the icewin startup script in order to work around some problem that occured when I converted tttuuxx's icewm pet package into a tar.gz that I can use in Unleashed. There is also a menu config file that I have to manually add to rootfs-complete in Unleashed in order to get the menu icons to be displayed.

I have never managed to suss out why converting a dotpet to a directory has caused this.

I'd like to try to wait for Firefox 3 Final before going beta. This should appear sometime in June according to Mozilla. I am testing Firefox 3RC1 at the moment and am a little wary of it as regards the old problem of stability. Its not quite there as yet, but will hopefully get sorted for the final release. It will be a terrific version if they can manage to stablise it. It is very fast.

All I need now is time to concentrate on building it. I don't have a great deal of time to even sit down at the computer at the moment. An incidental benefit with this though, is that it leaves a wider time-frame for incorporation of further packages if required. Things do not stand still in Puppyland. For, example someone has asked me to put back Dougal's enhanced remaster script. So that will need a bit of testing as well.

I'm still here as you can see!
Life is too short to spend it in front of a computer

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

disappearing menus, X startup, net disconnect

#141 Post by prehistoric »

@tronkel,

If the menu had disappeared at startup, I would suspect your hack. This happened during a long session without restarting either Icewm or X. MU has had similar cases of trouble with unionfs in Muppy 008.3, even posted about one today.

I have now moved the startup of ROX-filer into my autostart.sh script in the Startup directory. This seems to eliminate those icon pileups we have seen on a non-deterministic basis. When Dougal is completely finished with his latest version of Hotpup I'll move it as well. Concurrency between .xinitrc and Icewm startup has been the source of several mysterious problems.

My tiny patch to xwin, (and restartwm, wmpoweroff, wmreboot) has fixed problems for some people and survived my own testing again. So far, there have been no reports that it has caused problems. (The patch has even helped on 4.00, on some slow machines where I got the black screen.)

That emergency network disconnect I asked for could be as simple as

Code: Select all

ifconfig ra0 down
in my particular case. For others, the interface might be eth0 or wlan0. This should be passed as an argument instead of being hard coded in. The dialogue could be eliminated if the script just checked on interface status, if it is up, you want it down, and vice versa. (toggle interface off/on)

I'm comfortable with waiting for stable versions. In the meantime, the configuration I have is stable enough to be my regular system for email and browsing. I'm testing a couple of Icewm pets from ttuuxxx. My "problem" at this point is that I don't have bugs to track into them. All bugs found to date were outside the actual Icewm code.

jonyo

Re: glitches

#142 Post by jonyo »

prehistoric wrote: Anything more to report on the cursor and xorg?
Not setup yet to fiddle with xorg scenarios yet but can say that have been in chihuahua 99% of the time for awhile now & not having any issues other than the ones described.
Main one I'd like to sort out is d/loads from the petget manager.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

petget downloads

#143 Post by prehistoric »

@jonyo,

If I remember correctly, tronkel has the petget problem (broken link) covered, I'm expecting the fix in beta 1. At present, I'm downloading manually before I install.

@tronkel,

MU has an upgraded Sylpheed which can handle GPG, something people have already asked for. http://www.murga-linux.com/puppy/viewtopic.php?t=27944

I found another non-deterministic problem, presumably not involving the window manager, while investigating the hang at shutdown and the constant rechecking of the file system on booting with Muppy 008.3d. There is evidence this involves the unionfs, which could connect it with the glitches I've seen. I'll be testing for the same problem with Chihuahua.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

still non-deterministic problems

#144 Post by prehistoric »

After hundreds of reboots and shutdowns, I have just seen the first instance in which alpha 6 with the patches I applied exhibits the black screen on shutdown. This puts the incidence at about once a week in heavy use, which is almost impossible to debug.

This is also close to the incidence of a suspected bug in unionfs. It is possible these two problems are the same, if unionfs caused the xwin file to revert to its unpatched state.

To track this one down I need clues about how to make it more likely, and a single incident doesn't tell me enough. Anyone who has tested the patch can tell me what they've seen. Even if it doesn't appear to make any difference I would like to know that I haven't introduced new bugs.

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#145 Post by tronkel »

@prehistoric

Just a thought.

The patches may become inivisible due to the presence of whiteout files (*.wh files) on your system. These get created when you "delete" a file that exists in any loaded sfs files on your system. Might be worthwhile checking your file system for the presence of these files. Getting rid of your whiteout files would then allow any files within the sfs to become visible to the system again via unionfs.
Life is too short to spend it in front of a computer

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

whiteout files + xorgwizard + unionfs and swap

#146 Post by prehistoric »

@tronkel,

The problems I've been seeing have been earlier versions of files, which should be present in other layers, reappearing. If whiteout files are involved, it would seem they are being missed, not added.

Another, completely unrelated, question and search led me to this long thread. For the first time, I realized that rerwin's and Dougal's fixes to xorgwizard went from 3.01 directly to 4.00 alpha 3, bypassing us. I've only touched a few things connected with 4.00 and have not dug into the code. I was originally thinking Barry would go to a different version of Xorg, but from the discussion it sounds as if the patched wizard from 3.01 went in almost directly. (Forgive me, if this is old news I'm bringing up. )

After reading that thread, I understood that some of the problems which led me to make changes in xwin were addressed there. The text about available modes from xvesa (after exiting xorg) was one of the things which showed me I had two processes on one console. So far, I have no reports that my patch has caused problems, and it's hard to see how forcing the assumption to be true (that there is no previous X process running) could hurt. I say leave it in, as a last ditch defense against the really nasty situation of having more than one process trying to control the display and keyboard.

I'm still waiting for data on an extremely rare black screen reported above. If I can't get more information it will be virtually impossible to debug.

I've found that the problem of hangs on shutdown at "unmounting swap" (also seen by MU in Muppy) is connected with unionfs and the constant checking of the save file at the time it is mounted during boot up. (I saw an instance with error messages from unionfs code.) Any ideas for catching that one in the act could help solve several non-deterministic mysteries.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

clue

#147 Post by prehistoric »

@tronkel,

I know this is getting old, (especially since people have been living with the problem for some time.) I've just had a second instance of the black screen at shutdown after my patch, which gave me vital information. On the next boot it reported that X hung the last time I ran, meaning /etc/.XLOADED file is not being reset. There must be a deadlock somewhere under X. I've moved the "killall -9 X 2>/dev/null" to the section of xwin which handles returns from X. This should mean that every exit from X has this as a cleanup. It will take a while to collect data on this, because the problem is rare. (I wish I could find the process causing this.) I will also check if removing the "killall -9 X" from the beginning of xwin allows any examples of corrupted input because of multiple X processes.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Big step forward by MU

#148 Post by prehistoric »

@tronkel,

MU has just run the Unionfs bug down in Muppy 008.3. Take a look at the post about aufs, subject "important...", in this thread.

WhoDo has proved important confirmation about the black screen problem. I plan to release a better fix as soon as I can do a reasonable amount of testing on it. The difficulty here is that the problem is rare, so testing takes time.

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#149 Post by tronkel »

@prehistoric

I had thought about the possibility of using aufs instead of unionfs.
aufs doesn't create whiteout files which is a good thing.

Barry went back to using unionfs as the default, but for a reason I don't quite recall. Maybe something to do with problems with installs to usb drives on certain hardware - so moving entirely to aufs may have some side-effect somewhere.

Best thing to do is to keep plodding along with the testing. How about tryng frugal installs to usb stick but using the boot cheat code layerfs=aufs? If you don't experience any problems with this, then maybe the default for Chihuahua ought to be aufs after all.

Maybe the best thing to do is not to include the earlier fixes in the next Chihuahua version until more testing has been done. A roll-back to the initial state of Chihuahua will represent a more logical platform for further testing. There no pressing need to produce instantaneous results here. Just do what you can when you can :D
Life is too short to spend it in front of a computer

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

aufs, black screen fixes

#150 Post by prehistoric »

@tronkel,

I'm running right now with cheatcode "layerfs=aufs" and some glitches I could never classify seem gone. Dmesg shows "aufs 20070618" and lsmod shows unionfs not loaded. I'm running off a USB flash drive, installed before the change, with syslinux.cfg edited for the cheatcode.

As for the previous fix, it definitely made this Puppy usable on a few systems where there were serious problems. Since these are the ones I particularly need to test, I would say, include the two lines near the beginning of xwin but do not modify the original configuration of other files: restartwm, wmpoweroff, wmreboot. In this way, we will get the benefits on some systems, where otherwise we might not get test reports, without losing any which failed because I removed that "killall -9 X". I still intend to clean up the code so all situations where we clear deadlocked X processes on exit are handled together. This is better than depending on each separate command to do the job correctly. My current test system is doing this now, without problems. Other code may disappear when things are clarified. I'm hoping for a smaller, more readable, xwin.

I remain firmly convinced races between processes started in .xinitrc and Icewm startup are trouble. I've created an autostart.sh script in Startup to run things after Icewm comes up and moved things in, as previously described. This is a temporary fix which could get into trouble when users begin putting applications in Startup.

The business of getting test reports on results of the tiny change to xwin, etc. has been frustrating. Because we are dealing with rare cases and non-determinism, and still don't have all sources pinned down, testing is essential. You may not realise it, but I have never heard you or ttuuxxx say, "Well, I tried this, but as far as I can tell, it doesn't do anything. At least, it didn't break anything I had working." I had to send PMs to pry lose the reports I have.

Added Sunday: Both "layerfs=aufs" and the patch to put "killall -9 X" on the control path to exit from xwin continue to work. I've also upgraded to Firefox 3 rc 2 without problems.

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

#151 Post by nic2109 »

Hello; I have a curious bug to report: the window control icons randomly change when the pointer moves over them. They start out odd (see screenshot) and get odder! Luckily the words appear, so we know which does what (you know - Minimize, Maximize and Close) but the buttons change character alarmingly! I am using the fglrx-8.4 driver for my ATi card so that might have something to do with it.

I also have one question :- Firefox keeps telling me that it has downloaded an update (it's a popup from the Task-bar) but I never get to 'click here to install' before it goes away! Where will it have been put, and is it a one-click install?
[color=darkblue][b][size=150]Nick[/size][/b][/color]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#152 Post by ttuuxxx »

nic2109 wrote:Hello; I have a curious bug to report: the window control icons randomly change when the pointer moves over them. They start out odd (see screenshot) and get odder! Luckily the words appear, so we know which does what (you know - Minimize, Maximize and Close) but the buttons change character alarmingly! I am using the fglrx-8.4 driver for my ATi card so that might have something to do with it.

I also have one question :- Firefox keeps telling me that it has downloaded an update (it's a popup from the Task-bar) but I never get to 'click here to install' before it goes away! Where will it have been put, and is it a one-click install?
Hey Nic
I had that problem once before, I actually liked it, it was amusing, Its some sort of process bug, Like its using the taskbar info in the buttons.
I haven't had it happen in a long time, you might want to try and delay the startup of icewm and see how that goes.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

Post Reply