18:02:01 <jkurik> #startmeeting F27 Final and Server Beta Go/No-Go meeting
18:02:01 <zodbot> Meeting started Thu Nov  9 18:02:01 2017 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:01 <zodbot> The meeting name has been set to 'f27_final_and_server_beta_go/no-go_meeting'
18:02:08 <jkurik> #meetingname F27-final-and-Server-Beta-Go-No-Go-meeting
18:02:08 <zodbot> The meeting name has been set to 'f27-final-and-server-beta-go-no-go-meeting'
18:02:13 <mboddu> jkurik: Yeah, just checked my calendar
18:02:14 <jkurik> #topic Roll Call
18:02:19 <nirik> morning
18:02:22 <jkurik> .hello jkurik
18:02:23 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
18:02:24 <mboddu> .hello mohanboddu
18:02:26 <frantisekz> .hello2
18:02:26 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
18:02:29 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
18:02:29 <jkurik> #chair nirik adamw sgallagh mboddu
18:02:29 <zodbot> Current chairs: adamw jkurik mboddu nirik sgallagh
18:02:30 <stickster> .hello pfrields
18:02:32 <lbrabec> .hello2
18:02:34 <langdon> .hello2
18:02:36 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
18:02:39 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
18:02:41 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
18:02:44 <jkurik> Hi everyone
18:02:45 <sgallagh> and so it begins
18:02:49 <stickster> sgallagh: lol
18:02:51 <sgallagh> .hello2
18:02:51 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:03:35 <jkurik> do we have QA ? adamw, kparal ?
18:03:46 <adamw> .hello adamwill
18:03:47 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
18:03:52 <kparal> .hello kparal
18:03:54 <jkurik> \o/
18:03:59 <jkurik> #topic Purpose of this meeting
18:04:02 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
18:04:05 <jkurik> #info Purpose of this meeting is to check whether or not F27 Final and F27 Modular Server Beta are ready for shipment, according to the release criteria.
18:04:10 <jkurik> #info This is determined in a few ways:
18:04:15 <jkurik> #info * Release candidate compose is available
18:04:19 <jkurik> #info * No remaining blocker bugs
18:04:26 <jkurik> #info * Test matrices are fully completed
18:04:32 <jkurik> #topic Current status of F27 Final release
18:04:35 <bowlofeggs> .hello2
18:04:36 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
18:04:47 <jkurik> We have an RC compose available at https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20171105.0/
18:05:02 <jkurik> We also have test matrices available at https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.6_Summary
18:05:13 <jkurik> There are some proposed blockers: https://qa.fedoraproject.org/blockerbugs/milestone/27/final/buglist
18:05:23 <jkurik> May I have your confirmation of the above for the F27 Final release, please ?
18:05:42 <adamw> sounds right.
18:05:47 <jkurik> #info RC compose is ready, Test matrices are available and there are some proposed blockers.
18:05:56 <jkurik> #link https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20171105.0/ - The RC compose
18:06:03 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.6_Summary - Test matrices
18:06:10 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/27/final/buglist - Proposed blockers
18:06:21 <jkurik> #topic Current status of F27 Modular Server Beta release
18:06:31 <jkurik> We have RC compose available at https://kojipkgs.fedoraproject.org/compose/27/Fedora-Modular-27-20171108.2/
18:06:40 <jkurik> We do not have Test Matrices as there is an agreement between the Server/Modular WG and Fedoar QA to use https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria instead.
18:06:56 <jkurik> Am I correct ?
18:07:08 <sgallagh> Yes
18:07:19 <jkurik> #info RC is ready as well as Beta release criteria which are used as the criteria for testing purposes.
18:07:20 <sgallagh> Though "it's complicated" and I'll get to that in a bit
18:07:29 <jkurik> #link https://kojipkgs.fedoraproject.org/compose/27/Fedora-Modular-27-20171108.2/ - The RC compose
18:07:35 <jkurik> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria - F27 Modular Server Beta Release criteria
18:07:48 <jkurik> sgallagh: do you want to elaborate on it now ?
18:08:32 <sgallagh> jkurik: The 1.5 compose hit a very odd bug that caused one of the modules (fonts) not to be included in the compose tree)
18:08:59 <sgallagh> The installer works fine (and has the fonts, interestingly), but installation of FreeIPA doesn't work from that specific compose, due to missing fonts,
18:09:34 <sgallagh> However, FreeIPA via rolekit always hits the repos, so this is addressable without respinning the RC
18:10:07 <jkurik> ok, do we have a bugzilla for it (to mark it as 0day) ?
18:10:15 <sgallagh> There is currently a compose in-flight that restores the fonts to the compose tree. It hasn't finished yet, but should within the next 30 minutes, so I'd like us to defer decision until that happens
18:10:30 <jkurik> sgallagh: ah, ok
18:10:54 <jkurik> so we can move on with F27 Final release
18:11:05 <jkurik> adamw: May I ask you please to chair the Mini-blocker review ?
18:11:10 <adamw> sure.
18:11:12 <jkurik> #topic Mini-Blocker Review
18:11:32 <sgallagh> jkurik: 1508576 has sort of become this, but it's confusing
18:11:34 <adamw> #info here are the proposed Final blockers
18:11:44 <adamw> #topic (1469129) [abrt] gnome-shell: g_type_check_instance_cast(): gnome-shell killed by signal 11
18:11:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1469129
18:11:45 <adamw> #info Proposed Blocker, gnome-shell, NEW
18:11:46 <jkurik> sgallagh: thanks
18:11:54 <adamw> so. another gnome-shell crash bug.
18:12:00 <adamw> this one again has 20+ people CCed on it.
18:12:01 <sgallagh> We should probably add that to the blocker proposals
18:12:15 <adamw> and for some goddamn reason someone only decided to propose it as a blocker yesterday.
18:12:23 <adamw> leaving us no time to really investigate or analyse it.
18:12:39 <stickster> Hm. I haven't seen this problem.
18:12:53 <adamw> me either. there is some suggestion in the bug that it's related to btrfs.
18:13:06 <adamw> either three or four people mention btrfs, though one of them is leslie.
18:13:28 <adamw> (not sure who superdanby is, whether he's the same as one of the commenters or not)
18:13:29 * kparal isn't convinced this is related to btrfs in any way
18:13:48 <adamw> i wouldn't say i'm convinced either, but i guess it's *possible*.
18:14:46 <adamw> so i'm worried about this one, but it being proposed as a blocker yesterday really puts us in an awkward spot.
18:15:01 <stickster> 😒
18:15:04 <adamw> and we just don't have a great framework for assessing Shell crashers.
18:17:20 <kparal> since none of us has seen this crash, I'd consider it being rather rare
18:17:44 * nirik is -1 blocker. Hopefully more info could be found and it could be fixed in an update... and yeah, not see it in general testing here at all...
18:17:46 <jkurik> Hmm... I am more inclined to the mattdm's opinion that there might be several small issues for this crashes which are just having the same symptomps
18:17:47 <kparal> some people mentioned dnf update at the same time, and even more people lock screen deactivation
18:18:06 <stickster> and at least one mentions an extension installation
18:18:13 <adamw> the dupes here look more...dupey than the other one, to me.
18:18:26 <stickster> kparal: the lock screen deactivation could easily be known issues with external monitor
18:19:09 <stickster> they're all g_type_check_instance_cast() involved, right?
18:19:25 <adamw> yeah, the backtraces all match at least that far.
18:19:34 <stickster> interestingly I'm working on a coredumpctl article for Fedora Magazine :-)
18:19:41 <adamw> and it's my understanding that once a shell crash backtrace gets into the javascript interpreter it's basically useless
18:19:52 <stickster> :-(
18:19:52 <adamw> you need a separate javascript-specific trace there
18:20:09 <adamw> there's recently been a commit upstream that automatically does the appropriate javascript dump whenever shell crashes
18:20:16 <adamw> but that's not in f27 unfortunately
18:20:23 <stickster> :-( maybe we can get it backported
18:20:29 <stickster> anyway, not relevant here
18:20:31 <adamw> yeah, that was being kicked around
18:20:59 <stickster> hard for me to +1 this when I'm not seeing it on any of my h/w
18:22:23 * mboddu agrees with stickster
18:22:48 <jkurik> I would personally be -1 to block as the issue does not seem to be somehow general. But my opinion is based mostly on feelings.
18:23:22 <frantisekz> I am inclining more to -1; running X session instead of the Wayland one seems like an easy "workaround"
18:24:00 <puiterwijk> frantisekz: I disagree with that that's a fix
18:24:05 <puiterwijk> At least one of them happened on Xorg
18:24:25 <puiterwijk> s/fix/workaround/
18:24:49 <puiterwijk> https://bugzilla.redhat.com/show_bug.cgi?id=1499383 has XDG_SESSION_TYPE=x11
18:25:02 <adamw> i worry a bit that this could come back to bite us, but it's hard to be +1 right now
18:25:03 <frantisekz> yeah, I've meant that you wouldn't lose your apps and entire session on X if I am not mistaken
18:25:12 <puiterwijk> Right
18:25:15 <adamw> right
18:25:18 <adamw> it's an *effective* workaround
18:25:45 <adamw> we can definitely put some generic wording into commonbugs about switching to X if you experience repeated shell crashes
18:25:59 <adamw> i think we might actually even have some such text lying around in an older commonbugs page i could dust off...
18:26:03 <stickster> *nod...
18:26:22 <jkurik> and we can fix this with an update when we have the fix
18:26:54 <adamw> for non-live cases, yeah.
18:26:55 * mattdm has "get split session/compositor/etc onto roadmap" on the agenda for a meeting later today, not that that helps us hwre
18:27:10 <adamw> so, i'm like a -0.5
18:27:17 * stickster asked in #fedora-workstation, fwiw, and mclasen also opines the bug is way too cluttered to judge it as one bug
18:27:23 <nirik> I think there was a GSoC student working on that... but not sure how far they got
18:27:24 <adamw> is anyone voting +1 here? or have any other objection to proposing RejectedBlocker?
18:27:39 <mattdm> mclasen that is my take too
18:28:03 <jkurik> adamw: I am -0.75 :-)
18:28:33 <sgallagh> I'm also -1
18:28:41 <lbrabec> -1 here
18:28:41 <stickster> I'm -0.8119503 but only because it's a Thursday
18:28:47 <sgallagh> ...
18:29:08 <gholms> heh
18:29:11 <sumantro> I am also -1
18:29:15 <frantisekz> -1
18:29:26 <mboddu> -1
18:29:35 <mattdm> anyone want to sum th
18:29:44 <mattdm> ose fractions?
18:29:56 <sgallagh> .fire mattdm
18:29:56 <zodbot> adamw fires mattdm
18:29:57 * stickster withdraws to make the math easier ;-)
18:30:06 <stickster> you do it "mathdm"
18:30:23 <mboddu> haha :)
18:30:45 <puiterwijk> And if I vote -0.3141592653 ?
18:30:47 <stickster> it's -6.25 thus far if you don't count me
18:30:51 <adamw> the vote is minus a bunch, plus zero
18:31:13 <stickster> sorry, -7.25, I missed nirik earlier
18:31:29 * nirik waves
18:32:27 <adamw> proposed #agreed 1469129 - RejectedBlocker (Final) - this bug concerns us, but the fact that it was only proposed the day before the meeting puts us in an awkward spot. There really isn't sufficient information yet to clearly indicate this will affect a wide range of users, or even for us to usefully evaluate what circumstances trigger it or how long a fix may take. Given this, we don't feel we can block the release at this time
18:32:31 <stickster> puiterwijk: that would be fine, but you're not allowed to vote irrationally so 𝛑/10 is forbidden
18:33:00 <jkurik> adamw: ack
18:33:02 <mattdm> ack
18:33:04 <lbrabec> ack
18:33:06 <frantisekz> ack
18:33:08 <sumantro> ack
18:33:16 <stickster> ack
18:33:16 <mboddu> ack
18:33:17 <adamw> #agreed 1469129 - RejectedBlocker (Final) - this bug concerns us, but the fact that it was only proposed the day before the meeting puts us in an awkward spot. There really isn't sufficient information yet to clearly indicate this will affect a wide range of users, or even for us to usefully evaluate what circumstances trigger it or how long a fix may take. Given this, we don't feel we can block the release at this time
18:33:18 <puiterwijk> ack
18:33:41 <adamw> #topic (1497897) VPN entry text missing in GNOME Shell menu when laptop is plugged in to mains power
18:33:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1497897
18:33:41 <adamw> #info Proposed Blocker, gnome-shell, NEW
18:33:41 <mattdm> we can propose it right away as a priority candidate
18:33:45 <adamw> oh man, i didn't even see this one.
18:34:02 <adamw> mattdm: to be honest, i'd rather have the 'split the shell and compositor' stuff as the prioritizedbug
18:34:11 <adamw> mattdm: given that it seems like there's always going to be crasher bugs in shell...
18:34:29 <mattdm> adamw: good news then :)
18:35:45 <stickster> there seem to be a number of comments in bz#1497897 pointing -1 for various reasons... primarily that it's not being seen often by any of the commenters
18:35:53 * nirik is -1 blocker on this one. It's ugly, but everything works and can hopefully be fixed in an update (lives shouldn't normally have vpns enabled)
18:36:11 <puiterwijk> stickster: I was just about to say I am hitting this all the time, and had been planning on filing when I found this bug :)
18:36:12 <stickster> I haven't seen it myself but yay anecdata
18:36:15 <puiterwijk> https://puiterwijk.fedorapeople.org/gnome326/novpn.png
18:36:17 <stickster> lol
18:36:31 <adamw> huh, that is pretty weird
18:36:39 <jkurik> I am -1 for the same reason as nirik has described
18:36:48 <adamw> if this happened consistently i'd be +1 blocker per the criterion i think, but since it's seemingly quite rare, -1
18:36:56 <stickster> puiterwijk: are you on 3.26.1 or 3.26.2?
18:37:03 <puiterwijk> stickster: RC6, so 3.26.1
18:37:21 <puiterwijk> (since this blocker bug meeting is about RC6 as far as I'm aware)
18:37:21 <stickster> gotcha. I'm trying the zero-day megaupdate recently.
18:37:25 <sgallagh> I've never seen this either
18:37:30 <stickster> I have 3.26.1 on my other machine though
18:37:31 <puiterwijk> I see this consistently
18:37:56 <adamw> huh
18:37:56 <puiterwijk> Well, semi-consistently. It happens everytime I log in, and then after a while fixes itself.
18:37:58 * sumantro too never saw this
18:37:59 <adamw> i wonder what the cause is
18:38:07 * adamw doesn't recall ever seeing it either
18:38:07 <sgallagh> I'm -1
18:38:32 <puiterwijk> I'm -1 to blocking, but just wanted to chime in that I can reproduce it
18:38:35 <sumantro> -1
18:38:39 <frantisekz> -1
18:38:43 <lbrabec> -1
18:38:44 <stickster> I'd be -1 to blocking but +1 for common-bugs'ing it
18:38:53 <adamw> i suppose it *could* be to do with the 'power' entry, which is directly below it
18:39:04 <adamw> happens when battery is <100% and system is plugged in? meh
18:39:05 <kparal> adamw: we've seen it on a desktop
18:39:05 <dustymabe> -1, if this is the worst thing that happens then I think we did pretty good :)
18:39:13 <mattdm> adamw: that seems like the only reasonable theory I can think of too
18:39:15 <adamw> kparal: was it a desktop with a UPS? :)
18:39:21 <kparal> nope
18:39:22 <puiterwijk> adamw: on my screenshot, the battery is fully charged
18:39:23 <stickster> adamw: in puiterwijk's case, bluetooth is directly below
18:39:30 <adamw> dustymabe: oh, i can give you a list of worse things if you like :P
18:39:31 <puiterwijk> But yeah, bluetooth is below
18:39:34 <adamw> huh.
18:39:41 <adamw> welp, anyway, that's pretty solid -1 vote.
18:39:47 <dustymabe> adamw: /me likes to live in happy land
18:39:50 <stickster> dustymabe: "is this the one thing you'd hold for" ?
18:40:09 <stickster> dustymabe: me too, I call it the liquor cabinet
18:40:18 <mattdm> I'd like to make sure we get this at least triaged and to the attention of developers who can do something about it.
18:40:34 <adamw> proposed #agreed 1497897 - RejectedBlocker (Final) - since this doesn't happen consistently (and doesn't seem to affect many people at all), and the entry still works, we don't think this is serious enough to constitute a violation of the criterion. We will document it in CommonBugs
18:40:38 <mattdm> stickster: are you speaking for Workstation in this meeting?
18:40:38 <frantisekz> ack
18:40:39 <stickster> mattdm: for sure it would make sense to reproduce after the GNOME 3.26.2 megaupdate
18:40:41 <mattdm> adamw: ack
18:40:42 <lbrabec> ack
18:40:43 <puiterwijk> ack
18:40:44 <sumantro> ack
18:40:51 <stickster> mattdm: I think I'm the only person here from there, so... sure!
18:41:03 <mattdm> stickster: can you carry this to whoever might be able to actually do something about it?
18:41:07 <stickster> mattdm: yes
18:41:08 <adamw> #agreed 1497897 - RejectedBlocker (Final) - since this doesn't happen consistently (and doesn't seem to affect many people at all), and the entry still works, we don't think this is serious enough to constitute a violation of the criterion. We will document it in CommonBugs
18:41:24 <adamw> #topic (1510301) PulseAudio sometimes does not restart properly after logging out
18:41:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1510301
18:41:25 <adamw> #info Proposed Blocker, pulseaudio, NEW
18:41:37 <mattdm> #dontdothat
18:41:42 <adamw> heh
18:41:50 <adamw> yeah, i'm still -1 as voted in bug.
18:42:09 <adamw> we can document 'wait 20 seconds to log back in'.
18:42:30 * nirik is -1
18:42:31 * sumantro is -1 on this too
18:42:34 <frantisekz> -1
18:42:59 * mboddu is -1
18:43:00 <lbrabec> -1
18:43:10 <mattdm> Mantra here: we recognize this as a real bug, but not all bugs are blockers, or we'll never ever ship
18:43:34 <jkurik> -1; we have a workaround - having a coffee between logout and login solves the issue :-)
18:43:46 <sgallagh> -1
18:43:58 * stickster -1 but would be nice to see this not be annoying soon :-)
18:44:16 <kparal> I believe it's a blocker but discovered so late it's fine to postpone it to the next release
18:44:27 <stickster> I ran into it today myself but it was purely the specific issue of "log out and back in right away"
18:44:32 <kparal> but seems I'm outvoted anyway
18:44:37 <adamw> worth asking
18:44:48 <adamw> is anyone just -1 because this is late, and would vote +1 to f28finalblocker?
18:44:52 <stickster> kparal: not that we don't 💙 you
18:45:02 <adamw> i think i'm still -1 to f28final, it just doesn't quite reach the criteria for me.
18:45:07 <stickster> I would be -1 to f28final as well
18:45:16 <sgallagh> I'm firmly -1
18:45:21 <mattdm> adamw: no, I'm voting for "not blocker"
18:45:25 <jkurik> I would be -1 even for F28
18:45:25 <adamw> roger.
18:45:26 <kparal> stickster: why is that heart cold blue on my screen?
18:45:33 <stickster> kparal: it's Fedora blue!
18:45:38 <stickster> that was on purpose ;-)
18:45:54 <mattdm> I am also not sure I'd accept this as a prioritized bug. What was that dustymabe said about "if this is the worst thing..."?
18:46:05 <stickster> lolyup
18:46:07 <nirik> kparal: perhaps you prefer 💖 ?
18:46:08 <sgallagh> 💔
18:46:09 <sumantro> -1 on f28 too
18:46:10 <kparal> well, then I'm still outvoted :)
18:46:28 <adamw> proposed #agreed 1510301 - RejectedBlocker (Final) - we agreed that this is an annoyance, but clearly doesn't constitute a criteria violation, and it's reasonable to just document 'wait 20 seconds to log back in again (or change the config setting)'
18:46:30 <kparal> I guess I need to install that emoji keymap
18:46:35 <kparal> feel like outsider without it
18:46:40 * stickster using GNOME Characters
18:46:47 <jkurik> adamw: ack
18:46:50 <adamw> .fire everyone who uses emojis
18:46:50 <zodbot> adamw fires everyone who uses emojis
18:46:53 <stickster> lol
18:46:58 <mboddu> ack
18:46:59 <lbrabec> ack
18:47:01 <sumantro> ack
18:47:02 <stickster> ack
18:47:08 <gholms> Heh
18:47:09 <kparal> ack
18:47:10 <sgallagh> ack
18:47:34 <adamw> #agreed 1510301 - RejectedBlocker (Final) - we agreed that this is an annoyance, but clearly doesn't constitute a criteria violation, and it's reasonable to just document 'wait 20 seconds to log back in again (or change the config setting)'
18:48:23 <adamw> that's all the proposed blockers for Final
18:48:27 <adamw> do we do Server Beta now?
18:48:55 <jkurik> sgallagh: can we continue with F27 Modular Server Beta - blocker review ? ^^^
18:48:56 * nirik had a issue to bring up. I don't think it's a blocker, but it might cause some pain/we should decide what to do about it.
18:48:58 <mattdm> i think we say "ship it" to this one first
18:49:03 <mattdm> please :)
18:49:04 <nirik> (can wait until after server)
18:49:26 <adamw> well, now we have three choices!
18:49:43 <puiterwijk> I had an issue I just filed as well (forgot to do so in the last few hours), but not sure whether multi-monitor is important on live images
18:49:46 <nirik> or we could all go get beer?
18:49:56 <nirik> man, 5 choices.
18:50:05 <stickster> nirik: +∞
18:50:05 <jkurik> ok, so lets finish the F27 Final and then we can return back to the Modular Server
18:50:11 <mattdm> eyes please
18:50:15 <mattdm> lol "yes"
18:50:17 <stickster> +1
18:50:19 <mattdm> eyes too I guess
18:50:42 <adamw> ok, fine
18:50:48 <adamw> so, we should consider nirik and puiterwijk's issues
18:50:54 <adamw> (and then reject them and get a drink)
18:51:03 <nirik> :) ok, shall I go first?
18:51:11 <jkurik> nirik: yes please :-)
18:51:14 <nirik> The satyr package had a f27 buildroot override, so it was used until it expired yesterday. (ie, RC1.6 used it). Today, f27 nightly compose fails because the override expired. The old satyr causes anaconda-core to have broken deps.
18:51:14 <nirik> Problem: package anaconda-core-27.20.4-4.fc27.x86_64 requires libreport-anaconda >= 2.0.21-1, but none of the providers can be installed
18:51:14 <nirik> - package lorax-lmc-novirt-27.11-1.fc27.x86_64 requires anaconda-core, but none of the providers can be installed
18:51:14 <nirik> - package libreport-anaconda-2.9.3-1.fc27.x86_64 requires libreport = 2.9.3-1.fc27, but none of the providers can be installed
18:51:29 <adamw> I don't understand this.
18:51:33 <adamw> what do you mean when you say "used"?
18:51:41 <adamw> buildroot overrides don't go into composes.
18:51:43 <nirik> so, the old saytr is in the rc1.6 repos. but the newer one is likely on livemedia
18:52:06 <adamw> wait, buildroot override packages get pulled into live composes?
18:52:12 <adamw> that's...that's a problem.
18:52:15 <nirik> someone have a f27 rc6 live up? can you rpm -q satyr ?
18:52:23 <mattdm> .fire the entire buildsyste
18:52:23 <zodbot> adamw fires the entire buildsyste
18:52:26 <mattdm> m
18:52:32 * kparal boots
18:52:33 <nirik> well, I am not sure of the scope here either.
18:52:51 <adamw> but regardless, if anaconda has dep problems with the old package, how did the compose work and produce installer images that boot?
18:52:55 <puiterwijk> nirik: satyr-0.23-6.fc27.x86_64
18:53:02 <puiterwijk> (but that's post-install)
18:53:14 <puiterwijk> Sorry, that's useless obviously
18:53:23 <kparal> satyr-0.23-6.fc27.x86_64 from Live as well
18:53:30 <nirik> huh, interesting.
18:54:02 <sumantro> satyr-0.23-6.fc27.x86_64 on live
18:54:10 <adamw> what version is anaconda?
18:54:12 <nirik> ok, thats the old one
18:54:16 <adamw> anaconda-core
18:54:35 <kparal> anaconda-27.20.4-4.fc27.x86_64
18:54:38 <adamw> okay.
18:54:42 <adamw> nirik: oh, could these be BuildRequires?
18:54:57 <adamw> wait, no, that doesn't make sense.
18:54:58 <nirik> no, thats from a kde live compose failure
18:55:00 <adamw> they're binary packages.
18:55:08 <sumantro> adamw, anaconda-27.20.4-4.fc27.x86_64
18:55:34 <adamw> nirik: what caused you to decide the dep issue traces back to satyr?
18:55:41 * nirik appologizes that this isn't fully debugged. just saw it this morning
18:55:50 <puiterwijk> nirik: do note that we had a stable push for anaconda last night
18:56:10 <puiterwijk> So I'm going to guess it might be that new stable push request that dragged in the anaconda that broke stuff
18:56:30 <nirik> - nothing provides satyr >= 0.24 needed by libreport-2.9.3-1.fc27.x86_64
18:56:52 <kparal> libreport-2.9.2-1.fc27.x86_64 on Live
18:56:56 <kparal> which is older
18:56:56 <adamw> oh
18:56:57 <nirik> ah ha.
18:56:59 <puiterwijk> So, yeah, anaconda-27.20.4-4.fc27 was pulled in last night's stable request by adamw
18:57:01 <adamw> that libreport itself has a buildroot override
18:57:11 <adamw> it's not tagged f27
18:57:19 <adamw> but is tagged f27-override
18:57:23 <nirik> so we could kill that libreport override and be ok?
18:57:33 <adamw> yeah. either kill that, or resurrect the satyr override.
18:57:37 <jkurik> do I understand it correctly that it does not affect the RC we have, but might affect further RCs if we are No-Go ?
18:57:49 <adamw> i think it doesn't affect the RC and also wouldn't affect future RCs
18:57:50 <nirik> jkurik: yeah, seems so
18:57:52 <adamw> but it *does* affect nightlies
18:57:54 <adamw> but...imbw
18:57:57 <jkurik> if so, then we need to be GO
18:58:00 <nirik> :)
18:58:05 <adamw> anyway, it clearly doesn't affect the current RC.
18:58:08 <nirik> ok, so this is a non issue, move along.
18:58:08 <adamw> so, i think we're okay.
18:58:12 <mattdm> \o/
18:58:20 <nirik> thanks everyone. :)
18:58:23 * dustymabe saw mattdm sweating
18:58:27 <mattdm> those are good words for an FPL to hear
18:58:31 <mattdm> not the sweating. the other stuff.
18:58:39 <adamw> (though i would like to look into this issue of whether things with buildroot overrides get pulled into RC live composes, because if so, we could have a source/binary mismatch problem and hence technically licensing violations...)
18:58:42 <jkurik> puiterwijk: now your issue please
18:59:04 <stickster> adamw: great, now mattdm can sweat again
18:59:10 <adamw> i'm helping!
18:59:17 <stickster> PRETTY SURE YOU ARE
18:59:22 <puiterwijk> So, I found this morning that the display ordering widget in gnome 3.26 just doesn't work, making it basically impossible to order multiple displays correctly.
18:59:33 * stickster has a call in 1 minute but will try to stay tuned
18:59:33 <puiterwijk> And I'm not sure whether we consider multi-display workflows for live images
18:59:39 <kparal> adamw: maybe add a #topic
18:59:42 <adamw> i mean, depends what you mean by 'consider'.
18:59:56 <adamw> that sounds odd, though, i'm sure i used it earlier this cycle.
18:59:58 <adamw> kparal: oh right
19:00:04 <adamw> #topic miscellaneous F27 Final issues
19:00:05 <puiterwijk> Well, if it would be important enough to be possible seen as a blocker basically.
19:00:08 <bowlofeggs> mattdm: don't sweat the petty stuff, and don't pet the sweaty stuff
19:00:14 <adamw> puiterwijk: bz?
19:00:17 <puiterwijk> I totally forgot to file this earlier today, sorry for that. https://bugzilla.redhat.com/show_bug.cgi?id=1511638
19:00:35 <kparal> puiterwijk: did you have 3 displays?
19:00:45 <kparal> it's broken for 3 displays, even if 1 is disabled
19:00:46 <puiterwijk> kparal: I have two external ones, and a closed laptop lid
19:00:46 <kparal> iirc
19:00:50 <kparal> that's it
19:00:58 <kparal> the same problem here
19:01:00 <adamw> okay. i just tried it with two displays and it worked.
19:01:00 <puiterwijk> (the laptop lid is not shown in the widget )
19:01:07 <kparal> I know
19:01:22 <puiterwijk> adamw: okay, then it's probably just weird stuff with my system. It's just repeatable, and happens every time. But okay :)
19:01:26 <kparal> it can be made work, if you know how to wiggle those boxes. it's tricky :)
19:01:35 <adamw> sounds like kparal has a handle on it
19:01:44 <adamw> kparal: is there a bz?
19:01:47 <puiterwijk> kparal: yeah, it's just really annoying and doesn't "feel" like it works
19:01:51 <mattdm> handles are probably useful for wiggling boxes
19:02:13 <adamw> man, this crazy precise technical language we use must be so baffling to outsiders
19:02:31 <kparal> adamw: I don't recall. either I forgot to report it, or found an upstream bug but can't find it now
19:02:34 <puiterwijk> adamw: you mean it isn't baffling to insiders?
19:02:37 <adamw> =)
19:02:47 * puiterwijk has no idea what he's talking about here
19:02:59 <adamw> i was just laughing at the box wiggling
19:03:12 <adamw> like, what level of box wiggling do we consider unacceptable in a Quality Fedora Release
19:03:21 <adamw> do we consider size of box, or amplitude of wiggle, or frequency...
19:03:24 <kparal> :D
19:03:31 <puiterwijk> :-)
19:03:51 <adamw> okay, so yeah, this doesn't feel blockery to me
19:03:54 <adamw> anyone else super concerned?
19:03:57 <sgallagh> nope
19:04:05 <kparal> 3 monitors is not that common
19:04:11 <jkurik> do we have a clue how many people using Fedora with 3+ screens
19:04:15 * mattdm recites earlier mantra
19:04:15 <puiterwijk> kparal: until you go to a RH office.... :)
19:04:19 <kparal> right
19:04:38 <mattdm> jkurik: It's a reasonably common developer use case. Especially "two plus closed laptop"
19:04:41 <mattdm> We should support it
19:04:42 <puiterwijk> jkurik: go to a RH office (e.g. Munich), and about everyone does
19:04:54 <puiterwijk> However, I think the important question is: do we care about this for the live images.
19:04:55 <mattdm> but it also shouldn't be a blocker
19:04:59 <puiterwijk> Sincei t can probably be fixed with an update
19:05:01 <jkurik> puiterwijk: it is the same in Brno
19:05:18 <mattdm> because that. :)
19:05:33 <nirik> Did the big monitor rework land in 2.26 or was that a 2.28 thing?
19:05:34 <adamw> probably worth documenting, if the magic wiggling method can be cleanly described
19:05:56 <kparal> adamw: I don't think so
19:05:58 <puiterwijk> adamw: not really... My solution is to "just try it a bunch of times, sometimes it magically works"
19:06:26 <nirik> I guess it was 2.26...so likely fallout from that.
19:06:29 <puiterwijk> And sometimes I need to totally close gnome settings and reopen and it suddenly snaps into place
19:06:37 <puiterwijk> nirik: 2.26 I think
19:06:37 <kparal> I think there's basically an invisible box somewhere (the closed lid) and you have to drag other screens around it
19:06:46 <nirik> https://bugzilla.gnome.org/show_bug.cgi?id=777732
19:07:18 <adamw> nirik: thanks
19:07:35 <nirik> well, that was tracking the rework, not this bug...
19:07:48 <adamw> yeah, worth keeping in mind though.
19:09:27 <mattdm> afk for a minute
19:09:40 * stickster is still lurking while on call
19:09:50 <adamw> #info we considered a couple of issues raised by nirik and puiterwijk, but concluded neither needs to concern us too much
19:09:59 <adamw> that do?
19:10:01 * nirik nods.
19:10:15 <puiterwijk> Yep, agreed
19:10:27 <puiterwijk> Just figured I'd bring it up in case anyone cared about multi-monitor on live
19:11:07 <jkurik> ok, so no more blockers and we can move on, right ?
19:12:01 <stickster> agreed
19:12:07 <nirik> yep
19:12:09 <jkurik> #topic F27 Final Test Matrices coverage
19:12:16 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.6_Summary - Test matrices for the F27 Final
19:12:57 <adamw> i haven't transferred in transferrable results from earlier RCs, sorry
19:13:00 <adamw> been sidetracked with other stuff
19:13:13 <kparal> I have
19:13:37 <adamw> thanks kparal
19:14:02 <kparal> I might have missed something
19:14:06 <adamw> so we didn't test kde live written to a cd, but eh, if workstation worked there's zero reason kde wouldn't
19:14:17 <kparal> adamw: not blocking, though
19:14:20 <jkurik> excluding the Server, it looks quite covered for me
19:14:25 <adamw> and we're missing xen, but we've done all we can about that, we keep waiting on konrad
19:14:52 <jkurik> I would personally consider the coverage as sufficient
19:14:53 <kparal> somebody from releng could check the checksums
19:15:01 <adamw> yup
19:15:07 <kparal> it's pretty expensive to do that from the outside world
19:15:11 <adamw> yeah
19:15:21 <adamw> who was that guy who always used to run those tests?
19:15:25 <jkurik> mboddu: can we ask you to do the checksums ?
19:15:30 <adamw> iirc we gave him ssh access somewhere so he could do that test
19:15:37 <kparal> robatino?
19:15:43 <mboddu> jkurik: sure
19:15:51 <jkurik> mboddu++
19:15:51 <zodbot> jkurik: Karma for mohanboddu changed to 12 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:15:58 <mboddu> kparal: Is that the same thing that I did last time?
19:16:04 <kparal> mboddu: yes
19:16:12 <mboddu> kparal: Okay, give me few min
19:16:28 * mboddu goes and searches for his script
19:16:40 <kparal> we even talked about automatically checking checksums in the script that copies it to stage
19:17:10 <adamw> kparal: yeah, robatino
19:17:17 <adamw> wonder what's going on with him...
19:17:23 <kparal> base startup test case for EC2 is missing
19:17:32 <kparal> cloud and atomic (not blocking)
19:17:42 <adamw> anyone can test it for cloud quick?
19:17:48 <dustymabe> sup
19:17:48 <kparal> I didn't want to transfer that from RC1.3, it's base startup after all
19:17:58 <dustymabe> i can test EC2
19:18:06 <mattdm> dustymabe++
19:18:06 <zodbot> mattdm: Karma for dustymabe changed to 19 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:18:06 <dustymabe> i'm pretty sure I have already but will anyway
19:18:18 <mattdm> because I can't because I have crappy internet right now :(
19:19:37 <jkurik> assuming the checksums are OK (and EC2 is non-blocking) shall we move to Go/No-Go to speet things up ?
19:20:37 <mattdm> jkurik: that sounds reasonable
19:20:44 <adamw> cloud ec2 is blocking, isn't it?
19:20:44 <jkurik> ok, so
19:20:47 <adamw> atomic ec2 isn't
19:21:05 <jkurik> adamw: ah you are right, so lets wait a bit
19:21:05 <adamw> yeah
19:21:10 <adamw> also, we have no openstack testing reported
19:21:14 <adamw> has anyone tested in openstack?
19:21:19 <nirik> side note: there's grumblings amazon is moving to kvm from xen if anyone cares. :)
19:21:25 <puiterwijk> adamw: I can do that quickly
19:21:27 <nirik> yes, I tested rc1 I think?
19:21:35 <puiterwijk> But I tested last week's RC in openstack
19:22:18 <mattdm> nirik: it's vaguely interesting but doesn't affect us all that much really
19:22:32 <mattdm> it's apparently their own kvm thing rather than qemu
19:22:34 <nirik> sure, just down the road xen may become even less interesting
19:24:22 <dustymabe> looking good so far
19:24:30 <dustymabe> half way through the test services test
19:24:31 <gholms> I suppose I should try Fedora on that new hypervisor and see what happens.
19:24:37 <dustymabe> which has two reboots in it btw
19:24:48 <jkurik> dustymabe: thanks
19:24:52 <dustymabe> or even more than that
19:24:53 <adamw> doesn't that mean base startup passed already?
19:25:10 <adamw> so, we can say things are probably fine for ec2
19:25:19 <dustymabe> yeah i was just going through them all
19:25:19 <adamw> be nice if someone could just boot up 1.6 on openstack quick
19:25:26 <puiterwijk> adamw: doing so
19:25:30 <adamw> yay
19:25:37 <puiterwijk> Just waiting for cloud-init
19:25:43 <puiterwijk> [fedora@test123 ~]$
19:25:44 <nirik> as always
19:25:54 <puiterwijk> So yes, openstack boots the x86_64 (and ppc64le) images
19:26:05 <puiterwijk> Don't ask why I did ppc64le... I misclicked :/
19:26:13 <jkurik> puiterwijk: thanks
19:26:16 <jkurik> so I will move to the Go/No-Go decision
19:26:24 <jkurik> #topic F27 Final Go/No-Go decision
19:26:30 <jkurik> QE, FESCo, RelEng - we need your Go/No-Go
19:26:38 <jkurik> nirik, adamw, sgallagh, mboddu ^^^
19:26:40 <nirik> 🚤 🚤 🚤 GO! 🚤 🚤 🚤
19:26:42 <sgallagh> I'm Go
19:26:53 <jkurik> I am GO as well (for the record)
19:26:59 * mattdm not on the list, but GO GO GO!
19:27:07 * mboddu still testing the checksums, but otherwise GO
19:27:35 <jkurik> adamw, kparal: how about you ?
19:27:59 <kparal> GO (provided the checksums pass)
19:28:12 <jkurik> kparal: sure, thanks
19:29:10 <jugs> what's the new go date?
19:29:10 <adamw> qa votes go based on matrix coverage and lack of outstanding blockers
19:29:19 <adamw> (assuming checksums pass)
19:29:36 <mattdm> jugs: tuesday
19:29:42 <jugs> mattdm: thx
19:29:46 <mattdm> assuming checksums pass :)
19:29:53 <adamw> yay, the train has sailed
19:29:53 <jugs> lol is there an echo in here?
19:30:09 <adamw> YESYESYesYesyesyes
19:30:20 * mboddu is in pressure, everyone waiting for me
19:30:29 <adamw> jiiiiiiiiiiiiii
19:31:15 <nirik> ⌚
19:31:30 <puiterwijk> tick-tock-tick-tock-...
19:31:33 <jkurik> proposed #agreed The Fedora-27-20171105.0 compose is considered as GOLD and is going to be shipped on 2017-Nov-14 as Fedora 27 Final release.
19:31:43 <gholms> \o/
19:31:43 <jkurik> waiting on mboddu :-)
19:32:41 * mattdm buys mboddu more iops
19:33:08 <kparal> maybe we can discuss Modular Server in the meantime
19:33:28 * puiterwijk takes mattdm's joke and puts it in an email as "promised funding"
19:33:52 <kparal> mboddu: do you have an estimate how long it will take?
19:34:21 <mattdm> puiterwijk: :)
19:34:32 <adamw> kparal: well, now he has to write a script to estimate how long the script will take
19:34:37 <adamw> ...and i think now we're an xkcd comic
19:34:54 <mattdm> if we're not in an xkcd comic, we are not fedoraing enough
19:35:54 <sgallagh> mattdm: I'm quoting you on that
19:35:59 <mboddu> https://paste.fedoraproject.org/paste/jjpbDxl0gTnIY1xb82iSoQ sha256sum is done
19:36:26 <mattdm> spoiler: done *AND ALL OK*
19:36:34 <mboddu> checkisomd5 is running now
19:36:40 <jkurik> \o/
19:36:47 <mboddu> still running*
19:40:10 <jkurik> proposed #agreed The Fedora-27-20171105.0 (Fedora_27_RC_1.6) compose is considered as GOLD and is going to be shipped on 2017-Nov-14 as Fedora 27 Final release.
19:40:17 <sgallagh> ack
19:40:30 <jkurik> may I have your acks till the MD5 is running ?
19:40:48 <kparal> ack
19:40:52 <mattdm> jkurik: ack
19:40:58 <adamw> ack, assuming checkisomd5 passes.
19:40:59 <mboddu> kparal: https://paste.fedoraproject.org/paste/3NETujXpr-OuLhx8Qus1YQ
19:41:10 <jkurik> adamw: sure thing
19:41:36 <mboddu> adamw, kparal : checkisomd5 failed on Fedora-Server-dvd-armhfp-27-1.6.iso and Fedora-Server-dvd-i386-27-1.6.iso
19:41:42 * mboddu remember same thing last time
19:41:58 <adamw> neither of those blocks or is even going to be shipped, so eh.
19:42:01 <puiterwijk> it also failed on i386
19:42:14 <puiterwijk> Never mind, Mohan said that
19:43:16 <jkurik> hmm.. these are non-blocking so shall we ship it eve the md5 is not correct ?
19:43:22 <adamw> yes.
19:43:23 <mboddu> puiterwijk: Yep, both on Server DVD armhfp and i386, but I remember vaguely that same thing happened during F27 Beta
19:43:34 <adamw> like i said, these images will be stripped frm the release anyway, aiui.
19:43:38 <puiterwijk> jkurik: well, I don't think we are going to ship a "normal" (non-modular) server, right?
19:43:54 <jkurik> puiterwijk: correct
19:44:03 <jkurik> #agreed The Fedora-27-20171105.0 (Fedora_27_RC_1.6) compose is considered as GOLD and is going to be shipped on 2017-Nov-14 as Fedora 27 Final release.
19:44:05 <puiterwijk> jkurik: since they're both "normal" server, we would strip them
19:44:08 <puiterwijk> \o/
19:44:20 <jkurik> More fun ahead
19:45:04 <mattdm> yay
19:45:10 <jkurik> adamw: would you like to chair Mini-blocker review for the F27 Modular Server Beta release ?
19:45:12 <mattdm> awesome work everone. thank you!
19:45:28 <langdon> all++
19:45:59 <adamw> there are no proposed blockers for server beta
19:46:01 <adamw> there are proposed FEs
19:46:06 <adamw> do we need to go through those, sgallagh?
19:46:13 <langdont> langdon: like my new name?
19:46:24 <sgallagh> adamw: There is one possible blocker
19:46:36 <dustymabe> :)
19:46:39 <adamw> sgallagh: it ain't showing up in proposed blockers...
19:46:41 <sgallagh> I thought I proposed it an hour ago, but it seems I didn't
19:46:59 <sgallagh> .bug 1508576
19:46:59 <zodbot> sgallagh: Bug 1508576 – freeipa module installation fails - https://bugzilla.redhat.com/1508576
19:46:59 <jkurik> #topic Mini blocker review for F27 Modular Server Beta release
19:47:14 <sgallagh> This bug has *changed* since it was first proposed. It's technically a diffent bug, but here we are
19:47:48 <sgallagh> There was a bug in MBS that hit RC1.5 and resulted in the "fonts" module not being included in Server
19:48:00 <jkurik> #link https://bugzilla.redhat.com/1508576
19:48:03 <adamw> i think we've required freeipa to work from the media, for regular releases before
19:48:03 <sgallagh> Which in turn results in FreeIPA not being installable via rolekit (which is a blocker)
19:48:14 <jkurik> #info  Bug 1508576 – freeipa module installation fails
19:48:15 <adamw> i can maybe live with being a bit sloppier for a first release of modular beta, though
19:48:45 <sgallagh> Right, so what I'm kind of asking for is for this to be a zero-day blocker where I commit to making sure the fix is in the repos before Tuesday
19:49:14 <jkurik> I am fine to be relaxed for the Modular Beta release
19:49:18 <sgallagh> We have a compose running to do just this. I have tested that it works by pointing my RC1.5 install at the interim compose tree at https://kojipkgs.fedoraproject.org/compose/Fedora-Modular-27-20171109.n.2/compose/Server/
19:49:38 <jkurik> sgallagh: I am +1 for 0day
19:49:39 <adamw> to unpack that a bit: in practice, any time you deploy freeipa from an installed Server system, it's gonna pull from the repos
19:49:41 * mboddu notes that he just kicked off another nightly which will put the fix in the repos
19:50:16 <adamw> in order to deploy freeipa from the packages actually included in the compose you'd have to install it during initial system install (probably via kickstart) or tweak the repo config post-install
19:50:24 <langdon> i am a little confused on this though.. would we rsync a new rc as well?
19:50:40 <mboddu> langdon: nope, no new RC
19:50:54 <jkurik> langdon: the existing RC + 0day
19:50:56 <langdon> ok.. that makes sense
19:51:26 <adamw> deploying a freeipa server via kickstart does sound like a thing someone out there probably does, frankly, but we can probably live with it being broken for this first beta.
19:51:34 <adamw> so i'm okay with +1 accepted0day.
19:51:41 <mattdm> me too
19:51:49 <jkurik> I am +1 to 0day as well
19:51:58 <sgallagh> Obviously, I’m also +1 to 0day
19:52:00 <mattdm> I think i have a #shippit hashtag around here somewhere
19:52:09 <nirik> +1 to 0day
19:52:35 <sgallagh> For the record, I’ve also manually tested the rest of the server-specific criteria:
19:53:14 <mboddu> I am +1 0day
19:53:17 <sgallagh> AD client and FreeIPA client works out of the box, as does Cockpit, firewalld and networkmanager
19:53:39 <sgallagh> And the database server role also
19:54:04 * mattdm has to take off. I'll leave my hashtag for someone else to use :)
19:54:08 <adamw> #shipthetrain
19:54:17 <sgallagh> ...wreck? ;-)
19:54:45 <jkurik> adamw: may I ask you please to come up with some proposed #agreed ?
19:54:55 <adamw> ok
19:55:40 <adamw> #topic (1508576) freeipa module installation fails
19:56:08 <adamw> #info Proposed Blocker, fedora-modular-release, ASSIGNED
19:56:22 <adamw> sgallagh: oh - you have to remove the RejectedBlocker whiteboard field for it to show up as proposed again
19:56:41 <adamw> sgallagh: blockerbugs will see RejectedBlocker in the whiteboard and treat it as rejected, even if it's still/again set as blocking the tracker
19:56:48 <sgallagh> roger
19:56:48 <adamw> that's why it didn't show up
19:57:49 <adamw> proposed #agreed 1508576 - Accepted0Day (Server Beta) - clearly violates the requirement for release-blocking roles to be deployable. sgallagh states that this can be fixed in a new compose and thus will work for all typical post-install deployments which pull from the repositories, which we consider sufficient for a first release of Modular Server B eta
19:57:58 <adamw> (without the extra space...)
19:58:09 <sgallagh> ack
19:58:12 <jkurik> ack
19:58:17 <sumantro> ack
19:58:38 <mboddu> ack
19:58:41 <puiterwijk> ack
20:00:29 <adamw> #agreed 1508576 - Accepted0Day (Server Beta) - clearly violates the requirement for release-blocking roles to be deployable. sgallagh states that this can be fixed in a new compose and thus will work for all typical post-install deployments which pull from the repositories, which we consider sufficient for a first release of Modular Server Beta
20:00:32 <jkurik> adamw, sgallagh: that is all for blockers, right ?
20:00:35 <adamw> yes
20:00:38 <jkurik> #topic F27 Modular Server Beta Test Matrices coverage
20:00:39 <sgallagh> Yes
20:00:40 <adamw> i dunno if sgallagh needs us to review the proposed FEs
20:00:46 <jkurik> #info QA is using F27 Modular Server Beta Release criteria instead of Test Matrices
20:00:49 <sgallagh> adamw: If we're shipping RC5, no need
20:00:56 <sgallagh> err 1.5
20:01:01 <jkurik> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria - F27 Modular Server Beta Release criteria
20:01:12 <jkurik> Proposed #agreed The testing, given the state of F27 Modular Server Beta release, is considered as sufficient for the purpose of Beta release.
20:02:17 <adamw> "it's crap, so we didn't test it too hard"? :P
20:02:35 <langdon> thats probably a touch harsh :/
20:02:43 <adamw> i know, it's just how it reads :)
20:02:49 <jkurik> adamw: do you want to patch the wording with your statement ? :-)
20:02:49 <adamw> let's maybe break it out a bit
20:02:53 <adamw> for the record
20:02:56 <gholms> Haha
20:03:09 <adamw> we know openQA testing covers most of the server-specific requirements
20:03:19 <adamw> the one it doesn't cover is Active Directory client, which sgallagh has tested
20:03:30 <adamw> openQA should also cover the base requirements
20:04:27 <adamw> then there's the installation requirements; openQA covers some of those, and we could argue that we can consider the non-modular tests as applicable here to some extent, since modular is using the same anaconda
20:04:37 <adamw> there's always the possibility that bits could be missing from the modular compose images, though, i guess.
20:07:04 * adamw looks at installation requirements openqa doesn't cover
20:07:14 <jkurik> proposed #agreed The RC was tested using OpenQA, covering most of the server-specific requirements and base requirements. The OpenQA also covers some of installations requirements and non-modular tests are applicable to the modular release to some extent. Active Directory client has been tested manually. As such, we consider the testing coverage as sufficient.
20:07:36 <adamw> well, there's checksums.
20:07:51 <adamw> there's pxe boot.
20:08:18 <adamw> there's the RAID install tests.
20:08:30 <pwhalen> fwiw, pxe works on arm and aarch64
20:08:39 <adamw> VNC.
20:08:43 <adamw> pwhalen: with modular server?
20:08:47 <pwhalen> yes
20:08:50 <adamw> okay, cool
20:09:24 <mboddu> checksums again?
20:09:36 * mboddu goes and does it for modular
20:09:57 <jkurik> mboddu: I read it as "OpenQA covers checksums"
20:10:00 <adamw> basic video, serial console...
20:10:01 <adamw> no
20:10:05 <adamw> mboddu is right
20:10:09 <adamw> i'm listing off things openQA *doesn't* cover
20:10:17 <adamw> and thus which we have not necessarily tested yet
20:10:26 <adamw> if you actually *have* tried these things with modular server, please yell
20:10:33 <jkurik> ah, ok
20:10:54 <pwhalen> vnc I've tested on aarch64, serial console works on arm and aarch64
20:10:58 <langdon> adamw: "basic video" like running it and seeing a graphical or command line screen? or "more basic"
20:11:20 <adamw> langdon: it means the 'Basic Video Mode' option that runs with nomodeset
20:11:29 <langdon> adamw: ahh gotcha .. sorry
20:12:19 <mboddu> jkurik, adamw : Just started the testing, I can give you the results in few min
20:12:23 <adamw> okay
20:12:31 <jkurik> mboddu: thanks
20:12:54 <adamw> anaconda crash reporting...
20:13:04 <adamw> sgallagh: can you comment on any of those?
20:13:31 <kparal> adamw: basic video makes only sense to DE-enabled systems, no? server boots to text mode by default, doesn't it?
20:13:39 <sgallagh> Sorry, I got pulled into a meeting.
20:13:42 * sgallagh reads scrollback
20:14:12 <sgallagh> adamw: What's the specific question?
20:15:04 <mboddu> adamw: https://paste.fedoraproject.org/paste/3FacBkLFEAYuecbqYmcz0A and same thing here checkisomd5 failed on Fedora-Modular-Server-dvd-armhfp-27_Beta-1.5.iso and Fedora-Modular-Server-dvd-i386-27_Beta-1.5.iso
20:15:11 <jkurik> sgallagh: whether there was any testing done on the test cases adamw listed above
20:15:27 <mboddu> adamw: And I guess armhfp is a release blocking arch?
20:16:00 <kparal> yep
20:16:07 <pwhalen> the armhfp iso's aren't used at all
20:16:11 <puiterwijk> Hmm, the wiki says no.
20:16:25 <puiterwijk> The wiki says only dvd and netinst for x86_64 are blocking
20:16:28 * kparal tries to find the link
20:16:31 <puiterwijk> kparal: https://fedoraproject.org/wiki/Releases/27/ReleaseBlocking#Modular_Server
20:16:38 <puiterwijk> That's what I'm looking at
20:16:38 <langdon> i believe that is correct
20:16:42 <adamw> yeah, for server we only block on x86_64 i believe.
20:16:49 <adamw> this isn't new with modular server either.
20:16:59 <adamw> the logic being there's not really any 32-bit ARM hardware you'd reasonably want to run servers on.
20:17:11 <sgallagh> I have not specifically tested serial boot or nomodeset, no
20:17:12 <kparal> that's news to me. ok
20:17:13 <mboddu> puiterwijk: phew, good
20:17:19 <langdon> but we are trying to get more of them going for GA.. i think only armhfp is a problem.. basically inexplicable build problems
20:17:22 <adamw> do we know what's wrong with the checksums, though? it *is* worrying that they fail.
20:18:03 <adamw> so, i kinda would like to have a bit more installation test coverage, but not sure if it's fair to slip the release at this point for not having it
20:18:13 <adamw> it does feel a bit like we're rushing things, though, and we should be more careful for final
20:18:21 * sgallagh agrees
20:18:32 * mboddu agrees as well
20:18:37 <nirik> adamw: the only checksums that fail are the arm ones that don't exist. ;)
20:19:04 <nirik> oh, they exist but aren't working I guess.
20:19:05 <adamw> what about i386?
20:19:14 <mboddu> nirik: they exist
20:19:31 * nirik wonders if it's the isomd5sum 32bit but
20:19:32 <nirik> bug
20:20:00 <nirik> yeah, bet it is
20:20:23 <adamw> sounds plausible
20:20:26 <nirik> 1497458 fixed in isomd5sum-1.2.2-1.fc28
20:20:33 <adamw> in which case, image verification really will be broken for those iamges?
20:20:42 <nirik> modular is using 1.2.1-4
20:21:02 <nirik> hum, no.
20:21:06 <nirik> it is using the fixed one.
20:21:10 <nirik> oh well, not sure then
20:21:16 <adamw> so. something else?
20:21:24 <adamw> since the same images failed for Final, i guess.
20:21:28 <nirik> https://koji.fedoraproject.org/koji/buildinfo?buildID=979415
20:21:28 <adamw> anyhoo
20:21:32 <adamw> wait
20:21:47 <adamw> won't the key thing here be which isomd5sum is installed on *the system implanting the checksums*?
20:21:51 <adamw> not which version is in the compose?
20:22:16 <kparal> adamw++
20:22:17 <zodbot> kparal: Karma for adamwill changed to 11 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:22:25 <nirik> yeah, makes sense.
20:22:38 <nirik> the f27 ones are working tho?
20:22:48 <adamw> no, we got the same two images failed for f27 final
20:23:00 <adamw> though it's interesting it's only the server DVD images that fail, not anything else
20:23:05 <mboddu> adamw: compose-x86-02.phx2.fedoraproject.org is using isomd5sum-1.1.0-5.fc26.x86_64
20:23:11 <adamw> some difference in how checksums get implanted to live vs. non-live images or something i guess
20:23:21 <jkurik> so we should fix the test case then ?
20:23:26 <adamw> eh?
20:23:35 <adamw> what's wrong with the test case?
20:23:42 <nirik> well, it's likely in a runroot chroot... have to trace down to see where exactly.
20:23:45 <jkurik> I do not understand then
20:24:06 <adamw> we're saying this is likely a genuine problem and discussing a bit how to fix it for future composes.
20:24:22 <jkurik> ok
20:24:22 <mboddu> nirik: Oh just updating the builders might fix it as well
20:24:24 <adamw> but i guess we can say it doesn't block since we only block on x86_64.
20:24:27 <mboddu> s/Oh/Or
20:24:36 <nirik> I doubt it.
20:24:40 <adamw> so...where are we at?
20:24:57 <adamw> i guess i can ack that last proposal
20:24:58 <jkurik> Testing coverage
20:25:00 <adamw> a bit reluctantly
20:25:09 <adamw> it would've been nice to do more installer testing, but...we didn't
20:25:18 <adamw> and we kinda need to kick this thing out
20:25:28 <jkurik> adamw: you can come up with your own proposal, if you like
20:26:20 <adamw> nah, it's not the wording of the proposal i'm reluctant about
20:26:24 <adamw> just the state of the coverage :)
20:27:01 <jkurik> ok, nirik, mboddu, sgallagh: may I have your ack/patch to the proposal please ?
20:27:16 <sgallagh> jkurik: Which proposal? I lost track
20:27:16 * mboddu goes back and looks for the proposal
20:27:19 * nirik reads back up for it
20:27:27 <jkurik> proposed #agreed The RC was tested using OpenQA, covering most of the server-specific requirements and base requirements. The OpenQA also covers some of installations requirements and non-modular tests are applicable to the modular release to some extent. Active Directory client has been tested manually. As such, we consider the testing coverage as sufficient.
20:28:27 <sgallagh> ack
20:28:34 <nirik> ack
20:28:44 <mboddu> ack
20:28:46 <jkurik> #agreed The RC was tested using OpenQA, covering most of the server-specific requirements and base requirements. The OpenQA also covers some of installations requirements and non-modular tests are applicable to the modular release to some extent. Active Directory client has been tested manually. As such, we consider the testing coverage as sufficient.
20:28:50 <jkurik> #topic F27 Modular Server Beta Go/No-Go decision
20:28:56 <jkurik> QE, FESCo, RelEng - we need your Go/No-Go
20:29:10 <jkurik> sgallagh, nirik, adamw, kparal, mboddu ^^^
20:29:21 <sgallagh> I vote Go
20:29:24 <nirik> lets ship this beta... go
20:29:28 <jkurik> I am GO
20:29:42 <mboddu> GO
20:29:44 <sumantro> go
20:29:52 * mboddu wishes more testing but ehhh
20:30:02 <adamw> fine, whatever, ship the train
20:30:16 <adamw> QA raises telescope to blind eye, votes 'go'
20:30:28 <langdon> ha
20:31:32 <jkurik> proposed #agreed The Fedora-Modular-27-20171108.2 RC compose is considered as GOLD and is going to be shipped on 2017-Nov-14 as F27 Modular Server Beta release.
20:32:12 <jkurik> sgallagh, nirik, adamw, kparal, mboddu ^^^
20:32:20 <sgallagh> ack
20:32:22 <adamw> ack
20:32:27 <sumantro> ack
20:32:28 <nirik> ack
20:32:28 <mboddu> ack
20:32:43 <jkurik> #agreed The Fedora-Modular-27-20171108.2 RC compose is considered as GOLD and is going to be shipped on 2017-Nov-14 as F27 Modular Server Beta release.
20:32:46 <jkurik> #topic Open floor
20:32:57 <jkurik> anyone wants to add something ?
20:33:04 * mboddu has nothing
20:33:12 <kparal> I have the perfect QA emoji for releasing: 🙈
20:33:23 <langdon> woot!
20:33:24 <mboddu> kparal: whats that?
20:33:28 <langdon> sgallagh++
20:33:29 <kparal> it's a bit small
20:33:33 <mboddu> sgallagh++
20:33:33 <zodbot> mboddu: Karma for sgallagh changed to 21 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:33:38 <kparal> a qa monkey with hands over its eyes
20:33:42 <langdon> and, of course, all++
20:33:57 <mboddu> kparal: releng also needs that :)
20:34:10 <kparal> https://emojipedia.org/see-no-evil-monkey/
20:34:35 <langdon> the google one has his hands upside down :)
20:34:49 <nirik> and covered in cheese
20:34:53 <langdon> nirik: lol
20:35:35 <jkurik> kparal: is there UTF code for it ?
20:35:44 <adamw> haha, new team logo
20:35:55 <kparal> jkurik: it's on the page at the bottom
20:36:18 <jkurik> in case no one has anything, I will close the meeting in 1 minute
20:36:21 <jkurik> kparal: thanks
20:36:36 <sgallagh> jkurik++
20:36:36 <zodbot> sgallagh: Karma for jkurik changed to 5 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:37:26 <jkurik> #endmeeting