The 2nd Shogi Denousen has began. This is the first cut-throat match between top-notch professional Shogi players(yes, there are such people) and the best crop of computer Shogi engines, 5 on 5. Shogi is a distant cousin of Chess. Unlike Chess, you may re-use captured pieces anywhere on the board anytime. It brings quite lot of additional complexities, and even after the defeat of Garry Kasparov in 1997, many considered that (at least top-level) human Shogi players have a great lead on computer Shogi engines. The situation had changed dramatically when a newcomer Shogi engine called Bonanza, developed by a Japanese chemist Kunihito Hoki, won the 16th World Computer Shogi Championship. Bonanza appeared totally out of the blue Hoki incorporated some new ideas developed in the field of computer Chess, and Bonanza beated existing engines with no mercy. Bonanza could even corner some professional Shogi players in 2007. Later Hoki released(but not strictly open-source) the source code of Bonanza, and the standard of computer Shogi has risen considerably since then. Finally, in the 1st Denousen last year, Kunio Yonenaga, long retired but possibly one of the greatest Shogi players in the history, was defeated by Bonkras, a clustered version of Bonanza developed by Eiki Itoh of Fujitsu. The first match of Denousen this year was held yesterday between Kouru Abe, an 18-year old prodigy from Aomori, and Shueso, which finished in 5th at the 22nd World Computer Shogi Championship. I hoped a close game, but Abe could beat Shueso quite easily. Shueso somehow could not bring its ability into full play, to my great disappointment. Next weekend(Mar. 30), we will see the second match between Shinichi Sato, another young pro, and Ponanza, developed based on Bonanza by Issei Yamamoto of The University of Tokyo. BTW, Debian already has the package of GPS Shogi, which won the 22nd World Computer Shogi Championship and considered by many the strongest Shogi engine available now (there is also gnushogi in Debian, but gnushogi is quite weak). You may have fun with

    $ xshogi -fsp gpsshogi

Unfortunately, we don t have good modern GUI for Shogi yet

A new relase 0.10.3 of Rcpp is now on CRAN and in Debian. This is the fourth release in the 0.10.* series, and further extends and solidifies the excellent Rcpp attributes. A few other bugs were fixed as well, and support for wide character strings has been added. We once again tested this fairly rigorously by checking against 86 of the 100 CRAN packages depending on Rcpp. All of these passed. So we do not expect any issues with dependent packages, but one never knows. The complete NEWS entry for 0.10.3 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.3 (2013-03-23)

• Changes in R code:
  • Prevent build failures on Windowsn when Rcpp is installed in a library path with spaces (transform paths in the same manner that R does before passing them to the build system).
• Changes in Rcpp attributes:
  • Rcpp modules can now be used with sourceCpp
  • Standalone roxygen chunks (e.g. to document a class) are now transposed into RcppExports.R
  • Added Rcpp::plugins attribute for binding directly to inline plugins. Plugins can be registered using the new registerPlugin function.
  • Added built-in cpp11 plugin for specifying the use of C++11 in a translation unit
  • Merge existing values of build related environment variables for sourceCpp
  • Add global package include file to RcppExports.cpp if it exists
  • Stop with an error if the file name passed to sourceCpp has spaces in it
  • Return invisibly from void functions
  • Ensure that line comments invalidate block comments when parsing for attributes
  • Eliminated spurious empty hello world function definition in Rcpp.package.skeleton
• Changes in Rcpp API:
  • The very central use of R API R_PreserveObject and R_ReleaseObject has been replaced by a new system based on the functions Rcpp_PreserveObject, Rcpp_ReleaseObject and Rcpp_ReplaceObject which shows better performance and is implemented using a generic vector treated as a stack instead of a pairlist in the R implementation. However, as this preserve / release code is still a little rough at the edges, a new #define is used (in config.h) to disable it for now.
  • Platform-dependent code in Timer.cpp now recognises a few more BSD variants thanks to contributed defined() test suggestions
  • Support for wide character strings has been added throughout the API. In particular String, CharacterVector, wrap and as are aware of wide character strings

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.2. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

