16:01:33 <adamw> #startmeeting F27-blocker-review
16:01:33 <zodbot> Meeting started Mon Sep 11 16:01:33 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:33 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:01:33 <adamw> #meetingname F27-blocker-review
16:01:33 <adamw> #topic Roll Call
16:01:33 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:01:39 <adamw> morning folks, who's around for some blocker review?
16:01:49 <jkurik> .hello2
16:01:50 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:01:53 <kalev> morning
16:01:56 * kparal is here
16:01:56 <jkurik> hi adamw
16:01:58 <kalev> .hello2
16:02:00 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:39 <kparal> hello kalev. perhaps we should start with workstation bugs? or are you here for the whole deal? :)
16:03:19 <kalev> I'll be here for the whole deal, was thinking of starting to come here regularly
16:03:29 * mkolman notes the unusual lack of outstanding Anaconda blockers
16:04:23 <kparal> kalev: awesome
16:04:45 <kparal> mkolman: very weird, eh?
16:06:19 <adamw> mkolman: there *is* a new bug in the latest anaconda build
16:06:22 <adamw> but it's probably not a blocker
16:06:46 <adamw> mkolman: when we do a btrfs install using 'create partitions for me' on a 10G disk, it produces a warning about the swap size
16:06:48 <adamw> it didn't used to do that
16:06:53 <adamw> but i'll look into that some more and file it later.
16:07:18 <adamw> anyhoo, morning everyone
16:07:24 <mkolman> btrfs...
16:07:25 <adamw> #chair kparal jkurik
16:07:25 <zodbot> Current chairs: adamw jkurik kparal
16:08:07 <Amita> warnings can be ignored - so not a blocker :)
16:08:34 * Amita waves to everyone
16:08:46 * pwhalen is here
16:09:20 <adamw> Amita: true
16:09:22 <adamw> hi amita
16:09:37 <adamw> #topic Introduction
16:09:37 <adamw> Why are we here?
16:09:37 <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:38 <adamw> #info We'll be following the process outlined at:
16:09:39 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:39 <adamw> #info The bugs up for review today are available at:
16:09:43 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:45 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:47 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Alpha_Release_Criteria
16:09:49 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
16:09:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria
16:09:53 <adamw> (yes, the Alpha criteria *still* exist, i swear i'll get my changes into production this week...)
16:10:13 <kparal> adamw: booo
16:10:48 * kparal back in 5-10 min
16:11:27 <Amita> did not I read mails about Alpha Criteria will go away
16:11:38 <Amita> I think I missed the train after that
16:12:27 <adamw> Amita: they're going away because Alphas are going away, i've drafted the changes but not sent them out into production yet
16:13:07 <Amita> ah got it now, I thought you gonna bring that back in prod
16:13:09 <Amita> :)
16:13:44 <adamw> #info for Beta we have:
16:13:46 <adamw> #info 9 Proposed Blockers
16:13:46 <adamw> #info 4 Accepted Blockers
16:13:52 <adamw> #info 7 Proposed Freeze Exceptions
16:13:55 <adamw> #info for Final we have:
16:14:03 <adamw> #info 3 Proposed Blockers
16:14:03 <adamw> #info 7 Accepted Blockers
16:14:10 <kparal> loads of fun
16:14:15 <adamw> sure, 'fun'
16:14:18 <adamw> who wants to secretarialize?
16:14:24 <kparal> I will
16:17:46 * kparal pokes adamw
16:17:59 <adamw> sorry
16:18:01 <adamw> multitasking
16:18:07 <adamw> #info kparal to secretarialize
16:18:20 <adamw> alright, starting in with the proposed blockers!
16:18:32 <adamw> #topic (1489144) UEFI installs crash during bootloader installation: "TypeError: must be str, not method"
16:18:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489144
16:18:33 <adamw> #info Proposed Blocker, anaconda, VERIFIED
16:19:13 <kparal> +1
16:19:19 <pwhalen> +1
16:19:25 <kalev> +1
16:19:30 <jkurik> +1
16:21:20 <Amita> crash ..
16:21:22 <Amita> +!
16:21:24 <Amita> +1
16:21:58 <adamw> yup
16:22:24 <adamw> proposed #agreed 1489144 - AcceptedBlocker (Beta) - clearly violates several "must be able to complete an install" criteria, in the case of a UEFI install
16:22:40 <jkurik> ack
16:22:49 <kalev> ack
16:23:38 <pwhalen> ack
16:24:29 <kparal> ack
16:24:30 <adamw> #agreed 1489144 - AcceptedBlocker (Beta) - clearly violates several "must be able to complete an install" criteria, in the case of a UEFI install
16:24:40 <adamw> #topic (1477916) Workstation boot.iso is 1.8 GB, seems to be ostree iso
16:24:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1477916
16:24:40 <adamw> #info Proposed Blocker, distribution, NEW
16:24:43 <adamw> sigh, this one again
16:24:53 <jkurik> According to http://dl.fedoraproject.org/pub/fedora/linux/development/27/Workstation/x86_64/os/images/ it is back to 504M, so it was probably just some hiccup
16:25:07 <adamw> well, no, it's not some hiccup.
16:25:14 <adamw> we clearly know what's going on and why.
16:25:25 <adamw> so either they merged the fix for it, or the workstation ostree installer image didn't build that day.
16:25:27 * jkurik does not know it :-(
16:25:49 <adamw> https://pagure.io/pungi-fedora/pull-request/347 was merged 3 days ago
16:25:59 <kalev> ahh, good
16:26:11 <kparal> ostree image is not in iso/
16:26:43 <jkurik> yeah, the pull-request/347 looks like a fix
16:27:07 <adamw> well, also, the workstation ostree installer image has never been built for f27
16:27:09 <adamw> don't know why that is
16:27:28 <kparal> therefore we can't be sure the fix is working or not
16:27:41 <adamw> so, i'm gonna propose we either un-nominate or reject this on the basis it's not actually happening to Beta atm
16:27:58 * kparal shrugs
16:28:04 <jkurik> adamw: the https://fedoraproject.org/wiki/Changes/WorkstationOstree is still "PageIncomplete"
16:28:09 <adamw> but i'll ask releng to be aware that we probably shouldn't enable the workstation ostree installer image for beta unless we're sure this is fixed
16:28:22 <kparal> technically it's not a blocker "yet". just don't go screaming when it happens for an RC :)
16:28:35 <adamw> we could change it to FinalBlocker
16:29:06 <jkurik> adamw: it did not went through Change process yet
16:29:16 <adamw> jkurik: we already shipped it in f26
16:29:21 <adamw> so it appears it didn't need to
16:29:45 <jkurik> adamw: yes, but just a "pilot", not really made it public
16:31:06 * adamw dances on the head of a pin
16:31:14 <kparal> jkurik: but including this bug
16:31:33 <adamw> well, bottom line is, we can't reasonably say beta is blocked on something that's never happened to an f27 compose yet.
16:31:50 <kparal> let's un-nominate
16:31:54 <adamw> ok
16:31:55 <jkurik> right
16:31:59 <adamw> with a note to renominate if it actually happens
16:32:12 <kparal> maybe move to F28 Beta?
16:32:38 <kparal> either way is fine
16:32:54 <adamw> proposed #agreed 1477916 - drop nomination - the Workstation ostree installer image has never been built in an F27 compose; until it is, this bug cannot happen to one. So we're dropping the nomination for now, but will immediately re-nominate it if the bug does start affecting F27 composes
16:33:06 <kparal> ack
16:33:21 <kalev> ack
16:34:03 <pwhalen> ack
16:34:10 <adamw> #agreed 1477916 - drop nomination - the Workstation ostree installer image has never been built in an F27 compose; until it is, this bug cannot happen to one. So we're dropping the nomination for now, but will immediately re-nominate it if the bug does start affecting F27 composes
16:34:19 <adamw> #topic (1489164) Fedora 27 Beta backgrounds must be different from Fedora 26
16:34:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489164
16:34:19 <adamw> #info Proposed Blocker, distribution, NEW
16:34:30 <adamw> this is pretty unarguably a blocker, we just need to get people to jump through the necessary hoops :/
16:34:39 <adamw> i'm so tired of this not being done a month ahead of time, every time.
16:34:46 <Amita> hmm
16:35:07 <kparal> +1
16:35:08 <pwhalen> +1
16:35:13 <Amita> +1
16:35:19 <kalev> +1
16:35:31 <kalev> I'll also go an update gnome-software distro upgrade background images as well, before I forget about them
16:36:11 <jkurik> we have the backgrounds on review https://bugzilla.redhat.com/show_bug.cgi?id=1489160
16:36:13 <adamw> proposed #agreed 1489164 - AcceptedBlocker (Beta) - clearly violates Alpha criterion "The default desktop background must be different from that of the last two stable releases."
16:36:20 <adamw> jkurik: yes, this bug depends on that one.
16:36:30 <jkurik> ack
16:36:31 <kalev> ack
16:36:32 <adamw> but then there are also changes required to other packages and possibly comps/kickstarts.
16:36:35 <kparal> ack
16:36:41 <pwhalen> ack
16:36:48 <adamw> #agreed 1489164 - AcceptedBlocker (Beta) - clearly violates Alpha criterion "The default desktop background must be different from that of the last two stable releases."
16:37:16 <adamw> #topic (1456293) [abrt] gnome-shell: js::GCMethods<JSObject*>::needsPostBarrier(): gnome-shell killed by signal 11
16:37:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1456293
16:37:17 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:38:40 <kparal> no clear reproducer here
16:38:51 <kparal> FAF numbers are low
16:38:55 <kalev> I'd repurpose that as a final blocker, and freezeexcept this for Beta. We shipped with the very same crash in F26 gold and it passed final testing there.
16:39:20 <kparal> kalev: do you know when it happens?
16:39:47 <kalev> kparal: with certain extensions enabled, if I've understood this right. I've never been able to reproduce this myself
16:40:07 <kalev> gnome-shell extensions I mean
16:40:12 <kparal> if it passed for f26, and it's related to certain extensions, I guess it's not even final blocker material
16:40:29 <adamw> well, we can burn that bridge when we come to it
16:40:32 <adamw> but definitely -1 for beta
16:40:46 <kparal> we get to that bridge later today, hm?
16:41:07 <kalev> I'm -1 for beta as well
16:41:39 <pwhalen> -1
16:41:59 <kparal> -1 beta, +1 fe
16:42:16 <kalev> I'd like to have a FE for this as well. I've got a mozjs52 + gjs update in the works that should fix this crash
16:42:28 <adamw> kparal: i'm a bit nervy about FE because if we accept it as FE, what we're going to get submitted is the entire GNOME megaupdate, i think
16:42:38 <kalev> not entirely sure I'll be ready with this in time, as mozjs is a bit tricky, but if I do, I'd like to have a FE for this
16:42:39 <kparal> hm
16:42:40 <adamw> or can you give us a more targeted fix, kalev?
16:42:43 <kalev> I'll put this separately, yes
16:42:46 <adamw> okay
16:43:03 <adamw> well, if we're actually releasing this week (*hollow laugh*), you don't have much time. but uh...yeah.
16:43:04 <pwhalen> ok, +1 fe as well
16:43:10 * kalev nods.
16:43:18 <adamw> +1 fe if we get a targeted fix in reasonable time for whatever schedule we wind up on.
16:43:38 <jkurik> -1 beta blocker, +1 fe
16:43:40 <adamw> proposed #agreed 1456293 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is bad if you hit it, but the FAF numbers and upstream bug analysis indicate not many people do actually hit it; thus the breadth of impact isn't significant enough for this to block the Beta. We'll accept a fix if it's targeted and arrives in good time for testing
16:43:56 <kalev> ack
16:43:57 <jkurik> ack
16:44:06 <kparal> ack
16:44:10 <adamw> #agreed 1456293 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is bad if you hit it, but the FAF numbers and upstream bug analysis indicate not many people do actually hit it; thus the breadth of impact isn't significant enough for this to block the Beta. We'll accept a fix if it's targeted and arrives in good time for testing
16:44:23 <adamw> #topic (1490072) Program terminated with signal SIGSEGV, Segmentation fault. #0  0x00007f16279aa68f in _cogl_boxed_value_set_x () from /usr/lib64/mutter/libmutter-cogl-1.so
16:44:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490072
16:44:23 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:45:03 <adamw> welp, i know nothing about this.
16:45:12 <adamw> oh wait
16:45:21 <kalev> this is the first time I've heard of it as well
16:45:22 <adamw> i think i have this exact crash, actually. but somehow my report wound up somewhere else?
16:45:32 <adamw> but yeah, my GNOME session consistently crashes when I launch VMs in virt-manager.
16:45:40 <adamw> which is exceedingly frustrating, and means I just skip out on testing things.
16:46:04 <adamw> (although it's my own idiotic fault for running f27 on my desktop...)
16:46:10 * kparal chickened out and uses X11 for this reason
16:46:40 <kalev> adamw: can you file an upstream bug please if you can reproduce it?
16:46:54 <adamw> probably.
16:47:03 <adamw> i just hate reproducing it, because it blows up everything else i'm doing at the time. :P
16:47:13 <adamw> maybe i'll see if i can reproduce it on another box.
16:47:44 <adamw> so, this is maybe a bit closer to being a blocker for me, since it's triggered by something that's kinda in the beta criteria (virtualization)
16:47:59 <adamw> still, we're a bit short on data
16:48:12 <adamw> anyone else running f27 and can quickly try launching a VM in virt-manager? on a box they don't care too muc habout? :P
16:48:28 * kparal can't right now
16:48:47 <kalev> and if it's reproducible, try with newer mutter from updates-testing, just in case it's already fixed?
16:48:48 <kparal> punt and #action everyone to test
16:49:22 <adamw> sounds good
16:49:27 * kalev nods.
16:50:26 <adamw> hum, i just found a gnome-shell crash in abrt and filed it, but it wasn't this: https://bugzilla.redhat.com/show_bug.cgi?id=1486136
16:50:33 <adamw> good news everyone, everything is awful
16:50:37 <adamw> agree with punt and test
16:51:19 <adamw> proposed #agreed 1490072 - punt (delay decision) - we don't have quite enough information on how common this crash is to make a decision yet; we'd like to ask folks to test launching VMs in virt-manager on F27 and see if this affects many people
16:51:32 <jkurik> ack
16:51:40 <kalev> ack
16:52:08 <kparal> ack
16:55:17 <adamw> #agreed 1490072 - punt (delay decision) - we don't have quite enough information on how common this crash is to make a decision yet; we'd like to ask folks to test launching VMs in virt-manager on F27 and see if this affects many people
16:55:45 <adamw> #topic (1490287) dnf system-upgrade fails due to grub2/grub2-tools
16:55:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490287
16:55:46 <adamw> #info Proposed Blocker, grub2, NEW
16:56:04 <jkurik> +1 to block
16:56:12 <adamw> ehhh
16:56:14 <kparal> lbrabec wanted to upgrade to F27 today
16:56:18 <adamw> --allowerasing is actually fine
16:56:21 <adamw> removing the grub2 package is correct
16:56:26 <kparal> what?
16:56:26 <adamw> that's what *should* happen
16:56:35 <adamw> the bug is actually https://bugzilla.redhat.com/show_bug.cgi?id=1487867
16:57:06 * adamw dupes it
16:57:29 <kparal> I don't understand it
16:57:36 <kparal> if grub2 gets removed, what stays?
16:57:45 <adamw> grub2-pc
16:57:48 <adamw> (on i686 and x86_64_
16:57:53 <adamw> grub2-ppc64 on ppc64
16:57:57 <adamw> grub2-ppc64le on ppc64le
16:58:07 <adamw> well, they don't "stay", they're new packages
16:58:14 <jkurik> ah, that is tricky
16:58:28 * kparal quickly checks
16:58:31 <adamw> they're supposed to obsolete 'grub2', but because pjones typoed the Obsoletes: line, they don't.
16:58:59 <adamw> https://koji.fedoraproject.org/koji/buildinfo?buildID=967139 fixes this
16:59:11 <kalev> if we already have a build, can we pull this in for beta?
16:59:37 <adamw> there needs to be an update
16:59:38 <kparal> yeah, change it to FE
16:59:40 <adamw> i'm checking if there is one yet
16:59:48 <kalev> doesn't seem to be an update yet
16:59:56 <adamw> so we should make one.
17:00:03 <adamw> i'll poke pjones, but if he's not around, i'll just do it.
17:00:43 * kparal still checking grub-pc existence
17:02:29 <jkurik> kparal: http://dl.fedoraproject.org/pub/fedora/linux/development/27/Workstation/x86_64/os/Packages/g/grub2-pc-2.02-14.fc27.x86_64.rpm
17:02:52 <kparal> adamw: https://paste.fedoraproject.org/paste/ZV9PIOpBdFv54KbpiI9sdg/raw
17:02:56 <kparal> I don't see it there
17:03:03 <kparal> grub2 goes away, grub2-pc doesn't go in
17:03:19 <adamw> oooh, yeah
17:03:24 <adamw> so --allowerasing isn't doing the right thing
17:03:33 <kparal> so, seems like blocker after all
17:03:34 <adamw> right, because it doesn't know grub2-pc should go it
17:03:36 <adamw> in*
17:03:44 <adamw> well...not necessarily. cos grub2 not existing doesn't make the system fail to boot. :P
17:03:55 <adamw> the only thing the package contains is the config files.
17:04:08 <kparal> I don't like where this is going
17:04:22 <adamw> i'm just saying, we still don't know exactly what the consequences are here
17:04:25 <kparal> what happens after next kernel update?
17:04:27 <adamw> might be best just to fix it, though
17:04:29 <adamw> who knows!
17:04:35 <adamw> it depends if the config files actually go away, i think
17:04:49 <kalev> yes, let's get a fix in, just to be on the safe side here
17:04:52 <adamw> but all the actual tools are in, well, grub2-tools
17:04:55 <kparal> well, in this case I'd say blocker until proven innocent
17:04:59 <adamw> grub2-install and so on
17:05:11 <adamw> and they'll write the same config file regardless of whether it's packaged
17:05:23 <adamw> in fact...i suspect the case where this *would* break is if you update grub2 but *don't* update the kernel
17:05:43 <adamw> because removing the grub2 package might take away the config files, and if there's no kernel update, they don't get regenerated
17:05:59 <kparal> the users would never get a future grub2 update, because the package would not be there
17:06:05 <kparal> which might be a problem as well
17:06:07 <adamw> true
17:06:36 <adamw> okay, i'm willing to give this a +1 on that basis
17:06:38 <adamw> other votes?
17:06:40 <kparal> +1
17:06:43 <kalev> +1
17:08:02 <adamw> oh
17:08:08 <adamw> we actually have a nice clear-cut criterion to use here
17:08:12 <adamw> which i'd forgotten about...
17:09:06 <adamw> proposed #agreed 1490287 - AcceptedBlocker (Beta) - even if you can upgrade with --allowerasing, grub2-pc will not be installed after upgrade, violating the "The upgraded system must include all packages that would be present on the system after a default installation from install media" clause of the upgrade criterion
17:09:18 <adamw> i bet we break that all the time, but tum-ti-tum, let's not think too hard
17:09:29 <jkurik> ack
17:09:31 <kparal> ack
17:09:31 <kalev> ack
17:09:44 <adamw> #agreed 1490287 - AcceptedBlocker (Beta) - even if you can upgrade with --allowerasing, grub2-pc will not be installed after upgrade, violating the "The upgraded system must include all packages that would be present on the system after a default installation from install media" clause of the upgrade criterion
17:09:54 <adamw> #topic (1475570) Rescue mode fails while trying to access LVM volumes from existing install
17:09:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1475570
17:09:55 <adamw> #info Proposed Blocker, lvm2, NEW
17:10:15 <adamw> sorry, i only noticed this week that this is a beta criterion :/
17:10:19 <adamw> we've had the bug filed for a while
17:10:27 <adamw> i kinda thought it was final
17:10:42 <adamw> mkolman: here's your anaconda bug :P
17:11:13 * adamw brb, call of nature
17:11:17 <mkolman> adamw: it's assigned to LVM ;-)
17:11:21 <kparal> anaconda-ish
17:11:56 <kparal> +1
17:13:57 <pwhalen> +1
17:14:06 <kalev> +1
17:14:38 <jkurik> +1
17:15:30 <kalev> I have to step away for 15 minutes, back in a bit
17:17:11 <adamw> anaconda-adjacent
17:17:36 <adamw> proposed #agreed 1475570 - AcceptedBlocker (Beta) - seems a clear violation of "The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations"
17:18:10 <kparal> ack
17:18:46 <jkurik> ack
17:19:10 <pwhalen> ack
17:20:07 <adamw> #agreed 1475570 - AcceptedBlocker (Beta) - seems a clear violation of "The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations"
17:21:24 <adamw> #topic (1489862) There is FW Raid set, but there is no /dev/md* device
17:21:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489862
17:21:25 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:22:24 <adamw> i suspect this will be live only
17:22:40 <kparal> I'll have to retest that, pschindl is on vacation
17:22:43 <adamw> kparal: do you happen to know if they re-tested this?
17:22:51 <adamw> he was passing on info from someone called 'vojtech' apparently?
17:22:57 <adamw> oh, vtrefny
17:23:09 <kparal> vtrefny from blivet
17:23:19 <kparal> formerly from anaconda
17:23:30 <kparal> I'll talk to him
17:24:08 <kparal> either punt or we need to believe selinux was the problem here
17:24:38 <adamw> i can't test firmware RAID atm unfortunately because mdraid doesn't support the motherboard in my new test box
17:25:25 <adamw> if selinux *is* the issue, i'd probably be -1 beta (on the basis you can use a non-live image or boot with enforcing=0), +1 final
17:25:25 <kparal> yeah, we have one non-functional amd raid as well. we should probably inquire about its support, once we have some free time (ha ha)
17:25:33 <adamw> ahah ha. ha.
17:25:49 <adamw> i don't think anyone's super active writing new fw raid support for mdadm, but imbw.
17:26:27 <kparal> our amd motherboard is about 4 years old
17:26:28 <jkurik> Lukas Vrabec provided a fix https://bodhi.fedoraproject.org/updates/FEDORA-2017-5aefc0255f , I would be +1 FE at least
17:26:50 <kparal> jkurik: good idea
17:26:54 <kparal> +1 fe to selinux issue
17:26:58 <adamw> yeah, +1 FE indeed
17:27:00 <pwhalen> +1 fe
17:27:07 <adamw> karma that update, folks
17:27:08 <adamw> :P
17:27:55 <adamw> so do we want to vote or punt on blocker status?
17:28:01 <adamw> let's vote about whether to vote!
17:28:07 <kparal> punt
17:29:17 <jkurik> punt
17:30:04 <adamw> alrighty
17:30:52 <adamw> proposed #agreed 1489862 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - it's not 100% clear yet if the SELinux denials are the only problem here, so we will delay the blocker vote until we have confirmation on that. however, we think it at least makes sense to grant the SELinux fixes a freeze exception immediately
17:31:41 <kparal> ack
17:31:44 <jkurik> ack
17:32:26 <pwhalen> ack
17:33:03 <adamw> #agreed 1489862 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - it's not 100% clear yet if the SELinux denials are the only problem here, so we will delay the blocker vote until we have confirmation on that. however, we think it at least makes sense to grant the SELinux fixes a freeze exception immediately
17:34:23 <adamw> #topic (1488707) [abrt] tracker: g_str_hash(): tracker-extract killed by signal 11
17:34:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1488707
17:34:24 <adamw> #info Proposed Blocker, tracker, NEW
17:35:15 <kparal> FAF link not working
17:35:20 * kalev is back now
17:36:13 <adamw> is this happening every second to anyone else?
17:36:22 <adamw> it's not happening every second to me. but then...i think maybe i have tracker turned off.
17:36:22 * kparal is not yet running F27
17:36:36 <kparal> and I also turn tracker off :)
17:36:54 <kalev> I haven't seen that either, but I have abrt turned off :)
17:37:07 <kparal> see, two good solutions to this problem
17:37:49 <adamw> heh
17:38:23 <kalev> as much as I can tell, tracker is mostly broken on F27 for another reason, but not crashing here
17:38:35 <kalev> not really working, but not crashing at least :)
17:38:52 <adamw> and afaics no-one else has reported this...
17:39:49 <pwhalen> which is weird, surely else out there isnt disabling it
17:40:07 <adamw> well, it suggests this might be another system-dependent bug
17:40:19 <adamw> which isn't terribly weird, i mean, tracker basically *is* a giant database full of weird stuff from your system.
17:40:38 <adamw> it's not that unusual for it to crap its pants on certain specific conditions that don't happen everywhere.
17:40:55 <kalev> I think the report was for tracker 1.99.0. we now have 1.99.1 in F27 stable. might be fixed for everybody else because of that
17:42:46 <adamw> welp, anyway, i'm feeling pretty -1 on a bug no-one else has reported hitting yet, so far as we can tell.
17:43:08 <kalev> I'm -1 as well
17:43:37 <pwhalen> agreed.. -1
17:43:48 * kparal nods
17:43:49 <jkurik> I do not understand well how the tracker works, so I am +0 here
17:45:20 <kalev> can we have a brief discussion about another tracker issue when we're done with this? I'm interested how people feel if this is something we need to fix for Beta or not
17:46:20 <adamw> we usually do it in open floor
17:46:25 <kalev> ok
17:46:51 <adamw> proposed #agreed 1488707 - RejectedBlocker (Beta) - for now, there is no indication this affects anyone besides Mikhail. We'd need information indicating this bug will hit a somewhat wider range of folks to accept it as a blocker
17:47:09 <kparal> ack
17:47:10 <adamw> aside: I've just submitted an update for grub2 - https://bodhi.fedoraproject.org/updates/grub2-2.02-16.fc27 . if folks could karma it that'd be great
17:47:27 <kalev> ack
17:47:45 <pwhalen> ack
17:48:01 <adamw> #agreed 1488707 - RejectedBlocker (Beta) - for now, there is no indication this affects anyone besides Mikhail. We'd need information indicating this bug will hit a somewhat wider range of folks to accept it as a blocker
17:48:31 <kparal> it's also proposed for FE
17:48:35 <kparal> adamw: ^^
17:50:00 <adamw> grmph
17:50:21 <kparal> that sounds german
17:50:36 <adamw> proposed #agreed 1488707 - punt (delay decision) on FreezeException status - we don't have enough information on the cause, prevalence or fix for this yet to make an FE determination
17:50:45 <kparal> ack
17:50:47 <kalev> ack
17:50:57 <jkurik> ack
17:51:55 <adamw> #agreed 1488707 - punt (delay decision) on FreezeException status - we don't have enough information on the cause, prevalence or fix for this yet to make an FE determination
17:52:35 <adamw> #info moving onto proposed Beta freeze exceptions
17:52:39 <adamw> #topic (1489124) Downgrade to version 6 for Fedora 27
17:52:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489124
17:52:39 <adamw> #info Proposed Freeze Exceptions, ImageMagick, ON_QA
17:52:49 <adamw> this one's basically a FESCo request, so should be pretty no-brainer-ish
17:53:02 <kparal> +1
17:53:07 <kalev> +1
17:53:26 <pwhalen> +1
17:53:28 <jkurik> +1
17:55:48 <adamw> proposed #agreed 1489124 - AcceptedFreezeException (Beta) - this is required to fulfil a FESCo decision
17:55:58 <kparal> ack
17:55:59 <kalev> ack
17:56:00 <adamw> patch:
17:56:06 <adamw> proposed #agreed 1489124 - AcceptedFreezeException (Beta) - this is required to fulfil a FESCo decision (https://pagure.io/fesco/issue/1766)
17:56:12 <adamw> why not be helpful...
17:56:17 <jkurik> ack
17:56:24 <kparal> ack
17:56:27 <kalev> ack
17:58:36 <pwhalen> ack
17:59:39 <adamw> #agreed 1489124 - AcceptedFreezeException (Beta) - this is required to fulfil a FESCo decision (https://pagure.io/fesco/issue/1766)
17:59:53 <adamw> #topic (1489285) abrt-action-find-bodhi-update failed when reporting a bug on xfce
17:59:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489285
17:59:53 <adamw> #info Proposed Freeze Exceptions, abrt, MODIFIED
18:00:29 <adamw> i think this actually affects things outside of xfce
18:00:41 <adamw> but anyhow, looks +1 FE material to me
18:00:55 <kalev> probably something that would be nice to pull in to make sure people can actually report things that aren't workign in beta
18:01:00 <kalev> +1 FE from me too
18:01:17 <pwhalen> +1 FE
18:01:46 <kparal> +1
18:03:15 * kparal pokes adamw
18:03:22 <adamw> sorry, just writing the message
18:03:51 <adamw> proposed #agreed 1489285 - AcceptedFreezeException (Beta) - this is clearly desirable functionality and affects live images (so cannot be fully fixed with an update)
18:04:19 <kalev> ack
18:04:46 <kparal> ack
18:06:08 <jkurik> ack
18:06:11 <adamw> #agreed 1489285 - AcceptedFreezeException (Beta) - this is clearly desirable functionality and affects live images (so cannot be fully fixed with an update)
18:06:37 <adamw> #topic (1456293) [abrt] gnome-shell: js::GCMethods<JSObject*>::needsPostBarrier(): gnome-shell killed by signal 11
18:06:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1456293
18:06:37 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
18:06:44 <adamw> this is the same one we considered as a blocker earlier...
18:06:48 <adamw> did we make a call on FE at the time>?
18:07:03 * jkurik needs to leave
18:07:05 <adamw> oh, we did.
18:07:08 <kalev> yep, we did
18:07:08 <jkurik> thanks for the review
18:07:12 <adamw> #info we already made this accepted FE earlier
18:07:15 <adamw> thanks jkurik!
18:07:35 <adamw> same for 1490072
18:07:44 <adamw> #topic (1489184) ipa-dnskeysyncd fails in a loop in Fedora 27 ("pyasn1.error.PyAsn1Error: Uninitialized ASN.1 value ("__str__" attribute looked up)")
18:07:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489184
18:07:44 <adamw> #info Proposed Freeze Exceptions, python-ldap, NEW
18:09:40 <kparal> +1
18:11:10 <adamw> yeah, this doesn't actually prevent freeipa passing the validation tests but it's obviously bad to have it happening constantly on the server (and probably does brea ksome features)
18:11:11 <adamw> so +1
18:11:16 <pwhalen> +1
18:11:29 <kalev> +1
18:12:11 <adamw> proposed #agreed 1489184 - AcceptedFreezeException - this is a significant bug in a component shipped on the server DVD; it doesn't violate release criteria but it'd be good to have it fixed
18:12:51 <kparal> ack
18:12:52 <kalev> ack
18:13:36 <adamw> pwhalen: ack?
18:13:41 <pwhalen> ack
18:13:47 <pwhalen> sorry
18:14:41 <adamw> #agreed 1489184 - AcceptedFreezeException - this is a significant bug in a component shipped on the server DVD; it doesn't violate release criteria but it'd be good to have it fixed
18:14:41 <adamw> npnp
18:14:51 <adamw> #topic (1489604) AArch64 installations fail to boot using shimaa64.efi - 'Error reported: Unsupported'
18:14:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489604
18:14:51 <adamw> #info Proposed Freeze Exceptions, shim-signed, NEW
18:15:20 <adamw> this is really the same as the x86_64 bug, i think
18:15:26 <kparal> +1
18:15:31 <adamw> oh wait
18:15:32 <kalev> +1
18:15:34 <adamw> no it's not...
18:15:41 <adamw> so yeah, +1
18:15:56 <nb> +1
18:16:10 <pwhalen> +1
18:16:30 <pwhalen> adamw, has anyone booted from the x86 version?
18:16:38 <adamw> proposed #agreed 1489604 - AcceptedFreezeException (Beta) - this breaks UEFI installs on aarch64, a non-release-blocking arch; obviously can't be fixed with an update, so clearly worth an FE
18:16:44 <nb> ack
18:16:44 <adamw> pwhalen: yeah. it works fine.
18:16:45 <kparal> ack
18:16:55 <adamw> pwhalen: i ran some tests of a custom 27 image with anaconda 27.20.1-3.
18:16:56 <pwhalen> ack
18:17:06 <adamw> #agreed 1489604 - AcceptedFreezeException (Beta) - this breaks UEFI installs on aarch64, a non-release-blocking arch; obviously can't be fixed with an update, so clearly worth an FE
18:17:10 <pwhalen> adamw, ok, thanks..
18:18:59 <adamw> we already did 1488707
18:19:04 <adamw> so, let's go on to proposed final blockers
18:19:10 <adamw> #info moving onto proposed final blockers
18:19:39 <adamw> #topic (1490351) New version of gjs is available: 1.49.92
18:19:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490351
18:19:40 <adamw> #info Proposed Blocker, gjs, NEW
18:20:16 <kparal> I didn't know Frantisek started working for us today :)
18:20:17 <kalev> it's largely the same as the gnome-shell crash we discussed earlier, and FE'd for Beta
18:21:13 <adamw> i dunno if this is the right bug to make the blocker, but the basic issue seems reasonable
18:21:28 <adamw> it'd seem more sensible to make one of the actual crasher bugs be the blocker
18:21:37 <kparal> the linked bug was rejected as a blocker
18:21:57 <kparal> and so it probably doesn't make sense to make this one a blocker
18:22:06 <kparal> FE, sure
18:25:24 <adamw> well, there seem to be more than one dependent bug
18:25:26 <adamw> er, linked
18:25:53 <adamw> and we only rejected 1456293 as a *beta* blocker, not final.
18:26:36 <adamw> i propose we ask folks to nominate specific functionality bugs as blockers, and we'll take it from there
18:27:00 <kparal> agreed
18:27:36 * kalev concurs.
18:28:36 <adamw> proposed #agreed 1490351 - RejectedBlocker (Final) - this bug is simply about the availability of a new version, that is not a reasonable candidate for blocker status. We will ask reporters to nominate actual functional bugs that are fixed by the new version as blockers, and we'll evaluate those on their merits
18:28:55 <kparal> ack
18:28:58 <kalev> ack
18:29:50 <pwhalen> ack
18:32:53 <adamw> #agreed 1490351 - RejectedBlocker (Final) - this bug is simply about the availability of a new version, that is not a reasonable candidate for blocker status. We will ask reporters to nominate actual functional bugs that are fixed by the new version as blockers, and we'll evaluate those on their merits
18:33:00 <adamw> #topic (1146232) no VM networking; 'default' network in the VM conflicts with 'default' network on the host
18:33:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1146232
18:33:01 <adamw> #info Proposed Blocker, libvirt, ASSIGNED
18:33:03 <adamw> oh christ, this one again
18:33:19 * adamw breaks the glass on the 1146232 Emergency Whisky cabinet
18:34:23 <adamw> what did we do with it last time?
18:34:28 <kparal> I knew you would be very happy :)
18:34:42 <kparal> we always removed libvirt dep from gnome-boxes and then added it back as an update
18:34:45 <mkolman> 99 bottles of whiskey on the wall...
18:34:45 <kalev> I remember cherry-picking an old adamw fix
18:34:47 <kparal> like 5 releases in a row
18:35:06 <kparal> well libvirt networking dep, to be exact
18:35:12 <kparal> so that it defaults to userspace networking
18:35:35 <adamw> yeah
18:36:15 <kparal> Cole claimed to finally fix it in F26 update
18:36:35 <kparal> it might not apply for existing F26 systems, I don't know
18:36:45 <kparal> that's why I installed from F26 from Live and not netinst
18:36:58 <kparal> either way, doesn't work
18:37:05 <adamw> well
18:37:16 <adamw> it makes sense that the installed f26 system takes the network
18:37:28 <adamw> because the check cole added is basically saying 'don't take that network if we're running live'
18:37:31 <adamw> which the installed system...isn't
18:37:42 <adamw> what i'm surprised by, is that the f27 live image should have the same fix and so shouldn't try to claim it...
18:38:01 <kparal> yes, that's why I'd expect
18:38:08 <adamw> unless the fix was only ever applied to f26 branch
18:38:11 * adamw looks
18:38:33 <kparal> doesn't really matter at this moment, I think
18:38:36 <kparal> +1 as always
18:38:56 <adamw> yeah...i think the branches diverged
18:39:16 <adamw> and the systemd unit tweak was never applied to f27+
18:39:38 <adamw> still, as per #c78, the 'fix' only moves the problem out a bit...we think...
18:41:57 <adamw> this specific bug was never actually accepted as a blocker, it seems
18:42:01 <adamw> there must be another one
18:43:08 <adamw> kparal: can you remember what grounds we accepted this as a blocker on before?
18:43:11 <adamw> i don't see a criterion cited.
18:43:33 <kparal> virtualization needs to work?
18:43:42 <kparal> updates must work?
18:44:28 <kparal> we accepted https://bugzilla.redhat.com/show_bug.cgi?id=1164492
18:45:23 <adamw> oh, and wait, we *did* accept this bug at one point, i just read the comment too quickly.
18:45:37 <kparal> we jumped before the two bugs
18:45:41 <kparal> *between
18:45:49 <adamw> i think for good reason
18:46:05 <adamw> 1146232 is kinda the underlying problem that we want (but still have not figured out) a permanent solution for
18:46:20 <adamw> we don't want to set that to ON_QA and then CLOSED because we just do the 'twiddle the dep' workaround for f27
18:46:38 <kparal> but now it has a "proper" fix
18:46:41 <adamw> it doesn't, though
18:46:43 <kparal> and has been closed already
18:46:50 <adamw> i agree with cole re #c78
18:46:55 <adamw> (now i think about it a bit more)
18:47:40 <kparal> ah, I missed that comment
18:47:45 <kparal> that would still be the same problem
18:48:54 <adamw> god, i hate dealing with this
18:49:05 <kparal> we don't need to come up with a solution
18:49:14 <adamw> i just hate dealing with the bureaucracy :P
18:49:18 <adamw> but do you agree on having a new bug again?
18:49:36 <kparal> I don't care
18:49:39 <adamw> hah
18:49:47 <adamw> you've been at the emergency whisky, i see
18:50:14 <kparal> it's not important which bug it accepted as long as it is fixed somehow
18:50:36 <kparal> it makes sense to use 1164492 again
18:50:41 <kparal> rather than 1146232
18:51:00 <kparal> because the current solution is clearly not good enough according to c78
18:51:01 <adamw> okay, let's do that
18:52:42 <adamw> proposed #agreed 1146232 - RejectedBlocker (Final) - we do actually think the problem here constitutes a blocker, but as with previous releases, we will make #1164492 the blocker as we may fix it with a short-term workaround rather than a real fix (again)
18:52:56 <adamw> (i have re-opened and proposed 1164492)
18:53:14 <adamw> or, we can do it all in one:
18:53:45 <adamw> proposed #agreed 1146232 - RejectedBlocker (Final), #1164492 - AcceptedBlocker (Final) - we think the problem here constitutes a blocker, but as with previous releases, we will make #1164492 the blocker as we may fix it with a short-term workaround rather than a real fix (again)
18:54:00 <kparal> kalev: any chance on, I don't know, dropping boxes? :)
18:54:16 <kparal> ack
18:55:29 <kparal> 5 minutes remaining
18:55:53 <pwhalen> ack
18:56:05 <adamw> i think we have one bug after this
18:56:09 <adamw> those acks are for the second proposal, right?
18:56:23 <kparal> but we seem to be lacking living souls
18:56:27 <kalev> kparal: not sure, I think several people on the workstation WG would like it to be on the default install
18:56:34 <kalev> ack
18:56:51 <kparal> I was just joking. I know boxes is well loved in workstation WG
18:57:27 <adamw> #agreed 1146232 - RejectedBlocker (Final), #1164492 - AcceptedBlocker (Final) - we think the problem here constitutes a blocker, but as with previous releases, we will make #1164492 the blocker as we may fix it with a short-term workaround rather than a real fix (again)
18:57:35 <adamw> #topic (1485021) rawhide .treeinfo is missing [images-xen] section.
18:57:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1485021
18:57:35 <adamw> #info Proposed Blocker, pungi, NEW
18:58:42 <adamw> -1, i386 isn't release blocking.
18:59:04 <adamw> (and i wouldn't really count this as violating the criterion even if it was x86_64, virt-install is a convenience thing, not *required* functionality...)
18:59:52 <kalev> -1 blocker, but maybe +1 FE?
19:00:11 <kparal> -1
19:01:33 <pwhalen> -1
19:03:22 <adamw> just -1 for now, i think, there's nothing clearly needing/deserving an FE here i don't think...
19:03:38 <adamw> proposed #agreed 1485021 - RejectedBlocker (Final) - this is specific to i686, which is no longer a release-blocking arch.
19:04:22 <kparal> ack
19:04:41 <pwhalen> ack
19:04:42 <kalev> ack
19:04:46 <adamw> #agreed 1485021 - RejectedBlocker (Final) - this is specific to i686, which is no longer a release-blocking arch.
19:05:17 <adamw> #info accepted blockers don't really need looking at, I'm tracking those
19:05:21 <adamw> #topic Open floor
19:05:29 <adamw> so we're a bit over time, but kalev had something for open floor and we said we'd look at it
19:05:31 <adamw> what was that, kalev?
19:06:37 <kparal> I was worried we'd scare him away, and he has an encore
19:06:43 <kalev> right, let me find the bug
19:06:53 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1484086
19:07:18 <kalev> this is filed against F26, but we didn't get this fixed in F27
19:07:30 <kalev> and searching in gtk file dialogs is currently broken due to that
19:07:47 <kalev> opinions if it's worth fixing for F27 Beta?
19:08:22 <kparal> +1 FE for sure
19:08:31 <kparal> probably not blocker
19:08:53 <kparal> searching is used for history or as a full filesystem search?
19:09:26 <kalev> full filesystem search
19:09:54 <adamw> i mean, it's kinda a gues
19:09:55 <adamw> s
19:10:15 <kalev> ok, I'll get a fix lined up tomorrow and ping people on IRC for FE votes then
19:10:24 <kparal> not Beta blocker, imo. could be Final
19:10:27 <adamw> i have no idea how often people use that feature. i apparently don't ever, cos i'd never seen this bug till i intentionally tried it just now
19:10:39 <adamw> definitely feels more fe than blocker to me
19:10:47 * kalev nods.
19:10:50 <adamw> but it's always hard to make such calls without data
19:11:14 <kparal> the fix is new tracker, new gtk, or downgrade sqlite?
19:11:18 <adamw> oh for pete's sake
19:11:18 <kalev> new tracker
19:11:28 <adamw> as well as incorrectly claiming it was cancelled, did i also not actually send the announcement for this meeting?
19:11:30 * adamw fails at life
19:11:54 <kparal> adamw: it was all part of that one email :)
19:12:03 <kparal> if that's at least some consolation
19:12:04 <adamw> kparal: nah, i wrote an announcement for this meeting
19:12:13 <adamw> ...which i've just noticed has been sitting here in its composer window all weekend
19:12:14 <adamw> *sigh*
19:12:27 <kalev> anyway, that's all from me, just wanted to bring this up
19:12:30 <kparal> we can vote on FE right now if you prefer
19:12:34 <kalev> sure
19:12:45 <adamw> will the new tracker build include any other change?
19:12:47 <adamw> or just fix this?
19:13:59 <kparal> tracker updates can't make it worse
19:14:04 <kparal> it's an axiom
19:14:05 <kalev> so the reason why we haven't gotten the fix in F27 uet was because in upstream tracker got split into two projects, tracker+tracker-miners, and the fix is in the split release
19:14:21 <kalev> which we haven't gotten in Fedora yet because of the new package process overhead
19:14:51 <kalev> I was thinking of fixing it by just including the new tracker+tracker-miners upstream releases
19:15:01 <adamw> kparal: sure they could. it could eat *both* my cats.
19:15:28 <kparal> adamw: you deserve new ones, no?
19:15:29 <adamw> we generally ask for FE / blocker fixes to be *minimal*
19:15:31 <adamw> haha
19:15:58 <adamw> so...i think i'd probably prefer to vote on this when we have more certainty on what's being proposed to fix it
19:16:02 <adamw> kparal, wdyt?
19:16:20 <kalev> sure, makes sense
19:17:01 <kparal> ok
19:17:31 <adamw> #info kalev's 1484086 looks like a good FE candidate, but we'll delay voting on it till there's a clear fix proposal
19:17:35 <adamw> anything else for open floor?
19:18:04 <kparal> nope
19:18:06 <adamw> oh, one note, i'll be away next week
19:18:11 <adamw> so someone else will need to run the meeting
19:18:23 <adamw> i'll send out a mail about this at some point, and make sure all my stuff is covered
19:18:55 <kparal> good that you mention that. will you be away for one week? I heard something about 3 weeks
19:19:30 <adamw> yep, three weeks. i'll be checking in, though.
19:19:45 <kparal> pschindl will be the adamw impostor, I think
19:19:58 <adamw> for several things, yup
19:20:25 <kparal> 3 weeks, with nobody to reject my blocker proposals
19:20:32 <kparal> not sure how that's going to turn out
19:20:56 <adamw> haha
19:21:00 <adamw> i'll write a bot
19:21:42 <adamw> if blocker.proposed_by('kparal'): irc.write('.fire kparal nope'); blocker.reject(); isolation_device.activate()
19:22:08 <kparal> that could work
19:22:10 <adamw> =)
19:22:18 <adamw> thanks for coming, everyone
19:22:20 * adamw sets fuse
19:24:30 <adamw> see you all at the release party next week! (ahahaha. haha. ha.)
19:24:35 <adamw> #endmeeting