17:02:22 #startmeeting F20-blocker-review 17:02:22 Meeting started Mon Dec 2 17:02:22 2013 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:41 #chair adamw tflink 17:02:41 Current chairs: adamw roshi tflink 17:02:43 * pschindl is here 17:02:55 * Viking-Ice fresh cup of coffee 17:02:59 * jreznik is here but cooking rice - has to set an alarm :) 17:03:01 * satellit listening 17:03:04 #meetingname F20-blocker-review-#4 17:03:05 The meeting name has been set to 'f20-blocker-review-#4' 17:03:17 #topic Roll Call 17:03:25 * pschindl is still here :) 17:03:27 lol 17:03:29 * pwhalen is here 17:03:33 * roshi is here, obviously 17:03:33 ahoyhoy 17:04:05 #topic Introduction 17:04:05 Why are we here? 17:04:06 #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. 17:04:06 #info We'll be following the process outlined at: 17:04:06 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:04:06 #info The bugs up for review today are available at: 17:04:06 #link http://qa.fedoraproject.org/blockerbugs/current 17:04:07 #info The criteria for release blocking bugs can be found at: 17:04:07 #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria 17:04:08 #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 17:04:08 #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria 17:04:23 everyone have coffee and whatnot before we get down to it? 17:04:51 * brunowolff is here to answer questions spin-kickstarts and if time ask about whether an auto-filed bug I ran into was already covered. 17:05:24 sounds good brunowolff 17:05:26 thanks 17:05:38 onto proposed blockers! 17:05:47 #topic (1008137) BootLoaderError: bootloader install failed 17:05:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1008137 17:05:47 #info Proposed Blocker, anaconda, NEW 17:07:14 +1 17:07:18 so the bug that clyde reported that seems reproducible has been separated 17:07:23 and proposed as a blocker in its own right 17:07:38 we're left with the one filed by bjorn, who hasn't provided any info 17:07:51 and leslie, who is leslie. 17:07:59 did not kparal reproduce that one 17:08:17 as the one we are discussing 17:08:18 Viking-Ice: he reproduced clyde's 17:08:23 not bjorn's 17:08:46 he pulled a fairly weird error out of the OP's log in c#15 17:08:52 er, that is, bjorn's 17:09:12 this is a confusing bug 17:09:30 yeah mixed bugs usually tend to be that 17:09:32 c15, line a.) 17:09:50 so that works for sure 17:10:05 b.) PVs across 4 disks works 17:10:12 the way i see it we have a 'good bug' which has been split off into 1036705 17:10:17 so that's /boot on LVM 17:10:38 c18 there is no -tb attached though 17:10:42 what we're left with is the original report, comments #1-#12, and the first half of comment #15 17:10:56 cmurf: that is now 1036705, which has been proposed as a blocker separately. ignore it. 17:11:08 (until we get to it in its own right, of course) 17:11:31 i'm -1 or punt on the bjorn part of this one 17:12:03 kparal couldn't reproduce, reporter hasn't responded, there's really no useful detail 17:12:07 * jreznik is now completely lost 17:12:15 * adamw doesn't understand why it's THAT hard to get 17:12:47 bjorn esser hit some kind of bootloader install issue which is somehow related to a missing /usr/lib/grub/i386-pc , but has not provided any info requested or any reproduction method 17:12:56 the fundamental problem is that grub2-install fails for some reason trying to find /usr/lib/grub/i386 17:13:01 so, for sanity sake: this bug 1008137 is not repro'd and the reporter hasn't answered ATM 17:13:16 it was reproduced by kparal in c18 17:13:21 in alpha no less. 17:13:27 clyde kunkel hit what is clearly a *different* bootloader installer issue, did provide useful info and reproduction steps, and that bug has been split off to 1036705, so we can *stop talking about it here* 17:13:38 cmurf: no. it wasn't. clyde's was. they're *not the same bug* 17:13:50 (libreport is bad at bootloader bugs, it's always thinking they're dupes when they aren't) 17:13:54 -1 on this one without more info/current reproducer/etc 17:14:07 so let's nack that one ( Björns ) 17:14:08 -1 17:14:10 -1 17:14:14 -1 as well, more info is needed 17:14:29 you have to go look at the anaconda-tb and find the bootloader install bit 17:14:34 in the clyde / kparal bug, you see: 17:14:36 16:17:05,180 INFO program: Running... grub2-install --no-floppy /dev/sda 17:14:36 16:17:05,719 INFO program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting. 17:14:40 in the bjorn bug, you see: 17:14:42 ok, got it, so -1 17:15:00 06:13:35,358 INFO program: Running... grub2-install --no-floppy /dev/sdb 17:15:01 06:13:35,390 INFO program: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory 17:15:05 clearly not the same. 17:15:20 -1 fine by me, i can add a note to repropose with more details if appropriate 17:15:28 yeah -1 17:15:31 proposed #agreed - 1008137 - RejectedBlocker - Without solid reproduction steps, this isn't considered a blocker. 17:15:45 ack, or patch to add a note that 1036705 is being considered separately? 17:15:52 yeah 17:15:53 ack 17:15:56 ack 17:15:56 ack 17:16:01 ack 17:16:01 ack 17:16:19 I dont think we need a patch with note since we will be dealing with that one seperatly 17:16:21 proposed #agreed - 1008137 - RejectedBlocker - Without solid reproduction steps, this isn't considered a blocker. 1036705 spawned from this bug and is being considered on it's own. 17:16:55 that makes sense Viking-Ice 17:17:02 go with the first? 17:17:32 * roshi goes with the first 17:17:38 #agreed - 1008137 - RejectedBlocker - Without solid reproduction steps, this isn't considered a blocker. 17:17:50 #topic (1008732) LUKSError: luks device not configured 17:17:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732 17:17:50 #info Proposed Blocker, anaconda, NEW 17:18:25 -1 17:18:32 -4 17:18:37 -1 without recent reproducer. ;) 17:18:47 -1, kill it with fire 17:19:09 -1 17:19:27 -1 17:19:28 -1 17:19:41 -1 17:19:44 -1 17:20:20 proposed #agreed - 1008732 - RejectedBlocker - There are no recent reproducers or crash reports associated with this bug and is thusly not considered a blocker. 17:20:31 ack 17:20:32 ack 17:20:36 ack 17:20:40 ack 17:20:41 ack 17:20:42 ack 17:20:44 ack 17:20:45 ack 17:20:48 #agreed - 1008732 - RejectedBlocker - There are no recent reproducers or crash reports associated with this bug and is thusly not considered a blocker. 17:20:59 * roshi is happy to have used the word "thusly" 17:21:04 #topic (1026834) method= combined with kickstart uses invalid repository 17:21:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=1026834 17:21:04 #info Proposed Blocker, anaconda, NEW 17:21:49 .fire roshi but you could just have said 'thus'. 17:21:49 adamw fires roshi but you could just have said 'thus'. 17:22:14 too late - thusly is written in the stone tablets of the interwebz 17:22:47 just like web sms for 70k vodafuck users in Iceland 17:23:51 looking on the last comment by kparal and following his discussion with mkolman I think -1 for now 17:24:25 I'm -1 too 17:24:36 looks like a punt based on his comment 17:24:41 -1 blocker, +1 FE for virt-install to use repo= instead of method= 17:25:01 -1/+1 17:25:17 I say punt until they can confirm/Deny with tc4 as requested 17:26:09 punt votes? 17:26:28 Viking-Ice, how long do you propose we punt for? 17:26:54 until tested with tc4? 17:26:58 yeah 17:27:14 then vote in ticket, or what? 17:27:27 * roshi is thinking of our remaining time before go/nogo 17:27:36 puff 17:27:49 puff? 17:27:53 the journal/systemd/lvm will delay the release 17:28:02 in otherwords we are no go afaikt 17:28:24 that's a bit of a crystal ball. 17:28:29 even thou the lvm is somewhat gray in terms of release the journal is not 17:28:49 i'm ok with punt for tc4 testing, vote in ticket, or a conditional vote 17:28:57 Viking-Ice: sure, but we might fix it. 17:29:06 proposed #agreed - 1026834 - Punt - Putting off a decision until this is reproduced with TC4. Please vote on blocker status in ticket. 17:29:12 ack 17:29:33 ack 17:29:38 ack 17:29:39 adamw, first you have to find the issue I'm pretty sure it will be fixed quickly but systemd is part of core so it needs to be tested extensively 17:30:01 #agreed - 1026834 - Punt - Putting off a decision until this is reproduced with TC4. Please vote on blocker status in ticket. 17:30:20 #topic (1035799) f20 tc3, adding a new mount point, desired capacity empty, crash 17:30:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035799 17:30:20 #info Proposed Blocker, anaconda, POST 17:31:21 +1 17:31:42 +1 17:31:44 +1 17:31:59 +1 17:32:03 this the one i Just hit? +1 17:32:18 +1 17:32:52 proposed #agreed - 1035799 - AcceptedBlocker - This bug violates the Beta criteria: "Reject or disallow invalid disk and volume configurations without crashing." 17:33:09 ack 17:33:24 i'd argue it's more the 'any valid layout' final criterion, this isn't actually an invalid config. but either way. 17:33:39 ack 17:33:56 * roshi just went with what was in the bug 17:33:59 It is a valid config - Anaconda states to leave it blank in order to use the whole disk 17:34:03 * roshi looks up right criteria 17:34:23 ack 17:34:26 ack 17:36:48 ack 17:36:55 proposed #agreed - 1035799 - AcceptedBlocker - This bug violates the Beta criteria: "The installer must be able to create and install to any workable partition layout... " 17:37:00 er 17:37:10 proposed #agreed - 1035799 - AcceptedBlocker - This bug violates the Final criteria: "The installer must be able to create and install to any workable partition layout... " 17:37:26 ack 17:37:36 * jreznik would ack both, so... 17:37:44 ack 17:37:56 there's 3 - moving on 17:38:06 #agreed - 1035799 - AcceptedBlocker - This bug violates the Final criteria: "The installer must be able to create and install to any workable partition layout... " 17:38:28 sorry, catching up with stuff 17:38:30 #topic (1036705) BootLoaderError: bootloader install failed when /boot on LV 17:38:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1036705 17:38:30 #info Proposed Blocker, anaconda, NEW 17:39:21 this is the spawn bug 17:39:41 working on this now 17:40:11 punt and move on while I'm figuring it out but basically it is NOT related to /boot on LV because that works 17:40:16 the issue is related to raid10 17:40:33 i'm not sure yet if the problem is /boot on LV on raid10 or if it's just the raid10 17:41:02 kparal confirmed this one 17:41:19 in the other bug and I dont think that was narrowed down to raid 10 17:41:21 the crash is a blocker in its own right 17:41:39 ok well i just did a single disk install with only LVs including /boot on an LV and it works 17:41:43 so the description is incorrect 17:41:56 so summary should say 'RAID 10' not 'lV' 17:42:03 the problem must be related to raid10 or the combination of raid10 and LV 17:42:23 the thing is, grub2 can find /boot/grub2 on raid10 or on LVM, but I'm not sure if one is embedded in the other if it still can 17:42:41 in any case the crash is a blocker 17:42:43 clyde says it worked as of f18, which is a consideraiton 17:42:49 well then we need a seperated bug for kparals findings since it has nothing to do with raid 10 17:42:55 https://bugzilla.redhat.com/show_bug.cgi?id=1008137#c18 17:42:59 cmurf: on what basis? we don't necessarily maintain that ANY installer crash is a blocker 17:43:17 no wait I'm bullshitting it has everything to do with raid 10 17:43:19 cmurf: anaconda is more or less intentionally designed to crash on bootloader failure, in fact, on the basis that if it doesn't work it's probably best we make it very clear that it didn't 17:43:32 in anycase +1 blocker 17:43:45 umm 17:44:07 there's a criterion that says we can't crash if it's an invalid layout, so it stands to reason we don't crash for a valid layout 17:44:17 right 17:44:31 because if it's a valid layout, installation must complete 17:44:33 i'm not super happy with how that criterion is worded, tbh 17:44:35 but anyhow 17:44:41 +1 17:44:47 (says the guy who wrote it) 17:45:12 it certainly wasn't meant to create the implication that anaconda can't ever crash for any reason, but that's how it seems to be going :| 17:45:26 still, the criterion here's probably same as the last bug, "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. " 17:45:33 well the anaconda team seems pretty much OK with the idea the installer shouldn't crash 17:45:40 certainly seems like whatever's causing this crash is 'offered in a default installer configuration' 17:45:47 so seems like +1 on the face of it 17:45:52 adamw: well that's unclear 17:46:01 cmurf: https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Disk_layouts 17:46:04 Beta criteria: "Reject or disallow invalid disk and volume configurations without crashing." was what I was going to go with for the #agreed 17:46:05 i'm not sure i can create /boot LV on raid in anaconda 17:46:05 cmurf: see "What, what?" subnote 17:46:13 the description sounds like the raid10 already existed 17:46:20 roshi: let's try not to use that wherever possible. it sucks and i don't like. 17:46:22 iut 17:46:24 IT. god. 17:46:31 cmurf: kparal's reproducer doesn't, though. 17:46:34 ok 17:47:03 ok so i'm working on it, if you want to come back to it i'll have more info, if you want to vote on it as a crashing bug go for it 17:47:19 i'd be +1 on the basis of kparal's reproducer: he successfully caused this crash using anaconda to create the layout. 17:47:30 proposed #agreed - 1036705 - AcceptedBlocker - This bug violates the Final criteria: "The installer must be able to create and install to any workable partition layout... " 17:47:35 ack 17:47:40 ack 17:47:43 ack 17:47:47 ack 17:47:52 #agreed - 1036705 - AcceptedBlocker - This bug violates the Final criteria: "The installer must be able to create and install to any workable partition layout... " 17:48:03 #topic (1035533) Fedora 20 final fedora-release and generic-release packages required for GA 17:48:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035533 17:48:03 #info Proposed Blocker, fedora-release, ON_QA 17:48:35 +1, obviously. 17:48:41 +1 17:48:46 +1 17:48:50 +1 17:49:01 +1 17:49:05 +1 17:49:17 +1 17:49:58 proposed #agreed - 1035533 - AcceptedBlocker - This violates the final criteria: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images ..." 17:50:06 ack 17:50:07 ack 17:50:12 ack 17:50:23 ack 17:50:26 #agreed - 1035533 - AcceptedBlocker - This violates the final criteria: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images ..." 17:50:41 #topic (1035531) Fedora 20 final release notes required for GA 17:50:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035531 17:50:41 #info Proposed Blocker, fedora-release-notes, NEW 17:51:12 +1 17:51:13 +1 17:51:16 pretty much the same 17:51:21 +1 17:51:57 yup 17:52:01 just a tracking bug 17:52:04 proposed #agreed - 1035531 - AcceptedBlocker - This violates the final criteria: "The final branded release notes must be present on release-blocking images and the appropriately versioned generic release notes must be available in the release repository..." 17:52:04 +1 17:52:10 ack 17:52:11 ack 17:52:11 ack 17:52:14 +1, in case we will really need it asap I have a deal with docs guys, otherwise they are more aiming on wed 17:52:21 #agreed - 1035531 - AcceptedBlocker - This violates the final criteria: "The final branded release notes must be present on release-blocking images and the appropriately versioned generic release notes must be available in the release repository..." 17:52:36 ack +1 whatever 17:52:53 =) 17:53:03 #topic (1024223) fedup 19->20 failed with DVD iso upgrade 17:53:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1024223 17:53:03 #info Proposed Blocker, fedup, NEW 17:54:25 +1 17:54:55 * adamw checks the upgrade criteria 17:55:10 https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements 17:55:23 so, we don't explicitly state whether all fedup configs are required to work or not 17:55:37 arguably it's 'possible to successfully complete an upgrade' (as the criterion says) so long as one of them works... 17:55:48 yeah 17:56:03 I'm reading it now. And I changed my mind to -1. If at least one way works... 17:56:12 it's a fudge, but... 17:56:28 of course, the other way requires a network. or at least a correctly-configured yum repo. 17:56:29 but it should be +1 FE 17:56:54 -1/+1 17:57:59 +1 17:58:30 votes? 17:58:34 at least +1 FE 17:58:37 +1, I would expect this to work for final 17:58:50 blocker...is a tough call. do we know if it even worked for f18 or f19? i don't recall 17:59:11 (fwiw i can't even figure out in anaconda how to do LVM on md raid) 17:59:55 anyone to try? f19/19? 17:59:57 whether it worked or not in the past would be useful data 18:00:06 not really 18:00:20 I seem to recall updating 17 to 19 with fedup/iso 18:00:25 fedup is new and by now it should work 18:01:47 oh, yeah, it sure ought to work 18:02:04 i'm just thinking this is the kind of thing go/no-go often winds up fudging 18:02:21 the fact is that certain people overstep QA in "supporting" in the first place 18:02:24 i guess we really ought to be +1, though... 18:02:42 * adamw asked wwoods if he's got anywhere with it earlier, but no reply yet 18:02:48 definitely +1FE... but blocker... not sure. I guess I'm +0.5. 18:02:49 the era of FESCo getting away with anything scoot free is over and this should be supported 18:02:53 * satellit anyone tried from dd USB of DVD? 18:03:06 I have satellit 18:03:13 works ? 18:03:20 i guess we can try to hold the line and vote it +1 18:03:28 if go/no-go wants to fudge it, it'll be on their record not ours :P 18:03:33 ;) 18:03:48 I am more +1 blocker 18:03:58 i'll vote +1, trying to have standards over here again 18:04:26 especially for the case of upgrading with no network 18:05:01 yah - running install now 18:05:11 ok, so I'm reading +1 in general for this 18:05:20 which reminds me did someone check how anaconda behaves without network 18:05:42 not for TC3 18:05:52 +1 fe for sure but it's true - it should work for final, so like nirik, count my +0.5 18:06:22 * roshi doesn't see this upgrade requirements criteria 18:06:52 "The installer must be able to use an installer update image retrieved from removable media or a remote package source."? 18:07:14 Viking-Ice: think i did a couple of no-network installs, but i should double-check 18:07:18 roshi: it's beta criterion 18:07:22 will try li-t-d DVD with network install... 18:07:29 satellit: I'm installing with TC3 dd to USB from DVDiso 18:07:36 where though mkrizek? 18:07:39 https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements 18:07:41 we have fedup listed as a recommended upgrade method 18:08:08 roshi: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ", it's a conditional violation of that basically - the case where you try to use fedup iso method (which is documentedo n the fedup page) 18:08:50 pwhalen, yeah "recommended" 18:08:50 ok 18:09:04 so, recommended kinda means it has to work, imo 18:09:36 pwhalen, you do realize that RH slaps that "recommended" for all it's products through the community 18:09:41 its bullshit 18:10:02 proposed #agreed - 1024223 - AcceptedBlocker - This bug conditionally violates the beta criteria: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora..." 18:10:20 pwhalen, the community is still at impass with yum upgrade vs fedup afaik 18:10:35 Viking-Ice, it is what it is, i think its clear as its written now. 18:10:38 ack 18:10:59 ack 18:11:09 ack 18:11:15 pwhalen, I should remove all those recommendation at somepoint 18:11:15 ackl 18:11:17 ack 18:11:18 mean ack 18:11:25 #agreed - 1024223 - AcceptedBlocker - This bug conditionally violates the beta criteria: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora..." 18:11:27 ack 18:11:38 li-td DVD USB x86_64 with no network installing to HD atm 18:11:42 Viking-Ice: i don't think that's reasonable. fedup is the fedora project's recommended upgrade mechanism. i don't see why you have a big problem with that. it's the tool we wrote to do upgrades, it's gone through fesco and all that. 18:11:43 #topic (1035408) [abrt] gnome-shell-3.10.2.1-2.fc20: js_malloc: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV) 18:11:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035408 18:11:43 #info Proposed Blocker, gnome-shell, NEW 18:13:39 so anyone else was able to reproduce it? 18:13:43 when this bug reads "French Install" does that mean systme lang or just keyboard layout? 18:13:52 roshi: language 18:13:57 i couldn't reproduce it on a second try, though 18:14:06 though i used French French the first time and Canadian French the second 18:14:12 still, seems slippery enough to -1 it 18:14:17 -1/+1 FE 18:14:19 -1 18:14:26 -1/+1 FE 18:14:49 FE votes? 18:14:49 -1 / +1 18:14:49 this is one where i'd want more details to be +1 FE...maybe leave FE undetermined and vote on it if we get more concrete stuff? 18:15:04 +1 and decide whether to pull a fix if one shows up isn't too bad, though. 18:15:05 -1 and we can discuss it again in case it would be reproducible again 18:15:11 I was just going to ask what happens when we vote FE and it never gets reproduced 18:16:22 proposed #agreed - 1035408 - RejectedBlocker - Without valid reproduction steps this is not considered a blocker. 18:16:43 adamw, I'm aware of how mysteriously "supporting" upgrade got added to QA as well as the both the tool that got written for it and the pain and delay it caused 18:16:47 ack 18:16:51 maybe add that FE as proposed by adamw - we will take it in case it will be safe fix 18:16:51 ack 18:17:01 Viking-Ice: again, it didn't mysteriously get added. we *always* tested and blocked on upgrades. 18:17:17 patch to include jreznik's suggestion? 18:17:17 ack 18:17:24 we've been around this rodeo before. but no, this was nothing new with fedup. prior to fedup we had the old upgrade mechanism on the matrix and blocked on bugs in it. 18:17:30 adamw, yes it did starting with preupgrade 18:18:03 we did not even have workflows or criteria to deal with supported upgrades when it appeared with us 18:18:26 jreznik, just going to keep it as is. adamw can handle that in secretarializing I think 18:18:32 Viking-Ice: https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria 18:18:41 Viking-Ice: "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria " 18:18:49 we have the acks and should move on methinks - but we'll still look at this as FE when we go over FE's 18:18:51 that work? 18:18:53 i.e., as of F17, we supported *two* upgrade methods. 18:19:00 fedup cut it down to one - it reduced our burden, it didn't increase it. 18:19:01 sure 18:19:06 ack 18:19:18 #agreed - 1035408 - RejectedBlocker - Without valid reproduction steps this is not considered a blocker. 18:19:33 adamw, ? the history of supporting upgrades started with f7/f8/f9 or when ever Jeremy and Will decided to play preupgrade 18:19:37 #topic (1018317) Network Manager can't connect to OpenVPN network in F20 18:19:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=1018317 18:19:37 #info Proposed Blocker, NetworkManager-openvpn, NEW 18:19:49 -1 18:19:51 Viking-Ice: oh, jeez, sorry, we're talking past each other 18:20:05 Viking-Ice: i was reading 'fedup' for 'preupgrade'. yeah, i think the upgrade support came in with preupgrade indeed. 18:20:10 anyhoo 18:20:27 this can be fixed via update 18:20:31 -1 18:20:44 some people require VPN support to have any workable network access 18:20:52 how are they going to get the update if they need to be on a VPN to get updates? 18:20:53 * roshi is on F20 with NetworkManager via OpenVPN 18:21:28 seems like it's limited to poin to point configuration, not sure how common it is 18:21:32 roshi: the difference between working and not working has now been identified, see https://bugzilla.redhat.com/show_bug.cgi?id=1018317#c35 . 18:21:41 right 18:22:03 aha 18:22:05 * adamw counts reporters 18:22:19 +1 FE, sure and support for ptp is always good 18:22:22 we are not going to be adding or otherwise require vpn access and all the ways you can do so 18:22:25 +1 FE 18:22:38 to our release criteria 18:22:56 yep 18:23:06 ( + the entire network handling process is in serious state of flux now with systemd networkd 18:23:08 ) 18:23:09 so -1/+1 18:23:13 -1/+1 FE 18:23:19 -1/+1 FE 18:23:57 -1/+1 18:23:59 i count 15 different reporters 18:24:02 that's a lot of people 18:24:20 proposed #agreed - 1018317 - RejectedBlocker AcceptedFreezeException - This bug doesn't directly violate any criteria and can be fixed with an update. A stable fix will be considered past freeze. 18:24:30 i'm +1 on this, but looks like i'm outvoted. 18:24:31