Re: [gentoo-dev] epatch: splitting out common options from user-specific ones

2012-04-19 Thread Mike Frysinger
On Thursday 19 April 2012 23:24:19 Mike Frysinger wrote: > @@ -445,6 +473,7 @@ epatch() { > local patch_cmd > while [[ ${count} -lt 5 ]] ; do > patch_cmd="${BASH_ALIASES[patch]:-patch} -p${count} > +einfo $patch_cmd > > # Gen

Re: [gentoo-dev] epatch: splitting out common options from user-specific ones

2012-04-19 Thread Mike Frysinger
no complaints, so here's the patch. precedence order is EPATCH_COMMON_OPTS then EPATCH_OPTS then whatever has been specified on the cmdline. so you can do: EPATCH_OPTS="-F0" epatch epatch -p0 epatch (more for highlighting precedence than a realistic use case) -m

[gentoo-dev] gnome2 and gnome2-utils eclass changes

2012-04-19 Thread Gilles Dartiguelongue
Per bug #301311 [1], I decided to fix a couple of issue I had with the current way of dealing with scrollkeeper. Even though scrollkeeper is almost dead, it is still present in quite a few gnome packages notably due to gnome-doc-utils.make and the goal of these changes is to make scrollkeeper a bi

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Robin H. Johnson
On Thu, Apr 19, 2012 at 05:31:11PM +0200, Corentin Chary wrote: > Add rubygems, github, gitorious, pecl, pear, bitbucket. > All of them are handled by my remoteids.py script. Can we get Launchpad added as well? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Corentin Chary
On Thu, Apr 19, 2012 at 6:54 PM, Michał Górny wrote: > On Thu, 19 Apr 2012 17:31:11 +0200 > Corentin Chary wrote: > >> -      > (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran) >> #REQUIRED> >> +      > (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Michał Górny
On Thu, 19 Apr 2012 20:08:09 +0200 ""Paweł Hajdan, Jr."" wrote: > On 4/19/12 5:31 PM, Corentin Chary wrote: > > Add rubygems, github, gitorious, pecl, pear, bitbucket. > > All of them are handled by my remoteids.py script. > > Just making sure: do github, gitorious and bitbucket provide file > h

[gentoo-dev] openssl-1.0.1* moving to unstable

2012-04-19 Thread Mike Frysinger
the openssl project has started a new trend in keeping minor versions ABI compatible. in the past, 0.9.7 and 0.9.8 had different SONAMEs (because they diff ABIs). but now with 1.0.1, the minor/patch versions should have the same SONAME and ABI. however, the new 1.0.1 ebuilds have been masked

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Paweł Hajdan, Jr.
On 4/19/12 5:31 PM, Corentin Chary wrote: > Add rubygems, github, gitorious, pecl, pear, bitbucket. > All of them are handled by my remoteids.py script. Just making sure: do github, gitorious and bitbucket provide file hosting? I know they host repos, but for most ebuilds where remote-id would be

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Michał Górny
On Thu, 19 Apr 2012 17:31:11 +0200 Corentin Chary wrote: > - (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran) > #REQUIRED> > + (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran|rubygems|github|gitorious|pecl|pear|bi

[gentoo-dev] RFC: Add new remote-id types in metadata.dtd

2012-04-19 Thread Corentin Chary
Add rubygems, github, gitorious, pecl, pear, bitbucket. All of them are handled by my remoteids.py script. ref: https://bugs.gentoo.org/show_bug.cgi?id=406287 ref: https://github.com/iksaif/portage-janitor/blob/master/remoteids.py --- a/metadata/dtd/metadata.dtd 2010-03-02 18:52:11.0 +010

Re: [gentoo-dev] plymouth maintainer-needed

2012-04-19 Thread Maxim Kammerer
On Wed, Apr 18, 2012 at 17:49, Alex Legler wrote: > On Wednesday 18 April 2012 16:03:09 Amadeusz Żołnowski wrote: >> Plymouth has plugin I have written for OpenRC (see its openrc use flag) >> which is more proof-of-concept rather something to be used really >> seriously, therefore best would be to