The Linux Security Summit is happening in Chicago August 18th and 19th, just before LinuxCon. Send us some presentation and topic proposals, and join the conversation with other like-minded people. :) I d love to see what people have been working on, and what they d like to work on. Our general topics will hopefully include:

• System hardening
• Access control
• Cryptography
• Integrity control
• Hardware security
• Networking
• Storage
• Virtualization
• Desktop
• Tools
• Management
• Case studies
• Emerging technologies, threats & techniques

The Call For Participation closes June 6th, so you ve got about a month, but earlier is better.

2014, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

As promised, today I would like to write a bit about the making of The Hacker's Guide to Python. It has been a very interesting experimentation, and I think it is worth sharing it with you. The inspiration All started out at the beginning of August 2013. I was spending my summer, as the rest of the year, hacking on OpenStack. As years passed, I got more and more deeply involved in the various tools that we either built or contributed to within the OpenStack community. And I somehow got the feeling that my experience with Python, the way we used it inside OpenStack and other applications during these last years was worth sharing. Worth writing something bigger than a few blog posts. The OpenStack project is doing code reviews, and therefore so did I for almost two years. That inspired a lot of topics, like the definitive guide to method decorators that I wrote at the time I started the hacker's guide. Stumbling upon the same mistakes or misunderstanding over and over is, somehow, inspiring. I also stumbled upon Nathan Barry's blog and book Authority which were very helpful to get started and some sort of guideline. All of that brought me enough ideas to start writing a book about Python software development for people already familiar with the language. The writing The first thing I started to do is to list all the topics I wanted to write about. The list turned out to have subjects that had no direct interest for a practical guide. For example, on one hand, very few developers know in details how metaclasses work, but on the other hand, I never had to write a metaclass during these last years. That's the kind of subject I decided not to write about, dropped all subjects that I felt were not going to help my reader to be more productive. Even if they could be technically interesting.

Then, I gathered all problems I saw during the code reviews I did during these last two years. Some of them I only recalled in the days following the beginning of that project. But I kept adding them to the table of contents, reorganizing stuff as needed. After a couple of weeks, I had a pretty good overview of the contents that there I will write about. All I had to do was to fill in the blank (that sounds so simple now). The entire writing of the took hundred hours spread from August to November, during my spare time. I had to stop all my other side projects for that. The interviews While writing the book, I tried to parallelize every thing I could. That included asking people for interviews to be included in the book. I already had a pretty good list of the people I wanted to feature in the book, so I took some time as soon as possible to ask them, and send them detailed questions. I discovered two categories of interviewees. Some of them were very fast to answer ( 1 week), and others were much, much slower. A couple of them even set up Git repositories to answer the questions, because that probably looked like an entire project to them. :-) So I had to not lose sight and kindly ask from time to time if everything was alright, and at some point started to kindly set some deadline. In the end, the quality of the answers was awesome, and I like to think that was because I picked the right people! The proof-reading Once the book was finished, I somehow needed to have people proof-reading it. This was probably the hardest part of this experiment. I needed two different types of reviews: technical reviews, to check that the content was correct and interesting, and language review. That one is even more important since English is not my native language. Finding technical reviewers seemed easy at first, as I had ton of contacts that I identified as being able to review the book. I started by asking a few people if they would be comfortable reading a simple chapter and giving me feedbacks. I started to do that in September: having the writing and the reviews done in parallel was important to me in order to minimize latency and the book's release delay. All people I contacted answered positively that they would be interested in doing a technical review of a chapter. So I started to send chapters to them. But in the end, only 20% replied back. And even after that, a large portion stopped reviewing after a couple of chapters. Don't get me wrong: you can't be mad at people not wanting to spend their spare time in book edition like you do. However, from the few people that gave their time to review a few chapters, I got tremendous feedback, at all level. That's something that was very important and that helped a lot getting confident. Writing a book alone for months without having anyone taking a look upon your shoulder can make you doubt that you are creating something worth it. As far as English proof-reading, I went ahead and used ODesk to recruit a professional proof-reader. I looked for people with the right skills: a good English level (being a native English speaker at least), be able to understand what the book was about, and being able to work with correct delays. I had mixed results from the people I hired, but I guess that's normal. The only error I made was not to parallelize those reviews enough, so I probably lost a couple of months on that. The toolchain

