17:13:22 #startmeeting f18final-blocker-review-3 17:13:22 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:13:22 #meetingname f18final-blocker-review-3 17:13:22 The meeting name has been set to 'f18final-blocker-review-3' 17:13:22 #topic Roll Call 17:13:30 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 cool, sounds like we have enough people to get started 17:16:12 #topic Introduction 17:16:18 Why are we here? 17:16:18 #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 #info We'll be following the process outlined at: 17:16:23 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:16:29 #info The bugs up for review today are available at: 17:16:29 #link http://qa.fedoraproject.org/blockerbugs/current 17:16:57 #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 #link http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html 17:17:35 #info The criteria for release blocking bugs can be found at: 17:17:35 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 17:17:35 #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 17:17:35 #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 17:18:04 #info the current full list of blocker/nth bugs is at: 17:18:10 #info 28 Proposed Blockers 17:18:10 #info 14 Accepted Blockers 17:18:10 #info 26 Proposed NTH 17:18:10 #info 3 Accepted NTH 17:18:23 #info the list of bugs ready for discussion is at: 17:18:36 #info 16 Proposed Blockers deemed ready for discussion 17:19:04 if there are no objections, we'll get started 17:19:23 #topic (885378) AttributeError: 'NoneType' object has no attribute 'name' 17:19:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=885378 17:19:28 Bug 885378: unspecified, unspecified, ---, anaconda-maint-list, NEW , AttributeError: 'NoneType' object has no attribute 'name' 17:19:28 #info Proposed Blocker, anaconda, NEW 17:19:58 this is a bug about using existing encrypted VGs for install 17:20:18 could be a dupe of 882722 which is also a proposed blocker, waiting for more testing with anaconda-18.37 17:21:13 encrypted VGs should work per criteria 17:21:24 seems +1 blocker for me 17:22:00 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 well 17:22:15 from the forum thread... 17:22:18 "erf 17:22:20 test thread 17:22:21 what's weird on encrypted VG? 17:22:23 "Yes. I was able to reuse lvm volumes on LUKS encrypted partition on bare hardware." 17:22:32 oh, i see, n/m. 17:22:44 kparal: you lose all the advantages of LVM when you encrypt the VG 17:22:51 unless somethings changed from the last time I tried that 17:22:56 ah, we should say encrypted LV here 17:23:12 good point, I just saw that 17:23:17 why? I can extend encrypted LV just fine 17:23:26 I used encrypted LVs in the past 17:23:27 encrypted LVs are different 17:23:43 "Also, I only see it when trying to create or reuse an *encrypted* LV." 17:23:47 comment 16 17:24:03 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 tflink: that's basically encrypted PV, right? 17:24:20 you can't change LVs unless you unmount everything 17:24:32 we seem to be getting a bit off track 17:24:34 yep 17:24:45 is re-use of an encrypted LV a blocking issue? i guess it is. 17:24:48 so +1. 17:24:55 are we blocking on reuse of encrypted disks? 17:25:11 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 " 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 that includes re-use, doesn't it? 17:25:54 and encrypted too? 17:26:01 is reusing an encrypted layout a workable layout? 17:26:51 it sounds like we're mostly +1, though 17:26:59 I believe it falls into that criterion 17:26:59 it depends how you read 'create and install to', but i'm okay with saying 'yes'. 17:27:15 when i was writing it i wasn't really thinking about re-use, but it seems reasonable to cover it. 17:27:57 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 well under what criteria you'd like to accept it? but seems people are really trying to do so 17:28:29 ack 17:28:30 tflink: ack 17:28:33 ack 17:28:50 #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 jreznik: this criterion works okay 17:29:02 #topic (885124) Notifications stays after clicking on 'x' button 17:29:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=885124 17:29:02 #info Proposed Blocker, gnome-shell, NEW 17:29:04 Bug 885124: unspecified, unspecified, ---, otaylor, NEW , Notifications stays after clicking on 'x' button 17:29:39 hah 17:30:20 anyone else can test it now? is there a way to close the notification in another way? 17:30:21 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 any gnome user to take a look? :) 17:30:55 it's a nuisance, except if it causes problem on LiveCDs 17:31:04 you can use empathy from a live CD, sure. 17:31:17 if it blocked some important messages, for example... 17:31:22 or anything else 17:31:33 it doesn't block messages, it rather prevents you getting rid of them 17:31:34 * kparal is booting 17:31:45 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 i've got five in my notification panel right now, can't get rid of any one of them 17:32:06 so as a polish bug that'd affect the live image, +1 17:32:11 adamw: so after first notification appears, you'll see no other, because the first one can't be dismissed? 17:32:13 isn't there any automatic autohide? 17:32:21 kparal: no, that's not how shell notifications work. 17:32:23 yes, there is. 17:32:58 if it fades away after timeout, I'm more NTH (if I understand correctly) 17:33:28 yes, that bit works. but the notification isn't *gone*, 17:33:55 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 aha, so it hides, it's just not removed from the message tray 17:34:09 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 I'm -0 blocker here, +1 NTH 17:34:23 existing notifications show up as icons, you click on the notification, it opens up again. 17:34:32 yeah, this one is close 17:34:41 it's not functioning correctly exactly but it's not hideously broken 17:34:46 it's more polish than anything 17:34:55 I have found a workaround 17:35:00 -1 blocker, +1 NTH 17:35:02 adamw: try to click on that message, not on X 17:35:11 so -1 blocker/+1 NTH 17:35:19 kparal: that doesn't do the same thing. 17:35:30 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 adamw: ok, I don't know. I saw notification with buttons, nothing else 17:36:15 I usually click _on_ them to hide them 17:36:15 kparal: if you click on the message in an setroubleshoot notification, it will open setroubleshoot gui. 17:36:20 but hey, it gets rid of the notification too. 17:36:28 i guess i'm +/-0 , i kinda hate polish bugs, but eh. 17:36:40 so NTH? 17:36:49 adamw: you can also right click on the icon in message tray -> remove 17:36:54 2 workarounds now 17:37:17 it sounds like we're broadly -1/+1, then? 17:37:27 sure. 17:37:28 yep 17:37:28 well, more -1 than +1 blocker 17:37:30 yes 17:37:42 I'm -0.5 blocker now 17:37:50 still +1 nth 17:38:29 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 ack 17:38:46 ack 17:39:45 ack 17:40:06 ack 17:40:11 #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 #topic (866887) the default keyboard layout isn't comfortable with the selected language 17:40:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=866887 17:40:26 Bug 866887: unspecified, unspecified, ---, vpodzime, POST , the default keyboard layout isn't comfortable with the selected language 17:40:26 #info Proposed Blocker, anaconda, POST 17:40:59 my understanding of the short version of this bug is: 17:41:18 if you install w/ a non-US keyboard and select a different layout, that layout isn't the default post-install 17:41:32 it _is_ added and can be used but the US layout is still default 17:42:29 I'm not really sure this is exactly this issue 17:42:36 I could be wrong 17:44:31 should we skip this one and I'll present you TLDR version on wednesday? I can talk to Vratislav personally 17:44:41 sure, that works for me 17:45:07 #info it sounds like we are missing some info on this bug, will re-visit when more information is available 17:45:14 I think me and Vratislav already touched this issue in the past 17:45:26 kparal: ping me, I'll join you :) 17:45:44 #topic (885641) partitioning: Continue says I don't have enough space, Done says I do 17:45:47 #action kparal to ask Vratislav about 866887 and present a summary on wednesday. also ping jreznik 17:45:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=885641 17:45:49 Bug 885641: unspecified, unspecified, ---, anaconda-maint-list, NEW , partitioning: Continue says I don't have enough space, Done says I do 17:45:50 #info Proposed Blocker, anaconda, NEW 17:46:29 watch the video for this one 17:47:53 kparal: thanks. that just forced logout and I lost all of my windows :-P 17:48:06 tflink: I think you need to report a bug ;) 17:48:16 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 video does not work for me - I see one click and then it ends 17:50:06 :/ 17:50:12 it's standard ogg 17:50:24 it plays in totem fine here 17:50:28 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 is it triggered by double cancel? 17:50:41 it played fine when I downloaded it 17:50:41 Viking-Ice: I don't think so 17:50:49 is this the custom part path or guided part? /me doesn't feel like clicking on the video 17:50:55 in anycase it's an fatal error 17:50:59 +1 blocker 17:50:59 adamw: guided 17:50:59 if custom part, we can use the 'rejecting obviously invalid operations' bit from beta 17:51:02 ah. 17:51:28 adamw: seems like Done does not perform size checks 17:51:35 but Continue does 17:51:43 this looks a little bit like "doctor it hurts", though 17:51:56 tflink: why is that? Done is completely valid 17:51:56 ? 17:52:07 you canceled out of the reclaim dialog twice 17:52:23 tflink: I'm not sure that's necessary. I wanted to illustrate that anaconda sometimes warns 17:52:29 and sometimes it doesn't 17:52:37 I can quickly try 17:53:03 give me a minute 17:53:07 that probably shouldn't be allowed but I'm not sure this is a blocker 17:53:17 tflink: yeah, he was doing that to show what the screen after clicking 'continue' says. 17:53:18 but for polish - nth 17:53:37 tflink: a single Done is enough to trigger the bug 17:54:09 does it crash? and could you continue in installation when you hit this? (in case you start from scratch?) 17:54:26 worse than a crash, it fails during install after partitioning the disks 17:54:57 kparal: so if you go into partitioning and click 'done', there is no warning about capacity and no reclaim dialog? 17:55:10 tflink: correct 17:55:15 it's totally broken 17:55:40 tflink: oh, so that's not good 17:55:40 if that happens, it's more of a blocker 17:56:06 * jskladan is +1 blocker here 17:56:34 right, it shouldn't consider the spoke 'done', I guess. +1 17:56:44 +1 17:57:50 criterion suggestions? 17:57:57 that's your problem :P 17:58:25 "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 is 10G sufficiently large? 17:58:33 good one 17:58:42 well 17:58:50 maybe not best choice 17:58:52 I suppose it could happen with a larger disk 17:58:54 the disk is not empty 17:59:14 the existing partition should be deleted or shrunk 17:59:14 "or containing any kind of existing data" 17:59:20 ah 17:59:24 ok then 17:59:33 actually, hm 17:59:48 y'know, i'm reconsidering this a bit 17:59:50 how bad is it really? 18:00:13 it's so bad that it destroys your disk layout and then shows an error 18:00:20 does it really>? 18:00:24 if it didn't die during install after partitioning, I don't think I'd be +1 blocker 18:00:25 yup 18:00:31 i don't agree 18:00:33 it died after partitioning 18:00:35 yes 18:00:42 but it won't destroy existing partitions or anything in that workflow 18:00:47 it will only try and use existing empty space. 18:00:57 did you check the layout after the install attempt? 18:00:58 all it has done is partition the empty space and explode. how terrible is that? what have you lost? 18:01:08 that's true 18:01:11 you've gained a couple of useless partitions, but... 18:01:19 autopart shouldn't destroy anything 18:01:38 I didn't think about that 18:02:05 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 maybe we should have a criterion about size checks 18:02:31 not really, because this isn't a 'workable layout' - that's the whole problem, it's too small to be workable 18:02:36 I'd argue that 5G of free space isn't workable 18:02:50 am I blind or did we not have criteria that the installer must be able to install without fatal errors? 18:02:51 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 tflink: you can do it manually, yes. the autopart logic is pretty bad 18:03:24 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 if it doesn't bork the system, I'm not sure it's a blocker 18:03:50 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 satellit: the problem here is that the partitioning spoke is being considered 'done' when it really isn't 18:04:07 we should have a criterion that installer should warn you about possible problems in advance, before it touches your data 18:04:23 it's definitely a bug, but i'm being awkard about whether it's actually bad enough to be a blocker 18:04:53 what about " Rejecting obviously invalid operations without crashing " 18:04:59 it's not a crash really, but... 18:05:02 that's custom part 18:05:07 we could adjust it, of course, but 18:05:07 damn you 18:05:11 =) 18:05:26 saying, that autopart can do obviously invalid operations? ;) 18:05:29 I'm definitely +1 NTH on this 18:05:50 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 but i'm not convinced it does 18:05:54 well, let's go with NTH now and we can redefine later if we will know more how bad it is 18:06:01 what about UEFI? 18:06:11 would it format /boot/efi? 18:06:13 kparal: was this with a post-beta build? 18:06:19 it does not make sense fight for criterion if we are even unsure it's a blcoker 18:06:25 also, does it touch bootloader before copying packages? 18:06:36 bootloader should be after packages 18:06:37 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 adamw: 18.37, latest anaconda 18:06:42 bootloader's one of the last steps 18:06:59 I'm still wondering about /boot/efi since that's a partition, not a bootloader 18:07:14 adamw: it's probably just a case with an existing partition 18:07:26 tflink: good question 18:07:48 +1 nth and ask developers about corner cases 18:07:50 like uefi 18:07:55 * adamw getting smoke5 to try 18:08:02 punt blocker vote 18:08:10 other thoughts? 18:08:15 http://wiki.sugarlabs.org/go/File:Error_Msg-Disk_too_small.png also 18:08:17 anyone solidly -1 blocker? 18:08:19 got smoke5, gimme a sec 18:08:32 adamw: no, need results NOW! 18:08:34 adamw: that won't answer us the corner cases 18:08:48 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 yeah, i still get 'error checking storage configuration' 18:09:04 and before someone says it, no VB doesn't count 18:09:05 so it doesn't seem as simple as 'storage check is always skipped if you hit Done' or something like that 18:09:17 so i'm +1 nth, punt 18:09:24 adamw: +1 18:10:30 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 ack 18:10:43 ack 18:10:49 ack 18:10:51 ack 18:10:55 #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 #topic (885090) Inconsistent locations of font files on UEFI systems 18:11:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=885090 18:11:06 #info Proposed Blocker, grub2, NEW 18:11:08 Bug 885090: unspecified, unspecified, ---, pjones, NEW , Inconsistent locations of font files on UEFI systems 18:11:29 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 there are issues if grub can't find fonts on boot 18:12:19 https://bugzilla.redhat.com/show_bug.cgi?id=859632 is one of them 18:12:21 Bug 859632: unspecified, unspecified, ---, pjones, ASSIGNED , gfxterm hangs when editing boot entries with large font 18:12:35 some of these situations can lead to systems that have a non-functional grub menu 18:13:19 it also sounds like there is a mismatch between anaconda's bootloader installation and grub2-install 18:13:25 they're not installing stuff to the same place 18:13:26 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 can we ask for that in the bug report? 18:13:53 ^^ 18:14:58 also the hang issue is proposed as blocker in 859632 18:15:07 this is a root cause, if I understand it correctly 18:15:16 I think discussing just 859632 would be enough 18:15:16 part of the root cause, anyways 18:15:24 not the same thing, I don't think 18:16:40 or not. I didn't get to the bugs marked as needing info this morning 18:16:48 well if this bug was fixed, 859632 wouldn't occur, as i see it 18:17:05 if this bug was fixed, UEFI grub2 would use unicode.pf2 as it's supposed to, which would avoid 859632 happening. 18:17:14 this is basically 850783 redux for UEFI. 18:17:19 that's the theory, anyways 18:18:22 so i guess on its own merits i'm narrowly -1 on this bug 18:18:45 combined with 859632, though? 18:18:56 '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 i don't think that applies 18:19:09 if we think 859632 is a blocker we should make 859632 a blocker 18:19:32 then if this is fixed it would 'workaround' 859632... 18:19:50 hum, well. i guess you could look at it differently. 18:20:16 i suppose...maybe what we want to do is block on *either one* of these bugs? 18:21:30 there's various ways to express that, if it's what we want 18:21:50 that would get rid of the issue that's potentially blocker-worthy 18:24:02 other thoughts? 18:24:16 * kparal doesn't really know 18:24:34 i guess 'we want one or the other to be fixed' is where i am 18:24:42 i don't mind how that gets expressed... 18:25:05 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 agreed 18:25:52 so 859632 is blocker, 885090 is nth? 18:25:58 for now, anyways 18:26:10 that's how i'd do it. i'll make sure the tickets express what we really mean 18:26:24 k, we'll discuss 859632 after this one 18:27:28 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 ack 18:28:13 ack 18:28:53 any more acks? 18:29:10 ack 18:29:28 #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 #topic (859632) gfxterm hangs when editing boot entries with large font 18:29:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=859632 18:29:39 Bug 859632: unspecified, unspecified, ---, pjones, ASSIGNED , gfxterm hangs when editing boot entries with large font 18:29:40 #info Proposed Blocker, grub2, ASSIGNED 18:30:18 criterion on this? 18:31:13 "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 +1 blocker per earlier discussion 18:32:03 we don't have any criterion for this 18:32:10 +1 blocker as well 18:32:15 whatever we used for https://bugzilla.redhat.com/show_bug.cgi?id=850783 18:32:16 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 we didn't block for 850783 18:32:30 oh, we didn't. poop 18:32:46 * adamw looks for criterion to bend 18:33:30 we're kinda missing bootloader criteria, aren't we. 18:34:32 hmm 18:34:55 yeah, that's why I was using the firstboot criterion 18:35:06 since it could block booting 18:35:07 sigh. i should've read this one more cloesly 18:35:13 i assumed it was 'all UEFI' but it isn't 18:35:22 like 850783, it's only small screens 18:35:36 are we still +1 blocker even if it's only for low res? 18:35:45 uefi low res isn't a hugely likely combination except in virt 18:35:51 I don't think that 850783 caused grub to hang 18:36:01 no, but the effect was pretty similar really 18:36:07 if you need to edit the parameters you need to edit the parameters. 18:36:15 if you don't, well, you can just reboot and not try to edit them. 18:36:35 given my recent experience installing ubuntu - unusable grub after/during install is pretty infuriating 18:36:36 this is only a showstopper if you actually need to edit them... 18:36:49 I'm not sure we need boot criteria we probably just needs something else then grub2 ;) 18:37:39 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 true, I suppose that it's a minority of people who would need to edit grub menu before updating 18:37:59 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 might this not affect visually impaired ( which we probably should have criteria to cover ) 18:38:14 if i'm counting right, this is a minority of a minority of a minority 18:38:18 isn't grub's default for low res? 18:38:26 grub doesn't have a 'default' exactly 18:38:29 it tries to set a native mode 18:38:36 in VMs it always winds up picking a low res for some reason 18:39:12 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 Viking-Ice: well the font size for grub is a kind of hardcoded thing 18:39:57 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 yeah was just thinking about the guy in Grub2 thread on -devel 18:40:09 in any kind of 'assisted' way, anyways. 18:40:13 right, i got the reference 18:40:35 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 we probably should have something to cover that for *DE's 18:40:49 you can change that after install, no? 18:40:49 at least 18:40:58 brb, call of nature 18:41:09 or does it get stomped on every time you get a new kernel? 18:41:10 tflink, yup 18:42:17 or even before rebooting post-install IIRC 18:42:20 yup with changing it after install 18:42:35 which might be able to workaround this issue, too 18:42:52 not the nicest workaround and you have to know about it before you hit the bug 18:43:11 seriously we need something better in the ecosystem then grub2 18:43:29 perhaps but I sincerely doubt that'll happen before F18 18:44:13 yeah sure 18:44:17 just saying 18:44:29 * tflink isn't a huge fan of uefi in any case 18:44:48 the current situation as a whole, anyways 18:44:58 I realize that uefi brings some improvements 18:45:10 it just pisses me off more often than not 18:45:18 18:45:28 so what do we want to do about this bug? 18:45:38 this can be fixed via update right? 18:45:57 which brings us down how likely are you to hit this bugs followed buy 18:46:11 mean by +/- 18:46:19 depends. I've hit situations like this before but I'm not sure how common they are 18:46:33