Search Results: "jan"

24 December 2014

Gunnar Wolf: More on Debian as a social, quasi-familiar project

I have long wanted to echo Gregor's beautiful Debian Advent Calendar posts. Gregor is a dear project member and a dear friend to many of us Debianers, who has shown an amount of stamina and care for the project that inspires everybody; this year, after many harsh flamefests in the project (despite which we are moving at a great rate towards a great release!), many people have felt the need to echo how Debian even as often seen from the outside as a hostile mass of blabbering geeks is actually a great place to work together and to create a deep, strong social fabric And that's quite probably what binds the project together and ensures it will continue existing and excelling for a long time. As for the personal part: This year, my Debian involvement has once again reduced. Not because I care less about Debian, much to the contrary, but because I have taken several responsabilities which require my attention and time. Technically, I'm basically maintaining a couple of PHP-based packages I use for work (most prominently, Drupal7). I have stepped back of most of my DebConf responsabilities, although I stay (and will stay, as it's an area of the project I deeply enjoy doing) involved. And, of course, my current main area of involvement is keyring-maint (for which I have posted here several status updates). I have to say that we expected having a much harder time (read: Stronger opposition and discussions) regarding the expiry of 1024D keys. Of course, many people do have a hard time connecting anew to the web of trust, and we will still face quite a bit of work after January 1st, but the migration has been a mostly pleasant (although clearly intensive) work. Jonathan has just told me we are down to only 306 1024D keys in the keyring (which almost exactly matches the "200-300" I expected back at DC14). Anyway: People predicting doomsday scenarios for Debian do it because they are not familiar with how deep the project runs in us, how important it is socially, almost at a family level, to us that have been long involved in it. Debian is stronger than a technical or political discussion, no matter how harsh it is. And, as a personal thank-you: Gregor, your actions (the GDAC, the RC bug reports) inspire us to stay active, to do our volunteer work better, and remind us of how great is it to be a part of a global, distributed will to Do It Right. Thanks a lot!

14 December 2014

Enrico Zini: html5-sse

HTML5 Server-sent events I have a Django view that runs a slow script server-side, and streams the script output to Javascript. This is the bit of code that runs the script and turns the output into a stream of events: 
def stream_output(proc):
    '''
    Take a subprocess.Popen object and generate its output, line by line,
    annotated with "stdout" or "stderr". At process termination it generates
    one last element: ("result", return_code) with the return code of the
    process.
    '''
    fds = [proc.stdout, proc.stderr]
    bufs = [b"", b""]
    types = ["stdout", "stderr"]
    # Set both pipes as non-blocking
    for fd in fds:
        fcntl.fcntl(fd, fcntl.F_SETFL, os.O_NONBLOCK)
    # Multiplex stdout and stderr with different prefixes
    while len(fds) > 0:
        s = select.select(fds, (), ())
        for fd in s[0]:
            idx = fds.index(fd)
            buf = fd.read()
            if len(buf) == 0:
                fds.pop(idx)
                if len(bufs[idx]) != 0:
                    yield types[idx], bufs.pop(idx)
                types.pop(idx)
            else:
                bufs[idx] += buf
                lines = bufs[idx].split(b"\n")
                bufs[idx] = lines.pop()
                for l in lines:
                    yield types[idx], l
    res = proc.wait()
    yield "result", res
I used to just serialize its output and stream it to JavaScript, then monitor onreadystatechange on the XMLHttpRequest object browser-side, but then it started failing on Chrome, which won't trigger onreadystatechange until something like a kilobyte of data has been received. I didn't want to stream a kilobyte of padding just to work-around this, so it was time to try out Server-sent events. See also this. This is the Django view that sends the events: 
class HookRun(View):
    def get(self, request):
        proc = run_script(request)
        def make_events():
            for evtype, data in utils.stream_output(proc):
                if evtype == "result":
                    yield "event:  \ndata:  \n\n".format(evtype, data)
                else:
                    yield "event:  \ndata:  \n\n".format(evtype, data.decode("utf-8", "replace"))
        return http.StreamingHttpResponse(make_events(), content_type='text/event-stream')
    @method_decorator(never_cache)
    def dispatch(self, *args, **kwargs):
        return super().dispatch(*args, **kwargs)
And this is the template that renders it: 
 % extends "base.html" % 
 % load i18n % 
 % block head_resources % 
 block.super 
<style type="text/css">
.out  
    font-family: monospace;
    padding: 0;
    margin: 0;
 
.stdout  
.stderr   color: red;  
.result  
.ok   color: green;  
.ko   color: red;  
</style>
 # Polyfill for IE, typical... https://github.com/remy/polyfills/blob/master/EventSource.js # 
<script src="  STATIC_URL  js/EventSource.js"></script>
<script type="text/javascript">
$(function()  
    // Manage spinners and other ajax-related feedback
    $(document).nav();
    $(document).nav("ajax_start");
    var out = $("#output");
    var event_source = new EventSource(" % url 'session_hookrun' name=name % ");
    event_source.addEventListener("open", function(e)  
      //console.log("EventSource open:", arguments);
     );
    event_source.addEventListener("stdout", function(e)  
      out.append($("<p>").attr("class", "out stdout").text(e.data));
     );
    event_source.addEventListener("stderr", function(e)  
      out.append($("<p>").attr("class", "out stderr").text(e.data));
     );
    event_source.addEventListener("result", function(e)  
      if (+e.data == 0)
          out.append($("<p>").attr("class", "result ok").text(" % trans 'Success' % "));
      else
          out.append($("<p>").attr("class", "result ko").text(" % trans 'Script failed with code' %  " + e.data));
      event_source.close();
      $(document).nav("ajax_end");
     );
    event_source.addEventListener("error", function(e)  
      // There is an annoyance here: e does not contain any kind of error
      // message.
      out.append($("<p>").attr("class", "result ko").text(" % trans 'Error receiving script output from the server' % "));
      console.error("EventSource error:", arguments);
      event_source.close();
      $(document).nav("ajax_end");
     );
 );
</script>
 % endblock % 
 % block content % 
<h1> % trans "Processing..." % </h1>
<div id="output">
</div>
 % endblock %
It's simple enough, it seems reasonably well supported besides needing a polyfill for IE and, astonishingly, it even works!

11 December 2014

Steve Kemp: An anniversary and a retirement

On this day last year I we got married. This morning my wife cooked me breakfast in bed for the second time in her life, the first being this time last year. In thanks I will cook a three course meal this evening. In unrelated news the BlogSpam service will be retiring the XML/RPC API come 1st January 2015. This means that any/all plugins which have not been updated to use the JSON API will start to fail. Fingers crossed nobody will hate me too much..

9 December 2014

C.J. Adams-Collier: MySQL Meet-up 20141208

