On Thu, Jun 6, 2019 at 8:07 AM Andreas K. Huettel
wrote:
> Hi all,
>
> for the package maintainers among you, here's the list of remaining EAPI=2
> packages. Please help getting the number down to zero soon!!!
>
> Cheers,
> Andreas
>
> media-fonts/culmus-0.120-r4
>
>
Done.
On 6/6/19 1:06 AM, Andreas K. Huettel wrote:
> Hi all,
>
> for the package maintainers among you, here's the list of remaining EAPI=2
> packages. Please help getting the number down to zero soon!!!
>
> ...
> net-analyzer/nagtrap-0.1.3
Last release in 2008, no maintainer, dead homepage, dead
On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote:
Robert R. Russell wrote:
My personal opinion on this matter is pick one of the following:
1) perform the bugfix without a version bump and remain at the current
EAPI version
2) perform the bugfix with a version bump and remain
Robert R. Russell wrote:
My answer is a simple example from my own system. My current system uses a
motherboard that is around 6 months old and is only correctly supported by
the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old
nvidia card, works great with
why offlist?
Robert R. Russell wrote:
Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't
likely to go any where given the number of issues people are asking about on
the forums
But the important thing is that you notify the maintainers that you're
in trouble. That
Robert R. Russell [EMAIL PROTECTED] writes:
3) perform the bugfix with a version bump and upgrade to the latest EAPI
Options 1 and 2 are how most updates are done, the user can mask the latest
version or upgrade. Option 3 allows the user to continue using the previous
version while they
Jean-Marc Hengen wrote:
tree and my policies (more precisely: I can't keep current stable
portage and cmake-2.6.2). My solution to the problem, was to copy the
ebuild in /var/db/pkg to my local overlay and I'm fine with it for now.
The drawback of this workaround is, I could miss important
Robert R. Russell wrote:
My personal opinion on this matter is pick one of the following:
1) perform the bugfix without a version bump and remain at the current EAPI
version
2) perform the bugfix with a version bump and remain at the current EAPI
version
3) perform the bugfix with a
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote:
So this is about, if the current policy for using EAPI 2 in the tree
is really good or it should be improved, when introducing future
EAPI's, where portage supporting that EAPI is still unstable. My
proposal would be, to only use
On Mon, 08 Dec 2008 19:09:50 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
I'd like to go further and ask that for the next EAPI change, we only
allow ebuilds using it into the tree once a version of portage that
supports it has gone stable. And then, not make any ebuild with the
new EAPI
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:09:50 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
I'd like to go further and ask that for the next EAPI change, we only
allow ebuilds using it into the tree once a version of portage that
supports it has gone
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
The testing should be two phased, the first for regression (against
existing ebuilds), and once thats stable, then we can test with new
ebuilds...
Uh,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
The can be tested properly phase is when it's in ~arch...
That also means that to pull a significant number of ebuilds it forces
mostly everyone to
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote:
snip
This mail is about EAPI usage in the portage tree. Let me describe it,
with what happened today: I'm running a mostly stable system (91 of 1255
installed packages are unstable), but I test here and there some
packages. On of
On Fri, 2008-10-10 at 00:55 +0100, Ciaran McCreesh wrote:
On Thu, 9 Oct 2008 16:38:56 -0700
Brian Harring [EMAIL PROTECTED] wrote:
Of that 308, number of ebuilds that either inherit java-utils (which
adds src_prepare), define their own src_prepare, or even *match*
default via grepping in
On Thu, Oct 9, 2008 at 3:34 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
On Thu, 9 Oct 2008 15:22:19 -0700
Brian Harring [EMAIL PROTECTED] wrote:
So where exactly is this sky is falling issue you're worried
about? Bugs happen.
It means anyone using EAPI 2 now is going to encounter severe
On Fri, 10 Oct 2008 09:32:44 +0300
Mart Raudsepp [EMAIL PROTECTED] wrote:
Of those, and those in overlays, and those that are going to be
committed over the next few weeks, how many use src_prepare to apply
security related patches?
A round zero. Security patches are going stable soon
Ciaran McCreesh wrote:
Unfortunately Portage and Pkgcore have broken EAPI 2 implementations.
snip
Ciaran, I would think at this point you know this since you've seen this
brought up hundreds of times on this list. The mailing list is not an
appropriate place to file bug reports. The proper
On Thu, 09 Oct 2008 17:47:36 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
Unfortunately Portage and Pkgcore have broken EAPI 2
implementations.
snip
Ciaran, I would think at this point you know this since you've seen
this brought up hundreds of times on this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
Unfortunately Portage and Pkgcore have broken EAPI 2 implementations.
So far as I can see:
Portage:
* doesn't implement the 'default' function correctly for src_prepare.
This is fixed and released in
On Thu, Oct 09, 2008 at 10:53:13PM +0100, Ciaran McCreesh wrote:
On Thu, 09 Oct 2008 17:47:36 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
Unfortunately Portage and Pkgcore have broken EAPI 2
implementations.
snip
Ciaran, I would think at this point you
On Thu, 9 Oct 2008 15:22:19 -0700
Brian Harring [EMAIL PROTECTED] wrote:
So where exactly is this sky is falling issue you're worried
about? Bugs happen.
It means anyone using EAPI 2 now is going to encounter severe
breakages with Pkgcore. Simply put, all your Pkgcore users are going to
get
On Thu, Oct 09, 2008 at 11:34:59PM +0100, Ciaran McCreesh wrote:
On Thu, 9 Oct 2008 15:22:19 -0700
Brian Harring [EMAIL PROTECTED] wrote:
So where exactly is this sky is falling issue you're worried
about? Bugs happen.
It means anyone using EAPI 2 now is going to encounter severe
On Thu, 9 Oct 2008 16:38:56 -0700
Brian Harring [EMAIL PROTECTED] wrote:
Of that 308, number of ebuilds that either inherit java-utils (which
adds src_prepare), define their own src_prepare, or even *match*
default via grepping in the ebuild is 20.
Of those, and those in overlays, and those
On Sun, 5 Oct 2008 15:36:30 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:
How should exporting of src_configure in eclasses be handled? Should
it be conditional, depending on the EAPI? Or is it O.K. to export
src_configure unconditionally, since it doesn't harm for EAPI2?
Export it if and only
On Sun, 5 Oct 2008 15:07:27 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Sun, 5 Oct 2008 15:36:30 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:
How should exporting of src_configure in eclasses be handled? Should
it be conditional, depending on the EAPI? Or is it O.K. to export
On Sun, 5 Oct 2008 16:15:46 +0200
Alexis Ballier [EMAIL PROTECTED] wrote:
An eapi.eclass with such functions and lists of eapi features
maintained there could help though.
The problem is, 'features' change between EAPIs. For example, all three
EAPIs have src_compile, but it does different
On Sun, 5 Oct 2008 15:24:20 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Sun, 5 Oct 2008 16:15:46 +0200
Alexis Ballier [EMAIL PROTECTED] wrote:
An eapi.eclass with such functions and lists of eapi features
maintained there could help though.
The problem is, 'features' change
On Sun, 5 Oct 2008 17:07:40 +0200
Alexis Ballier [EMAIL PROTECTED] wrote:
Maybe eclasses should die on unknown eapi; the fact is I really hate
the current way it's done when switching an ebuild to EAPI-2 which
uses an eclass that exports src_compile; most eclasses don't special
case eapi-2 yet
On Sun, 5 Oct 2008, Alexis Ballier wrote:
Ciaran McCreesh [EMAIL PROTECTED] wrote:
Export it if and only if EAPI is 2.
By the way, do we really want to special case eapi-2 in every eclass ?
That's lot of code duplication and will get even worse when we'll reach
eapi-42. That would have
On Sun, 5 Oct 2008 17:38:11 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:
By the way, do we really want to special case eapi-2 in every
eclass ? That's lot of code duplication and will get even worse
when we'll reach eapi-42. That would have been cool to have a pm
function that tells has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 5 Oct 2008 17:07:40 +0200
Alexis Ballier [EMAIL PROTECTED] wrote:
Maybe eclasses should die on unknown eapi; the fact is I really hate
the current way it's done when switching an ebuild to EAPI-2 which
uses an
On Sun, 05 Oct 2008 10:11:08 -0700
Zac Medico [EMAIL PROTECTED] wrote:
They can call 'die' in global scope. Perhaps it's not the nicest
thing to do, but it can be done.
Last time I tried it, Portage behaved rather horribly with global scope
dies. Is this still the case?
Considering that they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 05 Oct 2008 10:11:08 -0700
Zac Medico [EMAIL PROTECTED] wrote:
They can call 'die' in global scope. Perhaps it's not the nicest
thing to do, but it can be done.
Last time I tried it, Portage behaved rather
Ciaran McCreesh kirjoitti:
On Sun, 14 Sep 2008 15:28:09 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 21:55 Sun 14 Sep , Ciaran McCreesh wrote:
On Sun, 14 Sep 2008 23:51:11 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Hopefully someone formats it to a real GLEP before that.
git clone
Jan Kundrát wrote:
Michael Hammer wrote:
But for me it's still questionable why we don't have a gentoo project
for this important task?
You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?
Cheers,
-jkt
This page is incomplete and needs some more details added to it. The
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
~ * The meaning of the !atom blocker syntax now implies that
~ temporary simultaneous installation of conflicting packages is
~ allowed [3].
~ * A new !!atom blocker syntax is now supported, for use in special
~ cases in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Lohrke wrote:
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
~ * The meaning of the !atom blocker syntax now implies that
~ temporary simultaneous installation of conflicting packages is
~ allowed [3].
~ * A new
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
Tobias Scherbaum wrote:
Luca Barbato wrote:
I don't see any problems with it.
+1
Tobias
+1
Since this latest version hasn't generated any noticeable disagreement, could
the Council please formally vote on it at the
David Leverton kirjoitti:
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
Tobias Scherbaum wrote:
Luca Barbato wrote:
I don't see any problems with it.
+1
Tobias
+1
Since this latest version hasn't generated any noticeable disagreement, could
the Council please formally
On Sun, 14 Sep 2008 23:51:11 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Hopefully someone formats it to a real GLEP before that.
git clone git://git.overlays.gentoo.org/proj/pms.git
git diff origin/master..origin/eapi-2
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sonntag, 14. September 2008, Zac Medico wrote:
Well, I'm open to alternative suggestions. Please see the previous
email in which I've attempted to explain the reasoning for the given
approach [1]. It seems to me that this approach is well suited for
solving cases in which temporary
On 21:55 Sun 14 Sep , Ciaran McCreesh wrote:
On Sun, 14 Sep 2008 23:51:11 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Hopefully someone formats it to a real GLEP before that.
git clone git://git.overlays.gentoo.org/proj/pms.git
git diff origin/master..origin/eapi-2
Ciaran, could you
Hi folks!
I am not involved in creating the EAPI 2 draft but I am interested in
the discussion and would like to track the technical evolution but
this seams nearly impossible as you're not able to agree on a public
draft document.
* Ciaran McCreesh [EMAIL PROTECTED] [080911 20:02]:
On Mon, 08
On Fri, 12 Sep 2008 08:28:52 +0200
Michael Hammer [EMAIL PROTECTED] wrote:
- An official (by the council accepted) VCS repo (a la git) for the
document (EAPI draft or even the PMS spec?)
Uh, already exists.
- An interface (mailing address) where everyone interested can submit
a patch for
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 9 Sep 2008 22:14:57 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:
I was personally expecting to see some sort of section called
EAPI-1 that contains something like:
EAPI-1 consists of EAPI-0 with the following features added...
Have a look
On Fri, 12 Sep 2008 14:14:51 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:
Unrelated topic: What packages are actually required to 'make
pms.pdf' so I can actually read it? I get:
Have a look at the dependencies for app-doc/pms.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 08 Sep 2008 23:34:28 +
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote:
So we're talking about adding the following to EAPI-2:
Are we treating PROPERTIES as purely optional and having no defined
values for EAPI 2 then?
--
Ciaran McCreesh
signature.asc
Description: PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 08 Sep 2008 23:34:28 +
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote:
So we're talking about adding the following to EAPI-2:
Are we treating PROPERTIES as purely optional and having no defined
values for
Luca Barbato wrote:
Jorge Manuel B. S. Vicetto wrote:
Hi again.
Quoting Zac earlier in #gentoo-portage:
21:46 zmedico jmbsvicetto: I think we essentially have a spec already
that people can agree on. just take my draft and subtract the eapi*
functions and the gitweb unpack
On Mon, 08 Sep 2008 23:34:28 +
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote:
Given the earlier discussion about EAPI-2 in
http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml
and cardoe's earlier request to the council ml, can the council
members discuss
On Tue, 9 Sep 2008 22:14:57 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:
I was personally expecting to see some sort of section called EAPI-1
that contains something like:
EAPI-1 consists of EAPI-0 with the following features added...
Have a look at the eapi-differences-summary branch on
Tobias Scherbaum wrote:
Luca Barbato wrote:
Jorge Manuel B. S. Vicetto wrote:
Hi again.
Quoting Zac earlier in #gentoo-portage:
21:46 zmedico jmbsvicetto: I think we essentially have a spec already
that people can agree on. just take my draft and subtract the eapi*
functions
On Tue, 9 Sep 2008 22:14:57 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:
What about the PMS EAPI 1 documentation do you consider 'not
proper'?
I was personally expecting to see some sort of section called EAPI-1
that contains something like:
EAPI-1 consists of EAPI-0 with the following
Ciaran McCreesh kirjoitti:
On Tue, 09 Sep 2008 16:31:08 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council
members discuss this proposal and consider voting it?
Does anyone have any objections to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
Ciaran McCreesh kirjoitti:
On Tue, 09 Sep 2008 16:31:08 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council
members discuss this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
Zac Medico kirjoitti:
Petteri Räty wrote:
Are you saying that the docs in my dev space don't count?
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1
They don't have any official status as far
On Tue, 09 Sep 2008 16:31:08 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council
members discuss this proposal and consider voting it?
Does anyone have any objections to this proposal?
I won't
Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council members
discuss this proposal and consider voting it?
Does anyone have any objections to this proposal?
I won't approve it for use in the tree before it's written as a GLEP in
order to
В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
So we're talking about adding the following to EAPI-2:
While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2? I've reviewed discussions on -dev
[1],[2] and bug 138792 [3] and seems that
On Tue, 09 Sep 2008 20:45:52 +0400
Peter Volkov [EMAIL PROTECTED] wrote:
В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
So we're talking about adding the following to EAPI-2:
While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2?
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 09 Sep 2008 16:31:08 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council
members discuss this proposal and consider voting it?
Does anyone
Jorge Manuel B. S. Vicetto wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again.
Quoting Zac earlier in #gentoo-portage:
21:46 zmedico jmbsvicetto: I think we essentially have a spec already
that people can agree on. just take my draft and subtract the eapi*
functions and the gitweb
В Срд, 11/06/2008 в 07:53 +0200, Luca Barbato пишет:
Getting the build time from 30minutes to an hour or more?
Actually I don't understand this concern. If you bother about time
tests take don't build package from sources - use binary packages. If
you build program by yourself - run testsuite
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
A whole bunch of science packages have upstreams that say If you're
building from source, run 'make check' and if it fails don't carry
on.
Their rationale behind that is that their code is severely broken,
using
On Wed, 11 Jun 2008 07:58:44 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
Oh, so Gentoo has decided that basic QA is another 'poor programming
practice' now?
Having a good testsuite is part of the QA, having it not failing is
part of the QA, running it for supposedly
Ciaran McCreesh wrote:
On Tue, 10 Jun 2008 17:11:23 -0700
Brian Harring [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED]
wrote:
At this point, we should really only discuss features that all
On Wed, 11 Jun 2008 08:01:30 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:49:44 +0200
Alexis Ballier [EMAIL PROTECTED] wrote:
I thought tests were already supposed to pass whatever the EAPI is
and devs were supposed to run them...
On Wed, 11 Jun 2008 08:02:48 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Had you bothered to write even trivial test suites for EAPI 1,
you'd've found at least one major bug straight away.
http://www.pkgcore.org/trac/pkgcore/newticket
http://www.pkgcore.org/trac/pkgcore/ticket/197
--
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
A whole bunch of science packages have upstreams that say If you're
building from source, run 'make check' and if it fails don't carry
on.
Their rationale behind that is that their code is severely
On Wed, 11 Jun 2008 08:50:47 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
And saving your ass when you're using a broken compiler that
generates broken code that would force you to reinstall a working
compiler by hand when the package manager gets h0rked.
You (upstream) are supposed to
On Wed, 11 Jun 2008 08:55:16 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
But more importantly, it still means that people *know* that a
failing src_test is to be investigated. Currently they instead have
to guess whether it's a lazy developer issue or a genuine bug being
shown.
Not
On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers.
It's fairly well established that a lot of them don't, particularly
on Gentoo.
if your code sucks isn't our fault. - gcc
Ciaran McCreesh wrote:
Sure it will. They won't be able to install their package without
either passing src_test or restricting it.
Developers *do* try to install things before committing, right?
No, they also write the ebuilds using cat /dev/urandom through a perl
regexp.
But more
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers.
It's fairly well established that a lot of them don't, particularly
on Gentoo.
if your code sucks isn't our
On Wed, 11 Jun 2008 09:14:03 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers.
It's fairly well established
Ciaran McCreesh wrote:
Ok, if EAPI 2 turns on src_test except where explicitly overridden by
the ebuild, explain how EAPI 2 src_test failures are meaningless in the
same way that EAPI 0/1 src_test failures are.
Test failures aren't meaningless right now. Applications with good test
suites got
On Wed, 11 Jun 2008 09:18:07 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
Ok, if EAPI 2 turns on src_test except where explicitly overridden
by the ebuild, explain how EAPI 2 src_test failures are meaningless
in the same way that EAPI 0/1 src_test failures are.
Test
On Wed, Jun 11, 2008 at 08:18, Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
Ok, if EAPI 2 turns on src_test except where explicitly overridden by
the ebuild, explain how EAPI 2 src_test failures are meaningless in the
same way that EAPI 0/1 src_test failures are.
Test
On 00:11 Wed 11 Jun , Bo Ørsted Andresen wrote:
I would like the portage devs to comment upon which of the following features
they think could easily be implemented before portage 2.2 goes stable.
These ones meet the criteria of I know people are working around them
because they don't
On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato [EMAIL PROTECTED] wrote:
A whole bunch of science packages have upstreams that say If you're
building from source, run 'make check' and if it fails don't carry on.
Their rationale behind that is that their code is severely broken, using
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:02:48 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Had you bothered to write even trivial test suites for EAPI 1,
you'd've found at least one major bug straight away.
http://www.pkgcore.org/trac/pkgcore/newticket
On Wed, 11 Jun 2008 06:55:45 -0400
Richard Freeman [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:02:48 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Had you bothered to write even trivial test suites for EAPI 1,
you'd've found at least one major bug straight away.
On Wed, Jun 11, 2008 at 08:23:59AM +0100, Richard Brown wrote:
Also, I think you seem to be suggesting that gentoo is so well tested
that once something's marked stable, there's no point in testing it.
A very good point. Just last week the *stable* perl cairo bindings were
broken by a
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick unit tests would catch straight away.
No, you
Santiago M. Mola wrote:
It's not as simple as that. A package may fail tests because compiler
bugs, build environment misconfiguration, problems in a library which
is being used, a setup problem or, of course, a bug in the package
which shows up in rare cases and haven't been spotted by upstream
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick unit tests would catch
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick
On Wed, 11 Jun 2008 14:49:19 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Why is Create tests for EAPI=1 stuff. not a way to describe how
to reproduce a problem?
because EAPI1 isn't specified completely so you don't have a large
field to cover but you also do not know the bounds of it.
Patrick Lauer schrieb:
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup
Ciaran McCreesh wrote:
EAPI 1 is entirely specified in terms of a diff against EAPI 0.
That doesn't have a complete definition by itself.
Checking every part that's changed before releasing an EAPI 1 package
manager is the least any responsible person would do. That they would
release a
Luca Barbato schrieb:
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup
On Wed, Jun 11, 2008 at 02:00:19PM +0100, Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 14:49:19 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Why is Create tests for EAPI=1 stuff. not a way to describe how
to reproduce a problem?
because EAPI1 isn't specified completely so you don't have
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick
On Wed, 11 Jun 2008 15:05:47 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
EAPI 1 is entirely specified in terms of a diff against EAPI 0.
That doesn't have a complete definition by itself.
It's more than enough to write unit tests to ensure that all things
changed from
On Wed, 11 Jun 2008 06:08:20 -0700
Brian Harring [EMAIL PROTECTED] wrote:
Ya know ciaran, I've just got to point out that you spend quite a
large amount of time talking about pkgcore. Literaly- you talk about
it more then I do.
Unfortunately, since you don't care about implementing EAPIs
Bernd Steinhauser wrote:
He doesn't point any issue in particular.
And that wasn't the point. He pointed out, that there is an issue, that
hasn't been caught because of missing tests.
That may or may not exist
because EAPI1 isn't specified completely so you don't have a large
field to cover
David Leverton [EMAIL PROTECTED] wrote:
Since at least one ebuild has already been modified specifically to
work around the bug, I'd say it's pretty real.
For those of us trying to play along at home, which one is this?
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
On Wed, 11 Jun 2008 15:34:43 +0200
Patrick Lauer [EMAIL PROTECTED] wrote:
Presumably those people, if they exist, haven't tried to go through
and install every EAPI 1 package in the tree (excluding KDE, since
that's big and slow, and starting backwards since the x11-
categories are nice
If, as a user or an arch person, I get a src_test failure right now, I
don't know whether this means eek! Something's gone wrong, and I
really need to fix this or oh, whoever maintains this package
doesn't care. But with EAPI 2, I'll be able to know that a src_test
failure really does mean
1 - 100 of 132 matches
Mail list logo
