Hello This blog explains how next lcdproc package provide easier upgrader with automatic configuration merge. Here s the current situation: lcdproc is shipped with several configuration files, including /etc/LCDd.conf. This file is modified upstream at every lcdproc release to bring configuration for new lcdproc drivers. On the other hand, this file is always customized to suit the specific hardware of the user s system. So upgrading a package will always lead to a conflict during upgrade. User will always be required to choose whether to use current version or upstream version. Next version of libconfig-model-lcdproc-perl will propose user whether to perform automatic merge of the configuration: upstream change are taken into account while preserving user change. The configuration upgrade shown is based on Config::Model can be applied to other package. Current lcdproc situation To function properly, lcdproc configuration must always be adapted to suit the user s hardware. On the following upgrade, upstream configuration is often updated so user will often be shown this question:

Configuration file '/etc/LCDd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** LCDd.conf (Y/I/N/O/D/Z) [default=N] ?

This question is asked in the middle of an upgrade and can be puzzling for an average user. Next package with automatic merge Starting from lcdproc 0.5.6, the configuration merge is handled automatically by the packaging script with the help of Config::Model::Lcdproc. When lcdproc is upgraded to 0.5.6, the following changes are visible:
* lcdproc depends on libconfig-model-lcdproc-perl
* user is asked once by debconf whether to use automatic configuration upgrades or not.
* no further question are asked (no ucf style questions). For instance, here s an upgrade from lcdproc_0.5.5 to lcdproc_0.5.6:

$ sudo dpkg -i lcdproc_0.5.6-1_amd64.deb 
(Reading database ... 322757 files and directories currently installed.)
Preparing to unpack lcdproc_0.5.6-1_amd64.deb ...
Stopping LCDd: LCDd.
Unpacking lcdproc (0.5.6-1) over (0.5.5-3) ...
Setting up lcdproc (0.5.6-1) ...
Changes applied to lcdproc configuration:
- server ReportToSyslog: '' -> '1' # use standard value
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Starting LCDd: LCDd.
Processing triggers for man-db (2.6.6-1) ...

Note: the automatic upgrade currently applies only to LCDd.conf. The other configuration files of lcdproc are handled the usual way. Other benefits User will also be able to:
* check lcdproc configuration with sudo cme check lcdproc
* edit the configuration with a GUI (see Managing Lcdproc configuration with cme for more details) Here s a screenshot of the GUI: More information * libconfig-model-lcdproc-perl package page. This package provides a configuration model for lcdproc.
* This blog explains how this model is generated from upstream LCDd.conf.
* How to adapt a package to perform configuration upgrade with Config::Model Next steps Automatic configuration merge can be applied to other packages. But my free time is already taken by the maintenance of Config::Model and the existing models, there s no room for me to take over another package. On the other hand, I will definitely help people who want to provide automatic configuration merge on their packages. Feel free to contact me on:
* config-model-user mailing list
* debian-perl mailing list (where Config::Model is often used to maintain debian package file with cme)
* #debian-perl IRC channel All the best
Tagged: config-model, configuration, debian, Perl, upgrade

In 2011, I first tried to fix a Debian bug #547587. The bug was about hook script result codes not being checked, so if a script fails, this isn t detected. Unfortunately, just checking the return code wasn t enough, as lots of scripts didn t care about their return code at all, so I had to unapply the patch. Now, after 2.5 years, I think it s time to try again, as most of the scripts have been fixed since then. At the same time, I ve changed error handling a little bit further: errors in any commands or scripts during interface configuration are considered fatal, but when interface is deconfigured, errors are ignored. However, this may change break configurations which depend on previous behaviour. Please report bugs if you find any.

The next version of Lintian, 2.5.22, is long overdue mostly because 2.5.21 FTBFS in sid. Besides fixing test failures, 2.5.22 also fixes:

• False-negative for most/all JAR related tags caused by file(1) changing its output for these files.
• A performance regression in checks/cruft.pm. For large source packages, this could severely affect performance of Lintian. This is #738342.
• A regression where lintian would not parse options appearing after file arguments.
• Some false-positives in the GFDL with invariants check.

Besides bug fixes, we also added a couple of new features/nice changes:

• The color option now defaults to auto instead of never .
• The homepage now links to the generated API-docs and thus, also the developer tutorial.
  • Patches extending/improving either/both are more than welcome.
• The test-suite runner now caches test artifacts meaning that subsequent test runs become vastly faster.
• The test-suite runner can now run tests under Devel::Cover , so we can now collect statistics about how much of the code is covered by the test suite.
• The html_reports tool (used e.g. on lintian.d.o) has been optimised. In particular, it only calls gnuplot twice, instead of once per data file (of which there was basically one per tag).
• The html-pages generated by the html_reports tool now uses content -based names for resources (e.g. images and the .css file). This allows them to be cached vastly longer, since any content changes will rename the resource and force browser to refetch them.
  • All resources handled this way are now stored in resources/ . As a side-effect, this means that images files are moved from images/ to resources/ .
  • A notable exception to this is the auto-generated (.svg) graphs.

We just need to do some final tweaks and get the tag descriptions reviewed before we are ready to release the next version.

Aldi Mobile has made a significant change to their offerings. They previously had an offer of $35 for unlimited calls and 2.5G of data in a month for which they had to publicly apologise for misleading customers as 2500 minutes of calls a month (83 minutes per day) is no-where near unlimited [1]. They also had an offer of $15 for 2G of data. In an email about this Aldi said Many of our customers are using a lot less than what is included in our current $35 plan. So we will soon be introducing new Value Packs with more flexible options; meaning you only pay for what you really need and they start from just $10. . That is grossly misleading, if they offered new plans in addition to the old ones and allowed customers to choose the plan that is the best match then it would be useful to some customers. But removing the supposedly unlimited plan and the $15 for 2G of data option is removing affordable options for people who want to use their phones for lots of calls or very few calls but moderate amounts of data use. New Plans The base rate for calls on Aldi pre-paid is $0.12 per minute and $0.12 per SMS, consider every mention of minute in this section to be minute or SMS . The Aldi Newplans page [2] starts with a $10 per month plan which offers 100 minutes of calls which would be $12 at the previous rate of $0.12 per minute. That is OK value when compared to just using the pre-paid calls if you consistently use more than 83 minutes of calls per month. However if you don t use 84 minutes of calls (EG you don t speak much on the phone and use Google Hangouts instead of SMS) then it s not good value. Also the advertised data use is $5 per 100MB, which is way below what is needed for a typical user with an Android phone. My mother in law was barely able to stick within a limit of 300MB/month when that was her limit, but while using the Aldo 2G/month bolt-on she s increased her data usage. The smallest of the new plans costs $20 per month, it provides 300 minutes of calls and includes 300MB of data. For an extra $7 you can get another 300MB of data. For my mother in law it seems that the cheapest option on the new plans would be $27 per month, that would cover the 60 minutes of calls she might make and the 450MB of data she s probably using. That s significantly more expensive than her previous cost of $15 for 2G of data and $7.20 for calls and has the additional difficulty that I would have to be more involved in helping her avoid excessive data use. The 2G data bolt-on was really good for some of my relatives, when they use that and configure their phones not to update software over 3G they never had to ask me about any problems related to excess data use. So my mother in law is facing an extra $5 per month (or maybe more depending on data use) and more time spent calling me for tech support. The data bolt on that Aldi is going to offer in future is $30 for 3G of data to replace the previous offer of $15 for 2G of data. The cost will be unchanged for anyone who uses between 2G and 3G a month, for everyone who uses less than 2G or more than 3G the data bolt-on will cost more. There is simply no possibility for any Aldi data-only customer to save on data use. The only way someone who uses a moderate amount of data could save money is if they use more than 160 minutes of calls and less than 1G of data. Disclaimer My analysis above is based on interpreting the Aldi web site. As with most telcos they aren t trying to make things easy in this regard, it seems that the consensus of opinion among telcos is to use complex pricing to make it difficult to compare and reduce competitive pressure. I blame any inaccuracies in my analysis on the Aldi web site. Why Aldi Shouldn t Mislead Customers Aldi isn t primarily a mobile phone company, their main business is running a supermarket. The trust of customers is important to them, raising prices when competition goes away is one thing, but misleading customers about it is another. If Aldi were to honestly say now that Kogan Mobile no longer exists there is nothing forcing us to have low prices then I d have a lot more respect for their company and be more inclined to shop at their supermarket. It s a sad indictment of our society that I need to include a why lying is wrong section in such a blog post.