I had an enjoyable time last night at Twitter with local MySQL DBAs and developers. We had an attendee who has no experience with SQL or programming at all. She is interested in organizing her collection of recipes and had heard a rumor that MySQL was a good tool to use for this task. She indicated that her desktop runs Windows 7. I think I m going to encourage her to turn her concept in to a community project, as she is not the first person I ve met who wants to organize recipes! We were hosted by Rob at Twitter, who used to work with Lisa back before she retired. He s a member of the site reliability team and keeps the fail whale from rearing its blubbery head. Pizza was provided by my dear friend and long-time open source buddy Gerry Narvaja with the assistance of the folks in the kitchen at Zeek s. We discussed new techniques in the areas of load balancing and high availability. Five nines is no longer the thing that people talk about, instead it s six nines. It s a brave new world out there! I was not the only person who was excited about one of the latest features in MariaDB / MySQL to come out of HP, the high resolution time data types. One of the attendees is an old hand at COBOL and was asking if anyone knows where one can get a COBOL runtime environment. I ve never thought about that before Let me ask the googs Looks like there s an active project called GNU COBOL which is officially part of the GNU project:

25 November 2014

Chris Lamb: Validating Django model attribute assignment

Ever done the following? 
>>> user = User.objects.get(pk=102)
>>> user.superuser = True
>>> user.save()
# Argh, why is this user now not a superuser...
Here's a dirty hack to validate these: 
import sys
from django.db import models
from django.conf import settings
FIELDS =  
EXCEPTIONS =  
    'auth.User': ('backend',),
 
def setattr_validate(self, name, value):
    super(models.Model, self).__setattr__(name, value)
    # Real field names cannot start with underscores
    if name.startswith('_'):
        return
    # Magic
    if name == 'pk':
        return
    k = '%s.%s' % (self._meta.app_label, self._meta.object_name)
    try:
        fields = FIELDS[k]
    except KeyError:
        fields = FIELDS[k] = set(
            getattr(x, y) for x in self._meta.fields
            for y in ('attname', 'name')
        )
    # Field is in allowed list
    if name in fields:
        return
    # Field is in known exceptions
    if  name in EXCEPTIONS.get(k, ()):
        return
    # Always allow Django internals to set values (eg. aggregates)
    if 'django/db/models' in sys._getframe().f_back.f_code.co_filename:
        return
    raise ValueError(
        "Refusing to set unknown attribute '%s' on %s instance. "
        "(Did you misspell %s?)" % (name, k, ', '.join(fields))
    )
# Let's assume we have good test coverage
if settings.DEBUG:
    models.Model.__setattr__ = setattr_validate
Now: 
>>> user = User.objects.get(pk=102)
>>> user.superuser = True
...
ValueError: Refusing to set unknown attribute 'superuser' on auth.User instance. (Did you misspell 'username', 'first_name', 'last_name', 'is_active', 'email', 'is_superuser', 'is_staff', 'last_login', 'password', 'id', 'date_joined')
(Django can be a little schizophrenic on this Model.save()'s update_fields keyword argument validates its fields, as does prefetch_related, but it's taking select_related a little while to land.)

19 November 2014

Dirk Eddelbuettel: R / Finance 2015 Call for Papers

Earlier today, Josh send the text below to the R-SIG-Finance list, and I updated the R/Finance website, including its Call for Papers page, accordingly. We are once again very excited about our conference, thrilled about the four confirmed keynotes, and hope that many R / Finance users will not only join us in Chicago in May 2015 -- but also submit an exciting proposal. So read on below, and see you in Chicago in May! Call for Papers: R/Finance 2015: Applied Finance with R
May 29 and 30, 2015
University of Illinois at Chicago, IL, USA
The seventh annual R/Finance conference for applied finance using R will be held on May 29 and 30, 2015 in Chicago, IL, USA at the University of Illinois at Chicago. The conference will cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure, and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading. Over the past six years, R/Finance has included attendees from around the world. It has featured presentations from prominent academics and practitioners, and we anticipate another exciting line-up for 2015. This year will include invited keynote presentations by Emanuel Derman, Louis Marascio, Alexander McNeil, and Rishi Narang. We invite you to submit complete papers in pdf format for consideration. We will also consider one-page abstracts (in txt or pdf format) although more complete papers are preferred. We welcome submissions for both full talks and abbreviated "lightning talks." Both academic and practitioner proposals related to R are encouraged. All slides will be made publicly available at conference time. Presenters are strongly encouraged to provide working R code to accompany the slides. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages. The conference will award two (or more) $1000 prizes for best papers. A submission must be a full paper to be eligible for a best paper award. Extended abstracts, even if a full paper is provided by conference time, are not eligible for a best paper award. Financial assistance for travel and accommodation may be available to presenters, however requests must be made at the time of submission. Assistance will be granted at the discretion of the conference committee. Please make your submission online at this link. The submission deadline is January 31, 2015. Submitters will be notified via email by February 28, 2015 of acceptance, presentation length, and financial assistance (if requested). Additional details will be announced via the R/Finance conference website as they become available. Information on previous years' presenters and their presentations are also at the conference website. For the program committee:
Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson, Dale Rosenthal,
Jeffrey Ryan, Joshua Ulrich

16 November 2014

John Goerzen: Contemplative Weather

