Screen-dependent window geometry I have an external monitor for my laptop in my work desk at home, and when I work I keep a few windows like IRC on my laptop screen, and everything else on the external monitor. Then maybe I transfer on the sofa to watch a movie or in the kitchen to cook, and I unplug from the external monitor to bring the laptop with me. Then maybe I go back to the external monitor to resume working. The result of this (with openbox) is that when I disconnect the external monitor all the windows on my external monitor get moved to the right edge of the laptop monitor, and when I reconnect the external monitor I need to rearrange them all again. I would like to implement something that does the following:

1. it keeps a dictionary mapping screen geometry to window geometries
2. every time a window geometry and virtual desktop number changes, it gets recorded in the hash for the current screen geometry
3. every time the screen geometry changes, for each window, if there was a saved window geometry + wirtual desktop number for it for the new screen geometry, it gets restored.

Questions:

1. Is anything like this already implemented? Where?
2. If not, what would be a convenient way to implement it myself, ideally in a wmctrl-like way that does not depend on a specific WM?

Note: I am not interested in switching to a different WM unless it is openbox with this feature implemented in it.

Wow, it's been quite a long time since I've posted something here. Everything is going well -- I'm just very, very engrossed with the new job, since I'm still in exponential ramp-up mode. It's lasting for longer than I expected, although my expectations didn't have much basis since this is the first time I've started a new job in 17 years. I'm feeling more and more capable every day, but the combination of a very heavily social learning process, a lot of new technical areas to learn, and not having taken a vacation since last June means that my weekends are spent just passively watching things and zoning. Not sure yet how long that will last, and I don't want to make any predictions, although I do have my first significant vacation coming up next month. Anyway, book reading and buying has continued, although I'm again far behind on writing reviews. With luck, I'll be writing one of those (for posting later) right after writing this post. Michelle Alexander The New Jim Crow (non-fiction)
Elizabeth Bear Karen Memory (sff)
Becky Chambers The Long Way to a Small, Angry Planet (sff)
Fred Clark The Anti-Christ Handbook (non-fiction)
Charles de Lint The Very Best of Charles de Lint (sff)
S.L. Huang A Neurological Study on the Effects... (sff)
S.L. Huang Half Life (sff)
Kameron Hurley The Mirror Empire (sff)
Sophie Lack Dissonance (sff)
Sophie Lack Imbalance (sff)
Susan R. Matthews An Exchange of Hostages (sff)
Kaoru Mori A Bride's Story #1 (graphic novel)
Donald Shoup The High Cost of Free Parking (non-fiction)
Jo Walton The Just City (sff) Pretty nice variety of different stuff from a huge variety of recommendation sources. I've already read the Chambers (and can recommend it). A review will be forthcoming.

My good friend Felipe Esquivel is driving a crowdfunded project: the first part of the "Natura" short film. I urge every reader of my blog to support Felipe's work! Felipe, the director for this project, is a very talented Chilean-Mexican animator. He has produced short animated films such as A duel and One fine day. Not only that: It might be interesting for my blog's readers that a good deal of the work of Cham n Animation's work (of course, I am not qualified to state that "all of" their work But it might well be the case) is done using Free Software, specifically, using Blender. So, people: Go look at their work. And try to be part of their work!

