Search Results: "will"

16 March 2008

Joey Hess: re: Apologies for spamming the planet...

Daniel, there have never, ever, been any changes in ikiwiki can could result in GUID changes on upgrade, with the exception of enabling usedirs, which is something you have to do manually. And there never will be any if I have anything to say about it.. Of course, you can cause the GUIDs of posts to change by renaming or moving the files around, or by changing the url to your blog. Doesn't explain why it happened of course.. PS, can I git clone your blog from somewhere? There's an interesting blip in your RecentChanges page that I'd like to figure out, where one time the change author is listed as "Daniel Burrows Daniel_Burrows".

Simon Richter: What is Debian's role?

I must admit that I feel slightly uneasy about this, because it blurs the distinction between maintaining a package and forking it even more than it is already. Some improvements have long been necessary, since we really need to handle more archive formats, or the situation where upstream ships five tarballs and two patches, however I think the quilt support is a step in the wrong direction. There is nothing wrong with quickly fixing a problem in a package so Debian users do not have to wait for the fix to be incorporated into an upstream release; however for that we don't need a sophisticated system to keep patches separate and forward-port them to new upstream releases easily. Let's face it: the quilt integration into the build process exists because we expect to maintain these patches for months. On the other hand, there is an effort to synchronize these changes between distributions. The question to me is: if all the distributions can agree that a certain change has to be made, why cannot this change be committed upstream? Is Debian failing to submit patches, or are our patches just unacceptable because they break every configuration except ours? I can absolutely see the need for a tool to assist in forks, ideally one that will allow us to easily submit these patches to upstream developers easily, and ideally so they can pick them up with a minimum amount of hassle. Now why does this entire discussion sound so incredibly familiar?

Joey Hess: The Lost Ring

I've been sucked into this alternate reality game, "The Lost Ring", which involves 6 people who woke up with amnesia in labyrinths around the world, blindfolded, with a tattoo "Trovu la ringon perditan". It involves a lost Olympic sport, lots of Greek mythology and history, and lots of puzzles and detective work. Currently 26 pages of a codex are being tracked down from hiding places all around the world, with ones in Cardiff and Austin recovered over the past few days, one in Shanghai that I hope will be reached soon, and a location just discovered in Stockholm (in a bread store!), that someone needs to go check out. (Update: Jon read about it in my blog and went and got photos! page 1 page 2.) This is the first time I've played an alternate reality game, but the way the story is told, through blogs, podcasts, youtube videos, email with the characters, and recovered documents like this, is quite compelling. Also interesting is all the use of Esperanto, as well as characters who speak Spanish, French, German, Chinese, Japanese, and Portuguese, so that translation is an ongoing part of the game.

Alexis Sukrieh: The road to Backup Manager 0.7.7

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release). All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way. So, fear a new release soon…

Daniel Burrows: aptitude 0.4.11 released

I've released version 0.4.11 of the aptitude package manager (release notes). Due to ongoing work by the installer team, I uploaded this release to experimental rather than unstable; once things are clear I will upload a build to unstable (probably promoting the experimental cwidget to unstable at the same time). The initial upload accidentally left out libept support, so I'm preparing a new upload as I write this. The aptitude search language and its documentation have gotten particular attention in this release. The most visible change is the introduction of a new syntax for search expressions: in addition to the old style of ~i, you can now type ?installed. Not only is this more readable and more memorable, it means that I'll be much more able to expand the breadth of the query language: it was becoming rather difficult to select new single-character flags for search terms, so expanding the namespace is nice. On this note, a number of search terms have been added to the language; see the release notes or the aptitude user's manual for details.

PS: if you're wondering about the quote in the release notes: I just needed to vent a little about that incident in a way that I found amusing and harmless; I'm over it now, and hopefully this will be the last time I mention it in public.

Andreas Barth: semantics in ldap - anyone out there?

