One of the most debated points at the DebConf&Debian BOF was money management. Let's talk about how it works in an ideal world, and then how it tends to work in practice. This post only talks about year-to-year management, I hope for another post talking about the complexities of budgeting within a single year.In an ideal world, DebConf fundraises all the money it needs to go on. There is a DebConf sub-team for fundraising, since Debian doesn't have its own fundraising team. This team make brochures and solicits sponsors - there will be another post about this by someone on the fundraising team.We do our best to raise enough money to cover the conference, but it's long and hard work. In the months leading up to the conference, we are almost always running short. However, in the end, somehow, it comes through by a combination of cutting costs and continued fundraising work.The money is held by various nonprofits like SPI in the USA and FFIS in Europe. They hold it in trust for Debian. I think most people on the DebConf team agree that this money belongs to Debian, but is earmarked for DebConf since it was fundraised for DebConf. In the past, the DPL has not been asked for permission to use DebConf-fundraised money to put on a DebConf, since that's always been kind of obvious that it's for DebConf.Planning how much it will cost is hard. Venue costs aren't always known in advance, and we don't know our number of attendees until late. There are many uncertainties, which will be described later. These questions are hard to answer, but not impossible. Most of they time things work out in our favor.At the end of the conference, we tally everything up. Usually(=always, as far as I know), there is a surplus. This surplus is important, since DebConfN+1 usually needs a little seed money to get started before the new funds start rolling in. Historically, this seed money has been used for DebConfN+1, since it was raised earmarked for DebConf.In practice, it works out mostly like this. We keep track of the money, and try to stay within our budget, and cut things when we need to.For the last two years (coinciding with the recession), we have expected a deficit in the months and weeks leading up to DebConf. In these cases, we asked the DPL for some money to be given from Debian general funds for DebConf, and we provide background on our fundraising and budget status for use in making that decision. Both times, the Debian funds went to ensure that we could get travel sponsorship out. Debian general funds are not used without DPL approval.Also, keeping all the paperwork straight is a hard task. We have limited people, and the budget-trackers are always doing many other jobs, too. Personally, I'm not convinced that we always know how much the exact post-DebConf surplus is and where it is (SPI, FFIS, ...) each year. It sort of gets morphed into the general Debian money, and then we know "we have (about) XXX surplus" and then use that amount as our starting seed for the next year, taken from wherever is convenient. If Debian gives money to help make DebConf happen, it's usually as a loan. However, this loan isn't tracked carefully year to year. Someone looked up numbers during the BOF and reported that Debian has given/loaned 50,000 USD to DebConf over the years, but it's hard to know just how accurate that is. For comparison, the total DebConf budget over those years has been close to 1,000,000 USD, as best I can figure.We've tried various types of accounting software with mixed success. They are a lot of overhead, and we usually revert to keeping track of things in spreadsheets.
Our goals for budgeting (being self-sustaining) are good and well agreed on, but the implementation is hard.However, it's a place where it is easy for dedicated volunteers to get involved. If you wanted to help to make this better, you could do a lot of good by watching #debconf-team and lists, making careful records of our cash flow and where it comes from and goes to. All money we spend is announced and documented on the lists, so the information is there. To really do a complete job, this person would need to remain motivated in the months after DebConf and wrap up all of the final payments. Preferably, we'd have the same person year after year.There are many more suggestions that both others and I could make, but I'll save those for later.Tags: debconf

In a great post a few days ago, Jono asks why you are doing free software and reminds us to remember it. It s quite easy to lose sight of our goals and motivations while working on the day-to-day tasks. This reminds me of an interesting point made in the course I m currently studying on Applying Our Co-operative Values and Principles. As well as our shared values and principles, each co-op should have a statement of its goals. For our co-op, that s to provide computer-related services . For the Co-operative Group, it s currently inspiring young people; tackling global poverty; and combatting climate change it s a big co-op, so it has big goals. But while goals are a shared commitment, your motivation for them is often a personal thing. Often it will be rooted in a negative, a dissatisfaction about how the world was before you started, then making that into an excitement about what you could do, the new possibilities that are opened up. I think you can see this a little in Jono s motivation of how excited they were at exploring their new system and many of the comments there. They re positives and often the silver lining around some cloud. So, please, head over to Jono s page and share your motivations. Then pop back to my site and tell me your goals (or how I ve misinterpreted this ) in a comment.

I was finding myself to be running the same povray command lines over and over again. And then ffmpeg2theora. And occasionally forget to update one or two .png files in the mean time, because I was trying and trying and trying some stuff all the time, and forgot that one frame in the final render. That's silly; that's why we have make. So I wrote me a makefile.

START := $(shell grep 'Initial_Frame' $(INIFILE)   cut -d'=' -f 2)
STOP := $(shell grep 'Final_Frame' $(INIFILE)   cut -d'=' -f 2)
NUMBERS := $(shell seq -w $(START) $(STOP) )
POVFILE := $(shell grep 'Input_File_Name' $(INIFILE)   cut -d'"' -f 2)
ifeq ($(OUTPUT),)
OUTPUT := $(basename $(shell grep 'Output_File_Name' $(INIFILE)   cut -d'"' -f 2))
endif
ifeq ($(OUTPUT),)
OUTPUT := $(basename $(INIFILE))_$(basename $(POVFILE))
endif
PNGFILES := $(foreach nr, $(NUMBERS), $(OUTPUT)$(nr).png)
LEN := $(shell echo "$(STOP)"   wc -m)
$(OUTPUT).ogv : PATTERN := $(OUTPUT)%$(LEN)d
$(OUTPUT).ogv : $(PNGFILES)
	ffmpeg2theora -f image2 -i '$(PATTERN)'.png -o $@
