If you use the emptypage package in your LaTeX document, you might get this error on compiling it: emptypage.sty not found
On Ubuntu, this LaTeX package is bundled with the texlive-latex-extra package. Install this package and the error should be gone.
Tried with: Ubuntu 12.04 LTS
If you use the algorithm package in your LaTeX document, you might get this error on compiling it:
LaTeX Error: File `algorithm.sty' not found.
On Ubuntu, this LaTeX package is bundled in the texlive-science package. Install this package and the error should be gone:
$ sudo apt-get install texlive-science
Tried with: Ubuntu 14.04
You might get this error when you create a file or copy some files in a AFS filesystem: File too large
This error message is misleading because I found that the file I was creating or copying was not large at all. In fact, an attempt to create an empty file also gave this error!
On investigation, I found that this error happens because the AFS filesystem seems to have a limit of 64435 files in any given directory. If your AFS directory already has this many files, any attempt to create or copy over a file gives the above error.
One possible solution is to archive the files using tar and copy that archive file to AFS.
Tried with: OpenAFS 1.6.1-1 and Ubuntu 12.04 LTS
I have a Python script named foo.py. Since, I would like to run it directly from the shell, I have added a shebang to run it through Python:
print "Hello world"
If I run it directly at the shell, I get a strange error:
: No such file or directory
However, if I run it explicitly with the Python interpreter, it works fine:
$ python foo.py
This strange error turned out to be due to the newline markers in the file. The file was created on Windows and had CR+LF as the newline marker. But, I was running the script on Linux, which only uses LF as the newline marker.
So, this must have led the env program to run the character CR as a command. And obviously, it could not find any such file or directory.
The solution is simple. Convert the newline markers in the file to that of the host system, in this case to Linux. This can be done easily in Vim by using the fileformat option.
Tried with: GNU CoreUtils 8.12.197, Python 2.7.3 and Ubuntu 12.04 LTS
A LaTeX document that compiled with pdflatex without errors on Windows using MikTeX was failing with this error on Ubuntu:
Package epstopdf Warning: Shell escape feature is not enabled.
! Package pdftex.def Error: File `foobar-eps-converted-to.pdf' not found.
The document used the epstopdf package to include EPS figures. A foobar.eps figure that is included in the document would be converted to a PDF file named foobar-eps-converted-to.pdf. The inclusion of foobar.eps in the document was giving this error on Ubuntu.
It turns out that epstopdf converts the included EPS document to PDF at compile time. This requires a feature of pdflatex called shell escape. This seems to be enabled in MikTeX on Windows, but disabled in Ubuntu. The error went away on enabling the shell escape feature manually while compiling the document:
$ pdflatex --shell-escape main.tex
Tried with: Ubuntu 12.04.2 LTS
I had a LaTeX document that was compiling without errors under both Windows and Ubuntu systems. When a friend tried to compile it on their Ubuntu system using pdflatex, it spewed this strange error:
! pdfTeX error (font expansion): auto expansion is only possible with scalable fonts
The error was strange because it gave no clue how to solve it. It turns out that the LaTeX installation on that particular Ubuntu system did not have scalable fonts. The common solution seems to be to install the cm-super package which has scalable fonts that can be used by LaTeX. On installing this package and recompiling the document, the error went away.
Tried with: Ubuntu 12.04.2 LTS
I wanted to install Ubuntu Desktop 12.04.2 LTS on a 64-bit computer. I downloaded the ISO files using BitTorrent and created a USB flash drive installer. On booting from this USB flash drive, I got this error:
/casper/vmlinuz: file not found
The fix turns out to be simple. Remove the USB flash drive, reboot back to Windows and plug it back in. In the casper directory of the flash drive, there is a file vmlinuz.efi. Remove its extension to rename it to vmlinuz. Try the installation again, it should work.
Tried with: Ubuntu Desktop 12.04.2 LTS
Eclim enables you to access Eclipse features from Vim. But, when you run the eclimd server on your 64-bit computer, you get this error:
Your jvm does not support the architecture required for the version of eclipse you have installed: -d32
eclimd is a Bash script and it has detected that your JVM is 64-bit, but your Eclipse is 32-bit. If this really is the case, you will need to fix it by using a 64-bit version of Eclipse.
In my case, I was using 64-bit versions of both programs. I found that the architecture detection lines of the script might have a bug. Find these lines in the eclimd script:
# ensure that the correct jvm environment is used.
SWT=`ls $ECLIM_ECLIPSE_HOME/plugins/org.eclipse.swt.*.jar 2> /dev/null`
if `echo "$SWT" | grep -q "x86_64"` ; then
if ! `java $ARCH -version 2> /dev/null` ; then
echo "Your jvm does not support the architecture required " \
"for the version of eclipse you have installed: $ARCH"
Comment these out and replace them with this line:
eclimd should work fine now.
Tried with: Eclim 1.7.13, Vim 7.3, Eclipse 3.7 (Indigo) and Ubuntu 12.04 LTS
In your CUDA code, you have a cudaMemcpyToSymbol call of this form:
cudaMemcpyToSymbol( "deviceVar", hostVar, hostVarSize, 0, cudaMemcpyHostToDevice );
This gives a runtime error of invalid device symbol.
Check if you are using CUDA 5.0 or later. The technique of passing the device symbol by using its name string is gone in CUDA 5.0. Instead, just remove the double quotes to specify the device variable itself like this:
cudaMemcpyToSymbol( deviceVar, &hostVar, hostVarSize, 0, cudaMemcpyHostToDevice );
Tried with: CUDA 5.0
Mercurial gives this error for the hgrc (Mercurial configuration file) when the user running a Mercurial command is not the same as the owner of hgrc. This typically happens on servers, shares or distributed filesystems.
To fix this, add a trusted section to the configuration file to tell Mercurial to trust the user or group reported in the error.
For example, if Mercurial complains that it does not trust joe and you happen to trust him, add him to hgrc:
users = joe
Tried with: Mercurial 2.0.2 and Ubuntu 12.04.1 LTS