0. Who are you and what is your history with Debian Project? I guess this part is well covered in my platform. 1. What is your most proud moment as Debian Developer? I am pretty proud of having been part of the few who implemented the first automatic dependency resolver for OCaml programs and libraries in Debian packages. It was really the first one in the OCaml community and we were quite proud of it. But that was done before I become a Debian Developer. As a DD, I have to admit I am quite proud to be part of the Release Team. It is a fantastic team where there is so much to do. Helping the team means something to me, and I invested a considerable amount of time (a few months) working on reviewing patches for Squeeze and helping to get it ready by our standards. My best moment was Squeeze's release, my first Debian release as Release Team member. 2. In your opinion what is the strongest part of Debian Project? I am not sure we can identify one single strength of the Debian project. But, when I think about your question, I remember something I've heard many times: Debian is about people . I have to admit that I didn't realize it myself until I heard it for the first time and I completely share the idea! For me, all the technical side of the project comes after the community. With time, I think we managed to build a strong community. Many contributors became friends with time. We are seeing many Developers having babies and bringing them to Debian events. I find that really amazing. 3. And what is the weakest part of Debian Project? Our strength is somehow also our weakness. We are humans and make mistakes. We have feelings and some discussions get heated sometimes. It is not easy to keep everyone calm and focused. We have seen the damage that was caused to our core community last year with all the flamewars. Many people lost their motivation and we have seen some of them stepping down. We are also having troubles on-boarding new contributors, which is a problem today because some teams are under-staffed and could become an even bigger issue on the longer term. 4. How do you intend to resolve the weakest part? An effort has already been made on this front. We can mention the introduction of the Code of Conduct and the diversity statement, for example. Both are important and make us a more welcoming and caring community. In my platform, I mentioned some ideas about recruitment and change management. I believe that both sides will help us to get a stronger community. Moreover, a DPL should act as a mediator to help some situation get through. This is one of the DPL tasks that is not formally identified and is usually under-estimated. 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? Personally, the main thing I have learned from past DPLs is that communication is very important. A DPL should dedicate time to communicate about ongoing actions and achievements. It is also important to remind a few things even if it may sound repetitive or trivial:

• Why such action/subject is important.
• What actions have been tried/done in the past.
• What progress has been made since last time.
• What is possibly the next step.

If the communication is only about listing some actions, many people will miss its essence and its goals. It is even more important when we know that some actions may take years (thus, several DPL terms) to complete. If I am elected as DPL, I'd really like to help the project to publish a roadmap. I think it is very important to set goals to the project to better explain our philosophy and approach in the Free Software world. This may also help to attract new contributors which may be interested by one or some items. Of course, I will not work on that subject only. I invite you to read the rest of my platform to see the other ideas. 6. What motivates you to work in Debian and run for DPL? Many many things. And more importantly, many many people As many of us, I like programming and socializing. It feels nice to be part of such a big project and where you can do many different things. I contribute to Debian because I find it fun and let me meet people I will not have been able to meet elsewhere. In my platform, I tried to identify ideas I'd like to see implemented, or at least started. Since Debian is a do-ocracy, I thought I could try to get them implemented by myself. I think that those ideas are important for the Debian community and will help us moving forward. Running for DPL is also another way of contributing to Debian and I'd feel honored to represent Debian.

0. Who are you and what's your history with Debian Project? I'm a little mouse behind a keyboard, going by the nickname "algernon". I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I did a number of things within Debian - mostly small and marginal things, mind you. With a little break, I've been here for over a decade, and am planning to stay for at least another. 1. What's your most proud moment as Debian Developer? At last year's LinuxTag, I was wandering around a stand where they sold Raspberry Pis (with cases and other accessories). I had a nice chat with one of the staffers there, inquired about the price (including the case, of course), and a few other things. He asked a few things back: what I'll be using it for, and so on. After it turned out that I'm a Debian Developer, and syslog-ng hacker, he went to the back, and emerged a few minutes later with a boxed up Pi, and gave it to me as a gift, for working on Debian. This was an incredibly touching moment, in many, many ways. 2. In your opinion what is the strongest part of Debian Project? That's hard to say, to be honest. There are a good number of things Debian is incredibly strong at, and it would be hard to arbitrarily pick one. Quality, responsibility, safety, predictability are all areas we are very good at. But those are the qualities of the OS. As a project, we are remarkably well organised, given the volunteer & distributed nature of the project. 3. And what is the weakest part of Debian Project? While we can resolve and work with technical issues in a reasonable manner, the project as a whole is rather lacking in all other areas. To grow beyond being the creators of the Universal OS, we, as a project, need to pursue goals beyond the OS. Being part of GSoC and Outreachy are great steps forward. But we still have a lot of internal issues that need to be resolved. Areas such as innovation, team work, where we're in dire need of improvement. 4. How do you intend to resolve the weakest part? As explained in my platform, my primary goal is to remove roadblocks. The DPL can do very little alone, his time and powers are better spent on enabling those who have the required skills and desires, to pursue those. 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? The most valuable thing I learned from past DPLs is that the expectations are sky-high, yet, a significant portion of what the DPL does is very different than what I imagined in past years. I'd like to challenge the status quo of the DPL being a nearly full-time job. 6. What motivates you to work in Debian and run for DPL? I'm in it for the fame and glory, of course! And because my Tamagotchi told me to. But on a more serious tone, my main motivation to work on Debian is because contributing makes me happy. It satisfies my hunger for doing useful work. Debian is - in my opinion - the perfect platform to give back to the wider Free Software community. Similarly, my motivation to run for DPL is to allow Debian to be a stronger member of that greater

