[mi] EQ overflowing. The server is probably stuck in an infinite loop.
...
Backtrace:
...
... /usr/lib/xorg/modules/drivers/intel_drv.so
...


in the :0… logfiles in /var/log/gdm when the problem occurs.

This is, however, not a kernel, XServer or GDM issue, but caused by a problem with the intel-linux driver. The problem is apparently fixed as of version 2:2.11.0-1ubuntu1 of the xserver-xorg-video-intel driver. Since this is not (yet) an update in the official distribution repo, I did the following to solve the issue:

1: Optional: Update to the latest stable kernel

Reason: IMO, upstream Intel drivers are usually build against the latest stable kernel

Goto http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/ and download the headers… _all.deb, headers-generic …..deb and linux-image… .deb for your platform (in most cases, i368). install the generic headers package, then the all headers package, then the image.

A word of warning: If you install this custom kernel you will not receive security updates for it from the automatic distribution updates.

2: Add the X Updates PPA to your sources.list

In a terminal, type:


sudo gedit /etc/apt/sources.list


And add at the bottom of the file (if not already present):


deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu lucid main #X-Updates PPA
deb-src http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu lucid main #X-Updates PPA


2.1: Trust the software packages from the x-updates PPA

sudo apt-key adv –recv-keys –keyserver keyserver.ubuntu.com AF1CDFA9

3: Update the driver


sudo apt-get update
sudo apt-get dist-upgrade


Reboot – the problem should be solved.


[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists


If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.

This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:

Use the latest 2.x snapshot version of the maven release plugin and configure it to use remote tagging (on the subversion server) rather than tagging from your local copy.

You can do so by

1.) Adding the apache snapshots repository to your plugin repositories list

    <pluginRepositories>
        <pluginRepository>
            <id>apache-snapshots</id>
            <name>Apache Snapshot Repository</name>
            <url>http://repository.apache.org/snapshots/</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
        ...
    </pluginRepositories>

2.) Configuring the release plugin’s version and tagging

        ...
        <build>
        ...
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.0-beta-9-SNAPSHOT</version>
                    <configuration>
                        <tagBase>full url to the tags directory on the svn server</tagBase>
                        <!-- See http://jira.codehaus.org/browse/SCM-406 -->
                        <remoteTagging>true</remoteTagging>
                        <!-- Further non-mandatory but useful settings... -->
                        <preparationGoals>clean install</preparationGoals>
                        <autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        ...
        </build>
        ...

This fixed it for me.

Note: i had problems getting this to function with the scp:// protocol (provider) for my distribution repository. It seems logic, tough, that the choosen provider must support remote tagging, thus i choose the scpexe:// protocol (using a local scp executable) instead, that worked:

...
<distributionManagement>
<repository>
  <id>myReo</id>
  <name>myreo</name>
  <url>scpexe://...</url>
 </repository>
...
</distributionManagement>
...

Apparently, the upcoming 2.0 release of the maven-release-plugin will have remote tagging as default, so if you read this and the 2.0 version has been released, simply using it should do the job.

Just for the record: It seems the new Debian Lenny release is close at hand.
Apparently a few packages for the lenny release already made it into the productive repositories, which causes them to be held back by apt-get upgrade:


apt-get dist-upgrade -V
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages have been kept back:
libapache2-mod-php5 (... => 5.2.6.dfsg.1-1+lenny2)
libperl5.8 (... => 5.8.8-11.1+lenny1)
php-pear (... => 5.2.6.dfsg.1-1+lenny2)
...


apt-get dist-upgrade, which usually resolves this issue by upgrading the system to the most recent release does not work yet, since lenny was not released so far.

Update June 22, 2010

The configuration described below is still valid up to the most recent Ubuntu release (10.04) !

This monday was sweet. I finally had the time to make a fresh install of ubuntu 8.10 on my thinkpad r52, and what can i say, just as all the other releases before, things got better.

I am especially happy about the re-programmed network manager, which works a whole lot better than in hardy.
Except that i didn’t get the PPTP VPN connection to my office to work instantly.

