16:00:34 #startmeeting F25-blocker-review 16:00:34 Meeting started Mon Oct 3 16:00:34 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:34 The meeting name has been set to 'f25-blocker-review' 16:00:34 #meetingname F25-blocker-review 16:00:34 The meeting name has been set to 'f25-blocker-review' 16:00:34 #topic Roll Call 16:00:38 ahoyhoy folks 16:00:48 ah, we scared mclasen away already, good good 16:00:52 * kparal is here 16:00:55 who else is around to review some blockers? :) 16:01:14 cornmodule is here. 16:01:29 .hello jkurik 16:01:30 jkurik: jkurik 'Jan Kurik' 16:01:30 * pschindl is here and is willing to do the secretarization 16:01:33 * garretraziel will be somewhat lurking around 16:02:57 .hello sgallagh 16:02:58 sgallagh: sgallagh 'Stephen Gallagher' 16:04:00 * cmurf is completely totally convinced he's here 16:04:15 cmurf: are you sure ? 16:04:26 absolutely 16:04:33 just waiting for adamw to tell me I'm wrong 16:04:48 or even better, confused 16:05:05 you are feeling very sleepy 16:05:59 * cmurf zzzzzzz 16:06:35 #chair coremodule jkurik 16:06:35 Current chairs: adamw coremodule jkurik 16:06:40 gonna go make a coffee while we're gathering i guess 16:06:43 #info pschindl will secretarialize 16:07:18 * coremodule standing by for any other duty that may come up during the course of the meeting. 16:08:18 #info coremodule will refill adamw's drink 16:08:39 lol. Not that kind of doody. 16:08:39 #topic Introduction 16:08:40 Why are we here? 16:08:40 #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:08:40 #info We'll be following the process outlined at: 16:08:40 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:08:41 #info The bugs up for review today are available at: 16:08:43 #link http://qa.fedoraproject.org/blockerbugs/current 16:08:45 #info The criteria for release blocking bugs can be found at: 16:08:47 #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria 16:08:51 #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria 16:08:53 #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria 16:08:55 coremodule: you'd better have the swiftest hands in the west 16:09:05 .hellomynameis kushal 16:09:06 kushal: kushal 'Kushal Das' 16:09:06 for Beta, we have: 16:09:07 #info 3 Proposed Blockers 16:09:08 #info 3 Accepted Blockers 16:09:18 for Final, we have: 16:09:26 #info 6 Proposed Blockers 16:11:17 i believe sgallagh has another blocker proposal to add as well? 16:11:28 adamw: No, I was talking about one of the known ones 16:11:37 I was reading ahead of the class ;-) 16:11:40 oh, okay. i don't see a beta one? anyhoo 16:11:52 .bug 1381045 16:11:52 sgallagh: Bug 1381045 – xorg-x11-drv-qxl update lets sddm coredump - https://bugzilla.redhat.com/1381045 16:12:17 oh, missed that 16:12:18 alrighty 16:12:25 starting with the proposed beta blockers: 16:12:31 #topic (1379865) Current Fedora 25 and Rawhide cannot detect Intel firmware RAID set 16:12:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1379865 16:12:31 #info Proposed Blocker, libblockdev, POST 16:12:44 this one seems pretty slam dunk-y, intel firmware raid detection just no worky 16:12:54 there's a fix i need to test, didn't get time yet 16:13:20 * cmurf thinks he voted in the bug 16:13:28 adamw: I think it has enough votes in the bug to be approved already. 16:13:35 probably 16:13:46 +1 16:13:59 I was +1 in the bug, ftr 16:14:02 we have +3 from the bug report 16:14:06 so we're at +4 now 16:14:08 anyone -1? 16:14:24 +1 16:14:26 I am +1 16:15:17 +1 16:15:18 proposed #agreed 1379865 - AcceptedBlocker - violates Beta criterion " The installer must be able to detect and install to hardware or firmware RAID storage devices." 16:15:31 ack 16:15:35 ack 16:15:42 ack 16:16:11 Do we expect to get a fix for this today? I see there's a patch upstream. 16:16:12 ack 16:16:29 yes, like i said, there's a fix that I need to test. 16:16:35 ack 16:16:39 #agreed 1379865 - AcceptedBlocker - violates Beta criterion "The installer must be able to detect and install to hardware or firmware RAID storage devices." 16:16:48 #topic (1377113) [selinux-policy] media inserted into by optical drive do not get auto-mounted 16:16:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1377113 16:16:48 #info Proposed Blocker, selinux-policy, POST 16:17:00 +1 to be a blocker 16:17:08 i'm +1 to this too, automount is in beta criteria, and until you get selinux 216 it doesn't work 16:17:17 +1 still 16:17:17 all we need for this is an update for -216 i believe 16:17:17 +1 here. 16:18:05 +1 16:18:06 +1 16:18:50 ola 16:19:19 proposed #agreed 1377113 - AcceptedBlocker (Beta) - violates Beta criterion "Automatic mounting of removable media on insertion must work in release-blocking desktops." 16:19:21 sorry, I could not use the blocker app because it was not possible to set rhbz credentials 16:19:32 RaphGro: you have a bug to propose? 16:19:39 ack 16:19:40 already done 16:19:43 RaphGro: known bug 16:19:48 ack 16:19:50 ack 16:20:16 ack 16:20:17 adamw, 1381045 see above. that's from me. 16:20:24 Right, we'll get there next 16:20:47 RaphGro: sorry, blocker app problem is what I was referring to 16:20:55 cmurf, no problem 16:21:37 #agreed 1377113 - AcceptedBlocker (Beta) - violates Beta criterion "Automatic mounting of removable media on insertion must work in release-blocking desktops." 16:21:47 #topic (1381045) xorg-x11-drv-qxl update lets sddm coredump 16:21:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1381045 16:21:48 #info Proposed Blocker, xorg-x11-drv-qxl, NEW 16:22:29 So, this sounds like it's not a blocker *today*, but would be if we had to let in an update to X11 for another reason 16:22:31 as per #c5 I don't think this is actually affecting stable atm. 16:22:39 since openQA tests are passing (they use qxl) 16:23:08 is qxl the driver VM's are expected to work with? 16:23:30 i.e. if there's a work around using a different driver, we'd block on qxl? 16:24:02 cmurf: I think that would be slushy for Beta and strict for Final. (Just my personal opinion) 16:24:34 cmurf: it's the default for newly created VMs atm, i think, so i'd be inclined to block on it 16:24:49 but yeah, i think we can reject for now 16:24:53 -1 for me 16:24:54 Proposal: Since this *will* hit stable once we exit freeze, re-propose as Final Blocker 16:25:07 or perhaps it would be better to un-propose it 16:25:10 sure, that seems reasonable too 16:25:12 hmmm, if we have a workaround (as stated in comment #4) it should not be a blocker even for final IMO 16:25:28 -1 beta blocker 16:25:34 -1 Beta, +1 Final 16:25:56 -1 beta blocker; ? for final 16:26:05 maybe there needs to be a qxl add on to whatever the applicable final release criterion is? 16:26:10 so is this not a 0day blocker? 16:26:25 as long as updates-testing is enabled by default, it would make sense to treat it the same way as stable updates 16:26:27 -1 Beta 16:26:32 except that it doesn't block compose 16:26:40 right 16:27:17 kparal: hum, we've never really considered that case 16:27:22 I know 16:27:26 kparal: No, because the VMs will still boot until you update 16:27:36 and then they won't 16:27:44 yeah hence 0day blocker 16:28:09 When have we ever done a 0day blocker for Beta? 16:28:23 Let's just mark it as a Final Blocker and trust the maintainers to get it fixed ASAP 16:28:49 sgallagh: we've only had 0day blockers for one cycle :) 16:28:49 that is the easiest thing to do 16:29:23 adamw: Don't you go spouting "facts" and "realities" at me! 16:29:26 it's pretty reasonable to make it a 0day if it's reasonable to make it a final blocker 16:29:29 still, in this case i'd probably be ok with mentioning this in common bugs and suggesting people disable u-t or skip the x update if it's not fixed by release ady 16:29:32 sorry! 16:29:35 because it's kinda crappy to release working beta, and then break it on update 16:29:38 cmurf: indeed 16:30:05 Remind me what 0day blocker entails? 16:30:21 If Xorg doesn't get it fixed in time, do we slip after Go/No-Go? 16:30:30 "Accepted0Day is used for cases where the fix does not need to appear in the final frozen release, but must be available as an update on release day." 16:30:31 sgallagh: that the bug is fixed by release time and pushed out as a 0 day update 16:30:43 sgallagh: either fixed on unpushed in this case 16:30:45 as in we can be ready and not release if its not fixed 16:31:03 if we were to apply it to this case, i guess it'd mean that by beta release day, either a fixed xorg-x11-drv-qxl must be in the update or the update must be yanked 16:31:11 So we would do everything else for the release except announce it? 16:31:26 sgallagh: and release it 16:31:41 ok so why not just unpush the busted update now? 16:31:41 it would remain staged but hidden 16:31:50 i think we decided that in practice if the fix wasn't in place by go/no-go day we'd vote no-go, right? 16:31:53 Right, that's what I meant 16:31:54 cmurf: we could 16:32:10 adamw: likely 16:32:25 ok so just unpush the bad update, making it 0day is effectively the same power being used, and unpush now is a lot more reliable without last minute what is happening here stuff 16:32:30 adamw: yes 16:32:42 /me nods 16:32:56 OK, in this case, the "unpush" option seems perfectly reasonable 16:33:05 Shall we also go negkarma it as a group? 16:33:12 (So it doesn't slip in by accident) 16:33:16 bingo 16:34:25 or we could disable updates-testing for Beta release 16:34:30 when do we flip this? 16:34:34 usually 16:34:45 kparal: Final RCs, I think 16:34:46 proposed #agreed 1381045 - Accepted0DayBlocker (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day 16:34:53 kparal: final 16:35:02 yeah, right around Final freeze. 16:35:10 adamw: Ack 16:35:13 proposed #agreed 1381045 - Accepted0Day (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day 16:35:33 ack 16:35:44 ack 16:35:58 ack 16:36:03 ack 16:36:10 #agreed 1381045 - Accepted0Day (Beta) - the affected package is in updates-testing, so the Beta compose is not affected, but Beta installs will break on first update. So we accept this as a 0-day blocker, meaning (for Beta) a fixed package must be added to the update or the update must be unpushed, by go/no-go day 16:36:33 OK, moving on to the accepted blockers 16:36:46 #info Moving to Beta accepted blockers: not reviewing blocker status but checking that fix is in progress 16:36:53 #topic (1369786) Autopart fails on installation from live usb created by l-i-t-d 16:36:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:36:53 #info Accepted Blocker, anaconda, POST 16:38:15 ok so this gets to my late email about adamw's wiki update, and how this relates to what is officially supported methods of creating USB stick media 16:38:33 I think Fedora Media Writer should be it. The current wiki lists five methods I don't think all should be officially supported. 16:38:56 I agree with cmurf here. FMW should be the only *blocking* tool. 16:38:58 And as litd is getting stale I'm really on the fence there also. 16:39:06 Esp for beta. 16:39:09 Just not worth it. 16:39:22 i don't think we can suddenly change that now. 16:40:03 There have been far worse bugs than this that we didn't make people fix. *shrug* 16:40:17 Esp people who don't have time to maintain the tool. 16:40:39 And the wiki is vague on what is officially supported anyway. Only FMW is "recommended" in the current wiki. 16:40:46 adamw: Let's at least make the assertion for F26 now, so there's no question. 16:40:51 I'm not sure whether it's ok to change this during F25 release cycle, but I'd also remove litd from the recommended tools list 16:41:01 or at least not block on it 16:41:07 sgallagh: let's not, this meeting isn't the place to make that decision 16:41:16 /me shrugs 16:41:29 Frankly, I don't think that blocking on unmaintained software makes sense in general. 16:41:48 I'm -1 blocker, because the prior wiki and current wiki do not state l-i-t-d is a recommended or officially supported tool for creating USB stick media. 16:41:59 cmurf: given that i wrote the current page, i'd say that litd is covered. 16:42:10 If litd is covered, then unetbootin is covered. 16:42:15 cmurf: i would disagree with that assessment, and i wrote both versions of the page and the criteria. 16:42:25 I read the whole thing there is no differentiating language. 16:42:26 cmurf: no, it is not, because the wiki page explicitly says *not* to use unetbootin and that we do not support it. 16:42:29 sure there is. 16:42:58 the unetbootin section has a big yellow box at the top that says "Fedora cannot guarantee support for UNetbootin-written images." 16:43:12 then some more text that says "If you encounter problems with UNetbootin, please contact the UNetbootin developers, not the Fedora developers." 16:43:23 the section explicitly exists in order to state that we don't support unetbootin. 16:43:28 none of that is true of the litd section. 16:44:16 there is a metric ass ton of text on that page - no offense 16:44:23 :) 16:44:24 i already cut as much of it as possible 16:44:35 it's like, Rube Goldberg contraption of how to make Fedora install media 16:44:53 i know, but if you take any more out, people start whining about it. 16:44:57 reads like the rules of hockey, except when there's blood then it's a 4 minute penalty 16:45:15 OK then GNOME Disk Utility is blocking too? 16:45:19 There's no exception for that. 16:45:49 well, that's an interesting case 16:46:05 since the page says it's "for people running Linux (or another *nix) with GNOME, Nautilus and the GNOME Disk Utility installed." 16:46:13 The only one explicitly recommended on that page, still, is FMW. 16:46:35 argh, I missed the discussion of my blocker proposal. but I'm fine with the decision. go ahead. 16:46:43 everything else is "may be useful" I don't think it's OK to block on "may be useful". 16:47:10 And how can things not explicitly recommended be officially supported? 16:47:22 i think you're reading more into it than i wrote into it. 16:47:37 the problem is we're still a bit in transition 16:47:54 we'll need to discuss properly on the mailing list. for the moment, it would probably make sense to continue with how we evaluated things in the past 16:47:56 FMW does not really cover everything yet. particularly, you can't easily use it on non-Fedora Linux 16:48:11 anyway, we already *accepted* this as a blocker 16:48:22 oh christ 16:48:24 the idea isn't to re-litigate that decision (unless we really need to) but to check in on the progress of the fix 16:48:29 good point :) 16:48:36 yes indeed good point 16:48:38 this bug is in POST and the PR is acked 16:49:04 whoops sorry ;-P bill the cat moment 16:50:57 so i think this should be in hand 16:51:15 I need to go and get lunch. Adios 16:52:04 so moving on? 16:53:07 sgallagh: cya 16:53:09 i guess 16:53:25 i notice one reviewer asked for changes in the PR, so I posted a poke... 16:53:48 #topic (1374864) initial-setup is not completable when there's no network link 16:53:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1374864 16:53:49 #info Accepted Blocker, anaconda, POST 16:54:31 so there's a proposed fix for this, but some more testing would be good 16:54:40 i asked dgilmore in the bug and i just poked him on IRC too 16:55:43 ack? 16:56:04 oh, i should've done #info...oh well, we can skip it for one bug 16:56:21 #info a proposed fix for this is under review, we have asked dgilmore to check status with current nightlies and test proposed fix if possible 16:56:27 #topic (1225184) Live installer does not detect RAID devices 16:56:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1225184 16:56:28 #info Accepted Blocker, python-blivet, VERIFIED 16:57:12 this was a different RAID bug, we've verified that it's fixed with https://github.com/rhinstaller/anaconda/pull/812 16:59:28 so should be fixed in next anaconda build 16:59:38 #info the fix for this has been tested, only needs a new anaconda build 16:59:53 alright, that should be all Beta blockers covered 16:59:59 anything else before we go to proposed Final blockers? 17:00:49 nothing here 17:01:15 alrighty 17:01:21 #info moving to proposed Final blockers 17:01:35 #topic (1378156) TypeError: Must be number, not str 17:01:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=1378156 17:01:35 #info Proposed Blocker, anaconda, NEW 17:01:40 more iSCSI fun, iirc. 17:01:45 pretty clearly a blocker 17:01:47 +1 17:02:15 even though I pine for the day of iscsi going away 17:02:22 * adamw checks this is still hitting current f25 nightlies, as exactly how iscsi is broken seems to change daily 17:02:27 adamw: we're hitting this repeatedly, right? 17:02:48 yep, same error today. 17:02:50 https://openqa.fedoraproject.org/tests/38358/file/disk_custom_iscsi-anaconda.log 17:02:56 i see iscsi related tracebacks in anaconda logs - program or storage, not sure if that's related 17:03:08 +1 17:03:34 +1 to final blocker 17:03:49 +1 17:04:32 proposed #agreed 1378156 - AcceptedBlocker (Final) - violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 17:04:56 ack 17:04:57 ack 17:05:00 ack 17:05:10 ack 17:05:41 #agreed 1378156 - AcceptedBlocker (Final) - violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 17:05:48 #topic (1379459) Fedora 25 official backgrounds not yet present in images / installed systems 17:05:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1379459 17:05:49 #info Proposed Blocker, desktop-backgrounds, ON_QA 17:06:01 this one's probably fixed now, just need to check it 17:06:15 some non-blocking desktops will still need comps/kickstarts changes, i can propose those today 17:06:23 but GNOME, KDE and Xfce should be good, at least if i can read 17:06:41 anyhow, i'm +1, it's a clear blocker 17:07:04 +1 final blocker 17:07:07 +1 17:07:28 +1 17:07:29 +1 17:07:53 +1 17:08:38 proposed #agreed 1379459 - AcceptedBlocker (Final) - violates "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." 17:08:48 ack 17:08:50 ack 17:08:53 ack 17:09:05 ack 17:09:06 ack 17:09:58 #agreed 1379459 - AcceptedBlocker (Final) - violates "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." 17:10:08 #topic (1381039) USB devices aren't found or enumerated, results in boot failure from USB stick installation media 17:10:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=1381039 17:10:08 #info Proposed Blocker, kernel, NEW 17:10:12 huh, this is a new one. 17:10:18 gist of this one: I guess the release criterion would be that the install media has to boot; but since it only affects 1 of 4 of my systems, I went with the kernel team's FAQ instead. 17:10:36 adamw: I can confirm that initial-setup is still broken 17:10:54 suggestion: punt or vote conditional, see if the kernel team has any idea what's going on and whether and how I can provide more information? 17:11:08 It is, but given that it seems to only impact 1 system, I would be hard pressed to call it a blocker just yet 17:11:41 jforbes: it is, what? 17:11:51 cmurf: a new one, typing slow today 17:11:53 dgilmore: can you test the fix? 17:12:16 gotcha 17:12:44 jesus, that wiki text is old. 17:13:01 so yeah, as long as we only know of one system suffering from this and it's not a regression, i'm inclined to -1 17:13:09 we can't really block the release on random hardware enablement 17:13:35 anyone else seen this, by any chance? 17:13:51 I would be all for it if this were impacting a number of systems or a common chipset 17:13:58 it's a brand new out of box HP Spectre, it's not exotic hardware 17:14:33 It's just really new. No idea if HP is doing something silly, or if Intel just doesn't have supporting code upstream? I don't really know what the deal is... 17:14:36 cmurf: doesn't really matter how exotic it is 17:14:55 jforbes: presumably we don't have a flood of these reports for all skylake systems or anything? 17:15:15 adamw: no, we don't 17:15:29 Ok well I did what the kernel FAQ asked :-) that's the only reason why I nominated it a blocker. 17:16:01 anyway, yeah, i'm -1 unless we find out this affects other systems or we find that a million people just bought spectre 13s and are desperate to run fedora on them. 17:16:36 -1, same reason 17:17:48 Wow, that page needs an update 17:18:05 =) 17:18:20 counting jforbes as -1, that's -3 17:18:27 -1 17:18:31 -1 as well 17:19:10 proposed 1381039 - RejectedBlocker - so far we only know of a single affected system, and it's not a regression; this isn't a broad enough impact for a hardware-specific bug to be counted as a violation of the criteria. this decision can be revisited if more systems are found to be affected 17:20:07 ack 17:20:13 ack 17:20:19 ack 17:20:33 #agreed 1381039 - RejectedBlocker - so far we only know of a single affected system, and it's not a regression; this isn't a broad enough impact for a hardware-specific bug to be counted as a violation of the criteria. this decision can be revisited if more systems are found to be affected 17:20:44 #topic (1380859) Should obsolete liveusb-creator 17:20:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=1380859 17:20:44 #info Proposed Blocker, mediawriter, NEW 17:21:28 i'm kinda convinced to +1 this on the rationale that the thing you get if you try to install our 'supported tool' from Software isn't the right thing and doesn't work 17:21:40 though we're not sure just adding an obsoletes will entirely fix that... 17:22:09 i guess there's also the point that if you had our previous 'supported tool' installed, it might not work any more and there's nothing much to tell you what to do 17:22:10 maybe I should have reported it separately. the important thing is that obsoletion is not strictly important, but people have to be able to install FMW from gnome-software 17:22:22 (or at least not install LUC while believing it's FMW) 17:22:27 +1 obsolete it 17:22:39 maybe use epoch if necessary to get rid of the renamed LUC as FMW 17:23:04 I talked to mbriza and he considers either obsoleting it, or reverting the graphics overhaul LUC received last cycle 17:23:15 (and also reverting the appstream metadata, hopefully) 17:23:34 after metadata is fixed, we will need to poke hughsie to rebuild them and submit an update 17:26:13 other votes? 17:26:22 hum, i'd be a bit worried about keeping the liveusb-creator package with no obsoletion because then people who already have it installed or just have the package name memorized are never going to get the good tool... 17:26:36 i'm just trying to think whether it really makes sense to block on the obsoletion specifically. 17:26:48 i think maybe we'd be better off with some kind of more general bug as a blocker if anything 17:26:50 adamw: if it gets renamed back to LUC, and we talk about FMW everywhere, then they'll just install FMW from gnome-software, no? 17:27:05 kparal: people showing up fresh and reading the instructions, yeah 17:27:12 hmm 17:27:12 kparal: people who already know liveusb-creator, not necessarily 17:27:27 we can't really dictate that LUC has to get obsoleted 17:27:40 not via this process, nope 17:27:52 it would just feel strange to me if we were to keep it around, i mean, why would we want to have both tools 17:28:21 I think the crux of this blocker bug should be "LUC must not be presented as FMW in gnome-software, because it's misleading" 17:28:44 that's why I said I might have hijacked your report 17:28:53 but it made sense earlier :) 17:29:39 adamw: mbriza said LUC can also do "cp mode" and persistent overlays, which FMW can't 17:29:45 but we all know how well that works 17:30:21 but it was a reason why he was thinking about keeping LUC installable 17:31:27 I think keeping LUC in F25 makes sense, however it must be clear that it is LUC and not FMW 17:31:39 right 17:31:48 kparal: yeah, if no-one's going to support or test that it's an anti-feature. 17:32:05 adamw: the proposed fix worked 17:32:09 dgilmore: great 17:32:12 ok, so let's add our recommendation to obsolete it 17:32:14 can you update the bug? 17:32:21 ok 17:32:39 so, are we inclined to take this as a blocker, or not? I guess I'm -1 on the grounds that adding the obsoletion specifically doesn't really mesh with any critera 17:32:42 and block on "FMW != LUC" 17:32:57 but i could +1 a 'only the real FMW should appear in Software' bug as a blocker at least 17:33:11 yeah, if you want to file and propose it quick we could do it in the meeting, otherwise it can wait for next week 17:33:27 I'll file it right away 17:33:30 +1 on the 'only the real FMW should appear in Software' criteria 17:33:40 if luc doesn't get obsoleted i think at least the package description should grow a 'you probably want FMW instead' disclaimer too 17:34:11 I agree with that. 17:34:36 proposed #agreed 1380859 - RejectedBlocker (Final) - we don't think adding this Obsoletes: specifically would really resolve anything that could be described as a 'criteria violation'. however, we discussed some other cases which may be more suitable and will propose new blockers 17:34:38 adamw: yes, we can propose that, but we should not block on it 17:34:39 +1 on only the real FMW should please stand up 17:34:40 * adamw brb call of nature 17:34:57 +1 17:36:41 ack 17:36:48 * kparal proposed https://bugzilla.redhat.com/show_bug.cgi?id=1381327 17:37:30 we don't even need to formally vote, I can just shift the blocker proposal from this one to the new one 17:37:37 #agreed 1380859 - RejectedBlocker (Final) - we don't think adding this Obsoletes: specifically would really resolve anything that could be described as a 'criteria violation'. however, we discussed some other cases which may be more suitable and will propose new blockers 17:37:56 too late :P 17:37:57 #topic (1379800) systemd does not create new machine-id file if none is present 17:37:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1379800 17:37:57 #info Proposed Blocker, systemd, NEW 17:38:18 adamw: go to 1381327 instead? 17:38:23 we worked around this for arm images, touching the file in the ks 17:38:52 everybody keep the context in your head, we'll get back to LUC :) 17:39:53 pwhalen, Did that fix for ARM get released? 17:40:01 The new kickstart? 17:40:16 kparal: sorry, just working through the list or i'll get confused... 17:40:30 coremodule, thankfully yes, its now included 17:41:11 +1 17:41:23 per comment 13 17:42:05 pwhalen, Gotcha, okay. If we can do the same for Cloud, that'd work. 17:42:49 I'm +1. 17:43:19 yeah, I can +1 this 17:43:46 hmm 17:43:47 actually 17:43:59 this should be a Beta blocker, I think? 17:44:06 Alpha criterion "A system logging infrastructure must be available, enabled by default, and working." 17:44:39 adamw, Good point. That criteria seems to be more this-case specific. 17:44:50 well, 'this case' involves a release blocking image, right? 17:45:05 if the upshot of this is that anyone who deploys the Cloud base image gets no logging, I'm ok with blocking Beta on that 17:45:11 Cloud x86_64 17:45:14 +1 17:45:29 for arm, we strip the file.. it is created, but we want unique machine-id's .. i think systemd should create it, but i dont know if we should block on this, not sure when a fix will be available.. does cloud strip the file? 17:45:31 presumably we can work around it with the 'empty file' trick if systemd can't be fixed immediately, right? 17:45:48 pwhalen: comment #13 says it does. 17:46:02 pwhalen: per the bug, we can make things work by putting the file in the image but having it *empty*. 17:46:11 #c6 17:46:24 In Cloud, the file is non-existent. If you create it and reboot or run systemd-machine-id-setup, then it populates the file with the machine-id. 17:46:58 coremodule: right. so what i'm saying is, we don't necessarily need a systemd fix immediately, we can just have the image include an empty file instead of stripping it entirely. 17:47:12 adamw, Sure, that'd work. 17:48:05 so...votes, again? if +1, state whether for beta or final 17:48:28 +1 for final 17:49:09 +1 final 17:49:10 why Final? 17:49:35 right, if we don't take this for Beta we need a rationale for why not, given that it seems to violate an Alpha criterion. 17:49:54 there is a workaround for it, so IMO we can live with it for Beta 17:50:11 but the workaround needs to be implemented in the compose tool, no? 17:50:31 looks like cloud already has the workaround - http://koji.fedoraproject.org/koji/taskinfo?taskID=15922122 17:50:31 or do you mean "create the file manually" workaround? 17:50:44 kparal: the bugs reads like you can create the file manually and reboot as a workaround. 17:50:47 yes, I mean the manual way 17:50:58 in the ks: touch /etc/machine-id 17:51:13 ok, but that doesn't help the cloud, unless it is really fixed already in it 17:51:14 ah yeah 17:51:22 pbrobinson applied it to all relevant kickstarts, it looks like: https://pagure.io/fedora-kickstarts/c/30c3f7e721709b354d2a98b48d533c359d57bb87?branch=master 17:51:28 nice 17:51:30 Great! 17:51:37 same on f25: https://pagure.io/fedora-kickstarts/c/73645f341ed34239e13c27ce8e7e8702487a6718?branch=f25 17:51:50 so i guess we can say this doesn't need to a be a blocker since we've worked around it in kickstarts? 17:51:56 yes 17:52:03 ok 17:52:11 Yes here. 17:52:40 proposed #agreed 1379800 - RejectedBlocker (Final) - this would be a blocker, but it has been worked around in fedora-kickstarts by ensuring the images contain an empty file, so we do not actually need to block on it so long as that works 17:52:49 ack 17:53:07 ack 17:53:34 ack 17:53:35 ack 17:53:39 #agreed 1379800 - RejectedBlocker (Final) - this would be a blocker, but it has been worked around in fedora-kickstarts by ensuring the images contain an empty file, so we do not actually need to block on it so long as that works 17:54:07 so, to kparal's new proposal 17:54:42 #topic (1381327) LUC is presented as FMW in gnome-software 17:54:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1381327 17:54:54 #info Proposed Blocker, liveusb-creator, NEW 17:55:09 +1 17:55:16 +1 final for me, yeah 17:55:20 +1 17:55:23 i think we can live with the mess for beta but not final 17:55:41 * jkurik has the same pov 17:56:49 proposed #agreed 1381327 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods", as we think we can live with the confusion for Beta but it's not acceptable for Final 17:57:10 ack 17:57:29 ack 17:57:35 ack 17:57:42 ack 17:58:23 ack 17:59:03 #agreed 1381327 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods", as we think we can live with the confusion for Beta but it's not acceptable for Final 17:59:14 okay, I think that's the lot 17:59:26 now we'd better get to lining up ducks to get an RC built tomorrow... 17:59:31 * pwhalen added a new proposal for beta - https://bugzilla.redhat.com/show_bug.cgi?id=1379311 17:59:34 sorry 17:59:42 sigfh 18:00:34 hmm, this looks like +1 :( 18:00:45 * adamw can't parse it. 18:00:52 what exactly is this about? 18:01:00 autopart defaults to 15G root partitions 18:01:09 #topic (1379311) 15Gigs root partition maxSize not customisable in anaconda kickstart script 18:01:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=1379311 18:01:35 #info Proposed Blocker (Beta), anaconda, NEW 18:01:37 okay, and? 18:01:41 that was a choice the ServerWG made 18:02:10 I am -1 blocker as it is the intended server behaviour 18:02:16 oh :/ interesting.. i didnt realize that 18:02:26 so you can't override partitioning in kickstart now? 18:02:48 kparal: that would likely be a anaconda bug 18:02:49 i don't read the bug as saying that 18:02:51 though it's very confusing 18:03:10 it seems to just be saying that you'll get different behaviour with the same kickstart (relying on auto-partitioning) depending on which image you use, which, yes, you will 18:03:16 but that's neither a blocker nor even a bug, i don't think 18:03:17 im sure you can, but autopart just does 15G.. I didnt realize this was intended. hrm, ok.. 18:03:30 "cannot be tweaked in the anaconda-ks.cfg file for another automated installation " - what does that mean? 18:03:39 I think it does 15G if you have at least 15G 18:04:00 kparal: yeah, that's one of the bits i'm having trouble grokking. 18:04:03 if you go auto partitioning you should get the defaults for the product being installed 18:04:10 dgilmore: right 18:04:12 xfs on server ext4 on workstation 18:04:24 sever says / should be only 15G 18:04:27 server 18:04:29 adamw: I think you're right in your interpretation 18:05:00 so basically i'm -1 as far as i understand the bug. :P 18:05:05 I don't understand the failure. Is this a kickstart asking for autopart but then trying to customize it? I wouldn't expect that to work. 18:05:13 if you use autopart you get teh defaults, to me this is not even a bug 18:05:15 * nb thinks he is -1 if he understands it correctly 18:05:21 so unless someone can demonstrate that manual partitioning in kickstart is broken, -1 18:05:28 I did read it in the same way as kparal, however you have convinced me it is not the right way :) 18:05:33 i just didnt expect autopart to give me a 15G root partition, if this was by design.. ok 18:05:50 yeah, it's by design. 18:05:53 so, -1 to block on this 18:05:54 hrm 18:05:55 pwhalen: it will probably surprise some people 18:06:02 i think to most 18:06:07 If you're using a kickstart, I think you need to explicitly ask for what you want, and not use autopart. If you want a different autopart then I think you want to start out with the Everything netinst. 18:06:07 alas 18:06:09 i mean, you can take up the design with server sig, if you like :) but it's not a bug. 18:06:09 pwhalen: where does the rest of the space go? 18:06:31 in the same vg 18:06:35 kparal: It should be in the VG, but unclaimed. 18:06:38 right 18:06:38 ah 18:06:43 cmurf: the complaint in the bug is basically that the reporter wants kickstarts to be entirely deterministic, i think. 18:06:48 "Maybe this option could be made available someway in an anaconda option, that would make the kickstart file self-contained ?" 18:07:03 The idea is to make it possible for the sysadmin to decide what to do with the space rather than decide it at autopart time, when it's too late to use it for some other purpose. 18:07:43 well it's not that hard to shrink an LV, but whatever 18:07:44 Someone might want a big LV for /opt or /data or whatever, someone else might want it used with docker-storage-setup which will autoconfigure that space as LVM thin. 18:07:52 kparal: can't shrink XFS 18:07:53 pwhalen: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/D7ZK7SILYDYAATRFS6BFWZQWS6KSRGDG/#PMU52NQX7XYMJ2HPR6QRKH2ARK5F2YM7 18:08:06 cmurf: well now it makes more sense 18:08:15 interesting file-system 18:08:20 proposed #agreed 1379311 - RejectedBlocker (Beta) - so far as we can determine there is not even a bug here, let alone a blocker. It is just the intended behaviour: if you specify autopart in your kickstart, the exact result will differ between Fedora flavors. 18:08:24 thanks dgilmore 18:08:42 ack 18:08:45 ack 18:08:48 ack 18:08:49 ack 18:08:57 #agreed 1379311 - RejectedBlocker (Beta) - so far as we can determine there is not even a bug here, let alone a blocker. It is just the intended behaviour: if you specify autopart in your kickstart, the exact result will differ between Fedora flavors. 18:09:16 alright, so do we have any other additional proposals or anything? 18:10:07 #topic Open floor 18:10:15 so...we're once again in Beta crunch time, sigh 18:10:39 go/no-go is Thursday, we cannot build an RC until at least tomorrow as sbueno says there will not be an anaconda build till then 18:11:03 in the meantime we need to be knocking out tests with the current validation nightly, and confirming / karma'ing the blocker fixes we do have 18:11:08 i'll try and send out status mail etc. later today 18:11:46 adamw: are you going to be present on the go/no-go ? 18:11:50 yeah. 18:12:58 ok, thanks 18:14:02 any other thoughts, notes, issues etc? 18:14:53 I'm missing one proposed Final blocker. Shouldn't be there 6 + 1 newly created by Kamil? 18:15:21 probably not :) 18:16:22 i think we covered them all 18:16:38 there's only two still showing in blockerbugs' proposed list, both of which we hit 18:19:20 alright, sounds like that's everything 18:19:22 thanks for coming, folks 18:19:24 * adamw sets fuse 18:19:54 Thanks for hosting adamw. 18:20:59 see you at the go/no-go, folks 18:21:01 #endmeeting