This is your one-day friendly reminder ! The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net. See the
channel topic for the exact time (but it's probably 2000 UTC).
If you're supposed to show up, please show up. If you're not supposed
to show up, then show up
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons that lead you to this decision so
that interested readers can make their own opinion?
Cheers,
-jkt
--
cd /local/pub more beer /dev/mouth
signature.asc
Description: OpenPGP digital
Doug Klima kirjoitti:
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi
I think it was answered.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
On K, 2007-12-12 at 07:07 +0200, Alon Bar-Lev wrote:
On 12/12/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote:
...We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support.
As I told you
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons that lead you to this decision so
that interested readers can make their own opinion?
http://bugs.gentoo.org/show_bug.cgi?id=159623
Best
On 12/12/07, Mart Raudsepp [EMAIL PROTECTED] wrote:
With no slotting I can bet on GnuPG-1 going away shortly after all
architectures have stabled GnuPG-2,
gpg-1.X series will be available as long as upstream maintain it.
or is that not so and such users can
mask =GnuPG-1.9 and keep using a
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima [EMAIL PROTECTED] wrote:
discuss.
* EAPI may only be set before the 'inherit' in an ebuild.
* Eclasses may not set EAPI.
* Eclasses may not assume a particular EAPI.
* If an eclass needs to work with multiple EAPIs, EAPI-specific code
should be
On Dec 12, 2007 1:21 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima [EMAIL PROTECTED] wrote:
discuss.
* EAPI may only be set before the 'inherit' in an ebuild.
* Eclasses may not set EAPI.
* Eclasses may not assume a particular EAPI.
* If an
Petteri Räty wrote:
Doug Klima kirjoitti:
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi
I think it was answered.
Regards,
Petteri
And I brough up valid
On Wed, 12 Dec 2007 15:08:36 +0100
Santiago M. Mola [EMAIL PROTECTED] wrote:
Would it be possible to have eclass/eapiBLAH/foo.eclass?
No. Not even with an EAPI change. This is one of the deficiencies in
the way EAPI was designed -- an EAPI cannot change the behaviour of
inherit, nor can it
On Wed, 12 Dec 2007 09:20:02 -0500
Doug Klima [EMAIL PROTECTED] wrote:
And I brough up valid reasons with zmedico why putting it before the
inherit line was flawed currently since it could lead to some
seriously unexpected behavior.
It's only unexpected if people screw up. If everyone
Ciaran McCreesh wrote:
On Tue, 11 Dec 2007 16:59:28 -0500
Doug Klima [EMAIL PROTECTED] wrote:
discuss.
* EAPI may only be set before the 'inherit' in an ebuild.
* Eclasses may not set EAPI.
* Eclasses may not assume a particular EAPI.
* If an eclass needs to work with multiple
Hi everyone,
this is a reminder especially for architecture people: Please use the
ChangeLog and really log everything you did. Don't do a change and
forget to document it. Oh and please don't forget to remove your
arches from the cc field if there is a bug.
V-Li
--
Christian Faulhammer,
On Wed, 12 Dec 2007 09:22:41 -0500
Doug Klima [EMAIL PROTECTED] wrote:
My point is it's fine to state this, however there needs to be
enforcement of this in the associated utilities. repoman, etc.
Unfortunately, eclasses are not checked at all at commit time, which
would allow developers to
On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons that lead you to this decision so
that interested readers can make their own
On Wednesday 12 of December 2007 15:20:19 Ciaran McCreesh wrote:
The .ebuild-eapi proposal didn't have this problem, but unfortunately it
was rejected for political reasons...
I wasn't around then, but the requirment of actually sourcing the ebuild to
read the EAPI value is extremely stupid
Ciaran McCreesh wrote:
On Wed, 12 Dec 2007 09:20:02 -0500
Doug Klima [EMAIL PROTECTED] wrote:
And I brough up valid reasons with zmedico why putting it before the
inherit line was flawed currently since it could lead to some
seriously unexpected behavior.
It's only unexpected if
Alon Bar-Lev wrote:
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons that lead you to this decision so
that interested readers can make their own opinion?
On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote:
Slotting makes logic if there is some advantage of having both slots
installed at the same machine,
Guess it's never been clear to you in upstream announcement that gnupg-1
BENEFITS from gnupg-2 co-existing. Again go back and read the
Christian Faulhammer wrote:
Hi everyone,
this is a reminder especially for architecture people: Please use the
ChangeLog and really log everything you did. Don't do a change and
forget to document it. Oh and please don't forget to remove your
arches from the cc field if there is a bug.
On Dec 12, 2007 4:08 PM, William L. Thomson Jr. [EMAIL PROTECTED] wrote:
On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons
Christian Faulhammer wrote:
Hi everyone,
this is a reminder especially for architecture people: Please use the
ChangeLog and really log everything you did. Don't do a change and
forget to document it. Oh and please don't forget to remove your
arches from the cc field if there is a bug.
William L. Thomson Jr. wrote:
On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
Could you provide a link to reasons that lead you to this
On Wed, 2007-12-12 at 11:11 -0500, Doug Klima wrote:
William L. Thomson Jr. wrote:
Why don't you step up and offer to help maintain this?
If your asking me, because I am already over committed. I can't be in
all places doing all things. Plus in this regard I am just a user, and
we should
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
* Eclasses may not set EAPI.
* Eclasses may not assume a particular EAPI.
I disagree here. It would be annoying and possibly even hindering in future
not being able to use higher EAPI features in eclasses. Point is the eclass
has to
On Dec 12, 2007 11:14 PM, Carsten Lohrke [EMAIL PROTECTED] wrote:
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
* Eclasses may not set EAPI.
* Eclasses may not assume a particular EAPI.
I disagree here. It would be annoying and possibly even hindering in future
not being able to
On Wed, 12 Dec 2007 23:14:24 +0100
Carsten Lohrke [EMAIL PROTECTED] wrote:
I disagree here. It would be annoying and possibly even hindering in
future not being able to use higher EAPI features in eclasses. Point
is the eclass has to check, if the author of an ebuild sets another
EAPI and
On Tue, 11 Dec 2007 20:00:51 -0500
Doug Klima [EMAIL PROTECTED] wrote:
When you could simply have $pkg_manager execute an eclass as 1
EAPI, another eclass as another and the ebuild as a third EAPI and
simplify it for the eclass maintenance.
Which doesn't work at all. Simple example would be
On Wed, Dec 12, 2007 at 10:03:56AM -0500, William L. Thomson Jr. wrote:
On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote:
Slotting makes logic if there is some advantage of having both slots
installed at the same machine,
Guess it's never been clear to you in upstream announcement that
On Wed, 2007-12-12 at 20:46 -0800, Robin H. Johnson wrote:
See the attached diff between the argument parsing.
Ok, thank you
I warned you last time, that it wasn't commandline argumnents, but
configure file arguments.
Part of that was going from the wrapper to replicate missing commands or
30 matches
Mail list logo