Turns out there is some kind of problem that prevents the network manager from obtaining the configured password, resulting in the error message:


The vpn connection X failed because there were no valid VPN secrets.


Furthermore, point-to-point encryption is not enabled by default any more. Here is how i got it to work:

1: Prerequisites: Install the required packages

If you don’t have pptp VPN support for network manager yet, install it…


sudo apt-get install network-manager-pptp


… and configure your VPN connection using the network manager.

2: Clear the password field in the vpn settings dialog

This should make the manager prompt you for the password.

3: Enable point-to-point encryption on the “Advanced” settings page

This should do! Now the PPTP settings should be about the same they where in hardy.

If you still experience problems, you might want to check the syslog for messages from the network manager, like so:


tail -f /var/log/syslog


Long story short, subclipse requires subversion 1.5, but ubuntu 8.04 provides 1.4.x.
If you still want to use subclipse with ganymede in ubuntu, there are only two ways two achieve this – both of which i cannot recommend because they are hacks or bad compromises.

a.) You could add the the ubuntu package source of the upcoming ubuntu release (i.e. deb http://fr.archive.ubuntu.com/ubuntu intrepid main) and install subversion 1.5 and the package libsvn-java from it. This is a bad idea since it will also install a bunch of transitive dependencies not designed for ubuntu 8.04. It might in fact damage your installation.
b.) You could not use the java hl API but a software connector completely written in JAVA (SVNKit client). This will work at first sight, but will convert your svn repository into 1.5 format. As a consequence, you can no longer use the svn command line client, since it does not support this format.

Subversive as an alternative to subclipse

Facing the above problems, i looked for an alternative and tried subversive. It’s an official and free eclipse plugin. The developers intend to make it the default subversion support plugin for eclipse.
It installed without any problem and worked really well with the javaHL api shipped with ubuntu 8.04. Look and feel of the plugin do not differ much from subclipse – subversive even offers a couple of additional useful options.

Here is how i installed and configured subversive:

1. Follow the installation instructions on the subversive download site.
   Since you will use the native javaHL connector implementation, be sure to choose the javaHL implementation from the update site:
   
2. Install the java HL API on ubuntu: sudo apt-get install libsvn-javahl.
3. Add the library directory where javahl resides to your eclipse.ini (located in the root folder of your eclipse installation). Just add the following line into it:
   -Djava.library.path=/usr/lib/jni.
4. Restart eclipse
5. Verify your setup.
   Goto Window>Preferences>Team>SVN and click the “SVN Connector” tab.
   The native javaHL connector should be selected
   

I’m working with it since about a week, it’s fast, has not failed on my a single time and is easy to use.

Note that his issue affects all debian-based systems, including ubuntu 8.04.

Source: http://lists.debian.org/debian-security-announce/2008/msg00152.html

Seems i’ll have a somewhat busy weekend.

Unfortunately, such a setting usually does not contain a username, since this has to be provided by the actual team member connecting to version control.
Neither did i have any intention to configure a placeholder into the scm section, forcing the developers to mess with the maven settings.xml in order to provide their own username.

Luckily, after searching a while, i found a proper solution.
SSH allows an optional per-host specific username setting to be placed in a file called “config” located in the user’s .ssh directory, for example

File: ~/.ssh/config


Host my.host.name
User myusername


Thanks to Chad Humphries for posting the Solution on programming is hard.
It really wasn’t…

mvn-Vervollständigung unter Ubuntu 7.10 (Gutsy Gibbon)

Unter der ubuntu-Distribution 7.10 (Gutsy Gibbon) aktiviert man die autocompletion durch Anlegen einer completion-Datei im Verzeichnis /etc/bash_completion.d, beispielsweise mit folgenden Inhalt:

#!/bin/bash

_m2_make_goals()
{
  plugin=$1
  mojos=$2
  for mojo in $mojos
  do
    export goals="$goals $plugin:$mojo"
  done
}

