Tales from the Gryphon/ categories/

Tales from the Gryphon

Blog postings related to Debian

Manoj's hackergotchi
RSS Atom Add a new post titled:
Monday 15 November
2010
Link: Dear Lazyweb: How do you refresh or recreate your kvm virt periodically?

Posted terribly early Monday morning, November 15th, 2010

License: GPL

Dear Lazyweb: How do you refresh or recreate your kvm virt periodically?

#+TITLE: Dear Lazyweb: How do you refresh or recreate your kvm virt periodically? #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ Dear Lazyweb, how do all y'all using virts recreate the build machine setup periodically? I have tried and failed to get =qemu-make-debian-root= script work for me. Going through and redoing it from netinst ISO is an option -- but then I need debconf preseeding files, and I was wondering if there are some out there. And then there is the whole "Oh, by the way, upgrade from Squeeze to Sid, please" step. The less sexy alternative is going to the master copy and running a /cron/ job to safe-upgrade each week, and re-creating any copy-on-write children. Would probably work, but I am betting there are less hackish solutions out there. First, some background. It has been an year since I interviewed for the job I currently hold. And nearly 10 months since I have been really active in Debian (apart from /Debconf/ 10). Partly it was trying to perform well at the new job, partly it was getting permissions to work on Debian from my employer. Now that I think I have an handle on the job, and the process for getting permissions is coming to a positive end, I am looking towards getting my Debian processes and infrastructure back up to snuff. Before the interregnum, I used to have a /UML/ machine setup to do builds. It was generated from scratch weekly using cron, and ran /SELinux/ strict mode, and I used to have an automated ssh based script to build packages, and dump them on my box to test them. I had local git porcelain to do all this and tag releases, in a nice, effortless work flow. Now, the glory days of /UML/ are long gone, and all the cool kids are using /KVM/. I have set up a kvm box, using a netinst ISO (like the majority of the HOWTO's say). I used [[http://madduck.net/docs/][madduck's]] [[http://slexy.org/view/s2acgjOwrr][old]] =/etc/networking/interfaces= set up to do networking using a public bridge (mostly because how cool his solution was, =virsh= can talk natively to a bridge for us now) and I have /NFS/, /SELinux/, /ssh/, and my remote build infrastructure all done, so I am ready to hop back into the fray once the lawyers actually ink the agreements. All I have to do is decide on how to refresh my build machines periodically. And I guess I should set up =virsh=, instead of having a shell alias around =kvm=. Just haven't gotten around to that.

Manoj

Monday 02 January
2006
Link: Belated ramblings on the state of the voting related stuff

Posted early Monday morning, January 2nd, 2006

License: GPL

Belated ramblings on the state of the voting related stuff

Well, as most of us have gathered, yet another DPL election session came to a close. The highlights from a technical standpoint this year were that Devotee was modified mid-stream to grok encrypted ballots (early encrypted ballots, though rejected, contributed by testing devotee). The other, more visible, high light was that devotee now spits out dot graphs to depict the pairwise contests in the Beat matrix, and the resulting graphical representation of the results were published. The reaction being mostly positive, I went back and punched in graphs on most of previous results that were at all complex and could benefit from the graph diagrams.

While I was changing the vote pages, I responded to criticism of the navigation panel (or the lack thereof) on the vote pages, and the result(after a couple of false starts) is aesthetically more pleasing (well, to me it is).

Hmm. Bits from the secretary ain't ever gonna happen. As this entry shows, they are deadly dull.

Manoj

Monday 02 January
2006
Link: Beyond crumbling consensus: communication in Debian

Posted early Monday morning, January 2nd, 2006

License: GPL

Beyond crumbling consensus: communication in Debian

I have talked earlier about the crumbling consensus in Debian, which was nice, but did not delve deep enough into the reasons for the crumbling tendency to try to arrive at an consensus.

I can see bunches of people jumping up and down screaming communication! communication! communication!. Yes, but; have people complaining about lack of communication ever looked for a cause why communication in the project has deteriorated (and no, frequent flame--fests do not count as communication)?

The facile explanation is that people who fail to communicate, or fail to respond, are either overly busy (which does not hold water since the people examples being flouted are actually doing visible and often extensive work), just plain lazy (again, easily refuted), impossible to communicate with (and there are equal examples of people who have no problem communicating with the same people), or just plain secretive and malicious and holding a grudge against people.

