[gentoo-project] Council meeting: Tuesday 11 September 2012, 19:00 UTC

[gentoo-project] Council meeting: Tuesday 11 September 2012, 19:00 UTC

[Ulrich Mueller]

The next council meeting will be on Tuesday 11 September 2012
at 19:00 UTC in the #gentoo-council channel on Freenode.

Proposed agenda:

1. Introduction and roll call (5 minutes)

2. EAPI 5 features (40 minutes)
   A detailed list of proposed features will be sent in a separate
   message to the gentoo-project mailing list.

     - Vote on the list of EAPI 5 features

3. Open bugs with council involvement (5 minutes)

     - Bug 383467 "Council webpage lacks results for 2010 and 2011
       elections"

4. Open floor (10 minutes)

Regards,
Ulrich

[gentoo-project] List of features proposed for EAPI 5 (was: Council meeting: Tuesday 11 September 2012, 19:00 UTC)

[Ulrich Mueller]

> 2. EAPI 5 features (40 minutes)
>    A detailed list of proposed features will be sent in a separate
>    message to the gentoo-project mailing list.

Here we go:


1. Features where a wording of the spec and a Portage implementation
   are ready

* Slot operator dependencies
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
  Bug: <https://bugs.gentoo.org/229521>

* Sub-slots
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=5d6749ac9e5ddc5b1daaad7737b65fa81c6ece47>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
  Bug: <https://bugs.gentoo.org/424429>

* Profile IUSE injection
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f76b983e95d022d6f377e3efd599dd8efbd30b3d>
  Bug: <https://bugs.gentoo.org/176467>

* econf --disable-silent-rules
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7d7387b34fdfb6ac8e736ca4e73f1e3f8fa1a705>
  Bug: <https://bugs.gentoo.org/379497>

* At-most-one-of operator for REQUIRED_USE
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ac843c3df2210566b559dc57c5fb657e20933a58>
  Bug: <https://bugs.gentoo.org/354219>

* EBUILD_PHASE_FUNC variable
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=cbd3ea6cad4d7ef8103ddbb71245c1ea47fa49ed>
  Bug: <https://bugs.gentoo.org/390765>

* Mandate GNU find
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8>,
               <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=6a95dae3fa6b8a6307f5d02c09dc550f1fbe97f2>,
               <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=421f2b9ae05999d621eb663f263ca93eaad0ae57>
  Portage patch: not needed
  Bug: <https://bugs.gentoo.org/384157>

* new* commands can read from standard input
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ffe2a5b5f70be05565b5a3038637805319088743>
  Bug: <https://bugs.gentoo.org/263565>

* Parsing of the EAPI assignment is mandatory
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5e28fe97e67ab4f3e2d8410a8704156b6bb08555>
  Bug: <https://bugs.gentoo.org/402167>

* src_test support for parallel tests
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9f14ed80e65a18da06e0834961ea032e3e830319>
  Bug: <https://bugs.gentoo.org/363005>

* Stable use forcing and masking
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ebf5d1a64a4a40a0efeba3b038122eef375ace94>
  Bug: <https://bugs.gentoo.org/431078>

* Option --host-root for {has,best}_version
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=25fb5fca6674215ea8aaa3d0ec3dd3df451eec07>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=bcf4ab871ededc3d535165757ba5597669e33dcb>
  Bug: <https://bugs.gentoo.org/401239>

* doheader helper function
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=fe5cf5e91299156dc74338c897d9a7bfb8883f5a>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e7e4c3720582a7ab938266e50e53d162f5248488>
  Bug: <https://bugs.gentoo.org/21310>

* usex helper function
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9ef20fa5b959f1878179342c5ed010534a954bf>
  Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b9e2daded3663c59bf11b04e952bdfb4eb5deabf>
  Bug: <https://bugs.gentoo.org/382963>


2. Things where additional discussion may be needed

* econf --disable-silent-rules (see above)
  - Apply retroactively to EAPI 4?
  - Apply retroactively to all EAPIs?
    (May be problematic because of additional configure call.)

