17:00:53 <adamw> #startmeeting F24-blocker-review
17:00:53 <zodbot> Meeting started Mon Feb 15 17:00:53 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:53 <zodbot> The meeting name has been set to 'f24-blocker-review'
17:00:57 <adamw> #meetingname F24-blocker-review
17:00:57 <zodbot> The meeting name has been set to 'f24-blocker-review'
17:01:01 <adamw> #topic Roll Call
17:01:09 <adamw> ahoyhoy folks! who's around for some quick blocker review?
17:01:20 <adamw> only four bugs, shouldn't take long
17:01:37 * kparal is here
17:01:50 * pschindl is here
17:01:59 <adamw> #chair kparal pschindl
17:01:59 <zodbot> Current chairs: adamw kparal pschindl
17:02:07 <pschindl> I'll do the secretarization.
17:02:10 <adamw> thanks pschindl!
17:03:29 <adamw> #topic Introduction
17:03:30 <adamw> Why are we here?
17:03:30 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:03:30 <adamw> #info We'll be following the process outlined at:
17:03:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:03:31 <adamw> #info The bugs up for review today are available at:
17:03:35 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:03:37 <adamw> #info The criteria for release blocking bugs can be found at:
17:03:39 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
17:03:41 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
17:03:43 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
17:03:59 <adamw> #info 3 Proposed Final Blockers
17:04:12 <adamw> #info 2 Proposed Alpha Freeze Exceptions
17:05:40 <adamw> starting with proposed final blockers:
17:05:41 <adamw> #topic (1304681) Journal spam: Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries
17:05:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1304681
17:05:42 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:07:21 <adamw> this seems like kind of a difficult call
17:07:44 <adamw> i'm probably -1 on the idea that log spam breaks 'basic functionality', the CPU usage is a bigger issue
17:08:51 <pschindl> I see this on my working laptop and it causes its fan running all the time. But I don't think it breaks any criterion.
17:09:28 <adamw> i'm gonna propose we punt this on the basis it's a difficult call and we only have a few people today
17:09:47 <tflink> sounds good to me
17:09:54 <pschindl> That seems right to me too
17:10:09 <kparal> I'm afraid we're still not at that point where we can block for battery and fan noise issues
17:10:20 <kparal> so I'd go with -1 I guess, but punt is ok too
17:10:49 <adamw> kparal: i think there's a better argument if it's gonna happen to just about every install
17:11:12 <kparal> that would be a good argument, yes
17:11:16 <pschindl> I think that lot of people would be quite disapointed if we release it with this bug.
17:11:59 <adamw> proposed #agreed 1304681 - punt (delay decision) - this is a difficult judgment call and it's hard to make it with only a few (mostly QA) folks in attendance
17:12:08 <kparal> pschindl: we don't have any criteria for disappointed people, yet ;)
17:12:24 <kparal> ack
17:12:28 <pschindl> ack
17:12:42 <adamw> #agreed 1304681 - punt (delay decision) - this is a difficult judgment call and it's hard to make it with only a few (mostly QA) folks in attendance
17:12:50 <adamw> #topic (1033778) installer considers encrypted Apple Core Storage volumes as resizeable
17:12:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1033778
17:12:50 <adamw> #info Proposed Blocker, python-blivet, NEW
17:13:48 <kparal> adamw: btw have you noticed we have 3 proposed beta blockers as well? it was not mentioned in your summary text
17:14:39 <adamw> kparal: er, really? i checked beta twice and didn't see anything
17:14:53 <adamw> has cmurf been on a proposal spree again
17:14:54 <kparal> adamw: they show up for me
17:14:57 <adamw> i see 'em now, we'll add them
17:15:06 <adamw> damnit, i need breakfast, this is supposed to be a SHORT meeting
17:15:14 <adamw> so, this appears to be another cmurf vs. the anaconda devs bug
17:16:20 <adamw> i'm kinda wary about wading in on it
17:16:46 <pschindl> -1. If anaconda doesn't try to resize it (and by the way destroy the disk), then it is just about wrong information.
17:17:07 <adamw> it does try to resize it and destroy the disk, according to the report.
17:17:12 <adamw> well, the partition.
17:17:25 <kparal> "b. Installer always obliterates all data on the OS X PV when the user chooses the "shrink" option in Reclaim Space."
17:17:38 <kparal> that's kinda bad
17:19:02 <adamw> proposal: we ask the anaconda devs what they think
17:19:12 <kparal> it certainly makes sense to disallow "shrink" for "unknown" filesystem
17:19:14 <adamw> oh goody, i get to talk to the anaconda devs about cmurf again, that's always a fun time
17:19:32 <adamw> kparal: yeah, that seems reasonable to me on the face of it, but i feel like there may be hidden depths here
17:19:37 <adamw> hence why i want to ask the devs
17:19:44 <kparal> please do, and let's punt this
17:19:50 <kparal> I haven't managed to read the whole discussion
17:19:51 <adamw> there's lots of stuff about GUIDs and partition types and lalala
17:20:47 <adamw> proposed #agreed 1033778 - punt (delay decision) - on the face of it we're inclined to agree that this is a blocker, but we suspect there may be hidden depths, so we want to discuss with anaconda devs before making a decision (none present at meeting)
17:21:29 <pschindl> ack
17:21:40 <kparal> ack
17:21:48 <adamw> #agreed 1033778 - punt (delay decision) - on the face of it we're inclined to agree that this is a blocker, but we suspect there may be hidden depths, so we want to discuss with anaconda devs before making a decision (none present at meeting)
17:21:49 <adamw> #topic (1306837) Anaconda's help is broken
17:21:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1306837
17:21:49 <adamw> #info Proposed Blocker, yelp, NEW
17:22:22 <adamw> sure, +1. not sure why the previous report got closed, but if it's still broken in current installer images, +1.
17:22:31 <kparal> ack
17:22:33 <kparal> +1
17:22:42 <pschindl> +1
17:23:06 <adamw> proposed #agreed 1306837 - AcceptedBlocker (Final) - clear violation of "Any element in the installer interface(s) which is clearly intended to display 'help' text must do so correctly when activated."
17:23:26 <pschindl> ack
17:24:37 <kparal> ack
17:24:49 <adamw> #agreed 1306837 - AcceptedBlocker (Final) - clear violation of "Any element in the installer interface(s) which is clearly intended to display 'help' text must do so correctly when activated."
17:24:58 <adamw> #topic (1306462) _ped.PartitionException: Unable to satisfy all constraints on the partition.
17:24:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1306462
17:24:58 <adamw> #info Proposed Blocker, anaconda, NEW
17:26:04 <adamw> hmm
17:26:10 <adamw> "Crashes after accepting reclaim space"
17:26:20 <adamw> the criterion does not apply to shrinking, it applies to a disk with literal empty unpartitioned space
17:26:46 <adamw> "Reject or disallow invalid disk and volume configurations without crashing." might get it through, but i'd like a bit more detail
17:26:58 <kparal> we need devs response first
17:28:24 <kparal> punt and ping anaconda?
17:29:07 <adamw> proposed #agreed 1306462 - punt (delay decision) - it's not clear precisely what the reporter did here (he cites the "unpartitioned space" criterion but refers to "reclaim space" also), thus we'd like more details and a developer response before making a determination
17:29:33 <kparal> ack
17:29:43 <pschindl> ack
17:30:47 <adamw> #agreed 1306462 - punt (delay decision) - it's not clear precisely what the reporter did here (he cites the "unpartitioned space" criterion but refers to "reclaim space" also), thus we'd like more details and a developer response before making a determination
17:31:02 <adamw> oh, sorry, should have mentioned - we're on Beta blockers now.
17:31:07 <adamw> that last one was proposed beta, so are the next two
17:31:08 <adamw> topic (1306808) blivet.errors.FSError: mount failed: 32
17:31:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1306808
17:31:08 <adamw> #info Proposed Blocker, anaconda, NEW
17:31:11 <adamw> grrr
17:31:12 <adamw> #undo
17:31:12 <zodbot> Removing item from minutes: INFO by adamw at 17:31:08 : Proposed Blocker, anaconda, NEW
17:31:16 <adamw> #undo
17:31:16 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f20c36a4fd0>
17:31:23 <adamw> #topic (1306808) blivet.errors.FSError: mount failed: 32
17:31:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1306808
17:31:23 <adamw> #info Proposed Blocker, anaconda, NEW
17:31:55 <kparal> this seems +1
17:32:51 <adamw> eh
17:33:03 <adamw> i wish cmurf would explain *exactly what he actually did* instead of leaving us to infer it
17:33:19 <adamw> this seems like he created a completely empty btrfs volume outside of the installer then tried to install to it?
17:33:23 <adamw> or something? he really doesn't explain
17:33:50 <kparal> so let's ask for a proper reproducer and developer feedback?
17:34:48 <adamw> the 'possible dupe' has a lot of other people hitting the same crash
17:35:03 <adamw> so there's clearly something bad in that bit of blivet, but i'm not sure we understand exactly what it is yet
17:35:25 <adamw> still, given the volume of people in 1253481 i'm actually inclined to +1 this on the 'reject invalid...without crashing' criterion
17:37:09 <adamw> votes? +1 or punt?
17:37:13 <kparal> punt
17:37:48 <pschindl> punt
17:38:28 <adamw> ok then
17:39:05 <adamw> proposed #agreed 1253481 - punt (delay decision) - this seems a strong candidate as there are many people hitting the 'potential dupe' bug, but reporter did not explain precisely what he actually did, we need that clarified to make a decision
17:39:23 <pschindl> ack
17:39:40 <kparal> ack
17:39:48 <adamw> #agreed 1253481 - punt (delay decision) - this seems a strong candidate as there are many people hitting the 'potential dupe' bug, but reporter did not explain precisely what he actually did, we need that clarified to make a decision
17:39:54 <adamw> #topic (1259865) call `dnf mark install <pkgs...>`on packages installed from PK
17:39:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259865
17:39:54 <adamw> #info Proposed Blocker, PackageKit, NEW
17:40:46 <kparal> you might want to see comment 29-30 first for some trivial reproducer
17:41:09 <kparal> and in comment 25 dnf developers are raising the priority for this
17:41:20 <kparal> there's a lot of dupes for it
17:41:56 <kparal> basically anything you update with packagekit might get removed by dnf at any point, if nothing else depends on it
17:42:11 <kparal> even important system packages
17:42:33 <adamw> does this affect things updated with Software?
17:42:37 <kparal> yes
17:42:39 <adamw> if so we might perhaps take it under "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops. "
17:42:46 <adamw> still, that's a stretch...
17:43:05 <kparal> the issue is the combination of using two different package managers
17:43:12 <adamw> yeah
17:43:13 <kparal> we don't have a direct criterion for it
17:43:20 <adamw> well, we could cite the two together
17:43:22 <kparal> but it can break the default app functionality :0
17:43:31 <adamw> (alpha has "install using CLI tool")
17:43:38 <kparal> that's true
17:43:42 <adamw> autoremove kicks in when you run 'dnf update'?
17:43:57 <adamw> or does it have to be explicitly run?
17:44:00 <kparal> by default, it kicks in for any operation that removes something, I believe
17:44:07 <adamw> hmm, ok
17:44:12 <adamw> i think i can go +1 on that basis
17:44:15 <adamw> pschindl? tflink?
17:44:33 <kparal> certainly dnf remove, not sure about update
17:45:28 <pschindl> +1
17:45:37 <adamw> i thought i had a todo item to require basic package manipulation (not just updates) to work safely, sigh
17:46:03 <kparal> but it's easy to imagine a situation where you update e.g. libreoffice using gnome-software, and then remove libreoffice-latex plugin and it takes away whole libreoffice
17:46:09 <kparal> that is still a safe example
17:46:14 <kparal> it might get worse
17:46:33 <adamw> kparal: yeah, problem is the criteria don't explicitly cover anything but updates anywhere
17:46:50 <adamw> we don't technically require that package install or removal works, or doesn't explode your system, without a bit of criteria judo
17:46:53 <adamw> still, let's fudge it for now
17:46:59 <kparal> I pinged hughsie about this and he said he thinks kalev already fixed it, but it's not stable yet
17:47:25 <adamw> proposed #agreed 1259865 - AcceptedBlocker (Beta) - we held that this violates the combination of "The installed system must be able to download and install updates with the default console package manager." (Alpha) and "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." (Beta) as it's believed that doing the former after the latter could lead to the rem
17:47:25 <adamw> oval of critical packages
17:47:27 <adamw> grr
17:47:33 <adamw> proposed #agreed 1259865 - AcceptedBlocker (Beta) - we held that this violates the combination of "The installed system must be able to download and install updates with the default console package manager." (Alpha) and "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." (Beta) as it's believed that doing the former after the latter could remove critical
17:47:33 <adamw> packages
17:47:35 <adamw> grrrr
17:47:51 <adamw> proposed #agreed 1259865 - AcceptedBlocker (Beta) - we hold this violates combination of "The installed system must be able to download and install updates with the default console package manager." (Alpha) and "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." (Beta) as it's believed that doing the former after the latter could remove critical packages
17:47:53 <adamw> there.
17:47:55 <kparal> one has to love irc
17:48:17 <kparal> ack
17:48:25 <tflink> +1 and ack
17:48:35 <adamw> #agreed 1259865 - AcceptedBlocker (Beta) - we hold this violates combination of "The installed system must be able to download and install updates with the default console package manager." (Alpha) and "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." (Beta) as it's believed that doing the former after the latter could remove critical packages
17:48:53 <adamw> ok, just a couple of alpha proposed FEs to finish on
17:49:00 <adamw> #info Alpha FEs
17:49:04 <adamw> #topic (1299210) No initial-setup on Fedora Rawhide 20160115 (qemu-kvm)
17:49:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1299210
17:49:04 <adamw> #info Proposed Freeze Exceptions, initial-setup, MODIFIED
17:49:48 <adamw> +1
17:49:56 <adamw> this could actually be blocker if it affects ARM disk image
17:50:00 <adamw> but +1 FE for sure
17:50:39 <kparal> we're not yet frozen, is there any reason to go through FEs?
17:50:43 <kparal> +1 sure
17:50:46 <adamw> hmm, point
17:50:49 <adamw> i'm all for ending the meeting
17:50:54 <adamw> anyone really want to do 'em?
17:51:04 <kparal> don't shout all at once :)
17:51:24 <adamw> #info actually, we're not frozen for a while, so let's skip FEs for now
17:51:35 <adamw> #topic Open floor
17:51:39 <adamw> any other blocker-related business?
17:51:44 <kparal> wheeeee
17:51:47 <kparal> nope
17:51:48 * adamw lights the blue touch paper
17:52:37 <adamw> thanks for coming out and punting everything, folks ;)
17:52:43 <kparal> :D
17:52:43 <adamw> #endmeeting