17:01:32 <adamw> #startmeeting Fedora 20 Blocker Review 4.5
17:01:32 <zodbot> Meeting started Mon Dec  9 17:01:32 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:37 * Viking-Ice goes outside before meeting for "fresh air"
17:01:38 <adamw> #meetingname F20-blocker-review-4.5
17:01:38 <zodbot> The meeting name has been set to 'f20-blocker-review-4.5'
17:01:45 <adamw> #topic Roll call
17:01:48 <adamw> ahoyhoy folks
17:01:51 * pschindl is here
17:02:01 * mkrizek is here
17:02:03 * nirik is lurking here too
17:02:03 * pwhalen is here
17:02:06 * greenlion is here
17:02:15 * cmurf is here and HUNGRY
17:02:25 * roshi is here
17:02:45 * kparal here
17:03:03 <adamw> nice turnout, thanks!
17:04:06 <adamw> #topic Introduction
17:04:07 <adamw> Why are we here?
17:04:07 <adamw> #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:07 <adamw> #info We'll be following the process outlined at:
17:04:08 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:04:08 <adamw> #info The bugs up for review today are available at:
17:04:17 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:04:18 <adamw> #info The criteria for release blocking bugs can be found at:
17:04:18 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
17:04:18 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
17:04:20 <adamw> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
17:04:30 <adamw> #info 9 Proposed Blockers
17:04:30 <adamw> #info 16 Accepted Blockers
17:04:30 <adamw> #info 7 Proposed Freeze Exceptions
17:04:30 <adamw> #info 13 Accepted Freeze Exceptions
17:04:37 <adamw> who wants to secretarialize?
17:04:49 * roshi has it
17:04:56 <adamw> #info roshi will secretarialize, thanks
17:05:06 <adamw> so, jumping right into the proposed blockers...
17:05:09 <adamw> #topic (1008732) LUKSError: luks device not configured
17:05:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008732
17:05:09 <adamw> #info Proposed Blocker, anaconda, NEW
17:06:12 <cmurf> to me it seems like an edge case to open the LUKS volume outside the installer, but then also to have interrupted the installation process just prior to that
17:07:01 <adamw> right
17:07:07 <cmurf> When creating a default encrypted install from DVD, then force a reboot after LUKS volume is created, but while packages are being installed; subsequent guided or custom installs succeed for me.
17:07:10 <kparal> it's not really, I used it countless times - use Live, do something with the disk (back up or something) and then install a new system
17:07:18 <adamw> seems like you hit this if you activate a LUKS volume and subsequently try to remove it with anaconda, all in the same boot some way or another
17:07:22 <cmurf> So it's not like the LUKS volume is busted and then anaconda can't handle that.
17:07:38 <adamw> i believe anaconda have stated before that they consider anything beyond 'boot the live image and run anaconda immediately' out of scope
17:07:56 <cmurf> Right, with a live environment, it's possible to make it unstable/unknowablel for the installer to deal with certain things.
17:08:23 <cmurf> So I'm a -1, I think it's  even an edge case for conditional blocker.
17:08:28 <adamw> this seems like one where it would be reasonable to fix anaconda - it seems sensible to try and deactivate/unmount things before removing them - but possibly not a blocker
17:08:32 <cmurf> and edge of an edge
17:08:35 <greenlion> but it shouldn't crash if it can't handle it, I think
17:08:43 <nirik> -1/+1 (but we are getting really late for FE)
17:09:06 <kparal> adamw: in that case we should not have anaconda on live at all, that's just stupid
17:09:10 <adamw> greenlion: anaconda doesn't really look at crashing as always being a bad thing; the design is kind of that if it's going to get into an unknown state, it *ought* to crash
17:09:10 <roshi> -1 from what I can see
17:09:27 <adamw> because that removes the danger of it doing something unintentionally bad to your data, and also provides a good mechanism to report the problem
17:09:28 <cmurf> How do we even stop the installer once it's started? Can it be quit normally in the live environment?
17:09:41 <adamw> sure, you can alt-f4 it, it's just an app fundamentally
17:09:58 <cmurf> Is that a graceful quit though?
17:10:04 <adamw> iunno.
17:10:18 <kparal> you can alt-f4, but anaconda process still runs
17:10:18 <greenlion> it shouldn't simply quit by alt-f4 without confirmation, btw
17:10:23 <adamw> i'm probably -1 on this, unless it can be reproduced without fiddling around before running anaconda...
17:10:34 <kparal> greenlion: reported a long time ago, they know about it
17:10:56 <greenlion> kparal, I see
17:11:13 <kparal> another use case - create the layout in advance using gparted and other tools, then run anaconda and install
17:11:36 <kparal> this might affect a lot of people, given how disappointed they are with their partitioning approach
17:11:40 <cmurf> based on the anaconda-tb, anaconda is really confused
17:11:45 <kparal> (including me)
17:12:18 <cmurf> it filters out the LUKS device opened outside of the installer
17:12:43 <cmurf> and then can't find vg "fedora" presumably because it's filtered out the luks device it's on
17:12:51 <cmurf> then says no devices or media present
17:12:52 <Viking-Ice> the most recent reproducible is outside the installer based on c29
17:12:53 <cmurf> then puks
17:12:56 <adamw> kparal: that's a reasonable consideration, although you can at least just reboot and try again
17:12:57 <Viking-Ice> -1 blocker
17:13:06 <pwhalen> -1
17:13:29 <Viking-Ice> -1 fe as well
17:13:30 <dan408_> hi
17:13:33 <adamw> hi dan
17:13:37 <dan408_> sorry for being late
17:13:41 <adamw> so that's a lot of -1s
17:13:45 <cmurf> i'm also -1 FE, i just don't want to bring in fragile fixes at all
17:13:45 <dan408_> on what?
17:13:47 <kparal> how hard would it be for anaconda to detect any open luks partitions during start and say "no, you can't have anything opened/mounted in advanced, please close it and run anaconda again"?
17:13:53 <dan408_> which bug are we talking about?
17:13:58 <dan408_> oh
17:14:01 * dan408_ looks at topic
17:14:13 <dan408_> .bug 1008732
17:14:14 <adamw> kparal: it kind of opens a pandora's box, because if we do that, why don't we detect $SOME_OTHER_STATE_ANACONDA_CANT_HANDLE too?
17:14:25 <adamw> which is, you know, an infinite set, probably
17:14:27 <zodbot> dan408_: Bug 1008732 LUKSError: luks device not configured - https://bugzilla.redhat.com/show_bug.cgi?id=1008732
17:14:28 <kparal> so currently it crashes without any info
17:14:38 <kparal> or hint
17:14:49 <cmurf> For me the rest of this release, FE means "fragility encouragement"
17:14:54 <adamw> hah, nice.
17:14:57 <roshi> lol
17:15:22 <Viking-Ice> well let's see how invasive those FE can be before completely dismissing them
17:15:43 <cmurf> Viking-Ice yeah that's a high burden of testing proofs really
17:16:04 <cmurf> that's why i'm generally opposed to FE for final, especially late
17:16:14 <cmurf> it's either a bad enough bug to block, or it's not
17:16:20 <adamw> proposed #agreed 1008732 is rejected as a blocker as it requires you to fiddle around with partitions prior to running anaconda, and anaconda team is on record as not being willing to block on that kind of case
17:16:26 * kparal is deeply unsatisfied with all of this. but it seems that everyone is -1, so...
17:16:30 <dan408_> I think this should remain a blocker until someone can prove that it's fixed
17:16:35 <dan408_> nack
17:16:45 <adamw> dan408_: we know it's broken, and we know what circumstances it's broken in.
17:16:53 <adamw> dan408_: how does the agreement not reflect the discussion and voting?
17:16:58 <Viking-Ice> ack
17:17:01 <cmurf> ack
17:17:04 <nirik> ack
17:17:05 <dan408_> so does that not violate the criterion of not having the installer crash?
17:17:14 <adamw> there isn't a criterion of not having the installer crash.
17:17:19 <dan408_> okay
17:17:20 <dan408_> ack
17:17:25 <dan408_> sorry i walked into that one late
17:17:26 <adamw> if there was we'd never ship anything. ;)
17:17:33 <dan408_> no comment..
17:18:05 * adamw thinks some ideas breed in the air; lots of people seem to think there's an 'anaconda should never crash for any reason ever' criterion, but there isn't.
17:18:34 <adamw> #agreed 1008732 is rejected as a blocker as it requires you to fiddle around with partitions prior to running anaconda, and anaconda team is on record as not being willing to block on that kind of case
17:18:45 <adamw> roshi: we probably want to commonbugs it at least
17:18:46 <pwhalen> ack
17:18:47 <dan408_> there must be something similar to it
17:18:54 <roshi> that works
17:19:02 <dan408_> ill go reread the criterion later
17:19:14 <adamw> dan408_: there's the wording about 'reject invalid operations without crashing', which i obviously need to revise as it keeps getting interpreted very loosely...
17:19:17 <cmurf> i think it's a 'shouldn't crash when there's an obviously invalid aspect to the layout (partition map, LV metadata, raid metadata, etc.)
17:19:24 <dan408_> adamw: yeah, that
17:19:33 <dan408_> there's also a
17:19:45 <dan408_> "the installer must be able to install fedora successfully"
17:19:47 <dan408_> LOL
17:20:08 <adamw> #topic (1038847) SizeNotPositiveError: spec= param must be >=0
17:20:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1038847
17:20:08 <adamw> #info Proposed Blocker, anaconda, NEW
17:20:52 <cmurf> looks like kparal reproduced it
17:20:56 <dan408_> +1
17:20:57 <Viking-Ice> kparal, did you actually reproduce this one?
17:21:25 <Viking-Ice> ( it sounds like you just tried to reproduce it not that you actually could )
17:21:53 <cmurf> comment 13
17:21:54 <kparal> Viking-Ice: you see crash, I reproduced it
17:21:55 <adamw> Viking-Ice: the fact that the comment's attached to a crash with the same error message suggests 'yes' :)
17:22:03 <Viking-Ice> +1 blocker
17:22:06 <adamw> well, seems hard to be -1 on this
17:22:13 <kparal> +1
17:22:17 <adamw> +1
17:22:19 <nirik> yeah, +1. ;(
17:22:23 <cmurf> i'm looking at the tb and not finding what it's imploding on
17:22:42 <cmurf> but this is all really basic stuff Manual Partitioning allows, and then crashes
17:22:53 <cmurf> so yeah +1
17:22:53 <pwhalen> +1
17:24:35 <adamw> proposed #agreed #1038847 is accepted as a blocker per "When using the custom partitioning flow, the installer must be able to: ...      Reject or disallow invalid disk and volume configurations without crashing."
17:24:37 <Viking-Ice> ack
17:24:39 <cmurf> ack
17:24:39 <adamw> #chair roshi
17:24:39 <zodbot> Current chairs: adamw roshi
17:25:07 <nirik> ack
17:25:09 <pwhalen> ack
17:25:25 <kparal> ack
17:25:55 <pschindl> ack
17:26:14 <adamw> #agreed #1038847 is accepted as a blocker per "When using the custom partitioning flow, the installer must be able to: ...      Reject or disallow invalid disk and volume configurations without crashing."
17:26:20 <adamw> #topic (1038969) DeviceCreateError: ('lvcreate failed for fedora/swap: running lvm lvcreate -L 819m -n swap fedora failed', 'fedora-swap')
17:26:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1038969
17:26:20 <adamw> #info Proposed Blocker, anaconda, NEW
17:27:29 <Viking-Ice> looks like a valid workflow +1
17:27:33 <Viking-Ice> blocker
17:27:50 <cmurf> yea i'm +1 at this point, still looking at the tb
17:27:57 <kparal> yes, no rocket science, just 2 encrypted VGs
17:28:10 <Viking-Ice> " insufficient free space"
17:28:13 <cmurf> which is valid but a bit more rare
17:28:18 <Viking-Ice> any user can run into this in custom
17:28:20 <kparal> (I'm actually very unclear if they get the same password or not, I was asked just once)
17:28:29 <ignatenkobrain> hi
17:28:46 <greenlion> kparal, should be same I think
17:28:49 <adamw> i suspect anaconda doesn't really account for the possibility...
17:29:12 <greenlion> looks like some rounding issues
17:29:16 <cmurf> it looks like it just overcommitted a VG for some reason
17:29:37 <cmurf> ends up with negative values in one of the VGs
17:29:45 <cmurf> it might have gotten confused which VG to suck the LV out of
17:30:02 <kparal> might be interesting if it also crashed if the second VG is not encrypted
17:30:03 <cmurf> or better phrasing is which VG to make the LV in
17:30:04 <kparal> would make more sense
17:30:05 <Viking-Ice> votes people
17:30:09 <cmurf> +1
17:30:34 <adamw> guess i'm +1
17:30:51 * kparal tests with second unencrypted VG
17:31:02 <adamw> proposed #agreed #1038969 is accepted as a blocker per criterion "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:31:33 <ignatenkobrain> ack
17:31:43 <Viking-Ice> ack
17:32:08 <pschindl> ack
17:32:23 <adamw> it seems like we can't break this cycle of finding more and more blockers in partitioning the longer we have to test :/
17:32:34 <adamw> more fuel for the 'partitioning is over-reaching' theory, i guess
17:32:40 <cmurf> ack
17:32:45 <adamw> #agreed #1038969 is accepted as a blocker per criterion "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:33:10 <adamw> #topic (1039288) GB in interface is 1000*1024*1024 bytes which is neither binary nor decimal
17:33:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039288
17:33:10 <adamw> #info Proposed Blocker, anaconda, NEW
17:33:21 <kparal> (crashed as well, with second unencrypted VG)
17:33:29 <cmurf> adamw: Anaconda Super Duper Partitioning Utility
17:33:33 <cmurf> split it out
17:33:37 <Viking-Ice> I've said it ones and I'll saying it again we are having way to many installer bugs in every cycle then what should be considered healthy ( let alone this late int the cycle )
17:33:39 <cmurf> -1 on this bug
17:34:04 <adamw> -1, probably -1 FE at this point too, let's not break more stuff
17:34:12 <cmurf> Viking-Ice: yes. all of this has happened before and will happen again.
17:34:14 <Viking-Ice> cosmetic issue -1
17:34:21 <cmurf> -1FE
17:34:21 <adamw> if this is correct though i'm amazed no-one noticed before...
17:34:22 <Viking-Ice> aswell as -1 fe
17:34:34 <cmurf> dlehman was complaining about this stuff last week vociferously
17:34:39 <pwhalen> -1
17:34:48 <Viking-Ice> adamw, or nobody cared to much about the few bits in difference ;)
17:35:09 <adamw> cmurf: when you say 'this stuff'?
17:35:47 <adamw> proposed #agreed #1039288 is rejected as a blocker, if the report is accurate this obviously ought to be fixed, but doesn't have any consequences significant enough to violate any criteria
17:35:58 <adamw> oh, patch
17:35:58 <pwhalen> ack
17:36:02 <Viking-Ice> aack
17:36:06 <cmurf> ack
17:36:14 <adamw> proposed #agreed #1039288 is rejected as a blocker, if the report is accurate this obviously ought to be fixed, but doesn't have any consequences significant enough to violate any criteria. also rejected as FE as it's too late to change something like this which could break other things
17:36:47 <Viking-Ice> ack again
17:37:30 <kparal> ack
17:37:47 <adamw> #agreed #1039288 is rejected as a blocker, if the report is accurate this obviously ought to be fixed, but doesn't have any consequences significant enough to violate any criteria. also rejected as FE as it's too late to change something like this which could break other things
17:38:06 <adamw> #topic (1039292) Assigning partition to disk with not enough free space causes custom partition interface to become unusable
17:38:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039292
17:38:06 <adamw> #info Proposed Blocker, anaconda, NEW
17:38:22 <adamw> hey look, more borkage
17:38:41 <adamw> this one i can confirm based on my iscsi test, i saw the same 'reqX' weirdness
17:38:51 <cmurf> interesting this hasn't been more widespread
17:39:18 <greenlion> I've seen it behave similar in some other situation too
17:40:08 <Viking-Ice> +1 blocker
17:40:25 <kparal> it seems we will release in March at earliest
17:40:47 <Viking-Ice> screw santa prepare for easter ;)
17:40:51 <cmurf> kparal: my wager is on Jan 20
17:41:02 <kparal> at least anaconda devs won't be bored during christmas
17:41:06 <cmurf> and even that is a bitter pill
17:41:16 <kparal> this is pretty basic use case, +1
17:41:45 * jreznik is finally here - crisis here, crisis there - our neighbor above flooded us from the bathroom :(((
17:42:12 <cmurf> jreznik: that always sucks
17:42:14 <roshi> +1
17:42:17 <pwhalen> +1
17:42:23 <cmurf> +1
17:42:56 * adamw playing with this in a VM
17:43:12 <Viking-Ice> votes still
17:43:26 <adamw> it doesn't seem to happen in absolutely all cases you assign a partition to a disk without sufficient space, i just did it by playing with /boot's size in a 2-disk LVM custom part install and got a yellow error bar, not this bug
17:43:38 <dan408_> +1
17:44:03 <greenlion> adamw, probably this happens with auto-created partitions only?
17:44:04 <adamw> but it's consistently reproducible per the description, so...i guess still +1
17:44:10 <Viking-Ice> still a valid workflow Alexey did + we have enough votes
17:44:16 <cmurf> if we have a reasonable, even if minority, use case, where the problem happens often, then block
17:44:18 <cmurf> otherwise -1
17:44:22 <adamw> greenlion: /boot is auto-created in that case, but it may happen only with the *size* being set by auto-creation (i.e. doesn't happen if you manually change the size)
17:44:42 <adamw> Viking-Ice: yeah, sorry, was just slow as i was fiddling with the bug
17:44:56 <adamw> proposed #agreed #1039292 is accepted as a blocker per criterion "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:44:59 <Viking-Ice> ack
17:45:04 <pschindl> ack
17:45:07 <cmurf> ack
17:45:23 <adamw> #agreed #1039292 is accepted as a blocker per criterion "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:31 <adamw> #topic (1039491) ValueError: new size same as old size
17:45:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039491
17:45:31 <adamw> #info Proposed Blocker, anaconda, NEW
17:46:13 <greenlion> i'm unable to reproduce this right way...
17:46:22 <greenlion> so this might need to be delay till next meeting
17:46:25 <cmurf> sounds like an old bug
17:46:51 <Viking-Ice> -1 blocker -1 fe
17:47:13 <cmurf> punt
17:47:13 <greenlion> Viking-Ice, why?
17:47:18 <adamw> -1 or punt, either way, can only consider it with a reproducer
17:47:25 <cmurf> if it's reproducible it's probably a blocker
17:47:37 <cmurf> so it's less cluttered to come back to it weds
17:48:32 <Viking-Ice> greenlion, easily workaround able ( by simple deleting the filled partition ) and not easily reproducible
17:48:32 <pwhalen> punt for now
17:50:16 <adamw> any more votes?
17:50:27 * adamw votes punt, so that's 3 punt, 1 -1
17:50:41 <roshi> -1
17:50:44 <Viking-Ice> I dont think this one is punt worthy hence still -1
17:51:02 <adamw> oh good, so 3/2
17:51:18 <kparal> the effect is the same, basically
17:51:20 <kparal> punt
17:51:42 <Viking-Ice> one get's it off our radar the other one keeps it on iot
17:51:47 <Viking-Ice> mean it
17:52:02 <jreznik> let's keep it on radar, at least for now
17:52:04 <Viking-Ice> but fine let's move passed it
17:52:16 <Viking-Ice> and punt-it then
17:52:19 * adamw tosses a coin
17:52:48 <Viking-Ice> you got enough punters to move to the next one
17:52:59 <adamw> proposed #agreed insufficient information available on #1039491 for now, it was not immediately reproducible: delaying decision until wednesday, greenlion will try to come up with a reliable reproducer
17:53:05 <cmurf> got enough punters for a ballgame of only punting
17:53:09 <kparal> ack
17:53:13 <cmurf> ack
17:53:15 <greenlion> ack
17:53:20 <adamw> #agreed insufficient information available on #1039491 for now, it was not immediately reproducible: delaying decision until wednesday, greenlion will try to come up with a reliable reproducer
17:53:37 <adamw> #topic (1035801) [abrt] control-center-3.10.2-2.fc20: _g_log_abort: Process /usr/bin/gnome-control-center was killed by signal 6 (SIGABRT)
17:53:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035801
17:53:37 <adamw> #info Proposed Blocker, control-center, NEW
17:53:41 <adamw> hey look, it's not anaconda!
17:53:59 <Viking-Ice> wait what what do we do now ( panic )
17:54:01 <Viking-Ice> lol
17:54:06 <cmurf> 8-)
17:54:15 <adamw> this does seem pretty easy to hit
17:54:18 <cmurf> oops, what's the bug eyed emoticon
17:54:35 <adamw> 'basic functionality' is a pretty subjective definition for something like control-center, but that's kinda unavoidable
17:54:40 <greenlion> .bug 1027365
17:54:45 <zodbot> greenlion: Bug 1027365 [abrt] bluez-5.10-2.fc20: _IO_default_xsputn: Process /usr/libexec/bluetooth/bluetoothd was killed by signal 11 (SIGSEGV) - https://bugzilla.redhat.com/show_bug.cgi?id=1027365
17:54:53 <adamw> this does seem plausible to hit on lives as well
17:54:55 <greenlion> are these bugs connected?
17:55:54 <kparal> -1/+1
17:56:36 <Viking-Ice> this is fixable via update right ( i dont think it's common that people disable sharing on live's )
17:56:40 <Viking-Ice> -1 -1
17:56:46 <nirik> -1/+1
17:56:48 <jreznik> -1/+1
17:56:55 <roshi> -1/+1
17:56:59 <greenlion> -1/+1
17:57:03 <pwhalen> -1/+1
17:57:09 <kparal> copycats
17:57:09 <cmurf> -1/-!
17:57:12 <adamw> greenlion: well, depends what you mean by 'connected', but i don't think they're directly related, no.
17:57:21 <adamw> the one in g-c-c looks like just a straight-up error in the g-c-c code, nothing more.
17:57:39 <adamw> so i guess people are -1 on the basis that this is beyond 'basic functionality'?
17:57:40 <Viking-Ice> well the fix seems simple enough +1 fe
17:57:50 <greenlion> if the fix works
17:58:11 <Viking-Ice> greenlion, more concerned if it breaks something else ;)
17:58:23 <greenlion> Viking-Ice, good point :)
17:58:24 <Viking-Ice> adamw, could be fixed via 0day  update
17:58:37 <adamw> proposed #agreed #1035801 is rejected as a blocker, considered beyond 'basic functionality', but accepted as an FE as the fix looks straightforward and would avoid a potential crasher bug in lives
17:58:41 <jreznik> well, bluez5 is pretty broken :(
17:58:42 <Viking-Ice> ack
17:58:46 <jreznik> ack
17:59:03 <nirik> ack
17:59:04 <greenlion> ack
17:59:07 <kparal> ack
17:59:10 <pschindl> ack
17:59:16 <adamw> #agreed #1035801 is rejected as a blocker, considered beyond 'basic functionality', but accepted as an FE as the fix looks straightforward and would avoid a potential crasher bug in lives
17:59:25 <adamw> #topic (1025072) libstdc++/58800 (the bug, not the fix) just got backported to Fedora 19 and 20
17:59:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1025072
17:59:25 <adamw> #info Proposed Blocker, gcc, NEW
17:59:42 <adamw> this one is...kind of icky, we're still trying to evaluate the practical impact
17:59:54 <Viking-Ice> lol the bug got backported
18:00:01 <adamw> broadly, anything built with gcc 4.8.2-1 which called a specific function may contain a crasher bug
18:00:18 <nirik> in a specific way possibly
18:00:20 <cmurf> yes this is an odd duck that the fix was delayed this long
18:00:20 <adamw> Viking-Ice: not exactly, we just took upstream's latest 'bugfix' release, which broke stuff.
18:00:38 <Viking-Ice> this looks serious enough to block for
18:00:41 <adamw> (it's broken between upstream 4.8.1 and 4.8.2)
18:00:46 <adamw> i'd say potentially it is
18:00:49 <Viking-Ice> +1
18:01:02 <nirik> needs more info
18:01:04 <adamw> but i'd really like to know exactly what packages containing affected functions were built with the affected gcc
18:01:14 <adamw> so far we have a list of all packages built with the affected gcc
18:01:17 <Viking-Ice> delaying this will not rebuild those packages in time
18:01:19 <nirik> I couldn't get eu-readelf to do anything here.
18:01:43 <adamw> Viking-Ice: if it turns out to be five packages we can rebuild 'em in a couple of hours.
18:01:48 <greenlion> adamw, how many packages?
18:02:04 <adamw> it would also be nice if we could construct a bugzilla search to see if we're actually seeing crasher bugs caused by this, apparently it ought to be possible
18:02:06 <nirik> so, we should try and get more info from jakub.
18:02:09 <jreznik> I think we can afford one small mass rebuild in schedule (ok, not joking anymore, be serious)
18:02:16 <adamw> greenlion: 137: http://paste.fedoraproject.org/59955/38650848/
18:02:23 <Viking-Ice> adamw, if we punt this then we punt the rebuild as well ( and this seems serious enough to take care of a.s.a.p )
18:02:23 <adamw> but again, we don't know which of those contain affected code
18:02:43 <nirik> right, could be none of them, or none that affect release critera.
18:02:49 <nirik> we just don't know
18:03:02 <jreznik> yep
18:03:04 <adamw> Viking-Ice: not really: a) we can't do the rebuild till we know what packages actually contain affected code, b) we can do rebuilds without the bug being a blocker, we just can't pull them through freeze unless it is
18:03:19 <greenlion> also need to consider packages only on dvd/lives
18:03:39 <adamw> well, the ones we'd mainly be worried about are critpath packages
18:03:42 <adamw> which should all be on there
18:03:57 <Viking-Ice> obviously we need to punt if the plan is to identify
18:04:04 <Viking-Ice> but if we slip anyway...
18:04:14 <adamw> :/
18:04:37 <Viking-Ice> I'm just amazed how long it took us to notice htis
18:04:38 <Viking-Ice> mean this
18:04:50 <nirik> which makes me think it's not that serious. ;)
18:05:01 <adamw> proposed #agreed not yet sufficient information on #1025072: we have a list of all packages built with affected gcc, but we do not yet know which contain the affected function(s). we will try to come up with a precise list and then re-evaluate
18:05:17 <adamw> nirik: right, that's why i didn't want to go too nuts with the awooga
18:05:20 <kparal> ack
18:05:25 <Viking-Ice> ack
18:05:25 <greenlion> ack
18:05:27 <nirik> ack
18:05:29 <Viking-Ice> nirik, right we are like the poster child for gcc experiments
18:05:34 <roshi> ack
18:05:43 <adamw> but otoh, if 100 crashes are caused by the same bug but aren't really obviously related, it's entirely plausible that we don't spot it
18:05:54 <jreznik> ack
18:05:58 <adamw> with bugzappers dormant, no-one's really looking at the whole firehose of bugs as they come in
18:05:59 <cmurf> right, how does this manifest?
18:06:01 <nirik> adamw: we could possibly ping retrace folks too... they might be able to do a search?
18:06:13 <Viking-Ice> adamw, bugzapper being dead
18:06:18 <Viking-Ice> not dormant
18:06:25 <adamw> cmurf: the issue's somewhat over my head, but it sounds like it manifests by something crashing; i'm not sure how obvious the underlying cause would be to a non-expert
18:06:31 <nirik> cmurf: crash in a inline function.
18:06:43 <nirik> __unguarded_partition_pivot
18:06:45 <adamw> #agreed not yet sufficient information on #1025072: we have a list of all packages built with affected gcc, but we do not yet know which contain the affected function(s). we will try to come up with a precise list and then re-evaluate
18:06:53 <cmurf> mmm
18:07:11 <adamw> google "__unguarded_partition_pivot site:bugzilla.redhat.com" returns only this bug.
18:07:37 <cmurf> but i'm not sure google spiders find attachment content
18:07:40 <adamw> but yeah, we'll look at it.
18:07:41 <cmurf> like in a coredump file
18:07:42 <adamw> cmurf: yeah.
18:07:49 <nirik> it's also likely it's only that inline function when called from a specific other one... so even smaller.
18:07:58 <adamw> i'd think it'd be in the bug description, but possibly not.
18:08:10 <adamw> anyhow, moving on
18:08:18 <adamw> #topic (1038109) [ms] typo in territory and locale for Malay language (causes error when selecting Malay in the language selection screen in Anaconda)
18:08:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1038109
18:08:18 <adamw> #info Proposed Blocker, langtable, ON_QA
18:08:26 <Viking-Ice> hey adamw area of expertise ;)
18:08:37 <adamw> heh
18:08:46 <adamw> i'm at least +1 FE
18:08:48 <Viking-Ice> you signed up to become master locale ;)
18:08:58 <adamw> we really oughtn't crash when someone picks a language that's right there in our list
18:09:06 <Viking-Ice> +1 blocker
18:09:09 <nirik> +1 FE for sure...
18:09:27 <Viking-Ice> selecting language is basic stuff
18:09:27 <cmurf> +1 blocker because it's a crash on language selection, not adorable or fuzzy
18:09:36 <kparal> +1
18:09:38 <adamw> yeah, let's just say +1
18:09:43 <pschindl> +1
18:09:46 <mkrizek> +1
18:09:54 * nirik isn't sure he would block on this if it was the last bug, but sure, ok
18:10:05 <greenlion> +1
18:10:26 <roshi> +1
18:10:28 <adamw> proposed #agreed #1038109 is accepted as a blocker as a conditional violation of criterion "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." in the case of selecting Malay
18:10:31 <Viking-Ice> ack
18:10:41 <jreznik> ack
18:10:48 <pschindl> ack
18:10:48 <adamw> roshi: that's alpha, for secretary purposes
18:10:52 <adamw> #agreed #1038109 is accepted as a blocker as a conditional violation of criterion "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." in the case of selecting Malay
18:11:07 <adamw> OK, that was all the proposed blockers
18:11:16 <roshi> yeah, I've been appending the such things since you're not putting them in the comment
18:11:16 <cmurf> there is a a new one
18:11:18 <roshi> :P
18:11:28 <cmurf> .bug 1039662
18:11:33 <zodbot> cmurf: Bug 1039662 hang on launch when existing installation is LVM thin provisioning on LUKS - https://bugzilla.redhat.com/show_bug.cgi?id=1039662
18:11:45 <cmurf> punt on it
18:12:24 <Viking-Ice> did we retract the whole feature-ism of lvm thinp
18:12:36 <Viking-Ice> and just deem it experiemental thus not blocker
18:12:38 <cmurf> seriously just punt because i'm finding it difficult to reproduce
18:12:49 <cmurf> it was 100% reproducible with a particular qcow2 file
18:12:54 <nirik> seems kinda corner casy
18:12:54 <adamw> cmurf: ah, thanks
18:12:57 <Viking-Ice> punt it is
18:12:59 <cmurf> and i deleted that (dumbass move)
18:13:08 <cmurf> and now can't reproduce with a new qcow2
18:13:13 <adamw> #topic (1039662) hang on launch when existing installation is LVM thin provisioning on LUKS
18:13:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039662
18:13:25 <cmurf> so this could be one of those situations where you get a real world problem because in the real world people don't have clean disks
18:13:34 <cmurf> it's like a multilayered bug of some sort
18:13:46 <cmurf> so i should have kept that qcow2 file
18:13:59 * kparal can try real quick
18:14:12 <adamw> cmurf: :/
18:14:13 <cmurf> the original qcow2 had probably a dozen installs on it
18:14:16 <adamw> if it's not reproducible, punt or -1
18:14:33 <Viking-Ice> just punt it unpropose if not reproducable
18:14:36 <cmurf> it is reproducible on that original qcow2, 100% of the time anaconda would hang
18:14:42 <cmurf> so there is a bug here
18:14:50 <Viking-Ice> or a faulty image
18:14:52 <cmurf> i just can't recreate the qcow2 that causes the problem
18:15:10 <jreznik> so it could be limited to that particulary broken image
18:15:17 <cmurf> Viking-Ice: no because it boots the luks thinp from that qcow2 fine
18:15:18 <kparal> give me a minute, installing
18:15:26 <cmurf> not a broken image, it's bootable
18:15:38 <cmurf> was bootable - before I DELETED it
18:15:56 * cmurf has destroyed evidence of a bug, he should be punished
18:16:15 <cmurf> anyway i say punt maybe i can figure it out and if not we'll nix it weds
18:16:15 <adamw> .fire cmurf
18:16:15 <zodbot> adamw fires cmurf
18:16:18 <Viking-Ice> squashing a bug by deleting it is as valid method as any lol
18:16:25 <kparal> post-install
18:16:26 <cmurf> no no firing me would be a blessing
18:16:45 <cmurf> assign me filling out the whole next TC6 matrix by myself
18:16:54 <cmurf> that's punishment
18:16:58 <adamw> proposed #agreed #1039662 looks like there is a real problem but cmurf lost the image that reproduces it and cannot immediately recreate it; we will delay the determination until we can say whether it's plausible to block on the bug (can reproduce it again, or tell what's going on from the trace)
18:17:06 <cmurf> rofl
18:17:08 <cmurf> he lost the image
18:17:09 <cmurf> haha
18:17:16 <adamw> "lost"
18:17:24 <cmurf> willful destruction
18:17:25 <kparal> rebooting
18:17:35 <Viking-Ice> ack
18:17:58 <kparal> anaconda starts for me
18:18:12 <kparal> can't reproduce
18:18:25 <pschindl> -1
18:18:52 <Viking-Ice> -1
18:18:57 <Viking-Ice> let's move pass this one
18:19:06 <cmurf> yes please
18:19:17 <adamw> well, i dunno if we're punting or rejecting
18:19:21 <cmurf> punting
18:19:23 <cmurf> ack
18:19:26 <kparal> ack
18:19:33 <roshi> ack
18:19:38 <cmurf> and btw there is no tb generated
18:19:40 * nirik is ok rejecting based on no reproducer, but ok, sure.
18:19:41 <cmurf> anaconda just hangs
18:19:44 <jreznik> ack to reject or punt?
18:19:48 <cmurf> ack to punt
18:20:01 <adamw> #agreed #1039662 looks like there is a real problem but cmurf lost the image that reproduces it and cannot immediately recreate it; we will delay the determination until we can say whether it's plausible to block on the bug (can reproduce it again, or tell what's going on from the trace)
18:20:05 * jreznik is more to reject after kparal's try
18:20:10 <jreznik> but ok with bot
18:20:11 <jreznik> h
18:20:28 <adamw> do we want to do proposed FEs?
18:20:42 <cmurf> no i'd vote against FE
18:20:44 <cmurf> fragility encouragement
18:20:50 <adamw> some of them are fairly significant bugs that i asked greenlion to downgrade
18:20:52 <cmurf> it's either bad enough to block or not
18:21:01 <Viking-Ice> on to proposed FE
18:21:08 <cmurf> OH
18:21:15 <adamw> e.g. installer crashes if you have an ipv6-only network config...
18:21:16 <cmurf> OH nevermind i'm not paying attention
18:21:23 <cmurf> yes let's review FE's
18:21:30 <adamw> ok, let's go through FEs till people die of boredom
18:21:33 <adamw> #topic (1026079) Crashes with "error: [Errno 101] Network is unreachable" in GeoIP with IPv6-only network connection
18:21:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026079
18:21:34 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
18:21:49 <Viking-Ice> +1 blocker ipv6 not working should be release blocking
18:21:55 <adamw> so...we downgraded this to proposed FE but it is kinda close to blocking
18:22:04 <nirik> note: this is ipv6 _only_
18:22:04 <cmurf> very close
18:22:06 <adamw> i asked a few others to test IPv6 and they said it was fine, but they may have had v6+v4 configs
18:22:18 <cmurf> but then also there are how many ways to configure ipv6?
18:22:40 <cmurf> yeah the tunneling approach vs pure ipv6, etc.
18:22:44 <nirik> I mean, it shouldn't crash, but it can't get any info in that case anyhow. :)
18:22:52 <nirik> also, I don't think we have any criteria for ipv6 only.
18:22:59 <cmurf> right
18:23:00 <adamw> nirik: we don't have specific criteria for networking at all.
18:23:08 <adamw> the criteria are functional, not configuration...y.
18:23:10 <nirik> alright. ;)
18:23:18 <adamw> the function that's broken in this case is...installing. =)
18:23:27 <cmurf> which is not a small problem
18:23:37 <cmurf> but it also seems to be a small population of reproducers
18:23:39 <Viking-Ice> I thought we had evolved to the stage that we did not make difference between ipv4 and ipv6 as in both block
18:23:39 <adamw> just a question of whether we consider the affected configuration(s) significant enough to constitute a blocking violation.
18:23:51 <cmurf> that's my concern
18:23:58 <adamw> Viking-Ice: we were trying to hold that line, yeah, but we kinda slacked off on testing in f19 and f20
18:24:11 <cmurf> do we need more information and to try and get a reproducer to see if this could be more widespread?
18:24:12 <Viking-Ice> "IPv6-only networks are becoming a
18:24:13 <Viking-Ice> configuration sufficiently important that a serious breach of the
18:24:13 <Viking-Ice> criteria in the context of an IPv6-only network is significant enough to
18:24:13 <Viking-Ice> be considered a release blocker, and we accepted the bug as a blocker." this was F17
18:24:24 <greenlion> ipv6-only is probably used for virtual machines by some people
18:24:32 <adamw> and i have to admit i'm not smart enough about ipv6 to grok it entirely
18:24:41 <adamw> is this going to affect 'most' ipv6 configs? enough?
18:24:51 <adamw> Viking-Ice: oh yeah, since f17 then
18:24:56 <cmurf> pff i'm not smart enough to grok ipv4 and ipv6 is not 2x more involved
18:24:56 <nirik> it's only going to affect configs where there is 0 ipv4 address.
18:25:17 <adamw> that i get, but how common is that in The Real World?
18:25:18 <Viking-Ice> I would not be surprised if bunch of clouds are ipv6 only these days
18:25:37 <nirik> it's not been very common on the past, possibly more so now.
18:25:43 <kparal> geoloc=0 fixes the problem?
18:25:52 <adamw> yeah, i recall reading some comment that in some datacenters you can't get ipv4s for all your instances any more
18:25:52 <cmurf> clouds as in internally they are ipv6 only?
18:25:52 <nirik> kparal: not sure, good thing to try. ;)
18:25:52 <adamw> kparal: would also be useful to know
18:26:09 <cmurf> that's an unexpected fix
18:26:10 <Viking-Ice> nirik, well if you exclude Asia not so common might be close to it lol
18:26:14 <adamw> are we sure that it's as simple as 'any ipv6-only config is hit'?
18:26:25 <adamw> or does it have to be specified on the cmdline, as in the report?
18:26:26 <nirik> seems likely to me.
18:26:42 <cmurf> that seems easy to test
18:27:02 <nirik> adamw: thats just a way of making that happen... I expect it would be the same if you didn't provide that arg and were in a ipv6 only env.
18:27:15 <cmurf> "easy" as in post a test case to the test list, ask some ipv6 only people to do that
18:27:21 <Viking-Ice> in anycase votes in I'm +1 for the reason we ought to be blocking for all ipv6 issues these days
18:27:40 <cmurf> well unless it's actually a geoip related bug
18:27:45 <adamw> Viking-Ice: to be clear, you're voting +1 blocker?
18:27:46 <cmurf> if geoloc=0 fixes this, then..
18:28:03 <nirik> it's a bug in anacondas geoip calling code.
18:28:09 <adamw> ok, to avoid confusion: although this is a proposed FE there's some +1 blocker sentiment, so people please vote in "blocker/FE" format
18:28:18 <adamw> or vote for punt, obviously.
18:28:25 <Viking-Ice> adamw, yup
18:28:29 <Viking-Ice> +1 blocker
18:28:31 <cmurf> punt, needinfo
18:28:41 <kparal> -1/+1
18:28:56 <nirik> the geoip.fedoraproject.org host is ipv4 only, so it will never be reachable from a pure ipv6 machine.
18:29:04 <cmurf> hmm
18:29:11 <Viking-Ice> great just great
18:29:38 <cmurf> so maybe that is the issue, anaconda isn't automatically doing geoloc=0 for ipv6 only configurations
18:29:38 <nirik> we could give it ipv6 addresses, but it would then never return any useful data for ipv6 because it doesn't exist.
18:29:53 <adamw> cmurf: it just shouldn't crash if it can't reach the host.
18:29:54 <nirik> so, seems to me yes, anaconda should avoid geoip in the case of ipv6 only
18:30:01 <greenlion> nirik, at least it will tell reply something
18:30:05 <adamw> anyhoo
18:30:14 <adamw> so far we have three different votes, folks :)
18:30:19 <greenlion> -1/+1
18:30:25 <nirik> I guess I am +0.5/+1
18:30:44 <adamw> i'd be -1/+1 if geoloc=0 is a workaround, so far it sounds like this is an unusual enough config that we can document it
18:30:48 <pwhalen> +1 FE
18:30:53 <adamw> if it's not a workaround, possibly more +1/+1
18:30:56 <cmurf> FE wins
18:31:03 <Viking-Ice> let's just make it clear that we do not block on ipv6 for the future then because I dont want us be doing the same questionable dance next release cycle
18:31:04 <nirik> adamw: yeah, me too...
18:31:35 <adamw> Viking-Ice: well, this is more "we don't block on a workaroundable bug in an IPv6-only configuration", while we still believe IPv6-only is a minority pursuit
18:31:42 <jreznik> anyone able to try that workaround?
18:31:43 <adamw> if we think IPv6-only is very common then it changes...
18:31:44 <Viking-Ice> if one votes +1 blocker he become auto +1 FE I would think
18:31:58 <adamw> Viking-Ice: sure, i'm counting that way
18:32:12 <jreznik> +1 fe for sure, more -1 blocker if it's really ipv6 only setup
18:32:27 * adamw not set up for IPv6 testing
18:33:04 * roshi has been meaning to look into setting up ipv6 here as well
18:33:06 <Viking-Ice> adamw, we either block on ipv6 ( and should have completely done that since the day we ran out of ipv4 and arguably sooner ) or we dont. We dont wait unti *we* think the world population as picked up ipv6
18:33:18 <Viking-Ice> btw Asia is more or less ipv6 only
18:33:21 <adamw> proposed #agreed #1026079 is accepted as a freeze exception issue. there is some sentiment that it could be promoted to a blocker if 'geoloc=0' does not work around the issue, we should ask the reporter to check.
18:33:31 <Viking-Ice> ack
18:33:36 <nirik> I can try testing here later today too if I get time.
18:33:38 <nirik> ack
18:33:54 <jreznik> ack
18:33:57 <greenlion> ack
18:34:02 <adamw> Viking-Ice: i hear what you're saying, but i'm not sure it's entirely that simple: do we 'block on IPv4'? i think that in theory if a bug required a sufficiently weird IPv4 configuration to hit it, we might not block on it
18:34:18 <adamw> but yeah, ikwym.
18:34:20 <pschindl> ack
18:34:25 <adamw> #agreed #1026079 is accepted as a freeze exception issue. there is some sentiment that it could be promoted to a blocker if 'geoloc=0' does not work around the issue, we should ask the reporter to check.
18:34:54 <adamw> #topic (1039168) Disallow non-ASCII characters in encryption passwords
18:34:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039168
18:34:55 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
18:35:14 <adamw> i don't know how complex this is to implement, but if it's not too complex, i think it may be worth doing, going on past form
18:35:17 <Viking-Ice> I actually lean towards this one being blocker worthy
18:35:28 <adamw> letting people put non-ascii in encryption passphrases just seems to be letting ourselves in for trouble
18:35:54 <Viking-Ice> consistency in the rescue image is what's missing
18:36:01 <adamw> hell, maybe we should only allow four-arabic-digit PINs. ;)
18:36:04 <kparal> what about languages not having ascii characters?
18:36:23 <cmurf> none of the 2-byte languages have ascii characters
18:36:33 <adamw> kparal: it is a basic tenet that all configurations need to allow you to input ascii characters
18:36:34 <cmurf> and there are single byte languages that also don't use ascii
18:36:37 * nirik thinks this is pretty late for this.
18:36:43 <roshi> we should just require retina scans instead
18:36:44 <cmurf> nirik i agree
18:36:45 <adamw> kparal: if we fail that we already failed
18:36:46 <roshi> use the webcam
18:36:49 <Viking-Ice> if you chose a password ( regardless if it's ascii or not ) you kinda expect being able to use that password when using rescue image
18:36:52 <cmurf> -1 FE
18:36:57 <nirik> "my voice is my password"
18:36:58 <cmurf> deal with this in F21
18:37:04 <roshi> point Viking-Ice
18:37:05 <Viking-Ice> hence I'm +1 blocker here
18:37:07 <adamw> cmurf: are you aware of all the details of input in such languages?
18:37:30 <cmurf> no i'm not which is why i'm in favor of requiring only ascii but not this late
18:37:30 <adamw> cmurf: anyone who uses such a language will expect to have an input configuration that allows them to input ASCII, and in F20, i believe we ensure this
18:37:32 <kparal> shouldn't rather rescue mode allow you to select keymap?
18:37:44 <nirik> I guess we could accept it as a FE, but be very paranoid about it if it's intrusive.
18:37:59 <adamw> kparal: it would be nice if it did, sure, but this is kind of wider than that
18:38:17 <adamw> kparal: that's just the _latest problem_ we've found when you have a non-ascii encryption passphrase
18:38:32 * jreznik is with nirik
18:38:33 <adamw> we have come across all sorts of ones before: problems with decrypting during fedup, during anaconda, during system boot...
18:38:45 <Viking-Ice> adamw, so what you are saying this is entirely broken across the field
18:38:45 <adamw> it's one of those things that just seems to keep breaking somewhere, hence my 'loaded gun' comment
18:38:59 <Viking-Ice> loaded gun or not this needs to be fixed before we release
18:39:03 <adamw> Viking-Ice: no, what i'm saying is it's one of those things that seems to be particularly susceptible to bugs
18:39:07 <nirik> I just worry that this fix my break it someplace we didn't expect, but yeah...
18:39:21 <cmurf> right
18:39:27 <adamw> nirik: i can't see that it can do that _as long as the fix can be proved to only affect passphrase creation_
18:39:30 <cmurf> it's fragile, i don't like it, it keeps breaking, but this is not news
18:39:45 <cmurf> and therefore not the time to fix it with a possibly intrusive fix
18:39:46 <nirik> yeah, so I guess +1FE
18:39:49 <adamw> if the code for creating a passphrase and the code for entering one to decrypt an existing encrypted volume are tied together i wouldn't want to poke them
18:39:54 <kparal> I think it doesn't make sense to debate this unless anaconda devs comment it
18:39:57 <nirik> but we don't have to take it if it's scary
18:40:00 <adamw> but if they're clearly separable i think the fix would not be fragile
18:40:02 <kparal> we don't even know if they want to implement it
18:40:05 <Viking-Ice> adamw, the end result is that you choose to encrypt your partition and a) might not be able to unlock it at boot time and b) use the rescue image to try to save it
18:40:07 <cmurf> kparal good point
18:40:23 <cmurf> do we even have wiling implementers
18:40:30 <kparal> that's why I think that FEs should be always proposed by developers
18:40:37 <adamw> we can punt and ask devs for input, i'd hate to lose it in a time crack, but eh
18:40:45 <Viking-Ice> that sounds serious enough to delay the release for ( to me anyway )
18:40:46 <adamw> kparal: let's not have that discussion in a meeting again
18:40:53 <kparal> +1 FE by me
18:41:04 <cmurf> use  needinfo
18:41:17 <cmurf> +1 FE
18:41:34 <cmurf> i'm leery about this though
18:42:02 <Viking-Ice> seriously guys is the workaround here supposed to be dont encrypt your partitions ?
18:42:02 <kparal> we don't decide whether it's a good idea. we decide whether we will take it if anaconda devs decide it's a good idea
18:42:23 <cmurf> ok
18:42:27 <adamw> proposed #agreed #1039168 is accepted as a freeze exception issue as a safe change here would significantly improve our robustness against bugs in passphrase entry in various places, but we will only take a simple that demonstrably is limited to the codepath for creating a new encrypted volume
18:42:31 <cmurf> ack
18:42:42 <kparal> ack
18:42:47 <adamw> Viking-Ice: no, silly, it's 'magically know that you shouldn't put non-ascii characters in your passphrase' ;)
18:43:03 <adamw> Viking-Ice: i think a lot of people _do_ know that (probably from bitter experience), but it'd be nice to protect those who don't
18:43:11 <greenlion> Viking-Ice, workaround is switch layout but because of bug 1039185 non-ascii layout is default
18:43:17 <Viking-Ice> I'm going -1 FE and hard +1 blocker here this is serious enough to explode in end users encrypted butt
18:43:52 <Viking-Ice> but carry on...
18:44:08 <roshi> I'm leaning towards Viking-Ice with this one
18:44:42 <adamw> well, you only have +2 votes for blocker, by my count
18:44:46 <roshi> but votes are in
18:44:48 <roshi> yeah
18:44:57 <roshi> ack on the wording
18:45:01 <adamw> #agreed #1039168 is accepted as a freeze exception issue as a safe change here would significantly improve our robustness against bugs in passphrase entry in various places, but we will only take a simple fix that demonstrably is limited to the codepath for creating a new encrypted volume
18:45:14 <adamw> #topic (1039185) When configuring both 'native' and US layout for a layout that cannot input ASCII, US should be first in the list
18:45:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039185
18:45:14 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
18:45:21 <adamw> this is the bug greenlion just referred to
18:45:26 <greenlion> yep
18:45:49 <jreznik> ack
18:46:01 <adamw> so, as briefly mentioned above, the typical configuration for inputting languages with entire non-latin alphabets is that you have switchable layouts
18:46:12 <greenlion> if this will be fixed, then previous will have less severity
18:46:25 <Viking-Ice> 0.5 on FE
18:46:26 <adamw> the letter keys input latin letters *or* 'native' letters, you switch between the two modes somehow (usually a magic key combo)
18:46:51 <adamw> greenlion asserts, and my research agrees, that the typical configuration in this case is that the keyboard starts out in 'latin mode' and you have to switch to get native characters
18:47:11 <adamw> but currently in anaconda, we set the default the other way around: it starts out in 'native' mode and you have to switch to get latin chars
18:47:39 <greenlion> and if one wants to have 'native' first they want to have it inside DE not system-wide
18:48:13 <roshi> that seems sensical
18:48:14 <adamw> vchronek is suggesting that other users filed reports suggesting they expected native layout first, but i can't find any immediately
18:48:40 <adamw> this would've been in f18 and f19 timeframe when we were much worse in this area, and were doing some silly things like not giving you a switchable layout at all
18:48:57 <greenlion> adamw, probably that was reports of having only native if F-18 ?
18:49:06 <greenlion> in*
18:49:10 <kparal> +1 FE, if anaconda devs decide to revert the keymap order
18:49:23 * Viking-Ice leaves this to master locale <adamw) to decide while grasping "fresh air"
18:49:36 <adamw> greenlion: that's what I think too, but we should probably investigate
18:49:38 <adamw> Viking-Ice: hehe
18:49:50 <adamw> greenlion: i can try and pull those bugs out of my internal long-term storage =)
18:50:22 <adamw> the patch is: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-December/007717.html
18:50:26 <adamw> so it's certainly small
18:51:12 <roshi> +1 FE, especially because of the mitigating effects to the previous bug
18:51:15 <adamw> proposed #agreed #1039185 is accepted as an FE issue, but we should double-check with more native users of affected languages that this is what they expect
18:51:22 <roshi> ack
18:51:28 <jreznik> ack
18:51:31 <greenlion> ack
18:51:41 <greenlion> adamw, how much is "more" by the way? :)
18:51:54 <adamw> as many as we can find
18:52:00 <adamw> i'll tag the bug with i18n and mail the i18n ml
18:53:51 <adamw> #agreed #1039185 is accepted as an FE issue, but we should double-check with more native users of affected languages that this is what they expect
18:54:02 <adamw> #topic (1039511) Selection of tmpfs filesystem is broken
18:54:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1039511
18:54:02 <adamw> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
18:55:06 <nirik> +1 FE, removing it seems reasonable
18:55:08 <adamw> +1 FE, this looks silly.
18:55:45 <kparal> +1
18:55:48 <adamw> of course, removing it from the list will turn out to prevent some partition that's supposed to be tmpfs from being created or something...
18:55:58 <roshi> +1
18:56:06 <Viking-Ice> definetly +1 here
18:56:23 <adamw> proposed #agreed #1039511 is accepted as a freeze exception issue, this is obviously bad installer behaviour that can't be fixed post-release
18:56:27 <roshi> ack
18:56:27 <Viking-Ice> ack
18:56:29 <kparal> ack
18:56:32 <greenlion> ack
18:56:35 <jreznik> ack
18:56:54 <adamw> #agreed #1039511 is accepted as a freeze exception issue, this is obviously bad installer behaviour that can't be fixed post-release
18:57:04 <adamw> #topic (1027365) [abrt] bluez-5.10-2.fc20: _IO_default_xsputn: Process /usr/libexec/bluetooth/bluetoothd was killed by signal 11 (SIGSEGV)
18:57:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027365
18:57:04 <adamw> #info Proposed Freeze Exceptions, bluez, NEW
18:57:47 <Viking-Ice> +1 blocker based on c12
18:57:50 <adamw> this feels a bit futile without wider testing...
18:57:51 <adamw> blocker?
18:58:01 <adamw> we're blocking releases on bluetooth now? i was not informed ;)
18:58:26 <adamw> note it says 'pair from phone to computer' as well, which is kinda unusual case, i think? i'd usually pair from the computer
18:59:02 * kparal testing
18:59:02 <nirik> didn't we already do this one? hum.
18:59:15 <Viking-Ice> I would think this would fall under expected desktop experience
18:59:47 <Viking-Ice> as well as jreznik mentioning bluez5 being utterly broken and Martin mentioning in c12 reverting the feature
18:59:48 <adamw> nirik: no, you're thinking of the gcc sharing bug
18:59:55 <kparal> ah, I don't have bluetooth, ok, nevermind, not testing :)
19:00:17 <adamw> Viking-Ice: i'm not sure i'm convinced it's 100% broken...what other bugs are there?
19:00:17 <jreznik> I was able to pair from laptop to the phone
19:00:38 <Viking-Ice> honestly people expect pairing phone's and tabled to their laptop/desktop/workstation
19:00:40 <Viking-Ice> these day's
19:00:58 <adamw> Viking-Ice: like i said, the bug is for pairing from phone to PC - i.e. you're sitting in front of both, and you decide to pair through the phone's UI
19:01:07 <Viking-Ice> adamw, right
19:01:13 <adamw> if you pair through PC's UI it works, it seems
19:01:16 <Viking-Ice> like you pair your phone to the tablet
19:01:30 * adamw checks
19:01:48 * danofsatx-dt is testing
19:02:03 <Viking-Ice> this boils down to modern desktop experience I would say but if people dont want to block on it fine +1 FE
19:02:15 <danofsatx-dt> confirmed crash
19:02:42 <adamw> huh. /me just did it and nothing crashed.
19:02:45 <cmurf> crash isn't good
19:02:46 <jreznik> same here, but from PC, I'm able to pair
19:02:58 <adamw> oh, bluez-5.11-1.fc20.x86_64
19:02:58 <danofsatx-dt> I can pair from PC to phone, not phone to PC
19:03:02 <cmurf> bluetooth is so flaky on devices that wouldn't block on it
19:03:12 <adamw> what bluez do you folks have?
19:03:21 <jreznik> so it works one way and I talked to Martix and he's happy with FE
19:03:31 <adamw> commonbugs it, though
19:03:39 <danofsatx-dt> 5.11
19:03:42 <jreznik> bluez-5.11-1.fc20.x86_64
19:03:55 <danofsatx-dt> 5.11-1
19:04:00 <Viking-Ice> hmm come to think of it I dont think this work reliably with bluez4 either so...
19:04:20 <cmurf> is it blooz or bloozy? i like bloozy.
19:04:44 <jreznik> Viking-Ice: well, BT never work reliably :(
19:04:51 <jreznik> worked
19:04:57 <cmurf> fwiw, Apple went way out on a limb with BT and seriously it's flaky on OS X also
19:05:00 <adamw> Viking-Ice: jreznik: yeah, that's how i'd look at it
19:05:02 <Viking-Ice> hurray for improvements (or not
19:05:11 <cmurf> and most of it has to do with the handheld devices
19:05:12 <Viking-Ice> so votes peopel
19:05:18 <Viking-Ice> mean people
19:05:29 <cmurf> the ones that work mostly well are things like keyboards and mice that are otherwise fairly dense
19:05:30 <roshi> I'm fine with FE
19:05:31 <adamw> proposed #agreed #1027365 is accepted as a freeze exception issue, crasher in a common desktop function that may well be used on lives.
19:05:36 <jreznik> ack
19:05:36 <Viking-Ice> ack
19:05:37 * roshi doesn't do anything with BT
19:05:39 <kparal> ack
19:05:39 <roshi> ack
19:05:42 <adamw> cmurf: eh, it was busted with my bt mouse for years
19:05:50 <adamw> #agreed #1027365 is accepted as a freeze exception issue, crasher in a common desktop function that may well be used on lives.
19:05:56 <adamw> #topic (1031850) Custom partitioning screen rendering broken at 1024x768 in Russian (F20 Final TC1)
19:05:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1031850
19:05:56 <adamw> #info Proposed Freeze Exceptions, gtk3, NEW
19:06:01 * jreznik uses BT pretty often but sometimes has to use strange combination of devices to make it work
19:06:03 <adamw> oh look what broke again
19:06:14 <greenlion> :D
19:06:17 <cmurf> haha
19:06:23 <adamw> +1 FE but only for a simple fix, something like a translation shortening or something
19:06:36 <adamw> don't want to go busting partitioning just to fix up one of these damn bugs
19:06:36 <cmurf> +1FE
19:06:53 <cmurf> wel it's UI busting only hopefully not actual on disk function
19:06:53 * nirik nods. +1FE
19:07:00 <pwhalen> +1 FE
19:07:12 <Viking-Ice> +1 FE
19:07:18 <roshi> +1
19:07:18 <jreznik> +1 for limited scope FE
19:07:50 <Viking-Ice> let's not risk angry mother russia
19:08:08 <greenlion> Viking-Ice, ;)
19:08:14 <adamw> proposed #agreed #1031850 is accepted as a freeze exception issue - obviously cannot be fixed with an update and sucks if you're a russian partition pokemon with a low-res screen, but we're looking for a very safe fix
19:08:25 <kparal> ack
19:08:28 <roshi> pokemon?
19:08:38 <jreznik> :D
19:08:39 <nirik> ack
19:08:49 <adamw> roshi: heh, term mizmo and I came up with to describe those people who've just gotta catch 'em all (obscure partition schemes)
19:08:59 <roshi> ah
19:09:04 <adamw> you can probably tell we were annoyed at the time :P
19:09:11 * roshi thought you were just testing if people read the thing before they ack'd
19:09:15 <roshi> :P
19:09:16 <jreznik> ack (for that bright moment that made me smile today)
19:09:16 <adamw> that too
19:09:17 <roshi> lol
19:09:17 <adamw> :D
19:09:42 <adamw> #agreed #1031850 is accepted as a freeze exception issue - obviously cannot be fixed with an update and sucks if you're a russian partition pokemon with a low-res screen, but we're looking for a very safe fix
19:09:42 <Viking-Ice> http://soepic.pl/stor/items/0f74ec7008cfceb8f.jpg
19:09:45 <Viking-Ice> ack
19:09:46 <cmurf> that's funny
19:10:21 <adamw> 1039052 was in the lsit but i unilaterally dropped it cos the affected yum never made stable'
19:10:37 * nirik nods
19:10:41 <adamw> i don't think we have any others at this point
19:11:01 <greenlion> adamw, eh, that means you consider me as pokemon? :)
19:11:49 <adamw> definitely :P
19:11:59 <greenlion> adamw, :D
19:12:01 <adamw> moving on to accepted blockers, then, let's just pull out the interesting ones
19:12:20 <adamw> #topic (1027947) Cannot change a partition's size, then return it to the original size
19:12:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027947
19:12:20 <adamw> #info Accepted Blocker, anaconda, ASSIGNED
19:12:29 <adamw> this one is kinda slipping between cracks, it feels like
19:12:38 <adamw> and dlehman chose today for PTO, so excellent
19:12:49 <kparal> I wanted to split this into several ones and vote on them independently, but bugzilla didn't allow me
19:12:53 <adamw> i asked #anaconda if anyone else is working on it, but no particular response
19:13:05 <adamw> is it clear from the bug at present precisely what's broken?
19:13:26 <cmurf> looking
19:13:27 <kparal> I tried to summarize in c40
19:14:02 <Viking-Ice> what's here to discuss
19:14:04 <Viking-Ice> it's a blocker
19:14:07 <Viking-Ice> it needs fixing
19:14:17 <cmurf> 11-20 "fix is simple"
19:14:49 <kparal> originally it was just about reverting a size for a partition. then I've found it it behaves differently for mounted and non-mounted partitions, and for standard and lvm partitions
19:14:51 <cmurf> huh so it's still not fixed in 20.25.14
19:15:04 <kparal> so it's a bit more complex now
19:15:11 <cmurf> shocking
19:15:12 <Viking-Ice> kparal, that's should be different blocker
19:15:27 <roshi> the fix is super simple (restart anaconda and know what you want next time)
19:15:34 <kparal> well it's related to the original one, but as I say, I'm not able to create a new bugzilla report
19:15:35 <Viking-Ice> ( since it sounds like a plethora of bugs )
19:15:44 <roshi> +1 FE if it's a trivial fix
19:15:50 <kparal> roshi: already a blocker
19:15:52 <Viking-Ice> roshi, it's already a blocker
19:16:02 <Viking-Ice> we wait for fix(es)
19:16:09 <roshi> haha
19:16:16 <adamw> yeah, we're on accepted blockers now
19:16:18 <roshi> yeah, missed the key comment saying we moved on
19:16:41 <adamw> kparal: when you say bugzilla 'wouldn't let you' split it up - because it files all the bugs as dupes?
19:16:46 <adamw> you can manually split them out, though it's painful
19:16:57 <cmurf> no i think he means he can't file bugs today at all
19:16:58 <kparal> adamw: no, because I get proxy error on https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
19:17:17 <cmurf> bc you disabled his bug creation privs
19:17:17 <Viking-Ice> yet another reason why we should ditch rh bugzilla
19:17:37 <cmurf> ohnoez
19:17:44 <adamw> kparal: oh yeah
19:18:01 <Viking-Ice> interesting it just hangs there
19:18:01 <adamw> so, assuming you manage to do that later...i think we're on top of this, but we're worried about anaconda side...
19:18:03 <cmurf> i'm sometimes getting a proxy error and sometimes not
19:18:23 <Viking-Ice> adamw, worried what do you mean worried
19:18:28 <Viking-Ice> we wait until they fix it
19:18:29 <cmurf> i think it's the same bug regardless of the "partition" method
19:18:34 <kparal> do you think I should split it into two bugs - standard part vs lvm? and close the original one (no longer crashes)?
19:18:35 <cmurf> unless dlehman asks for a new bug
19:19:34 <Viking-Ice> shall we move on it's not like rh bugzilla is usable at the moment
19:20:19 <Viking-Ice> hey here's an idea cant we use nsa agents to triage bugs when they crawl through bugzilla's
19:20:34 <cmurf> kparal: i see in 38 you reproduce with standard partitions, and then in 40 with lvm
19:20:41 <cmurf> so it seems still broken in any case
19:20:57 <kparal> yes
19:21:00 <cmurf> btw do you have the anaconda-tb for the crash in 38?
19:21:19 <cmurf> dlehman pretty much always wants the tb for any crash
19:21:20 <adamw> #info kparal has detailed the various broken cases in c#40, will split the bug into multiple reports when BZ is co-operating, other than that, we are simply waiting on anaconda team for fixes
19:21:25 <kparal> cmurf: it no longer crashes, except for one-time crash (1039503)
19:21:33 <adamw> storage.log , then
19:21:36 <cmurf> ok
19:21:39 <brunowolff> Can you cover the spin-kickstarts ticket next as I have to run to a meeting soon?
19:21:40 <cmurf> yeah
19:21:52 <kparal> yeah, I have them on disk, wanted to attach them to splitted reports
19:21:54 <Viking-Ice> lets move to spin kickstart
19:22:00 <kparal> I can attach them here
19:22:06 <brunowolff> The only thing to mention is whether there is likely yo be a change for getting the desktop undersize again.
19:22:27 <Viking-Ice> kparal, well on the bug report last time I checked irc did not have attachment feature lol
19:22:32 <adamw> that's not what was coming next...
19:22:33 <adamw> #topic (983110) several autostart apps (e.g. polkit-kde, kmix) and logout/shutdown countdown fails
19:22:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=983110
19:22:33 <adamw> #info Accepted Blocker, glib2, ASSIGNED
19:22:51 <Viking-Ice> adamw, brunowolff asked for  	1035536
19:22:57 <adamw> oh, sorry, missed that
19:23:01 <adamw> #info we'll come back
19:23:08 <adamw> #topic (1035536) Final spin-kickstarts build required for Fedora 20 GA
19:23:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035536
19:23:09 <adamw> #info Accepted Blocker, spin-kickstarts, MODIFIED
19:23:18 <adamw> i don't think we need anything much from bruno
19:23:32 <brunowolff> I think the last TC had a note that the desktop spin was oversize.
19:23:35 <adamw> i think for desktop size we can pull the libreoffice fix mentioned in the bug
19:23:56 <brunowolff> I was wondering if that was likely to trigger a change in spin-kickstarts?
19:24:05 <adamw> no reason why
19:24:12 <adamw> i lose track, do we have a build with the lxde changes in it yet?
19:24:19 <adamw> cwickert stuff from dec 4th
19:24:32 <brunowolff> OK. That's what I was interested in. I'll try to keep a lookout for any changes as well.
19:24:47 <brunowolff> We do not currently need a new build.
19:24:52 <adamw> OK
19:25:08 * nirik notes there were some commits to master after that...
19:25:08 <adamw> #info as of now no new spin-kickstarts build is needed or expected to be needed, but we'll keep an eye out
19:25:10 <brunowolff> I have to run. Thanks.
19:25:11 <nirik> but nothing to f20
19:25:35 * nirik suspects the cloud one was for f20 tho
19:25:36 <jreznik> thanks brunowolff for taking care
19:26:28 <adamw> #topic (983110) several autostart apps (e.g. polkit-kde, kmix) and logout/shutdown countdown fails
19:26:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=983110
19:26:29 <adamw> #info Accepted Blocker, glib2, ASSIGNED
19:26:36 <adamw> so this one's just all kinds of fun
19:26:45 <Viking-Ice> seems fixed
19:26:46 <adamw> KDE team has been trying to debug/fix it all weekend but it's not proving easy
19:26:51 <adamw> Viking-Ice: nah, not that simple
19:27:03 <adamw> a lot of the discussion is happening on IRC rather than in-bug, unfortunately
19:27:10 <jreznik> [20:12] <Kevin_Kofler> So I think we should do a kdelibs build without the debugging stuff, pull the debugging kdelibs+kde-workspace update and get the cleaned-up kdelibs through Bodhi ASAP.
19:27:59 <Viking-Ice> yeah well in the end of the day we have to wait so move on
19:28:05 <Viking-Ice> ?
19:28:08 <adamw> well, hm, maybe they do want to go with that fix
19:28:14 <adamw> jreznik: yeah
19:28:17 <adamw> hi kk
19:28:43 <adamw> so the current plan for 983110 is to do a kdelibs build with just the 'disable glib integration for klauncher' workaround and see if that's good enough?
19:28:55 <jreznik> I pinged mclasen today, so at least he's aware of it but did not hear back so far
19:29:03 <Kevin_Kofler> FYI, I'm now building kdelibs-4.11.3-9.fc20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6272910 – it's the same workaround as -8, but without the extra debugging output that was added to help debug the issue.
19:29:05 <adamw> jreznik: desrt has been helping from the glib side
19:29:20 <adamw> Kevin_Kofler: and there's a reasonable chance this will 'fix' the bug without causing other issues?
19:29:25 <Kevin_Kofler> Yes.
19:30:10 <Kevin_Kofler> So far all reports (with -8) were positive, the debugging output looked sane too, and re other issues, I don't see it causing any and we don't have any such reports in any case.
19:30:33 <adamw> OK.
19:31:01 <adamw> #info a build with a workaround for this bug is currently running, we have a reasonable belief that it may be sufficient to address it without causing other problems
19:31:10 <Kevin_Kofler> The Konqueror/QtWebKit problem we had in the chan is probably not related to my build. It may or may not be related to #983110, in that QT_NO_GLIB appears to fix that too (but breaks, uh, certain proprietary plugins).
19:31:14 <adamw> danofsatx hasn't been able to hit the bug with the workaround?
19:31:30 <Kevin_Kofler> My kdelibs build sets QT_NO_GLIB only inside KLauncher and so does not affect Konqueror at all.
19:32:11 <Kevin_Kofler> adamw: No, the bug seems gone for good. (Crossing fingers!)
19:32:44 <Kevin_Kofler> I only thought of the workaround yesterday, so time for testing has been short, unfortunately.
19:33:03 <adamw> yeah'
19:33:09 <adamw> still, beats no fix
19:33:19 <adamw> thanks, kev
19:33:26 <Kevin_Kofler> So my proposal is to get kdelibs-4.11.3-9.fc20 in.
19:33:31 <adamw> yup, sounds good to me
19:33:43 <Kevin_Kofler> It has only the workaround and no other changes.
19:33:49 <jreznik> thanks
19:33:51 <adamw> #topic (1000893) Desktop Live is oversized (larger than 1 GB)
19:33:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000893
19:33:51 <adamw> #info Accepted Blocker, LiveCD, NEW
19:34:38 <adamw> i haven't yet looked into what happened in TC5, but we have a change in reserve: the libreoffice update from the bug, that i didn't pull initially as i thought we wouldn't need it
19:34:45 <Kevin_Kofler> rdieter: You're late to the party. ;-)
19:36:03 <adamw> rdieter: we already moved on, unless you had anything to add besides 'we're gonna use -9 and cross our fingers :>'
19:36:20 <rdieter> nothing to add
19:36:23 <adamw> ok, thanks!
19:36:32 <adamw> on the current bug: tc5 is only 300k oversize, so the LO fix should be enough.
19:36:52 <adamw> #info we're not sure what changed in TC5 to cause the image to go back over size, but we do have a fix we can pull in for the next build
19:37:01 <danofsatx-dt> and I was nuking my lunch. -8 and -9 have mitigated the bug both with and without nvidia drivers in my case.
19:37:11 <adamw> OK, that's all the interesting acceptedblockers I had on my list, any I missed?
19:37:15 <adamw> danofsatx-dt: thanks muchly for your testing
19:37:28 <Viking-Ice> really size issues now in the cycle <sigh>
19:37:41 <adamw> desktop is right up against a knife-edge
19:37:54 <adamw> tc4 was like 1MB under, tc5 300K over...
19:38:06 <adamw> tc4 700K under, heh
19:38:47 <Viking-Ice> ok let's continue cursing holding that knife and move on
19:40:13 <adamw> nothing to move on to
19:40:16 <adamw> #topic Open floor
19:40:24 <adamw> anything I missed, folks? the lists are a bit messy so don't hesitate
19:40:35 <adamw> oh, i did kinda wonder why https://bugzilla.redhat.com/show_bug.cgi?id=1021507 isn't proposed as anything
19:40:40 <adamw> kparal, cmurf?
19:40:57 * kparal looking
19:41:07 <kparal> yeah, I considered that
19:41:16 * greenlion hopes he won't be hunt down by anaconda devs for finding all those partitioning bugs :)
19:41:19 <kparal> however, my reports seem to be assigned to it by abrt in error
19:41:32 <kparal> the original report is about thinp
19:42:01 <kparal> also, nobody complained in a month
19:42:06 <Viking-Ice> this looks like has fallen out of our radar https://bugzilla.redhat.com/show_bug.cgi?id=1026860
19:42:43 <cmurf> looking
19:42:51 <kparal> ad 1021507: we removed blocker status on 2013-10-30
19:43:11 <Viking-Ice> I dont think this is actually fixed properly
19:43:33 <Viking-Ice> spstarr is on QA most likely hitting regression with the fix for this
19:44:08 <cmurf> bug 1021507 seems familiar
19:44:11 <cmurf> i thought that was fixed
19:44:41 <adamw> on 1026860, i'm kinda confused, as prajnoha reported success with the systemd scratch build in https://bugzilla.redhat.com/show_bug.cgi?id=1026860#c52
19:44:42 <cmurf> propose it as a blocker?
19:45:49 <cmurf> that is kindof a messy bug, i'm not sure how to reproduce
19:46:26 <adamw> Viking-Ice: i've added a needinfo on prajnoha, sound good?
19:46:54 <Viking-Ice> adamw, yeah but I think in the end the fix will be that dm just needs to make use of SYSTEMD_READY
19:46:56 <adamw> brb, gotta pick up a parcel
19:47:10 <adamw> continue discussing 1021507...
19:50:07 <Viking-Ice> anywho I need to eat to maintain my fatness hence I'll be clocking out soon
19:50:32 <Viking-Ice> is there anything we need to discuss further here which cannot be brought up on next meeting?
19:50:54 * roshi doesn't have anything
19:51:14 <adamw> nope
19:51:43 * adamw sets quantum fuse
19:51:53 <adamw> speak now or forever hold your peace...
19:51:58 <adamw> or, at least until wednesday.
19:52:48 <adamw> OK, thanks for coming, folks
19:52:50 <adamw> back to the coalfaces!
19:52:53 <adamw> #endmeeting