* User patches
  PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538>
  Portage no-op dummy stub: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6b4b621f1abcf21d3bfa54b323126a3ef11eb52c>
  - Intrusive.
  - Current wording of the spec requires that every ebuild includes a
    call to the apply_user_patches function in src_prepare.
    An alternative would be to apply user patches after src_prepare as
    a default, if the ebuild doesn't call the respective function.
  - The spec doesn't provide any kind of epatch function, so we will
    end up having two copies of epatch, one for user patches, and the
    other (from eclass) for ebuilds.
  - Are we happy with the name apply_user_patches? (epatch_user?
    euserpatch?)

* License groups in ebuilds
  Bug: <https://bugs.gentoo.org/287192>
  - A simpler solution would be create separate license files like
    GPL-2+ for the few cases where this is needed. This would have the
    advantage that it could be applied to all EAPIs.

* EJOBS variable
  <http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml>
  -  Discussion was almost 4 years ago. Is there (still) consensus?

* Source eclasses only once
  Bug: <https://bugs.gentoo.org/422533>
  - <http://marc.info/?l=gentoo-dev&m=134493783816587&w=2>

* Extended default list of extensions in dohtml
  Bug: <https://bugs.gentoo.org/423245>
  - Objections against inclusion of non-standard extensions like .ico
    have been raised.

* REPOSITORY variable
  Bug: <https://bugs.gentoo.org/414813>
  - Controversial, see bug.

* Repository dependencies
  Bug: <https://bugs.gentoo.org/414815>
  - Controversial, see bug.


3. Not sure if the following are candidates for EAPI 5

* Cross-compile support
  <http://archives.gentoo.org/gentoo-project/msg_b1e2b88bbeb667a3fa834c99a1981fbe.xml>

* package.mask, use.force, use.mask, package.use, package.use.force
  and package.use.mask directories
  Bug: <https://bugs.gentoo.org/282296>
  - Need profiles EAPI bump

* make.defaults, use.force, use.mask, package.use, package.use.force
  and package.use.mask in ${repository_path}/profiles
  Bug: <https://bugs.gentoo.org/414817>
  - Need profiles EAPI bump

* HDEPEND: host dependencies for cross-compilation
  Bug: <https://bugs.gentoo.org/317337>

Re: [gentoo-project] List of features proposed for EAPI 5 (was: Council meeting: Tuesday 11 September 2012, 19:00 UTC)

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On 04-09-2012 12:37:17 +0200, Ulrich Mueller wrote:
> * Slot operator dependencies
>   PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906>
>   Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
>   Bug: <https://bugs.gentoo.org/229521>

The Portage patch doesn't match the PMS patch or the bug report.  The
Portage patch refers to slot_abi, not slot operator dependencies.

While Bug and PMS wording seem to be included in the Portage patch, the
Portage patch appears to do much more, overloading SLOT with some ABI
information, which Bug and PMS do NOT mention.  Instead, they assume
SLOT == ABI, probably as per Gentoo policy.

- the '/' delimiter in SLOT value is NOT mentioned in PMS
- PMS writes colon is immediately followed by '*' or '='
- Portage docs define a missing sub-slot to be implicitly '0', but when
  recording a slot dependency using '=', this default equals the value
  of SLOT

I'm not sure about sub-slot, and I can't find any case arguing in favour
of this feature.  Bug #424429 doesn't tell much more than how to use the
experimental version with an overlay.
Given that the sub-slot feature appears to be behind a special testing
EAPI now, I think it would be fair to at least mention explicitly that
sub-slot is not going to be part of EAPI5 (or this very point) as is.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] List of features proposed for EAPI 5

[Zac Medico]

On 09/05/2012 12:44 PM, Fabian Groffen wrote:
> On 04-09-2012 12:37:17 +0200, Ulrich Mueller wrote:
>> * Slot operator dependencies
>>   PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906>
>>   Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
>>   Bug: <https://bugs.gentoo.org/229521>
> 
> The Portage patch doesn't match the PMS patch or the bug report.  The
> Portage patch refers to slot_abi, not slot operator dependencies.

See the part about "Sub-slots", which are an extension of slot operator
dependencies (equivalent to slot_abi in the above patch):

* Sub-slots
  PMS wording:
<http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=5d6749ac9e5ddc5b1daaad7737b65fa81c6ece47>
  Portage patch:
<http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
  Bug: <https://bugs.gentoo.org/424429>

