16:01:56 <tflink> #startmeeting f18-alpha-blocker-review-4
16:01:56 <zodbot> Meeting started Wed Aug 22 16:01:56 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:56 <kparal> fireworks!
16:01:58 <tflink> #meetingname f18-alpha-blocker-review-4
16:01:58 <zodbot> The meeting name has been set to 'f18-alpha-blocker-review-4'
16:02:03 <tflink> #topic Roll Call
16:02:11 * kparal needs to go in 10 minutes
16:02:12 <tflink> who all's here for some blocker review fun?
16:02:25 * elad_laptop is here
16:02:37 <tflink> kparal: not acceptable
16:02:39 * nirik is lurking around.
16:02:44 <tflink> :)
16:02:56 <kparal> I'll read the log, I promise
16:02:59 <tflink> kparal: are there any bugs in particular that you'd like to see covered first?
16:03:29 <kparal> tflink: I don't think so
16:03:50 <kparal> nothing stands out in the proposed list
16:04:18 <tflink> ok, just making sure
16:04:30 <adamw> yo
16:04:50 <tflink> elad_laptop: welcome
16:06:10 * tflink waits another minute or two to see if we get 1 or 2 more people
16:06:18 * mkrizek joins
16:06:20 <kparal> mkrizek is my press manager today
16:06:45 <tflink> so all emails to you should be routed through him?
16:07:11 <mkrizek> oh god no
16:07:13 <mkrizek> :)
16:07:24 <kparal> he would be stating all my decisions and we can then blame him if they prove to be wrong
16:07:45 * rbergeron is here though god only knows how my internets will be
16:07:55 * rbergeron is coming to you LIVE from fudcon valencia hotel
16:08:05 <tflink> that sounds like a pretty sweet setup there - if it goes right, you can take credit. if it goes wrong, he can be blamed
16:08:22 <kparal> tflink: exactly
16:08:23 * maxamillion is here-ish
16:08:30 <kparal> I'm starting to like it
16:08:32 * tflink read internets as internals at first - glad that it was misread
16:09:02 <tflink> cool, I think we have a quorum, lets get started with some always awesome boilerplate
16:09:07 <tflink> #topic Introduction
16:09:18 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:09:29 <tflink> We'll be following the process outlined at:
16:09:29 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:29 <tflink> The bugs up for review today are available at:
16:09:30 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:44 <tflink> The criteria for release blocking bugs can be found at:
16:09:45 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:09:58 * tflink remembered to update the link this time :)
16:10:03 * adamw loves boilerplate
16:10:03 <maxamillion> tflink: holy jeebus, that webpage is *amazing* ... who made http://qa.fedoraproject.org/blockerbugs/current ?
16:10:11 <adamw> maxam: tflink did, take a bow tim
16:10:26 <maxamillion> tflink: that's absolutely *awesome*
16:10:29 * tflink bows but it's not all that special
16:10:39 <tflink> it needs a facelift :)
16:10:39 <maxamillion> <--- webdev noob
16:10:39 <rbergeron> oh, hell yes
16:10:43 <rbergeron> when did that happen?
16:10:48 * rbergeron lifts up the rock
16:10:59 <maxamillion> rbergeron: +1
16:11:01 <elad_laptop> that's awesome.
16:11:06 <tflink> rbergeron: the first version was released into the wild right before the first blocker review meeting
16:11:06 * kparal needs to go. mkrizek, don't forget being a good press manager
16:11:21 <elad_laptop> I noticed it on a different domain not long ago, glad it made it out to be official
16:11:23 <adamw> rbergeron: it just got put onto fp.o last week. before that it was even more awesome because it was hosted on tim's own domain, which is supermegawaffle.com =)
16:11:41 <rbergeron> tflink: you own supermegawaffle.com?
16:11:53 <tflink> rbergeron: yep, that's one of my domains
16:12:01 <rbergeron> that's ... well, that just rocks my waffle, that's all i have to say about it. especiaially since i don't ant to detract from the epic fun of a blocker meeting
16:12:13 <rbergeron> which go on for some time during this part of the cycle :)
16:12:44 <tflink> elad_laptop: yeah, it took me a while to get everything set up in the fedora infra. actually, I'm still working on that (packaging issues left to iron out)
16:13:00 <tflink> but it works and we digress
16:13:28 <tflink> if anyone has ideas for what else we could do with the app (different views, an API etc.), feel free to propose them
16:13:46 <tflink> any objections to starting with the proposed blockers?
16:13:57 <rbergeron> nope
16:14:13 <tflink> #topic (841451) polkitd doesn't start in rawhide
16:14:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=841451
16:14:14 <tflink> #info Proposed Blockers, NEW
16:14:15 <buggbot> Bug 841451: unspecified, unspecified, ---, davidz, NEW , polkitd doesn't start in rawhide
16:14:29 <adamw> so sigh, i really need to get around to re-checking this.
16:14:45 <tflink> I was just wondering if we got around to that, I haven't done it either
16:14:56 <adamw> if anyone has a clean tc3 install sitting around...
16:15:11 * maxamillion is working on installing one now
16:15:13 <adamw> i'm kinda convinced myself it's 844167, but really ought to confirm.
16:15:51 * nirik has one...
16:15:55 <nirik> what am I checking?
16:16:12 <elad_laptop> nirik: did polkitd start correctly?
16:16:19 * nirik fires up the machine.
16:16:32 <tflink> polkit is running on my almost-tc3 VM
16:16:47 <tflink> interestingly enough, polkitd.service does not exist. only polkit.service
16:17:14 <mkrizek> tflink: I can confirm that, checked that earlier today
16:17:27 * nirik waits for virt-manager to connect
16:17:57 <adamw> tflink: yeah, that's normal.
16:18:10 <tflink> ok, I thought it was supposed to be polkitd.service
16:18:25 <adamw> no, it's definitely polkit.service.
16:18:56 <tflink> either way, polkit.service is running on my VM
16:19:28 <elad_laptop> basically it failed cause it needed its own user, which was not created for updates
16:19:28 <adamw> does the 'polkitd' user and group exist?
16:19:36 <elad_laptop> s/user/group/
16:19:49 <elad_laptop> when you do a clean install or a reinstall, the group will be there
16:20:20 <tflink> yes, polkit user and group both exist, gid 999, uid 999
16:20:23 * nirik will have to rescue his virt instance. It's trying to start lightdm, but due to cirrus breakage it's not starting X right.
16:20:41 <adamw> nirik: set the video card to 'vga' or add 'nomodeset'.
16:20:58 <adamw> tflink: ok. i think we can probably just make the call that it's 844167 then, and hence not a blocker as it relates to yum upgrade.
16:20:58 <elad_laptop> Therefore I think this should not be an alpha blocker but rather a beta blocker
16:21:01 <nirik> yeah, grub is also hosed... but will fix.
16:21:05 <adamw> i expect it wouldn't hit an anaconda upgrade as anaconda runs in permissive mode.
16:21:27 <elad_laptop> we will have to check that.
16:21:30 <tflink> just yum upgrade, then?
16:21:38 <adamw> elad_laptop: we can't until the upgrade code exists =)
16:21:41 * tflink isn't sure that's as blocker worthy
16:21:44 <adamw> tflink: that's my current understanding, yeah.
16:21:45 <elad_laptop> adamw: exactly.
16:21:58 <tflink> either way, lets move to beta proposed
16:22:45 <tflink> proposed #agreed 841451 - RejectedBlocker (Alpha) - This appears to be an upgrade issue which is not alpha blocker material. Change to a proposed beta blocker.
16:22:50 <tflink> ack/nak/patch
16:22:54 <elad_laptop> ack
16:23:07 <adamw> ack
16:23:09 <mkrizek> ack
16:23:18 <nirik> ack
16:23:21 <tflink> #agreed 841451 - RejectedBlocker (Alpha) - This appears to be an upgrade issue which is not alpha blocker material. Change to a proposed beta blocker.
16:23:28 * nirik confirms polkit is running in my tc3 install too.
16:23:31 <tflink> #topic (850550) TypeError: verifyLocalPkg() takes exactly 1 argument (2 given)
16:23:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=850550
16:23:36 <buggbot> Bug 850550: urgent, unspecified, ---, packaging-team, ON_QA , TypeError: verifyLocalPkg() takes exactly 1 argument (2 given)
16:23:36 <tflink> #info Proposed Blockers, ON_QA
16:24:13 <tflink> sounds like a pretty clear blocker to me
16:24:21 <elad_laptop> I think so too
16:24:22 * tflink looks for criterion
16:25:06 <tflink> "The installer must be able to use at least one of the HTTP or FTP remote package source options" ?
16:25:15 <tflink> which isn't quite right
16:25:43 <elad_laptop> " The installer must be able to complete an installation using the text, graphical and VNC installation interfaces "
16:25:58 <elad_laptop> with this bug it can't even start an installation
16:26:08 <elad_laptop> therefor, this criterion fits
16:26:13 <tflink> true but the emphasis there is the interfaces
16:26:22 <tflink> but it's closer than the one I listed
16:26:26 <tflink> any other thoughts?
16:26:36 <adamw> i'm, er, not sure on this one.
16:26:53 <adamw> bcl said they'd actually worked around this bug in anaconda, i thought?
16:27:23 <adamw> oh, well, we need to take the fix anyway, so meh. +1
16:27:38 <tflink> "The installer must be able to complete package installation with the default package set for each supported installation method"
16:27:53 <tflink> but this is semantics after a point
16:28:31 <tflink> proposed #agreed 850550 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:28:45 <tflink> ack/nak/patch? I can switch the criterion if that works better
16:28:49 <elad_laptop> ack
16:29:13 <adamw> acl
16:29:14 <adamw> ack
16:29:59 <mkrizek> ack
16:30:06 <tflink> #agreed 850550 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:30:16 <tflink> #topic (849998) KDE artwork in Spherical Cow still contains content from the previous release
16:30:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849998
16:30:21 <buggbot> Bug 849998: unspecified, unspecified, ---, rdieter, ON_QA , KDE artwork in Spherical Cow still contains content from the previous release
16:30:21 <tflink> #info Proposed Blockers, ON_QA
16:30:55 <tflink> pretty clear blocker
16:31:06 <nirik> +1 blocker
16:31:21 <mkrizek> note: this one's fixed
16:31:33 <tflink> proposed #agreed 849998 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the install
16:31:48 <elad_laptop> ack
16:31:49 <tflink> I bet that's too long, isn't it?
16:31:49 <mkrizek> ack
16:31:56 <nirik> ack
16:32:50 <tflink> #agreed 849998 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development."
16:33:06 <tflink> #topic (849982) The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3
16:33:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849982
16:33:10 <buggbot> Bug 849982: unspecified, unspecified, ---, tcallawa, NEW , The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3
16:33:11 <tflink> #info Proposed Blockers, NEW
16:33:39 <elad_laptop> the background is packaged now (I should know cause I have it installed)
16:33:52 <elad_laptop> but I wonder about "GRUB Boot Menu has also what appears to be Fedora 17 theme." (comment 5)
16:34:03 <elad_laptop> didn't we disable the grub theme cause it caused slowness?
16:34:09 <tflink> it does match the F17 background
16:34:27 <elad_laptop> I thought we disabled the grub theme, to make it themeless like before f17ga
16:34:28 <tflink> elad_laptop: that was for F17 and I think that we also didn't have a complete theme in time
16:34:34 <mkrizek> elad_laptop: I installed it earlier today and the grub theme was enabled
16:34:54 <mkrizek> and yes, it's F17 background
16:35:09 <mkrizek> netinst
16:35:10 <tflink> sounds like a blocker to me, other thoughts?
16:35:15 <mkrizek> +1
16:35:30 <nirik> +1
16:35:38 <elad_laptop> for alpha, let's make this a blocker and disable the theme (unless the design team can get one ready without slowing alpha), the design team will attempt the finalize a theme for beta
16:35:47 <elad_laptop> so yeah, +1
16:36:18 <jreznik> sorry for being late, another meeting conflict
16:36:30 <tflink> proposed #agreed 849982 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following F18 alpha release criterion: "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development"
16:36:42 <tflink> jreznik: no worries, we're still reviewing bugs :)
16:36:50 <mkrizek> ack
16:36:54 <nirik> ack
16:36:57 * tflink wonders if the grub theme is blocking, though
16:37:07 <elad_laptop> It's artwork
16:37:12 <elad_laptop> ack
16:37:16 <tflink> my understanding of the criterion is that we wanted to reduce confusion between the releases
16:37:17 <adamw> so wait, what are we accepting here exactly? the grub background?
16:37:27 <tflink> the grub theme doesn't say F17 and it's different from F17
16:37:57 * jreznik prefers consistent alpha theming
16:37:57 <mkrizek> it somehow resemble F17 though
16:38:09 <elad_laptop> It is the f17 background
16:38:17 <elad_laptop> and it was made for 17
16:38:39 <tflink> true but it still looks different and doesn't say F17 - fewer chances for confusion
16:39:00 <jreznik> mkrizek: the question is - do we want to theme grub or not? that's the question for design team (we do not theme for each release plymouth...)
16:39:12 <tflink> if gnome isn't installable, we might need to punt until we can get a working gnome install
16:39:33 <elad_laptop> We did want to theme grub...
16:39:36 <adamw> the criterion probably isn't the best we ever came up with...
16:39:43 <elad_laptop> yes
16:39:53 <elad_laptop> anyway, I say let's not make this a blocker, logic.
16:40:19 <tflink> yeah, I think of alpha blocker artwork issues as stuff like the installer using the wrong version's graphics during install or something like that
16:40:31 <adamw> maybe punt on it for now and try to clarify with the design team exactly what the plan is for what bits of artwork should change per release...
16:40:33 <elad_laptop> I remember the theme being ready for f17 and then disabled because people reported it caused so much slowness grub was unusable
16:40:45 <nirik> yeah, it landed way late in f17
16:41:05 * jreznik can work with artwork team on it
16:41:46 <adamw> sounds good to me
16:41:47 <elad_laptop> adamw: as a member of the design team (I don't speak for the team, only myself) , I think we should make grub theme generic
16:41:52 <jreznik> elad_laptop: that's why it's alpha stuff... theming is artwork, yes, but implementation could be broken...
16:42:05 <adamw> jreznik: no, the intent of this criterion is as tflink said, to prevent confusion
16:42:07 <mkrizek> elad_laptop: I agree
16:42:17 <jreznik> elad_laptop: +1, once plymouth is generic one, grup should be too
16:42:21 <adamw> we had a release a while back where the Alpha had graphics all the way through that identified it as the previous release
16:42:31 <mkrizek> the grub theme is not generic as of now
16:42:33 <adamw> so people were posting and saying 'this isn't Fedora N+1 at all, it's Fedora N!'
16:42:35 <tflink> proposed #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker.
16:42:44 <adamw> really, we should word the criterion a bit better so that entirely generic art is okay
16:42:53 <adamw> tflink: that kinda works for me
16:43:01 <tflink> adamw: suggestions for improvement?
16:43:01 <elad_laptop> jreznik: it being slow is a bug in grub, it is not really good in rendering high resolution graphics
16:43:08 <elad_laptop> and it shouldn't be, cause it's a bootloader
16:43:15 <tflink> but that's a different issue
16:43:22 <elad_laptop> ack
16:43:27 <adamw> tflink: just state clearly that we're punting, i guess
16:43:43 <tflink> proposed #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker. Will re-evaluate at the next blocker review meeting.
16:43:53 <adamw> ack
16:43:54 <elad_laptop> acl
16:43:55 * nirik shrugs. ack
16:43:55 <mkrizek> ack
16:43:58 <elad_laptop> *ack
16:44:02 <tflink> #agreed 849982 - This is not a clear alpha blocker since it doesn't look exactly like the F17 theming. If the gnome theme is still F17, it will be accepted as a blocker. Will re-evaluate at the next blocker review meeting.
16:44:03 <aspratyush> ack
16:44:04 * jreznik is not sure
16:44:39 <tflink> jreznik: I can #undo if you have a suggestion
16:44:58 <elad_laptop> some of the design team prefers grub un-themed anyway, but that should not block alpha
16:45:26 <jreznik> tflink: go on
16:45:34 <tflink> ok, moving on
16:45:36 <elad_laptop> designwise, we shouldn't make grub attract too much attention, and we should also have 0s timeout by default unless other OSs are installed
16:46:07 <tflink> elad_laptop: perhaps but I'm not sure that's an issue for QA
16:46:16 <elad_laptop> It's not
16:46:20 <tflink> #topic (849967) firstboot fails to run partly due to /etc/sysconfig/i18n not being written by anaconda
16:46:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849967
16:46:25 <buggbot> Bug 849967: unspecified, unspecified, ---, vpodzime, POST , firstboot fails to run partly due to /etc/sysconfig/i18n not being written by anaconda
16:46:26 <tflink> #info Proposed Blockers, POST
16:46:30 <elad_laptop> just throwing bits of information around
16:46:58 <tflink> ok, not trying to shut down discussion - just trying to keep the meeting moving. these take long enough as it is :)
16:47:40 <elad_laptop> Sure, I understand
16:47:47 <jreznik> seems POST means Patch for this issue has been posted to anaconda-patches-list.
16:47:52 <tflink> I assume that this affects more than just LXDE and XFCE?
16:48:03 <jreznik> tflink: yep
16:48:18 <jreznik> and not sure what everything relies on i18n correctly written
16:48:48 <jreznik> definitely firstboot
16:48:59 <nirik> I got no firstboot here with tc3 and an Xfce install.
16:49:03 <tflink> what is the effect of this and what all does it affect?
16:49:13 <tflink> is it firstboot or anaconda crashing?
16:49:34 <jreznik> nirik: this one of the issues - missing i18n (traceback) - anaconda one and another is python-meh and gtk3
16:49:59 <jreznik> tflink: this issue is cause by anaconda now writing i18n correctly
16:50:01 <elad_laptop> isn't firtboot obsolete due to the anaconda redesign? (I'm not sure if configure-during-install was implemented yet)
16:50:09 <jreznik> there's another firsboot bug
16:50:11 <nirik> elad_laptop: only for gnome desktop...
16:50:24 <jreznik> and it's no anaconda redesign but initial experience
16:50:27 <tflink> jreznik: yeah, but I'm trying to figure out how the effect manifests
16:50:34 <elad_laptop> nirik: I'm not talking about the initial experience thing
16:50:36 <jreznik> (not sure about state, I asked mclasen to get status)
16:50:53 <elad_laptop> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/03-progress_hub2.svg
16:50:54 <adamw> elad_laptop: i don't believe anaconda is aiming to replace firstboot, no.
16:50:55 <tflink> in terms of release blocking DEs, it would have to affect KDE since gnome wouldn't be affected
16:51:03 <nirik> elad_laptop: ok. My understanding was that it was not obsolete, but I could be wrong.
16:51:07 <jreznik> elad_laptop: I talked to Anaconda guys and they don't know... even the IE cooperation is somehow unclear
16:51:16 <adamw> elad_laptop: that's a design mockup from a long time back. i don't think it's in the current newui design.
16:51:20 <nirik> it should be affecting kde as well I would think, but cannot directly confirm
16:51:36 <jreznik> yea, it affects kde
16:51:39 <tflink> if it's crashing firstboot, it'll affect KDE
16:51:42 <adamw> tflink: i don't think initial experience actually exists yet. this bug would certainly affect kde.
16:52:01 <jreznik> adamw: not sure about IE state, I asked mclasen on Monday...
16:52:04 <tflink> ah, I thought that it was already in alpha
16:52:05 <adamw> ok
16:52:06 <jreznik> but he was on PTO...
16:52:19 <adamw> tflink: i might be wrong, of course =)
16:52:20 <elad_laptop> I don't know what anaconda implements at the moment, I only remember what the design was...
16:52:22 <jreznik> so he has to ask team what's the progress
16:52:39 <jreznik> elad_laptop: it's not there and definitely not for f18
16:52:43 <tflink> either way, it sounds like we can take this as a blocker due to crashing firstboot on a KDE install
16:52:45 <elad_laptop> okay
16:52:49 <jreznik> yep
16:52:55 <adamw> yeah, +1 blocker.
16:53:05 <elad_laptop> +1 blocker
16:53:05 <jreznik> +1 (to be formal)
16:53:17 <nirik> +1 blocker yes
16:53:23 <adamw> ahhh, there's a separate anaconda-patches ML now. that clears things up.
16:53:36 <jreznik> :)
16:53:55 <tflink> proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explic
16:54:04 <tflink> gah, I need to work on the length of those
16:54:25 <adamw> you can cut out the parentheses i guess
16:54:40 <tflink> proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the co
16:54:42 <adamw> Release Criteria (Simplified Edition) :)
16:54:47 <tflink> that's still too long
16:54:49 <adamw> and the second sentence.
16:55:10 <tflink> proposed #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
16:55:16 <tflink> is that short enough?
16:55:19 <elad_laptop> I think you should just give ID numbers to release criteria and use them instead :P
16:55:56 <tflink> I think that would get confusing to people unfamiliar with the process, to be honest
16:56:02 <tflink> and to me :)
16:56:05 <jreznik> and me
16:56:14 <elad_laptop> hence the :P
16:56:20 <tflink> ah, a bit slow
16:56:21 <elad_laptop> I was joking.
16:56:29 <adamw> ack
16:56:32 <elad_laptop> ack
16:56:37 * jreznik is not computer to translate ID to text description... no blockerno function here
16:56:39 <jreznik> ack
16:56:47 <tflink> however, the idea of having entire discussions around f18a#7 vs f18a#9 is somewhat amusing
16:57:02 <tflink> #agreed 849967 - AcceptedBlocker - Accepted as a F18 alpha blocker due to violation of the F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
16:57:17 <tflink> #topic (850775) display managers aren't enabled after installation
16:57:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=850775
16:57:17 <tflink> #info Proposed Blockers, NEW
16:57:19 <buggbot> Bug 850775: unspecified, unspecified, ---, anaconda-maint-list, NEW , display managers aren't enabled after installation
16:58:01 * nirik was going to file something like this one. ;)
16:58:31 <nirik> there's a related spins-kickstarts bug
16:58:33 <jreznik> the whole presets thing is going to be crazy this release (not only dms)
16:58:46 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=850465
16:58:47 <buggbot> Bug 850465: unspecified, unspecified, ---, kanarip, NEW , KDE Spin should be shipped with KDM as the default login manager
16:59:10 <adamw> holy moley, i need a vacation.
16:59:28 <nirik> yeah, lets all go. ;)
16:59:38 <adamw> right, this is an obvious blocker for me
16:59:41 <tflink> it sounds like a blocker to me, unless I'm missing something
17:00:10 <nirik> yep. blocker, but I don't know enough details to say how best to fix it. ;)
17:00:31 <adamw> yeah, me either
17:00:38 <adamw> 850465 has this:
17:00:42 <nirik> anyhow, +1 blocker, we should fix it.
17:00:43 <adamw> "Halfline pointed out too that the old default ordering still takes place, so if only kdm is installed, it will get used."
17:00:53 <nirik> but that doesn't seem to be the case/
17:00:53 <adamw> which doesn't sound like what's actually happening...
17:00:54 <nirik> ?
17:00:55 <adamw> yeah
17:00:59 <adamw> maybe this is a systemd bug?
17:01:06 <adamw> definitely not anaconda, anyhow,
17:01:27 <elad_laptop> we moved from the prefdm logic to have a service file for each display manager
17:01:54 <tflink> proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account"
17:01:57 <elad_laptop> therefor we need to make our postinstall scripts aware of it and enable the installed display manager
17:02:01 <adamw> yeah, i get that. it's the involvement of this 'presets' thing that's confusing the issue for me.
17:02:23 <nirik> where are the presets currently being set? no where I guess?
17:02:29 <adamw> tflink: wrong criterion
17:02:34 <adamw> tflink: this should be the next one
17:02:40 <jreznik> adamw: and as I said - there's going more fun with presets as I heard
17:02:53 <adamw> firstboot startup doesn't rely on a login manager, but post-firstboot startup does.
17:03:06 <tflink> point, I was thinking it did for some reason
17:03:18 * nirik guesses it should just go in ks files at least for now...
17:03:44 <jreznik> nirik: we were talking about usin ks on #fedora-kde mtg
17:03:55 <tflink> proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is s
17:04:01 <nirik> jreznik: yeah, seems easiest.
17:04:06 <adamw> what about DVD installs?
17:04:15 <elad_laptop> nirik: ks for now unless someone manages to understand the presets thing
17:04:18 <tflink> proposed #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "After firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
17:04:27 <adamw> ack
17:04:30 * tflink assumed that it was too long
17:04:31 <jreznik> adamw: I have to ask lennart (that's my action item from kde-sig mtg)
17:04:34 <nirik> adamw: details details. ;) Yeah, that would be a flaw in that plan.
17:04:42 <nirik> ack
17:04:49 <mkrizek> ack
17:04:55 <tflink> #agreed 850775 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the release criterion: "After firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
17:04:56 <adamw> i'm tempted to mark 850465 as a dupe of 850775 and adjust it to systemd so lennart tells us what to do
17:05:07 <adamw> sound like a plan? or do we want 850465 to be separate?
17:05:08 <nirik> adamw: sounds reasonable to me.
17:05:27 <jreznik> adamw: sounds good, lennart is only person who can answer it right now
17:05:42 <jreznik> we (as kde sig) are quite lost in this waters...
17:06:12 <tflink> before I forget ...
17:06:17 <nirik> I guess now thinking about it we need a package for each spin that uses presets. ;(
17:06:17 <tflink> #chair adamw
17:06:17 <zodbot> Current chairs: adamw tflink
17:06:29 <nirik> but that could be bad if multiple ones are installed...
17:06:42 <adamw> nirik: but hey, anaconda doesn't let you install multiple desktops any more ;)
17:06:53 <nirik> you can still do it post install...
17:07:02 <jreznik> nirik: that's probably true, and it's idea of presets... but how to solve DVD install?
17:07:06 <tflink> I have at least one machine with multiple DEs installed
17:07:21 <nirik> if they are using different numbers/names, one of them will 'win'
17:07:49 <nirik> anyhow, drifting out of scope.
17:07:53 <nirik> we will figure it out.
17:08:06 <jreznik> yeah
17:08:12 <tflink> yep, sounds like it'll be tons of fun
17:08:21 <tflink> #topic (849395) UnicodeDecodeError: 'utf8' codec can't decode byte 0xb8 in position 0: invalid start byte
17:08:21 <jreznik> so close as dupe and get lennart involvement?
17:08:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849395
17:08:25 <buggbot> Bug 849395: unspecified, unspecified, ---, rvykydal, MODIFIED , UnicodeDecodeError: 'utf8' codec can't decode byte 0xb8 in position 0: invalid start byte
17:08:26 <tflink> #info Proposed Blockers, MODIFIED
17:08:50 <tflink> jreznik: I think they were talking about closing the KDE live as adupe of 850775 since it's more generic
17:09:23 <nirik> ran into this, it's fixed.
17:09:37 <nirik> I think anyone with a ipv6 enabled radvd network would hit it.
17:10:40 <tflink> proposed #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:11:09 <adamw> this is an installer error, isn't it?
17:11:18 <adamw> so it'd have to be one of the anaconda criteria
17:11:22 <adamw> http/ftp package source, maybe
17:11:27 <nirik> it bombs out right as it starts the main hub thing...
17:11:41 <nirik> when it's activating network I guess.
17:12:11 <tflink> ah, I misunderstood
17:12:26 <tflink> proposed #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installer must be able to use at least one of the HTTP or FTP remote package source options"
17:12:41 <nirik> sure. ack
17:13:28 <jreznik> ack
17:14:16 <adamw> ack
17:14:23 <tflink> #agreed 849395 - AcceptedBlocker - Accepted as F18 alpha blocker due to violation of the following release criterion for systems using ipv6: "The installer must be able to use at least one of the HTTP or FTP remote package source options"
17:14:33 <tflink> #topic (849990) Apper: Authentization failed when trying to install updates
17:14:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849990
17:14:37 <buggbot> Bug 849990: unspecified, unspecified, ---, rdieter, ASSIGNED , Apper: Authentization failed when trying to install updates
17:14:38 <tflink> #info Proposed Blockers, ASSIGNED
17:15:22 * tflink wonders if this will affect pk in gnome as well
17:15:54 * jreznik has to recheck this one... but maybe releated to that polkitd bug?
17:16:33 <tflink> proposed #agreed 849990 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following criteria for KDE systems: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:16:46 * nirik could try in Xfce real quick. ;)
17:16:54 <nirik> ack
17:17:00 <adamw> ack
17:17:10 <jreznik> ack
17:17:12 <tflink> #agreed 849990 - AcceptedBlocker - Accepted as a blocker for F18 alpha due to violation of the following criteria for KDE systems: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:17:17 <mkrizek> ack
17:17:26 <tflink> OK, that's all of the proposed blockers
17:17:29 <adamw> mkrizek: just to verify, this is from a clean install, not an upgrade?
17:17:39 <mkrizek> adamw: yes
17:17:41 <adamw> ok.
17:17:57 <adamw> jreznik: it's not related to the polkit-not-running bug, then - see comment #7, polkit is running and the user exists.
17:18:27 <tflink> any objection to doing the single proposed NTH?
17:18:36 <jreznik> adamw: ah, I'll take a look on this one
17:19:18 * tflink takes that as a 'no'
17:19:22 <tflink> #topic (847548) kernel BUG at include/linux/scatterlist.h:67 (vp_set / virtscsi_init / virtscsi_complete_free) kernel panics when virtio-scsi module is loaded
17:19:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847548
17:19:26 <buggbot> Bug 847548: unspecified, unspecified, ---, kernel-maint, MODIFIED , kernel BUG at include/linux/scatterlist.h:67 (vp_set / virtscsi_init / virtscsi_complete_free) kernel panics when virtio-scsi module is loaded
17:19:27 <tflink> #info Proposed NTH, MODIFIED
17:21:04 <adamw> there's a rationale in comment #11...
17:21:27 * tflink is a little hesitant to take a new kernel build
17:21:54 <tflink> if this only hits virtio-scsi, couldn't you switch the virtio driver to something else to work around this or am I misunderstanding the bug?
17:22:21 <adamw> tflink: we already accepted 849244 as nth so we're getting a new kernel anyhow
17:22:48 <adamw> aiui, this bug exists in that new kernel and the nth proposal was made so we could avoid that regression...
17:23:28 * adamw pinged jwb to see if he can help
17:24:00 <jwb> hi
17:24:03 <adamw> hi jwb
17:24:16 <adamw> so we're just trying to get our heads around the current status wrt kernel...
17:24:44 <jwb> do you want to do a one-by-one bug recount, or just have me summarize?
17:24:52 <adamw> summarize is probably good
17:24:52 <adamw> um
17:25:11 <jwb> ok here goes
17:25:35 <adamw> it is the case that you've just been finding regressions in the build that we were going to pull in to add secureboot support, and fixing those, more or less?
17:25:48 <jwb> yes, essentially
17:26:03 <adamw> so if we take this as NTH and pull the latest build, we'll get something *more reliable* than we'd get if we just pulled the earliest build that has the SB support?
17:26:05 <jwb> i've edited the update with the latest build.  it fixes the bugs listed, plus a CVE in the network stack
17:26:25 <adamw> i'm fine with accepting this as NTH and taking the most recent build, if all the changes have been stabilization/bugfix, i think
17:26:26 <jwb> yes, that is what I believe
17:26:28 <adamw> ok
17:26:35 <tflink> so our options are to not take the SB capable kernel as NTH or take the regression fixes as NTH?
17:26:48 <tflink> wait, the SB-capable kernel is already in stable, isn't it?
17:26:53 <jwb> tflink, no
17:27:02 <adamw> https://admin.fedoraproject.org/updates/kernel-3.6.0-0.rc2.git2.1.fc18,grub2-2.00-5.fc18,pesign-0.10-4.fc18 is the update
17:27:14 <adamw> it never got pushed stable yet; it's had updated builds edited in several times
17:27:20 <jwb> adamw, correct.  i edited it this morning to include the newer kernel
17:27:37 <jwb> now
17:27:39 <adamw> tflink: we *could* choose to ask jwb to cancel the update and re-submit it with an older build, that only has the SB stuff. but i don't see much value in that
17:27:49 <nirik> we aren't pushing anything to stable except karmaed /accepted blockers. ;)
17:28:05 <adamw> we're definitely going to be slipping, so effectively we're a week from go/no-go, so i think it's okay to take at this point...
17:28:53 <tflink> OK, I can follow the logic but I think that my counter argument still holds somewhat
17:28:57 <jreznik> to take, you mean?
17:29:01 <tflink> IIRC, this is a non-default virt setup.
17:29:22 <adamw> so let's see, right now the kernel we have in 'stable' is kernel-3.6.0-0.rc1.git6.1.fc18.x86_64.rpm
17:29:31 <tflink> I'm not sure that this particular bug is well qualified to be NTH and it also sounds like there are more fixes being included beyond the SB stuff
17:30:00 <tflink> if I'm being overly pedantic, I'll back down though
17:30:08 <adamw> the kernel currently in the update is kernel-3.6.0-0.rc2.git2.1.fc18 . which bumps to a new upstream rc, adds SB support, and fixes several specific regressions that were found in testing.
17:30:48 <adamw> i don't think we have really solid testing of any point between those two kernels, so i can't see an argument for taking one of the midpoints
17:31:00 <adamw> i think we either go with the current 'stable' kernel or we take the latest update
17:31:03 <jreznik> as I already said - I'd like to see SB as soon as possible in fedora... to avoid surprises...
17:31:48 <tflink> I just don't like taking what I see as a non-NTH bug as NTH so that we can get other features
17:31:50 <adamw> we usually ask for minimal possible changes for NTH stuff, but it seems silly to intentionally refuse to take tested fixes for identified regressions.
17:31:53 <tflink> but I'm not going to fight it
17:31:54 <adamw> tflink: yeah, the process kinda sucks.
17:32:04 <adamw> let's see if any of the other bugs referenced in the update make better candidates.
17:32:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=850003 ?
17:32:42 <adamw> that's a bare metal crash on boot.
17:33:27 <adamw> the other thing we can do is simply reject this as NTH, but take the latest build as the fix for 849244, which is already accepted NTH. so long as no-one complains. =)
17:34:27 <tflink> either way, I'm not sure it's worth arguing about for too much longer
17:34:36 * tflink is tempted to say just take it based on the already NTH bug
17:34:43 * nirik is fine with taking the latest, given we are likely not go... but meh
17:34:50 <adamw> okay. i guess the proper thing to do is just to evaluate this bug on its merits, really
17:35:14 * tflink is still -1 NTH on this particular bug unless I'm missing something
17:35:28 <tflink> virtio-scsi isn't the default IO bus, is it?
17:35:31 <adamw> yeah...i guess if we just go by the proper process and look at the merits of this bug, i'm -1
17:35:43 <adamw> it seems like fixing it with an update would be adequate
17:36:20 <tflink> unless you install w/ the affected kernel, in which case the VM install is hosed
17:36:55 <adamw> sure, it's easy enough to avoid that if you document it though. why are you arguing against me now? =)
17:37:23 <tflink> my rationale behind arguing against NTH is that it's a non-default VM setup
17:37:34 <tflink> I just wanted to make sure that I was right about the non-default part
17:39:04 <tflink> proposed #agreed 847548 - RejectedNTH - This bug requires a non-default VM setup in order to manifest and thus not qualified as alpha NTH.
17:39:08 <tflink> ack/nak/patch?
17:39:15 <adamw> tflink: ack
17:39:22 <jwb> ARGH...
17:39:27 <jwb> there was a netsplit or something here
17:39:33 <jwb> i missed a bunch of stuff i think
17:39:35 <jreznik> jwb: yep, netsplit
17:39:44 <adamw> jwb: you missed a bunch of process wankery.
17:39:54 <jreznik> :)
17:39:55 <tflink> yeah, that sums it up pretty well
17:39:55 <jwb> what was the last thing you saw from me?
17:39:59 <jreznik> ack
17:40:10 <tflink> jwb: "now"
17:40:16 <jreznik> jwb: [19:37] <-- jwb has left this server (*.net *.split).
17:40:33 <jwb> http://www.fpaste.org/ZUtO/
17:40:40 <jwb> that's what i was mumbling to myself then
17:40:50 <adamw> jwb: we decided the proper thing to do is just to evaluate this specific bug on its nth merits, and we're -1 on that, but we will still likely pull in the latest build and just say we're doing it for 849244, or 850003 (which i just nominated)
17:41:07 <jwb> adamw, ok, works for me
17:41:27 <adamw> tflink: i just nominated 850003, so add that to the list =)
17:42:49 <tflink> #agreed 847548 - RejectedNTH - This bug requires a non-default VM setup in order to manifest and thus not qualified as alpha NTH.
17:43:00 <tflink> #topic (850003) One machine is crashing when running kernel-PAE-3.6.0-0.rc2.git0.1.fc18.i686 but not kernel-PAE-3.6.0-0.rc1.git0.2.fc18.i686
17:43:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=850003
17:43:05 <bugb0t> Bug 850003: unspecified, unspecified, ---, kernel-maint, MODIFIED , One machine is crashing when running kernel-PAE-3.6.0-0.rc2.git0.1.fc18.i686 but not kernel-PAE-3.6.0-0.rc1.git0.2.fc18.i686
17:43:06 <tflink> #info Proposed NTH, MODIFIED
17:43:37 * tflink just noticed buggbot's name change
17:45:00 <tflink> +1 NTH
17:45:21 <nirik> +1 nth here too
17:45:21 <adamw> +1 nth, bare metal crashing on boot is bad.
17:45:30 <adamw> those cards aren't hideously obscure either, there are quite a few knocking around.
17:47:31 <tflink> proposed #agreed 850003 - AcceptedBlocker - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't too obscure, accepted as NTH
17:47:48 <jwb> if the fix for that is what i think it is, it has little to do with the card
17:47:50 <tflink> adamw: it sounds like there are other cards than the rv280, no?
17:48:05 <adamw> jwb: ah, okay.
17:48:12 <jwb> the oops is in the network stack
17:48:43 <adamw> so what is the trigger for the crash?
17:48:47 <adamw> something to do with ipv6?
17:49:48 <jwb> believe so
17:52:31 <tflink> common enough to be a blocker?
17:52:42 <tflink> or are we OK with NTH?
17:52:51 <adamw> eh, nth is fine in practice.
17:53:12 <tflink> proposed #agreed 850003 - AcceptedBlocker - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected.
17:53:16 <tflink> ack/nak/patch?
17:53:35 <jwb> what does patch mean?
17:53:58 <tflink> if you have a suggested change for the #agreed statement
17:54:16 <tflink> in practice nak and patch tend to go hand in hand, though
17:54:46 <jwb> oh.  i would  have said NTH.  bruno is the only report of this, but that's probably related to it only in koji
17:55:11 <tflink> oh, my mistake
17:55:12 <tflink> thanks
17:55:22 <adamw> ack
17:55:23 <tflink> proposed #agreed 850003 - AcceptedNTH - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected.
17:55:27 <adamw> er, ack for nth
17:55:44 <tflink> I was about to say "we are voting on NTH" until I read what I actually typed :)
17:56:41 <tflink> any other votes?
17:57:29 <jreznik> ack
17:57:47 * tflink thinks we scared almost everyone away with process
17:58:34 <tflink> well, 2 acks is going to have to be enough I suppose. can always undo later
17:58:44 <tflink> #agreed 850003 - AcceptedNTH - Bare metal crashes on boot are bad and would be nice to avoid. Hardware isn't obscure, many people could be affected.
17:58:55 <jreznik> long process :)
17:58:58 <tflink> time for some accepted blockers
17:59:09 * jreznik is getting hungry :)
17:59:27 <tflink> jreznik: yeah but some of it is protection against "well, you took that one as NTH/blocker, why not this one?"
17:59:43 <tflink> and wanting to avoid "because we said so" responses
17:59:58 <tflink> #topic (847693) repoclosure failure on 18 Alpha TC2 DVDs (pion-net)
17:59:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847693
17:59:59 <tflink> #info Accepted Blockers, ON_QA
18:00:00 <bugb0t> Bug 847693: unspecified, unspecified, ---, jvcelak, ON_QA , repoclosure failure on 18 Alpha TC3 DVDs (pion-net)
18:00:35 <adamw> there's an update for this, just needs karma and pulling into tc4.
18:01:04 <tflink> #info an update is available that should fix this bug, it needs karma and to be pulled in to tc4
18:01:53 <tflink> #topic (847694) repoclosure failure on 18 Alpha TC2 DVDs (shotwell)
18:01:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847694
18:01:53 <tflink> #info Accepted Blockers, NEW
18:01:55 <bugb0t> Bug 847694: unspecified, unspecified, ---, mclasen, NEW , repoclosure failure on 18 Alpha TC2 DVDs (shotwell)
18:02:05 <adamw> ditto for this one, now. (yay)
18:02:17 <tflink> I think we can remove this as a blocker since shotwell isn't in >=TC3, right?
18:02:44 <tflink> or do we have a new update that's not referenced in the bug?
18:03:46 <adamw> https://admin.fedoraproject.org/updates/FEDORA-2012-12406/shotwell-0.12.3-5.fc18
18:03:46 <tflink> we do have a new update that claims to fix the issue
18:03:56 <tflink> #link https://admin.fedoraproject.org/updates/FEDORA-2012-12406/shotwell-0.12.3-5.fc18
18:04:07 <adamw> yeah, we basically have two bugs on shotwell, forgot about that
18:04:24 <adamw> this one got mass-approved with all the other repoclosure bugs andre filed, but we could really just close it as a dupe of 844510
18:04:26 <tflink> not sure I follow you here
18:04:28 <adamw> shall we do that for clarity?
18:04:37 <tflink> yeah, that makes sense to me
18:04:38 <adamw> 847694 really doesn't tell us anything that 844510 didn't.
18:04:53 <tflink> #undo
18:04:53 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2415ca10>
18:05:52 <tflink> #info This bug doesn't tell us anything that #844510 doesn't already say and there is an update available to fix that bug. Closing as dupe of #844510
18:06:33 <tflink> #topic (847683) repoclosure failure on 18 Alpha TC3 DVDs (fatrat)
18:06:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847683
18:06:34 <tflink> #info Accepted Blockers, ON_QA
18:06:35 <bugb0t> Bug 847683: unspecified, unspecified, ---, jvcelak, ON_QA , repoclosure failure on 18 Alpha TC3 DVDs (fatrat)
18:07:12 <tflink> #info an update is available which claims to fix this issue - it needs testing and karma before being pulled into F18 alpha TC4
18:07:30 <adamw> it's busted
18:07:32 <adamw> see my comment on the update
18:07:40 <adamw> so we can't pull it for now. but jvcelak is aware.
18:07:55 <tflink> ot
18:08:02 <tflink> it's been unpushed
18:08:19 <adamw> brb call of nature
18:08:25 <tflink> #undo
18:08:25 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x14191850>
18:08:52 <tflink> #info update was submitted to fix this bug but didn't actually fix it. Update has been unpushed, still waiting for fix.
18:09:05 <tflink> #topic (848641) Fedora 18 Alpha TC2 fails to boot from USB stick (written by livecd-iso-to-disk)
18:09:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=848641
18:09:10 <bugb0t> Bug 848641: high, unspecified, ---, anaconda-maint-list, NEW , Fedora 18 Alpha TC2 fails to boot from USB stick (written by livecd-iso-to-disk)
18:09:11 <tflink> #info Accepted Blockers, NEW
18:10:28 <tflink> #info Some progress has been made, anaconda-dracut is currently suspected as being the problem. Waiting for more analysis and hopefully a fix since none of the supported USB media creation methods are currently working.
18:12:09 * tflink waits for adam to come back to make sure I didn't miss anything
18:13:30 <adamw> nothing new from me
18:14:38 <tflink> ok, moving on
18:14:50 <tflink> #topic (848803) Root password is not set due to missing authconfig
18:14:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=848803
18:14:50 <tflink> #info Accepted Blockers, MODIFIED
18:14:53 <bugb0t> Bug 848803: urgent, unspecified, ---, anaconda-maint-list, MODIFIED , Root password is not set due to missing authconfig
18:15:30 <tflink> it sounds like this should be ON_QA and needs verification
18:15:47 <adamw> it actually got closed, then re-opened by dan, probably incorrectly
18:16:05 <adamw> to be certain we should test a kickstart install that specifies a root password and see what happens, then re-close if it works
18:16:30 <tflink> #info This should be fixed, kickstart install needs verification that root password is set correctly before closing
18:17:12 <tflink> #topic (844510) FTBFS in Rawhide with gphoto 2.5.0
18:17:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=844510
18:17:12 <tflink> #info Accepted Blockers, ON_QA
18:17:35 <adamw> so yeah, there's an update, needs karma. worked fine for me.
18:17:46 <bugb0t> Bug 844510: urgent, unspecified, ---, mclasen, ON_QA , FTBFS in Rawhide with gphoto 2.5.0
18:17:47 <tflink> #info FTBFS issue has been fixed and an update is available. Needs karma before it's pulled in to TC4
18:18:07 <tflink> #topic (849118) firstboot doesn't show up in LXDE
18:18:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849118
18:18:07 <tflink> #info Accepted Blockers, POST
18:18:09 <bugb0t> Bug 849118: unspecified, unspecified, ---, vpodzime, POST , firstboot doesn't run, partly due to use of python-meh which has been ported to GTK+ 3
18:18:58 <adamw> so there's a patch posted for this too, waiting for review. not much we can do.
18:19:42 <tflink> #info patch for anaconda has been posted, waiting for review.
18:19:57 <tflink> #topic (840179) Latest grub2 update broke "system" theme
18:19:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=840179
18:19:58 <tflink> #info Accepted Blockers, ON_QA
18:20:02 <bugb0t> Bug 840179: medium, unspecified, ---, pjones, ON_QA , Latest grub2 update broke "system" theme
18:20:35 <tflink> #info Fix is available, update needs karma before being pulled in to TC4
18:20:46 <tflink> #topic (849012) IOError: [Errno 2] No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-p2p1'
18:20:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849012
18:20:51 <tflink> #info Accepted Blockers, MODIFIED
18:21:17 <bugb0t> Bug 849012: unspecified, unspecified, ---, rvykydal, MODIFIED , IOError: [Errno 2] No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-p2p1'
18:21:19 <tflink> #info Still waiting for patch to fix this issue
18:21:51 <adamw> why's it 'modified' then?
18:21:57 <tflink> looks like a partial patch
18:22:01 <tflink> #undo
18:22:01 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x15d5ee50>
18:22:11 <adamw> it's marked as fixed in 18.7, so i was assuming next build would get this
18:22:24 <tflink> #info partial patch has been written but still waiting for more code to complete the fix
18:22:33 <adamw> not entirely sure if comment #10 means the fix is incomplete or just a further improvement or what...
18:23:20 <jreznik> checking history
18:24:10 <adamw> anyhow, not sure there's much to discuss here, anaconda team is on the case.
18:24:10 <tflink> #undo
18:24:10 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2468e2d0>
18:24:57 <tflink> #info It's unclear whether or not this issue will be fully fixed with anaconda-18.7-1, will need testing when new build is available or clarification from anaconda devs
18:25:09 <tflink> #topic (849152) anaconda doesn't use DVD repo
18:25:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849152
18:25:10 <tflink> #info Accepted Blockers, MODIFIED
18:25:11 <bugb0t> Bug 849152: unspecified, unspecified, ---, clumens, MODIFIED , anaconda doesn't use DVD repo
18:25:40 <tflink> #info should be fixed with anaconda-18.7-1. Will need testing and karma once a new build is available
18:26:10 <tflink> #topic (849250) Not setting up a root password makes non-desktop installs impossible to access
18:26:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849250
18:26:15 <bugb0t> Bug 849250: urgent, unspecified, ---, anaconda-maint-list, NEW , Not setting up a root password makes non-desktop installs impossible to access
18:26:16 <tflink> #info Accepted Blockers, NEW
18:26:56 <tflink> doesn't sounds like there has been much movement on this
18:27:11 * tflink assumes that the anaconda devs are still discussing potential solutions
18:27:19 <adamw> yeah, might be a good idea to poke them though
18:27:25 <adamw> #action adamw to poke anaconda team about 849250
18:27:44 <jreznik> +1
18:27:52 <tflink> #info There hasn't been much movement on this yet, anaconda devs may still be discussing potential solutions, will ask for update
18:28:07 <tflink> #topic (849667) Bugreporting from anaconda doesn't work as expected
18:28:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849667
18:28:07 <tflink> #info Accepted Blockers, ON_QA
18:28:08 <bugb0t> Bug 849667: unspecified, unspecified, ---, vpodzime, ON_QA , Bugreporting from anaconda doesn't work as expected
18:28:41 <tflink> #info an update to python-meh should fix this, needs testing and karma before pulling into TC4
18:29:02 <tflink> eh, that's not quite right
18:29:14 <tflink> not sure it _can_ be verified w/o TC4
18:29:22 <tflink> #undo
18:29:22 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x158329d0>
18:29:35 <tflink> #info an update to python-meh should fix this, needs testing and karma so that it can be pushed to stable
18:29:51 <tflink> #topic (849070) Anaconda's bug reporter doesn't work
18:29:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849070
18:29:51 <tflink> #info Accepted Blockers, MODIFIED
18:29:53 <bugb0t> Bug 849070: unspecified, unspecified, ---, anaconda-maint-list, MODIFIED , Anaconda's bug reporter doesn't work
18:30:35 <tflink> #info patch has been submitted to fix this issue, waiting for it to be pulled into anaconda before it can be re-tested and karma-ed
18:30:45 <tflink> I think that's all of them
18:30:50 <tflink> anything I missed?
18:30:55 <adamw> sounds good to me
18:31:02 <tflink> #topic Open Floor
18:31:05 <adamw> not sure exactly how to karma python-meh, but i'll figure something out...
18:31:26 <tflink> Is there anything else to bring up before ending the meeting?
18:31:40 <adamw> escape plans?
18:31:57 <tflink> RUN!
18:32:35 * jreznik is running
18:32:43 * tflink plans to hide out somewhere in the caribbean for the next month or so :)
18:32:53 <tflink> wait, did I say that out loud?
18:33:05 <jreznik> ok, for go/no-go meeting? what's the process now?
18:33:17 <tflink> QA is no-go
18:33:23 <tflink> there are open, unaddressed blockers
18:33:53 <tflink> so it'll be a short go/no-go
18:34:24 <jreznik> :((( sad face :(((
18:34:40 <adamw> yeah, utterly no-go.
18:35:44 <jreznik> well in two and half hour
18:36:24 <tflink> release readiness is tomorrow, no? or do I have my dates mixed up?
18:36:40 * jreznik is new
18:37:10 <jreznik> so how's the process? as I announced the go/no-go meeting for today (or we could skip it) and then readiness?
18:37:23 <jreznik> pls educate me :) firt time, shy...
18:37:35 <tflink> IIRC, release readiness is held after the first go/no-go regardless of the state of the release
18:37:54 <tflink> to see where everyone is regarding the relese (docs etc.)
18:38:13 <tflink> but its only held once, not before every go/no-go
18:38:20 <tflink> s/before/after
18:39:01 <jreznik> so today go/no-go and if no-go, readiness is postponed?
18:39:24 <tflink> nope, readiness is held regardless of the results of go/no-go
18:39:31 <tflink> as far as I remember, anyways
18:39:34 <jreznik> sorry, too late here
18:39:38 <tflink> no worries
18:40:28 <jreznik> but for go/no-go we will meet today? is it true?
18:40:32 <tflink> yes
18:40:40 <jreznik> ok :)
18:41:05 <jreznik> thanks (I wanted to talk to rbergeron before Board mtg but seems she's not available)
18:41:27 <tflink> yeah, she knows the process better than I do :)
18:41:50 <tflink> she was here at first, said something about having a unreliable internet connection
18:42:04 <jreznik> tflink: I have the same problem today...
18:42:22 <tflink> fun times :)
18:42:42 <jreznik> well, so see qa with the verdict in two hours
18:42:54 <tflink> yep
18:43:09 <tflink> anyhow, I think that we're done here
18:43:18 * tflink sets the fuse for [0,5] minutes
18:46:44 <tflink> #info f18 alpha blocker review meeting #5 will be on 2012-08-29 @ 16:00 UTC if alpha slips
18:46:58 * tflink will send out minutes shortly
18:47:03 <tflink> Thanks for coming, everyone
18:47:06 <tflink> #endmeeting