Last week-end, I’ve participated Perl/QA hackathon in Paris.
Here’s a short summary of the main activities during this week-end. I was not in the best of shape due to a nasty (biological) bug that wore me down before the hackathon.
First of all, I discussed with rjbs about the bunch of debian patches I’ve written for Software::License. These patches (and hacks) are used in Debian to provide licenses summaries in Debian::Dpkg::Copyright model to help write Debian copyright files. License management is boring but necessary. cme and Software::License help in making this task slightly less boring. Ricardo kindly suggested some modifications and agreed to include my patches. I implemented these modifications directly during the hackathon.
The other tasks during this week-end were (not necessarily in that order):
- I discussed with alanhaggai and gave him some ideas to fix his Archive::Zip module
- I did a live demo of Debian packaging to ribasushi: I updated the Debian package libdbix-class-schema-loader-perl from CPAN and uploaded it in Debian.
- I presented how to package Perl modules for Debian. renormalist will package his own module Data::Dpath and its dependencies for Debian. I will sponsor his packages once they are available on Debian perl’s team git repository. Unless gregoa beats me to it
- I discussed with Slaven Rezic some binding weirdness found in Perl/Tk HList. Config::Model’s graphical interface provide a viewer widget and and editor widget for configuration items. As expected, the viewer is invoked by a single left click. One would expect a double click to invoke the editor widget. But the double click bindinngdoes not owrk in HList when the single click is used. Currently the editor widget is invoked with a right-click, which is not user-friendly. According to Slaven, the bug might be hidden quite deep in Perl/Tk guts. Fixing it won’t be easy.
- As a Debian/sid user, I’ve been quite spoiled: I’ve always had a recent Perl available on my system. I’ve neved had to compile Perl since my HPUX days back in last century. However, Config;:Model tests failed with Perl 5.15.9, a development version not available in Debian (sid is not that unstable). Thanks to Xavier Caron, I’ve learned about perlbrew and cpanminus to reproduce this bug and fix the issue. Many apologies to miyagawa for asking dumb questions about cpanm: the disctinction between runtime and build time does not apply to cpan minus. I guess that’s the drawback of wearing 2 hats (Debian dev hat and Perl dev hat): your brain may get confused and you conflate issues. Oops.
Many thanks to FreeSide who sponsored my travel, to the hackathons organisers and to all the participants for their welcome.
All the best
As maintainer of libwx-scintilla-perl, I had to update the package to update a dependency declation to close bug #662427. The dependency was good enough for the package to work but it blocked the linpng15 transition.
This is yet another detail to remember when updating package: whether the dependencies are impacted by a transition. As I’m really bad at remembering such details, I’ve added the relevant check in the dpkg control source model used by cme.
Now running ‘cme check dpkg’ will warn you if a dependency impacts a transition. And ‘cme fix dpkg’ will fix you dependency list as resquested by a transition. Well, that holds true for the transition I’m aware of. Feel free to contact me if more transition checks are needed.
For those who are curious (or want to send me a patch for another transition), here’s the actual implementation of these new checks.
All the best
I’ve (finally) released a new version of Config::Model. The main change for users is the deprecation of the config-edit program in favor of cme program. Instead of using options, this cme uses command keywords like git, so users will have more possibilities while typing less. bash completion is provided for cme command and options.
Following Debian annoucement regarding the recommended format of Debian copyright file (aka DEP-5), I’ve also updated the URL in Debian copyright model. If your package is already in a DEP-5 format, you can update the URL with this simple command:
cme fix dpkg-copyright
Check the wiki on github for more example of cme command.
All the best
In Debian package, the debian/control file has a specific syntax where each line must begin with a space and paragraphs are separated by a single ‘.’. If you want to follow DEP-5 syntax for debian/copyright files, you have a similar problem when comes the time to fill the license text for creative-common license: it’s easy to miss a space or a dot.
Let’s say I want to add a new section in the description of my package. Here’s the current description:
Description: module to automate definition of a DBIx::Class::Schema DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the definition of a DBIx::Class::Schema by scanning table schemas and setting up columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite and DB2. . Bare table definitions are fairly straightforward, but relationship creation is somewhat heuristic, especially with respect to choosing relationship types and names, as well as join types. The relationships generated by this module will probably never be as well-defined as hand-generated ones.
I want to add “This package is awesome” but I don’t want to be bothered by leading dots and white spaces.
First, I go in the package directory, then check the syntax with
$ cme check dpkg
Then create a loop directory, where the dpkg content will be mapped to a fuse directory:
$ mkdir loop $ cme fusefs dpkg -fuse-dir loop/ Mounting config on loop/ in background. Use command 'fusermount -u loop/' to unmount $ cat loop/control/binary/libdbix-class-schema-loader-perl/Description DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the definition of a DBIx::Class::Schema by scanning table schemas and setting up columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite and DB2. Bare table definitions are fairly straightforward, but relationship creation is somewhat heuristic, especially with respect to choosing relationship types and names, as well as join types. The relationships generated by this module will probably never be as well-defined as hand-generated ones.
loop/control/binary/libdbix-class-schema-loader-perl/Description with your favorite editor.
For the sake of this blog, I will use
echo to edit this file:
$ echo -e "\nThis module is awesome" >> loop/control/binary/libdbix-class-schema-loader-perl/Description
Now umount the loop (note that the actual debian/control is not changed before this step):
fusermount -u loop
Now the result:
$ cat debian/control [...] Description: module to automate definition of a DBIx::Class::Schema DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the definition of a DBIx::Class::Schema by scanning table schemas and setting up columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite and DB2. . Bare table definitions are fairly straightforward, but relationship creation is somewhat heuristic, especially with respect to choosing relationship types and names, as well as join types. The relationships generated by this module will probably never be as well-defined as hand-generated ones. . This module is awesome
Here’s another example to fill the license text for a license while respecting DEP-5 syntax, (done after the cme command):
# creating this dir will create a new DEP-5 # standalone license section with name CC-BY-30 mkdir loop/copyright/License/CC-BY-30 # fill the text part of the license wget http://creativecommons.org/licenses/by/3.0/legalcode -O - \ | html2text -style pretty > loop/copyright/License/CC-BY-30/text $ fusermount -u loop $ cat debian/copyright [...] License: CC-BY-30 . . . Creative_Commons . . Creative Commons Legal Code . . Attribution 3.0 Unported [...]
And that’s it. (note that cme command is new and is available only from version 2.004 of Config::Model)
Of course, there’s more than a way to do it: you can also run
cme edit dpkg and add or edit license text in the GUI (or in an editor launched by the GUI).
cme will take care of the syntax details.
All the best
Thanks to the effort of Felix Geyer (debfx) and Manuel Montecelo (mafm), most of SDL packages in Debian unstable are now up-to-date. These guys did a really great job: most of the time, I could upload the packages they prepared without modification. These guys should become DD, they have the skills. Ok, debfx has started the process (congrats) and mafm is still thinking about it…
Anyway, here the messages for all those who gave up packaging new SDL games for Debian because of stale SDL packages: SDL team is alive, the core SDL packages are now up-to-date, the wait is over.
This is true also for Perl SDL games: I’ve uploaded yesterday the latest Perl bindings to SDL. Unfortunately, this upload broke some games like frozen-bubble, pangzero and dizzy. But new versions compatible with new SDL perl are available upstream so theses games won’t be broken for long.
All the best
Following the suggestions provided after my post “What name for Config::Model’s new command line ? cfg or something else ?“, I’ve considered “cmc” and “cme” as a good candidates. But, “cmc” is used by a “C mol compiler” software (don’t ask me what it is…). “cme” is also a very good name.
So the winner is “cme”
Next version of Config::Model will provide
/usr/bin/cme. The old
config-edit command will be provided for a few months to preserve backward compatibility.
Thanks to all people who took the time to reply
All the best
As Damyan mentioned last summer in Debconf, the current command interface to Config::Model Perl module is rather cumbersome as it involves quite a lot of typing. First, config-edit command name is too long. Even with the help bash completion, this does not compare well with git or hg command. Then all operation require options. For instance, the -application option is required to specify what you will be working on. A required option is a good example of an oxymoron. Which may be funny but which is not user friendly…
So, here’s the synopsis of the new command I’m working on:
# edit dpkg config with GUI (Tk or curses, or readline) cfg edit dpkg # just check the validity of the file, show warnings # and suggested fixes # does not modify the file cfg check dpkg # check the file, remove deprecated parameters, # migrate data to new parameters and save cfg migrate dpkg # like migrate, but also apply all suggested fixes cfg fix dpkg # like migrate and modify configuration # with command line argument cfg modify dpkg source format="quilt (3.0)" # access dpkg parameters through a fuse file # system. data are saved when fs is unmounted cfg fusefs dpkg fuse-dir # dump configuration data in config-model format cfg dump dpkg # list all available applications cfg list # more general synopsis cfg [ global_options ] command application [ options ] arguments
This synopsis use dpkg as an example, but it could be used for any of the available models (e.g. ssh, lcdproc, multistrap …).
The main question I have for you is: Is cfg name good ? I mean it’s short, descriptive enough. But it’s also quite ugly. Does anyone have a better idea ?
And what do you think of the synopsis shown above ? Are the sub-command name descriptive enough ?
All the best