While writing the book, I did a few breaks to build a toolchain. What I call a toolchain is set of tools used to render the final PDF, EPUB and MOBI files of the guide. After some research, I decided to settle on AsciiDoc, using the DocBook output, which is then being transformed to LaTeX, and then to PDF, or either to EPUB directly. I realy on Calibre to convert the EPUB file to MOBI. It took me a few hours to do what I wanted, using some magic LaTeX tricks to have a proper render, but it was worth it and I'm particularly happy with the result. For the cover design, I asked my talented friend Nicolas to do something for me, and he designed the wonderful cover and its little snake! The publishing Publishing in an interesting topic people kept asking me about. This is what I had to answer a few dozens of time:

• "Who is your editor?"
• "Me."

I never had any plan for asking an editor to publish this book. Nowadays, asking an editor to publish a book feels to me like asking a major company to publish a CD. It feels awkward. However, don't get me wrong: there can be a few upsides of having an editor. They will find reviewers and review your book for you. Having the book review handled for you is probably a very good thing, considering how it was hard to me to get that in place. It can be especially important for a technical book. Also, your book may end up in brick and mortar stores and be part of a collection, both improving visibility. That may improve your book's selling, though the editor and all the intermediaries are going to keep the largest amount of the money anyway.

• "Oh, you will publish it yourself, great. So you will print it and sell it to people?"
• "Not really."

I've heard good stories about people using Gumroad to sell electronic contents, so after looking for competitors in that market, I picked them. I also had the idea to sell the book with Bitcoins, so I settled on Coinbase, because they have a nice API to do that. Setting up everything was quite straight-forward, especially with Gumroad. It only took me a few hours to do so. Writing the Coinbase application took a few hours too.

• "Oh, you will sell it only as an ebook? That's too bad. You need a paper version. Many people will want a paper version."

My initial plan was to only sell online an electronic version. On the other hand, since I kept hearing that a printed version should exist, I decided to give it a try. I chose to work with Lulu because I knew people using it, and it was pretty simple to set up. The launch Once I had everything ready, I built the selling page and connected everything between Mailchimp, Gumroad, Coinbase, Google Analytics, etc. Writing the launch email was really exciting. I used Mailchimp feature to send the launch mail in several batches, just to have some margin in case of a sudden last minute problem. But everything went fine. Hurrah! I distributed around 200 copies of the ebook in the first 48 hours, for about $5000. That covered all the cost I had from the writing the book, and even more, so I was already pretty happy with the launch.

Retrospective In retrospect, something that I didn't do the best way possible is probably to build a solid mailing list of people interested, and to build an important anticipation and incentive to buy the book at launch date. My mailing list counted around 1500 people subscribed because they were interested in the launch of the book subscribed; in the end, probably only 10-15% of them bought the book during the launch, which is probably a bit lower than what I could expect. But more than a month later, I distributed in total almost 500 copies of the book (including physical units) for more than $10000, so I tend to think that this was a success. I still sell a few copies of the book each weeks, but the number are small compared to the launch. I sold less than 10 copies of the ebook using Bitcoins, and I admit I'm a bit disappointed and surprised about that. Physical copies represent 10% of the book distribution. It's probably a lot lower than most people that pushed me to do it thought it would be. But it is still higher of what I thought it would be. So I still would advise to have a paperback version of your book. At least because it's nice to have it in your library.

I only got positive feedbacks, a few typo notices, and absolutely no refund demand, which I really find amazing. The good news is also that I've been contacted with a couple of Korean and Chinese editors to get the book translated and published in those countries. If everything goes well, the book should be translated in the upcoming months and be available on these markets in 2015! If you didn't get a copy, it's still time to do so!

TL;DR This key is no longer usable:

pub  2048R/9C6C32C7 2014-02-16 Laura ARJONA REINA <larjona99@gmail.com>
                               Laura ARJONA REINA <larjona@fsfe.org>
                               Laura ARJONA REINA <laura.arjona@upm.es>
                               Old key 0xE20474C3 no longer valid: lost secret key. (Clave antigua 0xE20474C4 ya no es v lida: clave secreta perdida.)
