Picking up the pieces

Update: After trying KiBi's suggestion to take advantage of this information, I looked for more info on the issue and found this conversation. A git upgrade to the backported git 1:1.7.1-1.1~bpo50+1 version, and git svn rebase started pulling the right stuff in. Yes, I left the svn-remote.svn.rewriteRoot stuff set to the old value and the svn-remote.svn.url to the new value.

Keywords:

Unable to determine upstream SVN information from working tree history

when running git svn reabase

---

As I said yesterday, I am going to come back to being active in Debian.

I remember looking a little at my page on the Debian Wiki and it was clear that it was stale. (I sometimes find it amusing how I presented myself „my name is Eddy Petrisor”.) For some reason now the wiki seems to be down.

Two days ago I tried to get the Wormux/Warmux upstream source but git svn appears not to like the rename although I even modified the .git/config and .git/svn/.metadata, but it still wasn't satisfied and answered in a bad mood with this message (after a long waiting period):

$ git svn rebase
Unable to determine upstream SVN information from working tree history

And, yes, I am aware of the compromise and I changed my password for the project on gna.org.

I guess is better if I try to take a look at the RC bugs for the moment.

Some Debian work in a long time

I finally managed to do some Debian work in a long time, I managed to package Wormux 0.8.5 for Debian Sid (aka Unstable).

This new version delivers one new binary package, wormux-servers, which contains the stand alone (aka headless) game server and the index server. Unfortunately, the information on setting these up resumes to have a couple of configuration files which are placed in /usr/share/wormux/examples/ .

Also, there's a bug that affects network games when using the construction tool, but fortunately, upstream already has some fixes, including one for this bug, and as soon as 1:0.8.5-1 enters squeeze, I'll prepare a patched version (including some other fixes present in upstream).

Until then, please enjoy Wormux.

migrating from svn to git for wormux's maintainance

I have been thinking for quite some time about migrating the maintenance of the wormux package to git, but in a really smart way so that:

• we preserve history currently stored in svn
• a new integration branch should exist - we used the incomplete package model with svn-buildpackage, but now it makes more sense to have the complete history, including the upstream code at the time
  
• all previous orig tarballs should exist in the git repo in pristine-tar format
• upstream's svn repo should be included entirely so that we can cherry-pick any patches we might want or need

Since both the package repo and the upstream repo are in SVN, you can't simply use git-svn for both in a single repo, so I started thinking of some scheme to be able to join both repos and the (uncommitted) orig tarballs (which are backed up on DGT's webspace).


Tonight I have experimented a little with my git-svn clones which I made previously and eventually thought that:

• the main repo should track the upstream repo via git-svn
• I should properly tag the debian package versions in the svn.d.o repo, so svn tags no longer look like branches in git
  
• ideally all the branches in the package repo should be reproduced in some corresponding branch in the final repo
• the integration branch (that should contain the real debian complete packages) should be created with a non-existant merge strategy which I call overlay (basically, for two branches A and B, the strategy resumes to: all files as in A are present, any files unique to B are present)
• using pristine-tar forces me to keep the 'upstream' branch reserved so I need to avoid using that

It seems the last point could be obtained in some way via this small set of commands (I am sure it needs some modification to make the integration work in another branch C):

git merge --no-commit -s ours B
git checkout B -- .
git checkout A -- .
git commit


Note: Looking back, I think I can do a better job next time and I will se if I can use the resulting repo to create a new repo and drop the svn package maintainance for wormux. If this works, I might be able to create a script to allow migration of svn-bp maintained packages to git, at least for the Debian Games Team.


Since you can't fix a problem if you don't take things one at a time, I started by cloning the initial git-svn generated repos.

So after waiting some time (both git-svn fetch commands took long enough), I had to git-svn repos:

• repo A - the package repo
• repo B - the upstream svn clone repo

I tried to clone both A and B, to avoid distroying the original A and B clones and noticed that the svn branches were not visible from the cloned repo since the origins didn't had any other local branches than master - the svn trunk for each of them. So I added tracking branches in A for the experimental and sarge versions of the package. I also added some tags in A so that the svn tags don't get lost in between.

In the end I got my A' repo that had:

0 eddy@heidi ~/usr/src/wormux/tt/debian-bare $ git br -a
debian-experimental
debian-sarge
debian-sid
* master
origin/debian-experimental
origin/debian-sarge
origin/master

Yes, and having master in A' is not a good idea, but since I made A' a bare repo I had to suffer. Well, one more thing to better in iteration 2.


Excellent, now I can go in B and add the new remote repo which is A' which I should have called pkgsvn, but I ended up call it 'origin'. Since git-svn doesn't treat the svn repo as a true remote, this was possible.



Due to some confusion I also added 'ups-' as a prefix to the svn remote trunk and tags, but I am still unsure if this was necessary - I'll have to see more clearly into the pristine-tar restrictions area.

