Gentoo Council Reminder for April 23

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Gentoo Council Reminder for April 23

Donnie Berkholz-2
This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

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.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting. Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Donnie Berkholz-2
On 15:17 Fri 17 Apr     , Donnie Berkholz 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.

I've got a few items pending that I would like to propose. It should be
clear that there are way too many topics in this list for a single
meeting, so we'll have to prioritize a bit and discuss on list in
advance as much as possible.

Feel free to reply to this email regarding any of the below items.
Please change the subject so it's easier to parse through the
subthreads.


GLEP 54: Dealing with live SCM packages
---------------------------------------

Goal: Vote on approval of GLEP 54.


Handling EAPI versioning in a forwards-compatible way
-----------------------------------------------------

Goal: Vote on the implementation for the problem solved in GLEP 55.


EAPI=3: Progress update
-----------------------

Zac agreed to have the feature list implemented by this meeting, April
23. Assuming this will be the case, what else is left?


EAPI 4: Inclusion of prefix-related variables
---------------------------------------------

Fabian Groffen wrote:

I would like the council to discuss the addition of three variables to
EAPI3.

- EPREFIX
  The offset prefix of a Gentoo Prefix installation.  When Gentoo Prefix
  is not used, ${EPREFIX} should be "".
  This variable should be available everywhere.
- EROOT
  The offset prefix appended to ${ROOT}, e.g. ${ROOT%/}${EPREFIX}/
  This variable is available where ROOT is, following PMS: pkg_*
- ED
  The offset prefix appended to ${D}, e.g. ${D%/}${EPREFIX}/
  This variable is available where D is, following PMS: src_install

While the first variable (EPREFIX) can be set using an eclass, the
latter two need to be set by the package manager.  In particular ED,
because the value of D might not be known.  EROOT and ED are convenience
variables.  Making them available already now, even though initialised
as ROOT and D respectively, allows Prefix enabled ebuilds to be shared
between gentoo-x86 and Prefix trees without modifications.


Goal: Get opinions from council members.

Time allotted: 15 minutes


EAPI 4: Inclusion of "mtime preservation"
-----------------------------------------

Ulrich Mueller proposed this for inclusion.

Consider inclusion of "mtime preservation" (see bug 264130, and the
thread "Preserving mtimes for EAPI3" in this ML).

As I see it, there are three options:
  A. Always preserve timestamps when merging from D to ROOT, what was my
     original suggestion. Portage and Pkgcore already comply with this.
  B. Preserve timestamps, but optionally allow the package manager to update
     "old" ones. This is the suggestion from comment #12. Again, Portage and
     Pkgcore would be compliant already (since updating mtimes would be
     optional).
  C. As B, but with mandatory updating of "old" mtimes. For this, all three
     package managers would have to be changed.


Goal: Bring up concerns. Vote on this.

Time allotted: 10 minutes


Portage changing behavior in ebuild-visible ways
------------------------------------------------

David Leverton wrote:

I would like the Council to discuss the matter of Portage repeatedly
changing behaviour in ebuild-visible ways without an EAPI bump or even
an announcement that anything changed.  Notable examples include .lzma
support in unpack (bug 207193), the change in pkg_* phase ordering (bug
222721) and the preservation of timestamps during merge (bug 264130).
It is quite frustrating to spend considerable effort determining
Portage's behaviour and matching it in Paludis, only to find a few
months later that Portage changed and now users are getting broken
packages if not broken systems because ebuilds are starting to rely on
the new rules.

Goal: David proposes having a policy that this won't happen in the
future or admitting that we don't really care.

Time allotted: 15 minutes

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Ciaran McCreesh-4
In reply to this post by Donnie Berkholz-2
On Fri, 17 Apr 2009 15:17:15 -0700
Donnie Berkholz <[hidden email]> wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> 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.

I'd like you to provisionally approve EAPI 3 (subject to
reconsideration if it turns out Portage can't get it implemented
within a reasonable timeframe) with the features selected by the Council
members who responded to the "PMS EAPI 3 more or less ready" thread
[1], or with features selected by the PMS editors if a majority of the
Council hasn't replied at least 24h before the meeting.

[1]: http://tinyurl.com/ccn5h8

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Ciaran McCreesh-4
In reply to this post by Donnie Berkholz-2
On Fri, 17 Apr 2009 15:27:30 -0700
Donnie Berkholz <[hidden email]> wrote:
> EAPI 4: Inclusion of prefix-related variables
> EAPI 4: Inclusion of "mtime preservation"

