17:02:22 <roshi> #startmeeting F20-blocker-review
17:02:22 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:41 <roshi> #chair adamw tflink
17:02:41 <zodbot> 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 <roshi> #meetingname F20-blocker-review-#4
17:03:05 <zodbot> The meeting name has been set to 'f20-blocker-review-#4'
17:03:17 <roshi> #topic Roll Call
17:03:25 * pschindl is still here :)
17:03:27 <roshi> lol
17:03:29 * pwhalen is here
17:03:33 * roshi is here, obviously
17:03:33 <adamw> ahoyhoy
17:04:05 <roshi> #topic Introduction
17:04:05 <roshi> Why are we here?
17:04:06 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:04:06 <roshi> #info We'll be following the process outlined at:
17:04:06 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:04:06 <roshi> #info The bugs up for review today are available at:
17:04:06 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
17:04:07 <roshi> #info The criteria for release blocking bugs can be found at:
17:04:07 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
17:04:08 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
17:04:08 <roshi> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
17:04:23 <roshi> 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 <roshi> sounds good brunowolff
17:05:26 <roshi> thanks
17:05:38 <roshi> onto proposed blockers!
17:05:47 <roshi> #topic (1008137) BootLoaderError: bootloader install failed
17:05:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008137
17:05:47 <roshi> #info Proposed Blocker, anaconda, NEW
17:07:14 <Viking-Ice> +1
17:07:18 <adamw> so the bug that clyde reported that seems reproducible has been separated
17:07:23 <adamw> and proposed as a blocker in its own right
17:07:38 <adamw> we're left with the one filed by bjorn, who hasn't provided any info
17:07:51 <adamw> and leslie, who is leslie.
17:07:59 <Viking-Ice> did not kparal reproduce that one
17:08:17 <Viking-Ice> as the one we are discussing
17:08:18 <adamw> Viking-Ice: he reproduced clyde's
17:08:23 <adamw> not bjorn's
17:08:46 <adamw> he pulled a fairly weird error out of the OP's log in c#15
17:08:52 <adamw> er, that is, bjorn's
17:09:12 <cmurf> this is a confusing bug
17:09:30 <Viking-Ice> yeah mixed bugs usually tend to be that
17:09:32 <cmurf> c15, line a.)
17:09:50 <cmurf> so that works for sure
17:10:05 <cmurf> b.) PVs across 4 disks works
17:10:12 <adamw> the way i see it we have a 'good bug' which has been split off into 1036705
17:10:17 <cmurf> so that's /boot on LVM
17:10:38 <cmurf> c18 there is no -tb attached though
17:10:42 <adamw> what we're left with is the original report, comments #1-#12, and the first half of comment #15
17:10:56 <adamw> cmurf: that is now 1036705, which has been proposed as a blocker separately. ignore it.
17:11:08 <adamw> (until we get to it in its own right, of course)
17:11:31 <adamw> i'm -1 or punt on the bjorn part of this one
17:12:03 <adamw> 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 <adamw> 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 <cmurf> the fundamental problem is that grub2-install fails for some reason trying to find /usr/lib/grub/i386
17:13:01 <roshi> so, for sanity sake: this bug 1008137 is not repro'd and the reporter hasn't answered ATM
17:13:16 <cmurf> it was reproduced by kparal in c18
17:13:21 <nirik> in alpha no less.
17:13:27 <adamw> 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 <adamw> cmurf: no. it wasn't. clyde's was. they're *not the same bug*
17:13:50 <adamw> (libreport is bad at bootloader bugs, it's always thinking they're dupes when they aren't)
17:13:54 <nirik> -1 on this one without more info/current reproducer/etc
17:14:07 <Viking-Ice> so let's nack that one ( Björns )
17:14:08 <Viking-Ice> -1
17:14:10 <roshi> -1
17:14:14 <pwhalen> -1 as well, more info is needed
17:14:29 <adamw> you have to go look at the anaconda-tb and find the bootloader install bit
17:14:34 <adamw> in the clyde / kparal bug, you see:
17:14:36 <adamw> 16:17:05,180 INFO program: Running... grub2-install --no-floppy /dev/sda
17:14:36 <adamw> 16:17:05,719 INFO program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
17:14:40 <adamw> in the bjorn bug, you see:
17:14:42 <jreznik> ok, got it, so -1
17:15:00 <adamw> 06:13:35,358 INFO program: Running... grub2-install --no-floppy /dev/sdb
17:15:01 <adamw> 06:13:35,390 INFO program: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory
17:15:05 <adamw> clearly not the same.
17:15:20 <adamw> -1 fine by me, i can add a note to repropose with more details if appropriate
17:15:28 <cmurf> yeah -1
17:15:31 <roshi> proposed #agreed - 1008137 - RejectedBlocker - Without solid reproduction steps, this isn't considered a blocker.
17:15:45 <adamw> ack, or patch to add a note that 1036705 is being considered separately?
17:15:52 <roshi> yeah
17:15:53 <Viking-Ice> ack
17:15:56 <pwhalen> ack
17:15:56 <nirik> ack
17:16:01 <pschindl> ack
17:16:01 <mkrizek> ack
17:16:19 <Viking-Ice> I dont think we need a patch with note since we will be dealing with that one seperatly
17:16:21 <roshi> 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 <roshi> that makes sense Viking-Ice
17:17:02 <roshi> go with the first?
17:17:32 * roshi goes with the first
17:17:38 <roshi> #agreed - 1008137 - RejectedBlocker - Without solid reproduction steps, this isn't considered a blocker.
17:17:50 <roshi> #topic (1008732) LUKSError: luks device not configured
17:17:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732
17:17:50 <roshi> #info Proposed Blocker, anaconda, NEW
17:18:25 <cmurf> -1
17:18:32 <Viking-Ice> -4
17:18:37 <nirik> -1 without recent reproducer. ;)
17:18:47 <jreznik> -1, kill it with fire
17:19:09 <roshi> -1
17:19:27 <adamw> -1
17:19:28 <mkrizek> -1
17:19:41 <pschindl> -1
17:19:44 <pwhalen> -1
17:20:20 <roshi> 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 <jreznik> ack
17:20:32 <mkrizek> ack
17:20:36 <Viking-Ice> ack
17:20:40 <pwhalen> ack
17:20:41 <nirik> ack
17:20:42 <roshi> ack
17:20:44 <adamw> ack
17:20:45 <pschindl> ack
17:20:48 <roshi> #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 <roshi> #topic (1026834) method= combined with kickstart uses invalid repository
17:21:04 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026834
17:21:04 <roshi> #info Proposed Blocker, anaconda, NEW
17:21:49 <adamw> .fire roshi but you could just have said 'thus'.
17:21:49 <zodbot> adamw fires roshi but you could just have said 'thus'.
17:22:14 <roshi> too late - thusly is written in the stone tablets of the interwebz
17:22:47 <Viking-Ice> just like web sms for 70k vodafuck users in Iceland
17:23:51 <jreznik> looking on the last comment by kparal and following his discussion with mkolman I think -1 for now
17:24:25 <pschindl> I'm -1 too
17:24:36 <Viking-Ice> looks like a punt based on his comment
17:24:41 <cmurf> -1 blocker, +1 FE for virt-install to use repo= instead of method=
17:25:01 <roshi> -1/+1
17:25:17 <Viking-Ice> I say punt until they can confirm/Deny with tc4 as requested
17:26:09 <roshi> punt votes?
17:26:28 <roshi> Viking-Ice, how long do you propose we punt for?
17:26:54 <mkrizek> until tested with tc4?
17:26:58 <Viking-Ice> yeah
17:27:14 <roshi> then vote in ticket, or what?
17:27:27 * roshi is thinking of our remaining time before go/nogo
17:27:36 <Viking-Ice> puff
17:27:49 <roshi> puff?
17:27:53 <Viking-Ice> the journal/systemd/lvm will delay the release
17:28:02 <Viking-Ice> in otherwords we are no go afaikt
17:28:24 <adamw> that's a bit of a crystal ball.
17:28:29 <Viking-Ice> even thou the lvm is somewhat gray in terms of release the journal is not
17:28:49 <adamw> i'm ok with punt for tc4 testing, vote in ticket, or a conditional vote
17:28:57 <adamw> Viking-Ice: sure, but we might fix it.
17:29:06 <roshi> proposed #agreed - 1026834 - Punt - Putting off a decision until this is reproduced with TC4. Please vote on blocker status in ticket.
17:29:12 <Viking-Ice> ack
17:29:33 <pschindl> ack
17:29:38 <roshi> ack
17:29:39 <Viking-Ice> 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 <roshi> #agreed - 1026834 - Punt - Putting off a decision until this is reproduced with TC4. Please vote on blocker status in ticket.
17:30:20 <roshi> #topic (1035799) f20 tc3, adding a new mount point, desired capacity empty, crash
17:30:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035799
17:30:20 <roshi> #info Proposed Blocker, anaconda, POST
17:31:21 <Viking-Ice> +1
17:31:42 <cmurf> +1
17:31:44 <mkrizek> +1
17:31:59 <roshi> +1
17:32:03 <adamw> this the one i Just hit? +1
17:32:18 <pwhalen> +1
17:32:52 <roshi> proposed #agreed - 1035799 - AcceptedBlocker - This bug violates the Beta criteria: "Reject or disallow invalid disk and volume configurations without crashing."
17:33:09 <Viking-Ice> ack
17:33:24 <adamw> 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 <pschindl> ack
17:33:56 * roshi just went with what was in the bug
17:33:59 <danofsatx> 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 <pwhalen> ack
17:34:26 <mkrizek> ack
17:36:48 <jreznik> ack
17:36:55 <roshi> 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 <roshi> er
17:37:10 <roshi> 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 <pschindl> ack
17:37:36 * jreznik would ack both, so...
17:37:44 <roshi> ack
17:37:56 <roshi> there's 3 - moving on
17:38:06 <roshi> #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 <adamw> sorry, catching up with stuff
17:38:30 <roshi> #topic (1036705) BootLoaderError: bootloader install failed when /boot on LV
17:38:30 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1036705
17:38:30 <roshi> #info Proposed Blocker, anaconda, NEW
17:39:21 <roshi> this is the spawn bug
17:39:41 <cmurf> working on this now
17:40:11 <cmurf> 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 <cmurf> the issue is related to raid10
17:40:33 <cmurf> i'm not sure yet if the problem is /boot on LV on raid10 or if it's just the raid10
17:41:02 <Viking-Ice> kparal confirmed this one
17:41:19 <Viking-Ice> in the other bug and I dont think that was narrowed down to raid 10
17:41:21 <cmurf> the crash is a blocker in its own right
17:41:39 <cmurf> ok well i just did a single disk install with only LVs including /boot on an LV and it works
17:41:43 <cmurf> so the description is incorrect
17:41:56 <adamw> so summary should say 'RAID 10' not 'lV'
17:42:03 <cmurf> the problem must be related to raid10 or the combination of raid10 and LV
17:42:23 <cmurf> 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 <cmurf> in any case the crash is a blocker
17:42:43 <adamw> clyde says it worked as of f18, which is a consideraiton
17:42:49 <Viking-Ice> well then we need a seperated bug for kparals findings since it has nothing to do with raid 10
17:42:55 <Viking-Ice> https://bugzilla.redhat.com/show_bug.cgi?id=1008137#c18
17:42:59 <adamw> cmurf: on what basis? we don't necessarily maintain that ANY installer crash is a blocker
17:43:17 <Viking-Ice> no wait I'm bullshitting it has everything to do with raid 10
17:43:19 <adamw> 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 <Viking-Ice> in anycase +1 blocker
17:43:45 <cmurf> umm
17:44:07 <cmurf> 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 <Viking-Ice> right
17:44:31 <cmurf> because if it's a valid layout, installation must complete
17:44:33 <adamw> i'm not super happy with how that criterion is worded, tbh
17:44:35 <adamw> but anyhow
17:44:41 <roshi> +1
17:44:47 <adamw> (says the guy who wrote it)
17:45:12 <adamw> 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 <adamw> 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 <cmurf> well the anaconda team seems pretty much OK with the idea the installer shouldn't crash
17:45:40 <adamw> certainly seems like whatever's causing this crash is 'offered in a default installer configuration'
17:45:47 <adamw> so seems like +1 on the face of it
17:45:52 <cmurf> adamw: well that's unclear
17:46:01 <adamw> cmurf: https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Disk_layouts
17:46:04 <roshi> 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 <cmurf> i'm not sure i can create /boot LV on raid in anaconda
17:46:05 <adamw> cmurf: see "What, what?" subnote
17:46:13 <cmurf> the description sounds like the raid10 already existed
17:46:20 <adamw> roshi: let's try not to use that wherever possible. it sucks and i don't like.
17:46:22 <adamw> iut
17:46:24 <adamw> IT. god.
17:46:31 <adamw> cmurf: kparal's reproducer doesn't, though.
17:46:34 <roshi> ok
17:47:03 <cmurf> 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 <adamw> 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 <roshi> 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 <adamw> ack
17:47:40 <pschindl> ack
17:47:43 <mkrizek> ack
17:47:47 <Viking-Ice> ack
17:47:52 <roshi> #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 <roshi> #topic (1035533) Fedora 20 final fedora-release and generic-release packages required for GA
17:48:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035533
17:48:03 <roshi> #info Proposed Blocker, fedora-release, ON_QA
17:48:35 <adamw> +1, obviously.
17:48:41 <mkrizek> +1
17:48:46 <roshi> +1
17:48:50 <pschindl> +1
17:49:01 <pwhalen> +1
17:49:05 <jreznik> +1
17:49:17 <Viking-Ice> +1
17:49:58 <roshi> 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 <pschindl> ack
17:50:07 <mkrizek> ack
17:50:12 <pwhalen> ack
17:50:23 <jreznik> ack
17:50:26 <roshi> #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 <roshi> #topic (1035531) Fedora 20 final release notes required for GA
17:50:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035531
17:50:41 <roshi> #info Proposed Blocker, fedora-release-notes, NEW
17:51:12 <roshi> +1
17:51:13 <mkrizek> +1
17:51:16 <roshi> pretty much the same
17:51:21 <pschindl> +1
17:51:57 <adamw> yup
17:52:01 <adamw> just a tracking bug
17:52:04 <roshi> 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 <pwhalen> +1
17:52:10 <pschindl> ack
17:52:11 <pwhalen> ack
17:52:11 <mkrizek> ack
17:52:14 <jreznik> +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 <roshi> #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 <Viking-Ice> ack +1 whatever
17:52:53 <adamw> =)
17:53:03 <roshi> #topic (1024223) fedup 19->20 failed with DVD iso upgrade
17:53:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1024223
17:53:03 <roshi> #info Proposed Blocker, fedup, NEW
17:54:25 <pschindl> +1
17:54:55 * adamw checks the upgrade criteria
17:55:10 <adamw> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements
17:55:23 <adamw> so, we don't explicitly state whether all fedup configs are required to work or not
17:55:37 <adamw> arguably it's 'possible to successfully complete an upgrade' (as the criterion says) so long as one of them works...
17:55:48 <roshi> yeah
17:56:03 <pschindl> I'm reading it now. And I changed my mind to -1. If at least one way works...
17:56:12 <adamw> it's a fudge, but...
17:56:28 <adamw> of course, the other way requires a network. or at least a correctly-configured yum repo.
17:56:29 <pschindl> but it should be +1 FE
17:56:54 <roshi> -1/+1
17:57:59 <Viking-Ice> +1
17:58:30 <roshi> votes?
17:58:34 <adamw> at least +1 FE
17:58:37 <pwhalen> +1, I would expect this to work for final
17:58:50 <adamw> blocker...is a tough call. do we know if it even worked for f18 or f19? i don't recall
17:59:11 <cmurf> (fwiw i can't even figure out in anaconda how to do LVM on md raid)
17:59:55 <jreznik> anyone to try? f19/19?
17:59:57 <pwhalen> whether it worked or not in the past would be useful data
18:00:06 <Viking-Ice> not really
18:00:20 <danofsatx> I seem to recall updating 17 to 19 with fedup/iso
18:00:25 <Viking-Ice> fedup is new and by now it should work
18:01:47 <adamw> oh, yeah, it sure ought to work
18:02:04 <adamw> i'm just thinking this is the kind of thing go/no-go often winds up fudging
18:02:21 <Viking-Ice> the fact is that certain people overstep QA in "supporting" in the first place
18:02:24 <adamw> 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 <nirik> definitely +1FE... but blocker... not sure. I guess I'm +0.5.
18:02:49 <Viking-Ice> 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 <roshi> I have satellit
18:03:13 <satellit> works ?
18:03:20 <adamw> i guess we can try to hold the line and vote it +1
18:03:28 <adamw> if go/no-go wants to fudge it, it'll be on their record not ours :P
18:03:33 <Viking-Ice> ;)
18:03:48 <mkrizek> I am more +1 blocker
18:03:58 <adamw> i'll vote +1, trying to have standards over here again
18:04:26 <adamw> especially for the case of upgrading with no network
18:05:01 <roshi> yah - running install now
18:05:11 <roshi> ok, so I'm reading +1 in general for this
18:05:20 <Viking-Ice> which reminds me did someone check how anaconda behaves without network
18:05:42 <satellit> not for TC3
18:05:52 <jreznik> +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 <roshi> "The installer must be able to use an installer update image retrieved from removable media or a remote package source."?
18:07:14 <adamw> Viking-Ice: think i did a couple of no-network installs, but i should double-check
18:07:18 <mkrizek> roshi: it's beta criterion
18:07:22 <satellit_f20> will try li-t-d DVD with network install...
18:07:29 <roshi> satellit: I'm installing with TC3 dd to USB from DVDiso
18:07:36 <roshi> where though mkrizek?
18:07:39 <mkrizek> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements
18:07:41 <pwhalen> we have fedup listed as a recommended upgrade method
18:08:08 <adamw> 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 <Viking-Ice> pwhalen, yeah "recommended" <sigh>
18:08:50 <roshi> ok
18:09:04 <pwhalen> so, recommended kinda means it has to work, imo
18:09:36 <Viking-Ice> pwhalen, you do realize that RH slaps that "recommended" for all it's products through the community
18:09:41 <Viking-Ice> its bullshit
18:10:02 <roshi> 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 <Viking-Ice> pwhalen, the community is still at impass with yum upgrade vs fedup afaik
18:10:35 <pwhalen> Viking-Ice, it is what it is, i think its clear as its written now.
18:10:38 <pwhalen> ack
18:10:59 <mkrizek> ack
18:11:09 <adamw> ack
18:11:15 <Viking-Ice> pwhalen, I should remove all those recommendation at somepoint
18:11:15 <Viking-Ice> ackl
18:11:17 <pschindl> ack
18:11:18 <Viking-Ice> mean ack
18:11:25 <roshi> #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 <jreznik> ack
18:11:38 <satellit> li-td DVD USB x86_64 with no network installing to HD atm
18:11:42 <adamw> 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 <roshi> #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 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035408
18:11:43 <roshi> #info Proposed Blocker, gnome-shell, NEW
18:13:39 <jreznik> so anyone else was able to reproduce it?
18:13:43 <roshi> when this bug reads "French Install" does that mean systme lang or just keyboard layout?
18:13:52 <adamw> roshi: language
18:13:57 <adamw> i couldn't reproduce it on a second try, though
18:14:06 <adamw> though i used French French the first time and Canadian French the second
18:14:12 <adamw> still, seems slippery enough to -1 it
18:14:17 <Viking-Ice> -1/+1 FE
18:14:19 <roshi> -1
18:14:26 <pwhalen> -1/+1 FE
18:14:49 <roshi> FE votes?
18:14:49 <mkrizek> -1 / +1
18:14:49 <adamw> 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 <adamw> +1 and decide whether to pull a fix if one shows up isn't too bad, though.
18:15:05 <jreznik> -1 and we can discuss it again in case it would be reproducible again
18:15:11 <roshi> I was just going to ask what happens when we vote FE and it never gets reproduced
18:16:22 <roshi> proposed #agreed - 1035408 - RejectedBlocker - Without valid reproduction steps this is not considered a blocker.
18:16:43 <Viking-Ice> 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 <Viking-Ice> ack
18:16:51 <jreznik> maybe add that FE as proposed by adamw - we will take it in case it will be safe fix
18:16:51 <pschindl> ack
18:17:01 <adamw> Viking-Ice: again, it didn't mysteriously get added. we *always* tested and blocked on upgrades.
18:17:17 <roshi> patch to include jreznik's suggestion?
18:17:17 <pwhalen> ack
18:17:24 <adamw> 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 <Viking-Ice> adamw, yes it did starting with preupgrade
18:18:03 <Viking-Ice> we did not even have workflows or criteria to deal with supported upgrades when it appeared with us
18:18:26 <roshi> jreznik, just going to keep it as is. adamw can handle that in secretarializing I think
18:18:32 <adamw> Viking-Ice: https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
18:18:41 <adamw> 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 <roshi> 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 <roshi> that work?
18:18:53 <adamw> i.e., as of F17, we supported *two* upgrade methods.
18:19:00 <adamw> fedup cut it down to one - it reduced our burden, it didn't increase it.
18:19:01 <adamw> sure
18:19:06 <adamw> ack
18:19:18 <roshi> #agreed - 1035408 - RejectedBlocker - Without valid reproduction steps this is not considered a blocker.
18:19:33 <Viking-Ice> adamw, ? the history of supporting upgrades started with f7/f8/f9 or when ever Jeremy and Will decided to play preupgrade
18:19:37 <roshi> #topic (1018317) Network Manager can't connect to OpenVPN network in F20
18:19:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1018317
18:19:37 <roshi> #info Proposed Blocker, NetworkManager-openvpn, NEW
18:19:49 <Viking-Ice> -1
18:19:51 <adamw> Viking-Ice: oh, jeez, sorry, we're talking past each other
18:20:05 <adamw> Viking-Ice: i was reading 'fedup' for 'preupgrade'. yeah, i think the upgrade support came in with preupgrade indeed.
18:20:10 <adamw> anyhoo
18:20:27 <Viking-Ice> this can be fixed via update
18:20:31 <roshi> -1
18:20:44 <adamw> some people require VPN support to have any workable network access
18:20:52 <adamw> 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 <jreznik> seems like it's limited to poin to point configuration, not sure how common it is
18:21:32 <adamw> 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 <adamw> right
18:22:03 <roshi> aha
18:22:05 * adamw counts reporters
18:22:19 <jreznik> +1 FE, sure and support for ptp is always good
18:22:22 <Viking-Ice> we are not going to be adding or otherwise require vpn access and all the ways you can do so
18:22:25 <Viking-Ice> +1 FE
18:22:38 <Viking-Ice> to our release criteria
18:22:56 <jreznik> yep
18:23:06 <Viking-Ice> ( + the entire network handling process is in serious state of flux now with systemd networkd
18:23:08 <Viking-Ice> )
18:23:09 <jreznik> so -1/+1
18:23:13 <pwhalen> -1/+1 FE
18:23:19 <roshi> -1/+1 FE
18:23:57 <pschindl> -1/+1
18:23:59 <adamw> i count 15 different reporters
18:24:02 <adamw> that's a lot of people
18:24:20 <roshi> 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 <adamw> i'm +1 on this, but looks like i'm outvoted.
18:24:31 <adamw> so ack
18:24:43 <adamw> and i guess it'll get fixed anyhow
18:24:53 <jreznik> ack
18:25:13 <pwhalen> ack
18:25:29 <roshi> #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:25:45 <roshi> oh, a bit late now - but do we have a volunteer for secretary duty?
18:25:54 <roshi> .fire roshi for forgetting
18:25:54 <zodbot> adamw fires roshi for forgetting
18:26:24 <roshi> last proposed blocker on my list
18:26:25 <roshi> #topic (1035536) Final spin-kickstarts build required for Fedora 20 GA
18:26:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035536
18:26:25 <roshi> #info Proposed Blocker, spin-kickstarts, NEW
18:26:35 <adamw> roshi: i've been doing secretary stuff
18:26:44 <roshi> cool
18:27:17 <jreznik> +1
18:27:27 <roshi> +1
18:27:35 <nirik> +1, we have a build already I think
18:27:37 <pschindl> +1
18:27:38 <pwhalen> +1
18:27:41 <jreznik> nirik: yep
18:28:04 <brunowolff> The build is still current I believe. I checked yesterday.
18:28:11 <roshi> proposed #agreed - 1035536 - AcceptedBlocker - This violates the final criteria: "A spin-kickstarts package which contains the exact kickstart files used to build the release must be present in the release repository."
18:28:23 <pschindl> ack
18:28:23 <nirik> brunowolff: yeah, it is.
18:28:28 <jreznik> thanks brunowolff
18:28:30 <jreznik> ack
18:28:35 <nirik> ack
18:28:37 <roshi> #agreed - 1035536 - AcceptedBlocker - This violates the final criteria: "A spin-kickstarts package which contains the exact kickstart files used to build the release must be present in the release repository."
18:28:40 <brunowolff> Be sure to read the new instructions for rebuilding if you need to do a rebuild, since it's changed from last time/
18:28:48 <roshi> any other blockers we didn't go over?
18:28:56 <adamw> we still ahven't solved the desktop size bug, so we may still need to poke kickstarts
18:29:00 * pschindl has to go. Bye
18:29:01 <adamw> i'll try and get with mclasen on that today
18:29:03 <adamw> cya pschindl!
18:29:17 <brunowolff> I had a question about bug 1036247
18:29:28 <roshi> #action adamw to ping mclasen regarding desktop size bug
18:29:32 <jreznik> roshi: for FEs, could we start with sec ones? sharkcz is waiting for them (erland, qt5*)
18:29:43 <brunowolff> I figured it already was reported, as it was filed semi-automatically.
18:30:30 <Viking-Ice> I'm splitting since I must do $otherstuff for the evening later...
18:30:35 <roshi> sure, jreznik, got a preference on which one?
18:31:11 <jreznik> erlang is even now first on the list :)
18:31:15 <roshi> true
18:31:17 <adamw> brunowolff: not sure what you mean?
18:31:21 <adamw> cya viking
18:31:22 <roshi> onto proposed FE's!
18:31:23 <adamw> doh
18:31:32 <nirik> .bug 1036247
18:31:37 <zodbot> nirik: Bug 1036247 GError: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Update" with signature "a{sa{sv}}" on interface "org.freedesktop.NetworkManager.Settings.Connection" doesn't exist - https://bugzilla.redhat.com/show_bug.cgi?id=1036247
18:31:41 <roshi> oh wait, sorry brunowolff
18:32:02 <brunowolff> I was wondering if there were already similar bugs filed by other people, so that it was really just a dup.
18:32:18 * nirik hasn't seen that personally. would expect others would have if it was common
18:32:29 <brunowolff> If it is new, it seems like an FE bug, since it happened on a non-blocking desktop.
18:32:38 <adamw> brunowolff: libreport would usually catch if it's a dupe and add a comment to the original bug, rather than filing a new one.
18:33:23 <brunowolff> I can see if it happens again with TC4/RC1. And ask for a review if it does.
18:34:13 <adamw> brunowolff: googling '"unknownmethod" org.freedesktop.NetworkManager.Settings.Connection site:bugzilla.redhat.com' doesn't produce any obvious other reports.
18:34:17 <brunowolff> It didn't actually break the install as far as I can tell. But it is a scary message.
18:34:34 <adamw> so, i'd say yours is the first report.
18:34:38 <adamw> propose it if you think it merits it
18:34:40 <roshi> #action brunowolff to reproduce bug 1036247 on TC4
18:34:46 <adamw> brb, call of nature
18:34:59 <brunowolff> I will if it happens again.
18:36:28 * satellit FYI Li-td USB DVD TC3 x86_64 with no network installed to HD
18:37:20 <roshi> onto FE's
18:37:26 <roshi> #topic (1023960) erlang-R16B-02.2.fc20 fails to build on secondary arches
18:37:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023960
18:37:26 <roshi> #info Proposed Freeze Exceptions, erlang, ON_QA
18:38:34 <jreznik> it's for sec arches +1
18:38:55 <nirik> sure, +1 FE
18:38:56 <sharkcz> it's just a rebuild for primary arches, no other change
18:39:05 <roshi> +1
18:40:08 <adamw> not likely to break anything important, sure +1
18:40:26 <roshi> proposed #agreed - 1023960 - AcceptedFreezeException - A fix will be considered past freeze.
18:41:32 <roshi> ack/nack/patch?
18:41:41 <jreznik> ack
18:41:54 * roshi acks implicitly
18:41:56 <nirik> ack
18:42:05 <roshi> #agreed - 1023960 - AcceptedFreezeException - A fix will be considered past freeze.
18:42:28 <roshi> #topic (1033156) qt5-qtdeclarative ppc bootstrap build does not build on power.
18:42:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1033156
18:42:29 <roshi> #info Proposed Freeze Exceptions, qt5-qtdeclarative, ON_QA
18:42:41 * roshi is going to get all mixed up taking these out of order :P
18:42:53 <sharkcz> there is one update in bodhi carrying both the qt5-* bugs
18:43:14 <sharkcz> same situation as with erlang, just a rebuilt for primary
18:43:16 <nirik> +1
18:43:23 <adamw> +1 for both, same as erlang.
18:43:33 <jreznik> +1, nothing important uses qt5 now
18:43:35 <roshi> +1
18:43:42 <jreznik> unless we want to block on hawaii desktop :)
18:43:50 <roshi> proposed #agreed - 103 - AcceptedFreezeException - A fix will be considered past freeze.
18:43:55 <roshi> meh
18:44:07 <roshi> proposed #agreed - 1033156 - AcceptedFreezeException - A fix will be considered past freeze.
18:44:13 <nirik> ack
18:44:27 <adamw> http://bugzilla.redhat.com/show_bug.cgi?id=103 "rpm-2.5.3-5.1 dumps core when I try to upgrade certain packages"
18:44:31 <adamw> sure sounds like a blocker!
18:44:58 <adamw> :P
18:45:01 <adamw> ack
18:45:05 <jreznik> ack
18:45:11 <roshi> #agreed - 1033156 - AcceptedFreezeException - A fix will be considered past freeze.
18:45:15 <sharkcz> thanks guys :-)
18:45:20 <roshi> np sharkcz
18:45:46 <adamw> "The problem is resolved in RH5.2" - history does not record what unfortunate people trying to use 5.1 were supposed to do.
18:45:51 <adamw> sounds like we've been fudging it for decades!
18:45:59 <roshi> #topic (1034940) qt5-qtwebkit 5.2.0-beta1 FTBFS on secondary arches
18:45:59 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1034940
18:45:59 <roshi> #info Proposed Freeze Exceptions, qt5-qtwebkit, ON_QA
18:46:08 <jreznik> +1 again
18:46:17 <roshi> yeah
18:46:20 <adamw> ditto
18:46:24 <roshi> +1
18:46:38 <roshi> proposed #agreed - 1034940 - AcceptedFreezeException - A fix will be considered past freeze.
18:46:44 <pwhalen> +1
18:46:50 <jreznik> ack
18:46:51 <pwhalen> ack
18:47:02 <roshi> #agreed - 1034940 - AcceptedFreezeException - A fix will be considered past freeze.
18:47:38 <roshi> #topic (1027507) [abrt] gnome-initial-setup-3.10.1.1-2.fc20: magazine_chain_pop_head: Process /usr/libexec/gnome-initial-setup was killed by signal 11 (SIGSEGV)
18:47:38 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027507
18:47:38 <roshi> #info Proposed Freeze Exceptions, gnome-initial-setup, ON_QA
18:48:51 <roshi> +1, looks like it's supposed to be fixed
18:49:42 <nirik> sure, +1
18:49:43 <pwhalen> +1
18:50:27 <pwhalen> did anyone else test, and able to add karma?
18:50:39 <roshi> proposed #agreed - 1027507 - AcceptedFreezeException - A fix will be considered past freeze.
18:50:43 * roshi hasn't
18:51:10 <pwhalen> ack
18:51:22 <roshi> ack
18:51:44 <pwhalen> did we lose everyone? should be a recess during these epic meetings
18:51:50 <roshi> lol
18:51:55 <roshi> was just wondering that
18:51:58 <nirik> ack
18:51:59 <roshi> adamw ?jreznik ?
18:52:35 * roshi keeps thinking there's FESco going on - because this meeting happens on Wednesdays
18:52:45 <jreznik> ack
18:52:46 <adamw> sorry, dividing my focus
18:52:49 <adamw> not fesco for me
18:52:52 <adamw> ack
18:52:52 <roshi> we have enough acks to move forward anyways
18:53:06 <roshi> #agreed - 1027507 - AcceptedFreezeException - A fix will be considered past freeze.
18:53:14 <roshi> #topic (1034790) Unable to start mariadb.
18:53:15 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1034790
18:53:15 <roshi> #info Proposed Freeze Exceptions, mariadb, MODIFIED
18:53:31 <nirik> +1
18:53:35 <pwhalen> +1
18:53:49 <adamw> -1
18:53:54 <adamw> the broken build never went stable.
18:54:03 <adamw> there is no need to push anything newer through the freeze. the build in stable does not have the bug.
18:54:09 * nirik reads the last bits
18:54:09 <roshi> ah
18:54:16 <roshi> -1 then
18:54:23 <nirik> so, it's only all the saps that installed before release. ok.
18:54:51 <pwhalen> -1 as well
18:54:55 <nirik> ok then... -1
18:55:22 <roshi> proposed #agreed - 1034790 - RejectedFreezeException - The listed build never got pushed to stable, so there's nothing to push past freeze.
18:55:29 <pwhalen> ack
18:55:35 <jreznik> ack
18:55:52 <roshi> ack
18:56:09 <nirik> ack
18:56:11 <roshi> #agreed - 1034790 - RejectedFreezeException - The listed build never got pushed to stable, so there's nothing to push past freeze.
18:56:20 <adamw> ack
18:56:24 <roshi> #topic (1031696) libvirt: machines get killed when scopes are destroyed
18:56:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1031696
18:56:24 <roshi> #info Proposed Freeze Exceptions, systemd, NEW
18:57:06 <nirik> no movement in the bug really
18:57:34 <nirik> -1 then from me.
18:57:48 <jreznik> yep, -1
18:58:17 <roshi> -1
18:58:48 * adamw reads
18:59:06 <adamw> yeah, looks like -1 for safety at this point
18:59:07 <pwhalen> -1
18:59:28 <adamw> definitely should document it, though
18:59:32 * adamw adds CommonBugs
18:59:43 <adamw> and perhaps we could take a fix if we slip, i'll note that
18:59:44 <nirik> perhaps they can fix it in a 0 day. ;)
18:59:59 <roshi> proposed #agreed - 1031696 - RejectedFreezeException - There is no tested fix for this and one won't be considered past freeze.
19:00:02 <adamw> ack
19:00:06 <pwhalen> ack
19:00:25 <roshi> ack
19:00:27 <jreznik> ack
19:00:31 <roshi> #agreed - 1031696 - RejectedFreezeException - There is no tested fix for this and one won't be considered past freeze.
19:00:47 <roshi> #topic (1035764) Crashes with certain Google Drive documents
19:00:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035764
19:00:47 <roshi> #info Proposed Freeze Exceptions, webkitgtk3, MODIFIED
19:01:27 <adamw> +1 per my comment, the fix is tested
19:01:28 <roshi> +1
19:01:29 <pwhalen> +1
19:01:43 <jreznik> ok, +1
19:02:11 <roshi> proposed #agreed - 1035764 - AcceptedFreezeException - A fix will be considered past freeze.
19:02:13 <adamw> ack
19:02:26 <pwhalen> ack
19:02:27 <roshi> ack
19:02:30 <roshi> #agreed - 1035764 - AcceptedFreezeException - A fix will be considered past freeze.
19:02:34 <roshi> that's all the FE's
19:02:45 <adamw> yay
19:02:46 <pwhalen> \o/
19:02:48 <adamw> acceptedblockers?
19:03:00 <adamw> I HAVEN'T HAD ENOUGH FUN YET
19:03:12 <roshi> I propose a 15 min break and then come back to do accepted blockers
19:03:22 <roshi> so, resume at 1920 UTC
19:03:40 <pwhalen> +1
19:03:41 <adamw> sure, if weaklings need to take a break
19:03:43 <adamw> :P
19:03:45 <pwhalen> :)
19:04:00 <jreznik> we covered pretty much on the qa meeting
19:04:06 <roshi> ok, 1920 UTC then
19:04:19 * jreznik will try to be still online, but not sure
19:06:00 <cmurf> .bug 1036705
19:06:04 <zodbot> cmurf: Bug 1036705 BootLoaderError: bootloader install failed when /boot on RAID 10(?) - https://bugzilla.redhat.com/show_bug.cgi?id=1036705
19:06:05 <cmurf> I can't reproduce this
19:06:59 <cmurf> doesn't matter if /boot is on LV, raid10 or LV+raid10 it works for me.
19:08:14 <adamw> hum, wonder what you and kparal did different?
19:08:41 <cmurf> his program.log is included in the -tb and they are essentially identical except his PV and my PV have different names
19:08:49 <cmurf> his is /dev/md/00 and mine is /dev/md/pv00
19:09:07 <cmurf> his is 10GB mine is 80GB
19:09:38 <cmurf> the /mnt/sysimage mounting of its various parts is all identical and in identical order
19:09:57 <cmurf> hence why i asked to see grub-install --debug
19:19:49 <roshi> ready?
19:19:50 * pwhalen is ready again
19:21:25 <adamw> i was born ready!
19:21:27 <roshi> anybody else?
19:21:29 <roshi> there he is
19:21:31 <roshi> #topic (1020974) incorrectly treats a disk with partially corrupt GPT as having no partition at all
19:21:31 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020974
19:21:31 <roshi> #info Accepted Blocker, anaconda, ASSIGNED
19:21:39 * jreznik is still ready even he really should quit :)
19:22:40 <jreznik> so this one needs bcl
19:23:16 <adamw> i know they're aware of all blocker bugs and working them
19:23:24 <adamw> just a question of whether we can get them all done in time or not :/
19:23:47 <cmurf> i thought a fix for this was already in place
19:24:13 <cmurf> maybe it was an unincorporated updates.img
19:24:37 * adamw doesn't recall seeing one
19:24:51 <cmurf> yeah c8
19:25:05 <adamw> oh, there was one, it didn't work
19:25:07 <cmurf> oh that blew up
19:25:21 <cmurf> well i don't know if it didn't work but it caused another problem
19:25:58 <cmurf> next bug i guess
19:26:06 <roshi> yeah
19:26:15 <roshi> #topic (1027947) Cannot change a partition's size, then return it to the original size
19:26:15 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027947
19:26:15 <roshi> #info Accepted Blocker, anaconda, ASSIGNED
19:28:14 <roshi> no change really
19:28:18 <roshi> next bug?
19:28:27 <jreznik> well, at least no more crash
19:29:53 <adamw> no change since the last time we looked at it. yeah, for anaconda, nothing much to do besides cross digits
19:30:03 <roshi> moving on
19:30:07 <roshi> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs
19:30:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
19:30:07 <roshi> #info Accepted Blocker, grubby, ASSIGNED
19:31:47 <adamw> so we discussed that one in the QA meeting
19:32:24 <adamw> for the benefit of posterity: pjones was not aware that the installer allowed you to make /boot a btrfs subvol , he considers it an unsupported configuration, and the likely upshot is we'll patch anaconda not to allow it any more.
19:32:47 <cmurf> this logic is really annoying
19:33:18 <cmurf> the year old description makes it clear the installer allows it
19:33:40 <cmurf> it's been allowed since F18
19:33:46 <cmurf> (at least)
19:34:09 <cmurf> it's just ridiculous but whatever, i'd move on
19:34:34 * roshi was just reading through comments
19:34:36 <adamw> cmurf: the description doesn't say that, it was buried in a comment...
19:34:40 <roshi> moving on
19:34:50 <adamw> cmurf: in the description you explicitly describe doing it outside of anaconda
19:35:06 <adamw> "2. Create a boot subvol on the existing btrfs volume.
19:35:07 <adamw> 3. cp -a contents of ext4 boot to the btrfs boot subvol.
19:35:07 <adamw> 4. Update fstab, update grub.cfg with grub2-mkconfig; on one attempt I had to relabel with restorecon."
19:36:18 <roshi> ...
19:36:25 <roshi> still want to move on?
19:36:50 <adamw> sure
19:36:52 <cmurf> yes it doesn't matter the clock has been run out on fixing the bug so it can't be fixed for f20
19:36:57 <adamw> just scoring points over here ;)
19:37:07 <roshi> #topic (1035462) initial-setup-text only displays timezone spoke
19:37:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035462
19:37:07 <roshi> #info Accepted Blocker, initial-setup, VERIFIED
19:37:55 <pwhalen> verified fixed, enough karma for stable
19:38:47 <roshi> shiny
19:38:58 <roshi> #topic (969524) qml-based systray plasma widgets unclickable on arm
19:38:59 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=969524
19:38:59 <roshi> #info Accepted Blocker, kdelibs, NEW
19:39:41 <pwhalen> build with the upstream workaround failed on x86
19:39:48 <pwhalen> http://koji.fedoraproject.org/koji/taskinfo?taskID=6247897
19:41:02 <roshi> anything we need to do in relation to this bug?
19:41:20 <jreznik> I'll talk to kde guys
19:41:45 <roshi> #action jreznik to check with KDE guys regarding 1035462
19:41:55 <pwhalen> jreznik, thanks. I've joined as well
19:42:17 <roshi> #topic (1004621) plasma-nm doesn't attempt to connect to any listed networks on Fedora KDE live
19:42:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1004621
19:42:17 <roshi> #info Accepted Blocker, kde-plasma-nm, ON_QA
19:43:07 <roshi> I thought this worked now...
19:43:17 <adamw> tc3 didn't have the kdm switch
19:43:21 <roshi> I'll test this with TC4
19:43:22 <adamw> well, i assume it didn't, i didn't check
19:43:24 <adamw> tc4 should do
19:43:29 <roshi> that's right
19:43:33 <adamw> yeah, or you can build an image with kdm, it's pretty trivial
19:43:46 <roshi> when are you putting in TC4 req?
19:43:51 <adamw> today
19:43:53 <adamw> after this meeting
19:43:57 <roshi> ok
19:44:04 <adamw> i tested this locally with a kdm image and it seemed fine to me
19:44:19 <roshi> ok
19:44:21 <roshi> #topic (1032921) KDE f20 TC2 x86_64 fails to shutdown from menu bar
19:44:22 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1032921
19:44:22 <roshi> #info Accepted Blocker, kde-workspace, MODIFIED
19:45:31 <roshi> I just installed KDE i686 from DVD iso and it shutdown fine...
19:45:37 <pwhalen> I didnt see this on arm
19:46:12 <satellit> only on live boot
19:46:36 <roshi> description says DVD install
19:47:10 <satellit> works after liveinst
19:47:17 <adamw> it's apparently intermittent, not 100%
19:47:23 <roshi> yeah
19:47:24 <adamw> they think the kdm change should make it a non-issue
19:47:27 <roshi> also comment 8
19:47:34 <adamw> so just needs re-testing with tc4, i guess
19:47:42 <roshi> I *just* did this and haven't seen it
19:47:48 <roshi> DVD iso dd to USB
19:47:50 <danofsatx> I just did a bare metal install over the weekend with TC3 and do not see the problem.
19:48:07 <satellit> it only occured for me on live CD boot
19:48:10 <danofsatx> and it was a dvd iso dd'd to usb drive
19:48:21 <satellit> not DVD installer
19:48:31 <adamw> sounds like there's still a bug in this area that may persist after kdm switch (983110)
19:48:37 <adamw> no-one's seen fit to suggest it as a blocker, though
19:49:04 <satellit> If you install with livinst it works
19:49:06 <roshi> yeah - just because it's intermittent
19:49:25 <roshi> well, the proposed fix is in TC4, so retest
19:49:28 <roshi> moving on
19:49:45 <roshi> #topic (1000893) Desktop Live is oversized (larger than 1 GB)
19:49:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000893
19:49:45 <roshi> #info Accepted Blocker, LiveCD, NEW
19:50:18 * satellit do to banner translations?
19:50:40 <adamw> seems to be a Combination Of Factors
19:50:55 <adamw> (sorry, as a history graduate that phrase is baked into my head)
19:51:21 <adamw> like i said, i'll try and knock heads together with mclasen to do something about this today, before tc4 if we can
19:51:48 <roshi> sounds good
19:52:22 <roshi> #topic (790339) [abrt] system-config-services-0.101.7-2.fc17: connection.py:630:call_blocking:DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "list_services" with signature "" on interface "org.fedoraproject.Config.Services.ServiceHerder" doesn't exist
19:52:22 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=790339
19:52:22 <roshi> #info Accepted Blocker, system-config-services, VERIFIED
19:53:59 <roshi> looks like the fix here is good
19:54:32 <roshi> #topic (1006386) Journal flushing often slow, can prevent system booting correctly
19:54:33 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1006386
19:54:33 <roshi> #info Accepted Blocker, systemd, NEW
19:54:49 <roshi> we've got 6 minutes left in our 3 hour limit for blocker meetings
19:55:54 <adamw> there's lots of active work going on with this one
19:56:01 <adamw> but it seems like they're having trouble nailing it down
19:56:21 <roshi> at least it isn't being ignored
19:56:24 <roshi> so that's good
19:56:30 <jreznik> mschmidt was on PTO today... he seems to be most active on this one, so I'll check with him tomorrow
19:56:33 <roshi> anything for us to do regarding it?
19:56:36 <roshi> ok
19:57:02 <roshi> #action jreznik to check with mschmidt regarding bug 1006386
19:57:31 <roshi> #topic (1026860) Instantiated service is not run, it stays in inactive state (and systemd debug log does not state why)
19:57:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026860
19:57:32 <roshi> #info Accepted Blocker, systemd, NEW
19:57:37 <roshi> this is the last accepted blocker
19:57:39 <adamw> kinda the same
19:57:51 <adamw> for both systemd blockers, lots of active effort, but no fix yet
19:57:59 <roshi> fair enough
19:58:11 <roshi> anybody have anything elese?
19:58:14 <roshi> *else
19:58:23 <roshi> #topic Open Floor
19:59:58 <adamw> any other bugs we've missed?
20:00:30 <roshi> I don't think so
20:03:35 <roshi> well, thanks for coming!
20:03:49 * roshi lights old fashioned fuse
20:04:07 <roshi> endmeeting in 1 minute
20:04:12 <adamw> pfah, you traditionalist
20:04:16 <jreznik> thanks roshi!
20:04:19 * adamw sneaks behind roshi's back and substitutes a quantum fuse
20:04:26 * roshi saw that
20:04:35 <roshi> np jreznik :)
20:04:38 <roshi> glad to do it
20:05:05 <roshi> #endmeeting