Qt4 has been deprecated since Qt5's first release on December 19th 2012, that means almost two years ago!
So far we had bugfixes-only releases, but upstream has announced that they will end this support on august 2015. This already means we will have to do a special effort from that point on for Jessie in case RC bugs appears, so having it in Jessie+1 is simply a non-go.
Some of us where involved in various Qt4 to Qt5 migrations  and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.
We also understand that there is still a lot of software still using Qt4. In order to easy the transition time we have provided Wheezy backports for Qt5.
Don't forget to take a look at the C++ API change page  whenever you start porting your application.
[maintainer warning] **Remember the freeze** and do not upload packages ported to Qt5 to unstable. The best thing you can do now is to ask your upstream if the code can be compiled against Qt5 and, why not, try it yourself.
Our first priority now is to release Jessie, and this is why this is an early announce.
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it’s one of the best ways to find volunteers to work with me on projects that matter to me.Packaging work
With the Jessie freeze approaching, I took care of packaging some new upstream releases that I wanted to get in. I started with zim 0.62, I had skipped 0.61 due to some annoying regressions. Since I had two bugs to forward, I took the opportunity to reach out to the upstream author to see if he had some important fixes to get into Jessie. This resulted in me pushing another update with 3 commits cherry picked from the upstream VCS. I also sponsored a wheezy-backports of the new version.
I pushed two new bugfixes releases of Publican (4.2.3 and 4.2.6) but I had to include a work-around for a bug that I reported earlier on docbook-xml (#763598: the XML catalog doesn’t allow libxml2/xmllint to identify the local copy of some entities files) and that is unlikely to be fixed in time for Jessie.
Last but not least, I pushed the first point release of Django 1.7, aka version 1.7.1 to unstable and asked release managers to ensure it migrates to testing before the real freeze. This is important because the closer we are to upstream, the easier it is to apply security patches during the lifetime of Jessie (which will hopefully be 5 years, thanks to Debian LTS!). I also released a backport of python-django 1.7 to wheezy-backports.
I sponsored galette 0.7.8+dfsg-1 fixing an RC bug so that it can get back to testing (it got removed from testing due to the bug).Debian LTS
See my dedicated report for the paid work I did on that area. Apart from that, I took some time to get in touch with all the Debian consultants and see if they knew some companies to reach out. There are a few new sponsors in the pipe thanks to this, but given the large set of people that it represents, I was expecting more. I used this opportunity to report all bogus entries (i.e bouncing email, broken URL) to the maintainer of the said webpage.Distro Tracker
Only 30 commits this month, with almost no external contribution, I’m a bit saddened by this situation because it’s not very difficult to contribute to this project and we have plenty of easy bugs to get you started.
That said I’m still happy with the work done. Most of the changes have been made for Kali but will be useful for all derivatives: it’s now possible to add external repositories in the tracker and not display them in the list of available versions, and not generate automatic news about those repositories. There’s a new “derivative” application which is only in its infancy but can already provide a useful comparison of a derivative with its parent. See it in action on the Kali Package Tracker: http://pkg.kali.org/derivative/ Thanks to Offensive Security which is sponsoring this work!
Since I have pushed Django 1.7 to wheezy-backports, all distro tracker instances that I manage are now running that version of Django and I opted to make that version mandatory. This made it possible to add initial Django migrations and rely on this new feature for future database schema upgrade (I have voluntarily avoided schema change up to now to avoid problems migrating from South to Django migrations).Thanks
See you next month for a new summary of my activities.
This is a feedback about installing a self hosted instance of Friendica on a Debian server (Jessie). If you’re not interested in why I use Friendica, just go to « Prerequisite for Friendica » section below.
Frustration about social networks
Being a hugh user of short messages, I was quite frustated to spend so much time on my Twitter account. To be quite honest, there is no much I like about this social network, except the hugh population of people being potentially interested in what I write.
I also have been using Identi.ca (now powered by Pump.io) for a while. But I tried for a while to manage both networks Pump.io and Twitter by hand and it was quite painful. And something was telling me another social network was going to appear from nowhere one of these days and I’ll be just horrible to try to keep it up this way.
Hmmm, what’s Friendica ?
Friendica is a content manager you can plug on almost anything: social networks (Facebook, Twitter, Pump.io, Diaspora*,…), but also WordPress, XMPP, emails… I’m in fact just discovering the power of this tool but to plug it on my different social network accounts was quite a good use case for me. And I guess if you’re still reading, for you too.
I tried to use some shared public servers but I was not quite happy with the result, one connector was still missing or public servers were really unstable. So I’m at last self hosting my Friendica. Here is how.
Prerequisite for Friendica
You need to install the following packages:
# apt-get install apache2 libapache2-mod-php5 php5 php5-curl php5-gd php5-mysql mysql-server git
Having a already self-modified /etc/php5/apache2/php.ini, I encountered a small issue with libCurl and had to manually add the following line in the php.ini:
Setting up MySQL
Connect to MySQL and create an empty database with a dedicated user:
# mysql -u root -pV3rYS3cr3t -e « create database friendica; GRANT ALL PRIVILEGES ON friendica.* TO friendica@localhost IDENTIFIED BY ‘R3AlLyH4rdT0Gu3ss' »
Setting up Apache
My server hosts several services, so I use a subdomain friendica.mydomain.com. If you use a subdomain, of course check you do have declared this subdomain in your DNS zone.
I use SSL encryption with a wildcard certificate for all my subdomains. My Friendica data are stored in /var/www/friendica. Here is my virtual host configuration for Friendica stored in the file /etc/apache2/sites-available/friendicassl.conf :
DirectoryIndex index.php index.html
Allow from all
After writing the configuration file, just launch the following commands and it should be good for the Apache configuration:
# a2ensite friendicassl && /etc/init.d/apache2 reload
Setting up Friendica
Get the master zip file of Friendica, copy it on your server and decompress it. Something like :
# cd /var/www/ && wget https://github.com/friendica/friendica/archive/master.zip && unzip master.zip && mv friendica-master friendica
You need to give www-data (Apache user) the rights to write in /var/www/friendica/view/smarty3/ :
# chown -R www-data:www-data /var/www/friendica/view/smarty3 && chmod -R ug+w var/www/friendica/view/smarty3
Ok, I guess we’re all set, lets launch the installation process! Using your web browser, connect to friendica.mydomain.com. First step you’ll see the installation window which checks the prerequisite before installing. Complete if something is missing.
Second step asks the host/user/password of the database, complete and the installation process starts. Hopefully all goes just fine.
Next you’ll have to create a /var/www/friendica/.htconfig.php with the content that the last page of the installation process provides. Just copy/paste, check the rights of this file and now you can connect again to see the register page of friendica at the url https://friendlica.mydomain.com/register . Pretty cool!
Register a user
That’s a fairly easy step. You just need to check before that your server is able to send emails, because the password is going to be sent to you by email. If it is ok, you should now identify on the welcome page of friendica and access your account. That’s a hugh step to broadcast your short messages everywhere, but we have some last steps before being able to send your short messages on all the social networks we need.
A smal break, create an app for twitter on apps.twitter.com
To send your short messages to Twitter, you need to create an app on apps.twitter.com. Just check you’re logged in Twitter and connect to apps.twitter.com. Create an app called with a unique name (apparently), then go to the Keys and Access tokens page, note the consumer key and the consumer secret. You’ll later need the name of the app, the consumer key and the consumer secret.
Install and configure the addons
Friendica uses an addon system in order to plug on the different third-parties it needs. We are going to configure Twitter, Pump.io and the Diaspora* plug. Let’s go back to our server and launches some commands:
# cd /tmp && git clone https://github.com/friendica/friendica-addons.git && cd friendica-addons
# tar xvf twitter.tgz -C /var/www/friendica/addon
# tar xvf pumpio.tgz -C /var/www/friendica/addon
# cp -a diaspora /var/www/friendica/addon
You need to modify your /var/www/friendica/.htconfig.php file and add the following content at the end:
// names of your addons, separated by a comma
$a->config['system']['addon'] = ‘pumpio, twitter, diaspora';
// your Twitter consumer key
$a->config['twitter']['consumerkey'] = ‘P4Jl2Pe4j7Lj91eIn0AR8vIl2′;
// your Twitter consumer secret
$a->config['twitter']['consumersecret'] = ‘1DnVkllPik9Ua8jW4fncxwtXZJbs9iFfI5epFzmeI8VxM9pqP1′;
// you Twitter app name
$a->config['twitter']['application_name'] = « whatever-twitter »;
Connect again to Friendica. Go to settings => social networks, you will see the options for Twitter, Pump.io and Diaspora*. Complete the requested information for each of them. Important options you should not forget to check are:
- Enable pump.io Post Plugin
- Post to pump.io by default
- Should posts be public?
- Authorize publication on Twitter
- Post to Twitter by default
- Post to Diaspora by default
Done? Now it’s time to send your first broadcasted short message. Yay!
Send a short message to your different social networks
It means your short messages will be broadcasted to the three networks. Or more, it’s up to you! That’s my setup, feel free to modify. Now close the lock window and send your message. For me it takes some time to appear on Twitter and Diaspora* and it immediatly appears on Identi.ca.
Friendica offers to take back the control of your data, by broadcasting content on different media from a single source. While self hosting, you keep your data whatever happends and are not subject to companies losing your data like recently Twitpic. Moreover the philosophy behind Friendica pushed me to dig and test the solution
What about you? How do you proceed to broadcast your short messages? Does Friendica offer a good solution in your opinion? Are you interested in the philosophy behind this project? Feel free to share your thoughs in the comments.
Git has support for checking whitespace in patches. git apply and git am have the option --whitespace, which can be used to warn or error about whitespace errors in the patches about to be applied. git diff has the option --check to check a change for whitespace errors.
But all this assumes that your existing code is cool, and only new changes are candidates for problems. Curiously, it is a bit hard to use those same tools for going back and checking whether an existing tree satisfies the whitespace rules applied to new patches.
The core of the whitespace checking is in git diff-tree. With the --check option, you can check the whitespace in the diff between two objects.
But how do you check the whitespace of a tree rather than a diff? Basically, you want
git diff-tree --check EMPTY HEAD
except there is no EMPTY. But you can compute the hash of an empty Git tree:
git hash-object -t tree /dev/null
So the full command is
git diff-tree --check $(git hash-object -t tree /dev/null) HEAD
If have this as an alias in my ~/.gitconfig:
[alias] check-whitespace = !git diff-tree --check $(git hash-object -t tree /dev/null) HEAD
can be as easy as running make or git commit.