16:00:39 #startmeeting f18beta-blocker-review-6 16:00:39 Meeting started Wed Oct 31 16:00:39 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:39 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:40 #meetingname f18beta-blocker-review-6 16:00:40 The meeting name has been set to 'f18beta-blocker-review-6' 16:00:44 #topic Roll Call 16:00:52 Who's ready for some blocker review fun time? 16:01:03 * kparal is here 16:01:37 * jreznik is here 16:01:41 * satellit- listening 16:01:54 * Martix1 is testing 16:02:41 testing? what is this testing thing of which you speak? 16:02:49 adamw: around? 16:02:50 Fedora 16:02:50 * Viking-Ice here 16:03:17 * nirik is lurking around. 16:03:39 yo 16:03:57 looks like we have enough people to get started 16:04:38 * tflink notes that he didn't send emails to devs yesterday due to an issue with the email generation. ask if you really want the gory details 16:04:51 time for the always fun boilerplate! 16:04:57 #topic Introduction 16:05:04 Why are we here? 16:05:04 #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. 16:05:12 #info We'll be following the process outlined at: 16:05:12 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:05:19 #info The bugs up for review today are available at: 16:05:19 #link http://qa.fedoraproject.org/blockerbugs/current 16:05:25 #info The criteria for release blocking bugs can be found at: 16:05:25 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 16:05:25 #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 16:05:25 #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 16:05:34 trick or treat! 16:05:40 #info Up for review today are: 16:05:43 #info 8 Proposed Blockers 16:05:44 #info 4 Accepted Blockers 16:05:44 #info 19 Proposed NTH 16:05:44 #info 17 Accepted NTH 16:05:54 kparal: does #action count as a trick? 16:06:13 that's a fine trick by my standards 16:06:28 #action kparal to fix and test all of F18 16:06:40 woohoo project pina! 16:06:56 anyways, objections to starting with the proposed blockers? 16:07:09 go ahead 16:07:27 #topic (868558) anaconda needs to tell yum what's a URL and what's a mirrorlist 16:07:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=868558 16:07:32 #info Proposed Blocker, anaconda, ASSIGNED 16:09:14 I think anaconda can't currently use mirrorlists at all 16:09:17 does this happen with netinstall? 16:09:29 tflink: doesn't matter, DVD or net 16:09:43 but Closest Mirror always worked for me 16:09:53 but specifying a mirror list manually didn't 16:10:03 there may be a difference between starting with closest mirror selected and switching to it 16:10:12 ah, so you have to change the default mirrorlist selection? 16:10:17 I'm not even sure Closest Mirror uses a mirrorlist 16:10:20 maybe it's just baseurl 16:10:31 oh, it could just use download.fp.o, yeah... 16:10:50 does anyone have smoke12 dvd handy? could try booting it and switching to closest mirror? 16:11:02 tflink: yes, you need to change that. in my case. the other person seems to indicate it might crash even with default, but I haven't seen that 16:11:30 * tflink boots up a vm 16:11:45 * kparal tries with TC6 16:12:13 hahah, crash 16:12:17 but probably not related 16:13:28 * kparal just reported https://bugzilla.redhat.com/show_bug.cgi?id=871888 16:14:41 smoke12 DVD doesn't crash but it is showing errors on the software selection 16:14:50 when I go into that spoke, no details 16:15:14 tflink: yes, I've seen that, my selecting something should help 16:15:21 *but 16:15:36 tflink: when you leave it should be fine 16:15:39 that's actually intention 16:15:40 al 16:15:51 I entered and left the spoke several times 16:15:53 Ticket notification - f18betablocker: [Bug 871888] AttributeError: 'YumPayload' object has no attribute '_yum' 16:15:56 well, with kparal's reproducer of entering a mirrorlist i'm -1 beta blocker 16:16:07 oh right i think you have to pick another desktop then pick gnome again. 16:16:08 when I switched to cinnimon desktop, the error went away 16:16:11 yeah 16:16:16 i think i filed a bug on that. 16:16:33 i'd like more data on nonamedotc's reproducer though... 16:16:40 read comment 19 16:16:51 still not complete 16:17:01 what was he booting? what was it set to before? 16:17:10 it could be a transient metadata issue in whichever mirror was chosen 16:17:23 could be...the result seems a bit wacky 16:17:38 I retried with TC6 and now it doesn't crash 16:17:51 adamw: you mean the crashing? 16:17:52 seems to be related to currently chosen mirror 16:18:14 tflink: no, what the mirror served 16:18:16 tflink: ask to retest - to check if metadata are now ok/not? 16:18:18 ah 16:18:28 so in kparal's case the response from the server starts out: 16:18:33 '\n' 16:18:52 in nonamedotc's case the response starts out:'' 16:19:04 yes, that's weird 16:19:05 and note the code we're in is looking for .treeinfo 16:19:27 it almost sounds like something got screwed up - dns resolving, broken mirror etc 16:19:30 there's obviously a link there 16:19:30 yeah 16:19:37 i think nonamedotc's case looks like one-time weirdness 16:20:09 indeed 16:20:15 yeah, -1 blocker but repropose/reopen if it happens again 16:20:18 I think I'm +1 Final blocker, -1 Beta blocker, +1 Beta NTH 16:20:20 whereas kparal's is a clearer straightforward bug - it can't handle being passed a mirrorlist URL directly - but to me that's final stuff not beta 16:20:24 agreed 16:20:26 default netinst works fine 16:20:58 well i agree with kparal if we hijack poor nonamedotc's case for the mirrorlist url case 16:21:11 and maybe this code needs better sanitisation so weirdness doesn't crash anaconda 16:21:33 it might not hurt to close and refile 16:22:25 -1 beta +1 nth 16:23:00 either way, it sounds like we're -1 blocker 16:23:15 -1 beta blocker 16:23:40 other thoughts on whether to hijack this or refile the mirrorlist issue? 16:23:48 -1 beta blocker, don't see it as nth (or nth should be sanitize code) 16:25:04 i'll write it up in a comment and ask the devs if they want to split the issues 16:25:43 proposed #agreed 868558 - RejectedBlocker (beta) - The original report seems like a one-time mirror issue and thus this bug was deemed to be not a blocker. The mirrorlist issue seems to be different but more of a final blocker - ask devs whether the issues should be split or not 16:26:19 ack 16:26:21 ack 16:26:46 ack 16:26:51 #agreed 868558 - RejectedBlocker (beta) - The original report seems like a one-time mirror issue and thus this bug was deemed to be not a blocker. The mirrorlist issue seems to be different but more of a final blocker - ask devs whether the issues should be split or not 16:26:55 #topic (867593) installer must stop relying on being able to tell kpartx to use a disk/partition delimiter 16:26:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=867593 16:27:00 ack 16:27:00 #info Proposed Blocker, anaconda, ASSIGNED 16:27:46 sounds like a relatively clear blocker to me 16:28:33 yay for long comments 16:28:38 proposed #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 16:29:00 proposed #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion for dmraid : "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 16:29:14 ack 16:29:52 ack 16:30:12 ack 16:30:27 #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion for dmraid : "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 16:30:31 #topic (868535) AttributeError: 'NoneType' object has no attribute 'get' 16:30:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=868535 16:30:36 #info Proposed Blocker, anaconda, MODIFIED 16:32:15 b) connect to wifi using AP without spaces or plug cable with dhcp in 16:32:16 1) visit network spoke from hub -> this bz 16:32:28 it sounds like wireless won't work in pretty much any situation 16:32:30 huh. so anaconda prompts you for a network connection even if you're installing from dvd. seems a bit bizarre, but oh well. 16:32:40 certainly sounds like this will crop up enough that it's at least NTH, probably blocker 16:32:49 this particular bug isn't actually wireless specific 16:32:51 * nirik is def +1 NTH... 16:33:02 adamw: is it not? 16:33:14 no, but if I'm reading it correctly, wireless won't work for netinstall or DVD 16:33:17 aiui, if you start install without a working network connection, anaconda prompts you for one before displaying the hub, and when you finish that dialog, anaconda crashes 16:33:34 kparal: comment #20 and #21 16:33:45 I see 16:33:47 that's pretty bad 16:33:51 i'm pretty sure this bug basically means you can't possibly proceed with install if you start without the network up 16:33:53 so that sounds blocker to me 16:33:54 ok, this is only if you try to change network after starting install 16:34:25 crash with wired crashes was random in my experience. wireless - always 16:34:28 tflink: not exactly. it concerns a specific instance of the network spoke you get at the start of install if you begin install with no network connection. 16:35:02 oh, wait...b) 1)...yeeks. 16:35:04 adamw: i remember this crashed happening even from network spoke - back to hub situation .. 16:35:54 proposed #agreed 868535 - AcceptedBlocker - Violates the following F18 alpha release criterion for machines without a network connection when anaconda starts (wireless, eth not plugged in etc.): "The installer must be able to use at least one of the HTTP or FTP remote package source options" 16:35:55 okay, lemme take another cut at it... 16:35:58 nack 16:36:12 i think to hit this you have to hit the pre-hub network spoke _and then go into the post-hub network spoke too_ 16:36:25 * satellit if you try to configure wep wireless get popup configure but does not connect (with wired conection with dhcp) will not start wireless "not connected" 16:36:30 basically if you run an install which hits the pre-hub network spoke, the hub network spoke becomes a landmine that explodes your install 16:36:45 i *think* that's it. 16:36:54 icky. if so, +1 blocker 16:37:06 I'm also +1 blocker 16:37:21 definite +1 nth, blocker seems slightly more questionable but i don't mind +1. 16:37:36 yeah, I'm not so convinced this is a blocker but I'm not -1, either 16:38:08 well, nth then? 16:38:19 * jreznik is not sure he understood it correctly 16:38:45 how often the pre-hub network spoke is shown usually? 16:38:50 thoughts on criterion? 16:38:56 * tflink isn't seeing anything off hand 16:38:59 so what exactly is the deal here 16:39:10 does it explode with wired or wireless or both 16:39:27 wireless and I imagine wired w/o dhcp 16:39:33 * kparal pinging rvykydal 16:39:41 unless network is configured via kernel boot options 16:39:44 +1 nth 16:40:37 jreznik: it's supposed to be shown if you start install without a working network connection 16:40:55 jreznik: due to another bug, at present it's not shown if you have a wired connection but DHCP fails (anaconda considers that a working connection when it shouldn't) 16:41:31 adamw: yep but how many times do you hit this error? eg how many people start without it? probably wireless always? 16:41:44 looks like we have +2.5 blocker +5 NTH (including me) 16:42:17 jreznik: wireless is the obvious case 16:42:43 i guess you're unlikely to hit this if you actually don't have a network connection as you'd have no reason to go into the network spoke post-hub 16:43:00 the other case would be non-DHCP wired connections, i guess 16:43:06 I think you needed to go there to configure wifi password 16:43:22 I'm getting closer to -1 blocker unless I'm missing something 16:43:34 shall we just vote it through as NTH and move on? 16:43:35 kparal: can't you configure the password in the pre-start network config 16:43:37 this is taking time 16:43:42 * nirik is ok with NTH I guess. 16:43:42 we can revisit the blocker question if it becomes necessary 16:43:46 tflink: I think there was a bug in it as well 16:43:48 I can't find a criterion, anyways 16:44:45 proposed #agreed 868535 - AcceptedNTH - While not a clear blocker, crashing when trying to configure network after initial wireless setup is bad and this can't be fixed after release with an update. 16:44:55 or did we want to reject as a blocker? 16:45:14 i'm fine with leaving it open 16:45:33 I think accept as NTH and maybe change mind in the future with better proof 16:45:34 I'm pretty sure we're going to be no-go, anyways 16:45:47 so ... ack/nak/patch? 16:45:48 ack 16:45:51 ack 16:45:52 ack 16:45:55 ack 16:45:57 ack 16:45:57 ack 16:46:13 #agreed 868535 - AcceptedNTH - While not a clear blocker, crashing when trying to configure network after initial wireless setup is bad and this can't be fixed after release with an update. A tested fix would be accepted past freeze 16:46:33 * tflink assumes that nobody has issues with adding the last sentance. otherwise #undo is possible 16:46:45 #topic (871129) Network is considered 'up' even if DHCP fails 16:46:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=871129 16:46:45 #info Proposed Blocker, anaconda, MODIFIED 16:47:50 so this causes problems for cases where static config of wired networking is required 16:47:59 +1 blocker 16:48:03 -1 blocker 16:48:08 because of comment #1 16:48:11 but +1 NTH 16:48:32 have someone tried that using boot options to configure network works? 16:48:39 i dunno 16:48:42 or GUI 16:48:55 yeah, -1 blocker +1 NTH 16:49:19 * jskladan is also +1 NTH 16:49:21 * adamw is not taking down his entire network to test this =) 16:49:49 I might be able to disable a specific MAC from my dhcp server 16:50:03 it should be easy to test in a VM 16:50:04 +1 nth 16:50:08 -1 blocker +1 NTH 16:50:12 (ahd hello) 16:50:19 morning jesse 16:50:22 anyway, if Radek's comment is valid, +1 nth -1 blocker 16:50:24 kparal: I hear a volunteer :) 16:50:43 Ticket notification - f18betanicetohave: [Bug 868535] AttributeError: 'NoneType' object has no attribute 'get' 16:51:34 proposed #agreed 871129 - RejectedBlocker, AcceptedNTH - This doesn't prevent configuration of static networking but this shouldn't happen for non-dhcp setups. A well tested fix would be accepted after freeze. 16:51:39 ack/nak/patch? 16:51:42 ack 16:51:44 ack 16:51:57 ack 16:51:58 ack 16:52:01 #agreed 871129 - RejectedBlocker, AcceptedNTH - This doesn't prevent configuration of static networking but this shouldn't happen for non-dhcp setups. A well tested fix would be accepted after freeze. 16:52:05 #topic (870208) Logoff does not close session so if Restart or Shutdown performed from Logon screen after logoff Authentication dialog presented 16:52:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=870208 16:52:11 #info Proposed Blocker, gnome-desktop3, NEW 16:53:30 looks like a regular bug to me 16:53:34 i don't think this is new, and i don't think it's a blocker 16:53:36 -1 blocker -1 nth 16:53:44 -1/-1 16:53:53 can be fixed with an update, aside from anything else. 16:53:55 -1/-1 16:53:59 -1/-1 16:54:00 yeah, I've been seeing this quite a bit but -1/-1, not a blocker and can be fixed w/ update 16:54:41 -1/-1 16:55:07 proposed #agreed 870208 - RejectedBlocker, RejectedNTH - This doesn't violate any of the F18 beta release criteria and could easily be fixed with an update. Thus this bug is rejected as a blocker or NTH for F18 beta 16:55:11 ack/nak/patch? 16:55:26 ack 16:55:32 ack 16:55:44 ack 16:55:51 ack 16:55:51 #agreed 870208 - RejectedBlocker, RejectedNTH - This doesn't violate any of the F18 beta release criteria and could easily be fixed with an update. Thus this bug is rejected as a blocker or NTH for F18 beta 16:55:55 #topic (844167) Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64 16:55:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=844167 16:56:01 #info Proposed Blocker, selinux-policy, MODIFIED 16:56:08 oh god, this thing again 16:56:11 can it please just die 16:57:11 it could affect upgrade as I understand it 16:57:16 yes 16:57:25 it's been left open forever because we didn't know if it affected fedup 16:57:25 does it? 16:57:34 you being Mr. Fedup Tester 16:57:41 depends on if the bug happens in permissive mode 16:57:41 then let's punt it once more 16:57:54 I haven't tried an upgrade with libvirt installed yet 16:58:12 request the reporter testing with fedup once it becomes widely available 16:58:19 the upgrades that have explodified have been due to other issues 16:58:24 using permissive seems to be the workaround for this bug, so if fedup runs permissive, i think we're fine 16:58:25 ah. 16:58:35 i'm okay with -1 or punt. 16:58:50 it runs in permissive at the moment but I think that there are plans to get it to work in enforcing 16:58:55 wwoods added a fix that I haven' 16:59:02 t gotten around to testing yet 16:59:07 Ticket notification - f18betanicetohave: [Bug 871129] Network is considered 'up' even if DHCP fails 16:59:08 arent selinux bugs been fixed by beta 16:59:16 supposed to be 17:00:00 Viking-Ice: ones in the straight through install / boot process iirc 17:00:07 from c#60, it sounds like it might be fixed with latest f18 build of selinux-policy 17:00:21 oh, no, that's Final - "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" 17:00:35 so this is only a blocker if it breaks fedup upgrades 17:00:35 ah that's final 17:00:36 I'm more for punt 17:00:43 and I need to get this tested 17:00:43 yeah let's punt it 17:00:46 ok punt 17:01:13 proposed #agreed 844167 - We're still not sure if this affects fedup, will re-evaluate after more testing has been done 17:01:32 #action tflink to test fedup upgrade from 17 to 18 with libvirt installed on F17 17:01:41 ack 17:01:46 ack 17:01:46 ack btw we should match the selinux criteria with the normal install and upgrade process as they should be one and the same 17:02:06 ack 17:02:12 #agreed 844167 - We're still not sure if this affects fedup, will re-evaluate after more testing has been done 17:02:25 Viking-Ice: yeah, i think that's reasonable, we should expand the criterion to cover upgrade 17:02:26 #topic (869061) No output to journal after double-switch-root 17:02:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=869061 17:02:26 #info Proposed Blocker, systemd, NEW 17:03:19 the short version of this is that there is no easily accessible output from fedup during upgrade 17:03:30 yeah but the root cause has not been found 17:03:38 true 17:03:38 there's still no answer to the question whether it needs to be fixed in frozen packages, but 17:03:40 so punt for wwoods responce 17:03:50 adamw: I pinged wwoods yesterday about it 17:03:55 it depends on how we handle upgrades for beta, to be honest 17:04:05 and how hacky we're willing to let the upgrade process be 17:04:19 I'm going for not so hacky 17:04:28 that would be nice :P 17:04:34 the systemd that's in question here is the version used to build the upgrade initramfs 17:04:55 so if we're assuming that the idea is to build an upgrade.img that everyone gets from our servers, maybe the fix needs to be frozen 17:05:02 so if we require systemd on the initramfs builder to be from frozen F18 then yes, it does need to be fixed in the frozen package set 17:05:08 "That's usually an indicaiton that an old systemd tried to talk to a new journald" 17:05:11 though actually we didn't decide on any official process for building that upgrade.img , so does it have to be built from frozen repos? who knows? 17:05:40 I just noticed the request for a reproducer 17:05:51 seems like the kind of thing that oh i don't know maybe should have been determined through the feature process. but le sigh. :) 17:05:56 I'll update the bug with current upgrade process to reproduce 17:06:05 honestly I'm a bit concern about these kind of issues 17:06:09 i think lennart wants a reproducer that does not involve an entire f17 upgrade. 17:06:18 good point 17:06:43 Viking-Ice: me too, in the sense that it exposes the fact there are rather serious release engineering decisions being made up as will goes along. 17:06:44 where it seems that the fedup is depended on specific dracut/systemd release 17:07:02 but i guess we're a bit off-topic 17:07:03 that's a communication issue, I think 17:07:06 so sounds like we're punting? 17:07:19 we need more data 17:07:21 so yeah 17:07:25 punt ( again ) 17:07:55 I'm +1 blocker on the 'no output during upgrade' issue but agreed that the cause isn't actually that clear 17:08:17 you can still access those logs from a shell 17:08:17 right 17:08:26 right, i'd be +1 on the issue _qua issue_, but the question that isn't answered yet is whether we actually need to fix this in the frozen package set. 17:08:47 it's better to pull the update in I would say rather then leaving it frozen 17:08:54 proposed #agreed 869061 - We still need more information on whether or not this actually needs to be fixed in the frozen package set and what the exact issue is 17:08:57 ack 17:09:03 ack 17:09:17 ack 17:09:19 #agreed 869061 - We still need more information on whether or not this actually needs to be fixed in the frozen package set and what the exact issue is. 17:09:53 * Viking-Ice thinks it's not an systemd issue 17:10:01 but wwoods issue ;) 17:10:16 have we figured out how we're going to approach the frozen issue or are we waiting for input from will? 17:10:31 I want to pull the release inn 17:11:10 * tflink was more interested in how the decision is being approached than actual solutions atm 17:11:30 not that the solution isn't important, just that we still have plenty of bugs to go through 17:12:02 anyways, on to the next bug 17:12:08 #topic (871161) Fedora Upgrade Tool for F18 (fedup) requires systemd-195 17:12:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=871161 17:12:08 #info Proposed Blocker, systemd, NEW 17:12:31 I think this is an clear blocker 17:12:51 security issues aside, the short version is that fedup uses functionality from systemd that isn't present until 195 17:13:04 yup 17:13:21 therefore, if functioning fedup is a blocker; we need systemd-195 17:13:29 yup again 17:13:40 sorry to be difficult, but again there's the issue of the frozen package set. we still don't know where fedup will get its systemd. 17:13:55 this would be a hell of a lot easier if someone would just nail down how the process is meant to work. 17:13:55 * tflink has been doing testing with 195-4 (which is different from the update in updates-testing) 17:14:01 but i guess i don't mind taking it. 17:14:08 I just started testing with 195-2 17:14:13 plus it fixes "Journal leaks memory " 17:14:30 ok, who do we need to aim our annoyance-phasers at to get the answer? 17:14:58 the fedup package depends on systemd 195 17:15:17 I'm aware of what the options are for handling the build issues, I just don't know what's planned 17:15:30 i think will needs to hammer it out with releng. 17:15:33 or infra. 17:15:36 regardless where the update image get process from + reportes and other users might want to test fedup by creating their own update.img manually what then? 17:15:41 or whoever would actually be in charge of building the images and mirroring them. 17:15:58 and locally 17:16:00 Viking-Ice: well if you're creating it locally you can always grab systemd from updates-testing, right? 17:16:18 Viking-Ice: that's assuming you have an extra F18 box sitting around to build the initramfs 17:16:29 adamw, looking over the update there is nothing that might cause regression I see there so I dont see why cant just pull it in 17:16:51 my understanding is that the options are either to use a magical side repo with the upgrade.img in it or to modify lorax such that the upgrade modules are pulled in to the released initramfs in the tree 17:17:12 Viking-Ice: i already said i don't really mind pulling it in, i'm just expressing frustration that the process is still so unclear we really can't tell for sure whether this really ought to block the beta release 17:17:29 Viking-Ice: there is no such thing as a major version change that _cannot_ cause regressions 17:17:32 so if we were doing this via lorax it'd pretty much have to be frozen 17:17:58 my impression is that there are no plans to update lorax for beta 17:18:00 adamw, no argument from me that this is to vague but I dont want it missing be an show stopper 17:18:16 eh, let's just take it, life's too short 17:18:27 I think there are bigger issues with fedup right now than which version of systemd is in stable 17:18:35 since this meeting's logged i now have my 'i told you so' card up my sleeve :) 17:18:46 * tflink is +/- 0 on this 17:19:05 in principle, I'm +1 17:19:05 there's the point that if we're going to wind up taking this we should probably take it _now_ 17:19:08 I'm +1 17:19:18 i guess that's better than realizing next tuesday we need to pull it in and re-test everything 17:19:20 and now is the timne 17:19:29 to pull it in 17:19:32 yeah 17:19:35 but I also agree that there is not enough information on how all the upgrade stuff is going to work 17:19:41 I would also say to pull it in 17:19:53 shall we call it accepted nth, blocker status uncertain, and pull it in now? 17:20:04 yup 17:20:05 on the basis of the reasoning above rather than the usual nth reasoning 17:20:23 that feels a bit like a fudge to me, but I'm not really going to fight it 17:20:46 so, punt on blocker, +1 nth? 17:20:49 tflink: i actually kinda like it because it expresses 'this may be necessary so we should pull it right now to get it tested, but if it turns out it breaks stuff and we don't actually need it for fedup, it can be taken out again' 17:20:50 yeah 17:21:07 adamw, agreed 17:21:17 if we pull it in now we can back out of it 17:21:18 ok 17:21:49 makes sense 17:22:27 ^^ 17:22:46 proposed #agreed 871161 - AcceptedNTH - We recognize that this is likely required for upgrades but there are too many unanswered questions to take this as a blocker. However, testing of this update needs to start sooner than later and it is accepted as NTH for F18 beta. A tested fix would be taken past freeze. 17:22:56 ack 17:23:02 ack 17:23:02 ack 17:23:09 * tflink needs to verify that 195-2 actually works with fedup 17:23:13 ack 17:23:17 #agreed 871161 - AcceptedNTH - We recognize that this is likely required for upgrades but there are too many unanswered questions to take this as a blocker. However, testing of this update needs to start sooner than later and it is accepted as NTH for F18 beta. A tested fix would be taken past freeze. 17:23:26 ok, that's all of the proposed blockers 17:23:41 any preferences on going through the accepted blockers or proposed NTH first? 17:24:21 that sounds like a no 17:24:26 on to the proposed NTH! 17:24:28 I'm going out for a smoke that's my propose ;) 17:24:55 * tflink isn't sure how to word that as a proposed #agreed 17:25:00 is there a bz for that? 17:25:03 :-D 17:25:07 proposed nth is good 17:25:19 we need to evaluate them so anaconda team knows what to put in 18.22 17:25:27 #topic (855646) custom partition setup: missing volume/device identification 17:25:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=855646 17:25:27 #info Proposed NTH, anaconda, NEW 17:26:53 +1 NTH, this is an improvement we decided on a week back or so that is wanted by some forum testers 17:27:04 +1 NTH 17:27:09 makes it much easier to figure out what partitions listed in Unknown are 17:28:10 proposed #agreed 855646 - AcceptedNTH - This alleviates some issues with custom partitioning and determining what can be deleted and what can't. Since this can't be fixed with an update, a tested fix would be taken past freeze. 17:28:11 * jskladan is a slow reader, but seems like +1 NTH to me so far 17:28:22 * kparal finished reading, +1 nth 17:28:28 ack 17:28:30 ack 17:28:35 ack 17:28:38 #agreed 855646 - AcceptedNTH - This alleviates some issues with custom partitioning and determining what can be deleted and what can't. Since this can't be fixed with an update, a tested fix would be taken past freeze. 17:28:50 #topic (869185) Crash when reclaiming space on disks with incomplete LVM 17:28:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=869185 17:28:50 #info Proposed NTH, anaconda, NEW 17:29:35 isn't this a blocker? 17:29:48 well 17:30:04 it's kinda broken disk layout 17:30:04 unless you're trying to reuse the partial VG? 17:30:20 I tried to delete it 17:30:52 it still shouldn't crash 17:30:54 it's true this Beta could cover it: 17:30:54 Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types 17:31:11 or "rejecting obviously invalid operations without crashing" 17:31:18 so it can be also discussed as Beta blocker 17:31:35 but on the other hand, how many users are going to have a partially removed VG 17:31:35 yeah...if we're going on the existing criteria (i'm still supposed to be revising them, remember) it may be a +1 17:31:44 but dlehman said they don't plan to fix this in Beta. so they wouldn't be happy 17:31:59 * Viking-Ice back 17:32:18 i think i'm ok with -1 blocker +1 nth 17:32:22 and +1 final blocker 17:32:53 Ticket notification - f18betanicetohave: [Bug 871161] Fedora Upgrade Tool for F18 (fedup) requires systemd-195 17:32:57 if this only happens with invalid LVM layouts, I'm ok enough with -1 betablocker, +1 nth and +1 final blocker 17:33:22 * kparal agrees 17:33:33 +1 nth +1 final 17:33:42 ^^ 17:34:40 well, the timing is perfect as usual. I'm about to step away right when you start getting to my bugs. 17:35:18 proposed #agreed 869185 - RejectedBlocker (beta), AcceptedNTH - This doesn't seem to affect enough installs to justify taking as a blocker for F18 beta. However, crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. 17:35:22 dlehman: any thoughts about this one? 17:35:27 * tflink wasn't sure how to word the accepted final blocker part 17:35:48 patch 17:35:52 the catch-all final criterion 17:35:59 it wasn't proposed Beta blocker, so we don't need to reject it 17:36:13 oh, good point 17:36:28 * akshayvyas is here 17:37:38 oh i am late :) 17:37:39 proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - This doesn't seem to affect enough installs to justify taking as a blocker for F18 beta. However, crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the following F18 final criterion for invalid LVM source layouts: "The installer must be able to create and install to a 17:37:46 which is way too long 17:38:00 how about we just propose it as a final blocker and deal with it then? 17:38:06 you don't need the bit about justifying it as a blocker. 17:38:16 the whole first sentence. 17:38:23 just start at 'Crashes in the installer are bad..." 17:38:25 -1 for beta blocker on the broken lvm thing, +1 final blocker 17:38:59 proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the following F18 final criterion for invalid LVM source layouts: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, L 17:39:06 isn't that still too long? 17:39:14 it is 17:39:23 what's the last word? 17:39:27 configuration 17:39:50 ack 17:39:54 can we just configure the IRC channel somehow? this is ridiculous 17:40:01 heh 17:40:18 i think you could shorten 'due to violation of the following F18 final criterion for invalid LVM source layouts'. 17:40:30 proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or co 17:40:31 * jreznik is back from fesco meeting, my tickets are over... back to fun 17:40:34 kparal: we're teaching tflink concision 17:40:40 so close! 17:40:52 adamw: coming from you? 17:40:59 touche 17:40:59 touche 17:41:02 :) 17:41:26 i just got touche touched 17:41:37 so close but nobody will tell me where it's cut off ... 17:41:49 tflink: , or co 17:42:10 proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combinati 17:42:16 combinati 17:42:18 wait, that's just as long 17:42:19 oh for god's sake that's close enough 17:42:34 just put a ... on the end 17:42:41 we know what criterion it is 17:42:49 proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, ..." 17:43:01 let's hash the criterion text and tag it with checksums 17:43:02 or just the number of the criterion it hits.. 17:43:06 solution! 17:43:21 the number won't work if the criteria change 17:43:21 Viking-Ice: that changes, checksum doesn't 17:43:41 checksum makes it hard to understand unless you know the criteria ahead of time 17:43:54 in theory hits beta criteria "10" should suffice 17:43:55 * tflink would prefer a url shortening scheme of some sort 17:44:12 but we're getting way off into the weeds 17:44:12 i've thought about this, it gets tricky. 17:44:20 ack/nak/patch? 17:44:34 my best plan so far was to use page anchors, but you have to be careful the anchor text will be valid if the criterion changes... 17:44:34 ack 17:44:58 ack 17:45:00 ack 17:45:05 ack 17:45:13 #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, ..." 17:45:26 #topic (868509) LUKS passphrase exposed in storage.log attached to bug report 17:45:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=868509 17:45:26 #info Proposed NTH, anaconda, MODIFIED 17:45:48 this is a politcal issue not technical one 17:45:51 +1 nth, identified as a security issue by srt, can't be fixed with an update. 17:46:08 yep +1 nth 17:46:47 +1 nth would like to get dlehman take on this thou ( since they are doing it deliberate ) 17:46:50 adamw: about srt, which comment? 17:47:11 proposed #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the output kickstart file are a security issue and this can't be fixed with an update. 17:47:20 ack 17:47:33 kparal: oh sorry, i was confusing this with the other issue, but comment #7 effectively 17:47:49 ack 17:47:50 this is less serious than i thought in comment #8, but still worth fixing. 17:47:51 the storage.log isn't deliberate, actually. code changed without regard for security of the logs 17:48:01 it's trivial to fix 17:48:04 oops, patch 17:48:07 i think viking was confusing this with the other bug too :) 17:48:48 the storage.log one is trivial to fix and should absolutely be fixed 17:48:54 proposed #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the storage log are a security issue and this can't be fixed with an update. A well tested fix would be considered past beta freeze 17:49:19 ack 17:49:30 the anaconda-ks.cfg one is somewhat debatable, but leaving them out errs on the side of caution IMO which is fine in this case 17:49:40 ack 17:50:04 ack 17:50:12 ack 17:50:13 #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the storage log are a security issue and this can't be fixed with an update. A well tested fix would be considered past beta freeze 17:50:24 #topic (866717) f18 anaconda cannot use the selected disk (continue button remains grayed out and the disks does 'not count' for anaconda) (reproduced) 17:50:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=866717 17:50:29 #info Proposed NTH, anaconda, ASSIGNED 17:51:15 +1 nth 17:51:35 +1 17:51:39 +1 17:51:47 +1 nth 17:51:55 * dlehman goes afk for an hour or more 17:52:10 +1 nth. 17:52:12 dlehman: the next 4 NTH are assigned to you 17:52:43 +1 nth 17:52:53 yeah, the reason I came was to argue for them if needed but oh well. I've used my blocker meeting time slot up now. 17:53:14 proposed #agreed 866717 - AcceptedNTH - While not a blocker, being able to select additional disks is somewhat expected. A tested fix would be considered past freeze. 17:53:25 ack 17:53:39 ack 17:53:40 ack 17:53:47 #agreed 866717 - AcceptedNTH - While not a blocker, being able to select additional disks is somewhat expected. A tested fix would be considered past freeze. 17:54:03 #topic (868468) anaconda displays previously installed Fedora systems as Unknown in Manual Partitioning 17:54:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=868468 17:54:09 #info Proposed NTH, anaconda, ASSIGNED 17:54:23 i'd be -1 later on, but since we have a week, +1. 17:55:02 our inconsistency on reasons for taking/rejecting NTH confuses me 17:55:25 yup 17:55:32 me as well 17:56:04 eh, I'm not so convinced this is needed for beta 17:56:44 +/- 0 nth 17:56:57 tflink: but i thought we're sensible people with common sense! ;) 17:57:20 +1 nth 17:57:44 to be honest i'm in a kind of 'we have a week before go/no-go and next anaconda is going to be a huge change anyway, so let's stick in all the fixes that look really useful for now' 17:57:47 adamw: generally yes but the lack of consistency is pretty frustrating 17:57:48 frame of mind 17:58:07 when stuff like https://bugzilla.redhat.com/show_bug.cgi?id=860551 is taken when no fix is even proposed 17:58:07 we're not really at the point where we have a 99% good RC and we really don't want to change it unless we absolutely have to 17:58:17 if you are dual booting and manual partitioning and let's say we have windows on one how would you tell them apart if they are "unknown" 17:58:20 which isn't what NTH is, according to previous meetings 17:58:33 sidetrack! 17:58:47 Viking-Ice: aiui this bug is btrfs-specific so it's unlikely to affect windows installs :) 17:58:53 for now, yes. I get dismissed with "sidetrack" again 17:58:55 but in theory any OS you can install to btrfs could wind up as Unknown. 17:59:14 it sounds like we're mostly +1 nth? 17:59:20 well, where 'mostly' is 2. 17:59:23 * tflink counts +2 17:59:29 I don't see any -1s 17:59:32 * kparal has no opinion here 17:59:37 ^^ 17:59:48 throw it in the basket! 17:59:52 that means +1 nth 17:59:59 because that's never gotten us into trouble before ... 18:00:11 =) 18:00:45 if you really feel strongly about it i don't mind changing to -1 on the 'tough on nth' mindset 18:00:53 * tflink is changing his vote to -1 18:00:54 like i said i'd be -1 if we were closer to done 18:00:58 but I'm still outvoted 18:00:59 me too 18:01:10 how many people are going to have btrfs subvols preexisting? 18:01:16 i think viking and i tend to vote pretty 'conditionally' when it comes to nth 18:01:21 that's a fair point. 18:01:26 okay, count me -1. 18:01:38 you couldn't do btrfs in F17 w/o doing custom partitioning 18:01:53 wasn't btrfs entirely disabled for f17? 18:01:56 and if you know enough to do that, you can handle the "unknown" in the installer? 18:01:56 +1 tflink 18:01:57 if "btrfs" is supposed to be next release default desktop we should be working in advance and start identifying related bugs now 18:02:15 adamw: by custom, I mean cli - possibly outside the installer 18:02:15 mean default filessystem 18:02:45 so we're +2, -2? 18:02:53 progress :-D 18:02:54 i count -3 18:03:00 akshay said '+1 tflink' 18:03:08 i am -1 18:03:15 ok, -3, +2 18:03:20 i said +1 for what tflink said 18:03:24 mine counts as 5 so I beat you all muhaha 18:03:35 I'm fine with -1 since it affects only btrfs 18:03:35 * adamw flips frantically through rule book 18:03:36 :P 18:03:41 uh, it's not +2 any more. i changed to -1. 18:03:43 there's only +1. 18:03:51 viking and kparal at the time 18:03:51 oh wait, kparal was +1 too. 18:03:53 confusion! 18:03:58 * kparal still has no opinion 18:04:03 it only affects btrfs with subvols - not even all btrfs 18:04:04 you're just easily swayed 18:04:11 okay...everyone vote again 18:04:16 -1 18:04:19 * adamw is now -1 nth, tflink convinced me 18:04:21 -1 18:04:24 -1 18:04:27 * kparal begins to write a proposal how to handle nth bugs differently 18:04:51 kparal: here, have some gin. 18:05:05 that looks like -4 +0. 18:05:16 tflink, root is a subvolume too 18:05:44 proposed #agreed 868468 - RejectedNTH - While unforutnate, this appears to only affect systems with pre-existing btrfs subvols. It was deemed uncommon enough not to justify NTH status for F18 beta, especially since btrfs partitioning was not possible through anaconda for F17. 18:05:49 ack 18:05:54 ack 18:05:56 or at least that's how Fedora 18 sets it up 18:05:57 er, patch - typo in 'unfortunate' 18:05:58 ack 18:06:25 ack 18:06:34 #agreed 868468 - RejectedNTH - While unfortunate, this appears to only affect systems with pre-existing btrfs subvols. It was deemed uncommon enough not to justify NTH status for F18 beta, especially since btrfs partitioning was not possible through anaconda for F17. 18:07:06 so Fedora 18 over Fedora 18 is the most likely thing to trigger that, no? 18:07:30 nanonyme: don't you have to do that in custom partitioning? 18:07:40 yeah, you do 18:07:41 I didn't think that autopart in F18 used btrfs 18:08:38 and it's just an inconvenience anyway, the significant F18 Btrfs over F18 Btrfs issues are already fixed that I know of 18:08:39 f18 over f18 custom part install is the reproducer, by the looks of it. 18:08:40 move along 18:08:44 +1 viking :) 18:09:00 #topic (870569) Custom partitioning should allow the user to specify which disk a partition should wind up on 18:09:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=870569 18:09:05 #info Proposed NTH, anaconda, ASSIGNED 18:09:22 +1 nth, this is a greatest hit for sure. 18:09:52 +1 nth 18:09:52 wasn't the RFE bug closed? 18:09:57 +1 nth 18:10:20 tflink: ? 18:10:32 nvm, that was for the bootloader location 18:10:36 +1 nth 18:10:37 +/- 0 18:11:42 proposed #agreed 870569 - AcceptedNTH - While not a blocker for F18 beta, this functionality is important for final and would be good to start testing now. A tested fix would be considered past freeze. 18:11:46 ack 18:11:52 ack 18:11:54 ack 18:11:56 #agreed 870569 - AcceptedNTH - While not a blocker for F18 beta, this functionality is important for final and would be good to start testing now. A tested fix would be considered past freeze. 18:12:14 #topic (871104) Installer allows use of preexisting root filesystem 18:12:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=871104 18:12:14 #info Proposed NTH, anaconda, NEW 18:12:53 +1 nth 18:13:32 actually I would be glad if this never gets fixed 18:13:38 +1, it's a safety check so not likely to cause problems. 18:13:43 kparal: ? 18:13:56 it can certainly speed some things up 18:14:01 I don't separate /home, and I use to reinstall by cleaning everything except /home 18:14:07 but it would put a system into a really unknown state. 18:14:08 force-formatting of / is evil 18:14:22 that's a highly crack-addled use case that i don't think we should support. 18:14:34 kparal: that sounds like a bad idea in the first place - why not just separate /home? 18:14:37 if you want to act as if /home is a separate partition make it a flipping separate partition. 18:14:40 or use ks 18:14:48 tflink: because separating /home is so 80s 18:14:53 I have a small disk, always 18:14:53 Not sure he can use KS to get the desired effect 18:14:57 no matter how large it is 18:15:18 anyway, that's just my rant 18:15:18 * adamw still +1. 18:15:21 so 80s? you're fine with your / filling up if you download too much? 18:15:22 don't let me sidetrack you 18:15:32 -1 nth 18:15:44 tflink: sure, it still has 5% reserved for root 18:15:48 so it sounds like +2, -2? 18:16:04 * kparal will just not vote here 18:16:09 Viking-Ice: why -1? 18:16:13 so +2, -1 18:16:37 I'm +1 NTH 18:16:49 +3, -1 18:16:51 wait, are these existing blockers? 18:17:02 jlk: just nth 18:17:06 ah, ok, yeah NTH 18:17:10 we're on proposed NTH. 18:17:12 adamw, I dont want to risk pulling something in at this time that is fiddling with partition layout on such an fundemental level 18:17:36 Viking-Ice: all it does is disallow a specific operation, it doesn't change any 'active' code aiui 18:17:50 would be nice to see the patch i guess 18:17:53 I don't think it fiddles with the partition layout much, just doesn't allow existing / to be selected w/o reformatting 18:18:03 adamw: you have a point 18:18:31 * adamw checks patches-list 18:18:39 if it's an minor change I'm +1 18:18:59 adamw, wasn't it anyway so that we can nay later since it's just nth? 18:19:10 (ie if patch sucks :p) 18:19:15 https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001824.html is the patch i believe 18:19:20 Viking-Ice: ^^^ 18:19:55 ok +1 nth 18:20:49 proposed #agreed 871104 - AcceptedNTH - Reusing / without reformatting is a bad idea and hasn't been allowed in anaconda for a while. A tested fix would be considered past freeze. 18:20:57 ack 18:21:03 the funny thing with this bug, if you have a valid rpmdb on your / filesystem, yum actually tries to do an upgrade rather than an install 18:21:12 ack 18:21:20 you could almost use this bug to upgrade F17 to F18 18:21:32 ack 18:21:35 #agreed 871104 - AcceptedNTH - Reusing / without reformatting is a bad idea and hasn't been allowed in anaconda for a while. A tested fix would be considered past freeze. 18:21:41 jlk: haha. 18:21:44 it's a feature! 18:21:52 #topic (871109) Confusing text in label for checkbutton to use custom partitioning 18:21:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=871109 18:21:58 #info Proposed NTH, anaconda, ASSIGNED 18:22:37 +1 NTH. 18:22:44 +1 18:22:49 nth 18:23:21 +1 nth 18:23:30 +1 18:23:50 +1 18:23:59 proposed #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze. 18:24:11 isn't this way past the translation deadline, though? 18:24:39 tflink: the question is - are anaconda translations already frozen? 18:24:59 the translations have been screwed anyway, i believe 18:25:03 I think they're supposed to be but I'm not sure, to be honest 18:25:05 as it's still under development... and I'm not sure exception was granted 18:25:08 i think newui has been pretty much ignoring the freeze 18:25:12 jlk? 18:25:36 we've sortof had a blanket translation freeze break going on 18:25:44 tflink: it's definitely after deadline and when I talked to translators, they were thinking about exception...but nobody asked that time for one 18:26:59 shall we say we're +1 NTH on this from a pure NTH process perspective, but that doesn't prejudice a translation freeze issue? 18:27:15 ack 18:27:15 i.e. if someone wants to enforce the string freeze here, that's a separate issue 18:27:36 proposed #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze if the translation freeze break is approved. 18:27:43 sounds good, ack 18:27:44 ack 18:27:56 ack 18:27:59 #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze if the translation freeze break is approved. 18:28:14 #topic (869675) RFE: Anaconda should warn user when disabling root account in certain situations 18:28:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=869675 18:28:19 #info Proposed NTH, anaconda, ASSIGNED 18:29:02 well anaconda should not allow for root password not being set in minimal installations 18:30:04 i think i put my opinion in comment #9 18:30:14 +1 nth 18:30:19 i'm kinda +1 but i could be argued out of it 18:30:34 so the change is to always require a root password? 18:30:34 if we do this change we do it now or we dont for the rest of the release cycle 18:30:55 mean development cycle 18:31:50 tflink: no, aiui 18:31:51 i'm with comment 6 on "desired" anaconda behavior noobs dont know what root password is hence the sudo scheme fits them better 18:31:53 wait a sec here 18:32:00 I think this bug is already fixed, or made obsolete 18:32:01 the change is to require a root password when firstboot isn't being installed, if i'm reading correctly 18:32:04 i made that mistake too 18:32:16 i think i understand this one, so let me see if i can summarize 18:32:18 the change that's in place is that the root password is required, period. 18:32:26 no it isn't. 18:32:31 the root password *spoke* is required. 18:32:32 uh, I wrote the damn code 18:32:35 I'm not convinced that this is wise to be changing right now 18:32:39 adamw is right 18:32:40 you are not required to set a root password in it. 18:32:43 you are /required/ to put in a root password. 18:32:47 no you're not. 18:32:49 :) 18:32:53 at least, as of TC6. 18:33:01 * adamw runs a quick check with smoke12 18:33:01 TC6 is old :) 18:33:02 O_O 18:33:02 it sounds like you guys are talking about 2 different things 18:33:10 be5d6d0ab2d1f47151879b1b9529baf1d3e78098 18:33:11 jlk is talking about the patch covered by the bug 18:33:15 o_O 18:33:23 adamw is talking about current behavior 18:33:24 if this changed in smoke12 such that we're simply forcing the creation of a root password in all cases - back to f17 behaviour - then i agree this issue is obsolete 18:33:31 ah. 18:33:43 so let me see if i have this straight 18:34:08 right now we simply force everyone through the root spoke, but don't make any attempt to conditionally force them to actually set a password 18:34:25 the proposed 'fix' for this is simply to always force the creation of a root password, not to only do it when firstboot is not present or something 18:34:28 is that accurate jlk? 18:34:54 correct. The upstream fix is that root password spoke is required, and once in the spoke you're required to set a password 18:35:19 we've punted on any attempt to make that variable based on payload contents 18:35:22 why is it that this stuff changes every 2 weeks? 18:35:36 so we're effectively ditching the whole 'let's go with admin users by default' thing. 18:35:54 adamw: we're punting that problem to the post-install tools 18:36:12 which can disable the root account if so desired 18:36:15 jlk: are the post-install tools aware of this? 18:36:29 firstboot is being re-written by an anaconda dev, so I assume so 18:36:44 anyway. if anaconda team is of the opinion that forcing root passwords for f18 is the best option, i'm +1 nth, because it makes sense to change it pre-beta not post beta. 18:36:45 anyway this is the behaviour that is to be expected from now on if so -1 to nth and just close this bug 18:37:00 and it would be going back to f17 behaviour and it's probably the behaviour least likely to cause problems. 18:37:11 Viking-Ice: we have to accept it as NTH to take the change to 'always force a root password 18:37:12 ' 18:37:28 if we don't take it as NTH, we'd be saying 'keep the current behaviour where you have to go to the spoke but you aren't forced to set a password' 18:37:39 * Viking-Ice confused 18:37:48 +1 nth 18:38:03 so in stable anaconda right now, we force the user to go through the spoke, but they can set the password empty, disabling root account. 18:38:05 we're frozen. 18:38:05 * kparal notes it would be nice to have some plan in advance rather to change it all the time 18:38:13 but this behavior should not be changed once this is in 18:38:18 so technically, to take a change for this in the next anaconda build, we have to approve this bug as NTH. 18:38:20 kparal: we had a plan 18:38:20 this doesn't feel like something that should be dealt with using the blocker/nth process but I'm not -1 18:38:39 kparal: but gave up on that plan when it came time to implement it and we discovered all sorts of problems with the plan 18:38:43 if we reject this as NTH and anaconda team pushes an anaconda 18.22 which changes this behaviour, technically they're breaching how the freeze process is supposed to work. 18:38:44 so the plan has changed. 18:39:07 so i'm saying we should accept this as NTH so anaconda 18.22 can 'legally' change back to the old 'always require a root password' behaviour. 18:39:18 adamw: so how is that different from any other bug past freeze? 18:39:19 if anaconda has decided this is the way forward, +1 is logical 18:39:19 the plan is for everybody make the best out of the mess we currently are in 18:39:47 tflink: don't quite understand the context of the question. are you saying 'why should we break freeze for this'? 18:39:51 technically we would have to revert be5d6d0ab2d1f47151879b1b9529baf1d3e78098 or make a f18-beta branch that doesn't include be5d6d0ab2d1f47151879b1b9529baf1d3e78098 18:40:20 adamw: no, I'm asking how pushing a fix for this w/o an accepted NTH or blocker would make it differnt for any other patch? 18:40:39 but whatever, we still have a lot of NTH left to go through 18:40:48 tflink: eh? the policy is that anaconda doesn't change stuff post-freeze unless it's accepted as NTH or blocker 18:40:56 exactly 18:40:59 we're trying to stick to that 18:41:06 tflink: so as jlk says, if we reject this as NTH, anaconda would have to revert the commit that fixes this bug 18:41:12 which is why I'd like this to be NTH, so that we can include it in the beta. 18:41:16 right. 18:41:30 i feel like i understand this but i'm worried we're not explaining it well to anyone else. :) 18:41:32 before I start, I'm not disagreeing completely with NTH 18:41:56 I do dislike justifying NTH by "well, it's already been pushed ..." 18:42:03 oh, I'm not using that as justification 18:42:04 no, that's not what i'm saying. 18:42:05 sorry 18:42:12 I didn't mean to imply that 18:42:29 the justification is that anaconda team believes this is how f18 should be, so we should have it this way in beta, not change it between beta and final, or not change it at all. 18:42:38 I do genuinely think that this is something we should expose in beta if we can, but not delay the beta for it if we can't. 18:42:59 and also i think it's the safest way to go anyway. 18:43:12 remind me again why we entered freeze last week 18:43:14 it's what we've done for 17 releases and what clearly works: a root account with a password. 18:43:26 tflink: because fesco's a bunch of idiots? ;) 18:43:29 hah 18:43:32 my response too 18:43:39 "here, take this unicorn I just pulled out of my ass" 18:43:55 anyhow 18:44:11 tflink: i'm not that happy with how this keeps changing either. which ironically is kind of why i'm in favour of *this* change 18:44:27 because *this* change constitutes 'fine, we'll just go back to the known safe way of doing this and stop fiddling with it'. which i think is good. 18:44:41 just please nobody suggest that the spoke goes back to the main screen, ok? 18:44:45 heh. 18:45:02 proposed #agreed 869675 - AcceptedNTH - While not a blocker, allowing people to install with no available users is a bad idea and if this changes, it needs to be changed now. A tested fix would be considered past freeze. 18:45:09 ack 18:45:10 jlk: I just started the RFE bz :-D 18:45:16 ack 18:45:29 ack I'm just happy if some group does not start popping up *now* asking for this or any other installer change to be changed 18:45:32 ack 18:45:34 #agreed 869675 - AcceptedNTH - While not a blocker, allowing people to install with no available users is a bad idea and if this changes, it needs to be changed now. A tested fix would be considered past freeze. 18:45:44 #topic (869978) %packages --default doesn't install default system, but minimal one 18:45:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=869978 18:45:49 Viking-Ice: yeah, i have the big NO hammer ready for *any* further twiddles to this. 18:45:49 #info Proposed NTH, anaconda, ASSIGNED 18:46:25 yeah, this is all sorts of fun 18:46:40 * tflink notes that we have 15 minutes left until the end of our allotted 3 hours 18:46:41 something I was hoping to look into today 18:47:03 If I can fix it, and it's not invasive, I'd like this NTH 18:47:39 we have run across a few cases of people with %packages --default in their kickstart files, and it's a useful bit of feature to mirror the graphical installer 18:47:50 well arguably the default should be minimal 18:48:00 and Bill got it wrong 18:48:05 erm, that would make this bug only accidentally correct 18:48:34 and it would be broken for any 3rd party setup that has a different idea as to what's default. 18:48:47 if you think about it start with 0 ( minimal ) the alphabetically add numbers to the available DE's 18:49:08 ( or build on top of that 0 3rd party or not ) 18:49:13 Viking-Ice: the purpose of this bug is that it is a regression. if you want to propose some changes to --default, propose them separately 18:49:24 based on the documentation and on previous releases, the behaviour is clearly wrong. 18:49:50 i can see the +1 nth argument; there may be people with kickstarts they've been using for a while which use %packages --default . if you were just writing a kickstart, following the documentation, it seems like the kind of thing you'd do. 18:50:01 +1 nth 18:50:14 and if the change only affects kickstarts, which we haven't tested heavily and only guarantee one specific working case for, it's not really hugely dangerous 18:50:28 kparal, comps have been redesigned those documents are most likely wrong now anyhow 18:50:44 Viking-Ice: this is the kickstart documentation, not package group docs... 18:50:44 +1 nth 18:50:54 +1 nth 18:51:16 on top of that we have a *new* installer so this is the time to define and get the desired behavior for future release 18:51:23 it's interesting to me how we take NTH bugs without knowing what the fix is 18:51:35 and we reject other NTH when we know what the fix is 18:51:58 tflink: we don't have to take in all fixes agreed as NTH 18:52:11 nope we dont have to 18:52:12 tflink: NTH is about the bug, not necessarily about the fix 18:52:31 the developer has to make a judgment call on whether the fix is too invasive or not 18:52:51 proposed #agreed 869978 - AcceptedNTH - This is a regression in the behavior of previous versions and would be good to fix. A tested fix would be considered past freeze. 18:52:57 ack 18:53:06 ack 18:53:08 ack 18:53:18 ack 18:53:50 #agreed 869978 - AcceptedNTH - This is a regression in the behavior of previous versions and would be good to fix. A tested fix would be considered past freeze. 18:54:38 kparal: my issue is with our inconsistency - sometimes we say 'well, we don't have to take nth fixes' and other times we say "it's too close to X to take this; rejected nth" 18:55:00 8 minutes to 3 hour mark 18:55:07 one more bug or ? 18:55:09 is that inconsistent? 18:55:12 how many more do we have? 18:55:22 kparal: it's kind of fuzzy. 18:55:29 anyway, I really want to propose some changes to NTH process, hopefully I'll write it up 18:55:33 please do 18:55:34 9 proposed NTH 18:55:42 4 accepted blockers 18:55:42 it's still more or less the first draft i pulled out of my ass two years ago 18:55:55 i'm not convinced it's the best process possible :) 18:55:57 * kparal proposes to end the meeting 18:56:17 * tflink also thinks that calling them NTH is a horrible idea 18:56:22 are any more of those NTFs anaconda? 18:56:25 NTHs 18:56:31 can we get through all the anaconda NTHs? 18:56:47 we kinda need to do that so the anaconda team knows what to put in 18.22, which we want to spin today 18:56:51 We could go with the RHEL terminology and call them "exceptions" 18:56:53 jlk: 6 of the 9 are 18:57:03 I'm willing to power through them if y'all are 18:57:12 me too 18:57:21 same here 18:57:21 I'm gonna clock out and head home can rejoin once i'm there 18:57:29 thanks viking, sorry for keeping you up 18:57:40 at work more like it ;) 18:57:44 =) 18:58:09 I don't feel well, I think I'll just lurk 18:58:38 I just think that it's a misnomer. we know what NTH really means but when you tell someone unfamilar with the process that a bug was rejected as NTH, doesn't that sound like "your bug isn't a big enough problem for us to care about"? 18:58:42 but I go off in the weeds 18:59:01 #topic (870570) Anaconda needs to retry downloading the repo medata on a network config change 18:59:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=870570 18:59:07 #info Proposed NTH, anaconda, ASSIGNED 18:59:25 another on my hitlist for today 18:59:38 tflink: i think everyone pretty much agrees the NTH name is terrible, as is the -accepted alias. i'm happy if we improve 'em. 19:00:09 this one is pretty annoying any time you're switching around network install 19:00:21 as dennis said it can actually be pretty tough to figure out what to do to force it to 'reinit' 19:00:22 yeah, I agree. We should get this in if we can 19:00:47 otoh, it's pretty fuzzy and in a sensitive area 19:00:57 and isn't breaking anything critical for beta 19:01:13 yup, I promise to be careful :) 19:01:16 +1 nth here. (we don't need to take it if it blows up things?) 19:01:19 I'm ok with NTH but I would like to see the patch as an update.img before it's pushed, if possible and reasonable 19:01:26 yeah, i'm with tflink on that 19:01:39 comment in the bug to that effect and it shall be done 19:01:44 i think this will be less of a practical issue if we fix up all the network hub issues 19:01:56 because then people should usually arrive at the hub with a working network. we hope. 19:03:04 proposed #agreed 870570 - AcceptedNTH - This would allow for networking configuration changes during install configuration, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed. 19:03:11 ack 19:03:26 maybe 'eases' rather than 'would allow for' 19:03:35 you _can_ do it at present, it's just a pain and non-obvious 19:03:37 ack 19:04:03 proposed #agreed 870570 - AcceptedNTH - This makes networking configuration changes during install configuration easier and more obvious, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed. 19:04:05 ack 19:04:42 ack 19:04:46 sure ack 19:04:51 #agreed 870570 - AcceptedNTH - This makes networking configuration changes during install configuration easier and more obvious, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed. 19:05:00 #topic (871554) NFSISO installs fail to reboot: SystemError: (16, 'umount.nfs: /run/install/isodir: device is busy') 19:05:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=871554 19:05:05 #info Proposed NTH, anaconda, ASSIGNED 19:05:15 I'm... not sure this is still a bug. 19:05:22 I can't reproduce it with the current code I'm working on 19:05:38 note though, nfsiso is in pretty bad shape right now 19:05:38 punt and retest? 19:06:02 I forget, is nfsiso required for beta? 19:06:22 didn't we have a bug for this back in 17? 19:06:32 tflink: either NFS or NFSISO 19:06:32 i think was what we decided on 19:06:38 it's an either or 19:06:42 "The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options " 19:06:44 both required for Final 19:06:46 yeah, I couldn't remember what we decided for beta and if it's different for final 19:07:55 anyway, I think this does need a punt and re-test, because I think it'll be fixed by way of fixing other nfsiso issues 19:08:15 wait a sec, how did this get on the proposed NTH list 19:08:15 like the fact you couldn't even select an nfsiso repo until my fix from yesterday. 19:08:21 jlk proposed it. 19:08:24 oops :) 19:08:25 its RH only 19:08:26 +1 punt 19:08:30 it's a clone of an RH report. 19:08:38 cloned for fedora, though not really clearly stated. 19:08:39 oooh! 19:08:40 right 19:08:42 dur 19:08:56 I think I was using this bug as a catchall for the nfsiso issues I was chasing 19:08:59 it's also RH employee only and blocking rhel70rtt at present 19:09:08 oh hah, forgot to clear the flag 19:09:20 i think you need to Fedorize it a bit more :) 19:09:22 which explains how that tracking bug got pulled in and screwed up my entire blocker list last night 19:09:22 flag cleared. 19:09:27 anyway, aside from that, punt till it's clearer. 19:09:28 ah. 19:09:42 jlk: canada's off the hook, now we're blaming you. 19:09:49 I was wondering how that happened but it went away this morning 19:09:51 actually I take back my earlier statements 19:10:00 there were almost 100 proposed blockers last night :) 19:10:14 this is the bug I'm using to track NFSISO fixes 19:10:15 but I digress 19:10:17 there are a few of them 19:10:27 all sort of related to just "nfsiso is broken" 19:10:39 it would be nice to have tighter focus on that. 19:10:51 can you clarify the bug description and, if we take this as NTH, restrict it to critical fixes? 19:10:58 i.e. stuff needed to make nfsiso work 19:11:07 i'm +1 nth to 'nfsiso doesn't work', but with a tight focus. 19:11:09 that's what I'm doing, I could split out more bugs I suppose 19:11:17 what I know now: 19:11:18 how bout this 19:11:24 gimme 2 minutes and i shall transform the bug 19:11:29 1) inability to make use of nfsiso if chosen in gui spoke 19:12:04 2) inability to use nfsiso if set as a inst.repo= argument 19:12:25 (yes, there are two separate problems there) 19:12:29 okay 19:12:40 as this was filed from an inst.repo attempt, make it the bug for inst.repo nfsiso doesn't work? 19:12:47 sure 19:13:06 there are some other bugs, where if started from nfsiso, switching to nfs or a different nfsiso location may break 19:13:25 or if you've ever setup an nfsiso source switching to another nfs or nfsiso related source may break 19:13:33 but those can be punted to post-beta 19:13:45 and with 2)..the bug isn't just if you actually literally pass repo=nfsiso:blah ,right/ 19:13:46 ? 19:14:01 it's not that it works if you pass repo=nfs:blah , even if blah is an ISO? 19:14:12 it's the actual nfs iso function itself that doesn't work? 19:14:16 Ticket notification - f18betanicetohave: [Bug 871554] NFSISO installs fail to reboot: SystemError: (16, 'umount.nfs: /run/install/isodir: device is busy') 19:14:40 adamw: the actual function itself isn't working. We're failing to do the right thing with any found .iso in the mount path 19:14:44 okay 19:14:51 that's the easier of the fixes 19:15:09 so if we consider this bug to be 'you can't install via NFS ISO when passing inst.repo on the cmdline' i am +1 nth to that. 19:15:19 obviously it'd be nice to have that testable in beta. 19:15:37 i can edit the bug to reflect that as part of the secretaryization if we're all happy with the idea. 19:16:11 anyone else? 19:16:22 proposed #agreed 871554 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze. 19:16:59 ack 19:17:02 ack 19:17:12 ack 19:17:18 #agreed 871554 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze. 19:17:21 if we are splitting this though, I'd like to get an NTH on the split out bug for the second problem. 19:17:32 oh geez 19:17:37 I misread adamw's question 19:18:46 adamw: your question has mostly the same answer for problem 2, except that it's a problem with how the yumpayload object is initialized that breaks things, not with what we do with the .iso file 19:18:57 problem 1 is what we do with the iso file 19:20:39 jlk: that's fine, i just wanted to make sure it's not as simple a case as 'the workaround is just to pass repo=nfs not repo=nfsiso' 19:20:46 correct 19:20:49 jlk: i'll file a split out bug and nominate that for NTH 19:20:53 k 19:21:03 so right now we have accepted NTH for nfsiso-via-inst.repo-fails 19:21:06 we're still OK with the #agreed, though? 19:21:10 yeah 19:21:19 we do not have accepted NTH for nfsiso-via-interactive-fails, but i will split that out and propose it 19:21:31 i wasn't planning to file/propose anything further yet, we can sort that out later 19:21:33 is that plan ok? 19:21:52 ok 19:22:30 ok, i think we're good 19:22:41 #topic (871648) Cannot use nfsiso repo through graphical source picker 19:22:41 Ticket notification - f18betanicetohave: [Bug 871554] Cannot use an 'NFS ISO' repository (NFS share containing a Fedora ISO image) passed as inst.repo on cmdline 19:22:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=871648 19:22:41 #info Proposed NTH, anaconda, POST 19:23:02 hey look at that. 19:23:18 +1 :) 19:24:10 I guess I did split it out 19:24:17 clearly I was drunk last night 19:24:29 adamw: looks like you don't need to file a separate bug 19:25:19 er, no 19:25:25 that's the bug we just acked :) 19:25:37 i hacked it up as part of the secretaryization. 19:25:41 i am secretaryizing in realtime. 19:25:57 really? 19:26:05 Reported: 2012-10-30 19:52 EDT by Jesse Keating 19:26:08 adamw: this list was generated hours ago 19:26:09 in a few seconds we should see a notification for 871943 , which is the bug I just filed for the interactive case :) 19:26:13 ohh, sorry 19:26:23 i saw the 'Ticket notification' and thought we were talking about that 19:26:27 not the next bug on the list :) 19:26:27 oh 19:26:35 okay, i'll close the dupe i just filed, d'oh 19:26:56 sorry, I must have been drunk or something and couldn't remember what all I did here 19:27:07 but looks like I was trying to be a good boy and split out the bugs to separately propose them 19:27:11 yay you 19:27:14 sorry for confusion 19:27:18 pretty much the same as the last NTH? 19:27:40 proposed #agreed 871648 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze. 19:27:44 it kinda seems like we should take both, yeah 19:27:47 * adamw looks at the patch 19:28:05 ack 19:28:15 ack 19:28:21 this bug is actually the easier fix 19:28:28 https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001845.html for anyone interested 19:28:30 ack 19:28:42 though whenever i see anaconda code that mounts stuff, things start itching. 19:29:26 I will note that the patch is getting some discussion upstream, so the final version may be slightly different, but the concept is the same 19:29:59 #agreed 871648 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze. 19:30:06 #topic (869106) F18 anaconda chokes on wireless network names containing spaces 19:30:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=869106 19:30:12 #info Proposed NTH, anaconda, MODIFIED 19:31:11 +1 NTH 19:31:20 +1 for me, this is obviously gonna be a problem if your AP has a space in it. :) 19:31:41 that's probably not enough APs to block release, but seems polite to fix it. 19:32:22 would suck if hte dudes in "FBI Surveillance Van" weren't able to do an install! 19:32:34 hehe. 19:32:38 proposed #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze/ 19:32:43 proposed #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze. 19:32:45 * satellit that may be why my Apple Network xxxxxxx fails ! 19:32:45 ack 19:32:47 ack 19:32:51 satellit: probably, yeah. 19:33:31 moar ack? 19:33:53 ack (back from Board meeting) 19:33:53 #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze. 19:34:11 #topic (871132) Protected wifi connection not enabled after secrets are set, user has to re-select it 19:34:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=871132 19:34:16 #info Proposed NTH, anaconda, NEW 19:35:12 while we're making networking not suck, sure, i guess. 19:35:35 yeah, +1. We can let the anaconda dev team nack it for beta if the fix is too invasive 19:36:03 I could go either way on this one, to be honest 19:36:35 in strict NTHland it's obviously a pretty small fix, but for me the swaying factor is this whole area has been broken to hell anyway. 19:36:39 so cleaning it up seems a good thing. 19:36:49 it's not like this is known-solid code we're fiddling with. 19:37:07 how does that decrease the risk of taking a patch? 19:38:05 it decreases the comparative risk of taking a patch, as the risk isn't 'we could screw up this well-tested and known reliable codepath'... 19:38:23 these are just the bugs that emerged within about ten minutes of wifi being made not-utterly-broken 19:38:38 so it changes to 'we could screw up this codebase that might be just getting stable' 19:38:50 i guess. 19:39:27 proposed #agreed 871132 - AcceptedNTH - While not a big enough problem to block release, it is an annoyance and can't be fixed with an update. A tested fix would be considered past freeze. 19:39:58 ack, with caveat that we think this isn't a really important change and it should be merged only if we're really pretty confident in it. 19:40:07 i can note that in the bug. 19:40:07 ack 19:40:15 #agreed 871132 - AcceptedNTH - While not a big enough problem to block release, it is an annoyance and can't be fixed with an update. A tested fix would be considered past freeze. 19:40:23 OK, that's all of the anaconda proposed NTH 19:40:27 we have 4 more 19:40:34 I'd like to do the XFCE one 19:40:38 ok, sorry, I'm checking out. Have to have lunch with fam. 19:40:52 * nirik perks up 19:41:05 maybe firstboot 19:41:38 do we have enough people to do that? 19:41:45 after almost 4 hours? 19:42:03 * adamw is still here 19:42:05 * nirik is still around, but not sure how many others. 19:42:44 * Viking-Ice 1/3 in 1/3 cooking 1/3 watching the match against white Russia 19:42:48 the firstboot one of course gets less important if we're gonna force root password in all cases now... 19:43:13 so let's do the xfce one and be done for today? 19:43:26 #topic (870781) keyboard shortcuts patch got lost during Xfce 4.10 update 19:43:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=870781 19:43:26 #info Proposed NTH, libxfce4ui, ON_QA 19:43:29 well we've had firstboot 18.4/18.5 in the last bunch of TCs so we should probably just go ahead and ack it 19:43:36 18.4/18.5 probably has more testing than 18.3 now 19:43:47 +1 nth. 19:44:02 +1 if cwickert wants it. 19:44:07 * adamw trusts the wickert. 19:44:13 yeah, I'm ok with +1 since it's a regression 19:44:26 yeah, it would be... nice to have. 19:44:28 (ha) 19:44:38 hey, we should call the bugs that! 19:45:08 proposed #agreed 870781 - AcceptedNTH - This fixes a functionality regression in XFCE when compared to previous versions of Fedora. A tested fix would be considered after freeze. 19:45:54 ack/nak/patch? 19:47:06 ack 19:47:59 ack 19:48:25 #agreed 870781 - AcceptedNTH - This fixes a functionality regression in XFCE when compared to previous versions of Fedora. A tested fix would be considered after freeze. 19:48:29 #topic (856194) firstboot has to insist the first user is admin when root account is locked 19:48:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=856194 19:48:34 #info Proposed NTH, firstboot, ON_QA 19:49:25 proposed #agreed 856194 - AcceptedNTH - Allowing for an install with no admin or root users is not desirable and should probably be fixed. A tested fix would be considered past freeze. 19:49:29 ack/nak/patch? 19:49:34 ack 19:49:37 as i said, this kinda becomes a null issue if we take the change to force root pw, but in theory we ought to cover that case and we've been testing it forever 19:49:39 so ack 19:50:02 ack 19:50:10 #agreed 856194 - AcceptedNTH - Allowing for an install with no admin or root users is not desirable and should probably be fixed. A tested fix would be considered past freeze. 19:50:18 OK, any objections with being done for now? 19:50:35 we have 2 unreviewed proposed NTH and 4 accepted blockers 19:50:50 I imagine that a meeting tomorrow before go/no-go wouldn't hurt, either 19:50:52 nope 19:50:55 i'm fine 19:50:57 * nirik doesn't care either way 19:51:08 i'm not sure if we need a meeting before go/no-go. no-go is pretty freaking obvious. 19:51:24 but upgrade might be done by then 19:51:29 :-D 19:51:42 https://bugzilla.redhat.com/show_bug.cgi?id=871888 seems to have been added to the propsoed blocker list 19:51:47 we can just give them our answer now 19:51:55 jreznik, what's your take? 19:52:38 Viking-Ice: well we'll show up for the meeting of course. but i don't think we need a pre-meeting to agree our position. i can't see any position but no-go. 19:52:50 shall we do 871888 before we wrap up? 19:54:10 * adamw is -1 as kparal said it doesn't seem reproducible 19:54:10 probably not, but go/no-go time could be used 19:54:17 #topic (871888) AttributeError: 'YumPayload' object has no attribute '_yum' 19:54:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=871888 19:54:18 #info ProposedBlocker, anaconda, NEW 19:55:01 -1 19:55:20 -1, not reproducible (i actually was trying this at the same time as kparal and it didn't happen to me, so seems like a rare issue) 19:55:30 probably timing 19:56:11 proposed #agreed 871888 - RejectedBlocker - While severe, this doesn't seem to be happening often enough to justify blocking F18 beta. Please repropose if this starts happening more often. 19:56:14 or a bad mirror 19:56:23 would be nice to know what mirror/conditions. 19:56:24 ack 19:56:24 ack 19:56:25 but yeah. 19:56:26 ack 19:56:32 #agreed 871888 - RejectedBlocker - While severe, this doesn't seem to be happening often enough to justify blocking F18 beta. Please repropose if this starts happening more often. 19:56:35 nirik: that's probably in the logs 19:56:46 alrighty, time for: 19:56:55 #topic Open Floor 19:57:02 Anything else that needs to be brought up? 19:57:22 can't think of anything 19:57:26 it sounds like the plan is to use go/no-go time instead of a meeting continuation tomorrow? 19:58:01 * nirik can't find it, but ok. 19:58:07 oh, we were thinking about how to review the remaining nth? sorry, i was thinking we were talking about having a meeting to decide on whether we would vote go/no-go 19:58:25 i don't mind a short blocker/nth review continuation tomorrow, sorry if i confused that 19:58:43 ok, we can cover anything else that may come up before then too 19:59:04 #info the blocker review will continue tomorrow: 2012-11-01 @ 16:00 UTC 20:00:08 if there's nothing else ... 20:00:24 * tflink sets the fuse for [0,eleventymillion] minutes 20:01:02 Thanks for coming everyone! 20:01:08 * tflink will send out minutes shortly 20:01:12 #endmeeting