19:02:37 <zbyszek> #startmeeting FESCO (2021-11-08)
19:02:37 <zodbot> Meeting started Mon Nov  8 19:02:37 2021 UTC.
19:02:37 <zodbot> This meeting is logged and archived in a public location.
19:02:37 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:02:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:02:37 <zodbot> The meeting name has been set to 'fesco_(2021-11-08)'
19:02:37 <zbyszek> #meetingname fesco
19:02:37 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, defolos, mboddu, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
19:02:37 <zbyszek> #topic init process
19:02:37 <zodbot> The meeting name has been set to 'fesco'
19:02:37 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe defolos mboddu mhroncok nirik sgallagh zbyszek
19:02:42 <zbyszek> Sorry for the delay.
19:02:50 <nirik> morning.
19:02:53 <mboddu> Morning
19:02:56 <zbyszek> afternoon ;)
19:02:57 <Eighth_Doctor> .hello ngompa
19:02:58 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
19:03:00 <zbyszek> .hello2
19:03:01 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
19:03:01 <dcantrell> .hello2
19:03:04 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
19:03:10 <nirik> I'm here, but also in the infrastructure/releng standup, which is now exactly the same time as this meeting. ;(
19:03:11 <mboddu> .hello mohanboddu
19:03:12 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
19:03:31 <mboddu> Same as nirik, I am also in infra/releng standup
19:03:53 <spichugi> .hello spichugi
19:03:54 <zodbot> spichugi: spichugi 'Simon Pichugin' <spichugi@redhat.com>
19:04:02 <zbyszek> mhroncok said that he's too tired to attend
19:04:49 * Eighth_Doctor is half-dead from timezone change
19:04:51 <zbyszek> We're 5, let's start
19:05:09 <dcantrell> I'd say I'm half-alive
19:05:18 <zbyszek> #topic #2682 F36 Change: Openldap-2.5
19:05:18 <zbyszek> .fesco 2682
19:05:19 <zodbot> zbyszek: Issue #2682: F36 Change: Openldap-2.5 - fesco - Pagure.io - https://pagure.io/fesco/issue/2682
19:05:20 <StephenGallagher> .hello sgallagh
19:05:22 <zodbot> StephenGallagher: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
19:05:46 <zbyszek> Hi spichugi
19:05:50 <spichugi> hi
19:05:53 <zbyszek> Thank you for coming.
19:06:34 <spichugi> sure
19:06:58 <spichugi> it's a first time for me. :) How is it done?
19:07:17 <zbyszek> I think I answered your other questions in the ticket… The part that remains is what Eighth_Doctor said
19:07:45 <zbyszek> I.e. that we expect the upgrade to happen automatically, no aborting of the transaction or anything like that.
19:08:19 <Eighth_Doctor> you can, of course, do something like make the service not start unless migrations are run
19:08:27 <Eighth_Doctor> but ideally these would also be taken care of automatically
19:08:36 <zbyszek> Yeah, I think that sounds like the most reasonable approach.
19:08:43 <Eighth_Doctor> but stopping the upgrade mid-way through is not acceptable
19:09:00 <zbyszek> Maybe we should check how it's done with postgresql… They have a similar situation on major version upgrades.
19:09:14 <dcantrell> I was just going to suggest postgresql as an example
19:09:20 <spichugi> yes, it's okay. We can't do it automatically because it may be very sensetive (and we don't want to break any deployments)
19:09:26 <dcantrell> it's been a long time since I've looked at that package though, but it is something they always have to deal with
19:09:48 <nirik> they just update and refuse to start after update until the db is migrated. (which they provide a tool for) (at least last I looked/used it)
19:10:09 <dcantrell> spichugi: can the migration fail from 2.4 to 2.6?
19:10:11 <StephenGallagher> I think such an approach is probably the right thing to do here as well
19:11:06 <dustymabe> .hi
19:11:07 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
19:11:10 <spichugi> dcantrell, 2.4 to 2.6 is the same like 2.4 to 2.6 mostly (there are small differences but they are more about 2.5 to 2.6 migration)
19:12:25 <spichugi> okay, sounds great! I'll check the postgresql package, and I won't do anything like 'breaking dnf upgrade process'
19:12:39 <dcantrell> does the data live in the same location?  you could convert to 2.6 but leave the existing data in place, and if there's a failure on the user end they at least have an option to revert to the previous package and their old data is still there
19:13:41 <spichugi> IIRC, it may modify the server on the start up (when the first start happens after 2.4->2.6 ungrade)
19:14:24 <spichugi> so Upstream suggests the certain upgrade procedure which should be done manually (as it's quite complex)
19:14:29 <zbyszek> Hmm, so what are steps that the admin needs to do?
19:15:28 <zbyszek> Is there some script to do this?
19:17:32 <spichugi> it may be developed personally by the admin but it should take into account all of the directories and cases that the user topology has (you can specify the data directory to another place, and it may have other settings and overlays/plugins involved)
19:18:01 <spichugi> In the upgrade section of the change proposal, I've linked the offical guide for upgrade
19:18:30 <zbyszek> Hmm, so this seems like a potentially nasty change.
19:19:05 <spichugi> first this is done - https://www.openldap.org/doc/admin25/maintenance.html ; then - https://www.openldap.org/doc/admin25/appendix-upgrading.html ; then this should be checked - https://www.openldap.org/doc/admin26/appendix-upgrading.html
19:19:06 <zbyszek> Dunno, do we have any proposals?
19:19:22 <zbyszek> spichugi: yeah, I read those, but they are very vague…
19:19:40 <spichugi> so yes, it's better to give the user the way to deal with it manually
19:19:49 <dcantrell> this doesn't strike me as something that can be automated on upgrading
19:20:17 <zbyszek> I think we need to make sure to warn very verbose in the upgrade notes about this.
19:20:19 <StephenGallagher> My suggestion would be to do nothing on the package upgrade, but add a new unit file that will run before the server starts up the next time and provides instructions on how to upgrade manually
19:20:45 <dcantrell> yes, and I would also suggest that openldap 2.6 use a new default data subdirectory
19:21:15 <StephenGallagher> Or otherwise create a backup of the initial state, yeah
19:21:20 <dcantrell> sure
19:21:41 <zbyszek> Proposal: change is approved, with the proviso that the dnf upgrade must go through, and the server will refuse to start until the data is successfully migrated. Change owner will figure out the best way to communicate this to the admin.
19:21:53 <zbyszek> s/server/service/
19:21:55 <StephenGallagher> +1
19:22:15 <dcantrell> +1
19:22:23 <nirik> +1
19:22:26 <mboddu> +1
19:22:46 <Eighth_Doctor> +1
19:23:28 <zbyszek> #agree Change is approved, with the proviso that the dnf upgrade must go through, and the service will refuse to start until the data is successfully migrated. Change owner will figure out the best way to communicate this to the admin (+6, 0, 0)
19:24:02 <zbyszek> spichugi: I think that in this case the good thing is that this seems almost ready, so there'll be a long time to figure out the best way to handle the upgrades.
19:24:19 <zbyszek> If the code were only to become available shortly before F36 release, this would be much harder.
19:24:34 <zbyszek> OK, let's go to the next one.
19:24:39 <zbyszek> #topic #2684 F36 Change: Drop NIS(+) support from PAM
19:24:39 <zbyszek> .fesco 2684
19:24:40 <zodbot> zbyszek: Issue #2684: F36 Change: Drop NIS(+) support from PAM - fesco - Pagure.io - https://pagure.io/fesco/issue/2684
19:24:44 <spichugi> Thank you, folks! Fantastic community, great conversation!
19:24:51 <zbyszek> spichugi: thank you!
19:24:55 <zbyszek> spichugi++
19:24:55 <zodbot> zbyszek: Karma for spichugi changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:24:55 <nirik> thanks for coming and talking things out spichugi!
19:25:19 <dustymabe> spichugi++
19:25:19 <zodbot> dustymabe: Karma for spichugi changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:25:36 <mboddu> Thanks spichugi for joining us and clarifying some questions.
19:25:41 <mboddu> spichugi++
19:25:41 <zodbot> mboddu: Karma for spichugi changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:25:57 <nirik> StephenGallagher: did you have some questions about this one? you wanted it discussed?
19:26:23 <spichugi> I'll still need to work with a few packages who fail to build with the new version. But it's may be 5-10 packages and the issues are minor. I'll open BZs for them
19:27:01 <StephenGallagher> Mostly I wanted to make sure it wasn't auto-approved without discussion.
19:27:19 <besser82[m]> StephenGallagher, I'm here to answer your questions / discuss further needed information
19:27:35 <spichugi> StephenGallagher++ dcantrell++ nirik++ mboddu++ Eighth_Doctor++ zbyszek++ dustymabe++
19:27:35 <zodbot> spichugi: Karma for dcantrell changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:38 <zodbot> spichugi: Karma for kevin changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:41 <zodbot> spichugi: Karma for mohanboddu changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:44 <zodbot> spichugi: Karma for ngompa changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:47 <zodbot> spichugi: Karma for zbyszek changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:50 <zodbot> spichugi: Karma for dustymabe changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:27:52 <zbyszek> So I share the concern that this is going to be very painful for people who have NIS e.g. in some lab setup at a university…
19:27:52 <StephenGallagher> besser82[m]: FTR, I'm personally fully in favor of burning NIS to the ground, salting the earth and then nuking the site, just to be sure.
19:28:12 <Eighth_Doctor> whoa, zodbot works now?
19:28:15 <Eighth_Doctor> for the cookies
19:28:18 <StephenGallagher> But with my FESCo hat on, I have to ask if it's worth it to remove it from the distro entirely.
19:28:23 <nirik> Eighth_Doctor: yes! :)
19:28:24 <zbyszek> I think NIS is terrible, don't get me wrong. But OTOH, people who are using it, probably know this.
19:28:41 <Eighth_Doctor> zbyszek: I'm not sure they do, actually
19:28:47 <dcantrell> I don't miss NIS or even NIS+
19:28:50 <dcantrell> we don't need it anymore
19:29:20 <Eighth_Doctor> do we have a NIS/NIS+ -> FreeIPA migration thingy?
19:29:20 <dcantrell> it would probably be nice to advertise that we're removing it as there may be some users of it out there who will be surprised
19:29:29 <StephenGallagher> We actually do!
19:29:42 <Eighth_Doctor> then we should definitely advertise that!
19:29:42 <nirik> I'd like to see a release note/doc on alternatives they could move to as part of this.
19:29:42 <StephenGallagher> (sort of)
19:29:50 <mboddu> Yeah, I agree with the change generally, but what happens with the existing one's
19:30:09 <StephenGallagher> FreeIPA has a mode where it can act as a NIS server, mostly to handle ancient clients like SunOS
19:30:15 <zbyszek> Could we maybe drag this out over at least one more release: e.g. start warning when it's used, so that people become more aware and have the extra 6 months to prepare?
19:30:41 <mboddu> zbyszek: If we approve now, they sorta have 6 months
19:30:47 <StephenGallagher> I think FreeIPA upstream also has some conversion scripts, but I don't know if they've been kept up to date
19:31:08 <besser82[m]> If there is a tool to migrate NIS -> FreeIPA, it shouldn't be too hard to migrate in time.
19:31:15 <Eighth_Doctor> it's been removed from RHEL with RHEL 9, right?
19:31:36 <Eighth_Doctor> so this is just bringing that change back into Fedora, and providing guidance on how to migrate
19:31:57 <zbyszek> Do you have any idea how many users are there?
19:32:30 <StephenGallagher> Was that rhetorical or a request for an actual number?
19:32:52 <zbyszek> Logind/some other systemd services had this issue that nss_nis would stop working when the sandbox was on. I got a small but regular number of bug reports.
19:33:05 <zbyszek> A ballpark figure.
19:33:24 <zbyszek> I know we don't know anything exactly, but I'm afraid that we do have *some* users of this.
19:33:35 <StephenGallagher> I'm sure that we do.
19:33:38 * nirik is +1 as long as there is a release note/doc talking about alternatives, etc.
19:33:56 <StephenGallagher> There are plenty of people out there using NIS in small testing environments simply because it's "easy"
19:34:17 <dcantrell> and don't forget retrocomputing
19:34:34 <StephenGallagher> (At least in comparison to setting up LDAP/FreeIPA is perceived to be)
19:34:35 <nirik> I suspect most of those folks will just move to local users.
19:34:46 <Eighth_Doctor> well, if FreeIPA is similarly "easy" and we provide NIS->FreeIPA guidance, I don't see why we can't do this
19:35:12 <nirik> I don't know that it is... but sure, if it can easily be made so
19:35:17 <zbyszek> Eighth_Doctor: the last time I checked it FreeIPA wasn't easy at all.
19:35:25 <mboddu> I am +1 with the change, with docs and lot of voice in the community that this is happening for f36
19:36:23 <StephenGallagher> zbyszek: I think that's a different debate. I would tend to say that at this point, FreeIPA is probably easier to set up than NIS, but that has to fight with perception
19:37:50 <dcantrell> I am +1 for NIS & NIS+ removal
19:38:06 <dcantrell> I don't have the yellow pages at home anymore, so NIS can go too  :)
19:38:47 <StephenGallagher> I guess I'm coming down on the side of +1, but I'd like to see this Change accompanied by a prominent migration guide
19:38:54 <zbyszek> StephenGallagher: same
19:38:56 <StephenGallagher> Maybe an article for Fedora Magazine would be good?
19:39:17 <mboddu> StephenGallagher: +1
19:39:19 <zbyszek> Yeah, "how to set up freeipa in the simplest fashion" or something like that.
19:39:37 <dcantrell> maybe reference NIS in the title
19:40:09 <zbyszek> OK, can somebody make a proposal that we can vote on?
19:40:19 <StephenGallagher> besser82[m]: I would advise you to talk to the FreeIPA folks and see if they have any existing NIS->FreeIPA material you can take advantage of as well.
19:40:28 <StephenGallagher> I'll make one.
19:41:14 <StephenGallagher> Proposal: NIS/NIS+ will be removed from the distro in F36, contingent upon the inclusion of documentation and/or migration tools being made prominently available.
19:41:20 <zbyszek> +1
19:41:22 <dcantrell> +1
19:41:23 <besser82[m]> StephenGallagher, Will do so.  Who is gonna take care of the article in Fedora Magazine?
19:41:37 <Eighth_Doctor> +1
19:41:39 <nirik> +1
19:41:41 <zbyszek> besser82[m]: we need a volunteer
19:41:46 <mboddu> +1
19:42:17 <zbyszek> besser82[m]: would you be willing to do it?
19:42:30 <StephenGallagher> besser82[m]: It doesn't strictly have to be in the Magazine, but I can probably help you with it if you need assistance.
19:42:42 <zbyszek> #agreed NIS/NIS+ will be removed from the distro in F36, contingent upon the inclusion of documentation and/or migration tools being made prominently available (+6, 0, 0)
19:42:57 <nirik> I think a release note would be just fine too
19:43:11 <besser82[m]> zbyszek, StephenGallagher I can write an article sure, but I don't know any folks responsible for publishing and proof-reading.
19:43:29 <StephenGallagher> The magazine has editors for that
19:43:29 <nirik> the magazine team does that kind of thing. ;) there's editors.
19:43:33 <zbyszek> besser82[m]: oh, that's not a problem, yeah.
19:43:35 <StephenGallagher> And I'm offering to help as well
19:43:57 <besser82[m]> StephenGallagher++ zbyszek++
19:43:57 <zodbot> besser82[m]: Karma for zbyszek changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:44:12 <besser82[m]> StephenGallagher++
19:44:30 <zbyszek> #action besser82[m] will initiate the work on the article
19:44:46 <zbyszek> besser82[m]++ thanks
19:44:46 <zodbot> zbyszek: Karma for besser82 changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:45:08 <besser82[m]> zbyszek, you're welcome =)
19:45:24 <zbyszek> #action StephenGallagher will help too
19:45:27 <mboddu> besser82[m]: https://docs.fedoraproject.org/en-US/fedora-magazine/ should have the workflow
19:45:28 <besser82[m]> StephenGallagher, thanks for offering assistance =)
19:45:54 <zbyszek> OK, let's jump to the last topic.
19:45:59 <zbyszek> #topic #2687 F36 Change: Package information on ELF objects
19:45:59 <zbyszek> .fesco 2687
19:46:00 <zodbot> zbyszek: Issue #2687: F36 Change: Package information on ELF objects - fesco - Pagure.io - https://pagure.io/fesco/issue/2687
19:46:35 <dcantrell> I replied to the thread on this today and mhroncok noted he still needs to catch up on it
19:47:12 * nirik is still +1
19:47:14 <zbyszek> Yeah, I see your and mhroncok's replies now.
19:47:23 * Eighth_Doctor shrugs
19:47:32 <Eighth_Doctor> I don't think this is actually worth it
19:47:38 * mboddu is meh
19:47:54 <Eighth_Doctor> but in lieu of being bashed again, I'm letting it through
19:48:17 <Eighth_Doctor> so I'm +1 while really being -1
19:48:23 <zbyszek> Do you want to punt this to the next week so that we can have more discussion?
19:48:36 <Eighth_Doctor> the discussion has been going in circles for over a week now
19:48:37 <dcantrell> I think we should give it another week
19:48:51 <nirik> I don't guess there's a hurry...
19:49:46 <dcantrell> my main issue is this is an optimization for a very narrow use case that needs to touch every ELF file on the system.  I don't dispute the value it provides in those cases, but I'm just not crazy about adding in JSON data in .gnu.notes in the ELF header
19:50:00 <zbyszek> dcantrell: OK, let's give this another week then.
19:50:12 <dcantrell> ok
19:50:40 <mboddu> Yeah, +1 for another week
19:51:20 <zbyszek> #agreed Let's discuss this more on the mailing list and revisit next week.
19:51:26 <zbyszek> #topic Next week's chair
19:51:41 <zbyszek> Volunteers?
19:52:39 * zbyszek prepares a 5 sided die
19:52:48 <StephenGallagher> I haven't done it for a while
19:53:02 <zbyszek> StephenGallagher, thanks
19:53:10 <zbyszek> #action StephenGallagher will chair the next meeting
19:53:15 <zbyszek> #topic Open Floor
19:53:18 <StephenGallagher> I wasn't volunteering, I was bragging! 😜
19:53:26 <nirik> question: are we keeping this time until after elections/next fesco?
19:53:56 <zbyszek> nirik: I think we should. We might need to change the time in a few weeks anyway.
19:54:13 <nirik> ok, I'll try and move our standup to another time then. :(
19:54:17 <StephenGallagher> Yeah, I don't think it makes sense to move it right now
19:54:30 <nirik> well, we did move it... but ok
19:55:20 <zbyszek> OK, anything else?
19:55:36 <zbyszek> If not I'll just go fall asleep in a minute.
19:56:27 <zbyszek> Thank you all for coming.
19:56:28 <zbyszek> #endmeeting