Search Results: "ema"

16 October 2007

MJ Ray: Stuttering through comment spam

I get too much spam and some of it isn't obvious from the subject line, particularly if it's a blog comment, so I use the following script to read the suspicious emails and pause at the bottom of each mail. It takes two optional parameters, explained in the comments below. Please comment on any obvious improvements to this quick hack.
#!/usr/bin/mzscheme -qr
(let ((c (or (and (> (vector-length argv) 0)
                  (string->number (vector-ref argv 0)))
             1)) ; first arg is how long to pause in seconds, default 1
      (re (or (and (> (vector-length argv) 1)
                   (regexp (vector-ref argv 1)))
              (regexp "^From [^ ]*@"))) ; second arg is regexp to pause at
      (i #f))
  (let loop ((l (read-line)))
    (if (regexp-match re l) (if i (sleep c) (set! i #t)))
    (write-string l) (newline)
    (if (not (eof-object? (peek-char))) (loop (read-line)))))
(exit)
;
#!/usr/bin/perl
# An earlier version in perl
$c = ($ARGV[0] 1); # How long to pause, in seconds
$re = ($ARGV[1] '^From [^ ]*@'); # What to pause on
$i = 0;
while (<STDIN>)  
  if (/$re/)   if ($i)   sleep ($c)   $i=1;  
  print $_;
 

Alastair McKinstry: The Curse of Oil

Jaldhar Vyas points to the rogues gallery of oil producing states and argues that Neoconservatism is good, well at least it gets rid of the dictators such as Saddam Hussein while it grabs the oil. As he ightly points out, we are researching new alternative energy sources, and just as importantly (or even more importantly) energy conservation. But we have been doing this for decades. Sooner or later we have to realize that the "Oil Crisis" isn't due to a shortage of energy sources: its due to deliberate politics to make us dependent on oil. Peak Oil is "only" a crisis for us consumers, dependent on oil to drive our cars, heat our houses, and supply our food. For oil companies, it means (1) they are shipping oil at a greater rate than ever before, (2) at higher demand than ever before, and (3) in circumstances where pesky politics like OPEC can't interfere and try and moderate the price down (I'm not arguing OPEC or cartels are good; its just that its long-term 'maximize the benefit for the oil producing nations' strategy interferes with oil companies shorter-term profit maximization). For the Oil Companies, its a good thing. In this context we have to see our current dependence on oil as the result of deliberate policy by the oil companies. The small filip that USanian governments have done towards alternative energy, such as funding Hydrogen fuel-cell research, nuclear power, etc. are so long-term, and so small in scale, that they have to be seen as deliberately not solving the problem. Thinking that research into alternative sources is good is gpoing to save us (disclaimer: as a scientist I think research is a good thing :-)) is missing the real problem. Its politics: the oil companies have simply been better at politics than the strugging alternatives; we need to recognize this, and fight for alternatives. When oil prices reach $100/barrel, and we struggle to pay rising food and energy bills, its because other have deliberately caused the crisis. Oil has often been called a Curse because of the effects 'Oil Wealth' have caused so many countries. They are not co-incidentally dictatorships; Saddam Hussein remained in power in Iraq for so long because it benefitted the West (see the weapons supplies to Iraq in the so-called "Iran-Contra" affair, for example). Ditto Saudi Arabia, remaining 'friends' of the USA despite its ties to 911. Overthrowing Saddam Hussein was about consolidating even more power in the Gulf than America had previously, not democracy. What was planned for Iraq was democracy in name only: all real power was already neutralised, with decisions to US benefit cemented in place before the parliament met: non-negotiable contracts already signed giving US companies control. This is straight imperialism, and cannot be considered democracy or a good thing. Tags , ,

Marc 'Zugschlus' Haber: A thousand things I never wanted to know about X

In the last few days, I have replaced the two 20 inch CRT monitors that I have hardly used the last years with two 20 inch TFT displays, and my company (finally) gave me a 19 inch TFT display to accompany my notebook display at work. Maybe I should take that as a hint that they want to see me in the office more frequently rather than in my home office which I generously use these days. At home, I built a “new” computer from mainly used parts to drive the two 20 inchers. I have learned a lot about X in the last days, but spent too much time with it. I have been running my Desktop with older X and two CRTs for quite some time, but I hardly ever used it due to the setup of my now ex-flat. Back then, I learned that the “two monitors, one display, one screen, one desktop” option of X was called Xinerama and statically configured: You write down your display layout in xorg.conf and it uses it. Configuration changes mean restarting the X server. KDE notices Xinerama automatically, designates one monitor the “main monitor” and displays its panel there. You can move windows from one monitor to the other one, but changing virtual desktops always changes what both monitors display. This is not really what I want, since I often have “static” contents (news reader, mail reader, chat windows, help screens etc) on one monitor while I do my normal work on the other monitor, which involves changing virtual desktops. So I was rather happy when I learned upon the arrival of the external TFT display for the notebook that you can work without Xinerama. In that case, the X server comes up with one display and two screens, which KDE uses to display two independent desktops which can be independently configured, but can both be accessed with one mouse and one keyboard. For me, this means that I finally can independently change virtual desktops on both monitors, but pay the price that I cannot display a certain virtual desktop on monitor 1 now, and on monitor 2 in five minutes, and that a window opened on monitor 1 is never going to be shown on monitor 2 without serious interference. This looked ok for me. Additionally, you can use different font sizes on the different monitors as defaults, which comes in handy if both monitors are blatantly different in size (which is the case with the notebook and its external monitor). However, with that setup, KDE seems to be challenged when it comes to saving the configuration. Some things (such as desktop background and panel config) seem to save fine, desktop independent, other things (such as open windows and their position) are lost when the session exitst. My daily visit to Kevin&Kell (which used to be in a browser window that was saved with my session) has badly suffered since then. Then, a few weeks ago, somebody talked me into trying the X server from experimental. Which is when my dual-desktop setup ceased working. The nice people on #debian-x told me that Xinerama is a thing of the past, and is currently in the process of being replaced by Xrandr 1.2. The removal of “my” two monitor, two screens, two desktop setup is collateral damage, and if I still want that behavior, the X.org upstream considers this an issue to be handled by the Window Manager / Desktop Environment now. Gee, thanks. That’s what I call a regression. After spending half a day cursing and ranting, and even considering to go back to lenny’s (or even etch’s) X.org, I finally settled on going with the “new” way as I was going to lose my independent desktops sooner or later anyway. Again, with the friendly help of the people on #debian-x, I found out about a lot of advantages of the latest X servers. In most basic cases, the latest X server does not need a configuration file any more. It autodetects your hardware and chooses whatever modes it finds optimal. It does a pretty decent job in doing so. If one wants to influence how the X system comes up, once can always write an Xorg.conf file - the configfileless server even writes the “virtual config file” it uses to the log as a starting point. Additionally, almost everything regarding screen layout can be reconfigured at run time using the xrandr binary from a command line. Even a hardware change (such a new monitor plugged into the powered on notebook) is correctly detected. Cute. This allows me to reconfigure my notebook depending on where it currently is and which external monitor (or projector) is connected. This can be perfected if I find out whether X offers a hook to plug a reconfiguration script into that is called when the X server starts or when the system is waking up from standby or hibernation with the X server running. A lot to do, and great potential for elegant stuff. However, while I am talking about hibernation, this is a downside of the new driver: When the system wakes up from hibernation, the X server sometimes confuses itself enough to become nearly unuseable: I had it become psychotic when plugging in the external monitor (which can do 1600x1200 points) after waking it up from hibernation at the office. The internal display can only do 1400x1050, and the box thought that the external monitor only had 1050 y axis pixels, displaying bit garbage in the lower part of the big monitor, and showing a useable, but unintelligible panel. When opening any browser or any other application with considerable text amounts in the window, all fonts become unreadable once one scrolls down. Restarting the X server helps and everyting is fine. But I do not use hibernation to force myself to log out of X after waking up. After going back to the “one monitor mode”, the X server now thinks that my virtual desktop is 1600x1200 and only shows 1400x1050, with dead space at the right and lower side of the virtual desktop. xrandr does not allow me to reisize the FB below 1600x1200. No idea what’s going on here. In most of the cases, calling xrandr --auto for each output will fix the issues at run time, but sometimes a session restart is needed. Code needs to stabilize quite a bit before becoming useable in production. There are a few disadvantages that will remain: Both monitors will change their contents when the virtual desktop is changed, and both displays will use the same default font size (which might be inappropriate if both displays are of different size). But I think, when the issues are cleared up, that I can live with these disadvantages. The “new” desktop system that I built has a Matrox G450 dual head graphics card, and unfortunately, the Xrandr 1.2 enabled X server from experiemental has shown to be unuseable: Upon some mode changes, the X server goes into an endless loop and proves itself to be unkillable short of SIGKILL. And if it dies, it sometimes pulls the entire system with it. There is a corresponding bug in the upstream BTS, but it hasn’t received any noticeable attention by the upstream developers. So I might find myself configuring one last Xinerama config before I can finally completly migrate to Xrandr 1.2 on the desktop as well. Then I’ll probably need to bug the KDE upstream people to implement a two-desktops-on-a-single-screen feature in one of their future versions so that I can get my independent-desktop-things back. But that’s a far far away future.

Dirk Eddelbuettel: Some marathon data analysis

A few days after the Chicago Marathon in record-heat, I was wondering just how much more I had been slowing down, and exactly when during the course of the race this occurred. Bigger races like Chicago provide the so-called 'splits' for every five kilometer segment. Helpfully, they also keep these with the archived results which are all accessible via the web. So it was easy enough to collect a sequence of time such as '0:22:34', '0:45:30', ... and so on. And thanks to R, my data slicing and dicing and visualizing tool of choice, it was just a handful of lines to produce the chart below. The chart covers my four Chicago marathons (2004, 2005, 2006 and 2007) as well as Boston (2007) --- the infamous '27.2 mile marathon' seems to have dropped off the net, and the smaller Sunburst does not have 5k split times. (pace comparison chart) The chart shows a few things quite nicely: While it was a tough race, I clearly ran a lot slower than previously, in particular between 25 km and 40 km. So there.

Raphael Geissert: Print before you think!

What?! I mean... Think before you print!.

It's not very uncommon to see people who always print almost every single email they receive with information (and not just a notification), pdf's, and many other kind of documents.

I've never liked when people do that because they don't just print it, they sometimes even print the whole email conversation (usually gmail users). Some of them even dare to use non-recycled paper for printing some text and trashing it away after reading it!

Today is the Blog Action Day about the environment, so all I want to say is: reconsider, reuse and recycle (yes, in that specific order :D ). I know it's not the classic reduce, reuse, recycle message because I think people should better reconsider and not only reduce.

Here's a nice reminder you can, err, use on your computer's desktop (did you think I was going to say print??, I wasn't):


If you don't like that one, Google will point you to some others.

15 October 2007

Martin F. Krafft: CO and the environment

Today is environment blog action day. I don't like memes or mass actions of this sort, but given a recent discussion on the effects of Al Gore's movie An Inconvenient Truth and everyday/everyone environmental protection on a UL-internal discussion list called "opinions", I feel like sharing my views. The original poster suggested everyone to see the movie and was promptly smashed down by two people who responded along the lines of "the movie has no scientific basis," quoting fancy research on how global warming is not as bad as it's hyped to be, and that CO is not as guilty as everyone claims. None of this research is relevant to what I had to say to this, so I won't quote it, but if you're interested, the Intergovernmental Panel on Climate Change (IPCC) is the place to start. One person went further and compared the CO -reduction hype to communism and criticised how we're expecting everyone to take action on the basis of false claims. I was partly disgusted by (all) those replies, not because they weren't accurate, but because they simply miss the point. And because the entire discussion was just another iteration of talk versus action. It may well be true that CO is not that bad, after all. But it's also true that any reasonable attempt to reduce its emission is not going to harm the environment (not to say that it might actually have a net-positive effect). Or as I put it in the thread:
I don't care for politics, I don't even care for research on this matter. I care for my environment, and I don't need to be a scientist to assume that plastic bags and car exhaust and lights left on when out to the pub are not making it any better. And yet, I am not a militant green. I prefer halogen light bulbs to the energy-saving ones and occasionally I'll be at the supermarket without a reusable bag; I don't condemn people using cars instead of a 15 minute walk to the office, and I still haven't managed to talk to a housemate of mine (no, not my Swiss flatmate), who notoriously leaves lights and appliances running when away. But at least I can say that I think of these issues, without scientific basis, but common sense. And I'll say that a thousand people aware of that will make more of a difference than any politician out there.
Not only do I think about these issues, I also act accordingly. But to be able to do that, I had to become aware of them. In as such, I'll stand by the claim in the discussion: awareness is what we ought to strive for, rather than talking about possible ways to start considering how we could potentially one day make leaps towards the solution of the world's problems, of which the environment is one. Awareness and little steps, which everyone can take: turn off lights and appliances, turn down the heater, use reusable shopping bags, prefer local produce to imported products, avoid fancy packaging, and so on In the thread, I asked "What have you done today to help lessen the burden we place on our environment?" I got no replies. I hope that's because people couldn't be bothered to show off their little contributions to the environment. If that were the case, then we are on the right path. NP: Gazpacho: Night

Biella Coleman: On Adivising Grad Students: A grad student perspective

Joe Reagle, who happens to be a PhD student I am happily advising, wrote a response to my blog entry on the Chronicle of Higher Education article lamenting and lambasting advising graduate students. I am quoting it here in its entirety because it is a very thoughtful response:
Difficult issue. I certainly feel sympathy with the anonymous faculty member with respect to her amorous and litigious students. Also, I often wonder how I would deal with students who don’t share my sensibilities or workstyle if I were advising them under such circumstances. However, I also find much of her disappointment is related to disappointment of what her students do next, and in this I feel she may be a little unfair. She rightly recognizes that graduate school is a time of flux, no student can really guarantee what’s going to happen next. (One of my favorite religious jokes is: “How do you make God laugh?… Tell her your plans.”) If she is disappointed that a student she tried to help achieve a position at a tier 1 research institute accommodates themselves to something less than that, I’m sure at the student worked just as hard and was even more disappointed. The heart of the issue is that academia is so ridiculously competitive. It is never good enough to make a contribution or to be helpful, one always needs to be the best. It’s an exemplar for “The Winner Takes All.” I often think of this in relation to my technical work. One of the most rewarding professional relationships I had was when a more experienced programmer co-authored a Python software library with me. I don’t think he did it with any expectation that he was somehow seeding the discipline with followers, or even that I would someday be able to reciprocate in a similar manner. He was a good guy, we enjoyed our collaboration, I think he was learning by helping me, and in the end we made something useful, even if neither of us ever became Python gods. This is one of the things I like about open content communities, yes the people at the top get a fair amount of attention, but even if you spellcheck Wikipedia articles or write a Python library for canonicalising XML, that work is still appreciated.

Christian Perrier: RWC: That will be South Africa-England

...and, really, we nearly never thought that Argentina could win tonight. South Africa was really too strong for them. The only domain where Argentinians dominated were scrums but this was much compensated by their great weakness on line-outs, losing something like 5 or 6 of them. South Africa thus logical won very easily...and Bryan Habana is now the best try scorer all along RWCs, along with Jonah Lomu. He is a really great player, indeed. Much much impressive South Africa: they'll be by far the favourites of the final against England, which they beated already during that World Cup. I said several times that I'm not a deep fan of RSA's play, but I could become one. Their game improved all along the World Cup and today, they probably played their best match. Two remakes next week-end: France-Argentina for the 3rd place and South Africa-England as final. That will be good matches, no doubt...and I hope that Bernard Laporte will change the French team to play against Argentina.

14 October 2007

Cameron Dale: DebTorrent Needs a Sponsor

Since the conclusion of the Google Summer of Code, the DebTorrent project has been without a sponsor. I was going to email debian-mentors to see if anyone was interested, but I decided to first post to my blog to see if there are any Debian Developers reading this who have the time and are especially interested in sponsoring it. Here are some of the details of the package: It is currently maintained using an svn-buildpackage subversion repository, but I might be interested in switching to git if a sponsor is interested.

Christian Perrier: RWC: That will be South Africa-England

...and, really, we nearly never though that Argentina could win tonight. South Africa was really too strong for them. The only domain were Argentinians dominated were scrums but this was much compensated by their great weakness on line-outs, losing something like 5 or 6 of them. South Africa thus logical won very easily...and Bryan Habana is now the best try scorer all along RWCs, along with Jonah Lomu. He is a really great player, indeed. Much much impressive South Africa: they'll be by far the favourites of the final against England, which they beated already during that World Cup. I said several times that I'm not a deep fan of RSA's play, but I could become one. Their game improved all along the World Cup and today, they probably played their best match. Two remakes next week-end: France-Argentina for the 3rd place and South Africa-England as final. That will be good matches, no doubt...and I hope that Bernard Laporte will change the French team to play against Argentina.

David Welton: Feisty to Gutsy Upgrade

I have a computer with a RaLink RT2561/RT61 wireless card that never worked very well under Feisty, so I decided to try out Gutsy, on a whim. The good: The card now works! So that's good news. Other than that, none of the features listed here is a big deal for me, but it's nice to get a lot of programs updated to newer versions. The bad: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/115616 Luckily it's easy to fix. The ugly: Upgrading emacs was a pain, as a lot of packages seem to cause breakage with emacs22. That's not really the fault of the Ubuntu guys, but it would be wonderful if they'd fix it prior to release. I haven't used the computer much yet, but consider the release isn't official yet, it's not bad, but I think it still needs a little bit of work. Anyway, I'm happy that my card works, I'm happy.

Martin F. Krafft: Converting a package to Git

Previously, I demonstrated a Debian packaging workflow using Git and I mentioned the possibility of a follow-up post; well, here it is: you want to use my workflow (or one that's related) for a package that is currently maintained with Subversion on svn.debian.org and you'd like to keep the history during the conversion. Make sure to read the previous post before this one. I am again using the example of mdadm since its Git packaging repository is in a state of shambles and I want to restart to get it right and import the history from the previous Subversion repository. What better way than to write a blog post as I do so? Well, plenty actually. This kind of post isn't really made for a blog, and I have started work on setting up ikiwiki on madduck.net, but it's not yet ready, so I'll stick with the blog for now. I will make sure that links don't break as I move content over, so feel free to bookmark this
Importing the package into Git Thanks to git-svn, the initial step of getting your package imported into Git is a breeze:
$ git-svn clone --stdlayout --no-metadata \
    svn+ssh://svn.debian.org/svn/pkg-mdadm/mdadm mdadm
Sit back and enjoy. If that command exits prematurely with an error such as the following:
Malformed network data: Malformed network data at /usr/local/bin/git-svn line 1029
then you should upgrade to a newer Git version, or have a look here. If your Git does not know --stdlayout then upgrade as well (or use -T trunk -t tags -b branches instead). Sam Vilain notes that it is important to "get the attribution right with the final SVN import - getting the authors map right. I didn't do that. If you look at the repository resulting from the above command, you'll notice strange commit authors, such as madduck@some-unique-uuid-from-svn . git-svn allows you to map these to real names with real email addresses, which ensures that the attributions are good for the whole world to see. When done, switch to the repository and run git-branch -r. As you'll see, git-svn imported all SVN branches and tags as remote branches. You need those if you want to bidirectionally track the Subversion repository, but we are converting, as you may have guessed by the --no-metadata switch above. Therefore, we resort to the Dinosaur method of converting branches to tags, which I'll simplify for mdadm. We also just delete all remote branches after tagging, since mdadm never used branches in the SVN repository. Your mileage may vary.
git branch -r   sed -rne 's, *tags/([^@]+)$,\1,p'   while read tag; do
  echo "git tag debian/$tag tags/$ tag ^; git branch -r -d tags/$tag"
done
git branch -r   while read tag; do
  echo "git branch -r -d $tag"
done
If that seems to work alright, then you can execute the commands. Sam Vilain (again) hints me at git-pack-refs and then to edit .git/packed-refs with an editor. This certainly leaves more room for errors but might be significantly faster.
Cleaning up the SVN references Even though we passed --no-metadata to git-svn, it did leave some traces in .git/, which we can now safely remove:
$ git config --remove-section svn-remote.svn
$ rm -r .git/svn
Setting things straight You can skip this section unless you want to know a bit about how to fix up stuff with Git. There was actually some nasty tagging errors leading up to the 2.5.6-9 release for etch and I could never be bothered to fix those in SVN, but now I can (I love Git!):
$ git tag -d debian/2.5.6-10            # never existed
$ git tag -f debian/2.5.6-8 2.5.6-8~2   # mistagged
$ git checkout -b maint/etch 2.5.6-8    # this is when we diverged
$ git apply < /tmp/mdadm-2.5.6-8..2.5.6-9.diff
$ git add debian/po/gl.po debian/po/pt.po debian/changelog
$ git commit -s
$ git tag debian/2.5.6-9
Now that that's fixed, there is one other thing to worry about, namely the very last commit to SVN, which obsoletes the repository and points to the Git repository. But that's not all of it. I was also silly enough to include a fix in the same commit. Let's see what Git can do. Since the process of obsoletion involves all but adding a file, we can simply --amend the last commit and provide a new log message:
$ git checkout master
$ git rm OBSOLETE debian/OBSOLETE
$ git commit --amend
Now the repository is in an acceptable state.
Making ends meet The pkg-mdadm effort on svn.debian.org only maintained the ./debian/ directory, separate from the upstream code, and boy was that a bad idea. Just to give one example: think about what's involved in preparing a Debian-specific patch against the upstream code this has to end, and we can make it end right here; let's import upstream's code (again not using his ADSL line, but the upstream branch of the pkg-mdadm Git repository; see the previous post for details):
$ git remote add upstream-repo git://git.debian.org/git/pkg-mdadm/mdadm
$ git config remote.upstream-repo.fetch \
    +refs/heads/upstream:refs/remotes/upstream-repo/upstream
$ git fetch upstream-repo
$ git checkout -b upstream upstream-repo/master
Now we have two unconnected ancestries in our repository, and it's time to join them together. The most logical way seems to be to use the last upstream tag for which we have a Debian tag: 2.6.2. For this, we branch off the corresponding Debian tag (2.6.2-1) and merge upstream's 2.6.2 tag into the new branch. This will be a temporary branch Then, we rebase (remember, nothing has been published yet) the master branch on top of this temporary branch, before we end that branch's short life. The Debian tag stays where it is since it describes the state of the repository at time of the release of 2.6.2-1.
$ git checkout -b tmp/join debian/2.6.2-1
$ git merge mdadm-2.6.2
$ git rebase tmp/join master
$ git branch -d tmp/join
It just so happens that the head of the SVN repository, which is identical to the tip of our master branch, corresponds to Debian release 2.6.2-2, so we tag it:
$ git tag debian/2.6.2-2
We are now also "born" in the sense that maintenance in Git has started. Let's mark that point in history. There is no real reason I can foresee for this yet, but nonetheless:
$ git tag -s git-birth
Turning dpatch files into feature branches We want to turn dpatch files into feature branches and we somehow make it "proper". We could branch, apply the patch, delete the patch file, checkout master and delete the patch file there as well, but that appears "improper" to me at least; so instead, we'll cherry-pick:
$ git checkout -b deb/conffile-location
$ debian/patches/01-mdadm.conf-location.dpatch -apply
$ git rm debian/patches/01-mdadm.conf-location.dpatch
$ git commit -s
$ git commit -s $(git ls-files --others --modified)
I should quickly intervene to make sure you are following. I am making use of Git's index here. Applying the patch makes the changes in the working tree, but we did not tell Git that we want those to be part of the commit just yet. Instead, we delete the dpatch with git-rm, which automatically registers the deletion with the index. Thus, the first git-commit creates a commit which deletes the dpatch, while the second git-commit creates a commit with all the changes from the dpatch, using git-ls-files to identify new and modified files. But for now, let's move on. We have two commits in the deb/conffile-location branch, and one of those is relevant to the master branch, we cherry-pick it:
$ git cherry-pick deb/conffile-location^
If you're confused, let me explain: our goal is to have a number of feature branches, of which master is the one in which most of ./debian/ is maintained. All the branches later come together in the long-living build branch, so deb/conffile-location will never be merged back into master. However, once we applied the dpatch to the feature branch, we can delete it from there and the master branch. By cherry-picking, we "import" the deletion to the master branch. I repeat the same procedure for deb/docs, merging all the documentation-related dpatches, but I'll spare you the details.
and then Git let me down In the next step, I found I had misunderstood Git merging: I thought Git was smart, but Linus had his reasons for calling Git the "stupid content tracker" (more on that later). Read on as I am obsoleting dpatch files that upstream had merged: 99-*-FIX.dpatch. For consistency, I wanted to cherry-pick each of the appropriate upstream commits into the master branch along with deleting the corresponding dpatch file. Here is one example: 99-monitor-6+10-FIX.dpatch was obsoleted by upstream's commit 66f8bbb; the -x records the original commit ID in the log:
$ git cherry-pick -x 66f8bbb
$ git rm debian/patches/99-monitor-6+10-FIX.dpatch
$ git commit -s -m"remove dpatch obsoleted by $(git rev-parse --short HEAD)"
I repeated the procedure for the other dpatch files, removed the dpatch infrastructure, and then went on to merge it all into build to build the package. The build branch is a long-living branch off upstream, but which upstream? I'll fast-forward you past a segfault problem with mdadm, which upstream (thought to have) resolved with commit 23dc1ae after 2.6.3, but he had not yet released 2.6.4. Looking at the commits between 23dc1ae and upstream's HEAD at the time, I decided to include them all and snapshot 4450e59:
$ git fetch upstream-repo
$ git checkout upstream
$ git merge upstream-repo
$ git tag mdadm-2.6.3+200709292116+4450e59 4450e59
$ git checkout master
$ git merge --no-commit mdadm-2.6.3+200709292116+4450e59
$ dch -v mdadm-2.6.3+200709292116+4450e59-1
$ git add debian/changelog
$ git commit -s
And then I called poor-mans-gitbuild, which merges master and then deb/* into build. Here is when stuff blew up. I'll make a long story short (read my description of the problem and Linus' answer if you want to know more): I thought Git was smart to identify merges common to both branches and do the right thing, but it turn out that Git does not care at all about commits, it only worries about content and the end result. In our case, unfortunately (or fortunately), the outcome meant a conflict because the upstream branch introduced a simple change (last hunk) in the lines surrounding the patch we cherry-picked, and Git can't handle it. The solution is not to cherry-pick, to cherry-pick all commits touching the context of the dpatch, or to simply merge upstream into all out feature branches. In our case, the first is the easiest solution and since importing dpatch files is a one-time thing (thank $DEITY), I'll leave it at that. Almost. I have spent two days thinking about this more than I should have. And it was this point Linus made which made me appreciate Git even more:
Conflicts aren't bad - they're good. Trying to aggressively resolve them automatically when two branches have done slightly different things in the same area is stupid and just results in more problems. Instead, git tries to do what I don't think anybody else has done: make the conflicts easy to resolve, by allowing you to work with them in your normal working tree, and still giving you a lot of tools to help you see what's going on.
The end This concludes today's report. Importing the changes from the old Git repo, tagging and merging the branches is all covered in my previous post, or at least you'll find enough information there to complete the exercise. I would like to specifically thank Sam Vilain and Linus Torvalds for their help in preparing this post, as well as the #git/freenode inhabitants, as always. If you are interested in the topic of using version control for distro packaging, I invite you to join the vcs-pkg mailing list and/or the #vcs-pkg/irc.oftc.net IRC channel. Also, if you are interested in Git in general, you can find a list of blog posts on the Git wiki. NP: The Police: Zenyatta Mondatta

Joey Hess: lego

The good: I had fun building an enclosure for my Atari <-> PC serial adapter board out of legos, and I love the result. Been too long since I played with legos. I need to dig up the rest of my legos so i can make some enclosures for my ARM boards. The bad: I picked up a 1 gigabyte USB drive in the shape of an off-brand lego block today. The price was right (< $10), but the implementation is depressing -- the fake legos don't stick well and so the cap can't be mounted on the drive body when it's in use. And the size isn't lego standard, so it can't attach to other blocks. The ugly: In a better world, Lego would be an open standard. The patent expired in 1988 (according to Wikipedia. But the company still has lawyers, who seem busy doing what (corporate) lawyers do. Meh. Legos were more fun to play with when playing with them didn't involve worrying about patents and copyrights and the market's propensity to deter standardisation.

13 October 2007

Adam Rosi-Kessel: Opened Pandora

Via Eric Goldman’s recent recommendation, I decided to give Pandora another shot. The short version: Pandora is an intelligent predictive personalized Internet radio service with an arguably sustainable and protectable business model. And by “intelligent,” I mean there are real human brains at work. As Eric explains:
Pandora’s main competitive differentiator is its “Music Genome Project.” 50 trained musicians with at least a college degree in music (called “music analysts”) listen to songs all day long and rate each song on 400 different musical attributes. See the 2005 WSJ article discussing them. By profiling songs this way, the system can predict that a person who likes an artist’s song might like other songs with similar musical attributes. From listening to Pandora for many, many hours, IMO the system isn’t perfect, but it does a pretty good job, and it has definitely hooked me on music that I wouldn’t have listened to otherwise.
They have apparently cataloged approximately half a million songs and the database continues to grow apace. There is also a collaborative-filtering aspect, similar to Netflix and Amazon. I suspect this hybrid between the “wisdom of crowds” and the “wisdom of experts” will be the future of most large content projects (including wikipedia). My first few hours have returned excellent results. I created a for-working “station” called, lazily, “The Bad Plus Radio” (described as “Avant garde and angular funk/jazz, but not so dissonant that you can’t do mind-taxing work while listening”). You are welcome to listen as well. (See also my Pandora Profile.) The “artist seeds” for the channel include the following: Pandora has played several tracks by these artists, but is increasingly mixing in other artists that match up on some axis of preference. I’ve thumbed-up and thumbed-down several tracks from beyond the “seed” set (and will continue to do so), thus driving the predictive engine. I look forward to creating some entirely different channels and publishing the URLs here. Although supposedly the “free” version is ad-supported, I haven’t heard any ads yet. Maybe that is still to come. In any case, it is probably worth the $36/year subscription cost. Beyond the specific content I’m enjoying here, it is nice to see a Web 2.0 (or pick your favorite version) business model that doesn’t require a leap of faith to see how it can work. Of course, they have a Facebook app as well.

Biella Coleman: Bad Apples .

I am not even sure what to make of this article, written by a professor at a well-known university, on the perils of advising graduate students. Given that I have been sitting at my computer for nearly 12 hours straight and since 4 a.m, I don’t think I am really in a state of mind to think too much of it. Neither do I have much experience doing this (though whatever experience I have had, it has been good so far), so I can’t really comment back via personal experience. I only hope that her/his experience was the exception or that he/she allowed too many boundaries to be crossed, but whatever the case, interesting food for thought. I am sure a graduate student could write an interesting counterpoint, talking about all the questionable things their professors did back to them too and knowing the web, I am sure that will be forthcoming soon.

Julien Valroff: Switched to Dovecot LDA and Sieve

I have worked almost all the day to update my mail server configuration to use Dovecot LDA and the Sieve mail filtering language instead of maildrop. This was very easy thanks to Christoph’s ISP-style Email Server with Debian-Etch and Postfix 2.3 how-to.
(more…)

Daniel Burrows: Monad.Reader

The Reader monad is a simple and easy-to-use structure from the Haskell library that solves a common problem.

Very often, it's the case that you have a lot of functions that all need to use the same values. For instance, you might be laying out some text on a page, and you need to keep the details of the page size around in all your layout algorithms. Typically, you handle this situation by adding a new parameter to all your functions which represents the state. So,


layoutPage :: Text -> Page


becomes


layoutPage :: PageLayoutParams -> Text -> Page


This works just fine, but it can get really ugly. Every single function gets a new parameter, which must be threaded through to every related function that it ever calls. This causes visual clutter, particularly for functions that don't actually use the parameter themselves but just pass it on.

A function written in the Reader monad is augmented with a hidden parameter. For the hypothetical example above, we would write:


import Control.Monad.Reader
type LayoutFunc = Reader PageLayoutParams

layoutPage :: Text -> LayoutFunc Page


Note that the Reader monad is partially applied here. The result, LayoutFunc, is a new monad that adds a parameter of type PageLayoutParams to any code that runs inside it.

So, now that we have this monad, how do we use it? The "ask" operation retrieves the parameter that's hidden in the monad:


ask :: Reader a a


or, specialized to LayoutFunc:


ask :: LayoutFunc PageLayoutParams


In order to remain close to the example in question, I will provide specialized type signatures for the rest of the library functions. You can find the generic type signatures in the Haskell library documentation for Control.Monad.Reader.

Suppose that layoutPage started out like this before it was moved into the monad:


layoutPage st txt =
let width = pageWidth st
...


In the Reader monad, this becomes:


layoutPage txt =
do st - ask
let width = pageWidth st
...


As you can see, we've gone from one line of code to two. As this is clearly unacceptable for a clutter-reducing device, the Reader module provides a convenience function encapsulating the above pattern:


asks :: (PageLayoutParams -> a) -> PageLayoutFunc a


This allows us to simplify the monadic implementation to:


layoutPage txt =
do width - asks pageWidth
...


It's quite common, when multiple functions share context information, to invoke a function in an altered context. For instance, we might have a layoutSubPage routine that changes the page width:


layoutSubPage st newWidth txt =
doLayout (st pageWidth = newWidth txt)


The Reader equivalent of this idiom is the function "local":


local :: (PageLayoutParams -> PageLayoutParams) -> LayoutFunc a -> LayoutFunc a


local executes an operation in a context modified by its first parameter. For instance,


layoutSubPage newWidth txt =
local (\st -> st pageWidth = newWidth ) txt


Finally, to actually invoke a computation in the Reader monad, use runReader:


runReader :: LayoutFunc a -> PageLayoutParams -> a

main = showPage (runReader defaultPageParams someText)


For much more information on the Reader monad, see All About Monads, or the Haskell library documentation.

Adam Rosi-Kessel: Useful Email Disclaimer

Unlike some email disclaimers, this snippet recently observed in a signature block could actually prove useful:
Please consider the environment - do you really need to print this email?

Eddy Petri&#537;or: SELinux: MLS/MCS support

When getting this error message:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
libsepol.link_modules: Tried to link in a non-MLS module with an MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!


You have to go back to the checkmodule step and type the same command, but add also the -M parameter:

bounty:~/usr/src/selinux/localpolicies/resolvconf# checkmodule -m -M -o localresovconf.mod *.te
checkmodule: loading policy configuration from resolvconf.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to localresovconf.mod

After that is all OK:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule_package -o localresovconf.pp -m *.mod
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -l grep localresolv
localresolvconf 1.0

Biella Coleman: Decoding Liberation: The Promise of FOSS (and Web 2.0)

Last week I helped Samir Chopra and Scott Dexter kick off their book release party in New York City. The book Decoding Liberation: The Promise of Free and Open Source Software is the first academic book length piece on free software proper that among other things examines the repercussions of such elements as language use (free software vs open source) and licensing (such as non-copyleft licensing). Here are my opening remarks, which don’t give justice to the book but give a small taste of what is in there. Samir and Scott are computer scientists, philosophers, and political thinkers and bring these positions and perspectives to bear in their work. While I tend to avoid the discussion on the differences and divergences between free and open source software and licensing (just because I ask a set of questions that tend not to go into that territory), they spend a hefty about of time on this sort of engagement And what is so useful about their approach is that it is technically detailed and carefully analyzed, clarifying the stakes involved in choosing a certain set of licensing over others, or the political implications of language use. Along with this focus, there are many other threads they unpack and one of my favorites is on the aesthetics of code, which I discuss with some detail in my opening remarks with the help of one of my favorite literary writers, Susan Sontag. The conversation that followed was lively, in part because there were a number of people in the audience who are also very familiar with FOSS (Somewhat unbelievably, there were 3 anthropologists there who study free software, myself, Jelena Karanovic, and Anita Chan). And I think one of the most interesting questions was launched by Anita who asked the authors what they meant more precisely by the promise of FOSS as well as liberation. The conversation that followed was too rich to recount here, but something that I raised and I do think is important is the relationship between the buzz word of the last few years, Web 2.0 and FOSS. Web 2.0 is related to FOSS in so far as Web 2.0 refers to a suite of technologies that allow for the creation of user-generated content and collaboration. FOSS refers to a development methodology that is based on promiscuous sharing of code and collaboration. The similarities, however, end there because much of the Web 2.0 infrastructure is proprietary. FOSS by definition is non-proprietary. But I think that soon we are going to see more Web 2.0-like companies open up their infrastructure entirely or at least important components. One example of a new technology that is Web 2.0-like and is entirely free software is a activist networking tool crabgrass that is pretty impressive (I have used it to coordinate my move and am using it now to coordinate a collaborative grant). It is still under development but once released, it will be a great boon to any group that needs to collaborate and organize and coordinate:
Crabgrass also provides a public advocacy centric view of content so that people can learn more about issues and organizations through social relationships. Blog tools, voter guides, petitions, event organizing tools, and action alerts are being added to the functionality of the platform. Crabgrass integrates wikis, asset repositories, task lists, calendars, polls, and meeting schedulers into one tool which allows groups to manage their internal organizing.
The other technology that I am excited about and that I have already written about is Kaltura. As I mentioned, Kaltura is important because it lowers the bar for collaboration, providing tools to facilitate video editing. But what I find as interesting and as significant is that they are perhaps the first large-scale Web 2.0 company that is actively seeking to enter the territory of FOSS and in this respect, once they do so, they will lead the field, not simply for technical reasons, but because they choose to make and engage with open source technologies. Bringing Web 2.0 within the orbit of FOSS and brining FOSS within the orbit of Web 2.0 can only work to bolster each other, and this is where I think, at least part of the promise of FOSS lies.

Next.

Previous.