• [1] https://www.aldimobile.com.au/corrective-notice
• [2] https://www.aldimobile.com.au/newplans

I will try to report my Debian activities here. I am trying to retake them and as I'm usually busy at work, I have limited amount of time to do so, they stand small for now. A new mailing list, debian-astro, has been created. This was requested to create a space to allow a discussion space around astronomy for Debian, both for professionals and amateurs, to potentially look into a blend, and in general to talk about packaging and development of astronomy-related tools into Debian. Thanks to those interested on making this happen. Go subscribe today!

That's it, I'm going to do it: I have now committed myself to writing a scalable, caching, reverse HTTP proxy. The biggest question right now is implementation language; obviously "threading" of some kind is required so it is a choice between Perl's anyevent, Python's twisted, Rubys event machine, or node.js. I'm absolutely, definitely, not going to use C, or C++. Writing a a reverse proxy in node.js is almost trivial, the hard part will be working out which language to express the caching behaviour, on a per type, and per-resource basis. I will ponder.

I have just released version 1.7.2 of Obnam, my backup program. While I was releasing 1.7.1, I found a new problem, so I fixed that. Due to sillinesses in my CI/release system, I had to bump the version number to 1.7.2. Version 1.7.2, released 2014-03-22 Bug fixes:

• Fix another bug in the FUSE plugin's file reading code, found during the release process of 1.7.2.

Version 1.7.1, released 2014-03-22

• The dump-repo command now outputs JSON instead of YAML. The dependency on PyYAML is no longer.

Bug fixes:

• Nemo Inis found a bug in the FUSE plugin (obnam mount), where Obnam would return the wrong data when the program reading the file didn't read the whole file from the beginning in one read(2) system call.
• The test suite now skips tests that require use of extended attributes in the user namespace. This should allow the test suite to be run on more build servers run by various distributions.

Core Rendering with Glamor I ve hacked up the intel driver to bypass all of the UXA paths when Glamor is enabled so I m currently running an X server that uses only Glamor for all rendering. There are still too many fall backs, and performance for some operations is not what I d like, but it s entirely usable. It supports DRI3, so I even have GL applications running. Core Rendering Status I ve continued to focus on getting the core X protocol rendering operations complete and correct; those remain a critical part of many X applications and are a poor match for GL. At this point, I ve got accelerated versions of the basic spans functions, filled rectangles, text and copies. GL and Scrolling OpenGL has been on a many-year vendetta against one of the most common 2D accelerated operations copying data within the same object, even when that operation overlaps itself. This used to be the most performance-critical operation in X; it was used for scrolling your terminal windows and when moving windows around on the screen. Reviewing the OpenGL 3.x spec, Eric and I both read the glCopyPixels specification as clearly requiring correct semantics for overlapping copy operations it says that the operation must be equivalent to reading the pixels and then writing the pixels. My CopyArea acceleration thus uses this path for the self-copy case. However, the ARB decided that having a well defined blt operation was too nice to the users, so the current 4.4 specification adds explicit language to assert that this is not well defined anymore (even in the face of the existing language which is pretty darn unambiguous). I suspect we ll end up creating an extension that offers what we need here; applications are unlikely to stop scrolling stuff around, and GPUs (at least Intel) will continue to do what we want. This is the kind of thing that makes GL maddening for 2D graphics the GPU does what we want, and the GL doesn t let us get at it. For implementations not capable of supporting the required semantic, someone will presumably need to write code that creates a temporary copy of the data. PBOs for fall backs For operations which Glamor can t manage, we need to fall back to using a software solution. Direct-to-hardware acceleration architectures do this by simply mapping the underlying GPU object to the CPU. GL doesn t provide this access, and it s probably a good thing as such access needs to be carefully synchronized with GPU access, and attempting to access tiled GPU objects with the CPU require either piles of CPU code to de-tile accesses (ala wfb), or special hardware detilers (like the Intel GTT). However, GL does provide a fairly nice abstraction called pixel buffer objects (PBOs) which work to speed access to GPU data from the CPU. The fallback code allocates a PBO for each relevant X drawable, asks GL to copy pixels in, and then calls fb, with the drawable now referencing the temporary buffer. On the way back out, any potentially modified pixels are copied back through GL and the PBOs are freed. This turns out to be dramatically faster than malloc ing temporary buffers as it allows the GL to allocate memory that it likes, and for it to manage the data upload and buffer destruction asynchronously. Because X pixmaps can contain many X windows (the root pixmap being the most obvious example), they are often significantly larger than the actual rendering target area. As an optimization, the code only copies data from the relevant area of the pixmap, saving considerable time as a result. There s even an interface which further restricts that to a subset of the target drawable which the Composite function uses. Using Scissoring for Clipping The GL scissor operation provides a single clipping rectangle. X provides a list of rectangles to clip to. There are two obvious ways to perform clipping here either perform all clipping in software, or hand each X clipping rectangle in turn to GL and re-execute the entire rendering operation for each rectangle. You d think that the former plan would be the obvious choice; clearly re-executing the entire rendering operation potentially many times is going to take a lot of time in the GPU. However, the reality is that most X drawing occurs under a single clipping rectangle. Accelerating this common case by using the hardware clipper provides enough benefit that we definitely want to use it when it works. We could duplicate all of the rendering paths and perform CPU-based clipping when the number of rectangles was above some threshold, but the additional code complexity isn t obviously worth the effort, given how infrequently it will be used. So I haven t bothered. Most operations look like this:

Allocate VBO space for data
Fill VBO with X primitives
loop over clip rects  
    glScissor()
    glDrawArrays()
 

This obviously out-sources as much of the problem as possible to the GL library, reducing the CPU time spent in glamor to a minimum. A Peek at Some Code With all of these changes in place, drawing something like a list of rectangles becomes a fairly simple piece of code: First, make sure the program we want to use is available and can be used with our GC configuration:

prog = glamor_use_program_fill(pixmap, gc,
                               &glamor_priv->poly_fill_rect_program,
                               &glamor_facet_polyfillrect);
if (!prog)
    goto bail_ctx;

Next, allocate the VBO space and copy all of the X data into it. Note that the data transfer is simply memcpy here that s because we break the X objects apart in the vertex shader using instancing, avoiding the CPU overhead of computing four corner coordinates.

/* Set up the vertex buffers for the points */
v = glamor_get_vbo_space(drawable->pScreen, nrect * (4 * sizeof (GLshort)), &vbo_offset);
glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
glVertexAttribDivisor(GLAMOR_VERTEX_POS, 1);
glVertexAttribPointer(GLAMOR_VERTEX_POS, 4, GL_SHORT, GL_FALSE,
                      4 * sizeof (GLshort), vbo_offset);
memcpy(v, prect, nrect * sizeof (xRectangle));
glamor_put_vbo_space(screen);

Finally, loop over the pixmap tile fragments, and then over the clip list, selecting the drawing target and painting the rectangles:

glEnable(GL_SCISSOR_TEST);
glamor_pixmap_loop(pixmap_priv, box_x, box_y)  
    int nbox = RegionNumRects(gc->pCompositeClip);
    BoxPtr box = RegionRects(gc->pCompositeClip);
    glamor_set_destination_drawable(drawable, box_x, box_y, TRUE, FALSE, prog->matrix_uniform, &off_x, &off_y);
    while (nbox--)  
        glScissor(box->x1 + off_x,
                  box->y1 + off_y,
                  box->x2 - box->x1,
                  box->y2 - box->y1);
        box++;
        glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, nrect);
     
 