Fingerprint=F29B A6D8 D1DC A30F 3E34  53DF 5CD1 FDE5 9C6C 32C7

Please act as if it does not exist. The reason is that I cannot remember the passphrase of my master GPG key. This is why I didn t signed any of the keys of people that I met in Barcelona MiniDebconf. My geek self steem is a bit undermined, but feeling sorry for myself accomplishes nothing, so I think I will not hide problems and move on. I ll post about my new key soon. Long version The bad news The bad news are many. I generated my key in February 2014 (I generated my very first GPG Key in 2010, as an exercise, but never used it again, and in 2014 I couldn t remember the passphrase, and the paper where it was written, had got lost before). Anyway, February 2014, new GPG key. I followed the Howto in FSFE wiki in order to use my brand new FSFE SmartCard. I have to admit that I didn t understand very well how all this works, and it seems that my main mistake was to miss-understand that since I was using a smartcard, with a PIN and an Admin PIN, remembering passphrases was no longer required (only remembering the PINs). I was WRONG! PINs are for daily use with the subkeys of your card (for encryption, decryption, and signing stuff different than GPG keys), you still have the master key that is not in the card (but in a separate medium in a safe place), and for the master key we still use passphrase, and the master key is the one that allows signing keys from other people, and changing, revoking, adding subkeys, etc. So, it seems I used a random passphrase that I didn t write down and I could not remember, due to this terrible missunderstanding. Another bad news is that I didn t generate a revocation certificate (well in fact, I was going to generate just before signing the first key of another person, and then I realize that it was asking the passphrase, hence the problem). First I thought that it should ask the PIN and my smartcard setup was wrong or anything, but after reading and interchanging emails with other people more experienced than me, I realized that I should remember that passphrase. And I couldn t. So there are no revocation certificates :( Another bad news is that some (awesome) people already signed my key, and it will be difficult to meet again so they sign my new key. I was thinking about applying to the Debian new member process this summer, and I have not many opportunities to meet Debian people in person, so I gathered quite a lot signs last March in MiniDebConf Barcelona. Now I m again at the starting point (well, this is perfect excuse to try to join a Debian event soon :) I don t know how I would manage to do it, but I ll try!). The good news (Always look at the bright side of life ) The main good news is that I didn t used the GPG key for signing/encrypting important stuff: I just interchanged some encrypted mail as test with friends, and signed some mails sent to public mailing lists (for signing mails I was using the smartcard PIN so I didn t notiece the problem). The other main good news is that my key is not compromised (well, you can never be sure, but I think so). I cannot revoke it but I m quite sure nothing important depends on that key. Other good news is that I have read a lot about how GPG works and how the smartcard works, keys and subkeys and all this stuff, and I think now I understand everything quite better. I have learned (and also tried) tools as nasty, John The Ripper and rephrase to try to recover the passphrase. I didn t recover it, but at least I know that all those (free software) tools exist and how to use them :) And I have learned the lesson: to be extremely careful, test that everything works (not just try one or two things, test everything) and to not leave work for later (and for example, generate the revocation certificates just right after the keys). Next steps I ll send a message to all the friends that signed or downloaded my old GPG key apologysing and pointing to this blog post so they learn the details about why I create a new key. I ll take this opportunity to download and use the Tails (The Agnostic Incognito System, a Debian derivative which is a live system and is focused in protecting privacy and anonymity of the user). Tails will be my safe, network disconnected environment to generate the new keys and do the sensible tasks with them. I think this time I will create my main key 4096-bit long (since now I understand that the main key is not stored in the card) and the subkeys can be 2048-bit or 3072 to fit in the smarcard. Well, hands on! I ll write another blog post when my new GPG keys are ready. I hope third time s the charm! Note: Thank you to all the people that gave me advice and support (knowledge, links, moral support) about this issue. You know who you are!
Filed under: My experiences and opinion, Tools Tagged: Debian, encryption, English, Free Software, gpg, libre software, Moving into free software, mswl-cases

