Peter Green's talk very clear and well received.

Now for (almost) the last of the day - Steve McIntyre (93sam / Sledge) for his annual presentation on the state of UEFI

I've had some 8GB USB keys made, with the Debian swirl and text. By buying a reasonable number, I've got what I think is a good price for nice high-quality keys (metal body with a solid loop for attaching to a keyring). I'm now selling these for 7 pounds each, and I'm planning on bringing some to DebConf 15 too, where they'll be 10 EUR. They're selling faster than I expected - if you're interested in buying one (or several!), please let me know. If there's enough demand, I may order more.

I'm in the middle of setting up new build machines for the armhf port (see the wiki for more details). We'll shortly have six machines set up in the machine room here at ARM in Cambridge:

• harris as a porter box
• hartmann, hasse, hebden and henze running buildd software
• hoiby as a hot spare

All of these machines are Freescale i.MX53 Quickstart (aka "loco") development boards. They include a 1GHz i.MX53 CPU (based around the ARM Cortex A8, one of the ARMv7-A family). They have 1GB of RAM and native SATA. They're lovely little machines, measuring just 3 inches square. To mount them usefully in a machine room, I've mounted each board with a 320GB notebook hard drive and the necessary cabling onto a small perspex card as you can see here. Then we can fit 6 such machines and a normal PC-style ATX PSU into a 3U mini-rack. Well, it almost fits - the power supply pokes out a little so we'll need 4U of space when we come to mount it. The Quickstart boards have been sponsored by Linaro, and ditto my time setting up these machines. Thanks! As is common with new development boards, these machines are not quite fully supported in Debian yet. The kernels we're using are locally-built, using the sources supplied by Freescale. For now, that means a heavily-patched "2.6.35" kernel but we're expecting to be able to switch to mainline very soon. The .config I'm using is kernel.config, and I've built it natively on harris using fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=1buildd1 Similarly to the setup for the armel machines, for now I've tweaked things when installing the kernel:

• depmod:
  • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
• initramfs-tools:
  • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
• flash-kernel:
  • Add support for these boards
  • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated by flash-kernel:

MX53-LOCO U-Boot > setenv loadaddr 0x70800000
MX53-LOCO U-Boot > setenv initrdaddr 0x71000000
MX53-LOCO U-Boot > setenv bootargs_sata set bootargs \$\ bootargs\  root=/dev/sda2 rw rootwait
MX53-LOCO U-Boot > setenv load_sata_kernel ext2load sata 0:1 \$\ loadaddr\  /uImage
MX53-LOCO U-Boot > setenv load_sata_initrd ext2load sata 0:1 \$\ initrdaddr\  /uInitrd
MX53-LOCO U-Boot > setenv load_sata run load_sata_kernel load_sata_initrd
MX53-LOCO U-Boot > setenv bootcmd_sata sata init\; run bootargs_base bootargs_sata load_sata\; bootm \$\ loadaddr\  \$\ initrdaddr\ 
MX53-LOCO U-Boot > setenv bootcmd run bootcmd_sata

And I've added extra config into uboot to use the pre-installed Ubuntu system on the micro SD card as a fall-back:

MX53-LOCO U-Boot > setenv bootcmd_rescue sata init\; run bootargs_base bootargs_sata\; mmc read 0 \$\ loadaddr\  0x800 0x1800\; bootm

One of the nice things that I've been involved with since starting to work at ARM in Cambridge is setting up newer, faster machines to help with the armel port. We have six machines hosted in the machine room here now:

• abel is a porter box
• arnold, alain, alwyn and antheil are running buildd software
• arne is a hot spare (currently on my desk, but ready to go back in the rack any minute now)