Hello To check the validity of Debian dependencies in Debian package, Config::Model queries a remote web server to get the list of package version known to Debian. The first version of this check did sequential requests: when the cache was not very fresh, I had to wait more than 60s before getting results for complex package like padre. That was very frustrating (but less frustrating than checking package names manually) For the following version, I addedhacked AnyEvent in Dpkg model to run parrallel queries. This went much faster but gaves weird results: before getting a response from Debian server, the packages were flagged as unknown. To get consistent results, running twice cme check dpkg was required. So, at new year, I ve decided to bite the bullet and implement correctly value checks with asynchronous queries to remote server. This new feature is now ready and will be delivered in Config::Model 2.030. cme will now return consistent results. This new release is mostly backward compatible. You may notice some quirks with some other modules based on Config::Model:

• Current Config::Model::Dpkg will returns unconsistent results as usual
• Tk UI will not show correct package status (i.e. packages may be wrongly shown as unknown)
• config-model-edit process must be killed if it refuses to exit.
• Tk UI non-regression tests will block

These quirks will disappear once these modules are updated. This should not be long since all the updates are ready in github. All the best
Tagged: Config::Model, debian, dpkg, Perl

Am I the only one who logically inferred this from the Ubuntu for Android's tagline "One device to rule them all"?

Following up on using Debian on the WeTab with GNOME Shell I figured accelerated video using the built in CrystalHD to save battery power and CPU cycles would be nice to have. There's even a Debian package available but not for gstreamer 1.0 (which is used by GNOME 3.6) so I had a look at gstreamer's plugin writers guide and porting guide and updated the driver. Packages are here until there's a new upstream version or Debian package release. This blog is flattr enabled.

Let's see if we will have 82 open bugs next week ;) Current trend points towards week 16/17. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 718
  • Affecting wheezy: 93 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 47 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 16 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 9 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 27 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 46 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 17 bugs are in packages that are unblocked by the release team.
      • 29 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!	212 (129+83)	+212 (+129/+83)
7	release+1	194 (128+66)	+194 (+128/+66)
8	release+2	206 (144+62)	+206 (+144/+62)
9	release+3	174 (105+69)	+174 (+105/+69)
10	release+4	120 (72+48)	+120 (+72/+48)
11	release+5	115 (74+41)	+115 (+74/+41)
12	release+6	93 (47+46)	+93 (+47/+46)
13	release+7
14	release+8
15	release+9
16	release+10
17	release+11
18	release+12

Graphical overview of bug stats thanks to azhag:

Update: This isn't actually that much better than letting them access the private key, since nothing is stopping the user from running their own SSH agent, which can be run under strace. A better solution is in the works. Thanks Timo Juhani Lindfors and Bob Proulx for both pointing this out. At work, we have a shared SSH key between the different people manning the support queue. So far, this has just been a file in a directory where everybody could read it and people would sudo to the support user and then run SSH. This has bugged me a fair bit, since there was nothing stopping a person from making a copy of the key onto their laptop, except policy. Thanks to a tip, I got around to implementing this and figured writing up how to do it would be useful. First, you need a directory readable by root only, I use /var/local/support-ssh here. The other bits you need are a small sudo snippet and a profile.d script. My sudo snippet looks like:

Defaults!/usr/bin/ssh-add env_keep += "SSH_AUTH_SOCK"
%support ALL=(root)  NOPASSWD: /usr/bin/ssh-add /var/local/support-ssh/id_rsa

Everybody in group support can run ssh-add as root. The profile.d goes in /etc/profile.d/support.sh and looks like:

if [ -n "$(groups   grep -E "(^  )support(  $)")" ]; then
    export SSH_AUTH_ENV="$HOME/.ssh/agent-env"
    if [ -f "$SSH_AUTH_ENV" ]; then
        . "$SSH_AUTH_ENV"
    fi
    ssh-add -l >/dev/null 2>&1
    if [ $? = 2 ]; then
        mkdir -p "$HOME/.ssh"
        rm -f "$SSH_AUTH_ENV"
        ssh-agent > "$SSH_AUTH_ENV"
        . "$SSH_AUTH_ENV"
    fi
    sudo ssh-add /var/local/support-ssh/id_rsa
fi

The key is unavailable for the user in question because ssh-add is sgid and so runs with group ssh and the process is only debuggable for root. The only thing missing is there's no way to have the agent prompt to use a key and I would like it to die or at least unload keys when the last session for a user is closed, but that doesn't seem trivial to do.

The Standalone Sysadmin asks, How do you manage database server instances? :

Do you have one (or a few) centralized database servers, either standalone or clustered, or do you spread the load like we are currently?

