Search Results: "cas"

11 June 2014

Yves-Alexis Perez: Debian, Xfce, policykit and permissions

So, it seems that for a lot of people using unstable, hardware-related permissions (shutdown/reboot, suspend/hibernate, devices mount/umount etc.) have been broken since some times. That's usually the case for people using GNOME with lightdm display manager, Xfce with either gdm or lightdm. It seems that recently, policykit (which is used by GNOME and Xfce) switched from consolekit backend to logind backend (yeah, systemd-logind). So applications using policykit needs to handle that correctly, and that means beeing sure a logind session is correctly setup, which is done by installing the package libpam-systemd. For now, it's still possible to not switch to systemd as init system, by installing the systemd-shim package before libpam-systemd. Be aware that (at least with the current state of affairs), this is only true with logind before 204. When systemd maintainers start transitionning to a later version, only systemd-sysv (so, systemd as init system) will work. For people reluctant to switch to systemd, they can use systemd-shim for now. Then when systemd 205+ enters the archive, either lose those hardware permissions, or try to improve systemd-shim to handle that situation. There's not much we (Xfce/LightDM maintainers) can do about that.

Daniel Pocock: Protest or Uber marketing stunt?

London's taxi "strike" today has been so successful that Uber claims to have had an 850% increase in new customer registrations this week. Well, that is a big success if you believe the strike may have been a guerrilla marketing tactic organised by Uber itself. No sympathy Personally, I have no sympathy for the taxi drivers. There is no city I have ever visited where I haven't encountered at least one taxi driver who tried to overcharge me. Honest drivers who give their customers value for money have less to fear from new technology than those who are unscrupulous. When I broke a leg a few years ago and was getting about on crutches for 6 weeks we decided to go out for dinner one night. This was the first time I went anywhere after having a long stint in hospital followed by a period of time I was confined to the house. The taxi driver deliberately skipped two turns leading directly to the restaurant, went another 1km past it and then followed a small street that winds back and forth and eventually demanded I pay him double what the fare should have been. This is exactly the type of abusive and despicable practice that is being eradicated by Uber's live GPS mapping technology. Although not every driver behaves so shamefully, this type of abuse of the weak or vulnerable is replicated in one way or another the world over. For example, in Melbourne, Australia, wheelchair taxis that have worked out they can make more money collecting families with suitcases at the airport leave genuine wheelchair users without a ride. Will Google be targeted next week? Google has just announced a step-change in plans to build their own self driving cars. Will Google offices around the world, including London be targetted by these crude blockades too? Political protest or anti-competitive mischief? Why were taxi drivers not arrested for their protest today? Given that the roads are the place where taxis and their competitors do business, can this blockade really be considered a political protest or is it an anti-competitive practice in blatant disregard of the law? Weapons of mass destruction Before even having breakfast you could probably find 10,000 cyclists in central London willing to sign a petition declaring taxis are a weapon of mass destruction. Once again, while there are honest drivers, there is a more than trivial number of taxi drivers who are a genuine danger to the lives of cyclists, scooters, motorcycles and occasionally pedestrians. I have personally experienced one of these thugs ramming my bicycle from behind (his hard-nosed insurer eventually paid up but without admitting liability). The police who attended the incident even told me they had seen so many accidents like this they wouldn't dare cycle themselves. The web is full of examples that appear to show malicious and criminal behavior by taxi drivers, thanks to Youtube and helmet cams: Will hotels protest about AirBNB? Now the taxi drivers have had their chance to cause mayhem, will hotel operators be next? What could they do though? Will they seek out AirBNB apartments and try to obstruct them somehow? Making mischief outside somebody's home is not a good way to make a point. Chances are, they would be prosecuted or served with restraining orders. So why do the taxi drivers get to jam up whole cities and get away with it? The Uber taxi meter loophole Will the courts decide that the Uber app is a taxi meter? This is actually a tough question. Even if courts rule against apps that perform live metering, Uber could simply remove all metering functions from the app itself and perform the metering calculations in the cloud. The app would just send start and finish locations to the cloud and the cloud would send a message back to the phone confirming the charge. The phone is then nothing more than a communication and positioning device. Remember the elevator man? When the automobile was first invented, laws were made requiring every car to be accompanied through public streets by a man carrying a flag. That job, like many others, no longer exists. elevator attendant In the good old days, every elevator had a man or woman who would sit on a stool and press buttons to operate the doors and motors. Some up-market department stores and hotels still have an elevator man to add a touch of nostalgia. The vast majority, however, have eliminated these jobs thanks to automatic elevators. Now, even aircraft can land automatically on a ship at sea. Look at all those people manning the deck in the video and contemplate how many of them might potentially be out of a job too in 50 years time as Terminator-style automated battleships patrol the seas. Technology, like the Terminator, is not going to stop.

10 June 2014

Russell Coker: Google Hardware Support

Ironically just 5 days after writing about how I choose Android devices for a long service life [1] my wife s Nexus 5 (with 32G of RAM (sorry Flash storage) to give it a long useful life) totally died. It reported itself as being fully charged and then 15 minutes later it was off and could not be revived. No combination of pushing the power button and connecting the power cable caused the screen to light up or any sound to be emitted. Google has a nice interactive support site for nexus devices that describes more ways of turning a phone on than any reasonable person could imagine. After trying to turn the phone on in various ways (plugged and unplugged etc) it gave me a link to get phone support. Clicking on that put me in the queue to RECEIVE a phone call and a minute later a lady who spoke English really well (which is unusual for telephone support) called me to talk me through the various options. Receiving a phone call is a much better experience than making a call. It meant that if the queue for phone support was long then I could do other things until the phone rings. It s impossible to be productive at other tasks while listening for hold music to stop and a person to start talking. The cost of doing this would be very tiny, while there would be some cost in hardware and software to have a web site that tells me how long I can expect to wait for a call a more basic implementation where I just submit my number and wait for a call would be very cheap to implement. The costs of calls from the US to Australia (and most places where people can afford a high end Android phone) are quite cheap for home users and are probably cheaper if you run a call center. If the average support call cost Google $1 and 3% of phones have support calls then that would be an extra cost of $0.03 per phone. I expect that almost everyone who buys a $450 phone would be happy to pay a lot more than $0.03 to avoid the possibility of listening to hold music! I received the phone call about a minute after requesting it, this was nice but I wonder how long I would have waited if I hadn t requested a call at 1AM Australian time (presumably during the day in a US call center). In any case getting a 1 minute response is great for any time of the day or night, lots of call centers can t do that. While the phone support is much better than most phone support, it would be nice if they added some extra options. I think it would be good to have webchat and SMS as options for support for the benefit of people who don t want to speak to strangers. This would be useful to a lot of people on the Autism Spectrum and probably others too. The phone call wasn t particularly productive, it merely confirmed that I had followed all the steps on the support website. Then I received an email telling me about the web site which was a waste of time as I d covered that in the phone call. I have just replied to their second email which asked for the IMEI of the phone to start the warranty return process. We could have saved more than 24 hours delay if this had been requested in the first email or the phone call. Google could have even requested the IMEI through the web site before starting the phone call. It would have been even easier if Google had included the device IMEI in the email they sent me to confirm the purchase as searching for old email is a lot easier than searching through my house for an old box. Another option for Google would be to just ask me for the Gmail account used for the purchase, as I only bought one Nexus 5 on that account they then have all the purchase details needed for a warranty claim. While the first call was a great experience the email support following that has been a waste of time. I m now wondering if they aim to delay the warranty process for a few days in the hope that the phone will just start working again.
Related posts:
  1. Support Gay Marriage in case You Become Gay A common idea among the less educated people who call...
  2. LUV Hardware Library What is it? Last month I started what I am...
  3. Wyndham Resorts is a Persistent Spammer Over the last week I have received five phone calls...

9 June 2014

Dirk Eddelbuettel: Rcpp 0.11.2

