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