16:06:13 <roshi> #startmeeting F26-blocker-review
16:06:13 <zodbot> Meeting started Mon Jul  3 16:06:13 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:13 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:06:13 <roshi> #meetingname F26-blocker-review
16:06:13 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:06:14 <roshi> #topic Roll Call
16:06:27 <adamw> .hello adamwill
16:06:28 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
16:06:40 * tenk is here
16:06:58 <adamw> nirik: pwhalen: satellit: sgallagh: kparal: ping
16:07:01 <adamw> tflink: ping
16:07:01 <zodbot> adamw: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:07:08 <adamw> zodbot: ping off
16:07:09 <roshi> tflink is on PTO
16:07:10 <zodbot> pong
16:07:17 <roshi> lol
16:07:38 <roshi> #chair adamw mattdm zodbot nirik
16:07:38 <zodbot> Current chairs: adamw mattdm nirik roshi zodbot
16:08:10 <tenk> i am at europe for two mouth so i can participate meeting during day \o/
16:08:24 * nirik is here
16:08:59 <roshi> #topic Introduction
16:08:59 <roshi> Why are we here?
16:08:59 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:09:03 <roshi> #info We'll be following the process outlined at:
16:09:05 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:08 <roshi> #info The bugs up for review today are available at:
16:09:10 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:13 <roshi> #info The criteria for release blocking bugs can be found at:
16:09:15 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:09:18 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:09:21 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:11:26 <roshi> we got 4 last minute proposals to go through
16:11:27 <roshi> #topic (1467164) 26 Final RC-1.3 compose is missing 'custodia' package
16:11:31 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467164
16:11:33 <roshi> #info Proposed Blocker, distribution, NEW
16:11:57 * nirik already voted +1 in bug
16:12:05 <mattdm> mattdm + in bug
16:12:08 <mattdm> +1 that is
16:12:38 <tenk> +1
16:13:13 <roshi> what criteria? custodia on the default package list?
16:13:27 * roshi is drawing a blank on what it does
16:13:54 * mboddu is here
16:13:59 <adamw> roshi: freeipa can't be installed without it.
16:14:03 <nirik> no, on the critera that freeipa needs it, which is a server role
16:14:04 <roshi> ah
16:14:18 <adamw> and that violates alpha criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:14:24 <adamw> sorry for not joining the dots, it was late :)
16:16:05 <roshi> proposed #agreed - RHBZ#1467164 - AcceptedBlocker - This bug is a clear violation of the following criterion: "elease-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:16:11 <roshi> no worries
16:16:14 <mattdm> +1
16:16:17 <mboddu> +1
16:16:37 <tenk> +1
16:16:54 <roshi> #agreed - RHBZ#1467164 - AcceptedBlocker - This bug is a clear violation of the following criterion: "elease-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:17:07 <mattdm> oh except elease blocking :)
16:17:07 <roshi> #topic (1467278) gdm prevents user logging in under vesa
16:17:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467278
16:17:08 <roshi> #info Proposed Blocker, gdm, NEW
16:17:10 <mattdm> rrrrr
16:17:20 <roshi> bah
16:17:22 <roshi> #undo
16:17:22 <zodbot> Removing item from minutes: INFO by roshi at 16:17:08 : Proposed Blocker, gdm, NEW
16:17:29 <roshi> #undo
16:17:29 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3b36a790>
16:17:31 <roshi> #undo
16:17:31 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x3b36aa50>
16:17:34 <roshi> #undo
16:17:34 <zodbot> Removing item from minutes: AGREED by roshi at 16:16:54 : - RHBZ#1467164 - AcceptedBlocker - This bug is a clear violation of the following criterion: "elease-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:17:54 <roshi> #agreed - RHBZ#1467164 - AcceptedBlocker - This bug is a clear violation of the following criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:17:59 <roshi> #topic (1467278) gdm prevents user logging in under vesa
16:18:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467278
16:18:04 <roshi> #info Proposed Blocker, gdm, NEW
16:18:07 <roshi> there
16:18:22 <mattdm> :)
16:19:01 <mattdm> As mentioned in ticket, I'm -1 to this, as we have high confidence that the systems affected will work in *regular* graphics mode
16:19:43 <nirik> so it's only some subset of intel ?
16:20:54 <mattdm> nirik: and only when configured with the VESA driver
16:21:36 <nirik> yeah, -1 blocker then
16:21:39 <roshi> I feel like basic graphics should be the baseline of "works," but not strongly enough to fight it
16:21:42 <roshi> -1
16:22:00 <adamw> there seem to be several different issues reported in the bug now (bad kparal), but the initial one doesn't feel blocker-y to me
16:22:08 <tenk> just done a fresh install and have also to click on user live system user
16:22:08 <adamw> that 'fails to boot at all in BIOS mode on T450' one seems a bit worrying
16:22:14 <tenk> -1 for me
16:22:15 <adamw> tenk: that part is known
16:22:25 <adamw> i used to know what the reason was, but i've forgotten...
16:22:31 <mattdm> roshi: yeah if it really worked that way where it was actually a more basic version of a more compicated thing. But it's actually a separate driver entirely and different path
16:22:51 <roshi> proposed #agreed - RHBZ#1467278 - RejectedBlocker - Rejecting as a blocker under the same reasoning from Comment #9.
16:22:57 <adamw> i think it's because the 'try loading with wayland and if it fails fall back to x11' thing doesn't quite interoperate right with 'autologin'
16:23:06 <adamw> ack, at least pending info on the T450 thing
16:23:10 <adamw> i might send out a call for testing on that, though
16:23:19 <roshi> sounds good
16:24:32 <nirik> ack
16:24:39 <roshi> #agreed - RHBZ#1467278 - RejectedBlocker - Rejecting as a blocker under the same reasoning from Comment #9.
16:24:51 <nirik> adamw: thats t450 with bios not efi right?
16:24:58 <adamw> yeah
16:25:17 <roshi> #topic (1467316) kwin and kactivitymanager crash on the first boot of KDE
16:25:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467316
16:25:23 <roshi> #info Proposed Blocker, kwin, NEW
16:25:37 <adamw> as stated in the bug, if this doesn't cause any noticeable problems and there's no user-visible notification, -1
16:26:14 <mattdm> yeah, this is not pretty, but the release criteria specifies "can't be horribly ugly", not "not pretty"
16:26:40 <mattdm> I can confirm that there's no pop-up or notification
16:28:38 <roshi> -1
16:28:51 <mattdm> so also -1 from me if that wasn't clear
16:28:53 <nirik> the bug mentions abrt notice.
16:29:01 <nirik> but you have to go looking for that one?
16:29:04 <mattdm> nirik: there is no pop-up abrt notice
16:29:30 <nirik> ok
16:29:35 <nirik> then -1 as well.
16:29:38 <roshi> proposed #agreed - RHBZ#1467316 - RejectedBlocker - This bug doesn't clearly violate any criteria, and it doesn't cause any noticeable problems or user-visible notifications of the failure, so is not considered a blocker.
16:29:38 <tenk> so -1
16:29:58 <mattdm> roshi: +1 to that
16:30:08 <adamw> ack
16:30:11 <mboddu> ack
16:30:12 <mattdm> i presume tenk's -1 is to the blocker not the other way around
16:30:13 <roshi> yay for run-on sentences :)
16:30:18 <roshi> same here
16:30:20 <mattdm> oh we say ack for this part :)
16:30:24 <mattdm> excellent
16:30:25 <mattdm> ack
16:30:26 <tenk> ack
16:30:28 <roshi> #agreed - RHBZ#1467316 - RejectedBlocker - This bug doesn't clearly violate any criteria, and it doesn't cause any noticeable problems or user-visible notifications of the failure, so is not considered a blocker.
16:30:47 <roshi> +/- for blocker status, and ack/nack/patch for proposed #agreed
16:30:49 <roshi> :D
16:31:31 <roshi> last proposal
16:31:32 <roshi> #topic (1467368) totem doesn't work in VMs under Wayland
16:31:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467368
16:31:32 <roshi> #info Proposed Blocker, totem, NEW
16:31:56 <mattdm> So, I can easily duplicate this, but note under Wayland and falling back to X11 (manually) is a work-around
16:32:09 <mattdm> It seems *likely* that there's a real bug in totem
16:32:13 <adamw> still...it *does* seem a bit bad
16:32:18 * mattdm wonders if this even works under F25
16:32:20 <adamw> and i'm worried if it may happen on some real hardware...
16:32:29 <adamw> yeah, i wondered that too, also if it happened on alpha or beta
16:32:34 <mattdm> but, yeah, it seems bad and does also seem to clearly violate the stated criteria
16:32:34 <roshi> is it a common use case to watch videos in a VM?
16:32:48 * roshi tests video playback on this workstation bare metal install I just did
16:32:51 <roshi> jas
16:33:24 <mattdm> roshi: I dunno how common, but I think the expectation would be that this is nothing particularly strange to want to do
16:34:11 <mattdm> video plays nicely in *Firefox* :)
16:34:46 <mboddu> mattdm: yep, I never used any video player :)
16:35:40 <mattdm> but if you download an ogg file and browse to it in nautilus and click on it, you'll get this.
16:36:02 <mattdm> What's our wiggle room here?
16:36:09 <mboddu> adamw: do we have any criteria set on this? or can we take it as an FE?
16:36:53 <adamw> well, this would be about the default app functionality criterion i think
16:36:54 <nirik> I guess the copout is: not many people play videos in vm's
16:37:08 <roshi> yeah, it'd be default func I think
16:37:13 * roshi has to install codecs
16:37:25 <adamw> well, i doubt it would happen on *all* bare metal
16:37:26 <mattdm> copout #2: there is another application installed by default that can also play those same videos
16:37:32 <roshi> oddly, when I played the ,mpg, audio started, after I clicked to install drivers via software
16:37:36 <mattdm> copout #3: you can fall back to X11
16:37:43 <adamw> but perhaps the case is 'it fails when using llvmpipe' or something like that
16:37:47 <mattdm> roshi: Yes, I get the same behavior
16:38:38 <roshi> works after installing codecs though
16:38:51 <adamw> audio and video playback are kinda separated in totem
16:38:55 <adamw> if it can play one but not the other, it will
16:39:13 <roshi> so I don't see this on bare metal with codecs installed
16:39:24 <roshi> so -1, if it's just inside a VM
16:39:30 <roshi> which it seems to be
16:39:41 <adamw> i don't think it's that straightforward.
16:39:54 <roshi> you wouldn't
16:40:01 <adamw> like i said, it clearly affects only some configurations
16:40:03 <roshi> don't shatter my fragile understanding of reality!
16:40:10 <adamw> but that doesn't mean the configurations it only affects are 'VMs'
16:40:18 <adamw> it might be 'all cases where we're using llvmpipe'
16:40:20 <adamw> or something like that
16:40:44 <adamw> has anyone tried it on bare metal in basic graphics mode?
16:40:54 <roshi> lemme try
16:42:59 * adamw downloading ISOs
16:43:19 <roshi> boot with nomodeset and it works fine
16:43:34 <adamw> hmm, kay
16:43:47 <adamw> i'm kinda reluctant to make a quick decision on this one, it'd be really nice to have more info
16:44:03 <roshi> can punt and look at it again at Go/No-go
16:44:07 <adamw> personally i might want to punt on this till go/no-go...yeah
16:44:12 <adamw> or, you know, sooner
16:44:13 <roshi> or set another meeting for Wednesday
16:44:23 <adamw> if it's just one bug we can evaluate it async (in the bug report)
16:44:29 <roshi> yeah
16:44:32 <roshi> +1 punt
16:44:42 <mattdm> adamw: we can punt and still get going on the next RC?
16:45:04 <mattdm> I'll check with bastian (who I think is both upstream *and* fedora maintainer)
16:45:24 <mattdm> and ping other gnome folks. maybe it turns out to be something easy and we can have a quick fix
16:45:28 <roshi> proposed #agreed - RHBZ#1467368 - Punt - It's unclear what all configurations are affected by this bug, and we'd like some more information before we determine status.
16:45:33 <adamw> mattdm: yeah, only *accepted* blockers prevent creation of another RC.
16:45:38 <mattdm> in that case, ack
16:45:39 * nirik wonders if GDK_BACKEND=x11 totem also works around it
16:45:44 <tenk> ack
16:45:45 <nirik> ack
16:45:52 * adamw also wants to try different VM configs...
16:45:58 <adamw> ack
16:46:04 <roshi> #agreed - RHBZ#1467368 - Punt - It's unclear what all configurations are affected by this bug, and we'd like some more information before we determine status.
16:46:23 <mattdm> nirik: that *does* work around it
16:46:34 <roshi> that's it for proposed blockers
16:46:37 <nirik> ok.
16:46:50 <roshi> adamw: which accepted blockers do you want to take a look at?
16:47:09 <mattdm> not sure that helps though since I'm not sure how to deal with the "clicked on a video in nautilus" case
16:47:15 <roshi> everything is VERIFIED or ON_QA, and the installs I've done look good
16:47:18 <roshi> work fine
16:47:50 <adamw> hum, 1436873 could do with more verification, and there's some discussion going on in 1466914
16:48:09 <adamw> wait, no, not 1466914. i'm thinking of antoher bug. forget that one
16:48:24 <roshi> want to take over? you have chair
16:48:53 <adamw> nah, just go ahead with 1436873
16:48:59 <roshi> huh, laptop didn't suspend when lid closed in basic graphics mode...
16:49:12 <roshi> #topic (1436873) KDE live environment notifies of available updates
16:49:15 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1436873
16:49:18 <roshi> #info Accepted Blocker, spin-kickstarts, ON_QA
16:49:20 <mattdm> I have high confidence that this worked.
16:49:35 <mattdm> I wouldn't mind another human being trying it, though
16:49:48 <adamw> did you do something to make an update available?
16:49:57 <mattdm> adamw: yes -- I enabled updates-testing
16:50:09 <mattdm> then i hit "check again now"
16:50:14 <adamw> also i have the openqa tests jump through a lot of hoops to make an update available *before* the desktop ever starts, though that's more about GNOME's annoying behaviour than KDE's
16:50:19 <mattdm> I wasn't patient enough to wait a day for it to look again
16:50:27 <adamw> the openqa test did pass on both prod and stg
16:50:32 <adamw> i might run it a few times
16:50:45 <adamw> the test that checks whether a notification appears for updates after install failed, though :/
16:50:52 <adamw> i'd better look into that too
16:50:56 <mattdm> it's definitely the case that the applet is not even installed on live
16:51:02 <mattdm> and that it is installed on install
16:51:14 <adamw> if you could check that post-install as well it'd be good...
16:51:40 <adamw> but yeah, it'd just be nice to double-check everything here.
16:52:09 <mattdm> yeah. because I've now done about 20 installs of kde, which is 19 more installs of kde than I had previously done in the past two years
16:52:15 <adamw> heh
16:52:23 <mattdm> and there's a chance that human error snuck in somewhere there
16:53:00 <adamw> alright, that's all i really had
16:53:28 <roshi> kk
16:53:35 <roshi> everything else looking good?
16:53:40 <roshi> #topic Open Floor
16:53:46 <mattdm> So, totem issue outstanding, but otherwise we're looking pretty good... knock on all available superstitions
16:54:01 * roshi has a wood desk for *just* that reason
16:54:07 <mattdm> let's tell kparal no more looking for problems :)
16:54:08 <adamw> well, i have a couple things
16:54:15 <mboddu> roshi: so what about proposed FE's?
16:54:18 <adamw> one, mboddu, do you actually know what went wrong with the custodia problem yet?
16:54:23 <adamw> oh yeah, we have those too
16:54:25 <roshi> oh, right
16:54:38 <roshi> onto the proposed FEs!
16:54:38 <roshi> #topic (1466356) Serial console output is garbled in U-Boot on Raspberry Pi
16:54:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1466356
16:54:45 <roshi> #info Proposed Freeze Exceptions, bcm283x-firmware, MODIFIED
16:54:53 <roshi> lol, I even told mboddu we'd look at it
16:54:59 <roshi> .fire roshi for being a bad person
16:54:59 <zodbot> adamw fires roshi for being a bad person
16:55:12 <mboddu> adamw: [04:10:08] <tyll_> adamw: mboddu: Sorry about custodia, I wrongly blocked it when cleaning up broken deps :-/ I skipped python-etcd for freeipa but missed that custodia was still on the list as an intermediate dependency
16:55:20 <mboddu> from releng channel
16:55:33 <adamw> aha
16:55:37 <mboddu> oops, wrong topic, but just want to answer adamw question
16:55:41 <adamw> thanks
16:55:57 <roshi> +1 to this as FE
16:56:51 <nirik> +1 fe here as well.
16:57:00 <mattdm> +1 to FE. moves back to an older version avoiding a regression, so should be relatively safe
16:57:15 <roshi> proposed #agreed - RHBZ#1466356 - AcceptedFreezeException - It would be good to get a fix for this as RPi is a widely used platform.
16:57:25 <adamw> +1
16:57:26 <tenk> ack
16:57:26 <nirik> ack
16:57:30 <adamw> ack
16:57:32 <roshi> #agreed - RHBZ#1466356 - AcceptedFreezeException - It would be good to get a fix for this as RPi is a widely used platform.
16:57:39 <roshi> #topic (1467355) Docker images are missing from f26 final RC composes
16:57:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467355
16:57:45 <roshi> #info Proposed Freeze Exceptions, distribution, NEW
16:58:03 <adamw> also +1, this is obviously quite bad
16:58:12 <adamw> mboddu: how risky are the pungi config changes, though?
16:58:29 <tenk> +1 FE
16:58:32 <roshi> yeah, +1
16:58:45 <roshi> though, we can build those pretty much any time, aiui
16:59:00 <roshi> as they get rebuilt with updates periodically
16:59:21 <adamw> true, i guess
16:59:25 <mboddu> adamw: its not big, the change is only releated to docker images part of pungi configs, 1 min
16:59:26 <adamw> we do a Docker daily compose
16:59:32 <adamw> okay, then +1.
16:59:34 <mattdm> I'd like to have them on release day; don't care if part of compose or not
16:59:39 <roshi> proposed #agreed - RHBZ#1467355 - AcceptedFreezeException - It would be good to get a fix in for this if the change is non-invasive.
16:59:44 <mattdm> ack
16:59:54 <nirik> sure, +1 ack
17:00:21 <roshi> #agreed - RHBZ#1467355 - AcceptedFreezeException - It would be good to get a fix in for this if the change is non-invasive.
17:00:23 <mboddu> adamw: https://pagure.io/fork/mohanboddu/pungi-fedora/diff/f26..f26-RC-1.4 will be the change, about to create the PR
17:00:24 <roshi> #topic (1467383) Missing workstation ostree installer in F26 RC's
17:00:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467383
17:00:29 <roshi> #info Proposed Freeze Exceptions, distribution, NEW
17:00:56 <adamw> did this image *ever* get built for 26 yet?
17:01:04 <roshi> dont think so
17:01:07 <adamw> i don't think it ever has
17:01:14 <roshi> based on the description
17:01:15 <mboddu> adamw: nope
17:01:27 <mboddu> adamw: last time we had it was in f25 beta
17:01:35 <adamw> but I can be +1
17:01:40 <adamw> mboddu: well, we have it in rawhide too
17:01:47 <adamw> the change looks safe and restricted
17:01:59 <mboddu> adamw: I mean for releases
17:02:13 <nirik> +1 FE
17:02:14 <adamw> although, the commit message claims it changes the repo, but the code looks like it doesn't
17:02:17 <adamw> only the rootfs size
17:02:40 <roshi> proposed #agreed - RHBZ#1467383 - AcceptedFreezeException - It'd be good to get this in if possible, to showcase the potential of an Atomic Workstation.
17:02:45 <adamw> ah, dustymabe changed that bit but didn't change the commit message
17:02:47 <adamw> +1
17:02:50 <adamw> ack
17:02:54 <tenk> ack
17:03:04 <roshi> #agreed - RHBZ#1467383 - AcceptedFreezeException - It'd be good to get this in if possible, to showcase the potential of an Atomic Workstation.
17:03:14 <roshi> #topic (1467108) Blank transition from an animated png wallpapers
17:03:14 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1467108
17:03:14 <roshi> #info Proposed Freeze Exceptions, f26-backgrounds, MODIFIED
17:03:32 <mboddu> adamw: yeah, it got rebased since we asked them not to change the repo
17:03:42 <mattdm> I don't like this. As Kevin noted, it might break other spins
17:03:49 <mattdm> plus the jpeg is ugly :(
17:04:17 <adamw> yeah, i think i'm -1 on this. the default wallpaper isn't affected
17:04:29 <roshi> TIL we do animated backgrounds
17:04:33 <adamw> it should just go through the regular update process
17:04:34 <roshi> or can do, rather
17:04:39 <roshi> -1
17:04:40 <adamw> so we can properly figure out if it breaks stuff
17:04:41 <mattdm> roshi: it's nifty they change throughout the day
17:04:41 <nirik> yeah.
17:04:47 <tenk> -1
17:05:48 <roshi> proposed #agreed -  RHBZ#1467108 - RejectedFreezeException - Because of the risk to other DEs, we're not going to include this during freeze (especially because this is easily fixed via an update and doesn't impact the default background).
17:06:10 <mattdm> ack
17:06:11 <tenk> ack
17:06:20 <mattdm> although I think the intention is actually to change the default background to an animated one
17:06:23 <mattdm> which would be cool
17:06:46 <adamw> ack
17:06:48 <roshi> #agreed -  RHBZ#1467108 - RejectedFreezeException - Because of the risk to other DEs, we're not going to include this during freeze (especially because this is easily fixed via an update and doesn't impact the default background).
17:06:53 <roshi> #topic Open Floor
17:07:01 <roshi> anyone have anything else?
17:07:11 <adamw> yeah, one other bug to mention
17:07:22 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1464843
17:07:30 <adamw> there's still some argy-bargy going on in the comments there
17:07:45 <adamw> i still personally am fine with shipping as-is and documenting the issue for folks who want to create live images, but thought i'd mention it
17:08:19 <mattdm> I'm also fine with that
17:08:43 <roshi> I'm of the same opinion I was for my comment in the bug
17:09:18 * satellit has anyone tested kd on rpi3 ?  i cannot get past login screen
17:09:22 <satellit> kde
17:09:31 * nirik reads.
17:10:26 <nirik> yeah, document and ship... if dnf updates that could even get fixed in an update.
17:10:29 <mboddu> adamw: also here is the list of blocked pkgs https://pagure.io/releng/issue/6836, do you think we should unblock any of them?
17:11:29 <mattdm> I have no idea what all of those golang libs might actually be used for
17:12:00 <mattdm> source-to-image is a tool from openshift... that makes me a little sad but if it's broken it's broken
17:12:22 * roshi just tested an update for that a week or so ago...
17:12:29 <roshi> source-to-image, I mean
17:13:01 <mattdm> what does it mean for a package to be blocked here? can it go into updates once fixed, or does it get dropped entirely?
17:13:11 * roshi has no idea
17:14:00 <nirik> it means koji doesn't use it at all for anything
17:14:06 <nirik> not in buildroots, not in composes, etc.
17:14:32 <nirik> packages can come back, but will need unblocking to build / appear again
17:14:35 <mattdm> I'm pretty sure this is a leaf package, so that's probably ok?
17:14:44 <nirik> yeah.
17:14:57 <adamw> mboddu: as i just commented in that issue i am extremely annoyed that this process happened during freeze *at all*
17:14:59 <mattdm> I assume bugs are filed for each thing that gets dropped?
17:15:00 <adamw> it absolutely should not
17:15:17 <adamw> i can't say off the top of my head whether any specific package on that list is going to cause problems, which is kind of the point
17:15:21 <nirik> it's supposed to be before I thought...
17:15:24 <mattdm> adamw: yeah :(
17:15:27 <adamw> we *don't* make unplanned and unassessed changes during freezes, we just don't
17:15:45 <adamw> nirik: per that ticket, till "blocked the remaining offenders" "2 days ago"
17:15:46 <adamw> :/
17:15:57 <roshi> yeah...
17:15:57 <nirik> I know... I said "supposed"
17:16:00 <mboddu> nirik: I think you guys decided it during last weeks releng meeting, which I didn't attend
17:16:13 <mattdm> what is the consequence of unblocking all of this stuff now?
17:16:15 <adamw> okay, 'unplanned' is inaccurate; i should say changes that have not gone through the FE/blocker process
17:16:29 <adamw> mattdm: who tf knows?
17:16:31 <nirik> mattdm: broken deps in the base repo
17:16:34 <mboddu> nirik: I came to know while doing the RC compose and started unblocking them as necessary
17:16:38 <nirik> at least
17:16:51 * nirik runs a repoclosure
17:16:53 <mattdm> shouldn't we do this *right after branching*?
17:17:29 * roshi would think
17:17:35 <adamw> overall, i'd say we should reverse what till did.
17:17:50 <nirik> I can get you a repoclosure if you want to wait for it...
17:18:00 <adamw> just looking at that list, i think qgis is an important thing
17:18:04 <nirik> there's a process for these... and yes, it's usually eariler
17:18:05 <adamw> asterisk stuff is on that list
17:18:23 <nirik> yes, it's broken in f26
17:18:53 <adamw> is it really broken on arches we care about?
17:19:01 <adamw> or is it another 'oh there's some issue on ppc64le' case?
17:19:27 <mattdm> there are packages which are super-broken which *aren't* ont his list. *cough* festival *cough*
17:19:28 <nirik> it's 100% broken from what I understand. Some package it depends on doesn't work at all? but I could be mistaken
17:19:37 <adamw> the combination of 'we're now blocking packages for dep issues on 3x more arches than we ever did before' and 'let's block packages in the middle of the final freeze' is pretty toxic
17:19:38 <nirik> this list is about broken deps.
17:19:48 <adamw> yes, but some of the dep issues are arch specific
17:20:22 <adamw> like i wrote about in the case of a package i maintain; os-autoinst was going to get dropped (which would have been a complete mess) because one of its dependencies wasn't built on ppc64 or some such nonsense
17:20:32 <nirik> ok
17:21:08 <adamw> and sometimes it's a case like 'the package has 50 subpackages and there's a dep issue in some rather unimportant one'
17:21:41 <adamw> also, i see at least two packages on the 'blocked' list that we have approved FEs for fixing
17:21:50 <adamw> like java-gnome (on the initial list) and python-etcd (on the second list)
17:23:26 <nirik> here's what I see for a current repoclosure on x86_64: https://paste.fedoraproject.org/paste/mu4cbVzNvH6UqBjTGpNIaA/
17:23:39 <adamw> here's another example:
17:24:06 <adamw> the first list of 'blocked' package - that is, the one in https://pagure.io/releng/issue/6836#comment-446781 - includes rpm-ostree-toolbox
17:24:16 <adamw> which i guess is rather important to ostree folks?
17:24:27 <adamw> the 'dependency issue' for that package is 'it depends on docker which isn't built on ppc64'
17:24:40 <roshi> tbh, I couldn't tell you - as I'm just an ostree consumer
17:24:41 <adamw> so it would work perfectly well on our release blocking arches and several others
17:24:47 * roshi keeps meaning to dig more into it
17:24:53 <kparal> ehm, I forgot about the meeting
17:24:56 <kparal> hello everyone
17:24:58 <adamw> hi kparal
17:25:01 <roshi> welcome :)
17:25:06 <adamw> i'm currently telling everyone how awful they are :P
17:25:12 <roshi> now go away, things are looking good :p
17:25:20 * roshi kids, please don't go away
17:25:25 <roshi> :D
17:25:31 * kparal was about to log out
17:25:41 * roshi loves how he and adamw present a united front
17:25:48 <adamw> hehe
17:26:04 <roshi> we're a well oiled *something*
17:26:08 <roshi> :p
17:26:39 <adamw> given the amount of problematic cases we appear to have, i'd suggest there's a solid case for just reverting all the blocking here
17:26:52 <nirik> anyhow, how about pushing those FE's for deps, making sure those things are unblocked and revamping this mess for f27?
17:27:06 <adamw> i'd rather have several packages in the final repo with dep issues than potentially important packages missing from the release
17:27:20 <adamw> but *at least* the cases we have FEs for should be unblocked
17:27:33 <nirik> so wait, when where those blocked? yesterday?
17:27:37 <roshi> yeah
17:27:38 <adamw> nirik: some three days ago, some two
17:27:47 <roshi> +1 based on adamw's logic
17:27:52 <adamw> https://pagure.io/releng/issue/6836#comment-446781 and https://pagure.io/releng/issue/6836#comment-447049
17:28:00 <roshi> I'd rather have the broken deps in the repos at this point
17:28:53 <nirik> then my repoclosure might not be accurate if they were blocked after the last nightly
17:30:03 <mboddu> nirik: nothing is blocked after the last nightly.
17:30:55 <nirik> ok
17:31:02 * nirik checks the rc1.3 repo
17:31:05 <adamw> nirik: your list seems to include all the packages that were 'blocked'
17:31:29 <adamw> compare your report to the lists from the ticket, just the first two packages (OmegaT and RackTables) are the first two packages in till's first list, for e.g.
17:31:48 <nirik> right.
17:31:56 <nirik> so thats what makes me think this is old
17:32:05 <nirik> yes, the rc 1.3 list is much smaller
17:32:23 <adamw> presumably only things mboddu unblocked
17:32:30 <nirik> https://paste.fedoraproject.org/paste/bLlxk4TcMC4R1wFBP1LRJQ
17:33:21 <adamw> right, so most of that is the issue we're aware of (mboddu unblocked python-etcd but didn't unblock custodia, which was blocked as a dep of it)
17:34:13 <mboddu> adamw: and custodia is unblocked now
17:34:13 <nirik> I thought tyll deliberately didn't block python-etcd but missed that custodia was needed for freeipa and blocked it.
17:34:21 <adamw> well, whichever
17:34:38 <adamw> so the real point is, a bunch of stuff that was in RC-1.1 and very recent nightlies was blocked from RC-1.3
17:34:53 <adamw> and we've caught *one* release blocking problem that caused, but we sure don't know if there might be any others
17:34:59 <adamw> or not release blocking but not desirable
17:35:14 <roshi> yeah
17:35:26 <adamw> i'm suggesting we should say nope, it was too late to do that, shouldn't have happened, and unblock the lot of 'em
17:35:37 <tenk> +1000
17:35:38 <nirik> ok.
17:35:42 <roshi> works for me, and sets a good precedent overall
17:35:45 <adamw> but of course, that's only my opinion :)
17:35:53 <roshi> because this should have happened at branch or not at all
17:35:57 <tenk> don t understand the start of this process so late in the F26 planning
17:35:59 * nirik would personally go for just fixing the ones now that we have FE's for...
17:36:01 <roshi> for sure not during freeze
17:37:12 * mboddu knows that we didn't do it for f25, so this happened now for f26 cycle
17:37:22 <mboddu> Does anyone know when this really should happen?
17:38:24 <nirik> I was looking...
17:38:46 <nirik> https://docs.pagure.org/releng/sop_retire_orphaned_packages.html doesn't mention any actual dates/times.
17:38:46 * mboddu not able to decide, unblocking everything or unblocking only the FE's
17:41:09 <roshi> votes to unblock all?
17:41:16 <roshi> votes to unblock just the FEs?
17:42:46 <nirik> I'm ok with either. I would prefer just FEs, but I understand adamw's point that we don't fully know what could be messed up.
17:43:14 <adamw> well, i'd argue for at least also unblocking cases like rpm-ostree-toolbox
17:43:33 <adamw> but if we're going to go through the list identifying cases like that, why not just unblock the lot
17:43:57 <nirik> thats not blocked?
17:44:06 <adamw> it was on till's initial list...
17:44:17 <nirik> huh, well, it's not blocked. ;)
17:44:32 <adamw> ah, mboddu unblocked it
17:45:04 <adamw> ah, mboddu unblocked several of the ones we had FEs for in the RC-1.1 compose request, i see
17:45:05 <nirik> it also has a FE
17:45:36 <mboddu> adamw: yes, I started unblocking them if we have FE's for them
17:45:42 <adamw> right, thanks
17:45:50 <adamw> so, i guess let's just vote and go with the majority.
17:46:06 <adamw> i still vote for unblocking everything that was blocked post final freeze.
17:46:32 <mboddu> adamw: thats everything from that ticket
17:46:38 <adamw> yep.
17:47:20 <roshi> so, votes to unblock everything?
17:47:29 <roshi> +1
17:47:37 <tenk> +1
17:47:42 <adamw> +1
17:48:02 <mattdm> +1 in the name of keeping freezes sacred, if nothing else :)
17:48:24 <mboddu> adamw: but what if one of the broken dep causes an issue with the RC-1.4 compose?
17:48:35 <roshi> +4 for that
17:48:43 <roshi> votes for only FEs?
17:48:44 <adamw> mboddu: they didn't cause any issues with the RC-1.1 compose, did they?
17:49:04 <nirik> +1 but fine if I am outvoted. ;) lets not spend all day on this.
17:49:04 <mboddu> adamw: I only unblocked that are in the FE's
17:49:10 <adamw> mboddu: i mean RC-1.1
17:49:15 <adamw> which happened *before* the blocking
17:49:42 <mboddu> adamw: we didn't had a RC compose before blocking
17:49:49 <adamw> i thought RC-1.1 was pre-blocking
17:49:54 <adamw> because the freeipa test passed on it, i think...
17:50:03 * adamw checks
17:50:06 <mboddu> adamw: nope
17:50:14 * mattdm mumbles about length of compose being a critical issue that causes terrible trouble all of the time
17:50:29 <adamw> mboddu: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=26&build=Fedora-26-20170630.0&groupid=1
17:50:44 <adamw> note that server_role_deploy_domain_controller passed
17:50:50 <adamw> it couldn't have done that if custodia was blocked
17:51:19 <adamw> though i suppose RC-1.1 could have been between the *first* block and the *second* block
17:51:23 <mboddu> adamw: custodia is blocked after RC-1.1
17:51:32 <mboddu> adamw: yes, thats right
17:51:47 <adamw> still
17:52:04 <adamw> is it really better if a package which is supposed to be on a medium is missing because it was blocked for dep issues?
17:52:21 <adamw> sigh, all of these bad choices is *why we don't do this stuff during freezes* :)
17:52:33 <mboddu> adamw: so, if we unblock everything and one of the broken dep fails the compose then we have to do another one. thats why I am confused to vote on anything
17:52:40 <adamw> yeah, it is a valid point
17:52:55 <adamw> can we compare the most recent nightly compose before the blocking?
17:53:00 <adamw> would that be 0628.n.0 ?
17:53:33 <adamw> there's a 27.n.0 and a 28.n.1...
17:53:54 <mboddu> adamw: yep, we can use 28 and 27
17:54:54 <mboddu> adamw: I think better use 27, not sure when 28.n.1 was started
17:55:39 <adamw> the funny thing is, even 20170701.n.0 seems to have at least RackTables in it
17:55:47 <adamw> and Ray, and asterisk, and ayttm...
17:55:52 <adamw> all the things that were supposedly 'blocked'
17:56:18 <mboddu> adamw: oh shoot, I forgot to mention, they are only blocked in f26-composse tag
17:56:23 <adamw> ah, fun.
17:56:27 <mboddu> adamw: not from f26
17:56:29 <adamw> that's even more silly
17:56:54 <adamw> well, at least it means we can compare a nightly and RC-1.3
17:57:33 <nirik> huh, thats weird. ok...
17:58:14 <adamw> sigh, just give me a second to hack up a quick fedfind script
17:59:09 <roshi> kk
18:03:07 <adamw> hmm, if i got that right, images that are in RC-1.3 but not in the most recent nightly are lxqt ARM disk image, workstation ARM disk image, and cinnamon live x86_64
18:04:54 <adamw> the workstation ARM disk image issue was some kind of server problem, i think: https://kojipkgs.fedoraproject.org//work/tasks/394/20280394/root.log
18:05:03 <adamw> https://koji.fedoraproject.org/koji/taskinfo?taskID=20280394 is the task
18:05:32 <adamw> "[MIRROR] rygel-0.34.0-1.fc26.armv7hl.rpm: Status code: 408 for http://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170701.n.0/compose/Workstation/armhfp/os/Packages/r/rygel-0.34.0-1.fc26.armv7hl.rpm"
18:05:39 <nirik> I really thought I quashed that download thing... oh, but perhaps it was after that
18:06:08 <adamw> lxqt similarly doesn't seem to be anything to do with bad deps: https://kojipkgs.fedoraproject.org//work/tasks/539/20280539/appliance.log
18:06:13 <adamw> https://koji.fedoraproject.org/koji/taskinfo?taskID=20280539
18:06:20 <nirik> yes, my fix landed on the 28th
18:07:13 <adamw> cinnamon also seems to have been a download failure:
18:07:14 <adamw> https://kojipkgs.fedoraproject.org//work/tasks/456/20280456/root.log
18:07:25 <adamw> "DEBUG util.py:439:  2017-07-01 13:42:07,696: Non interactive installation failed: Failed to download the following packages: Cannot download Packages/p/python3-javapackages-4.7.0-15.fc26.noarch.rpm: All mirrors were tried."
18:07:48 <adamw> so long story short, i don't see any image that fails to build in a nightly compose because of the packages that are present for nightly composes but not for candidate composes
18:08:01 <adamw> thus i'm still +1 to unblock everything
18:10:24 <adamw> woot, i finally managed to bore everyone to death! took longer than usual.
18:10:25 <nirik> ok
18:11:09 <mboddu> so?
18:12:27 <mattdm> adamw: sorry :)
18:12:44 <adamw> welp, so far the vote stands at +4 to unblock everything, +1 to only unblock things we have an FE for
18:12:49 <roshi> works for me
18:12:53 <roshi> yeah
18:12:54 <adamw> mboddu, you haven't voted yet
18:13:04 <roshi> adamw: you want to do the proposed #agreed
18:13:08 <adamw> sure
18:13:13 <mattdm> so, if we fire off a compose now, it'll be done sometime after midnight
18:13:21 <mattdm> which is awkward for deciding what to do if it goes wrong
18:13:30 <mattdm> but better than not having it :)
18:13:31 <adamw> mattdm: whose midnight? :P
18:13:44 <mattdm> adamw: I think maybe both mine *and* yours
18:13:51 <mattdm> but yes, sorry. I was actually thinking mboddu's
18:14:01 <mattdm> which happens to be mine as well but coincidentally
18:14:20 <mboddu> mattdm: yeah, both of us live in EST
18:14:36 <mboddu> adamw: and I am still not able to decide :(
18:14:49 <adamw> proposed #agreed The blocking of packages with dependency problems - https://pagure.io/releng/issue/6836 - was done far too late (well into Final freeze) and has already caused the RC-1.3 compose to be a failure. We agreed that all the packages blocked as part of that ticket should be unblocked again, and this kind of blocking should never be done without going through the FE/blocker process in future.
18:14:55 <roshi> ack
18:15:01 <adamw> mboddu: welp, if it's only you you're not going to change the result anyhow
18:15:05 <adamw> so you can abstain, if you want :)
18:15:06 <mboddu> adamw: but I am inclined towards unblocking just the FE's
18:15:25 <tenk> ack
18:16:30 <mattdm> mboddu: If it happens that one of the to-be-now-unblocked packages causes failure, can you immediately just block that package and restart?
18:17:30 <mboddu> mattdm: I can but depends on when it fails, if it fails late in the night then I wont notice it
18:17:55 * nirik can keep an eye out also
18:18:04 * adamw also
18:18:53 <mboddu> mattdm: and I dont think it will take that long, so I might be here to do another one
18:19:57 <adamw> waiting on another ack (or nack or patch)
18:20:07 <mattdm> ack
18:20:09 <mattdm> sorry :)
18:20:15 <adamw> #agreed The blocking of packages with dependency problems - https://pagure.io/releng/issue/6836 - was done far too late (well into Final freeze) and has already caused the RC-1.3 compose to be a failure. We agreed that all the packages blocked as part of that ticket should be unblocked again, and this kind of blocking should never be done without going through the FE/blocker process in future.
18:20:24 <adamw> that's all i had, sorry for the time
18:20:48 <mboddu> nirik: they outnumbered us ;)
18:20:48 <mattdm> mboddu: will you be available tomorrow to start a new one if need be?
18:21:23 <adamw> mboddu: nirik: as is traditional, if this turns out to be the wrong call you both get *full* "I told you so" privileges ;)
18:21:28 <mboddu> mattdm: I have to head back home, so I might not be available in the afternoon for 5 ish hours
18:21:39 <mattdm> Because otherwise unless things are perfect it's a very late wednesday night in order to ship on thursday
18:21:42 <adamw> mboddu: i will get a new compose request in ASAP
18:21:48 <mboddu> adamw: sure
18:22:00 <mattdm> mboddu: yeah understandable. it is a holiday after all :(
18:22:51 * nirik should be around tomorrow... although I will be prepping for house move, so may not see irc right away
18:22:52 <mboddu> mattdm: I can stay but that means I have to start either late night or early morning on Wed, so lets see what happens
18:23:19 <mattdm> mboddu: yeah. hoping that it isn't necessary
18:23:22 <adamw> btw, i need a #endmeeting to get started on the secretarialization :P
18:23:26 * adamw works from the meeting summary
18:23:38 <mattdm> work backward file compose request first :)
18:23:55 <adamw> mattdm: i need to do the secretarialization to double check the compose request
18:24:32 <mattdm> fine :)
18:24:38 <adamw> the compose request script works off the blocker app
18:24:49 <adamw> well, rather, they're all the same thing
18:25:11 * adamw hangs around the endmeeting fuse with a match and a clean conscience
18:25:19 <roshi> sounds good to me
18:25:21 <mboddu> nirik: once thats filed, I can create the PR for 1.4, can you merge it?
18:25:23 <roshi> thanks for coming folks
18:25:28 <adamw> thanks for running roshi
18:25:35 <nirik> yep
18:25:41 <mboddu> thanks everyone
18:25:51 <nirik> mboddu: you going to unblock those?
18:26:31 <roshi> np np
18:26:32 <mboddu> nirik: if you want you can do that and I can look at some of the last min things or else I can do that
18:26:55 * roshi sets the fuse
18:26:57 <roshi> 3...
18:27:26 <adamw> i updated the ticket to request they all be unblocked.
18:29:09 <roshi> 2...
18:29:11 * nirik moves to releng
18:29:26 <mboddu> nirik: are you doing the unblocking?
18:30:34 <roshi> 1...
18:30:40 <roshi> #endmeeting