15:00:13 <zbyszek> #startmeeting FESCO (2021-03-03)
15:00:13 <zodbot> Meeting started Wed Mar  3 15:00:13 2021 UTC.
15:00:13 <zodbot> This meeting is logged and archived in a public location.
15:00:13 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:13 <zodbot> The meeting name has been set to 'fesco_(2021-03-03)'
15:00:14 <zbyszek> #meetingname fesco
15:00:14 <zodbot> The meeting name has been set to 'fesco'
15:00:14 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
15:00:14 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:16 <zbyszek> #topic init process
15:00:19 <zbyszek> Hello!
15:00:24 <nirik> morning
15:00:30 <mhroncok> .hello churchyard
15:00:33 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:00:42 <sgallagh> .hello2
15:00:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:25 <sgallagh> Splitting my time between this and another meeting
15:01:42 <zbyszek> That means we have 3.5 people.
15:01:49 <bcotton> .hello2
15:01:50 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:58 <bcotton> now we still have 3.5 people :-)
15:02:02 <decathorpe> .hello2
15:02:03 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:02:13 <decathorpe> splitting this between here and 2 concurrent online courses :)
15:02:38 <zbyszek> This strange math. We're up to 5, almost.
15:02:40 <zbyszek> Let's start.
15:02:41 <decathorpe> so ... 3.83333 people?
15:03:03 <zbyszek> Round up to 5!
15:03:03 <bcotton> asymptotically approaching quorum
15:03:04 <zbyszek> #topic #2584 Fedora 34 incomplete changes: 100% complete dealine
15:03:04 <zbyszek> .fesco 2584
15:03:05 <zodbot> zbyszek: Issue #2584: Fedora 34 incomplete changes: 100% complete dealine - fesco - Pagure.io - https://pagure.io/fesco/issue/2584
15:03:32 <sgallagh> I'm sufficiently here for voting purposes :)
15:03:34 <zbyszek> I think we're good here. I put this on the agenda just to check.
15:03:46 * nirik checks the bz query
15:03:56 <zbyszek> bcotton: did you talk to eclipseo?
15:04:10 <bcotton> the only open question is if the libusb packages change is entirely f35 at this point, but i'm inclined to say it is
15:04:10 <bcotton> https://bugzilla.redhat.com/show_bug.cgi?id=1906540
15:04:18 <bcotton> zbyszek: i did, no reply yet
15:05:08 <zbyszek> I think we don't need to do anything right now.
15:05:20 <bcotton> agreed
15:05:40 <bcotton> we'll need to revisit xorg deaggregation after the beta release, since the deadline was extended for that change
15:05:49 <bcotton> but i think we're covered for this week
15:05:58 <zbyszek> OK, let's go to the next topic.
15:06:04 <zbyszek> #topic #2579 F35 Change: Autoconf-2.71
15:06:04 <zbyszek> .fesco 2579
15:06:05 <zodbot> zbyszek: Issue #2579: F35 Change: Autoconf-2.71 - fesco - Pagure.io - https://pagure.io/fesco/issue/2579
15:06:36 <zbyszek> We have two +1 votes in the ticket.
15:07:18 <sgallagh> They've decided that there will be a compat package, so I think this is fine to approve.
15:07:23 <nirik> I thought there were still some questions on the list?
15:07:40 <zbyszek> Details are being figured out, like whether the compat package name should have a dot.
15:07:55 <zbyszek> We don't need to block on this.
15:08:01 <decathorpe> have my +1 vote as well. with compat package this is fine, though I'd like to know how "broken" packages get changed to use the compat package. will maintainers need to do that themselves?
15:08:50 <nirik> +1 with the compat I guess... but would be nice to know all the details before too long.
15:08:59 <zbyszek> That's a good question. The Change page doesn't answer this.
15:09:27 <zbyszek> I think either option (change owner or other maintainers) is fine, as long as it's clear who's responsible.
15:10:01 <decathorpe> zbyszek: yeah. both is fine, but the expectation should be clear as to who needs to do it.
15:10:21 <zbyszek> I'll ask Ondrej to add that info.
15:10:52 <zbyszek> sgallagh: a formal vote?
15:11:14 <sgallagh> I was +1 in the ticket, but have one here too
15:11:34 <zbyszek> sgallagh: oops, indeed. I missed that.
15:11:47 <zbyszek> #agreed APPROVED (+5, 0, 0)
15:12:14 <zbyszek> #action zbyszek to ask for the details about who will update packages to be added to the Change page
15:12:22 <zbyszek> #topic #2581 F35 Change: POWER 4KiB page size
15:12:22 <zbyszek> .fesco 2581
15:12:23 <zodbot> zbyszek: Issue #2581: F35 Change: POWER 4KiB page size - fesco - Pagure.io - https://pagure.io/fesco/issue/2581
15:12:32 * sgallagh was -1 in the ticket
15:13:21 <decathorpe> I am -1 as well. I'd rather see btrfs and radeon drivers fixed properly than hit everything with the big hammer
15:14:06 <nirik> yeah... same
15:14:41 <decathorpe> that's great
15:15:43 <decathorpe> Maybe somebody can connect people with the necessary radeon + POWER hardware with upstream developers to get this fixed? It sounds like those people do not talk to each other (which is weird)
15:16:18 <zbyszek> Frankly, I don't understand this enough to have an informed opinion.
15:17:18 <zbyszek> But a strong justification and/or consensus would be necessary for me to override the maintainers.
15:17:28 <mhroncok> zbyszek: +1
15:18:53 <zbyszek> So... any comments? Should we vote?
15:19:22 <sgallagh> Sounds to me like we already have consensus, so might as well formalize it
15:19:35 <zbyszek> Ack.
15:20:06 <zbyszek> We have -1: sgallagh, decathorpe, mhroncok
15:20:14 <zbyszek> I'll add my -1
15:20:20 <sgallagh> nirik also said "same" above
15:20:25 <nirik> yeah, -1 here
15:20:37 <zbyszek> #agreed REJECTED (0, 0, -5)
15:20:41 <zbyszek> #topic #2585 systemd-resolved: stub resolver is not following CNAME for resolution
15:20:44 <zbyszek> .fesco 2585
15:20:45 <zodbot> zbyszek: Issue #2585: systemd-resolved: stub resolver is not following CNAME for resolution - fesco - Pagure.io - https://pagure.io/fesco/issue/2585
15:21:18 <zbyszek> We have +5 for beta blocker.
15:21:31 <zbyszek> But I'd like to propose the following:
15:21:46 <nirik> this one is weird. I don't see here it here... but I guess thats just some weird difference.
15:22:13 <zbyszek> No FESCo ticket is necessary for obvious "breaks the world" bugs, even if there is no specific criterion.
15:23:54 <nirik> I think it would fall under the critera cmurf mentioned there. It might be fixable on installs with an update, but not on live media thats already shipped.
15:24:18 <mhroncok> also, if your mirror is on CNAME, not sure if you can update :/
15:24:37 <decathorpe> mhroncok: that's a good point
15:25:22 <zbyszek> OK, let's go back one step.
15:25:29 <sgallagh> FWIW, I've noticed pretty slow DNS resolution on my F34 system sometimes. I have to wonder if this is related.
15:25:38 <zbyszek> Is anyone against approving this as a beta blocker?
15:26:18 <nirik> well, the scope is a bit fuzzy to me.
15:26:42 <zbyszek> #agreed
15:26:46 <zbyszek> Sorry.
15:27:07 * nirik looks at schedule
15:27:42 <nirik> go/no-go is a week from tomorrow right?
15:27:49 <bcotton> correct
15:27:55 <zbyszek> I think the bugs needs to be resolved. If it turns out that the scope is limited, then it can be reassigned for later.
15:28:06 <zbyszek> I'd opt on the side of caution here.
15:28:10 <nirik> so, we could just say there's not enough info to decide... and decide next week if it's not fixed?
15:29:30 <nirik> or I guess we could say it's a beta blocker, but if the scope is really small or something we can revisit next week. :)
15:29:39 <zbyszek> Yeah, I'd prefer the latter.
15:29:45 <sgallagh> zbyszek: +1
15:30:11 <zbyszek> If it turns out that there's a fix ready (which is likely to happen concurrently with the actual scope of the bug being figured out), I don't want to wait a few more days for a freeze exception.
15:30:25 <cmurf> btw, anyone with a clean install in the past ~3 months will have NetworkManager managed /etc/resolv.conf, rather than it pointing to stub-resolv.conf
15:30:34 <cmurf> and also this bug has a freeze exception
15:31:03 <zbyszek> OK, let's say that this is approved.
15:31:11 <zbyszek> #agreed APPROVED (+1, 0, 0)
15:31:30 <mhroncok> +1?
15:31:35 <decathorpe> +1? :)
15:31:37 <zbyszek> #undo
15:31:37 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:31:11 : APPROVED (+1, 0, 0)
15:31:41 <zbyszek> #agreed APPROVED (+6, 0, 0)
15:31:45 <zbyszek> #undo
15:31:45 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:31:41 : APPROVED (+6, 0, 0)
15:31:52 <zbyszek> #agreed Beta freeze exception is APPROVED (+6, 0, 0)
15:32:06 <zbyszek> (for clarity, because there was also my proposal which doesn't seem to have any traction.)
15:32:07 <sgallagh> I thought we voted for blocker...
15:32:12 <zbyszek> #topic Next week's chair
15:32:17 <mhroncok> blocker?
15:32:24 <zbyszek> #undo
15:32:24 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fd49d118f10>
15:32:27 <zbyszek> #undo
15:32:27 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:31:52 : Beta freeze exception is APPROVED (+6, 0, 0)
15:32:35 <zbyszek> #agreed Beta blocker is APPROVED (+6, 0, 0)
15:32:39 <zbyszek> #topic Next week's chair
15:32:53 <zbyszek> Thanks sgallagh.
15:32:59 <sgallagh> np
15:33:06 <zbyszek> Volunteers?
15:33:29 <sgallagh> Starting this week, I now have a conflict for the first 30 minutes of this time-slot, which will make it hard to chair :-(
15:34:07 <decathorpe> yeah this semester this time slot is also very bad for me since it collides with two courses at university :/
15:34:35 <zbyszek> We could revisit the time. We're barely making quorum recently anyway.
15:34:55 <zbyszek> OK, no volunteers. I can do it again next week.
15:35:03 <zbyszek> #action zbyszek will chair next meeting
15:35:06 <zbyszek> #topic Open Floor
15:35:27 <sgallagh> cmurf: " chris btw, anyone with a clean install in the past ~3 months will have NetworkManager managed /etc/resolv.conf, rather than it pointing to stub-resolv.conf"
15:35:30 <sgallagh> Can you expand on that?
15:36:40 <zbyszek> sgallagh: there's a bug open
15:36:43 <zbyszek> .bug 1933454
15:36:45 <zodbot> zbyszek: 1933454 – /etc/resolv.conf is not a symlink - https://bugzilla.redhat.com/1933454
15:37:00 <sgallagh> I meant in the context of the CNAME issue.
15:37:22 <sgallagh> cmurf just replied to me elsewhere: " it appears to have an effect in that if i stop systemd-resolved, and let NetworkManger create /etc/resolv.conf (i.e. remove the symlink and reboot or restart NM) then the problem doesn't happen"
15:38:05 <cmurf> a 3rd possibility is resolved is running, but NetworkManager manages /etc/resolv.conf, this is still resolv.conf mode: foreign
15:38:20 <sgallagh> Mostly I'm wondering if the fact that I still have the symlink to the stub-resolver is why I'm having slow resolution issues
15:38:28 <cmurf> and i'm not sure what's going on there because it's sort of an unintended configuration afaik
15:38:31 <sgallagh> And whether that's a symptom of the same problem
15:38:36 <cmurf> i don't know
15:38:59 <sgallagh> OK, we don't need to hash it out here. I was just trying to figure out if that was relevant information.
15:39:05 <cmurf> network stuff can be pretty non-deterministic
15:39:06 <zbyszek> The opposite: I expect the CNAME bug only happens when the local stub is used, and when NM takes over resolv.conf, the stub is not used.
15:39:25 <zbyszek> ("opposite" to "symptom of the same problem")
15:39:37 <sgallagh> zbyszek: I think we're getting our lines crossed.
15:39:46 <zbyszek> sgallagh: yeah, I see that now.
15:39:53 <sgallagh> My resolv.conf is managed by systemd-resolved
15:40:01 <zbyszek> sgallagh: it's not my day clearly.
15:40:33 <cmurf> yeah if you have upgraded from f33 or got an f34 clean install, then /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
15:40:48 <cmurf> f34 clean install ^a few months ago
15:41:01 <sgallagh> I upgraded, yeah
15:41:09 <cmurf> so
15:41:28 <zbyszek> cmurf?
15:41:31 <cmurf> i have heard some folks report slow application launch times, such as firefox, if resolved is running
15:41:44 <cmurf> and if they merely stop it, the launch times are normal
15:41:53 <cmurf> as in 30 seconds to launch vs 2
15:42:13 <cmurf> i haven't reproduced this so it could be a local phenomenon combined with resolved, perhaps
15:42:14 <zbyszek> It could be. If firefox is resolving something at startup and resolved doesn't return the expected answer...
15:42:18 <sgallagh> It's not just launch times, it's the first access of many (but not all) sites
15:42:26 <cmurf> could be related
15:42:30 * sgallagh nods
15:42:38 <sgallagh> I'll follow up elsewhere. No need to prolong this meeting.
15:42:42 <zbyszek> Right.
15:42:49 <zbyszek> Anything else for Open Floor?
15:43:16 <nirik> I had a quick item...
15:43:19 <zbyszek> nirik: go
15:43:48 <nirik> Just a short heads up: The new account system is coming soon (likely after beta is out the door). More schedule and docs and lists of changes soon also...
15:44:22 <zbyszek> Nice!
15:44:39 <sgallagh> Will there be end-user action that needs to be taken?
15:44:47 <sgallagh> (Updating passwords, etc.?)
15:45:12 <nirik> no password updating, but there will be some other workflow type changes
15:45:52 <zbyszek> OK, let's wrap this up.
15:45:58 <zbyszek> Thanks all. See you next week.
15:46:01 <zbyszek> #endmeeting