Posts from 2005–2010 temporarily unavailable.

Here’s a summary of some of the bugs against the Debian Policy Manual. Please consider getting involved, whether or not you’re an existing contributor.

Consensus has been reached and help is needed to write a patch

#228692 User/group creation/removal in package maintainer scripts

#685506 copyright-format: new Files-Excluded field

#759316 Document the use of /etc/default for cron jobs

#761219 document versioned Provides

#767839 Linking documentation of arch:any package to arch:all

#770440 policy should mention systemd timers

#793499 The Installed-Size algorithm is out-of-date

#823256 Update maintscript arguments with dpkg >= 1.18.5

#845715 Please document that packages are not allowed to write outside thei…

#874206 allow a trailing comma in package relationship fields

#902612 Packages should not touch users’ home directories

#905453 Policy does not include a section on NEWS.Debian files

#906286 repository-format sub-policy

#907051 Say much more about vendoring of libraries

Wording proposed, awaiting review from anyone and/or seconds by DDs

#662998 stripping static libraries

#682347 mark ‘editor’ virtual package name as obsolete

#737796 copyright-format: support Files: paragraph with both abbreviated na…

#756835 Extension of the syntax of the Packages-List field.

#786470 [copyright-format] Add an optional “License-Grant” field

#845255 Include best practices for packaging database applications

#897217 Vcs-Hg should support -b too

#901437 Add footnote warning readers that sometimes shared libaries are not coinstallable

#904248 Add netbase to build-essential

Posted Mon 27 Aug 2018 21:38:16 UTC Tags:

DebCamp for me extended an extra day to include the DebConf18 open day, but fortunately no further; today is the first day of DebConf18 proper, and I am happy to have DebCamp work sufficiently wrapped up that I can go to talks and discuss past and future work … rather than actually doing that work.

Here’s what I did at DebCamp:

  • Significant progress on both difficult and easy bugs against Debian Policy, and some admin issues. I haven’t managed to make a release but I think enough will fall into place between now and the end of DebConf that I can do that before flying home.

    Hideki Yamane is working on adding the infrastructure to translate Policy, which is very exciting. I don’t think we’ll get that all finished this week – I have to learn how to co-ordinate translators – but if we can get that infrastructure merged and released that is a big blocker out of the way.

  • Developed and released dgit versions 6.0 and 6.1 with Ian Jackson. The main changes: --build-products-dir works properly now and is configurable in your ~/.gitconfig, and dgit gained built-in support for pbuilder.

    There are various internal improvements to make these features work quite elegantly. Some of the work was reworking parts of a patch series I posted a few weeks ago, so it should be easier to rework the remainder of that series now.

    We realised yesterday evening that while the --build-products-dir work was intended mainly for the benefit of pbuilder users, it is actually quite a boon for sbuild users too, because sbuild itself does not support dumping .orig, .dsc, .debian.tar.gz etc. files into a build products directory. But now it does, if you run it via dgit.

    I have never been bothered by these build products in .., but I am considering starting to use the new feature and throwing away my crude perl code that cleans up ~/src on my workstations.

  • Finally found a place in the archive for some mail processing scripts in my ~/bin: a new package called mailscripts (after some discussion about where else they might be included). And finally wrote, and included in this package, a facility to pull a Debian bug into your notmuch database. No more opening up the web browser to read bugs because you were CCed on only a few of the messages in the bug.

  • Provided people with feedback: on a proposal for a procedure for salvaging packages; on Ian Jackson’s script and slides for our talk about git-debrebase.

  • Small pieces of work on team-maintained packages. Filing RFAs and removing myself from Uploaders where I’m not active. Some sponsorship. Some NMUs to help a transition.

  • Some ordinary package maintainance.

  • Some unfortunate yak shaving rabbit holes. Including broken /etc/mailname on my laptop. But that’s better than David Bremner, whose entire setup for sending e-mail broke in the middle of the week.

There has been a very positive and almost entirely non-hierarchical division of labour all week: the event organisers, who are all just Debian volunteers, have been dealing with quite a number of challenging issues, but these have not filtered through to bother those of us trying to power through work to improve Debian.

Further, the organising team has expanded to include people who had earlier in the week seemed a bit lost and didn’t seem to have something to do: a beginner data scientist from Taiwan who had showed up at the conference seemingly not knowing too much about Debian, and a group of Eastern European interns who have been contributing to Debian or related projects through schemes like Google Summer of Code and Outreachy. They all donned red staff T-shirts and got on with the job.

