git-svnimport will be removed in git-1.5.4 and i don't think it's tirival to use git-svn (which is great for bi-directional work) to properly convert an svn repo (with multiple branches) to a git one, so here is a recipe.

first, just use git-svn to create a git-svn repo. it's a git repo but it's a bit weird, it contains metadata which is necessary for bi-directional operations and you won't see the branches by default when you clone it. ah and it's not a bare repo.

in this example i'll convert ooo-build's svn repo (it has several branches and tags, so it's a good example).

mkdir -p ~/git/ooo-build cd ~/git/ooo-build git svn init -s svn+ssh://svn.gnome.org/svn/ooo-build git svn fetch

this will take a while. once it's completed, you need to convert this to a bare repo:

mkdir ../ooo-build.git cd ../ooo-build.git git --bare init git config remote.origin.url ~/git/ooo-build git config remote.origin.fetch +refs/remotes/tags/*:refs/tags/* git config --add remote.origin.fetch +refs/remotes/trunk:refs/heads/master git config --add remote.origin.fetch +refs/remotes/*:refs/heads/* git fetch

and you're done! :)

of course this is an incremental operation, so all you need is to run git svn fetch and git fetch from cron to keep the mirror up to date.

update:

it turns out you can even do this by having only one git repo. it has benefints: you don't have to duplicate the object database. and it has one problem: if you later switch fully to git, then you want to remove the git-svn metadata - doing so is the easiest if you just clone the repo.

so - in case you want this, you have to:

mkdir -p ~/git/ooo-build.git cd ~/git/ooo-build.git git --bare init git --bare svn init -s svn+ssh://svn.gnome.org/svn/ooo-build git --bare svn fetch

and then you can fetch from yourself:

git config remote.origin.url . git config remote.origin.fetch +refs/remotes/tags/*:refs/tags/* git config --add remote.origin.fetch +refs/remotes/*:refs/heads/* git fetch

note: git config --add remote.origin.fetch +refs/remotes/trunk:refs/heads/master it unnecessary as git svn fetch will update this for you (it is different from git fetch)

thanks for devurandom from #git for pointing out that this is possible using git --bare init before git svn init and using git --bare svn fetch :)

it was a while ago when we registered at ohloh.net, but i recently re-visited that page, and i found some nice PR texts there ;)

Over the past twelve months, 18 developers contributed new code to Frugalware Linux.

This is a relatively large team, putting this project among the top 10% of all project teams on Ohloh.

For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 36 developers have contributed.

well, i always considered our team as a nice and good but small team, it turns out that if you count projects, we're not that small! :)

it also creates nice charts about what programming languages do we use, etc, etc. so it's a different approach, compared to cia, but it's interesting.

recently i needed to convert a cvs repo to git, in fact i'm providing a git mirror, so i need incremental updates.

here is the command i needed:

$ git cvsimport -d :pserver:anonymous@tcpflow.cvs.sourceforge.net:/cvsroot/tcpflow -C tcpflow tcpflow

yes, this will do the initial conversion and the incremental one, too. :)

tcpflow is a nice small console application to debug your network data. the usage is simple. just something like

# tcpflow -i eth0

is enough. you're recommended to start it in an empty directory :)

don't be surprised, the incoming and the outgoing connection to a server's given port will be logged to 2 different files ;)

git filter-branch is a new command in git-1.5.3 and today i met a situation where it was really useful. here is the scenario:

i have a 'vmexam' (like soxexam, "vmiklos' examples") repo, random small code chunks, every commit touches only a given subdir. after some time some projects need an own repo and i do versioned releases. this was the case with pyrssi, too

so i wanted to have a new repo with only the pyrssi-related commits and without anything else. this is exactly the case git filter-branch's subdirectory filter is for:

git filter-branch --subdirectory-filter python/cgi/pyrssi HEAD

then in the old repo i just rm -rf'd the code and i had it in the root dir of the new repo. yay! :)

so, here is the situation:

you have a machine behind a firewall and you have an ssh session to a server. and you want to send notifications to you machine. here is what i did, maybe useful for others, too

• you'll need the program called osd_cat, provided by osd
• you'll need to use ssh with the -X option
• if you run programs inside screen, you still won't know the the right DISPLAY number, so do a trick: add

  [ -n "$DISPLAY" ] && echo $DISPLAY > ~/.display

  to you ~/.bash_login

• now you're ready to use osd_cat:

  $ echo -e 'foo'|DISPLAY=cat ~/.display osd_cat --color=blue --age=4 --font=-*-helvetica-medium-r-*-*-*-320-*-*-*-*-*-* --offset=100 --align=right --indent=100

as an example, irssi has osd.pl to use osd_cat for highlight notifications :)

Priyank recently removed Beryl from -current and added Compiz Fusion. so i did a base install then i followed the instructions in xgl's README.Frugalware. a few impressions:

pros:

• i have an i810 card, not nvidia, or anything extra, it's a cheap one. the only effect that was slow for me is when i marked the cube 100% transparent. but all the other effect were really fast.
• compiz initially worked fine only with gnome. i'm a kde fan so i tried compiz with kde and it worked fine. i think this is something new
• thanks to aiglx, i did not have to - in fact - start xgl, no editing in kdm.conf or anything, just xorg.conf

cons:

• i have 4 virtual desktops like:

  1 | 2
  ----
  3 | 4

  compiz translates this to: a simple paper with two side and on each size there is another side on top of the other one. so it says it's not a cube. how crappy

• i can't select to hide windows from other virtual desktops from the taskbar. a basic feature @ kde

conclusion? it's really nice, well done - but for daily work of course i won't enable it :)

here is the problem:

you hava gpg key since 5 years. you had various mail addresses over the time and every mail address is attached to a key. so it'll look ugly, like this.

the problem is that once you pushed a uid (read: email address, attached to a key) to the keyserver, you can no longer remove it. but here is the solution: you can revoke it! :)

how to do so?

it's easy:

$ gpg --edit-key john@foo.org

a list of your ids with numbers are displayed. select a uid:

Command> uid 2

then you can revoke it:

Command> revuid 3 Really revoke this user ID? (y/N) y Please select the reason for the revocation: 0 = No reason specified 4 = User ID is no longer valid Q = Cancel (Probably you want to select 4 here) Your decision? 4 Enter an optional description; end it with an empty line: > Reason for revocation: User ID is no longer valid (No description given) Is this okay? (y/N) y

you can notice that the uid is now listed as "revoked" instead of "ultimate"

now you can exit using:

Command> save

and send it to the key server:

$ gpg --send-key 03915096

of course the uids will be still there, but that bloated list should be now short and tiny :)

maybe you know a situation that is regular for me: when testing a new wireless network - if dhcp is misconfigured, dhcpcd would just have to timeout. though - thanks to zeroconf support - it uses to pick up some ip addresses instead, making debugging hard. so here is a trick to disable zeroconf support (so that dhcpcd will just timeout):

append

dhcp_opts = -L

to your /etc/sysconfig/network/default (or other) profile for the section of the wireless interface

dht support means support for trackerless torrents

currently rtorrent does not support it, but after a bit googling, i've found this ticket. it mentions that there is a patch here. so i've split up the patch for libtorrent and rtorrent and uploaded these packages to my bmf repo.

you need to add two extra lines to your ~/.rtorrent.rc:

dht = auto
dht_port = 6986

of course the port can be anything else.

during testing, i had one "server" - where i had the test file already - and one "client" - where i had only the torrent.

i opened one port for torrent communication and one port for the dht server on the server, of course no ports were open on the client. and yes, it did work fine! :)

(screenshot)

let's hope the patch will be included in the vanilla rtorrent soon!