16:01:32 #startmeeting F28-blocker-review 16:01:32 Meeting started Mon Mar 12 16:01:32 2018 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:32 The meeting name has been set to 'f28-blocker-review' 16:01:32 #meetingname F28-blocker-review 16:01:32 #topic Roll Call 16:01:32 The meeting name has been set to 'f28-blocker-review' 16:01:36 .fire mboddu 16:01:36 adamw fires mboddu 16:01:51 morning folks, who's around for the meeting? except mboddu. obvs. :P 16:01:52 * pwhalen is here 16:01:59 * satellit listening 16:02:00 * lruzicka is here 16:02:02 * suprith4989 is here 16:02:09 * puiterwijk is here for once 16:02:16 * lbrabec is here 16:02:36 hello 16:02:42 * kparal is here 16:02:47 * kalev is here 16:02:52 .hello2 16:02:53 frantisekz: frantisekz 'František Zatloukal' 16:03:00 * kparal waves at lbrabec 16:03:15 * coremodule is here! Willing to secretarialize as well. 16:03:21 .hello2 16:03:22 roca: roca 'Luis Roca' 16:04:11 thanks for coming, everyone 16:04:26 #chair pwhalen kparal 16:04:26 Current chairs: adamw kparal pwhalen 16:04:40 impending boilerplate alert! 16:04:40 #topic Introduction 16:04:41 Why are we here? 16:04:41 #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:04:41 #info We'll be following the process outlined at: 16:04:41 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:43 #info The bugs up for review today are available at: 16:04:45 #link http://qa.fedoraproject.org/blockerbugs/current 16:04:47 #info The criteria for release blocking bugs can be found at: 16:04:49 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:04:51 #link https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria 16:04:53 #link https://fedoraproject.org/wiki/Fedora_28_Final_Release_Criteria 16:04:55 #info coremodule will secretarialize 16:04:57 thanks coremodule 16:05:08 no problem! 16:05:56 for Beta, we have: 16:05:57 #info 4 Proposed Blockers 16:05:57 #info 6 Accepted Blockers 16:06:00 #info 9 Proposed Freeze Exceptions 16:06:01 #info 1 Accepted Freeze Exceptions 16:06:10 coremodule: if you need some refresher how to update a particular bug, just PM me 16:09:03 * pwhalen just ninja'd another blocker in 16:09:12 starting with the proposed blockers... 16:09:13 * sumantro is here 16:09:17 pwhalen: ok, remind me at the end if i don't do it 16:09:18 #topic (1553488) 'KickstartSpecificationHandler' object has no attribute 'UserData' 16:09:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1553488 16:09:19 #info Proposed Blocker, anaconda, POST 16:09:24 * adamw will brb, call of nature 16:09:28 adamw, will do 16:09:40 +1 16:09:49 kparal, will do! 16:10:48 +1 per criterion in comment 8 16:11:03 +1 16:11:04 +1 16:11:18 +1 16:11:20 +1 16:12:02 Isn't the bug resolved already as per comment 10? 16:12:07 otherwise +1 16:12:30 Well, without an accepted blocker, it won't go into the compose 16:12:32 So +1 16:12:35 +1 16:13:08 lruzicka: a new build is not created yet, it seems. and it needs a to be pushed into the compose, which needs either a blocker or a freeze exception, as puiterwijk says 16:13:42 fixing this just in source code is of course not enough 16:13:47 kparal: Thanks, kparal, in that case a blocker of course. 16:14:12 kparal: Now, I start to understand a bit :D 16:14:58 * mboddu is here now 16:15:39 proposed #agreed 1553488 - AcceptedBlocker (Beta) - clearly violates "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account." 16:15:49 ack 16:15:52 ack 16:15:53 ack 16:15:56 ack 16:15:57 ack 16:16:27 lruzicka: once the fix is committed to upstream anaconda git, we still need a release from upstream, then a package build, then - when bodhi is enabled for the affected branch - an update submitted. when freeze is in effect, the update can only be pushed stable if there is an accepted FE or blocker bug. 16:16:31 #agreed 1553488 - AcceptedBlocker (Beta) - clearly violates "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account." 16:16:48 #topic (1553792) Gnome Software doesn't offer upgrade from F26 to F28 16:16:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1553792 16:16:48 #info Proposed Blocker, gnome-software, NEW 16:17:11 has anyone else confirmed this? does sound like a blocker as described. 16:17:34 * kalev hasn't checked it. 16:17:42 adamw: why not? 16:18:10 I haven't checked it either 16:18:13 i said 'does' 16:18:25 * lruzicka has not either. 16:18:29 * satellit related: gnome-software was not in branched workstation as of Fedora-Workstation-Live-x86_64-28-20180309.n.0.iso 16:18:34 adamw: my eyes betrayed me 16:18:43 .fire kparal's eyes 16:18:43 adamw fires kparal's eyes 16:18:53 satellit: Now, it is in 20180310.n.0 16:18:58 * kparal imagines what everybody else says 16:19:02 +1 16:19:10 +1 per criterion 16:19:12 +1 16:19:15 +1 16:19:15 +1 16:19:16 * satellit not tested 16:19:18 +1 16:19:23 +1 16:19:27 +1 16:19:46 I can test it tomorrow 16:20:18 satellit: that was another bug (one we're coming to in a minute, in fact) 16:20:30 k 16:21:21 proposed #agreed 1553792 - AcceptedBlocker (Beta) - seems like a clear violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed" for Workstation (where Software is the recommended upgrade mechanism), would be good if others could confirm 16:21:26 ack 16:21:27 ack 16:21:30 ack 16:21:36 ack 16:21:42 ack 16:21:47 ack 16:22:04 ack 16:22:06 ack 16:22:10 #agreed 1553792 - AcceptedBlocker (Beta) - seems like a clear violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed" for Workstation (where Software is the recommended upgrade mechanism), would be good if others could confirm 16:22:22 #topic (1553646) Upgrading F27 > F28 is not possible because of nss-pem 16:22:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1553646 16:22:23 #info Proposed Blocker, nss-pem, MODIFIED 16:23:54 this doesn't happen with default package set I think 16:24:18 nss-pem.i686 is most probably not installed by default 16:24:26 so, +1 FE? 16:24:31 so while this probably affects many people, not a default install 16:24:38 yeah, -1 blocker +1 FE then. 16:24:43 Well... 16:24:48 It's even installed in the docker minimal root 16:24:55 is it? hum. 16:25:03 um 16:25:07 the *i686* one is? 16:25:08 ^[[A[puiterwijk@workstation ~]$ docker run --rm -it fedora:27 /bin/rpm -q nss-pem 16:25:10 nss-pem-1.0.3-5.fc27.x86_64 16:25:12 OH, no. 16:25:15 this only affects x86_64 installs with i686 installed, i think. 16:25:15 the x86_64 one is 16:25:16 the issue is with i686 on x86_64 16:25:25 Right, sorry 16:25:31 also, wouldn't --allowerasing work here, and just remove it? 16:25:45 it'll also remove affected packages 16:25:49 so, wine for example 16:25:52 are you sure? 16:26:02 i thought the whole reason this was a problem was that wine didn't require it any more 16:26:02 99.99% sure :D 16:26:12 if it did, wouldn't it be multilib automatically? 16:26:17 iirc gnome-software upgrade passes --allowerasing to the depsolver by default 16:26:32 I'm also confused by wine being uninstalled 16:26:32 yeah, which i'm not a huge fan of, because it could result in a drastically broken system in some cases, but hey 16:27:00 it reports the packages it's going to remove, at least 16:27:14 (when you tell dnf 'allow erasing', it really takes it seriously, and will happily perform any 'upgrade' which does not involve erasing a protected package...not many packages are protected...) 16:27:15 Well, I have just checked and I have wine NOT installed. 16:27:18 anyhoo 16:27:29 that's kind of a sideline, I'm -1 blocker / +1 fe regardless 16:27:34 -1/+1 16:27:41 -1 blocker, +1 FE 16:27:46 Although I did have it, and used --allowerasing to be able to upgrade 16:27:56 So, I just checked. And the nss that's now in f27 does not require nss-pem 16:28:00 -1 Blocker/+1 FE 16:28:02 -1/+1 16:28:06 -1 blocker / +1 fe 16:28:09 -1 blocker, +1 FE 16:28:16 So I think --allowerasing should be able to correctly remove nss-pem without erasing nss.i686 (and thus wine) 16:28:19 -1 blocker/+1 FE 16:28:22 -1 blocker, +1 FE 16:28:55 proposed #agreed 1553646 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this does not affect any default package sets so far as we know, so not a blocker, but is likely to affect many folks with wine installed, so we think it's worth a freeze exception 16:29:01 ack 16:29:03 ack 16:29:10 ack 16:29:13 frantisekz: please verify wine during upgrade, thanks 16:29:30 puiterwijk: the important thing would actually be whether the nss in *f28 stable* requires it, i think. 16:29:51 kparal: ack 16:30:03 #agreed 1553646 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this does not affect any default package sets so far as we know, so not a blocker, but is likely to affect many folks with wine installed, so we think it's worth a freeze exception 16:30:03 adamw: right. And that, they said, is no longer the case 16:30:13 #topic (1552910) Upgrading F27 > F28 is not possible because of shim 16:30:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552910 16:30:13 #info Proposed Blocker, shim, MODIFIED 16:30:23 so...this is interesting. this is the bug i thought was stopping gnome-software from being in composes 16:30:52 me too 16:30:56 ahhh... that bug. 16:31:10 +1 16:31:18 Gnome software is in the last compose, though. 16:31:22 I can confirm. 16:31:36 it's in the last two composes 16:31:39 huh, weird 16:31:42 right? 16:32:11 adamw: I only tested the last one :) but, as you are saying :) 16:32:17 seems we have shim-ia32, shim-unsigned (a really old version of that), shim-unsigned-ia32 and shim-unsigned-x64 in the composes also 16:32:25 last week we had a tagging issue, an older build got tagged in f28 16:32:29 shim-ia32-13-1.x86_64.rpm 16:32:33 ah, that could explain it 16:32:38 shim-unsigned-0.8-1.fc22.x86_64.rpm 16:32:42 (that really shouldn't be there, i don't think) 16:32:46 shim-unsigned-ia32-13-0.2.fc28.x86_64.rpm 16:32:50 shim-unsigned-x64-13-0.2.fc28.x86_64.rpm 16:33:15 just checked the upgrade 16:33:20 and it looks like it's fixed 16:33:26 shim-ia32 would be from https://koji.fedoraproject.org/koji/buildinfo?buildID=1051707 16:33:35 the others are from https://koji.fedoraproject.org/koji/buildinfo?buildID=1041248 16:33:58 running "sudo dnf system-upgrade download --refresh --releasever=28 --disablerepo=updates-testing" doesn't want to remove gnome-software anymore 16:34:12 per openqa, uefi installs work 16:34:14 (not sure about secure boot) 16:34:42 let me see if there's a pjones around 16:35:23 see if there are any potential blocker/fe consequences of having those builds of shim bits 16:36:31 if he's not around, i suggest we leave this proposed for now, post an update, i'll follow up with pjones and we can come back to it next time 16:37:25 sounds good 16:38:35 welp, not getting a response from planet pjones, so... 16:39:01 adamw: random idea: would you be interested in working together on testing secureboot in openqa? I've recently written some utilities to be able to do that quite easily 16:39:31 (I'll actually bring that up in #-qa after the meeting) 16:39:48 proposed #agreed 1552910 - punt (delay decision) - seems a tagging error has been fixed and current composes get a random selection of shim packages that at least doesn't block gnome-software; we will follow up with pjones to see if there are any other problems here and then make a decision 16:39:53 ack 16:39:58 ack 16:40:00 ack 16:40:02 ack 16:40:03 ack 16:40:03 ack 16:40:18 ack 16:40:18 ack 16:40:22 ack 16:40:38 ack 16:40:43 #agreed 1552910 - punt (delay decision) - seems a tagging error has been fixed and current composes get a random selection of shim packages that at least doesn't block gnome-software; we will follow up with pjones to see if there are any other problems here and then make a decision 16:41:08 #topic (1552130) Intermittent boot issues on the rpi3 with uboot-tools-2018.03-0.8.rc3 16:41:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552130 16:41:09 #info Proposed Blocker, uboot-tools, ON_QA 16:41:16 this is the one you ninja-ed, right pwhalen? 16:42:15 yes 16:42:42 it should be fixed with the latest uboot, but I havent confirmed it yet 16:43:03 adamw: Is this a release blocking criteria? 16:44:09 mboddu: per https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Supported_Hardware, RPi3 is a supported ARM board 16:44:49 Would that block x86_64 architecture, too? 16:45:01 No, but armhfp is a primary architecture. 16:45:09 right. 16:45:10 seems to violate criteria requiring the system to boot without intervention 16:45:25 'intermittent' makes it a bit of a judgment call 16:45:27 Yeah, what kparal said. I was just looking through the criteria 16:45:36 pwhalen: how often does it happen? 16:46:29 kparal, pretty regular 16:46:48 we have a tester for the latest nightly, who hit it (and has hit it before) 16:46:50 puiterwijk: Okay, I didn't know we have to support each and every board as part of armhfp being primary arch 16:47:12 mboddu: we don't support every board. We support the ones the ARM WG(?) deems supported 16:47:27 https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices 16:47:32 https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms 16:47:37 damn 16:47:52 Oh, or the one from kparal. That looks more concrete 16:48:11 looks like I need to update that for f28 16:48:11 puiterwijk: Yes, by each and every board I meant the supported boards listed on the wiki 16:48:30 rpi3 is pretty popular, and also used for aarch64. 16:48:31 mboddu: if it's listed under "Supported platforms", then yes, that's supported 16:48:41 kparal's is the correct link. 16:48:46 Yeah 16:48:56 Anyway, we got an updated uboot that needs to be tested 16:49:05 i think that list is supposed to be signed off on by fesco per cycle, or something. Some kinda bureaucracy, anyway! 16:49:16 and reported to fix this as well, just not confirmed myself 16:49:20 so, assuming we're going with the f27 list for now, +1 blocker. 16:49:33 Yeah, +1 blocker if it happens often 16:49:36 +1 16:49:46 Yeah, +1 blocker 16:50:24 +1 blocker 16:50:32 +1 16:51:33 +1 16:51:44 +1 16:52:39 just writing a justification here 16:52:45 +1 16:56:17 proposed #agreed 1552130 - AcceptedBlocker (Beta) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" for the release-blocking ARM minimal and Xfce disk images, on Raspberry Pi 3, which is a supported ARM platform per https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms 16:56:20 sorry 16:56:30 ack 16:56:30 ack 16:57:02 ack 16:57:03 ack 16:57:07 ack 16:57:20 ack 16:57:24 ack 16:57:26 ack 16:57:43 ack 16:58:57 ack 17:00:12 #agreed 1552130 - AcceptedBlocker (Beta) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" for the release-blocking ARM minimal and Xfce disk images, on Raspberry Pi 3, which is a supported ARM platform per https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms 17:00:28 pjones: thanks, sorry i gave you the wrong channel name earlier - i'll follow up with you in a bit 17:00:46 #info moving onto the proposed freeze exceptions 17:02:25 * satellit afk 17:02:29 #topic (1418336) Anaconda won't accept /boot on btrfs subvol, installation is impossible on my machine 17:02:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1418336 17:02:29 #info Proposed Freeze Exceptions, anaconda, NEW 17:02:52 so, basically, npmccallum wrote some patches to let /boot on btrfs-subvolume actually work, and would like us to put it into beta 17:03:05 he claims it's all tested and won't break anything else 17:03:53 what could it break.... :D 17:04:07 "I have tested this configuration manually, but for broader testing it is crucial we land in beta." 17:04:21 I see his point 17:05:04 I guess I'm more in favor 17:06:19 i'm kinda split, bootloader stuff is *weird* and i wish we'd got this in earlier. but it is something people have been asking for forever. 17:06:37 i guess i'm reluctantly willing to give it a +1. 17:06:41 note - the change to grubby is not yet merged either, so thisis double blocked 17:06:45 https://github.com/rhboot/grubby/pull/32 17:07:25 that needs review/testing as well because kernel updates use grubby invoked from the post-install scriplets to update for the new kernel versions 17:07:59 what is the procedure? will the freeze be lifted after beta and this could sneak in, or will it have to wait until post Final Release update? 17:08:12 imho it should be in rawhide and scheduled for F29 17:08:48 Or ... it can be the very first update of F28 final release? 17:09:17 that patch is in https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0e98e4635 17:09:17 Kellin: i'm treating the bug as covering all related packages. 17:09:34 lruzicka: we are debating right now whether to put it in beta. 17:09:41 adamw: my vote is the same, it should be placed in rawhide and scheduled to F29; not beta 17:09:49 if we don't put it in beta, it's up to the maintainers of the relevant packages whether they land it between beta release and the final freeze. 17:10:15 adamw: I understand. I am asking if, when it does not make it to beta, there is an option to have in Fedora 28. I guess not? 17:10:18 lruzicka: shipping it as an update for f28 would not make an awful lot of sense as it's partly an *installer* change 17:10:31 the installer is basically frozen when we release (ignoring the semi-official post-release live image respins) 17:10:45 lruzicka: it could theoretically be put in between beta and final. 17:10:47 adamw: Yeah, of course :) 17:10:59 adamw: Thats what I meant, too. 17:11:00 that'd arguably be against some update policies, but it's not like people haven't done that sort of thing before. :P 17:11:09 Why has this not been addressed in previous releases? Is there something missing that''s creating a conflict? 17:11:10 nat would prefer it go into beta if we want it to be in f28, though, as it will get more testing that way. 17:11:25 roca: grubby didn't know how to work with btrfs subvolumes. 17:11:39 the thing that changed is someone taught grubby to do that. 17:11:40 * pjones has no opinion on the anaconda bit, but the grubby bit is separable from that and already requested for stable. 17:12:01 requested, sure, but it won't be pushed unless we accept this as FE 17:12:04 understood 17:12:08 pjones: do you think the grubby changes are fairly safe? 17:12:10 I am in, because it is always nice to have better functionality. 17:12:44 if it works, of course 17:12:44 adamw: I do; there's not many cases they actually effect, and npmccallum wrote a pile of test cases for it 17:12:51 awww, they're so innocent when they're new 17:12:57 i like that. 17:13:01 adamw: :) 17:13:13 lruzicka: give it six months and you too will own a t-shirt with "NO" written on it. :P 17:13:28 :) 17:13:40 adamw: :) Therefore I do not push for anything :) 17:13:45 lruzicka: and after 2 years, you get it tattoo'd :op 17:13:53 :D 17:14:12 adamw: you know you're just going to find something else you want in grubby and we'll get it anyway ;) 17:14:12 * nirik has a related question.. does this stuff have anything to do with moving to the BLS in systemd? or thats completely seperate? 17:14:13 * mkolman still remembers the uefi32 fallout in F27 17:14:18 adamw: quick question, the patch is not merged upstream, so what happens if we ship in beta and the patch gets rejected upstream? 17:14:32 nirik: i believe it's separate, but imbw. 17:14:49 pjones: are you grubby upstream? 17:14:50 nirik: that's completely separate 17:14:55 adamw: sadly yes 17:15:01 pjones: are you going to reject the patch? 17:15:07 no. 17:15:11 mboddu: ^^ solved. :P 17:15:25 (the patch is merged upstream.) 17:15:35 * mboddu didn't know pjones is the maintainer until now :D 17:15:38 so, votes? 17:15:41 where is grubby upstream today if not https://github.com/rhboot/grubby ? 17:15:51 That's where it is. 17:16:09 https://github.com/rhboot/grubby/pull/32 needs marked as merged then - that's the source of mboddu's confusion 17:16:17 ... it is. 17:16:29 Kellin: pjones just merged it 17:16:37 sneaky. 17:16:58 I mean, I told you. 17:16:59 I see pushed to master, so +1 :) 17:17:36 +1 17:17:41 frantisekz: Are we going the risky side then? 17:17:44 +1 17:17:46 +1 17:18:09 lruzicka: looks like so 17:18:15 +1 fe 17:19:07 +1 fe 17:19:09 proposed #agreed 1418336 - AcceptedFreezeException (Beta) - we're a bit unhappy about touching bootloader stuff during a chaotic freeze, but this is a feature people have been asking for for a long time that'd add significant value to F28, and if we want it in, we'd better test it in Beta 17:19:25 ack 17:19:27 ack 17:19:29 ack 17:19:32 ack 17:20:13 ack 17:20:14 #agreed 1418336 - AcceptedFreezeException (Beta) - we're a bit unhappy about touching bootloader stuff during a chaotic freeze, but this is a feature people have been asking for for a long time that'd add significant value to F28, and if we want it in, we'd better test it in Beta 17:20:30 * mboddu is a bit worried about non x86 arches, but ehhh 17:21:28 ack 17:21:36 sorry about the delay 17:21:48 #topic (1553935) Installer auto-quits after Workstation live install (as no spokes are on the install hub) 17:21:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1553935 17:21:49 #info Proposed Freeze Exceptions, anaconda, NEW 17:23:37 so yeah, if you haven't done a Workstation live install lately, try one, it's fun. :P 17:24:06 we tried today twice on two different bare metals, crashed every time on startup 17:24:17 so, not that much fun 17:24:26 with which compose? 17:24:33 the latest one 17:24:37 huh. 17:24:39 what crash? 17:24:50 frantisekz: ^ 17:24:51 hmmm 17:24:55 adamw: bug 1524700 17:25:00 oh, usb, right. 17:25:02 use a shiny disc! 17:25:07 (or use the updates image) 17:25:07 haha 17:25:15 anyway, +1 FE here 17:25:20 .bug 1524700 17:25:23 mboddu: Bug 1524700 – AttributeError: 'NoneType' object has no attribute 'name' - https://bugzilla.redhat.com/1524700 17:25:26 I'd even vote +1 Final 17:25:27 kparal: Do we have a burner? Maybe we should try the disk. 17:25:44 +1 17:26:36 should be an anaconda that fixes 1524700 today, btw. 17:26:42 whoa! +1 FE 17:27:04 adamw: https://koji.fedoraproject.org/koji/taskinfo?taskID=25662380 17:27:21 mkolman: yay 17:28:04 proposed #agreed 1553935 - AcceptedFreezeException (Beta) - this could clearly confuse/concern users installing Workstation live in the Beta, and cannot be fixed with an update 17:28:16 ack 17:28:20 ack 17:28:21 ack 17:28:30 ack 17:28:48 ack 17:29:44 ack 17:29:50 ack 17:29:57 ack 17:30:32 #agreed 1553935 - AcceptedFreezeException (Beta) - this could clearly confuse/concern users installing Workstation live in the Beta, and cannot be fixed with an update 17:30:44 #topic (1552045) Include bolt 0.2 release 17:30:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552045 17:30:44 #info Proposed Freeze Exceptions, bolt, MODIFIED 17:31:40 +1 FE 17:31:41 +1 FE 17:31:42 +1 fe 17:32:00 +1 fe 17:32:17 +1 FE 17:32:19 +1 fe 17:32:28 +1fe 17:32:33 +1 fe 17:33:40 proposed #agreed 1552045 - AcceptedFreezeException (Beta) - this is part of an accepted Change for F28, it'd be good to have it in Beta for testing, and it should not endanger any release-blocking path 17:33:43 (the 's' word, i know) 17:34:22 *should* ---> there's always hope! 17:34:32 (yeah, you're really not using that in an rfc2119-compatible way. 17:34:32 ) 17:34:35 ack 17:34:37 ack 17:34:38 hope dies last 17:34:40 ack 17:34:46 ack 17:34:48 ack 17:35:01 ack 17:35:23 #agreed 1552045 - AcceptedFreezeException (Beta) - this is part of an accepted Change for F28, it'd be good to have it in Beta for testing, and it should not endanger any release-blocking path 17:35:25 akc 17:35:35 Late and miss typed :D 17:35:40 #topic (1552814) Need builds for F28 and F29 that reflect the Modularity changes 17:35:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552814 17:35:41 #info Proposed Freeze Exceptions, fedora-repos, ASSIGNED 17:36:23 so far as actually enabling modularity goes this is a blocker, but so far as the criteria go i don't think it is. 17:36:26 adamw: We did build them, but sgallagh is planning on changing them and once he sends out the PR, I will review - merge- build them 17:36:31 yep. 17:36:53 +1 FE 17:37:01 +1 FE 17:37:17 +1 FE 17:37:20 +1 FE 17:37:21 +1 17:37:23 +1 FE 17:37:45 +1 FE 17:38:31 mboddu: The PR was sent an hour ago. A review would be awesome :) 17:42:00 sgallagh: Ahh, sorry, I will take a look at it now 17:43:00 proposed #agreed 1552814 - AcceptedFreezeException (Beta) - the new files are necessary for Modularity enablement, which is a major Change for Fedora 28 and definitely needs to land in Beta 17:43:07 mboddu: Looks like Dennis did while I was at lunch; I'm updating my patch with his comment. 17:43:35 ack 17:44:03 ac 17:44:05 ack 17:44:06 ack 17:44:06 ack 17:44:07 ack 17:44:09 ack 17:44:15 sgallagh: Okay 17:44:24 mboddu: Updated :) 17:44:28 #agreed 1552814 - AcceptedFreezeException (Beta) - the new files are necessary for Modularity enablement, which is a major Change for Fedora 28 and definitely needs to land in Beta 17:44:39 #topic (1552923) Revert inadvertently bumped soname 17:44:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552923 17:44:39 #info Proposed Freeze Exceptions, ghc-conduit-extra, ON_QA 17:46:46 +1 FE 17:47:14 +1 FE 17:47:19 +1 FE 17:47:30 +1 FE 17:47:30 +1 FE 17:48:27 proposed #agreed 1552923 - AcceptedFreezeException (Beta) - it would be good to get these dependencies in line for the Beta, it may affect the compose of some images 17:48:47 ack 17:49:07 ack 17:49:11 ack 17:49:15 ack 17:49:15 ack 17:52:15 #agreed 1552923 - AcceptedFreezeException (Beta) - it would be good to get these dependencies in line for the Beta, it may affect the compose of some images 17:52:23 #topic (1094489) add support for btrfs in grub2 on /boot 17:52:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1094489 17:52:23 #info Proposed Freeze Exceptions, grubby, ON_QA 17:52:36 oh, so we do have a grubby bug for the same thing 17:52:42 so, i say +1 on the same basis as the earlier bug. 17:52:47 +1 17:52:56 +1 17:52:58 +1 17:53:09 we cannot act differently 17:53:10 -1 17:53:12 +1 17:53:20 (mostly because I didn't respond fast enough on last one) 17:53:32 +1 17:54:16 proposed #agreed 1094489 - AcceptedFreezeException (Beta) - this part of the same feature enablement as 1418336, so our decision is the same 17:54:46 ack 17:54:47 ack 17:54:53 ack 17:55:31 ack 17:55:41 #agreed 1094489 - AcceptedFreezeException (Beta) - this part of the same feature enablement as 1418336, so our decision is the same 17:55:54 #topic (1552913) Several packages still need rebuilds against OpenCV 3.4 17:55:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552913 17:55:55 #info Proposed Freeze Exceptions, opencv, ON_QA 17:57:15 +1 fe 17:57:22 lots o' rebuilds 17:57:26 rebuilds are my life 17:57:29 (there's another one coming up later) 17:57:53 +1 17:58:15 +1 fe 17:58:15 +1 without it, the thing stays incomplete 17:58:43 +1 fe 17:58:58 +1 fe 18:00:15 proposed #agreed 1552913 - AcceptedFreezeException (Beta) - again, fixing up dependencies is a good thing to do for the compose, can avoid packages missing from composes and fix upgrade issues 18:00:36 ack 18:00:37 ack 18:00:43 ack 18:00:48 ack 18:01:08 ack 18:01:46 ack 18:02:22 #agreed 1552913 - AcceptedFreezeException (Beta) - again, fixing up dependencies is a good thing to do for the compose, can avoid packages missing from composes and fix upgrade issues 18:02:32 #topic (1549686) Review Request: f28-backgrounds - Fedora 28 default desktop background 18:02:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1549686 18:02:32 #info Proposed Freeze Exceptions, Package Review, ON_QA 18:02:46 this one's actually a blocker if the current background is the same as f27's... 18:02:47 adamw: btw, bug 1554453 is now proposed as well 18:03:00 thanks 18:03:35 "In this case, F28 backgrounds differ from the previous release so assigning to FE." 18:03:38 * pwhalen hasnt checked the background in a while 18:03:46 uh 18:03:46 +1 FE 18:03:48 +1 FE 18:03:50 no 18:03:53 that sounds like the person didn't understand me 18:03:58 of course the *new* backgrounds are different 18:04:06 the question is what the background *before* the update looks like 18:04:13 openQA says it looks like this: 18:04:13 https://openqa.fedoraproject.org/tests/200929#step/_do_install_and_reboot/31 18:04:21 which is indeed the f27 background, isn't it? 18:04:26 yea 18:04:31 so, this is a blocker. 18:04:32 +1 blocker 18:04:33 ok 18:04:36 +1 blocker 18:04:45 adamw: My virtual machine had a different background 18:05:24 the last compose Workstation had some funny spheres ...it looked like pencilart 18:05:36 lruzicka: did you do a network install? 18:05:39 and/or update after install? 18:05:40 yes (RE: the 27 background) +1 blocker 18:06:11 fresh install Fedora Workstation from Everything-netinst 18:06:58 ok, yeah, if you use a netinst, it's going to pull in updates-testing, i believe. 18:07:00 lruzicka: https://openqa.fedoraproject.org/tests/201905#step/_do_install_and_reboot/57 18:07:03 is that what you saw? 18:07:03 BTW: http://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/ 18:07:34 adamw: This exactly :) 18:07:44 lruzicka: that's the new background, yes. but it's only in updates-testing atm. 18:07:45 I can confirm the wallpaper is F27 one, when installed from Live 18:07:51 so live images don't have it, for e.g. 18:08:49 proposed #agreed 1549686 - AcceptedBlocker (Beta) - we are accepting this as a blocker (not just FE) as the background in current F28 composes is the same as the F27 background, which violates "The default desktop background must be different from that of the last two stable releases" 18:08:56 ack 18:09:04 ack 18:09:06 if so, then ack 18:09:10 ack 18:09:53 #agreed 1549686 - AcceptedBlocker (Beta) - we are accepting this as a blocker (not just FE) as the background in current F28 composes is the same as the F27 background, which violates "The default desktop background must be different from that of the last two stable releases" 18:09:56 ack 18:10:04 coremodule: so, remember to change that from blocking the FE bug to blocking the blocker bug 18:10:35 #topic (1552318) Re-base Dogtag 10.5 to Dogtag 10.6 18:10:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=1552318 18:10:35 #info Proposed Freeze Exceptions, pki-core, NEW 18:10:36 mkolman: thanks for that link 18:10:53 np - saw it on planet Fedora a few days ago :) 18:10:58 so, aiui, this is basically freeipa folks asking for permission to bump the release of something as this is part of how they want to go about fixing freeipa to actually work. 18:11:17 adamw, roger, will do! 18:12:10 i am an unhappy +1 on it. 18:12:24 because it sounds like we're basically not going to get a working freeipa any other way. 18:12:49 we could try digging in our heels and saying "you've got to make whatever major versions are in beta right now work with each other", but practically speaking i doubt we'd get very far with that. 18:13:13 +1 18:13:19 +1 18:13:42 +1 18:13:58 +1 :/ 18:14:00 +1 18:14:01 +1 but maybe we should tell them to be more exact on dates? 18:14:29 agreed. they didn't seem to provide an estimate on the requested extension 18:15:08 lruzicka: yeah, i'm trying to kick up a bit off fuss about this for future releases too 18:15:43 adamw: thanks, that's a good thing to do :) 18:16:13 proposed #agreed 1552318 - AcceptedFreezeException (Beta) - we're not super happy about major version bumps this late, but it seems this is the only way we are likely to get a working FreeIPA. we would like to ask the FreeIPA-related teams to co-ordinate to get appropriate, interoperable versions landed *before* Beta freeze in future cycles. 18:16:31 good so, ack 18:16:35 ack 18:16:40 ack 18:16:47 ack 18:16:56 #agreed 1552318 - AcceptedFreezeException (Beta) - we're not super happy about major version bumps this late, but it seems this is the only way we are likely to get a working FreeIPA. we would like to ask the FreeIPA-related teams to co-ordinate to get appropriate, interoperable versions landed *before* Beta freeze in future cycles. 18:18:14 #topic (1554453) "exported surface had an invalid role" protocol errors from xdg_exporter when opening files 18:18:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1554453 18:18:15 #info Proposed Freeze Exceptions, mutter, NEW 18:18:51 so, this one boils down to 'nautilus crashes a lot' 18:19:07 since it's a core Workstation app, definitely seems +1 blocker to me. will affect use of Workstation lives, for e.g. 18:19:23 not a lot, always when you try to open a file 18:19:47 +1 , clear blocker then 18:19:53 +1 blocker 18:20:00 it's proposed against Final, to be clear 18:20:03 and Beta FE 18:20:25 our Beta criteria don't talk about nautilus 18:20:38 +1 beta FE, +1 Final blocker 18:20:50 kparal: But we test for core apps and Nautilus is one of them 18:21:09 do we have a Beta criterion for core apps? 18:21:13 I have no problem to go as adamw ... just saying 18:21:27 kparal: don't think so 18:21:44 I'm not happy with this not blocking Beta 18:21:52 but I don't see anything matching 18:22:02 we could tweak the criteria, i guess. it's always a balance. 18:22:23 what do others think? it's non-functional file manager good enough for Beta? 18:22:38 I'd tweak the criteria, so this counts as a beta blocker 18:22:56 where do you draw the line? 18:23:08 I'm not convinced myself, it's still Beta. I'm just asking 18:23:12 do we move the whole 'core apps' criterion (whatever it says exactly) from final to beta? 18:23:52 adamw: I would say yes, because core apps should be working in Beta 18:24:09 well, so, we can discuss it outside the meeting, if we just want to discuss the principle 18:24:19 we only have to discuss here if we think it's important enough to make *this specific* bug a blocker 18:24:30 adamw: the funny thing is, we block on all core apps except gedit and nautilus in Beta already :) 18:24:32 bearing in mind that we have a fix for it, so making it an FE means it's going to get fixed anyway... 18:24:43 kparal: heh, i guess we do... 18:24:44 firefox, gnome-software, terminal, boxes 18:25:07 adamw: that would still go fixed if that was a blocker, right? 18:25:09 aaanyway. if the fix is ready, let's move on 18:25:20 kparal: do go ahead and draft a criteria proposal... 18:25:23 +1 FE (it does seem like a blocker-ish imo) 18:25:26 so, +1 FE then for now 18:25:37 +1 final blocker, +1 beta FE at the moment 18:25:41 +1 FE for now 18:25:42 adamw: kparal: I can try to think about some 18:26:01 +1 FE now, +1 final blocker 18:26:26 proposed #agreed 1552318 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - we accept this as an FE (it's an obvious major bug in a core Workstation component that will affect live experience) and a Final blocker (as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic 18:26:26 functionality test") 18:26:27 +1 final blocker, +1 beta FE 18:26:32 grr 18:26:37 sorry 18:26:39 proposed #agreed 1552318 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - we accept this as an FE (it's an obvious major bug in a core Workstation component that will affect live experience) and a Final blocker (as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test") 18:26:48 roca: no, i was 'grr'ing that my proposal was too long :) 18:27:02 :D 18:27:12 adamw: But it exactly names the problem. 18:27:14 ack 18:28:01 ack 18:28:13 ack 18:29:08 #agreed 1552318 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - we accept this as an FE (it's an obvious major bug in a core Workstation component that will affect live experience) and a Final blocker (as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test") 18:29:11 ok, one more... 18:29:30 #topic (1554464) Rebuilds for GCC 8 ABI change miscompilation issue 18:29:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1554464 18:29:31 #info Proposed Freeze Exceptions, distribution, MODIFIED 18:29:36 yet another set of rebuilds. 18:29:51 i am still not sure exactly what this 'miscompilation' entails, but getting the rebuilds in seems like a solid idea. 18:29:55 +1 18:30:17 +1 18:30:31 +1 18:31:02 +1 FE 18:32:17 +1 FE 18:32:51 proposed #agreed 1554464 - AcceptedFreezeException (Beta) - when the gcc maintainers tell us their compiler miscompiled some stuff and it should be recompiled, recompiling it seems like a good plan. 18:33:00 ack 18:33:05 ack 18:33:05 ack 18:33:21 ack 18:33:22 ack 18:33:55 #agreed 1554464 - AcceptedFreezeException (Beta) - when the gcc maintainers tell us their compiler miscompiled some stuff and it should be recompiled, recompiling it seems like a good plan. 18:34:03 ok, that's all the proposals 18:34:20 #info that's all the proposals 18:34:35 looking at existing accepted blockers, most are clearly being addressed... 18:34:42 let's just quickly check in on two that aren't 18:34:47 #info quick check-in on accepted blockers 18:34:53 #topic (1496562) freeipa tests in Fedora28+ shouldn't test for specific NSS database filenames, but should be flexible 18:34:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=1496562 18:34:53 #info Accepted Blocker, pki-core, ASSIGNED 18:35:00 so, this one is basically a proxy for 'freeipa don't work; 18:35:02 so, this one is basically a proxy for 'freeipa don't work' 18:35:27 as mentioned in earlier discussion, my broad understanding of the state here is 'we're waiting for freeipa devs to submit a bunch of new versions of things that should magically make everything work' 18:35:32 i will be following up with them this week 18:35:59 #info freeipa is still broken and has been for months, freeipa folks intend to fix it by landing new versions of several things; adamw will check in with them on precise plan 18:36:13 #action adamw to check with freeipa folks on plan and schedule for landing working freeipa bits 18:36:19 any other notes on this? 18:38:42 nothing from my end 18:39:16 ok 18:39:25 #topic (1520580) Unable to log in on arm disk images 18:39:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=1520580 18:39:25 #info Accepted Blocker, selinux-policy, NEW 18:39:44 * pwhalen hasnt seen any movement or change on this 18:39:50 hmm, okay 18:39:54 i'd better poke the selinux folks 18:40:04 #info this has been unaddressed for a long time, we need to ping selinux folks about it 18:40:13 #action adamw to ping selinux maintainers re 1520580 18:40:51 #topic Open floor 18:40:57 alrighty, any other issues to bring up, folks? any missed bugs? 18:41:27 nothing here 18:41:49 * pwhalen has nothing 18:42:22 nothing here 18:43:35 * lruzicka nothing 18:43:44 alrighty, thanks for coming, folks 18:43:48 now go forth and...fix all the bugs :P 18:43:59 \o/ 18:44:00 :) 18:44:03 thanks for leading the meeting adam 18:44:26 thanks for hosting the meeting adamw :) 18:44:33 #endmeeting