> While Bug and PMS wording seem to be included in the Portage patch, the
> Portage patch appears to do much more, overloading SLOT with some ABI
> information, which Bug and PMS do NOT mention.  Instead, they assume
> SLOT == ABI, probably as per Gentoo policy.
> 
> - the '/' delimiter in SLOT value is NOT mentioned in PMS
> - PMS writes colon is immediately followed by '*' or '='
> - Portage docs define a missing sub-slot to be implicitly '0', but when
>   recording a slot dependency using '=', this default equals the value
>   of SLOT

It's in the Sub-slots PMS patch.

> I'm not sure about sub-slot, and I can't find any case arguing in favour
> of this feature.

There was lots of discussion about it in the "About forcing rebuilds of
other packages issue" [1] thread on gentoo-dev. My blog post about EPAI
4-slot-abi is a good reference [2].

> Bug #424429 doesn't tell much more than how to use the
> experimental version with an overlay.
> Given that the sub-slot feature appears to be behind a special testing
> EAPI now, I think it would be fair to at least mention explicitly that
> sub-slot is not going to be part of EAPI5 (or this very point) as is.

It's also included in EAPI 5_pre1 [3], and given that sub-slots are
already in the PMS eapi-5 branch, I've regarded it as a foregone
conclusion that they'd be accepted in EAPI 5. I've even renamed all of
the "slot-abi" stuff to refer to "slot-operator" in the portage sources [4].

[1]
http://archives.gentoo.org/gentoo-dev/msg_f0e171be0f12abac2a10069e05e43c73.xml
[2]
http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
[3] http://blogs.gentoo.org/zmedico/2012/09/02/experimental-eapi-5_pre1/
[4]
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=3ee4929c733a6c03f74d6e3f2ced29c30d0ca7b5
-- 
Thanks,
Zac

Re: [gentoo-project] List of features proposed for EAPI 5

[Zac Medico]

On 09/05/2012 12:44 PM, Fabian Groffen wrote:
> - Portage docs define a missing sub-slot to be implicitly '0', but when
>   recording a slot dependency using '=', this default equals the value
>   of SLOT

I don't see the part of the Portage docs that you're referring to, but
I'll gladly correct or clarify it if you show me which part.
-- 
Thanks,
Zac

Re: [gentoo-project] List of features proposed for EAPI 5

[Ulrich Mueller]

>>>>> On Wed, 5 Sep 2012, Fabian Groffen wrote:

>> * Slot operator dependencies
>> PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906>
>> Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
>> Bug: <https://bugs.gentoo.org/229521>

> The Portage patch doesn't match the PMS patch or the bug report.  The
> Portage patch refers to slot_abi, not slot operator dependencies.

> While Bug and PMS wording seem to be included in the Portage patch,
> the Portage patch appears to do much more, overloading SLOT with
> some ABI information, which Bug and PMS do NOT mention.

To clarify, the Portage patch links of "slot operator dependencies"
and "sub-slots" point to the same Git commit. Both features are
implemented and available in EAPI 5_pre1.

Ulrich

[gentoo-project] [sub-slot] List of features proposed for EAPI 5

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Seems I was to quick with the previous mail.

On 04-09-2012 12:37:17 +0200, Ulrich Mueller wrote:
> * Sub-slots
>   PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=5d6749ac9e5ddc5b1daaad7737b65fa81c6ece47>
>   Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
>   Bug: <https://bugs.gentoo.org/424429>

Any pointers where we can find the argumentation what this is useful
for?  PMS is very terse when it writes:

	The sub-slot is used to represent cases in which an upgrade to a new
	version of a package with a different sub-slot may require dependent
	packages to be rebuilt.  When the sub-slot part is omitted from the
	SLOT definition, the package is considered to have an implicit
	sub-slot which is equal to the regular slot.

While this is an inconsistency, as pointed out in previous email, it is
unclear to me how this feature distinguishes from the general slot
operator dependencies, which appears to achieve the same.

My impression here is that this tries to work around a problem where
SLOT != ABI.  If (and that is what I assume here) the sub-slot is used
to have a major/minor-like matching criteria, it would've been more
native to use dev-libs/glib:2.* and a sole slot of "2.30".
In the end, it seems to be necessary to identify the various cases of
breakage using versioned ELF objects, based on libtool's versioning
rules, and use those as starting point to backup this feature.  (Taking
special care for downgrading.)


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] [sub-slot] List of features proposed for EAPI 5

[Zac Medico]