There is a strange bug in Planet Debian I am seeing since I joined. It is rather minor, but since it is an accessibility bug, I'd like to mention it here. I have written to the Planet Debian maintainers, and was told to figure it out myself. This is a pattern, accessibility is considered wishlist, apparently. And the affected people are supposed to fix it on their own. It is better if I don't say anything more about that attitude.

I have been looking for an App like this since I got my first iOS device in december 2011. Finally, it is here! A single-player (bot-driven) poker app for iOS, THETA Poker Pro, fully accessible and usable with VoiceOver. AppleVis has a review. It doesn't happen very often, but App programmers in the iOS Universe do indeed sometimes think about Accessibility support, and the APIs provided by Apple are useful enough to allow programmers to write very accessible apps. You can say about Apple whatever you want, currently, it is the company providing the best accessibility support on the market. Why? Because they made accessibility a first-class citizen of their platform(s). This is where policy helps. If you can dictate top-down that you support people with disabilities, things actually start to happen. If you have to ask, hope, and wait, like it is with free software, things do not really progress as fast as the users need it. Back to THETA Poker Pro: The default configuration is already very useable with VoiceOver. However, if you want the cards placed on the board announced to you, so that you do not have to discover them manually by touch, you can enable the "Card Announcement" item in the Options menu. You can also set message delay a bit slower, such that all messages are actually fully spoken and not cut off sometimes. With these two settings adjusted, and maybe "Animation" set to "Very fast", the game feels extremely nice. There is actually nothing I would want to change, which does not happen very often when I test a program for its accessibility. With these settings changed, game play is very smooth with VoiceOver, you basically just have to tap your cards to check, tap the deck to fold, or tap your chips to raise. Very simple, and these three "buttons" are on the bottom of the screen, so rather easy and quick to find. All other activity is automatically announced by VoiceOver. I have played a few hundred hands already with this App. It is a wonderful way to pass time. For instance, I don't like to go to my doctor, because I usually wait up to two or three hours. I had to pay her a visit on monday. While waiting, I played "a few" hands, and suddenly, I was already called in. When I came out again, I checked the time and was rather surprised that yes, I have waited two hours again, but this time, I didn't notice! :-) Special thanks go to the author(s) of this app. It is a good example of an App that was not specially made for the blind, but which feels like it was. Thanks, you've made my week!

A bug-fix release 0.3.2.1.2 is of RcppEigen is now on CRAN and in Debian. It contains a short upstream patch by Gaek Guennebaud for the UBSAN warnings that were flagged at CRAN (from a rather harmless cpu-id comparison). The NEWS entry follows.

Changes in RcppEigen version 0.3.2.1.2 (2014-05-05)

• Applied upstream patch to not trigger g++ UBSAN warning on the cpu id comparison, with thanks to Gael Guennebaud for the patch

Courtesy of CRANberries, there are diffstat reports for the most recent release. Questions, comments etc about RcppEigen 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.

The recent flurry of activity with neovim have made me wonder if there could be something similar for the other editor, emacs. If you poke around recent GNU Emacs releases you'll come across random signs that the code carries a lot of baggage:

/usr/share/emacs/23.4/etc/MACHINES

There are special considerations for a variety of this system which is known as the Yellow Dog [GNU/]Linux' Yellow Dog [GNU/]Linux has been dead for many years now.

/etc/emacs/site-start.d/50dictionaries-common.el

Contains references to skipping stuff that runs under Emacs 19, 20, 21, & 22.

None of these are huge things, and the core code of Emacs is a pleasure to read in many places, but it does make you think, or not, whichever the case may be it is all good :) (I do all "real work" in emacs. I write all outgoing emails in vim, and use it for git/mercurial commit messsages, otherwise the only time I use it is for random one-line edits over slow links.)

Weblate 1.9 has been released today. It comes with lot of improvements and bug fixes and with experimental Zen mode for editing translations. Full list of changes for 1.9:

• Django 1.6 compatibility.
• No longer maintained compatibility with Django 1.4.
• Management commands for locking/unlocking translations.
• Improved support for Qt TS files.
• Users can now delete their account.
• Avatars can be disabled.
• Merged first and last name attributes.
• Avatars are now fetched and cached server side.
• Added support for shields.io badge.

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://l10n.cihar.com/ 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!

