16:19:26 <adamw> #startmeeting F22-blocker-review
16:19:26 <zodbot> Meeting started Mon Apr 13 16:19:26 2015 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:19:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:19:27 <adamw> #meetingname F22-blocker-review
16:19:27 <zodbot> The meeting name has been set to 'f22-blocker-review'
16:19:27 <adamw> #topic Roll Call
16:19:38 <danofsatx> .hello dmossor
16:19:38 <adamw> #chair jreznik sgallagh danofsatx
16:19:38 <zodbot> Current chairs: adamw danofsatx jreznik sgallagh
16:19:39 <zodbot> danofsatx: dmossor 'Dan Mossor' <danofsatx@gmail.com>
16:19:42 <adamw> .hello adamwill
16:19:43 <zodbot> adamw: adamwill 'Adam Williamson' <adamw+fedora@happyassassin.net>
16:19:52 <jreznik> .hello jreznik
16:19:53 <zodbot> jreznik: jreznik 'Jaroslav Reznik' <jreznik@redhat.com>
16:19:55 * pschindl is here
16:20:07 <adamw> jreznik: we only have two proposed blockers now...
16:20:08 <sgallagh> .hello sgallagh
16:20:09 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:20:16 <adamw> 5 proposed FE though.
16:20:18 <kalev> .hello kalev
16:20:20 <zodbot> kalev: kalev 'Kalev Lember' <kalevlember@gmail.com>
16:20:24 <pschindl> kparal: Are you here?
16:20:27 <sgallagh> adamw: I see 4 on the list
16:20:38 <adamw> sgallagh: i just cleared up two.
16:20:44 <sgallagh> ah ok
16:20:48 <jreznik> yep, I know
16:21:11 <jreznik> let's start!
16:22:27 <adamw> yup
16:22:34 <adamw> #topic Introduction
16:22:34 <adamw> Why are we here?
16:22:35 <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:22:35 <adamw> #info We'll be following the process outlined at:
16:22:36 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:22:37 <adamw> #info The bugs up for review today are available at:
16:22:38 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:22:40 <adamw> #info The criteria for release blocking bugs can be found at:
16:22:42 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria
16:22:46 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
16:22:48 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
16:23:15 <adamw> #info 2 Proposed Blockers
16:23:15 <adamw> #info 11 Accepted Blockers
16:23:15 <adamw> #info 5 Proposed Freeze Exceptions
16:23:15 <adamw> #info 9 Accepted Freeze Exceptions
16:23:56 <adamw> anyone willing to volunteer for secretary duty?
16:24:51 <jreznik> I might be able but post meeting
16:25:02 <jreznik> (in bugs)
16:25:27 <pschindl> adamw: I can do it.
16:25:43 <jreznik> even better :)
16:25:44 <adamw> thanks
16:25:50 <adamw> #info pschindl will secretarialize
16:26:28 <adamw> OK, starting with proposed blockers:
16:26:29 <adamw> #topic (1207366) Fedora 21 as an IPv6 tunnel endpoint (sit) gives severely crippled download speed over the tunnel
16:26:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1207366
16:26:29 <adamw> #info Proposed Blocker, kernel, NEW
16:26:44 <adamw> oh, shoot
16:26:49 <adamw> this is one of the ones I already dealt with
16:27:10 <adamw> #info this has been moved to proposed Final blocker with votes in bug
16:27:32 * danofsatx voted in bug
16:27:32 <adamw> hum, we should really be reviewing Final blockers too...maybe we can do that later.
16:27:43 <adamw> moving on to next beta for now
16:28:05 <adamw> #topic (1206760) Plasma desktop doesn't notify for available updates
16:28:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206760
16:28:05 <adamw> #info Proposed Blocker, plasma-pk-updates, ASSIGNED
16:28:28 <adamw> this was previously accepted, but I've moved it back to proposed, with a proposal: we should move the criterion this bug violates to Final
16:28:42 <adamw> the criterion is "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:29:11 <adamw> to give the history, the criterion was proposed by cwickert, but it was my choice to make it a Beta criterion, pretty much arbitrarily. no-one at the time expressed either support or opposition for that.
16:29:37 <adamw> given the current overall understanding of what ought to block Beta, i don't think it makes a lot of sense for this to be a Beta criterion, really.
16:29:59 <sgallagh> I'm not opposed, but could you elaborate on "the current overall understanding of what ought to block Beta"?
16:30:14 <danofsatx> +1 move to final.
16:30:24 <adamw> well, just our general approach that the key thing for beta is for it to be deployable and baseline usable for testing the new features and so on
16:31:08 <sgallagh> Works for me
16:31:13 <pschindl> +1 for moving it to final
16:31:42 <sgallagh> That being said, I'm open to allowing it as an FE if it should get fixed before we cut RC2
16:31:50 <adamw> it's apparently unlikelty
16:32:00 <adamw> also for the record KDE team is on board with pushing this to final
16:32:07 <sgallagh> Fine by me then
16:32:22 <kalev> as much as Workstation update notifications are concerned, I'd personally like to have them working in beta to make sure they get thoroughly tested
16:32:29 <kalev> but having said that, it doesn't necessarily mean it has to be coded that way in the QA test cases
16:32:51 <sgallagh> kalev: Yeah, this is all about when the lack of it working forces the release to slip
16:32:57 * kalev nods.
16:33:00 <sgallagh> The WGs can have more stringent policies.
16:33:14 <kalev> +1 from me too to move it to final then
16:33:22 <jreznik> +1 final
16:33:26 <sgallagh> +1 final
16:34:58 <adamw> rgr
16:35:54 <adamw> proposed #agreed #1206760: it was agreed in meeting that the criterion violated by this bug (update notification) should be moved to Final. Therefore this bug is accepted as a Final blocker.
16:36:05 <danofsatx> ack
16:36:30 <adamw> kalev: fwiw, update notification is one of the things we *do* usually test early
16:36:33 <jreznik> ack
16:36:37 <kalev> ack
16:36:40 <adamw> kalev: we caught this one at Alpha, for instance - it's just taking a long time to get fixed
16:36:46 <kalev> good good :)
16:36:55 <adamw> #agreed #1206760: it was agreed in meeting that the criterion violated by this bug (update notification) should be moved to Final. Therefore this bug is accepted as a Final blocker.
16:37:00 <sgallagh> Ack
16:37:04 <adamw> I'll take care of moving the criterion
16:37:20 <adamw> #topic (1207381) regression: smbd startup fails after update to 4.2.0-2.fc22
16:37:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1207381
16:37:20 <adamw> #info Proposed Blocker, samba, ON_QA
16:37:41 <adamw> i'm still -1 blocker on this, borderline -1 FE.
16:39:14 <kalev> I'm -1 blocker as well, but +1 FE since it seems like a small and isolated change that shouln't regress other samba functionality
16:40:07 <sgallagh> I'm sitting on the fence about FE, honestly.
16:40:13 <jreznik> I can be -1 blocker, +1 FE but do not push for that FE, maybe for safety even -1
16:40:38 <sgallagh> It can be fixed with an update though, so I guess I'm okay with -1 FE
16:41:04 <sgallagh> /me is paranoid about introducing any instability in RC2
16:41:39 <danofsatx> -1b, +1fe
16:41:53 <jreznik> ok, I trust sgallagh here, so +1 blocker/-1 FE
16:42:11 <danofsatx> my only concern is the mention that it breaks IPA with AD trusts
16:42:11 <sgallagh> jreznik: was that +1 blocker an accident? :)
16:42:22 <jreznik> sgallagh: accident
16:42:25 <adamw> so we're solid -1 blocker
16:42:27 <jreznik> -1/-1 sorry
16:42:58 <adamw> FE votes are... -3 +2 atm
16:43:00 <sgallagh> danofsatx: That's not currently a blocking configuration for Server
16:43:20 <sgallagh> We only block on the directly-connected domain
16:43:26 <danofsatx> true...
16:43:30 <sgallagh> (In part because the cross-domain stuff is hard to set up)
16:43:39 <danofsatx> like I said, it was a concern, not an issue ;)
16:43:51 <sgallagh> As that improves and simplifies, we may add criteria.
16:44:16 <sgallagh> danofsatx: The fix is known, so it'll be solved for Final
16:44:34 <adamw> so in the interests of brevity i'll just go with the majority here
16:44:54 <sgallagh> In case of deadlock, default to apathy? ;-)
16:45:21 <jreznik> apathylock
16:45:24 <adamw> propose #agreed #1207381: RejectedBlocker RejectedFreezeException - this bug has no significant effect on any known scenario related to the frozen package set and can be safely resolved with an update, so does not need to be a blocker or FE issue.
16:45:25 <adamw> hehe
16:45:39 <kalev> ack
16:45:40 <jreznik> ack
16:45:42 <sgallagh> ack
16:45:59 <adamw> but in seriousness, yes, it makes sense for the 'presumption' in this process to be against a bug being blocker/FE, i.e. it takes a clear decision to *make* a bug a blocker/FE, not to *stop* it being one.
16:46:15 <adamw> #agreed #1207381: RejectedBlocker RejectedFreezeException - this bug has no significant effect on any known scenario related to the frozen package set and can be safely resolved with an update, so does not need to be a blocker or FE issue.
16:46:40 <sgallagh> adamw: I agree with that statement wholeheartedly
16:47:26 <adamw> OK, do we have anything to discuss on the accepted blockers?
16:47:44 <sgallagh> I had one.
16:47:46 <adamw> one quick note, we have test cloud images for the fix to the outstanding blocker available for testing now: https://paste.fedoraproject.org/210376/89432271/
16:47:48 <sgallagh> /me looks it up
16:47:49 <adamw> sgallagh: which ?
16:48:07 <sgallagh> The fedup one
16:48:16 <sgallagh> Since that bounced back as FailedQA
16:48:32 <sgallagh> Though it's not part of the frozen package set, since it's being addressed on F21
16:49:40 <sgallagh> we probably need to circle back with wwoods and figure out if we're going to be clear for next Tuesday
16:50:29 * danofsatx is confused
16:50:37 <danofsatx> which one are we talking about?
16:50:44 <sgallagh> .bug 1207251
16:50:50 <zodbot> sgallagh: Bug 1207251 Fedup fail to decrypt disk with French keyboard layout (AZERTY) - https://bugzilla.redhat.com/1207251
16:50:57 <danofsatx> k
16:51:38 <adamw> k
16:51:42 <adamw> #topic (1207251) Fedup fail to decrypt disk with French keyboard layout (AZERTY)
16:51:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1207251
16:51:43 <adamw> #info Accepted Blocker, fedup, ASSIGNED
16:52:27 <sgallagh> "(12:51:36 PM) wwoods: *shrug* I can make that work by Thursday, I guess"
16:52:54 <adamw> oh, i hadn't seen wwoods' recent comment.
16:52:54 <kalev> sounds like the fix is entirely on the fedup (F21) side, and doesn't need image (F22) changes
16:52:59 <adamw> the thing is, this *still freaking works for me*.
16:53:02 <adamw> and kparal.
16:53:05 <adamw> we both tested. it works.
16:53:26 <adamw> i don't immediately see what lsinitrd has to do with anything except that it's confusing people who are trying to check if the file's there.
16:53:41 <sgallagh> From the last comment, it sounds like there's a little more to the repro case.
16:53:47 <adamw> i don't see what.
16:53:52 <sgallagh> That it only happens if the initrd is generated in a funky way
16:53:57 <adamw> we're all using the same initrd.
16:54:02 <sgallagh> /me shrugs
16:54:13 <adamw> oh, hum
16:54:27 <adamw> this is probably at the point where fedup modifies upgrade.img with files from the client system, right.
16:54:36 <adamw> still, i don't see how it could work in one case but not another
16:54:50 * adamw has to go re-read this code now.
16:55:38 <sgallagh> Well, regardless, the maintainer believes he can have a fix ready in time, so I'm inclined to just move on for now.
16:55:58 <sgallagh> This particular yak can remain shaggy a while longer
16:56:09 * kalev agrees.
16:57:26 <adamw> reasonable, yeah.
16:57:44 <adamw> ok, i kinda see a bit what's going on now, fedup reads the local/current files from the local initramfs, not from the sysroot.
16:58:11 <adamw> so depending on whether the local initramfs has the early-microcode wrinkle or not, it'll find the files to add to upgrade.img or not
16:58:27 <adamw> and whether the local initramfs has the early-microcode wrinkle or not could potentially vary, i guess.
16:58:36 <sgallagh> The other question I had on the AcceptedBlocker list was whether we wanted to drop blocker status on https://bugzilla.redhat.com/show_bug.cgi?id=864198 ?
16:58:47 <sgallagh> It's better than it was in F21, but not completely fixed.
16:58:56 <adamw> sgallagh: that doesn't need discussing, really, it's just waiting on me verifying that /boot-on-btrfs is disallowed in RC1/RC2.
16:59:02 <sgallagh> ok
16:59:06 <adamw> hold on, let me do some bureaucrazy.
16:59:21 * jreznik got lost here, completely
16:59:35 <sgallagh> ... the blockerbugs page appears not to be syncing, again
16:59:49 <adamw> #info we have a better idea of a wrinkle in initramfs layout which could cause #1207251 to occur in some cases but not others; the fix would be entirely on the from-release side and so does not need to block F22 image compose. wwoods aims to have a fix ready by Thursday.
17:00:17 <adamw> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs
17:00:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
17:00:17 <adamw> #info Accepted Blocker, grubby, ASSIGNED
17:00:37 <adamw> #info /boot-on-btrfs should be disallowed again in RC1/RC2, we just need to test and confirm this
17:02:18 <adamw> cmurf has an argument that this should block to the point of us not shipping till /boot-on-btrfs actually works, but i'm not convinced by it.
17:02:42 <adamw> pjones is also not exactly committed to treating this as an international emergency.
17:03:26 <sgallagh> adamw: We missed a proposed blocker earlier
17:03:30 <sgallagh> .bug 1211122
17:03:33 <zodbot> sgallagh: Bug 1211122 No closest mirror can be found from behind a proxy - https://bugzilla.redhat.com/1211122
17:03:40 <sgallagh> (BlockerBugs hadn't synced for 17 hours)
17:03:58 <kalev> did the F21 installer even allow installing on brtfs by default?
17:04:00 <adamw> sgallagh: oh, right, because i only fixed it to be a proposed beta blocker this morning, le sigh
17:04:08 <adamw> kalev: apparently yes, that's what the barney is about.
17:04:30 <adamw> still, according to this bug that should've resulted in a system on which you can't upgrade the damn kernel, so i mean, i just wish this whole thing would go away and die in a fire.
17:04:51 <adamw> sgallagh: we'll do that one after this
17:05:15 <sgallagh> ack
17:05:19 <adamw> so is anyone willing to die on the barricades for #864198 or shall we just carry on regretting the existence of btrfs and let it fester?
17:05:48 <sgallagh> Can we try treating it with leaches?
17:05:55 <sgallagh> eerr leeches
17:06:22 <adamw> sure, then we can treat the leeches with fire
17:06:24 * jreznik pretends brtfs does not exists
17:06:28 <adamw> a satisfactory outcome all around
17:06:32 <sgallagh> +1
17:08:22 <adamw> #info there is some concern that F21 systems deployed with /boot on btrfs will have problems upgrading to F22, but by all accounts this is a broken F21 configuration in any case and we don't see the value in delaying F22 Beta indefinitely for a currently unavailable grubby fix.
17:08:44 <adamw> back to the proposed blocker we missed
17:08:45 <adamw> #topic (1211122) No closest mirror can be found from behind a proxy
17:08:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211122
17:08:45 <adamw> #info Proposed Blocker, anaconda, NEW
17:09:27 <adamw> more proxy fun
17:09:34 <adamw> does anyone have a proxy setup they can use to confirm this?
17:10:11 * nirik looks.
17:10:16 <danofsatx> don't have one handy, but I could construct one (I think)
17:10:50 <sgallagh> Even if this is reproducible, I'm somewhat inclined to fudge this and fix it for Final.
17:10:51 * danofsatx checks his PFSense Firewall to see if it is easy enough
17:11:04 <jreznik> seems like no council meeting so I have to move home but I'll be available on phone
17:11:05 <sgallagh> The workaround for now is to use a known mirror
17:11:05 <adamw> sgallagh: given 'closest mirror' is the default choice, my 'icky' sensors go off.
17:11:39 <sgallagh> adamw: Yeah, which is why I'm wondering how we could have not noticed this before.
17:12:46 <nirik> few people do proxies anymore? and those that do likely just do internal installs?
17:13:28 <kalev> and add to that that Workstation / KDE live installs aren't affected, making it even harder to notice
17:14:18 <jreznik> davidshea says it might be network configuration problem
17:14:59 <nirik> hum, so they specified a http proxy but have no https connectivity?
17:15:13 <nirik> that bug report is low on facts. command line might be nice...
17:15:50 <sgallagh> For the few people who might hit this, I think we can have a Common Bugs entry.
17:16:12 <jreznik> sgallagh: yep
17:16:13 <kalev> I think I'd agree with sgallagh.
17:16:47 <kalev> is there a matrix somewhere which install media is considered blocking for each product?
17:16:55 <adamw> there's another wrinkle, which is that you can configure the proxy interactively as well as on cmdline, and we don't know if this happens tehre
17:17:02 <adamw> kalev: no.
17:17:24 <jreznik> kalev: not yet but I filed a fesco ticket to work on such list
17:17:24 <nirik> kalev: there's a fesco ticket to create such a thing tho
17:17:40 <adamw> so, i guess i'm a provisional -1, i'm willing to reconsider with more data...
17:17:46 <nirik> adamw: also, we only have the logs from the orig anaconda install on the orig bug, not the new one.
17:17:59 <jreznik> -1 blocker
17:18:01 <kalev> as far as my gut feeling goes, it doesn't make sense to block on the workstation netinstall not working with proxy setups
17:18:04 <kalev> ... since workstation's primary media is the live media
17:18:06 <kalev> -1 blocker as well
17:18:25 <nirik> it smells to me like they have a http proxy and aren't able to make https connections, so they can't get the orig metalink
17:18:31 <sgallagh> I'm -1 blocker, but I'm also trying to reproduce this myself
17:19:44 <danofsatx> -1 blocker.
17:19:51 <sgallagh> kalev: For the record, the reporter didn't mention which edition this was. Server netinstall or DVD would theoretically hit this too. But I'm still -1 blocker
17:20:31 <nirik> -1 based on the current info. ask reporter for more to figure out things.
17:21:47 <adamw> propose #agreed #1211122 - RejectedBlocker - there seems to be a lot of grey area in this bug, lots of information we need from the reporter, but even in the worst possible case people seem inclined to fudge this with a CommonBugs note suggesting explicit repo configuration for Beta.
17:22:33 <nirik> ack
17:22:36 <pschindl> ack
17:22:41 <danofsatx> ack
17:22:51 <kalev> ack
17:23:05 <adamw> #agreed #1211122 - RejectedBlocker - there seems to be a lot of grey area in this bug, lots of information we need from the reporter, but even in the worst possible case people seem inclined to fudge this with a CommonBugs note suggesting explicit repo configuration for Beta.
17:23:29 <adamw> ok, let's do the FEs that look like they might have fixes
17:23:50 <adamw> #topic (1209927) Geolocation is broken and default language is always used
17:23:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209927
17:23:50 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:24:26 <adamw> i can give this a +1 FE, though i expect we won't actually pull a fix into RC2, it'd likely go in only if there's another slip.
17:24:55 <nirik> sure, +1 FE
17:25:13 <kalev> +1 FE
17:25:45 <kalev> although it would be nice to have FE's pulled in for today's RC build to not have surprises in the last minute :)
17:26:38 <danofsatx> +1 FE
17:27:06 <sgallagh> +1 FE
17:27:16 <adamw> proposed #agreed #1209927 - AcceptedFreezeException - this is a highly-visible issue that can't be fixed with an update and inconveniences users who don't read English
17:27:40 <sgallagh> ack
17:27:40 <kalev> ack
17:27:56 <danofsatx> ack
17:27:58 <adamw> #agreed #1209927 - AcceptedFreezeException - this is a highly-visible issue that can't be fixed with an update and inconveniences users who don't read English
17:28:03 <adamw> #topic (1210474) Update fedora-bookmarks for Fedora 22
17:28:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210474
17:28:03 <adamw> #info Proposed Freeze Exceptions, fedora-bookmarks, NEW
17:28:14 <adamw> sure, makes sense to pull in a change for this if we get one. +1
17:29:05 <sgallagh> Low risk. +1
17:29:19 <nirik> sure. +1
17:29:22 <kalev> +1
17:29:46 <pschindl> +1
17:30:13 <adamw> proposed #agreed #1210474 - AcceptedFreezeException - the bookmarks on the live images cannot be changed with an update and this is a very low impact change
17:30:35 <pschindl> ack
17:30:42 <kalev> ack
17:31:57 <sgallagh> ack
17:32:28 <adamw> #agreed #1210474 - AcceptedFreezeException - the bookmarks on the live images cannot be changed with an update and this is a very low impact change
17:32:37 <adamw> #topic (1210259) missing libicui18n.so.52 after fedup to F22, firefox won't start
17:32:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210259
17:32:37 <adamw> #info Proposed Freeze Exceptions, firefox, NEW
17:32:39 <sgallagh> FYI, jumping back to the proxy issue, I can successfully reach the mirror list with a properly-configured squid proxy
17:33:00 <adamw> sgallagh: good info, thanks
17:33:07 <nirik> sgallagh: what command line there?
17:33:18 <sgallagh> Ah, I used the interactive mode in anaconda.
17:33:22 <sgallagh> I'll try the command line next
17:33:47 <adamw> so I'm +1 for this, but there's an interesting question whether we do it after go/no-go...
17:34:06 <adamw> i.e. do we pull firefox 37 into RC2
17:35:59 * nirik looks at this bug again
17:36:46 <adamw> basically people using fedup get broken firefox until their first post-upgrade update; this will be fixed whenever we push a new firefox package stable
17:37:34 <nirik> which we should do after go but before release anyhow
17:37:38 <danofsatx> +1
17:37:45 <danofsatx> I hit this, it needs fixed.
17:38:31 <adamw> so we can either include it in rc2 or do rc2 with firefox 36 and only push 37 stable after go/no-go.
17:38:52 <nirik> I guess I don't care. We could push it stable now, or before release, same difference really
17:39:00 <kalev> there's also the thing that Firefox always fixes some CVE issues and it would be nice to pull the new version in just for those, to make sure they are on the media
17:40:05 <sgallagh> nirik: Worked with proxy=http://192.168.124.1:3128 as well
17:40:19 <nirik> sgallagh: neat.
17:40:20 <sgallagh> I'm left to conclude that the issue is with their proxy and not us
17:40:34 <nirik> so, sure +1 to this, lets pull it into rc2.
17:40:39 <adamw> ok, let's just vote on FE-ness, and we can debate exactly when to include it outside the meeting
17:41:10 <adamw> proposed #agreed #1210259 - AcceptedFreezeException - it would be good to push this stable ASAP to help people testing fedup
17:41:16 <nirik> +1
17:41:23 <sgallagh> Do we not have a browser criterion for Workstation?
17:41:27 <sgallagh> That seems like an oversight.
17:41:28 * kalev is +1 FE. seems like a fairly safe change, with the update having gotten +5 karma already.
17:41:39 <nirik> sgallagh: browser criterion?
17:42:10 <nirik> it works fine on the media and in new installs.
17:42:16 <sgallagh> "With a properly-configured network connection, the default browser must be able to reach and display getfedora.org" seems like a reasonable blocker criterion.
17:42:20 <nirik> this is just fedup users. (and likely dnf/yum ones)
17:42:39 <pschindl> ack
17:42:42 <sgallagh> Sure, but as of Beta, upgrades are supposed to meet the same criteria as fresh installs
17:43:14 <sgallagh> Not having such a criteria for the default browser in Workstation seems like a glaring oversight
17:43:35 <kalev> we'd have to freeze all older releases while Branched is frozen to fix these kinds of upgrade issues properly
17:43:43 <kalev> but I don't think this is going to fly :)
17:43:48 <adamw> sgallagh: sure we do.
17:44:19 <adamw> https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Required_applications
17:44:23 <adamw> "
17:44:23 <adamw> The web browser must be able to download files, load extensions (if applicable), and log into FAS.
17:44:23 <adamw> "
17:44:32 <sgallagh> Ah ok
17:44:39 <sgallagh> Then this seems like a blocker to me.
17:44:42 <adamw> #agreed #1210259 - AcceptedFreezeException - it would be good to push this stable ASAP to help people testing fedup
17:44:57 <adamw> i don't think this really merits a blocker, though. anyhoo, moving on
17:45:03 <adamw> #topic (1195231) ghc-7.8.4 build fails to complete on aarch64
17:45:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1195231
17:45:03 <adamw> #info Proposed Freeze Exceptions, ghc, ON_QA
17:45:08 <adamw> looks like a standard secondary arch thing
17:45:54 <adamw> though, hrm, seems to be some discussion of fallout
17:46:07 <sgallagh> I'm wary of changing anything in the build-system during a freeze.
17:46:37 <sgallagh> Doesn't look like anything that has to be part of any install-set either
17:46:41 <kalev> secondary arches can just pull in the single update if it's needed for them, afaik
17:46:44 <sgallagh> So it could be fixed in an update easily
17:46:44 <adamw> oh, the fallout is with 42.2, not 43.
17:47:15 <adamw> pbrobinson said he wanted a fix 'by the beta freeze' but without elaboration...
17:47:15 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1195231#c11
17:48:25 * adamw never tires of being able to ping pbrobinson as pbr with nick completion
17:48:37 <adamw> not that he'd drink that hipster crap.
17:49:02 <danofsatx> pbr is hipster? wow...things shur have changed.
17:49:05 <adamw> proposal - punt for clarification on why exactly this needs to go stable?
17:49:10 * danofsatx thought it was a Redneck staple
17:49:19 <adamw> danofsatx: it's 'ironic' hipster.
17:49:26 <adamw> also, still, redneck staple.
17:49:54 <danofsatx> .fire adamw for not capitalizing Redneck
17:49:54 <zodbot> adamw fires adamw for not capitalizing Redneck
17:50:02 <adamw> heh
17:50:14 <kalev> I think they want to use the exact same "F22-Beta" tag / package set for secondary arches as is used for primary
17:50:54 <adamw> yes, but the bug doesn't give any clear indication why the update actually needs to be in a compose...
17:50:55 <kalev> but I don't understand the process well enough to say for certain if it's a problem for them to pull in an extra build for the secondary arches, without it making it to stable on primary
17:50:55 <nirik> right.
17:51:14 <adamw> did the current primary stable build entirely fail for secondary arches?
17:51:22 <adamw> if not, does it break something in install or other frozen env?
17:51:28 <adamw> if not, i don't see why it needs to be an FE...
17:53:04 <sgallagh> -1 FE unless new information surfaces
17:54:40 * adamw just got a response from pbr
17:54:44 <adamw> waiting for details
18:03:40 <sgallagh> For the benefit of the folks hanging around in here, there's a discussion happening in #fedora-releng
18:04:31 <adamw> also, this is the last proposed beta FE, so if anyone wants to slope off to the bar, go ahead
18:04:41 <adamw> we can do proposed final blockers after this if anyone hasn't had enough fun yet
18:05:07 <adamw> (we should've been doing them all along but sort of forgot a bit()
18:05:27 <sgallagh> adamw: I'll hang around to go through them
18:05:35 <adamw> we'll need at least 3 people
18:06:02 <sgallagh> Do my dissociative identities count?
18:08:51 <adamw> sgallagh: only if the voices in my head do
18:09:31 <sgallagh> adamw: One of my identities is offering to eat your voices. Should I be worried?
18:11:24 <adamw> yes, they're poisonous.
18:12:44 <adamw> ok, it sounds like this is causing pbrobinson heartache, but i don't really see a clear FE justification and don't want to go throwing big packages in willy-nilly
18:12:55 <adamw> so with apologies to peter gonna stick with -1
18:12:57 <sgallagh> Yeah, I'm inclined to agree.
18:13:07 <sgallagh> -1 FE. Too much risk during Freeze
18:13:57 <pschindl> -1 from me too
18:15:46 <adamw> proposed #agreed #1195231 - RejectedFreezeException - on currently available info we don't see a clear reason this needs to have a freeze exception, it's causing issues with package builds but there are other avenues for dealing with that. We will re-discuss this if re-proposed with a better justification
18:16:00 <sgallagh> ack
18:16:09 <pschindl> ack
18:17:00 <danofsatx> ack
18:17:16 <adamw> #agreed #1195231 - RejectedFreezeException - on currently available info we don't see a clear reason this needs to have a freeze exception, it's causing issues with package builds but there are other avenues for dealing with that. We will re-discuss this if re-proposed with a better justification
18:17:45 <adamw> OK, we currently have 9 proposed Final blockers - who wants to sit through those?
18:18:05 <danofsatx> oh, we're still here?
18:18:21 <sgallagh> adamw: s/wants/is willing/
18:18:27 <danofsatx> I vote for voting in bugs.
18:18:29 <adamw> danofsatx: if enough folks want to sit around for final blockers we can do them
18:18:35 <adamw> if not we can leave it for next week
18:20:06 <pschindl> it's quite late here. I'd prefer to make them next time or in bz
18:23:40 <adamw> sounds like we don't have the numbers for Final blocker review - votes in bugs would be great, i'll run through and secretaralize any which reach the necessary number of votes
18:23:51 <adamw> #info votes in bug on Final blockers ahead of next week's meeting would be great
18:24:36 <sgallagh> ok
18:24:48 <adamw> #topic Open Discussion
18:24:52 <adamw> any other topics before we shut down?
18:25:02 <adamw> looks like for RC2 we'll pull in the util-linux update plus a couple of FE fixes
18:25:59 <pschindl> When should we expect RC2?
18:26:02 <sgallagh> Also the rolekit blocker, I presume
18:26:41 * satellit_e late return
18:26:46 <adamw> today
18:27:01 <adamw> sgallagh: that was already in TC8 wasn't it? as it's fixed by the same update as an FE fix
18:27:25 <adamw> er, RC1, I mean
18:27:37 <sgallagh> err, let me double-check
18:28:13 <sgallagh> You're correct. My mistake.
18:28:26 <sgallagh> /me thought he remembered finding a post-RC1 blocker
18:28:52 <sgallagh> Oh, it was the realmd issue
18:28:56 <sgallagh> not rolekit
18:28:59 <adamw> the realmd one?
18:29:04 <adamw> yeah, that'll be pulled in too.
18:29:06 <sgallagh> k
18:30:23 <adamw> #info expect Beta RC2 today with fixes for all outstanding blockers
18:30:37 <sgallagh> And the boring ones, too
18:30:42 <kalev> sorry, had to step away for a bit
18:30:56 <kalev> I think there's one more bug with a possible fix:
18:31:20 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1209347
18:31:54 <adamw> heh
18:32:20 <adamw> kalev: sure, it's an accepted Beta freeze exception
18:32:23 <sgallagh> Right, halfline forgot to mark the bug as fixed by that update
18:32:33 <sgallagh> adamw: Please be aware of that when filing the request.
18:32:43 <adamw> i'd quite like it to get some testing before including it, though...
18:32:49 <adamw> has anyone actually tested it yet?
18:33:04 <kalev> yes, that's why I brought this up :)
18:33:27 <sgallagh> I haven't tested the packaged version, but I've tested the patched binary while we were investigating
18:34:04 <sgallagh> It's difficult to test out without a rebuilt live image
18:34:39 <adamw> hrm, yeah, i guess. i can do a live image...
18:34:41 <kalev> as long as it doesn't _regress_ regular login, I think it should be good
18:34:49 <sgallagh> For whatever reason, I almost never hit the race on an installed system
18:35:00 <sgallagh> (not *never* but significantly less often)
18:35:05 <kalev> if it turns out to not fully fix the live image issue, that's not the end of the world
18:35:10 <kalev> as long as it doesn't regress stuff :)
18:35:27 <sgallagh> kalev: All it does is lengthen a timeout from 0.5s to 25s
18:35:50 <sgallagh> So the only regression I can see is that startup could theoretically take an extra 24.5s if it never replies.
18:36:41 <kalev> yes, I was replying to the idea to do a live image build to test this
18:37:07 <sgallagh> If someone produces the live image, I'll happily test it
18:37:16 <kalev> what I was trying to say was that it should be ok to +1 it if it doesn't regress regular logins
18:37:25 <kalev> even without testing a live image
18:37:50 <sgallagh> Well, it's already an AcceptedFE
18:38:09 <adamw> right, it's not a question of voting, but whether we actually pull it into RC2
18:38:17 * adamw always happier with actual testing than What Could Possibly Go Wrong
18:38:20 <sgallagh> So let's pull it into RC2, I'll check the live image as soon as it's available
18:38:21 <adamw> i'll build a smoketest live
18:38:34 <sgallagh> (Which is faster than the rest of the compose) and we'll revert it and restart RC3 if I fail
18:38:36 <sgallagh> Reasonably?
18:38:41 <sgallagh> *reasonable
18:38:45 <kalev> makes sense to me
18:39:04 <sgallagh> or a smoketest live is fine too, if it doesn't hold up the RC2 compose too badly
18:39:06 <adamw> sgallagh: that works too i guess
18:39:14 <adamw> sgallagh: building is fast, but then i have to upload it somewhere.
18:39:25 <sgallagh> /me wants to give QA the maximum time with RC2
18:39:33 <adamw> ok, AOB?
18:39:41 <sgallagh> AOB?
18:40:05 <kalev> Aut of Band?
18:40:19 <kalev> As Originally Broposed? :)
18:40:35 <adamw> any other business
18:41:07 <sgallagh> adamw: Which are we doing? Starting RC2 immediately or waiting for a smoketest?
18:41:20 <adamw> RC2, i guess.
18:41:22 <sgallagh> ok
18:42:06 * danofsatx was thinking All On Board
18:43:24 <sgallagh> fin
18:43:47 <danofsatx> What is a shark, Alex?
18:45:02 <adamw> i'm sorry, the question we were looking for was "What is a significant feature of a shark."
18:45:09 <adamw> thanks for coming, folks
18:45:11 <sgallagh> /me was going with the latin...
18:45:13 <adamw> #endmeeting