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 S
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 m
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 x11-drivers/xf86
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
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 wi
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 fixe
"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
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote:
> 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 th
-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 e
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...
>
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 test it.. and that part is annoying..
If you don't like it, d
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
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 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
On Friday 10 October 2008, Ciaran McCreesh wrote:
> 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
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
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 encount
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 gr
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 th
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 seve
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
ge
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.
> >
> >
> > Ciaran, I would think at 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 sys-apps/porta
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.
>
>
> Ciaran, I would think at this point you know this since you've seen
> this brought up hundreds of times on thi
Ciaran McCreesh wrote:
> Unfortunately Portage and Pkgcore have broken EAPI 2 implementations.
>
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 plac
-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 rathe
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 t
-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
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 te
> 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 wo
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-
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' c
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: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 expor
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 EAPI<2?
Export it if and
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 clo
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 i
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, cou
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 simul
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
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 vo
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 o
-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].
>>
>> ~
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
> ~ cas
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
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..
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 patc
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, 0
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 subtrac
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 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 disc
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 gitw
-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
> v
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 sign
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 extension.
I don't see any problems
-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 offici
Zac Medico kirjoitti:
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 proposal and consider voti
-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
member
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 th
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
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?
> >
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
В Пнд, 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 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 avoid
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?
>
>
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 gitwe
В Срд, 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 t
On 11-06-2008 20:24:18 +0100, Roy Marples wrote:
> On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
> > On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > > David Leverton <[EMAIL PROTECTED]> wrote:
> > > > Since at least one ebuild has already been modified specifically to
> > > > wor
On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
> On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > 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 tho
On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> 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?
http://tin
Ciaran McCreesh 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
and pretty).
Nice game, still you aren't giving substance
> 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 doe
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 ar
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
Des
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 15:20:55 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
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.
It really doesn't matter how it is specified. You have an
im
On Wednesday 11 June 2008 14:20:55 Luca Barbato wrote:
> Bernd Steinhauser wrote:
> > 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
Since at least one ebuild has already been modified specifica
On Wed, 11 Jun 2008 15:20:55 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> 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.
> > It really doesn't matter how it is specified. You have an
> > implementation of it a
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
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 EAPI
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
change
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
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 th
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 versi
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 t
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 o
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 un
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 un
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 strai
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
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 are
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 x11-libs
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
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
http://www.pkgcore.org/trac/pkgco
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
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 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.
>
>
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.
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: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 fair
1 - 100 of 141 matches
Mail list logo