Trying out Debian arm64 port on chroot running inside qemu-user-static. It seems like it's getting closer to being ready. qemu 2.0 already hit Debian unstable, so qemu-aarch64-static is already available in qemu-user-static package. Today, debootstrap cross almost works but doesn't, because of some missing dependencies in debian-ports. hmmm... Some of the commands I needed to do:

A new release 4.300 of Armadillo, the templated C++ library for linear algebra, was released by Conrad a few days ago. As usual, this was rolled up in a new RcppArmadillo release 0.4.300.0 which is now on CRAN and in Debian. This release brings nice new upstream changes such as faster find() as well as corresponding functions to find elements which are either finite or non-finite, based on a suggestion we made. This may need an RcppArmadillo specific extension as R extends the IEEE logic to supported NA, NaN and Inf on floating point variables whereas standard C++ (and hence Armadillo) only supports the latter two. We hope to work on this shortly. Kevin also put in some code to make sure unsigned int vectors and matrices are converted correctly, and I updated the short configure script checking for complete LAPACK support to account for the R 3.0.3 or later case.

Changes in RcppArmadillo version 0.4.300.0 (2014-05-04)

• Upgraded to Armadillo release Version 4.300 (Medieval Cornea Scraper)
  • faster find()
  • added find_finite() and find_nonfinite() for finding indices of finite and non-finite elements
  • expressions X=inv(A)*B*C and X=A.i()*B*C are automatically converted to X=solve(A,B*C)
• Corrected conversion to unsigned int vectors and matrices
• Configure script now checks for R version 3.0.3 or newer to enable complex divide-and-conquer SVD in case of R-supplied LAPACK

Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, more detailed information is on the RcppArmadillo page. 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.

Dashkiosk is a solution to manage dashboards on multiple displays. It comes in four parts:

1. A server will manage the screens by sending URL to be displayed. A web interface enables an administrator to configure groups of dashboards and attach them to a set of displays.
2. A receiver runs in a browser attached to each screen. On start, it contacts the server and waits for the URL to display.
3. An Android application provides a simple fullscreen webview to display the receiver.
4. A Chromecast custom receiver which will run the regular receiver to display dashboards using Google Chromecast devices. The server is able to drive Chromecast devices through nodecastor, a reimplementation of the sender API.

For a demo, have a look at the following video (it is also available as an Ogg Theora video).

I was invited to give a talk at a local conference, OS-UPIITA. I have been invited to this conference before, and will gladly be there again. But I was recently pointed at the invitation poster they are distributing (which I reproduce here for your convenience) And I must make a couple of corrections here:

1. First and foremost: I don't want to trick anybody. I am not the Director of Debian Mexico. In fact, Debian Mexico does not exist. I am just a humble Debian Developer.
2. I accept the conference title, because that's what they requested from me. I'm trying to come up with a coherent exposition, but whoever knows me must be perfectly aware that I don't know (nor really care about) how to make money with Free Software. I have lived all of my professional life thanks to Free Software, but I'm against the entrepenurial culture. I will talk about my vision, of course, so if you want to hear me rant, you are invited to join us ;-)
3. I specifically asked the organizing committee by mid-April, when they gave me the talk title, to replace "Open Source" with "Free Software" in my talk. Even though the conference is called "OS UPIITA" (as it is the Open Source conference in the UPIITA unit of Instituto Polit cnico Nacional), I cannot identify with the Open Source monkier. And if we are talking about a deeply ideological issue, which is the case here, I request to use the name I can relate with. For my talk only, of course.

</rant> But anyway, I will be very happy to be there, and believe me, am working to come up with a good talk. OS-UPIITA friends: Please correct your online banners carrying this wrong data. [update] OS-UPIITA changed the poster! I'm just keeping this one for the memory ;-) [update 2] I was there, and gave the talk. And it was even a success, yay! \o/ Care to see it? Here is the presented material.

Attachment	Size
osupiita_chico.jpg	43.74 KB

