16:00:13 <tflink> #startmeeting f19alpha-blocker-review-2
16:00:13 <zodbot> Meeting started Wed Mar 20 16:00:13 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:13 <tflink> #meetingname f19alpha-blocker-review-2
16:00:13 <zodbot> The meeting name has been set to 'f19alpha-blocker-review-2'
16:00:13 <tflink> #topic Roll Call
16:00:34 * kparal here
16:00:48 * satellit_e listening
16:01:11 <tflink> Who's ready for the always awesome and exciting blocker review?
16:01:29 * tflink is attending via hotel wifi which has been spotty all week - may disappear
16:01:36 <tflink> #chair kparal adamw
16:01:36 <zodbot> Current chairs: adamw kparal tflink
16:01:52 * jreznik is here, stayed
16:02:16 <adamw> i'm here
16:02:20 <adamw> gimme couple of minutes
16:04:20 <tflink> ok
16:04:42 <tflink> the faster we get this done, the faster I can get back to hacking :)
16:05:20 <adamw> i mean, go right ahead
16:05:22 <jreznik> and faster I can get something to eat - after fesco meeting of course
16:05:24 <adamw> but i'm just intermittent
16:05:27 <adamw> i don't mean wait on me
16:05:45 * nirik is lurking around.
16:06:44 <tflink> let's get started with the boilerplate, then
16:06:52 <tflink> #topic Introduction
16:07:06 <tflink> Why are we here?
16:07:41 <tflink> 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:07:47 <tflink> We'll be following the process outlined at:
16:07:47 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:17 <tflink> The bugs up for review today is available at:
16:08:18 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:36 <tflink> The criteria for release blocking bugs can be found at:
16:08:36 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:08:48 <tflink> Up for review today, we have:
16:08:59 <tflink> #info 11 Proposed Blockers
16:08:59 <tflink> #info 1 Accepted Blockers
16:08:59 <tflink> #info 2 Proposed Freeze Exceptions
16:08:59 <tflink> #info 1 Accepted Freeze Exceptions
16:09:28 <tflink> If there are no oobjections, we can start with the proposed blockers
16:09:43 <jreznik> let's start
16:10:34 <tflink> #topic (922988) virtio modules (and possibly others?) missing from installed system's initramfs after a Fedora 19 live (pre-Alpha TC1) install
16:10:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922988
16:10:40 <tflink> #info Proposed Blocker, anaconda, NEW
16:11:22 <adamw> looks like harald is debugging this nicely
16:12:34 <tflink> it sounds like two separate issues, though
16:12:51 <adamw> what does?
16:13:14 <adamw> the modules are missing from the installed system's initramfs because /sys isn't present in the environment when the lve install generates the initramfs.
16:13:17 <adamw> it's all one issue.
16:13:32 <tflink> ok, wasn't 100% sure
16:13:37 <adamw> "And, when I mount bind /mnt/sysimage/sys manually, while rsync syncs, the initramfs contains the proper virtio drivers."
16:14:12 <kparal> sounds as a clear blocker
16:14:47 <jreznik> kparal: if it is all about virtio and virt machines and IDE works, not sure it's alpha blocker - on the other hand there's "(and possibly others?)"
16:15:04 <tflink> hrm, still haven't quite figured out how to reference the new style criteria from IRC - this'll have to do for now
16:15:08 <kparal> SATA works too?
16:16:00 <tflink> proposed #agreed 922988 - AcceptedBlocker - Violation of the following F19 alpha release criterion: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
16:16:20 <tflink> the only technicality that comes to mind is that it sounds like this is virtio only
16:16:41 <adamw> that's kinda more than a technicality
16:16:46 <pjones> tflink: it's anything that wouldn't be in hostonly I think?
16:16:49 <adamw> it's going to work on most systems, and you can work around it in a VM relatively easily
16:16:51 <tflink> and virtual guest blocker-ness doesn't happen until beta, IIRC
16:17:02 <adamw> but yeah, I haven't really checked to see what else is missing
16:17:03 <adamw> yes
16:17:18 <adamw> we should probably diff the lsinitrd output against an f18 live install and see what's missing
16:17:25 <jreznik> good idea
16:17:40 <adamw> or we can just punt, and then it should get fixed, and we don't have to worry about it!
16:17:52 <adamw> pjones: sounds to me like harald is right and it should be a relative easyfix?
16:18:07 <adamw> in fact, his new dracut ought to paper it over anyhow.
16:18:12 <pjones> adamw: I think his answer is a bit of a hack - we should really figure out why /sys isn't mounted when it should be
16:18:22 <adamw> well I think he wanted you to do that
16:18:26 <pjones> moi?
16:18:30 <adamw> but he also wanted to make dracut safe against this problem
16:18:32 <adamw> anaconda team
16:18:39 <adamw> belt and braces, etc
16:18:50 <pjones> yeah.
16:19:11 <adamw> so yeah, i'd say let's punt, theoretically to check on the wider impact of the bug, but really so we can close it.
16:20:50 <tflink> proposed #agreed 922988 - We're not 100% clear on the impact of this bug. Once we have more data on its impact, we can make a decision WRT its impact
16:20:58 <adamw> tflink: oh zap - I just realized I didn't do secretarialization last week, sorry :( so there may be a bug or two that was already covered
16:20:59 <jreznik> could we still at least try to get that diff?
16:21:00 <adamw> ack
16:21:16 <adamw> jreznik: sure. it'd involve tweaking though, since the files will be different sizes and stuff. probably doable.
16:21:22 <tflink> wording's a bit akward but ack/nak/patch?
16:21:41 <adamw> ack
16:21:49 <adamw> /nick adamw_mustache
16:21:49 <jreznik> ack (as what I requested are that more data)
16:22:02 <tflink> I think I still have my initrd content diff script from fedup testing in f18
16:22:15 <adamw> i just called the pope, and the pope says ACK
16:22:28 <kparal> ack
16:22:31 <pjones> tflink: we really should package that someplace.
16:22:33 <tflink> #agreed 922988 - We're not 100% clear on the impact of this bug. Once we have more data on its impact, we can make a decision WRT its impact
16:23:05 <tflink> pjones: the script? yeah, I should have made it public but I don't have it with me ATM
16:23:13 * tflink makes note on todo list
16:23:56 <tflink> #topic (923459) F19 pre-Alpha TC1 network installs stop at "Starting package installation process" (anaconda is stuck in a loop between writev and recvfrom)
16:23:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=923459
16:24:02 <tflink> #info Proposed Blocker, anaconda, NEW
16:24:57 * satellit_e this may be what 19.12-1 boot iso sees
16:25:24 <adamw> satellit_e: yes, it almost certainly is.
16:25:40 <adamw> note my initial description is a bit out, it looks like anaconda is perpetually hung and it'll never complete.
16:26:26 <tflink> all the more blocker-y
16:26:58 <pjones> adamw: thus preventing all other bugs.  what a minsch.
16:27:03 <adamw> yeah, this seems pretty straightforward
16:27:07 <pjones> way to take one for the team, anaconda.
16:27:10 <adamw> =)
16:27:17 <adamw> i'm hoping that if we spin a DVD at least that'll avoid the issue
16:27:28 <tflink> proposed #agreed 923459 - AcceptedBlocker - Violates the following F19 alpha release criteria for network sources "When using the dedicated installer images, the installer must be able to use either HTTP or FTP repositories (or both) as package sources."
16:27:28 <kparal> +1 blocker
16:27:30 <kparal> ack
16:27:31 <adamw> ack
16:27:35 <jreznik> ack
16:27:40 <adamw> i think bcl is working on this one, btw.
16:27:42 <tflink> #agreed 923459 - AcceptedBlocker - Violates the following F19 alpha release criteria for network sources "When using the dedicated installer images, the installer must be able to use either HTTP or FTP repositories (or both) as package sources."
16:27:54 <tflink> #topic (922991) dracut hook pre-pivot runs before mount hook
16:27:54 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922991
16:27:54 <tflink> #info Proposed Blocker, dracut, MODIFIED
16:28:52 <tflink> sounds pretty clear-cut blockery to me
16:29:00 <adamw> ayup
16:29:02 <adamw> +1 blocker
16:29:30 <adamw> we may be able to close it, but I dunno if the build made it to a compose yet.
16:29:45 <tflink> proposed #agreed 922991 - AcceptedBlocker - Violates the following F19 alpha release criterion: "The installer must be able to download and use an installer update image from an HTTP server."
16:29:52 <tflink> ack/nak/patch?
16:29:52 <adamw> ack
16:29:56 <kparal> how is it related to update image from http server?
16:30:10 <tflink> kparal: it interferes with the ability to apply an update
16:30:14 <kparal> ah
16:30:24 <kparal> ack
16:30:26 <adamw> if by 'interfere' you mean 'break' :)
16:30:56 <jreznik> ack
16:31:41 <tflink> #agreed 922991 - AcceptedBlocker - Violates the following F19 alpha release criterion: "The installer must be able to download and use an installer update image from an HTTP server."
16:32:04 <tflink> #topic (921896) Single quote in f19 release name breaks grub2, probably other stuff
16:32:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=921896
16:32:09 <tflink> #info Proposed Blocker, fedora-release, NEW
16:32:19 <jreznik> our dear cat
16:33:27 <adamw> looks like this can be closed at least for now
16:33:28 <jreznik> (and sorry for my comment - I don't know what I was thinking about when I wrote it...)
16:33:34 <adamw> well, no, i should test first
16:33:39 <adamw> but the new fedora-release is out
16:34:25 <adamw> I don't believe this actually affects fresh installs, but the system will break when you install any update kernel
16:34:25 <jreznik> we should accept it as blocker for the evidence - and close once verified
16:35:18 <adamw> criterion "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
16:35:28 <adamw> note plural "on subsequent boots" - that's broken as soon as you update kernel.
16:35:39 <adamw> I should add a footnote to explain that!
16:36:49 <kparal> do we need to come up with a solution here? just accept it as a blocker and let's move
16:37:20 <tflink> proposed #agreed 921896 - AcceptedBlocker - Violates the following F19 alpha release criteria as soon as the kernel is updated post-install "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
16:37:31 <kparal> ack
16:37:52 <jreznik> ack
16:38:16 <adamw> ack
16:38:42 <tflink> #agreed 921896 - AcceptedBlocker - Violates the following F19 alpha release criteria as soon as the kernel is updated post-install "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
16:39:19 <tflink> #topic (919374) /var/run not created with var_run_t leading to many boot avc's
16:39:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=919374
16:39:25 <tflink> #info Proposed Blocker, filesystem, ASSIGNED
16:40:31 <adamw> so, i have not seen this in any of my testing
16:40:33 <adamw> have you guys?
16:42:30 <tflink> I haven't been able to do much testing yet
16:42:38 <kparal> I can't really say, I usually disable selinux
16:42:41 <kparal> or set it permissive
16:43:29 <tflink> do we want to take it or wait until it's been reproduced?
16:43:51 <kparal> wait a bit
16:44:23 <adamw> i definitely would want to wait, i'm not convinced by this one at all
16:44:39 <adamw> it has not affected my live installs or my f18+yum tests or my install-f19-with-f18-anaconda boxes
16:44:44 <tflink> proposed #agreed 919374 - While this sounds like it could be a blocker, we want to wait until it has been reproduced by at least one other person before accepting it as a blocker for F19 alpha
16:44:52 * jreznik talked about it with ovasik and he has no clue neither
16:44:55 <kparal> ack
16:45:01 <jreznik> ack
16:45:50 <tflink> #agreed 919374 - While this sounds like it could be a blocker, we want to wait until it has been reproduced by at least one other person before accepting it as a blocker for F19 alpha
16:45:56 <adamw> ack
16:46:18 <tflink> #topic (923501) gnome-initial-setup is not visible on first boot after install
16:46:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=923501
16:46:23 <tflink> #info Proposed Blocker, gdm, NEW
16:47:12 <adamw> so it's possible this is VM-specific, I guess
16:47:16 <adamw> but otherwise it seems pretty clear
16:48:12 <kparal> I saw this too with the old package, but I don't remember how I triggered that
16:48:46 <kparal> no, I saw something else, even the top panel was missing. just  a gray area and a cursor
16:49:39 <kparal> still, seems blockery enough
16:50:21 <tflink> thoughts on blockery-ness right now?
16:50:27 <tflink> it does sound rather blockery to me
16:50:49 <adamw> probably fine to take it for now
16:50:57 <adamw> we can take it off the list if it turns out not to happen on metal or whatever
16:51:50 <tflink> proposed #agreed 923501 - AcceptedBlocker - Violates the following F19 alpha release criterion (substituting gnome-initial-experience for firstboot) A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation.
16:52:01 <tflink> or is this initial-experience and not the gnome variant
16:52:34 <adamw> ack
16:52:38 <adamw> it's gnome-i-e.
16:52:40 <kparal> that criterion will have to be updated
16:52:41 <tflink> adamw: I thought you had to remove g-i-e from the images to make them build?
16:52:58 <adamw> tflink: no, never to make it  build
16:53:08 <tflink> #info the criteria need to be updated to cover both firstboot and gnome-initial-experience
16:53:12 <tflink> ack/nak/patch?
16:53:18 <tflink> I see 1
16:53:23 <adamw> i took g-i-e out of some images to make them *work*, but then they brought out 0.8 which was supposed to fix that, so i put it back in my images
16:53:26 <kparal> (and initial-setup)
16:53:30 <adamw> 0.8...fails differently from 0.7 =)
16:53:35 <kparal> ack
16:53:49 <kparal> btw, it's not gnome-initial-experience but gnome-initial-setup
16:53:55 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=922951 covers the other fail.
16:53:57 <adamw> kparal: doh, yeah.
16:54:00 <jreznik> tflink: btw. firstboot is now initial-setup too (maybe with the way how it will work we could call it intial setup tool?)
16:54:14 <kparal> no, firstboot and initial-setup are two different packages
16:54:18 <kparal> I talked to msivak today
16:54:31 <jreznik> kparal: he told me he renamed firstboot to initial-setup
16:54:37 <jreznik> last time I talked to him
16:54:37 <kparal> we will have 3 first-boot-setup tools in F19
16:54:57 <kparal> firstboot is for RHEL purposes and does nothing in Fedora, just flashes X screen and ends
16:55:09 <kparal> initial-setup is a new tool from anaconda team, to create users and set up system stuff
16:55:10 <tflink> 3 first-boot-setup tools?
16:55:17 <kparal> gnome-initial-setup is from the gnome team
16:55:20 <adamw> that's great!
16:55:22 <tflink> for the love of all that is holy, why?
16:55:24 <adamw> (dies)
16:55:27 <kparal> all are currently set to run on first system boot
16:55:37 <adamw> why do we have to have something called firstboot "for rhel purposes"?
16:55:40 <jreznik> but we take care only about initial-setup and for gnome gie, no?
16:55:50 <adamw> anyway, we're kinda out of topic, i guess.
16:55:52 <kparal> mclasen says he needs to talk to dcantrell to set up some way of communication between i-s and g-i-s
16:56:20 <tflink> jreznik: ack/nak/patch?
16:56:21 <adamw> kparal: i think sufficiently sophisticated systemd scripts ought to handle it. they can just conflcit.
16:56:22 <jreznik> kparal: I expected they already talked and did it :( as they need it for anaconda too... life is life...
16:56:35 <kparal> adamw: both teams want to have it running
16:56:40 <kparal> ack
16:56:44 <jreznik> ack
16:56:51 <tflink> #agreed 923501 - AcceptedBlocker - Violates the following F19 alpha release criterion (substituting gnome-initial-experience for firstboot) A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation.
16:56:53 * jreznik will try to clarify the situation
16:57:06 <adamw> kparal: either we have g-i-s win whenever gnome is installed, or we have i-s win in any case except 'only gnome is installed'.
16:57:15 <adamw> cases without gnome installed seem obvious.
16:57:23 <tflink> #topic (922951) gnome-initial-setup is enabled by default (and presently crashes)
16:57:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922951
16:57:28 <tflink> #info Proposed Blocker, gnome-initial-setup, NEW
16:57:32 <kparal> adamw: the problem is that the tools don't do the same thing, they just have some intersection
16:57:35 <adamw> i think this one can probably be closed, this was the bug in 0.7
16:57:38 <adamw> kparal: oh joy.
16:58:17 <jreznik> kparal: it's even worst if you consider some parts could be now done in anaconda too...
16:59:15 <kparal> adamw: so the crash is replaced with an empty screen, right?
16:59:25 <kparal> i.e. crash is "solved"
16:59:28 <tflink> kparal: at least it isn't crashing anymore :)
16:59:42 <adamw> kparal: well, it looks like it runs for a while then crashes. i haven't whacked abrt over the head hard enough to file the crash yet, that's what i was trying to do at the start of the meeting
16:59:57 <adamw> maybe you can test with 0.8 and confirm you then see the same as me, then close the bug?
17:00:01 <kparal> either we can merge those issues or close this one as being obsolete
17:00:08 <kparal> ok
17:00:40 <kparal> punt now, I'll confirm adam's finding
17:00:43 <kparal> findings
17:00:44 <adamw> i don't mind accepting this as a blocker, it clearly is one.
17:00:48 <adamw> it just might be fixed already. =)
17:01:12 <jreznik> not against punting it today
17:01:33 <tflink> propose #agreed 922951 - While this seems as it it would be a blocker, we suspect that it has been fixed. If it isn't fixed already, will revisit at the next meeting
17:02:58 <adamw> ack
17:03:17 <tflink> acky/nak/patch?
17:03:43 <kparal> ack
17:03:55 <tflink> #agreed 922951 - While this seems as it it would be a blocker, we suspect that it has been fixed. If it isn't fixed already, will revisit at the next meeting
17:04:14 <tflink> #topic (922885) make sure gnome-initial-setup.service doesn't start on LiveCD
17:04:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922885
17:04:19 <tflink> #info Proposed Blocker, gnome-initial-setup, POST
17:04:38 <kparal> this is committed upstream
17:05:08 <adamw> looks like it works, in the live images i've built lately.
17:05:30 <kparal> I don't think it's part of the Fedora packages yet
17:05:41 <kparal> but the patch works, if you do it inside kickstart, yes
17:05:53 <adamw> yes it is.
17:05:59 <adamw> 47 hours	Don't activate gnome-initial-setup on a live image
17:06:03 <adamw> 31 hours	Updates for 0.80.8
17:06:12 <adamw> 31 hours	Updates for 0.8
17:06:15 <adamw> https://git.gnome.org/browse/gnome-initial-setup/log/
17:06:25 <adamw> [root@adam gnome-initial-setup (master)]# yum info gnome-initial-setup
17:06:25 <adamw> Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
17:06:25 <adamw> Available Packages
17:06:25 <adamw> Name        : gnome-initial-setup
17:06:25 <adamw> Arch        : x86_64
17:06:26 <adamw> Version     : 0.8
17:06:28 <adamw> I rest my case!
17:06:50 <kparal> oh great
17:06:57 <adamw> so, we can close it.
17:07:06 <kparal> I'd rather verify it first
17:07:11 <adamw> i already have.
17:07:11 <jreznik> kparal: +1
17:07:14 <adamw> :P
17:07:15 <kparal> ok, close
17:07:17 <jreznik> ok, in that case
17:07:46 <tflink> #info this has already been fixed, verified and will be closed
17:10:17 <tflink> #topic (922955) GNOME Shell fails to start if gnome-screensaver is not installed (it is not in our default groups)
17:10:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922955
17:10:22 <tflink> #info Proposed Blocker, gnome-shell, NEW
17:11:15 <kparal> clear blocker
17:11:33 <adamw> yeah, i'd say so.
17:11:35 <adamw> oh
17:11:56 <adamw> another one that can be closed
17:11:56 <jreznik> shouldn't this hit auto-blocker too?
17:12:05 <adamw> jreznik: no, auto-blocker is pretty conservative.
17:12:18 <tflink> is it?
17:12:26 <adamw> we have gnome-shell 3.7.92 in current f19 and it fixes the bug (verified, the live image i'm running right now has no gnome-screensaver and shell runs)
17:12:32 <tflink> the alpha criteria only talks about being able to boot to a VT
17:12:51 <adamw> er, no they don't.
17:13:00 <adamw> "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot. "
17:13:02 <adamw> we just cited it earlier :)
17:13:59 <adamw> but anyway, we can close this. move on
17:14:40 <tflink> shell != firstboot
17:15:08 <tflink> hrm, these things seem to conflict
17:15:38 <adamw> tflink: that criterion doesn't say firstboot has to work.
17:15:47 <adamw> it says logging into a desktop as the user created during firstboot has to work.
17:15:59 <tflink> or I can't read
17:16:05 <adamw> .fire tflink
17:16:06 <zodbot> adamw fires tflink
17:16:13 <adamw> yay! the bot made it here too!
17:16:21 <tflink> I'm reading the one _without_ graphical packages
17:16:31 <tflink> anyways ... close or accept?
17:16:33 <adamw> close
17:16:50 <tflink> #info this bug has been fixed and will be closed shortly
17:17:05 <tflink> #topic (917246) gdm-simple-slave crashes on login attempt
17:17:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=917246
17:17:06 <tflink> #info Proposed Blocker, gnome-shell, NEW
17:17:14 * tflink blames the psyco donuts
17:17:25 <tflink> and poor spelling on my part
17:19:25 <adamw> so I fixed *a* bug here
17:19:35 <adamw> mathieu's case seems to be getting complicated, though
17:19:53 <tflink> adamw: the bootiso case?
17:20:01 <tflink> er, the bootiso case is the one which is fixed?
17:20:11 <kparal> I think mathieu is stopped by non-related bugs
17:20:19 <kparal> and the core bug was "fixed" by adjusting comps
17:20:20 <adamw> the thing I fixed is that gnome-session-xsession needs to be present for gdm to log in to shell.
17:20:53 <tflink> kparal: didn't mathieu file the bug before it was somewhat hijacked?
17:21:08 <kparal> well, "I just boot it, and all I get is the GNOME fail screen."
17:21:15 <kparal> that's the original description
17:21:45 <kparal> which seem more like the g-s-i issue
17:21:55 <kparal> that we already discussed
17:22:16 <adamw> the xsession bug was clearly a blocker, but this report is pretty confused.
17:23:51 <tflink> so what do we want to do about it? I'm not 100% clear what's going on ATM
17:24:03 <tflink> it kind of sounds like there is another issue in here, somewhere though
17:24:23 <adamw> there does seem to be something going on with plymouth for some people
17:24:34 <adamw> we can just declare this to be the bug for the xsession issue?
17:24:46 <tflink> either way works for me
17:24:53 <kparal> adamw: +1
17:25:01 <tflink> ask for a new bug to be created for whatever plymouth issue people are hitting?
17:25:03 <adamw> ask mathieu to file new for what he's seeing now
17:25:09 <adamw> yeah
17:25:44 <adamw> so I added xsession to comps, but there's some reasonable input that may not be the best thing to do
17:25:51 <adamw> so we could accept it as a blocker and ask desktop team if they want to change the fix
17:26:09 <adamw> +1 blocker on the xsession issue anyhow
17:26:34 <tflink> is it close-able or are we still waiting on it?
17:27:09 <adamw> like i say, i'd leave it open and check if we want to change the fix
17:27:13 <adamw> the comps fix will *work*, though
17:27:30 <jreznik> seems reasonable
17:27:34 <jreznik> (for now0
17:27:36 <jreznik> )
17:28:57 <tflink> proposed #agreed 917246 - AcceptedBlocker - Violates the following F19 alpha release criterion: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:29:17 <tflink> ack/nak/patchy?
17:30:03 <kparal> ack
17:30:07 <adamw> ack
17:30:27 <tflink> #agreed 917246 - AcceptedBlocker - Violates the following F19 alpha release criterion: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:30:32 <tflink> ooh, last blocker!
17:30:46 <tflink> #topic (921914) Lorax should disable dracut's 'hostonly' mode when generating images
17:30:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=921914
17:30:52 <tflink> #info Proposed Blocker, lorax, NEW
17:32:17 <adamw> i think this can be closed now
17:32:20 <kparal> if harald wants to patch something, is it necessary to propose it as blockers? we're not yet in freeze
17:32:27 <tflink> this would cause the install media to have only the drivers used by the machine which built the image, no?
17:32:28 <kparal> he can just commit it
17:32:36 <tflink> not to lorax, I don't think
17:33:26 <adamw> tflink: basically.
17:33:29 * tflink isn't against just closing it if its fixed, though
17:34:29 <tflink> is it fixed and closable?
17:34:32 * adamw trying to ping bcl, but he's not replying
17:34:38 <adamw> i'm about 99% sure that 19.1 fixes it
17:34:57 <adamw> but it might be safest just to accept and i can close it async
17:36:11 <adamw> <bcl> adamw: yeah, that seems to be working fine now.
17:36:15 <adamw> so, let's close it.
17:36:40 <tflink> #info 921914 has been fixed and can be closed
17:36:53 <tflink> ok, that's all of the proposed blockers on my list
17:37:04 <tflink> on to the FEs
17:37:28 * tflink is skipping the one we rejected last week (894110)
17:37:32 <tflink> #topic (922335) enter not accepted in unlock screen anymore
17:37:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922335
17:37:32 <tflink> #info Proposed Freeze Exceptions, gnome-shell, NEW
17:38:19 <tflink> this doesn't feel all that alpha-FE-ish to me
17:38:27 <tflink> annoying, yes
17:38:31 <tflink> FE, not so much
17:38:40 <tflink> slightly -1 but I won't fight anyone about it
17:39:03 <adamw> -1, but it's fixed now anyway.
17:39:32 * adamw closes
17:39:35 <adamw> i'm on a closin' spree, ma!
17:40:03 <tflink> proposed #agreed 922335 - This isn't severe enough to take as a FE for F19 alpha as the unlock screen still works
17:40:13 <tflink> #info note that this has already been closed
17:40:55 <tflink> ack/nak/patch?
17:42:14 <tflink> anyone still there?
17:42:28 * kparal reads back
17:42:29 <tflink> eh, it's been closed already - good enough
17:42:35 <adamw> i was assuming the #info closed things
17:42:42 <kparal> even if  you try to log in, Enter doesn't work
17:42:48 <tflink> On to the one accepted blocker
17:43:05 <kparal> ok, let's move on
17:43:08 <tflink> #topic (919935) enblend FTBFS due to doc/texinfo related issues
17:43:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=919935
17:43:08 <tflink> #info Accepted Blocker, enblend, NEW
17:43:45 <tflink> it seems like this is progressing and doesn't really require anything from us
17:44:05 <adamw> yeah
17:44:12 <adamw> and we always have the option of just leaving it out
17:44:17 <adamw> we may want to do that for tc1 to get a testable image
17:44:42 <jreznik> "We've worked-around the texinfo issue"
17:44:49 <jreznik> so is it still blocking?
17:44:53 <tflink> when is TC1 due? tomorrow?
17:45:43 <jreznik> it would be great to have it tomorrow
17:46:08 <adamw> i was aiming for today
17:46:31 <adamw> jreznik: it's still blocking as long as it ftbfs
17:46:36 <adamw> which appears to still be the case
17:46:56 <tflink> #info this is still being worked out, leaving out kipi-plugins from the TC1 build is an option
17:47:19 <jreznik> adamw: true, I thought the workaround was applied rex was talking about
17:47:36 <jreznik> and it still fails
17:48:34 <adamw> yeah, it fails on something else
17:49:28 <tflink> but either way, nothing else is needed from us in the context of the blocker process, I don't think
17:50:04 <adamw> nope
17:50:36 <tflink> which brings us to the end of my list
17:50:43 <tflink> and ...
17:50:47 <tflink> #topic Open Floor
17:51:25 <tflink> #info the next version of the blocker tracking app will be hitting fedora infra staging soon (hopefully this friday)
17:51:53 <tflink> the hostname of the tracking app will be in flux at some point in the next couple of weeks but I'll send out an email when that happens
17:52:13 <tflink> anything else that needs to be brought up?
17:52:42 <adamw> what's the status on the blocker filing page?
17:53:09 <tflink> pretty much done, waiting on infra stuff
17:53:30 <tflink> assuming that we're still allowed to deploy an app which is using old-style FAS instead of the new openid stuff
17:53:33 <tflink> that isn't clear yet
17:54:13 <tflink> at this point, the code isn't an issue - it's getting to the point where we don't need a self-signed cert for https that is the issue
17:54:48 <tflink> so getting staging up and running is the next step in that direction
17:56:02 <tflink> if there's nothing else, I'm setting the fuse for 5 minutes
17:58:35 <adamw> okay
17:58:48 <adamw> don't think I have anything else, i'll work on trying to get as many bugs as possible fixed today
18:00:30 <jreznik> thanks guys! and fesco...
18:01:12 * tflink will send out minutes shortly
18:01:22 <tflink> thanks for coming, everyone!
18:02:38 <tflink> #endmeeting