With my experience with people in the project, I find it hard to credit the theory that people are strongly for a hidden, secret big boy club in Debian. Despite recurrent and no longer funny references (always unsubstantiated) about a Debian Cabal, I have not yet found any actual instantiation of the so called super secretive cabal. I know these folks, guys, and I am not buying a super secretive cabal.

But surely there must be some fire under all this smoke, right? Yes, but not in the manner that people think, I suspect.

I think the same phenomena is at work that causes lack of consensus efforts in Debian; and the root cause is partially the growth of the project (resulting in people no longer being acquainted with the other participants), and the perception of Debian as an faceless institution, rather than a convivial set of people trying to have fun and put together a distribution focussed on excellence.

I say this, since I have seen the growing tendency to treat classes of volunteers as faceless, nameless, institutions: we talk about DAM's, ftp-masters, list-masters -- anonymous, faceless, institutions that one may then chastise with little need to cater to their feeling (since when do institutions have feelings?). This is a similar phenomena to people treating other cars far more rudely than they would if they were talking to the driver face to face. The increasing hostility, expressed as increasingly pointless flame wars, and increasingly hostile mails to the people in visible positions in Debian (often verging to obnoxiously rude demands), whittle away at the motivation of the people doing additional work in Debian beyond their packages.

Now, given that most developers do not care to do more than cater to their own packages (the DPL has said several teams, including security, are overworked, and have been asking for volunteers. Policy has been looking for new blood as well, and I have been lucky enough to find one person who actually started out by doing the scut work, rather than ask for spoon feeding and a gilt-edg4ed invitation) -- we have a few people putting in far more labour into the project, above and beyond the talk of maintaining packages. The tasks these people perform is becoming increasingly thankless, to the point a few have taken to ignoring the most unpleasant communication in the interests of sanity. Since they respond still to nicer communications, it may appear there is a cabal -- but this is basic human nature, avoiding experiences that have, in the past, proven to be unpleasant and unproductive.

So what do I propose? The same thing I proposed before: I suggest that we try not to lose sight of who we are fundamentally: we are a group of people who have found common cause to volunteer our time to make the best OS out there. Treat developers like people. I would like to think we are a bunch of folks having fun -- and working together for what is still a common goal. Look at the big picture. Don't let the end goal be lost in the petty details.

Manoj

Monday 02 January
2006
Link: Crumbling of Rough consensus in Debian

Posted early Monday morning, January 2nd, 2006

License: GPL

Crumbling of Rough consensus in Debian

I am not the only one to be struck with the realization that there is very little effort at building consensus going on in Debian of late. Positions are presented, the active participants rapidly become polarized, and things rapidly head to counting hands; the largest of the polarized camps then carries the day. This certainly is not how things used to be.

And it is not as if the absence of an effort to come to a rough consensus has made the lists any less acrimonious; so this reduced tendency to enter into a dialogue with people that disagree with one has not made the lists any friendlier.

I think a couple of otherwise useful institutions have contributed to this malaise; the first is the constitution. Though accepted with relief and absolute unanimity (this is the only unanimous vote we have ever had), it has its flaws: it is written in pseudo-legalese, which practically invites picayune nitpicking and contentious debate over minor points of order. We spend far more time debating over the form of the trees, and miss the forest. At the time the constitution was being crafted, we were reeling from absolutely any rules governing conduct and any delineation of powers of people in the project, we had an informally defined Project leader, and we probably did not submit the constitution to the review it required, so starved were we for any semblance of order.

The second is stems from an constitutionally defined process, the general resolution: though something like a GR mechanism is a must for a project the size of Debian, the facility with which one can vote on multiple options simultaneously has lead to people just throwing up amendments that they like, and brute forcing the most popular amendment through a vote. There is no effort to compromise, and no effort to ameliorate the tyranny of the majority. There is no effort to even begin to find a common solution, instead people seem to be offended if an option exactly matching their sentiments is not on the ballot.

