16:01:13 <tflink> #startmeeting f20beta-blocker-review-3
16:01:13 <zodbot> Meeting started Wed Oct  9 16:01:13 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:13 <tflink> #meetingname f20beta-blocker-review-3
16:01:13 <zodbot> The meeting name has been set to 'f20beta-blocker-review-3'
16:01:25 <tflink> #topic Roll Call
16:01:33 * satellit listening
16:01:34 * mkrizek is here
16:01:48 <tflink> Who's ready for the fun?
16:01:49 * pwhalen is here
16:01:49 * cmurf here for a short bit
16:01:55 <pwhalen> who isn't? :)
16:02:15 * Viking-Ice sails in
16:02:20 <cmurf> yes it usually turns into something much longer than short or a bit
16:02:37 * roshi is here
16:03:42 * tflink will need to disappear for parts of the fesco meeting if the review takes that long
16:03:44 * jreznik is here
16:03:47 * kparal is here
16:04:28 * jreznik has to move home before fesco meeting but he was blocked by other meeting... no more meetings please! will be away for half hour
16:05:36 <tflink> I think we have enough to get started
16:05:45 <tflink> #topic Introduction
16:05:54 <tflink> Why are we here?
16:05:54 <tflink> #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 freeze exception bugs.
16:06:00 <tflink> #info We'll be following the process outlined at:
16:06:00 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:05 <tflink> #info The bugs up for review today are available at:
16:06:05 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:12 <tflink> #info The criteria for release blocking bugs can be found at:
16:06:12 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:06:17 <tflink> #info Up for review today, we have:
16:06:26 <tflink> #info 6 Proposed Blockers
16:06:26 <tflink> #info 12 Accepted Blockers
16:06:26 <tflink> #info 2 Proposed Freeze Exceptions
16:06:26 <tflink> #info 5 Accepted Freeze Exceptions
16:06:35 <tflink> Any volunteers for secretary duty?
16:06:52 * roshi raises hand
16:06:59 <tflink> cool
16:07:08 <tflink> adamw: you around?
16:07:22 <tflink> any objections to starting with the proposed blockers?
16:07:32 <Viking-Ice> nope let's rock on
16:07:58 <tflink> #topic (1009809) KeyError: 'name'
16:07:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009809
16:07:59 <tflink> #info Proposed Blocker, anaconda, ON_QA
16:09:05 <tflink> -1 blocker - nfs works
16:09:12 * kparal nods
16:09:16 <mkrizek> -1 blocker
16:09:22 <kparal> actually this is even fixed with F20 Beta TC2 I think
16:09:23 <cmurf> -1
16:09:37 <Viking-Ice> -1
16:09:43 <jreznik> so -1
16:10:01 <roshi> -1
16:10:18 <tflink> proposed #agreed 1009809 - RejectedBlocker - As stated in the F20 beta criteria, only one of [nfs, nfsiso] is required to work for beta. As nfs package sources have been confirmed to work, this is rejected as a release blocking bug for f20 beta.
16:10:22 <tflink> ack/nak/patch?
16:10:25 <kparal> ack
16:10:26 <mkrizek> ack
16:10:30 <Viking-Ice> ack
16:10:47 <cmurf> ack
16:10:49 <jreznik> ack
16:11:08 <tflink> #agreed 1009809 - RejectedBlocker - As stated in the F20 beta criteria, only one of [nfs, nfsiso] is required to work for beta. As nfs package sources have been confirmed to work, this is rejected as a release blocking bug for f20 beta.
16:11:16 <tflink> #topic (1013586) SizeNotPositiveError: spec= param must be >=0
16:11:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013586
16:11:16 <tflink> #info Proposed Blocker, anaconda, NEW
16:12:30 <kparal> please note that ext4 resize is broken as well, it's not just ntfs
16:12:46 <cmurf> +1 blocker
16:12:47 <tflink> but it's limited to gnome-disks?
16:12:52 <cmurf> but it would be helpful to know the mechanism
16:12:57 <kparal> tflink: no, I reproduced it with gdisk
16:13:05 <kparal> it's about partition size I think
16:13:06 <tflink> but not gparted?
16:13:12 <kparal> gparted adds padding
16:13:20 <Viking-Ice> this is gnome disk but not the anaconda installer right
16:13:27 <tflink> and anaconda uses parted under the hood, too, I think
16:13:40 <tflink> Viking-Ice: it's sounding like an anaconda issue
16:13:59 <Viking-Ice> if you skip the gdisk stuff and just use anaconda then what?
16:14:08 <cmurf> +1 blocker because even if the partition scheme is invalid, anaconda should not crash
16:14:15 <tflink> yeah, +1
16:14:30 <kparal> cmurf: it's most probably valid
16:14:30 <cmurf> however, if it is invalid, then we have bugs to file against gdisk and gnome-disks
16:14:30 <Viking-Ice> true +1
16:14:55 <cmurf> but looking at it, while there is a difference in free space between the utilities, i think this is just for alignment
16:15:02 <cmurf> it's not invalid layouts
16:15:10 <cmurf> so i don't know why anaconda has a problem with it
16:15:12 <jreznik> +1 and we will see if it's valid or not, we can deal with it later
16:15:21 <kparal> the only hiccup is that we don't have criteria for guided shrinking
16:15:41 <cmurf> true but you have one for the installer not crashing
16:15:53 <tflink> proposed #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for partitions not created using parted: "When using the guided partitioning flow, the installer must be able to ... Remove existing storage volumes to free up space, at the user's direction"
16:16:01 <Viking-Ice> ack
16:16:15 <kparal> that's the closest one, right
16:16:16 <kparal> ack
16:16:26 <cmurf> here you go
16:16:29 <jreznik> ack
16:16:30 <cmurf> "Complete an installation using any combination of disk configuration options it allows the user to select"
16:16:52 <tflink> actually, that's probably better
16:16:56 <cmurf> that encompases shrink
16:16:59 <kparal> hmm, I guess that applies even better, right
16:17:14 <tflink> proposed #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for partitions not created using parted: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:17:22 <kparal> ack
16:17:23 <cmurf> ack
16:17:27 <Viking-Ice> smack
16:17:35 <tflink> Viking-Ice: ?
16:17:38 <roshi> ack
16:17:52 <Viking-Ice> tflink, the new and improved ack
16:17:58 <Viking-Ice> ack 2.0
16:18:06 <tflink> #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for partitions not created using parted: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:18:29 <tflink> #topic (1015220) can't log in as ordinary user after text install unless under user spoke, password field is last one filled out
16:18:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1015220
16:18:34 <tflink> #info Proposed Blocker, anaconda, VERIFIED
16:18:56 <cmurf> i'm not finding any text install beta criteria
16:19:32 <tflink> "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so."
16:19:38 <kparal> cmurf: https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Installation_interfaces
16:19:43 <tflink> bah, I'm not thinking right
16:19:58 <cmurf> hmm ok so text is an alpha requirement, and it does complete, and it's a non-graphical package set...
16:20:14 <tflink> but you can't login post install
16:20:27 <kparal> +1
16:20:36 <tflink> A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles.
16:20:38 <cmurf> yeah so +1
16:20:46 <tflink> let's just get this accepted, it's already fixed :)
16:20:51 <jreznik> +1
16:20:51 <Viking-Ice> this seems to spesific to the wheel group
16:21:04 <pwhalen> +1
16:21:09 <jreznik> I don't think so
16:21:37 <tflink> proposed #agreed 1015220 - AcceptedBlocker - Violates the following F20 alpha release criterion for text installs where the user password isn't the last spoke entered: "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles."
16:21:38 <roshi> +1
16:21:45 <Viking-Ice> -1 +1 FE
16:21:45 <kparal> ack
16:21:49 <Viking-Ice> ack
16:21:54 <roshi> ack
16:21:56 <jreznik> ack
16:22:02 <cmurf> hold on
16:22:08 <pwhalen> ack
16:22:09 <tflink> I'm +1
16:22:31 <cmurf> yeah but the criteria doesn't say whether root or regular user, it just says the prompt must work
16:22:35 <cmurf> can the user login as root?
16:22:41 <cmurf> just not as ordinary user?
16:22:44 <Viking-Ice> comment 19
16:22:47 <Viking-Ice> mean comment 10
16:22:56 <Viking-Ice> but in anycase enough acks
16:23:10 <Viking-Ice> let's just pull this one in since the fix is there and move to the next
16:23:10 <tflink> I see +6/-1 blocker
16:23:23 <tflink> #agreed 1015220 - AcceptedBlocker - Violates the following F20 alpha release criterion for text installs where the user password isn't the last spoke entered: "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles."
16:23:36 <tflink> #topic (1016927) Fedora 20 Beta TC2 Anaconda Netinstall gets error checking software configuration
16:23:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016927
16:23:41 <cmurf> comment 11 indicates even root can't login
16:23:42 <tflink> #info Proposed Blocker, anaconda, NEW
16:24:03 * satellit I sa this last night
16:24:14 <satellit> saw*
16:24:23 <cmurf> well for sure KDE not working is blocking isn't it?
16:24:37 <kparal> why he always talk about dnf?
16:24:46 <satellit> dan also saw it
16:24:54 <pwhalen> this indicates they are including updates in the installation, is that intended in the testcase?
16:25:07 <cmurf> is this guided partitioning?
16:25:37 <satellit> with out checked box get to install but fail with check never are allowed to hit install in main hub
16:25:40 <tflink> pwhalen: for netinstall, I think so
16:25:48 <kparal> ok, this is simply a broken package
16:25:50 <pwhalen> I would think you want the release repo only, including updates-testing isn't reproducible
16:25:57 <Viking-Ice> or a resolv issue
16:26:14 <satellit> update box is default as checked
16:26:19 <tflink> is this related to the whole dnf-broke-the-buildroot issue
16:26:41 <pwhalen> dnf no longer has a specific requires on the new version
16:27:11 <jreznik> tflink: it is
16:27:27 <jreznik> python-librepo
16:27:41 <satellit> related to gnome firstboot?
16:27:45 <tflink> but gnome installs using boot.iso work?
16:27:53 <satellit> yes
16:28:03 <satellit> and soas dan says
16:28:11 <satellit> only
16:28:14 <tflink> kde and gnome?
16:28:20 <roshi> I ran into this yesterday, but wasn't sure if it was an error on my part
16:28:29 <cmurf> it looks like because netinstl gets the newest stuff, including updates-testing, that it's hanging on updating dnf because it wants an older version of python-librepo
16:28:37 * roshi was planning to reproduce today - but doesn't look like he needs to
16:29:08 <jreznik> it will be fixed once librepo issue is fixed I'd say
16:29:08 <pwhalen> new version, no specific requires - https://admin.fedoraproject.org/updates/FEDORA-2013-18516/dnf-0.4.3-2.fc20
16:29:15 <Viking-Ice> from the other bug "Hi, thank you for the report, this has just been fixed yesterday and the new DNF (starting with 0.4.3) does not depend on exact versions."
16:29:53 <cmurf> a.) it's fixed, and b.) it's not anything to do specifically with netinstl
16:29:59 <cmurf> so -1 blocker
16:30:03 <Viking-Ice> -1
16:30:06 <pwhalen> -1
16:30:26 <roshi> -1
16:30:28 <tflink> "There must be no errors in any package on the release-blocking images which cause the package to fail to install."
16:30:37 <tflink> is this satisfied?
16:30:46 <cmurf> nope
16:30:48 <kparal> if live nor dvd is broken...
16:30:51 <satellit> kde
16:30:51 <cmurf> because kde is release blocking
16:30:58 <kparal> _images_
16:31:01 <Viking-Ice> are we installing both yum and dnf by default ?
16:31:06 <cmurf> yes
16:31:24 <Viking-Ice> great subscription for disaster
16:31:37 <tflink> yeah, that's what I was thinking as well
16:31:56 <Viking-Ice> either one of those should be installed by default not both
16:31:59 <cmurf> well at least dnf doesn't download 750MB by default like gnome shell does...
16:32:01 <tflink> isn't there a third installation method coming? some pk replacement?
16:32:07 <tflink> we digress
16:32:24 <Viking-Ice> tflink, 4 we need to support 4 actually probably 5
16:32:37 <cmurf> tflink: yes there is an application package installer
16:32:38 <tflink> so the busted package isn't on any images?
16:32:44 <cmurf> tflink correct
16:32:49 <tflink> ok, I can live with -1
16:32:53 <jreznik> -1
16:32:58 <cmurf> netinstl inherits this problem just because it's so up to date
16:33:21 <cmurf> and i think updates-testing is disabled for final right?
16:33:28 <cmurf> by default
16:33:45 <tflink> proposed #agreed 1016927 - This would be a blocker if the broken packages were actually on any images but it was fixed quickly enough such that it was never included. Thus, it is rejected as a release blocking bug for f20 beta.
16:33:47 <jreznik> yes, but doesn't matter for this one
16:33:54 <jreznik> ack
16:33:55 <tflink> cmurf: once we get to final RCs
16:33:56 <cmurf> ack
16:33:58 <Viking-Ice> ack
16:34:04 <pwhalen> ack
16:34:11 <tflink> #agreed 1016927 - This would be a blocker if the broken packages were actually on any images but it was fixed quickly enough such that it was never included. Thus, it is rejected as a release blocking bug for f20 beta.
16:34:24 <tflink> #topic (1016959) ValueError: Cannot remove non-leaf device 'btrfs.14'
16:34:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016959
16:34:30 <tflink> #info Proposed Blocker, anaconda, NEW
16:34:57 <cmurf> yet another werid btrfs bug, with possible related/dup
16:34:59 <Viking-Ice> so where are we with btrfs
16:35:07 <Viking-Ice> is it not still flagged experimental
16:35:07 <tflink> why would you have btrfs on lvm?
16:35:11 <cmurf> lots of problems, lots of fixes
16:35:18 <Viking-Ice> tflink, you dont
16:35:28 <tflink> Viking-Ice: see c#14
16:36:06 <cmurf> btrfs on LVM is debatable but it depends on the layout, in any case it should work
16:36:18 <cmurf> and in the sister bug, it's not on LVM but i get the same basic error messages
16:36:35 <cmurf> anaconda is trying to delete subvolumes when it should just blow away the LV or partition with a whole new file system
16:36:41 <kparal> time to invite some anaconda folks?
16:36:43 <cmurf> yes
16:36:44 <Viking-Ice> I doubt that this setup is supported
16:37:02 <tflink> I'm not all that crazy on the idea of blocking release over questionably sane partitioning issues
16:37:06 <Viking-Ice> kparal, perhaps josef as well to see if this is supposed to be doable et all
16:37:07 <tflink> sane/supported
16:37:10 <cmurf> it's not questionable at all
16:37:13 <Viking-Ice> - 1 blocking
16:37:19 <cmurf> home is on LVM, and btrfs is on LV
16:37:26 <cmurf> no different than ext4 on an LV
16:37:45 <tflink> you can't have ext4 subvols, though
16:37:59 <cmurf> that's not the problem
16:38:05 <tflink> isn't it?
16:38:14 <cmurf> teh problem isn't subvols + LVM
16:38:16 <tflink> anaconda is deleting the subvol instead of the lv?
16:38:53 <cmurf> if the installer is confused between subvols and LVs it's definitely a bug
16:38:54 * pschindl is here and hopes that haven't left all the fun.
16:39:06 <tflink> #chair pschindl
16:39:06 <zodbot> Current chairs: pschindl tflink
16:39:08 <tflink> :)
16:39:25 <Viking-Ice> I'm pretty sure this is not supposed to be doable mean you must hit all kinds of weird issues when you for example resize etc
16:39:51 <cmurf> ok you can find on the btrfs wiki that all the LVM and device mapper stuff is supposed to work
16:39:58 <cmurf> so if it doesn't it's a bug and needs to be fixed
16:40:29 <cmurf> the only way to encrypt btrfs is via the dm. the only way to do reliable software raid 5/6 with btrfs is via dm.
16:40:33 <cmurf> LV is dm
16:41:01 <cmurf> now if you want to punt and make me reproduce this on a plain partition i'll try that, but the sister bug is exactly that
16:41:11 <cmurf> but the fact is
16:41:14 <cmurf> anaconda crashes
16:41:22 <cmurf> so even if this is an invalid layout, it should not crash
16:41:25 <cmurf> so +1 blocker
16:41:35 <tflink> you've got a point there
16:41:51 <Viking-Ice> ok we just need to get sorted what is a valid btrfs setup and what is not but I think this is enough corner case to not block the release for -1 blocker  +1FE
16:42:00 <tflink> +1
16:42:15 <cmurf> clearly violates the beta criteria as written
16:42:34 * jreznik2 is with Viking, sounds too corner case for me
16:42:41 <tflink> agreed, forgot about the invalid operation part
16:42:49 <tflink> er, agreed with cmurf
16:43:17 <tflink> When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing.
16:43:21 <Viking-Ice> it's an blocker on the crash value
16:43:23 <tflink> if the layout is not valid, anyways
16:43:28 <cmurf> "When using the custom partitioning flow, the installer must be able to, Reject or disallow invalid disk and volume configurations without crashing."
16:43:33 <kparal> bcl just replied on #anaconda
16:43:57 <cmurf> can you copy-paste :-) i just joined
16:44:39 <tflink> "well, just from that description that sounds like a bad idea. I'm fairly sure btrfs is meant to be used w/o lvm. I'm not even sure how you manage to get that kind of thing setup."
16:45:11 <Viking-Ice> but the bug is a blocker on the crash value
16:45:12 <Viking-Ice> +1
16:46:22 <Viking-Ice> hey people let's move on
16:46:43 <Viking-Ice> bcl can just share this with the rest of the meeting on the meeting channel for crying out loud
16:46:43 <tflink> proposed #agreed 1016959 - AcceptedBlocker - Violates the following F20 beta release criterion, assuming that the disk layout in question is not considered valid: "well, just from that description that sounds like a bad idea. I'm fairly sure btrfs is meant to be used w/o lvm. I'm not even sure how you manage to get that kind of thing setup."
16:46:46 <Viking-Ice> ack
16:46:51 <tflink> Viking-Ice: I can only type so fast
16:47:46 <Viking-Ice> should we be using the crash criteria?
16:48:14 <tflink> whoops
16:48:16 <jreznik2> Yep
16:48:33 <tflink> proposed #agreed 1016959 - AcceptedBlocker - Violates the following F20 beta release criterion, assuming that the disk layout in question is not considered valid: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing."
16:48:38 <tflink> copied the wrong thing
16:49:16 <tflink> here's another question - is this enough of a corner case to reject as a blocker, even under this criterion
16:49:18 <Viking-Ice> ack
16:49:19 <tflink> ?
16:49:31 <Viking-Ice> crash is an crash
16:49:34 <Viking-Ice> in anaconda
16:49:38 <jreznik2> tflink, I'd say so
16:50:06 <tflink> Viking-Ice: ideally, yes. but there's the practical question of whether this is worth blocking release over
16:50:43 <Viking-Ice> tflink, I was against it but for it due to the crash criteria
16:51:24 <cmurf> i think setting up the logic to warn is higher risk for sneaking it in as a freeze exception
16:51:31 <cmurf> i'd say make it a blocker or not
16:51:40 <Viking-Ice> this needs to be fixed for final
16:51:45 <Viking-Ice> anyway so
16:51:59 <cmurf> well then you might as well block on beta and have actual beta testers testing the resulting code
16:52:07 <cmurf> so that we aren't blowing up during final TC's and RC's
16:52:26 <cmurf> anaconda team prefers more blocks on beta than final crunch time, which is higher risk anyway
16:52:46 <tflink> hrm, I went too fast with the proposal - any more votes?
16:52:58 <tflink> cmurf: despite the fact that they said they didn't think this bug should block release?
16:53:13 <cmurf> bcl clarified that he thinks they should not blow up but also not support the layout
16:53:23 <cmurf> so supporting the layout he says should not be blocking
16:53:36 <cmurf> and i don't think they'd be required to support the layout in any case, just not blow up
16:53:47 <tflink> I read it differently
16:53:57 <Viking-Ice> seriusly guys have the anaconda developers have this discussion here
16:54:14 <cmurf> his idea of "fixing it" means to properly do what i asked which is to remove all of the related file systems
16:54:15 <tflink> I asked them to join, what else do you want us to do?
16:54:24 <cmurf> that's harder than just not blowing up
16:54:27 <Viking-Ice> and we should not be blocking surely based on dev input
16:54:35 <Viking-Ice> ( or not blocking )
16:54:47 <cmurf> he agreed with me
16:54:58 <cmurf> cmurf: bcl: that's reasonable but the criteria says you shouldn't blow up in any case, no matter the validity of the layout
16:54:58 <cmurf> [10:47am] bcl: that's what I just said
16:55:01 <Viking-Ice> then they just say nothing is a blocking bug and never fix anything
16:55:29 <tflink> more votes?
16:55:31 <cmurf> viking; totally untrue
16:55:43 <tflink> pschindl, jreznik2, roshi, adamw : votes?
16:55:50 <cmurf> viking: they routinely accept blockers without complaint and get them fixed rather quickly IMO
16:55:53 <tflink> kparal: you too :)
16:56:16 <roshi> +1 due to crash
16:56:26 <pschindl> I haven't seen the whole discussion but I'm +1
16:56:32 * roshi was thinking
16:58:01 * kparal was temporarily away, reading backlog
16:58:04 <Viking-Ice> so what are we waiting for now ( 10m gone in waiting for acks )
16:58:05 <tflink> I see .. +4/1x+0/-=
16:58:19 <tflink> I see .. +4/1x+0/-1
16:58:33 <kparal> ack
16:59:06 <tflink> kparal: I assume that's a +1?
16:59:16 <Viking-Ice> tflink, are you recounting now?
16:59:22 <tflink> yes
16:59:26 <kparal> that's ack to proposed #agreed
16:59:30 <Viking-Ice> <sigh>
16:59:39 <tflink> making sure we had enough +1s to move forward in the first place
16:59:54 <kparal> +1
17:00:09 <Viking-Ice> tflink, yeah like last time right
17:00:13 <tflink> #agreed 1016959 - AcceptedBlocker - Violates the following F20 beta release criterion, assuming that the disk layout in question is not considered valid: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing."
17:00:27 <tflink> Viking-Ice: I change my mind from time to time ... so sue me
17:00:46 <Viking-Ice> how much you got?
17:00:48 <tflink> if you really think that votes and minds should be unchangeable ... you're insane
17:01:07 <kparal> <quote>only idiots don't change opinions</quote>
17:01:30 <Viking-Ice> tflink, the bloody time it people decide then run to developer then people decide again blablabla
17:01:31 <tflink> #topic (1015234) F20 Beta TC1 ARM disk images unable to find root filesystem
17:01:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1015234
17:01:36 <tflink> #info Proposed Blocker, dracut, NEW
17:01:57 <tflink> Viking-Ice: I can wait longer before writing proposals if you'd like
17:02:18 <cmurf> seems like a clear +1 to me
17:02:20 <tflink> well, that'd be the other option but I'm not liking that idea much
17:02:31 <Viking-Ice> tflink, yeah why not since the workflow is like this, in honor of our 3 hours meetings ;)
17:03:20 <tflink> Viking-Ice: if you have reasonable ideas on how to improve the process, I'm interested
17:03:38 <tflink> I don't think this is real-fun for anyone
17:03:53 <tflink> "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."?
17:03:53 <roshi> just fun, not "real-fun"
17:03:54 <Viking-Ice> I think we need to punt this for more data
17:04:13 <kparal> what data?
17:04:21 <tflink> we do? the arm images aren't booting
17:04:32 <kparal> seems +1 blocker to me, at the moment
17:04:35 <Viking-Ice> tflink, yeah but we dont know why
17:04:41 <tflink> does it matter?
17:04:44 <Viking-Ice> Well according to the debug log, "mmc_block" is actually installed.
17:05:04 <tflink> a release-blocking image not booting is a blocker
17:05:19 <Viking-Ice> yes as well as crash in the installer is crash...
17:05:19 <kparal> if this happens to be just a glitch with a single device, we can remove the blocker afterwards
17:05:30 <Viking-Ice> +1
17:05:31 <kparal> at this moment it seems to be a generic error
17:05:32 <tflink> Viking-Ice: not even close to the same thing
17:05:50 <tflink> this is reported as a "not booting" across all images, virt and supported HW
17:05:54 <tflink> not a corner case in the installer
17:06:12 * tflink is +1
17:06:51 <tflink> proposed #agreed 1015234 - AcceptedBlocker - Violates the following F20 alpha release criterion for ARM images in virt and on bare-metal: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:07:28 <roshi> ack
17:07:35 <pschindl> ack
17:08:14 <jreznik2> ack
17:08:16 <Viking-Ice> ack btw tflink release-blocking image not booting is a blocker on primary arch ;)  his is reported as a "not booting" across all images, virt and supported HW
17:08:17 <Viking-Ice> not a corner case in the installer ?
17:08:29 <Viking-Ice> that report only mentions arm
17:08:37 <tflink> arm is PA
17:08:37 <kparal> ack
17:08:50 <tflink> unless that decision was reversed and I missed the announcement
17:09:19 <tflink> #agreed 1015234 - AcceptedBlocker - Violates the following F20 alpha release criterion for ARM images in virt and on bare-metal: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:09:41 <tflink> OK, that's all the blockers on my list
17:09:47 <tflink> proposed blockers, rather
17:09:50 <Viking-Ice> was actually decided I thought it was on somekind of "probation" from fesco but bah hardly matters really
17:10:35 <tflink> I think it was "considered as PA unless there are major issues that show arm isn't ready for PA"
17:10:39 <tflink> but I could be wrong
17:11:06 <Viking-Ice> yeah it was something vague like that
17:11:07 <tflink> do we want to skip the proposed FE again?
17:11:26 <Viking-Ice> +1 FE on sugar
17:11:31 <tflink> Viking-Ice: par for the coarse
17:12:11 * satellit peter said he would look at sugar soon - back from vacation
17:12:13 <Viking-Ice> as well as +1 for btrfs ( it has a patch )
17:12:32 <tflink> so we're not skipping the proposed FE
17:12:34 <tflink> ok
17:12:41 <tflink> #topic (1011714) btrfs scrub finds csum corruption after btrfs balance
17:12:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1011714
17:12:47 <tflink> #info Proposed Freeze Exceptions, kernel, MODIFIED
17:13:44 <tflink> is btrfs scrub like fsck?
17:14:58 <tflink> sounds like it's fsck in the background with some autofix
17:15:07 <tflink> how often should balance be performed
17:15:08 <tflink> ?
17:15:35 <tflink> I'm leaning -1 FE at the moment, seems fixable by updates
17:16:31 * kparal doesn't understand it
17:17:13 <tflink> my understanding is that there are issues with the background check on btrfs once it does some auto-maintenance on itself
17:17:18 <tflink> cmurf: you around?
17:18:01 <cmurf> yes sorry
17:18:36 <cmurf> btrfs scrub causes data to be checksumed and compared to the previously computed checksums stored in metadata
17:18:42 <cmurf> it's like a raid scrub, but better
17:18:50 <Viking-Ice> tflink, not all filesystem issues can be fixed via update
17:18:51 <cmurf> and balance doesn't need to be performed that often
17:19:05 <tflink> Viking-Ice: which is why I'm asking questions
17:19:16 <tflink> cmurf: can this be fixed with an update post-install?
17:19:17 <cmurf> tflink: the fix is headed to stable so it should be in 3.11.x
17:19:26 <cmurf> tflink: mmmm well the corruption is permanent
17:19:40 <cmurf> tflink: but at the moment it only affects systemd journals as far as i know
17:19:56 <cmurf> tflink: the result is that systemd complains about corrupt journals, and pitches them
17:20:05 <cmurf> tflink: life goes on but those journals are axed
17:20:23 <cmurf> tflink: until the journals are deleted, scrubs continue to report checksum errors
17:20:33 <Viking-Ice> well if journal gets corrupted other things will as well
17:20:57 <cmurf> viking: uncertain, systemd is allocating space and writing in a unique way
17:20:58 <tflink> ok, this is worse than I thought it was at first. I'm not a fan of kernel FEs, though
17:21:12 <cmurf> tflink: me neither, i tend to leave that up to the kernel people
17:21:17 <Viking-Ice> tflink, does not mean we have to pull it in
17:21:24 <Viking-Ice> and this is spesific to btrfs as well so
17:21:35 <cmurf> tflink: but sometimes these patches meant for stable are lost so i figured tracking it might be a good idea, maybe final freeze exception?
17:21:37 <cmurf> i'm not sure
17:21:41 <cmurf> hence i proposed it
17:21:48 <tflink> Viking-Ice: I mean that there are things which should probably be blockers to be pulled in: kernel, systemd, dracut, glibc ... some others
17:23:17 <Viking-Ice> anywho votes people!
17:23:46 <dan408-> hi
17:23:47 <tflink> I'm hesitant to vote on this without more understanding on how big/invasive the change is
17:23:52 <roshi> as am I
17:23:56 <tflink> I'm not -1, though
17:24:11 <cmurf> we need jwboyer maybe
17:24:12 * roshi isn'
17:24:17 <cmurf> any kernel people around?
17:24:18 <Viking-Ice> cmurf, josef
17:24:25 * roshi isn't familiar with btrfs
17:24:56 <cmurf> i think any kernel person can answer if this should block or FE
17:25:24 <cmurf> but you could punt and ask the question to josef in the bug and revisit in a week
17:25:42 <Viking-Ice> well í'm -1 beta blocker +1 FE +1 Final blocker
17:25:45 <tflink> yeah, I'm thinking punt
17:26:06 <tflink> FE doesn't matter until freeze starts, anyways
17:26:06 <Viking-Ice> tflink, why
17:26:22 <tflink> Viking-Ice: because I don't know enough about the patch to be comfortable voting yet
17:26:42 <cmurf> maybe i should cc a systemd dev on this bug?
17:26:47 <cmurf> maybe they have 2 cents
17:27:34 <cmurf> add in Lennart?
17:27:34 <tflink> cmurf: for the journal issue? you could but it sounds like this is an artifact of how systemd is allocating storage for journals to me
17:27:42 <tflink> but I could easily be wrong
17:27:51 <cmurf> tflink yes
17:28:07 <cmurf> tflink yes it's a side effect of how systemd allocates journals
17:28:18 <cmurf> but josef said they weren't doing the right thing on the btrfs side for this
17:28:34 <cmurf> it's possible something else in the world does what systemd is doing, but i don't know how unique that is
17:29:18 <cmurf> it's an experimental file system… that's reason enough to punt for now
17:30:29 <tflink> proposed #agreed 1011714 - We'd like to see more information on how big/invasive/risky this patch is before making a decision on FE, will ask relevant devs and revisit at the next review meeting
17:30:33 <roshi> +1 punt (personally) so I can do some research before voting
17:31:03 <cmurf> +1
17:31:12 <tflink> ack/nak/patch?
17:31:18 <roshi> ack
17:31:19 <cmurf> ack
17:31:28 <kparal> ack
17:31:30 <Viking-Ice> ack
17:31:37 <cmurf> fyi criteria says "fixed or documented"
17:31:46 <tflink> #agreed 1011714 - We'd like to see more information on how big/invasive/risky this patch is before making a decision on FE, will ask relevant devs and revisit at the next review meeting
17:31:49 <cmurf> so that's another recourse is to just require that it be documented
17:31:56 <cmurf> it=the corruption
17:32:04 <tflink> #topic (1015731) netinstall f20 Beta TC-1  x86_64 of sugar-desktop boots to console login
17:32:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1015731
17:32:09 <tflink> #info Proposed Freeze Exceptions, sugar, NEW
17:32:39 <tflink> +1 FE
17:32:53 <cmurf> +1 FE I don't see a criteria busted here
17:33:02 <roshi> +1
17:33:13 <dan408-> +1
17:33:49 <pwhalen> +1
17:34:12 <tflink> proposed #agreed 1015731 - AcceptedFreezeException - This prevents SoaS from booting or functioning properly. As a secondary DE, a tested fix would be considered after freeze.
17:34:21 <cmurf> ack
17:34:25 <dan408-> ack
17:34:26 <pwhalen> ack
17:34:39 <tflink> #agreed 1015731 - AcceptedFreezeException - This prevents SoaS from booting or functioning properly. As a secondary DE, a tested fix would be considered after freeze.
17:35:01 <tflink> OK, on to the accepted blockers
17:35:35 * satellit this is sugar-desktop DE not soas live....
17:36:27 <tflink> oh
17:36:34 <tflink> #undo
17:36:34 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x53939fd0>
17:36:41 * satellit Sugar on a Stick is SoaS
17:37:05 <tflink> #agreed 1015731 - AcceptedFreezeException - This prevents sugar-desktop from booting or functioning properly after install. As a secondary DE, a tested fix would be considered after freeze.
17:37:11 * tflink can undo if anyone objects
17:39:06 <tflink> pschindl: why did you close 901917? is anaconda-20.21-1 stable?
17:39:36 <pschindl> tflink: yes, it is stable
17:40:07 <tflink> ok, I didn't realize it had gone stable already
17:40:19 <tflink> #topic (901917) rescue a fedora system mode doesn't recognize luks installation
17:40:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=901917
17:40:25 <tflink> #info Accepted Blocker, anaconda, MODIFIED
17:40:32 <tflink> #info this has been verified, pushed stable and closed
17:40:51 * tflink is concerned that the app isn't correctly showing this bug - will investigate after the meeting(s)
17:41:14 <tflink> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke
17:41:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575
17:41:19 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
17:41:20 * kparal needs to leave, sorry
17:41:38 * cmurf needs to leave in ~10
17:42:23 <tflink> #info no apparant movement on this bug yet
17:42:33 <tflink> #info devs are aware of the issue, proposed it as a blocker
17:43:32 <pschindl> shouldn't we move it to 20 (version)?
17:44:08 <tflink> yeah, I wonder if this hasn't already been fixed
17:44:28 <Viking-Ice> are we doing proposed blockers now if so should we not only be looking at status new?
17:44:55 <tflink> accepted blockers, yes.
17:45:14 <tflink> status < ON_QA is how we've done it in the past
17:45:30 <tflink> < POST if we assume that the statuses are being updated properly
17:46:33 <tflink> I'd say lets poke dlehman via bz and revisit at the next meetign
17:46:49 <roshi> +1
17:47:40 <Viking-Ice> poke the entire anaconda team and have them walk through those
17:48:17 <tflink> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
17:48:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
17:48:23 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
17:48:40 <tflink> #info work on this has been moving along, doesn't appear as if anything is needed from us at this time
17:49:15 <cmurf> there is an updates.img, it has not been rolled into anaconda as of 20.23-1
17:49:31 <tflink> #info there is an updates.img, it has not been rolled into anaconda as of 20.23-1
17:49:43 <tflink> anything else for this one?
17:49:47 <cmurf> nope
17:49:51 <tflink> #topic (1012504) FSError: filesystem already exists
17:49:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012504
17:49:52 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
17:49:58 <tflink> it sounds like this can be closed
17:50:07 <cmurf> yes it could be bad media related if i have the bug right
17:50:27 <Viking-Ice> yup
17:50:28 <Viking-Ice> close it
17:50:44 <tflink> #info this bug has been fixed, can be closed
17:50:58 <cmurf> well it think it might not have been a bug at all but OK
17:51:05 <cmurf> bad media related weirdness
17:51:06 <tflink> #undo
17:51:06 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x5a9fe150>
17:51:11 <Viking-Ice> so who's going to close it? pschindl
17:51:18 <tflink> #info this is no longer an issue and it can now be closed
17:51:27 <tflink> roshi since he's playing secretary
17:51:43 * roshi has it :)
17:52:05 <tflink> #topic (1000891) DVD is oversized (larger than 4.7 GB)
17:52:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
17:52:05 <tflink> #info Accepted Blocker, distribution, MODIFIED
17:52:13 <tflink> F20 beta TC2 is still oversize
17:52:19 <tflink> #info F20 beta TC2 is still oversize
17:52:45 <Viking-Ice> great
17:53:07 <tflink> #info a different fix is needed than the KS exclusion, looking for a different method to exclude the gimp-help files
17:53:55 <tflink> #info devs are aware of the issue, looking for a fix
17:54:01 <tflink> anything else to say on this?
17:54:08 <Viking-Ice> not really
17:54:49 <tflink> #topic (1013767) rootfs on thinp not found, startup failure
17:54:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767
17:54:49 <tflink> #info Accepted Blocker, dracut, NEW
17:55:32 <tflink> #info work is progressing on this bug, nothing is needed from us at this point
17:55:58 <tflink> other than the part about beta freeze starting on tuesday
17:56:02 <tflink> :-/
17:56:16 <tflink> anything else to add here?
17:57:21 * tflink assumes not
17:57:30 <roshi> nothing on my end
17:57:45 <Viking-Ice> nope not really
17:57:45 <tflink> #topic (1009132) updates-plugin-WARNING **: failed to download: The backend exited unexpectedly.
17:57:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009132
17:57:51 <tflink> #info Accepted Blocker, gnome-settings-daemon, ASSIGNED
17:57:55 <tflink> pschindl: have you been able to repoduce this recently?
17:58:19 <pschindl> tflink: I haven't tried this
17:58:35 <pschindl> I will check it after meeting.
17:58:42 <tflink> #action pschindl to re-test #1009132 to make sure it's still an issue
17:59:03 <tflink> we should probably pester hughsie about this
17:59:25 <pschindl> tflink: I will ping him.
17:59:31 <tflink> pschindl: thanks
17:59:50 <tflink> #info there appears to have been no movement on this for weeks, we're not even sure it's still an issue
18:00:21 <tflink> #action pschindl to sync up with hughsie about this issue after re-testing
18:00:26 <tflink> cool, anything else here?
18:01:02 <tflink> #topic (1000893) Desktop Live is oversized (larger than 1 GB)
18:01:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000893
18:01:03 <tflink> #info Accepted Blocker, LiveCD, NEW
18:01:25 <dan408-> i can try to look at this one
18:02:23 <dan408-> http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Live/x86_64/
18:02:26 <tflink> was gavl-1.4.0-4.fc20 in TC2?
18:02:31 <dan408-> it is at exactly 1.0GB?
18:02:38 <mkrizek> sorry, note regarding irc://chat.freenode.net:6667/#1009132 — I haven't been able to reproduce it with TC2
18:02:51 * tflink notes that the fesco meeting just started
18:04:30 <tflink> dan408-: looks like it's close
18:04:42 <Viking-Ice> we can continue later if you need to run
18:04:57 * tflink needs to leave for a bit
18:05:03 * satellit note did netinstall to virtualBox of mate sucessfully just now.....with updates box unchecked
18:06:06 <satellit> ?me TC2
18:06:33 <dan408-> satellit: i want to know why that bug happened in the first place though, it's pissing me off
18:07:04 <satellit> comps? or did an update fix it
18:10:13 <tflink> I can chair someone if you all want to continue
18:10:31 <tflink> the list is up at http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/irc
18:11:52 <tflink> this, 1016842 and 1013800 are left
18:13:24 <pschindl> ok. And what's left on this?
18:13:52 <pschindl> It doesn't seem that it's moving forward.
18:15:17 <tflink> it is, just in deps
18:15:33 <tflink> they're trying to carve spave out, not sure if its been enough yet
18:22:27 * satellit afk (Dr.appt)
18:22:51 <Viking-Ice> who's left ?
18:23:09 <roshi> I'm here for a bit longer
18:24:10 <pschindl> I'm still here
18:26:55 <roshi> do we have enough, or does this have to wait until after fesco?
18:31:13 <pschindl> I don't know. We could probably finish the other two. But I'm not sure about this one. I don't know anything about this bug.
18:31:41 <roshi> dvd size or https://bugzilla.redhat.com/show_bug.cgi?id=1016842?
18:32:06 <roshi> or am I missing what "this one" is?
18:32:17 * roshi has missed plenty before :p
18:32:34 <pschindl> I thought that we are talking about Live oversized :)
18:32:40 <roshi> me too
18:32:41 <roshi> good
18:32:50 <roshi> it's been 10 min since Viking-Ice asked who was left
18:33:14 <roshi> if we don't have enough with us three, I suppose it's going to have to wait until after fesco
18:33:30 * roshi has to leave in a couple minutes
18:34:23 <Viking-Ice> I needed to fix some space issue for cargo company somewhere in the world on one of their serves so I'm currently just 50/50 in
18:35:47 <roshi> no worries
18:36:13 <roshi> not sure what the protocol is, but I move we push these last two until after fesco when people come back
18:36:17 <roshi> or something
18:36:35 <pschindl> I guess it is the best solution for now :)
18:37:41 <roshi> well, I'm going to depart for now then
18:41:23 <tflink> ok, the part i needed to participate in is done
18:41:28 <tflink> sorry for the delay
18:43:07 <tflink> is anyone still paying attention?
18:43:33 <tflink> #action dan408 to follow up with the gnome folks on getting the desktop spin under size
18:43:41 <tflink> dan408-: you were willing to do that, no?
18:47:27 <tflink> dan408-: let me know if I got it wrong and we'll get someone else to poke the gnome folks
18:47:35 <tflink> I suspect that not much is needed, though
18:47:42 <tflink> moving on ...
18:47:49 <tflink> #topic (1016842) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool
18:47:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016842
18:47:55 <tflink> #info Accepted Blocker, python-blivet, ASSIGNED
18:49:20 <tflink> bah, this is a rhel7 bug
18:49:31 <tflink> #info this is not actually a blocker, clone artifact
18:50:42 <pschindl> I agree. So there is only one left :)
18:53:41 <Viking-Ice> tflink, how did the meeting end, did fesco grant us extra time if so how much?
18:54:22 <tflink> Viking-Ice: 1 extra month for now, will revisit in january
18:54:40 <Viking-Ice> for f21 ?
18:54:42 <Viking-Ice> we are fucked
18:54:53 <Viking-Ice> but let's carry on
18:54:55 <jreznik> tflink: I still don't get how you count it
18:55:24 <tflink> jreznik: if you go from what we've usually done in the past, branch would be around feb 1
18:55:36 <jreznik> for f21?
18:55:37 <tflink> jreznik: 1 extra month puts the branch date around mar 1
18:55:40 <tflink> yeah
18:55:45 <tflink> ignoring any fedora.next stuff
18:56:03 <Viking-Ice> well qa wont be with multiple products until we sort out the anaconda stuff
18:56:13 <Viking-Ice> wont be dealing with
18:56:15 <jreznik> I'm getting lost... as I understand it - most people want f21 to be fedora.next
18:56:20 <tflink> can we hold this conversation off til later?
18:56:24 <jreznik> sorry
18:56:25 <Viking-Ice> yeah sure
18:56:30 <Viking-Ice> let's get this meeting over
18:56:36 <tflink> I want to get through this last bug and finish the meeting
18:56:52 <tflink> #topic (1013800) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool
18:56:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013800
18:56:57 <tflink> #info Accepted Blocker, python-blivet, ASSIGNED
18:57:40 <tflink> #info there is a fix available per c#7 but another issue was found during development
18:58:07 <Viking-Ice> has David spoken with the lvm team?
18:58:11 <tflink> #info currently waiting on a fix for this new issue
18:58:20 <tflink> no idea
18:58:47 <jreznik> let's ask in bz
18:59:09 <tflink> #info there was supposed to be more conversation with lvm folks by this past monday, no update since then - ask for more information in bug
18:59:12 <tflink> anything else for this?
18:59:14 <tflink> this bug
18:59:28 <pschindl> not from me
18:59:38 <tflink> if not, then it's time for ...
18:59:42 <tflink> #topic Open Floor
18:59:53 <tflink> Any other topics or issues to bring up in this meeting?
18:59:59 <Viking-Ice> just put the fuse on
19:00:16 <tflink> works for me, I don't really want to prolong the meeting :)
19:00:26 * tflink sets fuse for some non-zero amount of time
19:00:33 * jreznik should quit now... see you guys
19:00:57 <tflink> #info next blocker review meeting will be on 2013-10-16 @ 16:00 UTC
19:01:23 <tflink> #info if needed, another meeting will be scheduled for 2013-10-14
19:01:30 * tflink will send out minutes shortly
19:01:36 <tflink> Thanks for coming, everyone!
19:01:38 <tflink> #endmeeting