$(OUTPUT)%.png : ONAME := $(OUTPUT)
$(OUTPUT)%.png : INAME := $(INIFILE)
$(OUTPUT)%.png: $(POVFILE) $(INIFILE)
	povray $(INAME) -D +SF'$*' +EF'$*' +O$(ONAME)
ifeq ($(CLEANFILES),)
clean:
	$(RM) $(CLEANFILES)
endif
CLEANFILES := $(CLEANFILES) $(PNGFILES)

The first part, to just write the makefile so that it would work, was easy. The second bit, write it so that you can include it in the same Makefile several times and have it generate patterns for the files you need, without having them conflict with eachother, was... slightly harder. But not impossible, apparently, with GNU make. Use like this:

INIFILE=foo.ini
include povanim.mk
INIFILE=bar.ini
OUTPUT=bar
include povanim.mk

with povanim.mk containing the above Makefile Now just run 'make' or 'make bar.ogv', wait for the rendering and encoding to complete, and you have an animation film. You can even use make's '-j' option to speed up processing by using multiple processors. Which will no longer be useful when povray 3.7 comes out (since that uses multithreading to use all cores with a single povray instance, anyway), but it is for now.

Recently I was surprised to find that many of the rules I took for granted when dealing with an OpenPGP keyring, and the other activities associated with a web of trust, were new to some people I spoke to. These rules are born from a mixture of experience, accepted good practice, and wider reading, with a small dose of paranoia thrown in for good measure.

• Protect your secret keyring with file permissions. For GPG, your ~/.gnupg directory should not be readable by anybody else, including root (even though he could break in if he wanted). Mine is octal 700, and the secret keyring itself is 600.
• Create a revocation certificate, and keep online and offline copies (gpg --gen-revoke <keyid>). The revocation certificate is published to key servers by you in the event that you detect key compromise or loss. It s important that this is also well-protected, because the secret key is not required to upload it. Print a copy in bold and on good quality paper, so it will last a long time, and preferably keep them both off-site in a trusted location. Typing all those characters back in is a bore, but if your online copy fails it s better than being impersonated.
• Use a good pass-phrase, not a password. A pass-phrase is actually easier to remember than a string of random characters, without risk. It can be long enough to make brute-force attacks pointless, and if you re using the key a lot and can t be bothered to type it all the time, gpg-agent is a handy and safe tool. Your login password is not an acceptable pass-phrase for your secret key!
• Regularly refresh your public keyring from a well-connected keyserver. I detailed this in an earlier post; it s a case of calling gpg --refresh-keys once a week or so. This is the first line of defence against other people s keys being compromised, since without it you ll never know that your messages to them are now vulnerable. A well-connected server, like those in pool.sks-keyservers.net, matters since not all servers synchronise predictably.
• Rotate encrypting sub-keys regularly. This reduces the effect of a compromised key: if you rotate keys annually, a compromise only opens one year of mail. Small comfort, but every little helps. Don t delete the old keys though, just revoke them otherwise you won t be able to open mail from those senders who don t refresh their public keyrings.
• Keep your key offline and make a separated signing sub-key for day-to-day use. There isn t room to go into detail here, but you can export a signing sub-key with a relationship to your primary key material, so if it is compromised you can revoke it without losing all those carefully-collected signatures. The same goes for encrypting sub-keys. Adrian von Bidder has a guide to this, but he warns that it should be taken with a pinch of salt, so this isn t so much a rule as an interesting idea. I have not experimented with this yet.

And some rules about signing and signatures:

• Don t place too much store by signing parties. Parties are great for rapidly building a web of trust, but a part of that trust is to do with how the other party checks identities. I don t believe it s possible to establish that with just a few minutes chat and an identity check, so I never make a sig2 or sig3 on a key I met at a party. I m usually happy to do that later when I have an established relationship with the key holder, of course.
• Never upload your own signature to a key server. Apart from the fact that the key holder might not want their key published, you also have no way to prove that the key holder has access to the email address on their UID. It s much better to send the signature to them encrypted, which demonstrates that they the both key and can read mail at the address (the caff program is ideal for this).
• Give personal trust (the trustdb) carefully. Getting that message Good signature from in your mail client is really nice, but not at the expense of giving away trust where it is not deserved. In the same vein as not placing too much trust at signing parties, you should avoid the temptation to over-trust keys in your personal trustdb. Reputation on a mailing list is absolutely no substitute for observing the party taking care over their verifications when doing face-to-face signings.

Do you have other rules or guidelines that you use when dealing with keys and signatures?

A discussion the other night suggested that I m quite unusual among geeks in doing vanishingly little customisation of my system most of my systems have something very close to their default configuration, individual programs are usually at most a very few tweaks away from their upstream settings. For Emacs all I tend to do is install revbufs, set Linux mode by default for C and turn on syntax highlighting and line number mode (sometimes the last two only get done when I start Emacs). For vim it s just configuring a 72 column word wrap if my main use for vi on the system will be writing e-mail. For GNOME it s putting a terminal launcher in one of the panels and setting focus follows mouse. All very trivial stuff done in five minutes. The theory here is partly that I just can t be bothered to spend more time on tweaking things (and the subsequent carrying around of those tweaks) and partly that it ensures that I m not confused when I end up using a new system or someone else s for whatever reason. I find it somewhat odd that this would be something you d want to spend any time on.

This post concerns Romanian politics, internal affairs and improper direction of public funding for new hideous churches in spite of education, culture, health, technic development and old monuments. Thus I will write this in Romanian. Curious foreigners can try to read the text via Google's translation.

---

Din cauz c suntem n secolul XXI i consider c e o prostie imens s b g m bani n biserici n detrimentul educa iei, culturii, s n t ii, dezvolt rii tehnice i a vechilor monumente, iar politicul din Rom nia pare dornic s dea bani cultelor, am ajuns la concluzia c este cazul s -i scriu reprezntantului meu (teoretic) n Parlament, Deputatul Florin Iordache. Am aflat de ce colegiu apar in uit ndu-m aici i apoi n lista oficial cu deputa ii.