Can we put these on hold until EAPI 3 is up and running? We need to get
EAPI 3 sorted out before spending any of our limited time on EAPI 4. We
all know that these things are pending, so why not just have them as
being early on the list of things to discuss once EAPI 3's out of the
way?

Otherwise I see us sitting around debating things for EAPI 5 with the
EAPI 3 list still not decided or approved...

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Brian Harring-2
Mind you my opinion...

On Fri, Apr 17, 2009 at 11:32:42PM +0100, Ciaran McCreesh wrote:
> On Fri, 17 Apr 2009 15:27:30 -0700
> Donnie Berkholz <[hidden email]> wrote:
> > EAPI 4: Inclusion of prefix-related variables

While I'm a fan of prefix, a stronger case for existing
implementation (including more exposition of it) should be made for
this rather then planning for discussion of it for eapi4.

> > EAPI 4: Inclusion of "mtime preservation"

This belongs in eapi3.  Arguement that it should be shelved because
"we don't want to slow down eapi3" ignores the simplicity of it, the
gains/costs being nailed down for it, and the fact every manager has
to do work for eapi3- this is quite simple, hiding behind "eapi3 is
locked down" is just dodging the needed specification due to lacking
strong technical arguements to kill it.


~harring

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Peter Alfredsen-3
In reply to this post by Donnie Berkholz-2
On Fri, 17 Apr 2009 15:17:15 -0700
Donnie Berkholz <[hidden email]> 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.

Up or down vote on USE="static-libs". It seems it wasn't actually voted
on last time it was brought up. We now have EAPI=2 use-deps and I just
committed dev-util/lafilefixer for the .la file problems. I see no more
obstacles for getting this adopted.

/loki_val

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Thomas Anderson-10
On Sun, Apr 19, 2009 at 05:58:53PM +0200, Peter Alfredsen wrote:

> On Fri, 17 Apr 2009 15:17:15 -0700
> Donnie Berkholz <[hidden email]> 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.
>
> Up or down vote on USE="static-libs". It seems it wasn't actually voted
> on last time it was brought up. We now have EAPI=2 use-deps and I just
> committed dev-util/lafilefixer for the .la file problems. I see no more
> obstacles for getting this adopted.
>
> /loki_val
Why are we trying to get rid of static libraries again? I have not seen
any compelling reason to remove libraries that may be useful to our
users. Perhaps I've missed some discussion(in which case, I'd love to
read it), but this seems like an unnecessary complexity.
--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Peter Alfredsen-3
On Sun, 19 Apr 2009 12:21:55 -0400
Thomas Anderson <[hidden email]> wrote:

> Why are we trying to get rid of static libraries again? I have not
> seen any compelling reason to remove libraries that may be useful to
> our users. Perhaps I've missed some discussion(in which case, I'd
> love to read it), but this seems like an unnecessary complexity.

I am a user. I don't want them.  The current situation where [hidden email]
requires .a files to be installed is just ghastly. A policy with no
good reason whatsoever, other than "the ancients did it this way, so
shall we."

TBH, i see more reasons for splitdebug and -ggdb being defaults than
I do for static libs. And even then, I'd want a way to turn it off.

A reasonable default would be --disable-static. Then libs that have
in-tree consumers of their static libs could then make a use-flag, users
who need them could use EXTRA_ECONF="--enable-static".

But that's not what I'm after. For now I just want a way to turn .a
generation off. At the moment 500MB of prime space on /usr/lib64 is
being used by .a files. That's about 450MB more than is needed (last I
checked).

/loki_val

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Ciaran McCreesh-4
On Sun, 19 Apr 2009 19:10:50 +0200
Peter Alfredsen <[hidden email]> wrote:
> A reasonable default would be --disable-static. Then libs that have
> in-tree consumers of their static libs could then make a use-flag,
> users who need them could use EXTRA_ECONF="--enable-static".

If you're going to do that, why not do it as an EAPI thing? This has
the added bonus that there's a clean migration path...

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Duncan-42
In reply to this post by Thomas Anderson-10
Thomas Anderson <[hidden email]> posted
[hidden email], excerpted below, on  Sun,
19 Apr 2009 12:21:55 -0400:

> Why are we trying to get rid of static libraries again? I have not seen
> any compelling reason to remove libraries that may be useful to our
> users. Perhaps I've missed some discussion(in which case, I'd love to
> read it), but this seems like an unnecessary complexity.

It isn't that "we" are trying to get rid of static libs, but that the
*.la
files they need for linking are a pain in the backside for everyone,
while only a few people need them.

