17:02:18 <adamw> #startmeeting Fedora 15 Blocker Review #4
17:02:18 <zodbot> Meeting started Fri May  6 17:02:18 2011 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:23 <adamw> i did. booyah.
17:02:27 <tflink> that works, too
17:02:29 <rbergeron> oh hey it's adamw who is rockin like dokken
17:02:49 <adamw> #meetingname f15-blocker-review
17:02:49 <zodbot> The meeting name has been set to 'f15-blocker-review'
17:03:20 <adamw> soo, jlaska is marrying paris hilton in vegas
17:03:23 <adamw> (but you didn't hear that from me)
17:03:31 <rbergeron> NO WAY
17:03:33 <rbergeron> zomg
17:03:34 <adamw> so i'll be running the meeting today; feel free to run for the lifeboats now
17:03:41 <adamw> #topic intro
17:03:43 <brunowolff> I hope he didn't sign a prenup.
17:04:05 <rbergeron> well.
17:04:06 <adamw> for anyone who's terminally bewildered and wondering what they're doing here, we will be reviewing the proposed and accepted blockers, and proposed nice-to-have bugs, for fedora 15 final
17:04:12 <rbergeron> I hope *she* didn't sign a prenup
17:04:16 <adamw> as per this list: https://fedoraproject.org/wiki/Current_Release_Blockers
17:04:55 <adamw> we will be following RIGOROUSLY the procedures outlined at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process : any dissent will be punished by replacing jlaska
17:04:56 * rbergeron grins
17:05:43 <adamw> does anyone want to secretary-ize?
17:06:12 <tflink> I can
17:06:15 <adamw> cool
17:06:22 <adamw> #info tflink will be our secretary for this week
17:06:32 <adamw> so, starting with the proposed blockers
17:06:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696278
17:06:41 <buggbot> Bug 696278: high, unspecified, ---, dcbw, NEW, The system network services are not compatible with this version.
17:07:07 <adamw> so this is one that's been coming up for a couple of meetings
17:07:34 <adamw> jlaska has done some good detective work and figured out that all reporters seem to have actually hit https://bugzilla.redhat.com/show_bug.cgi?id=678553
17:07:36 <buggbot> Bug 678553: high, unspecified, ---, dcbw, CLOSED ERRATA, NetworkManager doesn't start successfully on bootup after upgrade from F14 -> F15
17:07:41 <adamw> which was a known bug with NM on upgrade that was fixed
17:08:15 <adamw> i'm happy to go with him on this one, and close this as a dupe of that
17:08:24 <tflink> +1
17:09:16 <brunowolff> +1
17:09:20 <adamw> ok
17:09:58 <adamw> #agreed 696278 tracks down to a dupe of 678553, which was indeed a blocker bug but was fixed; we see no reports of anyone doing an upgrade with an NM package fixed wrt 678553 and still having problems. closing it as a dupe.
17:10:07 <adamw> tflink, go ahead and close it off :)
17:10:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702261
17:10:22 <buggbot> Bug 702261: unspecified, unspecified, ---, anaconda-maint-list, NEW, network service not running on minimal install
17:10:31 <tflink> adamw: done
17:11:34 <adamw> so, if you do a minimal install, you get no network till you bring up the network service manually
17:11:35 <dgilmore> this has long been the case
17:11:39 <adamw> as noted in later comments, this isn't anything new
17:11:47 <dgilmore> -1 blocker
17:11:53 <adamw> there are theoretical possible improvements here, but we've been shipping this way for a while and nothing's exploded
17:11:53 <dgilmore> +1 nth
17:11:54 <clumens> yeah, tough for those people.
17:12:08 <adamw> i'm -1 to both
17:12:19 <bcl> -1 minimal is, well, minimal.
17:12:37 <adamw> since any fix for this is going to involve poking anaconda, and we really don't want to do that at this stage if it can be avoided.
17:12:46 <tflink> yeah, this can be an annoyance but nothing new or huge
17:12:56 <adamw> tflink: what's your vote?
17:12:58 <tflink> -1, -1
17:13:00 <adamw> ok
17:13:15 <tflink> +1 for doing it at some point, though :)
17:13:35 <adamw> #agreed 702261 rejectedblocker, rejectednth: this is not a behavior change and does not impact any criteria, we have shipped this way for a while, impact is not horrible
17:13:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702603
17:13:52 <buggbot> Bug 702603: medium, medium, ---, anaconda-maint-list, MODIFIED, FormatCreateError: ('format failed: 1', '/dev/mapper/vg_kralik-LogVol01')
17:14:25 <adamw> do you still have to use a special parameter to get btrfs as an option?
17:14:28 <adamw> or is it in there by default now?
17:14:44 <clumens> it's available without using a cmdline option
17:14:48 <clumens> but it is not the default
17:14:56 <adamw> +1 blocker, then
17:15:12 <adamw> the criteria requires all filesystems offered by default to work
17:15:22 <adamw> "The installer must be able to create and install to any workable partition
17:15:23 <adamw> layout using any file system offered in a default installer configuration"
17:15:37 <adamw> and hey, we have a fix already!
17:15:49 <tflink> one could argue that 100MB partitions aren't a workable partition
17:15:58 <tflink> workable layout, rather
17:16:14 <adamw> one could. but hey, let's just take it.
17:16:33 <tflink> but I'm ok with blocker on this one
17:16:39 <tflink> +1 blocker
17:16:46 <bcl> +1 fix is simple
17:16:48 <brunowolff> I'd be inclined to go with -1 blocker +1 NTH.
17:17:15 <adamw> we have no other anaconda blockers that i'm aware of
17:17:29 <adamw> dgilmore: any you're aware of?
17:17:36 <adamw> clumens: or you?
17:17:47 <clumens> nope
17:17:54 <adamw> so...if we declare this NTH, it doesn't get fixed
17:17:56 <dgilmore> adamw: none im aware of
17:17:59 <adamw> unless we come up with some more blockers
17:18:19 <brunowolff> The freeze isn't for a few days yet.
17:18:26 <adamw> oh, true
17:19:04 <tflink> would we have enough time to get it tested and in stable, though?
17:19:04 <brunowolff> And NTH also allows bugs to be accepted after freeze, we just won't do a new RC for them.
17:19:05 <dgilmore> freeze is monday
17:19:17 <dgilmore> im +1 nth
17:19:18 <adamw> brunowolff: true
17:19:21 <dgilmore> -1 blocker
17:19:44 <adamw> tflink: we're going to have to do rc1 anyway, we don't ship tcs
17:19:51 <adamw> tflink: and all accepted blockers have to be fixed for rc1
17:19:56 <adamw> so this wouldn't affect the test schedule really
17:20:11 <adamw> it would have to get fixed prior to rc1, and we'd do our testing on rc1.
17:20:18 <tflink> I was more wondering if we had to get it done before the freeze
17:20:27 <adamw> so, right now we have 3 votes for blocker, 2 votes against blocker
17:20:33 <tflink> wondering about timing if we had to get it done before the freeze, rather
17:20:59 <adamw> tflink: bruno's right, actually, if it's declared nth they can still rebuild anaconda and submit it during freeze if they like, so it doesn't matter from that pov.
17:21:06 * vhumpa lurking
17:21:11 <adamw> hey vhumpa
17:21:30 * rbergeron nods
17:21:34 <adamw> let's just go with the votes we have and call it a blocker, we're wasting time...
17:22:18 <adamw> #agreed 702603 acceptedblocker (on a split vote) under 'any workable layout' criterion
17:22:36 <adamw> #action anaconda team to submit a new build with the fix
17:22:52 <clumens> that's my plan for today.
17:23:16 <adamw> yay clumens
17:23:17 <adamw> okay
17:23:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702003
17:23:20 <buggbot> Bug 702003: unspecified, urgent, ---, notting, NEW, chkconfig --level N servicename returns wrong information
17:24:04 * adamw reads
17:24:59 <adamw> so...looks like simo and jlaska kind of agree this isn't a blocker
17:25:08 <adamw> and i can't find any major impact or criteria breakage here
17:25:11 <adamw> does anyone see anything?
17:25:32 <tflink> closest I can find: Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention)
17:25:44 <fenrus02> chkconfig should be just passing through to sysemctl
17:25:45 <adamw> i can't see how it would hit that
17:26:16 <tflink> I suppose it depends on reading, I see this as potentially breaking kickstart scripts
17:26:23 <brunowolff> I think it would be a reason NTH, since the output is confusing.
17:26:25 <tflink> not with UI prompts, though
17:26:31 <brunowolff> reasonable
17:26:51 <fenrus02> tflink, chkconfig --level 3 servicename on should still work in a ks, i think it does
17:27:03 <tflink> the only reason I can think of for making this NTH is that it wouldn't be easily fixed with an update
17:27:04 <adamw> yeah, i'm not sure what this would break in a ks
17:27:17 <adamw> well, jlaska says it can in his last comment
17:27:33 <brunowolff> I think the negative systemd PR wouldn't be too nice.
17:27:55 <tflink> I've done that before in kickstarts
17:28:01 <tflink> not recently, though
17:28:12 <fenrus02> fedora doesnt define runlevel 2,4 anyhow, so that's end-user defined.
17:28:23 <adamw> tflink: done what?
17:28:35 <tflink> used chkconfig --level in ks
17:28:51 <fenrus02> tflink, i've used it in %post for f14 it certainly works there.  i believe it works in f15 but not tested from %post
17:29:02 <dgilmore> im -1 blocker and -1 nth
17:29:51 * adamw notes comment #11
17:29:52 <adamw> "The simplest solution is likely to ship either only a sysv service file or a
17:29:53 <adamw> systemd service file in a pacakge, not both - this is likely the way the
17:29:53 <adamw> packaging guidelines will go."
17:30:04 <adamw> seems to imply that this only affects things which have both a systemd and a sysv service file?
17:30:28 <adamw> which is indeed the case for ntpd
17:30:36 <adamw> it has /etc/rc.d/init.d/ntpd and /lib/systemd/system/ntpd.service
17:31:05 <fenrus02> oh.  that might explain my 6min hang on bootup issue.
17:31:26 <brunowolff> In that case it's less of an issue and I think probably doesn't warrant NTH.
17:31:28 <adamw> so...yeah, i'm -1/-1
17:31:49 <tflink> eh, I'm thinking -1 blocker on this though. straightforward workaround, not clear violation of criteria, not worth blocking for since there doesn't seem to be a proposed fix yet
17:32:13 <tflink> +0 NTH
17:32:14 <adamw> okay, i think we have consensus
17:33:04 <adamw> #agreed 702003 rejectedblocker rejectednth: only affects services with both systemd and sysv definitions, does not clearly hit any criteria, and doesn't seem to have a significant enough impact for nth. there are workarounds for scripts that use this functionality.
17:33:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=698654
17:33:22 <buggbot> Bug 698654: unspecified, unspecified, ---, notting, NEW, fc14 to fc15 upgrade changes default init level
17:34:14 <adamw> so...this one's clear enough, though jlaska says he didn't hit it on a preupgrade. on the one hand it seems to hit the criterion, on the other it's obviously easy to work around.
17:34:26 <adamw> and we don't support upgrading with yum, really.
17:35:34 <adamw> i guess i'd kinda like to do a specific test using a supported upgrade method (dvd or preupgrade) and see if it hits this...otherwise i'm probably +1 nth for this since it can't be fixed with an update...
17:35:37 <adamw> anyone else?
17:35:47 <brunowolff> I don't believe distro-sync is supported way of upgrading.
17:36:02 <tflink> -1 blocker since it doesn't seem to affect preupgrade/DVD
17:36:04 <adamw> well, i guess it can be fixed with an update, actually, but wouldn't help people upgrading via dvd, only via net install / preupgrade.
17:36:04 <fenrus02> it happens to work, but not any way supported
17:36:17 <fenrus02> dvd/preupgrade are the only supported methods.
17:36:23 <tflink> couldn't this be fixed with an update since it's a yum upgrade?
17:36:23 <adamw> brunowolff: fenrus02: right, that's the status: we make a best effort but it's explicitly not 'supported'
17:36:29 <adamw> tflink: if it only affects yum, yeah
17:36:45 <adamw> so...i change to -1/-1 unless it affects dvd-based upgrades
17:36:59 <bcl> -1
17:37:02 <adamw> shall we agree on -1/-1, re-propose if testing shows it hits a dvd upgrade?
17:37:14 <tflink> not a whole lot of feedback, but jlaska notes that he didn't hit it with preupgrade
17:37:17 <dgilmore> im +1 to it being a blocker
17:37:17 <tflink> adamw: +1
17:37:25 <dgilmore> though its simple to work around
17:37:28 <tflink> err, +1 to your proposal
17:37:55 <dgilmore> adamw: i dont think it matters if it hits dvd or not
17:38:16 <adamw> dgilmore: well, it does for two reasons: we don't support upgrading via yum, and if you're upgrading via yum, you will pull in a post-release update that fixes this
17:38:33 <adamw> (assuming there is one)
17:38:59 <adamw> the criterion actually excludes yum upgrades in the way it's written (that was intentional) - it specifies using preupgrade, or the installer
17:39:39 <dgilmore> adamw: its listed as a supported method of upgrading last i looked
17:39:48 <adamw> dgilmore: really? where's that?
17:40:13 <adamw> dgilmore: http://fedoraproject.org/wiki/YumUpgradeFaq
17:40:20 <adamw> "Unofficial Procedure
17:40:21 <adamw> Although upgrades with yum do work, they are not explicitly tested as part of the release process by the Fedora QA and are not documented in the Fedora installation guide. If you are not prepared to resolve issues on your own if things break, you should probably use the recommended installation methods instead."
17:40:54 <adamw> and http://fedoraproject.org/wiki/Upgrading says "Upgrading directly from one release to the next using yum is not a officially supported method, but works for many users"
17:41:09 <dgilmore> i cant access the wiki right now for some reason
17:41:10 <adamw> so...it seems like our story is pretty consistent =)
17:41:29 <dgilmore> but last i knew it was supported. its the way ive done it forever
17:41:43 <dgilmore> anyways looks like im outvoted regardless
17:41:50 <brunowolff> And as someone who has been doing yum upgrades for several releases, it's pretty normal for there to be issues. Especially if you have a lot install or have rpmfusion stuff installed.
17:41:53 <fenrus02> dgilmore, i have too, but i always knew it was not supported.
17:41:57 <adamw> it's 'supported' in the sense that yum implements it and it generally more-or-less works, but it's not supported in the senses above (we don't formally test it and we don't block releases for it)
17:42:12 * nirik notes it's gotten easier with distro-sync, but yes.
17:42:32 <dgilmore> adamw: its pretty rediculous if we dont officially support it. since its whats used by anaconda
17:42:34 <adamw> dgilmore: i always figure it's best if we can all be on the same page though :)
17:42:53 <dgilmore> adamw: well AFAIK its a supported method
17:43:02 <adamw> i can't find anything that says that
17:43:04 <dgilmore> but i cant access the wiki to confirm or deny
17:43:17 <adamw> those wiki links are the relevant pages afaik, and i copy/pasted straight from them
17:43:17 <brunowolff> It would work better if people did a better job of using obsoletes, but orphans or dependencies that are broken in stuff not on the install disk still cause issues.
17:43:38 <fenrus02> orphans can be caused by a maintainer dropping the package, with no replacement too.
17:43:38 <adamw> (and no, i didn't edit them before i copy/pasted :>)
17:43:45 <adamw> anyway, let's go with the votes
17:44:50 <adamw> #agreed 698654 for now rejectedblocker rejectednth on the basis that it only affects yum upgrades, which are not supported - also, this can be fixed with a post-release update for the yum case, as yum implies the use of an up-to-date repo. we will ask reporter / jlaska to re-test with preupgrade or dvd upgrade and confirm whether this affects those cases
17:45:27 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701648
17:45:28 <buggbot> Bug 701648: unspecified, unspecified, ---, mgracik, ON_QA, firstboot-text.service doesn't honor "console=ttyS0" and instead displays on tty0, preventing serial login
17:46:05 <adamw> seems pretty straightforward to me based on jlaska comments, +1 blocker
17:46:28 <tflink> agreed, +1 blocker
17:46:35 <tflink> and there is a fix available
17:46:44 <dgilmore> +1 to blocker
17:47:26 <vhumpa> Looks like a blocker to me
17:47:41 <adamw> #agreed 701648 acceptedblocker per criteria cited by jlaska, fix is in
17:47:58 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=690873
17:48:00 <buggbot> Bug 690873: high, unspecified, ---, jmccann, NEW, gdm hangs and uses 100% CPU
17:48:55 <adamw> so, this is obviously a bad bug, i'm having trouble parsing the exact cases in which it occurs
17:49:02 * adamw pings halfline
17:49:34 <adamw> anyone have a good handle on this one?
17:50:57 <vhumpa> Seems like comments 2 and 5 tell the case
17:51:02 <tflink> yeah, its not clear on whether its just network logins or not
17:51:06 <adamw> well everyone in the report seems to be doing something a bit different
17:51:15 <adamw> and it's not entirely clearwhether they're all actually hitting the same bug...
17:51:23 <brunowolff> I'd be +1 blocker. 678236 is only NTH, so reverting accountservice seems to be a possible solution.
17:51:44 <adamw> well, i'd hate to lose that fix.
17:51:57 <adamw> i kinda would like more certain diagnosis before voting on this one...
17:52:05 <tflink> same here, very visable NTH
17:52:34 <tflink> request for more info and re-visit later?
17:52:43 <tflink> not sure when later would be, though
17:52:45 <adamw> halfline isn't replying to ping
17:52:47 <adamw> point
17:53:09 <adamw> so...reading jan horak's comments it seems like this happens when a user tries to log in for the first time, and not after that...
17:53:43 <tflink> yeah, but thats for local. not sure if it applies to network login too
17:53:48 <adamw> yeah
17:53:54 <tflink> and it sounds like that one was after upgrade
17:54:00 <adamw> we can follow up in the bug, i guess
17:54:05 <adamw> hey mcepl
17:54:14 <mcepl> hey
17:54:25 <brunowolff> And if it happens on live images, it's an ongoing issue.
17:54:26 <mcepl> just was looking for you
17:54:31 <adamw> does anyone want to vote one way or the other for sure yet? aside from bruno?
17:54:39 <adamw> mcepl: we're in the blocker meeting, so...pm?
17:55:12 <tflink> I'd rather see more info on impact and how it was hit
17:55:45 <adamw> okay
17:56:23 <adamw> propose agreed need more info on exact impact of 690873 to determine blocker status, we will ask for more info in the bug report, and follow up with evaluation via the report
17:56:53 <brunowolff> +1
17:56:57 <tflink> +1
17:57:18 <tflink> can you do a network login from a livecd?
17:57:45 <adamw> #agreed need more info on exact impact of 690873 to determine blocker status, we will ask for more info in the bug report, and follow up with evaluation via the report
17:57:48 <mcepl> adamw: ping me when you'll be ready
17:58:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=688277
17:58:02 <buggbot> Bug 688277: unspecified, unspecified, ---, bcl, MODIFIED, /etc/mtab not a symlink on livecd
17:58:06 <brunowolff> I was thinking if it hit the first login, you'd see it every time you rebooted.
17:58:26 <adamw> brunowolff: not sure if it's 'first per boot' or 'first ever'
17:58:27 <tflink> it doesn't seem to hit autologin, though
17:58:34 <adamw> anyway, moving on!
17:58:52 <brunowolff> live images don't normally save state.
17:59:08 <bcl> +1 :) Talked to lennart and w/o this mount may not show things correctly. Patch is simple and I've tested on a respin of F15.
17:59:29 <adamw> +1 nth
17:59:41 <adamw> can't really call it a blocker, but let's fix it!
18:00:00 <adamw> this is just a commit to spin-kickstarts to fix, right?
18:00:06 <tflink> yeah, this is a PITA for boxgrinder (unless they found a workaround)
18:00:13 <adamw> or is it livecd-creator itself?
18:00:25 <bcl> livecd-creator
18:00:28 <adamw> ah, k
18:00:33 <adamw> so we need to push a package, but still, lots of time.
18:00:51 <bcl> yeah, build, then rel-eng needs to start using it.
18:01:03 <bcl> single change from the current version though.
18:01:31 <tflink> +1 NTH
18:01:42 <brunowolff> +1 NTH
18:01:50 * halfline looks up
18:02:09 <adamw> halfline: ooh, hey. let's cycle back to the gdm bug after this one
18:02:14 * tflink needs to read more quickly or wait until talking, this is not quite the same issue that F15 was having in boxgrinder
18:02:31 <adamw> #agreed 688277 rejectedblocker, acceptednth - inaccurate mount output doesn't hit any criteria, but it's obviously something we should do right
18:02:40 <bcl> cool.
18:02:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=690873 redux
18:02:47 <buggbot> Bug 690873: high, unspecified, ---, jmccann, NEW, gdm hangs and uses 100% CPU
18:03:12 <adamw> halfline: so, we were kinda unsure on this one as it's tough to understand the exact impact and trigger from the report
18:03:20 <adamw> halfline: do you have any insight into this yet? have you been able to reproduce?
18:04:40 <halfline> adamw: honestly i sawthe bug go by but then it slipped my mind so i haven't looked into it at all
18:04:55 <halfline> it definitely seems blocker-worthy though
18:05:02 <adamw> okay...well, we're definitely worried about it, so if you could stick it at the top of your list to poke at that'd be great
18:05:08 <halfline> yup
18:05:14 <adamw> we kinda feel like that too but we didn't want to vote until we have a clearer understanding of it
18:05:15 <adamw> thanks!
18:07:14 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701999
18:07:15 <buggbot> Bug 701999: unspecified, unspecified, ---, psabata, ASSIGNED, Shouldn't start by default
18:08:28 <adamw> so...looks like this is clearly not a blocker, we might like to make it nth but it seems like it'd take invasive anaconda changes to fix
18:08:33 <adamw> does that sound about right, clumens?
18:09:57 <adamw> or bcl
18:10:19 * bcl looks
18:10:22 <brunowolff> For live images you can have it start on the live image using the special livesys service.
18:10:50 <brunowolff> If you do it that way, then it wouldn't be started by default on the installed systems. (Assuming that the default was
18:10:55 * tflink is having a hard time envisioning a situation where you'd want FCoE on a live system
18:10:59 <brunowolff> not to start the service.)
18:11:04 <Venemo> hi
18:11:06 <bcl> anaconda isn't involved. the package should decide.
18:11:18 <clumens> sorry, i'm off in rhel land right now
18:11:31 <bcl> nice clear title as well...
18:11:43 <adamw> brunowolff: that sounds interesting
18:11:46 <brunowolff> The only thing that seemed moderately bad was the report the service was consuming 10% cpu.
18:12:17 <adamw> brunowolff: but...it seems like lldpad sets the service to run when the package is installed and that's the way they want it to be
18:12:28 <adamw> so if we include the package on the live image we're kind of stuck with it running there.
18:12:38 <adamw> i'm just getting a 'not much we can do' vibe from this one...
18:13:39 <brunowolff> What does the FESCO policy on services that start by default say about this?
18:14:07 <adamw> well, afaict it's not a server process so that's not really relevant
18:14:12 <adamw> there's no security exposure issue is there?
18:14:24 <brunowolff> Not out of the ordinary.
18:14:42 <brunowolff> I am thinking the live image could still work around this.
18:15:17 <tflink> if I'm reading this right, wouldn't FCoE installs be broken if the default startup behavior of this was changed?
18:15:25 <adamw> propose agreed 701999 rejectedblocker, does not hit any criteria. for now, rejectednth as there's no clear path to fixing this in a minimum-impact way in time for f15; we will ask bastien to re-propose if he has a workable proposal
18:15:33 <brunowolff> It is normally against live image policy to do that, but we could make an exception.
18:15:38 <adamw> tflink: that seems to be the problem with just doing systemd activation, yeah
18:15:38 <dgilmore> tflink: no, the idea is that its only run when needed
18:15:52 <dgilmore> so the real fix might not exist yet
18:16:16 <adamw> i'm not sure we'd want to land systemd activation support in something like this right before release and say 'well hey, fixed it'
18:16:21 <adamw> seems like lots of potential for breakage there :)
18:16:27 <dgilmore> i think id like to have it proposed as a nice to have thing fixed for f16
18:16:32 <dgilmore> same with iscsi
18:16:34 <tflink> dgilmore: ideally, yes. I'm reading comment 5
18:16:44 <tflink> where anaconda can't turn on/off services
18:16:51 <tflink> only install packages right now
18:17:13 <tflink> so, if it wasn't enabled by default, anaconda can't turn it on and a FCoE install would be broken on firstboot
18:17:15 <clumens> anaconda knows how to enable/disable services based upon storage technology.
18:18:24 <adamw> does anyone have a clear plan that would fix this with no regressions by monday?
18:18:30 <dgilmore> no
18:18:31 * adamw trying to simplify :)
18:18:37 <dgilmore> so lets leave it as is
18:18:48 <brunowolff> I don't see a low risk way to do that.
18:18:51 <adamw> so, votes on my proposal of 3 minutes ago?
18:19:04 <brunowolff> +1
18:19:14 <dgilmore> adamw: +!
18:19:15 <dgilmore> 1
18:19:27 <tflink> +1
18:19:39 <adamw> #agreed 701999 rejectedblocker, does not hit any criteria. for now, rejectednth as there's no clear path to fixing this in a minimum-impact way in time for f15; we will ask bastien to re-propose if he has a workable proposal
18:20:09 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701622
18:20:10 <buggbot> Bug 701622: unspecified, unspecified, ---, mgracik, ON_QA, libproxy.so.1: cannot open shared object file: No such file or directory
18:21:28 <adamw> "looks bad" doesn't really cut it as a blocker for me, but +1 nth
18:21:54 <adamw> i'd be +1 blocker if there was some demonstrated practical impact beyond an error message - if someone showed proxy doesn't work or something. but hey, the fix is in already, just needs karma
18:21:59 <brunowolff> +1 nth unless we find out what ends up not working because of this.
18:24:26 <dgilmore> ill be using the updated lorax to compose rc1 regardless of if its in stable or not, or accepted as a nth or blocker
18:24:49 <dgilmore> so +1 to blocker and +1 to nth
18:25:13 <adamw> propose agreed 701622 rejectedblocker as no practical impact demonstrated, acceptednth to fix the error message and as fix is safe and simple
18:25:36 <dgilmore> sure
18:26:03 <tflink> would this affect virt installs?
18:26:03 <adamw> #agreed 701622 rejectedblocker as no practical impact demonstrated, acceptednth to fix the error message and as fix is safe and simple
18:26:23 <tflink> or do they use some other form of VNC connection?
18:26:30 <adamw> tflink: i think it affects all installs, as it's just a missing lib in the ramdisk, but we aren't clear what it actually causes. i don't think it's vnc specific
18:26:39 <adamw> jlaska just noticed it there as you're looking at a console when it happens, i think
18:26:56 <tflink> ok
18:27:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699198
18:27:20 <buggbot> Bug 699198: unspecified, unspecified, ---, theinric, ASSIGNED, rsyslogd not enabled after upgrade -- no logging in /var/log/messages
18:28:09 <adamw> so, looks like there's problems with rsyslog package's code for handling the upgrade to systemd
18:28:19 <adamw> which results in the service being disabled when you upgrade
18:28:43 <dgilmore> -1 blocker +1 nth
18:28:58 <dgilmore> it can be worked around
18:29:11 <dgilmore> should be documented though
18:29:42 <adamw> yeah, that's what i was thinking, there's a simple workaround (turn it on manually)
18:29:45 <adamw> but we should fix it if we acn
18:29:57 <adamw> i wonder if it's because the scriptlet in question uses chkconfig --level :D
18:30:34 <tflink> that would be kind of funny
18:30:36 <brunowolff> -1 blocker +1 nth
18:30:46 <tflink> -1 blocker, +1 nth
18:31:48 <adamw> #agreed 699198 rejectedblocker as there's a simple workaround (enable it) which can be clearly documented. acceptednth
18:32:25 <adamw> okay, last proposed blocker
18:32:27 <adamw> #topic
18:32:30 <adamw> #undo
18:32:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1758f6ec>
18:32:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702650
18:32:34 <buggbot> Bug 702650: unspecified, unspecified, ---, rstrode, NEW, Concurrency problem when unlocking partition
18:33:13 <adamw> this seems pretty icky
18:33:46 <adamw> halfline: it's another one for you - have you seen this one?
18:36:25 <adamw> guess he's off being jlaska's best man
18:36:36 <adamw> so...the impact is bad, but this looks kinda corner case-y
18:36:46 <rbergeron> lol
18:36:47 <adamw> it's not a common setup (not what you get if you just hit 'encrypt system')
18:36:49 <tflink> is this the same issue we saw before where there was timeout on the LUKS pw
18:36:56 <tflink> part of it, at least
18:37:06 <brunowolff> I have encrypted partitions and haven't seen a lockout like that for a while now. I sometimes don't see the passphrase
18:37:09 <adamw> well, that's probably why he gets dumped to rescue mode at the end, but not the cause of the main issue
18:37:16 <adamw> i wouldn't think anyway
18:37:45 <brunowolff> handed off between the early boot and the later boot (after the / pivot), but I can enter the passphrase again and things work.
18:38:04 <tflink> adamw: yeah, thats the part I was referring to
18:38:12 <Venemo> is it a known bug that it's not possible to create an ad-hoc network on Gnome 3?
18:40:20 <tflink> hmm, that is a bit of an odd disk layout
18:40:38 <dgilmore> it seems like a odd disk layout
18:41:05 <vhumpa> Venemo: I'd say that is a feature not yet done issue more than a bug
18:41:08 <adamw> yeah, so corner case-y
18:41:35 <adamw> it's one of those where i'd like the maintainer to know what was going wrong so we'd know how many cases it's likely to hit...
18:42:09 <tflink> in this case, it doesn't sounds like we're 100% clear on which package is causing this
18:42:12 <adamw> also we could ask if booting without plymouth works as a workaround
18:42:35 <adamw> i think we may have to punt for more data on this
18:43:14 <dgilmore> adamw: agreed
18:43:26 <brunowolff> The real problem may not be directly related to encryption.
18:43:40 <tflink> yeah, if I had to vote now, I'd probably be -1 blocker, +1 NTH but more information would be preferred since we don't know the cause or the potential side-effects
18:43:51 <brunowolff> Normally the system will complete booting after the timeout if the partition isn't critical to boot.
18:44:19 <tflink> point. /opt is the only thing that is encrypted
18:44:30 <adamw> propose agreed 702650 unable to determine status with current data: impact is bad, but only one specific and quite odd layout is known to be affected, others using encrypted partitions do not report seeing the same problem. also need to know if booting without plymouth or without rhgb quiet acts as a workaround. if halfline can figure out the bug that may help assess impact
18:44:38 <adamw> brunowolff: yeah
18:44:53 <tflink> ack
18:44:58 <brunowolff> +1
18:45:05 <adamw> so another data point - ask him to recreate the config from scratch and see if it reproduces the bug...
18:45:13 <adamw> #agreed 702650 unable to determine status with current data: impact is bad, but only one specific and quite odd layout is known to be affected, others using encrypted partitions do not report seeing the same problem. also need to know if booting without plymouth or without rhgb quiet acts as a workaround. if halfline can figure out the bug that may help assess impact
18:45:32 <adamw> okay, that's all the proposed blockers
18:45:36 <adamw> we have four accepted blockers to check in on
18:45:43 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696320
18:45:44 <buggbot> Bug 696320: unspecified, unspecified, ---, mgracik, ON_QA, After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console
18:46:11 <adamw> so we have an update in for this, just waiting on testing from jlaska
18:46:15 <adamw> don't see any other action required here
18:46:58 <adamw> #action jlaska to test latest firstboot update for 696320
18:47:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684846
18:47:11 <buggbot> Bug 684846: unspecified, unspecified, ---, tbzatek, MODIFIED, selinux denial prevents dbus activation of gnome-keyring-daemon
18:47:36 <adamw> we can actually close this one - the selinux-policy that fixes it has gone stable
18:47:42 <adamw> i tested it too, so we have a few confirmations
18:47:59 <adamw> #agreed 684846 can be closed, fixed selinux-policy has gone stable
18:48:40 * halfline looks up
18:49:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702650 redux
18:49:14 <buggbot> Bug 702650: unspecified, unspecified, ---, rstrode, NEW, Concurrency problem when unlocking partition
18:49:19 <adamw> ...aaand back to another halfline special =)
18:49:31 <adamw> halfline: kinda the same story here, we needs the datas
18:49:41 <adamw> have you looked into this one at all?
18:50:50 <halfline> adamw: no, looking into it now, i'll update the bug with my thoughts on it after i've given it a look through
18:51:21 <adamw> okay, thanks
18:51:22 <halfline> i figured out the other bug btw, just gotta do a build
18:51:28 <adamw> awesome, fast work!
18:51:35 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699905
18:51:36 <buggbot> Bug 699905: unspecified, unspecified, ---, ajax, MODIFIED, Mesa rebuild for fixed LLVM 2.8
18:51:52 <tflink> new build up for testing
18:52:02 <tflink> move to on_qa?
18:52:23 <adamw> oop, i skipped one, will come back to it...
18:52:42 <adamw> tflink: no, that happens automatically once it actually makes it to mirrors
18:52:52 <adamw> ajax obviously read up ahead of time and got to this =)
18:53:00 <adamw> so, no action needed here besides testing the package when it lands
18:53:13 <tflink> ok, didn't realize that happend automatically
18:55:15 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697834
18:55:17 <buggbot> Bug 697834: unspecified, unspecified, ---, rstrode, NEW, Other menu appears in default installation
18:56:12 <adamw> so...this one's kind of stuck. desktop team don't want to change anything.
18:56:13 <tflink> ATM, I think we leave this as is unless there's been a request to change the release requirements
18:56:47 <adamw> tflink: it's kind of the other way around; if we want to release without fixing this, we have to change the criteria...
18:56:56 <adamw> or we should, anyway.
18:57:08 <tflink> yeah, that's what I was getting at
18:57:32 <tflink> if it's not going to be fixed now: slip or change the criteria
18:57:42 <adamw> it seems like desktop team doesn't want system-config-foo tools to show up in 'system tools', and there's no 'settings' group or anything, so they just wind up in other.
18:58:05 <adamw> and they don't seem to want to do anything about that...
18:58:10 <elad661> what's wrong with putting those in system tools?
18:58:17 <adamw> i don't really know.
18:58:34 <elad661> I don't see any reason it wouldn't fit there
18:59:20 * elad661 will comment his toughts in the bug
19:00:05 <adamw> the "System Tools" category in gnome-menus includes things with category 'System', but explicitly excludes things with category 'Settings'. otherwise they'd be in there.
19:00:26 <adamw> there's no rationale in the file explaining why this is.
19:00:47 <brunowolff> Where does desktop think they should show up?
19:02:19 <brunowolff> If the answer is 'other' than the criteria should be changed.
19:02:35 <adamw> it's not particularly clear.
19:02:36 <tflink> a "System Administration"
19:02:39 <tflink> category
19:02:39 <adamw> well, i just poked them again in the bug
19:02:42 <adamw> i'm not sure what else we can do
19:02:45 <tflink> is the onlything that I've seen
19:02:50 <tflink> adamw: nothing that I can think of
19:03:02 <elad661> Having "other" by default is kinda making the whole category sorting useless
19:03:12 <elad661> It's not informative enough
19:03:28 <adamw> elad661: that's why we have this criterion
19:04:30 <clumens> jlaska: https://admin.fedoraproject.org/updates/anaconda-15.31-1.fc15
19:05:22 <adamw> okay, so - propose agreed 697834 we would still like this to be fixed and are unclear why desktop team think it cannot; we will continue to follow up in the bug
19:05:38 <tflink> ack
19:05:49 <brunowolff> +1
19:06:35 <adamw> okay
19:06:38 <adamw> that's all the accepted blockers
19:06:46 <adamw> 8 proposed NTH to go, and we're done
19:06:54 <adamw> actually 7
19:06:59 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699113
19:07:00 <buggbot> Bug 699113: low, unspecified, ---, harald, ON_QA, During boot, message 'mkdir: cannot create directory /run, file exists' appears on virt. console 1
19:07:25 <adamw> this is that cosmetic bug that everyone in the world reports and thinks is the cause of their real bug, whatever it is
19:07:30 <adamw> so i'm totally +1 to fixing it
19:08:01 <brunowolff> +1 NTH
19:08:10 <tflink> +1 NTH
19:08:29 <elad661> +1 NTH (If I'm allowed to vote on this)
19:08:39 <adamw> #agreed 699113 acceptednth: cosmetic issue but affects all installs and confuses people, fixing it would be a good thing
19:08:43 <adamw> elad661: we take votes from anyone. we're not proud :P
19:08:44 <tflink> elad661: you're here, you can vote :)
19:09:28 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702067
19:09:29 <buggbot> Bug 702067: medium, unspecified, ---, rstrode, ON_QA, fedora-icon-theme inherits Mist but does not depend on gnome-themes (where the Mist icon theme lives)
19:09:30 <dgilmore> +1 nth
19:09:51 <elad661> +1 NTH
19:09:52 <adamw> this one's simple enough - it causes icons to be completely messed up in lxde and xfce
19:10:05 <adamw> it'd be a blocker in gnome or kde, but it's in the non-blocking desktops, so nth
19:10:37 <adamw> +1 from me
19:10:55 <tflink> +1
19:10:55 <brunowolff> +1 nth
19:11:12 <adamw> #agreed 702067 acceptednth, criteria-breaking issue in non-blocking desktops (lxde and xfce)
19:11:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702633
19:11:27 <buggbot> Bug 702633: unspecified, unspecified, ---, rcritten, MODIFIED, Fixes for late changes in systemd/chkconfig packages
19:12:28 <adamw> i guess you could hit this installing from dvd with the freeipa package selected?
19:12:39 <adamw> (assuming it's actually in there?)
19:12:58 <dgilmore> +1 nth, though it could also be a zero day update
19:13:05 <dgilmore> it wont effect system install at all
19:13:37 <adamw> right, just that if freeipa's on the dvd and you select it during install, you'd get a broken setup that maybe wouldn't be fixed with an update?
19:13:40 <adamw> that's the only nth scenario i can see
19:14:39 <adamw> i'm kinda 0 on this one
19:14:54 <adamw> i think simo will actually be able to push the update before the freeze anyway...
19:15:06 <dgilmore> yeah
19:15:10 <dgilmore> its likely moot
19:15:15 <tflink> yep
19:15:28 <tflink> +0
19:15:53 <brunowolff> +0
19:15:55 <adamw> propose #agreed 702633 rejectednth for now as there's no clear rationale, if simo doesn't manage to push the fix before the freeze and has a real reason it needs to break freeze, he can re-propose
19:16:17 <dgilmore> +1
19:16:21 <brunowolff> +1
19:16:31 <adamw> #agreed 702633 rejectednth for now as there's no clear rationale, if simo doesn't manage to push the fix before the freeze and has a real reason it needs to break freeze, he can re-propose
19:17:17 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699432
19:17:18 <buggbot> Bug 699432: unspecified, unspecified, ---, pbrobinson, ASSIGNED, SoaS/Sugar spin needs additional firewall ports open for Salut to work.
19:17:24 <adamw> this one's another non-blocker desktop issue
19:17:34 <adamw> i proposed it but may want to retract that in light of sam's latest comment
19:18:13 <adamw> his 4th point is the most important for me
19:18:29 <adamw> so...given that, i'm -1, whoever proposed this as nth is an idiot :P
19:19:16 <dgilmore> ill +1 adamw's last statement
19:20:27 <tflink> -1 on NTH
19:20:32 <brunowolff> -1 nth
19:20:59 * tflink contemplates copying adamw's statement verbatim in the bz comment
19:21:02 <adamw> =)
19:21:18 <adamw> #agreed 699432 rejectednth given samuel's assessment, particularly the point about not affecting default configuration
19:21:31 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702480
19:21:32 <buggbot> Bug 702480: unspecified, unspecified, ---, simon, NEW, [abrt] sugar-browse-120-3.fc15: activitybundle.py:70:__init__:MalformedBundleException: No activity.info file
19:21:49 <adamw> another sugar issue proposed by me (guess what i was doing yesterday), this one's rather more clear-cut though: you can't launch the browser...
19:22:04 <dgilmore> +1 nth
19:22:31 <adamw> pbrobinson has told me via email that he probably can't fix this but he _can_ sub in an alternative browser activity, fwiw. so that's what'll happen.
19:22:47 <adamw> i'm +1 to this one, obviously.
19:24:23 <tflink> +1
19:24:49 <brunowolff> +1 nth
19:25:47 <adamw> #agreed 702480 acceptednth, criteria-breaking issue in a non-blocker desktop
19:26:00 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699027
19:26:01 <buggbot> Bug 699027: unspecified, unspecified, ---, lpoetter, NEW, systemctl --is-enabled does not report properly
19:26:37 <adamw> tim appears to have reported on this one FROM THE FUTURE
19:26:46 <adamw> did you edit the wrong bug, tim? :)
19:27:07 * tflink looks
19:27:13 <adamw> i think that comment was meant for https://bugzilla.redhat.com/show_bug.cgi?id=702633
19:27:14 <buggbot> Bug 702633: unspecified, unspecified, ---, rcritten, MODIFIED, Fixes for late changes in systemd/chkconfig packages
19:27:54 * tflink curses
19:28:06 <adamw> hehe
19:28:49 <adamw> so, for this one...it's obviously a big regression from systemd 24 to 25, i'm not sure if it really hits the nth principles, anyone have a strong feeling?
19:29:13 <dgilmore> nope
19:30:19 <rbergeron> it's a feature
19:30:20 <rbergeron> wait
19:30:26 <rbergeron> why is it not in the feature list
19:30:33 * rbergeron wonders if she did something amazingly stupid
19:30:42 <adamw> systemd? it is.
19:30:47 <rbergeron> no no, freeipa
19:30:52 <adamw> oh.
19:31:00 <adamw> we're on 699027 here
19:31:14 <adamw> 702633 we already did, i just noted that tflink's comment on 699027 was actually meant for 702633.
19:31:19 <tflink> some idiot made the freeipa comment on the wrong bug earlier
19:31:32 <rbergeron> ohhhhhhhhhhhhhhh
19:31:38 <adamw> yeah, some idiot named Jim Splink
19:31:40 <tflink> apparantly, systemd != freeipa
19:32:19 <rbergeron> well. never mind. though i need to look at why freeipa isn't in the list, which freaks me out a bit
19:32:20 <tflink> adamw: how many scapegoat aliases are we up to as a group now?
19:32:22 <rbergeron> and finish the lcoud meeting
19:32:28 <adamw> tflink: just you and james so far
19:32:45 <rbergeron> before Bobbin Fergeron does something stupid
19:32:54 <adamw> so yeah...not sure how to qualify this as nth
19:33:07 <adamw> i guess some rpm scripts could be relying on --is-enabled ?
19:34:17 <tflink> yeah, that or a kickstart file
19:35:07 <tflink> but not sure the ks thing would qualify as NTH
19:35:41 <adamw> basically if it's something a post-release update can't fix, it helps it qualify as nth.
19:36:18 <tflink> could this cause problems with install?
19:36:24 <dgilmore> rbergeron: i hear that bobbin charachter is a cutie petuite
19:37:09 <adamw> tflink: if some package's rpm scripts rely on the functionality, sure.
19:37:11 <rbergeron> lol
19:37:13 <dgilmore> adamw: bo rpm scripts should eb relying on --is-enabled
19:37:26 <dgilmore> s/bo/no/
19:37:26 * adamw hands dgilmore a better keyboard and asks him to try again
19:37:31 <adamw> =)
19:37:32 <adamw> okay
19:37:45 <adamw> i'm kinda feeling -1 nth on this then; nth doesn't just mean 'this is a bad bug we should fix', so...
19:37:54 <dgilmore> your not understanding the engrish coming out of my keys?
19:37:59 <adamw> again we can ask them to re-propose with any specific reasons why the freeze should break for this
19:38:07 <tflink> same here on -1 nth
19:38:17 <dgilmore> adamw: i could see people maybe using it in kickstart %post scripts
19:38:20 <adamw> dgilmore love you longtime
19:38:21 <tflink> no fix has been proposed, no clear disasterous non-fixable in update issue
19:38:32 <dgilmore> adamw: :)
19:38:45 <dgilmore> -1 nth
19:39:44 <adamw> #agreed 699027 -1 nth; it's clearly a bug that should get fixed but no clear rationale for why we should break the freeze (i.e. no scenario has been described in which it can affect something for which a post-release update wouldn't be an acceptable fix). can be re-proposed with a more specific rationale for nth status. freeze is not till 9th, fix can still go in before that.
19:40:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701704
19:40:07 <buggbot> Bug 701704: unspecified, unspecified, ---, lpoetter, NEW, doesn't clear the screen on logout
19:40:45 <adamw> oh crap
19:40:49 <adamw> going back
19:40:57 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=699027
19:40:59 <buggbot> Bug 699027: unspecified, unspecified, ---, lpoetter, NEW, systemctl --is-enabled does not report properly
19:41:00 <adamw> i just noticed something here
19:41:21 <adamw> we rejected https://bugzilla.redhat.com/show_bug.cgi?id=702003 as a blocker earlier as simo could work around that problem
19:41:22 <buggbot> Bug 702003: unspecified, urgent, ---, notting, NEW, chkconfig --level N servicename returns wrong information
19:41:33 <adamw> but his workaround relies on 699027 getting fixed
19:41:41 <tflink> good catch
19:41:51 <adamw> so essentially...the rationale for 699027 being NTH is the scenario described by simo in 702003
19:42:19 <adamw> freeipa needs this info to be correct
19:42:27 <dgilmore> F it
19:42:32 <adamw> so, okay, +1
19:42:38 <elad661> +1
19:42:51 <tflink> +1 to 699027 NTH?
19:43:02 <dgilmore> adamw: both can be fixed in updates
19:43:10 <adamw> tflink: yeah...
19:43:11 <tflink> what are we voting on here?
19:43:15 <tflink> too slow
19:43:19 <adamw> tflink: re-voting 699027 based on the new info
19:43:39 <dgilmore> we just need to make sure that 699027 is fixed first
19:43:47 <tflink> +1 NTH
19:44:02 <dgilmore> adamw: im -1 as neither effects installs and both can be fixed as updates
19:44:13 <adamw> dgilmore: comes down to whether freeipa is on the dvd again i think
19:44:34 <adamw> i should probably look...
19:44:37 <dgilmore> adamw: ill go look
19:45:17 <adamw> doesn't appear to ber
19:45:23 <sgallagh> https://bugzilla.redhat.com/show_bug.cgi?id=702633 was marked refused NTH, we would like to challenge this.
19:45:25 <buggbot> Bug 702633: unspecified, unspecified, ---, rcritten, MODIFIED, Fixes for late changes in systemd/chkconfig packages
19:45:25 <dgilmore> adamw: its not on the dvd
19:45:34 <dgilmore> punt to updates and move on :)
19:45:44 <adamw> oh hey, here comes the cavalry!
19:45:48 <sgallagh> In part because it says "If the fix does not get pushed to stable before the freeze, this can be re-proposed as NTH." We entered freeze yesterday
19:45:59 <adamw> sgallagh: no, the freeze notification was sent out yesterday
19:46:03 <tflink> sgallagh: its on the 9th, no?
19:46:05 <adamw> sgallagh: saying that the freeze comes into effect on the 9th
19:46:12 <dgilmore> sgallagh: freeze is monday
19:46:38 <dgilmore> i should have sent the freeze notification on monday not yesterday
19:46:57 <adamw> the update has sufficient karma already - +1 should be enough - so you can submit it to stable now, and all should be roses
19:47:42 <adamw> sgallagh: simo: so, right now we're discussing 702003/699027
19:48:21 <tflink> note that the comment in 699027 will be updated
19:48:22 <adamw> we're currently likely to reject both as NTH since freeipa isn't on the dvd; if this is fixed with a 0-day or post-release update, that's just as good as fixing it in the frozen package set, as far as we can tell
19:48:46 <adamw> can you see a scenario where it's necessary for freeipa that the systemd issue be fixed *in the frozen package set*?
19:48:55 <sgallagh> adamw: FreeIPA is the package that hit this, but we believe other packages are likely affected without having yet noticed
19:49:02 <simo> 699027 is now more important to us than 702003
19:49:09 <adamw> simo: right, we figured that
19:49:12 <simo> although I think that 702003 is important on itself
19:49:49 <adamw> we think they're important, but to some degree 'important' and 'nth' aren't the same; nth determines whether an update can break the freeze, so for something to be nth there usually has to be some concrete benefit from fixing it *in the frozen package set* rather than as a 0-day update
19:50:24 <sgallagh> adamw: I would think that in general, systemd breaking backwards-compatibility would be considered a blocker
19:50:28 <sgallagh> (Forget NTH)
19:51:04 <simo> adamw, we do not know if it breaks other packages, it broke freeipa until we changed it not to rely on --level
19:51:11 <simo> so I'll leave the decision to you
19:51:50 <simo> personally I think systemd will cause enough headache during f15 first months that one or more bugs won't make a huge difference
19:51:52 <adamw> okay, thanks
19:52:18 <adamw> so, final votes on 699027? given all the above and we don't currently have any scenario where it breaks something on the dvd or install or live images, i'm -1 nth
19:52:53 <tflink> and we don't appear to have a proposal for a fix? Same -> -1 NTH
19:53:31 <brunowolff> -1 nth based on what we know now.
19:53:34 <tflink> if we find more affected packages later, re-propose as NTH with fix?
19:53:50 <adamw> sure, note in the comment that it can be re-proposed with better data
19:54:57 <adamw> #agreed 699027 final vote: rejectednth as there's still no known scenario of breakage on dvd, live images, or otherwise affecting the frozen package set
19:55:21 <simo> adamw, fwiw 699027 can cause misbehavior of the freeipa install script, but won't preclude successful installation (might influence uninstall though)
19:55:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701704
19:55:33 <buggbot> Bug 701704: unspecified, unspecified, ---, lpoetter, NEW, doesn't clear the screen on logout
19:55:44 <adamw> simo: thanks
19:56:04 <simo> ok taken care, bb
19:57:33 <adamw> so...the discussion in the bug seems to wind up in favour of documenting it
19:57:43 <adamw> (which may be difficult as the release notes have been frozen approximately forever, but hey)
19:58:02 <adamw> i'd be +1 nth in _theory_, but if everyone's agreed a code fix isn't appropriate in f15 timeframe it's kinda academic
19:58:38 <tflink> yeah
19:59:00 <tflink> it sounds like there isn't a planned fix that would be ready in time for F15
19:59:30 <adamw> yeah
20:00:11 <tflink> not til F16, if I'm reading that right
20:00:36 <adamw> right
20:00:44 <adamw> so, in practice, -1
20:01:26 <tflink> yeah, if there is a fix that magically becomes tested and available, repropose but otherwise -1
20:01:29 <dgilmore> ehh
20:03:20 * adamw waits for elaboration on the ehh
20:05:19 <dgilmore> adamw: I think it reallly doesnt matter either way
20:05:33 <adamw> so, you're +/-0
20:05:34 <dgilmore> we should document the change
20:05:37 <dgilmore> ya
20:06:02 <adamw> #agreed 701704 rejectednth as it seems all parties agreed fixing in f15 timeframe isn't practical, but change should be documented somehow
20:06:40 <adamw> okay, that's the last on the list, i had one more that someone mentioned just before the meeting, though
20:06:42 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=681750
20:06:43 <buggbot> Bug 681750: unspecified, unspecified, ---, jmccann, NEW, No Language Selection/Language List in GDM
20:06:58 <tflink> haven't we seen that one before?
20:07:05 <adamw> i wasn't sure
20:07:10 <brunowolff> I noticed that but thought it was intentional.
20:07:14 <adamw> it feels like something that's been discussed before but i don't really have the details to hand
20:07:18 <adamw> halfline: yo, still around?
20:07:28 <adamw> brunowolff: i think so too, but i'm not sure the design that's supposed to account for it is present...
20:07:47 <adamw> i thought the idea was there was supposed to be some other obvious way to pick a language either before or after gdm, and there really isn't, afaict
20:07:54 <adamw> i mean, you can _do_ it, but it isn't made obvious at all
20:08:36 <brunowolff> I like to use en_DK.utf8 and remembered being able to do it with gdm, but used the language preferences instead.
20:09:17 <adamw> brunowolff: right, but if you don't speak english at all, having to dig through gnome in english to find it is rather harder than there being a drop-down right on the login screen...
20:09:21 <halfline> adamw: what's up
20:09:38 <adamw> halfline: is the lack of language selection in gdm a design choice? if so, what's the way you're supposed to do it now?
20:09:52 * adamw remembers the tablet he bought which came with android running in chinese
20:09:54 <adamw> that was fun
20:10:14 <dgilmore> adamw: i think it was a design choice
20:10:18 * dgilmore will miss it
20:10:32 <halfline> adamw: yea design choice, you change language from within the session now
20:10:33 <dgilmore> i switch between en_US.UTF8 and es_US.UTF8
20:10:35 <halfline> or at install time
20:10:58 <adamw> halfline: can't do it at install time for live systems, expecting people who don't speak english to drill down into control-center and find the way to do it there kind of sucks :(
20:11:03 <dgilmore> halfline: i use it to switch what language i log in as fairly frequently
20:11:05 <adamw> but i guess it's not something we can change now
20:11:28 <halfline> well we auto login now for the livecd
20:11:37 <halfline> i agree though that we need some sort of "first login" thing
20:11:37 <adamw> oh, right, forgot that wrinkle.
20:11:47 <adamw> probably f16 stuff though, right?
20:11:50 <halfline> yup
20:11:59 <adamw> i guess this is another thing we should document and say 'sorry, we'll fix it later'
20:12:01 <halfline> it's not something we're going to change for f15
20:12:03 <adamw> ok
20:12:06 <dgilmore> halfline: id like to vote for keeping it as it has been
20:12:07 <brunowolff> At one point a countdown was used for auto login on live images to allow for language choice.
20:12:11 <adamw> i'll stick 'commonbugs' on the bug
20:12:18 <dgilmore> halfline: but i know its too late for f15
20:13:27 <adamw> okay
20:13:34 <halfline> another thing we need to get figured out is keyboard layout/input method
20:15:03 <adamw> we have another proposed NTH that landed too late for the list
20:15:04 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=702749
20:15:05 <buggbot> Bug 702749: urgent, unspecified, ---, jmccann, NEW, No login on F15 TC1 Xfce Spin, gdm-simple-greeter goes up to 100% CPU
20:15:51 <adamw> i think that's just a dupe of the known gdm bug
20:16:03 <tflink> yeah, sounds like
20:16:03 <adamw> 690873
20:16:11 <adamw> halfline: sound correct to you?
20:16:39 <halfline> hah i just wrote that on the bug report
20:16:43 <adamw> okay
20:16:53 <adamw> #agreed 702749 is a dupe of 690873
20:16:58 <adamw> and one more i found...
20:17:03 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697649
20:17:04 <buggbot> Bug 697649: high, urgent, ---, simon, NEW, Sugar Wireless Networking broken by NetworkManager 0.9 API
20:17:41 <adamw> another criteria-breaking issue in sugar - wireless networking is totally fritzed (and wired doesn't work great)
20:17:49 <adamw> so pretty no-brainer
20:17:55 <adamw> +1 nth
20:18:01 <dgilmore> +1 nth
20:18:53 <tflink> is this a proposed change to NM or sugar?
20:18:58 <tflink> sugar, right?
20:19:13 <brunowolff> I'm out of time for today.
20:19:32 <adamw> okay, we're pretty much done anyway
20:19:34 <adamw> tflink: sugar, yeah
20:19:42 <tflink> +1 nth
20:19:44 <adamw> tflink: either port it to NM 0.9 API or adjust it to use the 0.8 compat API in 0.9
20:20:07 <adamw> #agreed 697649 acceptednth, criteria breaking issue in non-blocking desktop (Sugar)
20:20:34 <tflink> wait, this was alredy accepted 2011-04-21
20:20:40 <adamw> was it? erf. sorry, missed that.
20:21:08 <adamw> okay, i think we're really done
20:21:14 <tflink> at least we're consistent :-D
20:21:15 <dgilmore> adamw: excellent
20:21:16 <adamw> #topic open floor
20:21:20 <adamw> hehe, yeah, good self-check :P
20:21:47 <adamw> anyone have any bugs not yet brought up?
20:21:50 <tflink> I'll run the magical wiki bug page updating script once I've doublechecked all the BZ updates
20:22:44 <narendrak> adamw:Hi, yes
20:22:46 <narendrak> 
20:23:13 <narendrak> adamw: bug 702740
20:23:14 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=702740 urgent, unspecified, ---, kernel-maint, NEW, Fedora 15 [Regression] -  Existing whitelist for pci=bfsort not being preserved
20:24:16 <adamw> thanks
20:24:20 <adamw> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=702740
20:24:22 <buggbot> Bug 702740: urgent, unspecified, ---, kernel-maint, NEW, Fedora 15 [Regression] -  Existing whitelist for pci=bfsort not being preserved
20:24:46 <adamw> narendrak: what's the practical result of this?
20:24:53 <tflink> yeah, I was wondering the same thing
20:24:55 <adamw> i.e. what actually happens, if the parameter isn't set the way it should be?
20:26:29 <narendrak> adamw: on systems like PowerEdge 1950, pci=bfsort is enabled by default based on model number, this was enabled to mitigate the network interface naming issues
20:26:55 <tflink> so this breaks interface naming?
20:27:00 <tflink> with the new biosdevname?
20:27:03 <adamw> that still doesn't explain the practical result =)
20:27:13 <adamw> does it break networking? make interfaces have really bad names? make them unavailable? what?
20:27:46 <narendrak> adamw: no
20:28:12 <tflink> so, what happens?
20:29:59 <narendrak> adamw: pci=bfsort would not be set by default, which is not how it is in F14
20:30:28 <adamw> yes, we understand that
20:30:37 <adamw> but to decide if this qualifies as a blocker we need to know what that _means_
20:30:41 <adamw> what is the practical result of it not being set
20:30:43 <tflink> but what would happen? Crashes on install? PCI devices won't work? Explosions that take out entire racks of servers?
20:30:50 <adamw> oooh, i like explosions!
20:31:13 <tflink> as long as it's not my machine (doing that once is enough)
20:31:31 <narendrak> right :-).  i agree.
20:33:22 <adamw> so...you still didn't answer the question...
20:34:33 <narendrak> adamw: network functionality is not affected
20:34:44 <adamw> what is affected?
20:34:46 <tflink> narendrak: so, what is affected
20:35:19 * tflink will let adamw ask the questions, we seem to be repeating eachother
20:35:58 <sgallagh> tflink: Maybe you should work out a good cop/bad cop routine :)
20:36:06 <narendrak> the scenario that i was trying to address is when biosdevname is disabled, the pci=bfsort mitigates the
20:36:11 * adamw gets out the rubber hose
20:36:23 <tflink> sgallagh: can you do that over IRC?
20:36:40 <narendrak> possibility of 'eth0' not mapping to 'Gb1'  as labelled on chassis
20:37:27 <tflink> OK, so the effect would be that the biosdevname wouldn't take effect for installed F15 on certain models of dell servers?
20:37:34 <sgallagh> narendrak: Ok, so what you're saying is that the interface names end up being different from the expected values
20:37:59 <adamw> wait, i don't think that's it
20:38:11 <sgallagh> narendrak: eth0 might be Gb1, or it might be Gb2 with no way to predict before actually installing. Am I understanding this?
20:38:13 <adamw> seems like bfsort is a kind of pre-biosdevname way of trying to get the interface names right
20:38:29 <adamw> so if you use biosdevname as is default, this is kind of a no-op
20:38:43 <adamw> if you disable biosdevname, then the interface names are likely to be less accurate to the hardware than they were in f14
20:38:44 <adamw> right?
20:38:49 <narendrak> adamw:right
20:39:33 <adamw> okay. not a blocker, then.
20:39:40 <adamw> could be nth, i guess, though an update would fix it.
20:39:50 <tflink> adamw: even with the installer?
20:40:03 <tflink> device names get assigned in anaconda, no?
20:40:05 <sgallagh> adamw: An update might change the value post-installation, if I'm understanding it correctly.
20:40:10 <adamw> sgallagh: yeah, seems that way
20:40:28 <adamw> so maybe best to change it before release if at all
20:40:28 <sgallagh> That would be bad, if interfaces change names post-install
20:40:29 <adamw> +1 nth?
20:40:53 <tflink> +1 nth, if we're understanding correctly
20:41:12 <narendrak> adamw: no, i think
20:41:46 <narendrak> if upgraded, 70-persistent-net.rules will be preserved from the previous installation
20:42:08 <adamw> ah, so you'd get the same names you got on install...but they'd be the 'wrong' ones
20:42:13 <adamw> so we can't effectively fix it with an upgrade
20:42:45 <narendrak> names will not change across updates. they will be preserved
20:43:13 <adamw> right
20:43:26 <adamw> so if we don't fix this, and you disable biosdevname, you're kinda stuck with the bad names. so, still +1 nth for me.
20:44:01 <narendrak> upgrading a system with F14 to F15 will preserve the naming existed in F14
20:44:03 <tflink> yeah, I can see this being a big PITA if it was used on server,s though
20:44:39 <tflink> it would be a bit of a stretch to be a blocker, though
20:44:44 <tflink> so still +1 nth
20:44:55 <adamw> yeah
20:44:57 <adamw> okay
20:45:22 <adamw> #agreed 702740 rejectedblocker as it doesn't cause any major breakage, only 'wrong' interface names if biosdevname is disabled. acceptednth as the if names are fixed during install and can't be fixed with post-release updates
20:45:33 <adamw> aaaand with that...we really can end the meeting, i think :)
20:46:01 <tflink> propose #action set the fuse at the bottom instead of at the top - shorter that way :)
20:46:33 <adamw> heheh
20:46:37 * adamw nukes the fuse
20:46:39 <adamw> thanks all!
20:46:40 <adamw> #endmeeting