SP214 - unofficial service pack

[GuestToo]

no, i included the MOZ_PLUGIN_PATH bugfix too

[edoc]

no, i included the MOZ_PLUGIN_PATH bugfix too

My checksums are OK on the desktop so I do not know why the patch brings up an
error.

I also checked my download of your patch.

Code: Select all

sh-3.00# cd /root/dotpups-downloads
sh-3.00# md5sum SP214.pup
b9393d5e41df1085fd5fbb96113e185f  SP214.pup 

I don't know if this problem may be related to the same problem that is causing the
MENU item in the lower left corner of my desktop to be non-responsive to a mouse
click (it works fine on the laptop).

On both the laptop and desktop two shared problems exist that started, I think, with 2.11
(could have been earlier in the 2.xx releases):

1. Seamonkey spellcheck flags everything as wrong.

2. Login names and passwords are not remembered.

[GuestToo]

the dotpup packages have built in md5 checksums for exactly this purpose ... i am reasonably certain that you have an exact byte for byte duplicate of my dotpup package ... and your md5sum of the dotpup file matches mine ... it is theoretically possible that 2 different files can have the same checksum, but in practice, you might as well say that it is certain that your dotpup package is a perfect copy of the original

so i don't need to even think about the possiblilty that your dotpup file might be corrupted

similarly, the built in md5sum checks are made on the files that were in the zip package, after the zip file was unzipped ... i know the package unzipped perfectly

the problem you are having is due to this line:

if md5sum /usr/lib/seamonkey-1.0.6/mozilla-bin | grep -q 6fe531834c481cc44dd10eaa31877d81 ;then

this tests to see if the file mozilla-bin in /usr/lib/seamonkey-1.0.6/ is the original file that comes with Puppy 214 ... if it is not the original file, my patch will refuse to install

in your case, either the mozilla-bin file has been modified or corrupted ... or the md5sum test is failing for other reasons ... for example, the md5sum executable may be corrupted or modified, or the grep program may be modified ... this can actually happen, if you have a root kit installed ... a root kit is like a virus, and will modify certain programs like md5sum to avoid detection

i think it is more likely that your mozilla-bin has been modified ... if you type this, this should be the result:

# md5sum /usr/lib/seamonkey-1.0.6/mozilla-bin
6fe531834c481cc44dd10eaa31877d81

if you do not get that md5 checksum number, that is your problem ... the mozilla-bin file has been modified, and my patch will refuse to install because something is wrong

you can restore the original mozilla-bin file by copying it from the read-only Puppy file system, like this:

cp /initrd/pup_ro2/usr/lib/seamonkey-1.0.6/mozilla-bin /usr/lib/seamonkey-1.0.6/

if that does not work, then the read-only file system is not mounted on /initrd/pup_ro2/, or your original mozilla-bin is not the same as mine

in any case, there is something wrong, and my patch will not install if there is something wrong, because i do not want to be blamed if the patch does not work properly ... and it might not work properly on a system that is not the standard Puppy system that was released as Puppy 214

[GuestToo]

the
MENU item in the lower left corner of my desktop to be non-responsive to a mouse
click

that sounds like you are using JWM, and that there is something wrong with the .jwmrc file ... it is very easy to change the file so that JWM will not work properly, which is why i avoid modifiying it directly from my dotpup package scripts

you could try typing in an rxvt console:

fixmenus

then restart JWM or X (or reboot)

1. Seamonkey spell check flags everything as wrong

i mostly use Firefox, and rarely use Seamonkey ... i have never noticed this problem, but then i don't use Seamonkey enough so that i would ... the Firefox spell checker seems to work quite well

2. Login names and passwords are not remembered

again, i do not use Seamonkey much, but it has always seemed to remember my passwords properly

you could try renaming the hidden folder /root/.mozilla (to maybe .mozilla2) ... this would give Seamonkey a clean new configuration ... if it runs properly with the new configuration files, you would know that the problem was corrupted files in the configuration folder ... you could get your original configuration files back by deleting .mozilla/ and renaming .mozilla2 back to .mozilla

in any case, no, i am not having those problems myself

[edoc]

i think it is more likely that your mozilla-bin has been modified ... if you type this, this should be the result:

# md5sum /usr/lib/seamonkey-1.0.6/mozilla-bin
6fe531834c481cc44dd10eaa31877d81

