path: root/meeting-logs/20201108.txt

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!