GL texture size limits X pixmaps use 16 bit dimensions for width and height, allowing them to be up to 65536 x 65536 pixels. Because the X coordinate space is signed, only a quarter of this space is actually useful, which makes the useful size of X pixmaps only 32767 x 32767. This is still larger than most GL implementations offer as a maximum texture size though, and while it would be nice to just say we don t allow pixmaps larger than GL textures , the reality is that many applications expect to be able to allocate such pixmaps today, largely to hold the ever increasing size of digital photographs. Glamor has always supported large X pixmaps; it does this by splitting them up into tiles, each of which is no larger than the largest texture supported by the driver. What I ve added to Glamor is some simple macros that walk over the array of tiles, making it easy for the rendering code to support large pixmaps without needing any special case code. Glamor also had some simple testing support you can compile the code to ignore the system-provided maximum texture size and supply your own value. This code had gone stale, and couldn t work as there were parts of the code for which tiling support just doesn t make sense, like the glyph cache, or the X scanout buffer. I fixed things so that you could leave those special cases as solitary large tiles while breaking up all other pixmaps into tiles no larger than 32 pixels square. I hope to remove the single-tile case and leave the code supporting only the multiple-tile case; we have to have the latter code, and so having the single-tile code around simply increases our code size for not obvious benefit. Getting accelerated copies between tiled pixmaps added a new coordinate system to the mix and took a few hours of fussing until it was working. Rebasing Many (many) Times I m sure most of us remember the days before git; changes were often monolithic, and the notion of changing how the changes were made for the sake of clarity never occurred to anyone. It used to be that the final code was the only interesting artifact; how you got there didn t matter to anyone. Things are different today; I probably spend a third of my development time communicating how the code should change with other developers by changing the sequence of patches that are to be applied. In the case of Glamor, I ve now got a set of 28 patches. The first few are fixes outside of the glamor tree that make the rest of the server work better. Then there are a few general glamor infrastructure additions. After that, each core operation is replaced, one a at a time. Finally, a bit of stale code is removed. By sequencing things in a logical fashion, I hope to make review of the code easier, which should mean that people will spend less time trying to figure out what I did and be able to spend more time figuring out if what I did is reasonable and correct. Supporting Older Versions of GL All of the new code uses vertex instancing to move coordinate computation from the CPU to the GPU. I m also pulling textures apart using integer operations. Right now, we should correctly fall back to software for older hardware, but it would probably be nicer to just fall back to simpler GL instead. Unless everyone decides to go buy hardware with new enough GL driver support, someone is going to need to write simplified code paths for glamor. If you ve got such hardware, and are interested in making it work well, please take this as an opportunity to help yourself and others. Near-term Glamor Goals I m pretty sure we ll have the code in good enough shape to merge before the window closes for X server 1.16. Eric is in charge of the glamor tree, so it s up to him when stuff is pulled in. He and Markus Wick have also been generating code and reviewing stuff, but we could always use additional testing and review to make the code as good as possible before the merge window closes. Markus has expressed an interest in working on Glamor as a part of the X.org summer of code this year; there s clearly plenty of work to do here, Eric and I haven t touched the render acceleration stuff at all, and that code could definitely use some updating to use more modern GL features. If that works as well as the core rendering code changes, then we can look forward to a Glamor which offers GPU-limited performance for classic X applications, without requiring GPU-specific drivers for every generation of every chip.

The GSoC student application period is over, and the last two days were pretty interesting. For a few years now, Olly Betts has provided us with a spreadsheet to graph the number of applicants to an organization over time. Here s the graph for Debian this year: (Historical graphs: 2013, 2012. Spreadsheet available from Olly s blog) On Wednesday, I was thinking hmm, 30 applicants, this is a slow year . Well, the number of proposals more than doubled in the last two days, to conclude on a whooping 68 applications! The last one was submitted just three seconds before the deadline If you want to take a look at the proposals, head over to the Debian wiki. Time to get on reviewing! The final student acceptances will be published in just less than a month, on April 21st.

Christine's accidential blog spam on planet.d.o just now gave me the chance to re-read the comments in her post. The state from back then is still the current state on up-to-date Debian unstable:

• Microphone button does nothing.
• USB 3.0 docking station's display does not work thanks to the content mafiaa with an admittedly small petition trying to fix this. Obviously it is going to be ignored.
• No one using Debian seems to care about the fingerprint reader.
• UMTS/WWAN modem works fine on Windows, but Linux loses connection to the USB device all the time. As a result, UMTS does not work

The last item has the most impact on me. The need to tether when you have a dedicated SIM card, built-in modem, and good antennas in your laptop is... infuriating. Especially as it's working as intended on Windows. As an added benefit, even though I saved the PIN in network manager, it asks me for the PIN every time I log in and every time after hibernating. For a device which I can't use in the first place. Argh!

Installing fresh hot Debian 7.0 on a shiny new ThinkPad X1 Carbon laptop turns out to be easy as cake. You just need to make sure to grab the wifi firmware from unstable instead of the all-in-one firmware tarballs, which contain a version that is missing a couple required files.

