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?

1. What is special about the socket, connect, bind, accept, system calls?
2. How does the errno value get from the kernel to applications?
3. Some system calls return a number of times different of 1 in some cases. Which ones? (Put differently: enter a syscall once, exit more or less than once. Which ones can do that?)

(Thanks MG!)

It has come up on the Planet recently, as well as the gnupg users mailing list: users need to refresh keys that they use to get updated information on revocations and key expiration. And there are plenty of examples of simple additions to ones crontab to set up a key refresh. Of course, with me, things are rarely that simple. Firstly, I have my GNUPGHOME set to a non standard location; and, secondly, I like having my Gnus tell me about signatures on mails to the Debian mailing lists, so I periodically sync debian-keyring.gpg into my GNUPGHOME. I add this as an additional keyring in my gpg.conf file, so that in normal operations gnus has ready access to the keys; but I do not care to refresh all the keys in debian-keyring. I also prefer to trust and update keys in my keyring, so the commands grow a little complex. Also, I want to get keys for any signatures folks have kindly added to my key and uploaded to the key server (not everyone uses caff), so just refresh-keys does not serve. Linebreaks added for readability.

# refresh my keys
# Note how I have to dance around keyring specification
45      4    *  * 4   (/usr/bin/gpg2 --homedir ~/.sec --refresh-keys
    $(/usr/bin/gpg2 --options /dev/null --homedir ~/.sec
      --no-default-keyring --keyring pubring.gpg --with-colons
        --fixed-list-mode --list-keys   egrep '^pub'   cut -f5 -d:  
            sort -u) >/dev/null 2>&1)
# Get keys for new sigs on my keys (get my key by default, in case 
# there are no unknown user IDs [do not want to re-get all keys])
44      4    *  * 5  (/usr/bin/gpg2 --homedir ~/.sec --recv-keys
    0xC5779A1C $(/usr/bin/gpg2  --options  /dev/null --homedir ~/.sec
       --no-default-keyring --keyring pubring.gpg --with-colons
         --fixed-list-mode --list-sigs 0xC5779A1C   egrep '^sig:'  
            grep 'User ID not found'   cut -f5 -d:   sort -u) >/dev/null 2>&1)

