Lars Wirzenius: Debian, 2005
Contents
- December 30: Low threshold NMU page
- December 05: Debconf7?
- November 08: My BTS spam rant
- August 26: Piuparts development using Bzr
- July 25: Debconf5, Debian-Women having an impact?
- July 19: Piuparts is in!
- June 23: piuparts 0.5
- June 19: Oops, piuparts 0.4
- June 06: Sarge!, Vera in Debian as mistake?
- June 01: RFP?
- May 30: Finnish glossary for Debconf5
- May 24: Sarge is not small, How big is sarge?
- May 17: Bug number error checking codes
- May 09: Testing woody to sarge upgrades, Automatic package testing, part 2, Sea-Hack 2005?
- May 07: Automatic testing of packages
- April 27: Packaging tutorial
- April 01: BTS readability
- March 12: We're everywhere
- March 08: DebConf5 statistics lesson?
- February 15: BTS layout and typography
- February 09: Bologna
- February 08: Huge release management discussion coming up?
- January 28: Debconf5 talk wishlist, Project Leader elections are coming up soon
Friday, December 30, 2005
Debian: Low threshold NMU page
I set up the Low Threshold NMU wiki page. The goal is to test whether enough people participate and whether this then has enough of an impact on the quality that changes to the default NMU rules should be made.
Monday, December 05, 2005
Debian: Debconf7?
It has been brought to my attention that there is already scheming going on about the location of Debconf7, the one after Mexico. I know that people in Edinburgh have often expressed their desire to host Debconf, and I for one think it would be a swell location. We must have at least one Debconf where it rains, after all. Also, the last time I was offered, I was too much of a chicken to eat haggis. I'd further like to have the opportunity to view Scottish mountains through a really small window on a light-proof box.
So, Scots, if you want it, you'll have to fight for it. According to Andreas, the main organizer, one of the best ways to fight is to participate in the organization of the preceding conference. This helps the organizers get some understanding of what is involved, andwill make things go more smoothly.
Debconf7 in Ediburgh: because rain is wet!
Tuesday, November 08, 2005
Debian: My BTS spam rant
In recent times, the Debian bug tracking system has been suffering from slowness due to having to handle much spam. When it takes many hours to get a response from the system, usability and productivity hurt a lot. Having waited for a response for an hour again, I wanted to rant about the evilness of spammers, but luckily I did not. My aunt had called me and I had forgotten to press "send" (specifically, I had pressed control-backspace, instead of control-Enter). Oops.
So, instead, I'd like to express my gratitude to Blars Blarson for coping with the BTS spam load. Despite occasional hickups, he and others make sure spam is not something BTS users need to worry about much. Thanks!
Friday, August 26, 2005
Debian: Piuparts development using Bzr
Now that my vacation is over and various crises have been dealt with, I've started working again on piuparts, my package installation, upgrading, and removal tester for Debian. I want to make it easier for other people to contribute to this. So far, I've used CVS for version control, with CVSROOT being on my laptop. My laptop is my main development machine, and I need to be able to work with it in off-line mode. For the CVS/Subversion style of version control, this means having the repository on my laptop, but that makes it hard for other people to use it. (I know Subversion can do some things off-line, but it's not good enough.)
I've looked at several of the new-fangled distributed version control systems in the past months, and I've decided to have a dab at using Bazaar-NG (bzr). It's in development, and nowhere near as mature as, say, Bazaar or Darcs, but where those rub me the wrong way, Bzr seems sensible. We'll see.
Thus, if anyone wants to follow Piuparts development, and make patches, they can follow my development at http://liw.iki.fi/liw/bzr/piuparts. I'm quite new to this whole thing, but here's the basic instructions to work with this:
- To "check out" (using CVS terminology), you create
your own "branch" (using Bzr terminology):
"
bzr branch http://liw.iki.fi/liw/bzr/piuparts". This creates a directorypiupartsunder your working directory. - To fetch any new changes I've made, go into the
piupartsdirectory and say: "bzr pull". This works as long as you don't make any changes of your own. - If you make any changes of your own, do this
instead: "
bzr merge http://liw.iki.fi/liw/bzr/piuparts". This will merge my changes with your changes, in ways that are mysterious to me, but I'm hoping it'll just work, or at least work well enough when compared to CVS.
Given the in-development nature of Bzr, you may need to use a newer version than what is currently packaged for Debian. Sorry about that. I will, however, make frequent tarballs to work around problems and also to allow participation without having to use yet another version control system.
If you want to send me changes, mail me patches (unified
diffs, "bzr diff" does the right thing) or a
URL for your Bzr branch.
Monday, July 25, 2005
Debian: Debconf5
A belated summary of Debconf5. Fun. Tiresome. Crazy noisy people. Sleeping at home is good. Should've talked more with people, hacked less. Hacking at home is good, hacking at hacklab ineffective. Everyone, including me, should've showered more, since it was so hot.
Took a few photos just to satisfy myself once again that I suck at event photography.
Debian: Debian-Women having an impact?
I confess having impersonated a woman recently.
For a while, I used a female nickname on the
#debian IRC channel to see what it is like to
enter the Debian (user) community as a woman. I was happily
surprised. Despite a number of visits and being active on
the channel, I got not a single private message, and all
talk on the channel quite ignored the fact my assumed
gender. I expected at least a couple of guys to try to make
a pass. Either everyone realized what I was doing or else
the situation has changed. Debian IRC channels haven't
always been friendly to women. I'm going to be arrogantly
optimistic and assume the latter.
I suspect that the Debian-Women project is at least partly behind this change. I hope the trend continues.
Tuesday, July 19, 2005
Debian: Piuparts is in!
piuparts is now in the archive. It even has a bug (and a stupid one at that, I should've had better quality control; I'll do an upload in the near future to fix this).
I have made some changes the past few days, and been running piuparts on parts of the archive (well, as much as my server at home can manage). Lots of packages fail, but mostly they fail because of their dependencies. For example, fontconfig and libfontconfig1 depend on each other, and (sometimes) removing them causes problems and leaves behind some cruft. Lots of packages depend, possibly indirectly, on fontconfig. Ignoring such problems makes the statistics much better. In fact, it would seem that most packages work well, as far as piuparts testing is concerned.
There has been some talk of using piuparts in a centralized fashion to check all packages in the archive, and all new versions. This will probably take a while to become usable, though. I would like to see package maintainers use piuparts on their own packages (just like they use lintian and linda).
I would also like to see about making piuparts use user mode Linux or xen or qemu or some other virtualization system to reduce the chance that packages wreak havoc on the host system. However, it seems to now work well enough for most packages.
Thursday, June 23, 2005
Debian: piuparts 0.5
I made a new version of piuparts, my tool for testing installation, upgrades, and removals of Debian packages. The major change is that it now can test upgrades between Debian releases (say, woody to sarge to etch to sid).
See piuparts-0.5.tar.gz for the code. No Debian package yet, sorry.
Sunday, June 19, 2005
Debian: Oops
Bah. That "This & that" entry wasn't meant to go live. I'm not sure how it happened. Sorry for breaking Planet's RSS feed, though, really, planet.debian.org needs to be fixed to do things properly. My rss feed has the ampersand properly encoded, but planet.debian.org puts an unescaped ampersand in its feed.
Debian: piuparts 0.4
Frank Lichtenheld and others have brought up the idea of automatically testing installation, upgrading, and removal of packages. It struck me that it should be pretty simple to implement at least basic versions of this. The result: piuparts (now at version 0.4). From the manual page:
piuparts tests that Debian packages can be installed and removed without ill effects. It is meant for people who create Debian packages to test them before they upload them to the Debian package archive.
piuparts creates a chroot environment with a minimal Debian installation, plus any packages that are needed for the test. It then installs the packages, and removes and purges them, and checks that no files are left behind, and that no extra files are removed.
If the package is known to
apt-cache, piuparts also does an upgrade test, where it first installs the package withapt-get, and then installs from the package files given on the command line, and finally removes and purges everything that got installed. The assumption is that the versionapt-getfinds is older than the package file.
The current version is quite simplistic. It may well be too simplistic to work for more than in simple cases, but it's a start.
I'd be very curious to hear about suggestions for improvements. Comments on this preferably to the debian-devel mailing list, thanks.
Monday, June 06, 2005
Debian: Sarge!
Sarge has been released. Yay!
Many people have worked hard to make this happen. At the risk of forgetting someone important, I would still like to especially point out the release managers and assistants: Steve Langasek, Colin Watson, Joey Hess, Andreas Barth, and Frank Lichtenheld. Anthony Towns, the previous release manager, has also been crucial. Joey Hess has been essential for the installer, doing much of the work, and leading the project. All of them deserve a great big thanks. If we ever meet in person, I'll buy drinks or dinner.
In addition, everyone else who maintained packages, translated things, fixed bugs, reported bugs, maintained infrastructure, or otherwise helped with the development of sarge or the running of Debian deserves a thank you. I am alas not rich and can't buy drinks or dinner for so many people.
Now is a good time to celebrate, and relax, and pat ourselves on the back. It took a long time, but we did it: we're good, and today we can smile easily and be satisfied. We can finally rest our tortured brains and stop coming up with woody jokes. Work on the next release, etch, will start soon enough, but we can worry about that tomorrow, or next week.
Debian: Vera in Debian as mistake?
Some time ago my friend Vera showed interest in becoming involved with Debian development. She now suggests unconventional approaches to marketing and other things. And here I thought hot-babe was controversial. I'm not sure that Debian is quite ready for Vera yet.
Wednesday, June 01, 2005
Debian: RFP?
There seems to be over one thousand open Request For Package bugs against the wnpp pseudo-package. I wonder whether they server any purpose in this age. I think we've established pretty well that anything that anyone's ever written is something someone somewhere wants packaged for Debian.
Monday, May 30, 2005
Debian: Finnish glossary for Debconf5
If you're coming to Debconf5 in Helsinki, and don't know any Finnish, here's an essential glossary. I'll try to provide pronounciation guides as well: speak very slowly and clearly and people might understand you. Shouting won't help.
- Thank you: kiitos (pronounced approximately as "key toss").
- Greeting(s) (for all occasions): tervehdys ("ter" from terry, "ve" from verandah, and "dys" from dysentery).
- Good bye: hei hei ("hey hey").
- One, two, three, four, five, six, seven, eight, nine, ten: yksi ("ix e"), kaksi ("kax e"), kolme ("col" from colon, "may"), neljä ("nel" from Nelly, "ya" from Yankee), viisi ("we see"), kuusi ("coo" from cool, see"), seitsemän ("see it see man"), kahdeksan ("ca" from "carve", "dex", "an"), yhdeksän ("iih", "dex", "an"), kymmenen ("kim man an").
- Taxi: taksi ("taxi").
- Where am I: missä olen ("mis", "sa" from salad; "ol" from olfactory, "an").
You may also want to print out a few pieces of paper with the following phrases (I'm not going to give pronounciation guides for these):
- Olen ulkomaalainen ja eksyksissä. Auttaisitteko minut Otaniemeen? ("I am foreign and lost. Please help me to Otaniemi." Otaniemi is where Debconf is.)
- Ajaisitteko minut osoitteeseen Jämeräntaival 4. ("Please drive me to Jämeräntaival 4", to be shown to a taxi driver if really lost.)
- Missä on lähin tietokonekauppa? ("Where is the closest computer store?")
- Kadotin kannettavan tietokoneeni, auttaisitteko minua etsimään? ("I lost my laptop, would you help me look for it?")
- Voitteko lainata ruuvimeisseliä / ilmastointiteippiä / längatonta Internet-yhteyttä? ("May I borrow a screw driver / duct tape / wireless Internet?")
- En ymmärrä mitä sanot, mutta saanko tarjota juotavaa? ("I don't understand what you say, but may I buy you drink?"; this works equally well for all gender combinations).
- Anteeksi, tarkoitukseni ei ollut ärsyttää, älä läimäytä enää. ("I am sorry, I did not intend to annoy, please don't slap me anymore.")
- Epäilen, että minua seurataan. Missä on lähin poliisiasema? ("I think I'm being followed. Where is the nearest police station?")
I hope these are useful.
Tuesday, May 24, 2005
Debian: Sarge is not small
Right after I posted my previous entry, I was told about an existing effort to count lines of source code in sarge. Here's a summary: 8638 source packages, over one million files, over 245 million lines of source.
That's pretty big.
Debian: How big is sarge?
Here's an idea for someone who doesn't want to help with fixing release critical bugs, but would like to do something else for sarge.
For some past releases of Debian, there have been attempts at counting the number of lines of source code in the release. I did something in 1997 or so, though I've lost the information since. Other people have done it for other releases, though I've lost links to them. I think it would be nice if someone did it for sarge. sloccount seems like a nice tool: adding a bit of wrapper scripts to unpackage sources (and then unpack upstream tarballs inside sources) should take a day or so for someone.
I bet that anyone with a beefy machine and a local mirror could then run the script on the entire archive in a couple of days and post results. AMD64 can build the entire archive in a few days, I'm told, so just unpacking and counting them shouldn't take very long.
Tuesday, May 17, 2005
Debian: Bug number error checking codes
The Debian bug tracking system now has bug numbers well over three hundred thousand. That is six digits. Typos are getting fairly common, resulting in the wrong being closed. This can be combatted by people adopting a never-type-always-copy attitude to bug numbers, but that is not particularly likely. I rather think that adding an error checking letter to bug numbers would be good. Perhaps something like "add all numbers together, take modulo 26, and pick the corresponding letter". I'm sure there are better ways to compute it, though, and some of the letters are too similar to digits and should not be used.
Use of the error checking letter should be optional, for backwards compatibility, but should be encouraged.
(I'm only half-joking here.)
Monday, May 09, 2005
Debian: Testing woody to sarge upgrades
Now that sarge is frozen it is high time to start testing upgrades from woody to sarge. Using qemu, the CPU and PC emulator, can make this easier to do, especially repeatedly. Here is how I have been using qemu:
- Create a file to function as the hard disk for qemu:
dd if=/dev/zero of=disk.qemu bs=1073741824 seek=5 count=0(this creates a five-gigabyte file called disk.qemu; adjust of and seek according to taste). - Download the woody installation cd image. The first one is sufficient.
- Run qemu with the following command:
qemu -user-net -boot d -cdrom woody.iso disk.qemu(adjust filenames as necessary). This will start a woody installation. Install a basic woody system, then shut it down. Ctrl-Alt-2 will get you to the qemu "serial console", where you can type "quit" to quit qemu. - Make a copy of disk.qemu (to, say, woody.qemu) so that you can easily go back to a known state without having to install all of woody again. You might want to compress the copy; filesystem images usually compress quite well.
- Install the packages whose upgrade you want to test
into disk.qemu by running qemu again:
qemu -user-net disk.qemu. - Finally, adjust /etc/apt/sources.list in disk.qemu and do the upgrade test. Make notes and file bugs as necessary.
When doing installations many times, it is usually comfortable to not have to re-download packages from the Internet. Using a caching HTTP proxy, an apt proxy, or a local mirror helps a lot. I use debmirror to maintain a local mirror.
Debian: Automatic package testing, part 2
In response to my idea about automatic testing of Debian packags, this Ubuntu wiki page was pointed out to me. It is much more thought out than my initial idea. I don't think I had heard of this beforehand, but it is not impossible. Anyway, it would be great to see Debian and Ubuntu work together on this.
Since pbuilder already has much of the functionality (setting up a chroot and such), I suspect it should be a fairly simple modification to it to do at least a simple test to see that installation works, upgrade works, and that uninstallation doesn't leave extra files around, or modify unrelated files. Running tests on a centralized server should preferably be done in a virtual machine (qemu, xen, whatever), because of security reasons, but when people build their own packages, they should anyway have enough trust in the code that it doesn't contain booby traps.
Debian: Sea-Hack 2005?
An idea I've been toying with lately: a three-day Debian hacking party on the ferries (read: big luxury cruisers) between Helsinki and Stockholm. Finns would take the cruise from Helsinki to Stockholm and back. Swedes would take the cruise from Stockholm to Helsinki and back. Each would do one crossing by themselves, and the other in full company. If enough people from each country joins, it would be possible to have a meeting room (even a small auditorium), without it becoming excessively expensive. Internet access can also happen then, though probably it is pretty slow (thus, a USB hard disk with a Debian mirror would be needed).
There should be some goal to the hacking, of course. Like, say, fixing bugs or such.
Maybe this would be doable in the fall. This summer we have Debconf5, so the fall sounds like a better timing.
Saturday, May 07, 2005
Debian: Automatic testing of packages
What a better thing to do at a wedding reception than talk about Debian. I had a talk with Richard Braakman (also known as "dark") about automatic tests for Debian packages. My current thoughts about this are as follows:
- Testing of upstream functionality (unit tests and so on) should be added to upstream source code and sent to upstream to be included in future versions.
- Testing of packaging functionality should be done as
much as possible in lintian and linda. Package specific
tests should also be supported. These might be run
during package building, and after a package has been
installed. The tests should be in the source package.
Adding optional targets
check-buildandcheck-installationmight be a good way to go. - Making a tool to automatically (and safely) check fresh installations, removals, and upgrades would be cool. Something that would create a filesystem image, add depended packages, and then make a copy of it. Then install the package into the copy, remove it, and see if any extra files were left behind, or any files not belonging to the package were unduly modified. This tool should be runnable both by developers for their own packages, and by lintian.debian.org or a similar machine.
These are just ideas, however. I don't have the time or energy to work on them, at least for the time being.
Wednesday, April 27, 2005
Debian: Packaging tutorial
I have a tutorial on making Debian packages to three friends of mine. I had made some slides, which probably aren't useful without my handwaving, however. We had a bit of a timing problem, so we didn't get quite far enough to try our hand at making packages, and will do that later, maybe next week.
It was fun. Maybe I should offer to give the tutorial to, say, prospective Finnish Debian developers at Debconf5?
Friday, April 01, 2005
Debian: BTS readability
Wrote a patch to debbugs, the Debian bug tracking system software, to make the pages it outputs use CSS for formatting (colors, spacing) instead of raw HTML. This makes it easier to modify the way the pages look. Also made a CSS file to add some spacing between bugs in the package bug list page. This was the original reason I started caring about how the pages look at all: I read quite a lot of bugs for all sorts of packages and reading long lists of bugs was tedious. With a bit of extra space, things are much more readable, I think.
See #228972 for more information, including the patch after the bug tracking system has processed the mails.
There's plenty more that could be done to improve the readability of BTS pages, even without redesigning everything. For example, there's no point in displaying most e-mail headers normally. My Perl skills aren't up to the task of fixing that, however.
Saturday, March 12, 2005
Debian: We're everywhere
I just noticed that according to the Debian developer world map there is one of us in the middle of Greenland and another in the middle of Antarctica. Debian truly is universal!
Well, global.
Unless they're errors in the data.
But that wouldn't happen, right?
Tuesday, March 08, 2005
Debian: DebConf5 statistics lesson?
One more wishlist for a talk at Debconf5: a brief course in elementary statistics, including data collection, simple frequency analysis, average, mean, basic distributions, and so on. Particular emphasis on ways in which statistics can be done wrongly and how people lie with statistics.
People keep insisting on using pseudo-statistics to argue their point. For example, by taking the download numbers for one particular Debian mirror and pretending that they are representative for all users. It would be nice to stop this kind of useless argumentation.
Tuesday, February 15, 2005
Debian: BTS layout and typography
There was some discussion on IRC about ways to make the Debian bug tracking system's web interface nicer to use. I think it would be possible to achieve quite a bit with only small changes to the backend, by fixing some of the markup that is generated to be valid and to add a class attribute here and there. Then a CSS file can do the rest. I played around with this for a bit and created some samples of what an index page for a package could look like: the original, and my first, second, and third versions.
I did not have the time to do any major changes, like try table based approaches. It might be good for someone to write up or collect a few sample users and use cases and then start a redesign of the web interface.
Wednesday, February 09, 2005
Debian: Bologna
LocalGroups on wiki.debian.net lists various local Debian groups. Among them is this:
The Secret "Fetch Every DD Passing Thru Bologna and Take 'em To Dinner" Group
Location: Bologna, Italy
Description: Thou Shalt Not Pass For Bologna Without Gaining An Extra Kilo
I'd like to visit Italy some year. Now I have one more reason.
Tuesday, February 08, 2005
Debian: Huge release management discussion coming up?
For some time now, I've avoided talking about Debian release management except in very small gatherings of people. This is one of the topics that has a tendency to explode, resulting in very large and long discussions. Such discussions aren't useful right now, when we're working on getting sarge released. Large discussions distract from that.
I have today drawn a further conclusion about the issue: I don't know enough about Debian release management to talk usefully about it. I'm not sure anyone else does, either. I expect, however, that very soon after sarge is released, several Debian mailing lists will explode in volume with discussion about how to do release management better for etch. Those discussions are likely to last quite a while, and even if they happen not to degenerate into flame wars, the sheer volume will mean that they aren't going to be very productive. I have an idea for maybe avoiding that.
We could have free discussion about the topic for, say, one or two weeks. After this, the release management team will draft a proposal for how they intend to make the etch release happen, using any inputs from the discussion they like. This draft will then be discussed a further one or two weeks, and then the release management team will publish their final plan. This plan will be adhered to, to the letter, and without exception, and disobedience will be punished by expulsion from the ...
Er, sorry, I went into control freak mode there for a moment.
Let me try again: I think it would be good to at least try to put some structure into some of the more controversial discussions we have. In the case of release management, where we have a clearly identified team in charge, the structure might be that they make a draft and that is discussed, then they make a decision of how to proceed. That ends the discussion, until there is a need to change the plans.
This way, perhaps we could have more productive discussion than several weeks of open-ended flooding of debian-devel.
Friday, January 28, 2005
Debian: Debconf5 talk wishlist
Debconf5 registration is open. This reminds me that there are some topics I would like to see there, or somewhere.
- A tutorial or workshop for writing good manual pages. All commands in Debian are required to have manual pages and it would be nice if they were nicely written and properly formatted. Perhaps other formats might be good too, as separate talks.
- Possibly a more general technical writing tutorial or workshop, something to help make it easier to produce good quality writings for and about Debian. Could be as simple as a checklist of most typical errors, plus a coverage of tools to help with language, and a list of links to sites where you can easily find help for this stuff.
- A tutorial on using gettext as an application programmer or translator. Good practises for translating programs. Existing translation teams and good ways to work with them, as translator or Debian developer.
- A tutorial on writing or improving tests for lintian and linda, the package quality checking tools.
- A tutorial on Unicode. Unicode is a fairly complicated character set, very much unlike ASCII or Latin-1, and few people understand it well. Things like several ways to encode a sequence of Unicode character and several ways of representing a single code point (whatever that is) are mystical and confusing.
- Ways to improve package building and general compilation speeds, by using distcc and ccache and other methods.
- A tutorial or workshop on adding automatic tests to packages to be (perhaps optionally) run at build time, so as to catch build or configuration errors or such.
- Presentations from various important parts of Debian about what they actually do and how. For example, at Oslo there was a presentation by the ftp-admins. Something similar from the DPL, the release managers, debian-installer developers, toolchain maintainers, the security team, and GNOME and KDE teams would be nice. Others too, I have just listed here what I would be most interested in hearing myself.
- An overview of our track record for releasing fixes for security problems. Possibly combined with a talk about looking for common types of security problems in one's packages and the proper ways of releasing fixes by co-ordinating the release of the fix with other distros and the upstream developers.
- A talk on profiling memory usage correctly (including why it is difficult to do that via top and why the X server doesn't really use 128 megabytes of RAM) and what to do to avoid memory leaks, excessive memory usage, and in general how to avoid wasting memory needlessly.
- A presentation on copyrights, trademarks, and software patents, implied and explicit warranties, liabilities, what they actually are, how they affect free software, and how they work in various parts of the world, and what the status of various current changes to this are.
- A presentation of how easy it is to break into laptops at conferences or other large gatherings and what one can do about this. This could also cover other safety and security isues, such as doing backups when not at home, avoiding to have one's laptop stolen (and how useless Kensington locks are), and not having people sit on one's laptop.
I'm not going to offer to give talks on these, except perhaps the first one. The rest, I'm not qualified to. Would be nice to hear them from others who are qualifed, however.
Debian: Project Leader elections are coming up soon
I happened to read the Wikipedia page on Vlad Tepes, a figure in 15th century Romania, a part of Romania next to Transylvania.
A very rough summary: Vlad's father the Wallachian king makes peace with Turkey, sends Vlad and other son as hostages. Hungary attacks Turkey, forces Wallachia to join, Wallachian king sends a third son. Attack fails. Hungary vindictive, murders Wallachian king and third son. Turkey annoyed, releases Vlad, gives him an army. Vlad conquers Wallachia, becomes king, kills lots of people brutally. Hungary annoyed, attacks, throws Vlad out, puts in puppet king. Puppet king switches sides, likes Turks. Vlad gets friendly with Hungary, gets army, attacks puppet king, becomes king, kills lots of people brutally. Later, Hungary attacks Wallachia, captures Vlad, keeps Vlad prisoner. Later, Hungary lets Vlad become king again. Vlad kills lots of people brutally. Eventually Turkey annoyed again, kills Vlad.
Keeping this in mind, it is about time to start the Debian Project Leader campaigns again.