Ldap seems like a good database to store accounts in: Lots of tools can use it, it's easily integrated into pam, and lots more. But one sometimes just hits borders in the data model of openldap: There are no semantics available. So, let me give you an example. Take e.g. the dnsZoneEntry attribute in the debian.org-ldap. Actually, one wants to allow anyone to write into that attribute in his own entry. But - and that's a big but - one wants to have two additional checks before writing: One is that one cannot claim any dns entry already used by someone else. And the other is that the format needs to comply to specific standards. Now the question is, is there some way to use ldap with more semantics? Or does one need to write ones own backend to do that (and in all the non-plain-db*-backends, it is specified that one needs to write his own authorization code as well). Or some other recommended way to do that? (Or is the only existing incarnation of that ActiveDirectory?) Update: Thanks to Faidon Liambotis I know now about the overlays in openldap. The standard overlays unique and constraint will probably solve the case above - of course, I have a few more complex cases, but that are at least good starters.

Steve Kemp: E.T. phone home

I've just finished reading "Don't You Have Time to Think", a collection of letters written to and from Richard P. Feynman. A birthday present from my wishlist. Previously I've read the collection of letters to/from Tolkien. (Several times actually. Very nice collection!) It suddenly struck me that over my lifetime I've probably written <200 letters to people. When I was young I had a couple of pen pals, and when I was entering university I was involved with a couple of play by mail games which involved writing random letters involving strategy & etc. Personal letters though? I've written very few, and I think they've mostly consisted of letters to my partner/partners of the time. (For example Megan went home for a few months at the end of a university year about two months after I initially met her. So there were many letters back and forth. Recently she spent two months working in the USA; counting eggs and avoiding alligators so again there was a flurry of written letters, maybe 20 total during the duration of her trip.) I guess that most of my (hand)written messages to people have been in the form of postcards whilst on holiday. A long time ago I offered to mail postcards to Debian developers. I know I sent at least two, and I received at least one back - but the thing I remember most was exchanging addresses with Amayita and getting into character set issues. Her emails, containing her Spanish address, were difficult to understand as my mutt/console refused to display the foreign character set properly. I can't recall whether she did ultimately receive a card from me, but I'm sure she'll remind me if she did. Anyway I have no resolution, intention, or expectation that I will suddenly start writing more physical mails to people. But I think it almost counts as something we do less of these days. The telephone and internet have become the norm. In some ways this is fantastic. In others it less good. On the left my handwriting is so bad that maybe this isn't necessarily a problem. ObQuote: E.T.

Adrian von Bidder: Adams bler

Another week has been spent in a repetition course in the military. Readers of my blog will know that this means playing poker (I lost about CHF 7 this week — we just play for fun at CHF 5 for 50 chips) and watching movies. Tron and Kill Bill Vol. 1 from my collection, and the extremely funny Adams bler which I didn't know before. The story centers around a neo-nazi serving some time in some kind of rehab in a church where, it is soon discovered, the priest in charge of the whole thing is not that much in charge, even of himself. I'm told that I also should watch I Kina spiser de hunde by the Danish Anders Thomas Jensen (writer and director of Adams bler, writer of In China they eat dogs.) Also recently watched Casino Royale (the recent Bond movie. I haven't seen the 1967 one yet.) and The Gold Rush: the 1942 version with added spoken narrative and music by Chaplin. The DVD does contain the original 1925 silent movie, too, where especially the ending is a bit different. And finally lots of episodes of , ! (Nu, pogodi!), which was the Soviet equivalent to Tom and Jerry (not a clone, it is entirely different.) I can highly recommend this to everybody who likes cartoons.

15 March 2008

Daniel Leidert: Diploma exams are calling: Please read if you want to NMU my packages

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:

#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’: Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.
#438694: gabedit: Crashes when loading any XYZ format file: Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.
#442223: openbabel: some connect information lost when convert from pdb to txyz: Nothing examined yet to solve this bug.
#464867: extrema: conflicts with psi3 package: Hope, my team will cover this asap.
#465723: mopac7 — please do not use g2c.: There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.

For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:

docbook-xsl-ns: See the above note about docbook-xsl and the source package split.
html-xml-utils: Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.
DocBook 5: I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.

QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

Jeff Bailey: Post-Surgery Firsts...

I've had a series of post-surgery firsts in the past few days... Some of them good:

My first wriggling into a pair of jeans.

My first walks outside without my walker.

My first couple of stairs.

Some of them less good:

My first setback - It seems that 1.5km is too far for me to walk with the walker. I pulled a muscle in my back. I'm almost back to 100% after a couple of days, but I got to discover a new class of opiates.

My first family emergency - My father had a heart attack. He seems to be okay, he's in Kamloops hospital now, and will transfer to Vernon next week for the Angiogram. Information on bypass versus blood thinners waits on that (as does going home versus transfering to Vancouver). This is apparently the same sort of thing that killed my grandfather in his 30's. So there's two concerns:

1) My dad: Medtech is better than it was back then, and they're monitoring him in-hospital. So, I'm optimistic. While I can't find this in the Wikipedia article, I'm generally under the impression that once you make it to the hospital, you're probably fine and that deaths from heart attacks are from people who do things like sit around and wait to see if they'll feel better.

