\summary{2010}{12}{18} \agendaitem{slacking arches} \index{arches!slacking} This subject was proposed by scarabeus. As he wasn't around, the remaining council members shifted the focus to making sure there is enough relevant hardware available to developers to allow arch team work and questioned whether emulation could help on this, at least for non core parts on a trial basis. Roy (NeddySeagoon) asked what hardware is needed and whether there should be a funding application to the Foundation. Tony mentioned some hardware that could be used by the ppc64 team and Jorge noted that mainstream arches such as amd64 and x86 may also want to make a request. Finally, there was a mention that if council cared about this issue, one member could talk to arch teams to determine the hardware requirements and that we could take this opportunity to consider automated test boxes and rethink the boxes for the weekly builds. This issue was sent back to the ml for further debate. \agendaitem{la files removal status / progress} \index{.la files}\index{package!sys-devel/libtool} Jorge mentioned that portage-2.1.9* is now marked stable, but that he failed to take care of the documentation and or submitting a news item proposal based on the previous proposal made by Diego (flameeyes). He suggested the other council members that the council could either set a deadline to get a news item submitted for review in the dev ml after which the la files removal "embargo" would be dropped or just drop the "embargo" immediately and deal with the consequences. After some discussion there was a vote on "the council will drop the "embargo" on la file removal if no one submits to the dev ml a news item proposal about this issue before 2359 UTC next Wednesday". There were 3 yes votes and 2 no votes on this proposal. \agendaitem{Arfrever's suggestions for EAPI 4} \index{EAPI!4}\index{pkg_required_use}\index{GLEP!55} Reference: \agoref{gentoo-dev}{bec5db8373fca0271fcadf0cd55724e8} After some confusion caused by Jorge introducing the pkg_required_use topic during the discussion of this topic, the council members agreed to go over each of the points in Arfrever's email. Brian took the occasion to go over each of the points to finally get the discussion about them on record. Problem \#1: USE flags cannot contain "." characters. Brian argued that having "." on use flags is simply an aesthetic issue. Furthermore, use flags are used all over the tree and this could cause backward compatibility issues. Thus this would provide a minor gain, but would require much pain. Even though the council members agree that it would be possible to find ways to allow for the use of "." in use flags and that the change itself would be welcome, they agreed that this should only be addressed as part of a major restructuring of use flags, like the introduction of use groups. Petteri opened \bug{349021} for this. The council voted against the proposed solution for this problem with 5 votes no. Problem \#2: Files in profiles cannot use features from newer EAPIs. Brian argued that Arfrever's proposal for "-\$\{EAPI\}" extension files is a nightmare and that it relied on developers to get things right across multiple eapi versions. Jorge and Alex argued that this proposal is another variation of GLEP55 and that they have expressed their dislike for it before. The council voted against both proposed solutions for this problem with 5 votes no for the 1st solution and 4 votes no and 1 defer to ml for the 2nd solution. During this discussion there was a "detour" into the issue of migrating the EAPI of the base profiles, moving trouble files like package.mask to real profiles and how to ensure a clean upgrade path for old installs. Alex talked about an automated incremental process with switches of rsync sources over time and Brian mentioned the use of repository format markers. This discussion was pushed back to the ml. Problem \#3: repoman doesn't allow stable packages to have optional dependencies on unstable packages (usually until these packages are stabilized). Brian argued that both proposed solutions for this problem would cause a maintenance "hell" and would have a noticeable repoman run-time impact. Petteri noted he saw a problem needing a solution in here and Jorge argued that the solutions presented need a debate but that they are not tied to the presented problem. During the discussion Petteri asked about a 3rd option, unstable use flags, and Jorge argued that the separate profiles for stable / unstable tree could make sense if we got back to the idea of moving KEYWORDS out of ebuilds. In the end the council voted with 5 no votes for both solutions presented in point 3 to be part of the EAPI-4 specification. \agendaitem{pkg_required_use} \index{pkg_required_use} After a first attempt to discuss this during the previous point, the council addressed this issue after Ulrich (ulm) recalled he requested it to be added to the topic, which Jorge forgot to do. Following some debate about this issue, including requested feedback from both Zac (zmedico) and Brian, the council voted on having EAPI-4 introduce a pkg_required_use function to be called by the PM when it can't fulfill the required_use constraints with 4 no votes and 1 yes vote. The council members accepted having an EAPI-4.1 with pkg_required_use if / when there is a need for it in the tree. The council also expressed the desire to get a final vote on EAPI-4 before the end of the year. Petteri will propose a schedule to get EAPI-4 voted through email. \agendaitem{Open bugs} As the meeting lasted over 2 hours, the productivity was becoming low and Petteri had to leave, the review of the open bugs was pushed for next meeting. \agendaitem{Open floor - listen to the community} No issue was brought to the attention of the council at this meeting.