[arch-general] New vi/vim/gvim in testing requires intervention
Hi, Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu" -T
On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
-T
hello, as a linux newbie i am a little confused about the "sudo rm /usr/bin/{view/rview}" command. typing it with the "{}"s does not work, file or directory not found. am i supposed to delete /usr/bin/view (which is a link)? i am probably missing something very obvious, but before i mess up my system i rather ask.
On Tue, 2009-05-05 at 15:11 +0200, bs wrote:
On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
-T
hello, as a linux newbie i am a little confused about the "sudo rm /usr/bin/{view/rview}" command. typing it with the "{}"s does not work, file or directory not found. am i supposed to delete /usr/bin/view (which is a link)? i am probably missing something very obvious, but before i mess up my system i rather ask.
It shouldn't be {view/rview}, but {view,rview} or even {r,}view.
On Tue, May 5, 2009 at 2:11 PM, bs <bojan912@gmail.com> wrote:
On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
-T
hello, as a linux newbie i am a little confused about the "sudo rm /usr/bin/{view/rview}" command. typing it with the "{}"s does not work, file or directory not found. am i supposed to delete /usr/bin/view (which is a link)? i am probably missing something very obvious, but before i mess up my system i rather ask.
I think it would have been better to write in proper shell syntax, which would be "sudo rm /usr/bin/{view,rview}". The equivalent command, without the {} is "sudo rm /usr/bin/view /usr/bin/rview", by using the {} you let the shell do the expansion, and you save a few keystrokes. :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Yay, thanks. -AT On Tue, May 5, 2009 at 9:18 AM, Magnus Therning <magnus@therning.org> wrote:
On Tue, May 5, 2009 at 2:11 PM, bs <bojan912@gmail.com> wrote:
On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
-T
hello, as a linux newbie i am a little confused about the "sudo rm /usr/bin/{view/rview}" command. typing it with the "{}"s does not work, file or directory not found. am i supposed to delete /usr/bin/view (which is a link)? i am probably missing something very obvious, but before i mess up my system i rather ask.
I think it would have been better to write in proper shell syntax, which would be "sudo rm /usr/bin/{view,rview}". The equivalent command, without the {} is "sudo rm /usr/bin/view /usr/bin/rview", by using the {} you let the shell do the expansion, and you save a few keystrokes. :-)
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Tue, 05 May 2009, bs wrote:
hello, as a linux newbie i am a little confused about the "sudo rm /usr/bin/{view/rview}" command. typing it with the "{}"s does not work, file or directory not found. am i supposed to delete /usr/bin/view (which is a link)? i am probably missing something very obvious, but before i mess up my system i rather ask.
Hi, yeah as the others pointed out, that was a typo on my part, sorry. And of cause Jan beat me with shorten it up even further :P I'll go and fix the news. -T
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote:
Finally, the new vi* packages are up.
Why not letting Vim replace nvi entirely, the Vim package looks kinda ugly now. Thomas
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing. Th vim package is not uglier then it used to be before, actually it's less complex now because I don['t have to cater towards three different package from the same source that all depend on each otherl. It's down to two packages now vim and gvim -T Quoting Thomas Bohn <thomas@bohnomat.de>:
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote:
Finally, the new vi* packages are up.
Why not letting Vim replace nvi entirely, the Vim package looks kinda ugly now.
Thomas
On 2009-05-05 19:20 +0200, tobias@justdreams.de wrote:
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing.
I know that. That is why I'm asking. Either nvi or Vim. Both makes it complex.
Th vim package is not uglier then it used to be before,
Well before was extremely ugly with this three different packages and a Vim wich didn't react like one, at least until someone found out that it needed .virc. Thomas
On Tue, May 5, 2009 at 12:49 PM, Thomas Bohn <thomas@bohnomat.de> wrote:
On 2009-05-05 19:20 +0200, tobias@justdreams.de wrote:
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing.
I know that. That is why I'm asking. Either nvi or Vim. Both makes it complex.
Th vim package is not uglier then it used to be before,
Actually, I don't see a big problem with vim having provides/conflicts with vi, so that it will completely supplant it. That way we also cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh)
cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh)
couldn't we suggest them to make an alias ?
Hi, that can be done, sure, however I don't like the idea of having an extra package conflict with a core one. We could name the package nvi, call the binaries nvi and provide a symlink that gets replace on installing vim but all this symlinking stuff has proved itself to be error prone. - T Quoting Aaron Griffin <aaronmgriffin@gmail.com>:
On Tue, May 5, 2009 at 12:49 PM, Thomas Bohn <thomas@bohnomat.de> wrote:
On 2009-05-05 19:20 +0200, tobias@justdreams.de wrote:
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing.
I know that. That is why I'm asking. Either nvi or Vim. Both makes it complex.
Th vim package is not uglier then it used to be before,
Actually, I don't see a big problem with vim having provides/conflicts with vi, so that it will completely supplant it. That way we also cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh)
On Tue, May 5, 2009 at 12:20 PM, <tobias@justdreams.de> wrote:
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing.
Th vim package is not uglier then it used to be before, actually it's less complex now because I don['t have to cater towards three different package from the same source that all depend on each otherl. It's down to two packages now vim and gvim
:: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: vim-bufexplorer: requires vi>=7.0 Can you rebuild anything that depends on the vi version please? This looks like it really should depend on vim. -Dan
Hi, Just a question about this new vi package. Am I the only one having problems when openning UTF-8 files? I can't even type words with diacritics or vi will abort. For example, try to create a file with the following and then open it with the new vi package: This line will render fine Mas essa aqui não ("but this one won't" in Portuguese). I know that config files from Arch don't have diacritics, but I don't think that putting this vi package in core will be a good idea. (The new vim package is working fine, though.)
On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
Hi,
Just a question about this new vi package. Am I the only one having problems when openning UTF-8 files? I can't even type words with diacritics or vi will abort. For example, try to create a file with the following and then open it with the new vi package:
This line will render fine Mas essa aqui não ("but this one won't" in Portuguese).
I know that config files from Arch don't have diacritics, but I don't think that putting this vi package in core will be a good idea.
(The new vim package is working fine, though.)
vi is just a bare editor which has its limits. One of them is not being able to use the cursor keys while you're in insert mode for example. This issue is known on many platforms: other linux distributions, FreeBSD, OpenBSD, etc. They all have nvi or some other vi clone in the base system. If you want support for non-ASCII charsets and other things offered by vim, just install vim.
I was thinking more about the installation/recuperation process than the daily usage, because it's not always possible to install vim in such cases. That's why I was questioning only vi being in [core], though having vim in [core] would add lots of dependencies, so I guess it's better the way it is. Especially if other distros are using the same vi package, and still there is nano. On Wed, May 6, 2009 at 8:07 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
Hi,
Just a question about this new vi package. Am I the only one having problems when openning UTF-8 files? I can't even type words with diacritics or vi will abort. For example, try to create a file with the following and then open it with the new vi package:
This line will render fine Mas essa aqui não ("but this one won't" in Portuguese).
I know that config files from Arch don't have diacritics, but I don't think that putting this vi package in core will be a good idea.
(The new vim package is working fine, though.)
vi is just a bare editor which has its limits. One of them is not being able to use the cursor keys while you're in insert mode for example. This issue is known on many platforms: other linux distributions, FreeBSD, OpenBSD, etc. They all have nvi or some other vi clone in the base system. If you want support for non-ASCII charsets and other things offered by vim, just install vim.
Le Mercredi 6 à 13:07, Jan de Groot a écrit :
On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
Just a question about this new vi package. Am I the only one having problems when openning UTF-8 files? I can't even type words with diacritics or vi will abort. For example, try to create a file with the following and then open it with the new vi package:
This line will render fine Mas essa aqui não ("but this one won't" in Portuguese).
[...]
If you want support for non-ASCII charsets and other things offered by vim, just install vim.
I have a system whose users' real names can't be written in ASCII, and this being the 21st century, not the 70's, I have the real name (with accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I just have whatever the default package for vi is installed. Then for whatever reason, /etc/passwd is b0rked, and I have to boot into single usermode to repair that, and all I can use is vi. vi crashes when I open /etc/passwd. Now what ? Or, $config_file has comments in my native language, and vi crashes when I open it. FreeBSD's vi (actually nvi) can't manage non-ASCII characters, but at least it doesn't crash. (Actually : 1. I'm an emacs user, so I would use emacs ;-p ; 2. cut -d: -f -4,6- < /etc/passwd > /etc/passwd.no-real) -- Fred
2009/5/6 Frédéric Perrin <frederic.perrin@resel.fr>:
I have a system whose users' real names can't be written in ASCII, and this being the 21st century, not the 70's, I have the real name (with accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I just have whatever the default package for vi is installed.
$ grep http /etc/passwd | cut -d: -f5 $ usermod -c éøß http $ grep http /etc/passwd | cut -d: -f5 éøß Editing the passwd file by hand seems a little odd to me. Still, if vi crashes when opening a non ASCII file, that's another story
At least here, vi can open non-ASCII files, but as I said previously, it won't show the lines with non-ASCII characters. The worst thing is if you try to save this file, vi will save it only up to the first line with a non-ASCII character: $ cat test.txt This line is fine mas essa não (but this one isn't) neither is this one. Then open it with vi and try to save it. $ cat test.txt This line is fine and that's all. Vi does crash, but only when I type a non-ASCII character. On Wed, May 6, 2009 at 4:15 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
2009/5/6 Frédéric Perrin <frederic.perrin@resel.fr>:
I have a system whose users' real names can't be written in ASCII, and this being the 21st century, not the 70's, I have the real name (with accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I just have whatever the default package for vi is installed.
$ grep http /etc/passwd | cut -d: -f5
$ usermod -c éøß http $ grep http /etc/passwd | cut -d: -f5 éøß
Editing the passwd file by hand seems a little odd to me.
Still, if vi crashes when opening a non ASCII file, that's another story
On Wed, May 6, 2009 at 2:30 PM, André Ramaciotti <andre.ramaciotti@gmail.com> wrote:
At least here, vi can open non-ASCII files, but as I said previously, it won't show the lines with non-ASCII characters. The worst thing is if you try to save this file, vi will save it only up to the first line with a non-ASCII character:
$ cat test.txt This line is fine mas essa não (but this one isn't) neither is this one.
Then open it with vi and try to save it.
$ cat test.txt This line is fine
and that's all.
Vi does crash, but only when I type a non-ASCII character.
Might be worth seeing if we can find a patch to fix the crash at least.
Le Wed, 6 May 2009 14:53:43 -0500, Aaron Griffin <aaronmgriffin@gmail.com> a écrit :
Might be worth seeing if we can find a patch to fix the crash at least.
Patching might be a good idea, but if you just patch the crash I think it will still be even more dangerous to put this version of vi in core because of the behavior described by André Ramaciotti. If any user whose language is not English writes a comment at the top of a config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, this config file will be emptied and he won't know it. Guess what will happen when he tries to reboot. There is a simple, easy to use and mostly bug-free editor in core, it's nano. Why the need for another one? -- Pierre 'catwell' Chapuis
On Wed, May 6, 2009 at 3:15 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Wed, 6 May 2009 14:53:43 -0500, Aaron Griffin <aaronmgriffin@gmail.com> a écrit :
Might be worth seeing if we can find a patch to fix the crash at least.
Patching might be a good idea, but if you just patch the crash I think it will still be even more dangerous to put this version of vi in core because of the behavior described by André Ramaciotti.
If any user whose language is not English writes a comment at the top of a config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, this config file will be emptied and he won't know it. Guess what will happen when he tries to reboot.
There is a simple, easy to use and mostly bug-free editor in core, it's nano. Why the need for another one?
Not everyone likes or prefers nano. More to the point - a working vi is required to be POSIX compliant (or maybe it's SUSv3)
On Wed, 2009-05-06 at 15:40 -0500, Aaron Griffin wrote:
On Wed, May 6, 2009 at 3:15 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Wed, 6 May 2009 14:53:43 -0500, Aaron Griffin <aaronmgriffin@gmail.com> a écrit :
Might be worth seeing if we can find a patch to fix the crash at least.
Patching might be a good idea, but if you just patch the crash I think it will still be even more dangerous to put this version of vi in core because of the behavior described by André Ramaciotti.
If any user whose language is not English writes a comment at the top of a config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, this config file will be emptied and he won't know it. Guess what will happen when he tries to reboot.
There is a simple, easy to use and mostly bug-free editor in core, it's nano. Why the need for another one?
Not everyone likes or prefers nano. More to the point - a working vi is required to be POSIX compliant (or maybe it's SUSv3)
As for the working vi, we have two options: - disable widechar support - check debian sid for patches, they have some patches that cope with broken widechar support
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote:
Finally, the new vi* packages are up.
One more question about the vim package. Why is /usr/bin/vim a symlink to /usr/bin/vim-normal? Thomas
Hi all, Tobias, i`m without a machine, so, i can`t check the vim version. Did you compile new vim with witch version of ruby? On Sat, May 9, 2009 at 10:24 AM, Thomas Bohn <thomas@bohnomat.de> wrote:
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote:
Finally, the new vi* packages are up.
One more question about the vim package. Why is /usr/bin/vim a symlink to /usr/bin/vim-normal?
Thomas
-- Kessia Pinheiro Computer Science Student - Brazil, UFBa Linux System Administrator Arch Linux Trusted User Linux User #389695 http://even.archlinux-br.org --- X Fórum Internacional Software Livre - fisl10 24 a 27 de junho de 2009 PUCRS - Porto Alegre - Brasil
Kessia 'even' Pinheiro wrote:
Hi all, Tobias, i`m without a machine, so, i can`t check the vim version. Did you compile new vim with witch version of ruby?
It will be with ruby-1.8 because 1.9 is not in the repos yet... I am waiting for the vi(m)'s to move out of [testing] before I do the ruby update. Allan
On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
Any ideas? dmcgee@galway ~ $ vim .vimrc Error detected while processing /home/dmcgee/.vimrc: line 64: E185: Cannot find color scheme inkpot Press ENTER or type command to continue dmcgee@galway ~ $ locate inkpot /usr/share/vim/colors/inkpot.vim For reference, here is some of my .vimrc: " GUI/NONGUI SETTINGS " if has("gui_running") if has("gui_gtk2") set guifont=DejaVu\ Sans\ Mono\ 12 endif colorscheme desert set columns=80 lines=40 else colorscheme inkpot endif And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/ Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? -Dan
On Mon, May 11, 2009 at 8:40 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu"
Any ideas?
dmcgee@galway ~ $ vim .vimrc Error detected while processing /home/dmcgee/.vimrc: line 64: E185: Cannot find color scheme inkpot Press ENTER or type command to continue
dmcgee@galway ~ $ locate inkpot /usr/share/vim/colors/inkpot.vim
For reference, here is some of my .vimrc:
" GUI/NONGUI SETTINGS " if has("gui_running") if has("gui_gtk2") set guifont=DejaVu\ Sans\ Mono\ 12 endif colorscheme desert set columns=80 lines=40 else colorscheme inkpot endif
And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Addendum: *any* plugins installed do not work, not just colors or anything else. vim-bufexplorer is broken; vim-taglist is broken, etc. This is going to leave a lot of people with a crippled setup if we start moving the default paths around like this. This should not move out of [testing] until this is resolved in some way. -Dan
Dan McGee wrote:
On Mon, May 11, 2009 at 8:40 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}" before you run "sudo pacman -Syu" Any ideas?
dmcgee@galway ~ $ vim .vimrc Error detected while processing /home/dmcgee/.vimrc: line 64: E185: Cannot find color scheme inkpot Press ENTER or type command to continue
dmcgee@galway ~ $ locate inkpot /usr/share/vim/colors/inkpot.vim
For reference, here is some of my .vimrc:
" GUI/NONGUI SETTINGS " if has("gui_running") if has("gui_gtk2") set guifont=DejaVu\ Sans\ Mono\ 12 endif colorscheme desert set columns=80 lines=40 else colorscheme inkpot endif
And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Looking at other distros it seems using /usr/share/vim/vimX is the place for system-wide configurations. Not saying that's right or wrong. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Tue, 12 May 2009, Magnus Therning wrote:
And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Looking at other distros it seems using /usr/share/vim/vimX is the place for system-wide configurations. Not saying that's right or wrong.
Well, I tied up quite a few requests into the new vim packages. Becuase we serve the runtime files with one package(vim) and have other packages(gvim) depend on it, I used to set the runtime path explicitely. Users told me that causes vim to search always in two pathes(the explicite one AND the default one). Hence I started toi stick with the default path, which is /usr/share/vim/vimxy. That means all plugins need to be rebuild and some users that set fixed pathes in .vimrc will have to adjust. -T
On Tue, May 12, 2009 at 2:19 AM, Tobias Kieslich <tobias@justdreams.de> wrote:
On Tue, 12 May 2009, Magnus Therning wrote:
And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Looking at other distros it seems using /usr/share/vim/vimX is the place for system-wide configurations. Not saying that's right or wrong.
Well, I tied up quite a few requests into the new vim packages. Becuase we serve the runtime files with one package(vim) and have other packages(gvim) depend on it, I used to set the runtime path explicitely. Users told me that causes vim to search always in two pathes(the explicite one AND the default one). Hence I started toi stick with the default path, which is /usr/share/vim/vimxy.
That means all plugins need to be rebuild and some users that set fixed pathes in .vimrc will have to adjust.
Looks like we have a new rebuild list then: $ pacman -Sqs vim- gvim vim-a vim-bufexplorer vim-buftabs vim-colorsamplerpack vim-doxygentoolkit vim-guicolorscheme vim-matchit vim-minibufexpl vim-omnicppcomplete vim-project vim-taglist vim-vcscommand vim-workspace vim-pastie vim-rails vim-supertab vim-surround vim-timestamp vimpager Why the heck gvim and vimpager showed up in there I'm not sure, but the above plugin packages probably all use the default location. We should additionally make sure they depend on 'vim' and not 'vi', as I rebuilt two or three plugins already that made the assumption they were one and the same. -Dan
On Mon, May 11, 2009 at 08:50:02PM -0500, Dan McGee wrote:
And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Addendum: *any* plugins installed do not work, not just colors or anything else. vim-bufexplorer is broken; vim-taglist is broken, etc.
Add this line to ~/.vimrc: set runtimepath+=/usr/share/vim In the default vim configuration the main directory for runtime files is the one where vim installs its files, /usr/share/vim/vim72 in the new package, /usr/share/vim/ before the split vi/vim/gvim. See the help for :runtimepath, $VIMRUNTIME and $VIM. The plugins packages need a repackaging. There is already a bug report http://bugs.archlinux.org/task/14626.
participants (16)
-
Aaron Griffin
-
Alessandro Doro
-
Allan McRae
-
Andrei Thorp
-
André Ramaciotti
-
bs
-
Dan McGee
-
Frédéric Perrin
-
Jan de Groot
-
Kessia 'even' Pinheiro
-
ludovic coues
-
Magnus Therning
-
Pierre Chapuis
-
Thomas Bohn
-
Tobias Kieslich
-
tobias＠justdreams.de