All of these machines are Marvell DB-78x00-BP development boards, each configured with a 1GHz Feroceon processor (ARM v5t), 1.5GB of RAM and a 250GB drive attached via SATA. They're nice machines, reasonably powerful yet (as with many ARM-based machines) they draw very very little electrical power even when working hard. These very boards were used for a while by the folks at Canonical to help build the Ubuntu armel port, but now we've got them. In terms of configuration, these machines are not quite fully supported in Debian yet, though. The kernels we're using are locally-built, based on the Debian linux-source-2.6.32 package but with a .config (marvell.config) that's tweaked slightly to add the support for these boards. There aren't any source changes needed, so I'm hoping to get support added directly in Debian, either as a new kernel flavour or (preferred) as a patch to an existing flavour. I've had conflicting advice about whether the latter is possible, so I'm going to have to experiment and find out for myself. UPDATE 2010-09-28: I've tested, and it seems that the boards will need a new flavour after all, as the config is incompatible with the closest other config (kirkwood). Ah well... I had no end of trouble trying to get make-kpkg do the right thing, so on advice from Ben I built the kernel using "make deb-pkg", a standard target in the Linux kernel's build system: fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=buildd23 Annoyingly, that wouldn't work when cross-compiling either so I had to build the kernel natively. To make the resulting kernel image package install properly (and, just as importantly, allow for future easy upgrades for the DSA folks), I also needed the following tweaks to the Debian system:

• depmod:
  • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
• initramfs-tools:
  • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
• flash-kernel:
  • #594878: support for these boards. Hector did most of the work, and I've worked on it a little more.
  • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated:

Marvell>> setenv IDE ide reset
Marvell>> setenv loadkernel ext2load ide 0:1 0x2000000 /uImage
Marvell>> setenv loadinitramfs ext2load ide 0:1 0x3000000 /uInitrd
Marvell>> setenv bootboth bootm 0x2000000 0x3000000
Marvell>> setenv bootcmd setenv bootargs \$\(bootargs\)\;$(IDE)\;$(loadkernel)\;$(loadinitramfs)\;$(bootboth)
Marvell>> saveenv

And that's it, as far as I can see. I'll now wait for people to tell me what I've got wrong above... :-)

With all the discussion about SHA-1 weaknesses and generation of new OpenPGP keys going on there's some concern about how the web of trust will be affected. I'm particularly interested in the impact on Debian; while it's possible to add new keys and keep the old ones around that hasn't worked so well for us with the migration away from PGPv3 keys. We still have 125 v3 keys left, many of them for users who also have a v4 key but haven't asked for the v3 key to be removed or responded to my email prodding them about it. I don't want to repeat that.

So if we're looking at key replacement we need to have some idea about where our Web of Trust currently stands, and what effect various changes might have on it. I managed to find the keyrings Debian shipped all the way back to slink and ran the keyanalyze and cwot stats against them. I then took the current keyring, pull in all the updates for the keys in it (so that any signatures from newly generated keys would be included) and ran the stats again. Finally I took details of 12 key migrations (mostly from Debian Planet but also a couple of others I knew about) and calculated what the effect of removing each key would be. These stats are cumulative and I replaced the most well connected (by centrality) keys first.

The results are below.

• Total is the total number of keys in the keyring
• SCS is the largest Strongly Connected Subset
• Reachable is the largest reachable subset
• MSD is the Mean Shortest Distance
• Centrality is the average centrality for the reachable subset
• update-foo indicates that foo's key was replaced with a newer one

	Total	SCS		Reachable		MSD	Centrality
1999-02-06 (slink)	228	36	(15.78%)	50	(21.92%)	2.9022
2000-01-03 (potato)	375	104	(27.73%)	180	(48.00%)	4.3382
2001-09-22 (woody)	948	538	(56.75%)	704	(74.26%)	4.7320	2008.6249
2005-05-28 (sarge/etch)	1106	883	(79.83%)	969	(87.61%)	3.3485	2074.6604
2007-12-04	1191	1001	(84.04%)	1062	(89.16%)	3.1103	2113.3747
2009-01-18 (lenny)	1126	947	(84.10%)	1010	(89.69%)	3.0489	1941.2594
2009-04-04 (squeeze/sid)	1121	946	(84.38%)	1008	(89.91%)	3.0466	1936.9761
2009-05-06 (current)	1067	894	(83.78%)	958	(89.78%)	2.9670	1759.4363
	Total	SCS		Reachable		MSD	Centrality