I-am trimis textul de mai jos:

M numesc Petri or Eddy i sunt unul dintre cei pe care i reprezenta i n Parlamentul Rom niei. Este pentru prima dat c nd scriu unui parlamentar care m reprezint n conducerea statului rom n i o fac pentru a-mi exprima n mod clar i r spicat ideile i opinia n ceea ce prive te subiectul pe care l voi discuta mai jos. Am 30 de ani, sunt programator, am muncit i mi-am pl tit taxele de c nd am fost angajat, din anul 4 de facultate p n n prezent, adic de vreo 6-7 ani. Nu, acest mesaj nu este un strig t de ajutor, nu a tept pomeni, nu am milogit niciodat , mereu am muncit de i v d c pentru unii parazitismul fiscal a devenit un mod de via . Din acest motiv sunt revoltat.

Sunt revoltat pentru c :
- de i pl tesc taxe i impozite care ajung la peste 60% din venitul brut, nu primesc n schimb nici un fel de servicii, nici un fel de infrastructur , nici un fel de respect, nici un fel de eficien
- de i lucrez de ceva timp, am observat c pe unde am lucrat competen a i performa a erau o necesitate; n aparatul de stat nu este cazul
- de i sunt destui ca mine care pl tesc taxe i impozite, vocile noastre sunt ignorate i banii no tri sunt arunca i pe fereastr de cei ce administreaz fondurile colectate.

Domnule deputat sunt revoltat c de 15 ani de zile dispar n medie aproximativ 4 coli zilnic i apare, tot n medie, o biseric la fiecare 2 zile, iar asta se nt mpl cu accep iunea aparatului politic. Spitalul din Caracal, ca orice alt spital din Rom nia, e prost dotat, nu exist personal suficient, nu are fonduri pentru medica ie pentru pacien i, pe scurt, este un dezastru care e pe cale s se nt mple. i cu toate astea, banii se duc spre biserici. Se fac dona ii de coli i terenuri c tre biseric , n mod ilegal i abuziv chiar n jude ul Olt.

Ultima perioad n care religia a condus lumea s-a numit Evul Mediu i cred c orice om care a tr it m car 5 ani n secolul XXI poate s observe c nu religia ne-a adus mari beneficii, ci tiin a i tehnologia. n Evul Mediu tratamentul se f cea prin s nger ri , t ieri sub limb , scoaterea argintului viu i tot felul de alte supersti ii f r nici un efect pozitiv sau chair cu efecte negative.

ntre timp umanitatea a progresat i am descoperit medicina, curentul electric, am explorat universul, am aterizat pe Lun , am pus zeci de sateli i artificiali pe orbit , am aflat foarte multe despre univers i lumea care ne nconjoar , am inventat noi materiale (plasticul, p nzele impermeabile, kevlarul), am investigat lumea f r idei preconcepute dup metoda tiin ific , iar lucrul acesta ne-a mbun t it via a n toate aspectele ei. Sperant de via a crescut de la aproximativ 30-40 de ani n Evul Mediu, la 70-80 de ani n prezent, totul datorit tiin ei aplicate. Datorit tehnologiei i tiin ei pot s v scriu aceste cuvinte i tiu c vor ajunge la dumneavoastr , nu datorit unor incanta ii sau ritualuri, nu datorit telepatiei, de i mediul sta de transmisie se apropie foarte mult de ceea ce define te ca fiind telepatie :-) . Cu toate astea, unii consider c religia trebuie finan at pentru c e religie, nici m car pentru c ar avea programe sociale, contribu ii cuantificabile reale, nu, doar pentru c este religie.


Am citit foarte multe articole din pres , articole bine documentate, i am senza ia c tr iesc ntr-o lume incon tient c nd v d cum banii care ar trebui s ajung n drumuri, coli, spitale, cercetare, medicamente, programe sociale cu real impact, ajung n noi i noi biserici de beton n timp ce monumentele istorice, bisericile din lemn, m n stirile cu adev rat valoroase sunt l sate n paragin . Asist cu o senza ie de dezgust continuu la felul n care ne batem joc de cei ce ne salveaz vie ile, medicii, de cei ce ar trebui s ne fac educa ia, profesorii, de cei ce ne sting casele dac iau foc, pompierii, i, de felul n care ridic m misticismul religios la rang de virtute. Este de-a dreptul jignitor i aberant ca alfabetizarea tiin ific n secolul XXI s fie at t de joas nc t s avem 42% din popula ie care cred c Terra este centrul universului, s avem oameni care cred c astrologia este tiin ific , s NU avem nici m car o universitate n top 500 n lume, este jignitor s fim n permanen n coada tuturor clasamentelor pozitive i n fruntea tuturor celor negative.

Recent money.ro a publicat un articol n care esitma foarte conservator c averea Bisericii Ortodoxe Rom ne se nv rte la peste 3 miliarde de euro, are scutiri de impozite, are zeci de afaceri i cu toate acestea, statul continu s scuteasc cultele de impozite, ba chiar le ofer bani ntr-una. La o asemenea avere nu cred c mai poate fi vorba de necesitatea finan rii de c tre stat. Oamenii pot decide s doneze direct c tre bisericile lor bani i nici nu mai implic pierderile inerente ce apar datorit administr rii fondurilor de c tre stat.


Statul nu este un organ aparte, statul trebuie s munceasc pentru mine, cet eanul, iar eu sunt mpotriva acestui tip de batjocorire i napoiere voluntar a noastr ndreptat mpotriva noastr . Alexandru Ioan Cuza a secularizat averile m n stirilor nchinate celor de la muntele Athos, deci unor ter i extreni rii, a a cum afl m din scrierile istoricului A.D. Xenopol, deci nu exist nici o obliga ie a statului s finan eze o institu ie anacronistic :