wget http://cdimage.debian.org/debian-cd/7.0.0/multi-arch/iso-cd/debian-7.0.0-amd64-i386-netinst.iso
dd if=debian-7.0.0-amd64-i386-netinst.iso of=/dev/sdb

(Make sure /dev/sdb is really the usb stick you want to overwrite with the installer!)

wget http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_0.38_all.deb

And put that on a second usb stick for the installer to load the firmware off of. As far as I can tell, everything works. (Did not mess around with the fingerprint reader, don't care.)

I just donated $500 to OpenHatch. Here's why you should donate too:

1. Diversity in open source matters. We can't keep making the software the world runs on without involving people of all sorts, from all backgrounds.
2. OpenHatch is run by community members who I've known for years and trust. They care about data-driven effectiveness and are always getting better at what they do.
3. A rising tide floats all boats. More contributors == more awesome.
4. If you donate before December 24th, your donation makes twice the difference.

Diversity and education initiatives are the reason I'm a part of the free and open source software community today. (Thanks, Debian Women.) You don't have to donate $500 to make a difference. $5, $10, $25 from a hundred people all adds up. Please join me in supporting OpenHatch today.

I ve made a new release of my curiously popular SteamOS derivative, and given it a new name: Stephenson s Rocket. You can download the new release from here. Release highlights:

• Updated to alchemist_beta 93
• Support for pre-HD5000 Radeon cards
• Support for motherboard-based FakeRAID
• Video tutorial series about an hour of instructional material for all competency levels

Using the AWS donation, David Suarez and myself have been able to rebuild the whole archive with Clang 3.4.
The rebuild has been done January 10th but, with my new job, I did not find the time to publish the result.
Releases after releases, the results are getting better and better. Currently, 2193 packages in the archive are failing to build from source.
That is roughly the same number of build failures as with the precedent rebuild with Clang 3.3.
However, this is good news for two reasons:
* the number of new packages in Debian increased (18854 at time of the 3.3 release, 21204 for the 3.4)
* clang 3.4 has more checks and error detections. I also started to update clang to make it closer to gcc. For example, I transformed wrong usage of -O (> 6) error to be treated as regular warning. However, a critical bug has emerged during this release. When using -D_FORTIFY_SOURCE=2 (which is the case of many Debian packages), the binaries produced freeze (infinity loop in the ASM). This has been reported upstream as bug 16821 and concerns about 150 packages (including Firefox, gcc, LLVM, etc). Hopefully, this will be fixed in 3.5 (this is unlikely for 3.4.1). About the new build failures, now, Clang triggers an error (or warning + -Werror) on: * Wrong usage of the default argument (should be done in the definition)
16 occurrences * Usage of C++11 feature without the appropriate argument
7 occurrences * Unused static const declaration
5 occurrences * Recursive template instantiation exceeded
4 occurrences * Defitinion of a builtin function
3 occurrences * Read-only variable is not assignable
2 occurrences By the way, I proposed a Google Summer of Code Project to work faster on a support of Debian built by Clang. As requirements, I asked students to fix some bugs, they already did a great job.

Keeping your DVD collection safe from scratches and curious children fingers while still having it available when you want to see a movie is not straight forward. My preferred method at the moment is to store a full copy of the ISO on a hard drive, and use VLC, Popcorn Hour or other useful players to view the resulting file. This way the subtitles and bonus material are still available and using the ISO is just like inserting the original DVD record in the DVD player. Earlier I used dd for taking security copies, but it do not handle DVDs giving read errors (which are quite a few of them). I've also tried using dvdbackup and genisoimage, but these days I use the marvellous python library and program python-dvdvideo written by Bastian Blank. It is in Debian already and the binary package name is python3-dvdvideo. Instead of trying to read every block from the DVD, it parses the file structure and figure out which block on the DVD is actually in used, and only read those blocks from the DVD. This work surprisingly well, and I have been able to almost backup my entire DVD collection using this method. So far, python-dvdvideo have failed on between 10 and 20 DVDs, which is a small fraction of my collection. The most common problem is DVDs using UTF-16 instead of UTF-8 characters, which according to Bastian is against the DVD specification (and seem to cause some players to fail too). A rarer problem is what seem to be inconsistent DVD structures, as the python library claim there is a overlap between objects. An equally rare problem claim some value is out of range. No idea what is going on there. I wish I knew enough about the DVD format to fix these, to ensure my movie collection will stay with me in the future. So, if you need to keep your DVDs safe, back them up using python-dvdvideo. :)

Since introduction of Developer's Certificate of Origin in phpMyAdmin, we've struggled with automatically checking pull requests on GitHub that they match this. First attempt was to integrate this check into Travis environment, but that proven to be hard to understand by potential contributors as it did not give direct feedback what went wrong. So it was still useful for us, but still we had to explain the situation. With recent flood of contributions from potential GSoC students, it became quite tedious task. So let's automate that. GitHub has quite powerful API, so it should not be that hard. Looking at Webhooks documentation, it is quite easy to get hooked on pull request creation and updates and checking commits and adding comments is just a piece of cake. The hardest choice was choosing language in which to implement it :-). While not finding binding for GitHub in any of my favorite language packaged in Debian. I've decided to hack this quickly in PHP without using any library and if this turns out to be limitation in future, it can be easily rewritten. First incarnation of our commit checker did check just Signed-Off-By lines in commit messages, but I've found that there might be some other useful checks. So the script got extended for various simple coding style violations, which we see quite often like wrong indentation or using DOS end of lines (the example of all fired checks can be found in pull request 1081). You can find the code for it in our scripts repository.

Filed under: English phpMyAdmin 0 comments Flattr this!

I woke up at 2am, and then spent over an hour trying to get back to sleep. That was phenomenally annoying. Then at 5am, Zoe's white noise app on her Nexus 7 decided to go a bit wonky (as it does from time to time), which caused her to wake up. I couldn't convince her tablet to behave, so I just let her get in bed with me, but neither of us went back to sleep. I think at about 6am I told her she could turn on the TV so I could try and squeeze in a bit more rest. I managed to forget to put the oats in the Thermomix when I made porridge this morning. It took me a while to figure out why the consistency and colour didn't look quite right when I dished it up. Yep, it was one of those mornings. Zoe had her trial ballet class this morning, at 9:45am in Coorparoo. I managed to get Zoe organised a bit early, so we were the first ones there. It's in a church hall, and has a nice floor, with a mirrored wall and barres on each long wall. Eventually the other girls arrived, there were 5 regulars in total. A good sized class. I had mixed feelings when I discovered that parents weren't normally able to be present in the dance studio to watch the classes. I was today, because it was a trial, but once Zoe starts regular classes, I'll have to wait outside. I'm disappointed I won't be able to watch, but it'll be nice to have 45 minutes to myself. Zoe did really well in the class today. She picked everything up very quickly, and I don't think she'll be negatively impacted by having entered in Term 2. She seemed very comfortable and looked like she enjoyed herself. Not long after we arrived, the heavens opened in a massive downpour, which continued when we had to leave. It was a fair dash back to the car. I'd had plans of a picnic lunch in New Farm Park, but scrapped them on account of the weather. We got home, and had a late morning tea, and then Zoe wanted to play with her Marble Run. After that, we gave Smudge a good brushing and then Zoe wanted to do some craft and painting. I let Zoe set herself up, and it was fun to see what bits and pieces she chose to dig out of the arts and craft bins. She wanted to make another crown for Mummy's boss, but we don't have any crown making stuff at home (yet), so she ended up starting to decorate a wand and gluing a pom pom on a shoe box, before moving on to painting her cardboard box cubby house and rocket. She wanted to start doing some hand painting right around lunch time, but I managed to convince her to do that after lunch. We had some lunch, and then she did a little bit more painting and stickering before her nap. She passed out for her nap very quickly. After her nap, I asked her if she wanted to paint or do science, and without hesitation, she chose science! I delved into the "Weather" chapter of 365 Science Experiments and we did a couple with ice cubes and salt and then she saw one where you stick a balloon over the neck of a glass bottle and put it in hot water and the balloon "inflates", so we did that one as well. We also popped a balloon to simulate thunder. It was all nice and easy, without a lot of preparation required. After that, we did a bit of a clean up and then Zoe watched some of her DVDs from the library while she waited for Sarah to arrive to pick her up. It was a good day today. No meltdowns.