_m2_complete()
{
  local cur goals

  COMPREPLY=()
  cur=${COMP_WORDS[COMP_CWORD]}
  goals='clean compile test install package deploy site'
  goals=$goals _m2_make_goals "eclipse" "eclipse"
  goals=$goals _m2_make_goals "idea" "idea"
  goals=$goals _m2_make_goals "project-info-reports" "dependencies"
  goals=$goals _m2_make_goals "assembly" "assembly"
  goals=$goals _m2_make_goals "plexus" "app bundle-application bundle-runtime descriptor runtime service"
  cur=`echo $cur | sed 's/\\\\//g'`
  COMPREPLY=($(compgen -W "${goals}" ${cur} | sed 's/\\\\//g') )
}

Quelle: Working more productively with bash 2.x/3.x

Wie das ganze für Windows und MAC eingerichtet wird, steht auf willcodeforbeer.

Hin und wieder ist man in der Universität mit der vergnüglichen Tatsache konfrontiert, dass es weder eine brauchbare vorhandene Anzahl an Entwicklungswerkzeugen gibt, noch dass sich irgend jemand – ausserhalb von Lehrveranstaltungen – um Prozesse in der Softwareentwicklung kümmert.

Sprich: Ein Projekt soll umgesetzt werden, und außer einem SVN-Account gibt’s nichts.

Bei einem Team von 8 Leuten ist das völlig unzureichend. Neben einem ordentlichen Issue tracking bin ich auch daran gewöhnt, mittels eines Continous Integration-Systems aktuelle Buildstände abzurufen und den Stand der Dinge im Auge behalten zu können. Von einem ordentlichen WIKI zur Projektdoku ganz zu schweigen.

Da der Code an sich mittels Maven2 verwaltet wird, hatte ich sofort continuum ins Auge gefasst – schließlich ist continuum selbst Java-basiert und speziell für maven – Projekte entwickelt.

1.1: Voraussetzungen

Da Continuum eine J2EE-Webapplikation ist, muss zunächst einmal ein entsprechender Servletcontainer her.
Im recht schwachbrüstigen WIKI werden Resin, JBOSS, tomcat und glassfish als Referenzen angeführt.
Da ich mich gut mit Tomcat auskenne entschloss ich mich, continuum mit diesem zu installieren. als JDK entschied ich mich für Sun’s JDK 1.6.3, Datenbank sollte nicht die integrierte Derby, sondern ein vorhandenes MYSQL werden.

1.2: Die richtige Distribution herunterladen

Auf der continuum-Downloadseite stehen unterschiedliche Arten des 1.1-Releases zur Verfügung:
Die etwas schräge standalone-Distribution (Warum sollte man so etwas benutzen, wo es ein schönes, Standardkonformes WAR-Deployment gibt?), und die webapp-Distribution.
Ich empfehle in jedem Fall letztere zu verwenden, da somit kein Herumgefrickel in irgendwelchen Scripten notwendig wird.

1.3: continuum deployen und konfigurieren

1.3.1: Tomcat installieren

Der gute Tomcat lässt sich sehr einfach installieren. Ist das JDK vorhanden muss lediglich die Umgebungsvariable JAVA_HOME gesetzt sein.
Dann reicht es, wenn man keine weiteren Anpassungen braucht, die tomcat 6 core-distribution herunterzuladen und zu entpacken. Unix-typisch sind unter bin/ die ausführbaren Dateien, sprich start-Scripts (auch das weiter unten erwähnte catalina.sh – Script).
Unter conf/ findet man die server.xml, in welcher man die unten angeführten Anpassungen für die mysql-Anbindung durchführen kann.

1.3.2: continuum-Parameter in Umgebungsvariablen

Aus einem mir unklaren Grund brauch die continuum-webapp zwei JVM-Parameter um sich “zu orientieren”:
appserver.home und appserver.base sollten entsprechend auf das CATALINA_HOME und CATALINA_BASE Verzeichnis zeigen.
Bei einer sauberen default- Installation sind diese Verzeichnisse identisch. Ich habe das durch einen Eintrag am Anfang der catalina.sh erledigt:

