• CRAN Task View for Finance, on GitHub
• CRAN Task View for High-Performance Computing with R, on GitHub

#!/usr/bin/r
## if you do not have /usr/bin/r from littler, just use Rscript
ctv <- "Finance"
ctvfile  <- paste0(ctv, ".ctv")
htmlfile <- paste0(ctv, ".html")
mdfile   <- "README.md"
## load packages
suppressMessages(library(XML))          # called by ctv
suppressMessages(library(ctv))
r <- getOption("repos")                 # set CRAN mirror
r["CRAN"] <- "http://cran.rstudio.com"
options(repos=r)
check_ctv_packages(ctvfile)             # run the check
## create html file from ctv file
ctv2html(read.ctv(ctvfile), htmlfile)
### these look atrocious, but are pretty straight forward. read them one by one
###  - start from the htmlfile
cmd <- paste0("cat ", htmlfile,
###  - in lines of the form  ^<a href="Word">Word.html</a>
###  - capture the 'Word' and insert it into a larger URL containing an absolute reference to task view 'Word'
  "   sed -e 's ^<a href=\"\\([a-zA-Z]*\\)\\.html <a href=\"http://cran.rstudio.com/web/views/\\1.html\" '   ",
###  - call pandoc, specifying html as input and github-flavoured markdown as output
              "pandoc -s -r html -w markdown_github   ",
###  - deal with the header by removing extra  , replacing  ** with ** and **  with **:              
              "sed -e's/ //g' -e's/ \\*\\*/\\*\\*/g' -e's/\\*\\* /\\*\\* /g' -e's/ $/  /g' ",
###  - make the implicit URL to packages explicit
              "-e's ../packages/ http://cran.rstudio.com/web/packages/ g' ",
###  - write out mdfile
              "> ", mdfile)
system(cmd)                             # run the conversion
unlink(htmlfile)                        # remove temporary html file
cat("Done.\n")

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

$ openssl req -nodes -x509 -newkey rsa:2048 -keyout cal-key.pem -out cal-cert.pem -days 3650
[...]
Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Bologna
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:enricozini.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:cal.enricozini.org
Email Address []:postmaster@enricozini.org

$ openssl x509 -in cal-cert.pem -outform DER -out cal-cert.crt
$ adb push cal-cert.crt /mnt/sdcard/
$ enrico --follow-instructions http://davdroid.bitfire.at/faq/entry/importing-a-certificate

$ git clone git://keithp.com/git/calypso
$ git checkout debian -b enrico
$ git remote add chrysn  git://prometheus.amsuess.com/calypso-patches
$ git fetch chrysn
$ git merge chrysn/chrysn/integration
$ dch -v 1.4+enrico  "Merged with chrysn integration branch"
$ debuild -us -uc -rfakeroot

# dpkg -i calypso_1.4+enrico_all.deb

# adduser --system --disabled-password calypso
# chsh calypso  # /bin/dash

# cat /etc/default/calypso
CALYPSO_OPTS="-d -P $PIDFILE"
# diff -Nau calypso-init calypso-init.enrico
--- calypso-init        2014-11-26 11:50:35.301001194 +0100
+++ calypso-init.enrico 2014-11-26 12:18:16.564138554 +0100
@@ -62,8 +62,8 @@
          return 1
    mkdir -p $(dirname $PIDFILE)
-       chown calypso:calypso $(dirname $PIDFILE)
-       start-stop-daemon --start -c $NAME --quiet --pidfile $PIDFILE --exec $DAEMON -- \
+       chown calypso:nogroup $(dirname $PIDFILE)
+       start-stop-daemon --start -c $NAME:nogroup --quiet --pidfile $PIDFILE --exec $DAEMON -- \
        $CALYPSO_OPTS \
          return 2
    # Add code here, if necessary, that waits for the process to be ready
# cp calypso-init.enrico /etc/init.d/calypso
# update-rc.d calypso defaults

# su - calypso

