Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

On Fri, May 11, 2012 at 12:59:22AM +, Duncan wrote > It may very well be that a fork is thus required. I guess we wait and > see. But I don't see the kde folks being willingly subsumed into a > gnomeos black hole, and time and again, floss history has demonstrated > that when there's an i

Re: [gentoo-dev] RFC: check for enewuser, enewgroup outside of pkg_setup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/19/2011 11:44 PM, Mike Frysinger wrote: > this is why we allow people to pick the appropriate step. ebuilds > should be using pkg_{pre,post}inst unless the user/group is needed > at src_* time. -mike I noticed a rather annoying test inside en

Re: [gentoo-dev] pushing fixes to stable before closing bugs

> I noticed a general tendency to close bugs affecting stable before > pushing the fix to stable. > Right. > The idea is that if you only fix in ~arch, you risk a serious and > _known_ regression in stable, which could be easily avoided. > As already detailed by others, most of the time these bug

Re: [gentoo-dev] pushing fixes to stable before closing bugs

> I noticed a general tendency to close bugs affecting stable before > pushing the fix to stable. > > One recent example is , > but there are more. Not about the general question, but about this specific bug... I never really expected the Calligra

Re: [gentoo-dev] pushing fixes to stable before closing bugs

On Sat, May 12, 2012 at 4:01 PM, "Paweł Hajdan, Jr." wrote: > Agreed. I'm talking about compile errors or crashes here. I've really > seen arches stabilizing packages with known problems, just having closed > bugs because "the fix is in ~arch". We might already be on the same page, but I think th

Re: [gentoo-dev] pushing fixes to stable before closing bugs

On 5/12/12 6:28 PM, Rich Freeman wrote: > On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr." > wrote: >> The idea is that if you only fix in ~arch, you risk a serious and >> _known_ regression in stable, which could be easily avoided. > > How can you have a regression in stable if stable has th

Re: [gentoo-dev] Re: License groups in ebuilds

> On Sat, 12 May 2012, Ciaran McCreesh wrote: > On Sat, 12 May 2012 21:05:06 +0200 > Torsten Veller wrote: >> The perl-module.eclass offers a default LICENSE as >> LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}" >> >> So if a distribution uses "the same license as Perl 5 itself" you

[gentoo-dev] Re: License groups in ebuilds

* Ciaran McCreesh : > On Sat, 12 May 2012 21:05:06 +0200 > Torsten Veller wrote: > > The perl-module.eclass offers a default LICENSE as > > LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}" > > > > So if a distribution uses "the same license as Perl 5 itself" you can > > just drop the LICEN

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

* Corentin Chary : > On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote: > > { "term": { "status":"latest"} }, > > { "term": { "module.authorized":"true"}} What does this mean? - "latest"? this term looks like mainte

Re: [gentoo-dev] Re: License groups in ebuilds

On Sat, 12 May 2012 21:05:06 +0200 Torsten Veller wrote: > The perl-module.eclass offers a default LICENSE as > LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}" > > So if a distribution uses "the same license as Perl 5 itself" you can > just drop the LICENSE from the ebuild (as long no for

[gentoo-dev] Re: License groups in ebuilds

* Kent Fredric : > I'd welcome groups so we can have a "Perl_5" group. The lions share of > modules published on CPAN are licensed "Under the same license as Perl > 5 Itself", which implies "|| ( GPL-2 Artistic-1 )" Perl is licensed as | This program is free software; you can redistribute it and/

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

On 05/12/2012 06:50 PM, Samuli Suominen wrote: > Example, > > - Package is using autotools. > - The default phase like below works for the package: > > src_install() { > emake DESTDIR="${D}" install > dodoc README > } > > So when writing a new ebuild you would only add: > > DOCS="README" > > A

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

On 05/12/2012 06:50 PM, Samuli Suominen wrote: > Example, > > - Package is using autotools. > - The default phase like below works for the package: > > src_install() { > emake DESTDIR="${D}" install > dodoc README > } > > So when writing a new ebuild you would only add: > > DOCS="README" > > A

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

> On Sat, 12 May 2012, Michał Górny wrote: > On Sat, 12 May 2012 19:57:07 +0200 > Ulrich Mueller wrote: >> > The current workaround for this is to use EXTRA_EMAKE from ebuild, >> > but I find this rather ugly (if not even forbidden by some PMS >> > magic?) >> >> EXTRA_EMAKE isn't mentioned

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

On 05/12/2012 09:09 PM, Michał Górny wrote: On Sat, 12 May 2012 19:57:07 +0200 Ulrich Mueller wrote: The current workaround for this is to use EXTRA_EMAKE from ebuild, but I find this rather ugly (if not even forbidden by some PMS magic?) EXTRA_EMAKE isn't mentioned by the PMS. Do all packag

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

On Sat, 12 May 2012 19:57:07 +0200 Ulrich Mueller wrote: > > The current workaround for this is to use EXTRA_EMAKE from ebuild, > > but I find this rather ugly (if not even forbidden by some PMS > > magic?) > > EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers > support this variab

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

> On Sat, 12 May 2012, Samuli Suominen wrote: > Example, > - Package is using autotools. > - The default phase like below works for the package: > src_install() { > emake DESTDIR="${D}" install > dodoc README > } > So when writing a new ebuild you would only add: > DOCS="README" > And be d

[gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

Example, - Package is using autotools. - The default phase like below works for the package: src_install() { emake DESTDIR="${D}" install dodoc README } So when writing a new ebuild you would only add: DOCS="README" And be done with it. Then the next version of the package needs extra argume

Re: [gentoo-dev] pushing fixes to stable before closing bugs

On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr." wrote: > The idea is that if you only fix in ~arch, you risk a serious and > _known_ regression in stable, which could be easily avoided. How can you have a regression in stable if stable has the bug already? A regression is when you have a st

Re: [gentoo-dev] pushing fixes to stable before closing bugs

El sáb, 12-05-2012 a las 12:34 +0200, "Paweł Hajdan, Jr." escribió: > I noticed a general tendency to close bugs affecting stable before > pushing the fix to stable. > > One recent example is , > but there are more. > > The idea is that if you only

[gentoo-dev] pushing fixes to stable before closing bugs

I noticed a general tendency to close bugs affecting stable before pushing the fix to stable. One recent example is , but there are more. The idea is that if you only fix in ~arch, you risk a serious and _known_ regression in stable, which could be