A new minor release 0.11.2 of Rcpp is now on the CRAN network for GNU R, and binaries for Debian have also been uploaded. The release smoothes a few edges on both the Rcpp side itself, as well as on the interaction between Rcpp and R which since release 3.1.0 offers a few new features related to C++11. Kevin added a couple of neat extensions related to vectors, a new ListOf templated list class, as well as a new option to warn on implicit casts. We decided not to make this option the default as it may be too common in some packages. JJ took care of a few buglets related to the wonderful Rcpp Attributes. See the NEWS file section below for details, or the ChangeLog file in the package and on the Rcpp Changelog page. Note that the diffstat reported by CRANberries is very large as Kevin also committed a whitespace cleanup which touched almost all files. As before, we tested this release by building against all CRAN packages which depend upon Rcpp. In fact we did three such runs leading up to the release. Only one package was blacklisted (as I currently don't have CUDA set-up), two had what may be internal errors or tests which were too restrictive, sixteen suffered from missing packages or RGL devices --- but the remaining 202 packages all built and tested cleanly. Detailed results of those tests (and the scripts for it) are in the rcpp-logs repo GitHub. There are a number of other fixes, upgrades and other extensions detailed in NEWS file extract below, in the ChangeLog file in the package and on the Rcpp Changelog page.
Changes in Rcpp version 0.11.2 (2014-06-06
  • Changes in Rcpp API:
    • Implicit conversions, e.g. between NumericVector and IntegerVector, will now give warnings if you use #define RCPP_WARN_ON_COERCE before including the Rcpp headers.
    • Templated List containers, ListOf<T>, have been introduced. When subsetting such containers, the return is assumed to be of type T, allowing code such as ListOf<NumericVector> x; NumericVector y = x[0] + x[1] + x[2].
    • In a number of instances, returned results are protected and/or cast more carefully.
  • Changes in Rcpp Attributes
    • Trailing line comments are now stripped by the attributes parser. This allows the parser to handle C++ source files containing comments inline with function arguments.
    • The USE_CXX1X environment variable is now defined by the cpp11 plugin when R >= 3.1. Two additional plugins have been added for use with C++0x (eg when using g++ 4.6.* as on Windows) as well as C++1y for compilers beginning to support the next revision of the standard; additional fallback is provided for Windows.
    • compileAttributes() now also considers Imports: which may suppress a warning when running Rcpp.package.skeleton().
Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

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

8 June 2014

Bits from Debian: DebConf14 - Call for talks, BoFs and events

The Debian project is excited to announce that we are now accepting presentations, discussion sessions and tutorials for our DebConf14 conference which will take place in Portland State University, Oregon, USA from 23 to 31 August. Submitting an event To submit an event, first register as an attendee for DebConf14 in the conference management system. If you have any doubts or have problems with the registration process please check the Registration FAQ. After registering, go to the event submission page, or click on the Create an event option from the management system. Describe your submission in the web form. The most common event types are Lecture or Open Discussion (BoF). Please include a short title (to make it easy to produce a compact schedule) and an engaging description of the event. Tracks We will organize some talks into thematic tracks. If you have a proposal for a DebConf track, such as "Debian ARM", "Debian Infrastructure", or "Community Outreach" please contact talks@debconf.org. If you would like to be a track coordinator, please volunteer on the given mail address. Format of the events A regular session will be 45 minutes long, including time for questions. There will be a 15 minute breaks between events. Submissions are not limited to traditional talks: you could propose a performance, art installation, debate, or anything else. If you have any specific requirements for your event, please send an email to talks@debconf.org with the details of your requirements and be sure to mention your event title in the subject. Deadline While we ask speakers to submit their events before the deadline of 7 July 2014, 23:59:59 UTC, late submissions will continue to be accepted for scheduling until the end of DebConf. All attendees will have an opportunity to schedule ad-hoc events during DebConf itself if we have space for them. Very promising late submissions may be considered for inclusion in the main conference. Note that ad-hoc events have a much lower chance of video archiving, and streaming, so if you want these services it's better to get your submissions in early. DebConf official events will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides and papers. For private communication regarding your talk, or for more general ideas, or questions about the event and talks, please mail us We hope to you see you and share some good times with you this year in Portland during DebConf14!

Wouter Verhelst: Is Debian non-free?

According to the Free Software Foundation, the Debian distribution is not a Free System Distribution. While I, as a Debian Developer, disagree with that point of view, it should be obvious that the opinion of an organization that engages in politics (or, at the very least, in political lobbying) and of which I am not a member should not be my concern. However, it has long irked me the wrong way that these claims exist. A few weeks ago, I found the System distribution commitments page on Wikipedia. This does change the situation somewhat; I cannot say that a page explaining an opinion of the FSF is wrong; but if that opinion is copied nearly verbatim to a website which claims neutrality as one of its "Core content policies", then the situation is significantly different. When I originally found that page, it was immediately obvious where the content came from, but there was no reference listed, so I added a "citation needed" tag, the first time I ever did so on Wikipedia. Now, a few weeks later, a reference has been added, and the "citation needed" tag removed. However, as expected, the only reference which has been added is the highly opinionated document on the FSF's website, which is hardly neutral. I've added another tag (this time a "which" tag, asking for more clarification) and added a Talk page listing my concerns with the article. But I can't really explain in Wikipedia why I think the whole premise is wrong; that's what a blog is for. So, here goes. The FSF lists two reasons why they do not endorse Debian:
  1. The non-free and contrib repositories
  2. An unsubstantiated claim that "the installer in some cases recommends [...] non-free firmware files for the peripherals on the machine."
Let's have a look at them, each in turn.

Non-free and contrib It is true that Debian provides non-free software in separate repositories, and that software in these repositories does not comply with either the Debian Free Software Guidelines (DFSG) or the FSF's Free Software Definition. However, the non-free and contrib repositories are fairly small: 
wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_non-free_binary-amd64_Packages
4398812934
That is, the non-free repository contains just over 4G of software (after installation). Contrib is even smaller: 
wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_contrib_binary-amd64_Packages 
306578636
While, combined, this is approximately the same size as some other distributions, free and non-free together, it pales in comparison with the "main" repository: 
wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_main_binary-amd64_Packages
60025033622
i.e., the "main" repository contains just shy of 60G of software. Of course, whether non-free is large or not should not matter at all; the fact that it exists in the first place is a problem for free software advocates. But of those 4 gigabytes, what exactly is the non-free repository used for? For that, the Debian popularity contest has a page specifically for the non-free section. Looking at this page, and ignoring the packages that are listed as "Not in sid" (which either means they were installed from third-party suppliers and therefore cannot be attributed to Debian, or were only available in older distributions so should not be held against the Debian of today anymore), we see three main uses of non-free:
  1. Various implementations of non-free algorithms (unrar, libfaac0, etc)
  2. A lot of packages containing non-free firmware
  3. A number of packages containing non-free documentation
The first package which does not fit any of those descriptions is iozone3, currently on the 64th position of the popularity contest (including packages "Not in sid"). The first item in this list is something which most free software advocates will try to avoid. After all, for all of those algorithms, alternatives exist, and so there is no real reason why one would want to use such software, other than "someone sent me a file encoded according to that algorithm, and I want to decode it". Debian gives you the option to do so, but a valid case could be made for not doing so. The second item in that list is really an alternate version of "the installer recommends non-free software", so I'll come back on that in the next section. The 3rd item in the above list deserves some special attention. Just over 10 years ago, Debian clarified its position where it clearly specified that documentation and programs (as both are interpreted as "software") should follow the same set of guidelines regarding freedom. The FSF disagrees with this position, and chose to release some of its documentation under the GFDL with invariant sections, which Debian decided is a non-free license in 2006. Since then, such GNU documentation would no longer be available were Debian to ditch the non-free repository.

Recommending non-free firmware As I said above, the FSF's page claims that the Debian installer recommends non-free firmware "in some cases", without going into much detail. Special care should be taken in understanding the word "recommend" here; wiktionary defines it as follows:
recommend (third-person singular simple present recommends, present participle recommending, simple past and past participle recommended)
  1. (transitive) To bestow commendation on; to represent favourably; to suggest, endorse or encourage as an appropriate choice.
The board recommends Philips, given his ample experience in similar positions.
  1. (transitive) To make acceptable; to attract favor to.
  2. (transitive) To advise, propose, counsel favorably
The therapist recommends resting the mind and exercising the body.
  1. (transitive, archaic) To commit, confide to another's care, confidence or acceptance, with favoring representations
A medieval oblate's parents recommended the boy for life to God and the monastery
However, according to the FSF, merely showing a firmware filename in unencrypted form counts as a recommendation. I've always found that use of the word "recommendation" to be dubious, at best. Ignoring that part, we can make the following observations: The debian-installer module ("udeb") which is responsible for configuring apt is called apt-mirror-setup (code in the apt-setup git repository). The actual debconf templates which allow the user to enable the non-free or contrib repositories are the apt-setup/non-free and apt-setup/contrib templates, and they look like this: 
Template: apt-setup/non-free
Type: boolean
Default: false
# :sl1:
_Description: Use non-free software?
 Some non-free software has been made to work with Debian. Though this
 software is not at all a part of Debian, standard Debian tools can be used
 to install it. This software has varying licenses which may prevent you
 from using, modifying, or sharing it.
 .
 Please choose whether you want to have it available anyway.
Template: apt-setup/contrib
Type: boolean
Default: false
# :sl1:
_Description: Use contrib software?
 Some additional software has been made to work with Debian. Though this
 software is free, it depends on non-free software for its operation. This
 software is not a part of Debian, but standard Debian tools can be
 used to install it.
 .
 Please choose whether you want this software to be made available to you.
Note the lines Default: false, which imply that the default answer to these questions is to disable the non-free and contrib repositories. A question which defaults to false isn't a recommendation, nor do I read the text as any form of recommendation to install these repositories (quite the contrary, in fact). More important than whether the default is to enable or disable these repositories is whether this question is even shown to the user in normal installations. Whether this is the case isn't decided by any template; instead, it is decided by the code that calls the templates. That code currently looks like this: 
STATE=1
while true; do
        case "$STATE" in
            1)
                db_input low apt-setup/non-free   true
                ;;
            2)
                # If they chose not to use non-free, ask about
                # contrib, with a default of no. If they chose to
                # use non-free, they get contrib too..
                db_get apt-setup/non-free
                if [ "$RET" = false ]; then
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib false
                        fi
                        db_input low apt-setup/contrib   true
                else
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib true
                        fi
                fi
                ;;
            *)
                break
                ;;
        esac
        if db_go; then
                STATE=$(($STATE + 1))
        else
                STATE=$(($STATE - 1))
        fi