A.D. Xenopol Domnia lui Cuza Vod Vol.I , CAP. VIII. AI doile minister Cogalniceanu Secularizarea , pagina 291:

Nu vom atinge de c t mprejur rile care au condus la redob ndirea averilor, ajunse n st p nirea c lug rilor str ini, ating nd chestiunea nchin rei m n stirilor p n ntene c tre acele din R s rit, numai ntru c t va fi de nevoie, spre a n alege m sura seculariz rei nsu i.

Din aceste motive i multe altele, deoarece sunte i i reprezentantul meu n Parlamentul Rom niei, v cer ca s vota i pentru proiectul de lege ini iat de domnul Prigoan n ceea ce prive te t ierea finan rii personalui clerical de c tre stat i c t i a altor legi care ar putea duce la eliminarea privilegiilor pe care le au cultele, n condi iile n care singurul motiv real i corect pentru care o entitate ar putea beneficia de scutiri de taxe sau privilegii fiscale sunt doar cele ce nu urm resc interesul financiar i, totodat , au un impact social cuantificabil n mod clar.


Dac dori i, a fi bucuros s v r spund la eventualele ntreb ri sau neclarit i n ceea ce am scris, dac este nevoie.

V mul umesc anticipat!

L-am trimis joi, nc n-am primit r spuns de nici un fel. Pasul doi e s sun. M car s nnebuneasc dac tot sunt nesim i i. A a c , pute i afla de ce colegiu apar ine i i apoi pute i identifica pe cel/cea ce v reprezint n Parlament. Scrie i-le, suna i-i, a venit momentul m car s se enerveze, dac nu s - i fac m car o poleial de datorie.

...awesome. OK, I'm writing this while I'm still in USA, but there are so many things to say about these weeks that I can't write them in only one blog post. And, still, this one will be quite long as it will talk about hacking, running and sightseeing...:) Let's start about hacking: after all, this is the first reason for being there in US, isn't it? I cam to DebConf with a very long TODO list and, for the first time in seven DebConfs, I'm pretty happy with what I achieved from it:

• samba packages
  • I (shortly) discussed with Steve Langasek about samba packages. He will have to talk with upstream about 3.6 that unexpectedly drops symbols in libraries , so that we can upload it in experimental (and probably also offer a lenny backport)
  • We didn't decide yet about the version to have in squeeze. I know, the freeze happened in the meantime, so we should stick with 3.4.8 but I'm more and more convinced that we should have 3.5.4 instead as upstream should stop supporting 3.4 security-wise around June 2011. I think I can convince the Release Team that 3.4-3.5 upgrade is not to be disruptive with the freeze.
  • I hopefully fixed the 3.5.4 packages for lenny which we have in our unofficial repository at http://pkg-samba.alioth.debian.org. I didn't take time to check this properly, though, so feedback will be appreciated.
• Pootle/translate-toolkit/virtaal
  • These are usually maintained by Nicolas Fran ois but he has no time for them. So, I agreed with him that I would release new upstream versions
  • pootle 2.0.5 is now in unstable. I have to work on an RC bug, still
  • translate-toolkit 1.7.0 is now in unstable too
  • virtaal: I began working on new upstream release packaging
  • backporting: I planned to backport translate-toolkit and pootle as there is a strong demand for them for lenny servers but the above mentioned RC bug prevented me to do so
• D-I work
  • I partly reviewed and corrected the D-I l10n documentation
  • I reviewed and activated new debconf templates added by Otavio Salvador and Daniel Baumann to live-installer, then called for their translation
  • Support for locales with "@" in their name in localechooser: I looked at this but I need someone more clever than me in shell scripting to fix that. Until that's done, I deactivated Serbian (Latin), unfortunately.
• Various packaging work
  • New release for console-data (mostly l10n stuff aimed for D-I)
  • Uploaded ttf-dzongkha and ttf-inconsolata to s-p-u to fix two RC bugs in stable
  • Polish tasksel and have Otavio to upload it
  • Checked my own packages against Rhonda's list of RC bugs in stable
• Localization work
  • Pootle upstream French translation completed, for 2.1.0
  • Cleaned out the tracking robot for French l10n in Debian

As one can see, a lot of planned work happened while I still could maintain the usual flow of recurrent work with localization (Smith reviews, l10n NMUs). Some asked me why I didn't propose l10n sessions this year. Indeed, I wasn't feeling I could sustain animating them and I had no clear idea about which topic I could bring to be discussed. Last year, these sessions slightly killed my free time and I wanted to keep some this year for "impromptu" things. I didn't attend many talks, sorry for the speakers. The most I attended were during Debian Day, which I found highlyinteresting and motivating, just like Eben Moglen's talk. Marga's talk was also one I wanted to attend, though I regreted that things went mostly out of control during the talk (too many comments from the audience to allow Marga pushing her important points). As usual, I invested a big part of my time in "social" activities, the most proeminent being of course the Cheese and Wine party, which turned ut to be a great success. The help of my son Jean-Baptiste and the tremendous support of Michelle Lynn Hall helped a lot, though I still regret that we screwed about accessibility. I also ran a lot..:-)..that may be counted as social activities as I organized several group runs. The one I'm proud of has been participating to a local race, namely the Van Cortland Track Club Summer Series of cross-country running, in Bronx. We went there with no less than 10 DebConf participants and 1 kilt (hey, Luca!). All of us completed the race (that had 170 runners for 5 kilometers) and No l K the even finished 17th scratch and 2nd in his age/gender category. Besides that, we had a great run/sightseeing to Georges Washington Bridge (that links New Jersey and Harlem and offers an unusual view of Manhattan "from behind"). All this with a 17km run. We also ran several times in Central Park, and No l and me happened to go to Coney Island for the Day Trip by doing half of the trip by running (all around Manhattan and over the Broolyn Bridge), for about 20km. Then we "showered" in the Atlantic Ocean....:). At the end of DebConf, I think that I had my record broken with 112km run in 10 days and only one day *without* running. What about sightseeing? Well, this blog post is too long and we reach the end of Interstate-90, close to Albany, so that will be for an upcoming blog post. Aug 25th update: back home, so now I can publish this blog post...