2) Me: Hopefully the exercising, non-smoking, vegan thing is enough to mitigate this. Aside from my recent taking of steroids and opiates for my back, I've generally treated my body well, and I'll find out if I should be doing further things or monitoring to stay away from this one.

And, well, there it is.

Mike Hommey: Xulrunner 1.9beta4 not approaching experimental

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won’t be ready this week-end. It’s always when you come closer to the goal that it gets farther… And I still haven’t decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue. Considering we will more than probably have both schemes in use within reverse dependencies, I’m not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul… That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though. I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI. The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package. I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast ! For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I’m planning to package a new Webkit snapshot soon after I’m done with xulrunner and Iceweasel, we’ll see then how it performs. While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn’t crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0). Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I’m testing on x86-64).

Daniel Burrows: Installing packages in safe-upgrade

Colin Watson writes:

I do sometimes wonder why we don't relax the definition of "safe" upgrades to include installing new packages but still not removing old ones. I know that many of my uses of dist-upgrade are just for when something grows a new dependency that I didn't previously have installed.

That's a good question. Like many things in aptitude, the basic design was copied from apt-get, and I haven't thought much about it since then. But in fact, I think this makes a lot of sense, and it turns out that it's fairly easy to acheive. I've just checked a change into head that makes safe-upgrade allow new packages to be installed. This is accomplished using aptitude's dependency resolver, restricted to only consider holding packages back or installing the candidate version of a package (that is, the version that aptitude install would choose by default). If the resolver produces a solution, it's applied blindly; otherwise we fall back to the current behavior (and probably fail). The current behavior is still available through aptitude --no-new-installs safe-upgrade and the configuration option Aptitude::CmdLine::Safe-Upgrade::No-New-Installs. The one thing that might get missed are broken recommendations -- libapt doesn't consider these to be broken dependencies, so aptitude won't notice them unless there are broken real dependencies. These will get fixed in full-upgrade because it uses apt's resolve trivial dependencies algorithm. That's probably what's doing the wrong thing with conflicts, but it also has logic to do the right thing with new recommendations. Regardless, those wouldn't have been fixed by the old logic of safe-upgrade, so this is not a regression.

Daniel Burrows: Full upgrade and conflicts

Erich Schubert wonders how to improve the handling of conflicts in package managers, particularly in aptitude full-upgrade and

apt-get
dist-upgrade

. From the point of view of the package manager, conflicts are a bit tricky to deal with. The problem is that a conflict only really tells you not to install two packages at once; it doesn't tell you which package should end up on the system by default. Worse, aptitude has two approaches to this:

When a package is marked for installation in the visual interface or listed on the command-line, then if Aptitude::Auto-Install is enabled, aptitude will automatically resolve conflicts in favor of that package. The same applies to packages that are upgraded by pressing U or by full-upgrade.
When aptitude's dependency resolver encounters a conflict, it considers both resolutions to the conflict to be equally valid. If there are no other reasons to choose one package over the other, it will be unpredictable which one gets removed first, and even when there are reasons to choose, the user may not understand what they are.

