I noticed a general tendency to close bugs affecting stable before
pushing the fix to stable.
One recent example is https://bugs.gentoo.org/show_bug.cgi?id=399291,
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
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 https://bugs.gentoo.org/show_bug.cgi?id=399291,
but there are more.
The idea is that if you only fix in
On Sat, May 12, 2012 at 6:34 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org 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
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
argument
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 done with it. Then
On Sat, 12 May 2012 19:57:07 +0200
Ulrich Mueller u...@gentoo.org 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
On 05/12/2012 09:09 PM, Michał Górny wrote:
On Sat, 12 May 2012 19:57:07 +0200
Ulrich Muelleru...@gentoo.org 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
On Sat, 12 May 2012, Michał Górny wrote:
On Sat, 12 May 2012 19:57:07 +0200
Ulrich Mueller u...@gentoo.org 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
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
And be done with
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
And be done with
* Kent Fredric kentfred...@gmail.com:
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
On Sat, 12 May 2012 21:05:06 +0200
Torsten Veller t...@gentoo.org 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
* Corentin Chary corentin.ch...@gmail.com:
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
* Ciaran McCreesh ciaran.mccre...@googlemail.com:
On Sat, 12 May 2012 21:05:06 +0200
Torsten Veller t...@gentoo.org 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
On Sat, 12 May 2012, Ciaran McCreesh wrote:
On Sat, 12 May 2012 21:05:06 +0200
Torsten Veller t...@gentoo.org 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
On 5/12/12 6:28 PM, Rich Freeman wrote:
On Sat, May 12, 2012 at 6:34 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org 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
On Sat, May 12, 2012 at 4:01 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org 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,
I noticed a general tendency to close bugs affecting stable before
pushing the fix to stable.
One recent example is https://bugs.gentoo.org/show_bug.cgi?id=399291,
but there are more.
Not about the general question, but about this specific bug... I never really
expected the Calligra
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 bugs
-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
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
21 matches
Mail list logo