done
Note the "low" in the db_input lines; it means the question is only shown at low priority, i.e., in "expert" mode. The result is that, unless you enable expert mode, you won't even see the question about the non-free repository, and it will be disabled by default. There won't even be any mention of it in your sources.list file. Of course, the above isn't about firmware files, which is what the FSF website claims. So, there is a second part to this story. If you run a system with hardware for which there is a non-free firmware package in the non-free repository, and you provided firmware for this hardware to the installer through various means, then the hw-detect module comes into play. This has code which currently looks like this: 
# install cached firmware debs
if [ -d /var/cache/firmware ]; then
    for deb in /var/cache/firmware/*.deb; do
            if [ -f "$deb" ]; then
                    cp -a "$deb" /target/tmp
                    # TODO debconf passthrough
                    if ! in-target dpkg -i "/tmp/$(basename "$deb")"; then
                            # dpkg failed, force removal of package
                            in-target dpkg --force-depends --remove "$(deb_package "$deb")"   true
                    fi
                    rm -f "/target/tmp/$deb"
                    need_nonfree=1
            fi
    done
fi
if [ "$need_nonfree" ]; then
    db_set apt-setup/non-free true
fi
As can bee seen, if any firmware .deb files exist under /var/cache/firmware in the installer environment, then these will be installed on the target system and default answer to the apt-setup/non-free question will be changed to enable the non-free repository. How do such packages end up there? Well, that's done by the same hw-detect udeb, in a different script. The code there is a bit too long to quote in this already far too long blog post, but it boils down to:
  • If the installer detects missing firmware, the user is asked whether (s)he wants to install firmware, with the following template: 
    Template: hw-detect/load_firmware
Type: boolean
Default: true
# :sl2:
_Description: Load missing firmware from removable media?
 Some of your hardware needs non-free firmware files to operate. The
 firmware can be loaded from removable media, such as a USB stick or
 floppy.
 .
 The missing firmware files are: $ FILES 
 .
 If you have such media available now, insert it, and continue.
  • If the user agreed to doing so (and to me, the above template does not read as a recommendation), any firmware .deb files that are provided to the installer are tested for the missing firmware files.
  • If any of those files are found, these .deb files are copied to the /var/cache/firmware directory, and the firmware files are made available to the running kernel.

Conclusion In my opinion, while some of the claims on the FSF website are correct, others are at the very least misleading. Debian does not recommend the use of non-free software; and while providing non-free firmware to the installer isn't too difficult, it isn't documented very well; and as such installing a system with non-free enabled isn't something you can easily do by accident. Debian and the FSF clearly disagree on certain things, and this disagreement, not any policies by the Debian project, is the main reason why the FSF won't encourage Debian as a free distribution. I don't think the Debian project will easily agree to get rid of the non-free repository while the FSF still produces non-free documentation or while non-free firmware is still a fact of life in this world. However, I do think the following should happen:
  1. The FSF should relicense its non-free documentation so it becomes truly free.
  2. Once that has happened, Debian should rename its non-free repository to a "hardware-support" repository (or something along those lines), and remove everything that does not exist solely for the support of proprietary hardware (i.e., non-free drivers, non-free firmware, etc).
  3. The installer could be clearer on the fact that if non-free firmware is found to be in use for the system, the user is using software that cannot be properly supported by the Debian project.
While the above wouldn't necessarily bring the opinions of the FSF and Debian 100% in line, it would at least bring their positions closer to eachother. Unfortunately, however, I doubt that this will happen; and that's a shame, because in the end, both Debian and the FSF want the same thing: a world where Free Software is the norm, not the exception.

Update
  • The first version of this text said that providing firmware is not very easy. As was pointed out to me, it isn't too hard, but it's not very well documented and not part of the 'regular' installer images.
  • Add contrib too, when we compare non-free and main
  • Clarify when GFDL is non-free

7 June 2014

Vasudev Kamath: Exposing function in python module using entry_points, WSME in a Flask webapp

The heading might be ambiguous, but I couldn't figure out better heading so let me start by explaining what I'm trying to solve here.
Problem I have a python module which contains a function which I want to expose as a REST web service in a Flask application. I use WSME for Flask application, which actually needs signature of function in question and problem comes to picture because function to be exposed is foreign to Flask application, it resides in separate python module.
Solution While reading Julien Danjou's Hackers Guide To Python book I came across the setuptools entry_points concept which can be used to extend existing feature of a tool like plug-ins. So here I'm going to use this entry_points feature from setuptools to provide function in the module which can expose the signature of function[s] to be exposed through REST. Of course this means I need to modify module in question to write entry_points and function for giving out signature of function to be exposed. I will explain this with small example. I have a dummy module which provides a add function and a function which exposes the add functions signature. 
def add(a, b):
    return a + b
def expose_rest_func():
    return [add, int, int, int]
This is stored in dummy/__init__.py file. I use pbr tool to package my python module. Below is content of setup.cfg file. 
[metadata]
name = dummy
author = Vasudev Kamath
author-email = kamathvasudev@gmail.com
summary = Dummy module for testing purpose
version = 0.1
license = MIT
description-file =
  README.rst
requires-python = >= 2.7
[files]
packages =
  dummy
[entry_points] =
myapp.api.rest =
  rest = dummy:expose_rest_func
The special thing in above file is entry_points section, which defines function to be hooked into entry_point. In our case entry_point myapp.api.rest is used by our Flask application to interact with modules which expose them. The function which will be got accessing the entry_point is expose_rest_func which gives the function to be exposed its arg types and return types as a list. If we are looking at only supporting python3 it was sufficient to know function name only and use function annotations in function definition. Since I want to support both python2 and python3 this is out of question. Now, just run the following command in virtualenv to get the module installed. 
PBR_VERSION=0.1 python setup.py sdist
pip install dist/dummy_module-0.1.tar.gz
Now if you want to see if the module is exposing entry_point or not just use entry_point_inspector tool after installing you will get a command called epi if you run it as follows you should note the dummy_module in its output 
epi group list
+-----------------------------+
  Name                         
+-----------------------------+
  cliff.formatter.completion   
  cliff.formatter.list         
  cliff.formatter.show         
  console_scripts              
  distutils.commands           
  distutils.setup_keywords     
  egg_info.writers             
  epi.commands                 
  flake8.extension             
  setuptools.file_finders      
  setuptools.installation      
  myapp.api.rest               
  stevedore.example.formatter  
  stevedore.test.extension     
  wsme.protocols               
+-----------------------------+
So our entry_point is exposed now, we need to access it in our Flask application and expose the function using WSME. It is done by below code. 
from wsmeext.flask import signature
import flask
import pkg_resources
def main():
   app = flask.Flask(__name__)
   app.config['DEBUG'] = True
   for entrypoint in pkg_resources.iter_entry_points('myapp.api.rest'):
       # Ugly but fix is only supporting python3
       func_signature = entrypoint.load()()
       app.route('/' + func_signature[0].__name__, methods=['POST'])(
           signature(func_signature[-1],
               *func_signature[1:-1])(func_signature[0]))
   app.run()
if __name__ == '__main__':
    main()
entry_point myapp.api.rest are iterated using the pkg_resources package provided by setuptools, when I load the entry_point I get back the function to be used which is called in same place to get function signature. Then I'm calling Flask and WSME decorator functions (yeah instead of decorating I'm using them directly over function to be exposed). The code looks bit ugly at the place where I'm accessing list using slices but I can't help it due to limitation of python2 with python3 there is new packing and unpacking stuff which makes code look bit more cooler see below. 
from wsmeext.flask import signature
import flask
import pkg_resources
def main():
    app = flask.Flask(__name__)
    app.config['DEBUG'] = True
    for entrypoint in pkg_resources.iter_entry_points('silpa.api.rest'):
        func, *args, rettype = entrypoint.load()()
        app.route('/' + func.__name__, methods=['POST'])(
        signature(rettype, *args)(func_signature[0]))
    app.run()
if __name__ == '__main__':
    main()
You can access the service at http://localhost:5000/add depending on Accept header of HTTP you will get either XML or JSON response. If you access it from browser you will get XML response.
Usecase Now if you are wondering what is the reason behind this experience, this is for SILPA Project. I'm trying to implement REST service for all Indic language computing module. Since all these module are independent of SILPA which is a Flask web app I had to find a way to achieve this, and this is what I came up with.
Conclusion I'm not sure if there is any other approaches to achieve this, if there I would love to hear about them. You can write your comments and suggestion over email

Craig Small: A python utf gotcha

This one had me stumped for a while: 
# -*- coding: utf-7 -*-
import datetime
from sqlalchemy import ForeignKey, Column
from sqlalchemy.types import Integer, Unicode, Boolean, DateTime
 
default_due_date = datetime.datetime.now() + datetime.timedelta(days=30)
Syntax error found on last line. Hmm, bring up a python interpreter and type the last line in with the imports. Works fine. It s the first line that is the problem, I typoed it and made it utf-7 not utf-8. I suppose it means that it is case-insenstive. Still, it wasn t too clear to me at least, what was going on.

6 June 2014

Ian Donnelly: Week 3: First Merge Implementation

This week went much better. I figured out how to properly implement over an Elektra Keyset and was able to write my first implementation of the Merge function. Right now I need to move on to testing my implementation and fixing the bugs. Already I am aware of a change that will need to be made. I am going to need to use full key names for lookup instead of a cascading lookup like I have now. I plan to use the full name for the root of the keyset in conjunction with the keys full names to change the names to look in the right place for each keyset. Additionally I had a video call with Markus and Felix today and I have a clear plan for what the next two weeks should look like. I really feel like I am getting into the swing of things and better understanding Elektra as well as the development process. So for next week I plan to better test the merge implementation and fix any bugs that crop up. Additionally I plan to write some automated tests for the merge function to make sure it is running correctly. Additionally I am going to work to understand Debian packaging. Also I am going to look at Samba and understand when it checks the configuration files when upgrading the package to see where the merge tool would be used. I want to get a prototype of a package upgrade running the kdb merge tool during an upgrade instead of prompting the user to manually merge the config files. I also plan to spend some extra hours looking at the latest version on Elektra and trying to fix errors with the debian package. I am going to package a version with the augeas_plugin. Additionally I am going to work on fixing some of the lintian errors that are occurring. In other words, it is going to be a very busy week. For reference, here is the proper way to iterate through a keyset. KeySet ks;
Key key;
ks.rewind(); //This is the line I was forgetting. It is necessary to call this function to point the KeySet's internal cursor to the beginning of the KeySet.
while(key=ks.next())
//This will iterate through the KeySet until key is no longer valid (the end of the KeySet).
 Anyway, I will update you all next week. Until Then,
Ian

Gunnar Wolf: What defines an identity?

I must echo John Sullivan's post: GPG keysigning and government identification. John states some very important reasons for people everywhere to verify the identities of those parties they sign GPG keys with in a meaningful way, and that means, not just trusting government-issued IDs. As he says, It's not the Web of Amateur ID Checking. And I'll take the opportunity to expand, based on what some of us saw in Debian, on what this means. I know most people (even most people involved in Free Software development not everybody needs to join a globally-distributed, thousand-people-strong project such as Debian) are not that much into GPG, trust keyrings, or understand the value of a strong set of cross-signatures. I know many people have never been part of a key-signing party. I have been to several. And it was a very interesting experience. Fun, at the beginning at least, but quite tiring at the end. I was part of what could very well constitute the largest KSP ever in DebConf5 (Finland, 2005). Quite awe-inspiring We were over 200 people, all lined up with a printed list on one hand, our passport (or ID card for EU citizens) in the other. Actwally, we stood face to face, in a ribbon-like ring. And, after the basic explanation was given, it was time to check ID documents. And so it began. The rationale of this ring is that every person who signed up for the KSP would verify each of the others' identities. Were anything fishy to happen, somebody would surely raise a voice of alert. Of course, the interaction between every two people had to be quick More like a game than like a real check. "Hi, I'm #142 on the list. I checked, my ID is OK and my fingerprint is OK." "OK, I'm #35, I also printed the document and checked both my ID and my fingerprint are OK." The passport changes hands, the person in front of me takes the unique opportunity to look at a Mexican passport while I look at a Somewhere-y one. And all is fine and dandy. The first interactions do include some chatter while we grab up speed, so maybe a minute is spent Later on, we all get a bit tired, and things speed up a bit. But anyway, we were close to 200 people That means we surely spent over 120 minutes (2 full hours) checking ID documents. Of course, not all of the time under ideal lighting conditions. After two hours, nobody was checking anything anymore. But yes, as a group where we trust each other more than most social groups I have ever met, we did trust on others raising the alarm were anything fishy to happen. And we all finished happy and got home with a bucketload of signatures on. Yay! One year later, DebConf happened in Mexico. My friend Martin Krafft tested the system, perhaps cheerful and playful in his intent but the flaw in key signing parties such as the one I described he unveiled was huge: People join the KSP just because it's a social ritual, without putting any thought or judgement in it. And, by doing so, we ended up dilluting instead of strengthening our web of trust. Martin identified himself using an official-looking ID. According to his recount of the facts, he did start presenting a German ID and later switched to this other document. We could say it was a real ID from a fake country, or that it was a fake ID. It is up to each person to judge. But anyway, Martin brought his Transnational Republic ID document, and many tens of people agreed to sign his key based on it Or rather, based on it plus his outgoing, friendly personality. I did, at least, know perfectly well who he was, after knowing him for three years already. Many among us also did. Until he reached a very dilligent person, Manoj, that got disgusted by this experiment and loudly denounced it. Right, Manoj is known to have strong views, and using fake IDs is (or, at least, was) outside his definition of fair play. Some time after DebConf, a huge thread erupted questioning Martin's actions, as well as questioning what do we trust when we sign an identity document (a GPG key). So... We continued having traditional key signing parties for a couple of years, although more carefully and with more buzz regarding these issues. Until we finally decided to switch the protocol to a better one: One that ensures we do get some more talk and inter-personal recognition. We don't need everybody to cross-sign with everyone else A better trust comes from people chatting with each other and being able to actually pin-point who a person is, what do they do. And yes, at KSPs most people still require ID documents in order to cross-sign. Now... What do I think about this? First of all, if we have not ever talked for at least enough time for me to recognize you, don't be surprised: I won't sign your key or request you to sign mine (and note, I have quite a bad memory when it comes to faces and names). If it's the first conference (or social ocassion) we come together, I will most likely not look for key exchanges either. My personal way of verifying identities is by knowing the other person. So, no, I won't trust a government-issued ID. I know I will be signing some people based on something other than their name, but hey I know many people already who live pseudonymously, and if they choose for whatever reason to forgo their original name, their original name should not mean anything to me either. I know them by their pseudonym, and based on that pseudonym I will sign their identities. But... *sigh*, this post turned out quite long, and I'm not yet getting anywhere ;-) But what this means in the end is: We must stop and think what do we mean when we exchange signatures. We are not validating a person's worth. We are not validating that a government believes who they claim to be. We are validating we trust them to be identified with the (name,mail,affiliation) they are presenting us. And yes, our signature is much more than just a social rite It is a binding document. I don't know if a GPG signature is legally binding anywhere (I'm tempted to believe it is, as most jurisdictions do accept digital signatures, and the procedure is mathematically sound and criptographically strong), but it does have a high value for our project, and for many other projects in the Free Software world. So, wrapping up, I will also invite (just like John did) you to read the E-mail self-defense guide, published by the FSF in honor of today's Reset The Net effort.

Robert Edmonds: BIND and GCC 4.9

ISC has issued an operational notification advising the use of the -fno-delete-null-pointer-checks flag when compiling current versions of BIND with GCC 4.9:
Beginning with GCC 4.9.0, code optimization in GCC now includes (by default) an optimization which is intended to eliminate unnecessary null pointer comparisons in compiled code. Unfortunately this optimization removes checks which are necessary in BIND and the demonstrated effect is to cause unpredictable assertion failures during execution of named, resulting in termination of the server process. Future versions of BIND will be modified so that the optimizer does not incorrectly remove necessary checks when building from source, and until those versions are available multiple immediate workarounds are available.
According to the GCC documentation, -fdelete-null-pointer-checks performs the following optimization, and is enabled by default even when compiling with -O0:
Assume that programs cannot safely dereference null pointers, and that no code or data element resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null.
This optimization dates back to 1999 but it recently became more aggressive in the GCC 4.9 release:
GCC might now optimize away the null pointer check in code like: 
int copy (int* dest, int* src, size_t nbytes)  
  memmove (dest, src, nbytes);
  if (src != NULL)
    return *src;
  return 0;
The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash. The example above needs to be fixed to avoid the invalid memmove call, for example: 
if (nbytes != 0)
  memmove (dest, src, nbytes);
It's interesting that the ISC operational advisory labels this an "incorrect" optimization. I wonder if this is a similar case to the Glibc optimization which exposed incorrect usage of memcpy() in many applications, including BIND. Fortunately, few users should be affected by this bug, since GCC 4.9 is fairly new. (The upcoming Fedora 21 release will probably be the first mainstream distribution to ship with GCC 4.9 as the default compiler.) Update: Debian bug #750760 filed.

5 June 2014

Johannes Schauer: botch updates

My last update about ongoing development of botch, the bootstrap/build ordering tool chain, was four months ago and about several incremental updates. This post will be of similar nature. The most interesting news is probably the additional data that bootstrap.debian.net now provides. This is listed in the next section. All subsequent sections then list the changes under the hood that made the additions to bootstrap.debian.net possible.

bootstrap.debian.net The bootstrap.debian.net service used to have botch as a git submodule but now runs botch from its Debian package. This at least proves that the botch Debian package is mature enough to do useful stuff with it. In addition to the bootstrapping results by architecture, bootstrap.debian.net now also hosts the following additional services: Further improvements concern how dependency cycles are now presented in the html overviews. While before, vertices in a cycle where separated by commas as if they were simple package lists, vertices are now connected by unicode arrows. Dashed arrows indicate build dependencies while solid arrows indicate builds-from relationships. For what it's worth, installation set vertices now contain their installation set in their title attribute.

Debian package Botch has long depended on features of an unreleased version of dose3 which in turn depended on an unrelease version of libcudf. Both projects have recently made new releases so that I was now able to drop the dose3 git submodule and rely on the host system's dose3 version instead. This also made it possible to create a Debian package of botch which currently sits at Debian mentors. Writing the package also finally made me create a usable install target in the Makefile as well as adding stubs for the manpages of the 44 applications that botch currently ships. The actual content of these manpages still has to be written. The only documentation botch currently ships in the botch-doc package is an offline version of the wiki on gitorious. The new page ExamplesGraphs even includes pictures.

Cross By default, botch analyzes the native bootstrapping phase. That is, assume that the initial set of Essential:yes and build-essential packages magically exists and find out how to bootstrap the rest from there through native compilation. But part of the bootstrapping problem is also to create the set of Essential:yes and build-essential packages from nothing via cross compilation. Botch is unable to analyze the cross phase because too many packages cannot satisfy their crossbuild dependencies due to multiarch conflicts. This problem is only about the dependency metadata and not about whether a given source package actually crosscompiles fine in practice. Helmut Grohne has done great work with rebootstrap which is regularly run by jenkins.debian.net. He convinced me that we need an overview of what packages are blocking the analysis of the cross case and that it was useful to have a crossbuild order even if that was a fake order just to have a rough overview of the current situation in Debian Sid. I wrote a couple of scripts which would run dose-builddebcheck on a repository, analyze which packages fail to satisfy their crossbuild dependencies and why, fix those cases by adjusting package metadata accordingly and repeat until all relevant source packages satisfy their crossbuild dependencies. The result of this can then be used to identify the packages that need to be modified as well as to generate a crossbuild order. The fixes to the metadata are done in an automatic fashion and do not necessarily reflect the real fix that would solve the problem. Nevertheless, I ended up agreeing that it is better to have a slightly wrong overview than no overview at all.

Minimizing the dependency graph size Installation sets in the dependency graph are calculated independent from each other. If two binary packages provide A, then dependencies on A in different installation sets might choose different binary packages as providers of A. The same holds for disjunctive dependencies. If a package depends on A C and another package depends on C A then there is no coordination to choose C so to minimize the overall amount of vertices in the graph. I implemented two methods to minimize the impact of cases where the dependency solver has multiple options to satisfy a dependency through Provides and dependency disjunctions. The first method is inspired by Helmut Grohne. An algorithm goes through all disjunctive binary dependencies and removes all virtual packages, leaving only real packages. Of the remaining real packages, the first one is selected. For build dependencies, the algorithm drops all but the first package in every disjunction. This is also what sbuild does. Unfortunately this solution produces an unsatisfiable dependency situation in most cases. This is because oftentimes it is necessary to select the virtual disjunctive dependency because of a conflict relationship introduced by another package. The second method involves aspcud, a cudf solver which can optimize a solution by a criteria. This solution is based on an idea by Pietro Abate who implemented the basis for this idea back in 2012. In contrast to a usual cudf problem, binary packages now also depend on the source packages they build from. If we now ask aspcud to find an installation set for one of the base source packages (I chose src:build-essential) then it will return an installation set that includes source packages. As an optimization criteria the number of source packages in the installation set is minimized. This solution would be flawless if there were no conflicts between binary packages. Due to conflicts not all binary packages that must be coinstallable for this strategy to work can be coinstalled. The quick and dirty solution is to remove all conflicts before passing the cudf universe to aspcud. But this also means that the solution does sometimes not work in practice.

Test cases Botch now finally has a test target in its Makefile. The test target tests two code paths of the native.sh script and the cross.sh script. Running these two scripts covers testing most parts of botch. Given that I did lots of refactoring in the past weeks, the test cases greatly helped to assure that I didnt break anything in the process. I also added autopkgtests to the Debian packaging which test the same things as the test target but naturally run the installed version of botch instead. The autopkgtests were a great help in weeding out some lasts bugs which made botch depend on being executed from its source directory.

Python 3 Reading the suggestions in the Debian python policy I evaluated the possibility to use Python 3 for the Python scripts in botch. While I was at it I added transparent decompression for gzip, bz2 and xz based on the file magic, replaced python-apt with python-debian because of bug#748922 and added argparse argument parsing to all scripts. Unfortunately I had to find out that Python 3 support does not yet seem to be possible for botch for the following reasons:
  • no soap module for Python 3 in Debian (needed for bts access)
  • hash randomization is turned on by default in Python 3 and therefore the graph output of networkx is not deterministic anymore (bug#749710)
Thus I settled for changing the code such that it would be compatible with Python 2 as well as with Python 3. Because of the changed string handling and sys.stdout properties in Python 3 this proved to be tricky. On the other hand this showed me bugs in my code where I was wrongly relying on deterministic dictionary key traversal.

4 June 2014

Russell Coker: Android Device Service Life

In recent years Android devices have been the most expensive things I ve purchased apart from airline tickets and other travel/holiday expenses. As they are expensive I d like to use them for as long as possible to get the most value for money. Also as I give my devices to relatives when they no longer work for me I d like to avoid having relatives hassling me about their phone not working as desired. So I ve been thinking about the features that I need to make it possible to use a phone or tablet for a long time. RAM The way Android works is that when an application in the foreground requests more memory background applications may be closed to free some memory. Android doesn t use swap by default, there is some documentation on how to enable it (and it s not difficult to figure out for anyone who has used Linux before) but generally it s not done. If you run a larger application the chances of apps closing in the background (causing delays when you switch back to them and possibly a loss of context if the app is buggy and doesn t preserve all state) are increased. As a general trend apps tend to get bigger to provide more features and also because users who own newer bigger devices don t complain as much about memory use. Also to make things worse new versions of Android tend to use more RAM. So a phone that runs well can suddenly start performing badly when you upgrade to a new version of Android (which incidentally usually can t be reversed) and upgrade to new versions of apps (which can t be reversed through the Google Play Store). The Sony Ericsson Xperia X10 was a very nice phone when it was released, it ran Android 2.1 very quickly. When I upgraded the Xperia X10s that my wife and I used to Android 2.3 (which was necessary to have the phone run as a Wifi access point) performance dropped considerably. The Android upgrade combined with newer larger apps means that those phones are barely usable now. 384M of RAM was plenty in early 2011 when I first used the Xperia X10 but it s not nearly enough now. Recently 2G of RAM has been the minimum for a mid-range or high-end phone. It seems difficult to imagine a new Android feature as compelling as the addition of Wifi access point support in Android 2.3 that would drive an upgrade to a future memory hogging version of the OS. It also seems difficult to imagine Android apps needing enough memory to destroy the performance of a phone with 2G of RAM. But then I couldn t imagine the 384M in an Xperia X10 becoming inadequate or the 512M in a Samsung Galaxy S becoming barely usable either. Storage Until fairly recently storage in an Android device was divided into USB attached storage (a VFAT filesystem that could be directly mounted on a PC) and a Linux filesystem that was used for all internal operations of the phone. On such devices it typically wasn t possible to change partition sizes without a lot more skill than most users possess and most of the storage space was reserved for USB attachment. If you only had a few Android apps and lots of photos, movies, etc then this worked well. But if you wanted to install larger Android apps then you would have big problems. Even with Android 4.x devices (which all seem to have a single filesystem) you can easily run out of space. Modern games often take several hundred megs of storage. Games that take 500M+ for the Android package install (which also requires the same amount of temporary space for installation and upgrade) are common. Sometimes games download data files after they have been installed for a total size approaching 2G (such as The Sims Freeplay). When I bought a Nexus 4 for my wife I got the version with 8G of storage because paying an extra $50 for the 16G version seemed unreasonable. 8G was fine for my wife, but when she got a new phone I gave the Nexus 4 to a relative who wanted to play The Sims and other big games. That relative isn t so happy about having a limited number of games on their phone and I have to fix it when storage space runs out and things start aborting (when storage runs out the Google App Store program aborts and uses lots of space for temporary files). I recently bought a tablet with 32G of storage and filled 16G on the first day (tablets are good for watching
TV and TV shows are big). Fortunately the tablet in question has a SD socket so that when space becomes a problem in a year or two I can buy an SD card and keep using it. An unfortunate recent decision by Google was to prevent apps from being run from a SD card. So even if you have a device with a SD socket you still need to have enough internal storage for all apps and their private data. At 500M+ for a modern game that means a device with 8G of storage (which includes space for the OS) will be lucky to get 8 games installed. If you want to use a phone to it s full capacity (playing various media files, games, etc) then it seems that the minimum storage capacity would be 8G of internal storage and a SD socket. For a device without an SD socket (such as the Nexus 5 with 16G or 32G of storage) your future use will be limited. 32G is probably enough for a phone given that you can recode movies to use less space (the FullHD screen on the Nexus 5 is nice but 720p movies will probably look good enough). But the larger screens of tablets demand better video quality so the Nexus tablets are probably a bad choice due to lack of storage space. Screen Size and Resolution I have previously written about the sizes of devices and how they may be used by people of various ages [1]. That should be of use for anyone who plans to use their old phone as an educational device for their children (which appears to be very common). But apart from that I can t think of any reason why size would suddenly make an old phone obsolete. Only young children will have their hands change size in any significant way. Resolution also shouldn t be a huge problem, the 480*854 screen on the Xperia X10 is fairly good for a 4 screen. While a higher resolution makes text more readable at a small size for most users the availability of a higher resolution screen isn t going to make their old phone obsolete. CPU The only Android devices I owned that appeared to develop CPU speed issues late in life were the Xperia X10 phones, and that might be more due to RAM limits and the OS upgrade. All the other devices were either obviously slow at purchase time or are still performing well now. CPU speed may make it difficult or impossible to play new games, but shouldn t affect other uses of a phone or tablet. Conclusion It seems to me that if you want to use an Android device for more than 2 years then storage capacity should be a major factor in choosing which device to purchase. It seems that lack of storage space is in many cases the main factor that makes older devices annoying or impossible to use.
Related posts:
  1. Cheap Android Tablet from Aldi I ve just bought a 7 Onix tablet from Aldi....
  2. Choosing an Android Phone My phone contract ends in a few months, so I m...
  3. Standardising Android Don Marti wrote an amusing post about the lack of...

3 June 2014

Vasudev Kamath: Using WSME with Flask microframework

After reading Julien Danjou's I found out WSME (Web Service Made Easy) a Python framework which allows us to easily create Web Services in Python. For SILPA we needed a REST like interface and I thought of giving it try as WSME readily advertised the Flask integration, and this post was born when I read the documentation for Flask integration. First of all Flask is a nice framework which will right way allow development of REST api for simple purposes, but my requirement was bit complicated where I had to expose function in a separate python modules through SILPA. I think detailed requirement can be part of another post, so let me explain how to use WSME with Flask app. WSME integration with Flask is done via decorator function wsmeext.flask.signature which expects you to provide it with signature of function to expose. And here is its documentation, basically signature of signature function is 
wsmeext.flask.signature(return_type, *arg_types, **options)
Yeah thats all docs have sadly. So basically exposing is the only thing WSME handles for us here, routing and other stuffs need to be done by Flask itself. So lets consider a example, simple function to add as shown below. 
def add(a, b):
    return a + b
For providing REST like service, all you need below code. 
from flask import Flask
from wsmeext.flask import signature
app = Flask(__name__)
@app.route('/add')
@signature(int, int, int)
def add(a, b):
    return a + b
if __name__ == '__main__':
       app.run()
So first argument to signature is return type of function and rest arguments are the argument to function to be exposed. Now you can access the newly exposed service by visiting http://localhost:5000/add but don't forget to pass the arguments either via query string or through post. You can restrict methods of access via Flask's route. So what's the big deal of not having docs right?.. Well fun part began when we use bit more complex return type like dictionaries or lists . Below is modified code I'm using to demonstrate problem I faced during using dict as return type. 
from flask import Flask
from wsmeext.flask import signature
app = Flask(__name__)
@app.route('/add')
@signature(dict, int, int)
def add(a, b):
    return  "result": a + b 
if __name__ == '__main__':
    app.run()
Basically I'm returning a dictionary containing result now, for demonstration purpose. When I run the application boom python barked at me with following message. 
Traceback (most recent call last):
File "wsme_dummy.py", line 7, in <module>
 @signature(dict, int, int)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsmeext\flask.py", line 48, in decorator
 funcdef.resolve_types(wsme.types.registry)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\api.py", line 109, in resolve_types
 self.return_type = registry.resolve_type(self.return_type)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\types.py", line 739, in resolve_type
 type_ = self.register(type_)
File "c:\Users\invakam2\.virtualenvs\wsmetest\lib\site-packages\wsme\types.py", line 668, in register
 class_._wsme_attributes = None
TypeError: can't set attributes of built-in/extension type 'dict'
After going through code from files involved in above traces this is what I found
  1. wsmeext.flask.signature inturn uses wsme.signature which is just alias of wsme.api.signature.
  2. Link in documentation in sentence See @signature for parameter documentation is broken and should actually link to wsme.signature in docs.
  3. wsme.signature actually calls resolve_type to check on types of return and arguments. This function checks if types are instance of dict or list in such cases it creates instances of wsme.type.DictType and wsme.type.ArrayType respectively with values from the argument.
  4. When I just passed built-in type dict the control went to else part which just passed the type to wsme.type.Register.registry function which tries to set the attribute _wsme_attribute which actually raises TypeError as we can't set attribute for built-in types.
So by inspecting code of wsme.type.Registry.resolve_type and wsme.type.Registry.register its clear that what signature expects when arguments or return type is dictionary/list is instance of dictionary/list with type of value in it. May be sentence is bit vague but I'm not sure how to put it more clearly, as an example in our case add function returns dictioanry with key as string and value as int, so return type argument for signature will be str: int . Similarly if you return array with int values it will be [int]. With above understanding our add function now looks like below. 
@signature( str: int , int, int)
def add(a, b):
   return  'result': a + b
and now code worked just fine!. What I couldn't figure out here is there is no way to have tuple as return value or argument, but I guess that is not big deal. So immidiate task for me after finding this is fix the link in documentation to point to wsme.signature and probably put some note some where in documentation about above finding.

2 June 2014

Rapha&#235;l Hertzog: My Free Software Activities since January 2014

If you follow my blog closely, you noticed that I skipped all my usual monthly summaries in 2014. It s not that I stopped doing free software work, instead I was just too busy to be able to report about what I did. As an excuse, let me tell you that we just moved into a new house which was in construction since may last year. The lack of visible activity on my blog resulted in a steady decrease of the amount of donations received (January: 70.72 , February: 71.75 , March: 51.25 , April: 39.9 , May: 40.33 ). Special thanks to all the people who kept supporting my work even though I stopped reporting about it. So let s fix this. This report will be a bit less detailed since it covers the whole period since the start of the year. Debian France Preparations related to general assemblies. The year started with lots of work related to Debian France. First I took care of setting up limesurvey with Alexandre Delano to handle the vote to pick our new logo:
The new logo of Debian France I also helped Sylvestre Ledru to finalize and close the accounting books for 2013 in preparation for the general assembly that was due later in the month. I wrote the moral report of the president to be presented to the assembly. And last step, I collected vote mandates to ensure that we were going to meet the quorum for the extraordinary assembly that was planned just after the usual yearly assembly. The assemblies took place during a two days mini-debconf in Paris (January 17-18) where I was obviously present even though I gave no talk besides announcing the logo contest winner and thanking people for their participation.
Assembl e g n rale 2014 de Debian France

The Debian France members during the general assembly

It s worth noting that the extraordinary assembly was meant primarily to enshrine in our bylaws the possibility to act as a trusted organization for Debian. This status should be officialized by the Debian project leader (Lucas Nussbaum) in the upcoming weeks since we answered satisfactorily to all questions. Our paypal donation form and the accounting tools behind it are ready. Galette packaging and members map. I managed to hand over the package maintenance of galette to Fran ois-R gis Vuillemin. I sponsored all his uploads and we packaged a new plugin that allows to create a map with all the members who accept to share their location. The idea was to let people meet each other when they don t live far away with the long term goal to have Debian France organized activities not only in Paris but everywhere in France. New contributor game. Last but not least, I organized a game to encourage people to do their first contribution to Debian by offering them a copy of my book if they managed to complete a small Debian project. We got many interesting projects but the result so far seem to be very mixed. Many people did not complete their project (yet) that said for the few that did substantial work, it was rather good and they seem to be interested to continue to contribute. Debian France booth at Solutions Linux in Paris. Like each year, I spent two days in Paris to help man the Debian France booth at Solutions Linux. We had lots of goodies on sale and we made more than 2000 EUR in earnings during the two days. I also used this opportunity to try to convince companies to support the new Debian LTS effort.
Debian France booth at Solutions Linux

Tanguy Ortolo and Fernando Lagrange behind the Debian France booth

The Debian Administrator s Handbook In the last days of 2013, we released the wheezy update of the book. Then I quickly organized everything needed so that the various translation teams can now focus their efforts on the latest release of the book. Later (in February) I announced the availability of the French and Spanish translations. Debian Squeeze LTS When the security team called for help to try to put in place long term support for Squeeze, I replied positively because I m convinced that it s very important if Debian wants to stay an acceptable choice in big deployments and because I knew that some of my customers would be interested Thus I followed all the discussions (on a semi-private list first and then on debian-lts@lists.debian.org) and contributed my own experience. I have also taken up the responsibility to coordinate with the Debian contributors who can be hired to work on Squeeze LTS so that we have a clear common offer for all the companies who have offered financial support towards Squeeze LTS. Expect further news on this front in the upcoming days/weeks. Tryton I have been a long time user of SQL-Ledger to manage the accounting of my company Freexian. But while the license is free software, the project is not. It s the work of a single developer who doesn t really accept help. I have thus been considering to move to something else for a long time but never did anything. This year, after some rough evaluation, I decided to switch to Tryton for my company. It s probably not a wise choice from a business perspective because that migration took me many hours of unpaid labor but from a free software perspective it s definitely better than everything else I saw. I contributed a lot of bug reports and a few patches already (#3596, #3631, #3633, #3665, #3667, #3694, #3695, #3696, #3697) mainly about problems found in the French chart of accounts but also about missing features for my use case. I also accepted to sponsor Matthias Berhle, who is maintaining the official Debian packages of Tryton. He s already a Debian maintainer so it s mainly a matter of reviewing new source packages and granting him the required rights. Misc Debian work Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

B lint R czey: I Can Hear Music again (thanks to forked-daapd/Debian)

When I started looking for a lightweight solution of serving a music library over LAN I did not expect so many complications. I expected it not to be a unique need to have something running on a SheevaPlug straight from the Debian repository. Apparently it kind of was. Debian used to have mt-daapd (popcon: 165), but now it is available from oldstable only and upstream is dead. There is tangerine (popcon: 98) with its Mono dependencies and GUI which seemed to me overkill and more like a demo of a networked application written in Mono than a music library server. The most promising candidate was forked-daapd (popcon: 220) but it was far from being a true winner. First, it had a series of dead upstreams. At the beginning it was forked from mt-daapd (hence the name) by Julien Blache who also served as the prior Debian maintainer. Then the code base was forked and converted to use Grand Central Dispatch. Then the GCD fork died off slowly as well a few years ago. When I found the package it had been unmaintained for a few years and was based on the GCD branch which prevented building it on many architectures and the server itself was crashing or quitting occasionally. Luckily there still existed a fork thanks to Espen J rgensen which was well maintained and could serve as a way out but examining it closely it turned out that it had switched to libevent from GCD but to a version (1.4) which is present only in oldstable! And some say Debian s software versions are ancient ;-). Moreover it was not simply libevent 1.4-based, but it included some heavily patched parts of it. Espen also liked the idea of packaging his version in Debian and we extracted the patches to libevent and slowly got them accepted to libevent s master. Forked-daapd s master works best with libevent 2.1.4-alpha, but thanks to Espen the development branch now also works with libevent 2.0.x giving up some performance and a little feature. This was a long journey, but finally Espen s forked-daapd became ready for being used as a new upstream of the Debian package thus please welcome 20.0+git20140530+gc740e6e-1, the first version of forked-daapd building on all architectures for a very long time and a prime candidate for being the music library server in Jessie (and wheezy-backports, soon)! Testing, bug reports are always welcome! From the package description: 
 forked-daapd is an iTunes-compatible media server, originally intended
 as a rewrite of Firefly Media Server (also known as mt-daapd).
 It supports a wide range of audio formats, can stream video to iTunes,
 FrontRow and other compatible clients, has support for Apple's Remote
 iPhone/iPod application and can stream music to AirTunes devices like
 the AirPort Express.
 It also features RSP support for Roku's SoundBridge devices.
 Built-in, on-the-fly decoding support enables serving popular free music
 formats like FLAC, Ogg Vorbis or Musepack to those clients that do not
 otherwise support them.

Daniel Pocock: Fixing WebRTC dropouts

A few people have observed dropouts using WebRTC, including the new Debian community service at rtc.debian.org I've been going over some of these problems and made some improvements. If you tried it before and had trouble, please try again (rtc.debian.org is running with some of the fixes already). If anybody else has seen these problems or continues to experience them, please let the reSIProcate community know about it through the repro-users mailing list. WebSocket link disconnects immediately when call starts In this case, you may see the picture of the other person for a split second and then the websocket link disconnects and JSCommunicator re-initializes itself. People observing this problem had sometimes found that audio-only calls would work more frequently. I believe one reason for this problem has been some incorrect handling of the OpenSSL error queue. I posted my observations about this on the resiprocate developer's list and included a fix for it in the recent 1.9.7 release. Call starts, no remote picture appears, call stops after 20 seconds or so In this case, if you look closely in the JavaScript console, you may see that one of the endpoints has sent a SIP BYE message. A BYE message usually includes a reason such as this: Reason: SIP ;cause=200; text="RTP Timeout"
 This particular reason (RTP Timeout) may indicate that the TURN server is faulty, not running at all or is not reachable due to one or both users being behind a firewall. If you experience this problem but some other reason code appears, please share your observations on the repro-users mailing list so it can be improved. For those people who have firewall problems, this will eventually be resolved when the browsers support TURN over a TLS connection through a HTTP proxy. We also hope to provide better feedback in the JavaScript UI of JSCommunicator to tell people their call was blocked by a firewall.

1 June 2014

Antonio Terceiro: An introduction to the Debian Continuous Integration project

Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages. A new version of any of these packages can potentially break some functionality in the ruby package. And that dependency graph is very small. Looking at the dependency graph for, say, the rails package will make your eyes bleed. I tried it here, and GraphViz needed a PNG image with 7653 10003 pixels to draw it. It ain t pretty. Installing rails on a clean Debian system will pull in another 109 packages as part of the dependency chain. Again, as new versions of those packages are uploaded the archive, there is a probability that a backwards-incompatible change, or even a bug fix which was being worked around, might make some funcionality in rails stop working. Even if that probability is low for each package in the dependency chain, with enough packages the probability of any of them causing problems for rails is quite high. And still the rails dependency chain is not that big. libreoffice will pull in another 264 packages. gnome will pull in 1311 dependencies, and kde-full 1320 (!). With a system this big, problems will arrive, and that s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for. While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions. Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree). In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification. Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information. Durign the holiday break last year, I decided to give it a shot. I initially called the codebase dep8. Later I renamed it to debci, since it could potentially also run other other types of test suites in the future. Since early January, ci.debian.net run an instance of debci for the Debian Project. The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a global status is updated. Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events. Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%. There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system. This is just the beginning. debci is under a good rate of development, and you can expect to see a constant flux of improvements. In special, I would like to mention a few people who are giving amazing contributions to the project:

31 May 2014

Floris Stoica-Marcu: GSoC2014 Muon and sudo [Week2]

Hello, This has been a terrific week and a real learning experience for me. I finished packaging both Muon and QApt for Debian; my first two real debian packages, with very different packaging styles! Sune (svuorela), Maximiliano (maxy) and others helped me allot to understand the tools and I thank them very much for their support. While the first part of this second week was all about trying to make a solid package, the second part was me figuring out Policykit and KAuth in order for us to let go (as much as possible) of Kdesudo. I have managed to do a complete turnaround from kdesudo through policykit and now I am working on making an add-repo helper in C++/Qt using KAuth to keep it in line with QApt, in order to have a more uniform codebase. Big thanks to Aleix (apol) that guided me through the different uses of policykit and Kauth. To keep it short, policykit will not be used directly except QApt, in every other case we ll use KAuth. I m very close to finishing the KAuth add-repo helper and that will add improved functionality, as it extends well in what I will be doing next: renouncing specific backend support; The helper will manage how backends add/remove repos, meaning that if you use PackageKit you will no longer be tied to Apt if you want to use Muon! Here is a screenshot of the configure-software button in muon-discovery (finally) working on Debian and launching software-properties-kde:
Muon Software properties And below are some screens of Muon in the wild, running on Debian:
Auth required through policykit

Auth required through policykit

Adding Sources

Adding Sources

I hope you enjoyed this update and stay tuned for the debian package which is currently under review. Floris.

28 May 2014

Tanguy Ortolo: GNU/Linux graphic sessions: allowing computer suspend and disabling a monitor

Allowing computer suspend Major desktop environments such as Xfce or KDE have a built-in computer suspend feature, but when you use a lighter alternative, things are a bit more complicated, because basically: only root can suspend the computer. Possible solutions include: With recent updates of the related Debian packages no idea of which one exactly the latter solution may not work any more, in which case it will only return the following error: 
Error org.freedesktop.UPower.GeneralError: not authorized
It appears that this error is linked to ConsoleKit, a part of all this modern *Kit gizmo pile. If you are in this case, try prefixing your session launcher with the undocumented dark magic call ck-launch-session. For instance, this is what I have in my .xsession to launch my window manager i3: 
exec ck-launch-session i3
Note: I do not know what ck-launch-session does exactly, why it is needed, and I do not want to know. To me, all that WhatsitKit pile is just some opaque, under-documented as in: no man page crap, that no one but their author really understand, designed to solve theoretical problems no one really cares about like: how to allow locally connected users to use the sound card while forbidding it to remote users while creating new issues such as this one. This stuff is too complex and under-documented for me to dive into it, so if it does not work out of the box, it is just some crap that gets in my way to using my computer as I wish. Disabling a monitor In some configurations, you have two monitors and want to disable one. For instance, in addition to my LCD monitor, I have a projector which I only use for movies. According to xorg.conf's man page, it can be disabled this way: 
Section "Device"
    Identifier  "Internal graphic card"
    Option      "Monitor-DVI"   "LCD Monitor"
    Option      "Monitor-VGA"   "Projector"
EndSection
Section "Monitor"
    Identifier  "LCD Monitor"
EndSection
Section "Monitor"
    Identifier  "Projector"
    Option      "Enable"    "false"
EndSection
Except that does not work, because contrary to what the man page says the real option to use is not Enable but Disable! So here is the correct configuration to disable that monitor at start-up: 
Section "Device"
    Identifier  "Internal graphic card"
    Option      "Monitor-DVI"   "LCD Monitor"
    Option      "Monitor-VGA"   "Projector"
EndSection
Section "Monitor"
    Identifier  "LCD Monitor"
EndSection
Section "Monitor"
    Identifier  "Projector"
    Option      "Disable"   "true"
EndSection
Note: yes, I will send a bug report with a patch against xorg.conf's man page.

Next.

Previous.