After all of this I got this branch configuration:
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch
* master
0 eddy@heidi ~/usr/src/wormux/tt/git-full $ git branch -r
0.8-final
0.8beta4
origin/debian-experimental
origin/debian-sarge
origin/debian-sid
origin/master
ups-tags/wormux-0.7
ups-tags/wormux-0.7.2
ups-tags/wormux-0.7.3
ups-tags/wormux-0.7.4
ups-tags/wormux-0.7.9
ups-tags/wormux-0.7.9rc1
ups-tags/wormux-0.7beta3
ups-tags/wormux-0.8
ups-tags/wormux-0.8alpha1
ups-tags/wormux-0.8beta1
ups-tags/wormux-0.8beta2
ups-tags/wormux-0.8beta3
ups-tags/wormux-0.8beta4
ups-trunk
wormux-0.7
wormux-0.7.9
wormux-0.8beta1
wormux-0.8beta2

So more tracking branches were necessary; I fired 'gitk --all' and got a nice picture, after adding tracking branches for branches originating from A':


This is not yet complete and now I am feeling sleepy, so I'll continue once I experiment more.

Debian Games Team - have source, but do not import :-/

JoeyH wrote a while back some thoughts on why he hates the DGT SVN repo (mainly our policy to import just the incomplete source of packages - usually just the debian/ directory).

He updated that blog entry and latter said:

Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.

I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?

I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).


Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).


[1] I know Joey, you hate those, too

good news, bad news, such is life

After a really crazy weekend in which it looked like I wasn't able to set up NAT[1], I went to work with the gear and tested the exact same thing I did at home and it worked without a glitch.

So, now I suspect that there might be something wrong with my ISP or the DSL modem, while ritter (my NSLU2) is fine. As a bonus I just installed Debian armel on it (installation report to arrive soon).


When I got home, after the laptop came back from hibernate[2] I saw these messages on all my terminals:

Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: Uhhuh. NMI received for unknown reason b0.

Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: You have some hardware problem, likely on the PCI bus.

Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: Dazed and confused, but trying to continue

Is this a good time to panic?
I guess I'll have to dig into this, too.


In other news, svn-buildpackage 0.6.23 has been uploaded to unstable and it fixes yet another 7 bugs, which brings svn-bp's bug count down to 19 open valid bugs (2 more if you count wontfix bugs, too). This is the lowest bug count of svn-buildpackage since at least the end of April, according to the bug count graph.

Also, oolite 1.65-6 was also uploaded to unstable and fixes the breakage due to the gnustep build tools changes. Unfortunately, on arm is dep-waiting for libgnustep-base-dev which is broken on this arch.


Thanks to my sponsors, you know who you are ;-) .

[1] I have been trying to set up a simple NAT machine for more than 6 hours and, although everything seemed to be OK, checked and double checked it didn't work
[2] which works now only if I don't use fglrx which is broken from this PoV (bug 449095)

(debian) work and the silence

I've been really busy lately in RL and Debian work took the hit.

Some news:

• on the 1st of November, the compendiums on i18n.debian.net managed to waste a huge chunk of disk space and made other scripts (and itself) on churro fail miserably; now there is only a 7 days backlog of the compendiums
• oolite needs an upload due to the gnustep libs transition; I'll try to prepare tonight the long due 1.65-6 version for unstable
• wormux upstream is preparing for yet another beta which should be really close to the final 0.8 version; I wish I had more time to work on this game
• sadly, no news on the naughtysvn front :-( from me
• I have been coding now and then on svn-buildpackage 0.6.23 and I intent to make yet another drop in the bug count visible on the graph:

how did the Debian Games Team got rid of spam

How to get rid of most spam on Alioth mailing lists.

Until some Debian developer implements this idea in the BTS, the mailing list and in PTS, the quantities of spam that people get on the mail addresses they expose in the Debian world, the spam will keep on coming in huge quantities. I don't care that there will always be spam, I care that the amount of spam would be lower or probably nonexistent for one time sending (I sent just one mail to the BTS from two different mail addresses and it was enough to get huge amounts of spam on them).


The Debian Games Team's ML has suffered for a while, back in 2006, from spam bombing.
We thought that the easiest method to get rid of spam is to requires registration in order to be able to send mails to the list.

That was a big mistake because, as some people suspect, mails from the BTS needed to be allowed in and the reporters got an automated reply saying that the mail is waiting for approval, etc, etc - plain rude, people send you bug reports and you say "You are not listed, bla, bla bla". We changed the setting not to send any automatic reply and people were more content.

But still, we had to hand approve or white list valid mails/addresses. That worked for a while, but once the mail ended up on spammer lists, the thing blew out of proportions. We were desperate. We tweaked the settings of the lists in different ways, but in the end we ended up in having such a broken setup that we had to approve white listed addresses.

That did for me. I had to do something. So I started working on the ML setup and basically I did the following things to get rid of spam:

• anything coming from white listed mail addresses was approved
• black listed mails (bellsouth is one of those) is rejected (or should be)
• anything that came from the BTS (there are some nice headers that the BTS puts) and was evaluated as ham with a score of 0 (there is a field for that, too - some field has Spam=No, Score=...) was allowed
• anything that came from the BTS that was Spam=No with a score above 0 was held for moderation
• anything else is held for moderation

This solution allowed us to lighten the burden of manually white listing every email address that ever sent valid mails to the BTS and to focus only on real spam.

Try it your self on your lists, you'll be pleasantly surprised.

glest: a free 3D real time strategy game

After almost a year of working on and off on the package, glest is now in the new queue.

Glest is really a free 3D real time strategy game with amazing graphics and really interesting game play.

So maybe you're wondering why did it took me so long to package it. Well, glest is mainly developed on a Windows platform and GNU/Linux is the platform it was later ported to. So this came with some problems:

• the game uses jam as a build system; don't get me started on the intelligence of this build system; I had to go through real pain to make it build
  
• the game is entirely written with "little endian" assumtion in mind
• apparently the editor is not functional on Linux yet, but there is a patch (I will enable this later, after some testing)
• the build system was not bootstrapped before building the tarball
• the linux build creates some symlinks and I had to do some really nasty tricks so that there are no unrepresentable changes in the source
• the upstream is currently not that active, but it used to be a lot less last year; it seesm that there is a motivation/time issue with the leader of the project
  
• upstream moved the project to sourceforge and they keep the code now in subversion, but I wasn't aware about this until recently
• there are a few people talking about forks and a real fork which proclaims itself ast the real project continuation; I suspect that all this mess appeared due to inactivity of upstream last year
• the game used a non-free font
  

Since when I started the packaging work I was using a PowerBook G4 as my main machine I was upset that the game was little endian only, so I started working on a patch. I made an incomplete patch but I got stuck at some point. Time passed by and I replaced my laptop and I wasn't able to continue working on the patch. So I kind of forgot about it. Before debconf I decided is time to do the upload for little endian machines, add the endianess patch disabled.

During debconf I asked Tolimar to make an upload, and it turns out that for some reason I still don't know, the build resulted in a statically linked binary. I was amazed since I didn't recall doing any changes that might have triggered this. At some point I suspected that the build system is broken on other arches than i386 (my main machine is amd64) and halted. This until a few days ago Joey Hess added a comment in the ITP bug pointing out that the game is ok. After a couple of emails I realized that the static issue was just some strange temporary issue on my machine and now the package is in NEW.

So, that's my excuse. I hope that upstream glest issue get fixed. If not, I'll probably package glevolution, too.

The game Oolite was liberated

Yet another liberated game: Oolite, a clone of Elite.

I am the maintainer of the package; it was introduced as a non-free game in Debian, but a week ago upstream has announced that the game is now relicensed with a dual model licensing with GPL and cc-nc-sa 2.0 (the old license). Also, the change applies retroactively to the 1.65 release while further releases will be licensed GPL only and GPL/cc-nc-sa 3.0 for the code and data, respectively.

I have prepared the packages (oolite 1.65-5 and oolite-data 1.65-2) and Simon Richter agreed to make the honorary upload :-) tomorrow morning.

I hope he doesn't forget to build the packages by passing the '-sa' parameter to dpkg-buildpackage :-) and that these packages will reach Etch just in time for release.


As a bonus to this change, the game will be autobuilt on amd64, too.

(BTW, why isn't there any amd64 buildd in the non-free buildd network? Any technical reason?)

Update: the amd64 build seems that was behind in January when I installed the game on my new laptop. 1.65-4 seems that has been built a month ago, much later than the other arches.

Update: It seems that the package is on a positive trend on popularity: a constant rise in the number of oolite package installations is visible...

New laptop #2

A new laptop means more things than just new hardware.

1. I will no longer have a PowerPC machine; it has been fine, I have been spoiled by Apple hardware and design, but I also had my share of bitterness (like it or not flash is ubiquitous, wlan works on i386 hardware via ndiswrapper, wine is good enough when no free alternatives are around)
2. my father will use my current laptop in OS X; as sad as it may sound I am glad I will not have to administer the machine that much, and, like it or not, the OS X is better suited for him since he is not "that" skilled with computers
3. I can't work on powerpc/bigendian specific issues, thus, the long pending and incomplete glest big-endian support patch will have to find a new person to take care of and finish it. BTW, the glest project needs developers, the current ones are busy and can hardly do maintainance. Is a pitty, the game has incredible graphics.
4. I will be able to test the Debian Games Team's games... and I will be able to play again cursively Oolite. (BTW, Oolite should autobuild now, but it seems it hasn't been autobuilt, just the upload architecture is on version 1.65-4)