base	1067	904	(84.72%)	959	(89.87%)	2.9640	1776.4389
update-93sam	1067	902	(84.53%)	958	(89.78%)	2.9734	1780.9874
update-joerg	1067	900	(84.34%)	958	(89.78%)	2.9776	1780.7578
update-aurel32	1067	898	(84.16%)	957	(89.69%)	2.9803	1779.2497
update-noodles	1067	896	(83.97%)	956	(89.59%)	2.9831	1777.8326
update-jaldhar	1067	896	(83.97%)	955	(89.50%)	2.9855	1779.9193
update-srivasta	1067	896	(83.97%)	955	(89.50%)	2.9904	1784.3382
update-ana	1067	895	(83.88%)	954	(89.40%)	2.9926	1784.3102
update-nobse	1067	893	(83.69%)	953	(89.31%)	2.9947	1782.2392
update-neilm	1067	892	(83.59%)	951	(89.12%)	2.9974	1782.6098
update-reg	1067	891	(83.50%)	950	(89.03%)	2.9977	1780.8515
update-rmayorga	1067	890	(83.41%)	949	(88.94%)	2.9984	1779.4910
update-evgeni	1067	889	(83.31%)	948	(88.84%)	2.9974	1776.6445

This is actually more hopeful than I thought. There's an obvious weakening as a result of the migrations, but the MSD stays under 3 and the centrality stays fairly constant too. The reachable/SCS counts do decrease, but at this point it looks fairly linear rather than an instant partition. Of course the more keys that are removed the more likely this is to drop off suddenly. Counteracting that DebConf9 is coming up which will provide a good opportunity for normally geographically disperse groups to cross sign, reinforcing the WoT for these new keys.

Either way I at least have a better handle on the current state of play, which gives me something to work with when thinking about how to proceed. For now, bed.

I've followed the advice of Daniel and generated myself a new PGP key. I've moved from an old 1024-bit DSA key (88C7C1F7) to a new 4096-bit RSA key. I've signed the new key with the old one so there is a trust path already, and I've uploaded it to the keyservers today. I'm expecting some DD signatures on it shortly after a trip to the pub tonight. Once the new key is accepted I'll start phasing out the old one, of course. New key details:

pub   4096R/3442684E 2009-05-09
      Key fingerprint = CEBB 5230 1D61 7E91 0390  FE16 5879 7957 3442 684E
uid                  Steve McIntyre <steve@einval.com>
uid                  Steve McIntyre <stevem@chiark.greenend.org.uk>
uid                  Steve McIntyre <93sam@debian.org>
sub   4096R/E2C26E29 2009-05-09

In a couple of days, DPL-elect Steve McIntyre takes over as DPL, after being elected by around four hundred of his peers… Because I can’t help myself, I thought I might poke at election numbers and see if anything interesting fell out. First the basics: I get the same results as the official ones when recounting the vote. Using first-past-the-post, Steve wins with 147 first preference votes against Raphael’s 124, Marc’s 90 and NOTA’s 19 (with votes that specify a tie for first dropped). Using instant-runoff / single transferable vote, the winner is also Steve, with NOTA elimited first and Marc collecting collecting 5 votes, Steve 4 and Raphael 2, followed by Marc getting eliminated with Steve collecting 50 votes, against Raphael’s 26. So, as usual, different voting systems would have given the same result, presuming people voted in basically the same way. NOTA really didn’t fare well at all in this election, with a majority of voters ranking it beneath all candidates (268 of 401, 53.5%). For comparison, only 18 voters ranked all candidates beneath NOTA, with 9 of those voters then ranking all candidates equally. (For comparison, in 2007, 312 of 482 voters (about 65%) ranked some candidate below NOTA, though that drops to 225 voters (47%) if you ignore voters that just left some candidates unranked. Only 98 voters (20%) voted every candidate above NOTA) With NOTA excluded from consideration, things simplify considerably, with only 13 possible different votes remaining. Those come in four categories: ranking everyone equal (17 votes, 9 below NOTA as mentioned above, and 8 above NOTA), ranking one candidate below the others (13 votes total, 7 ranking Raphael last, 3 each for Steve and Marc), ranking one candidate above the others (66 votes; 30 ranking Steve first, 18 each ranking Raphael and Marc first), and the remainder with full preferences between the candidates:

     70 V: 213
     63 V: 123
     56 V: 132
     52 V: 231
     38 V: 312
     26 V: 321