It’s not that these organisers are working for those of us writing code and discussing policy. By enabling each other’s work we are all working for the good of Debian, and thereby the much wider good of anyone who directly or indirectly interacts with computers. I have been seriously impressed by how effective and non-hierarchical this division of labour has been this week. But now I’m happy to have some more time to actually talk to the organisers, instead of running off to try to fix a test suite failure.

Posted Sun 29 Jul 2018 00:57:40 UTC

Thanks to efforts from several contributors I was able to push a substantive release of Policy a little over a week ago. It contains a lot of changes that I was very pleased to release:

 debian-policy ( unstable; urgency=medium
   * Policy: Update section 4.1, "Standards conformance"
     Wording: Ian Jackson
     Seconded: Sean Whitton
     Seconded: Holger Levsen
     Closes: #901160
   * Policy: Require d-devel consultation for each epoch bump
     Wording: Ian Jackson
     Seconded: Sean Whitton
     Seconded: Paul Gevers
     Closes: #891216
   * Policy: Document Rules-Requires-Root
     Wording: Niels Thykier
     Wording: Guillem Jover
     Wording: Sean Whitton
     Seconded: Paul Gevers
     Closes: #880920
   * Policy: Update version of POSIX standard for shell scripts
     Wording: Sean Whitton
     Seconded: Simon McVittie
     Seconded: Julien Cristau
     Seconded: Gunnar Wolf
     Closes: #864615
   * Policy: Update version of FHS from 2.3 to 3.0
     Wording: Simon McVittie
     Seconded: Sean Whitton
     Seconded: Julien Cristau
     Closes: #787816
   * Add reference link to section 4.1 to section 5.6.11.

We’re now looking forward to the rolling Debian Policy spring at DebCamp18. You do not need to be physically present at DebCamp18 to participate. My goal is firstly to enable others to work on bugs by providing advice about the process and how to move things along, and secondarily to get some patches written for uncontroversial bugs.

See the linked wiki page for more information on the sprint.

Posted Fri 13 Jul 2018 16:41:24 UTC Tags:

Here’s what I’m planning to work on – please get in touch if you want to get involved with any of these items.

DebCamp work

Throughout DebCamp and DebConf

  • Debian Policy: sticky bugs; process; participation; translations

  • Helping people use dgit and git-debrebase

    • Writing up or following up on feature requests and bugs

    • Design work with Ian and others

Posted Tue 19 Jun 2018 15:43:17 UTC

I’d like to push a substantive release of Policy but I’m waiting for DDs to review and second patches in the following bugs. I’d be grateful for your involvement!

If a bug already has two seconds, or three seconds if the proposer of the patch is not a DD, please consider reviewing one of the others, instead, unless you have a particular interest in the topic of the bug.

If you’re not a DD, you are welcome to review, but it might be a more meaningful contribution to spend your time writing patches bugs that lack them, instead.

#786470 [copyright-format] Add an optional “License-Grant” field

#846970 Proposal for a Build-Indep-Architecture: control file field

#864615 please update version of posix standard for scripts (section 10.4)

#880920 Document Rules-Requires-Root field

#891216 Requre d-devel consultation for epoch bump

#897217 Vcs-Hg should support -b too

Posted Wed 13 Jun 2018 14:15:39 UTC Tags:


I wanted to set up my own apt repository to distribute packages to my own computers. This repository must be PGP-signed, but I want to use my regular PGP key rather than a PGP key stored on the server, because I don’t want to trust my server with root access to my laptop.

Further, I want to be able to add to my repo while offline, rather than dputting .changes files to my server.

The standard tools, mini-dinstall and reprepro, are designed to be executed on the same machine that will serve the apt repository. To satisfy the above, though, I need to be able to execute the repository generator offline, on my laptop.

Two new features of git-annex, git-annex-export and v6 repositories, can allow us to execute the repository generator offline and then copy the contents of the repository to the server in an efficient way.

(v6 repositories are not production-ready but the data in this repo is replaceable: I backup the reprepro config files, and the packages can be regenerated from the (d)git repositories containing the source packages.)

Schematic instructions

This should be enough to get you going if you have some experience with git-annex and reprepro.

In the following, athena is a host I can ssh to. On that host, I assume that Apache is set up to serve /srv/debian as the apt repository, with .htaccess rules to deny access to the conf/ and db/ subdirectories and to enable the following of symlinks.

  1. apt-get install git-annex reprepro
  2. git init a new git repository on laptop.
  3. Create conf/distributions, conf/options, conf/ and .gitattributes per below.
  4. Create other files such as README, sample foo.list, etc. if desired.
  5. git add the various plain text files we just created and commit.
  6. git annex init --version=6.
  7. Add an origin remote, git config remote.origin.annex-ignore true and git push -u origin master git-annex. I.e. store repository metadata somewhere.
  8. git config --local annex.thin true to save disc space.
  9. git config --local annex.addunlocked true so that reprepro can modify files.
  10. Tell git-annex about the /srv/debian directory on athena: git annex initremote athena type=rsync rsyncurl=athena:/srv/debian autoenable=true exporttree=yes encryption=none
  11. Tell git-annex that the /srv/debian directory on athena should track the contents of the master branch: git annex export --fast --to=athena --tracking master
  12. Now you can reprepro include foo.changes, reprepro export and git annex should do the rest: the script calls git annex sync and gitannex knows that it should export the repo to /srv/debian on athena when told to sync.


conf/distributions is an exercise for the reader – this is standard reprepro stuff.





git annex add
git annex sync --content


* annex.largefiles=anything
conf/* annex.largefiles=nothing
README annex.largefiles=nothing
\.gitattributes annex.largefiles=nothing

These git attributes tell git-annex to annex all files except the plain text config files, which are just added to git.


I’m not sure whether these are fixable in git-annex-export, or not. Both can be worked around with hacks/scripts on the server.

  • reprepro exportsymlinks won’t work to create suite symlinks: git-annex-export will create plain files instead of symlinks.

  • git-annex-exports exports non-annexed files in git, such as README, as readable only by their owner.

Posted Thu 03 May 2018 06:06:02 UTC

We had a release of Debian Policy near the beginning of last month but there hasn’t been much activity since then. Please consider writing or reviewing patches for some of these bugs.

Consensus has been reached and help is needed to write a patch

#273093 document interactions of multiple clashing package diversions

#314808 Web applications should use /usr/share/package, not /usr/share/doc/…

#425523 Describe error unwind when unpacking a package fails

#452393 Clarify difference between required and important priorities

#556015 Clarify requirements for linked doc directories

#578597 Recommend usage of dpkg-buildflags to initialize CFLAGS and al.

#582109 document triggers where appropriate

#685506 copyright-format: new Files-Excluded field

#757760 please document build profiles

#759316 Document the use of /etc/default for cron jobs

#761219 document versioned Provides

Wording proposed, awaiting review from anyone and/or seconds by DDs

#582109 document triggers where appropriate

#737796 copyright-format: support Files: paragraph with both abbreviated na…

#756835 Extension of the syntax of the Packages-List field.

#786470 [copyright-format] Add an optional “License-Grant” field

#835451 Building as root should be discouraged

#846970 Proposal for a Build-Indep-Architecture: control file field

#864615 please update version of posix standard for scripts (section 10.4)

#897217 Vcs-Hg should support -b too

Merged for the next release

#896749 footnote of 3.3 lists deprecated alioth mailinglist URL

Posted Wed 02 May 2018 03:30:20 UTC Tags:

We’re getting close to a new release of Policy. Just this week Adam Borowski stepped up to get a patch written for #881431 – thanks for getting things moving along!

Please consider jumping into some of these bugs.

Consensus has been reached and help is needed to write a patch

#823256 Update maintscript arguments with dpkg >= 1.18.5

#833401 virtual packages: dbus-session-bus, dbus-default-session-bus

#835451 Building as root should be discouraged

#838777 Policy 11.8.4 for x-window-manager needs update for freedesktop menus

#845715 Please document that packages are not allowed to write outside thei…

#853779 Clarify requirements about update-rc.d and invoke-rc.d usage in mai…

#874019 Note that the ’-e’ argument to x-terminal-emulator works like ’–’

#874206 allow a trailing comma in package relationship fields

Wording proposed, awaiting review from anyone and/or seconds by DDs

#756835 Extension of the syntax of the Packages-List field.

#786470 [copyright-format] Add an optional “License-Grant” field

#835451 Building as root should be discouraged

#845255 Include best practices for packaging database applications

#846970 Proposal for a Build-Indep-Architecture: control file field

#864615 please update version of posix standard for scripts (section 10.4)

#881431 Clarify a version number is unique field

#892142 update example to use default-mta instead of exim

Merged for the next release (no action needed)

#299007 Transitioning perms of /usr/local

#515856 remove get-orig-source

#742364 Document debian/missing-sources

#886890 Fix for found typos

#888437 Several example scripts are not valid.

#889960 stray line break at clean target in section 4.9

#892142 update example to use default-mta instead of exim

Posted Fri 30 Mar 2018 00:23:29 UTC Tags:

In the philosophy department the other day we were discussing race-based sexual preferences. As well as considering the cases in which this is ethically problematic, we were trying to determine cases in which it might be okay.

A colleague suggested that a preference with the following history would not be problematic. There is a culture with which he feels a strong affiliation, having spent time living in this culture and having a keen interest in various aspects of that culture, such as its food. As a result, he is more likely, on average, to find himself sexually attracted to someone from that culture—he shares something with them. And since almost all members of that culture are of a particular racial group, that means he is more likely to find himself sexually attracted to someone of that race than to other races, ceteris paribis.

The cultural affiliation is something good. The sexual preference is then an ethically neutral side effect of that affiliation. My colleague suggested a name for the process which is responsible for the preference: he has subjectified his relationship with the culture. Instead of objectifying members of that group, as happens with problematic race-based sexual preferences, he has done something which counts as the opposite.

I am interested in thinking more about the idea of subjectification.

Posted Thu 29 Mar 2018 22:13:48 UTC

A friend and I each run a D&D game, and we also play in each other’s games. We disagree on a number of different things about how the game is best played, and I learn a lot from seeing how both sets of choices play out in each of the two games.

One significant point of disagreement is how important it is to ensure that combat is balanced. In my game I disallow all homebrew and third party content. Only the core rulebooks, and official printed supplements, are permitted. By contrast, my friend has allowed several characters in his game to use homebrew races from the Internet, which are clearly more powerful than the PHB races. And he is quite happy to make modifications to spells and abilities without investigating the consequences for balance. Changes which seem innocuous can have balance consequences that you don’t realise for some time or do not observe without playtesting; I always assume the worst, and don’t change anything. (I constantly reflavour abilities and stats. In this post I’m interested in crunch alone.)

In this post I want to explain why I put such a premium on balance. Before getting on to that explanation, I first need to say something about the blogger Mike Shea’s claim that “D&D 5e is imbalanced by design and that’s ok. Imbalance leads to interesting stories.” (one, two). Shea is drawing a contrast between 4e and 5e. It was possible to more precisely quantify all character and monster abilities in 4e, which meant that if the calculations showed that an encounter would be easy, medium or hard, it was more likely to turn out to be easy, medium or hard. By contrast, 5e involves a number of abilities that can turn the tide of combat suddenly and against the odds. So while the XP thresholds might indicate that a planned encounter will be an easy one, a monster’s ability to petrify a character with just two failed saves could mean that the whole party goes down. Similarly for character abilities that can turn a powerful boss into a sitting duck for the entire combat. Shea points out that such abilities add an awful lot of fun and suspense to the game that might have been lacking from 4e.

I am not in a position to know whether 4e really lacked the kind of surprise and suspense described here. Regardless, Shea has identified something important about 5e. A great deal is added to combat by abilities on both sides that can quickly turn the tide. However, I find it misleading to say that this makes 5e unbalanced. Shea also uses the term ‘unpredictable’, and I think that’s a better way to refer to this phenomenon. For balance is more than determining an accurate challenge rating, and using this to pit the right number of monsters against the right number of players. In the absence of tide-turning abilities, that’s all balance is; however, balance is also a concept that applies to individual abilities, including tide-turning abilities.

I suggest that a very powerful ability, that has the potential to change the tide of a battle, is balanced by some combination of being (i) highly situational; (ii) very resource-depleting; and (iii) requires a saving throw, or similar, with the parameters set so that the full effect of the ability is unlikely to occur. Let me give a few examples. It’s been pointed out that the Fireball spell deals more damage than a multi-target 3rd level spell is meant to deal (DMG, p. 384). However, the spell is highly situational because it is highly likely to also hit your allies. (Evokers have a mitigation for this, but that is at the cost of a full class feature.) Power Word Kill might down a powerful enemy much sooner than expected. But there’s another enemy in the next room, and then that spell slot is gone.

We should conclude that 5e is not imbalanced by design, but unpredictable by design. In fact, I suggest that 5e spells and abilities are a mixture of the predictable and the unpredictable, and the concept of balance applies differently to these two kinds of abilities. A creature’s standard attack is predictable; balancing it is simply a matter of adjusting the to-hit bonus and the damage dice. Balancing its tide-turning ability is a matter of adjusting the factors I discussed in the previous paragraph, and possibly others. Playtesting will be necessary for both of these balancing efforts to succeed. Predictable abilities are unbalanced when they don’t do enough damage often enough, or too much damage too often, as compared with their CR. Unpredictable abilities are unbalanced when they offer systematic ways to change the tide of battle. Indeed, this makes them predictable.

Now that I’ve responded to Shea, I’ll say what I think the point of combat encounters is, and why this leads me to disallow content that has not been rigorously playtested. (My thinking here is very much informed by how Rodrigo Lopez runs D&D on the Critical Hit podcast, and what he says about running D&D in Q&A. Thank you Rodrigo!) Let me first set aside combat encounters that are meant to be a walkover, and combat encounters that are meant to end in multiple deaths or retreat. The purpose of walkover encounters is to set a particular tone in the story. It allows characters to know that certain things are not challenging to them, and this can be built into roleplaying (”we are among the most powerful denizens of the realm. That gives us a certain responsibility.”). The purpose of unwinnable combat encounters is to work through turning points in a campaign’s plot. The fact that an enemy cannot be defeated by the party is likely to drive a whole story arc; actually running that combat, rather than just saying that their attempt to fight the enemy fails, helps drive that home, and gives the characters points of reference (”you saw what happened when he turned his evil gaze upon you, Mazril. We’ve got to find another way!”).

Consider, then, other combat encounters. This is what I think they are all about. The GM creates an encounter that the rules say is winnable, or unwinnable but otherwise surviveable. Then the GM and the players fight out that encounter within the rules, each side trying to fully exploit the resources available to them, though without doing anything that would not make sense from the points of view of the characters and the monsters. Rolls are not made in secret or fudged, and HP totals are not arbitrarily adjusted. The GM does not pull punches. There are no restrictions on tactical thinking; for example, it’s fine for players to deduce enemy ACs, openly discuss them and act accordingly. However, actions taken must have an in-character justification. The outcome of the battle depends on a combination of tactics and luck: unpredictable abilities can turn the tide suddenly, and that might be enough to win or lose, but most of the time good tactical decision-making on the part of the players is rewarded. (The nature of monster abilities means that less interesting tactics are possible; further, the players have multiple brains between them, so ought to be able to out-think the GM in most cases.)

The result is that combat is a kind of minigame within D&D. The GM takes on a different role. In particular, GM fiat is suspended. The rules of the game are in charge (except, of course, where the GM has to make a call about a situation not covered by the rules). But isn’t this to throw out the advantages tabletop roleplaying games have over video games? Isn’t the GM’s freedom to bend the rules what makes D&D more fun and flexible? My basic response is that the rules for combat are only interesting when they do not depend on GM fiat, or other forms of arbitrariness, and for the parts of the game where GM fiat works well, it is better to use ability checks, or skills challenges, or straight roleplaying.

The thought is that the complexity of the combat rules is justified only when those rules are not arbitrary. If the players must think tactically within a system that can change arbitrarily, there’s no longer much point in investing energy in that tactical thinking. It is not intellectually interesting, it is much less fun, and it does not significantly contribute to the story. Tabletop games have an important role for a combination of GM fiat and dice rolls—the chance of those rolls succeeding remaining under the GM’s control—but that can be leveraged with simpler rules than those for combat. Now, I think that the combat rules are fun, so it is good to include them alongside the parts of the game that are more straightforwardly a collaboration between the GM and the players. But they should be deployed differently in order to bring out their strengths.

It should be clear, based on this, why I put such a premium on balance in combat: imbalance introduces arbitrariness to the combat system. If my tactical thinking is nullified by the systematic advantage that another party member has over my character, there’s no point in my engaging in that tactical thinking. Unpredictable abilities nullify tactical thinking in ways that are fun, but only when they are balanced in the ways I described above.

All of this is a matter of degree. I don’t think that combat is fun only when the characters and monsters are restricted to the core rulebooks; I enjoy combat when I play in my friend’s game. My view is just that combat is more fun the less arbitrary it is. I have certainly experienced the sense that my attempt to intellectually engage with the combat is being undermined by certain house rules and the overpowered abilities of homebrew races. Fortunately, thus far this problem has only affected a few turns of combat at a time, rather than whole combats.

Another friend is of the view that the GM should try to convince the players that they really are treating combat as I’ve described, but still fudge dice rolls in order to prevent, e.g., uninteresting character deaths. In response, I’ll note that I don’t feel capable of making those judgements, in the heat of the moment, about whether a death would be interesting. Further, having to worry about this would make combat less fun for me as the GM, and GM fun is important too.

Posted Sat 03 Mar 2018 23:32:56 UTC