17:00:45 #startmeeting F16-blocker-review 17:00:45 Meeting started Fri Sep 2 17:00:45 2011 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:48 pjones:just to be sure here is my fdisk -l :http://pastebin.com/iLfHRDwP 17:01:01 * brunowolff is here 17:01:03 #meetingname F16-beta-blocker-review-2 17:01:03 The meeting name has been set to 'f16-beta-blocker-review-2' 17:01:09 #topic roll call 17:01:12 yo 17:01:26 So would I need to specify sdb or sdb2? 17:01:31 * athmane is kinda here 17:01:31 yay, we have more people at the start than last week :) 17:02:21 * nirik is lurking, ping if I can help with anything. 17:02:51 looks like we have a long list this week 17:02:51 steve555: uh, wherever you installed the bootloader to previously. Which might be sdb, but I can't really know that. 17:03:10 oh yay, long blocker meetings, my favourite 17:03:34 Well I'll give it a try,and come back later if I fail. 17:03:43 yeah, no kidding - lots 'o fun 17:04:06 * tflink waits until 5 after to start 17:04:35 anyone interested in secretary duty? 17:04:45 i'll do it since you're running things 17:04:49 k, thanks 17:04:59 unless you'd rather run thing 17:05:03 I'm fine with either 17:05:20 nope, this is fine 17:05:41 well, lets get this party started 17:05:56 #topic Introduction 17:06:06 #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:06:22 also to have a lot of fun! 17:06:25 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:06:26 no, no, wait. that's not this meeting. 17:06:27 * rbergeron passes out hats 17:06:29 oh 17:06:33 * rbergeron retracts hats 17:06:39 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:06:40 hat denied! 17:06:51 no hats? crap, that's why I showed up 17:07:08 * mizmo passes out kazoos under the table 17:07:08 any objections to starting with proposed blockers? 17:07:21 anything that should be covered while someone is around? 17:07:24 anyone caught in possession of a hat, kazoo, or 'fun' will be reported to the appropriate authorities 17:07:46 adamw: if you ever wondered why people don't like showing up for these .... 17:07:59 ok, proposed blockers it is 17:08:03 #topic https://bugzilla.redhat.com/show_bug.cgi?id=728923 17:08:04 Bug 728923: unspecified, unspecified, ---, akozumpl, MODIFIED, Serial console is not configured 17:08:13 #info Serial console is not configured 17:08:48 it looks like this one has a fix and should already be in anaconda 17:08:48 should be fixed in tc1 17:08:59 did anyone re-test? 17:09:04 kamil said that the patch worked 17:09:08 okay 17:09:17 i guess we can ask him to update the bug, and close it once anaconda's pushed? 17:09:19 but it doesn't look like there are any tests with the actual TC1 media 17:09:44 adamw: its listed as fixed in 16.15-1, should be pushed already 17:10:01 oh, right. 17:10:42 proposed #agreed - 728923 - Appears to have been fixed, need confirmation in beta TC1. Close once confirmed. 17:10:48 ack! 17:11:02 ack/nack/patch? 17:11:36 this is simple, not waiting for more ack 17:11:42 #agreed - 728923 - Appears to have been fixed, need confirmation in beta TC1. Close once confirmed. 17:11:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=730415 17:11:49 Bug 730415: unspecified, unspecified, ---, bcl, MODIFIED, kickstart with user --name=blah results in traceback 17:11:56 #info kickstart with user --name=blah results in traceback 17:12:08 did we ever clarify where kickstart options fit in? 17:12:30 well, no-one seemed particularly keen to take this as a blocker... 17:12:38 or figure out what version of anaconda this is supposedly fixed in? 17:12:39 and so far we only have agreement for the super-basic criterion 17:12:59 if it's fixed, blocker status is kind of irrelevant 17:13:21 * adamw tries to hook a bcl 17:14:08 i haven't seen any indication that there _is_ afix 17:14:28 IIRC, he had a fix a week or two ago 17:14:55 pjones: any idea? 17:14:55 I _think_ that the fix is already in anaconda but that's from conversation 17:15:10 asside from the word "MODIFIED"? 17:15:38 yeah 17:16:23 i guess we can just re-test it 17:16:46 oh hey bcl 17:16:50 as far as blocker status goes ... I'm tempted to say -1 blocker since there don't seem to be many reporters on this 17:16:52 * bcl waves 17:16:52 I think he fixed it and just didn't really say so in the bz... 17:16:54 we were just wondering about https://bugzilla.redhat.com/show_bug.cgi?id=730415 17:16:56 Bug 730415: unspecified, unspecified, ---, bcl, MODIFIED, kickstart with user --name=blah results in traceback 17:17:01 is the fix in current anaconda 16? 17:17:07 i.e. 16.15 or 16.16? 17:17:17 (and I'd check but asking bcl is probably quicker while I'm waiting on git to do things) 17:18:02 hrm. not mentioned in any commit 17:18:58 hrmph. I don't remember. 17:18:59 I am not seeing any anaconda commits that appear to address the problem. (Based on shortlog titles.) 17:20:00 maybe we should set it back to assigned until bcl can track down the fix and establish whether it's actually in yet 17:20:28 that works for me 17:20:41 It's there. 17:20:48 ah, found it? 17:20:48 I forgot to add the bz to the title. 17:20:56 2bac5c72ce3035154a4fee1a751666e3dd87f629 17:20:57 okay, so it should be fixed in tc1? 17:20:59 yep 17:21:19 yeah, it is in 16.16 17:21:49 proposed #agreed - 730415 - RejectedBlocker - There don't seem to be many reports of this and discussions of blocker status are purely academic for pre-freeze fixes. Fix is in anaconda, needs verification 17:21:57 ack 17:22:02 ack/nack/patch? 17:22:18 closed->thepastman 17:22:37 #info fix for 730415 is in anaconda-16.16 17:22:54 I'm taking pjones' response as an ack 17:23:02 #agreed - 730415 - RejectedBlocker - There don't seem to be many reports of this and discussions of blocker status are purely academic for pre-freeze fixes. Fix is in anaconda, needs verification 17:23:13 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734861 17:23:21 Bug 734861: unspecified, unspecified, ---, anaconda-maint-list, NEW, text mode install fails ("you have not created a bootloader stage1 target device") 17:23:23 #info text mode install fails ("you have not created a bootloader stage1 target device") 17:24:01 seems like no-one else has confirmed this yet, but if it did affect all text installs, that'd be +1 blocker 17:24:11 robatino: am I understanding 734861 correctly? Are you hitting this pretty much every time on text installs? 17:24:26 tflink: yes 17:24:31 I've done some kickstarted text installs but I don't think those were auto partition 17:24:40 then I stick with +1 blocker 17:24:43 any other votes? 17:24:55 i think we can provisionally accept it, but we should verify it too 17:24:59 * adamw fires up an install 17:25:19 i've seen it with both vbox and kvm installs, so it seems reproducible and probably no one else has tried it 17:25:36 I think calling a text-mode install problem (that doesn't effect kickstarts) shouldn't be considered a blocker, honestly. 17:25:44 proposed #agreed - 734861 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 17:26:14 ack/nack/patch ? 17:26:15 pjones: that would be a change, we agreed text mode is alpha critical when setting up the criteria 17:26:29 adamw: so sad. 17:26:56 so ack for me 17:27:23 yup, reproduced 17:27:25 robatino: are those attachments really x-gzip or did bz get it wrong again? 17:27:52 any other votes on this? 17:28:04 I'm +1 17:28:14 that makes 2, would be nice to have >= 3 17:28:18 needs fixing :) 17:28:21 those are gzipped xwd dump files 17:28:40 ick 17:28:42 if you have ImageMagick installed, use "display foo.xwd.gz" 17:29:04 interesting buglet there, actually - gnome by default wants to open them with eog, but eog doesn't actually handle xwd 17:29:07 i've been using gimp 17:29:24 is that a broken mimetype association? 17:29:30 i always use ImageMagick so never noticed 17:29:40 no more votes? 17:29:42 preferrably images in attachments are visible with the browser. ie. jpg or png. 17:29:58 robatino: you get a vote, y'know :) 17:30:27 sorry, was distracted 17:30:30 +1 if that wasn't clear 17:30:38 bcl: thanks 17:30:44 bcl, yeh but bz is paranoid and doesn't let you view jpg/png in the browser, it pops up an external viewer (citing security reasons) 17:30:46 #agreed - 734861 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 17:30:55 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735016 17:30:57 Bug 735016: unspecified, unspecified, ---, anaconda-maint-list, NEW, reboot halts after preupgrade 17:31:03 #info reboot halts after preupgrade 17:31:16 mizmo: ok, true, but it happens automagically for me. instead of needing to use some other tool. 17:31:24 I think this is a pretty clear blocker 17:31:41 The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 17:32:23 nice screenshot. 17:32:31 proposed #agreed - 735016 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 17:32:31 as a note, that language should be amended to say "both" rather than "either" if we mean "both", since in this usage they have the opposite meaning. 17:32:57 pjones: good point 17:33:39 yeah...i'm not sure why i wrote it that way, but i believe we meant 'both'. 17:33:43 #action tflink or adamw - update beta release requirement to say "both" instead of "either" 17:34:40 ack/nack/patch ? 17:34:43 so yeah, as described this looks like a blocker, pretty short on info though. 17:34:44 ack 17:34:55 I think we need more info. 17:35:02 #info need more information from reporter 17:35:46 proposed #agreed - 735016 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria - The bug report is lacking some information, ask reporter for more details 17:36:23 I've got +2 so far, am I missing anyone? 17:36:31 bcl: what kind of info would help? 17:36:59 logs from preupgrade. Actually at this point it isn't an anaconda bug, it is preupgrade. 17:37:28 #info requested information: logs from preupgrade. 17:38:38 no more votes? Otherwise, I'm going to assume no dissenting opinion on blocker status 17:38:55 #agreed - 735016 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria - The bug report is lacking some information, ask reporter for more details 17:39:03 #topic https://bugzilla.redhat.com/show_bug.cgi?id=731248 17:39:04 Bug 731248: unspecified, unspecified, ---, control-center-maint, NEW, [abrt] control-center-3.1.4-1.fc16: Process /usr/bin/gnome-control-center was killed by signal 11 (SIGSEGV) 17:39:12 well, I think it's a mistake to make something blocker if we have not enough data, but... 17:39:13 #info [abrt] control-center-3.1.4-1.fc16: Process /usr/bin/gnome-control-center was killed by signal 11 (SIGSEGV) 17:39:26 pjones: we can go back 17:39:35 pjones: we can demote it if it turns out to be something unusual rather than all preupgrades 17:39:39 I assume no disagreement if it's quiet 17:39:42 we can always decide it's not later, yeah 17:39:57 this one actually looks to be fixed with 3.1.90 17:40:08 i now have a BT icon in the panel and the control center applet works fine 17:40:31 cool, fixed bugs are awesome 17:40:31 i don't recall if it was fixed in 3.1.4 though :/ 17:40:49 anyone have f16 without the 3.1.90 update, and a bluetooth adapter? 17:41:46 hum, actually, my last comment would've been with the last shell build prior to 3.1.90 17:41:55 so looks like this is valid until the 3.1.90 update is pushed 17:42:11 so, i'm +1 blocker obviously, per the criterion tim cited 17:42:15 otherwise, I'd say vote on it - if it's fixed, blocker status is just academic 17:42:35 proposed #agreed - 731248 - 17:42:41 proposed #agreed - 731248 - 17:42:47 copy paste fail 17:42:54 proposed #agreed - 731248 - 17:42:59 * tflink curses 17:43:12 proposed #agreed - 731248 - No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices 17:43:26 ack 17:43:27 proposed #agreed - 731248 - AcceptedBlocker - No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices 17:43:30 I'm full of fail on this one 17:43:31 sitll ack =) 17:43:38 * adamw pokes a hole in tflink to let the fail out 17:44:05 lol 17:44:17 * tflink hopes that it works or that he's reached his fail quota for the day 17:44:27 ok, we're at +2 again ... 17:44:40 anyone else? 17:45:39 man, you people are the reason democracy sucks! 17:45:44 +1! 17:45:51 yay! 3 votes! 17:45:58 #agreed - 731248 - AcceptedBlocker - No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices 17:46:06 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734286 17:46:11 Bug 734286: high, high, ---, notting, NEW, tboot package was not included in install DVD yet 17:46:17 #info tboot package was not included in install DVD yet 17:46:23 I'm -1 blocker on this one 17:46:24 sounds awful. 17:46:45 -1 17:47:03 nth? 17:47:09 bcl: no, the other thing 17:47:21 yeah, this is a feature thing, and we already agreed feature process and release validation process are separate. 17:47:21 not at all? ;) 17:47:31 crappy to have ;) 17:47:36 and this is a comps change anyway, so the freeze doesn't really affect it... 17:47:37 proposed #agreed - 734286 - RejectedBlocker - missing packages for optional features are not release blocking issues 17:47:41 ack/nack/patch ? 17:47:45 ack 17:47:49 hard to make it un-crappy if it isn't included. but yeah, not a blocker. 17:48:16 ack 17:48:18 ack 17:48:25 #agreed - 734286 - RejectedBlocker - missing packages for optional features are not release blocking issues 17:48:25 +1 to NOT a blocker 17:48:34 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734791 17:48:35 Bug 734791: unspecified, unspecified, ---, dennis, NEW, Checksum files for Live have wrong name 17:48:43 #info Checksum files for Live have wrong name 17:48:59 this seems like it has to be a blocker if we mean to be serious about Live in any way. 17:49:32 +1 17:49:32 yeah, I'm inclined to agree 17:49:42 +1 17:49:47 (which I view as a fairly contentious "if", but hey...) 17:50:11 given that they are available the checksums ought to be useful. 17:50:16 proposed #agreed - 734791 - AcceptedBlocker - Doesn't hit any release criteria but checksum files need to be correct before release 17:50:20 ack/nack/patch ? 17:50:24 ack 17:50:33 we probably ought to put that on the release criteria, really. 17:50:36 ack, though feels like there should be release criteria 17:50:40 well...the checksums aren't *wrong*. 17:50:42 the process of actually releasing the thing has to work ;) 17:50:44 it's just a file name. 17:50:51 proposed #agreed - 734791 - AcceptedBlocker - Doesn't hit any release criteria but checksum file names need to be correct before release 17:50:55 adamw: right, but it means automated checking will fail 17:50:59 ah, true. 17:51:12 I don't think that we need a criteria for this 17:51:23 overspecifying stuff doesn't help - they're long enough as it is :) 17:51:24 why not? 17:51:58 if we don't specify stuff, we're relying on Special Knowledge - i.e. that people know we usually publish checksums, that they should have a name in a certain format, etc etc... 17:52:08 anyway, sure, I'm +1 blocker on the basis that we propose a criterion for it 17:52:38 at what point do we stop specifying the specifics? 17:52:41 anyone else want to take an action item to propose a criterion or is it time for AdamW, Criteria Man again? 17:52:44 tflink: never! 17:53:05 * rbergeron passes adamw his cape 17:53:09 at some point, you have to rely on peoples' judgement 17:53:38 i really don't see that there's any downside to writing down what we require. i know the criteria are looking a bit wall-o-text-y these days but it would be pretty easy to reformat them a bit to read much better. it's really less than a page of text, way smaller than, say, the packaging guidelines. 17:53:39 this fails to be consistant with previous functionality (I assume) and expectations based on other similar media 17:53:43 tflink: right, but in this case we're relying on people's memory of things that need to be right, not their judgement. 17:53:49 pjones: exactly, thanks 17:54:06 anyway, I continue to maintain that that should be another meeting about criteria changes and in this one we just need to decide that this obviously blocks the release ;) 17:54:07 once we fix this, what are the odds that it'll happen again? 17:54:16 pjones: agreed, I'm done for now 17:54:30 pjones: indeed - as long as we all agree there should *be* a criterion we don't need to go further in this meeting 17:54:31 #agreed - 734791 - AcceptedBlocker - Doesn't hit any release criteria but checksum files need to be correct before release 17:54:45 tflink: exactly the same as the odds were before it happened this time, i think? =) 17:54:46 adamw: how about proposing a criteria 17:54:56 tflink: we don't have to do that in this meeting, pjones is right 17:55:01 just agree in principle that there should be one 17:55:07 gimme an action item and i'll do it =) 17:55:13 we could actually even argue about that elsewhere. 17:55:30 #action adamw propose release criteria for media checksums and checksum filenames 17:55:33 #chair adamw 17:55:33 Current chairs: adamw tflink 17:55:46 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735037 17:55:47 Bug 735037: high, unspecified, ---, notting, NEW, F16-Beta.TC1 - Yum update results in - "Check that the correct key URLs are configured for this repository" error message 17:55:54 #info F16-Beta.TC1 - Yum update results in - "Check that the correct key URLs are configured for this repository" error message 17:56:05 sounds like the yum configs are broken? 17:56:15 isn't this fallout from the btrfs signing issue? 17:56:55 if it is, I'm -1 blocker. yum is behaving correctly and was given bad input 17:57:13 it does look that way, but at the same time, this will hit a fair number of people 17:57:35 I think it already has 17:57:42 +1 blocker, the "bad input" should be fixed before release 17:57:44 -1 blocker too: our intent is to check that the update mechanism works, not that the update repos don't contain any bad packages 17:57:51 they aren't bad 17:57:53 bad packages in the repos can be fixed outside of the iso generation cycle 17:57:54 I'm not saying that it isn't a problem, just that this isn't a blocking bug issue 17:57:57 releng issue 17:58:20 fwiw, this is fixed already, according to dgilmore, and just needs mirror sync 17:58:21 jwb: I thought that they were signed with the wrong key 17:58:25 I thought using yum update to upgrade wasn't really supported. 17:58:28 -1 although yum really could help out by being more specific. 17:58:31 well, the package is signed with the right key 17:58:40 tflink, it's an fc15 package signed with an f15 key 17:58:40 brunowolff: it's not an upgrade issue, it's an f16 update issue 17:58:43 well, if it's fixed already, then it's a moot point anyway. 17:58:47 so, what happened is an f15 package was inherited into f16 17:59:00 that shouldn't have happened anyway - f15->f16 inheritance should've been turned off already 17:59:23 so dgilmore has re-signed the package, turned off inheritance, and we poked the maintainer for bumping f15 but not f16, and all is pretty much taken care of, afaik. 17:59:42 this is something that needs to be fixed in our release process, but not something that really has to do with if this is a blocker or the release criteria 17:59:55 proposed #agreed - 735037 - RejectedBlocker - This was an issue with a package that shouldn't have made it in to the F16 repos, has been taken care of 18:00:01 ack 18:00:05 ack 18:00:44 #agreed - 735037 - RejectedBlocker - This was an issue with a package that shouldn't have made it in to the F16 repos, has been taken care of 18:00:54 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734903 18:00:56 Bug 734903: high, unspecified, ---, dougsland, NEW, having dnsmasq start by default and bind to all interfaces breaks libvirt bridging 18:01:03 #info having dnsmasq start by default and bind to all interfaces breaks libvirt bridging 18:01:18 I'm not sure that I understand comment 4 18:01:33 wait, isn't the whole point of doing that *for* libvirt bridging? 18:01:38 i wouldn't worry about it too much 18:02:02 the main point is that the dnsmasq service from the dnsmasq package was disabled by default in <= f15, but is now enabled by defualt in f16 with the systemd migration, which is wrong 18:02:28 as long as the package is fixed so it doesn't turn the service on when updating from the pre-systemd-migration package, everything should be fine 18:02:42 doesn't seem like a blocker though. 18:02:52 bcl: it breaks libvirt 18:02:55 well, it stops you using the system as a virt host. though obviously it's easy to workaround. 18:03:11 * tflink likes the way adamw put it better 18:03:13 i could see rejecting it on the basis of ease to workaround. 18:03:15 but if you do an upgrade then it works, right? 18:03:39 bcl: it breaks when you upgrade from the pre-systemd package to the post-systemd package 18:03:45 bcl: doubt it - you'll migrate from the sysv initscript to the systemd rule 18:03:48 i didn't actually check what happens on a clean install, it may work in that case 18:04:02 nth, then? 18:04:16 oh, I see. hell, there's lots of that going around :/ 18:04:37 yeah, nth 18:04:42 from just eyeballing the spec it looks like it would work on a fresh install 18:04:43 +1 NTH 18:04:53 so yeah, given it only affects upgrades and it's super easy to workaround, i'm fine with nth 18:05:42 proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate " 18:05:56 proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situation 18:05:59 where the virtual host is running the same release (using Fedora's current 18:06:10 preferred virtualization technology)" - the workaround is easy 18:06:19 I guess I wasn't out of fail yet 18:06:46 proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situationwhere the virtual host is running the same release (using Fedora's currentpreferred virtualization technology)" - the workaround is easy 18:07:00 ack/nack/patch? 18:07:20 patch: proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situationwhere the virtual host is running the same release (using Fedora's currentpreferred virtualization technology)" it is very easy to work around and probably only affects updates 18:07:52 proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situationwhere the virtual host is running the same release (using Fedora's currentpreferred virtualization technology)" - it is very easy to work around and probably only affects upgrades 18:08:01 I assume you meant upgrades 18:08:07 yup 18:08:08 ack 18:08:16 (you are missing a space between current and preferred) 18:08:29 proposed #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situationwhere the virtual host is running the same release (using Fedora's current preferred virtualization technology)" - it is very easy to work around and probably only affects upgrades 18:08:33 ack 18:08:39 it read faster that way, but ok :-D 18:08:58 #agreed - 734903 - RejectedBlocker, AcceptedNTH - While it does violate "The release must boot successfully as a virtual guest in a situationwhere the virtual host is running the same release (using Fedora's current preferred virtualization technology)" - it is very easy to work around and probably only affects upgrades 18:09:08 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735259 18:09:09 Bug 735259: high, unspecified, ---, pjones, MODIFIED, after updating grub2, booting drops me to grub rescue prompt 18:09:16 #info after updating grub2, booting drops me to grub rescue prompt 18:09:30 only effects upgrades, which so far means only people who have installed rawhide/tc1/etc 18:10:00 fixed in -4 , but that actually means it's fixed win upgrading *from* -4, because it's a %preun that's doing stupid things. 18:10:09 obviously I'm +1 to it 18:10:24 +1 18:10:43 would it affect upgrades from f15? 18:10:56 +! 18:10:56 so this only hits upgrade or update from -4? 18:11:01 only if you've got grub2 installed, which isn't default (or even recommended) 18:11:05 okay 18:11:10 tflink: it hits any package upgrade from a package *earlier* than -4 18:11:45 I'm pretty much +0 on this for NTH and blocker 18:11:53 so let me think through this - if we somehow didn't take this into Beta, then your first upgrade post-beta install would cause you to hit the bug? 18:12:01 adamw: right 18:12:03 it's fixed and only hit people with a non-standard config or upgrading from rawhide 18:12:07 okay, so in that case, +1 blocker 18:12:12 oh, nvm then 18:12:16 +1 blocker 18:12:51 that's +3 18:13:01 so we should take -4 into beta and also commonbugs this for people who are upgrading alpha 18:13:08 that's actually +5 18:13:10 looking for criteria 18:13:13 * adamw no count good 18:13:19 upgrade or updates 18:13:26 heck, it doesn't matter all that much 18:13:37 yeah, just pick one. 18:13:45 proposed #agreed - 735259 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 18:13:59 oh, no, not that one. it clearly doesn't hit that. 18:14:18 adamw: well, from beta to after-beta it would. 18:14:33 that criterion is for upgrades from previous stable, though. 18:14:38 pjones: it doesn't count as upgrade and it isn't done by ananconda usually 18:14:38 proposed #agreed - 735259 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops 18:14:47 yeah 18:14:50 yeah, we can crowbar it into that. 18:15:05 i'll do some logic pretzels in the bug comment. 18:15:11 ack 18:15:19 like I said, nothing explicitly violated :) 18:15:37 #agreed - 735259 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops 18:15:49 #topic https://bugzilla.redhat.com/show_bug.cgi?id=731297 18:15:50 Bug 731297: unspecified, unspecified, ---, martin.sourada, NEW, gxine-0.5.905-6 can't re-play music after stop playing 18:15:57 #info gxine-0.5.905-6 can't re-play music after stop playing 18:16:37 I think this pretty clearly violates "In most cases, the installed system must be able to play back sound with gstreamer-based applications" 18:16:52 um 18:16:54 and blocks the beta desktop cases 18:16:59 tflink: it does? 18:17:02 gxine isn't gstreamer based 18:17:05 the clue is in the name =) 18:17:22 oh, my bad 18:17:27 also, the intent of that criterion is '*some* gstreamer app must be able to play sound', not 'all apps in the repo that can possibly play sound must be able to' 18:17:30 -1 seriously no 18:17:33 * tflink was going through these late last night 18:17:35 -1 18:17:51 i suspect this is an LXDE/XFCE 'blocker' mostly as gxine might be the default player for one of those 18:18:16 (somebody else should say "-1" randomly so we can move on ;) 18:18:21 -1 18:18:32 that's -3 18:18:36 nth, then since it came up in a non-default DE? 18:18:42 yeah - masami reported this for LXDE 18:18:44 sure, wahtever. 18:18:47 so yeah, it's an NTH under principles 18:18:48 (it's on lxde spin only) 18:18:55 -1 blocker, +1 nth 18:19:15 +1 nth 18:19:28 * adamw should reword that criterion as it's too tech-specific, should just say 'desktop default audio player' or something 18:19:31 anyway, just a note to self 18:19:51 proposed #agreed - 731297 - RejectedBlocker AcceptedNTH - gxine is only on LXDE and is nth since that's not the default DE 18:19:55 ack 18:19:58 ack 18:20:00 #agreed - 731297 - RejectedBlocker AcceptedNTH - gxine is only on LXDE and is nth since that's not the default DE 18:20:09 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735199 18:20:10 Bug 735199: unspecified, unspecified, ---, harald, MODIFIED, "mount -t squashfs" fails 18:20:18 #info "mount -t squashfs" fails 18:20:50 haraldh and i debugged that this morning. he submitted a fix for a race in how dracut was looking for the squashfs image 18:21:00 it fixes the issue he and i were able to recreate 18:21:07 cool. 18:21:10 which wasn't exactly the original reported issue 18:21:14 +1 blocker, the installer must boot. 18:21:29 however, they might be very well related issues and the fix will probably make both go away 18:21:47 yeah, I'm +1. there's a case for -1 as there are various workarounds - keep rebooting, mess with maxcpus for VMs - but the impact is so nasty it might cause people to stop trying, and it's a pretty bad impression. 18:22:04 +1 of course. 18:22:35 proposed #agreed - 735199 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 18:22:36 jwb: i guess we should spin a new boot.iso with the fix for people to test 18:22:52 was the fix in dracut? 18:22:56 tflink: looks like it 18:22:58 yes 18:23:02 do you want to take an action item to provide a test boot.iso? 18:23:06 since i still can't build one that works, le sigh 18:23:16 me? 18:23:19 #action tflink build boot.iso with new dracut for testing 18:23:20 tflink 18:23:23 he's the boot.iso king 18:23:29 oh good. because i've long forgotten how to do that 18:23:32 heh =) 18:23:34 when my internet doesn't suck, anyways 18:23:45 but I've figured out how to do it on EC2 now, so I'll be good either way 18:24:02 coolios. 18:24:05 ack 18:24:31 #agreed - 735199 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 18:24:41 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734845 18:24:42 Bug 734845: unspecified, unspecified, ---, vpvainio, NEW, repoclosure failure in 16-Beta.TC1 DVDs 18:24:50 #info repoclosure failure in 16-Beta.TC1 DVDs 18:25:20 looks fairly straightforward...though ville's note is interesting. 18:25:23 I'm +1 blocker on this 18:25:34 if it has been fixed, it'll be a closed blocker :) 18:26:02 proposed #agreed - 734845 - AcceptedBlocker - (alpha criterion) There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install 18:26:11 btw, if it hasn't been mentioned before, the meeting might go quicker if people just vote for blocker and nth at the same time 18:26:17 it seems like the wrong mozvoikko got onto the dvd somehow 18:26:24 e.g. blocker +1, nth -1 18:26:35 jwb: sometimes we do that, it kinda depends on how the discussion's going exactly 18:26:48 jwb: or if we just assumed NTH for bugs when blocker is -1'd unless somebody actually says we shouldn't fix some bug. 18:26:51 note that it's 1.9.0-6.fc15 on the DVD 18:27:07 but 1.9.0-6.fc16 and 1.9.0-6.fc15 were pushed on the same day as part of updates for f16 and f15 respectively 18:27:18 so somehow the tc1 dvd got most of the f16 update, but mozvoikko from the f15 update... 18:27:29 or maybe it has both, or something 18:27:33 #agreed - 734845 - AcceptedBlocker - (alpha criterion) There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install 18:27:38 pjones: there is a difference between "we should fix this bug" and "we should take a fix for this bug during the freeze" 18:27:43 pjones: well, it's not about whether the bug should be fixed, but whether the fix should go through freeze 18:27:59 jlk: yes, but we seem to say NTH for all of them ;) 18:27:59 anyway, ack, we can debug the exact cause in the bug report 18:28:02 and whether or not we should hold up release for them 18:28:09 #topic https://bugzilla.redhat.com/show_bug.cgi?id=728193 18:28:11 Bug 728193: medium, unspecified, ---, richard, VERIFIED, preupgrade cannot retrieve repomd.xml 18:28:17 pjones: I can start proposing some wild bugs for blockers if that would help. :) 18:28:17 #info preupgrade cannot retrieve repomd.xml 18:28:17 pjones: we do reject some - we rejected tboot, for e.g. 18:28:51 +1 blocker 18:29:01 this one is +1,+1 18:29:02 sounds like we need verification of a fix, but +1 blocker 18:29:33 proposed #agreed - 728193 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 18:30:35 #agreed - 728193 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria 18:30:45 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735013 18:30:47 Bug 735013: unspecified, unspecified, ---, lpoetter, NEW, Having unit B bound or required to unit A and restarting unit A while it's active results hang 18:30:58 #info Having unit B bound or required to unit A and restarting unit A while it's active results hang 18:31:02 least useful description ever. 18:31:30 yup. 18:31:40 yeah, I'm still not clear on how bad the impact would be for this but it sounds like anything using a chained systemd unit 18:31:46 i kinda trust viking to know what he's doing when it comes to systemd, but this is a bit hard to unpick. 18:32:05 Viking-Ice: you around? 18:32:55 guess he's shooting things 18:33:05 if its as common as it sounds, why haven't we seen more reports? 18:33:08 I love how the description assumes that we got something useful from the title. 18:33:44 https://bugs.freedesktop.org/show_bug.cgi?id=39824 is a whole lot more readable 18:33:45 Bug 39824: normal, medium, ---, lennart, NEW, systemctl try-restart hangs indefinitely on required service 18:33:47 tflink: yeah, i'm reluctant to take this without a more concrete impact assessment. 18:34:00 I'm not seeing how it's a blocker, though 18:34:11 hey, i like totoplouf. i'm gonna use that. 18:34:33 seems like a 0-day systemd update would fix it. 18:34:40 proposed #agreed - 735013 - The impact of this bug is unclear and more information is needed before making a decision on blocker status 18:34:57 pjones: i think it hinges on packages using try-restart in %post 18:35:12 pjones: so it could affect f15 -> f16 upgrades if there's an affected package in f15 and we don't fix f16's systemd, i guess 18:35:16 yeah, true 18:35:25 but i'd like to know if that's actually the case... 18:35:29 the freedesktop bug says that it could happen during restart in %post 18:35:33 not just try-restart 18:35:37 adamw, wth is totoplouf 18:35:39 if it is important, it should probably also be raised on the systemd list - it doesn't seem like the bug has attracted lennart's attention... 18:35:41 and it hangs forever 18:35:49 try-restart is the 'proper' way to do a service restart in systemd, and what's recommended for use in rpm scriptlets 18:36:03 jwb: kinda a french 'foobar' by the looks of it 18:36:40 so, seems like we basically agree, let's get a bit more concrete info on actual scenarios this may affect before judging it 18:36:50 #agreed - 735013 - The impact of this bug is unclear and more information is needed before making a decision on blocker status 18:36:55 of course one reason we might not have got any reports is that it seems like upgrade from f15 to f16 is broken in other ways. 18:37:10 but people have been yum upgrading, and apparently not hitting this. 18:37:10 I think that's it for the proposed blockers 18:37:41 There is still one about ogg files. 18:38:02 bug 731240 18:38:03 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=731240 medium, unspecified, ---, bnocera, NEW, Cannot stream pure audio ogg files in Alpha (RC5) 18:38:40 i think i didn't want to propose this as a blocker, i think i marked it as 'warn' rather than fail 18:38:49 (not your fault tflink, just noting) 18:39:02 this was another one that I was doing while half-asleep last night 18:39:17 yeah, i put it as 'warn'. i think it's not serious enough to consider as blocker, just a bug i noticed while doing the audio test. 18:39:24 so, -1 -1 for me 18:39:44 same here, it's a little obscure for blocker/NTH 18:39:58 -1 blocker 18:40:26 proposed #agreed - 731240 - RejectedBlocker - doesn't hit any of the release criteria 18:40:29 ack 18:40:48 proposed #agreed - tflink shouldn't propose blockers when half-asleep 18:41:05 #agreed - 731240 - RejectedBlocker - doesn't hit any of the release criteria 18:41:16 heh 18:41:23 bug 730985, tflink marked it, and seems to hit a criteria 18:41:25 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=730985 unspecified, unspecified, ---, rstrode, NEW, Customizing panel objects / layout with 'Alt + Right Click' not working 18:41:42 :-/, did I just miss some from the list? 18:42:12 #topic https://bugzilla.redhat.com/show_bug.cgi?id=730985 18:42:13 Bug 730985: unspecified, unspecified, ---, rstrode, NEW, Customizing panel objects / layout with 'Alt + Right Click' not working 18:42:21 that's proposed for Final, not beta. 18:42:31 #undo 18:42:32 Removing item from minutes: 18:42:47 and that looks like panel_advanced not panel_basic, so yeah, final issue rather than beta. 18:43:25 OK, any more that I missed? 18:43:51 i don't see any 18:43:56 on to the proposed NTH, then 18:44:04 #topic https://bugzilla.redhat.com/show_bug.cgi?id=498207 18:44:05 Bug 498207: low, high, ---, rvykydal, ASSIGNED, DVD install defaults to ONBOOT=no leaving networking down after reboot 18:44:13 #info DVD install defaults to ONBOOT=no leaving networking down after reboot 18:44:13 i thought we did this last week? 18:44:26 wait, something's not right here 18:44:36 #undo 18:44:36 Removing item from minutes: 18:44:40 yeah, the bug looks all in shape 18:44:42 * tflink is definitely not out of fail yet 18:44:45 so the list must be off 18:45:06 I was using the accepted list, not the proposed list 18:45:09 oh. you're on the approved list, not the proposed. 18:45:12 details, details, details ... 18:45:20 man, am i going to have to poke another fail hole?! 18:45:23 #topic https://bugzilla.redhat.com/show_bug.cgi?id=735027 18:45:24 Bug 735027: unspecified, unspecified, ---, anaconda-maint-list, NEW, Failed to install repository NFSISO default 18:45:55 #info Failed to install repository NFSISO default 18:46:07 seems like this is a dead bug 18:46:37 was caused by pilot error, there is still a bug when the pilot error is fixed, but it's an already-tracked-as-blocker bug 18:47:17 is this the same thing? 18:47:30 I thought that askmethod nfs was looking for a yum repo, not an iso 18:47:35 well, what's reported in this bug initially isn't the same, but the crash appears to have been caused by using the wrong ISO 18:47:37 or is that what the pilot error was? 18:47:52 he says it works, so NOTABUG 18:47:53 it seems when he used the right ISO, he hit the same bug you get with a regular nfs install 18:48:24 request that he close or dupe it? 18:48:24 I' 18:48:29 so this specific report is NOTABUG, and we're already tracking the later issue 18:48:31 m not quite sure what the resolution is 18:48:53 i'd say NOTABUG and follow up in 727522. 18:49:13 proposeed #agreed - 735027 - CLOSED NOTABUG - the original test case was not valid, later testing reproduced another, already tracked issue 18:49:55 I asked in -qa , and I assume it is OK, but I would like to test the nouveau driver this weekend rather then on Tuesday https://fedoraproject.org/wiki/Test_Day:2011-08-30_Nouveau, is there any reason to wait until the 6th ? 18:50:18 bodhi_zazen: well, we might build special images for the day, but any testing is better than none 18:50:26 it may be best to wait till next weekend, though. 18:50:28 tflink: ack 18:50:28 #agreed - 735027 - CLOSED NOTABUG - the original test case was not valid, later testing reproduced another, already tracked issue (727522) 18:50:39 #topic https://bugzilla.redhat.com/show_bug.cgi?id=678456 18:50:40 Bug 678456: unspecified, unspecified, ---, lkundrak, MODIFIED, GRUB 2 requires os-prober to detect other installed operating systems 18:50:48 #info GRUB 2 requires os-prober to detect other installed operating systems 18:50:50 the weekend it tomorrow, dl todays nightly build 18:51:17 Suppose I can test and re-test any failures if needed 18:51:22 is this what was causing problems with installing alongside windows? 18:51:46 it certainly does that. 18:51:55 +1 NTH for beta 18:51:56 well, this and the 'which' one. 18:52:06 +1 nth 18:52:12 yup, +1. 18:52:16 probably tflink , I think os-prober should be a grub 2 dependency 18:52:42 proposed #agreed - 678456 - AcceptedNTH - This is a final blocker but the fix is pretty simple and would be nice to have for beta 18:52:46 ack/nach/patch? 18:52:51 ack 18:52:54 ack 18:53:02 #agreed - 678456 - AcceptedNTH - This is a final blocker but the fix is pretty simple and would be nice to have for beta 18:53:15 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734959 18:53:16 Bug 734959: unspecified, unspecified, ---, pjones, MODIFIED, grub2 needs to require 'which' 18:53:25 #info grub2 needs to require 'which' 18:53:26 this is very similar to the previous one, same type of issue, same impact 18:53:34 -4 does 18:53:37 +1 nth 18:53:57 yeah, sounds similar 18:54:19 #agreed - 734959 - AcceptedNTH - This is a final blocker but the fix is pretty simple and would be nice to have for beta 18:54:23 #undo 18:54:23 Removing item from minutes: 18:54:28 proposed #agreed - 734959 - AcceptedNTH - This is a final blocker but the fix is pretty simple and would be nice to have for beta 18:54:44 tflink: can you bump mizmo's issues up the list? she has to leave soon 18:54:57 hehe i think they are next anyway if you're going down the page 18:54:59 its next 18:55:14 #agreed - 734959 - AcceptedNTH - This is a final blocker but the fix is pretty simple and would be nice to have for beta 18:55:24 i have three bugs blocking one tracker, so they could be discussed in one go i think 18:55:24 #topic https://bugzilla.redhat.com/show_bug.cgi?id=669120 18:55:25 Bug 669120: medium, low, ---, bcl, MODIFIED, Track down and modify PRODUCT string for cleaner syslinux display 18:55:34 #info Track down and modify PRODUCT string for cleaner syslinux display 18:55:46 +1 blocker. 18:55:55 right now it says something along the lines of 'Welcome to Fedora487r938uogftu4wggkjg1x86-64!' 18:56:08 elad661: it's proposed nth, not blocker 18:56:20 but yeah, +1, it seems an appropriate time to fix this 18:56:21 mizmo: at least it has x86-64 in it ! 18:56:27 we promote live install as the default method on the website so its pretty visible 18:56:42 mclasen, a small comfort :) 18:56:56 +1 NTH 18:57:07 as a note, the current string is actually quite often so long it gets truncated, in my experience anyway. 18:57:09 +1 18:57:28 it's somewhat difficult to find an informative string that fits in the ISO header requirements. 18:57:28 yeh the alpha's is cut off by two letters 18:57:36 proposed #agreed - 669120 - AcceptedNTH - Not catastrophic but it looks bad and now would be a good time to fix it 18:57:37 adamw: with the new syslinux.cfg long strings make the countdown *really* ugly. 18:57:45 ack 18:57:52 ackack 18:57:56 jlk, what we're proposing is to cut the 'Welcome' and the '!' and just have Product Version (Arch) 18:58:00 #agreed - 669120 - AcceptedNTH - Not catastrophic but it looks bad and now would be a good time to fix it 18:58:05 mizmo: for extra credit, make sure your proposed 'nice' names don't get truncated! 18:58:21 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734169 18:58:22 Bug 734169: unspecified, unspecified, ---, pjones, NEW, Updated syslinux theme for Fedora 16 18:58:28 yep :) oh well the new syslinux theme turns down the margins of the screen so we could fit more characters 18:58:29 mizmo: sorry, I was thinking about the name of the spin getting truncated into the iso label, which shows up when you insert the disk and it gets mounted on your desktop or whatever. 18:58:30 #info Updated syslinux theme for Fedora 16 18:58:41 jlk, ohhh okay 18:58:51 this probably shouldn't be assigned to syslinux 18:59:01 pjones, thats just the tracking bug 18:59:08 jlk: right, those used to be the same thing. now you can set them to any random string you want. 18:59:43 hrm, shall we come back to this one after hitting it's dependencies or just take them all at once? 18:59:48 so we should evaluate the 'dependent' bugs rather than the tracker? 18:59:49 this bug has two blockers, one for the live syslinux which is against livecd-tools, and one for the DVD but i think thats against syslinux - they are the next two in the wiki i think 18:59:54 we should do them all at once i think 19:00:10 we usually leave trackers alone and deal with the bugs they track 19:00:12 the dvd one should be lorax I think. 19:00:15 adamw: do the dependencies first 19:00:20 mizmo: dvd is lorax 19:00:25 propose #agreed this bug is a tracker, evaluate the dependent bugs 19:00:26 pjones, oh thats right 19:00:38 ack 19:00:54 ack 19:01:19 proposed #agreed - 734169 - RejectedNTH - this is a tracker bug, will evaluate dependencies on their own 19:01:34 ackackackack 19:01:38 pewpewpew 19:01:40 #agreed - 734169 - RejectedNTH - this is a tracker bug, will evaluate dependencies on their own 19:01:47 aflacack 19:01:48 uh, it's not rejectednth 19:01:52 * adamw should learn to read 19:02:04 no? 19:02:07 what we usually do is just let the tracker stand, and if we decide client bugs aren't nth, take 'em off the tracker 19:02:19 oh, OK 19:02:23 but let's just go evaluate the client bugs, we can fiddle with the tracker later 19:02:23 #undo 19:02:23 Removing item from minutes: 19:02:32 #agreed - 734169 - this is a tracker bug, will evaluate dependencies on their own 19:02:43 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734173 19:02:44 Bug 734173: unspecified, unspecified, ---, bcl, MODIFIED, New syslinux theme for F16 Live media 19:02:52 #info New syslinux theme for F16 Live media 19:03:24 it uses a cleaner look & feel and is going to match the bg of the plymouth splash so it'll be a bit more seamless 19:03:26 so...this does feel like a _slightly_ big change to take now. i'd kinda have been more comfortable having it in at alpha. 19:03:40 adamw, we proposed it back in f14 actually 19:03:45 It wasn't too terrible. 19:03:51 i guess on balance i'm +1, just covering my ass. ;) 19:04:06 mizmo: 'now' as in 'at beta stage rather than earlier' 19:04:06 Mostly text changes. the hard part was moving check and basic video to a sub-menu. 19:04:12 it wasnt approved as a blcoker so it didnt make it to f15, but the feedback i got on my blog post with screenshots and the description was overwhelming positive 19:04:35 sure, it's a great change and we should take it, just makes me worry a bit that we don't have testing all the way through the cycle. but it'll probably be fine. 19:05:01 yeah, it would have been nice to get this before alpha but +1 NTH 19:05:11 I don't think testing through the whole cycle is important for something like this. 19:05:11 yeh im sorry for that :( i am willing to help test though 19:05:15 mizmo: it's not that i worry people might not like the re-design, just that the live boot menu stuff is very voodoo-ish and poking it could somehow cause bugs. 19:05:24 so yeah, small +1. 19:05:29 lol 19:05:33 Hi all,I'm back.I booted into my Fedora 16 Alpha DVD into rescue mode then I went into chroot /mnt/sysimage. I ran "grub2-install /dev/sda" and rebooted. It went straight into fedora the first time,but when I rebooted again,I got this error message from grub2: "error: ELF header smaller than expected" how can Isolve this? 19:05:59 new one to me. 19:05:59 steve555: can you ask in #fedora-qa? we're doing a meeting here right now 19:06:09 is this ready to test? 19:06:09 +0.5? =) 19:06:29 if so, how about we do this as part of the boot.iso that I'm already spinning up for dracut to see if there are any issues? 19:06:42 Ok then,adamw, I have asked there already,I'll wait patiently for a response. 19:06:48 instead of waiting for TC2 or RC1 19:06:49 bcl checked it in yesterday right? 19:07:06 yep. livecd-tools-16.5-1 19:07:26 we can spin up live images to test easily too. 19:07:49 i think we have enough positive votes to take this anyway...if bcl is +1 19:08:01 that's why I'm not terribly concerned, we have a much tighter feedback loop with live. 19:08:02 proposed #agreed - 734173 - AcceptedNTH - This is a bit big of a change for this late but it would be nice to see this happen. Will create test boot.iso and/or live images to test with before TC2 or RC1 19:08:07 +1 19:08:35 if we hit big issues, we can always back it out (not that I'm expecting any) 19:08:38 true. 19:09:03 #agreed - 734173 - AcceptedNTH - This is a bit big of a change for this late but it would be nice to see this happen. Will create test boot.iso and/or live images to test with before TC2 or RC1 19:09:16 #topic https://bugzilla.redhat.com/show_bug.cgi?id=734170 19:09:17 Bug 734170: unspecified, unspecified, ---, mgracik, ASSIGNED, New syslinux theme for F16 DVD 19:09:25 #info New syslinux theme for F16 DVD 19:09:34 so this is pretty much the same thing redux? 19:09:44 this one is less risky i think just because it's a flat cfg file rather than having to be generated as it is in livecd-tools 19:09:44 yeah, just for the dvd instead of live image 19:09:50 the implementation is simpler 19:09:53 okay 19:09:56 i guess same vote then 19:09:58 yep, just for the DVD. It's actually easier since it is a config and not code. 19:10:15 +1 19:10:24 proposed #agreed - 734170 - AcceptedNTH - This is a bit big of a change for this late but it would be nice to see this happen 19:10:32 wait, too much copy paste this time 19:10:34 (can we do the reboot one next? :) ? :) ?) 19:11:07 that looks okay to me? 19:11:07 proposed #agreed - 734170 - AcceptedNTH - This is a small change and should happen with the livecd changes in 734173 19:11:08 ack 19:11:14 still ack! 19:11:18 #agreed - 734170 - AcceptedNTH - This is a small change and should happen with the livecd changes in 734173 19:11:55 I think that's it for the syslinux NTHs 19:11:59 did I miss any? 19:12:03 i think 3 is right 19:12:08 mizmo has one more proposed though 19:12:15 oh? 19:12:28 which one? 19:12:37 oh, seems like it wasn't correctly added to the list 19:12:44 but i think mizmo wanted to add it 19:12:49 https://bugzilla.redhat.com/show_bug.cgi?id=705189 , right? 19:12:50 Bug 705189: medium, unspecified, ---, bcl, ASSIGNED, Live install needs a 'reboot' button 19:12:52 yep 19:13:00 #topic https://bugzilla.redhat.com/show_bug.cgi?id=705189 19:13:02 Bug 705189: medium, unspecified, ---, bcl, ASSIGNED, Live install needs a 'reboot' button 19:13:11 #info Live install needs a 'reboot' button 19:13:20 this is more or less to handle a change in gnome3 19:13:42 so, in gnome 2, you could easily reboot from the gnome panel, and it was fine for anaconda to print a message at the end which said 'reboot now!' but didn't actually have a reboot button 19:13:54 yeh, anaconda tells you 'you may now reboot your system' but now that is a lie :) 19:14:00 yeah, I don't think live or anaconda should be doing this. 19:14:03 in gnome3, the reboot option is hidden behind the alt key trick, so if you don't know about that, you're left with a message that says 'reboot now!' but no very obvious way to reboot 19:14:43 wonderful non-discoverable ui. 19:14:45 so the proposal to add a "reboot" button to the anaconda window? 19:14:48 I also don't think it should be automatic -- I sometimes do installs then want to review logs, try again, etc. 19:15:07 i think this is one where we can evaluate it but leave it up to anaconda team whether they actually want to 'fix' it or not 19:15:20 so we can say it's a change it'd make sense to take through freeze if it were to happen 19:15:42 * mizmo gets on knees and begs! 19:15:47 or the desktop team, I guess - I'm not sure how much sense a "suspend" button makes on a livecd 19:15:47 bcl: the proposal isn't for it to be automatic, exactly - the button would be there but you'd have to actually click it. if you didn't, reboot wouldn't happen. 19:15:51 personally I think GNOME should do it. 19:15:53 tflink: that's a point. 19:16:04 although i think i've tested it and it actually worked (live suspend, that is.) 19:16:06 adamw: right, but that was an alternative that was discussed. 19:16:07 adamw: yeah, the problem is it isn't anaconda's business to reboot on the live image 19:16:28 Would making a favorite specific to live images also work? 19:16:37 so this might be a different bug 19:16:49 pjones: yeah, i can certainly see that line - but again, we can actually evaluate the NTHness of the bug without the implication that it must actually be changed, counter-intuitive as it seems 19:16:50 should live media be able to suspend? 19:16:58 why not? 19:17:07 because their menu only says 'suspend' instead of 'power off' when the kernel says the system can suspend 19:17:17 so the reason our live media has 'suspend' there is because the kernel is saying it's kosher to suspend 19:17:31 mizmo: it's certainly not a normal case, but I can see somebody doing livecd stuff and slamming their laptop closed and sticking it in their bag, so we probably do have to have it work 19:17:44 so i'm +1 nth to this, with the understanding that that doesn't mean anaconda team actually has to change it; they can perfectly well reject a bug even if it's acceptednth. 19:18:00 yeah, that works for me since its not a blocker 19:18:03 mizmo: ideally live would have both options in the menu, I guess 19:18:17 so we can have the discussion about whether we actually want to do this outside the meeting 19:18:30 adamw, if the bug is accepted NTH and desktop agrees to handle it on their end, does it keep the acceptance? 19:18:48 mizmo: good question, we should probably re-evaluate it then. i can note that in the comment. 19:18:57 proposed #agreed 705189 - AcceptedNTH - A tested fix would be accepted past freeze if the anaconda team chooses to move forward with a fix for this bug 19:18:59 okay, i will talk to them about adding reboot in live envs 19:19:02 in case the change on desktop end would be more intrusive. 19:19:13 ack 19:19:18 +1 19:19:24 #agreed 705189 - AcceptedNTH - A tested fix would be accepted past freeze if the anaconda team chooses to move forward with a fix for this bug 19:19:26 thanks folks 19:19:46 whee, last one (I think) 19:19:52 #topic https://bugzilla.redhat.com/show_bug.cgi?id=733808 19:19:53 Bug 733808: high, unspecified, ---, tcallawa, ASSIGNED, Installer shrink function fails when asked to shrink an NTFS Partition 19:20:03 #info Installer shrink function fails when asked to shrink an NTFS Partition 19:21:18 I don't have a problem with this fix, but I'm not sure about NTH 19:21:29 then again, it sounds like a simple fix 19:21:51 Is NTFS part of the criteria? 19:22:04 I don't think so 19:22:10 but it would be nice to have 19:22:14 -1 then. 19:22:19 resizing is specifically not part of the criteria 19:22:29 as we know it's way too fragile to 'support' 19:22:50 i'm in favour of putting in well-understood patches to improve its reliability, though 19:22:56 bcl: this is a proposed NTH not proposed blocker... 19:23:19 if it's a small, uninvasive change, I'm +1 NTH 19:23:21 however, the fact that this one didn't actually fix bob's issue makes me a bit cautious. 19:23:48 yeah, dlehman's fix is a real fix, but this guy seems to be hitting something else. 19:23:49 david's description in comment #11 does make it sound like this is a fix that makes sense. 19:24:23 so the patch is https://www.redhat.com/archives/anaconda-devel-list/2011-August/msg00398.html ? 19:24:46 yes 19:24:46 if so, that looks pretty reasonable. 19:25:11 i guess it means we're trying to get sizes for more partitions than we would previously, which could be somehow fragile, but... 19:25:18 and it does sounds like the issue was fixed, just has warnings now 19:25:39 no, the guy still can't resize apparently. 19:25:53 well, bob's test still didn't succeed. but that could really be anything. see note above about resizing being fragile. 19:26:11 so, since the fix is small and appears to be clearly correct, and we're still a ways out from beta, i'm pretty comfortable about taking this one as nth. 19:26:21 +1 19:26:27 another thought would be to punt on it until next week 19:26:32 since we haven't hit freeze yet 19:26:39 either way, though 19:27:11 meh. i don't see that would help much, i don't think we're going to get any more info about this. i'd like to just make sure it's in 16.17 and go on... 19:27:15 proposed #agreed 733808 - AcceptedNTH - Resizing partitions isn't supported but a small, tested fix would be accepted during freeze if it came to that 19:27:29 bcl: are you really -1 to nth or was that a misvote? 19:28:03 +1 nth 19:28:13 #agreed 733808 - AcceptedNTH - Resizing partitions isn't supported but a small, tested fix would be accepted during freeze if it came to that 19:28:35 ok, I think that's all of them 19:28:47 #topic open discussion 19:29:02 any other bugs or topics to cover? 19:30:05 i think we're good 19:30:19 I'm still working with upstream on a 3.1 kernel bug that seems to be raid related. Since it currently seems to be just affecting me and it normally takes hours to show up I haven't entered a fedora blocker bug for it. 19:30:28 #info The next blocker bug review meeting will be 2011-09-09 @ 17:00 UTC in #fedora-bugzappers 19:30:58 brunowolff: I assume that its not something that you want to discuss at the moment, then? 19:31:24 Just a heads up, in case other people also start seeing it. 19:31:46 thanks. 19:31:58 I probably won't be able to make that one; that's during Plumbers. 19:32:14 #info brunowolff is still triaging a bug related to the 3.1 kernel and raid, he will update as more information is available 19:32:21 * tflink sets fuse for 5 minutes 19:33:42 5 minutes? good lord. 30 second! 19:34:13 that works for me, this has been long enough as it is 19:34:20 hehe 19:34:25 Thanks for participating everyone! 19:34:30 yup 19:34:31 I'll be sending out minutes shortly 19:34:34 #endmeeting