Posted on September 26th, 2007
Ich hatte mich schon immer gefragt, ob man bei cp oder mv nicht auch eine Fortschrittsanzeige einbauen könnte. In den famosen Gentoo Foren bin ich dann tatsächlich fündig geworden. Die Patches waren in einigen Versionen der coreutils enthalten, allerdings auf Dauer nicht von den Upstream Maintainern geduldet worden.
I have mixed feelings about progress bars. I do like the progress bars in rsync, but am reluctant to embed such functionality in fundamental programs like cp and mv. I’d like to avoid adding any unnecessary complexity. When having a progress bar is important, can you use rsync?
Jim Meyering
Hm. Ist ein Wort. Kann man so sehen, muss man aber nicht. Die Patches werden nach wie vor gepflegt, also patchen wir uns selbst. Mit Gentoo und ein wenig Geschick sind wir in ein paar Sekunden damit durch und können etwa 9 Minuten später ein leuchtendes coreutils in unserem System wissen.
$ emerge -v coreutils
Genau wenn es heisst:
* Done with patching
STRG+Z drücken!
Das legt emerge in den Hintergrund und wir können den Patch an Portage vorbei in den Code schummeln. Am besten ihr macht ab coreutils- mit tab completion weiter um die richtige Version zu finden.
cd /var/tmp/portage/sys-apps/coreutils-6.9-r1/work/coreutils-6.9/
wget http://dev.gentoo.org/~vapier/dist/coreutils-6.9-patches-1.2.tar.bz2
tar -xjf coreutils-6.9-patches-1.2.tar.bz2
Wir brauchen nur den progress-bar Patch, nach dem Patchen holen wir emerge mit fg zurück.
patch -p1 < patch/generic/001_all_coreutils-gen-progress-bar.patch
fg
Von nun an zeigen cp und mv mit der -g Option zusätzlich Fortschritt in Prozent, Grösse der Datei, Übertragungsgeschwindigkeit und verbleibende Dauer an. Ein Alias in der .zshrc (oder .bashrc) macht sich bei mir ganz gut.
cp -g /mnt/etcbackup.zip ~/temp
etcbackup.zip | 1% | 175 MiB | 122 KiB/s | ETA 00:24.03
Wie man den Patch auf Ubuntu/Debian einbaut steht übrigens in den Ubuntu Foren.
Posted on August 28th, 2007
Wir sind gerade dabei, auf unserer wootstube eine Versionskontrolle mit git einzurichten. Eigentlich wollten wir ja Subversion einsetzen und eigentlich ist das ja für unsere Entwicklungsprojekte gedacht. Aber weil der Linus sagt, dass Subversion scheisse und git so viel toller ist habe ich es mir einfach mal angeschaut und bin dabei auf einen ganz netten Nebeneffekt gestossen: die Möglichkeit, Konfigurationen über meine Boxen ohne viel Aufwand zu synchronisieren. So habe ich jetzt zum Beispiel auf Server, Workstation und Notebook immer dieselben Configs.
Ich versuche das im Folgenden ein wenig zu dokumentieren. Dieser Walkthrough eignet sich nämlich prima, um die ersten Umgangsformen von git zu verstehen. Übrigens, ich arbeite hauptsächlich mit gentoo. Auf debian heisst das git Paket git-core und die apache vhosts organisiert sowieso jeder auf seine eigene Art & Weise. Der Rest sollte ziemlich gleich sein.
SERVER-SIDE [+]
# git und gitweb für die Weboberfläche installieren
USE="-vhosts" emerge -av dev-utils/git gitweb
# ins Verzeichnis der apache vhosts wechseln
cd /etc/apache2/vhosts.d/
# neue vhost anlegen
cat > git.conf << EOF
<VirtualHost DEINE_IP:80>
ServerName git.DEINE_DOMAIN.de
DocumentRoot /var/www/localhost/htdocs/gitweb/
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ \
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
SetEnv GITWEB_CONFIG /etc/gitweb.conf
<Directory '/var/www/localhost/htdocs/gitweb/'>
Options FollowSymLinks -SymLinksIfOwnerMatch Indexes +MultiViews
Order allow,deny
Allow from all
AllowOverride None
</Directory>
</VirtualHost>
EOF
# in Standard cgi Verzeichnis springen
cd /var/www/localhost/cgi-bin
# symlink für gitweb script anlegen (damit es durch portage aktualisiert werden kann)
ln -s ../htdocs/gitweb.cgi
# neue vhost laden
/etc/apache2 reload
# Verzeichnisse für git und User Verzeichnis anlegen
mkdir -p /var/git/jesse
# User Berechtigungen geben
chown -R jesse.users /var/git/jesse
# Von jetzt an machen wir als User weiter
su jesse
# Wir stellen uns git vor (sind ja höflich)
git config --global user.name "jesse keys"
git config --global user.email jesse@teranetworks.de"
# Wir springen in unser Verzeichnis
cd /var/git/jesse
# Und initialisieren darin unser Repository
git init
# Jetzt können wir auch schon mit ner dummy Datei testen:
echo "bar" > foo
# git tracks content, not files: jede zu verfolgende Datei muss git erst
# gezeigt werden (alternativ mit "git add ." alle Dateien im Verzeichnis)
git add foo
# Neue Datei mit Kommentar ins Repository übertragen
git commit -a -m "inital commit for my repo"
CLIENT-SIDE [+]
# Wir brauchen das git Paket natürlich auch
emerge -av dev-utils/git
# Danach arbeiten als User
su jesse
cd ~
# Wir stellen uns git vor
git config --global user.email "jesse@teranetworks.de"
git config --global user.name "jesse keys"
# Jetzt wirds interessant: wir holen uns das Repository vom Server
# und packen es in ~/myrepo
git clone git+ssh://geekosphere.org/var/git/jesse myrepo
cd myrepo
# Wir legen eine Testdatei an
echo "bar" >> foo
commit -a -m "woot, i changed it"
# Und schicken sie wieder zurück ins Repository
git push
# Das wars schon mit dem rudimentären git Zauber!
# Wenn wir die *Dateien* auf dem Server aktualisieren wollen müssen wir
# dort übrigens ein "git checkout -f" in /var/git/jesse ausführen
# Anhand der .zshrc zeige ich jetzt, wie man damit die Configs verwaltet:
# Wir gehen ins Home Verzeichnis
cd ~
# Verschieben die zshrc in das Repo
mv .zshrc myrepo/
# Und legen einen Symlink
ln -s myrepo/.zshrc
# Nicht vergessen, git die neue Datei vorzustellen
cd myrepo
git add .zshrc
# Brav committen
git commit -a -m "yay, teh zshrc"
# Und ab damit auf den Server
git push
# Haben wir von einem anderen PC aus Änderungen durchgeführt
# aktualisieren wir unsere lokale Kopie:
git pull
Eigentlich recht simpel, meiner Meinung nach aber echt genial. Hast Du toll gemacht, lieber Linus :)
Und hier findet ihr noch ein paar zusammengetragene Links zu Dokumentationen und Tutorials. Viel Spass!
Posted on July 21st, 2007
Just read about this in the new
Gentoo Linux Newsletter:
One can use genlop (0.30.7+) to estimate the time of an upcoming compile job now even if if a package has never been compiled on the system before. Just add the -q option which makes genlop query a database running on gentoo.linuxhowtos.org for compile times. The data is based on users with identical CPUs and it’s quite accurate since it calculates the average time.
Just give it a try with, e.g.: $ emerge -uDNpv world | genlop -p -q
If you didn’t know about genlop, emerge it with $ emerge -av app-portage/genlop
I usually use genlop to get the estimated time left when running a system update.
$ while genlop -c; do sleep 5; done
gives an output like
Currently merging 1 out of 6
* sys-libs/pam-0.99.8.0-r2
current merge time: 24 seconds.
ETA: 1 minute and 24 seconds.
Have fun :)
Gerade im aktuellen
Gentoo Linux Newsletter gelesen:
Seit Version 0.30.7 kann genlop die vorraussichtliche Kompilierzeit für einen Job berechnen, selbst wenn manche Pakete noch nie zuvor emerged worden sind. Mit der Option -q fragt es eine Datenbank auf gentoo.linuxhowtos.org ab und errechnet aus Zeiten von Leuten mit identischen CPUs einen Durchschnitt.
Versuchs einfach mal mit: $ emerge -uDNpv world | genlop -p -q
Falls Du genlop noch nicht kanntest installier es einfach mal mit: $ emerge -av app-portage/genlop
Ich habe es bisher immer verwendet, um zu schauen, wie lange ein laufendes Update/Kompilieren noch dauern wird.
$ while genlop -c; do sleep 5; done
gibt dann in etwa eine solche Ausgabe:
Currently merging 1 out of 6
* sys-libs/pam-0.99.8.0-r2
current merge time: 24 seconds.
ETA: 1 minute and 24 seconds.
Viel Spass damit :)
Posted on May 8th, 2007
The new gentoo version 2007.0 with the codename “Secret Sauce” was released yesterday. According to gentoo.org the delay of the release was due to security vulnerabilities of some large packages. The new gentoo version features a completely rewritten installer for AMD64 and x86 architectures.
To get an impression of the new features for your architecture (e.g. Emulation on AMD64) check out the official press release notes. You may download it here.