0. Who are you and what's your history with Debian Project? My name's Neil, I've been involved with Debian for over 10 years now. I've held a variety of roles, from the SPI board, writing policy and secure testing team, to being one of the Release Managers for Squeeze and Wheezy. 1. What's your most proud moment as Debian Developer? Probably the release of Squeeze, my first as RM. It was the end of a great effort to get the release out. I particularly remember at the end of DebConf 10 in New York going to the local Disney store and buying every single small squeeze plush toy they had, so I could send a thank you gift to the rest of the release team! Another perhaps was when I first got my Debian kilt. 2. In your opinion what is the strongest part of Debian Project? I think this is our social contract. It guides us, and is what we all agree on. This is our promise to ourselves, to the wider open source community and to our users. 3. And what is the weakest part of Debian Project? At a push, I'd say it's the variety of packages we have in the archive. I'm not sure it's weakness, but it's certainly a challenge. It becomes exponentially harder to ensure that everything integrates well as you add more packages. To have made it do so this far is quite impressive. 4. How do you intend to resolve the weakest part? Well, see the section in my platform on PPAs, and modernising our build and infrastructure system Wouldn't it be great if you could stage a package against all of stable, testing and unstable, and see what fails to build and where, with live build logs on all architectures? 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? I think my primary role as DPL for 2015 would be to get a great start of development for Stretch. The start of a new release cycle is the exact time to implement wide changes that are potentially disruptive. Every couple of years we seem to relax after the release, rather than get geared up for the next one, and then time passes, and plans slip, and before we know it, the freeze is fast approaching. If we start planning /now/, then we can hopefully enter the freeze with fewer RC bugs, which should be great news for everyone! For the second part, I've talked to a lot of the previous DPLs, and worked with them in one role or another. The main thing I was told was that I shouldn't try and do everything I planned on. It's hard work, and all sorts of things pop up that derail your original plans. 6. What motivates you to work in Debian and run for DPL? The people involved. I've met and worked with some of my greatest friends due to the project. The work, dedication and commitment of those over the years is outstanding. Most of these people are still with us, and unfortunately, a few are not. Whenever I'm feeling disheartened or annoyed, usually due to a giant flame-war then I simply remember that what we're doing is truly remarkable, and the effort that everyone has put in over the years isn't something that should be taken for granted.

Earlier today, I posted a mail to debian-devel about how approximately 25 RC bugs affecting Jessie have been unblocked. As mentioned, I planned to age some of them. The expected result is that about 18 of them will migrate tonight and the remaining 7 of them will migrate tomorrow night. After that, there are no more RC bugs waiting for the RT to unblock them! The only remaining item on the list is cgmanager, for which we are requesting a t-p-u (maintainer already contacted about it). If you want a release sooner, please have a look at the list of remaining RC bugs or/and start testing upgrades. In other news, the glibc regression got fixed. The new version of glibc has already been approved by us. It is now waiting for the debian-installer team to testing it and approve it.
Filed under: Debian, Release-Team

So, I also got myself a new toy. My current ThinkPad is a bit ancient, but still sturdy. It's an X201s from 2010 (brought refurbished), and it's still working pretty fine, but eh, I couldn't resist. The X230 was nice, but didn't have a large resolution screen (1366 768). The X240 brought a full HD (1920 1080) IPS screen, but lost the hardware trackpoint buttons. Finally, the X250 brings back the buttons, still have a nice screen (not qHD or some other trendy resolutions, but still FHD and IPS). And on top of that, it comes with Broadwell, so that means I get smap. It runs mostly fine out of the box on Debian sid, but for full support some tuning is needed. I've setup a page with more information on the laptop, and some images can be found over there.

A new minor release of littler is available now. It adds or extends a number of things:

