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
Hi,
I like to write about an observation about gentoo, I made the past
weeks, which does frustrate me personally a little bit, mainly because
it makes administration a bit harder for me. It could be considered as
an issue or as yet another case of When you play with unstable
packages, you're
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
13 matches
Mail list logo
