17:03:12 <tflink> #startmeeting f18final-blocker-review-8
17:03:12 <zodbot> Meeting started Wed Jan  2 17:03:12 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:13 <tflink> #meetingname f18final-blocker-review-8
17:03:13 <tflink> #topic Roll Call
17:03:13 <zodbot> The meeting name has been set to 'f18final-blocker-review-8'
17:03:33 <tflink> Who's ready for some blocker review fun time?
17:03:52 <adamw> yawn
17:03:56 <fenrus02> is this going to result in a tc4 / rc1 iso ? :)
17:03:59 <adamw> you might have left the announcement a bit late...
17:04:12 <adamw> fenrus02: the two aren't really related.
17:04:44 * kparal here
17:04:49 <tflink> adamw: yeah, I should have sent it out earlier than I did
17:05:07 * jreznik is here
17:06:22 <tflink> #chair adamw kparal
17:06:22 <zodbot> Current chairs: adamw kparal tflink
17:06:41 * nirik is lurking, ping if I can help.
17:08:25 <tflink> I think we have enough people to get started with the always exciting ... boilerplate!
17:08:30 <tflink> #topic Introduction
17:08:39 <tflink> Why are we here?
17:08:39 <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 nice-to-have bugs.
17:08:47 <tflink> #info We'll be following the process outlined at:
17:08:47 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:08:53 <tflink> #info The bugs up for review today are available at:
17:08:53 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:08:59 <tflink> #info The criteria for release blocking bugs can be found at:
17:08:59 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:08:59 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:08:59 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:09:59 <tflink> as a side note, I'm using the raw list today - there's only one blocker that seemed to need information and since go/no-go is tomorrow, we should review them all anyways
17:10:12 <tflink> Up for review today we have:
17:10:20 <tflink> #info 12 Proposed Blockers
17:10:20 <tflink> #info 15 Accepted Blockers
17:10:20 <tflink> #info 12 Proposed NTH
17:10:20 <tflink> #info 31 Accepted NTH
17:10:59 <tflink> If there are no objections, let's get started with the proposed blockers
17:11:40 <tflink> #topic (832510) vnc server starts before the network
17:11:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=832510
17:11:40 <tflink> #info Proposed Blocker, anaconda, NEW
17:11:42 <buggbot> Bug 832510: unspecified, unspecified, ---, anaconda-maint-list, NEW , vnc server starts before the network
17:12:04 * satellit sorry I am late
17:12:30 <tflink> this is a conditional violation of the final criterion "The installer must be able to complete an installation using all supported interfaces" where the network interface is a bit slow to come up
17:12:43 <tflink> satellit: no worries, it's not like review meetings are short :)
17:13:03 * satellit : )
17:13:48 <tflink> it looks like this might be a bigger problem for ppc than PA
17:13:50 <kparal> that has been reported a long time ago by lnie, no?
17:13:59 <tflink> more common, anyways
17:14:17 <brunowolff> Do the people that see this see it consistently or can they retry a couple of times and have a high chance of being able to install successfully?
17:14:19 <tflink> kparal: not sure. I don't remember seeing one like this but I could be forgetting something
17:15:02 <adamw> sorry, back
17:15:03 <fenrus02> can the timeout / auto-retries be extended a bit to cover this?
17:15:45 <tflink> brunowolff: good question, not sure. I suspect that it isn't every attempt by looking at the time between reports
17:15:58 <adamw> well, depends how often this gets tested
17:16:33 <tflink> true, but there is a 6 month gap between reports
17:16:34 <kparal> I was thinking it's the same as bug 868777
17:16:36 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=868777 unspecified, unspecified, ---, rvykydal, CLOSED CURRENTRELEASE, fail to install the system use vnc
17:16:51 <kparal> > Yes, we race with slow dhcp NM's default auto connection is waiting for. Sending a patch to ML.
17:17:29 <adamw> ah, nice catch
17:17:32 <adamw> so it may be fixed already?
17:17:43 <kparal> c#3 says anaconda 18.37.4
17:17:45 <tflink> but that was fixed in 18.37.2, the latest report is against 18.37.4
17:17:56 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-December/002427.html
17:17:59 <adamw> hrm
17:18:03 <kparal> so I guess it's not fixed
17:18:10 <kparal> or it's a related issue
17:18:23 <jreznik> anyone seeing it? who could try to reproduce it?
17:18:52 <adamw> i'd think anyone
17:19:01 <adamw> you don't even have to connect to the server, just fire up a VM with vnc parameter
17:19:03 <kparal> someone with a slow DHCP server :)
17:19:18 <kparal> adamw: it's a race
17:19:33 <adamw> sure, but anyone can _try_.
17:19:41 * adamw kinda on the fence here
17:19:46 <adamw> did anyone poke #anaconda?
17:20:16 <adamw> thanks jreznik
17:21:43 <Viking-Ice> hmm is this not started by systemd unit ?
17:23:10 <adamw> dunno.
17:23:15 <adamw> so what's everyone feeling on this?
17:23:41 <tflink> on the fence but leaning -1/+1
17:23:52 <Viking-Ice> +1/+1
17:23:57 <kparal> +1 blocker
17:24:29 <kparal> vnc is recommended for remote machine installs, it's hard to work around
17:24:44 * jreznik is more with tflink -1/+1, seems to be more corner one - race with slow network...
17:25:03 <tflink> the workaround issue is a good point, though
17:25:19 <fenrus02> hitting 'retry' from  a remote station is difficult.
17:25:36 <tflink> fenrus02: how so?
17:25:47 <fenrus02> tflink, without a gui, how do you hit the retry button?
17:26:01 <Viking-Ice> jreznik, these aren't corner cases
17:26:03 <tflink> there's a retry button?
17:26:19 <fenrus02> tflink, err.. there used to be when networking didnt come up.
17:26:23 <fenrus02> gone?
17:26:26 <brunowolff> I think -1 blocker / +1 NTH with common bugs note about slow DHCP triggering this.
17:26:46 <tflink> in this case, I think that a retry wouldn't matter since the vnc server crashes
17:26:47 <adamw> i was -1 for beta but i might be +1 for final, it might really help to have anaconda input but they don't seem to be responding :(
17:26:58 <kparal> this renders the vnc feature almost useless
17:27:09 <tflink> kparal: if you have a really slow dhcp
17:27:19 <Viking-Ice> jreznik, we have had plethora of bugs against systemd for admins that forget to enable  NetworkManager-wait-online.service
17:27:23 <kparal> or a slow NIC
17:27:27 <tflink> actually, I was wrong. the vnc server doesn't crash but anaconda does
17:27:28 <fenrus02> tflink, how slow is "really slow" ?
17:27:39 <tflink> fenrus02: not sure off the top of my head
17:28:00 <jreznik> skip it for now and wait for insights from anaconda? we can come back to this one later today
17:28:12 <tflink> the anaconda crashing part makes me more +1
17:29:33 <Viking-Ice> so that's 3 +1 blocker 2  +1 nth
17:29:36 <tflink> I suppose we could punt but how are we going to determine whether or not the lack of a timeout is common enough to justify blocking over
17:30:00 <Viking-Ice> the installer is not fixable via update hence...
17:30:02 <adamw> well i was hoping anaconda team might be able to help quantify
17:30:19 <kparal> I can talk to rvykydal tomorrow if that helps
17:30:56 <jreznik> or just skip it for now and wait for #anaconda reply... I expect the meeting is going take more time :)
17:31:47 <tflink> interesting proposed workaround
17:32:03 <tflink> use a ks or updates.img to force the network to be brought up in dracut
17:32:31 <adamw> that'd work, i guess.
17:32:38 <fenrus02> what is the downside to that?
17:32:43 <adamw> we could ask people to try it.
17:32:51 <kparal> fenrus02: you have to write a kickstart :)
17:32:59 <fenrus02> granted, a ks is not common use.  but an updates.img should be
17:33:24 <adamw> yeah, it wouldn't be hard to stick a dummy updates.img somewhere and link it to a commonbug.
17:33:35 <tflink> yep, that's what I was thinking
17:33:54 <tflink> punt, ask for more testing with workaround?
17:34:28 <jreznik> adamw: with linking form commonbugs, I'm ok with that, ask people to create it - it would be more...
17:34:36 <tflink> on the other hand, anaconda really shouldn't _crash_ if the vncserver doesn't start
17:34:44 <Viking-Ice> yup
17:35:22 <jreznik> it should not, but if it could be workarounded - let's try that
17:35:31 <fenrus02> imho, if anything makes anaconda _crash_ it's a blocker.
17:36:08 <adamw> i don't think that's tenable.
17:37:05 <jreznik> it should not crash but not everything has to be blocker
17:37:09 <fenrus02> error checking and handling is impossible ?
17:37:12 <tflink> I see +2 blocker and +3 nth
17:37:19 <adamw> fenrus02: on the f18 time scale, yes.
17:37:42 <fenrus02> how long would it take to have proper error handling placed in?  delay f18 that long.
17:37:53 <adamw> and in theory, really, yeah. anaconda is designed to crash as its failure case, for many failures. crashing _is_ anaconda error handling: when it crashes, you can report the bug.
17:38:12 <fenrus02> broken by design then. that's not good.
17:38:22 <adamw> let's not have that debate here.
17:38:29 * fenrus02 nods
17:38:53 <adamw> i'm either +1 or punt
17:38:54 <adamw> not -1
17:39:00 <tflink> proposed #agreed 832510 - AcceptedNTH - While not a clear blocker, vnc not starting can be a big problem for remote installs and a tested fix would be considered past freeze. Using an updates.img or ks @ boot could be a workaround as network would be brought up earlier - will revisit once the potential workaround has been tested
17:39:24 <tflink> yeah, I'm not sure I'm fully +1 but definitely not -1
17:39:45 <jreznik> what punt will bring to the decision?
17:40:32 <Viking-Ice> aren't the majority for blocker not nth?
17:40:49 <tflink> jreznik: not sure I understand your question - are you asking what will punting help with or what are we waiting for?
17:41:10 <adamw> yeah, nack on that, i see more +1 than -1.
17:41:26 <tflink> I don't see any strong -1
17:42:14 <jreznik> tflink: what we are waiting for
17:42:25 <tflink> proposed #agreed 832510 - AcceptedBlocker - Violates the following F18 final release criterion for installs using a network connection which is slow to come up: "The installer must be able to complete an installation using all supported interfaces"
17:42:45 <tflink> jreznik: assuming that you were asking about the punt - whether the workaround works
17:42:49 <adamw> i can ack that.
17:42:55 <Viking-Ice> ack
17:42:58 <BobLfoot> +1
17:43:00 <kparal> ack
17:43:12 <tflink> #agreed 832510 - AcceptedBlocker - Violates the following F18 final release criterion for installs using a network connection which is slow to come up: "The installer must be able to complete an installation using all supported interfaces"
17:43:21 <tflink> topic (869424) RuntimeError: Error running systemctl: No such file or directory
17:43:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869424
17:43:26 <buggbot> Bug 869424: unspecified, unspecified, ---, clumens, ASSIGNED , RuntimeError: Error running systemctl: No such file or directory
17:43:27 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:44:14 <tflink> we were waiting on logs for this, now we have them and are waiting for dev input
17:44:50 <tflink> would have been nice to see the repro on an available image, though
17:45:14 <Viking-Ice> path problem?
17:47:21 <nirik> I see one thing possibly worth noting here...
17:47:31 <tflink> doesn't seem clear what is causing this - obviously not everyone is hitting this
17:47:43 <nirik> "and hit on my current compose of the DVD"
17:47:56 <nirik> this doesn't seem to be with our dvd images, but one locally composed with changes?
17:48:34 <tflink> yeah, I imagine it was using the DVDs he's been composing to test MATE on DVD
17:48:36 <kparal> in that case punt and ask
17:48:45 <kparal> ask to test with official media
17:48:59 <adamw> well, seems a bit like kicking the can
17:49:29 * nirik is with kparal
17:50:06 <adamw> i know dan's builds are straight from the official kickstart/comps, just with MATE added/
17:50:26 <adamw> and the systemd package is clearly marked for install
17:50:53 <Viking-Ice> punt
17:50:59 <nirik> I thought he was also removing some things to free up space?
17:51:04 * nirik isn't fully sure tho
17:51:11 <adamw> 00:17:37,802 INFO program: Running... /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512
17:51:11 <adamw> 00:17:37,839 ERR program: Error running /usr/sbin/authconfig: No such file or directory
17:51:11 <adamw> 00:17:37,855 INFO program: Running... systemctl enable chronyd.service
17:51:11 <adamw> 00:17:37,875 ERR program: Error running systemctl: No such file or directory
17:51:43 <adamw> authconfig-gtk is marked for install...
17:51:44 <spot> that doesn't seem right.
17:51:50 <nirik> the base systemd package didn't get installed.
17:52:02 <nirik> systemd-libs did.
17:52:19 <adamw> ohhh
17:52:25 <adamw> there's a huge chunk of SKIPBROKEN going on
17:52:27 <adamw> i bet that's the problem
17:52:59 <adamw> just search the log for SKIPBROKEN. half the distro got zapped by it. so yeah, something in the deps in his build, most likely.
17:53:11 <adamw> punt or -1 and ask him to re-test with an official build.
17:53:12 <nirik> yep.
17:53:19 <nirik> -1 and ask to test with official media
17:53:48 <jreznik> -1 and ask to test with official media
17:53:53 <kparal> the same
17:54:49 <adamw> only 36 packages actually got installed :)
17:55:08 <jreznik> "the minimal install"
17:55:23 <tflink> proposed #agreed 832510 - RejectedBlocker - This looks to be more of an issue with the custom DVD used to reproduce the issue - if it is reproducable using the official media, please repropose as a blocker
17:55:27 <adamw> ack
17:55:29 <jreznik> ack
17:55:33 <BobLfoot> ack
17:55:37 <nirik> ack
17:55:38 <tflink> #agreed 832510 - RejectedBlocker - This looks to be more of an issue with the custom DVD used to reproduce the issue - if it is reproducable using the official media, please repropose as a blocker
17:55:46 <tflink> #topic (889570) Add help / instruction text for custom spoke
17:55:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889570
17:55:46 <tflink> #info Proposed Blocker, anaconda, ON_QA
17:55:48 <buggbot> Bug 889570: medium, unspecified, ---, dlehman, ON_QA , Add help / instruction text for custom spoke
17:56:07 <tflink> this is already accepted as NTH
17:56:12 <tflink> bah, ON_QA
17:56:24 <Viking-Ice> ack
17:56:35 <tflink> any desire to actually review this or objections to skipping?
17:57:13 * tflink takes silence as no objections
17:57:23 <jreznik> skip
17:57:29 <tflink> #info this is already accepted as NTH and ON_QA - doesn't need to be reviewed as a blocker at this time
17:57:40 <tflink> #topic (889470) updates-testing shouldn't be enabled by default
17:57:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889470
17:57:40 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:57:41 <buggbot> Bug 889470: unspecified, unspecified, ---, notting, ASSIGNED , updates-testing shouldn't be enabled by default
17:58:05 <kparal> this is just a formality bug
17:58:17 <tflink> yeah, part of the transition from pre-release to release
17:58:26 <kparal> u-t is still enabled so I thought about tracking it
17:58:46 <tflink> +1 blocker - it'll get closed if it is fixed with the next compose
17:58:55 <kparal> today netinst still uses u-t, I guess a new compose is needed
17:59:04 <kparal> +1
17:59:08 <nirik> +1 blocker, close soon.
17:59:14 <akshayvyas> +1 blocker
17:59:15 * tflink doesn't remember what version of fedora-release was used with latest smoke
17:59:16 <adamw> there is a criterion for this, so +1.
17:59:30 <adamw> "A Package-x-generic-16.pngfedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned Package-x-generic-16.pnggeneric-release package must be available in the online release repository "
18:00:01 <adamw> with the image names taken out, sigh.
18:00:24 <tflink> proposed #agreed 889470 - AcceptedBlocker - Violates the following F18 final release criterion: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository"
18:00:33 <akshayvyas> ack
18:00:39 <adamw> ack
18:00:40 <kparal> ack
18:00:45 <tflink> #agreed 889470 - AcceptedBlocker - Violates the following F18 final release criterion: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository"
18:00:51 <tflink> #topic (889710) issue with Spanish keyboard: some characters missing (anaconda did configure the keyboard in the installed system)
18:00:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889710
18:00:56 <buggbot> Bug 889710: high, unspecified, ---, anaconda-maint-list, NEW , VT is not put into an unicode mode
18:00:57 <tflink> #info Proposed Blocker, anaconda, NEW
18:01:26 <kparal> my bug was a duplicate of this one
18:01:48 <kparal> short summary: installed system doesn't have VT in unicode mode
18:01:55 <kparal> it breaks a lot of characters even with English locale
18:02:14 <adamw> there's lots of workarounds, though, and it's not really unusable, and relatively trivial to fix manually...
18:02:16 <adamw> i'm kinda leaning -1
18:02:16 <kparal> like blkid, findmnt or rm <non-existent file>
18:02:58 <kparal> LiveCDs are English only, so that's not so much of a problem
18:03:50 <kparal> -1/+1 I guess
18:03:51 <adamw> do we know precisely where the bug is here, btw?
18:03:53 <adamw> plymouth?
18:03:59 <kparal> no idea from me
18:04:00 <adamw> yeah, -1/+1 for me
18:04:16 <tflink> sounds like it might be since removing rhgb seems to fix the issue
18:04:18 <kparal> but unicode_start fixes the issue
18:04:23 <jreznik> that's a good question from where it comes, -1/+1
18:05:22 <tflink> sounds like we
18:05:23 <kparal> what sets the keyboard layout these days, systemd?
18:05:35 <tflink> re mostly -1/+1, though
18:05:40 <adamw> yes.
18:05:55 <adamw> (systemd)
18:06:02 <kparal> I'll re-assign
18:06:14 <kparal> but it can be an anaconda problem as well
18:06:16 <tflink> is this a keyboard layout issue?
18:06:45 <tflink> I thought it was a font issue
18:07:01 <kparal> hmm, right, probably font
18:07:04 <tflink> well font/unicode display issue, not an input issue
18:07:32 <kparal> but "unicode_start - put keyboard and console in unicode mode"
18:07:39 <kparal> that's what confused me
18:08:01 <jreznik> and only on vt1 as far as I can see - so could be related to plymouth running there
18:08:03 <adamw> anyways, we should probably move on if we're solidly -1/+1
18:08:04 <jreznik> asking halfline
18:08:19 <kparal> jreznik: on other tty's some characters are still mangled, but not as many of them
18:08:35 <Viking-Ice> -1/+1
18:08:52 <tflink> proposed #agreed 889710 - RejectedBlocker AcceptedNTH - While problematic, there are several workarounds which aren't difficult and can be fixed post install since it appears to be a display issue instead of an input issue. However, a tested fix would be considered past freeze.
18:09:00 <Viking-Ice> ack
18:09:06 <akshayvyas> ack
18:09:10 * tflink assumes that this doesn't affect login if a unicode-only char is in the password/username
18:09:11 <jreznik> ack
18:09:20 <kparal> ack
18:09:27 <adamw> tflink: it's cosmetic only
18:09:29 <kparal> tflink: probably not, input seems to be fine
18:09:29 <adamw> ack
18:09:30 <tflink> #agreed 889710 - RejectedBlocker AcceptedNTH - While problematic, there are several workarounds which aren't difficult and can be fixed post install since it appears to be a display issue instead of an input issue. However, a tested fix would be considered past freeze.
18:09:40 <adamw> tflink: everything _works_ as it should, just what's displayed on the monitor might be off
18:10:05 <tflink> adamw: that's what I thought, just making sure I understood correctly
18:10:09 <tflink> #topic (885492) LVMError: pvcreate failed for /dev/sda3: running lvm pvcreate --config  devices { filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda4$|","r|/sda5$|","r|/sda6$|","r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|","r|/sdb1$|","r|/sdb2$|","...
18:10:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885492
18:10:16 <tflink> #info Proposed Blocker, anaconda, NEW
18:10:17 <buggbot> Bug 885492: unspecified, unspecified, ---, anaconda-maint-list, NEW , LVMError: pvcreate failed for /dev/sda3: running lvm pvcreate --config  devices { filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda4$|","r|/sda5$|","r|/sda6$|","r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|","r|/sdb1$|","r|/sdb2$|","...
18:10:24 <kparal> whoooo
18:11:02 <tflink> I'm not quite sure what the actual bug is here outside of crash on really long LVM names
18:11:37 <tflink> wait, why is lvm creating pvs on loop devs?
18:12:01 <adamw> "Technically this is a beta blocker #10, installer should reject invalid operations without crashing. Proposing."
18:12:08 <tflink> that command looks really weird to me
18:12:36 <tflink> why would you run pvcreate on 6 partitions of the same disk?
18:12:54 * adamw has no clue
18:13:08 <kparal> actually it might be useful sometimes
18:13:24 <Viking-Ice> hmm is it not just running it on /dev/sda3
18:13:28 <akshayvyas> i think there are two disks sda and sdb
18:13:33 <Viking-Ice> and the rest is just device filter
18:13:36 <tflink> sda3 is the one it's failing on
18:14:04 <tflink> Viking-Ice: yeah, you're right. I was misreading the command
18:14:35 <tflink> could this be another incarnation of the disk clearing issue we were seeing before?
18:15:26 <tflink> the first report is before that was fixed, I think
18:16:20 <tflink> and I agree with c#23 - that looks like its a different bug
18:16:59 <tflink> error on vgcreate instead of pvcreate --config
18:17:07 <adamw> well what we're discussing here is the steve/chris bug, based on the proposal
18:17:17 <adamw> so it boils down to...are we blocking on ridiculously long LV names?
18:17:32 <adamw> i'm gonna argue not a blocker as I just don't think anyone's going to do it except for shitsngiggles.
18:17:36 <tflink> I'd be OK with NTH, not sure about blocker
18:17:42 <adamw> yeah, -1/+1 is my inclination
18:17:44 <jreznik> -1+1
18:17:51 <spot> -1+1 from me too
18:17:53 <Viking-Ice> -1/+1
18:17:53 <akshayvyas> nth
18:18:22 <kparal> -1/+1
18:19:05 <tflink> proposed #agreed 885492 - RejectedBlocker AcceptedNTH - While the original report appears different from the later comments, those recent reports are too much of a corner case to justify blocking release. However, a tested fix would be considered after freeze.
18:19:14 <jreznik> ack
18:19:24 <akshayvyas> ack
18:19:24 <adamw> ack
18:19:27 <kparal> ack
18:19:30 <Viking-Ice> I dont think this is even nth
18:19:31 <Viking-Ice> ack
18:19:33 <tflink> #agreed 885492 - RejectedBlocker AcceptedNTH - While the original report appears different from the later comments, those recent reports are too much of a corner case to justify blocking release. However, a tested fix would be considered after freeze.
18:19:43 <tflink> #topic (889908) QA:Testcase Anaconda User Interface serial console - Partial Failure
18:19:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889908
18:19:47 <buggbot> Bug 889908: high, unspecified, ---, anaconda-maint-list, NEW , QA:Testcase Anaconda User Interface serial console - Partial Failure
18:19:48 <tflink> #info Proposed Blocker, anaconda, NEW
18:20:01 <Viking-Ice> for "INFO storage: executing action: [8] Create Device lvmvg fedora_f18vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxddddddddddddddddddffffffffffffffffffffffffffffffffffggggggggggggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj"
18:20:40 <Viking-Ice> so basically in previous bug he litterally is holding the key's down for lvm names
18:21:07 <tflink> Viking-Ice: yeah, purpously poking at handling of long vg names
18:21:47 <kparal> ad 889908: it worked for Beta
18:21:52 <BobLfoot> I'm confused are we discussing 889908 or soemthing else?
18:22:06 <kparal> BobLfoot: yes, that one
18:22:07 <tflink> BobLfoot: leftover from the previous bug
18:22:08 <adamw> i think viking's comment was lagged perhaps
18:22:11 <adamw> that's happened to him before
18:22:16 <Viking-Ice> yeah
18:22:51 <jreznik> kparal: are you able to retest?
18:22:53 <BobLfoot> I just saw the logs request - I'll need to repeat the test and gather the logs as the vm from that test no longe exists
18:22:54 <tflink> this one needs more information for triage but I'm not sure it's a clear blocker either way
18:23:01 <adamw> i thought console=ttyS0 wasn't meant to be needed any more?
18:23:27 <kparal> BobLfoot: have you booted anaconda with "serial" boot option for sure?
18:23:41 <kparal> adamw: they added it back IIRC
18:23:47 <adamw> brb, leak check
18:23:50 <Viking-Ice> adamw, why do you think that?
18:24:03 <Viking-Ice> you need it if you expect systemd to pick it up
18:24:03 <kparal> oh no, they added back "serial"
18:24:14 <kparal> console was always needed
18:24:28 <BobLfoot> yes kparal the QA:TestCase Instructions were followed verbatim
18:24:37 <tflink> kparal: aren't you talking about the install, though?
18:24:42 <tflink> I think this bug is about post-install
18:25:05 <tflink> and the console=ttyS0 not being added to the kernel args post-install
18:25:24 <Viking-Ice> yeah that's my understanding as well
18:25:28 <BobLfoot> correct tflink - post install the installed system did not offer a serial console unless the the boot instructions were manually altered
18:25:43 * kparal checking, give me a minute
18:25:58 <BobLfoot> Also post-install grub was not presented over the serial console
18:26:23 <tflink> which in my mind, is a bigger problem than the kernel args
18:26:41 <kparal> yes
18:26:48 <adamw> Viking-Ice: must've got mixed up with something else
18:27:04 <tflink> but assuming that the issue is as stated (and not changed by the logs), is this enough to be a blocker?
18:27:11 <Viking-Ice> atleast afaik know this is the correct way https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Enable_Serial_Console_in_Grub
18:27:31 <Viking-Ice> I wrote that after we had users with serial troubles
18:27:43 <adamw> " The installer must be able to complete an installation using all supported interfaces " is the criterion, i guess
18:27:56 <tflink> the install completes, though
18:27:58 <Viking-Ice> +1 blockert
18:28:03 <tflink> "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles"
18:28:14 <adamw> and...yeah,. that one.
18:28:31 <tflink> which doesn't explicitly mention serial consoles
18:28:31 * kparal needs one more minute
18:28:53 * BobLfoot remains neutral, but will retest and submit logs in next 24
18:29:40 <kparal> worksforme
18:29:48 <kparal> grub displayed over serial console
18:29:55 <kparal> boot messages ok
18:30:00 <Viking-Ice> did the grub config get updated after install ?
18:30:03 <kparal> can log in
18:30:14 <tflink> kparal: over serial console?
18:30:17 <kparal> tflink: yes
18:30:31 <adamw> so, -1 or punt, to try and figure out the difference...
18:30:35 <kparal> BobLfoot: I think you must have forgotten/mistyped the "serial" boot option
18:31:01 <kparal> because "serial" does exactly what you reported bug against
18:31:13 * BobLfoot retestring now
18:31:25 <kparal> -1 now, please reopen if you can reproduce
18:31:31 <Viking-Ice> I'm with adamw here -1  or punt
18:31:34 <BobLfoot> kparal: did you use TC3 or a later smoke?
18:31:39 <kparal> BobLfoot: smoke12
18:31:49 <kparal> netinst
18:32:37 <BobLfoot> ah I am using TC3 -- maybe fixed ?
18:33:03 <tflink> proposed #agreed 889908 - At the moment, this appears to be more of a documentation/testcase issue than a bug - reject as blocker if original reporter is unable to reproduce issue
18:33:18 <kparal> BobLfoot: please try smoke12
18:33:31 <adamw> ack
18:33:33 <akshayvyas> yep, ack
18:33:35 <kparal> ack
18:33:36 <tflink> kparal: IIRC, he doesn't have a huge amount of bandwidth, though
18:33:41 <Viking-Ice> ack
18:33:48 <tflink> #agreed 889908 - At the moment, this appears to be more of a documentation/testcase issue than a bug - reject as blocker if original reporter is unable to reproduce issue
18:34:11 <kparal> BobLfoot: then try TC3 again, maybe it was just a typo in "serial"
18:34:38 <tflink> if it gets reproduced with TC3, we can take it from there
18:34:47 <BobLfoot> console=ttyS0 serial
18:35:11 <tflink> wow, that didn't make much sense - if it's reproduced w/ TC3, we can figure out what to do from there
18:35:24 <tflink> #topic (890577) drop to dracut shell if /usr is on a btrfs subvol
18:35:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=890577
18:35:25 <tflink> #info Proposed Blocker, dracut, MODIFIED
18:35:27 <buggbot> Bug 890577: unspecified, unspecified, ---, dracut-maint, MODIFIED , drop to dracut shell if /usr is on a btrfs subvol
18:35:34 * BobLfoot is testing - move on
18:36:18 <Viking-Ice> +1 nth
18:36:30 <tflink> it sounds like this is a relatively clear blocker assuming that we're counting btrfs subvols as workable layouts
18:36:31 <Viking-Ice> afaik we dont officially support btrfs at the moment but I might be mistaken
18:37:19 <Viking-Ice> and based on comment 12 it's fixed alrady
18:37:25 <Viking-Ice> mean already
18:37:26 <kparal> it depends whether anaconda displays btrfs publicly or not
18:37:26 <fenrus02> f18 does
18:37:51 <adamw> tflink: for me the question is if we consider /usr a usable layout, but eh.
18:37:52 <fenrus02> kparal, it does .. if you select the modify part menu, you can select btrfs without trouble
18:37:59 <adamw> i'm okay with +1/
18:38:44 <fenrus02> adamw, /usr as a split part is not supported.  no clue what to do with btrfs subvols though (not really another part)
18:39:02 <adamw> oh right.
18:39:56 <tflink> why wouldn't it be supported as long as it's mounted in the initramfs?
18:40:24 <tflink> does dracut detect /usr as a boot-critical mount?
18:40:27 <fenrus02> tflink, iirc because dracut images dont mount /usr.  not positive
18:40:37 <adamw> anyways, +1 ok for me.
18:41:12 <tflink> proposed #agreed 890577 - AcceptedBlocker - Violates the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:41:17 <adamw> ack
18:41:19 <akshayvyas> ack
18:41:22 <Viking-Ice> weak ack
18:41:56 <Viking-Ice> anyone else ?
18:41:56 <jreznik> ack
18:42:09 <kparal> ack
18:42:21 <tflink> #agreed 890577 - AcceptedBlocker - Violates the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:42:59 <tflink> #topic (881624) After Update using fedup default system keyboard changes to US
18:43:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
18:43:04 <buggbot> Bug 881624: medium, unspecified, ---, wwoods, NEW , After Update using fedup default system keyboard changes to US
18:43:05 <tflink> #info Proposed Blocker, fedup, NEW
18:43:57 <fenrus02> wasnt /etc/sysconfig/i18n supposed to be copied to /etc/locale.conf in fedup ?
18:44:14 <Viking-Ice> yup
18:44:25 <Viking-Ice> it should transparently migrate that file
18:44:30 <fenrus02> that should prevent the bz above, no?
18:44:33 <tflink> I suspect that wouldn't end up being a fedup issue, though
18:44:46 <tflink> but an issue with whatever package owns /etc/sysconfig/i18n
18:44:57 <tflink> and/or /etc/locale.conf
18:45:13 <fenrus02> systemd
18:45:25 <Viking-Ice> there is a tracker bug this should be added to
18:46:08 <adamw> i think i put comments in this one?
18:46:11 <tflink> either way, definitely not fedup as I'm reading this. fedup-dracut, maybe but doubtful
18:46:39 <tflink> adamw: yeah, there was a new report since your last comment
18:46:59 <adamw> as i read it, the console keyboard after upgrade is done was correct
18:47:03 <adamw> X keyboard after upgrade is done was not
18:47:09 <adamw> and console layout used during the upgrade was wrong
18:47:21 <adamw> i thought i tested #3 and got a different result, i have not tested the X layout part
18:47:41 <tflink> the console layout during upgrade doesn't worry me much, the x layout would be at least NTH in my mind
18:47:58 <BobLfoot> kparal: 889908 was a serial typo - restesting TC3 works bug closed
18:48:09 <fenrus02> fixable via zero-day update, right tflink ?
18:48:16 <kparal> BobLfoot: thanks
18:48:38 <Viking-Ice> is this nto duplicate of 889699
18:48:41 <tflink> fenrus02: the x layout part? probably but it might be wise to confirm with wwoods
18:49:35 <Viking-Ice> in anycase afaik tell we should based on previous voting make 881624 nth
18:49:36 <tflink> Viking-Ice: kind of sounds like it, yeah
18:50:18 <tflink> the only layout part that couldn't be fixed post-release would be the layout during the actual upgrade but there shouldn't be much user input during that process
18:50:31 <adamw> Viking-Ice: this bug is older and that one contains no real useful info, so i don't see the point in duping.
18:51:05 <adamw> tflink: user input during upgrade is encryption passphrase
18:51:13 <adamw> it's not much, but it's pretty important, and it absolutely depends on keyboard layout.
18:51:14 <tflink> oh, good point
18:51:33 <adamw> unfortunately i'm not sure upgrade of an encrypted system is working at all, which is making it kinda hard to test
18:51:46 <adamw> i had this on my list for more investigation, but if you want to try too, please do...
18:52:12 <tflink> I think I have an encrypted system that is ready for upgrade testing - I just didn't get around to it the other week
18:52:22 <Viking-Ice> ok punt then for more data
18:53:02 <adamw> yeah, that might be best
18:53:09 <adamw> i hate to keep punting this thing, but gneesh. keyboards.
18:53:51 <tflink> proposed #agreed 881624 - It still isn't 100% clear on whether this is release blocking - the only part that isn't fixable with updates post-release is encryption passwords during upgrade. If that is an issue, accepted as a blocker. otherwise, will discuss when additional information on effects is available.
18:54:36 <Viking-Ice> ack
18:55:35 <akshayvyas> ack
18:56:12 <adamw> ack
18:56:22 <tflink> #agreed 881624 - It still isn't 100% clear on whether this is release blocking - the only part that isn't fixable with updates post-release is encryption passwords during upgrade. If that is an issue, accepted as a blocker. otherwise, will discuss when additional information on effects is available.
18:56:58 <tflink> #topic (890965) Fedup does not replace all F17 packages and leaves F17 boot option present
18:57:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=890965
18:57:02 <buggbot> Bug 890965: low, unspecified, ---, wwoods, NEW , Fedup does not replace all F17 packages and leaves F17 boot option present
18:57:03 <tflink> #info Proposed Blocker, fedup, NEW
18:57:29 <tflink> wwoods phrased it more generally than I did
18:57:34 <tflink> either way, -1 blocker
18:57:49 <Viking-Ice> -1/-1
18:57:53 <tflink> the important parts of this will be fixed once we release and it's not wise to do during fedup anyways
18:57:57 <adamw> packages that are removed from the distro are supposed to be obsoleted by something, i think, but meh.
18:58:04 <adamw> -1/-1.
18:58:31 <tflink> adamw: if you update the upgraded system w/ updates-testing after upgrade, most of those go away
18:58:34 <adamw> there's no problem with the f17 kernel still being available either, is there? i'm pretty sure that's intended.
18:58:35 <BobLfoot> I'll concur -1 after reviewing all comments
18:58:52 <tflink> adamw: yeah, that's intensional
18:59:01 <tflink> it'll go away after enough f18 kernel updates
18:59:03 <kparal> -1
18:59:58 <akshayvyas> "This used the F18 wallpaper and screensaver when checked but uname -r was fc17"
19:00:04 <tflink> proposed #agreed 890965 - RejectedBlocker - The behavior described is partially a side effect of the release process and fedup isn't supposed to be removing packages in the manner described. Most issues will be fixed once f18 is released.
19:00:09 <Viking-Ice> ack
19:00:20 <BobLfoot> ack
19:00:46 <kparal> ack
19:00:54 <tflink> the kernel issue should also go away once we release
19:00:58 <BobLfoot> May want to update QA:Testcase to indicate previous packages may remain but new version will work without error.
19:01:08 <akshayvyas> ack
19:01:15 <tflink> still running a f17 kernel, anyways
19:01:21 <tflink> same issue with stuff not being in updates yet
19:01:30 <tflink> #agreed 890965 - RejectedBlocker - The behavior described is partially a side effect of the release process and fedup isn't supposed to be removing packages in the manner described. Most issues will be fixed once f18 is released.
19:01:38 <tflink> #topic (827654) Fedora 18 installer displays nothing on MacBook 3,1 internal display
19:01:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=827654
19:01:43 <buggbot> Bug 827654: unspecified, unspecified, ---, pjones, NEW , Fedora 18 installer displays nothing on MacBook 3,1 internal display
19:01:44 <tflink> #info Proposed Blocker, grub2, NEW
19:02:46 <tflink> I'm thinking this is a little too hardware specific to block over
19:02:47 <Viking-Ice> based on adamw intotion to graphics hw that would be a non blocker
19:03:35 <jreznik> yep
19:04:21 <tflink> proposed #agreed 827654 - RejectedBlocker - This is too hardware specific to justify blocking the release of F18
19:04:39 <Viking-Ice> ack
19:04:42 <akshayvyas> ack
19:05:50 <kparal> ack
19:05:52 <tflink> #agreed 827654 - RejectedBlocker - This is too hardware specific to justify blocking the release of F18
19:06:03 <tflink> OK, that's all of the blockers that I had on my list
19:06:21 <adamw> ack
19:06:40 <tflink> but I think 2 more have been added during the meeting
19:06:59 <adamw> +1 nth on that last one?
19:07:04 <Viking-Ice> 881887 got decided by fesco "fix firstboot/get into final compose if it turns out to
19:07:04 <Viking-Ice> always be offering en_US for firstboot. Otherwise let all these be
19:07:04 <Viking-Ice> fixed in updates"
19:07:09 <adamw> just on the offchance a fix shows up
19:07:43 <tflink> not sure I'd be all that enthused about changing grub so late
19:07:58 <adamw> the fix would likely be kernel, i think.
19:08:05 <adamw> it'll be UEFI modesetting stuff.
19:08:06 <nirik> yeah, It seems like this would have been filed by someone if it was happening. (the firstboot one)
19:08:10 <Viking-Ice> which bugs are we talking about here?
19:08:19 <jreznik> tflink: please go on through the added ones
19:08:35 <adamw> Viking-Ice: i'm still on 827654
19:08:42 <adamw> just wondering if we want to make it NTH
19:09:00 <Viking-Ice> adamw, we have already agree upon it not being a blocker
19:09:11 <adamw> Viking-Ice: ...
19:09:31 <tflink> adamw: I'm not -1 NTH on that but I'm not sure about +1 NTH either
19:09:49 <Viking-Ice> I dont think it's common enough to warrant either
19:11:25 <adamw> okay.
19:11:51 <adamw> next bug, then
19:12:10 <tflink> #topic (881887) firstboot: migration to /etc/hostname, /etc/vconsole.conf, /etc/locale.conf
19:12:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881887
19:12:15 <buggbot> Bug 881887: unspecified, unspecified, ---, msivak, NEW , firstboot: migration to /etc/hostname, /etc/vconsole.conf, /etc/locale.conf
19:12:16 <tflink> #info Proposed Blocker, firstboot, NEW
19:12:22 <nirik> this basically needs testing, IMHO.
19:12:46 <nirik> install with non en_US, reboot, is firstboot in your $lang, or en_US.UTF8?
19:12:55 <Viking-Ice> yeah but fesco already decided this one
19:13:10 <Viking-Ice> as I mentioned earlier
19:13:53 * adamw is doing a French smoke12 install atm.
19:14:20 <adamw> looks like stevet tested
19:14:30 <adamw> i'm almost sure i've tried this before and it's worked as well, but i wanted to double-check.
19:14:35 <nirik> it sorta hits the firstboot critera.
19:14:53 <nirik> there's also another bug against alpha about it, that the reporter says was fixed.
19:15:09 <adamw> my french install is nearly complete
19:15:24 <tflink> it's already been un-proposed as a blocker :)
19:15:52 <Viking-Ice> yup
19:16:01 <nirik> so, I think this is not a problem. Hurray.
19:16:08 <adamw> we can move on, i'll sound the awooga to come back to it if my test comes up bad.
19:16:36 <Viking-Ice> interesting device that awooga
19:17:14 <tflink> #info this has already been un-proposed as a blocker as the result could not be reproduced, will be re-proposed if it turns out to be a problem, though
19:17:26 <tflink> #topic (883555) Anaconda is missing croatian keyboard layout
19:17:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=883555
19:17:26 <tflink> #info Proposed Blocker, libxklavier, NEW
19:17:28 <buggbot> Bug 883555: high, unspecified, ---, rstrode, NEW , Anaconda is missing croatian keyboard layout
19:17:51 <nirik> mor keyboards!
19:18:06 <nirik> did we come to any conclusion about this keyboard mess?
19:18:15 <Viking-Ice> punt for input from devs
19:18:31 <Viking-Ice> we kinda need to map anaconda keyboard interaction to further grasp what's happening there
19:18:34 <tflink> Viking-Ice: it's been waiting for input from devs for a month now
19:18:46 <adamw> this is one specific case that's a bit different from the mess i've been poking
19:18:55 <adamw> for some reason, one particular layout that GNOME offers is missing from anaconda
19:19:04 <adamw> i'm not sure this passes the last-bug smell test
19:19:14 <jreznik> well, is component the correct one?
19:19:22 <adamw> it's a reasonable guess
19:19:26 <Viking-Ice> tflink, cant you just throw something in the booth where the anaconda developers reside
19:19:35 <adamw> Viking-Ice: tflink is remote. we're all remote.
19:20:00 <Viking-Ice> dammit was thinking wet note was motivating
19:20:30 <adamw> kparal can throw stuff at the brno devs, but aside from that, no dice.
19:20:32 <jreznik> it's safer for some developers some people are remote :)
19:20:55 <tflink> jreznik: not sure what you're implying there
19:21:07 <tflink> :)
19:21:08 <jreznik> adamw: well, only a few guys are here but my friend starts in anaconda team in March :)
19:21:10 <adamw> Croatian was offered in F17, so this is a regression
19:21:42 <Viking-Ice> we need more data before we either accept or dismiss
19:21:55 <adamw> what data?
19:21:59 <jreznik> halfline seems not to be available right now
19:22:05 <adamw> we don't know the cause, but the nature of the bug seems pretty simple.
19:22:14 <adamw> a layout we used to offer and that it looks like we ought be offering, is not offered.
19:22:18 <Viking-Ice> "We get it from querying the system for supported layouts." query what
19:22:22 <jreznik> could we make it at least nth? you don't have to think about "last bug one"
19:22:28 <adamw> anaconda asks xkb via xklavier.
19:22:33 <adamw> that's why the bug is assiged to xklavier.
19:22:35 <Viking-Ice> it's an nth for sure
19:22:47 <adamw> yeah, +1 nth is a no-brainer, we can agree on that much at least
19:23:05 <adamw> but GNOME does something very similar, and GNOME has the layout in its list. so there's something screwy going on there.
19:23:49 <tflink> proposed #agreed 883555 - AcceptedNTH - Not sure if this is a release blocking issue without more information and/or triage but a tested fix would be considered after freeze.
19:24:27 <Viking-Ice> ack
19:24:31 <akshayvyas> ack
19:25:21 <adamw> ack for that much
19:25:49 <adamw> i'm a narrow -1 blocker as i don't think we'd hold the release a week for this if it came down to it
19:26:17 <tflink> same here
19:26:22 <akshayvyas> adamw: agree
19:26:26 <Viking-Ice> I'm more towards blocker because I dont want to leave all croatioans with out a working keyboard
19:26:43 <Viking-Ice> let me put this the other way would it be a blocker if it was a us keyboard layout
19:27:05 <adamw> sure, but we have way more users using US...
19:27:25 <Viking-Ice> aha and where do you draw that line
19:27:33 <Viking-Ice> 1000 users 10000 users 1000000 users etc
19:27:41 <adamw> somewhere between US and Croatian, i think. :)
19:27:46 <Viking-Ice> canada
19:27:55 <adamw> i wouldn't block on any canadian layout, no
19:28:05 <jreznik> you should be still able to select right keyboard postinstall and fix everything that needed that keyaborad
19:28:18 <tflink> can't you select layout from gdm?
19:28:21 <adamw> no.
19:28:28 <adamw> this is something that makes people...unhappy.
19:28:37 <adamw> but anyway, we're going a bit sideways...
19:28:42 <tflink> yep
19:28:45 <Viking-Ice> think of encryption!
19:28:51 <Viking-Ice> hehe
19:29:06 <Viking-Ice> anyway I'm clocking out from work and heading home
19:29:09 <Viking-Ice> later...
19:29:32 <tflink> I don't think this would affect encryption since you can't select the layout during install
19:29:42 <tflink> anyhow, we're done with all the blockers for today
19:30:17 <adamw> we didn't make a call on this one.
19:30:30 <tflink> oh, thanks. I thought I did the #agreed
19:30:31 <jreznik> so only nth or add -1 blocker_
19:30:33 <adamw> we need to make a call, or state what we're waiting for.
19:30:41 <adamw> yes, you did the #agreed, but it did not relate to blocker status at all.
19:30:50 <adamw> we were just agreeing on NTH while we continued to discuss blocker
19:30:58 <jreznik> damn I switched to Czech keyboard, all layouts should be banned except the QWERTY US one!
19:31:19 <tflink> ?
19:31:28 <tflink> so punt or -1 blocker
19:31:34 <tflink> I'm more -1 than +1
19:31:54 <akshayvyas> i think punt is good
19:31:58 <tflink> as much as I dislike the idea of leaving out a keymap, I also can't see slipping another week for just this
19:32:15 <jreznik> -1, it would not pass that smell test...
19:32:57 <adamw> punt for what?
19:32:58 <tflink> #undo
19:32:58 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xada5150>
19:33:07 <adamw> i don't want to punt without deciding what we're punting _for_
19:34:36 <tflink> proposed #agreed 883555 - RejectedBlocker AcceptedNTH - While this is a nasty bug for croatian users, this keymap isn't common enough to justify blocking the release of F18 for. However, a tested fix would be considered after freeze.
19:35:21 <jreznik> ack
19:35:25 <adamw> ack
19:35:27 <akshayvyas> ack
19:35:30 <kparal> ack
19:35:44 <tflink> #agreed 883555 - RejectedBlocker AcceptedNTH - While this is a nasty bug for croatian users, this keymap isn't common enough to justify blocking the release of F18 for. However, a tested fix would be considered after freeze.
19:35:52 <tflink> OK, now we're done with all the blockers
19:35:54 <tflink> :)
19:36:01 <tflink> we're also over 2.5 hours
19:36:21 <tflink> do we want to do all the proposed NTH? just a few cherry-picked ones or deal with that tomorrow?
19:36:31 <tflink> there are a couple that I'd like to go over, at least
19:36:33 <jreznik> could we do a quick recap of currently accepted blockers (unresolved ones?)
19:36:55 <adamw> cherrypick nth and go over accepted blockers we haven't looked at might be good
19:37:19 <jreznik> yep
19:37:20 <tflink> the ones that jump out at me are 889760, 891142 and 856270
19:37:29 <tflink> anyone have others?
19:39:03 <adamw> 887816?
19:39:26 <adamw> or was that a post-freeze thing?
19:39:46 <adamw> oh yeah, looks like post-freeze stuff.
19:40:51 <adamw> so yeah, those 3.
19:41:54 <tflink> #topic (889760) Update to latest sugar bugfix release
19:41:54 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889760
19:41:54 <tflink> #info Proposed NTH, sugar, NEW
19:41:55 <buggbot> Bug 889760: unspecified, unspecified, ---, simon, NEW , Update to latest sugar bugfix release
19:42:08 <tflink> +1 NTH - it sounds like it would be blocker for a primary DE
19:43:10 <tflink> proposed #agreed 889760 - AcceptedNTH - This would be a release blocking issue for a primary DE and therefore NTH for a secondary DE like sugar.
19:43:37 <adamw> +1
19:43:40 <adamw> ack
19:43:49 <jreznik> ack
19:43:54 <akshayvyas> ack
19:44:33 <tflink> #agreed 889760 - AcceptedNTH - This would be a release blocking issue for a primary DE and therefore NTH for a secondary DE like sugar.
19:44:42 <tflink> hrm, we need to clone this next one, I think
19:45:05 <tflink> #topic (891142) (CVE-2012-6085) CVE-2012-6085 GnuPG: read_block() corrupt key input validation
19:45:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=891142
19:45:10 <buggbot> Bug 891142: low, low, ---, security-response-team, NEW , CVE-2012-6085 GnuPG: read_block() corrupt key input validation
19:45:10 <tflink> #info Proposed NTH, vulnerability, NEW
19:45:54 <tflink> +1 NTH for the fix, though
19:46:15 <adamw> yeah, I guess a fedora-specific report is good. +1 nth
19:47:30 <tflink> adamw: we got scolded the last time we added AcceptedNTH to a security bug
19:47:48 <tflink> something about breaking their scripts
19:47:53 <adamw> right.
19:47:56 <adamw> i'll take care of it
19:49:05 <adamw> can we just vote something through so i can handle it in post? :)
19:49:15 <tflink> proposed #agreed 891142 - AcceptedNTH - While this isn't severe enough to justify blocking the release of F18, it is a security issue that would be good to fix prior to release. A tested fix would be considered after freeze. Note that a fedora-specific bug will be filed to cover the same issue. The AcceptedNTH designation will be transfered to that new report
19:49:35 <tflink> adamw: if you can be patient enough to wait for me to be done typing, yes :)
19:49:41 <adamw> NO
19:49:46 <adamw> ack
19:50:14 <nirik> sure, ack...
19:50:23 <akshayvyas> ack
19:51:19 <tflink> #agreed 891142 - AcceptedNTH - While this isn't severe enough to justify blocking the release of F18, it is a security issue that would be good to fix prior to release. A tested fix would be considered after freeze. Note that a fedora-specific bug will be filed to cover the same issue. The AcceptedNTH designation will be transfered to that new report
19:51:26 <tflink> #topic (856270) [abrt] blueman-1.23-3.fc18: __init__.py:360:__init__:OSError: libpulse-mainloop-glib.so.0: cannot open shared object file: No such file or directory
19:51:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856270
19:51:31 <buggbot> Bug 856270: unspecified, unspecified, ---, nushio, ON_QA , [abrt] blueman-1.23-3.fc18: __init__.py:360:__init__:OSError: libpulse-mainloop-glib.so.0: cannot open shared object file: No such file or directory
19:51:32 <tflink> #info Proposed NTH, blueman, ON_QA
19:52:10 <tflink> I read this bug as pulseaudio having issues without this package on XFCE and LXDE
19:52:24 <tflink> which would be release blocking for primary DEs
19:52:55 <jreznik> +1
19:53:24 <tflink> proposed #agreed 856270 - AcceptedNTH - This causes problems with pulseaudio for LXDE and XFCE which would be a release blocking issue for primary DEs and therefore NTH for secondary DEs. A tested fix would be considered after freeze.
19:53:45 <adamw> ack
19:53:52 <jreznik> ack
19:55:07 <tflink> #agreed 856270 - AcceptedNTH - This causes problems with pulseaudio for LXDE and XFCE which would be a release blocking issue for primary DEs and therefore NTH for secondary DEs. A tested fix would be considered after freeze.
19:55:19 <tflink> OK, on to the accepted blockers
19:55:28 <tflink> #topic (858628) Some buttons and labels in Anaconda can't be localized
19:55:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858628
19:55:33 <buggbot> Bug 858628: unspecified, unspecified, ---, anaconda-maint-list, CLOSED ERRATA, Some buttons and labels in Anaconda can't be localized
19:55:34 <tflink> #info Accepted Blocker, anaconda, MODIFIED
19:55:50 <tflink> er, accepted blockers that are not ON_QA or VERIFIED
19:56:49 <tflink> damnation
19:56:55 <tflink> this was closed since I made my list
19:57:17 <jreznik> so for this one, we need separate bugs for any new translation bugs... it became mess
19:57:32 <tflink> #info this bug has already been closed, no need for review
19:57:58 <tflink> #topic (872739) AttributeError: 'NoneType' object has no attribute 'get'
19:58:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872739
19:58:03 <buggbot> Bug 872739: unspecified, unspecified, ---, anaconda-maint-list, ASSIGNED , AttributeError: 'NoneType' object has no attribute 'get'
19:58:03 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
19:59:00 <adamw> sigh. this has been re-opened in a substantially different reproducer from mine and then just left sitting there
19:59:00 <tflink> bah, no tb
19:59:47 <adamw> needinfo, ask chris to file separately with the tb, ask anaconda team to take a look?
20:00:10 <tflink> yeah, I suspect that this isn't the same issue - that tb is pretty generic
20:00:25 <nirik> I thought we didn't want to allow btrfs /boot this time around?
20:00:50 <tflink> #info This has been reopened with a significantly different reproducer. Ask new reporter to file a new bug with the tb info from this case
20:01:41 <jreznik> make sense this way
20:02:00 <adamw> we've had a few of these, maybe in f19 timeframe we need to improve libreport wrt anaconda someho
20:03:01 * tflink assumes no more input on this one
20:03:04 <tflink> #topic (888089) ValueError: A RAID0 set requires at least 2 members
20:03:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888089
20:03:04 <tflink> #info Accepted Blocker, anaconda, POST
20:03:06 <buggbot> Bug 888089: unspecified, unspecified, ---, dlehman, POST , ValueError: A RAID0 set requires at least 2 members
20:03:15 <tflink> looks like a patch is available but is waiting for review
20:03:45 <tflink> or has this already been fixed
20:03:49 <adamw> cmurf's last comment is slightly worrying too
20:04:16 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-December/002581.html looks like it was an ack
20:04:39 * jreznik already pointed anaconda guys to this what's the state...
20:04:47 * adamw checks git logs
20:05:45 <adamw> i don't see the commit on f18-branch
20:05:51 <adamw> so looks like it was acked but not pushed
20:07:00 <adamw> comment added to bug
20:07:30 <tflink> #info the patch for this bug was acked but doesn't appear to have been pushed to git, ask anaconda devs to push the patch
20:07:51 <tflink> #topic (883075) fedup upgrading is too quiet
20:07:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=883075
20:07:51 <tflink> #info Accepted Blocker, fedup-dracut, MODIFIED
20:07:53 <buggbot> Bug 883075: low, unspecified, ---, wwoods, MODIFIED , fedup upgrading is too quiet
20:08:42 <tflink> I need to build a new upgrade.img to test this
20:08:47 <tflink> on my list of stuff to do today
20:08:59 <jreznik> tflink: thanks
20:09:06 <adamw> then do we need a new 'official upgrade.img'? or what?
20:09:14 <tflink> #action tflink to build new upgrade.img to test this
20:09:28 <tflink> adamw: depends on what the goal is
20:09:42 <tflink> the autodetection of the upgrade.img won't be updated until release
20:10:17 <tflink> assuming that everything is fixed and we get a new fedup-dracut build, it would show up in the next TC/RC/smoke build
20:10:50 <tflink> #info this is reported to be fixed, needs testing to verify
20:11:10 <adamw> ok
20:11:20 <tflink> adamw: did that answer your question?
20:11:46 <tflink> in order to test with a TC/RC/smoke build, the --instrepo arg is needed on fedup
20:12:42 <adamw> yeah
20:12:48 <tflink> #topic (889562) Console keymap set to "us" if you install with a keymap not provided by systemd-localed
20:12:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889562
20:12:52 <buggbot> Bug 889562: unspecified, unspecified, ---, systemd-maint, NEW , Console keymap set to "us" if you install with a keymap not provided by systemd-localed
20:12:53 <tflink> #info Accepted Blocker, systemd, NEW
20:13:02 <adamw> so, this is the one i need to do some more testing on, to see how fuzzy systemd's matching is
20:13:12 <adamw> i'm not sure there's much to do here besides just try a bunch of installs with 'questionable' layouts :/
20:14:48 <tflink> yeah, that sounds about right
20:14:53 <adamw> #info adamw still has to test and see how many layouts are practically affected by this
20:15:11 <tflink> #info this needs more poking to get an idea of how many keymaps are affected
20:15:15 <tflink> #undo
20:15:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x15da0a90>
20:15:37 <tflink> #topic (876218) pxeboot/netinst + nfsiso repo = hang on reboot
20:15:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876218
20:15:37 <tflink> #info Accepted Blocker, systemd, ASSIGNED
20:15:39 <buggbot> Bug 876218: unspecified, unspecified, ---, systemd-maint, ASSIGNED , pxeboot/netinst + nfsiso repo = hang on reboot
20:16:04 <tflink> sounds like triage is still ongoing with this
20:16:14 <adamw> yeah, looks like it's being worked on...
20:16:49 <tflink> #info triage is ongoing with this bug, progress is being made
20:17:17 <tflink> that appears to be all of the accepted blockers that aren't already VERIFIED or ON_QA
20:17:49 <tflink> anything I missed?
20:18:12 <jreznik> for this one - kamil provided more info today
20:18:34 <adamw> so looks like we really need to do a TC4 with all the pending fixes to clean those up
20:18:40 <adamw> and then we have a small but non-zero set of blockers to bash on
20:18:42 <tflink> jreznik: I meant are there any bugs that I missed
20:18:56 <tflink> #topic Open Floor
20:18:57 <jreznik> tflink: sorry, it was unrelated
20:19:03 <tflink> jreznik: no worries
20:19:14 <tflink> just wasn't sure if I was clear on what I was asking
20:19:30 <tflink> #info TC4 will be requested soon
20:20:00 <nirik> so, how screwed are we for tomorrow?
20:20:02 <nirik> :)
20:20:10 <jreznik> adamw: clean up will be nice, could you take care of requesting tc4 today? dennis seems to be waiting for some work :)
20:20:46 <jreznik> nirik: do not talk about tmrw!
20:20:55 <nirik> alright. :)
20:21:28 <adamw> yes, i'm going to take a shower, then request tc4, then get down to some testing.
20:21:33 <tflink> jreznik: so go/no-go is kind of like fight club? "the first rule of go/no-go is that you don't talk about go/no-go?"
20:21:49 <jreznik> lol
20:22:36 <tflink> anyways, I assume that there are no other topics which need to be brought up now?
20:23:03 <nirik> oh, if there's a stable list for later we can push some things stable and clean up the lists some.
20:23:09 <jreznik> well quick recap - the keymap mess has to be sorted out, nfs hang on reboot, for vnc I'll poke Radek tmrw + that hold on POST one
20:23:21 <tflink> #info The next scheduled blocker review meeting will be on 2013-01-09 if needed
20:23:25 <jreznik> nirik: that's the idea
20:24:04 <tflink> if there are no other topics ...
20:24:13 * tflink sets fuse for some amount of time
20:24:32 <tflink> Time for testing!
20:24:44 <tflink> and at the end ... there will be cake!
20:25:01 * tflink will send out minutes shortly
20:25:06 <tflink> Thanks for coming everyone!
20:25:08 <tflink> #endmeeting