The Debian Women project aims to get more women to participate in Debian, as packagers, bug reporters, technical documentation writers, bug fixers, translators, artists and in any other area that helps the development of Debian. These goals are achieved through IRC tutorials, a mentoring program, a mailing list and an IRC channel.

The Mentoring Program, allows men and women that want to contribute to Debian but aren t sure where or how to start, to get some help with their first steps.

There have been at least 38 women that have contributed in packaging software for Debian, and there are currently 11 female Debian Developers and 1 Debian Maintainer. We d like to raise those numbers to 50 packagers by the end of 2011, and 20 Debian Developers by the end of 2012.

There are some other interesting statistics about the current female participation in Debian.

We are also interested in getting more women to file and fix bugs, translate debconf templates or package descriptions, contribute to the release notes, as well as participate in any other areas of the Debian project. In order to do this, we will be holding some IRC training sessions in the near future, to help people get started. We are currently making the list of subjects and trainers, we ll publish more news about this once the first sessions are scheduled.

For more information you can join the IRC channel #debian-women on irc.oftc.net, or subscribe to the debian-women mailing list. If you are a Spanish speaker, you can also join the IRC channel #debian-mujeres on irc.oftc.net.

Contributed by: Margarita Manterola

Many team maintained packages in Debian are maintained in Subversion which makes a lot of sense if people agreed on a common workflow. If you want to use git to work on these packages you can still do so with a bit of configuration without changing anything for the other team members. Let's take system-config-printer as example. git-svn can be used to checkout the svn repository:

git svn clone svn+ssh://svn.debian.org/svn/pkg-gnome/ -T packages/unstable/system-config-printer -t tags/system-config-printer system-config-printer

Since the pkg-gnome team keeps all the packages in one huge SVN repository and splits the directories by release first and then by package the above command uses -T to point git-svn to system-config-printer's trunk and -t to point it to the tags directory. In simpler repositories where trunk, branches and tags are subdirectories of the same base directory using --stdlayout instead is enough. Since in SVN based packaging the upstream sources usually aren't kept in the repository git-buildpackage needs to know where to find them and how to combine things in the build-directory:

cd system-config-printer
cat <<EOF >.git/gbp.conf
[git-buildpackage]
# Build in a separate build-area
export-dir = ../build-area/
# Look for tarballs in ../tarballs
tarball-dir = ../tarballs/
# Overlay the upstream sources on top of it
overlay = True
# Don't use pristine-tar
pristine-tar = False
# Compression type of the tarball
compression = bzip2

Like with svn-buildpackage the orig-tarball is expected to be found in ../tarballs where you should put it now e.g. using the get-orig-source target of debian/rules (yes, git-buildpackage should support this implicitly). You can then work on the package as usual using all the nifty git commands like git-rebase, etc. and build the package (in this case using git-pbuilder):

git-buildpackage --git-pbuilder

or if you don't want to export the current branch's HEAD of your git repository but your working copy (which might contain uncommitted changes) to the build-area instead use:

git-buildpackage --git-pbuilder --git-export=WC

The built packages can then be found in ../build-area. Once the package is ready pushing the changes into the SVN remote repository is as simple as:

git svn dcommit
git svn tag -m"Tagging system-config-printer (1.2.3-0.2)" 1.2.3-0.2

The last command appropriately tags the new version. This saves a bit of typing. In order to fetch changes others have made use:

git svn rebase

FrOSCon was a blast. I had two booths of my own MirBSD and FreeWRT as well as shares of Debian and Grml. Well, MirBSD was run by Benny and gecko2 because I just didn t have any time for it, despite XTaran s help with the FreeWRT booth. All I did was the initial setup of both booths, while at the same time answering about three questions regarding FreeWRT in parallel. Wow. What a little small, open hardware can do to you. XTaran and I had fun and we ll do FreeWRT booths again; I managed to flash my two FON2100 devices ( La Fonera the FON2200 can use the same image, says nbd of OpenWrt) and will fix the port s remaining few bugs I found; XTaran will try to push the WL-500gPv2 development. The social part was nice as well, although I think the greek restaurant in the city will not be visited by me again. Anyway, if you didn t attend FrOSCon, your own fault Since the BitTorrent tracker used by MirOS is down, here s the link to the [updated 2010-08-28] current (FrOSCon 2010 Edition) snapshot s torrent, Triforce as usual. We ll probably rewrite torrent files for all our ISOs and publish them on the MirBSD website. I m currently considering OpenBitTorrent plus one or two DHT seed nodes with no statistics. Maybe with webseed. (Need to update the libtorrent/rtorrent MirPorts first, though ) Other options would be different trackers or running one of our own. I will announce the outcome as news entry, once done. On the plus side, the review process of mksh(1) in Android continues, and I fixed the realpath builtin to behave even more POSIX-ish.

I got this in my Debian mailbox the other day (it s an invitation to Facebook, in French):

Bonjour Jonathan,

Je vous ai invit rejoindre Facebook r cemment et je voulais vous rappeler que d s que vous serez enregistr , vous pourrez vous connecter [...]

Poete Bellon a invit xxx@xxxx rejoindre Facebook. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe.

<script type="text/javascript"> var flattr_wp_ver = '0.9.12'; var flattr_uid = '32970'; var flattr_url = 'http://www.jwiltshire.org.uk/content'; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tag = 'blog,wordpress,rss,feed'; var flattr_btn = 'large'; var flattr_tle = 'jwiltshire.org.uk'; var flattr_dsc = 'The public face of jwiltshire'; </script> <script src="https://api.flattr.com/js/0.5.0/load.js?mode=auto" type="text/javascript"></script>

