Although some companies have embraced the world of free software with open arms, there are many who haven't. NVIDIA is one name that comes to mind. Its reputation in the Linux world is far from stellar, but maybe its recent actions will help mend some bridges. more>>
ConFoo, a community conference, one of the most important events for developers. It covers a multitude of programming languages, including Python. There are a total of 155 presentations. Two of them are amazing keynotes about cloud-connected robots and machine ethics. In addition, the innovation night will showcase local entrepreneurs who built fascinating technologies.
ConFoo 2016 will be held on February 24-26 in Montreal. Tickets are currently sold at a discount. There are also many socials that are free and open to the public: https://confoo.ca/en/2016/activities
Here is a preview of what the Python track holds: https://confoo.ca/en/2016/t/python.
In march, we are getting back to our root and visiting our friends of UQAM. For the occasion, It's an opportunity to come present cause we are looking for speakers for talks of 30, 15 or 5 minutes.
For example, if you are using Python to deploy Docker services, doing Big Data or simply having fun at discovering new tricks that make your life easier, we want you on stage :)
We are also looking for people interested for presenting at module of the month or a module that you love !
To submit your talk, write us at firstname.lastname@example.orgWhere
UQAM, more informations coming soonWhen
Monday, March 14th 2016Schedule
- 6:00pm — Doors open
- 6:30pm — Presentations start
- 7:30pm — Break
- 7:45pm — Second round of presentations
- 9:00pm — End of the meeting, have a drink with us
- Savoir-faire Linux
The Raspberry Pi Foundation continues to push the limits of single-board computing. This month, it has added experimental OpenGL support to its Raspbian OS. more>>
For many of us, our introduction to computing is being placed in front of a machine where the only challenge is figuring out the Windows user experience paradigm. Getting started with Linux, on the other hand, requires a bit more effort, a fair amount of trial and error, and perhaps some colorful language along the way. more>>
Recently, I wrote about how Docker is investing in Unikernels to reduce the size of its containers, but there is more than one way to skin a cat. Unikernels are a hot new technology, but many developers prefer stability and maturity over "new and shiny". And, that's where Alpine Linux comes in. more>>
This is my third month working on Debian LTS, started by Raphael Hertzog at Freexian. This month was my first month working on the frontdesk duty and did a good bunch of triage. I also performed one upload and reviewed a few security issues.Frontdesk duties
I spent some time trying to get familiar with the frontdesk duty. I still need to document a bit of what I learned, which did involve asking around for parts of the process. The following issues were triaged:
- roundcube in squeeze was happily not vulnerable to CVE-2015-8794 and CVE-2015-8793, as the code affected was not present. roundcube is also not shipped with jessie but the backport is vulnerable
- the php-openid vulnerability was actually just a code sample, a bug report comment clarified all of CVE-2016-2049
- ffmpeg issues were closed, as it is not supported in squeeze
- libxml2 was marked as needing work (CVE-2016-2073)
- asterisk was triaged for all distros before i found out it is also unsupported in squeeze (CVEs coming up, AST-2016-001, AST-2016-001, AST-2016-001)
- libebml and libmatroska were marked as unsupported, although an upload of debian-security-support will be necessary to complete that work (bug #814557 filed)
I only ended up doing one upload, of the chrony package (CVE-2016-1567), thanks to the maintainer which provided the patch.
I tried my best trying to sort through the issues with tiff (CVE-2015-8668 and CVE-2015-7554), which didn't have obvious fixes available. OpenSUSE seem to have patches, but it is really hard to find them through their issue trackers, which were timing out on me. Hopefully someone else can pick that one up.
I also tried and failed to reproduce the cpio issue (CVE-2016-2037), which, at the time, didn't have a patch for a fix. This ended up being solved and Santiago took up the upload.
I finally spent some time trying to untangle the mess that is libraw, or more precisely, all the packages that embed dcraw code instead of linking against libraw. Now I really feel even more strongly for the Debian policy section 4.13 which states that Debian packages should not ship with copies of other packages code. It made it really hard to figure out which packages were vulnerable, especially because it was hard to figure out which versions of libraw/dcraw were actually vulnerable to the bug, but also just plain figure out which packages were copying code from libraw. I wish I had found out about secure-testing/data/embedded-code-copies earlier... Still, it was interesting to get familiar with codesearch.debian.net to try to find copies of the vulnerable code, which was not working so well. Kudos to darktable 2.0 for getting rid of their embedded copy of libraw, by the way - it made it completely not vulnerable to the issue, the versions in stretch and sid not having the code at all and older versions having non-vulnerable copies of the code.Issues with VMs again
I still had problems running a squeeze VM - not wanting to use virtualbox because of the overhead, I got lost for a bit trying to use libvirt and KVM. A bunch of issues crept up: using virt-manager would just fail on startup with an error saying interface mtu value is improper, which is a very unhelpful error message (what is a proper value??) - and, for the record, the MTU on eth0 and wlan0 is the fairly standard 1500, while lo is at 65536 bytes, nothing unusual there as far as I know.
Then the next problem was actually running a VM - I still somewhat expected to be able to boot off a chroot, something I should definitely forget about it seems like (boot loader missing? not sure). I ended up calling virt-install with the live ISO image I was previously using:virt-install --virt-type kvm --name squeeze-amd64 --memory 512 --cdrom ~/iso/Debian/cdimage.debian.org_mirror_cdimage_archive_6.0.10_live_amd64_iso_hybrid_debian_live_6.0.10_amd64_gnome_desktop.iso --disk size=4 --os-variant debiansqueeze
At least now I have an installed squeeze VM, something I didn't get to do in Virtualbox (mostly because I didn't want to wait through the install, because it was so slow).
Finally, I still have trouble getting a commandline console on the VM: somehow, running virtsh console squeeze-amd64 doesn't give me a login terminal, and worse, it actually freezes the terminal that I can actually get on virt-viewer squeeze-amd64, which definitely sounds like a bug.
I documented a bit more of that setup in the Debian wiki KVM page so hopefully this will be useful for others.Other free software work
I continued my work on improving timetracking with ledger in my ledger-timetracking git repository, which now got a place on the new plaintextaccounting.org website, which acts as a portal for ledger-like software projects and documentation.Darktable 2.0
I had the pleasure of trying the new Darktable 2.0 release, which only recently entered Debian. I built a backport for jessie, which works beautifully: much faster thumbnail rendering, no dropping of history when switching views... The new features are great, but I also appreciate how they are being very conservative in their approach.
Darktable is great software: I may have trouble approaching the results other are having with lightroom and snapseed, but those are proprietary software that I can't use anyways. I also suspect that I just don't have enough of a clue of what I'm doing to get the results I need in Darktable. Maybe with hand-holding, one day, I will surpass the results I get with the JPEGs from my Canon camera. Until then, I turned off RAW exports in my camera to try and control the explosion of disk use I saw since I got that camera:41M 2004 363M 2005 937M 2006 2,2G 2007 894M 2008 800M 2009 1,8G 2010 1,4G 2011 9,8G 2012 31G 2013 26G 2014 9,8G 2015
The drop in 2015 is mostly due to me taking less pictures in the last year, for some reason...Markdown mode hacks
I ended up writing some elisp for the markdown mode. It seems I am always writing links like [text](link) which seems more natural at first, but then the formatting looks messier, as paragraph wrapping is all off because of the long URLs. So I always ended up converting those links, which was a painful series of keystrokes.
So I made a macro, and while I'm a it, why not rewrite it as a lisp function. Twice.
Then I was told by the markdown-mode.el developers that they had already fixed that (in the 2.1 version, not in Debian jessie) and that the C-c C-a r key binding actually recognized existing links and conveniently converted them.
I documented my adventures in bug #94, but it seems I wrote this code for nothing else than re-learning Emacs lisp, which was actually quite fun.More emacs hacking
Another thing I always wasted time doing by and is "rename file and buffer". Often, you visit a file but it's named wrong. My most common case is a .txt file that i rename to .mdwn.
I would then have to do:M-x rename-file <ret> newfile M-x rename-buffer <ret> newfile C-x C-s <ret> newfile
Turns out that set-visited-file-name actually does most of the job, but doesn't actually rename the file, which is really silly. So I wrote this small function instead:(defun rename-file-and-buffer (newfname) "combine rename-file and rename-buffer set-visited-file-name does most of the job, but unfortunately doesn't actually rename the file. rename-file does that, but doesn't rename the buffer. rename-buffer only renames the buffer, which is pretty pointless. only operates on current buffer because set-visited-file-name also does so and we don't bother doing excursions around. " (interactive "GRename file and bufer: ") (let ((oldfname (buffer-file-name))) (set-visited-file-name newfname nil t) (rename-file oldfname newfname) ) )
Not bound to any key, really trivial, but doing this without that function is really non-trivial, especially since set-visited-file-name needs special arguments to not mark the file as modified.IRC packages updates
I updated the Sopel IRC bot package to the latest release, 6.3.0. They have finally switched to Requests, but apart from that, no change was necessary. I am glad to finally see SNI support working everywhere in the bot!
I also update the Charydbis IRC server package to the latest 3.5.0 stable release. This release is great news, as I was able to remove 5 of the 7 patches I was dragging along the Debian package. The previous Charybdis stable release was over 3 years old, as 3.4.2 was released in (December) 2012!
I spend a good chunk of time making the package reproducible. I filed a bug upstream and eventually made a patch to make it possible to hardcode a build timestamp, which seems to have been the only detectable change in the reproducible build infrastructure. Charybdis had been FTBS for a while in sid now, and the upload should fix that as well. Unfortunately, Charybdis still doesn't build with hardening flags - but hopefully a future update of the package should fix that. It is probably because CFLAGS are not passed around properly.
There's really interesting stuff going on in the IRC world. Even though IRC is one of the oldest protocols still in operation (1988, even before the Web, but after SMTP and the even more venerable FTP), it is still being actively developed, with a working group drafting multiple extensions to the IRCv3 protocol defined in RFC 1459.
For example, IRCv3.3 includes a Strict Transport Security extension, which tries to ensure users use encrypted channels as much as possible, through warnings and STARTTLS support. Charybdis goes even further by proposing a reversal of the +S ("secure channel" flag) where all channels are secure by default, and you need to deliberately mark a channel as insecure with the +U flag if you actually want to allow users on an clear-text connection to join the channel. A transition mechanism is also proposed.Miscellaneous bug reports
I forwarded a bug report, originally filed against monkeysign, to the pyqrencode maintainers.
I filed a usability bug against tails-installer, which just entered Debian, mostly usability issues.
I discovered the fim image viewer, which re-entered Debian recently. It seemed perfect to adjust my photos-import workflow, so I added it to my script, to be able to review photos prior to importing them into Darktable and git-annex.
I recently had a problem trying to install the NVIDIA driver for my machine. It seemed the latest driver had stopped supporting my graphics card, and after updating my kernel, I was out of a driver. The question, obviously, was "which card did I have?" But, I didn't remember. more>>
I love video game emulation. My favorite games were produced in the 1980s and 1990s, so if I want to play them, I almost always have to emulate the old systems. There is usually a legal concern about ROM files for games, even if you own the original cartridges, so I'm not going to tell you where to find ROMs to download or anything like that. more>>
The ever-popular VLC turned 15 a few days ago--that's 15 years since the project was GPLed and released to the world. If we were pedants, we might point out that the project actually came into existence in 1996, but that was a different lifetime. more>>
Docker's recent acquisition of Unikernel Systems has sent pulses racing in the microservice world. At the same time, many people have no clue what to make of it, so here's a quick explanation of why this move is a good thing. more>>
I'm apparently in a silly-game mood this month, because I stumbled across an open-source project I couldn't keep all to myself: Snk. If you remember the classic game of snake, Snk is the same concept, but smaller, harder and with music. more>>
The OOM killer is a tough nut to crack. How can a system recover when it's violently thrashing and out of RAM? Once upon a time, you'd just have to reboot. And today, that still might be necessary, but less so, because the OOM killer attempts to identify and stop the process that seems to be causing the hangup. The problem is, it may not choose the right process every time. more>>
This article is the third part of a four-part series that examines some of the changes in 3D printing that have occurred in the past three years since my first articles on the subject. Because this is Linux Journal, instead of discussing the entire 3D printing world, I'm focusing on the sections of the topic most relevant to open source and open hardware. more>>
My friend and fellow Linux Journalian Kris Occhipinti recently posted a reminder on Facebook for everyone to back up regularly in 2016. Although it's something we already should be doing, if you're not a regular backer-upper, you should start today! more>>
I love my job. I teach Linux by day and write about Linux at night. It's easy to fall in love with your work when the things you do align with your passions. more>>
Ladies and Gentlemen, we at Montreal Python are super excited for 2016 and we have come up with some great ideas.
In order to turn these ideas into reality, we will need some help. Montreal Python is an open community and collaboration is key to our success. So we are inviting beginners, experts and newcomers to join us at our next organization meeting on Monday February 8th.
Here we will discuss topics about:
- Annual event / conference
- Hackathons / Project nights
- The future of Montreal Python / elections
Montreal has a pretty exciting Python scene, and thanks to the community that is something we'll maintain for years to come. It is now your chance to come and make things happening.When
Monday February 8th at 6pmWhere
Shopify Offices 490 rue de la Gauchetière west https://goo.gl/maps/MJrA2RN8e912Who
Anyone who want to help or is curious about the Python Community in Montreal
For those that can't attend, don't worry, send us a email with your ideas at email@example.com.
This is my second month working on Debian LTS, started by Raphael Hertzog at Freexian. I think this month has been a little better for me, as I was able to push two "DLA" (Debian LTS Advisories, similar to regular DSAs (Debian Security Advisories) but only applying to LTS releases).phpMyAdmin and Prosody
I pushed DLAs for phpmyadmin (DLA-406-1) and [prosody (CVE-2016-0756)]. Both were pretty trivial, but I still had to boot a squeeze VM to test the resulting packages, something that was harder than expected. Still the packages were accepted in squeeze-lts and should work fine.icu and JDK vulnerabilities
I also spent a good amount of time trying to untangle the mess that java software has become, and in particular the icu vulnerabilities, CVE-2015-4844 and CVE-2016-0494. I ended up being able to backport patches and build packages, not without a significant amount of pain because of how upstream failed to clearly identify which patches did what.
The fact that they (Oracle) did not notify their own upstream (icu) is also a really questionable practice in the free software world, which doesn't come as a surprise coming from Oracle anymore, unfortunately. Even worse, CVE-2016-0494 was actually introduced as part of the fix for CVE-2015-4844. I am not even sure the patches provided actually fix the problem because of course Oracle didn't clearly state what the problem was or how to exploit it.
Still: I did the best I could under the circumstances and built packages which I shared with the debian-lts list in the hope others could test it. I am not much familiar with the icu package or even Java anymore, so I do not feel comfortable uploading those fixes directly right now, especially since I just trust whatever was said on the Redhat and icu bugtrackers. Hopefully someone else can pick this up and confirm I had the right approach.OpenSSH vulnerabilities
I also worked on CVE-2016-1908 a fairly awkward vulnerability in OpenSSH involving bypassing a security check in the X server that forbids certain clients from looking at keystrokes, selections and more stuff from other clients. The problem is pretty well described in this article. It is, basically, that there are two ways for applications to talk to the X server: "trusted" and "untrusted". If an application is "trusted", they can do all sorts of stuff like manipulate the clipboard, send keystrokes to other applications, sniff keystrokes and so on. This seems fine if you are running local apps (a good example is xdotool to test this) but can be pretty bad once X forwarding comes in play in SSH because then the remote server can use your X credentials to run arbitrary X code in your local X server. In other words, once you forward X, you trust the remote server as being local, more or less.
This is why OpenSSH 3.8 introduced the distinction between -X (untrusted) and -Y (trusted). Unfortunately, after quite a bit of research and work to reproduce the issue (i could not not reproduce the issue!), I realized that Debian has, even since 3.8 has been released (around the "sarge" days!) forcibly defaulted ForwardX11Trusted to yes which makes -X and -Y behave the same way. I described all of this in a post to the LTS list and OpenSSH maintainers and it seems there were good reasons for this back then (-X actually breaks a lot of X clients, for example selecting text will crash xterm), but I still don't quite see why we shouldn't tell people to use -Y consciously if they need to, instead of defaulting to the nasty insecure behavior.
Anyways, this will probably end up being swept under the rug for usability reasons, but just keep in mind that -X can be pretty nasty if you run it against an untrusted server.Xscreensaver vulnerability
This one was fun. JWZ finally got bitten by his own rants and a pretty embarrassing vulnerability (CVE-2015-8025) that allowed one to crash the login dialog (and unlock the screen) by hot swapping external monitors (!). I worked on trying to reproduce the issue (I couldn't: my HDMI connector stopped working on my laptop, presumably because of a Linux kernel backport) and building the patches provided by the maintainer on wheezy, and pushed debdiffs to the security team which proceeded with the upload.Other LTS work
I still spend a bit too much time to my taste trying to find work in LTS land. Very often, all the issues are assigned or the ones that remain seem impossible to fix (like the icu vulnerabilities) or packages so big that I am scared to work on it (like eglibc). Still, the last week of work was much better, thanks to the excellent work that Guido Günther has done on the front desk duties this week. My turn is coming up next week and I hope I can do the same for my fellow LTS workers.
Oh, and I tried to reproduce the cpio issue (CVE-2016-2037) and failed, because I didn't know enough about Valgrind. But even then, I don't exactly know where to start to fix that issue. It seems no one does, because this unmaintained package is still not fixed anywhere...systemd-nspawn adventures
In testing the OpenSSH, phpMyAdmin and prosody issues, I had high hopes that systemd-nspawn would enable me to run an isolated squeeze container reliably. But I had trouble: for some reason, squeeze does not seem to like nspawn at all. First off, it completely refuses to boot it because it doesn't recognize it as an "OS root directory", which, apparently, need the os-release file (in /etc, but it doesn't say that because it would be too easy):$ sudo systemd-nspawn -b -D /var/cache/pbuilder/squeeze-amd64-vm Directory /home/pbuilder/squeeze-amd64-vm doesn't look like an OS root directory (os-release file is missing). Refusing.
I just created that as an empty file (it works: i also tried copying it from a Jessie system and "faking" the data in it, but it's not necessary), and then nspawn accepts booting it. The next problem is that it just hangs there: it seems that the getty programs can't talk to the nspawn console:$ sudo systemd-nspawn -b -D /var/cache/pbuilder/squeeze-amd64-vm Spawning container squeeze-amd64-vm on /home/pbuilder/squeeze-amd64-vm. Press ^] three times within 1s to kill container. /etc/localtime is not a symlink, not updating container timezone. INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Setting the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Unable to set System Clock to: Sun Jan 31 15:57:31 UTC 2016 ... (warning). Activating swap...done. Setting the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Unable to set System Clock to: Sun Jan 31 15:57:31 UTC 2016 ... (warning). Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Cleaning up temporary files.... INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. INIT: Id "2" respawning too fast: disabled for 5 minutes INIT: Id "1" respawning too fast: disabled for 5 minutes INIT: Id "3" respawning too fast: disabled for 5 minutes INIT: Id "4" respawning too fast: disabled for 5 minutes INIT: Id "5" respawning too fast: disabled for 5 minutes INIT: Id "6" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel
Note that before the INIT messages show up, quite a bit of time passes, around a minute or two. And then the container is just stuck there: no login prompt, no nothing. Turning off the VM is also difficult:$ sudo machinectl list MACHINE CONTAINER SERVICE squeeze-amd64-vm container nspawn 1 machines listed. $ sudo machinectl status squeeze-amd64-vm squeeze-amd64-vm Since: dim 2016-01-31 10:57:31 EST; 4min 44s ago Leader: 3983 (init) Service: nspawn; class container Root: /home/pbuilder/squeeze-amd64-vm Address: fe80::ee55:f9ff:fec5:f255 2001:1928:1:9:ee55:f9ff:fec5:f255 fe80::ea9a:8fff:fe6e:f60 2001:1928:1:9:ea9a:8fff:fe6e:f60 192.168.0.166 Unit: machine-squeeze\x2damd64\x2dvm.scope ├─3983 init  └─4204 lua /usr/bin/prosody $ sudo machinectl poweroff squeeze-amd64-vm # does nothing $ sudo machinectl terminate squeeze-amd64-vm # also does nothing $ sudo kill 3983 # does nothing $ sudo kill -9 3983 $
So only the latter kill -9 worked:Container squeeze-amd64-vm terminated by signal KILL.
Pretty annoying! So I ended up doing all my tests in a chroot, which involved shutting down the web server on my laptop (for phpmyadmin) and removing policy-rc.d to allow the services to start in the chroot. That worked, but I would prefer to run that code in a container. I'd be happy to hear how other maintainers are handling this kind of stuff.
For the OpenSSH vulnerability testing, I also wanted to have a X server running from squeeze, something which I found surprisingly hard. I was not able to figure out how to make [qemu] boot from a directory (the above chroot), so I turned to the Squeeze live images from the cdimage archive. Qemu, for some reason, was not able to boot those either: I would only get a grey screen. So I ended up installing Virtualbox, which worked perfectly, but I'd love to hear how I could handle this better as well.Other free software work
As usual, I did tons more stuff on the computer this month. Way more than I should, actually. I am trying to take some time to reflect upon my work and life these days, and the computer is more part of the problem than the solution, so those feel like a vice that I can't get rid of more than an accomplishment. Still, you might be interested to know about those, so here they are.Ledger timetracking
I am tracking the time I work on various issues through the overwhelming org-mode in Emacs. The rationale I had was that I didn't want to bother writing yet another time tracker, having written at least two before. One is the old phpTimeTracker, the other is a rewrite that never got anywhere, and finally, I had to deal with the formidable kProject during my time at Koumbit.org. All of those made me totally allergic to project trackers, timetrackers, and reinventing the wheel, so I figured it made sense to use an already existing solution.
Plus, org-mode allows me to track todos in a fairly meaningful way and I can punch into todo items fairly transparently. I also had a hunch I could bridge this with ledger, a lightweight accounting tool I started using recently. I was previously using the heavier Gnucash, almost a decade ago - but I really was seduced by the idea of a commandline tool that stores its data in a flat file that I can checkin to git.
How wrong I was! First off, ledger can't read org files out of the box. It's weird, but you need to convert those files into timeclock.el formatted files, which, oddly enough, is a completely different file format, and completely different timetracker. Interestingly, it's a very interesting format. An example:i 1970-01-01 12:00:00 project test 4h o 1970-01-01 16:00:00
... which makes it possible to write a timetracker with two simple shell aliases:export TIMELOG=$HOME/.timelog alias ti="echo i `date '+%Y-%m-%d %H:%M:%S'` \$* >>$TIMELOG" alias to="echo o `date '+%Y-%m-%d %H:%M:%S'` >>$TIMELOG"
How's that for simplicity!
So you use John Wiegley's org2tc (or my fork which adds a few improvements) to convert from org to timeclock.el. From there on, a bunch of tools can do reporting on those files, the most interesting being obviously ledger itself, as it can read those files natively (although hledger has trouble including them). So far so good: I can do time tracking very easily and report on my time now!
Now, to turn this into bills and actual accounting, well... it's really much more complicated. To make a long story short, it works, but I really had to pull my hair out and ended up making yet another git repository to demonstrate how that could work. I am now stuck at the actual step of generating bills more automatically, which seems to be a total pain. Previous examples and documentation I found were limited and while I feel that some people are actively doing this, they still have to reveal their magic sauce in a meaningful way. I was told on IRC no one actually achieved converting timeclock.el entries directly into bills...Kodi
I have done a small patch to the rom collection browser to turn off an annoying "OK" dialog that would block import of ROMs. This actually was way more involved than expected, considering the size of the patch: I had to export the project to Github since the original repository at Google Code is now archived, just like all Google Code repositories. I hope someone will pick it up from thereSopel
I have finally got my small patch for SNI support in Sopel! It turns out they are phasing out their own web module in favor of Requests, something that was refused last year. It seems the Sopel developers finally saw the interest in avoiding the maintenance cost of their own complete HTTP library... in an IRC bot.
Working on this patch, I filed a bug in requests which was promptly fixed.Feed2tweet and spigot
In the meantime, I figured it would make sense to also post to identi.ca. This turned out to be surprisingly more difficult - the only bridge available would not work very well for me. I also filed a bunch of issues in the hope things would stabilize, but so far I have not made this work properly.
It seems to me that all of this stuff is really just reinventing the wheel. There are pretty neat IM libraries out there, one that is actively developed is libturpial, used in the Turpial client. It currently only supports status.net and Twitter, but if Pump.io support is implemented, it would all of the above problems at once...Git-mediawiki
Did I mention how awesome the git-mediawiki remote is? It allows me to clone Mediawiki wikis and transparently read and write to them using usual git commands! I use it to keep a mirror of the amateur radio wiki site, for example, as it makes no sense to me to not have this site available offline. I was trying to mirror Wikivoyage and it would block at 500 pages, so I made a patch to support larger wikis.Borg resignation
Finally, it is with great sadness that I announce that I have left the Borg backup project. It seems that my views of release and project management are irreconcilable with those of the maintainer of the Attic fork. Those looking for more details and explanations are welcome to look in the issue tracker for the various discussions regarding i18n, the support timeframe and compatibility policy, or to contact me personally.
Linux has seen more than its fair share of controversy through the years. And, that's not so surprising. For one thing, the operating system flies in the teeth of deeply entrenched multinational companies. The fact that it stands for users instead of vested interests has drawn more than a little ire as well. more>>