The most interesting aspect of that I can see is that of the people who ranked Raphael first, there was a 1.8:1 split in preferring Steve to Marc, and for those who preferred Marc first, there was a 2:1 split preferring Steve to Raphael. For those who preferred Steve, there was only a 1.1:1 split favouring Raphael over Marc. I think it’s fair to infer from that that not only was Steve the preferred candidate overall, but that he’s considered a good compromise canidate for supporters of both the alternative candidates (though if all the people who ended up supporting Steve hadn’t been voting, Raphael would have won by something like 26 votes (129:103) with a 1.25:1 majority; if they had been voting, but Steve hadn’t been a candidate, Raphael’s margin would’ve increased absolutely to 33 votes (192:159) but decreased in ratio to a 1:1.2 majority.

The last few days have been quite difficult for me and right now I feel like a looser and winner at the same time as I never did before. In a way I feel that I won, since our platforms were so similar my ideas weren't that bad then and the project ack'ed that. The other side is that I'm just above NOTA and not closer to sam.

Anyway, I've already offered more help to the project (that refused) and for Sam. Time to go back to the shadows and keep co-maintaining more than 150 packages that you love to use, and maybe start more two or three subprojects... Thanks for those who voted for me, I hope to see you all during the next debconf and Guilherme, for working hard to keep my act together.

These are some random thoughts based on a not very thorough reading of candidate platforms of the DPL Election 2007, and my subjective view of the candidates based on the mailing traffic I remember reading. Wouter Verhelst: Has quite a broad Debian-background, the platform also seems to share quite a bit of my view of where Debian's problems are at the moment. Doesn't propose a course of action right now, not sure how to judge that. Not sure if I remember Wouter being heavily involved in flamewars, but I do remember reading quite a few of his emails in discussions with interest. broad Debian-background, the platform also seems to share quite a bit of my view of where Debian's problems are at the moment. Doesn't propose a course of action right now, not sure how to judge that. Not sure if I remember Wouter being heavily involved in flamewars, but I do remember reading quite a few of his emails in discussions with interest. broad Debian-background, the platform also seems to share quite a bit of my view of where Debian's problems are at the moment. Doesn't propose a course of action right now, not sure how to judge that. Not sure if I remember Wouter being heavily involved in flamewars, but I do remember reading quite a few of his emails in discussions with interest. broad Debian-background, the platform also seems to share quite a bit of my view of where Debian's problems are at the moment. Doesn't propose a course of action right now, not sure how to judge that. Not sure if I remember Wouter being heavily involved in flamewars, but I do remember reading quite a few of his emails in discussions with interest. Aigars Mahinovs: Quoting from his platform: “My goal of running for DPL is not to be DPL, but to get a few concepts closer to real life.” So don't run for DPL, but start doing these things you're thinking about. Not being DPL has the advantage that you don't have to spend time on DPL stuff that would detract you from these goals. Speaking about your goals: (i) No release: I've thought about that, too, but I feel this would quickly make Debian irrelevant. (ii) $HOME configuration files organisation: take it up with the upstream developers of all the application. I think this is a very good idea, but freedesktop.org would be a better platform. (iii) Old Maintainer Process: Idea looking for a problem. (iv) Dropping Trademarks: not sure what to think about this. Gustavo Franco: Some focus on the desktop, and a constructive attitude towards Ubuntu, both positive in my book. (The first one primarily because on servers Linux is already quite well established, while the desktop is where more work is still to be done. Not because servers are less important.) His goals: (i) Core teams: as with Wouter, he sees that people and what goes on between them are where the problems are. (ii) Release goals: I think building the release based on release goals could be a driving force, but this is more RM area than DPL. (iii) Adding features to the bts doesn't need DPL powers. (iii) New developers: certainly an area that still needs attention, but the intended course is not entirely clear to me. (iv) NEW queue: same. (v) CTTE: Not sure what the idea behind this is. (vi) Groups: yes, but again not entirely clear what and how. (vii) Backports: yes, new versions of some software should go into Debian (stable) faster. Officially supporting backports or something else, I don't know, but this is an area where a DPL could pull together the RMs, security team(s), backports.org people etc. (viii) Universal OS: is this about more media coverage or about more face to face meetings? Both are good, but we should set clear goals beforehand. (ix) Much work is needed, especially in the area of buildd management (meaning: the processes and people behind it!). Does Gustavo have previous involvement here? (x) Vendors, Website, Publicity: This is more or less all about media coverage and popularity. Much needed, but as Debian as it is will never be able to commit to a public official opinion of anything, we'll need to think hard about what to do here. (xi) NMU: I don't see a great need for action here, personally. Overall: this platform contains too much material, I fear trying to tackle all these areas will lead to a burned out DPL within three months and little actually getting anywhere. Sven Luther: It's true that it always needs at least two people for a flamewar. But having a DPL who is always ready to provide one side of an argument is not a good idea. Sam Hocevar: Everything is high-level on his platform. Both good and bad. Not sure how to rate this platform, but I see myself nodding along. Learn from other OSs is good, but I hope he also means active cooperation and not just passive let's see how they do it. Steve McIntyre: Should have won 2006. Certainly did a lot of both behind-the-scenes work and some good communication. The platform lacks mention of relations between Debian and the outside world, which is an area where I feel some work is missing (and where the DPL as the only person with a official role also known outside Debian can make a difference), and also lacks mention of legal problems (trademarks and patents) where I'm not sure how solid Debian's work is. Additional argument in favor of Steve: Having a 2IC and promoting him to DPL the year after might be a good idea overall. Maybe we should actually elect the 2IC and only have a confirmation vote to promote him to DPL? Raphaël Hertzog: I like the DPL board idea. I also like how Raphaël focuses, in his platform, on the DPL board idea and some selected problems. On the other hand, the platform is wholly focused inward, outside relations are important, too ! Anthony Towns: Not sure what to think of the current DPL. I think he had good ideas, and I still think the original “spend Debian funds for the release”-idea was not that bad, but seeing how it all worked out was very, very painful for too many people. The platform seems pretty much empty, so I guess ajt won't have my vote this time. Simon Richter: Maybe I miss something, but I only see “don't repeat the dunc-tank flamefest” in his platform, which seems a bit thin. His observation that the real power of the DPL is to get everybody's attention may be partly true, though, even if this power will be spent as soon as a DPL, trying to mediate, lets himself be drawn into the flamewar instead (I don't accuse Simon that he ultimately will do this, but I fear that it happens all too quickly). Now what? I really don't have the time to thoroughly follow the campaigning, but I'll certainly have a look at the rebuttals, and perhaps somebody will do some summary. So the ballot below will certainly change. (You might also be able to buy the vote if you're rich enough ;-)

 [ 1 ] Wouter Verhelst
 [ 5 ] Aigars Mahinovs
 [ 3 ] Gustavo Franco
 [ 6 ] Sven Luther
 [ 3 ] Sam Hocevar
 [ 1 ] Steve McIntyre
 [ 2 ] Raphaë Hertzog
 [ 5 ] Anthony Towns
 [ 4 ] Simon Richter
 [ 5 ] NOTA

Enrico, you forgot your own advanced ways of wasting time (and have some fun). ;) Here are the summaries of the candidate DPL platforms, in one sentence each: 93sam