$ mkdir .config/calypso/certs
$ mv cal-key.pem .config/calypso/certs/cal.key
$ mv cal-cert.pem .config/calypso/certs/cal.pem
$ chmod 0600 .config/calypso/certs/*
$ cat > .config/calypso/config << EOF
[server]
certificate=/home/calypso/.config/calypso/certs/cal.pem
key=/home/calypso/.config/calypso/certs/cal.key
[acl]
type=htpasswd
encryption=sha1
filename=/home/calypso/.config/calypso/htpasswd
    EOF

    $ htpasswd -s .config/calypso/htpasswd enrico

$ mkdir -p .config/calypso/calendars
$ cd .config/calypso/calendars
$ git init
    $ cat > .calypso-collection << EOF
[collection]
is-calendar = True
is-addressbook = False
displayname = Test
description = Test calendar
EOF
    $ git add .calypso-collection
$ git commit --allow-empty -m'initialize new calendar'

# /etc/init.d/calypso start

1. Add a new DAVdroid sync account
2. Use server/username configuration
3. For server, use https://:5233
4. Add username and password

• http://keithp.com/blogs/calypso/
• http://keithp.com/pipermail/calypso/2014-October/000052.html
• http://davdroid.bitfire.at/configuration#c122
• https://fsfe.org/campaigns/android/liberate.en.html
• http://radicale.org/

Server setup The first step is to install znc:

apt-get install znc

Make sure you get the 1.0 series (in jessie or trusty, not wheezy or precise) since it has much better multi-network support. Then, as a non-root user, generate a self-signed TLS certificate for it:

openssl req -x509 -sha256 -newkey rsa:2048 -keyout znc.pem -nodes -out znc.crt -days 365

and make sure you use something like irc.example.com as the subject name, that is the URL you will be connecting to from your IRC client. Then install the certificate in the right place:

mkdir ~/.znc
mv znc.pem ~/.znc/
cat znc.crt >> ~/.znc/znc.pem

Once that's done, you're ready to create a config file for znc using the znc --makeconf command, again as the same non-root user:

• create separate znc users if you have separate nicks on different networks
• use your nickserv password as the server password for each network
• enable ssl
• say no to the chansaver and nickserv plugins

Finally, open the IRC port (tcp port 6697 by default) in your firewall:

iptables -A INPUT -p tcp --dport 6697 -j ACCEPT

Client setup (irssi) On the client side, the official documentation covers a number of IRC clients, but the irssi page was quite sparse. Here's what I used for the two networks I connect to (irc.oftc.net and irc.mozilla.org):

servers = (
   
    address = "irc.example.com";
    chatnet = "OFTC";
    password = "fmarier/oftc:Passw0rd1!";
    port = "6697";
    use_ssl = "yes";
    ssl_verify = "yes";
    ssl_cafile = "~/.irssi/certs/znc.crt";
   ,
   
    address = "irc.example.com";
    chatnet = "Mozilla";
    password = "francois/mozilla:Passw0rd1!";
    port = "6697";
    use_ssl = "yes";
    ssl_verify = "yes";
    ssl_cafile = "~/.irssi/certs/znc.crt";
   
);

Of course, you'll need to copy your znc.crt file from the server into ~/.irssi/certs/znc.crt. Make sure that you're no longer authenticating with the nickserv from within irssi. That's znc's job now.

Wrapper scripts So far, this is a pretty standard znc+irssi setup. What makes it work with my workflow is the wrapper script I wrote to enable znc before starting irssi and then prompt to turn it off after exiting:

#!/bin/bash
ssh irc.example.com "pgrep znc   znc"
irssi
read -p "Terminate the bouncer? [y/N] " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]
then
  ssh irc.example.com killall -sSIGINT znc
fi

Now, instead of typing irssi to start my IRC client, I use irc. If I'm exiting irssi before commuting or because I need to reboot for a kernel update, I keep the bouncer running. At the end of the day, I say yes to killing the bouncer. That way, I don't have a backlog to go through when I wake up the next day.

#!/usr/bin/python3
import http.server
import cgi
import socketserver
import hashlib
import json
PORT = 8081
class Handler(http.server.SimpleHTTPRequestHandler):
    def do_POST(self):
        info =  
            "method": "POST",
            "headers":   k: v for k, v in self.headers.items()  ,
         
        # From https://snipt.net/raw/f8ef141069c3e7ac7e0134c6b58c25bf/?nice
        form = cgi.FieldStorage(
            fp=self.rfile,
            headers=self.headers,
            environ= 'REQUEST_METHOD':'POST',
                     'CONTENT_TYPE':self.headers['Content-Type'],
                      )
        postdata =  
        for k in form.keys():
            if form[k].file:
                buf = form.getvalue(k)
                postdata[k] =  
                    "type": "file",
                    "name": form[k].filename,
                    "size": len(buf),
                    # json.dumps will not serialize a byte() object, so we
                    # return the shasum instead of the file body
                    "sha256": hashlib.sha256(buf).hexdigest(),
                 
            else:
                vals = form.getlist(k)
                if len(vals) == 1:
                    postdata[k] =  
                        "type": "field",
                        "val": vals[0],
                     
                else:
                    postdata[k] =  
                        "type": "multifield",
                        "vals": vals,
                     
        info["postdata"] = postdata
        resbody = json.dumps(info, indent=1)
        print(resbody)
        resbody = resbody.encode("utf-8")
        self.send_response(200)
        self.send_header("Content-type", "application/json")
        self.send_header("Content-Length", str(len(resbody)))
        self.end_headers()
        self.wfile.write(resbody)
class TCPServer(socketserver.TCPServer):
    # Allow to restart the mock server without needing to wait for the socket
    # to end TIME_WAIT: we only listen locally, and we may restart often in
    # some workflows
    allow_reuse_address = True
httpd = TCPServer(("", PORT), Handler)
print("serving at port", PORT)
httpd.serve_forever()

Missing: you can just hit Alt-F2 and enter the command

	in-target apt-get --purge -y install sysvinit-core
 

there, no need to preseed. But this does not eliminate the aforementioned shortcomings, of course.

Noticing a regression and reporting a bug There is a regression with Emacs 24.4 relative to 24.3, which I discovered after Emacs 24.4 became available in Debian's sid. The regression in particular is that Emacs 24.4 doesn't seem to respect my Xresources, while 24.3 does (and this is 100% reproducible: I kept the binary packages of version 24.3 of emacs24 and I can install and reinstall things). When I reported this to upstream, I received a reply that it worked fine with another person that was using XFCE with unstable.

Testing various Desktop environments As I am using the MATE desktop environment, I proceeded to test this assertion by installing XFCE. Emacs 24.4 read my Xresources. I went ahead and installed LXDE. It worked again. I tried once more with GNOME 3, but "regular" GNOME 3 just crashed. I tried with GNOME 3 Classic and Emacs 24.4 just worked again.

Going deep into the rabbit's hole Then, I got more curious and I tried to see why things worked the way that they did and given that there was a mirror of the Emacs repo on github, I cloned it and started to git bisect to find the first problematic commit (I have no idea if bzr even offers something like git's bisect and I wouldn't really know how to do it as quickly as I do with git). To cut short a long story, after many recompiles, many wasted hours, a lot of wasted electrical energy, I found a bad commit and reported it. I received no response after that.

The new repo enters in action Of course, all my hard work bisecting things was completely invalidated after the transition to the new repository went live. To make things relevant again, I used the awesome powers of git, restricting the changes of the newly cloned repository to the e-mail of the committer in question (Chong Yidong) and, from there, I proceeded to another painful process of git bisects. And, sure enough, the first bad commit was the same one that I found with the previous tree. Semi-blindly reverting this commit, and also semi-blindly resolving the conflicts make Emacs's from master work again on my system, but I highly suspect that (given the way that I did it), it would not really be appropriate for upstream. But given also that I failed to receive feedback after my original report, I am not too confident that this bug can be solved soon (even if it doesn't qualify for being fixed in Debian 8). After all this, I don't really know what else to do. I even filed a bug report (more like a request for help) to the Debian MATE maintainers. As a side note, I would have filed a bug to upstream MATE, but it is not really clear what the proper procedure to report bugs to them is---they seem to use github's issues system, but given that they have separate repositories for each component of the project, and that I don't know precisely what repository to report to (or even if it applies to MATE after all), I am more or less paralyzed.

A side note I must say that the conversion was well done by Eric Raymond, because the whole .git repository of the new repo is only about 200MB, with history going back to 1985, while the other repository had about 800GB.

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1

preseed/late_command="in-target apt-get install --purge -y sysvinit-core"

d-i preseed/late_command string in-target apt-get install -y sysvinit-core