Re: [aur-general] [PATCH] initial support for any architecture.
2009/3/17 Aaron Griffin aaronmgrif...@gmail.com: Finally pulled in the last patch there into my any-arch branch. I'm not sure how I feel about it, seeing as it duplicates a lot of work (I was hoping to reuse the loop somehow), but it seems ok otherwise. Now we just need to make sure db-move and db-remove can handle any packages I could have added the ANYPKGS stuff in the main loop itself, but that was cluttering the code with a lot of if calls. I'm now working on db-{move, remove}. Would it be better if I refactored it to move packages in all archs possible, rather than specifying the arch? Then we could get rid of the testing2core64 and other *64 scripts. -- Abhishek.
[aur-general] Arch's Vim Failings Solution Suggestions
Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, Are you on Arch? Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp -- Forwarded message -- From: James Vega james...@debian.org Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: gar...@gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying --with-global-runtime=/usr/share/vim to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(rtp, 'colors/*') -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -END PGP SIGNATURE-
Re: [aur-general] Arch's Vim Failings Solution Suggestions
On Thu, Mar 19, 2009 at 10:54, Andrei Thorp gar...@gmail.com wrote: Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, Are you on Arch? Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp -- Forwarded message -- From: James Vega james...@debian.org Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: gar...@gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying --with-global-runtime=/usr/share/vim to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(rtp, 'colors/*') -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -END PGP SIGNATURE- I don't have a whole lot to add to this, except that it seems like a good idea to confer with the vim developers to raise the quality of the package. I would file a bug report on the Arch tracker. (Also sending to arch-general, so this gets more exposure)
Re: [aur-general] Arch's Vim Failings Solution Suggestions
Thanks for sending it along, Dae. -AT On Thu, Mar 19, 2009 at 11:01 AM, Kessia 'even' Pinheiro kessiapinhe...@gmail.com wrote: Hi, I had that problem too, i asked for something in #vim channel and they only ridicularize vim package from Arch. I tried talk with Tobias about the vim upgrade for support ruby1.9, but he are so far from fix it, looking for problems which isnt important, in my vision. VI package are with 65 patch, unless the oficial project are with more than 100! I think it's a problem from arch package, but we need know why it's so problematic for vim users dont like the package layout. thanks On Thu, Mar 19, 2009 at 11:54 AM, Andrei Thorp gar...@gmail.com wrote: Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, Are you on Arch? Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp -- Forwarded message -- From: James Vega james...@debian.org Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: gar...@gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying --with-global-runtime=/usr/share/vim to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(rtp, 'colors/*') -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -END PGP SIGNATURE- -- 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
Re: [aur-general] Arch's Vim Failings Solution Suggestions
Hi, I had that problem too, i asked for something in #vim channel and they only ridicularize vim package from Arch. I tried talk with Tobias about the vim upgrade for support ruby1.9, but he are so far from fix it, looking for problems which isnt important, in my vision. VI package are with 65 patch, unless the oficial project are with more than 100! I think it's a problem from arch package, but we need know why it's so problematic for vim users dont like the package layout. thanks On Thu, Mar 19, 2009 at 11:54 AM, Andrei Thorp gar...@gmail.com wrote: Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, Are you on Arch? Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp -- Forwarded message -- From: James Vega james...@debian.org Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: gar...@gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying --with-global-runtime=/usr/share/vim to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(rtp, 'colors/*') -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX =HJf3 -END PGP SIGNATURE- -- 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
Re: [aur-general] Arch's Vim Failings Solution Suggestions
Andrei Thorp wrote: snip There is a new vim setup on its way which should address some of these issues. Not sure what the status of it is though... Allan
Re: [aur-general] Arch's Vim Failings Solution Suggestions
On Thu, Mar 19, 2009 at 9:54 AM, Andrei Thorp gar...@gmail.com wrote: Hello, fellow Archers. Recently, I had a question about Vim, so I went to the #vim channel in IRC. I was doing something that should be working, but it wasn't. Surprisingly, the question came up, Are you on Arch? Turns out that several of the peolpe I most respect in the #vim IRC channel are very unhappy with the quality of Arch's Vim package. One even (jokingly?) asked if they could officially not support Arch in the channel, which I found somewhat alarming. I suggested that we should instead help improve the Arch package. I hate to pick on people, but according to the generally kind folks on IRC, the Vim package for Arch has quite a few issues, and the maintainer hasn't addressed some outstanding bugs in quite a long while. As some of you may know, James Vega (jamessan) is an outstanding Vim user and the Debian package maintainer for Vim. I asked him to send me what he saw as the problems with the Arch package, and he was kind enough to send along some suggestions. They are attached in this forward. Thank you, -Andrei Thorp -- Forwarded message -- From: James Vega james...@debian.org Date: Thu, Mar 19, 2009 at 2:29 AM Subject: Arch's Vim failings To: gar...@gmail.com Andrei, Thanks for being receptive to trying to address the issues in Arch's Vim packaging. Below are the major points that stand out. 1) gvim package: Shipping an /etc/gvimrc which, due to the order that Vim loads rc files, overrides any settings in the user's ~/.vimrc. Considering that some users make the conscious decision to keep all their settings in their ~/.vimrc instead of using both ~/.vimrc and ~/.gvimrc, this is at the very least annoying. More in depth discussion is contained in the nearly year old, unfixed bug[0] about this issue. 2) vi package: The package is built such that the resulting vi binary reads its config from the completely non-standard ~/.virc. Presumably this is to allow different configurations for the different feature-sets avaiable in vi vs. vim packages. Fortunately, Vim has methods to deal with this already such as being able to check what name was used to invoke Vim[1] and explicitly checking for feature support[2]. 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME == $VIM by specifying --with-global-runtime=/usr/share/vim to configure. This doesn't need to be specified to configure as it will be set to the correct directory on its own. If they insist on specifying it, the directory should be /usr/share/vim/vimXY (where XY is Vim's version number -- 72 for current Vim). This manifests various problems, the most noticeable being that the 'runtimepath' option in Vim has /usr/share/vim listed twice, thus causing runtime files to be sourced twice and causing duplicate information when using common scripting methods for discovering files in the runtimepath[3]. [0] - http://bugs.archlinux.org/task/10303 [1] - if v:progname == 'vi' [2] - if has('cscope') [3] - globpath(rtp, 'colors/*') Thanks for sending this along. We're more than willing to fix and work through problems that upstream has with the way we package software - as we always say, we try to stay as close to upstream as possible. So, couple of solutions I'd like to suggest: The reason the vi package is... well, jacked up, is because we needed a small version to stick in our base package set, without a lot of features. I guess this would be like vim-tiny on Debian. What we could do is simply ship nvi instead, for that purpose, and stick with only two packages, vim and gvim. That would help things greatly. Is not shipping a global /etc/gvimrc the norm? If so, we could do that, and it would solve some annoyances I myself experienced (though I rarely use gvim). Regarding the runtimepath, that is a good point that scripts are sourced twice. Definitely a bug and we should fix this.
Re: [aur-general] [PATCH] initial support for any architecture.
On Thu, Mar 19, 2009 at 1:54 AM, Abhishek Dasgupta abh...@gmail.com wrote: 2009/3/17 Aaron Griffin aaronmgrif...@gmail.com: Finally pulled in the last patch there into my any-arch branch. I'm not sure how I feel about it, seeing as it duplicates a lot of work (I was hoping to reuse the loop somehow), but it seems ok otherwise. Now we just need to make sure db-move and db-remove can handle any packages I could have added the ANYPKGS stuff in the main loop itself, but that was cluttering the code with a lot of if calls. I'm now working on db-{move, remove}. Would it be better if I refactored it to move packages in all archs possible, rather than specifying the arch? Then we could get rid of the testing2core64 and other *64 scripts. I thought of that. The reason I decided not to was because some packages could move, say, out of testing for i686 and NOT x86_64. I don't know if that's a common case though. Perhaps we can do this: move all packages by default. if the arch is specified on the command line, move only that arch. or in code - looparches=${arch...@]} [ -n $2 ] looparches=$2 for arch in $looparches; do do move logic here done
Re: [aur-general] Arch's Vim Failings Solution Suggestions
On Thu, Mar 19, 2009 at 11:35, Aaron Griffin aaronmgrif...@gmail.com wrote: snip What we could do is simply ship nvi instead, for that purpose, and stick with only two packages, vim and gvim. That would help things greatly. snip +1
Re: [aur-general] Arch's Vim Failings Solution Suggestions
It's been mentioned to me that several bugs are open around these issues, and if this indeed the case, I believe it valuable to bring attention to them -- a mailing list cannot hurt. -AT On Thu, Mar 19, 2009 at 1:07 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Thu, Mar 19, 2009 at 10:49 AM, Daenyth Blank daenyth+a...@gmail.com wrote: On Thu, Mar 19, 2009 at 11:35, Aaron Griffin aaronmgrif...@gmail.com wrote: snip What we could do is simply ship nvi instead, for that purpose, and stick with only two packages, vim and gvim. That would help things greatly. snip +1 I just realized this was on the aur-general list. Silly place for this discussion. Can we move this to the bug tracker?
Re: [aur-general] Arch's Vim Failings Solution Suggestions
On Thu, Mar 19, 2009 at 7:44 PM, Andrei Thorp gar...@gmail.com wrote: It's been mentioned to me that several bugs are open around these issues, and if this indeed the case, I believe it valuable to bring attention to them -- a mailing list cannot hurt. Well, at the very least, I'm sure the AUR mailing list is the wrong place for this. But discussion on the bug tracker centralizes the facts, so I don't have to go hunting around 4 different mailing lists, forum posts, and things like that.