okay, i learned something today :)

you have a client behind a firewall and you have a server somewhere. and you want to ssh from the server to the client. that's exactly why ssh has a magic -R option!

if you do an

$ ssh -R 19022:localhost:22 server

that will mean that you can ssh to client:22 on the server by sshing to localhost:19022 on the server. yes, and it works even if the client is behind a firewall, yay! :)

update:

you probably want to add this to your ~/.ssh/config on the server as well:

Host client
        NoHostAuthenticationForLocalhost yes
        HostName localhost
        Port 19022

so that you can easily just type

$ ssh client

on the server

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