summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndreas K. Hüttel <dilfridge@gentoo.org>2021-05-28 20:01:41 +0200
committerAndreas K. Hüttel <dilfridge@gentoo.org>2021-05-28 20:01:41 +0200
commit91df96729fb8ab289bd93d426797bafb11c2e3ed (patch)
treec57eaaa92c0f23b1566d97acca85266b8f271df1
parentAdd summary of the emergency meeting (diff)
downloadcouncil-91df96729fb8ab289bd93d426797bafb11c2e3ed.tar.gz
council-91df96729fb8ab289bd93d426797bafb11c2e3ed.tar.bz2
council-91df96729fb8ab289bd93d426797bafb11c2e3ed.zip
Add 2020/11 logs
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
-rw-r--r--meeting-logs/20201108.txt246
-rw-r--r--meeting-logs/20201108.txt.asc19
2 files changed, 265 insertions, 0 deletions
diff --git a/meeting-logs/20201108.txt b/meeting-logs/20201108.txt
new file mode 100644
index 0000000..030ad70
--- /dev/null
+++ b/meeting-logs/20201108.txt
@@ -0,0 +1,246 @@
+8/Nov/2020
+
+[20:00:38] <gyakovlev> !proj council
+[20:00:39] <willikins> (council@gentoo.org) dilfridge, gyakovlev, mattst88, slyfox, ulm, whissi, williamh
+[20:00:43] <slyfox> \o/
+[20:01:05] <gyakovlev> let's start the meeting.
+[20:01:05] <gyakovlev> today's agenda: https://archives.gentoo.org/gentoo-project/message/8a574038e9dc22d7f15b687ffab0abc6
+[20:01:10] <gyakovlev> 1. Roll call
+[20:01:15] -*- gyakovlev here
+[20:01:18] -*- slyfox here
+[20:01:19] -*- ulm here
+[20:01:20] -*- dilfridge here
+[20:01:21] -*- Whissi here
+[20:01:21] -*- WilliamH here
+[20:01:22] -*- mattst88 here
+[20:01:58] <gyakovlev> good, everyone is here. moving to 2.
+[20:02:47] <gyakovlev> in agenda there are links [1][2] and [3] contain all the proposed features, do we want to vote each separately?
+[20:03:20] <ulm> [1] contains all features
+[20:03:26] <mattst88> Quick question: this just approving EAPI=8 features, but not necessarily locking us into these being the /only/ EAPI=8 features, right?
+[20:03:26] <slyfox> i personally don't mind all-or-nothing vote
+[20:03:33] <mattst88> IOW: we can approve more changes later?
+[20:03:36] <ulm> and traditionally the council has voted separately
+[20:04:10] <dilfridge> traditionally it has, yes... before we discuss this for long let's just start with it
+[20:04:17] <WilliamH> I don't mind all or nothing either.
+[20:04:25] <ulm> mattst88: that's pretty much intended as the complete list
+[20:05:16] <mattst88> I'm happy with all of the proposed changes, FWIW
+[20:05:18] <dilfridge> works for me too
+[20:05:19] <Whissi> For my understanding, is this the final list? Is it still possible that we are going to remove/add stuff to EAPI 8?
+[20:05:51] <gyakovlev> ok, vote item: 1) EAPI8 tentative features, all or nothing.
+[20:05:51] <gyakovlev> features listed here https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features
+[20:05:51] <gyakovlev> please vote yes if agree with all, if someone votes no we'll move to itemized voting.
+[20:05:52] <ulm> Whissi: everything is possible
+[20:06:02] -*- slyfox yes
+[20:06:03] -*- dilfridge yes
+[20:06:04] <ulm> but there's not plan from the PMS team to extend the list
+[20:06:09] -*- gyakovlev yes
+[20:06:29] -*- mattst88 yes
+[20:06:59] -*- WilliamH yes
+[20:07:07] -*- Whissi yes
+[20:07:09] -*- ulm yes
+[20:07:12] <slyfox> \o/
+[20:07:20] <dilfridge> verrry nice
+[20:07:21] <ulm> excellent, thank you :)
+[20:07:39] <gyakovlev> ok all proposed eapi8 features passed with all yes vote. moving on.
+[20:07:46] <gyakovlev> *tentative
+[20:08:26] <gyakovlev> moving to 2) Open bugs with council participation
+[20:08:28] <gyakovlev> 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=4950950&query_format=advanced
+[20:08:55] <gyakovlev> https://bugs.gentoo.org/751010 Missing log summaries.
+[20:09:05] <dilfridge> I know I know...
+[20:09:10] <dilfridge> soon
+[20:09:21] <gyakovlev> speaking for myself I finally recovered the machine, will upload old log with todays one soon.
+[20:10:02] <gyakovlev> https://bugs.gentoo.org/688876 Comrel webpage does not document expectations of privacy
+[20:10:15] <gyakovlev> I see the ping but no answer.
+[20:10:30] <slyfox> I can ping again :)
+[20:10:39] <gyakovlev> I'll take that one, don't worry.
+[20:10:43] <slyfox> Thank you!
+[20:11:02] <gyakovlev> bug #729062
+[20:11:03] <willikins> gyakovlev: https://bugs.gentoo.org/729062 "Services and Software which is critical for Gentoo should be developed/run in the Gentoo namespace"; Gentoo Council, unspecified; IN_P; jstein:council
+[20:11:25] <WilliamH> Nothing else has really been said about that...
+[20:11:28] <Whissi> I missed both items... for some reason I thought we meet next week and just realized yesterday :/
+[20:11:59] <gyakovlev> ok that's one on Whissi in that case. Please follow up once you can.
+[20:12:42] <gyakovlev> as for bug #736760
+[20:12:43] <willikins> gyakovlev: https://bugs.gentoo.org/736760 "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees
+[20:13:27] <WilliamH> I think SFC isn't interested in taking us on?
+[20:13:27] <gyakovlev> I know there has been no new developments and we are waiting for some answers/clarifications.
+[20:13:31] <slyfox> cloucil@ there is as an FYI, right?
+[20:13:47] <gyakovlev> yeah there's no actionable items, just status update.
+[20:13:51] <slyfox> *nod*
+[20:14:39] <gyakovlev> and the last one is inderect bug #574752
+[20:14:40] <willikins> gyakovlev: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs
+[20:14:46] <Whissi> That's my second item, I have something prepared for zac to review but not yet posted :/
+[20:14:49] <gyakovlev> I finally see some activity there.
+[20:16:10] <gyakovlev> ok at least something happening after month of radio silence. This concludes item 3. of today's agenda.
+[20:16:19] <gyakovlev> 4. Open floor
+[20:16:52] <gyakovlev> any1?
+[20:17:03] -*- mattst88 has nothing
+[20:17:09] -*- WilliamH has nothing
+[20:17:18] <slyfox> ${crickets}
+[20:17:52] <gyakovlev> ok let's just wait 3 minutes till :20
+[20:17:58] <Whissi> This feels like my daily meetings...
+[20:17:59] -*- Whissi has nothing
+[20:18:01] <slyfox> SGTM
+[20:18:55] <FreedomBear> Way to go all.
+[20:18:56] <mattst88> epsilonKNOT asks about the display-manager init renaming
+[20:19:07] <dilfridge> after this week, a no-news slow week is just great
+[20:19:16] <mattst88> it feels like we're in a bit of a deadlock
+[20:19:29] <mattst88> renaming seems fine to me, FWIW, since we're already going to have a news item
+[20:19:30] <dilfridge> is that really necessary? we should just keep it as xdm
+[20:19:39] *** Modus #gentoo-council +v epsilonKNOT by mattst88
+[20:19:48] <slyfox> what is a tl'dr?
+[20:19:56] <dilfridge> too long didnt read
+[20:20:07] <epsilonKNOT> xdm is both an actual display-manager and also a init script
+[20:20:20] <epsilonKNOT> the init script name is a misnomer as it start any display-manager
+[20:20:23] <gyakovlev> slyfox: moving /etc/init.d/xdm out of xorg specific package.
+[20:20:31] <dilfridge> yes but for ages the xdm script has been used to start any display manager
+[20:20:35] <gyakovlev> to gui-libs/diplay-manager-init
+[20:20:37] <WilliamH> epsilonKNOT: That makes sense to me.
+[20:20:39] <slyfox> aha
+[20:20:43] <mattst88> the thread on gentoo-dev is '[gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
+[20:20:56] <epsilonKNOT> ty mattst88 :)
+[20:21:05] <dilfridge> moving it out makes sense, not so sure about the renaming :D
+[20:21:10] <WilliamH> dilfridge: fix the misnomer by renaming.
+[20:21:25] <slyfox> https://archives.gentoo.org/gentoo-dev/message/524ad4d76379a4f70555bf51aa1edbe4
+[20:21:27] <ulm> that rename is pointless and I am strongly opposed
+[20:21:45] <ulm> and it's longer to type :)
+[20:21:59] <dilfridge> well, the impact is rather limited, and how often do you have to type it?
+[20:22:12] <mattst88> yeah, that's argument is a complete waste of time
+[20:22:20] <WilliamH> mattst88++
+[20:22:26] <ulm> the problem is the impact on users because it will require manual intervention
+[20:22:30] <gyakovlev> epsilonKNOT: have you seen my proposal on smooth migration path? not sure if it made it to mailing list.
+[20:22:39] <gyakovlev> I had some mail troubles
+[20:22:52] <WilliamH> ulm: that's what news items are for, they tell users what they need to do, they do it once, then they are done.
+[20:23:02] <epsilonKNOT> i saw that you mentioned to *try* and get a smooth path, i am not sure if there was any concrete solution
+[20:24:00] <mattst88> ulm: we'll already have a news item, and I think we determined that we can just fix it up automatically in pkg_postinst(), didn't we?
+[20:24:00] <ulm> yeah, but there's no point to the renaming, in the first place
+[20:24:00] <ulm> it's just unnecessary bikeshedding
+[20:24:00] <WilliamH> ulm: I disagree.
+[20:24:00] <gyakovlev> epsilonKNOT: I provided one, I'll try to re-send.
+[20:24:00] <ulm> wihtout an underlying technical reason
+[20:24:00] <ulm> and it will put burden on users
+[20:24:00] <gyakovlev> it will solve manual steps completely.
+[20:24:00] <epsilonKNOT> gyakovlev: thanks :O
+[20:24:00] <WilliamH> ulm: the reason is that the xdm init script can start things other than xdm.
+[20:24:02] <ulm> gyakovlev: which aren't needed without the renaming
+[20:24:09] <ulm> WilliamH: so what?
+[20:24:11] <mattst88> the point in renaming is that it removes the ambiguity
+[20:24:27] <WilliamH> mattst88++
+[20:24:27] <ulm> the display-manager script would also start things named differently
+[20:24:59] <epsilonKNOT> thats a bit of a red herring, its starting a display-manager
+[20:25:08] <slyfox> '/etc/init.d/xdm' is also a gentoo-specific script, right?
+[20:25:08] <ulm> mattst88: what ambiguity, there's only one init script named xdm
+[20:25:14] <mattst88> slyfox: yes
+[20:25:27] <mattst88> ulm: with x11-apps/xdm
+[20:25:47] <mattst88> xdm (the script) can start x11-apps/xdm, gnome-base/gdm, or ..., et al
+[20:25:47] <slyfox> *nod*, i don't mind a rename (but i also don't use it)
+[20:25:49] <ulm> that's a package
+[20:26:04] <mattst88> ulm: of course it's a package?
+[20:26:20] -*- sam_ scratches head
+[20:26:23] <ulm> where's the ambiguity?
+[20:26:31] <ulm> different name space
+[20:26:37] <mattst88> the confusion is that there's a script, 'xdm' installed to /etc/init.d that (1) isn't from x11-apps/xdm and (2) can start things other than x11-apps/xdm
+[20:26:46] <ulm> so what?
+[20:26:55] <sam_> All this is about is making 'xdm' (the script which starts up a DM) not necessarily mean xdm the WM, and also emphasise it's not necessarily even X.
+[20:27:02] <gyakovlev> ulm: it's been a source of confusion for many years for many new users.
+[20:27:20] <gyakovlev> because everyone else has per-dm initscripts
+[20:27:21] <mattst88> ulm: maybe just take our words for it that it's been confusing for a lot of people?
+[20:27:21] <dilfridge> yeah not everyone remembers that xdm even exists
+[20:27:29] <sam_> having two things called xdm when you might even be using wayland is kind of weird.
+[20:27:30] <epsilonKNOT> as sam has said, the scripts don't have anything to do with xxorg-server either
+[20:27:36] <sam_> I didn't know xdm even existed when I first used 'xdm'
+[20:27:58] <dilfridge> can the xdm init script start cde?
+[20:28:05] <slyfox> so unambiguous which is which :)
+[20:28:16] <sam_> hehe
+[20:28:30] <gyakovlev> dilfridge: I authoritatively answer yes as cde maintainer
+[20:28:34] <dilfridge> ++
+[20:29:03] <mattst88> should I just put this on the council agenda for next month, or can we attempt a vote to unblock this?
+[20:29:11] <dilfridge> let's just vote
+[20:29:16] <slyfox> ultimately i'd say it's up to /etc/init.d/xdm maintainer to decide how it should be handled.
+[20:29:29] <epsilonKNOT> slyfox: there is none (if you don't count x project)
+[20:29:34] <dilfridge> !proj x11
+[20:29:34] <willikins> dilfridge: (x11@gentoo.org) chithanh, leio, mattst88, remi, sarnex, slashbeast
+[20:29:44] <dilfridge> mattst88: you decide :P
+[20:29:48] <mattst88> lol
+[20:29:51] <WilliamH> slyfox++
+[20:30:03] <WilliamH> I was about to ask why that is coming to the council to begin with.
+[20:30:14] <gyakovlev> so yeah please stop this bikeshed and do the right thing. there are solutions to work around this.
+[20:30:29] <gyakovlev> for smooth migration for unsuspecting users.
+[20:30:50] <WilliamH> I'm not sure it needs to be a council issue at all.
+[20:30:50] <dilfridge> no need for a fundamental discussion about constitutional amendments
+[20:30:52] <mattst88> WilliamH: right, only because of the strength of the disagreement did I think I should ask council
+[20:31:10] <WilliamH> How many people disagreed mattst88 ?
+[20:31:22] -*- slyfox does not
+[20:31:30] -*- dilfridge doesnt mind that much
+[20:31:37] <ulm> if this was a new introduction of the init script, I'd agree that xdm wasn't the best name
+[20:31:38] <epsilonKNOT> there were atleast 3 people with dissatisfaction in the mailing list thread
+[20:31:40] <ulm> but we're talking about migration path here
+[20:31:43] <dilfridge> my main point is it shoudl be a smooth upgrade path
+[20:32:00] <epsilonKNOT> it can be done by adding to pkg_postinst
+[20:32:00] <dilfridge> if zyou can provide that everything is good
+[20:32:02] <mattst88> WilliamH: ulm (strongly), juippis (mildly? thought the rename is useless). I think ulm is the only strongly-disagree that I know of
+[20:32:05] <gyakovlev> I personally HATE gui-libs category, it just does not sound right. but ok for rename itself.
+[20:32:36] <slyfox> i think package moves are easier to move
+[20:32:39] <WilliamH> If we are talking about migration path ulm, imo if there is a migration path that means the rename can go ahead.
+[20:32:59] <WilliamH> Even with manual intervention by users as long as there is a newsitem.
+[20:33:10] <epsilonKNOT> manual intervention is going to be required in any case
+[20:33:24] <WilliamH> epsilonKNOT: ok, in that case, there isn't a blocker.
+[20:33:29] <ulm> and that's a killer argument against renaming IMHO
+[20:33:50] <WilliamH> ulm: did you look at what epsilonKNOT said? there is going to be manual intervention regardless.
+[20:33:55] <epsilonKNOT> display-manager-init has no reverse dependencies, none of gdm/sddm/lightdm *need* xdm script to be present
+[20:34:05] <epsilonKNOT> they can all be started from command line
+[20:34:21] <epsilonKNOT> so if you want a display-manager-init script, you have to add it manually
+[20:34:30] <mattst88> in other words: users will be asked to emerge gui-libs/display-manager-init
+[20:34:40] <mattst88> so they can easily rc-update add ... too
+[20:35:33] <dilfridge> ok, on the upside we're not talking about the ssh or net.eth0 init script here
+[20:35:54] <mattst88> right
+[20:35:57] <dilfridge> so if this breaks people should be able to fix it rather quickly
+[20:36:02] <dilfridge> still it's kinda ugly
+[20:36:28] <ulm> mattst88: can't you make it a (use conditional) dependency of xorg-server
+[20:36:30] <ulm> ?
+[20:36:36] <WilliamH> dilfridge: manual intervention is a fact of life.
+[20:36:46] <epsilonKNOT> ulm: its a optional runtime dependency, i think thats not allowed
+[20:36:55] <WilliamH> epsilonKNOT++
+[20:37:21] <mattst88> ulm: we could -- it'd be distateful, but we could. but I assume we'll still have people with wayland-only systems that would need to install it explicitly
+[20:37:21] <ulm> there are exceptions to that rule for a transition path
+[20:37:29] <gyakovlev> epsilonKNOT: it's allowed under special circumstances with appropriate approval.
+[20:37:30] <dilfridge> WilliamH: yes, I still remember when my server didnt boot... since no keyboard was connected, dmcrypt timed out, mount failed, and then the network didnt start
+[20:38:15] <WilliamH> gyakovlev: I haven't heard that. if it is I am going to apply for it for logrotate w/ openrc. :-)
+[20:38:41] <gyakovlev> WilliamH: you have to have a good enough reason ofc. talk to qa.
+[20:38:58] <dilfridge> let's just say, a good reason should be there
+[20:38:58] <mattst88> ulm: are you against any sort of manual intervention? I'm struggling to understand what you find so awful about the rename
+[20:39:11] <WilliamH> mattst88++
+[20:39:29] <epsilonKNOT> if we go for keeping it as optional runtime, then we can do a pkg_postinst to check if it enabled and then swap out xdm to display-manager. this would count as an automated path
+[20:39:51] <ulm> mattst88: the rename would add an additional step to any manual intervention, right?
+[20:39:55] <gyakovlev> epsilonKNOT: poor soul, your got yourself into that opinion war trying to do a good thing.
+[20:40:05] <sam_> Fair play, she's gone right in the deep end. :)
+[20:40:15] <mattst88> ulm: yes, it would require the user to run rc-update
+[20:40:25] <sam_> at the end of the day, this is righting a long-standing wrong
+[20:40:37] <WilliamH> rc-update add display-manager <runlevel> <-- done
+[20:40:49] <ulm> *shrug* I believe I've voiced my opinion
+[20:40:52] <ulm> loudly :)
+[20:41:14] <WilliamH> ulm: your opinion seems to be that you are against manual intervention, which is unrealistic.
+[20:41:16] <dilfridge> so what happens to the people who administer 100++ desktops?
+[20:41:26] <epsilonKNOT> indeed, having disagreements is not bad per se :)
+[20:41:37] <Soap__> dilfridge: ansible?
+[20:41:39] -*- Soap__ ducks
+[20:41:40] <mattst88> dilfridge: presumably they have systems for managing 100+ desktops, like ansible, salt, puppet, etc?
+[20:41:45] <dilfridge> otoh, yes, ansible or rex or ...
+[20:42:06] <Soap__> that said, a university of gentoo desktops, I'm not convinced thats a thing
+[20:42:12] <dilfridge> sorry just channeling patrick :D
+[20:42:24] <Soap__> 100++ servers maybe
+[20:42:28] <mattst88> okay, I guess we're done here
+[20:42:39] <slyfox> *nod*
+[20:42:52] <epsilonKNOT> thanks you :)
+[20:43:00] <WilliamH> Yeah I would guess servers aren't going to have a display manager.
+[20:43:08] <dilfridge> I suppose this manual intervention is much smaller than typical portage upgrade fiddling.
+[20:43:36] <epsilonKNOT> for sure, removing cycles with use flags is more work :)
+[20:44:29] <gyakovlev> ok, seems there are no more open floor items.
+[20:44:36] <gyakovlev> let's call it a day
+[20:44:38] <dilfridge> thanks everyone
+[20:44:41] -*- dilfridge sneaks off
+[20:44:43] <WilliamH> We can argue about things like that all day, but really shouldn't we let the maintainers handle it?
+[20:44:43] <epsilonKNOT> thanks again :)
+[20:44:46] -*- gyakovlev bangs the gong, meeting closed.
+[20:44:47] <WilliamH> Thanks all. :-)
+[20:44:58] <Whissi> \o/
+[20:45:00] <slyfox> thanks all!
diff --git a/meeting-logs/20201108.txt.asc b/meeting-logs/20201108.txt.asc
new file mode 100644
index 0000000..7bcaf19
--- /dev/null
+++ b/meeting-logs/20201108.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE6W4INB9YeKX6Qpi1TEn3nlTQogYFAmCxL+hfFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU5
+NkUwODM0MUY1ODc4QTVGQTQyOThCNTRDNDlGNzlFNTREMEEyMDYACgkQTEn3nlTQ
+ogYAyBAAvKerAFLjf2qYh5Gxl8dL+dUsnM52GMrpWeH26F9k0KYAZyNEt7vMfrN+
+rbGiHdB8xyYAOrcCci/aXzNK668t2pT7YFua1nRAyyd0fUoVchGUq2ZkegWLTsIo
+BuZWQ9NlFgrtExF0y4MnbUGe3fGBHlJAXNbiphNDptVA6hBJ1UQlrI2suvHhuvSl
+UVeIcK9E7v15C8p+SSJGvL8Ew816f8nvDfgk8/5YBIPj2F0AeGHInrrqAbMMCZY/
+4GHv0I683ITRuiMsLuTNDsOi2Ey4xCdDL3xRgEWw4KmZOt8QKAtSQsvvLqh560Bv
+ZYFnfFTMkWW0mQIq2vPUWhE0NJFq37GFiGw1MpLCUGShbxgWtAs7n8oZEn1Ap16b
+Lua6hTs4wt5tBWElBjroXxOAnfyHw6oQWGeKtmX1/6sOvZcSG/g1ZkCoKRAEQ7dI
+b/2pYJch+waJ2jMExGI911zuwMgoZ3e1sb9nKrcmlVblR/ZXP7Y5e8j5qJe3DAM3
+JFWwVXTEZ9MQcP2FwZ6PoriXKc+r6vzEwohbPYoHbodR3nZpyinWCA32DkyzRcy5
+wIe6Y9ch6Rg9M20314Z/gCN8d3nUfxwOFI2SfnIC+46NIGcf84O+2TV+TTj4uqTE
+BKMdJUwq1h6mRabk2B8oXND4/q47vCin++07F1uB4u/P9bsEpIs=
+=L/Jo
+-----END PGP SIGNATURE-----