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!

it's a nice simple script to generate a message body for you when you have no write access to a repo and you want to request the m8r to pull from you. here is how to use it:

$ git request-pull origin/master \
vmiklos@vmiklos.dev.frugalware.org:git/pacman-g2/
The following changes since commit 52a29e40a52bb09e0db7f167712a9be3ad8d0d3c:
  Priyank (1):
        Merge branch 'master' of \
git.frugalware.org:/home/ftp/pub/other/pacman-g2/pacman-g2
are available in the git repository at:
  vmiklos@vmiklos.dev.frugalware.org:git/pacman-g2/ master
VMiklos (4):
      new NOARCH trans flag for _pacman_pkg_load()
      _pacman_pkg_load(): indentation fix
      parseargs(): new --noarch option
      tests/upgrade071.py: new test for --noarch
 lib/libpacman/package.c     |   36 +-----------------
 lib/libpacman/pacman.h      |    1 +
 pactest/tests/upgrade071.py |   10 +
 src/pacman-g2/pacman-g2.c   |    3 
 4 files changed, 33 insertions(+), 17 deletions(-)
 create mode 100644 pactest/tests/upgrade071.py

of course in real life, you want to use http:// or git:// since probably the m8r won't be be able to login to your own machine via ssh :)

after a long time, openoffice now builds again out of the box without any patches as all our fixes are in ooo-build :)

also, i recently started to re-use my "bmf" repo for packaging pre/rc versions, so it was logical to get rid of the "ooodev" repo and merge it to bmf. so openoffice.org-2.3oog680_m5-1 (alias 2.3.0rc3) is available for my bmf repo for both i686 and x86_64. compared to 2.2.x, the two notable improvements (imho) are the working mozilla plugin and the ooxml support.

thanks boobaa for building it for i686! :)

if you use rsync to copy your git repo (i mean a non-bare repo here: a repo with a working dir + a .git one), git diff will show that you touched your files. using git checkout -f can be a workaround to hide those changes, but then when you rsync again, it'll see that git thouched those files, so it'll re-download all the tracked files. infinite loop. so here is a trick from gitte: using

git update-index --refresh

the index itself will be updated, not the tracked files. this was rsync will only re-download the index which is far less time, compared to the original one :)

i've uploaded an updated mplayer package to my repo which includes dvdnav support to mplayer. at the moment it seems you need to

# pacman -R codecs

otherwise mplayer will crash

many thanks to Otvos Attila, the dvdnav patch author for his help (two additional build fixes was needed for our "enable everything what is possible" mplayer configuration)

hopefully we'll figure out soon how to resolve the conflict with the binary codecs, too :)

(a screenshot)

i think using git-svn is really easy, once you figured out how to use it. so here is how i use it. no, i'm not a git-svn expert, just a user. and the way i use it - i think it's easy. so here is our situation:

1) foo project uses svn for managing their code 2) you wish they would use git

how to do both:

1) get the full svn repo:

$ git svn clone --prefix=origin/ url

yes, in my situation this project does not use the trunk/tags/branches structure, see the git-svn manpage if the project you clone does (s/clone/clone -s/ should do the trick)

the --prefix parameter is needed so that you'll see the svn branches as if they were normal git remote branches

2) your local repo is a git repo, so you can do whatever you want, commit, revert, bisect, etc

3) instead of git pull, you need

$ git svn rebase

this does the same as git fetch + git rebase (since you can't merge because of svn)

4) instead of git push, you need

$ git svn dcommit

and we're ready. 3 and not more command, right? :)

this is always a subject of flamewars and Frugalware did not have any support for coloured manpages so far. i've now added (in man-1.6e-2) support for it, but it's still disabled. see the documentation on how to enable it if you like. you can reach a screenshot here if you use the default colors.

when we switched to git, our darcs stat page was no longer updated. now i've created gitstats, which serves the same purpose. it's written in python and it was a few more features compared to darcsstats, ie. alias support, so that the stats for a dev are not lost when he/she changes his/her email addr.

the new stat page is here. enjoy! :)