Well, FrOSCon is over and it s time to sum up the event a bit. First of all: it was great! But it was also hot (I heard the air-condition is off during week-ends ) and busy. And still, it was great! :) Why? Mostly because of the people of course! It was esp nice to meet Rhonda in person (almost all other people [except the grml ones] in the Debian-and-Friends corner were the usual suspects who you see at every (big) FOSS/Linux event). I had some nice chats with Enrico (about Geany and Xfce) and Leo (about bley), besides of the usual when will Squeeze be released? and how does X work in Debian? with random people. When there are a lot of people, a key signing party isn t too far away. Thanks formorer for the orga! You still owe me a sig from FrOSCon 2008 ;) And if someone wonders why he/she got a sign-mail from me even when he/she wasn t at the FrOSCon KSP: I used the fact that I have to sign a lot of keys to sign even more (from the OpenRheinRuhr 2009 KSP and the BSP in M nchengladbach at the beginning of this year [yes tg, I even signed yours, hope you liked the MIME]). As usual I missed almost every talk I wanted to hear and end up with just one (the one about RegEx), which sadly wasn t good at all. I guess that s all I have to say about FrOSCon. Oh wait, no, there was a questionnaire which included the question whether I ll visit future FrOSCons. Of course! Hope to see ya all at MRMCD, OpenRheinRuhr, 27C3 etc So Long, and Thanks for All the Frogs!

Just echoing what happens in Planet Debian for people who follow my blog (or any other planet where it is syndicated) and is interested in DebConf processes I'm specially thinking about people interested in preparing a bid for hosting a future DebConf, as well as people organizing hacking conferences who are interesed in understanding how DebConf works: Richard Darst, a.k.a. our very invaluable MrBeige, started a series of posts describing various processes of DebConf organization. He explicitly asked me for comments while this series was still in planning/wiki stage, but I failed miserably at doing so ;-) So at least I'll publicize his work, linking from here:

1. DebConf and Debian: Introductory message, basically outlining (Richard's view on) the relation between Debian and DebConf. This is not yet a clear thing It seems we are converging on the fact that DebConf *is* part of Debian, but there are several things to clear before it is viewed as a done deal.
2. Timeline of a DebConf: Running a DebConf as a local team is not (just) becoming crazy for two weeks, leaving life behind ans working hard for having your friends and peers in your hometown. It is an interesting full two year process, with different phases and aspects for the work. Richard has been involved as an organizer for the last two years, and he summarizes the main periods here.
3. What is the DebConf team?: We talk about the localteam and the globalteam as if those terms make any sense. Then again, we have had people as part of localteam who live in different countries... What does this mean? What are the tasks of the teams? How do you join? What kind of work is expected from you? What is the real difference between the teams, if there is any?
4. The DebConf selection process: How does the next year's venue selected? How is this "contest" held? When do you have to submit your proposal? How is it ranked/judged/decided? As I have told several people, the first document you should check is always the location checklist (also linked from Richard's text), but having this timeline will surely help you know what to expect.

I don't know if MrBeige is planning further parts for this series; if the past four were interesting, you should check on his weblog.

Another day, another story about #ukgov cuts and today it s the turn of libraries. When I turned on the TV at breakfast, they were discussing BBC: A novel idea: Take a look inside the library pub. There s also a discussion on the terrible BBC speak your branes site. People have quickly pointed out that the library pub is quite small (a few hundred books) and couldn t run without the support of the council library service (according to FranksCasket and msarahwickham), so it s not an obvious cost-cutter. I guess the most endangered are the mobile libraries, as the books could be delivered on request by parcel or courier services without skilled staff. North Somerset has already consulted on cutting the number of stops (the results will be published by 06 Sep 2010) so that might be happen anyway. The reply which made me smile the most was Have a better plan: put a pub in the library which, of course, the visionaries in Norwich have already done. Well, a cafe-bar in the same building as the Millennium Library, at least. Not quite Real Ale, but it s a start. Personally, I feel library IT should be in line for cuts before library branches (I really don t enjoy using the local council library catalogue and the Windows-based PC kiosk control system feels like an expensive nasty experience to me), but it s all connected. More flexible library IT like Koha, with its web-based user interfaces, common hardware and possibility of distributed cooperative support, could probably support microbranches better than some of the legacy systems.

Selecting a DebConf location hard, and can certainly get intense at times. This is an area where the DebConf team and the Debian project can work to improve our processes. There is a wiki page to collect our thoughts in preparation for a discussion later, as planned during the DebConf&Debian BOF.
First off, there is a time at DebConfN-2 for interested localteams to describe their rough plans. These are videoed, and you can view the events online if you would like: for dc11 at dc9, for dc12 at dc10 .There has been a nominal deadline of December 31, 20XX-2 for submitting a bid (not finalizing), but this has been bent in the past.While teams are preparing their bids, they should look at the location checklist. This summarize what past organizers know to look for in a location. There are questions sorted by category and priority.To organize their information so that people can understand, teams prepare bid documents on the wiki (DC10, DC11, here are the winning bid documents: DC10-New York City, DC11-Banja Luka). These start off by just answering all of the questions in the location checklist, but then get a lot of work to make the pages clear and complete. Anyone can browse the pages and ask questions of the teams anytime.There are several mini-meetings where teams describe their progress, and organizers and other interested people can ask questions. In these meetings, the channel is not moderated. Questions tend to be about the location checklist criteria related things.In February/March, there is a big selection meeting. This is the only DebConf meeting where the channel is moderated and only voiced people can speak. The voiced people historically are two moderators who keep things moving, two other past DebConf organizers to ask questions and relay questions from the audience discussion channel. (These facilitators have been self-selected in the past, usually in the minutes leading up to the meeting.) Then, there are two people per location whom are voiced. There is a audience channel for everyone else to discuss, and the moderators/helpers will look there for questions and relay them to the main channel. There have been unvoiced Q&A periods and periods which are designated for relaying questions from the discussion channel.These meetings are logged (dc10 selection, dc11 selection)Teams are rated based on the priority list. There has been a simple point list the last two years, -1 to +1 for each point on that list. For each item, there are debates on how many points each location should get. Points are added up, and a result appears. In the past, this has been a simple arithmetic sum, so all items are weighted the same (despite nominally having different weights). In the case of a tie or close call, there is more discussion. For DC10, there was a tie, and NYC won after opening the meeting to the audience and getting their opinions. I didn't pay enough attention to the DC11 selection process to be able to say how that close call was resolved.While this isn't really part of the selection process, local teams can give presentations at DebConfN-1 about their location and encourage attendance: dc10 at dc9, dc11 at dc10
So, there it is. Overall, there is a lot of openness in the process, but the exact rating schemes in the decision meeting could use discussion. The criteria are established, but can be refined each year based on what we learn.If you would like to comment on how to improve this in the future, please use the selection process wiki page (first person create it). We can follow up with a list discussion after our ideas have been fleshed out.Tags: debconf