On 09/05/2012 12:59 PM, Fabian Groffen wrote:
> Seems I was to quick with the previous mail.
> 
> On 04-09-2012 12:37:17 +0200, Ulrich Mueller wrote:
>> * Sub-slots
>>   PMS wording: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=5d6749ac9e5ddc5b1daaad7737b65fa81c6ece47>
>>   Portage patch: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01>
>>   Bug: <https://bugs.gentoo.org/424429>
> 
> Any pointers where we can find the argumentation what this is useful
> for?

It was discussed in the "About forcing rebuilds of other packages issue"
[1] thread on the gentoo-dev mailing list.

> PMS is very terse when it writes:
> 
> 	The sub-slot is used to represent cases in which an upgrade to a new
> 	version of a package with a different sub-slot may require dependent
> 	packages to be rebuilt.  When the sub-slot part is omitted from the
> 	SLOT definition, the package is considered to have an implicit
> 	sub-slot which is equal to the regular slot.
> 
> While this is an inconsistency, as pointed out in previous email, it is
> unclear to me how this feature distinguishes from the general slot
> operator dependencies, which appears to achieve the same.

The difference is that it's possible for the sub-slot to change while
the regular slot remains constant. I'm sure that you're familiar with
FEATURES=preserve-libs, and sub-slots can be used to trigger automatic
rebuilds in every case that triggers preserve-libs. I gave some examples
of how automatic rebuilds behave in my blog post about EAPI 4-slot-abi
[2]. In the comments of that post, I also mentioned that automatic
rebuilds are preferable to using @preserved-rebuild, since then help to
avoid the possibility of symbol collisions [3].

Another issue with @preserved-rebuild is that it pulls in possibly
irrelevant packages that are eligible for removal by --depclean.
Automatic rebuilds triggered by sub-slot changes to do not suffer from
this problem.

> My impression here is that this tries to work around a problem where
> SLOT != ABI.  If (and that is what I assume here) the sub-slot is used
> to have a major/minor-like matching criteria, it would've been more
> native to use dev-libs/glib:2.* and a sole slot of "2.30".
> In the end, it seems to be necessary to identify the various cases of
> breakage using versioned ELF objects, based on libtool's versioning
> rules, and use those as starting point to backup this feature.  (Taking
> special care for downgrading.)

We already discussed various kinds of syntax in the "About forcing
rebuilds of other packages issue" thread, and everyone seemed to be
happy with the sub-slot syntax that Ciaran suggested [4]. It's been
tested in the axs overlay for things like perl and icu sub-slot ABI
changes, and seems to work well.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/77601
[2]
http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
[3]
http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour
[4]
http://archives.gentoo.org/gentoo-dev/msg_f0e171be0f12abac2a10069e05e43c73.xml
[5] https://bugs.gentoo.org/424429
-- 
Thanks,
Zac

Re: [gentoo-project] Council meeting: Tuesday 11 September 2012, 19:00 UTC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Tue, 4 Sep 2012 12:16:04 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> 4. Open floor (10 minutes)

I would have one small conflict/issue to resolve if it fits the 'open
floor' time, or otherwise for the next meeting.

It is the inclusion of dointo() and newinto() functions into
eutils.eclass. The implementation of these functions would look like:

dointo() {
    (
        insinto "$1"
        doins "${@:2}"
    )
}

so it's simply insinto+*ins in a subshell to avoid altering the ebuild-
defined insinto target. This is how various eclasses implement
functions like domenu(), doicon()...

I wanted to add those functions to eutils.eclass so that the functions
defined other and other eclasses wouldn't have to repeat the same
code. However, Diego Petteno was strongly opposed to this and I wasn't
able to convince him so I'd like to put it to debate by the Council.

The alternative proposed by Diego is to include those helpers in EAPI
5. However, that would mean that the beneficial eclass functions will
have to use them conditionally to EAPI, so it wouldn't benefit at all
functions in eclasses supporting EAPI<5 (and the affected eclasses
have no reason to drop support for older EAPIs). Effectively,
if introduced in a future EAPI, the helpers will be not used at all for
a long time.

I would like to especially note that these functions are meant for
internal use by eclasses and not by ebuilds. Ebuilds can and should use
insinto directly which is more optimal; eclasses need the subshelling
to allow ebuilds to do things like:

    insinto /foo
    doins bar
    doicon bar.xpm
    doins something_else

Ebuilds obviously can control their use of insinto.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]