16:02:11 <adamw> #startmeeting F24-blocker-review
16:02:11 <zodbot> Meeting started Mon Apr 25 16:02:11 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:11 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:11 <adamw> #meetingname F24-blocker-review
16:02:11 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:11 <adamw> #topic Roll Call
16:02:14 <nb> .hello nb
16:02:15 <zodbot> nb: nb 'Nick Bebout' <nb@nb.zone>
16:02:17 <adamw> who's around to review some blockers?
16:02:19 <adamw> hi nick!
16:02:24 <nb> hi adam!
16:02:39 * kparal is here
16:02:53 <adamw> anyone in yelling distance of mbriza by any chance?
16:03:08 <adamw> since we have a metric elephant of live media writer bugs
16:03:18 <kparal> but most of them fixed ;)
16:03:21 <adamw> yaay fixed
16:03:28 <kparal> he worked really hard in the last few days
16:04:10 <kparal> I might unpropose the Windows-related ones?
16:04:21 * pschindl is here
16:04:22 <adamw> hmm, no
16:04:33 <adamw> we *have* considered windows luc issues blockers in the past and i think that was the intent
16:04:42 <adamw> even though fedora doesn't supply the tool, it is one of the recommended mechanisms
16:04:52 <adamw> so let's kick it over at least
16:04:59 <adamw> the *other* windows tools we recommend aren't written by fedora either =)
16:06:29 <kparal> that's true, but we wouldn't block on them I guess
16:07:39 <jkurik> adamw: there is a statement from maintainer about LUC blocking F24: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q3QF5VTMHMV2YDEGL4LZXZ5UGBD746ZF/
16:08:04 <adamw> okay, fair enough
16:09:01 * adamw doesn't want to battle fuzzy process issues of whether we make a bug a blocker in order to make sure we 'downgrade' the docs and so on to point to the old luc...
16:09:46 <adamw> alrighty, seems like long enough
16:09:46 <kparal> ugh
16:09:58 <adamw> #chair kparal jkurik nb
16:09:58 <zodbot> Current chairs: adamw jkurik kparal nb
16:11:58 * cmurf is in vicinity
16:12:00 <adamw> #topic Introduction
16:12:00 <adamw> Why are we here?
16:12:00 <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:12:00 <adamw> #info We'll be following the process outlined at:
16:12:01 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:02 <adamw> #info The bugs up for review today are available at:
16:12:04 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:06 <adamw> #info The criteria for release blocking bugs can be found at:
16:12:10 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:12:12 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:12:14 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:12:16 <adamw> hiya cmurf
16:12:24 <kparal> pschindl: secretary volunteer, hm? :)
16:12:37 <cmurf> mister williamson
16:12:40 <adamw> yeah i think i see pschindl volunteering
16:12:57 <adamw> there's definitely a volunteer-y look about his packets
16:13:20 <pschindl> oook
16:13:38 <cmurf> pschindl you just walked right into that one
16:13:45 <adamw> fedora 'volunteering' works a lot like the army
16:13:55 <adamw> #info pschindl will secretarialize
16:13:56 <cmurf> conscription
16:14:29 <adamw> for beta, we have:
16:14:29 <adamw> #info 8 Proposed Blockers
16:14:30 <adamw> #info 2 Accepted Blockers
16:14:30 <adamw> #info 3 Proposed Freeze Exceptions
16:14:30 <adamw> #info 4 Accepted Freeze Exceptions
16:14:47 <adamw> #info we also have 4 Proposed Blockers for Final
16:14:50 <adamw> dunno if we'll make it there
16:15:04 <jkurik> most of the proposed are fixed
16:15:08 <adamw> some of those may be windows luc bugs, we'll burn those bridges as we come to 'em
16:15:11 <adamw> let's just get rolling
16:15:16 <adamw> #topic (1322909) docker-1.10.3-3.gitd93ee51.fc24 fails to run anything
16:15:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1322909
16:15:17 <adamw> #info Proposed Blocker, docker, NEW
16:15:24 <adamw> i believe sgallagh is investigating this one
16:15:29 <cmurf> nasty little bug
16:15:53 <adamw> so my take on this is i'd be +1 blocker if the bug affects updates of Beta installs (i.e. as soon as you get a docker package update, docker stops working)
16:15:59 <cmurf> looks like once you hit it, it's nerfing the thin pool (?) because going back to the fixed version doesn't fix the problem
16:16:05 <adamw> if that's not the case and it's only updates from some random docker build from last week that fail, i'm -1
16:16:11 * pwhalen is here
16:16:25 <adamw> since we can't do anything sensible by blocking the beta release anyway, as people who already have f24 get packages from u-t
16:16:54 <cmurf> doesn't FE fix this?
16:17:16 <kparal> what criterion is this under?
16:17:21 <cmurf> there is a fix if you haven't hit the bug already
16:17:22 <adamw> no, afaict it'd be entirely pointless, if the bug is about updates of installed systems, especially if it's about updates from some build *we've already put out*
16:17:45 <adamw> kparal: er, good question? i kinda thought we had a 'docker docker docker' criterion but amazingly it seems we don't
16:17:48 <adamw> we probably should, though.
16:18:04 <adamw> at least Server and Cloud should be able to...docker.
16:18:04 <kparal> does Server depend on this?
16:18:11 <cmurf> no
16:18:26 <cmurf> my understanding of the bug is there is a new version that doesn't have the problem
16:18:29 <adamw> i don't *think* so
16:18:46 <adamw> cmurf: i'm not sure if we know 100% yet, since we don't have a -6 build to test updating from -5 to?
16:18:50 <adamw> but my *guess* is that that's the case
16:18:56 <pwhalen> but we dont know about upgrading to the next .. right :)
16:19:32 <RaphGro> .hello raphgro
16:19:33 <adamw> still, given that afaik we don't actually have any criteria that cover this...
16:19:33 <zodbot> RaphGro: raphgro 'Raphael Groner' <projects.rg@smart.ms>
16:19:39 <RaphGro> sorry, been away for dinner.
16:19:41 <cmurf> i think the bug is in docker-1.10.3-3
16:19:45 <adamw> i'm gonna say i'm -1 with an option to re-evaluate if it turns out updates from -5 are affected
16:19:53 <adamw> cmurf: that's what it *seems* like, but i don't wanna say it for sure
16:20:07 <adamw> and i'm also gonna suggest we have some docker criteria =)
16:20:27 <adamw> #action adamw to propose docker criteria
16:20:46 <pschindl> I'm also -1
16:20:50 <cmurf> atm i'm -1 blocker and +1 fe
16:20:52 <pwhalen> i think -1 blocker, +1 FE to pull in -5
16:21:01 <adamw> i don't see the point of FE
16:21:05 <adamw> this is an *update* issue
16:21:09 <adamw> f24 installs pull updates from u-t anyway
16:21:11 <adamw> what does an FE solve?
16:21:18 <adamw> or is -5 not stable yet?
16:21:41 <adamw> -5 is not stable but -4 is
16:21:55 <adamw> if -4 is affected by the bug i'd be +1 FE so we don't cause the bug to hit people installing images that include docker, but...
16:22:31 <cmurf> adamw i understand now, -3 is obsolete -4 is stable, and so far only -3 seems adversely affected
16:22:34 * adamw re-reads sgallagh's comment
16:22:35 <pwhalen> -4 is also affected in my testing
16:22:48 <adamw> pwhalen: what do you mean by 'affected'
16:23:01 <adamw> you install with -4 and it fails? you install with -4 and update to -5 and it fails? you install with -3 and update to -4 and it fails? what?
16:23:02 <pwhalen> meaning, -4 to -5 i hit it
16:23:08 <adamw> huh, sgallagh said the opposite.
16:23:11 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1322909#c21
16:23:12 <cmurf> pwhalen did you ever have -3?
16:23:29 <cmurf> once you have the problem, you have to remove and recreate the thin pool
16:23:39 <pwhalen> cmurf, no just -4 when i started to see it
16:23:44 <cmurf> huh
16:24:02 <adamw> if you could re-test, though, that would be good.
16:24:14 <pwhalen> for sure
16:24:26 <pwhalen> im doing the latest nightly now, so will get to it shortly
16:24:30 <adamw> ok
16:24:40 <adamw> so yeah, i think i'm -1-but-monitor on this one
16:24:43 <cmurf> easiest is to use dmsetup to remove the thin pool and reboot, docker-storage-setup should create a new pool
16:24:43 <adamw> anyone wanna argue +1 or punt?
16:24:52 <cmurf> no punt need more info
16:26:22 <adamw> any other votes?
16:26:34 <kparal> -1
16:28:18 <adamw> i think everyone else fell asleep
16:28:44 <adamw> i kinda was hoping for more votes, but we also need to move along, it's been 13 minutes on this bug
16:28:46 <adamw> so
16:28:50 * jkurik do not understand the issue enough to vote
16:29:27 <adamw> proposed #agreed 1322909 - RejectedBlocker - this is rejected for now as sgallagh's testing indicates the current stable package is not affected and there are no docker criteria in any case, but it may be re-evaluated if the bug affects -4 and we add docker criteria as proposed
16:29:56 <adamw> cmurf: vote is 2 to 1 so i dunno what else to do :)
16:30:23 <Amita> I joined late, otherwise I would have voted
16:30:31 <cmurf> ? i already voted -1
16:31:00 <kparal> ack
16:31:05 <cmurf> ack
16:31:08 <adamw> cmurf: oh, sorry, i thought you voted punt
16:31:13 <adamw> hi amita
16:31:20 <Amita> hello
16:31:25 <cmurf> well -1 and punt as if they aren't in conflict
16:31:34 <cmurf> so that's -1 or punt, whichever carries
16:31:39 <adamw> i see, gotcha
16:31:44 <adamw> #agreed 1322909 - RejectedBlocker - this is rejected for now as sgallagh's testing indicates the current stable package is not affected and there are no docker criteria in any case, but it may be re-evaluated if the bug affects -4 and we add docker criteria as proposed
16:32:32 <adamw> #topic (1314494) knode has unmet dependencies during dnf system-upgrade to f24
16:32:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1314494
16:32:32 <adamw> #info Proposed Blocker, kdepim, ON_QA
16:32:53 <adamw> this would be a 0DayBlocker i believe
16:32:58 <adamw> if i remember our terms right :)
16:33:14 <cmurf> neato
16:33:14 * kparal forgot
16:33:31 <adamw> Accepted0Day
16:33:51 <kparal> yes
16:33:53 <adamw> so i'm about +0.5 to this since we *could* document the workaround, but hey.
16:34:19 <kparal> but it has to be in the default installation set, right?
16:34:21 <cmurf> does FE cover it?
16:34:55 <jkurik> it seems to be already fixed, so I am +1 for FE
16:35:20 <kparal> if knode is installed by default from a KDE Live, +1 blocker
16:36:36 <adamw> it's installed by default in an f23 KDE live
16:36:54 <adamw> cmurf: FE would solve the problem since we have a fix
16:37:41 <cmurf> ok well I'm +1 to fixing it, FE if that does it and blocker if it's installed by default in KDE
16:37:48 <adamw> we don't really allow workarounds in the criterion, so i guess i'm +1 blocker again
16:37:55 <adamw> yes it is default in kde
16:38:26 <adamw> that's +3 i think, so:
16:38:53 <adamw> proposed #agreed 1314494 - AcceptedBlocker (Beta) - this is a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." for the KDE package set
16:39:03 <cmurf> ack
16:39:07 <kparal> ack
16:39:19 <kparal> pschindl: tag it with Accepted0Day, not AcceptedBlocker
16:39:34 <pschindl> kparal: ok
16:39:39 <pschindl> ack
16:39:44 <kparal> (btw does blocker bugs app track those?)
16:40:03 <adamw> depends if tflink updated the deployment yet
16:40:07 <jkurik> ack
16:40:34 <adamw> looks like he didn't, so...no, not yet, it will probably still list this in Proposed until that happens
16:40:56 <adamw> kparal: https://phab.qadevel.cloud.fedoraproject.org/D689 is the fix, it's merged, but not deployed.
16:41:27 <kparal> tflink: ^^
16:41:28 <adamw> #agreed 1314494 - AcceptedBlocker (Beta) - this is a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." for the KDE package set
16:41:56 <adamw> #topic (1328369) Luc doesn't reuse already downloaded image and stuck
16:41:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1328369
16:41:56 <adamw> #info Proposed Blocker, liveusb-creator, VERIFIED
16:42:58 <adamw> i'm +1 FE for this one
16:43:21 <RaphGro> interrupting question: is there time to vote for final blockers, today?
16:43:36 <adamw> RaphGro: not sure yet, we'll get through beta then see
16:43:37 <kparal> we can probably avoid discussing whether it's a blocker or not, we just need to push it stable in all branches
16:43:42 <tflink> adamw: i can get it into staging and request a freeze break if it works there
16:43:53 <adamw> RaphGro: if you're just waiting for one of those we can ping you if we get to them
16:44:22 <RaphGro> adamw, okay. thanks. the bug I filed for l10n of comps.
16:44:26 <cmurf> Can we clear all the LUC bugs from block proposal on the basis it can't block release since it's not the primary deliverable anymore?
16:44:37 <adamw> cmurf: it doesn't need to be in order to block the release.
16:44:42 <adamw> the criterion is not about 'primary deliverables'
16:44:51 <adamw> the criterion is about recommended USB writing tools
16:45:03 <cmurf> oh it's the supported media creation method thing
16:45:11 <cmurf> foop
16:45:12 <kparal> let's give it +1 FE and leave the blocker status undecided
16:45:18 <adamw> "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
16:45:28 <jkurik> kparal: +1
16:45:32 <adamw> kparal: to be clear i'm -1 blocker, this does not violate the criterion for me
16:45:32 <pwhalen> +1 FE
16:45:33 <adamw> but +1 FE
16:45:41 <kparal> adamw: why not?
16:45:50 <adamw> because the tool can write the image to a stick.
16:45:56 <kparal> only once
16:46:10 <kparal> if you want to write two of them, it will not work
16:46:28 <adamw> ONE USB STICK SHOULD BE ENOUGH FOR ANYBODY damnit
16:46:29 <kparal> if you download it and quit it, and then start it again, it will not work
16:46:30 <adamw> :P
16:46:41 <adamw> ok, i didn't realize it was that bad, but i'm fine with just +1 FE for now
16:46:47 <adamw> it'll get pushed and we can stop worryingh
16:46:47 <kparal> ok
16:46:58 <adamw> where are we with stable releases? do they have enough karma?
16:47:01 <kparal> we can discuss at go/no-go if it's not still pushed by then
16:47:12 <kparal> mbriza keeps updating them
16:47:16 <kparal> so the karma gets reset
16:47:22 <adamw> ah k
16:47:22 <cmurf> +1 FE
16:47:27 <adamw> so yeah, let's keep it there
16:47:48 <kparal> and fc23 does not have the latest version, damn
16:48:20 <kparal> anyway, we will encounter more serious issues
16:48:33 <adamw> proposed #agreed 1328369 - AcceptedFreezeException (Beta) - this is clearly bad enough to merit a freeze exception. We are undecided on blocker status for now, will re-evaluate at Go/No-Go if it is not pushed stable for all releases by then
16:48:34 <pschindl> +1 FE
16:48:36 <kparal> this is not the one that will slow us down
16:48:39 <adamw> ok
16:48:41 <kparal> ack
16:48:42 <pwhalen> ack
16:48:42 <pschindl> ack
16:48:46 <adamw> #agreed 1328369 - AcceptedFreezeException (Beta) - this is clearly bad enough to merit a freeze exception. We are undecided on blocker status for now, will re-evaluate at Go/No-Go if it is not pushed stable for all releases by then
16:49:12 <adamw> #topic (1328484) liveusb-creator on Windows 10 opens diskpart.exe but does nothing
16:49:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1328484
16:49:12 <adamw> #info Proposed Blocker, liveusb-creator, VERIFIED
16:49:17 <adamw> this is windows-specific?
16:49:20 <kparal> yes
16:49:28 <kparal> and fixed in the latest version
16:49:35 <kparal> which doesn't go through bodhi, so "live"
16:49:43 <kparal> however, there is still no official location
16:49:48 <adamw> right, it kinda depends what the docs point to
16:49:49 <kparal> so hard to say "live" :)
16:50:01 <adamw> yeah...
16:50:07 <cmurf> it's not mentioned in docs, it's not supported at all near as i can tell
16:50:10 <kparal> currently at https://mbriza.fedorapeople.org/liveusb-creator.zip
16:50:13 <cmurf> so i'd say -1
16:50:16 <adamw> but still, so far as this bug is concerned it can be closed, right?
16:50:19 <adamw> i'd say close the bug
16:50:29 <adamw> documentation issues can be dealt with separately (i.e. file a bug on me or something)(
16:50:30 <cmurf> even better
16:50:37 <kparal> I'll verify tomorrow with the very machine that we observed this bug on
16:50:38 <adamw> though we should consider the non-wiki docs too
16:50:42 <kparal> but on my windows it worked
16:51:05 <kparal> so probably we can close, yes
16:51:56 * kparal will close this, we can carry on
16:52:09 <adamw> #info no evaluation needed for #1328484 as bug is considered resolved
16:52:18 <adamw> #topic (1328498) partitions are not unmounted before writing image to a device, can lead to corrupted data written
16:52:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1328498
16:52:18 <adamw> #info Proposed Blocker, liveusb-creator, VERIFIED
16:52:48 <kparal> fixed in latest versions, not stable yet (any branch)
16:53:51 <kparal> the partitions were not unmounted prior to dd, which can lead to corruption when you eject the stick in nautilus, leading to unmounting partitions
16:54:02 <cmurf> yup, so does it need a FE
16:54:05 <adamw> i'm +1 PreviousRelease for this
16:54:06 <cmurf> ?
16:54:14 <cmurf> ok intersting
16:54:16 <kparal> it affects all releases
16:54:27 <adamw> an interesting thought occurs: can it be both AcceptedBlocker and AcceptedPreviousRelease...
16:54:32 <kparal> +1 FE for f24, AcceptedPreviousRelease for f22/f23?
16:54:35 <adamw> well, we can try it and see :)
16:54:47 <kparal> we can skip AcceptedBlocker same as we did last time
16:54:56 <kparal> and discuss at go/no-go if stil relevant
16:54:57 <adamw> well, this one is more serious
16:55:04 <adamw> but yeah, OK
16:55:07 <kparal> ok, if you say so :)
16:55:11 <adamw> for me anyhow =)
16:55:29 <adamw> my gut says more people would hit this one
16:55:45 * kparal can't estimate
16:55:46 <cmurf> ok so you're saying for beta release purposes, use previous release rather than push a new hopefully fixed version
16:55:57 <adamw> my gut also says that guy doesn't fit the profile of our killer, we're looking for someone...subtler
16:56:03 <kparal> I reproduced this only when willingly copying something to the stick after it was written by FMR
16:56:03 <adamw> cmurf: no.
16:56:17 <adamw> AcceptedPreviousRelease means that the fix must be pushed stable for a previous release before we will allow the Beta to go out.
16:56:19 <kparal> but I saw similar "random" issues in the past even with dd, when I forgot to unmount partitions
16:56:31 <adamw> i.e. this has to be pushed to F22 and F23
16:56:33 <cmurf> oh i see
16:56:36 <adamw> kparal: yeah, me too
16:56:37 <cmurf> previous release of Fedora, not the tool
16:56:43 <adamw> right.
16:56:55 <adamw> it's one of the two new blocker types, along with Accepted0Day.
16:57:07 <adamw> the ones we used to call 'special blockers' and handwave
16:57:15 <cmurf> +1 PR
16:57:21 <adamw> ooh, PR, I like that.
16:57:23 <cmurf> bonus handwave
16:57:25 <kparal> :D
16:58:06 <kparal> +1 PR, +1 FE, +1 blocker if we want to vote on that
16:58:26 <kparal> not sure if blocker bugs app won't go crazy after this
16:59:11 <adamw> proposed #agreed 1328498 - AcceptedPreviousRelease (22 and 23), AcceptedFreezeException (Beta) - this violates "All release-blocking images must boot in their supported configurations." (with the footnote about USB media) for F22 and F23. we may also consider it serious enough to be an F24 Beta blocker if not pushed stable by go/no-go, but it is at least freeze exception-worthy for now
16:59:23 <adamw> kparal: i *think* it should handle it. we'll see. =)
16:59:33 <cmurf> ack
16:59:47 <jkurik> ack
16:59:57 <adamw> pschindl: so you'd leave it blocking both BetaBlocker and BetaFreezeException and add both whiteboard tags
17:00:44 <cmurf> revolver based bug tagging
17:00:47 <pschindl> ack
17:00:56 <kparal> ack
17:00:56 <adamw> cmurf: chaingun-based
17:01:01 <adamw> #agreed 1328498 - AcceptedPreviousRelease (22 and 23), AcceptedFreezeException (Beta) - this violates "All release-blocking images must boot in their supported configurations." (with the footnote about USB media) for F22 and F23. we may also consider it serious enough to be an F24 Beta blocker if not pushed stable by go/no-go, but it is at least freeze exception-worthy for now
17:01:03 <pschindl> adamw: ok
17:01:20 <adamw> #topic (1329532) liveusb-creator on Windows 10 doesn't write image
17:01:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329532
17:01:21 <adamw> #info Proposed Blocker, liveusb-creator, VERIFIED
17:01:23 <cmurf> adamw: whoa you are violent
17:01:25 <adamw> is this different from the other one?
17:01:41 <kparal> the same situation. I tested on my home machine, will test tomorrow on an office machine
17:01:43 <kparal> can be closed
17:02:41 <cmurf> close the bug ship the beta
17:02:43 <kparal> it's a different bug, but same status for us
17:03:08 <adamw> ok
17:03:36 <adamw> #info as with 1328484, this is believed resolved in current version of Windows build, no evaluation required
17:03:47 <adamw> #topic (1329608) missing deps on F22
17:03:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329608
17:03:47 <adamw> #info Proposed Blocker, liveusb-creator, ASSIGNED
17:03:58 <adamw> thanks for being on top of all these, kparal
17:04:32 <kparal> well I reported most of these in the last few days, I'm very familiar with them :)
17:05:46 <adamw> looks like a clear PR
17:05:47 <adamw> +1 PR
17:05:50 <adamw> PR PR PR
17:06:01 <kparal> there is a catch, though
17:06:28 <cmurf> sure +1 PR
17:06:28 <kparal> some of those missing deps might not manifest on a fully updated system, but will do on an non-updated system
17:06:37 <kparal> does it still block in that case?
17:07:07 <kparal> currently it's a mixed bag, but after some fixed it might end up in the situation I described
17:07:22 <kparal> there seems to be some issue with mixing qt5 libraries of different version
17:07:36 <kparal> s/fixed/fixes
17:08:05 <kparal> +1 PR now, sure
17:08:21 <adamw> mmm, if updating to latest f22 is enough to go away i'd be -1 beta blocker i think
17:08:36 <adamw> the deps should be correct but i don't think it's serious enough to block beta on in that case
17:08:51 <kparal> ok, so depending on the fixes we might drop the status if that happens
17:10:00 <jkurik> I am -1 to block on this, PR looks like +1
17:10:15 <adamw> uh, PR *is* blocking.
17:10:28 <adamw> kparal: or split the bugs? either way.
17:10:51 <kparal> currently the deps are broken everywhere, so +1 PR is I believe correct
17:11:14 <jkurik> is it ?
17:11:17 <jkurik> ah
17:11:18 <kparal> if they fix it in such a way that updated systems are fine and outdated ones are not, I can move it back to proposed state
17:11:37 <adamw> jkurik: AcceptedPreviousRelease means we would block the Beta release if this was not fixed in F22 stable on the go/no-go day.
17:12:02 <jkurik> ok, ok
17:12:04 <cmurf> right so is it an important enough fix for F22/23 to block on
17:12:11 <cmurf> or per criterion
17:13:19 <cmurf> maybe FE is sufficient?
17:13:26 <adamw> that means nothing
17:13:30 <adamw> there is no freeze on f22 updates
17:13:33 <cmurf> how does that even work though for a previous release?
17:13:35 <adamw> nothing to be excepted from
17:13:45 <adamw> PR is the only status which would mean anything
17:13:53 <cmurf> how bad is the breakage?
17:13:59 <adamw> well, it's a *graphical* tool
17:14:02 <cmurf> i mean it's a beta, we've said that before, with a handwave
17:14:13 <adamw> if you don't happen to have python-urlgrabber installed it'd just crash mysteriously on startup
17:14:31 <cmurf> well
17:14:32 <adamw> ok, maybe you get an abrt crash notification and if you're really advanced maybe you'd look at the traceback in that and figure out what was wrong, but...it's not great
17:15:23 <jkurik> adamw: that looks too complicated
17:15:37 <cmurf> why can't F22/F23 just use the previous stable release of LUC for beta then?
17:15:53 <adamw> that would be a valid resolution to this bug, if we wanted to go that way.
17:16:14 <kparal> actually old LUC is still in stable, to make this more complicated
17:16:20 <adamw> oh...okay.
17:16:21 <adamw> hmm.
17:16:25 <kparal> the new LUC never made it to stable updates
17:16:25 <cmurf> well i don't want to hold up release for one tool that's undergoing a major rewrite that isn't strictly required to test beta
17:16:29 <adamw> so this only happens if you install the new one from u-t?
17:16:34 <kparal> yes
17:16:52 <cmurf> ok then give it negative karma so it doesn't go out or whatever needs to be done
17:16:54 <adamw> and the version that's now queued for stable is not affected by the urlgrabber issue?
17:16:56 <kparal> but as it was a primary deliverable, I never considered not having it in stable by Beta
17:16:59 <adamw> in that case, changing to -1
17:17:03 <cmurf> yeah -1
17:17:30 <kparal> hmm, I guess
17:17:39 <kparal> but we didn't actually test the old LUC
17:17:51 <cmurf> ruhroh
17:17:53 <adamw> then let's do that =)
17:17:58 <cmurf> yesa
17:17:59 <adamw> but anything broken in it won't be this bug
17:18:07 <kparal> oh man
17:18:09 <cmurf> haha
17:18:28 <adamw> proposed #agreed 1329608 - RejectedBlocker (Beta) - the affected luc never reached stable for F22, so this bug does not violate the criteria
17:18:34 <cmurf> just when you thought that you'd flicked the old one off
17:18:43 <adamw> we can still just push the new one stable
17:18:46 <adamw> there is no freeze
17:18:53 <cmurf> righto
17:18:59 <kparal> ack
17:19:02 <cmurf> ack
17:19:03 <adamw> so let's test it and get it out there
17:19:08 <adamw> #agreed 1329608 - RejectedBlocker (Beta) - the affected luc never reached stable for F22, so this bug does not violate the criteria
17:19:17 <adamw> #topic (1329611) no image written on F22
17:19:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329611
17:19:17 <adamw> #info Proposed Blocker, liveusb-creator, ASSIGNED
17:19:19 <adamw> similar case i guess?
17:19:25 <kparal> same case
17:19:29 <adamw> ok then, same vote
17:19:38 <kparal> but it's also the same case for the one bug we already accepted as PR
17:19:57 <adamw> proposed #agreed 1329611 - RejectedBlocker (Beta) - the affected luc never reached stable for F22, so this bug does not violate the criteria
17:20:00 <adamw> ...goddamnit it
17:20:05 <kparal> 1328498
17:20:09 <adamw> let's just pretend that never happened and it'll all work out in the wash
17:20:15 <kparal> ack
17:20:17 <cmurf> ack
17:20:20 <adamw> after this meeting we're all going to goddamn well karma the f22 package
17:20:28 <adamw> =)
17:20:41 <kparal> adamw: the f22 issues are not fixed yet
17:20:44 <adamw> #agreed 1329611 - RejectedBlocker (Beta) - the affected luc never reached stable for F22, so this bug does not violate the criteria
17:20:51 <adamw> okay, amendment
17:20:59 <adamw> after this meeting we're all going to drink heavily and switch to openSUSE
17:21:07 <kparal> ack
17:21:12 <adamw> =)
17:21:33 <adamw> last one out of fedora, please turn off the lights
17:21:43 <RaphGro> -.-
17:21:50 <adamw> OK, moving onto proposed freeze exceptions
17:22:03 <adamw> #topic (1327615) Incorrect subnet mask shown in network spoke
17:22:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1327615
17:22:03 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:22:06 <cmurf> adamw: no because they support hibernation so you'd probably pull out that chaingun you keep under your bed
17:22:15 <adamw> cmurf: that's fine, it's not my job to fix it
17:22:16 <adamw> :P
17:22:48 <cmurf> haha you have two responses for everything
17:23:04 <adamw> .fire garretraziel adium? srsly?
17:23:04 <zodbot> adamw fires garretraziel adium? srsly?
17:23:11 <RaphGro> -1, fix is available.
17:23:37 <adamw> i think i'm inclined to leave this alone at this point
17:23:42 <RaphGro> two weeks should be enough to get it as an update into repo, no?
17:23:45 <adamw> doesn't seem serious enough to merit a new anaconda build
17:23:48 <adamw> RaphGro: uh. what?
17:23:50 <adamw> it's an anaconda bug.
17:23:57 <RaphGro> (1327615)
17:23:59 <adamw> sending it out as an update fixes nothing, and we don't have two weeks.
17:24:07 <garretraziel> adamw: yes, that's how eager am I to be on this meeting
17:24:11 <RaphGro> oh, well. then I'm unsure.
17:24:32 <RaphGro> is there a test case?
17:24:34 <kparal> but if we have another anaconda blocker, we can pull this in?
17:24:47 <kparal> so +1 FE doesn't hurt, I think
17:24:48 <adamw> kparal: mehhhhhh...
17:24:52 <RaphGro> kparal, that would make sense.
17:25:00 <adamw> i explained myself poorly
17:25:09 <adamw> i'm not sure i wanna be poking the anaconda network screen just to fix a cosmetic bug at this point
17:25:17 <cmurf> right i agree
17:25:27 <RaphGro> well, NM integration is a new feature in f24, no?
17:25:30 <adamw> no.
17:25:34 <adamw> anaconda has used NM forever.
17:25:44 <RaphGro> but f23 anaconda allows to set hostname only
17:25:45 <kparal> ok, agreed
17:25:49 <kparal> -1 FE
17:25:52 <cmurf> -1 FE
17:26:04 <adamw> RaphGro: you may be looking at a live image.
17:26:08 <RaphGro> ah.
17:26:15 <adamw> RaphGro: in lives, the idea is you do network config in the host desktop.
17:26:25 <RaphGro> kk
17:26:27 <adamw> you only get the full-fat anaconda interface in installer images.
17:26:36 <RaphGro> understood
17:28:18 <adamw> proposed #agreed 1327615 - RejectedFreezeException (Beta) - at this point in the Beta process it's a bit late to poke the network screen for a purely cosmetic fix
17:28:49 <RaphGro> note: that should be noticed in alpha phase.
17:28:58 <RaphGro> have been noticed *
17:29:35 <kparal> ack
17:29:45 <cmurf> ack
17:29:57 <adamw> #agreed 1327615 - RejectedFreezeException (Beta) - at this point in the Beta process it's a bit late to poke the network screen for a purely cosmetic fix
17:30:21 <adamw> we already accepted #1328369 i think?
17:30:42 <adamw> yeah we did.
17:30:49 <adamw> #topic (1329715) [abrt] sddm: drainMarkStack(): sddm-greeter killed by SIGSEGV
17:30:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329715
17:30:50 <adamw> #info Proposed Freeze Exceptions, sddm, NEW
17:31:02 <adamw> so i hit this on upgrade of an i686 f23 KDE install to f24
17:31:15 <adamw> it'd be good if someone else could see if they see the same
17:31:53 <cmurf> FE implies tested fix so I'd be +1
17:32:18 <adamw> openQA also hit a black screen at sddm time on i686 kde live today, but i dunno if that's the same bug yet
17:32:18 <adamw> https://openqa.fedoraproject.org/tests/14439
17:32:24 <kparal> +1
17:32:40 <garretraziel> does it happen on x86_64?
17:32:40 <adamw> yeah, i'd only want to include a pretty small targeted fix for this if we get one soon
17:32:42 <adamw> no
17:32:45 <adamw> hence FE not blocker
17:32:55 <garretraziel> then +1 FE
17:33:40 <pschindl> +1
17:34:25 <adamw> proposed #agreed 1329715 - AcceptedFreezeException (Beta) - if a targeted and tested fix for this is available soon we will consider including it (as this would be an upgrade criterion violation if i686 still blocked releases), but will be careful not to break x86_64
17:34:43 <pschindl> ack
17:35:31 <garretraziel> ack
17:35:47 <kparal> ack
17:36:01 <adamw> #agreed 1329715 - AcceptedFreezeException (Beta) - if a targeted and tested fix for this is available soon we will consider including it (as this would be an upgrade criterion violation if i686 still blocked releases), but will be careful not to break x86_64
17:36:16 <adamw> ok, that's all the FEs
17:36:27 <adamw> we only had two accepted blockers, so quick status on those:
17:36:32 <adamw> #info accepted blocker update
17:36:45 <adamw> #info 1321330 - dennis and peter are actively working on it
17:37:02 <adamw> #info 1259865 - hughsie and mclasen reported earlier that this is also being worked on
17:37:15 <adamw> so i don't think we have any action required there atm, unless anyone knows better than me
17:38:45 <adamw> anyone wanna do proposed final blockers, or are we all done?
17:39:42 <adamw> there's a hibernate bug, a comps translation bug, a live USB overlay bug, and an intel graphics bug.
17:40:08 * kparal has had enough
17:41:39 <cmurf> me2 but i'd do it if there's concensus
17:41:52 <adamw> that's a consensus to not do it, i think =)
17:42:07 <adamw> that's fine, 4 isn't a big number so we aren't storing up a giant meeting for next week
17:42:10 <cmurf> the other thing is two of those probably need to simmer anyway and we'd just end up punting
17:42:21 <adamw> #info we will do final blocker review next week, for now we'll prioritize beta testing
17:42:27 <adamw> #topic Open floor
17:42:29 <cmurf> yeah
17:42:31 <adamw> any other business, folks?
17:42:42 <kparal> not here
17:43:11 <cmurf> me neither
17:43:48 <nb> not i
17:44:38 <adamw> ok, thanks for coming everyone!
17:44:40 <jkurik> I had to leave for a while and the meeting is over already ...
17:44:42 * adamw lights the blue touch paper
17:44:47 <adamw> jkurik: no problems :)
17:44:55 <jkurik> thanks guys
17:45:21 <kparal> thanks adamw
17:56:52 <jkurik> adamw: may we close the meeting ?
17:57:12 <jkurik> proposed #endmeeting
18:02:42 <RaphGro> okay, let's delay final blockers
18:04:48 <pschindl> jkurik: you can end it too as you are chair.
18:06:59 <jkurik> pschindl: I know, I just did not want to interrupt what adamw started
18:08:22 <pschindl> It's true that blocker review meetings are plan for maximum of 3 hours. Maybe adamw wants to use whole time :)
18:54:18 <jkurik> adamw: I am sorry if you wanted to discuss anything else here
18:54:20 <jkurik> #endmeeting