• added support for drat by adding a new example installDrat.r;
• the install.r, install2.r and check.r scripts now use getOption("repos") to set the default repos; this works well with drat and multiple repos set via, e.g. ~/.littler.r or /etc/littler.r;
• added support for installing Debian binaries as part of a check.r run, this can be particularly useful for one-command checks as done by some of the Rocker containers;
• added support for reproducible builds: if REPRODUCIBLE_BUILD is defined, no date and time stamp is added to the binary;
• added new command-line option -L --libpath to expand the library path used for packages;
• added support for setting multiple repos from the command-line in the install2.r script;
• the manual page was updated with respect to recent additions;
• a link to the examples web page was added to the --usage output display;

See the littler examples page for more details. Full details for the littler release are provided as usual at the ChangeLog page. The code is available via the GitHub repo, from tarballs off my littler page and the local directory here. A fresh package has gone to the incoming queue at Debian; Michael Rutter will probably have new Ubuntu binaries at CRAN in a few days too. Comments and suggestions are welcome via the mailing list or issue tracker at the GitHub repo.

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

We have several computers at home, and we want to allow guests to use one of them to access the Internet. This feature comes out of the box in Ubuntu and is called Guest sessions . My attempt to provide the same on Debian jessie is in a script Some notes:

• going to greeter via DBus is not standard (All *DM have there own API). I ve started a discussion about this
• lightdm in Ubuntu has it s own life and doesn t come from Debian (This is expected for an Ubuntu project):
  • Ubuntu s is the default DM and is not multi-arch, yet
  • Debian s is focused on Xfce and doesn t provide any guest-session machinery
• Ubuntu has patched gnome-shell and adduser to allow guest-sessions. I think we should merge those patches back (after jessie release)

Although things are not 100% certain it seems highly likely we'll be moving to Newcastle in five months time. If I seem distracted/absent/busy over the next month or two this will be a good excuse!

Editorial Note: The following post was kindly contributed by Steven Pav.

Why Drat? After playing around with drat for a few days now, my impressions of it are best captured by Dirk's quote:

It just works.

Demo To get some idea of what I mean by this, suppose you are a happy consumer of R packages, but want access to, say, the latest, greatest releases of my distribution package, sadist. You can simply add the following to your .Rprofile file:

drat::add("shabbychef")

After this, you instantly have access to new releases in the github/shabbychef drat store via the package tools you already know and tolerate. You can use

install.package('sadists')

to install the sadists package from the drat store, for example. Similarly, if you issue

update.packages(ask=FALSE)

all the drat stores you have added will be checked for package updates, along with their dependencies which may well come from other repositories including CRAN.

Use cases The most obvious use cases are:

1. Micro releases. For package authors, this provides a means to get feedback from the early adopters, but also allows one to push small changes and bug fixes without burning through your CRAN karma (if you have any left). My personal drat store tends to be a few minor releases ahead of my CRAN releases.
2. Local repositories. In my professional life, I write and maintain proprietary packages. Pushing package updates used to involve saving the package .tar.gz to a NAS, then calling something like R CMD INSTALL package_name_0.3.1.9001.tar.gz. This is not something I wanted to ask of my colleagues. With drat, they can instead add the following stanza to .Rprofile: drat:::addRepo('localRepo','file:///mnt/NAS/r/local/drat'), and then rely on update.packages to do the rest.

I suspect that in the future, drat might be (ab)used in the following ways:

3. Rolling your own vanilla CRAN mirror, though I suspect there are better existing ways to accomplish this.
4. Patching CRAN. Suppose you found a bug in a package on CRAN (inconceivable!). As it stands now, you email the maintainer, and wait for a fix. Maybe the patch is trivial, but suppose it is never delivered. Now, you can simply make the patch yourself, pick a higher revision number, and stash it in your drat store. The only downside is that eventually the package maintainer might bump their revision number without pushing a fix, and you are stuck in an arms race of version numbers.
5. Forgoing CRAN altogether. While some package maintainers might find this attractive, I think I would prefer a single huge repository, warts and all, to a landscape of a million microrepos. Perhaps some enterprising group will set up a CRAN-like drat store on github, and accept packages by pull request (whether github CDN can or will support the traffic that CRAN does is another matter), but this seems a bit too futuristic for me now.

My wish list In exchange for writing this blog post, I get to lobby Dirk for some features in drat:

6. I shudder at the thought of hundreds of tiny drat stores. Perhaps there should be a way to aggregate addRepo commands in some way. This would allow curators to publish their suggested lists of repos.
7. Drat stores are served in the gh-pages branch of a github repo. I wish there were some way to keep the index.html file in that directory reflect the packages present in the sources. Maybe this could be achieved with some canonical RMarkdown code that most people use.

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

A frantic last day of work on Scroll. Until 3 am last night, I was working on adding a new procedurally generated level. This morning, fixed two major bugs reported by playesters overnight. Also fixed crashes on small screens and got the viewport to scroll. Added a victory animation in time for lunch. After lunch, more level generation work. Wasted an entire hour tracking down a bug in level gen I introduced last night, when I was bad and didn't create a data type to express an idea. Added a third type of generated level, with its own feel. Finished up with a level selection screen, which needed just 47 lines of code and features a playable character. I have six hours until my 7drl is officially over, but I'm done! Success! You can download the code, play, etc, at Scroll's homepage

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1053 (Including 152 bugs affecting key packages)
  • Affecting Jessie: 97 (key packages: 63) That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 68 (key packages: 50) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 13 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 3 bugs are marked as done, but still affect unstable. (key packages: 1) This can happen due to missing builds on some architectures, for example. Help investigate!
      • 52 bugs are neither tagged patch, nor marked done. (key packages: 39) Help make a first step towards resolution!
    • Affecting Jessie only: 29 (key packages: 13) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 27 bugs are in packages that are unblocked by the release team. (key packages: 13)
      • 2 bugs are in packages that are not unblocked. (key packages: 0)

How do we compare to the Squeeze and Wheezy release cycles?

Week	Squeeze	Wheezy	Jessie
43	284 (213+71)	468 (332+136)	319 (240+79)
44	261 (201+60)	408 (265+143)	274 (224+50)
45	261 (205+56)	425 (291+134)	295 (229+66)
46	271 (200+71)	401 (258+143)	427 (313+114)
47	283 (209+74)	366 (221+145)	342 (260+82)
48	256 (177+79)	378 (230+148)	274 (189+85)
49	256 (180+76)	360 (216+155)	226 (147+79)
50	204 (148+56)	339 (195+144)	???
51	178 (124+54)	323 (190+133)	189 (134+55)
52	115 (78+37)	289 (190+99)	147 (112+35)
1	93 (60+33)	287 (171+116)	140 (104+36)
2	82 (46+36)	271 (162+109)	157 (124+33)
3	25 (15+10)	249 (165+84)	172 (128+44)
4	14 (8+6)	244 (176+68)	187 (132+55)
5	2 (0+2)	224 (132+92)	175 (124+51)
6	release!	212 (129+83)	161 (109+52)
7	release+1	194 (128+66)	147 (106+41)
8	release+2	206 (144+62)	147 (96+51)
9	release+3	174 (105+69)	152 (101+51)
10	release+4	120 (72+48)	112 (82+30)
11	release+5	115 (74+41)	97 (68+29)
12	release+6	93 (47+46)
13	release+7	50 (24+26)
14	release+8	51 (32+19)
15	release+9	39 (32+7)
16	release+10	20 (12+8)
17	release+11	24 (19+5)
18	release+12	2 (2+0)

Graphical overview of bug stats thanks to azhag:

My Lenovo x220, which I've owned for almost four years now (I remember fetching it from the supplier shortly before driving off to Banja Luka), was getting somewhat worn out. The keyboard and the screen had both been replaced at some point already, and the wwan interface had given up as well. The case was all cracked, and the NIC connector wasn't doing very well anymore either; there have been a few cases of me trying to configure the wireless network at a customer, but this being harder than it needs to be because the NIC will only work if I put in the network cable just so, and someone dropped a piece of paper onto the cable. In other words, it was time for a new one. At first I wanted to buy a Lenovo x250, but then I noticed that the Fujitsu came with an i7 4712MQ, which I liked (as today it is still quite exceptional for an ultrabook to have a quadcore processor). Fujitsu also claims up to 9 hours of battery life, but it's not clear to me whether this is supposed to be the case with the default battery only. They also have a battery for the modular bay, which I bought as well (to replace the optical drive whic I sometimes use, but only rarely), and on top of that it came with a free port replicator. Not all is well, however. In the x220, getting the WWAN interface to work involved some creative use of chat against /dev/ttyACM0 wherein I issue a few AT commands to put the WWAN interface into a particular mode, and from then on the WWAN interface is just a regular Ethernet interface on which I can do DHCP. The new laptop has a "Sierra Wireless, Inc." WWAN interface (USB id 1199:9041) which annoyingly doesn't seem to expose the ttyACM (or similar) devices, and I'm not sure what to use instead. Just trying to do DHCP doesn't work -- yes, I tried. Unfortunately, the keyboard isn't very good; it's of the bubble gum type, and I keep getting annoyed at it not picking up my keystrokes all the time. When I'm at home or at my main customer, I have a Das Keyboard Ultimate S (3rd (customer) and 4th (home) generation), so it's only a problem when I'm not at home, but it's still extremely annoying. There is a "backlight" function in that keyboard, but that's not something I think I'll ever use (hint: "das keyboard ultimate s"). The display can't do more than 1366x768, which is completely and utterly wrong for a computer -- but it's the same thing as my x220, so it's not really a regression. The "brightness" ACPI keys don't seem to work. I may have to fiddle with some ACPI settings at some point, I suppose, but it's not a major problem. When I plugged it in, I noticed that fdpowermon ignored the second battery. I had originally written fdpowermon with support for such a second battery, but as my x220 had only one, I never tested it. Apparently there was a bug, but that's been fixed now -- at least in unstable. On the good side of the equation, it has three USB3 ports in the laptop, and four in the port replicator, with no USB2; this is a major leap forwards from the one USB3 and six USB2 in the x220. A positive surprise was the CCID smartcard reader that I somehow missed while reading the specs, but which -- given my current major customer, is very welcome, indeed. Update: After having used it a few days, there were a few minor annoyances:

• Audio didn't work whenever I plugged the laptop to its port replicator and used the external screen. It took me a while to figure out that the default ALSA card (i.e., card 0) is the HDMI output, whereas card 1 is the PCH output, and that since I'm using the DVI port and analog audio, I hear nothing. To fix, create a .asoundrc containing:

    pcm.!default  
      type hw
      card 1
     
    ctl.!default  
      type hw
      card 1
     
  

• Backlight didn't work. My .config/awesome/rc.lua now contains the following lines:

    awful.key(   , "XF86MonBrightnessDown", function() awful.util.spawn("xbacklight -dec 5") end),
    awful.key(   , "XF86MonBrightnessUp", function() awful.util.spawn("xbacklight -inc 5") end),
    awful.key(  modkey  , "XF86MonBrightnessDown", function() awful.util.spawn("xbacklight -set 1") end),
    awful.key(  modkey  , "XF86MonBrightnessUp", function() awful.util.spawn("xbacklight -set 100") end),
  

  The lines with "modkey" allow me to go to "brightness max" or "brightness min" in one go, rather than have to hit fn+f6 or fn+f7 repeatedly, which is a useful extra.
• It was suggested to me that ModemManager might be able to figure out how to enable the WWAN modem. The good news is that it detects the modem, and mmcli should have a way to enable things. The bad news is that mmcli -m 0 -e just comes back with "error: couldn't enable the modem: 'timed out'" (partially translated into Dutch). I haven't had the time to look into this much yet, but it seems to be another one of those dbus complications. To be continued, I'm sure.

For many the PHP JSON extension license might look like a storm in a teacup, but for many Linux distributions the bits of the free software licenses are very important. That was the case when Debian decided (#692613) to remove the non-free JSON extension as part of the transition to PHP 5.5 in May 2013 (after the Debian 7 release). This change was done with the help of Remi Collet (from Fedora / Red Hat) who wrote an alternative extension based on JSON-C implementation. A similar change was done by other Linux distributions, and this became the defacto standard for most Linux users. The situation has recently changed with the acceptance of the Jakub Zelenka s jsond RFC to replace the current non-free implementation with a free one. The change was committed to the code base on early February (Closing #63520) and expected to be released later this year as part of PHP7.
Filed under: Free software licenses, PHP

0.1.1 is a one-bugfix release fixing an issue where git-cinnabar could be confused if commands were started from a subdirectory of the repository. It might be the cause for corruptions leading to issues such as the impossibility to push. If you do encounter failures please report them. Please also paste the output of git cinnabar fsck.