Now in dpkg I found this:
Homebank has had a few problems getting through NEW due to legacy problems from the original Amiga version (and it isn't ready yet) but I've been trying it out anyway and comparing to gnucash. Bearing in mind that I have done upstream work in gnucash (i.e. I like gnucash enough to tackle the massively scary gnucash source code) and have (almost) got used to the regular dependency hell that it imposes on my sid installation, I'm finding homebank quite friendly.
Last week, Rapha l Hertzog mentioned a transition in progress that
was going to change the way that Planet Debian updates. As part of
the plan to deprecate cvs.debian.org, Rapha l helped me move Planet
Debian away from the old CVS repository and to a new Subversion
repository in Alioth.
Readers of Planet Debian should not notice any differences.
When it comes time to change or disable a feed, contributors to planet
Debian will have to update their feed slightly differently.
Documentation on how the new method is now in the wiki and at
gluck:/org/planet.debian.org/README.
As Rapha l mentioned, all Debian Developers have write access to the
configuration file in the Subversion repository through their Alioth
accounts. Unlike the old setup, non-DD's who have blogs in Planet can
have write access to it as well, but they'll need to have an Alioth
account and they'll need to be added to the ACL by me. As before, it's
only OK to modify one's one feed and anyone who violates this in bad
faith will have their privileges to the repository removed.
The old CVS repository remains crudely broken. Please help update any
references to the old CVS-based method or alert me to documentation
that's public and out of date that you don't have access to change
yourself.
Continuing my mission to put together a kick-ass team to develop the Ubuntu Desktop, the following position is now up on the website:
Posting Date & ID: September 2007 UDD
I'm sitting here at XDS,
and John Bridgman and Matthew Tippett are announcing AMD's open source plans.
In three words: 'specifications without NDA'. 2D very soon, 3D coming when
the legal issues have been taken care of. Specs for the r3xx core will
probably be coming later on down the track.
Biella blogged about King of
Kong, a movie about classic video games. I also enjoyed it, although I
felt the rivalry and competition cheapened it (while also certianly
giving it more of a story to tell).
I wish I could enjoy competition the way Bubulle so eloquently
describes. For me
though, getting to the end of a game is more like raching the end of a long
hike, whether you beat someone to the end or not doesn't matter, it's the
personal experience of getting there that counts. Anyway..
The reason I'm really responding to Biella's post is because of the question
she asks:
But what I also found amazing was how the movie conveyed the persistence of the (older) game. They live on in the lives of individuals and collectives, despite the rise of a whole, new class of games that are much more popular today. I am not sure how much longer they will live on, or if the movie was also inadvertently portraying the rise and slow decline of an era that will, in another 50 years, become part of the archive of dead history.My guess is that the classic games will persist past the lifetime of their hardware, and that they'll keep on appealing to at least a small percentage of new gamers. Actually, I think they're more popular now than they were fifteen years ago, partly because the commercial gaming industry has moved further away from what the old games are really good at, and partly because emulation is so good that they're available to everyone. And maybe even partly because to really appreciate Kenta Cho's games or many of the other new non-commercial games that Miriam keeps finding and pushing into Debian, you need to know the classics. Even if you do suck at galaga, and even if the only version you've really played is xgalaga, which lacks ship capture. :-) I never played games in machines that ate quarters as a kid, because I didn't have many quarters, and it didn't seem to be a good value. I put one of the few quarters I've ever spent into a video game machine earlier this summer, in the corner of the Mus e M canique that's dedicated to sorta-old video machines (as opposed to ancient, lovingly restored arcade games). It was a metal slug machine. I've beat metal slug under emulation, but only at the expense of many emulated quarters. Another quarter went into vintage game of pong. I enjoyed playing them both on real hardware, but emulation was good enough for both of these and for many other games in between.
Due to popular demand, there is now a new version of mISDN in experimental. The usual warning applies: it will break your system, it will not work out of the box and whatever you do to make it not Oops your kernel during boot will probably no longer work with the next upload. YMMV. HTH. HAND.
You are demanding an explanation? Well, there are a few problems with this package that are not trivial to solve. The most visible of them is that it provides drivers for a bunch of ISDN cards that are also supported by the mainline kernel. The hotplug subsystem handles this situation totally gracefully and simply loads all of them. Now if that wasn't nasty enough by itself, mISDN also wants to set up the entire stack when a hardware driver is loaded. All the modules that aren't there at this point are replaced by NULL pointers. As there is no formal dependency on the modules providing layers 1-3, I invite you to guess the stability of your kernel at this point.
Upstream has an init script that parses XML files.
I sadly read that Warsow are having internal problems. It’s a pity, because it’s a great free game (even with its non-free game data), and they deserve the best. In any case, I just wanted to talk about this because of something that’s quite usual in the development of free games: having non-licensed data.
According to tigerchas’ note: “The non-licensed state of warsow media is what has allowed this to happen - and the team is now working on rectifying this. This whole episode has been very unsatisfying and has highlighted the problems of not having a global media license for warsow”.
I’m not worried about the future of the game at all, it’s not that the reason I’m writing this entry. As they also say in the same post: “Don’t let this announcement affect you too much, warsownians. warsow has hit minor stumbling blocks in the past and this is simply another. Maps can come and go. Rest assured that the current mapping team will be working on other great maps for you to enjoy”.
What I wanted to point out with all this, especially to games developers and teams, is that even when licenses are boring stuff and many of you might think that you can safely ignore them and it won’t affect you, especially when you start the development, reality shows that these things happen.
I wish all the best for the Warsow team anyway, and to go soon over this. Keep up the good work! 
OK, gpe-bluetooth updated and migrated to unstable from experimental.
Today was the day we had tickets for *the* match of the
day between South Africa and Samoa (59-7).
Of course, the Springboks won this game after the Samoan players were
exhausted of their battle after 60th minute.
However, we really enjoyed a great game during 1st half (21-7) with solid
play by RSA (without great vista, as usual, but, well, I'm not a Springboks
fan) and ultra-solid defense by Samoa.
And, well, as long as the Samoans have the ball in their hands, everything
can happen, especially with Henry Tuilagi, impressive number 8, which has
been acclaimed by the Parc des Princes public when finally quitting the
game on 60th minute.
Three great moments in the game:
I spent much of my early childhood at the video arcade. I was fortunate enough to have a best friend who 1) Lived in the old quarters of San Juan where you could walk everywhere 2) Had three older teenage sisters who would take us when we were still quite young to the arcade, which also doubled as a fantastic ice-cream parlor.
My favorite game there was galaga, and I played it incessantly (and had to use a foot stool too!!) As a result of all that childhood gaming, I am still pretty half decent at it. For example, I more often than not beat my partner (except under less than auspicious conditions, like being sleep deprived), which is pretty unbelievable as he is much more of a video game wizard than I and otherwise beats me in everything.
So they say.
That's the question I'm trying to solve right now. From
wide range of cameras, I reduced to this choice, but the decision
is now quite hard. Both have their advantages and disadvantages and
there is not easy to choose as it was to cut down previous list.
I used Google a lot in last weeks to find some experiences with both
cameras, but none of them really helped me.
Pentax pros:
source package name => binary package name, but with appended '-build-depends'
Build-Depends => Depends
Build-Depends-Indep => Recommends
Build-Conflicts => Conflicts
Binary => Suggests
Binary => Provides (with appended '-build-depends')
If any of the Build-Depends fields contains arch limiters, arch-dependent packages will be
created, otherwise one arch-independent package.
This allows easy installation of build-depends by installing the corresponding meta package,
tracking them, and removing them automatically in case you deinstall the meta package. It only
works for known architectures though and it requires creating around 60,000 binary packages.
It also doesn't allow tracking build-dependencies for more than one version of a package (e.g.
unstable and experimental).
You can use this by adding something like
deb http://sourcedeps.debian.net/ sid main contrib non-freeto your
sources.list. The archive is signed with the following key, available from
a keyserver near you and signed by me:
pub 1024D/ED505694 2007-09-08 [expires: 2008-09-07]
Key fingerprint = 4ECF DF07 F419 0B5B 45C4 51D0 00E9 C47B ED50 5694
uid SourceDeps.Debian.Net Archive Key
Comments welcome.
With the last git release, git-rebase gained a new option: --interactive.
If you already had the feeling that in a patch series of yours you should have ordered patches differently, or merged some, then this command is what you dreamed of. Here is how it works
Let's pretend you want to rework your last 10 patches, you'll run:
$ git rebase -i HEAD~10It will launch your
$EDITOR and you'll see something like:
# Rebasing 16d3800..14f3d11 onto 16d3800 # # Commands: # pick = use commit # edit = use commit, but stop for amending # squash = use commit, but meld into previous commit # # If you remove a line here THAT COMMIT WILL BE LOST. # pick 6270640 Simplify write_tree using strbuf's. pick 27c528a Further strbuf re-engineering. pick fd82c9a Eradicate yet-another-buffer implementation in buitin-rerere.c pick eee488f More strbuf uses in cache-tree.c. pick 16878b5 Add strbuf_rtrim and strbuf_insert. pick e9081af Change semantics of interpolate to work like snprintf. pick 99c3ef5 Rework pretty_print_commit to use strbufs instead of custom buffers. pick 203db5d Use strbuf_read in builtin-fetch-tool.c. pick a20d939 Use strbufs to in read_message (imap-send.c), custom buffer--. pick 14f3d11 Replace all read_fd use with strbuf_read, and get rid of it. ~ ~ ~ ~ ~ ~[1]Then you can rewrite "
pick" into "edit" if you want to change something in a commit, or "squash" if you want to merge it with the one from the line before.
What the small help doesn't say is that you can actually reorder your commits, and it will do what you expect it to do. I used it 10 minutes ago, because I have this string buffer module I extend on a regular basis, I squashed every API extension of that module in one commit using that.
Each time one change needs you to edit anything because either you asked for it, or that one of the change you asked for generated a conflict, then as usual the rebase will stop. You will be prompted to make the change, or fix the conflict, or merge comments (in case of a squash), and when all is in order, you just need to:
$ git rebase --continueThis is just awsomely simple and intuitive
$EDITOR sucks btwNext.