27 February 2014

ReviewBoard: RandomPool has no attribute 'new'

ReviewBoard 1.7.21 is installed from packages on CentOS6.4

Error message from post title is shown when I add a BitBucket repository. Inspecting sources of ReviewBoard it appeared that it performs a workaroung in case an old version on pycrypto lib is installed. And the workaround doesn't work quite well.

My distro had 2.0.1 version installed, so I had to find a newer version manually and install it with rpm -Uvh. After restarting apache everything worked fine.

10 February 2014

MalformedUrlException o_O

Caused by:
        at java.net.URL.(URL.java:601)
        at java.net.URL.(URL.java:464)
        at java.net.URL.(URL.java:413)
        at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
        at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        at org.apache.xalan.templates.StylesheetRootProxy.(Unknown Source)
 at java.net.URL.(URL.java:601)
 at java.net.URL.(URL.java:464)
 at java.net.URL.(URL.java:413)
 at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:649)
 at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186)
 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772)
 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
 at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
 at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
 at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)

...may just mean that you pushed a null InputSteam into parser.

For example this piece of code would produce such exception trace:

SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.parse(new InputSource((InputStream) null), new DefaultHandler());

It also may be done in less explicit way, for example with an XSLT parser being given XSLT source with null InputSteam inside (which actually was the issue I originally faced).

06 January 2013

LXDM PostLogout script to shutdown user's apps

LXDM is a bit strange in it's behaviour to not to kill your apps running when you log out. After logging out my deadbeef continues to play music and conky is still drawn on top of LXDM greeter. Look funny heh :)
I don't really like this, but I wanted DM to show list of users instead of simple prompt. Arch wiki suggests just to killall --user $USER which would also kill all your background processes they may be running (torrent, screen, etc).
Enough words - here goes the script:
$ cat /etc/lxdm/PostLogout 
# Note: this is a sample and will not be run as is.

current_windows=`xlsclients -al | grep Window | cut -d' ' -f2 | sed -e 's/:$//'`
for wid in $current_windows
        pid=`xprop -id ${wid} _NET_WM_PID | awk -F ' = ' '{ print $2 }'`
        wmname=`xprop -id ${wid} WM_CLASS | cut -d= -f2 | cut -d, -f2 | sed -e 's/[ "]//g'`
        if [ "p${pid}" != "p" ]
                echo "Killing ${wmname} (${pid})"
                kill ${pid}
                echo "No PID found for ${wmname}"

# for some reason PID for conky cannot be determined
killall --user $USER conky
It requires xlsclients and xprop. Some apps (like conky) are special case and they don't show their PID in X11 properties of a window, so they are killed separately.

05 November 2012

Archlinux moves to systemd. My own remarks.

After notice that systemd is now default in new installations I realised that sooner or later I'll be forced to migrate disregarding whether I like this idea or not :)
After some reading I rebooted, edited kernel loading line in my Grub2 with init param pointing to systemd and booted into my Arhclinux. What was noticable that I received to GUI :) Though I was aware that systemd ignores /etc/inittab (my SLiM used to start from inittab) and I wasn't that surprised. I did sudo systemctl enable slim.service (along with couple of other services which made sense for me) and rebooted again (needed not to forget to put init kernel param in place again).
Basically everything went smooth except just a few points, which weren't clear from documentation and which made me post this writing :)


Here I'm talking about pure systemd installations.


1. systemd-sysvcompat

Documentation from Archwiki states that you must not remove this package or you won't be able to boot any more. Though this package doesn't seem to contain any things I may need now (file list for systemd-sysvcompat). And it appeared to be true - if you want to remove this package you need to do the following (instructions for Grub2 loader):
  1. edit /etc/default/grub and make sure you have init kernel param present, like this:
  2. regenerate grub.cfg with
    sudo grub-mkconfig -o /boot/grub/grub.cfg
  3. now when everything went fine you could remove unnecessary things:
    sudo pacman -Rcs sysvinit-tools
    this should remove sysvinit-tools, initscripts, sysvinit and systemd-sysvcompat.

2. PCManFM doesn't show removable drives

While some other tools may show them. If not check documentation first. For me problem was that udisks daemon was inactive. So simple sudo systemctl enable udisks.service fixed this for me.

These seem to be all the troubles with systemd for me, which I find pretty painless! :) And instead of conclusion: if you want to know what else services you could enable (or disable) use systemctl list-unit-files

    24 September 2012

    Using multiple input documents for XSLT transformation

    I believe I'm not alone when I need to use couple of input documents for a XSLT transformation. It's rather common case to have input data from multiple sources, to process it and to return a single result. Should XSLT be an exception? Not this time.
    If we look at data type mapping it obvious that we could accept and return Nodes, NodeLists, etc. We could do the same with transformer parameters as well. Here is an example:

    Document doc = ...; // direct input for transformer
    Document anotherDoc = ...; // second document to be passed as parameter
    TransformerFactory factory = TransformerFactory.newInstance();
    Transformer transformer = factory.newTransformer(xsl);
    transformer.setParameter("anotherDoc", anotherDoc);
    transformer.transform(new DOMSource(doc), new StreamResult(System.out));

    <xsl:stylesheet version="1.0"
      <xsl:param name="anotherDoc" />
      <xsl:variable name="inputDoc" select="/" />
      <xsl:template match="/">
        <xsl:apply-templates select="$anotherDoc/anotherRoot" />
      <xsl:template match="nodeOfAnotherDoc">
        <xsl:value-of select="text()" />
        <xsl:value-of select="$inputDoc/root/@attr" />

    That's all the trick, we could operate of another document just on regular xsl:variable containing a node-set.
    Just one hint: it may be useful to have a variable referencing input document root (inputDoc in example), because inside context of xsl:template that matched anotherDoc you may have trouble accessing nodes of input document.