17:00:59 <adamw> #startmeeting F34-blocker-review
17:00:59 <zodbot> Meeting started Mon Mar  8 17:00:59 2021 UTC.
17:00:59 <zodbot> This meeting is logged and archived in a public location.
17:00:59 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:59 <zodbot> The meeting name has been set to 'f34-blocker-review'
17:01:04 <adamw> #meetingname F34-blocker-review
17:01:04 <zodbot> The meeting name has been set to 'f34-blocker-review'
17:01:09 <adamw> #topic Roll Call
17:01:27 <lruzicka[m]> .hello lruzicka
17:01:28 <zodbot> lruzicka[m]: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:01:32 <adamw> morning folks, who's around for blocker funtimes
17:01:42 * cmurf screeches to a halt in blocker review
17:01:55 <lruzicka[m]> and here I am, lord
17:02:07 <pwhalen> .hello pwhalen
17:02:08 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:02:12 * coremodule is here, willing to act as secretary for the meeting.
17:03:21 <adamw> thanks coremodule!
17:03:22 <bcotton> .hello2
17:03:22 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:05:45 <adamw> alrighty, let's get rolling
17:05:50 <adamw> impending boilerplate alert
17:05:58 <adamw> #chair pwhalen bcotton
17:05:58 <zodbot> Current chairs: adamw bcotton pwhalen
17:06:03 <adamw> #topic Introduction
17:06:07 <adamw> Why are we here?
17:06:14 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:06:19 <adamw> #info We'll be following the process outlined at:
17:06:25 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:29 <adamw> #info The bugs up for review today are available at:
17:06:35 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:06:40 <adamw> #info The criteria for release blocking bugs can be found at:
17:06:45 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:06:49 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria
17:06:55 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria
17:07:14 <adamw> #info for Beta, we have:
17:07:14 <adamw> #info 1 Proposed Blockers
17:07:20 <adamw> #info 3 Accepted Blockers
17:07:24 <adamw> #info 7 Proposed Freeze Exceptions
17:07:24 <adamw> #info 12 Accepted Freeze Exceptions
17:07:34 <adamw> #info for Final, we have:
17:07:41 <adamw> #info 2 Proposed Blockers
17:07:41 <adamw> #info 5 Accepted Blockers
17:07:46 <adamw> #info coremodule will secretarialize
17:07:52 <adamw> so without further ado, let's get going with the...
17:07:55 <adamw> #topic Proposed Beta blocker
17:08:06 * adamw sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/hJIonhhMLbjQhzWrCJjfnXEM/message.txt >
17:08:23 <adamw> to be clear here, cmurf, are you proposing the crashes as a blocker, or the abrt behaviour?
17:08:44 <pwhalen> adamw: you're sending long messages again
17:08:48 <pwhalen> adamw sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/hJIonhhMLbjQhzWrCJjfnXEM/message.txt >
17:09:27 <adamw> GAH
17:09:28 <adamw> i forgot
17:09:34 <adamw> so annoying
17:09:40 <adamw> #topic (1936288) multiple user space crashes are assigned to kernel-core and cannot be reported
17:09:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1936288
17:09:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/286
17:09:52 <adamw> #info Proposed Blocker, gnome-abrt, NEW
17:10:03 <cmurf> oh man what a terrible first bug
17:10:24 <cmurf> the reporter should be fired
17:11:26 <cmurf> the gist is that some times, not always, crashes for things like gnome-shell and even services like uresourced, get dinged against the kernel
17:11:51 <cmurf> and also can't be processed by either the retrace service or locally
17:12:18 <adamw> i noted why i think that is in the bug
17:12:26 <adamw> it's because the issue is a GPF, which the kernel catches
17:13:14 <cmurf> looks like it's a known issue too, https://github.com/abrt/abrt/issues/1386
17:13:22 <cmurf> ok so it's looking even less blockery
17:14:36 <adamw> yeah, if we're talking about the abrt behaviour i'm inclined to not-blocker
17:15:42 <cmurf> ok i'm going to -1 beta block my own bug
17:15:58 <lruzicka[m]> Abrt reports them from time to time on my machine, but the system seems to be sound and stable.
17:15:58 <adamw> heh
17:16:07 <lruzicka[m]> so let's do -1 BB
17:16:07 <adamw> -1 here too
17:16:24 <adamw> it's clearly a situation abrt should handle better somehow, but it's been the case for a while and there's no real justification to block a beta on it
17:16:29 <pwhalen> -1 BB, I've seen as well with no impact
17:17:55 <adamw> i mean, the impact is we can't debug the crash very well :P so there is an impact
17:18:25 <adamw> but i think cmurf was worried it was some new behaviour that might affect a lot of crashes, whereas it's actually nothing new and we know the bounds quite well: GPFs
17:18:35 <cmurf> correct
17:18:56 <pwhalen> Right, sorry I meant on the system.
17:19:13 <bcotton> -1 blockah
17:19:25 <cmurf> and also, these crashes are happening on reboot so there's something about how they're terminating that's the actual bug
17:19:48 <cmurf> but also that systemd-coredump can't get a coredump file is troublesome
17:19:55 <adamw> proposed #agreed 1936288 - RejectedBlocker (Beta) - this is definitely a case abrt should handle better, but it's not new and we know the bounds of it quite well (GPFs), it's not broad enough to block a release
17:20:01 <lruzicka[m]> ack
17:20:04 <cmurf> ack
17:20:10 <pwhalen> ack
17:20:46 <adamw> #agreed 1936288 - RejectedBlocker (Beta) - this is definitely a case abrt should handle better, but it's not new and we know the bounds of it quite well (GPFs), it's not broad enough to block a release
17:22:46 <adamw> ok, moving on to:
17:22:51 <adamw> #topic Proposed Beta freeze exceptions
17:23:25 <adamw> #topic (1934149) F34FailsToInstall: 0ad
17:23:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1934149
17:23:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/277
17:23:37 <adamw> #info Proposed Freeze Exceptions, 0ad, VERIFIED
17:23:44 <adamw> so, there are five similar bugs
17:23:53 <cmurf> yeah i got to the 3rd one and went "wait a minute"
17:24:02 <adamw> in the interests of time i'm proposing we take this as a proxy for all of them - whatever we decide for this i will apply to the other four as well
17:24:05 <adamw> does that sound cool to everyone?
17:24:09 <cmurf> yes please
17:24:22 <lruzicka[m]> yes
17:24:28 <bcotton> ack
17:24:57 <adamw> #agreed we will treat this bug as a proxy for all five proposed 'fails to install' bugs
17:25:35 <adamw> so, the question is kinda: what benefit is there to granting an FE to fix fails-to-install for packages not included on any blocking media (as I believe none of these five are)?
17:25:46 <adamw> i can think of two things: one, better overall quality of the frozen Beta tree (very meh)
17:26:10 <adamw> two, people upgrading from f33 to f34 beta likely don't have updates-testing enabled and so if they have one of these packages installed the upgrade will complain/leave it out at first
17:26:57 <lruzicka[m]> I suggested +1FE because I believe that even reason is nice to have
17:27:06 <lruzicka[m]> reason 1
17:27:39 <bcotton> i was -1 in the ticket, but i suppose there's no real harm in letting them in, since they won't land on any media
17:28:03 <cmurf> so it comes down to, it's neutral to good so long as it doesn't blow up composes, but we don't know for sure it won't blow up composes because we don't have a dry run function
17:28:31 <bcotton> i guess my question is "how much effort does it take to let them through and is that effort worth the minimal gains of not waiting for the release day"
17:28:53 <cmurf> exactly
17:29:53 <adamw> the second reason is the one that has merit for me
17:30:24 <adamw> we've definitely given FEs on that ground before, though usually when the bug report is framed "upgrade failed because XXX", not "package Y fails to install"
17:30:48 <cmurf> i guess the conclusion is the same
17:30:50 <pwhalen> same, smooth upgrades seem worthy
17:31:36 <cmurf> ok i'll stick to my +1's and extend to the lot
17:31:38 <pwhalen> +1 FE
17:32:19 <lruzicka[m]> Upgrades, btw., I had problems to upgrade from 20210227 to latest in the virtual machine, but I am willing to wait for open floor
17:32:28 <adamw> yeah, i'll lean +1 with the proviso i'll check the changelogs and stuff quite closely before actually submitting any fixes to be pushed
17:34:02 <adamw> any other votes?
17:34:28 <lruzicka[m]> +1FE to repeat
17:34:39 <coremodule> +1 FE
17:34:56 <bcotton> okay, call me +1FE
17:37:43 <adamw> roger
17:39:13 <adamw> proposed #agreed 1934149, 1924284, 1924317, 1924319, 1924321 AcceptedFreezeException (Beta) - we agree that an FE is generally merited if a package fails to install due to the impact on people upgrading from previous stable releases, likely without updates-testing enabled. However, fixes will only be pushed if they involve minimal change and don't seem likely to endanger compose of release-blocking images
17:39:24 <lruzicka[m]> ack
17:39:43 <bcotton> ack
17:40:05 <coremodule> ack
17:40:12 <pwhalen> ack
17:40:44 <adamw> #agreed 1934149, 1924284, 1924317, 1924319, 1924321 AcceptedFreezeException (Beta) - we agree that an FE is generally merited if a package fails to install due to the impact on people upgrading from previous stable releases, likely without updates-testing enabled. However, fixes will only be pushed if they involve minimal change and don't seem likely to endanger compose of release-blocking images
17:40:54 <adamw> #topic (1930567) ESP's "forwarding" grub.cfg doesn't contain $boot FS UUID when it's btrfs
17:41:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930567
17:41:05 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/285
17:41:09 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
17:41:41 <adamw> so AIUI this has effectively the same impact as https://bugzilla.redhat.com/show_bug.cgi?id=1928588 , which was already accepted as an FE
17:41:54 <adamw> there were two issues on the same path, that was the first and it was resolved, but the second still prevents things working
17:41:56 <adamw> is that accurate, cmurf?
17:42:02 <cmurf> in effect we already decided this in a bug where it turns out there were two bugs affecting the same 'stub' grub.cfg on the ESP
17:42:05 <cmurf> so yes
17:42:43 <cmurf> +1 beta fe, but at this point a grub update seems less likely and we'd just common bugs this
17:42:55 <cmurf> although... *sigh* upgrades could be affected
17:42:57 <lruzicka[m]> I think we should have it fixed, so +1 BE
17:43:24 <Eighth_Doctor> +1 Blocker
17:43:25 <cmurf> granted, it affects non-default installations
17:43:51 <adamw> conan: it's FE proposed, not blocker
17:43:57 <adamw> +1 FE for me
17:44:04 <cmurf> i think it's proposed as a final blocker also
17:44:05 <Eighth_Doctor> ah
17:44:10 <Eighth_Doctor> +1 FE then
17:44:23 <pwhalen> +1 FE
17:44:32 <cmurf> i'm still +1 FE
17:45:43 <bcotton> +1 fe
17:47:45 <adamw> rfr
17:47:46 <adamw> rgr
17:48:39 <coremodule> M503
17:48:56 <adamw> proposed #agreed 1930567 - AcceptedFreezeException (Beta) - this is accepted as it has the same effect as 1928588 , which was already accepted. It's a significant installer issue that can't be resolved with an update
17:49:04 <lruzicka[m]> ack
17:49:09 <bcotton> ack
17:49:19 <coremodule> ack
17:49:38 <cmurf> ack
17:49:54 <pwhalen> ack
17:50:16 <adamw> #agreed 1930567 - AcceptedFreezeException (Beta) - this is accepted as it has the same effect as 1928588 , which was already accepted. It's a significant installer issue that can't be resolved with an update
17:50:54 <adamw> #topic (1930401) No update notifications shown when updates available (F34, Rawhide)
17:50:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930401
17:51:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/234
17:51:09 <adamw> #info Proposed Freeze Exceptions, gnome-software, POST
17:51:24 <adamw> so we managed to work out the issues with testing this, and it turned out there was actually a real bug in there
17:51:35 <adamw> so i went ahead and proposed it as a beta fe because fixing that seems like a good idea
17:52:15 <coremodule> +1 FE
17:52:25 <cmurf> +1 FE
17:52:30 <bcotton> +1 FE
17:52:31 <lruzicka[m]> +1FE
17:52:41 <pwhalen> +1 FE
17:56:17 <adamw> proposed #agreed 1930401 - AcceptedFreezeException (Beta) - failing to notify of available updates is a significant issue, it can be fixed with an update but of course...there's a catch-22 there :D
17:56:25 <bcotton> ack
17:56:30 <pwhalen> ack
17:56:38 <lruzicka[m]> ack
17:56:42 <coremodule> ak
17:56:44 <coremodule> ack
17:57:06 <lruzicka[m]> coremodule: alaskan ack is stronger than normal :D
17:57:27 <coremodule> one ak == three ack
17:59:34 <adamw> haha
17:59:36 <adamw> i don't think that's the match
17:59:38 <adamw> math*
17:59:43 <adamw> #agreed 1930401 - AcceptedFreezeException (Beta) - failing to notify of available updates is a significant issue, it can be fixed with an update but of course...there's a catch-22 there :D
17:59:56 <adamw> #info that's all the proposed FEs, moving on to:
18:00:45 <adamw> #topic Proposed Final blockerss
18:00:58 <adamw> ...apparently I'm smeagol
18:01:07 <adamw> #topic (1930567) ESP's "forwarding" grub.cfg doesn't contain $boot FS UUID when it's btrfs
18:01:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930567
18:01:18 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/285
18:01:21 <adamw> #info Proposed Blocker, anaconda, NEW
18:02:31 <cmurf> all i can say is hopefully there's a fix for this because i don't like either of the alternative work arounds
18:02:38 <adamw> same bug we accepted as beta fe, but proposed as final blocker
18:03:04 <cmurf> this falls into the 'if we let the user do it, it's gotta work+boot' category
18:03:07 <adamw> per the criteria this does seem like a pretty clear +1
18:03:42 <pwhalen> +1 final blocker
18:03:48 <lruzicka[m]> +1 FB
18:03:56 <cmurf> i think i voted in the ticket but +1 final blocker
18:04:17 <adamw> sorry, yeah, i haven't been pasting ticket votes, bad me
18:04:18 <adamw> bcotton?
18:04:42 <coremodule> +1 Blocker
18:04:46 <bcotton> +1 blocker
18:07:07 <adamw> proposed #agreed 1930567 - AcceptedBlocker (Final) - this seems like a clear violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" combined with the Basic "installed system must boot" criteria
18:07:16 <lruzicka[m]> ack
18:07:21 <bcotton> ack
18:07:38 <pwhalen> ack
18:07:42 <coremodule> ack
18:08:10 <cmurf> ack
18:08:42 <adamw> #agreed 1930567 - AcceptedBlocker (Final) - this seems like a clear violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" combined with the Basic "installed system must boot" criteria
18:09:01 <adamw> #topic (1930401) No update notifications shown when updates available (F34, Rawhide)
18:09:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930401
18:09:12 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/234
18:09:16 <adamw> #info Proposed Blocker, gnome-software, POST
18:09:21 <adamw> again, same bug, different milestone
18:09:29 <adamw> again seems like a pretty clear violation since there is a real bug, so +1 for me
18:09:40 <lruzicka[m]> +1 FB
18:09:43 <coremodule> +1 blocker
18:10:10 <cmurf> +1 final blocker
18:10:49 <pwhalen> +1 FB
18:13:24 <adamw> proposed #agreed 1930401 - AcceptedBlocker (Final) - since we determined there *is* a bug here preventing notifications from being shown, this is a clear violation of Final criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
18:13:42 <pwhalen> ack
18:13:55 <lruzicka[m]> ack
18:14:11 <coremodule> ack
18:14:43 <adamw> #agreed 1930401 - AcceptedBlocker (Final) - since we determined there is a bug here preventing notifications from being shown, this is a clear violation of Final criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
18:14:51 <adamw> alrighty, and that's all the proposals I had on the list
18:14:54 <adamw> let's check in quickly on:
18:15:01 <adamw> #topic Accepted Beta blockers
18:15:12 <adamw> as a reminder, we aren't voting on this, just checking where we stand with fixing them
18:16:15 <adamw> #topic (1930977) [abrt] gnome-shell: nouveau_fence_signalled(): gnome-shell killed by SIGSEGV
18:16:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930977
18:16:26 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/241
18:16:30 <adamw> #info Accepted Blocker, mesa, ASSIGNED
18:17:28 <cmurf> oh boy
18:19:56 <adamw> basically we have a fix here and are just fighting process wars
18:20:16 <adamw> changing status to POST to reflect that
18:20:30 <adamw> i'll maybe do a scratch build if i can and submit a PR for the package or something, to show what's desired
18:20:54 <adamw> #info there basically is a fix for this, we just need to sort out the Fedora process side of things (maintainer is not clear on what's needed for the package)
18:21:02 <adamw> #action adamw to move 1930977 forward with the packager
18:21:18 <cmurf> ack
18:21:50 <pwhalen> ack (thanks adamw)
18:22:41 <adamw> #topic (1933433) systemd-resolved: stub resolver is not following CNAME for resolution
18:22:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1933433
18:22:53 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/261
18:22:57 <adamw> #info Accepted Blocker, systemd, MODIFIED
18:23:35 <adamw> #info there is an update for this in testing which is generally reported to solve things, a reporter has suggested there's still an issue in the bug, but it doesn't seem to be really the same problem
18:24:39 <cmurf> it's definitely much improved
18:24:43 <cmurf> esp for flatpaks
18:24:55 <cmurf> which means it should be better for all containers but... :D
18:24:58 <cmurf> i don't know that for sure
18:25:02 <adamw> so pretty much we just need to karma+push this (didn't check yet if it's already sufficiently karma'ed)
18:25:40 <cmurf> it's got 3, heading to stable
18:26:27 <cmurf> although it's been in that state for a day, according to bodhi
18:26:29 <adamw> great
18:27:09 <adamw> no, bodhi says it's pending stable.
18:27:21 <adamw> "has been submitted" != "has been pushed"
18:27:37 <adamw> #info update is pending stable, only needs pushing, will happen shortly
18:27:47 <adamw> #topic (1933454) /etc/resolv.conf is not a symlink
18:27:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1933454
18:27:58 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/265
18:28:04 <adamw> #info Accepted Blocker, systemd, NEW
18:28:17 <adamw> so I think this is pretty much a case of "decide what to do and do it", right? iirc there were several possible choices in the bug
18:29:12 <adamw> #info several possible resolutions have been discussed in the bug, we need to pick one and do it
18:30:50 <cmurf> correct
18:31:23 <cmurf> fortunately it's just a problem with Lives
18:31:55 <adamw> #action adamw to poke people to pick and implement a fix for 1933454
18:32:04 <adamw> any other notes?
18:32:32 <lruzicka[m]> in general?
18:32:49 <adamw> no on thsi bug
18:32:50 <adamw> general comes next :)
18:33:01 <lruzicka[m]> so ... not :D
18:33:26 <adamw> #topic Open floor
18:33:33 <adamw> alright, since lruzicka is clearly raring to go :D
18:35:54 <adamw> lruzicka?
18:35:58 <lruzicka[m]> yes
18:36:34 <lruzicka[m]> I wanted to ask, if someone arrived in the following upgrade problem
18:37:01 <lruzicka[m]> a 20210227 version in a VM cannot update due unresolved fedora-cisco-openh264 repo
18:37:14 <lruzicka[m]> when the repo gets disabled, everything runs
18:38:10 <lruzicka[m]> the host can resolve the address and download the packages, but the VM can't
18:38:15 <lruzicka[m]> internet works inside
18:38:30 <adamw> that might be the systemd CNAME bug, possibly
18:39:01 <lruzicka[m]> hmm, interesting I did not hit it on my main desktop (I mean ever)
18:39:07 <cmurf> hmm
18:39:15 <cmurf> i have not hit this in a VM
18:40:08 <lruzicka[m]> it is weird, because neither dnf nor Software can update with the repo enabled and when I copy the package adresses it does not open the page, but I can open google.com without issues.
18:40:30 <lruzicka[m]> This is what I am getting:
18:40:51 <lruzicka[m]> [MIRROR] gstreamer1-plugin-openh264-1.18.2-1.fc34.x86_64.rpm: Curl error (6): Couldn&apos;t resolve host name for http://ciscobinary.openh264.org/gstreamer1-plugin-openh264-1.18.2-1.fc34.x86_64.rpm
18:40:52 <lruzicka[m]> and more
18:41:12 <lruzicka[m]> the link works from my host machine but not from the VM
18:41:24 <adamw> your host is running what?
18:41:46 <lruzicka[m]> my host is running Fedora 34 promtly updated with updates-testing enabled.
18:42:06 <adamw> the record for that host is a CNAME, so that checks out
18:42:27 <adamw> and your host may have the fix or not be using the stub resolver in this case
18:42:39 <adamw> i'd try updating the VM to have the systemd build with the cname fix and see if it works after that
18:42:59 <adamw> and if that doesn't work and the host isn't updated, try updating the Host
18:43:20 <lruzicka[m]> the host has been updated today. I do it every morning.
18:43:29 <lruzicka[m]> But yes, I will give it a try and see.
18:44:46 <adamw> i dunno if the systemd update is actually in -testing yet
18:45:00 <adamw> but yeah i'm gonna guess it's ultimately that issue
18:45:31 <lruzicka[m]> Frantisek also thinks it is
18:45:34 <cmurf> hmm
18:46:04 <cmurf> that does not require enabling 3rd party repos does it?
18:47:38 <lruzicka[m]> is fedora-cisco a third party repo?
18:47:46 <lruzicka[m]> I thought it was enabled by default
18:48:13 <cmurf> looking
18:48:21 <lruzicka[m]> i need two minutes to move to another comp
18:48:25 <adamw> it's effectively a default repo
18:48:42 <adamw> but it's kinda immaterial since the bug is a blocker and we're pulling the fix today, i think. assuming it is that bug and that fix.
18:48:48 <cmurf> looks enabled
18:48:58 <cmurf> i do not have 3rd party stuff enabled
18:49:56 <cmurf> thing is, it's completely skipped on a refresh
18:50:13 <cmurf> oh nvm i'm wrong
18:50:16 <lruzicka> back here
18:50:18 <cmurf> it was skipped without --refresh
18:50:48 <cmurf> https://paste.centos.org/view/9552c3d6
18:51:38 <cmurf> well that's lovely formatting...
18:51:50 <cmurf> i think this is all that should be installed?
18:51:53 <cmurf> https://paste.centos.org/view/334618d0
18:52:09 <lruzicka> And it is the very first repo indeed
18:52:17 <lruzicka> Fedora 34 openh264
18:52:49 <lruzicka> but the name is fedora-cisco-openh264 so it is not a third party repo
18:54:24 <cmurf> i guess that failing url needs dns troubleshooting
18:55:03 <cmurf> maybe do that on #fedora-qa while we have nanonyme around
18:55:05 <lruzicka> I will try to upgrade without the repo and see if that will fix it for later
18:55:22 <cmurf> the rpm is actually not in fedora
18:55:28 <lruzicka> cmurf, now?
18:55:40 <cmurf> look at the url you pasted
18:55:46 <adamw> the repo definition is, though.
18:55:52 <cmurf> the rpm is somewhere else, sounds like resolving that is the problem
18:55:58 <adamw> the repo is maintained by a third party, but we ship the definition for it in fedora-repos.
18:56:07 <cmurf> yeah
18:56:19 <adamw> and yeah, the host it can't resolve is ciscobinary.openh264.org .
18:57:38 <adamw> ok, so i think we're mostly done here
18:57:47 <adamw> we can continue poking at that problem in #fedora-qa i guess
18:57:50 <adamw> so i'm gonna wrap up here
18:57:54 <adamw> thanks for coming, everyone!
19:03:31 <adamw> #endmeeting