Sometimes I look out the window and can t help but feel this weather is deep. Deep with meaning, with import. Almost as if the weather is confident of itself, and is challenging me to find some meaning within it. This weekend brought the first blast of winter to the plains of Kansas. Saturday was chilly and windy, and overnight a little snow fell. Just enough to cover up the ground and let the tops of the blades of grass poke through. Just enough to make the landscape look totally different, without completely hiding what lies beneath. Laura and I stood silently at the window for a few minutes this morning, gazing out over the untouched snow, extending out as far as we can see. Yesterday, I spent some time with my great uncle and aunt. My great uncle isn t doing so well. He s been battling cancer and other health issues for some time, and can t get out of the house very well. We talked for an hour and a half about news of the family, struggles in life now and in the past, and joys. There were times when all three of us had tears in our eyes, and times when all of us were laughing so loudly. My great uncle managed to stand up twice while I was there this took quite some effort once to give me a huge hug when I arrived, and another to give me an even bigger hug when I left. He has always been a person to give the most loving hugs. He hadn t been able to taste food for awhile, due to treatment for cancer. When I realized he could taste again, I asked, When should I bring you some borscht? He looked surprised, then got a huge grin, glanced at his watch, and said, Can you be back by 3:00? His brother, my grandpa, was known for his beef borscht. I also found out my great uncle s favorite kind of bread, and thought that maybe I would do some cooking for him sometime soon. Today on my way home from church, I did some shopping. I picked up the ingredients for borscht and for bread. I came home, said hi to the cats that showed up to greet me, and went inside. I turned on the radio Prairie Home Companion was on and started cooking. It takes a long time to prepare what I was working on I spent a solid two hours in the kitchen. As I was chopping up a head of cabbage, I remembered coming to what is now my house as a child, when my grandpa lived here. I remembered his borscht, zwiebach, monster cookies; his dusty but warm wood stove; his closet with toys in it. I remembered two years ago, having nearly 20 Goerzens here for Christmas, hosted by the boys and me, and the 3 gallons of borscht I made for the occasion. I poured in some tomato sauce, added some water. The radio was talking about being kind to people, remembering that others don t always have the advantages we do. Garrison Keillor s fictional boy in a small town, when asked what advantages he had, mentioned belonging. Yes, that is an advantage. We all deal with death, our own and that of loved ones, but I am so blessed by belonging to a loving family, two loving churches, a wonderful community. Out came three pounds of stew beef. Chop, chop, slice, plunk into the cast iron Dutch oven. It s my borscht pot. It looks as if it would be more at home over a campfire than a stovetop, but it works anywhere. Outside, the sun came up. The snow melts a little, and the cats start running around even though it s still below freezing. They look like they re having fun playing. I m chopping up parsley and an onion, then wrapping them up in a cheesecloth to make the spice ball for the borscht. I add the basil and dill, some salt, and plonk them in, too. My 6-quart pot is nearly overflowing as I carefully stir the hearty stew. On the radio, a woman who plays piano in a hospital and had dreamed of being on that particular radio program for 13 years finally was. She played with passion and delight I could hear through the radio. Then it s time to make bread. I pour in some warm water, add some brown sugar, and my thoughts turn to Home On The Range. I am reminded of this verse:
How often at night when the heavens are bright
With the light from the glittering stars
Have I stood here amazed and asked as I gazed
If their glory exceeds that of ours.
There s something about a beautiful landscape out the window to remind a person of all the blessings in life. This has been a quite busy weekend actually, a busy month but despite the fact I have a relative that is sick in the midst of it all, I am so blessed in so many ways. I finish off the bread, adding some yeast, and I remember my great uncle thanking me so much for visiting him yesterday. He commented that a lot of younger people have no use for visiting an old geezer like me. I told him, I ve never been like that. I am so glad I could come and visit you today. The best gifts are those that give in both directions, and this surely is that. Then I clean up the kitchen. I wipe down the counters from all the bits of cabbage that went flying. I put away all the herbs and spices I used, and finally go to sit down and reflect. From the kitchen, the smells of borscht and bread start to seep out, sweeping up the rest of the house. It takes at least 4 hours for the borscht to cook, and several hours for the bread, so this will be an afternoon of waiting with delicious smells. Soon my family will be home from all their activities of the day, and I will be able to greet them with a warm house and the same smells I stepped into when I was a boy. I remember this other verse from Home On the Range:
Where the air is so pure, the zephyrs so free,
The breezes so balmy and light,
That I would not exchange my home on the range
For all of the cities so bright.
Today s breeze is an icy blast from the north maybe not balmy in the conventional sense. But it is the breeze of home, the breeze of belonging. Even today, as I gaze out at the frozen landscape, I realize how balmy it really is, for I know I wouldn t exchange my life on the range for anything.

10 November 2014

Neil Williams: On getting NEW packages into stable

There s a lot of discussion / moaning /arguing at this time, so I thought I d post something about how LAVA got into Debian Jessie, the work involved and the lessons I ve learnt. Hopefully, it will help someone avoid the disappointment of having their package missing the migration into a future stable release. This was going to be a talk at the Minidebconf-uk in Cambridge but I decided to put this out as a permanent blog entry in the hope that it will be a useful reference for the future, not just Jessie. Context LAVA relies on a number of dependencies which were at the time all this started NEW to Debian as well as many others already in Debian. I d been running LAVA using packages on my own system for a few months before the packages were ready for use on the main servers (I never actually installed LAVA using the old virtualenv method on my own systems, except in a VM). I did do quite a lot of this on my own but I also had a team supporting the effort and valuing the benefits of moving to a packaged system. At the time, LAVA was based on Ubuntu (12.04 LTS Precise Pangolin) and a new Ubuntu LTS was close (Trusty Tahr 14.04) but I started work on this in 2013. By the time my packages were ready for general usage, it was winter 2013 and much too close to get anything into Ubuntu in time for Trusty. So I started a local repo using space provided by Linaro. At the same time, I started uploading the dependencies to Debian. json-schema-validator, django-testscenarios and others arrived in April and May 2014. (Trusty was released in April). LAVA arrived in NEW in May, being accepted into unstable at the end of June. LAVA arrived in testing for the first time in July 2014. Upstream development continued apace and a regular monthly upload, with some hotfixes in between, continued until close to the freeze. At this point, note that although upstream is a medium sized team, the Debian packaging also has a team but all the uploads were made by me. I planned ahead. I knew that I would be going to Macau for Linaro Connect in February a critical stage in the finalisation of the packages and the migration of existing instances from the old methods. I knew that I would be on vacation from August through to the end of September 2014 including at least two weeks with absolutely no connectivity of any kind. Right at this time, Django1.7 arrived in experimental with the intent to go into unstable and hence into Jessie. This was a headache for me, I initially sought to delay the migration until after Jessie. However, we discussed it upstream, allocated time within the busy schedule and also sought help from within Debian with the RFH tag. Rapha l Hertzog contributed patches for django1.7 support and we worked on those patches upstream, once I was back from vacation. (The final week of my vacation was a work conference, so we had everyone together at one hacking table.) Still there was more to do, the django1.7 patches allowed the unit tests to complete but broke other parts of the lava-server package and needed subsequent tweaks and fixes. Even with all this, the auto-removal from testing for packages affected by RC bugs in their dependencies became very important to monitor (it still is). It would be useful if some packages had less complex dependency chains (I m looking at you, uwsgi) as the auto-removal also covers build-depends. This led to some more headaches with libmatheval. I m not good with functional programming languages, I did have some exposure to Scheme when working on Gnucash upstream but it wasn t pleasant. The thought of fixing a scheme problem in the test suite of libmatheval was daunting. Again though, asking for help, I found people in the upstream team who wanted to refresh their use of scheme and were able to help out. The fix migrated into testing in October. Just for added complications, lava-server gained a few RC bugs of it s own during that time too fixed upstream but awkward nonetheless. Achievement unlocked So that s how a complex package like lava-server gets into stable. With a lot of help. The main problem with top-level packages like this is the sheer weight of the dependency chain. Something seemingly unrelated (like libmatheval) can seriously derail the migrations. The package doesn t use the matheval support provided by uwsgi. The bug in matheval wasn t in the parts of matheval used by uwsgi. It wasn t in a language I am at all comfortable in fixing but it s my name on the changelog of the NMU. That happened because I asked for help. OK, when django1.7 was scheduled to arrive in Debian unstable and I knew that lava was not ready, I reacted out of fear and anxiety. However, I sought help, help was provided and that help was enough to get upstream to a point where the side-effects of the required changes could be fixed. Maintaining a top-level package in Debian is becoming more like maintaining a core package in Debian and that is a good thing. When your package has a lot of dependencies, those dependencies become part of the maintenance workload of your package. It doesn t matter if those are install time dependencies, build dependencies or reverse dependencies. It doesn t actually matter if the issues in those packages are in languages you would personally wish to be expunged from the archive. It becomes your problem but not yours alone. Debian has a lot of flames right now and Enrico encouraged us to look at what else is actually happening in Debian besides those arguments. Well, on top of all this with lava, I also did what I could to help the arm64 port along and I m very happy that this has been accepted into Jessie as an official release architecture. That s a much bigger story than LAVA yet LAVA was and remains instrumental in how arm64 gained the support in the kernel and various upstreams which allowed patches to be accepted and fixes to be incorporated into Debian packages. So a roll call of helpers who may otherwise not have been recognised via changelogs, in no particular order: Also general thanks to the Debian FTP and Release teams. Lessons learnt
  1. Allow time! None of the deadlines or timings involved in this entire process were hidden or unexpected. NEW always takes a finite but fairly lengthy amount of time but that was the only timeframe with any amount of uncertainty. That is actually a benefit it reminds you that this entire process is going to take a significant amount of time and the only loser if you try to rush it is going to be you and your package. Plan for the time and be sceptical about how much time is actually required.
  2. Ask for help! Everyone in Debian is a volunteer. Yes, the upstream for this project is a team of developers paid to work on this code (and largely only this code) but the upstream also has priorities, requirements, objectives and deadlines. It s no good expecting upstream to do everything. It s no good leaving upstream insufficient time to fit the required work into the existing upstream schedules. So ask for help within upstream and within Debian ask for help wherever you can. You don t know who may be able to help you until you ask. Be clear when asking for help how would someone test their proposed fix? Exactly what are you asking for help doing? (Hint: everything is not a good answer.)
  3. Keep on top of announcements and changes. The release team in Debian have made the timetable strict and have published regular updates, guidelines and status notes. As maintainer, it is your responsibility to keep up with those changes and make others in the upstream team aware of the changes and the implications. Upstream will rely on you to provide accurate information about these requirements. This is almost more important than actually providing the uploads or fixes. Without keeping people informed, even asking for help can turn out to be counter-productive. Communicate within Debian too talk to the teams, send status updates to bugs (even if the status is tag 123456 + help).
  4. Be realistic! Life happens around us, things change, personal timetables get torn up. Time for voluntary activity can appear and disappear (it tends to disappear far more often than extends, so take that into account too).
  5. Do not expect others to do the work for you asking for help is one thing, leaving the work to others is quite another. No complaining to the release team that they are blocking your work and avoid pleading or arguing when a decision is made. The policies and procedures within Debian are generally clear and there are quite enough arguments without adding more. Read the policies, read the guidelines, watch how other packages and other maintainers are handled and avoid those mistakes. Make it easy for others to help deliver what you want.
  6. Get to know your dependency chain follow the links on the packages.debian.org pages and get a handle on which packages are relevant to your package. Subscribe to the bug pages for some of the more high-risk packages. There are tools to help. rc-alert can help you spot problems with runtime dependencies (you do have your own package installed on a system running unstable if not, get that running NOW). Watching build-dependencies is more difficult, especially build-dependencies of a runtime dependency, so watch the RC bug lists for packages in your dependency chain.