if you do not get that md5 checksum number, that is your problem ... the mozilla-bin file has been modified, and my patch will refuse to install because something is wrong

sh-3.00# md5sum /usr/lib/seamonkey-1.0.6/mozilla-bin
419e1e91194456d5d0ddefd8fdecbaff /usr/lib/seamonkey-1.0.6/mozilla-bin

you can restore the original mozilla-bin file by copying it from the read-only Puppy file system, like this:

cp /initrd/pup_ro2/usr/lib/seamonkey-1.0.6/mozilla-bin /usr/lib/seamonkey-1.0.6/

OK, did that and it ran OK ... now I will send this BEFORE
allowing my son to stress test it!

[edoc]

[quote="GuestToo"]
you could try typing in an rxvt console:
fixmenus
then restart JWM or X (or reboot)
[quote]

I tried "restart JWM" and the error was that Console did not
know "restart", tried JVM and nada, tried "reboot" and it all
froze -- had to do a cold reboot.

Once back up no change seen, it may have been lost due to
the freeze.

Executed "fixmenus" again.

Is it "shutdown reboot now" or something like that I should have typed? I forget.

[GuestToo]

there should be a "restart JWM" and "restart X" in the JWM menu ... but if your JWM menu is not working properly, you would not have those items in the menu ... catch 22

to restart X, you can usually press ctrl+alt+backspace to kill X, then type startx or xwin

i think typing wmreboot or wmpoweroff in an rxvt console window should work ... i think killing X then typing reboot or poweroff should also work

it sounds like fixmenus may not work to fix your problem ... you probably have some files from an older version of Puppy that were not replaced when Puppy upgraded (because the files were newer than the Puppy 214 files) ... i do not use JWM much, so i don't have much experience with JWM problems

[PsyBaba]

So...if it worked in Muppy...is there a way to make it work in Viz? (Linux for Dummies answer please )

[GuestToo]

if by "it" you mean SP214, it don't think it does work in Muppy ... SP214 was created for Barry's Puppy 214 only ... i included a few lines of code that should test if it is trying to install to any other version of Puppy, and it should pop up an error message and refuse to install if you try to install it on any other version of Puppy

furthermore, the Seamonkey bugfix will only install if the file it is modifying is the exact file that originally came with Puppy 214

you can unzip the SP214 dotpup file and extract the files if you want ... but whatever you do with them, you are on your own ... SP214 was only tested in Puppy 214

i know it says in the readme.txt file in the package that it should work in Muppy ... but i don't think it will ... i will edit the readme.txt file in the package, eventually

[edoc]

... you probably have some files from an older version of Puppy that were not replaced when Puppy upgraded (because the files were newer than the Puppy 214 files) ...

Any idea as to the most efficient way to fix this problem, short of wiping the HDD and
doing a clean 2.14 install?

It may be the answer to the laundry list of little hassles I am trying to chase down,
e.g. inconsistent memory of passwords, MENU button first not responding now only
responding with clever user effort, pdf that was printing across the network will now
not do so, etc.

[GuestToo]

one thing you can do, if you have a pup_save file (if you run Puppy from a cd or a frugal install) ... you can look in /initrd/pup_rw ... files in that folder are files that are modified, or files that were not in the original Puppy files that are in the .sfs file (also in /initrd/pup_ro2) ... so it is easier to see what has changed for a frugal install than it would be for a full install

when you upgrade Puppy, it's like installing a whole new version of the operating system ... for example, it's like upgrading WinXP to VIsta, and installing Vista over the old XP files ... this can cause problems

i am running Puppy 214 which i installed over Puppy 213 ... i think i installed 213 over 212, i don't remember for sure

anyway, it seems to be running reasonably well, so far, anyway ... but i mostly use Firefox, i don't really like pdfs, and i am using Icewm instead of JWM (JWM's menu is in the configuration file, and it is very easy to corrupt the file so that JWM won't work properly)

i don't know if i can be of much help fixing the problem ... but if you or anyone has a Puppy system in which some of the system files are not the correct files that are supposed to be in the system, then it would not be surprising if your system lacks stability, and it would not be really fair to blame Puppy ... it would be more fair to blame the system that you have, the system that whatever it is, is not Puppy

[edoc]

one thing you can do, if you have a pup_save file (if you run Puppy from a cd or a frugal install) ... you can look in /initrd/pup_rw ... files in that folder are files that are modified, or files that were not in the original Puppy files that are in the .sfs file (also in /initrd/pup_ro2) ... so it is easier to see what has changed for a frugal install than it would be for a full install