In a previous post I mentioned split debugging info. One addendum to this is how symbols are handled. Symbols are separate to debugging info (i.e. the stuff about variable names, types, etc you get when -g is turned on), but necessary for a good debugging experience. You have a choice, however, of where you leave the symbol files. You can leave them in your shipping binary/library so that users who don't have the full debugging info available will still get a back-trace that at least has function names. The cost is slightly larger files for everyone, even if the symbols are never used. This appears to be what Redhat does with it's system libraries, for example. The other option is to keep the symbols in the .debug files along-side the debug info. This results in smaller libraries, but really requires you to have the debug info files available to have workable debugging. This appears to be what Debian does. So, how do you go about this? Well, it depends on what tools you're using. For binutils strip, there is some asynchronicity between the --strip-debug and --only-keep-debug options. --strip-debug will keep the symbol table in the binary, and --only-keep-debug will also keep the symbol table. Of course, you can then strip (with no arguments) the final binary to get rid of the symbol table; but other than manually pulling out the .symtab section with objcopy I'm not aware of any way to remove it from the debug info file. Constrast with elfutils; more commonly used on Redhat based system I think. eu-strip's --strip-debug does the same thing; leaves the symtab section in the binary. However, it also has a -f option, which puts any removed sections during the strip into a separate file. Therefore, you can create any combination you wish; eu-strip -f results in an empty binary with symbols and debug data in the .debug file, while eu-strip -g -f results in debug data only in the .debug file, and symbol data retained in the binary. The only thing to be careful about is using eu-strip -g -f and then further stripping the binary, and consequently destroying the symbol table, but retaining debug info. This can lead to some strange things in backtraces: Note one difference between strip and eu-strip is that binutils strip will leave the .gnu_debuglink section in, while eu-strip will not:

This is my third video of me while doing my tattoo, hopefully it won t get removed again due to licensing, because I tried to provide all the necessary copyright. This is its first time showing up on Planet Debian, so I might even hear some criticism? If any please don t be too harsh on me I d like to have this one on as some kind of personal zeitgeist moment if anything, and I m definitely not making any other versions of this video. I have why I did it , and all the other things written in my previous posts related to this video. Enjoy <object height="324" width="400"><param name="movie" value="http://www.youtube.com/v/edKUKCTOpo0&amp;hl=en&amp;fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="344" src="http://www.youtube.com/v/edKUKCTOpo0&amp;hl=en&amp;fs=1" type="application/x-shockwave-flash" width="425"></embed></object> Related posts: Linux/Unix sex
Chimaira / Linux sex v2.0

Now that I've mentioned the general timeline of a DebConf, let's talk about the "global team", "local team", and decision processes.Who is the "global team"? Basically, it is the active people on the debconf-team IRC channel and mailing list. Anyone can contribute, but we know who is who. Those with the most moral authority tend to be those who have organized a past DebConf or been involved for many years, and their opinions always have a high weight. Many of them are still around.So then how are decisions made? It's a combination of consensus-based and "whoever want to, do it". We discuss ideas based on what experienced people have seen work/not work, what new people want to try, and perhaps most importantly, who can make it happen. (this is where you fit in). There aren't necessarily leaders picked beforehand, instead leaders develop themselves. Overall, this is similar to any other team in Debian.There aren't formal gatekeepers who can veto anything, but if someone sees a problem, they should speak up and get critical mass of people to fix things. Those who hold the money (SPI, FFIS, the DPL) of course will monitor our processes and would intervene if someone started going off course.Typical global team tasks are fundraising, travel sponsorship selection, talks, registration.The local team starts out as the winning bid team. They started out figuring out local logistics for their venue, and up until arrival, they are the ones who are handling the local tasks (venue, food, accommodation, entertainment, day trip, Debian Day outreach). They should keep the global team updated on their status and what they are arranging, so that the experienced ones on the global team can give feedback. Global people will, of course, get involved here where they see fit and can help.The local team shouldn't exist in isolation though, anyone local is highly encouraged to get involved in "global team" tasks. The more coordination and bi-directional help we have, the better.It isn't the job of the local team to put on all of DebConf themselves. They aren't selected and left with free reign, they should integrate with and understand the history of DebConf, and then work on whatever improvements they want, whether they are local or global.
So in short, there are the names "global team" and "local team", but really, it's all one big Debian team. Those who are interested work and make things happen through a consensus-driven process. Things aren't always perfect: we have conflict, disorganization, leadership turn-over, lack of volunteers, lack of time, all the usual things that happen in volunteer organizations. I think most people want to work towards this ideal, and we hope that this series of posts will help us to improve. Most importantly, when you see something you'd like to work on, you can get involved.Tags: debconf