Once we don’t Select a friendly community where the packages towards a lot of software, community are most noticeable use to show their packages towards a problem good job.

aigarius

While I were elected DPL, I have to time leave Debian Developers Corner Site, map Search about it should not have not be Even if he has, the NM; process is before.

ajt

Ideally, I’d expect that we ought to make It work together in Linux and a DPL review of the community and October firmware resolutions recall vote maybe That’s been some of stuff I’ve been a server near you United States.

hertzog

The sponsorship, principle.

sho

I believe admit volunteers to scratch our bug tracking system I do what I would like LowThresholdNmu to happen again; Admit it has rhymes with a few of it Debian; is to be really like to automatically see them.

sjr

To the web site, map Search Not Published Yet Back to the Debian Project Select a server near you United States; the web Site, map Search Not Published Yet Back to the debian For other contact information, See the Debian Project Select a server near you United States.

stratus

It is today in the web team, the users: and waited supergroups i will that any Debian support: this change our major Desktop, with Lenny development website, we’ve now almost our official status and how a statistics page.

svenl

To the ban.

wouter

I am of a native Dutch is not an area where possible.

These summaries have been generated by the following script:

for i in 93sam aigarius ajt hertzog sho sjr stratus svenl wouter; do
  echo $i
  lynx -dump -nolist http://www.debian.org/vote/2007/platforms/$i dadadodo -c 1 - 2> /dev/null
