Re: [gentoo-dev] EAPI 2 is brokened :(

2008-10-10 Thread Mart Raudsepp
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 the ebuild is 20.
 
 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 after entering
portage tree, and EAPI=2 ebuilds can not go stable yet, as there is no
package manager supporting EAPI=2 that is going to be stable in the next
week or two (so maintainers make sure they don't use EAPI=2 for security
fix revisions).
And if the bug is there and properly filed to the appropriate bugzilla,
they wouldn't go stable before that bug is fixed (which I read are
already fixed).
I can not understand why this is dragged on. It was a bug, it is fixed.
The sky is not falling and EAPI-2 is not broken - there was a bug in the
implementation that is fixed.


-- 
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Monthly Gentoo Council Reminder for October

2008-10-10 Thread Alec Warner
On Thu, Oct 9, 2008 at 11:55 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Thu, 9 Oct 2008 09:25:55 -0500
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 On 05:30 Wed 01 Oct , Mike Frysinger wrote:
  If you have something you'd wish for us to chat about, maybe even
  vote on, let us know !  Simply reply to this e-mail for the whole
  Gentoo dev list to see.

 Nothing was submitted, so there will be no meeting today. We'll have
 a meeting in 2 weeks if anything comes up or if I missed something
 that for some reason was not posted in response to the usual
 announcement thread.

 I'm guessing it's too late to ask the Council to discuss the EAPI 2 is
 brokened :( thread? What would be the earliest the Council would be
 able to make a decision upon that? Unfortunately it's something that
 could get messy if left for too long.

All I see in the thread is you bringing up a known issue and then
everyone telling you it will be fixed or is in the process of being
fixed.

What kind of improvements are you looking for?  Be specific.


 --
 Ciaran McCreesh




Re: [gentoo-dev] EAPI 2 is brokened :(

2008-10-10 Thread Alec Warner
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
 breakages with Pkgcore. Simply put, all your Pkgcore users are going to
 get screwed over very messily as soon as they try to use any EAPI 2
 things. Is this not something we should be caring about?

I think everyone appreciates the forewarning (even if not everyone
appreciates the manner in which it was delivered).  I think we do care
and we are fixing it.  I believe the developers of said packages have
a different idea of the risks involved than you and I don't expect
everyone to agree on specific software development or release
processes.


 Frankly you're overreacting on this- and that is assuming you *are*
 overreacting instead of just going for a bit of a public smear
 via bugs.

 Bah. If you want me to lecture you on how you're being blatantly
 irresponsible and incompetent then I will do, although by the way you
 rush on the defensive and start trying to cover your ass by throwing
 accusations at me it looks like you already know it. But what I care
 about is getting the mess fixed in the most painless way possible.

 This is a real issue and developers need to know the implications.


If you want to call people names do it on your own lists.

 Either way, my vote is fix the bugs, leave EAPI2 as is, and in the
 future kindly file bugs properly (preferably w/out the noise, but
 I'll take usable bug reports in almost any form).

 If you want bug reports via trac instead of IRC, get your trac to
 respond faster.

 --
 Ciaran McCreesh




Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Fabian Groffen
On 10-10-2008 04:21:23 +0200, Marius Mauch wrote:
amd64-linux
x64-openbsd
x64-solaris
   
   Is there a special reason why you're using x64 instead of amd64
   in those cases? (IMO x64 is the most stupid name for the x86_64
   architecture)
  
  AFAIK, that's not amd64/x86_64, but rather ia64, aka itanic aka
  itanium. At least, that's how I'd interpret them since I've seen that
  abbreviation made before, particularly since there's already amd64 in
  context.
 
 No, x64 is the marketing name Microsoft made up for x86_64 (aka amd64,
 ia32e and Intel 64), as Windows for x86_64 doesn't sound that sexy,
 and was later adopted by Sun and others. 
 ia64/Itanium doesn't have any other alias names AFAIK.

We simply found that:
- amd64 is misleading
- em64t would be more to the point for some?
- x64 is what the vendors (Apple, Sun) advertise themselves
- amd64 doesn't make any sense for a Mac
- x64 is more like x86, whereas the complement of amd64 would more be
  i386 or ia32, but we wanted to avoid x86_64, x8664, so x64
- we were changing keywords anyway


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

2008-10-10 Thread Alec Warner
I don't want to be the guy that kicks people off lists; but I will do
it; so keep the thread on topic[0] and be nice[1].  I know everyone
here is capable of that.  Feel free to sling the personal crap
comments somewhere more appropriate (such as a personal diary, blog,
or in verbal complaints to a spouse or drinking buddy.)  Remember that
text is hard to communicate through and regardless of any intentions,
people are judged by how they are perceived and 'helpful' intentions
may not come off quite as helpful as some would like; chose your words
carefully.

Consider this your first and last warning from Userrel.

-Alec

[0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
[1] http://www.gentoo.org/proj/en/council/coc.xml



Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Fabian Groffen
On 10-10-2008 14:40:13 +0200, Diego 'Flameeyes' Pettenò wrote:
 Fabian Groffen [EMAIL PROTECTED] writes:
 
  - x64 is what the vendors (Apple, Sun) advertise themselves
 
 Err I'm sure I haven't seen any x64 in the documentation or
 advertisement of my MacBook Pro, are you sure _Apple_ uses that totally
 bogus name?

Ehm, no.  So I must have been confused.

 Anyway, em64t might be better, but then again you're to the same point:
 an Opteron using an Intel name? I think amd64 is totally fine since it's
 the first commercial name it got by uh, those who introduced it, I
 guess, but the only thing I don't ever want to see officially is
 endorsing the x64 commercial speak.

Whatever.  Some of you seem to have some quite agressive dislikement to
it.  In the end it's just a name/tag.  I guess I could live with
anything, including c3p0.


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Jeremy Olexa

Fabian Groffen wrote:
snip

Most notably, in Prefix all keywords are full GLEP53 style, which
results in e.g. amd64-linux.  We did this on purpose, because in Prefix
we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
nbsd and obsd to their long variants, mainly because the short variants
might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
over-enthausiastic.)

I would like to hear some opinions on the keywords in general, as well
as the particular problem of having Gentoo Linux, and a Linux supported
by Gentoo Prefix.  Right now there is just the difference of -linux
appended, however this is not the clearest distinction between the two.
Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
and should we use something like PREFIX_KEYWORDS?



Ignoring the bit about how to name the keywords.. ;)

I am undecided about Prefix keywords in the normal KEYWORDS variable. In 
particular, we are overloading the -linux keyword to mean that it will 
run on any linux that Gentoo Prefix supports. This includes, Gentoo, 
RHEL, SLES, FreeMint, $OTHER.


Is there any problem with overloading the keywords like that? If not, 
then it shouldn't be a problem to keep prefix keywords in the KEYWORDS 
field. OTOH, I don't think we should add another variable to ebuilds.


Thoughts?

-Jeremy




[gentoo-dev] Re: EAPI-2 and src_configure in eclasses

2008-10-10 Thread Duncan
Alec Warner [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on  Fri, 10 Oct 2008 00:17:14 -0700:

 Consider this your first and last warning from Userrel.

FWIW... at least on gmane, that appears as a response to aballier (gentoo 
dev), with references headers indicating the same thing, but given that 
(1) there was no attribution or quote so it's not possible to say who it 
was intended for directly, (2) I didn't see what was offensive in his 
post, and (3) that the warning was from userrel not devrel, I believe the 
warning was intended for someone other than the direct parent (my 
grandparent) poster.

IOW, aballier may be very confused right about now... I know I was but at 
least it's not my posts in the balance like his appear to be, while 
someone else (my public attempt at a guess who wouldn't help) may be 
missing a warning they need to see (tho hopefully they got the message in 
any case).

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Diego 'Flameeyes' Pettenò
Fabian Groffen [EMAIL PROTECTED] writes:

 - x64 is what the vendors (Apple, Sun) advertise themselves

Err I'm sure I haven't seen any x64 in the documentation or
advertisement of my MacBook Pro, are you sure _Apple_ uses that totally
bogus name?

Anyway, em64t might be better, but then again you're to the same point:
an Opteron using an Intel name? I think amd64 is totally fine since it's
the first commercial name it got by uh, those who introduced it, I
guess, but the only thing I don't ever want to see officially is
endorsing the x64 commercial speak.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpfWJJfNdLak.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI 2 is brokened :(

2008-10-10 Thread Ciaran McCreesh
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 after entering
 portage tree, and EAPI=2 ebuilds can not go stable yet, as there is no
 package manager supporting EAPI=2 that is going to be stable in the
 next week or two (so maintainers make sure they don't use EAPI=2 for
 security fix revisions).

Oh really? So you're absolutely certain there aren't and won't soon be
any EAPI 2 bumps of non-EAPI 2 versions that include security patches?
And you're absolutely certain that there aren't, say, any packages that
sed a broken chmod in a makefile in src_prepare?

 I can not understand why this is dragged on. It was a bug, it is
 fixed. The sky is not falling and EAPI-2 is not broken - there was a
 bug in the implementation that is fixed.

The point of EAPI is to avoid these kinds of problems. The process is
failing and the fallout needs to be handled.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Michael Haubenwallner

On Thu, 2008-10-09 at 20:11 +0200, Fabian Groffen wrote:

   ia64-hpux

There's one thing to say for this platform to avoid later confusion:

'ia64-hpux' is the keyword for 32bit on that platform.
'ia64w-hpux' would be the 64bit keyword (not in prefix-tree yet).

This might seem confusing, but is the way HP does for various reasons.

HP-UX is the only OS I know that does multilib on the ia64 CPU, and the
default compiler output is 32bit without any additional switch.

I can provide more details if necessary.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level




[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Ryan Hill
On Fri, 10 Oct 2008 09:15:16 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

  No, x64 is the marketing name Microsoft made up for x86_64 (aka
  amd64, ia32e and Intel 64), as Windows for x86_64 doesn't sound
  that sexy, and was later adopted by Sun and others. 
  ia64/Itanium doesn't have any other alias names AFAIK.
 
 We simply found that:
 - amd64 is misleading
 - em64t would be more to the point for some?
 - x64 is what the vendors (Apple, Sun) advertise themselves
 - amd64 doesn't make any sense for a Mac
 - x64 is more like x86, whereas the complement of amd64 would more be
   i386 or ia32, but we wanted to avoid x86_64, x8664, so x64

why?  x86_64 is the proper name for the architecture. (includes amd64,
em64t, and via isaiah)

your bikeshed though, i guess.  you can paint it whatever you want.  ;)

-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI

2008-10-10 Thread Jeremy Olexa
On Thu, Oct 9, 2008 at 1:15 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Thu, 9 Oct 2008 19:46:55 +0200
large snip
 What's the scope of the changes? I think it'd be easiest to discuss
 this if you posted an informal summary describing the differences in
 terms of which bits of PMS are affected.

Ciaran, others:

In a way I feel like we (the Prefix project) are mis-using the EAPI
value. If we have something that is designed to work with *any* EAPI,
is it really a special EAPI? haubi said something on the gentoo-alt
list that made me think about this more:
When an usecase of something is orthogonal to what that thing is
designed for, one should consider using a different thing for this
usecase. -source unknown

Is this PROPERTIES-like information? Is that easily supportable in the PM?



Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Marius Mauch
On Fri, 10 Oct 2008 14:48:19 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

 Whatever.  Some of you seem to have some quite agressive dislikement
 to it.  In the end it's just a name/tag.  I guess I could live with
 anything, including c3p0.

Well, while I dislike x64 I'm more concerned about using different
names (amd64 and x64) for the same architecture (same would apply if
you had used i386 or ia32 in some cases instead of x86) and was just
checking if there was any functional reason for that difference.

Marius



Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

2008-10-10 Thread Alec Warner
On Fri, Oct 10, 2008 at 5:41 AM, Duncan [EMAIL PROTECTED] wrote:
 Alec Warner [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted
 below, on  Fri, 10 Oct 2008 00:17:14 -0700:

 Consider this your first and last warning from Userrel.

 FWIW... at least on gmane, that appears as a response to aballier (gentoo
 dev), with references headers indicating the same thing, but given that
 (1) there was no attribution or quote so it's not possible to say who it
 was intended for directly, (2) I didn't see what was offensive in his
 post, and (3) that the warning was from userrel not devrel, I believe the
 warning was intended for someone other than the direct parent (my
 grandparent) poster.

 IOW, aballier may be very confused right about now... I know I was but at
 least it's not my posts in the balance like his appear to be, while
 someone else (my public attempt at a guess who wouldn't help) may be
 missing a warning they need to see (tho hopefully they got the message in
 any case).

Assume the warning was for the whole list; I just replied to the last
message in the thread; blame gmail ;)

-Alec


 --
 Duncan - List replies preferred.   No HTML msgs.
 Every nonfree program has a lord, a master --
 and if you use the program, he is your master.  Richard Stallman






Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI

2008-10-10 Thread Ciaran McCreesh
On Fri, 10 Oct 2008 10:40:53 -0500
Jeremy Olexa [EMAIL PROTECTED] wrote:
 In a way I feel like we (the Prefix project) are mis-using the EAPI
 value.

You're misusing it in the way you treat it as a set of strings rather
than a single value. But this being an EAPI thing seems right.

 If we have something that is designed to work with *any* EAPI,
 is it really a special EAPI? haubi said something on the gentoo-alt
 list that made me think about this more:
 When an usecase of something is orthogonal to what that thing is
 designed for, one should consider using a different thing for this
 usecase. -source unknown
 
 Is this PROPERTIES-like information? Is that easily supportable in
 the PM?

I don't see it as orthogonal.

Here's the thing: you can't use prefix ebuilds in a non-prefix-aware
package manager because things like ED will be unset. If prefix ebuilds
could work (as in, install unprefixed) in a purely vanilla package
manager with no prefix awareness, it could be done using PROPERTIES or
some similar variable. But prefix won't work at all unless its
extensions are present, and it also appears to require changes to
things that are defined differently in different EAPIs.

I suspect most of the problem is down to timescale. The prefix
development time is spread out over three EAPIs so far, so you need
three sets of (mostly similar) extensions. Had prefix taken less time
to be worked out, it'd fairly clearly be something that could just go
straight in to the next EAPI, with duplicated base system packages in
an overlay to avoid having to use new EAPIs for core things in the
main tree.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] net-nds/nis-utils needs a maintainer or it will get removed.

2008-10-10 Thread Alec Warner
If you don't use NIS or NIS+ you can stop reading now; if you do use
NIS or NIS+...I'm so so sorry.

The basic gist is this package is old and everyone should move to LDAP.

Consider it masked in two weeks for removal in 30 days unless a
maintainer is found.

-Alec



Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Robert Bridge
On Fri, 10 Oct 2008 17:56:37 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 On Fri, 10 Oct 2008 14:48:19 +0200
 Fabian Groffen [EMAIL PROTECTED] wrote:
 
  Whatever.  Some of you seem to have some quite agressive dislikement
  to it.  In the end it's just a name/tag.  I guess I could live with
  anything, including c3p0.
 
 Well, while I dislike x64 I'm more concerned about using different
 names (amd64 and x64) for the same architecture (same would apply if
 you had used i386 or ia32 in some cases instead of x86) and was just
 checking if there was any functional reason for that difference.

I would agree with this.

As a user coming to the project, x64 is NOT the same arch as amd64, it
has a different name! Select one name for the arch, and use it
everywhere. Consistent naming is more important than having the name
absolutely technically correct.

And seeing as Gentoo uses amd64 for all those arches in the main tree
with minimal problems, I personally would vote for using amd64 in -alt
to retain consistency with the rest of Gentoo.

Just my 2 cents.

Rob.


signature.asc
Description: PGP signature