Recently I blogged a serious complain about Facebook marketing practices.
I must note, that, while writing this, this is still a standing fact.
And it somehow leads me to the question why I use facebook (and similar portals like Xing or Meinvz at all) at all.

I would say that I'm a person, who values security. Probably I need to, because my job involves security aspects, even if its only to protect data.
Additionally I value privacy. I would never go onto a toilet in a glass case, where everybody could watch me doing my business.
The idea to keep the door to my flat open all the time would trigger all alarm bells inside of me.
But on the other hand I have a blog on which I write about technical topics, and personal topics. Like the death of my grandma or how my neighbours disturb me. And I use Facebook. And MeinVZ.

I'm well aware of how this makes it easier to trace me. How this could be used against me, if I happen to search for a job. Aware of the everlasting memorization of the internet who will keep this.. eventually forever.
And I have friends who have a serious antipathy against this and probably would never use such a portal at all.
So why do I use it?

That I started using that portals were some kind of peer pressure. I'm a person who likes beeing "thereby" and I like beeing present. Many of my friends were already using those portals and so I followed an invitation to use it, too. But I did think about several points:

• Could this affect my career plans? The answer is yes. But it can have positive and negative aspects. I'm active in the Open Source movement. Therefore I am already present in the world wide web. As an IT-guy that s not the worst that can happen. If you are interested in working for one of those big prominent companies and if its only peripheral, being present in the web is a good thing, because there is a chance of being perceived. On the other hand I'm a somehow crazy person in my private life. I like doing party and some people would probably call me freaky. Most likely this could show in such a portal.. or in my blog. If it affects my carrier plans in a negative manner, well there are several things to consider. For example if I really want to work for a company, which decides to decline me just because I have a real life next to the job. I probably don't.
• Can these portals store information about me that I don't want to be public?Yes and no. Its a fact that these portals are designed to collect as many information about as many persons as possible. But they also give you some tools to control what is known about you. If you don't want to show nude photos, then don't post them. If you don't want to be seen as a person always drinking too much then don't write about it and don't show photos of you being drunk. And if others post such stuff about you: Use the tools to get it removed and eventually ask yourself if the persons doing it are really friends.
• Are the companies behind those portals evil?Hard question. In many ways they are acting in a way that makes them look evil. Like that aggresive advertising, I wrote about earlier. But on the other hand they are serving a need of people who like to keep in touch and they are really just doing business. What they do is required for their business. They collect data because they need it to make their free portals financable (e.g. by showing targeted advertising). If you want you can still think of them as the great evil but you are not really being forced to use their service.
• Is every facebook friend a friend?Uhm.. no. Its so easy to request friendship on a social network platform that people collect "friends" on them as other people collect knickknack.
  Personally I consider my friend list on these portals to be a collection of people I know. Some of them are friends but not all of them.
• Do I really need those social networking platforms?And here is the most important question. The answer is No.
  No one does. If you really want to keep in touch with persons you like you can always do. By telephone, by writing a letter, by visiting them etc.
  But its convenient. An example:
  I have friends in different parts of the world. In the United States for example. Or people living in my country (but in a distance) or people travelling around a lot. I can keep in touch with them via email or instant messenging etc. but those social networks give me the chance to keep up-to-date with their lifes (in which I'm really interested if they are friends) without direct contact the whole time (for which we may not always find time and occasion). Its easy, its fast.

I came to the conclusion that there are pros and cons for and against using these services. And I found that I can live with the cons due to the convenience they bring to me. And that I could always stop using them.

However: That does not mean that I have to "Eat or die" what they serve.

Oh and on a side note: I found "Facebook, Br ste und die Currywurst" to be an interesting article about the topic. Its a recommended reading, although only for the people who understand German.

Since I started using Linux I've used several window managers. I felt used to blackbox and fluxbox and eventually used enlightenment and some others in the past, but nowadays its been a while since I became the user of an Desktop Environment. I'm using GNOME because it provides what I need and I don't need to spend an hour to configure it before it suits my needs. After all I'm lazy.
With respect to the fact that I'm quiet satisfied with GNOME, there is one feature I were always missing.
Because I spend much time with tiling and arranging windows on my desktops I noticed that I could need
a tiling feature. Something which was already a feature back in Windows 3.11.
GNOME/metacity does not have this features and given that a wishlist bug about this is open since almost 7 years
its unlikley that this will ever change. There are separate tools, which I recently learned about that can assist me with this. For example the perl script 'wumwum'. But this seems to be the wrong solution to a real problem. Additional wumwum does not work properly with metacity and so I'd need to another WM anyway, which lead to the point where I started thinking about integrating a true tiling wm into GNOME... once again.

First, I looked into awesome, which is a window manager I used some time ago.
But documentation about configuring it is basically an API documentation, with no obvious entry point.
It seems to be the best to study the whole API just to set some simple settings (e.g. a padding for the GNOME panel and some always-floating applications). I even thought about learning LUA, because it seems like a language which is quick and easy to learn, but honestly if I need to study a programming language and a whole API documentation just to configure a window manager then IMHO there is something conceptionally wrong with that piece of software.
After all I came to Xmonad. This window manager is using Haskell and I fear I need to learn this language as well if I want to configure weird things. But the wanted scenario is well documented and documentation for more common configuration settings exists all over the place so that I don't really feel inclined to learn more then needed.
Remember? I'm lazy.

Now I'm feeling quiet happy with this combination. It didn't cost me much time to get used to the most basic keyboard shortcuts or setting the whole thing up. GNOME and Xmonad work together like a dream team. I feel more productive now. As an additional plus I reinstalled the vimperator firefox plugin, because with my new desktop environment I more often use the keyboard for ordinary tasks like switching between apps or desks and I felt beeing able to quickly operate firefox with the keyboard, too, would be a plus. Well, it is.