...and just now I have neither time nor nerve to look for a fix. "O" apparently is transmitted as enter, the left mouse button opens context menus, and so on. Neither a VNC restart on the remote machine nor a KRDC restart change anything - I've had that problem before (maybe it's the compressed ssh tunnel). Most forum and blog posters complain about apparent tightvnc bugs, but for me, switching to a different viewer already did the job.
Usually, the KDE3 KRDC version is less buggy (look for package kdenetwork3-vnc), but if you need just a plain vanilla VNC without extras like full screen windows and special key transmission, tightvnc's vncviewer (package tightvnc, binary is /usr/bin/vncviewer) has a nice minimalist interface (no space-eating menus). The -fullscreen option is also very useful.
19/09/2008
18/09/2008
Setting up an Apache server for testing purposes
First, why the hell would we do that? In my case, I have to play around with some simple PHP gallery scripts at the moment, and I am not very keen on testing them instantly on our university server (I expect the sysadmins aren't very keen on that, either, I'm a complete noob on a steep learning-by-doing curve).
Note: I include some MySQL directions here, because a lot of scripts manage MySQL databases. However, e.g. for a not-too-complicated image gallery PHP alone should do the job.
Warning: Don't follow this to configure a fully functional web server: a little knowledge is a dangerous thing - and who lets a total noob configure a web server anyway? This is just to get some practice - reduce my amount of noobness, so to say - working locally, I didn't care too much about security.
Packages to install: Either go for the full LAMP glory (YaST->Software->Patterns>Web and LAMP server), or install by hand apache2, php5, apache2_mod_php5 (if you want php4, find a repo, it's not in the official openSuSE 11 distro any more), if you want Mysql, also mysql, php5-mysql and probably phpMyAdmin. For any kind of server administration, Webmin is also not a bad idea.
To start the apache daemon: run sudo /etc/init.d/apache2 start (at least that's where the http daemon is on my system - you need the full path because it's not in PATH). Guess the code for stopping…
Check your firewall (YaST->Security and users). The allowed services for the External zone should include nothing like 'Apache' or 'HTTP daemon'. Thus, you won't need to fiddle with access control settings, the server is only accessible from localhost (however, some good information on that subject is here and here).
I don't know about other distros, but on openSuSE there is a public_html directory in your home folder. Any HTML documents you store there can be accessed on http://localhost/~<your user name>.
This is comfy if you keep the server local. On a public server I would strongly advise against public folders in one's home directory. However, you can change that in the Apache config files: Remove the userdir entry from the APACHE_MODULES list in /etc/sysconfig/apache2 (either modify the file directly or use the YaST module System->/etc/sysconfig Editor).
Note: I include some MySQL directions here, because a lot of scripts manage MySQL databases. However, e.g. for a not-too-complicated image gallery PHP alone should do the job.
Warning: Don't follow this to configure a fully functional web server: a little knowledge is a dangerous thing - and who lets a total noob configure a web server anyway? This is just to get some practice - reduce my amount of noobness, so to say - working locally, I didn't care too much about security.
Packages to install: Either go for the full LAMP glory (YaST->Software->Patterns>Web and LAMP server), or install by hand apache2, php5, apache2_mod_php5 (if you want php4, find a repo, it's not in the official openSuSE 11 distro any more), if you want Mysql, also mysql, php5-mysql and probably phpMyAdmin. For any kind of server administration, Webmin is also not a bad idea.
To start the apache daemon: run sudo /etc/init.d/apache2 start (at least that's where the http daemon is on my system - you need the full path because it's not in PATH). Guess the code for stopping…
Check your firewall (YaST->Security and users). The allowed services for the External zone should include nothing like 'Apache' or 'HTTP daemon'. Thus, you won't need to fiddle with access control settings, the server is only accessible from localhost (however, some good information on that subject is here and here).
I don't know about other distros, but on openSuSE there is a public_html directory in your home folder. Any HTML documents you store there can be accessed on http://localhost/~<your user name>.
This is comfy if you keep the server local. On a public server I would strongly advise against public folders in one's home directory. However, you can change that in the Apache config files: Remove the userdir entry from the APACHE_MODULES list in /etc/sysconfig/apache2 (either modify the file directly or use the YaST module System->/etc/sysconfig Editor).
Konqueror wants to open web documents in editor
One of the problems when you marry a file manager to a web browser. I don't recollect why the file association got changed in the first place, but it's easy to change it back again:
Settings->Configure Konqueror...->File associations: Search for HTML under 'Find filename pattern', it's probably in 'text' or 'application'. Set 'Show file in embedded viewer' in the Embedding tab and make sure 'KHTML' is the first item under Services Preference Order.
If you still want to edit local HTML documents, use the right-click menu.
12/09/2008
More gcc 4.3 'victims'
Quoting from a KDE mailing list: "In GCC 4.3, the C++ header
dependencies have been cleaned up. The advantage of this is that programs will compile faster. The downside is that you actually
need to directly #include everything you use".
So, if you get make errors like "error: 'free' was not declared in this scope", this might be due to a source file missing the (c)stdlib dependency.
This is kind of a wailing wall for patch candidates.
dependencies have been cleaned up. The advantage of this is that programs will compile faster. The downside is that you actually
need to directly #include everything you use".
So, if you get make errors like "error: 'free' was not declared in this scope", this might be due to a source file missing the (c)stdlib dependency.
This is kind of a wailing wall for patch candidates.
- miktex: patch exists
- qtpfsgui-1.8.12: #include <stdlib.h> in src/Libpfs/pfs.cpp and src/TM_operators/ashikhmin02/tmo_ashikhmin02.cpp
1.8.12 is the current stable release, the "new" version (>1.9.2) is already patched. - lshw-B.02.13: src/core/abi.cc needs cstdlib
26/08/2008
Compiling master documents in Kile
Kile has no special "build project" tool for building LaTeX master files (which irritates former TeXnicCenter users like me).
To handle LaTeX master files, e.g. a thesis with chapter input from \include{file} statements, define a Kile project and add all .tex files irrespective of master and child status.
Check the master file in the project options, usually the auto-detect option works (I assume Kile searches all files for \begin{document}/\end{document}). All normal build tools shold now apply only to the master file, no matter which document you are just editing.
Another issue: Using BibTeX in a Kile project. For this you need the QuickBuild tool. PDFLaTeX+BibTeX isn't preconfigured (at least with my Kile version) and has to be added by hand in Settings->Configure Kile…->Tools->Build:
PDFLaTeX
BibTeX
PDFLaTeX
PDFLaTeX
After that, you can run everything from inside Kile with the QuickBuild button.
If you are using a Kile project with a master document, you have to specify the appropriate QuickBuild configuration in the Project->Project Options dialog. (Actually, if you include a BibTeX bibliography in a .tex file, Kile seems to run BibTeX and 3 times LaTeX automatically. Still, it's good to have the QuickBuild handy). Also, there was a bug removing duplicate entries like "PDFLaTeX PDFLaTeX" in the Quickbuild configuration of Kile/KDE4 (fixed by now).
To handle LaTeX master files, e.g. a thesis with chapter input from \include{file} statements, define a Kile project and add all .tex files irrespective of master and child status.
Check the master file in the project options, usually the auto-detect option works (I assume Kile searches all files for \begin{document}/\end{document}). All normal build tools shold now apply only to the master file, no matter which document you are just editing.
Another issue: Using BibTeX in a Kile project. For this you need the QuickBuild tool. PDFLaTeX+BibTeX isn't preconfigured (at least with my Kile version) and has to be added by hand in Settings->Configure Kile…->Tools->Build:
PDFLaTeX
BibTeX
PDFLaTeX
PDFLaTeX
After that, you can run everything from inside Kile with the QuickBuild button.
If you are using a Kile project with a master document, you have to specify the appropriate QuickBuild configuration in the Project->Project Options dialog. (Actually, if you include a BibTeX bibliography in a .tex file, Kile seems to run BibTeX and 3 times LaTeX automatically. Still, it's good to have the QuickBuild handy). Also, there was a bug removing duplicate entries like "PDFLaTeX PDFLaTeX" in the Quickbuild configuration of Kile/KDE4 (fixed by now).
25/08/2008
Blank Java windows with compiz
Java apps (e.g. my favourite BibTeX editor, JabRef) have a habit of coming up as persistently blank windows with compiz and several recent Java versions. According to this thread this is due to Java expecting your window manager to re-parent the window which compiz doesn't (I'm so not a WM expert...). The following workaround did OK for me. Override the Java VM's default AWT Toolkit, e. g. calling JabRef:
export AWT_TOOLKIT=MToolkit
java -jar JabRef-2.3.1.jar
If you use Java apps a lot, it might be a good idea to add the export statement to your ~/.bashrc - or write the two lines above in a shell script in /usr/bin or similar.
UPDATE (2010): My days of compiz are long past, but I didn't change my ~/.bashrc despite several new SuSE installations. Running Jabref 2.5 with Sun's Java 1.6.0_17 on SuSE 11.2 (KDE 4.4β) produced a segfault citing a problematic frame in libc.so.6. Unsetting the AWT_TOOLKIT variable solved it.
export AWT_TOOLKIT=MToolkit
java -jar JabRef-2.3.1.jar
If you use Java apps a lot, it might be a good idea to add the export statement to your ~/.bashrc - or write the two lines above in a shell script in /usr/bin or similar.
UPDATE (2010): My days of compiz are long past, but I didn't change my ~/.bashrc despite several new SuSE installations. Running Jabref 2.5 with Sun's Java 1.6.0_17 on SuSE 11.2 (KDE 4.4β) produced a segfault citing a problematic frame in libc.so.6. Unsetting the AWT_TOOLKIT variable solved it.
16/08/2008
Samsung P35: openSuSE 11 and Compiz
After I had completely f**ked up my X-Server by trying different fglrx drivers in order to get a reasonable compiz 3d-Acceleration, I finally decided to throw away my openSuSE 10.3 and install openSuSE 11 on my Samsung P35 XVM 1600 II, graphics card ATI Mobility Radeon 9700 series. Installation went smooth, apart from the interesting suggestion of the setup program not to just mount my home partition, but format it (yes, you should be careful about that as well - I don't want to lose all my settings just because openSuSE thinks that might be a good idea).
After the reboot, I was more than impressed... Compiz was running out of the box, without even the need to use the ati fglrx driver. This is the proof, with the radeon driver included in the XServer version of openSuSE 11 the card definitely runs AIGLX - by the way also without the well known "freeze after ending an x-session" error. Video playback of embedded flash movies in firefox unfortunately flickers a little bit. But if you use fusion-icon, you can switch back to Kwin as window manager temporarily for viewing (add the openSuSE Build: Xgl/Xorg repo to Yast in order to find fusion-icon). On the other hand, playing movies with Kaffeine doesn't show flicker at all.
The hotkeys don't work out of the box, but it is sufficient to look for acerhk in Yast after adding the standard repos and choose the appropriate rpm for your kernel flavor (which you can also get by opening Konqueror and typing sysinfo:/ into the adress bar). After the necessary reboot all the (important) hotkeys work.
After the reboot, I was more than impressed... Compiz was running out of the box, without even the need to use the ati fglrx driver. This is the proof, with the radeon driver included in the XServer version of openSuSE 11 the card definitely runs AIGLX - by the way also without the well known "freeze after ending an x-session" error. Video playback of embedded flash movies in firefox unfortunately flickers a little bit. But if you use fusion-icon, you can switch back to Kwin as window manager temporarily for viewing (add the openSuSE Build: Xgl/Xorg repo to Yast in order to find fusion-icon). On the other hand, playing movies with Kaffeine doesn't show flicker at all.
The hotkeys don't work out of the box, but it is sufficient to look for acerhk in Yast after adding the standard repos and choose the appropriate rpm for your kernel flavor (which you can also get by opening Konqueror and typing sysinfo:/ into the adress bar). After the necessary reboot all the (important) hotkeys work.
01/08/2008
miktex-tools don't compile on openSuSE 11...
...because they included a newer gcc version (4.3.1 rc1). Typical make error: "expected ‘;’ before ‘<’ token". This is a known bug (see this discussion), and there is a patch - there are just some include statements missing.
Download the patch file mpm-2.7.3107-gcc-4.3.patch and run
patch -p0 < mpm-2.7.3107-gcc-4.3.patch
in the directory where you untarred the sources.
If your patch fails, try patching manually (read the patch file), it's just one or two lines each in less than 10 files. Mpm should compile OK now (HowTo).
A nice diff and patch intro can be found at linuxforums.org.
Considering the easy fix, I suppose they'll dispose of this bug soon ;-)
Download the patch file mpm-2.7.3107-gcc-4.3.patch and run
patch -p0 < mpm-2.7.3107-gcc-4.3.patch
in the directory where you untarred the sources.
If your patch fails, try patching manually (read the patch file), it's just one or two lines each in less than 10 files. Mpm should compile OK now (HowTo).
A nice diff and patch intro can be found at linuxforums.org.
Considering the easy fix, I suppose they'll dispose of this bug soon ;-)
Subscribe to:
Posts (Atom)