I ve done some clean-up in the Debian BTS. The result can be seen in the QA graphs: The last remaining 6 bugs are only affecting OpenStack Essex (which is what Wheezy ships, and which unfortunately I have not enough time to support properly), and the last one is waiting for FTP masters approval after I added Python 3 support to oslo-config (OpenStack is slowly moving to Python3, and I ve tried to add support to Python3 in the packages as well each time it was possible). Also, the Icehouse packages have passed the tempest tests (a set of functional tests) which we run in our continuous integration system. As I was doing some triaging, it is possible that some bugs have been closed a bit quickly (like for example the Ceilometer FTBFS which I couldn t reproduce, even with sbuild and cowbuilder), so it is well possible that some more QA work will be needed later on. I m also expecting a new set of patches for supporting Ceph in Nova. I m sure there s issues which we will discover later on, however, it is nice to have this result right after the first Icehouse release of OpenStack. Next up: testing new components that I uploaded for this release: Trove (DB as a Service), Designate (DNS as a Service), Ironic (Metal as a Service, or cloud computing on bare-metal), and TripleO (OpenStack on OpenStack). I unfortunately know already that TripleO and Tuskar wont really work yet, and that it needs some patches to be sent upstream for it to support Debian correctly (let s work it out for Juno!). So please consider it as a technology preview only. Though Trove, Designate and Ironic are supposed to be in good enough shape, I didn t have the chance to test them more than just installing the packages and checking daemons are running and connected to the various components of OpenStack (eg: database, keystone and RabbitMQ). Please do test them and report bugs in the BTS. I d like to thanks Gustavo Panizzo & Thomas Bechtold who contributed to this release, and also the folks at eNovance (Emilien, Cyril, Seb ) who provided precious help with the CI and package quality. See you in the Juno Atlanta design summit next week (as hopefully, my plane ticket issue will be soon solved).

Together with many phpMyAdmin guys, I'm traveling to LinuxTag 2014 in few days. We'll have a booth there (hall 6, booth A13), where we will show some demos and you can stop by and chat with us. Of course my presence there will not be just about phpMyAdmin, I'll meet there few Weblate users and developers, but if you have anything else to discuss, just stop by, I'll be usually around the booth.

Filed under: English phpMyAdmin Weblate 0 comments Flattr this!

Yesterday I received an automated alert from my kvm-hosting host-machine, informing me that one of the drives in the RAID-pair had failed. This particular machine has been up and running since 2009, and according to my outage log this is the first downtime in three years. (The uptime was over 1000 days, which seems to confirm that pretty nicely.) I like reliable systems, and sometimes it's worth remembering just how well they can work. In other news I'm currently continuing to chase a new job. The companies I've approached, or which have approached me, are being a little slow in replying which is a shame, but I'm not hugely concerned .. yet. I'm going to give things another week, or so, and then add a banner to the Debian-Administration website, and see if that results in anything interesting. In the meantime I've got some wood, and a new mitre saw, and I will be spending the remainder of today working on my new desk. Doing physical things is always fun, and right now especially.

Just saw http://sny.no/2014/04/dbts and I feel compelled to note that distributed bug trackers are not new the earliest I personally encountered was Aaron Bentley s Bugs everywhere coming up on it s 10th birthday. BE meets many of the criteria in the dbts post I read earlier today, but it hasn t taken over the world and I think this is in large part due to the propogation nature of bugs being very different to code different solutions are needed. XXXX: With distributed code versioning we often see people going to some effort to avoid conflicts semantic conflicts are common, and representation conflicts extremely common.The idions Take for example https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/805661. Here we can look at the nature of the content:

1. Concurrent cannot-conflict content e.g. the discussion about the bug. In general everyone should have this in their local bug database as soon as possible, and anyone can write to it.
2. Observations of fact e.g. the code change that should fix the bug has landed in Ubuntu or Commit C should fix the bug .
3. Reports of symptoms e.g. Foo does not work for me in Ubuntu with package versions X, Y and Z .
4. Collaboratively edited metadata tags, title, description, and arguably even the fields like package, open/closed, importance.

