\summary{2010}{12}{18} Agenda call: --- Agenda announcement: \agoref{gentoo-project}{30e33692f20e77c86977cc52e14ab9b5} \agendaitem{slacking arches} \index{arches!slacking}\index{arches!hardware}\index{foundation} This had been proposed by \dev{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. \dev{neddyseagoon} asked what hardware is needed and whether there should be a funding application to the Foundation. \dev{chainsaw} mentioned some hardware that could be used by the ppc64 team, and \dev{jmbsvicetto} noted that mainstream arches such as amd64 and x86 may also want to make a funding 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 mailing list for further debate. \agendaitem{la files removal status / progress} \index{.la files}\index{package!sys-devel/libtool} \index{package!sys-apps/portage} \dev{jmbsvicetto} mentioned that portage-2.1.9* is now marked stable, but that hadn't taken care of the documentation and or submitting a news item proposal based on the previous proposal made by \dev{flameeyes} so far. He suggested to the other council members that the council could either set a deadline to get a news item submitted for review on the gentoo-devel mailing list after which the .la files removal "embargo" would be dropped or that the "embargo" could just be dropped immediately, dealing with the consequences afterwards. \vote{The council will drop the "embargo" on .la file removal if no one submits to the gentoo-devel mailing list a news item proposal about this issue before 23:59 UTC next Wednesday.}{Passed with 3 yes votes and 2 no votes.} \agendaitem{Arfrever's suggestions for EAPI 4} \index{EAPI!4}\index{GLEP!55} Reference: \agoref{gentoo-dev}{bec5db8373fca0271fcadf0cd55724e8} After some confusion caused by \dev{jmbsvicetto} introducing the pkg_required_use topic (see next section below) here, the council members agreed to go over each of the points in \dev{arfrever}'s email. \dev{ferringb} took the occasion to go over each of the points to finally get the discussion about them on record. \index{use flags!dot character} Problem \#1: USE flags cannot contain "." characters. \dev{ferringb} 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, as tracked in \bug{311795}, 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.\footnote{Does anyone remember what ``use groups'' were supposed to be?} \dev{betelgeuse} opened \bug{349021} for this. The council voted against the proposed solution for this problem with 5 no votes. Problem \#2: Files in profiles cannot use features from newer EAPIs. \index{EAPI suffix}\index{EAPI!usage in profiles} \dev{ferringb} argued that \dev{arfrever}'s proposal for "-\$\{EAPI\}" extension files in the profiles is a nightmare and that it relied on developers to get things right across multiple EAPI versions. \dev{jmbsvicetto} and \dev{wired} argued that this proposal is another variation of \glep{55} and that they have expressed their dislike for it before. The council voted against "-\$\{EAPI\}" extension files in the profiles with 5 no votes. The proposal to create new profiles using EAPI="4", remove all older profiles from profiles.desc so that repoman doesn't check them anymore, and deprecate the older profiles was also defeated with 4 no votes and 1 vote to defer to the mailing list. 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. \dev{wired} talked about an automated incremental process with switches of rsync sources over time and \dev{ferringb} mentioned the use of repository format markers. This discussion was pushed back to the mailing list. Problem \#3: repoman does not allow stable packages to have optional dependencies on unstable packages (usually until these packages are stabilized). \index{use.unsatisfiable}\index{package.use.unsatisfiable} \index{profiles!per stable status} \dev{ferringb} argued that both proposed solutions for this problem would cause a maintenance "hell" and would have a noticeable repoman run-time impact. \dev{betelgeuse} noted he saw a problem needing a solution in here, and \dev{jmbsvicetto} argued that the solutions presented need a debate but that they are not tied to the presented problem of python versions. \index{use flags!unstable}\index{optional dependencies} During the discussion \dev{betelgeuse} asked about a third option, unstable use flags, and \dev{jmbsvicetto} argued that 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}\index{REQUIRED_USE} Reference: \agoref{gentoo-project}{3463900fd31abf9894c4c07e1a4a9978} After a first attempt to discuss this during the previous point, the council addressed this issue after \dev{ulm} recalled he requested it to be added to the agenda, which \dev{jmbsvicetto} forgot to do. Following some debate about this issue, including requested feedback from both \dev{zmedico} and \dev{ferringb}, 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. \dev{betelgeuse} 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 \dev{betelgeuse} had to leave, the review of the open bugs was pushed to the next meeting. \agendaitem{Open floor} No items were brought to the attention of the council at this meeting.