I don't think it's possible to always make upgrades predictable. But I think that even just making Auto-Install stick to installing packages and not removing conflicts would be a plus. Installing obvious dependencies up-front is good because it means less work for the resolver and a more predictable starting point. Many trivial dependency problems can even be completely solved this way. But removing conflicts is a lot trickier and should probably kick the problem into the full resolver. Unfortunately, the code enabled by Auto-Install is all deep in the guts of libapt. I've tried to avoid duplicating this code so far, but it does seem like I periodically run into cases where it doesn't do exactly what I need, so maybe I'll have to eventually. :-(

Daniel Burrows: HOWTO get and compile the apt source repository using bzr

Getting apt apt's source code is managed using bzr. Very fine tutorials and documentation on bzr exist on the Web; I'll give a brief rundown of some useful commands here, but you should read bzr-specific documentation to get a complete understanding of it. bzr is available in the Debian repositories, and likely other distributions have a package of it as well. The master apt branch for Debian is available at http://bzr.debian.org/apt/debian-sid. Yes, that looks like an empty directory if you view it with a Web browser, but it really contains the source tree. To retrieve it, run:

bzr branch http://bzr.debian.org/apt/debian-sid apt-debian-sid

That will download the repository to the directory apt-debian-sid. It takes a long time to download a fresh copy of the code, so be patient. When bzr branch finishes running, you have a new private copy of the source tree to work with. You can commit changes with bzr commit, download updates with bzr merge, see what you've changed with bzr diff, and copy your changes to a public location with bzr push. Read the bzr manpage and user's manual for full documentation on how to use bzr. Other public repositories of apt code include:

My own tree, at http://algebraicthunk.net/~dburrows/bzr/apt.
Email me at Daniel_Burrows@alumni.brown.edu and I'll add your tree to this list.

Compiling apt from its repository To compile apt, you'll need the following packages on Debian:

g++
make
libdb4.4-dev
gettext
libcurl4-gnutls-dev or libcurl3-gnutls-dev
xmlto

That will allow you to build apt without installing it by running make. xmlto is not listed in the Build-Depends line of apt, but you won't be able to produce manpages without it. In particular, you'll need it to produce a Debian package (see below).

Installing a build of the apt repository The easiest way to install a custom build of apt out of a repository checkout is to build a Debian package from the checkout. Install the following packages:

dpkg-dev
debhelper

and run the following command in the top-level directory of the apt repository:

dpkg-buildpackage -rfakeroot -us -uc

This will compile apt and produce several .deb packages in the parent directory of the repository. To install the generated packages, I recommend first installing the devscripts package and then running debi. You can also install the .deb packages by hand by running dpkg -i FILENAME.deb (...). Warning: installing an interim build of apt is likely to break all the packages that depend on it, such as aptitude and synaptic; interim builds might also be buggy and do strange things to your system. You should not install an unreleased version of apt unless you are sure that you can fix any problems that you encounter as a result of doing so.

Daniel Burrows: HOWTO convert your Blogger/BlogSpot blog to ikiwiki

Until recently, my blog was hosted on Google's free Blogger service. When I decided to move to my own server and ikiwiki, I didn't want to lose all my old posts. But exporting your blog from Blogger is a bit tricky. In fact, the Blogger page that provides instructions on how to do so starts off by saying:

Blogger does not have an export or download function.

Regardless of what they say, you can cajole Blogger into exporting text for use in other blog systems. Instructions for moving from Blogger to various pieces of software are available out there on the Web, but to switch to ikiwiki I had to tweak them a bit. Here's the procedure I used:

Extract your information from Blogger's clutches and add minimal IkiWiki tags. As in the official Blogger instructions, change your template temporarily. However, instead of using the page template they suggest, use the following template, which you can find as a text file here.
```
<Blogger>
[[meta author="<$BlogItemAuthor$>"]]
[[meta date="<$BlogItemDateTime$>"]]
[[meta title="<$BlogItemSubject$>"]]
<$BlogItemBody$>
</Blogger>
<BlogItemComments>
Comment by <$BlogCommentAuthor$> at <$BlogCommentDateTime$>:
<$BlogCommentBody$>
</BlogItemComments>
```
I recommend saving the file that's produced by this step even after you process it in the next step, in case you discover that you made a mistake.
Split the extracted file into pieces. Exporting your blog using the template above will get you all your blog posts in reasonable Markdown format, with all dates and titles preserved. But they'll all be scrunched into one file. Blogspot also won't interpret paragraph breaks into blank lines, and it inserts strange empty <div> tags all over. So the next step is to split this file into pieces and clean up the HTML. Since I had over a hundred posts, I wrote a Python script to do this postprocessing for me. You can find it here. You can run it like this to output each blog post as a separate file in the current directory:
```
/path/to/fixup-blogspot-export input-file
```
This script makes a few assumptions about its input file:
1. It assumes that the text [[meta author="NAME']] does not appear at the start of a line anywhere except the first line of a blog post. If you write about MarkDown syntax on your blog, you will run into problems.
2. It makes a similar assumption about Ikiwiki's date meta.
3. It assumes that line breaks are expressed using a variant of <br/>, and that <br/> never appears in the text of your blog.
4. It assumes that the text Comment by does not appear at the start of a line in any post.
5. It assumes, in general, that no Markdown or Ikiwiki commands appear in the blog text. If any do, you'll have to manually escape them, either before or after running the conversion script.
All in all, it's probably a good idea to at least skim the output once.
Create a top-level Ikiwiki page for your blog. The Ikiwiki site has instructions on doing this that are probably better than I could write. The most important thing is to use the created-after tag to limit your RSS feeds, so you don't spew new posts all over the planet (pun intended). For instance:
```
 [[inline pages="./blog/entry/*"
          feedpages="created_after(last_page_of_the_old_blog)"]]
```

Daniel Burrows: aptitude 0.4.10 released

I've just released version 0.4.10 of aptitude, a terminal and command-line package management tool for Debian. This release has many user-visible changes (see the changelog below). It also fixes an annoying and much-reported segfault. The Debian packages of this version are built against the new version of cwidget, which is sitting in NEW, but if you're impatient you can compile it by hand by dropping the versioned dependency. The dependency is there to ensure that we don't get dependency skew across architectures (aptitude depending on libcwidget0 on some archs and libcwidget1 on others) and doesn't represent an actual build requirement of aptitude.

[12/15/2007] Version 0.4.10 Oscillating Reindeer
New features:
In command-line mode, if the resolver fails to produce a solution for whatever reason, then instead of aborting the program entirely aptitude will now display a prompt at which you can fix the dependency problems by hand. Enter r at this prompt to try to automatically fix dependencies again.

safe-upgrade will now install new packages to fulfill dependences (but it will never remove packages, downgrade packages, or install a version that's not the default). The option --no-new-installs will disable this behavior.
Updates and commands that install, remove, or upgrade packages will now display a brief summary of what changed. For instance:
There are now 64 updates [+10], 3 new [+1].
Unfortunately, this change requires reading the cache after an update is complete. Passing -q will disable this behavior, but also make the update progress bar less attractive. More work on resolving this tension between features and performance remains to be done.
Add an option --allow-untrusted to override trust warnings. (Closes: bug #452201, bug #452541)

Recommended packages are now hidden if quiet mode is enabled. (Closes: bug #452202)

The options Aptitude::ProblemResolver::Trace-File and Aptitude::ProblemResolver::Trace-Directory allow you to generate a minimal cut of the cache that allows a problem resolver run to be reproduced. The eventual aim is both to simplify bug reporting and to generate a corpus of automatic test cases for the resolver (although more work needs to be done to accomplish the latter).
When run in command-line mode, instead of displaying many separate and sometimes duplicative groups of packages (e.g.: installed, auto-installed, auto-installed in a light cream sauce, etc), aptitude displays packages in a few exclusive categories and uses tags (like the existing purge tag) to provide more state information. For instance:
$ aptitude -s install wesnoth
The following NEW packages will be installed:
  wesnoth wesnoth-data a  wesnoth-music a 
$ aptitude -s remove freeciv-data
    (... dependency resolution ...)
The following packages will be REMOVED:
  freeciv-client-gtk a  freeciv-data freeciv-server a  ggzcore-bin u 
  libggz-gtk1 u  libggz2 u  libggzcore9 u  libggzdmod6 u  libggzmod4 u 
Here a indicates that a package was automatically installed or removed, and u indicates that a package is being removed because it is unused. Hopefully this will be less confusing than the old format.
Bug fixes:

Crashes and serious errors:

Track down and fix a SEGV triggered on the first action after a cache reload (sometimes). There are multiple bugs where this might have been the root cause, but it's confirmed that it was the cause of at least bug #454695, bug #454700, bug #455349, and bug #453362. Bug bug #455865 is almost certainly the same issue, and bug bug #352278 may be another manifestation of it.

If StepLimit is set to 0, refuse to solve dependencies instead of going into an infinite loop. (Closes: bug #451311)

Minor bugs:

Return a failing exit code after jumping from the command-line to visual mode if the last install run failed. (Closes: bug #282408)

Return a failing exit code from aptitude update if any download fails. (Closes: bug #233129)

Cosmetic and UI bugs:

In addition to Enter, Space will now activate checkboxes and radio buttons. (Closes: bug #451765)

Abort the program if we get EOF at the resolver prompt instead of claiming the resolver failed.

Command-line searches will now only print each result once. (Closes: bug #450798)

Documentation bugs:

The options menu documentation now minimally describes the new configuration interface.

The documentation of the configuration file options has been placed back in alphabetic order after apparently suffering bitrot over the years.

Corrected the documented default of Parse-Description-Bullets to match reality.

The manpages for aptitude-create-state-bundle and aptitude-run-state-bundle are now generated using DocBook, which should produce higher-quality and more consistent typesetting, as well as making the manpages more maintainable and allowing translators to easily produce localized versions of the manpages.

Internal changes:

Removed some unit tests that really tested cwidget.

Translation updates:

French (Christian Perrier)

Daniel Burrows: I hate it when I'm right this way

A few months ago, I registered my first domain name ever. When you want to register a domain, the first step is generally to enter the domain you are interested in into a box; the registrar will then check to see if the domain is not registered yet, and allow you to register it if it's available. When I saw this, I thought to myself: huh, I bet that if I were a registrar and I were evil, I would take domain names that people ask about but don't register and register them myself. So I used the normal DNS lookup process to check hostnames until I came up with one I liked, on the theory that they can't possibly be registering every single lookup failure. I really hoped that I was just being excessively paranoid, so it makes me sad to learn that apparently my cynicism in this particular case was entirely well-founded. Someday I want to believe bad things about humanity and have them turn out to be false. :-(

Daniel Burrows: Abusing metaphors is fun

I recently read a description for a 2.5-inch hard drive enclosure that said that it

comes with all the important features that are required in a portable hard drive rugged anodized aluminum housing, shock proof, light weight, compact size, and choice of enclosure that includes bullet proof hardware encryption to protect your sensitive data.

(my emphasis) So if someone puts a bullet through the hard drive, my data will be fine? Or are they just guaranteeing that no number of bullets shot at the drive will reveal the data stored on it?

Daniel Burrows: Abstracting over record fields in Haskell

It seems like I often run into situations in Haskell where it would be nice to be able to refer indirectly to a member of a record. For instance, say that I have a command-line program that can accept many options. I might choose to store its configuration in a large record:

data Settings = Settings   fld1 :: Type1, fld2 :: Type2, ...

The intuitive way of describing command-line options for a Haskell programmer would be something like:

let options = [ BoolOption   (Just "--foo") (Just "-f") fld1,
                StringOption (Just "--bar") Nothing     fld2,
                ... ]

However, this doesn't work. Since the type of fld1 is

Settings ->
Type1

, there's no way to use it to modify the value of fld1 in a Settings record (or rather, to produce a new Settings record with a different value of fld1). In other words, we need something like this:

let options = [ BoolOption (Just "--foo") (Just "-f") fld1 (\s val -> s   fld1 = val  ),
                ... ]

As the number of setings increases, it becomes annoying and error-prone to type out a setter function for each field of the record. Moreover, it feels very out of place, in a language where we can generalize over almost everything else, that we can't generalize over record fields. Other languages have solved this problem. Of course, in languages that aren't statically typed you just refer to fields using strings:

field_name = "name"
val = getattr(o, field_name)
setattr(o, field_name, val)

But you can do this in a statically typed language too. C++ has the concept of a pointer to member, which essentially stores the offset of a field within a structure:

struct X
 
  int a;
  int b;
 ;
// ...
int X::* p = &X::a;
X x;
x.*p = 5;

What we want, then, is a pointer to member for Haskell. Probably the easiest way to do this is something like:

data Member t rec = Member   get :: rec -> t;
                             set :: t -> rec -> rec

Now you can just write:

data Settings = Settings   realFld1 :: Type1, ...  
fld1 = Member realFld1 (\x r -> r   realFld1 = x )
-- ...
let y = get s fld1 in
(y, set s (y - 1))

This still needs a lot of boilerplate code for every record, though, and of course there's no guarantee that accesses will be inlined (I would assume that compilers treat record accessors specially in current compilers). Ideally the field declarations would be written out by the compiler, but this would conflict with fields being functions in Haskell98; Haskell is a mature enough language that I assume it's not acceptable to break existing code. Is there a nice way of fixing these problems and getting reasonable indirection to record members?

Daniel Burrows: Why so few X maintainers?

Andrew McMillian asks why X.org has so few active developers:

[Bernardo Innocenti] did a quick and dirty analysis of Xorg LoC vs Linux LoC, to give a "X codebase is roughly 1/2 Linux codebase" (which surprised me, actually, I'd always thought it was larger) and then a similarly rough analysis that suggests that Xorg has roughly 1/20th of the developer base. To some extent Bernardo's metrics are arguable, but the basic facts are that Linux gets the lions share of the developers. Is this what we should expect? Is this a healthy way for the free and open source software community to support the development of what I personally would like to see as the future desktop base?

There are a lot of factors involved in determining which projects get more attention. I'd imagine that things like the amount of domain knowledge required to contribute a simple patch, the structure of the code, the amount of press that a project and its maintainers get, and the presence (or not) of a charismatic and photogenic leader. You could probably even base your entire academic career on studying this question. But I also think we shouldn't underestimate the impact of paid jobs. Admittedly, I have never asked whether I could get paid before jumping off a cliff and starting a new project. But on the other hand, I now effectively work two jobs and only get paid for one. Most people are not as stupid as me, and will rationally choose to spend their time on tasks that they actually get compensated for. Even people who don't care about being paid will find it difficult to continue contributing over time due to practical issues of their personal life, families, etc, and they won't be able to contribute as much as if they were working full-time. It's well-known in the programming community that if you can hack the Linux kernel, you can pretty much write your own job description [1]. On the other hand, I've never heard that companies are looking to hire skilled X programmers. A quick pair of searches on that font of knowledge, Google, seem to back this up. Compare the results for x programming jobs -"active x" -"OS X" and linux kernel programming jobs [2]. Nothing on the first page has anything to do with being paid to work on X.org, whereas the second search gives me an entire page full of people offering to pay me money if only I knew how to hack the kernel. KernelTrap, a central site for information on the kernel, even has a job board just for jobs related to kernel programming. That's not to say that the X coders don't get paid; I'm sure many of them are compensated for their work on X, and given the level of expertise involved they're probably paid well. Companies that manufacture graphics cards have an interest in employing people to hack on X; Linux distributions and embedded hardware manufacturers also benefit from a better X and strike me as likely places of employment for X hackers. But there doesn't seem to be anything for X.org like the cornucopia of available and well-advertised jobs related to the Linux kernel. Programmers who want to be paid someday will, on average, end up gravitating to the project where the prospects are obvious, not hidden. [1] Note that for the purposes of this discussion, it doesn't matter whether this common wisdom is true. The perception of jobs available in Linux-land will tend to cause people to head towards Linux regardless of whether the jobs exist or not. [2] I also tried x server programming jobs -"OS X", x.org server programming jobs, x server jobs -"OS X", and x.org server jobs without notable success.

Next.

Previous.