Added to the growing unease about the lack of communication or openness in the organization (with the vague muttering about the cabal in Debian), this lack of communication (which is what this tendency not to convince the rest of the project of the merits of one's ideas is, really) leads to us making flawed decisions -- and then scrambling to put Humpty Dumpty together again.

So what is to be done? I suggest that we try not to lose sight of who we are fundamentally: we are a group of people who have found common cause to volunteer our time to make the best OS out there. I would like to think we are a bunch of folks having fun -- and working together for what is still a common goal. Look at the big picture. Don't let the end goal be lost in the petty details.

Manoj

Monday 02 January
2006
Link: Debian and tyranny of the masses

Posted early Monday morning, January 2nd, 2006

License: GPL

Debian and tyranny of the masses

There have been various people positing that Debian is a democracy. It's not, thank god. Yes, we do occasionally vote on issues, but that does not a democracy make.

Another theory often advanced (usually as a counter to the democracy theory) is that Debian is a meritocracy. Again, this is not true: as above, there are shades of truth (as in merit, in theory, is held in reverence in Debian).

Why is it not a democracy? Well, we do not decide on issues based on popularity (else we'd be distributing windows share-ware). We make decisions based on technical merits, and principles we have agreed on (the Social Contract, for one). A developer is the Czar for the packages maintained by him/her, for example.

Decisions, for the most part, are taken by those who do the work (in flex, and fvwm, I have made decisions that are fairly unpopular with the user base, but, in my opinion, the correct ones). A developer has control over his or her package. The NM team decides to accept (or not) applicants -- but not through GR's. The DPL decides who should get funded for debconf -- in consultation with other people, but not via a vote. In a sense, Debian is a volunteerocracy -- Those who do, rule.

Why do I say it is not a meritocracy? Well, there is no evidence that merit is a gating factor for entry into the project, or a position in Debian. Sure, a modicum of bare competence and a base demonstration of judgement is required, both for entry into the project, and for appointment to a delegate's job; but this is a minimum threshold, really. The important jobs are fulfilled by people who took it upon themselves, who went in and started working (my first real package, kernel-package, was just me getting tired of remembering all the steps needed to compile kernels, and the resulting kernel images were quietly accepted after a probation period). So, merit is not the gating factor -- demonstrating readiness to do the work trumps ability.

I am sure there are a large number of more meritorious people in the wings who never stepped up to the plate and volunteered; and they would lose out to people who stepped up and presented something. We are a volunteerocracy, not a meritocracy.

Why do I say thank god above? Do we really want Debian to be a democracy? I am not a domain expert in any but a small subset of technical topics, and I would hesitate to have my opinion overrule the domain expert's. And yet that is what going for popularity gives you. In all but a handful of topics, most of us represent mediocrity, and only the domain expert represents expertise; decisions by laymen, as opposed to the experts, lead to mediocrity.

So, do we really want democracy? Rule by the unwashed masses? Governance by the least common denominator? Taking the popular route, over determining the correct one? How can you create the best distribution ever by bending over backwards to pander to mediocrity? Would one want to select leaders based on how cute they look, or how well they kiss babies (which seems to be the basis we pick politician's by)?

Thanks for listening.

Manoj

Monday 02 January
2006
Link: First call for votes for the Sarge GR

Posted early Monday morning, January 2nd, 2006

License: GPL

First call for votes for the Sarge GR

I finally got time from my day job to set up the infrastructure for a vote. This entailed setting up a temporary vote key (the key I had set up earlier for the draft ballot had expired), adding the latest proposal (F). And set up the cron jobs, and so on.

Any way, head out over to the vote page for the juicy details. Take care in reading over the details, for this is not just a GR, it is a GR that changes foundation documents, and as the last vote has shown, any foundation doc change merits a modicum of diligence.

Manoj

Monday 02 January
2006
Link: In vain the sage with retrospective eye --Pope

Posted early Monday morning, January 2nd, 2006

License: GPL

In vain the sage with retrospective eye --Pope

It has been a tumultuous decade of involvement with Debian for me. I had been on the mailing list since mid 1994, but I was reasonably happy with my SLS system (installed using 40 floppies, including about a dozen for just X11 alone), and while I found Debian intriguing, I was not about to go through the pain of a brand new install until I felt that the new project was viable in the long term :-)

I actually jumped ship in the spring of '95 and installed 0.93R5. The next step came with Bug 1766, my very first bug report: Bug in script checksecurity in package cron, on 25 Oct 1995.

Once in, I rapidly went to the next phase: Here is the sum toto of the NM process I went through: my Hello, World mail. Those were the days :-). There was nothing between my ITP and the upload.

My first significant package was kernel-package, since I was always missing something in the series of steps needed to build a kernel, and I started getting into it in the summer of '96. This is where the second part of my apprenticeship started -- even though I had 3-4 packages in the archive, my kernel images were not yet trusted; so I sent my images to my sponsor (Hi Simon), who then uploaded the images to master.

Somewhat later, I also was involved in the early design stages of apt, and the dependency sorting algorithms.

While I was fairly silent during the whole DFSG/SC debates (to the extent I was labelled a mindless follower of Bruce --heh), I took an active part in the constitution debates (possibly due to the fallout of the beach story. Anyway, I seemed to want to get us a constitution, after it had seemed stalled for months.

It is interesting to note how the technical committee was initially setup, there was a proposal, and then Ian Jackson responded by saying he wanted to appoint the ctte members, since he had been around for a while and was also the DPL. The earliest data I can find is from June of '98, as seen in a mail later that year, when the initial list of committee members was created (I also seem to recall I was not on the list initially, but I was added in the early days, before the committee was actually formed).

I was interested in the technical policy fairly early, taking a stance that policy was more than just a bunch of ignorable guidelines. Eventually, a [thread that tried to reach a compromise][other] gave us something like the views we (well, I) hold today -- including what happens when packages do not follow policy, and about policy editors. And abuse of power. About this time, the policy Czar resigned, burned out, and hounded by accusations of delusion of power.

So I first proposed the whole policy editor and consensus approach to letting policy evolve, which eventually led to a formal delegation recently.

Brian Basset was our very first secretary. My first involvement with things that would lead on to the secretaries job started with trying to do voting for policy. Then, around 2000, our the secretary and treasurer Darren Benham went MIA, and Raul, as the chair of the technical committee, had to take over and run the DPL election for 2001 -- and forgot that DPL elections are supposed to be secret ballots. Ben Collins tapped me for the secretaries position mid-2001, as I recall.

It is hard, in a decade or so, to find anything I have not touched -- but NM is one such area. Apart from an early pre-current-NM mail, I have not been very involved in NM. Or the Debian installer. Or Debconf. Hmm. I seem to have drifted away from things that Joey Hess is involved in, which is a pity, he is high on the list of people I respect in the project, and this lack of interaction with as time goes on irks me.

Manoj

Monday 02 January
2006
Link: It is about Freedom, stupid

Posted early Monday morning, January 2nd, 2006

License: GPL

It is about Freedom, stupid

Suppose I have a set of Trade Marks, all legally set up and registered. I write up some software, and I am so enamored of my Marks that I intertwine them with every bit of my code (hey, they look pretty, OK, which is why I make them my Marks). Indeed, the effort of ripping them out would be essentially the same as rewriting the code. I, then, being the free software guy that I am, license the code under the MIT license.

However, I do love my marks -- so I have an aggressive trade mark enforcement policy, and I actively pursue usage of my marks by anybody unless they have approval from me -- and I don't allow them to use my mark if they have modified my code (I mean, who knows what butchery of my mark and my reputation shall then ensue?)

Should this piece of software be considered free by Debian? While the freedom to modify and distribute the software is effectively been taken away from the users of my software, there are those who argue that the software is free, since the freedom has been taken away by Trade Mark law, and not copyright law. By a strict reading of the letter of the DFSG, they claim that since only copyright licenses are mentioned, any other abrogation of freedom does not count. This is wrong.

The bottom line is whether the users have the freedom to modify the software, not exactly how the restriction of freedom was achieved. One should be looking at the freedoms, the so called spirit of the social contract, and not a strict interpretation of the exact wording of what is supposed to be a guideline, anyway (and yes, I know that the guideline argument has lent itself to abuse in times past).

Manoj

Monday 02 January
2006
Link: Project Leader Candidate rebuttals posted

Posted early Monday morning, January 2nd, 2006

License: GPL

Project Leader Candidate rebuttals posted

Well, all but one, since we still do not have one of the contributions in. I also think we have an agreement about the timing of the IRC debate, so we are well on our way to having a properly educated and primed electorate. As always, look at the vote page for details.

While working on my key-signing-helper script, I came across examples of IO::Select usage that I think shall benefit devotee, though I am leery of changing things this close to a vote. Oh, well, I guess the new gpg output processing code shall see the light of day with the first GR of the season.

Manoj


Webmaster <webmaster@golden-gryphon.com>
Last commit: in the wee hours of Friday night, May 31st, 2014
Last edited in the wee hours of Friday night, May 31st, 2014