export CATALINA_OPTS="-Dappserver.home=$CATALINA_HOME -Dappserver.base=$CATALINA_HOME"

1.3.3: MYSQL anbinden

Out-Of-The-Box verwendet Continuum Derby als Datenbank. Da ich MYSQL verwenden wollte war es notwendig, eigene DataSource-Konfigurationen vorzunehmen.
DataSources können Global oder Kontext-spezifisch in Tomcat Konfiguriert werden. Ich entschied mich, sie im <Context> Element der server.xml zu konfigurieren:

<Context path="/continuum" docBase="continuum">
<Resource name="jdbc/users"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="jdbc/continuum"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="mail/Session"
            auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>
</Context>

Dazu muss der passende mysql-connector natürlich im lib-Verzeichnis des Tomcats platziert werden. (Bei 5′er Tomcats unter common/lib, ab 6 einfach “lib”).
Wichtig ist, dass der Datenbanknutzer Tabellen etc. anlegen darf. Zudem ist bei der Anbindung von continuum an MYSQL oft folgende Fehlermeldung zu sehen:


Error thrown executing CREATE TABLE '.....'
...
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too long; max key length is 765 bytes


Das Problem existiert, da Continuum PRIMARY KEY-Constraints über mehrere varchar-Felder (als composite primary key) verwendet und tritt auf, wenn für
das Encoding der für continuum verwendeten Datenbank ein Encoding gewählt wurde, wass mehr als ein Byte pro Character verwendet – Beispielsweise “utf8_general_ci”.
Ich habe aus diesem Grund ein latin1-Encoding verwendet – Danach lief alles glatt.

1.3.4: Richtiges ablegen der .war-Datei

Extrem wichtig ist, dass Verzeichnis der continuum webapp unter “webapps” genau so zu nennen wie den Contextnamen:

<Context path="/continuum" docBase="continuum">

Da es ansonsten zu unangenehmen Fehlern bei der Auflösung der konfigurierten Datasource kommt.
Das continuum….war-File sollte also unter “webapps” am besten als “continuum.war” gespeichert werden.

1.3.5: Start!

Mit diesen Einstellungen sollte die Continuum webapp starten. Der Startvorgang wird recht ausführlich im logs-verzeichnis von catalina protokolliert.

1.4: Konfiguration verbessern

Die Out-Of-The-Box Konfiguration hat noch ein paar Defizite, welche in der application.xml der ausgepackten .war-Datei verbessert werden können.
Diese findet sich unter …/webapps/continuum/WEb-INF/classes/META-INF/plexus.

Unter

    <!--
    | The mail notifier
    |-->
    <component>
      <role>org.codehaus.plexus.notification.notifier.Notifier</role>
      <role-hint>mail</role-hint>
      <implementation>org.apache.maven.continuum.notification.mail.MailContinuumNotifier</implementation>
    ...

Sollte beispielsweise die sender-mailbox konfiguriert werden, da continuum sonst als continuum@localhost Nachrichten per SMTP versendet:

    <configuration>
        <from-mailbox>continuum@myhost.domain</from-mailbox>
        <from-name>Continuum Server</from-name>

1.5: Problem mit Jsch beheben

In der mit Continuum ausgelieferten Version enthält die java secure channel-Blibliothek Noch einen Nullpointer-Fehler, der sich
allerdings erst dann zeigt, wenn tatsächlich ein build in continuum durchgeführt wird. Dann erscheint folgendes im build-log:


...
java.lang.NullPointerException
at com.jcraft.jsch.ChannelSession.run(Unknown Source)
...


Zum Beheben einfach das jsch….jar File aus dem WEB-INF/lib Verzeichnes der continuum webapp mit einer aktuelleren Version, in meinem Fall jsch-0.1.36.jar, ersetzen.

Weiter geht es in Maven2-Projekt in Continuum konfigurieren.