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