/initrd/pup_rw contains 17 directories plus pup_214.sfs,
pupswap.swp, and zdrv_214.sfs

/initrd/ contains pup_ro1, pup_ro2, pup_ro3, pup_ro4, pup_ro5,

I am , as usual, confused as to how I should proceed.

[GuestToo]

for a frugal install, /initrd/pup_rw should be the file system that is inside of the pup_save file

i think pup_214.sfs and zdrv_214.sfs should be in /mnt/home, next to the pup_save file, not inside the pup_save file ... and the pupswap.swp file too

actually, i'm not even sure it would work to put those files inside the pup_save file

anyway, this is how my files are:

/mnt/home/pup_214.sfs
/mnt/home/pup_save.3fs
/mnt/home/zdrv_214.sfs

it's possible that if you looked in /initrd/pup_rw that you might see files that really are not necessary ... usually if the same file is in /initrd/pup_ro2, then the file is either an unnecessary duplicate that is wasting space in the pup_save file for no reason, or it is a modified file ... and it could be a file from an older version of Puppy that should not be there, and might possibly cause instability

i don't think there is any way to know which files are valid and which files might be problems ... maybe a program something like a simplified TripWire could be written

[GuestToo]

something like this, maybe, using md5deep ...

# cd /initrd/pup_ro2
# md5deep -rel bin lib sbin usr > /tmp/trip.txt

# cd /
# md5sum -c /tmp/trip.txt | grep -v OK > /tmp/modified.txt
md5sum: WARNING: 118 of 13436 computed checksums did NOT match

looking in modified.txt, i can see that the files in /usr/local/apps/ROX-Filer/ are all different ... that's because i am running Rox 2.6 instead of Puppy 214's Rox 2.5

sbin/modprobe.bin: FAILED ... that's ok, i modifed modprobe.bin, replacing it with a wrapper script that deletes those missingmods.txt files in /tmp

usr/X11R7/bin/wmreboot: FAILED ... that's ok, i modified it

usr/bin/man: FAILED ... i don't remember modifying that

usr/lib/mozilla/mozilla-bin: FAILED ... that's ok, that's my SP214 bugfix

usr/local/bin/defaultbrowser: FAILED
usr/local/bin/defaultconnect: FAILED
usr/local/bin/defaultemail: FAILED
etc etc ... that's ok, i set them to my preferences

usr/local/bin/gdmap: FAILED ... that's ok, i modified it (large file support and a quit button)

usr/local/bin/gxine: FAILED ... i think i modified gxine trying different compile options

usr/local/bin/isomaster: FAILED
usr/local/bin/leafpad: FAILED
that's ok ... both are newer versions

usr/local/bin/xarchive: FAILED ... ok, i modfied it so it would not corrupt the xerrs.log file

usr/sbin/dotpuprox.sh: FAILED ... ok, it's a newer version installed by SP214

there are a few other files that don't match, but nothing important

so, there are not suspicious files on my system, that might be causing instability, or that might indicate a root kit or a virus

this simple TripWire-like test does not really show problems with files that would normally be different anyway, like configuration files

[edoc]

Our Puppy 2.14 install desktop seems hopelessly trashed.

I am going to back it all up to an external HDD and wipe the internal HDD and
begin clean.

It has been through a lot of upgrades and suffered much tweaking. It is due.

Will report back my results ...

[miseral]

I installed the SP and all went clean. But i still get the same error using eclipse "libgfx_gtk.so: undefined symbol: pango_x_font_map".
help pls. thanks (I´m using 215 which is based on 214)

[GuestToo]

edit the text file /usr/lib/seamonkey-1.0.6/mozilla-bin and change:

export MOZ_DISABLE_PANGO=1

to:

export MOZ_DISABLE_PANGO=0

but this line only affects Seamonkey ... if Eclipse is started by Seamonkey, it would then apply to Eclise too ... otherwise, this line should only affect Seamonkey

note: pango is already disabled in Seamonkey by default in Puppy 214, and in the offical build of Seamonkey

[miseral]

ok, I try a workaround and it seems to be solved.
LD_PRELOAD=/usr/lib/libpangoxft-1.0.so.0.1200.2 /usr/local/eclipse/eclipse

thanks for the reply.