Re: [gentoo-dev] Gentoo Council Reminder for April 23
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.
Re: [gentoo-dev] Gentoo Council Reminder for April 23
-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-
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Thu, 23 Apr 2009 08:53:24 -0700 Donnie Berkholz 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 Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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 pgpS1YXoNjfGz.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Wed, 22 Apr 2009 23:21:26 -0700 Donnie Berkholz 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 Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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 Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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 Last meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20090409-summary.txt EAPI=3: Provisional approval Here are all features I saw that received a "no" on-list. Answers of "no" and "query" are starred. Only CONTROLLABLE-COMPRESS got both "no" and "critical" votes. > * CONTROLLABLE-COMPRESS betelgeuse: critical cardoe: critical dberkholz: critical *dev-zero: no leio: yes > * ANY-USE betelgeuse: yes cardoe: yes dberkholz: yes dev-zero: yes *leio: no > * DOEXAMPLE > * DOINCLUDE betelgeuse: yes cardoe: yes *dberkholz: no dev-zero: whatever doexample; yes doinclude *leio: no > * BANNED-COMMANDS betelgeuse: yes cardoe: yes dberkholz: whatever dev-zero: yes *leio: no for dohard > * UNPACK-IF-COMPRESSED betelgeuse: yes cardoe: yes *dberkholz: no dev-zero: yes *leio: query (for same reason as dberkholz, plain files) Goals: Any unanswered queries? Figure out what to do with features receiving a "no." Vote on approval of the spec once questionable features are resolved. Get progress update in portage from zmedico. GLEP 54: Dealing with live SCM packages --- Goal: Are we prepared to vote? If so, vote on approval of GLEP 54. Handling EAPI versioning in a forwards-compatible way - Goal: Are we prepared to vote? If so, vote on the implementation for the problem solved in GLEP 55. [dberkholz: I'm not prepared] Handling static libraries more flexibly --- Goal: Vote on whether to move forward with USE=static-libs to control building of static libraries. pgpMreb5yDLmw.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, 19 Apr 2009 18:14:36 +0100 Ciaran McCreesh wrote: > On Sun, 19 Apr 2009 19:10:50 +0200 > Peter Alfredsen 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
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sunday 19 April 2009 18:14:36 Ciaran McCreesh wrote: > On Sun, 19 Apr 2009 19:10:50 +0200 > > Peter Alfredsen 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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, 19 Apr 2009 19:10:50 +0200 Peter Alfredsen 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 Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, 19 Apr 2009 12:21:55 -0400 Thomas Anderson 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 q...@g.o 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
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, Apr 19, 2009 at 05:58:53PM +0200, Peter Alfredsen wrote: > On Fri, 17 Apr 2009 15:17:15 -0700 > 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. > > 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 - pgpDpweUzQ8PB.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Fri, 17 Apr 2009 15:17:15 -0700 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. 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
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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 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 pgp5pW7cxZGGb.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Fri, 17 Apr 2009 15:27:30 -0700 Donnie Berkholz 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 Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Fri, 17 Apr 2009 15:17:15 -0700 Donnie Berkholz 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 Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for April 23
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
pgpqod3r8lymr.pgp
Description: PGP signature
[gentoo-dev] Gentoo Council Reminder for April 23
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 pgpVCZRYdNIiA.pgp Description: PGP signature
