[00:00:00] - {Tageswechsel: Sonntag, 12. Januar 2025} [20:00:05] !proj council [20:00:05] sam_: (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm [20:00:08] Agenda: https://public-inbox.gentoo.org/gentoo-project/87a5bvzx8m.fsf@gentoo.org/T/#u [20:00:12] 1. Roll call [20:00:13] -*- sam_ here [20:00:16] -*- soap here [20:00:17] -*- mgorny here [20:00:18] -*- ulm here [20:01:17] -*- dilfridge here [20:01:39] arthurzam: robbat2: [20:03:18] will wait until 5 past [20:03:54] present [20:04:00] sorry, kid IRQs [20:05:03] ok [20:05:16] 2. (Further) pre-approval of EAPI 9 features [0] [20:05:19] 2a. * Do not export PMS variables (bug #721088) [1] [20:05:19] sam_: https://bugs.gentoo.org/721088 "[Future EAPI] Do not export PMS variables"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms [20:05:22] [0] https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_9_tentative_features [20:05:24] [1] https://public-inbox.gentoo.org/gentoo-project/87036fbf-6bd4-4577-bbd2-a11c9bc1dc1e@gentoo.org/ [20:05:31] ulm: flow: ^ [20:05:37] text of the spec is here: https://public-inbox.gentoo.org/gentoo-pms/20250110184912.16006-1-ulm@gentoo.org/T/#u [20:06:13] the idea is not to export most of the PM-defined variables [20:06:35] the the rationale that A has become very large in some cases [20:06:39] *with the [20:06:57] we went from A to AAAAA [20:07:02] the idea itself is sound, the rationale not really [20:07:03] and other vars like P may influence upstream build systems [20:07:12] that's what i wanted to say [20:07:24] yeah, I personally find the "other-vars cause issues" argument then "consistency" on top more persuasive [20:07:34] so we'd not export any of them except TMPDIR and HOME [20:07:36] I've had to deal with $P breaking makefiles [20:07:52] P has broken gcc several times in the last few years even [20:07:52] just to clarify, within ebuilds and eclasses directly nothing changes? [20:08:01] this will also cover USE_EXPAND vars like ARCH? [20:08:07] it's also usually not obvious at all when it is happening [20:08:07] nope [20:08:14] even worse for novices writing ebuilds [20:08:19] so I see this as a nice footgun removal too [20:08:22] what's defined in profiles will still be exported [20:08:33] (reducing "uh, works manually, fails in ebuild") [20:08:47] well, let's extend it to USE_EXPAND vars then explicitly, but that could be done separately [20:08:51] the only reason not to do this is tools *we've* written relying on these variables, like eselect calls [20:08:52] ARCH definitely breaks stuff [20:09:05] ulm had an idea of having pkgcheck look for the eselect case [20:09:17] (mainly for ROOT) [20:09:33] the eselect cases are trivial to catch [20:09:45] to double-check - if a tool does need a non-exported variable, all the ebuild author has to do is an extra "export VARNAME" in the ebuild? [20:10:22] "export VARNAME" or "local -Ix VARNAME" (assuming we switch to bash-5.2) [20:10:49] local has the advantage that it's ... local :) [20:11:03] I'm here. Power outage [20:11:27] ulm: wait, bash now allows you to actually make things exported locally now? [20:11:43] punt that to the next topic please ;) [20:11:47] naughty ulm! [20:11:56] mgorny: yes [20:12:34] mgorny: but don't use -I in EAPI 8 :) [20:12:44] i'm slightly worried about finding subtle breakage; e.g. where we were implicitly exporting CFLAGS before; and it built correctly, and then stops [20:12:59] CFLAGS isn't going to change [20:13:02] CFLAGS isn't affected [20:13:07] it's about PMS-defined variables we were always leaking to the environment [20:13:07] Do we have an idea for a env var that might be wanted to be manually exported in many places? [20:13:48] ROOT is the only one I can think of at the moment, also HOME and TMPDIR but those have exceptions in this [20:13:52] maybe the doc would be improved with a clear list there: "list of PMS-defined variables that will/will-not be exported" [20:14:17] robbat2: it's the ones in this table: https://projects.gentoo.org/pms/8/pms.html#x1-109001r1 [20:14:19] the list looks pretty harmless to me [20:14:35] except TMPDIR and HOME [20:14:38] Umm, SYSROOT maybe? [20:14:40] yeah, it's maybe clearer in the Portage patch Flow has written (https://github.com/gentoo/portage/pull/1407) [20:14:41] would you accept adding an adding a exported column? [20:15:07] robbat2: no :) [20:15:26] OK, went over Flow's patch, list looks ok for me :) [20:15:27] arthurzam: we might have to export EPREFIX in some rare cases, and maybe (E)SYSROOT for the benefit of some crossdev hacks we have [20:15:28] the table is already too wide as it is [20:15:34] but I'm not worried about it [20:15:43] sam_: ack :) [20:16:04] I see it as a good thing if these exports must be explicit [20:16:20] yes - I think it's going to reduce hard-to-debug breakage, and then makes environment smaller as a bonus [20:16:34] shall we proceed to vote? [20:16:53] sounds good [20:17:05] Motion: pre-approve "Do not export PMS variables" for EAPI 9 [20:17:06] no further questions from me [20:17:07] -*- sam_ yes [20:17:11] -*- arthurzam yes [20:17:13] -*- mgorny yes [20:17:13] -*- dilfridge yes [20:17:23] -*- robbat2 aye [20:17:31] .me yes [20:17:33] -*- soap yes [20:17:34] -*- ulm yes [20:17:50] motion passes (7 yes, 0 no, 0 abstentions) [20:17:58] good :) [20:18:16] 2b. Update Bash version to 5.2 (bug #946193) [2] [20:18:17] sam_: https://bugs.gentoo.org/946193 "[Future EAPI] Update Bash version to 5.2"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms [20:18:20] [2] https://public-inbox.gentoo.org/gentoo-project/ua5byebc7@gentoo.org/ [20:18:58] If we approve this, and bash 5.3 is considered stable in future, and EAPI=9 isn't yet out, would we be able to update from 5.2 baseline to 5.3? [20:19:05] sure [20:19:30] Is there potential cons against the upgrade then? [20:19:33] for me we'd need a strong reason not to approve this, because Chet has been very clear that he doesn't care for BASH_COMPAT at all [20:19:37] it's mainly that we don't fall to far behind [20:19:43] and we've had various issues with it not actually working [20:19:52] so there isn't really a choice [20:20:07] I've listed some incompatibilities in bug 946193 [20:20:07] https://bugs.gentoo.org/946193 "[Future EAPI] Update Bash version to 5.2"; Gentoo Hosted Projects, PMS/EAPI; CONF; ulm:pms [20:20:14] not sure if that's all [20:20:26] Kerin had tried reporting various issues w/ 5.2 with BASH_COMPAT as 5.1 and they all got WONTFIX'd [20:20:39] the main issue is that devs will start using 5.2 features anyway [20:20:47] yeah, that too [20:20:52] re bash 5.3: if upstream released a stable 5.3.0 today, that's 6? months until we can rely on it for stable ebuilds assuming EAPI=9 requires bash5.3? [20:21:24] yeah, we've been very conservative about it in the past [20:21:40] we've been very conservative with *that* part, and then not conservative enough with the rest [20:21:54] (PM support vs use in tree) [20:22:00] ulm: is there a reason to be conservative, and use 6 month and not the standard 30 days? [20:22:14] portage would depend on bash-5.3, I guess [20:22:35] so in principle it's usable as soon as 5.3 is stable [20:22:41] (maybe out of scope current motion, so maybe better postpone discussion on changing bash wait period to open floor) [20:22:55] yeah [20:23:02] 5.2 should be safe by now [20:23:08] agree [20:23:20] ok [20:23:27] Motion: Pre-approve "Update Bash version to 5.2" for EAPI 9 [20:23:30] -*- sam_ yes [20:23:30] -*- arthurzam yes [20:23:34] -*- robbat2 aye [20:23:43] -*- mgorny yes [20:23:44] -*- dilfridge aiaiaia... yes [20:23:47] -*- soap yes [20:23:48] -*- ulm yes [20:24:24] motion passes (7 yes, 0 no, 0 abstentions) [20:24:39] 3. Open bugs with Council participation [3] [20:24:42] [3] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation [20:24:50] https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=7352092&query_format=advanced [20:24:55] [20:24:57] bug 946351 [20:24:57] sam_: https://bugs.gentoo.org/946351 "Remove Open Collective organization"; Gentoo Council, unspecified; CONF; mgorny:council [20:25:12] ulm did some digging into this before because there's several different "Open Collective" bodies [20:25:23] I think there's an account we made a while ago that we need to deactivate [20:25:50] I don't think anyone disagrees with us doing that, do they? [20:26:14] sounds logical. Do we know who holds account's creds? [20:26:26] it's a role-based system [20:26:30] not a single account for the org [20:26:31] we have an account with open collective inc. which is the platform [20:27:28] whereas open collective foundation (OCF) was the fiscal host and is shutting down (or already has) [20:27:48] plus there's open source collective :/ [20:27:56] (OSC) [20:28:30] I'm all for removing us [20:28:47] the org had only submitted an application to OCF; and that application was rejected [20:28:57] from the admin panel right now, there is delete or archive [20:29:07] given that we had no data in here at all [20:29:29] i'm on the delete side, as long as the name isn't open for squatting in future, and only we can get it back [20:29:35] yes, make a clean slate [20:29:45] Yeah, delete I think is good [20:29:48] if squatting or never getting it back is a concern; then i'd vote archive [20:30:09] I don't think we need to vote on this [20:30:13] ok, let's move on [20:30:24] bug 936211 [20:30:25] sam_: https://bugs.gentoo.org/936211 "[Tracker] Gentoo Foundation dissolution"; Gentoo Foundation, Proposals; CONF; ulm:trustees [20:30:27] any news on this? [20:30:58] new donations (recurring & one-time) are going to SPI now [20:31:10] i'm waiting for their monthly financials due next week [20:31:19] to see if we have enough income to start switching over expenses [20:32:14] ok, thanks [20:32:32] 4. Open floor [20:32:34] anything? [20:33:19] do we want to discuss bash5.3 more? [20:33:26] let's cross that bridge when we reach it [20:33:42] then we'll have more facts on it [20:33:45] yeah, who knows when it will even come [20:33:50] or how bad the breakage within will be [20:34:51] i'm going to bang the gavel, i think [20:34:54] thank you all! [20:34:57] -*- sam_ bangs gavel [20:35:01] thanks! [20:35:04] thank you [20:35:12] thanks [20:35:13] thank you!