Note that only one of these things the commit to fix the bug happens in the same code tree as the code; and that the commit fixing it may be delayed by many things before the fix is available to users. Also note that conceptually conflicts can happen in any of those fields except 1). Anyhow my humble suggestion for tackling the conflicts angle is to treat all changes to a bug as events in a timeline e.g. adding a tag foo is an event to add foo , rather than an event setting the tags list to bar,foo then multiple editors adding foo do not conflict (or need special handling). Collaboratively edited fields would be likely be unsatisfying with this approach though last-writer-wins isn t a great story. OTOH the number of people that edit the collaborative fields on any given bug tend to be quite low so one could defer that to manual fixups. Further, as a developer wanting local access to my bug database, syncing all of these things is appealing but if I m dealing with a million-bug bug database, I may actually need the ability to filter what I sync or do not sync with some care. Even if I want everything, query performance on such a database is crucial for usability (something git demonstrated convincingly in the VCS space). Lastly, I don t think distributed bug tracking is needed it doesn t solve a deeply burning use case offline access would be a 90% solution for most people. What does need rethinking is the hugely manual process most bug systems use today. Making tools like whoopsie-daisy widely available is much more interesting (and that may require distributed underpinnings to work well and securely). Automatic collation of distinct reports and surfacing the most commonly experienced faults to developers offers a path to evidence based assessment of quality something I think we badly need.

The NVidia card being unable to drive two monitors is a little annoying, and the lack of support for skype and chrome is a bother, but I think I can build chrome There ll probably be no flash, I imagine.

A long time ago, St phane Glondu implemented an alternative to the Buildd status pages. It was implemented in OCaml and had some unique features. I think that my favorite one was the ability to click on package names appearing in DepWaits.

What you see on the image below is a simple example where the package gnome-shell Dep-Waits on a single package. This prevents buildd daemons to start the job as long as the specific version of the specified package or some new package are available. So, each package name in that field became now clickable and points to its buildd status page.


Similarly to Dep-Waits, results of edos-debcheck, which is used to spot installability issues of build dependencies, are now clickable too.

If you are a porter or if you are tracking down a build issue, I am sure you'll appreciate these two new features. Enjoy! As usual, if you notice some bugs or have some feature requests, please let me know.

A Git annex hook for Hubic I've just finished the git annex hook I was writing. It create a special remote that will use Hubic as a storage for git annex's objects. To use it, you will have to download it from github. It depend on

• ruby (the ruby debian package will do)
• mechanize (the ruby-mechanize debian package, you can also use gems)
• dbus (the ruby-dbus package)

To use it, you first need to initialize your account. You need an hubic account, but also a client_id and client_secret, that you can generate in My account then Developer. For my hook to work, you need to use http://localhost:4090/ as the Redirect URI (Domaine de redirection in french) Credential will be stored in dbus's org.freedesktop.secrets service, both gnome and kde will give you one. So run hubic-git-annex-hook --init, it will ask for your hubic username, password, your client id and your client secret that you just generate, and store them in the org.freedesktop.secrets service. Then configure git-annex to use it :

git config annex.hubic-hook /full/path/to/hubic-git-annex-hook $HUBIC_USERNAME $CONTAINER

the CONTAINER is openstack concept, that contain the files. Hubic use the container default for its synchronization application, you should probably use another. If the CONTAINER do not exist, the hook will create it. You finally need to create the special remote :

git annex initremote hubic type=hook hooktype=hubic encryption=none

(you could chose any other name than hubic), you can then git annex copy --to=hubic

A couple of weeks ago I finally got round to doing some major surgery on iptables-persistent. First of all it is principally now called netfilter-persistent (although the source package hasn t been renamed) and has a plugin architecture so that it can be extended by other packages. One of those packages is iptables-persistent; others may follow. This opens the way to fixing #662743 and #697088 (patches always welcome). There s also a new binary to handle loading/unloading of rules, instead of having all the logic in an init script. I was therefore able to add systemd support as a first-class unit, and I d appreciate patches for an Upstart service (as I m largely unfamiliar with it). Plugins are simply dropped into /usr/share/netfilter-persistent/plugins.d and must follow certain minimum conventions, detailed in netfilter-persistent(1). They can be any executable, so compiled or interpreted binaries are acceptable. This release finally gets the magic 1.0 identifier. It reaches Jessie today, and is already in Ubuntu Utopic. Flattr

---

iptables-persistent overhaul is a post from: jwiltshire.org.uk Flattr