DebConf continued until Saturday, but Friday the 6th was my last day as I left New York that evening. I m a bit late in getting this summary written up. Making Debian Rule, Again (Margarita Manterola) Marga took a bold look at the challenges facing Debian today. She says that Debian is perceived to be less innovative, out of date, difficult to use, and shrinking as a community. She called out Ubuntu as the elephant in the room , which is taking away from Debian. She insists that she is not opposed to Ubuntu, but that nonetheless Ubuntu is to some extent displacing Debian as a focal point for newcomers (both users and contributors). Marga points out that Debian s work is still meaningful, because many users still prefer Debian, and it is perceived to be of higher quality, as well as being the essential basis for derivatives like Ubuntu. She conducted a survey (about 40 respondents) to ask what Debian s problems are, and grouped them into categories like motivation and communication (tied for the #1 spot), visibility (#3, meaning public awareness and perception of Debian) and so on. She went on to make some suggestions about how to address these problems. On the topic of communication, she proposed changing Debian culture by:

• Spreading positive messages, celebrating success
• Thanking contributors for their work
• Avoiding escalation by staying away from email and IRC when angry
• Treating every contributor with respect, no matter how wrong they are

This stimulated a lot of discussion, and most of the remaining time was taken up by comments from the audience. The video has been published, and offers a lot of insight into how Debian developers perceive each other and the project. She also made suggestions for the problems of visibility and motivation. These are crucial issues for Debian devotees to be considering, and I applaud Marga for her fortitude in drawing attention to them. This session was one of the highlights of this DebConf, and catalyzed a lot of discussion of vital issues in Debian. Following her talk, there was a further discussion in the hallway which included many of the people who commented during the session, mostly about how to deal with problematic behavior in Debian. Although I agreed with much of what was said, I found it a bit painful to watch, because (ironically) this discussion displayed several of the characteristic people problems that Debian seems to have:

• Many people had opinions, and although they agreed on many things, agreement was rarely expressed openly. Sometimes it helps a lot to simply say I agree with you and leave it at that. Lending support, rather than adding a new voice, helps to build consensus.
• People waited for their turn to talk rather than listening to the person speaking, so the discussion didn t build momentum toward a conclusion.
• The conversation got louder and more dense over time, making it difficult to enter. It wasn t argumentative; it was simply loud and fast-paced. This drowned out people who weren t as vocal or willful.
• Even where agreement was apparent, there was often no clear action agreed. No one had responsibility for changing the situation.

These same patterns are easily observed on Debian mailing lists for the past 10+ years. I exhibited them myself when I was active on these lists. This kind of cultural norm, once established, is difficult to intentionally change. It requires a fairly radical approach, which will inevitably mean coping with loss. In the case of a community, this can mean losing volunteer contributors cannot let go of this norm, and that is an emotionally difficult experience. However, it is nonetheless necessary to move forward, and I think that Debian as a community is capable of moving beyond it. Juxtaposition Given my history with both Debian and Ubuntu, I couldn t help but take a comparative view of some of this. These problems are not new to Debian, and indeed they inspired many of the key decisions we made when founding the Ubuntu project in 2004. We particularly wanted to foster a culture which was supportive, encouraging and welcoming to potential contributors, something Debian has struggled with. Ubuntu has been, quite deliberately, an experiment in finding solutions to problems such as these. We ve learned a lot from this experiment, and I ve always hoped that this would help to find solutions for Debian as well. Unfortunately, I don t think Debian has benefited from these Ubuntu experiments as much as we might have hoped. A common example of this is the Ubuntu Code of Conduct. The idea of a project code of conduct predates Ubuntu, of course, but we did help to popularize it within the free software community, and this is now a common (and successful) practice used by many free software projects. The idea of behavioral standards for Debian has been raised in various forms for years now, but never seems to get traction. Hearing people talk about it at DebConf, it sometimes seemed almost as if the idea was dismissed out of hand because it was too closely associated with Ubuntu. I learned from Marga s talk that Enrico Zini drafted a set of Debian Community Guidelines over four years ago in 2006. It is perhaps a bit longand structured, but is basically excellent. Enrico has done a great job of compiling best practices for participating in an open community project. However, his document seems to be purely informational, without any official standing in the Debian project, and Debian community leaders have hesitated to make it something more. Perhaps Ubuntu leaders (myself included) could have done more to nurture these ideas in Debian. At least in my experience, though, I found that my affiliation with Ubuntu almost immediately labeled me an outsider in Debian, even when I was still active as a developer, and this made it very difficult to make such proposals. Perhaps this is because Debian is proud of its independence, and does not want to be unduly influenced by external forces. Perhaps the initial growing pains of the Debian/Ubuntu relationship got in the way. Nonetheless, I think that Debian could be stronger by learning from Ubuntu, just as Ubuntu has learned so much from Debian. Closing thoughts I enjoyed this DebConf very much. This was the first DebConf to be hosted in the US, and there were many familiar faces that I hadn t seen in some time. Columbia University offered an excellent location, and the presentation content was thought-provoking. There seemed to be a positive attitude toward Ubuntu, which was very good to see. Although there is always more work to do, it feels like we re making progress in improving cooperation between Debian and Ubuntu. I was a bit sad to leave, but was fortunate enough to meet up with Debian folk during my subsequent stay in the Boston area as well. It felt good to reconnect with this circle of friends again, and I hope to see you again soon. Looking forward to next year s DebConf in Bosnia

MJ Ray has said that he needs occasionally to concatenate MP3 files and he wants those files to be free of junk in their middle. There are some nice things to say about this problem:

• Just using cat with MP3 files work because those files are headerless : the metadata in form of ID3v 1,2 tags is an addendum to the format. MP3 is also a format that can be conveniently used without containers/wrappers.That is not the case with AAC files, in general: AAC files that are not inside a container (e.g., Matroska or MPEG 4) are usually useless, unless you know (and can inform) some properties of them to th software that you are using. This is especially the case with AAC files that were compressed with some advanced things like spectral band replication (SBR).
• The tags for MP3 files (at least those in ID3v2) are supposed to be unsynchronized , so as to not be interpreted as audio data. What this means is that some byte sequences (a byte 255 followed by a byte with value at least 224) that are allowed as audio to say hey, I am a marker, process the
  next chunk of data, now have to be escaped if they are present in tags (so that you don t listen to garbage in the middle of a file i.e., you don t play the tag).

Related to this second point, the MPEG standards have a guideline that, if some data is not known by a decoder, for resilience purposes, it should be ignored. This obviously allows some newer features to be
implemented in a backwards-compatible manner and is nice. In other words, decoders should just skip those data and be done with it. Also regarding the second point, apparently, some versions of popular music players/manipulators have problems with unsynchronized data. There are many tools that one can use for removing unwanted, unsynchronized data from an MP3 file. For instance, you can use mp3diags, which is already conveniently packaged in Debian s repository. It is a recommended program for those purposes, indeed. There is another tool that serves that purpose as a side effect: mp3packer. Its purpose is, naively speaking, to losslessly shuffle the data inside an MP3 file so that it can be stored with fewer bits (saving more space for portable players, for instance). In the process of regenerating a new MP3 file, it discards some junk data and solves the original problem. Despite not being part of our repository yet, it is already packaged and
even a RFP bug exists.

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.

There s some hype in the Ruby community about RVM (Ruby Version Manager). It s a tool that allows to switch between Ruby versions on the same system (much like what the alternatives system provides for Java on Debian, except that RVM does it either system-wide or per-user). However, when you look at it, RVM looks quite scary. The recommended installation instruction is:
bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ).
That script doesn t use set -e, and actually does a git clone behind the scenes. Without first checking that git is installed. But if you don t have git installed, it s not a problem: there s another script later on the page that downloads and compiles it for you. After installing RVM itself, you need to install rubies (different ruby implementations). Use rvm install ree,1.9.2-head,jruby. That will automatically download and build the various versions in your homedir. It s interesting to note the the compilation messages were probably too scary, and are not displayed. But how does it handle the switch between different versions ? First, you need to add some magic to your .bashrc:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
or, for a system-wide install of rvm:
[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm"
And then, you can select your ruby implementation using rvm --default 1.9.2, for example. That works by redefining $PATH:
# echo $PATH
/usr/local/rvm/gems/ruby-1.9.2-p0/bin:/usr/local/rvm/gems/ruby-1.9.2-p0@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p0/bin:/usr/local/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 Of course, that s quite fragile: if you are in one of the cases where bash doesn t read .bashrc, or if you happen to be using dash, you lose. Looking at the code of RVM itself, it is also very fragile: it s pure bash, without any error handling. During my test (in a chroot), I often got error messages about missing commands that were apparently ignored. The installer insists on using colors, and spews lots of error messages if executed without a controlling tty. There are also some interesting code snippets like perl -e 'sleep 0.5'. So, where do we go from here? Well, obviously, with my Debian hat, I m not going to advocate a solution that makes everything possible to avoid the distribution s packaging system, and I don t see RVM being packaged in Debian anytime soon.
In Debian, we already provide co-installability of Ruby 1.8 and 1.9.2, and users are free to choose which one to use on a per-script basis, by running them with version-suffixed ruby executables. The ruby executable itself still points to 1.8, as it s clearly too early to make 1.9.2 the default. Many Ruby libraries are provided for both 1.8 and 1.9.2, and we plan to discuss changes in the packaging system to be able to make it easier to provide packages for both versions. There s also recent work on packaging JRuby, but it s quite hard as it requires removing all the non-free or undistributable parts, and packaging them separately.

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

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

Now talk about good news.

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.

Yesterday I handed out how to vote (HTV) cards for the Australian Greens. The experience was very different to the one I had when I handed out cards for the Greens in the Victorian state election in 2006 [1]. The Labor party (ALP) hadn t spread any gross lies about the Greens and there were no representatives from the insane parties (Family First and Citizens Electoral Council/Commission (CEC)). So we didn t have any arguments among the people handing out the HTV cards. The atmosphere among the volunteers that were present was a good match for some ideals of a sporting contest. Everyone wanted their own team to win but acted in a sporting manner. When no voters were around we had some friendly conversations. One thing that was interesting to note was the significant number of families where the parents in their 40s deliberately snubbed me while their children in the 18-22 age range took the Greens cards. It seemed that for families with adult children there were two likely voting patterns, one was children voting Green and parents not liking it, and the other was when the entire family voted informal (when someone refuses all offers of HTV cards it s a safe bet that they will cast an informal vote). In Australia submitting a vote card is mandatory but making it legible and formal is optional. The last report I heard suggested that about 5% of the total votes were informal. This seems to be strong evidence showing that civics lessons are needed in high school. Also there were a disturbing number of people who stated that they didn t know which party to vote for when they were collecting the HTV cards. A HTV card has one or two sentences about the party and there are almost no requirements for truth in such statements. Anyone who votes according to such brief summaries of the parties is quiet unlikely to end up casting a vote that gives the result that they desire. The result of the election is a significant swing to the Greens, more senators and the first Green MP! For the lower house it seems that Labor will have great difficulty in forming government even when in a coalition with the Greens and some independents. It seems unlikely that the Liberal party could ever make a deal with the Greens, the Liberal position on almost every significant issue contradicts that of the Green policy, but there is a chance of a Liberal coalition with independent MPs. In any case it seems that the Greens will have the balance of power in the senate so the excesses of the Howard government can t be repeated. If you like the nail-biting drama of watching several columns of figures slowly changing over the course of several days then you would love watching the analysis of this election! Whatever coalition government is created is not likely to be stable and we can probably expect another election in a year or two.

• [1] http://etbe.coker.com.au/2006/11/26/supporting-an-electrion-campaign/

DebConf10 ended 2 weeks ago, I m back in Bosnia and I needed some time to recalculate everything that happened to me in last month This was my third time in NYC, and NYC as a city never left me empty handed, in every possible sense! And am seriously considering option of moving back one day, whether to get my Masters/phD or just do work we ll see what future holds for me DebConf10 I was in organization team for DebConf10, but if you put me aside, what s particularly interesting is that there was a total number of 7 Bosnians on DebConf10, two of which were government officials. I must note this wasn t our complete team, and what s most important of all is that they all pretty much volunteered as much as they could, of course, besides good will to help Debian, but also to at least somehow prepare themselves for organization of DebConf11. It s also worth noting that this was their first DebConf, and I as a leader of the team must say I m proud on how well they performed. I m sure by being highly active in volunteering they have learned as much as they could when it comes to how it s done and were able to see good and bad sides of DebConf10 organization team. Of course, I d also like to thank DebConf10 team for their superb work, perfect Venue selection, their hospitality and being incredibly friendly and helpful to all of us. As I said in one of my lectures, it s kinda unwritten rule that every next DebConf has to top the previous one, and that being said it s going to be almost impossible to compete with this year bid, but being Bosnians we re up for the challenge My DebConf10 Pictures: Semi-private album FaceBook public link (no registration required) DebConf11 DebConf10 was busy period for all of us, but I don t want to start complaining since even though we ve done enormous amounts of work so far, the real challenge lays ahead of us. With DebConf10 behind us, the thing we should process now is it s our turn now, we re next Before anything, I d like to thank Government of Republika Srpska for their full financial support, which was one of the preconditions to even get this bid. With their full support + sponsors, we ll be able to get great amount for sponsorships, for you to come to Banja Luka from the most remote places, and also in case you need visa for them to help you in getting one. Government support is just too precious in any way you want to take it. We would also like to invite you to DebConf11 in Bosnia (Banja Luka) next summer, we also invite all of you to our communication channels (mailing list, irc) since we would really like to get involved as many people as we can. Besides all of you enjoying DebConf11 next year, we would like you to help us in giving directions since we re a young team Besides Debian people, I d like to invite anyone who think he/she could help, or want to get involved, especially individuals/organizations/LUG from whole region! It s also important to stress that in all of our communication means, we do speak English, so please do not hesitate if you have any sort of question/suggestion/whatever. For those interested in next DebConf11, most important page you should follow is our wiki page, where you can find all information and which we keep updated in timely manner: http://wiki.debconf.org/wiki/DebConf11/BanjaLuka Communication/Links Languages we officially support are: English, Bosnian, Serbian and Croatian Mailing list:
http://lists.debconf.net/mailman/listinfo/debconf11-bosnia IRC:
#debconf11-bosnia on irc.debian.org / irc.oftc.net Twitter:
#debconf11 tag
http://twitter.com/absinthesyringe (shameless self promotion ) Facebook:
Official DebConf11 FaceBook group DebConf10 Adnan Hodzic DebConf11 in Bosnia (Introduction and Invitation):
Lecture video high quality (205mb)

See you next year!

People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the screenshots.debian.net service. People can upload screenshots for their favorite applications for others to take a look at. Finally, as convenience feature, they are now added on packages.debian.org. When you click on the screenshot of a package you can see the list of all of the available ones. In the case when no screenshot is available yet the page will show a placeholder image which gives you a convenience link to the screenshots page of the package where you can submit one for the benefit of all. Please make sure that you are following the guidelines for submissions, otherwise your upload might get rejected. On a not totally unrelated topic, the packages.ubuntu.com site finally will also show you packages in maverick. It doesn't show screenshots yet if you think adding support for screenshots in there would be a good thing too, please let me know! Enjoy!

/debian permanent link Comments: 5

When Lars and I started work on Branchable, the Ikiwiki-based wiki and blog hosting service that we first discussed a year ago, and launched two weeks ago, we didn't know what software to use to build it. Probably, we assumed, we'd need a relational database. (Or maybe Couchdb, we wondered?) To manage the sysadmin jobs of keeping a slew of Ikiwiki sites running, we investigated using Puppet or Chef. (We worried that scaling Puppet or Chef to handle an arbitrary number of ikiwiki sites could be a problem.) For the user interface frontend, we assumed we'd be writing code in some kind of web application framework. Nearly all of that conventional wisdom turned out to be false. Instead, all the frontend code for Branchable runs as part of Ikiwiki. www.branchable.com is just another Branchable site, though one with some custom plugins that can make other sites and display a user's control panel. Other plugins handle things like the DNS setup interface. Those plugins are part of the first public site hosted on Branchable, ikiwiki-hosting.branchable.com. That wiki's git repository holds all the code, as well as the wiki for documentation and bug tracking. Also included in ikiwiki-hosting are some backend programs, like ikisite, which handles the high-level site management (creation, deletion, branching, etc), and is what we used instead of Chef. (Though we may use Chef for server deployment later.) Rather than use a relational database, we did out own little noSQL thing, by using a special, locked-down wiki as our database. That wiki is so special-purpose that it is not even accessible via the web! But it's managed by Branchable just like any other site. Deciding to not use a database was a watershed moment, because at that point we were fully dogfooding everything for Branchable. It's worked out well so far, possibly because our database needs are minimal. We have over a dozen other Ikiwiki sites in Branchable that we use either internally, or for other special purposes. Like this parked site that is branched every day to refresh sandbox.branchable.com. So, no database, no Puppet, lots of dogfooding. Did we use a web app framework? Not really. The closest we came is when developing Branchable highlighted that Ikiwiki needed a more user-friendly openid login interface, so I went off and adapted one, and of course added it into Ikiwiki proper. And that uses the JQuery framework. (I might write sometime about all the other Ikiwiki improvements that Branchable spurred.) We've done a lot of eating our own dogfood at Branchable, but I think it's all been pragmatic, not due to Not Invented Here syndrome. And the result is that Branchable is increasingly flexible in what its sites can do, and runs on a very simple architecture, with no odd special-cases for database servers, etc. It's just a bunch of Ikiwiki sites that work together.

A while back I mentioned that I was going to be updating and overhauling the blogspam.net service. That process is now almost complete. A couple of nights ago I overhauled the website, and today I've finally commited my last (planned) change to the repository for the purposes of migration. I started reworking the code a week or so ago, but as of this evening the code in the repository is the code the server is actually running. The previous codebase was functional but a little hasty - and was implemented before I switched to per-UID server-hosting - so there was a need to clean things up and make sure permissions and similar niggles were checked. The new, modular, codebase requires no root access, and will store all state (logs & transient caches) in a clean extensible fasion. The code is also much more flexible making use of Module::Pluggable rather than Class::Pluggable. This allowed me to overhaul the API of the plugins (primarily to add an expire method such that each plugin has a well-defined means to expire any state they may maintain). Module::Pluggable is a great module - allows me to treat plugins as first class objects, which wasn't the case with C::P. Since all the code behind the service is Perl it is also now available on CPAN in addition to the mercurial repository where it is developed.. I see that the server is getting pretty popular these days, used by the likes of embedders.org, publiclive.com, & etc. It doesn't hurt that ikiwiki, identi.ca, and other people include support in their distributions these days. Me? I mostly use it on debian-administration.org where it does a great job. ObQuote: What's the name of that thing that if I eat it real fast, it's free? - Whip It.

Since I worked on UDD s upload history gatherer during Debconf, I generated the list of new Debian contributors. (By contributor, I mean here someone in the Changed-By field of an upload (so it s not necessarily the maintainer of the package he/she upload)). It s quite fun to try to remember the context of your first upload to Debian (which package, who sponsored it), and look at the other contributors that graduated at the same time as you did. Or to see the constant flux of new contributors.