You have some javascript where the user has selected some values you intend to persist when the user presses reload.

Solution

Have a form with a hidden field

<input id="someId" type="hidden" />

Set the value with

document.getElementById("someId").value=someValue;

Get the value with

someValue=document.getElementById("someId").value;

NB!If you dynamically add and remove input elements to the form as part of the javascript code, make sure the hidden fields are placed before any of the dynamic elements. The values are saved in the order the fields had when the user clicked to reload, and they are restored in the order the fields have initially, so if you have added fields before the hidden ones, the values are shifted to other fields.

while writing javascript it’s nice to actually see the errors I make.

Solution

Open chrome://global/content/console.xul in a new tab or window.

While upgrading a CentOS 4.5 to CentOS 5.*, yum starts to fail with

/usr/lib/python2.4/site-packages/_sqlitecache.so: undefined symbol: g_assert_warning

Please install a package which provides this module, or
verify that the module is installed correctly.

It’s possible that the above module doesn’t match the
current version of Python, which is:
2.4.3 (#1, May 24 2008, 13:47:28)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]

Reason

The reason was that the glib2 package hadn’t been updated at the same time as the yum and python packages, since they only required glib2 and not a specific version.

Solution

So the solution was to upgrade glib2 manually with the rpm command after which yum worked again.

I was trying to have the yum cache on a lustre mount so it could be shared amongst several machines to save on external bandwidth, but got the message that
_sqlite.OperationalError: database is locked

It also happens with an nfs mounted directory.

Solution

For lustre solution was to mount with localflock, for nfs the solutions is to make sure the nfslock service is running.

I had the problem that programs compiled with icc and ifort needed a library from the compiler’s directory to run, and I had gotten tired of needing to set LD_LOAD_PATH

Solution

Adding -Wl,-R/path/to/lib to the linker line solved the problem.

With an autotools based distribution, it was a matter of going:
/configure LDFLAGS=-Wl,-R/opt/intel/cce/10.1.015/bin CC=/opt/intel/cce/10.1.015/bin/icc CXX=/opt/intel/cce/10.1.015/bin/icpc F77=/opt/intel/fce/10.1.015/bin/ifort FC=/opt/intel/fce/10.1.015/bin/ifort --prefix= ...

I have a system that HP’s System Insight Manager previously discovered but I don’t want to see it any more.

Solution

This is done with by running

mxnode -r

on a command line on the HP SIM server.

A multiprocessor program using OpenMPI 1.2.6, with OFED 1.2.5 has some nodes fail with the following message:

[0,1,0][/home/henrik/src/openmpi-1.2.6/ompi/mca/btl/openib/btl_openib_component.c:1334:btl_openib_component_progress] from hidden.hidden.dk to: hidden.hidden.dk error polling HP CQ with status LOCAL PROTOCOL ERROR status number 4 for wr_id 7510264 opcode 42
[hidden.hidden:29673] [0,1,7]-[0,1,0] mca_oob_tcp_msg_recv: readv failed: Connection reset by peer (104)

The error was caused by calling system(3) in the short time between calling MPI_Send and the corresponding MPI_Recv which resulted in the send buffer being corrupted and the MPI_Recv call failing.

Solution

The solution was to either use MPI_Barrier to ensure all pending communication had finished or to replace the call of system(3) with another way to achieve the same result.

Mail sent from gmail to accounts on my mail servers never got through and the sender got an error message saying:

Technical details of permanent failure:
TEMP_FAILURE: The recipient server did not accept our requests to connect. Learn more at http://mail.google.com/support/bin/answer.py?answer=7720

This was a bit confusing as mail from everyone else got through without problems.

Cause

I had to use tcpdump to finally figure out why no mail from gmail was getting through to my mail server.

After trying myself while looking at the actual communication I could see that the connection actually got started correctly but all packets from the Gmail server had a tcp window of 90 bytes and, that if the first packet from my server didn’t include the CRLF (because it was too long) then the next packet from the Gmail server wasn’t an ack, but an rst in response to a resent packet, indicating the Gmail server dropped the connection without closing it, possibly because the connecting process died.

I confirmed the diagnosis by reconfiguring my mail server to start with a shorter greeting after which Gmail got through without any problems.

Note here that a limit of 88 characters for the “220 ” greeting is very far from the 512 bytes RFC2882 requires a standard compliant application to accept, so I’m considering this posting to be a bug report on a problem that’s likely to affect many, but is likely to be hard to solve for most because of the misleading error message.

Solution (temporary)

I reconfigured sendmail on the servers to use a shorter greeting by adding the following line to the .mc file:

define(`confSMTP_LOGIN_MSG', `$j Sendmail $b')

Solution (permanent)

The permanent solution would be to get Google to fix their mail servers, but so far I haven’t been able to figure out how to get in touch with the actual tech people at Gmail.

As a user, how do I control which files are backed up by EMC Networker?

Solution

In the directory you want to control, create a file called .nsr (in Linux) or nsr.dir (in Windows) containing skip directives such as
+skip: *.tmp

The “+” means it also covers subdirectories.

I tried starting ufoai after installing it and got an error saying:

SDL SetVideoMode failed: Couldn't find matching GLX visual

While googling for the error I could see it also happens with Quake2, though I haven’t installed that myself so I only have the general rather than specific solution for that program.

Cause

This happens with many SDL programs at startup, because the program can’t detect the video mode X windows is in, so it tries with the default settings, and if they are not compatible with the current mode, you get the “SDL SetVideoMode failed: Couldn’t find matching GLX visual” error.

Solution

In general the solution is to explicitely set the video mode the program is supposed to use so it matches the current mode.

For ufoai specifically, this was done by creating a config.cfg in ~/.ufoai/2.2/base containing

  set r_bitdepth "16"
  set r_colordepth "4"

since that’s what matched the screen configuration I was using.

Other programs are likely to have a similar way to control which values the program should call SetVideoMode with.