Above all else, remember why you and upstream want the packages in Debian in the first place. Debian is a respected distribution and has an acknowledged reputation for stability and portability. The very qualities that you and your upstream desire from having your package in Debian have direct implications for the amount of work and the amount of time that will be required to get your packages into Debian and keep them there. Having your package in Debian will bring considerable benefits but you will be required to invest a considerable amount of time. It is this contribution which is valuable to Debian and it is this work which will deliver the benefits you seek. Being an expert in the one package is wildly inadequate. Debian is about the system, the whole distribution and sooner or later, you as the maintainer will be absolutely required to handle something which is so far out of your comfort zone it s untrue. The reality is that you are not expected to fix that problem you are expected to handle that problem and that includes seeking and acknowledging the help of others. The story isn t over until release day. Having your package in testing the day before the freeze is one step. It may be a large step, but it is only one. The status of that package still needs monitoring. That long dependency chain can still come back and bite. Don t wait for problems to surprise you. Finally One thing I do ask is that other upstream teams and maintainers think about the dependency chain they are creating. It may sound nice to have bindings for every interpreted language possible when releasing your compiled library but it does not help people using that library. Yes, it is more work releasing the bindings separately because a stable API is going to be needed to allow version 1.2.3 to work alongside 1.2.2 and 1.3.0 or the entire effort is pointless. Consider how your upstream package migrates. Consider how adding yet another build-dependency for an optional component makes things exponentially harder for those who need to rely on that upstream. If it is truly optional, release it separately and keep backwards compatibility on each side. It is more work but in reality, all that is happening is that the work is being transferred from the distribution (where it helps only that one distribution and causes duplication into other distributions) into the upstream (where it helps all distributions). Think carefully about what constitutes core functionality and release the rest separately. Combining bindings for php, ruby, python, java, lua and xslt into a single upstream release tarball is a complete nonsense. It simply means that the package gets blocked from new uploads by the constant churn of being involved in every transition that occurs in the distribution. There is a very real risk that the package will miss a stable release simply by having fingers in too many pies. That hurts not only this upstream but every upstream trying to use any part of your code. Every developer likes to think that people are using and benefiting from their effort. It s not nice to directly harm the interests of other developers trying to use your code. It is not enough for the binary packages to be discrete migrations happen by source package and the released tarball needs to not include the optional bindings. It must be this way because it is the source package which determines whether version 1.2.3 of plugin foo can work with version 1.2.0 of the library as well as with version 1.3.0. Maintainers regularly deal with these issues so talk to your upstream teams and explain why this is important to that particular team. Help other maintainers use your code and help make it easier to make a stable release of Debian. The quicker the freeze & release process becomes, the quicker new upstream versions can be uploaded and backported.

Lars Wirzenius: A vision of backups in Debian