See flameeyes' recent blog on the topic, here (watch the wrap):
http://blog.flameeyes.eu/2009/04/18/some-details-about-our-old-friends-the-la-files

In addition to that, for archs like amd64 that need to compile things
twice if both static and dynamic libraries are provided (due to -fPIC
requirements in the dynamic case only, see the recent headaches with
mysql and the library amarok needed from it), killing the static libs
means shorter merge times and can mean significantly less build script
complication. =:^)

http://bugs.gentoo.org/show_bug.cgi?id=238487

--
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


Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Markos Chandras-2
In reply to this post by Ciaran McCreesh-4
On Sunday 19 April 2009 18:14:36 Ciaran McCreesh wrote:
> On Sun, 19 Apr 2009 19:10:50 +0200
>
> Peter Alfredsen <[hidden email]> wrote:
> > A reasonable default would be --disable-static. Then libs that have
> > in-tree consumers of their static libs could then make a use-flag,
> > users who need them could use EXTRA_ECONF="--enable-static".
>
> If you're going to do that, why not do it as an EAPI thing? This has
> the added bonus that there's a clean migration path...
+1 . I do like this approach instead of using a new use flag :)
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Qt/KDE/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Peter Alfredsen-3
In reply to this post by Ciaran McCreesh-4
On Sun, 19 Apr 2009 18:14:36 +0100
Ciaran McCreesh <[hidden email]> wrote:

> On Sun, 19 Apr 2009 19:10:50 +0200
> Peter Alfredsen <[hidden email]> wrote:
> > A reasonable default would be --disable-static. Then libs that have
> > in-tree consumers of their static libs could then make a use-flag,
> > users who need them could use EXTRA_ECONF="--enable-static".
>
> If you're going to do that, why not do it as an EAPI thing? This has
> the added bonus that there's a clean migration path...

If we ever decide to do that, eapi would be a sane way to do it. Right
now, we're only discussing making static libs configurable. The other
bits we can deal with when we come to them.

/loki_val

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Donnie Berkholz-2
In reply to this post by Donnie Berkholz-2
On 15:27 Fri 17 Apr     , Donnie Berkholz wrote:

> On 15:17 Fri 17 Apr     , Donnie Berkholz 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.
>
> I've got a few items pending that I would like to propose. It should be
> clear that there are way too many topics in this list for a single
> meeting, so we'll have to prioritize a bit and discuss on list in
> advance as much as possible.
>
> Feel free to reply to this email regarding any of the below items.
> Please change the subject so it's easier to parse through the
> subthreads.
Here is an updated agenda. I've removed a few items that I consider
lower priority and unlikely for us to have time for during this week's
meeting. Also, I added the issue about USE=static-libs because I think
it's important.

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

20090423-agenda.txt (1K) Download Attachment
attachment1 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Tiziano Müller-3
Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz:

> On 15:27 Fri 17 Apr     , Donnie Berkholz wrote:
> > On 15:17 Fri 17 Apr     , Donnie Berkholz 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.
> >
> > I've got a few items pending that I would like to propose. It should be
> > clear that there are way too many topics in this list for a single
> > meeting, so we'll have to prioritize a bit and discuss on list in
> > advance as much as possible.
> >
> > Feel free to reply to this email regarding any of the below items.
> > Please change the subject so it's easier to parse through the
> > subthreads.
>
> Here is an updated agenda. I've removed a few items that I consider
> lower priority and unlikely for us to have time for during this week's
> meeting. Also, I added the issue about USE=static-libs because I think
> it's important.
>
I'd really like to see the topic about "portage changing behaviour"
being discussed since I see it as crucial for future eapi/portage/pm
development and I therefore consider it urgent as well. Furthermore it
has been deferred already once.


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Ciaran McCreesh-4
In reply to this post by Donnie Berkholz-2
On Wed, 22 Apr 2009 23:21:26 -0700
Donnie Berkholz <[hidden email]> wrote:
> Here is an updated agenda. I've removed a few items that I consider
> lower priority and unlikely for us to have time for during this
> week's meeting.

Please bring forward dleverton's "Portage repeatedly changing
behaviour" thing. Without a resolution to this all the EAPI work we're
doing is a waste of time.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Donnie Berkholz-2
In reply to this post by Tiziano Müller-3
On 12:15 Thu 23 Apr     , Tiziano Müller wrote:

> Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz:
> > Here is an updated agenda. I've removed a few items that I consider
> > lower priority and unlikely for us to have time for during this
> > week's meeting. Also, I added the issue about USE=static-libs
> > because I think it's important.
>
> I'd really like to see the topic about "portage changing behaviour"
> being discussed since I see it as crucial for future eapi/portage/pm
> development and I therefore consider it urgent as well. Furthermore it
> has been deferred already once.
Which other important topic should we drop for it? I'm thinking we
probably won't even get to the last one, that's almost a wish list. I
think there's a pretty reasonable chance we also wouldn't get to
whatever other items came after this one.

Zac, have you commented on this topic previously? How do you think it
should work? See "Portage changing behavior in ebuild-visible ways" at
http://dev.gentoo.org/~dberkholz/20090514-agenda.txt for a description.
CC'ing you to make sure you see this...

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Ciaran McCreesh-4
On Thu, 23 Apr 2009 08:53:24 -0700
Donnie Berkholz <[hidden email]> wrote:
> Which other important topic should we drop for it? I'm thinking we
> probably won't even get to the last one, that's almost a wish list. I
> think there's a pretty reasonable chance we also wouldn't get to
> whatever other items came after this one.

Might as well hold off GLEPs 54 and 55. They're both effectively EAPI 4
territory anyway.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Mart Raudsepp-2
In reply to this post by Donnie Berkholz-2
On Wed, 2009-04-22 at 23:21 -0700, Donnie Berkholz wrote:
>
>
> Goals: Any unanswered queries? Figure out what to do with features
> receiving a "no."

I think the whole council should understand why something received a
"no" from someone, as they might be important technical (or subjective)
arguments against having that in EAPI-3, as to be able to make an
informed decision that is best for the whole of Gentoo.
I believe we have up to now just given individual stances on the
features - voting based on that doesn't really work right. It is quite
likely that almost all features will get a majority "yes" vote when
taken individually because not all council members have seen the
problems a few of the council members have.
So my point is that the whole of the council should consider the
objections of an individual council member, so that potentially bad
things don't end up accepted based on some kind of an uninformed
majority vote or concensus.


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

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Zac Medico-2
In reply to this post by Donnie Berkholz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:

> On 12:15 Thu 23 Apr     , Tiziano Müller wrote:
>> Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz:
>>> Here is an updated agenda. I've removed a few items that I consider
>>> lower priority and unlikely for us to have time for during this
>>> week's meeting. Also, I added the issue about USE=static-libs
>>> because I think it's important.
>> I'd really like to see the topic about "portage changing behaviour"
>> being discussed since I see it as crucial for future eapi/portage/pm
>> development and I therefore consider it urgent as well. Furthermore it
>> has been deferred already once.
>
> Which other important topic should we drop for it? I'm thinking we
> probably won't even get to the last one, that's almost a wish list. I
> think there's a pretty reasonable chance we also wouldn't get to
> whatever other items came after this one.
>
> Zac, have you commented on this topic previously? How do you think it
> should work? See "Portage changing behavior in ebuild-visible ways" at
> http://dev.gentoo.org/~dberkholz/20090514-agenda.txt for a description.
> CC'ing you to make sure you see this...

In the cases mentioned, I think that more communication would have
helped, and I wasn't as careful as I should have been. In
the future, I want to strive to use more communication to avoid
problems like these.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAknwp8EACgkQ/ejvha5XGaME8QCg3O1fMWlN87aH8xyfqy6mZK8+
KxkAoMP7SJKdhZSJ7H8nq47HnmKUXjOF
=4e2L
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Gentoo Council Reminder for April 23

Rich Freeman
In reply to this post by Mart Raudsepp-2
Mart Raudsepp wrote:
> So my point is that the whole of the council should consider the
> objections of an individual council member, so that potentially bad
> things don't end up accepted based on some kind of an uninformed
> majority vote or concensus.
>

Probably the best way to accomplish something like this is for a council
member to publish their no vote BEFORE the actual council meeting so
that there is actually time to discuss it.  The actual council meeting
isn't really a great forum to resolve issues - there just isn't that
much time.

I appreciate the fact that council members are avoiding huge amounts of
back-and-forth on the mailing list, but waiting until the last minute
for a surprise "no" vote isn't helpful either.

I think one of the great things Donnie has done for the council is to
push the discussion into the mailing list well in advance of the
meeting, and to defer issues that haven't gotten properly hashed out
on-list.  If something really needs interactive discussion that is one
thing, but going into a topic cold just results in a lot of "shooting
from the hip" and not much constructive progress.

12