[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: vim.eclass
Samuli Suominen wrote: > eclass has ChangeLog file now. any particular reason why you skipped it? Completely oblivious to its existence, that's all :) I'll (hopefully) remember it next time. > or is it not meant to be used yet / not mandatory to use yet? since most > people seem to skip it. In my case it was entirely ignorance, and with no statistical evidence to base my assertion I'll say that most other omissions come from the same cause. Though on the other hand you could argue that a Changelog for all eclasses may be a bit overkill. Most eclasses are not related to one another, so reading the CVS history of the changes to a single file is much more useful than having a big list of unrelated changes. A changelog becomes much more useful when you need to make related commits to multiple files with a non-atomic-commit system like CVS. -- Jim Ramsay Gentoo/Linux Developer (rox/fluxbox/gkrellm)
[gentoo-dev] Lastrite: dev-perl/Gtk2-Sexy and net-misc/twitux (Masking reverse dependencies of libsexy, part #1)
# Samuli Suominen (28 Nov 2011) # Masked for removal in 30 days because of bugs 380193 and 381227 dev-perl/Gtk2-Sexy net-misc/twitux
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: vim.eclass
eclass has ChangeLog file now. any particular reason why you skipped it?
or is it not meant to be used yet / not mandatory to use yet? since most
people seem to skip it.
- Samuli
On 11/28/2011 08:13 PM, Jim Ramsay (lack) wrote:
> lack11/11/28 18:13:42
>
> Modified: vim.eclass
> Log:
> Migrating vim.eclass from bash-completion.eclass to
> bash-completion-r1.eclass
>
> Also removing old blocker on 'app-vim/vimspell' which is no longer in the
> tree.
>
> Revision ChangesPath
> 1.201eclass/vim.eclass
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/vim.eclass?rev=1.201&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/vim.eclass?rev=1.201&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/vim.eclass?r1=1.200&r2=1.201
>
> Index: vim.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/vim.eclass,v
> retrieving revision 1.200
> retrieving revision 1.201
> diff -u -r1.200 -r1.201
> --- vim.eclass20 Aug 2011 15:46:21 - 1.200
> +++ vim.eclass28 Nov 2011 18:13:42 - 1.201
> @@ -1,6 +1,6 @@
> # Copyright 1999-2011 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/eclass/vim.eclass,v 1.200 2011/08/20
> 15:46:21 lack Exp $
> +# $Header: /var/cvsroot/gentoo-x86/eclass/vim.eclass,v 1.201 2011/11/28
> 18:13:42 lack Exp $
>
> # Authors:
> #Jim Ramsay
> @@ -31,7 +31,7 @@
> PYTHON_USE_WITH_OPT="python"
> PYTHON_USE_WITH="threads"
> fi
> -inherit eutils vim-doc flag-o-matic versionator fdo-mime bash-completion
> prefix python
> +inherit eutils vim-doc flag-o-matic versionator fdo-mime bash-completion-r1
> prefix python
>
> HOMEPAGE="http://www.vim.org/";
> SLOT="0"
> @@ -95,7 +95,6 @@
> acl? ( kernel_linux? ( sys-apps/acl ) )
> ruby?( =dev-lang/ruby-1.8* )
> ! - !app-vim/vimspell
> ! ! ! @@ -625,9 +624,9 @@
>
> # bash completion script, bug #79018.
> if [[ ${MY_PN} == "vim-core" ]] ; then
> - dobashcompletion "${FILESDIR}"/xxd-completion xxd
> + newbashcomp "${FILESDIR}"/xxd-completion xxd
> else
> - dobashcompletion "${FILESDIR}"/${MY_PN}-completion ${MY_PN}
> + newbashcomp "${FILESDIR}"/${MY_PN}-completion ${MY_PN}
> fi
> # We shouldn't be installing the ex or view man page symlinks, as they
> # are managed by eselect-vi
> @@ -723,12 +722,6 @@
>
> echo
>
> - # Display bash-completion message
> - if [[ ${MY_PN} == "vim-core" ]] ; then
> - export BASHCOMPLETION_NAME="xxd"
> - fi
> - bash-completion_pkg_postinst
> -
> # Make convenience symlinks
> if [[ ${MY_PN} != "vim-core" ]] ; then
> # But only for vim/gvim, bug #252724
>
>
>
>
Re: [gentoo-dev] Packages looking for proxy as ian no longer has commit access
On Thu, 2011-11-24 at 17:25 +0100, Ulrich Mueller wrote: > > On Thu, 24 Nov 2011, Pacho Ramos wrote: > > > Due https://bugs.gentoo.org/show_bug.cgi?id=99016 ian doesn't > > have commit access and, then, his packages need a proxy maintainer: > > app-portage/autounmask > > app-portage/demerge > > I would volunteer to proxy maintain these packages, if Christian still > wants to be maintainer for them (his last commit was in 2009). If not, > proxy maintainership doesn't make much sense. > Ulrich, If we decide to proxy maintain these two packages, go ahead and add tool-portage as the herd to back you up. Regards, Paul
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Mon, Nov 28, 2011 at 3:06 AM, Michał Górny wrote: > Have you considered time overhead of moving files in unnatural order? Rather than re-discuss this point it would probably be better for everybody to just read through the entire thread again, particularly Cirian's post and its follow-ups. My understanding is that the patch has already been reverted. Now, if somebody has a suggestion for how to sort the files in such a way as to improve the performance (assuming that it doesn't already happen in inode order) that would certainly take things forward. Sorting lists in RAM is cheap, disk seeks are expensive. Of course, if you're using tmpfs it is either all in RAM or in swap in the first place, and I'm not sure if swap brings in additional considerations here. Rich
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sun, 27 Nov 2011 23:28:12 +0100 Arfrever Frehtes Taifersar Arahesis wrote: > 2011-11-26 11:58:22 Fabian Groffen napisał(a): > > On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis > > wrote: > > > commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0 > > > T> Org> > > > AuthorDate: Sat Nov 26 01:52:49 2011 + > > > Commit: Arfrever Frehtes Taifersar Arahesis > > > gentoo org> CommitDate: Sat Nov 26 01:52:49 2011 + > > > URL: > > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d4ac47c > > > > > > dblink.mergeme(): Merge files in alphabetic order. > > > > What's the advantage of this? > > The advantage is that this allows to easier review output of `emerge` > to verify if correct files have been installed. > > > I don't really like to pay for sorting a potentially huge list just > > for some eye-candy. > > Time of sorting in case of Linux sources is less than 0.05 s. Have you considered time overhead of moving files in unnatural order? -- Best regards, Michał Górny signature.asc Description: PGP signature