Meet Alfred. Alfred is a Debian user. He has a laptop with Debian and a desktop environment running on it. Alfred does a lot of impotant things on his computer: his hobby is to photograph his cat, and also he works for a non-governmental organisation that investigates and reports on human rights violations. His job involves a lot of travel to many parts of the world, and he needs to handle a lot of very sensitive information. His laptop uses full-disk encryption, and it's generally speaking very well secured against the various security threats that are due to his job. He is worried about losing important data. He's not too worried that the sensitive information he has will leak if his laptop is stolen, but it might be impossible to re-create the data if the laptop is gone. If he interviews a whistleblower for a slave-trading corporation, and his laptop is stolen after that, it might be impossible to ever meet with the whistleblower again. Alfred wants backups of his data. He gets a USB thumb drive, and plugs it in. The laptop has never seen the drive before, so it asks Alfred if the drive should be used for backups. Alfred says yes. The laptop formats the thumb drive, again with full-disk encryption, and then runs a backup. The backup automatically picks up all the files from Alfred's home directory, and some system confguration files that may be necessary as well. (Read: /home and /etc.) Files that are usually not very precious, such as web browser caches, are automatically excluded. Later, when Alfred wants to update the backup, he plugs in the same drive again. The system recognises the drive, and runs the backup. While the backup is running, Alfred has an indicator in his desktop status bar. If Alfred leaves the drive plugged in, and changes anything in his home directory, that gets immediately backed up to the backup drive. Until the changes have been backed up, the indicator stays on Alfred's status bar. This isn't good enough, however. Alfred needs to carry the USB drive with him, and if he's mugged, he might lose both the laptop and the backup drive. Therefore, the system administrator at Alfred's NGO, Janet, sets up an account on an online backup server, and e-mails Alfred a configuration file, which Alfred drops into the backup system's configuration tool. From then on, whenever Alfred's laptop is online, and can see the backup server (identified by an SSH host key), any changes Alfred makes are backed up as soon as possible. For the next interview, as soon as the interview is finished and Alfred closes the laptop lid to suspend it, the backup has already finished, both to the online server and the USB thumb drive. Alfred is now happy, and no longer fears for the safety of his data. Janet, however, is still a little worried, because the online backup server is an attractive target for attacks. She asks Alfred to configure the backup service on the laptop to encrypt and digitally sign the backups, and sends the master backup public key with the request. Janet keeps the corresponding private key in a secure location. Alfred goes into the configuration dialog, ticks the right box, and drops in the server public key. The backup software generates a new public key for the laptop to use for encrypting the backups, and Alfred e-mails that to Janet, using PGP encrypted and signed e-mail. He also puts the laptop backup encryption keys on a couple of USB thumb drives, which he stores in safe places (in his sock drawer and coffee jar, but don't tell anyone that). Alfred's online backups are now encrypted with public keys so that both Alfred and Janet can decrypt them, but only they can do that. The backups are digitally signed so that if the server is hacked, the backups can't be altered without it being detectable. Some time passes. Alfred needs to go to speak to the general assembly of the Cat Conference, about how awesome his cat is. This requires him to travel to the US, and he's worried that the US authorities will confiscate his laptop and try to get at his work files that way. He deletes all his work files, ssh keys, and other files that aren't necessary to show his cat pictures at the conference. The conference goes fine, and when Alfred comes back home, he gets the USB thumb drive that contains his backup encryption key. He plugs it in, tells the backup configuration software to import it. Alfred can then open his backups on the online backup server in his file browser, and can restore back his files by copying them with drag and drop. However, the next day Alfred's cat, upset at how much he travels, pees on the laptop. It is ruined. Everything is lost. Alfred gets a new laptop from Janet, and installs Debian on it. During installation, Alfred gives the installer the USB backup drive, and the installer restores all of Alfred's own files, and also restores system configuration. After a little while, Alfred has a newly installed laptop with all his usual software and all of his files.
This is a summary of a vision for backups being a service in a default Debian install in the future. It is currently just a vision, and nobody is currently working on making it reality. Would you like to work on this for the release after jessie? (No cats were harmed in the production of this vision.)

9 November 2014

Antti-Juhani Kaijanaho: About to retire from Debian

I got involved with Debian development in, I think, 1998. In early 1999, I was accepted as a Debian developer. The next two or three years were a formative experience for me. I learned both software engineering and massively international collaboration; I also made two major contributions to Debian that are still around (of this, I am very proud). In consequence, being a Debian developer became a part of my identity. Even after my activity lessened more than a decade ago, after I no longer was a carefree student, it was very hard for me to let go. So I ve hung on. Until now. I created my 4096-bit GPG key (B00B474C) in 2010, but never got around to collecting signatures to it. I ve seen other people send me their key transition statements, but I have not signed any keys based on them. It just troubles me to endorse a better secured key based on the fact that I once verified a less secure key and I have a key signature chain to it. For this reason, I have not made any transition statements of my own. I ve been meaning to set up key signing meetings with Debian people in Finland. I never got around to that, either. That, my friends, was my wakeup call. If I can t be bothered to do that, what business do I have clinging on to my Debian identity? My conclusion is that there is none. Therefore, I will be retiring from Debian. This is not a formal notice; I will be doing the formal stuff (including disposing of my packages) separately in the appropriate forums in the near future. I agree with the sentiment that Joey Hess wrote elsewhere: It s become abundantly clear that this is no longer the project I originally joined . Unlike Joey, I think that is a good thing. Debian has grown, a lot. It s not perfect, but like my elementary-school teacher once said: A thing that is perfect was not made by people. Just remember to continue growing and getting better. And keep making the Universal Operating System. Thank you, all.

8 November 2014

Russ Allbery: Another book haul

Someday there will be reviews. Also, software releases. But these posts are much easier to write in the evening when my brain is fried. Also, the anticipation of reading good books is delightful. The motivating reason for this order was that Powell's was giving away $10 gift cards with an order, so I bought books to buy more books later. Iain M. Banks Feersum Endjinn (sff)
Jacqueline Carey Autumn Bones (sff)
Robert Caro The Path to Power (non-fiction)
Keith Houston Shady Characters (non-fiction)
Jan Morris Hav (mainstream)
Arika Okrent In the Land of Invented Languages (non-fiction) I've been in a non-fiction mood lately, so lots of random non-fiction here. The Caro is the first volume of his huge biography of LBJ, which is apparently one of the best biographies ever written. The other non-fiction is less serious: one about intentionally-created languages, and the other about the history of punctuation characters. Hav is a travel book about a city that doesn't actually exist, so it fits somewhat with the non-fiction theme.

6 November 2014

Daniel Kahn Gillmor: GnuPG 2.1.0 in debian experimental

Today, i uploaded GnuPG 2.1.0 into debian's experimental suite. It's built for amd64 and i386 and powerpc already. You can monitor its progress on the buildds to see when it's available for your architecture. ChangesGnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. GnuPG users who don't have this capability available won't be able to communicate with End-To-End users. There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all. One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring. I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use. Timing for debian The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment. If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you. Long term migration concerns GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently. In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now. In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow: And GnuPG 2.1.0 drops support for the older, known-weak OpenPGPv3 key formats. This is an important step for simplification, but there are a few people who probably still need to use v3 keys for obscure/janky reasons, or have data encrypted to a v3 key that they need to be able to decrypt. Those people will want to have GnuPG 1.4 around. Call for testing Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install gnupg2 and its friends from experimental. If you want to be sensibly conservative, i recommend backing up ~/.gnupg before trying to use it: 
cp -aT .gnupg .gnupg.bak
sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemon
If you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed. Tags: ecc, experimental, gnupg

Michal &#268;iha&#345;: Weblate 2.0

Weblate 2.0 has been released today. It comes with lot of improvements in backend and completely new user interface. Full list of changes for 2.0: You can find more information about Weblate on http://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://hosted.weblate.org/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English phpMyAdmin SUSE Weblate 0 comments Flattr this!

5 November 2014

