16:04:06 <adamw> #startmeeting F30-blocker-review
16:04:06 <zodbot> Meeting started Mon Mar 11 16:04:06 2019 UTC.
16:04:06 <zodbot> This meeting is logged and archived in a public location.
16:04:06 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:06 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:04:06 <adamw> #meetingname F30-blocker-review
16:04:06 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:04:06 <adamw> #topic Roll Call
16:04:14 <adamw> morning folks, who's around for some fun f30 blocker review?
16:04:27 * pwhalen is here
16:04:35 * satellit listening
16:04:35 <coremodule> .hello2
16:04:36 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:04:43 * coremodule willing to secretarialize!
16:04:57 * sgallagh is juggling multiple meetings, but will try to be here
16:05:19 * kalev is here too.
16:06:30 * bcotton is on the road today but should be here for all or most of the meeting
16:07:47 <adamw> thanks coremodule
16:08:02 <lruzicka> .hello2
16:08:03 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:08:08 <frantisekz> .hello2
16:08:09 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:08:18 <mkolman> \o/
16:08:22 * jlanda is around
16:08:59 <adamw> impending boilerplate alert!
16:09:09 <adamw> #topic Introduction
16:09:10 <adamw> Why are we here?
16:09:10 <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.
16:09:10 <adamw> #info We'll be following the process outlined at:
16:09:10 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:11 <adamw> #info The bugs up for review today are available at:
16:09:13 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:15 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:17 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria
16:09:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria
16:09:23 <adamw> #chair coremodule jlanda
16:09:23 <zodbot> Current chairs: adamw coremodule jlanda
16:09:27 <adamw> #info coremodule will secretarialize
16:12:27 <adamw> sorry, had to go out for a sec, back now
16:12:44 <adamw> we have:
16:12:46 <adamw> #info 4 Proposed Blockers (Beta)
16:12:51 <adamw> #info 4 Accepted Blockers (Beta)
16:12:57 <adamw> #info 6 Proposed Freeze Exceptions (Beta)
16:13:11 <adamw> let's get started with the proposed Beta blockers
16:13:19 <adamw> #info starting with proposed Beta blockers
16:13:26 <adamw> #topic (1652806) after move to bls grub can't find blscfg
16:13:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1652806
16:13:26 <adamw> #info Proposed Blocker, grub2, ON_QA
16:14:56 <cmurf> that's new, missed that yesterday when i looked
16:15:02 <jlanda> According to bugzilla it break f30 upgrades, but didn't test on my side
16:15:14 <adamw> this seems like it affects older installs that have been upgraded over time
16:15:20 <cmurf> thatt sounds vaguely familiar...
16:15:28 <jlanda> Over time, prior to f28?
16:15:32 <adamw> i think so
16:15:37 <sgallagh> That seems bad
16:16:00 <sgallagh> Bootloader failures are basically impossible for most humans to repair. +1 blocker
16:16:02 <frantisekz> but.... x86-32 , I am not sure if we want to beta block on that
16:16:03 <adamw> we don't cover this in the criteria - they only require a *clean* install of the n-2 release work
16:16:09 <adamw> (on upgrade)
16:16:27 <cmurf> needinfo
16:16:30 <cmurf> what's the layout
16:16:34 <cmurf> we have no reproduce steps
16:16:37 <sgallagh> Wait, only i686?
16:16:37 <jlanda> There is a proposed grub update, did someone be able to test? :D
16:16:41 <frantisekz> seems so
16:16:45 <sgallagh> Never mind. :-D
16:17:00 <sgallagh> That’s only eligible for FE, then
16:17:03 <frantisekz> "In a x86-32 VM the recent move to bls failed" "I have a similarly configured x86-64 VM and there the bls move worked fine.
16:17:03 <frantisekz> "
16:17:17 <frantisekz> yeah, -1 blocker, +1 fe
16:17:19 <sgallagh> So I’d call it +1 FE, try the fix and go from there
16:17:23 <adamw> let me see what the update actually *does*
16:17:28 <lruzicka> -1 B, +1 FE
16:17:31 <kalev> there's a bunch of dups for this bug, and dups on the duped bugs
16:17:55 <jlanda> -1b +1 fe with the info we have
16:18:07 <adamw> the commit message that claims to fix the bug says:
16:18:10 <adamw> "    Switch to BLS in tools package %post scriptlet
16:18:10 <adamw> 
16:18:10 <adamw> The switch to a BLS configuration was made before in the grubby package
16:18:10 <adamw> %post scriptlet, but this is wrong since it means that a not up-do-date
16:18:12 <adamw> grub2-switch-to-blscfg script could be used to do the switch."
16:18:24 <jlanda> There could be some other case on the dups of the dups of the dups to say something more, but we don't know yet :D
16:18:29 <adamw> yeah
16:18:31 <kalev> aha, so not i686 specific at all
16:18:41 <kalev> (the fix at least)
16:19:25 <cmurf> error: can't find command 'blscfg' is super suspicious that this is some other problem...
16:19:25 <adamw> i'm gonna say +1 FE on the basis that fixing any kind of significant upgrade issue related to the BLS stuff is worthwhile, i think
16:19:32 <cmurf> esp on i686
16:19:35 <adamw> but for blocker status, need more info...
16:19:37 <sgallagh> I’d still call it FE since we have no evidence it hits other arches
16:19:43 <kalev> I agree, let's take this as FE for now and see if it improves things
16:19:46 <pwhalen> definitely +1 FE
16:19:50 <kalev> +1 FE
16:20:30 <bcotton> 0 blocker, +1 FE
16:20:40 <cmurf> I concur with +1 FE but not because of this bug, best to have current grub2 and grubby in the beta
16:20:55 * kalev nods.
16:21:00 <adamw> proposed #agreed 1652806 - AcceptedFreezeException (Beta) - there's some uncertainty around precisely what bug(s) the reporter here has, and in what configuration they appear, versus what the claimed fix in the package actually does. But we at least agree that it seems worth taking as an FE, and will ask Javier for more details in the bug
16:21:00 <jlanda> We can always revisit it if new info appears
16:21:09 <pwhalen> ack
16:21:11 <frantisekz> ack
16:21:14 <lruzicka> ack
16:21:15 <jlanda> ack
16:21:23 <bcotton> ack
16:21:24 <kalev> ack
16:21:29 <adamw> #agreed 1652806 - AcceptedFreezeException (Beta) - there's some uncertainty around precisely what bug(s) the reporter here has, and in what configuration they appear, versus what the claimed fix in the package actually does. But we at least agree that it seems worth taking as an FE, and will ask Javier for more details in the bug
16:21:36 <adamw> #topic (1685992) Network spoke doesn't appear on ARM initial-setup
16:21:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1685992
16:21:37 <adamw> #info Proposed Blocker, initial-setup, POST
16:22:01 <cmurf> yep i'd say that's a problem
16:22:08 <cmurf> TUI only?
16:22:14 <pwhalen> yes
16:22:21 <pwhalen> tested graphical and it comes up there
16:22:49 <bcotton> +1 blocker
16:22:54 <lruzicka> +1 blocker
16:22:55 <frantisekz> +1 blocker
16:22:59 <kalev> +1 blocker
16:23:02 <lruzicka> seems they will fix it soon anyway
16:23:07 <pwhalen> +1 here as well
16:23:08 <coremodule> +1 blocker
16:23:20 <cmurf> +1 blocker
16:24:03 <sgallagh> +1 blocker
16:24:17 <adamw> what's the criterion?
16:24:41 <adamw> neither of the ones cited in the bug report works, for me
16:24:43 <adamw> the install completed
16:24:45 <pwhalen> I wasnt sure if we had something that covered it
16:24:55 <adamw> you can presumably configure the network at the console
16:25:01 <sgallagh> Basic server functionality?
16:25:04 <cmurf> lol +7 blocker votes and no criterion, oops
16:25:04 <adamw> the network spoke in i-s is more of a convenience, isn't it?
16:25:06 * sgallagh runs
16:25:24 <pwhalen> adamw, I dont really use it myself
16:25:25 <adamw> or is there some circumstance in which it's vital to be able to configure the network in i-s?
16:25:42 <lruzicka> there is one: Remote package sources
16:25:48 <adamw> this is initial-setup, not install
16:26:01 <sgallagh> adamw: on ARM, there is no install
16:26:03 <adamw> there is no anaconda install step for the relevant images here, they are disk images
16:26:06 <adamw> sgallagh: exactly
16:26:08 <sgallagh> This is your first chance
16:26:08 <lruzicka> the installar must be able to pull sources over network, which, without network setup, will hardly do
16:26:20 <adamw> the network spoke is vital for doing a network install, but this is not the scenario we're dealing with here
16:26:24 <adamw> lruzicka: there is no installer in this case.
16:26:31 <sgallagh> Hmm
16:26:53 <sgallagh> adamw: Can’t pull updates after a default install?
16:26:56 <cmurf> ok so revote +1 FE
16:26:58 <lruzicka> adamw, I do not understand then ... :(
16:27:00 <cmurf> same outcome
16:27:12 <adamw> lruzicka: for ARM we publish disk image files
16:27:15 <adamw> that's what this bug is about
16:27:26 <adamw> to 'install' them you basically dd them onto an sd card and boot the system from it
16:27:32 <frantisekz> I was assuming it cannot be skipped.... my bad then, so +1 FE it is
16:27:37 <adamw> at that point, initial-setup runs, so you can set up a root password
16:27:46 <lruzicka> adamw, aah, ok.
16:27:46 <adamw> or user password, and log into the system
16:27:59 <adamw> it also shows some other spokes, including i think network and date/time
16:28:24 <adamw> but those are really for convenience, the only truly *vital* part of i-s in this scenario is being able to set at least an admin user or a root password
16:28:26 <lruzicka> so I can go to the console and set up networking just fine?
16:28:33 <sgallagh> Okay, I guess I can see my way to not calling this a blocker. +1 FE
16:28:33 <adamw> as i understand this bug, yes
16:28:38 <adamw> pwhalen: am i wrong about anything there?
16:28:44 <pwhalen> yea, I'm ok with FE as well, I wasnt sure what it violated and dont think the spoke is widely used
16:29:09 <adamw> so, yeah, i'm -1 blocker +1 FE.
16:29:10 <pwhalen> adamw, nothing wrong I can see
16:29:14 <adamw> anyone else want to revote?
16:29:20 <jlanda> -1b +1 fe here too
16:29:30 <lruzicka> ok, +1 fe
16:29:31 <bcotton> okay -1b +1fe
16:29:33 <pwhalen> same, +1 FE..
16:29:56 <jlanda> And arm audience uses to be more powerussr than amd64, they'll manage to run a console and a command
16:31:50 <adamw> i mean, in most cases the network is just gonna work anyway
16:31:52 <adamw> dhcp is automatic
16:32:32 <pwhalen> right, I can only see it being needed for wireless. which can be done after boot
16:32:41 <adamw> #topic 1685992 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - the network spoke is more a convenience than a vital feature of i-s in this workflow, and there is no criterion requiring it to be present or work. however, this is obviously a significant bug that cannot be fixed with an update
16:33:02 <pwhalen> ack
16:33:06 <coremodule> ack
16:33:11 <jlanda> ack
16:33:14 <lruzicka> ack
16:33:25 <kalev> ack
16:33:25 <frantisekz> topic? adamw, you are destroying the logs!!! :D
16:33:35 <adamw> d'ooohhh
16:33:37 <adamw> #undo
16:33:37 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f5543f46950>
16:33:39 <jlanda> lol
16:33:49 <adamw> proposed #accepted 1685992 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - the network spoke is more a convenience than a vital feature of i-s in this workflow, and there is no criterion requiring it to be present or work. however, this is obviously a significant bug that cannot be fixed with an update
16:33:56 <frantisekz> ack
16:34:11 <cmurf> ack
16:34:11 <lruzicka> ack
16:34:11 <bcotton> ack
16:34:13 <coremodule> ack
16:34:14 <pwhalen> ack
16:34:15 <kalev> ack
16:34:39 <adamw> #accepted 1685992 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - the network spoke is more a convenience than a vital feature of i-s in this workflow, and there is no criterion requiring it to be present or work. however, this is obviously a significant bug that cannot be fixed with an update
16:34:48 <adamw> #topic (1686636) podman cannot be installed due to dependency on conmon (subpackage of retired / moved to module cri-o)
16:34:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1686636
16:34:49 <adamw> #info Proposed Blocker, podman, NEW
16:35:10 <cmurf> since this is ultimately a 'whatever adamw says, goes' meeting, +1 blocker even though he didn't specify a criterion
16:35:21 <adamw> haha it is not that
16:35:29 <cmurf> haha
16:35:33 <adamw> the proposal comes in with the dupe
16:35:45 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1686926
16:35:48 <cmurf> ahh ok but still it's a funny
16:36:00 <adamw> "The arm/aarch64 server disk images are failing due to missing conmon in the server compose."
16:36:02 <jlanda> Do we block on container runtime workflows?
16:36:10 <adamw> we block on release-blocking images being available.
16:36:21 <sgallagh> Right, isn’t this one automatic?
16:36:29 <pwhalen> right, +1 for me
16:36:32 <adamw> point...
16:36:36 <adamw> but since we're here anyway!
16:36:45 <bcotton> +1
16:36:50 <sgallagh> -1 since it’s being overruled!
16:36:52 <frantisekz> +1
16:36:53 <sgallagh> :-P
16:36:55 <adamw> actually, let's just go with automatic since it's faster
16:37:04 <pwhalen> I think the compose will fail on the aarch64 disk image
16:37:19 <adamw> well, actually, that causes one question for me
16:37:22 <adamw> how did we get a rawhide compose?
16:37:24 * adamw looks
16:37:44 <pwhalen> good point
16:38:46 <pwhalen> but I think someone mentioned it was fixed in rawhide?
16:38:47 <adamw> aha
16:39:06 <adamw> we're talking about https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190310.n.2/compose/Server/aarch64/images/Fedora-Server-Rawhide-20190310.n.2.aarch64.raw.xz , right?
16:39:14 <adamw> in that case i think it is not actually set to fail the compose
16:39:16 <pwhalen> right, saw that
16:39:30 <adamw> as 20190306.n.1 compose completed, but:
16:39:30 <adamw> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190306.n.1/compose/Server/aarch64/
16:39:34 <adamw> that directory is not in it at all
16:39:39 <adamw> there is no aarch64/images/
16:39:52 <adamw> so, that'd explain how we got that compose.
16:40:11 <adamw> ditto 32-bit
16:40:22 <adamw> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190310.n.2/compose/Server/armhfp/images/ exists , doesn't exist for 0306.n.1.
16:40:41 <kalev> is it supposed to be a blocking image?
16:40:55 <sgallagh> Yes
16:40:57 <adamw> #info sgallagh correctly points out that this should have been an automatic blocker, as it prevents the build of release-blocking images, the Server disk images for aarch64 and armhfp
16:41:14 <adamw> #info we will mark it as an accepted blocker and move on
16:41:18 <jlanda> server and xfce if i remember correctly kalev
16:41:20 <pwhalen> kalev, aarch64 is release blocking
16:41:31 <kalev> fair enough :)
16:41:36 <pwhalen> not armhfp. armhfp is minimal/xfce
16:42:45 <adamw> sgallagh: i think it may be time to break out the pointed sticks on this one?
16:43:21 <cmurf> toothpicks?
16:43:48 <sgallagh> adamw: Haven’t you heard? We found some bronze! We’ve got real spearheads now!
16:44:06 * cmurf is a fan of the halberd, personally
16:44:07 <adamw> i don't think the rawhide 'fix' was actually a fix at all, btw
16:44:14 <adamw> i think dwalsh got the wrong end of the (pointed?) stick entirely
16:44:19 <adamw> but i will follow up on that outside of the meeting
16:45:03 <adamw> or, humm, i may be wrong
16:45:03 <adamw> anyway
16:45:05 <adamw> next bug!
16:45:16 <adamw> #topic (1686919) Issues with cloud/iot images due to not being able to specify msdos partitions when underlying host is booted with  UEFI
16:45:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1686919
16:45:16 <adamw> #info Proposed Blocker, python-blivet, ON_QA
16:45:26 <cmurf> every take a shot of whiskey on this one...
16:46:12 <cmurf> s/every/everyone
16:46:22 <cmurf> so cloud is blocking i think
16:46:36 <cmurf> i couldn't find an f30 version of this https://fedoraproject.org/wiki/Releases/29/ReleaseBlocking
16:47:42 <cmurf> the cloud images need to be UEFI/BIOS hybrid with an MBR, i.e. block on this bug
16:47:56 <cmurf> if we don't block, then that'd presumably mean they can'd do the hybrid image feature
16:49:07 <cmurf> but it's an approved feature, right? so I think we block on something basic like, the image has to boot *shrug*
16:49:45 <bcotton> s$^#, i missed that task on the schedule. i'll start that process today (and then propose a more streamlined approach in the future)
16:50:17 <adamw> what's an approved feature?
16:51:27 <adamw> i'm still honestly not clear on precisely what is going on here
16:51:29 <cmurf> adamw: HUH you're right I can't find it
16:51:52 <adamw> pbrobinson refers to "default change from msdos to GPT when booting as UEFI" but there was no "change", we have *always* defaulted to GPT for UEFI installs
16:51:56 <jlanda> Release blocking cloud images must be able to automatically utilize all available space on a supported volume.  Well, if it can boot it can grow to use all the available space lol
16:52:16 <pwhalen> I think the aws images are currently broken
16:52:20 <adamw> was there a change in AWS here, or something?
16:52:28 <cmurf> yeah so with GPT images, AWS won't boot
16:52:37 <adamw> i am just trying to understand why there is suddenly a problem here when we did not change anything
16:52:39 <lruzicka> adamw, I think he means that AWS does not support GPT and therefore our images cannot boot there
16:52:51 <adamw> did AWS suddenly go from using BIOS to UEFI mode or something?
16:52:58 <cmurf> AWS will accept only Windows UEFI/GPT images because it automatically converts them on the fly to BIOS/MBR - they don't support UEFI or secure boot yet
16:53:02 <adamw> lruzicka: but why is this suddenly a problem now?
16:53:10 <adamw> we have *always* used GPT for UEFI installs. this is not something new
16:53:17 <jlanda> adamw: the bug talks about "now that releng can build secure boot images" but no idea what are they talking about
16:53:19 <adamw> if that is a problem now why wasn't it a problem for F28 or F29?
16:53:20 <cmurf> this is not an install
16:53:23 <cmurf> this ia another image
16:53:24 <adamw> i know that
16:53:32 <adamw> but what image are we talking about exactly
16:53:36 <cmurf> but the images have always been MBR to date
16:53:45 <jlanda> Yeah, that's the question
16:53:45 <cmurf> so they switched to UEFI/GPT but now the images fail in AWS
16:53:56 <adamw> okay, that would explain it, if it's the case
16:54:06 <adamw> do you have a commit link or anything handy?
16:54:11 <cmurf> sorry: more correctly, they were doing BIOS+UEFI hybrid images with a GPT
16:54:18 <jlanda> M, could we punt and talk to releng/whoever to get some info?
16:54:30 <cmurf> they want to do a BIOS+UEFI with an MBR to get around the AWS issue
16:54:36 <cmurf> but here's the thing
16:54:37 <adamw> ah, the 'releng ticket' has something...
16:54:37 <adamw> https://pagure.io/releng/issue/8197
16:54:39 <cmurf> no feature
16:54:52 <cmurf> if it's not an approved feature what's the basis for blocking?
16:55:25 <jlanda> But AH has not be branched to fc30 and will EOL with f29 EOL...
16:55:35 <jlanda> Or i miss read something...
16:56:15 <cmurf> oh god now i'm confused
16:56:35 <adamw> i note "https://pagure.io/releng/issue/8197#comment-559107"
16:56:37 <adamw> grr
16:56:40 <adamw> i note https://pagure.io/releng/issue/8197#comment-559107
16:56:47 <adamw> "@pbrobinson - any chance you could verify that the proposed change gives us a disk image that we can then upload to EC2 and boot? If we could get that data point now then we'll save a bunch of time and process if it doesn't work and we need to change the strategy."
16:56:50 <adamw> "Working on it"
16:56:56 <adamw> so...this hasn't actually been tested yet
16:58:37 <cmurf> i don't know if anaconda even has code for MBR on UEFI
16:58:56 <jlanda> cloud are images like arm
16:59:02 <jlanda> No install process
16:59:11 <jlanda> But does this affect other cloud images?
16:59:24 <jlanda> Or just AH?
16:59:50 <lruzicka> cmurf, probinson believes that it is an 8 character bug: https://pagure.io/releng/issue/8197#comment-558841
16:59:58 <adamw> cmurf: there isn't really "code" required, it's just a case of allowing it.
17:00:02 <cmurf> jlanda: it's a good question I think all x86_64 images
17:00:05 <adamw> i would still like to see it tested, though.
17:00:21 <adamw> i think the change affects any cloud-type image.
17:00:25 <pwhalen> adamw, iiuc hes done some testing on it
17:00:45 <lruzicka> without the AWS cloud, we cannot test it by ourselves, can we?
17:01:00 <jlanda> we can't block f30 based on a AH bug since AH will eol with fc29
17:01:24 <jlanda> so we must know if this affect all the cloud images or just AH
17:01:38 <lruzicka> jlanda, will that not be an issue with Core OS?
17:01:54 <jlanda> But fc-coreos is not blocker for fc30
17:02:05 <cmurf> I think this can be an FE
17:02:15 <cmurf> i'm unconvinced it can be a blocker
17:02:39 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1686919#c10 is my explanation
17:03:41 <adamw> jlanda: https://github.com/clalancette/oz/pull/269/files
17:03:43 <adamw> line 486
17:04:06 <adamw> with my current understanding, i would say there is clearly a blocker bug here
17:04:18 <adamw> "release-blocking cloud-type images do not boot in EC2" is a blocker bug
17:04:46 <adamw> however, i'd say either of the two possible resolutions i mentioned in my comment is a valid solution, and if we can't get UEFI-on-MBR to work PDQ we should just go back to BIOS-on-MBR for F30.
17:04:52 <adamw> with that caveat, i'm +1 blocker
17:04:56 <jlanda> yeah, there seems that they changed all the images, so then we have a broken release-blocking image
17:05:25 <jlanda> +1 b, in case they can't fix it we can always rever that commit and go
17:05:54 <cmurf> well if it's a PDQ or revert, I'm a strong +1 FE for sure
17:06:09 <cmurf> but i'm skeptical of saying now we'd block on something we'd also revert
17:06:09 <lruzicka> I am +1 blocker on this, but which of the two solutions will be applied does not matter to me, really.
17:06:27 <pwhalen> +1 blocker
17:06:36 <adamw> cmurf: but the fact that the images don't boot is a blocker
17:06:39 <jlanda> cmurf: we block on non usable image. Reverting is one solution
17:06:48 <adamw> if we don't accept something as a blocker to represent that, we can wind up shipping broken images
17:06:52 <cmurf> gotcha
17:06:55 <lruzicka> cmurf, we block because the images do not work, they will fix it somehow
17:07:01 <cmurf> +1 blocker
17:07:02 <cmurf> makes sense
17:07:36 <sgallagh> +1 blocker
17:09:09 <adamw> proposed #agreed 1686919 - AcceptedBlocker (Beta) - we accept this bug as a blocker as a violation of basic criterion "...Release-blocking cloud images must boot in the Fedora OpenStack Cloud and in Amazon EC2." to be clear, we block on the images not booting: if UEFI-on-MBR cannot be made to work, reverting to BIOS-on-MBR would also resolve the blocker.
17:09:20 <jlanda> ack
17:09:48 <pwhalen> ack
17:09:49 <frantisekz> ack
17:09:52 <lruzicka> ack
17:09:52 <kalev> ack
17:09:55 <cmurf> ack
17:10:57 <adamw> #agreed 1686919 - AcceptedBlocker (Beta) - we accept this bug as a blocker as a violation of basic criterion "...Release-blocking cloud images must boot in the Fedora OpenStack Cloud and in Amazon EC2." to be clear, we block on the images not booting: if UEFI-on-MBR cannot be made to work, reverting to BIOS-on-MBR would also resolve the blocker.
17:12:51 <adamw> #topic Proposed Beta freeze exceptions
17:12:58 <adamw> #info we now move on to proposed Beta freeze exceptions
17:13:20 <adamw> meta note: for anyone who wondered why i started doing topics like that recently - it makes the separations between the different groups of bugs much clearer in the meeting minutes
17:13:36 <adamw> #topic (1678453) Firefox Wayland By Default On Gnome
17:13:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1678453
17:13:36 <adamw> #info Proposed Freeze Exceptions, Changes Tracking, MODIFIED
17:14:18 <contyk> so FESCo would like FE+ here
17:14:36 <cmurf> +1FE, I've been testing this for awhile on F29, which curiously has newer FF for some time now than F30
17:15:42 <adamw> compose issues.
17:15:44 <cmurf> The thing is, FF 66 isn't due until 3/19 so that doesn't realistically seem like much testing time for it before a go no go
17:16:11 <adamw> "For the final decision I'd like to point out a GS bug [1] which affects window screenshots, animations and screencasting of FF on Wayland."
17:16:15 <adamw> that worries me a bit.
17:16:22 <adamw> taking a screenshot of the browser seems like a pretty common thing to do.
17:16:26 <adamw> (hell, i do it quite a lot.)
17:16:52 <cmurf> gnome-screenshot is affected or built-in firefox screenshot? or both?
17:17:20 <adamw> https://gitlab.gnome.org/GNOME/mutter/issues/146#note_403457
17:17:28 <adamw> cmurf: i'm guessing gnome-screenshot
17:17:35 <adamw> but i had no idea firefox has its own screenshot system
17:17:40 <adamw> and i'm gonna guess neither did most people?
17:17:47 <cmurf> :P
17:17:49 <cmurf> i use it often
17:17:54 <adamw> i think to most people, 'screenshot' and 'press printscreen' are basically the same thing...
17:18:09 <cmurf> puts your screenshot in the cloud, just copy paste the URL, sorta like fpaste except for screenshots
17:18:26 <cmurf> 7 day expiration, something like that
17:18:45 <lruzicka> cmurf, seems interesting, how do I use it?
17:19:12 <cmurf> lruzicka: go to the three dots to the right of URL, choose screenshot option
17:19:22 <lruzicka> cmurf, Yeah, thanks.
17:19:27 <lruzicka> cmurf, I can see it now.
17:19:35 <adamw> so, anyhow
17:19:41 <adamw> on the one hand, 'fesco wants this' is strong
17:19:53 <adamw> on the other hand, 'we know it breaks stuff and it's not going to be ready for 8 days' is also strong...
17:19:59 <cmurf> right
17:20:14 <cmurf> but FE doesn't mean it's accepted blinding, it means a tested fix is accepted
17:20:21 <cmurf> so it has to be tested or it's reverted
17:20:26 <contyk> well, if it's reasonable :) if it's broken, it's not
17:20:35 <bcotton> if it weren't such a prominent and widely-used package, i'd say just wait until the beta thaw, but...
17:20:43 <adamw> was fesco aware of the gnome-shell issue when it talked about tihs?
17:21:10 <adamw> sgallagh: ?
17:21:11 <contyk> no, we just said we'd like to have this but we'll follow the standard fe/blocker review process
17:21:14 <adamw> ah, thanks
17:21:24 <cmurf> ffwayland bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=1054334
17:21:43 <jlanda> Take screenshot is basic functionality of screenshot app
17:21:48 <adamw> in a sense, the question of whether the gnome-shell problem is serious enough to kick this out isn't really a "FE vs. not-FE" question
17:21:53 <jlanda> Installed by default, so blocker
17:22:02 <jlanda> Fun fact :D
17:22:20 <adamw> it wouldn't make any sense to say "well we're not going to put this in the Beta because of the gnome-shell bug, but we're fine landing it right after Beta is released", which would be the implict meaning of a no-FE decision
17:22:35 <adamw> jlanda: not necessarily, because it can take screenshots of everything *else*
17:22:35 <cmurf> adamw: true so you think it's actually a blocker because if we have a busted firefox, we'd block until we get a compose with a revert to ff on xwayland?
17:22:42 <adamw> and the gnome-screenshot app itself is basically working
17:23:11 <adamw> cmurf: nah, i think i'm more saying 'i'd like to know if fesco still thinks we should put ff-on-wayland in f30 *at all* if we can't get this gnome-shell bug fixed'
17:23:23 <kalev> the gnome-screenshot app is just a tiny wrapper around gnome-shell screenshotting API
17:23:24 <adamw> i don't have a sense for whether they'd think it's serious enough to delay the Change entirely
17:23:51 <adamw> so,....hum
17:23:56 <adamw> i think my vote might be conditional +1 FE
17:24:07 <jlanda> conditional on?
17:24:22 <adamw> as in, we ask fesco if they still want this in F30 given the gnome-shell bug and the relatively late date ff66 will be showing up
17:24:26 <adamw> if they do, then we should give it an FE
17:24:37 <lruzicka> that seems reasonable
17:25:02 <adamw> so, accept it as an FE, but file a fesco issue and note we're monitoring that
17:25:13 <contyk> sounds good
17:25:20 <cmurf> i'll vote for that
17:25:20 <jlanda> fine for me
17:25:30 <jlanda> +1 adam's fe
17:25:36 <bcotton> +1 to adam's fe proposal
17:25:55 <frantisekz> +1 for whatever adam says..... :D
17:26:10 <pwhalen> +1 to adam
17:26:17 <lruzicka> +1 adamized FE
17:26:22 <jlanda> until we hit a keyboard and i18n then
17:26:23 <pwhalen> heh :)
17:26:32 <jlanda> s/then/issue
17:26:32 <contyk> jlanda ;)
17:26:46 <adamw> proposed #agreed 1678453 - AcceptedFreezeException (Beta) - we are concerned about the gnome-shell issue and the late ff66 release date here, but it makes no sense to deny an FE for those reasons but take the Change post-Beta. so we grant it an FE, but will ask FESCo if it still thinks the Change should land in F30 at all given those considerations
17:27:02 <contyk> ack
17:27:04 <frantisekz> ack
17:27:05 <cmurf> ack
17:27:07 <jlanda> ack
17:27:08 <pwhalen> ack
17:27:08 <lruzicka> ack
17:27:08 <bcotton> ack
17:27:15 <adamw> #agreed 1678453 - AcceptedFreezeException (Beta) - we are concerned about the gnome-shell issue and the late ff66 release date here, but it makes no sense to deny an FE for those reasons but take the Change post-Beta. so we grant it an FE, but will ask FESCo if it still thinks the Change should land in F30 at all given those considerations
17:27:30 <adamw> #topic (1674809) digikam: FTBFS in Fedora rawhide/f30
17:27:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1674809
17:27:30 <adamw> #info Proposed Freeze Exceptions, digikam, ON_QA
17:27:34 <jlanda> gtg, I'll read later
17:27:39 <adamw> thanks jlanda
17:28:18 <frantisekz> so, I think we can let those FTBFS fixes in.... I mean, is it going to hurt anything at this point?
17:29:01 <adamw> well
17:29:14 <adamw> this actually is a new release of digikam
17:29:21 <frantisekz> hmm
17:29:39 <adamw> what's in f30 stable right now is digikam-5.9.0-2.fc29
17:29:52 <adamw> it would be useful to know if that's outright broken or non-installable
17:30:06 <adamw> if it is, i might be inclined to give 6.0.0 an FE, but otherwise it seems questionable
17:30:10 <frantisekz> yeah... that makes sense to find out
17:31:09 <frantisekz> but.... dnf install digikam is like.... Installed size: 1.0 G -_-
17:31:21 <adamw> yeah, you'd want to test on a kde install anyhow
17:31:24 <adamw> i'm asking rdieter right now
17:31:33 <lruzicka> I am installing it.
17:34:04 <adamw> "5.9.0 is uninstallable due to broken dependencies"
17:34:06 <adamw> says rdieter
17:34:12 <adamw> so on that basis, +1 FE, as we can't really make it worse. =)
17:34:32 <frantisekz> yep.... +1 FE in that case
17:34:46 <pwhalen> +1 FE
17:34:52 <lruzicka> The 6.0 seems ok
17:34:56 <kalev> +1 FE
17:35:10 <lruzicka> +1 FE
17:35:25 <cmurf> +1 FE
17:36:26 <adamw> proposed #agreed 1674809 - AcceptedFreezeException (Beta) - on the grounds that the existing package cannot be installed due to broken dependencies, we accept this as an FE (fixing broken dependencies in the stable package set is usually a good idea)
17:36:39 <lruzicka> ack
17:36:55 <kalev> ack
17:37:31 <pwhalen> ack
17:37:43 <frantisekz> ack
17:37:43 <adamw> #agreed 1674809 - AcceptedFreezeException (Beta) - on the grounds that the existing package cannot be installed due to broken dependencies, we accept this as an FE (fixing broken dependencies in the stable package set is usually a good idea)
17:37:51 <frantisekz> no late ack, yay :D
17:37:51 <adamw> #topic (1685939) Include GNOME 3.31.92 in Fedora 30 Beta
17:37:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1685939
17:37:52 <adamw> #info Proposed Freeze Exceptions, distribution, ON_QA
17:38:16 <adamw> so, this is the 'latest GNOME 3.32 pre-release megaupdate' fe
17:38:23 <frantisekz> +1 FE, assuming there is a fix for the mutter bug
17:38:25 <adamw> it's testing out fine so far
17:38:39 <adamw> note openqa now tests build+install of a live image including the update, so we know that works (on x86_64 anyway)
17:38:40 <cmurf> +1 FE
17:38:45 <adamw> yes, the color bug is fixed
17:38:50 <frantisekz> also, isn't gnome 3.32 final going to be released this week :) ?
17:38:54 <lruzicka> +1 FE
17:39:13 <kalev> frantisekz: yep, I just filed another FE for 3.32 final
17:39:21 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1687549
17:39:38 <adamw> still probably a good idea to consider them separately
17:39:39 <frantisekz> okay :D
17:39:46 <adamw> so i'm +1 FE on this with the testing
17:39:58 <frantisekz> yeah, in case something breaks, +1 FE for me then
17:40:07 <kalev> my plan here is to push 3.31.92 to stable today, if it gets FE accepted, and then do bodhi testing for 3.32 final separately and see how it goes
17:40:29 <kalev> and maybe accept a conditional FE based on the testing outcome for 3.32.0 today
17:40:36 <adamw> proposed #agreed 1685939 - AcceptedFreezeException (Beta) - as usual, we're generally inclined to accept FEs for newer pre-releases of the GNOME version we want to include in the final release. We still have some time till Beta release, and this has tested out well in manual and automated testing so far
17:40:44 <frantisekz> ack
17:40:46 <kalev> ack
17:42:03 <lruzicka> ack
17:42:14 <kalev> sorry for filing so many FE's, but that's probably the best we can do, given how the schedules align this cycle
17:43:00 <frantisekz> thanks for doing that kalev... i think it's the best way
17:43:05 <frantisekz> kalev++
17:43:05 <zodbot> frantisekz: Karma for kalev changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:44:36 <adamw> #agreed 1685939 - AcceptedFreezeException (Beta) - as usual, we're generally inclined to accept FEs for newer pre-releases of the GNOME version we want to include in the final release. We still have some time till Beta release, and this has tested out well in manual and automated testing so far
17:44:45 <adamw> #topic (1652806) after move to bls grub can't find blscfg
17:44:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1652806
17:44:46 <adamw> #info Proposed Freeze Exceptions, grub2, ON_QA
17:45:08 <adamw> oh, same one from earlier
17:45:17 <adamw> #info we accepted this as an FE during blocker review
17:45:20 <kalev> adamw: can you refresh the irc template at some point so it shows the 3.32.0 FE I just submitted?
17:45:24 <adamw> #topic (1687085) bootloader crashes early when it is compiled with gcc9
17:45:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1687085
17:45:24 <adamw> #info Proposed Freeze Exceptions, s390utils, ON_QA
17:45:34 <adamw> kalev: technically i can't, no - it's on a 30 minute cycle
17:45:43 <kalev> it just refreshed, I can see it there
17:45:50 <adamw> sure, i'll include it at the end
17:45:52 <kalev> thanks
17:46:13 <frantisekz> It can be refreshed manually if we need it at some point in the future </note>
17:48:23 * adamw not sure if he has the right privileges to do it
17:48:40 <adamw> so uh anyway, this bug
17:48:51 <adamw> breaks non-blocking arch, seems like a clear FE
17:48:54 <adamw> +1
17:48:59 <kalev> +1 FE
17:49:00 <frantisekz> +1 FE
17:49:07 <lruzicka> +1 FE
17:49:18 <pwhalen> +1 FE
17:51:13 <adamw> proposed #agreed 1687085 - AcceptedFreezeException (Beta) - this prevents all installs from booting on a non-blocking arch (s390), obviously a clear freeze exception
17:51:18 <frantisekz> ack
17:51:31 <lruzicka> ack
17:51:36 <kalev> ack
17:51:44 <pwhalen> ack
17:51:58 <adamw> #agreed 1687085 - AcceptedFreezeException (Beta) - this prevents all installs from booting on a non-blocking arch (s390), obviously a clear freeze exception
17:52:07 <adamw> #topic (1686053) Bump GNOME screen cast API compatibility
17:52:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1686053
17:52:07 <adamw> #info Proposed Freeze Exceptions, xdg-desktop-portal-gtk, ON_QA
17:53:07 <kalev> jadahl said it's needed for screencasting to work with the GNOME we have in stable, that's all I know :)
17:54:05 <kalev> I don't think it's super important for Beta to work, but seems like a nice to have thing
17:54:10 <frantisekz> +1 FE then, if it doesn't work now, it can't be worse
17:54:14 <adamw> seems simple enough
17:55:03 <lruzicka> nice to have .... +1 FE
17:56:38 <adamw> proposed #agreed 1686053 - AcceptedFreezeException (Beta) - this doesn't seem like a deal-breaking feature, but the risk seems equally low and the issue can't be fixed for live images with an update, so accepted as an FE
17:56:40 <pwhalen> +1 FE
17:56:43 <pwhalen> ack
17:56:47 <kalev> ack
17:56:55 <lruzicka> ack
17:57:06 <frantisekz> ack
17:57:57 <adamw> #agreed 1686053 - AcceptedFreezeException (Beta) - this doesn't seem like a deal-breaking feature, but the risk seems equally low and the issue can't be fixed for live images with an update, so accepted as an FE
17:58:18 <adamw> #topic (1687549) Include GNOME 3.32.0 in Fedora 30 Beta
17:58:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1687549
17:58:19 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
17:58:26 <adamw> so, here's the 3.32.0 final one
17:58:52 <frantisekz> +1 FE ... if it isn't going to break everything and eat your dog or cat....
17:59:05 <adamw> if the changes are minor, provisional +1 FE (let's pull it in if the tests pass)
17:59:32 * kalev agrees.
18:00:00 <lruzicka> +1 FE
18:00:15 <pwhalen> +1 FE
18:02:41 <jlanda> +1 FE
18:03:34 <adamw> proposed #agreed 1687549 - AcceptedFreezeException (Beta) - this is accepted on the same reasoning as the 3.31.92 FE. As there is no update yet, of course this can only be pushed if it lands in reasonable time and no major issues appear in manual or automated testing
18:03:42 <frantisekz> ack
18:03:44 <kalev> ack
18:03:47 <jlanda> ack
18:04:46 <pwhalen> ack
18:04:47 <adamw> #agreed 1687549 - AcceptedFreezeException (Beta) - this is accepted on the same reasoning as the 3.31.92 FE. As there is no update yet, of course this can only be pushed if it lands in reasonable time and no major issues appear in manual or automated testing
18:04:57 <adamw> we also have one more newly-arrived proposed FE
18:05:03 <adamw> #topic (1687508) F30-beta-FE for setup-2.13.2-1.fc30
18:05:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1687508
18:05:03 <adamw> #info Proposed Freeze Exceptions, setup, NEW
18:05:36 <adamw> so, slightly late Change component...
18:06:41 <adamw> there seem to be three changes
18:06:42 <adamw> https://pagure.io/setup/c/3553a1ae48c7b6e38f6599e45e88d6457c225876?branch=master
18:06:49 <adamw> https://pagure.io/setup/c/fef4c093aec7adef9a2ced5b374a3c3354901e10?branch=master
18:06:55 <adamw> https://pagure.io/setup/c/96eb9d6aae09e6207c611a02ab26413f3cd9ff18?branch=master
18:07:33 <adamw> i'm always a *bit* worried by things that fiddle around with critical bits of shell script...
18:08:02 <adamw> we're still 15 days from beta release, though, so i think i'm okay with this.
18:08:15 <frantisekz> yeah... but, it's going to land in F30 anyway, I think it's better to break now, than later
18:09:33 <adamw> so, reluctant +1, i guess
18:09:45 <pwhalen> +1 FE
18:09:50 <frantisekz> (is it +0.99 then? :D )
18:09:52 <frantisekz> +1 FE
18:10:16 <lruzicka> +1 FE
18:11:11 <cmurf> +0.51 FE
18:11:41 <adamw> +0.73
18:11:45 <adamw> ...ish
18:11:51 <cmurf> (pretty sure in ancient times adamw said only integer FE's were allowed)
18:12:06 <adamw> you never want to trust anything that guy says
18:12:06 <lruzicka> it still can be rounded :)
18:12:16 <cmurf> that's what i'm counting on
18:12:33 <adamw> proposed #agreed 1687508 - AcceptedFreezeException (Beta) - we're a bit reluctant to fiddle around with critical shell script in a freeze, but as this relates to a Change and there's still a couple of weeks to release, we're willing to take the risk
18:12:50 <frantisekz> ack
18:13:19 <jlanda> ack
18:14:01 <lruzicka> ack
18:14:08 <adamw> #agreed 1687508 - AcceptedFreezeException (Beta) - we're a bit reluctant to fiddle around with critical shell script in a freeze, but as this relates to a Change and there's still a couple of weeks to release, we're willing to take the risk
18:14:11 <cmurf> gagh too many tabs!
18:14:44 <pwhalen> ..ack
18:14:53 <adamw> looking at the accepted blockers, they're mostly a case of poking devs to actually fix them
18:15:01 <frantisekz> .fire pwhalen
18:15:01 <zodbot> adamw fires pwhalen
18:15:02 <adamw> #topic Accepted Beta blockers
18:15:10 <frantisekz> (late ack.... :D )
18:16:34 <adamw> #info most blockers are in a fairly straightforward state. 1673710 , 1656509 and 1686636 are waiting on the developers to fix them, 1684612 is awaiting verification with the next compose that all release-blocking images have new backgrounds
18:16:45 <adamw> #topic (1683197) gdm Fails to load with "nomodeset"
18:16:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1683197
18:16:45 <adamw> #info Accepted Blocker, xorg-x11-server, NEW
18:16:51 <adamw> this one seems a bit awkward
18:17:00 <adamw> there is widespread feedback that it's broken...but also was broken on f29
18:17:10 <adamw> we have not yet heard, i don't think, from anyone with a card that actually needs nomodeset to work
18:19:02 <lruzicka> which is a good thing, but nomodeset is a parachute in the plane and you want a working parachute
18:19:20 <adamw> i believe we've said before that 'nomodeset' not working on a system which doesn't actually *need* it is not a blocker
18:19:30 <frantisekz> yeah, something in those lines
18:19:39 <adamw> we're only going to block if it fails to work on a system which actually needs it to boot (i.e. isn't supported by native graphics drivers at all)
18:19:55 <frantisekz> I am okay with not-blocking on this, I'd like to discuss a little about the criterion, however
18:19:59 <adamw> still, i'm not sure what we want to do here. it feels like a problematic corner
18:20:08 <adamw> the functionality itself seems to be making less and less sense over time
18:20:17 <frantisekz> but... thread on a ml is probably a better place for that discussion
18:20:23 <adamw> yeah, true
18:20:27 <adamw> kalev: any thoughts?
18:20:47 <lruzicka> I think that if we do not have a working nomodeset, then Fedora will be not be installable on weird hardware and we might lose potential users.
18:21:33 <frantisekz> is it going to work reliably in graphical env anyway...? nomodeset worked horribly from what I remember
18:21:45 <adamw> i mean, ish.
18:21:55 <adamw> lruzicka: the thing is, this alleged 'weird hardware' seems to be a lot harder to find these days
18:22:04 <adamw> as evidenced by the fact that no-one seems to have any to try it on right now
18:22:24 <adamw> at least a few years ago we still actually had people with weird old matrox and s3 and stuff cards
18:22:42 <adamw> i don't recall the last time i saw *anything* that wasn't nvidia, amd or intel
18:22:57 <lruzicka> adamw, what about ATIs?
18:23:07 <frantisekz> work well
18:24:20 <adamw> lruzicka: AMD is ATI.
18:24:23 <adamw> they bought ATI like a decade ago. :)
18:24:41 <cmurf> i'm gonna file an issue with workstation WG
18:24:44 <lruzicka> I wonder why it does not work, is that such a hard thing to fix? Or is just nobody cared?
18:24:44 <frantisekz> (I mean, I've actually tried Fedora on ATI not that long ago, worked fine)
18:25:13 <adamw> #info we're a little concerned here that this may turn out not to be strictly a 'fixable' bug and may require some kind of change to the whole 'basic graphics' concept and criteria, but we will work on that with graphics and desktop folks
18:25:44 <adamw> lruzicka: i don't think we actually know what exactly is happening yet, so hard to say how hard it is to fix.
18:26:22 <lruzicka> but if we stopped blocking, it will never be fixed again.
18:26:45 <frantisekz> the question is... do we care about nomodeset anyway?
18:26:56 <lruzicka> which means to wave goodbye to it
18:28:01 <cmurf> if nomodeset isn't a safety parachute intended to always work; then we could optionaly tighten up the criterion so it's clear this refers only to the boot entry existing
18:28:28 <lruzicka> cmurf, I am for nomodeset be a safe parachute
18:28:36 <cmurf> because if it's not for sure supposed to work, we don't have enough hardware to make it a full blocker
18:28:44 <cmurf> it'd certainly be a conditional blocker
18:28:56 <cmurf> I'm asking the workstation WG that central question in the issue about to be filed
18:29:21 <cmurf> so if you want to punt on this bug that's fine :D
18:29:32 <lruzicka> I think we should block until we do not know that it cannot be fixed and then let FESCo decide
18:30:23 <adamw> cmurf: that is exactly what it currently says, but no-one believes me when i tell them that =)
18:30:30 <adamw> but anyway, we're not making a decision here, it's just a check-in
18:30:44 <cmurf> adamw: and I agree with you that is literally what it says
18:30:49 <cmurf> although there is a small ambiguity
18:30:57 <adamw> let's not re-litigate that, anyawy
18:31:05 <cmurf> i wont'
18:31:09 <cmurf> i'm putting it all in the issue
18:31:11 <cmurf> let them sort it
18:31:16 <cmurf> or not
18:32:35 <adamw> alrighty then
18:32:38 <adamw> i guess we're done here!
18:32:50 <adamw> #topic Open floor
18:32:53 <adamw> any other business, folks?
18:32:58 <adamw> of course, we are still having compose issues :/
18:33:06 <adamw> afaik the two most recent seem to be some sort of network issues, nirik?
18:34:36 <pwhalen> I took a look at yesterdays failed on arm xfce -  error: Curl error (16): Error in the HTTP2 framing layer
18:34:53 <adamw> yeah, that seems to be greatest hit, we've had it a couple of times before
18:34:55 <pwhalen> today's was the same iiuc
18:35:35 <nirik> yeah.
18:35:42 <nirik> I did one change that might help...
18:35:51 <nirik> and we have another we are going to try in rawhide first
18:38:12 <adamw> #info F30 composes are still failing for various reasons, most recently failures seem to be network-related, releng is trying to fix them
18:39:43 <adamw> hah
18:39:51 <adamw> actually saw the HTTP2 framing error in an openqa test just now
18:39:56 <adamw> https://openqa.fedoraproject.org/tests/361200
18:40:00 <adamw> https://openqa.fedoraproject.org/tests/361200/file/_check_install_source-packaging.log
18:40:06 <adamw> 07:53:54,294 DBG dnf: error: Curl error (16): Error in the HTTP2 framing layer for https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190310.n.2/compose/Everything/x86_64/os/repodata
18:44:30 <cmurf> basic video criterion, and failing boots with nomodeset https://pagure.io/fedora-workstation/issue/89
18:44:37 <adamw> thanks cmurf
18:45:24 <adamw> alrighty, seems we're about done here
18:45:28 <adamw> thanks for coming out, folks!
18:47:04 <adamw> #endmeeting