His argument for centralisation is one of easing the management burden of configuration and backups, whereas the distributed approach eliminates a central point of failure and performance degradation. I go for distributed, all the way. For a start, we run so many databases for so many customers that there s no way on earth we could stand up a small number of database servers and handle all the load (hell, we ve got single customers who consume a cluster of machines with 384GB of RAM and all the SSDs you can eat). Security and permissions is a whole other kettle of fish; the contortions we d have to do to allow customers the level of management they need with a centralised database system would be immense. Then there s the need of some customers for MySQL, some for PgSQL, different performance tuning for different workloads nope, centralised DBs don t work for us. Given this, we ve bitten the bullet and solved pretty much all of the management problems. Installation and configuration is all handled via Puppet, and backups are trivial the same system that installs the DB server itself also drops a hook script that the backup agent uses to know that it has to dump a database server. Monitoring that this backup is taking place successfully is also automatically provisioned, so we know that we re not missing anything. Ultimately, this same approach applies to practically anything that you re tossing up between centralised and distributed. At scale, you can never rely on centralisation, so you may as well bite the bullet and learn how to do it distributed pretty much from the start. That saves some serious system shock when you discover what your hardware vendor wants for the next step up in big iron hardware

This Clevo laptop is a new machine and like a lot of new machines, not all of its hardware has drivers in the current stable release of debian. Happily, there is a driver for its rtl8723ae wireless networking device in the later 3.8 Linux kernel versions. So it s just a case of installing the package called kernel-package and following the instructions in it, to make a new linux-image package with the latest drivers in it. One small thing which tripped me up is that you usually need to write make-kpkg rootcmd fakeroot initrd kernel-image now. I forgot the initrd option at first.

(btw, the source is on github) During the sprints at PyCon in a spare moment after some awesome OpenGov hacking, I ended up doing the unthinkable: rpython support in Hy. Yes. That s right. Lisp > Python > C > x86 instructions. The thanks here goes to Romain Guillebert - who is a really funny rpythonista and took the time to sit down and help me with this frankly insane idea. It works, though. I filed a bug on shipping rpython bits from PyPy s Debian package (hi, tumbleweed!), which should make building this a skitch easier. Finally, and unrelatedly, I also just got a .hy > .pyc compiler working (huzzah!) which means no one will ever know we wrote anything in Lisp, ever. As always, play with the REPL, star the code or have a laugh with it. Let me know what you hack up! I ll post the lightning talk I gave after it s posted :)

On wednesday 7. of November I gave a talk at EPFSUG in Brussels about FreedomBox. EPFSUG is an interest group of Free Software users working inside the European Parliament. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for a decade or more. The goal is a small, cheap physical box looking like and operating like an internet gateway or wifi router many are accustomed to nowadays - but with three additions:

• Easy and intuitive to setup and personalize for non-geeks
• Offers routines to help you protect your privacy
• Offers routines to let you help others in need of privacy

"Privacy" is commonly mistaken as "secrecy": Privacy is to keep you in control of your information - you can then use that control to keep secrets from others or to share with others as you like. Talking about personal privacy in the European Parliament can seem a bit of a stretch. It is not a home but a (huge) office space, where it is perhaps less obvious that you should treat some information as personal, or that you are even allowed to do so. Try watch the videos, and if you have questions then please don't hesitate to get in touch with me about them. At the EPFSUG meeting was also a presentation by an emplyee who had succesfully installed and used Free Software at the internal network of the Parliament, but then later told that it wasn't allowed - because the IT staff need to be in control of your computer activities at the place! The head of IT services at the Parliament attended the meeting and gave a short improvised talk at the end, expressing positive interest in behalf of the established IT services at the place towards our grassroots activities - and even praising explicitly EPFSUG as being the ideal place for all EU citizens to ask questions about Free Software in relation to the European Parliament. See for yourself in the video of Giancarlo! Thanks a lot especially to Erik Josefsson for making this event reality! Slides, sources and videos from the event.

Is Croatian kiberkomunist (i.e., cyber-communist ) artist and hacker Marcell Mars living a secret life as a Nantucket Reds -wearing preppie from the American northeast?