Rapha&#235;l Hertzog: My Free Software Activities in October 2014

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Packaging work With the Jessie freeze approaching, I took care of packaging some new upstream releases that I wanted to get in. I started with zim 0.62, I had skipped 0.61 due to some annoying regressions. Since I had two bugs to forward, I took the opportunity to reach out to the upstream author to see if he had some important fixes to get into Jessie. This resulted in me pushing another update with 3 commits cherry picked from the upstream VCS. I also sponsored a wheezy-backports of the new version. I pushed two new bugfixes releases of Publican (4.2.3 and 4.2.6) but I had to include a work-around for a bug that I reported earlier on docbook-xml (#763598: the XML catalog doesn t allow libxml2/xmllint to identify the local copy of some entities files) and that is unlikely to be fixed in time for Jessie. Last but not least, I pushed the first point release of Django 1.7, aka version 1.7.1 to unstable and asked release managers to ensure it migrates to testing before the real freeze. This is important because the closer we are to upstream, the easier it is to apply security patches during the lifetime of Jessie (which will hopefully be 5 years, thanks to Debian LTS!). I also released a backport of python-django 1.7 to wheezy-backports. I sponsored galette 0.7.8+dfsg-1 fixing an RC bug so that it can get back to testing (it got removed from testing due to the bug). Debian LTS See my dedicated report for the paid work I did on that area. Apart from that, I took some time to get in touch with all the Debian consultants and see if they knew some companies to reach out. There are a few new sponsors in the pipe thanks to this, but given the large set of people that it represents, I was expecting more. I used this opportunity to report all bogus entries (i.e bouncing email, broken URL) to the maintainer of the said webpage. Distro Tracker Only 30 commits this month, with almost no external contribution, I m a bit saddened by this situation because it s not very difficult to contribute to this project and we have plenty of easy bugs to get you started. That said I m still happy with the work done. Most of the changes have been made for Kali but will be useful for all derivatives: it s now possible to add external repositories in the tracker and not display them in the list of available versions, and not generate automatic news about those repositories. There s a new derivative application which is only in its infancy but can already provide a useful comparison of a derivative with its parent. See it in action on the Kali Package Tracker: http://pkg.kali.org/derivative/ Thanks to Offensive Security which is sponsoring this work! Since I have pushed Django 1.7 to wheezy-backports, all distro tracker instances that I manage are now running that version of Django and I opted to make that version mandatory. This made it possible to add initial Django migrations and rely on this new feature for future database schema upgrade (I have voluntarily avoided schema change up to now to avoid problems migrating from South to Django migrations). Thanks See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

3 November 2014

Hideki Yamane: gbp buildpackage fail: cannot find orig.tar.gz file

Dear Lazyweb,

I had already asked before in Jan but I got same issue. "gbp buildpackage" command fails...
rm -f ng
make[2]: Leaving directory '/home/henrich/src/pkg-java/nailgun'
rm /home/henrich/src/pkg-java/nailgun/ng-nailgun
rm: cannot remove '/home/henrich/src/pkg-java/nailgun/ng-nailgun': No such file or directory
debian/rules:16: recipe for target 'override_dh_auto_clean' failed
make[1]: [override_dh_auto_clean] Error 1 (ignored)
make[1]: Leaving directory '/home/henrich/src/pkg-java/nailgun'
dh_clean
gbp:info: Orig tarball 'nailgun_0.9.1.orig.tar.gz' not found at '../tarballs/'
Use of uninitialized value $_[0] in substitution (s///) at /usr/share/perl/5.20/File/Basename.pm line 341.
fileparse(): need a valid pathname at /usr/bin/pristine-tar line 417.
pristine-tar: failed to generate tarball
gbp:error: Couldn't checkout "nailgun_0.9.1.orig.tar.gz": it exited with 255
There IS orig tarball in ../tarballs directory and it works with copying all files to another directory as before...
Yes, and just "cp -arp libspiro /tmp/; cd /tmp/libspiro" and
gbp buildpackage works... (why?)
What causes this and is the best way to solve it?

2 November 2014

Thomas Goirand: OpenStack packaging activity: October 2014

Wednesday 1:
Uploaded python-xstatic-jquery removing the .pth file from package.
Uploaded python-taskflow 0.4 to experimental, needed by Cinder Juno RC1
Uploaded Cinder Juno RC1 to experimental Thuesday 2:
Finally understood that the issue with murano-dashboard was that it doesn t build without django-nose >= 1.2. Opened new patch at: https://review.openstack.org/125565
Uploaded murano-dashboard to Experimental, now using django-nose from wheezy-backports in my jenkins setup, so murano-dashboard can be built for Wheezy.
Uploaded python-oslotest 1.1.0.0 (really is upstream 1.1.0)
Uploaded python-oslo.serialization 1.0.0-1 (needed by Ceilometer Juno RC1)
Uploaded Ceilometer Juno RC1
Uploaded Heat Juno RC1
Uploaded oslo.rootwrap 1.3.0.0
Uploaded oslo.db 1.0.2 (bugfix release)
Wrote a new system in openstack-pkg-tools to generate init scripts and. service files from a template, so we don t have to write N times the same thing. Friday 3:
Reworked openstack-pkg-tools to generate automatically sysv-rc init scripts, upstart jobs and systemd unit files, making the system more unified and consistent.
Applied the new system to all packages in Juno.
Uploaded Keystone 2014.1.3-1 to Sid
Uploaded Nova 2014.1.3-1 to Sid
Uploaded Glance 2014.1.3-1 to Sid
Uploaded Neutron 2014.1.3-1 to Sid
Uploaded Horizon 2014.1.3-1 to Sid
Uploaded Cinder 2014.1.3-1 to Sid
Uploaded Trove 2014.1.3-1 to Sid
Uploaded Ceilometer 2014.1.3-1 to Sid Saturday 4:
Uploaded Horizon Juno RC1 to Experimental
Uploaded oslotest 1.1.0.0 to Experimental
Uploaded Ironic Juno RC1 to Experimental
Uploaded Designate Juno RC1 to Experimental
Uploaded Nova Juno RC1 to Experimental
Uploaded Neutron Juno RC1 to Experimental
Uploaded openstack-meta-packages 0.10 to Sid
Uploaded openstack-pkg-tools 13 to Experimental
Uploaded murano-agent Juno RC1 to Experimental Sunday 5:
Uploaded Sahara Juno RC1 to Experimental (it s been approved by FTP masters)
Uploaded Murano Juno RC1 to Experimental (it s been approved by FTP masters)
Fixed all debian/watch file to understand ~b and ~rc releases (fixed applied on both Icehouse and Juno branches, though no upload yet, I ll wait until uploads are needed to have this in the archive ).
Uploaded Trove Juno RC1 to Experimental
Uploaded Sahara Juno RC1 to Experimental With this last upload, everything of Juno RC1 is in Debian Experimental! \o/ Monday 6:
Uploaded some fixes for Nova 2014.1.3-2 in Sid:
* Removed contrib/boto_v6/* in debian/copyright, replaced bin/nova-manage by nova/cmd/ baremetal_, manage.py.
* Mangling upstream rc and beta versions in watch file.
* Added 9990_update_german_programm_messages.patch, thanks to Helge Kreutzmann <debian@helgefjell.de>.
* Fixed correct de.po (Closes: #763682).
* Added nl.po initial Debconf translation, thanks to Frans Spiesschaert <Frans.Spiesschaert@yucom.be> (Closes: #764125).
* Standards-Version is now 3.9.6 (no change).
Upstreamed german translation of po file: https://review.openstack.org/126212
Uploaded Designate 2014.1-12 to Sid, added new de.po also to the Juno branch on alioth (but didn t upload the fix yet).
Uploaded sphinxcontrib-httpdomain new upstream 1.3.0 release, added Python 3.x support to the package, and transitionning to the correct namespaced python-sphinxcontrib.httpdomain package name.
Spent most of the day fixing python-xstatic issues:
o uploaded libjs-twitter-bootstrap-datepicker 1.3.1
o uploaded python-xstatic-bootstrap-datepicker requiring this libjs package
o fixed python-xstatic-jquery-ui package
Now Horizon Juno RC1 builds well, and can be installed again. \o/ Tuesday 7:
Backported python-libvirt 1.2.8 in Wheezy (for Nova Juno support )
Uploaded Ceilometer Juno RC1 with ceilometer-agent-ipmi added (the package will therefore go through the NEW queue).
Uploaded python-requestbuilder 0.2.2-1, needed by the maintainers of euca2ools.
Ported the unified generated init system scripts to Icehouse packages.
Uploaded to Sid updates for: openstack-pkg-tools, ceilometer, cinder, glance, keystone, cinder, nova. Wednesday 8:
Uploaded openstack-pkg-tools 16 to Sid
Uploaded murano-dashboard (with upstream fix to remove font-awesome, which was the reason for FTP master s rejection)
Uploaded ceilometer Juno RC1 with new IPMI agent package (needed for Ironic support).
Uploaded heat 2014.1.3 which I forgot.
Tested https://review.openstack.org/#/c/126777/ which solves the bug I sent to launchpad and approved the patch.
Uploaded python-requestbuilder 0.2.3 Thesday 9:
Worked on fixing Neutron Alembic migration with SQLite3.
Uploade Neutron 2014.2~rc1-3 with a fix for a patch that was destroying dhcp.py. This still doesn t include the Alembic migration fixes, which are still a WIP. Firday 10:
Finished fixing Neutron SQLite 3 Alembic migrations.
Uploaded neutron 2014.2~rc1-3 with the fixes.
Fixed Ceilometer wrong generation of sample config file, using upstream patch (after discussing with Julien Danjou so he wrote it).
Uploaded Ceilometer 2014.2~rc1-4 with the fix
Checked that all packages can be installed in non-interactive mode. This works well now! \o/ Saturday 11:
Uploaded new version of python-xstatic-angular-cookies (ie: 1.2.24.1-2) which allows a higher version of libjs-angularjs (otherwise the package is not installable in Sid/Jessie since last version of angularjs is uploaded). Sunday 12:
Uploaded factory-boy fix for FTBFS
Uploaded python-django-appconf FTBFS
Uploaded Horizon Juno RC2
Uploaded Heat Juno RC3
Uploaded Trove Juno RC2
Uploaded Glance Juno RC2
Uploaded Sahara Juno RC2
Uploaded Nova Juno RC2
Uploaded Neutron Juno RC2
Uploaded Cinder Juno RC2
Uploaded murano-dashboard Juno RC2 Monday 13:
Uploaded python-heatclient 0.2.12-1 to Experimental
Uploaded python-yaql with RC bugfix to Sid (missing dep on python3-ply). Thuesday 14:
Fixed arping newly added dependency in Neutron
Started testing install of all of openstack Juno at once Wednesday 15:
Fixed missing configuration files in Ceilometer (ceilometer-api couldn t start)
Upgraded to Ceilometer Juno RC3.
Backported python-setuptools, as keystone and others are broken due to the namespace of modules not working correctly with the old version of python-pkg-resources. With the new one, everything is back in order. Thesday 16:
Uploaded to Debian Experimental the final release of Juno (ie: 2014.2) for:
Sahara
Nova
Ceilometer
Cinder
Heat
Neutron
Glance
Keystone
Horizon (with fix for Django 1.7 in the wsgi file)
Uploaded to Sid:
Swift 2.2.0
Horizon 2014.1.3-3 with fix for Django 1.7 in the wsgi file that was crashing apache. OpenStack Juno packages are out!!! (ready the day of the upstream release ) Friday 17:
Investigated Trove RC bug #765348, couldn t reproduce, and therefore closed it.
Uploaded Ironic Juno final to Experimental
Uploaded Designate Juno final to Experimental
Uploaded a fix for python-jingo which failed to build with Django 1.7. Sent pull request upstream: https://github.com/jbalogh/jingo/pull/63
Uploaded CVE-2014-7230 & CVE-2014-7231 fixes for both Cinder and Nova in Debian Sid, as per OSSA 2014-036 patches. No need to upload a fix for Trove, as 2014.1.3 already has the fixes. Saturday 18:
Started building Trusty packages
Fixed oslo-config so that it never depends on python3-argparse, which doesn t exist (uploaded to Experimental)
Uploaded python-django-pyscss 1.0.3-2 with python-simplejson now as build-depends (it failed to build in my Trusty jenkins without it).
Uploaded a fix for stevedore and oslo-config to not depends on python3-argparse in Ubuntu (added debian/py3dist-overrides) Sunday 19:
Uploaded python-taskflow with ordereddict in debian/pydist-overrides.
Backported JS packages for Horizon and libvirt for Trusty (from Sid). My new Jenkin server is now producing a full set of Juno packages for Ubuntu trusty. And of course, it s updated on each git push, just like for the Wheezy backports. Monday 20:
Added FORCE_COULEUR=1 when running tests in python-couleur, so that it doesn t fail when running with git-buildpackage. Uploaded result in Sid.
Fixed python-mockito so that it never downloads distribute or nose on its clean target, which was annoying when running git-buildpackage. Uploaded to Sid.
Started to work again on automatic package deployment using openstack-deploy, from the openstack-meta-packages source package. Thuesday 21, Wednesday 22:
Worked on testing packages, did couples of minor fixes, reworked some of the default configuration files to match the install-guide, move configuration directive to the correct new section in nova.conf, etc. Thursday 23:
Patch the Neutron chapter in the install-guide to take into account the changes done on Thuesday 21, Wednesday 22, and simplify the install procedure in Debian. https://review.openstack.org/#/c/130501/ Friday 24:
Busy packing my stuff for moving to France Not much packaging work, except more auto-deploy stuff and some tests. Saturday 25:
Uploaded Nova, Neutron, Cinder and Horizon Icehouse in Sid, including some debconf translation updates, beating the Jessie freeze deadline in 10 days.
Fixed and uploaded openstack-debian-images in Sid: the login option wasn t modifying the default sudoers file, which always contained debian , instead of the custom login. Sunday 26:
Traveled to Moscow Monday 27 & Tuesday 28:
Fixed some murano & murano-dashboard stuff, thanks to the help of some murano team members in Moscow office. Uploaded fixes for murano & murano-dashboard. Tested that murano-dashboard works well, and now it does! :)
Uploaded version dependency fixes for python-xstatic-angular-cookies and python-xstatic-d3 which couldn t be installed in Sid/Jessie because of libjs-* updates. Wednesday 29:
Meeting with Saratov team
Updated sahara endpoints, but didn t upload the package yet to Debian. Thursday 30:
Uploaded ruby-raemon needed for Astute (part of Fuel web).
Packaged ruby-symboltable (not uploaded yet). Friday 31:
Wrote unit test runner for python-webpy (the current package doesn t have unit test runs).
Uploaded python-dbutils (needed by python-web.py unit tests) to Sid: now in NEW queue
Uploaded python-nose-parametrized & python-nose-timer to Sid: now in NEW queue
Uploaded sahara -2 fixing the API endpoint registration URL and service name.
Uploaded python-sphinxcontrib.plantuml to Sid: : now in NEW queue

26 October 2014

Pau Garcia i Quiles: FOSDEM 2015 Desktops DevRoom Call for Talks

FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as CrossDesktop DevRoom ), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2014 schedule might give you some inspiration. Please include the following information when submitting a proposal: The deadline for submissions is December 7th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will take place on Sunday, February 1st 2015. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create a new Pentabarf account if you already have one from past years). You can also join the devroom s mailing list, which is the official communication channel for the DevRoom: desktops-devroom@lists.fosdem.org (subscription page for the mailing list) The Desktops DevRoom 2015 Organization Team

24 October 2014

Stefano Zacchiroli: Italy puts Free Software first in public sector

Debian participation in Italy's CAD68 committee (The initial policy change discussed in this document is a couple of years old now, but it took about the same time to be fully implemented, and AFAIK the role Debian played in it has not been documented yet.) In October 2012 the Italian government, led at the time by Mario Monti, did something rather innovative, at least for a country that is not usually ahead of its time in the area of information technology legislation. They decided to change the main law (the "CAD", for Codice dell'Amministrazione Digitale) that regulates the acquisition of software at all levels of the public administration (PA), giving an explicit preference to the acquisition of Free Software. The new formulation of article 68 of the CAD first lists some macro criteria (e.g., TCO, adherence to open standards, security support, etc.) that public administrations in Italy shall use as ranking criteria in software-related calls for tenders. Then, and this is the most important part, the article affirms that the acquisition of proprietary software solutions is permitted only if it is impossible to choose Free Software solutions instead; or, alternatively, to choose software solutions that have already being acquired (and paid for) by the PA in the past, reusing preexisting software. The combined effect of these two provisions is that all new software acquisitions by PAs in Italy will be Free Software, unless it is motivated in writing, challengable by a judge that it was impossible to do otherwise. Isn't it great? It is, except that such a law is not necessarily easy to adhere to in practice, especially for small public administrations (e.g., municipalities of a few hundred people, not uncommon in Italy) which might have very little clue about software in general, and even less so about Free Software. This is why the government also tasked the relevant Italian agency to provide guidelines on how to choose software in a way that conforms with the new formulation of article 68. The agency decided to form a committee to work on the guidelines (because you always need a committee, right? :-) ). To my surprise, the call for participation to be part of the committee explicitly listed representatives of Free Software communities as privileged software stakeholders that they wanted to have on the committee kudos to the agency for that. (The Italian wording on the call was: Costituir titolo di preferenza rivestire un ruolo di [ ] referenti di community del software a codice sorgente aperto.) Therefore, after various prods by fellow European Free Software activists that were aware of the ongoing change in legislation, I applied to be a volunteer CAD68 committee member, got selected, and ended up working over a period of about 6 months (March-September 2013) to help the agency writing the new software acquisition guidelines. Logistically, it hasn't been entirely trivial, as the default meeting place was in Rome, I live in Paris, and the agency didn't really have a travel budget for committee members. That's why I've sought sponsorship from Debian, offering to represent Debian views within the committee; Lucas kindly agreed to my request. So what did I do on behalf of Debian as a committee member during those months? Most of my job has been some sort of consulting on how community-driven Free Software projects like Debian work, on how the software they produce can be relied upon and contributed to, and more generally on how the PA can productively interact with such projects. In particular, I've been happy to work on the related work section of the guidelines, ensuring they point to relevant documents such as the French government guidelines on how to adopt Free Software (AKA circulaire Ayrault). I've also drafted the guidelines section on Free Software directories, ensuring that important resources such as FSF's Free Software Directory are listed as starting points for PAs that looking for software solutions for specific needs. Another part of my job has been ensuring that the guidelines do not end up betraying the principle of Free Software preference that is embodied in article 68. A majority of committee members came from a Free Software background, so that might not seem a difficult goal to accomplish. But it is important to notice that: (a) the final editor of the guidelines is the agency itself, not the committee, so having a "pro-Free Software" majority within the committee doesn't mean much per se; and (b) lobbying from the "pro-proprietary software" camp did happen, as it is entirely natural in these cases. In this respect I'm happy with the result: I do believe that the software selection process recommended by the guidelines, finally published in January 2014, upholds the Free Software preference principle of article 68. I credit both the agency and the non-ambiguity of the law (on this specific point) for that result. All in all, this has been a positive experience for me. It has reaffirmed my belief that Debian is a respected, non-partisan political actor of the wider software/ICT ecosystem. This experience has also given me a chance to be part of country-level policy-making, which has been very instructive on how and why good ideas might take a while to come into effect and influence citizen lives. Speaking of which, I'm now looking forward to the first alleged violations of article 68 in Italy, and how they will be dealt with. Abundant popcorn will certainly be needed. Links & press If you want to know more about this topic, I've collected below links to resources that have documented, in various languages, the publication of the CAD68 guidelines.

9 October 2014

Jan Wagner: Updated Monitoring Plugins Version is coming soon

Three months ago version 2.0 of Monitoring Plugins was released. Since then many changes were integrated. You can find a quick overview in the upstream NEWS. Now it's time to move forward and a new release is expected soon. It would be very welcome if you could give the latest source snapshot a try. You also can give the Debian packages a go and grab them from my 'unstable' and 'wheezy-backports' repositories at http://ftp.cyconet.org/. Right after the stable release, the new packages will be uploaded into Debian unstable. The whole packaging changes can be observed in the changelog. Feedback is very appreciated via Issue tracker or the Monitoring Plugins Development Mailinglist. Update: The official call for testing is available.

8 October 2014

Jan Wagner: Updated Monitoring Plugins Version is coming soon

Three months ago version 2.0 of Monitoring Plugins was released. Since then many changes were integrated. You can find a quick overview in the upstream NEWS. Now it's time to move forward and a new release is expected soon. It would be very welcome if you could give the latest source snapshot a try. You also can give the Debian packages a go and grab them from my 'unstable' and 'wheezy-backports' repositories at http://ftp.cyconet.org/. Right after the stable release, the new packages will be uploaded into Debian unstable. The whole packaging changes can be observed in the changelog. Feedback is very appreciated via Issue tracker or the Monitoring Plugins Development Mailinglist.

Next.

Previous.