done
It is somehow subobtimal, as aigarius and sjr’s summaries show: the headers and footers of the page have some influence, but well… it was fun anyways.

Enrico: if you extract the platforms using lynx -dump -nolist (or w3m -dump ), you’ll only extract the text, with no HTML, and the keywords will vary slightly:

• 93sam: jobs, deal, dds, nms, asking
• aigarius: applications, choose, trademarks, apps, formats
• ajt: effective, neat, hoping, success, interview
• hertzog: broadly, serve, represent, pushed, chosen
• sho: deadline, icons, helps, excellence, freaks
• sjr: published, yet, inc, feb, wed
• stratus: stable, websites, feature, submitter, involving
• svenl: weekend, publish, banning, unfair, protest
• wouter: controversy, seem, background, delegates, therefore

Representative keywords of DPL platforms The DPL platforms are too long and you could use a very, very short executive summary? No problem, I have the technology for it. After the results you can find the kit to build yourself an extractor in the comfort of your home. The results

• 93sam: jobs, deal, dds, nms, asking
• aigarius: applications, aigarius, choose, trademarks, apps
• ajt: humbug, effective, neat, hoping, success
• hertzog: broadly, wouter, serve, represent, pushed
• sho: deadline, helps, excellence, freaks, tasks
• sjr: qb, published, xxxx, r, yet
• stratus: stable, websites, feature, submitter, involving
• svenl: unfair, protest, ban, publish, banning
• wouter: controversy, seem, background, delegates, therefore

Acquiring the data

for i in 93sam aigarius ajt hertzog sho sjr stratus svenl wouter
do
    wget http://www.debian.org/vote/2007/platforms/$i
done

Tokenizing

#!/bin/sh
for file in "$@"
do
    lynx -dump -stdin < $file   tr -c '[a-zA-Z]' ' '   tr '[A-Z]' '[a-z]'   sed -e 's/ /\n/g'   sed -e '/^$/d' > $file.tok
done

Extracting the most representative keywords

#!/usr/bin/python
import sys, math
def read_tokens(file):
    "Read all the tokens from one file"
    return [ line[:-1] for line in open(file) ]
# Read all the "documents"
docs = [ read_tokens(file) for file in sys.argv[1:] ]
# Aggregate token counts
aggregated =  
for d in docs:
    for t in d:
        if t in aggregated:
            aggregated[t] += 1
        else:
            aggregated[t] = 1
def tfidf(doc, tok):
    "Compute TFIDF score of a token in a document"
    return doc.count(tok) * math.log(float(len(docs)) / aggregated[tok])
# Output the top 5 tokens by TFIDF for every document
for name, doc in zip(sys.argv[1:], docs):
    print name, sorted(set(doc), key=lambda tok: tfidf(doc, tok), reverse=True)[:5]

Errata Jacobo suggests to use lynx -dump -nolist or w3m -dump for a more tokenizer-friendly text expansion.