And here is one more explanation why.
P.S. At MSU, we do have a EMC storage device, and do use it with in-kernel multipath drivers. It works well.
Although official announcement is not published yet, this ftpmaster’s blog entry is a clear signal that we may start our party 
.
We have done that once again, and now the world will enjoy even better Debian than it was before!
So congratulations to everyone involved!
Those of us who use computer for some years, are aware of document file format problem. In short, it may be problematic to open a document created in environment other than you currently have.
So we all have been really excited about OpenDocument becoming an ISO standard. We believed that documents created in ODF-conforming text processor will be opened by other ODF-conforming text processor without issues.
However, let’s see how that works in practice.
Here is a very simple
Nothing special. Just created new document, selected Text Body style, pressed bullet button, entered some text, pressed Enter, pressed backspace to get rid of bullet button on the second line (it’s an easy method to get second text paragraph corresponding to the same bullet item), enter some text, press enter. Then repeat all that second time.
This used to work in all versions of OpenOffice.org since the beginning. As well as in Micro$oft office software.
And here is how it looks when opened in OpenOffice.org version 2.4, from debian lenny:
You see, spacing is broken. This is exactly same problem we had with old text processors using non-standard file formats!
I may understand that newer version of OpenOffice.org contains new features, and not everything that it supports could be correctly imported in older version. However, document in question is very simple, and formatting it uses has been supported from the beginning! WTF? Perhaps all those talks abouth standard document format eliminating document import/export problems are just noice? Bad.
P.S. Just tried the reverse – create the same document in OOo2, then open in OOo3. Result was better – no visible difference. So at least if we only switch to later versions, we don’t get broken documents. Still bad, but not that bad.
Update: there was a reply on debian-openoffice mailing list stating that it is a somewhat known bug with OOo 2.4 being not ODF-conforming regarding bullets. Well, fixing bugs is good. However, there will always be bugs, and if fixes are going to break compatibility between text processors and document files, we are returning to the original situation. Still not good 
.
I’ve mentioned git add --patch recently.
I’ve used it for some time, and found that it is even more cool than I thought. Not only it allows to select particular file changes to add into commit (while not adding other changes in the same file). It also allows to edit those changes in-place!
Say, you added some debugging code. You want to keep it, but not enabled by default, so you made it #ifdef-ed. And ant the top of your file, you added something like
/* Define this to get debug messages */ #define EXTRA_DEBUG_MESSAGES
You have this in your working directory, but in the commit that adds it, you want #undef instead of #define. Because addition of extra debugging messages is a single logical change that should become a commit, while enabling/disabling those is somewhat that you do in your working directory, and that has zero reasons to be stored in project’s history.
And git add --patch allows exactly that! When it asks what to do with a particular hunk, one of your choices is “edit”. If you choose that, a editor is fired up containing the hunk in diff -u format. Not all edits are safe, but lines marked as + may be changed or deleted. If you delete a line, you don’t need to change the top line containing line numbers – just leave it untouched, git add --patch will do the magic. If you do an unsave change, git add --patch will inform you and give you a chance to recover.
So you can change #define to #undef, or fix a just-noticed typo, or choose not to add something into this commit.
With such a tool available, is there any single reason left not to follow “commit per logical change” policy?
There are some masochists around still using subversion. If you have to deal with their work somehow, your must-use tool is git-svn. This is a bidirecteral gateway between git and svn – it allows you to fetch entire svn repositories into your git repositories, then enjoy working with git, and later push your changes back to original svn repositories if needed.
Although there is some fine documentation on using git-svn, I still think the below tips may be useful for someone who just needs to set up import, and then forget that svn exists. Like in a common debian-packaging case.
The below example presents details on importing eina component of enlightenment svn repository into debian pkg-e team’s git repositoriy at alioth.debian.org.
Doing initial import
Better to do initial import into a local git repository, and not directly to repository on server, to avoid breakages if things go wrong.
- Cd to the local repo directory (either an empty repo created by git init, or to repo that already contains previous packaging work).
- If repo is a bare repo (i.e. git data is in the repo directory itself,
not in .git/), set GIT_DIR environment variable to point to the repo directory. Without this hint, git-svn can’t work with bare repos. - Initialize git-svn:
git svn init --trunk=trunk/eina http://svn.enlightenment.org/svn/e
The git-svn init command line tells git-svn where svn repository is, and what part of it should be fetched. Documentation has some details.
- By default, git-svn does not prefix remote git branches that it creates with svn/, which is ugly, especially when you have other (non-svn) remote repos tracked in your local repo. Better to fix that before initial import. To do that, change the value of git config svn-remote.svn.fetch:
$ git config svn-remote.svn.fetch trunk/eina:refs/remotes/trunk $ git config svn-remote.svn.fetch trunk/eina:refs/remotes/svn/trunk $ git config svn-remote.svn.fetch trunk/eina:refs/remotes/svn/trunk
You may edit .git/config file directly as well.
- Do the import:
git svn fetch
First run of this command may be extremely slow (several hours, even days on slow connection) and traffic-hungry, since it will fetch entire svn history. Later updates will be fast.
Once these steps are completed, you have entire svn history in your git repo, so you may browse it using gitk, branch from whatever point, or push it to another git repo. More on this below.
To fetch svn updates into your repo, just run git svn fetch periodically.
Moving git-svn import to another repo
Once svn import is done into your local repo, svn/* branches may be pushed to another repo in the same way as any other git branches.
However, to make git-svn working on remote repo (without redoing time- and traffic-consuming initial import there), two additional steps are required.
Before pushing, login into remote server, cd to the repo there and/or set GIT_DIR environment variable, and initialize git-svn using exactly same git-svn init command line as you did on your initial import. Also do exactly same svn-remote.svn.fetch adjustment.
Then do the push:
git push ssh://alioth.debian.org/git/pkg-e/libs/eina.git refs/remotes/svn/*:refs/remotes/svn/*
In your setup, remote repository location will be likely different, but refspec should be the same.
Once import completed, login into server, cd to the repo there and/or set GIT_DIR environment variable, and run git svn fetch once, to make it rebuild it’s metadata. Git-svn stores needed info inside log messages of the imported commits, so metadata rebuild is a local operation and runs fast.
Now git-svn may be used on the remote server.
Warning: git-svn does not like when it’s branches are updated by other git commands. So don’t mix updates of those branches with git fetch and with git svn fetch – choose one of these two and use only that. If you have ocasionally updated svn/* branch from remote git repo with git fetch, you may restore git-svn functionality by removing git-svn metadata (stored in hidden files in branch directories under .git/svn/) and running git svn fetch to restore it. If that does not help, it is possible to remove all tracks of git-svn from local repo (.git/svn directory and svn-related sections in .git/config), and then move things from remote repo to local repo, exactly as described above, but in the reverse direction. Git is smart enough not to copy objects that are already in your repo, so this is even faster than you could think .
Setting up auto-import
Once git-svn import is on server, it is easy to set up auto-import, such that server will have a (non-remote) git branch that follows svn trunk.
We do it by having an hourly cron job on server, that runs something like
export GIT_DIR=/git/pkg-e/libs/eina.git git svn fetch if ! git push $GIT_DIR refs/remotes/svn/trunk:upstream-vcs; then git branch -D upstream-vcs git branch upstream-vcs svn/trunk fi
Normally, it just fetches updates from svn, and fast-forwards local upstream-vcs branch with the fresh fetch. But if fast-forward fails (which may happen if someone occasionally changes upstream-vcs branch), then branch is deleted and re-created at current svn/trunk point. (This “rude way” is only executed in problem case, not always, to avoid having a window when upstream-vcs branch does not exist.)
Once this thing is set up, we no longer care that upstream is using svn. We have all their updates in our git. And that is cool.
Ubuntu – ancient African word meaning “I can not install Debian”.
From someone’s signature.
So we got that once again. Thousands of people got offline, because they do not want to use braindead official ICQ clients, while ICQ does not want to service anything better.
Maybe enough is enough?
There is an internet standard on instant messaging, called jabber.
Most likely, you already have both jabber account and jabber client.
You are unaware that you already have a jabber account? Well, at least you have one if you are registered at either Google Mail or LiveJournal. Yes, both Google Talk and LJTalk are actually implementations of jabber. If you don’t use these services, you may get an account on some jabber server – here is a list. Or you may run your own server.
You are unaware that you already have a jabber client? Well, at least if you are using Miranda, or QIP, or Pidgin, or Kopete – you do. All those do include jabber support. As well as many other instant messaging programs.
Or are you using ICQ because your contacts do? Well… not so long ago I’ve seen a very funny situation. Two technical persons working for different companies had to exchange some technical documents. Both perons have been used to Open Office and preferred to use that excellent package, and it’s standard OpenDocument format. However, both converted the document to Microsoft’s .doc, suffering a lot from formatting breakages, just to make it readable for the other side.
You guess the analogy?
Your contacts still use ICQ (if they really do) for only one reason – because you still use it. Similar to you using ICQ because they do. So just break the chain! For a short period when somebody will talk with you over ICQ, a jabber-to-icq transport will do the job. The above server list mentions some.
You don’t need ICQ. Nobody does. So just stop it. Now. And forever. You will make the world better by that simple step!
Are you aware of git add --patch? If not yet, here is a must-read article.
As a side note, adding gitready.com to your feed reader could be a good idea.
After switching my home systems from ru_RU.KOI8-R to ru_RU.UTF-8 locale, I suddenly found that I can’t read russian file names in CDs from my video collection. Tried to play with iocharset mount option, but with zero result.
After a hint from a helpful person, I found that I have to mount with -o norock,utf8 to see russian filenames.
Don’t know what sort of breakage it is. Probably I did something wrong when writing the CDs (more than 5 years ago, using cdrecord from command line).
To make KDE+HAL to mount CDs with -o norock, I had to add a line for /dev/scd0 to /etc/fstab.
When you use perl or similar scripting language, and use variable to store command-line parameter, and then test that variable to check if parameter was passed or not, beware of
if ($param) {
... #param was passed
}
Think what happens if $param is “0″ string. And use if (defined($param)) instead.
That happened to be the reason why dpkg-buildpackage ignored -v0 flag. And when you discover that through pdebuild that does not process --debbuildopts “-sa -v0″ properly, you will first think that pdebuild once again has issues with passing multiple arguments to underlying tools, and spend your time looking in wrong direction…
english
русский