Noticed with a lot of happiness today that Gnome extensions list a new one showing weather information. (:

Today Sunday November 11th I give a talk at FSCONS in Gothenburg about FreedomBox. FSCONS is an annual scandinavian hacker conference, with a very friendly attitude and atmosphere. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for more than a decade. The project is exciting in that is frames a common dream among lots of hackers and therefore sparks new innovation and renewed commitment. The goal is frustrating to tackle, because us hackers most often solve problems close to ourselves (a.k.a. is driven by "an itch to scratch"), and only very few of us are interface designers, which are crucially needed to make things usable for non-geeks. Slides and sources for them.

Photo uploader has just got first release under new maintainer. It mostly fixes various bugs, but the project is going on. Full list of changes:

• Compatibility with Python 3.
• Fix build with Python 2.7.
• Added documentation in Sphinx format.
• Updated imageshack support.

Thanks to Andrew Shadura for taking over this tool. PS: The package should be soon available in Debian as well.

Filed under: Debian English Photo-Uploader 0 comments Flattr this!

I just pushed out a new python-dbusmock release 0.6. Calling a method on the mock now emits a MethodCalled signal on the org.freedesktop.DBus.Mock interface. In some cases this is easier to track than parsing the mock s log or using GetMethodCalls. Thanks to Lars Uebernickel for this. DBusMockObject.AddTemplate() and DBusTestCase.spawn_server_template() can now load local templates from your own project by specifying a path to a *.py file as template name. Thanks to Lucas De Marchi for this feature. I also wrote a quite comprehensive template for systemd s logind. It stubs out the power management functionality as well as user/seat/session objects, and is convincing enough for loginctl. Some bits like AttachDevice is missing, as this sounds unlikely to be required for D-BUS mock tests, but please let me know if you need anything else. The mock processes now terminate automatically if their connected D-BUS goes down, as advertised in the documentation. You can get the new tarball from Launchpad, and I uploaded it to Debian experimental now. Enjoy!

The following is what I usually do when I want to debianize a Haskell stuff from Hackage. This is a personal recipe, by no means official procedure or such. I may be wrong, badly at that.

1. Check pkg-haskell repository whether your intended package already exists or not. Somebody might work on it already.
2. Find the webpage of your intended package at HackageDB, then download Cabal source package . Untar it. The tarball filename should be changed to fit the Debian source package convention. For example, if the original name is something like foobar-1.0.tar.gz, then it should be haskell-foobar_1.0.orig.tar.gz.
3. File ITP. reportbug is your friend.
4. Run cabal-debian in untared dir:

    $ cabal-debian --debianize --quilt
   

   We do have the upstream tarball, so use quilt. See http://wiki.debian.org/UsingQuilt. It might give you warnings about changelog. debian/changelog doesn t exist yet, so ignore it.
5. Now read http://wiki.debian.org/Haskell/CollabMaint/Processes and http://wiki.debian.org/Haskell/CollabMaint/PackageTemplate carefully. Then do things as they say. These two are short, but well-written instructions. Edit the generated debian/control appropriately. Do not forget to make your debian/copyright machine-friendly. See http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/.
6. Test whether your package is flawless and really buildable. Do lintian. Use pbuilder.

    $ lintian haskell-foobar_1.0-1_amd64.changes
    # pbuilder --build haskell-foobar_1.0-1.dsc
   

7. Read http://wiki.debian.org/Haskell/CollabMaint/DarcsBasic. Darcs is quite easy to use, and you don t have to be the master of Darcs to merely debianize things anyway. Basically, what I usually do is

    $ darcs record -a; darcs push --repo=debian
   

   Darcs is well-suited to Haskell-related development, but seems you can use Git, too.
8. Change debian/changelog. UNRELEASED in the first line should be unstable or experimental . Do not forget to close ITP.
9. Finally, do

    $ debuild -tc; debcommit -r; debrelease; darcs push --repo=debian
   

   That s all folks!

As part of the DebConf13 fundraising effort, a generous sponsor, Brandorr Group, has proposed to start a matching fund in USD for DebConf13; in place through the end of April 30th. The rules are quite simple:

• for each dollar donated by an individual to DebConf13 through the mechanism, Brandorr Group will donate another dollar;
• individual donations will be matched only up to 100 USD each;
• only donations in USD will be matched;
• Brandorr Group will match the donated funds up to a maximum total of 5 000 USD;
• this generous offer will only stay in place through the end of April 30th, please act quickly, and help spread the word!

For details, please see our Monetary support from individuals page, which also has a short url, for convenience: http://deb.li/dc13donate. Help welcome As always, the DebConf team is looking for volunteers. Some jobs need technical skills, but many DebConf tasks are about working to deadlines on non-technical issues (e.g. fundraising, budgeting, talk scheduling). You can see more information about some of the jobs to be done on the DebConf wiki. Please do think about getting involved and sharing your ideas with us, to help us make DebConf an even more useful event for Debian in the future. We look forward to welcoming you to Vaumarcus!