17:13:22 <tflink> #startmeeting f18final-blocker-review-3
17:13:22 <zodbot> Meeting started Mon Dec 10 17:13:22 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:13:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:13:22 <tflink> #meetingname f18final-blocker-review-3
17:13:22 <zodbot> The meeting name has been set to 'f18final-blocker-review-3'
17:13:22 <tflink> #topic Roll Call
17:13:30 <adamw> morning
17:13:36 * kparal here
17:13:57 * jskladan zzzaps a bug
17:14:07 * kparal zzzaps jskladan
17:14:43 * jskladan is electrocuted & turns into a bot :)
17:15:06 * satellit listening
17:15:11 * mkrizek lurks
17:15:59 <tflink> cool, sounds like we have enough people to get started
17:16:12 <tflink> #topic Introduction
17:16:18 <tflink> Why are we here?
17:16:18 <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:16:23 <tflink> #info We'll be following the process outlined at:
17:16:23 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:16:29 <tflink> #info The bugs up for review today are available at:
17:16:29 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:16:57 <tflink> #info note that due to the number of currently proposed blockers, the list is currently being filtered for bugs which are ready for discussion
17:17:10 * rbergeron passes around stress balls and other devices
17:17:23 <tflink> #link http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html
17:17:35 <tflink> #info The criteria for release blocking bugs can be found at:
17:17:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:17:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:17:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:18:04 <tflink> #info the current full list of blocker/nth bugs is at:
17:18:10 <tflink> #info 28 Proposed Blockers
17:18:10 <tflink> #info 14 Accepted Blockers
17:18:10 <tflink> #info 26 Proposed NTH
17:18:10 <tflink> #info 3 Accepted NTH
17:18:23 <tflink> #info the list of bugs ready for discussion is at:
17:18:36 <tflink> #info 16 Proposed Blockers deemed ready for discussion
17:19:04 <tflink> if there are no objections, we'll get started
17:19:23 <tflink> #topic (885378) AttributeError: 'NoneType' object has no attribute 'name'
17:19:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885378
17:19:28 <buggbot> Bug 885378: unspecified, unspecified, ---, anaconda-maint-list, NEW , AttributeError: 'NoneType' object has no attribute 'name'
17:19:28 <tflink> #info Proposed Blocker, anaconda, NEW
17:19:58 <tflink> this is a bug about using existing encrypted VGs for install
17:20:18 <tflink> could be a dupe of 882722 which is also a proposed blocker, waiting for more testing with anaconda-18.37
17:21:13 <kparal> encrypted VGs should work per criteria
17:21:24 <kparal> seems +1 blocker for me
17:22:00 <tflink> why anyone would choose to use encrypted VGs other than the fact that it's somewhat default is a mystery to me, but that's a different topic
17:22:13 <adamw> well
17:22:15 <adamw> from the forum thread...
17:22:18 <adamw> "erf
17:22:20 <adamw> test thread
17:22:21 <kparal> what's weird on encrypted VG?
17:22:23 <adamw> "Yes. I was able to reuse lvm volumes on LUKS encrypted partition on bare hardware."
17:22:32 <adamw> oh, i see, n/m.
17:22:44 <tflink> kparal: you lose all the advantages of LVM when you encrypt the VG
17:22:51 <tflink> unless somethings changed from the last time I tried that
17:22:56 <kparal> ah, we should say encrypted LV here
17:23:12 <tflink> good point, I just saw that
17:23:17 <kparal> why? I can extend encrypted LV just fine
17:23:26 <kparal> I used encrypted LVs in the past
17:23:27 <tflink> encrypted LVs are different
17:23:43 <kparal> "Also, I only see it when trying to create or reuse an *encrypted* LV."
17:23:47 <kparal> comment 16
17:24:03 <tflink> I'm talking about the encryption of the whole VG like what happens when you use lvm and click "encrypt" in anaconda
17:24:18 <kparal> tflink: that's basically encrypted PV, right?
17:24:20 <tflink> you can't change LVs unless you unmount everything
17:24:32 <adamw> we seem to be getting a bit off track
17:24:34 <tflink> yep
17:24:45 <adamw> is re-use of an encrypted LV a blocking issue? i guess it is.
17:24:48 <adamw> so +1.
17:24:55 <tflink> are we blocking on reuse of encrypted disks?
17:25:11 <kparal> I think there are use cases for both approaches. I used encrypted LVs in the past, I use encrypted PV (VG) now
17:25:35 <kparal> " 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 "
17:25:45 <kparal> that includes re-use, doesn't it?
17:25:54 <jreznik> and encrypted too?
17:26:01 <tflink> is reusing an encrypted layout a workable layout?
17:26:51 <tflink> it sounds like we're mostly +1, though
17:26:59 <kparal> I believe it falls into that criterion
17:26:59 <adamw> it depends how you read 'create and install to', but i'm okay with saying 'yes'.
17:27:15 <adamw> when i was writing it i wasn't really thinking about re-use, but it seems reasonable to cover it.
17:27:57 <tflink> proposed #agreed 885378 - AcceptedBlocker - Violates the following F18 final release criterion for reuse of encrypted LVM layouts: "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"
17:27:58 <jreznik> well under what criteria you'd like to accept it? but seems people are really trying to do so
17:28:29 <kparal> ack
17:28:30 <jskladan> tflink: ack
17:28:33 <mkrizek> ack
17:28:50 <tflink> #agreed 885378 - AcceptedBlocker - Violates the following F18 final release criterion for reuse of encrypted LVM layouts: "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"
17:28:56 <adamw> jreznik: this criterion works okay
17:29:02 <tflink> #topic (885124) Notifications stays after clicking on 'x' button
17:29:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885124
17:29:02 <tflink> #info Proposed Blocker, gnome-shell, NEW
17:29:04 <buggbot> Bug 885124: unspecified, unspecified, ---, otaylor, NEW , Notifications stays after clicking on 'x' button
17:29:39 <kparal> hah
17:30:20 <kparal> anyone else can test it now? is there a way to close the notification in another way?
17:30:21 <tflink> the criterion in question is "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
17:30:54 <jreznik> any gnome user to take a look? :)
17:30:55 <kparal> it's a nuisance, except if it causes problem on LiveCDs
17:31:04 <adamw> you can use empathy from a live CD, sure.
17:31:17 <kparal> if it blocked some important messages, for example...
17:31:22 <adamw> or anything else
17:31:33 <adamw> it doesn't block messages, it rather prevents you getting rid of them
17:31:34 * kparal is booting
17:31:45 <adamw> i just checked, i'm seeing this too - it seems to affect all notifications, you can't dismiss them at all
17:31:45 * tflink is starting a VM that needs to be updated
17:32:00 <adamw> i've got five in my notification panel right now, can't get rid of any one of them
17:32:06 <adamw> so as a polish bug that'd affect the live image, +1
17:32:11 <kparal> adamw: so after first notification appears, you'll see no other, because the first one can't be dismissed?
17:32:13 <jreznik> isn't there any automatic autohide?
17:32:21 <adamw> kparal: no, that's not how shell notifications work.
17:32:23 <adamw> yes, there is.
17:32:58 <jreznik> if it fades away after timeout, I'm more NTH (if I understand correctly)
17:33:28 <adamw> yes, that bit works. but the notification isn't *gone*,
17:33:55 <adamw> so this is how notifications work in shell: they pop up for a few seconds then fade. but they aren't _gone_ at that point.
17:34:01 <kparal> aha, so it hides, it's just not removed from the message tray
17:34:09 <adamw> if you open overview or mouse the the bottom of the screen and wait a second, the notification tray shows up, and it is in there.
17:34:23 <kparal> I'm -0 blocker here, +1 NTH
17:34:23 <adamw> existing notifications show up as icons, you click on the notification, it opens up again.
17:34:32 <adamw> yeah, this one is close
17:34:41 <adamw> it's not functioning correctly exactly but it's not hideously broken
17:34:46 <adamw> it's more polish than anything
17:34:55 <kparal> I have found a workaround
17:35:00 <mkrizek> -1 blocker, +1 NTH
17:35:02 <kparal> adamw: try to click on that message, not on X
17:35:11 <jreznik> so -1 blocker/+1 NTH
17:35:19 <adamw> kparal: that doesn't do the same thing.
17:35:30 <adamw> kparal: for some notifications it has the same *effect*, but for others, it will for e.g. bring up the app.
17:35:31 * jreznik really should boot gnome
17:35:59 <kparal> adamw: ok, I don't know. I saw notification with buttons, nothing else
17:36:15 <kparal> I usually click _on_ them to hide them
17:36:15 <adamw> kparal: if you click on the message in an setroubleshoot notification, it will open setroubleshoot gui.
17:36:20 <adamw> but hey, it gets rid of the notification too.
17:36:28 <adamw> i guess i'm +/-0 , i kinda hate polish bugs, but eh.
17:36:40 <jreznik> so NTH?
17:36:49 <kparal> adamw: you can also right click on the icon in message tray -> remove
17:36:54 <kparal> 2 workarounds now
17:37:17 <tflink> it sounds like we're broadly -1/+1, then?
17:37:27 <adamw> sure.
17:37:28 <jreznik> yep
17:37:28 <tflink> well, more -1 than +1 blocker
17:37:30 <kparal> yes
17:37:42 <kparal> I'm -0.5 blocker now
17:37:50 <kparal> still +1 nth
17:38:29 <tflink> proposed #agreed 885124 - RejectedBlocker AcceptedNTH - While this is a polish issue with the default interface, there are workarounds and it does not seem to be enough to block release over. Accepted as NTH for F18 final and a tested fix would be considered past freeze.
17:38:38 <jreznik> ack
17:38:46 <kparal> ack
17:39:45 <adamw> ack
17:40:06 <mkrizek> ack
17:40:11 <tflink> #agreed 885124 - RejectedBlocker AcceptedNTH - While this is a polish issue with the default interface, there are workarounds and it does not seem to be enough to block release over. Accepted as NTH for F18 final and a tested fix would be considered past freeze.
17:40:20 <tflink> #topic (866887) the default keyboard layout isn't comfortable with the selected language
17:40:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866887
17:40:26 <buggbot> Bug 866887: unspecified, unspecified, ---, vpodzime, POST , the default keyboard layout isn't comfortable with the selected language
17:40:26 <tflink> #info Proposed Blocker, anaconda, POST
17:40:59 <tflink> my understanding of the short version of this bug is:
17:41:18 <tflink> if you install w/ a non-US keyboard and select a different layout, that layout isn't the default post-install
17:41:32 <tflink> it _is_ added and can be used but the US layout is still default
17:42:29 <kparal> I'm not really sure this is exactly this issue
17:42:36 <tflink> I could be wrong
17:44:31 <kparal> should we skip this one and I'll present you TLDR version on wednesday? I can talk to Vratislav personally
17:44:41 <tflink> sure, that works for me
17:45:07 <tflink> #info it sounds like we are missing some info on this bug, will re-visit when more information is available
17:45:14 <kparal> I think me and Vratislav already touched this issue in the past
17:45:26 <jreznik> kparal: ping me, I'll join you :)
17:45:44 <tflink> #topic (885641) partitioning: Continue says I don't have enough space, Done says I do
17:45:47 <kparal> #action kparal to ask Vratislav about 866887 and present a summary on wednesday. also ping jreznik
17:45:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885641
17:45:49 <buggbot> Bug 885641: unspecified, unspecified, ---, anaconda-maint-list, NEW , partitioning: Continue says I don't have enough space, Done says I do
17:45:50 <tflink> #info Proposed Blocker, anaconda, NEW
17:46:29 <kparal> watch the video for this one
17:47:53 <tflink> kparal: thanks. that just forced logout and I lost all of my windows :-P
17:48:06 <kparal> tflink: I think you need to report a bug ;)
17:48:16 <tflink> there will be a slight delay while I get everything setup again
17:48:32 * Viking-Ice note to self record more
17:49:04 <jreznik> video does not work for me - I see one click and then it ends
17:50:06 <kparal> :/
17:50:12 <kparal> it's standard ogg
17:50:24 <kparal> it plays in totem fine here
17:50:28 <adamw> as described in the bug I'm +1 - if anaconda knows you don't have space for the install, but there's a path to get to 'begin installation' without being warned, that's bad.
17:50:36 <Viking-Ice> is it triggered by double cancel?
17:50:41 <tflink> it played fine when I downloaded it
17:50:41 <kparal> Viking-Ice: I don't think so
17:50:49 <adamw> is this the custom part path or guided part? /me doesn't feel like clicking on the video
17:50:55 <Viking-Ice> in anycase it's an fatal error
17:50:59 <Viking-Ice> +1 blocker
17:50:59 <kparal> adamw: guided
17:50:59 <adamw> if custom part, we can use the 'rejecting obviously invalid operations' bit from beta
17:51:02 <adamw> ah.
17:51:28 <kparal> adamw: seems like Done does not perform size checks
17:51:35 <kparal> but Continue does
17:51:43 <tflink> this looks a little bit like "doctor it hurts", though
17:51:56 <kparal> tflink: why is that? Done is completely valid
17:51:56 <jskladan> ?
17:52:07 <tflink> you canceled out of the reclaim dialog twice
17:52:23 <kparal> tflink: I'm not sure that's necessary. I wanted to illustrate that anaconda sometimes warns
17:52:29 <kparal> and sometimes it doesn't
17:52:37 <kparal> I can quickly try
17:53:03 <kparal> give me a minute
17:53:07 <tflink> that probably shouldn't be allowed but I'm not sure this is a blocker
17:53:17 <adamw> tflink: yeah, he was doing that to show what the screen after clicking 'continue' says.
17:53:18 <jreznik> but for polish - nth
17:53:37 <kparal> tflink: a single Done is enough to trigger the bug
17:54:09 <jreznik> does it crash? and could you continue in installation when you hit this? (in case you start from scratch?)
17:54:26 <tflink> worse than a crash, it fails during install after partitioning the disks
17:54:57 <tflink> kparal: so if you go into partitioning and click 'done', there is no warning about capacity and no reclaim dialog?
17:55:10 <kparal> tflink: correct
17:55:15 <kparal> it's totally broken
17:55:40 <jreznik> tflink: oh, so that's not good
17:55:40 <tflink> if that happens, it's more of a blocker
17:56:06 * jskladan is +1 blocker here
17:56:34 <adamw> right, it shouldn't consider the spoke 'done', I guess. +1
17:56:44 <jreznik> +1
17:57:50 <tflink> criterion suggestions?
17:57:57 <adamw> that's your problem :P
17:58:25 <tflink> "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
17:58:32 <tflink> is 10G sufficiently large?
17:58:33 <kparal> good one
17:58:42 <kparal> well
17:58:50 <kparal> maybe not best choice
17:58:52 <tflink> I suppose it could happen with a larger disk
17:58:54 <kparal> the disk is not empty
17:59:14 <kparal> the existing partition should be deleted or shrunk
17:59:14 <tflink> "or containing any kind of existing data"
17:59:20 <kparal> ah
17:59:24 <kparal> ok then
17:59:33 <adamw> actually, hm
17:59:48 <adamw> y'know, i'm reconsidering this a bit
17:59:50 <adamw> how bad is it really?
18:00:13 <kparal> it's so bad that it destroys your disk layout and then shows an error
18:00:20 <adamw> does it really>?
18:00:24 <tflink> if it didn't die during install after partitioning, I don't think I'd be +1 blocker
18:00:25 <kparal> yup
18:00:31 <adamw> i don't agree
18:00:33 <kparal> it died after partitioning
18:00:35 <adamw> yes
18:00:42 <adamw> but it won't destroy existing partitions or anything in that workflow
18:00:47 <adamw> it will only try and use existing empty space.
18:00:57 <tflink> did you check the layout after the install attempt?
18:00:58 <adamw> all it has done is partition the empty space and explode. how terrible is that? what have you lost?
18:01:08 <kparal> that's true
18:01:11 <adamw> you've gained a couple of useless partitions, but...
18:01:19 <kparal> autopart shouldn't destroy anything
18:01:38 <kparal> I didn't think about that
18:02:05 <Viking-Ice> does this not hit "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:02:31 <kparal> maybe we should have a criterion about size checks
18:02:31 <adamw> not really, because this isn't a 'workable layout' - that's the whole problem, it's too small to be workable
18:02:36 <tflink> I'd argue that 5G of free space isn't workable
18:02:50 <Viking-Ice> am I blind or did we not have criteria that the installer must be able to install without fatal errors?
18:02:51 <adamw> what we're hitting here isn't a case where it ought to succeed and instead fails, but a case where it ought to fail more cleanly than it does
18:02:52 <kparal> tflink: you can do it manually, yes. the autopart logic is pretty bad
18:03:24 <adamw> you could argue that this is a conditional breach of e.g. " The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:03:37 * satellit_ doesn't formatting only occur when all hubs are OK?
18:03:47 <tflink> if it doesn't bork the system, I'm not sure it's a blocker
18:03:50 <adamw> the condition being 'you have enough space for an install only after adjusting the existing partitions, and you click Done instead of Continue in the partitioning spoke so miss the chance to do that'
18:03:55 * satellit_ spokes*
18:04:07 <adamw> satellit: the problem here is that the partitioning spoke is being considered 'done' when it really isn't
18:04:07 <kparal> we should have a criterion that installer should warn you about possible problems in advance, before it touches your data
18:04:23 <adamw> it's definitely a bug, but i'm being awkard about whether it's actually bad enough to be a blocker
18:04:53 <kparal> what about " Rejecting obviously invalid operations without crashing "
18:04:59 <kparal> it's not a crash really, but...
18:05:02 <adamw> that's custom part
18:05:07 <adamw> we could adjust it, of course, but
18:05:07 <kparal> damn you
18:05:11 <adamw> =)
18:05:26 <jskladan> saying, that autopart can do obviously invalid operations? ;)
18:05:29 <tflink> I'm definitely +1 NTH on this
18:05:50 <adamw> kparal: if this actually 'touched your data' i'd be +1 (we have a final criterion for 'potential corruption' or something like that
18:05:53 <adamw> but i'm not convinced it does
18:05:54 <jreznik> well, let's go with NTH now and we can redefine later if we will know more how bad it is
18:06:01 <tflink> what about UEFI?
18:06:11 <tflink> would it format /boot/efi?
18:06:13 <adamw> kparal: was this with a post-beta build?
18:06:19 <jreznik> it does not make sense fight for criterion if we are even unsure it's a blcoker
18:06:25 <kparal> also, does it touch bootloader before copying packages?
18:06:36 <tflink> bootloader should be after packages
18:06:37 <adamw> i just tried with Beta and a disk with 2.5GB free, if i hit the spoke and just hit Done, I get 'Error checking storage configuration'
18:06:39 <kparal> adamw: 18.37, latest anaconda
18:06:42 <adamw> bootloader's one of the last steps
18:06:59 <tflink> I'm still wondering about /boot/efi since that's a partition, not a bootloader
18:07:14 <kparal> adamw: it's probably just a case with an existing partition
18:07:26 <kparal> tflink: good question
18:07:48 <kparal> +1 nth and ask developers about corner cases
18:07:50 <kparal> like uefi
18:07:55 * adamw getting smoke5 to try
18:08:02 <kparal> punt blocker vote
18:08:10 <tflink> other thoughts?
18:08:15 <satellit_> http://wiki.sugarlabs.org/go/File:Error_Msg-Disk_too_small.png   also
18:08:17 <tflink> anyone solidly -1 blocker?
18:08:19 <adamw> got smoke5, gimme a sec
18:08:32 <tflink> adamw: no, need results NOW!
18:08:34 <kparal> adamw: that won't answer us the corner cases
18:08:48 <adamw> sure, but it seems to indicate that this isn't a 100% general bug
18:08:52 * tflink really wishes we had EFI VMs
18:08:53 <adamw> yeah, i still get 'error checking storage configuration'
18:09:04 <tflink> and before someone says it, no VB doesn't count
18:09:05 <adamw> so it doesn't seem as simple as 'storage check is always skipped if you hit Done' or something like that
18:09:17 <adamw> so i'm +1 nth, punt
18:09:24 <jreznik> adamw: +1
18:10:30 <tflink> proposed #agreed 885641 - AcceptedNTH - While this is a bad way for the installer to fail, it's not clear whether or not it's actually a blocker. Accepted as NTH, blocker status will be revisited when more info is available. A tested fix would be considered past freeze.
18:10:43 <Viking-Ice> ack
18:10:43 <kparal> ack
18:10:49 <mkrizek> ack
18:10:51 <jreznik> ack
18:10:55 <tflink> #agreed 885641 - AcceptedNTH - While this is a bad way for the installer to fail, it's not clear whether or not it's actually a blocker. Accepted as NTH, blocker status will be revisited when more info is available. A tested fix would be considered past freeze.
18:11:06 <tflink> #topic (885090) Inconsistent locations of font files on UEFI systems
18:11:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885090
18:11:06 <tflink> #info Proposed Blocker, grub2, NEW
18:11:08 <buggbot> Bug 885090: unspecified, unspecified, ---, pjones, NEW , Inconsistent locations of font files on UEFI systems
18:11:29 <tflink> This is another one that I don't understand 100% but it sounds like it could be a problem in some cases
18:12:09 <tflink> there are issues if grub can't find fonts on boot
18:12:19 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=859632 is one of them
18:12:21 <buggbot> Bug 859632: unspecified, unspecified, ---, pjones, ASSIGNED , gfxterm hangs when editing boot entries with large font
18:12:35 <tflink> some of these situations can lead to systems that have a non-functional grub menu
18:13:19 <tflink> it also sounds like there is a mismatch between anaconda's bootloader installation and grub2-install
18:13:25 <tflink> they're not installing stuff to the same place
18:13:26 <kparal> I think I need a better description of how it affects the system and what it can cause and in which circumstances to decide
18:13:44 <kparal> can we ask for that in the bug report?
18:13:53 <jskladan> ^^
18:14:58 <kparal> also the hang issue is proposed as blocker in 859632
18:15:07 <kparal> this is a root cause, if I understand it correctly
18:15:16 <kparal> I think discussing just 859632 would be enough
18:15:16 <tflink> part of the root cause, anyways
18:15:24 <tflink> not the same thing, I don't think
18:16:40 <tflink> or not. I didn't get to the bugs marked as needing info this morning
18:16:48 <adamw> well if this bug was fixed, 859632 wouldn't occur, as i see it
18:17:05 <adamw> if this bug was fixed, UEFI grub2 would use unicode.pf2 as it's supposed to, which would avoid 859632 happening.
18:17:14 <adamw> this is basically 850783 redux for UEFI.
18:17:19 <tflink> that's the theory, anyways
18:18:22 <adamw> so i guess on its own merits i'm narrowly -1 on this bug
18:18:45 <tflink> combined with 859632, though?
18:18:56 <adamw> 'wrong font for grub on UEFI installs' doesn't seem blocker-worthy - the worst consequence we knew of of the wrong font choice was the 'it breaks boot parameter modification on small screens' case
18:19:01 <adamw> i don't think that applies
18:19:09 <adamw> if we think 859632 is a blocker we should make 859632 a blocker
18:19:32 <adamw> then if this is fixed it would 'workaround' 859632...
18:19:50 <adamw> hum, well. i guess you could look at it differently.
18:20:16 <adamw> i suppose...maybe what we want to do is block on *either one* of these bugs?
18:21:30 <adamw> there's various ways to express that, if it's what we want
18:21:50 <tflink> that would get rid of the issue that's potentially blocker-worthy
18:24:02 <tflink> other thoughts?
18:24:16 * kparal doesn't really know
18:24:34 <adamw> i guess 'we want one or the other to be fixed' is where i am
18:24:42 <adamw> i don't mind how that gets expressed...
18:25:05 <adamw> i'd probably suggest what i did above, make 859632 the blocker, and if this one gets fixed, make it not a blocker any more
18:25:14 <Viking-Ice> agreed
18:25:52 <tflink> so 859632 is blocker, 885090 is nth?
18:25:58 <tflink> for now, anyways
18:26:10 <adamw> that's how i'd do it. i'll make sure the tickets express what we really mean
18:26:24 <tflink> k, we'll discuss 859632 after this one
18:27:28 <tflink> proposed #agreed 885090 - RejectedBlocker AcceptedNTH - This isn't serious enough by itself to warrent blocker status for F18 final but it would be nice to have correct fonts for release. A tested fix would be considered after freeze.
18:27:37 <Viking-Ice> ack
18:28:13 <adamw> ack
18:28:53 <adamw> any more acks?
18:29:10 <kparal> ack
18:29:28 <tflink> #agreed 885090 - RejectedBlocker AcceptedNTH - This isn't serious enough by itself to warrent blocker status for F18 final but it would be nice to have correct fonts for release. A tested fix would be considered after freeze.
18:29:34 <tflink> #topic (859632) gfxterm hangs when editing boot entries with large font
18:29:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859632
18:29:39 <buggbot> Bug 859632: unspecified, unspecified, ---, pjones, ASSIGNED , gfxterm hangs when editing boot entries with large font
18:29:40 <tflink> #info Proposed Blocker, grub2, ASSIGNED
18:30:18 <tflink> criterion on this?
18:31:13 <tflink> "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode."?
18:32:02 <adamw> +1 blocker per earlier discussion
18:32:03 <kparal> we don't have any criterion for this
18:32:10 <Viking-Ice> +1 blocker as well
18:32:15 <adamw> whatever we used for https://bugzilla.redhat.com/show_bug.cgi?id=850783
18:32:16 <buggbot> Bug 850783: unspecified, unspecified, ---, pjones, CLOSED CURRENTRELEASE, Font used in F18 grub2 configuration is too large for low resolution displays, makes it effectively impossible to edit entries in VMs
18:32:26 <tflink> we didn't block for 850783
18:32:30 <adamw> oh, we didn't. poop
18:32:46 * adamw looks for criterion to bend
18:33:30 <adamw> we're kinda missing bootloader criteria, aren't we.
18:34:32 <adamw> hmm
18:34:55 <tflink> yeah, that's why I was using the firstboot criterion
18:35:06 <tflink> since it could block booting
18:35:07 <adamw> sigh. i should've read this one more cloesly
18:35:13 <adamw> i assumed it was 'all UEFI' but it isn't
18:35:22 <adamw> like 850783, it's only small screens
18:35:36 <adamw> are we still +1 blocker even if it's only for low res?
18:35:45 <adamw> uefi low res isn't a hugely likely combination except in virt
18:35:51 <tflink> I don't think that 850783 caused grub to hang
18:36:01 <adamw> no, but the effect was pretty similar really
18:36:07 <adamw> if you need to edit the parameters you need to edit the parameters.
18:36:15 <adamw> if you don't, well, you can just reboot and not try to edit them.
18:36:35 <tflink> given my recent experience installing ubuntu - unusable grub after/during install is pretty infuriating
18:36:36 <adamw> this is only a showstopper if you actually need to edit them...
18:36:49 <Viking-Ice> I'm not sure we need boot criteria we probably just needs something else then grub2 ;)
18:37:39 <adamw> to take an overview: if we block on this we're saying 'the combination of a native UEFI install at a low resolution where you need to edit the boot parameters in order to be able to proceed with boot is common enough to block release for'...
18:37:41 <tflink> true, I suppose that it's a minority of people who would need to edit grub menu before updating
18:37:59 <adamw> it's also a minority of people who install to native UEFI. and a minority of that minority who do it at a low resolution...
18:38:10 <Viking-Ice> might this not affect visually impaired  ( which we probably should have criteria to cover )
18:38:14 <adamw> if i'm counting right, this is a minority of a minority of a minority
18:38:18 <tflink> isn't grub's default for low res?
18:38:26 <adamw> grub doesn't have a 'default' exactly
18:38:29 <adamw> it tries to set a native mode
18:38:36 <adamw> in VMs it always winds up picking a low res for some reason
18:39:12 <adamw> on metal, it tries to pick the 'correct' resolution for the screen. well, i'm not sure if that's true on UEFI, now i come to think of it, wish i could remember for sure. actually in UEFI doesn't the firmware set the video mode? hm.
18:39:41 <adamw> Viking-Ice: well the font size for grub is a kind of hardcoded thing
18:39:57 <adamw> so i don't think whether you're visually impaired or not really comes into it - you don't get to pick the font size anyway
18:40:05 <Viking-Ice> yeah was just thinking about the guy in Grub2 thread on -devel
18:40:09 <adamw> in any kind of 'assisted' way, anyways.
18:40:13 <adamw> right, i got the reference
18:40:35 <adamw> so i guess even if we fix the 'default' to be a small font, this bug could potentially affect visually impaired users who change it to a bigger one, yes.
18:40:41 <Viking-Ice> we probably should have something to cover that for *DE's
18:40:49 <tflink> you can change that after install, no?
18:40:49 <Viking-Ice> at least
18:40:58 <adamw> brb, call of nature
18:41:09 <tflink> or does it get stomped on every time you get a new kernel?
18:41:10 <Viking-Ice> tflink, yup
18:42:17 <tflink> or even before rebooting post-install IIRC
18:42:20 <Viking-Ice> yup with changing it after install
18:42:35 <tflink> which might be able to workaround this issue, too
18:42:52 <tflink> not the nicest workaround and you have to know about it before you hit the bug
18:43:11 <Viking-Ice> seriously we need something better in the ecosystem then grub2
18:43:29 <tflink> perhaps but I sincerely doubt that'll happen before F18
18:44:13 <Viking-Ice> yeah sure
18:44:17 <Viking-Ice> just saying
18:44:29 * tflink isn't a huge fan of uefi in any case
18:44:48 <tflink> the current situation as a whole, anyways
18:44:58 <tflink> I realize that uefi brings some improvements
18:45:10 <tflink> it just pisses me off more often than not
18:45:18 <tflink> </rant>
18:45:28 <tflink> so what do we want to do about this bug?
18:45:38 <Viking-Ice> this can be fixed via update right?
18:45:57 <Viking-Ice> which brings us down how likely are you to hit this bugs followed buy
18:46:11 <Viking-Ice> mean by +/-
18:46:19 <tflink> depends. I've hit situations like this before but I'm not sure how common they are
18:46:33 <tflink> usually with gfx issues where I need to add nomodeset to the kernel params
18:47:44 <adamw> Viking-Ice: it can be fixed by update, sure, but in the hypothetical scenario where you're someone doing a native UEFI install to a system with a small screen and you need to edit the parameters for boot to succeed, you'd be screwed.
18:47:56 <adamw> but i guess my position is that's too small a corner case to care about, so now i'm -1
18:48:19 <Viking-Ice> yeah I'm swinging -1 as well
18:48:29 <adamw> tflink: nomodeset is not going to give you much joy on uefi, iirc.
18:49:01 <tflink> adamw: it makes the difference between usable and not post-install when nouveau chokes on my gfx card
18:49:21 <adamw> tflink: on UEFI though?
18:49:22 <tflink> I don't think I'm +1 enough to argue
18:49:24 <tflink> adamw: yep
18:49:38 <tflink> integer underflow > inconvenience
18:49:39 <adamw> huh. i thought UEFI would just choke mightily without modesetting. must be misremembering something.
18:50:00 <tflink> adamw: the most recent case was with ubuntu, who knows how it was really set up
18:50:19 <tflink> I get unclear on what's actually in grub and what distros have tacked on
18:50:43 <adamw> ubuntu's grub was still a rather heavily patched 1.99.5 last i checked.
18:51:12 <tflink> all I know is that it took me over 2 hours to install ubuntu after fighting with all the workarounds
18:51:57 <Viking-Ice> I thought the triple U's installer and experience was supposed to be the holy grail
18:52:11 <tflink> proposed #agreed 859632 - RejectedBlocker, AcceptedNTH - Even though this is an actual hang in grub, it is too much of a corner case to block release for. However, a tested fix would be considered after freeze.
18:52:21 <Viking-Ice> I have never used nor install the triple U distro and never intent to
18:52:21 <tflink> Viking-Ice: some parts are nice, others aren't
18:52:21 <Viking-Ice> ack
18:52:31 <adamw> ack for now
18:52:32 <tflink> but I'm probably not in their target audience
18:52:35 <adamw> we can always revive it later if people yell
18:52:52 <tflink> did we lose everyone else again?
18:52:57 <adamw> i think so
18:53:16 <adamw> kparal: mkrizek: jreznik: ping?
18:53:32 <tflink> jreznik said something about having to leave for a while
18:53:32 <kparal> I'm here, I haven't really followed the discussion
18:53:49 <adamw> oh yeah.
18:54:32 <kparal> but I trust your decision
18:55:49 <tflink> are we OK with only 2 acks?
18:56:38 * jreznik is back
18:56:42 <adamw> well, three with yours, and kparal's implied ack.
18:56:58 <tflink> #agreed 859632 - RejectedBlocker, AcceptedNTH - Even though this is an actual hang in grub, it is too much of a corner case to block release for. However, a tested fix would be considered after freeze.
18:57:03 * jreznik is reading backlog
18:57:15 <tflink> #topic (880271) Wrong keyboard layout in initramdisk
18:57:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=880271
18:57:16 <tflink> #info Proposed Blocker, dracut, ASSIGNED
18:57:17 <buggbot> Bug 880271: unspecified, unspecified, ---, dracut-maint, ASSIGNED , Wrong keyboard layout in initramdisk
18:58:12 <tflink> my understanding is that dracut is not handling keyboard layouts on upgrade
18:58:18 <tflink> the initial report was an upgrade with yum
18:58:31 <tflink> reproduced w/ fedup in c#5
18:59:08 <adamw> we have something about 'unlocking encrypted disks on boot' iirc
18:59:21 <adamw> so this probably infringes the upgrade criterion plus that one, in the case of non-en-us keymap
18:59:34 <adamw> so i guess +1
18:59:41 <kparal> +1
18:59:46 <tflink> +1 here as well
19:00:07 <Viking-Ice> +1
19:00:58 <tflink> proposed #agreed 880271 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for non-US keymaps: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria"
19:01:23 <kparal> ack
19:01:25 <tflink> before I forget ...
19:01:30 <tflink> #chair adamw kparal
19:01:30 <zodbot> Current chairs: adamw kparal tflink
19:02:35 <tflink> anyone else?
19:02:53 <jreznik> ack
19:03:23 <Viking-Ice> ack
19:03:30 <adamw> ack
19:03:33 <tflink> #agreed 880271 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for non-US keymaps: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria"
19:03:39 <tflink> #topic (869584) ibus menu in kde panel does not work, disappears immediately
19:03:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869584
19:03:44 <buggbot> Bug 869584: unspecified, unspecified, ---, tfujiwar, MODIFIED , ibus menu in kde panel does not work, disappears immediately
19:03:45 <tflink> #info Proposed Blocker, ibus, MODIFIED
19:04:33 <tflink> this is an issue with IMEs not working quite right with some apps when used under KDE
19:04:58 * tflink will be back in a minute, call of nature. adamw and kparal are chairs
19:05:36 * jreznik has to admit - never understood ibus at all - but still wondering why gtk3 one should be default in kde - asking Kevin right now
19:06:19 <adamw> it seems that this boils down to 'CJK input in KDE is broken'. if that's the case i'm +1. not sure if i'm oversimplifying.
19:06:25 <adamw> i can test it given a few minutes.
19:07:33 <jreznik> [20:07] <Kevin_Kofler> jreznik: Well, on the KDE spin, we don't ship any input methods at all (space reasons), but when input methods are installed, ibus-gtk3 is the default, yes. :-(
19:08:30 <adamw> i'm testing a DVD install with Japanese keyboard layout added.
19:08:41 <adamw> hahaha.
19:08:49 <adamw> and I hit the 'setting root password explodes install' bug :)
19:08:55 <adamw> restart...
19:09:07 <adamw> but I'm conditional +1 if it is indeed that.
19:10:37 <adamw> anyone else?
19:10:53 <jreznik> I'm ok with that
19:11:05 <adamw> criterion is "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use "
19:11:07 <adamw> in the case of a CJK install
19:11:09 <adamw> KDE
19:11:16 <Viking-Ice> +1
19:11:27 <tflink> ok
19:11:28 <Viking-Ice> weak one
19:11:54 <jreznik> weak one but for people who needs input methods, it could be important one...
19:12:28 <tflink> proposed #agreed 869584 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for asian language users of KDE: "ll elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
19:12:58 <adamw> ack
19:12:59 <Viking-Ice> ack
19:13:07 <jreznik> ack
19:13:11 <kparal> ack
19:13:36 <tflink> #agreed 869584 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for asian language users of KDE: "ll elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
19:13:47 <tflink> #topic (885133) no notification when unmounting external HDDs and data are still not synced
19:13:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885133
19:13:52 <buggbot> Bug 885133: unspecified, unspecified, ---, tbzatek, NEW , no notification when unmounting external HDDs and data are still not synced
19:13:52 <tflink> #info Proposed Blocker, gvfs, NEW
19:14:19 <tflink> I think I'm -1 blocker, +1 NTH on this
19:14:33 <kparal> if you remember history, this is the same one as in F17. it was fixed for flash drives, but it is still broken for external HDDs
19:14:42 <kparal> I'm +1 blocker here
19:15:33 <Viking-Ice> +1 blocker
19:15:36 <adamw> did we take it as blocker or not for f17 in the end?
19:15:39 <tflink> yeah but I think it could be fixed with an update and I don't think there were many issues with F17
19:15:49 <kparal> adamw: it was unanimously taken as a blocker by fesco
19:15:57 <kparal> tflink: not on LiveCDs
19:16:47 <adamw> so the only weakness I see here is that we only have kparal's case
19:17:01 <adamw> do we actually know that all external HDDs work the way kparal's does?
19:17:03 <kparal> several computers tested, several HDDs
19:17:08 <adamw> ah k
19:17:10 <tflink> kparal: true but it still feels a little corner-casey for blocking release
19:17:11 <adamw> in that case +1
19:17:21 <tflink> criterion?
19:17:28 <adamw> data corruption i guess
19:17:35 <kparal> do we have something about losing user data?
19:17:38 <adamw> hm
19:17:40 <jreznik> still if external hdd claims it's not removable?
19:17:41 <adamw> " All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs "
19:17:51 <adamw> are these USB or eSATA?
19:18:00 <kparal> jreznik: also applies for internal drives connected over usb converter
19:18:05 * jreznik talked about that with kparal already and is still not convinced
19:18:14 <kparal> which is very common for system rescue purposes
19:18:36 <kparal> jreznik: in that time I didn't know it involves all HDDs out there. or at least it seems
19:18:41 <kparal> 3 brands tested
19:18:42 <jreznik> so the converter should set removable bit...
19:18:55 <kparal> jreznik: feel free to suggest that to hardware vendors
19:18:59 <tflink> proposed #agreed 885133 - AcceptedBlocker - Accepted due to conditional violation of the following F18 final release criteria for external hard drives: "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs"
19:19:00 * jreznik still thinks it's more hw fault...
19:19:08 <Viking-Ice> ack
19:19:08 <kparal> I'm pretty convinced it applies to esata as well
19:19:11 <adamw> jreznik: still, if the argument here is that we follow the removable bit, why do we show an eject button at all?
19:19:27 <kparal> but I don't have esata to test
19:19:28 <adamw> anyway I'm provisional +1 / ack for now, we could re-argue this if desktop team complains
19:19:34 <jreznik> ok
19:19:49 <tflink> more ack/nak/patch?
19:20:00 <kparal> adamw: they will probably, they did last time
19:20:00 <jreznik> or there's documentation part in case we would have to fudge it on go/no-go meeting
19:21:01 <jreznik> well, I'll try to ask tbzatek tomorrow...
19:21:06 <kparal> ack
19:21:13 <tflink> #agreed 885133 - AcceptedBlocker - Accepted due to conditional violation of the following F18 final release criteria for external hard drives: "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs"
19:21:22 <adamw> ack
19:21:31 <kparal> we also had some feedback from community, it is linked there
19:21:32 <tflink> topic (885147) Editing group properties finishes with 'The group 'groupname' already exists. Please choose a different name.'
19:21:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885147
19:21:36 <kparal> very angry feedback
19:21:38 <buggbot> Bug 885147: unspecified, unspecified, ---, nphilipp, NEW , Editing group properties finishes with 'The group 'groupname' already exists. Please choose a different name.'
19:21:38 <tflink> #info Proposed Blocker, system-config-users, NEW
19:22:33 <kparal> is this really in a default gnome install?
19:22:55 <tflink> not sure, I suppose it should have gone to "needs testing" first
19:23:39 <adamw> system-config-users is in default package set i think.
19:24:00 <Viking-Ice> thought that all system-config-foo was being dropped
19:24:07 <kparal> I wouldn't block on this personally, but the criteria say otherwise
19:24:15 <adamw> Viking-Ice: it's supposed to be being dropped approx. forever
19:24:28 <adamw> 'basic functionality test' is somewhat fudgeable
19:24:47 <kparal> well, for this application...
19:24:54 <kparal> it's really basic usage
19:24:59 <adamw> yeah, it's in the main GNOME menus
19:25:16 <tflink> well, it could be fixed with an update and I can't think of too many situations where you'd be adding groups when booted in a livecd
19:25:39 <kparal> no, not needed for livecds
19:25:57 <adamw> yeah, i'm kinda in favour of fudging this one
19:26:05 <adamw> it doesn't crash, and we can get by with a straight face
19:26:46 <adamw> it looks like you can do it 'the other way around' toop
19:26:49 <kparal> I'm OK with that
19:26:58 <adamw> do properties of the user, and add them to the group that way
19:27:03 <adamw> maybe we should clarify the criterion a bit
19:27:13 <Viking-Ice> +1 nth
19:27:17 <adamw> it's pretty vague as is
19:27:20 <tflink> isn't the bug that you can't create the group?
19:27:28 <tflink> not that you can't add a user to a group
19:27:29 <adamw> no, the error message is really misleading
19:27:36 <adamw> the operation is to try and add a user to an existing group
19:27:45 <adamw> i've no idea why you get that error message, but you do. i just reproduced.
19:27:48 <tflink> ah, you're right
19:27:49 <Viking-Ice> the workaround for this is easy create add to group from cli
19:27:59 <Viking-Ice> and this is fixable via update
19:28:01 <adamw> yeah
19:28:04 <adamw> i think we're all -1 here
19:28:15 <adamw> i'll throw a note about the criterion on the retrospective
19:28:40 <jreznik> -1 too
19:28:47 <tflink> proposed #agreed 885133 - RejectedBlocker AcceptedNTH - While this is a technical violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use", it could be fixed with an update, isn't likely to affect livecds and can be worked around by editing the user instead of the group.
19:29:03 <jreznik> ack
19:29:06 <kparal> ack
19:29:16 <adamw> ack
19:29:18 <tflink> #agreed 885133 - RejectedBlocker AcceptedNTH - While this is a technical violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use", it could be fixed with an update, isn't likely to affect livecds and can be worked around by editing the user instead of the group.
19:29:28 <tflink> #topic (885279) AttributeError: 'NoneType' object has no attribute 'startswith'
19:29:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885279
19:29:34 <tflink> #info Proposed Blocker, anaconda, NEW
19:29:35 <buggbot> Bug 885279: high, unspecified, ---, anaconda-maint-list, POST , AttributeError: 'NoneType' object has no attribute 'startswith'
19:30:09 <tflink> my understanding is that anaconda crashes if you try to add a swap partition in custom partitioning
19:30:48 <Viking-Ice> yup
19:30:50 <tflink> it also sounds like a recent regression
19:30:52 <Viking-Ice> that's mine as well
19:30:58 <Viking-Ice> and if that is the case +1
19:31:01 <Viking-Ice> to blocker
19:31:02 <kparal> +1
19:31:04 <adamw> seems pretty +1
19:31:37 <tflink> proposed #agreed 885279 - AcceptedBlocker - Violates the following F18 final release criterion for adding a swap partition in custom partitioning: "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"
19:31:57 <kparal> ack
19:32:02 <adamw> ack
19:32:44 <jreznik> ack
19:32:45 <Viking-Ice> ack
19:32:52 <tflink> #agreed 885279 - AcceptedBlocker - Violates the following F18 final release criterion for adding a swap partition in custom partitioning: "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"
19:32:57 <tflink> #topic (884896) DiskException: no partition specified
19:33:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=884896
19:33:02 <buggbot> Bug 884896: high, unspecified, ---, dlehman, ON_QA , DiskException: no partition specified
19:33:02 <tflink> #info Proposed Blocker, anaconda, ON_QA
19:33:44 <tflink> bah, this changed since I last looked at it
19:34:17 <kparal> fixed in .37
19:34:38 <adamw> seems like this needs more details
19:34:57 <adamw> not really sure what the trigger is
19:35:25 <adamw> we could ask dlehman or just punt and hope it goes away, since it's on ON_QA?
19:35:41 <Viking-Ice> punt and hope ;)
19:36:07 <kparal> adamw: ok with me
19:36:14 <adamw> yay punting!
19:37:13 <tflink> proposed #agreed 884896 - We need more information on exactly what the trigger for this bug is before deciding on blocker status, will re-visit when there is more info
19:37:17 <adamw> ack
19:37:19 <adamw> with a straight face
19:37:58 <jreznik> ack
19:38:00 * tflink notes that we have ~ 20 minutes before the 3 hour mark
19:38:23 <Viking-Ice> ack
19:38:31 <Viking-Ice> tflink, how many are left?
19:38:31 <tflink> #agreed 884896 - We need more information on exactly what the trigger for this bug is before deciding on blocker status, will re-visit when there is more info
19:38:40 <tflink> 4 on my list of bugs ready for discussion
19:38:46 <tflink> #topic (882722) 'KeyError: None' while trying to install F18 beta
19:38:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882722
19:38:47 <tflink> #info Proposed Blocker, anaconda, ON_QA
19:38:49 <buggbot> Bug 882722: unspecified, unspecified, ---, dlehman, ON_QA , 'KeyError: None' while trying to install F18 beta
19:39:39 <adamw> this error is like F18's Greatest Hit
19:39:43 <tflink> do we want to punt on this one as well
19:39:58 <tflink> yeah, I don't really like libreport's new naming scheme
19:40:08 <tflink> way too many bugs with the same common python error
19:40:17 <Viking-Ice> yeah I think we can punt it as well
19:40:43 <adamw> we never quite clarified the reproducer here either, though we took the other 'reuse of encrypted LVs' bug as a blocker didn't we?
19:40:45 <tflink> it's also more clear on what the trigger is
19:40:48 <adamw> i'm +1 or punt
19:41:03 <tflink> there is a reproducer in c#29
19:41:03 <adamw> sounds like it's encryped PVs rather than LVs here? per c#29
19:41:25 <tflink> which is what autopart in f17 steered you towards
19:42:12 <adamw> so yeah, +1 or punt.
19:42:18 <kparal> ack
19:42:21 * kparal fidgets
19:42:30 <tflink> kparal: ack to what?
19:42:39 <kparal> ah, I just received 50 lines in a second
19:42:51 <kparal> lag or something
19:43:13 <kparal> tflink: ack was to 884896 and I posted it 5 minutes ago
19:43:24 <tflink> ah, ok. it just showed up
19:43:34 <tflink> other votes?
19:44:07 <Viking-Ice> ack to punt or +1 blocker?
19:44:27 <tflink> proposed #agreed 882722 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for reuse of encrypted VGs: "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"
19:45:11 <adamw> ack
19:45:14 <kparal> tflink: I think we are really free to rename the titles of the bugzilla entries to be more reasonable. abrt uses the whiteboard with a hash
19:45:19 <Viking-Ice> ack
19:46:05 <tflink> kparal: ack/nak/patch?
19:46:10 <kparal> ack per comment #29
19:46:11 <jreznik> ack
19:46:18 <tflink> #agreed 882722 - AcceptedBlocker - Conditional violation of the following F18 final release criterion for reuse of encrypted VGs: "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"
19:46:25 <tflink> #topic (884660) Anaconda fails to load on machines with multiple NICs
19:46:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=884660
19:46:25 <tflink> #info Proposed Blocker, anaconda, MODIFIED
19:46:27 <buggbot> Bug 884660: unspecified, unspecified, ---, rvykydal, MODIFIED , Anaconda fails to load on machines with multiple NICs
19:47:26 <adamw> sounds like multiple *connected* NICs
19:47:36 <adamw> it's kind of a corner case I guess, but a pretty bad result...weak +1 here
19:47:44 <Viking-Ice> same hear
19:48:01 <tflink> yeah, at least +1 NTH.
19:48:10 <tflink> ok with blocker
19:48:27 <jreznik> wow, anyone installs fedora in such setup?
19:48:29 <adamw> it's just a corner, not a corner of a corner of a corner =)
19:48:29 <kparal> +1 blocker, not workaroundable
19:48:34 <adamw> jreznik: router machine?
19:48:41 <adamw> various enterprise configs?
19:48:48 <kparal> jreznik: it's in our cubicle, come to admire it
19:48:52 <jreznik> adamw: fedora?
19:48:57 <adamw> hell, i have two NICs in *this* box. one of them isn't hooked up, but still. it came from the factory that way.
19:49:01 <kparal> an old desktop of Petr's
19:49:15 <jreznik> I was more refering to the last comment
19:49:19 * tflink has multiple machines with fedora and multiple NICs
19:49:25 <jreznik> but I'm ok with that
19:49:44 <tflink> proposed #agreed 884660 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for systems with multiple connected nics: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the of
19:49:47 * jreznik was referring to "blade and rack-mounted servers"
19:49:51 <tflink> is that too long?
19:50:01 <jreznik> it is
19:50:02 * tflink has multiple rack mounted boxes w/ fedora running on them
19:50:03 <adamw> ack, but too long
19:50:12 <tflink> where does it get cut off?
19:50:38 <jreznik> one of the of
19:50:59 <tflink> proposed #agreed 884660 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for systems with multiple connected nics: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick ..."
19:51:03 <kparal> ack
19:51:07 <adamw> ack
19:51:10 <Viking-Ice> ack
19:51:16 <tflink> #agreed 884660 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for systems with multiple connected nics: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick ..."
19:51:36 <tflink> OK, last one on my list - are we OK with trying to get this done today?
19:51:40 <adamw> yup
19:51:43 <tflink> #topic (885240) GRUB is installed despite Do not install bootloader being selected
19:51:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885240
19:51:48 <buggbot> Bug 885240: high, unspecified, ---, dlehman, ON_QA , GRUB is installed despite Do not install bootloader being selected
19:51:49 <tflink> #info Proposed Blocker, anaconda, ON_QA
19:52:10 <adamw> feels +1 for me, not sure about criterion
19:52:28 <Viking-Ice> same here
19:53:06 <tflink> another one that's changed since I read it last
19:53:58 <adamw> it seems clear that the main bug here is fixed in 18.37
19:54:06 <adamw> two other issues are discussed but they should be separated out
19:54:16 <tflink> the issue ends up being that while it's currently possible to not install grub, there is no grub.cfg generated in that case
19:54:25 <tflink> which seems not too bad to me
19:54:34 <adamw> it's annoying but deal-with-able
19:54:37 <adamw> (for pokemons)
19:54:47 <adamw> any criteria ideas?
19:54:54 * tflink prefers the term pokemoners
19:55:02 <tflink> I am _not_ a pokemon :)
19:55:05 <adamw> well i suppose strictly it's 'collectors' :)
19:55:21 <adamw> or trainers?
19:55:27 <tflink> crazy people?
19:55:29 * adamw should stop now before he is laughed at.
19:55:55 <adamw> any criteria ideas?
19:56:00 * tflink notes for the record that he is probably in the group of crazy people - triple booting fedora, ubuntu and win7 on the same box
19:56:24 <adamw> I guess we can use the one chris suggested now i read it again
19:56:26 <adamw> "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working "
19:56:41 <tflink> I think that the "don't install grub when I tell you not to" part hits that criterion
19:56:44 <adamw> though the 'or' there is a problem, we're never consistent on how we read 'either/or' criteria - do we just need one of them to work, or both?
19:56:46 <tflink> but the rest of it ... not so sure
19:56:54 <adamw> that is the part we care about because that's what the bug is about.
19:56:59 <adamw> the other stuff needs to get separated out into other bugs.
19:57:09 <tflink> ok, that's fine with me then
19:57:15 <adamw> i guess we can just go ahead and take it with that criterion, time's a tickin
19:57:37 <Viking-Ice> yeha
19:57:43 <jreznik> ok
19:57:43 <Viking-Ice> mean yeah
19:57:53 <jreznik> yeha sounds good too
19:58:34 <tflink> proposed #agreed 885240 - AcceptedBlocker - The original report violates the following F18 final release criterion : "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working". The secondary issues are not affected by this and should be separated into new b
19:58:51 <Viking-Ice> cutoff
19:58:54 <tflink> where?
19:58:56 <Viking-Ice> into new b
19:59:04 <tflink> ha, 4 chars
19:59:22 <tflink> proposed #agreed 885240 - AcceptedBlocker - The original report violates the following F18 final release criterion : "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working". The other issues are not affected by this and should be separated into new bugs.
19:59:26 <adamw> nice.
19:59:26 <Viking-Ice> ack
19:59:27 <adamw> ack
19:59:30 <kparal> ack
19:59:36 <tflink> #agreed 885240 - AcceptedBlocker - The original report violates the following F18 final release criterion : "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working". The other issues are not affected by this and should be separated into new bugs.
19:59:47 <tflink> alrighty, there is one more on my list but that's in VERIFIED
19:59:53 <tflink> so I think we're done for the day
19:59:59 <tflink> #topic Open Floor
20:00:00 <jreznik> wooohooo!
20:00:06 <adamw> yay
20:00:08 <tflink> Anything else that needs to be brought up?
20:00:35 <kparal> I just reported one new
20:00:38 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=885853
20:00:41 <buggbot> Bug 885853: unspecified, unspecified, ---, wwoods, NEW , systemd-upgrade.target is copied to the upgraded system, rendering it unbootable
20:00:42 <jreznik> tflink: for pungi, had you time to take a look on dan's proposed workaround? otherwise he promised to prepare just langpack patch
20:00:48 <tflink> can it wait for wednesday?
20:00:55 <kparal> tflink: sure
20:01:00 <tflink> jreznik: I tried it last week and it was still busted
20:01:07 <tflink> not sure if he's changed anything since then
20:01:32 <jreznik> tflink: there's workaround explained in the bug (with old pungi and new yum)
20:01:44 <tflink> ok, I'll look after the meeting
20:01:47 <jreznik> but I'm not sure I understand it completely
20:01:51 <jreznik> thanks
20:01:52 <tflink> but I suspect that releng will reject workarounds
20:02:30 <jreznik> tflink: well, let me know and I'll ask Dan for correct patch
20:02:46 <jreznik> that 14 patch patchset is really something unmanagable now...
20:02:56 <adamw> the 'workaround' didn't sound too messy.
20:03:14 <tflink> I haven't looked at it today, to be honest
20:03:24 <jreznik> it should not but not nobody is sure it's going to work
20:03:36 <tflink> I just remember discussions around fedup and workarounds in the releng process
20:03:47 <tflink> either way, it sounds like nothing else for open floor?
20:04:03 <jreznik> nothing from me, thanks for leading this meeting!
20:04:35 <tflink> np, thanks for participating
20:04:52 * tflink sets the fuse for some amount of time, either positive or negative
20:05:16 * tflink also patents the 'time-machine-fuse'
20:05:45 <tflink> #info The next blocker review meeting is scheduled for 2012-12-12 @ 17:00 UTC
20:05:51 <tflink> 12-12-12
20:05:54 <tflink> ha
20:05:56 <tflink> anyways
20:06:03 <tflink> Thanks for coming, everyone!
20:06:08 * tflink will send out minutes shortly
20:06:11 <tflink> #endmeeting