16:59:40 <roshi> #startmeeting F21-blocker-review
16:59:40 <zodbot> Meeting started Wed Jul  9 16:59:40 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:59:53 <roshi> #meetingname F21-blocker-review
16:59:53 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:59:58 <roshi> #topic Roll Call
17:00:09 * pschindl1 is here
17:00:11 <jreznik> my hopes I will never have to join this channel no more are ruined now!
17:00:12 <roshi> so who's here for some reviewing goodness?
17:00:34 <roshi> blockers dash hopes and destroy dreams :)
17:00:40 * kparal is here
17:00:49 * roshi is obviously here
17:01:06 * nirik is lurking, but also in fesco meeting when it starts.
17:01:09 <roshi> #chair kparal tflink pschindl1 jreznik
17:01:09 <zodbot> Current chairs: jreznik kparal pschindl1 roshi tflink
17:01:12 <kparal> btw, why is it an hour later than usual?
17:01:22 <roshi> DST?
17:01:26 <roshi> I dunno
17:01:28 <jsmith> .hellomynameis jsmith
17:01:29 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
17:01:52 * nanonyme is lurking but does not remember if he has any formal position anyway; probably not :)
17:01:57 <roshi> I just copied the last review notice I sent out
17:02:18 <roshi> do we have a volunteer for secretary duty?
17:03:33 <kparal> ok, for the next time I proposed move it to 16 UTC, because we have summer time now :)
17:03:47 <kparal> we usually stick with local time
17:03:58 <roshi> works for me
17:04:26 <roshi> I think there might be discussion on changing the time, since mattdm and some other fesco people might be interested in coming to these
17:04:51 <roshi> ok, let's get started
17:04:55 * lsm5 is lurking
17:05:08 <roshi> #topic Introduction
17:05:08 <roshi> Why are we here?
17:05:08 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:05:12 <roshi> #info We'll be following the process outlined at:
17:05:15 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:05:17 <roshi> #info The bugs up for review today are available at:
17:05:20 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
17:05:22 <roshi> #info The criteria for release blocking bugs can be found at:
17:05:25 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
17:05:28 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
17:05:46 <roshi> onto the first bug
17:06:06 <roshi> #topic (1111417) anaconda should depend on NetworkManager-wifi
17:06:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1111417
17:06:08 <roshi> #info Proposed Blocker, anaconda, ASSIGNED
17:07:19 <roshi> looks like this is well on it's way to being fixed
17:07:37 <jreznik> yep
17:07:38 <jsmith> +1 for blocker
17:08:14 <roshi> as it's almost fixed already - I could go either way
17:08:15 <kparal> reading the criterion, what exactly is "a dedicated installer image"?
17:08:19 <kparal> is it netinst?
17:08:32 <tflink> not sure that's 100% defined yet
17:08:39 <roshi> I think it's everything but cloud, since that doesn't really *install*
17:09:10 <kparal> anyway, +1
17:09:19 <pschindl1> +1 from me too
17:09:23 <roshi> but yeah - I don't think it's defined as granular as we'll need it
17:09:34 <jreznik> at least server I'd say
17:09:40 <jreznik> +1
17:09:45 <jsmith> Is it worth adding a criterion around "wireless and wired" interfaces for network installation?
17:10:36 <kparal> depends whether we need that separation
17:10:52 <kparal> at the moment we consider it equivalent, I think
17:11:28 <roshi> proposed #agreed - 1111417 - AcceptedBlocker - Installation media should have access to wireless interfaces to satisfy Alpha Criterion "Remote Package Sources"
17:11:48 <roshi> oh, and who is being secretary today?
17:11:49 <pschindl1> ack
17:12:11 * kparal can't volunteer today, might leave early
17:12:14 <kparal> ack
17:12:17 <roshi> no worries
17:12:43 <roshi> any more acks?
17:13:46 <tflink> ack
17:13:59 <jsmith> ACK
17:14:35 <roshi> #agreed - 1111417 - AcceptedBlocker - Installation  media should have access to wireless interfaces to satisfy Alpha  Criterion "Remote Package Sources"
17:14:50 <roshi> moving on
17:14:52 <roshi> #topic (1114774) bootloader.write failed: failed to set new efi boot target, system is not bootable
17:14:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1114774
17:14:57 <roshi> #info Proposed Blocker, anaconda, NEW
17:15:44 <roshi> it occurs to me that we might want to add the different products to bz sometime in the future
17:16:49 <kparal> is this the famous nvram exhaustion bug?
17:16:59 <roshi> I think it might be
17:18:49 * tflink is doing secretrialization, btw
17:18:52 <roshi> nah - I think this is just related
17:18:56 <roshi> thanks tflink :)
17:19:59 <roshi> has anyone else run into this?
17:20:18 <kparal> so, I'd really like to see this fixed - grub config files should be generated even if nvram write fails
17:20:24 <roshi> for sure
17:20:25 <kparal> but I don't think it's Alpha material
17:20:47 <pschindl1> If it causes non-bootable installs it should be alpha blocker
17:20:53 <roshi> it needs to be fixed, but it doesn't seem to be affecting all the installs or even the typical use cases
17:21:08 <kparal> pschindl1: but only for selected systems, and the cause is in broken uefi firmware
17:21:39 <roshi> right - but normally pschindl1 is spot on for blockeriness
17:21:41 <kparal> we should do our best to work around it, but it affects only someone
17:21:42 <roshi> IMO
17:21:48 <kparal> at least that's my understanding
17:22:01 <nanonyme> How wide is this expected to be, btw?
17:22:26 <roshi> though cmurf does have a point at the end of comment 9
17:22:49 <roshi> it seems anaconda has some nvram issues
17:23:23 <roshi> I'd say punt to figure out how widespread this is
17:23:29 <jreznik> again?
17:24:13 <roshi> I can't tell how many systems this effects
17:24:17 <roshi> but that's just me
17:24:18 <jreznik> but for me, it doesn't sound like alpha, at least with info provided
17:25:07 <kparal> I'd say reject and re-evaluate if it turns out to be affecting multiple systems
17:25:20 <roshi> makes sense
17:25:35 <roshi> we're early enough in the cycle for it to be re-evaluated :p
17:25:59 <roshi> so, -1 with re-apply if there's more systems affected
17:26:01 <roshi> for me
17:27:09 <roshi> proposed #agreed - 1114774 - RejectedBlocker - This bug seems to only affect a small number of systems. If it's shown to affect more systems, we can re-evaluate it.
17:27:30 <nanonyme> Sounds reasonable to me
17:27:40 <roshi> -1 from me, kparal and jreznik is what I was counting
17:27:45 <kparal> ack
17:27:49 <pschindl1> ack. I will try to reproduce it on our efi machine.
17:28:04 <roshi> #agreed - 1114774 - RejectedBlocker - This bug seems to only affect a small number of systems. If it's shown to affect more systems, we can re-evaluate it.
17:28:27 <roshi> and on we go
17:28:29 <roshi> #topic (1109603) dracut unable to boot 3.16 most of the time
17:28:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1109603
17:28:29 <roshi> #info Proposed Blocker, cloud-initramfs-tools, NEW
17:28:48 <tflink> pschindl1: isn't that one of the systems that has been affected by nvram exhaustion issues in the past?
17:30:14 <kparal> tflink: what system do you refer to?
17:30:30 <pschindl1> tflink: yes, it is
17:30:33 <kparal> we have one in the office which was often affected before the kernel patch
17:31:32 <tflink> kparal: the amd asus box
17:31:51 <kparal> tflink: yes, that's the one
17:32:36 <kparal> so, this bug seems to affect only ARM?
17:32:46 <kparal> the system sometimes fails to boot
17:33:05 <roshi> does this bug still show up with the latest kernels in rawhide (rc4 iirc)
17:33:11 <roshi> ?
17:33:21 <kparal> that's not there, but we can still decide
17:33:37 <nanonyme> Sounded based on bug that it turned random after early 3.16's anyway
17:33:45 <roshi> yeah
17:33:50 <roshi> that's what I was reading
17:34:02 <roshi> but yeah kparal, it looks like only arm
17:34:14 <kparal> still, ARM is a primary architecture now
17:34:19 <roshi> yup
17:34:20 <kparal> so it seems to qualify
17:34:28 <nanonyme> How critical is that dracut-module-growroot, btw?
17:34:30 <roshi> do we block on "it randomly does foo?"
17:34:52 <kparal> it depends on how often
17:35:05 <roshi> I'm +1 (partially because I have a machine that randomly boots as well)
17:35:10 <kparal> 2 people confirming seems "often enough"
17:35:21 <roshi> yeah - that's what I was thinking
17:35:21 <nanonyme> Since sounded based on bug removing it made bug disappear completely. Looks like it's something that resizes root after first boot. I think I'm +1 regardless though
17:35:34 <kparal> How reproducible:
17:35:34 <kparal> Most of the time
17:36:07 <kparal> +1 blocker
17:36:39 <nanonyme> Well, according to comments reproducibility changed after initial report
17:38:09 <roshi> proposed #agreed - 1109603 - AcceptedBlocker - Installed systems need to be able to boot according to the Alpha Criteria "Expected installed system boot behavior"
17:38:39 <kparal> nanonyme: I understood it was caused by having nodebug kernel
17:38:39 <roshi> true nanonyme - but if it stops manifesting itself, then the blocker can be closed as fixed
17:38:50 <kparal> ack
17:38:57 <nanonyme> kparal, oh, I misunderstand then. I understood it was caused by a newer kernel
17:38:59 <nanonyme> ack
17:39:15 <roshi> #agreed - 1109603 - AcceptedBlocker - Installed systems need to be able to boot according to the Alpha Criteria "Expected installed system boot behavior"
17:39:36 <roshi> pull!
17:39:37 <roshi> #topic (1116450) Can't login to fresh rawhide installation (2014-07-04) if SELinux is enforcing
17:39:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116450
17:39:43 <roshi> #info Proposed Blocker, filesystem, NEW
17:41:30 <roshi> I haven't done an install with a recent rawhide image, but this seems like a clear blocker
17:41:36 <roshi> +1
17:41:43 <nanonyme> Well, I'm currently IRCing from an affected system. +1
17:41:48 <kparal> +1
17:42:15 <roshi> it actually violates two criterion, since the workaround forces you to break the SELinux Configuration criteria
17:42:19 <nanonyme> This is not just for first-time installs but also upgrades
17:43:06 <nanonyme> Just FWIW
17:43:31 <nanonyme> (will be debugging further once I get back from cabin)
17:43:48 <roshi> proposed #agreed - 1116450 - AcceptedBlocker - SELinux blocking login violates the Alpha Crierion "Expected installed system boot behavior"
17:43:52 <roshi> good to know nanonyme
17:43:58 <kparal> ack
17:44:01 <pschindl1> ack
17:44:23 <roshi> #agreed - 1116450 - AcceptedBlocker - SELinux blocking login violates the Alpha Crierion "Expected installed system boot behavior"
17:44:44 <roshi> moving on...
17:44:45 <roshi> #topic (1116478) [abrt] gnome-initial-setup: gdk_window_hide(): gnome-initial-setup killed by SIGSEGV
17:44:48 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116478
17:44:51 <roshi> #info Proposed Blocker, gnome-initial-setup, NEW
17:45:07 <nanonyme> roshi, either that or I'm seeing a sister bug that's roughly the same. I'll be out of here tomorrow, will be able to go more thoroughly through these then
17:45:21 <roshi> sounds good
17:45:28 <roshi> you want an action item for it?
17:46:29 <roshi> +1 for this bug
17:46:36 <nanonyme> Not with this meeting, I think
17:46:50 <pschindl1> It is more nice to have I thing, there is quite easy work around.
17:46:59 * roshi had never given an #action in a blocker meeting - wanted to see what it felt like :p
17:47:02 <kparal> +1
17:47:14 <nanonyme> pschindl1, yes, enforcing=0 does miracles
17:47:17 <roshi> true pschindl1 - but the criteria is pretty clear
17:47:32 <roshi> or are you talking about the last bug?
17:47:53 <pschindl1> no, I was talking about g-i-s
17:47:58 <nanonyme> Oh, sorry
17:48:07 * oddshocks pops in late, just got back from a roadtrip
17:48:17 <oddshocks> roshi: thanks for the invite
17:48:30 <roshi> not to mention having to reboot from a fresh install would lead to a bad first time user experience :)
17:48:37 <roshi> np oddshocks glad to have you aboard
17:48:53 <roshi> https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting for info on what's going on and whatnot
17:49:00 <roshi> if you want it :)
17:49:20 <roshi> so we've got two +1; anybody else?
17:49:22 <pschindl1> But I'm ok with blocker, it really violates criteria
17:49:33 <nanonyme> Sounds like a +1 to me
17:49:33 <pschindl1> so +1
17:49:54 <jsmith> +1 from me
17:50:21 <roshi> proposed #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion
17:51:01 * oddshocks clicks
17:51:05 <pschindl1> ack
17:51:09 <kparal> roshi: might be good to add a short excerpt of that particular criterion into #agreed
17:51:17 <kparal> otherwise ack, of course
17:51:41 <roshi> I can do that - was thinking having the criteria to reference was good enough
17:52:11 <jsmith> ACK
17:52:13 <roshi> proposed #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:52:32 <kparal> ack
17:52:34 * roshi always did that during the secretarial work
17:53:03 * roshi takes nothing as continued acks
17:53:08 <roshi> #agreed - 1116478 - AcceptedBlocker - This is a clear violation of the "Expected installed system boot behavior" Alpha Criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:53:15 <kparal> unfortunately there is a length limit in irc, so sometimes it needs to be shortened. but it's  better to have it there
17:53:57 <roshi> oddshocks, the basic workflow is: look at bug, compare to criteria, vote +1/-1 if it violates the criteria, then ack/nack on the proposed #agreed
17:54:06 <roshi> and next bug is....
17:54:22 <roshi> #topic (1099581) 'pyanaconda.timezone.TimezoneConfigError' after completing initial-setup
17:54:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1099581
17:54:28 <roshi> #info Proposed Blocker, initial-setup, VERIFIED
17:54:34 <kparal> verified?
17:54:39 <kparal> we can skip that
17:54:43 <roshi> yup
17:54:53 <roshi> didn't see that until I pasted it
17:55:06 <roshi> moving on
17:55:07 <roshi> #topic (1115120) cryptsetup-1.6.5-1.fc21 breaks booting when using luks partitions
17:55:10 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1115120
17:55:13 <roshi> #info Proposed Blocker, kernel, ASSIGNED
17:55:31 <pschindl1> +1
17:56:20 <oddshocks> roshi: cool, thanks
17:56:26 <roshi> I don't see anyting about luks in the alpha criteria
17:56:48 <brunowolff> I quoted the passage I think applies in the ticket.
17:57:13 <pschindl1> ah, sry I reacted on the wrong bug, my fault
17:57:48 <kparal> brunowolff: is it specific to your system or does it affect most people with encrypted /home?
17:57:59 <roshi> true brunowolff
17:58:02 <brunowolff> If you set up encrypted partitions during install, the machine should boot.
17:58:12 <roshi> yeah - clear +1 IMO
17:59:20 <pschindl1> ok +1 - "In all of the above cases, if any system partitions were encrypted as  part of the installation, the boot process must prompt for the  passphrase(s) and correctly unlock the partition(s) when provided with  the correct passphrase(s). " from Expected installed system boot behavior
17:59:27 <kparal> brunowolff: ?
17:59:30 <nanonyme> +1; is it just me of does this seem like a SELinux bug?
18:00:20 <brunowolff> The encrypted partitions work OK in early boot, but mounting them in late boot fails. I am not sure if luks is resetup in a way that would not work in late boot for /. Things fail when it gets to /home.
18:01:20 <brunowolff> All of the machines that were broken for me have /home as a separate partition.
18:01:25 <roshi> I don't know that this would be related to selinux nanonyme - but then again, setenforce 0 fixes all kinds of things I wouldn't expect it to
18:01:31 <nanonyme> IOW the discussion in the bug escalated to SELinux policies on certain cryptsetup files
18:02:01 <brunowolff> However, for blocker purposes I think not having /home work when it is a separate encrypted partition is still a blocker.
18:02:03 <kparal> I understand there are multiple broken machines, so +1
18:02:07 <nanonyme> I'll just shut up, not related to blockerness
18:03:06 <brunowolff> My understanding from the bug is that the real fault is a kernel bug in labelling a socket. The socket shows up as unlabelled when it should have a label.
18:03:57 <roshi> proposed #agreed - 1115120 - AcceptedBlocker - This violates the encryption subsection of the "Expected installed system boot behavior": if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s)...
18:04:01 <nanonyme> (ie re-iterating that yes, I think it's a blocker)
18:04:11 <brunowolff> I see the probelm on 3 similarly set up machines (though the hardware is significantly different between them).
18:04:15 <jsmith> ACK
18:04:32 <kparal> ack
18:04:35 <nanonyme> ack
18:04:56 <roshi> #agreed - 1115120 - AcceptedBlocker - This violates the encryption subsection of the "Expected installed system boot behavior": if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s)...
18:05:06 <roshi> the next one is an arm bug
18:05:06 <roshi> #topic (1115905) Segfaults on ARM
18:05:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1115905
18:05:07 <roshi> #info Proposed Blocker, libgit2, NEW
18:06:46 <kparal> I'm missing any substantial info on what crashes
18:06:55 <kparal> the fact that the unit tests fail is not an alpha blocker
18:07:03 <kparal> if git crashes, it's not an alpha blocker
18:07:37 <roshi> yeah - disabling failing tests doesn't equate to blocker status
18:07:47 <kparal> so it seems like -1 and ask for reason why it should be an alpha blocker
18:07:49 <roshi> and it's not clear what's failing other than the tests
18:08:14 <pwhalen> Ive asked Peter for clarification on this one
18:08:40 <pwhalen> I've not run into it
18:09:00 <jsmith> Agreed -- not sure it's a blocker, but disabling unit tests is not the right answer
18:09:05 <roshi> proposed #agreed - 1115905 - RejectedBlocker - It's not clear in the bug why this was nominated as a Alpha Blocker. Please provide reasoning and reapply.
18:09:06 <jsmith> (especially with ARM being a primary arch now)
18:09:17 <jsmith> ACK
18:09:20 <pschindl1> ack
18:09:22 <pwhalen> ack
18:09:22 <kparal> ack
18:09:56 <roshi> #agreed - 1115905 - RejectedBlocker - It's not clear in the bug why this was nominated as a Alpha Blocker. Please provide reasoning and reapply.
18:10:25 <roshi> almost done folks, only 5 more blockers to go and one FE
18:10:26 <roshi> #topic (1019454) fatal: RPC failed at server.  There is no Hardware named 'armv7l'
18:10:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1019454
18:10:32 <roshi> #info Proposed Blocker, libreport, NEW
18:10:38 <pwhalen> this is closed, sorry for not updating the bz
18:10:58 <roshi> that might have been one of the quickest blocker bug reviews ever :)
18:11:03 <roshi> moving on then
18:11:15 <roshi> #topic (1052317) selinux-policy preventing login through sddm and ssh
18:11:18 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1052317
18:11:21 <roshi> #info Proposed Blocker, selinux-policy-targeted, NEW
18:12:29 <kparal> is this the same as the gdm+selinux bug?
18:12:39 <roshi> looks like it could be
18:13:08 <roshi> they seem pretty similar - mislabeling things
18:13:14 <roshi> the workaround is the same
18:13:56 <kparal> it's not clear whether this affects fresh installs
18:14:17 <kparal> it has to affect fresh installs in order to be alpha blocker
18:14:22 <roshi> yeah
18:14:27 <kparal> so, either punt or reject
18:14:29 <roshi> danofsatx-work: you around?
18:14:45 <kparal> I'd punt and ask for confirmation about fresh installs
18:15:00 <roshi> I concur
18:15:08 <roshi> without that detail there isn't a good way to know
18:15:16 <pschindl1> I'd punt too. I can try it tomorrow.
18:16:27 <roshi> proposed #agreed - 1052317 - Punt - It's not clear if this affects fresh installs (which would make it qualify for Alpha Blocker), please provide details on if this manifests on fresh installations.
18:16:36 <pwhalen> fresh installs are affected, installed this morning and couldnt log in until a relabel
18:16:43 * pwhalen is distracted
18:16:55 <roshi> you mean I wrote all that for nothing pwhalen ?
18:16:57 <roshi> :p
18:17:04 <pschindl1> :D
18:17:07 <pwhalen> sorry
18:17:12 <roshi> if it affects fresh installations then it's a +1 from me
18:17:20 <roshi> but someone should update the bug to reflect that
18:17:24 <pwhalen> yes, believe satellite also reported
18:17:31 <kparal> +1
18:17:34 <pwhalen> +!
18:17:34 <pschindl1> +1
18:17:36 <pwhalen> +1
18:17:42 <nanonyme> +1
18:18:10 <jreznik_q102> +1
18:19:13 <roshi> proposed #agreed - 1052317 - AcceptedBlocker - This violates the Alpha Criterion "Expected installed system boot behavior": A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation...
18:19:22 <kparal> ack
18:19:28 <pschindl1> ack
18:19:29 <pwhalen> ack
18:19:34 * roshi sees pwhalen trying to pad the votes there...
18:19:41 <pwhalen> :)
18:19:49 <roshi> #agreed - 1052317 - AcceptedBlocker - This violates the Alpha Criterion "Expected installed system boot behavior": A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation...
18:20:13 <roshi> onward and upward!
18:20:14 <roshi> #topic (1116651) systemd-215 breaks livecd-tools with /etc/resolv.conf handling
18:20:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116651
18:20:20 <roshi> #info Proposed Blocker, systemd, NEW
18:20:54 <tflink> bah, I'm trying to do too many things @ the same time - thought the punt was accepted
18:21:27 <roshi> it was, then pwhalen went and broke all the things with his accurate input
18:21:45 <roshi> :)
18:23:26 <pwhalen> trying to keep it exciting
18:23:34 <roshi> haha
18:23:39 <roshi> it's working
18:24:14 <roshi> TNT's Summer New Drama "Fedora Blocker Review Meetings"
18:24:23 <roshi> er, new summer drama, w/e
18:24:34 <kparal> it's always fun to read discussions with lennart involved
18:25:01 <roshi> lol
18:25:27 <kparal> so, honestly, I don't know how to vote on this
18:25:36 <kparal> I'm not sure whether it concerns systemd anaconda or livecdtools
18:25:50 <kparal> yes, it's a blocker if TC1 can't be composed
18:25:52 <roshi> ...yes?
18:26:06 <roshi> it seems that has been patched and is building
18:26:07 <pwhalen> i would agree
18:26:08 <roshi> aiui
18:26:09 <kparal> so if that's the correct bug to make a blocker of, let's make it a blocker
18:26:25 <roshi> the live images all seemed to work looking at releng-dash this morning
18:26:25 <kparal> and let them resolve their disputes until it works again
18:26:48 <kparal> roshi: in that case we might not need to vote on this
18:27:09 <roshi> workstation-armhfp(raw) was the only fail as of 5 hours ago
18:27:16 <roshi> so I think we can just move on
18:27:29 <roshi> er, 6 hours ago
18:27:35 * roshi can type, he promises
18:27:41 <pschindl1> yep, all live cds seems to be built. So the problem was resolved.
18:27:48 <roshi> moving on then
18:28:02 <kparal> so let's suggest there to drop the blocker nomination
18:28:12 <kparal> if the building process works now
18:28:50 <pschindl1> https://apps.fedoraproject.org/releng-dash/#livecds here is the list of livecds and they looks quite built to me :)
18:28:58 <roshi> proposed #agreed - 1116651 - RejectedBlocker - This seems to be resolved for now. If it comes up again please reapply for blocker status.
18:29:10 <roshi> yeah - that's where I looked too pschindl1
18:29:14 <pschindl1> ack
18:29:18 <pwhalen> ack
18:29:40 <kparal> ack
18:29:41 <roshi> #agreed - 1116651 - RejectedBlocker - This seems to be resolved for now. If it comes up again please reapply for blocker status.
18:29:52 <roshi> now moving on :)
18:29:55 <roshi> #topic (1044778) wandboard uboot missing serial line speed in console environment variable
18:29:58 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1044778
18:30:00 <roshi> #info Proposed Blocker, uboot-tools, NEW
18:30:35 <roshi> looks like this is just the wandboard?
18:30:57 <pwhalen> i may have been over zealous with blocker nomination, this affects one board and can be worked around. dgilmore is going to fix this before release
18:31:17 <kparal> pwhalen: kernel messages are not shown, but you can log in?
18:31:37 <pwhalen> if you're using a display, it should work.. serial.. not so much
18:32:09 <roshi> so this is basically fixed already pwhalen?
18:32:14 <kparal> " A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. "
18:32:22 <kparal> so I think this would apply
18:32:34 <roshi> is it all arm, or one board in the arm ecosystem?
18:32:41 * roshi isn't clear on that line
18:32:45 <pwhalen> in the process, dgilmore is looking to have it fixed. for tracking it may be good to accept
18:32:48 <pwhalen> one board
18:33:10 <kparal> do you have some estimate how common the board is?
18:33:27 <pwhalen> it is one piece of hw . no estimates. we'd love to know.
18:33:29 <kparal> if it's not a complete outsider, I'm for +1
18:33:42 <roshi> yeah - if it's a more common board, then +1
18:33:46 <pwhalen> it is currently one of the best supported options
18:33:47 <tflink> isn't it one of the supported arm platforms, though?
18:34:08 <pwhalen> it is
18:34:19 <kparal> +1
18:34:25 <roshi> yeah - but if it's an odd board, then it's like blocking for a single odd mobos UEFI setup
18:34:34 <roshi> right? or am I understanding it wrong?
18:35:20 <pwhalen> roshi, pretty common
18:35:29 <roshi> ok
18:35:31 <roshi> +1 then
18:35:54 <pwhalen> +1
18:36:17 <tflink> roshi: it's a bit different for arm, I think. they only list a few boards as supported and this is one of them
18:36:34 <roshi> proposed #agreed - 1044778 - AcceptedBlocker - This blocks the Alpha Criterion "Expected installed system boot behavior": A system installed without a graphical package set must boot  to a state where it is possible to log in through at least one  of the default virtual consoles.
18:36:39 <pwhalen> right, and one of our 'stars'
18:36:54 <roshi> gotcha
18:37:09 <kparal> ack
18:38:07 <roshi> any other acks?
18:38:10 * roshi acks
18:38:15 <pschindl1> ack
18:38:19 <tflink> ack
18:38:25 <roshi> #agreed - 1044778 - AcceptedBlocker - This blocks the Alpha Criterion "Expected installed system boot behavior": A system installed without a graphical package set must boot  to a state where it is possible to log in through at least one  of the default virtual consoles.
18:38:36 <roshi> and now for the last blocker bug
18:38:38 <roshi> #topic (1044304) Segmentation fault in xorg-x11-drv-nouveau with kernel 3.13.0-0.rc3.git5.1.fc21.x86_64
18:38:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1044304
18:38:43 <pschindl1> -1 it seems to be already resolved (last comment)
18:38:44 <roshi> #info Proposed Blocker, xorg-x11-drv-nouveau, NEW
18:39:19 <dgilmore> hola
18:39:25 <pschindl1> I'm not sure why it's not closed then.
18:39:38 <roshi> it's been a couple months and seems to be fixed
18:39:51 <roshi> we were looking at other kde bugs that the desktop worked with later kernels
18:40:44 <kparal> it's old, ask for newer info or drop
18:42:13 <roshi> proposed #agreed - 1044304 - Punt - This bug seems to have gone stale. If it is still an issue, let us know or remove the blocker status.
18:42:31 <kparal> ack
18:42:32 <pwhalen> ack
18:42:36 <nanonyme> ack
18:42:44 <roshi> #agreed - 1044304 - Punt - This bug seems to have gone stale. If it is still an issue, let us know or remove the blocker status.
18:42:50 <roshi> onto freeze exceptions
18:43:11 <roshi> #topic (1116291) [en_US] imsettings-qt pulls in imsettings on Workstation Live causing: can't use any input method in gtk applications for en_US.utf8 locale
18:43:14 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1116291
18:43:16 <roshi> #info Proposed Freeze Exceptions, spin-kickstarts, MODIFIED
18:44:01 <kparal> I wonder if we need to vote on freezeexceptions now
18:44:05 <kparal> it's not freeze yet
18:44:09 <kparal> and it's already modified
18:44:25 <tflink> do we need to do FEs?
18:44:28 * danofsatx-work was at class, here now (albeit too late to do any good)
18:44:31 <roshi> probably not
18:44:45 <roshi> just was on a roll doing the blocker meeting and whatnot :)
18:44:54 <roshi> fingers moving faster than brain I guess
18:45:29 <roshi> anyone got anything else?
18:45:41 <roshi> #topic Open Floor
18:45:54 <danofsatx-work> anything I need to look at immediately, or can i scroll back at my leisure?
18:46:04 <roshi> you can scroll back at your leisure danofsatx-work
18:46:10 <danofsatx-work> roger ball
18:46:22 <roshi> also check out 1044304
18:46:26 * danofsatx-work wonders how many will get that reference
18:46:29 <roshi> it kinda went stale
18:46:35 * roshi has no idea
18:47:10 <roshi> well, if there's nothing left
18:47:15 <danofsatx-work> I submitted comment on that one long ago, but haven't revisited. I'll boot with a newish kernel tonight and check it out.
18:47:40 <roshi> #info Next meeting time - 16:00 UTC on 2014-07-16
18:47:44 <roshi> thanks danofsatx-work
18:48:04 * roshi sets the fuse [0,2]
18:48:46 <roshi> thanks for secretarializing tflink
18:49:46 <roshi> thanks for coming everyone!
18:49:48 <roshi> #endmeeting