How to destroy a project
Yesterday there have been many mails on the debian-live mailing list. A few people entered a bug that announced a new piece of software called 'live-build-ng'. The author of 'live-build', Daniel, complained about the name, because it is very close to the name of his package. Then the people behind the new package explained that 'live-build-ng' will replace 'live-build' in the near future, as the name already suggests. This disappointed Daniel so much, that he announced the end of the 'live-build' project. You can find his full post on the mailing list (or in his temporary blog).
I would like to say thank you to Daniel, who made a great job in inventing and developing 'live-build'! I feel very sad, that a few people attack a project leader who spent a huge amount of time to develop 'live-build' in such a way. They have no right to do that and there is no reason to choose a package name like 'live-build-ng' instead of attacking Daniel.
We will see what tool chain I will use for efaLive in the future. Maybe there will be a fork of the original 'live-build' project.
I wish all the best to Daniel. I hope you recover from this demotivating situation soon. Thank you!
efaLive 2.3 running on Raspberry Pi
Finally I found the time to try to run efaLive on a Raspberry Pi. It was less effort than expected. You just need a Raspbian installation that you upgrade from Wheezy to Jessie. This can be done by exchanging "wheezy" by "jessie" in the /etc/apt/sources.list. Then run "apt-get update" and "apt-get dist-upgrade". This will take a lot of time, but at the end you have a Debian Jessie based installation. Now add "deb http://efalive.hannay.de/debian jessie main" to /etc/apt/sources.list and run "apt-get updat"e and "apt-get install efalive" (ignore the missing GPG key for now). Many dependencies are installed now. At the end everything is ready to run efaLive. Just configure raspi-config to boot into the GUI and put the following lines into a file /home/efa/.xsessionrc:
Now you have to change the autologin user from "pi" to "efa" in /etc/lightdm/lightdm.conf. From now on, the efaLive Kiosk environment should start automatically.
Maybe I can provide a complete image for the Raspberry Pi in the future, we will see.
Secure SSL configuration for Apache 2.2
Finding a secure and compatible Apache configuration that is dealing with all the nice vulnerabilities in SSL and TLS handling is not an easy task. I always try to use an optimal configuration for my Apache 2.2. There are many threads in the Internet, but often the recommendations there don't work, because they are for Apache 2.4 or outdated. Often it is hard to find out, which version of Apache is dealt with in such a thread. Anyway, it might be helpful for others, so here is my configuration that gets an A+ at SSL Labs. It works with Apache 2.2.29.
LoadModule headers_module modules/mod_headers.so
SSLProtocol all -SSLv2 -SSLv3
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
efaLive 2.3 released
I now have uploaded efaLive 2.3 to the server. The main difference is that this version is now based on the new stable Debian release "Jessie" 8.0. Besides that there is a small watchdog that restarts the PC in case of a X-server crash. For more details have a look to the efaLive page.
Unfortunately the image size has grown over 700 MB. So you can not burn the image to a standard CD. You need an oversize CD oder a DVD. However, I recommend to use a USB stick, anyway.
Pitfalls with mocking in Python
Yesterday I have implemented a test for a Python module of the efaLive project. It required me to mock out one class that is used by the test target. So I used the
@patch annotation to mock the class. In a first step I used
assert_called_once(), copied from some website, to verify that a specific method of the mock has been called. The test was green. Then I changed the test to use
assert_called_once_with() to verify the arguments of the mock method as well. After that, the test became red. I checked the test code and did not find the reason for this. With
assert_called_once() I verified that the method is called, but
assert_called_once_with() tells me that it is called with other arguments than I expected. Here the test code that was green:
@patch("package1.ThirdPartyClass") def test_my_module(self, third_party_mock) class_under_test = my_module.MyClass() class_under_test.do_something() third_party_mock.called_by_do_something.assert_called_once()
After a while I found an interesting article about this problem. The point is:
third_party_mock is a mock object and in Python you can call any method of such a mock and it will not fail. The method
assert_called_once() does not exist. It was a failure to copy this code from an article in the web. However, the method
assert_called_once_with() exists and triggers the statistics of the mock object. But there is another problem in the test code. The method
called_by_do_something() is never called of the mock, but of its instance. So the correct code would be:
@patch("package1.ThirdPartyClass") def test_my_module(self, third_party_mock) class_under_test = my_module.MyClas() class_under_test.do_something() third_party_mock.return_value.called_by_do_something.assert_called_once_with("foo")
This code will work and trigger the correct mock statistics. To avoid issues like this, I even go a step further now. I don't use the convenience method
assert_called_once_with() any more. Now I use the statistics attributes
call_args directly. Here is what I would suggest to use for the test:
@patch("package1.ThirdPartyClass") def test_my_module(self, third_party_mock) class_under_test = my_module.MyClas() class_under_test.do_something() self.assertEqual(1, third_party_mock.return_value.called_by_do_something.call_count) self.assertEqual(call("foo"), third_party_mock.return_value.called_by_do_something.call_args)