17:00:45 <tstellar> #startmeeting FESCO (2023-11-02)
17:00:45 <zodbot> Meeting started Thu Nov  2 17:00:45 2023 UTC.
17:00:45 <zodbot> This meeting is logged and archived in a public location.
17:00:45 <zodbot> The chair is tstellar. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:45 <zodbot> The meeting name has been set to 'fesco_(2023-11-02)'
17:00:52 <tstellar> #meetingname fesco
17:00:52 <zodbot> The meeting name has been set to 'fesco'
17:01:01 <tstellar> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor, tstellar
17:01:01 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok nirik sgallagh tstellar zbyszek
17:01:04 <nirik> morning
17:01:06 <tstellar> #topic init process
17:01:09 <Son_Goku> hey folks
17:01:13 <Son_Goku> .hello ngompa
17:01:14 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:18 <tstellar> .hello tstellar
17:01:19 <zodbot> tstellar: tstellar 'Tom Stellard' <tstellar@redhat.com>
17:01:48 <dcantrell> .hello2
17:01:49 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:05:17 <tstellar> Ok, we have quorum barely.  Let's wait a few more minutes and see if anyone else joins.
17:05:34 <tstellar> Oops actually we don't.  I counted myself twice.
17:05:40 <dcantrell> off by one
17:05:44 <Son_Goku> lol
17:06:05 <decathorpe> hello
17:06:08 <decathorpe> .hi
17:06:09 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:06:33 <tstellar> OK, now there is quorum.
17:08:48 <tstellar> Let's start.
17:09:08 <tstellar> #topic #3089  retiring redhat-lsb in Fedora
17:09:13 <tstellar> .fesco 3089
17:09:14 <zodbot> tstellar: Issue #3089: retiring redhat-lsb in Fedora - fesco - Pagure.io - https://pagure.io/fesco/issue/3089
17:09:57 <Son_Goku> carlwgeorge: ping
17:09:57 <zodbot> Son_Goku: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
17:10:02 <Son_Goku> blech
17:10:09 <Son_Goku> carlwgeorge: are you here to talk about your topic?
17:10:21 <tstellar> As I understand the issue.  There is strong interest in retiring the package, but the maintainer disagrees.
17:10:36 <carlwgeorge> .hi
17:10:37 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
17:11:37 <carlwgeorge> tstellar: that's the gist of it
17:11:44 <dcantrell> is the maintainer here?
17:12:01 <tstellar> Are there any alternatives to retiring it?  Is it realistic to fix it?
17:12:20 <carlwgeorge> at a minimum, the EPEL steering committee is firmly against the package going into EPEL 9 in its current state
17:12:21 * nirik is +1 to retire, but would be nice to convince the maintainer of that.
17:12:52 <carlwgeorge> I don't believe it can realistically can be fixed, no
17:13:05 <dcavalca> .hi
17:13:06 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <davide@cavalca.name>
17:13:19 <dcavalca> what are the maintainer objections to the retirement?
17:13:27 <carlwgeorge> if the upstream wasn't defunct, it might be possible, but would still take a lot of work
17:13:37 <dcantrell> is upstream defunct?
17:13:53 <carlwgeorge> last update in 2015 iirc
17:13:54 <dcantrell> I mean, my own take is that LSB is no longer relevant to Linux distributions.  it's time has passed
17:14:09 <dcantrell> carlwgeorge: that doesn't mean it's defunct
17:14:35 <decathorpe> anything that still things Qt4 is the hot new thing is kind of defunct by definition for me
17:14:38 <dcantrell> what I would like to hear from the maintainer is why this needs to stay in Fedora
17:14:54 <dcantrell> -or- what would we break in Fedora by retiring redhat-lsb
17:15:07 <carlwgeorge> the RH kbase article about it says the governing body no longer exists
17:15:49 <decathorpe> there are two packages that currently depend on "redhat-lsb*": la-capitaine-icon-theme and rbm
17:15:49 <nirik> yeah, there's not been much info on what the use case is. If it's lsb_release the other package can do that
17:15:55 <decathorpe> and I assume those two are both mistakes
17:16:59 <dcantrell> oh good, at least we are in compliance with what LSB 5.0 says about Python.  it says we need Python 2.4.2 or greater  :)
17:17:17 <decathorpe> ☠️
17:17:27 <carlwgeorge> as I understand it, there are two use cases for requiring it directly
17:18:05 <michel-slm> for Python... I thought it also requires some modules that are deprecated /or/ removed so we are not even in compliance? :)
17:18:10 <carlwgeorge> you either actually require the things redhat-lsb requires, in which case you can require them directly
17:18:28 <nirik> (or you can't because fedora no longer ships them :)
17:18:30 <dcantrell> michel-slm: possibly, I didn't read that page
17:18:44 <michel-slm> I have not read it but it's in the Pagure ticket somewhere
17:18:52 <carlwgeorge> or your program runs the lsb_release command
17:18:55 <tstellar> If lsb is obsolete why do we need to add the lsb_release pacakge?
17:19:25 <michel-slm> tstellar: iirc lsb_release still has more usage (like in Puppet)
17:19:41 <michel-slm> Chef got fixed to use /etc/os-release ... I think Salt still use lsb_release too?
17:19:44 <tstellar> michel-slm: What is it used for?
17:19:46 <carlwgeorge> michel-slm: you're correct, and the python modules I found are listed in the ticket
17:19:57 <michel-slm> but yeah those should be removed eventually
17:20:26 <carlwgeorge> tstellar: did you read the issue?
17:20:27 <michel-slm> tstellar: configuration management tools expose what OS they are running on so recipes/playbooks/etc can behave differently based on that info
17:20:48 <dcavalca> tstellar: a bunch of proprietary software also shells out lsb_release to figure out the platform it's running on
17:21:16 <tstellar> carlwgeorge: Yes, I did.
17:21:44 <decathorpe> the official google chrome RPMs also used to depend on redhat-lsb, but I think that was fixed a while ago
17:22:01 <Son_Goku> decathorpe: yes, I fixed it 😅
17:22:18 <carlwgeorge> tstellar: see the second half of https://pagure.io/fesco/issue/3089#comment-881339
17:22:20 <Son_Goku> rewriting those scripts was annoying
17:22:34 <Son_Goku> but a lot of electron apps have versions of those scripts from before the rework in chromium
17:22:43 <Son_Goku> so the tool _needs_ to exist for them
17:22:54 <dcavalca> https://github.com/search?q=lsb_release+NOT+language%3AMarkdown&type=code has over 200k results for the record
17:23:01 <carlwgeorge> to rephrase it, lsb_release doesn't claim to implement the full lsb, it only provides /usr/bin/lsb_release for software that is hard coded to need that
17:23:22 <dcantrell> and lsb_release (or lsb-release) happily returns "n/a" on Fedora
17:23:31 <Son_Goku> yup, on purpose :)
17:23:43 <dcantrell> that could just be moved to the os-release package
17:24:02 <Son_Goku> though technically, it would return actual lsb values if a package providing /etc/lsb-release.d/* or /etc/lsb-release files were installed
17:24:14 <tstellar> Is the minimal lsb_release better than the on n redhat-lsb ?  The maintainer seems to think the one in redhat-lsb is sufficient.
17:24:24 <michel-slm> we definitely should do a Change Proposal to 'deprecate lsb_release' the same way we have one for deprecating Python mock ... in the future
17:24:32 <michel-slm> but that should not block retiring redhat-lsb
17:24:46 <Son_Goku> the redhat-lsb package's version requires every distro to customize it to get the correct output
17:25:12 <Son_Goku> just thinking about CentOS and RHEL, that's messy
17:25:31 <Son_Goku> but then other derivatives it'd be even more of a problem
17:25:49 <decathorpe> also, claiming support for LSB 5.0 but ... just not adding dependencies for mandatory components (because they are obsolete and no longer present in fedora) isn't good
17:26:31 <dcantrell> are lsb_release and redhat-lsb supposed to be able to install concurrently?  because i'm seeing conflicts.  I can't install both and lsb_release just provides that pointless program in /usr/bin
17:26:42 <Son_Goku> no, they are not supposed to be concurrent
17:26:54 <dcantrell> these two things are pointless now
17:27:05 <tstellar> Time check: It's been 15 minutes, do we want to continue to discuss or should we come to a conclusion?
17:27:13 <Son_Goku> the only other thing from redhat-lsb that might be worth salvaging is the init script stuff
17:27:16 <dcantrell> I can see someone arguing that they use redhat-lsb when installing via kickstart and use that package to pull in deps, but it brings in ancient deps like qt3.  so again, I don't care
17:27:21 <carlwgeorge> the program, while a bit silly, isn't pointless when third party software requires it
17:27:32 <dcantrell> tstellar: I don't want to make a decision until we hear from the maintainer
17:28:16 <Son_Goku> but I think we could just move the sysvinit lsb functions files into initscripts and call it a day
17:28:52 <Son_Goku> (this is, of course, assuming those functions are in redhat-lsb and not somewhere else already)
17:28:53 <carlwgeorge> the maintainer has previously replied in the ticket, so he likely saw the last comment about it being discussed here today
17:29:27 <tstellar> So should we invite the maintainer to our next meeting??
17:29:37 <dcantrell> yes, I think that is fair
17:29:45 <dcantrell> we shouldn't make a decision on that without them being in the discussion
17:30:14 <tstellar> #proposal Continue disucssing this issue in our next meeting and invite the maintainer.
17:30:28 <decathorpe> note that this will likely be too late to retire it from f39.
17:30:39 <dcantrell> then it's too late
17:30:54 <dcantrell> it's not fair to a maintainer to make a decision on their package when they aren't around
17:32:13 <dcantrell> tstellar: +1
17:32:33 <carlwgeorge> one last thing i'll note
17:33:19 <carlwgeorge> the concern that the package not correctly implementing lsb causes missed user expectations is not conjecture.  it has resulted in bugs being filed before.
17:33:24 <carlwgeorge> https://bugzilla.redhat.com/show_bug.cgi?id=2055953
17:35:14 <Son_Goku> I know that when carlwgeorge brought this up during the EPEL steering committee meeting last week, I started poking around and kept finding more broken things
17:35:29 <Son_Goku> I stopped looking because it's too much :/
17:35:41 <dcantrell> I am all for retiring the package, but I really want the maintainer to weigh in at a meeting if we're discussing here to make a deicsion
17:37:06 <tstellar> +1 to my own proposal, though pushing to next week and inviting the maintainer is probably the default action if we can't decide something else today.
17:37:16 <decathorpe> reading previous replies, I don't think the maintainer will change their mind ... but oh well
17:37:41 <decathorpe> so count me as ±0
17:37:48 <carlwgeorge> to decathorpe's point, i encourage fesco members to read through the epel bodhi update for context https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-336dbb57e0
17:38:04 <Son_Goku> this was why it got bounced to fesco
17:38:19 <Son_Goku> because it started turning nasty :/
17:39:06 <carlwgeorge> the maintainer so far has been unwilling to even request the dependencies that are in fedora be branched for epel, instead using recommends inappropriately
17:40:28 <carlwgeorge> i understand wanting to give the maintainer a chance to weigh in at the next meeting, as long as fesco is fine with the package shipping in f39 in its current state
17:40:31 <tstellar> Procedural question.  The ticket has enough votes to be approved, but not enough to be fast tracked, so what does that mean?  If it's approved but not fast tracked, can the package still be retired in f39?
17:41:04 <michel-slm> doesn't fast tracked just mean it can be decided before the full meeting?
17:41:15 <decathorpe> if we send it back to ticket voting, it will be approved after 7 days
17:41:24 <nirik> The package is in f37/f38... so...
17:41:26 <decathorpe> (if I understand the new voting rules correctly)
17:41:34 <tstellar> decathorpe: 7 days from filing or 7 days from the meeting?
17:42:00 <decathorpe> 7 days from filing the ticket, I think?
17:42:21 <tstellar> Ok, so if we don't agree to discuss during next meeting, then ticket will be approved in ~2 days.
17:42:39 <carlwgeorge> nirik: i was about to say those branches are on version 4.1, but it looks like f39 is too after Son_Goku unpushed the f39 update
17:42:48 <tstellar> It seems like this is where we are at.
17:43:05 <nirik> it's really too late to retire in 39 I'm afraid.
17:43:34 <carlwgeorge> that's fine as version 4.1 is somewhat less broken than the 5.0 update
17:43:47 <tstellar> carlwgeorge: Isn't there a 5.0 update for f39 though?
17:43:50 <decathorpe> if it's too late for f39, then I am OK with discussion next week.
17:44:05 <carlwgeorge> tstellar: Son_Goku unpushed it https://bodhi.fedoraproject.org/updates/FEDORA-2023-8e90030e60
17:44:10 <tstellar> carlwgeorge: Ok
17:44:38 <tstellar> decathorpe: But the propsoal just addresses retirement in general.  Retiring from f39 was requested but not the main goal of the proposal as I understand.
17:44:42 <carlwgeorge> so f39 will ship with the status-quo 4.1 that f38 has, reducing the severity in my opinion
17:45:35 <carlwgeorge> i expect i can make the meeting next week to be available for questions
17:46:14 <tstellar> Alright, it's been over 30 minutes now we should move on.  If this is approved via ticket voting (likely) then the package can be retired from f40 but not f39.
17:48:14 <tstellar> #topic Next week's chair
17:48:19 <tstellar> Any volunteers?
17:48:22 <Son_Goku> I'll take it
17:48:36 <tstellar> #action Son_Goku will chair next meeting
17:48:42 <tstellar> Son_Goku: Thank you!
17:48:42 <Son_Goku> hopefully we won't have go/no-go and this at the same time next week :)
17:48:48 <Son_Goku> otherwise this will be hard
17:48:50 <tstellar> #topic Open Floor
17:48:54 <tstellar> Anything else to discuss?
17:49:08 <Son_Goku> we need to move this meeting back to Tuesday
17:49:17 <michel-slm> or get the blocker meeting to move
17:49:24 <Son_Goku> the blocker meeting cannot move
17:49:42 <Son_Goku> it's at the beginning of the week so that there's time to do compose adjustments and such for the go/no-go meeting
17:49:51 <tstellar> Does someone want to volunteer to do a when is good poll?
17:50:20 <nirik> I think the last whenisgood didn't have any tuesday time we are all able to make
17:50:22 <michel-slm> ah I mean that go/no go but I guess same problem
17:51:12 <tstellar> Is the only reason to move the day, the conflict with the go/no-go meeting?
17:51:40 <Son_Goku> we also need to be early enough to be able to make decisions that affect it
17:51:56 <decathorpe> if there are FESCo blockers, it's also good to decide on them *before* go/no-go meetings rather than ... concurrently with them
17:52:04 <Son_Goku> for example, I would have not attempted fast track for today's topic if the meeting was on tuesday
17:52:21 <Son_Goku> and yes, fesco blockers may need discussion and propagate up before go/no-go
17:52:32 <Son_Goku> it really needs to be monday or tuesday
17:53:12 <Son_Goku> and we should document this rationale for why we need it on these days because otherwise we'll forget and do this again :)
17:54:36 <tstellar> Son_Goku: Do you want to create a ticket for this, so we can discuss offline.
17:54:36 <nirik> well, ideally, we decide things that affect the release long before go/nogo
17:54:50 <Son_Goku> tstellar: sure, I'll do that
17:56:00 <tstellar> #action Son_Goku will file a ticket so we can continue to discuss a new meeting time.
17:56:03 <decathorpe> nirik: "ideally" meaning Sperical Cows and all that?
17:56:10 <Son_Goku> :D
17:56:11 <nirik> heh.
17:56:29 <michel-slm> ideally contentious updates don't get published after the beta ;)
17:56:41 <tstellar> OK, we have 5 minutes left.  Anything else to discuss.
17:56:46 <decathorpe> true ...
18:00:41 <tstellar> No more topics then.
18:00:45 <tstellar> #endmeeting