Whenever I had tried out the devtools I had these issues:
- I always set a certain pkgdest in makepkg.conf. So (old and) new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that.
- As I only have poor bandwidth and like to keep working while down-/uploading I want to have a bandwidth-limit option for filetransfer. At least for uploading. Afaik the scripts use scp. Man scp tells me there's -l limit - Limits the used bandwidth, specified in Kbit/s.
Yes I like the idea to "force" all devs using devtools to reduce unneeded mistakes and issues. Forcing us with an integrated namcap run is something I would like to see. But we should still be able to do everything by hand. There always might appear some reason why the tools get broken and we need to fix something manually.
Andy
On 9/28/07, Andreas Radke a.radke@arcor.de wrote:
Whenever I had tried out the devtools I had these issues:
- I always set a certain pkgdest in makepkg.conf. So (old and)
new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that.
I *think* Thomas may have fixed this recently, but I will check. It's definitely very easy to fix if not.
- As I only have poor bandwidth and like to keep working while
down-/uploading I want to have a bandwidth-limit option for filetransfer. At least for uploading. Afaik the scripts use scp. Man scp tells me there's -l limit - Limits the used bandwidth, specified in Kbit/s.
Would adding the same argument (-l) to devtools that passes it to scp work for you?
Yes I like the idea to "force" all devs using devtools to reduce unneeded mistakes and issues. Forcing us with an integrated namcap run is something I would like to see. But we should still be able to do everything by hand. There always might appear some reason why the tools get broken and we need to fix something manually.
I agree, too, but that shouldn't be the common case, it should be the exception.
And even then, we need to make sure people are notified as to WHY the tools weren't used. For instance, the above cases. They are both very very easy to fix (around 15 minutes of work). If you would have let us know this.... a year ago, it would have been fixed.
On Fri, 28 Sep 2007, Aaron Griffin wrote:
On 9/28/07, Andreas Radke a.radke@arcor.de wrote:
Whenever I had tried out the devtools I had these issues:
- I always set a certain pkgdest in makepkg.conf. So (old and)
new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that.
I *think* Thomas may have fixed this recently, but I will check. It's definitely very easy to fix if not.
Now that I think about it, there another problem with checkpkg. It doesn't work when you use a server that requires a username/password, such as gerolde, for your repo in pacman.conf. The username/password gets stripped from the url by the script and, not surprisingly, you are denied access from the server.
On 9/28/07, Eric Belanger belanger@astro.umontreal.ca wrote:
Now that I think about it, there another problem with checkpkg. It doesn't work when you use a server that requires a username/password, such as gerolde, for your repo in pacman.conf. The username/password gets stripped from the url by the script and, not surprisingly, you are denied access from the server.
Do you mean when it downloads the packages? That should be fixable, but not as quick as the other two.
On Fri, 28 Sep 2007, Aaron Griffin wrote:
On 9/28/07, Eric Belanger belanger@astro.umontreal.ca wrote:
Now that I think about it, there another problem with checkpkg. It doesn't work when you use a server that requires a username/password, such as gerolde, for your repo in pacman.conf. The username/password gets stripped from the url by the script and, not surprisingly, you are denied access from the server.
Do you mean when it downloads the packages? That should be fixable, but not as quick as the other two.
Yes, it fails to download the current package in the repo in order to make the comparision with the new one.
Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.
http://projects.archlinux.org/git/?p=devtools.git;a=summary
Andy, could you try those scripts there and see if they suit your needs?
On 9/28/07, Eric Belanger belanger@astro.umontreal.ca wrote:
Yes, it fails to download the current package in the repo in order to make the comparision with the new one.
Sadly, this one is harder. The package URL is grabbed directly from pacman, and pacman doesn't output the user:pass for that.
So, there's two things here: a) You should be fine without specifying the user/pass for gerolde. b) Could you log a pacman bug about username:passwords from URLs? There's a potential security issue with outputting URLs like that so I want to make sure we fully discuss it.
Thanks guys, Aaron
On Mon, Oct 01, 2007 at 11:40:11PM -0500, Aaron Griffin wrote:
Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.
Hey thanks guys. I too struggled with git-svn, you guys just happened to triumph.
I'll remove the devtools svn in favour of the git project (once we release a new package and update the references).
Jason
On 10/2/07, Jason Chu jason@archlinux.org wrote:
On Mon, Oct 01, 2007 at 11:40:11PM -0500, Aaron Griffin wrote:
Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.
Hey thanks guys. I too struggled with git-svn, you guys just happened to triumph.
*we* didn't - Dan did. It seemed kinda hard though. I could only get about 13 revisions before it crapped out due to missing dirs or repos or something like that (pacbuild, srcpac, etc) - I'm not entirely sure what the deal was - probably multi-project commits it couldn't rationalize.
Looks like Dan actually used git-svn instead of git-svnimport, and then had to do some monkeying with some of the data.
I'll remove the devtools svn in favour of the git project (once we release a new package and update the references).
Yeah. I didn't know the devtools PKGBUILD used an svn pull - we should probably push a real tarball up to the ftp dirs like we do with pacman.
I'll remove the devtools svn in favour of the git project (once we release a new package and update the references).
Yeah. I didn't know the devtools PKGBUILD used an svn pull - we should probably push a real tarball up to the ftp dirs like we do with pacman.
That sounds like an excellent idea. At this point I don't know what's needed with devtools to make a new release. Can everyone who cares make a comment on anything they want in devtools? I'll start evaluating when I can make a new release.
Jason
Jason Chu schrieb:
At this point I don't know what's needed with devtools to make a new release. Can everyone who cares make a comment on anything they want in devtools? I'll start evaluating when I can make a new release.
You should include that one, as well as the patches from Archlinux CVS. http://archlinux.org/pipermail/arch-dev-public/2007-September/001831.html
On 10/2/07, Thomas Bächler thomas@archlinux.org wrote:
Jason Chu schrieb:
At this point I don't know what's needed with devtools to make a new release. Can everyone who cares make a comment on anything they want in devtools? I'll start evaluating when I can make a new release.
You should include that one, as well as the patches from Archlinux CVS. http://archlinux.org/pipermail/arch-dev-public/2007-September/001831.html
http://projects.archlinux.org/git/?p=devtools.git;a=summary
I think we got most of that in there last night. Let us know what is missing.
-Dan
On Mon, 1 Oct 2007, Aaron Griffin wrote:
Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.
http://projects.archlinux.org/git/?p=devtools.git;a=summary
Andy, could you try those scripts there and see if they suit your needs?
On 9/28/07, Eric Belanger belanger@astro.umontreal.ca wrote:
Yes, it fails to download the current package in the repo in order to make the comparision with the new one.
Sadly, this one is harder. The package URL is grabbed directly from pacman, and pacman doesn't output the user:pass for that.
So, there's two things here: a) You should be fine without specifying the user/pass for gerolde. b) Could you log a pacman bug about username:passwords from URLs? There's a potential security issue with outputting URLs like that so I want to make sure we fully discuss it.
a) doesn't work. See "ftp service on gerolde" thread.
b) I haven't submitted the bug report yet. Maybe it would be safer and easier to have a configure option or a config file for checkpkg to specify the server to be used by it.
Eric
On 10/2/07, Eric Belanger belanger@astro.umontreal.ca wrote:
b) I haven't submitted the bug report yet. Maybe it would be safer and easier to have a configure option or a config file for checkpkg to specify the server to be used by it.
Hmmm this is a good point. I will think about ways around this specific to checkpkg and not pacman, necessarily
On 10/1/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
Ok, Dan and I cracked this out, after struggling with the git svn stuff for a bit.
http://projects.archlinux.org/git/?p=devtools.git;a=summary
Andy, could you try those scripts there and see if they suit your needs?
Ping? We made these changes - could you respond and let us know if they work for you or not?
On Wed, 3 Oct 2007 12:42:33 -0500 "Aaron Griffin" aaronmgriffin@gmail.com wrote:
Ping? We made these changes - could you respond and let us know if they work for you or not?
Tried the new devtools from git, but following error appears:
---snip---- [ise@fuckup-ng mp3blaster]$ extrapkg daniel@archlinux.org's password: mp3blaster-3.2.3-3-i686.pkg.tar.gz 100% 218KB 54.5KB/s 00:04 daniel@archlinux.org's password: md5sum: staging/extra/add//home/ise/packages/mp3blaster-3.2.3-3-i686.pkg.tar.gz: No such file or directory File got corrupted during upload, cancelled. ---snip----
The error is in the md5sum check on line 56:
if [ "$(md5sum $pkgfile | cut -d' ' -f1)" != "$(ssh archlinux.org md5sum staging/${repo}/add/$pkgfile | cut -d' ' -f1)" ]; then
The variable $pkgfile is wrong, it was set right in the top of the script: pkgfile=${pkgname}-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.gz
But it changed to: "pkgfile=$PKGDEST/$pkgfile" just some lines lower.
Daniel
Hi,
Thomas told me that he has fixed the issue, which I have reported. I had test the new devtools from git and they work without any problems. I have checked only the extrapkg script.
Daniel
On 10/4/07, Daniel Isenmann daniel.isenmann@gmx.de wrote:
Hi,
Thomas told me that he has fixed the issue, which I have reported. I had test the new devtools from git and they work without any problems. I have checked only the extrapkg script.
Hooray.
Andy, can you see if the checkpkg changes work?
On 10/4/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 10/4/07, Daniel Isenmann daniel.isenmann@gmx.de wrote:
Hi,
Thomas told me that he has fixed the issue, which I have reported. I had test the new devtools from git and they work without any problems. I have checked only the extrapkg script.
Hooray.
Andy, can you see if the checkpkg changes work?
I used checkpkg and extrapkg last night without problems, but it would be good to hear a few more voices before we bump the official package.
Any other features/bug reports/requests for these tools before we do another release?
-Dan
one checkpkg issue - $PKGDEST isn't sourced well:
usr/share/icu/3.8/mkinstalldirs usr/share/licenses/ usr/share/licenses/icu/ usr/share/licenses/icu/license.html
tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden tar: Nicht behebbarer Fehler: Programmabbruch. tar: Child returned status 2 tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler. usr/lib/libicudata.so.38: SONAME libicudata.so.38 usr/lib/libicudata.so.38.0: SONAME libicudata.so.38 usr/lib/libicui18n.so.38: SONAME libicui18n.so.38
new pkg icu-3.8-1-x86_64.pkg.tar.gz does exist: [andyrtr@workstation64 icu]$ ls -l /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz -rw-r--r-- 1 andyrtr users 6844521 4. Okt 19:41 /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz
[andyrtr@workstation64 icu]$ tail /etc/makepkg.conf # #-- Destination: specify a fixed directory where all packages will be placed PKGDEST=/home/daten/arch64/packages/testing
The condition with oldstylepkgfile overwrites the values: echo $pkgfile echo $PKGDEST /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz /home/daten/arch64/packages/testing
the old pkg is oldstyle in this case.
Andy
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden tar: Nicht behebbarer Fehler: Programmabbruch.
Could someone translate, for clarity?
Am Thu, 4 Oct 2007 13:26:23 -0500 schrieb "Aaron Griffin" aaronmgriffin@gmail.com:
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden tar: Nicht behebbarer Fehler: Programmabbruch.
Could someone translate, for clarity?
tar: ..//home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors
Andy
it comes from
if diff filelist-old filelist | grep '.so.' > /dev/null 2>&1; then mkdir -p pkg cd pkg tar xzf ../$pkgfile > /dev/null <------- ??? for i in `diff ../filelist-old ../filelist | grep > | grep .so. | awk '{print $2}'`; do echo -n "${i}: " objdump -p $i | grep SONAME done else echo "No filename differences" fi
at the end of the script. isn't that one obsolete as it does simply nothing?
Andy
Andreas Radke schrieb:
tar xzf ../$pkgfile > /dev/null <------- ???
That line breaks it if $PKGDEST is used, and $pkgfile is an absolute path.
extrapkg issue:
[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$
The speedlimit worked well. but it seems to break the -m comment for cvs commit.
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
Andy
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
extrapkg issue:
[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$
The speedlimit worked well. but it seems to break the -m comment for cvs commit.
That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.
cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
Well, we could do it in reverse, I don't see a big problem with that... anyone else?
On Thu, 4 Oct 2007, Aaron Griffin wrote:
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
extrapkg issue:
[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$
The speedlimit worked well. but it seems to break the -m comment for cvs commit.
That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.
cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
Well, we could do it in reverse, I don't see a big problem with that... anyone else?
That can be solved by using ssh keys. If you also use keygen, you just need to enter your passphrase ounce per session and it won't ask for any password afterwards. I find it much more convenient too.
On Thu, Oct 04, 2007 at 02:49:16PM -0500, Aaron Griffin wrote:
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
extrapkg issue:
[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$
The speedlimit worked well. but it seems to break the -m comment for cvs commit.
That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.
cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
Well, we could do it in reverse, I don't see a big problem with that... anyone else?
I didn't want to commit (mostly tag) until after the package was available on the server. Once a package has been tagged, we'll start seeing errors because it's not in the staging dir when you run db-extra.
We could still commit first, but you'd probably run into the same timeout issue if we just tag though.
Jason
On 10/4/07, Jason Chu jason@archlinux.org wrote:
On Thu, Oct 04, 2007 at 02:49:16PM -0500, Aaron Griffin wrote:
On 10/4/07, Andreas Radke a.radke@arcor.de wrote:
extrapkg issue:
[andyrtr@workstation64 icu]$ extrapkg -l 60 andyrtr@gerolde.archlinux.org's password: icu-3.8-1-x86_64.pkg.tar.gz 100% 6684KB 7.4KB/s 15:00 andyrtr@gerolde.archlinux.org's password: File integrity okay. ===> Uploaded /home/daten/arch64/packages/testing/icu-3.8-1-x86_64.pkg.tar.gz cvs commit: Examining . andyrtr@cvs.archlinux.org's password: cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first! Cancelled [andyrtr@workstation64 icu]$
The speedlimit worked well. but it seems to break the -m comment for cvs commit.
That error looks more like the commit failed. The -m argument is for the commit message, this error is different. It means there's a conflict in CVS.
cvs commit: Up-to-date check failed for `PKGBUILD' cvs [commit aborted]: correct above errors first!
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
Well, we could do it in reverse, I don't see a big problem with that... anyone else?
I didn't want to commit (mostly tag) until after the package was available on the server. Once a package has been tagged, we'll start seeing errors because it's not in the staging dir when you run db-extra.
We could still commit first, but you'd probably run into the same timeout issue if we just tag though.
Yeah, I was afraid there was something I was forgetting.
In all honesty, I think Eric's solution is the best here.
We're uploading/committing in a certain order because it's the proper way, but the issue here is specific to your machine, so we should solve this on your machine.
Would someone mind writing up a quick HOWTO in the dev wiki for using ssh keys on gerolde - for those that haven't done it yet?
Yeah, I was afraid there was something I was forgetting.
In all honesty, I think Eric's solution is the best here.
I concur. SSH keys are the way to handle this issue and they always have been.
I probably should have written the document about it a long time ago (note, I'm not suggesting I do it now!).
Jason
Andreas Radke schrieb:
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
As already mentioned, you could use ssh keys. As my /home is encrypted, I use my key without a passphrase, but you could use a passphrase and ssh-agent (if you lock your screen during your absence, nobody will be able to login to gerolde). Using keys is much more secure than password authentication anyway.
Additionally, I use ssh master mode:
[thomas@artin ~]$ cat .ssh/config ControlPath /home/thomas/.ssh/master-%h-%p-%r
Host gerolde HostName archlinux.org
Host cvs.archlinux.org HostName archlinux.org
I now launch ssh -M gerolde. That creates a master connection, that all other ssh connections to the same host are tunneled through (thus the alias from cvs.archlinux.org to archlinux.org). The authentication problem remains the same, but as only one connection is established, the cvs commit and tag operations are done much quicker. I recommend to for anyone who is working much on arch cvs/git/upload via ssh.
On 10/4/07, Thomas Bächler thomas@archlinux.org wrote:
Andreas Radke schrieb:
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
As already mentioned, you could use ssh keys. As my /home is encrypted, I use my key without a passphrase, but you could use a passphrase and ssh-agent (if you lock your screen during your absence, nobody will be able to login to gerolde). Using keys is much more secure than password authentication anyway.
Additionally, I use ssh master mode:
[thomas@artin ~]$ cat .ssh/config ControlPath /home/thomas/.ssh/master-%h-%p-%r
Host gerolde HostName archlinux.org
Host cvs.archlinux.org HostName archlinux.org
I now launch ssh -M gerolde. That creates a master connection, that all other ssh connections to the same host are tunneled through (thus the alias from cvs.archlinux.org to archlinux.org). The authentication problem remains the same, but as only one connection is established, the cvs commit and tag operations are done much quicker. I recommend to for anyone who is working much on arch cvs/git/upload via ssh.
Further reading: http://phraktured.net/ssh-connection-control.html
On Thu, 4 Oct 2007, Aaron Griffin wrote:
On 10/4/07, Thomas Bächler thomas@archlinux.org wrote:
Andreas Radke schrieb:
Beside that i have a big problem with the strict order to first upload the package and then commit/tag it. OpenOffice.org needs me 4 hours to upload. When I will not sit in front of the pc when it comes to commit/tag the server will reject me due to a timeout. Any idea if/how this can be solved?
As already mentioned, you could use ssh keys. As my /home is encrypted, I use my key without a passphrase, but you could use a passphrase and ssh-agent (if you lock your screen during your absence, nobody will be able to login to gerolde). Using keys is much more secure than password authentication anyway.
Additionally, I use ssh master mode:
[thomas@artin ~]$ cat .ssh/config ControlPath /home/thomas/.ssh/master-%h-%p-%r
Host gerolde HostName archlinux.org
Host cvs.archlinux.org HostName archlinux.org
I now launch ssh -M gerolde. That creates a master connection, that all other ssh connections to the same host are tunneled through (thus the alias from cvs.archlinux.org to archlinux.org). The authentication problem remains the same, but as only one connection is established, the cvs commit and tag operations are done much quicker. I recommend to for anyone who is working much on arch cvs/git/upload via ssh.
Further reading: http://phraktured.net/ssh-connection-control.html
There's an article in the wiki: http://wiki.archlinux.org/index.php/Using_SSH_Keys That's the information source I use to create my setup.
arch-dev-public@lists.archlinux.org